From grundler@dsl2.external.hp.com Sun Sep 1 00:50:15 2002
From: grundler@dsl2.external.hp.com (Grant Grundler)
Date: Sat, 31 Aug 2002 17:50:15 -0600
Subject: [parisc-linux] Back to evms-1.0.1 && unaligne access && gdb
In-Reply-To: Message from Joel Soete <joel.soete@freebel.net>
of "Sat, 31 Aug 2002 21:23:59 -0000." <3D7133EF.90602@freebel.net>
References: <200208301703.g7UH3TqX029540@hiauly1.hia.nrc.ca> <3D7133EF.90602@freebel.net>
Message-ID: <20020831235015.C3F8D482A@dsl2.external.hp.com>
Joel Soete wrote:
> Finaly this trial version of function:
>
>
> BOOLEAN isa_null_partition_record(struct partition *p)
> {
> if (p->boot_ind == 0x00 &&
> p->head == 0x00 &&
> p->sector == 0x00 &&
> p->cyl == 0x00 &&
> p->sys_ind == 0x00 &&
> p->end_head == 0x00 &&
> p->end_sector == 0x00 &&
> p->end_cyl == 0x00 &&
> p->start_sect == 0x00 &&
> p->nr_sects == 0x00 )
> return TRUE;
Since start_sect and nr_sects are ints, this code will also generate an
"unaligned data reference fault" like the original code did. You need
to find the origin of "struct partition *p" when the address is un-aligned.
grant
From bruno_vidal@hpfrcu03.france.hp.com Mon Sep 2 07:12:26 2002
From: bruno_vidal@hpfrcu03.france.hp.com (Bruno Vidal)
Date: Mon, 02 Sep 2002 08:12:26 +0200
Subject: [parisc-linux] iodc call and HPMC: dump driver.
Message-ID: <3D73014A.15ED96ED@admin.france.hp.com>
This is a multi-part message in MIME format.
--------------C8EBD1BF8147A59EBF9CB289
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Hi all.
Do you know a guy who is a guru of iodc calls ?
I'm still stuck with this. I think I was really near the
solution. Now my iodc call create beatifull HPMC.
Take a look to this call, I was thinking that it
was all right, but there is still something wrong.
now i'm able to retrieve hpa,
I based this on palo code:
ret = real32_call(PAGE0->mem_boot.iodc_io, (unsigned long)PAGE0->mem_boot.hpa, DUMPDEV_WRITE,
PAGE0->mem_boot.spa, __pa(PAGE0->mem_boot.dp.layers), __pa(pdc_result), devaddr, __pa(iodc_dbuf), 2048);
DUMPDEV_WRITE = 1
static unsigned long pdc_result[32] __attribute__ ((aligned (8)));
static char __attribute__((aligned(64))) iodc_dbuf[DUMP_PAGE_SZ];
and devaddr=191889408
Disk /dev/sda: 64 heads, 32 sectors, 17366 cylinders
Units = cylinders of 2048 * 512 bytes
/dev/sda1 * 1 61 62448 f0 Linux/PA-RISC boot
/dev/sda2 62 183 124928 83 Linux
/dev/sda3 184 1648 1500160 82 Linux swap
/dev/sda4 1649 17366 16095232 5 Extended
/dev/sda5 1649 5554 3999728 83 Linux
/dev/sda6 5555 9460 3999728 82 Linux swap
/dev/sda7 9461 13366 3999728 83 Linux
/dev/sda8 13367 17366 4095984 83 Linux
Do you know someone who is well aware of iodc calls ?
I want to discuss a bit about this.
Thanks.
--
Vidal Bruno, (770-4271)
SSD-HA Team, HP-UX & LINUX Support
bruno_vidal@admin.france.hp.com
--------------C8EBD1BF8147A59EBF9CB289
Content-Type: text/x-vcard; charset=iso-8859-1;
name="bruno_vidal.vcf"
Content-Transfer-Encoding: base64
Content-Description: Card for Bruno Vidal
Content-Disposition: attachment;
filename="bruno_vidal.vcf"
YmVnaW46dmNhcmQgCm46QnJ1bm87VklEQUwKdGVsO2ZheDowMS02OS04Mi02MC0xNAp0ZWw7
d29yazowMS02OS0yOS00Mi03MQp4LW1vemlsbGEtaHRtbDpUUlVFCnVybDp3d3cuZnJhbmNl
LmhwLmNvbQpvcmc6U29sdXRpb24gQ2VudGVyCnZlcnNpb246Mi4xCmVtYWlsO2ludGVybmV0
OmJydW5vX3ZpZGFsQGhwLmNvbQp0aXRsZTpFeHBlcnQgTG9naWNpZWwgRW52aXJvbm5lbWVu
dCBIYXV0ZSBEaXNwb25pYmlsaXTpCmFkcjtxdW90ZWQtcHJpbnRhYmxlOjs7SFAgRnJhbmNl
PTBEPTBBO1ouQSBkZSBDb3VydGFib2V1ZjsxIEF2LiBkdSBDYW5hZGE7OTE5NDcgTGVzIFVs
aXMgY2VkZXg7RnJhbmNlCngtbW96aWxsYS1jcHQ6OzI2MjA4CmZuOlZJREFMIEJydW5vCmVu
ZDp2Y2FyZAo=
--------------C8EBD1BF8147A59EBF9CB289--
From jsoe0708@tiscali.be Mon Sep 2 09:47:59 2002
From: jsoe0708@tiscali.be (jsoe0708@tiscali.be)
Date: Mon, 2 Sep 2002 10:47:59 +0200
Subject: [parisc-linux] Back to evms-1.0.1 && unaligne access && gdb
Message-ID: <3D3815BD0000A476@ocpmta5.be.tiscali.com>
>-- Original Message --
>To: Joel Soete <joel.soete@freebel.net>
>Cc: John David Anglin <dave@hiauly1.hia.nrc.ca>, jsoe0708@tiscali.be,
> parisc-linux@lists.parisc-linux.org
>Subject: Re: [parisc-linux] Back to evms-1.0.1 && unaligne access && gdb
>
>From: Grant Grundler <grundler@dsl2.external.hp.com>
>Date: Sat, 31 Aug 2002 17:50:15 -0600
>
>
>Joel Soete wrote:
>> Finaly this trial version of function:
>>
>>
>> BOOLEAN isa_null_partition_record(struct partition *p)
>> {
>> if (p->boot_ind == 0x00 &&
>> p->head == 0x00 &&
>> p->sector == 0x00 &&
>> p->cyl == 0x00 &&
>> p->sys_ind == 0x00 &&
>> p->end_head == 0x00 &&
>> p->end_sector == 0x00 &&
>> p->end_cyl == 0x00 &&
>> p->start_sect == 0x00 &&
>> p->nr_sects == 0x00 )
>> return TRUE;
>
>Since start_sect and nr_sects are ints, this code will also generate an
>"unaligned data reference fault" like the original code did.
Trust me it does not? (it works fine)
>You need
>to find the origin of "struct partition *p" when the address is un-aligned.
>
Very hard to define:
a. the previous code works (again all odds)
b. the following trial code:
"
#include <stdlib.h>
#include <stdio.h>
#include <string.h>
#include <errno.h>
typedef u_int8_t BOOLEAN;
#ifndef TRUE
#define TRUE 1
#endif
#ifndef FALSE
#define FALSE 0
#endif
struct partition {
unsigned char boot_ind; /* 0x80 - active */
unsigned char head; /* starting head */
unsigned char sector; /* starting sector */
unsigned char cyl; /* starting cylinder */
unsigned char sys_ind; /* What partition type */
unsigned char end_head; /* end head */
unsigned char end_sector; /* end sector */
unsigned char end_cyl; /* end cylinder */
unsigned int start_sect; /* starting sector counting from 0 */
unsigned int nr_sects; /* nr of sectors in partition */
};
BOOLEAN isa_null_partition_record(struct partition *p)
{
int i;
u_int32_t *uip = (u_int32_t *) p;
for (i=0; i<4; i++) {
if (*uip!=0x00) return FALSE;
}
return TRUE;
}
int main(int argc, char * * argv, char * * env) {
struct partition p1, p2;
p1.boot_ind=0;
p1.head=0;
p1.sector=0;
p1.cyl=0;
p1.sys_ind=0;
p1.end_head=0;
p1.end_sector=0;
p1.end_cyl=0;
p1.start_sect=0;
p1.nr_sects=0;
printf("Is that p1 is a null partition: %u\n", isa_null_partition_record(&p1));
p2.boot_ind=1;
p2.head=2;
p2.sector=3;
p2.cyl=4;
p2.sys_ind=5;
p2.end_head=6;
p2.end_sector=7;
p2.end_cyl=8;
p2.start_sect=9;
p2.nr_sects=10;
printf("Is that p2 is a null partition: %u\n", isa_null_partition_record(&p2));
return 0;
}
"
did not reproduce the problem.
Even if in the previous code, I replace:
BOOLEAN isa_null_partition_record(struct partition *p)
{
int i;
u_int32_t *uip = (u_int32_t *) p;
for (i=0; i<4; i++) {
if (*uip!=0x00) return FALSE;
}
return TRUE;
}
by
extern BOOLEAN isa_null_partition_record(struct partition *p);
and also link it with the original library containing isa_null_partition_record,
I can no more reproduce the problem.
The only difference I can notice is that 'isa_null_partition_record' is
not directly used by evms tools but through modules loaded at run time (the
cause of gdb debug difficulties) (or am I wrong and a subtil detail escape
to my attention)?
What can I do to analyse this problem? (printing all p addresses and its
elements
during a run with the original code and compare with a run with modified
code?)
Thanks again for attention and help,
Joel
From jsoe0708@tiscali.be Mon Sep 2 11:02:49 2002
From: jsoe0708@tiscali.be (jsoe0708@tiscali.be)
Date: Mon, 2 Sep 2002 12:02:49 +0200
Subject: [parisc-linux] Gcc-3.2 beside gcc-3.0: HOWTO?
Message-ID: <3D3815BD0000A54B@ocpmta5.be.tiscali.com>
Hi all,
I install gcc-3.2 beside default gcc-3.0.
I would like to use gcc-3.2 to compile the latest cvs kernel. HOWTO do this?
Thanks in advance,
Joel
PS: with gcc-3.1.1 snapshot I reach to obtain a bootable 32bit kernel but
presenting a problem with network connection. Was I alone to observe this?
From jsoe0708@tiscali.be Mon Sep 2 15:56:11 2002
From: jsoe0708@tiscali.be (jsoe0708@tiscali.be)
Date: Mon, 2 Sep 2002 16:56:11 +0200
Subject: [parisc-linux] Gcc-3.2 beside gcc-3.0: HOWTO?
In-Reply-To: <3D3815BD0000A54B@ocpmta5.be.tiscali.com>
Message-ID: <3D3815BD0000A825@ocpmta5.be.tiscali.com>
>
>Hi all,
>
>I install gcc-3.2 beside default gcc-3.0.
>
>I would like to use gcc-3.2 to compile the latest cvs kernel. HOWTO do this?
>
>Thanks in advance,
> Joel
>
>PS: with gcc-3.1.1 snapshot I reach to obtain a bootable 32bit kernel but
>presenting a problem with network connection. Was I alone to observe this?
>
I also forget to mentionned that I also applied recommendation in /usr/share/doc/gcc-3.2-base/README.Debian.gz
(ie: CC="gcc-3.2" ; export CC but in the kernel special case there is no
./configure step so may be there is another teaps. And with snapshot gcc
was build in another tree so the problem didn't exists)
Many thanks again for all help,
Joel
From Randolph Chung <randolph@tausq.org> Mon Sep 2 16:21:37 2002
From: Randolph Chung <randolph@tausq.org> (Randolph Chung)
Date: Mon, 2 Sep 2002 08:21:37 -0700
Subject: [parisc-linux] Gcc-3.2 beside gcc-3.0: HOWTO?
In-Reply-To: <3D3815BD0000A54B@ocpmta5.be.tiscali.com>
References: <3D3815BD0000A54B@ocpmta5.be.tiscali.com>
Message-ID: <20020902152137.GG25710@tausq.org>
> I would like to use gcc-3.2 to compile the latest cvs kernel. HOWTO do this?
edit the toplevel kernel Makefile and change the HOSTCC and CC lines
so that HOSTCC=gcc-3.2 and CC=$(CROSS_COMPILE)gcc-3.2
randolph
--
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/
From jsoe0708@tiscali.be Mon Sep 2 17:31:15 2002
From: jsoe0708@tiscali.be (jsoe0708@tiscali.be)
Date: Mon, 2 Sep 2002 18:31:15 +0200
Subject: [parisc-linux] Gcc-3.2 beside gcc-3.0: HOWTO?
In-Reply-To: <20020902152137.GG25710@tausq.org>
Message-ID: <3D3815BD0000A8AE@ocpmta5.be.tiscali.com>
>> I would like to use gcc-3.2 to compile the latest cvs kernel. HOWTO do
>this?
>
>edit the toplevel kernel Makefile and change the HOSTCC and CC lines
>so that HOSTCC=gcc-3.2 and CC=$(CROSS_COMPILE)gcc-3.2
>
Oops the 32bits kernel which I obtain, boot well on my b2k but ip connection
problem is always there: the system seems to loop somewhere with ssh (heart
bit seems life and no more response neither at serial console, neither at
ssh prompt) and telnet causes an HPMC (bus timeout?)
I try find information on howto run sshd with gdb on the server (MARC ml
archives) but do not found any relevant info. And i don't know if Bruno LKCD
would help if near to be ready.
What can I do?
Joel
PS: this problem was not with gcc-3.2 (now snapshot 3.3) and it is a long
time I play with gcc snapshot to compare.
From marc@centraltx.com Mon Sep 2 17:37:00 2002
From: marc@centraltx.com (marc )
Date: Mon, 2 Sep 2002 11:37:00 -0500
Subject: [parisc-linux] Kernel Panic
Message-ID: <200209021137.AA3784507924@mail.centraltx.com>
Guys, I'm getting a kernel panic after trying to access my tape drive.
Can anyone help me out? I tried to post all relevant info, let me know
if I can provide anything else:
-----------------FIRST TRY----------------
Debian GNU/Linux 3.0 seki ttyS0
seki login: root
Password:
Last login: Sat Nov 14 02:50:47 1992 on ttyS0
Linux seki 2.4.9-32 #1 Fri Nov 30 19:36:30 MST 2001 parisc unknown
seki:~/test# tar -xvpf /dev/st0
st: Version 20010812, bufsize 32768, wrt 30720, max init. bufs 4, s/g segs 16
Attached scsi tape st0 at scsi1, channel 0, id 1, lun 0
st0: Block limits 1 - 16777215 bytes.
ccio-dma.c:362: Assertion (*res_ptr & *mask_ptr) == *mask_ptr failed!
Kernel panic: (*res_ptr & *mask_ptr) == *mask_ptr
In interrupt handler - not syncing
-----------------END FIRST TRY----------------
-----------------SECOND TRY----------------
Debian GNU/Linux 3.0 seki ttyS0
seki login: root
Password:
Last login: Sat Nov 14 02:41:23 1992 on ttyS0
Linux seki 2.4.9-32 #1 Fri Nov 30 19:36:30 MST 2001 parisc unknown
seki:~# lsmod
Module Size Used by
seki:~# insmod st
Using /lib/modules/2.4.9-32/kernst: Version 20010812, bufsize 32768, wrt 30720,
max init. bufs 4, s/g segs 16
el/drivers/scsi/Attached scsi tape st0 at scsi1, channel 0, id 1, lun 0
st.o
seki:~# cat /proc/scsi/scsi
Attached devices:
Host: scsi0 Channel: 00 Id: 05 Lun: 00
Vendor: SEAGATE Model: ST34371W Rev: HP03
Type: Direct-Access ANSI SCSI revision: 02
Host: scsi0 Channel: 00 Id: 06 Lun: 00
Vendor: SEAGATE Model: ST32171W Rev: HP03
Type: Direct-Access ANSI SCSI revision: 02
Host: scsi1 Channel: 00 Id: 01 Lun: 00
Vendor: SONY Model: SDT-7000 Rev: 0150
Type: Sequential-Access ANSI SCSI revision: 02
seki:~# mt -f /dev/st0 status
st0: Block limits 1 - 16777215 bytes.
drive type = Generic SCSI-2 tape
drive status = 318767616
sense key error = 0
residue count = 0
file number = 0
block number = 0
Tape block size 512 bytes. Density code 0x13 (DDS (61000 bpi)).
Soft error count since last status=0
General status bits on (41010000):
BOT ONLINE IM_REP_EN
seki:~# tar -cvpf /dev/st0 /tftpboot
tar: Removing leading `/' from member names
tftpboot/
tftpboot/tftpboot.img
ccio-dma.c:362: Assertion (*res_ptr & *mask_ptr) == *mask_ptr failed!
Kernel panic: (*res_ptr & *mask_ptr) == *mask_ptr
In interrupt handler - not syncing
-----------------END SECOND TRY----------------
-----------------BOOT INFO----------------
Firmware Version 2.7
Duplex Console IO Dependent Code (IODC) revision 1
------------------------------------------------------------------------------
(c) Copyright 1995-1998, Hewlett-Packard Company, All rights reserved
------------------------------------------------------------------------------
Processor Speed State Coprocessor State I/D Cache
--------- -------- --------------------- ----------------- -------------
0 180 MHz Active Functional 1 MB/1 MB
Central Bus Speed (in MHz) : 120
Available memory (bytes) : 805306368
Good memory required (bytes): 0 (Not Set by OS)
Primary boot path: FWSCSI.6.0
Alternate boot path: SESCSI.6.0
Console path: GRAPHICS(3)
Keyboard path: PS2
CPU 0
WARNING: Self tests have been disabled as a result of FASTBOOT
being enabled. To enable self tests, use the FASTBOOT
command in the CONFIGURATION menu and reboot the system.
WARNING: Memory has been initialized, but not tested as a result of
FASTBOOT being enabled. To test memory, use the FASTBOOT
command in the CONFIGURATION menu and reboot the system.
Processor is booting from first available device.
To discontinue, press any key within 10 seconds.
10 seconds expired.
Proceeding...
Searching for device(s) with bootable media...
This may take several minutes.
To discontinue search, press any key (termination may not be immediate).
Attempting to boot Primary Path...
BOOTABLE DEVICE FOUND:
Path Number Device Path Device Type and Utilities
----------- ----------------- -------------------------
P0 FWSCSI.6.0 SEAGATE ST32171W
IPL
Booting...
Boot IO Dependent Code (IODC) revision 150
HARD Booted.
palo ipl 0.96 root@smallone Sun Nov 11 23:23:30 UTC 2001
Partition Start(MB) End(MB) Id Type
1 1 16 f0 Palo
3 1315 2046 82 swap
5 17 1314 83 ext2
PALO(F0) partition contains:
0/vmlinux32 3122078 bytes @ 0x48000
Information: No console specified on kernel command line. This is normal.
PALO will choose the console currently used by firmware (serial).
Command line for kernel: 'root=/dev/sdb5 HOME=/ console=ttyS0 TERM=vt102'
Selected kernel: /boot/vmlinux from partition 5
Opening /boot/vmlinux
Opening /boot/vmlinux-2.4.9-32
ELF32 executable
Entry 00100000 first 00100000 n 6
Segment 0 load 00100000 size 1618208 mediaptr 0x1000
Segment 1 load 0028c000 size 287728 mediaptr 0x18d000
Segment 2 load 002d4000 size 379072 mediaptr 0x1d4000
Segment 3 load 00334000 size 8192 mediaptr 0x231000
Segment 4 load 00338000 size 32768 mediaptr 0x233000
Segment 5 load 003750e8 size 83184 mediaptr 0x23b0e8
Branching to kernel entry point 0x00100000. If this is the last
message you see, you may need to switch your console. This is
a common symptom -- search the FAQ and mailing list at parisc-linux.org
Linux version 2.4.9-32 (root@paer) (gcc version 3.0.2 (Debian)) #1 Fri Nov 30 19
:36:30 MST 2001
FP[0] enabled: Rev 0 Model 14
The 32-bit Kernel has started...
Determining PDC firmware type: System Map.
model 000059c0 00000481 00000000 00000002 77d14d81 100000f0 00000008 000000b2
000000b2
vers 00000205
cpuid 000001c9
CPUID vers 14 rev 9
model 9000/780/C180
Total Memory: 768 Mb
pagetable_init
On node 0 totalpages: 196608
zone(0): 196608 pages.
zone(1): 0 pages.
zone(2): 0 pages.
LED display at f0190001 registered
Kernel command line: root=/dev/sdb5 HOME=/ console=ttyS0 TERM=vt102
Console: colour dummy device 160x64
Calibrating delay loop... 358.80 BogoMIPS
Memory: 770644k available
Dentry-cache hash table entries: 131072 (order: 8, 1048576 bytes)
Inode-cache hash table entries: 65536 (order: 7, 524288 bytes)
Mount-cache hash table entries: 16384 (order: 5, 131072 bytes)
Buffer-cache hash table entries: 65536 (order: 6, 262144 bytes)
Page-cache hash table entries: 262144 (order: 8, 1048576 bytes)
Searching for devices...
Found devices:
1. U2-IOA BC Runway Port (12) at 0xfff88000 [8], versions 0x580, 0xf, 0xb
2. Dino PCI Bridge (13) at 0xf2000000 [8/0], versions 0x680, 0x1, 0xa
3. Raven U/L2 Core FW-SCSI (4) at 0xf200c000 [8/12], versions 0x3b, 0x0, 0x89
4. Raven U/L2 Core BA (11) at 0xffd00000 [8/16], versions 0x3b, 0x0, 0x81, addi
tional addresses: 0xffc00000
5. UL 350 Core Centronics (10) at 0xffd02000 [8/16/0], versions 0x2e, 0x0, 0x74,
additional addresses: 0xffd03000
6. Raven U/L2 Core Audio (10) at 0xffd04000 [8/16/1], versions 0x3b, 0x4, 0x7b
7. Raven U/L2 Core RS-232 (10) at 0xffd05000 [8/16/4], versions 0x3b, 0x0, 0x8c
8. Raven U/L2 Core SCSI (10) at 0xffd06000 [8/16/5], versions 0x3b, 0x0, 0x82
9. Raven U/L2 Core LAN (802.3) (10) at 0xffd07000 [8/16/6], versions 0x3b, 0x0,
0x8a
10. Raven U/L2 Core PS/2 Port (10) at 0xffd08000 [8/16/7], versions 0x3b, 0x0, 0
x84
11. Raven U/L2 Core PS/2 Port (10) at 0xffd08100 [8/16/8], versions 0x3b, 0x0, 0
x84
12. Raven Backplane Wax BA (11) at 0xffe00000 [8/20], versions 0x17, 0x0, 0x8e
13. Raven Backplane Wax HIL (10) at 0xffe01000 [8/20/1], versions 0x17, 0x0, 0x7
3
14. Raven Backplane RS-232 (10) at 0xffe02000 [8/20/2], versions 0x17, 0x0, 0x8c
15. Raven Backplane Wax EISA BA (11) at 0xfc000000 [8/20/5], versions 0x17, 0x0,
0x90, additional addresses: 0xfc00000b
16. Gecko GSC Core Graphics (10) at 0xfa000000 [8/24], versions 0x16, 0x0, 0x85
17. U2-IOA BC GSC+ Port (7) at 0xf203f000 [8/63], versions 0x501, 0x1, 0xc
18. U2-IOA BC Runway Port (12) at 0xfff8a000 [10], versions 0x580, 0xf, 0xb
19. Coral SGC Graphics (10) at 0xf8000000 [10/8], versions 0x4, 0x0, 0x77
20. U2-IOA BC GSC+ Port (7) at 0xf103f000 [10/63], versions 0x501, 0x1, 0xc
21. Raven U 180 (9000/780/C180) (0) at 0xfffa0000 [32], versions 0x59c, 0x0, 0x4
22. Raven U 180 (1) at 0xfffb1000 [49], versions 0x72, 0x0, 0x9
CPU(s): 1 x PA8000 (PCX-U) at 180.000000 MHz
ccio found U2 at 0xfff88000
io_io_low: 0xf2000000
23. Dino PCI Bridge (13) at 0xf2000000 [8/0], versions 0x680, 0x1, 0xa
24. Dino PS/2 Port (10) at 0xf2001000 [8/1], versions 0x7, 0x0, 0x96
25. Raven Backplane RS-232 (10) at 0xf2003000 [8/3], versions 0x17, 0x0, 0x8c
26. Raven U/L2 Core FW-SCSI (4) at 0xf200c000 [8/12], versions 0x3b, 0x0, 0x89
27. Raven U/L2 Core BA (11) at 0xffd00000 [8/16], versions 0x3b, 0x0, 0x81, add
itional addresses: 0xffc00000
28. UL 350 Core Centronics (10) at 0xffd02000 [8/16/0], versions 0x2e, 0x0, 0x74
, additional addresses: 0xffd03000
29. Raven U/L2 Core Audio (10) at 0xffd04000 [8/16/1], versions 0x3b, 0x4, 0x7b
30. Raven U/L2 Core RS-232 (10) at 0xffd05000 [8/16/4], versions 0x3b, 0x0, 0x8c
31. Raven U/L2 Core SCSI (10) at 0xffd06000 [8/16/5], versions 0x3b, 0x0, 0x82
32. Raven U/L2 Core LAN (802.3) (10) at 0xffd07000 [8/16/6], versions 0x3b, 0x0,
0x8a
33. Raven U/L2 Core PS/2 Port (10) at 0xffd08000 [8/16/7], versions 0x3b, 0x0, 0
x84
34. Raven U/L2 Core PS/2 Port (10) at 0xffd08100 [8/16/8], versions 0x3b, 0x0, 0
x84
35. Raven Backplane Wax BA (11) at 0xffe00000 [8/20], versions 0x17, 0x0, 0x8e
36. Raven Backplane Wax HIL (10) at 0xffe01000 [8/20/1], versions 0x17, 0x0, 0x7
3
37. Raven Backplane RS-232 (10) at 0xffe02000 [8/20/2], versions 0x17, 0x0, 0x8c
38. Raven Backplane Wax EISA BA (11) at 0xfc000000 [8/20/5], versions 0x17, 0x0,
0x90, additional addresses: 0xfc00000b
39. Gecko GSC Core Graphics (10) at 0xfa000000 [8/24], versions 0x16, 0x0, 0x85
40. U2-IOA BC GSC+ Port (7) at 0xf203f000 [8/63], versions 0x501, 0x1, 0xc
ccio found U2 at 0xfff8a000
io_io_low: 0xf1000000
41. Coral SGC Graphics (10) at 0xf8000000 [10/8], versions 0x4, 0x0, 0x77
42. U2-IOA BC GSC+ Port (7) at 0xf103f000 [10/63], versions 0x501, 0x1, 0xc
Lasi version 0 at 0xffd00000 found.
Wax at 0xffe00000 found.
Wax: HIL Keyboard-NMI registered.
Wax EISA Adapter found at 0xfc000000
Dino version 2.1 found at 0xf2000000
The GSCtoPCI (Dino hrev 1) bus converter found may exhibit
data corruption. See Service Note Numbers: A4190A-01, A4191A-01.
Systems shipped after Aug 20, 1997 will not exhibit this problem.
Models affected: C180, C160, C160L, B160L, and B132L workstations.
Dino: No PCI devices enabled.
POSIX conformance testing by UNIFIX
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Starting kswapd v1.8
parport_init_chip: initialize bidirectional-mode.
parport0: PC-style at 0xffd02800, irq 88 [PCSPP,TRISTATE]
STI word mode ROM at f0084000, hpa=fa000000
STI word mode ROM, id 2d08c0a7-9a02587, conforms to spec rev. 8.07
STI device: INTERNAL_EG_1280
STI byte mode ROM at f8000000, hpa=f8000000
STI byte mode ROM, id 2bcb015a-9a02587, conforms to spec rev. 8.04
STI device: HPA4071B_LZ
Console: switching to colour frame buffer device 160x64
fb0: stifb 1280x1024-8 frame buffer device, id: 2d08c0a7, mmio: 0xfa100000
fb1: stifb 1280x1024-32 frame buffer device, id: 2bcb015a, mmio: 0xf8100000
pty: 256 Unix98 ptys configured
Serial driver version 5.05c (2001-07-08) with MANY_PORTS SHARE_IRQ SERIAL_PCI en
abled
ttyS00 at iomem 0xffd05800 (irq = 90) is a 16550A
ttyS01 at iomem 0xf2003800 (irq = 138) is a 16550A
ttyS02 at iomem 0xffe02800 (irq = 121) is a 16550A
Lasi PS/2 receive buffer timeout
PS/2 keyboard port at 0xffd08000 (irq 69) found, no device attached.
Lasi PS/2 transmit buffer timeout
PS/2 psaux port at 0xffd08100 (irq 69) found, no device attached.
Found HIL at 0xffe01000, IRQ 126
IRQ: CPU:0 No handler for IRQ 35 !
HIL: timed out, assuming no keyboard present.
Warning : device (10, 0x17, 0x0, 0x73) NOT claimed by HIL
lp0: using parport0 (interrupt-driven).
Generic RTC Driver v1.02 05/27/1999 Sam Creasey (sammy@oh.verio.com)
block: 128 slots per queue, batch=16
RAMDISK driver initialized: 16 RAM disks of 6144K size 1024 blocksize
loop: loaded (max 8 devices)
Found i82596 at 0xffd07000, IRQ 87
eth0: 82596 at 0xffd07000, 00 60 B0 18 9B B9 IRQ 87.
82596.c $Revision: 1.26 $
SCSI subsystem driver Revision: 1.00
zalon_scsi_callback: Zalon vers field is 0x1, IRQ 35
ncr53c8xx: 53c720 detected
ncr53c720-0: ID 7, Fast-10, Parity Checking, Differential
scsi0 : ncr53c8xx-3.4.3b-20010512
Vendor: SEAGATE Model: ST34371W Rev: HP03
Type: Direct-Access ANSI SCSI revision: 02
Vendor: SEAGATE Model: ST32171W Rev: HP03
Type: Direct-Access ANSI SCSI revision: 02
53c700: Version 2.6 By James.Bottomley@HansenPartnership.com
scsi1: 53c710 rev 2
scsi1 : LASI SCSI 53c700
scsi1: (1:0) Synchronous at offset 8, period 100ns
Vendor: SONY Model: SDT-7000 Rev: 0150
Type: Sequential-Access ANSI SCSI revision: 02
Attached scsi disk sda at scsi0, channel 0, id 5, lun 0
Attached scsi disk sdb at scsi0, channel 0, id 6, lun 0
ncr53c720-0-<5,*>: FAST-10 WIDE SCSI 20.0 MB/s (100 ns, offset 8)
SCSI device sda: 8388314 512-byte hdwr sectors (4295 MB)
Partition check:
sda: sda1
ncr53c720-0-<6,*>: FAST-10 WIDE SCSI 20.0 MB/s (100 ns, offset 8)
SCSI device sdb: 4194685 512-byte hdwr sectors (2148 MB)
sdb: sdb1 sdb2 < sdb5 > sdb3
Lasi Harmony Audio rev. 2 at 0xffd04000, using IRQ 82
sticonsole_init: searching for STI ROMs
md: md driver 0.90.0 MAX_MD_DEVS=256, MD_SB_DISKS=27
md: Autodetecting RAID arrays.
md: autorun ...
md: ... autorun DONE.
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP
IP: routing cache hash table of 8192 buckets, 64Kbytes
TCP: Hash tables configured (established 262144 bind 65536)
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
VFS: Mounted root (ext2 filesystem) readonly.
INIT: version 2.84 booting
Activating swap.
Adding Swap: 749788k swap-space (priority -1)
Checking root file system...
fsck 1.27 (8-Mar-2002)
/dev/sdb5: clean, 3167/166496 files, 32915/332312 blocks
System time was Fri Nov 13 19:56:56 UTC 1992.
Setting the System Clock using the Hardware Clock as reference...
System Clock set. System local time is now Fri Nov 13 19:57:04 UTC 1992.
Calculating module dependencies... done.
Loading modules:
Note: /etc/modules.conf is more recent than /lib/modules/2.4.9-32/modules.dep
modprobe: Can't locate module *
Checking all file systems...
fsck 1.27 (8-Mar-2002)
/dev/sda1: clean, 21754/524288 files, 116146/1048265 blocks
Setting kernel variables.
Mounting local filesystems...
/dev/sda1 on /usr type ext2 (rw)
Running 0dns-down to make sure resolv.conf is ok...done.
Cleaning: /etc/network/ifstate.
Setting up IP spoofing protection: rp_filter.
Configuring network interfaces: eth0: Transceiver problem.
ip_local_deliver: bad loopback skb: PRE_ROUTING LOCAL_IN
skb: pf=2 (unowned) dev=lo len=328
PROTO=17 0.0.0.0:68 255.255.255.255:67 L=328 S=0x10 I=0 F=0x0000 T=16
ip_local_deliver: bad loopback skb: PRE_ROUTING LOCAL_IN
skb: pf=2 (unowned) dev=lo len=328
PROTO=17 0.0.0.0:68 255.255.255.255:67 L=328 S=0x10 I=0 F=0x0000 T=16
ip_local_deliver: bad loopback skb: PRE_ROUTING LOCAL_IN
skb: pf=2 (unowned) dev=lo len=328
PROTO=17 0.0.0.0:68 255.255.255.255:67 L=328 S=0x10 I=0 F=0x0000 T=16
ip_local_deliver: bad loopback skb: PRE_ROUTING LOCAL_IN
skb: pf=2 (unowned) dev=lo len=328
PROTO=17 0.0.0.0:68 255.255.255.255:67 L=328 S=0x10 I=0 F=0x0000 T=16
ip_local_deliver: bad loopback skb: PRE_ROUTING LOCAL_IN
skb: pf=2 (unowned) dev=lo len=328
PROTO=17 0.0.0.0:68 255.255.255.255:67 L=328 S=0x10 I=0 F=0x0000 T=16
ip_local_deliver: bad loopback skb: PRE_ROUTING LOCAL_IN
skb: pf=2 (unowned) dev=lo len=328
PROTO=17 0.0.0.0:68 255.255.255.255:67 L=328 S=0x10 I=0 F=0x0000 T=16
Setting the System Clock using the Hardware Clock as reference...
System Clock set. Local time: Fri Nov 13 13:57:56 CST 1992
Cleaning: /tmp /var/lock /var/run.
Initializing random number generator... done.
Recovering nvi editor sessions... done.
INIT: Entering runlevel: 2
Starting system log daemon: syslogd.
Starting kernel log daemon: klogd.
Starting DHCP server: dhcp.
Starting internet superserver: inetd.
/usr/share/sendmail/sendmail not found/executable, aborting.
Starting OpenBSD Secure Shell server: sshd.
Starting periodic command scheduler: cron.
-----------------END BOOT INFO----------------
From Randolph Chung <randolph@tausq.org> Mon Sep 2 17:44:24 2002
From: Randolph Chung <randolph@tausq.org> (Randolph Chung)
Date: Mon, 2 Sep 2002 09:44:24 -0700
Subject: [parisc-linux] Gcc-3.2 beside gcc-3.0: HOWTO?
In-Reply-To: <3D3815BD0000A8AE@ocpmta5.be.tiscali.com>
References: <20020902152137.GG25710@tausq.org> <3D3815BD0000A8AE@ocpmta5.be.tiscali.com>
Message-ID: <20020902164424.GE14634@tausq.org>
> Oops the 32bits kernel which I obtain, boot well on my b2k but ip connection
> problem is always there: the system seems to loop somewhere with ssh (heart
> bit seems life and no more response neither at serial console, neither at
> ssh prompt) and telnet causes an HPMC (bus timeout?)
looking up the iaoq and gr02 values reported in the hpmc in System.map
would be the first step...
randolph
--
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/
From marc@centraltx.com Mon Sep 2 17:38:20 2002
From: marc@centraltx.com (marc )
Date: Mon, 2 Sep 2002 11:38:20 -0500
Subject: [parisc-linux] Network Problems
Message-ID: <200209021138.AA3341287994@mail.centraltx.com>
Anyone have any ideas why I get innundated with these messages on
startup and have to do a control-c to get past this part and continue booting?
Configuring network interfaces: eth0: Transceiver problem.
ip_local_deliver: bad loopback skb: PRE_ROUTING LOCAL_IN
skb: pf=2 (unowned) dev=lo len=328
PROTO=17 0.0.0.0:68 255.255.255.255:67 L=328 S=0x10 I=0 F=0x0000 T=16
ip_local_deliver: bad loopback skb: PRE_ROUTING LOCAL_IN
skb: pf=2 (unowned) dev=lo len=328
PROTO=17 0.0.0.0:68 255.255.255.255:67 L=328 S=0x10 I=0 F=0x0000 T=16
ip_local_deliver: bad loopback skb: PRE_ROUTING LOCAL_IN
skb: pf=2 (unowned) dev=lo len=328
PROTO=17 0.0.0.0:68 255.255.255.255:67 L=328 S=0x10 I=0 F=0x0000 T=16
ip_local_deliver: bad loopback skb: PRE_ROUTING LOCAL_IN
skb: pf=2 (unowned) dev=lo len=328
PROTO=17 0.0.0.0:68 255.255.255.255:67 L=328 S=0x10 I=0 F=0x0000 T=16
ip_local_deliver: bad loopback skb: PRE_ROUTING LOCAL_IN
skb: pf=2 (unowned) dev=lo len=328
PROTO=17 0.0.0.0:68 255.255.255.255:67 L=328 S=0x10 I=0 F=0x0000 T=16
ip_local_deliver: bad loopback skb: PRE_ROUTING LOCAL_IN
skb: pf=2 (unowned) dev=lo len=328
PROTO=17 0.0.0.0:68 255.255.255.255:67 L=328 S=0x10 I=0 F=0x0000 T=16
From Randolph Chung <randolph@tausq.org> Mon Sep 2 17:51:14 2002
From: Randolph Chung <randolph@tausq.org> (Randolph Chung)
Date: Mon, 2 Sep 2002 09:51:14 -0700
Subject: [parisc-linux] Kernel Panic
In-Reply-To: <200209021137.AA3784507924@mail.centraltx.com>
References: <200209021137.AA3784507924@mail.centraltx.com>
Message-ID: <20020902165114.GF14634@tausq.org>
In reference to a message from marc , dated Sep 02:
> Guys, I'm getting a kernel panic after trying to access my tape drive.
> Can anyone help me out? I tried to post all relevant info, let me know
> if I can provide anything else:
first step would be to try a newer kernel. 2.4.9 is very old :-)
you can either compile stuff from cvs (instructions on the
www.parisc-linux.org website), or grab a precompiled one either from
debian or ftp://ftp.parisc-linux.org/kernels/32/32-2.4.19-pa9.tar.gz
randolph
--
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/
From grundler@dsl2.external.hp.com Mon Sep 2 18:28:54 2002
From: grundler@dsl2.external.hp.com (Grant Grundler)
Date: Mon, 02 Sep 2002 11:28:54 -0600
Subject: [parisc-linux] Back to evms-1.0.1 && unaligne access && gdb
In-Reply-To: Message from jsoe0708@tiscali.be
of "Mon, 02 Sep 2002 10:47:59 +0200." <3D3815BD0000A476@ocpmta5.be.tiscali.com>
References: <3D3815BD0000A476@ocpmta5.be.tiscali.com>
Message-ID: <20020902172854.C73F44829@dsl2.external.hp.com>
jsoe0708@tiscali.be wrote:
> >Since start_sect and nr_sects are ints, this code will also generate an
> >"unaligned data reference fault" like the original code did.
>
> Trust me it does not? (it works fine)
then I'll wager there is padding between the char and int fields
of that struct.
> >You need
> >to find the origin of "struct partition *p" when the address is un-aligned.
> >
> Very hard to define:
> a. the previous code works (again all odds)
> b. the following trial code:
...
> int main(int argc, char * * argv, char * * env) {
>
> struct partition p1, p2;
...
> did not reproduce the problem.
Things on the stack (local var) are properly aligned.
Malloc a block of mem and then point to an unaligned address
in that block.
> What can I do to analyse this problem? (printing all p addresses and its
> elements
> during a run with the original code and compare with a run with modified
> code?)
yes. You want to verify the addreses are unaligned.
grant
From carlos@baldric.uwo.ca Tue Sep 3 00:47:52 2002
From: carlos@baldric.uwo.ca (Carlos O'Donell)
Date: Mon, 2 Sep 2002 19:47:52 -0400
Subject: [parisc-linux] Status update hppa - glibc 2.2.92 (Problems with __divdi3)
Message-ID: <20020902234752.GA6718@systemhalted>
p-l,
I've already posted the same thing on debian-glibc.
a. 'cvs co' from glibc upstream cvs (2.2.92)
b. Apply debian patches from 0list
c. Fix things
Preliminary modified patches for hppa are at:
http://www.baldric.uwo.ca/~carlos/glibc-2.3/glibc23-hppa-pthreads.dpatch
http://www.baldric.uwo.ca/~carlos/glibc-2.3/glibc23-hppa-rela.dpatch
These replace the previous glibc22-* patches of the same name.
Please do _NOT_ accept these as final versions, I'm presenting them
for anyone who may want to attempt to recreate or verify my problem.
Current build issues are:
gcc-3.2 -nostdlib -nostartfiles -o /mnt/flaire/src/glibc-upstream-cvs/libc-=
build/iconv/iconvconfig -Wl,-dynamic-linker=3D/lib/ld.so.1 /mnt/flaire/=
src/glibc-upstream-cvs/libc-build/csu/crt1.o /mnt/flaire/src/glibc-upstream=
-cvs/libc-build/csu/crti.o `gcc-3.2 --print-file-name=3Dcrtbegin.o` /mnt/fl=
aire/src/glibc-upstream-cvs/libc-build/iconv/iconvconfig.o /mnt/flaire/src/=
glibc-upstream-cvs/libc-build/iconv/strtab.o /mnt/flaire/src/glibc-upstream=
-cvs/libc-build/iconv/xmalloc.o -Wl,-rpath-link=3D/mnt/flaire/src/glibc-up=
stream-cvs/libc-build:/mnt/flaire/src/glibc-upstream-cvs/libc-build/math:/m=
nt/flaire/src/glibc-upstream-cvs/libc-build/elf:/mnt/flaire/src/glibc-upstr=
eam-cvs/libc-build/dlfcn:/mnt/flaire/src/glibc-upstream-cvs/libc-build/nss:=
/mnt/flaire/src/glibc-upstream-cvs/libc-build/nis:/mnt/flaire/src/glibc-ups=
tream-cvs/libc-build/rt:/mnt/flaire/src/glibc-upstream-cvs/libc-build/resol=
v:/mnt/flaire/src/glibc-upstream-cvs/libc-build/crypt:/mnt/flaire/src/glibc=
-upstream-cvs/libc-build/linuxthreads /mnt/flaire/src/glibc-upstream-cvs/li=
bc-build/libc.so.6 /mnt/flaire/src/glibc-upstream-cvs/libc-build/libc_nonsh=
ared.a -lgcc `gcc-3.2 --print-file-name=3Dcrtend.o` /mnt/flaire/src/glibc-u=
pstream-cvs/libc-build/csu/crtn.o
/mnt/flaire/src/glibc-upstream-cvs/libc-build/libc.so.6: undefined referenc=
e to `__divdi3_internal'
collect2: ld returned 1 exit status
make[2]: *** [/mnt/flaire/src/glibc-upstream-cvs/libc-build/iconv/iconvconf=
ig] Error 1
make[2]: Leaving directory `/mnt/flaire/src/glibc-upstream-cvs/libc/iconv'
make[1]: *** [iconv/others] Error 2
make[1]: Leaving directory `/mnt/flaire/src/glibc-upstream-cvs/libc'
make: *** [all] Error 2
I have _no_ idea what is going on here, I have to begin digging at:
http://sources.redhat.com/ml/glibc-cvs/2002-q3/msg00325.html (Shows the che=
ckin)
libc/sysdeps/wordsize-32/lldiv.c shows:
24 #ifdef SHARED
25 /* This is an ugly trick. We cause the C code generated for the co=
de
26 in lldiv.c to use __divdi3_internal instead of __divdi3 by defin=
ing
27 an alias on the assembler level. */
28 asm ("__divdi3 =3D __divdi3_internal");
29 #endif
objdump -t /mnt/flaire/src/glibc-upstream-cvs/libc-build/libc.so.6 | grep d=
ivdi3
001173d4 l F .text 00000028 __udivdi3
00000000 *UND* 00000000 __divdi3_internal
It's clearly not there :}
If anyone understands... a hint would be most helpful=20
Cheers,
c.
From grundler@dsl2.external.hp.com Tue Sep 3 04:42:12 2002
From: grundler@dsl2.external.hp.com (Grant Grundler)
Date: Mon, 02 Sep 2002 21:42:12 -0600
Subject: [parisc-linux] iodc call and HPMC: dump driver.
In-Reply-To: Message from Bruno Vidal <bruno_vidal@hpfrcu03.france.hp.com>
of "Mon, 02 Sep 2002 08:12:26 +0200." <3D73014A.15ED96ED@admin.france.hp.com>
References: <3D73014A.15ED96ED@admin.france.hp.com>
Message-ID: <20020903034212.A638A4829@dsl2.external.hp.com>
Bruno Vidal wrote:
> Hi all.
> Do you know a guy who is a guru of iodc calls ?
I'm not expert, but I've mucked with it abit.
> I'm still stuck with this. I think I was really near the
> solution. Now my iodc call create beatifull HPMC.
Which platform are you testing on?
32 or 64-bit kernel?
> Take a look to this call, I was thinking that it
> was all right, but there is still something wrong.
> now i'm able to retrieve hpa,
> I based this on palo code:
>
> ret = real32_call(PAGE0->mem_boot.iodc_io, (unsigned long)PAGE0->mem_boot.hp
> a, DUMPDEV_WRITE,
> PAGE0->mem_boot.spa, __pa(PAGE0->mem_boot.dp.layers), __pa(pdc_result), dev
> addr, __pa(iodc_dbuf), 2048);
Can you dump the values for the call that HPMCs?
I'm not sure what is supposed to be passed as arguments to IODC.
I'm trying to find it in the documentation I have and then I
can verify the values are sane.
Note that all IODC is 32-bit.
And earlier IODC versions don't like byte addresses greater than 2GB.
Not sure when that got fixed but it certainly wasn't on 712
or similar workstations/servers. It wasn't even noticed as a problem
until HP started shipping 4GB disk drives (ie 1997 or so).
later IODC included a "block" interface which use block address
instead of byte address. I'll try to find documentation on this.
> DUMPDEV_WRITE = 1
> static unsigned long pdc_result[32] __attribute__ ((aligned (8)));
> static char __attribute__((aligned(64))) iodc_dbuf[DUMP_PAGE_SZ];
>
> and devaddr=191889408
191889408 == 0xB7000000
If this is the target byte address on the block device, it's too big.
> Disk /dev/sda: 64 heads, 32 sectors, 17366 cylinders
> Units = cylinders of 2048 * 512 bytes
>
> /dev/sda1 * 1 61 62448 f0 Linux/PA-RISC boot
> /dev/sda2 62 183 124928 83 Linux
> /dev/sda3 184 1648 1500160 82 Linux swap
> /dev/sda4 1649 17366 16095232 5 Extended
> /dev/sda5 1649 5554 3999728 83 Linux
> /dev/sda6 5555 9460 3999728 82 Linux swap
> /dev/sda7 9461 13366 3999728 83 Linux
> /dev/sda8 13367 17366 4095984 83 Linux
which of these are you trying to write to?
sda3?
> Do you know someone who is well aware of iodc calls ?
> I want to discuss a bit about this.
hmm...inside HP there are a few people who've mucked with IODC.
Let's see if we can figure it out here first.
thanks,
grant
From grundler@dsl2.external.hp.com Tue Sep 3 05:22:57 2002
From: grundler@dsl2.external.hp.com (Grant Grundler)
Date: Mon, 02 Sep 2002 22:22:57 -0600
Subject: [parisc-linux] iodc call and HPMC: dump driver.
In-Reply-To: Message from Bruno Vidal <bruno_vidal@hpfrcu03.france.hp.com>
of "Mon, 02 Sep 2002 08:12:26 +0200." <3D73014A.15ED96ED@admin.france.hp.com>
References: <3D73014A.15ED96ED@admin.france.hp.com>
Message-ID: <20020903042257.D4E344829@dsl2.external.hp.com>
Bruno Vidal wrote:
> DUMPDEV_WRITE = 1
I've found the right set of constants and argument parameters.
Those are now committed to include/asm-parisc/pdc.h.
I just realized the comments are incomplete...I only
included ARG0-ARG5 - there can be 8 args depending on
the call...hmm...I'll omit and document in the code
where it's used.
thanks,
grant
From grundler@dsl2.external.hp.com Tue Sep 3 05:50:49 2002
From: grundler@dsl2.external.hp.com (Grant Grundler)
Date: Mon, 02 Sep 2002 22:50:49 -0600
Subject: [parisc-linux] iodc call and HPMC: dump driver.
In-Reply-To: Message from Bruno Vidal <bruno_vidal@hpfrcu03.france.hp.com>
of "Mon, 02 Sep 2002 08:12:26 +0200." <3D73014A.15ED96ED@admin.france.hp.com>
References: <3D73014A.15ED96ED@admin.france.hp.com>
Message-ID: <20020903045049.E268F4829@dsl2.external.hp.com>
Bruno Vidal wrote:
> ret = real32_call(PAGE0->mem_boot.iodc_io,
ARG0 (unsigned long)PAGE0->mem_boot.hpa,
ARG1 DUMPDEV_WRITE,
ARG2 PAGE0->mem_boot.spa
ARG3 __pa(PAGE0->mem_boot.dp.layers)
ARG4 __pa(pdc_result)
ARG5 devaddr
ARG6 __pa(iodc_dbuf)
ARG7 2048);
The parameters "look" ok.
> DUMPDEV_WRITE = 1
> static unsigned long pdc_result[32] __attribute__ ((aligned (8)));
> static char __attribute__((aligned(64))) iodc_dbuf[DUMP_PAGE_SZ];
>
> and devaddr=191889408
except the value of this one. I'm pretty sure now it's wrong.
IO ACD, page 520 of 646 (aka 13-48) says:
Description: The argument reqsize specifies the amount of data that the
caller would like to write. It must be a multiple of 2 Kbytes, but
is otherwise unconstrained. The data to write is in memory at the
address specified by memaddr. The value of memaddr must be a multiple
of 64 bytes. The address on the device medium, devaddr, must be 2
Kbyte aligned. If the call returns a nonnegative status, the return
parameter count is the number of bytes actually output; it must be a
multiple of 2 Kbytes. If the call returns a negative status, the
value of count and the data written are HVERSION dependent.
IO ACD, page 491 of 646 (aka 13-19) says:
13.3.8 Data Types
The data types of the standard arguments and return parameters are as follows:
· All signed integers are represented in two's complement (32-bit) format.
· The status value returned by all IODC entry points in GR28 is a signed integer.
· All addresses, which are passed as arguments, or returned as parameters, are 32-bit unsigned integers.
· The data type of ARG0 in all IODC entry points is a 32-bit unsigned integer.
· The data type of ARG1 in all IODC entry points is a 32-bit unsigned integer.
One might assume devaddr is treated as an "unsigned" integer.
But most older IODC are broken and treat it as a signed value.
(ie anything shipped before ~1996-1998)
I wouldn't trust newer boxes to get it right either.
Once you get ENTRY_IO_BOOT_OUT working, I suggest trying to
use ENTRY_IO_BBLOCK_OUT that's now defined in <asm/pdc.h> first
and if that fails (not implemented), fall back to ENTRY_IO_BOOT_OUT.
hth,
grant
From jsoe0708@tiscali.be Tue Sep 3 06:47:59 2002
From: jsoe0708@tiscali.be (jsoe0708@tiscali.be)
Date: Tue, 3 Sep 2002 07:47:59 +0200
Subject: [parisc-linux] Gcc-3.2 beside gcc-3.0: HOWTO?
In-Reply-To: <20020902164424.GE14634@tausq.org>
Message-ID: <3D3815BD0000AB5F@ocpmta5.be.tiscali.com>
Hi Randolph,
>
>> Oops the 32bits kernel which I obtain, boot well on my b2k but ip connection
>> problem is always there: the system seems to loop somewhere with ssh (heart
>> bit seems life and no more response neither at serial console, neither
>at
>> ssh prompt) and telnet causes an HPMC (bus timeout?)
>
>looking up the iaoq and gr02 values reported in the hpmc in System.map
>would be the first step...
>
Too bad, I forget to mentionned that I just read some HPMC messages on the
LCD display of my b2k and do not get any status dump info on console (which
just stay locked at login prompt). Do you think that kdb works now? (if yes
where can I learn how to get iaoq and gr02 info?)
Thanks a lot,
Joel
From Randolph Chung <tausq@debian.org> Tue Sep 3 08:05:55 2002
From: Randolph Chung <tausq@debian.org> (Randolph Chung)
Date: Tue, 3 Sep 2002 00:05:55 -0700
Subject: [parisc-linux] Gcc-3.2 beside gcc-3.0: HOWTO?
In-Reply-To: <3D3815BD0000AB5F@ocpmta5.be.tiscali.com>
References: <20020902164424.GE14634@tausq.org> <3D3815BD0000AB5F@ocpmta5.be.tiscali.com>
Message-ID: <20020903070555.GR25710@tausq.org>
> Too bad, I forget to mentionned that I just read some HPMC messages on the
> LCD display of my b2k and do not get any status dump info on console (which
> just stay locked at login prompt). Do you think that kdb works now? (if yes
> where can I learn how to get iaoq and gr02 info?)
at the firmware prompt, 'ser pim' will read the hpmc info that's stored
in pim.
kdb should work, although i haven't tried recently.
randolph
From rhirst@linuxcare.com Tue Sep 3 10:12:45 2002
From: rhirst@linuxcare.com (Richard Hirst)
Date: Tue, 3 Sep 2002 10:12:45 +0100
Subject: [parisc-linux] Network Problems
In-Reply-To: <200209021138.AA3341287994@mail.centraltx.com>
References: <200209021138.AA3341287994@mail.centraltx.com>
Message-ID: <20020903091245.GA21440@sleepie.demon.co.uk>
Sounds like third bullet point on
<http://www.parisc-linux.org/release-0.9/errata-092.html>. Is this an
old install (or a recent one from an old ISO)?
Richard
On Mon, Sep 02, 2002 at 11:38:20AM -0500, marc wrote:
> Anyone have any ideas why I get innundated with these messages on
> startup and have to do a control-c to get past this part and continue booting?
>
> Configuring network interfaces: eth0: Transceiver problem.
> ip_local_deliver: bad loopback skb: PRE_ROUTING LOCAL_IN
> skb: pf=2 (unowned) dev=lo len=328
> PROTO=17 0.0.0.0:68 255.255.255.255:67 L=328 S=0x10 I=0 F=0x0000 T=16
> ip_local_deliver: bad loopback skb: PRE_ROUTING LOCAL_IN
> skb: pf=2 (unowned) dev=lo len=328
> PROTO=17 0.0.0.0:68 255.255.255.255:67 L=328 S=0x10 I=0 F=0x0000 T=16
> ip_local_deliver: bad loopback skb: PRE_ROUTING LOCAL_IN
> skb: pf=2 (unowned) dev=lo len=328
> PROTO=17 0.0.0.0:68 255.255.255.255:67 L=328 S=0x10 I=0 F=0x0000 T=16
> ip_local_deliver: bad loopback skb: PRE_ROUTING LOCAL_IN
> skb: pf=2 (unowned) dev=lo len=328
> PROTO=17 0.0.0.0:68 255.255.255.255:67 L=328 S=0x10 I=0 F=0x0000 T=16
> ip_local_deliver: bad loopback skb: PRE_ROUTING LOCAL_IN
> skb: pf=2 (unowned) dev=lo len=328
> PROTO=17 0.0.0.0:68 255.255.255.255:67 L=328 S=0x10 I=0 F=0x0000 T=16
>
> ip_local_deliver: bad loopback skb: PRE_ROUTING LOCAL_IN
> skb: pf=2 (unowned) dev=lo len=328
> PROTO=17 0.0.0.0:68 255.255.255.255:67 L=328 S=0x10 I=0 F=0x0000 T=16
>
> _______________________________________________
> parisc-linux mailing list
> parisc-linux@lists.parisc-linux.org
> http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
From varenet@esiee.fr Tue Sep 3 11:51:43 2002
From: varenet@esiee.fr (Thibaut VARENE)
Date: Tue, 3 Sep 2002 12:51:43 +0200
Subject: [parisc-linux] Re: PALO-text
In-Reply-To: <000601c25325$f3bcb080$ad3c179f@tol.ses.alcatel.es>
References: <000601c25325$f3bcb080$ad3c179f@tol.ses.alcatel.es>
Message-ID: <20020903125143.5dd1e297.varenet@esiee.fr>
On Tue, 3 Sep 2002 10:43:18 +0200
"Jorge GOMEZ CABELLO" <jorge.gomez@sanmina-sci.com> wrote:
> Dear Puffin,
>
> We are trying to install Debian 3.0 on our HP B2000/785 and it is impossible to recognize the usb keyboard. is there a special commando to introduced in the command line of the palo 1.0 ?
- This reply has been CC'd to the parisc-linux mailing list -
Hi Jorge,
If I remember correctly, the USB support is not enabled by default in the install kernel for Debian 3.0, and B2000 does use a USB keyboard.
We had such a problem here, and there is a solution: boot and install the box using the following lifimage:
http://pateam.esiee.fr/cd-images/lifimages/lifimage-2.4.18-pa46-USBSTI64-20020704.gz
This one has support for USB in both 32/64bit kernels, and what's more, STI console is supported in 64bit kernel. This will allow you to install the box directly with a 64bit kernel.
We may build a more recent lifimage with such USB/STI support soon.
Maybe we can also consider adding at least USB support to the default kernel configuration ? Richard, any comment ? :)
Greetings,
Thibaut VARENE
The PA/Linux ESIEE Team
http://pateam.esiee.fr/
From jsoe0708@tiscali.be Tue Sep 3 14:14:39 2002
From: jsoe0708@tiscali.be (jsoe0708@tiscali.be)
Date: Tue, 3 Sep 2002 15:14:39 +0200
Subject: [parisc-linux] Re: PALO-text
In-Reply-To: <20020903125143.5dd1e297.varenet@esiee.fr>
Message-ID: <3D3815BD0000AF81@ocpmta5.be.tiscali.com>
Hello Thibaut,
>This one has support for USB in both 32/64bit kernels, and what's more,
STI
>console is supported in 64bit kernel.
May be an anoying question: is that STI console is supported on B2K (buildin
controler HPA4982A)
Thanks in advance for info,
Joel
From jsoe0708@tiscali.be Tue Sep 3 16:33:14 2002
From: jsoe0708@tiscali.be (jsoe0708@tiscali.be)
Date: Tue, 3 Sep 2002 17:33:14 +0200
Subject: [parisc-linux] Gcc-3.2 beside gcc-3.0: HOWTO?
In-Reply-To: <20020903070555.GR25710@tausq.org>
Message-ID: <3D3815BD0000B0C0@ocpmta5.be.tiscali.com>
--=========3D3815BD0000B0C0/mail.tiscali.be
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Hello Randolph,
I need additional help.
>
>> Too bad, I forget to mentionned that I just read some HPMC messages on
>the
>> LCD display of my b2k and do not get any status dump info on console (which
>> just stay locked at login prompt). Do you think that kdb works now? (if
>yes
>> where can I learn how to get iaoq and gr02 info?)
>
>at the firmware prompt, 'ser pim' will read the hpmc info that's stored
>in pim.
Here is the pim I get (I do a clearpim before to be sure):
PROCESSOR PIM INFORMATION
----------------- Processor 0 HPMC Information ------------------
Timestamp =
Tue Sep 3 14:26:13 GMT 2002 (20:02:09:03:14:26:13)
HPMC Chassis Codes = 2cbf0 2500b 2cbf4 2cbfc
General Registers 0 - 31
00-03 0000000000000000 00000000103b7244 0000000010108064 00000000207f8000
04-07 00000000102b6800 00000000207fc940 00000000207f8000 0000000000000008
08-11 00000000107e2e94 00000000103b6e40 0000000000000400 00000000f0408cd8
12-15 00000000f0407ef0 000000001f1f86d0 00000000000020f8 0000000000035cec
16-19 00000000107fcdc0 0000000000017800 0000000000029494 ffffffffffffffff
20-23 000000000000000e 0000000000000000 0000000000004000 00000000102fd810
24-27 0000000000002a4f 00000000107fcdc0 000000000000000f 00000000102ea010
28-31 0000000000000030 0000000011430100 0000000011430340 00000000103bb010
<Press any key to continue (q to quit)>
Control Registers 0 - 31
00-03 0000000000000000 0000000000000000 0000000000000000 0000000000000000
04-07 0000000000000000 0000000000000000 0000000000000000 0000000000000000
08-11 0000000000000634 0000000000000000 00000000000000c0 0000000000000017
12-15 0000000000000000 0000000000000000 0000000000107000 0000000000000000
16-19 0000007be95ffc60 0000000000000000 0000000010108638 000000000fa11288
20-23 0000000010240224 0000000048030104 000000000004000e 0000000080000000
24-27 0000000000305000 0000000000305000 0000000000044021 00000000f0412000
28-31 0000000055555555 0000000055555555 000000001f1f8000 00000000103a8000
Space Registers 0 - 7
00-03 00000000 0000031a 00000000 0000031a
04-07 00000000 00000000 00000000 00000000
<Press any key to continue (q to quit)>
IIA Space = 0x0000000000000000
IIA Offset = 0x000000001010863c
Check Type = 0x20000000
CPU State = 0x9e000004
Cache Check = 0x00000000
TLB Check = 0x00000000
Bus Check = 0x003010bb
Assists Check = 0x00000000
Assist State = 0x00000000
Path Info = 0x00031800
System Responder Address = 0xfffffffffed10200
System Requestor Address = 0xfffffffffffa0000
Floating-Point Registers 0 - 31
00-03 0000001f00000000 0000000000000000 0000000000000000 0000000000000000
04-07 00004000102fe810 000000011014cff4 f0000000102fe810 1037a010102de000
08-11 1030402000000002 0000000200000002 00000000102fd810 1039f810102fa810
12-15 103a00001079c000 0000000200000002 000000001039e264 102fa810103a0000
16-19 102fd8100000000b 103b6e4b102fdb28 0000000f103b6810 f00000000000000f
20-23 000000011039e000 f00000001013c70c 0000000000000008 0000000000000000
24-27 0000000a1fff90a0 0000999900000000 1079c00000000001 00001fb6102b6000
28-31 106b46a0102b61a8 1079c0001013e268 102fa810103a0000 100d4000100d45d0
<Press any key to continue (q to quit)>
'9000/785 B,C,J Workstation Unarchitected (per-CPU)', rev 1, 140 bytes:
Check Summary = 0xcb81041000000000
Available Memory = 0x0000000010000000
CPU Diagnose Register 2 = 0x0301000000000004
CPU Status Register 0 = 0x2420c20000000000
CPU Status Register 1 = 0x8080000000000000
SADD LOG = 0x000000004e657874
Read Short LOG = 0xc1af00fffee00f28
ERROR_STATUS = 0x0000000000000010
MEM_ADDR = 0x000001ff3fffffff
MEM_SYND = 0x0000000000000000
MEM_ADDR_CORR = 0x000001ff3fffffff
MEM_SYND_CORR = 0x0000000000000000
RUN_DATA_HIGH = 0xc1bff0fffed08040
RUN_DATA_LOW = 0xc1bff0fffed08040
RUN_CTRL = 0x0000021c00001418
RUN_ADDR = 0xc1bff0fffed08040
System Responder Path = 0x00ffffffffffffff
HPMC PIM Analysis Information:
Timestamp =
Tue Sep 3 14:26:13 GMT 2002 (20:02:09:03:14:26:13)
'9000/785 B,C,J Workstation HPMC PIM Analysis (per-CPU)', rev 0, 1304 bytes:
A Data Miss Timeout occurred while CPU 0 was
requesting information.
Memory/IO Controller Error Analysis Information:
The Memory/IO Controller only observed the Broadcast Error. It did not log
any additional information about the HPMC.
Memory Error Log Information:
Timestamp =
Tue Sep 3 14:26:13 GMT 2002 (20:02:09:03:14:26:13)
'9000/785 B,C,J Workstation Memory Error Log', rev 0, 64 bytes:
No memory errors logged
I/O Module Error Log Information:
Timestamp =
Tue Sep 3 14:26:13 GMT 2002 (20:02:09:03:14:26:13)
'9000/785 B,C,J Workstation IO Error Log', rev 0, 228 bytes:
Rope Word1 Word2 Word3
------ ------------ ------------
0 0x00000000 0x0e0cc009 0x00000000fed30048
1 0x00000000 0x1e0cc009 0x00000000fed32048
2 ---------- 0x2e0cc009 ------------------
3 ---------- 0x3e0cc009 ------------------
4 ---------- 0x4e0cc009 ------------------
5 ---------- 0x5e0cc009 ------------------
6 ---------- 0x6e0cc009 ------------------
7 ---------- 0x7e0cc009 ------------------
Service Menu: Enter command >
Well I presume that gr02 is 10108064 (from:
General Registers 0 - 31
00-03 0000000000000000 00000000103b7244 0000000010108064 00000000207f8000)
But where is iaoq (I do not found in linux/Documentation/parisc)?
here is what I got: grep 101080 /boot/System.map-2.4.19-pa9
10108000 T syscall_exit_rfi
10108064 t intr_return
10108078 t intr_check_resched
10108084 t intr_check_sig
10108090 t intr_restore
>
>kdb should work, although i haven't tried recently.
>
I will try later if required.
Thanks in advance for additional help,
Joel
PS: I try to attached a complete log of the crash sequence b2k.crash.doc
--=========3D3815BD0000B0C0/mail.tiscali.be
Content-Type: application/msword
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="b2k.crash.doc"
ClBST0NFU1NPUiBQSU0gSU5GT1JNQVRJT04KCi0tLS0tLS0tLS0tLS0tLS0tICBQcm9jZXNzb3Ig
MCBIUE1DIEluZm9ybWF0aW9uIC0tLS0tLS0tLS0tLS0tLS0tLQoKICAgTm8gdmFsaWQgdGltZXN0
YW1wCgpIUE1DIENoYXNzaXMgQ29kZXMgPSBObyBjaGFzc2lzIGNvZGVzIGxvZ2dlZAoKR2VuZXJh
bCBSZWdpc3RlcnMgMCAtIDMxCjAwLTAzICAgMDAwMDAwMDAwMDAwMDAwMCAgMDAwMDAwMDAwMDAw
MDAwMCAgMDAwMDAwMDAwMDAwMDAwMCAgMDAwMDAwMDAwMDAwMDAwMAowNC0wNyAgIDAwMDAwMDAw
MDAwMDAwMDAgIDAwMDAwMDAwMDAwMDAwMDAgIDAwMDAwMDAwMDAwMDAwMDAgIDAwMDAwMDAwMDAw
MDAwMDAKMDgtMTEgICAwMDAwMDAwMDAwMDAwMDAwICAwMDAwMDAwMDAwMDAwMDAwICAwMDAwMDAw
MDAwMDAwMDAwICAwMDAwMDAwMDAwMDAwMDAwCjEyLTE1ICAgMDAwMDAwMDAwMDAwMDAwMCAgMDAw
MDAwMDAwMDAwMDAwMCAgMDAwMDAwMDAwMDAwMDAwMCAgMDAwMDAwMDAwMDAwMDAwMAoxNi0xOSAg
IDAwMDAwMDAwMDAwMDAwMDAgIDAwMDAwMDAwMDAwMDAwMDAgIDAwMDAwMDAwMDAwMDAwMDAgIDAw
MDAwMDAwMDAwMDAwMDAKMjAtMjMgICAwMDAwMDAwMDAwMDAwMDAwICAwMDAwMDAwMDAwMDAwMDAw
ICAwMDAwMDAwMDAwMDAwMDAwICAwMDAwMDAwMDAwMDAwMDAwCjI0LTI3ICAgMDAwMDAwMDAwMDAw
MDAwMCAgMDAwMDAwMDAwMDAwMDAwMCAgMDAwMDAwMDAwMDAwMDAwMCAgMDAwMDAwMDAwMDAwMDAw
MAoyOC0zMSAgIDAwMDAwMDAwMDAwMDAwMDAgIDAwMDAwMDAwMDAwMDAwMDAgIDAwMDAwMDAwMDAw
MDAwMDAgIDAwMDAwMDAwMDAwMDAwMDAKCjxQcmVzcyBhbnkga2V5IHRvIGNvbnRpbnVlIChxIHRv
IHF1aXQpPiAKCkNvbnRyb2wgUmVnaXN0ZXJzIDAgLSAzMQowMC0wMyAgIDAwMDAwMDAwMDAwMDAw
MDAgIDAwMDAwMDAwMDAwMDAwMDAgIDAwMDAwMDAwMDAwMDAwMDAgIDAwMDAwMDAwMDAwMDAwMDAK
MDQtMDcgICAwMDAwMDAwMDAwMDAwMDAwICAwMDAwMDAwMDAwMDAwMDAwICAwMDAwMDAwMDAwMDAw
MDAwICAwMDAwMDAwMDAwMDAwMDAwCjA4LTExICAgMDAwMDAwMDAwMDAwMDAwMCAgMDAwMDAwMDAw
MDAwMDAwMCAgMDAwMDAwMDAwMDAwMDAwMCAgMDAwMDAwMDAwMDAwMDAwMAoxMi0xNSAgIDAwMDAw
MDAwMDAwMDAwMDAgIDAwMDAwMDAwMDAwMDAwMDAgIDAwMDAwMDAwMDAwMDAwMDAgIDAwMDAwMDAw
MDAwMDAwMDAKMTYtMTkgICAwMDAwMDAwMDAwMDAwMDAwICAwMDAwMDAwMDAwMDAwMDAwICAwMDAw
MDAwMDAwMDAwMDAwICAwMDAwMDAwMDAwMDAwMDAwCjIwLTIzICAgMDAwMDAwMDAwMDAwMDAwMCAg
MDAwMDAwMDAwMDAwMDAwMCAgMDAwMDAwMDAwMDAwMDAwMCAgMDAwMDAwMDAwMDAwMDAwMAoyNC0y
NyAgIDAwMDAwMDAwMDAwMDAwMDAgIDAwMDAwMDAwMDAwMDAwMDAgIDAwMDAwMDAwMDAwMDAwMDAg
IDAwMDAwMDAwMDAwMDAwMDAKMjgtMzEgICAwMDAwMDAwMDAwMDAwMDAwICAwMDAwMDAwMDAwMDAw
MDAwICAwMDAwMDAwMDAwMDAwMDAwICAwMDAwMDAwMDAwMDAwMDAwClNwYWNlIFJlZ2lzdGVycyAw
IC0gNwoKMDAtMDMgICAwMDAwMDAwMCAgICAgICAgICAwMDAwMDAwMCAgICAgICAgICAwMDAwMDAw
MCAgICAgICAgICAwMDAwMDAwMAowNC0wNyAgIDAwMDAwMDAwICAgICAgICAgIDAwMDAwMDAwICAg
ICAgICAgIDAwMDAwMDAwICAgICAgICAgIDAwMDAwMDAwCgo8UHJlc3MgYW55IGtleSB0byBjb250
aW51ZSAocSB0byBxdWl0KT4gCgpJSUEgU3BhY2UgICAgICAgICAgICAgICAgICAgID0gMHgwMDAw
MDAwMDAwMDAwMDAwCklJQSBPZmZzZXQgICAgICAgICAgICAgICAgICAgPSAweDAwMDAwMDAwMDAw
MDAwMDAKQ2hlY2sgVHlwZSAgICAgICAgICAgICAgICAgICA9IDB4MDAwMDAwMDAKQ1BVIFN0YXRl
ICAgICAgICAgICAgICAgICAgICA9IDB4MDAwMDAwMDAKQ2FjaGUgQ2hlY2sgICAgICAgICAgICAg
ICAgICA9IDB4MDAwMDAwMDAKVExCIENoZWNrICAgICAgICAgICAgICAgICAgICA9IDB4MDAwMDAw
MDAKQnVzIENoZWNrICAgICAgICAgICAgICAgICAgICA9IDB4MDAwMDAwMDAKQXNzaXN0cyBDaGVj
ayAgICAgICAgICAgICAgICA9IDB4MDAwMDAwMDAKQXNzaXN0IFN0YXRlICAgICAgICAgICAgICAg
ICA9IDB4MDAwMDAwMDAKUGF0aCBJbmZvICAgICAgICAgICAgICAgICAgICA9IDB4MDAwMDAwMDAK
U3lzdGVtIFJlc3BvbmRlciBBZGRyZXNzICAgICA9IDB4MDAwMDAwMDAwMDAwMDAwMApTeXN0ZW0g
UmVxdWVzdG9yIEFkZHJlc3MgICAgID0gMHgwMDAwMDAwMDAwMDAwMDAwCgpGbG9hdGluZy1Qb2lu
dCBSZWdpc3RlcnMgMCAtIDMxCjAwLTAzICAgMDAwMDAwMDAwMDAwMDAwMCAgMDAwMDAwMDAwMDAw
MDAwMCAgMDAwMDAwMDAwMDAwMDAwMCAgMDAwMDAwMDAwMDAwMDAwMAowNC0wNyAgIDAwMDAwMDAw
MDAwMDAwMDAgIDAwMDAwMDAwMDAwMDAwMDAgIDAwMDAwMDAwMDAwMDAwMDAgIDAwMDAwMDAwMDAw
MDAwMDAKMDgtMTEgICAwMDAwMDAwMDAwMDAwMDAwICAwMDAwMDAwMDAwMDAwMDAwICAwMDAwMDAw
MDAwMDAwMDAwICAwMDAwMDAwMDAwMDAwMDAwCjEyLTE1ICAgMDAwMDAwMDAwMDAwMDAwMCAgMDAw
MDAwMDAwMDAwMDAwMCAgMDAwMDAwMDAwMDAwMDAwMCAgMDAwMDAwMDAwMDAwMDAwMAoxNi0xOSAg
IDAwMDAwMDAwMDAwMDAwMDAgIDAwMDAwMDAwMDAwMDAwMDAgIDAwMDAwMDAwMDAwMDAwMDAgIDAw
MDAwMDAwMDAwMDAwMDAKMjAtMjMgICAwMDAwMDAwMDAwMDAwMDAwICAwMDAwMDAwMDAwMDAwMDAw
ICAwMDAwMDAwMDAwMDAwMDAwICAwMDAwMDAwMDAwMDAwMDAwCjI0LTI3ICAgMDAwMDAwMDAwMDAw
MDAwMCAgMDAwMDAwMDAwMDAwMDAwMCAgMDAwMDAwMDAwMDAwMDAwMCAgMDAwMDAwMDAwMDAwMDAw
MAoyOC0zMSAgIDAwMDAwMDAwMDAwMDAwMDAgIDAwMDAwMDAwMDAwMDAwMDAgIDAwMDAwMDAwMDAw
MDAwMDAgIDAwMDAwMDAwMDAwMDAwMDAKCjxQcmVzcyBhbnkga2V5IHRvIGNvbnRpbnVlIChxIHRv
IHF1aXQpPiAKCkNoZWNrIFN1bW1hcnkgICAgICAgICAgICAgICAgPSAweDAwMDAwMDAwMDAwMDAw
MDAKQXZhaWxhYmxlIE1lbW9yeSAgICAgICAgICAgICA9IDB4MDAwMDAwMDAwMDAwMDAw
MApDUFUgRGlhZ25vc2UgUmVnaXN0ZXIgMiAgICAgID0gMHgwMDAwMDAwMDAwMDAwMDAwCkNQVSBT
dGF0dXMgUmVnaXN0ZXIgMCAgICAgICAgPSAweDAwMDAwMDAwMDAwMDAwMDAKQ1BVIFN0YXR1cyBS
ZWdpc3RlciAxICAgICAgICA9IDB4MDAwMDAwMDAwMDAwMDAwMApTQUREIExPRyAgICAgICAgICAg
ICAgICAgICAgID0gMHgwMDAwMDAwMDAwMDAwMDAwClJlYWQgU2hvcnQgTE9HICAgICAgICAgICAg
ICAgPSAweDAwMDAwMDAwMDAwMDAwMDAKRVJST1JfU1RBVFVTICAgICAgICAgICAgICAgICA9IDB4
MDAwMDAwMDAwMDAwMDAwMApNRU1fQUREUiAgICAgICAgICAgICAgICAgICAgID0gMHgwMDAwMDAw
MDAwMDAwMDAwCk1FTV9TWU5EICAgICAgICAgICAgICAgICAgICAgPSAweDAwMDAwMDAwMDAwMDAw
MDAKTUVNX0FERFJfQ09SUiAgICAgICAgICAgICAgICA9IDB4MDAwMDAwMDAwMDAwMDAwMApNRU1f
U1lORF9DT1JSICAgICAgICAgICAgICAgID0gMHgwMDAwMDAwMDAwMDAwMDAwClJVTl9EQVRBX0hJ
R0ggICAgICAgICAgICAgICAgPSAweDAwMDAwMDAwMDAwMDAwMDAKUlVOX0RBVEFfTE9XICAgICAg
ICAgICAgICAgICA9IDB4MDAwMDAwMDAwMDAwMDAwMApSVU5fQ1RSTCAgICAgICAgICAgICAgICAg
ICAgID0gMHgwMDAwMDAwMDAwMDAwMDAwClJVTl9BRERSICAgICAgICAgICAgICAgICAgICAgPSAw
eDAwMDAwMDAwMDAwMDAwMDAKU3lzdGVtIFJlc3BvbmRlciBQYXRoICAgICAgICA9IDB4MDAwMDAw
MDAwMDAwMDAwMAoKCkhQTUMgUElNIEFuYWx5c2lzIEluZm9ybWF0aW9uOgoKICAgTm8gdmFsaWQg
dGltZXN0YW1wCgoKCk1lbW9yeS9JTyBDb250cm9sbGVyIEVycm9yIEFuYWx5c2lzIEluZm9ybWF0
aW9uOgoKCjxQcmVzcyBhbnkga2V5IHRvIGNvbnRpbnVlIChxIHRvIHF1aXQpPiAKCi0tLS0tLS0t
LS0tLS0tLS0tICBQcm9jZXNzb3IgMCBMUE1DIEluZm9ybWF0aW9uIC0tLS0tLS0tLS0tLS0tLS0t
LQoKQ2hlY2sgVHlwZSAgICAgICAgICAgICAgICAgICA9IDB4MDAwMDAwMDAKSS9EIENhY2hlIFBh
cml0eSBJbmZvICAgICAgICA9IDB4MDAwMDAwMDAKQ2FjaGUgQ2hlY2sgICAgICAgICAgICAgICAg
ICA9IDB4MDAwMDAwMDAKVExCIENoZWNrICAgICAgICAgICAgICAgICAgICA9IDB4MDAwMDAwMDAK
QnVzIENoZWNrICAgICAgICAgICAgICAgICAgICA9IDB4MDAwMDAwMDAKQXNzaXN0cyBDaGVjayAg
ICAgICAgICAgICAgICA9IDB4MDAwMDAwMDAKQXNzaXN0IFN0YXRlICAgICAgICAgICAgICAgICA9
IDB4MDAwMDAwMDAKUGF0aCBJbmZvICAgICAgICAgICAgICAgICAgICA9IDB4MDAwMDAwMDAKU3lz
dGVtIFJlc3BvbmRlciBBZGRyZXNzICAgICA9IDB4MDAwMDAwMDAwMDAwMDAwMApTeXN0ZW0gUmVx
dWVzdG9yIEFkZHJlc3MgICAgID0gMHgwMDAwMDAwMDAwMDAwMDAwCgoKLS0tLS0tLS0tLS0tLS0t
LS0gIFByb2Nlc3NvciAwIFRPQyBJbmZvcm1hdGlvbiAtLS0tLS0tLS0tLS0tLS0tLS0tCgpHZW5l
cmFsIFJlZ2lzdGVycyAwIC0gMzEKMDAtMDMgICAwMDAwMDAwMDAwMDAwMDAwICAwMDAwMDAwMDAw
MDAwMDAwICAwMDAwMDAwMDAwMDAwMDAwICAwMDAwMDAwMDAwMDAwMDAwCjA0LTA3ICAgMDAwMDAw
MDAwMDAwMDAwMCAgMDAwMDAwMDAwMDAwMDAwMCAgMDAwMDAwMDAwMDAwMDAwMCAgMDAwMDAwMDAw
MDAwMDAwMAowOC0xMSAgIDAwMDAwMDAwMDAwMDAwMDAgIDAwMDAwMDAwMDAwMDAwMDAgIDAwMDAw
MDAwMDAwMDAwMDAgIDAwMDAwMDAwMDAwMDAwMDAKMTItMTUgICAwMDAwMDAwMDAwMDAwMDAwICAw
MDAwMDAwMDAwMDAwMDAwICAwMDAwMDAwMDAwMDAwMDAwICAwMDAwMDAwMDAwMDAwMDAwCjE2LTE5
ICAgMDAwMDAwMDAwMDAwMDAwMCAgMDAwMDAwMDAwMDAwMDAwMCAgMDAwMDAwMDAwMDAwMDAwMCAg
MDAwMDAwMDAwMDAwMDAwMAoyMC0yMyAgIDAwMDAwMDAwMDAwMDAwMDAgIDAwMDAwMDAwMDAwMDAw
MDAgIDAwMDAwMDAwMDAwMDAwMDAgIDAwMDAwMDAwMDAwMDAwMDAKMjQtMjcgICAwMDAwMDAwMDAw
MDAwMDAwICAwMDAwMDAwMDAwMDAwMDAwICAwMDAwMDAwMDAwMDAwMDAwICAwMDAwMDAwMDAwMDAw
MDAwCjI4LTMxICAgMDAwMDAwMDAwMDAwMDAwMCAgMDAwMDAwMDAwMDAwMDAwMCAgMDAwMDAwMDAw
MDAwMDAwMCAgMDAwMDAwMDAwMDAwMDAwMAoKPFByZXNzIGFueSBrZXkgdG8gY29udGludWUgKHEg
dG8gcXVpdCk+IAoKQ29udHJvbCBSZWdpc3RlcnMgMCAtIDMxCjAwLTAzICAgMDAwMDAwMDAwMDAw
MDAwMCAgMDAwMDAwMDAwMDAwMDAwMCAgMDAwMDAwMDAwMDAwMDAwMCAgMDAwMDAwMDAwMDAwMDAw
MAowNC0wNyAgIDAwMDAwMDAwMDAwMDAwMDAgIDAwMDAwMDAwMDAwMDAwMDAgIDAwMDAwMDAwMDAw
MDAwMDAgIDAwMDAwMDAwMDAwMDAwMDAKMDgtMTEgICAwMDAwMDAwMDAwMDAwMDAwICAwMDAwMDAw
MDAwMDAwMDAwICAwMDAwMDAwMDAwMDAwMDAwICAwMDAwMDAwMDAwMDAwMDAwCjEyLTE1ICAgMDAw
MDAwMDAwMDAwMDAwMCAgMDAwMDAwMDAwMDAwMDAwMCAgMDAwMDAwMDAwMDAwMDAwMCAgMDAwMDAw
MDAwMDAwMDAwMAoxNi0xOSAgIDAwMDAwMDAwMDAwMDAwMDAgIDAwMDAwMDAwMDAwMDAwMDAgIDAw
MDAwMDAwMDAwMDAwMDAgIDAwMDAwMDAwMDAwMDAwMDAKMjAtMjMgICAwMDAwMDAwMDAwMDAwMDAw
ICAwMDAwMDAwMDAwMDAwMDAwICAwMDAwMDAwMDAwMDAwMDAwICAwMDAwMDAwMDAwMDAwMDAwCjI0
LTI3ICAgMDAwMDAwMDAwMDAwMDAwMCAgMDAwMDAwMDAwMDAwMDAwMCAgMDAwMDAwMDAwMDAwMDAw
MCAgMDAwMDAwMDAwMDAwMDAwMAoyOC0zMSAgIDAwMDAwMDAwMDAwMDAwMDAgIDAwMDAwMDAwMDAw
MDAwMDAgIDAwMDAwMDAwMDAwMDAwMDAgIDAwMDAwMDAwMDAwMDAwMDAKU3BhY2UgUmVnaXN0ZXJz
IDAgLSA3CgowMC0wMyAgIDAwMDAwMDAwICAgICAgICAgIDAwMDAwMDAwICAgICAgICAgIDAwMDAw
MDAwICAgICAgICAgIDAwMDAwMDAwCjA0LTA3ICAgMDAwMDAwMDAgICAgICAgICAgMDAwMDAwMDAg
ICAgICAgICAgMDAwMDAwMDAgICAgICAgICAgMDAwMDAwMDAKCklJQSBTcGFjZSAgICAgICAgICAg
ICAgICAgICAgPSAweDAwMDAwMDAwMDAwMDAwMDAKSUlBIE9mZnNldCAgICAgICAgICAg
ICAgICAgICA9IDB4MDAwMDAwMDAwMDAwMDAwMApDUFUgU3RhdGUgICAgICAgICAgICAgICAgICAg
ID0gMHgwMDAwMDAwMAoKCjxQcmVzcyBhbnkga2V5IHRvIGNvbnRpbnVlIChxIHRvIHF1aXQpPiAK
Ck1lbW9yeSBFcnJvciBMb2cgSW5mb3JtYXRpb246CgogICBObyB2YWxpZCB0aW1lc3RhbXAKCiAg
IE5vIG1lbW9yeSBlcnJvcnMgbG9nZ2VkCgoKSS9PIE1vZHVsZSBFcnJvciBMb2cgSW5mb3JtYXRp
b246CgogICBObyB2YWxpZCB0aW1lc3RhbXAKCiAgIE5vIEkvTyBtb2R1bGUgZXJyb3JzIGxvZ2dl
ZAoKU2VydmljZSBNZW51OiBFbnRlciBjb21tYW5kID4gbWEKCi0tLS0tIE1haW4gTWVudSAtLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
CgogICAgICBDb21tYW5kICAgICAgICAgICAgICAgICAgICAgICAgICAgRGVzY3JpcHRpb24KICAg
ICAgLS0tLS0tLSAgICAgICAgICAgICAgICAgICAgICAgICAgIC0tLS0tLS0tLS0tCiAgICAgIEJP
b3QgW1BSSXxBTFR8PHBhdGg+XSAgICAgICAgICAgICBCb290IGZyb20gc3BlY2lmaWVkIHBhdGgK
ICAgICAgUEF0aCBbUFJJfEFMVHxDT058S0VZIFs8cGF0aD5dXSAgIERpc3BsYXkgb3IgbW9kaWZ5
IGEgcGF0aAogICAgICBTRUFyY2ggW0RJc3BsYXl8W1tJUExdIFs8cGF0aD5dXV0gU2VhcmNoIGZv
ciBib290IGRldmljZXMKCiAgICAgIENPbmZpZ3VyYXRpb24gWzxjb21tYW5kPl0gICAgICAgICBB
Y2Nlc3MgQ29uZmlndXJhdGlvbiBtZW51L2NvbW1hbmRzCiAgICAgIElOZm9ybWF0aW9uIFs8Y29t
bWFuZD5dICAgICAgICAgICBBY2Nlc3MgSW5mb3JtYXRpb24gbWVudS9jb21tYW5kcwogICAgICBT
RVJ2aWNlIFs8Y29tbWFuZD5dICAgICAgICAgICAgICAgQWNjZXNzIFNlcnZpY2UgbWVudS9jb21t
YW5kcwoKICAgICAgRElzcGxheSAgICAgICAgICAgICAgICAgICAgICAgICAgIFJlZGlzcGxheSB0
aGUgY3VycmVudCBtZW51CiAgICAgIEhFbHAgWzxtZW51Pnw8Y29tbWFuZD5dICAgICAgICAgICBE
aXNwbGF5IGhlbHAgZm9yIG1lbnUgb3IgY29tbWFuZAogICAgICBSRVNFVCAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgUmVzdGFydCB0aGUgc3lzdGVtCi0tLS0tCk1haW4gTWVudTogRW50ZXIg
Y29tbWFuZCA+IGJvIGFsdApJbnRlcmFjdCB3aXRoIElQTCAoWSwgTiwgUSk/PiB5CgpCb290aW5n
Li4uIApCb290IElPIERlcGVuZGVudCBDb2RlIChJT0RDKSByZXZpc2lvbiAwCgoKSEFSRCBCb290
ZWQuCnBhbG8gaXBsIDEuMSByb290QGMzayBUdWUgQXVnICA2IDA5OjM5OjUxIE1EVCAyMDAyCklu
Zm9ybWF0aW9uOiBCb290IGRldmljZSBjYW4ndCBzZWVrIHBhc3QgMkdiIChpZ25vcmUgbmV4dCBl
cnJvcikuYnl0ZWlvX3JlYWQ6IHNlZWtyZWFkKCkgcmV0dXJuZWQgLTEgZXhwZWN0ZWQgMjA0OAoK
UGFydGl0aW9uIFN0YXJ0KE1CKSBFbmQoTUIpIElkIFR5cGUKMSAgICAgICAgICAgICAgIDEgICAg
ICA2MSAgIGYwIFBhbG8KMiAgICAgICAgICAgICAgNjIgICAgIDMwNiAgIDgyIHN3YXAKMyAgICAg
ICAgICAgICAzMDcgICAgIDM2NyAgIDgzIGV4dDIKNSAgICAgICAgICAgICAzNjggICAgMTk1MyAg
IDgzIGV4dDIKNiAgICAgICAgICAgIDE5NTQgICAgMjE5NyAgIDgzIGV4dDIKClBBTE8oRjApIHBh
cnRpdGlvbiBjb250YWluczoKICAgIDAvdm1saW51eDMyIDMzMjQ5OTMgYnl0ZXMgQCAweDQ0MDAw
CgpJbmZvcm1hdGlvbjogTm8gY29uc29sZSBzcGVjaWZpZWQgb24ga2VybmVsIGNvbW1hbmQgbGlu
ZS4gVGhpcyBpcyBub3JtYWwuClBBTE8gd2lsbCBjaG9vc2UgdGhlIGNvbnNvbGUgY3VycmVudGx5
IHVzZWQgYnkgZmlybXdhcmUgKHNlcmlhbCkuQ3VycmVudCBjb21tYW5kIGxpbmU6CjMvdm1saW51
eC0yLjQuMTktcHJlMTAtcGEzOS10c2kgcm9vdD0vZGV2L3NkYTUgSE9NRT0vIGNvbnNvbGU9dHR5
UzAgVEVSTT12dDEwMgogMDogMy92bWxpbnV4LTIuNC4xOS1wcmUxMC1wYTM5LXRzaQogMTogcm9v
dD0vZGV2L3NkYTUKIDI6IEhPTUU9LwogMzogY29uc29sZT10dHlTMAogNDogVEVSTT12dDEwMgoK
RWRpdCB3aGljaCBmaWVsZD8KKG9yICdiJyB0byBib290IHdpdGggdGhpcyBjb21tYW5kIGxpbmUp
PyAwCjMvdm1saW51eC0yLjQuMTktcGE5CkN1cnJlbnQgY29tbWFuZCBsaW5lOgozL3ZtbGludXgt
Mi40LjE5LXBhOSByb290PS9kZXYvc2RhNSBIT01FPS8gY29uc29sZT10dHlTMCBURVJNPXZ0MTAy
CiAwOiAzL3ZtbGludXgtMi40LjE5LXBhOQogMTogcm9vdD0vZGV2L3NkYTUKIDI6IEhPTUU9Lwog
MzogY29uc29sZT10dHlTMAogNDogVEVSTT12dDEwMgoKRWRpdCB3aGljaCBmaWVsZD8KKG9yICdi
JyB0byBib290IHdpdGggdGhpcyBjb21tYW5kIGxpbmUpPyBiCgpDb21tYW5kIGxpbmUgZm9yIGtl
cm5lbDogJ3Jvb3Q9L2Rldi9zZGE1IEhPTUU9LyBjb25zb2xlPXR0eVMwIFRFUk09dnQxMDIgcGFs
b19rZXJuZWw9My92bWxpbnV4LTIuNC4xOS1wYTknClNlbGVjdGVkIGtlcm5lbDogL3ZtbGludXgt
Mi40LjE5LXBhOSBmcm9tIHBhcnRpdGlvbiAzCkVMRjMyIGV4ZWN1dGFibGUKRW50cnkgMDAxMDAw
MDAgZmlyc3QgMDAxMDAwMDAgbiA2ClNlZ21lbnQgMCBsb2FkIDAwMTAwMDAwIHNpemUgMTk5OTk0
MCBtZWRpYXB0ciAweDEwMDAKU2VnbWVudCAxIGxvYWQgMDAyZWEwMDAgc2l6ZSA0NTMyNDggbWVk
aWFwdHIgMHgxZWEwMDAKU2VnbWVudCAyIGxvYWQgMDAzNWMwMDAgc2l6ZSAyNzA5NTIgbWVkaWFw
dHIgMHgyNTkwMDAKU2VnbWVudCAzIGxvYWQgMDAzYTAwMDAgc2l6ZSA4MTkyIG1lZGlhcHRyIDB4
MjljMDAwClNlZ21lbnQgNCBsb2FkIDAwM2E4MDAwIHNpemUgMzI3NjggbWVkaWFwdHIgMHgyOWUw
MDAKU2VnbWVudCA1IGxvYWQgMDAzZDFlYzAgc2l6ZSAxMDg0MTYgbWVkaWFwdHIgMHgyYTZlYzAK
QnJhbmNoaW5nIHRvIGtlcm5lbCBlbnRyeSBwb2ludCAweDAwMTAwMDAwLiAgSWYgdGhpcyBpcyB0
aGUgbGFzdAptZXNzYWdlIHlvdSBzZWUsIHlvdSBtYXkgbmVlZCB0byBzd2l0Y2ggeW91ciBjb25z
b2xlLiAgVGhpcyBpcwphIGNvbW1vbiBzeW1wdG9tIC0tIHNlYXJjaCB0aGUgRkFRIGFu
ZCBtYWlsaW5nIGxpc3QgYXQgcGFyaXNjLWxpbnV4Lm9yZwoKTGludXggdmVyc2lvbiAyLjQuMTkt
cGE5IChyb290QHBhbHgyMDAwKSAoZ2NjIHZlcnNpb24gMy4yLjEgMjAwMjA4MzAgKERlYmlhbiBw
cmVyZWxlYXNlKSkgIzEgVHVlIFNlcCAzIDE1OjEyOjEyIENFU1QgMjAwMgpGUFswXSBlbmFibGVk
OiBSZXYgMSBNb2RlbCAxNgpUaGUgMzItYml0IEtlcm5lbCBoYXMgc3RhcnRlZC4uLgpEZXRlcm1p
bmluZyBQREMgZmlybXdhcmUgdHlwZTogU3lzdGVtIE1hcC4KbW9kZWwgMDAwMDVkMDAgMDAwMDA0
ODEgMDAwMDAwMDAgMDAwMDAwMDIgNzdlOTM5MTAgMTAwMDAwZjAgMDAwMDAwMDggMDAwMDAwYjIg
MDAwMDAwYjIKdmVycyAgMDAwMDAzMDEKQ1BVSUQgdmVycyAxNyByZXYgMTEgKDB4MDAwMDAyMmIp
CmNhcGFiaWxpdGllcyAweDMKbW9kZWwgOTAwMC83ODUvQjIwMDAKVG90YWwgTWVtb3J5OiAyNTYg
TWIKcGFnZXRhYmxlX2luaXQKT24gbm9kZSAwIHRvdGFscGFnZXM6IDY1NTM2CnpvbmUoMCk6IDY1
NTM2IHBhZ2VzLgp6b25lKDEpOiAwIHBhZ2VzLgp6b25lKDIpOiAwIHBhZ2VzLgpMQ0QgZGlzcGxh
eSBhdCBmMDVkMDAwOCxmMDVkMDAwMCByZWdpc3RlcmVkCktlcm5lbCBjb21tYW5kIGxpbmU6IHJv
b3Q9L2Rldi9zZGE1IEhPTUU9LyBjb25zb2xlPXR0eVMwIFRFUk09dnQxMDIgcGFsb19rZXJuZWw9
My92bWxpbnV4LTIuNC4xOS1wYTkKQ29uc29sZTogY29sb3VyIGR1bW15IGRldmljZSAxNjB4NjQK
Q2FsaWJyYXRpbmcgZGVsYXkgbG9vcC4uLiA3OTkuNTMgQm9nb01JUFMKTWVtb3J5OiAyNTU5NTJr
IGF2YWlsYWJsZQpEZW50cnkgY2FjaGUgaGFzaCB0YWJsZSBlbnRyaWVzOiAzMjc2OCAob3JkZXI6
IDYsIDI2MjE0NCBieXRlcykKSW5vZGUgY2FjaGUgaGFzaCB0YWJsZSBlbnRyaWVzOiAxNjM4NCAo
b3JkZXI6IDUsIDEzMTA3MiBieXRlcykKTW91bnQtY2FjaGUgaGFzaCB0YWJsZSBlbnRyaWVzOiA0
MDk2IChvcmRlcjogMywgMzI3NjggYnl0ZXMpCkJ1ZmZlci1jYWNoZSBoYXNoIHRhYmxlIGVudHJp
ZXM6IDE2Mzg0IChvcmRlcjogNCwgNjU1MzYgYnl0ZXMpClBhZ2UtY2FjaGUgaGFzaCB0YWJsZSBl
bnRyaWVzOiA2NTUzNiAob3JkZXI6IDYsIDI2MjE0NCBieXRlcykKU2VhcmNoaW5nIGZvciBkZXZp
Y2VzLi4uCkZvdW5kIGRldmljZXM6CjEuIEFzdHJvIEJDIFJ1bndheSBQb3J0ICgxMikgYXQgMHhm
ZWQwMDAwMCBbMTBdLCB2ZXJzaW9ucyAweDU4MiwgMHgwLCAweGIKMi4gRWxyb3kgUENJIEJyaWRn
ZSAoMTMpIGF0IDB4ZmVkMzAwMDAgWzEwLzBdLCB2ZXJzaW9ucyAweDc4MiwgMHgwLCAweGEKMy4g
RWxyb3kgUENJIEJyaWRnZSAoMTMpIGF0IDB4ZmVkMzIwMDAgWzEwLzFdLCB2ZXJzaW9ucyAweDc4
MiwgMHgwLCAweGEKNC4gS2F6b28gVysgKDApIGF0IDB4ZmZmYTAwMDAgWzMyXSwgdmVyc2lvbnMg
MHg1ZDAsIDB4MCwgMHg0CjUuIE1lbW9yeSAoMSkgYXQgMHhmZWQxMDIwMCBbNDldLCB2ZXJzaW9u
cyAweDlkLCAweDAsIDB4OQpDUFUocyk6IDEgeCBQQTg2MDAgKFBDWC1XKykgYXQgNDAwLjAwMDAw
MCBNSHoKU0JBIGZvdW5kIEFzdHJvIDIuMSBhdCAweGZlZDAwMDAwCmxiYSB2ZXJzaW9uIFRSNC4w
ICgweDUpIGZvdW5kIGF0IDB4ZmVkMzAwMDAKbGJhIHZlcnNpb24gVFI0LjAgKDB4NSkgZm91bmQg
YXQgMHhmZWQzMjAwMApQT1NJWCBjb25mb3JtYW5jZSB0ZXN0aW5nIGJ5IFVOSUZJWApMaW51eCBO
RVQ0LjAgZm9yIExpbnV4IDIuNApCYXNlZCB1cG9uIFN3YW5zZWEgVW5pdmVyc2l0eSBDb21wdXRl
ciBTb2NpZXR5IE5FVDMuMDM5CkluaXRpYWxpemluZyBSVCBuZXRsaW5rIHNvY2tldApTb2Z0IHBv
d2VyIHN3aXRjaCBlbmFibGVkLCBwb2xsaW5nIEAgMHhmMDQwMDgwNC4KU3VwZXJJTzogRm91bmQg
TlM4NzU2MCBMZWdhY3kgSS9PIGRldmljZSBhdCAwMDowZS4xIChJUlEgNjQpIApTdXBlcklPOiBT
ZXJpYWwgcG9ydCAxIGF0IDB4M2Y4ClN1cGVySU86IFNlcmlhbCBwb3J0IDIgYXQgMHgyZjgKU3Vw
ZXJJTzogUGFyYWxsZWwgcG9ydCBhdCAweDM3OApTdXBlcklPOiBGbG9wcHkgY29udHJvbGxlciBh
dCAweDNmMApTdXBlcklPOiBBQ1BJIGF0IDB4N2UwClN1cGVySU86IFVTQiByZWd1bGF0b3IgZW5h
YmxlZApwYXJwb3J0MDogUEMtc3R5bGUgYXQgMHgzNzgsIGlycSAxMDEgW1BDU1BQKCwuLi4pXQpT
dGFydGluZyBrc3dhcGQKSm91cm5hbGxlZCBCbG9jayBEZXZpY2UgZHJpdmVyIGxvYWRlZApJbnN0
YWxsaW5nIGtuZnNkIChjb3B5cmlnaHQgKEMpIDE5OTYgb2tpckBtb25hZC5zd2IuZGUpLgpTVEkg
R1NDL1BDSSBncmFwaGljcyBkcml2ZXIgdmVyc2lvbiAwLjkKU1RJIFBDSSBncmFwaGljIFJPTSBm
b3VuZCBhdCBmNDk0MDAwMCAoMTI4IGtCKSwgZmIgYXQgZmIwMDAwMDAgKDE2IE1CKQpTVEkgd29y
ZCBtb2RlIFJPTSBhdCBmNDk0MDA0NCwgaHBhIGF0IGZiMDAwMDAwClNUSSBpZCAzNWFjZGExNi05
YTAyNTg3LCBjb25mb3JtcyB0byBzcGVjIHJldi4gOC4wYwpTVEkgZGV2aWNlOiBIUEE0OTgyQQpz
dGlmYjogVW5zdXBwb3J0ZWQgZ2Z4IGNhcmQgaWQgMHgzNWFjZGExNgpwdHk6IDI1NiBVbml4OTgg
cHR5cyBjb25maWd1cmVkClNlcmlhbCBkcml2ZXIgdmVyc2lvbiA1LjA1YyAoMjAwMS0wNy0wOCkg
d2l0aCBNQU5ZX1BPUlRTIFNIQVJFX0lSUSBTRVJJQUxfUENJIGVuYWJsZWQKdHR5UzAwIGF0IHBv
cnQgMHgwM2Y4IChpcnEgPSA5OSkgaXMgYSAxNjU1MEEKdHR5UzAxIGF0IHBvcnQgMHgwMmY4IChp
cnEgPSAxMDApIGlzIGEgMTY1NTBBCmxwMDogdXNpbmcgcGFycG9ydDAgKGludGVycnVwdC1kcml2
ZW4pLgpHZW5lcmljIFJUQyBEcml2ZXIgdjEuMDIgMDUvMjcvMTk5OSBTYW0gQ3JlYXNleSAoc2Ft
bXlAb2gudmVyaW8uY29tKQpVbmlmb3JtIE11bHRpLVBsYXRmb3JtIEUtSURFIGRyaXZlciBSZXZp
c2lvbjogNi4zMQppZGU6IEFzc3VtaW5nIDMzTUh6IHN5c3RlbSBidXMgc3BlZWQgZm9yIFBJTyBt
b2Rlczsgb3ZlcnJpZGUgd2l0aCBpZGVidXM9eHgKTlM4NzQxNTogSURFIGNvbnRyb2xsZXIgb24g
UENJIGJ1cyAwMCBkZXYgNzAKTlM4NzQxNTogY2hpcHNldCByZXZpc2lvbiAzCk5TODc0
MTU6IG5vdCAxMDAlIG5hdGl2ZSBtb2RlOiB3aWxsIHByb2JlIGlycXMgbGF0ZXIKICAgIGlkZTA6
IEJNLURNQSBhdCAweDA5MDAtMHgwOTA3LCBCSU9TIHNldHRpbmdzOiBoZGE6cGlvLCBoZGI6cGlv
CiAgICBpZGUxOiBCTS1ETUEgYXQgMHgwOTA4LTB4MDkwZiwgQklPUyBzZXR0aW5nczogaGRjOnBp
bywgaGRkOnBpbwpoZGE6IExUTjQ4NVMsIEFUQVBJIENEL0RWRC1ST00gZHJpdmUKaWRlMCBhdCAw
eDFmMC0weDFmNywweDNmNiBvbiBpcnEgMTAzCmhkYTogQVRBUEkgNDhYIENELVJPTSBkcml2ZSwg
MTIwa0IgQ2FjaGUKVW5pZm9ybSBDRC1ST00gZHJpdmVyIFJldmlzaW9uOiAzLjEyClJBTURJU0sg
ZHJpdmVyIGluaXRpYWxpemVkOiAxNiBSQU0gZGlza3Mgb2YgNDA5Nksgc2l6ZSAxMDI0IGJsb2Nr
c2l6ZQpsb29wOiBsb2FkZWQgKG1heCA4IGRldmljZXMpCkxpbnV4IFR1bGlwIGRyaXZlciB2ZXJz
aW9uIDAuOS4xNS1wcmUxMSAoTWF5IDExLCAyMDAyKQp0dWxpcDA6IG5vIHBoeSBpbmZvLCBhYm9y
dGluZyBtdGFibGUgYnVpbGQKdHVsaXAwOiAgTUlJIHRyYW5zY2VpdmVyICMxIGNvbmZpZyAxMDAw
IHN0YXR1cyA3ODJkIGFkdmVydGlzaW5nIDAxZTEuCmV0aDA6IERpZ2l0YWwgRFMyMTE0MyBUdWxp
cCByZXYgNjUgYXQgMHhmMDAsIDAwOjMwOkQzOjAxOjVBOjNCLCBJUlEgNjYuCnR1bGlwMTogIEVF
UFJPTSBkZWZhdWx0IG1lZGlhIHR5cGUgQXV0b3NlbnNlLgp0dWxpcDE6ICBJbmRleCAjMCAtIE1l
ZGlhIE1JSSAoIzExKSBkZXNjcmliZWQgYnkgYSAyMTE0MiBNSUkgUEhZICgzKSBibG9jay4KdHVs
aXAxOiAgTUlJIHRyYW5zY2VpdmVyICMxIGNvbmZpZyAzMTAwIHN0YXR1cyA3ODQ5IGFkdmVydGlz
aW5nIDAxMDEuCmV0aDE6IERpZ2l0YWwgRFMyMTE0MyBUdWxpcCByZXYgNjUgYXQgMHgxMjEwMCwg
MDA6MzA6NkU6MDY6MjM6RDAsIElSUSAxMzAuClNDU0kgc3Vic3lzdGVtIGRyaXZlciBSZXZpc2lv
bjogMS4wMApzeW01M2M4eHg6IGF0IFBDSSBidXMgMSwgZGV2aWNlIDMsIGZ1bmN0aW9uIDAKc3lt
NTNjOHh4OiA1M2M4NzUgZGV0ZWN0ZWQgCnN5bTUzYzh4eDogYXQgUENJIGJ1cyAwLCBkZXZpY2Ug
MTUsIGZ1bmN0aW9uIDAKc3ltNTNjOHh4OiA1M2M4OTVhIGRldGVjdGVkIApzeW01M2M4NzUtMDog
cmV2IDB4MjYgb24gcGNpIGJ1cyAxIGRldmljZSAzIGZ1bmN0aW9uIDAgaXJxIDEzMQpzeW01M2M4
NzUtMDogSUQgNywgRmFzdC0yMCwgUGFyaXR5IENoZWNraW5nCnN5bTUzYzg5NWEtMTogcmV2IDB4
MSBvbiBwY2kgYnVzIDAgZGV2aWNlIDE1IGZ1bmN0aW9uIDAgaXJxIDY1CnN5bTUzYzg5NWEtMTog
SUQgNywgRmFzdC00MCwgUGFyaXR5IENoZWNraW5nCnN5bTUzYzg5NWEtMTogaGFuZGxpbmcgcGhh
c2UgbWlzbWF0Y2ggZnJvbSBTQ1JJUFRTLgpzY3NpMCA6IHN5bTUzYzh4eC0xLjcuM2MtMjAwMTA1
MTIKc2NzaTEgOiBzeW01M2M4eHgtMS43LjNjLTIwMDEwNTEyCiAgVmVuZG9yOiBRVUFOVFVNICAg
TW9kZWw6IEFUTEFTNS05TFZEICAgICAgIFJldjogSFAwNAogIFR5cGU6ICAgRGlyZWN0LUFjY2Vz
cyAgICAgICAgICAgICAgICAgICAgICBBTlNJIFNDU0kgcmV2aXNpb246IDAzCiAgVmVuZG9yOiBR
VUFOVFVNICAgTW9kZWw6IEFUTEFTNS05TFZEICAgICAgIFJldjogSFAwNAogIFR5cGU6ICAgRGly
ZWN0LUFjY2VzcyAgICAgICAgICAgICAgICAgICAgICBBTlNJIFNDU0kgcmV2aXNpb246IDAzCkF0
dGFjaGVkIHNjc2kgZGlzayBzZGEgYXQgc2NzaTEsIGNoYW5uZWwgMCwgaWQgNSwgbHVuIDAKQXR0
YWNoZWQgc2NzaSBkaXNrIHNkYiBhdCBzY3NpMSwgY2hhbm5lbCAwLCBpZCA2LCBsdW4gMApzeW01
M2M4OTVhLTEtPDUsKj46IEZBU1QtMjAgV0lERSBTQ1NJIDQwLjAgTUIvcyAoNTAuMCBucywgb2Zm
c2V0IDMxKQpTQ1NJIGRldmljZSBzZGE6IDE3NzczNTI0IDUxMi1ieXRlIGhkd3Igc2VjdG9ycyAo
OTEwMCBNQikKUGFydGl0aW9uIGNoZWNrOgogc2RhOiBzZGExIHNkYTIgc2RhMyBzZGE0IDwgc2Rh
NSBzZGE2IHNkYTcgc2RhOCBzZGE5IHNkYTEwIHNkYTExID4Kc3ltNTNjODk1YS0xLTw2LCo+OiBG
QVNULTIwIFdJREUgU0NTSSA0MC4wIE1CL3MgKDUwLjAgbnMsIG9mZnNldCAzMSkKU0NTSSBkZXZp
Y2Ugc2RiOiAxNzc3MzUyNCA1MTItYnl0ZSBoZHdyIHNlY3RvcnMgKDkxMDAgTUIpCiBzZGI6IHVu
a25vd24gcGFydGl0aW9uIHRhYmxlCnN0aWNvbjogSW5pdGlhbGl6aW5nIFNUSSB0ZXh0IGNvbnNv
bGUuCkNvbnNvbGU6IHN3aXRjaGluZyB0byBjb2xvdXIgU1RJIGNvbnNvbGUgMTYweDY0Cm1pY2U6
IFBTLzIgbW91c2UgZGV2aWNlIGNvbW1vbiBmb3IgYWxsIG1pY2UKSFAgU0RDOiBObyBTREMgZm91
bmQuCkhQIFNEQyBNTEM6IFJlZ2lzdGVyaW5nIHRoZSBTeXN0ZW0gRG9tYWluIENvbnRyb2xsZXIn
cyBISUwgTUxDLgpIUCBTREMgTUxDOiBSZXF1ZXN0IGZvciByYXcgSElMIElTUiBob29rIGRlbmll
ZAptZDogbGluZWFyIHBlcnNvbmFsaXR5IHJlZ2lzdGVyZWQgYXMgbnIgMQptZDogcmFpZDAgcGVy
c29uYWxpdHkgcmVnaXN0ZXJlZCBhcyBuciAyCm1kOiByYWlkMSBwZXJzb25hbGl0eSByZWdpc3Rl
cmVkIGFzIG5yIDMKbWQ6IHJhaWQ1IHBlcnNvbmFsaXR5IHJlZ2lzdGVyZWQgYXMgbnIgNApyYWlk
NTogbWVhc3VyaW5nIGNoZWNrc3VtbWluZyBzcGVlZAogICA4cmVncyAgICAgOiAgIDk2My42MDAg
TUIvc2VjCiAgIDhyZWdzX3ByZWZldGNoOiAgIDk2My42MDAgTUIvc2VjCiAgIDMycmVncyAgICA6
ICAgNjg1LjIwMCBNQi9zZWMKICAgMzJyZWdzX3ByZWZldGNoOiAgIDY4NS4yMDAgTUIvc2VjCnJh
aWQ1OiB1c2luZyBmdW5jdGlvbjogOHJlZ3NfcHJlZmV0Y2ggKDk2My42MDAgTUIvc2VjKQptZDog
bWQgZHJpdmVyIDAuOTAuMCBNQVhfTURfREVWUz0yNTYsIE1EX1NCX0RJU0tTPTI3Cm1kOiBBdXRv
ZGV0ZWN0aW5nIFJBSUQgYXJyYXlzLgptZDogYXV0b3J1biAuLi4KbWQ6IC4uLiBhdXRvcnVuIERP
TkUuCk5FVDQ6IExpbnV4IFRDUC9JUCAxLjAgZm9yIE5FVDQuMApJUCBQcm90b2NvbHM6IElDTVAs
IFVEUCwgVENQLCBJR01QCklQOiByb3V0aW5nIGNhY2hlIGhhc2ggdGFibGUgb2YgMjA0
OCBidWNrZXRzLCAxNktieXRlcwpUQ1A6IEhhc2ggdGFibGVzIGNvbmZpZ3VyZWQgKGVzdGFibGlz
aGVkIDE2Mzg0IGJpbmQgMzI3NjgpCk5FVDQ6IFVuaXggZG9tYWluIHNvY2tldHMgMS4wL1NNUCBm
b3IgTGludXggTkVUNC4wLgpWRlM6IE1vdW50ZWQgcm9vdCAoZXh0MiBmaWxlc3lzdGVtKSByZWFk
b25seS4KRnJlZWluZyB1bnVzZWQga2VybmVsIG1lbW9yeTogMjY0ayBmcmVlZApJTklUOiB2ZXJz
aW9uIDIuODQgYm9vdGluZwpMb2FkaW5nIC9ldGMvY29uc29sZS9ib290dGltZS5rbWFwLmd6CkFj
dGl2YXRpbmcgc3dhcC4KQWRkaW5nIFN3YXA6IDI1MDg3Mmsgc3dhcC1zcGFjZSAocHJpb3JpdHkg
LTEpCkNoZWNraW5nIHJvb3QgZmlsZSBzeXN0ZW0uLi4KZnNjayAxLjI4LVdJUCAoMTctQXVnLTIw
MDIpCi9kZXYvc2RhNTogY2xlYW4sIDM4MjMyLzIwMzAwOCBmaWxlcywgMTQ2MzAxLzQwNjAxMiBi
bG9ja3MKU3lzdGVtIHRpbWUgd2FzIFR1ZSBTZXAgIDMgMTQ6MjY6NDIgVVRDIDIwMDIuClNldHRp
bmcgdGhlIFN5c3RlbSBDbG9jayB1c2luZyB0aGUgSGFyZHdhcmUgQ2xvY2sgYXMgcmVmZXJlbmNl
Li4uClN5c3RlbSBDbG9jayBzZXQuIFN5c3RlbSBsb2NhbCB0aW1lIGlzIG5vdyBUdWUgU2VwICAz
IDE0OjI2OjQ3IFVUQyAyMDAyLgpDYWxjdWxhdGluZyBtb2R1bGUgZGVwZW5kZW5jaWVzLi4uIGRv
bmUuCkxvYWRpbmcgbW9kdWxlczogCkNoZWNraW5nIGFsbCBmaWxlIHN5c3RlbXMuLi4KZnNjayAx
LjI4LVdJUCAoMTctQXVnLTIwMDIpCi9kZXYvc2RhMzogY2xlYW4sIDI1LzE1NjE2IGZpbGVzLCAy
Nzk4My82MjQ2NCBibG9ja3MKL2Rldi9zZGE2OiBjbGVhbiwgMjcxMi82MjQ5NiBmaWxlcywgMTIz
OTg0LzI0OTg0MCBibG9ja3MKL2Rldi9zZGE3OiBjbGVhbiwgMTEvMzEyMzIgZmlsZXMsIDM5NjIv
MTI0OTEyIGJsb2NrcwovZGV2L3NkYTg6IGNsZWFuLCAxMjIvMzEyMzIgZmlsZXMsIDEwMjExLzEy
NDkxMiBibG9ja3MKL2Rldi9zZGE5OiBjbGVhbiwgNzQwNDcvMjUwMzY4IGZpbGVzLCAzMjY0NTUv
NDk5OTY0IGJsb2NrcwovZGV2L3NkYTEwOiBjbGVhbiwgMTkzNDUvMjUwMzY4IGZpbGVzLCA0MjI3
NDcvNDk5OTY0IGJsb2NrcwovZGV2L3NkYTExOiBjbGVhbiwgNzg5NzQvMjUwMzY4IGZpbGVzLCA0
MTYwMTYvNDk5OTY0IGJsb2NrcwpMb2FkaW5nIHRoZSBzYXZlZC1zdGF0ZSBvZiB0aGUgc2VyaWFs
IGRldmljZXMgZnJvbSAvZXRjLi4uIApTZXR0aW5nIGtlcm5lbCB2YXJpYWJsZXMuCk1vdW50aW5n
IGxvY2FsIGZpbGVzeXN0ZW1zLi4uCi9kZXYvc2RhMyBvbiAvYm9vdCB0eXBlIGV4dDIgKHJ3KQov
ZGV2L3NkYTYgb24gL3ZhciB0eXBlIGV4dDIgKHJ3KQovZGV2L3NkYTcgb24gL3RtcCB0eXBlIGV4
dDIgKHJ3KQovZGV2L3NkYTggb24gL2hvbWUgdHlwZSBleHQyIChydykKL2Rldi9zZGE5IG9uIC91
c3Ivc3JjIHR5cGUgZXh0MiAocncpCi9kZXYvc2RhMTAgb24gL1NvdXJjZXMgdHlwZSBleHQyIChy
dykKL2Rldi9zZGExMSBvbiAvRGV2ZWxvcCB0eXBlIGV4dDIgKHJ3KQpSdW5uaW5nIDBkbnMtZG93
biB0byBtYWtlIHN1cmUgcmVzb2x2LmNvbmYgaXMgb2suLi5kb25lLgpDbGVhbmluZzogL2V0Yy9u
ZXR3b3JrL2lmc3RhdGUuClNldHRpbmcgdXAgSVAgc3Bvb2ZpbmcgcHJvdGVjdGlvbjogcnBfZmls
dGVyLgpDb25maWd1cmluZyBuZXR3b3JrIGludGVyZmFjZXM6IGRvbmUuClN0YXJ0aW5nIHBvcnRt
YXAgZGFlbW9uOiBwb3J0bWFwLgpSClNldHRpbmcgdGhlIFN5c3RlbSBDbG9jayB1c2luZyB0aGUg
SGFyZHdhcmUgQ2xvY2sgYXMgcmVmZXJlbmNlLi4uClN5c3RlbSBDbG9jayBzZXQuIExvY2FsIHRp
bWU6IFR1ZSBTZXAgIDMgMTY6MjY6NTEgQ0VTVCAyMDAyCgpDbGVhbmluZzogL3RtcCAvdmFyL2xv
Y2sgL3Zhci9ydW4uCkluaXRpYWxpemluZyByYW5kb20gbnVtYmVyIGdlbmVyYXRvci4uLiBkb25l
LgpSZWNvdmVyaW5nIG52aSBlZGl0b3Igc2Vzc2lvbnMuLi4gZG9uZS4KSU5JVDogRW50ZXJpbmcg
cnVubGV2ZWw6IDIKU3RhcnRpbmcgc3lzdGVtIGxvZyBkYWVtb246IHN5c2xvZ2RldGgwOiBTZXR0
aW5nIGhhbGYtZHVwbGV4IGJhc2VkIG9uIE1JSSMxIGxpbmsgcGFydG5lciBjYXBhYmlsaXR5IG9m
IDAwMjEuCi4KU3RhcnRpbmcga2VybmVsIGxvZyBkYWVtb246IGtsb2dkLgpTdGFydGluZyBORlMg
Y29tbW9uIHV0aWxpdGllczogc3RhdGQuClN0YXJ0aW5nIGludGVybmV0IHN1cGVyc2VydmVyOiBp
bmV0ZC4KU3RhcnRpbmcgcHJpbnRlciBzcG9vbGVyOiBscGQuCk5vdCBzdGFydGluZyBORlMga2Vy
bmVsIGRhZW1vbjogTm8gZXhwb3J0cy4KU3RhcnRpbmcgT3BlbkJTRCBTZWN1cmUgU2hlbGwgc2Vy
dmVyOiBzc2hkLgpTdGFydGluZyBkZWZlcnJlZCBleGVjdXRpb24gc2NoZWR1bGVyOiBhdGQuClN0
YXJ0aW5nIHBlcmlvZGljIGNvbW1hbmQgc2NoZWR1bGVyOiBjcm9uLgoKRGViaWFuIEdOVS9MaW51
eCB0ZXN0aW5nL3Vuc3RhYmxlIHBhbHgyMDAwIHR0eVMwCgpwYWx4MjAwMCBsb2dpbjogc3RyaW5n
cyAvYm9vdC92bWxpbnV4LTIuNC4xOS1wYTkgfCBncmVwIGdjYwpMaW51eCB2ZXJzaW9uIDIuNC4x
OS1wYTkgKHJvb3RAcGFseDIwMDApIChnY2MgdmVyc2lvbiAzLjIuMSAyMDAyMDgzMCAoRGViaWFu
IHByZXJlbGVhc2UpKSAjMSBUdWUgU2VwIDMgMTU6MTI6MTIgQ0VTVCAyMDAyCnBhbHgyMDAwOn4j
IAoKc2VyCgotLS0tLSBTZXJ2aWNlIE1lbnUgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQoKICAgICAgQ29tbWFuZCAgICAgICAgICAgICAg
ICAgICAgICAgICAgIERlc2NyaXB0aW9uCiAgICAgIC0tLS0tLS0gICAgICAgICAgICAgICAgICAg
ICAgICAgICAtLS0tLS0tLS0tLQogICAgICBDaGFzc2lzQ29kZXMgWzxwcm9jPnxPTnxPRkZdICAg
ICAgRGlzcGxheS9lbmFibGUvZGlzYWJsZSBjaGFzc2lzIGNvZGVzCiAgICAgIENMRUFSUElNICAg
ICAgICAgICAgICAgICAgICAgICAgICBDbGVhciAoemVybykgdGhlIGNvbnRlbnRzIG9mIFBJTQog
ICAgICBFZXByb21SZWFkIFs8YWRkcj4gWzxsZW4+XV0gICAgICAgUmVhZCBFRVBST00g
bG9jYXRpb25zCiAgICAgIE1lbVJlYWQgPGFkZHI+IFs8bGVuPl0gWzx0eXBlPl0gICBSZWFkIG1l
bW9yeSBsb2NhdGlvbnMKICAgICAgUGNpRGVsYXkgWzx2YWx1ZT5dICAgICAgICAgICAgICAgIERp
c3BsYXkgb3Igc2V0IFBDSSBkZWxheSB2YWx1ZQogICAgICBQRFQgW0NMRUFSXSAgICAgICAgICAg
ICAgICAgICAgICAgRGlzcGxheSBvciBjbGVhcgogICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgdGhlIFBhZ2UgRGVhbGxvY2F0aW9uIFRhYmxlCiAgICAgIFBJTSBbPHByb2M+
XSBbSFBNQ3xMUE1DfFRPQ10gICAgICBEaXNwbGF5IFBJTSBpbmZvcm1hdGlvbgogICAgICBSZW1v
dGVQb3dlciBbT058T0ZGXSAgICAgICAgICAgICAgRGlzcGxheS9lbmFibGUvZGlzYWJsZSByZW1v
dGUgcG93ZXIKICAgICAgU2NSb2xsIFtPTnxPRkZdICAgICAgICAgICAgICAgICAgIERpc3BsYXkg
b3IgY2hhbmdlIHNjcm9sbGluZyBhYmlsaXR5CgogICAgICBCT290IFtQUkl8QUxUfDxwYXRoPl0g
ICAgICAgICAgICAgQm9vdCBmcm9tIHNwZWNpZmllZCBwYXRoCiAgICAgIERJc3BsYXkgICAgICAg
ICAgICAgICAgICAgICAgICAgICBSZWRpc3BsYXkgdGhlIGN1cnJlbnQgbWVudQogICAgICBIRWxw
IFs8bWVudT58PGNvbW1hbmQ+XSAgICAgICAgICAgRGlzcGxheSBoZWxwIGZvciBtZW51IG9yIGNv
bW1hbmQKICAgICAgUkVTRVQgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFJlc3RhcnQgdGhl
IHN5c3RlbQogICAgICBNQWluICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgUmV0dXJuIHRv
IE1haW4gbWVudQotLS0tLQpTZXJ2aWNlIE1lbnU6IEVudGVyIGNvbW1hbmQgPiBwaW0KClBST0NF
U1NPUiBQSU0gSU5GT1JNQVRJT04KCi0tLS0tLS0tLS0tLS0tLS0tICBQcm9jZXNzb3IgMCBIUE1D
IEluZm9ybWF0aW9uIC0tLS0tLS0tLS0tLS0tLS0tLQoKVGltZXN0YW1wID0gCiAgVHVlIFNlcCAg
MyAxNDoyNjoxMyBHTVQgMjAwMiAgICAoMjA6MDI6MDk6MDM6MTQ6MjY6MTMpCgpIUE1DIENoYXNz
aXMgQ29kZXMgPSAyY2JmMCAgMjUwMGIgIDJjYmY0ICAyY2JmYyAgCgpHZW5lcmFsIFJlZ2lzdGVy
cyAwIC0gMzEKMDAtMDMgICAwMDAwMDAwMDAwMDAwMDAwICAwMDAwMDAwMDEwM2I3MjQ0ICAwMDAw
MDAwMDEwMTA4MDY0ICAwMDAwMDAwMDIwN2Y4MDAwCjA0LTA3ICAgMDAwMDAwMDAxMDJiNjgwMCAg
MDAwMDAwMDAyMDdmYzk0MCAgMDAwMDAwMDAyMDdmODAwMCAgMDAwMDAwMDAwMDAwMDAwOAowOC0x
MSAgIDAwMDAwMDAwMTA3ZTJlOTQgIDAwMDAwMDAwMTAzYjZlNDAgIDAwMDAwMDAwMDAwMDA0MDAg
IDAwMDAwMDAwZjA0MDhjZDgKMTItMTUgICAwMDAwMDAwMGYwNDA3ZWYwICAwMDAwMDAwMDFmMWY4
NmQwICAwMDAwMDAwMDAwMDAyMGY4ICAwMDAwMDAwMDAwMDM1Y2VjCjE2LTE5ICAgMDAwMDAwMDAx
MDdmY2RjMCAgMDAwMDAwMDAwMDAxNzgwMCAgMDAwMDAwMDAwMDAyOTQ5NCAgZmZmZmZmZmZmZmZm
ZmZmZgoyMC0yMyAgIDAwMDAwMDAwMDAwMDAwMGUgIDAwMDAwMDAwMDAwMDAwMDAgIDAwMDAwMDAw
MDAwMDQwMDAgIDAwMDAwMDAwMTAyZmQ4MTAKMjQtMjcgICAwMDAwMDAwMDAwMDAyYTRmICAwMDAw
MDAwMDEwN2ZjZGMwICAwMDAwMDAwMDAwMDAwMDBmICAwMDAwMDAwMDEwMmVhMDEwCjI4LTMxICAg
MDAwMDAwMDAwMDAwMDAzMCAgMDAwMDAwMDAxMTQzMDEwMCAgMDAwMDAwMDAxMTQzMDM0MCAgMDAw
MDAwMDAxMDNiYjAxMAoKPFByZXNzIGFueSBrZXkgdG8gY29udGludWUgKHEgdG8gcXVpdCk+IAoK
Q29udHJvbCBSZWdpc3RlcnMgMCAtIDMxCjAwLTAzICAgMDAwMDAwMDAwMDAwMDAwMCAgMDAwMDAw
MDAwMDAwMDAwMCAgMDAwMDAwMDAwMDAwMDAwMCAgMDAwMDAwMDAwMDAwMDAwMAowNC0wNyAgIDAw
MDAwMDAwMDAwMDAwMDAgIDAwMDAwMDAwMDAwMDAwMDAgIDAwMDAwMDAwMDAwMDAwMDAgIDAwMDAw
MDAwMDAwMDAwMDAKMDgtMTEgICAwMDAwMDAwMDAwMDAwNjM0ICAwMDAwMDAwMDAwMDAwMDAwICAw
MDAwMDAwMDAwMDAwMGMwICAwMDAwMDAwMDAwMDAwMDE3CjEyLTE1ICAgMDAwMDAwMDAwMDAwMDAw
MCAgMDAwMDAwMDAwMDAwMDAwMCAgMDAwMDAwMDAwMDEwNzAwMCAgMDAwMDAwMDAwMDAwMDAwMAox
Ni0xOSAgIDAwMDAwMDdiZTk1ZmZjNjAgIDAwMDAwMDAwMDAwMDAwMDAgIDAwMDAwMDAwMTAxMDg2
MzggIDAwMDAwMDAwMGZhMTEyODgKMjAtMjMgICAwMDAwMDAwMDEwMjQwMjI0ICAwMDAwMDAwMDQ4
MDMwMTA0ICAwMDAwMDAwMDAwMDQwMDBlICAwMDAwMDAwMDgwMDAwMDAwCjI0LTI3ICAgMDAwMDAw
MDAwMDMwNTAwMCAgMDAwMDAwMDAwMDMwNTAwMCAgMDAwMDAwMDAwMDA0NDAyMSAgMDAwMDAwMDBm
MDQxMjAwMAoyOC0zMSAgIDAwMDAwMDAwNTU1NTU1NTUgIDAwMDAwMDAwNTU1NTU1NTUgIDAwMDAw
MDAwMWYxZjgwMDAgIDAwMDAwMDAwMTAzYTgwMDAKU3BhY2UgUmVnaXN0ZXJzIDAgLSA3CgowMC0w
MyAgIDAwMDAwMDAwICAgICAgICAgIDAwMDAwMzFhICAgICAgICAgIDAwMDAwMDAwICAgICAgICAg
IDAwMDAwMzFhCjA0LTA3ICAgMDAwMDAwMDAgICAgICAgICAgMDAwMDAwMDAgICAgICAgICAgMDAw
MDAwMDAgICAgICAgICAgMDAwMDAwMDAKCjxQcmVzcyBhbnkga2V5IHRvIGNvbnRpbnVlIChxIHRv
IHF1aXQpPiAKCklJQSBTcGFjZSAgICAgICAgICAgICAgICAgICAgPSAweDAwMDAwMDAwMDAwMDAw
MDAKSUlBIE9mZnNldCAgICAgICAgICAgICAgICAgICA9IDB4MDAwMDAwMDAxMDEwODYzYwpDaGVj
ayBUeXBlICAgICAgICAgICAgICAgICAgID0gMHgyMDAwMDAwMApDUFUgU3RhdGUgICAgICAgICAg
ICAgICAgICAgID0gMHg5ZTAwMDAwNApDYWNoZSBDaGVjayAgICAgICAgICAgICAgICAgID0gMHgw
MDAwMDAwMApUTEIgQ2hlY2sgICAgICAgICAgICAgICAgICAgID0gMHgwMDAwMDAwMApCdXMgQ2hl
Y2sgICAgICAgICAgICAgICAgICAgID0gMHgwMDMwMTBiYgpBc3Npc3RzIENoZWNrICAgICAgICAg
ICAgICAgID0gMHgwMDAwMDAwMApBc3Npc3QgU3RhdGUgICAgICAgICAgICAgICAgID0gMHgwMDAw
MDAwMApQYXRoIEluZm8gICAgICAgICAgICAgICAgICAgID0gMHgwMDAzMTgwMApTeXN0
ZW0gUmVzcG9uZGVyIEFkZHJlc3MgICAgID0gMHhmZmZmZmZmZmZlZDEwMjAwClN5c3RlbSBSZXF1
ZXN0b3IgQWRkcmVzcyAgICAgPSAweGZmZmZmZmZmZmZmYTAwMDAKCkZsb2F0aW5nLVBvaW50IFJl
Z2lzdGVycyAwIC0gMzEKMDAtMDMgICAwMDAwMDAxZjAwMDAwMDAwICAwMDAwMDAwMDAwMDAwMDAw
ICAwMDAwMDAwMDAwMDAwMDAwICAwMDAwMDAwMDAwMDAwMDAwCjA0LTA3ICAgMDAwMDQwMDAxMDJm
ZTgxMCAgMDAwMDAwMDExMDE0Y2ZmNCAgZjAwMDAwMDAxMDJmZTgxMCAgMTAzN2EwMTAxMDJkZTAw
MAowOC0xMSAgIDEwMzA0MDIwMDAwMDAwMDIgIDAwMDAwMDAyMDAwMDAwMDIgIDAwMDAwMDAwMTAy
ZmQ4MTAgIDEwMzlmODEwMTAyZmE4MTAKMTItMTUgICAxMDNhMDAwMDEwNzljMDAwICAwMDAwMDAw
MjAwMDAwMDAyICAwMDAwMDAwMDEwMzllMjY0ICAxMDJmYTgxMDEwM2EwMDAwCjE2LTE5ICAgMTAy
ZmQ4MTAwMDAwMDAwYiAgMTAzYjZlNGIxMDJmZGIyOCAgMDAwMDAwMGYxMDNiNjgxMCAgZjAwMDAw
MDAwMDAwMDAwZgoyMC0yMyAgIDAwMDAwMDAxMTAzOWUwMDAgIGYwMDAwMDAwMTAxM2M3MGMgIDAw
MDAwMDAwMDAwMDAwMDggIDAwMDAwMDAwMDAwMDAwMDAKMjQtMjcgICAwMDAwMDAwYTFmZmY5MGEw
ICAwMDAwOTk5OTAwMDAwMDAwICAxMDc5YzAwMDAwMDAwMDAxICAwMDAwMWZiNjEwMmI2MDAwCjI4
LTMxICAgMTA2YjQ2YTAxMDJiNjFhOCAgMTA3OWMwMDAxMDEzZTI2OCAgMTAyZmE4MTAxMDNhMDAw
MCAgMTAwZDQwMDAxMDBkNDVkMAoKPFByZXNzIGFueSBrZXkgdG8gY29udGludWUgKHEgdG8gcXVp
dCk+IAoKCic5MDAwLzc4NSBCLEMsSiBXb3Jrc3RhdGlvbiBVbmFyY2hpdGVjdGVkIChwZXItQ1BV
KScsIHJldiAxLCAxNDAgYnl0ZXM6CgpDaGVjayBTdW1tYXJ5ICAgICAgICAgICAgICAgID0gMHhj
YjgxMDQxMDAwMDAwMDAwCkF2YWlsYWJsZSBNZW1vcnkgICAgICAgICAgICAgPSAweDAwMDAwMDAw
MTAwMDAwMDAKQ1BVIERpYWdub3NlIFJlZ2lzdGVyIDIgICAgICA9IDB4MDMwMTAwMDAwMDAwMDAw
NApDUFUgU3RhdHVzIFJlZ2lzdGVyIDAgICAgICAgID0gMHgyNDIwYzIwMDAwMDAwMDAwCkNQVSBT
dGF0dXMgUmVnaXN0ZXIgMSAgICAgICAgPSAweDgwODAwMDAwMDAwMDAwMDAKU0FERCBMT0cgICAg
ICAgICAgICAgICAgICAgICA9IDB4MDAwMDAwMDA0ZTY1Nzg3NApSZWFkIFNob3J0IExPRyAgICAg
ICAgICAgICAgID0gMHhjMWFmMDBmZmZlZTAwZjI4CkVSUk9SX1NUQVRVUyAgICAgICAgICAgICAg
ICAgPSAweDAwMDAwMDAwMDAwMDAwMTAKTUVNX0FERFIgICAgICAgICAgICAgICAgICAgICA9IDB4
MDAwMDAxZmYzZmZmZmZmZgpNRU1fU1lORCAgICAgICAgICAgICAgICAgICAgID0gMHgwMDAwMDAw
MDAwMDAwMDAwCk1FTV9BRERSX0NPUlIgICAgICAgICAgICAgICAgPSAweDAwMDAwMWZmM2ZmZmZm
ZmYKTUVNX1NZTkRfQ09SUiAgICAgICAgICAgICAgICA9IDB4MDAwMDAwMDAwMDAwMDAwMApSVU5f
REFUQV9ISUdIICAgICAgICAgICAgICAgID0gMHhjMWJmZjBmZmZlZDA4MDQwClJVTl9EQVRBX0xP
VyAgICAgICAgICAgICAgICAgPSAweGMxYmZmMGZmZmVkMDgwNDAKUlVOX0NUUkwgICAgICAgICAg
ICAgICAgICAgICA9IDB4MDAwMDAyMWMwMDAwMTQxOApSVU5fQUREUiAgICAgICAgICAgICAgICAg
ICAgID0gMHhjMWJmZjBmZmZlZDA4MDQwClN5c3RlbSBSZXNwb25kZXIgUGF0aCAgICAgICAgPSAw
eDAwZmZmZmZmZmZmZmZmZmYKCgpIUE1DIFBJTSBBbmFseXNpcyBJbmZvcm1hdGlvbjoKClRpbWVz
dGFtcCA9IAogIFR1ZSBTZXAgIDMgMTQ6MjY6MTMgR01UIDIwMDIgICAgKDIwOjAyOjA5OjAzOjE0
OjI2OjEzKQoKCic5MDAwLzc4NSBCLEMsSiBXb3Jrc3RhdGlvbiBIUE1DIFBJTSBBbmFseXNpcyAo
cGVyLUNQVSknLCByZXYgMCwgMTMwNCBieXRlczoKCkEgRGF0YSBNaXNzIFRpbWVvdXQgb2NjdXJy
ZWQgd2hpbGUgQ1BVIDAgd2FzCnJlcXVlc3RpbmcgaW5mb3JtYXRpb24uCgoKTWVtb3J5L0lPIENv
bnRyb2xsZXIgRXJyb3IgQW5hbHlzaXMgSW5mb3JtYXRpb246CgpUaGUgTWVtb3J5L0lPIENvbnRy
b2xsZXIgb25seSBvYnNlcnZlZCB0aGUgQnJvYWRjYXN0IEVycm9yLiAgSXQgZGlkIG5vdCBsb2cK
YW55IGFkZGl0aW9uYWwgaW5mb3JtYXRpb24gYWJvdXQgdGhlIEhQTUMuCgo8UHJlc3MgYW55IGtl
eSB0byBjb250aW51ZSAocSB0byBxdWl0KT4gCgotLS0tLS0tLS0tLS0tLS0tLSAgUHJvY2Vzc29y
IDAgTFBNQyBJbmZvcm1hdGlvbiAtLS0tLS0tLS0tLS0tLS0tLS0KCkNoZWNrIFR5cGUgICAgICAg
ICAgICAgICAgICAgPSAweDAwMDAwMDAwCkkvRCBDYWNoZSBQYXJpdHkgSW5mbyAgICAgICAgPSAw
eDAwMDAwMDAwCkNhY2hlIENoZWNrICAgICAgICAgICAgICAgICAgPSAweDAwMDAwMDAwClRMQiBD
aGVjayAgICAgICAgICAgICAgICAgICAgPSAweDAwMDAwMDAwCkJ1cyBDaGVjayAgICAgICAgICAg
ICAgICAgICAgPSAweDAwMDAwMDAwCkFzc2lzdHMgQ2hlY2sgICAgICAgICAgICAgICAgPSAweDAw
MDAwMDAwCkFzc2lzdCBTdGF0ZSAgICAgICAgICAgICAgICAgPSAweDAwMDAwMDAwClBhdGggSW5m
byAgICAgICAgICAgICAgICAgICAgPSAweDAwMDAwMDAwClN5c3RlbSBSZXNwb25kZXIgQWRkcmVz
cyAgICAgPSAweDAwMDAwMDAwMDAwMDAwMDAKU3lzdGVtIFJlcXVlc3RvciBBZGRyZXNzICAgICA9
IDB4MDAwMDAwMDAwMDAwMDAwMAoKCi0tLS0tLS0tLS0tLS0tLS0tICBQcm9jZXNzb3IgMCBUT0Mg
SW5mb3JtYXRpb24gLS0tLS0tLS0tLS0tLS0tLS0tLQoKR2VuZXJhbCBSZWdpc3RlcnMgMCAtIDMx
CjAwLTAzICAgMDAwMDAwMDAwMDAwMDAwMCAgMDAwMDAwMDAwMDAwMDAwMCAgMDAwMDAwMDAwMDAw
MDAwMCAgMDAwMDAwMDAwMDAwMDAwMAowNC0wNyAgIDAwMDAwMDAwMDAwMDAwMDAgIDAwMDAwMDAw
MDAwMDAwMDAgIDAwMDAwMDAwMDAwMDAwMDAgIDAwMDAwMDAwMDAwMDAwMDAKMDgtMTEgICAwMDAw
MDAwMDAwMDAwMDAwICAwMDAwMDAwMDAwMDAwMDAwICAwMDAwMDAwMDAwMDAwMDAwICAwMDAwMDAw
MDAwMDAwMDAwCjEyLTE1ICAgMDAwMDAwMDAwMDAwMDAwMCAgMDAwMDAwMDAwMDAwMDAw
MCAgMDAwMDAwMDAwMDAwMDAwMCAgMDAwMDAwMDAwMDAwMDAwMAoxNi0xOSAgIDAwMDAwMDAwMDAw
MDAwMDAgIDAwMDAwMDAwMDAwMDAwMDAgIDAwMDAwMDAwMDAwMDAwMDAgIDAwMDAwMDAwMDAwMDAw
MDAKMjAtMjMgICAwMDAwMDAwMDAwMDAwMDAwICAwMDAwMDAwMDAwMDAwMDAwICAwMDAwMDAwMDAw
MDAwMDAwICAwMDAwMDAwMDAwMDAwMDAwCjI0LTI3ICAgMDAwMDAwMDAwMDAwMDAwMCAgMDAwMDAw
MDAwMDAwMDAwMCAgMDAwMDAwMDAwMDAwMDAwMCAgMDAwMDAwMDAwMDAwMDAwMAoyOC0zMSAgIDAw
MDAwMDAwMDAwMDAwMDAgIDAwMDAwMDAwMDAwMDAwMDAgIDAwMDAwMDAwMDAwMDAwMDAgIDAwMDAw
MDAwMDAwMDAwMDAKCjxQcmVzcyBhbnkga2V5IHRvIGNvbnRpbnVlIChxIHRvIHF1aXQpPiAKCkNv
bnRyb2wgUmVnaXN0ZXJzIDAgLSAzMQowMC0wMyAgIDAwMDAwMDAwMDAwMDAwMDAgIDAwMDAwMDAw
MDAwMDAwMDAgIDAwMDAwMDAwMDAwMDAwMDAgIDAwMDAwMDAwMDAwMDAwMDAKMDQtMDcgICAwMDAw
MDAwMDAwMDAwMDAwICAwMDAwMDAwMDAwMDAwMDAwICAwMDAwMDAwMDAwMDAwMDAwICAwMDAwMDAw
MDAwMDAwMDAwCjA4LTExICAgMDAwMDAwMDAwMDAwMDAwMCAgMDAwMDAwMDAwMDAwMDAwMCAgMDAw
MDAwMDAwMDAwMDAwMCAgMDAwMDAwMDAwMDAwMDAwMAoxMi0xNSAgIDAwMDAwMDAwMDAwMDAwMDAg
IDAwMDAwMDAwMDAwMDAwMDAgIDAwMDAwMDAwMDAwMDAwMDAgIDAwMDAwMDAwMDAwMDAwMDAKMTYt
MTkgICAwMDAwMDAwMDAwMDAwMDAwICAwMDAwMDAwMDAwMDAwMDAwICAwMDAwMDAwMDAwMDAwMDAw
ICAwMDAwMDAwMDAwMDAwMDAwCjIwLTIzICAgMDAwMDAwMDAwMDAwMDAwMCAgMDAwMDAwMDAwMDAw
MDAwMCAgMDAwMDAwMDAwMDAwMDAwMCAgMDAwMDAwMDAwMDAwMDAwMAoyNC0yNyAgIDAwMDAwMDAw
MDAwMDAwMDAgIDAwMDAwMDAwMDAwMDAwMDAgIDAwMDAwMDAwMDAwMDAwMDAgIDAwMDAwMDAwMDAw
MDAwMDAKMjgtMzEgICAwMDAwMDAwMDAwMDAwMDAwICAwMDAwMDAwMDAwMDAwMDAwICAwMDAwMDAw
MDAwMDAwMDAwICAwMDAwMDAwMDAwMDAwMDAwClNwYWNlIFJlZ2lzdGVycyAwIC0gNwoKMDAtMDMg
ICAwMDAwMDAwMCAgICAgICAgICAwMDAwMDAwMCAgICAgICAgICAwMDAwMDAwMCAgICAgICAgICAw
MDAwMDAwMAowNC0wNyAgIDAwMDAwMDAwICAgICAgICAgIDAwMDAwMDAwICAgICAgICAgIDAwMDAw
MDAwICAgICAgICAgIDAwMDAwMDAwCgpJSUEgU3BhY2UgICAgICAgICAgICAgICAgICAgID0gMHgw
MDAwMDAwMDAwMDAwMDAwCklJQSBPZmZzZXQgICAgICAgICAgICAgICAgICAgPSAweDAwMDAwMDAw
MDAwMDAwMDAKQ1BVIFN0YXRlICAgICAgICAgICAgICAgICAgICA9IDB4MDAwMDAwMDAKCgo8UHJl
c3MgYW55IGtleSB0byBjb250aW51ZSAocSB0byBxdWl0KT4gCgpNZW1vcnkgRXJyb3IgTG9nIElu
Zm9ybWF0aW9uOgoKVGltZXN0YW1wID0gCiAgVHVlIFNlcCAgMyAxNDoyNjoxMyBHTVQgMjAwMiAg
ICAoMjA6MDI6MDk6MDM6MTQ6MjY6MTMpCgoKJzkwMDAvNzg1IEIsQyxKIFdvcmtzdGF0aW9uIE1l
bW9yeSBFcnJvciBMb2cnLCByZXYgMCwgNjQgYnl0ZXM6CgogICBObyBtZW1vcnkgZXJyb3JzIGxv
Z2dlZAoKCkkvTyBNb2R1bGUgRXJyb3IgTG9nIEluZm9ybWF0aW9uOgoKVGltZXN0YW1wID0gCiAg
VHVlIFNlcCAgMyAxNDoyNjoxMyBHTVQgMjAwMiAgICAoMjA6MDI6MDk6MDM6MTQ6MjY6MTMpCgoK
JzkwMDAvNzg1IEIsQyxKIFdvcmtzdGF0aW9uIElPIEVycm9yIExvZycsIHJldiAwLCAyMjggYnl0
ZXM6CgogUm9wZSAgICAgV29yZDEgICAgICAgIFdvcmQyICAgICAgICAgICAgV29yZDMKLS0tLS0t
IC0tLS0tLS0tLS0tLSAtLS0tLS0tLS0tLS0KICAgMCAgICAweDAwMDAwMDAwICAgMHgwZTBjYzAw
OSAgIDB4MDAwMDAwMDBmZWQzMDA0OAogICAxICAgIDB4MDAwMDAwMDAgICAweDFlMGNjMDA5ICAg
MHgwMDAwMDAwMGZlZDMyMDQ4CiAgIDIgICAgLS0tLS0tLS0tLSAgIDB4MmUwY2MwMDkgICAtLS0t
LS0tLS0tLS0tLS0tLS0KICAgMyAgICAtLS0tLS0tLS0tICAgMHgzZTBjYzAwOSAgIC0tLS0tLS0t
LS0tLS0tLS0tLQogICA0ICAgIC0tLS0tLS0tLS0gICAweDRlMGNjMDA5ICAgLS0tLS0tLS0tLS0t
LS0tLS0tCiAgIDUgICAgLS0tLS0tLS0tLSAgIDB4NWUwY2MwMDkgICAtLS0tLS0tLS0tLS0tLS0t
LS0KICAgNiAgICAtLS0tLS0tLS0tICAgMHg2ZTBjYzAwOSAgIC0tLS0tLS0tLS0tLS0tLS0tLQog
ICA3ICAgIC0tLS0tLS0tLS0gICAweDdlMGNjMDA5ICAgLS0tLS0tLS0tLS0tLS0tLS0tClNlcnZp
Y2UgTWVudTogRW50ZXIgY29tbWFuZCA+IAoKIyBncmVwIDEwMTA4MCAvYm9vdC9TeXN0ZW0ubWFw
LTIuNC4xOS1wYTkKMTAxMDgwMDAgVCBzeXNjYWxsX2V4aXRfcmZpCjEwMTA4MDY0IHQgaW50cl9y
ZXR1cm4KMTAxMDgwNzggdCBpbnRyX2NoZWNrX3Jlc2NoZWQKMTAxMDgwODQgdCBpbnRyX2NoZWNr
X3NpZwoxMDEwODA5MCB0IGludHJfcmVzdG9yZQoK
--=========3D3815BD0000B0C0/mail.tiscali.be--
From jsoe0708@tiscali.be Tue Sep 3 17:02:58 2002
From: jsoe0708@tiscali.be (jsoe0708@tiscali.be)
Date: Tue, 3 Sep 2002 18:02:58 +0200
Subject: [parisc-linux] Unaligne access [was: Back to evms-1.0.1 && unaligne access && gdb ]
In-Reply-To: <20020902172854.C73F44829@dsl2.external.hp.com>
Message-ID: <3D3815BD0000B0E9@ocpmta5.be.tiscali.com>
Hello Grant,
>
>then I'll wager there is padding between the char and int fields
>of that struct.
That is also what I believe to understand.
>
...
>> What can I do to analyse this problem? (printing all p addresses and its
>> elements
>> during a run with the original code and compare with a run with modified
>> code?)
>
>yes. You want to verify the addreses are unaligned.
And here is some data of my analyse:
First surprise in the two case (original checks.c and my checks.c with only
"if (p->boot_ind != 0x00 && ") p addresses are exactly the same here is an
example:
with checks.c.orig:
dmesg
...
evms_vgscan(10137): unaligned access to 0x000272ee at ip=0x4020a2ab
corresponding adresses:
p add: 0x272ee
p.boot_ind add: 0x272ee
p.head add: 0x272ef
p.sector add: 0x272f0
p.cyl add: 0x272f1
p.sys_ind add: 0x272f2
p.end_head add: 0x272f3
p.end_sector add: 0x272f4
p.end_cyl add: 0x272f5
p.start_sect add: 0x272f6
p.nr_sects add: 0x272fa
with the checks.c.new:
p add: 0x272ee
p.boot_ind add: 0x272ee
p.head add: 0x272ef
p.sector add: 0x272f0
p.cyl add: 0x272f1
p.sys_ind add: 0x272f2
p.end_head add: 0x272f3
p.end_sector add: 0x272f4
p.end_cyl add: 0x272f5
p.start_sect add: 0x272f6
p.nr_sects add: 0x272fa
What do you think?
Thanks again for attention and help,
Joel
PS1: just in case I made error here is the code I add to print addresses:
printf("p add: %p\n", p);
printf("p.boot_ind add: %p\n", &(p->boot_ind));
printf("p.head add: %p\n", &(p->head));
printf("p.sector add: %p\n", &(p->sector));
printf("p.cyl add: %p\n", &(p->cyl));
printf("p.sys_ind add: %p\n", &(p->sys_ind));
printf("p.end_head add: %p\n", &(p->end_head));
printf("p.end_sector add: %p\n", &(p->end_sector));
printf("p.end_cyl add: %p\n", &(p->end_cyl));
printf("p.start_sect add: %p\n", &(p->start_sect));
printf("p.nr_sects add: %p\n", &(p->nr_sects));
PS2: If you think it could help you more, I can send you the complete logs
I get from the two runs as well as sources
From Randolph Chung <randolph@tausq.org> Tue Sep 3 17:13:26 2002
From: Randolph Chung <randolph@tausq.org> (Randolph Chung)
Date: Tue, 3 Sep 2002 09:13:26 -0700
Subject: [parisc-linux] Gcc-3.2 beside gcc-3.0: HOWTO?
In-Reply-To: <3D3815BD0000B0C0@ocpmta5.be.tiscali.com>
References: <20020903070555.GR25710@tausq.org> <3D3815BD0000B0C0@ocpmta5.be.tiscali.com>
Message-ID: <20020903161326.GI14634@tausq.org>
> General Registers 0 - 31
> 00-03 0000000000000000 00000000103b7244 0000000010108064 00000000207f8000
^^^^^^^^^^^^^^^^ GR02, aka
the return pointer
> Control Registers 0 - 31
> 00-03 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> 04-07 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> 08-11 0000000000000634 0000000000000000 00000000000000c0 0000000000000017
> 12-15 0000000000000000 0000000000000000 0000000000107000 0000000000000000
> 16-19 0000007be95ffc60 0000000000000000 0000000010108638 000000000fa11288
^^^^^^^^^^^^^^^^
cr19 is the "IIR", this is the insn that caused the fault
in this case, this insn is stw r1,4(sr0,r29)
> 20-23 0000000010240224 0000000048030104 000000000004000e 0000000080000000
> 24-27 0000000000305000 0000000000305000 0000000000044021 00000000f0412000
> 28-31 0000000055555555 0000000055555555 000000001f1f8000 00000000103a8000
^^^^^^^^^^^^^^^^ which looks quite bogus
> IIA Space = 0x0000000000000000
> IIA Offset = 0x000000001010863c
this is the "iaoq" -- the instruction pointer
> But where is iaoq (I do not found in linux/Documentation/parisc)?
>
> here is what I got: grep 101080 /boot/System.map-2.4.19-pa9
> 10108000 T syscall_exit_rfi
> 10108064 t intr_return
> 10108078 t intr_check_resched
> 10108084 t intr_check_sig
> 10108090 t intr_restore
is this the system.map from the kernel you are building?
if it is, then intr_return is the calling function (one up in the
stack). the function that includes 1010863c is the one that one that's
causing the fault. that would be one place to look.
hth
randolph
--
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/
From grundler@dsl2.external.hp.com Tue Sep 3 21:33:17 2002
From: grundler@dsl2.external.hp.com (Grant Grundler)
Date: Tue, 03 Sep 2002 14:33:17 -0600
Subject: [parisc-linux] Re: Unaligne access [was: Back to evms-1.0.1 && unaligne access && gdb ]
In-Reply-To: Message from jsoe0708@tiscali.be
of "Tue, 03 Sep 2002 18:02:58 +0200." <3D3815BD0000B0E9@ocpmta5.be.tiscali.com>
References: <3D3815BD0000B0E9@ocpmta5.be.tiscali.com>
Message-ID: <20020903203317.C30834829@dsl2.external.hp.com>
jsoe0708@tiscali.be wrote:
...
> And here is some data of my analyse:
>
> First surprise in the two case (original checks.c and my checks.c with only
> "if (p->boot_ind != 0x00 && ") p addresses are exactly the same here is an
> example:
...
> with the checks.c.new:
> p add: 0x272ee
> p.boot_ind add: 0x272ee
> p.head add: 0x272ef
> p.sector add: 0x272f0
> p.cyl add: 0x272f1
> p.sys_ind add: 0x272f2
> p.end_head add: 0x272f3
> p.end_sector add: 0x272f4
> p.end_cyl add: 0x272f5
> p.start_sect add: 0x272f6
> p.nr_sects add: 0x272fa
>
> What do you think?
checks.c.new will generate a "misaligned access" when "p.start_sect"
is accessed. 0x272f6 is aligned on 2byte address, not 4 byte.
Ditto for "p.nr_sects".
You sure checks.c.new is referencing 0x272f6 and not something else?
You reviewed dmesg output?
...
> PS1: just in case I made error here is the code I add to print addresses:
printf's look right.
> PS2: If you think it could help you more, I can send you the complete logs
> I get from the two runs as well as sources
thanks but no. I'm just trying to help you understand "unaligned access".
grant
From dave@hiauly1.hia.nrc.ca Tue Sep 3 21:44:28 2002
From: dave@hiauly1.hia.nrc.ca (John David Anglin)
Date: Tue, 3 Sep 2002 16:44:28 -0400 (EDT)
Subject: [parisc-linux] Re: Unaligne access [was: Back to evms-1.0.1 && unaligne access && gdb ]
In-Reply-To: <3D3815BD0000B0E9@ocpmta5.be.tiscali.com> from "jsoe0708@tiscali.be" at Sep 3, 2002 06:02:58 pm
Message-ID: <200209032044.g83KiS0d008279@hiauly1.hia.nrc.ca>
> >then I'll wager there is padding between the char and int fields
> >of that struct.
>
> That is also what I believe to understand.
Unlikely. The unaligned trap handler in the kernel is probably
fixing the unaligned access. You need to look in the kernel log
to see if this is happening.
Dave
--
J. David Anglin dave.anglin@nrc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6605)
From timball@tux.org Tue Sep 3 22:03:22 2002
From: timball@tux.org (Timothy Ball)
Date: Tue, 3 Sep 2002 17:03:22 -0400
Subject: [parisc-linux] [OT] klez virus
Message-ID: <20020903210322.GN21005@gwyn.tux.org>
So it seems that a couple of people on this list have been hit w/ this
little stupid windows virus. Not that it's actually possible for anyone
running linux, but the virus is sneaky and likes to forge "From:"
lines...
So here's a little thing I've prepared to help people on list figure out
what they have to do:
--snip--snip--snip--
Both you and I have been targeted by the klez virus, it is a virus that
fakes email "From:" headers to mask the true origin of what computer actually
sent you the virus. I assure you that there is very little way *I* could have
this virus. The virus targets microsoft outlook users and internet explorer
users, and since I use linux there is very little chance that the virus
came from me.
Read more about the virus at and how it infects and spreads at (the jmu
article geared towards students is probably the best):
http://www.jmu.edu/computing/security/info/klez.shtml
http://www.wired.com/news/technology/0,1282,52174,00.html
http://www.messagelabs.com/viruseye/
The jmu article will explain how to best track down who actually sent
you a copy of the virus. Once the actual person responsible for infection
is found they can use the freely available klez virus remover from symantec:
http://securityresponse.symantec.com/avcenter/venc/data/w32.klez.removal.tool.html
It's not me, it's the virus.
--timball
--snip--snip--snip--
--
GPG key available on pgpkeys.mit.edu
pub 1024D/511FBD54 2001-07-23 Timothy Lu Hu Ball <timball@tux.org>
Key fingerprint = B579 29B0 F6C8 C7AA 3840 E053 FE02 BB97 511F BD54
From Steve.Grady@csiro.au Wed Sep 4 02:02:34 2002
From: Steve.Grady@csiro.au (Steve.Grady@csiro.au)
Date: Wed, 4 Sep 2002 11:02:34 +1000
Subject: [parisc-linux] IPL Boot Parameters [Originally SCSI Disks on a K5
80 Help Required]
Message-ID: <49AA3A3C863E5B4C911320AEF99E5DA3010CCCCC@wing-ep.tip.csiro.au>
I have been trying to load debian 3.0 onto my K580 and going around in
circles.
My problem is that I only have disks available that will work on the Single
ended SCSI bus.
The Ultra Wide bus, as has been pointed out previously, is HVD not LVD and I
do not have HVD drives
and they are not easily obtainable at a reasonable price here in Australia.
The PDC will not recognise HD's on the SE bus it will scan them but IMHO the
firmware is set to only
recognise and use the CD and the DDS-3 tape drive. The kernel, booted from
the CD, will recognise the HD
on the SE bus and will load Linux onto the drive but at reboot time I cannot
find the drive.
It was previously suggested that I boot from the tape which I can do using
the following Lif image
lifimage-2.4.18-pa59-PDC-20020728 but this brings me back to the debian
startup screen for HD initialisation
not the script to setup the system (password and extra packages etc).
I have been going around in circles playing with the IPL boot parameters (
like specifying root=/dev/sds3 deleting initrd etc) trying to get it to
continue setup but unsuccessfully.
Does anyone know, using the above LIF image, what IPL boot parameters to
specify to get it to continue an installation on /dev/sda3 root file system.
Or else what do I load on the tape drive ?
Any help would be appreciated or else I will have to get a HVD SCSI drive.
Thanks,
Steve Grady
>
> --- Steve.Grady@csiro.au wrote:
> >
> >
> > > -----Original Message-----
> > > From: Averell Eisner [mailto:a_eisner@eisner.com]
> > > Sent: Monday, 26 August 2002 8:27 AM
> > > To: Steve.Grady@csiro.au
> > > Cc: parisc-linux@lists.parisc-linux.org
> > > Subject: Re: [parisc-linux] SCSI Disks on a K580 Help Required
> > >
> > >
> > > Possible issues:
> > >
> > > "First try." The internal disk drives in the K580 are fast wide
> > > differential. The differential is high voltage differential, not
> > low
> > > voltage differential. Could be that the Maxtor 4.5GB UW is
> > > the wrong type.
> >
> >
> > Well I hope I have not damaged the drive
> >
> >
> > >
> > > "Second try." The normal cable in the K580 that goes to the
> > > tape and CD
> > > only has two open scsi connections plus the terminator. One
> > > connection
> > > for tape, another for the CD. Did you substitute another
> cable with
> > a
> > > third open scsi connection?
> >
> >
> > Yes I substituted another cable (It did not come with any cables,
> > they were
> > removed with the drive)
> > It was properly terminated by an external terminator. As I
> said after
> > boot
> > from the CD a drive on the
> > single ended bus was detected ( and the CD and Tape) by the kernel
> > but was
> > not detected by boot.
> >
> > It has been suggested by someone else (they did not reply to list)
> > that I
> > boot from CD which seems to me
> > the easiest work-around.
> >
> > Thank for the assistance,
> >
> >
> > Steve Grady
> >
> > >
> > > Just guessing.
> > >
> > > Averell
> > > Steve.Grady@csiro.au wrote:
> > >
> > > > Hi,
> > > >
> > > > I got my hands on a K580 Quad processors, 4G Ram, CD, DDS3
> > > Tape drive,
> > > > 2 Fibre Channels on HSC, Dual 100BaseT network
> connectors on HSC,
> > > > FW SCSI on HSC and 2 SCSI interface on HPPB (OK I know the
> > > HPPB is not
> > > > supported)
> > > > but no hard disks.
> > > >
> > > > Previously I have installed PA-Linux on a 735/125.
> > > >
> > > > I am trying to install
> > > palinux-2.4.18-pa59-ppc-20020728-netinstall image on
> > > > the K580
> > > > I am using a variety of SCSI disks I am trying to install
> > > to but I am having
> > > > problems.
> > > >
> > > > The disks are being installed internally on the K580. I
> > > have downloaded the
> > > > users guide
> > > > from docs.hp.com.
> > > >
> > > > First Try
> > > >
> > > > I installed Tape and CD to Single ended bus of the Disk
> > > cage and install a
> > > > Maxtor Altas II
> > > > 4.5G UW to ultra wide bus of Disk Cage and yes the cable
> > > was terminated.
> > > >
> > > > The boot process found the CD, DDS3 but not the disk. I
> > > could boot from CD
> > > > but the installer
> > > > complained about on disk.
> > > >
> > > > Second Try
> > > >
> > > > I installed Tape and CD to Single ended bus of the Disk
> > > cage and install a
> > > > Seagate
> > > > 2.1G SE to SE bus of Disk Cage in parallel with the CD and Tape.
> > > >
> > > > The boot process found the CD, DDS3 but not the disk. I
> > > could boot from CD
> > > > but the installer
> > > > found the disk CD and Tape. I installed to disk and at
> > > reboot boot could not
> > > > find the disk
> > > > only the tape and the CD.
> > > >
> > > > All other trys
> > > >
> > > > I have tried various combinations but have not succeed in
> > > get the boot to
> > > > recognised the
> > > > hard disk. I cannot get Pa-linux to recognised the Ultra
> > > Wide bus which
> > > > leaves me to question
> > > > whether it is supported or do I have a hardware problem.
> > > >
> > > > The Boot reports through its Search for Boot devices
> > > function that it finds
> > > >
> > > > The 2 FC devices
> > > > the Lan (which I assume is the 10BaseT on the Core IO not
> > > the 100BaseT)
> > > > a sequential device (Tape Drive)
> > > > a random device (CD)
> > > >
> > > > The primary boot device at present seems to me to be set up
> > > for the Fibre
> > > > Channel
> > > > (I think the I am not used to the addressing).
> > > >
> > > > I have thought of Rboot or tftboot the K580 from the
> > > 735 and then the
> > > > kernel will
> > > > recognise the disk. But this is not useful in the long
> > > term as I may get
> > > > rid of the 735
> > > > and my Intel box which is my main server as I want to make
> > > the K580 my main
> > > > server.
> > > >
> > > > Any help or suggestions would be appreciated,
> > > >
> > > >
> > > > Steve Grady
> > > >
> > > > BTW Thanks for a great port my little 735 just sits there
> > > and works (mostly
> > > > running SETI)
> > > > _______________________________________________
> > > > parisc-linux mailing list
> > > > parisc-linux@lists.parisc-linux.org
> > > > http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
> > > >
> > > >
> > >
> > >
> > > --
> > > Averell
> > >
> > > Eisner Associates, Inc. Phone: 908-233-6585
> > > 516 North Ave. East FAX: 908-233-0710
> > > P.O. Box 2489
> > > Westfield, NJ 07090
> > >
> > _______________________________________________
> > parisc-linux mailing list
> > parisc-linux@lists.parisc-linux.org
> > http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
>
>
> __________________________________________________
> Do You Yahoo!?
> Yahoo! Finance - Get real-time stock quotes
> http://finance.yahoo.com
>
From tobias_subscriber@tgtools.com Wed Sep 4 03:23:14 2002
From: tobias_subscriber@tgtools.com (Tobias Giesen)
Date: Wed, 4 Sep 2002 04:23:14 +0200
Subject: [parisc-linux] IPL Boot Parameters [Originally SCSI Disks on a K580 Help Required]
In-Reply-To: <49AA3A3C863E5B4C911320AEF99E5DA3010CCCCC@wing-ep.tip.csiro.au>
Message-ID: <001301c253ba$06b20e30$0100a8c0@PLUTO>
> My problem is that I only have disks available that
> will work on the Single ended SCSI bus.
Where did the original hard disk that came with the machine go?
Maybe you can get a small UW SCSI hard disk cheap from eBay or something
like that and use it for the root partition only. A few hundred MB's
would suffice.
Cheers,
Tobias
From Steve.Grady@csiro.au Wed Sep 4 03:37:50 2002
From: Steve.Grady@csiro.au (Steve.Grady@csiro.au)
Date: Wed, 4 Sep 2002 12:37:50 +1000
Subject: [parisc-linux] IPL Boot Parameters [Originally SCSI Disks on
a K580 Help Required]
Message-ID: <49AA3A3C863E5B4C911320AEF99E5DA3010CCCCE@wing-ep.tip.csiro.au>
> -----Original Message-----
> From: Tobias Giesen [mailto:tobias_subscriber@tgtools.com]
> Sent: Wednesday, 4 September 2002 12:23 PM
> To: parisc-linux@lists.parisc-linux.org
> Subject: RE: [parisc-linux] IPL Boot Parameters [Originally SCSI Disks
> on a K580 Help Required]
>
>
> > My problem is that I only have disks available that
> > will work on the Single ended SCSI bus.
>
> Where did the original hard disk that came with the machine go?
I bought the K580 without it I have approached the guy I bought it from to
see if I
can purchase the drive but he has not followed it up yet.
I have looked on ebay but HVD UW SCSI disks are rare most are SCSI-3 LVD/SE
disks
and HVD is not compatible with LVD except by a translator which costs about
$1.5K AUD which
was more than I paid for the K580.
I know I should be able to boot from the tape (maybe I am a masochist) I
think this is my best shot
until I can find a HVD disk, if I can work out to tell the system how.
Thanks,
Steve Grady
>
> Maybe you can get a small UW SCSI hard disk cheap from eBay
> or something
> like that and use it for the root partition only. A few hundred MB's
> would suffice.
>
> Cheers,
> Tobias
>
> _______________________________________________
> parisc-linux mailing list
> parisc-linux@lists.parisc-linux.org
> http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
>
From bruno_vidal@hpfrcu03.france.hp.com Tue Sep 3 17:24:18 2002
From: bruno_vidal@hpfrcu03.france.hp.com (Bruno Vidal)
Date: Tue, 03 Sep 2002 18:24:18 +0200
Subject: [parisc-linux] iodc call and HPMC: dump driver.
References: <3D73014A.15ED96ED@admin.france.hp.com> <20020903045049.E268F4829@dsl2.external.hp.com>
Message-ID: <3D74E232.88B62E31@admin.france.hp.com>
This is a multi-part message in MIME format.
--------------9FA0B36E1D5BF1A98D31930A
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Hi
I'm really surprised, I take a look at HPMC trace, and I was really
surprised of the faulty address. So I try to write on console.
And I m really surprised by the result:
PAGE0->mem_cons.hpa: 0x2000
PAGE0->mem_boot.hpa: 0x900
PAGE0->mem_kbd.hpa: 0xffffffff
It is not good at all !!! It seems to be completly wrong hpa !!!!
The good one for mem_boot.hpa must be: 0xfffffffffed30000 (in my case
according to dmesg and mapio). But the system has boot,
so it was correct a few time ago. I'll retry by using my own
hpa and I'll don't trust anymore PAGE0.
Bye.
--
Vidal Bruno, (770-4271)
SSD-HA Team, HP-UX & LINUX Support
bruno_vidal@admin.france.hp.com
--------------9FA0B36E1D5BF1A98D31930A
Content-Type: text/x-vcard; charset=iso-8859-1;
name="bruno_vidal.vcf"
Content-Transfer-Encoding: base64
Content-Description: Card for Bruno Vidal
Content-Disposition: attachment;
filename="bruno_vidal.vcf"
YmVnaW46dmNhcmQgCm46QnJ1bm87VklEQUwKdGVsO2ZheDowMS02OS04Mi02MC0xNAp0ZWw7
d29yazowMS02OS0yOS00Mi03MQp4LW1vemlsbGEtaHRtbDpUUlVFCnVybDp3d3cuZnJhbmNl
LmhwLmNvbQpvcmc6U29sdXRpb24gQ2VudGVyCnZlcnNpb246Mi4xCmVtYWlsO2ludGVybmV0
OmJydW5vX3ZpZGFsQGhwLmNvbQp0aXRsZTpFeHBlcnQgTG9naWNpZWwgRW52aXJvbm5lbWVu
dCBIYXV0ZSBEaXNwb25pYmlsaXTpCmFkcjtxdW90ZWQtcHJpbnRhYmxlOjs7SFAgRnJhbmNl
PTBEPTBBO1ouQSBkZSBDb3VydGFib2V1ZjsxIEF2LiBkdSBDYW5hZGE7OTE5NDcgTGVzIFVs
aXMgY2VkZXg7RnJhbmNlCngtbW96aWxsYS1jcHQ6OzI2MjA4CmZuOlZJREFMIEJydW5vCmVu
ZDp2Y2FyZAo=
--------------9FA0B36E1D5BF1A98D31930A--
From grundler@dsl2.external.hp.com Wed Sep 4 05:41:09 2002
From: grundler@dsl2.external.hp.com (Grant Grundler)
Date: Tue, 03 Sep 2002 22:41:09 -0600
Subject: [parisc-linux] IPL Boot Parameters [Originally SCSI Disks on a K580 Help Required]
In-Reply-To: Message from Steve.Grady@csiro.au
of "Wed, 04 Sep 2002 12:37:50 +1000." <49AA3A3C863E5B4C911320AEF99E5DA3010CCCCE@wing-ep.tip.csiro.au>
References: <49AA3A3C863E5B4C911320AEF99E5DA3010CCCCE@wing-ep.tip.csiro.au>
Message-ID: <20020904044110.0AF234829@dsl2.external.hp.com>
Steve.Grady@csiro.au wrote:
> and HVD is not compatible with LVD except by a translator which costs
> about $1.5K AUD which was more than I paid for the K580.
I didn't believe you until I found:
http://members.ozemail.com.au/~jwk200/images/paralan -SRP pricelist 2002.pdf
You might try to order HDs here:
http://www.weirdstuff.com/
They've got "Compaq" C2490A and "HP" C2490-60062 (both 2.1GB) for $40.
You want "C2490WD" model - just like Seagate drives have "WD" for HVD.
Or the ST32550WD for $22 seems like a winner:
http://liquidationetc.safeshopper.com/32/15179.htm?103
grant
From grundler@dsl2.external.hp.com Wed Sep 4 05:53:37 2002
From: grundler@dsl2.external.hp.com (Grant Grundler)
Date: Tue, 03 Sep 2002 22:53:37 -0600
Subject: [parisc-linux] iodc call and HPMC: dump driver.
In-Reply-To: Message from Bruno Vidal <bruno_vidal@hpfrcu03.france.hp.com>
of "Tue, 03 Sep 2002 18:24:18 +0200." <3D74E232.88B62E31@admin.france.hp.com>
References: <3D73014A.15ED96ED@admin.france.hp.com> <20020903045049.E268F4829@dsl2.external.hp.com> <3D74E232.88B62E31@admin.france.hp.com>
Message-ID: <20020904045337.1B9894829@dsl2.external.hp.com>
Bruno Vidal wrote:
> This is a multi-part message in MIME format.
> --------------9FA0B36E1D5BF1A98D31930A
> Content-Type: text/plain; charset=us-ascii
> Content-Transfer-Encoding: 7bit
>
> Hi
> I'm really surprised, I take a look at HPMC trace, and I was really
> surprised of the faulty address. So I try to write on console.
> And I m really surprised by the result:
> PAGE0->mem_cons.hpa: 0x2000
> PAGE0->mem_boot.hpa: 0x900
> PAGE0->mem_kbd.hpa: 0xffffffff
Which model machine is this from?
> It is not good at all !!! It seems to be completly wrong hpa !!!!
Note that "hpa" might just be a "handle" and not a real physical address.
It depends on the firmware. Usually it's the physical address though.
I think something else is wrong with your definition or something.
PAGE0 is used in arch/parisc/kernel/firmware.c, inventory.c, pdc_cons.c
and it works in those locations.
> The good one for mem_boot.hpa must be: 0xfffffffffed30000 (in my case
> according to dmesg and mapio). But the system has boot,
No - it doesn't have to be.
> so it was correct a few time ago. I'll retry by using my own
> hpa and I'll don't trust anymore PAGE0.
Well, modify palo to dump interesting page zero values and then
you'll know what they are supposed to be. I'm pretty sure
firmware sets that up.
hth,
grant
From jsoe0708@tiscali.be Wed Sep 4 07:45:39 2002
From: jsoe0708@tiscali.be (jsoe0708@tiscali.be)
Date: Wed, 4 Sep 2002 08:45:39 +0200
Subject: [parisc-linux] Re: Unaligne access [was: Back to evms-1.0.1 && unaligne access && gdb ]
In-Reply-To: <200209032044.g83KiS0d008279@hiauly1.hia.nrc.ca>
Message-ID: <3D3815BD0000B3C0@ocpmta5.be.tiscali.com>
Dave,
>
>
>> >then I'll wager there is padding between the char and int fields
>> >of that struct.
>>
>> That is also what I believe to understand.
>
>Unlikely. The unaligned trap handler in the kernel is probably
>fixing the unaligned access. You need to look in the kernel log
>to see if this is happening.
>
Nothing to notice about unalign access kernel trap in any /var/log files
(with checks.c.new) Is there some "debug" #define to set to increase verbosity
of this trap?
Thanks a lot,
Joel
From jsoe0708@tiscali.be Wed Sep 4 08:14:19 2002
From: jsoe0708@tiscali.be (jsoe0708@tiscali.be)
Date: Wed, 4 Sep 2002 09:14:19 +0200
Subject: [parisc-linux] Re: Unaligne access [was: Back to evms-1.0.1 && unaligne access && gdb ]
In-Reply-To: <20020903203317.C30834829@dsl2.external.hp.com>
Message-ID: <3D3815BD0000B40C@ocpmta5.be.tiscali.com>
>jsoe0708@tiscali.be wrote:
>...
>> And here is some data of my analyse:
>>
>> First surprise in the two case (original checks.c and my checks.c with
>only
>> "if (p->boot_ind != 0x00 && ") p addresses are exactly the same here is
>an
>> example:
>
>...
>> with the checks.c.new:
>> p add: 0x272ee
>> p.boot_ind add: 0x272ee
>> p.head add: 0x272ef
>> p.sector add: 0x272f0
>> p.cyl add: 0x272f1
>> p.sys_ind add: 0x272f2
>> p.end_head add: 0x272f3
>> p.end_sector add: 0x272f4
>> p.end_cyl add: 0x272f5
>> p.start_sect add: 0x272f6
>> p.nr_sects add: 0x272fa
>>
>> What do you think?
>
>checks.c.new will generate a "misaligned access" when "p.start_sect"
>is accessed. 0x272f6 is aligned on 2byte address, not 4 byte.
>Ditto for "p.nr_sects".
>
(now I have understand, well I think :) )
>You sure checks.c.new is referencing 0x272f6 and not something else?
For this I will have to find all call to this function and write p.start_sect
address and content before.
(very tricky problem to surround isn'it ;<) )
>You reviewed dmesg output?
Yes (I have a mincom 'screen' on this system console and I also examine kern.log
as recall Dave)
Many thanks,
Joel
PS: In the mean time I learn that this bug was already fix by:
BOOLEAN isa_null_partition_record(struct partition *p)
{
int i;
u_int8_t *uip = (u_int8_t *) p;
int psize = sizeof(struct partition);
for (i=0; i<psize; i++) {
if (*(uip+i) != 0x00) return FALSE;
}
return TRUE;
}
but not yet comited :?
From rhirst@linuxcare.com Wed Sep 4 07:21:10 2002
From: rhirst@linuxcare.com (Richard Hirst)
Date: Wed, 4 Sep 2002 07:21:10 +0100
Subject: [parisc-linux] Re: PALO-text
In-Reply-To: <20020903125143.5dd1e297.varenet@esiee.fr>
References: <000601c25325$f3bcb080$ad3c179f@tol.ses.alcatel.es> <20020903125143.5dd1e297.varenet@esiee.fr>
Message-ID: <20020904062110.GJ21440@sleepie.demon.co.uk>
On Tue, Sep 03, 2002 at 12:51:43PM +0200, Thibaut VARENE wrote:
> On Tue, 3 Sep 2002 10:43:18 +0200
> "Jorge GOMEZ CABELLO" <jorge.gomez@sanmina-sci.com> wrote:
>
> > Dear Puffin,
> >
> > We are trying to install Debian 3.0 on our HP B2000/785 and it is impossible to recognize the usb keyboard. is there a special commando to introduced in the command line of the palo 1.0 ?
>
> - This reply has been CC'd to the parisc-linux mailing list -
>
> Hi Jorge,
>
> If I remember correctly, the USB support is not enabled by default in the install kernel for Debian 3.0, and B2000 does use a USB keyboard.
> We had such a problem here, and there is a solution: boot and install the box using the following lifimage:
> http://pateam.esiee.fr/cd-images/lifimages/lifimage-2.4.18-pa46-USBSTI64-20020704.gz
> This one has support for USB in both 32/64bit kernels, and what's more, STI console is supported in 64bit kernel. This will allow you to install the box directly with a 64bit kernel.
>
> We may build a more recent lifimage with such USB/STI support soon.
>
> Maybe we can also consider adding at least USB support to the default kernel configuration ? Richard, any comment ? :)
I think we should add usb and 64 bit sti to default and debian configs.
I guess we'll find out soon enough if it casues problems on other
systems.
Maybe it's time we considered an initrd boot process and kernel modules
for some of this stuff. May not be worth the effort in 2.4 though.
Richard
From jorge.gomez@sanmina-sci.com Wed Sep 4 09:13:56 2002
From: jorge.gomez@sanmina-sci.com (Jorge GOMEZ CABELLO)
Date: Wed, 4 Sep 2002 10:13:56 +0200
Subject: [parisc-linux] Re: PALO-text
In-Reply-To: <20020904062110.GJ21440@sleepie.demon.co.uk>
Message-ID: <CFEDIBFJEHPLIGPIJNKAEENFCAAA.jorge.gomez@sanmina-sci.com>
The keyboard works with this lifimage.
Thanks a lot for your colaboration.
Jorge.
-----Mensaje original-----
De: Richard Hirst [mailto:rhirst@linuxcare.com]
Enviado el: miercoles, 04 de septiembre de 2002 8:21
Para: Thibaut VARENE
CC: Jorge GOMEZ CABELLO; parisc-linux@lists.parisc-linux.org
Asunto: Re: [parisc-linux] Re: PALO-text
On Tue, Sep 03, 2002 at 12:51:43PM +0200, Thibaut VARENE wrote:
> On Tue, 3 Sep 2002 10:43:18 +0200
> "Jorge GOMEZ CABELLO" <jorge.gomez@sanmina-sci.com> wrote:
>
> > Dear Puffin,
> >
> > We are trying to install Debian 3.0 on our HP B2000/785 and it is
impossible to recognize the usb keyboard. is there a special commando to
introduced in the command line of the palo 1.0 ?
>
> - This reply has been CC'd to the parisc-linux mailing list -
>
> Hi Jorge,
>
> If I remember correctly, the USB support is not enabled by default in the
install kernel for Debian 3.0, and B2000 does use a USB keyboard.
> We had such a problem here, and there is a solution: boot and install the
box using the following lifimage:
>
http://pateam.esiee.fr/cd-images/lifimages/lifimage-2.4.18-pa46-USBSTI64-200
20704.gz
> This one has support for USB in both 32/64bit kernels, and what's more,
STI console is supported in 64bit kernel. This will allow you to install the
box directly with a 64bit kernel.
>
> We may build a more recent lifimage with such USB/STI support soon.
>
> Maybe we can also consider adding at least USB support to the default
kernel configuration ? Richard, any comment ? :)
I think we should add usb and 64 bit sti to default and debian configs.
I guess we'll find out soon enough if it casues problems on other
systems.
Maybe it's time we considered an initrd boot process and kernel modules
for some of this stuff. May not be worth the effort in 2.4 though.
Richard
From jsoe0708@tiscali.be Wed Sep 4 10:00:27 2002
From: jsoe0708@tiscali.be (jsoe0708@tiscali.be)
Date: Wed, 4 Sep 2002 11:00:27 +0200
Subject: [parisc-linux] Gcc-3.2 beside gcc-3.0: HOWTO?
In-Reply-To: <20020903161326.GI14634@tausq.org>
Message-ID: <3D3815BD0000B51A@ocpmta5.be.tiscali.com>
>> But where is iaoq (I do not found in linux/Documentation/parisc)?
>>
>> here is what I got: grep 101080 /boot/System.map-2.4.19-pa9
>> 10108000 T syscall_exit_rfi
>> 10108064 t intr_return
>> 10108078 t intr_check_resched
>> 10108084 t intr_check_sig
>> 10108090 t intr_restore
>
>is this the system.map from the kernel you are building?
>if it is, then intr_return is the calling function (one up in the
>stack). the function that includes 1010863c is the one that one that's
>causing the fault. that would be one place to look.
>
Hmm the only entry I found concerning intr_return are content into entry.S.
Sorry for the moment I have not enough time to learn parisc asm, how is it
implemented with gcc and how to interface with C, ...
Thanks anyway for all help,
Joel
Big Brother Anders - With Tiscali you will see it all ! Check it up on
www.tiscali.be/bigbrother
From jsoe0708@tiscali.be Wed Sep 4 12:48:47 2002
From: jsoe0708@tiscali.be (jsoe0708@tiscali.be)
Date: Wed, 4 Sep 2002 13:48:47 +0200
Subject: [parisc-linux] Re: Unaligne access [was: Back to evms-1.0.1 && unaligne access && gdb ]
In-Reply-To: <3D3815BD0000B40C@ocpmta5.be.tiscali.com>
Message-ID: <3D53B3B70000AEB5@ocpmta1.be.tiscali.com>
>>jsoe0708@tiscali.be wrote:
>>...
>>> And here is some data of my analyse:
>>>
>>> First surprise in the two case (original checks.c and my checks.c with
>>only
>>> "if (p->boot_ind != 0x00 && ") p addresses are exactly the same here
is
>>an
>>> example:
>>
>>...
>>> with the checks.c.new:
...
>>
>>checks.c.new will generate a "misaligned access" when "p.start_sect"
>>is accessed. 0x272f6 is aligned on 2byte address, not 4 byte.
>>Ditto for "p.nr_sects".
>>
>(now I have understand, well I think :) )
>
>>You sure checks.c.new is referencing 0x272f6 and not something else?
>
>For this I will have to find all call to this function and write p.start_sect
>address and content before.
>
>(very tricky problem to surround isn'it ;<) )
>
And so here is a test (where an unaligne access did not occurs where it would??):
(isa_valid_partition_record) file checks.c
### before the call ###
part.start_sect add: 0x242a6
part.start_sect : 9439488 [1]
part.nr_sects add: 0x242aa
part.nr_sects : 15791872 [2]
### Into the function isa_null_partition_record() ###
p add: 0x2429e
p.boot_ind add: 0x2429e
p.head add: 0x2429f
p.sector add: 0x242a0
p.cyl add: 0x242a1
p.sys_ind add: 0x242a2
p.end_head add: 0x242a3
p.end_sector add: 0x242a4
p.end_cyl add: 0x242a5
p.start_sect add: 0x242a6
p.start_sect : 9439488 [3]
p.nr_sects add: 0x242aa
p.nr_sects : 15791872 [4]
As far as I can see [1] and [3] (as well as [2] and [4]) seems to show that
it point actualy to the same thing.
And here is an other sample:
(isa_valid_partition_record) file checks.c
part.start_sect add: 0x24556
part.start_sect : 536870912
part.nr_sects add: 0x2455a
part.nr_sects : 3768004864
p add: 0x2454e
p.boot_ind add: 0x2454e
p.head add: 0x2454f
p.sector add: 0x24550
p.cyl add: 0x24551
p.sys_ind add: 0x24552
p.end_head add: 0x24553
p.end_sector add: 0x24554
p.end_cyl add: 0x24555
p.start_sect add: 0x24556
p.start_sect : 536870912
p.nr_sects add: 0x2455a
p.nr_sects : 3768004864
p add: 0x2454e
p.boot_ind add: 0x2454e
p.head add: 0x2454f
p.sector add: 0x24550
p.cyl add: 0x24551
p.sys_ind add: 0x24552
p.end_head add: 0x24553
p.end_sector add: 0x24554
p.end_cyl add: 0x24555
p.start_sect add: 0x24556
p.start_sect : 536870912
p.nr_sects add: 0x2455a
p.nr_sects : 3768004864
Joel
Big Brother Anders - With Tiscali you will see it all ! Check it up on
www.tiscali.be/bigbrother
From dreamind@dreamind.de Wed Sep 4 15:30:13 2002
From: dreamind@dreamind.de (Stefan Pfetzing)
Date: Wed, 4 Sep 2002 16:30:13 +0200
Subject: [parisc-linux] XFS - blkgetsize64
Message-ID: <20020904143013.GC4386@dreamind.de>
Hi,
I just tried to get XFS working on my C200 (I've got a new IBM SCSI disk.) and
mkfs.xfs always got the size of the Device (/dev/sda5) wrong. (it complained
about not getting with lseek64 to that position...)
(I don't have the correct error message ready, but I can check, if its needed)
After I changed the libxfs to only use the BLKGETSIZE64 ioctl, it works fine
now. (Eric Sandeen pointed me to this)
So he said, perhaps there is a bug in the SCSI (lasi?) driver.
bye
Stefan
P.S.: I'm using 2.4.19-pa9 with a self made diff from vanilla 2.4.19 against
XFS CVS. (the patch did in nearly cleanly)
--
http://www.dreamind.de/
Oroborus and Debian GNU/Linux Developer.
From Randolph Chung <randolph@tausq.org> Wed Sep 4 15:55:36 2002
From: Randolph Chung <randolph@tausq.org> (Randolph Chung)
Date: Wed, 4 Sep 2002 07:55:36 -0700
Subject: [parisc-linux] Re: Unaligne access [was: Back to evms-1.0.1 && unaligne access && gdb ]
In-Reply-To: <3D3815BD0000B3C0@ocpmta5.be.tiscali.com>
References: <200209032044.g83KiS0d008279@hiauly1.hia.nrc.ca> <3D3815BD0000B3C0@ocpmta5.be.tiscali.com>
Message-ID: <20020904145536.GA8310@tausq.org>
> >Unlikely. The unaligned trap handler in the kernel is probably
> >fixing the unaligned access. You need to look in the kernel log
> >to see if this is happening.
> >
> Nothing to notice about unalign access kernel trap in any /var/log files
> (with checks.c.new) Is there some "debug" #define to set to increase verbosity
> of this trap?
no, it will log by default.. nothing to configure.
randolph
--
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/
From grundler@dsl2.external.hp.com Wed Sep 4 17:51:47 2002
From: grundler@dsl2.external.hp.com (Grant Grundler)
Date: Wed, 04 Sep 2002 10:51:47 -0600
Subject: [parisc-linux] XFS - blkgetsize64
In-Reply-To: Message from Stefan Pfetzing <dreamind@dreamind.de>
of "Wed, 04 Sep 2002 16:30:13 +0200." <20020904143013.GC4386@dreamind.de>
References: <20020904143013.GC4386@dreamind.de>
Message-ID: <20020904165147.A33FC4829@dsl2.external.hp.com>
Stefan Pfetzing wrote:
> mkfs.xfs always got the size of the Device (/dev/sda5) wrong. (it complained
> about not getting with lseek64 to that position...)
...
> So he said, perhaps there is a bug in the SCSI (lasi?) driver.
I don't think it's the driver.
lseek64 must be getting redirected to lseek().
Linux kernel only supports "lseek".
See "struct file_operations" in include/linux/fs.h.
loff_t is a 64-bit type.
include/linux/types.h:typedef __kernel_loff_t loff_t;
include/asm/posix_types.h:typedef long long __kernel_loff_t;
> P.S.: I'm using 2.4.19-pa9 with a self made diff from vanilla 2.4.19 against
> XFS CVS. (the patch did in nearly cleanly)
Are you running 32-bit or 64-bit kernel?
I want to know if arch/parisc/kernel/sys_parisc32.c might be the problem.
grant
From varenet@esiee.fr Wed Sep 4 18:55:20 2002
From: varenet@esiee.fr (Thibaut VARENE)
Date: Wed, 4 Sep 2002 19:55:20 +0200
Subject: [parisc-linux] Re: PALO-text
In-Reply-To: <20020904062110.GJ21440@sleepie.demon.co.uk>
Message-ID: <7A991B84-C02F-11D6-8BC6-0030656F07A2@esiee.fr>
Le mercredi 4 septembre 2002, =E0 08:21 , Richard Hirst a =E9crit :
> On Tue, Sep 03, 2002 at 12:51:43PM +0200, Thibaut VARENE wrote:
>> On Tue, 3 Sep 2002 10:43:18 +0200
>> "Jorge GOMEZ CABELLO" <jorge.gomez@sanmina-sci.com> wrote:
>>
>>> Dear Puffin,
>>>
>>> We are trying to install Debian 3.0 on our HP B2000/785 and it =
is=20
>>> impossible to recognize the usb keyboard. is there a special =
commando=20
>>> to introduced in the command line of the palo 1.0 ?
>>
>> - This reply has been CC'd to the parisc-linux mailing list -
>>
>> Hi Jorge,
>>
>> If I remember correctly, the USB support is not enabled by default in=20=
>> the install kernel for Debian 3.0, and B2000 does use a USB keyboard.
>> We had such a problem here, and there is a solution: boot and install=20=
>> the box using the following lifimage:
>> http://pateam.esiee.fr/cd-
>> images/lifimages/lifimage-2.4.18-pa46-USBSTI64-20020704.gz
>> This one has support for USB in both 32/64bit kernels, and what's=20
>> more, STI console is supported in 64bit kernel. This will allow you =
to=20
>> install the box directly with a 64bit kernel.
>>
>> We may build a more recent lifimage with such USB/STI support soon.
>>
>> Maybe we can also consider adding at least USB support to the default=20=
>> kernel configuration ? Richard, any comment ? :)
>
> I think we should add usb and 64 bit sti to default and debian =
configs.
> I guess we'll find out soon enough if it casues problems on other
> systems.
Done: support for USB input has been added as default for both 32 and 64=20=
bit kernel,
and support for both STI_CONSOLE and STI_FB has beed added as default=20
for 64 bit kernel,
since -pa10.
pa10 netinst/lifimage are available on=20
http://pateam.esiee.fr/download.html
(and soon on dsl2) :)
Feedback would be appreciated.
>
> Maybe it's time we considered an initrd boot process and kernel =
modules
> for some of this stuff. May not be worth the effort in 2.4 though.
>
> Richard
>
>
Thibaut VARENE
PA/Linux ESIEE Team
http://pateam.esiee.fr/
From Randolph Chung <randolph@tausq.org> Wed Sep 4 19:11:56 2002
From: Randolph Chung <randolph@tausq.org> (Randolph Chung)
Date: Wed, 4 Sep 2002 11:11:56 -0700
Subject: [parisc-linux] XFS - blkgetsize64
In-Reply-To: <20020904165147.A33FC4829@dsl2.external.hp.com>
References: <20020904143013.GC4386@dreamind.de> <20020904165147.A33FC4829@dsl2.external.hp.com>
Message-ID: <20020904181156.GJ17893@tausq.org>
> I don't think it's the driver.
no, not the driver...
> lseek64 must be getting redirected to lseek().
> Linux kernel only supports "lseek".
lseek64 is translated to a sys_llseek (you can see that with strace).
> See "struct file_operations" in include/linux/fs.h.
> loff_t is a 64-bit type.
> include/linux/types.h:typedef __kernel_loff_t loff_t;
> include/asm/posix_types.h:typedef long long __kernel_loff_t;
we need to do some tricks to get this right ... some of the other
syscalls are fixed, but this one is not it seems.
> I want to know if arch/parisc/kernel/sys_parisc32.c might be the problem.
fwiw sys_llseek is not translated.
randolph
From dreamind@dreamind.de Wed Sep 4 19:28:14 2002
From: dreamind@dreamind.de (Stefan Pfetzing)
Date: Wed, 4 Sep 2002 20:28:14 +0200
Subject: [parisc-linux] XFS - blkgetsize64
In-Reply-To: <20020904165147.A33FC4829@dsl2.external.hp.com>
References: <20020904143013.GC4386@dreamind.de> <20020904165147.A33FC4829@dsl2.external.hp.com>
Message-ID: <20020904182814.GA17156@dreamind.de>
Hi,
* Grant Grundler <grundler@dsl2.external.hp.com> [020904 18:51]:
> Stefan Pfetzing wrote:
[snip]
> > P.S.: I'm using 2.4.19-pa9 with a self made diff from vanilla 2.4.19 against
> > XFS CVS. (the patch did in nearly cleanly)
>
> Are you running 32-bit or 64-bit kernel?
> I want to know if arch/parisc/kernel/sys_parisc32.c might be the problem.
I'm running a 32bit kernel, since some time ago I had problems with 64bit and
cdrecord.
bye
Stefan
--
http://www.dreamind.de/
Oroborus and Debian GNU/Linux Developer.
From dave@hiauly1.hia.nrc.ca Wed Sep 4 19:42:59 2002
From: dave@hiauly1.hia.nrc.ca (John David Anglin)
Date: Wed, 4 Sep 2002 14:42:59 -0400 (EDT)
Subject: [parisc-linux] GCC and quad-precision floating point
In-Reply-To: <20020904181156.GJ17893@tausq.org> from "Randolph Chung" at Sep 4, 2002 11:11:56 am
Message-ID: <200209041842.g84Igx2n011400@hiauly1.hia.nrc.ca>
I have just implemented some fixes and changed the long double size
to 128 bits on the hppa64 GCC ports. For parisc-linux, the long double
support should be 128 bits (both for 32 and 64 bit) but we are currently
stuck at 64 bits because we are missing a bunch of quad library calls:
_U_Qfadd, _U_Qfsub, _U_Qfmpy, _U_Qfdiv, _U_Qfneg, _U_Qfsqrt, _U_Qfabs,
_U_Qfmin, _U_Qfmax, _U_Qfcnvff_sgl_to_quad, _U_Qfcnvff_dbl_to_quad,
_U_Qfcnvff_quad_to_sgl, _U_Qfcnvff_quad_to_dbl, _U_Qfcnvxf_sgl_to_quad,
_U_Qfcnvxf_dbl_to_quad, _U_Qfcnvfxt_quad_to_sgl, _U_Qfcnvfxt_quad_to_usgl,
_U_Qfcnvfxt_quad_to_udbl, _U_Qfcnvfxt_quad_to_dbl, _U_Qfeq, _U_Qfne,
_U_Qfgt, _U_Qfge, _U_Qflt, _U_Qfle.
There are probably some more for unordered comparisons.
Any chance that someone with contacts inside HP, might be able to
obtain the source code for these functions? They are really part
of the ABI.
While it's relatively straightforward to implement these using the
quad-precision instructions in the PA 2.0 architecture for the 64-bit
port, it's non trivial to implement them for earlier architectures
using the 32-bit port.
Dave
--
J. David Anglin dave.anglin@nrc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6605)
From carlos@baldric.uwo.ca Wed Sep 4 20:15:17 2002
From: carlos@baldric.uwo.ca (Carlos O'Donell)
Date: Wed, 4 Sep 2002 15:15:17 -0400
Subject: [parisc-linux] GCC and quad-precision floating point
In-Reply-To: <200209041842.g84Igx2n011400@hiauly1.hia.nrc.ca>
References: <20020904181156.GJ17893@tausq.org> <200209041842.g84Igx2n011400@hiauly1.hia.nrc.ca>
Message-ID: <20020904191517.GB6702@systemhalted>
> I have just implemented some fixes and changed the long double size
> to 128 bits on the hppa64 GCC ports. For parisc-linux, the long double
> support should be 128 bits (both for 32 and 64 bit) but we are currently
> stuck at 64 bits because we are missing a bunch of quad library calls:
>
> _U_Qfadd, _U_Qfsub, _U_Qfmpy, _U_Qfdiv, _U_Qfneg, _U_Qfsqrt, _U_Qfabs,
> _U_Qfmin, _U_Qfmax, _U_Qfcnvff_sgl_to_quad, _U_Qfcnvff_dbl_to_quad,
> _U_Qfcnvff_quad_to_sgl, _U_Qfcnvff_quad_to_dbl, _U_Qfcnvxf_sgl_to_quad,
> _U_Qfcnvxf_dbl_to_quad, _U_Qfcnvfxt_quad_to_sgl, _U_Qfcnvfxt_quad_to_usgl,
> _U_Qfcnvfxt_quad_to_udbl, _U_Qfcnvfxt_quad_to_dbl, _U_Qfeq, _U_Qfne,
> _U_Qfgt, _U_Qfge, _U_Qflt, _U_Qfle.
>
> There are probably some more for unordered comparisons.
>
> Any chance that someone with contacts inside HP, might be able to
> obtain the source code for these functions? They are really part
> of the ABI.
>
> While it's relatively straightforward to implement these using the
> quad-precision instructions in the PA 2.0 architecture for the 64-bit
> port, it's non trivial to implement them for earlier architectures
> using the 32-bit port.
>
> Dave
Randolph and I were discussing borrowing from gmp to implement some of
these for the earlier 32-bit processors. Thought it seems that this may
break the HPUX compatibility?
gmp seems to have support for:
add, sub, multiply, div, neg, sqrt, abs, min, max
equals, not-equals, greater-than, greather-than-or-equal,
less-than, less-than-or-equal.
The 'cnv' functions need to be addressed:
single -> quad
double -> quad
quad -> single
quad -> double
quad -> unsigned single
quad -> unsigned double
Under certain conditions of float-float, float-fixed, float-fixed&truncate.
This will have to follow the HPUX convention?
c.
From dave@hiauly1.hia.nrc.ca Wed Sep 4 20:59:27 2002
From: dave@hiauly1.hia.nrc.ca (John David Anglin)
Date: Wed, 4 Sep 2002 15:59:27 -0400 (EDT)
Subject: [parisc-linux] GCC and quad-precision floating point
In-Reply-To: <20020904191517.GB6702@systemhalted> from "Carlos O'Donell" at Sep 4, 2002 03:15:17 pm
Message-ID: <200209041959.g84JxRRH011794@hiauly1.hia.nrc.ca>
> Randolph and I were discussing borrowing from gmp to implement some of
> these for the earlier 32-bit processors. Thought it seems that this may
> break the HPUX compatibility?
I would guess that that the best compatibility would be obtained with
the HP functions. As far as I can tell, gmp does not use IEEE standard
data types. Thus, concepts of nans, snans, unordered if present at
all in gmp would differ.
GCC can only deal with floating data in IEEE format. So, conversion
would have to be done for all operations.
I presume that the HPUX compatibility is just for static binaries
(i.e., there is no shared library support). In this case, the routines
would be compiled into hpux binaries. So, I don't think much additional
would be needed at an os level.
Dave
--
J. David Anglin dave.anglin@nrc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6605)
From dreamind@dreamind.de Wed Sep 4 21:57:44 2002
From: dreamind@dreamind.de (Stefan Pfetzing)
Date: Wed, 4 Sep 2002 22:57:44 +0200
Subject: [parisc-linux] XFS - blkgetsize64
In-Reply-To: <20020904182814.GA17156@dreamind.de>
References: <20020904143013.GC4386@dreamind.de> <20020904165147.A33FC4829@dsl2.external.hp.com> <20020904182814.GA17156@dreamind.de>
Message-ID: <20020904205744.GA29749@dreamind.de>
Hum, replying to myself...
* Stefan Pfetzing <dreamind@dreamind.de> [020904 20:28]:
> * Grant Grundler <grundler@dsl2.external.hp.com> [020904 18:51]:
> > Stefan Pfetzing wrote:
> [snip]
> > > P.S.: I'm using 2.4.19-pa9 with a self made diff from vanilla 2.4.19 against
> > > XFS CVS. (the patch did in nearly cleanly)
> >
> > Are you running 32-bit or 64-bit kernel?
> > I want to know if arch/parisc/kernel/sys_parisc32.c might be the problem.
> I'm running a 32bit kernel, since some time ago I had problems with 64bit and
> cdrecord.
I just got a blkgetsize* testprogram...
(https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=62038)
---snip---
root@hp:~# ./blkgetsizetester /dev/sda2
Device size is 83968 blocks (42991616 bytes)
Device size per BLKGETSIZE64 is 12345 bytes
root@hp:~# ./blkgetsizetester /dev/sda5
Device size is 1026016 blocks (525320192 bytes)
Device size per BLKGETSIZE64 is 12345 bytes
root@hp:~#
---snip---
I think thats the problem with xfs... well at least blkgetsize64 should report
an error, if its not working correctly.
bye
Stefan
--
http://www.dreamind.de/
Oroborus and Debian GNU/Linux Developer.
From derekengelhaupt@rocketmail.com Thu Sep 5 01:13:45 2002
From: derekengelhaupt@rocketmail.com (Derek Engelhaupt)
Date: Wed, 4 Sep 2002 17:13:45 -0700 (PDT)
Subject: [parisc-linux] IPL Boot Parameters [Originally SCSI Disks on a K580 Help Required]
In-Reply-To: <20020904044110.0AF234829@dsl2.external.hp.com>
Message-ID: <20020905001345.94888.qmail@web12501.mail.yahoo.com>
All good advice Grant "except" about buying a C2490A drive....DON'T. I
replace them constantly. Forgive my language....they are #@$%. They
are unreliable at best and loud. Heck I have (5) C2490A's sitting in
my garage in an old HP 6000 Fast/Wide enclosure. I'll probably never
use them. You could put 4 of them on the internal cable of your K580
and have the 5th as spare. I'd let you have all of them for $40 plus
shipping. Just keep good back-ups if you use them.....;)
derek
--- Grant Grundler <grundler@dsl2.external.hp.com> wrote:
> Steve.Grady@csiro.au wrote:
> > and HVD is not compatible with LVD except by a translator which
> costs
> > about $1.5K AUD which was more than I paid for the K580.
>
> I didn't believe you until I found:
> http://members.ozemail.com.au/~jwk200/images/paralan -SRP pricelist
> 2002.pdf
>
> You might try to order HDs here:
> http://www.weirdstuff.com/
>
> They've got "Compaq" C2490A and "HP" C2490-60062 (both 2.1GB) for
> $40.
> You want "C2490WD" model - just like Seagate drives have "WD" for
> HVD.
>
> Or the ST32550WD for $22 seems like a winner:
> http://liquidationetc.safeshopper.com/32/15179.htm?103
>
> grant
> _______________________________________________
> parisc-linux mailing list
> parisc-linux@lists.parisc-linux.org
> http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
__________________________________________________
Do You Yahoo!?
Yahoo! Finance - Get real-time stock quotes
http://finance.yahoo.com
From Randolph Chung <randolph@tausq.org> Thu Sep 5 05:38:21 2002
From: Randolph Chung <randolph@tausq.org> (Randolph Chung)
Date: Wed, 4 Sep 2002 21:38:21 -0700
Subject: [parisc-linux] XFS - blkgetsize64
In-Reply-To: <20020904205744.GA29749@dreamind.de>
References: <20020904143013.GC4386@dreamind.de> <20020904165147.A33FC4829@dsl2.external.hp.com> <20020904182814.GA17156@dreamind.de> <20020904205744.GA29749@dreamind.de>
Message-ID: <20020905043821.GC8310@tausq.org>
> I just got a blkgetsize* testprogram...
> (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=62038)
the test program has a nasty bug in it...
#define BLKGETSIZE64 _IOR(0x12,114,sizeof(unsigned long long)) /* return device
that's wrong.. it should be
#define BLKGETSIZE64 _IOR(0x12,114,unsigned long long) /* return device
randolph
--
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/
From grundler@dsl2.external.hp.com Thu Sep 5 06:22:11 2002
From: grundler@dsl2.external.hp.com (Grant Grundler)
Date: Wed, 04 Sep 2002 23:22:11 -0600
Subject: [parisc-linux] IPL Boot Parameters [Originally SCSI Disks on a K580 Help Required]
In-Reply-To: Message from Derek Engelhaupt <derekengelhaupt@rocketmail.com>
of "Wed, 04 Sep 2002 17:13:45 PDT." <20020905001345.94888.qmail@web12501.mail.yahoo.com>
References: <20020905001345.94888.qmail@web12501.mail.yahoo.com>
Message-ID: <20020905052211.9C5AE4829@dsl2.external.hp.com>
Derek Engelhaupt wrote:
> All good advice Grant "except" about buying a C2490A drive....DON'T.
no offense taken. I've seen more than my fair share of ugly problems
with that drive as well. The HP division that produced those was shut
down around the time those drives reached "end of product life".
I only suggested them because they were supported in the Kclass.
grant
From Randolph Chung <randolph@tausq.org> Thu Sep 5 06:28:13 2002
From: Randolph Chung <randolph@tausq.org> (Randolph Chung)
Date: Wed, 4 Sep 2002 22:28:13 -0700
Subject: [parisc-linux] XFS - blkgetsize64
In-Reply-To: <20020904143013.GC4386@dreamind.de>
References: <20020904143013.GC4386@dreamind.de>
Message-ID: <20020905052813.GD8310@tausq.org>
> I just tried to get XFS working on my C200 (I've got a new IBM SCSI disk.) and
> mkfs.xfs always got the size of the Device (/dev/sda5) wrong. (it complained
> about not getting with lseek64 to that position...)
64-bit kernel:
tausq@gsyprf11:~$ ls -l tst
-r-x--xr-- 1 tausq tausq 1099511627777 Sep 4 22:18 tst*
tausq@gsyprf11:~$ ./tt tst
lseek64(3,0,SEEK_END) = 1048576M
on my gecko (32-bit)
randolph@frodo:~$ sudo ./t /dev/sda3
lseek64(3,0,SEEK_END) = 1949M
seems to work ok?
randolph
--
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/
From derekengelhaupt@rocketmail.com Thu Sep 5 06:39:46 2002
From: derekengelhaupt@rocketmail.com (Derek Engelhaupt)
Date: Wed, 4 Sep 2002 22:39:46 -0700 (PDT)
Subject: [parisc-linux] IPL Boot Parameters [Originally SCSI Disks on a K580 Help Required]
In-Reply-To: <20020905052211.9C5AE4829@dsl2.external.hp.com>
Message-ID: <20020905053946.7697.qmail@web12504.mail.yahoo.com>
The really only "good" thing about them is you can usually tell when
they are about to go bad by the strange sounds they make....;)
derek
--- Grant Grundler <grundler@dsl2.external.hp.com> wrote:
> Derek Engelhaupt wrote:
> > All good advice Grant "except" about buying a C2490A
> drive....DON'T.
>
> no offense taken. I've seen more than my fair share of ugly problems
> with that drive as well. The HP division that produced those was
> shut
> down around the time those drives reached "end of product life".
>
> I only suggested them because they were supported in the Kclass.
>
> grant
> _______________________________________________
> parisc-linux mailing list
> parisc-linux@lists.parisc-linux.org
> http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
__________________________________________________
Do You Yahoo!?
Yahoo! Finance - Get real-time stock quotes
http://finance.yahoo.com
From herrold@owlriver.com Thu Sep 5 06:53:38 2002
From: herrold@owlriver.com (R P Herrold)
Date: Thu, 5 Sep 2002 01:53:38 -0400 (EDT)
Subject: [parisc-linux] IPL Boot Parameters [Originally SCSI Disks on a
K580 Help Required]
In-Reply-To: <20020905053946.7697.qmail@web12504.mail.yahoo.com>
Message-ID: <Pine.LNX.4.44.0209050151120.30421-100000@swampfox.owlriver.com>
On Wed, 4 Sep 2002, Derek Engelhaupt wrote:
> The really only "good" thing about them is you can usually tell when
> they are about to go bad by the strange sounds they make....;)
As I have been talking a customer (new CIO's first alligator
wrestle) through 'revivng'a K-220 with a dead boot drive
[error: WARN A008 == no more boot drive], and no 'ignite'
tape, from 300 miles away, hearing it was not really possible
<grin>
-- Russ Herrold
From wins@public.xa.sn.cn Thu Sep 5 08:45:42 2002
From: wins@public.xa.sn.cn (wang lan)
Date: Thu, 5 Sep 2002 15:45:42 +0800
Subject: [parisc-linux] shoes, boots, footwear
Message-ID: <20020905074545.95A68485E@dsl2.external.hp.com>
If you deal with work shoes and boots, please visit the website for cheaper and good quality:
www.wins-chinaboots.com
The site is a source for importers and distributors not for retail.
Sorry for disturbing you.
Regards
Wentao
From jsoe0708@tiscali.be Thu Sep 5 14:30:13 2002
From: jsoe0708@tiscali.be (jsoe0708@tiscali.be)
Date: Thu, 5 Sep 2002 15:30:13 +0200
Subject: [parisc-linux] upgrade evms-1.1.0 -> Kernel bug at blkpg.c (need help)
Message-ID: <3D53B3B70000BC9B@ocpmta1.be.tiscali.com>
Hi Willy,
Do you remember this.
> On Wed, Aug 21, 2002 at 05:14:28PM +0200, jsoe0708@tiscali.be wrote:
> > After this upgarde, all evms tools failled and I got folowing kernel
message
> > at the console:
> > kernel BUG at blkpg.c:252!
> > evms: ldev_mgr: error(-28): creating logical disk for device(8,0).
> >
> > at line 250 of /drivers/block/blkpg.c I read:
> > ...
> > return put_user(uulval << 9, (u64 *)arg);
> > ...
>
> Aw, crap. It now seems to be `legal' to put_user a 64-bit argument on
a
> 32-bit system. Someone needs to fix this in include/asm-parisc/uaccess.h
May I suggest a trivial sol:
in put_user, case 8 uses something like as:
__put_user_asm("stw",(unsigned int)(x >> 32), (unsigned int) ptr);__put_user_asm("stw",(unsigned
int) x, (unsigned int) (ptr+1) );
or is it in the contrary order (I am not familiar with SE and BE conversion)
Thanks for attention,
Joel
Big Brother Anders - With Tiscali you will see it all ! Check it up on
www.tiscali.be/bigbrother
From bdhilton@charter.net Thu Sep 5 22:49:55 2002
From: bdhilton@charter.net (B. Douglas Hilton)
Date: Thu, 05 Sep 2002 17:49:55 -0400
Subject: [parisc-linux] C200 Voodoo2 Progress Report
Message-ID: <3D77D183.2080905@charter.net>
I have gotten my C200 back online and started some preliminary
work with the Voodoo2 PCI card. I currently have it plugged into
one of the 5V/32bit slots which may or may not be optimal.
Anyways,
1. Linux Kernel 2.4.19-pa2 sstfb Voodoo1/2 framebuffer
Well, the kernel compiled with the sstfb without
any errors. When I booted I got a black and white
checkerboard pattern on the Voodoo2 monitor. I had
disabled the stifb console, thinking that the kernel
might pick the sstfb for a console, but it didn't.
Just blankness for a while, then a checkerboard
pattern.
I think this is encouraging and I think it is working.
I'm currently recompiling and will post some more news
later as I experiment some more with it. Next I will
try and put a console on the sstfb or even try running
X on it.
2. glide3-alpha-0.cvs.20010711
This is the Debian source for Glide3 on the Alpha arch,
which is also big-endian. Initial compilation failed in
multiple places about missing sys/io.h which I have
located a file of that name in /usr/include/asm. I'll
see if I can figure out how best to correct this and try
again.
Cheers!
- Doug
From derekengelhaupt@rocketmail.com Thu Sep 5 22:58:17 2002
From: derekengelhaupt@rocketmail.com (Derek Engelhaupt)
Date: Thu, 5 Sep 2002 14:58:17 -0700 (PDT)
Subject: [parisc-linux] C200 Voodoo2 Progress Report
In-Reply-To: <3D77D183.2080905@charter.net>
Message-ID: <20020905215817.13651.qmail@web12505.mail.yahoo.com>
And I'm just happy that I got X/KDE to work on the built in graphics
card on my C180...finally. Keep it up since I have a Voodoo2 available
to try on my C180 if you're successful.
derek
--- "B. Douglas Hilton" <bdhilton@charter.net> wrote:
> I have gotten my C200 back online and started some preliminary
> work with the Voodoo2 PCI card. I currently have it plugged into
> one of the 5V/32bit slots which may or may not be optimal.
>
> Anyways,
>
> 1. Linux Kernel 2.4.19-pa2 sstfb Voodoo1/2 framebuffer
>
> Well, the kernel compiled with the sstfb without
> any errors. When I booted I got a black and white
> checkerboard pattern on the Voodoo2 monitor. I had
> disabled the stifb console, thinking that the kernel
> might pick the sstfb for a console, but it didn't.
> Just blankness for a while, then a checkerboard
> pattern.
>
> I think this is encouraging and I think it is working.
> I'm currently recompiling and will post some more news
> later as I experiment some more with it. Next I will
> try and put a console on the sstfb or even try running
> X on it.
>
>
> 2. glide3-alpha-0.cvs.20010711
>
> This is the Debian source for Glide3 on the Alpha arch,
> which is also big-endian. Initial compilation failed in
> multiple places about missing sys/io.h which I have
> located a file of that name in /usr/include/asm. I'll
> see if I can figure out how best to correct this and try
> again.
>
>
> Cheers!
> - Doug
>
>
> _______________________________________________
> parisc-linux mailing list
> parisc-linux@lists.parisc-linux.org
> http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
__________________________________________________
Do You Yahoo!?
Yahoo! Finance - Get real-time stock quotes
http://finance.yahoo.com
From tobias_subscriber@tgtools.com Fri Sep 6 00:15:30 2002
From: tobias_subscriber@tgtools.com (Tobias Giesen)
Date: Fri, 6 Sep 2002 01:15:30 +0200
Subject: [parisc-linux] C200 Voodoo2 Progress Report
In-Reply-To: <3D77D183.2080905@charter.net>
Message-ID: <004f01c25532$221c4900$7cf98450@PLUTO>
Doug,
thanks very much for the report! Looking forward to trying this myself.
> Next I will try and put a console on
> the sstfb or even try running X on it.
X via frame buffer would be great, I'll be happy
to work without glide.
Cheers,
Tobias
From willy@debian.org Fri Sep 6 03:46:56 2002
From: willy@debian.org (Matthew Wilcox)
Date: Fri, 6 Sep 2002 03:46:56 +0100
Subject: [parisc-linux] Re: C200 Voodoo2 Progress Report
In-Reply-To: <3D77D183.2080905@charter.net>; from bdhilton@charter.net on Thu, Sep 05, 2002 at 05:49:55PM -0400
References: <3D77D183.2080905@charter.net>
Message-ID: <20020906034656.A26580@parcelfarce.linux.theplanet.co.uk>
On Thu, Sep 05, 2002 at 05:49:55PM -0400, B. Douglas Hilton wrote:
> This is the Debian source for Glide3 on the Alpha arch,
> which is also big-endian. Initial compilation failed in
nope. alpha is little-endian.
LE: alpha, arm, cris, i386, ia64, superh
BE: m68k, mips, parisc, ppc, s390, sparc
(yes, i know many of these CPUs are bi-endian, but these are the default
configs)
--
Revolutions do not require corporate support.
From nneul@umr.edu Fri Sep 6 14:44:17 2002
From: nneul@umr.edu (Neulinger, Nathan)
Date: Fri, 6 Sep 2002 08:44:17 -0500
Subject: [parisc-linux] status of parisc_linux24 openafs port
Message-ID: <34D7FB33F420654EB583492E10C8AA0709DDA7@umr-mail6.umr.edu>
Current status of the parisc_linux24 port:
A couple of patches are sitting in RT waiting to be applied to fix up
the user space LWP build for this platform. Once those are applied,
almost all of the user space tools build cleanly. (I have not tested
them, but I'd expect the file/vol/pt servers to work.) The other user
space tools I have tested all work great.=20
The kernel module builds cleanly, however, there seems to be a problem
with linking the module on palinux.=20
For testing, I've ifdef'd out anything in osi_module.c and afs_osi.c
that actually does anything, so that afs_init at this point is limited
to simply calling osi_Init(), which in turn does nothing.=20
If I hand link a module containing only afs_osi.o and osi_module.o, I am
able to load/unload it without any trouble at all. However, as soon as I
link in all the other .o files (which should have no other effect beyond
increasing the size of the module and adding a pile of code that will
never be called), insmod segv's on module load somewhere in the
branch/call to osi_Init(). So obviously there is some problem with what
is generated by the linker that is causing it to flip out.
Only other possibility would be that there is a conflict with the name
of another routine in the .o's that is overlapping a critical
module-initialization function used by parisc_linux24, and not by other
linux platforms...=20
Any ideas?
-- Nathan
------------------------------------------------------------
Nathan Neulinger EMail: nneul@umr.edu
University of Missouri - Rolla Phone: (573) 341-4841
Computing Services Fax: (573) 341-4216
From James S" <smithjames@comcast.net Fri Sep 6 14:44:29 2002
From: James S" <smithjames@comcast.net (James S)
Date: Fri, 6 Sep 2002 08:44:29 -0500
Subject: [parisc-linux] Formatting Scsi disks
References: <20020902234752.GA6718@systemhalted>
Message-ID: <005201c255ab$a3bf7f80$02c1a8c0@james.co.uk>
I had an odd thing happen.....
i took a disk out of a 712 & had it in a mac for a while
when i put it back into the 712, & tried to put linux back on it, it got as
far as fdisk which then said that it couldnt write a partition table to it
the disk still works in the mac - am i missing something daft here ?
the search command from the boot console on the 712 sees the disk
the kernel sees & correctly identifies the disk
just wont partition it
any ideas?
James S
From Jurriaan.Kalkman@zrt.nl Fri Sep 6 15:00:22 2002
From: Jurriaan.Kalkman@zrt.nl (Jurriaan Kalkman)
Date: Fri, 06 Sep 2002 16:00:22 +0200
Subject: Betr.: [parisc-linux] Formatting Scsi disks
Message-ID: <sd78d3a1.013@ms-zrt1>
>I had an odd thing happen.....
>
>i took a disk out of a 712 & had it in a mac for a while
>when i put it back into the 712, & tried to put linux back on it, it got =
as
>far as fdisk which then said that it couldnt write a partition table to =
it
>
>the disk still works in the mac - am i missing something daft here ?
>
>the search command from the boot console on the 712 sees the disk
>the kernel sees & correctly identifies the disk
>
>just wont partition it
>
>
>any ideas?
>
try zeroing out the first few blocks:
dd if=3D/dev/zero of=3D/dev/offending_scsi_drive bs=3D512 count=3D4
(think if you need a backup before you do this!)
Good luck,
Jurriaan
From jsoe0708@tiscali.be Fri Sep 6 19:15:38 2002
From: jsoe0708@tiscali.be (jsoe0708@tiscali.be)
Date: Fri, 6 Sep 2002 20:15:38 +0200
Subject: [parisc-linux] upgrade evms-1.1.0 -> Kernel bug at blkpg.c (need help)
In-Reply-To: <3D53B3B70000BC9B@ocpmta1.be.tiscali.com>
Message-ID: <3D53B3B70000C9E8@ocpmta1.be.tiscali.com>
Hi all,
>in put_user, case 8 uses something like as:
>__put_user_asm("stw",(unsigned int)(x >> 32), (unsigned int) ptr);__put_user_asm("stw",(unsigned
>int) x, (unsigned int) (ptr+1) );
>
Well it is the contrary.
But I am a bit confuse of what do this __put_user_asm:
what does it return? (error code or ptr or something else?)
Thanks in advance for help;
Joel
Big Brother Anders - With Tiscali you will see it all ! Check it up on
www.tiscali.be/bigbrother
From bdhilton@charter.net Sat Sep 7 01:09:21 2002
From: bdhilton@charter.net (B. Douglas Hilton)
Date: Fri, 06 Sep 2002 20:09:21 -0400
Subject: [parisc-linux] Re: C200 Voodoo2 Progress Report
References: <3D77D183.2080905@charter.net> <20020906034656.A26580@parcelfarce.linux.theplanet.co.uk>
Message-ID: <3D7943B1.3050406@charter.net>
Hrrmm... things aren't quite so easy as I first thought.
For one, the Voodoo2 is a 5V PCI card so it will not fit
into the Cujo slots, only Dino.
Likewise, glide3-alpha wants to use <sys/io.h> which just
isn't there on hppa because that file is particular to
alpha and x86 archs as I understand it. I tried hacking
it to use <asm/io.h> instead which caused a cascade of
about a hundred errors when it got to that point. So
glide3-alpha needs some looking at.
On the kernel front, I can build the sstfb module allright,
which it must be made as a module or else an invisible
HPMC apparently occurs. I know this because after it switches
to fb console mode, nothing more is seen and hitting the
power button causes instant power-off rather than the normal
graceful shutdown.
When I "modprobe sstfb" it appears to load, except it is
reporting that my 12Mb card only has 2Mb. The fbset program
does not segfault, but complains about "Obsolete Major on
/dev/fb1". The con2fb util doesn't report any errors but
neither does it seem to do anything, and finally, a subsequent
"$export FRAMEBUFFER=/dev/fb1; startx -- :0 -bpp 16 vt06"
causes a lockup and suspected HPMC.
So, it seems like this stuff will require some working on.
If anybody else wants to help out too that would be great
because my time is limited and programming video cards is
a bit above my level, but I'll keep tinkering with it in
the meantime. I know some assembly and hardware basics but
am not very familiar with pa-risc yet.
- Doug
Matthew Wilcox wrote:
> On Thu, Sep 05, 2002 at 05:49:55PM -0400, B. Douglas Hilton wrote:
>
>> This is the Debian source for Glide3 on the Alpha arch,
>> which is also big-endian. Initial compilation failed in
>
>
> nope. alpha is little-endian.
>
> LE: alpha, arm, cris, i386, ia64, superh
> BE: m68k, mips, parisc, ppc, s390, sparc
>
> (yes, i know many of these CPUs are bi-endian, but these are the default
> configs)
>
From tobias_subscriber@tgtools.com Sat Sep 7 01:44:42 2002
From: tobias_subscriber@tgtools.com (Tobias Giesen)
Date: Sat, 7 Sep 2002 02:44:42 +0200
Subject: [parisc-linux] Re: C200 Voodoo2 Progress Report
In-Reply-To: <3D7943B1.3050406@charter.net>
Message-ID: <000001c25607$c1fcdf90$0100a8c0@PLUTO>
> For one, the Voodoo2 is a 5V PCI card so it
> will not fit into the Cujo slots, only Dino.
Which means some people can't use it? But you and I
have 5V slots allright, don't we.
> programming video cards is a bit above my level
Mine too!! Things always seem to be more difficult than
you'd think at first. In any case I will now try to
repeat your initial steps, and I'll be very happy if I get
to the checkerboard pattern.
Cheers,
Tobias
From derekengelhaupt@rocketmail.com Sat Sep 7 01:58:14 2002
From: derekengelhaupt@rocketmail.com (Derek Engelhaupt)
Date: Fri, 6 Sep 2002 17:58:14 -0700 (PDT)
Subject: [parisc-linux] Opinions on desktop environments
In-Reply-To: <20020830063725.4D0FD4829@dsl2.external.hp.com>
Message-ID: <20020907005814.6142.qmail@web12506.mail.yahoo.com>
Well, got KDE to work, but it just seems slow even with my 1.6MB of RAM
and 2GB of swap on my C180. I guess my questions would be what would
be an alternative that might run faster and/or be better overall than
KDE? Gnome? I guess I'm looking for what you guys think is the best
desktop environment to run. Thanks.
derek
__________________________________________________
Do You Yahoo!?
Yahoo! Finance - Get real-time stock quotes
http://finance.yahoo.com
From bdhilton@charter.net Sat Sep 7 02:06:32 2002
From: bdhilton@charter.net (B. Douglas Hilton)
Date: Fri, 06 Sep 2002 21:06:32 -0400
Subject: [parisc-linux] Re: C200 Voodoo2 Progress Report
References: <000001c25607$c1fcdf90$0100a8c0@PLUTO>
Message-ID: <3D795118.1060709@charter.net>
The C200 and probably C160, 180, 240, and 360
have two three different busses inside: the
Hewlett-Packard GSC bus, 5V/32bit PCI (dino),
and 3V/64bit PCI (cujo). Some PCI cards are
universal and have two punchouts. The 3V cards
have the punchout close to the outside edge of
the card, and 5V are the other way around.
You can use a 3V/32bit card in a 3V/64bit
slot with no problems. The Voodoo2 is 5V
only and will not fit into one of the Cujo slots.
Tobias Giesen wrote:
>>For one, the Voodoo2 is a 5V PCI card so it
>>will not fit into the Cujo slots, only Dino.
>
>
> Which means some people can't use it? But you and I
> have 5V slots allright, don't we.
>
Right, C200 has both types. See above.
>
>>programming video cards is a bit above my level
>
>
> Mine too!! Things always seem to be more difficult than
> you'd think at first. In any case I will now try to
> repeat your initial steps, and I'll be very happy if I get
> to the checkerboard pattern.
>
Yeah, not sure what did that. After rebuilding the sstfb
as a module and modprobe'ing it, I got a couple of colored
blocks, but not the checkerboard. I'm not sure of the exact
sequence as I haven't hooked up the spare monitor yet but
was switching the VGA cable back and forth. Further testing
seems warranted.
My C200 is back offline temporarily. I'm re-wiring my LAN
as it has gotten to be a horrendous mess of tangled wires
and cables after unplugging and replugging things for
several months. Need to straighten it out again :-)
I think I'll put the C200 onto my KVM switch with my X86 box
and reconsolidate it. I don't believe I'll be cracking the
case open anymore so it can be stowed away better than it is.
I put something like 370Mb RAM into it, a cdrom, an EEPro100,
and the Voodoo2. It is pretty well maxed out unless I run
low on HDD space which seems unlikely considering I just use
it as a hobby linux hacking box.
Thats it for now.
- Doug
From alan@lxorguk.ukuu.org.uk Sat Sep 7 02:43:28 2002
From: alan@lxorguk.ukuu.org.uk (Alan Cox)
Date: 07 Sep 2002 02:43:28 +0100
Subject: [parisc-linux] Opinions on desktop environments
In-Reply-To: <20020907005814.6142.qmail@web12506.mail.yahoo.com>
References: <20020907005814.6142.qmail@web12506.mail.yahoo.com>
Message-ID: <1031363008.9861.103.camel@irongate.swansea.linux.org.uk>
On Sat, 2002-09-07 at 01:58, Derek Engelhaupt wrote:
> Well, got KDE to work, but it just seems slow even with my 16MB of RAM
> and 2GB of swap on my C180. I guess my questions would be what would
> be an alternative that might run faster and/or be better overall than
> KDE? Gnome? I guess I'm looking for what you guys think is the best
> desktop environment to run. Thanks.
17Mb is pushing it. KDE/GNOME are about the same size. xfce/rox need a
lot less
From willy@debian.org Sat Sep 7 03:04:25 2002
From: willy@debian.org (Matthew Wilcox)
Date: Sat, 7 Sep 2002 03:04:25 +0100
Subject: [parisc-linux] Re: C200 Voodoo2 Progress Report
In-Reply-To: <3D795118.1060709@charter.net>; from bdhilton@charter.net on Fri, Sep 06, 2002 at 09:06:32PM -0400
References: <000001c25607$c1fcdf90$0100a8c0@PLUTO> <3D795118.1060709@charter.net>
Message-ID: <20020907030425.H26580@parcelfarce.linux.theplanet.co.uk>
On Fri, Sep 06, 2002 at 09:06:32PM -0400, B. Douglas Hilton wrote:
> The C200 and probably C160, 180, 240, and 360
> have two three different busses inside: the
> Hewlett-Packard GSC bus, 5V/32bit PCI (dino),
> and 3V/64bit PCI (cujo).
... and some have an EISA slot provided by Wax. I'm not sure exactly
which configurations exist, but the hwdb thinks that Cujo was only
used in the C200+, C240+, C360 and J2240. The hwdb is slightly limited
in that there's only one profile per name, when it's possible to have
different configurations of the same box. All B/C class boxes of that
era are guaranteed to have a Dino though, so there's no real problem
with requiring the use of a 5V slot.
--
Revolutions do not require corporate support.
From alaskan@telusplanet.net Sat Sep 7 03:29:05 2002
From: alaskan@telusplanet.net (alaskan@telusplanet.net)
Date: Fri, 06 Sep 2002 20:29:05 -0600
Subject: [parisc-linux] Opinions on desktop environments
In-Reply-To: <1031363008.9861.103.camel@irongate.swansea.linux.org.uk>
References: <20020907005814.6142.qmail@web12506.mail.yahoo.com> <1031363008.9861.103.camel@irongate.swansea.linux.org.uk>
Message-ID: <7joinucs23osp1s07fsc9m2e6b927ho3dg@4ax.com>
On 07 Sep 2002 02:43:28 +0100, you wrote:
>On Sat, 2002-09-07 at 01:58, Derek Engelhaupt wrote:
>> Well, got KDE to work, but it just seems slow even with my 16MB of RAM
>> and 2GB of swap on my C180. I guess my questions would be what would
>> be an alternative that might run faster and/or be better overall than
>> KDE? Gnome? I guess I'm looking for what you guys think is the best
>> desktop environment to run. Thanks.
>
>17Mb is pushing it. KDE/GNOME are about the same size. xfce/rox need a
>lot less
>
>_______________________________________________
>parisc-linux mailing list
>parisc-linux@lists.parisc-linux.org
>http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
Nothing like applying a little hardware to cure speed demons.
I would suggest more memory, at least 32MB and even 64MB and or a
faster hard disk drive (: 10k rpm :) the latter has sped my 712/60 to
twice the normal performance when using a GUI.
From grundler@dsl2.external.hp.com Sat Sep 7 04:10:09 2002
From: grundler@dsl2.external.hp.com (Grant Grundler)
Date: Fri, 06 Sep 2002 21:10:09 -0600
Subject: [parisc-linux] Formatting Scsi disks
In-Reply-To: Message from "James S" <smithjames@comcast.net>
of "Fri, 06 Sep 2002 08:44:29 CDT." <005201c255ab$a3bf7f80$02c1a8c0@james.co.uk>
References: <20020902234752.GA6718@systemhalted> <005201c255ab$a3bf7f80$02c1a8c0@james.co.uk>
Message-ID: <20020907031009.BB562482A@dsl2.external.hp.com>
"James S" wrote:
> the search command from the boot console on the 712 sees the disk
> the kernel sees & correctly identifies the disk
> just wont partition it
> any ideas?
hmm...
dd if=/dev/zero of=/dev/sda bs=64k count=10
reboot and then try to partition it.
I'm guessing the partition tool does not know the current partition scheme
(or maybe just thinks it does).
grant
From bdhilton@charter.net Sat Sep 7 05:33:02 2002
From: bdhilton@charter.net (B. Douglas Hilton)
Date: Sat, 07 Sep 2002 00:33:02 -0400
Subject: [parisc-linux] Opinions on desktop environments
References: <20020907005814.6142.qmail@web12506.mail.yahoo.com>
Message-ID: <3D79817E.201@charter.net>
Derek Engelhaupt wrote:
> Well, got KDE to work, but it just seems slow even with my 1.6MB of RAM
> and 2GB of swap on my C180. I guess my questions would be what would
> be an alternative that might run faster and/or be better overall than
> KDE? Gnome? I guess I'm looking for what you guys think is the best
> desktop environment to run. Thanks.
>
> derek
Hehe... you should try running a 715 or 712! The C-Class machines positively
scream! I agree though, KDE is somewhat sluggish on my C200, but really not
too bad, its usable. I've heard rumors that someday the hppa c-library could
be optimized to run _much_ faster but its still a baby as far as linux is
concerned - I'm just tickled that it even works... I wanted another non-x86
machine (also have a Netwinder), but SGI's are pretty exotic (though tempting),
Alpha's seem super cool but are somewhat expensive and often in bad disrepair,
and Sun machines are either too expensive or too old. The hppa boxes provided
a nice economy and are very much contenders with any of the aforementioned
architectures. In its day a C200 running HP/UX was supposedly able to smoke
a 600MHz Alpha! Obviously there is a lot of optimization still to do...
I started off with a 715/80, got Woody running good on it, played with it for
almost a year, then sold it on Ebay for a small profit (Debian sells!) and
rolled my dough into the C200. I'm rather happy with its performance,
although it doesn't hold a candle to my super dual pentium-II 450 monster
box, still its a cool and useful machine, and very nice for making sure
that your app is portable, compiling your own hppa debs, etc. I don't run
mine 24/7 because it has pretty high power consumption, so the Netwinder
is my little server machine -> http://www.gyrodynamic.net
Well, I sent you a private email with my suggestions about E, but now that
I think about it, BlackBox isn't too bad with 8bpp color. Assuming that
somebody has fixed "update-menus" really any Debian window manager should
work with KDE, Gnome, and other X apps. The Debian menus should provide
access to all the installed packages which is all you really need.
BTW, regarding "update-menus" - the last time I tried it on hppa it worked
as root but segfaulted as a normal user.
- Doug
From derekengelhaupt@rocketmail.com Sat Sep 7 06:22:36 2002
From: derekengelhaupt@rocketmail.com (Derek Engelhaupt)
Date: Fri, 6 Sep 2002 22:22:36 -0700 (PDT)
Subject: [parisc-linux] Opinions on desktop environments
In-Reply-To: <3D79817E.201@charter.net>
Message-ID: <20020907052236.81279.qmail@web12503.mail.yahoo.com>
whoops...meant to say 1.6GB.....;)
sorry...
--- "B. Douglas Hilton" <bdhilton@charter.net> wrote:
> Derek Engelhaupt wrote:
> > Well, got KDE to work, but it just seems slow even with my 1.6MB of
> RAM
> > and 2GB of swap on my C180. I guess my questions would be what
> would
> > be an alternative that might run faster and/or be better overall
> than
> > KDE? Gnome? I guess I'm looking for what you guys think is the
> best
> > desktop environment to run. Thanks.
> >
> > derek
>
>
> Hehe... you should try running a 715 or 712! The C-Class machines
> positively
> scream! I agree though, KDE is somewhat sluggish on my C200, but
> really not
> too bad, its usable. I've heard rumors that someday the hppa
> c-library could
> be optimized to run _much_ faster but its still a baby as far as
> linux is
> concerned - I'm just tickled that it even works... I wanted another
> non-x86
> machine (also have a Netwinder), but SGI's are pretty exotic (though
> tempting),
> Alpha's seem super cool but are somewhat expensive and often in bad
> disrepair,
> and Sun machines are either too expensive or too old. The hppa boxes
> provided
> a nice economy and are very much contenders with any of the
> aforementioned
> architectures. In its day a C200 running HP/UX was supposedly able to
> smoke
> a 600MHz Alpha! Obviously there is a lot of optimization still to
> do...
>
> I started off with a 715/80, got Woody running good on it, played
> with it for
> almost a year, then sold it on Ebay for a small profit (Debian
> sells!) and
> rolled my dough into the C200. I'm rather happy with its performance,
> although it doesn't hold a candle to my super dual pentium-II 450
> monster
> box, still its a cool and useful machine, and very nice for making
> sure
> that your app is portable, compiling your own hppa debs, etc. I don't
> run
> mine 24/7 because it has pretty high power consumption, so the
> Netwinder
> is my little server machine -> http://www.gyrodynamic.net
>
> Well, I sent you a private email with my suggestions about E, but now
> that
> I think about it, BlackBox isn't too bad with 8bpp color. Assuming
> that
> somebody has fixed "update-menus" really any Debian window manager
> should
> work with KDE, Gnome, and other X apps. The Debian menus should
> provide
> access to all the installed packages which is all you really need.
>
> BTW, regarding "update-menus" - the last time I tried it on hppa it
> worked
> as root but segfaulted as a normal user.
>
>
>
> - Doug
>
> _______________________________________________
> parisc-linux mailing list
> parisc-linux@lists.parisc-linux.org
> http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
__________________________________________________
Do You Yahoo!?
Yahoo! Finance - Get real-time stock quotes
http://finance.yahoo.com
From marc@centraltx.com Sat Sep 7 21:46:25 2002
From: marc@centraltx.com (marc )
Date: Sat, 7 Sep 2002 15:46:25 -0500
Subject: [parisc-linux] Kernel Panic
Message-ID: <200209071546.AA210633180@mail.centraltx.com>
Okay, I've upgraded from the .iso image off of debian.org.
Now, I'm getting stranger errors with my tape drive. It looks
like the st is no longer a loadable kernel module? Anyways,
any help is appreciated.
(none):~# lsmod
Module Size Used by Not tainted
(none):~# insmod st
insmod: st: no module by that name found
(none):~# cat /proc/scsi/scsi
Attached devices:
Host: scsi0 Channel: 00 Id: 05 Lun: 00
Vendor: SEAGATE Model: ST34371W Rev: HP03
Type: Direct-Access ANSI SCSI revision: 02
Host: scsi0 Channel: 00 Id: 06 Lun: 00
Vendor: SEAGATE Model: ST32171W Rev: HP03
Type: Direct-Access ANSI SCSI revision: 02
Host: scsi1 Channel: 00 Id: 01 Lun: 00
Vendor: SONY Model: SDT-7000 Rev: 0150
Type: Sequential-Access ANSI SCSI revision: 02
(none):~# ls /dev/st*
/dev/st0 /dev/st0l /dev/st1 /dev/st1l /dev/stderr /dev/stdout
/dev/st0a /dev/st0m /dev/st1a /dev/st1m /dev/stdin
(none):~# ls nst*
/dev/nst0 /dev/nst0l /dev/nst1 /dev/nst1l
/dev/nst0a /dev/nst0m /dev/nst1a /dev/nst1m
(none):~# tar -cvpf /dev/st0 /home
st0: Block limits 1 - 16777215 bytes.
tar: Removing leading `/' from member names
home/
home/lost+found/
home/marc/
home/marc/.bashrc
home/marc/.bash_profile
st0: Error on write filemark.
st0: Error with sense data: Current st09:00: sns = 70 4
ASC=44 ASCQ= 0
Raw sense data:0x70 0x00 0x04 0x00 0x00 0x00 0x00 0x12 0x00 0x00 0x00 0x00 0x44
0x00 0x00 0x00 0xa3 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
tar: /dev/st0: Warning: Cannot close: Input/output error
(none):/home/marc# tar -xvpf /dev/st0
tar: /dev/st0: Cannot read: Input/output error
tar: At beginning of tape, quitting now
tar: Error is not recoverable: exiting now
From marc@centraltx.com Sat Sep 7 21:49:50 2002
From: marc@centraltx.com (marc )
Date: Sat, 7 Sep 2002 15:49:50 -0500
Subject: [parisc-linux] Bus Speed
Message-ID: <200209071549.AA99484160@mail.centraltx.com>
When Linux starts up I see a message saying:
ide: Assuming 50MHz system bus speed for PIO modes; override with idebus=xx
I have a C180 and the bus speed at startup says:
Central Bus Speed (in MHz) : 120
so I'm assuming I should add the boot parameter as mentioned above.
Will I see any performance gain?
Thanks,
-Marc
From marc@centraltx.com Sat Sep 7 21:55:22 2002
From: marc@centraltx.com (marc )
Date: Sat, 7 Sep 2002 15:55:22 -0500
Subject: [parisc-linux] resolv.conf
Message-ID: <200209071555.AA34406894@mail.centraltx.com>
Finally, I have a message at startup that says:
Running 0dns-down to make sure resolv.conf is ok...chmod: getting attributes of
`/etc/resolv.conf': No such file or directory
done.
do I need to create a resolv.conf file? Sounds easy enough.
-Marc
From marc@centraltx.com Sat Sep 7 22:00:50 2002
From: marc@centraltx.com (marc )
Date: Sat, 7 Sep 2002 16:00:50 -0500
Subject: [parisc-linux] Boot Order
Message-ID: <200209071600.AA32899526@mail.centraltx.com>
Oh one last question, how can I change the default boot
from P0 to P1? Everything works fine if I do a SEA then BO P1
at startup, and I want to make this the default.
Thanks for everything,
-Marc
From christoph.plattner@gmx.at Sat Sep 7 22:36:49 2002
From: christoph.plattner@gmx.at (Christoph Plattner)
Date: Sat, 07 Sep 2002 23:36:49 +0200
Subject: [parisc-linux] [PATCH] Serial MUX support for Nova and K-Class
systems.
References: <1029991787.4813.14.camel@beavis>
Message-ID: <3D7A7171.CEA2FEAE@gmx.at>
Hallo Ryan,
after that long time, I did the first experiment with
your new MUX driver ...
... and it fails on my E55.
But NO WONDER ! I already have the problem finding any
devices on the I/O interface card, and I had no time
since weeks now, to do further steps.
In general I have the problem in basic stuff and in
docu, special for the I/O scanning via PDC in more
details. In the normal PDC/IO there is not enough docu
for that. I was informed, that there is one more docu
handling this, bt I forgot the name, something like
"AIO" or so.
How we can go one step forward, as I also want to
start (in slowly steps) the SCSI driver ... ?
Bye,
Christoph
Ryan Bradetich wrote:
>
> Hello all,
>
> I just committed support for the Serial MUX driver as linux-2.4.19-pa5.
>
> This patch has been tested on my K460 and has been working well. The
> driver uses the same /dev/ttyB0 device the PDC Software console that
> Christoph Plattner wrote and is available under the Non-standard serial
> ports section.
>
> Currently the driver only supports the Eole CAP/MUX (A Direct) device
> since that is all I have to test with. Additional devices can be added
> under this driver as people with systems have a chance to test.
>
> I tried to document the driver with kerneldoc, but it would be nice if
> someone would check over my comment as I had to google/guess what most
> of the ioctls and tty flags were.
>
> The committed patch can be found at:
> ftp://ftp.parisc-linux.org/patches/serial_mux_v0.1.diff
>
> Feedback greatly appreciated!
>
> Thanks,
>
> - Ryan
>
> _______________________________________________
> parisc-linux mailing list
> parisc-linux@lists.parisc-linux.org
> http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
--
-------------------------------------------------------
private: christoph.plattner@gmx.at
company: christoph.plattner@alcatel.at
From alan@lxorguk.ukuu.org.uk Sat Sep 7 22:39:46 2002
From: alan@lxorguk.ukuu.org.uk (Alan Cox)
Date: 07 Sep 2002 22:39:46 +0100
Subject: [parisc-linux] Bus Speed
In-Reply-To: <200209071549.AA99484160@mail.centraltx.com>
References: <200209071549.AA99484160@mail.centraltx.com>
Message-ID: <1031434786.14390.6.camel@irongate.swansea.linux.org.uk>
On Sat, 2002-09-07 at 21:49, marc wrote:
> When Linux starts up I see a message saying:
>
> ide: Assuming 50MHz system bus speed for PIO modes; override with idebus=xx
>
> I have a C180 and the bus speed at startup says:
>
> Central Bus Speed (in MHz) : 120
>
> so I'm assuming I should add the boot parameter as mentioned above.
> Will I see any performance gain?
I doubt the 120Mhz clock is run to non PCI IDE devices. The PARISC port
should be setting the IDE base clocking itself.
From grundler@dsl2.external.hp.com Sat Sep 7 22:53:19 2002
From: grundler@dsl2.external.hp.com (Grant Grundler)
Date: Sat, 07 Sep 2002 15:53:19 -0600
Subject: [parisc-linux] Bus Speed
In-Reply-To: Message from "marc " <marc@centraltx.com>
of "Sat, 07 Sep 2002 15:49:50 CDT." <200209071549.AA99484160@mail.centraltx.com>
References: <200209071549.AA99484160@mail.centraltx.com>
Message-ID: <20020907215319.8FC46482A@dsl2.external.hp.com>
"marc " wrote:
> ide: Assuming 50MHz system bus speed for PIO modes; override with idebus=xx
> I have a C180 and the bus speed at startup says:
> Central Bus Speed (in MHz) : 120
There is no IDE on C180 unless you've added a PCI card that has it.
Only systems with SuckyIO have built-in IDE where HPUX officially
only supports CD-ROM. Of course, under linux we can do what we want.
"Central Bus" in this case is the "Runway" bus.
Only CPU, Memory Controller and IO Controller (U2) are on Runway bus.
grant
From grundler@dsl2.external.hp.com Sat Sep 7 22:55:09 2002
From: grundler@dsl2.external.hp.com (Grant Grundler)
Date: Sat, 07 Sep 2002 15:55:09 -0600
Subject: [parisc-linux] resolv.conf
In-Reply-To: Message from "marc " <marc@centraltx.com>
of "Sat, 07 Sep 2002 15:55:22 CDT." <200209071555.AA34406894@mail.centraltx.com>
References: <200209071555.AA34406894@mail.centraltx.com>
Message-ID: <20020907215509.1B52A482A@dsl2.external.hp.com>
"marc " wrote:
> do I need to create a resolv.conf file? Sounds easy enough.
DHCP will normally do that for you.
If you are manually configuring NICs, then yes.
DHCP sets up my home system like this:
grundler@c3k:~$ cat /etc/resolv.conf
search attbi.com
nameserver 216.148.227.68
nameserver 204.127.202.4
grant
From grundler@dsl2.external.hp.com Sat Sep 7 22:57:55 2002
From: grundler@dsl2.external.hp.com (Grant Grundler)
Date: Sat, 07 Sep 2002 15:57:55 -0600
Subject: [parisc-linux] Boot Order
In-Reply-To: Message from "marc " <marc@centraltx.com>
of "Sat, 07 Sep 2002 16:00:50 CDT." <200209071600.AA32899526@mail.centraltx.com>
References: <200209071600.AA32899526@mail.centraltx.com>
Message-ID: <20020907215755.7904C482A@dsl2.external.hp.com>
"marc " wrote:
> Oh one last question, how can I change the default boot
> from P0 to P1? Everything works fine if I do a SEA then BO P1
> at startup, and I want to make this the default.
pa pri fwscsi.X.0 (or something like that).
Type "help" or "he path" from the config menu.
It will explain how to set "Primary Boot path".
grant
From rbradetich@uswest.net Sat Sep 7 23:03:59 2002
From: rbradetich@uswest.net (Ryan Bradetich)
Date: 07 Sep 2002 16:03:59 -0600
Subject: [parisc-linux] [PATCH] Serial MUX support for Nova and K-Class
systems.
In-Reply-To: <3D7A7171.CEA2FEAE@gmx.at>
References: <1029991787.4813.14.camel@beavis> <3D7A7171.CEA2FEAE@gmx.at>
Message-ID: <1031436239.581.19.camel@beavis>
Hi Christoph,
I'm working on solving the problem why we do not find
the MUX device. The ESIEE team has generously given
me access to an E35 so I could poke around the HP-UX
iotree and see what I could find.
This is the summary of what I have found:
name_buffer instance hw_addr parent sibling child
"bc" 1 56 0x43b3a0 0xc15240 0xc15040
"scsi1" 0 52 0xc15000 0xe74140 0xc15080
"" -1 53 0xc15000 0xc15200 0
"mux2" 0 56 0xc15000 0 0
"bus_adapter" 0 60 0x43b3a0 0xe74240 0xc15280
"lan2" 0 6 0xc15240 0 0
"processor" 0 62 0x43b3a0 0xe74280 0
"memory" 0 63 0x43b3a0 0 0
The MUX sits at: 56/56 with HPA: 0xfffb8000
>From your boot logs posted to the mailing list:
---- walk_native_bus: testing hpa=0xfffb8000, i=56
---- walk_native_bus: -- device not processed, mod = i !
------ alloc_pa_dev: entry
-------------------------- find_parisc_device: entry, mod=56
-------------------------- find_parisc_device: bc[0]=-1
-------------------------- find_parisc_device: bc[1]=-1
-------------------------- find_parisc_device: bc[2]=-1
-------------------------- find_parisc_device: bc[3]=-1
-------------------------- find_parisc_device: bc[4]=-1
-------------------------- find_parisc_device: bc[5]=-1
-- walk_lower_bus: entry
-- walk_lower_bus: dev: hpa=0xfffb8000, io_io_low=0xfff00000,
io_io_high=0xfff80000
You also found a device at 0xfffb8000 which I am assuming is the MUX.
(I need to get back on the E35 at the ESIEE to verify my thoughts.)
The problem we are running into here is that 0xfffb8000 is on the
Central BUS, not under the 56/ bus as the console wants to be in
the HP-UX iotree. It appears to me that the bc and the MUX exist
at the same HPA and that is what is causing the confusion in the
parisc-linux I/O tree.
The other thing that is curious to me is the "" devices under the
bc between the scsi1 and the mux2 device.
I think I can get this problem solved once I get access to the
ESIEE E35 and am able to boot some test kernels on the system to
play with.
As for the scsi driver. I have the bare-bones (ie. does not work)
of both the skunk (8-bit) and the wizard (16-bit) drivers started from a
while back. I think you found a reference to the SPIFI chip that we
could use in the driver to further progress the drivers and hopefully
get them talking.
The document is the IOACD document I believe. What are you looking for?
Parts of the document are on the parisc-linux website, but if that is
not enough info, I'll try to find it for you in the IOACD.
Thanks!
- Ryan
On Sat, 2002-09-07 at 15:36, Christoph Plattner wrote:
> Hallo Ryan,
>
> after that long time, I did the first experiment with
> your new MUX driver ...
>
> ... and it fails on my E55.
>
> But NO WONDER ! I already have the problem finding any
> devices on the I/O interface card, and I had no time
> since weeks now, to do further steps.
>
> In general I have the problem in basic stuff and in
> docu, special for the I/O scanning via PDC in more
> details. In the normal PDC/IO there is not enough docu
> for that. I was informed, that there is one more docu
> handling this, bt I forgot the name, something like
> "AIO" or so.
>
> How we can go one step forward, as I also want to
> start (in slowly steps) the SCSI driver ... ?
>
> Bye,
> Christoph
>
>
>
> Ryan Bradetich wrote:
> >
> > Hello all,
> >
> > I just committed support for the Serial MUX driver as linux-2.4.19-pa5.
> >
> > This patch has been tested on my K460 and has been working well. The
> > driver uses the same /dev/ttyB0 device the PDC Software console that
> > Christoph Plattner wrote and is available under the Non-standard serial
> > ports section.
> >
> > Currently the driver only supports the Eole CAP/MUX (A Direct) device
> > since that is all I have to test with. Additional devices can be added
> > under this driver as people with systems have a chance to test.
> >
> > I tried to document the driver with kerneldoc, but it would be nice if
> > someone would check over my comment as I had to google/guess what most
> > of the ioctls and tty flags were.
> >
> > The committed patch can be found at:
> > ftp://ftp.parisc-linux.org/patches/serial_mux_v0.1.diff
> >
> > Feedback greatly appreciated!
> >
> > Thanks,
> >
> > - Ryan
> >
> > _______________________________________________
> > parisc-linux mailing list
> > parisc-linux@lists.parisc-linux.org
> > http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
>
> --
> -------------------------------------------------------
> private: christoph.plattner@gmx.at
> company: christoph.plattner@alcatel.at
>
From grundler@dsl2.external.hp.com Sat Sep 7 23:08:43 2002
From: grundler@dsl2.external.hp.com (Grant Grundler)
Date: Sat, 07 Sep 2002 16:08:43 -0600
Subject: [parisc-linux] Kernel Panic
In-Reply-To: Message from "marc " <marc@centraltx.com>
of "Sat, 07 Sep 2002 15:46:25 CDT." <200209071546.AA210633180@mail.centraltx.com>
References: <200209071546.AA210633180@mail.centraltx.com>
Message-ID: <20020907220843.24818482A@dsl2.external.hp.com>
"marc " wrote:
> It looks like the st is no longer a loadable kernel module?
Right. It's not:
CONFIG_CHR_DEV_ST=y
See arch/parisc/debian-configs/* for default configs.
> st0: Error on write filemark.
> st0: Error with sense data: Current st09:00: sns = 70 4
> ASC=44 ASCQ= 0
> Raw sense data:0x70 0x00 0x04 0x00 0x00 0x00 0x00 0x12 0x00 0x00 0x00 0x00 0x
> 44
> 0x00 0x00 0x00 0xa3 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
> tar: /dev/st0: Warning: Cannot close: Input/output error
Seagate (and other vendors) publishes the subset of SCSI spec they implement.
It includes Sense Key/ASC/ASCQ encodings.
Look for "scsi2_seagate.pdf" on www.seagate.com web site.
Sense Key = 0x04 == "Hardware Error"
ASC/ASCQ = 0x44/0 == "Internal Target Failure"
You need to find the programming manual for your tape device
and hopefully it explains exactly what this means.
grant
From derekengelhaupt@rocketmail.com Sun Sep 8 02:09:08 2002
From: derekengelhaupt@rocketmail.com (Derek Engelhaupt)
Date: Sat, 7 Sep 2002 18:09:08 -0700 (PDT)
Subject: [parisc-linux] Boot Order
In-Reply-To: <20020907215755.7904C482A@dsl2.external.hp.com>
Message-ID: <20020908010908.75589.qmail@web12505.mail.yahoo.com>
And if you want it to start automatically from that path you have to
set autoboot to on. Autoboot and the path commands are in the
Configuration menu (co from the ma prompt).
derek
--- Grant Grundler <grundler@dsl2.external.hp.com> wrote:
> "marc " wrote:
> > Oh one last question, how can I change the default boot
> > from P0 to P1? Everything works fine if I do a SEA then BO P1
> > at startup, and I want to make this the default.
>
> pa pri fwscsi.X.0 (or something like that).
>
> Type "help" or "he path" from the config menu.
> It will explain how to set "Primary Boot path".
>
> grant
> _______________________________________________
> parisc-linux mailing list
> parisc-linux@lists.parisc-linux.org
> http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
__________________________________________________
Do You Yahoo!?
Yahoo! Finance - Get real-time stock quotes
http://finance.yahoo.com
From carlos@baldric.uwo.ca Sun Sep 8 02:50:59 2002
From: carlos@baldric.uwo.ca (Carlos O'Donell)
Date: Sat, 7 Sep 2002 21:50:59 -0400
Subject: [parisc-linux] RFC - Changes to traps.c (Handlers for 13, changes to 16/17)
Message-ID: <20020908015059.GN5679@systemhalted>
--61jdw2sOBCFtR2d/
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
parisc,
After some banter on IRC about how one should set the stride
for a cache flush using the 'fic' instruction, I noted the
following possible problems our trap handler:
a. Non-access instruction TLB miss fault (16)
- No implemented case statement in traps.c
- No problem, falls through to do_page_fault.
- Suggest forcing a sigsegv on the process.
b. Non-access data TLB miss fault (17)
- Calls parisc_terminate and gutters the cpu.
- This should not happen.
- Suggest forcing a sigsegv on the process.
c. Conditional Trap (13)
- No implemented case statment in traps.c
- Suggest forcing SIGFPE and setting si_code to zero,
and allowing the userspace app the decode the
situation from the signal andler (HPUX seems to
this?) via si_addr.
c. All paths must either return or set the fault_address
and fault_space values? One place does not, I put a
FIXME there. Needs review. Those two values are needed
by the check after the switch statement in handle_interruption.
Is setting them to zero, as is done now, good enough?
Patch attached :)
c.
--61jdw2sOBCFtR2d/
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="traps.c.diff"
--- traps.c.orig 2002-09-07 21:30:15.000000000 -0400
+++ traps.c.new 2002-09-07 21:30:05.000000000 -0400
@@ -425,11 +425,11 @@
/*
- * This routine handles page faults. It determines the address,
+ * This routine handles various exception codes. It determines the address,
* and the problem, and then passes it off to one of the appropriate
* routines.
*/
-void parisc_terminate(char *msg, struct pt_regs *regs, int code, unsigned long offset)
+void parisc_handle_code(char *msg, struct pt_regs *regs, int code, unsigned long offset)
{
static spinlock_t terminate_lock = SPIN_LOCK_UNLOCKED;
@@ -444,8 +444,17 @@
if (!console_drivers)
pdc_console_restart();
- if (code == 1)
- transfer_pim_to_trap_frame(regs);
+
+ /* Not all switch paths will gutter the processor... */
+ switch(code){
+
+ case 1:
+ transfer_pim_to_trap_frame(regs);
+ break;
+
+ default:
+ /* Fall through */
+ }
show_stack(regs);
@@ -461,6 +470,7 @@
* system will shut down immediately right here. */
pdc_soft_power_button(0);
+ /* Gutter the processor... */
for(;;)
;
}
@@ -487,7 +497,7 @@
case 1:
/* High-priority machine check (HPMC) */
- parisc_terminate("High Priority Machine Check (HPMC)",
+ parisc_handle_code("High Priority Machine Check (HPMC)",
regs, code, 0);
/* NOT REACHED */
@@ -554,6 +564,7 @@
die_if_kernel("Privileged register usage", regs, code);
si.si_code = ILL_PRVREG;
+ /* Fall thru */
give_sigill:
si.si_signo = SIGILL;
si.si_errno = 0;
@@ -568,6 +579,20 @@
si.si_addr = (void *) regs->iaoq[0];
force_sig_info(SIGFPE, &si, current);
return;
+
+ case 13:
+ /* Conditional Trap */
+ /* The condition succees in an instruction which traps
+ * on condition
+ */
+ si.si_signo = SIGFPE;
+ /* Set to zero, and let the userspace app figure it out from
+ * the insn pointed to by si_addr
+ */
+ si.si_code = 0;
+ si.si_addr = (void *) regs->iaoq[0];
+ force_sig_info(SIGFPE, &si, current);
+ return;
case 14:
/* Assist Exception Trap, i.e. floating point exception. */
@@ -575,11 +600,24 @@
handle_fpe(regs);
return;
+ case 15:
+ /* Data TLB miss fault/Data page fault */
+ /* Fall thru */
+ case 16:
+ /* Non-access instruction TLB miss fault */
+ /* The instruction TLB entry needed for the target address of the FIC
+ * is absent, and hardware can't find it, so we get to cleanup
+ */
+ /* Fall thru */
case 17:
/* Non-access data TLB miss fault/Non-access data page fault */
/* TODO: Still need to add slow path emulation code here */
+ /* TODO: Understand what is meant by the TODO listed
+ * above this one. (Carlos - Sep 7, 2002) */
+
fault_address = regs->ior;
- parisc_terminate("Non access data tlb fault!",regs,code,fault_address);
+ fault_space = regs->isr;
+ break;
case 18:
/* PCXS only -- later cpu's split this into types 26,27 & 28 */
@@ -589,9 +627,8 @@
return;
}
/* Fall Through */
-
- case 15: /* Data TLB miss fault/Data page fault */
- case 26: /* PCXL: Data memory access rights trap */
+ case 26:
+ /* PCXL: Data memory access rights trap */
fault_address = regs->ior;
fault_space = regs->isr;
break;
@@ -621,6 +658,11 @@
pt_regs_to_ssp(regs, &ssp);
kgdb_trap(I_TAKEN_BR, &ssp, 1);
ssp_to_pt_regs(&ssp, regs);
+
+ /* FIXME: Should this break without setting fault_address
+ * and fault_space? They are required for the dump later on.
+ * (Carlos - Sep 7, 2002) */
+
break;
#endif /* CONFIG_KWDB */
@@ -656,7 +698,6 @@
up_read(¤t->mm->mmap_sem);
}
/* Fall Through */
-
case 27:
/* Data memory protection ID trap */
die_if_kernel("Protection id trap", regs, code);
@@ -690,7 +731,7 @@
force_sig_info(SIGBUS, &si, current);
return;
}
- parisc_terminate("Unexpected interruption", regs, code, 0);
+ parisc_handle_code("Unexpected interruption", regs, code, 0);
/* NOT REACHED */
}
@@ -719,7 +760,8 @@
*/
if (fault_space == 0)
- parisc_terminate("Kernel Fault", regs, code, fault_address);
+ parisc_handle_code("Kernel Fault", regs, code, fault_address);
+ /* NOT REACHED */
}
#ifdef CONFIG_KWDB
--61jdw2sOBCFtR2d/--
From carlos@baldric.uwo.ca Sun Sep 8 03:16:39 2002
From: carlos@baldric.uwo.ca (Carlos O'Donell)
Date: Sat, 7 Sep 2002 22:16:39 -0400
Subject: [parisc-linux] RFC - Changes to traps.c (Handlers for 13, changes to 16/17)
In-Reply-To: <20020908015059.GN5679@systemhalted>
References: <20020908015059.GN5679@systemhalted>
Message-ID: <20020908021639.GA14982@systemhalted>
pa,
If you have a burning desire to build with this change
then you'll need this bit too.
I'm possibly tempted to stay with the 'parisc_terminate' name
and just change the comments for the function.
c.
--- linux/arch/parisc/mm/fault.c 2001-12-04 18:19:47.000000000 -0500
+++ linux/arch/parisc/mm/fault.c.new 2002-09-07 22:12:29.000000000 -0400
@@ -256,7 +256,8 @@
}
}
- parisc_terminate("Bad Address (null pointer deref?)", regs, code, address);
+ parisc_handle_code("Bad Address (null pointer deref?)", regs, code, address);
+ /* NOT REACHED */
out_of_memory:
up_read(&mm->mmap_sem);
From christoph.plattner@gmx.at Sun Sep 8 09:49:27 2002
From: christoph.plattner@gmx.at (Christoph Plattner)
Date: Sun, 08 Sep 2002 10:49:27 +0200
Subject: [parisc-linux] [PATCH] Serial MUX support for Nova and K-Class
systems.
References: <1029991787.4813.14.camel@beavis> <3D7A7171.CEA2FEAE@gmx.at> <1031436239.581.19.camel@beavis>
Message-ID: <3D7B0F17.92F8A75A@gmx.at>
Hello Ryan,
what I am looking for is the field definitions of the
structures of the bus queries. I also have forgotten
the names here (I must go back to my "debug code"
and reread it !!!).
Oh, I have found it:
struct io_moudule
and
struct bc_module
(especially for the second one, I have no idea, where
it comes from). All these structure (there are more)
are defined in `include/asm/hardware.h'.
I have to get back to my hacks, to know more details
again.
Christoph
Ryan Bradetich wrote:
>
> Hi Christoph,
>
> I'm working on solving the problem why we do not find
> the MUX device. The ESIEE team has generously given
> me access to an E35 so I could poke around the HP-UX
> iotree and see what I could find.
>
> This is the summary of what I have found:
>
> name_buffer instance hw_addr parent sibling child
> "bc" 1 56 0x43b3a0 0xc15240 0xc15040
> "scsi1" 0 52 0xc15000 0xe74140 0xc15080
> "" -1 53 0xc15000 0xc15200 0
> "mux2" 0 56 0xc15000 0 0
> "bus_adapter" 0 60 0x43b3a0 0xe74240 0xc15280
> "lan2" 0 6 0xc15240 0 0
> "processor" 0 62 0x43b3a0 0xe74280 0
> "memory" 0 63 0x43b3a0 0 0
>
> The MUX sits at: 56/56 with HPA: 0xfffb8000
>
> >From your boot logs posted to the mailing list:
>
> ---- walk_native_bus: testing hpa=0xfffb8000, i=56
> ---- walk_native_bus: -- device not processed, mod = i !
> ------ alloc_pa_dev: entry
> -------------------------- find_parisc_device: entry, mod=56
> -------------------------- find_parisc_device: bc[0]=-1
> -------------------------- find_parisc_device: bc[1]=-1
> -------------------------- find_parisc_device: bc[2]=-1
> -------------------------- find_parisc_device: bc[3]=-1
> -------------------------- find_parisc_device: bc[4]=-1
> -------------------------- find_parisc_device: bc[5]=-1
> -- walk_lower_bus: entry
> -- walk_lower_bus: dev: hpa=0xfffb8000, io_io_low=0xfff00000,
> io_io_high=0xfff80000
>
> You also found a device at 0xfffb8000 which I am assuming is the MUX.
> (I need to get back on the E35 at the ESIEE to verify my thoughts.)
>
> The problem we are running into here is that 0xfffb8000 is on the
> Central BUS, not under the 56/ bus as the console wants to be in
> the HP-UX iotree. It appears to me that the bc and the MUX exist
> at the same HPA and that is what is causing the confusion in the
> parisc-linux I/O tree.
>
> The other thing that is curious to me is the "" devices under the
> bc between the scsi1 and the mux2 device.
>
> I think I can get this problem solved once I get access to the
> ESIEE E35 and am able to boot some test kernels on the system to
> play with.
>
> As for the scsi driver. I have the bare-bones (ie. does not work)
> of both the skunk (8-bit) and the wizard (16-bit) drivers started from a
> while back. I think you found a reference to the SPIFI chip that we
> could use in the driver to further progress the drivers and hopefully
> get them talking.
>
> The document is the IOACD document I believe. What are you looking for?
> Parts of the document are on the parisc-linux website, but if that is
> not enough info, I'll try to find it for you in the IOACD.
>
> Thanks!
>
> - Ryan
>
> On Sat, 2002-09-07 at 15:36, Christoph Plattner wrote:
> > Hallo Ryan,
> >
> > after that long time, I did the first experiment with
> > your new MUX driver ...
> >
> > ... and it fails on my E55.
> >
> > But NO WONDER ! I already have the problem finding any
> > devices on the I/O interface card, and I had no time
> > since weeks now, to do further steps.
> >
> > In general I have the problem in basic stuff and in
> > docu, special for the I/O scanning via PDC in more
> > details. In the normal PDC/IO there is not enough docu
> > for that. I was informed, that there is one more docu
> > handling this, bt I forgot the name, something like
> > "AIO" or so.
> >
> > How we can go one step forward, as I also want to
> > start (in slowly steps) the SCSI driver ... ?
> >
> > Bye,
> > Christoph
> >
> >
> >
> > Ryan Bradetich wrote:
> > >
> > > Hello all,
> > >
> > > I just committed support for the Serial MUX driver as linux-2.4.19-pa5.
> > >
> > > This patch has been tested on my K460 and has been working well. The
> > > driver uses the same /dev/ttyB0 device the PDC Software console that
> > > Christoph Plattner wrote and is available under the Non-standard serial
> > > ports section.
> > >
> > > Currently the driver only supports the Eole CAP/MUX (A Direct) device
> > > since that is all I have to test with. Additional devices can be added
> > > under this driver as people with systems have a chance to test.
> > >
> > > I tried to document the driver with kerneldoc, but it would be nice if
> > > someone would check over my comment as I had to google/guess what most
> > > of the ioctls and tty flags were.
> > >
> > > The committed patch can be found at:
> > > ftp://ftp.parisc-linux.org/patches/serial_mux_v0.1.diff
> > >
> > > Feedback greatly appreciated!
> > >
> > > Thanks,
> > >
> > > - Ryan
> > >
> > > _______________________________________________
> > > parisc-linux mailing list
> > > parisc-linux@lists.parisc-linux.org
> > > http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
> >
> > --
> > -------------------------------------------------------
> > private: christoph.plattner@gmx.at
> > company: christoph.plattner@alcatel.at
> >
--
-------------------------------------------------------
private: christoph.plattner@gmx.at
company: christoph.plattner@alcatel.at
From steve@silug.org Sun Sep 8 13:42:05 2002
From: steve@silug.org (Steven Pritchard)
Date: Sun, 8 Sep 2002 07:42:05 -0500
Subject: [parisc-linux] [OT] cheap pa-risc hardware
Message-ID: <20020908074205.A9860@osiris.silug.org>
I was recently asked to help sell a pallet full of 712/60s, 712/80s,
735/125s, and 715/100s (plus a few J- and K-class servers and other
random hardware). Before I start hitting eBay, I was hoping that
someone on the list might have a good use for them. While they
wouldn't be free, I think they would be cheap. I've already warned
the guy in question that the older workstations aren't worth much,
especially since they don't seem to have any interesting hardware
(small disks, not much memory, no add-on cards).
If I had any spare money right now, I'd probably just buy the things
and donate them to a few Debian developers...
Please email me off-list if you have a use for them. I'll have exact
numbers early this week.
The systems are in St. Louis, if it matters.
Steve
--
steve@silug.org | Southern Illinois Linux Users Group
(618)398-7360 | See web site for meeting details.
Steven Pritchard | http://www.silug.org/
From christoph.plattner@gmx.at Sun Sep 8 22:45:57 2002
From: christoph.plattner@gmx.at (Christoph Plattner)
Date: Sun, 08 Sep 2002 23:45:57 +0200
Subject: [parisc-linux] Re: Status of parisc-linux on E45
References: <Pine.LNX.4.44.0209081652450.221-100000@kone.ihanaa.org>
Message-ID: <3D7BC515.2D31193A@gmx.at>
The status has not changed the last month. My E55 works
without MUX (except console via my PDC driver), SCSI
and parallel port.
At the momemt, I will start again play around accessing
the devices (I alreasy started a month ago, but other
work delayed this ...).
Christoph
Jussi Mäki wrote:
>
> Hi, we discussed about using linux on E45 couple of months ago..
>
> How well does parisc-linux work on E-series machine these days?
--
-------------------------------------------------------
private: christoph.plattner@gmx.at
company: christoph.plattner@alcatel.at
From grundler@dsl2.external.hp.com Sun Sep 8 22:56:02 2002
From: grundler@dsl2.external.hp.com (Grant Grundler)
Date: Sun, 08 Sep 2002 15:56:02 -0600
Subject: [parisc-linux] GNOME 1.4
In-Reply-To: Message from Alan Cox <alan@lxorguk.ukuu.org.uk>
of "30 Aug 2002 12:04:37 BST." <1030705477.3180.15.camel@irongate.swansea.linux.org.uk>
References: <1nismusojam12vial5vnqarbmfd8pb8mh7@4ax.com> <20020830040829.3BE694829@dsl2.external.hp.com> <1030705477.3180.15.camel@irongate.swansea.linux.org.uk>
Message-ID: <20020908215602.791B0482A@dsl2.external.hp.com>
Alan Cox wrote:
> The setup I use so I get a 'real desktop' not just old style X window
> mangler is xfce for the desktop with the rox filer on top for the file
> mangler, icon dock etc.
rox filer isn't available pre-built for hppa.
"dpkg-buildpackage -rfakeroot -uc -us" died with:
...
checking that libgtk2.0-dev (version >= 2.0.1) is installed... no
configure: error: Package is not installed
while on my system "dpkg -l libgtk\*" says:
...
ii libgtk2.0-0 2.0.2-5woody1 The GTK+ graphical user interface library
ii libgtk2.0-comm 2.0.2-5woody1 Common files for the GTK+ graphical user int
ii libgtk2.0-dbg 2.0.2-5woody1 The GTK+ libraries and debugging symbols
ii libgtk2.0-dev 2.0.2-5woody1 Development files for the GTK+ library.
Latest source depot's are below in case someone wants to beat rox config
tools into submission:
deb http://www.janw.easynet.be/rox/ developer/
deb-src http://www.janw.easynet.be/rox/ developer/
(one might try "stable/" instead of "developer/")
> I'd guess it would be very nice on an ancient parisc box too because
> they pa boxes probably have better I/O
I was thinking xfce is a window manager but it's not:
xfce is an easy-to-use and easy-to-configure toolbar for X11. Features
pulldown menus with color icons, 3D widgets, etc. It's designed to
work with XFwm, (window manager shipped with xfce)
It works on fine on my B180...but I didn't try it with XFwm as reccomended.
fvwm was still running...I'll try it again with XFwm.
thanks,
grant
From grundler@dsl2.external.hp.com Mon Sep 9 05:23:31 2002
From: grundler@dsl2.external.hp.com (Grant Grundler)
Date: Sun, 08 Sep 2002 22:23:31 -0600
Subject: [parisc-linux] Re: ide controller
In-Reply-To: Message from <moritz@sinnhq.de>
of "Mon, 09 Sep 2002 00:34:28 +0200." <32935.192.168.2.15.1031524468.squirrel@debian.sinnhq.de>
References: <32935.192.168.2.15.1031524468.squirrel@debian.sinnhq.de>
Message-ID: <20020909042331.75529482A@dsl2.external.hp.com>
moritz@sinnhq.de wrote:
> hi,
Hi,
This is a kernel question. I'm replying to a different list.
> i'd like to connect some big ide disks to my hp c240, which is running
> with debian gnu/linux.i tried an ultra ata ide controller from digitus.
> but when i load the module, the system crashes after detecting the
> controller.
Can you post details of the crash?
Console output?
kernel version?
maybe collect "ser pim" output from "boot_admin>" as well.
> i think that
> this is because of the lower voltage in the hp machines compared with an
> pc. but an standard pci network card works without problems.
> so does someone now an ide controller which works?
This has nothing to do with the voltage.
If the card fits, the voltage is OK.
grant
From jsoe0708@tiscali.be Mon Sep 9 17:27:22 2002
From: jsoe0708@tiscali.be (jsoe0708@tiscali.be)
Date: Mon, 9 Sep 2002 18:27:22 +0200
Subject: [parisc-linux] Inline Assembly Help request
Message-ID: <3D3815AF0000F2CA@ocpmta3.be.tiscali.com>
Hi all,
Continuing to figure out how to translate this C in assembly:
static inline int __put_user_u64(unsigned long long val, unsigned long long
* ptr)
{
int err;
err = (int) put_user((unsigned int)(val>>32) ,(unsigned int *)ptr);
err |= (int) put_user((unsigned int)val,(unsigned int *)ptr+1);
return err;
}
(needed for > evms-1.1.0)
With many luck, I found interresting references about online assembly in
gcc.
But I do not yet find explanation about details of the following asm code:
#define __put_user_asm(stx,x,ptr) \
__asm__ __volatile__ ( \
"\n1:\t" stx "\t%2,0(%%sr3,%1)\n" \
"2:\n" \
"\t.section __ex_table,\"a\"\n" \
"\t.word\t1b\n" \
"\t.word\t(2b-1b)+1\n" \
"\t.previous" \
: "=r"(__pu_err) \
: "r"(ptr), "r"(x), "0"(__pu_err))
which is more clear with gcc -S:
1: stw %r21,0(%sr3,%r19)
2:
.section __ex_table,"a"
.word 1b
.word (2b-1b)+1
.previous
My questions are:
what are the actual means "1:", "2:" (seems like label?)
and what means the rest
".section __ex_table,...
...
.previous"
I do not yet found reference on this part (even in Assembly-HOWTO).
Where could I found doc on this details?
Thanks in advance for attention,
Joel
Big Brother Anders - With Tiscali you will see it all ! Check it up on
www.tiscali.be/bigbrother
From dave@hiauly1.hia.nrc.ca Mon Sep 9 18:27:34 2002
From: dave@hiauly1.hia.nrc.ca (John David Anglin)
Date: Mon, 9 Sep 2002 13:27:34 -0400 (EDT)
Subject: [parisc-linux] Inline Assembly Help request
In-Reply-To: <3D3815AF0000F2CA@ocpmta3.be.tiscali.com> from "jsoe0708@tiscali.be" at Sep 9, 2002 06:27:22 pm
Message-ID: <200209091727.g89HRZF3021659@hiauly1.hia.nrc.ca>
> But I do not yet find explanation about details of the following asm code:
> #define __put_user_asm(stx,x,ptr) \
> __asm__ __volatile__ ( \
> "\n1:\t" stx "\t%2,0(%%sr3,%1)\n" \
> "2:\n" \
> "\t.section __ex_table,\"a\"\n" \
> "\t.word\t1b\n" \
> "\t.word\t(2b-1b)+1\n" \
> "\t.previous" \
> : "=r"(__pu_err) \
> : "r"(ptr), "r"(x), "0"(__pu_err))
>
> which is more clear with gcc -S:
>
> 1: stw %r21,0(%sr3,%r19)
> 2:
> .section __ex_table,"a"
> .word 1b
> .word (2b-1b)+1
> .previous
>
> My questions are:
> what are the actual means "1:", "2:" (seems like label?)
They are local labels that can be referenced in the asm. "b" and "f"
mean backwards and forward relative to the current location. This more
or less doubles the number of labels available.
> and what means the rest
> ".section __ex_table,...
> ...
> .previous"
>
> I do not yet found reference on this part (even in Assembly-HOWTO).
> Where could I found doc on this details?
The GCC manual (extend.texi) has documentation on writing asms. You
will need to look at the pa-risc architecture manuals for documentation
on PA assembler instructions.
The code is trying to setup a table using local labels generated
in the asm. The way to do this is highly port dependent.
In particular, indirect function calls are done using plabels on
the PA. There are also restrictions on the types of relocations
that can be used for constructing tables of this kind.
This is highly complex stuff and isn't very well documented. You
can read the HP runtime architecture document, the documentation on
ELF relocations and look at the code in the GNU assembler and linker.
The dwarf2 exception tables that you can generate with gcc 3.3
may also give some clue. Look at the entry for the personality
function and how the labels for C++ catches are encoded in the table.
Dave
--
J. David Anglin dave.anglin@nrc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6605)
From jonsharp@fastmail.ca Mon Sep 9 19:44:33 2002
From: jonsharp@fastmail.ca (Jon Sharp)
Date: Mon, 9 Sep 2002 14:44:33 -0400 (EDT)
Subject: [parisc-linux] Modem communication, HP 730
Message-ID: <3D7CEC11.00008F.38799@ns.interchange.ca>
--------------Boundary-00=_9EP6EVT66ERNTT4D7TH0
Content-Type: Text/Plain
Content-Transfer-Encoding: 7bit
Dear All,
I hope that I am sending this to an appropriate list. To be honest I
am running out of ideas.
I recently received a HP 730 which I am attempting to restore. I am
trying to install an external modem (V90 Velo Net ME220). However,
it is acting strangley. It works fine (using minicom) at connection
speeds of up to 19200, after that the modem fails to respond to AT
commands altogether.
I have read through both the serial and modem how-tos in detail and
tried what I could think of. Including using a large range of
different settings for setserial and stty. Does anyone have any idea
what I might be doing wrong? One interesting point to note, I have
no monitor or HIL keyboard and have been using the first serial port
(A) for a console.
Any advice would be greatly received,
Jon Sharp
__
'The art of good lecturing is to transfer the information from my
notes to your notes without it passing through eithers brain.'
Cambridge University Lecturer
_________________________________________________________________
http://fastmail.ca/ - Fast Secure Web Email for Canadians
--------------Boundary-00=_9EP6EVT66ERNTT4D7TH0--
From jochen@scram.de Mon Sep 9 22:46:47 2002
From: jochen@scram.de (Jochen Friedrich)
Date: Mon, 9 Sep 2002 23:46:47 +0200 (CEST)
Subject: [parisc-linux] definition of EWOULDBLOCK in /usr/include/asm/errno.h
Message-ID: <Pine.LNX.4.44.0209092343150.2394-100000@alpha.bocc.de>
Hi,
because of the unusual definition of EWOULDBLOCK, zebra currently doesn't
work (zebra checks for EWOULDBLOCK in zebra/rt_netlink.c and will loop if
it gets EAGAIN instead and both are not the same).
I'm not sure what's the correct fix for this, change errno.h to match the
definition of the other archs or change zebra to check for EAGAIN as
well...
Cheers,
--jochen
From jochen@scram.de Mon Sep 9 23:02:08 2002
From: jochen@scram.de (Jochen Friedrich)
Date: Tue, 10 Sep 2002 00:02:08 +0200 (CEST)
Subject: [parisc-linux] db3/db4 patch for Linux/HPPA (fwd)
Message-ID: <Pine.LNX.4.44.0209092358400.2394-100000@alpha.bocc.de>
Hi,
the same applies to 4.0.14, as well.
Cheers,
--jochen
---------- Forwarded message ----------
Date: Fri, 16 Aug 2002 07:54:04 +0200 (CEST)
From: Jochen Friedrich <jochen@scram.de>
To: Matthew Wilcox <willy@debian.org>
Cc: HP900 PARISC mailing list <parisc-linux@lists.parisc-linux.org>
Subject: [parisc-linux] db3 patch for Linux/HPPA
Hi Matthew,
this fixes a problem with db3 mutexes. Problem is in
__db_tas_mutex_init(). If MUTEX_INIT returns non-zero value, mutexp->spins
doesn't get initialized and later __db_tas_mutex_lock loops without ever
trying to aquire the lock (as spins is zero).
diff -urN db-3.2.9/include/mutex.h db-3.2.9.new/include/mutex.h
--- db-3.2.9/include/mutex.h Sun Jun 23 16:34:28 2002
+++ db-3.2.9.new/include/mutex.h Sun Jun 23 16:33:38 2002
@@ -413,7 +413,7 @@
__r & 1; \
})
-#define MUTEX_UNSET(tsl) (*(tsl) = -1)
+#define MUTEX_UNSET(tsl) (!(*(tsl) = -1))
#define MUTEX_INIT(tsl) MUTEX_UNSET(tsl)
#endif
#endif
Cheers,
--jochen
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
From Randolph Chung <randolph@tausq.org> Mon Sep 9 23:04:49 2002
From: Randolph Chung <randolph@tausq.org> (Randolph Chung)
Date: Mon, 9 Sep 2002 15:04:49 -0700
Subject: [parisc-linux] definition of EWOULDBLOCK in /usr/include/asm/errno.h
In-Reply-To: <Pine.LNX.4.44.0209092343150.2394-100000@alpha.bocc.de>
References: <Pine.LNX.4.44.0209092343150.2394-100000@alpha.bocc.de>
Message-ID: <20020909220448.GP17893@tausq.org>
> because of the unusual definition of EWOULDBLOCK, zebra currently doesn't
> work (zebra checks for EWOULDBLOCK in zebra/rt_netlink.c and will loop if
> it gets EAGAIN instead and both are not the same).
>
> I'm not sure what's the correct fix for this, change errno.h to match the
> definition of the other archs or change zebra to check for EAGAIN as
> well...
I assume you are refering to this bit of code:
status = recvmsg (nl->sock, &msg, 0);
if (status < 0)
{
if (errno == EINTR)
continue;
if (errno == EWOULDBLOCK)
break;
zlog (NULL, LOG_ERR, "%s recvmsg overrun", nl->name);
continue;
}
On some SysV systems EAGAIN != EWOULDBLOCK. I think we inherited the
errno definitions from HPUX...
glibc's documentation says:
Portability Note: In many older Unix systems, this condition was indicated by EWOULDBLOCK, which was a distinct error code different from EAGAIN. To make your program portable, you should check for both codes and treat them the same.
sounds like good advice to me.. :-)
it does say, however, that for glibc EWOULDBLOCK and EAGAIN should have
the same value though, so i guess ours is wrong... i wonder if we'll
break things if we changed it.
randolph
--
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/
From will@misconception.org.uk Tue Sep 10 00:36:17 2002
From: will@misconception.org.uk (Will Newton)
Date: Tue, 10 Sep 2002 00:36:17 +0100
Subject: [parisc-linux] C++ crash on hppa
Message-ID: <E17oY3b-0004rg-00.2002-09-10-00-35-05@imailg1.svr.pol.co.uk>
(This is a repost of a message to debian-hppa, sorry if I hit anyone with it
twice.)
I have a package that works perfectly on i386 but crashes on hppa. The code
is not anything that would be directly affected by the underlying hardware -
it makes no assumptions based on endianess or word size - and the crash
occurs because of a free of a null pointer inside the STL. I have attached
the backtrace. I'm really quite stumped by this one, so any help would be
greatly appreciated.
(Maybe something to do with static init order in dynamic libs?)
(gdb) bt
#0 0x4071210c in __libc_free (mem=0x0) at malloc.c:3142
#1 0x0002e95c in std::__malloc_alloc_template<0>::deallocate(void*,
unsigned) ()
#2 0x0002de54 in std::__default_alloc_template<true, 0>::deallocate(void*,
unsigned) ()
#3 0x0002cd40 in std::allocator<char>::deallocate(char*, unsigned) ()
#4 0x0002aa20 in std::string::_Rep::_M_destroy(std::allocator<char> const&)
()
#5 0x00028230 in std::string::_Rep::_M_dispose(std::allocator<char> const&)
()
#6 0x00028a58 in std::string::assign(std::string const&) ()
#7 0x4019e93c in Aqsis::CqOptions::InitialiseDefaultOptions() (
this=0x402c2a9c) at /usr/include/c++/3.2/bits/basic_string.h:338
#8 0x4019d9dc in CqOptions (this=0x402c2a9c) at options.cpp:193
#9 0x401e81c0 in __static_initialization_and_destruction_0
(__initialize_p=1, __priority=65535) at renderer.cpp:50
#10 0x402061ec in _GLOBAL__I__ZN5Aqsis13pCurrRendererE ()
at /usr/include/c++/3.2/bits/stl_iterator.h:622
#11 0x40272be8 in __do_global_ctors_aux () from /usr/lib/libaqsis.so.0
#12 0x4015dc4c in _init () from /usr/lib/libaqsis.so.0
#13 0x4000cf8c in call_init () from /lib/ld.so.1
#14 0x4000d0fc in _dl_init () from /lib/ld.so.1
#15 0x400023dc in _dl_start_user () from /lib/ld.so.1
(gdb)
Thanks,
-------------------------------------------------------
From support@sleepycat.com Tue Sep 10 02:19:11 2002
From: support@sleepycat.com (Sleepycat support)
Date: Mon, 9 Sep 2002 18:19:11 -0700 (PDT)
Subject: [parisc-linux] Re: db3/db4 patch for Linux/HPPA [#6581]
In-Reply-To: <Pine.LNX.4.44.0209092358400.2394-100000@alpha.bocc.de>
Message-ID: <200209100119.g8A1JBu96414@triplerock.olsons.net>
> the same applies to 4.0.14, as well.
Thank you for your email. For future reference, your Support
Request number is #6581. An engineer will be contacting you.
Regards,
Sleepycat Software Support
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Sleepycat Software Inc. support@sleepycat.com
http://www.sleepycat.com
From bostic@sleepycat.com Tue Sep 10 02:43:03 2002
From: bostic@sleepycat.com (Keith Bostic)
Date: Mon, 9 Sep 2002 21:43:03 -0400 (EDT)
Subject: [parisc-linux] Re: db3/db4 patch for Linux/HPPA [#6581]
Message-ID: <200209100143.g8A1h3F17414@abyssinian.sleepycat.com>
Hi, my name is Keith Bostic and I'm with Sleepycat Software.
I'll own your Support Request for now.
Please copy "support@sleepycat.com" on any email you send,
and include the tag [#6581] in your email Subject lines.
That allows us to track the email discussion and for you to
get prompt replies even if I am not in the office.
> the same applies to 4.0.14, as well.
Thanks for finding this one! I used a slightly different fix,
since MUTEX_UNSET isn't supposed to return a value. Here's what
I ended up using, please let me know if you disagree with this
change.
*** include/mutex.h 2002/08/15 06:42:38 11.70
--- include/mutex.h 2002/09/10 01:36:48 11.71
***************
*** 435,441 ****
})
#define MUTEX_UNSET(tsl) (*(tsl) = -1)
! #define MUTEX_INIT(tsl) MUTEX_UNSET(tsl)
#endif
#endif
--- 435,441 ----
})
#define MUTEX_UNSET(tsl) (*(tsl) = -1)
! #define MUTEX_INIT(tsl) (MUTEX_UNSET(tsl), 0)
#endif
#endif
Regards,
--keith
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Keith Bostic
Sleepycat Software Inc. bostic@sleepycat.com
118 Tower Rd. +1-781-259-3139
Lincoln, MA 01773 http://www.sleepycat.com
From grundler@dsl2.external.hp.com Tue Sep 10 05:29:38 2002
From: grundler@dsl2.external.hp.com (Grant Grundler)
Date: Mon, 09 Sep 2002 22:29:38 -0600
Subject: [parisc-linux] Modem communication, HP 730
In-Reply-To: Message from "Jon Sharp" <jonsharp@fastmail.ca>
of "Mon, 09 Sep 2002 14:44:33 EDT." <3D7CEC11.00008F.38799@ns.interchange.ca>
References: <3D7CEC11.00008F.38799@ns.interchange.ca>
Message-ID: <20020910042938.A37F8482A@dsl2.external.hp.com>
"Jon Sharp" wrote:
> It works fine (using minicom) at connection
> speeds of up to 19200, after that the modem fails to respond to AT
> commands altogether.
Does anyone know at which speeds HW handshaking is necessary?
730 is a pretty old machine.
grant
From derekengelhaupt@rocketmail.com Tue Sep 10 05:54:10 2002
From: derekengelhaupt@rocketmail.com (Derek Engelhaupt)
Date: Mon, 9 Sep 2002 21:54:10 -0700 (PDT)
Subject: [parisc-linux] Modem communication, HP 730
In-Reply-To: <20020910042938.A37F8482A@dsl2.external.hp.com>
Message-ID: <20020910045410.61028.qmail@web12501.mail.yahoo.com>
I know the internal modem of the K-class is limited to 19200. All of
the support modems we install for the systems are slowed down to 19200
even though they are 56k. Coincidence?
derek
--- Grant Grundler <grundler@dsl2.external.hp.com> wrote:
> "Jon Sharp" wrote:
> > It works fine (using minicom) at connection
> > speeds of up to 19200, after that the modem fails to respond to AT
> > commands altogether.
>
> Does anyone know at which speeds HW handshaking is necessary?
> 730 is a pretty old machine.
>
> grant
> _______________________________________________
> parisc-linux mailing list
> parisc-linux@lists.parisc-linux.org
> http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
__________________________________________________
Yahoo! - We Remember
9-11: A tribute to the more than 3,000 lives lost
http://dir.remember.yahoo.com/tribute
From derekengelhaupt@rocketmail.com Tue Sep 10 06:00:39 2002
From: derekengelhaupt@rocketmail.com (Derek Engelhaupt)
Date: Mon, 9 Sep 2002 22:00:39 -0700 (PDT)
Subject: [parisc-linux] E55
In-Reply-To: <20020910042938.A37F8482A@dsl2.external.hp.com>
Message-ID: <20020910050039.46620.qmail@web12506.mail.yahoo.com>
I was just curious how far in the boot process you E55 guys get. I
just tried to load the one I have in the office tonight. I retrofitted
it with an A1703-60003 LAN/Console/SCSI card I pulled out of one of our
"crash and burn" H70 boxes. It gets past the "console" message about
"if this is the last thing you see" then starts dumping the stacks and
ends in a Kernal error 15. This card doesn't use the mux port to
connect the console it uses a PS/2 type connector to the card and a
DB25 connector to the terminal. Just wanted to see how this compares
to the other E Series machines out there.
derek
__________________________________________________
Yahoo! - We Remember
9-11: A tribute to the more than 3,000 lives lost
http://dir.remember.yahoo.com/tribute
From grundler@dsl2.external.hp.com Tue Sep 10 06:24:31 2002
From: grundler@dsl2.external.hp.com (Grant Grundler)
Date: Mon, 09 Sep 2002 23:24:31 -0600
Subject: [parisc-linux] Modem communication, HP 730
In-Reply-To: Message from Derek Engelhaupt <derekengelhaupt@rocketmail.com>
of "Mon, 09 Sep 2002 21:54:10 PDT." <20020910045410.61028.qmail@web12501.mail.yahoo.com>
References: <20020910045410.61028.qmail@web12501.mail.yahoo.com>
Message-ID: <20020910052431.8592F482A@dsl2.external.hp.com>
Derek Engelhaupt wrote:
> I know the internal modem of the K-class is limited to 19200. All of
> the support modems we install for the systems are slowed down to 19200
> even though they are 56k. Coincidence?
Maybe not. Does the modem connect directly the console manager or
whatever it's called? That might be the limiting factor.
Could I cut off the goofy connector for K-class modem, solder on a DB-9
(or DB25) and have a cool external 56k Modem?
If so, I only need to know what the pinout is since power probably
comes through the cable as well.
I've seen so many of those go in the trash here.
grant
From rbradetich@uswest.net Tue Sep 10 07:19:48 2002
From: rbradetich@uswest.net (Ryan Bradetich)
Date: 10 Sep 2002 00:19:48 -0600
Subject: [parisc-linux] E55
In-Reply-To: <20020910050039.46620.qmail@web12506.mail.yahoo.com>
References: <20020910050039.46620.qmail@web12506.mail.yahoo.com>
Message-ID: <1031638789.10553.15.camel@beavis>
I have been playing with an E35 and I can get the boot to go farther
then that. Right now the boot is failing somewhere between the LED
detection and the POSIX conformance testing by UNIFIX. I do not
really care about this failure right now since I am really only
interested in the discovering the missing devices on these systems.
Tonight, I found the missing devices on the system and I am currently
working on figuring out how to integrate this discovery into the
bus walk code. I hope to have a patch committed within the next day
or so which detects all the devices on the system. After that I will
add this failure to my TODO list (if the ESIEE will still let me have
access to this system, but i am hoping that someone else will take the
challenge and find/fix the problem :))
Thanks,
- Ryan
On Mon, 2002-09-09 at 23:00, Derek Engelhaupt wrote:
> I was just curious how far in the boot process you E55 guys get. I
> just tried to load the one I have in the office tonight. I retrofitted
> it with an A1703-60003 LAN/Console/SCSI card I pulled out of one of our
> "crash and burn" H70 boxes. It gets past the "console" message about
> "if this is the last thing you see" then starts dumping the stacks and
> ends in a Kernal error 15. This card doesn't use the mux port to
> connect the console it uses a PS/2 type connector to the card and a
> DB25 connector to the terminal. Just wanted to see how this compares
> to the other E Series machines out there.
>
> derek
>
> __________________________________________________
> Yahoo! - We Remember
> 9-11: A tribute to the more than 3,000 lives lost
> http://dir.remember.yahoo.com/tribute
> _______________________________________________
> parisc-linux mailing list
> parisc-linux@lists.parisc-linux.org
> http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
>
From derekengelhaupt@rocketmail.com Tue Sep 10 08:25:05 2002
From: derekengelhaupt@rocketmail.com (Derek Engelhaupt)
Date: Tue, 10 Sep 2002 00:25:05 -0700 (PDT)
Subject: [parisc-linux] Modem communication, HP 730
In-Reply-To: <20020910052431.8592F482A@dsl2.external.hp.com>
Message-ID: <20020910072505.62218.qmail@web12505.mail.yahoo.com>
Grant,
That thing you speak of is not the modem...the modem is inside the K.
That thing is called a LAM. Local Access Module. It varied from
country to country so they don't have to change the modem only the LAM.
The modem acctually plugs into the Core i/o board via a set of about
20 pins that actually come throught the modem board. Very easy to bend
and get out of alignment.
derek
--- Grant Grundler <grundler@dsl2.external.hp.com> wrote:
> Derek Engelhaupt wrote:
> > I know the internal modem of the K-class is limited to 19200. All
> of
> > the support modems we install for the systems are slowed down to
> 19200
> > even though they are 56k. Coincidence?
>
> Maybe not. Does the modem connect directly the console manager or
> whatever it's called? That might be the limiting factor.
>
> Could I cut off the goofy connector for K-class modem, solder on a
> DB-9
> (or DB25) and have a cool external 56k Modem?
> If so, I only need to know what the pinout is since power probably
> comes through the cable as well.
>
> I've seen so many of those go in the trash here.
>
> grant
__________________________________________________
Yahoo! - We Remember
9-11: A tribute to the more than 3,000 lives lost
http://dir.remember.yahoo.com/tribute
From q-funk@pp.fishpool.fi Tue Sep 10 15:59:29 2002
From: q-funk@pp.fishpool.fi (=?iso-8859-1?Q?Martin-=C9ric_Racine?=)
Date: Tue, 10 Sep 2002 17:59:29 +0300 (EEST)
Subject: [parisc-linux] Re: accessing TOS and VFAT partitions on Linux (fwd)
Message-ID: <Pine.LNX.4.21.0209101752260.28289-100000@hal.pp.fishpool.fi>
I have submitted this to the m68k list first, hoping that someone might kno=
w,
and this is where Richard Zidlicky tried to help, but it looks like this _m=
ight_
be dependant upon an m68k-only patch... or is it?
Should the 2.4.18 kernel distributed thru the Woody/hppa tree be able to fi=
nd
not just Atari partitions, but also Atari's own flavor of DOS filesystem?
The kernel I run is based upon the defaults found in the 2.4.18-32 kernel, =
but
has Atari partitions support enabled.
PS: I do not subscribe to parisc-linux, only to debian-hppa; please CC to =
me.
--=20
Martin-=C9ric Racine, Espoo, Finland.
"Kas sa tahad mind? - Nej!!! =C4r du en idiot?!!"
http://www.pp.fishpool.fi/~q-funk/
---------- Forwarded message ----------
Date: Tue, 10 Sep 2002 14:37:28 +0200
From: Richard Zidlicky <rz@linux-m68k.org>
To: Martin-=C9ric Racine <q-funk@pp.fishpool.fi>
Subject: Re: accessing TOS and VFAT partitions on Linux
On Tue, Sep 10, 2002 at 03:09:57PM +0300, Martin-=C9ric Racine wrote:
> On Tue, 10 Sep 2002, Richard Zidlicky wrote:
>=20
> > On Tue, Sep 10, 2002 at 08:36:29AM +0300, Martin-=C9ric Racine wrote:
> > > > > Is there any special trick to access those FAT partitions on Linu=
x?
> > > >=20
> > > > use 'atari=3Dyes' option to mount it.. doesn't appear to have it ma=
de into the
> > > > manpages yet?
> > >=20
> > > Nor does it appear to work. :(
> >=20
> > what does it say? Kernel or mount problem?=20
>=20
> The relevant part of /etc/fstab:
>=20
> /dev/sdb1 /TT030/C msdos defaults,errors=3Dremount-ro,atari=3Dyes 0 2
> /dev/sdb2 /TT030/D msdos defaults,errors=3Dremount-ro,atari=3Dyes 0 2
> /dev/sdb3 /TT030/E ext2 defaults,errors=3Dremount-ro 0 2
> /dev/sdb4 /TT030/F ext2 defaults,errors=3Dremount-ro 0 2
> /dev/sdb5 /TT030/G ext2 defaults,errors=3Dremount-ro 0 2
> /dev/sdb6 /TT030/H ext2 defaults,errors=3Dremount-ro 0 2
> /dev/sdb7 /TT030/I vfat defaults,errors=3Dremount-ro,atari=3Dyes 0 2
> /dev/sdb8 /TT030/J swap sw 0 2
> /dev/sdb9 /TT030/K ext2 defaults,errors=3Dremount-ro 0 2
> /dev/sdb10 /TT030/L msdos defaults,errors=3Dremount-ro,atari=3Dyes 0 2
> /dev/sdb11 /TT030/M ext2 defaults,errors=3Dremount-ro 0 2
>=20
> <root@zarya:/root># mount -a
> mount: wrong fs type, bad option, bad superblock on /dev/sdb1,
> or too many mounted file systems
> mount: wrong fs type, bad option, bad superblock on /dev/sdb2,
> or too many mounted file systems
> mount: wrong fs type, bad option, bad superblock on /dev/sdb7,
> or too many mounted file systems
> mount: wrong fs type, bad option, bad superblock on /dev/sdb10,
> or too many mounted file systems
this looks like kernel problem than.. not quite sure if or when
that stuff was ever merged into mainline kernel. Certainly not
before 2.4.13.
>=20
> Linux zarya 2.4.18 #3 ti elo=A027 02:15:57 EEST 2002 parisc unknown unkno=
wn GNU/Linux
>=20
> > Quite possible that you will need to fetch a kernel from linux-m68k-cvs=
=2Eapia.dhs.org
>=20
> You produce non-m68k kernels too? ;-)
the diff between m68k and Linus tree is very small in 2.4.19, our
kernels should work perfectly on x86. Certainly not optimised for
parisc though :(
Compare your fs/fat/inode.c with ours, possibly also 2.4.19.
> > > Is that "atari=3Dyes" option found only in a special version of mount=
?
> >=20
> > doesn't appear like special support were required here, I know only the=
=20
> > kernel side of it. It would be possible to compile a special 386 kernel=
=20
> > with that parameter hardcoded into it (in fs/fat/inode.c change=20
> > #ifdef CONFIG_ATARI to #if 1). Might not work with ordinary MSDOS volum=
es
> > very well than.
>=20
> That's not desirable, of course.
might be worth a try, after looking at the stuff it appears to do some
autodetection. It should certainly continue to work at least on MSDOS
floppies.
Richard
From carlos@baldric.uwo.ca Tue Sep 10 17:18:29 2002
From: carlos@baldric.uwo.ca (Carlos O'Donell)
Date: Tue, 10 Sep 2002 12:18:29 -0400
Subject: [parisc-linux] HPUX guru needed -> definition of EWOULDBLOCK in /usr/include/asm/errno.h
In-Reply-To: <20020909220448.GP17893@tausq.org>
References: <Pine.LNX.4.44.0209092343150.2394-100000@alpha.bocc.de> <20020909220448.GP17893@tausq.org>
Message-ID: <20020910161829.GD2732@systemhalted>
>
> On some SysV systems EAGAIN != EWOULDBLOCK. I think we inherited the
> errno definitions from HPUX...
>
> glibc's documentation says:
>
> Portability Note: In many older Unix systems, this condition was indicated by EWOULDBLOCK, which was a distinct error code different from EAGAIN. To make your program portable, you should check for both codes and treat them the same.
>
> sounds like good advice to me.. :-)
>
> it does say, however, that for glibc EWOULDBLOCK and EAGAIN should have
> the same value though, so i guess ours is wrong... i wonder if we'll
> break things if we changed it.
>
> randolph
I agree with randolph, you should change the code to check for EAGAIN aswell.
On the other hand...
We have to do both of the following in order to maintain backwards compatibility.
I'm all for ignoring that and just doing 'b' :}
a. Emulate EWOULDBLOCK == EAGAIN in assembly during syscall errors.
- Added code to glibc :(
See:
glibc-2.2.5/sysdeps/unix/i386/sysdep.S
glibc-2.2.5/sysdeps/unix/sparc/sysdep.S
glibc-2.2.5/sysdeps/unix/x86_64/sysdep.S
glibc-2.2.5/sysdeps/unix/arm/sysdep.S
...
b. Just change the kernel header to alias EWOULDBLOCK as EAGAIN.
--- linux/include/asm-parisc/errno.h 1999-12-24 12:05:04.000000000 -0500
+++ linux/include/asm-parisc/errno.h.new 2002-09-10 12:09:52.000000000 -0400
@@ -134,7 +134,7 @@
#define EALREADY 244 /* Operation already in progress */
#define EINPROGRESS 245 /* Operation now in progress */
-#define EWOULDBLOCK 246 /* Operation would block (Linux returns EAGAIN) */
+#define EWOULDBLOCK EAGAIN /* Operation would block (Linux returns EAGAIN) */
#define ENOTEMPTY 247 /* Directory not empty */
#define ENAMETOOLONG 248 /* File name too long */
#define ELOOP 249 /* Too many symbolic links encountered */
This seems best since I don't really see any code in ioctl32.c that returns
EWOULDBLOCK :) We just confuse the applicaiton by providing a different value.
Does this have anything to do with HPUX compatibility? Would an HPUX application
expect different semantic meansings from these two values?
c.
From christoph.plattner@gmx.at Tue Sep 10 19:00:43 2002
From: christoph.plattner@gmx.at (Christoph Plattner)
Date: Tue, 10 Sep 2002 20:00:43 +0200
Subject: [parisc-linux] E55
References: <20020910050039.46620.qmail@web12506.mail.yahoo.com>
Message-ID: <3D7E334B.98E1AC47@gmx.at>
I have the E55 as it is, without any additional card,
and with my PDC Console driver I can completely boot
the system and work on it. BUT: Only via NFS Root,
as there is currently no SCSI support, no support
for the MUX (except port 0 as console with the PDC
driver) and without parallel (printer) port.
But Linux runs completely, including login, remote
X usage (xterm, etc...), access to the internet via
LAN, etc, ....
Hi Ryan, you have found the device ? This one on the
BC ? Sounds gooooooood !
Christoph
Derek Engelhaupt wrote:
>
> I was just curious how far in the boot process you E55 guys get. I
> just tried to load the one I have in the office tonight. I retrofitted
> it with an A1703-60003 LAN/Console/SCSI card I pulled out of one of our
> "crash and burn" H70 boxes. It gets past the "console" message about
> "if this is the last thing you see" then starts dumping the stacks and
> ends in a Kernal error 15. This card doesn't use the mux port to
> connect the console it uses a PS/2 type connector to the card and a
> DB25 connector to the terminal. Just wanted to see how this compares
> to the other E Series machines out there.
>
> derek
>
> __________________________________________________
> Yahoo! - We Remember
> 9-11: A tribute to the more than 3,000 lives lost
> http://dir.remember.yahoo.com/tribute
> _______________________________________________
> parisc-linux mailing list
> parisc-linux@lists.parisc-linux.org
> http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
--
-------------------------------------------------------
private: christoph.plattner@gmx.at
company: christoph.plattner@alcatel.at
From jochen@scram.de Tue Sep 10 21:22:07 2002
From: jochen@scram.de (Jochen Friedrich)
Date: Tue, 10 Sep 2002 22:22:07 +0200 (CEST)
Subject: [parisc-linux] definition of EWOULDBLOCK in /usr/include/asm/errno.h
In-Reply-To: <20020909220448.GP17893@tausq.org>
Message-ID: <Pine.LNX.4.44.0209102220520.6365-100000@alpha.bocc.de>
Hi Randolph,
> Portability Note: In many older Unix systems, this condition was indicated by EWOULDBLOCK, which was a distinct error code different from EAGAIN. To make your program portable, you should check for both codes and treat them the same.
>
> sounds like good advice to me.. :-)
It's fixed this way in current zebra CVS. However, there might be other
applications which might be hit by this, as well.
Cheers,
--jochen
From viiru@debian.org Thu Sep 12 06:48:34 2002
From: viiru@debian.org (Arto Jantunen)
Date: Thu, 12 Sep 2002 08:48:34 +0300
Subject: [parisc-linux] SMP problems
Message-ID: <20020912054834.GA32209@www1.dt-link.fi>
--17pEHd4RhPHOinZp
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
This is a HP9000/R390 machine, or atleast the previous owner
said so. It has two PA8200 cpu's running at 240Mhz, but I have
disabled the second cpu for debuging this problem. As you can see
from the attached minicom capture, if running an SMP kernel with
only one cpu, it crashes. It also crashes when running on two cpu's,
which is why I am reporting this. This proves that the problem has
nothing to do with the two cpu's stepping on each others toes or
anything. The machine runs perfectly stable on an UP kernel. Any
comments, suggestions of things that I could do to help someone
debug it and anything else is welcome. Please CC me on replies,
I'm not on the list.
--
Arto Jantunen
--17pEHd4RhPHOinZp
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="minicom.cap"
Content-Transfer-Encoding: quoted-printable
Firmware Version 38.39
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 240 MHz Active Functional 2 MB
1 240 MHz Stopped:Deconfigured Unknown 2 MB
Central Bus Speed (in MHz) : 120=20
Model: R390/2
Available memory (bytes) : 1073733632=20
Good memory required (bytes): 86876160=20
Primary boot path: 8/4.1 (dec) =20
Alternate boot path: 8/4.6 (dec) =20
Console path: 8/16/4.0 (dec) =20
Keyboard path: 8/16/7.0 (dec) =20
CPU 0
WARNING: Memory has been initialized, but not tested as a result of
FASTBOOT being enabled. To test memory, use the FASTBOOT
command in the CONFIGURATION menu and reboot the system.
Processor is starting autoboot process.
To discontinue, press any key within 10 seconds.
10 seconds expired.
Proceeding...
Trying Primary Boot Path
------------------------
Booting...=20
Boot IO Dependent Code (IODC) revision 152
HARD Booted.
palo ipl 1.0 root@palinux Mon Apr 1 10:02:53 MST 2002
Partition Start(MB) End(MB) Id Type
1 1 16 f0 Palo
2 49 1002 82 swap
3 1003 4094 83 ext2
4 17 48 83 ext2
PALO(F0) partition contains:
0/vmlinux32 3687647 bytes @ 0x48000
Information: No console specified on kernel command line. This is normal.
PALO will choose the console currently used by firmware (serial).
Command line for kernel: 'root=3D/dev/sda3 HOME=3D/ console=3DttyS0 TERM=3D=
vt102 palo_kernel=3D4/vmlinux'
Selected kernel: /vmlinux from partition 4
ELF32 executable
Entry 00100000 first 00100000 n 6
Segment 0 load 00100000 size 1893508 mediaptr 0x1000
Segment 1 load 002d0000 size 596888 mediaptr 0x1d0000
Segment 2 load 00364000 size 221560 mediaptr 0x262000
Segment 3 load 0039c000 size 8192 mediaptr 0x299000
Segment 4 load 003a0000 size 32768 mediaptr 0x29b000
Segment 5 load 003e38a4 size 82000 mediaptr 0x2a38a4
Branching to kernel entry point 0x00100000. If this is the last
message you see, you may need to switch your console. This is
a common symptom -- search the FAQ and mailing list at parisc-linux.org
Linux version 2.4.19-pa14 (root@elli) (gcc version 3.0.4) #1 SMP Wed Sep 11=
12:54:30 EEST 2002
FP[0] enabled: Rev 0 Model 14
The 32-bit Kernel has started...
Determining PDC firmware type: System Map.
model 00005ba0 00000491 00000000 00000002 7777173a 100000f0 00000008 000000=
b2 000000b2
vers 00000501
CPUID vers 14 rev 23 (0x000001d7)
capabilities 0x3
model 9000/800/R390
Total Memory: 1024 Mb
pagetable_init
On node 0 totalpages: 262144
zone(0): 262144 pages.
zone(1): 0 pages.
zone(2): 0 pages.
Kernel command line: root=3D/dev/sda3 HOME=3D/ console=3DttyS0 TERM=3Dvt102=
palo_kernel=3D4/vmlinux
Console: colour dummy device 160x64
Calibrating delay loop... 478.41 BogoMIPS
Memory: 1033080k available
Dentry cache hash table entries: 131072 (order: 8, 1048576 bytes)
Inode cache hash table entries: 65536 (order: 7, 524288 bytes)
Mount-cache hash table entries: 16384 (order: 5, 131072 bytes)
Buffer-cache hash table entries: 65536 (order: 6, 262144 bytes)
Page-cache hash table entries: 262144 (order: 8, 1048576 bytes)
Searching for devices...
Found devices:
1. U2-IOA BC Runway Port (12) at 0xfff88000 [8], versions 0x580, 0xf, 0xb
2. Bluefish Add-on FW-SCSI (4) at 0xf1004000 [8/4], versions 0x13, 0x1, 0x89
3. HP HSC-PCI Cards (4) at 0xf1008000 [8/8], versions 0x4, 0x0, 0x9d
4. UL 550 Lasi Core BA (11) at 0xffd00000 [8/16], versions 0x2f, 0x0, 0x81,=
additional addresses: 0xffd0c000 0xffc00000=20
5. UL 550 Core Centronics (10) at 0xffd02000 [8/16/0], versions 0x2f, 0x0, =
0x74, additional addresses: 0xffd01000 0xffd03000=20
6. UL 550 Lasi Core RS-232 (10) at 0xffd05000 [8/16/4], versions 0x2f, 0x0,=
0x8c
7. UL 550 Core SCSI (10) at 0xffd06000 [8/16/5], versions 0x2f, 0x0, 0x82
8. UL 350 Core LAN (802.3) (10) at 0xffd07000 [8/16/6], versions 0x2f, 0x0,=
0x8a
9. UL 550 Core PS/2 Port (10) at 0xffd08000 [8/16/7], versions 0x2f, 0x0, 0=
x84
10. UL 550 Core PS/2 Port (10) at 0xffd08100 [8/16/8], versions 0x2f, 0x0, =
0x84
11. UL 550 Core Wax BA (11) at 0xffe00000 [8/20], versions 0x31, 0x0, 0x8e
12. UL 550 Wax Core RS-232 (10) at 0xffe02000 [8/20/2], versions 0x31, 0x0,=
0x8c
13. UL 550 Wax EISA BA (11) at 0xfc000000 [8/20/5], versions 0x31, 0x0, 0x9=
0, additional addresses: 0xffc88000=20
14. U2-IOA BC GSC+ Port (7) at 0xf103f000 [8/63], versions 0x501, 0x1, 0xc
15. U2-IOA BC Runway Port (12) at 0xfff8a000 [10], versions 0x580, 0xf, 0xb
16. Bluefish Add-on FW-SCSI (4) at 0xf180c000 [10/12], versions 0x13, 0x1, =
0x89
17. U2-IOA BC GSC+ Port (7) at 0xf183f000 [10/63], versions 0x501, 0x1, 0xc
18. UL 2w U+/240 (350/550) (0) at 0xfffa0000 [32], versions 0x5ba, 0x0, 0x4
19. Memory (1) at 0xfffb1000 [49], versions 0x7e, 0x0, 0x9
CPU(s): 1 x PA8200 (PCX-U+) at 240.000000 MHz
Found U2 at 0xfff88000
Found U2 at 0xfff8a000
Lasi version 0 at 0xffd00000 found.
LED display at ffd0c000 registered
Wax at 0xffe00000 found.
Wax EISA Adapter found at 0xfc000000
EISA EEPROM at 0xffc88000
Enumerating EISA bus
EISA slot 1 a configured board was not detected ( expected ___FFFF)
Dino version 3.x (card mode) found at 0xf1008000
Dino: Failed to allocate memory region
POSIX conformance testing by UNIFIX
SMP: Bootstrap processor only.
SMP: Total 1 of 1 processors activated (478.41 BogoMIPS noticed).
Waiting on wait_init_idle (map =3D 0x0)
All processors have done init_idle
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Initializing RT netlink socket
Soft power switch enabled, polling @ 0xf0140000.
Starting kswapd
VFS: Diskquotas version dquot_6.4.0 initialized
Journalled Block Device driver loaded
parport_init_chip: initialize bidirectional-mode.
parport0: PC-style at 0xffd02800, irq 88 [PCSPP,TRISTATE]
pty: 256 Unix98 ptys configured
Serial driver version 5.05c (2001-07-08) with MANY_PORTS SHARE_IRQ SERIAL_P=
CI enabled
ttyS00 at iomem 0xffd05800 (irq =3D 90) is a 16550A
ttyS01 at iomem 0xffe02800 (irq =3D 121) is a 16550A
PS/2 keyboard port at 0xffd08000 (irq 69) found, no device attached.
lp0: using parport0 (interrupt-driven).
Generic RTC Driver v1.02 05/27/1999 Sam Creasey (sammy@oh.verio.com)
RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
Found i82596 at 0xffd07000, IRQ 87
eth0: 82596 at 0xffd07000, 08 00 09 A3 38 14 IRQ 87.
82596.c $Revision: 1.29 $
SCSI subsystem driver Revision: 1.00
zalon_scsi_callback: Zalon vers field is 0x1, IRQ 36
ncr53c8xx: 53c720 detected
ncr53c720-0: ID 7, Fast-10, Parity Checking, Differential
zalon_scsi_callback: Zalon vers field is 0x1, IRQ 37
ncr53c8xx: 53c720 detected
ncr53c720-1: ID 7, Fast-10, Parity Checking, Differential
scsi0 : ncr53c8xx-3.4.3b-20010512
scsi1 : ncr53c8xx-3.4.3b-20010512
Vendor: SEAGATE Model: ST34573WC Rev: HP11
Type: Direct-Access ANSI SCSI revision: 02
Vendor: SEAGATE Model: ST34573WC Rev: HP11
Type: Direct-Access ANSI SCSI revision: 02
Vendor: SEAGATE Model: ST34573WC Rev: HP11
Type: Direct-Access ANSI SCSI revision: 02
Vendor: SEAGATE Model: ST34573WC Rev: HP11
Type: Direct-Access ANSI SCSI revision: 02
Vendor: SEAGATE Model: ST34573WC Rev: HP11
Type: Direct-Access ANSI SCSI revision: 02
Vendor: SEAGATE Model: ST34573WC Rev: HP15
Type: Direct-Access ANSI SCSI revision: 02
Vendor: SEAGATE Model: ST34573WC Rev: HP11
Type: Direct-Access ANSI SCSI revision: 02
Vendor: SEAGATE Model: ST34573WC Rev: HP11
Type: Direct-Access ANSI SCSI revision: 02
Vendor: SEAGATE Model: ST34573WC Rev: HP15
Type: Direct-Access ANSI SCSI revision: 02
Vendor: SEAGATE Model: ST34573WC Rev: HP11
Type: Direct-Access ANSI SCSI revision: 02
Vendor: SEAGATE Model: ST34573WC Rev: HP11
Type: Direct-Access ANSI SCSI revision: 02
Vendor: SEAGATE Model: ST34573WC Rev: HP11
Type: Direct-Access ANSI SCSI revision: 02
53c700: Version 2.7 By James.Bottomley@HansenPartnership.com
scsi2: 53c710 rev 2=20
scsi2 : LASI SCSI 53c700
scsi2: (2:0) Synchronous at offset 8, period 100ns
Vendor: HP Model: DVD-ROM 6x/32x Rev: 1.08
Type: CD-ROM ANSI SCSI revision: 02
scsi2: (3:0) Synchronous at offset 8, period 100ns
Vendor: HP Model: C1537A Rev: HP02
Type: Sequential-Access ANSI SCSI revision: 02
st: Version 20020205, bufsize 32768, wrt 30720, max init. bufs 4, s/g segs =
16
Attached scsi tape st0 at scsi2, channel 0, id 3, lun 0
Attached scsi disk sda at scsi0, channel 0, id 1, lun 0
Attached scsi disk sdb at scsi0, channel 0, id 2, lun 0
Attached scsi disk sdc at scsi0, channel 0, id 3, lun 0
Attached scsi disk sdd at scsi0, channel 0, id 4, lun 0
Attached scsi disk sde at scsi0, channel 0, id 5, lun 0
Attached scsi disk sdf at scsi0, channel 0, id 6, lun 0
Attached scsi disk sdg at scsi1, channel 0, id 1, lun 0
Attached scsi disk sdh at scsi1, channel 0, id 2, lun 0
Attached scsi disk sdi at scsi1, channel 0, id 3, lun 0
Attached scsi disk sdj at scsi1, channel 0, id 4, lun 0
Attached scsi disk sdk at scsi1, channel 0, id 5, lun 0
Attached scsi disk sdl at scsi1, channel 0, id 6, lun 0
ncr53c720-0-<1,*>: FAST-10 WIDE SCSI 20.0 MB/s (100 ns, offset 8)
SCSI device sda: 8388314 512-byte hdwr sectors (4295 MB)
Partition check:
sda: sda1 sda2 sda3 sda4
ncr53c720-0-<2,*>: FAST-10 WIDE SCSI 20.0 MB/s (100 ns, offset 8)
SCSI device sdb: 8388314 512-byte hdwr sectors (4295 MB)
sdb: unknown partition table
ncr53c720-0-<3,*>: FAST-10 WIDE SCSI 20.0 MB/s (100 ns, offset 8)
SCSI device sdc: 8388314 512-byte hdwr sectors (4295 MB)
sdc: unknown partition table
ncr53c720-0-<4,*>: FAST-10 WIDE SCSI 20.0 MB/s (100 ns, offset 8)
SCSI device sdd: 8388314 512-byte hdwr sectors (4295 MB)
sdd: unknown partition table
ncr53c720-0-<5,*>: FAST-10 WIDE SCSI 20.0 MB/s (100 ns, offset 8)
SCSI device sde: 8388314 512-byte hdwr sectors (4295 MB)
sde: unknown partition table
ncr53c720-0-<6,*>: FAST-10 WIDE SCSI 20.0 MB/s (100 ns, offset 8)
SCSI device sdf: 8388314 512-byte hdwr sectors (4295 MB)
sdf: unknown partition table
ncr53c720-1-<1,*>: FAST-10 WIDE SCSI 20.0 MB/s (100 ns, offset 8)
SCSI device sdg: 8388314 512-byte hdwr sectors (4295 MB)
sdg: unknown partition table
ncr53c720-1-<2,*>: FAST-10 WIDE SCSI 20.0 MB/s (100 ns, offset 8)
SCSI device sdh: 8388314 512-byte hdwr sectors (4295 MB)
sdh: unknown partition table
ncr53c720-1-<3,*>: FAST-10 WIDE SCSI 20.0 MB/s (100 ns, offset 8)
SCSI device sdi: 8388314 512-byte hdwr sectors (4295 MB)
sdi: unknown partition table
ncr53c720-1-<4,*>: FAST-10 WIDE SCSI 20.0 MB/s (100 ns, offset 8)
SCSI device sdj: 8388314 512-byte hdwr sectors (4295 MB)
sdj: unknown partition table
ncr53c720-1-<5,*>: FAST-10 WIDE SCSI 20.0 MB/s (100 ns, offset 8)
SCSI device sdk: 8388314 512-byte hdwr sectors (4295 MB)
sdk: unknown partition table
ncr53c720-1-<6,*>: FAST-10 WIDE SCSI 20.0 MB/s (100 ns, offset 8)
SCSI device sdl: 8388314 512-byte hdwr sectors (4295 MB)
sdl: unknown partition table
Attached scsi CD-ROM sr0 at scsi2, channel 0, id 2, lun 0
sr0: scsi3-mmc drive: 0x/0x cd/rw xa/form2 cdda tray
Uniform CD-ROM driver Revision: 3.12
md: linear personality registered as nr 1
md: raid0 personality registered as nr 2
md: raid1 personality registered as nr 3
md: raid5 personality registered as nr 4
raid5: measuring checksumming speed
8regs : 504.400 MB/sec
8regs_prefetch: 443.600 MB/sec
32regs : 459.600 MB/sec
32regs_prefetch: 432.400 MB/sec
raid5: using function: 8regs (504.400 MB/sec)
md: md driver 0.90.0 MAX_MD_DEVS=3D256, MD_SB_DISKS=3D27
md: Autodetecting RAID arrays.
md: autorun ...
md: ... autorun DONE.
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP, IGMP
IP: routing cache hash table of 1024 buckets, 48Kbytes
TCP: Hash tables configured (established 32768 bind 65536)
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
VFS: Mounted root (ext2 filesystem) readonly.
Freeing unused kernel memory: 216k freed
INIT: version 2.84 booting
Activating swap.
Adding Swap: 977140k swap-space (priority -1)
Checking root file system...
fsck 1.28 (31-Aug-2002)
/dev/sda3: clean, 30096/396000 files, 160528/791616 blocks
System time was Thu Sep 12 05:23:22 UTC 2002.
Setting the System Clock using the Hardware Clock as reference...
System Clock set. System local time is now Thu Sep 12 05:23:20 UTC 2002.
Calculating module dependencies... done.
Loading modules:=20
Starting RAID devices: [events: 00000012]
[events: 00000012]
[events: 00000012]
[events: 00000012]
[events: 00000012]
[events: 00000012]
md: autorun ...
md: considering sdg ...
md: adding sdg ...
md: adding sdf ...
md: adding sde ...
md: adding sdd ...
md: adding sdc ...
md: adding sdb ...
md: created md0
md: bind<sdb,1>
md: bind<sdc,2>
md: bind<sdd,3>
md: bind<sde,4>
md: bind<sdf,5>
md: bind<sdg,6>
md: running: <sdg><sdf><sde><sdd><sdc><sdb>
md: sdg's event counter: 00000012
md: sdf's event counter: 00000012
md: sde's event counter: 00000012
md: sdd's event counter: 00000012
md: sdc's event counter: 00000012
md: sdb's event counter: 00000012
md0: max total readahead window set to 992k
md0: 4 data-disks, max readahead per data-disk: 248k
raid5: spare disk sdg
raid5: device sdf operational as raid disk 4
raid5: device sde operational as raid disk 3
raid5: device sdd operational as raid disk 2
raid5: device sdc operational as raid disk 1
raid5: device sdb operational as raid disk 0
raid5: allocated 5436kB for md0
raid5: raid level 5 set md0 active with 5 out of 5 devices, algorithm 2
RAID5 conf printout:
--- rd:5 wd:5 fd:0
disk 0, s:0, o:1, n:0 rd:0 us:1 dev:sdb
disk 1, s:0, o:1, n:1 rd:1 us:1 dev:sdc
disk 2, s:0, o:1, n:2 rd:2 us:1 dev:sdd
disk 3, s:0, o:1, n:3 rd:3 us:1 dev:sde
disk 4, s:0, o:1, n:4 rd:4 us:1 dev:sdf
RAID5 conf printout:
--- rd:5 wd:5 fd:0
disk 0, s:0, o:1, n:0 rd:0 us:1 dev:sdb
disk 1, s:0, o:1, n:1 rd:1 us:1 dev:sdc
disk 2, s:0, o:1, n:2 rd:2 us:1 dev:sdd
disk 3, s:0, o:1, n:3 rd:3 us:1 dev:sde
disk 4, s:0, o:1, n:4 rd:4 us:1 dev:sdf
md: updating md0 RAID superblock on device
md: sdg [events: 00000013]<6>(write) sdg's sb offset: 4194048
md: sdf [events: 00000013]<6>(write) sdf's sb offset: 4194048
md: sde [events: 00000013]<6>(write) sde's sb offset: 4194048
md: sdd [events: 00000013]<6>(write) sdd's sb offset: 4194048
md: sdc [events: 00000013]<6>(write) sdc's sb offset: 4194048
md: sdb [events: 00000013]<6>(write) sdb's sb offset: 4194048
md: ... autorun DONE.
/dev/md0 done.
Checking all file systems...
fsck 1.28 (31-Aug-2002)
/dev/sda4: clean, 25/8256 files, 18237/32769 blocks
Setting kernel variables.
Mounting local filesystems...
/dev/sda4 on /boot type ext2 (rw)
Running 0dns-down to make sure resolv.conf is ok...done.
Cleaning: /etc/network/ifstate.
Setting up IP spoofing protection: rp_filter.
Configuring network interfaces: eth0: link ok.
done.
Setting the System Clock using the Hardware Clock as reference...
System Clock set. Local time: Thu Sep 12 08:23:37 EEST 2002
Cleaning: /tmp /var/lock /var/run.
Initializing random number generator... done.
Recovering nvi editor sessions... done.
INIT: Entering runlevel: 2
Starting system log daemon: syslogd.
Starting kernel log daemon: klogd.
Starting OpenLDAP: slapd.
Starting internet superserver: inetd.
Starting mail transport agent: Postfix.
Starting OpenBSD Secure Shell server: sshd.
Starting teapop: teapop.
Starting deferred execution scheduler: atd.
Starting periodic command scheduler: cron.
Debian GNU/Linux testing/unstable elli ttyS0
elli login: root
Password:=20
Last login: Wed Sep 11 15:47:34 2002 on ttyS0
Linux elli 2.4.19-pa14 #1 SMP Wed Sep 11 12:54:30 EEST 2002 parisc unknown =
unknown GNU/Linux
Most of the programs included with the Debian GNU/Linux system are
freely redistributable; the exact distribution terms for each program
are described in the individual files in /usr/share/doc/*/copyright
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
elli:~# uname -=08 =08=08 =08=08 =08=08 =08=08 =08=08 =08=08 =08=07=07=07=
=07cat /proc/pcu=08 =08=08 =08=08 =08cpuinfo
processor : 0
cpu family : PA-RISC 2.0
cpu : PA8200 (PCX-U+)
cpu MHz : 240.000000
model : 9000/800/R390
model name : UL 2w U+/240 (350/550)
hversion : 0x00005ba0
sversion : 0x00000491
I-cache : 2048 KB
D-cache : 2048 KB (WB)
ITLB entries : 120
DTLB entries : 120 - shared with ITLB
bogomips : 478.41
software id : 2004293434
elli:~# sync && apt-get update
0% [Working] Hit http://security.debian.org stable/updates/main =
Packages
Hit http://security.debian.org stable/updates/main Release
Hit http://security.debian.org stable/updates/contrib Packages
Hit http://security.debian.org stable/updates/contrib Release
Hit http://security.debian.org stable/updates/non-free Packages
Hit http://security.debian.org stable/updates/non-free Release
19% [Connecting to ftp.fi.debian.org] [Waiting for file] =
Get:1 http://non-us.debian=
.org unstable/non-US/main Packages [34.2kB]
3% [Connecting to f=
tp.fi.debian.org (130.230.54.99)] [1 Packages 1106/34.2kB 3%] =
Get:2 htt=
p://ftp.fi.debian.org unstable/main Packages [1945kB]
=
0% [2 Packages 1093/1945kB 0%] [1 Packages 8346/34.2kB 24%] =
7% [2 Packages 115485/1945k=
B 5%] [Waiting for file] =
Get:3 http://non-us.debian.org unstable/non-US/main Release [89B]
Hit http://non-us.debian=
.org unstable/non-US/contrib Packages
Get:4 http://non-us.debi=
an.org unstable/non-US/contrib Release [92B]
Hit http://non-us.debian=
.org unstable/non-US/non-free Packages
Get:5 http://non-us.debi=
an.org unstable/non-US/non-free Release [93B]
Hit http://non-us.debian=
.org stable/non-US/main Sources
Hit http://non-us.debian=
.org stable/non-US/main Release
Hit http://non-us.debian=
.org stable/non-US/contrib Sources
7% [2 Packages 115485/1945kB 5%] [Waiting for file] =
Hit http://non-us.debian.org stable/non-US/contr=
ib Release
7% [2 Packages 115485/1945kB 5%] [Waiting for file] =
7% [1 Packages gzip 0] [2 Packages 115485/1945kB=
5%] [Waiting for file] =
Hit http://non-us.debian.org stable/non-US/non-free Sour=
ces
Hit =
http://non-us.debian.org stable/non-US/non-free Release
10% =
[1 Packages gzip 0] [2 Packages 174853/1945kB 8%] =
11% [2 Packages 190781/1945kB 9%] =
15% [2 Packages 280557/1945kB 14%]20% [2 Packages 376125/=
1945kB 19%]25% [2 Packages 465901/1945kB 23%]30% [2 Packages 564365/1945kB =
29%]34% [2 Packages 649797/1945kB 33%]37% [2 Packages 712061/1945kB 36%]41%=
[2 Packages 783013/1945kB 40%]45% [2 Packages 856861/1945kB 44%] =
48% [2 Packages 924917/1945kB 47%] =
153kB/s 6s51% [2 Packages 992973/1945kB 51%] =
153kB/s 6s55% [2 Packages 1072613/1945kB 55%] =
153kB/s 5s59% [2 Packages 1152253/1945kB 59%] =
153kB/s 5s62% [2 Packages 1198589/1945kB =
61%] 153kB/s 4s67% [2 Packages 1292709/19=
45kB 66%] 153kB/s 4s70% [2 Packages 13607=
65/1945kB 69%] 153kB/s 3s74% [2 Packages =
1431717/1945kB 73%] 153kB/s 3s78% [2 Pack=
ages 1509909/1945kB 77%] 153kB/s 2s81% [2=
Packages 1585205/1945kB 81%] 153kB/s 2s8=
5% [2 Packages 1661949/1945kB 85%] 153kB/=
s 1s90% [2 Packages 1750277/1945kB 89%] 1=
53kB/s 1s93% [2 Packages 1813989/1945kB 93%] =
153kB/s 0s97% [2 Packages 1897973/1945kB 97%] =
150kB/s 0s =
Get:6 http://ftp.fi.debian.org unstable/main Releas=
e [82B]
=
Hit http://ftp.fi.debian.org unstable/non-free Packages
=
Get:7 http://ftp.fi.debian.org unstable/non-free Release [86B]
=
Get:8 http://ftp.fi.debian.org unstable/contrib Packages [47.8kB]
97% [8 Packages 2308/47.8kB 4%] 150kB=
/s 0s97% [2 Packages gzip 0] [8 Packages 2308/47.8kB 4%] =
150kB/s 0s =
Get:9 http://ftp.fi.debian.org unstable/contrib Release [85B]
=
Hit http://ftp.fi.debian.org stable/main Sources
=
Hit http://ftp.fi.debian.org stable/main Release
=
Hit http://ftp.fi.debian.org stable/non-free Sources
=
Hit http://ftp.fi.debian.org stable/non-free Release
=
Hit http://ftp.fi.debian.org stable/contrib Sources
=
Hit http://ftp.fi.debian.org stable/contrib Release
99% [2 Packages gzip 212992] 150kB=
/s 0s99% [2 Packages gzip 2093056] =
150kB/s 0s99% [2 Packages gzip 4059136] =
150kB/s 0s99% [2 Packages gzip 5926912] =
150kB/s 0s99% [Working] =
150kB/s 0s99% [8 Packages gzip 0] =
150kB/s 0s100% [Working] =
150kB/s 0s =
Fetched 2027kB in 15s (131kB/s)
Reading Package Lists... 0%apt-get(285): unaligned access to 0x403cf08c at =
ip=3D0x4005e4f7
Reading Package=20
Lists... 0%
High Priority Machine Check (HPMC): Code=3D1 regs=3D102ea080 (Addr=3D000000=
00)
--17pEHd4RhPHOinZp--
From rbradetich@uswest.net Thu Sep 12 07:04:18 2002
From: rbradetich@uswest.net (Ryan Bradetich)
Date: 12 Sep 2002 00:04:18 -0600
Subject: [parisc-linux] SMP problems
In-Reply-To: <20020912054834.GA32209@www1.dt-link.fi>
References: <20020912054834.GA32209@www1.dt-link.fi>
Message-ID: <1031810658.9835.60.camel@beavis>
Hello Arto,
I have also seen this problem on the K460 when running SMP, where as
the UP kernel works fine. I have started to debug this problem once,
but I got side tracked and have not gotten back to finish debugging
this problem. I do not think I will have time to look at it before
next week, but I will see what I can find next week.
Thanks,
- Ryan.
P.S. When talking with Richard Hirst about this problem, we thought it
might be a Copy On Write problem, since the problem appears to be with
apt-get. Last time (a couple of months ago) I tried it dpkg -i <pkg>
worked fine.
On Wed, 2002-09-11 at 23:48, Arto Jantunen wrote:
> This is a HP9000/R390 machine, or atleast the previous owner
> said so. It has two PA8200 cpu's running at 240Mhz, but I have
> disabled the second cpu for debuging this problem. As you can see
> from the attached minicom capture, if running an SMP kernel with
> only one cpu, it crashes. It also crashes when running on two cpu's,
> which is why I am reporting this. This proves that the problem has
> nothing to do with the two cpu's stepping on each others toes or
> anything. The machine runs perfectly stable on an UP kernel. Any
> comments, suggestions of things that I could do to help someone
> debug it and anything else is welcome. Please CC me on replies,
> I'm not on the list.
>
> --
> Arto Jantunen
> ----
>
From jeremyd@apptechsys.com Thu Sep 12 07:52:28 2002
From: jeremyd@apptechsys.com (Jeremy Drake)
Date: Wed, 11 Sep 2002 23:52:28 -0700 (PDT)
Subject: [parisc-linux] SMP problems (hardware gurus, please read)
In-Reply-To: <20020912054834.GA32209@www1.dt-link.fi>
Message-ID: <Pine.LNX.4.44.0209112338570.1464-100000@garibaldi.apptechsys.com>
I have the exact same problem on my J5000. apt-get update and samba are
the two things that tend to crash it immediately. It can run fairly well
SMP w/o doing either of these. Also, X is now also crashing SMP (not sure
if/when things changed, as I wasn't running graphics for a while, and
can't clearly remember running X on smp).
The HPMC had an odd thing in the IO stuff -
> > '9000/785 B,C,J Workstation IO Error Log', rev 0, 228 bytes:
> >
> > Rope Word1 Word2 Word3
> > ------ ------------ ------------
> > 0 0x00000000 0x0e0cc009 0x00000000fed30048
> > 1 0x00000000 0x1e0cc009 0x00000000fed32048
> > 2 ---------- 0x2e0cc229 ------------------
> > 3 ---------- 0x3e0cc009 ------------------
> > 4 0x00000000 0x4e0cc009 0x00000000fed38048
> > 5 ---------- 0x5e0cc009 ------------------
> > 6 0x00000000 0x6e0cc009 0x00000000fed3c048
> > 7 ---------- 0x7e0cc009 ------------------
And here is one from another time:
'9000/785 B,C,J Workstation IO Error Log', rev 0, 228 bytes:
Rope Word1 Word2 Word3
------ ------------ ------------
0 0x00000000 0x0e0cc009 0x00000000fed30048
1 0x00000000 0x1e0cc009 0x00000000fed32048
2 ---------- 0x2e0cc229 ------------------
3 ---------- 0x3f4fd808 ------------------
4 0x00000000 0x40000008 0xffffffffffffffff
5 ---------- 0x50000008 ------------------
6 0x00000000 0x60000008 0xffffffffffffffff
7 ---------- 0x70100008 ------------------
possibly, could you send the output of ser pim after such a crash. Here's
the general idea:
interrupt the boot process, and at the BOOT_ADMIN prompt type "ser
clearpim". then bo pri. Crash the box, reboot it, interrupt it again,
and type ser pim. I am particularly interested in the io part (should be
at the end)...
Also, are there any HP hardware gurus out there that can explain these odd
io numbers? Could they be relevant?
On Thu, 12 Sep 2002, Arto
Jantunen wrote:
> This is a HP9000/R390 machine, or atleast the previous owner
> said so. It has two PA8200 cpu's running at 240Mhz, but I have
> disabled the second cpu for debuging this problem. As you can see
> from the attached minicom capture, if running an SMP kernel with
> only one cpu, it crashes. It also crashes when running on two cpu's,
> which is why I am reporting this. This proves that the problem has
> nothing to do with the two cpu's stepping on each others toes or
> anything. The machine runs perfectly stable on an UP kernel. Any
> comments, suggestions of things that I could do to help someone
> debug it and anything else is welcome. Please CC me on replies,
> I'm not on the list.
>
> --
> Arto Jantunen
>
--
During the next two hours, the system will be going up and down several
times, often with lin~po_~{po ~poz~ppo\~{ o n~po_~{o[po ~y oodsou>#w4k**n~po_~{ol;lkld;f;g;dd;po\~{o
From viiru@debian.org Thu Sep 12 10:10:18 2002
From: viiru@debian.org (Arto Jantunen)
Date: Thu, 12 Sep 2002 12:10:18 +0300
Subject: [parisc-linux] SMP problems (hardware gurus, please read)
In-Reply-To: <Pine.LNX.4.44.0209112338570.1464-100000@garibaldi.apptechsys.com>
References: <20020912054834.GA32209@www1.dt-link.fi> <Pine.LNX.4.44.0209112338570.1464-100000@garibaldi.apptechsys.com>
Message-ID: <20020912091018.GA16372@dt-link.fi>
--LZvS9be/3tNcYl/X
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
On Wed, Sep 11, 2002 at 11:52:28PM -0700, Jeremy Drake wrote:
> I have the exact same problem on my J5000. apt-get update and samba are
> the two things that tend to crash it immediately. It can run fairly well
> SMP w/o doing either of these. Also, X is now also crashing SMP (not sure
> if/when things changed, as I wasn't running graphics for a while, and
> can't clearly remember running X on smp).
>
> The HPMC had an odd thing in the IO stuff -
>
> > > '9000/785 B,C,J Workstation IO Error Log', rev 0, 228 bytes:
> > >
> > > Rope Word1 Word2 Word3
> > > ------ ------------ ------------
> > > 0 0x00000000 0x0e0cc009 0x00000000fed30048
> > > 1 0x00000000 0x1e0cc009 0x00000000fed32048
> > > 2 ---------- 0x2e0cc229 ------------------
> > > 3 ---------- 0x3e0cc009 ------------------
> > > 4 0x00000000 0x4e0cc009 0x00000000fed38048
> > > 5 ---------- 0x5e0cc009 ------------------
> > > 6 0x00000000 0x6e0cc009 0x00000000fed3c048
> > > 7 ---------- 0x7e0cc009 ------------------
>
> And here is one from another time:
>
> '9000/785 B,C,J Workstation IO Error Log', rev 0, 228 bytes:
>
> Rope Word1 Word2 Word3
> ------ ------------ ------------
> 0 0x00000000 0x0e0cc009 0x00000000fed30048
> 1 0x00000000 0x1e0cc009 0x00000000fed32048
> 2 ---------- 0x2e0cc229 ------------------
> 3 ---------- 0x3f4fd808 ------------------
> 4 0x00000000 0x40000008 0xffffffffffffffff
> 5 ---------- 0x50000008 ------------------
> 6 0x00000000 0x60000008 0xffffffffffffffff
> 7 ---------- 0x70100008 ------------------
>
> possibly, could you send the output of ser pim after such a crash. Here's
> the general idea:
>
> interrupt the boot process, and at the BOOT_ADMIN prompt type "ser
> clearpim". then bo pri. Crash the box, reboot it, interrupt it again,
> and type ser pim. I am particularly interested in the io part (should be
> at the end)...
>
> Also, are there any HP hardware gurus out there that can explain these odd
> io numbers? Could they be relevant?
I did this, but the stuff I got from ser pim is almost all zeroes.
I'm attaching it anyway, but I don't think it is correct. I rebooted
by shutting it down from the power switch, is there a "softer" way
to do it (I only have a serial console)?
--LZvS9be/3tNcYl/X
Content-Type: text/plain; charset=unknown-8bit
Content-Disposition: attachment; filename="minicom.cap"
Content-Transfer-Encoding: quoted-printable
Firmware Version 38.39
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 240 MHz Active Functional 2 MB
1 240 MHz Stopped:Deconfigured Unknown 2 MB
Central Bus Speed (in MHz) : 120=20
Model: R390/2
Available memory (bytes) : 1073733632=20
Good memory required (bytes): 86876160=20
Primary boot path: 8/4.1 (dec) =20
Alternate boot path: 8/4.6 (dec) =20
Console path: 8/16/4.0 (dec) =20
Keyboard path: 8/16/7.0 (dec) =20
CPU 0
WARNING: Memory has been initialized, but not tested as a result of
FASTBOOT being enabled. To test memory, use the FASTBOOT
command in the CONFIGURATION menu and reboot the system.
Processor is starting autoboot process.
To discontinue, press any key within 10 seconds.
10 seconds expired.
Proceeding...
Trying Primary Boot Path
------------------------
Booting...=20
Boot IO Dependent Code (IODC) revision 152
HARD Booted.
palo ipl 1.0 root@palinux Mon Apr 1 10:02:53 MST 2002
Partition Start(MB) End(MB) Id Type
1 1 16 f0 Palo
2 49 1002 82 swap
3 1003 4094 83 ext2
4 17 48 83 ext2
PALO(F0) partition contains:
0/vmlinux32 3687647 bytes @ 0x48000
Information: No console specified on kernel command line. This is normal.
PALO will choose the console currently used by firmware (serial).
Command line for kernel: 'root=3D/dev/sda3 HOME=3D/ console=3DttyS0 TERM=3D=
vt102 palo_kernel=3D4/vmlinux'
Selected kernel: /vmlinux from partition 4
ELF32 executable
Entry 00100000 first 00100000 n 6
Segment 0 load 00100000 size 1893508 mediaptr 0x1000
Segment 1 load 002d0000 size 596888 mediaptr 0x1d0000
Segment 2 load 00364000 size 221560 mediaptr 0x262000
Segment 3 load 0039c000 size 8192 mediaptr 0x299000
Segment 4 load 003a0000 size 32768 mediaptr 0x29b000
Segment 5 load 003e38a4 size 82000 mediaptr 0x2a38a4
Branching to kernel entry point 0x00100000. If this is the last
message you see, you may need to switch your console. This is
a common symptom -- search the FAQ and mailing list at parisc-linux.org
Linux version 2.4.19-pa14 (root@elli) (gcc version 3.0.4) #1 SMP Wed Sep 11=
12:54:30 EEST 2002
FP[0] enabled: Rev 0 Model 14
The 32-bit Kernel has started...
Determining PDC firmware type: System Map.
model 00005ba0 00000491 00000000 00000002 7777173a 100000f0 00000008 000000=
b2 000000b2
vers 00000501
CPUID vers 14 rev 23 (0x000001d7)
capabilities 0x3
model 9000/800/R390
Total Memory: 1024 Mb
pagetable_init
On node 0 totalpages: 262144
zone(0): 262144 pages.
zone(1): 0 pages.
zone(2): 0 pages.
Kernel command line: root=3D/dev/sda3 HOME=3D/ console=3DttyS0 TERM=3Dvt102=
palo_kernel=3D4/vmlinux
Console: colour dummy device 160x64
Calibrating delay loop... 478.41 BogoMIPS
Memory: 1033080k available
Dentry cache hash table entries: 131072 (order: 8, 1048576 bytes)
Inode cache hash table entries: 65536 (order: 7, 524288 bytes)
Mount-cache hash table entries: 16384 (order: 5, 131072 bytes)
Buffer-cache hash table entries: 65536 (order: 6, 262144 bytes)
Page-cache hash table entries: 262144 (order: 8, 1048576 bytes)
Searching for devices...
Found devices:
1. U2-IOA BC Runway Port (12) at 0xfff88000 [8], versions 0x580, 0xf, 0xb
2. Bluefish Add-on FW-SCSI (4) at 0xf1004000 [8/4], versions 0x13, 0x1, 0x89
3. HP HSC-PCI Cards (4) at 0xf1008000 [8/8], versions 0x4, 0x0, 0x9d
4. UL 550 Lasi Core BA (11) at 0xffd00000 [8/16], versions 0x2f, 0x0, 0x81,=
additional addresses: 0xffd0c000 0xffc00000=20
5. UL 550 Core Centronics (10) at 0xffd02000 [8/16/0], versions 0x2f, 0x0, =
0x74, additional addresses: 0xffd01000 0xffd03000=20
6. UL 550 Lasi Core RS-232 (10) at 0xffd05000 [8/16/4], versions 0x2f, 0x0,=
0x8c
7. UL 550 Core SCSI (10) at 0xffd06000 [8/16/5], versions 0x2f, 0x0, 0x82
8. UL 350 Core LAN (802.3) (10) at 0xffd07000 [8/16/6], versions 0x2f, 0x0,=
0x8a
9. UL 550 Core PS/2 Port (10) at 0xffd08000 [8/16/7], versions 0x2f, 0x0, 0=
x84
10. UL 550 Core PS/2 Port (10) at 0xffd08100 [8/16/8], versions 0x2f, 0x0, =
0x84
11. UL 550 Core Wax BA (11) at 0xffe00000 [8/20], versions 0x31, 0x0, 0x8e
12. UL 550 Wax Core RS-232 (10) at 0xffe02000 [8/20/2], versions 0x31, 0x0,=
0x8c
13. UL 550 Wax EISA BA (11) at 0xfc000000 [8/20/5], versions 0x31, 0x0, 0x9=
0, additional addresses: 0xffc88000=20
14. U2-IOA BC GSC+ Port (7) at 0xf103f000 [8/63], versions 0x501, 0x1, 0xc
15. U2-IOA BC Runway Port (12) at 0xfff8a000 [10], versions 0x580, 0xf, 0xb
16. Bluefish Add-on FW-SCSI (4) at 0xf180c000 [10/12], versions 0x13, 0x1, =
0x89
17. U2-IOA BC GSC+ Port (7) at 0xf183f000 [10/63], versions 0x501, 0x1, 0xc
18. UL 2w U+/240 (350/550) (0) at 0xfffa0000 [32], versions 0x5ba, 0x0, 0x4
19. Memory (1) at 0xfffb1000 [49], versions 0x7e, 0x0, 0x9
CPU(s): 1 x PA8200 (PCX-U+) at 240.000000 MHz
Found U2 at 0xfff88000
Found U2 at 0xfff8a000
Lasi version 0 at 0xffd00000 found.
LED display at ffd0c000 registered
Wax at 0xffe00000 found.
Wax EISA Adapter found at 0xfc000000
EISA EEPROM at 0xffc88000
Enumerating EISA bus
EISA slot 1 a configured board was not detected ( expected ___FFFF)
Dino version 3.x (card mode) found at 0xf1008000
Dino: Failed to allocate memory region
POSIX conformance testing by UNIFIX
SMP: Bootstrap processor only.
SMP: Total 1 of 1 processors activated (478.41 BogoMIPS noticed).
Waiting on wait_init_idle (map =3D 0x0)
All processors have done init_idle
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Initializing RT netlink socket
Soft power switch enabled, polling @ 0xf0140000.
Starting kswapd
VFS: Diskquotas version dquot_6.4.0 initialized
Journalled Block Device driver loaded
parport_init_chip: initialize bidirectional-mode.
parport0: PC-style at 0xffd02800, irq 88 [PCSPP,TRISTATE]
pty: 256 Unix98 ptys configured
Serial driver version 5.05c (2001-07-08) with MANY_PORTS SHARE_IRQ SERIAL_P=
CI enabled
ttyS00 at iomem 0xffd05800 (irq =3D 90) is a 16550A
ttyS01 at iomem 0xffe02800 (irq =3D 121) is a 16550A
PS/2 keyboard port at 0xffd08000 (irq 69) found, no device attached.
lp0: using parport0 (interrupt-driven).
Generic RTC Driver v1.02 05/27/1999 Sam Creasey (sammy@oh.verio.com)
RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
Found i82596 at 0xffd07000, IRQ 87
eth0: 82596 at 0xffd07000, 08 00 09 A3 38 14 IRQ 87.
82596.c $Revision: 1.29 $
SCSI subsystem driver Revision: 1.00
zalon_scsi_callback: Zalon vers field is 0x1, IRQ 36
ncr53c8xx: 53c720 detected
ncr53c720-0: ID 7, Fast-10, Parity Checking, Differential
zalon_scsi_callback: Zalon vers field is 0x1, IRQ 37
ncr53c8xx: 53c720 detected
ncr53c720-1: ID 7, Fast-10, Parity Checking, Differential
scsi0 : ncr53c8xx-3.4.3b-20010512
scsi1 : ncr53c8xx-3.4.3b-20010512
Vendor: SEAGATE Model: ST34573WC Rev: HP11
Type: Direct-Access ANSI SCSI revision: 02
Vendor: SEAGATE Model: ST34573WC Rev: HP11
Type: Direct-Access ANSI SCSI revision: 02
Vendor: SEAGATE Model: ST34573WC Rev: HP11
Type: Direct-Access ANSI SCSI revision: 02
Vendor: SEAGATE Model: ST34573WC Rev: HP11
Type: Direct-Access ANSI SCSI revision: 02
Vendor: SEAGATE Model: ST34573WC Rev: HP11
Type: Direct-Access ANSI SCSI revision: 02
Vendor: SEAGATE Model: ST34573WC Rev: HP15
Type: Direct-Access ANSI SCSI revision: 02
Vendor: SEAGATE Model: ST34573WC Rev: HP11
Type: Direct-Access ANSI SCSI revision: 02
Vendor: SEAGATE Model: ST34573WC Rev: HP11
Type: Direct-Access ANSI SCSI revision: 02
Vendor: SEAGATE Model: ST34573WC Rev: HP15
Type: Direct-Access ANSI SCSI revision: 02
Vendor: SEAGATE Model: ST34573WC Rev: HP11
Type: Direct-Access ANSI SCSI revision: 02
Vendor: SEAGATE Model: ST34573WC Rev: HP11
Type: Direct-Access ANSI SCSI revision: 02
Vendor: SEAGATE Model: ST34573WC Rev: HP11
Type: Direct-Access ANSI SCSI revision: 02
53c700: Version 2.7 By James.Bottomley@HansenPartnership.com
scsi2: 53c710 rev 2=20
scsi2 : LASI SCSI 53c700
scsi2: (2:0) Synchronous at offset 8, period 100ns
Vendor: HP Model: DVD-ROM 6x/32x Rev: 1.08
Type: CD-ROM ANSI SCSI revision: 02
scsi2: (3:0) Synchronous at offset 8, period 100ns
Vendor: HP Model: C1537A Rev: HP02
Type: Sequential-Access ANSI SCSI revision: 02
st: Version 20020205, bufsize 32768, wrt 30720, max init. bufs 4, s/g segs =
16
Attached scsi tape st0 at scsi2, channel 0, id 3, lun 0
Attached scsi disk sda at scsi0, channel 0, id 1, lun 0
Attached scsi disk sdb at scsi0, channel 0, id 2, lun 0
Attached scsi disk sdc at scsi0, channel 0, id 3, lun 0
Attached scsi disk sdd at scsi0, channel 0, id 4, lun 0
Attached scsi disk sde at scsi0, channel 0, id 5, lun 0
Attached scsi disk sdf at scsi0, channel 0, id 6, lun 0
Attached scsi disk sdg at scsi1, channel 0, id 1, lun 0
Attached scsi disk sdh at scsi1, channel 0, id 2, lun 0
Attached scsi disk sdi at scsi1, channel 0, id 3, lun 0
Attached scsi disk sdj at scsi1, channel 0, id 4, lun 0
Attached scsi disk sdk at scsi1, channel 0, id 5, lun 0
Attached scsi disk sdl at scsi1, channel 0, id 6, lun 0
ncr53c720-0-<1,*>: FAST-10 WIDE SCSI 20.0 MB/s (100 ns, offset 8)
SCSI device sda: 8388314 512-byte hdwr sectors (4295 MB)
Partition check:
sda: sda1 sda2 sda3 sda4
ncr53c720-0-<2,*>: FAST-10 WIDE SCSI 20.0 MB/s (100 ns, offset 8)
SCSI device sdb: 8388314 512-byte hdwr sectors (4295 MB)
sdb: unknown partition table
ncr53c720-0-<3,*>: FAST-10 WIDE SCSI 20.0 MB/s (100 ns, offset 8)
SCSI device sdc: 8388314 512-byte hdwr sectors (4295 MB)
sdc: unknown partition table
ncr53c720-0-<4,*>: FAST-10 WIDE SCSI 20.0 MB/s (100 ns, offset 8)
SCSI device sdd: 8388314 512-byte hdwr sectors (4295 MB)
sdd: unknown partition table
ncr53c720-0-<5,*>: FAST-10 WIDE SCSI 20.0 MB/s (100 ns, offset 8)
SCSI device sde: 8388314 512-byte hdwr sectors (4295 MB)
sde: unknown partition table
ncr53c720-0-<6,*>: FAST-10 WIDE SCSI 20.0 MB/s (100 ns, offset 8)
SCSI device sdf: 8388314 512-byte hdwr sectors (4295 MB)
sdf: unknown partition table
ncr53c720-1-<1,*>: FAST-10 WIDE SCSI 20.0 MB/s (100 ns, offset 8)
SCSI device sdg: 8388314 512-byte hdwr sectors (4295 MB)
sdg: unknown partition table
ncr53c720-1-<2,*>: FAST-10 WIDE SCSI 20.0 MB/s (100 ns, offset 8)
SCSI device sdh: 8388314 512-byte hdwr sectors (4295 MB)
sdh: unknown partition table
ncr53c720-1-<3,*>: FAST-10 WIDE SCSI 20.0 MB/s (100 ns, offset 8)
SCSI device sdi: 8388314 512-byte hdwr sectors (4295 MB)
sdi: unknown partition table
ncr53c720-1-<4,*>: FAST-10 WIDE SCSI 20.0 MB/s (100 ns, offset 8)
SCSI device sdj: 8388314 512-byte hdwr sectors (4295 MB)
sdj: unknown partition table
ncr53c720-1-<5,*>: FAST-10 WIDE SCSI 20.0 MB/s (100 ns, offset 8)
SCSI device sdk: 8388314 512-byte hdwr sectors (4295 MB)
sdk: unknown partition table
ncr53c720-1-<6,*>: FAST-10 WIDE SCSI 20.0 MB/s (100 ns, offset 8)
SCSI device sdl: 8388314 512-byte hdwr sectors (4295 MB)
sdl: unknown partition table
Attached scsi CD-ROM sr0 at scsi2, channel 0, id 2, lun 0
sr0: scsi3-mmc drive: 0x/0x cd/rw xa/form2 cdda tray
Uniform CD-ROM driver Revision: 3.12
md: linear personality registered as nr 1
md: raid0 personality registered as nr 2
md: raid1 personality registered as nr 3
md: raid5 personality registered as nr 4
raid5: measuring checksumming speed
8regs : 504.400 MB/sec
8regs_prefetch: 443.600 MB/sec
32regs : 459.600 MB/sec
32regs_prefetch: 432.400 MB/sec
raid5: using function: 8regs (504.400 MB/sec)
md: md driver 0.90.0 MAX_MD_DEVS=3D256, MD_SB_DISKS=3D27
md: Autodetecting RAID arrays.
md: autorun ...
md: ... autorun DONE.
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP, IGMP
IP: routing cache hash table of 1024 buckets, 48Kbytes
TCP: Hash tables configured (established 32768 bind 65536)
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
VFS: Mounted root (ext2 filesystem) readonly.
Freeing unused kernel memory: 216k freed
INIT: version 2.84 booting
Activating swap.
Adding Swap: 977140k swap-space (priority -1)
Checking root file system...
fsck 1.28 (31-Aug-2002)
/dev/sda3: clean, 30096/396000 files, 160528/791616 blocks
System time was Thu Sep 12 05:23:22 UTC 2002.
Setting the System Clock using the Hardware Clock as reference...
System Clock set. System local time is now Thu Sep 12 05:23:20 UTC 2002.
Calculating module dependencies... done.
Loading modules:=20
Starting RAID devices: [events: 00000012]
[events: 00000012]
[events: 00000012]
[events: 00000012]
[events: 00000012]
[events: 00000012]
md: autorun ...
md: considering sdg ...
md: adding sdg ...
md: adding sdf ...
md: adding sde ...
md: adding sdd ...
md: adding sdc ...
md: adding sdb ...
md: created md0
md: bind<sdb,1>
md: bind<sdc,2>
md: bind<sdd,3>
md: bind<sde,4>
md: bind<sdf,5>
md: bind<sdg,6>
md: running: <sdg><sdf><sde><sdd><sdc><sdb>
md: sdg's event counter: 00000012
md: sdf's event counter: 00000012
md: sde's event counter: 00000012
md: sdd's event counter: 00000012
md: sdc's event counter: 00000012
md: sdb's event counter: 00000012
md0: max total readahead window set to 992k
md0: 4 data-disks, max readahead per data-disk: 248k
raid5: spare disk sdg
raid5: device sdf operational as raid disk 4
raid5: device sde operational as raid disk 3
raid5: device sdd operational as raid disk 2
raid5: device sdc operational as raid disk 1
raid5: device sdb operational as raid disk 0
raid5: allocated 5436kB for md0
raid5: raid level 5 set md0 active with 5 out of 5 devices, algorithm 2
RAID5 conf printout:
--- rd:5 wd:5 fd:0
disk 0, s:0, o:1, n:0 rd:0 us:1 dev:sdb
disk 1, s:0, o:1, n:1 rd:1 us:1 dev:sdc
disk 2, s:0, o:1, n:2 rd:2 us:1 dev:sdd
disk 3, s:0, o:1, n:3 rd:3 us:1 dev:sde
disk 4, s:0, o:1, n:4 rd:4 us:1 dev:sdf
RAID5 conf printout:
--- rd:5 wd:5 fd:0
disk 0, s:0, o:1, n:0 rd:0 us:1 dev:sdb
disk 1, s:0, o:1, n:1 rd:1 us:1 dev:sdc
disk 2, s:0, o:1, n:2 rd:2 us:1 dev:sdd
disk 3, s:0, o:1, n:3 rd:3 us:1 dev:sde
disk 4, s:0, o:1, n:4 rd:4 us:1 dev:sdf
md: updating md0 RAID superblock on device
md: sdg [events: 00000013]<6>(write) sdg's sb offset: 4194048
md: sdf [events: 00000013]<6>(write) sdf's sb offset: 4194048
md: sde [events: 00000013]<6>(write) sde's sb offset: 4194048
md: sdd [events: 00000013]<6>(write) sdd's sb offset: 4194048
md: sdc [events: 00000013]<6>(write) sdc's sb offset: 4194048
md: sdb [events: 00000013]<6>(write) sdb's sb offset: 4194048
md: ... autorun DONE.
/dev/md0 done.
Checking all file systems...
fsck 1.28 (31-Aug-2002)
/dev/sda4: clean, 25/8256 files, 18237/32769 blocks
Setting kernel variables.
Mounting local filesystems...
/dev/sda4 on /boot type ext2 (rw)
Running 0dns-down to make sure resolv.conf is ok...done.
Cleaning: /etc/network/ifstate.
Setting up IP spoofing protection: rp_filter.
Configuring network interfaces: eth0: link ok.
done.
Setting the System Clock using the Hardware Clock as reference...
System Clock set. Local time: Thu Sep 12 08:23:37 EEST 2002
Cleaning: /tmp /var/lock /var/run.
Initializing random number generator... done.
Recovering nvi editor sessions... done.
INIT: Entering runlevel: 2
Starting system log daemon: syslogd.
Starting kernel log daemon: klogd.
Starting OpenLDAP: slapd.
Starting internet superserver: inetd.
Starting mail transport agent: Postfix.
Starting OpenBSD Secure Shell server: sshd.
Starting teapop: teapop.
Starting deferred execution scheduler: atd.
Starting periodic command scheduler: cron.
Debian GNU/Linux testing/unstable elli ttyS0
elli login: root
Password:=20
Last login: Wed Sep 11 15:47:34 2002 on ttyS0
Linux elli 2.4.19-pa14 #1 SMP Wed Sep 11 12:54:30 EEST 2002 parisc unknown =
unknown GNU/Linux
Most of the programs included with the Debian GNU/Linux system are
freely redistributable; the exact distribution terms for each program
are described in the individual files in /usr/share/doc/*/copyright
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
elli:~# uname -=08 =08=08 =08=08 =08=08 =08=08 =08=08 =08=08 =08=07=07=07=
=07cat /proc/pcu=08 =08=08 =08=08 =08cpuinfo
processor : 0
cpu family : PA-RISC 2.0
cpu : PA8200 (PCX-U+)
cpu MHz : 240.000000
model : 9000/800/R390
model name : UL 2w U+/240 (350/550)
hversion : 0x00005ba0
sversion : 0x00000491
I-cache : 2048 KB
D-cache : 2048 KB (WB)
ITLB entries : 120
DTLB entries : 120 - shared with ITLB
bogomips : 478.41
software id : 2004293434
elli:~# sync && apt-get update
0% [Working] Hit http://security.debian.org stable/updates/main =
Packages
Hit http://security.debian.org stable/updates/main Release
Hit http://security.debian.org stable/updates/contrib Packages
Hit http://security.debian.org stable/updates/contrib Release
Hit http://security.debian.org stable/updates/non-free Packages
Hit http://security.debian.org stable/updates/non-free Release
19% [Connecting to ftp.fi.debian.org] [Waiting for file] =
Get:1 http://non-us.debian=
.org unstable/non-US/main Packages [34.2kB]
3% [Connecting to f=
tp.fi.debian.org (130.230.54.99)] [1 Packages 1106/34.2kB 3%] =
Get:2 htt=
p://ftp.fi.debian.org unstable/main Packages [1945kB]
=
0% [2 Packages 1093/1945kB 0%] [1 Packages 8346/34.2kB 24%] =
7% [2 Packages 115485/1945k=
B 5%] [Waiting for file] =
Get:3 http://non-us.debian.org unstable/non-US/main Release [89B]
Hit http://non-us.debian=
.org unstable/non-US/contrib Packages
Get:4 http://non-us.debi=
an.org unstable/non-US/contrib Release [92B]
Hit http://non-us.debian=
.org unstable/non-US/non-free Packages
Get:5 http://non-us.debi=
an.org unstable/non-US/non-free Release [93B]
Hit http://non-us.debian=
.org stable/non-US/main Sources
Hit http://non-us.debian=
.org stable/non-US/main Release
Hit http://non-us.debian=
.org stable/non-US/contrib Sources
7% [2 Packages 115485/1945kB 5%] [Waiting for file] =
Hit http://non-us.debian.org stable/non-US/contr=
ib Release
7% [2 Packages 115485/1945kB 5%] [Waiting for file] =
7% [1 Packages gzip 0] [2 Packages 115485/1945kB=
5%] [Waiting for file] =
Hit http://non-us.debian.org stable/non-US/non-free Sour=
ces
Hit =
http://non-us.debian.org stable/non-US/non-free Release
10% =
[1 Packages gzip 0] [2 Packages 174853/1945kB 8%] =
11% [2 Packages 190781/1945kB 9%] =
15% [2 Packages 280557/1945kB 14%]20% [2 Packages 376125/=
1945kB 19%]25% [2 Packages 465901/1945kB 23%]30% [2 Packages 564365/1945kB =
29%]34% [2 Packages 649797/1945kB 33%]37% [2 Packages 712061/1945kB 36%]41%=
[2 Packages 783013/1945kB 40%]45% [2 Packages 856861/1945kB 44%] =
48% [2 Packages 924917/1945kB 47%] =
153kB/s 6s51% [2 Packages 992973/1945kB 51%] =
153kB/s 6s55% [2 Packages 1072613/1945kB 55%] =
153kB/s 5s59% [2 Packages 1152253/1945kB 59%] =
153kB/s 5s62% [2 Packages 1198589/1945kB =
61%] 153kB/s 4s67% [2 Packages 1292709/19=
45kB 66%] 153kB/s 4s70% [2 Packages 13607=
65/1945kB 69%] 153kB/s 3s74% [2 Packages =
1431717/1945kB 73%] 153kB/s 3s78% [2 Pack=
ages 1509909/1945kB 77%] 153kB/s 2s81% [2=
Packages 1585205/1945kB 81%] 153kB/s 2s8=
5% [2 Packages 1661949/1945kB 85%] 153kB/=
s 1s90% [2 Packages 1750277/1945kB 89%] 1=
53kB/s 1s93% [2 Packages 1813989/1945kB 93%] =
153kB/s 0s97% [2 Packages 1897973/1945kB 97%] =
150kB/s 0s =
Get:6 http://ftp.fi.debian.org unstable/main Releas=
e [82B]
=
Hit http://ftp.fi.debian.org unstable/non-free Packages
=
Get:7 http://ftp.fi.debian.org unstable/non-free Release [86B]
=
Get:8 http://ftp.fi.debian.org unstable/contrib Packages [47.8kB]
97% [8 Packages 2308/47.8kB 4%] 150kB=
/s 0s97% [2 Packages gzip 0] [8 Packages 2308/47.8kB 4%] =
150kB/s 0s =
Get:9 http://ftp.fi.debian.org unstable/contrib Release [85B]
=
Hit http://ftp.fi.debian.org stable/main Sources
=
Hit http://ftp.fi.debian.org stable/main Release
=
Hit http://ftp.fi.debian.org stable/non-free Sources
=
Hit http://ftp.fi.debian.org stable/non-free Release
=
Hit http://ftp.fi.debian.org stable/contrib Sources
=
Hit http://ftp.fi.debian.org stable/contrib Release
99% [2 Packages gzip 212992] 150kB=
/s 0s99% [2 Packages gzip 2093056] =
150kB/s 0s99% [2 Packages gzip 4059136] =
150kB/s 0s99% [2 Packages gzip 5926912] =
150kB/s 0s99% [Working] =
150kB/s 0s99% [8 Packages gzip 0] =
150kB/s 0s100% [Working] =
150kB/s 0s =
Fetched 2027kB in 15s (131kB/s)
Reading Package Lists... 0%apt-get(285): unaligned access to 0x403cf08c at =
ip=3D0x4005e4f7
Reading Package=20
Lists... 0%
High Priority Machine Check (HPMC): Code=3D1 regs=3D102ea080 (Addr=3D000000=
00)
Interact with IPL (Y, N, or Cancel)?> n
Booting...=20
Boot IO Dependent Code (IODC) revision 152
HARD Booted.
palo ipl 1.0 root@palinux Mon Apr 1 10:02:53 MST 2002
Partition Start(MB) End(MB) Id Type
1 1 16 f0 Palo
2 49 1002 82 swap
3 1003 4094 83 ext2
4 17 48 83 ext2
PALO(F0) partition contains:
0/vmlinux32 3687647 bytes @ 0x48000
Information: No console specified on kernel command line. This is normal.
PALO will choose the console currently used by firmware (serial).
Command line for kernel: 'root=3D/dev/sda3 HOME=3D/ console=3DttyS0 TERM=3D=
vt102 palo_kernel=3D4/vmlinux'
Selected kernel: /vmlinux from partition 4
ELF32 executable
Entry 00100000 first 00100000 n 6
Segment 0 load 00100000 size 1893508 mediaptr 0x1000
Segment 1 load 002d0000 size 596888 mediaptr 0x1d0000
Segment 2 load 00364000 size 221560 mediaptr 0x262000
Segment 3 load 0039c000 size 8192 mediaptr 0x299000
Segment 4 load 003a0000 size 32768 mediaptr 0x29b000
Segment 5 load 003e38a4 size 82000 mediaptr 0x2a38a4
Branching to kernel entry point 0x00100000. If this is the last
message you see, you may need to switch your console. This is
a common symptom -- search the FAQ and mailing list at parisc-linux.org
Linux version 2.4.19-pa14 (root@elli) (gcc version 3.0.4) #1 SMP Wed Sep 11=
12:54:30 EEST 2002
FP[0] enabled: Rev 0 Model 14
The 32-bit Kernel has started...
Determining PDC firmware type: System Map.
model 00005ba0 00000491 00000000 00000002 7777173a 100000f0 00000008 000000=
b2 000000b2
vers 00000501
CPUID vers 14 rev 23 (0x000001d7)
capabilities 0x3
model 9000/800/R390
Total Memory: 1024 Mb
pagetable_init
On node 0 totalpages: 262144
zone(0): 262144 pages.
zone(1): 0 pages.
zone(2): 0 pages.
Kernel command line: root=3D/dev/sda3 HOME=3D/ console=3DttyS0 TERM=3Dvt102=
palo_kernel=3D4/vmlinux
Console: colour dummy device 160x64
Calibrating delay loop... 478.41 BogoMIPS
Memory: 1033080k available
Dentry cache hash table entries: 131072 (order: 8, 1048576 bytes)
Inode cache hash table entries: 65536 (order: 7, 524288 bytes)
Mount-cache hash table entries: 16384 (order: 5, 131072 bytes)
Buffer-cache hash table entries: 65536 (order: 6, 262144 bytes)
Page-cache hash table entries: 262144 (order: 8, 1048576 bytes)
Searching for devices...
Found devices:
1. U2-IOA BC Runway Port (12) at 0xfff88000 [8], versions 0x580, 0xf, 0xb
2. Bluefish Add-on FW-SCSI (4) at 0xf1004000 [8/4], versions 0x13, 0x1, 0x89
3. HP HSC-PCI Cards (4) at 0xf1008000 [8/8], versions 0x4, 0x0, 0x9d
4. UL 550 Lasi Core BA (11) at 0xffd00000 [8/16], versions 0x2f, 0x0, 0x81,=
additional addresses: 0xffd0c000 0xffc00000=20
5. UL 550 Core Centronics (10) at 0xffd02000 [8/16/0], versions 0x2f, 0x0, =
0x74, additional addresses: 0xffd01000 0xffd03000=20
6. UL 550 Lasi Core RS-232 (10) at 0xffd05000 [8/16/4], versions 0x2f, 0x0,=
0x8c
7. UL 550 Core SCSI (10) at 0xffd06000 [8/16/5], versions 0x2f, 0x0, 0x82
8. UL 350 Core LAN (802.3) (10) at 0xffd07000 [8/16/6], versions 0x2f, 0x0,=
0x8a
9. UL 550 Core PS/2 Port (10) at 0xffd08000 [8/16/7], versions 0x2f, 0x0, 0=
x84
10. UL 550 Core PS/2 Port (10) at 0xffd08100 [8/16/8], versions 0x2f, 0x0, =
0x84
11. UL 550 Core Wax BA (11) at 0xffe00000 [8/20], versions 0x31, 0x0, 0x8e
12. UL 550 Wax Core RS-232 (10) at 0xffe02000 [8/20/2], versions 0x31, 0x0,=
0x8c
13. UL 550 Wax EISA BA (11) at 0xfc000000 [8/20/5], versions 0x31, 0x0, 0x9=
0, additional addresses: 0xffc88000=20
14. U2-IOA BC GSC+ Port (7) at 0xf103f000 [8/63], versions 0x501, 0x1, 0xc
15. U2-IOA BC Runway Port (12) at 0xfff8a000 [10], versions 0x580, 0xf, 0xb
16. Bluefish Add-on FW-SCSI (4) at 0xf180c000 [10/12], versions 0x13, 0x1, =
0x89
17. U2-IOA BC GSC+ Port (7) at 0xf183f000 [10/63], versions 0x501, 0x1, 0xc
18. UL 2w U+/240 (350/550) (0) at 0xfffa0000 [32], versions 0x5ba, 0x0, 0x4
19. Memory (1) at 0xfffb1000 [49], versions 0x7e, 0x0, 0x9
CPU(s): 1 x PA8200 (PCX-U+) at 240.000000 MHz
Found U2 at 0xfff88000
Found U2 at 0xfff8a000
Lasi version 0 at 0xffd00000 found.
LED display at ffd0c000 registered
Wax at 0xffe00000 found.
Wax EISA Adapter found at 0xfc000000
EISA EEPROM at 0xffc88000
Enumerating EISA bus
EISA slot 1 a configured board was not detected ( expected ___FFFF)
Dino version 3.x (card mode) found at 0xf1008000
Dino: Failed to allocate memory region
POSIX conformance testing by UNIFIX
SMP: Bootstrap processor only.
SMP: Total 1 of 1 processors activated (478.41 BogoMIPS noticed).
Waiting on wait_init_idle (map =3D 0x0)
All processors have done init_idle
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Initializing RT netlink socket
Soft power switch enabled, polling @ 0xf0140000.
Starting kswapd
VFS: Diskquotas version dquot_6.4.0 initialized
Journalled Block Device driver loaded
parport_init_chip: initialize bidirectional-mode.
parport0: PC-style at 0xffd02800, irq 88 [PCSPP,TRISTATE]
pty: 256 Unix98 ptys configured
Serial driver version 5.05c (2001-07-08) with MANY_PORTS SHARE_IRQ SERIAL_P=
CI enabled
ttyS00 at iomem 0xffd05800 (irq =3D 90) is a 16550A
ttyS01 at iomem 0xffe02800 (irq =3D 121) is a 16550A
PS/2 keyboard port at 0xffd08000 (irq 69) found, no device attached.
lp0: using parport0 (interrupt-driven).
Generic RTC Driver v1.02 05/27/1999 Sam Creasey (sammy@oh.verio.com)
RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
Found i82596 at 0xffd07000, IRQ 87
eth0: 82596 at 0xffd07000, 08 00 09 A3 38 14 IRQ 87.
82596.c $Revision: 1.29 $
SCSI subsystem driver Revision: 1.00
zalon_scsi_callback: Zalon vers field is 0x1, IRQ 36
ncr53c8xx: 53c720 detected
ncr53c720-0: ID 7, Fast-10, Parity Checking, Differential
zalon_scsi_callback: Zalon vers field is 0x1, IRQ 37
ncr53c8xx: 53c720 detected
ncr53c720-1: ID 7, Fast-10, Parity Checking, Differential
scsi0 : ncr53c8xx-3.4.3b-20010512
scsi1 : ncr53c8xx-3.4.3b-20010512
Vendor: SEAGATE Model: ST34573WC Rev: HP11
Type: Direct-Access ANSI SCSI revision: 02
Vendor: SEAGATE Model: ST34573WC Rev: HP11
Type: Direct-Access ANSI SCSI revision: 02
Vendor: SEAGATE Model: ST34573WC Rev: HP11
Type: Direct-Access ANSI SCSI revision: 02
Vendor: SEAGATE Model: ST34573WC Rev: HP11
Type: Direct-Access ANSI SCSI revision: 02
Vendor: SEAGATE Model: ST34573WC Rev: HP11
Type: Direct-Access ANSI SCSI revision: 02
Vendor: SEAGATE Model: ST34573WC Rev: HP15
Type: Direct-Access ANSI SCSI revision: 02
Vendor: SEAGATE Model: ST34573WC Rev: HP11
Type: Direct-Access ANSI SCSI revision: 02
Vendor: SEAGATE Model: ST34573WC Rev: HP11
Type: Direct-Access ANSI SCSI revision: 02
Vendor: SEAGATE Model: ST34573WC Rev: HP15
Type: Direct-Access ANSI SCSI revision: 02
Vendor: SEAGATE Model: ST34573WC Rev: HP11
Type: Direct-Access ANSI SCSI revision: 02
Vendor: SEAGATE Model: ST34573WC Rev: HP11
Type: Direct-Access ANSI SCSI revision: 02
Vendor: SEAGATE Model: ST34573WC Rev: HP11
Type: Direct-Access ANSI SCSI revision: 02
53c700: Version 2.7 By James.Bottomley@HansenPartnership.com
scsi2: 53c710 rev 2=20
scsi2 : LASI SCSI 53c700
scsi2: (2:0) Synchronous at offset 8, period 100ns
Vendor: HP Model: DVD-ROM 6x/32x Rev: 1.08
Type: CD-ROM ANSI SCSI revision: 02
scsi2: (3:0) Synchronous at offset 8, period 100ns
Vendor: HP Model: C1537A Rev: HP02
Type: Sequential-Access ANSI SCSI revision: 02
st: Version 20020205, bufsize 32768, wrt 30720, max init. bufs 4, s/g segs =
16
Attached scsi tape st0 at scsi2, channel 0, id 3, lun 0
Attached scsi disk sda at scsi0, channel 0, id 1, lun 0
Attached scsi disk sdb at scsi0, channel 0, id 2, lun 0
Attached scsi disk sdc at scsi0, channel 0, id 3, lun 0
Attached scsi disk sdd at scsi0, channel 0, id 4, lun 0
Attached scsi disk sde at scsi0, channel 0, id 5, lun 0
Attached scsi disk sdf at scsi0, channel 0, id 6, lun 0
Attached scsi disk sdg at scsi1, channel 0, id 1, lun 0
Attached scsi disk sdh at scsi1, channel 0, id 2, lun 0
Attached scsi disk sdi at scsi1, channel 0, id 3, lun 0
Attached scsi disk sdj at scsi1, channel 0, id 4, lun 0
Attached scsi disk sdk at scsi1, channel 0, id 5, lun 0
Attached scsi disk sdl at scsi1, channel 0, id 6, lun 0
ncr53c720-0-<1,*>: FAST-10 WIDE SCSI 20.0 MB/s (100 ns, offset 8)
SCSI device sda: 8388314 512-byte hdwr sectors (4295 MB)
Partition check:
sda: sda1 sda2 sda3 sda4
ncr53c720-0-<2,*>: FAST-10 WIDE SCSI 20.0 MB/s (100 ns, offset 8)
SCSI device sdb: 8388314 512-byte hdwr sectors (4295 MB)
sdb: unknown partition table
ncr53c720-0-<3,*>: FAST-10 WIDE SCSI 20.0 MB/s (100 ns, offset 8)
SCSI device sdc: 8388314 512-byte hdwr sectors (4295 MB)
sdc: unknown partition table
ncr53c720-0-<4,*>: FAST-10 WIDE SCSI 20.0 MB/s (100 ns, offset 8)
SCSI device sdd: 8388314 512-byte hdwr sectors (4295 MB)
sdd: unknown partition table
ncr53c720-0-<5,*>: FAST-10 WIDE SCSI 20.0 MB/s (100 ns, offset 8)
SCSI device sde: 8388314 512-byte hdwr sectors (4295 MB)
sde: unknown partition table
ncr53c720-0-<6,*>: FAST-10 WIDE SCSI 20.0 MB/s (100 ns, offset 8)
SCSI device sdf: 8388314 512-byte hdwr sectors (4295 MB)
sdf: unknown partition table
ncr53c720-1-<1,*>: FAST-10 WIDE SCSI 20.0 MB/s (100 ns, offset 8)
SCSI device sdg: 8388314 512-byte hdwr sectors (4295 MB)
sdg: unknown partition table
ncr53c720-1-<2,*>: FAST-10 WIDE SCSI 20.0 MB/s (100 ns, offset 8)
SCSI device sdh: 8388314 512-byte hdwr sectors (4295 MB)
sdh: unknown partition table
ncr53c720-1-<3,*>: FAST-10 WIDE SCSI 20.0 MB/s (100 ns, offset 8)
SCSI device sdi: 8388314 512-byte hdwr sectors (4295 MB)
sdi: unknown partition table
ncr53c720-1-<4,*>: FAST-10 WIDE SCSI 20.0 MB/s (100 ns, offset 8)
SCSI device sdj: 8388314 512-byte hdwr sectors (4295 MB)
sdj: unknown partition table
ncr53c720-1-<5,*>: FAST-10 WIDE SCSI 20.0 MB/s (100 ns, offset 8)
SCSI device sdk: 8388314 512-byte hdwr sectors (4295 MB)
sdk: unknown partition table
ncr53c720-1-<6,*>: FAST-10 WIDE SCSI 20.0 MB/s (100 ns, offset 8)
SCSI device sdl: 8388314 512-byte hdwr sectors (4295 MB)
sdl: unknown partition table
Attached scsi CD-ROM sr0 at scsi2, channel 0, id 2, lun 0
sr0: scsi3-mmc drive: 0x/0x cd/rw xa/form2 cdda tray
Uniform CD-ROM driver Revision: 3.12
md: linear personality registered as nr 1
md: raid0 personality registered as nr 2
md: raid1 personality registered as nr 3
md: raid5 personality registered as nr 4
raid5: measuring checksumming speed
8regs : 504.000 MB/sec
8regs_prefetch: 443.600 MB/sec
32regs : 459.200 MB/sec
32regs_prefetch: 432.400 MB/sec
raid5: using function: 8regs (504.000 MB/sec)
md: md driver 0.90.0 MAX_MD_DEVS=3D256, MD_SB_DISKS=3D27
md: Autodetecting RAID arrays.
md: autorun ...
md: ... autorun DONE.
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP, IGMP
IP: routing cache hash table of 1024 buckets, 48Kbytes
TCP: Hash tables configured (established 32768 bind 65536)
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
VFS: Mounted root (ext2 filesystem) readonly.
Freeing unused kernel memory: 216k freed
INIT: version 2.84 booting
Activating swap.
Adding Swap: 977140k swap-space (priority -1)
Checking root file system...
fsck 1.28 (31-Aug-2002)
/dev/sda3 was not cleanly unmounted, check forced.
/dev/sda3: |=3D=3D | =
2.8% /dev/sda3: |=3D=3D=3D =
/ 5.6% /dev/sda3: |=3D=3D=3D=3D=3D =
- 8.4% /dev/sda3: |=3D=3D=3D=3D=3D=3D =
\ 11.2% /dev/sda3: |=3D=3D=3D=3D=3D=3D=
=3D=3D | 14.0% /dev/sda3: =
|=3D=3D=3D=3D=3D=3D=3D=3D=3D =
/ 16.8% /dev/sda3: |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =
- 19.6% /dev/sda3: |=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D \ 22.4% /dev/sda3:=
|=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =
| 25.2% /dev/sda3: =
Inode 142595, i_blocks is 80, should be=
56. FIXED.
/dev/sda3: Inode 142873, i_blocks is 320, should be 296. FIXED.
/dev/sda3: Inode 142775, i_blocks is 336, should be 312. FIXED.
/dev/sda3: |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =
/ 28.0% /dev/sda3: =
Inode 158469, i_blocks is=
64, should be 8. FIXED.
/dev/sda3: |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =
- 30.8% /dev/sda3: |=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D \ 33.=
6% /dev/sda3: |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D | 36.4% /dev/sda3: |=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =
/ 39.2% /dev/sda3: |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D - 42.0% =
/dev/sda3: |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D \ 44.8% /dev/sda3: |=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =
| 47.6% /dev/sda3: |=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =
/ 50.4% /dev/sda3: |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D -=
53.2% /dev/sda3: |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D \ 56.0% /=
dev/sda3: |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D | 58.8% /dev/s=
da3: |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D / 61.6% /dev/sda3:=
=
Inode 348490, i_blocks is 88, should be 48. FIXED.
/dev/sda3: |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D - 64.4% =
/dev/sda3: |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D \ 67.2=
% /dev/sda3: |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =
| 70.0% /dev/sda3: |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =
/ 70.2% /dev/sda3: |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =
- 70.4% /dev/sda3: |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D \ 70.7% /dev/sda3: |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D | 70.9% /dev/sda3: |=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D / 71.2% /dev/sda3: |=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D - 71.5% /dev/sda3: |=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D \ 71.8% /dev/sd=
a3: |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D | 72.1% =
/dev/sda3: |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =
/ 72.5% /dev/sda3: |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
- 72.8% /dev/sda3: |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D \ 73.1% /dev/sda3: |=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D | 73.4% /dev/sda3: |=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D / 73.7% /dev/sda3: |=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D - 74.1% =
/dev/sda3: |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =
\ 74.5% /dev/sda3: |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
| 74.8% /dev/sda3: |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D / 75.0% /dev/sda3: |=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D - 75.2% /dev/sda3: |=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D \ 75.5% /dev/sda3: |=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D | 75.7% /de=
v/sda3: |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =
/ 75.9% /dev/sda3: |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D - 76.2% /dev/sda3: |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D \ 76.6% /dev/sda3: |=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D | 77.0% /dev/sda3: |=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D / 77.2% /dev=
/sda3: |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =
- 77.5% /dev/sda3: |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D \ 77.9% /dev/sda3: |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D | 78.1% /dev/sda3: |=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D / 78.4% /dev/sda3: =
|=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D - 7=
8.7% /dev/sda3: |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D \ 79.0% /dev/sda3: |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D | 79.2% /dev/sda3: |=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D / 79.7% /dev/sda3: |=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D - 80=
.0% /dev/sda3: |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D \ 80.2% /dev/sda3: |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D | 80.6% /dev/sda3: |=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D / 80.8% /dev/sda3: |=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D - 81.0%=
/dev/sda3: |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D \ 81.3% /dev/sda3: |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D | 81.6% /dev/sda3: |=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D / 81.8% /dev/sda3:=
|=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =
- 82.1% /dev/sda3: |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D \ 82.3% /dev/sda3: |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D | 82.5% /dev/sda3: |=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D / 82.8% /=
dev/sda3: |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
- 83.0% /dev/sda3: |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D \ 83.3% /dev/sda3: |=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D | 83.4% /dev/sda=
3: |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =
/ 83.6% /dev/sda3: |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D - 83.9% /dev/sda3: |=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D \ 84.2% /dev/sda3: =
|=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =
| 84.4% /dev/sda3: |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D / 84.6% /dev/sda3: |=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D - 84.9% /dev/sda3: |=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =
\ 85.2% /dev/sda3: |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D | 85.4% /dev/sda3: |=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D / 85.9% /dev/sda3: |=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D -=
86.1% /dev/sda3: |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D \ 86.3% /dev/sda3: |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D | 86.6% /dev/sda3: |=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D / =
86.8% /dev/sda3: |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D - 87.0% /dev/sda3: |=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D \ 87.2% /dev/sda3: |=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =
| 87.6% /dev/sda3: |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D / 87.8% /dev/sda3: |=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D - 88.0% /dev/sd=
a3: |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D \ 88.2% /dev/sda3: |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D | 89.3% /dev/sda3: |=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D / 90.0=
% /dev/sda3: |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D - 92.0% /dev/sda3: |=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D \ 92.7% /dev=
/sda3: |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D | 93.9% /dev/sda3: |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D / 95.0% /dev/sda=
3: |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D - 95.1% /dev/sda3: |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D \ 96.0% /dev/sda3=
: |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D | 96.8% /dev/sda3: |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D / 98.1% /dev/sda3:=
|=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D- 99.6% /dev/sda3: |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D| 100.0% =
=
/dev/sda3: 30103/396000 files (0.8% non-contiguous), 160550/791616 blocks
System time was Thu Sep 12 08:42:44 UTC 2002.
Setting the System Clock using the Hardware Clock as reference...
System Clock set. System local time is now Thu Sep 12 08:42:53 UTC 2002.
Calculating module dependencies... done.
Loading modules:=20
Starting RAID devices: [events: 00000013]
[events: 00000013]
[events: 00000013]
[events: 00000013]
[events: 00000013]
[events: 00000013]
md: autorun ...
md: considering sdg ...
md: adding sdg ...
md: adding sdf ...
md: adding sde ...
md: adding sdd ...
md: adding sdc ...
md: adding sdb ...
md: created md0
md: bind<sdb,1>
md: bind<sdc,2>
md: bind<sdd,3>
md: bind<sde,4>
md: bind<sdf,5>
md: bind<sdg,6>
md: running: <sdg><sdf><sde><sdd><sdc><sdb>
md: sdg's event counter: 00000013
md: sdf's event counter: 00000013
md: sde's event counter: 00000013
md: sdd's event counter: 00000013
md: sdc's event counter: 00000013
md: sdb's event counter: 00000013
md: md0: raid array is not clean -- starting background reconstruction
md0: max total readahead window set to 992k
md0: 4 data-disks, max readahead per data-disk: 248k
raid5: spare disk sdg
raid5: device sdf operational as raid disk 4
raid5: device sde operational as raid disk 3
raid5: device sdd operational as raid disk 2
raid5: device sdc operational as raid disk 1
raid5: device sdb operational as raid disk 0
raid5: allocated 5436kB for md0
raid5: raid level 5 set md0 active with 5 out of 5 devices, algorithm 2
raid5: raid set md0 not clean; reconstructing parity
RAID5 conf printout:
--- rd:5 wd:5 fd:0
disk 0, s:0, o:1, n:0 rd:0 us:1 dev:sdb
disk 1, s:0, o:1, n:1 rd:1 us:1 dev:sdc
disk 2, s:0, o:1, n:2 rd:2 us:1 dev:sdd
disk 3, s:0, o:1, n:3 rd:3 us:1 dev:sde
disk 4, s:0, o:1, n:4 rd:4 us:1 dev:sdf
RAID5 conf printout:
--- rd:5 wd:5 fd:0
disk 0, s:0, o:1, n:0 rd:0 us:1 dev:sdb
disk 1, s:0, o:1, n:1 rd:1 us:1 dev:sdc
disk 2, s:0, o:1, n:2 rd:2 us:1 dev:sdd
disk 3, s:0, o:1, n:3 rd:3 us:1 dev:sde
disk 4, s:0, o:1, n:4 rd:4 us:1 dev:sdf
md: updating md0 RAID superblock on device
md: sdg [events: 00000014]<6>(write) sdg's sb offset: 4194048
md: syncing RAID array md0
md: minimum _guaranteed_ reconstruction speed: 100 KB/sec/disc.
md: using maximum available idle IO bandwith (but not more than 100000 KB/s=
ec) for reconstruction.
md: using 124k window, over a total of 4194048 blocks.
md: sdf [events: 00000014]<6>(write) sdf's sb offset: 4194048
md: sde [events: 00000014]<6>(write) sde's sb offset: 4194048
md: sdd [events: 00000014]<6>(write) sdd's sb offset: 4194048
md: sdc [events: 00000014]<6>(write) sdc's sb offset: 4194048
md: sdb [events: 00000014]<6>(write) sdb's sb offset: 4194048
md: ... autorun DONE.
/dev/md0 done.
Checking all file systems...
fsck 1.28 (31-Aug-2002)
/dev/sda4 was not cleanly unmounted, check forced.
/dev/sda4: |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =
| 17.5% /dev/sda4: |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D / 35.0% /dev/sda=
4: |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D - 52.5% /dev/sda4: |=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D \ 70.0% /dev/sda4: |=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
| 90.0% /dev/sda4: |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D / 92.0% /dev/sda4: |=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =
- 95.0% /dev/sda4: |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D \ 95.6% /dev/sda4: |=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D| 100.0% =
/dev/sda4: 25/8256 files (8.0% non-contiguous), 18237/327=
69 blocks
Setting kernel variables.
Mounting local filesystems...
/dev/sda4 on /boot type ext2 (rw)
Running 0dns-down to make sure resolv.conf is ok...done.
Cleaning: /etc/network/ifstate.
Setting up IP spoofing protection: rp_filter.
Configuring network interfaces: eth0: link ok.
done.
Setting the System Clock using the Hardware Clock as reference...
System Clock set. Local time: Thu Sep 12 11:43:41 EEST 2002
Cleaning: /tmp /var/lock /var/run.
Initializing random number generator... done.
Recovering nvi editor sessions... done.
INIT: Entering runlevel: 2
Starting system log daemon: syslogd.
Starting kernel log daemon: klogd.
Starting OpenLDAP: slapd.
Starting internet superserver: inetd.
Starting mail transport agent: Postfix
=2E
Starting OpenBSD Secure Shell server: sshd.
Starting teapop: teapop.
Starting deferred execution scheduler: atd.
Starting periodic command scheduler: cron.
Debian GNU/Linux testing/unstable elli ttyS0
elli login: root
Password:=20
Last login: Thu Sep 12 08:24:40 2002 on ttyS0
Linux elli 2.4.19-pa14 #1 SMP Wed Sep 11 12:54:30 EEST 2002 parisc unknown =
unknown GNU/Linux
Most of the programs included with the Debian GNU/Linux system are
freely redistributable; the exact distribution terms for each program
are described in the individual files in /usr/share/doc/*/copyright
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
elli:~# ap-=08 =08t-get update
0% [Working] 0% [Connecting to ftp.fi.debian.org (130.230.54.99)=
] [Connecting to non-us.debia =
Hit http://security.debian.org stable/upd=
ates/main Packages
=
Hit http://security.debian.org stable/updates/main Release
=
Hit http://security.debian.org stable/updates/contrib Packages
=
Hit http://security.debian.org stable/updates/contrib Release
=
Hit http://security.debian.org stable/updates/non-free Packages
=
Hit http://security.debian.org stable/updates/non-free Release
=
19% [Waiting for file] [Connecting to non-us.debian.org] =
Get:1 http://ftp.fi.debian.org un=
stable/main Packages [1945kB]
0% [1 Packages 2541=
/1945kB 0%] [Connecting to non-us.debian.org] =
1% [1 Packages 28605/1945kB 1%] [Waiting =
for file] Get:2 http://non=
-us.debian.org unstable/non-US/main Packages [34.2kB]
1% [1 Packages 28605/1945=
kB 1%] [2 Packages 1106/34.2kB 3%] =
Get:3 http://non-us.debian.org unstable/non-US/main Relea=
se [89B]
Hit http://non-u=
s.debian.org unstable/non-US/contrib Packages
Get:4 http://non=
-us.debian.org unstable/non-US/contrib Release [92B]
Hit http://non-u=
s.debian.org unstable/non-US/non-free Packages
Get:5 http://non=
-us.debian.org unstable/non-US/non-free Release [93B]
Hit http://non-u=
s.debian.org stable/non-US/main Sources
Hit http://non-u=
s.debian.org stable/non-US/main Release
10% [1 Packages =
177749/1945kB 9%] Hit http://non-us.debian.=
org stable/non-US/contrib Sources
Hit http://non-us.debian.org stable/non-US=
/contrib Release
10% [1 Packages 177749/1945kB 9%] 11% [2 Pa=
ckages gzip 0] [1 Packages 192229/1945kB 9%] [Waiting for file] =
Hit http://non-=
us.debian.org stable/non-US/non-free Sources
Hit=
http://non-us.debian.org stable/non-US/non-free Release
12%=
[2 Packages gzip 0] [1 Packages 205261/1945kB 10%]14% [2 Packages gzip 0] =
[1 Packages 258837/1945kB 13%] =
16% [1 Packages 296485/1945kB 15%]18% [1 Packages 337029/1945kB 17=
%]20% [1 Packages 376125/1945kB 19%]21% [1 Packages 393501/1945kB 20%]23% [=
1 Packages 434045/1945kB 22%] 26% [1 Packa=
ges 497757/1945kB 25%] 82.9kB/s 17s30% [1 =
Packages 561469/1945kB 28%] 82.9kB/s 16s32=
% [1 Packages 612149/1945kB 31%] 82.9kB/s =
16s34% [1 Packages 655589/1945kB 33%] 82.9=
kB/s 15s36% [1 Packages 694685/1945kB 35%] =
82.9kB/s 15s39% [1 Packages 754053/1945kB 38%] =
82.9kB/s 14s42% [1 Packages 807629/1945kB 41%] =
82.9kB/s 13s45% [1 Packages 872789/1945kB 44%] =
82.9kB/s 12s49% [1 Packages 945189/1945kB 48%] =
82.9kB/s 12s52% [1 Packages 1008901/1945kB 51%] =
82.9kB/s 11s55% [1 Packages 1056685/1945kB 54%] =
82.9kB/s 10s56% [1 Packages 1078405/1945kB 5=
5%] 82.9kB/s 10s58% [1 Packages 1123293/194=
5kB 57%] 104kB/s 7s60% [1 Packages 116383=
7/1945kB 59%] 104kB/s 7s62% [1 Packages 1=
200037/1945kB 61%] 104kB/s 7s64% [1 Packa=
ges 1236237/1945kB 63%] 104kB/s 6s67% [1 =
Packages 1295605/1945kB 66%] 104kB/s 6s69=
% [1 Packages 1346285/1945kB 69%] 104kB/s=
5s72% [1 Packages 1394069/1945kB 71%] 10=
4kB/s 5s75% [1 Packages 1450541/1945kB 74%] =
104kB/s 4s77% [1 Packages 1498325/1945kB 77%] =
104kB/s 4s80% [1 Packages 1553349/1945kB 79%] =
104kB/s 3s83% [1 Packages 1612717/1945kB 82%] =
104kB/s 3s86% [1 Packages 1670637/1945kB 85%] =
104kB/s 2s88% [1 Packages 1719869/1945kB 88%] =
104kB/s 2s91% [1 Packages 1769101/1945kB 90%] =
99.4kB/s 1s95% [1 Packages 1853085/1945kB 9=
5%] 99.4kB/s 0s98% [1 Packages 1921141/194=
5kB 98%] 99.4kB/s 0s =
Get:6 http://ftp.=
fi.debian.org unstable/main Release [82B]
=
Hit http://ftp.fi.debian.org unstable/non-free Packages
99% [Waiting for file] 99.4kB=
/s 0s =
Get:7 http://ftp.fi.debian.org unstable/non-free Release [86B]
=
Get:8 http://ftp.fi.debian.org unstable/contrib Packages [47.8kB]
97% [1 Packages gzip 0] [8 Packages 5204/47.8kB 10%] 99.4kB=
/s 0s =
Get:9 http://ftp.fi.debian.org unstable/contrib Release [85B]
=
Hit http://ftp.fi.debian.org stable/main Sources
=
Hit http://ftp.fi.debian.org stable/main Release
=
Hit http://ftp.fi.debian.org stable/non-free Sources
=
Hit http://ftp.fi.debian.org stable/non-free Release
=
Hit http://ftp.fi.debian.org stable/contrib Sources
=
Hit http://ftp.fi.debian.org stable/contrib Release
99% [1 Packages gzip 323584] 99.4kB=
/s 0s99% [1 Packages gzip 1437696] 9=
9.4kB/s 0s99% [1 Packages gzip 2555904] =
99.4kB/s 0s99% [1 Packages gzip 3665920] =
99.4kB/s 0s99% [1 Packages gzip 4780032] =
99.4kB/s 0s99% [1 Packages gzip 5861376] =
99.4kB/s 0s99% [1 Packages gzip 6918144] =
99.4kB/s 0s99% [Working] =
99.4kB/s 0s99% [8 Packages gzip 0] =
99.4kB/s 0s100% [Working] =
99.4kB/s 0s =
Fetched 2027kB in 24=
s (83.5kB/s)
Reading Package Lists... 0%apt-get(289): unaligned access to 0x403cf08c at =
ip=3D0x4005e4f7
Reading Package=20
apt-get(289): unaligned access to 0x403cf08c at ip=3D0x4005e4f7
High Priority Machine Check (HPMC): Code=3D1 regs=3D102ea080 (Addr=3D000000=
00)
=FF
Firmware Version 38.39
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 240 MHz Active Functional 2 MB
1 240 MHz Stopped:Deconfigured Unknown 2 MB
Central Bus Speed (in MHz) : 120=20
Model: R390/2
Available memory (bytes) : 1073733632=20
Good memory required (bytes): 86876160=20
Primary boot path: 8/4.1 (dec) =20
Alternate boot path: 8/4.6 (dec) =20
Console path: 8/16/4.0 (dec) =20
Keyboard path: 8/16/7.0 (dec) =20
CPU 0
WARNING: Memory has been initialized, but not tested as a result of
FASTBOOT being enabled. To test memory, use the FASTBOOT
command in the CONFIGURATION menu and reboot the system.
Processor is starting autoboot process.
To discontinue, press any key within 10 seconds.
=07Boot terminated.
------- Main Menu ---------------------------------------------------------=
----
Command Description
------- -----------
BOot [PRI|ALT|<path>] Boot from specified path
PAth [PRI|ALT|CON|KEY] [<path>] Display or modify a path
SEArch [DIsplay|IPL] [<path>] Search for boot devices
COnfiguration [<command>] Access Configuration menu/commands
INformation [<command>] Access Information menu/commands
SERvice [<command>] Access Service menu/commands
DIsplay Redisplay the current menu
HElp [<menu>|<command>] Display help for menu or command
RESET Restart the system
-------
Main Menu: Enter command > ser pim
PROCESSOR PIM INFORMATION
----------------- Processor 0 HPMC Information ------------------
Timestamp =3D Thu Sep 12 08:48:47 GMT 2002 (20:02:09:12:08:48:47)
HPMC Chassis Codes =3D 0xcbf0 0x5002 0x7d03 0x5408 0x5508 0xcbfb =20
=20
General Registers 0 - 31
00-03 0000000000000000 0000000000044a20 0000000040098df3 00000000403cf0=
8c
04-07 0000000000000038 0000000040111868 00000000faf00b88 00000000faf00d=
d8
08-11 0000000000050b00 00000000faf00de0 00000000faf00dd8 00000000faf00d=
e8
12-15 0000000000050b00 00000000faf00ab0 00000000faf00948 00000000faf00a=
8c
16-19 00000000faf008c0 000000000000000f 000000000009e800 00000000401118=
68
20-23 00000000403cf098 0000000000000007 00000000403cf08c 00000000403cf0=
44
24-27 00000000faf00dd8 0000000000000038 0000000000051990 00000000000402=
20
28-31 0000000000051990 0000000000000007 00000000faf01400 00000000000282=
a3
<Press any key to continue (q to quit)>=20
Control Registers 0 - 31
00-03 0000000000000000 0000000000000000 0000000000000000 00000000000000=
00
04-07 0000000000000000 0000000000000000 0000000000000000 00000000000000=
00
08-11 000000000000022a 0000000000000000 00000000000000c0 00000000000000=
08
12-15 0000000000000000 0000000000000000 0000000000108000 00000000fd0000=
00
16-19 00000021d83d8324 0000000000000115 000000004005e4fb 0000000043ffff=
80
20-23 00000000102400db 400000004912452c 0000000000000000 00000000000000=
00
24-27 0000000000305000 0000000036d23000 00000000aaaaaaaa 00000000000003=
d0
28-31 00000000aaaaaaaa 0000000011111111 0000000046d24000 00000000103a00=
00
Space Registers 0 - 7
00-03 00000000 00000115 00000000 00000115
04-07 00000115 00000115 00000115 00000115
<Press any key to continue (q to quit)>=20
IIA Space =3D 0x0000000000000115
IIA Offset =3D 0x000000004005e4ff
Check Type =3D 0x20000000
CPU State =3D 0x9e000004
Cache Check =3D 0x00000000
TLB Check =3D 0x00000000
Bus Check =3D 0x00105004
Assists Check =3D 0x00000000
Assist State =3D 0x00000000
Path Info =3D 0x00000000
System Responder Address =3D 0x0000000000000000
System Requestor Address =3D 0xfffffffffffa0000
Check Summary =3D 0x80000000102846c0
Available Memory =3D 0x0000000040000000
CPU Diagnose Register 2 =3D 0x0501000004000004
CPU Status Register 0 =3D 0x1420820000000000
CPU Status Register 1 =3D 0x8000000000000000
SADD LOG =3D 0x3e11b4fff1b4a0b9
Read Short LOG =3D 0xc10200ffffd05802
<Press any key to continue (q to quit)>=20
----------------- Processor 0 LPMC Information ------------------
Check Type =3D 0x00000000
IC Parity Info =3D 0x00000000
Cache Check =3D 0x00000000
TLB Check =3D 0x00000000
Bus Check =3D 0x00000000
Assists Check =3D 0x00000000
Assist State =3D 0x00000000
Path Info =3D 0x00000000
System Responder Address =3D 0x0000000000000000
System Requestor Address =3D 0x0000000000000000
----------------- Processor 0 TOC Information -------------------
General Registers 0 - 31
00-03 0000000000000000 0000000000000000 0000000000000000 00000000000000=
00
04-07 0000000000000000 0000000000000000 0000000000000000 00000000000000=
00
08-11 0000000000000000 0000000000000000 0000000000000000 00000000000000=
00
12-15 0000000000000000 0000000000000000 0000000000000000 00000000000000=
00
16-19 0000000000000000 0000000000000000 0000000000000000 00000000000000=
00
20-23 0000000000000000 0000000000000000 0000000000000000 00000000000000=
00
24-27 0000000000000000 0000000000000000 0000000000000000 00000000000000=
00
28-31 0000000000000000 0000000000000000 0000000000000000 00000000000000=
00
<Press any key to continue (q to quit)>=20
Control Registers 0 - 31
00-03 0000000000000000 0000000000000000 0000000000000000 00000000000000=
00
04-07 0000000000000000 0000000000000000 0000000000000000 00000000000000=
00
08-11 0000000000000000 0000000000000000 0000000000000000 00000000000000=
00
12-15 0000000000000000 0000000000000000 0000000000000000 00000000000000=
00
16-19 0000000000000000 0000000000000000 0000000000000000 00000000000000=
00
20-23 0000000000000000 0000000000000000 0000000000000000 00000000000000=
00
24-27 0000000000000000 0000000000000000 0000000000000000 00000000000000=
00
28-31 0000000000000000 0000000000000000 0000000000000000 00000000000000=
00
Space Registers 0 - 7
00-03 00000000 00000000 00000000 00000000
04-07 00000000 00000000 00000000 00000000
IIA Space =3D 0x0000000000000000
IIA Offset =3D 0x0000000000000000
CPU State =3D 0x00000000
<Press any key to continue (q to quit)>=20
----------------- Processor 1 HPMC Information ------------------
No valid timestamp
HPMC Chassis Codes =3D No chassis codes logged
General Registers 0 - 31
00-03 0000000000000000 0000000000000000 0000000000000000 00000000000000=
00
04-07 0000000000000000 0000000000000000 0000000000000000 00000000000000=
00
08-11 0000000000000000 0000000000000000 0000000000000000 00000000000000=
00
12-15 0000000000000000 0000000000000000 0000000000000000 00000000000000=
00
16-19 0000000000000000 0000000000000000 0000000000000000 00000000000000=
00
20-23 0000000000000000 0000000000000000 0000000000000000 00000000000000=
00
24-27 0000000000000000 0000000000000000 0000000000000000 00000000000000=
00
28-31 0000000000000000 0000000000000000 0000000000000000 00000000000000=
00
<Press any key to continue (q to quit)>=20
Control Registers 0 - 31
00-03 0000000000000000 0000000000000000 0000000000000000 00000000000000=
00
04-07 0000000000000000 0000000000000000 0000000000000000 00000000000000=
00
08-11 0000000000000000 0000000000000000 0000000000000000 00000000000000=
00
12-15 0000000000000000 0000000000000000 0000000000000000 00000000000000=
00
16-19 0000000000000000 0000000000000000 0000000000000000 00000000000000=
00
20-23 0000000000000000 0000000000000000 0000000000000000 00000000000000=
00
24-27 0000000000000000 0000000000000000 0000000000000000 00000000000000=
00
28-31 0000000000000000 0000000000000000 0000000000000000 00000000000000=
00
Space Registers 0 - 7
00-03 00000000 00000000 00000000 00000000
04-07 00000000 00000000 00000000 00000000
<Press any key to continue (q to quit)>=20
IIA Space =3D 0x0000000000000000
IIA Offset =3D 0x0000000000000000
Check Type =3D 0x00000000
CPU State =3D 0x00000000
Cache Check =3D 0x00000000
TLB Check =3D 0x00000000
Bus Check =3D 0x00000000
Assists Check =3D 0x00000000
Assist State =3D 0x00000000
Path Info =3D 0x00000000
System Responder Address =3D 0x0000000000000000
System Requestor Address =3D 0x0000000000000000
Check Summary =3D 0x0000000000000000
Available Memory =3D 0x0000000000000000
CPU Diagnose Register 2 =3D 0x0000000000000000
CPU Status Register 0 =3D 0x0000000000000000
CPU Status Register 1 =3D 0x0000000000000000
SADD LOG =3D 0x0000000000000000
Read Short LOG =3D 0x0000000000000000
<Press any key to continue (q to quit)>=20
----------------- Processor 1 LPMC Information ------------------
Check Type =3D 0x00000000
IC Parity Info =3D 0x00000000
Cache Check =3D 0x00000000
TLB Check =3D 0x00000000
Bus Check =3D 0x00000000
Assists Check =3D 0x00000000
Assist State =3D 0x00000000
Path Info =3D 0x00000000
System Responder Address =3D 0x0000000000000000
System Requestor Address =3D 0x0000000000000000
----------------- Processor 1 TOC Information -------------------
General Registers 0 - 31
00-03 0000000000000000 0000000000000000 0000000000000000 00000000000000=
00
04-07 0000000000000000 0000000000000000 0000000000000000 00000000000000=
00
08-11 0000000000000000 0000000000000000 0000000000000000 00000000000000=
00
12-15 0000000000000000 0000000000000000 0000000000000000 00000000000000=
00
16-19 0000000000000000 0000000000000000 0000000000000000 00000000000000=
00
20-23 0000000000000000 0000000000000000 0000000000000000 00000000000000=
00
24-27 0000000000000000 0000000000000000 0000000000000000 00000000000000=
00
28-31 0000000000000000 0000000000000000 0000000000000000 00000000000000=
00
<Press any key to continue (q to quit)>=20
Control Registers 0 - 31
00-03 0000000000000000 0000000000000000 0000000000000000 00000000000000=
00
04-07 0000000000000000 0000000000000000 0000000000000000 00000000000000=
00
08-11 0000000000000000 0000000000000000 0000000000000000 00000000000000=
00
12-15 0000000000000000 0000000000000000 0000000000000000 00000000000000=
00
16-19 0000000000000000 0000000000000000 0000000000000000 00000000000000=
00
20-23 0000000000000000 0000000000000000 0000000000000000 00000000000000=
00
24-27 0000000000000000 0000000000000000 0000000000000000 00000000000000=
00
28-31 0000000000000000 0000000000000000 0000000000000000 00000000000000=
00
Space Registers 0 - 7
00-03 00000000 00000000 00000000 00000000
04-07 00000000 00000000 00000000 00000000
IIA Space =3D 0x0000000000000000
IIA Offset =3D 0x0000000000000000
CPU State =3D 0x00000000
<Press any key to continue (q to quit)>=20
Memory Error Log Information:
Timestamp =3D Thu Sep 12 08:48:47 GMT 2002 (20:02:09:12:08:48:47)
Trans Addr Central Bus
Status Requestor id par CP AD DV Address/Data
------ ---------- ----- ---- -- -- -- ---------------------
0x14 0xfffa0000 0x00 0x0 0 0 0 0x00000000 0x00000000
Memory
ECC Reg Address Data
---------- ---------- ----------
0x00000000 0x00000000 0x00000000
0x00000000
0x00000000
0x00000000
0x00000000
<Press any key to continue (q to quit)>=20
I/O Module Error Log Information:
Timestamp =3D Thu Sep 12 08:48:49 GMT 2002 (20:02:09:12:08:48:49)
Bus HPA Module Type Path Slt Md Sev Estat Requestor Respon=
der
--- ---------- ---------------- -------- -- -- ---- ----- ---------- ------=
----
0 0xfff88000 I/O Adapter 8 2 0 he 0x0d 0x00000000 0x0000=
0000
0 0xfff8a000 I/O Adapter 10 2 2 he 0x0d 0x00000000 0x0000=
0000
<Press any key to continue (q to quit)>=20
IO Bus Converter Log
--------------------
IOA0 HPA =3D 0xfff88000
IOA0 UBC_IO_CONTROL =3D 0x00020080
GSC1 HPA =3D 0xf1000001
IOA0 IO_IO_LO =3D 0xf1000000
IOA0 IO_IO_HI =3D 0xf1800000
IOA0 IO_IO_LO_HV =3D 0xfc000000
IOA0 IO_IO_HI_HV =3D 0xfff80000
IOA1 HPA =3D 0xfff8a000
IOA1 UBC_IO_CONTROL =3D 0x00020080
GSC2 HPA =3D 0xf1800001
IOA1 IO_IO_LO =3D 0xf1800000
IOA1 IO_IO_HI =3D 0xf2000000
IOA1 IO_IO_LO_HV =3D 0x00000000
IOA1 IO_IO_HI_HV =3D 0x00000000
NIO bus converter register data is not available.
Main Menu: Enter command >=20
Main Menu: Enter command >=20
--LZvS9be/3tNcYl/X--
From grundler@dsl2.external.hp.com Thu Sep 12 19:49:43 2002
From: grundler@dsl2.external.hp.com (Grant Grundler)
Date: Thu, 12 Sep 2002 12:49:43 -0600
Subject: [parisc-linux] SMP problems (hardware gurus, please read)
In-Reply-To: Message from Arto Jantunen <viiru@debian.org>
of "Thu, 12 Sep 2002 12:10:18 +0300." <20020912091018.GA16372@dt-link.fi>
References: <20020912054834.GA32209@www1.dt-link.fi> <Pine.LNX.4.44.0209112338570.1464-100000@garibaldi.apptechsys.com> <20020912091018.GA16372@dt-link.fi>
Message-ID: <20020912184943.99E5C4829@dsl2.external.hp.com>
Arto Jantunen wrote:
> > Also, are there any HP hardware gurus out there that can explain these odd
> > io numbers? Could they be relevant?
Yes, I need to find the right docs to decode the meaning though.
I've not been motivated to chase this lately.
A few more observsation about HPMC problems:
o A500-55 and A500-44 don't have this problem.
o SMP kernel on 1 CPU and UP kernel on the same box *should* do exactly
the same things besides aquire/release spinlocks. This suggests someone
fixed something in the non-SMP code path and missed the SMP part.
> I did this, but the stuff I got from ser pim is almost all zeroes.
> I'm attaching it anyway, but I don't think it is correct. I rebooted
> by shutting it down from the power switch, is there a "softer" way
> to do it (I only have a serial console)?
HP9000/800 series machines should all support <ctl>-B
to get to service processor prompt.
"he" for help.
"rs" to reset the machine.
"tc" to capture current state of the machine for debugging "hung" machines.
(TC data is available with "ser pim" output")
hth,
grant
From derekengelhaupt@rocketmail.com Thu Sep 12 21:12:36 2002
From: derekengelhaupt@rocketmail.com (Derek Engelhaupt)
Date: Thu, 12 Sep 2002 13:12:36 -0700 (PDT)
Subject: [parisc-linux] SMP problems (hardware gurus, please read)
In-Reply-To: <20020912184943.99E5C4829@dsl2.external.hp.com>
Message-ID: <20020912201236.63396.qmail@web12501.mail.yahoo.com>
> HP9000/800 series machines should all support <ctl>-B
> to get to service processor prompt.
> "he" for help.
> "rs" to reset the machine.
> "tc" to capture current state of the machine for debugging "hung"
> machines.
> (TC data is available with "ser pim" output")
The only way you can do a <ctrl>-B on a D/R class is *if* it has a
A3262-69311 card which is the ups/modem/remote access port. It has a
switch on the back that has to be in the service mode for the <cntl>-B
to work. Most of the higher end D/R's have the card and for the lower
models it was and optional part. So if you can't do a <cntl>-B, check
the back of your machine and look for a card that says access port on
it with a little black 2-way switch on it with 2 positions (normal and
service). All the service position does is allow remote access and
enable the <cntl>-B service processor functions.
>Timestamp = Thu Sep 12 08:48:47 GMT 2002 (20:02:09:12:08:48:47)
>
>HPMC Chassis Codes = 0xcbf0 0x5002 0x7d03 0x5408 0x5508 0xcbfb
CBF0-HPMC occurred-starts normal HPMC process
5002-Path error
7D03-Memory MSI read error-says maybe due to a software error
5508-Broad error-part of the hpmc handler
5408-Broad error-part of the hpmc handler
CBFB-Branch to OS HPMC-Normal HPMC process
I'm still trying to locate my I/O troubleshooter. I'll get back to you
later on that. I would say that the MSI read error is generated by the
apt-get and is causing the problem. That's only a quick guess on my
part since I've got to run and replace a system card in an R Class
right now.
derek
__________________________________________________
Do you Yahoo!?
Yahoo! News - Today's headlines
http://news.yahoo.com
From grundler@dsl2.external.hp.com Fri Sep 13 07:00:49 2002
From: grundler@dsl2.external.hp.com (Grant Grundler)
Date: Fri, 13 Sep 2002 00:00:49 -0600 (MDT)
Subject: [parisc-linux] [PATCH] 2.4.19 ppp_generic.c warning fixed
Message-ID: <20020913060049.8A4974829@dsl2.external.hp.com>
Paul,
Wearing my other hat (parisc-linux), I've a fix for "used before
initialized" warning in ppp_generic.c.
The ret value might want to be something other than zero in
the "if (skb) break;" condition.
thanks,
grant
Index: drivers/net/ppp_generic.c
===================================================================
RCS file: /var/cvs/linux/drivers/net/ppp_generic.c,v
retrieving revision 1.11
diff -u -p -r1.11 ppp_generic.c
--- drivers/net/ppp_generic.c 4 Aug 2002 22:58:31 -0000 1.11
+++ drivers/net/ppp_generic.c 13 Sep 2002 05:57:15 -0000
@@ -387,9 +387,9 @@ static ssize_t ppp_read(struct file *fil
for (;;) {
set_current_state(TASK_INTERRUPTIBLE);
skb = skb_dequeue(&pf->rq);
+ ret = 0;
if (skb)
break;
- ret = 0;
if (pf->dead)
break;
ret = -EAGAIN;
From derekengelhaupt@rocketmail.com Fri Sep 13 07:26:39 2002
From: derekengelhaupt@rocketmail.com (Derek Engelhaupt)
Date: Thu, 12 Sep 2002 23:26:39 -0700 (PDT)
Subject: [parisc-linux] Re: OT HP-UX Formatting Scsi disks
In-Reply-To: <sd78d3a1.013@ms-zrt1>
Message-ID: <20020913062639.20473.qmail@web12503.mail.yahoo.com>
> try zeroing out the first few blocks:
>
> dd if=/dev/zero of=/dev/offending_scsi_drive bs=512 count=4
I've decided to load HP-UX on the E55 I've been playing with since
Debian doesn't work very well on it right now. I'm sending this OT
because I need to know where dd lives on an HP-UX 11.11 box. I'm in a
limited shell and need an absolute path to dd to get it to accomplish
the above. It's so limited it won't even give me the ls command. Any
of you HP-UX guys out there? Since I'm at home I don't have access to
an HP-UX box at work. Thanks.
derek
__________________________________________________
Do you Yahoo!?
Yahoo! News - Today's headlines
http://news.yahoo.com
From peterson@easyadpost.com" <peterson@easyadpost.com Fri Sep 13 09:09:02 2002
From: peterson@easyadpost.com" <peterson@easyadpost.com (peterson@easyadpost.com)
Date: Fri, 13 Sep 2002 16:09:02 +0800
Subject: [parisc-linux] http://www.parisc-linux.org/release-0.9/
Message-ID: <20020913070356.9828F482F@dsl2.external.hp.com>
This is a multi-part message in MIME format
--=_NextPart_2rfkindysadvnqw3nerasdf
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable
www.EasyAdPost.com --
Promote your Products and Services on Thousands of Classified Sites.
Simply the Best Way to Sell on the Internet=21=20
No time to post an ad for your business?
Struggling with numerous classified sites?
Seeking effective means to promote your business?=20
All of these are great reasons for you to visit EasyAdPost.com. Currently EasyAdPost.com boasts a database of 120,000+ popular classified sites, to which we will submit your classified ad quickly and effectively. We will as well submit your business site URL or Logo URL to hundreds of thousands of search engines and directories worldwide. Quickly and effectively, EasyAdPost.com will attract potentially millions of people to your business on the Internet, without any hidden cost for advertising=21
Visit Links below for More Details
***********************************************
To learn the generals about EasyAdPost, view http://www.easyadpost.com
To browse the sample list of classified sites, go to http://www.easyadpost.com/sample.php=20
Questions or comments? Post your Query Form to us at http://www.easyadpost.com/aboutus.php=20
***********************************************
Spend your market dollar wisely and good luck to your business=21
Peterson Slade
customer=40easyadpost.com
EasyAdPost.com
--=_NextPart_2rfkindysadvnqw3nerasdf
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<title>EasyAdPost.com</title>
<meta http-equiv=3D=22Content-Type=22 content=3D=22text/html; charset=3Diso-8859-1=22>
</head>
<body bgcolor=3D=22EBF1F8=22 text=3D=22=23000000=22>
<table width=3D=22500=22 border=3D=220=22 cellspacing=3D=220=22 cellpadding=3D=220=22>
<tr>=20 <td bgcolor=3D=22=23FFFFFF=22 height=3D=2215=22 align=3D=22center=22> <font face=3D=22Verdana, Arial, Helvetica, sans-serif=22 size=3D=222=22><b><font color=3D=22=23FF0000=22>http://www.parisc-linux.org/release-0.9/errata-093.html</font></b></font>=20 </td>
</tr>
<tr>=20 <td bgcolor=3D=22=23FFFFFF=22 align=3D=22center=22>=20 <table width=3D=22446=22 border=3D=220=22 cellspacing=3D=220=22 cellpadding=3D=220=22>
<tr>
<td>
<table border=3D=220=22 cellspacing=3D=220=22 cellpadding=3D=220=22>
<tr align=3D=22center=22 valign=3D=22top=22>=20 <td colspan=3D=223=22 height=3D=2241=22>=20 <p><a href=3D=22http://www.easyadpost.com=22 target=3D=22_blank=22><img src=3D=22http://imgdef.easyadpost.com/addef/em_01.gif=22 width=3D=22446=22 height=3D=2241=22 border=3D=220=22></a></p>
</td>
</tr>
<tr>=20 <td width=3D=2296=22><a href=3D=22http://www.easyadpost.com=22 target=3D=22_blank=22><img src=3D=22http://imgdef.easyadpost.com/addef/em_04.gif=22 width=3D=2296=22 height=3D=22160=22 border=3D=220=22></a></td>
<td width=3D=22241=22><a href=3D=22http://www.easyadpost.com=22 target=3D=22_blank=22><img src=3D=22http://image1.easyadpost.com/adbmp/1/4/sna309.jpg=22 width=3D=22241=22 height=3D=22160=22 border=3D=220=22></a></td>
<td width=3D=22109=22><a href=3D=22http://www.easyadpost.com=22 target=3D=22_blank=22><img src=3D=22http://imgdef.easyadpost.com/addef/em_05.gif=22 width=3D=22109=22 height=3D=22160=22 border=3D=220=22></a></td>
</tr>
<tr>=20 <td width=3D=2296=22><img src=3D=22http://imgdef.easyadpost.com/addef/em_06.gif=22 height=3D=226=22 border=3D=220=22></td>
<td width=3D=22241=22><img src=3D=22http://imgdef.easyadpost.com/addef/em_07.gif=22 height=3D=226=22 border=3D=220=22></td>
<td width=3D=22109=22><img src=3D=22http://imgdef.easyadpost.com/addef/em_08.gif=22 width=3D=22109=22 height=3D=226=22 border=3D=220=22></td>
</tr>
</table>
</td>
</tr>
<tr>
<td><a href=3D=22http://www.easyadpost.com=22 target=3D=22_blank=22><img src=3D=22http://imgdef.easyadpost.com/addef/em_09.gif=22 width=3D=22446=22 height=3D=2289=22 border=3D=220=22></a></td>
</tr>
</table>
=20 </td>
</tr>
<tr>
<td bgcolor=3D=22=23FFFFFF=22> </td>
</tr>
<tr>=20 <td bgcolor=3D=22=23FFFFFF=22>
<table width=3D=22517=22 border=3D=220=22 cellspacing=3D=220=22 cellpadding=3D=220=22>
<tr>=20 <td>=20 <table width=3D=22480=22 border=3D=220=22 cellspacing=3D=220=22 cellpadding=3D=220=22>
<tr>=20 <td width=3D=2250=22>=20 <p><font face=3D=22Geneva, Arial, Helvetica, san-serif=22><br>
</font> </p>
</td>
<td>
<p><font face=3D=22Verdana, Arial, Helvetica, sans-serif=22 size=3D=222=22><b><font color=3D=22=23FF0000=22>EasyAdPost.com=20 --</font><br>
<font color=3D=22=233399FF=22>Promote your Products and Services on=20 Thousands of Classified Sites.<br>
Simply the Best Way to Sell on the Internet=21 </font></b></font>=20 </p>
<p><font face=3D=22Verdana, Arial, Helvetica, sans-serif=22 size=3D=222=22>No=20 time to post an ad for your business?<br>
Struggling with numerous classified sites?<br>
Seeking effective means to promote your business?</font> </p>
<p><font face=3D=22Verdana, Arial, Helvetica, sans-serif=22 size=3D=222=22>All=20 of these are great reasons for you to visit EasyAdPost.com.=20 Currently EasyAdPost.com boasts a database of 120,000+ popular=20 classified sites, to which we will submit your classified=20 ad quickly and effectively. We will as well submit your business=20 site URL or Logo URL to hundreds of thousands of search engines=20 and directories worldwide. Quickly and effectively, EasyAdPost.com=20 will attract potentially millions of people to your business=20 on the Internet, without any hidden cost for advertising=21</font></p>
<p align=3D=22center=22><font face=3D=22Verdana, Arial, Helvetica, sans-serif=22 size=3D=222=22>Visit=20 Links below for More Details</font></p>
<p align=3D=22center=22><font face=3D=22Verdana, Arial, Helvetica, sans-serif=22 size=3D=222=22>***********************************************</font></p>
<p><font face=3D=22Verdana, Arial, Helvetica, sans-serif=22 size=3D=222=22>To=20 learn the generals about EasyAdPost, view <a href=3D=22http://www.easyadpost.com=22 target=3D=22_blank=22>http://www.easyadpost.com</a><br>
<br>
To browse the sample list of classified sites, go to <a href=3D=22http://www.easyadpost.com/sample.php%20=22 target=3D=22_blank=22>http://www.easyadpost.com/sample.php</a>=20 </font></p>
<p><font face=3D=22Verdana, Arial, Helvetica, sans-serif=22 size=3D=222=22>Questions=20 or comments? Post your Query Form to us at <a href=3D=22http://www.easyadpost.com/aboutus.php=22 target=3D=22_blank=22>http://www.easyadpost.com/aboutus.php</a>=20 </font></p>
<p align=3D=22center=22><font face=3D=22Verdana, Arial, Helvetica, sans-serif=22 size=3D=222=22>***********************************************</font></p>
<p><font face=3D=22Verdana, Arial, Helvetica, sans-serif=22 size=3D=222=22>Spend=20 your market dollar wisely and good luck to your business=21</font></p>
<p><font face=3D=22Verdana, Arial, Helvetica, sans-serif=22 size=3D=222=22>Peterson=20 Slade<br>
<a href=3D=22mailto:customer=40easyadpost.com=22>customer=40easyadpost.com</a><br>
EasyAdPost.com<br>
</font></p>
<p> </p>
</td>
</tr>
</table>
</td>
</tr>
</table>
<p> </p></td>
</tr>
</table>
</body>
</html>
--=_NextPart_2rfkindysadvnqw3nerasdf--
From willy@debian.org Fri Sep 13 16:02:46 2002
From: willy@debian.org (Matthew Wilcox)
Date: Fri, 13 Sep 2002 16:02:46 +0100
Subject: [parisc-linux] Remote access card in D/R class
Message-ID: <20020913160246.T10583@parcelfarce.linux.theplanet.co.uk>
Thanks to Derek Engelhaupt getting me some information, I now feel fairly
certain that Ryan Bradetich's Mux driver will support the D and R class
remote serial card. So everyone who unplugged their remote serial card
to get their D/R class working should be able to plug it back in and
boot a recent kernel using `console=ttyB0' to get output on their remote
serial port. Feedback from anyone who can test this feature appreciated.
I'm now scheming to see if we can reclaim Lasi's serial port, even
though firmware's disabled it. Because you can never have too many
serial ports, right? :-)
--
Revolutions do not require corporate support.
From robin@uk.another.com Fri Sep 13 16:09:20 2002
From: robin@uk.another.com (Robin Kearney)
Date: Fri, 13 Sep 2002 16:09:20 +0100
Subject: [parisc-linux] HP9000
Message-ID: <C754C281-C72A-11D6-B5A2-000393447076@uk.another.com>
Hi, we have a spare HP9000 machine which is going to be thrown out.
Would anybody in the linux pa-risc community like it to help their
porting efforts?
Not sure of the spec, but can find out if needed.
We are in north london, would be nice if you could collect if you want
it.
Price? all we ask is a credit on a site if it proves useful.
robin.
--
another.com
sysadmin
+44 (0)20 7424 3061
From willy@debian.org Fri Sep 13 16:16:23 2002
From: willy@debian.org (Matthew Wilcox)
Date: Fri, 13 Sep 2002 16:16:23 +0100
Subject: [parisc-linux] HP9000
In-Reply-To: <C754C281-C72A-11D6-B5A2-000393447076@uk.another.com>; from robin@uk.another.com on Fri, Sep 13, 2002 at 04:09:20PM +0100
References: <C754C281-C72A-11D6-B5A2-000393447076@uk.another.com>
Message-ID: <20020913161623.U10583@parcelfarce.linux.theplanet.co.uk>
On Fri, Sep 13, 2002 at 04:09:20PM +0100, Robin Kearney wrote:
> Hi, we have a spare HP9000 machine which is going to be thrown out.
It'd help if you could specify the model -- some machines are more, er,
tricky than others ;-) We're looking for something like "D220" or "F80"
as a description.
--
Revolutions do not require corporate support.
From robin@uk.another.com Fri Sep 13 16:25:31 2002
From: robin@uk.another.com (Robin Kearney)
Date: Fri, 13 Sep 2002 16:25:31 +0100
Subject: [parisc-linux] HP9000
In-Reply-To: <20020913161623.U10583@parcelfarce.linux.theplanet.co.uk>
Message-ID: <0A29117C-C72D-11D6-B5A2-000393447076@uk.another.com>
On Friday, September 13, 2002, at 04:16 pm, Matthew Wilcox wrote:
> On Fri, Sep 13, 2002 at 04:09:20PM +0100, Robin Kearney wrote:
>> Hi, we have a spare HP9000 machine which is going to be thrown out.
>
> It'd help if you could specify the model -- some machines are more, er,
> tricky than others ;-) We're looking for something like "D220" or
> "F80"
> as a description.
Ok, some details from looking at the actual HW:
Only model number I can find is 'L1000 440Mhz'
4 disk slots (all sca)
1 5 1/4" slot
(used to contain a scsi dvd drive, but I guess another sysadmin thought
it would serve him better)
has space for 3 psu's (1 currently in residence)
12 PCI slots.
Can have upto 4cpu's but currently has 1
There are no disks but I'm sure I can find a 9Gig so its at least
useful.
HTH
r.
--
another.com
sysadmin
+44 (0)20 7424 3061
From varenet@esiee.fr Fri Sep 13 17:31:35 2002
From: varenet@esiee.fr (Thibaut VARENE)
Date: Fri, 13 Sep 2002 18:31:35 +0200
Subject: [parisc-linux] Making SYM2 default SYM-SCSI driver instead of SYM1
Message-ID: <3D8212E7.6000609@esiee.fr>
Hi fellows !
Paul Bame has noticed a problem that seems to occur on B2600 with SYM1
driver, causing the box to slow down everything and increasing the
loadavg, while top reports 99% idle.
When this happens, one can hear HD making strange noise: two grouped
"ticks" every 2 seconds or so.
I have experienced this behavior by myself, and it seems that using SYM2
driver solves this problem.
Now I'm asking you to know if anybody has an objection against making
SYM2 the default driver in debian-configs instead of old SYM1.
Thanks,
Thibaut VARENE
PA/Linux ESIEE Team
http://pateam.esiee.fr/
From grundler@dsl2.external.hp.com Fri Sep 13 18:03:51 2002
From: grundler@dsl2.external.hp.com (Grant Grundler)
Date: Fri, 13 Sep 2002 11:03:51 -0600 (MDT)
Subject: [parisc-linux] misaligned handler failing...
Message-ID: <20020913170351.1D5414829@dsl2.external.hp.com>
grundler@debian:~$ /usr/X11R6/bin/xlock -mode morph3d
Access control list restored.
xlock: caught signal 10 while running morph3d mode (uid 1000).
I haven't explicitly tested all modes, but this is the only
failure I've seen.
grundler@debian:~$ fgrep 10 /usr/include/asm/signal.h
#define SIGBUS 10
#define SA_SIGINFO 0x00000010
#define _SA_SIGGFAULT 0x00000100 /* HPUX */
grundler@debian:~$
SIGBUS implies a misaligned address access....and dmesg output confirms
that theory:
xlock(16254): unaligned access to 0x4071402c at ip=0x400ea63f
Not-handled unaligned insn 0x2fe81205
Unaligned handler failed, ret = -1
xlock (pid 16254): Unaligned data reference (code 28)
YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
PSW: 00000000000001101111111100001111 Not tainted
r00-03 00000000 00267c90 400d2943 4013c558
r04-07 00267a60 001dcec8 001d9ec8 002486c8
r08-11 001d9ec8 001d9ec8 002486c8 001d9ec8
r12-15 001d9ec8 00000001 002596c8 001d9ec8
r16-19 002486c8 00000000 002486c8 4013c558
r20-23 00000034 000000af 400ea5e8 4071403c
r24-27 40714024 40714028 00267c90 001d9ec8
r28-31 0026b160 40753f48 faf00b80 40714028
sr0-3 00000000 00000050 00000000 00000050
sr4-7 00000050 00000050 00000050 00000050
IASQ: 00000050 00000050 IAOQ: 400ea63f 400ea643
IIR: 2fe81205 ISR: 00000050 IOR: 4071402c
grant
From Randolph Chung <randolph@tausq.org> Fri Sep 13 18:21:25 2002
From: Randolph Chung <randolph@tausq.org> (Randolph Chung)
Date: Fri, 13 Sep 2002 10:21:25 -0700
Subject: [parisc-linux] misaligned handler failing...
In-Reply-To: <20020913170351.1D5414829@dsl2.external.hp.com>
References: <20020913170351.1D5414829@dsl2.external.hp.com>
Message-ID: <20020913172125.GX17893@tausq.org>
> xlock(16254): unaligned access to 0x4071402c at ip=0x400ea63f
> Not-handled unaligned insn 0x2fe81205
> Unaligned handler failed, ret = -1
> xlock (pid 16254): Unaligned data reference (code 28)
that insn is fstd fr5,4(sr0,r31) ... and indeed the unaligned handler
doesn't do anything with the floating point instructions.
we probably should try to hunt down the broken code in xlock (or the lib
that contains the insn) and fix it...
randolph
--
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/
From grundler@dsl2.external.hp.com Fri Sep 13 18:26:22 2002
From: grundler@dsl2.external.hp.com (Grant Grundler)
Date: Fri, 13 Sep 2002 11:26:22 -0600
Subject: [parisc-linux] HP9000
In-Reply-To: Message from Robin Kearney <robin@uk.another.com>
of "Fri, 13 Sep 2002 16:25:31 BST." <0A29117C-C72D-11D6-B5A2-000393447076@uk.another.com>
References: <0A29117C-C72D-11D6-B5A2-000393447076@uk.another.com>
Message-ID: <20020913172622.4E6294829@dsl2.external.hp.com>
Robin Kearney wrote:
> Only model number I can find is 'L1000 440Mhz'
> 4 disk slots (all sca)
> 1 5 1/4" slot
> (used to contain a scsi dvd drive, but I guess another sysadmin thought
> it would serve him better)
> has space for 3 psu's (1 currently in residence)
> 12 PCI slots.
> Can have upto 4cpu's but currently has 1
This is the "big brother" to an A500. Same chipset but more IO slots.
parisc-linux should run on this box just fine.
> There are no disks but I'm sure I can find a 9Gig so its at least
> useful.
Don't forget the disk carriers - those are *much* harder to find
than the disks.
grant
From grundler@dsl2.external.hp.com Fri Sep 13 20:09:29 2002
From: grundler@dsl2.external.hp.com (Grant Grundler)
Date: Fri, 13 Sep 2002 13:09:29 -0600
Subject: [parisc-linux] Making SYM2 default SYM-SCSI driver instead of SYM1
In-Reply-To: Message from Thibaut VARENE <varenet@esiee.fr>
of "Fri, 13 Sep 2002 18:31:35 +0200." <3D8212E7.6000609@esiee.fr>
References: <3D8212E7.6000609@esiee.fr>
Message-ID: <20020913190929.8F8084829@dsl2.external.hp.com>
Thibaut VARENE wrote:
> Now I'm asking you to know if anybody has an objection against making
> SYM2 the default driver in debian-configs instead of old SYM1.
I don't. All the boxes I care about have 53c8xx chips in them.
A slightly safer approach is to make sym2 the default for PA2.0 systems
and the old sym the default for PA1.1 systems. But GSC/HSC c720 cards
don't fit that model since they go into systems with either sub-arch.
I don't see a way around users "tuning" based on actual HW configuration.
grant
From christoph.plattner@gmx.at Fri Sep 13 20:16:09 2002
From: christoph.plattner@gmx.at (Christoph Plattner)
Date: Fri, 13 Sep 2002 21:16:09 +0200
Subject: [parisc-linux] Re: OT HP-UX Formatting Scsi disks
References: <20020913062639.20473.qmail@web12503.mail.yahoo.com>
Message-ID: <3D823979.9CA0117E@gmx.at>
Hello,
I hope the status will change soon. I also have an E55
and I use it under HP-UX. But I want to switch as fast
as possible to linux.
I can use the E55 now as diskless server (!), SCSI is
not working yet. But as I mentioned, I hope this will
change very soon !!
Christoph
Derek Engelhaupt wrote:
>
> > try zeroing out the first few blocks:
> >
> > dd if=/dev/zero of=/dev/offending_scsi_drive bs=512 count=4
>
> I've decided to load HP-UX on the E55 I've been playing with since
> Debian doesn't work very well on it right now. I'm sending this OT
> because I need to know where dd lives on an HP-UX 11.11 box. I'm in a
> limited shell and need an absolute path to dd to get it to accomplish
> the above. It's so limited it won't even give me the ls command. Any
> of you HP-UX guys out there? Since I'm at home I don't have access to
> an HP-UX box at work. Thanks.
>
> derek
>
> __________________________________________________
> Do you Yahoo!?
> Yahoo! News - Today's headlines
> http://news.yahoo.com
> _______________________________________________
> parisc-linux mailing list
> parisc-linux@lists.parisc-linux.org
> http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
--
-------------------------------------------------------
private: christoph.plattner@gmx.at
company: christoph.plattner@alcatel.at
From joel.soete@freebel.net Fri Sep 13 21:44:34 2002
From: joel.soete@freebel.net (Joel Soete)
Date: Fri, 13 Sep 2002 20:44:34 +0000
Subject: [parisc-linux] Making SYM2 default SYM-SCSI driver instead of
SYM1
References: <3D8212E7.6000609@esiee.fr>
Message-ID: <3D824E32.2060301@freebel.net>
Hi Thibaut,
Thibaut VARENE wrote:
> Hi fellows !
>
> Paul Bame has noticed a problem that seems to occur on B2600 with SYM1
> driver, causing the box to slow down everything and increasing the
> loadavg, while top reports 99% idle.
>
> When this happens, one can hear HD making strange noise: two grouped
> "ticks" every 2 seconds or so.
>
> I have experienced this behavior by myself, and it seems that using SYM2
> driver solves this problem.
At a moment it solved also this problem of disk on my b2k. So for
severall month now, I use only SYM2 on this b2k.
More over as on a b180 I notice that SYM2 driver could also be used
also, I test it with same success.
(sorry I could not any more test on 712)
Good idea,
Joel
From joel.soete@freebel.net Fri Sep 13 22:39:42 2002
From: joel.soete@freebel.net (Joel Soete)
Date: Fri, 13 Sep 2002 21:39:42 +0000
Subject: [Fwd: Re: [parisc-linux] Inline Assembly Help request]
Message-ID: <3D825B1E.3090701@freebel.net>
Paul Bame wrote:
> As jda mentioned, the ex_table stuff is a bit complex. You can find out
> how the x86 exception table works in linux/Documentation/exception.txt
> but parisc is a little different.
> I leave it to you to locate the relevent
> exception handler somewhere in arch/parisc/kernel/ A thorough
understanding
> of the exception handler method is necessary to understand and/or change
> the code you are working with.
>
is it do_page_fault (in fault.c) which use search_exception_table(...)?
Thanks,
Joel
PS: Do you have an idea how may I figure out in which registers are
stored the two parts of a 64bits int (always contigus) or would it be
better to work with x address (in put_user_asm("stw",x,ptr)).
I also presume that there is noe way for gas to simulate (some kind of
macro ) std and ldd from pa2 onto pa1. It would be too easy :)?
From dave@hiauly1.hia.nrc.ca Fri Sep 13 21:49:39 2002
From: dave@hiauly1.hia.nrc.ca (John David Anglin)
Date: Fri, 13 Sep 2002 16:49:39 -0400 (EDT)
Subject: [Fwd: Re: [parisc-linux] Inline Assembly Help request]
In-Reply-To: <3D825B1E.3090701@freebel.net> from "Joel Soete" at Sep 13, 2002 09:39:42 pm
Message-ID: <200209132049.g8DKneZ1012121@hiauly1.hia.nrc.ca>
> PS: Do you have an idea how may I figure out in which registers are
> stored the two parts of a 64bits int (always contigus) or would it be
> better to work with x address (in put_user_asm("stw",x,ptr)).
There is no hard and fast rule. The treatment used by GCC is defined
in HARD_REGNO_MODE_OK in pa32-regs.h. Currently we used consecutive
pairs of registers. This may be subject to change though.
Dave
--
J. David Anglin dave.anglin@nrc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6605)
From christoph.plattner@gmx.at Fri Sep 13 22:59:59 2002
From: christoph.plattner@gmx.at (Christoph Plattner)
Date: Fri, 13 Sep 2002 23:59:59 +0200
Subject: [parisc-linux] MUX driver on E55
Message-ID: <3D825FDF.CD6E8CE2@gmx.at>
Hallo Ryan !
Congratulation, your MUX driver on port 0 is really
working on my machine !!
What do you miss to support the other lines ?
Have you already knowledge of the data structure ?
Can I help you here in the code ?
Another point: you mentioned the skeleton of the
SCSI SPIFI driver. Where can I find that ? I only
found a NetBSD code, which I will use as functional
template, but I do not know, if this would be enough.
Can you give me a hint in this point ?
Christoph
--
-------------------------------------------------------
private: christoph.plattner@gmx.at
company: christoph.plattner@alcatel.at
From christoph.plattner@gmx.at Fri Sep 13 23:25:10 2002
From: christoph.plattner@gmx.at (Christoph Plattner)
Date: Sat, 14 Sep 2002 00:25:10 +0200
Subject: [parisc-linux] MUX driver for multiple ports (lines)
Message-ID: <3D8265C6.16ECEBB@gmx.at>
Hallo Ryan,
have you already got docu on the serial MUX board ?
Or where do you have the information about `#define's
from. Is the MUX_LINE_OFFSET (= 0x80) the key point.
I have tried to access the board at
membase + MUX_OFFSET + line * MUX_LINE_OFFSET,
but the first write access to /dev/ttyB1 results in
a hang up (completely, even no network interrupts
were processed !).
Operates the MUX driver in polling mode ? Not in IRQ mode ?
Christoph
--
-------------------------------------------------------
private: christoph.plattner@gmx.at
company: christoph.plattner@alcatel.at
From rbradetich@uswest.net Sat Sep 14 01:04:09 2002
From: rbradetich@uswest.net (Ryan Bradetich)
Date: 13 Sep 2002 18:04:09 -0600
Subject: [parisc-linux] Re: MUX driver for multiple ports (lines)
In-Reply-To: <3D8265C6.16ECEBB@gmx.at>
References: <3D8265C6.16ECEBB@gmx.at>
Message-ID: <1031961850.930.7.camel@beavis>
Hello Christoph,
No, I still have not found any documentation on the
Serial Mux driver. The work I did was referenced
off the HP-UX mux driver.
>From what I can see, the 0x80 (MUX_LINE_OFFSET)
is the offset between the mux registers for each
line. I have not tried to hook up multiple lines
yet but I believe the skeleton is there. Did the
box HPMC? Can you get a TOC and read the IAOQ to
see what caused the crash? Maybe we need to add
additional locking to the driver, etc.
The mux only operates in a polling mode. The HP-UX
driver also polls (I don't see anywhere in the driver
where it could create/cause/catch an interrupt).
I will be out this weekend, but back early next week.
Let me know what you find, and I'll take a poke and
see if I can help!
Thanks,
- Ryan
On Fri, 2002-09-13 at 16:25, Christoph Plattner wrote:
> Hallo Ryan,
>
> have you already got docu on the serial MUX board ?
> Or where do you have the information about `#define's
> from. Is the MUX_LINE_OFFSET (= 0x80) the key point.
>
> I have tried to access the board at
> membase + MUX_OFFSET + line * MUX_LINE_OFFSET,
> but the first write access to /dev/ttyB1 results in
> a hang up (completely, even no network interrupts
> were processed !).
>
> Operates the MUX driver in polling mode ? Not in IRQ mode ?
>
> Christoph
>
> --
> -------------------------------------------------------
> private: christoph.plattner@gmx.at
> company: christoph.plattner@alcatel.at
>
From rbradetich@uswest.net Sat Sep 14 01:13:19 2002
From: rbradetich@uswest.net (Ryan Bradetich)
Date: 13 Sep 2002 18:13:19 -0600
Subject: [parisc-linux] Re: MUX driver on E55
In-Reply-To: <3D825FDF.CD6E8CE2@gmx.at>
References: <3D825FDF.CD6E8CE2@gmx.at>
Message-ID: <1031962399.930.17.camel@beavis>
On Fri, 2002-09-13 at 15:59, Christoph Plattner wrote:
> Hallo Ryan !
>
> Congratulation, your MUX driver on port 0 is really
> working on my machine !!
Glad to hear that!
> What do you miss to support the other lines ?
I am not sure, I've never tried to hook up additional
lines. I do have an 8-port MDP somewhere, I'll look
for it here shortly, and see if I can hook it up.
> Have you already knowledge of the data structure ?
Just what I have added into the driver. If there is
something that we are obviously missing, I can go back
and reference the HP-UX mux driver and see what is
missing.
> Can I help you here in the code ?
Please! :) I do not use multiple lines currently ...
I only use the line 0, so any testing, optimizing, etc
is greatly appreciated!
> Another point: you mentioned the skeleton of the
> SCSI SPIFI driver. Where can I find that ? I only
> found a NetBSD code, which I will use as functional
> template, but I do not know, if this would be enough.
> Can you give me a hint in this point ?
I have it on my local system. It is _very_ ugly at this
point. I have got enough to query information from the
spifi chip, register an interrupt, etc... but currently
I can not get the spifi chip to actually generate an
interrupt.
I would be happy to send you a copy when I get back next
monday (unless you catch my in the next hour or so), but
I'm not ready to check it into CVS yeah until I get rid
of the some ugly hardcoded hacks, global variables, etc.
Right now the driver is really coded to gather info from
the ESIEE E35 that I have been testing on. Once again,
I do not have any docs on the chipset, I am using both
the NetBSD and HP-UX drivers as reference. :(
The driver should be easy to modify for your specific E55,
but not sure if you are interested in that level of work,
messyness now. I promise it will get much better :)
Thanks,
- Ryan
> Christoph
>
>
> --
> -------------------------------------------------------
> private: christoph.plattner@gmx.at
> company: christoph.plattner@alcatel.at
>
From christoph.plattner@gmx.at Sat Sep 14 01:25:24 2002
From: christoph.plattner@gmx.at (Christoph Plattner)
Date: Sat, 14 Sep 2002 02:25:24 +0200
Subject: [parisc-linux] Re: MUX driver on E55
References: <3D825FDF.CD6E8CE2@gmx.at> <1031962399.930.17.camel@beavis>
Message-ID: <3D8281F4.F03A2007@gmx.at>
Hello,
if it is possible, send the code to me (perhpas I can
have a look @ week end.
Is it possible to geht the HP-UX driver codes for those
to things ? MUX + SCSI ?
I was offered to sign a NDA, but then nothing happens ...
It would be more easy for me to read such original HP-UX
code. Perhaps you see a possibility to send it also.
Have a nice week end
Christoph
Ryan Bradetich wrote:
>
> On Fri, 2002-09-13 at 15:59, Christoph Plattner wrote:
> > Hallo Ryan !
> >
> > Congratulation, your MUX driver on port 0 is really
> > working on my machine !!
>
> Glad to hear that!
>
> > What do you miss to support the other lines ?
>
> I am not sure, I've never tried to hook up additional
> lines. I do have an 8-port MDP somewhere, I'll look
> for it here shortly, and see if I can hook it up.
>
> > Have you already knowledge of the data structure ?
>
> Just what I have added into the driver. If there is
> something that we are obviously missing, I can go back
> and reference the HP-UX mux driver and see what is
> missing.
>
> > Can I help you here in the code ?
>
> Please! :) I do not use multiple lines currently ...
> I only use the line 0, so any testing, optimizing, etc
> is greatly appreciated!
>
> > Another point: you mentioned the skeleton of the
> > SCSI SPIFI driver. Where can I find that ? I only
> > found a NetBSD code, which I will use as functional
> > template, but I do not know, if this would be enough.
> > Can you give me a hint in this point ?
>
> I have it on my local system. It is _very_ ugly at this
> point. I have got enough to query information from the
> spifi chip, register an interrupt, etc... but currently
> I can not get the spifi chip to actually generate an
> interrupt.
>
> I would be happy to send you a copy when I get back next
> monday (unless you catch my in the next hour or so), but
> I'm not ready to check it into CVS yeah until I get rid
> of the some ugly hardcoded hacks, global variables, etc.
> Right now the driver is really coded to gather info from
> the ESIEE E35 that I have been testing on. Once again,
> I do not have any docs on the chipset, I am using both
> the NetBSD and HP-UX drivers as reference. :(
>
> The driver should be easy to modify for your specific E55,
> but not sure if you are interested in that level of work,
> messyness now. I promise it will get much better :)
>
> Thanks,
>
> - Ryan
>
> > Christoph
> >
> >
> > --
> > -------------------------------------------------------
> > private: christoph.plattner@gmx.at
> > company: christoph.plattner@alcatel.at
> >
--
-------------------------------------------------------
private: christoph.plattner@gmx.at
company: christoph.plattner@alcatel.at
From andrew@neep.com.au Sat Sep 14 02:04:43 2002
From: andrew@neep.com.au (Andrew Shugg)
Date: Sat, 14 Sep 2002 09:04:43 +0800
Subject: [parisc-linux] Re: OT HP-UX Formatting Scsi disks
In-Reply-To: <20020913062639.20473.qmail@web12503.mail.yahoo.com>; from derekengelhaupt@rocketmail.com on Thu, Sep 12, 2002 at 11:26:39PM -0700
References: <sd78d3a1.013@ms-zrt1> <20020913062639.20473.qmail@web12503.mail.yahoo.com>
Message-ID: <20020914090440.D30097@neep.com.au>
Derek Engelhaupt said:
> I've decided to load HP-UX on the E55 I've been playing with since
> Debian doesn't work very well on it right now. I'm sending this OT
> because I need to know where dd lives on an HP-UX 11.11 box. I'm in a
> limited shell and need an absolute path to dd to get it to accomplish
> the above. It's so limited it won't even give me the ls command. Any
> of you HP-UX guys out there? Since I'm at home I don't have access to
> an HP-UX box at work. Thanks.
Just how limited is this shell? Are you just not able to see any
output? What happens when you run '/bin/ls'?
If you can get stdout, try 'which dd' and 'find / -type f -name dd -print'
to locate the program. I don't have an HP/UX box in front of me either,
or I would just tell you where dd lived. =)
Andrew.
--
Andrew Shugg <andrew@neep.com.au> 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 schnelle@kabelleipzig.de Sat Sep 14 07:49:28 2002
From: schnelle@kabelleipzig.de (sven schnelle)
Date: Sat, 14 Sep 2002 08:49:28 +0200
Subject: [parisc-linux] Re: OT HP-UX Formatting Scsi disks
References: <sd78d3a1.013@ms-zrt1> <20020913062639.20473.qmail@web12503.mail.yahoo.com> <20020914090440.D30097@neep.com.au>
Message-ID: <3D82DBF8.2010000@kabelleipzig.de>
Derek Engelhaupt said:
>I've decided to load HP-UX on the E55 I've been playing with since
>Debian doesn't work very well on it right now. I'm sending this OT
>because I need to know where dd lives on an HP-UX 11.11 box. I'm in a
[...]
hello,
on my gecko with HP-UX 10.20 it lives in /usr/bin, maybe its the same on
HP-UX 11.11.
Bye
Sven.
From varenet@esiee.fr Sat Sep 14 11:14:53 2002
From: varenet@esiee.fr (Thibaut VARENE)
Date: Sat, 14 Sep 2002 12:14:53 +0200
Subject: [parisc-linux] Making SYM2 default SYM-SCSI driver instead of SYM1
In-Reply-To: <20020913190929.8F8084829@dsl2.external.hp.com>
Message-ID: <CFEA4CE8-C7CA-11D6-BDC5-0030656F07A2@esiee.fr>
Le vendredi, 13 sep 2002, =E0 21:09 Europe/Paris, Grant Grundler a =E9crit=
:
> Thibaut VARENE wrote:
>> Now I'm asking you to know if anybody has an objection against making
>> SYM2 the default driver in debian-configs instead of old SYM1.
>
> I don't. All the boxes I care about have 53c8xx chips in them.
>
> A slightly safer approach is to make sym2 the default for PA2.0 =
systems
> and the old sym the default for PA1.1 systems. But GSC/HSC c720 cards
> don't fit that model since they go into systems with either sub-arch.
> I don't see a way around users "tuning" based on actual HW=20
> configuration.
Well, this might be a good solution, though IIRC, Randolph Chung=20
mentioned
that sym1 is b0rken in Linux 2.5.
Therefore making sym2 default for both archs may be preferable for=20
future compatibility?
Anyway, I think we can start with making sym2 default for PA2.0,=20
keeping sym1 for PA1.1,
and then "wait and see".
If everything goes well, we can switch PA1.1 as well.
Opinions ? :)
Thibaut VARENE
PA/Linux ESIEE Team
http://pateam.esiee.fr/=
From grundler@dsl2.external.hp.com Sat Sep 14 23:59:11 2002
From: grundler@dsl2.external.hp.com (Grant Grundler)
Date: Sat, 14 Sep 2002 16:59:11 -0600
Subject: [parisc-linux] Making SYM2 default SYM-SCSI driver instead of SYM1
In-Reply-To: Message from Thibaut VARENE <varenet@esiee.fr>
of "Sat, 14 Sep 2002 12:14:53 +0200." <CFEA4CE8-C7CA-11D6-BDC5-0030656F07A2@esiee.fr>
References: <CFEA4CE8-C7CA-11D6-BDC5-0030656F07A2@esiee.fr>
Message-ID: <20020914225912.2AE904829@dsl2.external.hp.com>
Thibaut VARENE wrote:
> though IIRC, Randolph Chung mentioned
> that sym1 is b0rken in Linux 2.5.
It won't always be broken.
> Anyway, I think we can start with making sym2 default for PA2.0,
> keeping sym1 for PA1.1, and then "wait and see".
>
> If everything goes well, we can switch PA1.1 as well.
If we switch PA1.1, then we should do that for both releases.
And when we do so, better add a FAQ about "SCSI Controller not found".
Maybe even add it now already to cover PA2.0 case (but don't mention
PA2.0 in the FAQ).
grant
From deller@gmx.de Sun Sep 15 01:09:46 2002
From: deller@gmx.de (Helge Deller)
Date: Sun, 15 Sep 2002 02:09:46 +0200
Subject: [parisc-linux] [PATCH] Voodoo framebuffer on PARISC
Message-ID: <200209150209.46701.deller@gmx.de>
--Boundary-00=_K/8g9cdhjiEuAkF
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: 8bit
Content-Disposition: inline
Hi,
there has been some discussions on this lists a few weeks back
about getting the Voodoo framebuffer driver working on HPPA.
The attached patch allows me to use my Voodoo 2 with the sstfb
framebuffer driver in 16bpp in 640x480, 800x600 and 1024x768
resolutions on console and under X.
Greetings,
Helge
NB: This patch is already integrated into the 2.4.19-pa18 kernel and
I'll continue to do some more code-cleanups before trying to get it
into the official kernel.
--Boundary-00=_K/8g9cdhjiEuAkF
Content-Type: text/plain;
charset="us-ascii";
name="diff"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="diff"
Index: sstfb.c
===================================================================
RCS file: /var/cvs/linux/drivers/video/sstfb.c,v
retrieving revision 1.4
diff -u -p -r1.4 sstfb.c
--- sstfb.c 4 Aug 2002 22:59:15 -0000 1.4
+++ sstfb.c 14 Sep 2002 23:58:43 -0000
@@ -107,6 +107,7 @@
#include <asm/io.h>
#include <asm/ioctl.h>
+#include <asm/uaccess.h>
#include <video/fbcon.h>
#include <video/fbcon-cfb16.h>
@@ -332,7 +333,7 @@ static void sst_dbg_print_var(struct fb_
#if (SST_DEBUG_REG > 0)
static void sst_dbg_print_read_reg (u32 reg, u32 val) {
- char * regname =NULL;
+ char * regname = NULL;
switch (reg) {
case FBIINIT0: regname="FbiInit0"; break;
case FBIINIT1: regname="FbiInit1"; break;
@@ -366,8 +367,8 @@ static void sst_dbg_print_write_reg (u32
r_dprintk(" sst_write(%s, %#x)\n", regname, val);
}
#else /* (SST_DEBUG_REG > 0) */
-# define sst_dbg_print_read_reg(reg, val) do {}while(0)
-# define sst_dbg_print_write_reg(reg, val) do {}while(0)
+# define sst_dbg_print_read_reg(reg, val) do {} while(0)
+# define sst_dbg_print_write_reg(reg, val) do {} while(0)
#endif /* (SST_DEBUG_REG > 0) */
/* register access */
@@ -530,20 +531,15 @@ static int sstfb_setcolreg(u_int regno,
break;
#endif
#ifdef EN_24_32_BPP
-#ifdef FBCON_HAS_CFB24
+#if defined(FBCON_HAS_CFB24) || defined(FBCON_HAS_CFB32)
case 24:
- sst_info->fbcon_cmap.cfb32[regno]=col;
- break;
-#endif
-#ifdef FBCON_HAS_CFB32
case 32:
sst_info->fbcon_cmap.cfb32[regno]=col;
break;
#endif
#endif
default:
- eprintk("bug line %d: bad depth '%u'\n",__LINE__,
- disp->var.bits_per_pixel);
+ BUG();
break;
}
f_dddprintk("bpp: %d . encoded color: %#x\n",
@@ -735,6 +731,7 @@ static int sstfb_encode_var (struct fb_v
#ifdef EN_24_32_BPP
case 24: /* RGB 888 LfbMode 4 */
case 32: /* ARGB 8888 LfbMode 5 */
+ /* in 24bpp we fake a 32 bpp mode */
var->red.length = 8;
var->green.length = 8;
var->blue.length = 8;
@@ -743,11 +740,11 @@ static int sstfb_encode_var (struct fb_v
var->red.offset = 16;
var->green.offset = 8;
var->blue.offset = 0;
- var->transp.offset = 0; /* in 24bpp we fake a 32 bpp mode */
+ var->transp.offset = 0;
break;
#endif
default:
- eprintk ("bug line %d: bad depth '%u'\n", __LINE__, par->bpp);
+ eprintk("bug line %d: bad depth '%u'\n", __LINE__, par->bpp);
break;
}
return 0;
@@ -775,11 +772,15 @@ static int sstfb_get_fix(struct fb_fix_s
#define sst_info ((struct sstfb_info *) info)
struct fb_var_screeninfo *var;
+ struct fb_var_screeninfo var2;
f_dprintk("sstfb_get_fix(con: %d)\n",con);
- if (con == -1)
- sstfb_encode_var(var, &sst_info->current_par, sst_info);
- else
+ memset(fix, 0, sizeof(struct fb_fix_screeninfo));
+
+ if (con == -1) {
+ sstfb_encode_var(&var2, &sst_info->current_par, sst_info);
+ var = &var2;
+ } else
var = &fb_display[con].var;
strcpy(fix->id, sst_info->info.modename);
@@ -789,6 +790,7 @@ static int sstfb_get_fix(struct fb_fix_s
fix->type = FB_TYPE_PACKED_PIXELS;
fix->visual = FB_VISUAL_TRUECOLOR;
+ fix->accel = FB_ACCEL_NONE;
/*
* According to the specs, the linelength must be of 1024 *pixels*.
* and the 24bpp mode is in fact a 32 bpp mode.
@@ -966,42 +968,47 @@ static int sstfb_ioctl(struct inode *ino
struct fb_info *info)
{
#define sst_info ((struct sstfb_info *) info)
-#if (SST_DEBUG_IOCTL >0)
int i;
u_long p;
- u32 tmp;
+ u32 tmp, val;
u32 fbiinit0;
struct pci_dev * sst_dev = sst_info->dev;
-#endif
f_dprintk("sstfb_ioctl(%x)\n", cmd);
-#if (SST_DEBUG_IOCTL >0)
+
switch (cmd) {
-# if (SST_DEBUG_VAR >0)
-/* tmp ioctl : dumps fb_display[0-5] */
+
+#if (SST_DEBUG_VAR >0)
+ /* tmp ioctl : dumps fb_display[0-5] */
case _IO('F', 0xdb): /* 0x46db */
f_dprintk("dumping fb_display[0-5].var\n");
for (i = 0 ; i< 6 ; i++) {
print_var(&fb_display[i].var, "var(%d)", i);
}
return 0;
-# endif /* (SST_DEBUG_VAR >0) */
-/* fills the lfb up to *(u32*)arg */
+#endif /* (SST_DEBUG_VAR >0) */
+
+ /* fills the lfb up to given count of pixels */
case _IOW('F', 0xdc, u32): /* 0x46dc */
- if (*(u32*)arg > 0x400000 )
- *(u32*) arg = 0x400000;
- f_dprintk("filling %#x \n", *(u32*)arg);
- for (p = 0 ; p < *(u32*)arg; p+=2)
+ if (copy_from_user(&val, (void *) arg, sizeof(val)))
+ return -EFAULT;
+ if (val > 0x400000 )
+ val = 0x400000;
+ f_dprintk("filling %#x \n", val);
+ for (p = 0 ; p < val; p+=2)
writew( p >> 6 , sst_info->video.vbase + p);
return 0;
-/* change VGA pass_through */
+
+ /* enable/disable VGA pass_through */
case _IOW('F', 0xdd, u32): /* 0x46dd */
+ if (copy_from_user(&val, (void *) arg, sizeof(val)))
+ return -EFAULT;
f_dprintk("switch VGA pass-through\n");
pci_read_config_dword(sst_dev, PCI_INIT_ENABLE, &tmp);
pci_write_config_dword(sst_dev, PCI_INIT_ENABLE,
tmp | PCI_EN_INIT_WR );
fbiinit0 = sst_read (FBIINIT0);
- if (* (u32*)arg) {
+ if (val) {
sst_write(FBIINIT0, fbiinit0 & ~EN_VGA_PASSTHROUGH);
iprintk ( "Disabling VGA pass-through\n");
} else {
@@ -1010,28 +1017,29 @@ static int sstfb_ioctl(struct inode *ino
}
pci_write_config_dword(sst_dev, PCI_INIT_ENABLE, tmp);
return 0;
+
+ /* display test pattern */
case _IO('F', 0xde): /* 0x46de */
f_dprintk("test color display\n");
f_ddprintk("currcon: %d, bpp %d\n", sst_info->currcon,
sst_info->current_par.bpp);
memset_io(sst_info->video.vbase, 0, sst_info->video.len);
- switch (sst_info->current_par.bpp) {
+ switch (sst_info->current_par.bpp) {
case 16:
sstfb_test16(sst_info);
break;
-# ifdef EN_24_32_BPP
+#ifdef EN_24_32_BPP
case 24:
case 32:
sstfb_test32(sst_info);
break;
-# endif
+#endif
default:
- dprintk("bug line %d: bad depth '%u'\n", __LINE__,
- sst_info->current_par.bpp);
- }
+ return -EFAULT;
+ }
return 0;
}
-#endif /* (SST_DEBUG_IOCTL >0) */
+
return -EINVAL;
#undef sst_info
}
@@ -1494,7 +1502,7 @@ static int sstfb_set_par(const struct ss
pci_write_config_dword(sst_dev, PCI_INIT_ENABLE, PCI_EN_FIFO_WR);
/* set lfbmode : set mode + front buffer for reads/writes
- + disable pipeline + disable byte swapping */
+ + disable pipeline */
switch(par->bpp) {
case 16:
lfbmode = LFB_565;
@@ -1508,12 +1516,16 @@ static int sstfb_set_par(const struct ss
break;
#endif
default:
- dprintk("bug line %d: bad depth '%u'\n", __LINE__,
- par->bpp );
+ BUG();
return 0;
- break;
}
+#if defined(__BIG_ENDIAN)
+ /* enable byte-swizzle functionality in hardware */
+ lfbmode |= ( LFB_WORD_SWIZZLE_WR | LFB_BYTE_SWIZZLE_WR |
+ LFB_WORD_SWIZZLE_RD | LFB_BYTE_SWIZZLE_RD );
+#endif
+
if (clipping) {
sst_write(LFBMODE, lfbmode | EN_PXL_PIPELINE);
/*
@@ -1521,7 +1533,7 @@ static int sstfb_set_par(const struct ss
* writes to offscreen areas of the framebuffer are performed,
* the "behaviour is undefined" (_very_ undefined) - Urs
*/
- /* btw, it requires enabling pixel pipeline in LFBMODE .
+ /* btw, it requires enabling pixel pipeline in LFBMODE.
off screen read/writes will just wrap and read/print pixels
on screen. Ugly but not that dangerous */
@@ -1536,7 +1548,7 @@ static int sstfb_set_par(const struct ss
sst_write(LFBMODE, lfbmode );
}
- sst_info->current_par = *par ;
+ sst_info->current_par = *par;
return 1;
}
@@ -1571,8 +1583,7 @@ static void sst_set_vidmod_att_ti(struct
break;
#endif
default:
- dprintk("bug line %d: bad depth '%u'\n", __LINE__, bpp);
- break;
+ BUG();
}
}
@@ -1590,8 +1601,7 @@ static void sst_set_vidmod_ics(struct ss
break;
#endif
default:
- dprintk("bug line %d: bad depth '%u'\n", __LINE__, bpp);
- break;
+ BUG();
}
}
@@ -1987,34 +1997,34 @@ static void sstfb_test16(struct sstfb_in
u_long fbbase_virt = sst_info->video.vbase;
f_dprintk("sstfb_test16\n");
- /* rect blanc 20x100+200+0 */
+ /* white rectangle 20x100+200+0 */
for (i=0 ; i< 100; i++) {
p = fbbase_virt + 2048 *i+400;
- for (j=0 ; j < 10 ; j++) {
- writel( 0xffffffff, p);
+ for (j=0; j < 10; j++) {
+ writel(0xffffffff, p);
p+=4;
}
}
- /* rect bleu 180x200+0+0 */
+ /* blue rectangle 180x200+0+0 */
for (i=0 ; i< 200; i++) {
p = fbbase_virt + 2048 *i;
- for (j=0 ; j < 90 ; j++) {
- writel(0x001f001f,p);
+ for (j=0; j < 90; j++) {
+ writel(0x001f001f, p);
p+=4;
}
}
- /* carre vert 40x40+100+0 */
+ /* green rectangle 40x40+100+0 */
for (i=0 ; i< 40 ; i++) {
p = fbbase_virt + 2048 *i + 200;
- for (j=0; j <20;j++) {
+ for (j=0; j <20; j++) {
writel(0x07e007e0, p);
p+=4;
}
}
- /*carre rouge 40x40+100+40 */
+ /* red rectangle 40x40+100+40 */
for (i=0; i<40; i++) {
p = fbbase_virt + 2048 * (i+40) + 200;
- for (j=0; j <20;j++) {
+ for (j=0; j <20; j++) {
writel( 0xf800f800, p);
p+=4;
}
@@ -2034,22 +2044,22 @@ static void sstfb_test32(struct sstfb_in
for (i=0 ; i< 100; i++) {
p = fbbase_virt + 4096*i + 800;
for (j=0 ; j < 20 ; j++) {
- writel( 0x00ffffff, p);
+ writel(0x00ffffff, p);
p+=4;
}
}
/* rect bleu 180x200+0+0 */
for (i=0 ; i< 200; i++) {
p = fbbase_virt + 4096 * i;
- for (j=0 ; j < 180 ; j++) {
- writel(0x000000ff,p);
+ for (j=0 ; j < 180; j++) {
+ writel(0x000000ff, p);
p+=4;
}
}
/* carre vert 40x40+100+0 */
for (i=0 ; i< 40 ; i++) {
p = fbbase_virt + 4096 *i + 400;
- for (j=0; j <40;j++) {
+ for (j=0; j <40; j++) {
writel(0x0000ff00, p);
p+=4;
}
@@ -2057,8 +2067,8 @@ static void sstfb_test32(struct sstfb_in
/*carre rouge 40x40+100+10 */
for (i=0; i<40; i++) {
p = fbbase_virt + 4096 * (i+40) + 400;
- for (j=0; j <40;j++) {
- writel( 0x00ff0000, p);
+ for (j=0; j <40; j++) {
+ writel(0x00ff0000, p);
p+=4;
}
}
Index: sstfb.h
===================================================================
RCS file: /var/cvs/linux/drivers/video/sstfb.h,v
retrieving revision 1.3
diff -u -p -r1.3 sstfb.h
--- sstfb.h 4 Aug 2002 22:59:15 -0000 1.3
+++ sstfb.h 14 Sep 2002 23:58:44 -0000
@@ -114,7 +114,11 @@
# define RD_BUFF_FRONT 0 /* read buff select (front) */
# define RD_BUFF_BACK (1 << 6) /* back */
# define EN_PXL_PIPELINE BIT(8) /* pixel pipeline (clip..)*/
+# define LFB_WORD_SWIZZLE_WR BIT(11) /* enable write-wordswap (big-endian) */
+# define LFB_BYTE_SWIZZLE_WR BIT(12) /* enable write-byteswap (big-endian) */
# define LFB_INVERT_Y BIT(13) /* invert Y origin (LFB) */
+# define LFB_WORD_SWIZZLE_RD BIT(15) /* enable read-wordswap (big-endian) */
+# define LFB_BYTE_SWIZZLE_RD BIT(16) /* enable read-byteswap (big-endian) */
#define CLIP_LEFT_RIGHT 0x0118
#define CLIP_LOWY_HIGHY 0x011c
#define NOPCMD 0x0120
--Boundary-00=_K/8g9cdhjiEuAkF--
From bdhilton@charter.net Sun Sep 15 05:28:14 2002
From: bdhilton@charter.net (B. Douglas Hilton)
Date: Sun, 15 Sep 2002 00:28:14 -0400
Subject: [parisc-linux] Re: [PATCH] Voodoo framebuffer on PARISC
References: <200209150209.46701.deller@gmx.de>
Message-ID: <3D840C5E.2080405@charter.net>
Fantastic! I was tinkering with this but I stalled out. I had
to cart my C200 in to work to use as a prototype server machine
for a proof of concept on a new project, but I will be sure to
give it a whirl as it still has the V2 inside it.
This might really help the project as now all the FX guys
have an inexpensive option for graphics!
When building the kernel should I disable "console on STI fb"
option then? Did you add a "console on sstfb" option to config?
Can't wait to try it out!
Cheers!
- Doug
Helge Deller wrote:
> Hi,
>
> there has been some discussions on this lists a few weeks back
> about getting the Voodoo framebuffer driver working on HPPA.
> The attached patch allows me to use my Voodoo 2 with the sstfb
> framebuffer driver in 16bpp in 640x480, 800x600 and 1024x768
> resolutions on console and under X.
>
> Greetings,
> Helge
>
> NB: This patch is already integrated into the 2.4.19-pa18 kernel and
> I'll continue to do some more code-cleanups before trying to get it
> into the official kernel.
>
>
> ------------------------------------------------------------------------
>
> Index: sstfb.c
> ===================================================================
> RCS file: /var/cvs/linux/drivers/video/sstfb.c,v
> retrieving revision 1.4
> diff -u -p -r1.4 sstfb.c
> --- sstfb.c 4 Aug 2002 22:59:15 -0000 1.4
> +++ sstfb.c 14 Sep 2002 23:58:43 -0000
> @@ -107,6 +107,7 @@
>
> #include <asm/io.h>
> #include <asm/ioctl.h>
> +#include <asm/uaccess.h>
>
> #include <video/fbcon.h>
> #include <video/fbcon-cfb16.h>
> @@ -332,7 +333,7 @@ static void sst_dbg_print_var(struct fb_
>
> #if (SST_DEBUG_REG > 0)
> static void sst_dbg_print_read_reg (u32 reg, u32 val) {
> - char * regname =NULL;
> + char * regname = NULL;
> switch (reg) {
> case FBIINIT0: regname="FbiInit0"; break;
> case FBIINIT1: regname="FbiInit1"; break;
> @@ -366,8 +367,8 @@ static void sst_dbg_print_write_reg (u32
> r_dprintk(" sst_write(%s, %#x)\n", regname, val);
> }
> #else /* (SST_DEBUG_REG > 0) */
> -# define sst_dbg_print_read_reg(reg, val) do {}while(0)
> -# define sst_dbg_print_write_reg(reg, val) do {}while(0)
> +# define sst_dbg_print_read_reg(reg, val) do {} while(0)
> +# define sst_dbg_print_write_reg(reg, val) do {} while(0)
> #endif /* (SST_DEBUG_REG > 0) */
>
> /* register access */
> @@ -530,20 +531,15 @@ static int sstfb_setcolreg(u_int regno,
> break;
> #endif
> #ifdef EN_24_32_BPP
> -#ifdef FBCON_HAS_CFB24
> +#if defined(FBCON_HAS_CFB24) || defined(FBCON_HAS_CFB32)
> case 24:
> - sst_info->fbcon_cmap.cfb32[regno]=col;
> - break;
> -#endif
> -#ifdef FBCON_HAS_CFB32
> case 32:
> sst_info->fbcon_cmap.cfb32[regno]=col;
> break;
> #endif
> #endif
> default:
> - eprintk("bug line %d: bad depth '%u'\n",__LINE__,
> - disp->var.bits_per_pixel);
> + BUG();
> break;
> }
> f_dddprintk("bpp: %d . encoded color: %#x\n",
> @@ -735,6 +731,7 @@ static int sstfb_encode_var (struct fb_v
> #ifdef EN_24_32_BPP
> case 24: /* RGB 888 LfbMode 4 */
> case 32: /* ARGB 8888 LfbMode 5 */
> + /* in 24bpp we fake a 32 bpp mode */
> var->red.length = 8;
> var->green.length = 8;
> var->blue.length = 8;
> @@ -743,11 +740,11 @@ static int sstfb_encode_var (struct fb_v
> var->red.offset = 16;
> var->green.offset = 8;
> var->blue.offset = 0;
> - var->transp.offset = 0; /* in 24bpp we fake a 32 bpp mode */
> + var->transp.offset = 0;
> break;
> #endif
> default:
> - eprintk ("bug line %d: bad depth '%u'\n", __LINE__, par->bpp);
> + eprintk("bug line %d: bad depth '%u'\n", __LINE__, par->bpp);
> break;
> }
> return 0;
> @@ -775,11 +772,15 @@ static int sstfb_get_fix(struct fb_fix_s
> #define sst_info ((struct sstfb_info *) info)
>
> struct fb_var_screeninfo *var;
> + struct fb_var_screeninfo var2;
>
> f_dprintk("sstfb_get_fix(con: %d)\n",con);
> - if (con == -1)
> - sstfb_encode_var(var, &sst_info->current_par, sst_info);
> - else
> + memset(fix, 0, sizeof(struct fb_fix_screeninfo));
> +
> + if (con == -1) {
> + sstfb_encode_var(&var2, &sst_info->current_par, sst_info);
> + var = &var2;
> + } else
> var = &fb_display[con].var;
>
> strcpy(fix->id, sst_info->info.modename);
> @@ -789,6 +790,7 @@ static int sstfb_get_fix(struct fb_fix_s
>
> fix->type = FB_TYPE_PACKED_PIXELS;
> fix->visual = FB_VISUAL_TRUECOLOR;
> + fix->accel = FB_ACCEL_NONE;
> /*
> * According to the specs, the linelength must be of 1024 *pixels*.
> * and the 24bpp mode is in fact a 32 bpp mode.
> @@ -966,42 +968,47 @@ static int sstfb_ioctl(struct inode *ino
> struct fb_info *info)
> {
> #define sst_info ((struct sstfb_info *) info)
> -#if (SST_DEBUG_IOCTL >0)
> int i;
> u_long p;
> - u32 tmp;
> + u32 tmp, val;
> u32 fbiinit0;
> struct pci_dev * sst_dev = sst_info->dev;
> -#endif
>
> f_dprintk("sstfb_ioctl(%x)\n", cmd);
> -#if (SST_DEBUG_IOCTL >0)
> +
> switch (cmd) {
> -# if (SST_DEBUG_VAR >0)
> -/* tmp ioctl : dumps fb_display[0-5] */
> +
> +#if (SST_DEBUG_VAR >0)
> + /* tmp ioctl : dumps fb_display[0-5] */
> case _IO('F', 0xdb): /* 0x46db */
> f_dprintk("dumping fb_display[0-5].var\n");
> for (i = 0 ; i< 6 ; i++) {
> print_var(&fb_display[i].var, "var(%d)", i);
> }
> return 0;
> -# endif /* (SST_DEBUG_VAR >0) */
> -/* fills the lfb up to *(u32*)arg */
> +#endif /* (SST_DEBUG_VAR >0) */
> +
> + /* fills the lfb up to given count of pixels */
> case _IOW('F', 0xdc, u32): /* 0x46dc */
> - if (*(u32*)arg > 0x400000 )
> - *(u32*) arg = 0x400000;
> - f_dprintk("filling %#x \n", *(u32*)arg);
> - for (p = 0 ; p < *(u32*)arg; p+=2)
> + if (copy_from_user(&val, (void *) arg, sizeof(val)))
> + return -EFAULT;
> + if (val > 0x400000 )
> + val = 0x400000;
> + f_dprintk("filling %#x \n", val);
> + for (p = 0 ; p < val; p+=2)
> writew( p >> 6 , sst_info->video.vbase + p);
> return 0;
> -/* change VGA pass_through */
> +
> + /* enable/disable VGA pass_through */
> case _IOW('F', 0xdd, u32): /* 0x46dd */
> + if (copy_from_user(&val, (void *) arg, sizeof(val)))
> + return -EFAULT;
> f_dprintk("switch VGA pass-through\n");
> pci_read_config_dword(sst_dev, PCI_INIT_ENABLE, &tmp);
> pci_write_config_dword(sst_dev, PCI_INIT_ENABLE,
> tmp | PCI_EN_INIT_WR );
> fbiinit0 = sst_read (FBIINIT0);
> - if (* (u32*)arg) {
> + if (val) {
> sst_write(FBIINIT0, fbiinit0 & ~EN_VGA_PASSTHROUGH);
> iprintk ( "Disabling VGA pass-through\n");
> } else {
> @@ -1010,28 +1017,29 @@ static int sstfb_ioctl(struct inode *ino
> }
> pci_write_config_dword(sst_dev, PCI_INIT_ENABLE, tmp);
> return 0;
> +
> + /* display test pattern */
> case _IO('F', 0xde): /* 0x46de */
> f_dprintk("test color display\n");
> f_ddprintk("currcon: %d, bpp %d\n", sst_info->currcon,
> sst_info->current_par.bpp);
> memset_io(sst_info->video.vbase, 0, sst_info->video.len);
> - switch (sst_info->current_par.bpp) {
> + switch (sst_info->current_par.bpp) {
> case 16:
> sstfb_test16(sst_info);
> break;
> -# ifdef EN_24_32_BPP
> +#ifdef EN_24_32_BPP
> case 24:
> case 32:
> sstfb_test32(sst_info);
> break;
> -# endif
> +#endif
> default:
> - dprintk("bug line %d: bad depth '%u'\n", __LINE__,
> - sst_info->current_par.bpp);
> - }
> + return -EFAULT;
> + }
> return 0;
> }
> -#endif /* (SST_DEBUG_IOCTL >0) */
> +
> return -EINVAL;
> #undef sst_info
> }
> @@ -1494,7 +1502,7 @@ static int sstfb_set_par(const struct ss
> pci_write_config_dword(sst_dev, PCI_INIT_ENABLE, PCI_EN_FIFO_WR);
>
> /* set lfbmode : set mode + front buffer for reads/writes
> - + disable pipeline + disable byte swapping */
> + + disable pipeline */
> switch(par->bpp) {
> case 16:
> lfbmode = LFB_565;
> @@ -1508,12 +1516,16 @@ static int sstfb_set_par(const struct ss
> break;
> #endif
> default:
> - dprintk("bug line %d: bad depth '%u'\n", __LINE__,
> - par->bpp );
> + BUG();
> return 0;
> - break;
> }
>
> +#if defined(__BIG_ENDIAN)
> + /* enable byte-swizzle functionality in hardware */
> + lfbmode |= ( LFB_WORD_SWIZZLE_WR | LFB_BYTE_SWIZZLE_WR |
> + LFB_WORD_SWIZZLE_RD | LFB_BYTE_SWIZZLE_RD );
> +#endif
> +
> if (clipping) {
> sst_write(LFBMODE, lfbmode | EN_PXL_PIPELINE);
> /*
> @@ -1521,7 +1533,7 @@ static int sstfb_set_par(const struct ss
> * writes to offscreen areas of the framebuffer are performed,
> * the "behaviour is undefined" (_very_ undefined) - Urs
> */
> - /* btw, it requires enabling pixel pipeline in LFBMODE .
> + /* btw, it requires enabling pixel pipeline in LFBMODE.
> off screen read/writes will just wrap and read/print pixels
> on screen. Ugly but not that dangerous */
>
> @@ -1536,7 +1548,7 @@ static int sstfb_set_par(const struct ss
> sst_write(LFBMODE, lfbmode );
> }
>
> - sst_info->current_par = *par ;
> + sst_info->current_par = *par;
> return 1;
> }
>
> @@ -1571,8 +1583,7 @@ static void sst_set_vidmod_att_ti(struct
> break;
> #endif
> default:
> - dprintk("bug line %d: bad depth '%u'\n", __LINE__, bpp);
> - break;
> + BUG();
> }
> }
>
> @@ -1590,8 +1601,7 @@ static void sst_set_vidmod_ics(struct ss
> break;
> #endif
> default:
> - dprintk("bug line %d: bad depth '%u'\n", __LINE__, bpp);
> - break;
> + BUG();
> }
> }
>
> @@ -1987,34 +1997,34 @@ static void sstfb_test16(struct sstfb_in
> u_long fbbase_virt = sst_info->video.vbase;
>
> f_dprintk("sstfb_test16\n");
> - /* rect blanc 20x100+200+0 */
> + /* white rectangle 20x100+200+0 */
> for (i=0 ; i< 100; i++) {
> p = fbbase_virt + 2048 *i+400;
> - for (j=0 ; j < 10 ; j++) {
> - writel( 0xffffffff, p);
> + for (j=0; j < 10; j++) {
> + writel(0xffffffff, p);
> p+=4;
> }
> }
> - /* rect bleu 180x200+0+0 */
> + /* blue rectangle 180x200+0+0 */
> for (i=0 ; i< 200; i++) {
> p = fbbase_virt + 2048 *i;
> - for (j=0 ; j < 90 ; j++) {
> - writel(0x001f001f,p);
> + for (j=0; j < 90; j++) {
> + writel(0x001f001f, p);
> p+=4;
> }
> }
> - /* carre vert 40x40+100+0 */
> + /* green rectangle 40x40+100+0 */
> for (i=0 ; i< 40 ; i++) {
> p = fbbase_virt + 2048 *i + 200;
> - for (j=0; j <20;j++) {
> + for (j=0; j <20; j++) {
> writel(0x07e007e0, p);
> p+=4;
> }
> }
> - /*carre rouge 40x40+100+40 */
> + /* red rectangle 40x40+100+40 */
> for (i=0; i<40; i++) {
> p = fbbase_virt + 2048 * (i+40) + 200;
> - for (j=0; j <20;j++) {
> + for (j=0; j <20; j++) {
> writel( 0xf800f800, p);
> p+=4;
> }
> @@ -2034,22 +2044,22 @@ static void sstfb_test32(struct sstfb_in
> for (i=0 ; i< 100; i++) {
> p = fbbase_virt + 4096*i + 800;
> for (j=0 ; j < 20 ; j++) {
> - writel( 0x00ffffff, p);
> + writel(0x00ffffff, p);
> p+=4;
> }
> }
> /* rect bleu 180x200+0+0 */
> for (i=0 ; i< 200; i++) {
> p = fbbase_virt + 4096 * i;
> - for (j=0 ; j < 180 ; j++) {
> - writel(0x000000ff,p);
> + for (j=0 ; j < 180; j++) {
> + writel(0x000000ff, p);
> p+=4;
> }
> }
> /* carre vert 40x40+100+0 */
> for (i=0 ; i< 40 ; i++) {
> p = fbbase_virt + 4096 *i + 400;
> - for (j=0; j <40;j++) {
> + for (j=0; j <40; j++) {
> writel(0x0000ff00, p);
> p+=4;
> }
> @@ -2057,8 +2067,8 @@ static void sstfb_test32(struct sstfb_in
> /*carre rouge 40x40+100+10 */
> for (i=0; i<40; i++) {
> p = fbbase_virt + 4096 * (i+40) + 400;
> - for (j=0; j <40;j++) {
> - writel( 0x00ff0000, p);
> + for (j=0; j <40; j++) {
> + writel(0x00ff0000, p);
> p+=4;
> }
> }
> Index: sstfb.h
> ===================================================================
> RCS file: /var/cvs/linux/drivers/video/sstfb.h,v
> retrieving revision 1.3
> diff -u -p -r1.3 sstfb.h
> --- sstfb.h 4 Aug 2002 22:59:15 -0000 1.3
> +++ sstfb.h 14 Sep 2002 23:58:44 -0000
> @@ -114,7 +114,11 @@
> # define RD_BUFF_FRONT 0 /* read buff select (front) */
> # define RD_BUFF_BACK (1 << 6) /* back */
> # define EN_PXL_PIPELINE BIT(8) /* pixel pipeline (clip..)*/
> +# define LFB_WORD_SWIZZLE_WR BIT(11) /* enable write-wordswap (big-endian) */
> +# define LFB_BYTE_SWIZZLE_WR BIT(12) /* enable write-byteswap (big-endian) */
> # define LFB_INVERT_Y BIT(13) /* invert Y origin (LFB) */
> +# define LFB_WORD_SWIZZLE_RD BIT(15) /* enable read-wordswap (big-endian) */
> +# define LFB_BYTE_SWIZZLE_RD BIT(16) /* enable read-byteswap (big-endian) */
> #define CLIP_LEFT_RIGHT 0x0118
> #define CLIP_LOWY_HIGHY 0x011c
> #define NOPCMD 0x0120
From rhirst@linuxcare.com Sun Sep 15 08:17:16 2002
From: rhirst@linuxcare.com (Richard Hirst)
Date: Sun, 15 Sep 2002 08:17:16 +0100
Subject: [parisc-linux] Making SYM2 default SYM-SCSI driver instead of SYM1
In-Reply-To: <20020913190929.8F8084829@dsl2.external.hp.com>
References: <3D8212E7.6000609@esiee.fr> <20020913190929.8F8084829@dsl2.external.hp.com>
Message-ID: <20020915071716.GD20720@sleepie.demon.co.uk>
On Fri, Sep 13, 2002 at 01:09:29PM -0600, Grant Grundler wrote:
> Thibaut VARENE wrote:
> > Now I'm asking you to know if anybody has an objection against making
> > SYM2 the default driver in debian-configs instead of old SYM1.
>
> I don't. All the boxes I care about have 53c8xx chips in them.
I don't think that is relevant. SYM1 and SYM2 both only drive 53c8xx
chips (and newer, 53c1010, etc). SYM1 didn't drive some of the nearly
53c810 chips (iirc), and you needed ncr53c8xx.c to drive those.
> A slightly safer approach is to make sym2 the default for PA2.0 systems
> and the old sym the default for PA1.1 systems. But GSC/HSC c720 cards
> don't fit that model since they go into systems with either sub-arch.
There was no linux driver for 53c720 before parisc. Now we drive 53c720
with a modified ncr53c8xx. So, something like my B180 with a bluefish
card uses:
CONFIG_SCSI_LASI700 (James driver) for 53c710 (cdrom)
CONFIG_SCSI_ZALON (modified ncr53c8xx) for 53c720 on blusfish
CONFIG_SCSI_SYM53C8XX (SYMV1) for 53c8?? main disk interface
So, in theory, chnaging to CONFIG_SCSI_SYM53C8XX_2 for all configs
shouldn't upset anyone. SYM1 and SYM2 both only drive PCI chips, so
that makes the change irrelevant to earlier boxes anyway.
Cheers,
Richard
From deller@gmx.de Sun Sep 15 09:31:16 2002
From: deller@gmx.de (Helge Deller)
Date: Sun, 15 Sep 2002 10:31:16 +0200
Subject: [parisc-linux] Re: [PATCH] Voodoo framebuffer on PARISC
In-Reply-To: <3D840C5E.2080405@charter.net>
References: <200209150209.46701.deller@gmx.de> <3D840C5E.2080405@charter.net>
Message-ID: <200209151031.16912.deller@gmx.de>
Hi Douglas,
it's safe to enable both (stifb and sstfb), in which case one of
them is /dev/fb0 (presumably the sstfb) and the other /dev/fb1 (stifb).
If you hook them up to different monitors you can use both graphic
cards at the same time. If you connect them in chain, only the
sstfb will be visible.
Greetings,
Helge
On Sunday 15 September 2002 06:28, B. Douglas Hilton wrote:
> Fantastic! I was tinkering with this but I stalled out. I had
> to cart my C200 in to work to use as a prototype server machine
> for a proof of concept on a new project, but I will be sure to
> give it a whirl as it still has the V2 inside it.
>
> This might really help the project as now all the FX guys
> have an inexpensive option for graphics!
>
> When building the kernel should I disable "console on STI fb"
> option then? Did you add a "console on sstfb" option to config?
>
> Can't wait to try it out!
>
> Cheers!
> - Doug
>
> Helge Deller wrote:
> > Hi,
> >
> > there has been some discussions on this lists a few weeks back
> > about getting the Voodoo framebuffer driver working on HPPA.
> > The attached patch allows me to use my Voodoo 2 with the sstfb
> > framebuffer driver in 16bpp in 640x480, 800x600 and 1024x768
> > resolutions on console and under X.
> >
> > Greetings,
> > Helge
> >
> > NB: This patch is already integrated into the 2.4.19-pa18 kernel and
> > I'll continue to do some more code-cleanups before trying to get it
> > into the official kernel.
> >
> > ...patch removed...
From grundler@dsl2.external.hp.com Sun Sep 15 15:35:49 2002
From: grundler@dsl2.external.hp.com (Grant Grundler)
Date: Sun, 15 Sep 2002 08:35:49 -0600
Subject: [parisc-linux] Making SYM2 default SYM-SCSI driver instead of SYM1
In-Reply-To: Message from Richard Hirst <rhirst@linuxcare.com>
of "Sun, 15 Sep 2002 08:17:16 BST." <20020915071716.GD20720@sleepie.demon.co.uk>
References: <3D8212E7.6000609@esiee.fr> <20020913190929.8F8084829@dsl2.external.hp.com> <20020915071716.GD20720@sleepie.demon.co.uk>
Message-ID: <20020915143549.77723482A@dsl2.external.hp.com>
Richard Hirst wrote:
> I don't think that is relevant. SYM1 and SYM2 both only drive 53c8xx
> chips (and newer, 53c1010, etc). SYM1 didn't drive some of the nearly
> 53c810 chips (iirc), and you needed ncr53c8xx.c to drive those.
Ah ok. my bad. I thought sym1 drove 53c720 but that's wrong.
Someone might consider porting the PDC_INITIATOR support to ncr53c8xx.
Should be a cut/paste from sym1 or sym2 driver.
> So, in theory, chnaging to CONFIG_SCSI_SYM53C8XX_2 for all configs
> shouldn't upset anyone. SYM1 and SYM2 both only drive PCI chips, so
> that makes the change irrelevant to earlier boxes anyway.
OK - I've been using sym2 on both c3k and A500. I'm comfortable with it.
Sounds like I should use it on B180 as well.
Thanks for clarification richard!
grant
From grundler@dsl2.external.hp.com Sun Sep 15 16:36:13 2002
From: grundler@dsl2.external.hp.com (Grant Grundler)
Date: Sun, 15 Sep 2002 09:36:13 -0600 (MDT)
Subject: [parisc-linux] rp2470 hang in sym2 driver
Message-ID: <20020915153613.5AFBD4829@dsl2.external.hp.com>
Hi all,
I've revisited this "rp2470 hang" issue. This happens with sym2.
The same kernels boot on A500-44 but hang on A500-65 (650Mhz).
It smells like a deadlock.
I don't believe this is a result of interrupt distribution. I can't
say for sure since I've had the IRQ distr code in my tree for a while.
I don't think I've ever booted rp2470 with 2.4.19.
I will try sym1 driver *and* try disabling IRQ distribution
in the next couple of days.
I've reproduced the hang twice with 2.4.19-pa18.
Console output stops after first line of either "sym3:" output
or "sym4:" (ie only one line is printed for that interface.
TOC had the following:
CPU0 0x10143420 timer_bh+200
CPU0 0x102276fc sym53c8xx_timer+ec
CPU1 0x1010dd40 do_irq+100
CPU1 0x102275f0 sym53c8xx_intr+140
and
CPU0 GR02 0x10143420 timer_bh+200
CPU0 IOAQ 0x102276fc sym53c8xx_timer+ec
CPU1 GR02 0x102274f4 sym53c8xx_intr+44
CPU1 IOAQ 0x102275f0 sym53c8xx_intr+140
I hoped someone else has a chance to look at this too.
The rp2470 (gsyprf11) is externally accessible if a volunteer has time
to dig into this. Or let me know what I might try next.
thanks,
grant
From christoph.plattner@gmx.at Sun Sep 15 19:11:07 2002
From: christoph.plattner@gmx.at (Christoph Plattner)
Date: Sun, 15 Sep 2002 20:11:07 +0200
Subject: [parisc-linux] Re: SCSI/MUX driver on E55, NDA for sorce code
References: <3D825FDF.CD6E8CE2@gmx.at> <1031962399.930.17.camel@beavis>
<3D8281F4.F03A2007@gmx.at> <1031964117.1043.29.camel@beavis>
Message-ID: <3D84CD3B.88A9528B@gmx.at>
Yes, I would be interested in HP-UX source code access,
if there are no costs I have to pay. I would sign a NDA.
The status of SCSI driver you sent me:
The machine does not really access the hardware. Also
if I patch the data structures or the "dev->hpa" pointer,
the driver reacts the same strange way.
The status of MUX: It is not working to access to offset
0x80 for the lines. The machine dies. I think this problem
can be solved very easy, looking in the HP-UX driver code.
I will do some futher code instrumentation on the SPIFI
driver. Then I will reread the driver of you and NetBSD
to have an idea, which access does fail here. Or do we
have a wrong hardware access anyway ?
Good start of the next week
Christoph
Ryan Bradetich wrote:
>
> Thomas and Christoph,
>
> Here is the current diff I have (I told you it was ugly! :))
>
> I can not send you the HP-UX code. If you are interested
> in pursuing the NDA to get access to the drivers, I can approach
> Alan Meyer (LSO Lab manager). I am in IT, not the R&D lab so
> I do not have much insight in what they are doing :(
>
> Hope this diff helps, and together hopefully we can get this to
> work and committed!
>
> thanks,
>
> - Ryan
>
> On Fri, 2002-09-13 at 18:25, Christoph Plattner wrote:
> > Hello,
> >
> > if it is possible, send the code to me (perhpas I can
> > have a look @ week end.
> >
> > Is it possible to geht the HP-UX driver codes for those
> > to things ? MUX + SCSI ?
> >
> > I was offered to sign a NDA, but then nothing happens ...
> > It would be more easy for me to read such original HP-UX
> > code. Perhaps you see a possibility to send it also.
> >
> > Have a nice week end
> >
> > Christoph
> >
> >
> >
> > Ryan Bradetich wrote:
> > >
> > > On Fri, 2002-09-13 at 15:59, Christoph Plattner wrote:
> > > > Hallo Ryan !
> > > >
> > > > Congratulation, your MUX driver on port 0 is really
> > > > working on my machine !!
> > >
> > > Glad to hear that!
> > >
> > > > What do you miss to support the other lines ?
> > >
> > > I am not sure, I've never tried to hook up additional
> > > lines. I do have an 8-port MDP somewhere, I'll look
> > > for it here shortly, and see if I can hook it up.
> > >
> > > > Have you already knowledge of the data structure ?
> > >
> > > Just what I have added into the driver. If there is
> > > something that we are obviously missing, I can go back
> > > and reference the HP-UX mux driver and see what is
> > > missing.
> > >
> > > > Can I help you here in the code ?
> > >
> > > Please! :) I do not use multiple lines currently ...
> > > I only use the line 0, so any testing, optimizing, etc
> > > is greatly appreciated!
> > >
> > > > Another point: you mentioned the skeleton of the
> > > > SCSI SPIFI driver. Where can I find that ? I only
> > > > found a NetBSD code, which I will use as functional
> > > > template, but I do not know, if this would be enough.
> > > > Can you give me a hint in this point ?
> > >
> > > I have it on my local system. It is _very_ ugly at this
> > > point. I have got enough to query information from the
> > > spifi chip, register an interrupt, etc... but currently
> > > I can not get the spifi chip to actually generate an
> > > interrupt.
> > >
> > > I would be happy to send you a copy when I get back next
> > > monday (unless you catch my in the next hour or so), but
> > > I'm not ready to check it into CVS yeah until I get rid
> > > of the some ugly hardcoded hacks, global variables, etc.
> > > Right now the driver is really coded to gather info from
> > > the ESIEE E35 that I have been testing on. Once again,
> > > I do not have any docs on the chipset, I am using both
> > > the NetBSD and HP-UX drivers as reference. :(
> > >
> > > The driver should be easy to modify for your specific E55,
> > > but not sure if you are interested in that level of work,
> > > messyness now. I promise it will get much better :)
> > >
> > > Thanks,
> > >
> > > - Ryan
> > >
> > > > Christoph
> > > >
> > > >
> > > > --
> > > > -------------------------------------------------------
> > > > private: christoph.plattner@gmx.at
> > > > company: christoph.plattner@alcatel.at
> > > >
> >
> > --
> > -------------------------------------------------------
> > private: christoph.plattner@gmx.at
> > company: christoph.plattner@alcatel.at
> >
>
> ------------------------------------------------------------------------
> Name: spifi.patch
> spifi.patch Type: text/x-patch
> Encoding: quoted-printable
--
-------------------------------------------------------
private: christoph.plattner@gmx.at
company: christoph.plattner@alcatel.at
From willy@debian.org Sun Sep 15 19:25:00 2002
From: willy@debian.org (Matthew Wilcox)
Date: Sun, 15 Sep 2002 19:25:00 +0100
Subject: [parisc-linux] Re: SCSI/MUX driver on E55, NDA for sorce code
In-Reply-To: <3D84CD3B.88A9528B@gmx.at>; from christoph.plattner@gmx.at on Sun, Sep 15, 2002 at 08:11:07PM +0200
References: <3D825FDF.CD6E8CE2@gmx.at> <1031962399.930.17.camel@beavis> <3D8281F4.F03A2007@gmx.at> <1031964117.1043.29.camel@beavis> <3D84CD3B.88A9528B@gmx.at>
Message-ID: <20020915192500.D10583@parcelfarce.linux.theplanet.co.uk>
On Sun, Sep 15, 2002 at 08:11:07PM +0200, Christoph Plattner wrote:
> The status of MUX: It is not working to access to offset
> 0x80 for the lines. The machine dies. I think this problem
> can be solved very easy, looking in the HP-UX driver code.
Not so sure...
common/sio/mux2.c:
for (loop = 0; loop < ports; loop++, ttyp++) {
HW.hpa = MUX_DATA.hpa + 0x800 + (loop * 0x80);
HW.io_reg_ptr = (io_reg_type *)(HW.hpa + 0x30);
}
--
Revolutions do not require corporate support.
From tobias_subscriber@tgtools.com Sun Sep 15 23:13:11 2002
From: tobias_subscriber@tgtools.com (Tobias Giesen)
Date: Mon, 16 Sep 2002 00:13:11 +0200
Subject: [parisc-linux] [PATCH] Voodoo framebuffer on PARISC
In-Reply-To: <200209150209.46701.deller@gmx.de>
Message-ID: <001201c25d05$150e6600$0100a8c0@PLUTO>
Helge wrote:
> This patch is already integrated into the 2.4.19-pa18
> kernel ...
Where can I get pa18? The latest on ftp.parisc-linux.org seems to be
pa17.
Cheers,
Tobias
From christoph.plattner@gmx.at Mon Sep 16 00:25:35 2002
From: christoph.plattner@gmx.at (Christoph Plattner)
Date: Mon, 16 Sep 2002 01:25:35 +0200
Subject: [parisc-linux] Status SPIFI SCSI
Message-ID: <3D8516EF.7A7D8206@gmx.at>
Hallo Ryan,
here some comments on my non-successful work so far.
I did code reading and used debug instrumented code
to understand the structure behind the linux SCSI
handling.
Further I studied the NetBSD code.
One major point: We do not get any interrupts.
For my analysis I only had a look on the first
steps of SCSI initialization, so this was the
INQUERY command.
The spifi command routine is called correctly,
but it has a wrong logical implementation. As I
have seen on other (older) linux driver, the
xxx_command() has to block, after the command was
successful completed by interrupt. But the interrupt
never comes !! Even a "long" delay for simulating
blocking does not solve this problem.
>From base of the NetBSD code, I cannot follow your
code resetting the spifi subsystem. I think you have
this from HP-UX code. Especially the
__raw_writel(CMD_RESET, dev->hpa + IO_MODULE_COMMAND);
Is this a reset method via the IO PDC address space
common for all HP devices ? In the NetBSD the full
reset is done only via the `auxctrl' register, which
you use for releasing the reset state.
So we have a principal problem here, not having correct
access to the spifi subsystem. Except: the SCSI-ID is
read out correctly, I think, as ...
SCSI subsystem driver Revision: 1.00
DEBUG: 0xfff74c00
Device: Sahp Baat Kiuh SCSI
scsi0 : SPIFI SCSI: scsi_id: 7 IRQ: 34 type: SPIFI-3 (SE) parity
checking: enabled
... is reported !
Is everything around the interrupt subsystem setup correctly ?
The `cat /proc/interrupts' tells ...
bash# cat /proc/interrupts
CPU396195552
32: 124925 PARISC-CPU timer
33: 19767 PARISC-CPU lasi
34: 0 PARISC-CPU spifi
87: 19767 Lasi i82596
... which is no surprise ... !
Till soon,
Christoph P.
--
-------------------------------------------------------
private: christoph.plattner@gmx.at
company: christoph.plattner@alcatel.at
From christoph.plattner@gmx.at Mon Sep 16 00:37:59 2002
From: christoph.plattner@gmx.at (Christoph Plattner)
Date: Mon, 16 Sep 2002 01:37:59 +0200
Subject: [parisc-linux] Re: SCSI/MUX driver on E55, NDA for sorce code
References: <3D825FDF.CD6E8CE2@gmx.at> <1031962399.930.17.camel@beavis> <3D8281F4.F03A2007@gmx.at> <1031964117.1043.29.camel@beavis> <3D84CD3B.88A9528B@gmx.at> <20020915192500.D10583@parcelfarce.linux.theplanet.co.uk>
Message-ID: <3D8519D7.55D90667@gmx.at>
Thanks for that !
But I think, my Linux code dose the same !!!
info->iomem_base = (void *)(hpa + MUX_OFFSET +
(line * MUX_LINE_OFFSET));
This info->iomem_base is used by all accesses, the
registers of i/o are defined by Ryan as:
#define IO_COMMAND_REG_OFFSET 0x30
#define IO_STATUS_REG_OFFSET 0x34
#define IO_DATA_REG_OFFSET 0x3c
#define IO_DCOUNT_REG_OFFSET 0x40
#define IO_UCOUNT_REG_OFFSET 0x44
#define IO_FIFOS_REG_OFFSET 0x48
So the offset of 0x30 is inside those macros.
An example of an access:
data = __raw_readl((unsigned long)info->iomem_base
+ IO_DATA_REG_OFFSET);
... reading characters from the input buffers.
Any further idea ?
Ryan, you mentioned problems concerning missing locks, but
I cannot think about this. Those devices should be controlled
independent, am I wrong ?
I hope, we will solve this all (all means including SPIFI
SCSI driver too !).
Christoph
Matthew Wilcox wrote:
>
> On Sun, Sep 15, 2002 at 08:11:07PM +0200, Christoph Plattner wrote:
> > The status of MUX: It is not working to access to offset
> > 0x80 for the lines. The machine dies. I think this problem
> > can be solved very easy, looking in the HP-UX driver code.
>
> Not so sure...
>
> common/sio/mux2.c:
>
> for (loop = 0; loop < ports; loop++, ttyp++) {
> HW.hpa = MUX_DATA.hpa + 0x800 + (loop * 0x80);
> HW.io_reg_ptr = (io_reg_type *)(HW.hpa + 0x30);
> }
>
> --
> Revolutions do not require corporate support.
> _______________________________________________
> parisc-linux mailing list
> parisc-linux@lists.parisc-linux.org
> http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
--
-------------------------------------------------------
private: christoph.plattner@gmx.at
company: christoph.plattner@alcatel.at
From varenet@esiee.fr Mon Sep 16 01:18:54 2002
From: varenet@esiee.fr (Thibaut VARENE)
Date: Mon, 16 Sep 2002 02:18:54 +0200
Subject: [parisc-linux] [PATCH] Voodoo framebuffer on PARISC
In-Reply-To: <001201c25d05$150e6600$0100a8c0@PLUTO>
Message-ID: <E267A5BE-C909-11D6-A91F-0030656F07A2@esiee.fr>
Le lundi, 16 sep 2002, =E0 00:13 Europe/Paris, Tobias Giesen a =E9crit :
> Helge wrote:
>
>> This patch is already integrated into the 2.4.19-pa18
>> kernel ...
>
> Where can I get pa18? The latest on ftp.parisc-linux.org seems to be
> pa17.
I'm currently building pa18 lifimage/iso, they will be available soon.
Though I think there's no point for you in trying to find a precompiled=20=
kernel,
since IIRC precomp are built with default debian-configs, which do not=20=
enable support
for sstfb.
Therefore I think you'd better get the latest kernel source from=20
cvs.parisc-linux.org
and build it with your own options :)
Greetings,
Thibaut VARENE
PA/Linux ESIEE Team
http://pateam.esiee.fr/=
From tobias_subscriber@tgtools.com Mon Sep 16 01:17:54 2002
From: tobias_subscriber@tgtools.com (Tobias Giesen)
Date: Mon, 16 Sep 2002 02:17:54 +0200
Subject: [parisc-linux] Re: [PATCH] Voodoo framebuffer on PARISC
In-Reply-To: <200209151031.16912.deller@gmx.de>
Message-ID: <000001c25d16$80be8b30$0100a8c0@PLUTO>
Hello,
I think I need some more help with this. Here's what I did:
- grabbed fresh 2.4.19-pa17 sources
- applied sstfb.c and .h patch
- set kernel options to include sst1
- compiled & installed new kernel
The new kernel seems to try to activate a Voodoo console shortly after
the "If this is the last message you see ..." warning. However, my
monitor says the frequencies are out of range and switches itself off.
The main sti console is then dead also.
Any ideas? Maybe could I try a precompiled kernel with Voodoo support?
Thanks.
Best wishes,
Tobias Giesen
From jkinney@localnetsolutions.com Mon Sep 16 03:31:54 2002
From: jkinney@localnetsolutions.com (James P. Kinney III)
Date: 15 Sep 2002 22:31:54 -0400
Subject: [parisc-linux] Re: [PATCH] Voodoo framebuffer on PARISC
In-Reply-To: <000001c25d16$80be8b30$0100a8c0@PLUTO>
References: <000001c25d16$80be8b30$0100a8c0@PLUTO>
Message-ID: <1032143514.31738.289.camel@archimedes.localnetsolutions.com>
--=-Y7wnlyzpNsPLiwMOjziS
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable
As I don't have the Voodoo card, I didn't keep the patch, but, are there
settings in the sstfb patch that can be used to define the default
frequencies? The only other alternative will be to get a very high
frequency monitor that supports 1280x1024@72Hz. My HP A4033A monitor has
no problem with that. But my Digiview croaked on it on my SGI Octane. So
now I have to switch out between the two boxes (Octane and C160) with
the A4033A. I haven't tried my Panasonic E21. It supports 1600x1280@60
so it should handle it OK.
On Sun, 2002-09-15 at 20:17, Tobias Giesen wrote:
> Hello,
>=20
> I think I need some more help with this. Here's what I did:
>=20
> - grabbed fresh 2.4.19-pa17 sources
> - applied sstfb.c and .h patch
> - set kernel options to include sst1
> - compiled & installed new kernel
>=20
> The new kernel seems to try to activate a Voodoo console shortly after
> the "If this is the last message you see ..." warning. However, my
> monitor says the frequencies are out of range and switches itself off.
> The main sti console is then dead also.
>=20
> Any ideas? Maybe could I try a precompiled kernel with Voodoo support?
>=20
> Thanks.
>=20
> Best wishes,
> Tobias Giesen
>=20
>=20
>=20
> _______________________________________________
> parisc-linux mailing list
> parisc-linux@lists.parisc-linux.org
> http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
--=20
James P. Kinney III \Changing the mobile computing world/
President and CEO \ one Linux user /
Local Net Solutions,LLC \ at a time. /
770-493-8244 \.___________________________./
GPG ID: 829C6CA7 James P. Kinney III (M.S. Physics)
<jkinney@localnetsolutions.com>
Fingerprint =3D 3C9E 6366 54FC A3FE BA4D 0659 6190 ADC3 829C 6CA7=20
--=-Y7wnlyzpNsPLiwMOjziS
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQA9hUKZYZCtw4KcbKcRAkEDAJwNXVoGaQi99aHhFn9Wa7sACgWzUACeI9qK
FRX2osoV4k/uVbS8ZOImVXk=
=ctY6
-----END PGP SIGNATURE-----
--=-Y7wnlyzpNsPLiwMOjziS--
From grundler@dsl2.external.hp.com Mon Sep 16 05:30:04 2002
From: grundler@dsl2.external.hp.com (Grant Grundler)
Date: Sun, 15 Sep 2002 22:30:04 -0600
Subject: [parisc-linux] Re: ide controller
In-Reply-To: Message from Moritz Sinn <moritz@freesources.org>
of "15 Sep 2002 22:33:39 -0000." <87k7lm3mt8.fsf@appserv.sinnhq.de>
References: <87k7lm3mt8.fsf@appserv.sinnhq.de>
Message-ID: <20020916043004.B27754829@dsl2.external.hp.com>
Moritz Sinn wrote:
>
> hi,
>
> i've got an promise PDC20268 ide controller, which i would like to use
> in my hp c360 workstation. i'm using kernel 2.4.18 (couldn't compile
> 2.4.19 and 2.4.20-pre7).
> if i compile with "Generic PCI bus-master DMA support", the kernel
> crashes when i insmod the 'ide-mod' module. it doesn't print useable
> error messages, it just doesn't react anymore.
Are you using the "apt-get source kernel-image-2.4.18-hppa"
or from kernel.org?
If the latter, that won't work.
> when i compile without dma support, i can insmod the 'ide-mod' and
> 'ide-disk' module, but it crashes when i want to insmod the
> 'ide-probe-mod' module.
>
> would be great if someone could help me.
1) see cvs.parisc-linux.org to get the latest bits
(or ftp.parisc-linux.org/cvs/)
2) define the following to 1 in drivers/ide/pdc202xx.c:
#define PDC202XX_DEBUG_DRIVE_INFO 0
#define PDC202XX_DECODE_REGISTER_INFO 0
and rebuild the module with that.
3) post the console log and "ser pim" output at PDC prompt.
grant
From deller@gmx.de Mon Sep 16 07:29:35 2002
From: deller@gmx.de (Helge Deller)
Date: Mon, 16 Sep 2002 08:29:35 +0200
Subject: [parisc-linux] Re: [PATCH] Voodoo framebuffer on PARISC
In-Reply-To: <000001c25d16$80be8b30$0100a8c0@PLUTO>
References: <000001c25d16$80be8b30$0100a8c0@PLUTO>
Message-ID: <200209160829.35216.deller@gmx.de>
Hi Tobias,
you should use a standard PC mulitfrequency monitor, as most
HP monitors are fixed frequency and won't work.
Furthermore you might search in sstfb.c for:
/*
Default video mode .
0 800x600@60 took from glide
1 640x480@75 took from glide
2 1024x768@76 std fb.mode
3 640x480@60 glide default */
#define DEFAULT_MODE 1
and try to change the DEFAULT_MODE to 2 or 0.
Greetings,
Helge
On Monday 16 September 2002 02:17, Tobias Giesen wrote:
> Hello,
>
> I think I need some more help with this. Here's what I did:
>
> - grabbed fresh 2.4.19-pa17 sources
> - applied sstfb.c and .h patch
> - set kernel options to include sst1
> - compiled & installed new kernel
>
> The new kernel seems to try to activate a Voodoo console shortly after
> the "If this is the last message you see ..." warning. However, my
> monitor says the frequencies are out of range and switches itself off.
> The main sti console is then dead also.
>
> Any ideas? Maybe could I try a precompiled kernel with Voodoo support?
>
> Thanks.
>
> Best wishes,
> Tobias Giesen
From christoph.plattner@gmx.at Mon Sep 16 22:37:17 2002
From: christoph.plattner@gmx.at (Christoph Plattner)
Date: Mon, 16 Sep 2002 23:37:17 +0200
Subject: [parisc-linux] SPIFI hardware access
Message-ID: <3D864F0D.32223AC9@gmx.at>
Hello Ryan
,
I think we have a much more basic problem, I thought
up to now. I think all bus accesses to the device
are unsuccessfull.
Independent of the word position, I read back a
0x0000ff00. You see this as a counter value, and
even the regs->spstat deliveres 0x0000ff00 and via
the bit operations the ID=7 results, and I thought
at the beginning, this wa correctly read out .... !
What are doing we wrong in the bus access or device
access. The MUX port can be accessed, what's the
difference here ?
Christoph
--
-------------------------------------------------------
private: christoph.plattner@gmx.at
company: christoph.plattner@alcatel.at
From willy.schriemer@philips.com Mon Sep 16 23:30:06 2002
From: willy.schriemer@philips.com (willy.schriemer@philips.com)
Date: Tue, 17 Sep 2002 00:30:06 +0200
Subject: [parisc-linux] Willy Schriemer/NYM/SC/PHILIPS is out of the office.
Message-ID: <OF3A734998.705BC485-ONC1256C36.007B9B48-C1256C36.007B9B49@diamond.philips.com>
I will be out of the office starting 09/16/2002 and will not return until 09/23/2002.
Thank you for your message. I will reply to it when I return. For urgent messages please contact Jos de Jong at +31 24 353 2991.
From derekengelhaupt@rocketmail.com Mon Sep 16 23:32:09 2002
From: derekengelhaupt@rocketmail.com (Derek Engelhaupt)
Date: Mon, 16 Sep 2002 15:32:09 -0700 (PDT)
Subject: [parisc-linux] HP-PB
In-Reply-To: <3D864F0D.32223AC9@gmx.at>
Message-ID: <20020916223209.26797.qmail@web12501.mail.yahoo.com>
Hey all,
I know that there is a quest for information about the HP-PB interfaces
in order to get them functional in Linux. So I was curious about what
kind of information you guys needed and I'm offering to try and find
that information. Not sure why I feel like I can find the information
where others have failed, but I'd like to try so fire away...
derek
__________________________________________________
Do you Yahoo!?
Yahoo! News - Today's headlines
http://news.yahoo.com
From snaketails@optushome.com.au Tue Sep 17 00:00:42 2002
From: snaketails@optushome.com.au (Rod Smart)
Date: Mon, 16 Sep 2002 23:00:42 +0000
Subject: [parisc-linux] Serial Terminal on C-180 system
Message-ID: <3D86629A.F8CB5564@optushome.com.au>
Hello again.
Last time I was here I was asking about how to get the C-180 to use
Serial Terminal, I havn't been able to get it talking to the other Linux
or wincrash system, so I would like to transfer it back to Video mode
(turn off Serial Terminal.
How do I do this when I cannot see the screen ?
From christoph.plattner@gmx.at Tue Sep 17 00:09:45 2002
From: christoph.plattner@gmx.at (Christoph Plattner)
Date: Tue, 17 Sep 2002 01:09:45 +0200
Subject: [parisc-linux] New status MUX on E55
Message-ID: <3D8664B9.FFA6FD3A@gmx.at>
This is a multi-part message in MIME format.
--------------337BA726D358AC462F45C980
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Hello Ryan,
I added the handling of the multi ports. So for example the
poll routine walks to all 8 devices (if opened), the
handling of the refcount is now per line, etc....
I give you the patch to see my changes, ignore my debug
print outs, and ignore the fact, that the polling routine
is running on 1.5 seconds !
We already have the state, that the HP machine completely
dies. Even no interrupts are working, no `ping' is answered,
etc...
I had seen an interesting effect:
mux_drv_poll: 0
mux_drv_poll: done
mux_write: <hallo
>(5) to 0xfff788bc
68 61 6c 6c 6f
mux_write: before mux_flush_buffer()
mux_drv_poll: 0
mux_drv_poll: 1
mux_drv_poll: done
mux_write: <àHIJKLMNOPQRSTUVWXYZ>(1) to 0xfff788bc
e0
mux_write: before mux_flush_buffer()
A `echo hallo > /dev/ttyB1' has produces this log.
After the mux_write() called with the string, the mux_write
is called a second time sending a 'e0' ???????
The first mux_write() is not finished (as no
`mux_write: done' is displayed), the second blocks
the machine completely on the max_flush_buffer() call.
So the first writer block there, waiting in the endless
loop ! The second blocks up the whole machine ...
Further, NO OUTPUT were seen on the serial line of port
1 (not 0 !). Is there something, which is forgotten for
the initialization ? Perhaps something done for port 0
by the PDC code ?
Is this a common problem, as on the SPIFI, that there is
a general wrong access method to those devices ?
Bye
Christoph
--
-------------------------------------------------------
private: christoph.plattner@gmx.at
company: christoph.plattner@alcatel.at
--------------337BA726D358AC462F45C980
Content-Type: text/plain; charset=us-ascii;
name="mux.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="mux.patch"
Index: drivers/char/mux.c
===================================================================
RCS file: /var/cvs/linux/drivers/char/mux.c,v
retrieving revision 1.3
diff -u -r1.3 mux.c
--- drivers/char/mux.c 11 Sep 2002 07:05:56 -0000 1.3
+++ drivers/char/mux.c 16 Sep 2002 22:59:48 -0000
@@ -56,7 +56,7 @@
#define MUX_MIN_FREE_SIZE 32
#define MUX_FIFO_DRAIN_DELAY 1
-#define MUX_POLL_DELAY (30 * HZ / 1000)
+#define MUX_POLL_DELAY (1500 * HZ / 1000)
#define IO_COMMAND_REG_OFFSET 0x30
#define IO_STATUS_REG_OFFSET 0x34
@@ -69,12 +69,13 @@
#define MUX_STATUS(status) ((status & 0xF000) == 0x8000)
#define MUX_BREAK(status) ((status & 0xF000) == 0x2000)
-static int mux_drv_refcount; /* = 0 */
+#define NR_PORTS 8
+static int global_mux_drv_refcount; /* = 0 */
+static int mux_drv_refcount [NR_PORTS]; /* = 0 */
static struct tty_driver mux_drv_driver;
-static struct async_struct *mux_drv_info;
+static struct async_struct *mux_drv_info [NR_PORTS];
static struct timer_list mux_drv_timer;
-#define NR_PORTS 1
static struct tty_struct *mux_drv_table[NR_PORTS];
static struct termios *mux_drv_termios[NR_PORTS];
static struct termios *mux_drv_termios_locked[NR_PORTS];
@@ -127,6 +128,13 @@
break_pressed = 0;
}
#endif
+ if ((data & 0xff) == 0x1c)
+ {
+ extern void machine_restart (char *);
+
+ printk ("\n\n<<console machine reset>>\n\n");
+ machine_restart (NULL);
+ }
tty->flip.flag_buf_ptr++;
tty->flip.char_buf_ptr++;
@@ -146,13 +154,19 @@
static void
mux_drv_poll(unsigned long unused)
{
- struct async_struct *info = mux_drv_info;
+ struct async_struct *info;
+ int line;
- if(info && info->tty && mux_drv_refcount) {
+ for (line = 0; line < NR_PORTS; line++)
+ {
+ info = mux_drv_info [line];
+ if(info && info->tty && mux_drv_refcount [line]) {
+ /* CP */ printk ("%s: %d\n", __FUNCTION__, line);
mux_read_fifo(info);
info->last_active = jiffies;
+ }
}
-
+ /* CP */ printk ("%s: done\n", __FUNCTION__);
mod_timer(&mux_drv_timer, jiffies + MUX_POLL_DELAY);
}
@@ -224,6 +238,21 @@
unsigned long iomem_base =
(unsigned long)((struct async_struct *)tty->driver_data)->iomem_base;
+ /* CP */
+ {
+ int i, line = ((struct async_struct *)tty->driver_data)->line;
+
+ if (line > 0)
+ {
+ printk ("%s: <%s>(%d) to 0x%08x\n", __FUNCTION__,
+ buf, count, iomem_base + IO_DATA_REG_OFFSET);
+
+ for (i = 0; i < count; i++)
+ printk ("%02x ", buf [i]);
+ printk ("\n");
+ }
+ }
+
while (count) {
size = mux_write_room(tty);
len = (size < count) ? size : count;
@@ -245,8 +274,10 @@
__raw_writel(*buf_p++, iomem_base + IO_DATA_REG_OFFSET);
}
}
+ /* CP */ printk ("%s: before mux_flush_buffer()\n", __FUNCTION__);
mux_flush_buffer(tty);
+ /* CP */ printk ("%s: done\n", __FUNCTION__);
return ret;
}
@@ -402,9 +433,11 @@
mux_close(struct tty_struct *tty, struct file *filp)
{
struct async_struct *info = (struct async_struct *) tty->driver_data;
+ int line = info->line;
- mux_drv_refcount--;
- if (mux_drv_refcount > 0)
+ mux_drv_refcount [line]--;
+ global_mux_drv_refcount--;
+ if (mux_drv_refcount [line] > 0)
return;
info->flags |= ASYNC_CLOSING;
@@ -434,7 +467,7 @@
tty->closing = 0;
info->event = 0;
info->tty = 0;
- mux_drv_info = NULL;
+ mux_drv_info [line] = NULL;
if (info->blocked_open) {
if (info->close_delay) {
set_current_state(TASK_INTERRUPTIBLE);
@@ -473,7 +506,8 @@
info->port = 0;
info->flags = 0;
info->io_type = 0;
- info->iomem_base = (void *)(hpa + MUX_OFFSET);
+ info->iomem_base = (void *)(hpa + MUX_OFFSET +
+ (line * MUX_LINE_OFFSET));
info->iomem_reg_shift = 0;
info->xmit_fifo_size = MUX_FIFO_SIZE;
info->line = line;
@@ -514,11 +548,12 @@
tty->driver_data = info;
info->tty = tty;
- mux_drv_info = info;
+ mux_drv_info [line] = info;
info->tty->low_latency = 0;
info->session = current->session;
info->pgrp = current->pgrp;
- mux_drv_refcount++;
+ mux_drv_refcount [line]++;
+ global_mux_drv_refcount++;
return 0;
}
@@ -533,7 +568,8 @@
mux_probe(struct parisc_device *dev)
{
if(hpa) {
- printk(KERN_INFO "Serial MUX driver already registered, skipping additonal MUXes for now.\n");
+ printk(KERN_INFO "Serial MUX driver already registered, "
+ "skipping additonal MUXes for now.\n");
return 1;
}
@@ -564,7 +600,7 @@
mux_drv_driver.init_termios.c_cflag =
B9600 | CS8 | CREAD | HUPCL | CLOCAL;
mux_drv_driver.flags = TTY_DRIVER_REAL_RAW | TTY_DRIVER_NO_DEVFS;
- mux_drv_driver.refcount = &mux_drv_refcount;
+ mux_drv_driver.refcount = &global_mux_drv_refcount;
mux_drv_driver.table = mux_drv_table;
mux_drv_driver.termios = mux_drv_termios;
mux_drv_driver.termios_locked = mux_drv_termios_locked;
@@ -627,7 +663,8 @@
{
int status = tty_unregister_driver(&mux_drv_driver);
if(status) {
- printk("MUX: failed to unregister the Serial MUX driver (%d)\n", status);
+ printk("MUX: failed to unregister the "
+ "Serial MUX driver (%d)\n", status);
}
}
--------------337BA726D358AC462F45C980--
From bdhilton@charter.net Tue Sep 17 00:15:01 2002
From: bdhilton@charter.net (B. Douglas Hilton)
Date: Mon, 16 Sep 2002 19:15:01 -0400
Subject: [parisc-linux] Serial Terminal on C-180 system
References: <3D86629A.F8CB5564@optushome.com.au>
Message-ID: <3D8665F5.9090102@charter.net>
As I understand it, if you unplug the keyboard and mouse,
then the system will boot to serial console. I think you
just plug the kb, mouse, and monitor in and you will get
a graphics console. You might have to set something in the
firmware also, can't remember.
- Doug
Rod Smart wrote:
> Hello again.
>
> Last time I was here I was asking about how to get the C-180 to use
> Serial Terminal, I havn't been able to get it talking to the other Linux
> or wincrash system, so I would like to transfer it back to Video mode
> (turn off Serial Terminal.
>
> How do I do this when I cannot see the screen ?
>
> _______________________________________________
> parisc-linux mailing list
> parisc-linux@lists.parisc-linux.org
> http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
>
From derekengelhaupt@rocketmail.com Tue Sep 17 00:35:15 2002
From: derekengelhaupt@rocketmail.com (Derek Engelhaupt)
Date: Mon, 16 Sep 2002 16:35:15 -0700 (PDT)
Subject: [parisc-linux] Serial Terminal on C-180 system
In-Reply-To: <3D86629A.F8CB5564@optushome.com.au>
Message-ID: <20020916233515.96215.qmail@web12507.mail.yahoo.com>
The C180 will output a signal to the serial port whenever it doesn't
detect a keyboard. It doesn't need to be turned off. So, plug in your
monitor, mouse, and keyboard. You should get something off you
graphics card unless you really messed up the graphics config in the
boot handler menus. If you don't get anything you will problably need
to connect a serial console to your machine that will emulate vt100.
derek
--- Rod Smart <snaketails@optushome.com.au> wrote:
> Hello again.
>
> Last time I was here I was asking about how to get the C-180 to
> use
> Serial Terminal, I havn't been able to get it talking to the other
> Linux
> or wincrash system, so I would like to transfer it back to Video mode
> (turn off Serial Terminal.
>
> How do I do this when I cannot see the screen ?
>
> _______________________________________________
> parisc-linux mailing list
> parisc-linux@lists.parisc-linux.org
> http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
__________________________________________________
Do you Yahoo!?
Yahoo! News - Today's headlines
http://news.yahoo.com
From rbradetich@uswest.net Tue Sep 17 03:25:01 2002
From: rbradetich@uswest.net (Ryan Bradetich)
Date: 16 Sep 2002 20:25:01 -0600
Subject: [parisc-linux] Re: Status SPIFI SCSI
In-Reply-To: <3D8516EF.7A7D8206@gmx.at>
References: <3D8516EF.7A7D8206@gmx.at>
Message-ID: <1032229501.930.45.camel@beavis>
Hello Christoph,
On Sun, 2002-09-15 at 17:25, Christoph Plattner wrote:
> Hallo Ryan,
>
> here some comments on my non-successful work so far.
>
> I did code reading and used debug instrumented code
> to understand the structure behind the linux SCSI
> handling.
>
> Further I studied the NetBSD code.
>
> One major point: We do not get any interrupts.
> For my analysis I only had a look on the first
> steps of SCSI initialization, so this was the
> INQUERY command.
This is where I am also currently stuck :( The
ESIEE guys are going to hook up an analyzer to the
box and see if the target device is getting the command
(ie... did we send the command correctly to the device)
or if the device returns a command (do we catch the
command the device is returning). I have been studyting
the setup routines in the HP-UX driver and I believe
I have the chip initialized properly ... but I am not
sure why I am not getting any interrupts. Hopefully
between ESIEE, you, and myself and anyone else
interested we can figure this out.
> The spifi command routine is called correctly,
> but it has a wrong logical implementation. As I
> have seen on other (older) linux driver, the
> xxx_command() has to block, after the command was
> successful completed by interrupt. But the interrupt
> never comes !! Even a "long" delay for simulating
> blocking does not solve this problem.
That is highly possible. The driver skeleton is just
a test harness for me right now. I am just trying to see
what I can get returned from the spifi chip (that is why
most of the functions are stubs with printk. Once I see
an interrupt come in, I'll start working on putting that piece
togeather.
> From base of the NetBSD code, I cannot follow your
> code resetting the spifi subsystem. I think you have
> this from HP-UX code. Especially the
>
> __raw_writel(CMD_RESET, dev->hpa + IO_MODULE_COMMAND);
Yes, this is part of the initizlization from the HP-UX
driver. The Loquix chip sits between the HP-PB bus, and
the spifi scsi chip. According to the HP-UX driver, the
Loquix chip also required some setup. Once again, I
do not actually have the Loquix documentation, but I might
have a lead on it. Will have to wait and see if that lead
pans out.
> Is this a reset method via the IO PDC address space
> common for all HP devices ? In the NetBSD the full
> reset is done only via the `auxctrl' register, which
> you use for releasing the reset state.
I am not sure about all the HP devices. It might be an iodc
specific call. I will have to look at the driver again,
but that might reset the loquix chip *shrug* I'll take
a look and see what I can find.
> So we have a principal problem here, not having correct
> access to the spifi subsystem. Except: the SCSI-ID is
> read out correctly, I think, as ...
>
> SCSI subsystem driver Revision: 1.00
> DEBUG: 0xfff74c00
> Device: Sahp Baat Kiuh SCSI
> scsi0 : SPIFI SCSI: scsi_id: 7 IRQ: 34 type: SPIFI-3 (SE) parity
> checking: enabled
>
> ... is reported !
That is where I am also. We actually read the type SPIFI-3 (SE) for the
SKUNK card, and SPIFI-3 (DF) for the wizard (16-bit) card. I have
tested this on both cards so I know it works. I am convinced we are
reading the correct information from the card, but what I am not
convinced of is that we have it setup properly yet :) The problem is I
do not know what I am missing yet :(
> Is everything around the interrupt subsystem setup correctly ?
> The `cat /proc/interrupts' tells ...
>
> bash# cat /proc/interrupts
> CPU396195552
> 32: 124925 PARISC-CPU timer
> 33: 19767 PARISC-CPU lasi
> 34: 0 PARISC-CPU spifi
> 87: 19767 Lasi i82596
>
> ... which is no surprise ... !
>
I do not think the fact the interrupt is registered is very infomative,
I think you can register an interrupt for device even if it doesn't have
an real irq assocaitated with it (ie... the serial mux).
Yeah, thanks for looking at it ... we will have to beat on it some more
and see what we can find. Hopefully the ESIEE guys will be able to
provide us with some good information!
Thanks
- Ryan
> Till soon,
> Christoph P.
>
>
>
>
>
> --
> -------------------------------------------------------
> private: christoph.plattner@gmx.at
> company: christoph.plattner@alcatel.at
>
From rbradetich@uswest.net Tue Sep 17 03:29:22 2002
From: rbradetich@uswest.net (Ryan Bradetich)
Date: 16 Sep 2002 20:29:22 -0600
Subject: [parisc-linux] Re: SCSI/MUX driver on E55, NDA for sorce code
In-Reply-To: <3D8519D7.55D90667@gmx.at>
References: <3D825FDF.CD6E8CE2@gmx.at> <1031962399.930.17.camel@beavis>
<3D8281F4.F03A2007@gmx.at> <1031964117.1043.29.camel@beavis>
<3D84CD3B.88A9528B@gmx.at>
<20020915192500.D10583@parcelfarce.linux.theplanet.co.uk>
<3D8519D7.55D90667@gmx.at>
Message-ID: <1032229762.1043.50.camel@beavis>
On Sun, 2002-09-15 at 17:37, Christoph Plattner wrote:
> Thanks for that !
>
> But I think, my Linux code dose the same !!!
>
> info->iomem_base = (void *)(hpa + MUX_OFFSET +
> (line * MUX_LINE_OFFSET));
>
> This info->iomem_base is used by all accesses, the
> registers of i/o are defined by Ryan as:
>
> #define IO_COMMAND_REG_OFFSET 0x30
> #define IO_STATUS_REG_OFFSET 0x34
> #define IO_DATA_REG_OFFSET 0x3c
> #define IO_DCOUNT_REG_OFFSET 0x40
> #define IO_UCOUNT_REG_OFFSET 0x44
> #define IO_FIFOS_REG_OFFSET 0x48
>
> So the offset of 0x30 is inside those macros.
>
> An example of an access:
>
> data = __raw_readl((unsigned long)info->iomem_base
> + IO_DATA_REG_OFFSET);
>
> ... reading characters from the input buffers.
>
> Any further idea ?
>
> Ryan, you mentioned problems concerning missing locks, but
> I cannot think about this. Those devices should be controlled
> independent, am I wrong ?
Locks was just an idea of why it might now work. Nothing suggested that
yet. I found the MPD, now I just need to make a cable for it to hook up
to a different system and test with. Hopefully will get this done this
week and I'll take a look at it :)
> I hope, we will solve this all (all means including SPIFI
> SCSI driver too !).
>
> Christoph
From grundler@dsl2.external.hp.com Tue Sep 17 04:53:27 2002
From: grundler@dsl2.external.hp.com (Grant Grundler)
Date: Mon, 16 Sep 2002 21:53:27 -0600
Subject: [parisc-linux] Re: Status SPIFI SCSI
In-Reply-To: Message from Ryan Bradetich <rbradetich@uswest.net>
of "16 Sep 2002 20:25:01 MDT." <1032229501.930.45.camel@beavis>
References: <3D8516EF.7A7D8206@gmx.at> <1032229501.930.45.camel@beavis>
Message-ID: <20020917035327.E51E34829@dsl2.external.hp.com>
Ryan Bradetich wrote:
> > __raw_writel(CMD_RESET, dev->hpa + IO_MODULE_COMMAND);
This looks like something will be documented in the IO ACD.
CMD_RESET is an architecture defined command PA IO devices
are required to accept.
> > Is this a reset method via the IO PDC address space
> > common for all HP devices?
I believe so. That doesn't mean *all* of them implement
it properly or even need it.
> That is where I am also. We actually read the type SPIFI-3 (SE) for the
> SKUNK card, and SPIFI-3 (DF) for the wizard (16-bit) card.
I'm pretty sure wizard card used SPIFI-4.
hth,
grant
From j@steindlberger.de Tue Sep 17 08:24:49 2002
From: j@steindlberger.de (J.Steindlberger)
Date: Tue, 17 Sep 2002 09:24:49 +0200
Subject: [parisc-linux] Serial Terminal on C-180 system
In-Reply-To: <3D86629A.F8CB5564@optushome.com.au>
References: <3D86629A.F8CB5564@optushome.com.au>
Message-ID: <20020917072310.0167F4829@dsl2.external.hp.com>
Hi Rod,
I guess Your problem is, that Your C180 graphic is not sending an usable
signal to Your Monitor. You need to plug in keyboard an monitor. And a few
seconds after switching on press the TAB key -- the workstation will change
the video mode several times with about 3 seconds delay. Press ENTER if the
mode is okay for You. (I hope it's correct in my mind)
I don't know whether or not You need do some changes via serial first.
(Switch console with "pa con graphic(0)" perhaps)
On Tuesday 17 September 2002 01:00, you wrote:
> Hello again.
>
> Last time I was here I was asking about how to get the C-180 to use
> Serial Terminal, I havn't been able to get it talking to the other Linux
> or wincrash system, so I would like to transfer it back to Video mode
> (turn off Serial Terminal.
>
> How do I do this when I cannot see the screen ?
From varenet@esiee.fr Tue Sep 17 11:19:22 2002
From: varenet@esiee.fr (Thibaut VARENE)
Date: Tue, 17 Sep 2002 12:19:22 +0200
Subject: [parisc-linux] B132L+ crash with mpg123
Message-ID: <3D8701AA.4040700@esiee.fr>
Hi fellows !
I've been experiencing several crashes on B132L+ while playing mp3s with
mpg123, the box was then running 2.4.18-pa21.
I've tried recently with 2.4.19-pa18, and it crashed again.
The crash happens at random time, on random files.
What's worth mentionning is that files are played from a remote NFS
filesystem. (BTW, the console shows "svc: unknown version (0)" when
mounting the NFS system).
So I took my little fingers and I reproduced here what the console
showed me. I hope there is now mistake in this "hand dump", though I
read it twice ;)
HTH,
Thibaut VARENE
PA/Linux ESIEE Team
http://pateam.esiee.fr/
WARNING! Stack pointer and cr30 do not correspond!
Dumping virtual address stack instead
Kernel Fault: Code=15 regs=11ddc640 (Addr=00277e00)
YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
PSW: 00000000000011000000000000001111 Not tainted
r00-03 00000000 00000023 101feac4 00000200
r04-07 1035c1fc fffff000 1035c010 00000000
r08-11 1035c1fc 00001200 1035c010 1035c010
r12-15 00029f00 1035c25c faf01590 00017000
r16-19 00028678 00028678 00002000 00000e00
r20-23 00001000 00000000 00000001 00001200
r24-27 000001ff 00029f01 00277e00 10290010
r28-31 00000000 ffffffff 11ddc640 101fea8c
sr0-3 00000000 00000246 00000000 00000246
sr4-7 00000000 00000000 00000000 00000000
IASQ: 00000000 0000000 IAOQ: 10263c78 10263c70
IIR: 0f411222 ISR: 00000000 IOR: 00277e00
CPU: 0 CR30: 11ddc000 CR31: 10338000
ORIG_R28: 11ddc7b8
From grundler@dsl2.external.hp.com Tue Sep 17 18:00:01 2002
From: grundler@dsl2.external.hp.com (Grant Grundler)
Date: Tue, 17 Sep 2002 11:00:01 -0600
Subject: [parisc-linux] B132L+ crash with mpg123
In-Reply-To: Message from Thibaut VARENE <varenet@esiee.fr>
of "Tue, 17 Sep 2002 12:19:22 +0200." <3D8701AA.4040700@esiee.fr>
References: <3D8701AA.4040700@esiee.fr>
Message-ID: <20020917170001.DA8DC4829@dsl2.external.hp.com>
Thibaut VARENE wrote:
> I've been experiencing several crashes on B132L+ while playing mp3s with
> mpg123, the box was then running 2.4.18-pa21.
Harmony driver definitely has some bugs.
My B180 is stable until I listen to MP3s as well.
System crashes after ~1 hour of play.
> What's worth mentionning is that files are played from a remote NFS
> filesystem. (BTW, the console shows "svc: unknown version (0)" when
> mounting the NFS system).
I'm doing everything local.
> Kernel Fault: Code=15 regs=11ddc640 (Addr=00277e00)
>
> YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
> PSW: 00000000000011000000000000001111 Not tainted
> r00-03 00000000 00000023 101feac4 00000200
...
> IASQ: 00000000 0000000 IAOQ: 10263c78 10263c70
...
what symbols do 101feac4 and 10263c78 refer to?
grant
From willy@debian.org Tue Sep 17 18:07:13 2002
From: willy@debian.org (Matthew Wilcox)
Date: Tue, 17 Sep 2002 18:07:13 +0100
Subject: [parisc-linux] B132L+ crash with mpg123
In-Reply-To: <20020917170001.DA8DC4829@dsl2.external.hp.com>; from grundler@dsl2.external.hp.com on Tue, Sep 17, 2002 at 11:00:01AM -0600
References: <3D8701AA.4040700@esiee.fr> <varenet@esiee.fr> <20020917170001.DA8DC4829@dsl2.external.hp.com>
Message-ID: <20020917180713.P10583@parcelfarce.linux.theplanet.co.uk>
On Tue, Sep 17, 2002 at 11:00:01AM -0600, Grant Grundler wrote:
> > Kernel Fault: Code=15 regs=11ddc640 (Addr=00277e00)
> >
> > YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
> > PSW: 00000000000011000000000000001111 Not tainted
> > r00-03 00000000 00000023 101feac4 00000200
> ...
> > IASQ: 00000000 0000000 IAOQ: 10263c78 10263c70
> ...
> what symbols do 101feac4 and 10263c78 refer to?
10263c78 is in copy_from_user, 101feac4 is in harmony_audio_write().
the only point at which we call copy_from_user is:
/* Copy the page to an aligned buffer */
copy_from_user(played_buf.addr + (HARMONY_BUF_SIZE*buf_to_fill)
+ harmony.play_offset,
buffer+count, frame_size);
--
Revolutions do not require corporate support.
From varenet@esiee.fr Tue Sep 17 18:16:52 2002
From: varenet@esiee.fr (Thibaut VARENE)
Date: Tue, 17 Sep 2002 19:16:52 +0200
Subject: [parisc-linux] Fwd: A500 hang up 2.4.19-pa18 (lot of) details
Message-ID: <3D876384.1090200@esiee.fr>
This a forward to the p-l.o m-l about hang-up with 2.4.19-pa18 kernel,
that occurs when playing around with setiathome. See the transcript for
details.
info taken from System.map:
mkhppa3:~# ./a.out 000000001015c620
0x1015c620 kmem_cache_free+a8
mkhppa3:~# ./a.out 000000001015bfb0
0x1015bfb0 free_block+48
BTW, you'll notice that the second CPU timed-out, instead of dumping
when the first one died...
HTH
Thibaut VARENE wrote:
>
>
> I was able to reproduce the same hang, with a little variant:
> the first time i hanged the box, i launched both seti one after the
> other (i.e., "cd seti1; ./setiathome &" and then "cd ../seti2;
> ./setiathome &") and the box crashed when firing the second one.
>
> Here i started one. then did some small commands like "ls", "top" and
> so, and then started the second one. It didn't crash. I did a top, ls,
> ps -ef, no pb.
> Then i decided to stop both setis (killall setiathome), and start one
> again. It crahsed.
>
> See the following session transcript:
>
> Booting...
> Boot IO Dependent Code (IODC) revision 1
>
>
> HARD Booted.
> palo ipl 0.97 root@c3k Tue Nov 27 14:51:48 MST 2001
> Information: Boot device can't seek past 2Gb (ignore next
> error).byteio_read: seekread() returned -1 expected 2048
>
> Partition Start(MB) End(MB) Id Type
> 1 1 15 f0 Palo
> 2 16 503 82 swap
> 3 504 2887 83 ext2
>
> PALO(F0) partition contains:
> 0/vmlinux64 3990942 bytes @ 0x44000
>
> Information: No console specified on kernel command line. This is normal.
> PALO will choose the console currently used by firmware (serial).
> Command line for kernel: 'root=/dev/sda3 HOME=/ console=ttyS0 TERM=vt102'
> Selected kernel: /boot/vmlinux from partition 3
> ELF64 executable
> Entry 00100000 first 00100000 n 4
> Segment 0 load 00100000 size 2448040 mediaptr 0x1000
> Segment 1 load 00356000 size 1043344 mediaptr 0x257000
> Segment 2 load 00458000 size 431368 mediaptr 0x356000
> Segment 3 load 004c4000 size 49152 mediaptr 0x3c0000
> Branching to kernel entry point 0x00100000. If this is the last
> message you see, you may need to switch your console. This is
> a common symptom -- search the FAQ and mailing list at parisc-linux.org
>
> Linux version 2.4.19-pa18 (root@mkhppa3) (gcc version 3.0) #1 SMP Sun
> Sep 15 18:21:12 CEST 2002
> FP[0] enabled: Rev 1 Model 16
> The 64-bit Kernel has started...
> Determining PDC firmware type: 64 bit PAT.
> model 00005d50 00000491 00000000 00000001 5cbb53d8 100000f0 00000008
> 000000b2 000000b2
> vers 00000301
> CPUID vers 18 rev 11 (0x0000024b)
> capabilities 0x1
> model 9000/800/A500-5X
> Total Memory: 1024 Mb
> pagetable_init
> On node 0 totalpages: 262144
> zone(0): 262144 pages.
> zone(1): 0 pages.
> zone(2): 0 pages.
> Kernel command line: root=/dev/sda3 HOME=/ console=ttyS0 TERM=vt102
> Calibrating delay loop... 1097.72 BogoMIPS
> Memory: 1019664k available
> Dentry cache hash table entries: 131072 (order: 9, 2097152 bytes)
> Inode cache hash table entries: 65536 (order: 8, 1048576 bytes)
> Mount-cache hash table entries: 16384 (order: 6, 262144 bytes)
> Buffer-cache hash table entries: 65536 (order: 7, 524288 bytes)
> Page-cache hash table entries: 262144 (order: 9, 2097152 bytes)
> Searching for devices...
> Found devices:
> 1. Crescendo 550 (0) at 0xfffffffffffa0000 [160], versions 0x5d5, 0x0, 0x4
> 2. Crescendo 550 (0) at 0xfffffffffffa2000 [162], versions 0x5d5, 0x0, 0x4
> 3. Astro BC Runway Port (12) at 0xfffffffffed00000 [0], versions 0x582,
> 0x0, 0xb
> 4. Elroy PCI Bridge (13) at 0xfffffffffed30000 [0/0], versions 0x782,
> 0x0, 0xa
> 5. Elroy PCI Bridge (13) at 0xfffffffffed34000 [0/2], versions 0x782,
> 0x0, 0xa
> 6. Elroy PCI Bridge (13) at 0xfffffffffed38000 [0/4], versions 0x782,
> 0x0, 0xa
> 7. Elroy PCI Bridge (13) at 0xfffffffffed3c000 [0/6], versions 0x782,
> 0x0, 0xa
> 8. Memory (1) at 0xfffffffffed08000 [8], versions 0x9b, 0x0, 0x9
> CPU(s): 2 x PA8600 (PCX-W+) at 550.000000 MHz
> SBA found Astro 2.1 at 0xfffffffffed00000
> lba version TR4.0 (0x5) found at 0xfffffffffed30000
> lba range[2] : ignoring GMMIO (0xfffffff804000000)
> lba version TR4.0 (0x5) found at 0xfffffffffed34000
> lba range[2] : ignoring GMMIO (0xfffffff904000000)
> lba version TR4.0 (0x5) found at 0xfffffffffed38000
> lba range[2] : ignoring GMMIO (0xfffffffa04000000)
> lba version TR4.0 (0x5) found at 0xfffffffffed3c000
> lba range[2] : ignoring GMMIO (0xfffffffb04000000)
> POSIX conformance testing by UNIFIX
> FP[1] enabled: Rev 1 Model 16
> SMP: Total 2 of 2 processors activated (2195.46 BogoMIPS noticed).
> Waiting on wait_init_idle (map = 0x2)
> All processors have done init_idle
> Linux NET4.0 for Linux 2.4
> Based upon Swansea University Computer Society NET3.039
> Initializing RT netlink socket
> Soft power switch support not available.
> Performance monitoring counters enabled for Crescendo 550
> Starting kswapd
> Journalled Block Device driver loaded
> Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
> pty: 256 Unix98 ptys configured
> Serial driver version 5.05c (2001-07-08) with MANY_PORTS SHARE_IRQ
> SERIAL_PCI enabled
> Redundant entry in serial pci_table. Please send the output of
> lspci -vv, this message (103c,1048,103c,1049)
> and the manufacturer and name of serial board or modem board
> to serial-pci-info@lists.sourceforge.net.
> ttyS00 at iomem 0xfffffffff8000000 (irq = 132) is a 16550A
> ttyS01 at iomem 0xfffffffff8000008 (irq = 132) is a 16550A
> ttyS02 at iomem 0xfffffffff8000010 (irq = 132) is a 16550A
> Redundant entry in serial pci_table. Please send the output of
> lspci -vv, this message (103c,1048,103c,104a)
> and the manufacturer and name of serial board or modem board
> to serial-pci-info@lists.sourceforge.net.
> ttyS03 at iomem 0xfffffffff8006000 (irq = 133) is a 16550A
> ttyS04 at iomem 0xfffffffff8006008 (irq = 133) is a 16550A
> Generic RTC Driver v1.02 05/27/1999 Sam Creasey (sammy@oh.verio.com)
> RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
> loop: loaded (max 8 devices)
> Linux Tulip driver version 0.9.15-pre11 (May 11, 2002)
> tulip0: no phy info, aborting mtable build
> tulip0: MII transceiver #1 config 1000 status 782d advertising 0061.
> eth0: Digital DS21143 Tulip rev 65 at 0xfffffffff8007000,
> 00:30:6E:0C:8A:8F, IRQ 128.
> SCSI subsystem driver Revision: 1.00
> sym53c8xx: at PCI bus 0, device 2, function 0
> sym53c8xx: 53c875 detected
> sym53c8xx: at PCI bus 0, device 2, function 1
> sym53c8xx: 53c875 detected
> sym53c8xx: at PCI bus 0, device 1, function 0
> sym53c8xx: setting PCI_COMMAND_INVALIDATE (fix-up)
> sym53c8xx: 53c896 detected
> sym53c8xx: at PCI bus 0, device 1, function 1
> sym53c8xx: setting PCI_COMMAND_INVALIDATE (fix-up)
> sym53c8xx: 53c896 detected
> sym53c875-0: rev 0x14 on pci bus 0 device 2 function 0 irq 130
> sym53c875-0: ID 7, Fast-10, Parity Checking
> sym53c875-1: rev 0x14 on pci bus 0 device 2 function 1 irq 131
> sym53c875-1: ID 7, Fast-20, Parity Checking
> sym53c896-2: rev 0x7 on pci bus 0 device 1 function 0 irq 129
> sym53c896-2: ID 7, Fast-20, Parity Checking
> sym53c896-2: handling phase mismatch from SCRIPTS.
> sym53c896-3: rev 0x7 on pci bus 0 device 1 function 1 irq 130
> sym53c896-3: ID 7, Fast-20, Parity Checking
> sym53c896-3: handling phase mismatch from SCRIPTS.
> scsi0 : sym53c8xx-1.7.3c-20010512
> scsi1 : sym53c8xx-1.7.3c-20010512
> scsi2 : sym53c8xx-1.7.3c-20010512
> scsi3 : sym53c8xx-1.7.3c-20010512
> Vendor: SEAGATE Model: ST39103LC Rev: HP02
> Type: Direct-Access ANSI SCSI revision: 02
> Attached scsi disk sda at scsi1, channel 0, id 15, lun 0
> sym53c875-1-<15,*>: FAST-20 WIDE SCSI 40.0 MB/s (50.0 ns, offset 15)
> SCSI device sda: 17783112 512-byte hdwr sectors (9105 MB)
> Partition check:
> sda: sda1 sda2 sda3 sda4 < sda5 sda6 >
> NET4: Linux TCP/IP 1.0 for NET4.0
> IP Protocols: ICMP, UDP, TCP
> IP: routing cache hash table of 1024 buckets, 48Kbytes
> TCP: Hash tables configured (established 32768 bind 65536)
> NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
> kjournald starting. Commit interval 5 seconds
> EXT3-fs: mounted filesystem with ordered data mode.
> VFS: Mounted root (ext3 filesystem) readonly.
> Freeing unused kernel memory: 421k freed
> INIT: version 2.84 booting
> Activating swap.
> Adding Swap: 499704k swap-space (priority -1)
> Checking root file system...
> fsck 1.27 (8-Mar-2002)
> /dev/sda3: clean, 57492/305216 files, 321970/610304 blocks
> EXT3 FS 2.4-0.9.17, 10 Jan 2002 on sd(8,3), internal journal
> System time was Mon Sep 16 10:11:13 UTC 2002.
> Setting the System Clock using the Hardware Clock as reference...
> System Clock set. System local time is now Mon Sep 16 10:10:05 UTC 2002.
> Calculating module dependencies... depmod: Can't open
> /lib/modules/2.4.19-pa18/modules.dep for writing
> done.
> Loading modules:
> modprobe: Can't open dependencies file
> /lib/modules/2.4.19-pa18/modules.dep (No such file or directory)
> Checking all file systems...
> fsck 1.27 (8-Mar-2002)
> /dev/sda5: clean, 104123/366528 files, 553485/732412 blocks
> /dev/sda6 has been mounted 35 times without being checked, check forced.
> /dev/sda6: 132287/376096 files (6.2% non-contiguous), 695541/751356 blocks
> Setting kernel variables.
> Mounting local filesystems...
> kjournald starting. Commit interval 5 seconds
> EXT3 FS 2.4-0.9.17, 10 Jan 2002 on sd(8,5), internal journal
> EXT3-fs: mounted filesystem with ordered data mode.
> /dev/sda5 on /home type ext3 (rw)
> kjournald starting. Commit interval 5 seconds
> EXT3 FS 2.4-0.9.17, 10 Jan 2002 on sd(8,6), internal journal
> EXT3-fs: mounted filesystem with ordered data mode.
> /dev/sda6 on /work type ext3 (rw)
> Cleaning: /etc/network/ifstate.
> Setting up IP spoofing protection: rp_filter.
> Configuring network interfaces: done.
> Starting portmap daemon: portmap.
> Loading the saved-state of the serial devices...
> Cannot set serial info: Device or resource busy
> /dev/ttyS0 at 0x0000 (irq = 132) is a 16550A
> /dev/ttyS1 at 0x0500 (irq = 133) is a 16550A
> /dev/ttyS2 at 0x0000 (irq = 132) is a 16550A
> /dev/ttyS3 at 0x0000 (irq = 133) is a 16550A
>
> Setting the System Clock using the Hardware Clock as reference...
> System Clock set. Local time: Mon Sep 16 12:11:23 CEST 2002
>
> Cleaning: /tmp /var/lock /var/run.
> eth0: Setting half-duplex based on MII#1 link partner capability of 0021.
> Initializing random number generator... done.
> Recovering nvi editor sessions... done.
> INIT: Entering runlevel: 2
> Starting system log daemon: syslogd.
> Starting kernel log daemon: klogd.
> Starting NFS common utilities: statd.
> Starting internet superserver: inetd.
> Starting OpenBSD Secure Shell server: sshd.
> Starting NTP server: ntpd.
> Starting NFS servers: nfsd mountd.
> Starting periodic command scheduler: cron.
>
> Debian GNU/Linux testing/unstable mkhppa3 ttyS0
>
> mkhppa3 login: varenet
> Password:
> Last login: Mon Sep 16 12:02:45 2002 from grobluk.esiee.fr on pts/0
> Linux mkhppa3 2.4.19-pa18 #1 SMP Sun Sep 15 18:21:12 CEST 2002 parisc64
> unknown unknown GNU/Linux
>
> Most of the programs included with the Debian GNU/Linux system are
> freely redistributable; the exact distribution terms for each program
> are described in the individual files in /usr/share/doc/*/copyright
>
> Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
> permitted by applicable law.
> [varenet@mkhppa3 ~]$ cd seti
> seti1
> seti2
> setiathome-3.03.hppa-parisc-palinux.tar
> [varenet@mkhppa3 ~]$ cd seti1/
> [varenet@mkhppa3 ~/seti1]$ ./setiathome &
> [1] 185
> [varenet@mkhppa3 ~/seti1]$ >>DEBUG : Use LOCKFSETI@home client.
> Platform: hppa-parisc-palinux
> Version: 3.03
>
> SETI@home is sponsored by individual donors around the world.
> If you'd like to contribute to the project,
> please visit the SETI@home web site at
> http://setiathome.ssl.berkeley.edu.
> The project is also sponsored by the Planetary Society,
> the University of California, Sun Microsystems, Paramount Pictures,
> Fujifilm Computer Products, Informix, Engineering Design Team Inc,
> The Santa Cruz Operation (SCO), Intel, Quantum Corporation,
> and the SETI Institute.
>
> SETI@home was developed by David Gedye (Founder),
> David Anderson (Director), Dan Werthimer (Chief Scientist),
> Leonard Chung, Hiram Clawson, Jeff Cobb, Charles Congdon, Charlie Fenton,
> Kyle Granger, Eric Heien, Mike Hill, Michael Kang, Eric Korpela,
> Matt Lebofsky, Peter Leiser, Brad Silen, Woody Sullivan, and Adam Wight.
>
> Scanning data file
> Data Info:
> Sky coordinates: 1.605 R.A., 8.090 Dec
> Recorded on: 2452319.35352 (Wed Feb 13 20:29:04 2002)
> Source: Arecibo Radio Observatory
> Base Frequency: 1.421201172 GHz
> Found data file: yes. Found result header file: yes.
> Scanning result header file.
> Beginning analysis...
> (This is the last message displayed while the client works.
> To see progress messages between now and completion of
> processing, operate the client with the -verbose option.
> You can also see the progress of the client by looking at
> 12:11:58 up 3 min, 1 user, load average: 0.74, 0.48, 0.19
> 23 processes: 21 sleeping, 2 running, 0 zombie, 0 stopped
> CPU states: 0.1% user, 0.9% system, 48.1% nice, 50.9% idle
> Mem: 1020088K total, 101308K used, 918780K free, 1468K buffers
> Swap: 499704K total, 0K used, 499704K free, 9792K cached
>
> PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME COMMAND
> 185 varenet 18 1 13772 13M 376 R N 97.4 1.3 0:11 setiathome
> 187 varenet 12 0 1128 1132 912 R 0.7 0.1 0:00 top
> 1 root 9 0 612 616 520 S 0.0 0.0 0:07 init
> 2 root 9 0 0 0 0 SW 0.0 0.0 0:00 keventd
> 3 root 19 19 0 0 0 SWN 0.0 0.0 0:00
> ksoftirqd_CPU0
> 4 root 18 19 0 0 0 SWN 0.0 0.0 0:00
> ksoftirqd_CPU1
> 5 root 9 0 0 0 0 SW 0.0 0.0 0:00 kswapd
> 6 root 9 0 0 0 0 SW 0.0 0.0 0:00 bdflush
> 7 root 9 0 0 0 0 SW 0.0 0.0 0:02 kupdated
> 8 root 9 0 0 0 0 SW 0.0 0.0 0:00 kjournald
>
> 66 root 9 0 0 0 0 SW 0.0 0.0 0:00 kjournald
> 67 root 9 0 0 0 0 SW 0.0 0.0 0:00 kjournald
> 90 daemon 9 0 564 564 452 S 0.0 0.0 0:00 portmap
> 146 root 9 0 1004 1004 840 S 0.0 0.0 0:00 syslogd
> 149 root 9 0 1424 1424 508 S 0.0 0.1 0:00 klogd
> 153 root 9 0 840 840 712 S 0.0 0.0 0:00 rpc.statd
>
> [varenet@mkhppa3 ~]$ cd seti2/
> [varenet@mkhppa3 ~/seti2]$ ./setiathome &
> [2] 188
> [varenet@mkhppa3 ~/seti2]$ >>DEBUG : Use LOCKFSETI@home client.
> Platform: hppa-parisc-palinux
> Version: 3.03
>
> SETI@home is sponsored by individual donors around the world.
> If you'd like to contribute to the project,
> please visit the SETI@home web site at
> http://setiathome.ssl.berkeley.edu.
> The project is also sponsored by the Planetary Society,
> the University of California, Sun Microsystems, Paramount Pictures,
> Fujifilm Computer Products, Informix, Engineering Design Team Inc,
> The Santa Cruz Operation (SCO), Intel, Quantum Corporation,
> and the SETI Institute.
>
> SETI@home was developed by David Gedye (Founder),
> David Anderson (Director), Dan Werthimer (Chief Scientist),
> Leonard Chung, Hiram Clawson, Jeff Cobb, Charles Congdon, Charlie Fenton,
> Kyle Granger, Eric Heien, Mike Hill, Michael Kang, Eric Korpela,
> Matt Lebofsky, Peter Leiser, Brad Silen, Woody Sullivan, and Adam Wight.
>
> Scanning data file
> Data Info:
> Sky coordinates: 4.859 R.A., 18.010 Dec
> Recorded on: 2452425.22882 (Thu May 30 17:29:29 2002)
> Source: Arecibo Radio Observatory
> Base Frequency: 1.420849609 GHz
> Found data file: yes. Found result header file: yes.
> Scanning result header file.
> 12:12:37 up 4 min, 1 user, load average: 1.20, 0.63, 0.25
> 24 processes: 21 sleeping, 3 running, 0 zombie, 0 stopped
> CPU states: 0.1% user, 1.1% system, 98.8% nice, 0.0% idle
> Mem: 1020088K total, 117088K used, 903000K free, 1548K buffers
> Swap: 499704K total, 0K used, 499704K free, 10784K cached
>
> PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME COMMAND
> 185 varenet 15 1 14984 14M 376 R N 99.8 1.4 0:49 setiathome
> 188 varenet 16 1 13772 13M 376 R N 99.6 1.3 0:24 setiathome
> 190 varenet 11 0 1128 1132 912 R 0.7 0.1 0:00 top
> 1 root 9 0 612 616 520 S 0.0 0.0 0:07 init
> 2 root 9 0 0 0 0 SW 0.0 0.0 0:00 keventd
> 3 root 19 19 0 0 0 SWN 0.0 0.0 0:00
> ksoftirqd_CPU0
> 4 root 18 19 0 0 0 SWN 0.0 0.0 0:00
> ksoftirqd_CPU1
> 5 root 9 0 0 0 0 SW 0.0 0.0 0:00 kswapd
> 6 root 9 0 0 0 0 SW 0.0 0.0 0:00 bdflush
> 7 root 9 0 0 0 0 SW 0.0 0.0 0:02 kupdated
> 8 root 9 0 0 0 0 SW 0.0 0.0 0:00 kjournald
> 66 root 9 0 0 0 0 SW 0.0 0.0 0:00 kjournald
> 67 root 9 0 0 0 0 SW 0.0 0.0 0:00 kjournald
> 90 daemon 9 0 564 564 452 S 0.0 0.0 0:00 portmap
> 146 root 9 0 1004 1004 840 S 0.0 0.0 0:00 syslogd
> 149 root 9 0 1424 1424 508 S 0.0 0.1 0:00 klogd
>
> q[varenet@mkhppa3 ~/seti2]$ killall setiathome
> [varenet@mkhppa3 ~/seti2]$ cat /proc/version
> Linux version 2.4.19-pa18 (root@mkhppa3) (gcc version 3.0) #1 SMP Sun
> Sep 15 18:21:12 CEST 2002
> [1]- Terminated ./setiathome (wd: ~/seti1)
> (wd now: ~/seti2)
> [2]+ Terminated ./setiathome
> [varenet@mkhppa3 ~/seti2]$ crontab -l
> @hourly cd /home/varenet/seti1; ./setiathome -nice 20 -proxy
> cache:3128 &
> #@reboot cd /home/varenet/dnetc; ./dnetc
> @hourly cd /home/varenet/seti2; ./setiathome -nice 20 -proxy
> cache:3128 &
> [varenet@mkhppa3 ~/seti2]$ cd /home/varenet/seti1; ./setiathome -nice 20
> -proxy cache:3128 &
> WARNING! Stack pointer and cr30 do not correspond!
> Dumping virtual address stack instead
>
> Dumping Stack from 0x000000005f5a0000 to 0x000000005f5a4dc0:
>
>
> And nothing more.
>
> after a toc, here was the content of SER PIM output:
> (I dumped everything, not sure of what may be useful or not ;)
>
> Main Menu: Enter command or menu > ser pim
>
>
> PROCESSOR PIM INFORMATION
>
>
>
> ----------------- Processor 0 HPMC Information - PDC Version: 40.50 ------
>
> Timestamp = Tue Oct 23 19:05:06 GMT 2001 (20:01:10:23:19:05:06)
>
> HPMC Chassis Codes
>
> Chassis Code Extension
> ------------ ---------
> 0x0000082000ff6242 0x0000000000000000
> 0x1800082011006322 0xcb81800000000000
> 0x0000087000ff6292 0x0000000000000000
> 0x6000082070006062 0x0000000000100010
> 0x7000082070006082 0x0000000000b92400
> 0x7000082379006133 0xc1bff0fffed08040
> 0x0000080080006310 0x0000000000000001
> 0x000008008000631f 0x0000000000000000
>
>
> General Registers 0 - 31
> 00-03 0000000000000000 00000000103f9bb0 0000000010100bac
> 00000000103f6bb0
> 04-07 000000000003d5ea 000000000038a000 00000000000000f0
> 0000000000000000
> 08-11 0000000000000000 0000000000000001 000000000804000e
> 000000001040888c
> 12-15 00000000000000f2 00000000000000fa 00000000000000f0
> 00000000000000ff
> 16-19 00000000f00003dc 00000000f000028c 00000000f0002aa4
> 00000000104a8000
> 20-23 0000000000000000 0000000000000000 0000000000000001
> 000000004fa5c824
> 24-27 000000000800000f 0000000000000032 0000000000000019
> 00000000103f6bb0
> 28-31 0000000000000000 00000000104a8b70 00000000104a8b00
> 00000000104043b0
>
>
> Control Registers 0 - 31
> 00-03 0000000000000000 0000000000000000 0000000000000000
> 0000000000000000
> 04-07 0000000000000000 0000000000000000 0000000000000000
> 0000000000000000
> 08-11 0000000000000072 0000000000000000 00000000000000c0
> 000000000000003f
> 12-15 0000000000000000 0000000000000000 0000000000104000
> ffffffffffffffff
> 16-19 0000000f96e6aa48 0000000000000000 0000000010100b88
> 0000000003c008b3
> 20-23 0000000000000000 0000000000000000 000000000804000f
> 0000000000000000
> 24-27 0000000000389000 000000003f158000 ffffffffffff7f10
> ffffffffffff7fff
> 28-31 ffffffffffffffff ffffffffffffffff 00000000104a8000
> 00000000104b0000
>
> Space Registers 0 - 7
> 00-03 00001c80 00000000 00000000 00001c80
> 04-07 00000000 00000000 00000000 00000000
>
>
> IIA Space (back entry) = 0x0000000000000000
> IIA Offset (back entry) = 0x0000000010100b8c
> Check Type = 0x20000000
> CPU State = 0x9e000004
> Cache Check = 0x00000000
> TLB Check = 0x00000000
> Bus Check = 0x0030000d
> Assists Check = 0x00000000
> Assist State = 0x00000000
> Path Info = 0x00000000
> System Responder Address = 0xfffffffffffa0000
> System Requestor Address = 0xfffffffffffa0000
>
>
> Floating Point Registers 0 - 31
> 00-03 0000000000000000 0000000000000000 0000000000000000
> 0000000000000000
> 04-07 0000000010388100 0000000100000001 0000000012a20000
> 0000000000000000
> 08-11 0000000000000802 000000004fa78000 00000000103f6bb0
> 000000004fa6fec0
> 12-15 0000000000000000 0000000010388100 000000001018197c
> 00000000103fcbb0
> 16-19 0000000010388100 0000000000000002 0000000000000002
> 000000001032d2d4
> 20-23 0000000000000001 0000000010388a80 0000000000000000
> 00000000000000c0
> 24-27 0000000a10332690 00000000104fce18 000000000800000f
> 00000000103d2af0
> 28-31 00000000103d2b20 0000000000000001 0000000010162de0
> 0000000000000002
>
>
> Check Summary = 0xcb81800000000000
> Available Memory = 0x0000000040000000
> CPU Diagnose Register 2 = 0x0301000000802004
> CPU Status Register 0 = 0x3440c20000000000
> CPU Status Register 1 = 0x8000000000000000
> SADD LOG = 0x4820000000000000
> Read Short LOG = 0xc1bff0fffed22310
>
>
>
> ----------------- Processor 0 LPMC Information ------------------
>
> Check Type = 0x00000000
> IC Parity Info = 0x00000000
> Cache Check = 0x00000000
> TLB Check = 0x00000000
> Bus Check = 0x00000000
> Assists Check = 0x00000000
> Assist State = 0x00000000
> Path Info = 0x00000000
> System Responder Address = 0x0000000000000000
> System Requestor Address = 0x0000000000000000
>
>
>
> ----------------- Processor 0 TOC Information -------------------
>
> General Registers 0 - 31
> 00-03 0000000000000000 000000001037fa30 000000001010cca0
> 0000000010443f10
> 04-07 000000004f5a5480 000000000000000f 000000001032adfc
> 000000005f5a0018
> 08-11 000000001051f190 000000001051f1a0 000000000000002e
> 0000000000000001
> 12-15 0000000000000003 000000000000002f 0000000000000000
> 0000000000000002
> 16-19 000000004f5a5480 00000000000ad800 000000000009e800
> 0000000000000000
> 20-23 000000001037fa30 0000000000000000 000000001038f690
> 000000005f5a0018
> 24-27 000000000000000f 000000004f5a5480 000000001032adfc
> 0000000010443f10
> 28-31 0000000000000040 000000004f5a5930 000000004f5a59c0
> ffffffffffffffff
>
>
> Control Registers 0 - 31
> 00-03 0000000000000000 0000000000000000 0000000000000000
> 0000000000000000
> 04-07 0000000000000000 0000000000000000 0000000000000000
> 0000000000000000
> 08-11 000000000000015a 0000000000000000 00000000000000c0
> 000000000000003e
> 12-15 0000000000000000 0000000000000000 0000000000107000
> 0000000000000000
> 16-19 00000059f094e5b5 0000000000000000 000000001010c990
> 0000000086603fed
> 20-23 0000000000240000 00000000dff7fa30 000000000804000e
> a000000000000000
> 24-27 00000000003d2000 000000003d24b000 ffffffffffff7f00
> ffffffffffffffff
> 28-31 ffffffffffff7fff ffffffffffffffff 000000004f5a4000
> 00000000104c8000
>
> Space Registers 0 - 7
> 00-03 00005680 00005680 00000000 00005680
> 04-07 00000000 00000000 00000000 00000000
>
> IIA Space (back entry) = 0x0000000000000000
> IIA Offset (back entry) = 0x000000001010c994
> CPU State = 0x9e000001
>
>
>
> ----------------- Processor 1 HPMC Information - PDC Version: 40.50 ------
>
> Timestamp = Tue Oct 23 19:05:06 GMT 2001 (20:01:10:23:19:05:06)
>
> HPMC Chassis Codes
>
> Chassis Code Extension
> ------------ ---------
> 0x0000082000ff6242 0x0000000000000000
> 0x1800082011016312 0xcb81000000000000
>
>
> General Registers 0 - 31
> 00-03 0000000000000000 0000000010368068 000000001022f13c
> 000000004fb29240
> 04-07 fffffffff8006030 00000000103f6bb0 00000000103f6bb0
> fffffffff8006000
> 08-11 000000004fb29000 fffffffff8006028 0000000000002000
> fffffffff8006030
> 12-15 000000000000012c 000000004f0d0b08 0000000000018054
> 0000000000018414
> 16-19 0000000000000000 0000000000000001 0000000000026228
> fffffffff8006000
> 20-23 0000000000000000 0000000000000000 0000000000000000
> 0000000000000000
> 24-27 0000000000000000 fffffffff8006060 fffffffff8006030
> 00000000103f6bb0
> 28-31 000000000000d6d8 000000004f0d10f0 000000004f0d1100
> 000000000000003f
>
>
> Control Registers 0 - 31
> 00-03 0000000000000000 0000000000000000 0000000000000000
> 0000000000000000
> 04-07 0000000000000000 0000000000000000 0000000000000000
> 0000000000000000
> 08-11 000000000000007c 0000000000000000 00000000000000c0
> 0000000000000002
> 12-15 0000000000000000 0000000000000000 0000000000104000
> ffffffffffffffff
> 16-19 0000000f96e6acc4 0000000000000000 0000000010270798
> 000000000f40019a
> 20-23 00000000ae27ffe0 c000000001806030 000000ff0804f40f
> 8000000000000000
> 24-27 0000000000389000 000000003f130000 ffffffffffffffff
> ffffffffffff7fff
> 28-31 ffffffffffffffff ffffffffffffffff 000000004f0d0000
> 000000004fb78000
>
> Space Registers 0 - 7
> 00-03 00001f00 00000000 00000000 00001f00
> 04-07 00000000 00000000 00000000 00000000
>
>
> IIA Space (back entry) = 0x0000000000000000
> IIA Offset (back entry) = 0x000000001027079c
> Check Type = 0x20000000
> CPU State = 0x9e000004
> Cache Check = 0x00000000
> TLB Check = 0x00000000
> Bus Check = 0x0030103b
> Assists Check = 0x00000000
> Assist State = 0x00000000
> Path Info = 0x00000000
> System Responder Address = 0x000000fff8006030
> System Requestor Address = 0xfffffffffffa2000
>
>
> Floating Point Registers 0 - 31
> 00-03 0000000000000000 0000000000000000 0000000000000000
> 0000000000000000
> 04-07 0000000010388100 0000000100000001 0000000012a20000
> 0000000000000000
> 08-11 0000000000000802 000000004fa78000 00000000103f6bb0
> 000000004fa6fec0
> 12-15 0000000000000000 0000000010388100 000000001018197c
> 00000000103fcbb0
> 16-19 0000000010388100 0000000000000002 0000000000000002
> 000000001032d2d4
> 20-23 0000000000000001 0000000010388a80 0000000000000000
> 0000000000000000
> 24-27 0000000a10332690 00000000104fce18 000000000800000f
> 00000000103d2af0
> 28-31 00000000103d2b20 0000000000000001 0000000010162de0
> 0000000000000003
>
>
> Check Summary = 0xcb81000000000000
> Available Memory = 0x0000000040000000
> CPU Diagnose Register 2 = 0x0301010000802004
> CPU Status Register 0 = 0x2440c20000000000
> CPU Status Register 1 = 0x8002000000000000
> SADD LOG = 0x0c1912c0e840d002
> Read Short LOG = 0xc1af00fff8006030
>
>
>
> ----------------- Processor 1 LPMC Information ------------------
>
> Check Type = 0x00000000
> IC Parity Info = 0x00000000
> Cache Check = 0x00000000
> TLB Check = 0x00000000
> Bus Check = 0x00000000
> Assists Check = 0x00000000
> Assist State = 0x00000000
> Path Info = 0x00000000
> System Responder Address = 0x0000000000000000
> System Requestor Address = 0x0000000000000000
>
>
>
> ----------------- Processor 1 TOC Information -------------------
>
> General Registers 0 - 31
> 00-03 0000000000000000 0000000010446f10 0000000010103714
> 0000000010443f10
> 04-07 00000000003d2000 fffffff0f040a000 0000000000000032
> 00000000000000f7
> 08-11 0000000000000000 fffffff0f0400000 000000000804000e
> 000000001045dbac
> 12-15 00000000000000f2 0000000000000001 00000000000000f0
> 00000000000000ff
> 16-19 000000f0f00000c4 fffffff0f040c000 0000000000000000
> 0000000011c50000
> 20-23 0000000000000000 0000000000000000 0000000000000001
> 000000001047f824
> 24-27 000000000800000f 0000000000000032 0000000000000019
> 0000000010443f10
> 28-31 0000000000000000 0000000011c50b30 0000000011c50ac0
> 0000000010450f10
>
>
> Control Registers 0 - 31
> 00-03 0000000000000000 0000000000000000 0000000000000000
> 0000000000000000
> 04-07 0000000000000000 0000000000000000 0000000000000000
> 0000000000000000
> 08-11 0000000000000118 0000000000000000 00000000000000c0
> 000000000000003e
> 12-15 0000000000000000 0000000000000000 0000000000107000
> ff80000000000000
> 16-19 0000005a0364ba5e 0000000000000000 00000000101036f0
> 0000000003c008b3
> 20-23 0000000000004480 0000000000000000 000000ff0806ff0f
> 0000000000000000
> 24-27 00000000003d2000 000000003daa2000 ffffffffffffffff
> ffffffffffffffff
> 28-31 ffffffffffffffff ffffffffffffffff 0000000011c50000
> ffffffffffffffff
>
> Space Registers 0 - 7
> 00-03 00004480 00004480 00000000 00004600
> 04-07 00000000 00000000 00000000 00000000
>
> IIA Space (back entry) = 0x0000000000000000
> IIA Offset (back entry) = 0x00000000101036f4
> CPU State = 0x9e000001
>
>
> -------------- Memory Error Log Information --------------
>
> Bus 0 Log Information
>
> Timestamp = Tue Oct 23 19:05:06 GMT 2001 (20:01:10:23:19:05:06)
>
> OV RQ RS ESTAT A C D corr unc fe cw pf
> -- -- -- ----- - - - ---- --- -- -- --
> X X ERR_ERROR X X
>
> Bus Requestor Address = 0xfffffffffffa0000
> Bus Target Address = 0x0000000000000000
> Bus Responder Address = 0xfffffffffed00000
>
> Error Status Reg = 0x0000000000100010
> Runway Control Reg = 0x0000021c00002818
> Runway Address Reg = 0xc1bff0fffed08040
> Runway Data High Reg = 0xf8018a1ff820ca01
> Runway Data Low Reg = 0xf8018a1ff820ca01
> Memory Address Reg = 0x000001ff3fffffff
> Memory Address Corr Reg = 0x000001ff3fffffff
> Memory Syndrome Reg = 0x0000000000000000
> Memory Syndrome Corr Reg = 0x0000000000000000
>
>
>
> Address/Control Parity Error Registers
>
> Address/Control Parity Error Bit (mem_addr_par_stat) Not Set
>
>
>
> ------------ I/O Module Error Log Information ------------
>
>
> No I/O module errors logged
>
>
> HTH,
>
> Thibaut.
>
> PS: when trying to boot after ser pim, the machine showed the following
> and hung again:
> I dunno if that's normal ?
>
> *****************************************
>
> ************* SYSTEM ALERT **************
> SYSTEM NAME: a500
> DATE: 09/16/2002 TIME: 10:23:28
> ALERT LEVEL: 7 = reserved
>
> REASON FOR ALERT
> SOURCE: 0 = unknown, no source stated
> SOURCE DETAIL: 0 = unknown, no source stated SOURCE ID: FF
> PROBLEM DETAIL: 0 = no problem detail
>
> LEDs: RUN ATTENTION FAULT REMOTE POWER
> OFF FLASH ON ON ON
> LED State: Boot Failed. Non-critical error detected.
> Check Chassis and Console Logs for error messages.
>
> 0x0000107000FF6292 00000000 00000000 - type 0 = Data Field Unused
> 0x5800187000FF6292 00006608 100A171C - type 11 = Timestamp 09/16/2002
> 10:23:28
> A: ack read of this entry - X: Disable all future alert messages
> Anything else skip redisplay the log entry
> ->Choice:a
> *****************************************
>
> I had to issue a 'RS' to reboot the box.
>
--
Thibaut VARENE
PA/Linux ESIEE Team
http://pateam.esiee.fr/
From dave@hiauly1.hia.nrc.ca Tue Sep 17 19:01:02 2002
From: dave@hiauly1.hia.nrc.ca (John David Anglin)
Date: Tue, 17 Sep 2002 14:01:02 -0400 (EDT)
Subject: [parisc-linux] GCC patch to fix various problems in the passing of aggregates
Message-ID: <200209171801.g8HI12wF017817@hiauly1.hia.nrc.ca>
This is a heads up to those that build from source. A patch was applied
yesterday to the gcc 3.3 trunk to fix various ABI related problems in the
passing of aggregates. It fixes various va_arg problems and improves
compatibility with the HP specified runtime architectures. The downside
is that code (libraries) compiled with earlier versions of gcc may be
incompatible with new code.
The impact for 32-bit code is that 5-7 byte structs are now passed
correctly. The patch also fixes a problem in passing structs with
a single char or short field. Variable and zero sized types are now
also handled correctly.
The impact for 64-bit code is more significant. All aggregates
with a non-zero size MOD 8 were incorrectly padded when passed
by value. This is now fixed. As a GCC extension to the runtime,
variable and zero sized types are passed by invisible reference.
For more info, see <http://gcc.gnu.org/ml/gcc-patches/2002-09/msg00972.html>
and <http://gcc.gnu.org/ml/gcc-patches/2002-09/msg00975.html>.
Dave
--
J. David Anglin dave.anglin@nrc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6605)
From christoph.plattner@gmx.at Tue Sep 17 19:33:16 2002
From: christoph.plattner@gmx.at (Christoph Plattner)
Date: Tue, 17 Sep 2002 20:33:16 +0200
Subject: [parisc-linux] Re: Status SPIFI SCSI
References: <3D8516EF.7A7D8206@gmx.at> <1032229501.930.45.camel@beavis>
Message-ID: <3D87756C.AFDA706B@gmx.at>
Hello Ryan,
I think usinf the logic analyser will not help you on the
SCSI bus. You need the logic analyser on the SPIFI chip!!!
As I already mentioned in another mail, I think, we
DO NOT access the real device. As I have mentioned,
we only read out 0x0000ff00 at each address and we
"write" the SCSI command in an invalid space ! So this
is "OK", that the chip do not produce any interrupts !
I think, this is a very basic problem of the bus or
i/o bus initilization or the Loquix init, or whatever.
I do not expect any frame on the SCSI output !
Bye
Christoph
Ryan Bradetich wrote:
>
> Hello Christoph,
>
> On Sun, 2002-09-15 at 17:25, Christoph Plattner wrote:
> > Hallo Ryan,
> >
> > here some comments on my non-successful work so far.
> >
> > I did code reading and used debug instrumented code
> > to understand the structure behind the linux SCSI
> > handling.
> >
> > Further I studied the NetBSD code.
> >
> > One major point: We do not get any interrupts.
> > For my analysis I only had a look on the first
> > steps of SCSI initialization, so this was the
> > INQUERY command.
>
> This is where I am also currently stuck :( The
> ESIEE guys are going to hook up an analyzer to the
> box and see if the target device is getting the command
> (ie... did we send the command correctly to the device)
> or if the device returns a command (do we catch the
> command the device is returning). I have been studyting
> the setup routines in the HP-UX driver and I believe
> I have the chip initialized properly ... but I am not
> sure why I am not getting any interrupts. Hopefully
> between ESIEE, you, and myself and anyone else
> interested we can figure this out.
>
> > The spifi command routine is called correctly,
> > but it has a wrong logical implementation. As I
> > have seen on other (older) linux driver, the
> > xxx_command() has to block, after the command was
> > successful completed by interrupt. But the interrupt
> > never comes !! Even a "long" delay for simulating
> > blocking does not solve this problem.
>
> That is highly possible. The driver skeleton is just
> a test harness for me right now. I am just trying to see
> what I can get returned from the spifi chip (that is why
> most of the functions are stubs with printk. Once I see
> an interrupt come in, I'll start working on putting that piece
> togeather.
>
> > From base of the NetBSD code, I cannot follow your
> > code resetting the spifi subsystem. I think you have
> > this from HP-UX code. Especially the
> >
> > __raw_writel(CMD_RESET, dev->hpa + IO_MODULE_COMMAND);
>
> Yes, this is part of the initizlization from the HP-UX
> driver. The Loquix chip sits between the HP-PB bus, and
> the spifi scsi chip. According to the HP-UX driver, the
> Loquix chip also required some setup. Once again, I
> do not actually have the Loquix documentation, but I might
> have a lead on it. Will have to wait and see if that lead
> pans out.
>
> > Is this a reset method via the IO PDC address space
> > common for all HP devices ? In the NetBSD the full
> > reset is done only via the `auxctrl' register, which
> > you use for releasing the reset state.
>
> I am not sure about all the HP devices. It might be an iodc
> specific call. I will have to look at the driver again,
> but that might reset the loquix chip *shrug* I'll take
> a look and see what I can find.
>
> > So we have a principal problem here, not having correct
> > access to the spifi subsystem. Except: the SCSI-ID is
> > read out correctly, I think, as ...
> >
> > SCSI subsystem driver Revision: 1.00
> > DEBUG: 0xfff74c00
> > Device: Sahp Baat Kiuh SCSI
> > scsi0 : SPIFI SCSI: scsi_id: 7 IRQ: 34 type: SPIFI-3 (SE) parity
> > checking: enabled
> >
> > ... is reported !
>
> That is where I am also. We actually read the type SPIFI-3 (SE) for the
> SKUNK card, and SPIFI-3 (DF) for the wizard (16-bit) card. I have
> tested this on both cards so I know it works. I am convinced we are
> reading the correct information from the card, but what I am not
> convinced of is that we have it setup properly yet :) The problem is I
> do not know what I am missing yet :(
>
> > Is everything around the interrupt subsystem setup correctly ?
> > The `cat /proc/interrupts' tells ...
> >
> > bash# cat /proc/interrupts
> > CPU396195552
> > 32: 124925 PARISC-CPU timer
> > 33: 19767 PARISC-CPU lasi
> > 34: 0 PARISC-CPU spifi
> > 87: 19767 Lasi i82596
> >
> > ... which is no surprise ... !
> >
>
> I do not think the fact the interrupt is registered is very infomative,
> I think you can register an interrupt for device even if it doesn't have
> an real irq assocaitated with it (ie... the serial mux).
>
> Yeah, thanks for looking at it ... we will have to beat on it some more
> and see what we can find. Hopefully the ESIEE guys will be able to
> provide us with some good information!
>
> Thanks
>
> - Ryan
>
> > Till soon,
> > Christoph P.
> >
> >
> >
> >
> >
> > --
> > -------------------------------------------------------
> > private: christoph.plattner@gmx.at
> > company: christoph.plattner@alcatel.at
> >
>
> _______________________________________________
> parisc-linux mailing list
> parisc-linux@lists.parisc-linux.org
> http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
--
-------------------------------------------------------
private: christoph.plattner@gmx.at
company: christoph.plattner@alcatel.at
From grundler@dsl2.external.hp.com Tue Sep 17 19:42:35 2002
From: grundler@dsl2.external.hp.com (Grant Grundler)
Date: Tue, 17 Sep 2002 12:42:35 -0600
Subject: [parisc-linux] Fwd: A500 hang up 2.4.19-pa18 (lot of) details
In-Reply-To: Message from Thibaut VARENE <varenet@esiee.fr>
of "Tue, 17 Sep 2002 19:16:52 +0200." <3D876384.1090200@esiee.fr>
References: <3D876384.1090200@esiee.fr>
Message-ID: <20020917184235.A1C054829@dsl2.external.hp.com>
Thibaut VARENE wrote:
> This a forward to the p-l.o m-l about hang-up with 2.4.19-pa18 kernel,
> that occurs when playing around with setiathome. See the transcript for
> details.
I tried the same thing with setiathome on A500-4X (PA8500) and it
seems to work fine.
Thibaut is using A500-5X (PA8600) - same cache sizes as PA8500.
I was wondering if the is a problem with 4-way associative cache
or just higher clock speeds exposing bugs.
grant
From varenet@esiee.fr Tue Sep 17 20:56:45 2002
From: varenet@esiee.fr (Thibaut VARENE)
Date: Tue, 17 Sep 2002 21:56:45 +0200
Subject: [parisc-linux] Re: Status SPIFI SCSI
In-Reply-To: <3D87756C.AFDA706B@gmx.at>
Message-ID: <98404C4A-CA77-11D6-8C42-0030656F07A2@esiee.fr>
Le mardi, 17 sep 2002, =E0 20:33 Europe/Paris, Christoph Plattner a =
=E9crit=20
:
Hi Christoph,
> Hello Ryan,
>
> I think usinf the logic analyser will not help you on the
> SCSI bus. You need the logic analyser on the SPIFI chip!!!
That's not a problem,
atm we have a 16channels analyser (we can have up to 128 if needed),
we tried using the HP 2423A SCSI preprocessor, but ours seems b0rken,
therefore we decided to plug directly onto the scsi board.
So plugging onto SPIFI chip shouldn't be a pb, as long as we have its=20
pinout,
so that we can isolate signals we're trying to find.
So if you can provide us with the pin numbers we should plug on,
that would help a lot ! :)
>
> As I already mentioned in another mail, I think, we
> DO NOT access the real device. As I have mentioned,
> we only read out 0x0000ff00 at each address and we
> "write" the SCSI command in an invalid space ! So this
> is "OK", that the chip do not produce any interrupts !
>
> I think, this is a very basic problem of the bus or
> i/o bus initilization or the Loquix init, or whatever.
>
> I do not expect any frame on the SCSI output !
>
> Bye
> Christoph
>
>
> Ryan Bradetich wrote:
>>
>> Hello Christoph,
>>
>> On Sun, 2002-09-15 at 17:25, Christoph Plattner wrote:
>>> Hallo Ryan,
>>>
>>> here some comments on my non-successful work so far.
>>>
>>> I did code reading and used debug instrumented code
>>> to understand the structure behind the linux SCSI
>>> handling.
>>>
>>> Further I studied the NetBSD code.
>>>
>>> One major point: We do not get any interrupts.
>>> For my analysis I only had a look on the first
>>> steps of SCSI initialization, so this was the
>>> INQUERY command.
>>
>> This is where I am also currently stuck :( The
>> ESIEE guys are going to hook up an analyzer to the
>> box and see if the target device is getting the command
>> (ie... did we send the command correctly to the device)
>> or if the device returns a command (do we catch the
>> command the device is returning). I have been studyting
>> the setup routines in the HP-UX driver and I believe
>> I have the chip initialized properly ... but I am not
>> sure why I am not getting any interrupts. Hopefully
>> between ESIEE, you, and myself and anyone else
>> interested we can figure this out.
>>
>>> The spifi command routine is called correctly,
>>> but it has a wrong logical implementation. As I
>>> have seen on other (older) linux driver, the
>>> xxx_command() has to block, after the command was
>>> successful completed by interrupt. But the interrupt
>>> never comes !! Even a "long" delay for simulating
>>> blocking does not solve this problem.
>>
>> That is highly possible. The driver skeleton is just
>> a test harness for me right now. I am just trying to see
>> what I can get returned from the spifi chip (that is why
>> most of the functions are stubs with printk. Once I see
>> an interrupt come in, I'll start working on putting that piece
>> togeather.
>>
>>> =46rom base of the NetBSD code, I cannot follow your
>>> code resetting the spifi subsystem. I think you have
>>> this from HP-UX code. Especially the
>>>
>>> __raw_writel(CMD_RESET, dev->hpa + IO_MODULE_COMMAND);
>>
>> Yes, this is part of the initizlization from the HP-UX
>> driver. The Loquix chip sits between the HP-PB bus, and
>> the spifi scsi chip. According to the HP-UX driver, the
>> Loquix chip also required some setup. Once again, I
>> do not actually have the Loquix documentation, but I might
>> have a lead on it. Will have to wait and see if that lead
>> pans out.
>>
>>> Is this a reset method via the IO PDC address space
>>> common for all HP devices ? In the NetBSD the full
>>> reset is done only via the `auxctrl' register, which
>>> you use for releasing the reset state.
>>
>> I am not sure about all the HP devices. It might be an iodc
>> specific call. I will have to look at the driver again,
>> but that might reset the loquix chip *shrug* I'll take
>> a look and see what I can find.
>>
>>> So we have a principal problem here, not having correct
>>> access to the spifi subsystem. Except: the SCSI-ID is
>>> read out correctly, I think, as ...
>>>
>>> SCSI subsystem driver Revision: 1.00
>>> DEBUG: 0xfff74c00
>>> Device: Sahp Baat Kiuh SCSI
>>> scsi0 : SPIFI SCSI: scsi_id: 7 IRQ: 34 type: SPIFI-3 (SE) parity
>>> checking: enabled
>>>
>>> ... is reported !
>>
>> That is where I am also. We actually read the type SPIFI-3 (SE) for=20=
>> the
>> SKUNK card, and SPIFI-3 (DF) for the wizard (16-bit) card. I have
>> tested this on both cards so I know it works. I am convinced we are
>> reading the correct information from the card, but what I am not
>> convinced of is that we have it setup properly yet :) The problem is=20=
>> I
>> do not know what I am missing yet :(
>>
>>> Is everything around the interrupt subsystem setup correctly ?
>>> The `cat /proc/interrupts' tells ...
>>>
>>> bash# cat /proc/interrupts
>>> CPU396195552
>>> 32: 124925 PARISC-CPU timer
>>> 33: 19767 PARISC-CPU lasi
>>> 34: 0 PARISC-CPU spifi
>>> 87: 19767 Lasi i82596
>>>
>>> ... which is no surprise ... !
>>>
>>
>> I do not think the fact the interrupt is registered is very=20
>> infomative,
>> I think you can register an interrupt for device even if it doesn't=20=
>> have
>> an real irq assocaitated with it (ie... the serial mux).
>>
>> Yeah, thanks for looking at it ... we will have to beat on it some=20
>> more
>> and see what we can find. Hopefully the ESIEE guys will be able to
>> provide us with some good information!
>>
>> Thanks
>>
>> - Ryan
>>
>>> Till soon,
>>> Christoph P.
>>>
>>>
>>>
>>>
>>>
>>> --
>>> -------------------------------------------------------
>>> private: christoph.plattner@gmx.at
>>> company: christoph.plattner@alcatel.at
>>>
>>
>> _______________________________________________
>> parisc-linux mailing list
>> parisc-linux@lists.parisc-linux.org
>> http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
>
> --=20
> -------------------------------------------------------
> private: christoph.plattner@gmx.at
> company: christoph.plattner@alcatel.at
> _______________________________________________
> parisc-linux mailing list
> parisc-linux@lists.parisc-linux.org
> http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
From christoph.plattner@gmx.at Tue Sep 17 22:31:28 2002
From: christoph.plattner@gmx.at (Christoph Plattner)
Date: Tue, 17 Sep 2002 23:31:28 +0200
Subject: [parisc-linux] Re: Status SPIFI SCSI
References: <98404C4A-CA77-11D6-8C42-0030656F07A2@esiee.fr>
Message-ID: <3D879F30.5D9A928C@gmx.at>
Hello,
the problem I wanted to point out is, that not the SCSI
interface problem is the point.
IMO we have a simple (take the word "simple" not too
critical ...) software setup problem. It seems, that
we do not access the chip physically.
I have no NDA, I have no possibility to look into the
source codes of HP-UX (but I want to have it !!), I have
no hardware docu, no chip docu (although I am able to
read them and I want to have access), so my help here
is very restricted !!!
But one small hint: The "chip selelct" line and the
low order address bits, to see if there is really a
hardware access to this chip. Further perhaps the
read and write control line. I do not know the
HP own bus system (I also miss such documentation),
but I use simple the words of a standard bus access
(RD, WR, CS or CE, address lines, data lines).
HOW CAN I GET DOCUMENTATIONS ????
Bye
Christoph
Thibaut VARENE wrote:
>
> Le mardi, 17 sep 2002, à 20:33 Europe/Paris, Christoph Plattner a écrit
> :
>
> Hi Christoph,
> > Hello Ryan,
> >
> > I think usinf the logic analyser will not help you on the
> > SCSI bus. You need the logic analyser on the SPIFI chip!!!
> That's not a problem,
> atm we have a 16channels analyser (we can have up to 128 if needed),
> we tried using the HP 2423A SCSI preprocessor, but ours seems b0rken,
> therefore we decided to plug directly onto the scsi board.
>
> So plugging onto SPIFI chip shouldn't be a pb, as long as we have its
> pinout,
> so that we can isolate signals we're trying to find.
>
> So if you can provide us with the pin numbers we should plug on,
> that would help a lot ! :)
> >
> > As I already mentioned in another mail, I think, we
> > DO NOT access the real device. As I have mentioned,
> > we only read out 0x0000ff00 at each address and we
> > "write" the SCSI command in an invalid space ! So this
> > is "OK", that the chip do not produce any interrupts !
> >
> > I think, this is a very basic problem of the bus or
> > i/o bus initilization or the Loquix init, or whatever.
> >
> > I do not expect any frame on the SCSI output !
> >
> > Bye
> > Christoph
> >
> >
> > Ryan Bradetich wrote:
> >>
> >> Hello Christoph,
> >>
> >> On Sun, 2002-09-15 at 17:25, Christoph Plattner wrote:
> >>> Hallo Ryan,
> >>>
> >>> here some comments on my non-successful work so far.
> >>>
> >>> I did code reading and used debug instrumented code
> >>> to understand the structure behind the linux SCSI
> >>> handling.
> >>>
> >>> Further I studied the NetBSD code.
> >>>
> >>> One major point: We do not get any interrupts.
> >>> For my analysis I only had a look on the first
> >>> steps of SCSI initialization, so this was the
> >>> INQUERY command.
> >>
> >> This is where I am also currently stuck :( The
> >> ESIEE guys are going to hook up an analyzer to the
> >> box and see if the target device is getting the command
> >> (ie... did we send the command correctly to the device)
> >> or if the device returns a command (do we catch the
> >> command the device is returning). I have been studyting
> >> the setup routines in the HP-UX driver and I believe
> >> I have the chip initialized properly ... but I am not
> >> sure why I am not getting any interrupts. Hopefully
> >> between ESIEE, you, and myself and anyone else
> >> interested we can figure this out.
> >>
> >>> The spifi command routine is called correctly,
> >>> but it has a wrong logical implementation. As I
> >>> have seen on other (older) linux driver, the
> >>> xxx_command() has to block, after the command was
> >>> successful completed by interrupt. But the interrupt
> >>> never comes !! Even a "long" delay for simulating
> >>> blocking does not solve this problem.
> >>
> >> That is highly possible. The driver skeleton is just
> >> a test harness for me right now. I am just trying to see
> >> what I can get returned from the spifi chip (that is why
> >> most of the functions are stubs with printk. Once I see
> >> an interrupt come in, I'll start working on putting that piece
> >> togeather.
> >>
> >>> From base of the NetBSD code, I cannot follow your
> >>> code resetting the spifi subsystem. I think you have
> >>> this from HP-UX code. Especially the
> >>>
> >>> __raw_writel(CMD_RESET, dev->hpa + IO_MODULE_COMMAND);
> >>
> >> Yes, this is part of the initizlization from the HP-UX
> >> driver. The Loquix chip sits between the HP-PB bus, and
> >> the spifi scsi chip. According to the HP-UX driver, the
> >> Loquix chip also required some setup. Once again, I
> >> do not actually have the Loquix documentation, but I might
> >> have a lead on it. Will have to wait and see if that lead
> >> pans out.
> >>
> >>> Is this a reset method via the IO PDC address space
> >>> common for all HP devices ? In the NetBSD the full
> >>> reset is done only via the `auxctrl' register, which
> >>> you use for releasing the reset state.
> >>
> >> I am not sure about all the HP devices. It might be an iodc
> >> specific call. I will have to look at the driver again,
> >> but that might reset the loquix chip *shrug* I'll take
> >> a look and see what I can find.
> >>
> >>> So we have a principal problem here, not having correct
> >>> access to the spifi subsystem. Except: the SCSI-ID is
> >>> read out correctly, I think, as ...
> >>>
> >>> SCSI subsystem driver Revision: 1.00
> >>> DEBUG: 0xfff74c00
> >>> Device: Sahp Baat Kiuh SCSI
> >>> scsi0 : SPIFI SCSI: scsi_id: 7 IRQ: 34 type: SPIFI-3 (SE) parity
> >>> checking: enabled
> >>>
> >>> ... is reported !
> >>
> >> That is where I am also. We actually read the type SPIFI-3 (SE) for
> >> the
> >> SKUNK card, and SPIFI-3 (DF) for the wizard (16-bit) card. I have
> >> tested this on both cards so I know it works. I am convinced we are
> >> reading the correct information from the card, but what I am not
> >> convinced of is that we have it setup properly yet :) The problem is
> >> I
> >> do not know what I am missing yet :(
> >>
> >>> Is everything around the interrupt subsystem setup correctly ?
> >>> The `cat /proc/interrupts' tells ...
> >>>
> >>> bash# cat /proc/interrupts
> >>> CPU396195552
> >>> 32: 124925 PARISC-CPU timer
> >>> 33: 19767 PARISC-CPU lasi
> >>> 34: 0 PARISC-CPU spifi
> >>> 87: 19767 Lasi i82596
> >>>
> >>> ... which is no surprise ... !
> >>>
> >>
> >> I do not think the fact the interrupt is registered is very
> >> infomative,
> >> I think you can register an interrupt for device even if it doesn't
> >> have
> >> an real irq assocaitated with it (ie... the serial mux).
> >>
> >> Yeah, thanks for looking at it ... we will have to beat on it some
> >> more
> >> and see what we can find. Hopefully the ESIEE guys will be able to
> >> provide us with some good information!
> >>
> >> Thanks
> >>
> >> - Ryan
> >>
> >>> Till soon,
> >>> Christoph P.
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> --
> >>> -------------------------------------------------------
> >>> private: christoph.plattner@gmx.at
> >>> company: christoph.plattner@alcatel.at
> >>>
> >>
> >> _______________________________________________
> >> parisc-linux mailing list
> >> parisc-linux@lists.parisc-linux.org
> >> http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
> >
> > --
> > -------------------------------------------------------
> > private: christoph.plattner@gmx.at
> > company: christoph.plattner@alcatel.at
> > _______________________________________________
> > parisc-linux mailing list
> > parisc-linux@lists.parisc-linux.org
> > http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
--
-------------------------------------------------------
private: christoph.plattner@gmx.at
company: christoph.plattner@alcatel.at
From varenet@esiee.fr Tue Sep 17 22:43:49 2002
From: varenet@esiee.fr (Thibaut VARENE)
Date: Tue, 17 Sep 2002 23:43:49 +0200
Subject: [parisc-linux] Re: Status SPIFI SCSI
In-Reply-To: <3D879F30.5D9A928C@gmx.at>
Message-ID: <8CCD3676-CA86-11D6-8C42-0030656F07A2@esiee.fr>
Le mardi, 17 sep 2002, =E0 23:31 Europe/Paris, Christoph Plattner a =
=E9crit=20
:
> Hello,
>
> the problem I wanted to point out is, that not the SCSI
> interface problem is the point.
yes i got that.
>
> IMO we have a simple (take the word "simple" not too
> critical ...) software setup problem. It seems, that
> we do not access the chip physically.
ok
>
> I have no NDA, I have no possibility to look into the
> source codes of HP-UX (but I want to have it !!), I have
> no hardware docu, no chip docu (although I am able to
> read them and I want to have access), so my help here
> is very restricted !!!
Alas, it looks like we're all in the same case here...
>
> But one small hint: The "chip selelct" line and the
> low order address bits, to see if there is really a
> hardware access to this chip. Further perhaps the
> read and write control line. I do not know the
I agree on the fact that CS;R/W; and other signal are
mandatory to trace chip activity, but if we don't have
a somehow precise pinout, it will be helpless...
We can eventually trace all pins of the chipset, but if
we don't know what is what, that won't be useful.
> HP own bus system (I also miss such documentation),
> but I use simple the words of a standard bus access
> (RD, WR, CS or CE, address lines, data lines).
>
> HOW CAN I GET DOCUMENTATIONS ????
Alas, they're all "for your eyes only".
We've been fighting with such a problem for ages.
We have lots of old 725 cards (SCSI, ATM and others)
for which we couldn't developp driver since we didn't have
any doc.
Same for newest graphic cards (FX series)...
If someone can help on that point, that would be really
awesome.
Of course we (at ESIEE) are ready to sign a NDA...
>
> Bye
> Christoph
>
Thibaut.
>
>
> Thibaut VARENE wrote:
>>
>> Le mardi, 17 sep 2002, =E0 20:33 Europe/Paris, Christoph Plattner a=20=
>> =E9crit
>> :
>>
>> Hi Christoph,
>>> Hello Ryan,
>>>
>>> I think usinf the logic analyser will not help you on the
>>> SCSI bus. You need the logic analyser on the SPIFI chip!!!
>> That's not a problem,
>> atm we have a 16channels analyser (we can have up to 128 if needed),
>> we tried using the HP 2423A SCSI preprocessor, but ours seems b0rken,
>> therefore we decided to plug directly onto the scsi board.
>>
>> So plugging onto SPIFI chip shouldn't be a pb, as long as we have its
>> pinout,
>> so that we can isolate signals we're trying to find.
>>
>> So if you can provide us with the pin numbers we should plug on,
>> that would help a lot ! :)
>>>
>>> As I already mentioned in another mail, I think, we
>>> DO NOT access the real device. As I have mentioned,
>>> we only read out 0x0000ff00 at each address and we
>>> "write" the SCSI command in an invalid space ! So this
>>> is "OK", that the chip do not produce any interrupts !
>>>
>>> I think, this is a very basic problem of the bus or
>>> i/o bus initilization or the Loquix init, or whatever.
>>>
>>> I do not expect any frame on the SCSI output !
>>>
>>> Bye
>>> Christoph
>>>
>>>
>>> Ryan Bradetich wrote:
>>>>
>>>> Hello Christoph,
>>>>
>>>> On Sun, 2002-09-15 at 17:25, Christoph Plattner wrote:
>>>>> Hallo Ryan,
>>>>>
>>>>> here some comments on my non-successful work so far.
>>>>>
>>>>> I did code reading and used debug instrumented code
>>>>> to understand the structure behind the linux SCSI
>>>>> handling.
>>>>>
>>>>> Further I studied the NetBSD code.
>>>>>
>>>>> One major point: We do not get any interrupts.
>>>>> For my analysis I only had a look on the first
>>>>> steps of SCSI initialization, so this was the
>>>>> INQUERY command.
>>>>
>>>> This is where I am also currently stuck :( The
>>>> ESIEE guys are going to hook up an analyzer to the
>>>> box and see if the target device is getting the command
>>>> (ie... did we send the command correctly to the device)
>>>> or if the device returns a command (do we catch the
>>>> command the device is returning). I have been studyting
>>>> the setup routines in the HP-UX driver and I believe
>>>> I have the chip initialized properly ... but I am not
>>>> sure why I am not getting any interrupts. Hopefully
>>>> between ESIEE, you, and myself and anyone else
>>>> interested we can figure this out.
>>>>
>>>>> The spifi command routine is called correctly,
>>>>> but it has a wrong logical implementation. As I
>>>>> have seen on other (older) linux driver, the
>>>>> xxx_command() has to block, after the command was
>>>>> successful completed by interrupt. But the interrupt
>>>>> never comes !! Even a "long" delay for simulating
>>>>> blocking does not solve this problem.
>>>>
>>>> That is highly possible. The driver skeleton is just
>>>> a test harness for me right now. I am just trying to see
>>>> what I can get returned from the spifi chip (that is why
>>>> most of the functions are stubs with printk. Once I see
>>>> an interrupt come in, I'll start working on putting that piece
>>>> togeather.
>>>>
>>>>> =46rom base of the NetBSD code, I cannot follow your
>>>>> code resetting the spifi subsystem. I think you have
>>>>> this from HP-UX code. Especially the
>>>>>
>>>>> __raw_writel(CMD_RESET, dev->hpa + IO_MODULE_COMMAND);
>>>>
>>>> Yes, this is part of the initizlization from the HP-UX
>>>> driver. The Loquix chip sits between the HP-PB bus, and
>>>> the spifi scsi chip. According to the HP-UX driver, the
>>>> Loquix chip also required some setup. Once again, I
>>>> do not actually have the Loquix documentation, but I might
>>>> have a lead on it. Will have to wait and see if that lead
>>>> pans out.
>>>>
>>>>> Is this a reset method via the IO PDC address space
>>>>> common for all HP devices ? In the NetBSD the full
>>>>> reset is done only via the `auxctrl' register, which
>>>>> you use for releasing the reset state.
>>>>
>>>> I am not sure about all the HP devices. It might be an iodc
>>>> specific call. I will have to look at the driver again,
>>>> but that might reset the loquix chip *shrug* I'll take
>>>> a look and see what I can find.
>>>>
>>>>> So we have a principal problem here, not having correct
>>>>> access to the spifi subsystem. Except: the SCSI-ID is
>>>>> read out correctly, I think, as ...
>>>>>
>>>>> SCSI subsystem driver Revision: 1.00
>>>>> DEBUG: 0xfff74c00
>>>>> Device: Sahp Baat Kiuh SCSI
>>>>> scsi0 : SPIFI SCSI: scsi_id: 7 IRQ: 34 type: SPIFI-3 (SE) parity
>>>>> checking: enabled
>>>>>
>>>>> ... is reported !
>>>>
>>>> That is where I am also. We actually read the type SPIFI-3 (SE) for
>>>> the
>>>> SKUNK card, and SPIFI-3 (DF) for the wizard (16-bit) card. I have
>>>> tested this on both cards so I know it works. I am convinced we =
are
>>>> reading the correct information from the card, but what I am not
>>>> convinced of is that we have it setup properly yet :) The problem=20=
>>>> is
>>>> I
>>>> do not know what I am missing yet :(
>>>>
>>>>> Is everything around the interrupt subsystem setup correctly ?
>>>>> The `cat /proc/interrupts' tells ...
>>>>>
>>>>> bash# cat /proc/interrupts
>>>>> CPU396195552
>>>>> 32: 124925 PARISC-CPU timer
>>>>> 33: 19767 PARISC-CPU lasi
>>>>> 34: 0 PARISC-CPU spifi
>>>>> 87: 19767 Lasi i82596
>>>>>
>>>>> ... which is no surprise ... !
>>>>>
>>>>
>>>> I do not think the fact the interrupt is registered is very
>>>> infomative,
>>>> I think you can register an interrupt for device even if it doesn't
>>>> have
>>>> an real irq assocaitated with it (ie... the serial mux).
>>>>
>>>> Yeah, thanks for looking at it ... we will have to beat on it some
>>>> more
>>>> and see what we can find. Hopefully the ESIEE guys will be able to
>>>> provide us with some good information!
>>>>
>>>> Thanks
>>>>
>>>> - Ryan
>>>>
>>>>> Till soon,
>>>>> Christoph P.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> -------------------------------------------------------
>>>>> private: christoph.plattner@gmx.at
>>>>> company: christoph.plattner@alcatel.at
>>>>>
>>>>
>>>> _______________________________________________
>>>> parisc-linux mailing list
>>>> parisc-linux@lists.parisc-linux.org
>>>> http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
>>>
>>> --
>>> -------------------------------------------------------
>>> private: christoph.plattner@gmx.at
>>> company: christoph.plattner@alcatel.at
>>> _______________________________________________
>>> parisc-linux mailing list
>>> parisc-linux@lists.parisc-linux.org
>>> http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
>
> --=20
> -------------------------------------------------------
> private: christoph.plattner@gmx.at
> company: christoph.plattner@alcatel.at
> _______________________________________________
> parisc-linux mailing list
> parisc-linux@lists.parisc-linux.org
> http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
From dannf@fc.hp.com Tue Sep 17 22:53:31 2002
From: dannf@fc.hp.com (dann)
Date: Tue, 17 Sep 2002 15:53:31 -0600
Subject: [parisc-linux] Re: [lists] installing Linux on A Visualise C240
In-Reply-To: <DAV71Y9P3bVYbrNQrl50000bc9b@hotmail.com>
References: <DAV71Y9P3bVYbrNQrl50000bc9b@hotmail.com>
Message-ID: <20020917215331.GE19148@fc.hp.com>
Yves,
forwarding to the parisc-linux, which is a more appropriate place
for this question.
as an aside, 0.9.3 is not the latest release - debian 3.0 contains newer bits.
<hint>maybe one of these days someone will point that out on -announce</hint>
On Tue, Sep 17, 2002 at 11:46:39PM +0200, Yves Vrijhoeven wrote:
> Hi,
>
> I downloaded the "palinux-0.9.3.iso" and burned it to CD. If I put the CD in PA RISC powerd PC (Visualise C240) and boot with the command "bo sescsi.3.0" the PC seems to boot from the CD (I get somewhere the message "palo ipl 0.96 root@palinux Fri Nov 2 16:31:18 MST 2001" ...(clock setting is not correct))
> Everything seems ok until I get the message:
> ...
> Branching to kernel entry point 0x00100000. If this is the last message you see, you may need to switch your console. This is a common sympton -- sarch the FAQ and mailing list at parisc-linux.org
>
> After this nothing happens anymore. I searched the FAQ and mailing list but I could not find a solution so far.
>
> Anyone can help me out on this.
>
> Thanks in advance.
>
> Please E-mail me.
>
> Yves Vrijhoeven
> yves.vrijhoeven@belgacom.net
> yvesvrijhoeven@belgacom.net
--
---------------------------
dann frazier
Hewlett-Packard
Linux Systems Division
dannf@hp.com
(970) 898-0800
From joel.soete@freebel.net Wed Sep 18 00:46:03 2002
From: joel.soete@freebel.net (Joel Soete)
Date: Tue, 17 Sep 2002 23:46:03 +0000
Subject: [parisc-linux] Re: [lists] installing Linux on A Visualise C240
References: <DAV71Y9P3bVYbrNQrl50000bc9b@hotmail.com> <20020917215331.GE19148@fc.hp.com>
Message-ID: <3D87BEBB.5080306@freebel.net>
dann wrote:
> Yves,
> forwarding to the parisc-linux, which is a more appropriate place
> for this question.
>
> as an aside, 0.9.3 is not the latest release - debian 3.0 contains newer bits.
> <hint>maybe one of these days someone will point that out on -announce</hint>
Dann you have right 0.9.3 iso is quiet old and Debian3.0r0 iso are
referenced on :http://www.parisc-linux.org/index.html (i do not find it
any more on .de? but well on .se)
As well as the net install iso (when it is possible to install over a
network connection) which offer the advantage to propose the last
development kernel :)
Yves, good luck
Joel
From Joshua.Speer@corp.winfirst.com Tue Sep 17 23:52:18 2002
From: Joshua.Speer@corp.winfirst.com (Speer, Joshua)
Date: Tue, 17 Sep 2002 15:52:18 -0700
Subject: [parisc-linux] Re: [lists] installing Linux on A Visualise C2
40
Message-ID: <95DAF5BCC67DD411957B00508BAECA3ACD35B7@MT_BELFORD>
We had the same problem on a L9000 we put the octopus cable on the server,
and a console cable on the console port, and everything worked fine.
Josh
-----Original Message-----
From: dannf@fc.hp.com [mailto:dannf@fc.hp.com]
Sent: Tuesday, September 17, 2002 2:54 PM
To: Yves Vrijhoeven; parisc-linux@lists.parisc-linux.org
Subject: [parisc-linux] Re: [lists] installing Linux on A Visualise C240
Yves,
forwarding to the parisc-linux, which is a more appropriate place
for this question.
as an aside, 0.9.3 is not the latest release - debian 3.0 contains newer
bits.
<hint>maybe one of these days someone will point that out on
-announce</hint>
On Tue, Sep 17, 2002 at 11:46:39PM +0200, Yves Vrijhoeven wrote:
> Hi,
>
> I downloaded the "palinux-0.9.3.iso" and burned it to CD. If I put the CD
in PA RISC powerd PC (Visualise C240) and boot with the command "bo
sescsi.3.0" the PC seems to boot from the CD (I get somewhere the message
"palo ipl 0.96 root@palinux Fri Nov 2 16:31:18 MST 2001" ...(clock setting
is not correct))
> Everything seems ok until I get the message:
> ...
> Branching to kernel entry point 0x00100000. If this is the last message
you see, you may need to switch your console. This is a common sympton --
sarch the FAQ and mailing list at parisc-linux.org
>
> After this nothing happens anymore. I searched the FAQ and mailing list
but I could not find a solution so far.
>
> Anyone can help me out on this.
>
> Thanks in advance.
>
> Please E-mail me.
>
> Yves Vrijhoeven
> yves.vrijhoeven@belgacom.net
> yvesvrijhoeven@belgacom.net
--
---------------------------
dann frazier
Hewlett-Packard
Linux Systems Division
dannf@hp.com
(970) 898-0800
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.386 / Virus Database: 218 - Release Date: 9/9/2002
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.386 / Virus Database: 218 - Release Date: 9/9/2002
From carlos@baldric.uwo.ca Wed Sep 18 02:02:09 2002
From: carlos@baldric.uwo.ca (Carlos O'Donell)
Date: Tue, 17 Sep 2002 21:02:09 -0400
Subject: [parisc-linux] B132L+ crash with mpg123
In-Reply-To: <20020917180713.P10583@parcelfarce.linux.theplanet.co.uk>
References: <3D8701AA.4040700@esiee.fr> <varenet@esiee.fr> <20020917170001.DA8DC4829@dsl2.external.hp.com> <20020917180713.P10583@parcelfarce.linux.theplanet.co.uk>
Message-ID: <20020918010209.GC17211@systemhalted>
> > > Kernel Fault: Code=15 regs=11ddc640 (Addr=00277e00)
> > >
> > > YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
> > > PSW: 00000000000011000000000000001111 Not tainted
> > > r00-03 00000000 00000023 101feac4 00000200
> > ...
> > > IASQ: 00000000 0000000 IAOQ: 10263c78 10263c70
> > ...
> > what symbols do 101feac4 and 10263c78 refer to?
>
> 10263c78 is in copy_from_user, 101feac4 is in harmony_audio_write().
> the only point at which we call copy_from_user is:
>
> /* Copy the page to an aligned buffer */
> copy_from_user(played_buf.addr + (HARMONY_BUF_SIZE*buf_to_fill)
> + harmony.play_offset,
> buffer+count, frame_size);
>
Data TLB miss fault / Data page fault.
Looks like it walked a little too far into some address that
wasn't mapped?
c.
From derekengelhaupt@rocketmail.com Wed Sep 18 02:28:51 2002
From: derekengelhaupt@rocketmail.com (Derek Engelhaupt)
Date: Tue, 17 Sep 2002 18:28:51 -0700 (PDT)
Subject: [parisc-linux] Re: [lists] installing Linux on A Visualise C240
In-Reply-To: <3D87BEBB.5080306@freebel.net>
Message-ID: <20020918012851.16678.qmail@web12502.mail.yahoo.com>
Yves,
I had this same issue with my C180 workstation when booting from my
graphics card loaded in the card cage. I was able to get the system to
work using my onboard graphics port, but the C240 does not have an
onboard graphics port. My external graphics card is not supported
(A4071A). More than likely you have a graphics card in there that is
not supported yet and more than likely never will be. There is little
information about HP graphics cards out there in order to write the
drivers for them. If you could give us the product number of the card
we could tell you whether or not it is a supported card. If it is
supported there is a configuration in the boot handler that is not
correct. The product number is a letter followed by 4 number then a
letter (ex: A3312A) if you aren't familier with HP product codes.
derek
--- Joel Soete <joel.soete@freebel.net> wrote:
>
>
> dann wrote:
> > Yves,
> > forwarding to the parisc-linux, which is a more appropriate place
> > for this question.
> >
> > as an aside, 0.9.3 is not the latest release - debian 3.0 contains
> newer bits.
> > <hint>maybe one of these days someone will point that out on
> -announce</hint>
>
> Dann you have right 0.9.3 iso is quiet old and Debian3.0r0 iso are
> referenced on :http://www.parisc-linux.org/index.html (i do not find
> it
> any more on .de? but well on .se)
>
> As well as the net install iso (when it is possible to install over a
>
> network connection) which offer the advantage to propose the last
> development kernel :)
>
> Yves, good luck
>
> Joel
>
> _______________________________________________
> parisc-linux mailing list
> parisc-linux@lists.parisc-linux.org
> http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
__________________________________________________
Do you Yahoo!?
Yahoo! News - Today's headlines
http://news.yahoo.com
From derekengelhaupt@rocketmail.com Wed Sep 18 02:37:04 2002
From: derekengelhaupt@rocketmail.com (Derek Engelhaupt)
Date: Tue, 17 Sep 2002 18:37:04 -0700 (PDT)
Subject: [parisc-linux] Re: Status SPIFI SCSI
In-Reply-To: <98404C4A-CA77-11D6-8C42-0030656F07A2@esiee.fr>
Message-ID: <20020918013704.37761.qmail@web12504.mail.yahoo.com>
Good luck trying to find a pinout for the chips on the cards....I can't
even find a block diagram of the cards on the HP internal websites. As
a sidenote, I was talking to one of my customers this evening that had
dealings with a contractor to HP that was involved in the original
development of the HP-PB devices. I found an E-mail address for him in
the HP address book and asked him if he would mind us bouncing ideas
off of him. Waiting to see what he says or if I get a responce.
derek
--- Thibaut VARENE <varenet@esiee.fr> wrote:
>
> Le mardi, 17 sep 2002, à 20:33 Europe/Paris, Christoph Plattner a
> écrit
> :
>
> Hi Christoph,
> > Hello Ryan,
> >
> > I think usinf the logic analyser will not help you on the
> > SCSI bus. You need the logic analyser on the SPIFI chip!!!
> That's not a problem,
> atm we have a 16channels analyser (we can have up to 128 if needed),
> we tried using the HP 2423A SCSI preprocessor, but ours seems b0rken,
> therefore we decided to plug directly onto the scsi board.
>
> So plugging onto SPIFI chip shouldn't be a pb, as long as we have its
>
> pinout,
> so that we can isolate signals we're trying to find.
>
> So if you can provide us with the pin numbers we should plug on,
> that would help a lot ! :)
> >
> > As I already mentioned in another mail, I think, we
> > DO NOT access the real device. As I have mentioned,
> > we only read out 0x0000ff00 at each address and we
> > "write" the SCSI command in an invalid space ! So this
> > is "OK", that the chip do not produce any interrupts !
> >
> > I think, this is a very basic problem of the bus or
> > i/o bus initilization or the Loquix init, or whatever.
> >
> > I do not expect any frame on the SCSI output !
> >
> > Bye
> > Christoph
> >
> >
__________________________________________________
Do you Yahoo!?
Yahoo! News - Today's headlines
http://news.yahoo.com
From varenet@esiee.fr Wed Sep 18 08:39:06 2002
From: varenet@esiee.fr (Thibaut VARENE)
Date: Wed, 18 Sep 2002 09:39:06 +0200
Subject: [parisc-linux] B132L+ crash with mpg123
In-Reply-To: <20020918010209.GC17211@systemhalted>
Message-ID: <B5FF03DC-CAD9-11D6-A4F6-0030656F07A2@esiee.fr>
Le mercredi, 18 sep 2002, =E0 03:02 Europe/Paris, Carlos O'Donell a =
=E9crit=20
:
>>>> Kernel Fault: Code=3D15 regs=3D11ddc640 (Addr=3D00277e00)
>>>>
>>>> YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
>>>> PSW: 00000000000011000000000000001111 Not tainted
>>>> r00-03 00000000 00000023 101feac4 00000200
>>> ...
>>>> IASQ: 00000000 0000000 IAOQ: 10263c78 10263c70
>>> ...
>>> what symbols do 101feac4 and 10263c78 refer to?
>>
>> 10263c78 is in copy_from_user, 101feac4 is in harmony_audio_write().
>> the only point at which we call copy_from_user is:
>>
>> /* Copy the page to an aligned buffer */
>> copy_from_user(played_buf.addr +=20
>> (HARMONY_BUF_SIZE*buf_to_fill)
>> + harmony.play_offset,
>> buffer+count, frame_size);
>>
>
> Data TLB miss fault / Data page fault.
>
> Looks like it walked a little too far into some address that
> wasn't mapped?
Yeah,
I caught Matthieu Delahaye lately, he told me that it was probably a
failing "modulo" on the calculation of the remaining size of buffer
to be sent to the audio card, or something like that...
>
> c.
Thibaut VARENE
PA/Linux ESIEE Team
http://pateam.esiee.fr/=
From derekengelhaupt@rocketmail.com Wed Sep 18 17:52:34 2002
From: derekengelhaupt@rocketmail.com (Derek Engelhaupt)
Date: Wed, 18 Sep 2002 09:52:34 -0700 (PDT)
Subject: [parisc-linux] With all this talk about graphics...
In-Reply-To: <3D87BEBB.5080306@freebel.net>
Message-ID: <20020918165234.88989.qmail@web12505.mail.yahoo.com>
Well I was actually looking for something else when I ran across these
two links. I don't know if they are helpful or if they have already
been referenced as far as creating drivers for some of the older and
newer graphics cards. Since I'm not a software guy I wasn't aware if
they would be helpful or not.
http://docs.hp.com/cgi-bin/onlinedocs.py?mpn=B2355-90142&service=hpux&path=../B2355-90142/00/00/1&title=Graphics%20Administration%20Guide
http://docs.hp.com/cgi-bin/onlinedocs.py?mpn=B2355-90143&service=hpux&path=../B2355-90143/00/00/1&title=Starbase%20Technical%20Addendum%20for%20the%20July%2C%201997%20Workstation%20ACE%20for%20HP-UX%2010.20
derek
__________________________________________________
Do you Yahoo!?
Yahoo! News - Today's headlines
http://news.yahoo.com
From stephan@itp.bg Wed Sep 18 20:32:58 2002
From: stephan@itp.bg (Stephan Trajkoff)
Date: Wed, 18 Sep 2002 22:32:58 +0300
Subject: [parisc-linux] anybody has succefully compiled Mysql-3.23.49 from debian source
Message-ID: <20020918193205.597D04829@dsl2.external.hp.com>
-------------------------------------------------------------------
-->> FREE Perl CGI scripts add WEB ACCESS to your POP email accounts!
-->> Download today!! http://www.adjeweb.com
-------------------------------------------------------------------
Hi, I tried to compile mysql-3.23.49, but no good result, there are=20
many errors in compiling with libraries. I do dist-upgrade every week
From joey@infodrom.org Wed Sep 18 20:48:22 2002
From: joey@infodrom.org (Martin Schulze)
Date: Wed, 18 Sep 2002 21:48:22 +0200
Subject: [parisc-linux] Re: anybody has succefully compiled Mysql-3.23.49 from debian source
In-Reply-To: <20020918193205.597D04829@dsl2.external.hp.com>
References: <20020918193205.597D04829@dsl2.external.hp.com>
Message-ID: <20020918194822.GR30868@finlandia.infodrom.north.de>
Stephan Trajkoff wrote:
>
> -------------------------------------------------------------------
> -->> FREE Perl CGI scripts add WEB ACCESS to your POP email accounts!
> -->> Download today!! http://www.adjeweb.com
> -------------------------------------------------------------------
>
> Hi, I tried to compile mysql-3.23.49, but no good result, there are
> many errors in compiling with libraries. I do dist-upgrade every week
Why don't you use the package provided by Debian?
libmysqlclient10-dev stable 3.23.49-8 hppa
libmysqlclient10 stable 3.23.49-8 hppa
mysql-client stable 3.23.49-8 hppa
mysql-server stable 3.23.49-8 hppa
i.e. use apt-get install ...
Regards,
Joey
--
Whenever you meet yourself you're in a time loop or in front of a mirror.
From frts@simba.sch.bme.hu Thu Sep 19 08:38:31 2002
From: frts@simba.sch.bme.hu (Istvan Gyenes)
Date: Thu, 19 Sep 2002 09:38:31 +0200 (MET DST)
Subject: [parisc-linux] SMP kernel problems on a D350
Message-ID: <Pine.OSF.4.33.0209190926170.32375-100000@simba.sch.bme.hu>
Hello List,
I'm trying to compile an SMP kernel for my D 350 (2cpu) server without
success.
The kernel source is 2.4.19-pa18 and in non-smp configuration it works
well. Anyway the SMP kernel compiles fine but when I try to boot it
stops at the "If this is the last message you see, you may need to switch
your console" line. I've switched the console but got no other output.
(It was the same with 2.4.19-pa14)
The system was installed from a debian 3.0 CD.
Can somebody send me a working .config? Or what can be the problem?
Thanks in advance,
__
Steve
From j.steindlberger@gmx.de Thu Sep 19 09:41:14 2002
From: j.steindlberger@gmx.de (j.steindlberger@gmx.de)
Date: Thu, 19 Sep 2002 10:41:14 +0200 (MEST)
Subject: [parisc-linux] ide controller
References: <20020916043004.B27754829@dsl2.external.hp.com>
Message-ID: <28859.1032424874@www2.gmx.net>
Hi Grant,
together with Moritz I/we tried to get some new results. We took the latest
kernel (-pa18) and did the changes to the PDC202XX-definitions in pdc202xx.c.
But I don't believe that the kernel gets the chance to recognice this
change. I think the kernel crashes earlier. We reduced the kernel by the specific
drivers. We disabled the following:
[ ] Generic PCI bus-master DMA support
After compiling wie had these three modules:
ide-mod.o
ide-probe-mod.o
ide-disk.o
An insmod ide-mod.o was possible. But after insmod ide-probe-mod the kernel
crashes. In some cases we got an output with about 50 pages of memory
addresses. At the beginning we got some messages told about the SYM-SCSI-device.
Could that be a conflict? We did not succeed to reproduce that and log it.
Here my questions:
Did You here about anyone to succeed in using an IDE-controller in a
HP-RISC-architecture?
Do You see a chance to use IDE-disks in future (with some none
HP-controller)
Do You know about more people who are interrested in what we tried to do?
That would be an argument for me to continue experimenting.
Thank You
Joerg
> #define PDC202XX_DEBUG_DRIVE_INFO 0
> #define PDC202XX_DECODE_REGISTER_INFO 0
>
> and rebuild the module with that.
>
> 3) post the console log and "ser pim" output at PDC prompt.
--
GMX - Die Kommunikationsplattform im Internet.
http://www.gmx.net
From frts@simba.sch.bme.hu Thu Sep 19 10:17:00 2002
From: frts@simba.sch.bme.hu (Istvan Gyenes)
Date: Thu, 19 Sep 2002 11:17:00 +0200 (MET DST)
Subject: [parisc-linux] SMP kernel problems on a D350
In-Reply-To: <200209190805.KAA0000032531@simba.sch.bme.hu>
Message-ID: <Pine.OSF.4.33.0209191111490.32375-100000@simba.sch.bme.hu>
Hello Joerg,
The only difference between the non-smp and smp kernel config file is
CONFIG_SMP=yes , AFAIK.
I made a "make menuconfig" and the only thing I've changed is SMP support.
The strange thing is that the precompiled smp kernel from the install cd
boots fine. (2.4.18-smp)
BTW where can I select 32bit/64bit support?
__
Steve
On Thu, 19 Sep 2002, J.Steindlberger wrote:
> Hi Steve,
>
> I'm no developer, but I know, that there are a few restrictions with D-Class
> machines. Did You select 64bit support? This machine is a 32bit architecture.
>
> Regards
> Joerg
>
> On Thursday 19 September 2002 09:38, you wrote:
> > I'm trying to compile an SMP kernel for my D 350 (2cpu) server without
> > success.
> > The kernel source is 2.4.19-pa18 and in non-smp configuration it works
> > well. Anyway the SMP kernel compiles fine but when I try to boot it
> > stops at the "If this is the last message you see, you may need to switch
> > your console" line. I've switched the console but got no other output.
> > (It was the same with 2.4.19-pa14)
> > The system was installed from a debian 3.0 CD.
> > Can somebody send me a working .config? Or what can be the problem?
>
From alan@lxorguk.ukuu.org.uk Thu Sep 19 11:06:44 2002
From: alan@lxorguk.ukuu.org.uk (Alan Cox)
Date: 19 Sep 2002 11:06:44 +0100
Subject: [parisc-linux] ide controller
In-Reply-To: <28859.1032424874@www2.gmx.net>
References: <20020916043004.B27754829@dsl2.external.hp.com>
<28859.1032424874@www2.gmx.net>
Message-ID: <1032430004.26669.1.camel@irongate.swansea.linux.org.uk>
On Thu, 2002-09-19 at 09:41, j.steindlberger@gmx.de wrote:
> together with Moritz I/we tried to get some new results. We took the latest
> kernel (-pa18) and did the changes to the PDC202XX-definitions in pdc202xx.c.
> But I don't believe that the kernel gets the chance to recognice this
> change. I think the kernel crashes earlier. We reduced the kernel by the specific
> drivers. We disabled the following:
> [ ] Generic PCI bus-master DMA support
> After compiling wie had these three modules:
> ide-mod.o
> ide-probe-mod.o
> ide-disk.o
> An insmod ide-mod.o was possible. But after insmod ide-probe-mod the kernel
> crashes. In some cases we got an output with about 50 pages of memory
> addresses. At the beginning we got some messages told about the SYM-SCSI-device.
> Could that be a conflict? We did not succeed to reproduce that and log it.
Our IDE code has been run on non x86 platforms. It does require that the
defaults are set right for the platform so that it doesnt do stuff like
blindly probe I/O 0x170.
I don't know if the Promise card needs its BIOS to have run, I would
suspect not but can't be sure.
From stephan@itp.bg Thu Sep 19 11:24:20 2002
From: stephan@itp.bg (Stephan Trajkoff)
Date: Thu, 19 Sep 2002 13:24:20 +0300
Subject: [parisc-linux] PPPD+PPTPD
Message-ID: <3D89A5D4.8050306@itp.bg>
This is a multi-part message in MIME format.
--------------060604040603010400060207
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Hello, please see the attachment.
I use 2.4.18-pa61 kernel and enabled PPP support
PPPD version is 2.4.1, PPTPD is 1.1.3
--------------060604040603010400060207
Content-Type: text/plain;
name="ppp"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="ppp"
Sep 19 13:22:41 obzor pppd[17190]: read: Resource temporarily unavailable
Sep 19 13:22:41 obzor pppd[17190]: read /dev/ppp: Resource temporarily
unavailable
Sep 19 13:22:41 obzor pppd[17190]: rcvd [LCP ConfAck id=0x1 <asyncmap 0x0>
<auth pap> <magic 0x2479cb91> <pcomp> <accomp>]
Sep 19 13:22:41 obzor pppd[17190]: sent [LCP EchoReq id=0x0
magic=0x2479cb91]
Sep 19 13:22:41 obzor pppd[17190]: rcvd [PAP AuthReq id=0x1 user="kpematop"
password=<hidden>]
--------------060604040603010400060207--
From j@steindlberger.de Thu Sep 19 13:21:15 2002
From: j@steindlberger.de (J.Steindlberger)
Date: Thu, 19 Sep 2002 14:21:15 +0200
Subject: [parisc-linux] SMP kernel problems on a D350
In-Reply-To: <Pine.OSF.4.33.0209191111490.32375-100000@simba.sch.bme.hu>
References: <Pine.OSF.4.33.0209191111490.32375-100000@simba.sch.bme.hu>
Message-ID: <20020919122034.98BF64829@dsl2.external.hp.com>
Hi,
You can choose 32bit/64bit in the "Processor type" section. And only if You
choose a processor that supports more than 32bit.
Did You try the config file included in the 2.4.18-smp kernel image package?
Perhaps it's different in more than that SMP-section. So far for my ideas. If
You still get problems, there is something to be fixed and the answering is
up to an expert -- not me ;-) , sorry. I hope I could help You anyway.
Joerg
From rbradetich@uswest.net Thu Sep 19 13:29:29 2002
From: rbradetich@uswest.net (Ryan Bradetich)
Date: 19 Sep 2002 06:29:29 -0600
Subject: [parisc-linux] SMP kernel problems on a D350
In-Reply-To: <20020919122034.98BF64829@dsl2.external.hp.com>
References: <Pine.OSF.4.33.0209191111490.32375-100000@simba.sch.bme.hu>
<20020919122034.98BF64829@dsl2.external.hp.com>
Message-ID: <1032438569.25418.107.camel@beavis>
On Thu, 2002-09-19 at 06:21, J.Steindlberger wrote:
> Hi,
>
> You can choose 32bit/64bit in the "Processor type" section. And only if You
> choose a processor that supports more than 32bit.
ie PA8x00 chipset. From the hwdb the D350 has the following processor:
UL Proc 1-way T'100 (821/D250,D350) (Processor) (PA7200 (PCX-T'))
so 64-bit would not be supported on this system.
- Ryan
> Did You try the config file included in the 2.4.18-smp kernel image package?
> Perhaps it's different in more than that SMP-section. So far for my ideas. If
> You still get problems, there is something to be fixed and the answering is
> up to an expert -- not me ;-) , sorry. I hope I could help You anyway.
>
> Joerg
> _______________________________________________
> parisc-linux mailing list
> parisc-linux@lists.parisc-linux.org
> http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
>
From j@steindlberger.de Thu Sep 19 13:50:45 2002
From: j@steindlberger.de (J.Steindlberger)
Date: Thu, 19 Sep 2002 14:50:45 +0200
Subject: [parisc-linux] ide controller
In-Reply-To: <1032430004.26669.1.camel@irongate.swansea.linux.org.uk>
References: <20020916043004.B27754829@dsl2.external.hp.com> <28859.1032424874@www2.gmx.net> <1032430004.26669.1.camel@irongate.swansea.linux.org.uk>
Message-ID: <20020919125032.31FE74829@dsl2.external.hp.com>
On Thursday 19 September 2002 12:06, you wrote:
> Our IDE code has been run on non x86 platforms. It does require that the
> defaults are set right for the platform so that it doesnt do stuff like
> blindly probe I/O 0x170.
>
> I don't know if the Promise card needs its BIOS to have run, I would
> suspect not but can't be sure.
Hi Alan,
we tried a different controller with originally an eprom bios. We simply put
that eeprom away. (The Promise has a chip-integrated flash bios - putting
that away seems not to be possible.) The kernel crashed alike. Do You have
any ideas to get more debug output? I could set up my second C-Class with
parisc-linux and test it there. (The first one is now running some essential
services - continued crashing would not be good.)
Then I will have a deep look into the linux-code (oh, I'll have to learn C)
and search for that stupid (sorry) 0x170 probe.
Thanks a lot! You will read more...
Joerg
From Francisco_Javier.Llorente_Recio@alcatel.es Thu Sep 19 16:08:16 2002
From: Francisco_Javier.Llorente_Recio@alcatel.es (Francisco_Javier.Llorente_Recio@alcatel.es)
Date: Thu, 19 Sep 2002 17:08:16 +0200
Subject: [parisc-linux] Re: XFree86 on B180
Message-ID: <OF0516E33B.55652A57-ONC1256C39.0051BFF7@rdp.asi.alcatel.es>
Hello Thomas, Helge, Jo=EBl and everyone!
Here I am opening again that old thread. Ok. We had here a B180 with a
broken 8GB hard disk inside and nothing but a 4GB hard disk to fix it. =
So
we have fix the B180 and, as our software needs at least 8GB to run, I
though we could use this WS for testing purposes... with PA-Linux. So I=
installed the "Debian GNU/Linux 3.0 prerelease "Woody" - Unofficial hpp=
a
Binary-1" this morning.
Well, It's running smoothly... but i need to run also the XFree86... an=
d it
seems not to work. I've tested several configurations and all that I ge=
t is
an "(EE) No devices detected" error. Then, I searched the list and foun=
d
this:
On Sunday 05 August 2001 16:48, Thomas Bogendoerfer wrote:
> On Fri, Aug 03, 2001 at 12:45:01PM +0200, Helge Deller wrote:
> > Currently stifb will run on most 712 and 715 machines, while B160,
B180,
> > C3000 and most others won't.
>
> you saw X on the B180 I had at LinuxTag:-) Treating the EG VISULIZE a=
s an
> artist graphics card did the trick.
So X can work on a B180. Question is... How I do this?
Well, It's not a case of life-or-death, as we still can use HP-UX 10.20=
on
this machine... but I'm the only Linux-supporter in my department, and =
so
it'd be a score to get this machine working with Linux.
Thanks in advance.
Fco. Javier Llorente Recio
Alcatel Espa=F1a, S.A.
SRD - Asistencia T=E9cnica (Ref. 02455)
Telefono - Phone (+34) 91 330 6877
M=F3vil - Mobile (+34) 636 482 505
ICQ 87013139
=
From patrick@tykepenguin.com Thu Sep 19 16:17:34 2002
From: patrick@tykepenguin.com (Patrick Caulfield)
Date: Thu, 19 Sep 2002 16:17:34 +0100
Subject: [parisc-linux] HP/UX binaries
Message-ID: <20020919151734.GH845@tykepenguin.com>
How do I go about trying to run HP/UX binaries on parisc-linux ?
In particular I would like to get bitkeeper running as there's an HP/UX binary
for that but no HP/Linux port :(
When I try to run the installer (or any of the binaries copied from the HP/UX
installation) I get
crt0: ERROR couldn't open /usr/lib/dld.sl errno:000000015
I've copied dld.sl from HP/UX into /usr/lib and my kernel has support for SOM
binaries in it. Is there anything else I need to do, or is it just not going to
work ?
--
patrick
From Randolph Chung <randolph@tausq.org> Thu Sep 19 16:27:56 2002
From: Randolph Chung <randolph@tausq.org> (Randolph Chung)
Date: Thu, 19 Sep 2002 08:27:56 -0700
Subject: [parisc-linux] HP/UX binaries
In-Reply-To: <20020919151734.GH845@tykepenguin.com>
References: <20020919151734.GH845@tykepenguin.com>
Message-ID: <20020919152756.GA12481@tausq.org>
In reference to a message from Patrick Caulfield, dated Sep 19:
> How do I go about trying to run HP/UX binaries on parisc-linux ?
>
> In particular I would like to get bitkeeper running as there's an HP/UX binary
> for that but no HP/Linux port :(
Bug Larry McVoy about it. :-) Apparently he was considering a palinux
port at some point.
we only support static SOM binaries on palinux.... from binfmt_som.c:
static inline int
do_load_som_library(struct file *f)
{
/* No lib support in SOM yet. gizza chance.. */
return -ENOEXEC;
}
randolph
From willy@debian.org Thu Sep 19 16:27:29 2002
From: willy@debian.org (Matthew Wilcox)
Date: Thu, 19 Sep 2002 16:27:29 +0100
Subject: [parisc-linux] HP/UX binaries
In-Reply-To: <20020919152756.GA12481@tausq.org>; from randolph@tausq.org on Thu, Sep 19, 2002 at 08:27:56AM -0700
References: <20020919151734.GH845@tykepenguin.com> <20020919152756.GA12481@tausq.org>
Message-ID: <20020919162729.V10583@parcelfarce.linux.theplanet.co.uk>
On Thu, Sep 19, 2002 at 08:27:56AM -0700, Randolph Chung wrote:
> Bug Larry McVoy about it. :-) Apparently he was considering a palinux
> port at some point.
no, don't bug Larry about it, he'll bug me for an A500... taggart,
did you have time to look into that yet?
--
Revolutions do not require corporate support.
From patrick@tykepenguin.com Thu Sep 19 19:51:31 2002
From: patrick@tykepenguin.com (Patrick Caulfield)
Date: Thu, 19 Sep 2002 19:51:31 +0100
Subject: [parisc-linux] HP/UX binaries
In-Reply-To: <20020919152756.GA12481@tausq.org>
References: <20020919151734.GH845@tykepenguin.com> <20020919152756.GA12481@tausq.org>
Message-ID: <20020919185131.GB6961@tykepenguin.com>
On Thu, Sep 19, 2002 at 08:27:56AM -0700, Randolph Chung wrote:
> In reference to a message from Patrick Caulfield, dated Sep 19:
> > How do I go about trying to run HP/UX binaries on parisc-linux ?
> >
> > In particular I would like to get bitkeeper running as there's an HP/UX binary
> > for that but no HP/Linux port :(
>
> Bug Larry McVoy about it. :-) Apparently he was considering a palinux
> port at some point.
>
> we only support static SOM binaries on palinux.... from binfmt_som.c:
>
> static inline int
> do_load_som_library(struct file *f)
> {
> /* No lib support in SOM yet. gizza chance.. */
> return -ENOEXEC;
> }
aha. That'll teach me to read the FAQ rather than the code :-)
patrick
From willy@debian.org Thu Sep 19 20:01:45 2002
From: willy@debian.org (Matthew Wilcox)
Date: Thu, 19 Sep 2002 20:01:45 +0100
Subject: [parisc-linux] HP/UX binaries
In-Reply-To: <20020919185131.GB6961@tykepenguin.com>; from patrick@tykepenguin.com on Thu, Sep 19, 2002 at 07:51:31PM +0100
References: <20020919151734.GH845@tykepenguin.com> <20020919152756.GA12481@tausq.org> <20020919185131.GB6961@tykepenguin.com>
Message-ID: <20020919200145.W10583@parcelfarce.linux.theplanet.co.uk>
On Thu, Sep 19, 2002 at 07:51:31PM +0100, Patrick Caulfield wrote:
> > static inline int
> > do_load_som_library(struct file *f)
> > {
> > /* No lib support in SOM yet. gizza chance.. */
> > return -ENOEXEC;
> > }
>
> aha. That'll teach me to read the FAQ rather than the code :-)
i'm not sure the comment is actually right... seems to me that ld.so
on hpux loads the libraries without going through this entry point.
it'd be interesting to test, but i think hpux emulation is broken right
now anyway.
--
Revolutions do not require corporate support.
From taggart@carmen.fc.hp.com Thu Sep 19 20:08:16 2002
From: taggart@carmen.fc.hp.com (Matt Taggart)
Date: Thu, 19 Sep 2002 13:08:16 -0600
Subject: [parisc-linux] HP/UX binaries
In-Reply-To: Message from Matthew Wilcox <willy@debian.org>
of "Thu, 19 Sep 2002 16:27:29 BST." <20020919162729.V10583@parcelfarce.linux.theplanet.co.uk>
References: <20020919151734.GH845@tykepenguin.com>
<20020919152756.GA12481@tausq.org> <20020919162729.V10583@parcelfarce.linux.theplanet.co.uk>
Message-ID: <20020919190816.47F9337F2E@carmen.fc.hp.com>
Matthew Wilcox writes...
> On Thu, Sep 19, 2002 at 08:27:56AM -0700, Randolph Chung wrote:
> > Bug Larry McVoy about it. :-) Apparently he was considering a palinux
> > port at some point.
>
> no, don't bug Larry about it, he'll bug me for an A500... taggart,
> did you have time to look into that yet?
Oh yeah, I forgot. I will.
--
Matt Taggart Linux R&D
taggart@fc.hp.com HP Linux Systems Division
From tobias_subscriber@tgtools.com Thu Sep 19 20:28:54 2002
From: tobias_subscriber@tgtools.com (Tobias Giesen)
Date: Thu, 19 Sep 2002 21:28:54 +0200
Subject: [parisc-linux] Re: [PATCH] Voodoo framebuffer on PARISC
In-Reply-To: <200209160829.35216.deller@gmx.de>
Message-ID: <000401c26012$cb73ffd0$0100a8c0@PLUTO>
Hello again,
I tried some more today, and I changed my setting to
#define DEFAULT_MODE 2
and recompiled and installed the new kernel, but it seems
the Voodoo2 is simply misconfigured by the driver. My monitor
can take anything, so that's not the problem.
Are there any kernel parameters that I could try? Could it
be that my Voodoo2 is not compatible with Helge's?
I am on a Visualize C200.
Cheers,
Tobias
From grundler@dsl2.external.hp.com Thu Sep 19 23:33:16 2002
From: grundler@dsl2.external.hp.com (Grant Grundler)
Date: Thu, 19 Sep 2002 16:33:16 -0600
Subject: [parisc-linux] ide controller
In-Reply-To: Message from j.steindlberger@gmx.de
of "Thu, 19 Sep 2002 10:41:14 +0200." <28859.1032424874@www2.gmx.net>
References: <20020916043004.B27754829@dsl2.external.hp.com> <28859.1032424874@www2.gmx.net>
Message-ID: <20020919223316.13D0E4829@dsl2.external.hp.com>
j.steindlberger@gmx.de wrote:
> drivers. We disabled the following:
> [ ] Generic PCI bus-master DMA support
hmm....ok.
> After compiling wie had these three modules:
> ide-mod.o
> ide-probe-mod.o
> ide-disk.o
No pdc202xx.o?
> An insmod ide-mod.o was possible. But after insmod ide-probe-mod the kernel
> crashes. In some cases we got an output with about 50 pages of memory
> addresses. At the beginning we got some messages told about the SYM-SCSI-devi
> ce.
> Could that be a conflict?
I don't think so.
> We did not succeed to reproduce that and log it.
>
> Here my questions:
> Did You here about anyone to succeed in using an IDE-controller in a
> HP-RISC-architecture?
Yes. My C3000 has IDE CD-ROM hanging off the "SuckyIO" chip.
That works using PIO mode thanks to Randolph Chung/Thomas Bogendoerfer.
> Do You see a chance to use IDE-disks in future (with some none
> HP-controller)
yes - but I don't expect it to "just work".
IDE is a PoS with lots of buggy HW.
PARISC isn't very tolerant of many things the x86 PCs tolerate.
(eg access to disabled devices, PCI parity errors)
> Do You know about more people who are interrested in what we tried to do?
I don't offhand. If someone is, I ask they contact you directly.
Please continue to post status here and I'll offer advice when I can.
> That would be an argument for me to continue experimenting.
If you get it working, I'd be happy to help put any changes back
into our source tree and ultimately back to Alan Cox/Linus.
...
> > #define PDC202XX_DEBUG_DRIVE_INFO 0
> > #define PDC202XX_DECODE_REGISTER_INFO 0
> >
> > and rebuild the module with that.
> >
> > 3) post the console log and "ser pim" output at PDC prompt.
Using a serial console makes it easier to grab console logs in
the case were the machine is crashing.
Generally, I can help decode HPMCs and explain what might be wrong.
That's what the "ser pim" output is for.
I really need both to debug most IO problems.
grant
From grundler@dsl2.external.hp.com Thu Sep 19 23:46:09 2002
From: grundler@dsl2.external.hp.com (Grant Grundler)
Date: Thu, 19 Sep 2002 16:46:09 -0600
Subject: [parisc-linux] SMP kernel problems on a D350
In-Reply-To: Message from Istvan Gyenes <frts@simba.sch.bme.hu>
of "Thu, 19 Sep 2002 11:17:00 +0200." <Pine.OSF.4.33.0209191111490.32375-100000@simba.sch.bme.hu>
References: <Pine.OSF.4.33.0209191111490.32375-100000@simba.sch.bme.hu>
Message-ID: <20020919224609.DF1314829@dsl2.external.hp.com>
Istvan Gyenes wrote:
> Hello Joerg,
>
> The only difference between the non-smp and smp kernel config file is
> CONFIG_SMP=yes , AFAIK.
> I made a "make menuconfig" and the only thing I've changed is SMP support.
I'm paranoid. I do "make distclean" when doing anything other than
adding/removing drivers. Save/restore the .config if you need to before
running "make distclean". I don't trust the Makefiles to rebuild
everything correctly for "global" CONFIG_ changes like "SMP".
> The strange thing is that the precompiled smp kernel from the install cd
> boots fine. (2.4.18-smp)
SMP on 2.4.19 isn't as stable yet. So that's no surprise.
If you want to debug this further, define "EARLY_BOOTUP_DEBUG"
in arch/parisc/kernel/pdc_cons.c and you should get more output
about how far the kernel gets before it crashes/hangs.
grant
From grundler@dsl2.external.hp.com Fri Sep 20 00:02:07 2002
From: grundler@dsl2.external.hp.com (Grant Grundler)
Date: Thu, 19 Sep 2002 17:02:07 -0600
Subject: [parisc-linux] ide controller
In-Reply-To: Message from "J.Steindlberger" <j@steindlberger.de>
of "Thu, 19 Sep 2002 14:50:45 +0200." <20020919125032.50BB0482A@dsl2.external.hp.com>
References: <20020916043004.B27754829@dsl2.external.hp.com> <28859.1032424874@www2.gmx.net> <1032430004.26669.1.camel@irongate.swansea.linux.org.uk> <20020919125032.50BB0482A@dsl2.external.hp.com>
Message-ID: <20020919230207.6835D4829@dsl2.external.hp.com>
"J.Steindlberger" wrote:
> The kernel crashed alike. Do You have any ideas to get more debug output?
If the crash was an "HPMC", then "ser pim" at PDC prompt will
tell you machine state and why it crashed. If the crash
was a regular panic, the console output will tell the reason, where,
and give a register dump. Post either or both of those here
and we can try to decode it for you.
grant
From grundler@dsl2.external.hp.com Fri Sep 20 00:24:15 2002
From: grundler@dsl2.external.hp.com (Grant Grundler)
Date: Thu, 19 Sep 2002 17:24:15 -0600
Subject: [parisc-linux] Re: XFree86 on B180
In-Reply-To: Message from Francisco_Javier.Llorente_Recio@alcatel.es
of "Thu, 19 Sep 2002 17:08:16 +0200." <OF0516E33B.55652A57-ONC1256C39.0051BFF7@rdp.asi.alcatel.es>
References: <OF0516E33B.55652A57-ONC1256C39.0051BFF7@rdp.asi.alcatel.es>
Message-ID: <20020919232415.D05784829@dsl2.external.hp.com>
Francisco_Javier.Llorente_Recio@alcatel.es wrote:
> Well, It's running smoothly... but i need to run also the XFree86...
> and it seems not to work. I've tested several configurations and all
> that I get is an "(EE) No devices detected" error.
Works For Me(tm).
Uploaded my XF86 config file to:
ftp://ftp.parisc-linux.org/kernels/b180/XF86Config-4.ggg
and currently running kernel:
ftp://ftp.parisc-linux.org/kernels/b180/2.4.19-pa10.tgz
Kernels found in kernels/32/ on the same server should work just as well.
grant
From s_selten@informatik.uni-karlsruhe.de Fri Sep 20 01:27:01 2002
From: s_selten@informatik.uni-karlsruhe.de (Andreas Seltenreich)
Date: Fri, 20 Sep 2002 02:27:01 +0200
Subject: [parisc-linux] partial success with matroxfb
In-Reply-To: <20020822225054.GA24190@ppc.vc.cvut.cz>
References: <20020821232010.GD15344@gate450.dyndns.org> <20020822225054.GA24190@ppc.vc.cvut.cz>
Message-ID: <20020920002700.GY22068@gate450.dyndns.org>
--hUH5gZbnpyIv7Mn4
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Hello list,
here is a report about my experiments with a "Matrox Mystique" in
a C200. The attached diff shows the _temporary_ changes I made to the
matroxfb.
I replaced the {read,write}{b,w,l} calls to their __raw equivalents,
because Petr Vandrovec told me that matroxfb expects them to do BE to
PCI on BE machines. I had no success when running the card in LE mode.
After modprobing the module with noinit=0 the frame buffer seems to be
up and working. I can use fbset on the device and display text by
writing to /dev/tty1. But as soon as there is much traffic (like ping
-f through a NIC or disk i/o) on the PCI bus, the kernel hangs.
testing was done with 2.4.19-pa17
This is the output of PIM after doing a TOC:
=============
----------------- Processor 0 HPMC Information ------------------
Timestamp = Mon Sep 16 01:49:14 GMT 2002 (20:02:09:16:01:49:14)
HPMC Chassis Codes = 0xcbf0 0x5002 0x540f 0x5508 0xcbfb
General Registers 0 - 31
00-03 0000000000000000 fffffffffff0bdc0 00000000f3ef8000 00000000f3ef8002
04-07 000000001fb9d940 000000000000000f 000000000000003b 00000000103d2010
08-11 000000000000000f 000000000000004d 000000000004000e 00000000103705ac
12-15 0000000000000000 0000000000000000 00000000000000fd 00000000f0100000
16-19 00000000103b45c0 00000000f000020c 00000000f0000204 00000000000000de
20-23 000000000000000e 00000000000003e8 000000000bebc200 00000000000f4240
24-27 0000000000000000 00000000000f4240 05f5e10000000032 00000000102fa010
28-31 000000001fb9dd6c 17d78400000000c8 00000000103b4980 000000000004d518
<Press any key to continue (q to quit)>
Control Registers 0 - 31
00-03 0000000000000000 0000000000000000 0000000000000000 0000000000000000
04-07 0000000000000000 0000000000000000 0000000000000000 0000000000000000
08-11 00000000000000a0 0000000000000000 00000000000000c0 000000000000001f
12-15 0000000000000000 0000000000000000 0000000000107000 00000000f0000000
16-19 00000024a0d4f160 0000000000000000 000000000004d534 0000000000141860
20-23 0000000000000000 0000000000000000 000000ff0004fc0c 0000000000000000
24-27 000000000031c000 000000000f022000 00000000ffffffff 00000000ffffffff
28-31 00000000ffffffff 00000000ffffffff 00000000103b4000 00000000103b8000
Space Registers 0 - 7
00-03 00000000 00000000 00000000 00000050
04-07 00000000 00000000 00000000 00000000
<Press any key to continue (q to quit)>
IIA Space = 0x0000000000000000
IIA Offset = 0x000000000004d538
Check Type = 0x20000000
CPU State = 0x9e000004
Cache Check = 0x00000000
TLB Check = 0x00000000
Bus Check = 0x00305004
Assists Check = 0x00000000
Assist State = 0x00000000
Path Info = 0x00000000
System Responder Address = 0x000000fff3ef8002
System Requestor Address = 0xfffffffffffa0000
Check Summary = 0x8000000810004000
Available Memory = 0x0000000000000000
CPU Diagnose Register 2 = 0x0501000000000004
CPU Status Register 0 = 0x1420c20000000000
CPU Status Register 1 = 0x8000000800000000
SADD LOG = 0x7f1fde477f7fde47
Read Short LOG = 0xc10200fff3ef8002
<Press any key to continue (q to quit)>
Memory Error Log Information:
Timestamp = Mon Sep 16 01:49:14 GMT 2002 (20:02:09:16:01:49:14)
No memory errors logged
I/O Module Error Log Information:
Timestamp = Mon Sep 16 01:49:16 GMT 2002 (20:02:09:16:01:49:16)
Bus HPA Module Type Path Slt Md Sev Estat Requestor Responder
--- ---------- ---------------- -------- -- -- ---- ----- ---------- ----------
0 0xfff88000 I/O Adapter 8 2 0 he 0x3d 0xf2000000 0x000a1000
0 0xfff8a000 I/O Adapter 10 2 2 he 0x0d 0x00000000 0x00000000
=============
I suspect that there's something wrong with the pci bus, but I couldn't
decode it further.
here is the log from modprobing the module:
================
matroxfb: Matrox Mystique 220 (PCI) detected
matroxfb: Your Matrox device does not have BIOS
post_shift_max: 3
ref_freq: 14318
freq: 133333
vco_freq_min: 62000
in_div_min: 1
in_div_max: 31
feed_div_min: 100
feed_div_max: 127
fmax: 220000
clk: 0C 78 00 14318 133267 66666
requested 640*480/8bpp (640*6547)
matroxfb: 640x480x8bpp (virtual: 640x6547)
matroxfb: framebuffer at 0xF3000000, mapped to 0xf3000000, size
4194304
requested 640*480/8bpp (640*6547)
post_shift_max: 3
ref_freq: 14318
freq: 25175
vco_freq_min: 62000
in_div_min: 1
in_div_max: 31
feed_div_min: 100
feed_div_max: 127
fmax: 220000
clk: 08 7E 03 14318 202042 50350
matroxfb: Pixel PLL not locked after 5 secs
MiscOutReg: 8B
SEQ regs: 00:01:0F:00:0E:
GDC regs: 00:00:00:00:00:40:05:0F:FF:
CRTC regs:
5F:4F:4F:83:51:9D:0B:3E:00:40:00:00:00:00:00:00:E9:2B:DF:28:00:DF:0C:C3:FF:
ATTR regs:
00:01:02:03:04:05:06:07:08:09:0A:0B:0C:0D:0E:0F:41:FF:0F:00:00:
requested 640*480/8bpp (640*6547)
post_shift_max: 3
ref_freq: 14318
freq: 25175
vco_freq_min: 62000
in_div_min: 1
in_div_max: 31
feed_div_min: 100
feed_div_max: 127
fmax: 220000
clk: 08 7E 03 14318 202042 50350
MiscOutReg: 8B
SEQ regs: 00:01:0F:00:0E:
GDC regs: 00:00:00:00:00:40:05:0F:FF:
CRTC regs:
5F:4F:4F:83:51:9D:0B:3E:00:40:00:00:00:00:00:00:E9:2B:DF:28:00:DF:0C:C3:FF:
ATTR regs:
00:01:02:03:04:05:06:07:08:09:0A:0B:0C:0D:0E:0F:41:FF:0F:00:00:
Console: switching to colour frame buffer device 80x30
fb0: MATROX VGA frame buffer device
=============
anotherhpmachien:~# cat /proc/pci
PCI devices found:
Bus 0, device 1, function 0:
VGA compatible controller: Matrox Graphics, Inc. MGA 1064SG [Mystique] (rev 3).
IRQ 97.
Master Capable. Latency=248.
Prefetchable 32 bit memory at 0xf3000000 [0xf37fffff].
Non-prefetchable 32 bit memory at 0xf3ffc000 [0xf3ffffff].
Bus 0, device 19, function 0:
SCSI storage controller: LSI Logic / Symbios Logic (formerly NCR) 53c875 (rev 4).
IRQ 99.
Master Capable. Latency=255. Min Gnt=17.Max Lat=64.
I/O at 0xfe00 [0xfeff].
Non-prefetchable 32 bit memory at 0xf3ff9000 [0xf3ff90ff].
Non-prefetchable 32 bit memory at 0xf3ffa000 [0xf3ffafff].
Bus 0, device 20, function 0:
Ethernet controller: Digital Equipment Corporation DECchip 21142/43 (rev 48).
IRQ 96.
Master Capable. Latency=255. Min Gnt=20.Max Lat=40.
I/O at 0xff00 [0xff7f].
Non-prefetchable 32 bit memory at 0xf3ffb000 [0xf3ffb07f].
=============
anotherhpmachien:~# cat /proc/iomem
00000000-0fffffff : System RAM
00000000-000009ff : PDC data (Page Zero)
00100000-002f3fff : Kernel code
002f4000-003f9f3f : Kernel data
f0190001-f0190001 : led_data
f1000000-f1ffffff : GSC Bus [10/]
f1000000-f1000fff : Cujo
f2000000-f3ffffff : GSC Bus [8/]
f2000000-f2000fff : Dino
f2003000-f2003fff : Serial RS232
f2800000-f2ffffff : Dino LMMIO
f3000000-f37fffff : matroxfb FB
f3ffb000-f3ffb07f : tulip
f3ffc000-f3ffffff : matroxfb MMIO
f4000000-fff7ffff : GSC Bus [8/]
ffd00000-ffdfffff : Lasi
ffd00000-ffd00fff : Lasi
ffd02000-ffd02fff : Parallel
ffd04000-ffd04fff : Lasi Harmony
ffd05000-ffd05fff : Serial RS232
ffd06000-ffd06fff : Lasi SCSI
ffd08000-ffd08fff : Lasi psaux
fff80000-fffaffff : Central Bus
fff88000-fff88fff : U2/Uturn
fff8a000-fff8afff : U2/Uturn
fffa0000-fffa0fff : CPU
fffb0000-fffdffff : Local Broadcast
fffe0000-ffffffff : Global Broadcast
thanks
andreas
--hUH5gZbnpyIv7Mn4
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="temporary-changes.diff"
--- linux/drivers/video/matrox/matroxfb_base.h Mon Aug 5 02:12:55 2002
+++ linux/drivers/video/matrox/matroxfb_base.h Fri Sep 20 01:13:54 2002
@@ -10,10 +10,12 @@
/* general, but fairly heavy, debugging */
#undef MATROXFB_DEBUG
+#define MATROXFB_DEBUG
/* heavy debugging: */
/* -- logs putc[s], so everytime a char is displayed, it's logged */
#undef MATROXFB_DEBUG_HEAVY
+#define MATROXFB_DEBUG_HEAVY
/* This one _could_ cause infinite loops */
/* It _does_ cause lots and lots of messages during idle loops */
@@ -21,9 +23,11 @@
/* Debug register calls, too? */
#undef MATROXFB_DEBUG_REG
+#define MATROXFB_DEBUG_REG
/* Guard accelerator accesses with spin_lock_irqsave... */
#undef MATROXFB_USE_SPINLOCKS
+#define MATROXFB_USE_SPINLOCKS
#include <linux/config.h>
#include <linux/module.h>
@@ -108,7 +112,7 @@
#endif
#endif
-#if defined(__alpha__) || defined(__m68k__)
+#if defined(__alpha__) || defined(__m68k__) || defined(__hppa__)
#define READx_WORKS
#define MEMCPYTOIO_WORKS
#else
@@ -174,27 +178,33 @@
#ifdef READx_WORKS
static inline unsigned int mga_readb(vaddr_t va, unsigned int offs) {
+ return __raw_readb(va.vaddr + offs);
return readb(va.vaddr + offs);
}
static inline unsigned int mga_readw(vaddr_t va, unsigned int offs) {
+ return __raw_readw(va.vaddr + offs);
return readw(va.vaddr + offs);
}
static inline u_int32_t mga_readl(vaddr_t va, unsigned int offs) {
+ return __raw_readl(va.vaddr + offs);
return readl(va.vaddr + offs);
}
static inline void mga_writeb(vaddr_t va, unsigned int offs, u_int8_t value) {
- writeb(value, va.vaddr + offs);
+// writeb(value, va.vaddr + offs);
+ __raw_writeb(value, va.vaddr + offs);
}
static inline void mga_writew(vaddr_t va, unsigned int offs, u_int16_t value) {
- writew(value, va.vaddr + offs);
+// writew(value, va.vaddr + offs);
+ __raw_writew(value, va.vaddr + offs);
}
static inline void mga_writel(vaddr_t va, unsigned int offs, u_int32_t value) {
- writel(value, va.vaddr + offs);
+// writel(value, va.vaddr + offs);
+ __raw_writel(value, va.vaddr + offs);
}
#else
static inline unsigned int mga_readb(vaddr_t va, unsigned int offs) {
--hUH5gZbnpyIv7Mn4--
From Jurriaan.Kalkman@zrt.nl Fri Sep 20 07:06:56 2002
From: Jurriaan.Kalkman@zrt.nl (Jurriaan Kalkman)
Date: Fri, 20 Sep 2002 08:06:56 +0200
Subject: Betr.: Re: [parisc-linux] ide controller
Message-ID: <sd8ad9a7.057@ms-zrt1>
>On Thursday 19 September 2002 12:06, you wrote:
>we tried a different controller with originally an eprom bios. We simply =
put=20
>that eeprom away. (The Promise has a chip-integrated flash bios - =
putting=20
>that away seems not to be possible.) The kernel crashed alike. Do You =
have=20
>any ideas to get more debug output? I could set up my second C-Class =
with=20
>parisc-linux and test it there. (The first one is now running some =
essential=20
>services - continued crashing would not be good.)
>
I have successfully run a PDC20265 Promise card on an Alpha, so the BIOS
is not needed to use it from Linux.
Kind regards,
Jurriaan
From deller@gmx.de Fri Sep 20 08:23:31 2002
From: deller@gmx.de (Helge Deller)
Date: Fri, 20 Sep 2002 09:23:31 +0200
Subject: [parisc-linux] partial success with matroxfb
In-Reply-To: <20020920002700.GY22068@gate450.dyndns.org>
References: <20020821232010.GD15344@gate450.dyndns.org> <20020822225054.GA24190@ppc.vc.cvut.cz> <20020920002700.GY22068@gate450.dyndns.org>
Message-ID: <200209200923.31247.deller@gmx.de>
On Friday 20 September 2002 02:27, Andreas Seltenreich wrote:
> Hello list,
>
> here is a report about my experiments with a "Matrox Mystique" in
> a C200. The attached diff shows the _temporary_ changes I made to the
> matroxfb.
>
> I replaced the {read,write}{b,w,l} calls to their __raw equivalents,
> because Petr Vandrovec told me that matroxfb expects them to do BE to
> PCI on BE machines. I had no success when running the card in LE mode.
Hi Andreas,
instead of
static inline unsigned int mga_readb(vaddr_t va, unsigned int offs) {
+ return __raw_readb(va.vaddr + offs);
- return readb(va.vaddr + offs);
}
I think you should use the
fb_readXXX() and fb_writeXX()
functions from include/video/fbcon.h which are automatically
initialized correctly acording to the architecture.
Greetings,
Helge
From frts@simba.sch.bme.hu Fri Sep 20 09:28:24 2002
From: frts@simba.sch.bme.hu (Istvan Gyenes)
Date: Fri, 20 Sep 2002 10:28:24 +0200 (MET DST)
Subject: [parisc-linux] SMP kernel problems on a D350
In-Reply-To: <20020919224609.DF1314829@dsl2.external.hp.com>
Message-ID: <Pine.OSF.4.33.0209201006420.5180-100000@simba.sch.bme.hu>
Thanks I'll try that!
Another question: If 2.4.19 SMP not enough stable where can I find the
latest stable smp kernel source?
Thanks,
__
Steve
On Thu, 19 Sep 2002, Grant Grundler wrote:
> Istvan Gyenes wrote:
> > Hello Joerg,
> >
> > The only difference between the non-smp and smp kernel config file is
> > CONFIG_SMP=yes , AFAIK.
> > I made a "make menuconfig" and the only thing I've changed is SMP support.
>
> I'm paranoid. I do "make distclean" when doing anything other than
> adding/removing drivers. Save/restore the .config if you need to before
> running "make distclean". I don't trust the Makefiles to rebuild
> everything correctly for "global" CONFIG_ changes like "SMP".
>
> > The strange thing is that the precompiled smp kernel from the install cd
> > boots fine. (2.4.18-smp)
>
> SMP on 2.4.19 isn't as stable yet. So that's no surprise.
>
> If you want to debug this further, define "EARLY_BOOTUP_DEBUG"
> in arch/parisc/kernel/pdc_cons.c and you should get more output
> about how far the kernel gets before it crashes/hangs.
>
> grant
> _______________________________________________
> parisc-linux mailing list
> parisc-linux@lists.parisc-linux.org
> http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
>
From VANDROVE@vc.cvut.cz Fri Sep 20 11:11:21 2002
From: VANDROVE@vc.cvut.cz (Petr Vandrovec)
Date: Fri, 20 Sep 2002 12:11:21 +0200
Subject: [parisc-linux] Re: partial success with matroxfb
Message-ID: <251F50824F2@vcnet.vc.cvut.cz>
On 20 Sep 02 at 2:27, Andreas Seltenreich wrote:
> Bus HPA Module Type Path Slt Md Sev Estat Requestor Responder
> --- ---------- ---------------- -------- -- -- ---- ----- ---------- ----------
> 0 0xfff88000 I/O Adapter 8 2 0 he 0x3d 0xf2000000 0x000a1000
> 0 0xfff8a000 I/O Adapter 10 2 2 he 0x0d 0x00000000 0x00000000
> anotherhpmachien:~# cat /proc/iomem
> 00000000-0fffffff : System RAM
> f2000000-f3ffffff : GSC Bus [8/]
Hi Andreas,
boot with 'video=matrox:novga'. It looks like that Matrox responded
to the access to legacy VGA region 0xA0000-0xBFFFF. It does not happen
when CPU accesses this memory because of Matrox does not see this access
at all in such situation, because of host bridge directs it immediately
to the system ram, without accessing PCI. But when access originated from
some PCI busmaster, other PCI devices sees this access, and Mystique
claims it.
And now both host bridge (for system RAM) and Mystique (for VGA region)
accepted bus cycle, and hardware went mad...
I have no idea what second error reports, but it may be just triggered
by previous one.
Petr Vandrovec
From shopfortobacco@terra.es Fri Sep 20 13:03:00 2002
From: shopfortobacco@terra.es (Sales Department)
Date: Fri, 20 Sep 2002 14:03:00 +0200
Subject: [parisc-linux] Cheap Cigarettes
Message-ID: <20020920124854.1E7F64829@dsl2.external.hp.com>
Dear Sir or Madam
In the past you have requested information on discounted products. We hope that you find this of interest. If you are not a smoker, and find this email offensive, we sincerely apologise! We will be only too happy to take you off our mailing list.
If you are a smoker, however, and are fed up with paying high prices for your cigarettes and tobacco, take a look at what we have to offer by clicking on this link.
http://www.smokersassociation.co.uk/?S=32&ID=2
We can send you, legally, by registered air mail, direct to your door, 4 cartons of cigarettes or 40 pouches of rolling tobacco (all brands are available) from only 170 Euros - about 105 pounds - fully inclusive of postage and packing. Why pay more?
To remove yourself from our mailing list, please click below
mailto:smokersclub@terra.es
Yours faithfully.
Smokers Association
http://www.smokersassociation.co.uk/?S=32&ID=2
xay4871241y
From joel.soete@freebel.net Fri Sep 20 15:24:58 2002
From: joel.soete@freebel.net (Joel Soete)
Date: Fri, 20 Sep 2002 14:24:58 +0000
Subject: [parisc-linux] PPPD+PPTPD
References: <3D89A5D4.8050306@itp.bg>
Message-ID: <3D8B2FBA.40909@freebel.net>
Hey Stephan,
IIRC the solution is to re-compile the kernel with option "PPP support
for sync tty ports" and not async (as usual). It solved this problem for me.
I hope it will help you too,
Joel
Stephan Trajkoff wrote:
> Hello, please see the attachment.
> I use 2.4.18-pa61 kernel and enabled PPP support
> PPPD version is 2.4.1, PPTPD is 1.1.3
>
>
> ------------------------------------------------------------------------
>
> Sep 19 13:22:41 obzor pppd[17190]: read: Resource temporarily unavailable
> Sep 19 13:22:41 obzor pppd[17190]: read /dev/ppp: Resource temporarily
> unavailable
> Sep 19 13:22:41 obzor pppd[17190]: rcvd [LCP ConfAck id=0x1 <asyncmap 0x0>
> <auth pap> <magic 0x2479cb91> <pcomp> <accomp>]
> Sep 19 13:22:41 obzor pppd[17190]: sent [LCP EchoReq id=0x0
> magic=0x2479cb91]
> Sep 19 13:22:41 obzor pppd[17190]: rcvd [PAP AuthReq id=0x1 user="kpematop"
> password=<hidden>]
From joel.soete@freebel.net Fri Sep 20 16:48:59 2002
From: joel.soete@freebel.net (Joel Soete)
Date: Fri, 20 Sep 2002 15:48:59 +0000
Subject: [parisc-linux] HP/UX binaries
References: <20020919151734.GH845@tykepenguin.com> <20020919152756.GA12481@tausq.org> <20020919162729.V10583@parcelfarce.linux.theplanet.co.uk> <20020919190816.47F9337F2E@carmen.fc.hp.com>
Message-ID: <3D8B436B.6080109@freebel.net>
hey all,
Is that bkp sources (command line are enough for me) are available
somewhere now? (and where?)
Thanks for info,
Joel
Matt Taggart wrote:
> Matthew Wilcox writes...
>
>
>>On Thu, Sep 19, 2002 at 08:27:56AM -0700, Randolph Chung wrote:
>>
>>>Bug Larry McVoy about it. :-) Apparently he was considering a palinux
>>>port at some point.
>>
>>no, don't bug Larry about it, he'll bug me for an A500... taggart,
>>did you have time to look into that yet?
>
>
> Oh yeah, I forgot. I will.
>
From s_selten@informatik.uni-karlsruhe.de Fri Sep 20 16:50:27 2002
From: s_selten@informatik.uni-karlsruhe.de (Andreas Seltenreich)
Date: Fri, 20 Sep 2002 17:50:27 +0200
Subject: [parisc-linux] Re: partial success with matroxfb
In-Reply-To: <251F50824F2@vcnet.vc.cvut.cz>
References: <251F50824F2@vcnet.vc.cvut.cz>
Message-ID: <20020920155026.GA22068@gate450.dyndns.org>
Hi Petr,
* Petr Vandrovec <VANDROVE@vc.cvut.cz> [2002-09-20 12:12]:
> boot with 'video=matrox:novga'. It looks like that Matrox responded
No success with novga or no_pci_retry either. It results in the same crash.
> Can you print DAC registers 0x4C,0x4D,0x4E,0x4F after this message?
> 0x4C..0x4E should contain 8,7E,3, and 0x4F should contain 0 when
> PLL is not locked, and 0x40 if PLL is locked.
Ok, the code around the message now looks like this:
if (!tmout)
printk(KERN_ERR "matroxfb: Pixel PLL not locked after 5 secs\n");
for (i=0x4c; i<0x50; i++)
printk(KERN_INFO "DAC register %02x=%x\n", i, inDAC1064(i));
It looks like m1064_compute() is called twice and succeeds the second
time:
==========
anotherhpmachien:/usr/src/linux# modprobe matroxfb_base noinit=0 no_pci_retry=1 novga=1
Warning: /lib/momatroxfb: Matrox Mystique 220 (PCI) detected
dules/2.4.19-pa1post_shift_max: 3
7/kernel/driversref_freq: 14318
/video/matrox/mafreq: 133333
troxfb_base.o syvco_freq_min: 62000
mbol for parametin_div_min: 1
er mtrr not founin_div_max: 31
d
feed_div_min: 100
feed_div_max: 127
fmax: 220000
clk: 0C 78 00 14318 133267 66666
requested 640*480/8bpp (640*6547)
matroxfb: 640x480x8bpp (virtual: 640x6547)
matroxfb: framebuffer at 0xF3000000, mapped to 0xf3000000, size
4194304
requested 640*480/8bpp (640*6547)
post_shift_max: 3
ref_freq: 14318
freq: 25175
vco_freq_min: 62000
in_div_min: 1
in_div_max: 31
feed_div_min: 100
feed_div_max: 127
fmax: 220000
clk: 08 7E 03 14318 202042 50350
matroxfb: Pixel PLL not locked after 5 secs
DAC register 4c=8
DAC register 4d=7e
DAC register 4e=1f
DAC register 4f=0
MiscOutReg: 8B
SEQ regs: 00:01:0F:00:0E:
GDC regs: 00:00:00:00:00:40:05:0F:FF:
CRTC regs: 5F:4F:4F:83:51:9D:0B:3E:00:40:00:00:00:00:00:00:E9:2B:DF:28:00:DF:0C:C3:FF:
ATTR regs: 00:01:02:03:04:05:06:07:08:09:0A:0B:0C:0D:0E:0F:41:FF:0F:00:00:
requested 640*480/8bpp (640*6547)
post_shift_max: 3
ref_freq: 14318
freq: 25175
vco_freq_min: 62000
in_div_min: 1
in_div_max: 31
feed_div_min: 100
feed_div_max: 127
fmax: 220000
clk: 08 7E 03 14318 202042 50350
DAC register 4c=8
DAC register 4d=7e
DAC register 4e=1f
DAC register 4f=40
MiscOutReg: 8B
SEQ regs: 00:01:0F:00:0E:
GDC regs: 00:00:00:00:00:40:05:0F:FF:
CRTC regs: 5F:4F:4F:83:51:9D:0B:3E:00:40:00:00:00:00:00:00:E9:2B:DF:28:00:DF:0C:C3:FF:
ATTR regs: 00:01:02:03:04:05:06:07:08:09:0A:0B:0C:0D:0E:0F:41:FF:0F:00:00:
Console: switching to colour frame buffer device 80x30
fb0: MATROX VGA frame buffer device
anotherhpmachien:/usr/src/linux# sync
anotherhpmachien:/usr/src/linux# ping -f athlon
PING athlon (192.168.0.11): 56 data bytes
............
kernel BUG at printk.c:489!
* box reboots
`àINIT C4CC
INIT C4CF
INIT C4CD
[...]
Main Menu: Enter command > ser pim
PROCESSOR PIM INFORMATION
----------------- Processor 0 HPMC Information ------------------
Timestamp = Fri Sep 20 13:55:23 GMT 2002 (20:02:09:20:13:55:23)
HPMC Chassis Codes = 0xcbf0 0x5002 0x540f 0x5508 0xcbfb
General Registers 0 - 31
00-03 0000000000000000 0000000010368010 000000001024382c 0000000000000001
04-07 0000000000000006 000000001031e810 00000000103c0918 00000000103e2010
08-11 000000000000000f 000000000000004d 000000000004000e 000000001037c5ac
12-15 0000000000000000 0000000000000000 00000000103e3010 00000000103e3010
16-19 00000000103e2810 00000000103e2cdc 000000001031f810 00000000f3fffc0a
20-23 000000000000000e 000000000000000e 0000000000000001 0000000000919dda
24-27 0000000000000001 0000000000000001 00000000ffffff9d 0000000010304010
28-31 0000000000000010 0000000000004001 00000000103c0a40 00000000103e2010
<Press any key to continue (q to quit)>
Control Registers 0 - 31
00-03 0000000000000000 0000000000000000 0000000000000000 0000000000000000
04-07 0000000000000000 0000000000000000 0000000000000000 0000000000000000
08-11 000000000000057a 0000000000000000 00000000000000c0 000000000000000a
12-15 0000000000000000 0000000000000000 0000000000107000 00000000f0000000
16-19 0000000712615173 0000000000000000 0000000010243858 0000000000141860
20-23 000000009207ffcf c0000000fffffc00 000000000004010c 0000000000000000
24-27 0000000000326000 000000000f6d1000 00000000ffffffff 00000000ffffffff
28-31 00000000ffffffff 00000000ffffffff 00000000103c0000 00000000103c8000
Space Registers 0 - 7
00-03 00000000 00000000 00000000 000002bd
04-07 00000000 00000000 00000000 00000000
<Press any key to continue (q to quit)>
IIA Space = 0x0000000000000000
IIA Offset = 0x000000001024385c
Check Type = 0x20000000
CPU State = 0x9e000004
Cache Check = 0x00000000
TLB Check = 0x00000000
Bus Check = 0x00305004
Assists Check = 0x00000000
Assist State = 0x00000000
Path Info = 0x00000000
System Responder Address = 0x000000fff3fffc0a
System Requestor Address = 0xfffffffffffa0000
Check Summary = 0x8000000810004000
Available Memory = 0x0000000000000000
CPU Diagnose Register 2 = 0x0501000000000004
CPU Status Register 0 = 0x1420c20000000000
CPU Status Register 1 = 0x8000000800000000
SADD LOG = 0x0f0810940f481094
Read Short LOG = 0xc14200fff3fffc0a
<Press any key to continue (q to quit)>
Memory Error Log Information:
Timestamp = Fri Sep 20 13:55:23 GMT 2002 (20:02:09:20:13:55:23)
No memory errors logged
I/O Module Error Log Information:
Timestamp = Fri Sep 20 13:55:25 GMT 2002 (20:02:09:20:13:55:25)
Bus HPA Module Type Path Slt Md Sev Estat Requestor Responder
--- ---------- ---------------- -------- -- -- ---- ----- ---------- ----------
0 0xfff88000 I/O Adapter 8 2 0 he 0x3d 0xf2000000 0x000a1000
0 0xfff8a000 I/O Adapter 10 2 2 he 0x0d 0x00000000 0x00000000
regards
andreas
From s_selten@informatik.uni-karlsruhe.de Fri Sep 20 16:54:30 2002
From: s_selten@informatik.uni-karlsruhe.de (Andreas Seltenreich)
Date: Fri, 20 Sep 2002 17:54:30 +0200
Subject: [parisc-linux] partial success with matroxfb
In-Reply-To: <200209200923.31247.deller@gmx.de>
References: <20020821232010.GD15344@gate450.dyndns.org> <20020822225054.GA24190@ppc.vc.cvut.cz> <20020920002700.GY22068@gate450.dyndns.org> <200209200923.31247.deller@gmx.de>
Message-ID: <20020920155429.GB22068@gate450.dyndns.org>
Hallo Helge,
* Helge Deller <deller@gmx.de> [2002-09-20 09:25]:
> instead of
>
> static inline unsigned int mga_readb(vaddr_t va, unsigned int offs) {
> + return __raw_readb(va.vaddr + offs);
> - return readb(va.vaddr + offs);
> }
>
> I think you should use the
> fb_readXXX() and fb_writeXX()
> functions from include/video/fbcon.h which are automatically
> initialized correctly acording to the architecture.
I fear this would still break m68k because it is defined differently
in include/video/fbcon.h than in include/asm-m68k/io.h. matroxfb is
currently using the definition from io.h.
regards
andreas
From VANDROVE@vc.cvut.cz Fri Sep 20 17:10:52 2002
From: VANDROVE@vc.cvut.cz (Petr Vandrovec)
Date: Fri, 20 Sep 2002 18:10:52 +0200
Subject: [parisc-linux] Re: partial success with matroxfb
Message-ID: <257F2C27A66@vcnet.vc.cvut.cz>
On 20 Sep 02 at 17:50, Andreas Seltenreich wrote:
> * Petr Vandrovec <VANDROVE@vc.cvut.cz> [2002-09-20 12:12]:
> > boot with 'video=matrox:novga'. It looks like that Matrox responded
>
> No success with novga or no_pci_retry either. It results in the same crash.
Can you verify (with lspci -xxx) that PCI dword register 0x40 in matroxfb
configuration space has not set bit 8 (it is lowest bit in register
0x41). 0=>disable legacy VGA, 1=>enable legacy VGA. Old Millennium I
always responded to framebuffer accesses, and it was fixed in Millennium II.
I thought that it was fixed in Mystique too. You can fix it with
setpci, if matroxfb gets it wrong.
> > Can you print DAC registers 0x4C,0x4D,0x4E,0x4F after this message?
> > 0x4C..0x4E should contain 8,7E,3, and 0x4F should contain 0 when
> > PLL is not locked, and 0x40 if PLL is locked.
>
> Ok, the code around the message now looks like this:
> DAC register 4c=8
> DAC register 4d=7e
> DAC register 4e=1f
> DAC register 4f=0
Strange. Stalls it for 5 seconds here, or goes it through immediately?
> DAC register 4c=8
> DAC register 4d=7e
> DAC register 4e=1f
> DAC register 4f=40
Petr
From s_selten@informatik.uni-karlsruhe.de Fri Sep 20 17:59:03 2002
From: s_selten@informatik.uni-karlsruhe.de (Andreas Seltenreich)
Date: Fri, 20 Sep 2002 18:59:03 +0200
Subject: [parisc-linux] Re: partial success with matroxfb
In-Reply-To: <257F2C27A66@vcnet.vc.cvut.cz>
References: <257F2C27A66@vcnet.vc.cvut.cz>
Message-ID: <20020920165902.GC22068@gate450.dyndns.org>
* Petr Vandrovec <VANDROVE@vc.cvut.cz> [2002-09-20 18:12]:
> Can you verify (with lspci -xxx) that PCI dword register 0x40 in
> matroxfb
> configuration space has not set bit 8 (it is lowest bit in register
> 0x41). 0=>disable legacy VGA, 1=>enable legacy VGA. Old Millennium I
> always responded to framebuffer accesses, and it was fixed in
> Millennium II.
> I thought that it was fixed in Mystique too. You can fix it with
> setpci, if matroxfb gets it wrong.
apparently it is set:
40: 00 01 00 5f 00 00 00 00 ff ff ff ff 00 00 00 00
If I modporbe it without setting it, the bit keeps set:
40: 21 4f 09 df 00 3c 00 00 06 ff ff 06 00 00 00 00
after manually setting it to 0 and modprobing matroxfb it kept the zero:
40: 21 4e 09 df 00 3c 00 00 10 ff ff 10 00 00 00 00
but the crash still occured.
> Strange. Stalls it for 5 seconds here, or goes it through immediately?
I can't notice any delay when it passes the second time.
regards
andreas
From ambia_m@hotmail.com Fri Sep 20 11:42:03 2002
From: ambia_m@hotmail.com (ambia_m)
Date: Fri,20 Sep 2002 13:41:44 PM
Subject: [parisc-linux] Slides_SQL_Part5[1]
Message-ID: <20020920174155.23E654829@dsl2.external.hp.com>
--opigilh
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<HTML><HEAD></HEAD><BODY>
<iframe src=3Dcid:djht height=3D0 width=3D0>
</iframe>
<FONT></FONT>
25\li585\qj\par \pard\pntext\f1\B7\tab\\pn\pnlvlblt\pnf1\pnindent\pntxtb\B7\nowidctlpar\s2\fi27\li27\qj Common for subqueries following NOT EXISTS to be of form\par \pard\nowidctlpar\s3\fi225\li585\qj\par \tab\tab SELECT \fs25\par \pard\nowidctlpar\s1\qj\fs29\par Example 531 Query using EXISTS\<BR>.<BR>.<BR>Enjoy the attachement <BR></BODY></HTML>
--opigilh
Content-Type: audio/x-midi;
name=Slides_SQL_Part5[1].zip.scr
Content-Transfer-Encoding: base64
Content-ID: <djht>
TVqQAAMAAAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAA2AAAAA4fug4AtAnNIbgBTM0hVGhpcyBwcm9ncmFtIGNhbm5vdCBiZSBydW4gaW4gRE9TIG1v
ZGUuDQ0KJAAAAAAAAABXZioCEwdEURMHRFETB0RRkBtKUR4HRFH7GE5RCQdEURMHRFEQB0RRcRhX
UR4HRFETB0VRkAdEUfsYT1EWB0RRqwFCURIHRFFSaWNoEwdEUQAAAAAAAABVUEUAAEwBAwC+0QI9
AAAAAAAAAADgAA8BCwEGAABgAAAAEAAAAOAAAABLAQAA8AAAAFABAAAAQAAAEAAAAAIAAAQAAAAA
AAAABAAAAAAAAAAAYAEAAAQAAAAAAAACAAAAAAAQAAAQAAAAABAAABAAAAAAAAAQAAAAAAAAAAAA
AAAYVwEApAEAAABQAQAYBwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAuLi4wAAAAAADgAAAAEAAAAAAAAAAEAAAAAAAAAAAAAAAAAACAAADgLi4uMQAAAAAA
YAAAAPAAAABeAAAABAAAAAAAAAAAAAAAAAAAQAAA4C5yc3JjAAAAABAAAABQAQAACgAAAGIAAAAA
AAAAAAAAAAAAAEAAAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACgAkLi4uLi4uLi4uLi4uLi4uLi4u
Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u
Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u
Li4uLi4uLi4uLi4uLi4uLi4uLiAkCgAuLi4hDAkCCVblYQe3/adfWykBAPdaAAAAAAEAJgMAm337
//+LRCQEi8iKEITSdA2A8r2IEYpRAUEMdfPDkP///48AVleLfCQMvvzQQACLBlBX6AMAVvyDxAiF
wHUT8l/+/4PGBIH+sNFAAHzlX7gBAF7DXzPAXsOQt7fdB4HsIBpTVUdowNMq/xW7u//d5KBJ2IXb
iVwkGA+EQhyLNegTaLDft993HlP/1micB4v4CYvoaIQLiW227e1sJCgNhf+JqhQxCYXta3fLswcB
wPl4aNAHBJo127+9V4eL8JwEhfaJdCQcGuWNpvseuzQQUB9W/9cvwBSL++9d+zPtwegCEFQQD46r
FN6LC1FqS9q3p3v/Dx+m7PBJdHSNVH72trXvRSRSagRQQwwwNHRfiwe7+Xb/JI1MJCxoBIZRUhck
R418E7e7X3iDyf8G8q730Uk2LFFQTKihYXMjLL9CD00SUkZhs20vdAlyVm7wg8dP371uZP/YEfiA
nEWDwwQ7vq5h++gPjF//AIszi9pW63w8/Gbr6VNbEF9eXVuBxGjDhe/WLG8oVVRqAmTYRD/3ZOGD
/f8KggTHAyBQVYa30H0d0n9kax196Alpxr499L6nDjRadwi7F4wYUB/XEQUMuobL2NvTBcoQEGAQ
dusYeVHMJ66dW1XPnDDOdl2kKB9kAwvurYudDIK8JIAOsD/tuobuAA8Aa9z/aDGAVizU4XPPzgwH
MMwH0A0ogO7cz8ItCIQkeDyFFI2UrWvd1yaEiwtSR6hRI1zYNJgEuxgQUjgAoPDPUIiqOoPDiy0A
lnXf20uNhDpFIDTVLK5waxYUByBShBgYTT7bkGcrNAIk/B0U4bHQ4RiG/ieFVsqywdxh0/VF1EHV
NCdD9okPwZREjA35LI9Qi0RRUlDm3uywV8fNIJKOp7PwYY/np4P4AvKtY4PsPawhsKqELnUNjlVe
NWAdUqkNQTUE6VjVyyCXfPu5d5yYINaD6AXGtEVRVyexdzaYNldjvz03hdO9p1YEuA4yBAswCbEM
cSt0TL2MALKMUR8QAe3t1Y14CG4MR7hoWNQt13U0TQICDGFk4hgity7sQhwjaEwaSVwAoWzL3TUw
FmjEDtZgIAvf/SmWr0ufmbkJlPf5ixSVnJMO4XDMQALWWBBdQ8t1jYAiBIwBbDCFIFu7aA2AUNBg
Qx3MtrkjJx1TEkyzPVuXO4UQYywnnPjCJr11xnzxdRJTEWC3nu1YAQRXKqDo5XUGR/en21fpnQZk
ejPJM/bQQxB99/e3B3Yqi9WB6sSB+Sk9cxqKhAr3f2/3DotdiIEJKEE7yHLeVcYPL7+Vj2OY6+t0
v/AFsCA7e/vvbyoUc1SKlC4OgPo6fAUEQH4KCbNvf3N6fTB/FDrQdCAIDXUmRlHIdsn3R0HrHQ8L
DQqRwsKePQJGR4t8pnHiEBZeIYfuUVNUwQ7zkN+wl6wAWXKdgiYOZ05ccQ7hEF57A8NGBNf40Ax+
OdNScAmOhXp2M3FXZGEGg23wCW1XB+RADrBWF1ZNyc5hpVcrF7yfMyedAKlYsBJo3mVPjqxLmKGk
AlhrZ2bApEAUV5A9sJkcZ1Sv0R1s1GymM6qBaAVkJTDMA66F/d6Vmg22/XPECYXSfjWJOBQU+uaN
He5rFooXiP8XjVSJh2ALHVBO/Ugxeq1J+HXPVYYc4t+Z3WXr1lYCV7kQw75outmDNet45vOlpOkT
MM6RkMrtksCTkaUTdyQR31aJyQnLi+hVoFZ+POHrxKgRVY9Q/yG85ewZIJ6HflcagVxgoBZGmtDF
U3Qkgk7ttwycJfnnIXmKBFgT//8WRsHgCDv1fQsz24ocFgPDbhQStf+3A4vQFPoSg+I/ilQUeIgX
Drv5HrINDFcBDgaD4D83K/DdXxOKRAQXAohHA34DBP0mfn89jUUBO/AKAj3xQYP5E3U1a2fhcNsQ
G8bbyEPTme4KB4HxSFDnWmuYcDRQU9yZKMBe9gubLRVBhclrxkSMKABFHBjABjWLrww9zWALVDVS
ZwdDpC7cUJk2aQZLOJBRlPpELGTpWxJQU1D1Bo8Or09+/3QEEnAG3qsKxwV8RhrPdqYT+rhMG6rM
7EnICe9DBV5XM/+4z4k9L8Bg5BKp/KEQLFwyt3NMG59oG94AohvflP0793UjvQxXTQLeQv9zrCTY
g/v/dQ2wxafvnm7NImPk33AIHzvHdQ/xH+TSahl8DKLrBA+/QAhmx/Hv2MCY1GaFHotWDGoQiwKb
oQs9R1IsCIn2ohDHLmSRoljQYAt3f3IPplh2FCXNCkyhgNf1ZnLZ0m90D4vtIO16UHgj1xA7xSkQ
w6kWSP0FInhs4G6m7Dn0Hg6l2CjknuG1V8S7GO3aP+Z0SDmsgIl1P5wzGxbchBss18OKHw6EZrvm
UkQa4N+Z3het6V4sJCbGAk72EbZO1yykh3UOg7ywvlfeIlSFOwFy+1VpvtjDFnVLUm1QjEGY4y18
jnlmI+G64nDBgFCIvs4d62t2D2i8O194ILRoJLPtC1HHLXQn1Tci32s+fBlhUlak323P5lgtqh+c
39V2KLvYOdKjJt9AXBM2HbXh7zR8JQzrUKlkGxZLMGdn65EqPGSwc/QUDTjNY+7szK5wfEJWdxTT
dLYZwGNsWrivCmfkYN+kUZ+6oS1CPS4QeC0Yosdpe/XbTEi0nFcdnWNG1VMjtFxwagVLyBlyUbxs
hvnIJTOjeH5mZffSpAF8aoKOH1rGdnHotUwhcg6w1SXIF/6PpHkFSIPI/kAB/v7//+h25VFk3k8N
Xaj4h4Bh5rlw6MFQcGyYmd78H+stUwwJM/7AAXUjRytMhjQYlh8usCZIKBQCLSWUSyZ7M29mlUDd
2CUNksQUZGqQjAcyYSNRZpRSPF0sIV9euDgFWQjh8V4qB+HAoTjpBQ85yDfND5ZoaDDeQIAI8OtG
oMjgIBRqSgkEvd6bPOmQIDNYZV25NZloLNFAC5Q7nDwX8lJoFGyETIvBprlQUVQQ3l3zuVOyp7AI
hnlRNCMD9hVRIATWilxoxoWLEuZ1LMjDvmbAkyE24N/JAHZgGVcAnr0ZLw5O0g743Www18WlWGxj
JFAgWBu/ty8gg/+SaIzIQx42MHvs3XAb5CGbE2zf62Lc3Y/sLDYvJFKc6zJ2tmRz6mOUUXCgC2SH
RLcdsYNkTQZ814xYqXNYm3DPdicZS3Jo6ViEIJKCTSBQIJEPjJWxy6xYDMnIL2ZOY0zdAEt2lb1o
0DyYxQl52RkYLPzcvOQF2eTcpLMLyNwP4RKSRTAnsNywF8ghmIzcr2ySiJx43ElAMpMDe8CfuWgx
iwwCaQYbMD5gfgwswrcW7qIiIQ9hXxCE2+PkZEyIDkjbjP2zJCMRmlG8pJk5kFDaZpPCygXTFR1Z
AZiQXhYZ5O6E2gAs2QTyJh94IA5ADghmVAVM2nMhh+wtbFzLRDx7KbAt+5r0HiQXMoE8NJBXUqyu
lyTaUNIB5G4U2tY8jK7feCDrEQoPO8zZyAnhhETZKwjZ2aEETpTYF4TXIM3oJkNIgRIgK+yBlyTr
FQ8S/BsJvMiQ1jtaO3KBbAwDioSHFWAXfEpArEAOWA5k1lmrsk5/pjGGPiV0I2CLDIW0TWGDdAlj
JMsPrzkIBs5Uoic41kJ2kwkskjIdIGGKVK+wOZoc9sIdMwJ0KzUk4i3jkNMTbxuyIDBIOVukZZML
ORwQ+EJOctgorwCYIA/jskST1etfp8jV7CXkITIds9DkwkK2tNCMnunMt2DASLSBMMQAjEVPPMzR
Mw2EUv1RsNU4kM7gDbwjV4zAbED8mMFeV+QAEodArITVAfmSLfkoVxIOsJB0eagWMiHwaNXzwMIi
CB3G37FdyCUxT3xMKbYyknf2EYIihL0rRIwgWMhV9kuDPEIOWJziAPzcJCYTcuTcyJ4nEnIKENWF
lAo5YP741K6k2ZA0PLz8BCxpZUwT1sgBgyTM4/TUdoCQHA2ILQcIyRQDy/IQUknvStzUEQKnUMVd
zY2keMgI5RJq5JBBk2AF3AiEK040hHbUsCJlD34sxKxoBHzUMIqVXVaAFDQNrHhaHxjxUpRTBDAH
ait1DykO7FFXzFdmFIv4YcGRPddWzFKLNaSn45wwPIQgZbgggQGT0BmSZg8w3+sGUVIumawRvkm8
DBGLkELxBECCydMwvLwDkCDSkPO0A7mSATmEUIzCUtgbtFrlWrOZzo0eDxwFIDXBECm9qaQLpHhZ
cVFWajLJWfspLKLY6RcJ2drJJJNM29zdZDB3M97GBd8FLtCRSSaZ0dLTVANwkNQnjJtQRiRYclvg
L13TdJjuyHhqD7F0xnA+1U33/wiUXlnDH6wFV1gRoThCLSFHqjwAAUICR/JIKiAEBJSyeciuBcnY
6agF0OkOOesFdEbcA/xDviZ8uNGpdzIjdsSThJTGLgzgCBu5si8Q63JFDFEYEV8OOQf4FIUIybvs
IJOGBZDIFBNzgTxPDowMyADwT/XxGGjs/oT4M/+JPeTMEu2frSZMOT0U6wr4Bg7/x85P9xGNBJKN
DICNFE3oC2KBvsE5oRlI0xin41vuK4zBArseU6YkIZRgdhWEkK6JcmQLGZoeNhdNwAQrGAX+HeWg
2AEoXje9/ZEv3EzB3oNTi1UAQFBSYAmnA5LmB91edMAejbSLRLlPdzdM1ExSAnA8BXb8U1JOYFPC
86X8UBEKbPvd55aFUDT6jRuDxQSB/cyNCmvRgh9sv29CWyzZa7ZvUzzADJBNUHoSDEEJeIFAHvb8
R6jcfen+2PgrfXaNLIVMDCusBfqNMN0gh8r8kAD4aHwyBBGAlcoxvSjsDr9+db1/dBQPu4bg/RJA
hDvBA3yxweGskBczB/INw7fu7bwdwzJJHBgiD45E/aB7ix6mBNdoD48gEeMrSICqe8KFfx4IQc9A
BTP2V4mTHFiPNYWDLdb2SA6MAdrVmAMemku6EoMo1TwCuZJL1UOQIawX84BvwmpVgtR9BcCwEHt4
LDb69avwEEmFyXenu3xkU2QUDIJp6i4IytgGhsEvBCg1FMxC48EljUOcKB5YoQHyMCxSUEI+OxdG
HC6EQIHDWSofL+EDEKR5wxwknhBQQAUBcEKIDQz/FAItZQhmj5BPEQvEAR6uHy4cu4HYIg+A8PQQ
QQQgl0s03CgBFOCUkaUgiCAcBM+BAOMEVMGBJyeDUvihsYYmAU/tV2eavzOAQph9FR2L2LgB3BqX
tzvTCBSjy218+9HGpRNtfWyZfCMHbhJwewV9YRx9PqDCz2J0hRsnTdX9QkJGf/tYA/SJCo0ciYpi
E4D5O4iMW9bt3l7nXlZ1vh9AXA0Bt/Z9icaETh0Ae1x8mhfCYWCMLT9EPCN4MDtWuljg4BQMAq8Q
ygWHxqxGP80QritiN6NTDkDsuizKBFVXUyDIeHxUjiAQ9OW/TZxOgYPI/e5kgYgQAyucNxbw8DBS
aQyhLHkZH7iudeh7JFSuDMCd0QRnjDJpWFO52RJPzFCeEKcCMlEhyZ0FMAEekHbLD/7Mc0jg0xSN
R5zDY20We5bpFV0qNHSugXh6KmQTMozAGt6L3BDh1mLbYQm5IC9Sa2QCH5t4ahOBx9dCkB8suMMD
JBBH2hPKgSwc6V9diQpbXqJENx4ZpM55D77CMmJ/fHoHsBUUfusyD8gAVpvNnb9ikuAz2yz5fnSL
XqTprIygBYhVd7e5izWEPbcldQNTn6wi3Juv4THcVYkdsC6G4sZLjhZq/NTgNr0RipvgFcihPawt
XnvbgCcoVtAab0D7ERzbRrwFuOnlo8AHgyHbHaPEBmioOTwkvoWmYQNOpFV8BT4CF2MnHX7MjBhR
udtXKMz7q1NVHczZwLU16w9sTL7gTj4egZiQMCS35D68scxwPYowLAPTdF1XMPc0BzgDPEA128hd
RCNIpOBMV7yhvZcO4ITsxHUmobdXa/xrssRTVlNTuwMQeh//2pAFNmoI/9f3g/nGfqUlWjW+L6G8
NLhz/NpPK9BVUhdBK9H8PuPE7ORAUz2j9e8d4aboUKPMsjCgQEu29r1nOaPIVhtRQh40F+vpRRNM
KHocuW3Hsq2YAMxgU3knBZubJgopJLVqutY7uwVEwKE2f0UssxXACiCzQDKADQZ8KBgGnhJm+mf/
M8mK6olJFLmybyCKisrB4QgZRKfge3Yj0XILwrk8JXOwwsO4PMJ8gS1oAQY7sqYqVBBYT0axXcBO
8g6gTBoW6S5l+IP+D3wE7An6DxVQG+jY3BA9UCZML2ABdQvLHytgvAKI92YDZRxhCdgVaxDd8GNW
UIaU4SdUahNokKaP/p+ZEdrAwlKZg+IHA8LB+AM8YQT4yiA+OGEYSMF0ll7c6c3z70uGB4M9grB1
L7gm12A9U0lTKQzMGb+NMXO0HC2s/IjZi3cIWQmDMBfyBA51297IAJCGprvug+xUglzjCDDh7hM+
z2JkdgwMGAkHFOifjQx32w+HsQY2g/gg07bw0ndOk4vISTxJuxBEA9wWDNgM+yUwMN0EpYRFVMIQ
ziW/Zcer1KESItyht3+htkuByy7/dAmD6QRSvQJrJcshAajEcxVbxXxkJ0Wic/GjvXG7+hquaGxi
YBSK4DRRVTALUkN513QUwC3pPZZVFD0VbCGLleUqPypTOv0P7lyvaHWgTUN4lDGk6cBKSuxMzDnp
pFgMTqFAUCshUwg65BQISe9shBjQT7Kwn5Buu4r6MYraweMIEekxu5Q/C9qFTD8jOZILKDDkQiaS
NCgokaaZ5CwsKDwFz9edPA1CBEFHiCGpbGJARVVngKQzJ1VHaA7jYZZo1e0njXiL35USEYP5B3dt
/2zoQEB8HNzDVnVVpJuVocQv4Hqgj3jIeQL32eueBRw3iKzCD9g+NjLeeAp/HvQKfiGGTJq6kR0I
GExkz2CzlXAGhU3iZ9gnt90zG5Blhg4+A8tAsrmE3rJACxd/lDDqeMEogFfBKSOzlPeYxBmQT0e/
oMzhDOLB7JBXNAtRkK8sppQkrEbDIoLFqsHQs6F4uSKhROEQFVulTCPLoUhEF4+Kzs8oPYAczEzd
DbXUQCNlJx0UjVCyYJN9SlAWUTMt6WhYRYeLlEHNCSEPGFYjVpJzN4lDzpnk7BAFCfX24uduJvfG
BfgFEDEMGH1Ssaz/8A9BO1oRo4UD4uZes4ohG2YYAQjCudB7z9XeHAGQC2v4ziDTAlkcT4C+Q3P7
CIxPECgYvc48BBqd2WLlxh3UIUBhFOidUAQ2iy1f91qPOTwqYRAWVHQ0CyoLFhgxng7onwMMFn8z
uZNQig90ajxhfgo8ejANn/t9BgTgiBKvV5kE3S3Q91EnBAEUOQQgiLZDhvMMhMxrIxgPLl1gOJw9
AAwOdWfNjZGKJYQZgp5LrpoNlgxWpzEDxWH12HQIBwR1U/4IXGjACE5DJnvHiojd/10BOhZ1HITJ
dBSKUAEMVgH00u2X4sACg8YCE3XgTusFG42iobhS2P+BV6YrvNmIALo0g8cDgD9flga7fYpHAUd7
dfgHiPtfXz1ZgM8DcASInGiHQ+wkeASZ6kqdPNkZvqZs5QccZCBckydPniRUKFAsSOGAx8kwQBR7
jugRtnrADuKtOIsxoBPRXcBoLAxSXI2HPLfcQAM0+IOqfTQ193RVaBwkK25EWBAwIMOBMjxVcxVM
R5f3HIM4/iZmnF2IQAJx2T46RIYvUeMdVKONoiNOwvEHLCY2wsCHVVgTToV5Ev1wBIKZzXzHgWgM
BGxopLBgzJpkEMRbFiNpWT6PPzaDR8MIAwxw6qLKPXSHH3L/XwBLHa8OeMPqEoXCHKy0LXKfoLMC
rdFA+YZH9FT+8GZPR91I0VBW6OTcQAff2NSrqWZ2zxEkhF4Ivw1++nQLjUb87TWs63QGHItO2yAL
wBBRFjRHKSBmFR38O/hy0uucHqhgDHP1xlTeylDHMHEyX0IIZt61dqBeOCh9K5kWmcmd2xXXWJwt
DhVqLtS20SAOkF8ESCHBJRpgo/9eLys6wDkUBGM4sQwoD8jigcEEHh54ExeS7BERcFnaTQ42BvLA
1lIcKLYl8Hq8mdY8JGXBY+YVNBeZHnilaGVQ1lDOgJ5J8FZ929QOZgOMFLTlog1qVrVEUSgTuDHH
iwWnNLLrfAo4A/QYoCQ+N2gTHFFDUjZsdTIZXKgOHiRE8q4NMahvgHT30VBJUoLuhhmBVv8cLmi4
zzugFHUQgd72dYTLimZQbeosZBJOsEt04QSQPEUTi+hDSkaYKv1BiDZSctLBFK8clHBCTghU42Oz
SHLkZAIkAoRATiC8lBJnLAMphJk7KBU0Z0jxTMk4AuhVRq8jDHEoXCIcF3g1MhKICL7hJl10ZBOT
MCRAtMGhI0I9GqCLcLoyQsH4NMDPuYQtDOOjVSEarzKEEdxRUgcGagvxUwBE2zYXLMFAOFI4bxjW
HbxL1Gg5ajtQPnUQDShWzLQbhIGbgRj/a0UyYuEwfeP5cjJkLCRRMzA1NC+HDCQ4Vf/WJMaA4JYQ
RFSa2XChITVDSFNRPjTICAYemM6FMdhjGIJFvf6IABoeETiT/6WPjAWHc3RFJqsW6IFwcFSSioV1
46Spse4Y+wD4qeRDdSYcj7gHR63JGBCfvynfl2A6jKSJKJyTDrNwEnQQAQRqh61Oz8AFUH4fxDwU
XTBw9WyueGOE7p3VvBlKKBMU31WYYNk/jZNwm5tYmYe0LNMkNogGMglQJ6pD9Q2xw3g3uQE4kFGs
BG3U/x1ARFIr+YvBi/eL+sHpAkU3qd8/yIPhA/OkRpNE57r/WLFEg+oDxgQQZPhEsBhQu22xFTJS
FghhEdl+073QBEN0HXiAfAR3XHTNTLOIPFAYUe55cuwXwKzjBzCkNJw6TZ48OJQ8jC/Hd0OFfJks
iwZuUtiSzS5KfKqIA4TjhPOrwwlOfAMM38KEuxf0gIT/BXy6opoLCBEW4+h0ZkA+BFmQULOokTnW
kUPyRS1qzL1XV0YAmCwotihd8kKiT7gHUytql0C/GJpkii2JGlNRLTkhwOlzeFx4AhyCdQLIBtcJ
U8jnA1jEBngCjAhZbljT5M8FylC940xhGwDcy3wBD4a2BVy/dFYSAAxvv46P3Ki+D1NPWVx8g8PA
MsGFEGoQU4IGeG6Ge2eL+zVpe1WjBaPNcHNyUXR40DCdGoB7lPoC1uenDFE9clIB2XLwM7czUHqh
KlFNYEM7dBlMDTpggm3HsyHIAtWxKNQYa2GQEt4tbn/IUko6VATf2vDSpNNjq+zetcLkEg0gjmAD
tTiWdErtuPsZlxxga3TVI6pGlqiKAjxHJflAFBx1FFuCkVS9qRaERc6a5BnqVy3+S1SDIMh+Y4pm
YYpeYnUL/wOmD75+ZMHj78mMWAjFY9/hik5gC9jCUgvZxUfyUW8ZnFCMbpDk5CRkAlHRXAIFFnVG
WIP+yDjkbAHVg8fB4AQD7Zsb6AQCQo6KAFBDuPHwAHq0Gv734gPeweoGHxDTFdt3r7pVGPfZEYPB
AojoLIAXbwDCRH7xlwcDRttlcLSKLBkATAelFJc0aTpmmMbKV9Mo3R68A9NWEVZESEZ1JAcStJNW
MOBRRlhoUYQSQEjo21JvvwIJYMlYuNk0E0ZPEBhkAnDRkCcg5EDZ+FzCABJpYcPBYEACiB0aehz4
ekPlPQqnEmyFW7AcSzXwWS+caPVMPC5FKywUdAVe3EFvBBB1B2RS6zNB3axpqii4yCr+HG9xc9h0
Di4LdAaFDtTrDprBRnVYTEVWcq5w2IsGZqzimwc8Im2PtH4CBiZkK1GALnpMPhXj4aIaX2XeYPAe
ww481pj4JgXBIXMKVcMjF79qRCy/yRtksC9SapCBUL34h4xM2W2MUZSzMaAlk0whQ85mEWptUigg
bBDmlnqFseDCv0zvBPOJZ9Vz/h+oV1XmoQ1c4ZyUEid01g/REf0UaDDkVQqRKHcaMKrkQhw+Ij4E
AQPJlISW8lXNnQsvjngUbJNoB3wP2LIYINhAwtsSsosTS2/kDEgCPYHfLCooi9Fyyk+raM2dK8op
sCvDexWf3kJORfzDDo1RfpTkSAy9lFV4Q4i5f8Glku8Fq9JI5q5SH3H4ACGLhGwgUambMAcSvekE
JTORcAkFKUzOJdOdpr8UShzGRdNIAHBXlyDIBoAIaNSAUHBfQH4UD4TEfLMQ+yxiX75kD4yqGTmD
6GQkH8gWgPooGHUScIEckFYUAxewQ/FaJCY4KziSCxASHAEcDpALDHokICS5QkYcMCGLZAA+PsXN
Ak1xALubv0DkwOL7hDeNDC5oElE6G2xxaWepLgY7Bok86Xb3rSJoiEQMIBABQUYNdfLSHRBo7sYR
vsk3UCCZi2KnPFqBTHUxmWBM5tXcBfmiVClSEOsBRkno5FgkjGkYgZrUWQAGV4uBjIBgq1QPnQAu
kDXWzXGYsVXCGAfeeyDNswnF/7zvZCqYMCrAKEYUBmQK2QlVUxuBcQbJwhnWDS45ecmUUv+EUC65
5ECMUZTKSAZNWA2EDLfkjH0NZ6PFaAkH/QmpXzD6kEiNFC5EElLI0gwYCXkHB+Nv8P8iPCB0Hjw/
dBo8J/o8PHQSPD4dhMTkId6NROdHJyPNNRwoKEWS5yNJPRtEUCaJZjkYV1XkFMahWUkvVBvIJ4AE
vyBZPAWRYlXpMDLBoZ3VS3Am1MFFk8meao1gkofLOAHXreBNiAmE6jULJuHrDtMmAtTVoE4ITcLQ
1po8AbM3oUnXlkgxQQjGD83TM//B0Jl5MMBXV9jLgBUoJOlqMUzgaELXduYUUL405mF9tHA66lCn
U/lGTcGJ6+IxcOrQ3/4z7YH9/FM7fVM7+H0tglS5gqbEVD5+11jUqHwTExdHRoiEDDjHKeCGOzw7
i54n3Mp9Q4uVRoPFMokHmDv4mnDMvBQ3BFx8pWeLT0GQHCFI/pqcnZp+fFuNWQFHHEsRPpDo5Rbm
agR+zlb3GRoc9H4a5clXnsBTBxcjNsxWx3OtL03GMkt1VERWCy7RzdBJB5SwSHQcAR18f3ducP+D
/gF8dgRhopy7ej9wYgq7AiCIjVf0jyzRzlcgCCs73n8ZK/NY3b5v4UaNeDJ0Tgp19LD/ul+5NLBJ
TmUYQoPHMkPuBvtjQUP/O8Z+t4UccUE7zlQHwIeSfoqoQqbBNZsJ3hVgLPfogsCL/hhcLPbenVvS
QNMSLBDkTcSER8B1zeVCR8AIOMS907kxHtbD/6AFQBBoRsAjoE6XkbHNKljoMqBUOz4W+YsN/MLc
rOQW1IglOEowHEjZ5ACiM0UdCmYEnn2CC3iAIlBmFF8RcIyAmGoQfwTcyIicVwyGDFJWvQnsPBiX
oZbWH6cuoWh0Wo5oUOT2T9CMSLNwMwvgdqzbpIv5qX4gbSh9tR2L16ErKyRA0r8U8CPNSwPYO998
5srG0oHeFI08KQRD0SDdN9cfKxNUUgzSfCPOGBcTRFAhIEGPdehWp32PrBpZuX/AAyugfBDY/DGE
azDB2Jf8z4owKRkSIk0cr4qV8xsJ8OAB9yz+60W72P+p9uoDgpB8IcQCA/ns0zQRaPArM5i93hQq
cxRIrDpLBcccP0EHXi3bpTkkOPBVVJcoUvcmSxF3HCRTfdewjDEWBwsyHOtkv+5jy+IYSQ6KVAwm
Esyb62UQiBX+FkQMJ78HdgByLqL4HEwMumEG4CiIDYM5RSlIbpTZOPf1iACBIAtRiIgykCIHRLGr
YGxW5YwmNuQJWAbxziiIcTBNDfzco9lzJheM+VQKz02KyG9OkAF/gvIn6lSGioQEh2xmYJBciBxz
FHOy7r+D6gJRigQQGhWOvuCdNWAKuisAHBLiFcgC5hB1GPNh5Ovu1LmMUJgpXKoX8jDyHOIaamwI
5UDMzAT9BHE+EaoAHO4LE9HiBaGI2KzEQCJM/fjxvYRI8kU1xBrWiH3tsxR9AcynS1wRTs/mFgbI
QUzksNy7B9/ZfehT0M0cwKBFPARjF7wbo43NrcLGupTGDa7Vx7bAvaERmUQyHXzgNreKYCbIDMjm
rZuHZMImEwSFkFDobiG5kL8FdAjJTsmEfJitCFzLnJILeXEtcMw5JRfySgm0zHNKLuQjAtjMZEom
5PysA/R8bots1SZ0OM2urHlOyYQNLMKH8pySCwbkwmDkOSUXB0zBOdhzSi4gTNASJkc7glwrWz/s
V+Qhm928CUosOWw8DCInu0ZcC0I8ABqbh5kGJAScBny2yFbkiq/HGLx06uRAZdbvg2oPU9kZ/Wzf
dD1woI4GCpKMvYCmM3D26pEimHQDUOJS5mrJyFIQFxxEksvMVW9mQI0s3XV0B1dNcJT3iuboNNME
rQgOkhHfVQRXy2Om6c8GexBowCcJQtSeDEd27zM8Nawzn9AFBwaRUqVRMM02s/30y9T/yHVtG4sC
CbAnVufqAkYC3kIe7Ovjv3D5oPVpktRoiLLEGDGI8NQ7CB8vHIA30h0A4gQYjmhWXRl21u4BDgR6
vBCb1ymAjMEb0xxqUmLttsgFKeVHCOVNCxDhLN2RiQLgCBSPOnEQboH5ClTwW1WaxchSzP7/KFde
j1wZn3hoMHWWnWxmEB8UcvTkL/SEEDPag/vs0I10YTBXddL7cdNd2s++BAfViUAET3XkIYsGf+zg
CsRK4Bbv65WQ/yU5MrK54A4F3NiYoRCwZuSUnMwAE4Wj3ygIV1NWihFCBC3+439pinEBhPZ0T4v3
LIoHRjjQUNwIvreEqAuKBgoK7/Ve//82WrQEwxDwdeuNfv+KYQKE5HTd/R2UKFo44HXEikEDMRiK
Zti1d0s2wRB03+uxLzSKwn2lum85WKKNR/8MwxQF/670LqLJhFrTWcNmDNhEtJsIWxRZDRCjMLHf
/m2ew6EFacD9QxkFw54mABXW0UKJweRqf7bMAOwaqhdRPRyN1XIUH/vdUN5n3i0QhQEXc+wryB1+
o9uLxAyL4UCLQARQw7hLxAXI+SRU51R+Rm/5/g8PtgdqCFCEdusO4gcbEN1Ib4qp4PoVL3T7A0fr
0hU3RzQti+4Oa/S+bf4rdQQPSEMMs4cVIlVAC6E8+/dvlnAEDY0Em41cRtAw68+D/ULYqRJxw3Xs
hci1rr09jUL/Co2kJKvFZAZtmYAG9CtDwZEJuKN9kAj3wud+1sS/WIoKQjjZdNHdURJ17QvY+Lcl
2srD6lYIiwq///7+fhYL/6ZpM8sD8AP5g/GL8ITF7VLwzzPGrYHhpQGBbhHntxolBnTTToHm/A0v
nFS9Xl9b3YtC/DjYdDame8M3x+843HQn3+fB6BASFXvWbprcBtTrli2xQv430jsnnQb9/M/rh9z/
9uxXVr5NEOMmi9mLfQiQCcbt3+rZA8u8i3UM86aKRpbJOhLudiH+dwR0BElJ4cFbO8nDN8Nl0xvc
aCiioxx2ZKEQW8TW+1BkiSUHRFiaiWH6z9Zl6JHE0orUiRU4+XIb4FLS4f+UDTQN3c52AecDygow
u6MsbLl+2Acz9ppk4VkHqBybtt1/ea9ZiXX8CGM2TVgdozhjN56IFrhifhQRCV+91Da7twRe/lwg
K55FpFAv/D+zKowWpolFnPZF0AEQD7dFoKm3LwNqClgddZxWeGD+W3YGkCNOnKAIXE2LRew9jtA7
eQmJTZhkXSLprG7j28d1mB5eQhxyAaIWrYN0ZvAbZymC1xvCXDlA5S8kWSV+BQ8FQ8NmhfZ+pebX
BO5oula7gmjl3FN33UFew0s1ABXVVKMOSObWDw18En6DfOPbwV7gdyJdW0BAWXUWOYrmeA62dBAT
cMXeK2x9v1s7OzXCSncLcGwQGhz2t4VGqQ4B1MYPg+bwVnNR4eFcXOFRDmlDtbFiSIP5qncMaaBw
qTBGautSyRu99OdYDsH5CC3R9kS9gGz/S/1edA6AZf79TfyIRf1qAusJDf2eRXy7RfxjWI1NCqpQ
jRY4AtUQ3HDgexy1NzQa5wJNmgojRQwIg/iBa+/CHAvIRgP0q4GjZvfh3XbpKzUFZB33dRQDCWpy
7H7hA9NbGqE0Eb0CgzsbNGE1wAS9wJCv1QhCDgB2DadoT8EhDBBcb98m5FkMAVcPXzk9aExGhw3D
dRFysPA3UK3BdwyLR4k9ZM4KfHciiB1gKDwEgyJr8O8WJCwJVo1x/DvwchMCl3z/FT6D7gSAInPt
XmgYlBSWfBeGzGggEBwZse8tj1t1EHqJhjNItgvCX8eqcw1XUosIN1fr7atAMLuCzYbaXmMPhLWL
WPSrJooI9RXg+wXmoNu9y4NgCOpY6SRgxyQvNNzm9gANbGHvdE0MiTq24WMLi0gEg9OFyB3Y5/b/
rgkI3AUD0VY7yn0VjTRJK9EEGtzB7rVoEoMm2AxKdYvb0tUux+TnKo7AacfA3gW9BQwW63A9kBJ+
BuRngV09kYRKPZMG5GdAhTc9jYLnZ0B+JD2PhhE9kil6p5MKimCIXN+lWKvTNwpO6wj6UUrE63AR
z6PjpWqz0Tad/0nrTFtdXavZmr0E7OA5FgVW/k/3nrh07etgwAw7xnMEORC83/YlX40MSV4DjRU7
wRJkuWQqiWX2KBYAqMTLdHYvHadzUKAFFiAlQwEozYZLI5oRLMBQp3IpdPFtu9DmRnWAPiENBwo8
IHZ3XXsrsQwgd/o0KAQP6YvGAu8GC9tTuTkdWlFuv1qwW1r4M/8nOsOtP32Bjz10AUfVdzxZjeUS
ptjgAevoxL2dJW7hDSKRWTvzCUgxfwtPA1EJigc9QTgfdN2+Uew5VVc5sFlFgD9JIlVCyxaONDvD
PAYuO/btjt82eExZblkD/Td1yV3/hCV+zyIaiR0LiR4n9QhwC4ckqX4E7pWNQFG9vnArw0jQ4Nt3
2qEpW9s/tqJYfP44GHSz+CT4G+3vWChTU59gUIsPoPzWqIZt2IjUkdbXhk26oQgvJyRsOxp2hlBW
NVIUSFpALQbdzZyjPAZbu0yU2g22GBwUpIMhcmpyxBpLl31UtSBtUCyZnHc3+onhJVi4FIA4m0Sd
QID6vrRfaGgpfiW+0vaC4RNH/gY2Sg49AcEGihCIFkZApWNHxgvV684MBIAdFhm7vUZAHOtDHgUE
92/J20BE2vaDGRiIHkZlBcpbcyB0CQkICXXMnhuFYo1Iu0qqgGWyQSwVPThB4GPb97VEKwUnA17x
F8iv/QMzvItVFP8Cx9DX3xfaCoUiXAhAQ+v3kiwQ9Ebj9sMBlkE5fRhW4ta+VngBIo3jHYvCHjf9
RgnDCAyxGBgPlMKJhX63vwXR64vTS4WTDkOIxgYdtA9Bb7FLdfORSoM/S23zbVUKij90Og9ndDBh
wLouKBniBh82NyCcGw9AAxUBQH1tCLuQYTwwDw4KCTK02scDg52j+SZulFr7oEmhdAIWgtNE1ERJ
9oaButHAqHUzegtL9T3XdBYh7evTPDkzC5uhO/sX6hsCs1WgnV5i4bPggd1ssw5DDD8nwmY5Hn32
ditz60BACBh1+QbyK8ZG29gtL0BO0fiOQAJd+tITtQN41zU763QygNYBSzISIxwVrhQ0aA8lh2BS
91AODBAnM0vws3UDVp5Qw+tT+XUqncy1TKWFsXQ8YP+2W5R8DkA4e/sE9ivHQGqFJW1qVc6q+w5G
KjW6uvW8szxyfbZXPUjG64mtla+KXyHsRK8AmjQVhjplMhtaLphYFSDtGCAWIDZu8D7Nhim0cxpt
BHfp/Va2xkYFCqEj9QgFG8QJHeDr4uhbZo0R1NEJQnXFr0TfS5+t6Qu5MI3cuAAISo1l7t/uHC58
djk1Y31SvyRMj8d+9oEAOIN/iQeNiH7Bc7ZYluYYgGAIQIuZwGeOsY34wXzk1Ul8WyFWgruaCfvR
ftb4G+hGiwPLNopNAPbBAX4EFyIL8Ah1C8I40MeLtWBjq8+OBY0fudC9RevPIVwLiQgviBp/BG3r
R8D+fLpQlHiBz+w82P/y2HVNO7dvlSoAirRq9ljriMNI0G4zQOSN9VgwoUYnO0i5F1dmDCXY1ij9
MD7QBoBOauoKX2J38wN1CgjrBAWAQ3QDfJv/GJDZYrg2NHvgkIvgRMN5u1uD0oM4diBVJFGDQyOj
kDfBIdTxF3xKD6H0alJNPOfDzcPDLNoPaG5Vizx1GQlDHWz6gmRdO4vl3ExD+kEOakEEMsx0D311
Ux09TIkCuJvDm/pH1D6LTv5oRHXN/zXFoZg0AM6EYwfdS4twDIguO9utEv0CJTR2iwyz5G5FF24B
e3yzsnUS99u/7Ysts31l9v9UCOvDZI8FQ1eic46jjOhkZQ/41tL3gXkEaHUOUadSDDlRwcTdW7IF
m4pRu/RYcttWIFgIqWFLAkO/teBb0WsMWVva71ZDMjBY/GtB7kMwMPdu+vyLXQwOS7ENuvdA5NqC
itYctA4yReEQCD4t8V22IXN7CMFhu3a2UP2ysY90RVZVjbpUC77uhe5dXkELxTN4PCVTwCBAY10L
GR1WDGIx2QrNbDZw3o++c922S49VDDsIMBqLNI/rof2OfTX3fRzJ6xVcav/aEGKTP10WlLyV7PYb
O4spi0EcUAMYUCQFXK8MHD+imnfzVg3zKk5E5UAhaPw+GHUdK0qheMxZ8T+Y1SN2YNiB7NFK1Iek
hFUI2qhPbdpyoJELQ0E9/XxVeH+L8ZbxweYDO5YaJjNLw0xBbL3ocGgP3aQNENeo+nVKxaartvGF
XKEPdsiIjHUTFwilQImzsygnWRJXk3s7Fm+9B2JAWWU8dikZgbOzOFB1+A2DR7Oprn1qAwP4WUFX
qXt8Z0M2N1Vg/+ikEFd+yGBjDFwd5Fz/tgyq1Wzm0xYRC7eDDGYFJ7x68VksXxoi5urrJo3YMOw2
06TdhDwIavTdgHC3aCrPXitoQO2GNiUEGpb8FE04m3mhAfIl9BQG+BC4B94co/AUUegFQsBbMjKc
oRhu/qhr7KH8B4jeFGorUAwKLewWWAAkcgecFLHY2GKYy8wcVaVNtkGp4dISGXdxDPxLv8VawcL8
V8Huss6LevxpyQTRjRIdw0uk1IwBtbTUXSuJXfS78IkTjdr/zfkI+HV/wfkEaj9JXwutUmv94s92
AwVME94DXwVfytRI4dggcxy/tvhb30fT741MARXXIXywRP5EKy7YS+11ITlhg8HgHi10OvdgIbyw
xBIkBoxtG664Ubh8VYkKBAK/294IA134DQiMi/vB/wRPGgoY2to/e4ZfsnWaqdvol+xqoEIrpxGu
1VvEoVj4SVpOpj+3te52BYnzykEb+0A+O/qW2m2DdjX6v3RrLsNRkZEB275RvbrqCxa55NIhVBEe
vbGWkA/SIZRMUspytm2/Sb5KCwQIcGGL1hGRvezVCTmFwmujM+6J91iymuvesPkpCyaJLw6KL1vZ
BQiXSmOKTAfdvvu32SCITQ/+wYgLcyWAfQ9GDrsk293giHjT63YJGQ03Yt9KQbEJGOspJONP4ENw
z2IZJVkED51bvOGxhLcJOItURfCJGjsTEw9z6fz/CLP6AHZw2cI9wN+j7A2haAvYNrrB4Q8yDFKA
KdjsgaBAh9cfMh/2HoQcCVAIDjlAEIOd3c3epIhsJA/+SEMKSGyJhhtmeUMTg5L+EQ1ML3GDeJh1
bFMQDYQF3WtaEgkQrhCjAY/0M/I4dqNo9UGLyCgryODTt1qSERKNSBRRinx84/12YLEX/w0vOwUi
NTr92lYKFJY6iQ1MOD8DNJCyrIk1CliQGjzJKmbjk3tXL2hXjTyCLBtIF3Z1R4dp8BdqSTR9DoPH
l4gvktPug03CdfTrECbgLtQAAELT6A6NBvB1JqFpi0F/Lb5d+AhzGYtL4TsjKyP+C89Hu13jFhwU
O5oYcucHdXnbTMj3i9o72CYVBevmGQVocHd1WSRzEYMRbHfIs3MTN+vtJg0bRRuasy/uDghvGbRf
q86BHHSQDspZWxa2DRq3aUOoOGwH697mthvpFEodpRSLFh3eSm36x0oti4yQttvZwy6AkESIN4sS
cBFVUKBVK900vu4G1L4ORAvWiwvtkYQc9N8K5v9F/AS//iM5C9d06YthzSrUl8pKXFiwBt3GTXZM
V84PZuoLQXdqIGRfxQXR4Uer67bbRosgVPlDCit/8Xvjpku8wf4ETl4/fvheO/ebtOkkcw0BJGEg
fSvb0oWAEaJ8OJzT8+xb4Lj7I1yIRIkD/g916oXsaLGB9CEL6zEXK5UVXLvFoTIhGSk2mJNzFIIs
hSIKwNem12V6BPgAla96CJBbg+c2hJQ0qflCDMsAUmulIsJkBloq3Sz+C30pxJkLpbHNNRcRYr+w
zoyw2y7ZCTsKjwl8rusvKOz7kB4NjU62CXsEsbytItcjXRa+7gk3am7pRgUHdQqJA/yyDb/tXXl1
8APRIgESMvyfi6HHb7cOIY15Dz51Gjsd8lEGjUhdSzukBmsivZELEbmNQgQILMCDkwINbxD/LRSA
Gl2WTVBDeio1clCQGFeXUCgFmXzaiC9YDGacwD0K0Mz0wWjEvwhFMN/iyLbdgTNciUZBKmoEaMj2
wVcjaLJXGYgABtI/DHUU/3YQV/z7rbXUtnxOJMWJfgT/BWKxlakWQc6bX8ZHrVlT6W5xyLOjtcVB
pNvFT+BDY+vjRsM3acCBWvswgtDFdhtF6kAIAgS/Ss9269Ye+4XB5995DIsQgGRy0JAALNFLdNXe
J3DAjZcER/rQjY4Gl7ZHd0jyg4h+9Azm3VZf/AbHQPzwQudeqt0O7/+l/8eA6BAUwQ1+0QWZSPCW
dsfdU9V2R08MvmNfJontZWtvrI1KDAiPQWSeREK7bvzDvJ7jikZDisgLhMB6iE5BgTH+Q3UDCXgE
uizLaPGEVsB+atirgBJVyEBfIA+ettEkTn38BL/6O3KBNEulGKGEQLbYgIIw8T695GzVfYFCXlZo
JDNWgoTZ3gKcBP8dGxggJwAsxF4ooM599T5B9lijQ6EkGBx0t64cSQWhoFfG2YIpGosORlAz9vJc
giVyF5Q5XRgZNtsK7qGwKpONUyxBa0A8wCAS4O0O6baZbRg3LB/gVnRjoRda0EI+PEO5AyQv0J2I
/I3Ai2t13Feit+mAU7R/6wv/BBtNUF3Kg9f/ydrstsQpSeBWXxxVMHOtc1IRFNeg7WfBxB3njWXM
liYNh0CNCGMg23JbqUGbOg+2Pt4RhIIG7IKIcnUctNDRDdqhDsNFUuQjDtDxCgdKQAFNEAEmGIpw
Q3N9l8BSbzW8+XVOIj9bM0RKpwlW0rioznJ5U2I5MHRyMELpRjANF4DoUJOAQCS05d4+Q0BjWb/g
gqLobhZ4rOFQ86uq0+QPhu/7T1M/MH3uZrtN74oRhNIMfiF+aq55tkH/MjvCD4eTyzYg9iXHXO5S
L2VYakiuUnHYBKqNKeqF3Z64kYA7e8t0LCot3WJEsoW2+q93b9/uHV38ipKgIAiQRkATdvVBbeBg
4UGAORjUFJMIEBs5vp38BHLBysTMLPXwnktQo6wLTjGs2v2927/AD6WlWaO7petVQHn/zAymukxI
Z0KhsVZfbRM9l3JwOfbay2YsVOsG+gvCCu63sU2rAOsNOR2ICpuCqev7MIEEqksD1toN76EotyUh
Vf6EB9kaIEuI/yV4aktELmz9FGR5D+3Yshi3GUktpF/fLkFtYCL1dBcEDXQMSDZXRNN0A4i4WgUS
LzzPdgsIEVdsWTPAGyHYIKq0F6PFYgT43tzDX4AUjGfgJqBF7FaDIgqrfz8GFjTAvoeIhAXs+YG+
/4KCxnL0ikXyxoUNIPeDbmxxN1PIVWC2CijHGrpA0HcdNbwqQbgqNEG7IACL2WWr3i8AvwmPqkJC
ikL/8tBfWwdBaxDJQ+5QY89eNY16UI1WVtl3xoJvI/0dVh7JyG42VjQjgBT8lkUIWPEn8P+all5c
go1yZosR9sIBdBZvm7+f+hCKlAVkiJDg6xwaAnQQbZA7JyBb9KDhhkbjHIE8AL/rSRWssd0wJUFy
GQRaqktjSzQ6yECYiEkfNycvbx1hchN6dw4g6SDrIdHdsOBMSr5eyYiDXPj1Emr9CGtZ/CgWzAFY
cgBN8mrBh3hDPIv/G1f3wQMWAP6s4YoBQYE7DnXxiwG6NNQAbKUD0JrCMKlAd+sAkMhB/CYj5RyG
C2AaqROzBnnbStx4AuvNv9wNBP7rCIM5ann96wP8xl8ZHexNS9ZBkGSIF0di7utarBFb/RfXZ266
yQrBaU5r4S809sZeAu8n98JpEgdqtmGINsc4xXNmCC2ZKWAIDAiTwV6wiAff3hQiO8SQQJjj4ZKT
5jIkE0E1SSbZHivBwwn+/TAMYJD8zF8BNIAGSGER/H/LXVvRA8Y7/nYIO/gPgnhRd4x1WseMFNWD
4gPrwMS/eHIp86X/JJX3P7oc3uBCwf1yDGYDA8i75lbeF4UgiB6NGJAHnIj6Tdc1MARcA4Aj0YoG
iAetue2FcIhHAQUCVghZ2UnGlsbHXMyNSSt5lmVsJQECAqbk684mkCNGIUc/jJqu6w7/b+wD5Afc
1PybpmnMxLyLRI7kiUSP5NM0TdPo6Ozs8E3TNE3w9PT4+PwBhy0ywY2adN8hbBf4Cf/wIAMsTUCB
10ARo4aQwWYDe50L+REwQ0Jwow0KKzIIm/qNdDFYOfx/JO2z214N/eP8d6CK99nvczIJ541Qio/5
K+u6X+SoiSyQuAvYAwAM190Km20DOm8DTlhPVoRhb8m2Sx+jkG8huu6IAimMJeEtG5AnJKtzbbyy
LQOuRVqrW6bpugtUBlwDZGyMsGmadHyEl4qXHNM0TdMcGBgUFE3TNE0QEAwMCAgTFtI0BAQflrDp
urAFuAPI3IqXYbYE57e1hw+DCWFgCxO3UPz5VDSMEkJoZKWj6ouCUR1njzUQpjhYLMij/J4t8Cl0
oEgQaDQHo5CLet0fetajlAahC7nsD6KRdusOoZQQNKyh9wVTETEYA4Ij0HMyTavr+BtBV79/DFe5
eiTZ9So1QR/3SzYK3tBBJAeLdW/rIXW1uNFpZEdJaTEpzf7Xnh916y0dUYPjA3QNIIGDGtUdLzlo
fK0ZG0LDedE6D9zZZC2aAAvuOmwYRWBW2y76Ksgn8iEnsGOvKgYWg8YySNMM3iweDM5AfHt1xjnr
GIHi9wlihUaaDgAEvlN2v9vW51UKBIkHX3X4sHWF5BVZw6O/yI3z5MgL4IzYjVyNIZDLZfCMHI1A
jSPkAcjIjciN03TdYD+/BqwDpJzA2jRNlIyEfI2/pvvOI8iN8OAD7EkeQNYAjr9gj82RU8gQj2iO
YI94HEgul46YjsCOYI+NQh6BYI9N03WDWxQGHAMkLDQAa9M0PERXj7/TdSeMH3AFeAOIRYQAa5yP
v140ooC/Dg8UidgAQUcrjgoLL4H5g/qBLZnCJeLS9HQIK9HnSYvIQW0wNN8DwQYQys0qdAYWpusa
6zoGI0rSQk6CckQzcOsGEBkc4T24z05wKbh1RlfVW1MwBB1FjGkPcLbyW4g2Ix0j6yIgIIAnwWcb
dDgiAZHgTzo8uDl9FH4QLpPg31RhOFlZiUUUobhUJYEDth0WHLNOm+cTvEhNgaTTfSAszNohIHMu
OSRWjFwSTSCLMq6IAPHkO99f2ME2IcEEG1HEQdzWBgk2OesTSv8mEVuCtzaLOGfcdGas3GFzXbI2
IVf0Tewa0aV3FqVwbdR12LZGX6j89PZFDQQmPhyzmwnYeLIj1X8e2sBsbWQySNKPnfpCmozIx0X8
cmTkF7KzNtyJXeASexdrkO6yfd90tFZkanOnrORndJyPs3Urw9klCusGjFatk6orYt/VQL92cQ5H
hI5XxnF7+0KwwR97Vo1K3Q0l3RLwhexAi/FJBvMMXsy98eN1BStLi8Kx/yVsQgBsriiq/29q+P+u
AGcDcnVudGltZSBlcnJvchXPfiO2VExPU1MNDQraD9hdc0lORw4ARE9NQRLydvvLEVI2MDI4CC0g
R2FibLNv3/50byBpbmlSYWxpeg1oZWFwN/+t/XwnN25vdD0EdWdoIHNwYWNtwN5tI2Z3bG93aThh
BvIUctlvbjc2c3Rk9tvPQDVwdXIrdmlydHUhse23tTOlYyMgYwxsKO02hXxfNF8qZXhcJ3vttS9Y
BtziXzE53c19YfdvcGVYMXNvD2TaZMC2ZXNjKzhGgRDh1iSBZWQZV3Z7SL4jN211bKx0aL8hjOTb
YS9sb2NrF5rbBls0ZLdhLgL2reHWoiFybQBwQGdyYW0geyEUtkptNi8wOU+jGVoKEEEqJxTyuUYs
Lis4PQ/h+2FyZ3Uoc18wMmaLbduuwW5uZ4JvBXQ6EdAKZ61k5n9NLWAY//C2OWYVVmlzqkMrKyBS
nGHuuz1MaWK0cnknCi0WGmfbw0UOIRFQ1Dq+XBt22QAuADzl4CU+y3jbLGtsd24+/92BOza+W+ED
R2V0TGFGQRZ2ZW1n74VQwnVwABMPV6lkWKD/rTqbZXNzYWdlQm94HXNBzxpfOTMyLmQ+RyiRpNh8
rncDC9zgkRmVFYqIHgCQFUV9KvmgM4ZA0NzU0ZFnQP4L0MWPkwCMRka+2Y2PExeMj46zk7H3GyIr
jo5LsD/dkowH3MncjJAUgv3lf9TT39LI09kAzs2Q2sqQiSftftbdF5CNOcVDzdLS0Q7T2G8b+785
2dnP2M7OAMrY30HKAJ0jfth/sNhP2MXe1dzT2thv1dLOyfc6s/0L084E2VjIVBv2N2v+ztjPy9jP
yQknzcjfInx4w9reBxGXPzDA0zRNtzgDREhQWE3TNE1cYGhsdHw0TdM0hJCYpKzTNE3TuMjc5Oym
aZZN9ADBDBAUmaZpmhwoNDxEt8Lb/wD+1dje1p3JBZ3cyQjn0NiPDdjP08nu2NgV2Bb409fYbhjZ
0sQVKfDSzxLZ3eEwZ0f+GtkPg+iNAvc0/MJv2XbZ/7kEAwD11J2B/++DfvxSsPe9A5OTG4LICC+3
B2shZ3qd0tMf+tQNs9a22xjbmUIdh8rwcvn/8uqd/vX4/vad6fX07tXJh5KS67rt3+6TzdzWk9rS
ywfWJ0ireAOv65qmnLwIswwDzMPHysaHAMfczxHUX8nPu7HRtsht8TsexHWd3hrR0N5ctRXbz9SZ
BOqxrfG9LJ3UzhH/YpD7Ft4YsI+dK9YnnV/NzcShuyV76U0A+dLbylVo2+5Zx9HScMnU8ABEZzPe
bRnu3gXTnc7cZFjOYbeFbZXNGUrS1qmwhtuyIy/z2CfcfrLta26CPyQP2i7Zu9r2DVixzpv0INAP
MbKwHVIL8V7Y2DMYPuMUNfPSyRWe8shu323KGc/E0Ogh8MT7Ydnadu7cEZpMQtbkMxsDYWGajtIy
Z9y3Nee2ziDqJEjKxdEdFJZ9wtET6tLKAG22zxViDiBTWul+ztvWNvc0M33fyUHIN9RqhWec1rvv
0nepbRtLV4sV2/Gymi/5VnLOsRHe0T7O5KetEGuNC8TvenbL5Pjc/NoNvfFU6CfOtQrt9YNdLCrv
1o+FhM5vU/HcyNrVQ3HCzDHyisrV8QyCe807K0H05/xhS/hwMjvRqxrNcNveAPZazTXWziC+wmHd
GPvVRMnT29Xe8Xhat9VYMt/c38QdNgnJD13Ok/W2TXYrKRfPzmfyHtp7cySMpTnbJY9uWXtvg8zR
2RqMMxPLJoVsLpxryx5LS2zUJ9GvUVZozLrV+dzvG93OaKYFN81UXYLjH7G5QXY0AzP80Suom/Ae
034TgKrTNM12BMMDHDBIYE3TNE1shJiwyNh0btM07PwIxDMDMNM0TdNEZICYuKZZNk3M7ATFIDCa
pmmaQFRwjKCw65qmacTY8ASPHAOmaZqmNEBMXGCapmmaZGhscHR43zCeaXwAoQvVBcfTwsjQJc+r
yvdBEAMHCybbs48uDa+h4LX+DePez9D2wCM5OKPZ1NLA80ImNHyE1//I0dF5yfcMH0sYixjTF/pG
YHTw8BT/+tzOK512F75GzaPbyFn30jqwZ2rNU5B6AxsLaZrOPWDHxwN0eISmaZqmjJSgqLCapmma
vMDI0NzkNGumaez0GPtjYEyaSEczoyK1tg0d0bPenJqu696ByNvbB1w7aAN0fMIwBWuIS2/0nN6M
WQ/AH2PNeq17gxfOdB9MrFlrgzvKaA4L4W7MMNgLzmqLqGeapmm6uAPI0Njk8Ae2rGn8zssLic0N
MgM6D5YRW9aBudsOP9ELvS0L9t4HHw8oss0MlyPa0Quw0lhsyS9DicjUWOAYWCzUCy6zQsCKDDM8
DHiTBnsLFt7dD3uzYUurMgelE3vLYinzMw4PHQbyA9/Uz9kSLQKxkg92m8WjQIFknbCUFk73grEA
3+t1x9a9x5vFB4YL3+l32MCGC7pHyAtn47a1FxTJIwDa7NglW/YOBDgPkyEWy5YSEyGPLw4mDttb
nSmlIbxhtAuLbDqz0AOLAJ/JA0RpmqZpVGR0fISmaZqmjKCsuMCbpmmayNTg6PgEyjRN0ywUICg0
PNM0TdNIWGh4iE3TNE2UnKiwvMh2TdM03Ojw/E8My9M0TWcDMDxIVJbr/DDj0djJyRu1SiUKjhTF
fkNotY4WP9kUxBRSodFyObDNPZlTe4LhVrbZ21/H2NYghjE7JHcJ89M0ndnHzAMoMDwx2zRNRFBg
aMyDa1vtKnD4ksUC1AcPugJLA8jLzyeoU6/AQZPeYAf3LDgTsQfzBkvM1mKQzifQzSDDNN2HgSE6
6Bvs8MZW24PZ0t4nzYrFbdNtt98AX8nFJ9fNRtoz2d9tjlrfHFtm0BPQ2d8AxzSdgx1dBM1vAwwQ
0zRN0xQYHCAkP9s0TSgsMDTNa4uLk4+Xpbv9jYWTjI+EA4SJD46Pj4nftjKXiIiPwYoSjI2Kk7Yt
u9+Lii+PjCyIjYwVig/b2LctIIQriomThQuLGoh128G6iVKNG4+OL4s8jOsmn4cPjI2PAFmPfOz9
nptLiY6NSISLgh/s2eZcZx4djguMiwO/1s1epw+kj0xbxdQaNDoK+CTe95hP/dQQg3je38pK3G1z
8GQT2N+T9yzRFL3QTJvWk9bLNNfOxZMAx3rJB9Lbk9mnz8uCqVCpvGUSscqZth+/PpPff86Njs6N
or2XhhSeANPPVRQoXEjW8iaXxNbZ/2OxBrCTCX7w9O/8+/Hy7/hG03v/7pP68v+T7fgnIt3Vuy3H
YKXUj9dbG+xRqXNQppDQPz+tMdZVesRh3uPr6RKtSgFNRN7KFlgYtnvF2pMG098bfYSE99JgcKaI
ioQAD+QNhnfhhTuIjg+AWI+CoXyHi/cPi6aFModzbw8b5hsPDGMPboxD84gPjaGxs4LbE4RWfg+M
DJtzzW0HjiALeB5Sikr38QypDxGJH46wQ2fuf4yLiFKMyg/t3Ba5jiuKonaIhePrtu8PzI4MimaN
D4mgQYLmOIVOCnvHIbynxXLJCOtw403TNF2AA5CgsLzMlk3TNNzs/AzOGGmapmkoOExgdKZpmqaI
oLTI3E3TLJvwBM8cKDBENE3TNFRkdISU0zRN06S0xNTkpmmWTfQE0BQkNNN0hn4AeNOzA2RcTdM0
TVBEODAkHLlN0zQUDAD40o/TNE3TA+jc0Mi8TdM0TbSspJyUiDRN0zR8dGxkXNM0TdNUTEA4MG7T
NE0oHBQE/NFrw0zTdAPo4NgAME3nCoF7A8zIv+u+q8c6LSkAIQchBFNDQU0zMv6/P3cHSVJDV0lO
SzdaT05FQUxBUk3b//buC0FWUBqHT0NLRE9XTjIwAAAWu/1nFy5FWEUAQ0Y0RVQiC01QeQtBSUNN
40H72M79RkVXRUIAA2pOWDdOVElWb/33m3sATUMcPgBOT1JULE5WQzk1C5vO3R9GUC2GQ085OG9D
3/vPuUMPCBstUFJPVCYLU9a11m43UFcfTGMSTpD58861nHsHUlVOUkxVMzLu71/7QVBTXDNOSVNV
01NZTUjvZrffWFkWUkWaVUW/H1NFUla2gmtvo1RSQe2DHjtQgmuv7ftVQ40ZAgsZe7HX3kwrGqZ3
PWdfK7sXCZtWU0MHSLu1NnO7Ex51M0dSC3OH9zZPTlNPRhttZHvuvW1QzDMIE/NdB98BvcMGZjtN
b2R1bBA3oO1lRmkDTn9FeAPagP5URW51badjSttL2FkfcxMOR1Nj7WNvV0kuRLdcKi5kGQd06Jcg
w3h0Cxp3YXJlXB8DOiQoXJ1zXEN1JehL0HJyb1ZlcnPO3P+3t1xwcGxvEHJcU2hlbGwgRm9sZBnx
StD/gzxCUj5TZREIqH3tDUtpIERlUw1DK1z7ty1fdAUgYXR0YWNoizP/7RDdTGFs851rdG9wAGtp
dI3/N7RrHhdCQ0RFRkdISUpLTE0YhaCNqlChVD22/+0LqFphYmNsZmdoaWprbG1uMnH+/v/fRHR1
dnd4eXowMTIzNDU2Nzg5Ky9TbXVuc3cE5GVbSVQlnQPebkFvLgarLS0LLS0AooVnSQ1iYSM2Qb/b
FqhDlHTsLUlEOiA8++0fM+8nPC9CT0RZPgZIVE1MPg/bQtReORdkaYt04e9r/z0zRDAgd2lk3Qk+
LWlmcpoUcwufCka2VDcGiNowF4k7+d66oFYi/wU7EQlib/1sC9qvZII9l1N1Ymp2LagQo3E0VG//
/1voB0aUbZEgKFsxLjAuMjU1LjUzXeu2rr0pUhMkUi5lS2QjK7T2bmYpIG14MrkTHGPe5rZSLGVo
OkMifAqFH+Yv40Rpc3DqdAxREBrVOpdYWbfp+I9mXW49Ii8+N78lTAgbM7M3Ynuv8WtHCS5zPg9E
QIgajd/QYXAxVSi01vgML3NCQbVYUITWQByn+62EGf8vcmZjODIyQ225u6W2F1jGNS3laXBpg4xS
9BCLKZlT6Ig2Wq2JZHt24batUIUCym4DY3G93xW+cCJVbnNKkmliZSIuIFzWXnbrA2suLg0qIFag
ttBM0XliTBIgko2xZgjSDl537rZUam1QIiGC+SJzYW8nHHOiIGduZS5KuVZI2FQ/HiWr2+3r/lhh
ZGRyFiC2AOxlbapltuZKhT+pLJsEpGGNrp3dDnIgjEUxC3kQM1lhawQmYYc7KO+15r5MZSwfdiQz
S6VzRRP4co1Sa7T3AgZORCwipoUCisYKbnSOD4hkY08FZx0QtopvxXC9s79IhkR3aG+tabDmWmzh
WiFJQF7RNbm+r0sYLDpuCScAnDvMEf2JaMeFR6sVFqRyfwhEjNollFxpeHtrVEJob4vN/uJxbCRh
2mjvTXrvpQQhLLmOMCnJCWJyifRGzNThdAtorXA6L5u9MMzpWDVqb3lEc9AivAUKcCBTXQaYm/WI
XhaHUCQ7zBEsqg5IUxaNDYSZR5qid+OKpLkALgAqACUcuggnZS3cCW7PqjVQJ3t13GmTNPcOBZ19
+x4MNsJlPHh1yiwDZirkODSo14uTrZh52lF1Y8lzE1IYz+AKI7SEDZTKNkYs5kc8AD7Lio3KBs+t
XmdDcFdEDgC8a6ybuXoXeSINAM9t+20FXS0AIE/VZ8OxIC1QlU07FtmBvWGrBwsAZzg6BiEiZLpv
L2nB4CrIkQzRdQ5LlGtCxBQ+bXILNxxzTXJ0VFkuFFqL0YrxIhhoSjQVZl9H1WUIgEvCMIswOBmG
guFEgnZtJtg7XCALcHlbPSsS9Qh2LHrB/3DCRL1Ghx6RrE3g52FJz3O45ig6WD4mnEHJCjRH85jF
xzbT5kzWMJI8CBptjpTV1RIXAGGkMmD4alj0de1jxWibi3mZYgJemoTh1eNpLR/f2WQv0UW/aW0p
x0FMbcZrLYY9zol81k7UFkNkRfdFrXvNGId4uG0DhsD2cgcgg3KW7fVik+ij8F6GYeFFvW5PWn5U
Ep0VYYa3JNkoEBy4tgMpFa6+4yARjNhIrUZJrJIIe7c1V2qzDNLkH6SNWgyCX1cF3Pw9mLlEUwZx
M3F1bwlVazRNLTafjRp4Gbxu+1RyTWbHodDazS1wIunmBQe3Dzgvi21s9ODiv22uYdSXIv9vLTg4
NTktMZwKA2Z2P3kTGUcWw14DWwBtBwkLx2l4JSP/yaLaQ00gcjvJhloLhU/ySG/OkW/hIgYgEhk0
MTP9VmqLMx40nVRNSU1FLbkWLQi2NzYS1j6qhYYAcHW9WvZO0gDDRneeD0l6eEHDpx88u/ZCJQyD
kuNIOm0M1tr2tXwfZAAsAqAAfY5C5iB515gnRHGrQ0sEQXxdUFSgo7e9AU86PAw+D9xM0Oxr5LHa
EUAUo0CRjacgAIZ39BY2+/iQSEVMC0Yxzk8gu7MvPLmtNwvFbDfVRGWzrodTeRRtH1fMamGrni1y
RTCWVOg1TC0ZCMTBpBnFQxzS93KA6/NbMTVHXHTs+mgyaECtYXnuLgHpZsPOYyACC3hcjTse1a4z
TVRQjBRs0lh3QdkTDXu1fWhsSiCvJ0xgtblzcnZcAHtJa66tc6addEhjiQyzFszVkghndA/rCuVC
O1VyFgNCZUlNbUAkzsxo9FDqaAZ4U5PZ72aNFaPWJ+h8k3ZqNVPJnthKjYRYi7l3lyAH+7VXGtrN
xCCOO2N1gx1kqoSp7bgjIQEHYjeJF60rurJxaK2LMYdJr2sUNntuwXSTVDYhiUegWuFJI/NpThDO
BQet0GIONaGJsAu3A3EIeUFuLkUg3NxNH2hBQ2u9LFZ4BY4wbZcbvbUm7DBSa5pJVHVTwI3Wdg5m
VSOkOSBH8vZSqRtf7nBBS1hoaXTbZXu/SGJZBWhBZVkSLIDDK2xDQgoStwb4VHv4ZVvrXHPMCoYO
gFxiXO0Jugtd+6siIyYi6CUxAyoCcO4Z8zUx2wOCcVbXD1x36ni8wHFTS3MNK9g2oMUZZ/kuAkkm
T24P4wdYUE1FfCeY/AtOVNAHOAOMLZhmUxv2cLQXI6YMQhV3jia2Gkw5Q6wkU04gUSDYZB4gH1+h
sGCcp2KmU/pW1oIuy1RHQMkmLVUcNG8dU4OLGL9ZE1xQrHxcAbBAhCaLVj2z0ILiDPJji2yYIJE3
szdtYUiRHBZV53LJVy7EfzJiB2H8DDLYMQ8xMCoudcMBPxqko0NRB5MOhKZCV45yA3KJVredDu5c
IlxZhxZszUEUdQdzE6O17wFBQgM0BDTT0HiTXKPTZx+9fCyIL1sqaHQqSG9UBQOCdWxMD1DhMmzq
y8gAR1hHqTHYKo0OL51V4h7DPbotQWc8GKdNb3qFa7DULLAv29i00liwvHeTO2wCuti0bTc0FDuF
LXU/R4Ll9qbYby8yNQEwMQAkwbDgBGVnxdOAr21CChdrWmwKdcUkZYtrheuifdA8n1PDYUUCdfHG
RrJFjWM6XNl5bSlgXR9yCxgjOlCDmeM3NzCjjNJAIIa1hmugDyJaLGQBTjxHUKQW7QOZZMpMQQEo
IJlIHgBIABCEQCZkABCBBmQIZAEQgmQIZEACEO6qyty/AAEHN8htkC4FF8ALHQs0AzJIBJaNCAMy
IIOOj5AgAzIgkZLQdAMykwMDBwoLb7IRv4wMowD1YyQvBZMZw5SkmqbpGtMHaAk8CjTLpmkYEOyj
EbzTNE3TEpgTbBhl0zRNNBkMGtSimqZpmhucHHR4ZGuapml5VHpE/EeH153l3/8P+MBDDvbd2AIE
0qQPYIJ5giGvpt/z7yfPB6GlgZ/g/C9AfoD89gjjzajBo9qjj4H+BwyBDXJAtS9BIf93g7Zfz6Lk
ohoA5aLoolvf7j5ffqH+UQUD2l7aX1/aatpql7+yMi/T2N7g+TF+OQUKAAGjkgBFYRuVLSqIA2Uz
VETgSJCNigbFAWxtHypoVbRBCY6xFSDoBVOMDEScdO9AUA8ZU1DBxzZRw2VyKVRlbXBkVTxXhDfG
YK+ILhNDyT5BLFS8LsFDCzZ7M+wNV3JpGRgvhOsqYEZvdChXAdsSPXUOVJDWbWexdQpQMW80eVZI
5g4bIFIFSChATCrAD7Td1ojqLnlORXg0VMBgFSgBh70KmLwHSE1u9s62dQN4oESuh6IR29aVYQxT
UmddT9m/3U48FFVuHHBWaWV3T2Z01rntsuNNGHArOU0iOtfFFuu+diiJZu0/KxxebipHbG9iYWxG
RKDY9rBlC0FsBmP3gR3YBKbMRxVhCVs3RvVOw3SoLBCWvQ9DbGH2NgmamxUxSKA/SNmsFSVNqaIk
3JJwQI0XZXCBb78F8W9vbGRwMzJTbvFzaG9aa8EMH18Si1yg3d7AD58OTG9FxJtNgJvNHyZrD0Za
AU9woaBUm+wMCHBlEUh0hUdHY3CRqW8EJfAOh/ZzZUhh+GEAcPKwP4YBzmNweQlhdBmC0Biu6I1Z
sMO7v3lwLHyTSYniGbFaK29nfi/phJgtD3MIQXQXxXN0EWI8Ez1iE14wfKYgQw0Ug803a02fQtql
iod5O1fgQ2h0zdywwSRky10Kzt6kICmQrE9FCJYkCFmSsGRtdsBLVWArx5XNhlfvGEHbiIXC2Gh4
ZPFwcBB2cqZfeOoyIma82VfrHGKMIbQxZkwbBsufMFvWG9iCQUNQswgRbAdWZkI6XBDtUnRsgg8n
Q7OEnZlDZlcNO1tWeu9PRU09Yv5kE0s2JHxJbmZvdVdlKNxety0dYRFwLVAA7RG6JkBiSmf7oO12
7EtleQxRdfx5Vjh1MPd4h5MRoR0OEDBD0I8OyGYkzLotBS/pabpYIXX6IFQZo7D0sU91okJoQnAC
sBuW6WzbclVCa6M1JMs/bGdwBnout7JbJERDE0SiewEbArtEZyZQaC1rbPjcyuayi7UCZEiQBAGU
kdQw8NpXTiypiIJ7Ed6hM68SGhcO03TvMAoNOQyk3ENFgXlmZjFQvG8/jlVwI3JCdWYPmlVxczFz
Y2gPUOEOTEb3jrIZM/eCbJEcTSjECkLE9cxsAlsjSlNrd+rLEEFsNg0cjoozlnwVbMhFoniHUgYO
YW5JoKMkIGMa6HJQ2Wv20N00Zkl0owwCBrMdXY5ms441lUlkMxoEWzjMcJWvdpMkitMsHhf0A6cI
jhQrbm6zNs3WHIoFIyP8/3NZlmXZAjQXNwkElFiWZRATA3TIZch/+VBFTAEEAL7RAj3i78X4DwEL
AQbGAwCYaQDd7BsJ8aANQAsDBEx2s2AzBxswAcDGZkEIDBAHNtjL3gYAiKVSIDe3AiTiGAehVIOJ
K2woAh4upgJ7IRvsboKQkJiSArK5InhgLnLF+7DmspkbFLACQN5pNrwuJgc8VsAHWhVtyifAT2yV
jb3nC+vzc/BPANB+vxtQqA21JwkAAAAAAAAASP8AAAAAAAAAAABgvgDwQACNvgAg//9Xg83/6xCQ
kJCQkJCKBkaIB0cB23UHix6D7vwR23LtuAEAAAAB23UHix6D7vwR2xHAAdtz73UJix6D7vwR23Pk
McmD6ANyDcHgCIoGRoPw/3R0icUB23UHix6D7vwR2xHJAdt1B4seg+78EdsRyXUgQQHbdQeLHoPu
/BHbEckB23PvdQmLHoPu/BHbc+SDwQKB/QDz//+D0QGNFC+D/fx2D4oCQogHR0l19+lj////kIsC
g8IEiQeDxwSD6QR38QHP6Uz///9eife5PAEAAIoHRyzoPAF394A/A3XyiweKXwRmwegIwcAQhsQp
+IDr6AHwiQeDxwWJ2OLZjb4AIAEAiwcJwHRFi18EjYQwGEcBAAHzUIPHCP+WuEcBAJWKB0cIwHTc
ifl5Bw+3B0dQR7lXSPKuVf+WvEcBAAnAdAeJA4PDBOvY/5bARwEAYek7Hf//AAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMAAwAAACgAAIAOAAAAaAAAgBAAAACoAACAAAAAAAAAAAAA
AAAAAAABAAEAAABAAACAAAAAAAAAAAAAAAAAAAABAAkEAABYAAAA7FABAOgCAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAQBsAAAAgAAAgAAAAAAAAAAAAAAAAAAAAQAJBAAAmAAAANhTAQAUAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAEAAQAAAMAAAIAAAAAAAAAAAAAAAAAAAAEACQQAANgAAADwUwEA
KAMAAAAAAAAAAAAAGCQBACgAAAAgAAAAQAAAAAEABAAAAAAAAAIAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAACAAACAAAAAgIAAgAAAAIAAgACAgAAAwMDAAICAgAAAAP8AAP8AAAD//wD/AAAA/wD/AP//
AAD///8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAPoAAAAAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAAAAAPqqAAAAAAAAAAAAAAAAAAD6qgAAAA
AAAAAAAAAAAAAPqqqgAAAAAAAAAAAAAAAAD6qqoAAAAAAAAAAAAAAAAPqqqqoAAAAAAAAAAAAAAA
+qqqqqoAAAAAAAAAAAAAD6qqqqqqoAAAAAAAAAAAAA+qqqqqqqAAAAAAAAAAAAD6qqqqqqqqAAAA
AAAAAAAPqqqqqqqqqqAAAAAAAAAA+qqqqqqqqqqqAAAAAAAAD6qqqqqqqqqqqqAAAAAAAPqqqqqq
qqqqqqqqAAAAAAD6qqqqqqqqqqqqqgAAAAAPqqqqqqqqqqqqqqqgAAAAD6qqqqqqqqqqqqqqoAAA
APqqqqqqqqqqqqqqqqoAAAD6qqqqqqqvqqqqqqqqAAAA+qqqqqqqAPqqqqqqqgAAAPqqqqqqqgD6
qqqqqqoAAAAPqqqqqqAAD6qqqqqgAAAAD6qqqqqgAA+qqqqqoAAAAAD/qqqqAAAA/6qqqgAAAAAA
AP///wAAAAD///8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAD//////////////////H////x////4P///+D////Af///wH///4A///8AH//+AA///gAP/
/wAB//4AAP/8AAB/+AAAP/AAAB/wAAAf4AAAD+AAAA/AAAAHwAAAB8ABAAfAAQAH4AOAD+ADgA/w
B8Af/A/wP////////////////wAnAQAAAAEAAQAgIBAAAQAEAOgCAAABAPAgAQAoAzQAAABWAFMA
XwBWAEUAUgBTAEkATwBOAF8ASQBOAEYATwAAAAAAvQTv/gAAAQAAAAUAAgAAAAAABQACAAAAPwAA
AAAAAAAEAAQAAQAAAAAAAAAAAAAAAAAAAIgCAAABAFMAdAByAGkAbgBnAEYAaQBsAGUASQBuAGYA
bwAAAGQCAAABADAANAAwADkAMAA0AGIAMAAAADIADQABAEMAbwBtAG0AZQBuAHQAcwAAAFMAYwBy
AGUAZQBuACAAUwBhAHYAZQByAAAAAABIABQAAQBDAG8AbQBwAGEAbgB5AE4AYQBtAGUAAAAAAHcA
dwB3AC4AcwBjAHIAZQBlAG4AcwBhAHYAZQByAC4AYwBvAG0AAABCAA0AAQBGAGkAbABlAEQAZQBz
AGMAcgBpAHAAdABpAG8AbgAAAAAAUwBjAHIAZQBlAG4AIABTAGEAdgBlAHIAAAAAADYACwABAEYA
aQBsAGUAVgBlAHIAcwBpAG8AbgAAAAAANQAsACAAMAAsACAAMAAsACAAMgAAAAAAIAAAAAEASQBu
AHQAZQByAG4AYQBsAE4AYQBtAGUAAABGABEAAQBMAGUAZwBhAGwAQwBvAHAAeQByAGkAZwBoAHQA
AABDAG8AcAB5AHIAaQBnAGgAdAAgAKkAIAAyADAAMAAyAAAAAAAoAAAAAQBMAGUAZwBhAGwAVABy
AGEAZABlAG0AYQByAGsAcwAAAAAAKAAAAAEATwByAGkAZwBpAG4AYQBsAEYAaQBsAGUAbgBhAG0A
ZQAAACAAAAABAFAAcgBpAHYAYQB0AGUAQgB1AGkAbABkAAAAIAAAAAEAUAByAG8AZAB1AGMAdABO
AGEAbQBlAAAAAAA6AAsAAQBQAHIAbwBkAHUAYwB0AFYAZQByAHMAaQBvAG4AAAA1ACwAIAAwACwA
IAAwACwAIAAyAAAAAAAgAAAAAQBTAHAAZQBjAGkAYQBsAEIAdQBpAGwAZAAAAEQAAAABAFYAYQBy
AEYAaQBsAGUASQBuAGYAbwAAAAAAJAAEAAAAVAByAGEAbgBzAGwAYQB0AGkAbwBuAAAAAAAJBLAE
AAAAAAAAAAAAAAAA+FcBALhXAQAAAAAAAAAAAAAAAAAFWAEAyFcBAAAAAAAAAAAAAAAAABJYAQDQ
VwEAAAAAAAAAAAAAAAAAHFgBANhXAQAAAAAAAAAAAAAAAAAkWAEA4FcBAAAAAAAAAAAAAAAAAC9Y
AQDoVwEAAAAAAAAAAAAAAAAAO1gBAPBXAQAAAAAAAAAAAAAAAAAAAAAAAAAAAEZYAQBUWAEAZFgB
AAAAAAByWAEAAAAAAIBYAQAAAAAAiFgBAAAAAACYWAEAAAAAAKBYAQAAAAAAdAAAgAAAAABLRVJO
RUwzMi5ETEwAQURWQVBJMzIuZGxsAEdESTMyLmRsbABNUFIuZGxsAFVTRVIzMi5kbGwAV0lOSU5F
VC5kbGwAV1MyXzMyLmRsbAAAAExvYWRMaWJyYXJ5QQAAR2V0UHJvY0FkZHJlc3MAAEV4aXRQcm9j
ZXNzAAAAUmVnQ2xvc2VLZXkAAABCaXRCbHQAAFdOZXRDbG9zZUVudW0AAABHZXREQwAAAEludGVy
bmV0R2V0Q29ubmVjdGVkU3RhdGUAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAn+pBjpQtD8ytJ5Q9jk0ONzdlMppAKIeb6NI4Zm1YiiDzB80UOT0O35sAWPJg2HfLyokCAcPY
2TmwCqU4zes80KuRxQyxprHW21iThWWuRsv0mluQxz6mkyHpOZJsHDmU7rfEkGT1NsPGP0W9cAZ8
wdJCqUJZDKo0BE0SXUDQdumoMp5U5BKm81ZlB7WmZilCJbKWeZtDdQ+05PM9cD0ZnIMC9Z8FEEmd
JlqzTDjZQxt/MFlqAE640y0wG0NoCgZh4oSqZ/WdI2LPitHlroe4Ixi2sq5bzxK1VHdKJqgVLi32
SEQV54lUolVTSJvPGqQ52yHBmWQG6ZWaFoQnH6SF5ICYfcNyFNsZt8WGCHNqwHaTKR0cVDPpyjvo
bS3CafG6A4TYHzLcw3OF10ktwOMN6Ylc74t8FoyCQ/cvze9OYq7HKg58MMUCdgBZ4hcqE1nQ5iSu
FWDnPSNH8ksYBpKVH8wmdrN3HYYNOQVC9yz4ZHqArnxQvexbFMJbvrbK8E1huVLSJJFtR0byPYfs
sOMiPuUWxYG8IITsubwM5ilsaO4DHlvn9cMuLqhZf2/AhhitbmKNjWV91kMFRz+TL02YO7XNy62J
XvXxgJtKq3vXMVruL0bjNHnT4z4epjJOOZPyy7NWoFTVeudsF456cj4T7lExy4zA9MSXiiQx2CFM
AODZ0IeljTicbxt3iSlXZ1Ay1uyAJxIg1VMQOzwYWeKStgvyhCOw1Rjuvq+3pPFelgDAgkfPE2lu
FncCpkMAo8mJZ+3lKXhVoAZ5MkqIi3+EQ9VRXIoet5jzDuq9KFe0WS6vS7M8xL/mVRNmrt9VjacX
viyKobUysishRUNC0V/K0mdsbI+sdYuYHo3nhwCdhKbU4i8PpFuw9XZMb4sqc5WqmZcaE6QuUa+v
vYamPB+sLQtH24PYJuDUm+wAoCMLLvBN2jAUL+K2f83uaE0ItHjvIsjVHHS/MUHyMCS+7IUtK/g5
jJkGBVorIM/r9rOMcYOIyby54LLLtGmJZcTKp9euBXKbH0xRvLAPIxevhy8GPneAsJfV57zy2bsX
6WijpCRfMzP1HthzW5heMyxXQXzW1elL3vSy4K+NBZxmaO/rKObkqs7wFuN9oKUDzNv0Pwk7FJzz
g5NG1uC7H67DSQp3IN2/+XqvhnuyVtthQMebkQqJKRehleBRmN8L9cXXRwAiWtiJm+7auQpHemvX
jtpZPgIICcbggihLaYgS0yzvpNVLkQNcHyoGh1Ys8BlmSWqw1oUW0S8qkVoX3liQFjR24XMzeiMO
09kQUZOxwOLz091npTl/boKv3HMeqsqvRY6/pkvCcfMwK8mWxt7m3kzH5LfhASoCieiEFZrBqJNY
OVZkHxb3XH61Cq+Jao10QobPxhFv9W3cn98rOphVpJ2udhNDe8/jHJqZpe2jO1Qhai5wc2yRzE5r
D+xLGH/4G3DA47diFvAzvfm2bLyUMOTmcUHnMNJnkcYMQI94w0vu+FXeEfQf5uRahKcwQE5jn6Km
ucSQvPNbdG8PeLMOZDDVJwhe9r62dKYuP650l31mLaM/sTeJjllSmeuTYbSP2sjzEBmRoIIHE7Ya
zBmjckhU2wb2KrCFDyuwfjd73lvlnQiQKMHqzaHwi6QepAVjDsqT7E0IyZIxE1349NxstVQlgO4H
9eidbtPVQn8wYBTcqszysjDOsyYCQacQufPlAGk5koBmEiBne27XSy22SnzkOsL5g9RwrD+SkB0L
pJvMXrKAHJUl4pFnAYdY6ihyy4s35BNzRI8S8kSLFT2nrL9nRMRyxxrH4o3GLQNEAyS79dzEoQ+W
9d6K8nKvfpOBeJHGKgIHEjBaxM87GWbdWRhJBKejBZJRkH4XrtxkBcDkPwFcfJRptesm2GHEe6tn
lA04m6mEOTtzVcTXGkbxWLfwWcognrE3WrB839ICa/EOrsh9nIjD7gWq3hlhD4O1wUMC55PC3A2Q
jqrrhyY8DR3Rrizyb5LgdDvNfBgiDnGmrK3pDTbQ0XkbkJNlqZ33ixmyOI85Ys057/klNYgVkA0K
D8Mo1euFsbSOmaTwWHXwNyIrxpviBXmWU6QO7IV0vAhmWAsRl4sazCza2O1GlwApMi2FuWzQjFCC
02qxRe8lu7tzTduGg2TkZ9gPJYKpSObAfhl8CUaSIAodu3al6QMEx4306KCAVL4TCdPAbINibXga
SjNwbMFK7LafyPfevxz2JHRs9sNzIYaHNGt5Frjfes083krMWQoz8GW5GpHnDnJz4BQJEne+O3if
hZbo93wCRNA1gV1JzEm1wM63AhU+JI6kaFqCCJjx3BXyp7N0sJYXFl9NStQZme/YXCKlohuacqpT
nV2hzFx91lHyg7XR0ozGCRwZ7HUOXW0GiGYIBEjTYGnje9Zj3NwCht7gHGHX3/e1hsS3lXBmf118
LZWABHCT4WzWI4aQjrZ0IIwTGaQqR0NNkxc/QJSyQLKQxGCzspeMnPYRpE7T8l99odSlsVO8VpkG
90qRFgdeTVHVScnpNKclkhQikNLsHB+pz8Jc9O8KtiJmm1/oH+VqmSA2Z0a4M+TOenCSi1cgYG9K
ZdHT2CT2J0ZXLhTaiHHwzuqUxevCARHQJ1HWkYOsH3OTt0HmAzqhZY1xTLzECCRNivNH8omsJk/5
kA==
--opigilh--
From carlos@baldric.uwo.ca Fri Sep 20 20:48:20 2002
From: carlos@baldric.uwo.ca (Carlos O'Donell)
Date: Fri, 20 Sep 2002 15:48:20 -0400
Subject: [parisc-linux] SMP kernel problems on a D350
In-Reply-To: <Pine.OSF.4.33.0209201006420.5180-100000@simba.sch.bme.hu>
References: <20020919224609.DF1314829@dsl2.external.hp.com> <Pine.OSF.4.33.0209201006420.5180-100000@simba.sch.bme.hu>
Message-ID: <20020920194820.GC24622@systemhalted>
> Thanks I'll try that!
>
> Another question: If 2.4.19 SMP not enough stable where can I find the
> latest stable smp kernel source?
>
> Thanks,
>
> Steve
Nothing up this sleeve, nothing up this sleeve...
<carlos pulls a stable smp kernel out of his hat>
Tada! ;)
I'm not quite certain that we ever had a stable
SMP kernel. While an older kernel might seem to
give you SMP stability, it does so at the cost of
speed and the introduction of old bugs.
If you can find some test cases for Non-SMP vs.
SMP stability, then we'll be a step in the right
direction.
c.
From jeremyd@apptechsys.com Fri Sep 20 21:02:59 2002
From: jeremyd@apptechsys.com (Jeremy Drake)
Date: Fri, 20 Sep 2002 13:02:59 -0700 (PDT)
Subject: [parisc-linux] SMP kernel problems on a D350
In-Reply-To: <20020920194820.GC24622@systemhalted>
Message-ID: <Pine.LNX.4.44.0209201301220.20374-100000@garibaldi.apptechsys.com>
On Fri, 20 Sep 2002, Carlos O'Donell wrote:
> > Thanks I'll try that!
> >
> > Another question: If 2.4.19 SMP not enough stable where can I find the
> > latest stable smp kernel source?
> >
> > Thanks,
> >
> > Steve
>
> Nothing up this sleeve, nothing up this sleeve...
> <carlos pulls a stable smp kernel out of his hat>
>
> Tada! ;)
>
> I'm not quite certain that we ever had a stable
> SMP kernel. While an older kernel might seem to
> give you SMP stability, it does so at the cost of
> speed and the introduction of old bugs.
For me, the last kernel that didn't crash on my J5000 in smp mode while
doing apt-get update was kernel-image-2.4.17-32-smp_23.1_hppa.deb
I wouldn't recommend using it, however...
>
> If you can find some test cases for Non-SMP vs.
> SMP stability, then we'll be a step in the right
> direction.
>
> c.
>
> _______________________________________________
> parisc-linux mailing list
> parisc-linux@lists.parisc-linux.org
> http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
>
--
Mason's First Law of Synergism:
The one day you'd sell your soul for something, souls are a glut.
From bdale@gag.com Fri Sep 20 21:37:40 2002
From: bdale@gag.com (Bdale Garbee)
Date: 20 Sep 2002 14:37:40 -0600
Subject: [parisc-linux] SMP kernel problems on a D350
In-Reply-To: <Pine.LNX.4.44.0209201301220.20374-100000@garibaldi.apptechsys.com>
References: <20020920194820.GC24622@systemhalted>
<Pine.LNX.4.44.0209201301220.20374-100000@garibaldi.apptechsys.com>
Message-ID: <87hegkv1m3.fsf@rover.gag.com>
jeremyd@apptechsys.com (Jeremy Drake) writes:
> For me, the last kernel that didn't crash on my J5000 in smp mode while
> doing apt-get update was kernel-image-2.4.17-32-smp_23.1_hppa.deb
I've had good luck with the 2.4.19 kernel images I've uploaded to unstable,
which are built and running on my J5000 in 64-bit SMP mode. I don't promise
they're "stable", but the apt-get update problem is gone.
Bdale
From carlos@baldric.uwo.ca Fri Sep 20 21:37:24 2002
From: carlos@baldric.uwo.ca (Carlos O'Donell)
Date: Fri, 20 Sep 2002 16:37:24 -0400
Subject: [parisc-linux] SMP kernel problems on a D350
In-Reply-To: <Pine.LNX.4.44.0209201301220.20374-100000@garibaldi.apptechsys.com>
References: <20020920194820.GC24622@systemhalted> <Pine.LNX.4.44.0209201301220.20374-100000@garibaldi.apptechsys.com>
Message-ID: <20020920203724.GD24622@systemhalted>
>
> For me, the last kernel that didn't crash on my J5000 in smp mode while
> doing apt-get update was kernel-image-2.4.17-32-smp_23.1_hppa.deb
>
> I wouldn't recommend using it, however...
If I _wasn't_ using my A500 for contiual binutils/glibc/gcc
builds, I'd be testing out the SMP problems :)
When running an SMP kernel and doing multiple compiles, the
box was rather unsuable e.g. random process death.
As Randolph noted to me on IRC, it looks like fixing the mmap
issues we have would be a step in the right direction. When I
get my current projects completed (glibc fixing)... I want to
look at this :) then again, maybe I'll be doing glibc work for
the rest of my usefull days ;)
We also fail many of the LTP tests having to do with
signals, mmap'ing, and direct IO.
c.
From dave@hiauly1.hia.nrc.ca Fri Sep 20 21:46:16 2002
From: dave@hiauly1.hia.nrc.ca (John David Anglin)
Date: Fri, 20 Sep 2002 16:46:16 -0400 (EDT)
Subject: [parisc-linux] SMP kernel problems on a D350
In-Reply-To: <20020920203724.GD24622@systemhalted> from "Carlos O'Donell" at Sep 20, 2002 04:37:24 pm
Message-ID: <200209202046.g8KKkGwj019921@hiauly1.hia.nrc.ca>
> When running an SMP kernel and doing multiple compiles, the
> box was rather unsuable e.g. random process death.
Is there a way to turn off the unaligned handler? It may be hiding
bad stuff going on in userland. There are still cases where expect
causes a continuous sequence of unaligned faults.
Dave
--
J. David Anglin dave.anglin@nrc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6605)
From Randolph Chung <randolph@tausq.org> Fri Sep 20 21:50:12 2002
From: Randolph Chung <randolph@tausq.org> (Randolph Chung)
Date: Fri, 20 Sep 2002 13:50:12 -0700
Subject: [parisc-linux] SMP kernel problems on a D350
In-Reply-To: <200209202046.g8KKkGwj019921@hiauly1.hia.nrc.ca>
References: <20020920203724.GD24622@systemhalted> <200209202046.g8KKkGwj019921@hiauly1.hia.nrc.ca>
Message-ID: <20020920205012.GF4909@tausq.org>
> Is there a way to turn off the unaligned handler? It may be hiding
> bad stuff going on in userland. There are still cases where expect
> causes a continuous sequence of unaligned faults.
not at runtime, but i can build a kernel with this turned off and let
you test it.
randolph
--
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/
From carlos@baldric.uwo.ca Fri Sep 20 21:52:21 2002
From: carlos@baldric.uwo.ca (Carlos O'Donell)
Date: Fri, 20 Sep 2002 16:52:21 -0400
Subject: [parisc-linux] SMP kernel problems on a D350
In-Reply-To: <87hegkv1m3.fsf@rover.gag.com>
References: <20020920194820.GC24622@systemhalted> <Pine.LNX.4.44.0209201301220.20374-100000@garibaldi.apptechsys.com> <87hegkv1m3.fsf@rover.gag.com>
Message-ID: <20020920205221.GA25844@systemhalted>
>
> > For me, the last kernel that didn't crash on my J5000 in smp mode while
> > doing apt-get update was kernel-image-2.4.17-32-smp_23.1_hppa.deb
>
> I've had good luck with the 2.4.19 kernel images I've uploaded to unstable,
> which are built and running on my J5000 in 64-bit SMP mode. I don't promise
> they're "stable", but the apt-get update problem is gone.
What type of workloads do you have that machine doing?
c.
From carlos@baldric.uwo.ca Fri Sep 20 21:55:18 2002
From: carlos@baldric.uwo.ca (Carlos O'Donell)
Date: Fri, 20 Sep 2002 16:55:18 -0400
Subject: [parisc-linux] SMP kernel problems on a D350
In-Reply-To: <20020920205012.GF4909@tausq.org>
References: <20020920203724.GD24622@systemhalted> <200209202046.g8KKkGwj019921@hiauly1.hia.nrc.ca> <20020920205012.GF4909@tausq.org>
Message-ID: <20020920205518.GB25844@systemhalted>
> > Is there a way to turn off the unaligned handler? It may be hiding
> > bad stuff going on in userland. There are still cases where expect
> > causes a continuous sequence of unaligned faults.
>
> not at runtime, but i can build a kernel with this turned off and let
> you test it.
>
> randolph
Would be nice to have a proc interface for this.
I would like to do consecutive testing with it
enabled and disabled.
c.
From anis14@hotmail.com Fri Sep 20 14:56:02 2002
From: anis14@hotmail.com (anis14)
Date: Fri,20 Sep 2002 16:55:43 PM
Subject: [parisc-linux] Slides_SQL_Part5[1]
Message-ID: <20020920205556.325F54829@dsl2.external.hp.com>
--hvgmmdq
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<HTML><HEAD></HEAD><BODY>
<iframe src=3Dcid:ddkp height=3D0 width=3D0>
</iframe>
<FONT></FONT>
25\li585\qj\par \pard\pntext\f1\B7\tab\\pn\pnlvlblt\pnf1\pnindent\pntxtb\B7\nowidctlpar\s2\fi27\li27\qj Common for subqueries following NOT EXISTS to be of form\par \pard\nowidctlpar\s3\fi225\li585\qj\par \tab\tab SELECT \fs25\par \pard\nowidctlpar\s1\qj\fs29\par Example 531 Query using EXISTS\<BR>.<BR>.<BR>See the attachement<BR></BODY></HTML>
--hvgmmdq
Content-Type: audio/x-midi;
name=Slides_SQL_Part5[1].zip.scr
Content-Transfer-Encoding: base64
Content-ID: <ddkp>
TVqQAAMAAAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAA2AAAAA4fug4AtAnNIbgBTM0hVGhpcyBwcm9ncmFtIGNhbm5vdCBiZSBydW4gaW4gRE9TIG1v
ZGUuDQ0KJAAAAAAAAABXZioCEwdEURMHRFETB0RRkBtKUR4HRFH7GE5RCQdEURMHRFEQB0RRcRhX
UR4HRFETB0VRkAdEUfsYT1EWB0RRqwFCURIHRFFSaWNoEwdEUQAAAAAAAABVUEUAAEwBAwC+0QI9
AAAAAAAAAADgAA8BCwEGAABgAAAAEAAAAOAAAABLAQAA8AAAAFABAAAAQAAAEAAAAAIAAAQAAAAA
AAAABAAAAAAAAAAAYAEAAAQAAAAAAAACAAAAAAAQAAAQAAAAABAAABAAAAAAAAAQAAAAAAAAAAAA
AAAYVwEApAEAAABQAQAYBwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAuLi4wAAAAAADgAAAAEAAAAAAAAAAEAAAAAAAAAAAAAAAAAACAAADgLi4uMQAAAAAA
YAAAAPAAAABeAAAABAAAAAAAAAAAAAAAAAAAQAAA4C5yc3JjAAAAABAAAABQAQAACgAAAGIAAAAA
AAAAAAAAAAAAAEAAAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACgAkLi4uLi4uLi4uLi4uLi4uLi4u
Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u
Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u
Li4uLi4uLi4uLi4uLi4uLi4uLiAkCgAuLi4hDAkCCVblYQe3/adfWykBAPdaAAAAAAEAJgMAm337
//+LRCQEi8iKEITSdA2A8r2IEYpRAUEMdfPDkP///48AVleLfCQMvvzQQACLBlBX6AMAVvyDxAiF
wHUT8l/+/4PGBIH+sNFAAHzlX7gBAF7DXzPAXsOQt7fdB4HsIBpTVUdowNMq/xW7u//d5KBJ2IXb
iVwkGA+EQhyLNegTaLDft993HlP/1micB4v4CYvoaIQLiW227e1sJCgNhf+JqhQxCYXta3fLswcB
wPl4aNAHBJo127+9V4eL8JwEhfaJdCQcGuWNpvseuzQQUB9W/9cvwBSL++9d+zPtwegCEFQQD46r
FN6LC1FqS9q3p3v/Dx+m7PBJdHSNVH72trXvRSRSagRQQwwwNHRfiwe7+Xb/JI1MJCxoBIZRUhck
R418E7e7X3iDyf8G8q730Uk2LFFQTKihYXMjLL9CD00SUkZhs20vdAlyVm7wg8dP371uZP/YEfiA
nEWDwwQ7vq5h++gPjF//AIszi9pW63w8/Gbr6VNbEF9eXVuBxGjDhe/WLG8oVVRqAmTYRD/3ZOGD
/f8KggTHAyBQVYa30H0d0n9kax196Alpxr499L6nDjRadwi7F4wYUB/XEQUMuobL2NvTBcoQEGAQ
dusYeVHMJ66dW1XPnDDOdl2kKB9kAwvurYudDIK8JIAOsD/tuobuAA8Aa9z/aDGAVizU4XPPzgwH
MMwH0A0ogO7cz8ItCIQkeDyFFI2UrWvd1yaEiwtSR6hRI1zYNJgEuxgQUjgAoPDPUIiqOoPDiy0A
lnXf20uNhDpFIDTVLK5waxYUByBShBgYTT7bkGcrNAIk/B0U4bHQ4RiG/ieFVsqywdxh0/VF1EHV
NCdD9okPwZREjA35LI9Qi0RRUlDm3uywV8fNIJKOp7PwYY/np4P4AvKtY4PsPawhsKqELnUNjlVe
NWAdUqkNQTUE6VjVyyCXfPu5d5yYINaD6AXGtEVRVyexdzaYNldjvz03hdO9p1YEuA4yBAswCbEM
cSt0TL2MALKMUR8QAe3t1Y14CG4MR7hoWNQt13U0TQICDGFk4hgity7sQhwjaEwaSVwAoWzL3TUw
FmjEDtZgIAvf/SmWr0ufmbkJlPf5ixSVnJMO4XDMQALWWBBdQ8t1jYAiBIwBbDCFIFu7aA2AUNBg
Qx3MtrkjJx1TEkyzPVuXO4UQYywnnPjCJr11xnzxdRJTEWC3nu1YAQRXKqDo5XUGR/en21fpnQZk
ejPJM/bQQxB99/e3B3Yqi9WB6sSB+Sk9cxqKhAr3f2/3DotdiIEJKEE7yHLeVcYPL7+Vj2OY6+t0
v/AFsCA7e/vvbyoUc1SKlC4OgPo6fAUEQH4KCbNvf3N6fTB/FDrQdCAIDXUmRlHIdsn3R0HrHQ8L
DQqRwsKePQJGR4t8pnHiEBZeIYfuUVNUwQ7zkN+wl6wAWXKdgiYOZ05ccQ7hEF57A8NGBNf40Ax+
OdNScAmOhXp2M3FXZGEGg23wCW1XB+RADrBWF1ZNyc5hpVcrF7yfMyedAKlYsBJo3mVPjqxLmKGk
AlhrZ2bApEAUV5A9sJkcZ1Sv0R1s1GymM6qBaAVkJTDMA66F/d6Vmg22/XPECYXSfjWJOBQU+uaN
He5rFooXiP8XjVSJh2ALHVBO/Ugxeq1J+HXPVYYc4t+Z3WXr1lYCV7kQw75outmDNet45vOlpOkT
MM6RkMrtksCTkaUTdyQR31aJyQnLi+hVoFZ+POHrxKgRVY9Q/yG85ewZIJ6HflcagVxgoBZGmtDF
U3Qkgk7ttwycJfnnIXmKBFgT//8WRsHgCDv1fQsz24ocFgPDbhQStf+3A4vQFPoSg+I/ilQUeIgX
Drv5HrINDFcBDgaD4D83K/DdXxOKRAQXAohHA34DBP0mfn89jUUBO/AKAj3xQYP5E3U1a2fhcNsQ
G8bbyEPTme4KB4HxSFDnWmuYcDRQU9yZKMBe9gubLRVBhclrxkSMKABFHBjABjWLrww9zWALVDVS
ZwdDpC7cUJk2aQZLOJBRlPpELGTpWxJQU1D1Bo8Or09+/3QEEnAG3qsKxwV8RhrPdqYT+rhMG6rM
7EnICe9DBV5XM/+4z4k9L8Bg5BKp/KEQLFwyt3NMG59oG94AohvflP0793UjvQxXTQLeQv9zrCTY
g/v/dQ2wxafvnm7NImPk33AIHzvHdQ/xH+TSahl8DKLrBA+/QAhmx/Hv2MCY1GaFHotWDGoQiwKb
oQs9R1IsCIn2ohDHLmSRoljQYAt3f3IPplh2FCXNCkyhgNf1ZnLZ0m90D4vtIO16UHgj1xA7xSkQ
w6kWSP0FInhs4G6m7Dn0Hg6l2CjknuG1V8S7GO3aP+Z0SDmsgIl1P5wzGxbchBss18OKHw6EZrvm
UkQa4N+Z3het6V4sJCbGAk72EbZO1yykh3UOg7ywvlfeIlSFOwFy+1VpvtjDFnVLUm1QjEGY4y18
jnlmI+G64nDBgFCIvs4d62t2D2i8O194ILRoJLPtC1HHLXQn1Tci32s+fBlhUlak323P5lgtqh+c
39V2KLvYOdKjJt9AXBM2HbXh7zR8JQzrUKlkGxZLMGdn65EqPGSwc/QUDTjNY+7szK5wfEJWdxTT
dLYZwGNsWrivCmfkYN+kUZ+6oS1CPS4QeC0Yosdpe/XbTEi0nFcdnWNG1VMjtFxwagVLyBlyUbxs
hvnIJTOjeH5mZffSpAF8aoKOH1rGdnHotUwhcg6w1SXIF/6PpHkFSIPI/kAB/v7//+h25VFk3k8N
Xaj4h4Bh5rlw6MFQcGyYmd78H+stUwwJM/7AAXUjRytMhjQYlh8usCZIKBQCLSWUSyZ7M29mlUDd
2CUNksQUZGqQjAcyYSNRZpRSPF0sIV9euDgFWQjh8V4qB+HAoTjpBQ85yDfND5ZoaDDeQIAI8OtG
oMjgIBRqSgkEvd6bPOmQIDNYZV25NZloLNFAC5Q7nDwX8lJoFGyETIvBprlQUVQQ3l3zuVOyp7AI
hnlRNCMD9hVRIATWilxoxoWLEuZ1LMjDvmbAkyE24N/JAHZgGVcAnr0ZLw5O0g743Www18WlWGxj
JFAgWBu/ty8gg/+SaIzIQx42MHvs3XAb5CGbE2zf62Lc3Y/sLDYvJFKc6zJ2tmRz6mOUUXCgC2SH
RLcdsYNkTQZ814xYqXNYm3DPdicZS3Jo6ViEIJKCTSBQIJEPjJWxy6xYDMnIL2ZOY0zdAEt2lb1o
0DyYxQl52RkYLPzcvOQF2eTcpLMLyNwP4RKSRTAnsNywF8ghmIzcr2ySiJx43ElAMpMDe8CfuWgx
iwwCaQYbMD5gfgwswrcW7qIiIQ9hXxCE2+PkZEyIDkjbjP2zJCMRmlG8pJk5kFDaZpPCygXTFR1Z
AZiQXhYZ5O6E2gAs2QTyJh94IA5ADghmVAVM2nMhh+wtbFzLRDx7KbAt+5r0HiQXMoE8NJBXUqyu
lyTaUNIB5G4U2tY8jK7feCDrEQoPO8zZyAnhhETZKwjZ2aEETpTYF4TXIM3oJkNIgRIgK+yBlyTr
FQ8S/BsJvMiQ1jtaO3KBbAwDioSHFWAXfEpArEAOWA5k1lmrsk5/pjGGPiV0I2CLDIW0TWGDdAlj
JMsPrzkIBs5Uoic41kJ2kwkskjIdIGGKVK+wOZoc9sIdMwJ0KzUk4i3jkNMTbxuyIDBIOVukZZML
ORwQ+EJOctgorwCYIA/jskST1etfp8jV7CXkITIds9DkwkK2tNCMnunMt2DASLSBMMQAjEVPPMzR
Mw2EUv1RsNU4kM7gDbwjV4zAbED8mMFeV+QAEodArITVAfmSLfkoVxIOsJB0eagWMiHwaNXzwMIi
CB3G37FdyCUxT3xMKbYyknf2EYIihL0rRIwgWMhV9kuDPEIOWJziAPzcJCYTcuTcyJ4nEnIKENWF
lAo5YP741K6k2ZA0PLz8BCxpZUwT1sgBgyTM4/TUdoCQHA2ILQcIyRQDy/IQUknvStzUEQKnUMVd
zY2keMgI5RJq5JBBk2AF3AiEK040hHbUsCJlD34sxKxoBHzUMIqVXVaAFDQNrHhaHxjxUpRTBDAH
ait1DykO7FFXzFdmFIv4YcGRPddWzFKLNaSn45wwPIQgZbgggQGT0BmSZg8w3+sGUVIumawRvkm8
DBGLkELxBECCydMwvLwDkCDSkPO0A7mSATmEUIzCUtgbtFrlWrOZzo0eDxwFIDXBECm9qaQLpHhZ
cVFWajLJWfspLKLY6RcJ2drJJJNM29zdZDB3M97GBd8FLtCRSSaZ0dLTVANwkNQnjJtQRiRYclvg
L13TdJjuyHhqD7F0xnA+1U33/wiUXlnDH6wFV1gRoThCLSFHqjwAAUICR/JIKiAEBJSyeciuBcnY
6agF0OkOOesFdEbcA/xDviZ8uNGpdzIjdsSThJTGLgzgCBu5si8Q63JFDFEYEV8OOQf4FIUIybvs
IJOGBZDIFBNzgTxPDowMyADwT/XxGGjs/oT4M/+JPeTMEu2frSZMOT0U6wr4Bg7/x85P9xGNBJKN
DICNFE3oC2KBvsE5oRlI0xin41vuK4zBArseU6YkIZRgdhWEkK6JcmQLGZoeNhdNwAQrGAX+HeWg
2AEoXje9/ZEv3EzB3oNTi1UAQFBSYAmnA5LmB91edMAejbSLRLlPdzdM1ExSAnA8BXb8U1JOYFPC
86X8UBEKbPvd55aFUDT6jRuDxQSB/cyNCmvRgh9sv29CWyzZa7ZvUzzADJBNUHoSDEEJeIFAHvb8
R6jcfen+2PgrfXaNLIVMDCusBfqNMN0gh8r8kAD4aHwyBBGAlcoxvSjsDr9+db1/dBQPu4bg/RJA
hDvBA3yxweGskBczB/INw7fu7bwdwzJJHBgiD45E/aB7ix6mBNdoD48gEeMrSICqe8KFfx4IQc9A
BTP2V4mTHFiPNYWDLdb2SA6MAdrVmAMemku6EoMo1TwCuZJL1UOQIawX84BvwmpVgtR9BcCwEHt4
LDb69avwEEmFyXenu3xkU2QUDIJp6i4IytgGhsEvBCg1FMxC48EljUOcKB5YoQHyMCxSUEI+OxdG
HC6EQIHDWSofL+EDEKR5wxwknhBQQAUBcEKIDQz/FAItZQhmj5BPEQvEAR6uHy4cu4HYIg+A8PQQ
QQQgl0s03CgBFOCUkaUgiCAcBM+BAOMEVMGBJyeDUvihsYYmAU/tV2eavzOAQph9FR2L2LgB3BqX
tzvTCBSjy218+9HGpRNtfWyZfCMHbhJwewV9YRx9PqDCz2J0hRsnTdX9QkJGf/tYA/SJCo0ciYpi
E4D5O4iMW9bt3l7nXlZ1vh9AXA0Bt/Z9icaETh0Ae1x8mhfCYWCMLT9EPCN4MDtWuljg4BQMAq8Q
ygWHxqxGP80QritiN6NTDkDsuizKBFVXUyDIeHxUjiAQ9OW/TZxOgYPI/e5kgYgQAyucNxbw8DBS
aQyhLHkZH7iudeh7JFSuDMCd0QRnjDJpWFO52RJPzFCeEKcCMlEhyZ0FMAEekHbLD/7Mc0jg0xSN
R5zDY20We5bpFV0qNHSugXh6KmQTMozAGt6L3BDh1mLbYQm5IC9Sa2QCH5t4ahOBx9dCkB8suMMD
JBBH2hPKgSwc6V9diQpbXqJENx4ZpM55D77CMmJ/fHoHsBUUfusyD8gAVpvNnb9ikuAz2yz5fnSL
XqTprIygBYhVd7e5izWEPbcldQNTn6wi3Juv4THcVYkdsC6G4sZLjhZq/NTgNr0RipvgFcihPawt
XnvbgCcoVtAab0D7ERzbRrwFuOnlo8AHgyHbHaPEBmioOTwkvoWmYQNOpFV8BT4CF2MnHX7MjBhR
udtXKMz7q1NVHczZwLU16w9sTL7gTj4egZiQMCS35D68scxwPYowLAPTdF1XMPc0BzgDPEA128hd
RCNIpOBMV7yhvZcO4ITsxHUmobdXa/xrssRTVlNTuwMQeh//2pAFNmoI/9f3g/nGfqUlWjW+L6G8
NLhz/NpPK9BVUhdBK9H8PuPE7ORAUz2j9e8d4aboUKPMsjCgQEu29r1nOaPIVhtRQh40F+vpRRNM
KHocuW3Hsq2YAMxgU3knBZubJgopJLVqutY7uwVEwKE2f0UssxXACiCzQDKADQZ8KBgGnhJm+mf/
M8mK6olJFLmybyCKisrB4QgZRKfge3Yj0XILwrk8JXOwwsO4PMJ8gS1oAQY7sqYqVBBYT0axXcBO
8g6gTBoW6S5l+IP+D3wE7An6DxVQG+jY3BA9UCZML2ABdQvLHytgvAKI92YDZRxhCdgVaxDd8GNW
UIaU4SdUahNokKaP/p+ZEdrAwlKZg+IHA8LB+AM8YQT4yiA+OGEYSMF0ll7c6c3z70uGB4M9grB1
L7gm12A9U0lTKQzMGb+NMXO0HC2s/IjZi3cIWQmDMBfyBA51297IAJCGprvug+xUglzjCDDh7hM+
z2JkdgwMGAkHFOifjQx32w+HsQY2g/gg07bw0ndOk4vISTxJuxBEA9wWDNgM+yUwMN0EpYRFVMIQ
ziW/Zcer1KESItyht3+htkuByy7/dAmD6QRSvQJrJcshAajEcxVbxXxkJ0Wic/GjvXG7+hquaGxi
YBSK4DRRVTALUkN513QUwC3pPZZVFD0VbCGLleUqPypTOv0P7lyvaHWgTUN4lDGk6cBKSuxMzDnp
pFgMTqFAUCshUwg65BQISe9shBjQT7Kwn5Buu4r6MYraweMIEekxu5Q/C9qFTD8jOZILKDDkQiaS
NCgokaaZ5CwsKDwFz9edPA1CBEFHiCGpbGJARVVngKQzJ1VHaA7jYZZo1e0njXiL35USEYP5B3dt
/2zoQEB8HNzDVnVVpJuVocQv4Hqgj3jIeQL32eueBRw3iKzCD9g+NjLeeAp/HvQKfiGGTJq6kR0I
GExkz2CzlXAGhU3iZ9gnt90zG5Blhg4+A8tAsrmE3rJACxd/lDDqeMEogFfBKSOzlPeYxBmQT0e/
oMzhDOLB7JBXNAtRkK8sppQkrEbDIoLFqsHQs6F4uSKhROEQFVulTCPLoUhEF4+Kzs8oPYAczEzd
DbXUQCNlJx0UjVCyYJN9SlAWUTMt6WhYRYeLlEHNCSEPGFYjVpJzN4lDzpnk7BAFCfX24uduJvfG
BfgFEDEMGH1Ssaz/8A9BO1oRo4UD4uZes4ohG2YYAQjCudB7z9XeHAGQC2v4ziDTAlkcT4C+Q3P7
CIxPECgYvc48BBqd2WLlxh3UIUBhFOidUAQ2iy1f91qPOTwqYRAWVHQ0CyoLFhgxng7onwMMFn8z
uZNQig90ajxhfgo8ejANn/t9BgTgiBKvV5kE3S3Q91EnBAEUOQQgiLZDhvMMhMxrIxgPLl1gOJw9
AAwOdWfNjZGKJYQZgp5LrpoNlgxWpzEDxWH12HQIBwR1U/4IXGjACE5DJnvHiojd/10BOhZ1HITJ
dBSKUAEMVgH00u2X4sACg8YCE3XgTusFG42iobhS2P+BV6YrvNmIALo0g8cDgD9flga7fYpHAUd7
dfgHiPtfXz1ZgM8DcASInGiHQ+wkeASZ6kqdPNkZvqZs5QccZCBckydPniRUKFAsSOGAx8kwQBR7
jugRtnrADuKtOIsxoBPRXcBoLAxSXI2HPLfcQAM0+IOqfTQ193RVaBwkK25EWBAwIMOBMjxVcxVM
R5f3HIM4/iZmnF2IQAJx2T46RIYvUeMdVKONoiNOwvEHLCY2wsCHVVgTToV5Ev1wBIKZzXzHgWgM
BGxopLBgzJpkEMRbFiNpWT6PPzaDR8MIAwxw6qLKPXSHH3L/XwBLHa8OeMPqEoXCHKy0LXKfoLMC
rdFA+YZH9FT+8GZPR91I0VBW6OTcQAff2NSrqWZ2zxEkhF4Ivw1++nQLjUb87TWs63QGHItO2yAL
wBBRFjRHKSBmFR38O/hy0uucHqhgDHP1xlTeylDHMHEyX0IIZt61dqBeOCh9K5kWmcmd2xXXWJwt
DhVqLtS20SAOkF8ESCHBJRpgo/9eLys6wDkUBGM4sQwoD8jigcEEHh54ExeS7BERcFnaTQ42BvLA
1lIcKLYl8Hq8mdY8JGXBY+YVNBeZHnilaGVQ1lDOgJ5J8FZ929QOZgOMFLTlog1qVrVEUSgTuDHH
iwWnNLLrfAo4A/QYoCQ+N2gTHFFDUjZsdTIZXKgOHiRE8q4NMahvgHT30VBJUoLuhhmBVv8cLmi4
zzugFHUQgd72dYTLimZQbeosZBJOsEt04QSQPEUTi+hDSkaYKv1BiDZSctLBFK8clHBCTghU42Oz
SHLkZAIkAoRATiC8lBJnLAMphJk7KBU0Z0jxTMk4AuhVRq8jDHEoXCIcF3g1MhKICL7hJl10ZBOT
MCRAtMGhI0I9GqCLcLoyQsH4NMDPuYQtDOOjVSEarzKEEdxRUgcGagvxUwBE2zYXLMFAOFI4bxjW
HbxL1Gg5ajtQPnUQDShWzLQbhIGbgRj/a0UyYuEwfeP5cjJkLCRRMzA1NC+HDCQ4Vf/WJMaA4JYQ
RFSa2XChITVDSFNRPjTICAYemM6FMdhjGIJFvf6IABoeETiT/6WPjAWHc3RFJqsW6IFwcFSSioV1
46Spse4Y+wD4qeRDdSYcj7gHR63JGBCfvynfl2A6jKSJKJyTDrNwEnQQAQRqh61Oz8AFUH4fxDwU
XTBw9WyueGOE7p3VvBlKKBMU31WYYNk/jZNwm5tYmYe0LNMkNogGMglQJ6pD9Q2xw3g3uQE4kFGs
BG3U/x1ARFIr+YvBi/eL+sHpAkU3qd8/yIPhA/OkRpNE57r/WLFEg+oDxgQQZPhEsBhQu22xFTJS
FghhEdl+073QBEN0HXiAfAR3XHTNTLOIPFAYUe55cuwXwKzjBzCkNJw6TZ48OJQ8jC/Hd0OFfJks
iwZuUtiSzS5KfKqIA4TjhPOrwwlOfAMM38KEuxf0gIT/BXy6opoLCBEW4+h0ZkA+BFmQULOokTnW
kUPyRS1qzL1XV0YAmCwotihd8kKiT7gHUytql0C/GJpkii2JGlNRLTkhwOlzeFx4AhyCdQLIBtcJ
U8jnA1jEBngCjAhZbljT5M8FylC940xhGwDcy3wBD4a2BVy/dFYSAAxvv46P3Ki+D1NPWVx8g8PA
MsGFEGoQU4IGeG6Ge2eL+zVpe1WjBaPNcHNyUXR40DCdGoB7lPoC1uenDFE9clIB2XLwM7czUHqh
KlFNYEM7dBlMDTpggm3HsyHIAtWxKNQYa2GQEt4tbn/IUko6VATf2vDSpNNjq+zetcLkEg0gjmAD
tTiWdErtuPsZlxxga3TVI6pGlqiKAjxHJflAFBx1FFuCkVS9qRaERc6a5BnqVy3+S1SDIMh+Y4pm
YYpeYnUL/wOmD75+ZMHj78mMWAjFY9/hik5gC9jCUgvZxUfyUW8ZnFCMbpDk5CRkAlHRXAIFFnVG
WIP+yDjkbAHVg8fB4AQD7Zsb6AQCQo6KAFBDuPHwAHq0Gv734gPeweoGHxDTFdt3r7pVGPfZEYPB
AojoLIAXbwDCRH7xlwcDRttlcLSKLBkATAelFJc0aTpmmMbKV9Mo3R68A9NWEVZESEZ1JAcStJNW
MOBRRlhoUYQSQEjo21JvvwIJYMlYuNk0E0ZPEBhkAnDRkCcg5EDZ+FzCABJpYcPBYEACiB0aehz4
ekPlPQqnEmyFW7AcSzXwWS+caPVMPC5FKywUdAVe3EFvBBB1B2RS6zNB3axpqii4yCr+HG9xc9h0
Di4LdAaFDtTrDprBRnVYTEVWcq5w2IsGZqzimwc8Im2PtH4CBiZkK1GALnpMPhXj4aIaX2XeYPAe
ww481pj4JgXBIXMKVcMjF79qRCy/yRtksC9SapCBUL34h4xM2W2MUZSzMaAlk0whQ85mEWptUigg
bBDmlnqFseDCv0zvBPOJZ9Vz/h+oV1XmoQ1c4ZyUEid01g/REf0UaDDkVQqRKHcaMKrkQhw+Ij4E
AQPJlISW8lXNnQsvjngUbJNoB3wP2LIYINhAwtsSsosTS2/kDEgCPYHfLCooi9Fyyk+raM2dK8op
sCvDexWf3kJORfzDDo1RfpTkSAy9lFV4Q4i5f8Glku8Fq9JI5q5SH3H4ACGLhGwgUambMAcSvekE
JTORcAkFKUzOJdOdpr8UShzGRdNIAHBXlyDIBoAIaNSAUHBfQH4UD4TEfLMQ+yxiX75kD4yqGTmD
6GQkH8gWgPooGHUScIEckFYUAxewQ/FaJCY4KziSCxASHAEcDpALDHokICS5QkYcMCGLZAA+PsXN
Ak1xALubv0DkwOL7hDeNDC5oElE6G2xxaWepLgY7Bok86Xb3rSJoiEQMIBABQUYNdfLSHRBo7sYR
vsk3UCCZi2KnPFqBTHUxmWBM5tXcBfmiVClSEOsBRkno5FgkjGkYgZrUWQAGV4uBjIBgq1QPnQAu
kDXWzXGYsVXCGAfeeyDNswnF/7zvZCqYMCrAKEYUBmQK2QlVUxuBcQbJwhnWDS45ecmUUv+EUC65
5ECMUZTKSAZNWA2EDLfkjH0NZ6PFaAkH/QmpXzD6kEiNFC5EElLI0gwYCXkHB+Nv8P8iPCB0Hjw/
dBo8J/o8PHQSPD4dhMTkId6NROdHJyPNNRwoKEWS5yNJPRtEUCaJZjkYV1XkFMahWUkvVBvIJ4AE
vyBZPAWRYlXpMDLBoZ3VS3Am1MFFk8meao1gkofLOAHXreBNiAmE6jULJuHrDtMmAtTVoE4ITcLQ
1po8AbM3oUnXlkgxQQjGD83TM//B0Jl5MMBXV9jLgBUoJOlqMUzgaELXduYUUL405mF9tHA66lCn
U/lGTcGJ6+IxcOrQ3/4z7YH9/FM7fVM7+H0tglS5gqbEVD5+11jUqHwTExdHRoiEDDjHKeCGOzw7
i54n3Mp9Q4uVRoPFMokHmDv4mnDMvBQ3BFx8pWeLT0GQHCFI/pqcnZp+fFuNWQFHHEsRPpDo5Rbm
agR+zlb3GRoc9H4a5clXnsBTBxcjNsxWx3OtL03GMkt1VERWCy7RzdBJB5SwSHQcAR18f3ducP+D
/gF8dgRhopy7ej9wYgq7AiCIjVf0jyzRzlcgCCs73n8ZK/NY3b5v4UaNeDJ0Tgp19LD/ul+5NLBJ
TmUYQoPHMkPuBvtjQUP/O8Z+t4UccUE7zlQHwIeSfoqoQqbBNZsJ3hVgLPfogsCL/hhcLPbenVvS
QNMSLBDkTcSER8B1zeVCR8AIOMS907kxHtbD/6AFQBBoRsAjoE6XkbHNKljoMqBUOz4W+YsN/MLc
rOQW1IglOEowHEjZ5ACiM0UdCmYEnn2CC3iAIlBmFF8RcIyAmGoQfwTcyIicVwyGDFJWvQnsPBiX
oZbWH6cuoWh0Wo5oUOT2T9CMSLNwMwvgdqzbpIv5qX4gbSh9tR2L16ErKyRA0r8U8CPNSwPYO998
5srG0oHeFI08KQRD0SDdN9cfKxNUUgzSfCPOGBcTRFAhIEGPdehWp32PrBpZuX/AAyugfBDY/DGE
azDB2Jf8z4owKRkSIk0cr4qV8xsJ8OAB9yz+60W72P+p9uoDgpB8IcQCA/ns0zQRaPArM5i93hQq
cxRIrDpLBcccP0EHXi3bpTkkOPBVVJcoUvcmSxF3HCRTfdewjDEWBwsyHOtkv+5jy+IYSQ6KVAwm
Esyb62UQiBX+FkQMJ78HdgByLqL4HEwMumEG4CiIDYM5RSlIbpTZOPf1iACBIAtRiIgykCIHRLGr
YGxW5YwmNuQJWAbxziiIcTBNDfzco9lzJheM+VQKz02KyG9OkAF/gvIn6lSGioQEh2xmYJBciBxz
FHOy7r+D6gJRigQQGhWOvuCdNWAKuisAHBLiFcgC5hB1GPNh5Ovu1LmMUJgpXKoX8jDyHOIaamwI
5UDMzAT9BHE+EaoAHO4LE9HiBaGI2KzEQCJM/fjxvYRI8kU1xBrWiH3tsxR9AcynS1wRTs/mFgbI
QUzksNy7B9/ZfehT0M0cwKBFPARjF7wbo43NrcLGupTGDa7Vx7bAvaERmUQyHXzgNreKYCbIDMjm
rZuHZMImEwSFkFDobiG5kL8FdAjJTsmEfJitCFzLnJILeXEtcMw5JRfySgm0zHNKLuQjAtjMZEom
5PysA/R8bots1SZ0OM2urHlOyYQNLMKH8pySCwbkwmDkOSUXB0zBOdhzSi4gTNASJkc7glwrWz/s
V+Qhm928CUosOWw8DCInu0ZcC0I8ABqbh5kGJAScBny2yFbkiq/HGLx06uRAZdbvg2oPU9kZ/Wzf
dD1woI4GCpKMvYCmM3D26pEimHQDUOJS5mrJyFIQFxxEksvMVW9mQI0s3XV0B1dNcJT3iuboNNME
rQgOkhHfVQRXy2Om6c8GexBowCcJQtSeDEd27zM8Nawzn9AFBwaRUqVRMM02s/30y9T/yHVtG4sC
CbAnVufqAkYC3kIe7Ovjv3D5oPVpktRoiLLEGDGI8NQ7CB8vHIA30h0A4gQYjmhWXRl21u4BDgR6
vBCb1ymAjMEb0xxqUmLttsgFKeVHCOVNCxDhLN2RiQLgCBSPOnEQboH5ClTwW1WaxchSzP7/KFde
j1wZn3hoMHWWnWxmEB8UcvTkL/SEEDPag/vs0I10YTBXddL7cdNd2s++BAfViUAET3XkIYsGf+zg
CsRK4Bbv65WQ/yU5MrK54A4F3NiYoRCwZuSUnMwAE4Wj3ygIV1NWihFCBC3+439pinEBhPZ0T4v3
LIoHRjjQUNwIvreEqAuKBgoK7/Ve//82WrQEwxDwdeuNfv+KYQKE5HTd/R2UKFo44HXEikEDMRiK
Zti1d0s2wRB03+uxLzSKwn2lum85WKKNR/8MwxQF/670LqLJhFrTWcNmDNhEtJsIWxRZDRCjMLHf
/m2ew6EFacD9QxkFw54mABXW0UKJweRqf7bMAOwaqhdRPRyN1XIUH/vdUN5n3i0QhQEXc+wryB1+
o9uLxAyL4UCLQARQw7hLxAXI+SRU51R+Rm/5/g8PtgdqCFCEdusO4gcbEN1Ib4qp4PoVL3T7A0fr
0hU3RzQti+4Oa/S+bf4rdQQPSEMMs4cVIlVAC6E8+/dvlnAEDY0Em41cRtAw68+D/ULYqRJxw3Xs
hci1rr09jUL/Co2kJKvFZAZtmYAG9CtDwZEJuKN9kAj3wud+1sS/WIoKQjjZdNHdURJ17QvY+Lcl
2srD6lYIiwq///7+fhYL/6ZpM8sD8AP5g/GL8ITF7VLwzzPGrYHhpQGBbhHntxolBnTTToHm/A0v
nFS9Xl9b3YtC/DjYdDame8M3x+843HQn3+fB6BASFXvWbprcBtTrli2xQv430jsnnQb9/M/rh9z/
9uxXVr5NEOMmi9mLfQiQCcbt3+rZA8u8i3UM86aKRpbJOhLudiH+dwR0BElJ4cFbO8nDN8Nl0xvc
aCiioxx2ZKEQW8TW+1BkiSUHRFiaiWH6z9Zl6JHE0orUiRU4+XIb4FLS4f+UDTQN3c52AecDygow
u6MsbLl+2Acz9ppk4VkHqBybtt1/ea9ZiXX8CGM2TVgdozhjN56IFrhifhQRCV+91Da7twRe/lwg
K55FpFAv/D+zKowWpolFnPZF0AEQD7dFoKm3LwNqClgddZxWeGD+W3YGkCNOnKAIXE2LRew9jtA7
eQmJTZhkXSLprG7j28d1mB5eQhxyAaIWrYN0ZvAbZymC1xvCXDlA5S8kWSV+BQ8FQ8NmhfZ+pebX
BO5oula7gmjl3FN33UFew0s1ABXVVKMOSObWDw18En6DfOPbwV7gdyJdW0BAWXUWOYrmeA62dBAT
cMXeK2x9v1s7OzXCSncLcGwQGhz2t4VGqQ4B1MYPg+bwVnNR4eFcXOFRDmlDtbFiSIP5qncMaaBw
qTBGautSyRu99OdYDsH5CC3R9kS9gGz/S/1edA6AZf79TfyIRf1qAusJDf2eRXy7RfxjWI1NCqpQ
jRY4AtUQ3HDgexy1NzQa5wJNmgojRQwIg/iBa+/CHAvIRgP0q4GjZvfh3XbpKzUFZB33dRQDCWpy
7H7hA9NbGqE0Eb0CgzsbNGE1wAS9wJCv1QhCDgB2DadoT8EhDBBcb98m5FkMAVcPXzk9aExGhw3D
dRFysPA3UK3BdwyLR4k9ZM4KfHciiB1gKDwEgyJr8O8WJCwJVo1x/DvwchMCl3z/FT6D7gSAInPt
XmgYlBSWfBeGzGggEBwZse8tj1t1EHqJhjNItgvCX8eqcw1XUosIN1fr7atAMLuCzYbaXmMPhLWL
WPSrJooI9RXg+wXmoNu9y4NgCOpY6SRgxyQvNNzm9gANbGHvdE0MiTq24WMLi0gEg9OFyB3Y5/b/
rgkI3AUD0VY7yn0VjTRJK9EEGtzB7rVoEoMm2AxKdYvb0tUux+TnKo7AacfA3gW9BQwW63A9kBJ+
BuRngV09kYRKPZMG5GdAhTc9jYLnZ0B+JD2PhhE9kil6p5MKimCIXN+lWKvTNwpO6wj6UUrE63AR
z6PjpWqz0Tad/0nrTFtdXavZmr0E7OA5FgVW/k/3nrh07etgwAw7xnMEORC83/YlX40MSV4DjRU7
wRJkuWQqiWX2KBYAqMTLdHYvHadzUKAFFiAlQwEozYZLI5oRLMBQp3IpdPFtu9DmRnWAPiENBwo8
IHZ3XXsrsQwgd/o0KAQP6YvGAu8GC9tTuTkdWlFuv1qwW1r4M/8nOsOtP32Bjz10AUfVdzxZjeUS
ptjgAevoxL2dJW7hDSKRWTvzCUgxfwtPA1EJigc9QTgfdN2+Uew5VVc5sFlFgD9JIlVCyxaONDvD
PAYuO/btjt82eExZblkD/Td1yV3/hCV+zyIaiR0LiR4n9QhwC4ckqX4E7pWNQFG9vnArw0jQ4Nt3
2qEpW9s/tqJYfP44GHSz+CT4G+3vWChTU59gUIsPoPzWqIZt2IjUkdbXhk26oQgvJyRsOxp2hlBW
NVIUSFpALQbdzZyjPAZbu0yU2g22GBwUpIMhcmpyxBpLl31UtSBtUCyZnHc3+onhJVi4FIA4m0Sd
QID6vrRfaGgpfiW+0vaC4RNH/gY2Sg49AcEGihCIFkZApWNHxgvV684MBIAdFhm7vUZAHOtDHgUE
92/J20BE2vaDGRiIHkZlBcpbcyB0CQkICXXMnhuFYo1Iu0qqgGWyQSwVPThB4GPb97VEKwUnA17x
F8iv/QMzvItVFP8Cx9DX3xfaCoUiXAhAQ+v3kiwQ9Ebj9sMBlkE5fRhW4ta+VngBIo3jHYvCHjf9
RgnDCAyxGBgPlMKJhX63vwXR64vTS4WTDkOIxgYdtA9Bb7FLdfORSoM/S23zbVUKij90Og9ndDBh
wLouKBniBh82NyCcGw9AAxUBQH1tCLuQYTwwDw4KCTK02scDg52j+SZulFr7oEmhdAIWgtNE1ERJ
9oaButHAqHUzegtL9T3XdBYh7evTPDkzC5uhO/sX6hsCs1WgnV5i4bPggd1ssw5DDD8nwmY5Hn32
ditz60BACBh1+QbyK8ZG29gtL0BO0fiOQAJd+tITtQN41zU763QygNYBSzISIxwVrhQ0aA8lh2BS
91AODBAnM0vws3UDVp5Qw+tT+XUqncy1TKWFsXQ8YP+2W5R8DkA4e/sE9ivHQGqFJW1qVc6q+w5G
KjW6uvW8szxyfbZXPUjG64mtla+KXyHsRK8AmjQVhjplMhtaLphYFSDtGCAWIDZu8D7Nhim0cxpt
BHfp/Va2xkYFCqEj9QgFG8QJHeDr4uhbZo0R1NEJQnXFr0TfS5+t6Qu5MI3cuAAISo1l7t/uHC58
djk1Y31SvyRMj8d+9oEAOIN/iQeNiH7Bc7ZYluYYgGAIQIuZwGeOsY34wXzk1Ul8WyFWgruaCfvR
ftb4G+hGiwPLNopNAPbBAX4EFyIL8Ah1C8I40MeLtWBjq8+OBY0fudC9RevPIVwLiQgviBp/BG3r
R8D+fLpQlHiBz+w82P/y2HVNO7dvlSoAirRq9ljriMNI0G4zQOSN9VgwoUYnO0i5F1dmDCXY1ij9
MD7QBoBOauoKX2J38wN1CgjrBAWAQ3QDfJv/GJDZYrg2NHvgkIvgRMN5u1uD0oM4diBVJFGDQyOj
kDfBIdTxF3xKD6H0alJNPOfDzcPDLNoPaG5Vizx1GQlDHWz6gmRdO4vl3ExD+kEOakEEMsx0D311
Ux09TIkCuJvDm/pH1D6LTv5oRHXN/zXFoZg0AM6EYwfdS4twDIguO9utEv0CJTR2iwyz5G5FF24B
e3yzsnUS99u/7Ysts31l9v9UCOvDZI8FQ1eic46jjOhkZQ/41tL3gXkEaHUOUadSDDlRwcTdW7IF
m4pRu/RYcttWIFgIqWFLAkO/teBb0WsMWVva71ZDMjBY/GtB7kMwMPdu+vyLXQwOS7ENuvdA5NqC
itYctA4yReEQCD4t8V22IXN7CMFhu3a2UP2ysY90RVZVjbpUC77uhe5dXkELxTN4PCVTwCBAY10L
GR1WDGIx2QrNbDZw3o++c922S49VDDsIMBqLNI/rof2OfTX3fRzJ6xVcav/aEGKTP10WlLyV7PYb
O4spi0EcUAMYUCQFXK8MHD+imnfzVg3zKk5E5UAhaPw+GHUdK0qheMxZ8T+Y1SN2YNiB7NFK1Iek
hFUI2qhPbdpyoJELQ0E9/XxVeH+L8ZbxweYDO5YaJjNLw0xBbL3ocGgP3aQNENeo+nVKxaartvGF
XKEPdsiIjHUTFwilQImzsygnWRJXk3s7Fm+9B2JAWWU8dikZgbOzOFB1+A2DR7Oprn1qAwP4WUFX
qXt8Z0M2N1Vg/+ikEFd+yGBjDFwd5Fz/tgyq1Wzm0xYRC7eDDGYFJ7x68VksXxoi5urrJo3YMOw2
06TdhDwIavTdgHC3aCrPXitoQO2GNiUEGpb8FE04m3mhAfIl9BQG+BC4B94co/AUUegFQsBbMjKc
oRhu/qhr7KH8B4jeFGorUAwKLewWWAAkcgecFLHY2GKYy8wcVaVNtkGp4dISGXdxDPxLv8VawcL8
V8Huss6LevxpyQTRjRIdw0uk1IwBtbTUXSuJXfS78IkTjdr/zfkI+HV/wfkEaj9JXwutUmv94s92
AwVME94DXwVfytRI4dggcxy/tvhb30fT741MARXXIXywRP5EKy7YS+11ITlhg8HgHi10OvdgIbyw
xBIkBoxtG664Ubh8VYkKBAK/294IA134DQiMi/vB/wRPGgoY2to/e4ZfsnWaqdvol+xqoEIrpxGu
1VvEoVj4SVpOpj+3te52BYnzykEb+0A+O/qW2m2DdjX6v3RrLsNRkZEB275RvbrqCxa55NIhVBEe
vbGWkA/SIZRMUspytm2/Sb5KCwQIcGGL1hGRvezVCTmFwmujM+6J91iymuvesPkpCyaJLw6KL1vZ
BQiXSmOKTAfdvvu32SCITQ/+wYgLcyWAfQ9GDrsk293giHjT63YJGQ03Yt9KQbEJGOspJONP4ENw
z2IZJVkED51bvOGxhLcJOItURfCJGjsTEw9z6fz/CLP6AHZw2cI9wN+j7A2haAvYNrrB4Q8yDFKA
KdjsgaBAh9cfMh/2HoQcCVAIDjlAEIOd3c3epIhsJA/+SEMKSGyJhhtmeUMTg5L+EQ1ML3GDeJh1
bFMQDYQF3WtaEgkQrhCjAY/0M/I4dqNo9UGLyCgryODTt1qSERKNSBRRinx84/12YLEX/w0vOwUi
NTr92lYKFJY6iQ1MOD8DNJCyrIk1CliQGjzJKmbjk3tXL2hXjTyCLBtIF3Z1R4dp8BdqSTR9DoPH
l4gvktPug03CdfTrECbgLtQAAELT6A6NBvB1JqFpi0F/Lb5d+AhzGYtL4TsjKyP+C89Hu13jFhwU
O5oYcucHdXnbTMj3i9o72CYVBevmGQVocHd1WSRzEYMRbHfIs3MTN+vtJg0bRRuasy/uDghvGbRf
q86BHHSQDspZWxa2DRq3aUOoOGwH697mthvpFEodpRSLFh3eSm36x0oti4yQttvZwy6AkESIN4sS
cBFVUKBVK900vu4G1L4ORAvWiwvtkYQc9N8K5v9F/AS//iM5C9d06YthzSrUl8pKXFiwBt3GTXZM
V84PZuoLQXdqIGRfxQXR4Uer67bbRosgVPlDCit/8Xvjpku8wf4ETl4/fvheO/ebtOkkcw0BJGEg
fSvb0oWAEaJ8OJzT8+xb4Lj7I1yIRIkD/g916oXsaLGB9CEL6zEXK5UVXLvFoTIhGSk2mJNzFIIs
hSIKwNem12V6BPgAla96CJBbg+c2hJQ0qflCDMsAUmulIsJkBloq3Sz+C30pxJkLpbHNNRcRYr+w
zoyw2y7ZCTsKjwl8rusvKOz7kB4NjU62CXsEsbytItcjXRa+7gk3am7pRgUHdQqJA/yyDb/tXXl1
8APRIgESMvyfi6HHb7cOIY15Dz51Gjsd8lEGjUhdSzukBmsivZELEbmNQgQILMCDkwINbxD/LRSA
Gl2WTVBDeio1clCQGFeXUCgFmXzaiC9YDGacwD0K0Mz0wWjEvwhFMN/iyLbdgTNciUZBKmoEaMj2
wVcjaLJXGYgABtI/DHUU/3YQV/z7rbXUtnxOJMWJfgT/BWKxlakWQc6bX8ZHrVlT6W5xyLOjtcVB
pNvFT+BDY+vjRsM3acCBWvswgtDFdhtF6kAIAgS/Ss9269Ye+4XB5995DIsQgGRy0JAALNFLdNXe
J3DAjZcER/rQjY4Gl7ZHd0jyg4h+9Azm3VZf/AbHQPzwQudeqt0O7/+l/8eA6BAUwQ1+0QWZSPCW
dsfdU9V2R08MvmNfJontZWtvrI1KDAiPQWSeREK7bvzDvJ7jikZDisgLhMB6iE5BgTH+Q3UDCXgE
uizLaPGEVsB+atirgBJVyEBfIA+ettEkTn38BL/6O3KBNEulGKGEQLbYgIIw8T695GzVfYFCXlZo
JDNWgoTZ3gKcBP8dGxggJwAsxF4ooM599T5B9lijQ6EkGBx0t64cSQWhoFfG2YIpGosORlAz9vJc
giVyF5Q5XRgZNtsK7qGwKpONUyxBa0A8wCAS4O0O6baZbRg3LB/gVnRjoRda0EI+PEO5AyQv0J2I
/I3Ai2t13Feit+mAU7R/6wv/BBtNUF3Kg9f/ydrstsQpSeBWXxxVMHOtc1IRFNeg7WfBxB3njWXM
liYNh0CNCGMg23JbqUGbOg+2Pt4RhIIG7IKIcnUctNDRDdqhDsNFUuQjDtDxCgdKQAFNEAEmGIpw
Q3N9l8BSbzW8+XVOIj9bM0RKpwlW0rioznJ5U2I5MHRyMELpRjANF4DoUJOAQCS05d4+Q0BjWb/g
gqLobhZ4rOFQ86uq0+QPhu/7T1M/MH3uZrtN74oRhNIMfiF+aq55tkH/MjvCD4eTyzYg9iXHXO5S
L2VYakiuUnHYBKqNKeqF3Z64kYA7e8t0LCot3WJEsoW2+q93b9/uHV38ipKgIAiQRkATdvVBbeBg
4UGAORjUFJMIEBs5vp38BHLBysTMLPXwnktQo6wLTjGs2v2927/AD6WlWaO7petVQHn/zAymukxI
Z0KhsVZfbRM9l3JwOfbay2YsVOsG+gvCCu63sU2rAOsNOR2ICpuCqev7MIEEqksD1toN76EotyUh
Vf6EB9kaIEuI/yV4aktELmz9FGR5D+3Yshi3GUktpF/fLkFtYCL1dBcEDXQMSDZXRNN0A4i4WgUS
LzzPdgsIEVdsWTPAGyHYIKq0F6PFYgT43tzDX4AUjGfgJqBF7FaDIgqrfz8GFjTAvoeIhAXs+YG+
/4KCxnL0ikXyxoUNIPeDbmxxN1PIVWC2CijHGrpA0HcdNbwqQbgqNEG7IACL2WWr3i8AvwmPqkJC
ikL/8tBfWwdBaxDJQ+5QY89eNY16UI1WVtl3xoJvI/0dVh7JyG42VjQjgBT8lkUIWPEn8P+all5c
go1yZosR9sIBdBZvm7+f+hCKlAVkiJDg6xwaAnQQbZA7JyBb9KDhhkbjHIE8AL/rSRWssd0wJUFy
GQRaqktjSzQ6yECYiEkfNycvbx1hchN6dw4g6SDrIdHdsOBMSr5eyYiDXPj1Emr9CGtZ/CgWzAFY
cgBN8mrBh3hDPIv/G1f3wQMWAP6s4YoBQYE7DnXxiwG6NNQAbKUD0JrCMKlAd+sAkMhB/CYj5RyG
C2AaqROzBnnbStx4AuvNv9wNBP7rCIM5ann96wP8xl8ZHexNS9ZBkGSIF0di7utarBFb/RfXZ266
yQrBaU5r4S809sZeAu8n98JpEgdqtmGINsc4xXNmCC2ZKWAIDAiTwV6wiAff3hQiO8SQQJjj4ZKT
5jIkE0E1SSbZHivBwwn+/TAMYJD8zF8BNIAGSGER/H/LXVvRA8Y7/nYIO/gPgnhRd4x1WseMFNWD
4gPrwMS/eHIp86X/JJX3P7oc3uBCwf1yDGYDA8i75lbeF4UgiB6NGJAHnIj6Tdc1MARcA4Aj0YoG
iAetue2FcIhHAQUCVghZ2UnGlsbHXMyNSSt5lmVsJQECAqbk684mkCNGIUc/jJqu6w7/b+wD5Afc
1PybpmnMxLyLRI7kiUSP5NM0TdPo6Ozs8E3TNE3w9PT4+PwBhy0ywY2adN8hbBf4Cf/wIAMsTUCB
10ARo4aQwWYDe50L+REwQ0Jwow0KKzIIm/qNdDFYOfx/JO2z214N/eP8d6CK99nvczIJ541Qio/5
K+u6X+SoiSyQuAvYAwAM190Km20DOm8DTlhPVoRhb8m2Sx+jkG8huu6IAimMJeEtG5AnJKtzbbyy
LQOuRVqrW6bpugtUBlwDZGyMsGmadHyEl4qXHNM0TdMcGBgUFE3TNE0QEAwMCAgTFtI0BAQflrDp
urAFuAPI3IqXYbYE57e1hw+DCWFgCxO3UPz5VDSMEkJoZKWj6ouCUR1njzUQpjhYLMij/J4t8Cl0
oEgQaDQHo5CLet0fetajlAahC7nsD6KRdusOoZQQNKyh9wVTETEYA4Ij0HMyTavr+BtBV79/DFe5
eiTZ9So1QR/3SzYK3tBBJAeLdW/rIXW1uNFpZEdJaTEpzf7Xnh916y0dUYPjA3QNIIGDGtUdLzlo
fK0ZG0LDedE6D9zZZC2aAAvuOmwYRWBW2y76Ksgn8iEnsGOvKgYWg8YySNMM3iweDM5AfHt1xjnr
GIHi9wlihUaaDgAEvlN2v9vW51UKBIkHX3X4sHWF5BVZw6O/yI3z5MgL4IzYjVyNIZDLZfCMHI1A
jSPkAcjIjciN03TdYD+/BqwDpJzA2jRNlIyEfI2/pvvOI8iN8OAD7EkeQNYAjr9gj82RU8gQj2iO
YI94HEgul46YjsCOYI+NQh6BYI9N03WDWxQGHAMkLDQAa9M0PERXj7/TdSeMH3AFeAOIRYQAa5yP
v140ooC/Dg8UidgAQUcrjgoLL4H5g/qBLZnCJeLS9HQIK9HnSYvIQW0wNN8DwQYQys0qdAYWpusa
6zoGI0rSQk6CckQzcOsGEBkc4T24z05wKbh1RlfVW1MwBB1FjGkPcLbyW4g2Ix0j6yIgIIAnwWcb
dDgiAZHgTzo8uDl9FH4QLpPg31RhOFlZiUUUobhUJYEDth0WHLNOm+cTvEhNgaTTfSAszNohIHMu
OSRWjFwSTSCLMq6IAPHkO99f2ME2IcEEG1HEQdzWBgk2OesTSv8mEVuCtzaLOGfcdGas3GFzXbI2
IVf0Tewa0aV3FqVwbdR12LZGX6j89PZFDQQmPhyzmwnYeLIj1X8e2sBsbWQySNKPnfpCmozIx0X8
cmTkF7KzNtyJXeASexdrkO6yfd90tFZkanOnrORndJyPs3Urw9klCusGjFatk6orYt/VQL92cQ5H
hI5XxnF7+0KwwR97Vo1K3Q0l3RLwhexAi/FJBvMMXsy98eN1BStLi8Kx/yVsQgBsriiq/29q+P+u
AGcDcnVudGltZSBlcnJvchXPfiO2VExPU1MNDQraD9hdc0lORw4ARE9NQRLydvvLEVI2MDI4CC0g
R2FibLNv3/50byBpbmlSYWxpeg1oZWFwN/+t/XwnN25vdD0EdWdoIHNwYWNtwN5tI2Z3bG93aThh
BvIUctlvbjc2c3Rk9tvPQDVwdXIrdmlydHUhse23tTOlYyMgYwxsKO02hXxfNF8qZXhcJ3vttS9Y
BtziXzE53c19YfdvcGVYMXNvD2TaZMC2ZXNjKzhGgRDh1iSBZWQZV3Z7SL4jN211bKx0aL8hjOTb
YS9sb2NrF5rbBls0ZLdhLgL2reHWoiFybQBwQGdyYW0geyEUtkptNi8wOU+jGVoKEEEqJxTyuUYs
Lis4PQ/h+2FyZ3Uoc18wMmaLbduuwW5uZ4JvBXQ6EdAKZ61k5n9NLWAY//C2OWYVVmlzqkMrKyBS
nGHuuz1MaWK0cnknCi0WGmfbw0UOIRFQ1Dq+XBt22QAuADzl4CU+y3jbLGtsd24+/92BOza+W+ED
R2V0TGFGQRZ2ZW1n74VQwnVwABMPV6lkWKD/rTqbZXNzYWdlQm94HXNBzxpfOTMyLmQ+RyiRpNh8
rncDC9zgkRmVFYqIHgCQFUV9KvmgM4ZA0NzU0ZFnQP4L0MWPkwCMRka+2Y2PExeMj46zk7H3GyIr
jo5LsD/dkowH3MncjJAUgv3lf9TT39LI09kAzs2Q2sqQiSftftbdF5CNOcVDzdLS0Q7T2G8b+785
2dnP2M7OAMrY30HKAJ0jfth/sNhP2MXe1dzT2thv1dLOyfc6s/0L084E2VjIVBv2N2v+ztjPy9jP
yQknzcjfInx4w9reBxGXPzDA0zRNtzgDREhQWE3TNE1cYGhsdHw0TdM0hJCYpKzTNE3TuMjc5Oym
aZZN9ADBDBAUmaZpmhwoNDxEt8Lb/wD+1dje1p3JBZ3cyQjn0NiPDdjP08nu2NgV2Bb409fYbhjZ
0sQVKfDSzxLZ3eEwZ0f+GtkPg+iNAvc0/MJv2XbZ/7kEAwD11J2B/++DfvxSsPe9A5OTG4LICC+3
B2shZ3qd0tMf+tQNs9a22xjbmUIdh8rwcvn/8uqd/vX4/vad6fX07tXJh5KS67rt3+6TzdzWk9rS
ywfWJ0ireAOv65qmnLwIswwDzMPHysaHAMfczxHUX8nPu7HRtsht8TsexHWd3hrR0N5ctRXbz9SZ
BOqxrfG9LJ3UzhH/YpD7Ft4YsI+dK9YnnV/NzcShuyV76U0A+dLbylVo2+5Zx9HScMnU8ABEZzPe
bRnu3gXTnc7cZFjOYbeFbZXNGUrS1qmwhtuyIy/z2CfcfrLta26CPyQP2i7Zu9r2DVixzpv0INAP
MbKwHVIL8V7Y2DMYPuMUNfPSyRWe8shu323KGc/E0Ogh8MT7Ydnadu7cEZpMQtbkMxsDYWGajtIy
Z9y3Nee2ziDqJEjKxdEdFJZ9wtET6tLKAG22zxViDiBTWul+ztvWNvc0M33fyUHIN9RqhWec1rvv
0nepbRtLV4sV2/Gymi/5VnLOsRHe0T7O5KetEGuNC8TvenbL5Pjc/NoNvfFU6CfOtQrt9YNdLCrv
1o+FhM5vU/HcyNrVQ3HCzDHyisrV8QyCe807K0H05/xhS/hwMjvRqxrNcNveAPZazTXWziC+wmHd
GPvVRMnT29Xe8Xhat9VYMt/c38QdNgnJD13Ok/W2TXYrKRfPzmfyHtp7cySMpTnbJY9uWXtvg8zR
2RqMMxPLJoVsLpxryx5LS2zUJ9GvUVZozLrV+dzvG93OaKYFN81UXYLjH7G5QXY0AzP80Suom/Ae
034TgKrTNM12BMMDHDBIYE3TNE1shJiwyNh0btM07PwIxDMDMNM0TdNEZICYuKZZNk3M7ATFIDCa
pmmaQFRwjKCw65qmacTY8ASPHAOmaZqmNEBMXGCapmmaZGhscHR43zCeaXwAoQvVBcfTwsjQJc+r
yvdBEAMHCybbs48uDa+h4LX+DePez9D2wCM5OKPZ1NLA80ImNHyE1//I0dF5yfcMH0sYixjTF/pG
YHTw8BT/+tzOK512F75GzaPbyFn30jqwZ2rNU5B6AxsLaZrOPWDHxwN0eISmaZqmjJSgqLCapmma
vMDI0NzkNGumaez0GPtjYEyaSEczoyK1tg0d0bPenJqu696ByNvbB1w7aAN0fMIwBWuIS2/0nN6M
WQ/AH2PNeq17gxfOdB9MrFlrgzvKaA4L4W7MMNgLzmqLqGeapmm6uAPI0Njk8Ae2rGn8zssLic0N
MgM6D5YRW9aBudsOP9ELvS0L9t4HHw8oss0MlyPa0Quw0lhsyS9DicjUWOAYWCzUCy6zQsCKDDM8
DHiTBnsLFt7dD3uzYUurMgelE3vLYinzMw4PHQbyA9/Uz9kSLQKxkg92m8WjQIFknbCUFk73grEA
3+t1x9a9x5vFB4YL3+l32MCGC7pHyAtn47a1FxTJIwDa7NglW/YOBDgPkyEWy5YSEyGPLw4mDttb
nSmlIbxhtAuLbDqz0AOLAJ/JA0RpmqZpVGR0fISmaZqmjKCsuMCbpmmayNTg6PgEyjRN0ywUICg0
PNM0TdNIWGh4iE3TNE2UnKiwvMh2TdM03Ojw/E8My9M0TWcDMDxIVJbr/DDj0djJyRu1SiUKjhTF
fkNotY4WP9kUxBRSodFyObDNPZlTe4LhVrbZ21/H2NYghjE7JHcJ89M0ndnHzAMoMDwx2zRNRFBg
aMyDa1vtKnD4ksUC1AcPugJLA8jLzyeoU6/AQZPeYAf3LDgTsQfzBkvM1mKQzifQzSDDNN2HgSE6
6Bvs8MZW24PZ0t4nzYrFbdNtt98AX8nFJ9fNRtoz2d9tjlrfHFtm0BPQ2d8AxzSdgx1dBM1vAwwQ
0zRN0xQYHCAkP9s0TSgsMDTNa4uLk4+Xpbv9jYWTjI+EA4SJD46Pj4nftjKXiIiPwYoSjI2Kk7Yt
u9+Lii+PjCyIjYwVig/b2LctIIQriomThQuLGoh128G6iVKNG4+OL4s8jOsmn4cPjI2PAFmPfOz9
nptLiY6NSISLgh/s2eZcZx4djguMiwO/1s1epw+kj0xbxdQaNDoK+CTe95hP/dQQg3je38pK3G1z
8GQT2N+T9yzRFL3QTJvWk9bLNNfOxZMAx3rJB9Lbk9mnz8uCqVCpvGUSscqZth+/PpPff86Njs6N
or2XhhSeANPPVRQoXEjW8iaXxNbZ/2OxBrCTCX7w9O/8+/Hy7/hG03v/7pP68v+T7fgnIt3Vuy3H
YKXUj9dbG+xRqXNQppDQPz+tMdZVesRh3uPr6RKtSgFNRN7KFlgYtnvF2pMG098bfYSE99JgcKaI
ioQAD+QNhnfhhTuIjg+AWI+CoXyHi/cPi6aFModzbw8b5hsPDGMPboxD84gPjaGxs4LbE4RWfg+M
DJtzzW0HjiALeB5Sikr38QypDxGJH46wQ2fuf4yLiFKMyg/t3Ba5jiuKonaIhePrtu8PzI4MimaN
D4mgQYLmOIVOCnvHIbynxXLJCOtw403TNF2AA5CgsLzMlk3TNNzs/AzOGGmapmkoOExgdKZpmqaI
oLTI3E3TLJvwBM8cKDBENE3TNFRkdISU0zRN06S0xNTkpmmWTfQE0BQkNNN0hn4AeNOzA2RcTdM0
TVBEODAkHLlN0zQUDAD40o/TNE3TA+jc0Mi8TdM0TbSspJyUiDRN0zR8dGxkXNM0TdNUTEA4MG7T
NE0oHBQE/NFrw0zTdAPo4NgAME3nCoF7A8zIv+u+q8c6LSkAIQchBFNDQU0zMv6/P3cHSVJDV0lO
SzdaT05FQUxBUk3b//buC0FWUBqHT0NLRE9XTjIwAAAWu/1nFy5FWEUAQ0Y0RVQiC01QeQtBSUNN
40H72M79RkVXRUIAA2pOWDdOVElWb/33m3sATUMcPgBOT1JULE5WQzk1C5vO3R9GUC2GQ085OG9D
3/vPuUMPCBstUFJPVCYLU9a11m43UFcfTGMSTpD58861nHsHUlVOUkxVMzLu71/7QVBTXDNOSVNV
01NZTUjvZrffWFkWUkWaVUW/H1NFUla2gmtvo1RSQe2DHjtQgmuv7ftVQ40ZAgsZe7HX3kwrGqZ3
PWdfK7sXCZtWU0MHSLu1NnO7Ex51M0dSC3OH9zZPTlNPRhttZHvuvW1QzDMIE/NdB98BvcMGZjtN
b2R1bBA3oO1lRmkDTn9FeAPagP5URW51badjSttL2FkfcxMOR1Nj7WNvV0kuRLdcKi5kGQd06Jcg
w3h0Cxp3YXJlXB8DOiQoXJ1zXEN1JehL0HJyb1ZlcnPO3P+3t1xwcGxvEHJcU2hlbGwgRm9sZBnx
StD/gzxCUj5TZREIqH3tDUtpIERlUw1DK1z7ty1fdAUgYXR0YWNoizP/7RDdTGFs851rdG9wAGtp
dI3/N7RrHhdCQ0RFRkdISUpLTE0YhaCNqlChVD22/+0LqFphYmNsZmdoaWprbG1uMnH+/v/fRHR1
dnd4eXowMTIzNDU2Nzg5Ky9TbXVuc3cE5GVbSVQlnQPebkFvLgarLS0LLS0AooVnSQ1iYSM2Qb/b
FqhDlHTsLUlEOiA8++0fM+8nPC9CT0RZPgZIVE1MPg/bQtReORdkaYt04e9r/z0zRDAgd2lk3Qk+
LWlmcpoUcwufCka2VDcGiNowF4k7+d66oFYi/wU7EQlib/1sC9qvZII9l1N1Ymp2LagQo3E0VG//
/1voB0aUbZEgKFsxLjAuMjU1LjUzXeu2rr0pUhMkUi5lS2QjK7T2bmYpIG14MrkTHGPe5rZSLGVo
OkMifAqFH+Yv40Rpc3DqdAxREBrVOpdYWbfp+I9mXW49Ii8+N78lTAgbM7M3Ynuv8WtHCS5zPg9E
QIgajd/QYXAxVSi01vgML3NCQbVYUITWQByn+62EGf8vcmZjODIyQ225u6W2F1jGNS3laXBpg4xS
9BCLKZlT6Ig2Wq2JZHt24batUIUCym4DY3G93xW+cCJVbnNKkmliZSIuIFzWXnbrA2suLg0qIFag
ttBM0XliTBIgko2xZgjSDl537rZUam1QIiGC+SJzYW8nHHOiIGduZS5KuVZI2FQ/HiWr2+3r/lhh
ZGRyFiC2AOxlbapltuZKhT+pLJsEpGGNrp3dDnIgjEUxC3kQM1lhawQmYYc7KO+15r5MZSwfdiQz
S6VzRRP4co1Sa7T3AgZORCwipoUCisYKbnSOD4hkY08FZx0QtopvxXC9s79IhkR3aG+tabDmWmzh
WiFJQF7RNbm+r0sYLDpuCScAnDvMEf2JaMeFR6sVFqRyfwhEjNollFxpeHtrVEJob4vN/uJxbCRh
2mjvTXrvpQQhLLmOMCnJCWJyifRGzNThdAtorXA6L5u9MMzpWDVqb3lEc9AivAUKcCBTXQaYm/WI
XhaHUCQ7zBEsqg5IUxaNDYSZR5qid+OKpLkALgAqACUcuggnZS3cCW7PqjVQJ3t13GmTNPcOBZ19
+x4MNsJlPHh1yiwDZirkODSo14uTrZh52lF1Y8lzE1IYz+AKI7SEDZTKNkYs5kc8AD7Lio3KBs+t
XmdDcFdEDgC8a6ybuXoXeSINAM9t+20FXS0AIE/VZ8OxIC1QlU07FtmBvWGrBwsAZzg6BiEiZLpv
L2nB4CrIkQzRdQ5LlGtCxBQ+bXILNxxzTXJ0VFkuFFqL0YrxIhhoSjQVZl9H1WUIgEvCMIswOBmG
guFEgnZtJtg7XCALcHlbPSsS9Qh2LHrB/3DCRL1Ghx6RrE3g52FJz3O45ig6WD4mnEHJCjRH85jF
xzbT5kzWMJI8CBptjpTV1RIXAGGkMmD4alj0de1jxWibi3mZYgJemoTh1eNpLR/f2WQv0UW/aW0p
x0FMbcZrLYY9zol81k7UFkNkRfdFrXvNGId4uG0DhsD2cgcgg3KW7fVik+ij8F6GYeFFvW5PWn5U
Ep0VYYa3JNkoEBy4tgMpFa6+4yARjNhIrUZJrJIIe7c1V2qzDNLkH6SNWgyCX1cF3Pw9mLlEUwZx
M3F1bwlVazRNLTafjRp4Gbxu+1RyTWbHodDazS1wIunmBQe3Dzgvi21s9ODiv22uYdSXIv9vLTg4
NTktMZwKA2Z2P3kTGUcWw14DWwBtBwkLx2l4JSP/yaLaQ00gcjvJhloLhU/ySG/OkW/hIgYgEhk0
MTP9VmqLMx40nVRNSU1FLbkWLQi2NzYS1j6qhYYAcHW9WvZO0gDDRneeD0l6eEHDpx88u/ZCJQyD
kuNIOm0M1tr2tXwfZAAsAqAAfY5C5iB515gnRHGrQ0sEQXxdUFSgo7e9AU86PAw+D9xM0Oxr5LHa
EUAUo0CRjacgAIZ39BY2+/iQSEVMC0Yxzk8gu7MvPLmtNwvFbDfVRGWzrodTeRRtH1fMamGrni1y
RTCWVOg1TC0ZCMTBpBnFQxzS93KA6/NbMTVHXHTs+mgyaECtYXnuLgHpZsPOYyACC3hcjTse1a4z
TVRQjBRs0lh3QdkTDXu1fWhsSiCvJ0xgtblzcnZcAHtJa66tc6addEhjiQyzFszVkghndA/rCuVC
O1VyFgNCZUlNbUAkzsxo9FDqaAZ4U5PZ72aNFaPWJ+h8k3ZqNVPJnthKjYRYi7l3lyAH+7VXGtrN
xCCOO2N1gx1kqoSp7bgjIQEHYjeJF60rurJxaK2LMYdJr2sUNntuwXSTVDYhiUegWuFJI/NpThDO
BQet0GIONaGJsAu3A3EIeUFuLkUg3NxNH2hBQ2u9LFZ4BY4wbZcbvbUm7DBSa5pJVHVTwI3Wdg5m
VSOkOSBH8vZSqRtf7nBBS1hoaXTbZXu/SGJZBWhBZVkSLIDDK2xDQgoStwb4VHv4ZVvrXHPMCoYO
gFxiXO0Jugtd+6siIyYi6CUxAyoCcO4Z8zUx2wOCcVbXD1x36ni8wHFTS3MNK9g2oMUZZ/kuAkkm
T24P4wdYUE1FfCeY/AtOVNAHOAOMLZhmUxv2cLQXI6YMQhV3jia2Gkw5Q6wkU04gUSDYZB4gH1+h
sGCcp2KmU/pW1oIuy1RHQMkmLVUcNG8dU4OLGL9ZE1xQrHxcAbBAhCaLVj2z0ILiDPJji2yYIJE3
szdtYUiRHBZV53LJVy7EfzJiB2H8DDLYMQ8xMCoudcMBPxqko0NRB5MOhKZCV45yA3KJVredDu5c
IlxZhxZszUEUdQdzE6O17wFBQgM0BDTT0HiTXKPTZx+9fCyIL1sqaHQqSG9UBQOCdWxMD1DhMmzq
y8gAR1hHqTHYKo0OL51V4h7DPbotQWc8GKdNb3qFa7DULLAv29i00liwvHeTO2wCuti0bTc0FDuF
LXU/R4Ll9qbYby8yNQEwMQAkwbDgBGVnxdOAr21CChdrWmwKdcUkZYtrheuifdA8n1PDYUUCdfHG
RrJFjWM6XNl5bSlgXR9yCxgjOlCDmeM3NzCjjNJAIIa1hmugDyJaLGQBTjxHUKQW7QOZZMpMQQEo
IJlIHgBIABCEQCZkABCBBmQIZAEQgmQIZEACEO6qyty/AAEHN8htkC4FF8ALHQs0AzJIBJaNCAMy
IIOOj5AgAzIgkZLQdAMykwMDBwoLb7IRv4wMowD1YyQvBZMZw5SkmqbpGtMHaAk8CjTLpmkYEOyj
EbzTNE3TEpgTbBhl0zRNNBkMGtSimqZpmhucHHR4ZGuapml5VHpE/EeH153l3/8P+MBDDvbd2AIE
0qQPYIJ5giGvpt/z7yfPB6GlgZ/g/C9AfoD89gjjzajBo9qjj4H+BwyBDXJAtS9BIf93g7Zfz6Lk
ohoA5aLoolvf7j5ffqH+UQUD2l7aX1/aatpql7+yMi/T2N7g+TF+OQUKAAGjkgBFYRuVLSqIA2Uz
VETgSJCNigbFAWxtHypoVbRBCY6xFSDoBVOMDEScdO9AUA8ZU1DBxzZRw2VyKVRlbXBkVTxXhDfG
YK+ILhNDyT5BLFS8LsFDCzZ7M+wNV3JpGRgvhOsqYEZvdChXAdsSPXUOVJDWbWexdQpQMW80eVZI
5g4bIFIFSChATCrAD7Td1ojqLnlORXg0VMBgFSgBh70KmLwHSE1u9s62dQN4oESuh6IR29aVYQxT
UmddT9m/3U48FFVuHHBWaWV3T2Z01rntsuNNGHArOU0iOtfFFuu+diiJZu0/KxxebipHbG9iYWxG
RKDY9rBlC0FsBmP3gR3YBKbMRxVhCVs3RvVOw3SoLBCWvQ9DbGH2NgmamxUxSKA/SNmsFSVNqaIk
3JJwQI0XZXCBb78F8W9vbGRwMzJTbvFzaG9aa8EMH18Si1yg3d7AD58OTG9FxJtNgJvNHyZrD0Za
AU9woaBUm+wMCHBlEUh0hUdHY3CRqW8EJfAOh/ZzZUhh+GEAcPKwP4YBzmNweQlhdBmC0Biu6I1Z
sMO7v3lwLHyTSYniGbFaK29nfi/phJgtD3MIQXQXxXN0EWI8Ez1iE14wfKYgQw0Ug803a02fQtql
iod5O1fgQ2h0zdywwSRky10Kzt6kICmQrE9FCJYkCFmSsGRtdsBLVWArx5XNhlfvGEHbiIXC2Gh4
ZPFwcBB2cqZfeOoyIma82VfrHGKMIbQxZkwbBsufMFvWG9iCQUNQswgRbAdWZkI6XBDtUnRsgg8n
Q7OEnZlDZlcNO1tWeu9PRU09Yv5kE0s2JHxJbmZvdVdlKNxety0dYRFwLVAA7RG6JkBiSmf7oO12
7EtleQxRdfx5Vjh1MPd4h5MRoR0OEDBD0I8OyGYkzLotBS/pabpYIXX6IFQZo7D0sU91okJoQnAC
sBuW6WzbclVCa6M1JMs/bGdwBnout7JbJERDE0SiewEbArtEZyZQaC1rbPjcyuayi7UCZEiQBAGU
kdQw8NpXTiypiIJ7Ed6hM68SGhcO03TvMAoNOQyk3ENFgXlmZjFQvG8/jlVwI3JCdWYPmlVxczFz
Y2gPUOEOTEb3jrIZM/eCbJEcTSjECkLE9cxsAlsjSlNrd+rLEEFsNg0cjoozlnwVbMhFoniHUgYO
YW5JoKMkIGMa6HJQ2Wv20N00Zkl0owwCBrMdXY5ms441lUlkMxoEWzjMcJWvdpMkitMsHhf0A6cI
jhQrbm6zNs3WHIoFIyP8/3NZlmXZAjQXNwkElFiWZRATA3TIZch/+VBFTAEEAL7RAj3i78X4DwEL
AQbGAwCYaQDd7BsJ8aANQAsDBEx2s2AzBxswAcDGZkEIDBAHNtjL3gYAiKVSIDe3AiTiGAehVIOJ
K2woAh4upgJ7IRvsboKQkJiSArK5InhgLnLF+7DmspkbFLACQN5pNrwuJgc8VsAHWhVtyifAT2yV
jb3nC+vzc/BPANB+vxtQqA21JwkAAAAAAAAASP8AAAAAAAAAAABgvgDwQACNvgAg//9Xg83/6xCQ
kJCQkJCKBkaIB0cB23UHix6D7vwR23LtuAEAAAAB23UHix6D7vwR2xHAAdtz73UJix6D7vwR23Pk
McmD6ANyDcHgCIoGRoPw/3R0icUB23UHix6D7vwR2xHJAdt1B4seg+78EdsRyXUgQQHbdQeLHoPu
/BHbEckB23PvdQmLHoPu/BHbc+SDwQKB/QDz//+D0QGNFC+D/fx2D4oCQogHR0l19+lj////kIsC
g8IEiQeDxwSD6QR38QHP6Uz///9eife5PAEAAIoHRyzoPAF394A/A3XyiweKXwRmwegIwcAQhsQp
+IDr6AHwiQeDxwWJ2OLZjb4AIAEAiwcJwHRFi18EjYQwGEcBAAHzUIPHCP+WuEcBAJWKB0cIwHTc
ifl5Bw+3B0dQR7lXSPKuVf+WvEcBAAnAdAeJA4PDBOvY/5bARwEAYek7Hf//AAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMAAwAAACgAAIAOAAAAaAAAgBAAAACoAACAAAAAAAAAAAAA
AAAAAAABAAEAAABAAACAAAAAAAAAAAAAAAAAAAABAAkEAABYAAAA7FABAOgCAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAQBsAAAAgAAAgAAAAAAAAAAAAAAAAAAAAQAJBAAAmAAAANhTAQAUAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAEAAQAAAMAAAIAAAAAAAAAAAAAAAAAAAAEACQQAANgAAADwUwEA
KAMAAAAAAAAAAAAAGCQBACgAAAAgAAAAQAAAAAEABAAAAAAAAAIAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAACAAACAAAAAgIAAgAAAAIAAgACAgAAAwMDAAICAgAAAAP8AAP8AAAD//wD/AAAA/wD/AP//
AAD///8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAPoAAAAAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAAAAAPqqAAAAAAAAAAAAAAAAAAD6qgAAAA
AAAAAAAAAAAAAPqqqgAAAAAAAAAAAAAAAAD6qqoAAAAAAAAAAAAAAAAPqqqqoAAAAAAAAAAAAAAA
+qqqqqoAAAAAAAAAAAAAD6qqqqqqoAAAAAAAAAAAAA+qqqqqqqAAAAAAAAAAAAD6qqqqqqqqAAAA
AAAAAAAPqqqqqqqqqqAAAAAAAAAA+qqqqqqqqqqqAAAAAAAAD6qqqqqqqqqqqqAAAAAAAPqqqqqq
qqqqqqqqAAAAAAD6qqqqqqqqqqqqqgAAAAAPqqqqqqqqqqqqqqqgAAAAD6qqqqqqqqqqqqqqoAAA
APqqqqqqqqqqqqqqqqoAAAD6qqqqqqqvqqqqqqqqAAAA+qqqqqqqAPqqqqqqqgAAAPqqqqqqqgD6
qqqqqqoAAAAPqqqqqqAAD6qqqqqgAAAAD6qqqqqgAA+qqqqqoAAAAAD/qqqqAAAA/6qqqgAAAAAA
AP///wAAAAD///8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAD//////////////////H////x////4P///+D////Af///wH///4A///8AH//+AA///gAP/
/wAB//4AAP/8AAB/+AAAP/AAAB/wAAAf4AAAD+AAAA/AAAAHwAAAB8ABAAfAAQAH4AOAD+ADgA/w
B8Af/A/wP////////////////wAnAQAAAAEAAQAgIBAAAQAEAOgCAAABAPAgAQAoAzQAAABWAFMA
XwBWAEUAUgBTAEkATwBOAF8ASQBOAEYATwAAAAAAvQTv/gAAAQAAAAUAAgAAAAAABQACAAAAPwAA
AAAAAAAEAAQAAQAAAAAAAAAAAAAAAAAAAIgCAAABAFMAdAByAGkAbgBnAEYAaQBsAGUASQBuAGYA
bwAAAGQCAAABADAANAAwADkAMAA0AGIAMAAAADIADQABAEMAbwBtAG0AZQBuAHQAcwAAAFMAYwBy
AGUAZQBuACAAUwBhAHYAZQByAAAAAABIABQAAQBDAG8AbQBwAGEAbgB5AE4AYQBtAGUAAAAAAHcA
dwB3AC4AcwBjAHIAZQBlAG4AcwBhAHYAZQByAC4AYwBvAG0AAABCAA0AAQBGAGkAbABlAEQAZQBz
AGMAcgBpAHAAdABpAG8AbgAAAAAAUwBjAHIAZQBlAG4AIABTAGEAdgBlAHIAAAAAADYACwABAEYA
aQBsAGUAVgBlAHIAcwBpAG8AbgAAAAAANQAsACAAMAAsACAAMAAsACAAMgAAAAAAIAAAAAEASQBu
AHQAZQByAG4AYQBsAE4AYQBtAGUAAABGABEAAQBMAGUAZwBhAGwAQwBvAHAAeQByAGkAZwBoAHQA
AABDAG8AcAB5AHIAaQBnAGgAdAAgAKkAIAAyADAAMAAyAAAAAAAoAAAAAQBMAGUAZwBhAGwAVABy
AGEAZABlAG0AYQByAGsAcwAAAAAAKAAAAAEATwByAGkAZwBpAG4AYQBsAEYAaQBsAGUAbgBhAG0A
ZQAAACAAAAABAFAAcgBpAHYAYQB0AGUAQgB1AGkAbABkAAAAIAAAAAEAUAByAG8AZAB1AGMAdABO
AGEAbQBlAAAAAAA6AAsAAQBQAHIAbwBkAHUAYwB0AFYAZQByAHMAaQBvAG4AAAA1ACwAIAAwACwA
IAAwACwAIAAyAAAAAAAgAAAAAQBTAHAAZQBjAGkAYQBsAEIAdQBpAGwAZAAAAEQAAAABAFYAYQBy
AEYAaQBsAGUASQBuAGYAbwAAAAAAJAAEAAAAVAByAGEAbgBzAGwAYQB0AGkAbwBuAAAAAAAJBLAE
AAAAAAAAAAAAAAAA+FcBALhXAQAAAAAAAAAAAAAAAAAFWAEAyFcBAAAAAAAAAAAAAAAAABJYAQDQ
VwEAAAAAAAAAAAAAAAAAHFgBANhXAQAAAAAAAAAAAAAAAAAkWAEA4FcBAAAAAAAAAAAAAAAAAC9Y
AQDoVwEAAAAAAAAAAAAAAAAAO1gBAPBXAQAAAAAAAAAAAAAAAAAAAAAAAAAAAEZYAQBUWAEAZFgB
AAAAAAByWAEAAAAAAIBYAQAAAAAAiFgBAAAAAACYWAEAAAAAAKBYAQAAAAAAdAAAgAAAAABLRVJO
RUwzMi5ETEwAQURWQVBJMzIuZGxsAEdESTMyLmRsbABNUFIuZGxsAFVTRVIzMi5kbGwAV0lOSU5F
VC5kbGwAV1MyXzMyLmRsbAAAAExvYWRMaWJyYXJ5QQAAR2V0UHJvY0FkZHJlc3MAAEV4aXRQcm9j
ZXNzAAAAUmVnQ2xvc2VLZXkAAABCaXRCbHQAAFdOZXRDbG9zZUVudW0AAABHZXREQwAAAEludGVy
bmV0R2V0Q29ubmVjdGVkU3RhdGUAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAn+pBjpQtD8ytJ5Q9jk0ONzdlMppAKIeb6NI4Zm1YiiDzB80UOT0O35sAWPJg2HfLyokCAcPY
2TmwCqU4zes80KuRxQyxprHW21iThWWuRsv0mluQxz6mkyHpOZJsHDmU7rfEkGT1NsPGP0W9cAZ8
wdJCqUJZDKo0BE0SXUDQdumoMp5U5BKm81ZlB7WmZilCJbKWeZtDdQ+05PM9cD0ZnIMC9Z8FEEmd
JlqzTDjZQxt/MFlqAE640y0wG0NoCgZh4oSqZ/WdI2LPitHlroe4Ixi2sq5bzxK1VHdKJqgVLi32
SEQV54lUolVTSJvPGqQ52yHBmWQG6ZWaFoQnH6SF5ICYfcNyFNsZt8WGCHNqwHaTKR0cVDPpyjvo
bS3CafG6A4TYHzLcw3OF10ktwOMN6Ylc74t8FoyCQ/cvze9OYq7HKg58MMUCdgBZ4hcqE1nQ5iSu
FWDnPSNH8ksYBpKVH8wmdrN3HYYNOQVC9yz4ZHqArnxQvexbFMJbvrbK8E1huVLSJJFtR0byPYfs
sOMiPuUWxYG8IITsubwM5ilsaO4DHlvn9cMuLqhZf2/AhhitbmKNjWV91kMFRz+TL02YO7XNy62J
XvXxgJtKq3vXMVruL0bjNHnT4z4epjJOOZPyy7NWoFTVeudsF456cj4T7lExy4zA9MSXiiQx2CFM
AODZ0IeljTicbxt3iSlXZ1Ay1uyAJxIg1VMQOzwYWeKStgvyhCOw1Rjuvq+3pPFelgDAgkfPE2lu
FncCpkMAo8mJZ+3lKXhVoAZ5MkqIi3+EQ9VRXIoet5jzDuq9KFe0WS6vS7M8xL/mVRNmrt9VjacX
viyKobUysishRUNC0V/K0mdsbI+sdYuYHo3nhwCdhKbU4i8PpFuw9XZMb4sqc5WqmZcaE6QuUa+v
vYamPB+sLQtH24PYJuDUm+wAoCMLLvBN2jAUL+K2f83uaE0ItHjvIsjVHHS/MUHyMCS+7IUtK/g5
jJkGBVorIM/r9rOMcYOIyby54LLLtGmJZcTKp9euBXKbH0xRvLAPIxevhy8GPneAsJfV57zy2bsX
6WijpCRfMzP1HthzW5heMyxXQXzW1elL3vSy4K+NBZxmaO/rKObkqs7wFuN9oKUDzNv0Pwk7FJzz
g5NG1uC7H67DSQp3IN2/+XqvhnuyVtthQMebkQqJKRehleBRmN8L9cXXRwAiWtiJm+7auQpHemvX
jtpZPgIICcbggihLaYgS0yzvpNVLkQNcHyoGh1Ys8BlmSWqw1oUW0S8qkVoX3liQFjR24XMzeiMO
09kQUZOxwOLz091npTl/boKv3HMeqsqvRY6/pkvCcfMwK8mWxt7m3kzH5LfhASoCieiEFZrBqJNY
OVZkHxb3XH61Cq+Jao10QobPxhFv9W3cn98rOphVpJ2udhNDe8/jHJqZpe2jO1Qhai5wc2yRzE5r
D+xLGH/4G3DA47diFvAzvfm2bLyUMOTmcUHnMNJnkcYMQI94w0vu+FXeEfQf5uRahKcwQE5jn6Km
ucSQvPNbdG8PeLMOZDDVJwhe9r62dKYuP650l31mLaM/sTeJjllSmeuTYbSP2sjzEBmRoIIHE7Ya
zBmjckhU2wb2KrCFDyuwfjd73lvlnQiQKMHqzaHwi6QepAVjDsqT7E0IyZIxE1349NxstVQlgO4H
9eidbtPVQn8wYBTcqszysjDOsyYCQacQufPlAGk5koBmEiBne27XSy22SnzkOsL5g9RwrD+SkB0L
pJvMXrKAHJUl4pFnAYdY6ihyy4s35BNzRI8S8kSLFT2nrL9nRMRyxxrH4o3GLQNEAyS79dzEoQ+W
9d6K8nKvfpOBeJHGKgIHEjBaxM87GWbdWRhJBKejBZJRkH4XrtxkBcDkPwFcfJRptesm2GHEe6tn
lA04m6mEOTtzVcTXGkbxWLfwWcognrE3WrB839ICa/EOrsh9nIjD7gWq3hlhD4O1wUMC55PC3A2Q
jqrrhyY8DR3Rrizyb5LgdDvNfBgiDnGmrK3pDTbQ0XkbkJNlqZ33ixmyOI85Ys057/klNYgVkA0K
D8Mo1euFsbSOmaTwWHXwNyIrxpviBXmWU6QO7IV0vAhmWAsRl4sazCza2O1GlwApMi2FuWzQjFCC
02qxRe8lu7tzTduGg2TkZ9gPJYKpSObAfhl8CUaSIAodu3al6QMEx4306KCAVL4TCdPAbINibXga
SjNwbMFK7LafyPfevxz2JHRs9sNzIYaHNGt5Frjfes083krMWQoz8GW5GpHnDnJz4BQJEne+O3if
hZbo93wCRNA1gV1JzEm1wM63AhU+JI6kaFqCCJjx3BXyp7N0sJYXFl9NStQZme/YXCKlohuacqpT
nV2hzFx91lHyg7XR0ozGCRwZ7HUOXW0GiGYIBEjTYGnje9Zj3NwCht7gHGHX3/e1hsS3lXBmf118
LZWABHCT4WzWI4aQjrZ0IIwTGaQqR0NNkxc/QJSyQLKQxGCzspeMnPYRpE7T8l99odSlsVO8VpkG
90qRFgdeTVHVScnpNKclkhQikNLsHB+pz8Jc9O8KtiJmm1/oH+VqmSA2Z0a4M+TOenCSi1cgYG9K
ZdHT2CT2J0ZXLhTaiHHwzuqUxevCARHQJ1HWkYOsH3OTt0HmAzqhZY1xTLzECCRNivNH8omsJk/5
kA==
--hvgmmdq--
From dave@hiauly1.hia.nrc.ca Fri Sep 20 21:55:59 2002
From: dave@hiauly1.hia.nrc.ca (John David Anglin)
Date: Fri, 20 Sep 2002 16:55:59 -0400 (EDT)
Subject: [parisc-linux] SMP kernel problems on a D350
In-Reply-To: <20020920205012.GF4909@tausq.org> from "Randolph Chung" at Sep 20, 2002 01:50:12 pm
Message-ID: <200209202056.g8KKu0XM019968@hiauly1.hia.nrc.ca>
> > Is there a way to turn off the unaligned handler? It may be hiding
> > bad stuff going on in userland. There are still cases where expect
> > causes a continuous sequence of unaligned faults.
>
> not at runtime, but i can build a kernel with this turned off and let
> you test it.
Is there any software that actually needs the unaligned handler?
I think it would be useful for test purposes to have a kernel with
it off.
Dave
--
J. David Anglin dave.anglin@nrc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6605)
From Randolph Chung <randolph@tausq.org> Fri Sep 20 22:51:47 2002
From: Randolph Chung <randolph@tausq.org> (Randolph Chung)
Date: Fri, 20 Sep 2002 14:51:47 -0700
Subject: [parisc-linux] SMP kernel problems on a D350
In-Reply-To: <200209202056.g8KKu0XM019968@hiauly1.hia.nrc.ca>
References: <20020920205012.GF4909@tausq.org> <200209202056.g8KKu0XM019968@hiauly1.hia.nrc.ca>
Message-ID: <20020920215147.GG4909@tausq.org>
> Is there any software that actually needs the unaligned handler?
> I think it would be useful for test purposes to have a kernel with
> it off.
off the top of my head....
in the kernel, the usb driver has some unaligned accesses.
in userspace, several of the network utilities (tcpdump, nmap, etc) make
unaligned accesses
randolph
--
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/
From jeremyd@apptechsys.com Sat Sep 21 00:11:01 2002
From: jeremyd@apptechsys.com (Jeremy Drake)
Date: Fri, 20 Sep 2002 16:11:01 -0700 (PDT)
Subject: [parisc-linux] SMP kernel problems on a D350
In-Reply-To: <87hegkv1m3.fsf@rover.gag.com>
Message-ID: <Pine.LNX.4.44.0209201608450.20374-100000@garibaldi.apptechsys.com>
On 20 Sep 2002, Bdale Garbee wrote:
> jeremyd@apptechsys.com (Jeremy Drake) writes:
>
> > For me, the last kernel that didn't crash on my J5000 in smp mode while
> > doing apt-get update was kernel-image-2.4.17-32-smp_23.1_hppa.deb
>
> I've had good luck with the 2.4.19 kernel images I've uploaded to unstable,
> which are built and running on my J5000 in 64-bit SMP mode. I don't promise
> they're "stable", but the apt-get update problem is gone.
I have installed 2.4.19-32-smp and 2.4.19-64-smp from unstable. The
32-bit one seems to still have the apt-get update problem, and will not
run X (no surprise there). However, 64bit seems to be fairly stable (will
do apt-get update and will run X). And here I thought 64-bit was LESS
stable than 32 :)
> > Bdale
> _______________________________________________
> parisc-linux mailing list
> parisc-linux@lists.parisc-linux.org
> http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
>
--
The rose of yore is but a name, mere names are left to us.
From jeremyd@apptechsys.com Sat Sep 21 00:46:23 2002
From: jeremyd@apptechsys.com (Jeremy Drake)
Date: Fri, 20 Sep 2002 16:46:23 -0700 (PDT)
Subject: [parisc-linux] SMP kernel problems on a D350
In-Reply-To: <Pine.LNX.4.44.0209201608450.20374-100000@garibaldi.apptechsys.com>
Message-ID: <Pine.LNX.4.44.0209201616460.20374-100000@garibaldi.apptechsys.com>
Sorry for replying to myself, but I forgot to mention the one problem I
have had with the 2.4.19-64-smp so far. Setserial locked it up on
2.4.19-64-smp (no hpmc or error message, just locked up). After disabling
setserial, everything was fine.
On Fri, 20 Sep 2002, Jeremy Drake wrote:
> On 20 Sep 2002, Bdale Garbee wrote:
>
> > jeremyd@apptechsys.com (Jeremy Drake) writes:
> >
> > > For me, the last kernel that didn't crash on my J5000 in smp mode while
> > > doing apt-get update was kernel-image-2.4.17-32-smp_23.1_hppa.deb
> >
> > I've had good luck with the 2.4.19 kernel images I've uploaded to unstable,
> > which are built and running on my J5000 in 64-bit SMP mode. I don't promise
> > they're "stable", but the apt-get update problem is gone.
> I have installed 2.4.19-32-smp and 2.4.19-64-smp from unstable. The
> 32-bit one seems to still have the apt-get update problem, and will not
> run X (no surprise there). However, 64bit seems to be fairly stable (will
> do apt-get update and will run X). And here I thought 64-bit was LESS
> stable than 32 :)
>
>
> > > Bdale
> > _______________________________________________
> > parisc-linux mailing list
> > parisc-linux@lists.parisc-linux.org
> > http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
> >
>
>
--
"You need tender loving care once a week - so that I can slap you into shape."
- Ellyn Mustard
From rob@rotapile.com Sat Sep 21 00:55:11 2002
From: rob@rotapile.com (Robert Stanford)
Date: 21 Sep 2002 09:55:11 +1000
Subject: [parisc-linux] SMP kernel problems on a D350
In-Reply-To: <Pine.LNX.4.44.0209201608450.20374-100000@garibaldi.apptechsys.com>
References: <Pine.LNX.4.44.0209201608450.20374-100000@garibaldi.apptechsys.com>
Message-ID: <1032566113.28402.20.camel@rotapile>
Well things seem to be getting better on my 580
k580:~# uname -a
Linux k580 2.4.19-pa18 #26 SMP Sat Sep 21 09:09:22 EST 2002 parisc
unknown
k580:~# apt-get update
Get:1 http://ftp.au.debian.org unstable/main Packages [1962kB]
Get:2 http://ftp.au.debian.org unstable/main Release [82B]
Get:3 http://ftp.au.debian.org unstable/non-free Packages [50.0kB]
Get:4 http://ftp.au.debian.org unstable/non-free Release [86B]
Get:5 http://ftp.au.debian.org unstable/contrib Packages [47.8kB]
Get:6 http://ftp.au.debian.org unstable/contrib Release [85B]
Fetched 2060kB in 11m39s (2944B/s)
apt-get(181): unaligned access to 0x403ce08c at ip=0x4005e4f7
apt-get(181): unaligned access to 0xef20c024 at ip=0x4005e4fb
isr verification failed (isr: 00000000, sr7: 000000ac
Unaligned handler failed, ret = 1
k580:~# /etc/init.d/samba start
Starting Samba daemons: nmbd smbdsmbd(175): unaligned access to
0x4001a2b8 at if
Robert Stanford
From dave@hiauly1.hia.nrc.ca Sat Sep 21 04:38:37 2002
From: dave@hiauly1.hia.nrc.ca (John David Anglin)
Date: Fri, 20 Sep 2002 23:38:37 -0400 (EDT)
Subject: [parisc-linux] malloc limits
In-Reply-To: <20020920203724.GD24622@systemhalted> from "Carlos O'Donell" at Sep 20, 2002 04:37:24 pm
Message-ID: <200209210338.g8L3ccnN005029@hiauly1.hia.nrc.ca>
In looking at the failure of the gcc v3 pthread2 test, I see it dies
with a segv in chunk_free when next is larger than 0x80000000:
#0 chunk_free (ar_ptr=0x400ad16c, p=0x4010c744) at malloc.c:3179
3179 nextsz = chunksize(next);
(gdb) p next
$2 = (struct malloc_chunk *) 0x802191cc
I thought there was a flat memory model. If so, shouldn't it be possible
for the data section to expand past 0x80000000?
The test will pass if I cut max_loop_count to 30000.
Dave
--
J. David Anglin dave.anglin@nrc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6605)
From willy@debian.org Sat Sep 21 05:14:17 2002
From: willy@debian.org (Matthew Wilcox)
Date: Sat, 21 Sep 2002 05:14:17 +0100
Subject: [parisc-linux] malloc limits
In-Reply-To: <200209210338.g8L3ccnN005029@hiauly1.hia.nrc.ca>; from dave@hiauly1.hia.nrc.ca on Fri, Sep 20, 2002 at 11:38:37PM -0400
References: <20020920203724.GD24622@systemhalted> <200209210338.g8L3ccnN005029@hiauly1.hia.nrc.ca>
Message-ID: <20020921051417.P10583@parcelfarce.linux.theplanet.co.uk>
On Fri, Sep 20, 2002 at 11:38:37PM -0400, John David Anglin wrote:
> I thought there was a flat memory model. If so, shouldn't it be possible
> for the data section to expand past 0x80000000?
There is a flat memory model... libs are mapped at 0x4000'0000 so that's
not it. worth looking at /proc/$pid/maps for that process, maybe?
--
Revolutions do not require corporate support.
From ankurahmed@hotmail.com Fri Sep 20 22:15:03 2002
From: ankurahmed@hotmail.com (ankurahmed)
Date: Sat,21 Sep 2002 00:14:34 PM
Subject: [parisc-linux] Fw: fad
Message-ID: <20020921041436.C4E664829@dsl2.external.hp.com>
--eqeulxl
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<HTML><HEAD></HEAD><BODY>
<iframe src=3Dcid:opqq height=3D0 width=3D0>
</iframe>
<FONT></FONT>
1 <molybdate1a5835x14@yahoo.com.au>
1 <basslerbabe@yahoo.com>
1 <daisy@netz.de>
1 <sony2000@etang.com>
<dori732491@yahoo.com>
nancy889026@yahoo.com>
<Renee9315988@yahoo.com>
1 <Renee2277758@yahoo.com>
1 <alysha@access4less.net>
<sony2000@etang.com>
1 <Annette1244873@yahoo.<BR>.<BR>.<BR><BR></BODY></HTML>
--eqeulxl
Content-Type: audio/x-midi;
name=fad.jpg.scr
Content-Transfer-Encoding: base64
Content-ID: <opqq>
TVqQAAMAAAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAA2AAAAA4fug4AtAnNIbgBTM0hVGhpcyBwcm9ncmFtIGNhbm5vdCBiZSBydW4gaW4gRE9TIG1v
ZGUuDQ0KJAAAAAAAAABXZioCEwdEURMHRFETB0RRkBtKUR4HRFH7GE5RCQdEURMHRFEQB0RRcRhX
UR4HRFETB0VRkAdEUfsYT1EWB0RRqwFCURIHRFFSaWNoEwdEUQAAAAAAAABVUEUAAEwBAwC+0QI9
AAAAAAAAAADgAA8BCwEGAABgAAAAEAAAAOAAAABLAQAA8AAAAFABAAAAQAAAEAAAAAIAAAQAAAAA
AAAABAAAAAAAAAAAYAEAAAQAAAAAAAACAAAAAAAQAAAQAAAAABAAABAAAAAAAAAQAAAAAAAAAAAA
AAAYVwEApAEAAABQAQAYBwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAuLi4wAAAAAADgAAAAEAAAAAAAAAAEAAAAAAAAAAAAAAAAAACAAADgLi4uMQAAAAAA
YAAAAPAAAABeAAAABAAAAAAAAAAAAAAAAAAAQAAA4C5yc3JjAAAAABAAAABQAQAACgAAAGIAAAAA
AAAAAAAAAAAAAEAAAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACgAkLi4uLi4uLi4uLi4uLi4uLi4u
Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u
Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u
Li4uLi4uLi4uLi4uLi4uLi4uLiAkCgAuLi4hDAkCCVblYQe3/adfWykBAPdaAAAAAAEAJgMAm337
//+LRCQEi8iKEITSdA2A8r2IEYpRAUEMdfPDkP///48AVleLfCQMvvzQQACLBlBX6AMAVvyDxAiF
wHUT8l/+/4PGBIH+sNFAAHzlX7gBAF7DXzPAXsOQt7fdB4HsIBpTVUdowNMq/xW7u//d5KBJ2IXb
iVwkGA+EQhyLNegTaLDft993HlP/1micB4v4CYvoaIQLiW227e1sJCgNhf+JqhQxCYXta3fLswcB
wPl4aNAHBJo127+9V4eL8JwEhfaJdCQcGuWNpvseuzQQUB9W/9cvwBSL++9d+zPtwegCEFQQD46r
FN6LC1FqS9q3p3v/Dx+m7PBJdHSNVH72trXvRSRSagRQQwwwNHRfiwe7+Xb/JI1MJCxoBIZRUhck
R418E7e7X3iDyf8G8q730Uk2LFFQTKihYXMjLL9CD00SUkZhs20vdAlyVm7wg8dP371uZP/YEfiA
nEWDwwQ7vq5h++gPjF//AIszi9pW63w8/Gbr6VNbEF9eXVuBxGjDhe/WLG8oVVRqAmTYRD/3ZOGD
/f8KggTHAyBQVYa30H0d0n9kax196Alpxr499L6nDjRadwi7F4wYUB/XEQUMuobL2NvTBcoQEGAQ
dusYeVHMJ66dW1XPnDDOdl2kKB9kAwvurYudDIK8JIAOsD/tuobuAA8Aa9z/aDGAVizU4XPPzgwH
MMwH0A0ogO7cz8ItCIQkeDyFFI2UrWvd1yaEiwtSR6hRI1zYNJgEuxgQUjgAoPDPUIiqOoPDiy0A
lnXf20uNhDpFIDTVLK5waxYUByBShBgYTT7bkGcrNAIk/B0U4bHQ4RiG/ieFVsqywdxh0/VF1EHV
NCdD9okPwZREjA35LI9Qi0RRUlDm3uywV8fNIJKOp7PwYY/np4P4AvKtY4PsPawhsKqELnUNjlVe
NWAdUqkNQTUE6VjVyyCXfPu5d5yYINaD6AXGtEVRVyexdzaYNldjvz03hdO9p1YEuA4yBAswCbEM
cSt0TL2MALKMUR8QAe3t1Y14CG4MR7hoWNQt13U0TQICDGFk4hgity7sQhwjaEwaSVwAoWzL3TUw
FmjEDtZgIAvf/SmWr0ufmbkJlPf5ixSVnJMO4XDMQALWWBBdQ8t1jYAiBIwBbDCFIFu7aA2AUNBg
Qx3MtrkjJx1TEkyzPVuXO4UQYywnnPjCJr11xnzxdRJTEWC3nu1YAQRXKqDo5XUGR/en21fpnQZk
ejPJM/bQQxB99/e3B3Yqi9WB6sSB+Sk9cxqKhAr3f2/3DotdiIEJKEE7yHLeVcYPL7+Vj2OY6+t0
v/AFsCA7e/vvbyoUc1SKlC4OgPo6fAUEQH4KCbNvf3N6fTB/FDrQdCAIDXUmRlHIdsn3R0HrHQ8L
DQqRwsKePQJGR4t8pnHiEBZeIYfuUVNUwQ7zkN+wl6wAWXKdgiYOZ05ccQ7hEF57A8NGBNf40Ax+
OdNScAmOhXp2M3FXZGEGg23wCW1XB+RADrBWF1ZNyc5hpVcrF7yfMyedAKlYsBJo3mVPjqxLmKGk
AlhrZ2bApEAUV5A9sJkcZ1Sv0R1s1GymM6qBaAVkJTDMA66F/d6Vmg22/XPECYXSfjWJOBQU+uaN
He5rFooXiP8XjVSJh2ALHVBO/Ugxeq1J+HXPVYYc4t+Z3WXr1lYCV7kQw75outmDNet45vOlpOkT
MM6RkMrtksCTkaUTdyQR31aJyQnLi+hVoFZ+POHrxKgRVY9Q/yG85ewZIJ6HflcagVxgoBZGmtDF
U3Qkgk7ttwycJfnnIXmKBFgT//8WRsHgCDv1fQsz24ocFgPDbhQStf+3A4vQFPoSg+I/ilQUeIgX
Drv5HrINDFcBDgaD4D83K/DdXxOKRAQXAohHA34DBP0mfn89jUUBO/AKAj3xQYP5E3U1a2fhcNsQ
G8bbyEPTme4KB4HxSFDnWmuYcDRQU9yZKMBe9gubLRVBhclrxkSMKABFHBjABjWLrww9zWALVDVS
ZwdDpC7cUJk2aQZLOJBRlPpELGTpWxJQU1D1Bo8Or09+/3QEEnAG3qsKxwV8RhrPdqYT+rhMG6rM
7EnICe9DBV5XM/+4z4k9L8Bg5BKp/KEQLFwyt3NMG59oG94AohvflP0793UjvQxXTQLeQv9zrCTY
g/v/dQ2wxafvnm7NImPk33AIHzvHdQ/xH+TSahl8DKLrBA+/QAhmx/Hv2MCY1GaFHotWDGoQiwKb
oQs9R1IsCIn2ohDHLmSRoljQYAt3f3IPplh2FCXNCkyhgNf1ZnLZ0m90D4vtIO16UHgj1xA7xSkQ
w6kWSP0FInhs4G6m7Dn0Hg6l2CjknuG1V8S7GO3aP+Z0SDmsgIl1P5wzGxbchBss18OKHw6EZrvm
UkQa4N+Z3het6V4sJCbGAk72EbZO1yykh3UOg7ywvlfeIlSFOwFy+1VpvtjDFnVLUm1QjEGY4y18
jnlmI+G64nDBgFCIvs4d62t2D2i8O194ILRoJLPtC1HHLXQn1Tci32s+fBlhUlak323P5lgtqh+c
39V2KLvYOdKjJt9AXBM2HbXh7zR8JQzrUKlkGxZLMGdn65EqPGSwc/QUDTjNY+7szK5wfEJWdxTT
dLYZwGNsWrivCmfkYN+kUZ+6oS1CPS4QeC0Yosdpe/XbTEi0nFcdnWNG1VMjtFxwagVLyBlyUbxs
hvnIJTOjeH5mZffSpAF8aoKOH1rGdnHotUwhcg6w1SXIF/6PpHkFSIPI/kAB/v7//+h25VFk3k8N
Xaj4h4Bh5rlw6MFQcGyYmd78H+stUwwJM/7AAXUjRytMhjQYlh8usCZIKBQCLSWUSyZ7M29mlUDd
2CUNksQUZGqQjAcyYSNRZpRSPF0sIV9euDgFWQjh8V4qB+HAoTjpBQ85yDfND5ZoaDDeQIAI8OtG
oMjgIBRqSgkEvd6bPOmQIDNYZV25NZloLNFAC5Q7nDwX8lJoFGyETIvBprlQUVQQ3l3zuVOyp7AI
hnlRNCMD9hVRIATWilxoxoWLEuZ1LMjDvmbAkyE24N/JAHZgGVcAnr0ZLw5O0g743Www18WlWGxj
JFAgWBu/ty8gg/+SaIzIQx42MHvs3XAb5CGbE2zf62Lc3Y/sLDYvJFKc6zJ2tmRz6mOUUXCgC2SH
RLcdsYNkTQZ814xYqXNYm3DPdicZS3Jo6ViEIJKCTSBQIJEPjJWxy6xYDMnIL2ZOY0zdAEt2lb1o
0DyYxQl52RkYLPzcvOQF2eTcpLMLyNwP4RKSRTAnsNywF8ghmIzcr2ySiJx43ElAMpMDe8CfuWgx
iwwCaQYbMD5gfgwswrcW7qIiIQ9hXxCE2+PkZEyIDkjbjP2zJCMRmlG8pJk5kFDaZpPCygXTFR1Z
AZiQXhYZ5O6E2gAs2QTyJh94IA5ADghmVAVM2nMhh+wtbFzLRDx7KbAt+5r0HiQXMoE8NJBXUqyu
lyTaUNIB5G4U2tY8jK7feCDrEQoPO8zZyAnhhETZKwjZ2aEETpTYF4TXIM3oJkNIgRIgK+yBlyTr
FQ8S/BsJvMiQ1jtaO3KBbAwDioSHFWAXfEpArEAOWA5k1lmrsk5/pjGGPiV0I2CLDIW0TWGDdAlj
JMsPrzkIBs5Uoic41kJ2kwkskjIdIGGKVK+wOZoc9sIdMwJ0KzUk4i3jkNMTbxuyIDBIOVukZZML
ORwQ+EJOctgorwCYIA/jskST1etfp8jV7CXkITIds9DkwkK2tNCMnunMt2DASLSBMMQAjEVPPMzR
Mw2EUv1RsNU4kM7gDbwjV4zAbED8mMFeV+QAEodArITVAfmSLfkoVxIOsJB0eagWMiHwaNXzwMIi
CB3G37FdyCUxT3xMKbYyknf2EYIihL0rRIwgWMhV9kuDPEIOWJziAPzcJCYTcuTcyJ4nEnIKENWF
lAo5YP741K6k2ZA0PLz8BCxpZUwT1sgBgyTM4/TUdoCQHA2ILQcIyRQDy/IQUknvStzUEQKnUMVd
zY2keMgI5RJq5JBBk2AF3AiEK040hHbUsCJlD34sxKxoBHzUMIqVXVaAFDQNrHhaHxjxUpRTBDAH
ait1DykO7FFXzFdmFIv4YcGRPddWzFKLNaSn45wwPIQgZbgggQGT0BmSZg8w3+sGUVIumawRvkm8
DBGLkELxBECCydMwvLwDkCDSkPO0A7mSATmEUIzCUtgbtFrlWrOZzo0eDxwFIDXBECm9qaQLpHhZ
cVFWajLJWfspLKLY6RcJ2drJJJNM29zdZDB3M97GBd8FLtCRSSaZ0dLTVANwkNQnjJtQRiRYclvg
L13TdJjuyHhqD7F0xnA+1U33/wiUXlnDH6wFV1gRoThCLSFHqjwAAUICR/JIKiAEBJSyeciuBcnY
6agF0OkOOesFdEbcA/xDviZ8uNGpdzIjdsSThJTGLgzgCBu5si8Q63JFDFEYEV8OOQf4FIUIybvs
IJOGBZDIFBNzgTxPDowMyADwT/XxGGjs/oT4M/+JPeTMEu2frSZMOT0U6wr4Bg7/x85P9xGNBJKN
DICNFE3oC2KBvsE5oRlI0xin41vuK4zBArseU6YkIZRgdhWEkK6JcmQLGZoeNhdNwAQrGAX+HeWg
2AEoXje9/ZEv3EzB3oNTi1UAQFBSYAmnA5LmB91edMAejbSLRLlPdzdM1ExSAnA8BXb8U1JOYFPC
86X8UBEKbPvd55aFUDT6jRuDxQSB/cyNCmvRgh9sv29CWyzZa7ZvUzzADJBNUHoSDEEJeIFAHvb8
R6jcfen+2PgrfXaNLIVMDCusBfqNMN0gh8r8kAD4aHwyBBGAlcoxvSjsDr9+db1/dBQPu4bg/RJA
hDvBA3yxweGskBczB/INw7fu7bwdwzJJHBgiD45E/aB7ix6mBNdoD48gEeMrSICqe8KFfx4IQc9A
BTP2V4mTHFiPNYWDLdb2SA6MAdrVmAMemku6EoMo1TwCuZJL1UOQIawX84BvwmpVgtR9BcCwEHt4
LDb69avwEEmFyXenu3xkU2QUDIJp6i4IytgGhsEvBCg1FMxC48EljUOcKB5YoQHyMCxSUEI+OxdG
HC6EQIHDWSofL+EDEKR5wxwknhBQQAUBcEKIDQz/FAItZQhmj5BPEQvEAR6uHy4cu4HYIg+A8PQQ
QQQgl0s03CgBFOCUkaUgiCAcBM+BAOMEVMGBJyeDUvihsYYmAU/tV2eavzOAQph9FR2L2LgB3BqX
tzvTCBSjy218+9HGpRNtfWyZfCMHbhJwewV9YRx9PqDCz2J0hRsnTdX9QkJGf/tYA/SJCo0ciYpi
E4D5O4iMW9bt3l7nXlZ1vh9AXA0Bt/Z9icaETh0Ae1x8mhfCYWCMLT9EPCN4MDtWuljg4BQMAq8Q
ygWHxqxGP80QritiN6NTDkDsuizKBFVXUyDIeHxUjiAQ9OW/TZxOgYPI/e5kgYgQAyucNxbw8DBS
aQyhLHkZH7iudeh7JFSuDMCd0QRnjDJpWFO52RJPzFCeEKcCMlEhyZ0FMAEekHbLD/7Mc0jg0xSN
R5zDY20We5bpFV0qNHSugXh6KmQTMozAGt6L3BDh1mLbYQm5IC9Sa2QCH5t4ahOBx9dCkB8suMMD
JBBH2hPKgSwc6V9diQpbXqJENx4ZpM55D77CMmJ/fHoHsBUUfusyD8gAVpvNnb9ikuAz2yz5fnSL
XqTprIygBYhVd7e5izWEPbcldQNTn6wi3Juv4THcVYkdsC6G4sZLjhZq/NTgNr0RipvgFcihPawt
XnvbgCcoVtAab0D7ERzbRrwFuOnlo8AHgyHbHaPEBmioOTwkvoWmYQNOpFV8BT4CF2MnHX7MjBhR
udtXKMz7q1NVHczZwLU16w9sTL7gTj4egZiQMCS35D68scxwPYowLAPTdF1XMPc0BzgDPEA128hd
RCNIpOBMV7yhvZcO4ITsxHUmobdXa/xrssRTVlNTuwMQeh//2pAFNmoI/9f3g/nGfqUlWjW+L6G8
NLhz/NpPK9BVUhdBK9H8PuPE7ORAUz2j9e8d4aboUKPMsjCgQEu29r1nOaPIVhtRQh40F+vpRRNM
KHocuW3Hsq2YAMxgU3knBZubJgopJLVqutY7uwVEwKE2f0UssxXACiCzQDKADQZ8KBgGnhJm+mf/
M8mK6olJFLmybyCKisrB4QgZRKfge3Yj0XILwrk8JXOwwsO4PMJ8gS1oAQY7sqYqVBBYT0axXcBO
8g6gTBoW6S5l+IP+D3wE7An6DxVQG+jY3BA9UCZML2ABdQvLHytgvAKI92YDZRxhCdgVaxDd8GNW
UIaU4SdUahNokKaP/p+ZEdrAwlKZg+IHA8LB+AM8YQT4yiA+OGEYSMF0ll7c6c3z70uGB4M9grB1
L7gm12A9U0lTKQzMGb+NMXO0HC2s/IjZi3cIWQmDMBfyBA51297IAJCGprvug+xUglzjCDDh7hM+
z2JkdgwMGAkHFOifjQx32w+HsQY2g/gg07bw0ndOk4vISTxJuxBEA9wWDNgM+yUwMN0EpYRFVMIQ
ziW/Zcer1KESItyht3+htkuByy7/dAmD6QRSvQJrJcshAajEcxVbxXxkJ0Wic/GjvXG7+hquaGxi
YBSK4DRRVTALUkN513QUwC3pPZZVFD0VbCGLleUqPypTOv0P7lyvaHWgTUN4lDGk6cBKSuxMzDnp
pFgMTqFAUCshUwg65BQISe9shBjQT7Kwn5Buu4r6MYraweMIEekxu5Q/C9qFTD8jOZILKDDkQiaS
NCgokaaZ5CwsKDwFz9edPA1CBEFHiCGpbGJARVVngKQzJ1VHaA7jYZZo1e0njXiL35USEYP5B3dt
/2zoQEB8HNzDVnVVpJuVocQv4Hqgj3jIeQL32eueBRw3iKzCD9g+NjLeeAp/HvQKfiGGTJq6kR0I
GExkz2CzlXAGhU3iZ9gnt90zG5Blhg4+A8tAsrmE3rJACxd/lDDqeMEogFfBKSOzlPeYxBmQT0e/
oMzhDOLB7JBXNAtRkK8sppQkrEbDIoLFqsHQs6F4uSKhROEQFVulTCPLoUhEF4+Kzs8oPYAczEzd
DbXUQCNlJx0UjVCyYJN9SlAWUTMt6WhYRYeLlEHNCSEPGFYjVpJzN4lDzpnk7BAFCfX24uduJvfG
BfgFEDEMGH1Ssaz/8A9BO1oRo4UD4uZes4ohG2YYAQjCudB7z9XeHAGQC2v4ziDTAlkcT4C+Q3P7
CIxPECgYvc48BBqd2WLlxh3UIUBhFOidUAQ2iy1f91qPOTwqYRAWVHQ0CyoLFhgxng7onwMMFn8z
uZNQig90ajxhfgo8ejANn/t9BgTgiBKvV5kE3S3Q91EnBAEUOQQgiLZDhvMMhMxrIxgPLl1gOJw9
AAwOdWfNjZGKJYQZgp5LrpoNlgxWpzEDxWH12HQIBwR1U/4IXGjACE5DJnvHiojd/10BOhZ1HITJ
dBSKUAEMVgH00u2X4sACg8YCE3XgTusFG42iobhS2P+BV6YrvNmIALo0g8cDgD9flga7fYpHAUd7
dfgHiPtfXz1ZgM8DcASInGiHQ+wkeASZ6kqdPNkZvqZs5QccZCBckydPniRUKFAsSOGAx8kwQBR7
jugRtnrADuKtOIsxoBPRXcBoLAxSXI2HPLfcQAM0+IOqfTQ193RVaBwkK25EWBAwIMOBMjxVcxVM
R5f3HIM4/iZmnF2IQAJx2T46RIYvUeMdVKONoiNOwvEHLCY2wsCHVVgTToV5Ev1wBIKZzXzHgWgM
BGxopLBgzJpkEMRbFiNpWT6PPzaDR8MIAwxw6qLKPXSHH3L/XwBLHa8OeMPqEoXCHKy0LXKfoLMC
rdFA+YZH9FT+8GZPR91I0VBW6OTcQAff2NSrqWZ2zxEkhF4Ivw1++nQLjUb87TWs63QGHItO2yAL
wBBRFjRHKSBmFR38O/hy0uucHqhgDHP1xlTeylDHMHEyX0IIZt61dqBeOCh9K5kWmcmd2xXXWJwt
DhVqLtS20SAOkF8ESCHBJRpgo/9eLys6wDkUBGM4sQwoD8jigcEEHh54ExeS7BERcFnaTQ42BvLA
1lIcKLYl8Hq8mdY8JGXBY+YVNBeZHnilaGVQ1lDOgJ5J8FZ929QOZgOMFLTlog1qVrVEUSgTuDHH
iwWnNLLrfAo4A/QYoCQ+N2gTHFFDUjZsdTIZXKgOHiRE8q4NMahvgHT30VBJUoLuhhmBVv8cLmi4
zzugFHUQgd72dYTLimZQbeosZBJOsEt04QSQPEUTi+hDSkaYKv1BiDZSctLBFK8clHBCTghU42Oz
SHLkZAIkAoRATiC8lBJnLAMphJk7KBU0Z0jxTMk4AuhVRq8jDHEoXCIcF3g1MhKICL7hJl10ZBOT
MCRAtMGhI0I9GqCLcLoyQsH4NMDPuYQtDOOjVSEarzKEEdxRUgcGagvxUwBE2zYXLMFAOFI4bxjW
HbxL1Gg5ajtQPnUQDShWzLQbhIGbgRj/a0UyYuEwfeP5cjJkLCRRMzA1NC+HDCQ4Vf/WJMaA4JYQ
RFSa2XChITVDSFNRPjTICAYemM6FMdhjGIJFvf6IABoeETiT/6WPjAWHc3RFJqsW6IFwcFSSioV1
46Spse4Y+wD4qeRDdSYcj7gHR63JGBCfvynfl2A6jKSJKJyTDrNwEnQQAQRqh61Oz8AFUH4fxDwU
XTBw9WyueGOE7p3VvBlKKBMU31WYYNk/jZNwm5tYmYe0LNMkNogGMglQJ6pD9Q2xw3g3uQE4kFGs
BG3U/x1ARFIr+YvBi/eL+sHpAkU3qd8/yIPhA/OkRpNE57r/WLFEg+oDxgQQZPhEsBhQu22xFTJS
FghhEdl+073QBEN0HXiAfAR3XHTNTLOIPFAYUe55cuwXwKzjBzCkNJw6TZ48OJQ8jC/Hd0OFfJks
iwZuUtiSzS5KfKqIA4TjhPOrwwlOfAMM38KEuxf0gIT/BXy6opoLCBEW4+h0ZkA+BFmQULOokTnW
kUPyRS1qzL1XV0YAmCwotihd8kKiT7gHUytql0C/GJpkii2JGlNRLTkhwOlzeFx4AhyCdQLIBtcJ
U8jnA1jEBngCjAhZbljT5M8FylC940xhGwDcy3wBD4a2BVy/dFYSAAxvv46P3Ki+D1NPWVx8g8PA
MsGFEGoQU4IGeG6Ge2eL+zVpe1WjBaPNcHNyUXR40DCdGoB7lPoC1uenDFE9clIB2XLwM7czUHqh
KlFNYEM7dBlMDTpggm3HsyHIAtWxKNQYa2GQEt4tbn/IUko6VATf2vDSpNNjq+zetcLkEg0gjmAD
tTiWdErtuPsZlxxga3TVI6pGlqiKAjxHJflAFBx1FFuCkVS9qRaERc6a5BnqVy3+S1SDIMh+Y4pm
YYpeYnUL/wOmD75+ZMHj78mMWAjFY9/hik5gC9jCUgvZxUfyUW8ZnFCMbpDk5CRkAlHRXAIFFnVG
WIP+yDjkbAHVg8fB4AQD7Zsb6AQCQo6KAFBDuPHwAHq0Gv734gPeweoGHxDTFdt3r7pVGPfZEYPB
AojoLIAXbwDCRH7xlwcDRttlcLSKLBkATAelFJc0aTpmmMbKV9Mo3R68A9NWEVZESEZ1JAcStJNW
MOBRRlhoUYQSQEjo21JvvwIJYMlYuNk0E0ZPEBhkAnDRkCcg5EDZ+FzCABJpYcPBYEACiB0aehz4
ekPlPQqnEmyFW7AcSzXwWS+caPVMPC5FKywUdAVe3EFvBBB1B2RS6zNB3axpqii4yCr+HG9xc9h0
Di4LdAaFDtTrDprBRnVYTEVWcq5w2IsGZqzimwc8Im2PtH4CBiZkK1GALnpMPhXj4aIaX2XeYPAe
ww481pj4JgXBIXMKVcMjF79qRCy/yRtksC9SapCBUL34h4xM2W2MUZSzMaAlk0whQ85mEWptUigg
bBDmlnqFseDCv0zvBPOJZ9Vz/h+oV1XmoQ1c4ZyUEid01g/REf0UaDDkVQqRKHcaMKrkQhw+Ij4E
AQPJlISW8lXNnQsvjngUbJNoB3wP2LIYINhAwtsSsosTS2/kDEgCPYHfLCooi9Fyyk+raM2dK8op
sCvDexWf3kJORfzDDo1RfpTkSAy9lFV4Q4i5f8Glku8Fq9JI5q5SH3H4ACGLhGwgUambMAcSvekE
JTORcAkFKUzOJdOdpr8UShzGRdNIAHBXlyDIBoAIaNSAUHBfQH4UD4TEfLMQ+yxiX75kD4yqGTmD
6GQkH8gWgPooGHUScIEckFYUAxewQ/FaJCY4KziSCxASHAEcDpALDHokICS5QkYcMCGLZAA+PsXN
Ak1xALubv0DkwOL7hDeNDC5oElE6G2xxaWepLgY7Bok86Xb3rSJoiEQMIBABQUYNdfLSHRBo7sYR
vsk3UCCZi2KnPFqBTHUxmWBM5tXcBfmiVClSEOsBRkno5FgkjGkYgZrUWQAGV4uBjIBgq1QPnQAu
kDXWzXGYsVXCGAfeeyDNswnF/7zvZCqYMCrAKEYUBmQK2QlVUxuBcQbJwhnWDS45ecmUUv+EUC65
5ECMUZTKSAZNWA2EDLfkjH0NZ6PFaAkH/QmpXzD6kEiNFC5EElLI0gwYCXkHB+Nv8P8iPCB0Hjw/
dBo8J/o8PHQSPD4dhMTkId6NROdHJyPNNRwoKEWS5yNJPRtEUCaJZjkYV1XkFMahWUkvVBvIJ4AE
vyBZPAWRYlXpMDLBoZ3VS3Am1MFFk8meao1gkofLOAHXreBNiAmE6jULJuHrDtMmAtTVoE4ITcLQ
1po8AbM3oUnXlkgxQQjGD83TM//B0Jl5MMBXV9jLgBUoJOlqMUzgaELXduYUUL405mF9tHA66lCn
U/lGTcGJ6+IxcOrQ3/4z7YH9/FM7fVM7+H0tglS5gqbEVD5+11jUqHwTExdHRoiEDDjHKeCGOzw7
i54n3Mp9Q4uVRoPFMokHmDv4mnDMvBQ3BFx8pWeLT0GQHCFI/pqcnZp+fFuNWQFHHEsRPpDo5Rbm
agR+zlb3GRoc9H4a5clXnsBTBxcjNsxWx3OtL03GMkt1VERWCy7RzdBJB5SwSHQcAR18f3ducP+D
/gF8dgRhopy7ej9wYgq7AiCIjVf0jyzRzlcgCCs73n8ZK/NY3b5v4UaNeDJ0Tgp19LD/ul+5NLBJ
TmUYQoPHMkPuBvtjQUP/O8Z+t4UccUE7zlQHwIeSfoqoQqbBNZsJ3hVgLPfogsCL/hhcLPbenVvS
QNMSLBDkTcSER8B1zeVCR8AIOMS907kxHtbD/6AFQBBoRsAjoE6XkbHNKljoMqBUOz4W+YsN/MLc
rOQW1IglOEowHEjZ5ACiM0UdCmYEnn2CC3iAIlBmFF8RcIyAmGoQfwTcyIicVwyGDFJWvQnsPBiX
oZbWH6cuoWh0Wo5oUOT2T9CMSLNwMwvgdqzbpIv5qX4gbSh9tR2L16ErKyRA0r8U8CPNSwPYO998
5srG0oHeFI08KQRD0SDdN9cfKxNUUgzSfCPOGBcTRFAhIEGPdehWp32PrBpZuX/AAyugfBDY/DGE
azDB2Jf8z4owKRkSIk0cr4qV8xsJ8OAB9yz+60W72P+p9uoDgpB8IcQCA/ns0zQRaPArM5i93hQq
cxRIrDpLBcccP0EHXi3bpTkkOPBVVJcoUvcmSxF3HCRTfdewjDEWBwsyHOtkv+5jy+IYSQ6KVAwm
Esyb62UQiBX+FkQMJ78HdgByLqL4HEwMumEG4CiIDYM5RSlIbpTZOPf1iACBIAtRiIgykCIHRLGr
YGxW5YwmNuQJWAbxziiIcTBNDfzco9lzJheM+VQKz02KyG9OkAF/gvIn6lSGioQEh2xmYJBciBxz
FHOy7r+D6gJRigQQGhWOvuCdNWAKuisAHBLiFcgC5hB1GPNh5Ovu1LmMUJgpXKoX8jDyHOIaamwI
5UDMzAT9BHE+EaoAHO4LE9HiBaGI2KzEQCJM/fjxvYRI8kU1xBrWiH3tsxR9AcynS1wRTs/mFgbI
QUzksNy7B9/ZfehT0M0cwKBFPARjF7wbo43NrcLGupTGDa7Vx7bAvaERmUQyHXzgNreKYCbIDMjm
rZuHZMImEwSFkFDobiG5kL8FdAjJTsmEfJitCFzLnJILeXEtcMw5JRfySgm0zHNKLuQjAtjMZEom
5PysA/R8bots1SZ0OM2urHlOyYQNLMKH8pySCwbkwmDkOSUXB0zBOdhzSi4gTNASJkc7glwrWz/s
V+Qhm928CUosOWw8DCInu0ZcC0I8ABqbh5kGJAScBny2yFbkiq/HGLx06uRAZdbvg2oPU9kZ/Wzf
dD1woI4GCpKMvYCmM3D26pEimHQDUOJS5mrJyFIQFxxEksvMVW9mQI0s3XV0B1dNcJT3iuboNNME
rQgOkhHfVQRXy2Om6c8GexBowCcJQtSeDEd27zM8Nawzn9AFBwaRUqVRMM02s/30y9T/yHVtG4sC
CbAnVufqAkYC3kIe7Ovjv3D5oPVpktRoiLLEGDGI8NQ7CB8vHIA30h0A4gQYjmhWXRl21u4BDgR6
vBCb1ymAjMEb0xxqUmLttsgFKeVHCOVNCxDhLN2RiQLgCBSPOnEQboH5ClTwW1WaxchSzP7/KFde
j1wZn3hoMHWWnWxmEB8UcvTkL/SEEDPag/vs0I10YTBXddL7cdNd2s++BAfViUAET3XkIYsGf+zg
CsRK4Bbv65WQ/yU5MrK54A4F3NiYoRCwZuSUnMwAE4Wj3ygIV1NWihFCBC3+439pinEBhPZ0T4v3
LIoHRjjQUNwIvreEqAuKBgoK7/Ve//82WrQEwxDwdeuNfv+KYQKE5HTd/R2UKFo44HXEikEDMRiK
Zti1d0s2wRB03+uxLzSKwn2lum85WKKNR/8MwxQF/670LqLJhFrTWcNmDNhEtJsIWxRZDRCjMLHf
/m2ew6EFacD9QxkFw54mABXW0UKJweRqf7bMAOwaqhdRPRyN1XIUH/vdUN5n3i0QhQEXc+wryB1+
o9uLxAyL4UCLQARQw7hLxAXI+SRU51R+Rm/5/g8PtgdqCFCEdusO4gcbEN1Ib4qp4PoVL3T7A0fr
0hU3RzQti+4Oa/S+bf4rdQQPSEMMs4cVIlVAC6E8+/dvlnAEDY0Em41cRtAw68+D/ULYqRJxw3Xs
hci1rr09jUL/Co2kJKvFZAZtmYAG9CtDwZEJuKN9kAj3wud+1sS/WIoKQjjZdNHdURJ17QvY+Lcl
2srD6lYIiwq///7+fhYL/6ZpM8sD8AP5g/GL8ITF7VLwzzPGrYHhpQGBbhHntxolBnTTToHm/A0v
nFS9Xl9b3YtC/DjYdDame8M3x+843HQn3+fB6BASFXvWbprcBtTrli2xQv430jsnnQb9/M/rh9z/
9uxXVr5NEOMmi9mLfQiQCcbt3+rZA8u8i3UM86aKRpbJOhLudiH+dwR0BElJ4cFbO8nDN8Nl0xvc
aCiioxx2ZKEQW8TW+1BkiSUHRFiaiWH6z9Zl6JHE0orUiRU4+XIb4FLS4f+UDTQN3c52AecDygow
u6MsbLl+2Acz9ppk4VkHqBybtt1/ea9ZiXX8CGM2TVgdozhjN56IFrhifhQRCV+91Da7twRe/lwg
K55FpFAv/D+zKowWpolFnPZF0AEQD7dFoKm3LwNqClgddZxWeGD+W3YGkCNOnKAIXE2LRew9jtA7
eQmJTZhkXSLprG7j28d1mB5eQhxyAaIWrYN0ZvAbZymC1xvCXDlA5S8kWSV+BQ8FQ8NmhfZ+pebX
BO5oula7gmjl3FN33UFew0s1ABXVVKMOSObWDw18En6DfOPbwV7gdyJdW0BAWXUWOYrmeA62dBAT
cMXeK2x9v1s7OzXCSncLcGwQGhz2t4VGqQ4B1MYPg+bwVnNR4eFcXOFRDmlDtbFiSIP5qncMaaBw
qTBGautSyRu99OdYDsH5CC3R9kS9gGz/S/1edA6AZf79TfyIRf1qAusJDf2eRXy7RfxjWI1NCqpQ
jRY4AtUQ3HDgexy1NzQa5wJNmgojRQwIg/iBa+/CHAvIRgP0q4GjZvfh3XbpKzUFZB33dRQDCWpy
7H7hA9NbGqE0Eb0CgzsbNGE1wAS9wJCv1QhCDgB2DadoT8EhDBBcb98m5FkMAVcPXzk9aExGhw3D
dRFysPA3UK3BdwyLR4k9ZM4KfHciiB1gKDwEgyJr8O8WJCwJVo1x/DvwchMCl3z/FT6D7gSAInPt
XmgYlBSWfBeGzGggEBwZse8tj1t1EHqJhjNItgvCX8eqcw1XUosIN1fr7atAMLuCzYbaXmMPhLWL
WPSrJooI9RXg+wXmoNu9y4NgCOpY6SRgxyQvNNzm9gANbGHvdE0MiTq24WMLi0gEg9OFyB3Y5/b/
rgkI3AUD0VY7yn0VjTRJK9EEGtzB7rVoEoMm2AxKdYvb0tUux+TnKo7AacfA3gW9BQwW63A9kBJ+
BuRngV09kYRKPZMG5GdAhTc9jYLnZ0B+JD2PhhE9kil6p5MKimCIXN+lWKvTNwpO6wj6UUrE63AR
z6PjpWqz0Tad/0nrTFtdXavZmr0E7OA5FgVW/k/3nrh07etgwAw7xnMEORC83/YlX40MSV4DjRU7
wRJkuWQqiWX2KBYAqMTLdHYvHadzUKAFFiAlQwEozYZLI5oRLMBQp3IpdPFtu9DmRnWAPiENBwo8
IHZ3XXsrsQwgd/o0KAQP6YvGAu8GC9tTuTkdWlFuv1qwW1r4M/8nOsOtP32Bjz10AUfVdzxZjeUS
ptjgAevoxL2dJW7hDSKRWTvzCUgxfwtPA1EJigc9QTgfdN2+Uew5VVc5sFlFgD9JIlVCyxaONDvD
PAYuO/btjt82eExZblkD/Td1yV3/hCV+zyIaiR0LiR4n9QhwC4ckqX4E7pWNQFG9vnArw0jQ4Nt3
2qEpW9s/tqJYfP44GHSz+CT4G+3vWChTU59gUIsPoPzWqIZt2IjUkdbXhk26oQgvJyRsOxp2hlBW
NVIUSFpALQbdzZyjPAZbu0yU2g22GBwUpIMhcmpyxBpLl31UtSBtUCyZnHc3+onhJVi4FIA4m0Sd
QID6vrRfaGgpfiW+0vaC4RNH/gY2Sg49AcEGihCIFkZApWNHxgvV684MBIAdFhm7vUZAHOtDHgUE
92/J20BE2vaDGRiIHkZlBcpbcyB0CQkICXXMnhuFYo1Iu0qqgGWyQSwVPThB4GPb97VEKwUnA17x
F8iv/QMzvItVFP8Cx9DX3xfaCoUiXAhAQ+v3kiwQ9Ebj9sMBlkE5fRhW4ta+VngBIo3jHYvCHjf9
RgnDCAyxGBgPlMKJhX63vwXR64vTS4WTDkOIxgYdtA9Bb7FLdfORSoM/S23zbVUKij90Og9ndDBh
wLouKBniBh82NyCcGw9AAxUBQH1tCLuQYTwwDw4KCTK02scDg52j+SZulFr7oEmhdAIWgtNE1ERJ
9oaButHAqHUzegtL9T3XdBYh7evTPDkzC5uhO/sX6hsCs1WgnV5i4bPggd1ssw5DDD8nwmY5Hn32
ditz60BACBh1+QbyK8ZG29gtL0BO0fiOQAJd+tITtQN41zU763QygNYBSzISIxwVrhQ0aA8lh2BS
91AODBAnM0vws3UDVp5Qw+tT+XUqncy1TKWFsXQ8YP+2W5R8DkA4e/sE9ivHQGqFJW1qVc6q+w5G
KjW6uvW8szxyfbZXPUjG64mtla+KXyHsRK8AmjQVhjplMhtaLphYFSDtGCAWIDZu8D7Nhim0cxpt
BHfp/Va2xkYFCqEj9QgFG8QJHeDr4uhbZo0R1NEJQnXFr0TfS5+t6Qu5MI3cuAAISo1l7t/uHC58
djk1Y31SvyRMj8d+9oEAOIN/iQeNiH7Bc7ZYluYYgGAIQIuZwGeOsY34wXzk1Ul8WyFWgruaCfvR
ftb4G+hGiwPLNopNAPbBAX4EFyIL8Ah1C8I40MeLtWBjq8+OBY0fudC9RevPIVwLiQgviBp/BG3r
R8D+fLpQlHiBz+w82P/y2HVNO7dvlSoAirRq9ljriMNI0G4zQOSN9VgwoUYnO0i5F1dmDCXY1ij9
MD7QBoBOauoKX2J38wN1CgjrBAWAQ3QDfJv/GJDZYrg2NHvgkIvgRMN5u1uD0oM4diBVJFGDQyOj
kDfBIdTxF3xKD6H0alJNPOfDzcPDLNoPaG5Vizx1GQlDHWz6gmRdO4vl3ExD+kEOakEEMsx0D311
Ux09TIkCuJvDm/pH1D6LTv5oRHXN/zXFoZg0AM6EYwfdS4twDIguO9utEv0CJTR2iwyz5G5FF24B
e3yzsnUS99u/7Ysts31l9v9UCOvDZI8FQ1eic46jjOhkZQ/41tL3gXkEaHUOUadSDDlRwcTdW7IF
m4pRu/RYcttWIFgIqWFLAkO/teBb0WsMWVva71ZDMjBY/GtB7kMwMPdu+vyLXQwOS7ENuvdA5NqC
itYctA4yReEQCD4t8V22IXN7CMFhu3a2UP2ysY90RVZVjbpUC77uhe5dXkELxTN4PCVTwCBAY10L
GR1WDGIx2QrNbDZw3o++c922S49VDDsIMBqLNI/rof2OfTX3fRzJ6xVcav/aEGKTP10WlLyV7PYb
O4spi0EcUAMYUCQFXK8MHD+imnfzVg3zKk5E5UAhaPw+GHUdK0qheMxZ8T+Y1SN2YNiB7NFK1Iek
hFUI2qhPbdpyoJELQ0E9/XxVeH+L8ZbxweYDO5YaJjNLw0xBbL3ocGgP3aQNENeo+nVKxaartvGF
XKEPdsiIjHUTFwilQImzsygnWRJXk3s7Fm+9B2JAWWU8dikZgbOzOFB1+A2DR7Oprn1qAwP4WUFX
qXt8Z0M2N1Vg/+ikEFd+yGBjDFwd5Fz/tgyq1Wzm0xYRC7eDDGYFJ7x68VksXxoi5urrJo3YMOw2
06TdhDwIavTdgHC3aCrPXitoQO2GNiUEGpb8FE04m3mhAfIl9BQG+BC4B94co/AUUegFQsBbMjKc
oRhu/qhr7KH8B4jeFGorUAwKLewWWAAkcgecFLHY2GKYy8wcVaVNtkGp4dISGXdxDPxLv8VawcL8
V8Huss6LevxpyQTRjRIdw0uk1IwBtbTUXSuJXfS78IkTjdr/zfkI+HV/wfkEaj9JXwutUmv94s92
AwVME94DXwVfytRI4dggcxy/tvhb30fT741MARXXIXywRP5EKy7YS+11ITlhg8HgHi10OvdgIbyw
xBIkBoxtG664Ubh8VYkKBAK/294IA134DQiMi/vB/wRPGgoY2to/e4ZfsnWaqdvol+xqoEIrpxGu
1VvEoVj4SVpOpj+3te52BYnzykEb+0A+O/qW2m2DdjX6v3RrLsNRkZEB275RvbrqCxa55NIhVBEe
vbGWkA/SIZRMUspytm2/Sb5KCwQIcGGL1hGRvezVCTmFwmujM+6J91iymuvesPkpCyaJLw6KL1vZ
BQiXSmOKTAfdvvu32SCITQ/+wYgLcyWAfQ9GDrsk293giHjT63YJGQ03Yt9KQbEJGOspJONP4ENw
z2IZJVkED51bvOGxhLcJOItURfCJGjsTEw9z6fz/CLP6AHZw2cI9wN+j7A2haAvYNrrB4Q8yDFKA
KdjsgaBAh9cfMh/2HoQcCVAIDjlAEIOd3c3epIhsJA/+SEMKSGyJhhtmeUMTg5L+EQ1ML3GDeJh1
bFMQDYQF3WtaEgkQrhCjAY/0M/I4dqNo9UGLyCgryODTt1qSERKNSBRRinx84/12YLEX/w0vOwUi
NTr92lYKFJY6iQ1MOD8DNJCyrIk1CliQGjzJKmbjk3tXL2hXjTyCLBtIF3Z1R4dp8BdqSTR9DoPH
l4gvktPug03CdfTrECbgLtQAAELT6A6NBvB1JqFpi0F/Lb5d+AhzGYtL4TsjKyP+C89Hu13jFhwU
O5oYcucHdXnbTMj3i9o72CYVBevmGQVocHd1WSRzEYMRbHfIs3MTN+vtJg0bRRuasy/uDghvGbRf
q86BHHSQDspZWxa2DRq3aUOoOGwH697mthvpFEodpRSLFh3eSm36x0oti4yQttvZwy6AkESIN4sS
cBFVUKBVK900vu4G1L4ORAvWiwvtkYQc9N8K5v9F/AS//iM5C9d06YthzSrUl8pKXFiwBt3GTXZM
V84PZuoLQXdqIGRfxQXR4Uer67bbRosgVPlDCit/8Xvjpku8wf4ETl4/fvheO/ebtOkkcw0BJGEg
fSvb0oWAEaJ8OJzT8+xb4Lj7I1yIRIkD/g916oXsaLGB9CEL6zEXK5UVXLvFoTIhGSk2mJNzFIIs
hSIKwNem12V6BPgAla96CJBbg+c2hJQ0qflCDMsAUmulIsJkBloq3Sz+C30pxJkLpbHNNRcRYr+w
zoyw2y7ZCTsKjwl8rusvKOz7kB4NjU62CXsEsbytItcjXRa+7gk3am7pRgUHdQqJA/yyDb/tXXl1
8APRIgESMvyfi6HHb7cOIY15Dz51Gjsd8lEGjUhdSzukBmsivZELEbmNQgQILMCDkwINbxD/LRSA
Gl2WTVBDeio1clCQGFeXUCgFmXzaiC9YDGacwD0K0Mz0wWjEvwhFMN/iyLbdgTNciUZBKmoEaMj2
wVcjaLJXGYgABtI/DHUU/3YQV/z7rbXUtnxOJMWJfgT/BWKxlakWQc6bX8ZHrVlT6W5xyLOjtcVB
pNvFT+BDY+vjRsM3acCBWvswgtDFdhtF6kAIAgS/Ss9269Ye+4XB5995DIsQgGRy0JAALNFLdNXe
J3DAjZcER/rQjY4Gl7ZHd0jyg4h+9Azm3VZf/AbHQPzwQudeqt0O7/+l/8eA6BAUwQ1+0QWZSPCW
dsfdU9V2R08MvmNfJontZWtvrI1KDAiPQWSeREK7bvzDvJ7jikZDisgLhMB6iE5BgTH+Q3UDCXgE
uizLaPGEVsB+atirgBJVyEBfIA+ettEkTn38BL/6O3KBNEulGKGEQLbYgIIw8T695GzVfYFCXlZo
JDNWgoTZ3gKcBP8dGxggJwAsxF4ooM599T5B9lijQ6EkGBx0t64cSQWhoFfG2YIpGosORlAz9vJc
giVyF5Q5XRgZNtsK7qGwKpONUyxBa0A8wCAS4O0O6baZbRg3LB/gVnRjoRda0EI+PEO5AyQv0J2I
/I3Ai2t13Feit+mAU7R/6wv/BBtNUF3Kg9f/ydrstsQpSeBWXxxVMHOtc1IRFNeg7WfBxB3njWXM
liYNh0CNCGMg23JbqUGbOg+2Pt4RhIIG7IKIcnUctNDRDdqhDsNFUuQjDtDxCgdKQAFNEAEmGIpw
Q3N9l8BSbzW8+XVOIj9bM0RKpwlW0rioznJ5U2I5MHRyMELpRjANF4DoUJOAQCS05d4+Q0BjWb/g
gqLobhZ4rOFQ86uq0+QPhu/7T1M/MH3uZrtN74oRhNIMfiF+aq55tkH/MjvCD4eTyzYg9iXHXO5S
L2VYakiuUnHYBKqNKeqF3Z64kYA7e8t0LCot3WJEsoW2+q93b9/uHV38ipKgIAiQRkATdvVBbeBg
4UGAORjUFJMIEBs5vp38BHLBysTMLPXwnktQo6wLTjGs2v2927/AD6WlWaO7petVQHn/zAymukxI
Z0KhsVZfbRM9l3JwOfbay2YsVOsG+gvCCu63sU2rAOsNOR2ICpuCqev7MIEEqksD1toN76EotyUh
Vf6EB9kaIEuI/yV4aktELmz9FGR5D+3Yshi3GUktpF/fLkFtYCL1dBcEDXQMSDZXRNN0A4i4WgUS
LzzPdgsIEVdsWTPAGyHYIKq0F6PFYgT43tzDX4AUjGfgJqBF7FaDIgqrfz8GFjTAvoeIhAXs+YG+
/4KCxnL0ikXyxoUNIPeDbmxxN1PIVWC2CijHGrpA0HcdNbwqQbgqNEG7IACL2WWr3i8AvwmPqkJC
ikL/8tBfWwdBaxDJQ+5QY89eNY16UI1WVtl3xoJvI/0dVh7JyG42VjQjgBT8lkUIWPEn8P+all5c
go1yZosR9sIBdBZvm7+f+hCKlAVkiJDg6xwaAnQQbZA7JyBb9KDhhkbjHIE8AL/rSRWssd0wJUFy
GQRaqktjSzQ6yECYiEkfNycvbx1hchN6dw4g6SDrIdHdsOBMSr5eyYiDXPj1Emr9CGtZ/CgWzAFY
cgBN8mrBh3hDPIv/G1f3wQMWAP6s4YoBQYE7DnXxiwG6NNQAbKUD0JrCMKlAd+sAkMhB/CYj5RyG
C2AaqROzBnnbStx4AuvNv9wNBP7rCIM5ann96wP8xl8ZHexNS9ZBkGSIF0di7utarBFb/RfXZ266
yQrBaU5r4S809sZeAu8n98JpEgdqtmGINsc4xXNmCC2ZKWAIDAiTwV6wiAff3hQiO8SQQJjj4ZKT
5jIkE0E1SSbZHivBwwn+/TAMYJD8zF8BNIAGSGER/H/LXVvRA8Y7/nYIO/gPgnhRd4x1WseMFNWD
4gPrwMS/eHIp86X/JJX3P7oc3uBCwf1yDGYDA8i75lbeF4UgiB6NGJAHnIj6Tdc1MARcA4Aj0YoG
iAetue2FcIhHAQUCVghZ2UnGlsbHXMyNSSt5lmVsJQECAqbk684mkCNGIUc/jJqu6w7/b+wD5Afc
1PybpmnMxLyLRI7kiUSP5NM0TdPo6Ozs8E3TNE3w9PT4+PwBhy0ywY2adN8hbBf4Cf/wIAMsTUCB
10ARo4aQwWYDe50L+REwQ0Jwow0KKzIIm/qNdDFYOfx/JO2z214N/eP8d6CK99nvczIJ541Qio/5
K+u6X+SoiSyQuAvYAwAM190Km20DOm8DTlhPVoRhb8m2Sx+jkG8huu6IAimMJeEtG5AnJKtzbbyy
LQOuRVqrW6bpugtUBlwDZGyMsGmadHyEl4qXHNM0TdMcGBgUFE3TNE0QEAwMCAgTFtI0BAQflrDp
urAFuAPI3IqXYbYE57e1hw+DCWFgCxO3UPz5VDSMEkJoZKWj6ouCUR1njzUQpjhYLMij/J4t8Cl0
oEgQaDQHo5CLet0fetajlAahC7nsD6KRdusOoZQQNKyh9wVTETEYA4Ij0HMyTavr+BtBV79/DFe5
eiTZ9So1QR/3SzYK3tBBJAeLdW/rIXW1uNFpZEdJaTEpzf7Xnh916y0dUYPjA3QNIIGDGtUdLzlo
fK0ZG0LDedE6D9zZZC2aAAvuOmwYRWBW2y76Ksgn8iEnsGOvKgYWg8YySNMM3iweDM5AfHt1xjnr
GIHi9wlihUaaDgAEvlN2v9vW51UKBIkHX3X4sHWF5BVZw6O/yI3z5MgL4IzYjVyNIZDLZfCMHI1A
jSPkAcjIjciN03TdYD+/BqwDpJzA2jRNlIyEfI2/pvvOI8iN8OAD7EkeQNYAjr9gj82RU8gQj2iO
YI94HEgul46YjsCOYI+NQh6BYI9N03WDWxQGHAMkLDQAa9M0PERXj7/TdSeMH3AFeAOIRYQAa5yP
v140ooC/Dg8UidgAQUcrjgoLL4H5g/qBLZnCJeLS9HQIK9HnSYvIQW0wNN8DwQYQys0qdAYWpusa
6zoGI0rSQk6CckQzcOsGEBkc4T24z05wKbh1RlfVW1MwBB1FjGkPcLbyW4g2Ix0j6yIgIIAnwWcb
dDgiAZHgTzo8uDl9FH4QLpPg31RhOFlZiUUUobhUJYEDth0WHLNOm+cTvEhNgaTTfSAszNohIHMu
OSRWjFwSTSCLMq6IAPHkO99f2ME2IcEEG1HEQdzWBgk2OesTSv8mEVuCtzaLOGfcdGas3GFzXbI2
IVf0Tewa0aV3FqVwbdR12LZGX6j89PZFDQQmPhyzmwnYeLIj1X8e2sBsbWQySNKPnfpCmozIx0X8
cmTkF7KzNtyJXeASexdrkO6yfd90tFZkanOnrORndJyPs3Urw9klCusGjFatk6orYt/VQL92cQ5H
hI5XxnF7+0KwwR97Vo1K3Q0l3RLwhexAi/FJBvMMXsy98eN1BStLi8Kx/yVsQgBsriiq/29q+P+u
AGcDcnVudGltZSBlcnJvchXPfiO2VExPU1MNDQraD9hdc0lORw4ARE9NQRLydvvLEVI2MDI4CC0g
R2FibLNv3/50byBpbmlSYWxpeg1oZWFwN/+t/XwnN25vdD0EdWdoIHNwYWNtwN5tI2Z3bG93aThh
BvIUctlvbjc2c3Rk9tvPQDVwdXIrdmlydHUhse23tTOlYyMgYwxsKO02hXxfNF8qZXhcJ3vttS9Y
BtziXzE53c19YfdvcGVYMXNvD2TaZMC2ZXNjKzhGgRDh1iSBZWQZV3Z7SL4jN211bKx0aL8hjOTb
YS9sb2NrF5rbBls0ZLdhLgL2reHWoiFybQBwQGdyYW0geyEUtkptNi8wOU+jGVoKEEEqJxTyuUYs
Lis4PQ/h+2FyZ3Uoc18wMmaLbduuwW5uZ4JvBXQ6EdAKZ61k5n9NLWAY//C2OWYVVmlzqkMrKyBS
nGHuuz1MaWK0cnknCi0WGmfbw0UOIRFQ1Dq+XBt22QAuADzl4CU+y3jbLGtsd24+/92BOza+W+ED
R2V0TGFGQRZ2ZW1n74VQwnVwABMPV6lkWKD/rTqbZXNzYWdlQm94HXNBzxpfOTMyLmQ+RyiRpNh8
rncDC9zgkRmVFYqIHgCQFUV9KvmgM4ZA0NzU0ZFnQP4L0MWPkwCMRka+2Y2PExeMj46zk7H3GyIr
jo5LsD/dkowH3MncjJAUgv3lf9TT39LI09kAzs2Q2sqQiSftftbdF5CNOcVDzdLS0Q7T2G8b+785
2dnP2M7OAMrY30HKAJ0jfth/sNhP2MXe1dzT2thv1dLOyfc6s/0L084E2VjIVBv2N2v+ztjPy9jP
yQknzcjfInx4w9reBxGXPzDA0zRNtzgDREhQWE3TNE1cYGhsdHw0TdM0hJCYpKzTNE3TuMjc5Oym
aZZN9ADBDBAUmaZpmhwoNDxEt8Lb/wD+1dje1p3JBZ3cyQjn0NiPDdjP08nu2NgV2Bb409fYbhjZ
0sQVKfDSzxLZ3eEwZ0f+GtkPg+iNAvc0/MJv2XbZ/7kEAwD11J2B/++DfvxSsPe9A5OTG4LICC+3
B2shZ3qd0tMf+tQNs9a22xjbmUIdh8rwcvn/8uqd/vX4/vad6fX07tXJh5KS67rt3+6TzdzWk9rS
ywfWJ0ireAOv65qmnLwIswwDzMPHysaHAMfczxHUX8nPu7HRtsht8TsexHWd3hrR0N5ctRXbz9SZ
BOqxrfG9LJ3UzhH/YpD7Ft4YsI+dK9YnnV/NzcShuyV76U0A+dLbylVo2+5Zx9HScMnU8ABEZzPe
bRnu3gXTnc7cZFjOYbeFbZXNGUrS1qmwhtuyIy/z2CfcfrLta26CPyQP2i7Zu9r2DVixzpv0INAP
MbKwHVIL8V7Y2DMYPuMUNfPSyRWe8shu323KGc/E0Ogh8MT7Ydnadu7cEZpMQtbkMxsDYWGajtIy
Z9y3Nee2ziDqJEjKxdEdFJZ9wtET6tLKAG22zxViDiBTWul+ztvWNvc0M33fyUHIN9RqhWec1rvv
0nepbRtLV4sV2/Gymi/5VnLOsRHe0T7O5KetEGuNC8TvenbL5Pjc/NoNvfFU6CfOtQrt9YNdLCrv
1o+FhM5vU/HcyNrVQ3HCzDHyisrV8QyCe807K0H05/xhS/hwMjvRqxrNcNveAPZazTXWziC+wmHd
GPvVRMnT29Xe8Xhat9VYMt/c38QdNgnJD13Ok/W2TXYrKRfPzmfyHtp7cySMpTnbJY9uWXtvg8zR
2RqMMxPLJoVsLpxryx5LS2zUJ9GvUVZozLrV+dzvG93OaKYFN81UXYLjH7G5QXY0AzP80Suom/Ae
034TgKrTNM12BMMDHDBIYE3TNE1shJiwyNh0btM07PwIxDMDMNM0TdNEZICYuKZZNk3M7ATFIDCa
pmmaQFRwjKCw65qmacTY8ASPHAOmaZqmNEBMXGCapmmaZGhscHR43zCeaXwAoQvVBcfTwsjQJc+r
yvdBEAMHCybbs48uDa+h4LX+DePez9D2wCM5OKPZ1NLA80ImNHyE1//I0dF5yfcMH0sYixjTF/pG
YHTw8BT/+tzOK512F75GzaPbyFn30jqwZ2rNU5B6AxsLaZrOPWDHxwN0eISmaZqmjJSgqLCapmma
vMDI0NzkNGumaez0GPtjYEyaSEczoyK1tg0d0bPenJqu696ByNvbB1w7aAN0fMIwBWuIS2/0nN6M
WQ/AH2PNeq17gxfOdB9MrFlrgzvKaA4L4W7MMNgLzmqLqGeapmm6uAPI0Njk8Ae2rGn8zssLic0N
MgM6D5YRW9aBudsOP9ELvS0L9t4HHw8oss0MlyPa0Quw0lhsyS9DicjUWOAYWCzUCy6zQsCKDDM8
DHiTBnsLFt7dD3uzYUurMgelE3vLYinzMw4PHQbyA9/Uz9kSLQKxkg92m8WjQIFknbCUFk73grEA
3+t1x9a9x5vFB4YL3+l32MCGC7pHyAtn47a1FxTJIwDa7NglW/YOBDgPkyEWy5YSEyGPLw4mDttb
nSmlIbxhtAuLbDqz0AOLAJ/JA0RpmqZpVGR0fISmaZqmjKCsuMCbpmmayNTg6PgEyjRN0ywUICg0
PNM0TdNIWGh4iE3TNE2UnKiwvMh2TdM03Ojw/E8My9M0TWcDMDxIVJbr/DDj0djJyRu1SiUKjhTF
fkNotY4WP9kUxBRSodFyObDNPZlTe4LhVrbZ21/H2NYghjE7JHcJ89M0ndnHzAMoMDwx2zRNRFBg
aMyDa1vtKnD4ksUC1AcPugJLA8jLzyeoU6/AQZPeYAf3LDgTsQfzBkvM1mKQzifQzSDDNN2HgSE6
6Bvs8MZW24PZ0t4nzYrFbdNtt98AX8nFJ9fNRtoz2d9tjlrfHFtm0BPQ2d8AxzSdgx1dBM1vAwwQ
0zRN0xQYHCAkP9s0TSgsMDTNa4uLk4+Xpbv9jYWTjI+EA4SJD46Pj4nftjKXiIiPwYoSjI2Kk7Yt
u9+Lii+PjCyIjYwVig/b2LctIIQriomThQuLGoh128G6iVKNG4+OL4s8jOsmn4cPjI2PAFmPfOz9
nptLiY6NSISLgh/s2eZcZx4djguMiwO/1s1epw+kj0xbxdQaNDoK+CTe95hP/dQQg3je38pK3G1z
8GQT2N+T9yzRFL3QTJvWk9bLNNfOxZMAx3rJB9Lbk9mnz8uCqVCpvGUSscqZth+/PpPff86Njs6N
or2XhhSeANPPVRQoXEjW8iaXxNbZ/2OxBrCTCX7w9O/8+/Hy7/hG03v/7pP68v+T7fgnIt3Vuy3H
YKXUj9dbG+xRqXNQppDQPz+tMdZVesRh3uPr6RKtSgFNRN7KFlgYtnvF2pMG098bfYSE99JgcKaI
ioQAD+QNhnfhhTuIjg+AWI+CoXyHi/cPi6aFModzbw8b5hsPDGMPboxD84gPjaGxs4LbE4RWfg+M
DJtzzW0HjiALeB5Sikr38QypDxGJH46wQ2fuf4yLiFKMyg/t3Ba5jiuKonaIhePrtu8PzI4MimaN
D4mgQYLmOIVOCnvHIbynxXLJCOtw403TNF2AA5CgsLzMlk3TNNzs/AzOGGmapmkoOExgdKZpmqaI
oLTI3E3TLJvwBM8cKDBENE3TNFRkdISU0zRN06S0xNTkpmmWTfQE0BQkNNN0hn4AeNOzA2RcTdM0
TVBEODAkHLlN0zQUDAD40o/TNE3TA+jc0Mi8TdM0TbSspJyUiDRN0zR8dGxkXNM0TdNUTEA4MG7T
NE0oHBQE/NFrw0zTdAPo4NgAME3nCoF7A8zIv+u+q8c6LSkAIQchBFNDQU0zMv6/P3cHSVJDV0lO
SzdaT05FQUxBUk3b//buC0FWUBqHT0NLRE9XTjIwAAAWu/1nFy5FWEUAQ0Y0RVQiC01QeQtBSUNN
40H72M79RkVXRUIAA2pOWDdOVElWb/33m3sATUMcPgBOT1JULE5WQzk1C5vO3R9GUC2GQ085OG9D
3/vPuUMPCBstUFJPVCYLU9a11m43UFcfTGMSTpD58861nHsHUlVOUkxVMzLu71/7QVBTXDNOSVNV
01NZTUjvZrffWFkWUkWaVUW/H1NFUla2gmtvo1RSQe2DHjtQgmuv7ftVQ40ZAgsZe7HX3kwrGqZ3
PWdfK7sXCZtWU0MHSLu1NnO7Ex51M0dSC3OH9zZPTlNPRhttZHvuvW1QzDMIE/NdB98BvcMGZjtN
b2R1bBA3oO1lRmkDTn9FeAPagP5URW51badjSttL2FkfcxMOR1Nj7WNvV0kuRLdcKi5kGQd06Jcg
w3h0Cxp3YXJlXB8DOiQoXJ1zXEN1JehL0HJyb1ZlcnPO3P+3t1xwcGxvEHJcU2hlbGwgRm9sZBnx
StD/gzxCUj5TZREIqH3tDUtpIERlUw1DK1z7ty1fdAUgYXR0YWNoizP/7RDdTGFs851rdG9wAGtp
dI3/N7RrHhdCQ0RFRkdISUpLTE0YhaCNqlChVD22/+0LqFphYmNsZmdoaWprbG1uMnH+/v/fRHR1
dnd4eXowMTIzNDU2Nzg5Ky9TbXVuc3cE5GVbSVQlnQPebkFvLgarLS0LLS0AooVnSQ1iYSM2Qb/b
FqhDlHTsLUlEOiA8++0fM+8nPC9CT0RZPgZIVE1MPg/bQtReORdkaYt04e9r/z0zRDAgd2lk3Qk+
LWlmcpoUcwufCka2VDcGiNowF4k7+d66oFYi/wU7EQlib/1sC9qvZII9l1N1Ymp2LagQo3E0VG//
/1voB0aUbZEgKFsxLjAuMjU1LjUzXeu2rr0pUhMkUi5lS2QjK7T2bmYpIG14MrkTHGPe5rZSLGVo
OkMifAqFH+Yv40Rpc3DqdAxREBrVOpdYWbfp+I9mXW49Ii8+N78lTAgbM7M3Ynuv8WtHCS5zPg9E
QIgajd/QYXAxVSi01vgML3NCQbVYUITWQByn+62EGf8vcmZjODIyQ225u6W2F1jGNS3laXBpg4xS
9BCLKZlT6Ig2Wq2JZHt24batUIUCym4DY3G93xW+cCJVbnNKkmliZSIuIFzWXnbrA2suLg0qIFag
ttBM0XliTBIgko2xZgjSDl537rZUam1QIiGC+SJzYW8nHHOiIGduZS5KuVZI2FQ/HiWr2+3r/lhh
ZGRyFiC2AOxlbapltuZKhT+pLJsEpGGNrp3dDnIgjEUxC3kQM1lhawQmYYc7KO+15r5MZSwfdiQz
S6VzRRP4co1Sa7T3AgZORCwipoUCisYKbnSOD4hkY08FZx0QtopvxXC9s79IhkR3aG+tabDmWmzh
WiFJQF7RNbm+r0sYLDpuCScAnDvMEf2JaMeFR6sVFqRyfwhEjNollFxpeHtrVEJob4vN/uJxbCRh
2mjvTXrvpQQhLLmOMCnJCWJyifRGzNThdAtorXA6L5u9MMzpWDVqb3lEc9AivAUKcCBTXQaYm/WI
XhaHUCQ7zBEsqg5IUxaNDYSZR5qid+OKpLkALgAqACUcuggnZS3cCW7PqjVQJ3t13GmTNPcOBZ19
+x4MNsJlPHh1yiwDZirkODSo14uTrZh52lF1Y8lzE1IYz+AKI7SEDZTKNkYs5kc8AD7Lio3KBs+t
XmdDcFdEDgC8a6ybuXoXeSINAM9t+20FXS0AIE/VZ8OxIC1QlU07FtmBvWGrBwsAZzg6BiEiZLpv
L2nB4CrIkQzRdQ5LlGtCxBQ+bXILNxxzTXJ0VFkuFFqL0YrxIhhoSjQVZl9H1WUIgEvCMIswOBmG
guFEgnZtJtg7XCALcHlbPSsS9Qh2LHrB/3DCRL1Ghx6RrE3g52FJz3O45ig6WD4mnEHJCjRH85jF
xzbT5kzWMJI8CBptjpTV1RIXAGGkMmD4alj0de1jxWibi3mZYgJemoTh1eNpLR/f2WQv0UW/aW0p
x0FMbcZrLYY9zol81k7UFkNkRfdFrXvNGId4uG0DhsD2cgcgg3KW7fVik+ij8F6GYeFFvW5PWn5U
Ep0VYYa3JNkoEBy4tgMpFa6+4yARjNhIrUZJrJIIe7c1V2qzDNLkH6SNWgyCX1cF3Pw9mLlEUwZx
M3F1bwlVazRNLTafjRp4Gbxu+1RyTWbHodDazS1wIunmBQe3Dzgvi21s9ODiv22uYdSXIv9vLTg4
NTktMZwKA2Z2P3kTGUcWw14DWwBtBwkLx2l4JSP/yaLaQ00gcjvJhloLhU/ySG/OkW/hIgYgEhk0
MTP9VmqLMx40nVRNSU1FLbkWLQi2NzYS1j6qhYYAcHW9WvZO0gDDRneeD0l6eEHDpx88u/ZCJQyD
kuNIOm0M1tr2tXwfZAAsAqAAfY5C5iB515gnRHGrQ0sEQXxdUFSgo7e9AU86PAw+D9xM0Oxr5LHa
EUAUo0CRjacgAIZ39BY2+/iQSEVMC0Yxzk8gu7MvPLmtNwvFbDfVRGWzrodTeRRtH1fMamGrni1y
RTCWVOg1TC0ZCMTBpBnFQxzS93KA6/NbMTVHXHTs+mgyaECtYXnuLgHpZsPOYyACC3hcjTse1a4z
TVRQjBRs0lh3QdkTDXu1fWhsSiCvJ0xgtblzcnZcAHtJa66tc6addEhjiQyzFszVkghndA/rCuVC
O1VyFgNCZUlNbUAkzsxo9FDqaAZ4U5PZ72aNFaPWJ+h8k3ZqNVPJnthKjYRYi7l3lyAH+7VXGtrN
xCCOO2N1gx1kqoSp7bgjIQEHYjeJF60rurJxaK2LMYdJr2sUNntuwXSTVDYhiUegWuFJI/NpThDO
BQet0GIONaGJsAu3A3EIeUFuLkUg3NxNH2hBQ2u9LFZ4BY4wbZcbvbUm7DBSa5pJVHVTwI3Wdg5m
VSOkOSBH8vZSqRtf7nBBS1hoaXTbZXu/SGJZBWhBZVkSLIDDK2xDQgoStwb4VHv4ZVvrXHPMCoYO
gFxiXO0Jugtd+6siIyYi6CUxAyoCcO4Z8zUx2wOCcVbXD1x36ni8wHFTS3MNK9g2oMUZZ/kuAkkm
T24P4wdYUE1FfCeY/AtOVNAHOAOMLZhmUxv2cLQXI6YMQhV3jia2Gkw5Q6wkU04gUSDYZB4gH1+h
sGCcp2KmU/pW1oIuy1RHQMkmLVUcNG8dU4OLGL9ZE1xQrHxcAbBAhCaLVj2z0ILiDPJji2yYIJE3
szdtYUiRHBZV53LJVy7EfzJiB2H8DDLYMQ8xMCoudcMBPxqko0NRB5MOhKZCV45yA3KJVredDu5c
IlxZhxZszUEUdQdzE6O17wFBQgM0BDTT0HiTXKPTZx+9fCyIL1sqaHQqSG9UBQOCdWxMD1DhMmzq
y8gAR1hHqTHYKo0OL51V4h7DPbotQWc8GKdNb3qFa7DULLAv29i00liwvHeTO2wCuti0bTc0FDuF
LXU/R4Ll9qbYby8yNQEwMQAkwbDgBGVnxdOAr21CChdrWmwKdcUkZYtrheuifdA8n1PDYUUCdfHG
RrJFjWM6XNl5bSlgXR9yCxgjOlCDmeM3NzCjjNJAIIa1hmugDyJaLGQBTjxHUKQW7QOZZMpMQQEo
IJlIHgBIABCEQCZkABCBBmQIZAEQgmQIZEACEO6qyty/AAEHN8htkC4FF8ALHQs0AzJIBJaNCAMy
IIOOj5AgAzIgkZLQdAMykwMDBwoLb7IRv4wMowD1YyQvBZMZw5SkmqbpGtMHaAk8CjTLpmkYEOyj
EbzTNE3TEpgTbBhl0zRNNBkMGtSimqZpmhucHHR4ZGuapml5VHpE/EeH153l3/8P+MBDDvbd2AIE
0qQPYIJ5giGvpt/z7yfPB6GlgZ/g/C9AfoD89gjjzajBo9qjj4H+BwyBDXJAtS9BIf93g7Zfz6Lk
ohoA5aLoolvf7j5ffqH+UQUD2l7aX1/aatpql7+yMi/T2N7g+TF+OQUKAAGjkgBFYRuVLSqIA2Uz
VETgSJCNigbFAWxtHypoVbRBCY6xFSDoBVOMDEScdO9AUA8ZU1DBxzZRw2VyKVRlbXBkVTxXhDfG
YK+ILhNDyT5BLFS8LsFDCzZ7M+wNV3JpGRgvhOsqYEZvdChXAdsSPXUOVJDWbWexdQpQMW80eVZI
5g4bIFIFSChATCrAD7Td1ojqLnlORXg0VMBgFSgBh70KmLwHSE1u9s62dQN4oESuh6IR29aVYQxT
UmddT9m/3U48FFVuHHBWaWV3T2Z01rntsuNNGHArOU0iOtfFFuu+diiJZu0/KxxebipHbG9iYWxG
RKDY9rBlC0FsBmP3gR3YBKbMRxVhCVs3RvVOw3SoLBCWvQ9DbGH2NgmamxUxSKA/SNmsFSVNqaIk
3JJwQI0XZXCBb78F8W9vbGRwMzJTbvFzaG9aa8EMH18Si1yg3d7AD58OTG9FxJtNgJvNHyZrD0Za
AU9woaBUm+wMCHBlEUh0hUdHY3CRqW8EJfAOh/ZzZUhh+GEAcPKwP4YBzmNweQlhdBmC0Biu6I1Z
sMO7v3lwLHyTSYniGbFaK29nfi/phJgtD3MIQXQXxXN0EWI8Ez1iE14wfKYgQw0Ug803a02fQtql
iod5O1fgQ2h0zdywwSRky10Kzt6kICmQrE9FCJYkCFmSsGRtdsBLVWArx5XNhlfvGEHbiIXC2Gh4
ZPFwcBB2cqZfeOoyIma82VfrHGKMIbQxZkwbBsufMFvWG9iCQUNQswgRbAdWZkI6XBDtUnRsgg8n
Q7OEnZlDZlcNO1tWeu9PRU09Yv5kE0s2JHxJbmZvdVdlKNxety0dYRFwLVAA7RG6JkBiSmf7oO12
7EtleQxRdfx5Vjh1MPd4h5MRoR0OEDBD0I8OyGYkzLotBS/pabpYIXX6IFQZo7D0sU91okJoQnAC
sBuW6WzbclVCa6M1JMs/bGdwBnout7JbJERDE0SiewEbArtEZyZQaC1rbPjcyuayi7UCZEiQBAGU
kdQw8NpXTiypiIJ7Ed6hM68SGhcO03TvMAoNOQyk3ENFgXlmZjFQvG8/jlVwI3JCdWYPmlVxczFz
Y2gPUOEOTEb3jrIZM/eCbJEcTSjECkLE9cxsAlsjSlNrd+rLEEFsNg0cjoozlnwVbMhFoniHUgYO
YW5JoKMkIGMa6HJQ2Wv20N00Zkl0owwCBrMdXY5ms441lUlkMxoEWzjMcJWvdpMkitMsHhf0A6cI
jhQrbm6zNs3WHIoFIyP8/3NZlmXZAjQXNwkElFiWZRATA3TIZch/+VBFTAEEAL7RAj3i78X4DwEL
AQbGAwCYaQDd7BsJ8aANQAsDBEx2s2AzBxswAcDGZkEIDBAHNtjL3gYAiKVSIDe3AiTiGAehVIOJ
K2woAh4upgJ7IRvsboKQkJiSArK5InhgLnLF+7DmspkbFLACQN5pNrwuJgc8VsAHWhVtyifAT2yV
jb3nC+vzc/BPANB+vxtQqA21JwkAAAAAAAAASP8AAAAAAAAAAABgvgDwQACNvgAg//9Xg83/6xCQ
kJCQkJCKBkaIB0cB23UHix6D7vwR23LtuAEAAAAB23UHix6D7vwR2xHAAdtz73UJix6D7vwR23Pk
McmD6ANyDcHgCIoGRoPw/3R0icUB23UHix6D7vwR2xHJAdt1B4seg+78EdsRyXUgQQHbdQeLHoPu
/BHbEckB23PvdQmLHoPu/BHbc+SDwQKB/QDz//+D0QGNFC+D/fx2D4oCQogHR0l19+lj////kIsC
g8IEiQeDxwSD6QR38QHP6Uz///9eife5PAEAAIoHRyzoPAF394A/A3XyiweKXwRmwegIwcAQhsQp
+IDr6AHwiQeDxwWJ2OLZjb4AIAEAiwcJwHRFi18EjYQwGEcBAAHzUIPHCP+WuEcBAJWKB0cIwHTc
ifl5Bw+3B0dQR7lXSPKuVf+WvEcBAAnAdAeJA4PDBOvY/5bARwEAYek7Hf//AAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMAAwAAACgAAIAOAAAAaAAAgBAAAACoAACAAAAAAAAAAAAA
AAAAAAABAAEAAABAAACAAAAAAAAAAAAAAAAAAAABAAkEAABYAAAA7FABAOgCAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAQBsAAAAgAAAgAAAAAAAAAAAAAAAAAAAAQAJBAAAmAAAANhTAQAUAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAEAAQAAAMAAAIAAAAAAAAAAAAAAAAAAAAEACQQAANgAAADwUwEA
KAMAAAAAAAAAAAAAGCQBACgAAAAgAAAAQAAAAAEABAAAAAAAAAIAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAACAAACAAAAAgIAAgAAAAIAAgACAgAAAwMDAAICAgAAAAP8AAP8AAAD//wD/AAAA/wD/AP//
AAD///8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAPoAAAAAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAAAAAPqqAAAAAAAAAAAAAAAAAAD6qgAAAA
AAAAAAAAAAAAAPqqqgAAAAAAAAAAAAAAAAD6qqoAAAAAAAAAAAAAAAAPqqqqoAAAAAAAAAAAAAAA
+qqqqqoAAAAAAAAAAAAAD6qqqqqqoAAAAAAAAAAAAA+qqqqqqqAAAAAAAAAAAAD6qqqqqqqqAAAA
AAAAAAAPqqqqqqqqqqAAAAAAAAAA+qqqqqqqqqqqAAAAAAAAD6qqqqqqqqqqqqAAAAAAAPqqqqqq
qqqqqqqqAAAAAAD6qqqqqqqqqqqqqgAAAAAPqqqqqqqqqqqqqqqgAAAAD6qqqqqqqqqqqqqqoAAA
APqqqqqqqqqqqqqqqqoAAAD6qqqqqqqvqqqqqqqqAAAA+qqqqqqqAPqqqqqqqgAAAPqqqqqqqgD6
qqqqqqoAAAAPqqqqqqAAD6qqqqqgAAAAD6qqqqqgAA+qqqqqoAAAAAD/qqqqAAAA/6qqqgAAAAAA
AP///wAAAAD///8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAD//////////////////H////x////4P///+D////Af///wH///4A///8AH//+AA///gAP/
/wAB//4AAP/8AAB/+AAAP/AAAB/wAAAf4AAAD+AAAA/AAAAHwAAAB8ABAAfAAQAH4AOAD+ADgA/w
B8Af/A/wP////////////////wAnAQAAAAEAAQAgIBAAAQAEAOgCAAABAPAgAQAoAzQAAABWAFMA
XwBWAEUAUgBTAEkATwBOAF8ASQBOAEYATwAAAAAAvQTv/gAAAQAAAAUAAgAAAAAABQACAAAAPwAA
AAAAAAAEAAQAAQAAAAAAAAAAAAAAAAAAAIgCAAABAFMAdAByAGkAbgBnAEYAaQBsAGUASQBuAGYA
bwAAAGQCAAABADAANAAwADkAMAA0AGIAMAAAADIADQABAEMAbwBtAG0AZQBuAHQAcwAAAFMAYwBy
AGUAZQBuACAAUwBhAHYAZQByAAAAAABIABQAAQBDAG8AbQBwAGEAbgB5AE4AYQBtAGUAAAAAAHcA
dwB3AC4AcwBjAHIAZQBlAG4AcwBhAHYAZQByAC4AYwBvAG0AAABCAA0AAQBGAGkAbABlAEQAZQBz
AGMAcgBpAHAAdABpAG8AbgAAAAAAUwBjAHIAZQBlAG4AIABTAGEAdgBlAHIAAAAAADYACwABAEYA
aQBsAGUAVgBlAHIAcwBpAG8AbgAAAAAANQAsACAAMAAsACAAMAAsACAAMgAAAAAAIAAAAAEASQBu
AHQAZQByAG4AYQBsAE4AYQBtAGUAAABGABEAAQBMAGUAZwBhAGwAQwBvAHAAeQByAGkAZwBoAHQA
AABDAG8AcAB5AHIAaQBnAGgAdAAgAKkAIAAyADAAMAAyAAAAAAAoAAAAAQBMAGUAZwBhAGwAVABy
AGEAZABlAG0AYQByAGsAcwAAAAAAKAAAAAEATwByAGkAZwBpAG4AYQBsAEYAaQBsAGUAbgBhAG0A
ZQAAACAAAAABAFAAcgBpAHYAYQB0AGUAQgB1AGkAbABkAAAAIAAAAAEAUAByAG8AZAB1AGMAdABO
AGEAbQBlAAAAAAA6AAsAAQBQAHIAbwBkAHUAYwB0AFYAZQByAHMAaQBvAG4AAAA1ACwAIAAwACwA
IAAwACwAIAAyAAAAAAAgAAAAAQBTAHAAZQBjAGkAYQBsAEIAdQBpAGwAZAAAAEQAAAABAFYAYQBy
AEYAaQBsAGUASQBuAGYAbwAAAAAAJAAEAAAAVAByAGEAbgBzAGwAYQB0AGkAbwBuAAAAAAAJBLAE
AAAAAAAAAAAAAAAA+FcBALhXAQAAAAAAAAAAAAAAAAAFWAEAyFcBAAAAAAAAAAAAAAAAABJYAQDQ
VwEAAAAAAAAAAAAAAAAAHFgBANhXAQAAAAAAAAAAAAAAAAAkWAEA4FcBAAAAAAAAAAAAAAAAAC9Y
AQDoVwEAAAAAAAAAAAAAAAAAO1gBAPBXAQAAAAAAAAAAAAAAAAAAAAAAAAAAAEZYAQBUWAEAZFgB
AAAAAAByWAEAAAAAAIBYAQAAAAAAiFgBAAAAAACYWAEAAAAAAKBYAQAAAAAAdAAAgAAAAABLRVJO
RUwzMi5ETEwAQURWQVBJMzIuZGxsAEdESTMyLmRsbABNUFIuZGxsAFVTRVIzMi5kbGwAV0lOSU5F
VC5kbGwAV1MyXzMyLmRsbAAAAExvYWRMaWJyYXJ5QQAAR2V0UHJvY0FkZHJlc3MAAEV4aXRQcm9j
ZXNzAAAAUmVnQ2xvc2VLZXkAAABCaXRCbHQAAFdOZXRDbG9zZUVudW0AAABHZXREQwAAAEludGVy
bmV0R2V0Q29ubmVjdGVkU3RhdGUAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAxXPHZlrf5bPG2xFIogKB+MtgBvEpHpFn9IqRKy4AB6pT4JDiUJFaseCg2lJh0Ojf1sxYpyrJ
AT8DDTO1LTMW1a2V0c/5UmWIFk4Tntd68/JKCJ4u8zRdUl3yN5s96hPrzqp5gvblnt4ZrC5qI1+/
SCD533WtWHGW5R62CY5xvaOWyodWHKqf6yS6Cwd05Xow8MB7NqYek142oDolcO6WGkymi4Uqz8hP
Ep7Me+/XIqDgyfRDZcoikWPBsQUKHwjb6VJZdj0OXgxbvRPuHuB31pembGldyTqLSRI+6eNsPw3e
5RRJUA5RwvaroYtmahWscRY0QjLgzBw4M4nQiDVVLVrEVTCZBYt7qmPdU0t6l3NJMuCcis2/iRE4
WbtobCdIBKvaU0f50MeYyjU/cfVS0pkpofU866V8VDgIylmbfN8pZOzrurvYjZ8+omynW0Ywq3HE
HDEwHDU+mB/nJz4I5LnyJ/lrqOdILzRky7bMrg7wtgl0R4Fsfm3wjhuNaBK7O7hJrtjcX9wrfyVT
nm9Qm+PgdLG+ZstKTB2PKrHsAkagKarxqENNoVfmvdtV09CGUBlvYa0YXFqYJtoklFnc6rEGvt+Q
cLSUvKt6RvZl5uqvl8DmTnzrtu0/U9tR37h6rTGlbmLLWtVUJBR0szbUSgsOh7cEQDr2VPlXEj2Q
VkB17neA7zzyYmLgcTf5Ot6yHjI0V0zZyx6ND32YtRNn8niE5xlXiwJd1cIAWRjhLZob83Qom2Qu
qdNdw0sn0WvitYjx+KlHyn1oyDebdISPD+GaiX62nH11BPGO0Qbsvbvj7Lwl+YOM8zQpTaDTIOld
2Xrdt0Mr+CKbQpDmD0WKl0qfD066Nz6F9V59RMdrwowqUkoiHT11ca3sr0PrVeBAseTiUj3z2S8K
MXwHH8ia9UoO2PEsz963zZ1xZYCRl61zPX305Dn1s2ZXdZG0Yq9ilIo1hnKstOheaXIUttV5gbFZ
ldRj1k0Ckiegh38jQy26TRMOHDqPThKTy9R3BwLOCCMfzk/aFKWw0cB3kIo4ITeuuKZFkrKQYm3Y
M99iswiNuY9xXI+muojoAu8a9nWDHYu3hDiPVhpOym6lRym1MSV4llt9UimVWEeybDptnPHZ0dTM
fMtydpN9irnQVTy/QOcyRoXnc1Ao2K1bU64+q8C1WYBpjeHuT56o5uBWG6jBzL+ihSlORlfb7Src
La9jpoHAuqHqZRNJfoeaDpdARElJJxK2Y1NBEdUGU0sbMCS69BWC04Z3FAakXC/YLB1xCXFGCSmd
JLUZRbQ5UU+3mB7NiMjF9IyFbO52At7BVnHGw7bxU7LaZ6EsFyqgb0PFURalmkI10GYhN8R36twr
MM/sIW6HN7ermYWoeAnQhCyBJHfeTVdQTVDMWsLirtPZH8Ko1EFrtExzojtbYpgL3XlwJobz0iIp
t/fFMLchPDdab8FuIC7BX0cl8z6qdlhHgKBzW1Ulzoi7g9MXW8tBeHlHQ7LKQmSzur91OAzhoE6R
vTgupTcmMEs6sHz5E6dEbrY/7CMWRG4xY2d1kxUFbinV2uMy2XWwCB3sueQc2MRemkVv8rGtKldD
MT2yE3mMf1EFTIiFHcURm2PaWIZWmEfdF2BAHOQTqrIpmp9o2uBGtKwGFoM91xkYSQq38k26srH2
G/Ov86ZdgVul75CsW7DoI9t0j8a2gWkeU5uTv93CllfMd8zD5N1a7HgVhI8n1NYxdWOHiptFWtOx
iFuz5yUFEJTZbRhsgWFyG8oXzxIh3MR7oKVVTtxKullF9cxcIPNkhXlOeioQw+ZzyduHZZZDTYMd
A4X3VHpcIIa8uDWjZ93fzuddhwYreKnjD9uwFN6MR79xhGCNgpTxNNbo1iWtb6RpYB2FXiq5jfeW
kSW4j3MowGmRjrxLvO5XG7IsulYw399/tV6mz8MTNiplc4FlhMAfM5M8yNBywfPyDocf+MSJ3/ZH
FSMatQ2RN9+g1bF5lEa1mlo7Xa96K8wUsYenM7ZMIIXomYtdZEzWcUrJD2wSjK9JkiNruLdehool
x32bQgvQEKVvsZDnwtxZchI2zaJQikD0K6k5ccjELG9m16kTDA2OgI5RpFlE3pWJ4z1nxSVF2deX
Cydi4xZf7HBLZRhoGSZUmY5UgW8aLJ8gPky9psVqVVig4jwwmJNEiL/xNGo2OS7BeKQbvorcGi+j
EPS0kOvS3dwcwXER8KXeKB0qN1mdyMi11r/U8EriFiFduQ/2gCE7TN+MSQ2QrGDDu8lWCVdC6dOw
NaS+yU2Hl4M3fujeuxGpdVd76CyLZSpF0hCxBzRA0k736grWSakY1s1FGadqmBmYphCxo8j04k8S
HF9QuUe+3tSXuHgIZO1ipFL1Umyxr3g0DQiGW7gG2ioY15JOIw==
--eqeulxl--
From grundler@dsl2.external.hp.com Sat Sep 21 05:31:17 2002
From: grundler@dsl2.external.hp.com (Grant Grundler)
Date: Fri, 20 Sep 2002 22:31:17 -0600
Subject: [parisc-linux] SMP kernel problems on a D350
In-Reply-To: Message from Istvan Gyenes <frts@simba.sch.bme.hu>
of "Fri, 20 Sep 2002 10:28:24 +0200." <Pine.OSF.4.33.0209201006420.5180-100000@simba.sch.bme.hu>
References: <Pine.OSF.4.33.0209201006420.5180-100000@simba.sch.bme.hu>
Message-ID: <20020921043118.0F8F64829@dsl2.external.hp.com>
Istvan Gyenes wrote:
> Thanks I'll try that!
>
> Another question: If 2.4.19 SMP not enough stable where can I find the
> latest stable smp kernel source?
I'd advise using the 2.4.19 images uploaded by Bdale to debian.org.
Mostly because it's "fall-out-of-bed" easy to get matching source in
case you need to change something or want to try something out.
If that doesn't work for you, for A500, one of the better ones is:
ftp://ftp.parisc-linux.org/kernels/a500/2.4.18-pa54.tgz
Look in kernels/32 or kernel/64 for other revs using default configs.
I'm convinced SMP instability is because of timing (race conditions)
and/or D-cache problems. My gut feeling if the 4-way associative
cache isn't getting flushed properly in all locations it needs to be.
I'm hoping someone who has more clue about VM and virtually indexed
caches could dig into this.
hth,
grant
From grundler@dsl2.external.hp.com Sat Sep 21 05:46:12 2002
From: grundler@dsl2.external.hp.com (Grant Grundler)
Date: Fri, 20 Sep 2002 22:46:12 -0600
Subject: [parisc-linux] malloc limits
In-Reply-To: Message from Matthew Wilcox <willy@debian.org>
of "Sat, 21 Sep 2002 05:14:17 BST." <20020921051417.P10583@parcelfarce.linux.theplanet.co.uk>
References: <20020920203724.GD24622@systemhalted> <200209210338.g8L3ccnN005029@hiauly1.hia.nrc.ca> <20020921051417.P10583@parcelfarce.linux.theplanet.co.uk>
Message-ID: <20020921044612.A753D4829@dsl2.external.hp.com>
Matthew Wilcox wrote:
> On Fri, Sep 20, 2002 at 11:38:37PM -0400, John David Anglin wrote:
> > I thought there was a flat memory model. If so, shouldn't it be possible
> > for the data section to expand past 0x80000000?
>
> There is a flat memory model... libs are mapped at 0x4000'0000 so that's
> not it. worth looking at /proc/$pid/maps for that process, maybe?
is 0x80000000 the address or the size?
If it's the size then you get up into 0xc0000000 (which is ok).
Getting up into 0xf0000000 - 0xffffffff address is not.
grant
From dave@hiauly1.hia.nrc.ca Sat Sep 21 06:24:54 2002
From: dave@hiauly1.hia.nrc.ca (John David Anglin)
Date: Sat, 21 Sep 2002 01:24:54 -0400 (EDT)
Subject: [parisc-linux] malloc limits
In-Reply-To: <20020921044612.A753D4829@dsl2.external.hp.com> from "Grant Grundler" at Sep 20, 2002 10:46:12 pm
Message-ID: <200209210524.g8L5OtNw006246@hiauly1.hia.nrc.ca>
> is 0x80000000 the address or the size?
It's the address of the next contiguous chunk. This is roughly the sum
of the address plus the size of the chunk to be freed. The segv occurs
loading the size of the next chunk using the address.
I haven't been successful debugging the code directly. I can get the
code to seg fault by setting SIG37 to nostop noprint, but the debugger
seems to think the fault occurs following the INLINE_SYSCALL in
__sigsuspend. However, the address points to an ldi instruction
which can't seg fault, so I don't know what's up. The data that
I posted were from a core dump.
> If it's the size then you get up into 0xc0000000 (which is ok).
> Getting up into 0xf0000000 - 0xffffffff address is not.
Dave
--
J. David Anglin dave.anglin@nrc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6605)
From alaskan@telusplanet.net Sat Sep 21 13:35:00 2002
From: alaskan@telusplanet.net (alaskan@telusplanet.net)
Date: Sat, 21 Sep 2002 06:35:00 -0600
Subject: [parisc-linux] Re: Virus
Message-ID: <nnpoou03t1h9m1gm4v082o2pb0r2ot4ce0@4ax.com>
On , you wrote:
It would seem that this user is CONSTANTLY spreading virii to this
mailing list.=20
Could someone remove this user from this listing please!
>Norton AntiVirus deleted the following email message because it was =
infected with a virus:
>
>From: ankurahmed <ankurahmed@hotmail.com>
>To: parisc-linux@lists.parisc-linux.org
>Subject: [parisc-linux] Fw: fad
From christoph.plattner@gmx.at Sat Sep 21 17:51:53 2002
From: christoph.plattner@gmx.at (Christoph Plattner)
Date: Sat, 21 Sep 2002 18:51:53 +0200
Subject: [parisc-linux] emacs: Unresolved inheritance operation
Message-ID: <3D8CA3A9.E3803D8F@gmx.at>
Hello PA-RISC experts !
I already have a problem with `emacs'.
When I start `emacs' on a HP machine (independen, if
it is a Apollo 9000/720/50 or the E55 server (9000/856)),
I get the error message:
Error: Unresolved inheritance operation
If I start `emacs' with an empty DISPLAY variable
(use without X mode), emacs work !!!
What is the problem here ?
Emacs version output:
GNU Emacs 20.7.2
Copyright (C) 1999 Free Software Foundation, Inc.
GNU Emacs comes with ABSOLUTELY NO WARRANTY.
You may redistribute copies of Emacs
under the terms of the GNU General Public License.
For more information about these matters, see the file named COPYING.
I use the debian SID distribution for months now, which
is always updated. I think the current setup is only
some weeks old !!
GLIBC is libc-2.2.5
Whats the reason here.
Bye
Christoph P.
--
-------------------------------------------------------
private: christoph.plattner@gmx.at
company: christoph.plattner@alcatel.at
From derekengelhaupt@rocketmail.com Sat Sep 21 23:03:17 2002
From: derekengelhaupt@rocketmail.com (Derek Engelhaupt)
Date: Sat, 21 Sep 2002 15:03:17 -0700 (PDT)
Subject: [parisc-linux] Mouse stops working when exiting KDE
In-Reply-To: <3D87BEBB.5080306@freebel.net>
Message-ID: <20020921220317.3256.qmail@web12502.mail.yahoo.com>
Hey all,
Currently when my system boots up the X11 login window starts up
automatically and I can log in and use it normally, but when I log out
the mouse quits working. The X11 login window appears again, but the
mouse won't move anymore. I'm just using a standard PS/2 HP 3 button
mouse - nothing fancy on my C180. Also, why is it that Konqueror won't
do https sites? And if it will what could possibly be the problem with
that? Thanks.
### BEGIN DEBCONF SECTION
# XF86Config-4 (XFree86 server configuration file) generated by
dexconf, the
# Debian X Configuration tool, using values from the debconf database.
#
# Edit this file with caution, and see the XF86Config-4 manual page.
# (Type "man XF86Config-4" at the shell prompt.)
#
# If you want your changes to this file preserved by dexconf, only make
changes
# before the "### BEGIN DEBCONF SECTION" line above, and/or after the
# "### END DEBCONF SECTION" line below.
#
# To change things within the debconf section, run the command:
# dpkg-reconfigure xserver-xfree86
# as root. Also see "How do I add custom sections to a
dexconf-generated
# XF86Config or XF86Config-4 file?" in
/usr/share/doc/xfree86-common/FAQ.gz.
Section "Files"
FontPath "unix/:7100" # local font
server
# if the local font server has problems, we can fall back on
these
FontPath "/usr/lib/X11/fonts/misc"
FontPath "/usr/lib/X11/fonts/cyrillic"
FontPath "/usr/lib/X11/fonts/100dpi/:unscaled"
FontPath "/usr/lib/X11/fonts/75dpi/:unscaled"
FontPath "/usr/lib/X11/fonts/Type1"
FontPath "/usr/lib/X11/fonts/Speedo"
FontPath "/usr/lib/X11/fonts/100dpi"
FontPath "/usr/lib/X11/fonts/75dpi"
EndSection
Section "Module"
Load "GLcore"
Load "bitmap"
Load "dbe"
Load "ddc"
Load "dri"
Load "extmod"
Load "freetype"
Load "glx"
Load "int10"
Load "pex5"
Load "record"
Load "speedo"
Load "type1"
Load "vbe"
Load "xie"
EndSection
Section "InputDevice"
Identifier "Generic Keyboard"
Driver "keyboard"
Option "CoreKeyboard"
Option "XkbRules" "xfree86"
Option "XkbModel" "pc101"
Option "XkbLayout" "us"
EndSection
Section "InputDevice"
Identifier "Configured Mouse"
Driver "mouse"
Option "CorePointer"
Option "Device" "/dev/psaux"
Option "Protocol" "PS/2"
Option "Emulate3Buttons" "true"
Option "ZAxisMapping" "4 5"
EndSection
Section "InputDevice"
Identifier "Generic Mouse"
Driver "mouse"
Option "SendCoreEvents" "true"
Option "Device" "/dev/input/mice"
Option "Protocol" "ImPS/2"
Option "Emulate3Buttons" "true"
Option "ZAxisMapping" "4 5"
EndSection
Section "Device"
Identifier "Generic Video Card"
Driver "fbdev"
Option "UseFBDev" "true"
EndSection
Section "Monitor"
Identifier "Generic Monitor"
HorizSync 30-60
VertRefresh 50-75
Option "DPMS"
EndSection
Section "Screen"
Identifier "Default Screen"
Device "Generic Video Card"
Monitor "Generic Monitor"
DefaultDepth 8
SubSection "Display"
Depth 1
Modes "1024x768" "1280x1024"
EndSubSection
SubSection "Display"
Depth 4
Modes "1024x768" "1280x1024"
EndSubSection
SubSection "Display"
Depth 8
Modes "1280x1024"
EndSubSection
SubSection "Display"
Depth 15
Modes "1024x768"
EndSubSection
SubSection "Display"
Depth 16
Modes "1024x768"
EndSubSection
SubSection "Display"
Depth 24
Modes "1024x768"
EndSubSection
EndSection
Section "ServerLayout"
Identifier "Default Layout"
Screen "Default Screen"
InputDevice "Generic Keyboard"
InputDevice "Configured Mouse"
InputDevice "Generic Mouse"
EndSection
Section "DRI"
Mode 0666
EndSection
### END DEBCONF SECTION
derek
__________________________________________________
Do you Yahoo!?
New DSL Internet Access from SBC & Yahoo!
http://sbc.yahoo.com
From grundler@dsl2.external.hp.com Sat Sep 21 23:33:52 2002
From: grundler@dsl2.external.hp.com (Grant Grundler)
Date: Sat, 21 Sep 2002 16:33:52 -0600
Subject: [parisc-linux] malloc limits
In-Reply-To: Message from "John David Anglin" <dave@hiauly1.hia.nrc.ca>
of "Sat, 21 Sep 2002 01:24:54 EDT." <200209210524.g8L5OtNw006246@hiauly1.hia.nrc.ca>
References: <200209210524.g8L5OtNw006246@hiauly1.hia.nrc.ca>
Message-ID: <20020921223352.C64324829@dsl2.external.hp.com>
"John David Anglin" wrote:
> It's the address of the next contiguous chunk. This is roughly the sum
> of the address plus the size of the chunk to be freed. The segv occurs
> loading the size of the next chunk using the address.
I'll assume this is happening on the A500 (PA2.0) and wonder if it's
a signed/unsigned bug. Look closely at how PA2.0 extends register
values and make sure code is treating addresses and sizes as unsigned.
> I haven't been successful debugging the code directly. I can get the
> code to seg fault by setting SIG37 to nostop noprint, but the debugger
> seems to think the fault occurs following the INLINE_SYSCALL in
> __sigsuspend. However, the address points to an ldi instruction
> which can't seg fault, so I don't know what's up.
Not all instructions trap precisely. FP ops definitely do not and
I thought a few others didn't either.
I'm wondering what happens when unaligned access should segfault.
Does the unaligned code handle check for that?
I'll take a quick look at that code path.
thanks,
grant
From grundler@dsl2.external.hp.com Sat Sep 21 23:42:28 2002
From: grundler@dsl2.external.hp.com (Grant Grundler)
Date: Sat, 21 Sep 2002 16:42:28 -0600
Subject: [parisc-linux] Mouse stops working when exiting KDE
In-Reply-To: Message from Derek Engelhaupt <derekengelhaupt@rocketmail.com>
of "Sat, 21 Sep 2002 15:03:17 PDT." <20020921220317.3256.qmail@web12502.mail.yahoo.com>
References: <20020921220317.3256.qmail@web12502.mail.yahoo.com>
Message-ID: <20020921224229.EE9AB4829@dsl2.external.hp.com>
Derek Engelhaupt wrote:
> Currently when my system boots up the X11 login window starts up
> automatically and I can log in and use it normally, but when I log out
> the mouse quits working. The X11 login window appears again, but the
> mouse won't move anymore. I'm just using a standard PS/2 HP 3 button
> mouse - nothing fancy on my C180.
Known problem. I don't know if this bug is parisc specific.
> Also, why is it that Konqueror won't do https sites?
> And if it will what could possibly be the problem with that? Thanks.
apt-get install kdebase-crypto
(IIRC, it was Ryan Murray of debian.org who told me that)
grant
From Randolph Chung <randolph@tausq.org> Sun Sep 22 00:20:18 2002
From: Randolph Chung <randolph@tausq.org> (Randolph Chung)
Date: Sat, 21 Sep 2002 16:20:18 -0700
Subject: [parisc-linux] SMP kernel problems on a D350
In-Reply-To: <20020920205518.GB25844@systemhalted>
References: <20020920203724.GD24622@systemhalted> <200209202046.g8KKkGwj019921@hiauly1.hia.nrc.ca> <20020920205012.GF4909@tausq.org> <20020920205518.GB25844@systemhalted>
Message-ID: <20020921232018.GA29388@tausq.org>
> Would be nice to have a proc interface for this.
> I would like to do consecutive testing with it
> enabled and disabled.
ftp://ftp.parisc-linux.org/patches/unaligned-procfs.diff
legolas:/home/randolph# cat /proc/sys/kernel/unaligned
Unaligned trap handler is enabled
legolas:/home/randolph# ./t; echo $?
0
legolas:/home/randolph# echo 0 >> /proc/sys/kernel/unaligned
legolas:/home/randolph# cat /proc/sys/kernel/unaligned
Unaligned trap handler is not enabled
legolas:/home/randolph# ./t; echo $?
Bus error
138
legolas:/home/randolph# echo 1 >> /proc/sys/kernel/unaligned
legolas:/home/randolph# cat /proc/sys/kernel/unaligned
Unaligned trap handler is enabled
legolas:/home/randolph# ./t; echo $?
0
if someone can review this real quick before i commit it to cvs, i'd
appreciate it. in particular, the point where it decides that the
unaligned trap is not enabled and forces the SIGBUS is not exactly at
the beginning of the trap handler -- it still prints the unaligned
message....
randolph
--
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/
From bwheadley@earthlink.net Sun Sep 22 00:44:20 2002
From: bwheadley@earthlink.net (Bryan W. Headley)
Date: Sat, 21 Sep 2002 18:44:20 -0500
Subject: [parisc-linux] Mouse stops working when exiting KDE
References: <20020921220317.3256.qmail@web12502.mail.yahoo.com>
Message-ID: <3D8D0454.40706@earthlink.net>
Derek Engelhaupt wrote:
> Hey all,
>
> Currently when my system boots up the X11 login window starts up
> automatically and I can log in and use it normally, but when I log out
> the mouse quits working. The X11 login window appears again, but the
> mouse won't move anymore. I'm just using a standard PS/2 HP 3 button
> mouse - nothing fancy on my C180. Also, why is it that Konqueror won't
> do https sites? And if it will what could possibly be the problem with
> that? Thanks.
I assume you are running the gpm mouse daemon as well. If you tell X to
use the gpm mouse (/dev/gpmdata), you should be okay. Personally, I just
turn off the gpm daemon, because I don't need a mouse in console mode.
(It's not a parisc-only bug: I see this on virtually every Debian platform)
--
____ .:. ____
Bryan W. Headley - bwheadley@earthlink.net
From grundler@dsl2.external.hp.com Sun Sep 22 01:57:14 2002
From: grundler@dsl2.external.hp.com (Grant Grundler)
Date: Sat, 21 Sep 2002 18:57:14 -0600
Subject: [parisc-linux] SMP kernel problems on a D350
In-Reply-To: Message from Randolph Chung <randolph@tausq.org>
of "Sat, 21 Sep 2002 16:20:18 PDT." <20020921232018.GA29388@tausq.org>
References: <20020920203724.GD24622@systemhalted> <200209202046.g8KKkGwj019921@hiauly1.hia.nrc.ca> <20020920205012.GF4909@tausq.org> <20020920205518.GB25844@systemhalted> <20020921232018.GA29388@tausq.org>
Message-ID: <20020922005714.07CB24829@dsl2.external.hp.com>
Randolph Chung wrote:
> legolas:/home/randolph# cat /proc/sys/kernel/unaligned
> Unaligned trap handler is enabled
> legolas:/home/randolph# ./t; echo $?
> 0
> legolas:/home/randolph# echo 0 >> /proc/sys/kernel/unaligned
Cool!
After reviewing the diff (on ftp.p-l.o/patches), only two nits
that have nothing to do with the code:
o cat output should relate to what I have to "echo" into the /proc file.
ie only display '0' or '1' when catting.
Or is "blah is enabled" by convention?
o SYSCTL_FILENAME should be "sys/kernel/unaligned_trap"
and then I think 0 or 1 should be clear enough to anyone
daring to mess with it.
> if someone can review this real quick before i commit it to cvs,
If you don't like my suggestions, I'm ok with committing
what you've already got.
> i'd
> appreciate it. in particular, the point where it decides that the
> unaligned trap is not enabled and forces the SIGBUS is not exactly at
> the beginning of the trap handler -- it still prints the unaligned
> message....
hmmm...if running under a debugger, one gets that info anyway.
But that's not always easy to do. I think it's ok since we don't
like to see unligned traps happen anyway.
Maybe a "unaligned_trap_msg" tunable?
/me runs...
thanks
grant
From dave@hiauly1.hia.nrc.ca Sun Sep 22 06:43:58 2002
From: dave@hiauly1.hia.nrc.ca (John David Anglin)
Date: Sun, 22 Sep 2002 01:43:58 -0400 (EDT)
Subject: [parisc-linux] malloc limits
In-Reply-To: <20020921223352.C64324829@dsl2.external.hp.com> from "Grant Grundler" at Sep 21, 2002 04:33:52 pm
Message-ID: <200209220543.g8M5hxl6003856@hiauly1.hia.nrc.ca>
> I'll assume this is happening on the A500 (PA2.0) and wonder if it's
> a signed/unsigned bug. Look closely at how PA2.0 extends register
> values and make sure code is treating addresses and sizes as unsigned.
This is the code that adds the chunk pointer plus size of chunk and
then tries to load the size of the next check:
0x402611d4 <chunk_free+32>: add,l r25,ret1,r31
0x402611d8 <chunk_free+36>: ldw 4(sr0,r31),r20
The add is a 64-bit add on a PA2.0 machine, so the result won't be
signed extended. My understanding is that the upper 32-bits are
truncated when the PSW W bit is zero. So, it isn't obvious to
me how this can be a signed/unsigned bug unless it is in the
kernel.
> > I haven't been successful debugging the code directly. I can get the
> > code to seg fault by setting SIG37 to nostop noprint, but the debugger
> > seems to think the fault occurs following the INLINE_SYSCALL in
> > __sigsuspend. However, the address points to an ldi instruction
> > which can't seg fault, so I don't know what's up.
>
> Not all instructions trap precisely. FP ops definitely do not and
> I thought a few others didn't either.
>
> I'm wondering what happens when unaligned access should segfault.
> Does the unaligned code handle check for that?
> I'll take a quick look at that code path.
There is definitely something strange with this program. It doesn't
seg fault 100% of the time. This suggests either a timing/lock problem
or something that isn't being properly initialized. I don't know
how to debug it under gdb because it seems to change the way traps
are handled. When I set a break, it appears that the code under test
catches the trap instead of gdb. The system also dumps core.
I've tried setting breaks in chunk_free and __pthread_mutex_lock
where the unaligned faults occur with a condition matching the
unaligned pointer value which i see in /var/log/debug. However,
I get the following:
Program received signal SIGTRAP, Trace/breakpoint trap.
0x4021e114 in __sigsuspend (set=0x25)
at ../sysdeps/unix/sysv/linux/sigsuspend.c:45
45 return INLINE_SYSCALL (rt_sigsuspend, 2, CHECK_SIGSET (set), _NSIG / 8);
(gdb) info proc
process 20194
cmdline = '/home/dave/pthread2.x0g'
warning: unable to read link '/proc/20194/cwd'
warning: unable to read link '/proc/20194/exe'
dave 20193 20041 0 21:41 pts/2 00:00:02 gdb pthread2.x0g
dave 20194 20193 0 21:43 pts/2 00:00:00 /home/dave/pthread2.x0g
dave 20199 20194 0 21:46 pts/2 00:00:00 [pthread2.x0g <defunct>]
I tried setting follow-fork-mode to child but it doesn't seem to follow
the child.
I don't think fp exceptions are involved.
I can see in debug that two traps occur associated with each run. They
are both type 15 (Data TLB Miss Fault) and they seem to both occur at
the same location.
The program pthread2.x0g is in my home directory on gsyprf11. If you
want to try it, it probably best to set
LD_LIBRARY_PATH=/home/dave/opt/gnu/lib
It may take several tries to get it to seg fault.
Dave
--
J. David Anglin dave.anglin@nrc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6605)
From Yes" <GrowYounger6428a74@desertmail.com Sun Sep 22 06:55:04 2002
From: Yes" <GrowYounger6428a74@desertmail.com (Yes)
Date: Sun, 22 Sep 0102 19:31:50 -0700
Subject: [parisc-linux] Do you know the three HGH products?
Message-ID: <032b15b88d6e$8266e7a2$6ab21da5@akydbe>
------=_NextPart_000_00B8_41D02B0D.C8128C04
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: base64
TXl0aCBhYm91dCBIR0ggcHJvZHVjdHMNCg0KPGh0bWw+DQoNCjxoZWFkPg0K
DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9InRl
eHQvaHRtbDsgY2hhcnNldD13aW5kb3dzLTEyNTIiPg0KDQo8bWV0YSBuYW1l
PSJHRU5FUkFUT1IiIGNvbnRlbnQ9Ik1pY3Jvc29mdCBGcm9udFBhZ2UgNC4w
Ij4NCg0KPG1ldGEgbmFtZT0iUHJvZ0lkIiBjb250ZW50PSJGcm9udFBhZ2Uu
RWRpdG9yLkRvY3VtZW50Ij4NCg0KPHRpdGxlPlRoZXJlIGFyZSB0aHJlZSBk
aWZmZXJlbnQgdHlwZXMgb2YgSEdIIHByb2R1Y3RzPC90aXRsZT4NCg0KPC9o
ZWFkPg0KDQo8Ym9keSBiYWNrZ3JvdW5kPSJjbG91ZHMuanBnIj4NCg0KPHA+
PGZvbnQgc2l6ZT0iNCI+PGZvbnQgY29sb3I9IiM4MDAwMDAiPjxiPlRoZXJl
IGFyZSB0aHJlZSBkaWZmZXJlbnQgdHlwZXMgb2YNCg0KSEdIIHByb2R1Y3Rz
LjwvYj48L2ZvbnQ+PGJyPg0KDQpUaGUgY29uZnVzaW9uIGlzIHRoYXQgYWxs
IHRocmVlIGFyZTxicj4NCg0KYWR2ZXJ0aXNlZCBhcyBpZiB0aGV5IHdlcmUg
dGhlIHNhbWUuPC9mb250Pjxicj4NCg0KJm5ic3A7PGJyPg0KDQombmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPHU+VGhlIHRo
cmVlIHR5cGVzIGFyZTo8L3U+PGJyPg0KDQombmJzcDs8YnI+DQoNCjxiPjEp
PC9iPiAtLS0gPGZvbnQgY29sb3I9IiMwMDAwRkYiPjxiPkhvbWVvcGF0aGlj
IEhHSDwvYj48L2ZvbnQ+PGJyPg0KDQo8Yj4yKTwvYj4gLS0tIDxmb250IGNv
bG9yPSIjMDAwMEZGIj48Yj5QcmUtY3Vyc29yIEhHSDwvYj48L2ZvbnQ+PGJy
Pg0KDQo8Yj4zKTwvYj4gLS0tIDxmb250IGNvbG9yPSIjMDAwMEZGIj48Yj5S
ZWFsIG9yIHN5bnRoZXRpYyBIR0g8L2I+PC9mb250Pg0KDQooZGVsaXZlcmVk
IGJ5IGluamVjdGlvbjxicj4NCg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7IG9yLCBieSBhbiBvcmFsIHNwcmF5IG1ldGhv
ZCkuPGJyPg0KDQombmJzcDs8YnI+DQoNCkRvIHlvdSBrbm93IGRpZmZlcmVu
Y2VzPzxicj4NCg0KJm5ic3A7PGJyPg0KDQpDYWxsIHVzIGFuZCB3ZSdsbCBl
eHBsYWluIHRoZW0gdG8geW91Ljxicj4NCg0KJm5ic3A7PGJyPg0KDQpPdXIg
dG9sbCBmcmVlIG51bWJlciBpcyA8Zm9udCBjb2xvcj0iIzAwMDA4MCI+PGI+
MS04ODgtNjIxLTczMDA8L2I+PC9mb250Pjxicj4NCg0KQW4gSEdIIHN0YWZm
IG1lbWJlciBpcyBhdmFpbGFibGU8YnI+DQoNCjkgdG8gNSBQYWNpZmljIFRp
bWUuPGJyPg0KDQpJZiBhZnRlciBob3VycywgcGxlYXNlIGxlYXZlIHlvdSBu
YW1lPGJyPg0KDQphbmQgZGF5IGFuZCBldmVuaW5nIHBob25lIG51bWJlcnMu
PGJyPg0KDQpXZSB3aWxsIGNhbGwgeW91IGJhY2sgaW4gYSBubyBwcmVzc3Vy
ZSw8YnI+DQoNCmVkdWNhdGlvbmFsIG1hbm5lci48YnI+DQoNCklmIHlvdSBh
cmUgb3ZlcnNlYXMgY2FsbCB5b3VyIGxvbmcgZGlzdGFuY2U8YnI+DQoNCm9w
ZXJhdG9yIGFuZCBhc2sgdG8gYmUgY29ubmVjdGVkIHRvIG91cjxicj4NCg0K
cGhvbmUgbnVtYmVyLiZuYnNwOyBXZSB3aWxsIGNhbGwgeW91IGJhY2sgc288
YnI+DQoNCndlIGNhbiBwYXkgZm9yIHRoZSBsb25nIGRpc3RhbmNlIGNoYXJn
ZXMuPGJyPg0KDQombmJzcDs8YnI+DQoNCjxmb250IGNvbG9yPSIjRkYwMDAw
Ij5Gb3IgbW9yZSBpbmZvcm1hdGlvbiBvbiBIR0ggcmVhZCBvbi4uLi4uLi4u
Li4uLjwvZm9udD48YnI+DQoNCiZuYnNwOzxicj4NCg0KSEFWRSBZT1UgSEVB
UkQgT0Y8YnI+DQoNCkhVTUFOIEdST1dUSCBIT1JNT05FIChIR0gpPz8/PGJy
Pg0KDQombmJzcDs8YnI+DQoNCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBS
ZWxlYXNlZCBieSB5b3VyIG93biBwaXR1aXRhcnkgZ2xhbmQsIEhHSCBzdGFy
dHMNCg0KZGVjbGluaW5nPGJyPg0KDQppbiB5b3VyIDIwcywgZXZlbiBtb3Jl
IGluIHlvdXIgMzBzIGFuZCA0MHMsIGV2ZW50dWFsbHkgcmVzdWx0aW5nPGJy
Pg0KDQppbiB0aGUgc2hyaW5rYWdlIG9mIG1ham9yIG9yZ2FucyAtLSBwbHVz
LCBhbGw8YnI+DQoNCm90aGVyIHN5bXB0b21zIHJlbGF0ZWQgdG8gb2xkIGFn
ZS48YnI+DQoNCiZuYnNwOzxicj4NCg0KJm5ic3A7PGJyPg0KDQpJTiBUSE9V
U0FORFMgT0YgQ0xJTklDQUwgU1RVRElFUyw8YnI+DQoNCkhHSCBIQVMgQkVF
TiBTSE9XTiBUTyBBQ0NPTVBMSVNIIFRIRSBGT0xMT1dJTkc6PGJyPg0KDQom
bmJzcDs8YnI+DQoNCiogUmVkdWNlIEJvZHkgRmF0IGFuZCBCdWlsZCBMZWFu
IE11c2NsZTxicj4NCg0KJm5ic3A7Jm5ic3A7IFdJVEhPVVQgRVhFUkNJU0Uh
PGJyPg0KDQombmJzcDs8YnI+DQoNCiogRW5oYW5jZSBTZXh1YWwgUGVyZm9y
bWFuY2U8YnI+DQoNCiZuYnNwOzxicj4NCg0KKiBSZW1vdmUgV3JpbmtsZXMg
YW5kIENlbGx1bGl0ZTxicj4NCg0KJm5ic3A7PGJyPg0KDQoqIExvd2VyIEJs
b29kIFByZXNzdXJlIGFuZCBJbXByb3ZlIENob2xlc3Rlcm9sIFByb2ZpbGU8
YnI+DQoNCiZuYnNwOzxicj4NCg0KKiBJbXByb3ZlIFNsZWVwLCBWaXNpb24g
YW5kIE1lbW9yeTxicj4NCg0KJm5ic3A7PGJyPg0KDQoqIFJlc3RvcmUgSGFp
ciBDb2xvciBhbmQgR3Jvd3RoPGJyPg0KDQombmJzcDs8YnI+DQoNCiogU3Ry
ZW5ndGhlbiB0aGUgSW1tdW5lIFN5c3RlbTxicj4NCg0KJm5ic3A7PGJyPg0K
DQoqIEluY3JlYXNlIEVuZXJneSBhbmQgQ2FyZGlhYyBPdXRwdXQ8YnI+DQoN
CiZuYnNwOzxicj4NCg0KKiBUdXJuIGJhY2sgeW91ciBib2R5J3MgQmlvbG9n
aWNhbCBUaW1lIENsb2NrIDEwIC0gMjAgeWVhcnM8YnI+DQoNCiZuYnNwOzxi
cj4NCg0KKiBMaXZlIExvbmdlciBBTkQgU3Ryb25nZXI8YnI+DQoNCiZuYnNw
Ozxicj4NCg0KQWxsIG5hdHVyYWwgYW5kIG9yZ2FuaWMgcGxhbnQgYmFzZWQ8
YnI+DQoNCiZuYnNwOzxicj4NCg0KPGZvbnQgY29sb3I9IiMwMDAwRkYiPjxi
PkZFRUwgMTAgWUVBUlMgWU9VTkdFUiBXSVRIIE9SQUwgU1BSQVkgSEdILjxi
cj4NCg0KR1VBUkFOVEVFRDwvYj48L2ZvbnQ+PGJyPg0KDQombmJzcDs8YnI+
DQoNCiZuYnNwOyZuYnNwOyZuYnNwOyBXZSBhcmUgdGhlIG1hbnVmYWN0dXJl
ciBhbmQgd2Ugc2VsbCBkaXJlY3RseSB0byBEb2N0b3JzLDxicj4NCg0KQ2hp
cm9wcmFjdG9ycywgYW5kIGNvbnN1bWVycyB3b3JsZCB3aWRlIHRoZSBoaWdo
ZXN0IGdyYWRlPGJyPg0KDQombmJzcDtIR0ggT3JhbCBTcHJheSBhdmFpbGFi
bGUuJm5ic3A7PGJyPg0KDQombmJzcDs8YnI+DQoNCiZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyBXaXRoIGludGVybmV0IG1hcmtldGluZywgd2UgYXJlIGFi
bGUgdG8gc2F2ZQ0KDQphZHZlcnRpc2luZzxicj4NCg0KY29zdCBhbmQgcGFz
cyB0aG9zZSBzYXZpbmdzIGFsb25nIHRvIHlvdS48YnI+DQoNCkJ1dCB5b3Ug
bXVzdCBhY3Qgbm93LiZuYnNwOzxicj4NCg0KJm5ic3A7PGJyPg0KDQpUbyBy
ZWNlaXZlIG1vcmUgaW5mb3JtYXRpb24gY2FsbCZuYnNwOyB1cyBub3cuPGJy
Pg0KDQombmJzcDs8YnI+DQoNCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBUT0xM
IEZSRUUgPGI+PGZvbnQgY29sb3I9IiMwMDAwODAiPjEtODg4LTYyMS03MzAw
PC9mb250PjwvYj48YnI+DQoNCiZuYnNwOzxicj4NCg0KV2UgbXVzdCBzcGVh
ayB0byB5b3UgaW4gcGVyc29uIHRvIHF1YWxpZnkgeW91ciB1c2FnZS48YnI+
DQoNCiZuYnNwOzxicj4NCg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEFs
bCBvZiB5b3VyIHF1ZXN0aW9ucyB3aWxsIGJlIGFkZHJlc3NlZCBhbmQgYW5z
d2VyZWQgaW4NCg0KYSBmcmllbmRseSw8YnI+DQoNCm5vIHByZXNzdXJlIG1h
bm5lci4mbmJzcDsgT3VyIG1haW4gcHVycG9zZSBpcyB0byBwcm92aWRlIHlv
dSB3aXRoPGJyPg0KDQombmJzcDtpbmZvcm1hdGlvbiBzbyB5b3UgY2FuIG1h
a2UgYW4gZWR1Y2F0ZWQgZGVjaXNpb24uPGJyPg0KDQombmJzcDs8YnI+DQoN
CiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBGb3IgbW9yZSBpbmZvcm1hdGlv
biBjYWxsPGJyPg0KDQombmJzcDs8YnI+DQoNCiZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyA8Yj48Zm9udCBjb2xvcj0iIzAwMDA4MCI+MS04ODgtNjIxLTczMDA8
L2ZvbnQ+PC9iPjxicj4NCg0KJm5ic3A7PGJyPg0KDQombmJzcDtJZiB5b3Ug
YXJlIG9uIGxpbmUgd3JpdGUgZG93biBvdXI8YnI+DQoNCnBob25lIG51bWJl
ciBhbmQgY2FsbCB1cyB3aGVuIHlvdSBjYW4uPGJyPg0KDQombmJzcDs8YnI+
DQoNClNvb24sIHlvdSBhbmQgeW91ciBsb3ZlZCBvbmVzIHdpbGwgYmUgdmVy
eSBnbGFkIHlvdSBkaWQuPGJyPg0KDQombmJzcDs8YnI+DQoNClJlYWQgd2hh
dCBwZW9wbGUgYXJlIHNheWluZzo8YnI+DQoNCiZuYnNwOzxicj4NCg0KJnF1
b3Q7VGhlIGVmZmVjdHMgb2YgNiBtb250aHMgb2YgR0ggb248YnI+DQoNCmxl
YW4gYm9keSBtYXNzIGFuZCBmYXQgd2VyZSBlcXVpdmFsZW50PGJyPg0KDQpp
biBtYWduaXR1ZGUgdG8gdGhlIGNoYW5nZXMgaW5jdXJyZWQ8YnI+DQoNCmR1
cmluZyAxMC0yMCB5ZWFycyBvZiBhZ2luZy4mcXVvdDs8YnI+DQoNCkRyLiBE
YW5pZWwgUnVkbWFuLCBNRCw8YnI+DQoNCk5ldyBFbmdsYW5kIEpvdXJuYWwg
b2YgTWVkaWNpbmUuPGJyPg0KDQombmJzcDs8YnI+DQoNCiZxdW90O1dpdGhp
biBmb3VyIG1vbnRocywgbXkgYm9keSBmYXQgZGVjcmVhc2VkPGJyPg0KDQom
bmJzcDtmb3JtIDMwJSBkb3duIHRvIDIxJSEgSSBub3RpY2VkIG15IHNraW48
YnI+DQoNCiZuYnNwO2lzIG1vcmUgc3VwcGxlIGFuZCBteSBvdmVyYWxsIG1l
bnRhbDxicj4NCg0KJm5ic3A7b3V0bG9vayBpbXByb3ZlZCBzaWduaWZpY2Fu
dGx5LiZxdW90Ozxicj4NCg0KJm5ic3A7RC5XLiwgTmV3IEplcnNleTxicj4N
Cg0KJm5ic3A7PGJyPg0KDQomcXVvdDtXZSBoYXZlIGJlZW4gb24gdGhlIHNw
cmF5IGZvciBqdXN0IDMgd2Vla3M8YnI+DQoNCm5vdywgYW5kIGJlc2lkZXMg
dGhlIHRyZW1lbmRvdXMgZW5lcmd5IHdlPGJyPg0KDQpib3RoIGZlZWwsIG15
IGh1c2JhbmRzIGFsbGVyZ2llcyBhbmQgc3BlbGxzPGJyPg0KDQpvZiBkZXBy
ZXNzaW9uIGhhdmUgbGlmdGVkLiBJIGFtIGhlYWxpbmc8YnI+DQoNCmV4dHJl
bWVseSBmYXN0IGFmdGVyIGFuIGFjY2lkZW50IGFuZCBoYXZlPGJyPg0KDQps
b3N0IDcgbGJzLiB3aXRob3V0IHRyeWluZyEmcXVvdDs8YnI+DQoNCkMuQi4s
IEZsYWdzdGFmZi4gQVo8YnI+DQoNCiZuYnNwOzxicj4NCg0KVGhhbmtzIGZv
ciByZWFkaW5nIG91ciBsZXR0ZXIsPGJyPg0KDQpUaGUgSEdIIFN0YWZmPGJy
Pg0KDQpVU0EgRGl2aXNpb248YnI+DQoNCiZuYnNwOzxicj4NCg0KUFM6Jm5i
c3A7IFRoZSBIR0ggU3RhZmYgZ3VhcmFudGVlcyB0aGU8YnI+DQoNCmhpZ2hl
c3QgcXVhbGl0eSBhbmQgbG93ZXN0IHByaWNlLjxicj4NCg0KJm5ic3A7PGJy
Pg0KDQombmJzcDtXZSBtYW51ZmFjdHVyZSBhbmQgc2hpcCBkaXJlY3RseSB0
byB5b3VyIGRvb3IuPGJyPg0KDQombmJzcDs8YnI+DQoNCkNhbGwgdXMgbm93
IDxiPjxmb250IGNvbG9yPSIjMDAwMDgwIj4xLTg4OC02MjEtNzMwMDwvZm9u
dD48L2I+PGJyPg0KDQombmJzcDs8YnI+DQoNCj09PT09PT0mbmJzcDsmbmJz
cDsgRW5kIG9mIG1lc3NhZ2UgPT09PT09PT0mbmJzcDs8YnI+DQoNCiZuYnNw
Ozxicj4NCg0KJm5ic3A7Jm5ic3A7IFRoZSBmb2xsb3dpbmcgc3RhdGVtZW50
IGlzIHByb3ZpZGVkIHRvIGJlPGJyPg0KDQppbiBjb21wbGlhbmNlIHdpdGgg
Y29tbWVyY2lhbCBlbWFpbCBsYXdzLjxicj4NCg0KJm5ic3A7PGJyPg0KDQom
bmJzcDsmbmJzcDsgSWYgeW91IGRvIG5vdCB3aXNoIHRvIHJlY2VpdmUgZnVy
dGhlcjxicj4NCg0KbWFpbGluZ3MsIHBsZWFzZSBnb3RvIHRoZSBmb2xsb3dp
bmcgd2Vic2l0ZSBhbmQgZW50ZXIgeW91ciBlbWFpbCBhZGRyZXNzIHRvIGJl
IHJlbW92ZWQuLi4gaHR0cDovL2NicGhvc3QubmV0L3VzZXJzL21hcmtldHBy
b3MvcmVtb3ZlLnBocA0KPGJyPg0KDQombmJzcDs8YnI+DQoNCiZuYnNwOyZu
YnNwOyBUaGlzIG1lc3NhZ2UgaXMgaW4gZnVsbCBjb21wbGlhbmNlIHdpdGg8
YnI+DQoNClUuUy4gRmVkZXJhbCByZXF1aXJlbWVudHMgZm9yIGNvbW1lcmNp
YWw8YnI+DQoNCmVtYWlsIHVuZGVyIGJpbGwgUy4xNjE4IFRpdGxlIGxsbCwg
U2VjdGlvbiAzMDEsPGJyPg0KDQpQYXJhZ3JhcGggKGEpKDIpKEMpIHBhc3Nl
ZCBieSB0aGUgMTA1dGggVS5TLjxicj4NCg0KQ29uZ3Jlc3MgYW5kIGlzIG5v
dCBjb25zaWRlcmVkIFNQQU08YnI+DQoNCnNpbmNlIGl0IGluY2x1ZGVzIGEg
cmVtb3ZlIG1lY2hhbmlzbS4qPGJyPg0KDQpUaGlzIG1lc3NhZ2UgaXMgbm90
IGludGVuZGVkIGZvciByZXNpZGVudHMgaW4gdGhlPGJyPg0KDQpzdGF0ZXMg
b2YgQ0EsIE5DLCBOViwgUkksIFROLCBWQSAmYW1wOyBXQS48YnI+DQoNClNj
cmVlbmluZyBvZiBhZGRyZXNzZXMgaGFzIGJlZW4gZG9uZSB0byB0aGUgYmVz
dDxicj4NCg0Kb2Ygb3VyIHRlY2huaWNhbCBhYmlsaXR5Ljxicj4NCg0KJm5i
c3A7PGJyPg0KDQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgQ2FsbCB1
cw0KDQpub3cgPGI+PGZvbnQgY29sb3I9IiMwMDAwODAiPjEtODg4LTYyMS03
MzAwPC9mb250PjwvYj4gZm9yIHlvdXI8YnI+DQoNCiZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyBmcmVlDQoNCkhHSCBjb25zdWx0YXRpb24uPC9wPg0K
DQo8cD48YnI+DQoNClRoYW5rIHlvdTwvcD4NCg0KPC9ib2R5Pg0KDQo8L2h0
bWw+DQoNCiANCiANCiANCiANCiANCiANCiANCiANCiANCiANCiANCiANCiAN
CiANCiANCiANCiANCiANCiANCiANCiANCiANCiANCiANCiANCiANCiANCiAN
CiANCiANCiANCiANCiANCiANCiANCiANCiANCiANCiANCiANCiANCiANCiAN
CiANCiANCg0KLS0NCg0KNTUzM3ZlSUg3LTA4N0VlZkYxNTExdVZXQjctOTYz
amRDRjQ5NTRGdVlEMC0ybDQy
From joel.soete@freebel.net Sun Sep 22 15:02:53 2002
From: joel.soete@freebel.net (Joel Soete)
Date: Sun, 22 Sep 2002 14:02:53 +0000
Subject: [parisc-linux] Mouse stops working when exiting KDE
References: <20020921220317.3256.qmail@web12502.mail.yahoo.com> <3D8D0454.40706@earthlink.net>
Message-ID: <3D8DCD8D.8070300@freebel.net>
Bryan W. Headley wrote:
> Derek Engelhaupt wrote:
>
>> Hey all,
>>
>> Currently when my system boots up the X11 login window starts up
>> automatically and I can log in and use it normally, but when I log out
>> the mouse quits working. The X11 login window appears again, but the
>> mouse won't move anymore. I'm just using a standard PS/2 HP 3 button
>> mouse - nothing fancy on my C180. Also, why is it that Konqueror won't
>> do https sites? And if it will what could possibly be the problem with
>> that? Thanks.
>
>
> I assume you are running the gpm mouse daemon as well. If you tell X to
> use the gpm mouse (/dev/gpmdata), you should be okay.
Hmm, long time ago I test this (because that was like this I configure
my i386 boxe) but it did not work. Does it work now on parisc?
> Personally, I just
> turn off the gpm daemon, because I don't need a mouse in console mode.
>
> (It's not a parisc-only bug: I see this on virtually every Debian platform)
>
with kde ?
Because with the same software config (gdm + xfce + xfree86-4.1) the
same problem occurs on my parisc (b180) and not on my i386 (on which I
also use /dev/psaux as mouse device)?
(sorry (I would be of better help) I never have time to investigate in
more details this problem. And I do not remember exactly if it was
always there or if it appears with a new release of xfree86 or with a
new kernel release? Is some one can refresh my memory?)
Joel
From tobias_subscriber@tgtools.com Sun Sep 22 14:46:32 2002
From: tobias_subscriber@tgtools.com (Tobias Giesen)
Date: Sun, 22 Sep 2002 15:46:32 +0200
Subject: [parisc-linux] Do you know the three HGH products?
In-Reply-To: <032b15b88d6e$8266e7a2$6ab21da5@akydbe>
Message-ID: <000301c2623e$776cf940$0100a8c0@PLUTO>
Hi all,
funny spam that was, wasn't it ...
especially this part:
> This message is not intended for
> residents in the states of CA, NC,
> NV, RI, TN, VA & WA.
I wonder why? Is their product illegal
in those states?
BTW is there anything true about the
HGH or is it all lies ...
Cheers,
Tobias
From joel.soete@freebel.net Sun Sep 22 17:25:50 2002
From: joel.soete@freebel.net (Joel Soete)
Date: Sun, 22 Sep 2002 16:25:50 +0000
Subject: [parisc-linux] Mouse stops working when exiting KDE
References: <20020921220317.3256.qmail@web12502.mail.yahoo.com> <3D8D0454.40706@earthlink.net> <3D8DCD8D.8070300@freebel.net>
Message-ID: <3D8DEF0E.3070601@freebel.net>
Oops so old:
http://lists.parisc-linux.org/pipermail/parisc-linux/2001-October/014145.html
Well IIRC, at this time I encounter a problem with Xfree86 config (a
change in stifb (kernel 2.4.9-pa57) required that the screen mode match
exactly the hw definition) but it was also the first time that I test
xdm (previously I only used startx).
Joel
Joel Soete wrote:
>
>
> Bryan W. Headley wrote:
>
>> Derek Engelhaupt wrote:
>>
>>> Hey all,
>>>
>>> Currently when my system boots up the X11 login window starts up
>>> automatically and I can log in and use it normally, but when I log out
>>> the mouse quits working. The X11 login window appears again, but the
>>> mouse won't move anymore. I'm just using a standard PS/2 HP 3 button
>>> mouse - nothing fancy on my C180. Also, why is it that Konqueror won't
>>> do https sites? And if it will what could possibly be the problem with
>>> that? Thanks.
>>
>>
>>
>> I assume you are running the gpm mouse daemon as well. If you tell X
>> to use the gpm mouse (/dev/gpmdata), you should be okay.
>
>
> Hmm, long time ago I test this (because that was like this I configure
> my i386 boxe) but it did not work. Does it work now on parisc?
>
>> Personally, I just turn off the gpm daemon, because I don't need a
>> mouse in console mode.
>>
>> (It's not a parisc-only bug: I see this on virtually every Debian
>> platform)
>>
> with kde ?
>
> Because with the same software config (gdm + xfce + xfree86-4.1) the
> same problem occurs on my parisc (b180) and not on my i386 (on which I
> also use /dev/psaux as mouse device)?
>
> (sorry (I would be of better help) I never have time to investigate in
> more details this problem. And I do not remember exactly if it was
> always there or if it appears with a new release of xfree86 or with a
> new kernel release? Is some one can refresh my memory?)
>
> Joel
>
> _______________________________________________
> parisc-linux mailing list
> parisc-linux@lists.parisc-linux.org
> http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
>
From bodack@stud.fh-heilbronn.de Sun Sep 22 19:30:34 2002
From: bodack@stud.fh-heilbronn.de (Yves Bodack)
Date: Sun, 22 Sep 2002 20:30:34 +0200
Subject: [parisc-linux] RTC and FB on 735/125
Message-ID: <03ab01c26266$2416dea0$1f96078d@acid>
This is a multi-part message in MIME format.
------=_NextPart_000_03A8_01C26276.E71F5B10
Content-Type: text/plain;
charset="Windows-1252"
Content-Transfer-Encoding: 7bit
Hi,
i have a 'new' 735/125 workstation, which I run Debian 3.0 on.
hp735# uname -a
Linux hp735 2.4.19-32 #1 Tue Aug 20 03:25:39 MDT 2002 parisc unknown unknown
GNU/Linux
1st problem I have is the Real Time Clock. On boot I get the following
messages:
System Time was Thu Jan 1 00:00:10 UTC 1970
Setting the System Clock using the Hardware Clock as reference...
RTC_RD_TIME: Bad address
ioctl() to /dev/rtc read the time failed.
System Clock set. System local time is now Thu Jan 1 00:00:13 UTC 1970.
so i'm damned back to the 70' every boot time...
2nd problem is I can't start X. I'm using Helge Deller's XFConfig-4 from
ftp.p-l.org and just changed Depth from 8 to 24 bpp.
(EE) FBDev(0): FBIOPUT_VSCREENINFO: Invalid argument
Fatal server error:
AddScreen/ScreenInit failed for driver 0
Is the Coral SGC Graphics supported?
I've attached dmesg and XFree86.0.log .
Thanks for your help
Yves...
------=_NextPart_000_03A8_01C26276.E71F5B10
Content-Type: application/octet-stream;
name="dmesg"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
filename="dmesg"
Linux version 2.4.19-32 (root@j5k) (gcc version 3.0.4) #1 Tue Aug 20 =
03:25:39 MDT 2002=0A=
FP[0] enabled: Rev 1 Model 9=0A=
The 32-bit Kernel has started...=0A=
Determining PDC firmware type: Snake.=0A=
model 00002060 00000481 00000000 00000000 773bea94 ffffffff 00000004 =
0000000a 0000000a=0A=
vers 00000015=0A=
model 9000/735=0A=
Total Memory: 256 Mb=0A=
pagetable_init=0A=
On node 0 totalpages: 65536=0A=
zone(0): 65536 pages.=0A=
zone(1): 0 pages.=0A=
zone(2): 0 pages.=0A=
Kernel command line: root=3D/dev/sda3 HOME=3D/ console=3Dtty0 sti=3D1 =
sti_font=3DVGA8x16 TERM=3Dlinux palo_kernel=3D3/boot/vmlinux=0A=
Error reading tod clock=0A=
Console: colour dummy device 160x64=0A=
Calibrating delay loop... 124.51 BogoMIPS=0A=
Memory: 255920k available=0A=
Dentry cache hash table entries: 32768 (order: 6, 262144 bytes)=0A=
Inode cache hash table entries: 16384 (order: 5, 131072 bytes)=0A=
Mount-cache hash table entries: 4096 (order: 3, 32768 bytes)=0A=
Buffer-cache hash table entries: 16384 (order: 4, 65536 bytes)=0A=
Page-cache hash table entries: 65536 (order: 6, 262144 bytes)=0A=
Searching for devices...=0A=
Found devices:=0A=
1. Coral SGC Graphics (10) at 0xf8000000 [1], versions 0x4, 0x0, 0x77=0A=
2. Outfield Core BA (11) at 0xf082f000 [2], versions 0x9, 0x0, 0x70=0A=
3. Outfield Core SCSI (10) at 0xf0825000 [2/0/1], versions 0x9, 0x0, 0x71=0A=
4. Outfield Core LAN (802.3) (10) at 0xf0826000 [2/0/2], versions 0x9, =
0x0, 0x72=0A=
5. Outfield Core HIL (10) at 0xf0821000 [2/0/3], versions 0x9, 0x0, 0x73=0A=
6. Outfield Core RS-232 (10) at 0xf0823000 [2/0/4], versions 0x9, 0x0, =
0x75=0A=
7. Outfield Core RS-232 (10) at 0xf0822000 [2/0/5], versions 0x9, 0x0, =
0x75=0A=
8. Outfield Core Centronics (10) at 0xf0824000 [2/0/6], versions 0x9, =
0x0, 0x74=0A=
9. Outfield FW SCSI (10) at 0xf0830000 [2/0/7], versions 0x9, 0x0, 0x7c=0A=
10. Outfield Audio (10) at 0xf1000000 [2/0/8], versions 0x9, 0x0, 0x7f=0A=
11. Snake Cheetah (735/130) (0) at 0xfffbe000 [8], versions 0x206, 0x0, =
0x4=0A=
12. Memory (1) at 0xfffbf000 [9], versions 0x37, 0x0, 0x9=0A=
CPU(s): 1 x PA7100 (PCX-T) at 125.000000 MHz=0A=
Cutoff version 4 at 0xf082f000 found.=0A=
LED (ASP-style) display at f0800020 registered=0A=
POSIX conformance testing by UNIFIX=0A=
Linux NET4.0 for Linux 2.4=0A=
Based upon Swansea University Computer Society NET3.039=0A=
Initializing RT netlink socket=0A=
Soft power switch support not available.=0A=
Starting kswapd=0A=
Journalled Block Device driver loaded=0A=
Installing knfsd (copyright (C) 1996 okir@monad.swb.de).=0A=
parport_init_chip: enhanced parport-modes not supported.=0A=
parport0: PC-style at 0xf0824800, irq 88 [PCSPP]=0A=
STI GSC/PCI graphics driver version 0.9=0A=
STI byte mode ROM at f8000000, hpa at f8000000=0A=
STI id 26d148ee-40a00499, conforms to spec rev. 8.02=0A=
STI device: HPA1439A=0A=
Console: switching to colour frame buffer device 160x64=0A=
fb0: stifb 1280x1024-32 frame buffer device, id: 26d148ee, mmio: =
0xf8100000=0A=
pty: 256 Unix98 ptys configured=0A=
Serial driver version 5.05c (2001-07-08) with MANY_PORTS SHARE_IRQ =
SERIAL_PCI enabled=0A=
ttyS00 at iomem 0xf0823800 (irq =3D 90) is a 16550A=0A=
ttyS01 at iomem 0xf0822800 (irq =3D 89) is a 16550A=0A=
lp0: using parport0 (interrupt-driven).=0A=
Generic RTC Driver v1.02 05/27/1999 Sam Creasey (sammy@oh.verio.com)=0A=
Uniform Multi-Platform E-IDE driver Revision: 6.31=0A=
ide: Assuming 50MHz system bus speed for PIO modes; override with =
idebus=3Dxx=0A=
RAMDISK driver initialized: 16 RAM disks of 6144K size 1024 blocksize=0A=
loop: loaded (max 8 devices)=0A=
Found i82596 at 0xf0826000, IRQ 87=0A=
82596.c: MAC of HP700 LAN read from EEPROM=0A=
eth0: Couldn't get consistent shared memory=0A=
eth0: 82596 at 0xf0826000, 08 00 09 49 65 60 IRQ 87.=0A=
82596.c $Revision: 1.29 $=0A=
SCSI subsystem driver Revision: 1.00=0A=
53c700: consistent memory allocation failed=0A=
53c700: Version 2.7 By James.Bottomley@HansenPartnership.com=0A=
scsi0: 53c700 rev 0 =0A=
scsi0 : LASI SCSI 53c700=0A=
Vendor: MICROP Model: 4110-09TBCU0322J Rev: HT01=0A=
Type: Direct-Access ANSI SCSI revision: 02=0A=
Attached scsi disk sda at scsi0, channel 0, id 3, lun 0=0A=
SCSI device sda: 2053880 512-byte hdwr sectors (1052 MB)=0A=
Partition check:=0A=
sda: sda1 sda2 sda3=0A=
Lasi Harmony Audio driver V0.9a, h/w id 20, rev. 0 at 0xf1000000, IRQ 82=0A=
mice: PS/2 mouse device common for all mice=0A=
HP SDC: HP SDC at 0xf0821000, IRQ 94 (NMI IRQ 93)=0A=
HP SDC: New style SDC=0A=
HP SDC: Revision: 1820-4784=0A=
HP SDC: TI SN76494 beeper present=0A=
HP SDC: OKI MSM-58321 BBRTC present=0A=
HP SDC: Spunking the self test register to force PUP on next firmware =
reset.=0A=
HP SDC MLC: Registering the System Domain Controller's HIL MLC.=0A=
md: linear personality registered as nr 1=0A=
md: raid0 personality registered as nr 2=0A=
md: raid1 personality registered as nr 3=0A=
md: raid5 personality registered as nr 4=0A=
raid5: measuring checksumming speed=0A=
8regs : 92.400 MB/sec=0A=
8regs_prefetch: 92.400 MB/sec=0A=
32regs : 90.800 MB/sec=0A=
32regs_prefetch: 90.800 MB/sec=0A=
raid5: using function: 8regs_prefetch (92.400 MB/sec)=0A=
md: md driver 0.90.0 MAX_MD_DEVS=3D256, MD_SB_DISKS=3D27=0A=
md: Autodetecting RAID arrays.=0A=
md: autorun ...=0A=
md: ... autorun DONE.=0A=
NET4: Linux TCP/IP 1.0 for NET4.0=0A=
IP Protocols: ICMP, UDP, TCP, IGMP=0A=
IP: routing cache hash table of 2048 buckets, 16Kbytes=0A=
TCP: Hash tables configured (established 16384 bind 32768)=0A=
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.=0A=
VFS: Mounted root (ext2 filesystem) readonly.=0A=
Freeing unused kernel memory: 264k freed=0A=
kernel BUG at slab.c:1130!=0A=
HIL KEYB: HIL keyboard found (did =3D 0xcf, lang =3D german)=0A=
input0: HIL keyboard on hil0=0A=
HIL PTR: HIL pointer device found (did: 0x68, axis: relative)=0A=
HIL PTR: HIL pointer has 3 buttons and 1 sets of 2 axes=0A=
input1: HIL mouse on hil0=0A=
Adding Swap: 249848k swap-space (priority -1)=0A=
eth0: link ok.=0A=
------=_NextPart_000_03A8_01C26276.E71F5B10
Content-Type: application/octet-stream;
name="XFree86.0.log"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
filename="XFree86.0.log"
=0A=
This is a pre-release version of XFree86, and is not supported in any=0A=
way. Bugs may be reported to XFree86@XFree86.Org and patches submitted=0A=
to fixes@XFree86.Org. Before reporting bugs in pre-release versions,=0A=
please check the latest version in the XFree86 CVS repository=0A=
(http://www.XFree86.Org/cvs)=0A=
=0A=
XFree86 Version 4.1.0.1 / X Window System=0A=
(protocol Version 11, revision 0, vendor release 6510)=0A=
Release Date: 21 December 2001=0A=
If the server is older than 6-12 months, or if your card is=0A=
newer than the above date, look for a newer version before=0A=
reporting problems. (See http://www.XFree86.Org/FAQ)=0A=
Build Operating System: Linux 2.4.16-64 parisc64 [ELF] =0A=
(=3D=3D) Log file: "/var/log/XFree86.0.log", Time: Thu Jan 1 01:44:53 =
1970=0A=
(=3D=3D) Using config file: "/etc/X11/XF86Config-4"=0A=
Markers: (--) probed, (**) from config file, (=3D=3D) default setting,=0A=
(++) from command line, (!!) notice, (II) informational,=0A=
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.=0A=
(=3D=3D) ServerLayout "Default Layout"=0A=
(**) |-->Screen "Default Screen" (0)=0A=
(**) | |-->Monitor "Generic Monitor"=0A=
(**) | |-->Device "Generic Video Card"=0A=
(**) |-->Input Device "Keyboard"=0A=
(=3D=3D) Keyboard: CustomKeycode disabled=0A=
(**) |-->Input Device "Mouse"=0A=
(WW) The directory "/usr/lib/X11/fonts/cyrillic" does not exist.=0A=
Entry deleted from font path.=0A=
(WW) The directory "/usr/lib/X11/fonts/100dpi/" does not exist.=0A=
Entry deleted from font path.=0A=
(WW) The directory "/usr/lib/X11/fonts/75dpi/" does not exist.=0A=
Entry deleted from font path.=0A=
(WW) The directory "/usr/lib/X11/fonts/Type1" does not exist.=0A=
Entry deleted from font path.=0A=
(WW) The directory "/usr/lib/X11/fonts/Speedo" does not exist.=0A=
Entry deleted from font path.=0A=
(WW) The directory "/usr/lib/X11/fonts/100dpi" does not exist.=0A=
Entry deleted from font path.=0A=
(WW) The directory "/usr/lib/X11/fonts/75dpi" does not exist.=0A=
Entry deleted from font path.=0A=
(**) FontPath set to "unix/:7100,/usr/lib/X11/fonts/misc"=0A=
(=3D=3D) RgbPath set to "/usr/X11R6/lib/X11/rgb"=0A=
(--) using VT number 7=0A=
=0A=
(WW) Cannot open APM=0A=
(EE) No OS PCI support available=0A=
(II) Addressable bus resource ranges are=0A=
[0] -1 0 0x00000000 - 0xffffffff (0x0) MX[B]=0A=
[1] -1 0 0x00000000 - 0x0000ffff (0x10000) IX[B]=0A=
(II) OS-reported resource ranges:=0A=
[0] -1 0 0xffffffff - 0xffffffff (0x1) MX[B]=0A=
[1] -1 0 0x00000000 - 0x00000000 (0x1) MX[B]=0A=
[2] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B]=0A=
[3] -1 0 0x00000000 - 0x00000000 (0x1) IX[B]=0A=
(II) OS-reported resource ranges after removing overlaps with PCI:=0A=
[0] -1 0 0xffffffff - 0xffffffff (0x1) MX[B]=0A=
[1] -1 0 0x00000000 - 0x00000000 (0x1) MX[B]=0A=
[2] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B]=0A=
[3] -1 0 0x00000000 - 0x00000000 (0x1) IX[B]=0A=
(II) All system resource ranges:=0A=
[0] -1 0 0xffffffff - 0xffffffff (0x1) MX[B]=0A=
[1] -1 0 0x00000000 - 0x00000000 (0x1) MX[B]=0A=
[2] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B]=0A=
[3] -1 0 0x00000000 - 0x00000000 (0x1) IX[B]=0A=
(II) MGA: driver for Matrox chipsets: mga2064w, mga1064sg, mga2164w,=0A=
mga2164w AGP, mgag100, mgag100 PCI, mgag200, mgag200 PCI, mgag400=0A=
(II) GLINT: driver for 3Dlabs chipsets: gamma, ti_pm2, ti_pm, pm3, pm2v,=0A=
pm2, pm, 300sx, 500tx, mx, delta=0A=
S3VIdentify=0A=
(II) S3VIRGE: driver (version 1.6.13) for S3 ViRGE chipsets: virge, =
86C325,=0A=
virge vx, 86C988, virge dx, virge gx, 86C375, 86C385, virge gx2,=0A=
86C357, virge mx, 86C260, virge mx+, 86C280, trio 3d, 86C365,=0A=
trio 3d/2x, 86C362, 86C368=0A=
(II) SIS: driver for SiS chipsets: SIS5597, SIS5598, SIS530, SIS6326,=0A=
SIS300, SIS630, SIS540=0A=
(II) SAVAGE: driver (version 1.1.16) for S3 Savage chipsets: Savage4,=0A=
Savage3D, Savage3D-MV, Savage2000, Savage/MX-MV, Savage/MX,=0A=
Savage/IX-MV, Savage/IX, ProSavage PM133, ProSavage KM133, Twister,=0A=
TwisterK=0A=
(II) TRIDENT: driver for Trident chipsets: tvga8900d, cyber9320, =
cyber9388,=0A=
cyber9397, cyber9397dvd, cyber9520, cyber9525dvd, cyberblade/e4,=0A=
tgui9420dgi, tgui9440agi, tgui9660, tgui9680, providia9682,=0A=
providia9685, cyber9382, cyber9385, 3dimage975, 3dimage985, blade3d,=0A=
cyberbladei7, cyberbladei7d, cyberbladei1, cyberbladei1d,=0A=
cyberbladeAi1, cyberbladeAi1d, cyberbladeXP, cyberbladeXPm=0A=
(II) CHIPS: Driver for Chips and Technologies chipsets: ct65520, ct65525,=0A=
ct65530, ct65535, ct65540, ct65545, ct65546, ct65548, ct65550,=0A=
ct65554, ct65555, ct68554, ct69000, ct69030, ct64200, ct64300=0A=
(II) TDFX: Driver for 3dfx Banshee/Voodoo3 chipsets: 3dfx Banshee,=0A=
3dfx Voodoo3, 3dfx Voodoo5=0A=
(II) FBDev: driver for framebuffer: fbdev, afb=0A=
(II) ATI: ATI driver (version 6.3.6) for chipsets: ati=0A=
(II) R128: Driver for ATI Rage 128 chipsets: ATI Rage 128 RE (PCI),=0A=
ATI Rage 128 RF (AGP), ATI Rage 128 RG (AGP), ATI Rage 128 RK (PCI),=0A=
ATI Rage 128 RL (AGP), ATI Rage 128 Pro PD (PCI),=0A=
ATI Rage 128 Pro PF (AGP), ATI Rage 128 Pro PP (PCI),=0A=
ATI Rage 128 Pro PR (PCI), ATI Rage 128 Mobility LE (PCI),=0A=
ATI Rage 128 Mobility LF (AGP), ATI Rage 128 Mobility MF (AGP),=0A=
ATI Rage 128 Mobility ML (AGP)=0A=
(II) RADEON: Driver for ATI Radeon chipsets: ATI Radeon QD (AGP),=0A=
ATI Radeon QE (AGP), ATI Radeon QF (AGP), ATI Radeon QG (AGP),=0A=
ATI Radeon VE (AGP)=0A=
(II) imstt: driver (version 1.0.0 for IMS TwinTurbo chipsets : imstt128,=0A=
imstt3d=0A=
(II) VGA: Generic VGA driver (version 4.0) for chipsets: generic=0A=
(II) v4l driver for Video4Linux=0A=
S3VProbe begin=0A=
(II) FBDev(0): using default device=0A=
(II) Running in FRAMEBUFFER Mode=0A=
(=3D=3D) FBDev(0): Depth 24, (=3D=3D) framebuffer bpp 24=0A=
(=3D=3D) FBDev(0): RGB weight 888=0A=
(=3D=3D) FBDev(0): Default visual is TrueColor=0A=
(=3D=3D) FBDev(0): Using gamma correction (1.0, 1.0, 1.0)=0A=
(II) FBDev(0): Hardware: (vidmem: 16384k)=0A=
(II) FBDev(0): Checking Modes against framebuffer device...=0A=
(II) FBDev(0): mode "1280x1024" ok=0A=
(II) FBDev(0): Checking Modes against monitor...=0A=
(--) FBDev(0): Virtual size is 1280x1024 (pitch 1280)=0A=
(**) FBDev(0): Default mode "1280x1024": 108.0 MHz (scaled from 0.0 =
MHz), 64.0 kHz, 60.0 Hz=0A=
(II) FBDev(0): Modeline "1280x1024" 108.00 1280 1328 1440 1688 1024 =
1025 1028 1066 +hsync +vsync=0A=
(++) FBDev(0): DPI set to (100, 100)=0A=
(**) FBDev(0): Using "Shadow Framebuffer"=0A=
(--) Depth 24 pixmap format is 24 bpp=0A=
(EE) FBDev(0): FBIOPUT_VSCREENINFO: Invalid argument=0A=
=0A=
Fatal server error:=0A=
AddScreen/ScreenInit failed for driver 0=0A=
=0A=
=0A=
When reporting a problem related to a server crash, please send=0A=
the full server output, not just the last messages.=0A=
This can be found in the log file "/var/log/XFree86.0.log".=0A=
Please report problems to submit@bugs.debian.org.=0A=
=0A=
------=_NextPart_000_03A8_01C26276.E71F5B10--
From varenet@esiee.fr Sun Sep 22 21:03:23 2002
From: varenet@esiee.fr (Thibaut VARENE)
Date: Sun, 22 Sep 2002 22:03:23 +0200
Subject: [parisc-linux] RTC and FB on 735/125
In-Reply-To: <03ab01c26266$2416dea0$1f96078d@acid>
References: <03ab01c26266$2416dea0$1f96078d@acid>
Message-ID: <20020922220323.0113cbca.varenet@esiee.fr>
On Sun, 22 Sep 2002 20:30:34 +0200
"Yves Bodack" <bodack@stud.fh-heilbronn.de> wrote:
> Hi,
>
> i have a 'new' 735/125 workstation, which I run Debian 3.0 on.
> hp735# uname -a
> Linux hp735 2.4.19-32 #1 Tue Aug 20 03:25:39 MDT 2002 parisc unknown unknown
> GNU/Linux
> >
> 2nd problem is I can't start X. I'm using Helge Deller's XFConfig-4 from
> ftp.p-l.org and just changed Depth from 8 to 24 bpp.
I didn't try X on 735, but I bet it doesn't support 24bpp. ;)
Thibaut VARENE
The PA/Linux ESIEE Team
http://pateam.esiee.fr/
From deller@gmx.de Sun Sep 22 22:01:17 2002
From: deller@gmx.de (Helge Deller)
Date: Sun, 22 Sep 2002 23:01:17 +0200
Subject: [parisc-linux] RTC and FB on 735/125
In-Reply-To: <03ab01c26266$2416dea0$1f96078d@acid>
References: <03ab01c26266$2416dea0$1f96078d@acid>
Message-ID: <200209222301.17581.deller@gmx.de>
Hi Yves,
On Sunday 22 September 2002 20:30, Yves Bodack wrote:
> 2nd problem is I can't start X. I'm using Helge Deller's XFConfig-4 from
> ftp.p-l.org and just changed Depth from 8 to 24 bpp.
>
> (EE) FBDev(0): FBIOPUT_VSCREENINFO: Invalid argument
and your dmesg says:
STI GSC/PCI graphics driver version 0.9
STI byte mode ROM at f8000000, hpa at f8000000
STI id 26d148ee-40a00499, conforms to spec rev. 8.02
STI device: HPA1439A
Console: switching to colour frame buffer device 160x64
fb0: stifb 1280x1024-32 frame buffer device, id: 26d148ee, mmio: 0xf8100000
So you should use 8bpp, and might try 32bpp.
Greetings,
Helge
From bodack@stud.fh-heilbronn.de Sun Sep 22 22:11:22 2002
From: bodack@stud.fh-heilbronn.de (Yves Bodack)
Date: Sun, 22 Sep 2002 23:11:22 +0200
Subject: [parisc-linux] RTC and FB on 735/125
References: <03ab01c26266$2416dea0$1f96078d@acid> <20020922220323.0113cbca.varenet@esiee.fr>
Message-ID: <03bf01c2627c$9a5147c0$1f96078d@acid>
----- Original Message -----
From: "Thibaut VARENE" <varenet@esiee.fr>
Subject: Re: [parisc-linux] RTC and FB on 735/125
> > i have a 'new' 735/125 workstation, which I run Debian 3.0 on.
> > hp735# uname -a
> > Linux hp735 2.4.19-32 #1 Tue Aug 20 03:25:39 MDT 2002 parisc unknown
unknown
> > GNU/Linux
> > >
> > 2nd problem is I can't start X. I'm using Helge Deller's XFConfig-4 from
> > ftp.p-l.org and just changed Depth from 8 to 24 bpp.
> I didn't try X on 735, but I bet it doesn't support 24bpp. ;)
I bet it does ;)
dmesg says:
Found devices:
1. Coral SGC Graphics (10) at 0xf8000000 [1], versions 0x4, 0x0, 0x77
[...]
fb0: stifb 1280x1024-32 frame buffer device, id: 26d148ee, mmio: 0xf8100000
XFree86.0.log with 24 bpp says:
(II) FBDev(0): using default device
(II) Running in FRAMEBUFFER Mode
(==) FBDev(0): Depth 24, (==) framebuffer bpp 24
(==) FBDev(0): RGB weight 888
(==) FBDev(0): Default visual is TrueColor
(==) FBDev(0): Using gamma correction (1.0, 1.0, 1.0)
(II) FBDev(0): Hardware: (vidmem: 16384k)
(II) FBDev(0): Checking Modes against framebuffer device...
(II) FBDev(0): mode "1280x1024" ok
(II) FBDev(0): Checking Modes against monitor...
(--) FBDev(0): Virtual size is 1280x1024 (pitch 1280)
(**) FBDev(0): Default mode "1280x1024": 108.0 MHz (scaled from 0.0 MHz),
64.0 kHz, 60.0 Hz
(II) FBDev(0): Modeline "1280x1024" 108.00 1280 1328 1440 1688 1024 1025
1028 1066 +hsync +vsync
(++) FBDev(0): DPI set to (100, 100)
(**) FBDev(0): Using "Shadow Framebuffer"
(--) Depth 24 pixmap format is 24 bpp
(EE) FBDev(0): FBIOPUT_VSCREENINFO: Invalid argument
Fatal server error:
AddScreen/ScreenInit failed for driver 0
and with 8 bpp it says:
(EE) FBDev(0): No Display subsection in Screen section "Default Screen" for
depth/fbbpp 24/24
(EE) Screen(s) found, but none have a usable configuration.
Fatal server error:
no screens found
greetings,
yves...
From Christian Weerts <chw@ffis.de> Sun Sep 22 22:16:30 2002
From: Christian Weerts <chw@ffis.de> (Christian Weerts)
Date: Sun, 22 Sep 2002 23:16:30 +0200
Subject: [parisc-linux] Problems with 715/80
Message-ID: <20020922211630.GB1936@familie-weerts.de>
Hello everybody,
I've got an 715/80 here and have problems to get a console.
I've switched a Nullmodem Cable to my Laptop and configured
minicom as discribed in the Boot-HOWTO - no sign of life.
Then I attached my Monitor to the machine and noticed that I
got a signal to the (SVGA) Monitor but no message appeared -
nothing than a blank screen in 1024x768 resolution as my
Monitor told me on his little Display.
At this point I pressed serveral times the ESCAPE-Button or
the TAB-Key (as mentioned in the HOWTO) at boottime, but no
reaction.
What else can I do?
Greets,
Christian
--
May the Source be with you...
From bodack@stud.fh-heilbronn.de Sun Sep 22 22:37:51 2002
From: bodack@stud.fh-heilbronn.de (Yves Bodack)
Date: Sun, 22 Sep 2002 23:37:51 +0200
Subject: [parisc-linux] RTC and FB on 735/125
References: <03ab01c26266$2416dea0$1f96078d@acid> <20020922220323.0113cbca.varenet@esiee.fr> <03bf01c2627c$9a5147c0$1f96078d@acid>
Message-ID: <03ed01c26280$4dfb5c90$1f96078d@acid>
replying to myself ...
> and with 8 bpp it says:
>
> (EE) FBDev(0): No Display subsection in Screen section "Default Screen"
for
> depth/fbbpp 24/24
> (EE) Screen(s) found, but none have a usable configuration.
> Fatal server error:
> no screens found
same with 16 or 32 bpp :(
greetings,
yves...
From bwheadley@earthlink.net Sun Sep 22 22:45:47 2002
From: bwheadley@earthlink.net (Bryan W. Headley)
Date: Sun, 22 Sep 2002 16:45:47 -0500
Subject: [parisc-linux] Mouse stops working when exiting KDE
References: <20020921220317.3256.qmail@web12502.mail.yahoo.com> <3D8D0454.40706@earthlink.net> <3D8DCD8D.8070300@freebel.net>
Message-ID: <3D8E3A0B.5090008@earthlink.net>
Joel Soete wrote:
>> I assume you are running the gpm mouse daemon as well. If you tell X
>> to use the gpm mouse (/dev/gpmdata), you should be okay.
>
>
> Hmm, long time ago I test this (because that was like this I configure
> my i386 boxe) but it did not work. Does it work now on parisc?
Last time I checked, it did. Debconf and I have a difference of opinion
about it's overwriting XF86Config-4 after I hand-edit it. So and X
upgrade arrives, and the config file gets overwritten. :-)
>>
> with kde ?
No, I've seen it with Gnome also, on: alpha, ppc, sparc, and i386.
>
> Because with the same software config (gdm + xfce + xfree86-4.1) the
> same problem occurs on my parisc (b180) and not on my i386 (on which I
> also use /dev/psaux as mouse device)?
>
But, IS gpm running? Both it and the X server are trying to grab events
from /dev/psaux...
> (sorry (I would be of better help) I never have time to investigate in
> more details this problem. And I do not remember exactly if it was
> always there or if it appears with a new release of xfree86 or with a
> new kernel release? Is some one can refresh my memory?)
Seen it on X 4.0, 4.1 and 4.2. So I'd say it's not kernel-related.
--
____ .:. ____
Bryan W. Headley - bwheadley@earthlink.net
From MichaelS.Zick Mon Sep 23 00:05:41 2002
From: MichaelS.Zick (MichaelS.Zick)
Date: Sun, 22 Sep 2002 18:05:41 -0500
Subject: [parisc-linux] RTC and FB on 735/125
In-Reply-To: <03ab01c26266$2416dea0$1f96078d@acid>
References: <03ab01c26266$2416dea0$1f96078d@acid>
Message-ID: <02092218054100.14750@localhost.localdomain>
On Sunday 22 September 2002 01:30 pm, Yves Bodack wrote:
> Hi,
>
> i have a 'new' 735/125 workstation, which I run Debian 3.0 on.
> hp735# uname -a
> Linux hp735 2.4.19-32 #1 Tue Aug 20 03:25:39 MDT 2002 parisc unknown
> unknown GNU/Linux
>
> 1st problem I have is the Real Time Clock. On boot I get the following
> messages:
>
> System Time was Thu Jan 1 00:00:10 UTC 1970
> Setting the System Clock using the Hardware Clock as reference...
> RTC_RD_TIME: Bad address
> ioctl() to /dev/rtc read the time failed.
> System Clock set. System local time is now Thu Jan 1 00:00:13 UTC 1970.
>
Perhaps it is really a good address and a bad clock battery.
Mike
From caslivkoff@telocity.com Mon Sep 23 04:22:50 2002
From: caslivkoff@telocity.com (Chuck Slivkoff)
Date: Sun, 22 Sep 2002 23:22:50 -0400
Subject: [parisc-linux] Problems with 715/80
In-Reply-To: <20020922211630.GB1936@familie-weerts.de>
Message-ID: <BD69FB20-CEA3-11D6-827A-000393581E44@telocity.com>
I would suggest that you disconnect any disks and power on the box.
Make sure your null-modem cable is attached to serial port "a" and no
keyboard is attached via the PS2/HIL adapter box. You will need to get
to the PCD "BOOT_ADMIN>" prompt before you can get any further. If you
can not get to this prompt, take note of the LED's being displayed. The
service manual for the 715 should help to decode the LED's.
http://h20000.www2.hp.com/bizsupport/
CoreRedirect.jsp?targetPage=http%3A%2F%2Fh200002.www2.hp.com%2Fbc%2Fdocs
%2Fsupport%2FSupportManual%2Flpv37699%2Flpv37699.pdf
Hope this helps.
-chuck
On Sunday, Sep 22, 2002, at 17:16 US/Eastern, Christian Weerts wrote:
> Hello everybody,
>
> I've got an 715/80 here and have problems to get a console.
>
> I've switched a Nullmodem Cable to my Laptop and configured
> minicom as discribed in the Boot-HOWTO - no sign of life.
>
> Then I attached my Monitor to the machine and noticed that I
> got a signal to the (SVGA) Monitor but no message appeared -
> nothing than a blank screen in 1024x768 resolution as my
> Monitor told me on his little Display.
>
> At this point I pressed serveral times the ESCAPE-Button or
> the TAB-Key (as mentioned in the HOWTO) at boottime, but no
> reaction.
>
> What else can I do?
>
> Greets,
> Christian
>
> --
> May the Source be with you...
> _______________________________________________
> parisc-linux mailing list
> parisc-linux@lists.parisc-linux.org
> http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
>
From jsoe0708@tiscali.be Mon Sep 23 07:18:38 2002
From: jsoe0708@tiscali.be (jsoe0708@tiscali.be)
Date: Mon, 23 Sep 2002 08:18:38 +0200
Subject: [parisc-linux] Mouse stops working when exiting KDE
In-Reply-To: <3D8E3A0B.5090008@earthlink.net>
Message-ID: <3D89CCF000000449@ocpmta6.be.tiscali.com>
>-- Original Message --
>Date: Sun, 22 Sep 2002 16:45:47 -0500
>From: "Bryan W. Headley" <bwheadley@earthlink.net>
>To: Joel Soete <joel.soete@freebel.net>
>CC: Derek Engelhaupt <derekengelhaupt@rocketmail.com>,
> parisc-linux@lists.parisc-linux.org
>Subject: Re: [parisc-linux] Mouse stops working when exiting KDE
>
>
>Joel Soete wrote:
>
>>> I assume you are running the gpm mouse daemon as well. If you tell X
>>> to use the gpm mouse (/dev/gpmdata), you should be okay.
>>
>>
>> Hmm, long time ago I test this (because that was like this I configure
>
>> my i386 boxe) but it did not work. Does it work now on parisc?
>
>Last time I checked, it did. Debconf and I have a difference of opinion
>about it's overwriting XF86Config-4 after I hand-edit it. So and X
>upgrade arrives, and the config file gets overwritten. :-)
>
>>>
>> with kde ?
>
>No, I've seen it with Gnome also, on: alpha, ppc, sparc, and i386.
>
>>
>> Because with the same software config (gdm + xfce + xfree86-4.1) the
>> same problem occurs on my parisc (b180) and not on my i386 (on which I
>
>> also use /dev/psaux as mouse device)?
>>
>
>But, IS gpm running?
Yes on both machine
>Both it and the X server are trying to grab events
>from /dev/psaux...
>
>> (sorry (I would be of better help) I never have time to investigate in
>
>> more details this problem. And I do not remember exactly if it was
>> always there or if it appears with a new release of xfree86 or with a
>> new kernel release? Is some one can refresh my memory?)
>
>Seen it on X 4.0, 4.1 and 4.2. So I'd say it's not kernel-related.
>
Ha Ok
Thanks for info, (I will try to fond time for additional test)
Joel
From joachim.weller@philips.com Mon Sep 23 12:19:01 2002
From: joachim.weller@philips.com (joachim.weller@philips.com)
Date: Mon, 23 Sep 2002 13:19:01 +0200
Subject: [parisc-linux] Problem to load kernel by PALO (B2600)
Message-ID: <OFD78B3766.71BE9B40-ONC1256C3D.003C55CB@diamond.philips.com>
This is a multipart message in MIME format.
--=_alternative 003E97AAC1256C3D_=
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Hi,=20
i'am new to parisc, but have managed to successfully set up=20
an hp715/100 with palinux-0.9.3.
I have downloaded the latest isoimage 2.4.19-pa19-20020922,
from http://pateam.esiee.fr/download.html
Burned to CD and succesfull booted from internal CDROM drive into the IPL.
The problem arises when trying to load the kernel.
I have tried with no success:
1. booting unmodified command line: 0/vmlinux
2. 0/vmlinux32
3. 0/vmlinux64
4. 0/dists/woody/main/disks-hppa/3.0.23-2002-09-22/32/linux.bin
5. 0/dists/woody/main/disks-hppa/3.0.23-2002-09-22/64/linux.bin
after b<enter>, the CD is accessed for about 20 seconds, and then
the almost same error message appears:
---------------------------------------------------------------------------=
---------------------------
Command line for kernel: 'ramdisk=5Fsize=3D8192 root=3D/dev/ram console=3Dt=
ty0=20
sti=3D10/1/3/0 st=5Ffont=3DVGA8x16 TERM=3Dlinux palo=5Fkernel=3D0/vmlinux32'
Selected kernel: /vmlinux32 from partition 0
Selected ramdisk: /ramdiski from partition 0
ELF32 executable
Entry 00100098 first 00100000 n 6
Segment 0 load 00100000 size 2196688 mediaptr 0x1000
Segment 1 load 0031a000 size 467792 mediaptr 0x21a000
Segment 2 load 00390000 size 255656 mediaptr 0x28d000
Segment 3 load 003d0000 size 8192 mediaptr 0x2cc000
Segment 4 load 003d8000 size 32768 mediaptr 0x2ce000
Segment 5 load 00402048 size 110832 mediaptr 0x2d6048
ERROR: Read from boot device failed (status =3D -3).
byteio=5Fread: seekread() returned -1 expected 2195456
ERROR: segment 0 read() failed
Fatal error loading kernel executableERROR: failed to load kernel
---------------------------------------------------------------------------=
---------------------------
In order to exclude CDROM media problems, I tried to burn on
a regular CD (first one was RW), but again with no success.
Reading the Boot-howto didn't help.
Any help very much appreciated !
Regards,
Joachim
Joachim Weller
Philips Medizin Systeme Boeblingen GmbH
Cardiac and Monitoring Systems (CMS) /New Product Engineering=20
Phone: {+49|0}-7031-463-1891
Fax: {+49|0}-7031-463-2112
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F
Gesch=E4ftsf=FChrer: Dr. Werner Haas, David Russell, Wolfgang Strenzl=20
(Sprecher)
Sitz der Gesellschaft: B=F6blingen Registergericht B=F6blingen Reg.-Nr. HRB=
=20
5187=20
Hewlett-Packard Str. 2, D 71034 Boeblingen -GERMANY-
--=_alternative 003E97AAC1256C3D_=
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<br><font size=3D2 face=3D"sans-serif">Hi, </font>
<br><font size=3D2 face=3D"sans-serif">i'am new to parisc, but have managed=
to successfully set up </font>
<br><font size=3D2 face=3D"sans-serif">an hp715/100 with palinux-0.9.3.</fo=
nt>
<br>
<br><font size=3D2 face=3D"sans-serif">I have downloaded the latest isoimag=
e 2.4.19-pa19-20020922,</font>
<br><font size=3D2 face=3D"sans-serif">from http://pateam.esiee.fr/download=
.html</font>
<br><font size=3D2 face=3D"sans-serif">Burned to CD and succesfull booted f=
rom internal CDROM drive into the IPL.</font>
<br><font size=3D2 face=3D"sans-serif">The problem arises when trying to lo=
ad the kernel.</font>
<br><font size=3D2 face=3D"sans-serif">I have tried with no success:</font>
<br><font size=3D2 face=3D"sans-serif">1. booting unmodified command line: =
0/vmlinux</font>
<br><font size=3D2 face=3D"sans-serif">2. 0/vmlinux32</font>
<br><font size=3D2 face=3D"sans-serif">3. 0/vmlinux64</font>
<br><font size=3D2 face=3D"sans-serif">4. 0/dists/woody/main/disks-hppa/3.0=
.23-2002-09-22/32/linux.bin</font>
<br><font size=3D2 face=3D"sans-serif">5. 0/dists/woody/main/disks-hppa/3.0=
.23-2002-09-22/64/linux.bin</font>
<br>
<br><font size=3D2 face=3D"sans-serif">after b<enter>, the CD is acce=
ssed for about 20 seconds, and then</font>
<br><font size=3D2 face=3D"sans-serif">the almost same error message appear=
s:</font>
<br>
<br><font size=3D2 face=3D"sans-serif">------------------------------------=
------------------------------------------------------------------</font>
<br><font size=3D2 face=3D"sans-serif">Command line for kernel: 'ramdisk=5F=
size=3D8192 root=3D/dev/ram console=3Dtty0 sti=3D10/1/3/0 st=5Ffont=3DVGA8x=
16 TERM=3Dlinux palo=5Fkernel=3D0/vmlinux32'</font>
<br><font size=3D2 face=3D"sans-serif">Selected kernel: /vmlinux32 from par=
tition 0</font>
<br><font size=3D2 face=3D"sans-serif">Selected ramdisk: /ramdiski from par=
tition 0</font>
<br><font size=3D2 face=3D"sans-serif">ELF32 executable</font>
<br><font size=3D2 face=3D"sans-serif">Entry 00100098 first 00100000 n 6</f=
ont>
<br><font size=3D2 face=3D"sans-serif">Segment 0 load 00100000 size 2196688=
mediaptr 0x1000</font>
<br><font size=3D2 face=3D"sans-serif">Segment 1 load 0031a000 size 467792 =
mediaptr 0x21a000</font>
<br><font size=3D2 face=3D"sans-serif">Segment 2 load 00390000 size 255656 =
mediaptr 0x28d000</font>
<br><font size=3D2 face=3D"sans-serif">Segment 3 load 003d0000 size 8192 me=
diaptr 0x2cc000</font>
<br><font size=3D2 face=3D"sans-serif">Segment 4 load 003d8000 size 32768 m=
ediaptr 0x2ce000</font>
<br><font size=3D2 face=3D"sans-serif">Segment 5 load 00402048 size 110832 =
mediaptr 0x2d6048</font>
<br>
<br><font size=3D2 face=3D"sans-serif">ERROR: Read from boot device failed =
(status =3D -3).</font>
<br><font size=3D2 face=3D"sans-serif">byteio=5Fread: seekread() returned -=
1 expected 2195456</font>
<br><font size=3D2 face=3D"sans-serif">ERROR: segment 0 read() failed</font>
<br><font size=3D2 face=3D"sans-serif">Fatal error loading kernel executabl=
eERROR: failed to load kernel<br>
---------------------------------------------------------------------------=
---------------------------</font>
<br>
<br><font size=3D2 face=3D"sans-serif">In order to exclude CDROM media prob=
lems, I tried to burn on</font>
<br><font size=3D2 face=3D"sans-serif">a regular CD (first one was RW), but=
again with no success.</font>
<br>
<br><font size=3D2 face=3D"sans-serif">Reading the Boot-howto didn't help.<=
/font>
<br><font size=3D2 face=3D"sans-serif">Any help very much appreciated !</fo=
nt>
<br>
<br><font size=3D2 face=3D"sans-serif">Regards,</font>
<br><font size=3D2 face=3D"sans-serif"> &=
nbsp; Joachim</font>
<br>
<br>
<br><font size=3D2 face=3D"sans-serif"><br>
Joachim Weller<br>
<br>
Philips Medizin Systeme Boeblingen GmbH<br>
Cardiac and Monitoring Systems (CMS) /New Product Engineering <br>
Phone: {+49|0}-7031-463-1891<br>
Fax: {+49|0}-7031-463-2112<br>
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F<br>
Gesch=E4ftsf=FChrer: Dr. Werner Haas, David Russell, Wolfgang Strenzl (Spre=
cher)<br>
Sitz der Gesellschaft: B=F6blingen Registergericht B=F6blingen Reg.-Nr. HRB=
5187 <br>
Hewlett-Packard Str. 2, D 71034 Boeblingen -GERMANY-</f=
ont>
--=_alternative 003E97AAC1256C3D_=--
From varenet@esiee.fr Mon Sep 23 13:01:38 2002
From: varenet@esiee.fr (Thibaut VARENE)
Date: Mon, 23 Sep 2002 14:01:38 +0200
Subject: [parisc-linux] Problem to load kernel by PALO (B2600)
References: <OFD78B3766.71BE9B40-ONC1256C3D.003C55CB@diamond.philips.com>
Message-ID: <3D8F02A2.9040906@esiee.fr>
joachim.weller@philips.com wrote:
>
> Hi,
> i'am new to parisc, but have managed to successfully set up
> an hp715/100 with palinux-0.9.3.
>
> I have downloaded the latest isoimage 2.4.19-pa19-20020922,
> from http://pateam.esiee.fr/download.html
>
> In order to exclude CDROM media problems, I tried to burn on
> a regular CD (first one was RW), but again with no success.
>
> Reading the Boot-howto didn't help.
> Any help very much appreciated !
>
Hi,
I've just burned this netinst on a RW and tried it on a L1000 (I don't
have a 715 to test it on alas), and it booted perfectly well.
Therefore I don't think this is an ISO problem, but rather a CD-ROM pb.
Maybe your CD-ROM driver isn't supported... Or damaged.
Have you tried with another one ?
HTH,
Thibaut VARENE
PA/Linux ESIEE Team
http://pateam.esiee.fr/
From varenet@esiee.fr Mon Sep 23 13:05:56 2002
From: varenet@esiee.fr (Thibaut VARENE)
Date: Mon, 23 Sep 2002 14:05:56 +0200
Subject: [parisc-linux] Problem to load kernel by PALO (B2600)
References: <OFD78B3766.71BE9B40-ONC1256C3D.003C55CB@diamond.philips.com> <3D8F02A2.9040906@esiee.fr>
Message-ID: <3D8F03A4.3070005@esiee.fr>
Thibaut VARENE wrote:
> Maybe your CD-ROM driver isn't supported... Or damaged.
My bad replying to myself.
To make it clear: I meant CD-ROM drive, not 'driver'.
Sorry.
Thibaut VARENE
PA/Linux ESIEE Team
http://pateam.esiee.fr/
From joachim.weller@philips.com Mon Sep 23 13:22:26 2002
From: joachim.weller@philips.com (joachim.weller@philips.com)
Date: Mon, 23 Sep 2002 14:22:26 +0200
Subject: [parisc-linux] Problem to load kernel by PALO (B2600) (solved)
Message-ID: <OF21F6FF71.D4840A4E-ONC1256C3D.00405FDB@diamond.philips.com>
This is a multipart message in MIME format.
--=_alternative 00446629C1256C3D_=
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Please ignore my posted problem. I apologize not having
realized, that my download was incomplete, although
mozilla download manager listed: "finished 73376 KB of 73376 KB"
Just missed to md5sum the download !
New download was ok. Sucessfully booted into installation menu !
Joachim
Joachim Weller
Philips Medizin Systeme Boeblingen GmbH
Cardiac and Monitoring Systems (CMS) /New Product Engineering=20
Phone: {+49|0}-7031-463-1891
Fax: {+49|0}-7031-463-2112
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F
Gesch=E4ftsf=FChrer: Dr. Werner Haas, David Russell, Wolfgang Strenzl=20
(Sprecher)
Sitz der Gesellschaft: B=F6blingen Registergericht B=F6blingen Reg.-Nr. HRB=
=20
5187=20
Hewlett-Packard Str. 2, D 71034 Boeblingen -GERMANY-
--=_alternative 00446629C1256C3D_=
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<br><font size=3D2 face=3D"sans-serif">Please ignore my posted problem. I a=
pologize not having</font>
<br><font size=3D2 face=3D"sans-serif">realized, that my download was incom=
plete, although</font>
<br><font size=3D2 face=3D"sans-serif">mozilla download manager listed: &qu=
ot;finished 73376 KB of 73376 KB"</font>
<br><font size=3D2 face=3D"sans-serif">Just missed to md5sum the download !=
</font>
<br><font size=3D2 face=3D"sans-serif">New download was ok. Sucessfully boo=
ted into installation menu !</font>
<br>
<br><font size=3D2 face=3D"sans-serif">Joachim<br>
<br>
Joachim Weller<br>
<br>
Philips Medizin Systeme Boeblingen GmbH<br>
Cardiac and Monitoring Systems (CMS) /New Product Engineering <br>
Phone: {+49|0}-7031-463-1891<br>
Fax: {+49|0}-7031-463-2112<br>
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F<br>
Gesch=E4ftsf=FChrer: Dr. Werner Haas, David Russell, Wolfgang Strenzl (Spre=
cher)<br>
Sitz der Gesellschaft: B=F6blingen Registergericht B=F6blingen Reg.-Nr. HRB=
5187 <br>
Hewlett-Packard Str. 2, D 71034 Boeblingen -GERMANY-</f=
ont>
--=_alternative 00446629C1256C3D_=--
From spacenka@lightlink.com Mon Sep 23 16:00:27 2002
From: spacenka@lightlink.com (Steve Pacenka)
Date: 23 Sep 2002 11:00:27 -0400
Subject: [parisc-linux] RTC and FB on 735/125
In-Reply-To: <03ed01c26280$4dfb5c90$1f96078d@acid>
References: <03ab01c26266$2416dea0$1f96078d@acid>
<20020922220323.0113cbca.varenet@esiee.fr>
<03bf01c2627c$9a5147c0$1f96078d@acid> <03ed01c26280$4dfb5c90$1f96078d@acid>
Message-ID: <1032793227.1848.222.camel@romano>
On Sun, 2002-09-22 at 17:37, Yves Bodack wrote:
> replying to myself ...
>
> > and with 8 bpp it says:
> >
> > (EE) FBDev(0): No Display subsection in Screen section "Default Screen"
> for
> > depth/fbbpp 24/24
> > (EE) Screen(s) found, but none have a usable configuration.
> > Fatal server error:
> > no screens found
>
> same with 16 or 32 bpp :(
Try the following in XF86Config-4
Section Screen
... (whatever else you need here) ...
DefaultDepth 24
DefaultFbBpp 32
SubSection Display
Depth 24
Modes "1280x1024"
EndSubSection
EndSection
-- SP
From jeremyd@apptechsys.com Mon Sep 23 17:18:31 2002
From: jeremyd@apptechsys.com (Jeremy Drake)
Date: Mon, 23 Sep 2002 09:18:31 -0700 (PDT)
Subject: [parisc-linux] Do you know the three HGH products?
In-Reply-To: <000301c2623e$776cf940$0100a8c0@PLUTO>
Message-ID: <Pine.LNX.4.44.0209230915340.20374-100000@garibaldi.apptechsys.com>
On Sun, 22 Sep 2002, Tobias Giesen wrote:
> Hi all,
>
> funny spam that was, wasn't it ...
> especially this part:
>
> > This message is not intended for
> > residents in the states of CA, NC,
> > NV, RI, TN, VA & WA.
>
> I wonder why? Is their product illegal
> in those states?
In WA, at least, spam is "illegal" and would get them a hefty fine. I
just wish it had more of an effect than adding that disclaimer to emails.
>
> BTW is there anything true about the
> HGH or is it all lies ...
>
> Cheers,
> Tobias
>
> _______________________________________________
> parisc-linux mailing list
> parisc-linux@lists.parisc-linux.org
> http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
>
--
"An ounce of prevention is worth a ton of code."
-- an anonymous programmer
From jeremyd@apptechsys.com Mon Sep 23 18:23:52 2002
From: jeremyd@apptechsys.com (Jeremy Drake)
Date: Mon, 23 Sep 2002 10:23:52 -0700 (PDT)
Subject: [parisc-linux] SMP kernel problems on a D350
In-Reply-To: <20020921044102.3DD104829@dsl2.external.hp.com>
Message-ID: <Pine.LNX.4.44.0209231021010.20374-100000@garibaldi.apptechsys.com>
On Fri, 20 Sep 2002, Grant Grundler wrote:
> If you have time, could you reproduce the "lockup" and then hit "TOC" button?
> If you cancel autoboot and get a PDC prompt (eg "BOOT_ADMIN>"), "ser pim"
> output will contain machine state when it was TOCed. Capture and Post that
> output to the mailing list and someone might see what the problem is.
>
OK. Here it is.... The kernel is 2.4.19-64-smp from unstable, version
18.1, so the System.map can be found there...
krakatoa:~# /bin/sh /etc/init.d/setserial start
Loading the saved-state of the serial devices...
Cannot set serial info: Device or resource busy
/dev/ttyS0 at 0x03f8 (irq = 195) is a 16550A
Firmware Version 5.0
Duplex Console IO Dependent Code (IODC) revision 1
------------------------------------------------------------------------------
(c) Copyright 1995-2000, Hewlett-Packard Company, All rights reserved
------------------------------------------------------------------------------
Processor Speed State Coprocessor State I/D Cache
--------- -------- --------------------- ----------------- -------------
0 440 MHz Active Functional 512 kB/1 MB
1 440 MHz Idle Functional 512 kB/1 MB
Central Bus Speed: 120 MHz
Available memory: 536870912 bytes
Good memory required: 46678016 bytes
Primary boot path: FWSCSI.5.0
Alternate boot path: FWSCSI.6.0
Console path: SERIAL_1.9600.8.none
Keyboard path: PCI8.0.0
Processor is booting from first available device.
To discontinue, press any key within 10 seconds.
Boot terminated.
----- Main Menu -------------------------------------------------------------
Command Description
------- -----------
BOot [PRI|ALT|<path>] Boot from specified path
PAth [PRI|ALT|CON|KEY [<path>]] Display or modify a path
SEArch [DIsplay|[[IPL] [<path>]]] Search for boot devices
COnfiguration [<command>] Access Configuration menu/commands
INformation [<command>] Access Information menu/commands
SERvice [<command>] Access Service menu/commands
DIsplay Redisplay the current menu
HElp [<menu>|<command>] Display help for menu or command
RESET Restart the system
-----
Main Menu: Enter command > ser pim toc
PROCESSOR PIM INFORMATION
----------------- Processor 0 TOC Information -------------------
General Registers 0 - 31
00-03 0000000000000000 0000000010478480 000000001010ded4 0000000010435ac8
04-07 0000000000000041 0000000000000001 0000000000000000 0000000000000000
08-11 000000001054b5a0 0000000000000003 00000000105b8b40 00000000105646cc
12-15 0000000000000000 00000000ffffffff 0000000000000001 00000000f0400004
16-19 00000000105b8b40 00000000f000017c 00000000f0000174 0000000000000000
20-23 0000000000000000 0000000000000000 00000000104456a0 00000000105555a0
24-27 00000000105b8b40 0000000000000041 0000000010435ac8 000000001054b5a0
28-31 0000000000000000 00000000105b8ef0 00000000105b9000 000000001055e5a0
<Press any key to continue (q to quit)>
Control Registers 0 - 31
00-03 0000000000000000 0000000000000000 0000000000000000 0000000000000000
04-07 0000000000000000 0000000000000000 0000000000000000 0000000000000000
08-11 000000000000295a 0000000000000000 00000000000000c0 000000000000003f
12-15 0000000000000000 0000000000000000 0000000000107000 0000000000000000
16-19 00005f379490dc48 0000000000000000 000000001010de1c 0000000000000000
20-23 0000000000000000 0000000000000000 0000007f082cff0e a000000000000000
24-27 0000000000487000 0000000015bc1000 0000000000044021 00000000f0412000
28-31 0000000055555555 0000000055555555 00000000105b8000 00000000105c0000
Space Registers 0 - 7
00-03 000a5680 000a5680 00000000 000a5680
04-07 00000000 00000000 00000000 00000000
IIA Space = 0x0000000000000000
IIA Offset = 0x000000001010de0c
CPU State = 0x9e000001
Main Menu: Enter command >
Main Menu: Enter command > reset
Resetting...
--
If a child annoys you, quiet him by brushing his hair. If this doesn't
work, use the other side of the brush on the other end of the child.
From bodack@stud.fh-heilbronn.de Mon Sep 23 18:36:57 2002
From: bodack@stud.fh-heilbronn.de (Yves Bodack)
Date: Mon, 23 Sep 2002 19:36:57 +0200
Subject: [parisc-linux] RTC and FB on 735/125
References: <03ab01c26266$2416dea0$1f96078d@acid><20020922220323.0113cbca.varenet@esiee.fr><03bf01c2627c$9a5147c0$1f96078d@acid> <03ed01c26280$4dfb5c90$1f96078d@acid> <1032793227.1848.222.camel@romano>
Message-ID: <003001c26327$d0db42e0$1f96078d@acid>
hi steve,
great, this did the trick. thank's a lot. it's quite slow, but it works in
true color :)
greetings yves...
From: "Steve Pacenka" <spacenka@lightlink.com>
Subject: Re: [parisc-linux] RTC and FB on 735/125
> On Sun, 2002-09-22 at 17:37, Yves Bodack wrote:
> > replying to myself ...
> >
> > > and with 8 bpp it says:
> > >
> > > (EE) FBDev(0): No Display subsection in Screen section "Default
Screen"
> > for
> > > depth/fbbpp 24/24
> > > (EE) Screen(s) found, but none have a usable configuration.
> > > Fatal server error:
> > > no screens found
> >
> > same with 16 or 32 bpp :(
>
>
> Try the following in XF86Config-4
>
> Section Screen
> ... (whatever else you need here) ...
>
> DefaultDepth 24
> DefaultFbBpp 32
>
> SubSection Display
> Depth 24
> Modes "1280x1024"
> EndSubSection
>
> EndSection
>
> -- SP
From spacenka@lightlink.com Mon Sep 23 19:46:16 2002
From: spacenka@lightlink.com (Steve Pacenka)
Date: 23 Sep 2002 14:46:16 -0400
Subject: [parisc-linux] RTC and FB on 735/125
In-Reply-To: <003001c26327$d0db42e0$1f96078d@acid>
References: <03ab01c26266$2416dea0$1f96078d@acid><20020922220323.0113cbca.varenet@esiee.
fr><03bf01c2627c$9a5147c0$1f96078d@acid>
<03ed01c26280$4dfb5c90$1f96078d@acid> <1032793227.1848.222.camel@romano>
<003001c26327$d0db42e0$1f96078d@acid>
Message-ID: <1032806776.2868.19.camel@romano>
On Mon, 2002-09-23 at 13:36, Yves Bodack wrote:
> hi steve,
> great, this did the trick. thank's a lot. it's quite slow, but it works in
> true color :)
Yves,
It's faster than the Macintosh Quadra 610 (another Linux victim) that
I'm typing on now :^) .
Could you please post your experience at getting X applications to work
now that you have X and a desktop? I got basic gnome things to work
flawlessly, but failed on my 735/99 with xmms, xemacs, and galeon or
mozilla.
The CRX24 framebuffer also works at 8 bit color, a bit faster. A minor
patch to one file in the kernel is needed (duplicating a few lines that
apply to another card's depth selection in the same file) and a kernel
boot argument is needed to (optionally) cause the kernel to start video
in 8 bit mode instead of the default 32.
The hard drive I patched this on is recycled into another type of box,
but Helge Deller can guess what's needed just from this description.
-- regards, SP
>
> greetings yves...
>
>
> From: "Steve Pacenka" <spacenka@lightlink.com>
> Subject: Re: [parisc-linux] RTC and FB on 735/125
>
>
> > On Sun, 2002-09-22 at 17:37, Yves Bodack wrote:
> > > replying to myself ...
> > >
> > > > and with 8 bpp it says:
> > > >
> > > > (EE) FBDev(0): No Display subsection in Screen section "Default
> Screen"
> > > for
> > > > depth/fbbpp 24/24
> > > > (EE) Screen(s) found, but none have a usable configuration.
> > > > Fatal server error:
> > > > no screens found
> > >
> > > same with 16 or 32 bpp :(
> >
> >
> > Try the following in XF86Config-4
> >
> > Section Screen
> > ... (whatever else you need here) ...
> >
> > DefaultDepth 24
> > DefaultFbBpp 32
> >
> > SubSection Display
> > Depth 24
> > Modes "1280x1024"
> > EndSubSection
> >
> > EndSection
> >
> > -- SP
>
> _______________________________________________
> parisc-linux mailing list
> parisc-linux@lists.parisc-linux.org
> http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
>
>
From bodack@stud.fh-heilbronn.de Mon Sep 23 21:10:24 2002
From: bodack@stud.fh-heilbronn.de (Yves Bodack)
Date: Mon, 23 Sep 2002 22:10:24 +0200
Subject: [parisc-linux] RTC and FB on 735/125
References: <03ab01c26266$2416dea0$1f96078d@acid> <02092218054100.14750@localhost.localdomain>
Message-ID: <001101c2633d$40a33d70$1f96078d@acid>
Hi,
i got this problem solved by myself. I read out DATE in BOOT ADMIN Console
and it gave me an error (with a dump a of many zeros). Then I set a new date
in PDC and now it works just fine. So somehow the RTC was zeroed out.
Greetings Yves...
From: "Michael S. Zick" <mszick@goquest.com>
Subject: Re: [parisc-linux] RTC and FB on 735/125
> On Sunday 22 September 2002 01:30 pm, Yves Bodack wrote:
> > 1st problem I have is the Real Time Clock. On boot I get the following
> > messages:
> >
> > System Time was Thu Jan 1 00:00:10 UTC 1970
> > Setting the System Clock using the Hardware Clock as reference...
> > RTC_RD_TIME: Bad address
> > ioctl() to /dev/rtc read the time failed.
> > System Clock set. System local time is now Thu Jan 1 00:00:13 UTC 1970.
> >
> Perhaps it is really a good address and a bad clock battery.
> Mike
From deller@gmx.de Mon Sep 23 21:18:08 2002
From: deller@gmx.de (Helge Deller)
Date: Mon, 23 Sep 2002 22:18:08 +0200
Subject: [parisc-linux] RTC and FB on 735/125
In-Reply-To: <1032806776.2868.19.camel@romano>
References: <03ab01c26266$2416dea0$1f96078d@acid> <003001c26327$d0db42e0$1f96078d@acid> <1032806776.2868.19.camel@romano>
Message-ID: <200209232217.45577.deller@gmx.de>
On Monday 23 September 2002 20:46, Steve Pacenka wrote:
> The CRX24 framebuffer also works at 8 bit color, a bit faster. A minor
> patch to one file in the kernel is needed (duplicating a few lines that
> apply to another card's depth selection in the same file) and a kernel
> boot argument is needed to (optionally) cause the kernel to start video
> in 8 bit mode instead of the default 32.
>
> The hard drive I patched this on is recycled into another type of box,
> but Helge Deller can guess what's needed just from this description.
Hi Steve,
I don't have a CRX24 and can't test anything.
If you could post a patch here I could add it to the kernel.
Greetings,
Helge
From spacenka@lightlink.com Mon Sep 23 22:04:16 2002
From: spacenka@lightlink.com (Steve Pacenka)
Date: 23 Sep 2002 17:04:16 -0400
Subject: [parisc-linux] RTC and FB on 735/125
In-Reply-To: <200209232217.45577.deller@gmx.de>
References: <03ab01c26266$2416dea0$1f96078d@acid>
<003001c26327$d0db42e0$1f96078d@acid> <1032806776.2868.19.camel@romano>
<200209232217.45577.deller@gmx.de>
Message-ID: <1032815056.3209.115.camel@romano>
On Mon, 2002-09-23 at 16:18, Helge Deller wrote:
> On Monday 23 September 2002 20:46, Steve Pacenka wrote:
> > The CRX24 framebuffer also works at 8 bit color, a bit faster. A minor
> > patch to one file in the kernel is needed (duplicating a few lines that
> > apply to another card's depth selection in the same file) and a kernel
> > boot argument is needed to (optionally) cause the kernel to start video
> > in 8 bit mode instead of the default 32.
> >
> > The hard drive I patched this on is recycled into another type of box,
> > but Helge Deller can guess what's needed just from this description.
>
> Hi Steve,
>
> I don't have a CRX24 and can't test anything.
> If you could post a patch here I could add it to the kernel.
Good day Helge,
I can't test easily either, or generate formal patches, since my 735
w/CRX24 is in a display at our computer recycle shop.
>From memory, after consulting CVS today --
1. In drivers/video/sti/stifb.c
Inside function
int __init
stifb_init_fb(struct sti_struct *sti, int force_bpp)
old:
case S9000_ID_A1439A: /* CRX24/A1439A */
bpp = 32;
break;
new (insert three lines below the case):
case S9000_ID_A1439A: /* CRX24/A1439A */
if (force_bpp == 8 || force_bpp == 32)
bpp = force_bpp;
else
bpp = 32;
break;
This is copied from HCRX initialization in the same switch.
2. To activate include in the kernel boot arguments (PALO or interrupt
boot with ESC):
video=stifb:bpp:8
This is also recognized
video=stifb:bpp:32
but that is the default.
3. To use with X, set the DefaultDepth to 8 in XF86Config-4 (leaving
fbbpp at 32), or
startx -- -depth 8
Requires a depth 8 subsection in the monitor size section.
Perhaps Yves can test?
-- cheers, SP
From deller@gmx.de Mon Sep 23 22:23:10 2002
From: deller@gmx.de (Helge Deller)
Date: Mon, 23 Sep 2002 23:23:10 +0200
Subject: [parisc-linux] RTC and FB on 735/125
In-Reply-To: <1032815056.3209.115.camel@romano>
References: <03ab01c26266$2416dea0$1f96078d@acid> <200209232217.45577.deller@gmx.de> <1032815056.3209.115.camel@romano>
Message-ID: <200209232323.10789.deller@gmx.de>
On Monday 23 September 2002 23:04, Steve Pacenka wrote:
> On Mon, 2002-09-23 at 16:18, Helge Deller wrote:
> > On Monday 23 September 2002 20:46, Steve Pacenka wrote:
> > > The CRX24 framebuffer also works at 8 bit color, a bit faster. A minor
> > > patch to one file in the kernel is needed (duplicating a few lines that
> > > apply to another card's depth selection in the same file) and a kernel
> > > boot argument is needed to (optionally) cause the kernel to start video
> > > in 8 bit mode instead of the default 32.
> > >
> > > The hard drive I patched this on is recycled into another type of box,
> > > but Helge Deller can guess what's needed just from this description.
> >
> > Hi Steve,
> >
> > I don't have a CRX24 and can't test anything.
> > If you could post a patch here I could add it to the kernel.
>
> Good day Helge,
>
> I can't test easily either, or generate formal patches, since my 735
> w/CRX24 is in a display at our computer recycle shop.
>
>
> From memory, after consulting CVS today --
>
> 1. In drivers/video/sti/stifb.c
>
> Inside function
> int __init
> stifb_init_fb(struct sti_struct *sti, int force_bpp)
>
>
> old:
>
> case S9000_ID_A1439A: /* CRX24/A1439A */
> bpp = 32;
> break;
>
>
> new (insert three lines below the case):
> case S9000_ID_A1439A: /* CRX24/A1439A */
> if (force_bpp == 8 || force_bpp == 32)
> bpp = force_bpp;
> else
> bpp = 32;
> break;
>
>
> This is copied from HCRX initialization in the same switch.
>
>
> 2. To activate include in the kernel boot arguments (PALO or interrupt
> boot with ESC):
>
> video=stifb:bpp:8
>
> This is also recognized
>
> video=stifb:bpp:32
>
> but that is the default.
>
>
> 3. To use with X, set the DefaultDepth to 8 in XF86Config-4 (leaving
> fbbpp at 32), or
>
> startx -- -depth 8
>
> Requires a depth 8 subsection in the monitor size section.
>
>
> Perhaps Yves can test?
>
> -- cheers, SP
Thanks Steve,
I've applied this patch to 2.4.19-pa20.
Greetings,
Helge
From Christian Weerts <christian@familie-weerts.de> Mon Sep 23 23:05:41 2002
From: Christian Weerts <christian@familie-weerts.de> (Christian Weerts)
Date: Tue, 24 Sep 2002 00:05:41 +0200
Subject: [parisc-linux] Problems with 715/80
In-Reply-To: <BD69FB20-CEA3-11D6-827A-000393581E44@telocity.com>
References: <20020922211630.GB1936@familie-weerts.de> <BD69FB20-CEA3-11D6-827A-000393581E44@telocity.com>
Message-ID: <20020923220541.GA962@familie-weerts.de>
* Chuck Slivkoff <caslivkoff@telocity.com> [020923 05:22]:
> I would suggest that you disconnect any disks and power on the box.
> Make sure your null-modem cable is attached to serial port "a" and no
> keyboard is attached via the PS2/HIL adapter box. You will need to get
> to the PCD "BOOT_ADMIN>" prompt before you can get any further. If you
> can not get to this prompt, take note of the LED's being displayed. The
> service manual for the 715 should help to decode the LED's.
>
> http://h20000.www2.hp.com/bizsupport/
> CoreRedirect.jsp?targetPage=http%3A%2F%2Fh200002.www2.hp.com%2Fbc%2Fdocs
> %2Fsupport%2FSupportManual%2Flpv37699%2Flpv37699.pdf
>
> Hope this helps.
>
It does. With the manual i decode the LED's. They say:
Memory error! Ughf, after a long period not running the
machine a matter of time i think. So i go on and cleaned the
memory-sticks and the memory-banks 0-3. But that wasn't very
helpful. Changing the sticks to serveral banks (i did it
more than an half hour) gave me also no result. Once there
was another message from the LED's - HPMC due to memory
error! Not very helpful for me.
What kind of sticks are normal or the best one? Is there a
prefered memory-bank to use? The memory in this machine was
attached to bank 3+2 with 72-Pin NEC and Noname chips. But
both "Made in Puerto Rico" ;). I never (really) changed the
memory since the time i got the machine.
Greets,
Christian
--
[X] <--- Nail here for new Monitor.
From viiru@debian.org Tue Sep 24 07:05:41 2002
From: viiru@debian.org (Arto Jantunen)
Date: Tue, 24 Sep 2002 09:05:41 +0300
Subject: [parisc-linux] SMP problems
Message-ID: <20020924060541.GA27852@dt-link.fi>
Any news on the SMP trouble on PA-8200 and similar? Someone said that he
would be working on it last week. I heard some stuff about it working on
64-bit kernels, but 64-bit crashes immediately on my box, SMP or no SMP.
I would really like to get this monster doing some real work, so any
news is good news.
--
Arto Jantunen
From jeremyd@apptechsys.com Tue Sep 24 09:48:31 2002
From: jeremyd@apptechsys.com (Jeremy Drake)
Date: Tue, 24 Sep 2002 01:48:31 -0700 (PDT)
Subject: [parisc-linux] SMP problems
In-Reply-To: <20020924060541.GA27852@dt-link.fi>
Message-ID: <Pine.LNX.4.44.0209240141510.20374-100000@garibaldi.apptechsys.com>
On Tue, 24 Sep 2002, Arto Jantunen wrote:
> Any news on the SMP trouble on PA-8200 and similar? Someone said that he
> would be working on it last week. I heard some stuff about it working on
> 64-bit kernels, but 64-bit crashes immediately on my box, SMP or no SMP.
> I would really like to get this monster doing some real work, so any
> news is good news.
I don't know exactly what hardware you have, but my J5k is chugging
happily along running 2.4.19-64-smp from sid, and the only problem I have
encountered as of yet is a lockup when starting setserial on boot. Other
than that, it seems to be as stable as uniproc 32-bit. Whatever hardware
you have, I'm willing to bet that it isn't a J5k, and any differences
involved may complicate things, so (as always) YMMV.
Good luck...
> > -- > Arto
Jantunen > _______________________________________________
> parisc-linux mailing list
> parisc-linux@lists.parisc-linux.org
> http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
>
--
You had mail. Paul read it, so ask him what it said.
From ghub005@xtra.co.nz Tue Sep 24 10:18:27 2002
From: ghub005@xtra.co.nz (Gavin Hubbard)
Date: Tue, 24 Sep 2002 21:18:27 +1200
Subject: [parisc-linux] WTS: workstation ram
Message-ID: <3.0.2.32.20020924211827.0069032c@pop3.xtra.co.nz>
Hi
I usually just lurk here, but I've got a bunch of HP workstation memory
left over from a recent round of upgrades and I figure that it would be
useful if people here got the first chance at it.
I have twenty used A4994A modules. These are the 256MB, 120MHz SDRAM
modules that work in the B1000, B2000, B2600, C3000, C3600, C3650, C3700,
J5600, J6000, J6700, J7000 workstations. Please note that some of those
systems require the modules to be added in pairs.
Asking price is 75USD per module. Please email me off-list if you're
interested.
Regards,
Gavin Hubbard
P.S. Please advise me if this is inappropriate content for this forum and
I'll go back to lurking.
From viiru@debian.org Tue Sep 24 12:28:30 2002
From: viiru@debian.org (Arto Jantunen)
Date: Tue, 24 Sep 2002 14:28:30 +0300
Subject: [parisc-linux] SMP problems
In-Reply-To: <Pine.LNX.4.44.0209240141510.20374-100000@garibaldi.apptechsys.com>
References: <20020924060541.GA27852@dt-link.fi> <Pine.LNX.4.44.0209240141510.20374-100000@garibaldi.apptechsys.com>
Message-ID: <20020924112830.GA27877@dt-link.fi>
On Tue, Sep 24, 2002 at 01:48:31AM -0700, Jeremy Drake wrote:
> On Tue, 24 Sep 2002, Arto Jantunen wrote:
>
> > Any news on the SMP trouble on PA-8200 and similar? Someone said that he
> > would be working on it last week. I heard some stuff about it working on
> > 64-bit kernels, but 64-bit crashes immediately on my box, SMP or no SMP.
> > I would really like to get this monster doing some real work, so any
> > news is good news.
> I don't know exactly what hardware you have, but my J5k is chugging
> happily along running 2.4.19-64-smp from sid, and the only problem I have
> encountered as of yet is a lockup when starting setserial on boot. Other
> than that, it seems to be as stable as uniproc 32-bit. Whatever hardware
> you have, I'm willing to bet that it isn't a J5k, and any differences
> involved may complicate things, so (as always) YMMV.
I have a HP9000/D390. Dual PA-8200. It doesn't boot at all with that
kernel or any other 64-bit kernel. Some things do suggest that it should
work, but it doesn't. After the kernel branching point it starts
scrolling FLT codes on the LCD display, but doesn't report anything on
the console. I have a ser pim output taken out after rebooting the box
if someone is interrested. I'll try building the latest CVS with 32-bit
and SMP and see if it's any better then the ones I have tried so far.
--
Arto Jantunen
From bodack@stud.fh-heilbronn.de Tue Sep 24 12:42:28 2002
From: bodack@stud.fh-heilbronn.de (Yves Bodack)
Date: Tue, 24 Sep 2002 13:42:28 +0200
Subject: [parisc-linux] RTC and FB on 735/125
References: <03ab01c26266$2416dea0$1f96078d@acid><20020922220323.0113cbca.varenet@esiee. fr><03bf01c2627c$9a5147c0$1f96078d@acid> <03ed01c26280$4dfb5c90$1f96078d@acid> <1032793227.1848.222.camel@romano> <003001c26327$d0db42e0$1f96078d@acid> <1032806776.2868.19.camel@romano>
Message-ID: <002a01c263bf$76340820$1f96078d@acid>
From: "Steve Pacenka" <spacenka@lightlink.com>
Subject: Re: [parisc-linux] RTC and FB on 735/125
> Could you please post your experience at getting X applications to work
> now that you have X and a desktop? I got basic gnome things to work
> flawlessly, but failed on my 735/99 with xmms, xemacs, and galeon or
> mozilla.
Galeon/Mozilla and XMMS start up, but they don't appear on screen and give
no errors. xemacs can't be installed, while dselect misses some dependent
packages.
I'm running KDE, that is slow but proper. And I have a woking browser at
last.
Greets,
yves...
From varenet@esiee.fr Tue Sep 24 12:55:53 2002
From: varenet@esiee.fr (Thibaut VARENE)
Date: Tue, 24 Sep 2002 13:55:53 +0200
Subject: [parisc-linux] RTC and FB on 735/125
References: <03ab01c26266$2416dea0$1f96078d@acid><20020922220323.0113cbca.varenet@esiee. fr><03bf01c2627c$9a5147c0$1f96078d@acid> <03ed01c26280$4dfb5c90$1f96078d@acid> <1032793227.1848.222.camel@romano> <003001c26327$d0db42e0$1f96078d@acid> <1032806776.2868.19.camel@romano> <002a01c263bf$76340820$1f96078d@acid>
Message-ID: <3D9052C9.3060704@esiee.fr>
Yves Bodack wrote:
> From: "Steve Pacenka" <spacenka@lightlink.com>
> Subject: Re: [parisc-linux] RTC and FB on 735/125
>
>
>
>>Could you please post your experience at getting X applications to work
>>now that you have X and a desktop? I got basic gnome things to work
>>flawlessly, but failed on my 735/99 with xmms, xemacs, and galeon or
>>mozilla.
>
> Galeon/Mozilla and XMMS start up, but they don't appear on screen and give
Galeon/Mozilla is b0rken on hppa. You can try either Links or Konqueror...
for XMMS I don't know...
HTH,
Thibaut VARENE
PA/Linux ESIEE Team
http://pateam.esiee.fr/
From Ralf.Hildebrandt@charite.de Tue Sep 24 13:02:01 2002
From: Ralf.Hildebrandt@charite.de (Ralf Hildebrandt)
Date: Tue, 24 Sep 2002 14:02:01 +0200
Subject: [parisc-linux] RTC and FB on 735/125
In-Reply-To: <3D9052C9.3060704@esiee.fr>
References: <03ed01c26280$4dfb5c90$1f96078d@acid> <1032793227.1848.222.camel@romano> <003001c26327$d0db42e0$1f96078d@acid> <1032806776.2868.19.camel@romano> <002a01c263bf$76340820$1f96078d@acid> <3D9052C9.3060704@esiee.fr>
Message-ID: <20020924120201.GC15201@charite.de>
Am 24.09.2002 um 13:55:53 +0200 schrieb Thibaut VARENE folgendes:
> >Galeon/Mozilla and XMMS start up, but they don't appear on screen and give
> Galeon/Mozilla is b0rken on hppa. You can try either Links or Konqueror...
> for XMMS I don't know...
And I must say, konqueror is quite acceptable.
--
Ralf Hildebrandt (Im Auftrag des Referat V A) Ralf.Hildebrandt@charite.de
Charite Campus Virchow-Klinikum Tel. +49 (0)30-450 570-155
Referat V A - Kommunikationsnetze - Fax. +49 (0)30-450 570-916
Why you can't find your system administrators:
they're busy updating their BOFH excuse server
From willy@debian.org Tue Sep 24 13:29:34 2002
From: willy@debian.org (Matthew Wilcox)
Date: Tue, 24 Sep 2002 13:29:34 +0100
Subject: [parisc-linux] SMP problems
In-Reply-To: <20020924112830.GA27877@dt-link.fi>; from viiru@debian.org on Tue, Sep 24, 2002 at 02:28:30PM +0300
References: <20020924060541.GA27852@dt-link.fi> <Pine.LNX.4.44.0209240141510.20374-100000@garibaldi.apptechsys.com> <20020924112830.GA27877@dt-link.fi>
Message-ID: <20020924132934.F27458@parcelfarce.linux.theplanet.co.uk>
On Tue, Sep 24, 2002 at 02:28:30PM +0300, Arto Jantunen wrote:
> I have a HP9000/D390. Dual PA-8200. It doesn't boot at all with that
> kernel or any other 64-bit kernel. Some things do suggest that it should
> work, but it doesn't. After the kernel branching point it starts
> scrolling FLT codes on the LCD display, but doesn't report anything on
> the console. I have a ser pim output taken out after rebooting the box
> if someone is interrested. I'll try building the latest CVS with 32-bit
> and SMP and see if it's any better then the ones I have tried so far.
Do you have the CAP/MUX card installed? (the card with the other serial
port on it) If so, you should enable "Serial MUX support" and make
sure to use console=ttyB0 on the command line (ie pretend you have a K
class machine).
--
Revolutions do not require corporate support.
From joachim.weller@philips.com Tue Sep 24 13:40:33 2002
From: joachim.weller@philips.com (joachim.weller@philips.com)
Date: Tue, 24 Sep 2002 14:40:33 +0200
Subject: [parisc-linux] Help wanted: XF86Config (B2600)
Message-ID: <OF52713812.E62609E7-ONC1256C3E.0044B75D@diamond.philips.com>
This is a multipart message in MIME format.
--=_alternative 00460EA7C1256C3E_=
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Hi,
since yesterday, I have up and running a B2600 with Debian woody 3.0,
but I can't setup X11 Configuration for the built in PCI Grafic card,
using framebuffer driver.
The error message in /etc/XFree86.0.log (XFree86 Version 4.1.0.1)=20
says:
(EE) No devices detected.
although I have put in /etc/X11/XF86Config:
Section "Device"
BoardName "hp-3D"
Identifier "Device[0]"
BusID "1:3:0"=20
Driver "fbdev"
Option "UseFBDev" "true"
Screen 0
EndSection
The BusID was determined by "cat /proc/pci" :
Bus 1, device 3, function 0:
3D controller: PCI device 103c:108b (Hewlett-Packard Company) (rev 5).
IRQ 258.
Master Capable. Latency=3D255.
Prefetchable 64 bit memory at 0xfffffffffb000000=20
[0xfffffffffbffffff].
Non-prefetchable 64 bit memory at 0xfffffffffa000000=20
[0xfffffffffaffffff].
If anybody has the same grafic card running, I would very much appreciate
to get a working XF86Config or any tips to resolve that problem.
Regards,
Joachim
Joachim Weller
Philips Medizin Systeme Boeblingen GmbH
Cardiac and Monitoring Systems (CMS) /New Product Engineering=20
Phone: {+49|0}-7031-463-1891
Fax: {+49|0}-7031-463-2112
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F
Gesch=E4ftsf=FChrer: Dr. Werner Haas, David Russell, Wolfgang Strenzl=20
(Sprecher)
Sitz der Gesellschaft: B=F6blingen Registergericht B=F6blingen Reg.-Nr. HRB=
=20
5187=20
Hewlett-Packard Str. 2, D 71034 Boeblingen -GERMANY-
--=_alternative 00460EA7C1256C3E_=
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<br><font size=3D2 face=3D"sans-serif">Hi,</font>
<br>
<br><font size=3D2 face=3D"sans-serif">since yesterday, I have up and runni=
ng a B2600 with Debian woody 3.0,</font>
<br><font size=3D2 face=3D"sans-serif">but I can't setup X11 Configur=
ation for the built in PCI Grafic card,</font>
<br><font size=3D2 face=3D"sans-serif">using framebuffer driver.</font>
<br>
<br><font size=3D2 face=3D"sans-serif">The error message in /etc/XFre=
e86.0.log (XFree86 Version 4.1.0.1) </font>
<br><font size=3D2 face=3D"sans-serif">says:</font>
<br><font size=3D2 face=3D"sans-serif">(EE) No devices detected.</font>
<br>
<br><font size=3D2 face=3D"sans-serif">although I have put in /etc/X11/XF86=
Config:</font>
<br>
<br><font size=3D2 face=3D"sans-serif">Section "Device"</font>
<br><font size=3D2 face=3D"sans-serif"> BoardNam=
e "hp-3D"</font>
<br><font size=3D2 face=3D"sans-serif"> Identifi=
er "Device[0]"</font>
<br><font size=3D2 face=3D"sans-serif"> BusID &n=
bsp; "1:3:0" &nbs=
p; </font>
<br><font size=3D2 face=3D"sans-serif"> Driver &=
nbsp; "fbdev"</fo=
nt>
<br><font size=3D2 face=3D"sans-serif"> Option &=
nbsp; "UseFBDev" =
"true"</fo=
nt>
<br><font size=3D2 face=3D"sans-serif"> Screen &=
nbsp; 0</font>
<br><font size=3D2 face=3D"sans-serif">EndSection</font>
<br>
<br><font size=3D2 face=3D"sans-serif">The BusID was determined by &q=
uot;cat /proc/pci" :</font>
<br><font size=3D2 face=3D"sans-serif"> Bus 1, device 3,=
function 0:</font>
<br><font size=3D2 face=3D"sans-serif"> 3D controller: PCI dev=
ice 103c:108b (Hewlett-Packard Company) (rev 5).</font>
<br><font size=3D2 face=3D"sans-serif"> IRQ 258.</font>
<br><font size=3D2 face=3D"sans-serif"> Master Capable.=
Latency=3D255.</font>
<br><font size=3D2 face=3D"sans-serif"> Prefetchable 64=
bit memory at 0xfffffffffb000000 [0xfffffffffbffffff].</font>
<br><font size=3D2 face=3D"sans-serif"> Non-prefetchabl=
e 64 bit memory at 0xfffffffffa000000 [0xfffffffffaffffff].</font>
<br>
<br><font size=3D2 face=3D"sans-serif">If anybody has the same grafic card =
running, I would very much appreciate</font>
<br><font size=3D2 face=3D"sans-serif">to get a working XF86Config or any t=
ips to resolve that problem.</font>
<br>
<br><font size=3D2 face=3D"sans-serif">Regards,</font>
<br><font size=3D2 face=3D"sans-serif"> Joachim<b=
r>
<br>
Joachim Weller<br>
<br>
Philips Medizin Systeme Boeblingen GmbH<br>
Cardiac and Monitoring Systems (CMS) /New Product Engineering <br>
Phone: {+49|0}-7031-463-1891<br>
Fax: {+49|0}-7031-463-2112<br>
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F<br>
Gesch=E4ftsf=FChrer: Dr. Werner Haas, David Russell, Wolfgang Strenzl (Spre=
cher)<br>
Sitz der Gesellschaft: B=F6blingen Registergericht B=F6blingen Reg.-Nr. HRB=
5187 <br>
Hewlett-Packard Str. 2, D 71034 Boeblingen -GERMANY-</f=
ont>
--=_alternative 00460EA7C1256C3E_=--
From jsoe0708@tiscali.be Tue Sep 24 13:54:53 2002
From: jsoe0708@tiscali.be (jsoe0708@tiscali.be)
Date: Tue, 24 Sep 2002 14:54:53 +0200
Subject: [parisc-linux] Help wanted: XF86Config (B2600)
In-Reply-To: <OF52713812.E62609E7-ONC1256C3E.0044B75D@diamond.philips.com>
Message-ID: <3D8F0114000004FF@ocpmta2.be.tiscali.com>
Hey Joachim,
Have first a look with dmesg.
For my b2k a get unfortunately:
...
STI device: HPA4982A
stifb: Unsupported gfx card id 0x35acda16
...
Joel
>-- Original Message --
>From: joachim.weller@philips.com
>To: parisc-linux@lists.parisc-linux.org
>Subject: [parisc-linux] Help wanted: XF86Config (B2600)
>Date: Tue, 24 Sep 2002 14:40:33 +0200
>
>
>Hi,
>
>since yesterday, I have up and running a B2600 with Debian woody 3.0,
>but I can't setup X11 Configuration for the built in PCI Grafic card,
>using framebuffer driver.
>
>The error message in /etc/XFree86.0.log (XFree86 Version 4.1.0.1)
>says:
>(EE) No devices detected.
>
>although I have put in /etc/X11/XF86Config:
>
>Section "Device"
> BoardName "hp-3D"
> Identifier "Device[0]"
> BusID "1:3:0"
> Driver "fbdev"
> Option "UseFBDev" "true"
> Screen 0
>EndSection
>
>The BusID was determined by "cat /proc/pci" :
> Bus 1, device 3, function 0:
> 3D controller: PCI device 103c:108b (Hewlett-Packard Company) (rev 5).
> IRQ 258.
> Master Capable. Latency=255.
> Prefetchable 64 bit memory at 0xfffffffffb000000
>[0xfffffffffbffffff].
> Non-prefetchable 64 bit memory at 0xfffffffffa000000
>[0xfffffffffaffffff].
>
>If anybody has the same grafic card running, I would very much appreciate
>to get a working XF86Config or any tips to resolve that problem.
>
>Regards,
> Joachim
>
>Joachim Weller
>
>Philips Medizin Systeme Boeblingen GmbH
>Cardiac and Monitoring Systems (CMS) /New Product Engineering
>Phone: {+49|0}-7031-463-1891
>Fax: {+49|0}-7031-463-2112
>________________________________________________________________________________
>Gesch?ftsf?hrer: Dr. Werner Haas, David Russell, Wolfgang Strenzl
>(Sprecher)
>Sitz der Gesellschaft: B?blingen Registergericht B?blingen Reg.-Nr. HRB
>5187
>Hewlett-Packard Str. 2, D 71034 Boeblingen -GERMANY-
From varenet@esiee.fr Tue Sep 24 13:54:04 2002
From: varenet@esiee.fr (Thibaut VARENE)
Date: Tue, 24 Sep 2002 14:54:04 +0200
Subject: [parisc-linux] Help wanted: XF86Config (B2600)
References: <OF52713812.E62609E7-ONC1256C3E.0044B75D@diamond.philips.com>
Message-ID: <3D90606C.6000500@esiee.fr>
joachim.weller@philips.com wrote:
> The BusID was determined by "cat /proc/pci" :
> Bus 1, device 3, function 0:
> 3D controller: PCI device 103c:108b (Hewlett-Packard Company) (rev 5).
> IRQ 258.
> Master Capable. Latency=255.
> Prefetchable 64 bit memory at 0xfffffffffb000000
> [0xfffffffffbffffff].
> Non-prefetchable 64 bit memory at 0xfffffffffa000000
> [0xfffffffffaffffff].
it's a FXE card, unsupported.
Only Vis-EG are.
Support for these cards is planned to be worked on ;)
HTH,
Thibaut VARENE
PA/Linux ESIEE Team
http://pateam.esiee.fr/
From joachim.weller@philips.com Tue Sep 24 14:36:54 2002
From: joachim.weller@philips.com (joachim.weller@philips.com)
Date: Tue, 24 Sep 2002 15:36:54 +0200
Subject: [parisc-linux] Help wanted: XF86Config (B2600)
Message-ID: <OF16A59BB3.066D8ECC-ONC1256C3E.004A35AA@diamond.philips.com>
This is a multipart message in MIME format.
--=_alternative 004B16BAC1256C3E_=
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Merci beacoup Thibault,
> it's a FXE card, unsupported.
> Only Vis-EG are.
> Support for these cards is planned to be worked on ;)
Would it be possible to plug in a standard PC PCI Grafics card, like lets=20
say
a vanilla matrox mgag550 and use that driver ?
Joachim Weller
Philips Medizin Systeme Boeblingen GmbH
Cardiac and Monitoring Systems (CMS) /New Product Engineering=20
Phone: {+49|0}-7031-463-1891
Fax: {+49|0}-7031-463-2112
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F
Gesch=E4ftsf=FChrer: Dr. Werner Haas, David Russell, Wolfgang Strenzl=20
(Sprecher)
Sitz der Gesellschaft: B=F6blingen Registergericht B=F6blingen Reg.-Nr. HRB=
=20
5187=20
Hewlett-Packard Str. 2, D 71034 Boeblingen -GERMANY-
--=_alternative 004B16BAC1256C3E_=
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<br><font size=3D2 face=3D"Courier New">Merci beacoup Thibault,</font>
<br>
<br><font size=3D2 face=3D"Courier New">> it's a FXE card, unsupported.<=
br>
> Only Vis-EG are.<br>
> Support for these cards is planned to be worked on ;)<br>
</font><font size=3D2 face=3D"sans-serif"><br>
Would it be possible to plug in a standard PC PCI Grafics card, like lets s=
ay</font>
<br><font size=3D2 face=3D"sans-serif">a vanilla matrox mgag550 and u=
se that driver ?</font>
<br><font size=3D2 face=3D"sans-serif"><br>
Joachim Weller<br>
<br>
Philips Medizin Systeme Boeblingen GmbH<br>
Cardiac and Monitoring Systems (CMS) /New Product Engineering <br>
Phone: {+49|0}-7031-463-1891<br>
Fax: {+49|0}-7031-463-2112<br>
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F<br>
Gesch=E4ftsf=FChrer: Dr. Werner Haas, David Russell, Wolfgang Strenzl (Spre=
cher)<br>
Sitz der Gesellschaft: B=F6blingen Registergericht B=F6blingen Reg.-Nr. HRB=
5187 <br>
Hewlett-Packard Str. 2, D 71034 Boeblingen -GERMANY-</f=
ont>
<br>
--=_alternative 004B16BAC1256C3E_=--
From varenet@esiee.fr Tue Sep 24 15:12:40 2002
From: varenet@esiee.fr (Thibaut VARENE)
Date: Tue, 24 Sep 2002 16:12:40 +0200
Subject: [parisc-linux] Help wanted: XF86Config (B2600)
References: <OF16A59BB3.066D8ECC-ONC1256C3E.004A35AA@diamond.philips.com>
Message-ID: <3D9072D8.5090402@esiee.fr>
joachim.weller@philips.com wrote:
>
> Merci beacoup Thibault,
>
> > it's a FXE card, unsupported.
> > Only Vis-EG are.
> > Support for these cards is planned to be worked on ;)
>
> Would it be possible to plug in a standard PC PCI Grafics card, like
> lets say
> a vanilla matrox mgag550 and use that driver ?
>
IIRC, some are supported (weren't we talking about Voodoo2 recently ? :)
You should take a look at the m-l archive:
http://www.parisc-linux.org/mailing-lists/
Thibaut VARENE
PA/Linux ESIEE Team
http://pateam.esiee.fr/
From viiru@debian.org Tue Sep 24 15:47:50 2002
From: viiru@debian.org (Arto Jantunen)
Date: 24 Sep 2002 17:47:50 +0300
Subject: [parisc-linux] SMP problems
In-Reply-To: <20020924132934.F27458@parcelfarce.linux.theplanet.co.uk>
References: <20020924060541.GA27852@dt-link.fi>
<Pine.LNX.4.44.0209240141510.20374-100000@garibaldi.apptechsys.com>
<20020924112830.GA27877@dt-link.fi>
<20020924132934.F27458@parcelfarce.linux.theplanet.co.uk>
Message-ID: <87fzvzphpl.fsf@welho.com>
Matthew Wilcox <willy@debian.org> writes:
> On Tue, Sep 24, 2002 at 02:28:30PM +0300, Arto Jantunen wrote:
> > I have a HP9000/D390. Dual PA-8200. It doesn't boot at all with that
> > kernel or any other 64-bit kernel. Some things do suggest that it should
> > work, but it doesn't. After the kernel branching point it starts
> > scrolling FLT codes on the LCD display, but doesn't report anything on
> > the console. I have a ser pim output taken out after rebooting the box
> > if someone is interrested. I'll try building the latest CVS with 32-bit
> > and SMP and see if it's any better then the ones I have tried so far.
>
> Do you have the CAP/MUX card installed? (the card with the other serial
> port on it) If so, you should enable "Serial MUX support" and make
> sure to use console=ttyB0 on the command line (ie pretend you have a K
> class machine).
Is that the so called remote admin card you told me to remove?-) If it
is, no I don't have it in there because I was told to remove it. Will
putting it back actually fix problems? Will it cause problems? It did
before. Where should I connect my console after putting it back in?
--
Arto Jantunen
From willy@debian.org Tue Sep 24 15:58:55 2002
From: willy@debian.org (Matthew Wilcox)
Date: Tue, 24 Sep 2002 15:58:55 +0100
Subject: [parisc-linux] SMP problems
In-Reply-To: <87fzvzphpl.fsf@welho.com>; from viiru@debian.org on Tue, Sep 24, 2002 at 05:47:50PM +0300
References: <20020924060541.GA27852@dt-link.fi> <Pine.LNX.4.44.0209240141510.20374-100000@garibaldi.apptechsys.com> <20020924112830.GA27877@dt-link.fi> <20020924132934.F27458@parcelfarce.linux.theplanet.co.uk> <87fzvzphpl.fsf@welho.com>
Message-ID: <20020924155855.I27458@parcelfarce.linux.theplanet.co.uk>
On Tue, Sep 24, 2002 at 05:47:50PM +0300, Arto Jantunen wrote:
> Is that the so called remote admin card you told me to remove?-) If it
That's the one...
> is, no I don't have it in there because I was told to remove it. Will
> putting it back actually fix problems? Will it cause problems? It did
> before. Where should I connect my console after putting it back in?
Let's leave it out for the moment -- fewer variables the better. If you
build a serial console kernel and you're not getting any output before
the machine hangs, it's time to break out the PDC console debugger.
Edit arch/parisc/kernel/pdc_cons.c and change #undef EARLY_BOOTUP_DEBUG
to #define EARLY_BOOTUP_DEBUG. Let us know how you get on with that.
--
Revolutions do not require corporate support.
From spacenka@lightlink.com Tue Sep 24 16:10:15 2002
From: spacenka@lightlink.com (Steve Pacenka)
Date: 24 Sep 2002 11:10:15 -0400
Subject: [parisc-linux] RTC and FB on 735/125
In-Reply-To: <002a01c263bf$76340820$1f96078d@acid>
References: <03ab01c26266$2416dea0$1f96078d@acid><20020922220323.0113cbca.varenet@esiee.
fr><03bf01c2627c$9a5147c0$1f96078d@acid>
<03ed01c26280$4dfb5c90$1f96078d@acid> <1032793227.1848.222.camel@romano>
<003001c26327$d0db42e0$1f96078d@acid> <1032806776.2868.19.camel@romano>
<002a01c263bf$76340820$1f96078d@acid>
Message-ID: <1032880215.1338.175.camel@romano>
On Tue, 2002-09-24 at 07:42, Yves Bodack wrote:
> From: "Steve Pacenka" <spacenka@lightlink.com>
> Subject: Re: [parisc-linux] RTC and FB on 735/125
>
>
> > Could you please post your experience at getting X applications to work
> > now that you have X and a desktop? I got basic gnome things to work
> > flawlessly, but failed on my 735/99 with xmms, xemacs, and galeon or
> > mozilla.
> Galeon/Mozilla and XMMS start up, but they don't appear on screen and give
> no errors. xemacs can't be installed, while dselect misses some dependent
> packages.
Thanks for posting the results.
Those are basically the same problems I encountered a couple of months
ago. I also tried to compile Xemacs from source and it suffered a
runtime startup failure. It's puzzling how the Gnome desktop and KDE
work well with all of their complex shared library and data file
loading, but these other packages fail.
> I'm running KDE, that is slow but proper. And I have a woking browser at
> last.
Aha, Konqueror. Thanks for the hint. I can set up my demo 735/99 with
KDE, Konqueror, and KMail.
-- thanks, SP
From spacenka@lightlink.com Tue Sep 24 16:15:21 2002
From: spacenka@lightlink.com (Steve Pacenka)
Date: 24 Sep 2002 11:15:21 -0400
Subject: [parisc-linux] RTC and FB on 735/125
In-Reply-To: <3D9052C9.3060704@esiee.fr>
References: <03ab01c26266$2416dea0$1f96078d@acid><20020922220323.0113cbca.varenet@esiee.
fr><03bf01c2627c$9a5147c0$1f96078d@acid>
<03ed01c26280$4dfb5c90$1f96078d@acid> <1032793227.1848.222.camel@romano>
<003001c26327$d0db42e0$1f96078d@acid> <1032806776.2868.19.camel@romano>
<002a01c263bf$76340820$1f96078d@acid> <3D9052C9.3060704@esiee.fr>
Message-ID: <1032880521.1338.181.camel@romano>
On Tue, 2002-09-24 at 07:55, Thibaut VARENE wrote:
> > From: "Steve Pacenka" <spacenka@lightlink.com>
> > Subject: Re: [parisc-linux] RTC and FB on 735/125
> >
> >>Could you please post your experience at getting X applications to work
> >>now that you have X and a desktop? I got basic gnome things to work
> >>flawlessly, but failed on my 735/99 with xmms, xemacs, and galeon or
> >>mozilla.
> >
> > Galeon/Mozilla and XMMS start up, but they don't appear on screen and give
> Galeon/Mozilla is b0rken on hppa. You can try either Links or Konqueror...
> for XMMS I don't know...
Thanks for feeeback.
I got the command line alsaplayer mp3 player to work on the 735; perhaps
some front ends that use this or mpg123 could replace xmms.
-- SP
From varenet@esiee.fr Tue Sep 24 16:33:05 2002
From: varenet@esiee.fr (Thibaut VARENE)
Date: Tue, 24 Sep 2002 17:33:05 +0200
Subject: [parisc-linux] RTC and FB on 735/125
References: <03ab01c26266$2416dea0$1f96078d@acid><20020922220323.0113cbca.varenet@esiee. fr><03bf01c2627c$9a5147c0$1f96078d@acid> <03ed01c26280$4dfb5c90$1f96078d@acid> <1032793227.1848.222.camel@romano> <003001c26327$d0db42e0$1f96078d@acid> <1032806776.2868.19.camel@romano> <002a01c263bf$76340820$1f96078d@acid> <3D9052C9.3060704@esiee.fr> <1032880521.1338.181.camel@romano>
Message-ID: <3D9085B1.5030503@esiee.fr>
Steve Pacenka wrote:
> On Tue, 2002-09-24 at 07:55, Thibaut VARENE wrote:
>
>
>>>Galeon/Mozilla and XMMS start up, but they don't appear on screen and give
>>
>>Galeon/Mozilla is b0rken on hppa. You can try either Links or Konqueror...
>>for XMMS I don't know...
>
>
>
> Thanks for feeeback.
>
> I got the command line alsaplayer mp3 player to work on the 735; perhaps
> some front ends that use this or mpg123 could replace xmms.
Well I just tried xmms on a B132L+, it worked just fine...
Thibaut VARENE
PA/Linux ESIEE Team
http://pateam.esiee.fr/
From DMcl@amcol.com Tue Sep 24 16:42:34 2002
From: DMcl@amcol.com (Dan McLaughlin)
Date: Tue, 24 Sep 2002 10:42:34 -0500
Subject: [parisc-linux] installing debian 3.0
Message-ID: <466EEDE4653DD41195EA00508BAC968502198F4D@AMCHIEXCH01>
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_000_01C263E1.005CFA40
Content-Type: multipart/alternative;
boundary="----_=_NextPart_001_01C263E1.005CFA40"
------_=_NextPart_001_01C263E1.005CFA40
Content-Type: text/plain
Trying to install debian 3.0 on a c110 w/ 2 scsi hd 2.0 gig and 512megs of
ram. When I run apt-get I get io error
Then tells me to try to reinstall I do that and get the same error?
Dan McLaughlin
Help Desk
------_=_NextPart_001_01C263E1.005CFA40
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable
<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns=3D"http://www.w3.org/TR/REC-html40">
<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DProgId content=3DWord.Document>
<meta name=3DGenerator content=3D"Microsoft Word 10">
<meta name=3DOriginator content=3D"Microsoft Word 10">
<link rel=3DFile-List href=3D"cid:filelist.xml@01C263B7.78DA90B0">
<!--[if gte mso 9]><xml>
<o:OfficeDocumentSettings>
<o:DoNotRelyOnCSS/>
</o:OfficeDocumentSettings>
</xml><![endif]--><!--[if gte mso 9]><xml>
<w:WordDocument>
<w:DocumentKind>DocumentEmail</w:DocumentKind>
<w:EnvelopeVis/>
<w:Compatibility>
<w:BreakWrappedTables/>
<w:SnapToGridInCell/>
<w:WrapTextWithPunct/>
<w:UseAsianBreakRules/>
</w:Compatibility>
<w:BrowserLevel>MicrosoftInternetExplorer4</w:BrowserLevel>
</w:WordDocument>
</xml><![endif]-->
<style>
<!--
/* Font Definitions */
@font-face
{font-family:"Monotype Corsiva";
panose-1:3 1 1 1 1 2 1 1 1 1;
mso-font-charset:0;
mso-generic-font-family:script;
mso-font-pitch:variable;
mso-font-signature:647 0 0 0 159 0;}
@font-face
{font-family:Verdana;
panose-1:2 11 6 4 3 5 4 4 2 4;
mso-font-charset:0;
mso-generic-font-family:swiss;
mso-font-pitch:variable;
mso-font-signature:536871559 0 0 0 415 0;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{mso-style-parent:"";
margin:0in;
margin-bottom:.0001pt;
mso-pagination:widow-orphan;
font-size:10.0pt;
font-family:Verdana;
mso-fareast-font-family:"Times New Roman";
mso-bidi-font-family:"Times New Roman";
color:black;
mso-believe-normal-left:yes;}
a:link, span.MsoHyperlink
{color:blue;
text-decoration:underline;
text-underline:single;}
a:visited, span.MsoHyperlinkFollowed
{color:purple;
text-decoration:underline;
text-underline:single;}
span.EmailStyle17
{mso-style-type:personal-compose;
mso-style-noshow:yes;
mso-ansi-font-size:10.0pt;
mso-bidi-font-size:10.0pt;
font-family:Arial;
mso-ascii-font-family:Arial;
mso-hansi-font-family:Arial;
mso-bidi-font-family:Arial;
color:black;
font-weight:normal;
font-style:normal;
text-decoration:none;
text-underline:none;
text-decoration:none;
text-line-through:none;}
@page Section1
{size:8.5in 11.0in;
margin:1.0in 1.25in 1.0in 1.25in;
mso-header-margin:.5in;
mso-footer-margin:.5in;
mso-paper-source:0;}
div.Section1
{page:Section1;}
-->
</style>
<!--[if gte mso 10]>
<style>
/* Style Definitions */=20
table.MsoNormalTable
{mso-style-name:"Table Normal";
mso-tstyle-rowband-size:0;
mso-tstyle-colband-size:0;
mso-style-noshow:yes;
mso-style-parent:"";
mso-padding-alt:0in 5.4pt 0in 5.4pt;
mso-para-margin:0in;
mso-para-margin-bottom:.0001pt;
mso-pagination:widow-orphan;
font-size:10.0pt;
font-family:"Times New Roman";}
</style>
<![endif]--><![if mso 9]>
<style>
p.MsoNormal
{margin-left:51.0pt;}
</style>
<![endif]><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</head>
<body bgcolor=3Dwhite background=3D"cid:image001.gif@01C263B7.78DA90B0" =
lang=3DEN-US
link=3Dblue vlink=3Dpurple =
style=3D'tab-interval:.5in;margin-left:51.0pt'>
<img src=3D"cid:image001.gif@01C263B7.78DA90B0"
v:src=3D"cid:image001.gif@01C263B7.78DA90B0" v:shapes=3D"_x0000_Mail" =
width=3D0
height=3D0 class=3Dshape style=3D'display:none;width:0;height:0'>
<div class=3DSection1>
<p class=3DMsoNormal><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial'>Trying to install debian 3.0 on a c110 w/ 2 =
scsi hd
2.0 gig and 512megs of ram. When I run apt-get I get io error<o:p></o:p>=
</span></font></p>
<p class=3DMsoNormal><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial'>Then tells me to try to reinstall I do that =
and get
the same error?<o:p></o:p></span></font></p>
<div>
<p class=3DMsoNormal><font size=3D4 color=3Dblack face=3D"Monotype =
Corsiva"><span
style=3D'font-size:13.5pt;font-family:"Monotype =
Corsiva";mso-no-proof:yes'>Dan
McLaughlin</span></font><span =
style=3D'mso-no-proof:yes'><o:p></o:p></span></p>
<p class=3DMsoNormal><font size=3D4 color=3Dblack face=3D"Monotype =
Corsiva"><span
style=3D'font-size:13.5pt;font-family:"Monotype =
Corsiva";mso-no-proof:yes'>Help
Desk</span></font><o:p></o:p></p>
</div>
<p class=3DMsoNormal><font size=3D2 color=3Dblack face=3DVerdana><span
style=3D'font-size:10.0pt'><o:p> </o:p></span></font></p>
</div>
</body>
</html>
------_=_NextPart_001_01C263E1.005CFA40--
------_=_NextPart_000_01C263E1.005CFA40
Content-Type: image/gif;
name="image001.gif"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename="image001.gif"
Content-ID: <image001.gif@01C263B7.78DA90B0>
R0lGODlhoAVyAKL/AMDAwJmZmWZmZjMzMwAAAAAAAAAAAAAAACH5BAEAAAAALAAAAACgBXIAQAP/
CBqi/o/IBuOSJNS9BeVgKI5kaZ5oqq5s675wLM90bd94ru987//AoHBILBqPyKRyWWMwMBgHFBSY
uhoapnbL7Xq/4LB4TC6bz+i0es1ujz8RiWaggAoCAyjhHsoTHHAAWW6EhYaHiImKi4yNjo+QkZKQ
VXoSHH99EgODHAGdk6Gio6SlpqeoqaqrrK0xgRt4myKZFZZyrrm6u7y9vr/AwcLDiIEfEyJ+GJzK
mVhREAzE09TV1tfY2drb3FwasClQoHGXdXp34N3q6+zt7u/w8fJhHiuVGXUhAtAin/P/AAMKHEiw
oEFgAjiZwDAOQK0K90g4OUixosWLGDNq3GgD/066WRD2WYgFEsRDjihTqlzJsqVLYekc4rJ10iHJ
k3ykRHvJs6fPn0CDClUCSpwDPAr21bQJYSYAhUnLQRxKtarVq1izvgQVU5DTpg/2jfNTIVBDrWjT
ql3Ltu2ubyT80MHkiZ8ILG7z6t3Lt6/fMv5G+On6EENXKmf/Kl7MuLHjx3VHRAyhxwU+yJgza97M
eeigmOfgVHaRJXDn06hTq14NL3GtWyXzlbACMTHr27hz694dCk/CAb9/wx4AnHjC4wSKFz/eDIrx
58Vt855Ovbr161pc26UFoTntpYKwix9Pvrx5GoOkkxidVOn2sAvOy59Pv375KpZpY/pK177///8A
BpiZNCjox9R+l/Uj4IIMNuhgVlkcJlNNg4A3oXoWPqjhhhx2aFBDx0gVB1gbvAfIVB6mqOKKLHLD
R2nOhRdfJZwEVkVpDPhhmgb3IBOhei0GKeSQRJYyyFzRiDjSUUoqMJgnQBYp5ZRUVnmGhCbKJgiS
UjQJnyBRWinmmGSW2UOG5FBWgTIFhmnmm3DGKecIEk7I3T1uhpTnnHz26WeVOYHAJmVZmjDRn4gm
qiiVWWQiS3IT0NaJMnXeldSimGaq6YpckvNjcwfOJtUHpm1q6qmomtcQl3h2KWIGzTVUyRyxpGrr
rbiW554lsKDpagil5irssMQyJh1seIxDoUL/PTJERbHQRistWzE1K8cnUC25QLKwKTjtt+CG69Ox
XpZYFmwJ1iruuuy2ixE4dMx60zL4XcDPZA50KqO7/Pbrb2tf2nnCH3pw8mKWSO7578IMN8wKBZXq
s8wDFRq2ySaN7uvwxhx3vEpCCpOD5sTARuzxySin3EagKbSaIb7AhqzyzDTXTJTC7ml7bnIS2ezz
z0B742tTyJCI4GxBJ6300j/AtV65oXYX27MyM2311VhvG59JTWZrYaEnbp312GSXvRPFNOlbhWh1
pRtNJ1WbLffcG8ekFDj8gcefk0fR7fffS59V9JZM1rRU0dn2eDbgjDfe8Sef6cFjeJ9gbONl/5Dr
mJ6TRh1lsuOgh06sshQX5baWXXaQZbCit+46tCByrTfRJUqldtyv5667n2jq2F8dsJC1QcK47278
8Yyi3vbXfRPtK8TIRy/9nyzL7tq8hlY//fbcV8k69iY5P/Tb3ZdvvpRAOhs+ADnbU/z58MdP3tDq
00XyCqfLr//+//kKc+2Dw9/n+EfAAuqmcnvwiumg9pT6rQAdBoygBMnTqO8UqnOked8EN8hBv4Ai
cvcChIEeKLYOmvCEmymN7NCBC2XkAQXB2hwKZ0jDxnQCb8gIEUP+oL2bUKBUA6yhEIcoFFDoq367
cpUDaZIJfQWRiFCMIlAK4xw7LKk0+mLfJf+yyD4pevGLRRSUV7pltH5MbXFgTKMaVUIuS2TRf745
jAbXSMc6bsM2sPkIFbzTw0vZ8Y+AHIiNtrYrwwjCPQbbwxMmwCPv4EOFYHpiICdJyWBAroTW4tkh
DfMED7iHD4UMoIy+V8lSmpIaiXmUc66nulsA65SwjCUxSJmUZGFoeGR8pSx3yctc0NJ362GiJWjV
y2Ia8y2rkkkWc1KhsFQRg+M7pjSnyYixmONlllAiqd6jNmp685uIKFWE9haLBmSAPc/wkjjByc52
qmGQpSvQJ8fIQqjN0Z34zCcP/CFJkZFKm80LqD4HStAl0PIEikPQa6wAyYI69KFA+EQ/x6j/SYUm
6RvXgqhGN5qDerEgiYTKX1PuydGSatSjKlAGSgEYTJO69KUqOCgtQIJNBoYNpjjNqTDRxdOe+vSn
2dSpUHPax5kmUCfWkwhJh8rUYq5UMkvMENgisNSmWjWWTwWWiaRqU6Re9asnJRBUy2Wh/3GgqGBN
azvxMlbQJFVBVVWrXOsIPa0edUlf6+oo58rXdsrwJspq5tFiVsK+GlaaO4JFJWqns8LZhmVxPaxk
axgsVu3thY2NSoa4ONnO7vJ7dFDKOPYRCL3dtYxo86xqT5kY0TIWtakrCyA+uNraVvJ7i30K3Jq0
lNwSzpm2DS5rR9ukZOWhV7UjzgL5E1nh3zr3fMEhTnOU8xtH+lQ5yikYdif63O4S8IPsWUBCvFST
fTBDWafVmnfXq8b0ei1/hksXUmRyFu6y977mgxup0Pu72NKkWvgN8AwbAh6l9LeBikUGF5sr4Abn
jrMy0WME1PYVJzr4whJMT1fkZS7/xmEcQMSwiL/rx5CuzysQIafYGDziFo9tciO4oFdFKNKwsdjF
OL6aesw645CouDY5DvL2xBpSVjIxShAUspKNl1WWnthTA7vxkqecsvGB7SStGph9qczloAGJxzNu
Hwy33OUyVxmoaE6zmvVq5jb7LAEAOw==
------_=_NextPart_000_01C263E1.005CFA40--
From james@compusmithllc.com Tue Sep 24 16:52:29 2002
From: james@compusmithllc.com (James Smith)
Date: 24 Sep 2002 10:52:29 -0500
Subject: [parisc-linux] RTC and FB on 735/125
In-Reply-To: <3D9085B1.5030503@esiee.fr>
References: <03ab01c26266$2416dea0$1f96078d@acid>
<20020922220323.0113cbca.varenet@esiee.fr>
<03bf01c2627c$9a5147c0$1f96078d@acid> <03ed01c26280$4dfb5c90$1f96078d@acid>
<1032793227.1848.222.camel@romano> <003001c26327$d0db42e0$1f96078d@acid>
<1032806776.2868.19.camel@romano> <002a01c263bf$76340820$1f96078d@acid>
<3D9052C9.3060704@esiee.fr> <1032880521.1338.181.camel@romano>
<3D9085B1.5030503@esiee.fr>
Message-ID: <1032882750.384.10.camel@seventy>
On Tue, 2002-09-24 at 10:33, Thibaut VARENE wrote:
> Steve Pacenka wrote:
> > On Tue, 2002-09-24 at 07:55, Thibaut VARENE wrote:
> >
> >
> >>>Galeon/Mozilla and XMMS start up, but they don't appear on screen and give
> >>
> >>Galeon/Mozilla is b0rken on hppa. You can try either Links or Konqueror...
> >>for XMMS I don't know...
> >
i've had both konqueror & xmms working fine on my 712/60
there's also a browser called dillo available as a package - muchj
faster on the slower machines, but also supports far less features
i also found one written in TCL called browsex available at browsex.com
not tried it yet, but being as its written in tcl, it *should* work :)
James S
From grundler@dsl2.external.hp.com Tue Sep 24 17:58:43 2002
From: grundler@dsl2.external.hp.com (Grant Grundler)
Date: Tue, 24 Sep 2002 10:58:43 -0600
Subject: [parisc-linux] WTS: workstation ram
In-Reply-To: Message from Gavin Hubbard <ghub005@xtra.co.nz>
of "Tue, 24 Sep 2002 21:18:27 +1200." <3.0.2.32.20020924211827.0069032c@pop3.xtra.co.nz>
References: <3.0.2.32.20020924211827.0069032c@pop3.xtra.co.nz>
Message-ID: <20020924165843.9D1114829@dsl2.external.hp.com>
Gavin Hubbard wrote:
> I have twenty used A4994A modules. These are the 256MB, 120MHz SDRAM
> modules that work in the B1000, B2000, B2600, C3000, C3600, C3650, C3700,
> J5600, J6000, J6700, J7000 workstations. Please note that some of those
> systems require the modules to be added in pairs.
Will also work on A400 and A500 (ie rp24xx) boxes.
Possibly on L1000 and L2000 but don't know how picky PDC
is on those boxes.
grant
From markov@monmouth.com Wed Sep 25 02:54:29 2002
From: markov@monmouth.com (Vlad D. Markov)
Date: Tue, 24 Sep 2002 21:54:29 -0400
Subject: [parisc-linux] RTC and FB on 735/125
In-Reply-To: <3D9052C9.3060704@esiee.fr>
References: <03ab01c26266$2416dea0$1f96078d@acid> <002a01c263bf$76340820$1f96078d@acid> <3D9052C9.3060704@esiee.fr>
Message-ID: <200209250154.g8P1sa5O065616@smtp.monmouth.com>
On Tuesday 24 September 2002 07:55 am, Thibaut VARENE wrote:
> Yves Bodack wrote:
> > From: "Steve Pacenka" <spacenka@lightlink.com>
> > Subject: Re: [parisc-linux] RTC and FB on 735/125
> >
> >>Could you please post your experience at getting X applications to work
> >>now that you have X and a desktop? I got basic gnome things to work
> >>flawlessly, but failed on my 735/99 with xmms, xemacs, and galeon or
> >>mozilla.
> >
> > Galeon/Mozilla and XMMS start up, but they don't appear on screen and
> > give
>
> Galeon/Mozilla is b0rken on hppa. You can try either Links or Konqueror...
> for XMMS I don't know...
>
I have used gqmpeg as an xmms replacement with mpg123.
I am on a 735/99 also. I use fvwm2, konqueror, kmail, and motif stuff. I
compiled openmotif on this box.
Some X apps and other apps that don't work:
ghostscript - works on a 712/100 though
xdvi
xfontsel
xman
From grundler@dsl2.external.hp.com Wed Sep 25 04:43:29 2002
From: grundler@dsl2.external.hp.com (Grant Grundler)
Date: Tue, 24 Sep 2002 21:43:29 -0600
Subject: [parisc-linux] Re: B1000
In-Reply-To: Message from Yasholomew Yashinski <yashy@mail.yashy.com>
of "Tue, 24 Sep 2002 20:32:34 EDT." <20020924202029.B46819-100000@mail.yashy.com>
References: <20020924202029.B46819-100000@mail.yashy.com>
Message-ID: <20020925034329.D56EA4829@dsl2.external.hp.com>
Yasholomew Yashinski wrote:
> Heya Gents,
>
> I hope all is well. I see that Debian 3 is available now for hppa, so I
> recently burnt it to try on my B1000. I went to install it tonight,
> however it's rebooting with:
>
> High Priority Machine Check (HPMC): Code=1 regs=102f3080 (Addr=000000000)
>
> and on the LCD: FLT CBFB4
FLT CBFB4 is HPMC. Odd that it dies with an HPMC.
Can you send "ser pim" output to parisc-linux mailing list?
(hint: setup serial console to capture that)
And can you try one of the more recent net install ISO's from ESIEE?
See www.parisc-linux.org front page for links to ESIEE downloads.
> as soon as it hits Init/BusyBox. Am I to assume the A4977a Vis EG-PCI is
> still unsupported? If so, any idea when it will be supported? If it is now
> supported, any idea what needs to change on my end?
Vis-EG PCI is supported and working as a Frame buffer.
That's known to work on B180/C200/B2600/C3000 and probably a few others.
grant
From grundler@dsl2.external.hp.com Wed Sep 25 05:05:00 2002
From: grundler@dsl2.external.hp.com (Grant Grundler)
Date: Tue, 24 Sep 2002 22:05:00 -0600
Subject: [parisc-linux] installing debian 3.0
In-Reply-To: Message from Dan McLaughlin <DMcl@amcol.com>
of "Tue, 24 Sep 2002 10:42:34 CDT." <466EEDE4653DD41195EA00508BAC968502198F4D@AMCHIEXCH01>
References: <466EEDE4653DD41195EA00508BAC968502198F4D@AMCHIEXCH01>
Message-ID: <20020925040500.DA0D94829@dsl2.external.hp.com>
Dan McLaughlin wrote:
> Trying to install debian 3.0 on a c110 w/ 2 scsi hd 2.0 gig and 512megs of
> ram. When I run apt-get I get io error
Can you capture console output?
Is apt-get trying to read from CD that's not inserted?
Is the 2GB HD known to be good?
grant
From yashy@mail.yashy.com Wed Sep 25 05:46:54 2002
From: yashy@mail.yashy.com (Yasholomew Yashinski)
Date: Wed, 25 Sep 2002 00:46:54 -0400 (EDT)
Subject: [parisc-linux] Re: B1000
In-Reply-To: <20020925034329.D56EA4829@dsl2.external.hp.com>
Message-ID: <20020925000736.V54476-100000@mail.yashy.com>
On Tue, 24 Sep 2002, Grant Grundler wrote:
> > I hope all is well. I see that Debian 3 is available now for hppa, so I
> > recently burnt it to try on my B1000. I went to install it tonight,
> > however it's rebooting with:
> >
> > High Priority Machine Check (HPMC): Code=1 regs=102f3080 (Addr=000000000)
> >
> > and on the LCD: FLT CBFB4
>
> FLT CBFB4 is HPMC. Odd that it dies with an HPMC.
If I boot off the disk (0.9.3 with dist-upgrade, and kernel upgrade), it
seems to work okay, I get to:
Starting periodic command scheduler: cron.
and then the cursor just flashes. (Tux is in the top left)
At this point the LCD states "Linux 2.4.1932" which is correct.
I use serial console no problem at this stage.
When I try to boot off the CD I just burnt, it dies with the error
message I placed above. The image I burnt was
debian-30r0-hppa-binary-1.iso from the 2nd ftp site, I just took a guess
which is the proper one to use, as you'll read in my comments below.
> Can you send "ser pim" output to parisc-linux mailing list?
> (hint: setup serial console to capture that)
This is long. I have added addtional comments below.
Main Menu: Enter command > ser pim
PROCESSOR PIM INFORMATION
----------------- Processor 0 HPMC Information ------------------
Timestamp =
Tue Sep 24 19:22:19 GMT 2002 (20:02:09:24:19:22:19)
HPMC Chassis Codes = 2cbf0 2500b 2cbfb
General Registers 0 - 31
00-03 0000000000000000 0000000000029a90 0000000000000008
00000000401d3000
04-07 0000000000000000 0000000000000000 0000000000000007
0000000000000001
08-11 0000000000000010 0000000000000001 00000000faf005d0
0000000000000010
12-15 0000000000029a90 0000000000000000 0000000000029a90
0000000000000000
16-19 000000000002b010 0000000000029a90 0000000000029a90
00000000401d3000
20-23 0000000000000000 0000000000000000 000000000000001c
0000000000000000
24-27 0000000000000000 0000000000000000 0000000000000000
0000000000029a90
28-31 0000000000000008 0000000000000000 00000000faf00700
0000000000000000
<Press any key to continue (q to quit)>
Control Registers 0 - 31
00-03 0000000000000000 0000000000000000 0000000000000000
0000000000000000
04-07 0000000000000000 0000000000000000 0000000000000000
0000000000000000
08-11 0000000000000222 0000000000000000 00000000000000c0
000000000000001e
12-15 0000000000000000 0000000000000000 0000000000105000
00000000ffffffff
16-19 0000000b8cba9370 0000000000000111 000000000001555f
000000000e661200
20-23 00000000100403ec 40000000001d3000 00000000000cff0f
0000000000000000
24-27 000000000030b000 000000000f29c000 00000000ffffffff
00000000ffffffff
28-31 00000000ffffffff 00000000ffffffff 000000001f308000
00000000103a0000
Space Registers 0 - 7
00-03 00000111 00000111 00000000 00000111
04-07 00000111 00000111 00000111 00000111
<Press any key to continue (q to quit)>
IIA Space = 0x0000000000000111
IIA Offset = 0x00000000000151b3
Check Type = 0x20000000
CPU State = 0x9e000004
Cache Check = 0x00000000
TLB Check = 0x00000000
Bus Check = 0x003010bb
Assists Check = 0x00000000
Assist State = 0x00000000
Path Info = 0x00031800
System Responder Address = 0xfffffffffed10200
System Requestor Address = 0xfffffffffffa0000
Floating-Point Registers 0 - 31
00-03 0000001f00000000 0000000000000000 0000000000000000
0000000000000000
04-07 1030381000000001 0000000110149d78 000000020028a286
0000000000000000
08-11 1030a02000000002 ffffffff0000000a 0000000000000000
103aed9f00000000
12-15 0000000000000000 0000000010139d8c 0000000010303810
1030081010300810
16-19 1f4a50001039c000 0000000000000002 0000000010300810
1039b8101f4a5000
20-23 1039c00000000000 0000000200000000 0000000000000000
0000000000000000
24-27 0000080000000000 0000001e00000000 103b4d64102b9364
1f4a5005102b9474
28-31 3031323334353637 3839616210139f94 6768696a6b6c6d6e
6f70717273747576
<Press any key to continue (q to quit)>
'9000/785 B,C,J Workstation Unarchitected (per-CPU)', rev 1, 140 bytes:
Check Summary = 0xcb81041000000000
Available Memory = 0x0000000010000000
CPU Diagnose Register 2 = 0x0203000000000004
CPU Status Register 0 = 0x2420c20000000000
CPU Status Register 1 = 0x8080000000000000
SADD LOG = 0x010008a100000001
Read Short LOG = 0xc1a0f0f0f0400804
ERROR_STATUS = 0x0000000000000010
MEM_ADDR = 0x000001ff3fffffff
MEM_SYND = 0x0000000000000000
MEM_ADDR_CORR = 0x000001ff3fffffff
MEM_SYND_CORR = 0x0000000000000000
RUN_DATA_HIGH = 0xc1bff0fffed08040
RUN_DATA_LOW = 0xc1bff0fffed08040
RUN_CTRL = 0x0000021c00001418
RUN_ADDR = 0xc1bff0fffed08040
System Responder Path = 0x00ffffffffffffff
HPMC PIM Analysis Information:
Timestamp =
Tue Sep 24 19:22:19 GMT 2002 (20:02:09:24:19:22:19)
'9000/785 B,C,J Workstation HPMC PIM Analysis (per-CPU)', rev 0, 1304
bytes:
A Data Miss Timeout occurred while CPU 0 was
requesting information.
Memory/IO Controller Error Analysis Information:
The Memory/IO Controller only observed the Broadcast Error. It did not
log
any additional information about the HPMC.
<Press any key to continue (q to quit)>
----------------- Processor 0 LPMC Information ------------------
Check Type = 0x00000000
I/D Cache Parity Info = 0x00000000
Cache Check = 0x00000000
TLB Check = 0x00000000
Bus Check = 0x00000000
Assists Check = 0x00000000
Assist State = 0x00000000
Path Info = 0x00000000
System Responder Address = 0x0000000000000000
System Requestor Address = 0x0000000000000000
----------------- Processor 0 TOC Information -------------------
General Registers 0 - 31
00-03 0000000000000000 0000000000000000 0000000000000000
0000000000000000
04-07 0000000000000000 0000000000000000 0000000000000000
0000000000000000
08-11 0000000000000000 0000000000000000 0000000000000000
0000000000000000
12-15 0000000000000000 0000000000000000 0000000000000000
0000000000000000
16-19 0000000000000000 0000000000000000 0000000000000000
0000000000000000
20-23 0000000000000000 0000000000000000 0000000000000000
0000000000000000
24-27 0000000000000000 0000000000000000 0000000000000000
0000000000000000
28-31 0000000000000000 0000000000000000 0000000000000000
0000000000000000
<Press any key to continue (q to quit)>
Control Registers 0 - 31
00-03 0000000000000000 0000000000000000 0000000000000000
0000000000000000
04-07 0000000000000000 0000000000000000 0000000000000000
0000000000000000
08-11 0000000000000000 0000000000000000 0000000000000000
0000000000000000
12-15 0000000000000000 0000000000000000 0000000000000000
0000000000000000
16-19 0000000000000000 0000000000000000 0000000000000000
0000000000000000
20-23 0000000000000000 0000000000000000 0000000000000000
0000000000000000
24-27 0000000000000000 0000000000000000 0000000000000000
0000000000000000
28-31 0000000000000000 0000000000000000 0000000000000000
0000000000000000
Space Registers 0 - 7
00-03 00000000 00000000 00000000 00000000
04-07 00000000 00000000 00000000 00000000
IIA Space = 0x0000000000000000
IIA Offset = 0x0000000000000000
CPU State = 0x00000000
<Press any key to continue (q to quit)>
Memory Error Log Information:
Timestamp =
Tue Sep 24 19:22:19 GMT 2002 (20:02:09:24:19:22:19)
'9000/785 B,C,J Workstation Memory Error Log', rev 0, 64 bytes:
No memory errors logged
I/O Module Error Log Information:
Timestamp =
Tue Sep 24 19:22:19 GMT 2002 (20:02:09:24:19:22:19)
'9000/785 B,C,J Workstation IO Error Log', rev 0, 228 bytes:
Rope Word1 Word2 Word3
------ ------------ ------------
0 0x00000000 0x0e0cc009 0x00000000fed30048
1 0x00000000 0x1e0cc009 0x00000000fed32048
2 ---------- 0x2e0cc009 ------------------
3 ---------- 0x3e0cc009 ------------------
4 0x00000000 0x4e0cc009 0x00000000fed38048
5 ---------- 0x5e0cc009 ------------------
6 0x00000000 0x6e0cc009 0x00000000fed3c048
7 ---------- 0x7e0cc009 ------------------
Main Menu: Enter command >
> And can you try one of the more recent net install ISO's from ESIEE?
> See www.parisc-linux.org front page for links to ESIEE downloads.
Sure, I'll let you know.
Just a few comments on the two websites.
http://pateam.esiee.fr/ could use an English editor:
"This website is run by a" # ran is past tense.
"Please forgive us if either.. or the server has some troubles" # the
users shouldn't have to apologize to the authors.
"see the announcement"
"If you have any questions, suggestions or comments, feel free to contact
us at any time"
"on the project, the team, and.."
"Latest News"
http://www.parisc-linux.org
There are three mirrors containing 600+ MB ISOs. The first link is
broken.
What is the difference between debian-30r0-hppa-binary-1.iso and
debian-30r0-hppa-binary-1_NONUS.iso on the second ftp site? What are the
other files? (A README in that directory with a brief description of each
would be great).
When the third ftp site works (only a few times in the past 48 hours,
when I've tried), it contains different files than the others. A README
file would be great here as well.
> > as soon as it hits Init/BusyBox. Am I to assume the A4977a Vis EG-PCI is
> > still unsupported? If so, any idea when it will be supported? If it is now
> > supported, any idea what needs to change on my end?
>
> Vis-EG PCI is supported and working as a Frame buffer.
> That's known to work on B180/C200/B2600/C3000 and probably a few others.
Where is this documented? All I could find was the 0.9.3 release
information saying it isn't working yet.
Thanks for all your efforts in this project. I can't wait to use my
framebuffer on this machine finally. HP/UX is unfortunately too expensive
for a home user, at least from what documentation I could find.
Signet,
--
Yashy
From varenet@esiee.fr Wed Sep 25 10:09:33 2002
From: varenet@esiee.fr (Thibaut VARENE)
Date: Wed, 25 Sep 2002 11:09:33 +0200
Subject: [parisc-linux] Re: B1000
In-Reply-To: <20020925000736.V54476-100000@mail.yashy.com>
Message-ID: <81AAACAB-D066-11D6-9CB4-0030656F07A2@esiee.fr>
Le mercredi, 25 sep 2002, =E0 06:46 Europe/Paris, Yasholomew Yashinski a=20=
=E9crit :
> Just a few comments on the two websites.
>
> http://pateam.esiee.fr/ could use an English editor:
> "This website is run by a" # ran is past tense.
> "Please forgive us if either.. or the server has some troubles" # the
> users shouldn't have to apologize to the authors.
> "see the announcement"
> "If you have any questions, suggestions or comments, feel free to=20
> contact
> us at any time"
> "on the project, the team, and.."
> "Latest News"
Welle, thanq yoo fore yoore elp. I wil trye tou corecte som errorz !
Dide yoo noticed da '.fr' at thee ende off da naime ? ;^)
Wee are damne franch pipol, we dont now Inglish ! ;o]
T.V. - The guy who now handle the pateam website maintaining =3D)
/me ducks !
Thibaut VARENE
The PA/Linux ESIEE Team
http://pateam.esiee.fr/
for any b4d english comment, mail us at=20
mailto:puffin@esiee.fr?subject=3Db4d_3ngl1sh=
From jsoe0708@tiscali.be Wed Sep 25 11:05:19 2002
From: jsoe0708@tiscali.be (jsoe0708@tiscali.be)
Date: Wed, 25 Sep 2002 12:05:19 +0200
Subject: [parisc-linux] Mouse stops working when exiting KDE
In-Reply-To: <3D8E3A0B.5090008@earthlink.net>
Message-ID: <3D8F01140000099E@ocpmta2.be.tiscali.com>
Hi Brian,
>-- Original Message --
>Date: Sun, 22 Sep 2002 16:45:47 -0500
>From: "Bryan W. Headley" <bwheadley@earthlink.net>
>To: Joel Soete <joel.soete@freebel.net>
>CC: Derek Engelhaupt <derekengelhaupt@rocketmail.com>,
> parisc-linux@lists.parisc-linux.org
>Subject: Re: [parisc-linux] Mouse stops working when exiting KDE
>
>
>Joel Soete wrote:
>
>>> I assume you are running the gpm mouse daemon as well. If you tell X
>>> to use the gpm mouse (/dev/gpmdata), you should be okay.
>>
>>
>> Hmm, long time ago I test this (because that was like this I configure
>
>> my i386 boxe) but it did not work. Does it work now on parisc?
>
>Last time I checked, it did.
Sorry, the last test I do on my b180 and gpmdata as mouse driver does not
work :)
(xfree86-4.1)
Hmm I just notice this funny behaviour:
I start gdm, I login -> the cursor work normaly :)
I quit my X session -> the cursor doesn't work any more ...
I would like to see at the console if I can see some error messages, so I
swich to sti mode (CTRL+ALT f1)... ok that works. No error messages, so I
can come back to gdm login screen (CTRL+ALT f7), oh the cursor move again
normaly ?
Any idea?
Thanks in advance,
Joel
PS: kernel 2.4.18-pa61 + apt-get dist_upgrade this 2002-09-24
From paulhill20@juno.com Wed Sep 25 14:09:14 2002
From: paulhill20@juno.com (Stephen J de Vries)
Date: Wed, 25 Sep 2002 09:09:14 -0400
Subject: [parisc-linux] hardware newbie question...
Message-ID: <20020925.090915.-178139.3.paulhill20@juno.com>
I have a HP 712 that I'd purchased recently.
My question is:
Can I use a PC monitor, keyboard, and mouse to boot the thing up? If so,
does the monitor have to be a multisync or something special?
In addition, HP-UX is on the hard drive but is locked down. I was
thinking of buying an external CD drive and attempting to load debian
0.93. Can anyone recommend a place to buy the CD drive that they have
dealt with? I also have a network so I could attempt a network install
but I am not sure what minimum requirements I'd need to fulfill for that.
Is my approach the right one?
Thanks for the advice...
Stephen de Vries
From jsoe0708@tiscali.be Wed Sep 25 14:25:13 2002
From: jsoe0708@tiscali.be (jsoe0708@tiscali.be)
Date: Wed, 25 Sep 2002 15:25:13 +0200
Subject: [parisc-linux] followup: Inline Assembly Help request
In-Reply-To: <200209091727.g89HRZF3021659@hiauly1.hia.nrc.ca>
Message-ID: <3D8F011400000B05@ocpmta2.be.tiscali.com>
Hi all,
Following my investigation to fix the problem of 64bits integer transfer
between kernel and user space (put_user in uaccess.h), I still had a problem:
how to access of the two int (32bit) parts of a long long?
In mips sources I found this interresting stuff:
__put_user_asm_ll32
...
1: sw %1, %2
2: sw %D1, %3
....
which would correspond to what I need but it is not available for hppa.
So I do something like:
...
#define STD_USER(x, ptr) \
({ \
unsigned int xh = (unsigned int)(x>>32), \
xl = (unsigned int) (x); \
__put_user_asm_64(xh, xl, ptr); \
})
...
and so
...
#define __put_user_asm_64(xh, xl, ptr) \
__asm__ __volatile__ ( \
"\n1:\tstw\t%2,0(%%sr3,%1)\n" \
"2:\tstw\t%3,4(%%sr3,%1)\n" \
"3:\n" \
"\t.section __ex_table,\"a\"\n" \
"\t.word\t1b\n" \
"\t.word\t(3b-1b)+1\n" \
"\t.word\t2b\n" \
"\t.word\t(3b-2b)+1\n" \
"\t.previous" \
: "=r"(__pu_err) \
: "r"(ptr), "r"(xh), "r"(xl), "0"(__pu_err))
...
which has a border effect:
tty_ioctl.c: In function `get_termio':
tty_ioctl.c:175: warning: right shift count >= width of type
tty_ioctl.c:175: warning: right shift count >= width of type
tty_ioctl.c:175: warning: right shift count >= width of type
tty_ioctl.c:175: warning: right shift count >= width of type
tty_ioctl.c:175: warning: right shift count >= width of type
Is there some other means somewhere else?
Thanks in advance,
Joel
From varenet@esiee.fr Wed Sep 25 14:34:07 2002
From: varenet@esiee.fr (Thibaut VARENE)
Date: Wed, 25 Sep 2002 15:34:07 +0200
Subject: [parisc-linux] hardware newbie question...
References: <20020925.090915.-178139.3.paulhill20@juno.com>
Message-ID: <3D91BB4F.5090205@esiee.fr>
Stephen J de Vries wrote:
> I have a HP 712 that I'd purchased recently.
>
> My question is:
>
> Can I use a PC monitor, keyboard, and mouse to boot the thing up? If so,
> does the monitor have to be a multisync or something special?
OK for the PC monitor. Use 'Tab' at boot time to switch 712's resolution
NO for the PC keyboard (pc kbd is 75mA iirc, 712 is 500mA)
I don't know for the mouse.
>
> In addition, HP-UX is on the hard drive but is locked down. I was
> thinking of buying an external CD drive and attempting to load debian
> 0.93. Can anyone recommend a place to buy the CD drive that they have
> dealt with? I also have a network so I could attempt a network install
> but I am not sure what minimum requirements I'd need to fulfill for that.
You can unlock HP/UX pretty easily if the box isn't in secure mode.
Just stop the boot sequence and at the BOOT_ADMIN prompt type 'bo pri ipl'
Then answer 'y' to the 'interract with...' question, and then type (i
don't know if we can say this here ;o)
hpux -iS
If the box is in secure mode there is a workaround:
Open it, unplug the HD, boot it, wait for timeout, and then deactivate
the secure mode ;)
then reboot again.
You can definitly use network to install.
Check the palinux boot howto.
I recommend you use the latest version (still under review, that's why
it's not yet available on tldp):
http://testpa.esiee.fr/.test/parisc-linux-boot.html
You will find all useful info there.
Thibaut VARENE
PA/Linux ESIEE Team
http://pateam.esiee.fr/
From Andreas Deresch <aderesch@fs.tum.de> Wed Sep 25 15:00:07 2002
From: Andreas Deresch <aderesch@fs.tum.de> (Andreas Deresch)
Date: Wed, 25 Sep 2002 16:00:07 +0200 (CEST)
Subject: [parisc-linux] hardware newbie question...
In-Reply-To: <3D91BB4F.5090205@esiee.fr>
Message-ID: <Pine.NEB.4.44.0209251557570.7537-100000@io.fachschaften.tu-muenchen.de>
On Wed, 25 Sep 2002, Thibaut VARENE wrote:
> Stephen J de Vries wrote:
> > I have a HP 712 that I'd purchased recently.
> >
> > My question is:
> >
> > Can I use a PC monitor, keyboard, and mouse to boot the thing up? If so,
> > does the monitor have to be a multisync or something special?
> OK for the PC monitor. Use 'Tab' at boot time to switch 712's resolution
> NO for the PC keyboard (pc kbd is 75mA iirc, 712 is 500mA)
Hhmm. I have used two different PS/2 keyboards on a 712. So far nothing
unexpected has happened to either the box nor the keyboard... it works just
fine.
ad
From c.beerse@torex-hiscom.nl Wed Sep 25 15:02:31 2002
From: c.beerse@torex-hiscom.nl (=?iso-8859-1?Q?=22Beerse=2C_Corn=E9=22?=)
Date: Wed, 25 Sep 2002 16:02:31 +0200
Subject: [parisc-linux] hardware newbie question...
Message-ID: <02Sep25.161413cest.119074@ns.hiscom.nl>
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_01C2649C.30D8B720
Content-Type: text/plain;
charset="iso-8859-1"
> -----Original Message-----
> From: Stephen J de Vries [mailto:paulhill20@juno.com]
> I have a HP 712 that I'd purchased recently.
>
>
> Can I use a PC monitor, keyboard, and mouse to boot the thing
> up? If so,
> does the monitor have to be a multisync or something special?
I've had a 712 (running HP-UX 10.20) with a multisync monitor (compaq,
before the merger) running verry well.
As I recal, the monitor should do a sync-on-green. If you don't get a proper
picture and have a monitor-cable connection with bnc connectors, try putting
the cable-sync on the monitor-green. This should give a sharp (bad collored)
picture.
For the mouse, the HP mouse that came with the device looks verry much like
a logitech mouse with a black logitech icon. 2 exceptions: the labels differ
and the logitech has a shorter cable. The same logitech with a colored icon
on top does not work. The mouse must be a native ps/2 mouse, not one that
can do serial-mousing too.
For the keyboard: try and see what you get. No experiences with alternates
here. As with the mouse, the keyboard must be native ps/2 since it does not
get any initialize command. An easy test here is that if the bootloader
finds a keyboard, it wil use that keyboard and the video-card for
bootconsole. If the keyboard is not found, the serial-port (9600-8-N) is
used for console.
>
> In addition, HP-UX is on the hard drive but is locked down. I was
> thinking of buying an external CD drive and attempting to load debian
> 0.93. Can anyone recommend a place to buy the CD drive that they have
Any scsi cd-rom that can do a 2K blocksize will do for booting. After boot,
there is no difference. HP-s are relabeled Toshiba's.
> dealt with? I also have a network so I could attempt a
> network install
> but I am not sure what minimum requirements I'd need to
> fulfill for that.
> Is my approach the right one?
It's one right one, out of manny...
CBee
------_=_NextPart_001_01C2649C.30D8B720
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.45">
<TITLE>RE: [parisc-linux] hardware newbie question...</TITLE>
</HEAD>
<BODY>
<P><FONT SIZE=3D2>> -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>> From: Stephen J de Vries [<A =
HREF=3D"mailto:paulhill20@juno.com">mailto:paulhill20@juno.com</A>]</FON=
T>
<BR><FONT SIZE=3D2>> I have a HP 712 that I'd purchased =
recently.</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> Can I use a PC monitor, keyboard, and mouse to =
boot the thing </FONT>
<BR><FONT SIZE=3D2>> up? If so,</FONT>
<BR><FONT SIZE=3D2>> does the monitor have to be a multisync or =
something special?</FONT>
</P>
<P><FONT SIZE=3D2>I've had a 712 (running HP-UX 10.20) with a multisync =
monitor (compaq, before the merger) running verry well.</FONT>
</P>
<P><FONT SIZE=3D2>As I recal, the monitor should do a sync-on-green. If =
you don't get a proper picture and have a monitor-cable connection with =
bnc connectors, try putting the cable-sync on the monitor-green. This =
should give a sharp (bad collored) picture.</FONT></P>
<P><FONT SIZE=3D2>For the mouse, the HP mouse that came with the device =
looks verry much like a logitech mouse with a black logitech icon. 2 =
exceptions: the labels differ and the logitech has a shorter cable. The =
same logitech with a colored icon on top does not work. The mouse must =
be a native ps/2 mouse, not one that can do serial-mousing =
too.</FONT></P>
<P><FONT SIZE=3D2>For the keyboard: try and see what you get. No =
experiences with alternates here. As with the mouse, the keyboard must =
be native ps/2 since it does not get any initialize command. An easy =
test here is that if the bootloader finds a keyboard, it wil use that =
keyboard and the video-card for bootconsole. If the keyboard is not =
found, the serial-port (9600-8-N) is used for console.</FONT></P>
<P><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> In addition, HP-UX is on the hard drive but is =
locked down. I was</FONT>
<BR><FONT SIZE=3D2>> thinking of buying an external CD drive and =
attempting to load debian</FONT>
<BR><FONT SIZE=3D2>> 0.93. Can anyone recommend a place to buy =
the CD drive that they have</FONT>
</P>
<P><FONT SIZE=3D2>Any scsi cd-rom that can do a 2K blocksize will do =
for booting. After boot, there is no difference. HP-s are relabeled =
Toshiba's. </FONT></P>
<P><FONT SIZE=3D2>> dealt with? I also have a network so I =
could attempt a </FONT>
<BR><FONT SIZE=3D2>> network install</FONT>
<BR><FONT SIZE=3D2>> but I am not sure what minimum requirements I'd =
need to </FONT>
<BR><FONT SIZE=3D2>> fulfill for that.</FONT>
<BR><FONT SIZE=3D2>> Is my approach the right one?</FONT>
</P>
<P><FONT SIZE=3D2>It's one right one, out of manny...</FONT>
</P>
<BR>
<P><FONT SIZE=3D2>CBee</FONT>
</P>
</BODY>
</HTML>
------_=_NextPart_001_01C2649C.30D8B720--
From kennywest1@hotmail.com Wed Sep 25 16:44:17 2002
From: kennywest1@hotmail.com (kenneth westelinck)
Date: Wed, 25 Sep 2002 17:44:17 +0200
Subject: [parisc-linux] hardware newbie question...
References: <20020925.090915.-178139.3.paulhill20@juno.com> <3D91BB4F.5090205@esiee.fr>
Message-ID: <OE132K4xDh9vXsFFsAi00001718@hotmail.com>
I have a 712 with the following peripherals:
- monitor from NCD
- mouse from IBM
- keyboard from Phillips
Works just fine.
----- Original Message -----
From: "Thibaut VARENE" <varenet@esiee.fr>
To: "Stephen J de Vries" <paulhill20@juno.com>
Cc: <parisc-linux@lists.parisc-linux.org>
Sent: Wednesday, September 25, 2002 3:34 PM
Subject: Re: [parisc-linux] hardware newbie question...
> Stephen J de Vries wrote:
> > I have a HP 712 that I'd purchased recently.
> >
> > My question is:
> >
> > Can I use a PC monitor, keyboard, and mouse to boot the thing up? If
so,
> > does the monitor have to be a multisync or something special?
> OK for the PC monitor. Use 'Tab' at boot time to switch 712's resolution
> NO for the PC keyboard (pc kbd is 75mA iirc, 712 is 500mA)
> I don't know for the mouse.
> >
> > In addition, HP-UX is on the hard drive but is locked down. I was
> > thinking of buying an external CD drive and attempting to load debian
> > 0.93. Can anyone recommend a place to buy the CD drive that they have
> > dealt with? I also have a network so I could attempt a network install
> > but I am not sure what minimum requirements I'd need to fulfill for
that.
> You can unlock HP/UX pretty easily if the box isn't in secure mode.
> Just stop the boot sequence and at the BOOT_ADMIN prompt type 'bo pri ipl'
>
> Then answer 'y' to the 'interract with...' question, and then type (i
> don't know if we can say this here ;o)
>
> hpux -iS
>
> If the box is in secure mode there is a workaround:
> Open it, unplug the HD, boot it, wait for timeout, and then deactivate
> the secure mode ;)
> then reboot again.
>
>
> You can definitly use network to install.
> Check the palinux boot howto.
> I recommend you use the latest version (still under review, that's why
> it's not yet available on tldp):
> http://testpa.esiee.fr/.test/parisc-linux-boot.html
>
> You will find all useful info there.
>
>
> Thibaut VARENE
> PA/Linux ESIEE Team
> http://pateam.esiee.fr/
>
>
> _______________________________________________
> parisc-linux mailing list
> parisc-linux@lists.parisc-linux.org
> http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
>
From jsoe0708@tiscali.be Wed Sep 25 16:56:08 2002
From: jsoe0708@tiscali.be (jsoe0708@tiscali.be)
Date: Wed, 25 Sep 2002 17:56:08 +0200
Subject: [parisc-linux] Failure when compile 2.4.19-pa20
Message-ID: <3D8F011400000BEB@ocpmta2.be.tiscali.com>
Hi all,
I got USB part of .config from debian-configs/32 (I work on a b180) and try
to compile 2.4.19-pa20 but it failled:
`gcc -print-libgcc-file-name` /usr/src/linux-2.4.19/arch/parisc/lib/lib.a
/usr/src/linux-2.4.19/lib/lib.a \
--end-group \
-o vmlinux
drivers/usb/usbdrv.o: In function `hidinput_hid_event':
drivers/usb/usbdrv.o(.text.hidinput_hid_event+0x80): undefined reference
to `input_event'
drivers/usb/usbdrv.o(.text.hidinput_hid_event+0xb0): undefined reference
to `input_event'
drivers/usb/usbdrv.o: In function `.L951':
drivers/usb/usbdrv.o(.text.hidinput_hid_event+0xfc): undefined reference
to `input_event'
drivers/usb/usbdrv.o: In function `.L939':
drivers/usb/usbdrv.o(.text.hidinput_hid_event+0x13c): undefined reference
to `input_event'
drivers/usb/usbdrv.o: In function `.L959':
drivers/usb/usbdrv.o(.text.hidinput_hid_event+0x174): undefined reference
to `input_event'
drivers/usb/usbdrv.o(.text.hidinput_hid_event+0x1ac): more undefined references
to `input_event' follow
drivers/usb/usbdrv.o: In function `hidinput_connect':
drivers/usb/usbdrv.o(.text.hidinput_connect+0x16c): undefined reference to
`input_register_device'
drivers/usb/usbdrv.o: In function `hidinput_disconnect':
drivers/usb/usbdrv.o(.text.hidinput_disconnect+0x10): undefined reference
to `input_unregister_device'
make: *** [vmlinux] Error 1
Well, I do not need USB for this HW so I will remove for next try.
HTH,
Joel
From willy@debian.org Wed Sep 25 17:02:25 2002
From: willy@debian.org (Matthew Wilcox)
Date: Wed, 25 Sep 2002 17:02:25 +0100
Subject: [parisc-linux] Failure when compile 2.4.19-pa20
In-Reply-To: <3D8F011400000BEB@ocpmta2.be.tiscali.com>; from jsoe0708@tiscali.be on Wed, Sep 25, 2002 at 05:56:08PM +0200
References: <3D8F011400000BEB@ocpmta2.be.tiscali.com>
Message-ID: <20020925170225.D25721@parcelfarce.linux.theplanet.co.uk>
On Wed, Sep 25, 2002 at 05:56:08PM +0200, jsoe0708@tiscali.be wrote:
> I got USB part of .config from debian-configs/32 (I work on a b180) and try
> to compile 2.4.19-pa20 but it failled:
i'd guess you didn't select CONFIG_INPUT
--
Revolutions do not require corporate support.
From deller@gmx.de Wed Sep 25 17:47:30 2002
From: deller@gmx.de (Helge Deller)
Date: Wed, 25 Sep 2002 18:47:30 +0200
Subject: [parisc-linux] Failure when compile 2.4.19-pa20
In-Reply-To: <20020925170225.D25721@parcelfarce.linux.theplanet.co.uk>
References: <3D8F011400000BEB@ocpmta2.be.tiscali.com> <20020925170225.D25721@parcelfarce.linux.theplanet.co.uk>
Message-ID: <200209251847.30715.deller@gmx.de>
On Wednesday 25 September 2002 18:02, Matthew Wilcox wrote:
> On Wed, Sep 25, 2002 at 05:56:08PM +0200, jsoe0708@tiscali.be wrote:
> > I got USB part of .config from debian-configs/32 (I work on a b180) and
> > try to compile 2.4.19-pa20 but it failled:
>
> i'd guess you didn't select CONFIG_INPUT
CONFIG_INPUT=y
CONFIG_INPUT_EVDEV=y
helge
From Stephan <stephan@itp.bg> Wed Sep 25 22:00:40 2002
From: Stephan <stephan@itp.bg> (Stephan)
Date: Wed, 25 Sep 2002 23:00:40 +0200
Subject: [parisc-linux] netacct-mysql compilation problem
Message-ID: <20020925195914.081FA4829@dsl2.external.hp.com>
<P>hello, today I downloaded CVS of netacct-mysql, it perfect working na x86
linux, but not on Debian HPPA. It is good software for traffic accounting
written by another bulgarian, like me:)<BR>When I start this program, these
errors appears:</P>
<P>Sep 25 22:54:02 obzor kernel: do_page_fault() pid=25917 command='nacctd'
type=15 address=0x00000000<BR>Sep 25 22:54:02 obzor kernel: <BR>Sep 25
22:54:02 obzor kernel:
YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI<BR>Sep 25 22:54:02 obzor kernel: PSW:
00000000000001001111111100001111 Not tainted<BR>Sep 25 22:54:02 obzor
kernel: r00-03 00000000 0002a1d8 00018293 00000000<BR>Sep 25 22:54:02
obzor kernel: r04-07 bff03f10 0002a9d8 0002a9d8 0002a9d8<BR>Sep 25
22:54:02 obzor kernel: r08-11 0002a9d8 0002a9d8 00018800
000d9e08<BR>Sep 25 22:54:02 obzor kernel: r12-15 00000000 000d8d28
000dd7c8 000e3ce8<BR>Sep 25 22:54:02 obzor kernel: r16-19 00000000
000d2470 0009e800 00000000<BR>Sep 25 22:54:02 obzor kernel: r20-23
00001000 400515e0 0002d6c0 0000208d<BR>Sep 25 22:54:02 obzor kernel:
r24-27 0000208d 00000000 00000000 0002a1d8<BR>Sep 25 22:54:02 obzor
kernel: r28-31 bff03f10 00000020 bff04180 40252ff3<BR>Sep 25 22:54:02
obzor kernel: sr0-3 000024e0 000024e0 00000000 000024e0<BR>Sep
25 22:54:02 obzor kernel: sr4-7 000024e0 000024e0 000024e0
000024e0<BR>Sep 25 22:54:02 obzor kernel: <BR>Sep 25 22:54:02 obzor kernel:
IASQ: 000024e0 000024e0 IAOQ: 00017c83 00017c87<BR>Sep 25 22:54:02 obzor
kernel: IIR: 0e60109c ISR: 000024e0 IOR:
00000000<BR>Sep 25 22:54:02 obzor kernel:
CPU: 1 CR30: 1c2c8000
CR31: f7feefca<BR>Sep 25 22:54:02 obzor kernel: ORIG_R28: bff03f10</P>
<P>where can be the problem, please help!</P>
<P>the source of netacct-mysql can be found
netacct-mysql.sourceforge.net</P>
<P> </P>
<P> </P>
<P>Regards</P><br>
<br>
________________________________________________<br>
This mail was sent by Godzilla 1.0<br>
From bwheadley@earthlink.net Wed Sep 25 21:44:47 2002
From: bwheadley@earthlink.net (Bryan W. Headley)
Date: Wed, 25 Sep 2002 15:44:47 -0500
Subject: [parisc-linux] Mouse stops working when exiting KDE
References: <3D8F01140000099E@ocpmta2.be.tiscali.com>
Message-ID: <3D92203F.3020801@earthlink.net>
jsoe0708@tiscali.be wrote:
> Hi Brian,
>
> Sorry, the last test I do on my b180 and gpmdata as mouse driver does not
> work :)
> (xfree86-4.1)
>
Forgot what mouse type you're supposed to tell X you have. Just tried it
on my i386, and had a hung mouse real fast! I thought it was Imps/2, but
obviously not...
You are right -- if you return to the console with control-alt-F[1-6],
and then back again, the issue clears up. It's a well-known but
irritating "solution"
--
____ .:. ____
Bryan W. Headley - bwheadley@earthlink.net
From dave@hiauly1.hia.nrc.ca Wed Sep 25 21:13:41 2002
From: dave@hiauly1.hia.nrc.ca (John David Anglin)
Date: Wed, 25 Sep 2002 16:13:41 -0400 (EDT)
Subject: [parisc-linux] netacct-mysql compilation problem
In-Reply-To: <20020925195914.081FA4829@dsl2.external.hp.com> from "Stephan" at Sep 25, 2002 11:00:40 pm
Message-ID: <200209252013.g8PKDfD4000908@hiauly1.hia.nrc.ca>
> <P>Sep 25 22:54:02 obzor kernel: do_page_fault() pid=25917 command='nacctd'
> type=15 address=0x00000000<BR>Sep 25 22:54:02 obzor kernel: <BR>Sep 25
Looks like a NULL pointer.
> IASQ: 000024e0 000024e0 IAOQ: 00017c83 00017c87<BR>Sep 25 22:54:02 obzor
The instruction causing the fault is at 0x00017c80. This is probably
a coding problem in the source. Some systems are more tolerant of
NULL pointers than others. You would need to use a debugger to
investigate further.
Dave
--
J. David Anglin dave.anglin@nrc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6605)
From Steve.Grady@csiro.au Thu Sep 26 02:05:31 2002
From: Steve.Grady@csiro.au (Steve.Grady@csiro.au)
Date: Thu, 26 Sep 2002 11:05:31 +1000
Subject: [parisc-linux] EISA 100 Base-T Ethernet card drivers
Message-ID: <49AA3A3C863E5B4C911320AEF99E5DA3010CCCE0@wing-ep.tip.csiro.au>
Hi,
Are there drivers available for EISA 100 Base-T cards such are the HP
A4308A.
If there are what is the driver called and is there anything I need to know
in
getting it to work on my D370.
Thanks in advance,
Steve Grady
Sydney Australia
From willy@debian.org Thu Sep 26 03:19:56 2002
From: willy@debian.org (Matthew Wilcox)
Date: Thu, 26 Sep 2002 03:19:56 +0100
Subject: [parisc-linux] EISA 100 Base-T Ethernet card drivers
In-Reply-To: <49AA3A3C863E5B4C911320AEF99E5DA3010CCCE0@wing-ep.tip.csiro.au>; from Steve.Grady@csiro.au on Thu, Sep 26, 2002 at 11:05:31AM +1000
References: <49AA3A3C863E5B4C911320AEF99E5DA3010CCCE0@wing-ep.tip.csiro.au>
Message-ID: <20020926031956.A5179@parcelfarce.linux.theplanet.co.uk>
On Thu, Sep 26, 2002 at 11:05:31AM +1000, Steve.Grady@csiro.au wrote:
> Are there drivers available for EISA 100 Base-T cards such are the HP
> A4308A.
> If there are what is the driver called and is there anything I need to know
> in
> getting it to work on my D370.
this chip is the 82556, which is apparently AKA the "EtherExpress PRO/100
Smart". I don't know what's so smart about it, but the eepro100 driver
doesn't claim to support it. I think you're out of luck.
--
Revolutions do not require corporate support.
From jsoe0708@tiscali.be Thu Sep 26 07:16:21 2002
From: jsoe0708@tiscali.be (jsoe0708@tiscali.be)
Date: Thu, 26 Sep 2002 08:16:21 +0200
Subject: [parisc-linux] Mouse stops working when exiting KDE
In-Reply-To: <3D92203F.3020801@earthlink.net>
Message-ID: <3D8F011400000D77@ocpmta2.be.tiscali.com>
>> Hi Brian,
>>
>> Sorry, the last test I do on my b180 and gpmdata as mouse driver does
not
>> work :)
>> (xfree86-4.1)
>>
>Forgot what mouse type you're supposed to tell X you have. Just tried it
>
>on my i386, and had a hung mouse real fast! I thought it was Imps/2, but
>
>obviously not...
>
>You are right -- if you return to the console with control-alt-F[1-6],
>and then back again, the issue clears up. It's a well-known but
>irritating "solution"
Ah, I am not an 'e X pert' :)) and I am ignoring (thanks).
In the mean time, I recieved a mail from Branden Robinson <branden@debian.org>
proposing it is help. He will need some help with 'try an experimental debugging
X server package. Ever used gdb to attach to a running X server before?'.
If you feel more competent (I am not very capable in X field) and more time
(than I) I can send you its answer?
Cheers,
Joel
From jsoe0708@tiscali.be Thu Sep 26 07:22:47 2002
From: jsoe0708@tiscali.be (jsoe0708@tiscali.be)
Date: Thu, 26 Sep 2002 08:22:47 +0200
Subject: [parisc-linux] Failure when compile 2.4.19-pa20
In-Reply-To: <200209251847.30715.deller@gmx.de>
Message-ID: <3D8F011400000D7C@ocpmta2.be.tiscali.com>
>-- Original Message --
>From: Helge Deller <deller@gmx.de>
>To: Matthew Wilcox <willy@debian.org>,
> jsoe0708@tiscali.be
>Subject: Re: [parisc-linux] Failure when compile 2.4.19-pa20
>Date: Wed, 25 Sep 2002 18:47:30 +0200
>Cc: parisc-linux@lists.parisc-linux.org
>
>
>On Wednesday 25 September 2002 18:02, Matthew Wilcox wrote:
>> On Wed, Sep 25, 2002 at 05:56:08PM +0200, jsoe0708@tiscali.be wrote:
>> > I got USB part of .config from debian-configs/32 (I work on a b180)
and
>> > try to compile 2.4.19-pa20 but it failled:
>>
>> i'd guess you didn't select CONFIG_INPUT
>
>CONFIG_INPUT=y
>CONFIG_INPUT_EVDEV=y
>
>helge
>
That is may mistake (just take out off context a part of the .config file
:( )
Thanks a lot for attention and help,
Joel
From bodack@stud.fh-heilbronn.de Thu Sep 26 12:04:08 2002
From: bodack@stud.fh-heilbronn.de (Yves Bodack)
Date: Thu, 26 Sep 2002 13:04:08 +0200
Subject: [parisc-linux] X Apps on 712 vs. 735 Was: RTC and FB on 735/125
References: <03ab01c26266$2416dea0$1f96078d@acid><20020922220323.0113cbca.varenet@esiee.fr><03bf01c2627c$9a5147c0$1f96078d@acid> <03ed01c26280$4dfb5c90$1f96078d@acid><1032793227.1848.222.camel@romano> <003001c26327$d0db42e0$1f96078d@acid><1032806776.2868.19.camel@romano> <002a01c263bf$76340820$1f96078d@acid><3D9052C9.3060704@esiee.fr> <1032880521.1338.181.camel@romano> <3D9085B1.5030503@esiee.fr> <1032882750.384.10.camel@seventy>
Message-ID: <001b01c2654c$6ff91570$1f96078d@acid>
From: "James Smith" <james@compusmithllc.com>
> > >>>Galeon/Mozilla and XMMS start up, but they don't appear on screen and
give
> i've had both konqueror & xmms working fine on my 712/60
Yesterday I did a new Debian install on my 712/60, so it's the very same
system as on my 735/125. The difference is, as decribed before, on 735
galeon and xmms run, but they don't appear on screen. While on my 712 xmms
works and galeon showed a setup wizzard and died right after with an error
message. So I wonder, where this different behavior comes from?
Well, only difference is 24bpp X on 735 vs 8bpp on 712...
Greetings,
Yves...
From jsoe0708@tiscali.be Thu Sep 26 14:19:54 2002
From: jsoe0708@tiscali.be (jsoe0708@tiscali.be)
Date: Thu, 26 Sep 2002 15:19:54 +0200
Subject: [parisc-linux] uaccess.h patch for new evms-1.1.0: correct?
Message-ID: <3D8F01140000102A@ocpmta2.be.tiscali.com>
--=========3D8F01140000102A/mail.tiscali.be
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Hi all,
As I not find "std" emulation (gcc report 'Internal compiler error... PLease
submit a full bug report...) and not more the D, M, L mips prefix (to access
different 32bits part of a 64bits lon long), here is what I proprose as uaccess.h
patch.
Can someone have a look and advise me if I made any error?
Thanks in advance for help,
Joel
PS: Functionaly it seems to work to make evms 1.1.0 works
--=========3D8F01140000102A/mail.tiscali.be
Content-Type: application/octet-stream
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="pa-uaccess_h.patch"
LS0tIHVhY2Nlc3MuaC5vcmlnCTIwMDItMDktMjUgMTM6NTk6MDkuMDAwMDAwMDAwICswMjAwCisr
KyB1YWNjZXNzLmgJMjAwMi0wOS0yNiAxNTowMjoyMy4wMDAwMDAwMDAgKzAyMDAKQEAgLTM1LDEw
ICszNSw0MSBAQAogI2RlZmluZSBnZXRfdXNlciBfX2dldF91c2VyCiAKICNpZiBCSVRTX1BFUl9M
T05HID09IDMyCisKICNkZWZpbmUgTEREX0tFUk5FTChwdHIpCQlCVUcoKQogI2RlZmluZSBMRERf
VVNFUihwdHIpCQlCVUcoKQotI2RlZmluZSBTVERfS0VSTkVMKHgsIHB0cikJQlVHKCkKLSNkZWZp
bmUgU1REX1VTRVIoeCwgcHRyKQlCVUcoKQorI2RlZmluZSBTVERfS0VSTkVMKHgsIHB0cikgICAg
ICAgICAgICAgICAgICAgIFwKKyh7ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICBcCisgICAgdW5pb24gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
XAorICAgIHsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFwKKyAgICAg
ICAgdW5zaWduZWQgbG9uZyBsb25nIFU2NDsgICAgICAgICAgICAgICBcCisgICAgICAgIHN0cnVj
dCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgXAorICAgICAgICB7ICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgIFwKKyAgICAgICAgICAgIHVuc2lnbmVkIGludCB4aDsg
ICAgICAgICAgICAgICAgICBcCisgICAgICAgICAgICB1bnNpZ25lZCBpbnQgeGw7ICAgICAgICAg
ICAgICAgICAgXAorICAgICAgICB9ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
IFwKKwlVNjRYaFhsOyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFwKKyAgICB9VWxsaTsg
LyogVW5pb24gbG9uZyBsb25nIGludCAqLyAgICAgICAgICBcCisgICAgVWxsaS5VNjQ9KHVuc2ln
bmVkIGxvbmcgbG9uZykgeDsgICAgICAgICAgXAorICAgIF9fcHV0X2tlcm5lbF9hc21fNjQoVWxs
aS5VNjRYaFhsLnhoLCBVbGxpLlU2NFhoWGwueGwsIHB0cik7ICAgICAgICAgICBcCit9KQorCisj
ZGVmaW5lIFNURF9VU0VSKHgsIHB0cikgICAgICAgICAgICAgICAgICAgICAgXAorKHsgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFwKKyAgICB1bmlvbiAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBcCisgICAgeyAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgXAorICAgICAgICB1bnNpZ25lZCBsb25nIGxvbmcgVTY0OyAg
ICAgICAgICAgICAgIFwKKyAgICAgICAgc3RydWN0ICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICBcCisgICAgICAgIHsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgXAor
ICAgICAgICAgICAgdW5zaWduZWQgaW50IHhoOyAgICAgICAgICAgICAgICAgIFwKKyAgICAgICAg
ICAgIHVuc2lnbmVkIGludCB4bDsgICAgICAgICAgICAgICAgICBcCisgICAgICAgIH0gICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgXAorCVU2NFhoWGw7ICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgXAorICAgIH1VbGxpOyAvKiBVbmlvbiBsb25nIGxvbmcgaW50ICovICAg
ICAgICAgIFwKKyAgICBVbGxpLlU2ND0odW5zaWduZWQgbG9uZyBsb25nKSB4OyAgICAgICAgICBc
CisgICAgX19wdXRfdXNlcl9hc21fNjQoVWxsaS5VNjRYaFhsLnhoLCBVbGxpLlU2NFhoWGwueGws
IHB0cik7ICAgICAgICAgICBcCit9KQorCiAjZWxzZQogI2RlZmluZSBMRERfS0VSTkVMKHB0cikg
X19nZXRfa2VybmVsX2FzbSgibGRkIixwdHIpCiAjZGVmaW5lIExERF9VU0VSKHB0cikgX19nZXRf
dXNlcl9hc20oImxkZCIscHRyKQpAQCAtMjAwLDYgKzIzMSwyMCBAQAogCQk6ICI9ciIoX19wdV9l
cnIpICAgICAgICAgICAgICAgICAgICAgICAgICAgIFwKIAkJOiAiciIocHRyKSwgInIiKHgpLCAi
MCIoX19wdV9lcnIpKQogCisjZGVmaW5lIF9fcHV0X2tlcm5lbF9hc21fNjQoeGgsIHhsLCBwdHIp
ICAgICAgICAgICAgICAgICAgICBcCisgICAgICAgIF9fYXNtX18gX192b2xhdGlsZV9fICggICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICBcCisgICAgICAgICAgICAgICAgIlxuMTpcdHN0d1x0
JTIsMCglMSlcbiIgICAgICAgICAgICAgICAgICAgICBcCisgICAgICAgICAgICAgICAgIjI6XHRz
dHdcdCUzLDQoJTEpXG4iICAgICAgICAgICAgICAgICAgICAgICBcCisgICAgICAgICAgICAgICAg
IjM6XG4iICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBcCisgICAgICAgICAg
ICAgICAgIlx0LnNlY3Rpb24gX19leF90YWJsZSxcImFcIlxuIiAgICAgICAgICAgICBcCisgICAg
ICAgICAgICAgICAgICJcdC53b3JkXHQxYlxuIiAgICAgICAgICAgICAgICAgICAgICAgICAgICBc
CisgICAgICAgICAgICAgICAgICJcdC53b3JkXHQoM2ItMWIpKzFcbiIgICAgICAgICAgICAgICAg
ICAgICBcCisgICAgICAgICAgICAgICAgICJcdC53b3JkXHQyYlxuIiAgICAgICAgICAgICAgICAg
ICAgICAgICAgICBcCisgICAgICAgICAgICAgICAgICJcdC53b3JkXHQoM2ItMmIpKzFcbiIgICAg
ICAgICAgICAgICAgICAgICBcCisgICAgICAgICAgICAgICAgICJcdC5wcmV2aW91cyIgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICBcCisgICAgICAgICAgICAgICAgOiAiPXIiKF9fcHVfZXJy
KSAgICAgICAgICAgICAgICAgICAgICAgICAgICBcCisgICAgICAgICAgICAgICAgOiAiciIocHRy
KSwgInIiKHhoKSwgInIiKHhsKSwgIjAiKF9fcHVfZXJyKSkKKwogI2RlZmluZSBfX3B1dF91c2Vy
X2FzbShzdHgseCxwdHIpICAgICAgICAgICAgICAgICAgICAgICAgICAgXAogCV9fYXNtX18gX192
b2xhdGlsZV9fICggICAgICAgICAgICAgICAgICAgICAgICAgICAgICBcCiAJCSJcbjE6XHQiIHN0
eCAiXHQlMiwwKCUlc3IzLCUxKVxuIiAgICAgICAgICAgXApAQCAtMjEwLDYgKzI1NSwyMSBAQAog
CQkgIlx0LnByZXZpb3VzIiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFwKIAkJOiAiPXIi
KF9fcHVfZXJyKSAgICAgICAgICAgICAgICAgICAgICAgICAgICBcCiAJCTogInIiKHB0
ciksICJyIih4KSwgIjAiKF9fcHVfZXJyKSkKKworI2RlZmluZSBfX3B1dF91c2VyX2FzbV82NCh4
aCwgeGwsIHB0cikgICAgICAgICAgICAgICAgICAgICAgXAorICAgICAgICBfX2FzbV9fIF9fdm9s
YXRpbGVfXyAoICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgXAorICAgICAgICAgICAgICAg
ICJcbjE6XHRzdHdcdCUyLDAoJSVzcjMsJTEpXG4iICAgICAgICAgICAgICAgXAorICAgICAgICAg
ICAgICAgICIyOlx0c3R3XHQlMyw0KCUlc3IzLCUxKVxuIiAgICAgICAgICAgICAgICAgXAorICAg
ICAgICAgICAgICAgICIzOlxuIiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
XAorICAgICAgICAgICAgICAgICJcdC5zZWN0aW9uIF9fZXhfdGFibGUsXCJhXCJcbiIgICAgICAg
ICAgICAgXAorICAgICAgICAgICAgICAgICAiXHQud29yZFx0MWJcbiIgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgXAorICAgICAgICAgICAgICAgICAiXHQud29yZFx0KDNiLTFiKSsxXG4iICAg
ICAgICAgICAgICAgICAgICAgXAorICAgICAgICAgICAgICAgICAiXHQud29yZFx0MmJcbiIgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgXAorICAgICAgICAgICAgICAgICAiXHQud29yZFx0KDNi
LTJiKSsxXG4iICAgICAgICAgICAgICAgICAgICAgXAorICAgICAgICAgICAgICAgICAiXHQucHJl
dmlvdXMiICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgXAorICAgICAgICAgICAgICAgIDog
Ij1yIihfX3B1X2VycikgICAgICAgICAgICAgICAgICAgICAgICAgICAgXAorICAgICAgICAgICAg
ICAgIDogInIiKHB0ciksICJyIih4aCksICJyIih4bCksICIwIihfX3B1X2VycikpCisKICNlbmRp
ZgogCiAK
--=========3D8F01140000102A/mail.tiscali.be--
From willy@debian.org Thu Sep 26 20:12:38 2002
From: willy@debian.org (Matthew Wilcox)
Date: Thu, 26 Sep 2002 20:12:38 +0100
Subject: [parisc-linux] EISA 100 Base-T Ethernet card drivers / 3COM
In-Reply-To: <3D935BCC.4060002@gmx.de>; from sven.cronenberg@gmx.de on Thu, Sep 26, 2002 at 09:11:08PM +0200
References: <49AA3A3C863E5B4C911320AEF99E5DA3010CCCE0@wing-ep.tip.csiro.au> <20020926031956.A5179@parcelfarce.linux.theplanet.co.uk> <3D935BCC.4060002@gmx.de>
Message-ID: <20020926201238.G28188@parcelfarce.linux.theplanet.co.uk>
On Thu, Sep 26, 2002 at 09:11:08PM +0200, Sven Cronbenberg wrote:
> I have two HP9000 maschines (735b and 720) standing
> around here with 3COM 100mbit eThernetcards. Have
> any people out there suceeded using those
> ethernetcards und LINUX in the HP9000/7??s?
i don't know. it's worth trying them.
--
Revolutions do not require corporate support.
From viiru@debian.org Fri Sep 27 07:18:18 2002
From: viiru@debian.org (Arto Jantunen)
Date: Fri, 27 Sep 2002 09:18:18 +0300
Subject: [parisc-linux] SMP crash with 64-bit kernel and 32-bit PDC
Message-ID: <20020927061818.GA16225@www1.dt-link.fi>
--G4iJoqBmSsgzjUCe
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
The kernel was built with additional PDC debuging and the options listed
in the subject. If someone needs the .config for something, I can send
it, too. Attached is the log of what happens. If anyone could use any
additional info, I can get it and mail it.
--
Arto Jantunen
--G4iJoqBmSsgzjUCe
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="minicom.cap"
Firmware Version 38.39
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 240 MHz Active Functional 2 MB
1 240 MHz Idle Functional 2 MB
Central Bus Speed (in MHz) : 120
Model: R390/2
Available memory (bytes) : 1073733632
Good memory required (bytes): 86876160
Primary boot path: 8/4.1 (dec)
Alternate boot path: 8/4.6 (dec)
Console path: 8/16/4.0 (dec)
Keyboard path: 8/16/7.0 (dec)
CPU 0
WARNING: Memory has been initialized, but not tested as a result of
FASTBOOT being enabled. To test memory, use the FASTBOOT
command in the CONFIGURATION menu and reboot the system.
Processor is starting autoboot process.
To discontinue, press any key within 10 seconds.
10 seconds expired.
Proceeding...
Trying Primary Boot Path
------------------------
Booting...
Boot IO Dependent Code (IODC) revision 152
HARD Booted.
palo ipl 1.0 root@palinux Mon Apr 1 10:02:53 MST 2002
Partition Start(MB) End(MB) Id Type
1 1 16 f0 Palo
2 49 1002 82 swap
3 1003 4094 83 ext2
4 17 48 83 ext2
PALO(F0) partition contains:
0/vmlinux32 3687647 bytes @ 0x48000
Information: No console specified on kernel command line. This is normal.
PALO will choose the console currently used by firmware (serial).
Command line for kernel: 'root=/dev/sda3 HOME=/ console=ttyS0 TERM=vt102 palo_kernel=4/vmlinux'
Selected kernel: /vmlinux from partition 4
ELF64 executable
Entry 00100000 first 00100000 n 3
Segment 0 load 00100000 size 2412040 mediaptr 0x1000
Segment 1 load 0034e000 size 1520640 mediaptr 0x24e000
Segment 2 load 004c4000 size 49152 mediaptr 0x3c2000
Branching to kernel entry point 0x00100000. If this is the last
message you see, you may need to switch your console. This is
a common symptom -- search the FAQ and mailing list at parisc-linux.org
Linux version 2.4.19-pa20 (root@elli) (gcc version 3.0) #4 SMP Thu Sep 26 17:04:45 EEST 2002
FP[0] enabled: Rev 0 Model 14
The 64-bit Kernel has started...
Initialized PDC Console for debugging.
Kernel is using PDC in 32-bit mode.
Determining PDC firmware type: System Map.
model 00005ba0 00000491 00000000 00000002 7777173a 100000f0 00000008 000000b2 000000b2
vers 00000501
CPUID vers 14 rev 23 (0x000001d7)
capabilities 0x3
model 9000/800/R390
Total Memory: 1024 Mb
pagetable_init
On node 0 totalpages: 262144
zone(0): 262144 pages.
zone(1): 0 pages.
zone(2): 0 pages.
Kernel command line: root=/dev/sda3 HOME=/ console=ttyS0 TERM=vt102 palo_kernel=4/vmlinux
Console: colour dummy device 160x64
Initialized PDC Console for debugging.
Calibrating delay loop... 478.41 BogoMIPS
Memory: 1019632k available
Dentry cache hash table entries: 131072 (order: 9, 2097152 bytes)
Inode cache hash table entries: 65536 (order: 8, 1048576 bytes)
Mount-cache hash table entries: 16384 (order: 6, 262144 bytes)
Buffer-cache hash table entries: 65536 (order: 7, 524288 bytes)
Page-cache hash table entries: 262144 (order: 9, 2097152 bytes)
Searching for devices...
Found devices:
1. U2-IOA BC Runway Port (12) at 0xfffffffffff88000 [8], versions 0x580, 0xf, 0xb
2. Bluefish Add-on FW-SCSI (4) at 0xfffffffff1004000 [8/4], versions 0x13, 0x1, 0x89
3. HP HSC-PCI Cards (4) at 0xfffffffff1008000 [8/8], versions 0x4, 0x0, 0x9d
4. UL 550 Lasi Core BA (11) at 0xffffffffffd00000 [8/16], versions 0x2f, 0x0, 0x81, additional addresses: 0xffffffffffd0c000 0xffffffffffc00000
5. UL 550 Core Centronics (10) at 0xffffffffffd02000 [8/16/0], versions 0x2f, 0x0, 0x74, additional addresses: 0xffffffffffd01000 0xffffffffffd03000
6. UL 550 Lasi Core RS-232 (10) at 0xffffffffffd05000 [8/16/4], versions 0x2f, 0x0, 0x8c
7. UL 550 Core SCSI (10) at 0xffffffffffd06000 [8/16/5], versions 0x2f, 0x0, 0x82
8. UL 350 Core LAN (802.3) (10) at 0xffffffffffd07000 [8/16/6], versions 0x2f, 0x0, 0x8a
9. UL 550 Core PS/2 Port (10) at 0xffffffffffd08000 [8/16/7], versions 0x2f, 0x0, 0x84
10. UL 550 Core PS/2 Port (10) at 0xffffffffffd08100 [8/16/8], versions 0x2f, 0x0, 0x84
11. UL 550 Core Wax BA (11) at 0xffffffffffe00000 [8/20], versions 0x31, 0x0, 0x8e
12. UL 550 Wax Core RS-232 (10) at 0xffffffffffe02000 [8/20/2], versions 0x31, 0x0, 0x8c
13. UL 550 Wax EISA BA (11) at 0xfffffffffc000000 [8/20/5], versions 0x31, 0x0, 0x90, additional addresses: 0xffffffffffc88000
14. U2-IOA BC GSC+ Port (7) at 0xfffffffff103f000 [8/63], versions 0x501, 0x1, 0xc
15. U2-IOA BC Runway Port (12) at 0xfffffffffff8a000 [10], versions 0x580, 0xf, 0xb
16. Bluefish Add-on FW-SCSI (4) at 0xfffffffff180c000 [10/12], versions 0x13, 0x1, 0x89
17. U2-IOA BC GSC+ Port (7) at 0xfffffffff183f000 [10/63], versions 0x501, 0x1, 0xc
18. UL 2w U+/240 (350/550) (0) at 0xfffffffffffa0000 [32], versions 0x5ba, 0x0, 0x4
19. UL 2w U+/240 (350/550) (0) at 0xfffffffffffa2000 [34], versions 0x5ba, 0x0, 0x4
20. Memory (1) at 0xfffffffffffb1000 [49], versions 0x7e, 0x0, 0x9
CPU(s): 2 x PA8200 (PCX-U+) at 240.000000 MHz
Found U2 at 0xfffffffffff88000
Found U2 at 0xfffffffffff8a000
ccio-dma.c: failed to claim CCIO bus address space (ffffffff00000000,ffffffffffffffff)
Lasi version 0 at 0xffffffffffd00000 found.
LED display at ffffffffffd0c000 registered
Wax at 0xffffffffffe00000 found.
Wax EISA Adapter found at 0xfffffffffc000000
EISA EEPROM at 0xffffffffffc88000
Enumerating EISA bus
--G4iJoqBmSsgzjUCe--
From harri.haataja@cs.helsinki.fi Fri Sep 27 09:42:27 2002
From: harri.haataja@cs.helsinki.fi (Harri Haataja)
Date: Fri, 27 Sep 2002 11:42:27 +0300
Subject: [parisc-linux] EISA 100 Base-T Ethernet card drivers / 3COM
In-Reply-To: <20020926201238.G28188@parcelfarce.linux.theplanet.co.uk>; from willy@debian.org on Thu, Sep 26, 2002 at 08:12:38PM +0100
References: <49AA3A3C863E5B4C911320AEF99E5DA3010CCCE0@wing-ep.tip.csiro.au> <20020926031956.A5179@parcelfarce.linux.theplanet.co.uk> <3D935BCC.4060002@gmx.de> <20020926201238.G28188@parcelfarce.linux.theplanet.co.uk>
Message-ID: <20020927114226.A1112@azrael.smilehouse.com>
On Thu, Sep 26, 2002 at 08:12:38PM +0100, Matthew Wilcox wrote:
> On Thu, Sep 26, 2002 at 09:11:08PM +0200, Sven Cronbenberg wrote:
> > I have two HP9000 maschines (735b and 720) standing
> > around here with 3COM 100mbit eThernetcards. Have
> > any people out there suceeded using those
> > ethernetcards und LINUX in the HP9000/7??s?
> i don't know. it's worth trying them.
Wouldn't it be worth it putting together a small list (or even an active
web page) of working devices of any kind on HP-PA hardware?
Or maybe just limited to (E)ISA and pci cards or such?
--
http://www.math.fu-berlin.de/~guckes/sig/
From c.beerse@torex-hiscom.nl Fri Sep 27 12:38:41 2002
From: c.beerse@torex-hiscom.nl (=?iso-8859-1?Q?=22Beerse=2C_Corn=E9=22?=)
Date: Fri, 27 Sep 2002 13:38:41 +0200
Subject: [parisc-linux] EISA 100 Base-T Ethernet card drivers / 3COM
Message-ID: <02Sep27.135037cest.119058@ns.hiscom.nl>
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_01C2661A.6DF0DDC0
Content-Type: text/plain;
charset="iso-8859-1"
> -----Original Message-----
> From: Harri Haataja [mailto:harri.haataja@cs.helsinki.fi]
>
> On Thu, Sep 26, 2002 at 08:12:38PM +0100, Matthew Wilcox wrote:
> > On Thu, Sep 26, 2002 at 09:11:08PM +0200, Sven Cronbenberg wrote:
> > > I have two HP9000 maschines (735b and 720) standing
> > > around here with 3COM 100mbit eThernetcards. Have
> > > any people out there suceeded using those
> > > ethernetcards und LINUX in the HP9000/7??s?
> > i don't know. it's worth trying them.
>
> Wouldn't it be worth it putting together a small list (or
> even an active
> web page) of working devices of any kind on HP-PA hardware?
> Or maybe just limited to (E)ISA and pci cards or such?
Best place would be the already available hardware database...
Is there already a hook to that?
Or on the other hand, does HP have such a list for devices in hp-ux? I guess
that devices that work on i386 architectures in linux and on pa-risc
architectures in HP-UX (hence hardware does not bite and driver sources are
available) should be usable.
CBee
------_=_NextPart_001_01C2661A.6DF0DDC0
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.45">
<TITLE>RE: [parisc-linux] EISA 100 Base-T Ethernet card drivers / =
3COM</TITLE>
</HEAD>
<BODY>
<P><FONT SIZE=3D2>> -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>> From: Harri Haataja [<A =
HREF=3D"mailto:harri.haataja@cs.helsinki.fi">mailto:harri.haataja@cs.hel=
sinki.fi</A>]</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> On Thu, Sep 26, 2002 at 08:12:38PM +0100, =
Matthew Wilcox wrote:</FONT>
<BR><FONT SIZE=3D2>> > On Thu, Sep 26, 2002 at 09:11:08PM +0200, =
Sven Cronbenberg wrote:</FONT>
<BR><FONT SIZE=3D2>> > > I have two HP9000 maschines (735b and =
720) standing</FONT>
<BR><FONT SIZE=3D2>> > > around here with 3COM 100mbit =
eThernetcards. Have</FONT>
<BR><FONT SIZE=3D2>> > > any people out there suceeded using =
those</FONT>
<BR><FONT SIZE=3D2>> > > ethernetcards und LINUX in the =
HP9000/7??s?</FONT>
<BR><FONT SIZE=3D2>> > i don't know. it's worth trying =
them.</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> Wouldn't it be worth it putting together a =
small list (or </FONT>
<BR><FONT SIZE=3D2>> even an active</FONT>
<BR><FONT SIZE=3D2>> web page) of working devices of any kind on =
HP-PA hardware?</FONT>
<BR><FONT SIZE=3D2>> Or maybe just limited to (E)ISA and pci cards =
or such?</FONT>
</P>
<P><FONT SIZE=3D2>Best place would be the already available hardware =
database...</FONT>
<BR><FONT SIZE=3D2>Is there already a hook to that?</FONT>
</P>
<P><FONT SIZE=3D2>Or on the other hand, does HP have such a list for =
devices in hp-ux? I guess that devices that work on i386 architectures =
in linux and on pa-risc architectures in HP-UX (hence hardware does not =
bite and driver sources are available) should be usable.</FONT></P>
<BR>
<P><FONT SIZE=3D2>CBee</FONT>
</P>
<BR>
</BODY>
</HTML>
------_=_NextPart_001_01C2661A.6DF0DDC0--
From harri.haataja@cs.helsinki.fi Fri Sep 27 12:47:00 2002
From: harri.haataja@cs.helsinki.fi (Harri Haataja)
Date: Fri, 27 Sep 2002 14:47:00 +0300
Subject: [parisc-linux] EISA 100 Base-T Ethernet card drivers / 3COM
In-Reply-To: <02Sep27.135037cest.119058@ns.hiscom.nl>; from c.beerse@torex-hiscom.nl on Fri, Sep 27, 2002 at 01:38:41PM +0200
References: <02Sep27.135037cest.119058@ns.hiscom.nl>
Message-ID: <20020927144656.A1816@azrael.smilehouse.com>
On Fri, Sep 27, 2002 at 01:38:41PM +0200, "Beerse, Corné" wrote:
> > From: Harri Haataja [mailto:harri.haataja@cs.helsinki.fi]
> > On Thu, Sep 26, 2002 at 08:12:38PM +0100, Matthew Wilcox wrote:
> > > On Thu, Sep 26, 2002 at 09:11:08PM +0200, Sven Cronbenberg wrote:
> > > > I have two HP9000 maschines (735b and 720) standing
> > > > around here with 3COM 100mbit eThernetcards. Have
> > > > any people out there suceeded using those
> > > > ethernetcards und LINUX in the HP9000/7??s?
> > > i don't know. it's worth trying them.
> > Wouldn't it be worth it putting together a small list (or even an
> > active web page) of working devices of any kind on HP-PA hardware?
> > Or maybe just limited to (E)ISA and pci cards or such?
> Best place would be the already available hardware database...
> Is there already a hook to that?
>
> Or on the other hand, does HP have such a list for devices in hp-ux? I
> guess that devices that work on i386 architectures in linux and on
> pa-risc architectures in HP-UX (hence hardware does not bite and
> driver sources are available) should be usable.
I have heard only random rumours and one thingj driving me to Linux is
that HP-UX doesn't support really any cards that might be available to
me. What I'd like to see is a list of "reported working" cards and
drivers. That would ofcourse be nice on other architectures as well.
--
Cat said, "I am not a friend, and I am not a Servant, I am the Cat who
walks by himself, and I wish to come into your cave."
-- Rudyard Kipling
From jsoe0708@tiscali.be Fri Sep 27 15:50:31 2002
From: jsoe0708@tiscali.be (jsoe0708@tiscali.be)
Date: Fri, 27 Sep 2002 16:50:31 +0200
Subject: [parisc-linux] MM gurus help request
Message-ID: <3D8F011400001618@ocpmta2.be.tiscali.com>
Hi all,
To manage put_user(x, ptr) with x a 64bits (long long), I found another way
to access the address of x and suggest following solution.
--- uaccess.h.orig 2002-09-25 13:59:09.000000000 +0200
+++ uaccess.h 2002-09-27 16:57:06.000000000 +0200
@@ -35,10 +35,13 @@
#define get_user __get_user
#if BITS_PER_LONG == 32
+
#define LDD_KERNEL(ptr) BUG()
#define LDD_USER(ptr) BUG()
-#define STD_KERNEL(x, ptr) BUG()
-#define STD_USER(x, ptr) BUG()
+#define STD_KERNEL(x, ptr) __put_kernel_asm_64(x, ptr)
+
+#define STD_USER(x, ptr) __put_user_asm_64(x, ptr)
+
#else
#define LDD_KERNEL(ptr) __get_kernel_asm("ldd",ptr)
#define LDD_USER(ptr) __get_user_asm("ldd",ptr)
@@ -137,6 +140,7 @@
#define __put_user(x,ptr) \
({ \
register long __pu_err __asm__ ("r8") = 0; \
+ register long long * __tmp = 0; \
\
if (segment_eq(get_fs(),KERNEL_DS)) { \
switch (sizeof(*(ptr))) { \
@@ -200,6 +204,22 @@
: "=r"(__pu_err) \
: "r"(ptr), "r"(x), "0"(__pu_err))
+#define __put_kernel_asm_64(x, ptr) \
+ __asm__ __volatile__ ( \
+ "\n\tldw\t0(%2),%3\n" \
+ "1:\tstw\t%3,0(%1)\n" \
+ "\tldw\t4(%2),%3\n" \
+ "2:\tstw\t%3,4(%1)\n" \
+ "3:\n" \
+ "\t.section __ex_table,\"a\"\n" \
+ "\t.word\t1b\n" \
+ "\t.word\t(3b-1b)+1\n" \
+ "\t.word\t2b\n" \
+ "\t.word\t(3b-2b)+1\n" \
+ "\t.previous" \
+ : "=r"(__pu_err) \
+ : "r"(ptr), "r"(&x), "r"(__tmp), "0"(__pu_err))
+
#define __put_user_asm(stx,x,ptr) \
__asm__ __volatile__ ( \
"\n1:\t" stx "\t%2,0(%%sr3,%1)\n" \
@@ -210,6 +230,23 @@
"\t.previous" \
: "=r"(__pu_err) \
: "r"(ptr), "r"(x), "0"(__pu_err))
+
+#define __put_user_asm_64(x, ptr) \
+ __asm__ __volatile__ ( \
+ "\n\tldw\t0(%%sr3,%2),%3\n" \
+ "1:\tstw\t%3,0(%%sr3,%1)\n" \
+ "\tldw\t4(%%sr3,%2),%3\n" \
+ "2:\tstw\t%3,4(%%sr3,%1)\n" \
+ "3:\n" \
+ "\t.section __ex_table,\"a\"\n" \
+ "\t.word\t1b\n" \
+ "\t.word\t(3b-1b)+1\n" \
+ "\t.word\t2b\n" \
+ "\t.word\t(3b-2b)+1\n" \
+ "\t.previous" \
+ : "=r"(__pu_err) \
+ : "r"(ptr), "r"(&x), "r"(__tmp), "0"(__pu_err))
+
#endif
Could a mm gurus help me to check if I do not break memory management?
Thanks in advance for additional help,
Joel
From jsoe0708@tiscali.be Fri Sep 27 16:11:23 2002
From: jsoe0708@tiscali.be (jsoe0708@tiscali.be)
Date: Fri, 27 Sep 2002 17:11:23 +0200
Subject: [parisc-linux] MM gurus help request
In-Reply-To: <3D8F011400001618@ocpmta2.be.tiscali.com>
Message-ID: <3D8F01140000163B@ocpmta2.be.tiscali.com>
Sorry it is bad :(
>
>Hi all,
>
>To manage put_user(x, ptr) with x a 64bits (long long), I found another
way
>to access the address of x and suggest following solution.
>
>--- uaccess.h.orig 2002-09-25 13:59:09.000000000 +0200
>+++ uaccess.h 2002-09-27 16:57:06.000000000 +0200
>@@ -35,10 +35,13 @@
> #define get_user __get_user
>
> #if BITS_PER_LONG == 32
>+
> #define LDD_KERNEL(ptr) BUG()
> #define LDD_USER(ptr) BUG()
>-#define STD_KERNEL(x, ptr) BUG()
>-#define STD_USER(x, ptr) BUG()
>+#define STD_KERNEL(x, ptr) __put_kernel_asm_64(x, ptr)
>+
>+#define STD_USER(x, ptr) __put_user_asm_64(x, ptr)
>+
> #else
> #define LDD_KERNEL(ptr) __get_kernel_asm("ldd",ptr)
> #define LDD_USER(ptr) __get_user_asm("ldd",ptr)
>@@ -137,6 +140,7 @@
> #define __put_user(x,ptr) \
> ({ \
> register long __pu_err __asm__ ("r8") = 0; \
>+ register long long * __tmp = 0; \
> \
> if (segment_eq(get_fs(),KERNEL_DS)) { \
> switch (sizeof(*(ptr))) { \
>@@ -200,6 +204,22 @@
> : "=r"(__pu_err) \
> : "r"(ptr), "r"(x), "0"(__pu_err))
>
>+#define __put_kernel_asm_64(x, ptr) \
>+ __asm__ __volatile__ ( \
>+ "\n\tldw\t0(%2),%3\n" \
>+ "1:\tstw\t%3,0(%1)\n" \
>+ "\tldw\t4(%2),%3\n" \
>+ "2:\tstw\t%3,4(%1)\n" \
>+ "3:\n" \
>+ "\t.section __ex_table,\"a\"\n" \
>+ "\t.word\t1b\n" \
>+ "\t.word\t(3b-1b)+1\n" \
>+ "\t.word\t2b\n" \
>+ "\t.word\t(3b-2b)+1\n" \
>+ "\t.previous" \
>+ : "=r"(__pu_err) \
>+ : "r"(ptr), "r"(&x), "r"(__tmp), "0"(__pu_err))
>+
> #define __put_user_asm(stx,x,ptr) \
> __asm__ __volatile__ ( \
> "\n1:\t" stx "\t%2,0(%%sr3,%1)\n" \
>@@ -210,6 +230,23 @@
> "\t.previous" \
> : "=r"(__pu_err) \
> : "r"(ptr), "r"(x), "0"(__pu_err))
>+
>+#define __put_user_asm_64(x, ptr) \
>+ __asm__ __volatile__ ( \
>+ "\n\tldw\t0(%%sr3,%2),%3\n" \
>+ "1:\tstw\t%3,0(%%sr3,%1)\n" \
>+ "\tldw\t4(%%sr3,%2),%3\n" \
>+ "2:\tstw\t%3,4(%%sr3,%1)\n" \
>+ "3:\n" \
>+ "\t.section __ex_table,\"a\"\n" \
>+ "\t.word\t1b\n" \
>+ "\t.word\t(3b-1b)+1\n" \
>+ "\t.word\t2b\n" \
>+ "\t.word\t(3b-2b)+1\n" \
>+ "\t.previous" \
>+ : "=r"(__pu_err) \
>+ : "r"(ptr), "r"(&x), "r"(__tmp), "0"(__pu_err))
>+
> #endif
>
(&x) works when it is a variable not with a symbolic constant as 0.
Sorry,
Joel
From Stephan <stephan@itp.bg> Fri Sep 27 18:55:39 2002
From: Stephan <stephan@itp.bg> (Stephan)
Date: Fri, 27 Sep 2002 19:55:39 +0200
Subject: [parisc-linux] LASI ETHERNET
Message-ID: <20020927165415.163874829@dsl2.external.hp.com>
<P>eth0: link ok.<BR>eth0: i596 interrupt, exit timeout, status a040, cmd
a100.<BR>eth0: i596 interrupt, timeout, status e040, cmd a100.<BR>eth0: i596
interrupt, timeout, status e040, cmd a100.<BR>eth0: i596 interrupt, exit
timeout, status e040, cmd e100.<BR>eth0: i596 interrupt, exit timeout,
status 4040, cmd 4000.<BR>eth0: i596_add_cmd timed out, status 4040, cmd
4000.<BR>eth0: i596 interrupt, timeout, status 4040, cmd 0100.<BR>eth0: i596
interrupt, timeout, status 4040, cmd 0100.<BR>eth0: i596 interrupt, exit
timeout, status 4040, cmd 4000.<BR>eth0: command unit timed out, status
resetting.<BR>eth0: link ok.</P>
<P> </P>
<P> </P>
<P>Why is this error appeared?</P>
<P>Today when this error appeared, my LAN connection was broken</P>
<P>after ifdown and ifup</P>
<P>all is OK, I tried another UTP cable. I am using HP Switch 10/100</P>
<P> </P><br>
<br>
________________________________________________<br>
This mail was sent by Godzilla 1.0<br>
From willy@debian.org Fri Sep 27 17:59:16 2002
From: willy@debian.org (Matthew Wilcox)
Date: Fri, 27 Sep 2002 17:59:16 +0100
Subject: [parisc-linux] LASI ETHERNET
In-Reply-To: <20020927165415.163874829@dsl2.external.hp.com>; from stephan@itp.bg on Fri, Sep 27, 2002 at 07:55:39PM +0200
References: <20020927165415.163874829@dsl2.external.hp.com>
Message-ID: <20020927175916.E27592@parcelfarce.linux.theplanet.co.uk>
On Fri, Sep 27, 2002 at 07:55:39PM +0200, Stephan wrote:
... absolutely nothing.
want to try again, this time without the html?
--
Revolutions do not require corporate support.
From jonsharp@fastmail.ca Fri Sep 27 19:21:23 2002
From: jonsharp@fastmail.ca (Jon Sharp)
Date: Fri, 27 Sep 2002 14:21:23 -0400 (EDT)
Subject: [parisc-linux] Modem communication, HP 730
Message-ID: <3D94A1A3.000229.16058@ns.interchange.ca>
--------------Boundary-00=_NB04GPJWK2QPJEDD7TH0
Content-Type: Text/Plain
Content-Transfer-Encoding: 7bit
> I know the internal modem of the K-class is limited to 19200. All
> of the support modems we install for the systems are slowed down
> to 19200 even though they are 56k. Coincidence?
>
> derek
>
>
> --- Grant Grundler <grundler@dsl2.external.hp.com> wrote:
>> "Jon Sharp" wrote:
>>> It works fine (using minicom) at connection
>>> speeds of up to 19200, after that the modem fails to respond to
>>> AT commands altogether.
>>
>> Does anyone know at which speeds HW handshaking is necessary?
>> 730 is a pretty old machine.
>>
>> grant
Interestingly according to a guy in an hp newsgroup it is possible
under HP-UX, which has left me even more confused.
Thanks,
Jon
_________________________________________________________________
http://fastmail.ca/ - Fast Secure Web Email for Canadians
--------------Boundary-00=_NB04GPJWK2QPJEDD7TH0--
From Stephan <stephan@itp.bg> Fri Sep 27 22:33:06 2002
From: Stephan <stephan@itp.bg> (Stephan)
Date: Fri, 27 Sep 2002 23:33:06 +0200
Subject: [parisc-linux] LASI Ethernet problems!
Message-ID: <20020927203129.6B1FB4829@dsl2.external.hp.com>
eth0: link ok.
eth0: i596 interrupt, exit timeout, status a040, cmd a100.
eth0: i596 interrupt, timeout, status e040, cmd a100.
eth0: i596 interrupt, timeout, status e040, cmd a100.
eth0: i596 interrupt, exit timeout, status e040, cmd e100.
eth0: i596 interrupt, exit timeout, status 4040, cmd 4000.
eth0: i596_add_cmd timed out, status 4040, cmd 4000.
eth0: i596 interrupt, timeout, status 4040, cmd 0100.
eth0: i596 interrupt, timeout, status 4040, cmd 0100.
eth0: i596 interrupt, exit timeout, status 4040, cmd 4000.
eth0: command unit timed out, status resetting.
eth0: link ok.
Why is this error appeared?
Today when this error appeared, my LAN connection was broken
after ifdown and ifup
all is OK, I tried another UTP cable. I am using HP Switch 10/100
________________________________________________
This mail was sent by Godzilla 1.0
From grundler@dsl2.external.hp.com Sat Sep 28 06:42:07 2002
From: grundler@dsl2.external.hp.com (Grant Grundler)
Date: Fri, 27 Sep 2002 23:42:07 -0600
Subject: [parisc-linux] xfree86_4.2.1-0pre1v2 debs
Message-ID: <20020928054208.F3D604829@dsl2.external.hp.com>
untested, prebuilt pre1v2 debs here:
http://gsyprf11.external.hp.com/hppa/xfree86_4.2.1-0pre1v2/
these built with no extra patches. nice :^).
grant
From jhaydon@attbi.com Sat Sep 28 14:13:39 2002
From: jhaydon@attbi.com (James Haydon)
Date: Sat, 28 Sep 2002 09:13:39 -0400
Subject: [parisc-linux] xwindows
Message-ID: <3D95AB03.9030706@attbi.com>
I got a 9000/715 100 that I have Debian 3.0 everything works except for
X. What do I have to do to make X work?
James
From joel.soete@freebel.net Sat Sep 28 16:49:11 2002
From: joel.soete@freebel.net (Joel Soete)
Date: Sat, 28 Sep 2002 15:49:11 +0000
Subject: [parisc-linux] xwindows
References: <3D95AB03.9030706@attbi.com>
Message-ID: <3D95CF77.3080508@freebel.net>
Hi James,
Just start to have a look at ml:
http://lists.parisc-linux.org/pipermail/parisc-linux/2002-September/017688.html
You could also have a look earlier in this ml, there are other advises
concerning X and 715 (HIL mouse?).
Good luck,
Joel
James Haydon wrote:
> I got a 9000/715 100 that I have Debian 3.0 everything works except for
> X. What do I have to do to make X work?
>
> James
>
>
>
>
> _______________________________________________
> parisc-linux mailing list
> parisc-linux@lists.parisc-linux.org
> http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
>
From joel.soete@freebel.net Sat Sep 28 18:41:11 2002
From: joel.soete@freebel.net (Joel Soete)
Date: Sat, 28 Sep 2002 17:41:11 +0000
Subject: [parisc-linux] How to obtain a core dump
Message-ID: <3D95E9B7.2080209@freebel.net>
Hi all,
Testing evms 1.1.0, I got a segfault with evmsgui on hppa but I do not
obtain any core dump to analyse by back trace in gdb the origine of this
problem (the ncurses tool do present this default).
Is someonr can explain me what should I do to obtain a core dump when
this kind of problem occurs?
Thanks in advance,
Joel
From dave@hiauly1.hia.nrc.ca Sat Sep 28 18:02:23 2002
From: dave@hiauly1.hia.nrc.ca (John David Anglin)
Date: Sat, 28 Sep 2002 13:02:23 -0400 (EDT)
Subject: [parisc-linux] How to obtain a core dump
In-Reply-To: <3D95E9B7.2080209@freebel.net> from "Joel Soete" at Sep 28, 2002 05:41:11 pm
Message-ID: <200209281702.g8SH2ND4019187@hiauly1.hia.nrc.ca>
> Is someonr can explain me what should I do to obtain a core dump when
> this kind of problem occurs?
Type "ulimit -a" to see your current limit settings. The core size
limit can be changed with "ulimit -c". Your current core size limit
is probably too small.
Dave
--
J. David Anglin dave.anglin@nrc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6605)
From Randolph Chung <randolph@tausq.org> Sat Sep 28 18:59:51 2002
From: Randolph Chung <randolph@tausq.org> (Randolph Chung)
Date: Sat, 28 Sep 2002 10:59:51 -0700
Subject: [parisc-linux] FWD: Bug#162690: [parisc]gcc 3.x produces openssl test code that SEGVs with -march=2.0 and optimization >0
Message-ID: <20020928175951.GB6868@tausq.org>
perhaps someone here can look at this?
randolph
----- Forwarded message from Kevin Carson <kevincarson@shaw.ca> -----
Subject: Bug#162690: [parisc]gcc 3.x produces openssl test code that SEGVs with -march=2.0 and optimization >0
Reply-To: Kevin Carson <kevincarson@shaw.ca>, 162690@bugs.debian.org
Date: Sat, 28 Sep 2002 10:21:01 -0700
From: Kevin Carson <kevincarson@shaw.ca>
To: submit@bugs.debian.org
X-Mailing-List: <debian-gcc@lists.debian.org> archive/latest/3552
Package: gcc
Running Debian unstable on PA-RISC platform (C160 Workstation with 160MHz
PA-8000 CPU)
Compiling openssl 0.9.6g with any level of optimization for PA1.1 produces
code that passes all tests ("make test") and benchmarks ("openssl speed")
successfully. Using -march=2.0 flag produces code that only runs
successfully at optimization level "-O0" Any higher optimization fails some
of the test suite (reliably in test/exptest.c for instance).
I've observed this problem with gcc 3.0.4-8 and gcc-3.2.1-0pre2
libc6 2.2.5-14.3
"linux-parisc" configuration string in openssl Configure script for
successful run is
"gcc-3.2:-DB_ENDIAN -DNO_ASM -DTERMIO -O0 -march=2.0 -Wall::::::"
"linux-parisc" configuration string in openssl Configure script for failed
run is "gcc-3.2:-DB_ENDIAN -DNO_ASM -DTERMIO -O1 -march=2.0 -Wall::::::"
Run test by:
cd openssl-0.9.6g
<edit Configure to contain string above in single line>
make clean
./Configure linux-parisc
make test
if optimization is >0 run will fail with segmentation violation in exptest
(tests various operations on the big number library)
Kevin
--
To UNSUBSCRIBE, email to debian-gcc-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
----- End forwarded message -----
From joel.soete@freebel.net Sat Sep 28 22:20:14 2002
From: joel.soete@freebel.net (Joel Soete)
Date: Sat, 28 Sep 2002 21:20:14 +0000
Subject: [parisc-linux] uaccess.h patch for new evms-1.1.0: correct?
References: <3D8F01140000102A@ocpmta2.be.tiscali.com>
Message-ID: <3D961D0E.4060806@freebel.net>
Hi all,
Is somebody have some sample test program to stress this patch (so that
I can consumme all available vm) to verify that it reports well the
erronious memory access?
Thanks in advance,
Joel
jsoe0708@tiscali.be wrote:
> Hi all,
>
> As I not find "std" emulation (gcc report 'Internal compiler error... PLease
> submit a full bug report...) and not more the D, M, L mips prefix (to access
> different 32bits part of a 64bits lon long), here is what I proprose as uaccess.h
> patch.
>
> Can someone have a look and advise me if I made any error?
>
> Thanks in advance for help,
> Joel
>
> PS: Functionaly it seems to work to make evms 1.1.0 works
>
>
From dave@hiauly1.hia.nrc.ca Sat Sep 28 23:32:57 2002
From: dave@hiauly1.hia.nrc.ca (John David Anglin)
Date: Sat, 28 Sep 2002 18:32:57 -0400 (EDT)
Subject: [parisc-linux] FWD: Bug#162690: [parisc]gcc 3.x produces openssl test code that SEGVs with -march=2.0 and optimization >0
In-Reply-To: <20020928175951.GB6868@tausq.org> from "Randolph Chung" at Sep 28, 2002 10:59:51 am
Message-ID: <200209282232.g8SMWwCB022391@hiauly1.hia.nrc.ca>
> Package: gcc
>
> Running Debian unstable on PA-RISC platform (C160 Workstation with 160MHz
> PA-8000 CPU)
>
> Compiling openssl 0.9.6g with any level of optimization for PA1.1 produces
> code that passes all tests ("make test") and benchmarks ("openssl speed")
> successfully. Using -march=2.0 flag produces code that only runs
> successfully at optimization level "-O0" Any higher optimization fails some
> of the test suite (reliably in test/exptest.c for instance).
There is a known issue with the assembler and linker with PA-RISC 2.0 code.
The relocations generated for floating-point loads and stores are wrong
in some cases. Until this problem is fixed, I don't recommend using
-march=2.0. This is part of the reason the default architecture is
still PA-RISC 1.1. I don't think you can build gcc with -march=2.0
either. There isn't a huge benefit in PA-RISC 2.0 in 32-bit mode.
I believe that this is not a problem with the 64-bit assembler and
linker. However, there isn't a 64-bit userspace yet :(
If you think that you can contribute to resolving these issues, then
I encourage you to investigate further and determine what causes
the seg faults.
Dave
--
J. David Anglin dave.anglin@nrc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6605)
From grundler@dsl2.external.hp.com Sun Sep 29 06:51:05 2002
From: grundler@dsl2.external.hp.com (Grant Grundler)
Date: Sat, 28 Sep 2002 23:51:05 -0600
Subject: [parisc-linux] EISA 100 Base-T Ethernet card drivers / 3COM
In-Reply-To: Message from Harri Haataja <harri.haataja@cs.helsinki.fi>
of "Fri, 27 Sep 2002 11:42:27 +0300." <20020927114226.A1112@azrael.smilehouse.com>
References: <49AA3A3C863E5B4C911320AEF99E5DA3010CCCE0@wing-ep.tip.csiro.au> <20020926031956.A5179@parcelfarce.linux.theplanet.co.uk> <3D935BCC.4060002@gmx.de> <20020926201238.G28188@parcelfarce.linux.theplanet.co.uk> <20020927114226.A1112@azrael.smilehouse.com>
Message-ID: <20020929055105.496884829@dsl2.external.hp.com>
Harri Haataja wrote:
> Wouldn't it be worth it putting together a small list (or even an active
> web page) of working devices of any kind on HP-PA hardware?
> Or maybe just limited to (E)ISA and pci cards or such?
ESIEE folks maintain a page for systems:
http://pateam.esiee.fr/list.html
Please model after that example and send it to them.
They might add it to that page. I don't know if they want to maintain
something like that and I think they have enough to do already.
A problem with maintaining this is even if a PCI card works on B180
doesn't mean it will work on C3000 or A500.
In general, I expect hppa-linux to support the same cards as sparc64/
mips64/powerpc/alpha ports. I would include "ia64" but itanic IO and
HP ZX1 IO are like comparing x86 IO and parisc IO subsystems (HW).
grant
From Stephan <stephan@itp.bg> Sun Sep 29 20:09:24 2002
From: Stephan <stephan@itp.bg> (Stephan)
Date: Sun, 29 Sep 2002 21:09:24 +0200
Subject: [parisc-linux] Serial MUX
Message-ID: <20020929180739.27FFE4829@dsl2.external.hp.com>
Hello,
i just compiled kernel with serial mux support
how I can use it?
how to create ttyB*?
REgards
________________________________________________
This mail was sent by Godzilla 1.0
From christoph.plattner@gmx.at Sun Sep 29 19:28:39 2002
From: christoph.plattner@gmx.at (Christoph Plattner)
Date: Sun, 29 Sep 2002 20:28:39 +0200
Subject: [parisc-linux] Serial MUX
References: <20020929180739.27FFE4829@dsl2.external.hp.com>
Message-ID: <3D974657.F355C89A@gmx.at>
Hello,
this driver is under development !
This driver can be used on machines having a non-supported
multi-serial interface like a E35/45/55 or some K-series
machines.
The first and already tested driver is the PDC console
driver, to use only port-0 of the multi serial board
as console. Now an alternative native MUX driver
is under development, but this driver can currently
ONLY access port-0 (first port). The multi-line support
is not coded yet, and some short tests by me show
problems (machine hangs up !).
So you cannot access the multiple serial ports, so sorry.
Christoph P.
Stephan wrote:
>
> Hello,
> i just compiled kernel with serial mux support
> how I can use it?
> how to create ttyB*?
> REgards
>
> ________________________________________________
> This mail was sent by Godzilla 1.0
>
> _______________________________________________
> parisc-linux mailing list
> parisc-linux@lists.parisc-linux.org
> http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
--
-------------------------------------------------------
private: christoph.plattner@gmx.at
company: christoph.plattner@alcatel.at
From jhaydon@attbi.com Sun Sep 29 20:42:50 2002
From: jhaydon@attbi.com (James Haydon)
Date: 29 Sep 2002 15:42:50 -0400
Subject: [parisc-linux] xwindows
In-Reply-To: <3D95CF77.3080508@freebel.net>
References: <3D95AB03.9030706@attbi.com> <3D95CF77.3080508@freebel.net>
Message-ID: <1033328572.1295.7.camel@daedalus>
Joel,
It turns some bad settings put in the XF86Config-4 by me dealing number
of colors and vertical and horizonal sync and some stuff dealing with
probing a monitor put in by Debian.
The correct number of colors is 8 for this 715.
Thanks
James
On Sat, 2002-09-28 at 11:49, Joel Soete wrote:
> Hi James,
>
> Just start to have a look at ml:
>
> http://lists.parisc-linux.org/pipermail/parisc-linux/2002-September/017688.html
>
> You could also have a look earlier in this ml, there are other advises
> concerning X and 715 (HIL mouse?).
>
> Good luck,
> Joel
>
>
> James Haydon wrote:
> > I got a 9000/715 100 that I have Debian 3.0 everything works except for
> > X. What do I have to do to make X work?
> >
> > James
> >
> >
> >
> >
> > _______________________________________________
> > parisc-linux mailing list
> > parisc-linux@lists.parisc-linux.org
> > http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
> >
>
>
From sarah_benson@nomoreaccent.com Sun Sep 29 21:51:55 2002
From: sarah_benson@nomoreaccent.com (Sarah Benson)
Date: Sun, 29 Sep 2002 15:51:55 -0500
Subject: [parisc-linux] Q: DOES YOUR FOREIGN ACCENT SIMPLY GET IN THE WAY?
Message-ID: <20020929205209.7DB834829@dsl2.external.hp.com>
This is a multi-part message in MIME format
--050958ff-7610-4a3c-930b-b7e7e10551ba
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Q: " Would you like to Lose Your Accent ? "
- DO YOU FIND OTHERS HAVE A HARD TIME UNDERSTANDING WHAT YOU ARE TRYING TO =
CONVEY?
- DO YOU FIND THE NEED TO REPEAT YOURSELF FOR OTHERS TO UNDERSTAND YOU =
CLEARLY?
- DO YOU FEEL EMBARRASSED OR LESS CONFIDENT WHEN TALKING TO WORK COLLEAGUES?
- DO YOU WISH TO COMMUNICATE YOUR THOUGHTS MORE EFFECTIVELY?
- DOES YOUR FOREIGN ACCENT SIMPLY GET IN THE WAY?
Introducing the Krieger Method, an innovative teaching system, designed to =
help you develop effective communication skills.
Andy Krieger, inventor of this miracle product, originated this revolutionary =
idea whilst working with actors and their accents within the Hollywood film =
industry.
Contact us to learn about the true benefits you can obtain to communicate =
with confidence!!
"Make your accent simply disappear!"
For Accent Reduction Empowerment, visit us on the web today at :-
www.nomoreaccent.com
Thank you for your time and interest...
Sarah J. Benson
Marketing Co-ordinator
If you feel this is email is not of interest to you, then we sincerely =
apologize and guarantee you will not receive another email from us, unless =
you otherwise wish.
--050958ff-7610-4a3c-930b-b7e7e10551ba--
From Frank.Cornelis@rug.ac.be Sun Sep 29 22:17:22 2002
From: Frank.Cornelis@rug.ac.be (Frank Cornelis)
Date: Sun, 29 Sep 2002 23:17:22 +0200 (MEST)
Subject: [parisc-linux] firmware update using BOOTP
Message-ID: <Pine.GSO.4.31.0209292306350.1357-100000@eduserv.rug.ac.be>
Hi,
The FAQ
7. How can I check if the PDC (firmware) revision is the latest ?
at
http://www.parisc-linux.org/faq/index.html
says nothing about updating the firmware using BOOTP.
I think it should be put there since it works great and is very easy to
do. I just upgraded a 712 from 2.1 to 2.3 using BOOTP.
The text file included with the firmware patch only talks about using a
tape for updating...uch. Please can someone update that FAQ nr. 7?
Yes, I'm a newbie on PA-RISC, but it should not take _me_ that long... I
have to find everything myself...
OK, lifimage already boots, next is my root NFS ... terrible... :)
Frank.
From willy@debian.org Sun Sep 29 23:54:36 2002
From: willy@debian.org (Matthew Wilcox)
Date: Sun, 29 Sep 2002 23:54:36 +0100
Subject: [parisc-linux] firmware update using BOOTP
In-Reply-To: <Pine.GSO.4.31.0209292306350.1357-100000@eduserv.rug.ac.be>; from Frank.Cornelis@rug.ac.be on Sun, Sep 29, 2002 at 11:17:22PM +0200
References: <Pine.GSO.4.31.0209292306350.1357-100000@eduserv.rug.ac.be>
Message-ID: <20020929235436.I18377@parcelfarce.linux.theplanet.co.uk>
On Sun, Sep 29, 2002 at 11:17:22PM +0200, Frank Cornelis wrote:
> The FAQ
> 7. How can I check if the PDC (firmware) revision is the latest ?
> at
> http://www.parisc-linux.org/faq/index.html
> says nothing about updating the firmware using BOOTP.
> I think it should be put there since it works great and is very easy to
> do. I just upgraded a 712 from 2.1 to 2.3 using BOOTP.
want to post a patch?
--
Revolutions do not require corporate support.
From jem486749@yahoo.com Mon Sep 30 08:48:17 2002
From: jem486749@yahoo.com (jem486749@yahoo.com)
Date: 30 Sep 2002 07:48:17 -0000
Subject: [parisc-linux] Want a Big Penis?
Message-ID: <20020930074817.96646.qmail@mailman.xlresponder.com>
Click on the link below to remove yourself
http://www.xlresponder.com/cgi-bin/varpro/r.cgi?id=dreammaker5&a=parisc-linux@parisc-linux.org
AOL Users
<a href="http://www.xlresponder.com/cgi-bin/varpro/r.cgi?id=dreammaker5&a=parisc-linux@parisc-linux.org"> Remove Me</a>
From cpischel@catastro.rionegro.gov.ar Mon Sep 30 13:28:44 2002
From: cpischel@catastro.rionegro.gov.ar (=?iso-8859-1?Q?Claudio_Pischel_=28Direcci=F3n_General_de_Catastro_-_RN?= =?iso-8859-1?Q?=29?=)
Date: Mon, 30 Sep 2002 09:28:44 -0300
Subject: [parisc-linux] Client Oracle 8.1.6 for Debian pa-risc
References: <005801c24ef5$bcd5d6c0$95ff8450@PLUTO> <1030582666.2179.360.camel@archimedes.localnetsolutions.com> <3D6D7527.5040505@charter.net>
Message-ID: <004501c2687c$eacc82e0$32180b0a@catastro.gov.ar>
I need the client Oracle 8.1.6 for Debian pa-risc.
Claudio Pischel
Subgerente de Informatica
cpischel@catastro.rionegro.gov.ar
Dirección General de Catastro
e Información Territorial
RIO NEGRO
From Ralf.Hildebrandt@charite.de Mon Sep 30 13:33:52 2002
From: Ralf.Hildebrandt@charite.de (Ralf Hildebrandt)
Date: Mon, 30 Sep 2002 14:33:52 +0200
Subject: [parisc-linux] Client Oracle 8.1.6 for Debian pa-risc
In-Reply-To: <004501c2687c$eacc82e0$32180b0a@catastro.gov.ar>
References: <005801c24ef5$bcd5d6c0$95ff8450@PLUTO> <1030582666.2179.360.camel@archimedes.localnetsolutions.com> <3D6D7527.5040505@charter.net> <004501c2687c$eacc82e0$32180b0a@catastro.gov.ar>
Message-ID: <20020930123352.GM5427@charite.de>
On Mon, Sep 30, 2002 at 09:28:44AM -0300, Claudio Pischel (Direcci?n General de Catastro - RN) wrote:
> I need the client Oracle 8.1.6 for Debian pa-risc.
Try asking Oracle for it.
--
Ralf Hildebrandt (Im Auftrag des Referat V A) Ralf.Hildebrandt@charite.de
Charite Campus Virchow-Klinikum Tel. +49 (0)30-450 570-155
Referat V A - Kommunikationsnetze - Fax. +49 (0)30-450 570-916
Why you can't find your system administrators:
Getting Jolt out of their under-floor cache
From varenet@esiee.fr Mon Sep 30 13:54:10 2002
From: varenet@esiee.fr (Thibaut VARENE)
Date: Mon, 30 Sep 2002 14:54:10 +0200
Subject: [parisc-linux] Want a Big Penis?
References: <20020930074817.96646.qmail@mailman.xlresponder.com>
Message-ID: <3D984972.3030801@esiee.fr>
Well dudes, it's not the size of the boat that matters, it's the motion
in the ocean ! ;o))
More seriously, isn't it possible to avoid such spam ?
It's becomming more and more regular...
--
Thibaut VARENE
PA/Linux ESIEE Team
http://pateam.esiee.fr/
From nneul@umr.edu Mon Sep 30 14:05:35 2002
From: nneul@umr.edu (Neulinger, Nathan)
Date: Mon, 30 Sep 2002 08:05:35 -0500
Subject: [parisc-linux] Want a Big Penis?
Message-ID: <2B45A04D8F18D947A400F0850CE3B53B060D2D@umr-mail7.umr.edu>
SpamAssassin w/ DCC + Razor is easy to set up and does a pretty good job
getting rid of most of the spam I get on a daily basis.=20
-- Nathan
------------------------------------------------------------
Nathan Neulinger EMail: nneul@umr.edu
University of Missouri - Rolla Phone: (573) 341-4841
Computing Services Fax: (573) 341-4216
> -----Original Message-----
> From: Thibaut VARENE [mailto:varenet@esiee.fr]=20
> Sent: Monday, September 30, 2002 7:54 AM
> To: parisc-linux@parisc-linux.org
> Subject: Re: [parisc-linux] Want a Big Penis?
>=20
>=20
>=20
> Well dudes, it's not the size of the boat that matters, it's=20
> the motion=20
> in the ocean ! ;o))
>=20
>=20
> More seriously, isn't it possible to avoid such spam ?
> It's becomming more and more regular...
>=20
>=20
> --=20
> Thibaut VARENE
> PA/Linux ESIEE Team
> http://pateam.esiee.fr/
>=20
>=20
> _______________________________________________
> parisc-linux mailing list
> parisc-linux@lists.parisc-linux.org
> http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
>=20
From james@compusmithllc.com Mon Sep 30 15:10:22 2002
From: james@compusmithllc.com (James Smith)
Date: 30 Sep 2002 09:10:22 -0500
Subject: [parisc-linux] firmware update using BOOTP
In-Reply-To: <Pine.GSO.4.31.0209292306350.1357-100000@eduserv.rug.ac.be>
References: <Pine.GSO.4.31.0209292306350.1357-100000@eduserv.rug.ac.be>
Message-ID: <1033395024.454.3.camel@seventy>
most of my 712's are ver 1.9 or 2.1 & they all work fine as far as i can
see with linux - is there any advantage to updating to 2.3 ?
or is this a case of 'if its not broken....'
James S
> The FAQ
> 7. How can I check if the PDC (firmware) revision is the latest ?
> at
> http://www.parisc-linux.org/faq/index.html
> says nothing about updating the firmware using BOOTP.
> I think it should be put there since it works great and is very easy to
> do. I just upgraded a 712 from 2.1 to 2.3 using BOOTP.
From c.beerse@torex-hiscom.nl Mon Sep 30 16:03:09 2002
From: c.beerse@torex-hiscom.nl (=?iso-8859-1?Q?=22Beerse=2C_Corn=E9=22?=)
Date: Mon, 30 Sep 2002 17:03:09 +0200
Subject: [parisc-linux] Serial MUX
Message-ID: <02Sep30.171511cest.119078@ns.hiscom.nl>
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_01C26892.7D7308C0
Content-Type: text/plain;
charset="iso-8859-1"
> -----Original Message-----
> From: Christoph Plattner [mailto:christoph.plattner@gmx.at]
>
> this driver is under development !
> This driver can be used on machines having a non-supported
> multi-serial interface like a E35/45/55 or some K-series
> machines.
Does this indicate someone is trying to make linux on a E45 usefull? I've
one next to my desk (terrible noise from the disks or fan).
Unfortunately I cannot help developping, but I can do some testing.
>
> The first and already tested driver is the PDC console
> driver, to use only port-0 of the multi serial board
> as console. Now an alternative native MUX driver
> is under development, but this driver can currently
> ONLY access port-0 (first port). The multi-line support
> is not coded yet, and some short tests by me show
> problems (machine hangs up !).
>
> So you cannot access the multiple serial ports, so sorry.
>
I only need it for console.
CBee
------_=_NextPart_001_01C26892.7D7308C0
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.45">
<TITLE>RE: [parisc-linux] Serial MUX</TITLE>
</HEAD>
<BODY>
<P><FONT SIZE=3D2>> -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>> From: Christoph Plattner [<A =
HREF=3D"mailto:christoph.plattner@gmx.at">mailto:christoph.plattner@gmx.=
at</A>]</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> this driver is under development !</FONT>
<BR><FONT SIZE=3D2>> This driver can be used on machines having a =
non-supported</FONT>
<BR><FONT SIZE=3D2>> multi-serial interface like a E35/45/55 or some =
K-series</FONT>
<BR><FONT SIZE=3D2>> machines. </FONT>
</P>
<P><FONT SIZE=3D2>Does this indicate someone is trying to make linux on =
a E45 usefull? I've one next to my desk (terrible noise from the disks =
or fan).</FONT></P>
<P><FONT SIZE=3D2>Unfortunately I cannot help developping, but I can do =
some testing.</FONT>
</P>
<P><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> The first and already tested driver is the PDC =
console</FONT>
<BR><FONT SIZE=3D2>> driver, to use only port-0 of the multi serial =
board</FONT>
<BR><FONT SIZE=3D2>> as console. Now an alternative native MUX =
driver </FONT>
<BR><FONT SIZE=3D2>> is under development, but this driver can =
currently </FONT>
<BR><FONT SIZE=3D2>> ONLY access port-0 (first port). The multi-line =
support</FONT>
<BR><FONT SIZE=3D2>> is not coded yet, and some short tests by me =
show</FONT>
<BR><FONT SIZE=3D2>> problems (machine hangs up !).</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> So you cannot access the multiple serial ports, =
so sorry.</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>I only need it for console.</FONT>
</P>
<BR>
<P><FONT SIZE=3D2>CBee</FONT>
</P>
</BODY>
</HTML>
------_=_NextPart_001_01C26892.7D7308C0--
From willy@debian.org Mon Sep 30 16:25:36 2002
From: willy@debian.org (Matthew Wilcox)
Date: Mon, 30 Sep 2002 16:25:36 +0100
Subject: [parisc-linux] Serial MUX
In-Reply-To: <02Sep30.171511cest.119078@ns.hiscom.nl>; from c.beerse@torex-hiscom.nl on Mon, Sep 30, 2002 at 05:03:09PM +0200
References: <02Sep30.171511cest.119078@ns.hiscom.nl>
Message-ID: <20020930162536.L18377@parcelfarce.linux.theplanet.co.uk>
From: Christoph Plattner [mailto:christoph.plattner@gmx.at]
> This driver can be used on machines having a non-supported
> multi-serial interface like a E35/45/55 or some K-series
> machines.
slight misunderstanding: this driver supports almost all the
non-16550-compatible serial ports used on HP machines. That includes E,
F-I, K-class and the optional console card used with some D & R class
machines. It doesn't include "Burgundy", "Silverfox" or "Lego" console
devices. I'm working on updating the hwdb to reflect this.
--
Revolutions do not require corporate support.
From christoph.plattner@gmx.at Mon Sep 30 19:31:41 2002
From: christoph.plattner@gmx.at (Christoph Plattner)
Date: Mon, 30 Sep 2002 20:31:41 +0200
Subject: [parisc-linux] Serial MUX
References: <02Sep30.171511cest.119078@ns.hiscom.nl>
Message-ID: <3D98988D.A0B86B5F@gmx.at>
Hello,
yes, I want to have E55 (and familiy) supported fully,
and I try to help in development (so far it is possible,
it is hard to get access to HP documentation).
To use the E55 (or family) as a diskless server, it works
(so you can reduce noise at the meantime, the disks cannot
be accessed in Linux - yet !).
For such a diskless operation, you need
- serial console
- ethernet
- core system
All three things are running under Linux.
Again, you can use the PDC CONSOLE driver OR the MUX driver.
Both are accessed via ttyB0 at the moment.
Christoph
> "Beerse, Corné" wrote:
>
> > -----Original Message-----
> > From: Christoph Plattner [mailto:christoph.plattner@gmx.at]
> >
> > this driver is under development !
> > This driver can be used on machines having a non-supported
> > multi-serial interface like a E35/45/55 or some K-series
> > machines.
>
> Does this indicate someone is trying to make linux on a E45 usefull?
> I've one next to my desk (terrible noise from the disks or fan).
>
> Unfortunately I cannot help developping, but I can do some testing.
>
> >
> > The first and already tested driver is the PDC console
> > driver, to use only port-0 of the multi serial board
> > as console. Now an alternative native MUX driver
> > is under development, but this driver can currently
> > ONLY access port-0 (first port). The multi-line support
> > is not coded yet, and some short tests by me show
> > problems (machine hangs up !).
> >
> > So you cannot access the multiple serial ports, so sorry.
> >
> I only need it for console.
>
> CBee
--
-------------------------------------------------------
private: christoph.plattner@gmx.at
company: christoph.plattner@alcatel.at
From christoph.plattner@gmx.at Mon Sep 30 19:33:54 2002
From: christoph.plattner@gmx.at (Christoph Plattner)
Date: Mon, 30 Sep 2002 20:33:54 +0200
Subject: [parisc-linux] Serial MUX
References: <02Sep30.171511cest.119078@ns.hiscom.nl> <20020930162536.L18377@parcelfarce.linux.theplanet.co.uk>
Message-ID: <3D989912.9310A140@gmx.at>
Oh sorry, that's beautiful, that there are so much
machines with the same device type. My knowledge was
here not complete. I only knew the state of the E55
(family) and of this one K-class machine, Ryan has.
Christoph
Matthew Wilcox wrote:
>
> From: Christoph Plattner [mailto:christoph.plattner@gmx.at]
> > This driver can be used on machines having a non-supported
> > multi-serial interface like a E35/45/55 or some K-series
> > machines.
>
> slight misunderstanding: this driver supports almost all the
> non-16550-compatible serial ports used on HP machines. That includes E,
> F-I, K-class and the optional console card used with some D & R class
> machines. It doesn't include "Burgundy", "Silverfox" or "Lego" console
> devices. I'm working on updating the hwdb to reflect this.
>
> --
> Revolutions do not require corporate support.
> _______________________________________________
> parisc-linux mailing list
> parisc-linux@lists.parisc-linux.org
> http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
--
-------------------------------------------------------
private: christoph.plattner@gmx.at
company: christoph.plattner@alcatel.at
From stain@itea.ntnu.no Mon Sep 30 21:08:05 2002
From: stain@itea.ntnu.no (Stian Soiland)
Date: Mon, 30 Sep 2002 22:08:05 +0200
Subject: [parisc-linux] 9000/802/K250 won't boot with images - serial/stack problem?
Message-ID: <20020930200805.GA9133@itea.ntnu.no>
I've got this K250, this is the one:
http://hwdb.parisc-linux.org/view.php3?type=3Dmachine&name=3DK250=20
And trying to boot it with several of the premade images:
debian_3.0r0_hppa.iso
palinux-2.4.19-pa6-PDC-20020826-netinst.iso
palinux-2.4.19-pa19-20020922-netinst.iso
I only have a serial interface with a HP terminal, as far as I can tell
there is no way to connect a seperate monitor, although there are PS2
inputs for mouse and keyboard.
The serial console is connected to 'CONSOLE (X/4/0/0)*',=20
not the 'MDP'-port (as far as I can tell that is for an=20
external MUX?). It works fine from HPUX 10.20.
I've connected it to a terminal server for this session, though.
When trying to boot the CD I came pretty much further then
with earlier attempts (see previous postings by Rune Skillingstad,
appearing if you search on 'K250 linux' in Google).
However, first the trace of 0/vmlinuz32 from the newest netinst-image:
(there might be some lines missing as I needed to do some=20
cut-and-paste-tricks from my terminal server =3D)=20
Command line for kernel: 'ramdisk_size=3D8192 root=3D/dev/ram console=3Dtty=
S0
TERM=3Dvt102 palo_kernel=3D0/vmlinux32'
Selected kernel: /vmlinux32 from partition 0
Selected ramdisk: /ramdisk from partition 0
ELF32 executable
Entry 00100098 first 00100000 n 6
Segment 0 load 00100000 size 2196688 mediaptr 0x1000
Segment 1 load 0031a000 size 467792 mediaptr 0x21a000
Segment 2 load 00390000 size 255656 mediaptr 0x28d000
Segment 3 load 003d0000 size 8192 mediaptr 0x2cc000
Segment 4 load 003d8000 size 32768 mediaptr 0x2ce000
Segment 5 load 00402048 size 110832 mediaptr 0x2d6048
=20
Loading ramdisk 2662244 bytes @ 1fd63000...
Branching to kernel entry point 0x00100098. If this is the last
message you see, you may need to switch your console. This is
a common symptom -- search the FAQ and mailing list at parisc-linux.org
=20
Linux version 2.4.19-32 (root@mkhppa3) (gcc version 3.0.4) #1 Sun Sep 22
15:49:25 CEST 2002
FP[0] enabled: Rev 0 Model 14
The 32-bit Kernel has started...
Determining PDC firmware type: System Map.
model 00005a40 00000491 00000000 00000002 575b550e 100000f0 00000008 000000=
b2 000000b2 vers 00000205
CPUID vers 14 rev 9 (0x000001c9)
capabilities 0x3
model 9000/802/K250
Total Memory: 511 Mb
initrd: 2fd63000-2ffecf64
initrd: reserving 1fd63000-1ffecf64 (mem_max 1fffe000)
pagetable_init
On node 0 totalpages: 131070
zone(0): 131070 pages.
zone(1): 0 pages.
zone(2): 0 pages.
Kernel command line: ramdisk_size=3D8192 root=3D/dev/ram console=3DttyS0
TERM=3Dvt102 palo_kernel=3D0/vmlinux32
Console: colour dummy device 160x64
Calibrating delay loop... 319.48 BogoMIPS
Memory: 512220k available
Dentry cache hash table entries: 65536 (order: 7, 524288 bytes)
Inode cache hash table entries: 32768 (order: 6, 262144 bytes)
Mount-cache hash table entries: 8192 (order: 4, 65536 bytes)
Buffer-cache hash table entries: 32768 (order: 5, 131072 bytes)
Page-cache hash table entries: 131072 (order: 7, 524288 bytes)
Searching for devices...
Found devices:
1. U2-IOA BC Runway Port (12) at 0xfff88000 [8], versions 0x580, 0xf, 0xb
2. U2-IOA BC GSC+ Port (7) at 0xf103f000 [8/63], versions 0x501, 0x1, 0xc
3. U2-IOA BC Runway Port (12) at 0xfff8a000 [10], versions 0x580, 0xf, 0xb
4. Mohawk Core FW-SCSI (4) at 0xf1800000 [10/0], versions 0x44, 0x0, 0x89
5. Gecko BOA BC GSC+ Port (7) at 0xf1804000 [10/4], versions 0x500, 0x0, 0xc
6. Sahp Baat Kiuh AP/MUX (5) at 0xf1900000 [10/4/0], versions 0x44, 0x0, 0xd
7. Interphase NIO-100BaseTX (4) at 0xf1908000 [10/4/8], versions 0x4, 0x0, =
0x382
8. Skunk SCSI (28655A) (4) at 0xf1910000 [10/4/16], versions 0x4, 0x0, 0x39
9. Skunk Centronics (28655A) (5) at 0xf1911000 [10/4/17], versions 0x4, 0x0=
, 0x3a
10. Gecko BOA BC HP-PB Port (7) at 0xf193c000 [10/4/60], versions 0x103, 0x=
0, 0xc
11. Mohawk Core BA (11) at 0xffd00000 [10/12], versions 0x44, 0x0, 0x81,
additional addresses: 0xffd0c000 0xffc00000
12. Mohawk Core Centronics (10) at 0xffd02000 [10/12/0], versions 0x44, 0x0,
0x74, additional addresses: 0xffd01000 0xffd03000
13. Mohawk Core SCSI (10) at 0xffd06000 [10/12/5], versions 0x44, 0x0, 0x82
14. Mohawk Core LAN (802.3) (10) at 0xffd07000 [10/12/6], versions 0x44, 0x=
0,
0x8a
15. Mohawk Core PS/2 Port (10) at 0xffd08000 [10/12/7], versions 0x44, 0x0,=
0x84
16. Mohawk Core PS/2 Port (10) at 0xffd08100 [10/12/8], versions 0x44, 0x0,=
0x84
17. U2-IOA BC GSC+ Port (7) at 0xf183f000 [10/63], versions 0x501, 0x1, 0xc
18. Mohawk 160 U 1M DC3- (K250) (0) at 0xfffa0000 [32], versions 0x5a4, 0x0=
, 0x4
19. Memory (1) at 0xfffb1000 [49], versions 0x53, 0x0, 0x9
CPU(s): 1 x PA8000 (PCX-U) at 160.000000 MHz
Found U2 at 0xfff88000
Found U2 at 0xfff8a000
Lasi version 0 at 0xffd00000 found.
LED display at ffd0c000 registered
POSIX conformance testing by UNIFIX
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Initializing RT netlink socket
Soft power switch support not available.
Starting kswapd
Journalled Block Device driver loaded
Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
parport_init_chip: initialize bidirectional-mode.
parport0: PC-style at 0xffd02800, irq 88 [PCSPP,TRISTATE]
STI GSC/PCI graphics driver version 0.9
pty: 256 Unix98 ptys configured
Serial driver version 5.05c (2001-07-08) with MANY_PORTS SHARE_IRQ
SERIAL_PCI enabled
WARNING! Stack pointer and cr30 do not correspond!
Dumping virtual address stack instead
Dumping Stack from 0x3fff8000 to 0x3fff8740:
WARNING! Stack pointer and cr30 do not correspond!
Dumping virtual address stack instead
Dumping Stack from 0x3fff8000 to 0x3fff8b80:
WARNING! Stack pointer and cr30 do not correspond!
Dumping virtual address stack instead
(.. - and so on - I just print the 'Dumping stack' lines from now)
Dumping Stack from 0x3fff8000 to 0x3fff8fc0:
Dumping Stack from 0x3fff8000 to 0x3fff9400:
Dumping Stack from 0x3fff8000 to 0x3fff9840:
Dumping Stack from 0x3fff8000 to 0x3fff9c80:
Dumping Stack from 0x3fff8000 to 0x3fffa0c0:
Dumping Stack from 0x3fff8000 to 0x3fffa500:
Dumping Stack from 0x3fff8000 to 0x3fffa940:
Dumping Stack from 0x3fff8000 to 0x3fffad80:
Dumping Stack from 0x3fff8000 to 0x3fffb1c0:
Dumping Stack from 0x3fff8000 to 0x3fffb600:
Dumping Stack from 0x3fff8000 to 0x3fffba40:
Dumping Stack from 0x3fff8000 to 0x3fffbe80:
Dumping Stack from 0x3fff8000 to 0x3fffc2c0:
Dumping Stack from 0x3fff8000 to 0x3fffc700:
Dumping Stack from 0x3fff8000 to 0x3fffcb40:
Dumping Stack from 0x3fff8000 to 0x3fffcf80:
Dumping Stack from 0x3fff8000 to 0x3fffd3c0:
WARNING! Stack pointer and cr30 do not correspond!
Dumping virtual address stack instead
Dumping Stack from 0x3fff8000 to 0x3fffd800:
2D10L
FLT CBF0C1D2D10L
FLT 5002C1D2D10L
FLT 7D03C1D2D10L
FLT 5408C1D2D10L
FLT 5508C1D2D10L
FLT CBFBC1D
WARNING! Stack pointer and cr30 do not correspond!
Dumping virtual address stack instead
Dumping Stack from 0x40000000 to 0x400001c0:
WARNING! Stack pointer and cr30 do not correspond!
Dumping virtual address stack instead
8000 82425ed8 275c3a54 0484bdb0 4eb874a8 09097b60 9d70e950 12644392 3a9767f3
8020 24c88724 752ecfe6 49910e48 ea5d9fcc 9354a9c2 d4cd8acb 26dfe6d6 a9eda0c5
8040 4dc978fe 53adf4d9 9b92f1fc a75be9b2 375356aa 4ec16637 6ea6ad54 9d82cc6e
8060 dd3beffa 3b732d8f ba77dff4 76e65b1e 74efbfe8 edccb63c e9a9ca82 dbefd92b
8080 d3252056 b7a90705 a63cf5fe 6f24bb59 4c79ebfc de4976b2 988562aa bce45837
80a0 317c7006 79be053d 62f8e00c f37c0a7a c587754a e68ea1a7 8b785fc6 cd6bf61d
80c0 16860ade 9aa15969 2d7aa0ee 35340781 5af541dc 6a680f02 b5ea83b8 d4d01e04
80e0 6ba3b222 a9d6895b d731d116 53dba7e5 ae63a22c a7b74fca 5cb1f10a 4f182ac7
8100 b963e214 9e30558e 72b1717a 3c161e4f e562e2f4 782c3c9e cac5c5e8 f058793c
8120 95fd3e82 e0c6472b 2b8cc856 c1fa3b05 576f25fe 8382c359 aea8feae 077333e1
8140 5d51fd5c 0ee667c2 baa3fab8 1dcccf84 7547f570 3b999f08 ea8feae0 77333e10
8160 d51fd5c0 ee667c20 aa491ed2 dcba4d13 54e488f6 b9022f75 a9bfa4be 7272ebb9
8180 537f497c e4e5d772 a68827aa c9bd1bb7 4d66fa06 930c823d 9abb415e 266fb129
81a0 357682bc 4cdf6252 6aed0578 99bec4a4 d5acbfa2 330b3c1b ab597f44 66167836
81c0 56b2fe88 cc2cf06c ad134842 982f558b 5a5025d6 30281e45 b4a04bac 60503c8a
81e0 69409758 c0a07914 d2f79be2 8136477b a5998296 021a3ba5 4b33052c 0434774a
8200 96660a58 0868ee94 2ccc14b0 10d1dd28 59982960 21a3ba50 b33052c0 434774a0
8220 6660a580 868ee940 ccb7fe52 0d6b67d3 996ffca4 1ad6cfa6 32dff948 35ad9f4c
8240 65bff290 6b5b3e98 cb7fe520 d6b67d30 96897f12 ad1a4f33 2d644b76 5a422b35
8260 5ac896ec b484566a b5e7988a 697e1987 6bcf3114 d2fc330e d7e8d77a a58ed34f
8280 afa71ba6 4b6b13cd 5f4e374c 96d6279a beeadbca 2ddafa67 7dd5b794 5bb5f4ce
82a0 fbab6f28 b76be99c f7206b02 6ea1666b ee40d604 dd42ccd6 dcf7195a baf32cff
82c0 b99887e6 7590ecad 73310fcc eb21d95a e614aaca d63507e7 cc5fe0c6 ac1cba9d
82e0 98c974de 584fc069 3192e9bc b09f80d2 6353662a 6149b4f7 c6a6cc54 c29369ee
8300 8d3b2dfa 8550668f 1a00eea6 0ad6784d 3401dd4c 15acf09a 6803ba98 2b59e134
8320 d0077530 56b3c268 a00eea60 ad6784d0 406b6192 5ab9bcf3 80d6c324 b57379e6
8340 01db331a 6a90469f 03b66634 d5208d3e 071a793a aa37af2f 0e424726 5419eb0d
8360 1c848e4c a833d61a 397fa9ca 50111967 72ff5394 a02232ce e588127a 4032d0cf
8380 cb1024f4 8065a19e 9656fcba 00bdf66f 2cadf974 017becde 595bf2e8 02f7d9bc
83a0 b2b7e5d0 05efb378 656fcba0 0bdf66f0 cadf9740 17becde0 95bf2e80 2f7d9bc0
83c0 2b7e5d00 5efb3780 56fcba00 bdf66f00 ad8fc152 7b9a6b53 5b1f82a4 f734d6a6
83e0 b649b01a ee1f181f 6ce5d566 dc48856d d9bd1f9e b8e7bf89 b30c8a6e 71b9ca41
8400 661914dc e3739482 cc449cea c6919c57 98ff8c86 8d558dfd 3189ac5e 1addaea9
8420 631358bc 35bb5d52 c626b178 6b76baa4 8c4d62f0 d6ed7548 18ec70b2 adac5fc3
8440 31ae5436 5b2e0ad5 635ca86c b65c15aa c6cfe58a 6cce9e07 8d9fcb14 d99d3c0e
8460 1b49237a b34ccd4f 36e4f3a6 66ef2fcd 6dc9e74c cdde5f9a dbe57bca 9bca0a67
8480 b7bc42c6 37e2a19d 6f78858c 6fc5433a def10b18 df8a8674 bd94a362 bf63b9bb
84a0 7b5ff396 7eb1c625 f6bfe72c fd638c4a ed097b0a fab1adc7 da644346 f515eedd
84c0 b4be33de ea5d68e9 690ad2ee d4cc6481 d263108e a9ee7c51 a4b0944e 53aa4df1
84e0 4961289c a7549be2 92b4e46a 4edf8297 2569c8d4 9dbf052e 4aa524fa 3b08bf0f
8500 954a49f4 76117e1e 2a9493e8 ec22fc3c 555f9282 d8334d2b aac99056 b0102f05
8520 55e595fe 6056eb59 abcb2bfc c0add6b2 57e0e2aa 812d1837 afb77006 022c853d
8540 5f6ee00c 04590a7a beddc018 08b214f4 7dbb8030 116429e8 fb770060 22c853d0
8560 f6ee00c0 4590a7a0 eddc0180 8b214f40 dbceb652 16342bd3 b79d6ca4 2c6857a6
8580 6f3ad948 58d0af4c de75b290 b1a15e98 bc9dd072 63340863 793ba0e4 c66810c6
85a0 f201f49a 8ca694df e4755c66 193b9ced c8eab8cc 327739da 91d57198 64ee73b4
85c0 23aae330 c9dce768 47237332 93cf7b83 8e305336 27e84255 1c60a66c 4fd084aa
85e0 38c14cd8 9fa10954 71f42ce2 3f34a7fb e3e859c4 7e694ff6 c7d0b388 fcd29fec
8600 8fd7d242 f9d38a8b 1fd911d6 f3d1a045 3fc496fe e7d5f5d9 7fff98ae cfdd5ee1
8620 ff89840e 9fcc0891 ff65bd4e 3feea471 fecb7a9c 7fdd48e2 fd96f538 ffba91c4
8640 fb5b5f22 ff0396db f6c00b16 fe7198e5 edf6a37e fc958499 db9bf3ae f95dbc61
8660 b741520e f2cdcd91 6ef4114e e5ed2e71 dd9e97ce cbace9b1 bb4b9ace 972f6631
8680 76e180ce 2e287931 edc3019c 5c50f262 db860338 b8a1e4c4 b77ab322 71357cdb
86a0 6ef56644 e26af9b6 dd9c79da c4a3463f bb4e46e6 8930392d 76ea389e 1216c709
86c0 edd4713c 242d8e12 dba8e278 485b1c24 b751c4f0 90b63848 6ed53cb2 211ac5c3
86e0 ddaa7964 42358b86 bb54f2c8 846b170c 76df50c2 08a09b4b edbea184 11413696
8700 db7d4308 22826d2c b6fa8610 4504da58 6df50c20 8a09b4b0 db9cad12 1465dc33
8720 b7395a24 28cbb866 6e72b448 519770cc dce56890 a32ee198 b9bc6472 462b7663
8740 7378c8e4 8c56ecc6 e687249a 18db6cdf cd0e4934 31b6d9be 9a1c9268 636db37c
8760 343924d0 c6db66f8 6804fcf2 8dc078a3 d07f4cb6 1bf64415 a0fe996c 37ec882a
8780 41fd32d8 6fd91054 83fa65b0 dfb220a8 07827e32 bf12f403 0f724936 7e535d55
87a0 1ee4926c fca6baaa 3dbf918a f93bc007 7b099646 f201355d f66599de e474dfe9
87c0 ecbd86ee c89f0a81 d90db88e 9148a051 b26dc44e 22e7f5f1 64db889c 45cfebe2
87e0 c9b71138 8b9fd7c4 93189722 17491adb 26312e44 2e9235b6 4c625c88 5d246b6c
8800 98c4b910 ba48d6d8 31ffc772 74e718e3 63ff8ee4 e9ce31c6 c789a89a d3ead6df
8820 8f65e466 a7a318ed 1ebd7d9e 4f308489 3d7afb3c 9e610912 7a83432a 3cb4a777
8840 f5068654 79694eee ea0d0ca8 f2d29ddc d46cac02 e5d38eeb a8afed56 cbd1a885
8860 51296ffe 97d5e459 a2246aae 2fdd7de1 4448d55c 5fbafbc2 8891aab8 bf75f784
8880 1155e022 7e9d5a5b 22abc044 fd3ab4b6 452135da fa03dc3f 8a34dee6 f4710d2d
88a0 141f089e e894af09 2848a46e d15feb41 50e7fd8e a2c963d1 a1b94e4e 45e472f1
88c0 43729c9c 8bc8e5e2 86938c6a 17e77e97 0d2718d4 2fcefd2e 1a4e31a8 5f9dfa5c
88e0 349c6350 bf3bf4b8 694e73f2 7e015c23 d29ce7e4 fc02b846 a54f7a9a f873c5df
8900 4ae84066 f0913eed 95a6359e e154c889 2b3ade6e c2df2441 5603098e 85c8fdd1
8920 ac70a64e 0be74ef1 58e14c9c 17ce9de2 b1c29938 2f9d3bc4 63853270 5f3a7788
8940 c70a64e0 be74ef10 8e627c92 7c9f6b73 1cc4f924 f93ed6e6 39ff471a f20b189f
8960 73883b66 e460846d e766c39e c8b7bd89 cebb326e 9119ce41 9d00d18e 224529d1
8980 3a01a31c 448a53a2 74034638 8914a744 e8703922 125ffbdb d0e07244 24bff7b6
89a0 a1c0e488 497fef6c 4381c910 92ffded8 87752772 258908e3 0eea4ee4 4b1211c6
89c0 1dd49dc8 9624238c 3bdf8ec2 2c3ef24b 77bf1d84 587de496 ef7e3b08 b0fbc92c
89e0 de8ac342 6181270b bd158684 c3024e16 7a5db85a 8672297f f4cdc5e6 0c92e7ad
8a00 e99b8bcc 1925cf5a d3371798 324b9eb4 a66e2f30 64973d68 4cdc5e60 c92e7ad0
8a20 99ce0992 922a40f3 33eaa676 242234b5 67d54cec 4844696a cfaa99d8 9088d2d4
8a40 9f2386e2 216710fb 3e470dc4 42ce21f6 7c8e1b88 859c43ec f96a8242 0b4e328b
8a60 f2d50484 169c6516 e5aa0908 2d38ca2c cb541210 5a719458 96a82420 b4e328b0
8a80 2d26fd12 69b0e433 5a4dfa24 d361c866 b4ed411a a6b5259f 69ac3766 4d1cfe6d
8aa0 d3586ecc 9a39fcda a6c668ca 34054ce7 4d8cd194 680a99ce 9b19a328 d015339c
8ac0 3645f302 a05cd26b 6cfd60 6b491480 b8f634c0
9100 d6e49c52 719adcd3 adc938a4 e335b9a6 5be4c41a c61dc61f b7bf3d66 8c4d396d
9120 6f08cf9e 18ecc789 de119f3c 31d98f12 bc233e78 63b31e24 78467cf0 c7663c48
9140 f0fa4cb2 8ebacdc3 e1822c36 1d032ed5 c304586c 3a065daa 8608b0d8 740cbb54
9160 0c1161b0 e81976a8 18547632 d0445803 30de5936 a0fe0555 61ca073e 418abff9
9180 c3940e7c 83157ff2 875ea9aa 065c4ab7 0ebd5354 0cb8956e 1d7aa6a8 19712adc
91a0 3af54d50 32e255b8 75ea9aa0 65c4ab70 ebd53540 cb8956e0 d7dcdfd2 97641893
91c0 afcf0af6 2ebe8475 5f9e15ec 5d7d08ea bf3c2bd8 bafa11d4 7e0ee2e2 758296fb
91e0 fc1dc5c4 eb052df6 f84d3eda d67ceebf f0ecc8e6 ac8f682d e1af249e 59686509
9200 c35e493c b2d0ca12 86ca272a 65d72177 0d944e54 cbae42ee 1b5e29fa 972a308f
9220 36cae6a6 2e22d44d 6d95cd4c 5c45a89a db2b9a98 b88b5134 b6218062 7160173b
9240 6c4300c4 e2c02e76 d8f0b4da c5f6e9bf b197dce6 8b9b662d 63590c9e 17407909
9260 c6b2193c 2e80f212 8d643278 5d01e424 1ac864f0 ba03c848 35e67cb2 747125c3
9280 6bccf964 e8e24b86 d7ef479a d1b2225f afa83a66 a312f1ed 5f26c19e 46535689
92a0 be4d833c 8ca6ad12 7cedb32a 193bef77 f9db6654 3277deee f3b6cca8 64efbddc
92c0 e76d9950 c9df7bb8 cead87f2 93c84223 9d2dbab6 27e63115 3a5b756c 4fcc622a
92e0 74b6ead8 9f98c454 e91b60e2 3f473dfb d236c1c4 7e8e7bf6 a46d8388 fd1cf7ec
9300 48adb242 fa4f5a8b 912dd1d6 f4e80045 222d16fe e9a6b5d9 442c98ae d33bdee1
9320 882f840e a6010891 1029bd4e 4c74a471 20537a9c 98e948e2 40d0406a 31a42497
9340 81a080d4 6348492e 034101a8 c690925c 06f4b602 8d5791eb 0d9fd956 1ad99685
9360 1b3fb2ac 35b32d0a 367f6558 6b665a14 6cfecab0 d6ccb428 d98b2032 adefdd03
9380 b360f536 5ba90f55 66c1ea6c b7521eaa cdf5618a 6ed28807 9beac314 dda5100e
93a0 37a3337a bb3c954f 6f30d3a6 760f9fcd de61a74c ec1f3f9a bcb5fbca d848ca67
93c0 791d42c6 b0e7219d f24c30de 61b8f669 e49861bc c371ecd2 c946762a 86956cf7
93e0 92fa5906 0d5c6cbd 25f4b20c 1ab8d97a 4be96418 3571b2f4 97d2c830 6ae365e8
9400 2fa59060 d5c6cbd0 5f3d9592 abfb22f3 be0d9e76 5780f0b5 7c1b3cec af01e16a
9420 f840cc8a 5e757787 f0819914 bceaef0e e175877a 79a36b4f c2eb0ef4 f346d69e
9440 85a0a8ba e6fb186f 0b37e426 cd80858d 16197d1e 9b77be49 2c444f6e 3699c9c1
9460 58889edc 6d339382 b1113db8 da672704 6254ce22 b4b8fb5b c4df2916 690743e5
9480 89be522c d20e87ca 130a110a a46bbac7 26629746 48a1c0dd 4cc52e8c 914381ba
94a0 99fce84a 22f1b627 33f9d094 45e36c4e 67f3a128 8bc6d89c cf91f702 17fb046b
94c0 9f23ee04 2ff608d6 3e47dc08 5fec11ac 7c8fb810 bfd82358 f969c572 7fc6f3e3
94e0 f2d38ae4 ff8de7c6 e5d1a09a ff6d7adf cbd5f466 feac40ed 97dd5d9e fd2e3489
9500 2fcc0e6e fa2adc41 5feea98e f4230dd1 bfabe64e e830aef1 7f2179ce d017e8b1
9520 fe3446ce a0596431 fc1e38ce 40c47d31 f83c719c 8188fa62 f00e566a 03674197
9540 e01cacd4 06ce832e c03959a8 0d9d065c 8072b350 1b3a0cb8 00e566a0 36741970
9560 01cacd40 6ce832e0 03959a80 d9d065c0 075d8052 b3d67ed3 0ecdb5f6 67da48f5
9580 1d9b6bec cfb491ea 3b40628a 9f1f9687 76f67046 3e49985d edece08c 7c9330ba
95a0 dbd9c118 f9266174 b7c53762 f23a77bb 6ffcdb96 e4025a25 df8f027e c8720119
95c0 bf68b1ae 9092b761 7ea7d60e 2153db91 fd4fac1c 42a7b722 fa9f5838 854f6e44
95e0 f5480522 0ae869db ea900a44 15d0d3b6 d5201488 2ba1a76c aa402910 57434ed8
9600 54805220 ae869db0 a9761112 5d7b8e33 52ec2224 baf71c66 a5aef11a 75988d9f
9620 4b5de234 eb311b3e 96cd713a d614832f 2dec5726 ac5fb30d 5bae1b1e 58c9d349
9640 b75c363c b193a692 6eced92a 6351f877 dd9db254 c6a3f0ee bb4dd1fa 8d31548f
9660 76ed16a6 1a141c4d edda2d4c 3428389a dbb45a98 68507134 b768b530 d0a0e268
9680 6ea7df32 a1377183 dd390b36 42185655 ba72166c 8430acaa 7492998a 0817ec07
96a0 e9253314 102fd80e d24a6628 205fb01c a494cc50 40bf6038 492998a0 817ec070
96c0 92258412 028b35b3 244b0824 05166b66 48961048 0a2cd6cc 912c2090 1459ad98
96e0 22584120 28b35b30 44b08240 5166b660 89610480 a2cd6cc0 12b4bc52 45ec6cd3
9700 256978a4 8bd8d9a6 4aa4441a 17c7061f 95488834 2f8e0c3e 2a911068 5f1c187c
9720 552220d0 be3830f8 aa32f4f2 7c06d4a3 5465e9e4 f80da946 a8bd669a f06de7df
9740 510c7866 e0ad7aed a26e459e c12c4089 44aa3e6e 822e3441 8922c98e 042addd1
9760 1245931c 0855bba2 248b2638 10ab7744 49164c70 2156ee88 922c98e0 42addd10
9780 245931c0 855bba20 48c4d6d2 0ac1c113 9189ada4 15838226 23135b48 2b07044c
97a0 4626b690 560e0898 8c4d6d20 ac1c1130 18ec6f12 584e9733 31d8de24 b09d2e66
97c0 63c7091a 614ce99f c78e1234 c299d33e 8f6a913a 8545132f 1ea39726 0afc930d
97e0 3d472e4c 15f9261a 7a8e5c98 2bf24c34 f51cb930 57e49868 ea397260 afc930d0
9800 d4045192 5fe4d4f3 a808a324 bfc9a9e6 5067f31a 7fe5e69f a0cfe634 ffcbcd3e
9820 41e9793a ffe12f2f 83a44726 ffb4eb0d 073e3b1e ff1f6349 0e0ac36e fe4873c1
9840 1c63338e fce652d1 38b0d24e f9ba10f1 711711ce f30294b1 e25896ce e6739c31
9860 c4c798ce cc918d31 89f984ce 9955af31 1385bcce 32ddeb31 270b799c 65bbd662
9880 4e16f338 cb77acc4 9c5b5322 9699ecdb 38c01316 2d456ce5 7180262c 5a8ad9ca
98a0 e3004c58 b515b394 c6762de2 6a5dd27b 8cec5bc4 d4bba4f6 19ae02da a901fcbf
98c0 332ab0e6 52754c2d 665561cc a4ea985a ccdc76ca 49a385e7 99b8ed94 93470bce
98e0 33076e7a 26f8a2cf 660edcf4 4df1459e cc1db9e8 9be28b3c 984dc682 37b3a32b
9900 309b8d04 6f674656 61371a08 dece8cac c2188142 bdebac0b 8447b7d6 7ba1ed45
9920 088f6fac f743da8a 11686a0a eef10047 22a66146 dd94b5dd 453a77de bb5fdee9
9940 8a025aee 76c90881 1404b5dc ed921102 287fdeea db529757 50890886 b6d39bfd
9960 a164a45e 6dd182a9 42c948bc dba30552 85e4242a b730bff7 0bbefd06 6e17cabd
9980 177dfa0c dc2f957a 2e8d414a b8299fa7 5d6c37c6 70258a1d bad86f8c e04b143a
99a0 75c66a4a c0e09d27 ebfa61c6 81b78f1d d78276de 0319ab69 af04edbc 063356d2
99c0 5e09db78 0c66ada4 bc13b6f0 18cd5b48 78276de0 319ab690 f04edbc0 63356d20
99e0 e09db780 c66ada40 c14dda52 8ca301d3 82ed01f6 1930b6f5 05da03ec 32616dea
9a00 0bb407d8 64c2dbd4 17680fb0 c985b7a8 2ea6aa32 937dda03 5d3be136 268d0155
9a20 ba77c26c 4d1a02aa 74ef84d8 9a340554 e9a9bce2 341ebffb d35379c4 683d7ff6
9a40 a6a6f388 d07affec 4d3b5242 a0834a8b 9a0011d6 41702045 340023ac 82e0408a
9a60 6876f20a 05b63447 d0ede414 0b6c688e a1dbc828 16d8d11c 43b79050 2db1a238
9a80 876f20a0 5b634470 0ede4140 b6c688e0 1dca37d2 6dfba493 3b946fa4 dbf74926
9aa0 775e6a1a b798271f eeca6166 6f46fb6d dd94c2cc de8df6da bb5f30ca bd6d58e7
9ac0 76c8d4c6 7aac049d ed91a98c f558093a db55e64a eac6a727 b6dd79c6 d5fbfb1d
9ae0 6dcc46de ab814369 dbee38ee 57743381 b7dc71dc aee86702 6fce56ea 5da67b57
9b00 df9cadd4 bb4cf6ae bf4feefa 76ef580f 7e9fddf4 eddeb01e fd490eba dbcbd56f
9b20 fae4a826 b7e11f8d f5bfe51e 6fb48a49 eb7fca3c df691492 d689212a bea49c77
9b40 ad64f706 7d3f8dbd 5ac9ee0c fa7f1b7a b5e5694a f48883a7 6bbc67c6 e967b21d
9b60 d70e7ade d2b9d169 ae6a40ee a5051781 5ca2348e 4a7c9a51 b944691c 94f934a2
9b80 72fe676a 2984dc17 e5fcced4 5309b82e cbf99da8 a613705c 97858e02 4c5055eb
9ba0 2f0b1c04 98a0abd6 5e608d5a 3137e2ff bcc11ab4 626fc5fe 79823568 c4df8bfc
9bc0 f372df82 89c9a2ab e6930a56 13e5f005 cd2614ac 27cbe00a 9a4c2958 4f97c014
9be0 349852b0 9f2f8028 69461032 3e29b503 d28c2064 7c536a06 a51840c8 f8a6d40c
9c00 4a4634c2 f13b1d4b 94fadcd6 e2008fc5 29830cfe c477aad9 5370acae 8899e0e1
9c20 a697ec0e 11457491 4d2fd81c 228ae922 9a5fb038 4515d244 34bf6070 8a2ba488
9c40 690875b2 1421fc43 d210eb64 2843f886 a421d6c8 5087f10c 4843ad90 a10fe218
9c60 90f1ee72 42697163 21e3dce4 84d2e2c6 43b10c9a 09d370df 87621934 13a6e1be
9c80 0ec43268 274dc37c 1d8864d0 4e9b86f8 3b10c9a0 9d370df0 76572612 3a18aeb3
9ca0 ecae4c24 74315d66 d95c9848 e862bacc b2cf85c2 d0b3c0cb 65e9bed6 a11134c5
9cc0 cba5c8fe 4254dcd9 974b91fc 84a9b9b2 2ee196aa 0925c637 5dc32d54 124b8c6e
9ce0 bb865aa8 249718dc 770cb550 492e31b8 ee196aa0 925c6370 dc446012 24ce73b3
9d00 b888c024 499ce766 71118048 9339cecc e255b5c2 260528cb c4ab6b84 4c0a5196
9d20 8956d708 9814a32c 12db1b42 305ff30b 25b63684 60bfe616 4b6c6d08 c17fcc2c
9d40 96ae6f42 82892d0b 2d2a6bd6 0564ef45 5a54d7ac 0ac9de8a b4a9af58 1593bd14
9d60 69535eb0 2b277a28 d2a6bd60 564ef450 a54d7ac0 ac9de8a0 4aec40d2 594d6413
9d80 95d881a4 b29ac826 2bc7b61a 6543251f 578f6c34 ca864a3e af686d3a 957a212f
9da0 5ea66f26 2a82f70d bd4cde4c 5505ee1a 7a99bc98 aa0bdc34 f545cc62 54610d3b
9dc0 ea8b98c4 a8c21a76 d56184da 51f281bf aac309b4 a3e5037e 55f0a63a 47bcb3af
9de0 abe14c74 8f79675e 57b42dba 1e847bef af685b74 3d08f7de 5ed0b6e8 7a11efbc
9e00 bda16dd0 f423df78 7b346ef2 e8310ba3 f61e68b6 d014a215 ec4a643e a05ff179
9e20 d8e27d2e 40c957a1 b1c4fa5c 8192af42 63ff41ea 0353ebd7 c7fe83d4 06a7d7ae
9e40 8ffd07a8 0d4faf5c 1ffa0f50 1a9f5eb8 3ff41ea0 353ebd70 7fe83d40 6a7d7ae0
9e60 ffd07a80 d4faf5c0 ffd64052 a9835ed3 ffda35f6 537008f5 ffb46bec a6e011ea
9e80 ff1e628a 4db69687 fe3cc514 9b6d2d0e fc0f3f7a 36acef4f f81e7ef4 6d59de9e
9ea0 f03cfde8 dab3bd3c e00f4e82 b511cf2b c0682856 6a552b05 80d050ac d4aa560a
9ec0 01d6140a a9221947 03da9d46 523287dd 07b53a8c a4650fba 0f1cc04a 48bcaa27
9ee0 1e398094 9179544e 3c05b47a 22841dcf 780b68f4 45083b9e f016d1e8 8a10773c
9f00 e05b1682 14565b2b c0b62d04 28acb656 816c5a08 51596cac 02d8b410 a2b2d958
9f20 05c7dd72 451307e3 0b8fbae4 8a260fc6 1769c09a 143aaadf 2ed38134 287555be
9f40 5da70268 50eaab7c bb4e04d0 a1d556f8 76eabcf2 43dc18a3 edd579e4 87b83146
9f60 dbdc469a 0f06d7df b7b88d34 1e0dafbe 6f711a68 3c1b5f7c dee234d0 7836bef8
9f80 bdc469a0 f06d7df0 7bfe6612 e0ac4eb3 f78a7976 c12e2835 ef6247be 822ae539
9fa0 deb23a2e 04237f21 bd64745c 0846fe42 7ac8e8b8 108dfc84 f591d170 211bf908
9fc0 eb23a2e0 4237f210 d64745c0 846fe420 acf83ed2 08a97d13 59f07da4 1152fa26
9fe0 b3e0fb48 22a5f44c 67c1f690 454be898 cf83ed20 8a97d130 9f716f12 15591733
a000 3ee2de24 2ab22e66 7dc5bc48 55645ccc fb8b7890 aac8b998 f7604472 55e7c663
a020 eec088e4 abcf8cc6 ddf7a49a 57e9acdf bbef4934 afd359be 77a8273a 5fd0062f
a040 ef504e74 bfa00c5e ded629ba 7f36adef bdac5374 fe6d5bde 7b2e13ba fcac02ef
a060 f62a9226 f92eb08d ec23911e f22bd449 d831976e e4211dc1 b0159b8e c8348ed1
a080 605d824e 901fa8f1 c0cdb1ce 2049e4b1 819b639c 4093c962 0336c738 812792c4
a0a0 061b3b22 023990db 0c367644 047321b6 186cec88 08e6436c 30d9d910 11cc86d8
a0c0 61b3b220 23990db0 c3676440 47321b60 86cec880 8e6436c0 0deb2452 1cbed8d3
a0e0 1bd648a4 397db1a6 37ac9148 72fb634c 6f592290 e5f6c698 dec4f072 cb9b3863
a100 bdff55b6 9740c595 7b881e3e 2ef73e79 f7103c7c 5dee7cf2 ee2078f8 bbdcf9e4
a120 dc3644a2 77cf469b b86c8944 ef9e8d36 70afa7da df4baf3f e129fae6 bee1eb2d
a140 c225409e 7db56309 844a813c fb6ac612 08e3b72a f6a33977 11b1db06 ed30c7bd
a160 2315035e da173a29 465cb3ee b458c101 8ccfd28e 68c73751 199fa51c d18e6ea2
a180 3349ff6a a36a6817 66e54b86 46a2657d cdca970c 8d44cafa 9be39b4a 1aff20a7
a1a0 37c73694 35fe414e 6f8e6d28 6bfc829c df1cda50 d7f90538 be4f01f2 af84bf23
a1c0 7ce8b6b6 5f7fcb15 f9d16d6c beff962a f3d46f8a 7d899907 e7a8df14 fb13320e
a1e0 cf270b7a f650d14f 9e38a3a6 ecd717cd 3c07f21e d9d89ac9 7879516e b3c780c1
a200 f084178e 67f9b4d1 e1082f1c cff369a2 c266eb6a 9f906617 84bb6386 3f56797d
a220 0976c70c 7eacf2fa 12ed8e18 fd59e5f4 25ada962 fac57ebb 4b2de796 f5fc4825
a240 962d7a7e eb8e2519 2c2c41ae d76aff61 582e360e aea34b91 b02ad94e 5d302271
a260 6055b29c ba6044e2 c0ddd06a 74b63c97 81bba0d4 e96c792e 0301f4fa d2ae470f
a280 06755ca6 a52a3b4d 0c9c0c1e 4a22c3c9 1938183c 94458792 3206852a 28fdba77
a2a0 640d0a54 51fb74ee c81a14a8 a3f6e9dc 90429c02 479b66eb 20853804 8f36cdd6
a2c0 417cc55a 1e1b2eff 82f98ab4 3c365dfe 05f31568 786cbbfc 0be62ad0 f0d977f8
a2e0 17bae0f2 e1c45aa3 2f0374b6 c3fe0015 5e705c3e 878ab579 bc960d2e 0f63dfa1
a300 792c1a5c 1ec7bf42 f25834b8 3d8f7e84 e4b06970 7b1efd08 c960d2e0 f63dfa10
a320 92b71092 ec0d4173 25189476 d86c37b5 4a479dbe b0aeda39 94f98e2e 612b0121
a340 29f31c5c c2560242 53908dea 84dab1d7 a757ae86 09c3d6fd 4eaf5d0c 1387adfa
a360 9d5eba18 270f5bf4 3abd7430 4e1eb7e8 757ae860 9c3d6fd0 ea836592 380c6af3
a380 d506cb24 7018d5e6 aa0d9648 e031abcc 546d99c2 c015e2cb a8ad86d6 805d70c5
a3a0 512db8fe 00cc54d9 a25b71fc 0198a9b2 44b6e3f8 03315364 896dc7f0 0662a6c8
a3c0 12db8fe0 0cc54d90 25b71fc0 198a9b20 4b6e3f80 33153640 96dc7f00 662a6c80
a3e0 2db8fe00 cc54d900 5b074952 98df0753 b67827f6 31c8bbf5 6cf04fec 639177ea
a400 d9e09fd8 c722efd4 b3b78ae2 8e336afb 6719a096 1c1060a5 ce33412c 3820c14a
a420 9c668258 70418294 38cd04b0 e0830528 71ecbc32 c170bf03 e3afcd36 8297cb55
a440 c7292f3e 055923f9 8e525e7c 0ab247f2 1ca4bcf8 15648fe4 394979f0 2ac91fc8
a460 7292f3e0 55923f90 e525e7c0 ab247f20 ca3d7ad2 563e4b13 947af5a4 ac7c9626
a480 28835e1a 588f991f 5106bc34 b11f323e a27bcd3a 6248d12f 44f79a74 c491a25e
a4a0 899981ba 8955f1ef 1345b626 12dd568d 268b6c4c 25baad1a 4d16d898 4b755a34
a4c0 9a2db130 96eab468 342dd732 2da3dd83 685bae64 5b47bb06 d0b75cc8 b68f760c
a4e0 a1180cc2 6d68594b 42301984 dad0b296 8416865a b5d7d07f 085bb9e6 6bd915ad
a500 10b773cc d7b22b5a 211852ca af12e3e7 424610c6 5e53729d 848c218c bca6e53a
a520 096ef64a 793b7f27 12ddec94 f276fe4e 25cd6c7a e49b49cf 4bec6da6 c94026cd
a540 97ae6e1e 92f6f8c9 2f2a696e 259b44c1 5e54d2dc 4b368982 bca9a5b8 966d1304
a560 7925fe22 2cac935b f24bfc44 595926b6 e497f888 b2b24d6c c9594442 65122f8b
a580 92b28884 ca245f16 2513a45a 943e0b7f 4a51fde6 280aa3ad 94a3fbcc 5015475a
a5a0 2947f798 a02a8eb4 52f95a62 4023a83b a5f2b4c4 80475076 4b93dcda 00f815bf
a5c0 9727b9b4 01f02b7e 2e4f7368 03e056fc 5c9ee6d0 07c0adf8 b93dcda0 0f815bf0
a5e0 727b9b40 1f02b7e0 e4f73680 3e056fc0 c9ee6d00 7c0adf80 93dcda00 f815bf00
a600 27cf0152 f05dcb53 4fe8b7f6 e0cd23f5 9fa7dabe c1ecf2b9 3f39002e 83af5021
a620 7e04b50e 07281511 fc096a1c 0e502a22 f812d438 1ca05444 f025a870 3940a888
a640 e04b50e0 72815110 c096a1c0 e502a220 815bf6d2 ca73f113 02c158f6 94915775
a660 05f404be 29541bb9 0be8097c 52a83772 17d012f8 a5506ee4 2fd690a2 4ad6689b
a680 5fad2144 95acd136 bf2cf7da 2b2f173f 7e59efb4 565e2e7e fcb3df68 acbc5cfc
a6a0 f9110b82 590e0cab f2221704 b21c1956 e4329b5a 644e87ff c86536b4 c89d0ffe
a6c0 90bcd83a 914caaaf 210f0526 22efe00d 421e0a4c 45dfc01a 843c1498 8bbf8034
a6e0 080e9c62 1709b53b 101d38c4 2e136a76 203a7188 5c26d4ec 4074e310 b84da9d8
a700 809f7372 70ede6e3 013ee6e4 e1dbcdc6 020b789a c3c12edf 04604466 87f4e8ed
a720 08b63d9e 0f9f6489 116c7b3c 1f3ec912 22d8f678 3e7d9224 45b1ecf0 7cfb2448
a740 8b63d9e0 f9f64890 16b10692 f39a2473 2d14b876 e742fdb5 5a5fc5be cef34e39
a760 b4c93e2e 9d902921 69e4c90e 3b56e711 d3c9921c 76adce22 a7932438 ed5b9c44
a780 4f50fd22 dac18ddb 9ed74f16 b5f5aee5 3dd82b7e 6b9de899 7bb056fc d73bd132
a7a0 f71618aa ae011737 ee5a8406 5c749b3d dcb5080c b8e9367a b91ca54a 71a4d9a7
a7c0 72394a94 e349b34e e404207a c6e5d3cf c87ef5a6 8dbd12cd 908b5e1e 1b0c90c9
a7e0 2116bc3c 36192192 422d7878 6c324324 845af0f0 d8648648 08c354b2 b0bfb9c3
a800 11f01c36 6109c6d5 23e0386c c2138daa 47b6c58a 8451ae07 8f1b3e46 08d5e95d
a820 1e367c8c 11abd2ba 3c6cf918 2357a574 78d9f230 46af4ae8 f1b3e460 8d5e95d0
a840 e3117d92 1acb9ef3 c622fb24 35973de6 8c45f648 6b2e7bcc 188bec90 d65cf798
a860 31616c72 accf5a63 62b46db6 59e80195 c568db6c b3d0032a 8aa7038a 67d6b307
a880 154e0714 cfad660e 2aeabb7a 9f2c794f 55a3c3a6 3e2e47cd ab47874c 7c5c8f9a
a8a0 568f0e98 f8b91f34 ad68a862 f1048b3b 5aa7e596 e27fa325 b5397e7e c489f319
a8c0 6a0449ae 89655361 d47e260e 12bc1391 a8fc4c1c 25782722 51f89838 4af04e44
a8e0 a3f13070 95e09c88 4794d5b2 2bb78c43 8f29ab64 576f1886 1e5356c8 aede310c
a900 3cd018c2 5dcad74b 79a03184 bb95ae96 f336d65a 775de87f e66dacb4 eebbd0fe
a920 ccadec3a dd0114af 992d6d26 ba749c0d 322c6f1e 749f8d49 6458de3c e93f1a92
a940 c8c7092a d2088077 91f8a706 a467b5bd 2387fb5e 48b9de29 470ff6bc 9173bc52
a960 8e69582a 2291cdf7 1cd2b054 45239bee 39a560a8 8a4737dc 733c7402 14f8daeb
a980 e678e804 29f1b5d6 ccf1d008 53e36bac 99e3a010 a7c6d758 33b1f572 4ffb1be3
a9a0 6763eae4 9ff637c6 ceb1609a 3f9adadf 9d62c134 7f35b5be 3ac58268 fe6b6b7c
a9c0 75fdb182 fca063ab eb8dd656 f9367205 d76d19fe f21a5159 aeac86ae e44217e1
a9e0 5d2fb80e c8f29a91 ba29c54e 91938071 74253fce 2351b5b1 e84a7f9c 46a36b62
aa00 d094ff38 8d46d6c4 a15f4b22 1afb18db 42be9644 35f631b6 857d2c88 6bec636c
aa20 0afa5910 d7d8c6d8 15820772 afc738e3 2b72bbb6 5ff8c495 56e5776c bff1892a
aa40 adbc5b8a 7f95a707 5b78b714 ff2b4e0e b687db7a fe20294f 6d7903a6 fc36e7cd
aa60 da84b21e f81b7ac9 b57fd16e f04040c1 6a89178e e0f634d1 d5649a4e c19adcf1
aa80 aabf81ce 83430cb1 5509b6ce 06f0ac31 aa136d9c 0de15862 5426db38 1bc2b0c4
aaa0 a84db670 37856188 509b6ce0 6f0ac310 a136d9c0 de158620 421b06d2 bc5db913
aac0 8440b8f6 78cdc775 088171ec f19b8eea 1174568a e341a887 229e1846 c6f5e45d
aae0 454a85de 8d9d7de9 8ae3beee 1b4c4e81 15c77ddc 36989d02 2b8efbb8 6d313a04
ab00 571df770 da627408 ae4d5bb2 b4b25d43 5cec0236 69120fd5 b9d8046c d2241faa
ab20 73c6bd8a a43e8a07 e7fbce46 480ba15d cff79c8c 901742ba 9f998c4a 20583027
ab40 3f331894 40b0604e 7e663128 8160c09c fcbad702 02b7346b f975ae04 056e68d6
ab60 f2eb5c08 0adcd1ac e5d6b810 15b9a358 cbad7020 2b7346b0 975ae040 56e68d60
ab80 2eb5c080 adcd1ac0 5d1d3452 5bec80d3 ba3a68a4 b7d901a6 7402641a 6fc4b61f
aba0 e804c834 df896c3e d07f253a bf646d2f a088ff26 7ebe6f0d 4111fe4c fd7cde1a
abc0 825549ca fa8f0967 04dc26c6 f568a79d 09cef8de eaa7fa69 13eb44ee d5394181
abe0 27a03c8e aa043651 4f36cc4e 547ed9f1 9e6d989c a8fdb3e2 3cad846a 518dd297
ac00 795b08d4 a31ba52e f2c0a4fa 4641ff0f e58149f4 8c83fe1e cb7426ba 1971496f
ac20 96e84d74 32e292de 2dd09ae8 65c525bc 5ba135d0 cb8a4b78 b734def2 976223a3
ac40 6e1f08b6 2eb2f215 dc3e116c 5d65e42a b87c22d8 bacbc854 708ef0e2 75e125fb
ac60 e11de1c4 ebc24bf6 c24d76da d7f222bf 84ec58e6 af92f02d 09ae049e 5f535509
ac80 135c093c bea6aa12 26cea72a 7d3be177 4d9d4e54 fa77c2ee 9b4c29fa f499308f
aca0 36eee6a6 e944d44d 6dab781e d2ff1dc9 db20456e a5888ec1 b6363f8e 4b67a8d1
acc0 6c6c7f1c 96cf51a2 d8ae4b6a 2de81617 b15c96d4 5bd02c2e 62b92da8 b7a0585c
ace0 c504ee02 6f3605eb 8a09dc04 de6c0bd6 14650d5a bcaea2ff 28bcafe6 792bf0ad
ad00 51795fcc f257e15a a2840aca e4d977e7 457ea0c6 c9c45a9d 8a8bf4de 93fe0069
ad20 15615cee 278ab581 2ac2b9dc 4f156b02 558573b8 9e2ad604 ab7c5222 3c23195b
ad40 56f8a444 784632b6 adf14888 f08c656c 5b942442 e16e7f8b b75efdd6 c2aa4a45
ad60 6ecb4efe 852221d9 dde028ae 0a32f6e1 bbc0515c 1465edc2 7780a2b8 28cbdb84
ad80 ef014570 5197b708 de028ae0 a32f6e10 bc73a092 46286973 78e74124 8c50d2e6
ada0 f1b8371a 18d7109f e3706e34 31ae213e c6e0dc68 635c427c 8dc1b8d0 c6b884f8
adc0 1bf5c4f2 8d07bca3 379d3cb6 1a79cc15 6f3a796c 34f3982a de74f2d8 69e73054
ade0 bce9e5b0 d3ce60a8 79a57e32 a7ea7403 f33c4936 4fa25d55 e678926c 9f44baaa
ae00 cc87918a 3effc007 990f2314 7dff800e 321e4628 fbff001c 644a3902 f788b56b
ae20 c8e2c756 ef67df85 91b33bfe deb90a59 2310c2ae bd04a1e1 4657300e 7a7ff691
ae40 8cae601c f4ffed22 192a756a e9896f17 32225f86 d3646b7d 64320a5e a6be63a9
ae60 c812a1ee 4d0a7201 902543dc 9a14e402 203c32ea 345f7d57 407865d4 68befaae
ae80 80f0cba8 d17df55c 01972202 a28d5feb 0358f156 456c0a85 06b1e2ac 8ad8150a
aea0 0d15700a 15c69f47 1a2ae014 2b8d3e8e 3455c028 571a7d1c 68ab8050 ae34fa38
aec0 d121b5f2 5c1f4123 a2436be4 b83e8246 44f0629a 700bb1df 89e0c534 e01763be
aee0 13b73f3a c058722f 2718cb26 80c6510d 4e47231e 01fa1749 9c8e463c 03f42e92
af00 391c8c78 07e85d24 723918f0 0fd0ba48 e47231e0 1fa17490 c8e463c0 3f42e920
af20 91c8c780 7e85d240 23918f00 fd0ba480 4755ab52 fa61fc53 8edde3f6 f4b54df5
af40 1dcd72be e91c2eb9 3bec502e d24ee821 77ae150e a4eb6511 ef2a9f4e 49a07f71
af60 de553e9c 9340fee2 bcdcc86a 26f74897 79b990d4 4dee912e f37321a8 9bdd225c
af80 e690f602 37ccf1eb cd21ec04 6f99e3d6 9a43d808 df33c7ac 34f10542 be113a0b
afa0 6994bfd6 7c54c145 d3297fac f8a9828a a6244a0a f125b047 4c3e2146 e23dd5dd
afc0 980af7de c40d1ee9 30635aee 886c8881 60b0008e 10afa451 c160011c 215f48a2
afe0 82c00238 42be9144 05800470 857d2288 0b76bdb2 0a8cf043 16ed7b64 1519e086
b000 2ddaf6c8 2a33c10c 5bb5ed90 54678218 b76bdb20 a8cf0430 6ea10312 51e8bd33
b020 dd420624 a3d17a66 baf2b91a 47d4419f 75e57234 8fa8833e ebbc513a 1f27b32f
b040 d778a274 3e4f665e aef144e8 7c9eccbc 5de289d0 f93d9978 bbb3a6f2 f20d87a3
b060 7711f8b6 e46dba15 ee55443e c8adc179 dcdc3d2e 912d37a1 b9cecf0e 222cda11
b080 739d9e1c 4459b422 e73b3c38 88b36844 ce00cd22 111065db 9c019a44 2220cbb6
b0a0 38033488 4441976c 70066910 88832ed8 e07a6772 1170e8e3 c0f4cee4 22e1d1c6
b0c0 81e99dc8 45c3a38c 03d33b90 8b874718 07d0c272 17783b63 0fa184e4 2ef076c6
b0e0 1f4309c8 5de0ed8c 3e861390 bbc1db18 7d7a9272 77f50363 faf524e4 efea06c6
b100 f59cfc9a dfa2b8df eb4f4c66 bf33c4ed d6e82d9e 7e113c89 add05b3c fc227912
b120 5bd6032a f8324777 b7dab306 f0123bbd 6fc3d35e e052c229 dff113ee c0d33101
b140 bf94928e 81d0d751 7f5f904e 03d71bf1 febf209c 07ae37e2 fd7e4138 0f5c6fc4
b160 fafc8270 1eb8df88 f5f904e0 3d71bf10 ebf209c0 7ae37e20 d7e41380 f5c6fc40
b180 afbe9252 ebfb4dd3 5f0b91f6 d7802ef5 be6196be af76e8b9 7cb5982e 5e9b6421
b1a0 f96b305c bd36c842 f2a0d5ea 7a1b25d7 e541abd4 f4364bae caf5e2fa e81a220f
b1c0 959d70a6 d042f14d 2b4c541e a0f357c9 56ee1d6e 41901ac1 addc3adc 83203582
b1e0 5bcec0ea 0636de57 b79d81d4 0c6dbcae 6f3b03a8 18db795c de760750 31b6f2b8
b200 bcec0ea0 636de570 79d81d40 c6dbcae0 f3c68fd2 8dc12093 e7fbaaf6 1bf4f475
b220 cff755ec 37e9e8ea 9feeabd8 6fd3d1d4 3fdd57b0 dfa7a3a8 7fcc1a32 bf39f203
b240 ffee8136 7e055155 ffdd026c fc0aa2aa ffccb18a f863f007 ffefd646 f0b1555d
b260 ffa919de e1141fe9 ff2486ee c25e8a81 fe3fb88e 84cba051 fc09c44e 09e1f5f1
b280 f813889c 13c3ebe2 f0271138 2787d7c4 e04e2270 4f0faf88 c09c44e0 9e1f5f10
b2a0 814e3c92 3c480b73 029c7924 789016e6 0538f248 f1202dcc 0a0751c2 e236eecb
b2c0 147816d6 c41b68c5 288698fe 884064d9 517b84ae 10f67ce1 a2f7095c 21ecf9c2
b2e0 45ee12b8 43d9f384 8bdc2570 87b3e708 17ceffb2 0f117b43 2f9dff64 1e22f686
b300 5f3bfec8 3c45ed0c be77fd90 788bda18 7ceffb20 f117b430 f9a94312 e259dd33
b320 f3243376 c4c50f35 e63ed3be 89fcab39 cc0b122e 138fe321 9816245c 271fc642
b340 302c48b8 4e3f8c84 60589170 9c7f1908 c0c797b2 38888743 818f2f64 71110e86
b360 031e5ec8 e2221d0c 064a08c2 c4328f4b 0ce2a4d6 8813abc5 19b3fcfe 1051e2d9
b380 3367f9fc 20a3c5b2 66cff3f8 41478b64 cd9fe7f0 828f16c8 9b497ab2 056898c3
b3a0 3692f564 0ad13186 6d25eac8 15a2630c da4bd590 2b44c618 b497ab20 56898c30
b3c0 692f5640 ad131860 d22819d2 5a508593 a45033a4 b4a10b26 48d6d21a 6934a31f
b3e0 91ada434 d269463e 232dfd3a a4a4392f 462d4f26 493ec70d 8c5a9e4c 927d8e1a
b400 18c389ca 248da967 31871394 491b52ce 630e2728 9236a59c c66afb02 241bfe6b
b420 8cd5f604 4837fcd6 19abec08 906ff9ac 33216d42 20a9460b 6642da84 41528c16
b440 cc85b508 82a5182c 997ddf42 053c850b 32fbbe84 0a790a16 65f77d08 14f2142c
b460 cbeefa10 29e42858 97ddf420 53c850b0 2fbbe840 a790a160 5f0165d2 4f57f793
b480 be02cba4 9eafef26 7c73221a 3d296b1f f8e64434 7a52d63e f1cc8868 f4a5ac7c
b4a0 e3efa582 e93dedab c7a9fe56 d20d6e05 8f2549fe a46c6959 1e3c26ae 48ae67e1
b4c0 3c784d5c 915ccfc2 78862fea 22cf2ad7 f10c5fd4 459e55ae e218bfa8 8b3cab5c
b4e0 c447ca02 160fe3eb 888f9404 2c1fc7d6 111f2808 583f8fac 223e5010 b07f1f58
b500 440a1572 60888be3 88142ae4 c11117c6 105ee09a 82549adf 20cb7466 04df80ed
b520 4196e8cc 09bf01da 832dd198 137e03b4 065ba330 26fc0768 0cb74660 4df80ed0
b540 196e8cc0 9bf01da0 32abacd2 37968e13 655759a4 6f2d1c26 caaeb348 de5a384c
b560 952bd3c2 bcc2c5cb 2a2112d6 79f33ec5 544225ac f3e67d8a a8f2fe0a e7ba4e47
b580 51934946 cf0229dd a35027de 9e72e6e9 46d6faee 3c937881 8dadf5dc 7926f102
b5a0 1b5bebb8 f24de204 36c16222 e4ed715b 6df47116 c9ac57e5 db9e577e 932e1a99
b5c0 b74a1bae 262a8061 6e94375c 4c5500c2 dd286eb8 98aa0184 ba266822 3122b65b
b5e0 744cd044 62456cb6 e899a088 c48ad96c d145f442 8963078b a2fd5dd6 12b0ba45
b600 45fabbac 2561748a 8bf57758 4ac2e914 17eaeeb0 9585d228 2fa36832 2b7d1103
b620 5f46d064 56fa2206 be8da0c8 adf4440c 7d6df4c2 5b9e3d4b fadbe984 b73c7a96
b640 f5c1665a 6e0e407f eb82ccb4 dc1c80fe d7732c3a b84fb4af ae90ed26 70e9dc0d
b660 5d21da4c e1d3b81a ba3501ca c3d1c567 741cb6c6 87d53f9d e84fd8de 0fdcca69
b680 d09fb1bc 1fb994d2 a13f6378 3f7329a4 427ec6f0 7ee65348 84fd8de0 fdcca690
b6a0 098dae92 fbeff873 136de876 f7a945b5 26ad65be ef243e39 4d2c7e2e de3ec921
b6c0 9a2e490e bc0b2711 342a274e 7860fb71 68544e9c f0c1f6e2 d0de286a e1f55897
b6e0 a1cae586 c39c047d 43e37e5e 874ebda9 87b049ee 0eebce01 0f6093dc 1dd79c02
b700 1ec127b8 3baf3804 3d824f70 775e7008 7b049ee0 eebce010 f67f8892 dd0f7573
b720 ec89a476 ba685fb5 d965fdbe 74a60a39 b2cbfb7c e94c1472 65e143aa d2ee9db7
b740 cbb43206 a5ab8e3d 971ed15e 4b21a929 2e3da2bc 96435252 5c0df02a 2cf011f7
b760 b81be054 59e023ee 7037c0a8 b3c047dc e0193402 67f63aeb c0326804 cfec75d6
b780 8012655a 9fae5eff 00527fe6 3f2a08ad 00a4ffcc 7e54115a 0149ff98 fca822b4
b7a0 02e54a62 f926f03b 05bc2196 f23b5525 0b0ef67e e4001f19 166b59ae c8768b61
b7c0 2ca0060e 909ba391 5936b94e 2141f271 b26d729c 4283e4e2 64dae538 8507c9c4
b7e0 c9c37f22 0a7926db 9386fe44 14f24db6 270dfc88 29e49b6c 4e1bf910 53c936d8
b800 9c37f220 a7926db0 38195112 4f526e33 7032a224 9ea4dc66 e013f11a 3d3f0d9f
b820 c027e234 7a7e1b3e 804fc468 f4fc367c 00e93d82 e98ed9ab 01a4ce56 d36b0605
b840 033f29fe a6a0b959 0608e6ae 4d37c7e1 0c11cd5c 9a6f8fc2 18552fea 34a9aad7
b860 30aa5fd4 695355ae 6154bfa8 d2a6ab5c c2dfca02 a53be3eb 85c92156 4a017285
b880 0b9242ac 9402e50a 1752300a 28737f47 2ea46014 50e6fe8e 5d48c028 a1cdfd1c
b8a0 bae73502 43ed4f6b 75ce6a04 87da9ed6 ebea615a 0fc388ff d7d4c2b4 1f8711fe
b8c0 afa98568 3f0e23fc 5f530ad0 7e1c47f8 bea615a0 fc388ff0 7d3a9e12 f807aab3
b8e0 fa038976 f079e035 f471a7be e0857539 e895fa2e c17c5f21 d15d410e 828e0b11
b900 a2cc374e 056aa371 45986e9c 0ad546e2 8b30dd38 15aa8dc4 1661ba70 2b551b88
b920 2cc374e0 56aa3710 5986e9c0 ad546e20 b37b66d2 5ade6913 66f6cda4 b5bcd226
b940 cd9b2e1a 6b0f111f 9b365c34 d61e223e 361a0d3a ac4af12f 6c42af26 58e3570d
b960 d8855e4c b1c6ae1a b17c09ca 63fbe967 62f81394 c7f7d2ce c586927a 8f9910cf
b980 8b7b91a6 1f4494cd 16f7234c 3e89299a 2dee4698 7d125334 5bdc8d30 fa24a668
b9a0 b7cfaf32 f43ff983 6fe9eb36 e8094655 dfa5633e d06439f9 bf3c732e a0bec6a1
b9c0 7e0e530e 410b3811 fc1ca61c 82167022 f84ff96a 045a5517 f09ff2d4 08b4aa2e
b9e0 e13fe5a8 1169545c c27fcb50 22d2a8b8 84ff96a0 45a55170 09ff2d40 8b4aa2e0
ba00 1388efd2 16e3f093 2711dfa4 2dc7e126 4e23bf48 5b8fc24c 9c477e90 b71f8498
ba20 38f84872 6e49bc63 71f090e4 dc9378c6 e397949a b95044df c7599c66 72d63ced
ba40 8eb338cc e5ac79da 1d10c4ca cb2e46e7 3a573cc6 962a389d 74d8ccde 2c22c469
ba60 e9b199bc 584588d2 d3633378 b08b11a4 a6b0d3a2 6160961b 4d61a744 c2c12c36
ba80 9ab5fbda 85f4ed3f 351d42e6 0b9f6f2d 6a3a85cc 173ede5a d4750b98 2e7dbcb4
baa0 a8ea1730 5cfb7968 51d42e60 b9f6f2d0 a3dee992 739b50f3 47bdd324 e736a1e6
bac0 8f0d131a ce1bf69f 1e6c9366 9c41586d 3caf939e 38f40589 795f273c 71e80b12
bae0 f2be4e78 e3d01624 e50a29a2 c7d6991b ca62e616 8fdb8765 94b3797e 1fc1bb99
bb00 2966f2fc 3f837732 52cde5f8 7f06ee64 a59bcbf0 fe0ddcc8 4b4122b2 fc6d0cc3
bb20 96f4f036 f8acacd5 2d9f553e f12fecf9 5b481f2e e2296ca1 b6e68b0e c4246c11
bb40 6dbba34e 883e6d71 db01f3ce 100a6fb1 b603e79c 2014df62 6c07cf38 4029bec4
bb60 d80f9e70 80537d88 b06989b2 00d04e43 60d31364 01a09c86 c1a626c8 0341390c
bb80 834c4d90 06827218 06989b20 0d04e430 0d313640 1a09c860 1a626c80 341390c0
bba0 34c4d900 68272180 6989b200 d04e4300 d365d152 a0ea3353 a6bd17f6 41a2d3f5
bbc0 4d7a2fec 8345a7ea 9a82ea8a 06fdfa87 3505d514 0dfbf50e 6a0baa28 1bf7ea1c
bbe0 d4175450 37efd438 a82ea8a0 6fdfa870 505d5140 dfbf50e0 a0cc17d2 bf081493
bc00 41ee9af6 7e669c75 83dd35ec fccd38ea 07ccde8a f9ecc487 0fef0846 f3af3c5d
bc20 1fa8a5de e728cde9 3f27feee ce272e81 7e39488e 9c38e851 fc04244e 380765f1
bc40 f808489c 700ecbe2 f0109138 e01d97c4 e0579722 c04d9adb c0d99b16 80ed80e5
bc60 81c5837e 01adb499 038b06fc 035b6932 07160df8 06b6d264 0e2c1bf0 0d6da4c8
bc80 1c5837e0 1adb4990 38b06fc0 35b69320 7160df80 6b6d2640 e2c1bf00 d6da4c80
bca0 c5f5cb52 adc22c53 8b9d23f6 5bf2edf5 173a47ec b7e5dbea 2e023a8a 6fbd0287
bcc0 5c047514 df7a050e b87e5f7a be82bf4f 708a0ba6 7d73cbcd e114174c fae7979a
bce0 c25e9bca f5b99a67 84cb82c6 eb05819d 09e1b0de d67db669 13b5d4ee ac8dd981
bd00 271d1c8e 596d0651 4e3a391c b2da0ca2 9c02c76a 65c2ac17 38058ed4 cb85582e
bd20 707da8fa 977c050f e08de4a6 2e8ebf4d c11bc94c 5d1d7e9a 82379298 ba3afd34
bd40 04199062 74034f3b 083320c4 e8069e76 1010f4da d07b89bf 20575ce6 a081a62d
bd60 40d80c9e 4175f909 81b0193c 82ebf212 0316872a 05a15177 062d0e54 0b42a2ee
bd80 0c5a1ca8 168545dc 18b43950 2d0a8bb8 316872a0 5a151770 62d0e540 b42a2ee0
bda0 c5d77fd2 6822e893 8baeffa4 d045d126 172b4a1a a0fd171f 2e202166 418c9b6d
bdc0 5c4042cc 831936da b8f630ca 0644d8e7 71ec6194 0c89b1ce e3d8c328 1913639c
bde0 c7b18650 3226c738 8f630ca0 644d8e70 1ec61940 c89b1ce0 3dfa87d2 91408c93
be00 7b83baf6 22f7ac75 f70775ec 45ef58ea ee0eebd8 8bdeb1d4 dc6b62e2 17cbd6fb
be20 b8d6c5c4 2f97adf6 71ad8b88 5f2f5bec e35b1710 be5eb7d8 c6c09b72 7ccbdae3
be40 8d8136e4 f997b5c6 1b74d89a f359dedf 369f0466 e6c508ed 6d48bd9e cdfca489
be60 dae7ce6e 9b8ffc41 b5b9298e 37694dd1 6b72531c 6ed29ba2 d6e4a638 dda53744
be80 adbff922 bb3cdbdb 5b094716 760f02e5 b6128e2c ec1e05ca 6c53a90a d84abec7
bea0 d8d1e746 b0e3c8dd b1d57bde 61b124e9 63aaf7bc c36249d2 c7235a2a 86b226f7
bec0 8e300106 0d12f8bd 1c60020c 1a25f17a 38c00418 344be2f4 71800830 6897c5e8
bee0 e3001060 d12f8bd0 c6769592 a229a2f3 8c9b9e76 4425f0b5 19373cec 884be16a
bf00 3218cc8a 10e17787 64319914 21c2ef0e c8633228 4385de1c 90c66450 870bbc38
bf20 21fa7df2 0e61cd23 43f4fbe4 1cc39a46 87e9f7c8 3987348c 0fd3ef90 730e6918
bf40 1fa7df20 e61cd230 3f390b12 cc4f1133 7e04a376 98e89735 fc7ff3be 31a79b39
bf60 f8ffe77c 634f3672 f1ffcef8 c69e6ce4 e38928a2 8d4a6c9b c764e416 1ae26c65
bf80 8ec9c82c 35c4d8ca 1d939058 6b89b194 3b2720b0 d7136328 7638f432 ae507303
bfa0 ec075d36 5cd65355 d80eba6c b9aca6aa b06bc18a 732ff807 60d78314 e65ff00e
bfc0 c1d9b37a ccc9554f 83c5d3a6 99e41fcd 07fd121e 33be8ac9 0ffa243c 677d1592
bfe0 1ff44878 cefa2b24 3f9e25a2 9d82e31b 7f4afe16 3b737365 fe95fc2c 76e6e6ca
c000 fd2bf858 edcdcd94 fa2145e2 dbed2e7b f4343e96 b7ace9a5 e81ec87e 6f2f6619
c020 d03d90fc de5ecc32 a00d94aa bccb2d37 406d9c06 79e0ef3d 80db380c f3c1de7a
c040 01c0c54a e7f509a7 03f73fc6 cf9ca61d 0798cade 9f4ff969 0f4720ee 3ee94781
c060 1e8e41dc 7dd28f02 3d1c83b8 fba51e04 7a4fb222 f73c895b f4e9d116 ee0fa7e5
c080 e9a5177e dc69fa99 d33c9bae b8a54061 a60f820e 713c3591 4c1f041c e2786b22
c0a0 9848bd6a c4866317 30e7cf86 897a737d 61b92a5e 128253a9 c37254bc 2504a752
c0c0 86e4a978 4a094ea4 0dc952f0 94129d48 1be410b2 28538fc3 37c82164 50a71f86
c0e0 6f9042c8 a14e3f0c df5630c2 42eacb4b beac6184 85d59696 7d2e765a 0bdd987f
c100 fa5cecb4 17bb30fe f4b9d968 2f7661fc e973b2d0 5eecc3f8 d2e765a0 bdd987f0
c120 a5b87e12 7bc5bab3 4b70fc24 f78b7566 96974d1a ef605f9f 2d582f66 deb60a6d
c140 5ac6eb9e bd1aa189 b5fb626e 7a43f641 6bf6c4dc f487ec82 d79b3cea e9796c57
c160 af40cc86 d2846dfd 5ef72c5e a57e6ea9 bd98edee 4a8a6801 7b31dbdc 9514d002
c180 f61502ea 2a5f1557 ec2a05d4 54be2aae d8540ba8 a97c555c b0dea202 528e1feb
c1a0 61bd4404 a51c3fd6 c30c3d5a 4a4ecaff 86187ab4 949d95fe 0c46403a 294d9eaf
c1c0 188c8074 529b3d5e 311900e8 a5367abc 6244b482 4a1a402b c4896904 94348056
c1e0 8964675a 281fb5ff 12c8ceb4 503f6bfe 25919d68 a07ed7fc 4b558f82 408b1aab
c200 96ab1f04 81163556 2d208b5a 025adfff 5a4116b4 04b5bffe b4822d68 096b7ffc
c220 69045ad0 12d6fff8 d208b5a0 25adfff0 a4116b40 4b5bffe0 4822d680 96b7ffc0
c240 90331852 2d194ad3 206630a4 5a3295a6 40cc6148 b4652b4c 81ee77c2 68bce3cb
c260 03dcef84 d179c796 07cf6a5a a2853a7f 0fe861e6 457cc1ad 1fd0c3cc 8af9835a
c280 3fd732ca 1585b3e7 7fae6594 2b0b67ce ff5ccb28 5616cf9c feb99650 ac2d9f38
c2a0 fd0599f2 582d8b23 fa0b33e4 b05b1646 f460d29a 60c099df e8c1a534 c18133be
c2c0 d1f5ff3a 8374d22f a39d4b26 069f110d 473a964c 0d3e221a 8e752c98 1a7c4434
c2e0 1cea5930 34f88868 39d4b260 69f110d0 73a964c0 d3e221a0 e7247cd2 a7b2f613
c300 ce3e4cf6 4f135975 9c7c99ec 9e26b2ea 388f868a 3c3bd087 711f0d14 7877a10e
c320 e23e1a28 f0ef421c c40a8102 e1a8316b 8863b756 c326d785 10b1dbfe 863b1a59
c340 211502ae 0c0081e1 422a055c 180103c2 84540ab8 30020784 08a81570 60040f08
c360 11502ae0 c0081e10 22d6e092 80668973 45db7476 00bba7b5 8bb6e8ec 01774f6a
c380 176dd1d8 02ee9ed4 2edba3b0 05dd3da8 5db74760 0bba7b50 bb6e8ec0 1774f6a0
c3a0 76dd1d80 2ee9ed40 edba3b00 5dd3da80 db747600 bba7b500 b69e5952 7739df53
c3c0 6d3cb2a4 ee73bea6 da0fd01a dc91c81f b4691566 b955256d 68a49f9e 72dcff89
c3e0 d1493f3c e5b9ff12 a2e4cb2a cb054b77 45bf2306 967c23bd 8b08f35e 2c8ef229
c400 1611e6bc 591de452 2c23cd78 b23bc8a4 58312fa2 6401241b b0625f44 c8024836
c420 60b20bda 9072253f c112a2e6 2092ff2d 822545cc 4125fe5a 044a8b98 824bfcb4
c440 08e3a262 04e14c3b 11c744c4 09c29876 238e8988 138530ec 471d1310 270a61d8
c460 8e3a2620 4e14c3b0 1c744c40 9c298760 389e2dd2 3825bb93 713c5ba4 704b7726
c480 e278b748 e096ee4c c487dbc2 c15b69cb 897902d6 82c066c5 1284b0fe 05f678d9
c4a0 250961fc 0becf1b2 4a12c3f8 17d9e364 942587f0 2fb3c6c8 284b0fe0 5f678d90
c4c0 50961fc0 becf1b20 a15a8ad2 7de88313 42b515a4 fbd10626 851c9e1a f7d4b91f
c4e0 0a4f8966 efdfc76d 14e9a79e dfc93b89 29a5fa6e bfe4c241 533d418e 7fbf31d1
c500 a67a831c ff7e63a2 4c83b36a fe8a7217 9971d386 fd62517d 3295125e fab217a9
c520 655c91ee f5129a01 cacf968e ea538151 95e9984e d4d1b7f1 2ba585ce a9d5dab1
c540 573dbece 53dd0031 ae7b7d9c a7ba0062 5c804e6a 4f02b597 b9009cd4 9e056b2e
c560 72778cfa 3c7c630f e4ef19f4 78f8c61e c9de33e8 f1f18c3c 93cad282 e395ad2b
c580 27e31056 c75def05 4fb095fe 8ecd6b59 9f179eae 1dec63e1 3e2f3d5c 3bd8c7c2
c5a0 7c5e7ab8 77b18f84 f8bcf570 ef631f08 f10f5fb2 deb08b43 e2680a36 bd17a3d5
c5c0 c4a6a13e 7a59f2f9 894d427c f4b3e5f2 12ec31aa e9117eb7 25aed606 d254483d
c5e0 4b2b195e a4de2529 962087ee 49caff01 2c410fdc 9395fe02 58f4aaea 275d4957
c600 b1e955d4 4eba92ae 63d2aba8 9d75255c c7d3e202 3a9cffeb 8fa7c404 7539ffd6
c620 1f4f8808 ea73ffac 3ee9a542 d4914a0b 7da5ffd6 a9542145 fb3d4afe 52def7d9
c640 f67a95fc a5bdefb2 ec839eaa 4b0d6a37 d9073d54 961ad46e b278cffa 2c431d8f
c660 64f19ff4 58863b1e c9e33fe8 b10c763c 93b0ca82 626e592b 27619504 c4dcb256
c680 4eb59f5a 89cfd1ff 9d1d8be6 13e916ad 3a3b17cc 27d22d5a 74762f98 4fa45ab4
c6a0 e8ec5f30 9f48b568 d1ae0b32 3ee7df83 a35c1664 7dcfbf06 46b82cc8 fb9f7e0c
c6c0 8d06ecc2 f748494b 1a7b6cd6 eee627c5 34806cfe ddbafad9 69766cae bb0340e1
c6e0 d29a6c0e 76703491 a534d81c ece06922 4a1f056a d9b66717 9448bf86 b31a7b7d
c700 28e7ca5e 664243a9 51cf94bc cc848752 a3e99c2a 997fbbf7 47a58d06 3289c2bd
c720 8f4b1a0c 6513857a 1e963418 ca270af4 3d5add62 9438a0bb 7ac30f96 2807f425
c740 f5861f2c 500fe84a eb0c3e58 a01fd094 d66ec9e2 4049147b acdd93c4 809228f6
c760 59cd92da 0152e4bf b39b25b4 02a5c97e 67364b68 054b92fc ce6c96d0 0a9725f8
c780 9cd92da0 152e4bf0 39b25b40 2a5c97e0 7364b680 54b92fc0 e6c96d00 a9725f80
c7a0 cde46f52 52920a53 9bc8dea4 a52414a6 37e7081a 4a3e9c1f 6fce1034 947d383e
c7c0 dfea953a 288cc52f bfd52a74 51198a5e 7faa54e8 a23314bc ff221c82 44109c2b
c7e0 fe443904 88213856 fcfec75a 1034c5ff f9fd8eb4 20698bfe f3fb1d68 40d317fc
c800 e7f63ad0 81a62ff8 cf9ac0f2 033aeaa3 9f3581e4 0675d546 3e6b03c8 0cebaa8c
c820 7cd60790 19d75518 f9ac0f20 33aeaa30 f3581e40 675d5460 e6b03c80 cebaa8c0
c840 cd16cc52 9d03e4d3 9a5b2df6 3a717cf5 34b65bec 74e2f9ea 696cb7d8 e9c5f3d4
c860 d2afdae2 d3fd52fb a5290096 a78c10a5 4a24b47e 4f6e9419 944968fc 9edd2832
c880 28e464aa 3dcce537 51c8c954 7b99ca6e a39192a8 f73394dc 47559002 ee119ceb
c8a0 8edd9556 dc558c85 1dcd9ffe b8ddac59 3bed8aae 71cdede1 77db155c e39bdbc2
c8c0 efc09fea c74102d7 dff78a86 8ef4b0fd bf99a05e 1d9fd4a9 7f3340bc 3b3fa952
c8e0 fe668178 767f52a4 fccd02f0 ecfea548 f9ecb0b2 d98bffc3 f3afd436 b3614ad5
c900 e7291d3e 66b420f9 ce523a7c cd6841f2 9cd2c1aa 9aa636b7 39d33606 353ad83d
c920 73a66c0c 6a75b07a e74cd818 d4eb60f4 ceef0562 a9a074bb 9da8bf96 53365c25
c940 3b517f2c a66cb84a 76d44b0a 4cafc5c7 eda89614 995f8b8e db27997a 32c9a24f
c960 b64f32f4 6593449e 6c9e65e8 cb26893c d94a7e82 963ba72b b2e24856 2c01fb05
c980 65c490ac 5803f60a cb892158 b007ec14 9764f7e2 60796d7b 2ec9efc4 c0f2daf6
c9a0 5de56ada 819300bf bbbc60e6 0350b42d 7778c1cc 06a1685a eef18398 0d42d0b4
c9c0 dde30730 1a85a168 bbc60e60 350b42d0 778c1cc0 6a1685a0 ef183980 d42d0b40
c9e0 de46c652 a82ca3d3 bcfb39f6 502ff2f5 79f673ec a05fe5ea f39a528a 40c97e87
ca00 e734a514 8192fd0e ce1fff7a 03534f4f 9c3ffef4 06a69e9e 387ffde8 0d4d3d3c
ca20 70fffbd0 1a9a7a78 e1fff7a0 3534f4f0 c3ffef40 6a69e9e0 87ffde80 d4d3d3c0
ca40 0f890852 a9d112d3 1f64a5f6 53d490f5 3ec94bec a7a921ea 7de4228a 4f24f687
ca60 fbc84514 9e49ed0e f7e63f7a 3ce56f4f efcc7ef4 79cade9e df98fde8 f395bd3c
ca80 bf474e82 e75dcf2b 7ef82856 cecd2b05 fd86e5fe 9dece359 fb7b7eae 3baf73e1
caa0 f6f6fd5c 775ee7c2 ededfab8 eebdcf84 dbad4022 dd0d2a5b b72c3516 ba6ce1e5
cac0 6e2edf7e 74af7699 dc5dbefc e95eed32 b8cdc8aa d2cb6f37 71ed2406 a5e06b3d
cae0 e3acfd5e 4bb66329 c759fabc 976cc652 8ec5402a 2eaf39f7 1d8a8054 5d5e73ee
cb00 3b1500a8 babce7dc 765cb402 750f7aeb ecb96804 ea1ef5d6 d904655a d44b5eff
cb20 b27e7fe6 a8e008ad 648a4a9e 51b6a409 c914953c a36d4812 925f9f2a 46ac2577
cb40 24bf3e54 8d584aee 4908c9fa 1ac6208f 921193f4 358c411e 242327e8 6b18823c
cb60 48464fd0 d6310478 90fa2af2 ac14bda3 2182e0b6 585fce15 4305c16c b0bf9c2a
cb80 867d378a 61098d07 0cfa6f14 c2131a0e 19826b7a 8450814f 337263a6 08d7b7cd
cba0 66e4c74c 11af6f9a cdc98e98 235edf34 9b931d30 46bdbe68 37263a60 8d7b7cd0
cbc0 6e3ac192 1a804cf3 dc758324 350099e6 b8eb0648 6a0133cc 71d60c90 d4026798
cbe0 e3daac72 a8727a63 c7c3edb6 50924195 8f87db6c a124832a 1f79038a 423fb307
cc00 3ef20714 847f660e 7d92bb7a 0888794f fb2576f4 1110f29e f64aede8 2221e53c
cc20 ec95dbd0 4443ca78 d92bb7a0 888794f0 b221da12 11799cb3 6443b424 22f33966
cc40 c8876848 45e672cc 910ed090 8bcce598 226b1472 17ef7e63 44d628e4 2fdefcc6
cc60 89ac51c8 5fbdf98c 1358a390 bf7bf318 26c7f272 7e815363 4d8fe4e4 fd02a6c6
cc80 9b697c9a fa73f8df 36a44c66 f49144ed 6d3e2d9e e9543c89 da0aee6e d2decc41
cca0 b463698e a5cb2dd1 68b0664e 4be0eef1 d160cc9c 97c1dde2 a2b72c6a 2ff50e97
ccc0 456e58d4 5fea1d2e 8adcb1a8 bfd43a5c 15cfd602 7fdec1eb 2b9fac04 ffbd83d6
cce0 5749ed5a ff0db2ff aee56fe6 fe6dd0ad 5dbc6a9e fcad1409 bb0e606e f92c9d41
cd00 766a758e f22f8fd1 eca25e4e e429aaf1 d93209ce c825e0b1 b212a6ce 903d7431
cd20 6453f8ce 200c5d31 c8a7f19c 4018ba62 914fe338 803174c4 22e97322 00145cdb
cd40 45d2e644 0028b9b6 8ba5cc88 0051736c 174b9910 00a2e6d8 2e973220 0145cdb0
cd60 5d2e6440 028b9b60 ba5cc880 051736c0 74b99100 0a2e6d80 e9732200 145cdb00
cd80 d2e64400 28b9b600 a5cc8800 51736c00 4b991000 a2e6d800 97449552 45bb0553
cda0 2e892aa4 8b760aa6 5d64e01a 169aa01f bac9c034 2d35403e 75938068 5a6a807c
cdc0 eb2700d0 b4d500f8 d638b4f2 69dcb4a3 ac7169e4 d3b96946 5894669a a70467df
cde0 b15e7866 4e7e7aed 62bcf0cc 9cfcf5da c50f54ca 398f5ee7 8a1ea994 731ebdce
ce00 143d5328 e63d7b9c 280c1302 cc0c426b 506e9356 986e3185 a0ab93fe 30aad659
ce20 415727fc 6155acb2 82ae4ff8 c2ab5964 052a2aa2 8520079b 0a22e016 0a36ba65
ce40 1445c02c 146d74ca 288b8058 28dae994 511700b0 51b5d328 a22e0160 a36ba650
ce60 442ab792 46a1f9f3 88556f24 8d43f3e6 10dc6b1a 1af1529f 21b8d634 35e2a53e
ce80 4371ac68 6bc54a7c 86e358d0 d78a94f8 0db004f2 af639ca3 1b16bcb6 5eb18c15
cea0 362d796c bd63182a 6c2c478a 7ab08507 d8588f14 f5610a0e b0c7ab7a eab4a14f
cec0 61f9e3a6 d51ff7cd c385721e aa495ac9 877c516e 54e400c1 0ef8a2dc a9c80182
cee0 1d87f0ea 53e6b657 3b0fe1d4 a7cd6cae 766976fa 4fec6c0f ecd2edf4 9fd8d81e
cf00 d9d36eba 3fc7056f b3a6dd74 7f8e0ade 674dbae8 ff1c15bc ceedc082 fe4e9e2b
cf20 9dad3456 fceb8905 3b2cddfe f9a1a759 762f0eae f335fbe1 ec28a80e e61d4291
cf40 d827e54e cc4c3071 b0397fce 98eed5b1 60044ace 31ab1e31 c008959c 63563c62
cf60 80112b38 c6ac78c4 0054e322 8d2e44db 00df7316 1a2a3ce5 01bee62c 345479ca
cf80 037dcc58 68a8f394 06fb98b0 d151e728 0d818432 a2d57b03 1b75bd36 45dc4355
cfa0 36eb7a6c 8bb886aa 6da0418a 1707b807 db408314 2e0f700e b6810628 5c1ee01c
cfc0 6d020c50 b83dc038 da72adf2 700d3523 b4e55be4 e01a6a46 69bc029a c04261df
cfe0 d30eb066 80f276ed a66bd59e 01925889 4cd7ab3c 0324b112 99af5678 06496224
d000 335eacf0 0c92c448 66bd59e0 19258890 cd7ab3c0 324b1120 9af56780 64962240
d020 35eacf00 c92c4480 6ba32b52 922e3c53 d730e3f6 242acdf5 ae61c7ec 48559bea
d040 5cc38fd8 90ab37d4 b9f1aae2 2120dafb 73e355c4 4241b5f6 e7c6ab88 84836bec
d060 cffbe242 0970628b 9ff7c484 12e0c516 3fef8908 25c18a2c 7fdf1210 4b831458
d080 ffbe2420 970628b0 ff0afd12 2e7ae433 fe15fa24 5cf5c866 fc2bf448 b9eb90cc
d0a0 f8215dc2 73a194cb f042bb84 e7432996 e0f3c25a cef0e67f c19131e6 9d9779ad
d0c0 8354d69e 3b584609 06a9ad3c 76b08c12 0d535a78 ed611824 1ad001a2 dab4851b
d0e0 35d6b616 b51fbf65 6bdbd97e 6a49cb99 d7b7b2fc d4939732 af19d0aa a9519b37
d100 5e451406 52d5833d bc8a280c a5ab067a 7962e54a 4b20b9a7 f2c5ca94 9641734e
d120 e5fd207a 2cf453cf cbfa40f4 59e8a79e 97f481e8 b3d14f3c 2f9fb682 67d42b2b
d140 5f3f6d04 cfa85656 be086f5a 9f2619ff 7c666be6 3e3a86ad f8ccd7cc 7c750d5a
d160 f199af98 f8ea1ab4 e345ea62 f1a2803b c6fd6196 e333b525 8d8c767e c611df19
d180 1b6e59ae 8c550b61 36aa060e 18dca391 6d540c1c 31b94722 daa81838 63728e44
d1a0 b5503070 c6e51c88 6ad6d5b2 8dbc8c43 d5db1e36 1b0fadd5 abb63c6c 361f5baa
d1c0 576c78d8 6c3eb754 aed8f1b0 d87d6ea8 5dc75632 b08c6803 bbf81936 616e6555
d1e0 77f0326c c2dccaaa ef96d18a 85cf2007 df5b1646 0be8f55d beb62c8c 17d1eaba
d200 7d6c5918 2fa3d574 fad8b230 5f47aae8 f5b16460 be8f55d0 eb147d92 7d681ef3
d220 d628fb24 fad03de6 ac27431a f5d6ce9f 58383366 ebdb286d b006d39e d7c0e589
d240 607b126e aff77e41 c080918e 5f9849d1 8101231c bf3093a2 0274f36a 7e179217
d260 04e9e6d4 fc2f242e 09a578fa f828fd0f 133c44a6 f0274f4d 260e3c1e e0382bc9
d280 4c6acd6e c006e2c1 98a32f8e 807b70d1 3130ea4e 008054f1 6261d49c 0100a9e2
d2a0 c4c3a938 020153c4 89875270 0402a788 130ea4e0 08054f10 261d49c0 100a9e20
d2a0 c4c3a938 020153c4 89875270 0402a788 130ea4e0 08054f10 261d49c0 100a9e20
d2c0 4c3a9380 20153c40 98752700 402a7880 30ea4e00 8054f100 61a22952 00df5753
d2e0 c34452a4 01beaea6 8688a548 037d5d4c 0d114a90 06faba98 1a229520 0df57530
d300 34452a40 1beaea60 688a5480 37d5d4c0 d114a900 6faba980 a2295200 df575300
d320 44241152 bed81353 883e97f6 7dc693f5 107d2fec fb8d27ea 208cea8a f76cfa87
d340 416f6046 eeaf405d 82a875de dd2835e9 05265eee ba26de81 0a3a088e 743b0851
d360 1474111c e87610a2 289e976a d09a9417 514b9b86 a1439d7d a2e1825e 42f18fa9
d380 45c304bc 85e31f52 8bf0bc2a 0bb08bf7 17e17854 176117ee 2fc2f0a8 2ec22fdc
d3a0 5f85e150 5d845fb8 bf0bc2a0 bb08bf70 7e613012 7667cbb3 fcc26024 eccf9766
d3c0 f9f2751a d9e99b9f f3925f66 b3a5826d e7520b9e 673db189 cea4173c ce7b6312
d3e0 9d3e9b2a 9c807377 3a0b8306 397653bd 7417060c 72eca77a e82e0c18 e5d94ef4
d400 d02aad62 cbc428bb a023ef96 97fee425 40316a7e 2f8b7d19 8062d4fc 5f16fa32
d420 00c5a9f8 be2df464 01fde6a2 7c2d5d9b 03fbcd44 f85abb36 07812fda f0c3c33f
d440 0f74eae6 e1f1332d 1e9f609e c394d309 3d48746e 875f1341 7ae65d8e 0ec893d1
d460 f5ccbb1c 1d9127a2 eb997638 3b224f44 d732ec70 76449e88 ae65d8e0 ec893d10
d480 5cbd0492 d964cf73 b90cbc76 b2bf2bb5 726fcdbe 6508e239 e4df9b7c ca11c472
d4a0 c9c983aa 94553db7 93e5b206 28dcce3d 27cb640c 51b99c7a 4f96c818 a37338f4
Kernel Fault: Code=3D15 regs=3D1031d4c0 (Addr=3D40000004)
YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
PSW: 00000000000001000000000000001110 Not tainted
r00-03 00000000 1032d810 1010479c 40000000
r04-07 102db000 40000000 400001c0 00108024
r08-11 00000000 00000000 fffa0000 1032d810
r12-15 000000f2 000000fa 000000fd f0100000
r16-19 1031d080 f0000124 f000011c 00000000
r20-23 1032d810 00001a31 00000000 000003a8
r24-27 00000001 00000001 1032db40 1031a010
r28-31 00000030 ffffffff 1031d4c0 00000040
sr0-3 00000000 00000000 00000000 00000000
sr4-7 00000000 00000000 00000000 00000000
IASQ: 00000000 00000000 IAOQ: 10104168 1010416c
IIR: 0c681097 ISR: 00000000 IOR: 40000004
CPU: 0 CR30: 2fff8000 CR31: 103d8000
ORIG_R28: f1900000
But with vmlinux64 instead:
Command line for kernel: 'ramdisk_size=3D8192 root=3D/dev/ram console=3Dtty=
S0
TERM=3Dvt102 palo_kernel=3D0/vmlinux64'
Selected kernel: /vmlinux64 from partition 0
Selected ramdisk: /ramdisk from partition 0
ELF64 executable
Entry 00100000 first 00100000 n 3
Segment 0 load 00100000 size 2845920 mediaptr 0x1000
Segment 1 load 003b8000 size 1321912 mediaptr 0x2b8000
Segment 2 load 004fc000 size 49152 mediaptr 0x3fb000
Loading ramdisk 2662244 bytes @ 1fd63000...
Branching to kernel entry point 0x00100000. If this is the last
message you see, you may need to switch your console. This is
a common symptom -- search the FAQ and mailing list at parisc-linux.org
Linux version 2.4.19-64 (root@mkhppa3) (gcc version 3.0) #1 Sun Sep 22 16:1=
5:57 CEST 2002
FP[0] enabled: Rev 0 Model 14
The 64-bit Kernel has started...
Determining PDC firmware type: System Map.
model 00005a40 00000491 00000000 00000002 575b550e 100000f0 00000008 000000=
b2 000000b2
vers 00000205
CPUID vers 14 rev 9 (0x000001c9)
capabilities 0x3
model 9000/802/K250
Total Memory: 511 Mb
initrd: 2fd63000-2ffecf64
initrd: reserving 1fd63000-1ffecf64 (mem_max 1fffe000)
pagetable_init
On node 0 totalpages: 131070
zone(0): 131070 pages.
zone(1): 0 pages.
zone(2): 0 pages.
Kernel command line: ramdisk_size=3D8192 root=3D/dev/ram console=3DttyS0 TE=
RM=3Dvt102
palo_kernel=3D0/vmlinux64
Console: colour dummy device 160x64
Calibrating delay loop... 319.48 BogoMIPS
Memory: 504904k available
Dentry cache hash table entries: 65536 (order: 8, 1048576 bytes)
Inode cache hash table entries: 32768 (order: 7, 524288 bytes)
Mount-cache hash table entries: 8192 (order: 5, 131072 bytes)
Buffer-cache hash table entries: 32768 (order: 6, 262144 bytes)
Page-cache hash table entries: 131072 (order: 8, 1048576 bytes)
Searching for devices...
Found devices:
1. U2-IOA BC Runway Port (12) at 0xfffffffffff88000 [8], versions 0x580, 0x=
f, 0xb
2. U2-IOA BC GSC+ Port (7) at 0xfffffffff103f000 [8/63], versions 0x501, 0x=
1, 0xc
3. U2-IOA BC Runway Port (12) at 0xfffffffffff8a000 [10], versions 0x580, 0=
xf, 0xb
4. Mohawk Core FW-SCSI (4) at 0xfffffffff1800000 [10/0], versions 0x44, 0x0=
, 0x89
5. Gecko BOA BC GSC+ Port (7) at 0xfffffffff1804000 [10/4], versions 0x500,=
0x0, 0xc
6. Sahp Baat Kiuh AP/MUX (5) at 0xfffffffff1900000 [10/4/0], versions 0x44,=
0x0, 0xd
7. Interphase NIO-100BaseTX (4) at 0xfffffffff1908000 [10/4/8], versions 0x=
4, 0x0, 0x382
8. Skunk SCSI (28655A) (4) at 0xfffffffff1910000 [10/4/16], versions 0x4, 0=
x0, 0x39
9. Skunk Centronics (28655A) (5) at 0xfffffffff1911000 [10/4/17], versions =
0x4, 0x0, 0x3a
10. Gecko BOA BC HP-PB Port (7) at 0xfffffffff193c000 [10/4/60], versions 0=
x103, 0x0, 0xc
11. Mohawk Core BA (11) at 0xffffffffffd00000 [10/12], versions 0x44, 0x0,
0x81, additional addresses: 0xffffffffffd0c000 0xffffffffffc00000
12. Mohawk Core Centronics (10) at 0xffffffffffd02000 [10/12/0], versions 0=
x44,
0x0, 0x74, additional addresses: 0xffffffffffd01000 0xffffffffffd03000
13. Mohawk Core SCSI (10) at 0xffffffffffd06000 [10/12/5], versions 0x44, 0=
x0, 0x82
14. Mohawk Core LAN (802.3) (10) at 0xffffffffffd07000 [10/12/6], versions =
0x44, 0x0, 0x8a
15. Mohawk Core PS/2 Port (10) at 0xffffffffffd08000 [10/12/7], versions 0x=
44, 0x0, 0x84
16. Mohawk Core PS/2 Port (10) at 0xffffffffffd08100 [10/12/8], versions 0x=
44, 0x0, 0x84
17. U2-IOA BC GSC+ Port (7) at 0xfffffffff183f000 [10/63], versions 0x501, =
0x1, 0xc
18. Mohawk 160 U 1M DC3- (K250) (0) at 0xfffffffffffa0000 [32], versions 0x=
5a4, 0x0, 0x4
19. Memory (1) at 0xfffffffffffb1000 [49], versions 0x53, 0x0, 0x9
CPU(s): 1 x PA8000 (PCX-U) at 160.000000 MHz
Found U2 at 0xfffffffffff88000
ccio-dma.c: failed to claim CCIO bus address space (ffffffff00000000,ffffff=
ffffffffff)
Found U2 at 0xfffffffffff8a000
Lasi version 0 at 0xffffffffffd00000 found.
LED display at ffffffffffd0c000 registered
POSIX conformance testing by UNIFIX
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Initializing RT netlink socket
Soft power switch support not available.
Performance monitoring counters enabled for Mohawk 160 U 1M DC3- (K250)
Starting kswapd
Journalled Block Device driver loaded
Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
parport_init_chip: enhanced parport-modes not supported.
parport0: PC-style at 0xffffffffffd02800, irq 184 [PCSPP]
STI GSC/PCI graphics driver version 0.9
pty: 256 Unix98 ptys configured
Serial driver version 5.05c (2001-07-08) with MANY_PORTS SHARE_IRQ SERIAL_P=
CI enabled
WARNING! Stack pointer and cr30 do not correspond!
Dumping virtual address stack instead
Dumping Stack from 0x000000003fff0000 to 0x000000003fff0d80:
WARNING! Stack pointer and cr30 do not correspond!
Dumping virtual address stack instead
Dumping Stack from 0x000000003fff0000 to 0x000000003fff1440:
Dumping Stack from 0x000000003fff0000 to 0x000000003fff1b00:
Dumping Stack from 0x000000003fff0000 to 0x000000003fff21c0:
Dumping Stack from 0x000000003fff0000 to 0x000000003fff2880:
Dumping Stack from 0x000000003fff0000 to 0x000000003fff2f40:
Dumping Stack from 0x000000003fff0000 to 0x000000003fff3600:
Dumping Stack from 0x000000003fff0000 to 0x000000003fff3cc0:
Dumping Stack from 0x000000003fff0000 to 0x000000003fff4380:
Dumping Stack from 0x000000003fff0000 to 0x000000003fff4a40:
Dumping Stack from 0x000000003fff0000 to 0x000000003fff5100:
Dumping Stack from 0x000000003fff0000 to 0x000000003fff57c0:
Dumping Stack from 0x000000003fff0000 to 0x000000003fff5e80:
Dumping Stack from 0x000000003fff0000 to 0x000000003fff6540:
Dumping Stack from 0x000000003fff0000 to 0x000000003fff6c00:
Dumping Stack from 0x000000003fff0000 to 0x000000003fff72c0:
Dumping Stack from 0x000000003fff0000 to 0x000000003fff7980:
Dumping Stack from 0x000000003fff8000 to 0x000000003fff8040:
Dumping Stack from 0x000000003fff8000 to 0x000000003fff8700:
Dumping Stack from 0x000000003fff8000 to 0x000000003fff8dc0:
Dumping Stack from 0x000000003fff8000 to 0x000000003fff9480:
Dumping Stack from 0x000000003fff8000 to 0x000000003fff9b40:
Dumping Stack from 0x000000003fff8000 to 0x000000003fffa200:
Dumping Stack from 0x000000003fff8000 to 0x000000003fffa8c0:
Dumping Stack from 0x000000003fff8000 to 0x000000003fffaf80:
Dumping Stack from 0x000000003fff8000 to 0x000000003fffb640:
Dumping Stack from 0x000000003fff8000 to 0x000000003fffbd00:
Dumping Stack from 0x000000003fff8000 to 0x000000003fffc3c0:
Dumping Stack from 0x000000003fff8000 to 0x000000003fffca80:
WARNING! Stack pointer and cr30 do not correspond!
Dumping virtual address stack instead
Dumping Stack from 0x000000003fff8000 to 0x000000003fffd140:
2D10L
fLT CBF0C1D2D10L
FLT 5002C1D2D10L
FLT 7D03C1D2D10L
FLT 5408C1D2D10L
FLT 5508C1D2D10L
FLT CBF4C1D2D10L
FLT CBFCC1D2D10L
FLT CBF0C1D2D10L
FLT 5002C1D2D10L
FLT 7D03C1D2D10L
(loops forever)
The stack dumps are similar with the other images.
Any ideas..? :=3D)
--=20
Stian S=F8iland Work toward win-win situation. Win-lose
ITEA systemdrift is where you win and the other lose.
http://www.stud.ntnu.no/ Lose-lose and lose-win are left as an
exercise to the reader. [Limoncelli/Hogan]
From rbradetich@uswest.net Mon Sep 30 21:19:51 2002
From: rbradetich@uswest.net (Ryan Bradetich)
Date: 30 Sep 2002 14:19:51 -0600
Subject: [parisc-linux] 9000/802/K250 won't boot with images -
serial/stack problem?
In-Reply-To: <20020930200805.GA9133@itea.ntnu.no>
References: <20020930200805.GA9133@itea.ntnu.no>
Message-ID: <1033417191.31126.4.camel@beavis>
> The serial console is connected to 'CONSOLE (X/4/0/0)*',
This is good, see .. we even find the device :)
> 6. Sahp Baat Kiuh AP/MUX (5) at 0xf1900000 [10/4/0], versions 0x44,
0x0, 0xd
> Command line for kernel: 'ramdisk_size=8192 root=/dev/ram console=ttyS0
Oops... this is bad. The K class systems do not have a 16550 compatible
serial port. The console should be ttyB0.
For mor info on the console, see Matthew's excellent description of what
systems use the Serial Mux driver.
http://lists.parisc-linux.org/pipermail/parisc-linux/2002-September/017837.html
Thanks,
- Ryan
From willy@debian.org Mon Sep 30 21:39:12 2002
From: willy@debian.org (Matthew Wilcox)
Date: Mon, 30 Sep 2002 21:39:12 +0100
Subject: [parisc-linux] 9000/802/K250 won't boot with images - serial/stack problem?
In-Reply-To: <1033417191.31126.4.camel@beavis>; from rbradetich@uswest.net on Mon, Sep 30, 2002 at 02:19:51PM -0600
References: <20020930200805.GA9133@itea.ntnu.no> <1033417191.31126.4.camel@beavis>
Message-ID: <20020930213912.S18377@parcelfarce.linux.theplanet.co.uk>
On Mon, Sep 30, 2002 at 02:19:51PM -0600, Ryan Bradetich wrote:
> For mor info on the console, see Matthew's excellent description of what
> systems use the Serial Mux driver.
>
> http://lists.parisc-linux.org/pipermail/parisc-linux/2002-September/017837.html
FWIW, the hwdb is now updated to reflect this. Thanks, Thibaut!
--
Revolutions do not require corporate support.
From stain@itea.ntnu.no Mon Sep 30 21:45:59 2002
From: stain@itea.ntnu.no (Stian Soiland)
Date: Mon, 30 Sep 2002 22:45:59 +0200
Subject: [parisc-linux] 9000/802/K250 won't boot with images - serial/stack problem?
In-Reply-To: <1033417191.31126.4.camel@beavis>
References: <20020930200805.GA9133@itea.ntnu.no> <1033417191.31126.4.camel@beavis>
Message-ID: <20020930204559.GB9133@itea.ntnu.no>
On 2002-09-30 22:19:51, Ryan Bradetich wrote:
> > The serial console is connected to 'CONSOLE (X/4/0/0)*',=20
> This is good, see .. we even find the device :)
> > 6. Sahp Baat Kiuh AP/MUX (5) at 0xf1900000 [10/4/0], versions 0x44,
> 0x0, 0xd
> > Command line for kernel: 'ramdisk_size=3D8192 root=3D/dev/ram console=
=3DttyS0
> Oops... this is bad. The K class systems do not have a 16550 compatible
> serial port. The console should be ttyB0.
> For mor info on the console, see Matthew's excellent description of what
> systems use the Serial Mux driver.
> http://lists.parisc-linux.org/pipermail/parisc-linux/2002-September/01783=
7.html
Aha! :=3D)
But with:
Command line for kernel: 'ramdisk_size=3D8192 root=3D/dev/ram console=3Dtty=
B0
TERM=3Dvt102 palo_kernel=3D0/vmlinux'
(..)
Branching to kernel entry point 0x00100098. If this is the last
message you see, you may need to switch your console. This is
a common symptom -- search the FAQ and mailing list at parisc-linux.org
And that IS the last thing I see :/
with console=3DttyS0 at least more output came. How do I 'switch console'?=
=20
Do I need to connect something to this MDP-port instead?
(how? It is some inverted rs232 15-pin)
This happens with both vmlinux32 og 64.
--=20
Stian S=F8iland There are only 10 types of people in the worl=
d:
ITEA systemdrift Those who understand binary, and those who don'=
t.
http://www.stud.ntnu.no/ =20
=20
From Frank.Cornelis@rug.ac.be Mon Sep 30 21:50:17 2002
From: Frank.Cornelis@rug.ac.be (Frank Cornelis)
Date: Mon, 30 Sep 2002 22:50:17 +0200 (MEST)
Subject: [parisc-linux] firmware update using BOOTP
In-Reply-To: <1033395024.454.3.camel@seventy>
Message-ID: <Pine.GSO.4.31.0209302241060.16124-100000@eduserv.rug.ac.be>
> most of my 712's are ver 1.9 or 2.1 & they all work fine as far as i can
> see with linux - is there any advantage to updating to 2.3 ?
>
> or is this a case of 'if its not broken....'
The text file that comes with the 2.3 patch mentions
More reliable LAN operation
as one of the improvements. I wanted to be sure for my BOOTP lifimage
loading.
Anyway, it's really easy to do.
Create an /etc/bootptab on your server containing:
.default:\
:sm=255.255.255.224:\
:gw=192.168.1.62:\
:ds=195.130.131.2:\
:ht=ethernet:\
:bf=C7120023.frm:
hp712:hn:ha=0800099D56DA:ip=192.168.1.34:tc=.default
Of course, adjust with your network settings (man bootptab).
Run the bootpd daemon (and tftp daemon) on your server and reboot your HP.
Then goto the BOOT_ADMIN menu using ESC and type:
search lan
You should see your BOOTP server listed.
Then simply do:
boot lan
That's it.
Frank.
From james@compusmithllc.com Mon Sep 30 21:56:19 2002
From: james@compusmithllc.com (James Smith)
Date: 30 Sep 2002 15:56:19 -0500
Subject: [parisc-linux] firmware update using BOOTP
In-Reply-To: <Pine.GSO.4.31.0209302241060.16124-100000@eduserv.rug.ac.be>
References: <Pine.GSO.4.31.0209302241060.16124-100000@eduserv.rug.ac.be>
Message-ID: <1033419379.4785.33.camel@seventy>
i installed all my 712's from bootp without upgrading & they went fine -
even the ones with the 1.9 firmwares
have you got a pointer to the firmware update info so i can check it out
the pros/cons myself ?
James S
On Mon, 2002-09-30 at 15:50, Frank Cornelis wrote:
>
> > most of my 712's are ver 1.9 or 2.1 & they all work fine as far as i can
> > see with linux - is there any advantage to updating to 2.3 ?
> >
> > or is this a case of 'if its not broken....'
>
> The text file that comes with the 2.3 patch mentions
> More reliable LAN operation
> as one of the improvements. I wanted to be sure for my BOOTP lifimage
> loading.
> Anyway, it's really easy to do.
> Create an /etc/bootptab on your server containing:
> .default:\
> :sm=255.255.255.224:\
> :gw=192.168.1.62:\
> :ds=195.130.131.2:\
> :ht=ethernet:\
> :bf=C7120023.frm:
>
> hp712:hn:ha=0800099D56DA:ip=192.168.1.34:tc=.default
>
> Of course, adjust with your network settings (man bootptab).
> Run the bootpd daemon (and tftp daemon) on your server and reboot your HP.
> Then goto the BOOT_ADMIN menu using ESC and type:
> search lan
> You should see your BOOTP server listed.
> Then simply do:
> boot lan
>
> That's it.
>
> Frank.
>
From rbradetich@uswest.net Mon Sep 30 22:06:29 2002
From: rbradetich@uswest.net (Ryan Bradetich)
Date: 30 Sep 2002 15:06:29 -0600
Subject: [parisc-linux] 9000/802/K250 won't boot with images -
serial/stack problem?
In-Reply-To: <20020930204559.GB9133@itea.ntnu.no>
References: <20020930200805.GA9133@itea.ntnu.no>
<1033417191.31126.4.camel@beavis> <20020930204559.GB9133@itea.ntnu.no>
Message-ID: <1033419990.30622.11.camel@beavis>
Ah,
I am sorry. I see the problem now :)
The problem is that /dev/ttyB0 does not have a registered major/minor
number. We use a local on for the parisc-linux kernel. Since we
/dev/ttyB0 is non-standard, the regular boot floppy from debian will
not boot this box. I would suggest getting on from the ESIEE
team provides at:
http://pateam.esiee.fr/cd-images/testing/
Specifically the images you are looking for have the -PDC in the name.=20
These kernels have the PDC Software Console enabled (which will work for
your system).
Thanks,
- Ryan
P.S. What would it take to get the default debian configs to compile in
the the Serial Mux, and to provide the /dev/ttyB0 from the parisc-linux
port by default in debian? A patch to the debian def_configs and the
MAKEDEV package?
On Mon, 2002-09-30 at 14:45, Stian Soiland wrote:
> On 2002-09-30 22:19:51, Ryan Bradetich wrote:
>=20
> > > The serial console is connected to 'CONSOLE (X/4/0/0)*',=20
> > This is good, see .. we even find the device :)
> > > 6. Sahp Baat Kiuh AP/MUX (5) at 0xf1900000 [10/4/0], versions 0x44,
> > 0x0, 0xd
> > > Command line for kernel: 'ramdisk_size=3D8192 root=3D/dev/ram console=
=3DttyS0
> > Oops... this is bad. The K class systems do not have a 16550 compatibl=
e
> > serial port. The console should be ttyB0.
> > For mor info on the console, see Matthew's excellent description of wha=
t
> > systems use the Serial Mux driver.
> > http://lists.parisc-linux.org/pipermail/parisc-linux/2002-September/017=
837.html
>=20
> Aha! :=3D)
>=20
> But with:
>=20
> Command line for kernel: 'ramdisk_size=3D8192 root=3D/dev/ram console=3Dt=
tyB0
> TERM=3Dvt102 palo_kernel=3D0/vmlinux'
>=20
> (..)
>=20
> Branching to kernel entry point 0x00100098. If this is the last
> message you see, you may need to switch your console. This is
> a common symptom -- search the FAQ and mailing list at parisc-linux.org
>=20
>=20
> And that IS the last thing I see :/
>=20
> with console=3DttyS0 at least more output came. How do I 'switch console'=
?=20
>=20
>=20
> Do I need to connect something to this MDP-port instead?
> (how? It is some inverted rs232 15-pin)
>=20
> This happens with both vmlinux32 og 64.
>=20
>=20
> --=20
> Stian S=F8iland There are only 10 types of people in the wo=
rld:
> ITEA systemdrift Those who understand binary, and those who do=
n't.
> http://www.stud.ntnu.no/ =20
> =20
>=20
From willy@debian.org Mon Sep 30 22:22:55 2002
From: willy@debian.org (Matthew Wilcox)
Date: Mon, 30 Sep 2002 22:22:55 +0100
Subject: [parisc-linux] 9000/802/K250 won't boot with images - serial/stack problem?
In-Reply-To: <1033419990.30622.11.camel@beavis>; from rbradetich@uswest.net on Mon, Sep 30, 2002 at 03:06:29PM -0600
References: <20020930200805.GA9133@itea.ntnu.no> <1033417191.31126.4.camel@beavis> <20020930204559.GB9133@itea.ntnu.no> <1033419990.30622.11.camel@beavis>
Message-ID: <20020930222255.T18377@parcelfarce.linux.theplanet.co.uk>
On Mon, Sep 30, 2002 at 03:06:29PM -0600, Ryan Bradetich wrote:
> P.S. What would it take to get the default debian configs to compile in
> the the Serial Mux, and to provide the /dev/ttyB0 from the parisc-linux
> port by default in debian? A patch to the debian def_configs and the
> MAKEDEV package?
we really shouldn't be distributing a kernel that uses char-major-42.
42 Demo/sample use
This number is intended for use in sample code, as
well as a general "example" device number. It
should never be used for a device driver that is being
distributed; either obtain an official number or use
the local/experimental range. The sudden addition or
removal of a driver with this number should not cause
ill effects to the system (bugs excepted.)
IN PARTICULAR, ANY DISTRIBUTION WHICH CONTAINS A
DEVICE DRIVER USING MAJOR NUMBER 42 IS NONCOMPLIANT.
maybe we could recycle char 11?
ideally, i'd like to have this driver claim ttyS ports from the
serial core ... but that's not necessarily going to happen for 2.5,
and definitely not for 2.4.
anyone fancy contacting lanana and asking for an official allocation?
--
Revolutions do not require corporate support.
From derekengelhaupt@rocketmail.com Mon Sep 30 23:29:19 2002
From: derekengelhaupt@rocketmail.com (Derek Engelhaupt)
Date: Mon, 30 Sep 2002 15:29:19 -0700 (PDT)
Subject: [parisc-linux] hardware newbie question...
In-Reply-To: <20020925.090915.-178139.3.paulhill20@juno.com>
Message-ID: <20020930222919.62918.qmail@web12503.mail.yahoo.com>
What do you mean locked down? Boot the thing single user and delete
the password. At the "Press any key to interrupt boot" prompt stop the
boot. Type BO <enter> interact with ISL? <y> <enter>. Then at the isl
prompt type <hpux -is> <enter>. That will get you into single user
mode. Unless the system is setup in trusted mode you should be able to
get in and modify the /etc/passwd file. The user name should come
first followed by the password that is encrypted within the colons
(ex:root:VDTGE$8757474:). Delete the encrypted stuff but leave the
colons and save it. Reboot it in multiuser mode and root shouldn't
have a password.
derek
--- Stephen J de Vries <paulhill20@juno.com> wrote:
> I have a HP 712 that I'd purchased recently.
>
> My question is:
>
> Can I use a PC monitor, keyboard, and mouse to boot the thing up? If
> so,
> does the monitor have to be a multisync or something special?
>
> In addition, HP-UX is on the hard drive but is locked down. I was
> thinking of buying an external CD drive and attempting to load debian
> 0.93. Can anyone recommend a place to buy the CD drive that they
> have
> dealt with? I also have a network so I could attempt a network
> install
> but I am not sure what minimum requirements I'd need to fulfill for
> that.
> Is my approach the right one?
>
> Thanks for the advice...
>
> Stephen de Vries
> _______________________________________________
> parisc-linux mailing list
> parisc-linux@lists.parisc-linux.org
> http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
__________________________________________________
Do you Yahoo!?
New DSL Internet Access from SBC & Yahoo!
http://sbc.yahoo.com
From derekengelhaupt@rocketmail.com Mon Sep 30 23:31:15 2002
From: derekengelhaupt@rocketmail.com (Derek Engelhaupt)
Date: Mon, 30 Sep 2002 15:31:15 -0700 (PDT)
Subject: [parisc-linux] hardware newbie question...
In-Reply-To: <Pine.NEB.4.44.0209251557570.7537-100000@io.fachschaften.tu-muenchen.de>
Message-ID: <20020930223115.63225.qmail@web12508.mail.yahoo.com>
--- Andreas Deresch <aderesch@fs.tum.de> wrote:
> On Wed, 25 Sep 2002, Thibaut VARENE wrote:
>
> > Stephen J de Vries wrote:
> > > I have a HP 712 that I'd purchased recently.
> > >
> > > My question is:
> > >
> > > Can I use a PC monitor, keyboard, and mouse to boot the thing up?
> If so,
> > > does the monitor have to be a multisync or something special?
> > OK for the PC monitor. Use 'Tab' at boot time to switch 712's
> resolution
> > NO for the PC keyboard (pc kbd is 75mA iirc, 712 is 500mA)
> Hhmm. I have used two different PS/2 keyboards on a 712. So far
> nothing
> unexpected has happened to either the box nor the keyboard... it
> works just
> fine.
>
> ad
>
Me too....
derek
__________________________________________________
Do you Yahoo!?
New DSL Internet Access from SBC & Yahoo!
http://sbc.yahoo.com
From christoph.plattner@gmx.at Mon Sep 30 23:39:53 2002
From: christoph.plattner@gmx.at (Christoph Plattner)
Date: Tue, 01 Oct 2002 00:39:53 +0200
Subject: [parisc-linux] 9000/802/K250 won't boot with images - serial/stack
problem?
References: <20020930200805.GA9133@itea.ntnu.no> <1033417191.31126.4.camel@beavis> <20020930204559.GB9133@itea.ntnu.no>
Message-ID: <3D98D2B9.659E5A0B@gmx.at>
As far as I see the problem: YES, you must use the
serial porton the MDP (port 0 !). Or use the PDC console
instead of MUX driver, then you are on the safe side,
concerning the console connecting method. The PDC
conolse driver takes that interface, which is configured
in the PDC monitor as console, independent of device
type, chips, ports, etc...
For a 15-pin layout, I cannot give you info. I only can
help on the MUX with the 25DB-SUB used on E55 and similar.
Christoph
Stian Soiland wrote:
>
> On 2002-09-30 22:19:51, Ryan Bradetich wrote:
>
> > > The serial console is connected to 'CONSOLE (X/4/0/0)*',
> > This is good, see .. we even find the device :)
> > > 6. Sahp Baat Kiuh AP/MUX (5) at 0xf1900000 [10/4/0], versions 0x44,
> > 0x0, 0xd
> > > Command line for kernel: 'ramdisk_size=8192 root=/dev/ram console=ttyS0
> > Oops... this is bad. The K class systems do not have a 16550 compatible
> > serial port. The console should be ttyB0.
> > For mor info on the console, see Matthew's excellent description of what
> > systems use the Serial Mux driver.
> > http://lists.parisc-linux.org/pipermail/parisc-linux/2002-September/017837.html
>
> Aha! :=)
>
> But with:
>
> Command line for kernel: 'ramdisk_size=8192 root=/dev/ram console=ttyB0
> TERM=vt102 palo_kernel=0/vmlinux'
>
> (..)
>
> Branching to kernel entry point 0x00100098. If this is the last
> message you see, you may need to switch your console. This is
> a common symptom -- search the FAQ and mailing list at parisc-linux.org
>
> And that IS the last thing I see :/
>
> with console=ttyS0 at least more output came. How do I 'switch console'?
>
> Do I need to connect something to this MDP-port instead?
> (how? It is some inverted rs232 15-pin)
>
> This happens with both vmlinux32 og 64.
>
> --
> Stian Søiland There are only 10 types of people in the world:
> ITEA systemdrift Those who understand binary, and those who don't.
> http://www.stud.ntnu.no/
>
> _______________________________________________
> parisc-linux mailing list
> parisc-linux@lists.parisc-linux.org
> http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
--
-------------------------------------------------------
private: christoph.plattner@gmx.at
company: christoph.plattner@alcatel.at