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 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 >Cc: John David Anglin , 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 >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 #include #include #include 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 Mon Sep 2 16:21:37 2002 From: Randolph Chung (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 Mon Sep 2 17:44:24 2002 From: Randolph Chung (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 Mon Sep 2 17:51:14 2002 From: Randolph Chung (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 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 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 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 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 Tue Sep 3 08:05:55 2002 From: Randolph Chung (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 . 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" 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 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 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 '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 Tue Sep 3 17:13:26 2002 From: Randolph Chung (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 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 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 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" 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: 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" 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 Wed Sep 4 15:55:36 2002 From: Randolph Chung (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 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" 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 Wed Sep 4 19:11:56 2002 From: Randolph Chung (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 [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 [020904 20:28]: > * Grant Grundler [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 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 Thu Sep 5 05:38:21 2002 From: Randolph Chung (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 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 Thu Sep 5 06:28:13 2002 From: Randolph Chung (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 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: 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 -- 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" 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" 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: >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 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 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" 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" 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 " 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 " 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 " 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 " 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 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: 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 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 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: 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: 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 To: Matthew Wilcox Cc: HP900 PARISC mailing list 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 Mon Sep 9 23:04:49 2002 From: Randolph Chung (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: References: 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: (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::deallocate(void*, unsigned) () #3 0x0002cd40 in std::allocator::deallocate(char*, unsigned) () #4 0x0002aa20 in std::string::_Rep::_M_destroy(std::allocator const&) () #5 0x00028230 in std::string::_Rep::_M_dispose(std::allocator 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: 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" 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 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 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 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: 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 To: Martin-=C9ric Racine 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 > # 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: <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: 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 md: bind md: bind md: bind md: bind md: bind md: running: 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 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: 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: References: <20020912054834.GA32209@www1.dt-link.fi> 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 md: bind md: bind md: bind md: bind md: bind md: running: 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 md: bind md: bind md: bind md: bind md: bind md: running: 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|] Boot from specified path PAth [PRI|ALT|CON|KEY] [] Display or modify a path SEArch [DIsplay|IPL] [] Search for boot devices COnfiguration [] Access Configuration menu/commands INformation [] Access Information menu/commands SERvice [] Access Service menu/commands DIsplay Redisplay the current menu HElp [|] Display help for menu or command RESET Restart the system ------- Main Menu: Enter command > 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 =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 =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 =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 =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 =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 =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 =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 =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 =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 =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 =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 =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 of "Thu, 12 Sep 2002 12:10:18 +0300." <20020912091018.GA16372@dt-link.fi> References: <20020912054834.GA32209@www1.dt-link.fi> <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 -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 -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 -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 -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 -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 -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: 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" 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 EasyAdPost.com =20 =20 =20
http://www.parisc-linux.org/release-0.9/errata-093.html=20
=20
=20 =20 =20
=20

=20
 
=20
=20 =20
=20


EasyAdPost.com=20 --
Promote your Products and Services on=20 Thousands of Classified Sites.
Simply the Best Way to Sell on the Internet=21 =20

No=20 time to post an ad for your business?
Struggling with numerous classified sites?
Seeking effective means to promote your business?

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

Visit=20 Links below for More Details

***********************************************

To=20 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=20 or comments? Post your Query Form to us at http://www.easyadpost.com/aboutus.php=20

***********************************************

Spend=20 your market dollar wisely and good luck to your business=21

Peterson=20 Slade
customer=40easyadpost.com
EasyAdPost.com

 

 
--=_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: 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: ; from robin@uk.another.com on Fri, Sep 13, 2002 at 04:09:20PM +0100 References: 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 Fri Sep 13 18:21:25 2002 From: Randolph Chung (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 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 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: <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 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: <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: 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 of "Sat, 14 Sep 2002 12:14:53 +0200." References: 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 #include +#include #include