From None Date: None From: Subject: [kernel] bug#95: panic when setserial restores config from different hardware X-PA-RISC Linux-PR-Message: report 95 X-PA-RISC Linux-PR-Package: kernel X-Loop: daniel_frazier@hp.com Received: via spool by bugs@bugs.parisc-linux.org id=B.9864051855965 (code B ref -1); Wed, 04 Apr 2001 17:33:01 GMT Message-Id: Date: Wed, 4 Apr 2001 11:26:10 -0600 (MDT) To: submit@bugs.parisc-linux.org From: bame@debian.org Cc: bame@debian.org Sender: www-data@bame.riverrock.org Package: kernel Version: 4Apr2001 Severity: grave Kernel dies in a PCI access routine (outb?) when setserial restores a saved serial configuration from a machine with different serial hardware. I first noticed this when I xeroxed a disk from a c3k with a 4-port serial card and tried to boot that on one with a 2-port card, but I think the other direction works too. From None Date: None From: Subject: [kernel] bug#99: missing nfsservctl and quotactl syscall wrappers X-PA-RISC Linux-PR-Message: report 99 X-PA-RISC Linux-PR-Package: kernel X-Loop: daniel_frazier@hp.com Received: via spool by bugs@bugs.parisc-linux.org id=B.98680748514298 (code B ref -1); Mon, 09 Apr 2001 09:18:02 GMT Date: Mon, 9 Apr 2001 10:12:27 +0100 From: Richard Hirst To: submit@bugs.parisc-linux.org Message-ID: <20010409101227.B5790@linuxcare.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0us Package: kernel Version: 2.4.0 Severity: grave We are missing 32-->64 bit syscall wrappers for nfsservctl and quotactl. Both of these are used by the nfs-common package, with rpc.lockd calling nfsservctl(). From None Date: None From: Subject: [kernel] bug#102: second SCSI on C3000 doesn't work X-PA-RISC Linux-PR-Message: report 102 X-PA-RISC Linux-PR-Package: kernel X-Loop: daniel_frazier@hp.com Received: via spool by bugs@bugs.parisc-linux.org id=B.9871159515590 (code B ref -1); Thu, 12 Apr 2001 23:03:01 GMT To: submit@bugs.parisc-linux.org Date: Thu, 12 Apr 2001 16:51:56 -0600 From: Paul Bame Message-Id: Package: kernel Version: 12Apr2001 Severity: normal The second (actually the first) SCSI controller on C3000 doesn't work. This one's hooked to the narrow SCSI connector on the back, which had a disk and proper termination at the time of the test, which the boot rom saw just fine. This boot log is with terminator but no disk, and I think it's the same as when the disk is attached: Booting... Network Station Address 001083-cf855f System IP Address 15.1.49.181 Server IP Address 15.1.52.69 Boot IO Dependent Code (IODC) revision 2 HARD Booted. palo ipl bame@noam Tue Mar 13 17:40:00 MST 2001 0/vmlinux 3487651 bytes @ 0x6800 0/palo-cmdline '0/vmlinux HOME=/ TERM=linux root=/dev/sda5 console=ttyS0' Kernel: partition 0 file /vmlinux ELF64 executable Entry 00100000 first 00100000 n 3 Segment 0 load 00100000 size 2032328 mediaptr 0x1000 Segment 1 load 002f2000 size 750128 mediaptr 0x1f2000 Segment 2 load 003ac000 size 16384 mediaptr 0x2aa000 branching to kernel entry point 0x00100000 Set default PSW W bit to 1 PDC Console Initialized Linux version 2.4.0 (bame@noam) (gcc version 2.97 20010203 (experimental)) #70 Thu Apr 12 16:39:55 MDT 2001 FP[0] enabled: Rev 1 Model 16 The 64-bit Kernel has started... Determining PDC firmware type: Newer Box setup_cmdline(0x64d58,0x64d58,0x0,0x0) PALO command line: 'HOME=/ TERM=linux root=/dev/sda5 console=ttyS0' PALO initrd 0-0 model 00005bb0 00000481 00000000 00000002 782aecfc 100000f0 00000008 000000b2 000000b2 vers 00000203 cpuid 00000227 CPUID vers 17 rev 7 model 9000/785/C3000 Total Memory: 896 Mb initrd: 00000000-00000000 pagetable_init On node 0 totalpages: 229376 zone(0): 229376 pages. zone(1): 0 pages. zone(2): 0 pages. led_init: chassis info: model=0 (LCD), lcd_width=16, cmd_delay=40, actcnt=44, maxcnt=44 led_init: min_cmd_delay = 40 uS LCD display at fffffffff0190000,fffffffff0190001 registered Searching for devices... Found devices: 1. Astro BC Runway Port (12) at 0xfffffffffed00000, versions 0x582, 0x0, 0xb, 0x0, 0x10 2. Elroy PCI Bridge (13) at 0xfffffffffed30000, versions 0x782, 0x0, 0xa, 0x0, 0x0 3. Elroy PCI Bridge (13) at 0xfffffffffed32000, versions 0x782, 0x0, 0xa, 0x0, 0x0 4. Elroy PCI Bridge (13) at 0xfffffffffed38000, versions 0x782, 0x0, 0xa, 0x0, 0x0 5. Elroy PCI Bridge (13) at 0xfffffffffed3c000, versions 0x782, 0x0, 0xa, 0x0, 0x0 6. AllegroHigh W (0) at 0xfffffffffffa0000, versions 0x5bb, 0x0, 0x4, 0x0, 0x81 7. AllegroHigh Memory (1) at 0xfffffffffed10200, versions 0x86, 0x0, 0x9, 0x0, 0x0 That's a total of 7 devices. CPU(s): 1 x PA8500 (PCX-W) at 400.000000 MHz Kernel command line: HOME=/ TERM=linux root=/dev/sda5 console=ttyS0 Calibrating delay loop... 797.90 BogoMIPS Memory: 882048k available Dentry-cache hash table entries: 131072 (order: 9, 2097152 bytes) Buffer-cache hash table entries: 65536 (order: 7, 524288 bytes) Page-cache hash table entries: 262144 (order: 9, 2097152 bytes) Inode-cache hash table entries: 65536 (order: 8, 1048576 bytes) POSIX conformance testing by UNIFIX lba version TR2.1 (0x2) found at 0xfffffffffed30000 lba version TR2.1 (0x2) found at 0xfffffffffed32000 lba version TR2.1 (0x2) found at 0xfffffffffed38000 Warning : device (13, 0x782, 0x0, 0xa, 0x0) NOT claimed by lba TR2.1 lba version TR2.1 (0x2) found at 0xfffffffffed3c000 Warning : device (13, 0x782, 0x0, 0xa, 0x0) NOT claimed by lba TR2.1 SBA found Astro 2.1 at 0xfffffffffed00000 Linux NET4.0 for Linux 2.4 Based upon Swansea University Computer Society NET3.039 Starting kswapd v1.8 pty: 256 Unix98 ptys configured lp: driver loaded but no devices found RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize Serial driver version 5.02 (2000-08-09) with MANY_PORTS SHARE_IRQ SERIAL_PCI enabled SuperIO: Found NS87560 legacy I/O device at 00:0e.1. iosapic irq = 128 SuperIO: Serial port 1 at 0x3f8 SuperIO: Serial port 2 at 0x2f8 SuperIO: Parallel port at 0x378 SuperIO: Floppy controller at 0x3f0 ttyS00 at port 0x03f8 (irq = 195) is a 16550A ttyS01 at port 0x02f8 (irq = 196) is a 16550A ttyS02 at port 0x2100 (irq = 256) is a 16550A ttyS03 at port 0x2000 (irq = 256) is a 16550A Generic RTC Driver v1.02 05/27/1999 Sam Creasey (sammy@oh.verio.com) Linux Tulip driver version 0.9.13 (January 2, 2001) eth0: Digital DS21143 Tulip rev 65 at 0x1000, 00:10:83:CF:85:5F, IRQ 130. eth0: MII transceiver #1 config 1000 status 782d advertising 01e1. SCSI subsystem driver Revision: 1.00 sym53c8xx: at PCI bus 0, device 15, function 0 sym53c8xx: 53c896 detected sym53c8xx: at PCI bus 0, device 15, function 1 sym53c8xx: 53c896 detected sym53c896-0: rev 0x4 on pci bus 0 device 15 function 0 irq 129 sym53c896-0: NCR clock is 40218KHz sym53c896-0: ID 7, Fast-40, Parity Checking sym53c896-0: on-chip RAM at 0xfffffffff4002000 sym53c896-0: suspicious SCSI data while resetting the BUS. sym53c896-0: dp1,d15-8,dp0,d7-0,rst,req,ack,bsy,sel,atn,msg,c/d,i/o = 0x4000100, expecting 0x100 sym53c896-0: FATAL ERROR: CHECK SCSI BUS - CABLES, TERMINATION, DEVICE POWER etc.! sym53c896-0: giving up ... sym53c896-0: rev 0x4 on pci bus 0 device 15 function 1 irq 129 sym53c896-0: NCR clock is 40218KHz sym53c896-0: ID 7, Fast-40, Parity Checking sym53c896-0: on-chip RAM at 0xfffffffff4000000 sym53c896-0: restart (scsi reset). sym53c896-0: handling phase mismatch from SCRIPTS. sym53c896-0: Downloading SCSI SCRIPTS. scsi0 : sym53c8xx - version 1.6b Vendor: SEAGATE Model: ST39173LC Rev: 4270 Type: Direct-Access ANSI SCSI revision: 02 Vendor: SEAGATE Model: ST39102LC Rev: 7C03 Type: Direct-Access ANSI SCSI revision: 02 sym53c896-0-<5,0>: tagged command queue depth set to 8 sym53c896-0-<6,0>: tagged command queue depth set to 8 Detected scsi disk sda at scsi0, channel 0, id 5, lun 0 Detected scsi disk sdb at scsi0, channel 0, id 6, lun 0 sym53c896-0-<5,0>: wide msgout: 1-2-3-1. sym53c896-0-<5,0>: wide msgin: 1-2-3-1. sym53c896-0-<5,0>: wide: wide=1 chg=0. sym53c896-0-<5,0>: wide msgout: 1-2-3-1. sym53c896-0-<5,0>: wide msgin: 1-2-3-1. sym53c896-0-<5,0>: wide: wide=1 chg=0. sym53c896-0-<5,0>: sync msgout: 1-3-1-c-1f. sym53c896-0-<5,0>: sync msg in: 1-3-1-c-f. sym53c896-0-<5,0>: sync: per=12 scntl3=0xb0 scntl4=0x0 ofs=15 fak=0 chg=0. sym53c896-0-<5,*>: FAST-20 WIDE SCSI 40.0 MB/s (50 ns, offset 15) SCSI device sda: 17781521 512-byte hdwr sectors (9104 MB) Partition check: sda: sda1 sda2 sda3 sda4 < sda5 sda6 sda7 sda8 > sym53c896-0-<6,0>: wide msgout: 1-2-3-1. sym53c896-0-<6,0>: wide msgin: 1-2-3-1. sym53c896-0-<6,0>: wide: wide=1 chg=0. sym53c896-0-<6,0>: wide msgout: 1-2-3-1. sym53c896-0-<6,0>: wide msgin: 1-2-3-1. sym53c896-0-<6,0>: wide: wide=1 chg=0. sym53c896-0-<6,0>: sync msgout: 1-3-1-c-1f. sym53c896-0-<6,0>: sync msg in: 1-3-1-c-f. sym53c896-0-<6,0>: sync: per=12 scntl3=0xb0 scntl4=0x0 ofs=15 fak=0 chg=0. sym53c896-0-<6,*>: FAST-20 WIDE SCSI 40.0 MB/s (50 ns, offset 15) SCSI device sdb: 17781521 512-byte hdwr sectors (9104 MB) sdb: sdb1 sdb2 sdb3 sdb4 < sdb5 sdb6 sdb7 sdb8 > linear personality registered raid0 personality registered raid1 personality registered raid5 personality registered raid5: measuring checksumming speed 8regs : 2214.753 MB/sec 8regs_prefetch: 1941.576 MB/sec 32regs : 1497.711 MB/sec 32regs_prefetch: 1717.929 MB/sec raid5: using function: 8regs (2214.753 MB/sec) md driver 0.90.0 MAX_MD_DEVS=256, MD_SB_DISKS=27 md.c: sizeof(mdp_super_t) = 4096 NET4: Linux TCP/IP 1.0 for NET4.0 IP Protocols: ICMP, UDP, TCP IP: routing cache hash table of 4096 buckets, 64Kbytes TCP: Hash tables configured (established 32768 bind 32768) Sending BOOTP requests.... OK IP-Config: Got BOOTP answer from 15.1.52.69, my address is 15.1.49.181 NET4: Unix domain sockets 1.0/SMP for Linux NET4.0. VFS: Mounted root (ext2 filesystem) readonly. INIT: version 2.78 booting Activating swap... Adding Swap: 525304k swap-space (priority -1) Adding Swap: 525288k swap-space (priority -2) Checking root file system... Parallelizing fsck version 1.19 (13-Jul-2000) /dev/sda5: clean, 33107/262656 files, 245540/524288 blocks Checking all file systems... Parallelizing fsck version 1.19 (13-Jul-2000) /dev/sda3: clean, 17/8480 files, 13400/33792 blocks /dev/sda6: clean, 126927/262656 files, 453790/524288 blocks Setting kernel variables. Mounting local filesystems... /dev/sda3 on /boot type ext2 (rw,errors=remount-ro) /dev/sda6 on /home type ext2 (rw,errors=remount-ro) Cleaning: /etc/network/ifstate. Configuring network interfaces: done. Starting portmap daemon: portmapeth0: Setting full-duplex based on MII#1 link partner capability of 45e1. do_page_fault() pid=57 command='portmap' type=15 address=0xe840bffc vm_start = 0x40175000, vm_end = 0x40179000 YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI PSW: 00000000000001101111111100001111 r0-3 0000000000000000 00000000e840c000 00000000400223e7 00000000faf00340 r4-7 000000004014fb18 00000000faf001a4 0000000000000001 000000004001a4e4 r8-11 00000000faf0016c 00000000faf00164 0000000000000001 000000004001bc40 r12-15 000000004001bc20 0000000000000000 0000000000089c10 0000000000000000 r16-19 0000000000000000 0000000000077578 000000000000b270 000000004014fb18 r20-23 00000000e840bffc 0000000000003a08 00000000400223b8 0000000000000000 r24-27 00000000faf0016c 00000000faf00164 0000000000000001 0000000000004f54 r28-31 000000004001b3d2 0000000000000037 00000000faf003c0 000000004000f053 sr0-3 0000000000004000 0000000000004000 0000000000000000 0000000000004000 sr4-7 0000000000004000 0000000000004000 0000000000004000 0000000000004000 IASQ: 0000000000004000 0000000000004000 IAOQ: 0000000040025c2f 0000000040025c33 IIR: 0e801094 ISR: 0000000000004000 IOR: 00000000e840bffc ORIG_R28: 00000000faf00005 /etc/rcS.d/S41portmap: line 47: 57 Segmentation fault start-stop-daemon --start --quiet --exec /sbin/portmap . Setting the System Clock using the Hardware Clock as reference... System Clock set. Local time: Thu Apr 12 16:31:37 MDT 2001 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 klogd. Starting Name Service Cache Daemon: nscd. Starting internet superserver: inetd. Starting locally-built Secure Shell server: sshd. Starting web server: apache. /usr/local/apache/bin/apachectl start: httpd started shmctl(IPC_STAT(cmd=0x2)) does not support libc5 cmds Debian GNU/Linux testing/unstable palinux ttyS0 palinux login: l  ------- End of Forwarded Message From None Date: None From: Subject: bug#102: [kernel] bug#102: second SCSI on C3000 doesn't work X-PA-RISC Linux-PR-Message: report 102 X-PA-RISC Linux-PR-Package: kernel X-Loop: daniel_frazier@hp.com Received: via spool by 102-bugs@bugs.parisc-linux.org id=B102.9871189496218 (code B ref 102); Thu, 12 Apr 2001 23:48:01 GMT Date: Fri, 13 Apr 2001 00:43:08 +0100 From: Richard Hirst To: Paul Bame , 102@bugs.parisc-linux.org Message-ID: <20010413004308.E11226@linuxcare.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0us In-Reply-To: ; from kernel-admin@lists.parisc-linux.org on Thu, Apr 12, 2001 at 11:05:41PM +0000 On Thu, Apr 12, 2001 at 11:05:41PM +0000, kernel-admin@lists.parisc-linux.org wrote: > The second (actually the first) SCSI controller on C3000 doesn't work. > This one's hooked to the narrow SCSI connector on the back, which had > a disk and proper termination at the time of the test, which the boot > rom saw just fine. This boot log is with terminator but no disk, and > I think it's the same as when the disk is attached: > sym53c896-0: suspicious SCSI data while resetting the BUS. > sym53c896-0: dp1,d15-8,dp0,d7-0,rst,req,ack,bsy,sel,atn,msg,c/d,i/o = 0x4000100, expecting 0x100 > sym53c896-0: FATAL ERROR: CHECK SCSI BUS - CABLES, TERMINATION, DEVICE POWER etc.! > sym53c896-0: giving up ... It is complaining about dp1, parity for the top half of the bus, which is interesting if it is only narrow out of the box. If you boot with sym53c8xx=buschk:2 it should just warn about the error and carry on. See drivers/scsi/README.ncr553c8xx for options. Richard From daniel_frazier@hp.com Thu, 12 Apr 2001 17:48:02 -0600 (MDT) Date: Thu, 12 Apr 2001 17:48:02 -0600 (MDT) From: PA-RISC Linux bug Tracking System daniel_frazier@hp.com Subject: [kernel] bug#83: marked as done (Unexpected FPU exception building CVS Debian Package) X-PA-RISC Linux-PR-Message: closed 83 Your message dated Thu, 12 Apr 2001 17:37:17 -0600 with message-id and subject line fixed FPU stuff has caused the attached bug report to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what I am talking about this indicates a serious mail system misconfiguration somewhere. Please contact me immediately.) dann frazier (administrator, PA-RISC Linux bugs database) -------------------------------------- Received: (at submit) by bugs.parisc-linux.org; 20 Mar 2001 22:05:39 +0000 >From bame@fc.hp.com Tue Mar 20 15:05:39 2001 Received: from atlrel1.hp.com (atlrel1.hp.com [156.153.255.210]) by dsl2.external.hp.com (Postfix) with ESMTP id 045194A19 for ; Tue, 20 Mar 2001 15:05:39 -0700 (MST) Received: from hpfcla.fc.hp.com (hpfcla.fc.hp.com [15.254.48.2]) by atlrel1.hp.com (Postfix) with ESMTP id 594F011DF for ; Tue, 20 Mar 2001 17:03:56 -0500 (EST) Received: from noam.fc.hp.com (mail@noam.fc.hp.com [15.1.52.69]) by hpfcla.fc.hp.com (8.9.3 (PHNE_22672)/8.9.3 SMKit7.01) with ESMTP id PAA03679 for ; Tue, 20 Mar 2001 15:03:55 -0700 (MST) Received: from localhost ([127.0.0.1] helo=fc.hp.com ident=bame) by noam.fc.hp.com with esmtp (Exim 3.12 #1 (Debian)) id 14fUEN-0007bs-00 for ; Tue, 20 Mar 2001 15:03:55 -0700 To: submit@bugs.parisc-linux.org Subject: Unexpected FPU exception building CVS Debian Package Date: Tue, 20 Mar 2001 15:03:55 -0700 From: Paul Bame Message-Id: Package: kernel Version: 20Mar2001 Severity: normal While building the CVS Debian package the kernel complains about an unemulated FPU instruction which turns out to be a fsub,dbl producing a FPU exception code 9. None of the status register IEEE exception bits are set but the I(nexact) exception bit in the status register is being set. Debug output: This is the disassembled instruction: 23988: 30 0c 2e 16 fsub,dbl fr0,fr12,fr22 The offending command is /usr/bin/pic which is run during the CVS build because 'groff -Tpic' is used. pid 266(pic): Unemulated floating instruction: exception 0x09:0c2e16 fmt 1 class 3 subop 1 01234567890123456789012345678901 Instruction 00000011000010111000010110 VZOUICxxxxCQCQCQCQCQCRMxxTDVZOUI FP Status Word 00001000001111111101100001000000 fr0-3 0000000000000000 0000000000000000 0000000000000000 0000000000000000 fr4-7 0000000a066d87d6 00005000c28f5c29 0000000000032000 0000000023d3173a fr8-11 0000000000000000 102d000000000000 10282064102ed010 102ef81010268010 fr12-15 0000000023d3173a 1028601010139050 102ec010102ce138 102ce138102ce0b0 fr16-19 47d420001028260c 0000000000000002 0000000010298ea4 0004000e000000c1 fr20-23 102ed01047d42000 1028260c1014a808 00000000df58b452 000000019999999a fr24-27 000000084189374c 0000132f51c10aba 000089d710280c28 00000000000000c1 fr28-31 ffffff05102ef810 00000001101391b8 47d78c0010280c28 0000000000000000 YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI PSW: 00000000000001001111111100001111 r0-3 00000000 00030a38 00023367 000367e8 r4-7 000369b8 faf00d34 0002d000 00030fa0 r8-11 00000000 00033188 00000000 00031a38 r12-15 00030a38 00000001 00030a38 00000000 r16-19 0000e860 0000e860 0000e86c faf03600 r20-23 00032578 400786c4 00023924 c0000000 r24-27 00000000 00000000 000367e8 00030a38 r28-31 4007acb0 faf03c08 faf03640 00023367 sr0-3 00000000 00000167 00000000 00000167 sr4-7 00000167 00000167 00000167 00000167 IASQ: 00000167 00000167 IAOQ: 0002398f 00023993 IIR: 2e701216 ISR: 103400da IOR: edb03608 ORIG_R28: 4001e000 --------------------------------------- Received: (at 83-close) by bugs.parisc-linux.org; 12 Apr 2001 23:37:21 +0000 >From bame@fc.hp.com Thu Apr 12 17:37:21 2001 Received: from atlrel2.hp.com (atlrel2.hp.com [156.153.255.202]) by dsl2.external.hp.com (Postfix) with ESMTP id AB684482A for <83-close@bugs.parisc-linux.org>; Thu, 12 Apr 2001 17:37:21 -0600 (MDT) Received: from hpfcla.fc.hp.com (hpfcla.fc.hp.com [15.254.48.2]) by atlrel2.hp.com (Postfix) with ESMTP id 534A0DD3 for <83-close@bugs.parisc-linux.org>; Thu, 12 Apr 2001 19:37:20 -0400 (EDT) Received: from noam.fc.hp.com (mail@noam.fc.hp.com [15.1.52.69]) by hpfcla.fc.hp.com (8.9.3 (PHNE_22672)/8.9.3 SMKit7.01) with ESMTP id RAA28303 for <83-close@bugs.parisc-linux.org>; Thu, 12 Apr 2001 17:37:18 -0600 (MDT) Received: from localhost ([127.0.0.1] helo=fc.hp.com ident=bame) by noam.fc.hp.com with esmtp (Exim 3.12 #1 (Debian)) id 14nqeL-0004fh-00 for <83-close@bugs.parisc-linux.org>; Thu, 12 Apr 2001 17:37:17 -0600 To: 83-close@bugs.parisc-linux.org Subject: fixed FPU stuff Date: Thu, 12 Apr 2001 17:37:17 -0600 From: Paul Bame Message-Id: Added FPU emulation handling to kernel. From None Date: None From: Subject: bug#102: [kernel] bug#102: second SCSI on C3000 doesn't work X-PA-RISC Linux-PR-Message: report 102 X-PA-RISC Linux-PR-Package: kernel X-Loop: daniel_frazier@hp.com Received: via spool by 102-bugs@bugs.parisc-linux.org id=B102.98714708610735 (code B ref 102); Fri, 13 Apr 2001 07:33:01 GMT Message-Id: <200104130724.BAA31057@puffin.external.hp.com> To: Paul Bame , 102@bugs.parisc-linux.org In-Reply-To: Your message of "Thu, 12 Apr 2001 16:57:06 MDT." <200104122257.QAA25591@puffin.external.hp.com> Date: Fri, 13 Apr 2001 01:24:56 -0600 From: Grant Grundler Paul Bame wrote: > The second (actually the first) SCSI controller on C3000 doesn't work. > This one's hooked to the narrow SCSI connector on the back, which had > a disk and proper termination at the time of the test, which the boot > rom saw just fine. This boot log is with terminator but no disk, and > I think it's the same as when the disk is attached: Paul, I'm surprised we hadn't filed a bug on this before. Thanks for doing it! ... > sym53c896-0: suspicious SCSI data while resetting the BUS. > sym53c896-0: dp1,d15-8,dp0,d7-0,rst,req,ack,bsy,sel,atn,msg,c/d,i/o > = 0x4000100, expecting 0x100 > sym53c896-0: FATAL ERROR: CHECK SCSI BUS - CABLES, TERMINATION, DEVICE POWER > etc.! > sym53c896-0: giving up ... I suspect the problem is that the SCSI interface chip is capable of running "wide" (16-bit data path) and the sym53c8xx assumes that's how it's wired. The upper bits *probably* are not grounded since the interface out the back is narrow. Can anyone confirm this? (ie has 896 or c3k motherboard knowledge?) [ And I just saw Richard's mail saying parity is wrong for upper bits ] HPUX queries PDC to determine the SCSI ID (+ other attributes) and programs the 896 chip accordingly *before* the SCSI bus probe. I assume bus width is one of the attributes but haven't checked. grant Grant Grundler parisc-linux {PCI|IOMMU|SMP} hacker +1.408.447.7253 From None Date: None From: Subject: [kernel] bug#103: perl build on 64-bit shows possible syscall wrapper problems X-PA-RISC Linux-PR-Message: report 103 X-PA-RISC Linux-PR-Package: kernel X-Loop: daniel_frazier@hp.com Received: via spool by bugs@bugs.parisc-linux.org id=B.98718985219427 (code B ref -1); Fri, 13 Apr 2001 19:33:01 GMT To: submit@bugs.parisc-linux.org Date: Fri, 13 Apr 2001 13:24:09 -0600 From: Paul Bame Message-Id: package: kernel version: 13apr2001 severity: serious during the perl build on wide kernel the kernel says: shmctl(IPC_STAT(cmd=0x2)) does not support libc5 cmds msgctl() does not support libc5 IPC_STAT semctl(IPC_STAT(cmd=0x2)) does not support libc5-style cmds semctl(IPC_STAT(cmd=0x2)) does not support libc5-style cmds From None Date: None From: Subject: [kernel] bug#104: 32-bit kernel dies on c3000 when CONFIG_CHASSIS_LCD_LED enabled X-PA-RISC Linux-PR-Message: report 104 X-PA-RISC Linux-PR-Package: kernel X-Loop: daniel_frazier@hp.com Received: via spool by bugs@bugs.parisc-linux.org id=B.98718995719439 (code B ref -1); Fri, 13 Apr 2001 19:33:01 GMT To: submit@bugs.parisc-linux.org Date: Fri, 13 Apr 2001 13:25:54 -0600 From: Paul Bame Message-Id: package: kernel version: 13apr2001 From None Date: None From: Subject: [kernel] bug#105: ccio_dma kernel panic X-PA-RISC Linux-PR-Message: report 105 X-PA-RISC Linux-PR-Package: kernel X-Loop: daniel_frazier@hp.com Received: via spool by bugs@bugs.parisc-linux.org id=B.98719910620889 (code B ref -1); Fri, 13 Apr 2001 22:03:01 GMT X-Mailer: exmh version 2.3.1 01/18/2001 (debian 2.3.1-1) with nmh-1.0.4+dev To: submit@bugs.parisc-linux.org Cc: bryang@soccer.fc.hp.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 13 Apr 2001 16:01:07 -0600 From: Matt Taggart Message-Id: <20010413220107.2DCFB37E5D@carmen.fc.hp.com> Package: kernel Version: 2001-04-11 Severity: grave I gave a 0.6 iso to a local user, and he attempted to install on his C240. When he was cpio'ing the CDROM to the scsi disk he experienced the problem below. He said it is repeatable. -- Matt Taggart Linux Development Lab taggart@fc.hp.com HP Linux Systems Operation ------- Forwarded Message From: Bryan Gartner Subject: parisc info To: taggart@fc.hp.com Date: Fri, 13 Apr 2001 15:21:43 MDT Matt, C240, 1.5GB RAM, 9GB disk, built-in 100bt /mnt/boot /mnt/boot/iplboot /mnt/boot/kernels /mnt/boot/kernels/hppa32 /mnt/boot/kernels/hppa32/serial ccio_dma.c:365: Assertion (pages needed * IOVP_SIZE) < DMA_CHUNK_SIZE Kernel panic: (pages needed * IOVP_SIZE) < DMA_CHUNK_SIZE System is in cube next to me. bryang ------- End of Forwarded Message From None Date: None From: Subject: bug#105: [kernel] bug#105: ccio_dma kernel panic X-PA-RISC Linux-PR-Message: report 105 X-PA-RISC Linux-PR-Package: kernel X-Loop: daniel_frazier@hp.com Received: via spool by 105-bugs@bugs.parisc-linux.org id=B105.98720143021643 (code B ref 105); Fri, 13 Apr 2001 22:48:01 GMT Message-Id: <200104132230.QAA09407@puffin.external.hp.com> To: Matt Taggart , 105@bugs.parisc-linux.org In-Reply-To: Your message of "Fri, 13 Apr 2001 15:57:05 MDT." <200104132157.PAA08703@puffin.external.hp.com> Date: Fri, 13 Apr 2001 16:30:36 -0600 From: Grant Grundler kernel-admin@lists.parisc-linux.org wrote: ... > ccio_dma.c:365: Assertion (pages needed * IOVP_SIZE) < DMA_CHUNK_SIZE > Kernel panic: (pages needed * IOVP_SIZE) < DMA_CHUNK_SIZE DMA_CHUNK_SIZE is the max IO length SCSI midlayer will limit itself to when doin I/O. parisc defines it with: #define DMA_CHUNK_SIZE (BITS_PER_LONG*PAGE_SIZE) If any part of the I/O is not aligned to a page boundary, we will need more than BITS_PER_LONG I/O pdir entries and hit the above assertion. Worst case might be (BITS_PER_LONG/2). If the mapping request is for the HD, then we might avoid the buffer aligment issue by forcing the file system to 4K blocks. This is just a workaround though. grant Grant Grundler parisc-linux {PCI|IOMMU|SMP} hacker +1.408.447.7253 From None Date: None From: Subject: bug#105: [kernel] bug#105: ccio_dma kernel panic X-PA-RISC Linux-PR-Message: report 105 X-PA-RISC Linux-PR-Package: kernel X-Loop: daniel_frazier@hp.com Received: via spool by 105-bugs@bugs.parisc-linux.org id=B105.98720279321869 (code B ref 105); Fri, 13 Apr 2001 23:03:01 GMT X-Mailer: exmh version 2.3.1 01/18/2001 (debian 2.3.1-1) with nmh-1.0.4+dev To: Grant Grundler Cc: 105@bugs.parisc-linux.org In-Reply-To: Message from Grant Grundler of "Fri, 13 Apr 2001 16:30:36 MDT." <200104132230.QAA09407@puffin.external.hp.com> References: <200104132230.QAA09407@puffin.external.hp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 13 Apr 2001 17:02:34 -0600 From: Matt Taggart Message-Id: <20010413230234.C0C0637E5D@carmen.fc.hp.com> Grant Grundler writes... > kernel-admin@lists.parisc-linux.org wrote: [snip] > If the mapping request is for the HD, then we might avoid the buffer > aligment issue by forcing the file system to 4K blocks. > This is just a workaround though. I was able to repeat this problem on my C240, on a file system with 4k blocks. -- Matt Taggart Linux Development Lab taggart@fc.hp.com HP Linux Systems Operation From daniel_frazier@hp.com Fri, 13 Apr 2001 21:03:01 -0600 (MDT) Date: Fri, 13 Apr 2001 21:03:01 -0600 (MDT) From: PA-RISC Linux bug Tracking System daniel_frazier@hp.com Subject: [kernel] Processed: owning bug #105 Processing commands for control@bugs.parisc-linux.org: > owner 105 rbradetich@uswest.net bug#105: ccio_dma kernel panic Noted your statement that bug has been assigned to rbradetich@uswest.net. > End of message, stopping processing here. Please contact me if you need assistance. dann frazier (administrator, PA-RISC Linux bugs database) From daniel_frazier@hp.com Sat, 14 Apr 2001 01:03:01 -0600 (MDT) Date: Sat, 14 Apr 2001 01:03:01 -0600 (MDT) From: PA-RISC Linux bug Tracking System daniel_frazier@hp.com Subject: [kernel] Processed: closing bug #105 Processing commands for control@bugs.parisc-linux.org: > close 105 bug#105: ccio_dma kernel panic bug closed, send any further explanations to Matt Taggart > End of message, stopping processing here. Please contact me if you need assistance. dann frazier (administrator, PA-RISC Linux bugs database) From None Date: None From: Subject: [kernel] bug#107: shmctl returns ENOSYS X-PA-RISC Linux-PR-Message: report 107 X-PA-RISC Linux-PR-Package: kernel X-Loop: daniel_frazier@hp.com Received: via spool by bugs@bugs.parisc-linux.org id=B.98749044224707 (code B ref -1); Tue, 17 Apr 2001 07:03:01 GMT Date: Tue, 17 Apr 2001 16:52:57 +1000 From: Brendan O'Dea To: submit@bugs.parisc-linux.org Message-ID: <20010417165257.A30220@compusol.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.17i Sender: Brendan O'Dea Package: kernel Version: 2.4.0 Linux j5k 2.4.0 #15 Thu Apr 12 19:26:53 MDT 2001 parisc64 unknown The shmctl in the code below fails with ENOSYS. #include #include #include int main() { int seg; struct shmid_ds buf; if ((seg = shmget(IPC_PRIVATE, 2000, 0700)) < 0) { perror("shmget"); return 1; } if (shmctl(seg, IPC_STAT, &buf) < 0) { perror("shmctl"); return 1; } return 0; } Regards, -- Brendan O'Dea bod@compusol.com.au Compusol Pty. Limited (NSW, Australia) +61 2 9810 3633 From None Date: None From: Subject: [kernel] bug#109: iptables causes trap 27 X-PA-RISC Linux-PR-Message: report 109 X-PA-RISC Linux-PR-Package: kernel X-Loop: daniel_frazier@hp.com Received: via spool by bugs@bugs.parisc-linux.org id=B.98762688814379 (code B ref -1); Wed, 18 Apr 2001 21:03:01 GMT Message-Id: <200104182041.OAA20296@puffin.external.hp.com> To: submit@bugs.parisc-linux.org Date: Wed, 18 Apr 2001 14:41:27 -0600 From: Grant Grundler Package: kernel Version: 20010418 Severity: grave Summary Tried to run iptables on my A500 from /etc/init.d/firewall script. Resulted in a "Segementation fault" (trap 27 on console output). Kernel spewed register state at that point and locked up. I'll submit the firewall script and .config I was using in seperate e-mails. Notes of what I've looked at so far are appended. Out of time at the moment to track this further. grant a500:/etc/init.d# ./firewall start Starting firewall (iptables):firewall INPUT -i eth0 -j LOG -s localhost firewall INPUT -i eth0 -j DROP -s localhost firewall INPUT -i eth0 -j LOG -s a500 firewall INPUT -i eth0 -j DROP -s a500 firewall INPUT -i eth1 -j ACCEPT firewall INPUT -i eth2 -j ACCEPT firewall INPUT -i eth3 -j ACCEPT firewall INPUT -s localhost -j ACCEPT firewall INPUT -s a500 -j ACCEPT firewall INPUT -s 192.168.0.20 -j ACCEPT firewall INPUT -j ACCEPT -p tcp --syn -d 0/0 --dport 22 firewall INPUT -j ACCEPT -p tcp --syn -d 0/0 --dport http firewall INPUT -j ACCEPT -p tcp --syn -d 0/0 --dport smtp firewall INPUT -j ACCEPT -p tcp --syn -d 0/0 --dport ident ./firewall: line 3: 724 Segmentation fault iptables -A $* firewall INPUT -j ACCEPT -p tcp --syn -d 0/0 --dport ftp iptables[724]: Protection Id Trap 27 YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI PSW: 00001000000011000000000000001111 r0-3 0000000000000000 0000000000000040 00000000102a316c 000000000008da58 r4-7 0000000010373600 0000000000000070 000000000008d9e8 000000000008d000 r8-11 0000000010373600 0000000000000a58 0000000010373600 000000000008f000 r12-15 0000000000000000 00000000ffffffff 00000000000aee70 0000000000000000 r16-19 0000000000000000 0000000000007514 0000000000005000 000000000000003b r20-23 0000000000000020 000000000000001f 0000000000000001 0000000000098000 r24-27 00000000000000ff 000000000008f001 000119800000e9d4 0000000010373600 r28-31 0000000000000013 00000000fcae8e30 00000000fcae9180 0000000000000000 sr0-3 0000000000000180 0000000000000180 0000000000000000 0000000000000180 sr4-7 0000000000000000 0000000000000000 0000000000000000 0000000000000000 IASQ: 0000000000000000 0000000000000000 IAOQ: 00000000102c43a8 00000000102c43a0 IIR: 0f415222 ISR: 0000000000011980 IOR: 000000000000e9d4 ORIG_R28: 0000000010150e14 IAOQ 0x102c43a8 $lctu_loop+8 GR02 0x102a316c do_replace+51c No stack trace *sigh* lctu_loop seems related to copy_to_user ggg: no... someone called copy_to_user with an invalid address to copy _from_, i think. net/ipv4/netfilter/ip_tables.c: static int do_replace(void *user, unsigned int len) { ... struct ipt_replace tmp; struct ipt_counters *counters; ... if (copy_from_user(&tmp, user, sizeof(tmp)) != 0) return -EFAULT; ... counters = vmalloc(tmp.num_counters * sizeof(struct ipt_counters)); if (!counters) { ret = -ENOMEM; goto free_newinfo; } memset(counters, 0, tmp.num_counters * sizeof(struct ipt_counters)); ... /* Get the old counters. */ get_counters(oldinfo, counters); ... copy_to_user(tmp.counters, counters, sizeof(struct ipt_counters) * tmp.num_counters); ... } 102a3140: 37 dd 3f e1 ldo -10(sp),ret1 102a3144: eb 53 ad c9 b,l 10149830 ,%r2 102a3148: 08 07 02 5a copy r7,r26 102a314c: 4b d8 3d c9 ldw -11c(sp),r24 102a314c: 4b d8 3d c9 ldw -11c(sp),r24 102a3150: 37 dd 3f e1 ldo -10(sp),ret1 102a3154: 53 da 3d d1 ldd -118(sp),r26 102a3158: 08 08 02 5b copy r8,dp 102a315c: db 18 0b e0 extrd,u r24,63,32,r24 102a3160: 08 0b 02 59 copy r11,r25 102a3164: e8 10 a4 2c call 102c4380 102a3168: f3 18 10 84 depd,z r24,59,60,r24 00000000102c4380 : 102c4380: 87 00 20 4a cmpib,=,n 0,r24,102c43ac <$lctu_done> 102c4384: 08 1e 02 41 copy sp,r1 102c4388: f4 20 04 12 depdi 0,63,14,r1 102c438c: 48 36 00 28 ldw 14(r1),r22 102c4390: 00 00 c4 a1 mfsp sr3,r1 102c4394: 08 16 32 40 or,<> r22,r0,r0 102c4398: 08 00 02 41 copy r0,r1 102c439c: 00 01 58 20 mtsp r1,sr1 00000000102c43a0 <$lctu_loop>: 102c43a0: 0f 22 10 21 ldb,ma 1(sr0,r25),r1 102c43a4: af 1f 3f ed addib,<> -1,r24,102c43a0 <$lctu_loop> 102c43a8: 0f 41 52 22 stb,ma r1,1(sr1,r26) *** TRAP27 *** 00000000102c43ac <$lctu_done>: 102c43ac: e8 40 c0 00 bv r0(rp) 102c43b0: 08 18 02 5c copy r24,ret0 102c43b4: e8 1f 1f e5 b,l 102c43ac <$lctu_done>,r0 102c43b8: 37 18 00 02 ldo 1(r24),r24 GR24 00000000000000ff GR25 000000000008f001 GR26 000119800000e9d4 SR1 0000000000000180 (SR0 is the same) Looks like we tried to copyout the counters info but went past the end of the page/space allocated by iptables. Not sure about this conclusion though... From None Date: None From: Subject: bug#109: [kernel] bug#109: iptables causes trap 27 X-PA-RISC Linux-PR-Message: report 109 X-PA-RISC Linux-PR-Package: kernel X-Loop: daniel_frazier@hp.com Received: via spool by 109-bugs@bugs.parisc-linux.org id=B109.98763010314962 (code B ref 109); Wed, 18 Apr 2001 21:48:01 GMT Date: Wed, 18 Apr 2001 22:41:44 +0100 From: Richard Hirst To: Grant Grundler , 109@bugs.parisc-linux.org Message-ID: <20010418224144.Y11226@linuxcare.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0us In-Reply-To: ; from kernel-admin@lists.parisc-linux.org on Wed, Apr 18, 2001 at 09:13:57PM +0000 On Wed, Apr 18, 2001 at 09:13:57PM +0000, kernel-admin@lists.parisc-linux.org wrote: > 00000000102c4380 : > 102c4380: 87 00 20 4a cmpib,=,n 0,r24,102c43ac <$lctu_done> > 102c4384: 08 1e 02 41 copy sp,r1 > 102c4388: f4 20 04 12 depdi 0,63,14,r1 > 102c438c: 48 36 00 28 ldw 14(r1),r22 > 102c4390: 00 00 c4 a1 mfsp sr3,r1 > 102c4394: 08 16 32 40 or,<> r22,r0,r0 > 102c4398: 08 00 02 41 copy r0,r1 > 102c439c: 00 01 58 20 mtsp r1,sr1 > > 00000000102c43a0 <$lctu_loop>: > 102c43a0: 0f 22 10 21 ldb,ma 1(sr0,r25),r1 > 102c43a4: af 1f 3f ed addib,<> -1,r24,102c43a0 <$lctu_loop> > 102c43a8: 0f 41 52 22 stb,ma r1,1(sr1,r26) *** TRAP27 *** > > 00000000102c43ac <$lctu_done>: > 102c43ac: e8 40 c0 00 bv r0(rp) > 102c43b0: 08 18 02 5c copy r24,ret0 > 102c43b4: e8 1f 1f e5 b,l 102c43ac <$lctu_done>,r0 > 102c43b8: 37 18 00 02 ldo 1(r24),r24 > > GR24 00000000000000ff > GR25 000000000008f001 > GR26 000119800000e9d4 > SR1 0000000000000180 (SR0 is the same) > > Looks like we tried to copyout the counters info but went past the > end of the page/space allocated by iptables. Not sure about this > conclusion though... I'd guess gr26 was screwed. Surely the top half should be zero? Richard From None Date: None From: Subject: [kernel] bug#109: firewall script using iptables X-PA-RISC Linux-PR-Message: report 109 X-PA-RISC Linux-PR-Package: kernel X-Loop: daniel_frazier@hp.com Received: via spool by 109-bugs@bugs.parisc-linux.org id=B109.98765263318383 (code B ref 109); Thu, 19 Apr 2001 04:03:01 GMT Date: Wed, 18 Apr 2001 21:51:04 -0600 From: Grant Grundler Message-Id: <200104190351.VAA21420@puffin.external.hp.com> To: 109@bugs.parisc-linux.org #!/bin/bash add() { echo `basename $0` $* iptables -D $* >/dev/null 2>&1 iptables -A $* } #LOCAL_IP=puffin LOCAL_IP=a500 OUTSIDE_NET=0/0 OUTSIDE_IF=eth0 DNS_NET1=156.153.255.234 DNS_NET2=156.153.255.202 NTP_NET=clock.isc.org PRIVATE_NET=192.168.0.20 firewall() { iptables -P INPUT ACCEPT iptables -P OUTPUT ACCEPT iptables -P FORWARD DROP iptables -F INPUT #add INPUT -i $OUTSIDE_IF # Look for possible source-routed packet attacks (should we log this?) add INPUT -i $OUTSIDE_IF -j LOG -s localhost add INPUT -i $OUTSIDE_IF -j DROP -s localhost add INPUT -i $OUTSIDE_IF -j LOG -s $LOCAL_IP add INPUT -i $OUTSIDE_IF -j DROP -s $LOCAL_IP # Trust these interfaces - all are connected to a private subnet add INPUT -i eth1 -j ACCEPT add INPUT -i eth2 -j ACCEPT add INPUT -i eth3 -j ACCEPT # Trust these IP addresses to do anything add INPUT -s localhost -j ACCEPT add INPUT -s $LOCAL_IP -j ACCEPT add INPUT -s $PRIVATE_NET -j ACCEPT # MJT no longer exists #add INPUT -s puffinpa.external.hp.com -j ACCEPT ####################### TCP Section ############################### # Accept ssh, http, smtp, and ident connections from anywhere. add INPUT -j ACCEPT -p tcp --syn -d $OUTSIDE_NET --dport 22 # ssh add INPUT -j ACCEPT -p tcp --syn -d $OUTSIDE_NET --dport http add INPUT -j ACCEPT -p tcp --syn -d $OUTSIDE_NET --dport smtp add INPUT -j ACCEPT -p tcp --syn -d $OUTSIDE_NET --dport ident # add INPUT -j ACCEPT -p tcp --syn -d $OUTSIDE_NET --dport cvs # FTP server add INPUT -j ACCEPT -p tcp --syn -d $OUTSIDE_NET --dport ftp add INPUT -j ACCEPT -p tcp --syn -d $OUTSIDE_NET --dport ftp-data # Passive ftp. add INPUT -j ACCEPT -p tcp --dport 1024:5999 add INPUT -j ACCEPT -p tcp --dport 6010: # DNS server access. add INPUT -j ACCEPT -p tcp -d $OUTSIDE_NET -s $DNS_NET1 --dport domain add INPUT -j ACCEPT -p tcp -d $OUTSIDE_NET -s $DNS_NET2 --dport domain # NTP time server add INPUT -j ACCEPT -p udp -d $OUTSIDE_NET -s $NTP_NET --dport ntp # MJT not using this server anymore #add INPUT -j ACCEPT -p udp -s finch.cc.ukans.edu --dport ntp -d $OUTSIDE_NET # Deny all other "external" TCP connections add INPUT -s ! $LOCAL_IP -j LOG -p tcp --syn add INPUT -s ! $LOCAL_IP -j DROP -p tcp --syn # But accept all other "external" TCP non-connections add INPUT -s ! $LOCAL_IP -j ACCEPT -p tcp ####################### UDP Section ############################### # Allow these services from specific hosts. add INPUT -j ACCEPT -p udp -d $OUTSIDE_NET -s $DNS_NET1 --dport domain add INPUT -j ACCEPT -p udp -d $OUTSIDE_NET -s $DNS_NET2 --dport domain #add INPUT -j ACCEPT -p udp -d $OUTSIDE_NET -s $NTP_NET --dport ntp ####################### ICMP Section ############################### add INPUT -j ACCEPT -p icmp # I hate MS-Windows! Don't log the mindless machines add INPUT -p udp --dport 137 -j DROP add INPUT -p udp --dport 138 -j DROP # Deny but don't log these -- they're from a misbehaving machines add INPUT -s 192.6.38.18 -p udp -j DROP add INPUT -s 192.6.38.19 -p udp -j DROP # A biggie -- deny anything else not from the local network add INPUT -s ! $LOCAL_IP -j LOG add INPUT -s ! $LOCAL_IP -j DROP # These are simply for monitoring iptables -F OUTPUT add OUTPUT -s $OUTSIDE_NET add OUTPUT -s localhost add OUTPUT -s $LOCAL_IP add OUTPUT -s $PRIVATE_NET # QOS # add OUTPUT -p tcp --dport www -t 0x01 0x10 # add OUTPUT -p tcp --dport telnet -t 0x01 0x10 # add OUTPUT -p tcp --dport ftp -t 0x01 0x10 # Set ftp-data for maximum throughput # add OUTPUT -p tcp --dport ftp-data -t 0x01 0x08 } antispoof() { # Turn on Source Address Verification and get spoof protection on # all current and future interfaces. if [ -e /proc/sys/net/ipv4/conf/all/rp_filter ]; then for f in /proc/sys/net/ipv4/conf/*/rp_filter; do echo 1 > $f done fi } # added ipmasq() per http://linuxdocs.org/HOWTOs/IPTABLES-HOWTO-3.html#ss3.1 # - ggg ipmasq() { # firewall() already DROP's everything #iptables -P FORWARD DROP if [ -e /proc/sys/net/ipv4/ip_forward ]; then echo 1 > /proc/sys/net/ipv4/ip_forward else echo "WARN:" $0 ": ip_forward not configured in kernel?" fi add FORWARD -i eth0 -j MASQ } case "$1" in start) echo -n "Starting firewall (iptables):" firewall echo "." # echo -n "Starting IP spoof protection:" # antispoof # echo "." # echo -n "Starting IP Masquerading:" # ipmasq echo "." ;; stop) # Open up the firewall iptables -P INPUT ACCEPT iptables -P OUTPUT ACCEPT iptables -P FORWARD ACCEPT # And flush any existing rules iptables -F INPUT iptables -F OUTPUT iptables -F FORWARD ;; restart) firewall # antispoof # ipmasq ;; *) echo "Usage: /etc/init.d/firewall {start|stop|restart}" exit 1 ;; esac exit 0 From None Date: None From: Subject: [kernel] bug#109: .config used on A500 X-PA-RISC Linux-PR-Message: report 109 X-PA-RISC Linux-PR-Package: kernel X-Loop: daniel_frazier@hp.com Received: via spool by 109-bugs@bugs.parisc-linux.org id=B109.98765266118385 (code B ref 109); Thu, 19 Apr 2001 04:03:02 GMT Date: Wed, 18 Apr 2001 21:51:32 -0600 From: Grant Grundler Message-Id: <200104190351.VAA21424@puffin.external.hp.com> To: 109@bugs.parisc-linux.org # # Automatically generated make config: don't edit # CONFIG_PARISC=y # CONFIG_UID16 is not set # # Code maturity level options # CONFIG_EXPERIMENTAL=y # # Loadable module support # CONFIG_MODULES=y # CONFIG_MODVERSIONS is not set CONFIG_KMOD=y # # Processor type # # CONFIG_PA7100 is not set # CONFIG_PA7200 is not set # CONFIG_PA7100LC is not set CONFIG_PA8X00=y CONFIG_PA20=y CONFIG_PARISC64=y # CONFIG_PDC_NARROW is not set # # General options # # CONFIG_SMP is not set # CONFIG_KWDB is not set CONFIG_GSC=y CONFIG_IOMMU_CCIO=y CONFIG_GSC_LASI=y CONFIG_GSC_WAX=y CONFIG_PCI=y CONFIG_GSC_DINO=y CONFIG_PCI_LBA=y CONFIG_WAX_EISA=y # CONFIG_SUPERIO is not set CONFIG_IOSAPIC=y CONFIG_IOMMU_SBA=y CONFIG_PCI_NAMES=y CONFIG_CHASSIS_LCD_LED=y # # General setup # CONFIG_HOTPLUG=y CONFIG_NET=y CONFIG_SYSVIPC=y # CONFIG_BSD_PROCESS_ACCT is not set CONFIG_SYSCTL=y CONFIG_KCORE_ELF=y CONFIG_BINFMT_ELF=y CONFIG_BINFMT_SOM=y # CONFIG_BINFMT_MISC is not set # CONFIG_PM is not set # # Parallel port support # CONFIG_PARPORT=y # CONFIG_PARPORT_PC is not set # CONFIG_PARPORT_AMIGA is not set # CONFIG_PARPORT_MFC3 is not set # CONFIG_PARPORT_ATARI is not set CONFIG_PARPORT_GSC=y # CONFIG_PARPORT_SUNBPP is not set # CONFIG_PARPORT_OTHER is not set # CONFIG_PARPORT_1284 is not set # # Block devices # # CONFIG_BLK_DEV_FD is not set # CONFIG_BLK_DEV_XD is not set # CONFIG_PARIDE is not set # CONFIG_BLK_CPQ_DA is not set # CONFIG_BLK_CPQ_CISS_DA is not set # CONFIG_BLK_DEV_DAC960 is not set # CONFIG_BLK_DEV_LOOP is not set # CONFIG_BLK_DEV_NBD is not set CONFIG_BLK_DEV_RAM=y CONFIG_BLK_DEV_RAM_SIZE=4096 CONFIG_BLK_DEV_INITRD=y # # Multi-device support (RAID and LVM) # CONFIG_MD=y CONFIG_BLK_DEV_MD=y CONFIG_MD_LINEAR=y CONFIG_MD_RAID0=y CONFIG_MD_RAID1=y CONFIG_MD_RAID5=y # CONFIG_MD_BOOT is not set # CONFIG_AUTODETECT_RAID is not set # CONFIG_BLK_DEV_LVM is not set # CONFIG_LVM_PROC_FS is not set # # Networking options # CONFIG_PACKET=y CONFIG_PACKET_MMAP=y CONFIG_NETLINK=y CONFIG_RTNETLINK=y # CONFIG_NETLINK_DEV is not set CONFIG_NETFILTER=y # CONFIG_NETFILTER_DEBUG is not set # CONFIG_FILTER is not set CONFIG_UNIX=y CONFIG_INET=y # CONFIG_IP_MULTICAST is not set # CONFIG_IP_ADVANCED_ROUTER is not set CONFIG_IP_PNP=y CONFIG_IP_PNP_BOOTP=y # CONFIG_IP_PNP_RARP is not set # CONFIG_NET_IPIP is not set # CONFIG_NET_IPGRE is not set # CONFIG_ARPD is not set # CONFIG_INET_ECN is not set # CONFIG_SYN_COOKIES is not set # # IP: Netfilter Configuration # CONFIG_IP_NF_CONNTRACK=y CONFIG_IP_NF_FTP=y # CONFIG_IP_NF_QUEUE is not set CONFIG_IP_NF_IPTABLES=y CONFIG_IP_NF_MATCH_LIMIT=y CONFIG_IP_NF_MATCH_MAC=y CONFIG_IP_NF_MATCH_MARK=y CONFIG_IP_NF_MATCH_MULTIPORT=y CONFIG_IP_NF_MATCH_TOS=y CONFIG_IP_NF_MATCH_STATE=y # CONFIG_IP_NF_MATCH_UNCLEAN is not set # CONFIG_IP_NF_MATCH_OWNER is not set CONFIG_IP_NF_FILTER=y CONFIG_IP_NF_TARGET_REJECT=y # CONFIG_IP_NF_TARGET_MIRROR is not set CONFIG_IP_NF_NAT=y CONFIG_IP_NF_NAT_NEEDED=y # CONFIG_IP_NF_TARGET_MASQUERADE is not set # CONFIG_IP_NF_TARGET_REDIRECT is not set # CONFIG_IP_NF_MANGLE is not set CONFIG_IP_NF_TARGET_LOG=y # CONFIG_IPV6 is not set # CONFIG_KHTTPD is not set # CONFIG_ATM is not set # # # # CONFIG_IPX is not set # CONFIG_ATALK is not set # CONFIG_DECNET is not set # CONFIG_BRIDGE is not set # CONFIG_X25 is not set # CONFIG_LAPB is not set # CONFIG_LLC is not set # CONFIG_NET_DIVERT is not set # CONFIG_ECONET is not set # CONFIG_WAN_ROUTER is not set # CONFIG_NET_FASTROUTE is not set # CONFIG_NET_HW_FLOWCONTROL is not set # # QoS and/or fair queueing # # CONFIG_NET_SCHED is not set # # SCSI support # CONFIG_SCSI=y # # SCSI support type (disk, tape, CD-ROM) # CONFIG_BLK_DEV_SD=y CONFIG_SD_EXTRA_DEVS=40 CONFIG_CHR_DEV_ST=y # CONFIG_CHR_DEV_OSST is not set CONFIG_BLK_DEV_SR=y # CONFIG_BLK_DEV_SR_VENDOR is not set CONFIG_SR_EXTRA_DEVS=2 CONFIG_CHR_DEV_SG=y # # Some SCSI devices (e.g. CD jukebox) support multiple LUNs # # CONFIG_SCSI_DEBUG_QUEUES is not set # CONFIG_SCSI_MULTI_LUN is not set # CONFIG_SCSI_CONSTANTS is not set # CONFIG_SCSI_LOGGING is not set # # SCSI low-level drivers # # CONFIG_BLK_DEV_3W_XXXX_RAID is not set # CONFIG_SCSI_7000FASST is not set # CONFIG_SCSI_ACARD is not set # CONFIG_SCSI_AHA152X is not set # CONFIG_SCSI_AHA1542 is not set # CONFIG_SCSI_AHA1740 is not set # CONFIG_SCSI_AIC7XXX is not set # CONFIG_SCSI_ADVANSYS is not set # CONFIG_SCSI_IN2000 is not set # CONFIG_SCSI_AM53C974 is not set # CONFIG_SCSI_MEGARAID is not set # CONFIG_SCSI_BUSLOGIC is not set # CONFIG_SCSI_CPQFCTS is not set # CONFIG_SCSI_DMX3191D is not set # CONFIG_SCSI_DTC3280 is not set # CONFIG_SCSI_EATA is not set # CONFIG_SCSI_EATA_DMA is not set # CONFIG_SCSI_EATA_PIO is not set # CONFIG_SCSI_FUTURE_DOMAIN is not set # CONFIG_SCSI_GDTH is not set # CONFIG_SCSI_GENERIC_NCR5380 is not set CONFIG_SCSI_LASI=y CONFIG_SCSI_ZALON=y # CONFIG_SCSI_INITIO is not set # CONFIG_SCSI_INIA100 is not set # CONFIG_SCSI_PPA is not set # CONFIG_SCSI_IMM is not set # CONFIG_SCSI_NCR53C406A is not set # CONFIG_SCSI_NCR53C7xx is not set # CONFIG_SCSI_NCR53C8XX is not set CONFIG_SCSI_SYM53C8XX=y CONFIG_SCSI_NCR53C8XX_DEFAULT_TAGS=8 CONFIG_SCSI_NCR53C8XX_MAX_TAGS=32 CONFIG_SCSI_NCR53C8XX_SYNC=20 # CONFIG_SCSI_NCR53C8XX_PROFILE is not set # CONFIG_SCSI_NCR53C8XX_IOMAPPED is not set # CONFIG_SCSI_NCR53C8XX_PQS_PDS is not set # CONFIG_SCSI_NCR53C8XX_SYMBIOS_COMPAT is not set # CONFIG_SCSI_PAS16 is not set # CONFIG_SCSI_PCI2000 is not set # CONFIG_SCSI_PCI2220I is not set # CONFIG_SCSI_PSI240I is not set # CONFIG_SCSI_QLOGIC_FAS is not set # CONFIG_SCSI_QLOGIC_ISP is not set # CONFIG_SCSI_QLOGIC_FC is not set # CONFIG_SCSI_QLOGIC_1280 is not set # CONFIG_SCSI_SIM710 is not set # CONFIG_SCSI_SYM53C416 is not set # CONFIG_SCSI_DC390T is not set # CONFIG_SCSI_T128 is not set # CONFIG_SCSI_U14_34F is not set # CONFIG_SCSI_DEBUG is not set # # PCMCIA SCSI adapter support # # CONFIG_SCSI_PCMCIA is not set # # Network device support # CONFIG_NETDEVICES=y # # ARCnet devices # # CONFIG_ARCNET is not set # CONFIG_DUMMY is not set # CONFIG_BONDING is not set # CONFIG_EQUALIZER is not set # CONFIG_TUN is not set # CONFIG_ETHERTAP is not set # CONFIG_NET_SB1000 is not set # # Ethernet (10 or 100Mbit) # CONFIG_NET_ETHERNET=y CONFIG_LASI_82596=y # CONFIG_NET_VENDOR_3COM is not set # CONFIG_LANCE is not set # CONFIG_NET_VENDOR_SMC is not set # CONFIG_NET_VENDOR_RACAL is not set # CONFIG_AT1700 is not set # CONFIG_DEPCA is not set # CONFIG_HP100 is not set # CONFIG_NET_ISA is not set CONFIG_NET_PCI=y # CONFIG_PCNET32 is not set # CONFIG_ADAPTEC_STARFIRE is not set # CONFIG_APRICOT is not set # CONFIG_CS89x0 is not set CONFIG_TULIP=y # CONFIG_DE4X5 is not set # CONFIG_DGRS is not set # CONFIG_DM9102 is not set # CONFIG_EEPRO100 is not set # CONFIG_EEPRO100_PM is not set # CONFIG_LNE390 is not set # CONFIG_NATSEMI is not set # CONFIG_NE2K_PCI is not set # CONFIG_NE3210 is not set # CONFIG_ES3210 is not set # CONFIG_8139TOO is not set # CONFIG_RTL8129 is not set # CONFIG_SIS900 is not set # CONFIG_EPIC100 is not set # CONFIG_SUNDANCE is not set # CONFIG_TLAN is not set # CONFIG_VIA_RHINE is not set # CONFIG_WINBOND_840 is not set # CONFIG_HAPPYMEAL is not set # CONFIG_NET_POCKET is not set # # Ethernet (1000 Mbit) # CONFIG_ACENIC=m CONFIG_ACENIC_OMIT_TIGON_I=y # CONFIG_HAMACHI is not set # CONFIG_YELLOWFIN is not set # CONFIG_SK98LIN is not set # CONFIG_FDDI is not set # CONFIG_HIPPI is not set # CONFIG_PLIP is not set CONFIG_PPP=m # CONFIG_PPP_MULTILINK is not set CONFIG_PPP_ASYNC=m CONFIG_PPP_SYNC_TTY=m CONFIG_PPP_DEFLATE=m CONFIG_PPP_BSDCOMP=m CONFIG_PPPOE=m CONFIG_SLIP=m # CONFIG_SLIP_COMPRESSED is not set # CONFIG_SLIP_SMART is not set # CONFIG_SLIP_MODE_SLIP6 is not set # # Wireless LAN (non-hamradio) # # CONFIG_NET_RADIO is not set # # Token Ring devices # # CONFIG_TR is not set # CONFIG_NET_FC is not set # CONFIG_RCPCI is not set # CONFIG_SHAPER is not set # # Wan interfaces # # CONFIG_WAN is not set # # PCMCIA network device support # # CONFIG_NET_PCMCIA is not set # # Input core support # # CONFIG_INPUT is not set # # Character devices # CONFIG_VT=y CONFIG_VT_CONSOLE=y CONFIG_GSC_PS2=y CONFIG_HIL=y CONFIG_SERIAL=y CONFIG_SERIAL_CONSOLE=y CONFIG_SERIAL_GSC=y # CONFIG_SERIAL_EXTENDED is not set # CONFIG_SERIAL_NONSTANDARD is not set CONFIG_UNIX98_PTYS=y CONFIG_UNIX98_PTY_COUNT=256 CONFIG_PRINTER=y # CONFIG_LP_CONSOLE is not set # CONFIG_PPDEV is not set # # I2C support # # CONFIG_I2C is not set # # Mice # # CONFIG_BUSMOUSE is not set # CONFIG_MOUSE is not set # # Joysticks # # CONFIG_JOYSTICK is not set # # Input core support is needed for joysticks # # CONFIG_QIC02_TAPE is not set # # Watchdog Cards # # CONFIG_WATCHDOG is not set CONFIG_GENRTC=y # CONFIG_INTEL_RNG is not set # CONFIG_NVRAM is not set # CONFIG_RTC is not set # CONFIG_DTLK is not set # CONFIG_R3964 is not set # CONFIG_APPLICOM is not set # # Ftape, the floppy tape device driver # # CONFIG_FTAPE is not set # CONFIG_AGP is not set # CONFIG_DRM is not set CONFIG_PCMCIA_SERIAL=y # # PCMCIA character device support # # CONFIG_PCMCIA_SERIAL_CS is not set # # Multimedia devices # # CONFIG_VIDEO_DEV is not set # # File systems # # CONFIG_QUOTA is not set # CONFIG_AUTOFS_FS is not set # CONFIG_AUTOFS4_FS is not set # CONFIG_ADFS_FS is not set # CONFIG_ADFS_FS_RW is not set # CONFIG_AFFS_FS is not set # CONFIG_HFS_FS is not set # CONFIG_BFS_FS is not set # CONFIG_FAT_FS is not set # CONFIG_MSDOS_FS is not set # CONFIG_UMSDOS_FS is not set # CONFIG_VFAT_FS is not set # CONFIG_EFS_FS is not set # CONFIG_JFFS_FS is not set # CONFIG_CRAMFS is not set # CONFIG_RAMFS is not set CONFIG_ISO9660_FS=y # CONFIG_JOLIET is not set # CONFIG_MINIX_FS is not set # CONFIG_NTFS_FS is not set # CONFIG_NTFS_RW is not set # CONFIG_HPFS_FS is not set CONFIG_PROC_FS=y # CONFIG_DEVFS_FS is not set # CONFIG_DEVFS_MOUNT is not set # CONFIG_DEVFS_DEBUG is not set # CONFIG_DEVPTS_FS is not set # CONFIG_QNX4FS_FS is not set # CONFIG_QNX4FS_RW is not set # CONFIG_ROMFS_FS is not set CONFIG_EXT2_FS=y # CONFIG_SYSV_FS is not set # CONFIG_SYSV_FS_WRITE is not set # CONFIG_UDF_FS is not set # CONFIG_UDF_RW is not set # CONFIG_UFS_FS is not set # CONFIG_UFS_FS_WRITE is not set # # Network File Systems # # CONFIG_CODA_FS is not set CONFIG_NFS_FS=y # CONFIG_NFS_V3 is not set CONFIG_ROOT_NFS=y # CONFIG_NFSD is not set # CONFIG_NFSD_V3 is not set CONFIG_SUNRPC=y CONFIG_LOCKD=y # CONFIG_SMB_FS is not set # CONFIG_NCP_FS is not set # CONFIG_NCPFS_PACKET_SIGNING is not set # CONFIG_NCPFS_IOCTL_LOCKING is not set # CONFIG_NCPFS_STRONG is not set # CONFIG_NCPFS_NFS_NS is not set # CONFIG_NCPFS_OS2_NS is not set # CONFIG_NCPFS_SMALLDOS is not set # CONFIG_NCPFS_NLS is not set # CONFIG_NCPFS_EXTRAS is not set # # Partition Types # # CONFIG_PARTITION_ADVANCED is not set CONFIG_MSDOS_PARTITION=y # CONFIG_SMB_NLS is not set # CONFIG_NLS is not set # # Console drivers # # # Frame-buffer support # # CONFIG_FB is not set # CONFIG_STI_CONSOLE is not set CONFIG_DUMMY_CONSOLE=y # # Sound # # CONFIG_SOUND is not set # # Kernel hacking # CONFIG_MAGIC_SYSRQ=y From None Date: None From: Subject: bug#109: [kernel] bug#109: iptables causes trap 27 X-PA-RISC Linux-PR-Message: report 109 X-PA-RISC Linux-PR-Package: kernel X-Loop: daniel_frazier@hp.com Received: via spool by 109-bugs@bugs.parisc-linux.org id=B109.98765449418885 (code B ref 109); Thu, 19 Apr 2001 04:33:01 GMT Message-Id: <200104190421.WAA21523@puffin.external.hp.com> To: Richard Hirst Cc: 109@bugs.parisc-linux.org In-Reply-To: Your message of "Wed, 18 Apr 2001 22:41:44 BST." <20010418224144.Y11226@linuxcare.com> Date: Wed, 18 Apr 2001 22:21:37 -0600 From: Grant Grundler Richard Hirst wrote: > > GR24 00000000000000ff > > GR25 000000000008f001 > > GR26 000119800000e9d4 > > SR1 0000000000000180 (SR0 is the same) > > > > Looks like we tried to copyout the counters info but went past the > > end of the page/space allocated by iptables. Not sure about this > > conclusion though... > > I'd guess gr26 was screwed. Surely the top half should be zero? I thought so too. But then thought I have no clue how we copy from kernel to user space and have sr1 == sr0. Hopefully jsm or willy can comment on this ASAP. I haven't traced the syscall path. This could be a 32-user/64-kernel issue. 0x00011980 would be a valid user app address while 0xe9d4 would not. (I thought all user app addresses were > 0x00010000). Interesting we managed to make more than a dozen calls before it crashed. thanks, grant Grant Grundler parisc-linux {PCI|IOMMU|SMP} hacker +1.408.447.7253 From None Date: None From: Subject: [kernel] bug#109: kernel] bug#109: iptables causes trap 27 X-PA-RISC Linux-PR-Message: report 109 X-PA-RISC Linux-PR-Package: kernel X-Loop: daniel_frazier@hp.com Received: via spool by 109-bugs@bugs.parisc-linux.org id=B109.98766951321161 (code B ref 109); Thu, 19 Apr 2001 08:48:01 GMT Date: Thu, 19 Apr 2001 09:38:31 +0100 From: Richard Hirst To: Grant Grundler , 109@bugs.parisc-linux.org Message-ID: <20010419093831.A11226@linuxcare.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0us In-Reply-To: ; from kernel-admin@lists.parisc-linux.org on Thu, Apr 19, 2001 at 04:42:06AM +0000 On Thu, Apr 19, 2001 at 04:42:06AM +0000, kernel-admin@lists.parisc-linux.org wrote: > X-PA-RISC Linux-PR-Message: report 109 > X-PA-RISC Linux-PR-Package: kernel > X-Loop: daniel_frazier@hp.com > Received: via spool by 109-bugs@bugs.parisc-linux.org id=B109.98765449418885 > (code B ref 109); Thu, 19 Apr 2001 04:33:01 GMT > Message-Id: <200104190421.WAA21523@puffin.external.hp.com> > To: Richard Hirst > Cc: 109@bugs.parisc-linux.org > In-Reply-To: Your message of "Wed, 18 Apr 2001 22:41:44 BST." > <20010418224144.Y11226@linuxcare.com> > Date: Wed, 18 Apr 2001 22:21:37 -0600 > From: Grant Grundler > > Richard Hirst wrote: > > > GR24 00000000000000ff > > > GR25 000000000008f001 > > > GR26 000119800000e9d4 > > > SR1 0000000000000180 (SR0 is the same) > > > > > > Looks like we tried to copyout the counters info but went past the > > > end of the page/space allocated by iptables. Not sure about this > > conclusion though... > > > > I'd guess gr26 was screwed. Surely the top half should be zero? > > I thought so too. But then thought I have no clue how we copy from > kernel to user space and have sr1 == sr0. Hopefully jsm or willy > can comment on this ASAP. But specifying space 0 means the space ID selection is implicit, using the top two bits of the base register to select one of sr4->sr7 - that's my understanding anyway, but I'm still learning (and reading the top of page 3-7 in PA-RISC 2.0). Richard From None Date: None From: Subject: [kernel] bug#109: kernel] bug#109: iptables causes trap 27 X-PA-RISC Linux-PR-Message: report 109 X-PA-RISC Linux-PR-Package: kernel X-Loop: daniel_frazier@hp.com Received: via spool by 109-bugs@bugs.parisc-linux.org id=B109.98767763922886 (code B ref 109); Thu, 19 Apr 2001 11:03:01 GMT Date: Thu, 19 Apr 2001 11:53:58 +0100 From: Richard Hirst To: Grant Grundler , 109@bugs.parisc-linux.org Message-ID: <20010419115358.C11226@linuxcare.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0us In-Reply-To: ; from kernel-admin@lists.parisc-linux.org on Thu, Apr 19, 2001 at 04:42:06AM +0000 On Thu, Apr 19, 2001 at 04:42:06AM +0000, kernel-admin@lists.parisc-linux.org wrote: > X-PA-RISC Linux-PR-Message: report 109 > X-PA-RISC Linux-PR-Package: kernel > X-Loop: daniel_frazier@hp.com > Received: via spool by 109-bugs@bugs.parisc-linux.org id=B109.98765449418885 > (code B ref 109); Thu, 19 Apr 2001 04:33:01 GMT > Message-Id: <200104190421.WAA21523@puffin.external.hp.com> > To: Richard Hirst > Cc: 109@bugs.parisc-linux.org > In-Reply-To: Your message of "Wed, 18 Apr 2001 22:41:44 BST." > <20010418224144.Y11226@linuxcare.com> > Date: Wed, 18 Apr 2001 22:21:37 -0600 > From: Grant Grundler > > Richard Hirst wrote: > > > GR24 00000000000000ff > > > GR25 000000000008f001 > > > GR26 000119800000e9d4 > > > SR1 0000000000000180 (SR0 is the same) > > > > > > Looks like we tried to copyout the counters info but went past the > > > end of the page/space allocated by iptables. Not sure about this > > conclusion though... > > > > I'd guess gr26 was screwed. Surely the top half should be zero? > > I thought so too. But then thought I have no clue how we copy from > kernel to user space and have sr1 == sr0. Hopefully jsm or willy > can comment on this ASAP. > > I haven't traced the syscall path. > This could be a 32-user/64-kernel issue. > 0x00011980 would be a valid user app address while 0xe9d4 would not. Spot on. do_replace() copies a struct ipt_replace from user space and the tries to use a (32 bit) pointer from that struct as somewhere to copy the old counter values to. I think this means we need a syscall wrapper for at least sys_setsockopt, if I've understood how do_replace() gets called. In the meantime, I did this very ugly hack, which should work given the layout of the struct, and the fact that 32 bit userland adds 4 bytes of padding after the counter anyway. counters is at offset 88, struct size is 96 (which explains why the len check at the start of do_replace didn't fail). With this, I could run your firewall script without any obvious problems. Index: net/ipv4/netfilter/ip_tables.c =================================================================== RCS file: /home/cvs/parisc/linux/net/ipv4/netfilter/ip_tables.c,v retrieving revision 1.3 diff -u -r1.3 ip_tables.c --- ip_tables.c 2001/01/25 00:03:55 1.3 +++ ip_tables.c 2001/04/19 10:41:17 @@ -1107,8 +1107,13 @@ IPT_ENTRY_ITERATE(oldinfo->entries, oldinfo->size, cleanup_entry,NULL); vfree(oldinfo); /* Silent error: too late now. */ +#if defined(__hppa__) && defined(__LP64__) + copy_to_user((void *)((long)tmp.counters >> 32), counters, + sizeof(struct ipt_counters) * tmp.num_counters); +#else copy_to_user(tmp.counters, counters, sizeof(struct ipt_counters) * tmp.num_counters); +#endif vfree(counters); up(&ipt_mutex); return 0; From daniel_frazier@hp.com Thu, 19 Apr 2001 13:48:01 -0600 (MDT) Date: Thu, 19 Apr 2001 13:48:01 -0600 (MDT) From: PA-RISC Linux bug Tracking System daniel_frazier@hp.com Subject: [kernel] Processed: IPC problems are same bug Processing commands for control@bugs.parisc-linux.org: > merge 103 107 bug#103: perl build on 64-bit shows possible syscall wrapper problems bug#107: shmctl returns ENOSYS Merged 103 107. > End of message, stopping processing here. Please contact me if you need assistance. dann frazier (administrator, PA-RISC Linux bugs database) From None Date: None From: Subject: [kernel] bug#110: kernel time faster than RTC X-PA-RISC Linux-PR-Message: report 110 X-PA-RISC Linux-PR-Package: kernel X-Loop: daniel_frazier@hp.com Received: via spool by bugs@bugs.parisc-linux.org id=B.98771097612402 (code B ref -1); Thu, 19 Apr 2001 20:18:02 GMT Date: Thu, 19 Apr 2001 14:03:19 -0600 From: Grant Grundler Message-Id: <200104192003.OAA25531@puffin.external.hp.com> To: submit@bugs.parisc-linux.org Package: kernel Version: 20010418 Severity: normal Not sure how much drift between RTC and kernel is acceptable but we are going to have some. But 1 second per 24h seems a bit high to me. That's 30sec per month and even my cheapo casio does better than that. Perhaps the kernel needs to note the drift and on occasion tune the "fudge factor" used in the itimer path. Then assume ntpdate is available to update the RTC. Other thoughts? Workaround is to add a cron job which runs ntpdate and then hwclock daily. To: Andreas Thienemann Subject: Re: [parisc-linux] Clock skew problems Date: Thu, 19 Apr 2001 12:02:54 -0600 From: Grant Grundler Andreas Thienemann wrote: > I'm getting the following message from make: > > make: *** Warning: File `libdb.a' has modification time in the future > (2001-04-19 15:15:33 > 2001-04-19 15:15:04) > > And I have absolutely no Idea why this is happening. Everytime one updates the kernel time and it gets set *back*, make will notice the derived objects (ie libdb.a) are newer than current time and complain. However, I suspect the kernel isn't keeping time perfectly and updating from the HW clock (YMMV: historically, some servers had better RTC crystals) is causing the problem. Having a bad RTC will also look like the kernel isn't keeping time when in fact it is. a500# date Thu Apr 19 11:11:02 MDT 2001 a500# hwclock Thu Apr 19 11:11:01 2001 -1.003308 seconds a500# uptime 11:11:36 up 21:25, 1 user, load average: 0.00, 0.04, 0.04 So not doing too badly - but it needs to be fixed. I'm assuming the A500 has a good RTC. I'll submit a bug for you. grant Andreas Thienemann replied later with: | > I'm assuming the A500 has a good RTC. | I've got a 821/D250 and I don't know anything about the accuracy of the | RTC clock. But hwclock tells me the following: | | [root@hp9000 root]# hwclock | Thu Apr 19 20:17:25 2001 -1.063290 seconds From None Date: None From: Subject: [kernel] bug#109: An IRC conversation with rusty X-PA-RISC Linux-PR-Message: report 109 X-PA-RISC Linux-PR-Package: kernel X-Loop: daniel_frazier@hp.com Received: via spool by 109-bugs@bugs.parisc-linux.org id=B109.98782764614792 (code B ref 109); Sat, 21 Apr 2001 04:48:02 GMT Date: Fri, 20 Apr 2001 22:34:01 -0600 To: 109@bugs.parisc-linux.org Message-ID: <20010420223401.Q4217@zumpano.fc.hp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i From: willy@ldl.fc.hp.com (Matthew Wilcox) willy: it's hacked around in userspace. willy: or should be... works for ultrasparc, anyway. rusty: oh. rusty: doesn't seem to be working for PA :-) (we're the same endianness... wonder what the problem is) Ahh... the ifeq ($(shell uname -m),sparc64) in the Makefile! willy: -DKERNEL_64_USERSPACE_32 8) willy: what does uname -m give? willy@jagu:~/glibc-build$ uname -m parisc64 how about checking for `64' in the uname -m output? i bet you mips has similar issues. willy: Committed in CVS Merci beaucoup. From None Date: None From: Subject: [kernel] bug#109: patch from maintainer X-PA-RISC Linux-PR-Message: report 109 X-PA-RISC Linux-PR-Package: kernel X-Loop: daniel_frazier@hp.com Received: via spool by 109-bugs@bugs.parisc-linux.org id=B109.98783722116730 (code B ref 109); Sat, 21 Apr 2001 07:18:02 GMT Message-Id: <200104210707.BAA01361@puffin.external.hp.com> To: 109@bugs.parisc-linux.org Date: Sat, 21 Apr 2001 01:07:25 -0600 From: Grant Grundler I've built a new iptables binary and the a500 still crashes. Does the Makefile assume the binary produced will be 64-bit? Maybe I botched and ran the wrong iptables binary...will try again later. /etc/init.d/firewall: line 3: 5969 Segmentation fault iptables -A $* iptables[5969]: Protection Id Trap 27 YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI PSW: 00001000000011000000000000001111 r0-3 0000000000000000 0000000000000000 00000000102a316c 000000000008da58 r4-7 0000000010373600 0000000000000070 000000000008d9e8 000000000008d000 r8-11 0000000010373600 0000000000000a58 0000000010373600 000000000008f000 r12-15 0000000000000000 00000000ffffffff 00000000000aee70 0000000000000000 r16-19 0000000000000000 0000000000007514 0000000000005000 000000000000003b r20-23 0000000000000033 0000000000000032 0000000000000001 00000000000e8000 r24-27 00000000000000ff 000000000008f001 0001798000014a3c 0000000010373600 r28-31 000000000000001d 00000000565b4e30 00000000565b5180 0000000000000000 sr0-3 0000000000000180 0000000000000180 0000000000000000 0000000000000180 sr4-7 0000000000000000 0000000000000000 0000000000000000 0000000000000000 IASQ: 0000000000000000 0000000000000000 IAOQ: 00000000102c43a8 00000000102c43a0 IIR: 0f415222 ISR: 0000000000017980 IOR: 0000000000014a3c ORIG_R28: 0000000010150e14 ------- Forwarded Message From: Rusty Russell To: grundler@puffin.external.hp.com Subject: [PATCH] HPPA fix for iptables Date: Sat, 21 Apr 2001 14:38:42 +1000 This should work against 1.2.1a. Yeah, it's a hack... Index: Makefile =================================================================== RCS file: /data/cvs/netfilter/userspace/Makefile,v retrieving revision 1.35 retrieving revision 1.36 diff -u -r1.35 -r1.36 - --- Makefile 2001/04/12 16:06:53 1.35 +++ Makefile 2001/04/21 04:25:09 1.36 @@ -48,6 +48,12 @@ CFLAGS+=-DIPT_MIN_ALIGN=8 -DKERNEL_64_USERSPACE_32 endif +# HPPA hack +ifeq ($(shell uname -m),parisc64) +# The kernel is 64-bit, even though userspace is 32. +CFLAGS+=-DIPT_MIN_ALIGN=8 -DKERNEL_64_USERSPACE_32 +endif + ifndef IPT_LIBDIR IPT_LIBDIR:=$(LIBDIR)/iptables endif - -- Premature optmztion is rt of all evl. --DK ------- End of Forwarded Message From None Date: None From: Subject: [kernel] bug#109: despite iptables patch, trap 27 still occurs X-PA-RISC Linux-PR-Message: report 109 X-PA-RISC Linux-PR-Package: kernel X-Loop: daniel_frazier@hp.com Received: via spool by 109-bugs@bugs.parisc-linux.org id=B109.98787886512339 (code B ref 109); Sat, 21 Apr 2001 18:48:01 GMT Date: Sat, 21 Apr 2001 12:41:01 -0600 From: Grant Grundler Message-Id: <200104211841.MAA03683@puffin.external.hp.com> To: 109@bugs.parisc-linux.org I verfied I was using the iptables binary that was built with the patch applied to the Makefile. Scrounging through the 1.2.1 source I see something else in the Makefile: # Waiting for inclusions in the kernel tree. PENDING_PATCHES:=tos-fix.patch dropped-table.patch seqoffset.patch irc-conntrack -nat.patch # These went in previous kernels. PENDING_PATCHES+=ipv6-fixes.patch.ipv6 masquerade+fwmark.patch nat-overlap.patch ppc-sparc-mangle.patch Perhaps parisc/parisc64 (or __hppa__ rather) also needs a patch? I didn't find any references "sparc" in the sources so I doubt it. Any other ideas? I haven't reviewed the following iptables code yet either: ./include/libipq/libipq.h:#ifdef KERNEL_64_USERSPACE_32 ./libiptc/libiptc.c:#ifdef KERNEL_64_USERSPACE_32 I've pushed my iptables_1.2.1-1_hppa.deb to pehc:~grundler in case someone on a 64-bit box wants to play more with it. Please read issues below before applying this to your system or uploading to pehc:~ftp site. I notice two other problems with the iptables debian packaging: 1) dpkg-buildpackage -b -uc fails with debstd -m make: debstd: Command not found And a500:~# dpkg -l debmake Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad) ||/ Name Version Description +++-==============-==============-============================================ in debmake (no description available) I built and installed debmake_3.6.9_all.deb since I now have xlibs (or whatever it was). uploaded to pehc:~ftp/pub/parisc/binaries/debian/debs. Now the buildpackage complains about a few other things: WARNING: debian/rules file potentially contains a bashism but has no SHELL = ? statement. It might be wise to add a line SHELL = /bin/bash to debian/rules An iptables_1.2.1-1_hppa.deb did get built. However, I'm not going to upload because of the next issue which I'm not going to resolve. 2) We need to deliver two iptables binaries and install the correct one depending on what flavor of kernel is running on the system. The patch to the Makefile means iptables binary encodes the ioctl data structure layout for a 32 or 64-bit kernel. Normally, both sparc64 and parisc64 would provide a "compatibility" wrapper in arch/parisc/kernel/ioctl32.c. So normally, we would only need to deliver a 32-bit iptables binary and 64-bit kernel would fixup the data structure. If sparc and sparc64 share one package, they will have the same problem. grant From None Date: None From: Subject: [kernel] bug#111: kernel: unemulated FP exception X-PA-RISC Linux-PR-Message: report 111 X-PA-RISC Linux-PR-Package: kernel X-Loop: daniel_frazier@hp.com Received: via spool by bugs@bugs.parisc-linux.org id=B.98788623019491 (code B ref -1); Sat, 21 Apr 2001 21:03:01 GMT To: submit@bugs.parisc-linux.org From: LaMont Jones Cc: LaMont Jones MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <17277.987886214.1@cranston.fc.hp.com> Date: Sat, 21 Apr 2001 14:50:14 -0600 Sender: lamont@hp.com Message-Id: <20010421205015.4609F1872C@security.hp.com> Package: kernel Version: 20010418-23:58 Severity: normal Trying to build openldap2 on an A500, I get the following in dmesg, and a hung build. 2667(conftest): Unemulated floating instruction: exception 0x09:2c0220c fmt 0 class 1 subop 1 YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI PSW: 00000000000011001111111100001111 r0-3 0000000000000000 000000004014a31c 0000000040069a17 0000000000004778 r4-7 0000000000000000 000000000000004e 000000000000885e 000000000000477b r8-11 000000000000886e 0000000000000000 00000000000a1ad0 00000000000a2050 r12-15 0000000040136c94 0000000000000000 0000000000000000 0000000040150b18 r16-19 000000000000000a 00000000bff00588 0000000000000001 0000000040150b18 r20-23 0000000000000000 0000000000000028 0000000001010101 ffffffff80808080 r24-27 0000000000000000 00000000401380cb 000000000000477b 000000000000882c r28-31 0000000000000000 0000000000000020 00000000bff00840 000000004000afd3 sr0-3 000000000002b480 000000000002b480 0000000000000000 000000000002b480 sr4-7 000000000002b480 000000000002b480 000000000002b480 000000000002b480 IASQ: 000000000002b480 000000000002b480 IAOQ: 0000000040069b3b 000000004006d46f IIR: 31804804 ISR: 0000000010240000 IOR: 0000006374f00588 ORIG_R28: 00000000bff00001 2667(conftest): Unemulated floating instruction: exception 0x09:2c0220c fmt 0 class 1 subop 1 YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI PSW: 00000000000011001111111100001111 r0-3 0000000000000000 000000004014a31c 0000000040069a17 0000000000004778 r4-7 0000000000000000 000000000000004e 000000000000885e 000000000000477b r8-11 000000000000886e 0000000000000000 00000000000a1ad0 00000000000a2050 r12-15 0000000040136c94 0000000000000000 0000000000000000 0000000040150b18 r16-19 000000000000000a 00000000bff00588 0000000000000001 0000000040150b18 r20-23 0000000000000000 0000000000000028 0000000001010101 ffffffff80808080 r24-27 0000000000000000 00000000401380cb 000000000000477b 000000000000882c r28-31 0000000000000000 0000000000000020 00000000bff00840 000000004000afd3 sr0-3 000000000002b480 000000000002b480 0000000000000000 000000000002b480 sr4-7 000000000002b480 000000000002b480 000000000002b480 000000000002b480 IASQ: 000000000002b480 000000000002b480 IAOQ: 0000000040069b3b 000000004006d46f IIR: 31804804 ISR: 0000000010240000 IOR: 0000006374f00588 ORIG_R28: 00000000bff00001 6410(conftest): Unemulated floating instruction: exception 0x09:2c0220c fmt 0 class 1 subop 1 YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI PSW: 00000000000011001111111100001111 r0-3 0000000000000000 000000004014a31c 0000000040069a17 00000000bff00580 r4-7 0000000000000000 000000000000004e 000000000000871a 0000000000004637 r8-11 000000000000872a 0000000000000000 00000000000ab270 00000000000ab510 r12-15 0000000040136c94 0000000000000000 0000000000000000 0000000040150b18 r16-19 000000000000000a 00000000bff0058c 0000000000000001 0000000040150b18 r20-23 0000000000000000 0000000000000028 0000000001010101 ffffffff80808080 r24-27 0000000000000000 00000000401380cb 0000000000004637 00000000000086e8 r28-31 0000000000000000 0000000000000020 00000000bff00840 000000004000afd3 sr0-3 0000000000026a00 0000000000026a00 0000000000000000 0000000000026a00 sr4-7 0000000000026a00 0000000000026a00 0000000000026a00 0000000000026a00 IASQ: 0000000000026a00 0000000000026a00 IAOQ: 0000000040069b3b 000000004006d46f IIR: 31804804 ISR: 0000000010240080 IOR: 00000038d8b0058c ORIG_R28: 00000000bff00001 Kernel-Version: Linux smallone 2.4.0 #23 Sat Apr 14 23:32:01 MDT 2001 parisc64 unknown lamont From daniel_frazier@hp.com Mon, 23 Apr 2001 23:18:01 -0600 (MDT) Date: Mon, 23 Apr 2001 23:18:01 -0600 (MDT) From: PA-RISC Linux bug Tracking System daniel_frazier@hp.com Subject: [kernel] bug#107: marked as done (shmctl returns ENOSYS) X-PA-RISC Linux-PR-Message: closed 107 Your message dated Mon, 23 Apr 2001 23:05:01 -0600 with message-id <20010423230501.A1166@zumpano.fc.hp.com> and subject line glibc fixed has caused the attached bug report to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what I am talking about this indicates a serious mail system misconfiguration somewhere. Please contact me immediately.) dann frazier (administrator, PA-RISC Linux bugs database) -------------------------------------- Received: (at submit) by bugs.parisc-linux.org; 17 Apr 2001 06:54:02 +0000 >From bod@compusol.com.au Tue Apr 17 00:54:02 2001 Received: from duende.compusol.com.au (compusol.com.au [203.101.1.221]) by dsl2.external.hp.com (Postfix) with ESMTP id 58AB1482A for ; Tue, 17 Apr 2001 00:54:01 -0600 (MDT) Received: from bod by duende.compusol.com.au with local (Exim 3.22 #1 (Debian)) id 14pPM9-0007rz-00 for ; Tue, 17 Apr 2001 16:52:57 +1000 Date: Tue, 17 Apr 2001 16:52:57 +1000 From: Brendan O'Dea To: submit@bugs.parisc-linux.org Subject: shmctl returns ENOSYS Message-ID: <20010417165257.A30220@compusol.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.17i Sender: Brendan O'Dea Package: kernel Version: 2.4.0 Linux j5k 2.4.0 #15 Thu Apr 12 19:26:53 MDT 2001 parisc64 unknown The shmctl in the code below fails with ENOSYS. #include #include #include int main() { int seg; struct shmid_ds buf; if ((seg = shmget(IPC_PRIVATE, 2000, 0700)) < 0) { perror("shmget"); return 1; } if (shmctl(seg, IPC_STAT, &buf) < 0) { perror("shmctl"); return 1; } return 0; } Regards, -- Brendan O'Dea bod@compusol.com.au Compusol Pty. Limited (NSW, Australia) +61 2 9810 3633 --------------------------------------- Received: (at 107-done) by bugs.parisc-linux.org; 24 Apr 2001 05:05:23 +0000 >From willy@ldl.fc.hp.com Mon Apr 23 23:05:23 2001 Received: from atlrel2.hp.com (atlrel2.hp.com [156.153.255.202]) by dsl2.external.hp.com (Postfix) with ESMTP id 4F42B482A for <107-done@bugs.parisc-linux.org>; Mon, 23 Apr 2001 23:05:23 -0600 (MDT) Received: from ldl.fc.hp.com (ldl.fc.hp.com [15.1.50.190]) by atlrel2.hp.com (Postfix) with ESMTP id EEE00AD2 for <107-done@bugs.parisc-linux.org>; Tue, 24 Apr 2001 01:05:03 -0400 (EDT) Received: by ldl.fc.hp.com (Postfix, from userid 22224) id B00665AB08; Mon, 23 Apr 2001 23:05:01 -0600 (MDT) Date: Mon, 23 Apr 2001 23:05:01 -0600 To: 107-done@bugs.parisc-linux.org Subject: glibc fixed Message-ID: <20010423230501.A1166@zumpano.fc.hp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i From: willy@ldl.fc.hp.com (Matthew Wilcox) Glibc now always adds | __IPC64 to the call, so the 32-bit syscall wrappers in the kernel work. From daniel_frazier@hp.com Mon, 23 Apr 2001 23:18:01 -0600 (MDT) Date: Mon, 23 Apr 2001 23:18:01 -0600 (MDT) From: PA-RISC Linux bug Tracking System daniel_frazier@hp.com Subject: [kernel] bug#103: marked as done (perl build on 64-bit shows possible syscall wrapper problems) X-PA-RISC Linux-PR-Message: closed 103 Your message dated Mon, 23 Apr 2001 23:05:01 -0600 with message-id <20010423230501.A1166@zumpano.fc.hp.com> and subject line glibc fixed has caused the attached bug report to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what I am talking about this indicates a serious mail system misconfiguration somewhere. Please contact me immediately.) dann frazier (administrator, PA-RISC Linux bugs database) -------------------------------------- Received: (at submit) by bugs.parisc-linux.org; 13 Apr 2001 19:24:12 +0000 >From bame@fc.hp.com Fri Apr 13 13:24:11 2001 Received: from atlrel1.hp.com (atlrel1.hp.com [156.153.255.210]) by dsl2.external.hp.com (Postfix) with ESMTP id BDEB9482A for ; Fri, 13 Apr 2001 13:24:11 -0600 (MDT) Received: from hpfcla.fc.hp.com (hpfcla.fc.hp.com [15.254.48.2]) by atlrel1.hp.com (Postfix) with ESMTP id 7655BC8C for ; Fri, 13 Apr 2001 15:24:10 -0400 (EDT) Received: from noam.fc.hp.com (mail@noam.fc.hp.com [15.1.52.69]) by hpfcla.fc.hp.com (8.9.3 (PHNE_22672)/8.9.3 SMKit7.01) with ESMTP id NAA18582 for ; Fri, 13 Apr 2001 13:24:09 -0600 (MDT) Received: from localhost ([127.0.0.1] helo=fc.hp.com ident=bame) by noam.fc.hp.com with esmtp (Exim 3.12 #1 (Debian)) id 14o9Av-0006pd-00 for ; Fri, 13 Apr 2001 13:24:09 -0600 To: submit@bugs.parisc-linux.org Subject: perl build on 64-bit shows possible syscall wrapper problems Date: Fri, 13 Apr 2001 13:24:09 -0600 From: Paul Bame Message-Id: package: kernel version: 13apr2001 severity: serious during the perl build on wide kernel the kernel says: shmctl(IPC_STAT(cmd=0x2)) does not support libc5 cmds msgctl() does not support libc5 IPC_STAT semctl(IPC_STAT(cmd=0x2)) does not support libc5-style cmds semctl(IPC_STAT(cmd=0x2)) does not support libc5-style cmds --------------------------------------- Received: (at 107-done) by bugs.parisc-linux.org; 24 Apr 2001 05:05:23 +0000 >From willy@ldl.fc.hp.com Mon Apr 23 23:05:23 2001 Received: from atlrel2.hp.com (atlrel2.hp.com [156.153.255.202]) by dsl2.external.hp.com (Postfix) with ESMTP id 4F42B482A for <107-done@bugs.parisc-linux.org>; Mon, 23 Apr 2001 23:05:23 -0600 (MDT) Received: from ldl.fc.hp.com (ldl.fc.hp.com [15.1.50.190]) by atlrel2.hp.com (Postfix) with ESMTP id EEE00AD2 for <107-done@bugs.parisc-linux.org>; Tue, 24 Apr 2001 01:05:03 -0400 (EDT) Received: by ldl.fc.hp.com (Postfix, from userid 22224) id B00665AB08; Mon, 23 Apr 2001 23:05:01 -0600 (MDT) Date: Mon, 23 Apr 2001 23:05:01 -0600 To: 107-done@bugs.parisc-linux.org Subject: glibc fixed Message-ID: <20010423230501.A1166@zumpano.fc.hp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i From: willy@ldl.fc.hp.com (Matthew Wilcox) Glibc now always adds | __IPC64 to the call, so the 32-bit syscall wrappers in the kernel work. From daniel_frazier@hp.com Tue, 24 Apr 2001 18:18:01 -0600 (MDT) Date: Tue, 24 Apr 2001 18:18:01 -0600 (MDT) From: PA-RISC Linux bug Tracking System daniel_frazier@hp.com Subject: [kernel] Processed: all architectures have the same problem Processing commands for control@bugs.parisc-linux.org: > severity 95 wishlist bug#95: panic when setserial restores config from different hardware Severity set to `wishlist'. > End of message, stopping processing here. Please contact me if you need assistance. dann frazier (administrator, PA-RISC Linux bugs database) From daniel_frazier@hp.com Thu, 26 Apr 2001 16:33:01 -0600 (MDT) Date: Thu, 26 Apr 2001 16:33:01 -0600 (MDT) From: PA-RISC Linux bug Tracking System daniel_frazier@hp.com Subject: [kernel] Processed: your mail Processing commands for control@bugs.parisc-linux.org: > owner 111 bame@debian.org bug#111: kernel: unemulated FP exception Noted your statement that bug has been assigned to bame@debian.org. > End of message, stopping processing here. Please contact me if you need assistance. dann frazier (administrator, PA-RISC Linux bugs database) From daniel_frazier@hp.com Thu, 26 Apr 2001 16:48:01 -0600 (MDT) Date: Thu, 26 Apr 2001 16:48:01 -0600 (MDT) From: PA-RISC Linux bug Tracking System daniel_frazier@hp.com Subject: [kernel] bug#111: marked as done (kernel: unemulated FP exception) X-PA-RISC Linux-PR-Message: closed 111 Your message dated Thu, 26 Apr 2001 16:41:21 -0600 with message-id and subject line Can not reproduce has caused the attached bug report to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what I am talking about this indicates a serious mail system misconfiguration somewhere. Please contact me immediately.) dann frazier (administrator, PA-RISC Linux bugs database) -------------------------------------- Received: (at submit) by bugs.parisc-linux.org; 21 Apr 2001 20:50:30 +0000 >From lamont@hp.com Sat Apr 21 14:50:30 2001 Received: from atlrel2.hp.com (atlrel2.hp.com [156.153.255.202]) by dsl2.external.hp.com (Postfix) with ESMTP id CB0EA482A for ; Sat, 21 Apr 2001 14:50:29 -0600 (MDT) Received: from security.hp.com (cranston.fc.hp.com [15.1.44.224]) by atlrel2.hp.com (Postfix) with ESMTP id 3FC7416A0 for ; Sat, 21 Apr 2001 16:50:19 -0400 (EDT) Received: from cranston.fc.hp.com (cranston.fc.hp.com [15.1.44.224]) by security.hp.com (Postfix) with ESMTP id 4609F1872C; Sat, 21 Apr 2001 14:50:14 -0600 (MDT) To: submit@bugs.parisc-linux.org From: LaMont Jones Cc: LaMont Jones Subject: kernel: unemulated FP exception MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <17277.987886214.1@cranston.fc.hp.com> Date: Sat, 21 Apr 2001 14:50:14 -0600 Sender: lamont@hp.com Message-Id: <20010421205015.4609F1872C@security.hp.com> Package: kernel Version: 20010418-23:58 Severity: normal Trying to build openldap2 on an A500, I get the following in dmesg, and a hung build. 2667(conftest): Unemulated floating instruction: exception 0x09:2c0220c fmt 0 class 1 subop 1 YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI PSW: 00000000000011001111111100001111 r0-3 0000000000000000 000000004014a31c 0000000040069a17 0000000000004778 r4-7 0000000000000000 000000000000004e 000000000000885e 000000000000477b r8-11 000000000000886e 0000000000000000 00000000000a1ad0 00000000000a2050 r12-15 0000000040136c94 0000000000000000 0000000000000000 0000000040150b18 r16-19 000000000000000a 00000000bff00588 0000000000000001 0000000040150b18 r20-23 0000000000000000 0000000000000028 0000000001010101 ffffffff80808080 r24-27 0000000000000000 00000000401380cb 000000000000477b 000000000000882c r28-31 0000000000000000 0000000000000020 00000000bff00840 000000004000afd3 sr0-3 000000000002b480 000000000002b480 0000000000000000 000000000002b480 sr4-7 000000000002b480 000000000002b480 000000000002b480 000000000002b480 IASQ: 000000000002b480 000000000002b480 IAOQ: 0000000040069b3b 000000004006d46f IIR: 31804804 ISR: 0000000010240000 IOR: 0000006374f00588 ORIG_R28: 00000000bff00001 2667(conftest): Unemulated floating instruction: exception 0x09:2c0220c fmt 0 class 1 subop 1 YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI PSW: 00000000000011001111111100001111 r0-3 0000000000000000 000000004014a31c 0000000040069a17 0000000000004778 r4-7 0000000000000000 000000000000004e 000000000000885e 000000000000477b r8-11 000000000000886e 0000000000000000 00000000000a1ad0 00000000000a2050 r12-15 0000000040136c94 0000000000000000 0000000000000000 0000000040150b18 r16-19 000000000000000a 00000000bff00588 0000000000000001 0000000040150b18 r20-23 0000000000000000 0000000000000028 0000000001010101 ffffffff80808080 r24-27 0000000000000000 00000000401380cb 000000000000477b 000000000000882c r28-31 0000000000000000 0000000000000020 00000000bff00840 000000004000afd3 sr0-3 000000000002b480 000000000002b480 0000000000000000 000000000002b480 sr4-7 000000000002b480 000000000002b480 000000000002b480 000000000002b480 IASQ: 000000000002b480 000000000002b480 IAOQ: 0000000040069b3b 000000004006d46f IIR: 31804804 ISR: 0000000010240000 IOR: 0000006374f00588 ORIG_R28: 00000000bff00001 6410(conftest): Unemulated floating instruction: exception 0x09:2c0220c fmt 0 class 1 subop 1 YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI PSW: 00000000000011001111111100001111 r0-3 0000000000000000 000000004014a31c 0000000040069a17 00000000bff00580 r4-7 0000000000000000 000000000000004e 000000000000871a 0000000000004637 r8-11 000000000000872a 0000000000000000 00000000000ab270 00000000000ab510 r12-15 0000000040136c94 0000000000000000 0000000000000000 0000000040150b18 r16-19 000000000000000a 00000000bff0058c 0000000000000001 0000000040150b18 r20-23 0000000000000000 0000000000000028 0000000001010101 ffffffff80808080 r24-27 0000000000000000 00000000401380cb 0000000000004637 00000000000086e8 r28-31 0000000000000000 0000000000000020 00000000bff00840 000000004000afd3 sr0-3 0000000000026a00 0000000000026a00 0000000000000000 0000000000026a00 sr4-7 0000000000026a00 0000000000026a00 0000000000026a00 0000000000026a00 IASQ: 0000000000026a00 0000000000026a00 IAOQ: 0000000040069b3b 000000004006d46f IIR: 31804804 ISR: 0000000010240080 IOR: 00000038d8b0058c ORIG_R28: 00000000bff00001 Kernel-Version: Linux smallone 2.4.0 #23 Sat Apr 14 23:32:01 MDT 2001 parisc64 unknown lamont --------------------------------------- Received: (at 111-close) by bugs.parisc-linux.org; 26 Apr 2001 22:41:26 +0000 >From bame@fc.hp.com Thu Apr 26 16:41:26 2001 Received: from atlrel1.hp.com (atlrel1.hp.com [156.153.255.210]) by dsl2.external.hp.com (Postfix) with ESMTP id 2BEC4482A for <111-close@bugs.parisc-linux.org>; Thu, 26 Apr 2001 16:41:26 -0600 (MDT) Received: from hpfcla.fc.hp.com (hpfcla.fc.hp.com [15.254.48.2]) by atlrel1.hp.com (Postfix) with ESMTP id 59853BD7 for <111-close@bugs.parisc-linux.org>; Thu, 26 Apr 2001 18:41:24 -0400 (EDT) Received: from noam.fc.hp.com (mail@noam.fc.hp.com [15.1.52.69]) by hpfcla.fc.hp.com (8.9.3 (PHNE_22672)/8.9.3 SMKit7.01) with ESMTP id QAA04733 for <111-close@bugs.parisc-linux.org>; Thu, 26 Apr 2001 16:41:22 -0600 (MDT) Received: from localhost ([127.0.0.1] helo=fc.hp.com ident=bame) by noam.fc.hp.com with esmtp (Exim 3.12 #1 (Debian)) id 14suRt-0001Xn-00 for <111-close@bugs.parisc-linux.org>; Thu, 26 Apr 2001 16:41:21 -0600 To: 111-close@bugs.parisc-linux.org Subject: Can not reproduce Date: Thu, 26 Apr 2001 16:41:21 -0600 From: Paul Bame Message-Id: Just built openldap2 just fine from upstream unstable sources. Am guessing the kernel used by the submitter is actually not as new as they thought. -Paul Bame