From owner-freebsd-stable Sun Nov 28 3:56:44 1999 Delivered-To: freebsd-stable@freebsd.org Received: from buffy.tpgi.com.au (buffy.tpgi.com.au [203.12.160.34]) by hub.freebsd.org (Postfix) with ESMTP id E0D8514FAE for ; Sun, 28 Nov 1999 03:56:27 -0800 (PST) (envelope-from eirvine@tpgi.com.au) Received: (from smtpd@localhost) by buffy.tpgi.com.au (8.9.3/8.9.3) id WAA18651 for ; Sun, 28 Nov 1999 22:56:26 +1100 Received: from tar-56k-218.tpgi.com.au(203.26.26.218), claiming to be "tpgi.com.au" via SMTP by buffy.tpgi.com.au, id smtpdd8KDT7; Sun Nov 28 22:56:18 1999 Message-ID: <38411840.1FBCA6B7@tpgi.com.au> Date: Sun, 28 Nov 1999 22:55:44 +1100 From: eirvine X-Mailer: Mozilla 4.6 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Netatalk Input/Output problems. Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, Running Netatalk-asun port on FreeBSD-SATBLE. Hardware is a new Dell 2300 on a 100Base-T network. When another 100Base-T client connects I get the following error on the console: atalkd: afp_openfork: ad_open: Input/Output error. With older 100Base-T clients (actually other Mac fileservers) the speed is still quite good, but with iMac clients the speed goes right down to around 400K a second. Reading *from* the server seems to be about half that again. 10Base-T clients do cause these symptoms. I've also noted the same slowdown and error messages on another FreeBSD-stable machine with a 3Com 3905b (?)card. I've posted this to the netatalk list but got no replies so far. Eddie To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Sun Nov 28 8:33:45 1999 Delivered-To: freebsd-stable@freebsd.org Received: from aurora.sol.net (aurora.sol.net [206.55.65.76]) by hub.freebsd.org (Postfix) with ESMTP id 0828714BE9 for ; Sun, 28 Nov 1999 08:33:14 -0800 (PST) (envelope-from jgreco@aurora.sol.net) Received: (from jgreco@localhost) by aurora.sol.net (8.9.2/8.9.2/SNNS-1.02) id KAA55332; Sun, 28 Nov 1999 10:33:07 -0600 (CST) From: Joe Greco Message-Id: <199911281633.KAA55332@aurora.sol.net> Subject: Re: ahc problems (with vinum?) In-Reply-To: <199911280515.WAA19138_panzer.kdm.org@ns.sol.net> from "Kenneth D. Merry" at "Nov 28, 1999 5:16: 2 am" To: ken@kdm.org (Kenneth D. Merry) Date: Sun, 28 Nov 1999 10:33:07 -0600 (CST) Cc: dgilbert@velocet.ca, stable@freebsd.org X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > David Gilbert wrote... > > >>>>> "Kenneth" =3D=3D Kenneth D Merry writes: > > Kenneth> David Gilbert wrote... > > >> Several times, on a system I've been configuring and testing, I've > > >> got some maddening ahc0 messages. In general, they complain of a > > >> timeout on the bus (I think some packet got lost)... and x SCBs are > > >> aborted. > > >>=20 > > >> At this point, some portion of the SCSI bus is unusable... and the > > >> machine eventually hangs due to this. It does claim that it's > > >> resetting channel A of the ahc0 controller, but I gather it doesn't > > >> do any good. > > >>=20 > > >> I'm running 3.3-STABLE (as of thursday, I think) and am trying to > > >> format and test an 8-drive vinum RAID-5 array. > >=20 > > Kenneth> You'll need to provide more information in order for anyone > > Kenneth> to make sense of your problem. Specifically, please post any > > Kenneth> and all relevant kernel messages, including your controllers > > Kenneth> and drives and the errors you've seen printed out, explain > > Kenneth> your SCSI bus configuration, where it is terminated, etc. > >=20 > > Kenneth> The #1 cause of problems is cabling and termination. The > > Kenneth> second most common cause of problems is bogus drive firmware. > >=20 > > Kenneth> In any case, check your cabling and termination, as that is > > Kenneth> most likely problem. > >=20 > > Regardless of terminaion, the SCSI bus reset should clear > > things... the unit will run for hours just fine... get this one error > > and hang. It is difficult to copy down all the messages --- as they > > don't get copied into the logs (since the SCSI bus is locked). >=20 > Run a serial console on the box. You'll get all the messages that way. > Seriously, there's no way to adequately diagnose the problem without the > specific error messages in question. There are any number of conditions > that can cause a timeout. >=20 > > The controller is the 2940 U2W --- the one with a SE and an LVD > > connector. The LVD bus is connected to a professional 8 drive LVD > > case which is connected and terminated with the supplied cables. The > > SE connector is connected to a single drive. >=20 > And the SE drive is terminated as well? Are the supplied cables and > terminator for the LVD segment LVD cables/terminators? Ken, Just having spent a week debugging a (very) intermittent SCSI bus problem, I agree that I've seen some odd behaviour of this sort. What's even more exasperating is that, at least in some cases, it does appear to recover the one device that erred, but the rest stop functioning. I've got serial consoles on my machines, let me see if I can dig up... /=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\= =08|=08/=08-=08Console: serial port BIOS drive A: is disk0 BIOS drive C: is disk1 BIOS drive D: is disk2 BIOS drive E: is disk3 BIOS drive F: is disk4 BIOS drive G: is disk5 BIOS drive H: is disk6 BIOS drive I: is disk7 BIOS drive J: is disk8 FreeBSD/i386 bootstrap loader, Revision 0.7 640/65472kB (jkh@highwing.cdrom.com, Thu Sep 16 22:16:41 GMT 1999) |=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-= =08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08= /=08-=08\=08|=08/=08Loading /boot/defaults/loader.conf=20 -=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|= =08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/kernel = text=3D0x10a418 /=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\= =08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08= -=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|= =08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08= \=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08= -=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|= =08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08= \=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08data=3D0x17= b48+0x1a97c \=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08syms=3D[0x4+0x1= ee30\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08+0x4+0x= 206b3\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08] \=08|=08/=08-=08\=08|=08/=08 Hit [Enter] to boot immediately, or any other key for command prompt. Type '?' for a list of commands, 'help' for more detailed help. boot: host > boot -s Copyright (c) 1992-1999 FreeBSD Inc. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 3.3-RELEASE #0: Mon Nov 22 13:38:07 CST 1999 root@host:/usr/src/sys/compile/DEMO Timecounter "i8254" frequency 1193182 Hz CPU: Pentium II/Xeon/Celeron (686-class CPU) Origin =3D "GenuineIntel" Id =3D 0x652 Stepping =3D 2 Features=3D0x183fbff real memory =3D 536870912 (524288K bytes) avail memory =3D 519716864 (507536K bytes) Programming 24 pins in IOAPIC #0 FreeBSD/SMP: Multiprocessor motherboard cpu0 (BSP): apic id: 1, version: 0x00040011, at 0xfee00000 cpu1 (AP): apic id: 0, version: 0x00040011, at 0xfee00000 io0 (APIC): apic id: 2, version: 0x00170011, at 0xfec00000 Preloaded elf kernel "kernel" at 0xc027e000. Pentium Pro MTRR support enabled Probing for devices on PCI bus 0: chip0: rev 0x03 on pci0.0.0 chip1: rev 0x03 on pci0.1.0 chip2: rev 0x02 on pci0.4.0 chip3: rev 0x02 on pci0.4.3 ahc0: rev 0x00 int a irq 19 on pci= 0.6.0 ahc0: aic7890/91 Wide Channel A, SCSI Id=3D7, 16/255 SCBs hfa0: rev 0x00 int a irq 19 on pci0.9.0 chip4: rev 0x03 on pci0.1= 0.0 ahc1: rev 0x00 int a irq 17 on pci0.11.0 ahc1: aic7890/91 Wide Channel A, SCSI Id=3D7, 16/255 SCBs ahc2: rev 0x00 int a irq 16 on pci0.12.0 ahc2: aic7880 Wide Channel A, SCSI Id=3D7, 16/255 SCBs Probing for devices on PCI bus 1: Probing for devices on PCI bus 2: de0: rev 0x22 int a irq 18 on pci2.4.0 de0: SMC 9332BDT 21140A [10-100Mb/s] pass 2.2 de0: address 00:e0:29:3c:fb:84 de1: rev 0x22 int a irq 19 on pci2.5.0 de1: SMC 9332BDT 21140A [10-100Mb/s] pass 2.2 de1: address 00:e0:29:3c:fb:85 Probing for PnP devices: Probing for devices on the ISA bus: sc0 on isa sc0: VGA color <16 virtual consoles, flags=3D0x0> atkbdc0 at 0x60-0x6f on motherboard atkbd0 irq 1 on isa psm0 not found sio0 at 0x3f8-0x3ff irq 4 flags 0x10 on isa sio0: type 16550A, console sio1 at 0x2f8-0x2ff irq 3 on isa sio1: type 16550A sio2: configured irq 5 not in bitmap of probed irqs 0 sio2 not found at 0x3e8 sio3: configured irq 9 not in bitmap of probed irqs 0 sio3 not found at 0x2e8 fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa fdc0: FIFO enabled, 8 bytes threshold fd0: 1.44MB 3.5in vga0 at 0x3b0-0x3df maddr 0xa0000 msize 131072 on isa npx0 on motherboard npx0: INT 16 interface we0 at 0x2e8 on isa we0: kernel is keeping watchdog alive APIC_IO: Testing 8254 interrupt delivery APIC_IO: routing 8254 via pin 2 IP packet filtering initialized, divert disabled, rule-based forwarding dis= abled, logging limited to 100 packets/entry by default ccd0-15: Concatenated disk drivers Waiting 2 seconds for SCSI devices to settle SMP: AP CPU #1 Launched! de0: enabling 100baseTX port chda1 at ahc1 bus 0 target 0 lun 0 da1: Fixed Direct Access SCSI-2 device=20 da1: 40.000MB/s transfers (20.000MHz, offset 15, 16bit), Tagged Queueing En= abled da1: 17366MB (35566480 512 byte sectors: 255H 63S/T 2213C) da4 at ahc1 bus 0 target 3 lun 0 da4: Fixed Direct Access SCSI-2 device=20 da4: 40.000MB/s transfers (20.000MHz, offset 15, 16bit), Tagged Queueing En= abled da4: 17366MB (35566480 512 byte sectors: 255H 63S/T 2213C) da7 at ahc1 bus 0 target 6 lun 0 da7: Fixed Direct Access SCSI-2 device=20 da7: 40.000MB/s transfers (20.000MHz, offset 15, 16bit), Tagged Queueing En= abled da7: 17366MB (35566480 512 byte sectors: 255H 63S/T 2213C) da10 at ahc2 bus 0 target 0 lun 0 da10: Fixed Direct Access SCSI-2 device=20 da10: 40.000MB/s transfers (20.000MHz, offset 8, 16bit), Tagged Queueing En= abled da10: 17366MB (35566480 512 byte sectors: 64H 32S/T 17366C) da6 at ahc1 bus 0 target 5 lun 0 da6: Fixed Direct Access SCSI-2 device=20 da6: 40.000MB/s transfers (20.000MHz, offset 15, 16bit), Tagged Queueing En= abled da6: 17366MB (35566480 512 byte sectors: 255H 63S/T 2213C) da13 at ahc2 bus 0 target 3 lun 0 da13: Fixed Direct Access SCSI-2 device=20 da13: 40.000MB/s transfers (20.000MHz, offset 8, 16bit), Tagged Queueing En= abled da13: 17366MB (35566480 512 byte sectors: 64H 32S/T 17366C) da5 at ahc1 bus 0 target 4 lun 0 da5: Fixed Direct Access SCSI-2 device=20 da5: 40.000MB/s transfers (20.000MHz, offset 15, 16bit), Tagged Queueing En= abled da5: 17366MB (35566480 512 byte sectors: 255H 63S/T 2213C) da16 at ahc2 bus 0 target 6 lun 0 da16: Fixed Direct Access SCSI-2 device=20 da16: 40.000MB/s transfers (20.000MHz, offset 8, 16bit), Tagged Queueing En= abled da16: 17366MB (35566480 512 byte sectors: 64H 32S/T 17366C) da3 at ahc1 bus 0 target 2 lun 0 da3: Fixed Direct Access SCSI-2 device=20 da3: 40.000MB/s transfers (20.000MHz, offset 15, 16bit), Tagged Queueing En= abled da3: 17366MB (35566480 512 byte sectors: 255H 63S/T 2213C) da2 at ahc1 bus 0 target 1 lun 0 da2: Fixed Direct Access SCSI-2 device=20 da2: 40.000MB/s transfers (20.000MHz, offset 15, 16bit), Tagged Queueing En= abled da2: 17366MB (35566480 512 byte sectors: 255H 63S/T 2213C) da15 at ahc2 bus 0 target 5 lun 0 da15: Fixed Direct Access SCSI-2 device=20 da15: 40.000MB/s transfers (20.000MHz, offset 8, 16bit), Tagged Queueing En= abled da15: 17366MB (35566480 512 byte sectors: 64H 32S/T 17366C) da9 at ahc1 bus 0 target 9 lun 0 da9: Fixed Direct Access SCSI-2 device=20 da9: 40.000MB/s transfers (20.000MHz, offset 15, 16bit), Tagged Queueing En= abled da9: 17366MB (35566480 512 byte sectors: 255H 63S/T 2213C) da14 at ahc2 bus 0 target 4 lun 0 da14: Fixed Direct Access SCSI-2 device=20 da14: 40.000MB/s transfers (20.000MHz, offset 8, 16bit), Tagged Queueing En= abled da14: 17366MB (35566480 512 byte sectors: 64H 32S/T 17366C) da8 at ahc1 bus 0 target 8 lun 0 da8: Fixed Direct Access SCSI-2 device=20 da8: 40.000MB/s transfers (20.000MHz, offset 15, 16bit), Tagged Queueing En= abled da8: 17366MB (35566480 512 byte sectors: 255H 63S/T 2213C) da12 at ahc2 bus 0 target 2 lun 0 da12: Fixed Direct Access SCSI-2 device=20 da12: 40.000MB/s transfers (20.000MHz, offset 8, 16bit), Tagged Queueing En= abled da12: 17366MB (35566480 512 byte sectors: 64H 32S/T 17366C) da11 at ahc2 bus 0 target 1 lun 0 da11: Fixed Direct Access SCSI-2 device=20 da11: 40.000MB/s transfers (20.000MHz, offset 8, 16bit), Tagged Queueing En= abled da11: 17366MB (35566480 512 byte sectors: 64H 32S/T 17366C) da0 at ahc0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-2 device=20 da0: 40.000MB/s transfers (20.000MHz, offset 15, 16bit), Tagged Queueing En= abled da0: 4357MB (8925000 512 byte sectors: 255H 63S/T 555C) anging root device to da0s2a Enter full pathname of shell or RETURN for /bin/sh:=20 erase ^H, kill ^U, intr ^C # mioy=08 =08=08 =08=08 =08ount -a # cd ~de1: autosense failed: cable problem? jgreco # ls .cshrc .login.env .logout .path run .login .login.env.old .mailrc .profile # sh run& # dd: /dev/rda17: Device not configured dd: /dev/rda18: Device not configured (da13:ahc2:0:3:0): SCB 0xa - timed out in datain phase, SEQADDR =3D=3D 0x110 (da13:ahc2:0:3:0): Other SCB Timeout (da11:ahc2:0:1:0): SCB 0xb - timed out in datain phase, SEQADDR =3D=3D 0x110 (da11:ahc2:0:1:0): Other SCB Timeout (da10:ahc2:0:0:0): SCB 0x9 - timed out in datain phase, SEQADDR =3D=3D 0x110 (da10:ahc2:0:0:0): BDR message in message buffer (da10:ahc2:0:0:0): SCB 0x9 - timed out in datain phase, SEQADDR =3D=3D 0x10f (da10:ahc2:0:0:0): no longer in timeout, status =3D 34b ahc2: Issued Channel A Bus Reset. 7 SCBs aborted (da11:ahc2:0:1:0): SCB 0xa - timed out in datain phase, SEQADDR =3D=3D 0x153 (da11:ahc2:0:1:0): Other SCB Timeout (da10:ahc2:0:0:0): SCB 0x9 - timed out in datain phase, SEQADDR =3D=3D 0x153 (da10:ahc2:0:0:0): BDR message in message buffer (da10:ahc2:0:0:0): SCB 0x9 - timed out in datain phase, SEQADDR =3D=3D 0x153 (da10:ahc2:0:0:0): no longer in timeout, status =3D 34b ahc2: Issued Channel A Bus Reset. 3 SCBs aborted (da10:ahc2:0:0:0): SCB 0xa - timed out in datain phase, SEQADDR =3D=3D 0x110 (da10:ahc2:0:0:0): BDR message in message buffer (da10:ahc2:0:0:0): SCB 0xa - timed out in datain phase, SEQADDR =3D=3D 0x10f (da10:ahc2:0:0:0): no longer in timeout, status =3D 34b ahc2: Issued Channel A Bus Reset. 6 SCBs aborted 4357+1 records in 4357+1 records out 4569600000 bytes transferred in 428.640450 secs (10660683 bytes/sec) # reboot /=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\= =08|=08/=08-=08Console: serial port BIOS drive A: is disk0 BIOS drive C: is disk1 BIOS drive D: is disk2 run is a little script that sucks data in from all SCSI drives with dd and dumps it to /dev/null, in parallel. Now, when the bus reset happens, often the drive listed will actually recover and continue going, but if so, the others will typically stop (but dd is just waiting for data). This isn't written in stone, I've seen all drives drop off, and I've also seen the whole thing recover just fine. I have no idea what the result was for the incident listed above. It was one of dozens of incidents. The "reboot" bit is also mildly interesting. FreeBSD (cam?) seems to have lots of problems halting or rebooting in the event that a device is unavailable or a scbus is hung. I'd guess that it is waiting to flush some buffers or something, except that my tests only do reads - no writes. ... Joe ---------------------------------------------------------------------------= ---- Joe Greco - Systems Administrator jgreco@ns.sol.net Solaria Public Access UNIX - Milwaukee, WI 414/342-4847 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Sun Nov 28 9:36:11 1999 Delivered-To: freebsd-stable@freebsd.org Received: from trooper.velocet.net (trooper.velocet.net [216.126.82.226]) by hub.freebsd.org (Postfix) with ESMTP id 49ED014D4C for ; Sun, 28 Nov 1999 09:36:08 -0800 (PST) (envelope-from dgilbert@trooper.velocet.net) Received: (from dgilbert@localhost) by trooper.velocet.net (8.9.3/8.9.3) id MAA19762; Sun, 28 Nov 1999 12:34:41 -0500 (EST) (envelope-from dgilbert) From: David Gilbert MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14401.26545.58505.622791@trooper.velocet.net> Date: Sun, 28 Nov 1999 12:34:41 -0500 (EST) To: Joe Greco Cc: ken@kdm.org (Kenneth D. Merry), dgilbert@velocet.ca, stable@freebsd.org Subject: Re: ahc problems (with vinum?) In-Reply-To: <199911281633.KAA55332@aurora.sol.net> References: <199911280515.WAA19138_panzer.kdm.org@ns.sol.net> <199911281633.KAA55332@aurora.sol.net> X-Mailer: VM 6.75 under 20.4 "Emerald" XEmacs Lucid Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >>>>> "Joe" == Joe Greco writes: Joe> Just having spent a week debugging a (very) intermittent SCSI bus Joe> problem, I agree that I've seen some odd behaviour of this sort. Joe> What's even more exasperating is that, at least in some cases, it Joe> does appear to recover the one device that erred, but the rest Joe> stop functioning. It would appear that I have replicated the problem again... but I have relagated my serial consoles to other more desparate uses. I will go down and check, but from memory, that is typical of the sequence I see. My drives (just to respond to an earlier question) are correctly terminated with manufacturer's parts --- so the LVD chain is terminated with LVD parts supplied by the LVD enclosure maker. The Ultra chain is terminated by an older drive that supports termination ... and there are only two drives on that chain. I think my short-term solution will be to put a second 2940 in the machine so that the root drive will still be functional when this happens. Dave. -- ============================================================================ |David Gilbert, Velocet Communications. | Two things can only be | |Mail: dgilbert@velocet.net | equal if and only if they | |http://www.velocet.net/~dgilbert | are precisely opposite. | =========================================================GLO================ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Sun Nov 28 9:39:50 1999 Delivered-To: freebsd-stable@freebsd.org Received: from trooper.velocet.net (trooper.velocet.net [216.126.82.226]) by hub.freebsd.org (Postfix) with ESMTP id 2C70A14D4C for ; Sun, 28 Nov 1999 09:39:47 -0800 (PST) (envelope-from dgilbert@trooper.velocet.net) Received: (from dgilbert@localhost) by trooper.velocet.net (8.9.3/8.9.3) id MAA24725; Sun, 28 Nov 1999 12:38:31 -0500 (EST) (envelope-from dgilbert) From: David Gilbert MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14401.26775.527190.403502@trooper.velocet.net> Date: Sun, 28 Nov 1999 12:38:31 -0500 (EST) To: Joe Greco Cc: ken@kdm.org (Kenneth D. Merry), dgilbert@velocet.ca, stable@freebsd.org Subject: Re: ahc problems (with vinum?) In-Reply-To: <199911281633.KAA55332@aurora.sol.net> References: <199911280515.WAA19138_panzer.kdm.org@ns.sol.net> <199911281633.KAA55332@aurora.sol.net> X-Mailer: VM 6.75 under 20.4 "Emerald" XEmacs Lucid Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG ... and just to add a different spin to things... I have seen this on our busier 2 drive systems, but it is much more rare. Dave. -- ============================================================================ |David Gilbert, Velocet Communications. | Two things can only be | |Mail: dgilbert@velocet.net | equal if and only if they | |http://www.velocet.net/~dgilbert | are precisely opposite. | =========================================================GLO================ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Sun Nov 28 9:57:35 1999 Delivered-To: freebsd-stable@freebsd.org Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169]) by hub.freebsd.org (Postfix) with ESMTP id 338F514D4C for ; Sun, 28 Nov 1999 09:57:32 -0800 (PST) (envelope-from ken@panzer.kdm.org) Received: (from ken@localhost) by panzer.kdm.org (8.9.3/8.9.1) id KAA21363; Sun, 28 Nov 1999 10:56:12 -0700 (MST) (envelope-from ken) Message-Id: <199911281756.KAA21363@panzer.kdm.org> Subject: Re: ahc problems (with vinum?) In-Reply-To: <199911281633.KAA55332@aurora.sol.net> from Joe Greco at "Nov 28, 1999 10:33:07 am" To: jgreco@ns.sol.net (Joe Greco) Date: Sun, 28 Nov 1999 10:56:12 -0700 (MST) Cc: dgilbert@velocet.ca, stable@freebsd.org From: "Kenneth D. Merry" X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Joe Greco wrote... > Just having spent a week debugging a (very) intermittent SCSI bus problem, > I agree that I've seen some odd behaviour of this sort. What's even more > exasperating is that, at least in some cases, it does appear to recover > the one device that erred, but the rest stop functioning. > > I've got serial consoles on my machines, let me see if I can dig up... > Okay, you've got two problems that I can see. [ ... ] > Copyright (c) 1992-1999 FreeBSD Inc. > Copyright (c) 1982, 1986, 1989, 1991, 1993 > The Regents of the University of California. All rights reserved. > FreeBSD 3.3-RELEASE #0: Mon Nov 22 13:38:07 CST 1999 > root@host:/usr/src/sys/compile/DEMO The first problem is that you're running 3.3-R with two 7890s. Justin worked around a bug in the 7890 in the Adaptec driver shortly after 3.3 came out. I'd recommend at the very least updating your Adaptec driver, although depending on your circumstances, it might be easier to just update to the latest -stable. That isn't where your problems are showing up, however. (Likely you haven't loaded your system enough to trigger the 7890 problem.) [ ... ] > ahc0: rev 0x00 int a irq 19 on pci0.6.0 > ahc0: aic7890/91 Wide Channel A, SCSI Id=7, 16/255 SCBs > hfa0: rev 0x00 int a irq 19 on pci0.9.0 > chip4: rev 0x03 on pci0.10.0 > ahc1: rev 0x00 int a irq 17 on pci0.11.0 > ahc1: aic7890/91 Wide Channel A, SCSI Id=7, 16/255 SCBs > ahc2: rev 0x00 int a irq 16 on pci0.12.0 > ahc2: aic7880 Wide Channel A, SCSI Id=7, 16/255 SCBs [ ... ] > # sh run& > # dd: /dev/rda17: Device not configured > dd: /dev/rda18: Device not configured > (da13:ahc2:0:3:0): SCB 0xa - timed out in datain phase, SEQADDR == 0x110 > (da13:ahc2:0:3:0): Other SCB Timeout > (da11:ahc2:0:1:0): SCB 0xb - timed out in datain phase, SEQADDR == 0x110 > (da11:ahc2:0:1:0): Other SCB Timeout > (da10:ahc2:0:0:0): SCB 0x9 - timed out in datain phase, SEQADDR == 0x110 > (da10:ahc2:0:0:0): BDR message in message buffer > (da10:ahc2:0:0:0): SCB 0x9 - timed out in datain phase, SEQADDR == 0x10f > (da10:ahc2:0:0:0): no longer in timeout, status = 34b > ahc2: Issued Channel A Bus Reset. 7 SCBs aborted > (da11:ahc2:0:1:0): SCB 0xa - timed out in datain phase, SEQADDR == 0x153 > (da11:ahc2:0:1:0): Other SCB Timeout > (da10:ahc2:0:0:0): SCB 0x9 - timed out in datain phase, SEQADDR == 0x153 > (da10:ahc2:0:0:0): BDR message in message buffer > (da10:ahc2:0:0:0): SCB 0x9 - timed out in datain phase, SEQADDR == 0x153 > (da10:ahc2:0:0:0): no longer in timeout, status = 34b > ahc2: Issued Channel A Bus Reset. 3 SCBs aborted > (da10:ahc2:0:0:0): SCB 0xa - timed out in datain phase, SEQADDR == 0x110 > (da10:ahc2:0:0:0): BDR message in message buffer > (da10:ahc2:0:0:0): SCB 0xa - timed out in datain phase, SEQADDR == 0x10f > (da10:ahc2:0:0:0): no longer in timeout, status = 34b > ahc2: Issued Channel A Bus Reset. 6 SCBs aborted > 4357+1 records in > 4357+1 records out > 4569600000 bytes transferred in 428.640450 secs (10660683 bytes/sec) [ ... ] "Timed out in {datain|dataout} phase" means that a transaction took longer than 60 seconds to complete, and the bus was stuck in datain/dataout phase at the time. This is almost always the result of a cabling or termination problem. So you'll probably want to replace the cable on your Ultra-Wide chain, and verify that the termination is correct. > run is a little script that sucks data in from all SCSI drives with dd and > dumps it to /dev/null, in parallel. > > Now, when the bus reset happens, often the drive listed will actually > recover and continue going, but if so, the others will typically stop (but > dd is just waiting for data). This isn't written in stone, I've seen all > drives drop off, and I've also seen the whole thing recover just fine. > I have no idea what the result was for the incident listed above. It was > one of dozens of incidents. Well, the SCSI layer does its best to recover, but naturally if you've got cabling problems that cause you to get stuck in certain bus phases, it won't be able to recover from everything. > The "reboot" bit is also mildly interesting. FreeBSD (cam?) seems to have > lots of problems halting or rebooting in the event that a device is > unavailable or a scbus is hung. I'd guess that it is waiting to flush some > buffers or something, except that my tests only do reads - no writes. Reboot problems with buffers not getting flushed are generally because of issues in the higher level code. I don't know if they've been fixed in -current or not, and I really don't have a good handle on why it happens. Perhaps someone else has an idea on that one.. Ken -- Kenneth Merry ken@kdm.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Sun Nov 28 9:59:58 1999 Delivered-To: freebsd-stable@freebsd.org Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169]) by hub.freebsd.org (Postfix) with ESMTP id AF45714D4C for ; Sun, 28 Nov 1999 09:59:56 -0800 (PST) (envelope-from ken@panzer.kdm.org) Received: (from ken@localhost) by panzer.kdm.org (8.9.3/8.9.1) id KAA21374; Sun, 28 Nov 1999 10:58:37 -0700 (MST) (envelope-from ken) Message-Id: <199911281758.KAA21374@panzer.kdm.org> Subject: Re: ahc problems (with vinum?) In-Reply-To: <14401.26545.58505.622791@trooper.velocet.net> from David Gilbert at "Nov 28, 1999 12:34:41 pm" To: dgilbert@velocet.ca (David Gilbert) Date: Sun, 28 Nov 1999 10:58:37 -0700 (MST) Cc: jgreco@ns.sol.net (Joe Greco), stable@FreeBSD.ORG From: "Kenneth D. Merry" X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG David Gilbert wrote... > >>>>> "Joe" == Joe Greco writes: > > Joe> Just having spent a week debugging a (very) intermittent SCSI bus > Joe> problem, I agree that I've seen some odd behaviour of this sort. > Joe> What's even more exasperating is that, at least in some cases, it > Joe> does appear to recover the one device that erred, but the rest > Joe> stop functioning. > > It would appear that I have replicated the problem again... but I have > relagated my serial consoles to other more desparate uses. I will go > down and check, but from memory, that is typical of the sequence I > see. If you're seeing the same sorts of problems that Joe is, you probably have a cabling or termination problem. > My drives (just to respond to an earlier question) are correctly > terminated with manufacturer's parts --- so the LVD chain is > terminated with LVD parts supplied by the LVD enclosure maker. The > Ultra chain is terminated by an older drive that supports termination > ... and there are only two drives on that chain. > > I think my short-term solution will be to put a second 2940 in the > machine so that the root drive will still be functional when this > happens. ...And you can get console logs off the machine that way. That will hopefully reveal what sort of trouble is going on. Ken -- Kenneth Merry ken@kdm.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Sun Nov 28 10: 3:53 1999 Delivered-To: freebsd-stable@freebsd.org Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169]) by hub.freebsd.org (Postfix) with ESMTP id DFCE21523B for ; Sun, 28 Nov 1999 10:03:48 -0800 (PST) (envelope-from ken@panzer.kdm.org) Received: (from ken@localhost) by panzer.kdm.org (8.9.3/8.9.1) id LAA21409; Sun, 28 Nov 1999 11:02:21 -0700 (MST) (envelope-from ken) Message-Id: <199911281802.LAA21409@panzer.kdm.org> Subject: Re: ahc problems (with vinum?) In-Reply-To: <14401.26775.527190.403502@trooper.velocet.net> from David Gilbert at "Nov 28, 1999 12:38:31 pm" To: dgilbert@velocet.ca (David Gilbert) Date: Sun, 28 Nov 1999 11:02:21 -0700 (MST) Cc: jgreco@ns.sol.net (Joe Greco), stable@FreeBSD.ORG From: "Kenneth D. Merry" X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG David Gilbert wrote... > ... and just to add a different spin to things... I have seen this on > our busier 2 drive systems, but it is much more rare. Things that appear to be the "same problem" to a casual observer can often actually be the result of two very different problems. For instance, I had two Quantum Atlas II's on one Ultra-Wide chain, and was able to get timeouts and errors from the Adaptec driver on a pretty regular basis. The problem was not cabling or termination, but rather bogus drive firmware. The drives would just kinda lockup under high bus traffic. The problem went away when I upgraded the firmware. That's why I need to see the actual, full errors reported in order to have a chance at guessing what your problem is. Ken -- Kenneth Merry ken@kdm.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Sun Nov 28 11:30:53 1999 Delivered-To: freebsd-stable@freebsd.org Received: from trooper.velocet.net (trooper.velocet.net [216.126.82.226]) by hub.freebsd.org (Postfix) with ESMTP id 1238714EAE for ; Sun, 28 Nov 1999 11:30:47 -0800 (PST) (envelope-from dgilbert@trooper.velocet.net) Received: (from dgilbert@localhost) by trooper.velocet.net (8.9.3/8.9.3) id OAA27199; Sun, 28 Nov 1999 14:30:45 -0500 (EST) (envelope-from dgilbert) From: David Gilbert MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14401.33509.371420.557945@trooper.velocet.net> Date: Sun, 28 Nov 1999 14:30:45 -0500 (EST) To: "Kenneth D. Merry" Cc: dgilbert@velocet.ca (David Gilbert), jgreco@ns.sol.net (Joe Greco), stable@FreeBSD.ORG Subject: Re: ahc problems (with vinum?) In-Reply-To: <199911281802.LAA21409@panzer.kdm.org> References: <14401.26775.527190.403502@trooper.velocet.net> <199911281802.LAA21409@panzer.kdm.org> X-Mailer: VM 6.75 under 20.4 "Emerald" XEmacs Lucid Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >>>>> "Kenneth" == Kenneth D Merry writes: Kenneth> For instance, I had two Quantum Atlas II's on one Ultra-Wide Kenneth> chain, and was able to get timeouts and errors from the Kenneth> Adaptec driver on a pretty regular basis. Kenneth> The problem was not cabling or termination, but rather bogus Kenneth> drive firmware. The drives would just kinda lockup under Kenneth> high bus traffic. The problem went away when I upgraded the Kenneth> firmware. ... these are all Atlas IV's... is there updated firmware for them? How do you upgrade the firmware on SCSI devices? Dave. -- ============================================================================ |David Gilbert, Velocet Communications. | Two things can only be | |Mail: dgilbert@velocet.net | equal if and only if they | |http://www.velocet.net/~dgilbert | are precisely opposite. | =========================================================GLO================ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Sun Nov 28 11:45:18 1999 Delivered-To: freebsd-stable@freebsd.org Received: from aurora.sol.net (aurora.sol.net [206.55.65.76]) by hub.freebsd.org (Postfix) with ESMTP id E1C26150DB for ; Sun, 28 Nov 1999 11:45:15 -0800 (PST) (envelope-from jgreco@aurora.sol.net) Received: (from jgreco@localhost) by aurora.sol.net (8.9.2/8.9.2/SNNS-1.02) id NAA68811; Sun, 28 Nov 1999 13:45:12 -0600 (CST) From: Joe Greco Message-Id: <199911281945.NAA68811@aurora.sol.net> Subject: Re: ahc problems (with vinum?) In-Reply-To: <199911281756.KAA21363@panzer.kdm.org> from "Kenneth D. Merry" at "Nov 28, 1999 10:56:12 am" To: ken@kdm.org (Kenneth D. Merry) Date: Sun, 28 Nov 1999 13:45:12 -0600 (CST) Cc: dgilbert@velocet.ca, stable@freebsd.org X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > Copyright (c) 1992-1999 FreeBSD Inc. > > Copyright (c) 1982, 1986, 1989, 1991, 1993 > > The Regents of the University of California. All rights reserved. > > FreeBSD 3.3-RELEASE #0: Mon Nov 22 13:38:07 CST 1999 > > root@host:/usr/src/sys/compile/DEMO > > The first problem is that you're running 3.3-R with two 7890s. Justin > worked around a bug in the 7890 in the Adaptec driver shortly after 3.3 > came out. I'd recommend at the very least updating your Adaptec driver, > although depending on your circumstances, it might be easier to just update > to the latest -stable. Noted. One is an onboard controller, part of the ASUS P2B-DS. This particular system was supposed to have a 3940, but I didn't have one so I crammed in two 2940-type controllers. Would this also be an issue for a system with the onboard controller and a 3940-type controller? > That isn't where your problems are showing up, however. (Likely you > haven't loaded your system enough to trigger the 7890 problem.) Maybe/maybe not. What might I expect to see from such a problem? I have certainly beat the $#!+ out of these systems in a variety of ways, and have run into some odd things. Most were traceable to SCSI issues. Some didn't get classified. I'm running vinum in a ten-filesystem config on top of the 18 18GB drives, and I copy in data from another machine. I then have an application which mmap()'s the files, doing search and replace ops on the data. Running this app in parallel causes the system to hang (eventually causing the watchdog to expire and reset the system). Running it serially on one fs at a time doesn't. This is probably the most worrisome of the issues I've seen. If you have a recommended revision of the ahc driver you'd like me to try, let me know. > > # sh run& > > # dd: /dev/rda17: Device not configured > > dd: /dev/rda18: Device not configured > > (da13:ahc2:0:3:0): SCB 0xa - timed out in datain phase, SEQADDR == 0x110 > > (da13:ahc2:0:3:0): Other SCB Timeout > > (da11:ahc2:0:1:0): SCB 0xb - timed out in datain phase, SEQADDR == 0x110 > > (da11:ahc2:0:1:0): Other SCB Timeout > > (da10:ahc2:0:0:0): SCB 0x9 - timed out in datain phase, SEQADDR == 0x110 > > (da10:ahc2:0:0:0): BDR message in message buffer > > (da10:ahc2:0:0:0): SCB 0x9 - timed out in datain phase, SEQADDR == 0x10f > > (da10:ahc2:0:0:0): no longer in timeout, status = 34b > > ahc2: Issued Channel A Bus Reset. 7 SCBs aborted > > (da11:ahc2:0:1:0): SCB 0xa - timed out in datain phase, SEQADDR == 0x153 > > (da11:ahc2:0:1:0): Other SCB Timeout > > (da10:ahc2:0:0:0): SCB 0x9 - timed out in datain phase, SEQADDR == 0x153 > > (da10:ahc2:0:0:0): BDR message in message buffer > > (da10:ahc2:0:0:0): SCB 0x9 - timed out in datain phase, SEQADDR == 0x153 > > (da10:ahc2:0:0:0): no longer in timeout, status = 34b > > ahc2: Issued Channel A Bus Reset. 3 SCBs aborted > > (da10:ahc2:0:0:0): SCB 0xa - timed out in datain phase, SEQADDR == 0x110 > > (da10:ahc2:0:0:0): BDR message in message buffer > > (da10:ahc2:0:0:0): SCB 0xa - timed out in datain phase, SEQADDR == 0x10f > > (da10:ahc2:0:0:0): no longer in timeout, status = 34b > > ahc2: Issued Channel A Bus Reset. 6 SCBs aborted > > 4357+1 records in > > 4357+1 records out > > 4569600000 bytes transferred in 428.640450 secs (10660683 bytes/sec) > > [ ... ] > > "Timed out in {datain|dataout} phase" means that a transaction took longer > than 60 seconds to complete, and the bus was stuck in datain/dataout phase > at the time. > > This is almost always the result of a cabling or termination problem. > > So you'll probably want to replace the cable on your Ultra-Wide chain, and > verify that the termination is correct. It's more complex than that. :-) These machines are intended for deployment in remote areas, and realistically I may never see many of them ever again after that point. They are rackmount in Antec PC cases and Kingston 9-bay drive arrays, the drives themselves are mounted in Antec 690 drive modules. This allows for easy replacement/upgrade in the event of problems, and with the exception of this one problem-child machine, has worked out fantastic so far. But it introduces multi-multi variables into the equation. The 3940-to-PC backplate cable, the external cables, the terminators, the internal 9-position Kingston ribbon cable, any of the 9 receiving brackets, any of the 9 drive modules, and any of the 9 drives can potentially be an issue. The Antec drive modules seem to be the typical source of flakiness, about 1:20 seem to give problems. Okay, now, stop rolling your eyes. I know it is ugly from a SCSI perspective, but it is very functional and very useful, not to mention very nice and damn fast. It's hard to build something like that which can also be deployed in a remote location where you'll have to explain to someone who has 1/2 a clue what you want replaced, and how. I prefer the no-screwdriver-required method. > > run is a little script that sucks data in from all SCSI drives with dd and > > dumps it to /dev/null, in parallel. > > > > Now, when the bus reset happens, often the drive listed will actually > > recover and continue going, but if so, the others will typically stop (but > > dd is just waiting for data). This isn't written in stone, I've seen all > > drives drop off, and I've also seen the whole thing recover just fine. > > I have no idea what the result was for the incident listed above. It was > > one of dozens of incidents. > > Well, the SCSI layer does its best to recover, but naturally if you've got > cabling problems that cause you to get stuck in certain bus phases, it > won't be able to recover from everything. I thought a bus reset was supposed to deal with bus phase issues...? But I'm admittedly an armchair SCSI quarterback. I used to see Suns that had a heterogeneous SCSI array of mildly incompatible SCSI devices routinely go through the jam-reset-restart sequence. > > The "reboot" bit is also mildly interesting. FreeBSD (cam?) seems to have > > lots of problems halting or rebooting in the event that a device is > > unavailable or a scbus is hung. I'd guess that it is waiting to flush some > > buffers or something, except that my tests only do reads - no writes. > > Reboot problems with buffers not getting flushed are generally because > of issues in the higher level code. I don't know if they've been fixed > in -current or not, and I really don't have a good handle on why it > happens. Perhaps someone else has an idea on that one.. ... Joe ------------------------------------------------------------------------------- Joe Greco - Systems Administrator jgreco@ns.sol.net Solaria Public Access UNIX - Milwaukee, WI 414/342-4847 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Sun Nov 28 13: 2:40 1999 Delivered-To: freebsd-stable@freebsd.org Received: from trooper.velocet.net (trooper.velocet.net [216.126.82.226]) by hub.freebsd.org (Postfix) with ESMTP id 2FBA814A20 for ; Sun, 28 Nov 1999 13:02:28 -0800 (PST) (envelope-from dgilbert@trooper.velocet.net) Received: (from dgilbert@localhost) by trooper.velocet.net (8.9.3/8.9.3) id QAA31940; Sun, 28 Nov 1999 16:01:11 -0500 (EST) (envelope-from dgilbert) From: David Gilbert MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14401.38935.33670.167936@trooper.velocet.net> Date: Sun, 28 Nov 1999 16:01:11 -0500 (EST) To: Joe Greco Cc: ken@kdm.org (Kenneth D. Merry), dgilbert@velocet.ca, stable@freebsd.org Subject: Re: ahc problems (with vinum?) In-Reply-To: <199911281945.NAA68811@aurora.sol.net> References: <199911281756.KAA21363@panzer.kdm.org> <199911281945.NAA68811@aurora.sol.net> X-Mailer: VM 6.75 under 20.4 "Emerald" XEmacs Lucid Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >>>>> "Joe" == Joe Greco writes: >> > Copyright (c) 1992-1999 FreeBSD Inc. > Copyright (c) 1982, 1986, >> 1989, 1991, 1993 > The Regents of the University of California. All >> rights reserved. > FreeBSD 3.3-RELEASE #0: Mon Nov 22 13:38:07 CST >> 1999 > root@host:/usr/src/sys/compile/DEMO >> >> The first problem is that you're running 3.3-R with two 7890s. >> Justin worked around a bug in the 7890 in the Adaptec driver >> shortly after 3.3 came out. I'd recommend at the very least >> updating your Adaptec driver, although depending on your >> circumstances, it might be easier to just update to the latest >> -stable. Joe> Noted. One is an onboard controller, part of the ASUS P2B-DS. Joe> This particular system was supposed to have a 3940, but I didn't Joe> have one so I crammed in two 2940-type controllers. Would this Joe> also be an issue for a system with the onboard controller and a Joe> 3940-type controller? In my case... this happens with single or multiple controlers and I'm not using the 3940's. I am already running 3.3-STABLE (as of Thursday, I believe) because vinum improved quite a bit after 3.3-RELEASE. Joe> I thought a bus reset was supposed to deal with bus phase Joe> issues...? But I'm admittedly an armchair SCSI quarterback. I Joe> used to see Suns that had a heterogeneous SCSI array of mildly Joe> incompatible SCSI devices routinely go through the Joe> jam-reset-restart sequence. One strange datapoint to add. I was looking at the system in preparation for putting another SCSI controller into it so I could get back the errors... and I removed the external terminator from the LVD chain to read it's label. Immediately, the screen started scrolling again with ahc messages --- This leads me to believe that everything is stuck waiting for the card to un-wedge. Now... I'd already hit CTRL-ALT-DEL to see if I could unwedge things... so the system didn't come back at that point, but I thought it was interesting. The following is my carefully typed sequence of messages from the console: (does not include messages after the terminator was removed). (da5:ahc0:0:9;0): SCB 0xd5 - time out in dataout phase, SEQADDR == 0x5e (da5:ahc0:0:9;0): BDR message in message buffer (da5:ahc0:0:9;0): SCB 0xd5 - time out in dataout phase, SEQADDR == 0x5d (da5:ahc0:0:9;0): no longer in timeout, status 34b ahc0: Issued Channel A Bus Reset. 4 SCBs aborted Dave. -- ============================================================================ |David Gilbert, Velocet Communications. | Two things can only be | |Mail: dgilbert@velocet.net | equal if and only if they | |http://www.velocet.net/~dgilbert | are precisely opposite. | =========================================================GLO================ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Sun Nov 28 13:31:42 1999 Delivered-To: freebsd-stable@freebsd.org Received: from 24-25-220-29.san.rr.com (24-25-220-29.san.rr.com [24.25.220.29]) by hub.freebsd.org (Postfix) with ESMTP id 4D7F114D73 for ; Sun, 28 Nov 1999 13:31:21 -0800 (PST) (envelope-from Doug@gorean.org) Received: from gorean.org (doug@master [10.0.0.2]) by 24-25-220-29.san.rr.com (8.9.3/8.8.8) with ESMTP id NAA16069; Sun, 28 Nov 1999 13:31:00 -0800 (PST) (envelope-from Doug@gorean.org) Message-ID: <38419F12.C5174B0D@gorean.org> Date: Sun, 28 Nov 1999 13:30:58 -0800 From: Doug Barton Organization: Triborough Bridge & Tunnel Authority X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 4.0-CURRENT-0927 i386) X-Accept-Language: en MIME-Version: 1.0 To: Christopher Michaels Cc: "'Adam Szilveszter'" , stable@FreeBSD.ORG Subject: Re: Bug-fixing previous -RELEASE, was Re: speaking of 3.4... References: <6C37EE640B78D2118D2F00A0C90FCB4401105DC8@site2s1> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Christopher Michaels wrote: > Just for the record, just before 3.3 was frozen, I did several "make > worlds" and rebuilt my kernel (my minor contribution to the cause). Please don't minimize the importance of your contribution here. We need many more people to do exactly this during the testing phase prior to a -Release. If we had more people doing this, and reporting their problems in a timely manner we would have much cleaner releases. Doug -- "Welcome to the desert of the real." - Laurence Fishburne as Morpheus, "The Matrix" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Sun Nov 28 13:34:14 1999 Delivered-To: freebsd-stable@freebsd.org Received: from 24-25-220-29.san.rr.com (24-25-220-29.san.rr.com [24.25.220.29]) by hub.freebsd.org (Postfix) with ESMTP id 619F414A16; Sun, 28 Nov 1999 13:34:12 -0800 (PST) (envelope-from Doug@gorean.org) Received: from gorean.org (doug@master [10.0.0.2]) by 24-25-220-29.san.rr.com (8.9.3/8.8.8) with ESMTP id NAA16073; Sun, 28 Nov 1999 13:33:55 -0800 (PST) (envelope-from Doug@gorean.org) Message-ID: <38419FC1.1C63F94@gorean.org> Date: Sun, 28 Nov 1999 13:33:53 -0800 From: Doug Barton Organization: Triborough Bridge & Tunnel Authority X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 4.0-CURRENT-0927 i386) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Michaels Cc: Kris Kennaway , "Forrest W. Christian" , "Jordan K. Hubbard" , Colin , stable@FreeBSD.ORG Subject: Re: Bug-fixing previous -RELEASE, was Re: speaking of 3.4... References: <19991128103420.A95893@phoenix.welearn.com.au> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Jonathan Michaels wrote: > or put anouter way, is it possible to pick and choose the > patches (updates) that come down the cvs pipe every night ? I addressed this in my post yesterday, but I'll mention again briefly that what you suggest is possible for an experienced user, but because it's very likely that Fix A depends on some bits from Fixes B, Q and L what you are suggesting would likely be more difficult than just tracking -Stable in toto. Doug -- "Welcome to the desert of the real." - Laurence Fishburne as Morpheus, "The Matrix" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Sun Nov 28 13:42:18 1999 Delivered-To: freebsd-stable@freebsd.org Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169]) by hub.freebsd.org (Postfix) with ESMTP id E67C015705 for ; Sun, 28 Nov 1999 13:42:09 -0800 (PST) (envelope-from ken@panzer.kdm.org) Received: (from ken@localhost) by panzer.kdm.org (8.9.3/8.9.1) id OAA22259; Sun, 28 Nov 1999 14:40:47 -0700 (MST) (envelope-from ken) Message-Id: <199911282140.OAA22259@panzer.kdm.org> Subject: Re: ahc problems (with vinum?) In-Reply-To: <14401.33509.371420.557945@trooper.velocet.net> from David Gilbert at "Nov 28, 1999 02:30:45 pm" To: dgilbert@velocet.ca (David Gilbert) Date: Sun, 28 Nov 1999 14:40:47 -0700 (MST) Cc: jgreco@ns.sol.net (Joe Greco), stable@FreeBSD.ORG From: "Kenneth D. Merry" X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG David Gilbert wrote... > >>>>> "Kenneth" == Kenneth D Merry writes: > > Kenneth> For instance, I had two Quantum Atlas II's on one Ultra-Wide > Kenneth> chain, and was able to get timeouts and errors from the > Kenneth> Adaptec driver on a pretty regular basis. > > Kenneth> The problem was not cabling or termination, but rather bogus > Kenneth> drive firmware. The drives would just kinda lockup under > Kenneth> high bus traffic. The problem went away when I upgraded the > Kenneth> firmware. > > ... these are all Atlas IV's... is there updated firmware for them? > How do you upgrade the firmware on SCSI devices? Quantum has a utility that'll do it, although it generally takes a bootable DOS floppy and ASPI drivers for your SCSI controllers. I haven't heard of any problems with the Atlas IV that would cause anything other than Quantum's usual bogus queue full behavior, but of course that doesn't mean that there aren't any. Ken -- Kenneth Merry ken@kdm.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Sun Nov 28 13:56: 8 1999 Delivered-To: freebsd-stable@freebsd.org Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169]) by hub.freebsd.org (Postfix) with ESMTP id 88E7C14BEE for ; Sun, 28 Nov 1999 13:56:04 -0800 (PST) (envelope-from ken@panzer.kdm.org) Received: (from ken@localhost) by panzer.kdm.org (8.9.3/8.9.1) id OAA22358; Sun, 28 Nov 1999 14:54:44 -0700 (MST) (envelope-from ken) Message-Id: <199911282154.OAA22358@panzer.kdm.org> Subject: Re: ahc problems (with vinum?) In-Reply-To: <199911281945.NAA68811@aurora.sol.net> from Joe Greco at "Nov 28, 1999 01:45:12 pm" To: jgreco@ns.sol.net (Joe Greco) Date: Sun, 28 Nov 1999 14:54:44 -0700 (MST) Cc: dgilbert@velocet.ca, stable@freebsd.org From: "Kenneth D. Merry" X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Joe Greco wrote... > > > Copyright (c) 1992-1999 FreeBSD Inc. > > > Copyright (c) 1982, 1986, 1989, 1991, 1993 > > > The Regents of the University of California. All rights reserved. > > > FreeBSD 3.3-RELEASE #0: Mon Nov 22 13:38:07 CST 1999 > > > root@host:/usr/src/sys/compile/DEMO > > > > The first problem is that you're running 3.3-R with two 7890s. Justin > > worked around a bug in the 7890 in the Adaptec driver shortly after 3.3 > > came out. I'd recommend at the very least updating your Adaptec driver, > > although depending on your circumstances, it might be easier to just update > > to the latest -stable. > > Noted. One is an onboard controller, part of the ASUS P2B-DS. This > particular system was supposed to have a 3940, but I didn't have one > so I crammed in two 2940-type controllers. Would this also be an issue > for a system with the onboard controller and a 3940-type controller? It will be an issue for any system with a 7890/1 in it. I'm not sure if the same bug affects the 7896/7, so I can't say whether using a 3950 would fix the problem. > > That isn't where your problems are showing up, however. (Likely you > > haven't loaded your system enough to trigger the 7890 problem.) > > Maybe/maybe not. What might I expect to see from such a problem? Well, I know you would probably get some data corruption. I can't remember which list the thread was on, but you can search for "data corruption" and "aic7890" in the -current and -hackers list archives and see what turns up. > I have certainly beat the $#!+ out of these systems in a variety of ways, > and have run into some odd things. Most were traceable to SCSI issues. > Some didn't get classified. I'm running vinum in a ten-filesystem config > on top of the 18 18GB drives, and I copy in data from another machine. I > then have an application which mmap()'s the files, doing search and replace > ops on the data. Running this app in parallel causes the system to hang > (eventually causing the watchdog to expire and reset the system). Running > it serially on one fs at a time doesn't. This is probably the most > worrisome of the issues I've seen. If you have a recommended revision of > the ahc driver you'd like me to try, let me know. Yes, you should run a version of the driver that has Justin's fix from September 20th. Unfortunately, he didn't find the problem before 3.3 came out. > > > (da10:ahc2:0:0:0): SCB 0x9 - timed out in datain phase, SEQADDR == 0x153 > > > (da10:ahc2:0:0:0): no longer in timeout, status = 34b > > > ahc2: Issued Channel A Bus Reset. 3 SCBs aborted > > > (da10:ahc2:0:0:0): SCB 0xa - timed out in datain phase, SEQADDR == 0x110 > > > (da10:ahc2:0:0:0): BDR message in message buffer > > > (da10:ahc2:0:0:0): SCB 0xa - timed out in datain phase, SEQADDR == 0x10f > > > (da10:ahc2:0:0:0): no longer in timeout, status = 34b > > > ahc2: Issued Channel A Bus Reset. 6 SCBs aborted > > > 4357+1 records in > > > 4357+1 records out > > > 4569600000 bytes transferred in 428.640450 secs (10660683 bytes/sec) > > > > [ ... ] > > > > "Timed out in {datain|dataout} phase" means that a transaction took longer > > than 60 seconds to complete, and the bus was stuck in datain/dataout phase > > at the time. > > > > This is almost always the result of a cabling or termination problem. > > > > So you'll probably want to replace the cable on your Ultra-Wide chain, and > > verify that the termination is correct. > > It's more complex than that. :-) These machines are intended for deployment > in remote areas, and realistically I may never see many of them ever again > after that point. They are rackmount in Antec PC cases and Kingston 9-bay > drive arrays, the drives themselves are mounted in Antec 690 drive modules. > This allows for easy replacement/upgrade in the event of problems, and with > the exception of this one problem-child machine, has worked out fantastic > so far. But it introduces multi-multi variables into the equation. The > 3940-to-PC backplate cable, the external cables, the terminators, the > internal 9-position Kingston ribbon cable, any of the 9 receiving brackets, > any of the 9 drive modules, and any of the 9 drives can potentially be an > issue. The Antec drive modules seem to be the typical source of flakiness, > about 1:20 seem to give problems. > > Okay, now, stop rolling your eyes. I know it is ugly from a SCSI > perspective, but it is very functional and very useful, not to mention very > nice and damn fast. It's hard to build something like that which can also > be deployed in a remote location where you'll have to explain to someone who > has 1/2 a clue what you want replaced, and how. I prefer the > no-screwdriver-required method. Oh, I can certainly appreciate the idiot-proof approach. In your situation, it makes a lot of sense. However it'll make it a little more difficult to track down the problem. I'm pretty sure you've got a problem somewhere in your Ultra-Wide chain, and the fact that you've had good success with the same configuration before seems to point to that. It could be bent connector pins or who knows what, but you'll have to track it down one way or another to solve this problem. (i.e. it is unlikely that this is a software problem, since you're having this on a chain driven by a 7880, not a 7890.) > > > run is a little script that sucks data in from all SCSI drives with dd and > > > dumps it to /dev/null, in parallel. > > > > > > Now, when the bus reset happens, often the drive listed will actually > > > recover and continue going, but if so, the others will typically stop (but > > > dd is just waiting for data). This isn't written in stone, I've seen all > > > drives drop off, and I've also seen the whole thing recover just fine. > > > I have no idea what the result was for the incident listed above. It was > > > one of dozens of incidents. > > > > Well, the SCSI layer does its best to recover, but naturally if you've got > > cabling problems that cause you to get stuck in certain bus phases, it > > won't be able to recover from everything. > > I thought a bus reset was supposed to deal with bus phase issues...? But > I'm admittedly an armchair SCSI quarterback. I used to see Suns that had > a heterogeneous SCSI array of mildly incompatible SCSI devices routinely > go through the jam-reset-restart sequence. It does, generally, but if you've got flaky cabling, it's hard to guarantee that the bus reset will fix all of your problems. Ken -- Kenneth Merry ken@kdm.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Sun Nov 28 13:56:31 1999 Delivered-To: freebsd-stable@freebsd.org Received: from trooper.velocet.net (trooper.velocet.net [216.126.82.226]) by hub.freebsd.org (Postfix) with ESMTP id ED84C153A4 for ; Sun, 28 Nov 1999 13:56:23 -0800 (PST) (envelope-from dgilbert@trooper.velocet.net) Received: (from dgilbert@localhost) by trooper.velocet.net (8.9.3/8.9.3) id QAA34141; Sun, 28 Nov 1999 16:56:21 -0500 (EST) (envelope-from dgilbert) From: David Gilbert MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14401.42245.286750.658069@trooper.velocet.net> Date: Sun, 28 Nov 1999 16:56:21 -0500 (EST) To: "Kenneth D. Merry" Cc: stable@freebsd.org Subject: Re: ahc problems (with vinum?) In-Reply-To: <199911282140.OAA22259@panzer.kdm.org> References: <14401.33509.371420.557945@trooper.velocet.net> <199911282140.OAA22259@panzer.kdm.org> X-Mailer: VM 6.75 under 20.4 "Emerald" XEmacs Lucid Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >>>>> "Kenneth" == Kenneth D Merry writes: Kenneth> I haven't heard of any problems with the Atlas IV that would Kenneth> cause anything other than Quantum's usual bogus queue full Kenneth> behavior, but of course that doesn't mean that there aren't Kenneth> any. Hmmm... well... this is very repeatable. This controller now has nothing but the ARRAY of LVD drives using the vendor's cable and terminator. I have another LVD cable and terminator (take came with an HP DAT drive)... I'm going to try them... Basically, cd'ing to a directory on the raid drive and doing dump -0af - /usr | team 1m 8 | restore rf - will cause the problem very repeatably. (da5:ahc1:0:4:0): SCB 0xdc - timed out in dataout phase, SEQADDR == 0x5d (da5:ahc1:0:4:0): Other SCB Timeout (da8:ahc1:0:11:0): SCB 0xe6 - timed out in dataout phase, SEQADDR == 0x5d (da8:ahc1:0:11:0): BDR message in message buffer (da8:ahc1:0:11:0): SCB 0xe6 - timed out in dataout phase, SEQADDR == 0x5e (da8:ahc1:0:11:0): no longer in timeout, status = 34b ahc1: Issued Channel A Bus Reset. 4 SCBs aborted Dave. -- ============================================================================ |David Gilbert, Velocet Communications. | Two things can only be | |Mail: dgilbert@velocet.net | equal if and only if they | |http://www.velocet.net/~dgilbert | are precisely opposite. | =========================================================GLO================ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Sun Nov 28 14: 1:32 1999 Delivered-To: freebsd-stable@freebsd.org Received: from trooper.velocet.net (trooper.velocet.net [216.126.82.226]) by hub.freebsd.org (Postfix) with ESMTP id 65D9314BEE for ; Sun, 28 Nov 1999 14:01:28 -0800 (PST) (envelope-from dgilbert@trooper.velocet.net) Received: (from dgilbert@localhost) by trooper.velocet.net (8.9.3/8.9.3) id RAA34244; Sun, 28 Nov 1999 17:01:26 -0500 (EST) (envelope-from dgilbert) From: David Gilbert MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14401.42550.303044.385649@trooper.velocet.net> Date: Sun, 28 Nov 1999 17:01:26 -0500 (EST) To: "Kenneth D. Merry" Cc: jgreco@ns.sol.net (Joe Greco), dgilbert@velocet.ca, stable@freebsd.org Subject: Re: ahc problems (with vinum?) In-Reply-To: <199911282154.OAA22358@panzer.kdm.org> References: <199911281945.NAA68811@aurora.sol.net> <199911282154.OAA22358@panzer.kdm.org> X-Mailer: VM 6.75 under 20.4 "Emerald" XEmacs Lucid Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >>>>> "Kenneth" == Kenneth D Merry writes: Kenneth> It does, generally, but if you've got flaky cabling, it's Kenneth> hard to guarantee that the bus reset will fix all of your Kenneth> problems. But since removing the terminator seems to unwedge things, it would make sense to look at what state we're getting stuck in. In my case, the components were checked and certified by an ISO 9001 var on Friday. I have also tried several different adaptec cards. Dave. -- ============================================================================ |David Gilbert, Velocet Communications. | Two things can only be | |Mail: dgilbert@velocet.net | equal if and only if they | |http://www.velocet.net/~dgilbert | are precisely opposite. | =========================================================GLO================ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Sun Nov 28 14: 3:52 1999 Delivered-To: freebsd-stable@freebsd.org Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169]) by hub.freebsd.org (Postfix) with ESMTP id 39B2C15381 for ; Sun, 28 Nov 1999 14:03:43 -0800 (PST) (envelope-from ken@panzer.kdm.org) Received: (from ken@localhost) by panzer.kdm.org (8.9.3/8.9.1) id PAA22418; Sun, 28 Nov 1999 15:02:24 -0700 (MST) (envelope-from ken) Message-Id: <199911282202.PAA22418@panzer.kdm.org> Subject: Re: ahc problems (with vinum?) In-Reply-To: <14401.38935.33670.167936@trooper.velocet.net> from David Gilbert at "Nov 28, 1999 04:01:11 pm" To: dgilbert@velocet.ca (David Gilbert) Date: Sun, 28 Nov 1999 15:02:23 -0700 (MST) Cc: jgreco@ns.sol.net (Joe Greco), stable@FreeBSD.ORG From: "Kenneth D. Merry" X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG David Gilbert wrote... > >>>>> "Joe" == Joe Greco writes: > > >> > Copyright (c) 1992-1999 FreeBSD Inc. > Copyright (c) 1982, 1986, > >> 1989, 1991, 1993 > The Regents of the University of California. All > >> rights reserved. > FreeBSD 3.3-RELEASE #0: Mon Nov 22 13:38:07 CST > >> 1999 > root@host:/usr/src/sys/compile/DEMO > >> > >> The first problem is that you're running 3.3-R with two 7890s. > >> Justin worked around a bug in the 7890 in the Adaptec driver > >> shortly after 3.3 came out. I'd recommend at the very least > >> updating your Adaptec driver, although depending on your > >> circumstances, it might be easier to just update to the latest > >> -stable. > > Joe> Noted. One is an onboard controller, part of the ASUS P2B-DS. > Joe> This particular system was supposed to have a 3940, but I didn't > Joe> have one so I crammed in two 2940-type controllers. Would this > Joe> also be an issue for a system with the onboard controller and a > Joe> 3940-type controller? > > In my case... this happens with single or multiple controlers and I'm > not using the 3940's. I am already running 3.3-STABLE (as of > Thursday, I believe) because vinum improved quite a bit after > 3.3-RELEASE. So you shouldn't have a problem with the 7890 bug, since you have the newer driver. Joe's problem is actually with a bus on a non-Ultra2 2940. > Joe> I thought a bus reset was supposed to deal with bus phase > Joe> issues...? But I'm admittedly an armchair SCSI quarterback. I > Joe> used to see Suns that had a heterogeneous SCSI array of mildly > Joe> incompatible SCSI devices routinely go through the > Joe> jam-reset-restart sequence. > > One strange datapoint to add. I was looking at the system in > preparation for putting another SCSI controller into it so I could get > back the errors... and I removed the external terminator from the LVD > chain to read it's label. Immediately, the screen started scrolling > again with ahc messages --- This leads me to believe that everything > is stuck waiting for the card to un-wedge. Now... I'd already hit > CTRL-ALT-DEL to see if I could unwedge things... so the system didn't > come back at that point, but I thought it was interesting. I believe LVD busses need to be properly terminated with an LVD terminator in order to function. So yanking the terminator is a bad idea. :) > The following is my carefully typed sequence of messages from the > console: (does not include messages after the terminator was > removed). > > (da5:ahc0:0:9;0): SCB 0xd5 - time out in dataout phase, SEQADDR == 0x5e > (da5:ahc0:0:9;0): BDR message in message buffer > (da5:ahc0:0:9;0): SCB 0xd5 - time out in dataout phase, SEQADDR == 0x5d > (da5:ahc0:0:9;0): no longer in timeout, status 34b > ahc0: Issued Channel A Bus Reset. 4 SCBs aborted That generally means you have a cabling or termination problem. It could be a bent pin somewhere even. Justin has had trouble with pins on his LVD cables getting bent and causing weird problems. So if you've got a spare cable setup, it might be a good idea to just swap the cables out and see if the problem goes away. Before you put in the new cable set, make sure you check for any bent pins. Specifically, the error above means that the bus probably got stuck for 60 seconds while the controller was trying to write data out to the drive. So it is the fact that your bus is getting stuck in dataout phase that leads me to believe that you've got a cabling or termination problem. Ken -- Kenneth Merry ken@kdm.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Sun Nov 28 14: 8:21 1999 Delivered-To: freebsd-stable@freebsd.org Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169]) by hub.freebsd.org (Postfix) with ESMTP id 0861B14BEE for ; Sun, 28 Nov 1999 14:08:19 -0800 (PST) (envelope-from ken@panzer.kdm.org) Received: (from ken@localhost) by panzer.kdm.org (8.9.3/8.9.1) id PAA22480; Sun, 28 Nov 1999 15:06:47 -0700 (MST) (envelope-from ken) Message-Id: <199911282206.PAA22480@panzer.kdm.org> Subject: Re: ahc problems (with vinum?) In-Reply-To: <14401.42550.303044.385649@trooper.velocet.net> from David Gilbert at "Nov 28, 1999 05:01:26 pm" To: dgilbert@velocet.ca (David Gilbert) Date: Sun, 28 Nov 1999 15:06:46 -0700 (MST) Cc: jgreco@ns.sol.net (Joe Greco), stable@freebsd.org From: "Kenneth D. Merry" X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG David Gilbert wrote... > >>>>> "Kenneth" == Kenneth D Merry writes: > > Kenneth> It does, generally, but if you've got flaky cabling, it's > Kenneth> hard to guarantee that the bus reset will fix all of your > Kenneth> problems. > > But since removing the terminator seems to unwedge things, it would > make sense to look at what state we're getting stuck in. You're getting stuck in dataout phase. > In my case, the components were checked and certified by an ISO 9001 > var on Friday. I have also tried several different adaptec cards. From personal experience, ISO 9001 doesn't mean they're competent. :) (I think it just means they document things.) And you've only tried different cards, not cables. Ken -- Kenneth Merry ken@kdm.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Sun Nov 28 14: 8:51 1999 Delivered-To: freebsd-stable@freebsd.org Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169]) by hub.freebsd.org (Postfix) with ESMTP id D96FE153BE for ; Sun, 28 Nov 1999 14:08:44 -0800 (PST) (envelope-from ken@panzer.kdm.org) Received: (from ken@localhost) by panzer.kdm.org (8.9.3/8.9.1) id PAA22480; Sun, 28 Nov 1999 15:06:47 -0700 (MST) (envelope-from ken) Message-Id: <199911282206.PAA22480@panzer.kdm.org> Subject: Re: ahc problems (with vinum?) In-Reply-To: <14401.42550.303044.385649@trooper.velocet.net> from David Gilbert at "Nov 28, 1999 05:01:26 pm" To: dgilbert@velocet.ca (David Gilbert) Date: Sun, 28 Nov 1999 15:06:46 -0700 (MST) Cc: jgreco@ns.sol.net (Joe Greco), stable@freebsd.org From: "Kenneth D. Merry" X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG David Gilbert wrote... > >>>>> "Kenneth" == Kenneth D Merry writes: > > Kenneth> It does, generally, but if you've got flaky cabling, it's > Kenneth> hard to guarantee that the bus reset will fix all of your > Kenneth> problems. > > But since removing the terminator seems to unwedge things, it would > make sense to look at what state we're getting stuck in. You're getting stuck in dataout phase. > In my case, the components were checked and certified by an ISO 9001 > var on Friday. I have also tried several different adaptec cards. From personal experience, ISO 9001 doesn't mean they're competent. :) (I think it just means they document things.) And you've only tried different cards, not cables. Ken -- Kenneth Merry ken@kdm.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Sun Nov 28 14: 9: 2 1999 Delivered-To: freebsd-stable@freebsd.org Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169]) by hub.freebsd.org (Postfix) with ESMTP id A7061155C0 for ; Sun, 28 Nov 1999 14:08:58 -0800 (PST) (envelope-from ken@panzer.kdm.org) Received: (from ken@localhost) by panzer.kdm.org (8.9.3/8.9.1) id PAA22493; Sun, 28 Nov 1999 15:08:47 -0700 (MST) (envelope-from ken) Message-Id: <199911282208.PAA22493@panzer.kdm.org> Subject: Re: ahc problems (with vinum?) In-Reply-To: <14401.42245.286750.658069@trooper.velocet.net> from David Gilbert at "Nov 28, 1999 04:56:21 pm" To: dgilbert@velocet.ca (David Gilbert) Date: Sun, 28 Nov 1999 15:08:47 -0700 (MST) Cc: stable@FreeBSD.ORG From: "Kenneth D. Merry" X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG David Gilbert wrote... > >>>>> "Kenneth" == Kenneth D Merry writes: > > Kenneth> I haven't heard of any problems with the Atlas IV that would > Kenneth> cause anything other than Quantum's usual bogus queue full > Kenneth> behavior, but of course that doesn't mean that there aren't > Kenneth> any. > > Hmmm... well... this is very repeatable. This controller now has > nothing but the ARRAY of LVD drives using the vendor's cable and > terminator. I have another LVD cable and terminator (take came with > an HP DAT drive)... I'm going to try them... Hopefully that'll fix it. > Basically, cd'ing to a directory on the raid drive and doing > > dump -0af - /usr | team 1m 8 | restore rf - > > will cause the problem very repeatably. > > (da5:ahc1:0:4:0): SCB 0xdc - timed out in dataout phase, SEQADDR == 0x5d > (da5:ahc1:0:4:0): Other SCB Timeout > (da8:ahc1:0:11:0): SCB 0xe6 - timed out in dataout phase, SEQADDR == 0x5d > (da8:ahc1:0:11:0): BDR message in message buffer > (da8:ahc1:0:11:0): SCB 0xe6 - timed out in dataout phase, SEQADDR == 0x5e > (da8:ahc1:0:11:0): no longer in timeout, status = 34b > ahc1: Issued Channel A Bus Reset. 4 SCBs aborted Yep, looks like a cabling problem all right. Ken -- Kenneth Merry ken@kdm.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Sun Nov 28 14:11:49 1999 Delivered-To: freebsd-stable@freebsd.org Received: from aurora.sol.net (aurora.sol.net [206.55.65.76]) by hub.freebsd.org (Postfix) with ESMTP id 6BE4E15362 for ; Sun, 28 Nov 1999 14:11:46 -0800 (PST) (envelope-from jgreco@aurora.sol.net) Received: (from jgreco@localhost) by aurora.sol.net (8.9.2/8.9.2/SNNS-1.02) id QAA79181; Sun, 28 Nov 1999 16:11:40 -0600 (CST) From: Joe Greco Message-Id: <199911282211.QAA79181@aurora.sol.net> Subject: Re: ahc problems (with vinum?) In-Reply-To: <199911282154.OAA22358@panzer.kdm.org> from "Kenneth D. Merry" at "Nov 28, 1999 2:54:44 pm" To: ken@kdm.org (Kenneth D. Merry) Date: Sun, 28 Nov 1999 16:11:40 -0600 (CST) Cc: dgilbert@velocet.ca, stable@freebsd.org X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > Noted. One is an onboard controller, part of the ASUS P2B-DS. This > > particular system was supposed to have a 3940, but I didn't have one > > so I crammed in two 2940-type controllers. Would this also be an issue > > for a system with the onboard controller and a 3940-type controller? > > It will be an issue for any system with a 7890/1 in it. I'm not sure if > the same bug affects the 7896/7, so I can't say whether using a 3950 would > fix the problem. > > > > That isn't where your problems are showing up, however. (Likely you > > > haven't loaded your system enough to trigger the 7890 problem.) > > > > Maybe/maybe not. What might I expect to see from such a problem? > > Well, I know you would probably get some data corruption. I can't remember > which list the thread was on, but you can search for "data corruption" and > "aic7890" in the -current and -hackers list archives and see what turns up. Ok. > > I have certainly beat the $#!+ out of these systems in a variety of ways, > > and have run into some odd things. Most were traceable to SCSI issues. > > Some didn't get classified. I'm running vinum in a ten-filesystem config > > on top of the 18 18GB drives, and I copy in data from another machine. I > > then have an application which mmap()'s the files, doing search and replace > > ops on the data. Running this app in parallel causes the system to hang > > (eventually causing the watchdog to expire and reset the system). Running > > it serially on one fs at a time doesn't. This is probably the most > > worrisome of the issues I've seen. If you have a recommended revision of > > the ahc driver you'd like me to try, let me know. > > Yes, you should run a version of the driver that has Justin's fix from > September 20th. Unfortunately, he didn't find the problem before 3.3 came > out. Ok. > > > > (da10:ahc2:0:0:0): SCB 0x9 - timed out in datain phase, SEQADDR == 0x153 > > > > (da10:ahc2:0:0:0): no longer in timeout, status = 34b > > > > ahc2: Issued Channel A Bus Reset. 3 SCBs aborted > > > > (da10:ahc2:0:0:0): SCB 0xa - timed out in datain phase, SEQADDR == 0x110 > > > > (da10:ahc2:0:0:0): BDR message in message buffer > > > > (da10:ahc2:0:0:0): SCB 0xa - timed out in datain phase, SEQADDR == 0x10f > > > > (da10:ahc2:0:0:0): no longer in timeout, status = 34b > > > > ahc2: Issued Channel A Bus Reset. 6 SCBs aborted > > > > 4357+1 records in > > > > 4357+1 records out > > > > 4569600000 bytes transferred in 428.640450 secs (10660683 bytes/sec) > > > > > > [ ... ] > > > > > > "Timed out in {datain|dataout} phase" means that a transaction took longer > > > than 60 seconds to complete, and the bus was stuck in datain/dataout phase > > > at the time. > > > > > > This is almost always the result of a cabling or termination problem. > > > > > > So you'll probably want to replace the cable on your Ultra-Wide chain, and > > > verify that the termination is correct. > > > > It's more complex than that. :-) These machines are intended for deployment > > in remote areas, and realistically I may never see many of them ever again > > after that point. They are rackmount in Antec PC cases and Kingston 9-bay > > drive arrays, the drives themselves are mounted in Antec 690 drive modules. > > This allows for easy replacement/upgrade in the event of problems, and with > > the exception of this one problem-child machine, has worked out fantastic > > so far. But it introduces multi-multi variables into the equation. The > > 3940-to-PC backplate cable, the external cables, the terminators, the > > internal 9-position Kingston ribbon cable, any of the 9 receiving brackets, > > any of the 9 drive modules, and any of the 9 drives can potentially be an > > issue. The Antec drive modules seem to be the typical source of flakiness, > > about 1:20 seem to give problems. > > > > Okay, now, stop rolling your eyes. I know it is ugly from a SCSI > > perspective, but it is very functional and very useful, not to mention very > > nice and damn fast. It's hard to build something like that which can also > > be deployed in a remote location where you'll have to explain to someone who > > has 1/2 a clue what you want replaced, and how. I prefer the > > no-screwdriver-required method. > > Oh, I can certainly appreciate the idiot-proof approach. In your > situation, it makes a lot of sense. However it'll make it a little more > difficult to track down the problem. Already tracked down and fixed as of last week, it just took some time since the problem only manifested itself after really hammering on the thing for a while. Sorry I didn't make that clear. :-) It makes for a really sucky debug cycle... try "x", hammer on system for hours, watch for errors. You know. Bleah. ... Joe ------------------------------------------------------------------------------- Joe Greco - Systems Administrator jgreco@ns.sol.net Solaria Public Access UNIX - Milwaukee, WI 414/342-4847 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Sun Nov 28 14:15:47 1999 Delivered-To: freebsd-stable@freebsd.org Received: from trooper.velocet.net (trooper.velocet.net [216.126.82.226]) by hub.freebsd.org (Postfix) with ESMTP id E12A214A2C for ; Sun, 28 Nov 1999 14:15:44 -0800 (PST) (envelope-from dgilbert@trooper.velocet.net) Received: (from dgilbert@localhost) by trooper.velocet.net (8.9.3/8.9.3) id RAA34497; Sun, 28 Nov 1999 17:15:42 -0500 (EST) (envelope-from dgilbert) From: David Gilbert MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14401.43406.254826.447466@trooper.velocet.net> Date: Sun, 28 Nov 1999 17:15:42 -0500 (EST) To: "Kenneth D. Merry" Cc: dgilbert@velocet.ca (David Gilbert), jgreco@ns.sol.net (Joe Greco), stable@freebsd.org Subject: Re: ahc problems (with vinum?) In-Reply-To: <199911282206.PAA22480@panzer.kdm.org> References: <14401.42550.303044.385649@trooper.velocet.net> <199911282206.PAA22480@panzer.kdm.org> X-Mailer: VM 6.75 under 20.4 "Emerald" XEmacs Lucid Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >>>>> "Kenneth" == Kenneth D Merry writes: Kenneth> David Gilbert wrote... >> >>>>> "Kenneth" == Kenneth D Merry writes: >> Kenneth> It does, generally, but if you've got flaky cabling, it's Kenneth> hard to guarantee that the bus reset will fix all of your Kenneth> problems. >> But since removing the terminator seems to unwedge things, it >> would make sense to look at what state we're getting stuck in. Kenneth> You're getting stuck in dataout phase. Ok... but... I just went over to the machine with the intention of changing the cables. I removed the terminator just to see... and everything unwedged (although ... this is after I replaced the terminator). Dave. -- ============================================================================ |David Gilbert, Velocet Communications. | Two things can only be | |Mail: dgilbert@velocet.net | equal if and only if they | |http://www.velocet.net/~dgilbert | are precisely opposite. | =========================================================GLO================ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Sun Nov 28 16:14:49 1999 Delivered-To: freebsd-stable@freebsd.org Received: from sand2.sentex.ca (sand2.sentex.ca [209.167.248.3]) by hub.freebsd.org (Postfix) with ESMTP id 7C7BF153D9 for ; Sun, 28 Nov 1999 16:14:24 -0800 (PST) (envelope-from mike@sentex.net) Received: from gravel (ospf-mdt.sentex.net [205.211.164.81]) by sand2.sentex.ca (8.8.8/8.8.8) with SMTP id TAA07192; Sun, 28 Nov 1999 19:13:05 -0500 (EST) (envelope-from mike@sentex.net) Message-Id: <4.1.19991128190819.0518bd70@granite.sentex.ca> X-Sender: mdtancsa@granite.sentex.ca X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Sun, 28 Nov 1999 19:13:02 -0500 To: Joe Greco From: Mike Tancsa Subject: mmap bugs (was Re: ahc problems (with vinum?)) Cc: stable@FreeBSD.ORG, mcgovern@spoon.beta.com In-Reply-To: <199911281945.NAA68811@aurora.sol.net> References: <199911281756.KAA21363@panzer.kdm.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At 02:45 PM 11/28/99 , Joe Greco wrote: >I have certainly beat the $#!+ out of these systems in a variety of ways, >and have run into some odd things. Most were traceable to SCSI issues. >Some didn't get classified. I'm running vinum in a ten-filesystem config >on top of the 18 18GB drives, and I copy in data from another machine. I >then have an application which mmap()'s the files, doing search and replace >ops on the data. Running this app in parallel causes the system to hang >(eventually causing the watchdog to expire and reset the system). Running >it serially on one fs at a time doesn't. This is probably the most >worrisome of the issues I've seen. If you have a recommended revision of >the ahc driver you'd like me to try, let me know. Can you post more details of the mmap bug you have come across ? It would be nice if this were fixed for 3.4. mcgovern@spoon.beta.com is coordinating testing of RCs for 3.4. Perhaps this is a problem that someone could be fix in time. ---Mike ********************************************************************** Mike Tancsa * mike@sentex.net Sentex Communications Corp, * http://www.sentex.net/mike Cambridge, Ontario * 519 651 3400 Canada * To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Sun Nov 28 17: 5:20 1999 Delivered-To: freebsd-stable@freebsd.org Received: from aurora.sol.net (aurora.sol.net [206.55.65.76]) by hub.freebsd.org (Postfix) with ESMTP id 153CD14CA6 for ; Sun, 28 Nov 1999 17:05:15 -0800 (PST) (envelope-from jgreco@aurora.sol.net) Received: (from jgreco@localhost) by aurora.sol.net (8.9.2/8.9.2/SNNS-1.02) id TAA91433; Sun, 28 Nov 1999 19:05:13 -0600 (CST) From: Joe Greco Message-Id: <199911290105.TAA91433@aurora.sol.net> Subject: Re: mmap bugs (was Re: ahc problems (with vinum?)) In-Reply-To: <4.1.19991128190819.0518bd70@granite.sentex.ca> from Mike Tancsa at "Nov 28, 1999 7:13: 2 pm" To: mike@sentex.net (Mike Tancsa) Date: Sun, 28 Nov 1999 19:05:12 -0600 (CST) Cc: stable@FreeBSD.ORG, mcgovern@spoon.beta.com X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > At 02:45 PM 11/28/99 , Joe Greco wrote: > >I have certainly beat the $#!+ out of these systems in a variety of ways, > >and have run into some odd things. Most were traceable to SCSI issues. > >Some didn't get classified. I'm running vinum in a ten-filesystem config > >on top of the 18 18GB drives, and I copy in data from another machine. I > >then have an application which mmap()'s the files, doing search and replace > >ops on the data. Running this app in parallel causes the system to hang > >(eventually causing the watchdog to expire and reset the system). Running > >it serially on one fs at a time doesn't. This is probably the most > >worrisome of the issues I've seen. If you have a recommended revision of > >the ahc driver you'd like me to try, let me know. > > Can you post more details of the mmap bug you have come across ? It would > be nice if this were fixed for 3.4. mcgovern@spoon.beta.com is coordinating > testing of RCs for 3.4. Perhaps this is a problem that someone could be > fix in time. That's the problem, I don't really know what it is. I'd sure love to see it fixed, since anything that can hang a system in such a manner is unsettling, but I don't really have much of an idea what's causing it. It could be a vinum thing, it could be some VM thing, it could be my crappy programming (but userland programs should never puke the kernel). I'll show you the program, the wrapper script, and a description of the specific environment and use. I'll also try to get around to doing some additional debugging, but basically I've been seeing a soft system lockup (userland processes appear to stop running, but console is responsive to vty changes, pressing return results in an echo but the underlying program doesn't seem to receive it and then further keystrokes are not echoed). The kernel is still sane enough to be running my watchdog code, which will eventually cause the system to reboot via software. However, it does a forced termination of the kernel since killing init doesn't work. % cat filesed.c /* * filesed.c * * (c) 1999 Joe Greco and sol.net Network Services. All Rights Reserved. * * mmap a file, hunting for a string. Replace with an identical-length * string. Intended for scouring a spool and replacing Path: hosts after * a load-via-disk-copy. * * filesed 'from' 'to' file [file...] */ #include #include #include #include #include int filesed(file, from, to) char *file, *from, *to; { int count = 0; int slen = strlen(from); struct stat statbuf; caddr_t map; char *here, *end, *ptr; int fd; if (stat(file, &statbuf) < 0) { perror(file); return(-1); } if ((fd = open(file, O_RDWR, 0)) < 0) { perror(file); return(-1); } if (((int)(map = mmap(NULL, statbuf.st_size, PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0))) == -1) { close(fd); perror(file); return(-1); } /* Search and replace. */ here = map; end = map + statbuf.st_size - slen; while (here < end) { ptr = memchr(here, *from, end - here); if (! ptr) { here = end; } else { if (! memcmp(ptr, from, slen)) { memcpy(ptr, to, slen); count++; } here = ptr + 1; } } if (munmap(map, statbuf.st_size) < 0) { perror(file); } if (count) { printf("%s: %d change%s\n", file, count, count == 1 ? "" : "s"); } else { printf("%s: no changes\n", file); } return(0); } int main(argc, argv) int argc; char *argv[]; { int slen; char *from; char *to; if (argc < 4) { fprintf(stderr, "usage: filesed [file ...]\n"); exit(1); } from = argv[1]; to = argv[2]; slen = strlen(from); if (slen != strlen(to)) { fprintf(stderr, "error: string lengths must be identical\n"); exit(1); } if (! slen) { fprintf(stderr, "error: zero-length string unacceptable\n"); exit(1); } argv += 3; argc -= 3; while (argc) { filesed(*argv, from, to); argv++; argc--; } } % cat fixpath.sh #! /bin/sh - case "${1}" in spool*|bins*) continue;; *) exit 1;; esac for i in /news/spool/news/N.*; do find ${i} -type f -name 'B.*' -print | xargs ./filesed $1 $2 & done What happens is I've got a system that looks like this: % df -k Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/da0s2a 158783 21626 124455 15% / /dev/da0s2h 772075 97 710212 0% /export/home/u0 /dev/da0s2e 198399 143748 38780 79% /usr /dev/da0s2f 119055 8264 101267 8% /usr/local /dev/da0s2g 1016303 3078 931921 0% /var procfs 4 4 0 100% /proc /dev/vinum/news 14142987 2120003 12022984 15% /news /dev/vinum/n0 31821718 14782554 17039164 46% /news/spool/news/N.00 /dev/vinum/n1 31821718 14921680 16900038 47% /news/spool/news/N.01 /dev/vinum/n2 31821718 15535917 16285801 49% /news/spool/news/N.02 /dev/vinum/n3 31821718 14769382 17052336 46% /news/spool/news/N.03 /dev/vinum/n4 31821718 15435368 16386350 49% /news/spool/news/N.04 /dev/vinum/n5 31821718 14619211 17202507 46% /news/spool/news/N.05 /dev/vinum/n6 31821718 15547271 16274447 49% /news/spool/news/N.06 /dev/vinum/n7 31821718 14721799 17099919 46% /news/spool/news/N.07 /dev/vinum/n8 31821718 1 31821717 0% /news/spool/news/N.08 which is an ASUS P2B-DS with the previously mentioned dmesg. Each "n?" partition is striped across two 18GB drives, striped across controllers too. The data on the "n?" partitions is Usenet article data, stored in Matt Dillon's Diablo format - many articles per file, maybe 10000 files per FS. To install a new server, I build it and then load each filesystem across the network. I can't afford to lose months worth of data. The only downside to this is that the Path: lines are then wrong, since they'll say that the article came in on "server1" but the data is actually now on "server2" due to my cross-network-copy. Since I'm working in a distributed server environment and occasionally need to do debugging, I felt it necessary to change these files. Since this is a nice fast SMP dual PII/400, and there's lots of drives, the theoretical limiting factors are the SCSI busses and the CPU. So I decided to try running my little filesed program in parallel on all filesystems, maximizing the concurrency and hopefully maxxing out the CPU or the SCSI busses. Instead, it hangs the $*!*$# system after doing a few thousand files. If you have a suggested test/debug methodology, please let me know. I can also arrange for console access if someone wishes to poke at the machine. I'm also willing to try patches/etc. I'm just not quite sure what to do. ... Joe ------------------------------------------------------------------------------- Joe Greco - Systems Administrator jgreco@ns.sol.net Solaria Public Access UNIX - Milwaukee, WI 414/342-4847 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Sun Nov 28 21:16: 7 1999 Delivered-To: freebsd-stable@freebsd.org Received: from lh2.rdc1.ct.home.com (ha2.rdc1.ct.home.com [24.2.0.67]) by hub.freebsd.org (Postfix) with ESMTP id 4658715418 for ; Sun, 28 Nov 1999 21:16:05 -0800 (PST) (envelope-from tsikora@home.com) Received: from home.com ([24.2.168.186]) by lh2.rdc1.ct.home.com (InterMail v4.01.01.00 201-229-111) with ESMTP id <19991129051605.NTRU1992.lh2.rdc1.ct.home.com@home.com> for ; Sun, 28 Nov 1999 21:16:05 -0800 Message-ID: <38420C24.A95C034C@home.com> Date: Mon, 29 Nov 1999 00:16:20 -0500 From: Ted Sikora Reply-To: tsikora@powerusersbbs.com Organization: Jtl Development X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.2.13 i686) X-Accept-Language: en-US,en-GB MIME-Version: 1.0 To: FreeBSD-stable@FreeBSD.ORG Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG subscribe tsikora@home.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Sun Nov 28 21:18:51 1999 Delivered-To: freebsd-stable@freebsd.org Received: from fep9.mail.ozemail.net (fep9.mail.ozemail.net [203.2.192.103]) by hub.freebsd.org (Postfix) with ESMTP id D698F15441 for ; Sun, 28 Nov 1999 21:18:47 -0800 (PST) (envelope-from count@ozemail.com.au) Received: from mycroft.marshall.id.au (slmlb44p15.ozemail.com.au [210.84.140.16]) by fep9.mail.ozemail.net (8.9.0/8.6.12) with SMTP id QAA06354 for ; Mon, 29 Nov 1999 16:18:42 +1100 (EST) From: "Geoffrey C. Marshall" Organization: Tobacco Chewers and Body Painters Association To: freebsd-stable@freebsd.org Subject: Re: mmap bugs (was Re: ahc problems (with vinum?)) Date: Mon, 29 Nov 1999 16:08:04 +1100 X-Mailer: KMail [version 1.0.21] Content-Type: text/plain References: <199911290105.TAA91433@aurora.sol.net> MIME-Version: 1.0 Message-Id: <99112916183700.06280@mycroft.marshall.id.au> Content-Transfer-Encoding: 8bit Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 29 Nov 1999, Joe Greco wrote: > > I'll show you the program, the wrapper script, and a description of the > specific environment and use. I'll also try to get around to doing some > additional debugging, but basically I've been seeing a soft system lockup > (userland processes appear to stop running, but console is responsive to > vty changes, pressing return results in an echo but the underlying program > doesn't seem to receive it and then further keystrokes are not echoed). That matches exactly a problem that occurs (rarely) to me when I have mulitiple Netscape windows open and in use. That is the "Package" Netscape not the port. Both O/S and package were off the October 3.3 release. When the system gets to this state, the only option is a hard reboot, right? I had assumed I had stuffed some configuration issue. If it *is* the same problem, I do run a twin Adaptec 2940UW but not vinum. I do however us both SCSI busses. If you think it might be related and I can supply more information, please let me know. Geoff -- count@ozemail.com.au Practice random acts of kindness and senseless beauty. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Mon Nov 29 2:24:35 1999 Delivered-To: freebsd-stable@freebsd.org Received: from axl.noc.iafrica.com (axl.noc.iafrica.com [196.31.1.175]) by hub.freebsd.org (Postfix) with ESMTP id 46D7614BC5 for ; Mon, 29 Nov 1999 02:24:29 -0800 (PST) (envelope-from sheldonh@axl.noc.iafrica.com) Received: from sheldonh (helo=axl.noc.iafrica.com) by axl.noc.iafrica.com with local-esmtp (Exim 3.040 #1) id 11sNyR-0006iS-00; Mon, 29 Nov 1999 12:23:59 +0200 From: Sheldon Hearn To: Kai Voigt Cc: stable@FreeBSD.ORG Subject: Re: finger(1) not RFC compliant In-reply-to: Your message of "Sun, 28 Nov 1999 03:14:04 +0100." <19991128031403.N19490@abc.123.org> Date: Mon, 29 Nov 1999 12:23:59 +0200 Message-ID: <25819.943871039@axl.noc.iafrica.com> Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 28 Nov 1999 03:14:04 +0100, Kai Voigt wrote: > In chapter 2.3, RFC 1288 defines a non recursive finger query as > > {Q1} ::= [ {W} | {W} {S} {U} ] {C} > > where {W} is "/W", {S} one or more spaces, {U} the username and {C} > is "\r\n". Are you sure that the notation used in the RFC does not define elements prescribed within "[" and "]" as optional? My reading of the rvalue quoted is: Must be one of: {C} {W} {C} {W} {S} {U} {C} Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Mon Nov 29 2:45:35 1999 Delivered-To: freebsd-stable@freebsd.org Received: from lugh.relay.co.uk (lugh.relay.co.uk [194.72.177.254]) by hub.freebsd.org (Postfix) with ESMTP id 2A97B14F0E for ; Mon, 29 Nov 1999 02:45:31 -0800 (PST) (envelope-from jrochester@enetgroup.co.uk) Received: from raku.enetgroup.co.uk ([194.72.178.7]) by lugh.relay.co.uk (Netscape Messaging Server 3.6) with ESMTP id AAA2D08; Mon, 29 Nov 1999 10:45:17 +0000 Content-Length: 656 Message-ID: X-Mailer: XFMail 1.3 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <19991128031403.N19490@abc.123.org> Date: Mon, 29 Nov 1999 10:49:16 -0000 (GMT) From: John Rochester To: Kai Voigt Subject: RE: finger(1) not RFC compliant Cc: stable@freebsd.org Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 28-Nov-99 Kai Voigt wrote: > When entering "finger user@remotehost", finger has to send > "/W user\r\n" to the remotehost. Instead, it sends "user\r\n" without > the leading "/W ". > > In chapter 2.3, RFC 1288 defines a non recursive finger query as > > {Q1} ::= [ {W} | {W} {S} {U} ] {C} I am sure this is a typo in the RFC. If you look at the meaning of "/W", it does not make sense for it to be optional for the Q2 (recursive) query, but not optional for Q1. BSD finger properly only adds the /W when finger -l is used. ---- John Rochester Java Developer, e-Net Software, Bath, UK john.rochester@enetgroup.co.uk jr@cs.mun.ca To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Mon Nov 29 3: 8:47 1999 Delivered-To: freebsd-stable@freebsd.org Received: from abc.123.org (123.org [195.244.241.123]) by hub.freebsd.org (Postfix) with ESMTP id 7750D15100 for ; Mon, 29 Nov 1999 03:08:39 -0800 (PST) (envelope-from k@abc.123.org) Received: (from k@localhost) by abc.123.org (8.9.3/8.9.3) id MAA40085; Mon, 29 Nov 1999 12:08:07 +0100 (CET) (envelope-from k) Date: Mon, 29 Nov 1999 12:08:07 +0100 From: Kai Voigt To: Sheldon Hearn Cc: Kai Voigt , stable@FreeBSD.ORG Subject: Re: finger(1) not RFC compliant Message-ID: <19991129120807.B37610@abc.123.org> References: <19991128031403.N19490@abc.123.org> <25819.943871039@axl.noc.iafrica.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre2i In-Reply-To: <25819.943871039@axl.noc.iafrica.com> Organization: 123.org Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Sheldon Hearn wrote: > > On Sun, 28 Nov 1999 03:14:04 +0100, Kai Voigt wrote: > > > In chapter 2.3, RFC 1288 defines a non recursive finger query as > > > > {Q1} ::= [ {W} | {W} {S} {U} ] {C} > > > > where {W} is "/W", {S} one or more spaces, {U} the username and {C} > > is "\r\n". > > Are you sure that the notation used in the RFC does not define elements > prescribed within "[" and "]" as optional? My reading of the rvalue > quoted is: > > Must be one of: > {C} > {W} {C} > {W} {S} {U} {C} correct, but this means that you have to specify "/W " when doing a user query. Which FreeBSD does not. Kai -- kai voigt hamburger chaussee 36 24113 kiel 04 31 - 22 19 98 69 http://k.123.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Mon Nov 29 3:16:25 1999 Delivered-To: freebsd-stable@freebsd.org Received: from abc.123.org (123.org [195.244.241.123]) by hub.freebsd.org (Postfix) with ESMTP id 3014215100 for ; Mon, 29 Nov 1999 03:16:21 -0800 (PST) (envelope-from k@abc.123.org) Received: (from k@localhost) by abc.123.org (8.9.3/8.9.3) id MAA40126; Mon, 29 Nov 1999 12:16:07 +0100 (CET) (envelope-from k) Date: Mon, 29 Nov 1999 12:16:06 +0100 From: Kai Voigt To: John Rochester Cc: Kai Voigt , stable@freebsd.org Subject: Re: finger(1) not RFC compliant Message-ID: <19991129121606.C37610@abc.123.org> References: <19991128031403.N19490@abc.123.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre2i In-Reply-To: Organization: 123.org Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG John Rochester wrote: > On 28-Nov-99 Kai Voigt wrote: > > When entering "finger user@remotehost", finger has to send > > "/W user\r\n" to the remotehost. Instead, it sends "user\r\n" without > > the leading "/W ". > > > > In chapter 2.3, RFC 1288 defines a non recursive finger query as > > > > {Q1} ::= [ {W} | {W} {S} {U} ] {C} > > I am sure this is a typo in the RFC. If you look at the meaning of "/W", it > does not make sense for it to be optional for the Q2 (recursive) query, but > not optional for Q1. BSD finger properly only adds the /W when finger -l > is used. Yes, I assume the same. Common sense tells me to have {Q1} ::= [ {W} {S} ] [ {U} ] {C} where {S} can be any number of spaces. The RFC requires at least one space. I have checked out Solaris' and Linux' behaviour, and they have implemented it the same way. With the syntax above, the RFC specification is still accepted. Maybe the RFC should be updated :) Kai -- kai voigt hamburger chaussee 36 24113 kiel 04 31 - 22 19 98 69 http://k.123.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Mon Nov 29 4:35:14 1999 Delivered-To: freebsd-stable@freebsd.org Received: from thumper.cns.vt.edu (thumper.cns.vt.edu [128.173.12.196]) by hub.freebsd.org (Postfix) with ESMTP id 1AB60150B8 for ; Mon, 29 Nov 1999 04:35:10 -0800 (PST) (envelope-from ceharris@cns.vt.edu) Received: (ceharris@localhost) by thumper.cns.vt.edu (8.8.5/8.8.5) id HAA23712 for freebsd-stable@freebsd.org; Mon, 29 Nov 1999 07:35:10 -0500 (EST) Date: Mon, 29 Nov 1999 07:35:10 -0500 From: Carl Harris To: freebsd-stable@freebsd.org Subject: Re: Bug-fixing previous -RELEASE, was Re: speaking of 3.4... Message-ID: <19991129073510.A23669@thumper.cns.vt.edu> References: <19991128103420.A95893@phoenix.welearn.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <19991128103420.A95893@phoenix.welearn.com.au>; from jon@welearn.com.au on Sun, Nov 28, 1999 at 10:34:22AM +1100 Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, Nov 28, 1999 at 10:34:22AM +1100, Jonathan Michaels wrote: > things. to go on .. the impression i got from the original > question is that this person (me and others i dare with rather > limited resources as well) might find the traffic some what > financially trying, given most f the rest of the world still > charges internet access by the byte as well as by the minute. > tracking the whole tree could run up a tidy bill, not a real > probelm for those in the trade so to speak but us "hangers on". I have quite limited resources, and pay per-minute charges to my ISP, yet I find that tracking -STABLE with cvsup is not especially burdensome, financially or otherwise. I use a 56K modem to connect to my ISP. cvsup seems involve quite a bit of data flowing from my machine to the cvsup server. Since the back channel of a 56K modem tops out at 33.6 Kbps, this will increase the time it takes to complete the update. I track all of the src-* collections plus ports-all. Typically, I run an update every day, and it takes five to seven minutes to complete the run. Even on days when there are many deltas applied to my copy of the tree, the time required doesn't change significantly (i.e. much of the time is spent in overhead activities that don't vary with the number of deltas). Curiously, I notice that it doesn't run significantly faster on our systems in the office, which have several orders of magnitude greater bandwidth at their disposal. This suggests that network bandwidth isn't really a significant issue WRT the time required to complete the update, which sorta makes sense if the cvsup server has a lot of work on its hands. FWIW, I started tracking -STABLE with the same trepidation about applying all of those changes willy-nilly, without regard for whether I need them or not. The reality is that there really aren't all that many deltas in the src-* collections on a day-to-day basis (relative to the number of changes to ports-all!). After many, many iterations of 'make world' and 'make depend kernel install', I've never had a serious problem as a result of a change committed to -STABLE. --c To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Mon Nov 29 5:27:11 1999 Delivered-To: freebsd-stable@freebsd.org Received: from sol.cc.u-szeged.hu (sol.cc.u-szeged.hu [160.114.8.24]) by hub.freebsd.org (Postfix) with ESMTP id 4217C14A20 for ; Mon, 29 Nov 1999 05:26:58 -0800 (PST) (envelope-from sziszi@petra.hos.u-szeged.hu) Received: from petra.hos.u-szeged.hu by sol.cc.u-szeged.hu (8.9.1b+Sun/SMI-SVR4) id OAA08499; Mon, 29 Nov 1999 14:26:41 +0100 (MET) Received: from sziszi by petra.hos.u-szeged.hu with local-smtp (Exim 2.05 #1 (Debian)) id 11sQe0-0000ly-00; Mon, 29 Nov 1999 14:15:04 +0100 Date: Mon, 29 Nov 1999 14:15:04 +0100 (CET) From: Adam Szilveszter To: Carl Harris Cc: freebsd-stable@freebsd.org Subject: Re: Bug-fixing previous -RELEASE, was Re: speaking of 3.4... In-Reply-To: <19991129073510.A23669@thumper.cns.vt.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi! Here is another "horror" story about tracking -STABLE:-) Normally I only sync the tree via cvsup only once a month and always wait a couple of weeks after a release is out to see the first, frightening and probably easy-to-fix startup errors that will later make up the contents of the ERRATA file. Even after a month, changes can be merged in a reasonable time frame. (As for ports, I track 'em almost daily, but that's a different story) And never had a problem while doing buildworlds. Not even now, when I did 'em three times in as many days. So I think I can say that it is rather safe to track this branch, and AFAIR there were not many cases when functionality would have been lost because of new additions. (BTW anyone knows, where the Build script had gone from our sendmail distro? Or any other ideas on how to rebuild *THAT* only?) Cheers! Szilveszter ADAM ------------------------------------------------------------------------------- * Adam Szilveszter * JATE Szeged * email: sziszi@petra.hos.u-szeged.hu * * Homepage : none * alternate email: cc@flanker.itl.net.ua * * Finger sziszi@petra.hos.u-szeged.hu for PGP key. * * I prefer using the door instead of Windows(tm)... * To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Mon Nov 29 6:59:25 1999 Delivered-To: freebsd-stable@freebsd.org Received: from mail.infolibria.com (mail.infolibria.com [199.103.137.198]) by hub.freebsd.org (Postfix) with ESMTP id E51CA15033 for ; Mon, 29 Nov 1999 06:59:19 -0800 (PST) (envelope-from loverso@infolibria.com) Received: from infolibria.com (border [199.103.137.193]) by mail.infolibria.com (Postfix) with ESMTP id 2EF07DDB83 for ; Mon, 29 Nov 1999 10:11:33 -0500 (EST) Message-ID: <384294DD.A501DD45@infolibria.com> Date: Mon, 29 Nov 1999 09:59:41 -0500 From: John LoVerso X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: stable@FreeBSD.ORG Subject: Re: finger(1) not RFC compliant References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > In chapter 2.3, RFC 1288 defines a non recursive finger query as Of course, everyone knows that RRC 1288 was written to document existing FINGER servers, especially WRT the TOPS20 and 4BSD implementations? John To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Mon Nov 29 7:34: 2 1999 Delivered-To: freebsd-stable@freebsd.org Received: from point.osg.gov.bc.ca (point.osg.gov.bc.ca [142.32.102.44]) by hub.freebsd.org (Postfix) with ESMTP id C9D051500F for ; Mon, 29 Nov 1999 07:33:59 -0800 (PST) (envelope-from cy@cschuber.net.gov.bc.ca) Received: (from daemon@localhost) by point.osg.gov.bc.ca (8.8.7/8.8.8) id HAA06255; Mon, 29 Nov 1999 07:33:55 -0800 Received: from cschuber.net.gov.bc.ca(142.31.240.113), claiming to be "cwsys.cwsent.com" via SMTP by point.osg.gov.bc.ca, id smtpda06253; Mon Nov 29 07:33:47 1999 Received: (from uucp@localhost) by cwsys.cwsent.com (8.9.3/8.9.1) id HAA19643; Mon, 29 Nov 1999 07:33:44 -0800 (PST) Message-Id: <199911291533.HAA19643@cwsys.cwsent.com> Received: from localhost.cwsent.com(127.0.0.1), claiming to be "cwsys" via SMTP by localhost.cwsent.com, id smtpdW19639; Mon Nov 29 07:33:39 1999 X-Mailer: exmh version 2.1.1 10/15/1999 Reply-To: Cy Schubert - ITSD Open Systems Group From: Cy Schubert - ITSD Open Systems Group X-OS: FreeBSD 3.3-RELEASE X-Sender: cy To: Colin Cc: "Forrest W. Christian" , Stable@FreeBSD.ORG Subject: Re: Bug-fixing previous -RELEASE In-reply-to: Your message of "Sat, 27 Nov 1999 12:35:25 EST." <3840165D.CAF495E9@home.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 29 Nov 1999 07:33:37 -0800 Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <3840165D.CAF495E9@home.com>, Colin writes: > Forrest W. Christian wrote: > > > > Hmm, this brings up another interesting question. First, to put this in > > context: > > > > Jordan K. Hubbard wrote: > > > Actually, the -missioncritical branch is sort of provided for > > > now as a function of -previousstable. There are plenty of people still > > > running 2.2.x, for example, and you even still occasionally see commits > > > to the 2.2.x branch. > > > > Ok, so, let's assume I JUST want to incorporate bugfixes into the -RELEASE > > (be it 3.x or whatever) that I have on a particular machine. How would I > > go about doing this? > > > My intent was actually a little different from the responses that > are elswhere in this list. My thought was, when you find a bug that > affects you, get the diffs/upgraded source that fixes that problem only > and apply. I'm new enough to this branch that I don't know for sure how > difficult that would be, but I don't imagine it would be that big of a > deal. You could also move just far enough up the source tree to fix > your current problems and stop there, but at that point, there's no more > risk than tracking -STABLE completely. This approach does work (usually), however there are times that a fix may require prerequisite patches. Sometimes you end up with a long chain of prerequisites that need to be installed that eventually leads into an abyss. In that case you need to carefully decide whether to sync up with -stable or live with the bug. Usually what I do in the above situation is run the "new" O/S from another disk or slice, then if it breaks something or customers complain and no fix can be found, the backout is a simple reboot. Once the "new" O/S has been running for a couple of weeks or so, you can safely reclaim the space used by the "old" O/S. This is an approach that I and my team have been using on Solaris, Digital UNIX, and FreeBSD for a number of years. It's an approach I learned in my previous life as an MVS Systems Programmer. Of course none of this beats having a testbed, however O/S's that run nicely on testbeds tend to have problems on production machines because users will do things you've never even dreamed of testing. Regards, Phone: (250)387-8437 Cy Schubert Fax: (250)387-5766 Sun/DEC Team, UNIX Group Internet: Cy.Schubert@uumail.gov.bc.ca ITSD Cy.Schubert@gems8.gov.bc.ca Province of BC "e**(i*pi)+1=0" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Mon Nov 29 7:55:16 1999 Delivered-To: freebsd-stable@freebsd.org Received: from betelgeuse.accessus.net (betelgeuse.accessus.net [209.145.151.40]) by hub.freebsd.org (Postfix) with ESMTP id 6D64014C35; Mon, 29 Nov 1999 07:55:12 -0800 (PST) (envelope-from root@betelgeuse.accessus.net) Received: from localhost (root@localhost) by betelgeuse.accessus.net (8.9.3/8.9.3) with ESMTP id JAA05852; Mon, 29 Nov 1999 09:55:12 -0600 (CST) (envelope-from root@betelgeuse.accessus.net) Date: Mon, 29 Nov 1999 09:55:12 -0600 (CST) From: Libertarian To: FreeBSD-stable@FreeBSD.ORG, FreeBSD-current@FreeBSD.ORG Subject: subscribe zoso@accessus.net Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Mon Nov 29 8:13: 9 1999 Delivered-To: freebsd-stable@freebsd.org Received: from trooper.velocet.net (trooper.velocet.net [216.126.82.226]) by hub.freebsd.org (Postfix) with ESMTP id 232E71507E for ; Mon, 29 Nov 1999 08:13:04 -0800 (PST) (envelope-from dgilbert@trooper.velocet.net) Received: (from dgilbert@localhost) by trooper.velocet.net (8.9.3/8.9.3) id LAA66277; Mon, 29 Nov 1999 11:13:04 -0500 (EST) (envelope-from dgilbert) From: David Gilbert MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14402.42511.251303.652112@trooper.velocet.net> Date: Mon, 29 Nov 1999 11:13:03 -0500 (EST) To: stable@freebsd.org Subject: vinum crash. X-Mailer: VM 6.75 under 20.4 "Emerald" XEmacs Lucid Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG OK... havn't had a look at things yet, but here's the crash. This was cased (and can be repeatedly caused) by doing: dump -0af - /usr | team 1m 8 | restore rf - This is 3.3-STABLE as of Saturday. The SCSI drives are on an Adaptec 2940 LVD controller. My vinum configuration is: # Vinum configuration of raid1.velocet.net, saved at Mon Nov 29 10:50:15 1999 # Current configuration: # drive d1 device /dev/da2s1g # drive d2 device /dev/da3s1g # drive d3 device /dev/da4s1g # drive d4 device /dev/da5s1g # drive d5 device /dev/da6s1g # drive d6 device /dev/da7s1g # drive d7 device /dev/da8s1g # drive d8 device /dev/da9s1g # volume raid # plex name raid.p0 org raid5 1024s vol raid # sd name raid.p0.s0 drive d1 plex raid.p0 len 35872768s driveoffset 265s plexof fset 0s # sd name raid.p0.s1 drive d2 plex raid.p0 len 35872768s driveoffset 265s plexof fset 1024s # sd name raid.p0.s2 drive d3 plex raid.p0 len 35872768s driveoffset 265s plexof fset 2048s # sd name raid.p0.s3 drive d4 plex raid.p0 len 35872768s driveoffset 265s plexof fset 3072s # sd name raid.p0.s4 drive d5 plex raid.p0 len 35872768s driveoffset 265s plexof fset 4096s # sd name raid.p0.s5 drive d6 plex raid.p0 len 35872768s driveoffset 265s plexof fset 5120s # sd name raid.p0.s6 drive d7 plex raid.p0 len 35872768s driveoffset 265s plexof fset 6144s # sd name raid.p0.s7 drive d8 plex raid.p0 len 35872768s driveoffset 265s plexof fset 7168s Here's the crash: Fatal trap 12: page fault while in kernel mode fault virtual address = 0x0 fault code = supervisor read, page not present instruction pointer = 0x8:0x0 stack pointer = 0x10:0xc0240448 frame pointer = 0x10:0xc0240484 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = Idle interrupt mask = bio trap number = 12 panic: page fault (kgdb) bt #0 boot (howto=260) at ../../kern/kern_shutdown.c:285 #1 0xc0152738 in at_shutdown ( function=0xc0237182 <__set_sysinit_set_sym_memdev_sys_init+1050>, arg=0x0, queue=12) at ../../kern/kern_shutdown.c:446 #2 0xc02093e5 in trap_fatal (frame=0xc023ffc8, eva=184) at ../../i386/i386/trap.c:942 #3 0xc02090c3 in trap_pfault (frame=0xc023ffc8, usermode=0, eva=184) at ../../i386/i386/trap.c:835 #4 0xc0208d66 in trap (frame={tf_es = -1058668528, tf_ds = -1072431088, tf_edi = 256, tf_esi = 39187457, tf_ebp = -1071382504, tf_isp = -1071382544, tf_ebx = 0, tf_edx = -971053936, tf_ecx = 100, tf_eax = 200, tf_trapno = 12, tf_err = 0, tf_eip = -1072347325, tf_cs = 8, tf_eflags = 66054, tf_esp = -1057173408, tf_ss = 9}) at ../../i386/i386/trap.c:437 #5 0xc0154743 in tsleep (ident=0x255f401, priority=272, wmesg=0xc022949d "vrlock", timo=200) at ../../kern/kern_synch.c:383 #6 0xc013dded in lockrange (stripe=39187457, bp=0xc61ee490, plex=0xc0e62800) at ../../dev/vinum/vinumlock.c:250 #7 0xc013ece2 in bre5 (rq=0xc1142340, plexno=0, diskaddr=0xc02401ac, diskend=39190608) at ../../dev/vinum/vinumraid5.c:586 #8 0xc013fa6d in bre (rq=0xc1142340, plexno=0, diskaddr=0xc02401ac, diskend=39190608) at ../../dev/vinum/vinumrequest.c:633 #9 0xc013fce4 in build_write_request (rq=0xc1142340) at ../../dev/vinum/vinumrequest.c:749 #10 0xc013f238 in vinumstart (bp=0xc61ee490, reviveok=0) at ../../dev/vinum/vinumrequest.c:276 #11 0xc013f0aa in vinumstrategy (bp=0xc61ee490) at ../../dev/vinum/vinumrequest.c:162 #12 0xc018094e in spec_strategy (ap=0xc0240224) at ../../miscfs/specfs/spec_vnops.c:540 #13 0xc01800cd in spec_vnoperate (ap=0xc0240224) at ../../miscfs/specfs/spec_vnops.c:129 #14 0xc01e37a5 in ufs_vnoperatespec (ap=0xc0240224) at ../../ufs/ufs/ufs_vnops.c:2318 #15 0xc016dc73 in bwrite (bp=0xc61ee490) at vnode_if.h:891 #16 0xc0172276 in vop_stdbwrite (ap=0xc024028c) at ../../kern/vfs_default.c:296 #17 0xc01720c1 in vop_defaultop (ap=0xc024028c) at ../../kern/vfs_default.c:130 #18 0xc01800cd in spec_vnoperate (ap=0xc024028c) at ../../miscfs/specfs/spec_vnops.c:129 #19 0xc01e37a5 in ufs_vnoperatespec (ap=0xc024028c) at ../../ufs/ufs/ufs_vnops.c:2318 #20 0xc016e61f in vfs_bio_awrite (bp=0xc61ee490) at vnode_if.h:1145 #21 0xc01dcafe in ffs_fsync (ap=0xc0240314) at ../../ufs/ffs/ffs_vnops.c:205 #22 0xc01daf87 in ffs_sync (mp=0xc0e66800, waitfor=2, cred=0xc0e79f80, p=0xc03195cc) at vnode_if.h:499 #23 0xc0176b9b in sync (p=0xc03195cc, uap=0x0) at ../../kern/vfs_syscalls.c:549 #24 0xc01522f9 in boot (howto=256) at ../../kern/kern_shutdown.c:203 #25 0xc0152738 in at_shutdown ( function=0xc0237182 <__set_sysinit_set_sym_memdev_sys_init+1050>, arg=0x0, queue=12) at ../../kern/kern_shutdown.c:446 #26 0xc02093e5 in trap_fatal (frame=0xc024040c, eva=0) at ../../i386/i386/trap.c:942 #27 0xc02090c3 in trap_pfault (frame=0xc024040c, usermode=0, eva=0) at ../../i386/i386/trap.c:835 #28 0xc0208d66 in trap (frame={tf_es = -1055653872, tf_ds = 16, tf_edi = -1073215488, tf_esi = -1058172928, tf_ebp = -1071381372, tf_isp = -1071381452, tf_ebx = -1057715172, tf_edx = 0, tf_ecx = -1057715172, tf_eax = -919485568, tf_trapno = 12, tf_err = 0, tf_eip = 0, tf_cs = 8, tf_eflags = 66054, tf_esp = -1072236035, tf_ss = -1057715172}) at ../../i386/i386/trap.c:437 #29 0x0 in ?? () Dave. -- ============================================================================ |David Gilbert, Velocet Communications. | Two things can only be | |Mail: dgilbert@velocet.net | equal if and only if they | |http://www.velocet.net/~dgilbert | are precisely opposite. | =========================================================GLO================ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Mon Nov 29 8:26: 6 1999 Delivered-To: freebsd-stable@freebsd.org Received: from trooper.velocet.net (trooper.velocet.net [216.126.82.226]) by hub.freebsd.org (Postfix) with ESMTP id 9824015181 for ; Mon, 29 Nov 1999 08:26:02 -0800 (PST) (envelope-from dgilbert@trooper.velocet.net) Received: (from dgilbert@localhost) by trooper.velocet.net (8.9.3/8.9.3) id LAA66495; Mon, 29 Nov 1999 11:26:01 -0500 (EST) (envelope-from dgilbert) From: David Gilbert MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14402.43119.163568.35734@trooper.velocet.net> Date: Mon, 29 Nov 1999 11:23:11 -0500 (EST) To: stable@freebsd.org Subject: curproc 0? X-Mailer: VM 6.75 under 20.4 "Emerald" XEmacs Lucid Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I was going through the crash I just posted, and I was looking at the tsleep funciton in kern_synch.c. line 382 is: struct proc *p = curproc; ... now doing a 'p curproc' in gdb gave 0... so I'm wondering where curproc comes from --- a static variable somewhere? I've been experimenting with vinum here. I have 8 18Gig Atlas IV's.... and I gather this has something to do with how busy I make them. If I 'dump -0af - /usr | team 1m 8 | restore rf -' ... then I get the crash I just posted. If I remove team, then I don't get the crash. Similarly, I was running bonnie processes in parallel --- to see how the performance was affected by number of processes hitting the drives. With 1, 2, 3, or 4 bonnie processes, everything ran fine. With 8 bonnie processes, I got the crash. I can repeat this at will and the system can be made available for testing as required, too. vinumlock.c calls tsleep in a function that's dealing with locks over the range of stripes on the volume. Is the call to tsleep() improper here because it can somehow occur when we are not within a process? Dave. -- ============================================================================ |David Gilbert, Velocet Communications. | Two things can only be | |Mail: dgilbert@velocet.net | equal if and only if they | |http://www.velocet.net/~dgilbert | are precisely opposite. | =========================================================GLO================ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Mon Nov 29 9: 0:19 1999 Delivered-To: freebsd-stable@freebsd.org Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169]) by hub.freebsd.org (Postfix) with ESMTP id 4772E15181 for ; Mon, 29 Nov 1999 09:00:12 -0800 (PST) (envelope-from ken@panzer.kdm.org) Received: (from ken@localhost) by panzer.kdm.org (8.9.3/8.9.1) id JAA26636; Mon, 29 Nov 1999 09:58:39 -0700 (MST) (envelope-from ken) Message-Id: <199911291658.JAA26636@panzer.kdm.org> Subject: Re: ahc problems (with vinum?) In-Reply-To: <14401.43406.254826.447466@trooper.velocet.net> from David Gilbert at "Nov 28, 1999 05:15:42 pm" To: dgilbert@velocet.ca (David Gilbert) Date: Mon, 29 Nov 1999 09:58:39 -0700 (MST) Cc: jgreco@ns.sol.net (Joe Greco), stable@freebsd.org From: "Kenneth D. Merry" X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG David Gilbert wrote... > >>>>> "Kenneth" == Kenneth D Merry writes: > > Kenneth> David Gilbert wrote... > >> >>>>> "Kenneth" == Kenneth D Merry writes: > >> > Kenneth> It does, generally, but if you've got flaky cabling, it's > Kenneth> hard to guarantee that the bus reset will fix all of your > Kenneth> problems. > >> But since removing the terminator seems to unwedge things, it > >> would make sense to look at what state we're getting stuck in. > > Kenneth> You're getting stuck in dataout phase. > > Ok... but... > > I just went over to the machine with the intention of changing the > cables. I removed the terminator just to see... and everything > unwedged (although ... this is after I replaced the terminator). I dunno why removing the terminator would unwedge things. Removing the terminator isn't generally a good idea, though. Ken -- Kenneth Merry ken@kdm.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Mon Nov 29 10:10:43 1999 Delivered-To: freebsd-stable@freebsd.org Received: from trooper.velocet.net (trooper.velocet.net [216.126.82.226]) by hub.freebsd.org (Postfix) with ESMTP id 75F3C151DE for ; Mon, 29 Nov 1999 10:10:18 -0800 (PST) (envelope-from dgilbert@trooper.velocet.net) Received: (from dgilbert@localhost) by trooper.velocet.net (8.9.3/8.9.3) id NAA72998; Mon, 29 Nov 1999 13:10:12 -0500 (EST) (envelope-from dgilbert) From: David Gilbert MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14402.49539.605255.833958@trooper.velocet.net> Date: Mon, 29 Nov 1999 13:10:11 -0500 (EST) To: John LoVerso Cc: stable@freebsd.org Subject: Re: curproc 0? In-Reply-To: <3842B827.11EEDD05@infolibria.com> References: <14402.43119.163568.35734@trooper.velocet.net> <3842B827.11EEDD05@infolibria.com> X-Mailer: VM 6.75 under 20.4 "Emerald" XEmacs Lucid Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >>>>> "John" == John LoVerso writes: John> curproc is a magic pointer to the current process, set by the John> scheduler. If you inspect it from an interrupt or other John> non-process context, you'll find that it is 0. Well... the vinum code is calling tsleep() (in vinumlock.c at line 250) and curproc is 0... so what I'm asking here is if vinum should be calling this function, and if not, what? Or... should tsleep() not try to dereference curproc immediately? Dave. -- ============================================================================ |David Gilbert, Velocet Communications. | Two things can only be | |Mail: dgilbert@velocet.net | equal if and only if they | |http://www.velocet.net/~dgilbert | are precisely opposite. | =========================================================GLO================ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Mon Nov 29 10:22:11 1999 Delivered-To: freebsd-stable@freebsd.org Received: from trooper.velocet.net (trooper.velocet.net [216.126.82.226]) by hub.freebsd.org (Postfix) with ESMTP id 4A79915575 for ; Mon, 29 Nov 1999 10:22:03 -0800 (PST) (envelope-from dgilbert@trooper.velocet.net) Received: (from dgilbert@localhost) by trooper.velocet.net (8.9.3/8.9.3) id NAA73295; Mon, 29 Nov 1999 13:22:03 -0500 (EST) (envelope-from dgilbert) From: David Gilbert MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14402.50250.717414.95677@trooper.velocet.net> Date: Mon, 29 Nov 1999 13:22:02 -0500 (EST) To: stable@freebsd.org Subject: Repeatable vinum crash. X-Mailer: VM 6.75 under 20.4 "Emerald" XEmacs Lucid Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG So... I'm able to repeat the vinum crash mentioned earlier. It would appear that tsleep() is getting called when curproc = 0. I'm not exactly sure how to correct this. tsleep() seems to make a fair bit of use of the curproc structure... so it wouldn't appear that accepting a NULL there would be a good idea (but can we just return if curproc is NULL --- it looks like the structure of tsleep() doesn't work if you don't have a process to return to) ... so would it then be an interim hack to not call tsleep (effectively spin waiting) if curproc is null? I suppose this would be equivalent. If vinum needs to wait on a lock at this point, and curproc is 0, what is the accepted method? Dave. -- ============================================================================ |David Gilbert, Velocet Communications. | Two things can only be | |Mail: dgilbert@velocet.net | equal if and only if they | |http://www.velocet.net/~dgilbert | are precisely opposite. | =========================================================GLO================ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Mon Nov 29 11:24: 6 1999 Delivered-To: freebsd-stable@freebsd.org Received: from front7m.grolier.fr (front7m.grolier.fr [195.36.216.57]) by hub.freebsd.org (Postfix) with ESMTP id C94471570D for ; Mon, 29 Nov 1999 11:23:56 -0800 (PST) (envelope-from vons@iname.com) Received: from CYRIL (ppp-105-155.villette.club-internet.fr [194.158.105.155]) by front7m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id UAA01489 for ; Mon, 29 Nov 1999 20:23:52 +0100 (MET) Message-Id: <4.2.2.19991129200126.00a94c20@mail.vons.local> X-Sender: vons@mail.vons.local (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Mon, 29 Nov 1999 20:23:27 +0100 To: freebsd-stable@freebsd.org From: Gert-Jan Vons Subject: kernel panic in stable of 29 Nov. Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hello all, My freebsd3.3-stable as of today panics with a page fault in kernel mode when I try to mount a CD-ROM. I haven't used the CD-ROM player in a while on this system, so I don't know exactly since when this is happening. The output of gdb -k and dmesg follow. I've kept the dump so if more info is needed, let me know. Gert-Jan -------------------------------- [dodo: compile/DODO]: gdb -k GNU gdb 4.18 Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-unknown-freebsd". (kgdb) symbol-file kernel.debug kernel.debug: No such file or directory. (kgdb) symbol-file kernel.dbg Reading symbols from kernel.dbg...done. (kgdb) exec-file /var/crash/kernel.2 (kgdb) core-file /var/crash/vmcore.2 IdlePTD 2510848 initial pcb at 200f40 panicstr: page fault panic messages: --- Fatal trap 12: page fault while in kernel mode fault virtual address = 0x17004a fault code = supervisor read, page not present instruction pointer = 0x8:0xc015d826 stack pointer = 0x10:0xc36ced68 frame pointer = 0x10:0xc36ced80 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 144 (mountd) interrupt mask = trap number = 12 panic: page fault syncing disks... 2 2 done dumping to dev 20401, offset 106496 dump 48 47 46 45 44 43 42 41 40 39 38 37 36 35 34 33 32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 --- #0 boot (howto=256) at ../../kern/kern_shutdown.c:285 285 dumppcb.pcb_cr3 = rcr3(); (kgdb) where #0 boot (howto=256) at ../../kern/kern_shutdown.c:285 #1 0xc01380ec in at_shutdown ( function=0xc01e8802 <__set_sysinit_set_sym_memdev_sys_init+1050>, arg=0xc369c0a0, queue=-1016271572) at ../../kern/kern_shutdown.c:446 #2 0xc01c55e1 in trap_fatal (frame=0xc36ced2c, eva=1507402) at ../../i386/i386/trap.c:942 #3 0xc01c52bf in trap_pfault (frame=0xc36ced2c, usermode=0, eva=1507402) at ../../i386/i386/trap.c:835 #4 0xc01c4f62 in trap (frame={tf_es = 16, tf_ds = -1051787248, tf_edi = -1066765280, tf_esi = 32, tf_ebp = -1016271488, tf_isp = -1016271532, tf_ebx = 1507362, tf_edx = -1066765312, tf_ecx = 0, tf_eax = -1066765280, tf_trapno = 12, tf_err = -1066795008, tf_eip = -1072310234, tf_cs = -1015480312, tf_eflags = 66054, tf_esp = 1507362, tf_ss = -1072310304}) at ../../i386/i386/trap.c:437 #5 0xc015d826 in vfs_free_addrlist (nep=0xc06a7420) at ../../kern/vfs_subr.c:2283 #6 0xc015d88a in vfs_export (mp=0xc06a7600, nep=0xc06a7420, argp=0xc36ceddc) at ../../kern/vfs_subr.c:2303 #7 0xc06d42fa in ?? () #8 0xc015e58e in mount (p=0xc369c0a0, uap=0xc36cef94) at ../../kern/vfs_syscalls.c:305 #9 0xc01c5823 in syscall (frame={tf_es = 39, tf_ds = 39, tf_edi = 134718632, tf_esi = 134808899, tf_ebp = -1077945100, tf_isp = -1016270876, ---Type to continue, or q to quit--- tf_ebx = 5, tf_edx = 671604736, tf_ecx = 0, tf_eax = 21, tf_trapno = 12, tf_err = 2, tf_eip = 134543252, tf_cs = 31, tf_eflags = 518, tf_esp = -1077946428, tf_ss = 39}) at ../../i386/i386/trap.c:1100 #10 0xc01bb71c in Xint0x80_syscall () #11 0xbfbfdfcc in ?? () #12 0x80484f1 in ?? () #13 0x80480e9 in ?? () (kgdb) up #1 0xc01380ec in at_shutdown ( function=0xc01e8802 <__set_sysinit_set_sym_memdev_sys_init+1050>, arg=0xc369c0a0, queue=-1016271572) at ../../kern/kern_shutdown.c:446 446 boot(bootopt); (kgdb) up #2 0xc01c55e1 in trap_fatal (frame=0xc36ced2c, eva=1507402) at ../../i386/i386/trap.c:942 942 panic(trap_msg[type]); (kgdb) up #3 0xc01c52bf in trap_pfault (frame=0xc36ced2c, usermode=0, eva=1507402) at ../../i386/i386/trap.c:835 835 trap_fatal(frame, eva); (kgdb) up #4 0xc01c4f62 in trap (frame={tf_es = 16, tf_ds = -1051787248, tf_edi = -1066765280, tf_esi = 32, tf_ebp = -1016271488, tf_isp = -1016271532, tf_ebx = 1507362, tf_edx = -1066765312, tf_ecx = 0, tf_eax = -1066765280, tf_trapno = 12, tf_err = -1066795008, tf_eip = -1072310234, tf_cs = -1015480312, tf_eflags = 66054, tf_esp = 1507362, tf_ss = -1072310304}) at ../../i386/i386/trap.c:437 437 (void) trap_pfault(&frame, FALSE, eva); (kgdb) up #5 0xc015d826 in vfs_free_addrlist (nep=0xc06a7420) at ../../kern/vfs_subr.c:2283 2283 (*rnh->rnh_walktree) (rnh, vfs_free_netcred, (kgdb) list 2278 register int i; 2279 register struct radix_node_head *rnh; 2280 2281 for (i = 0; i <= AF_MAX; i++) 2282 if ((rnh = nep->ne_rtable[i])) { 2283 (*rnh->rnh_walktree) (rnh, vfs_free_netcred, 2284 (caddr_t) rnh); 2285 free((caddr_t) rnh, M_RTABLE); 2286 nep->ne_rtable[i] = 0; 2287 } (kgdb) -------------------------------- Copyright (c) 1992-1999 FreeBSD Inc. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 3.3-STABLE #6: Mon Nov 29 19:56:46 CET 1999 vons@dodo.vons.local:/home/fbsd/stable/src/sys/compile/DODO Timecounter "i8254" frequency 1193079 Hz CPU: Cyrix 6x86 (486-class CPU) Origin = "CyrixInstead" DIR=0x1731 Stepping=1 Revision=7 real memory = 50331648 (49152K bytes) avail memory = 46620672 (45528K bytes) Preloaded elf kernel "kernel" at 0xc0253000. Probing for devices on PCI bus 0: chip0: rev 0x02 on pci0.0.0 chip1: rev 0x02 on pci0.7.0 pn0: <82c169 PNIC 10/100BaseTX> rev 0x20 int a irq 15 on pci0.9.0 pn0: Ethernet address: 00:a0:cc:53:1a:e6 pn0: autoneg complete, link status good (full-duplex, 100Mbps) ncr0: rev 0x02 int a irq 9 on pci0.10.0 vga0: rev 0x00 int a irq 10 on pci0.11.0 de0: rev 0x21 int a irq 11 on pci0.12.0 de0: 21041 [10Mb/s] pass 2.1 de0: address 00:80:c8:4a:2f:3b Probing for devices on the ISA bus: sc0 flags 0x6 on isa sc0: VGA color <16 virtual consoles, flags=0x6> atkbdc0 at 0x60-0x6f on motherboard atkbd0 irq 1 on isa psm0 irq 12 on isa psm0: model Generic PS/2 mouse, device ID 0 sio0 at 0x3f8-0x3ff irq 4 flags 0x10 on isa sio0: type 16550A sio1 at 0x2f8-0x2ff irq 3 on isa sio1: type 16550A fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa fdc0: FIFO enabled, 8 bytes threshold fd0: 1.44MB 3.5in ppc0 at 0x378 irq 7 flags 0x40 on isa ppc0: Generic chipset (EPP/NIBBLE) in COMPATIBLE mode lpt0: on ppbus 0 lpt0: Interrupt-driven port vga0 at 0x3b0-0x3df maddr 0xa0000 msize 131072 on isa npx0 on motherboard npx0: INT 16 interface IP Filter: initialized. Default = pass all, Logging = enabled Waiting 5 seconds for SCSI devices to settle sa0 at ncr0 bus 0 target 4 lun 0 sa0: Removable Sequential Access SCSI-CCS device sa0: 3.300MB/s transfers da1 at ncr0 bus 0 target 1 lun 0 da1: Fixed Direct Access SCSI-2 device da1: 10.000MB/s transfers (10.000MHz, offset 8) da1: 1222MB (2503872 512 byte sectors: 255H 63S/T 155C) da0 at ncr0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-2 device da0: 10.000MB/s transfers (10.000MHz, offset 8), Tagged Queueing Enabled da0: 1033MB (2117025 512 byte sectors: 255H 63S/T 131C) changing root device to da0s1a cd0 at ncr0 bus 0 target 6 lun 0 cd0: Removable CD-ROM SCSI-2 device cd0: 4.237MB/s transfers (4.237MHz, offset 8) cd0: Attempt to query device size failed: NOT READY, Medium not present ------------------------ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Mon Nov 29 11:50:48 1999 Delivered-To: freebsd-stable@freebsd.org Received: from trooper.velocet.net (trooper.velocet.net [216.126.82.226]) by hub.freebsd.org (Postfix) with ESMTP id CF7C815249 for ; Mon, 29 Nov 1999 11:50:45 -0800 (PST) (envelope-from dgilbert@trooper.velocet.net) Received: (from dgilbert@localhost) by trooper.velocet.net (8.9.3/8.9.3) id OAA75790; Mon, 29 Nov 1999 14:50:44 -0500 (EST) (envelope-from dgilbert) From: David Gilbert MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14402.55572.178182.42119@trooper.velocet.net> Date: Mon, 29 Nov 1999 14:50:44 -0500 (EST) To: stable@freeBSD.org Subject: What to do when trace doesn't work. X-Mailer: VM 6.75 under 20.4 "Emerald" XEmacs Lucid Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I'm trying to track down this vinum problem --- it appears that a panic happens while the first panic is in process... which cuts off the stack trace... so I was trying to use ddb to figure it out. What do you do when "trace" in ddb simply causes another panic? How do I just tell it to dump the current kernel? Dave. -- ============================================================================ |David Gilbert, Velocet Communications. | Two things can only be | |Mail: dgilbert@velocet.net | equal if and only if they | |http://www.velocet.net/~dgilbert | are precisely opposite. | =========================================================GLO================ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Mon Nov 29 12:42:52 1999 Delivered-To: freebsd-stable@freebsd.org Received: from trooper.velocet.net (trooper.velocet.net [216.126.82.226]) by hub.freebsd.org (Postfix) with ESMTP id 2A1DE1529A for ; Mon, 29 Nov 1999 12:42:47 -0800 (PST) (envelope-from dgilbert@trooper.velocet.net) Received: (from dgilbert@localhost) by trooper.velocet.net (8.9.3/8.9.3) id PAA78012; Mon, 29 Nov 1999 15:42:47 -0500 (EST) (envelope-from dgilbert) From: David Gilbert MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14402.58695.141814.462651@trooper.velocet.net> Date: Mon, 29 Nov 1999 15:42:47 -0500 (EST) To: stable@freebsd.org Subject: vinum crash... how to proceed. X-Mailer: VM 6.75 under 20.4 "Emerald" XEmacs Lucid Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Ok... on my 8 drive vinum system, I can cause a crash with a simple "du" in a directory which is a copy of a normal usr filesystem. My problem is that the kernel dump (as follows) is less-than-helpful. Why is the 5th frame on the stack 0x0? How do I find out what caused the trap() call? #0 boot (howto=256) at ../../kern/kern_shutdown.c:285 #1 0xc0152738 in at_shutdown ( function=0xc0237182 <__set_sysinit_set_sym_memdev_sys_init+1050>, arg=0x0, queue=12) at ../../kern/kern_shutdown.c:446 #2 0xc02093e5 in trap_fatal (frame=0xc024041c, eva=0) at ../../i386/i386/trap.c:942 #3 0xc02090c3 in trap_pfault (frame=0xc024041c, usermode=0, eva=0) at ../../i386/i386/trap.c:835 #4 0xc0208d66 in trap (frame={tf_es = -1057619952, tf_ds = -1058209776, tf_edi = -1073215488, tf_esi = -1058136064, tf_ebp = -1071381356, tf_isp = -1071381436, tf_ebx = -1057770468, tf_edx = 0, tf_ecx = -1057770468, tf_eax = -919261248, tf_trapno = 12, tf_err = 0, tf_eip = 0, tf_cs = 8, tf_eflags = 66054, tf_esp = -1072236031, tf_ss = -1057770468}) at ../../i386/i386/trap.c:437 #5 0x0 in ?? () Dave. -- ============================================================================ |David Gilbert, Velocet Communications. | Two things can only be | |Mail: dgilbert@velocet.net | equal if and only if they | |http://www.velocet.net/~dgilbert | are precisely opposite. | =========================================================GLO================ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Mon Nov 29 12:51:42 1999 Delivered-To: freebsd-stable@freebsd.org Received: from zippy.cdrom.com (zippy.cdrom.com [204.216.27.228]) by hub.freebsd.org (Postfix) with ESMTP id EAA74153A5 for ; Mon, 29 Nov 1999 12:51:40 -0800 (PST) (envelope-from jkh@zippy.cdrom.com) Received: from zippy.cdrom.com (localhost [127.0.0.1]) by zippy.cdrom.com (8.9.3/8.9.3) with ESMTP id MAA87236; Mon, 29 Nov 1999 12:51:36 -0800 (PST) (envelope-from jkh@zippy.cdrom.com) To: David Gilbert Cc: stable@FreeBSD.ORG Subject: Re: vinum crash... how to proceed. In-reply-to: Your message of "Mon, 29 Nov 1999 15:42:47 EST." <14402.58695.141814.462651@trooper.velocet.net> Date: Mon, 29 Nov 1999 12:51:36 -0800 Message-ID: <87232.943908696@zippy.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Ok... on my 8 drive vinum system, I can cause a crash with a simple > "du" in a directory which is a copy of a normal usr filesystem. My > problem is that the kernel dump (as follows) is less-than-helpful. > Why is the 5th frame on the stack 0x0? How do I find out what caused > the trap() call? Look at frame 3 - it's quite obvious. Your crash was caused by a page fault, and you can consider it as analgous to a signal 10 or signal 11 in usermode. The driver went wild and attempted to use an address which wasn't kosher for something. :-) - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Mon Nov 29 12:53:42 1999 Delivered-To: freebsd-stable@freebsd.org Received: from ns1.sprawlnet.com (ns1.sprawlnet.com [208.224.169.130]) by hub.freebsd.org (Postfix) with ESMTP id 50A311529A for ; Mon, 29 Nov 1999 12:53:33 -0800 (PST) (envelope-from mike@sprawlnet.com) Received: from jedi (jedi.sprawlnet.com [208.224.169.134]) by ns1.sprawlnet.com (8.9.3/8.9.2) with SMTP id EAA00360 for ; Tue, 30 Nov 1999 04:55:29 GMT (envelope-from mike@sprawlnet.com) Message-ID: <000801bf3aab$8cf30a60$86a9e0d0@sprawlnet.com> From: "Michael Steinfeld" To: Subject: weird: adduser, rmuser, shutdown and more commands not found Date: Mon, 29 Nov 1999 15:51:46 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0005_01BF3A81.A3F86360" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This is a multi-part message in MIME format. ------=_NextPart_000_0005_01BF3A81.A3F86360 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hey, Somehow as of about a week ago, adduser, shutdown, rmuser, startx, xinit = and many other commands do not work. I'm clueless to why. It was after last weks build of 3.3-stable exactly = 1 week ago today. I jsut did a 'make world' today. Not expecting that would change = anything but jsut in case. Anyone have any ideas why this is happening or suggestions?=20 Michael Steinfeld | The only good is knowledge and the only = evil ignorance. --Socrates Unix Administrator | mike@sprawlnet.com // Salute to JGB and = The Boys .. still going down that road. Sprawlnet.com INC =20 ------=_NextPart_000_0005_01BF3A81.A3F86360 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hey,
 
Somehow as of about a week ago, adduser, shutdown, = rmuser,=20 startx, xinit and many other commands do not work.
I'm clueless to why. It was after last weks build of = 3.3-stable exactly 1 week ago today.
 
I jsut did a 'make world' today. Not expecting that = would=20 change anything but jsut in case.
 
Anyone have any ideas why this is happening or = suggestions?=20
 
Michael=20 Steinfeld         | The only = good is=20 knowledge and the only evil ignorance. --Socrates
 Unix=20 Administrator       |  mike@sprawlnet.com  &nbs= p; //=20 Salute to JGB and The Boys .. still going down that = road.
Sprawlnet.com=20 INC    
------=_NextPart_000_0005_01BF3A81.A3F86360-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Mon Nov 29 13: 8:46 1999 Delivered-To: freebsd-stable@freebsd.org Received: from workhorse.iMach.com (workhorse.iMach.com [206.127.77.89]) by hub.freebsd.org (Postfix) with ESMTP id F1F7A14A1C for ; Mon, 29 Nov 1999 13:08:42 -0800 (PST) (envelope-from forrestc@workhorse.iMach.com) Received: from localhost (forrestc@localhost) by workhorse.iMach.com (8.8.8/8.8.8) with SMTP id OAA22856; Mon, 29 Nov 1999 14:05:10 -0700 (MST) Date: Mon, 29 Nov 1999 14:05:09 -0700 (MST) From: "Forrest W. Christian" To: Michael Steinfeld Cc: stable@FreeBSD.ORG Subject: Re: weird: adduser, rmuser, shutdown and more commands not found In-Reply-To: <000801bf3aab$8cf30a60$86a9e0d0@sprawlnet.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 29 Nov 1999, Michael Steinfeld wrote: > Somehow as of about a week ago, adduser, shutdown, rmuser, startx, xinit and many other commands do not work. > I'm clueless to why. It was after last weks build of 3.3-stable exactly 1 week ago today. Ummmm.... Not to be obvious but.... Path? Non-existant executables? Corrupt files's? Check to make sure the files are still in the path and that they still exist. Try running them with a full pathname. - Forrest W. Christian (forrestc@imach.com) KD7EHZ ---------------------------------------------------------------------- iMach, Ltd., P.O. Box 5749, Helena, MT 59604 http://www.imach.com Solutions for your high-tech problems. (406)-442-6648 ---------------------------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Mon Nov 29 20: 6:43 1999 Delivered-To: freebsd-stable@freebsd.org Received: from s01.arpa-canada.net (s01.arpa-canada.net [209.104.122.2]) by hub.freebsd.org (Postfix) with ESMTP id 0818E15759 for ; Mon, 29 Nov 1999 20:06:15 -0800 (PST) (envelope-from matt@BabCom.ORG) Received: by s01.arpa-canada.net (Postfix, from userid 1001) id C8E6EB885; Mon, 29 Nov 1999 23:06:14 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by s01.arpa-canada.net (Postfix) with ESMTP id 7E4C2F for ; Mon, 29 Nov 1999 23:06:14 -0500 (EST) Date: Mon, 29 Nov 1999 23:06:14 -0500 (EST) From: matt X-Sender: matt@s01.arpa-canada.net To: FreeBSD-STABLE Subject: Login.conf and tweaking. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hello, I run a shell company that recently started up and runs strictly on FreeBSD 3.3-STABLE. I have, obviously, configured the login.conf to limit users mainly on memory and file descriptor usage. I however have the problem where certain procs eat up 99% of CPU when they loop and screw up. This seems to be of no fault to the user, mainly of the code. I find that BNC and Eggdrops are specially susceptable to this happening. What this ends up doing, is shooting my load averages very high and generally slowing down the system. I see that I can limit cputime and so on, but can I limit the % of cpu a user can user? I do not mean to do this to be restrictive, simply to make a hard cap so a user's messed up proccess cannot overload my CPU. Thank you in advance for your help, You guys have been amazing with FreeBSD help. People often take the list's help for granted, not enough let you know they appreciate it, I like to let you know. Matt -- "If the primates that we came from had known that someday politicians would come out of the...the gene pool, they'd a stayed up in the trees and written evolution off as a bad idea. Hell, I always thought the opposable thumb was overrated." -Sheridan, "A Distant Star" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Tue Nov 30 3: 5:24 1999 Delivered-To: freebsd-stable@freebsd.org Received: from www.menzor.org (themoonismadeofgreenchease.dk [195.249.147.160]) by hub.freebsd.org (Postfix) with ESMTP id 869E615124 for ; Tue, 30 Nov 1999 03:04:48 -0800 (PST) (envelope-from ml@seeberg.dk) Received: from SOS (fwuser@gw.danadata.com [194.239.79.3]) by www.menzor.org (8.8.8/8.8.8) with SMTP id NAA23129 for ; Tue, 30 Nov 1999 13:18:06 +0100 (CET) (envelope-from ml@seeberg.dk) Message-ID: <017d01bf3b22$893bfcc0$1600a8c0@SOS> Reply-To: "Morten Seeberg" From: "Morten Seeberg" To: Subject: cvsup.internat.freebsd.org Date: Tue, 30 Nov 1999 12:03:28 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.5600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.5600 Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Has this server been down for atleast a day or so?? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /\/\orten $eeberg, Systems Consultant @ Merkantildata - Enterprise Solutions #echo 'System Administrators suck :)' > /dev/console To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Tue Nov 30 3:48:45 1999 Delivered-To: freebsd-stable@freebsd.org Received: from zibbi.mikom.csir.co.za (zibbi.mikom.csir.co.za [146.64.24.58]) by hub.freebsd.org (Postfix) with ESMTP id CE83214CFC for ; Tue, 30 Nov 1999 03:48:27 -0800 (PST) (envelope-from jhay@zibbi.mikom.csir.co.za) Received: (from jhay@localhost) by zibbi.mikom.csir.co.za (8.9.3/8.9.3) id NAA18070; Tue, 30 Nov 1999 13:47:35 +0200 (SAT) (envelope-from jhay) From: John Hay Message-Id: <199911301147.NAA18070@zibbi.mikom.csir.co.za> Subject: Re: cvsup.internat.freebsd.org In-Reply-To: <017d01bf3b22$893bfcc0$1600a8c0@SOS> from Morten Seeberg at "Nov 30, 1999 12:03:28 pm" To: morten@seeberg.dk (Morten Seeberg) Date: Tue, 30 Nov 1999 13:47:35 +0200 (SAT) Cc: stable@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Has this server been down for atleast a day or so?? Nope, and as far as I can see everything is ok. At the moment there are 4 cvsupd sessions going. John -- John Hay -- John.Hay@mikom.csir.co.za To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Tue Nov 30 6:48:25 1999 Delivered-To: freebsd-stable@freebsd.org Received: from axolotl.ic.gc.ca (axolotl.ic.gc.ca [198.103.246.251]) by hub.freebsd.org (Postfix) with ESMTP id 5B45215748 for ; Tue, 30 Nov 1999 06:48:18 -0800 (PST) (envelope-from antonio@axolotl.ic.gc.ca) Received: from localhost (antonio@localhost) by axolotl.ic.gc.ca (8.9.3/8.9.2) with SMTP id JAA10738 for ; Tue, 30 Nov 1999 09:48:23 -0500 (EST) (envelope-from antonio@axolotl.ic.gc.ca) Date: Tue, 30 Nov 1999 09:48:23 -0500 (EST) From: Antonio Bemfica To: freebsd-stable@freebsd.org Subject: Is UNION fs still broken? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG The subject says it all. I've seen warnings over the years about the UNION fs not really being usable. Has the situation changed? Is it safe to use? I would like to share my "/usr/local" partition with a test machine (mounted read-only) and would also like some users on the test machine to be able to add stuff from the ports, and play around a bit (they are training). Other than mounting my "/usr/local" as /usr/local_1 on the test machine and modifying paths, ldconfig paths and so on, the UNION fs looks like the perfect solution (if it is reliable...). Any ideas? Antonio To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Tue Nov 30 8:25:56 1999 Delivered-To: freebsd-stable@freebsd.org Received: from lafontaine.cybercable.fr (lafontaine.cybercable.fr [212.198.0.202]) by hub.freebsd.org (Postfix) with SMTP id 2DF7C15995 for ; Tue, 30 Nov 1999 08:25:49 -0800 (PST) (envelope-from Artur.Silveira@rezo.com) Received: (qmail 5210028 invoked from network); 30 Nov 1999 16:25:46 -0000 Received: from d023.paris-107.cybercable.fr (HELO rezo.com) ([212.198.107.23]) (envelope-sender ) by lafontaine.cybercable.fr (qmail-ldap-1.03) with SMTP for ; 30 Nov 1999 16:25:46 -0000 Message-ID: <38440789.739A7EF6@rezo.com> Date: Tue, 30 Nov 1999 17:21:14 +0000 From: Artur Silveira da Cunha Organization: REZO+ X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-bugs@freebsd.org, freebsd-stable@freebsd.org Subject: vm_fault witn 3.3-Release with NFS and Panic Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hello I'm working with 3.3 Release stable in dual processing and I obtains a vm_fault error and after some seconds an automatic reboot or a system lock. 1) How I obtain the vm_panic My hardware configuration follows: Asus P2B-D with 2 Pentium III 500Mhz 128MB memory Adaptec 2940UW ethernet card Kingston I have several NFS mounts served by an AIX computer. I use the Freebsd computer for tests only. The error is always obtained while compiling by NFS the lynx package (./configure and make) at the moment where the makefile makes a copy of the linx to .. . The error is the following: /kernel: vm_fault: pager read error, pid 6951 (cp) I restart the computer and obtains at the same moment the vm_fault error and reboots!!! 2) Some additional tests a) I try to copy the lynx to the fixed disks and I obtains the lynx package normally compiled. b) simultaneous loopings copy of several files works without problems c) the same with an SparcSolaris with simultaneous copy, works without problems 3) No vm_fault with options -r=1024,-w=1024 I could obtain my lynx with NFS when I mount the NFS with packets at 1024 bytes size. What do you think about this. It's normal in FreeBsd that I reduce the packet size to 1024? It exists another problem (network driver?). Can I use FreeBsd without the fear that I cant give to me computer a big NFS load? Artur Silveira -- Artur Silveira da Cunha email: Artur.Silveira@rezo.com REZO+ www.rezo.com Tel: 33 1 44 23 02 61 Fax: 33 1 44 23 94 45 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Tue Nov 30 10:15:53 1999 Delivered-To: freebsd-stable@freebsd.org Received: from trooper.velocet.net (trooper.velocet.net [216.126.82.226]) by hub.freebsd.org (Postfix) with ESMTP id 429071599F for ; Tue, 30 Nov 1999 10:15:32 -0800 (PST) (envelope-from dgilbert@trooper.velocet.net) Received: (from dgilbert@localhost) by trooper.velocet.net (8.9.3/8.9.3) id NAA29120; Tue, 30 Nov 1999 13:15:31 -0500 (EST) (envelope-from dgilbert) From: David Gilbert MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14404.5187.497998.940864@trooper.velocet.net> Date: Tue, 30 Nov 1999 13:15:31 -0500 (EST) To: freebsd-stable@freebsd.org Subject: stack up or stack down. X-Mailer: VM 6.75 under 20.4 "Emerald" XEmacs Lucid Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I'm trying to track down where vinum is trashing the kernel stack. It has been suggested that the only way to attack this it to rummage around the stack for a valid frame. To that end, does the kernel stack build up (from low to high addresses) or down (high to low addresses) in FreeBSD? Dave.c To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Tue Nov 30 10:39:29 1999 Delivered-To: freebsd-stable@freebsd.org Received: from forrie.net (forrie.net [216.67.12.69]) by hub.freebsd.org (Postfix) with ESMTP id 371B814CB9 for ; Tue, 30 Nov 1999 10:39:20 -0800 (PST) (envelope-from forrie@forrie.com) Received: from forrie (boomer.navinet.net [216.67.12.90]) by forrie.net (8.9.3/8.9.3) with ESMTP id NAA77168 for ; Tue, 30 Nov 1999 13:39:15 -0500 (EST) Message-Id: <4.2.2.19991130133851.014b3100@216.67.12.69> X-Sender: forrie@216.67.12.69 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Tue, 30 Nov 1999 13:39:33 -0500 To: freebsd-stable@freebsd.org From: Forrest Aldrich Subject: Today's Buildworld Fails Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Current cvsup on Freebsd-3.3-Stable: -------------------------------------------------------------- >>> Making mtree -------------------------------------------------------------- mkdir -p /usr/obj/usr/src/tmp/usr/sbin /usr/obj/usr/src/tmp/mtree ( cd /usr/src/usr.sbin/mtree; MAKEOBJDIRPREFIX=""; unset MAKEOBJDIRPREFIX; export MAKEOBJDIR=/usr/obj/usr/src/tmp/mtree; PATH=/usr/obj/usr/src/tmp/sbin:/usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tmp/bin:/usr/obj/usr/src/tmp/usr/bin:/local/sbin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/bin:/usr/local/home/forrie/bin:/usr/local/ssl/bin:/usr/X11R6/bin:/usr/local/samba/bin:/usr/local/home/forrie/bin BISON_SIMPLE=/usr/obj/usr/src/tmp/usr/share/misc/bison.simple COMPILER_PATH=/usr/obj/usr/src/tmp/usr/libexec:/usr/obj/usr/src/tmp/usr/bin GCC_EXEC_PREFIX=/usr/obj/usr/src/tmp/usr/lib:/usr/obj/usr/src/tmp/usr/lib/ LD_LIBRARY_PATH=/usr/obj/usr/src/tmp/usr/lib LIBRARY_PATH=/usr/obj/usr/src/tmp/usr/lib:/usr/obj/usr/src/tmp/usr/lib NOEXTRADEPEND=t OBJFORMAT_PATH=/usr/obj/usr/src/tmp/usr/libexec:/usr/libexec /usr/obj/usr/src/tmp/usr/bin/make DESTDIR=/usr/obj/usr/src/tmp -DNOINFO -DNOMAN -DNOPIC -DNOPROFILE -DNOSHARED all; PATH=/usr/obj/usr/src/tmp/sbin:/usr/obj/usr/src/tmp/usr! /sbin: /usr/obj/usr/src/tmp/bin:/usr/obj/usr/src/tmp/usr/bin:/local/sbin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/bin:/usr/local/home/forrie/bin:/usr/local/ssl/bin:/usr/X11R6/bin:/usr/local/samba/bin:/usr/local/home/forrie/bin BISON_SIMPLE=/usr/obj/usr/src/tmp/usr/share/misc/bison.simple COMPILER_PATH=/usr/obj/usr/src/tmp/usr/libexec:/usr/obj/usr/src/tmp/usr/bin GCC_EXEC_PREFIX=/usr/obj/usr/src/tmp/usr/lib:/usr/obj/usr/src/tmp/usr/lib/ LD_LIBRARY_PATH=/usr/obj/usr/src/tmp/usr/lib LIBRARY_PATH=/usr/obj/usr/src/tmp/usr/lib:/usr/obj/usr/src/tmp/usr/lib NOEXTRADEPEND=t OBJFORMAT_PATH=/usr/obj/usr/src/tmp/usr/libexec:/usr/libexec /usr/obj/usr/src/tmp/usr/bin/make DESTDIR=/usr/obj/usr/src/tmp -DNOINFO -DNOMAN -DNOPIC -DNOPROFILE -DNOSHARED -B install clean ) cc -O -pipe -I/usr/obj/usr/src/tmp/usr/include -c /usr/src/usr.sbin/mtree/compare.c cc: Internal compiler error: program cc1 got fatal signal 11 *** Error code 1 The machine in question has tons of RAM, so that's not the issue. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Tue Nov 30 10:55:24 1999 Delivered-To: freebsd-stable@freebsd.org Received: from misha.cisco.com (misha.cisco.com [171.69.206.50]) by hub.freebsd.org (Postfix) with ESMTP id 09CF115805 for ; Tue, 30 Nov 1999 10:55:03 -0800 (PST) (envelope-from mi@misha.cisco.com) Received: (from mi@localhost) by misha.cisco.com (8.9.3/8.9.1) id NAA50402; Tue, 30 Nov 1999 13:54:28 -0500 (EST) (envelope-from mi) Message-Id: <199911301854.NAA50402@misha.cisco.com> Subject: Re: Today's Buildworld Fails In-Reply-To: <4.2.2.19991130133851.014b3100@216.67.12.69> from Forrest Aldrich at "Nov 30, 1999 01:39:33 pm" To: Forrest Aldrich Date: Tue, 30 Nov 1999 13:54:28 -0500 (EST) Cc: freebsd-stable@FreeBSD.ORG Reply-To: mi@aldan.algebra.com From: Mikhail Teterin X-Mailer: ELM [version 2.4ME+ PL60 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Forrest Aldrich once wrote: > cc -O -pipe -I/usr/obj/usr/src/tmp/usr/include -c /usr/src/usr.sbin/mtree/compare.c > cc: Internal compiler error: program cc1 got fatal signal 11 > *** Error code 1 > The machine in question has tons of RAM, so that's not the issue. It probably is :) This, I believe, is one of the GNU-C FAQs. The most probable cause is the buggy RAM and/or overclocking. Try restarting the build. If it goes on smoothly this time, or fails in a different spot, you have the hardware problem. -mi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Tue Nov 30 11: 1:39 1999 Delivered-To: freebsd-stable@freebsd.org Received: from email.netonecom.net (email.netonecom.net [209.172.26.13]) by hub.freebsd.org (Postfix) with ESMTP id 572CA14E88 for ; Tue, 30 Nov 1999 11:01:10 -0800 (PST) (envelope-from administrator@grbs.org) Received: from pooh (gr-ppp198.triton.net [209.172.1.198]) by email.netonecom.net (8.8.5/8.7.3) with SMTP id OAA05248 for ; Tue, 30 Nov 1999 14:00:57 -0500 (EST) Received: from pooh [192.168.0.1] by pooh [192.168.0.1] with SMTP (MDaemon.v2.7.SP4.R) for ; Tue, 30 Nov 1999 14:09:56 -0500 Message-Id: <3.0.6.32.19991130140955.008e5320@pooh> X-Sender: sysadmin@pooh X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) Date: Tue, 30 Nov 1999 14:09:55 -0500 To: freebsd-stable@freebsd.org From: administrator@grbs.org Subject: PPP Problems Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MDaemon-Deliver-To: freebsd-stable@freebsd.org X-Return-Path: administrator@grbs.org Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hello everyone. I have set up PPP over an ISDN modem and it appears to work well. Unfortunately looks aren't everything. We have to pay for each time we dial out on our ISDN modem. I have ppp set on -ddial so the conection automatically stays up. In my logs it appears to be disconnecting after a number of packets. I don't know what to make of. I've attached the logs so you can see for yourself. If anything else needs to be include, just notify me. Also I have a message at the end of my dmesg conerning "rtinit" that I haven't investigated yet if anyone would like to enlighten me :) Thank You, Dan Diephouse DMESG: Copyright (c) 1992-1999 FreeBSD Inc. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 3.3-STABLE #8: Tue Nov 16 13:10:51 EST 1999 root@owl.grbs.org:/usr/src/sys/compile/OWL Timecounter "i8254" frequency 1193182 Hz CPU: Pentium Pro (686-class CPU) Origin = "GenuineIntel" Id = 0x619 Stepping = 9 Features=0xfbff real memory = 134217728 (131072K bytes) config> avail memory = 126787584 (123816K bytes) Programming 28 pins in IOAPIC #0 EISA INTCONTROL = 00000e20 IOAPIC #0 intpint 24 -> irq 13 FreeBSD/SMP: Multiprocessor motherboard cpu0 (BSP): apic id: 1, version: 0x00040011, at 0xfee00000 cpu1 (AP): apic id: 0, version: 0x00040011, at 0xfee00000 io0 (APIC): apic id: 2, version: 0x001b0011, at 0xfec00000 Preloaded elf kernel "kernel" at 0xc02d6000. Preloaded userconfig_script "/boot/kernel.conf" at 0xc02d609c. Pentium Pro MTRR support enabled eisa0: Probing for devices on the EISA bus Probing for devices on PCI bus 0: chip0: rev 0x02 on pci0.0.0 chip1: rev 0x01 on pci0.13.0 chip2: rev 0x01 on pci0.15.0 chip3: rev 0x07 on pci0.20.0 Probing for devices on PCI bus 1: vga0: rev 0x22 int a irq 255 on pci1.6.0 tl0: rev 0x10 int a irq 10 on pci1.7.0 tl0: Ethernet address: 00:80:5f:a6:29:6f tl0: autoneg not complete, no carrier ncr0: rev 0x03 int a irq 11 on pci1.9.0 xl0: <3Com 3c905B-TX Fast Etherlink XL> rev 0x24 int a irq 5 on pci1.13.0 xl0: Ethernet address: 00:10:4b:66:b4:3b xl0: autoneg not complete, no carrier (forcing half-duplex, 10Mbps) Probing for devices on PCI bus 2: ida0: rev 0x02 int a irq 9 on pci2.0.0 ida0: drvs=2 firm_rev=1.36 ida0: unit 0 (id0): id0: 8024MB (16434495 total sec), 1023 cyl, 255 head, 63 sec, bytes/sec 512 ida0: unit 1 (id1): id1: 4257MB (8719950 total sec), 953 cyl, 183 head, 50 sec, bytes/sec 512 ida: wdc vector stealing on (mode = always, boot major = 0) Probing for PnP devices: Probing for devices on the ISA bus: sc0 on isa sc0: VGA color <16 virtual consoles, flags=0x0> atkbdc0 at 0x60-0x6f on motherboard atkbd0 irq 1 on isa psm0 irq 12 on isa psm0: model Generic PS/2 mouse, device ID 0 sio0 at 0x3f8-0x3ff irq 4 flags 0x10 on isa sio0: type 16550A sio1 at 0x2f8-0x2ff irq 3 on isa sio1: type 16550A fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa fdc0: FIFO enabled, 8 bytes threshold fd0: 1.44MB 3.5in ida0 not found at 0x0 ppc0 at 0x3bc irq 7 flags 0x40 on isa ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode lpt0: on ppbus 0 lpt0: Interrupt-driven port ppi0: on ppbus 0 plip0: on ppbus 0 vga0 at 0x3b0-0x3df maddr 0xa0000 msize 131072 on isa npx0 on motherboard npx0: INT 16 interface APIC_IO: Testing 8254 interrupt delivery APIC_IO: Broken MP table detected: 8254 is not connected to IO APIC int pin 2 APIC_IO: routing 8254 via 8259 on pin 0 IP packet filtering initialized, divert disabled, rule-based forwarding disabled, unlimited logging Waiting 15 seconds for SCSI devices to settle SMP: AP CPU #1 Launched! changing root device to wd0s1a rtinit: wrong ifa (0xc19c2000) was (0xc1230380) rtinit: wrong ifa (0xc1231d00) was (0xc1230080) Daily Output for the tun0 device day 1: Network interface status: Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll tl0 1500 00.80.5f.a6.29.6f 439078 0 427924 0 0 tl0 1500 192.168 192.168.0.3 439078 0 427924 0 0 xl0* 1500 00.10.4b.66.b4.3b 0 0 0 0 0 lp0* 1500 0 0 0 0 0 tun0 1500 340470 0 325940 0 0 tun0 1500 gr-ppp142.tri gr-ppp142.trito 340470 0 325940 0 0 tun0 1500 gr-ppp158.tri gr-ppp158.trito 340470 0 325940 0 0 tun0 1500 gr-ppp209.tri gr-ppp209.trito 340470 0 325940 0 0 tun0 1500 gr-ppp214.tri gr-ppp214.trito 340470 0 325940 0 0 tun0 1500 gr-ppp183.tri gr-ppp183.trito 340470 0 325940 0 0 tun0 1500 gr-ppp107.tri gr-ppp107.trito 340470 0 325940 0 0 tun0 1500 gr-ppp53.trit gr-ppp53.triton 340470 0 325940 0 0 tun0 1500 gr-ppp9.trito gr-ppp9.triton. 340470 0 325940 0 0 tun0 1500 gr-ppp188.tri gr-ppp188.trito 340470 0 325940 0 0 tun0 1500 gr-ppp97.trit gr-ppp97.triton 340470 0 325940 0 0 tun0 1500 gr-ppp136.tri gr-ppp136.trito 340470 0 325940 0 0 tun0 1500 gr-ppp109.tri gr-ppp109.trito 340470 0 325940 0 0 tun0 1500 gr-ppp67.trit gr-ppp67.triton 340470 0 325940 0 0 tun0 1500 gr-ppp144.tri gr-ppp144.trito 340470 0 325940 0 0 tun0 1500 gr-ppp23.trit gr-ppp23.triton 340470 0 325940 0 0 tun0 1500 gr-ppp98.trit gr-ppp98.triton 340470 0 325940 0 0 tun0 1500 gr-ppp196.tri gr-ppp196.trito 340470 0 325940 0 0 tun0 1500 gr-ppp112.tri gr-ppp112.trito 340470 0 325940 0 0 tun0 1500 gr-ppp210.tri gr-ppp210.trito 340470 0 325940 0 0 tun0 1500 gr-ppp99.trit gr-ppp99.triton 340470 0 325940 0 0 tun0 1500 gr-ppp177.tri gr-ppp177.trito 340470 0 325940 0 0 tun0 1500 gr-ppp204.tri gr-ppp204.trito 340470 0 325940 0 0 tun0 1500 gr-ppp52.trit gr-ppp52.triton 340470 0 325940 0 0 tun0 1500 gr-ppp129.tri gr-ppp129.trito 340470 0 325940 0 0 tun0 1500 gr-ppp205.tri gr-ppp205.trito 340470 0 325940 0 0 tun0 1500 gr-ppp24.trit gr-ppp24.triton 340470 0 325940 0 0 tun0 1500 gr-ppp92.trit gr-ppp92.triton 340470 0 325940 0 0 tun0 1500 gr-ppp126.tri gr-ppp126.trito 340470 0 325940 0 0 tun0 1500 gr-ppp172.tri gr-ppp172.trito 340470 0 325940 0 0 tun0 1500 gr-ppp213.tri gr-ppp213.trito 340470 0 325940 0 0 tun0 1500 gr-ppp54.trit gr-ppp54.triton 340470 0 325940 0 0 tun0 1500 gr-ppp86.trit gr-ppp86.triton 340470 0 325940 0 0 tun0 1500 gr-ppp119.tri gr-ppp119.trito 340470 0 325940 0 0 tun0 1500 gr-ppp151.tri gr-ppp151.trito 340470 0 325940 0 0 tun0 1500 gr-ppp193.tri gr-ppp193.trito 340470 0 325940 0 0 tun0 1500 gr-ppp211.tri gr-ppp211.trito 340470 0 325940 0 0 tun0 1500 gr-ppp14.trit gr-ppp14.triton 340470 0 325940 0 0 tun0 1500 gr-ppp28.trit gr-ppp28.triton 340470 0 325940 0 0 tun0 1500 gr-ppp38.trit gr-ppp38.triton 340470 0 325940 0 0 tun0 1500 gr-ppp58.trit gr-ppp58.triton 340470 0 325940 0 0 tun0 1500 gr-ppp84.trit gr-ppp84.triton 340470 0 325940 0 0 tun0 1500 gr-ppp101.tri gr-ppp101.trito 340470 0 325940 0 0 tun0 1500 gr-ppp122.tri gr-ppp122.trito 340470 0 325940 0 0 tun0 1500 gr-ppp137.tri gr-ppp137.trito 340470 0 325940 0 0 tun0 1500 gr-ppp155.tri gr-ppp155.trito 340470 0 325940 0 0 tun0 1500 gr-ppp168.tri gr-ppp168.trito 340470 0 325940 0 0 tun0 1500 gr-ppp185.tri gr-ppp185.trito 340470 0 325940 0 0 tun0 1500 triton.net gr-ppp202.trito 340470 0 325940 0 0 sl0* 552 0 0 0 0 0 ppp0* 1500 0 0 0 0 0 lo0 16384 927 0 927 0 0 lo0 16384 127 localhost 927 0 927 0 0 Daily Output for the tun0 device day 2: Network interface status: Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll tl0 1500 00.80.5f.a6.29.6f 584870 1 566357 0 0 tl0 1500 192.168 192.168.0.3 584870 1 566357 0 0 xl0* 1500 00.10.4b.66.b4.3b 0 0 0 0 0 lp0* 1500 0 0 0 0 0 tun0 1500 449324 0 429181 0 0 tun0 1500 gr-ppp209.tri gr-ppp209.trito 449324 0 429181 0 0 tun0 1500 gr-ppp214.tri gr-ppp214.trito 449324 0 429181 0 0 tun0 1500 gr-ppp107.tri gr-ppp107.trito 449324 0 429181 0 0 tun0 1500 gr-ppp53.trit gr-ppp53.triton 449324 0 429181 0 0 tun0 1500 gr-ppp9.trito gr-ppp9.triton. 449324 0 429181 0 0 tun0 1500 gr-ppp188.tri gr-ppp188.trito 449324 0 429181 0 0 tun0 1500 gr-ppp109.tri gr-ppp109.trito 449324 0 429181 0 0 tun0 1500 gr-ppp67.trit gr-ppp67.triton 449324 0 429181 0 0 tun0 1500 gr-ppp196.tri gr-ppp196.trito 449324 0 429181 0 0 tun0 1500 gr-ppp112.tri gr-ppp112.trito 449324 0 429181 0 0 tun0 1500 gr-ppp210.tri gr-ppp210.trito 449324 0 429181 0 0 tun0 1500 gr-ppp99.trit gr-ppp99.triton 449324 0 429181 0 0 tun0 1500 gr-ppp177.tri gr-ppp177.trito 449324 0 429181 0 0 tun0 1500 gr-ppp204.tri gr-ppp204.trito 449324 0 429181 0 0 tun0 1500 gr-ppp129.tri gr-ppp129.trito 449324 0 429181 0 0 tun0 1500 gr-ppp205.tri gr-ppp205.trito 449324 0 429181 0 0 tun0 1500 gr-ppp92.trit gr-ppp92.triton 449324 0 429181 0 0 tun0 1500 gr-ppp126.tri gr-ppp126.trito 449324 0 429181 0 0 tun0 1500 gr-ppp172.tri gr-ppp172.trito 449324 0 429181 0 0 tun0 1500 gr-ppp54.trit gr-ppp54.triton 449324 0 429181 0 0 tun0 1500 gr-ppp119.tri gr-ppp119.trito 449324 0 429181 0 0 tun0 1500 gr-ppp151.tri gr-ppp151.trito 449324 0 429181 0 0 tun0 1500 gr-ppp211.tri gr-ppp211.trito 449324 0 429181 0 0 tun0 1500 gr-ppp14.trit gr-ppp14.triton 449324 0 429181 0 0 tun0 1500 gr-ppp28.trit gr-ppp28.triton 449324 0 429181 0 0 tun0 1500 gr-ppp38.trit gr-ppp38.triton 449324 0 429181 0 0 tun0 1500 gr-ppp84.trit gr-ppp84.triton 449324 0 429181 0 0 tun0 1500 gr-ppp101.tri gr-ppp101.trito 449324 0 429181 0 0 tun0 1500 gr-ppp155.tri gr-ppp155.trito 449324 0 429181 0 0 tun0 1500 gr-ppp185.tri gr-ppp185.trito 449324 0 429181 0 0 tun0 1500 gr-ppp202.tri gr-ppp202.trito 449324 0 429181 0 0 tun0 1500 gr-ppp2.trito gr-ppp2.triton. 449324 0 429181 0 0 tun0 1500 gr-ppp12.trit gr-ppp12.triton 449324 0 429181 0 0 tun0 1500 gr-ppp31.trit gr-ppp31.triton 449324 0 429181 0 0 tun0 1500 gr-ppp40.trit gr-ppp40.triton 449324 0 429181 0 0 tun0 1500 gr-ppp43.trit gr-ppp43.triton 449324 0 429181 0 0 tun0 1500 gr-ppp60.trit gr-ppp60.triton 449324 0 429181 0 0 tun0 1500 gr-ppp68.trit gr-ppp68.triton 449324 0 429181 0 0 tun0 1500 gr-ppp79.trit gr-ppp79.triton 449324 0 429181 0 0 tun0 1500 gr-ppp91.trit gr-ppp91.triton 449324 0 429181 0 0 tun0 1500 gr-ppp97.trit gr-ppp97.triton 449324 0 429181 0 0 tun0 1500 gr-ppp103.tri gr-ppp103.trito 449324 0 429181 0 0 tun0 1500 gr-ppp108.tri gr-ppp108.trito 449324 0 429181 0 0 tun0 1500 gr-ppp114.tri gr-ppp114.trito 449324 0 429181 0 0 tun0 1500 gr-ppp122.tri gr-ppp122.trito 449324 0 429181 0 0 tun0 1500 gr-ppp128.tri gr-ppp128.trito 449324 0 429181 0 0 tun0 1500 gr-ppp144.tri gr-ppp144.trito 449324 0 429181 0 0 tun0 1500 gr-ppp152.tri gr-ppp152.trito 449324 0 429181 0 0 tun0 1500 gr-ppp157.tri gr-ppp157.trito 449324 0 429181 0 0 tun0 1500 gr-ppp168.tri gr-ppp168.trito 449324 0 429181 0 0 tun0 1500 gr-ppp176.tri gr-ppp176.trito 449324 0 429181 0 0 tun0 1500 gr-ppp187.tri gr-ppp187.trito 449324 0 429181 0 0 tun0 1500 gr-ppp193.tri gr-ppp193.trito 449324 0 429181 0 0 tun0 1500 gr-ppp212.tri gr-ppp212.trito 449324 0 429181 0 0 tun0 1500 gr-ppp217.tri gr-ppp217.trito 449324 0 429181 0 0 tun0 1500 gr-ppp13.trit gr-ppp13.triton 449324 0 429181 0 0 tun0 1500 gr-ppp22.trit gr-ppp22.triton 449324 0 429181 0 0 tun0 1500 gr-ppp35.trit gr-ppp35.triton 449324 0 429181 0 0 tun0 1500 gr-ppp52.trit gr-ppp52.triton 449324 0 429181 0 0 tun0 1500 gr-ppp94.trit gr-ppp94.triton 449324 0 429181 0 0 tun0 1500 gr-ppp113.tri gr-ppp113.trito 449324 0 429181 0 0 tun0 1500 gr-ppp137.tri gr-ppp137.trito 449324 0 429181 0 0 tun0 1500 gr-ppp162.tri gr-ppp162.trito 449324 0 429181 0 0 tun0 1500 gr-ppp98.trit gr-ppp98.triton 449324 0 429181 0 0 tun0 1500 gr-ppp138.tri gr-ppp138.trito 449324 0 429181 0 0 tun0 1500 gr-ppp24.trit gr-ppp24.triton 449324 0 429181 0 0 tun0 1500 gr-ppp192.tri gr-ppp192.trito 449324 0 429181 0 0 tun0 1500 gr-ppp41.trit gr-ppp41.triton 449324 0 429181 0 0 tun0 1500 gr-ppp17.trit gr-ppp17.triton 449324 0 429181 0 0 tun0 1500 gr-ppp200.tri gr-ppp200.trito 449324 0 429181 0 0 tun0 1500 gr-ppp142.tri gr-ppp142.trito 449324 0 429181 0 0 tun0 1500 gr-ppp158.tri gr-ppp158.trito 449324 0 429181 0 0 tun0 1500 gr-ppp46.trit gr-ppp46.triton 449324 0 429181 0 0 tun0 1500 gr-ppp154.tri gr-ppp154.trito 449324 0 429181 0 0 tun0 1500 gr-ppp51.trit gr-ppp51.triton 449324 0 429181 0 0 tun0 1500 gr-ppp183.tri gr-ppp183.trito 449324 0 429181 0 0 tun0 1500 gr-ppp72.trit gr-ppp72.triton 449324 0 429181 0 0 tun0 1500 gr-ppp164.tri gr-ppp164.trito 449324 0 429181 0 0 tun0 1500 gr-ppp82.trit gr-ppp82.triton 449324 0 429181 0 0 tun0 1500 gr-ppp184.tri gr-ppp184.trito 449324 0 429181 0 0 tun0 1500 gr-ppp66.trit gr-ppp66.triton 449324 0 429181 0 0 tun0 1500 gr-ppp198.tri gr-ppp198.trito 449324 0 429181 0 0 tun0 1500 gr-ppp86.trit gr-ppp86.triton 449324 0 429181 0 0 tun0 1500 gr-ppp213.tri gr-ppp213.trito 449324 0 429181 0 0 tun0 1500 gr-ppp102.tri gr-ppp102.trito 449324 0 429181 0 0 tun0 1500 gr-ppp23.trit gr-ppp23.triton 449324 0 429181 0 0 tun0 1500 gr-ppp104.tri gr-ppp104.trito 449324 0 429181 0 0 tun0 1500 gr-ppp173.tri gr-ppp173.trito 449324 0 429181 0 0 tun0 1500 gr-ppp5.trito gr-ppp5.triton. 449324 0 429181 0 0 tun0 1500 gr-ppp58.trit gr-ppp58.triton 449324 0 429181 0 0 tun0 1500 gr-ppp111.tri gr-ppp111.trito 449324 0 429181 0 0 tun0 1500 gr-ppp136.tri gr-ppp136.trito 449324 0 429181 0 0 tun0 1500 triton.net gr-ppp150.trito 449324 0 429181 0 0 sl0* 552 0 0 0 0 0 ppp0* 1500 0 0 0 0 0 lo0 16384 1225 0 1225 0 0 lo0 16384 127 localhost 1225 0 1225 0 0 And my ppp.conf file: default: # # Make sure that "device" references the correct serial port # for your modem. (cuaa0 = COM1, cuaa1 = COM2) # set device /dev/cuaa0 set log Phase Chat LCP IPCP CCP tun command set speed 115200 set dial "ABORT BUSY ABORT NO\\sCARRIER TIMEOUT 5 \"\" AT OK-AT-OK \\dATDT\\T TIMEOUT 40 CONNECT" set timeout 0 set ifaddr 10.0.0.1/0 10.0.0.2/0 255.255.255.0 0.0.0.0 add default HISADDR enable dns papchap: set phone xxxxxxx set authname xxxxxx set authkey xxxxxx To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Tue Nov 30 11:31:26 1999 Delivered-To: freebsd-stable@freebsd.org Received: from trooper.velocet.net (trooper.velocet.net [216.126.82.226]) by hub.freebsd.org (Postfix) with ESMTP id 315C9159F9 for ; Tue, 30 Nov 1999 11:31:09 -0800 (PST) (envelope-from dgilbert@trooper.velocet.net) Received: (from dgilbert@localhost) by trooper.velocet.net (8.9.3/8.9.3) id OAA32005; Tue, 30 Nov 1999 14:31:07 -0500 (EST) (envelope-from dgilbert) From: David Gilbert MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14404.9723.200774.823194@trooper.velocet.net> Date: Tue, 30 Nov 1999 14:31:07 -0500 (EST) To: stable@freebsd.org Subject: Stack/i386-type ugh question. Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Ok... chasing down some memory corruption in FreeBSD's new vinum code. I have the following: #0 boot (howto=256) at ../../kern/kern_shutdown.c:285 #1 0xc0152738 in at_shutdown ( function=0xc0237182 <__set_sysinit_set_sym_memdev_sys_init+1050>, arg=0x0, queue=12) at ../../kern/kern_shutdown.c:446 #2 0xc02093e5 in trap_fatal (frame=0xc024041c, eva=0) at ../../i386/i386/trap.c:942 #3 0xc02090c3 in trap_pfault (frame=0xc024041c, usermode=0, eva=0) at ../../i386/i386/trap.c:835 #4 0xc0208d66 in trap (frame={tf_es = -1057619952, tf_ds = -1058209776, tf_edi = -1073215488, tf_esi = -1058136064, tf_ebp = -1071381356, tf_isp = -1071381436, tf_ebx = -1057770468, tf_edx = 0, tf_ecx = -1057770468, tf_eax = -919261248, tf_trapno = 12, tf_err = 0, tf_eip = 0, tf_cs = 8, tf_eflags = 66054, tf_esp = -1072236031, tf_ss = -1057770468}) at ../../i386/i386/trap.c:437 #5 0x0 in ?? () ... now obviously frame 5 has been trashed, and I doubt that I can purify my kernel (even if I had a copy). So. Which of those registers is the program counter? I need to find the stack frame #6, basically... but I suppose I need to know a few things... Is frame #6 > or < the address of frame #5? Is one of the elements of "frame" in frame 4 the PC... which might contain a hint? Dave. -- ============================================================================ |David Gilbert, Velocet Communications. | Two things can only be | |Mail: dgilbert@velocet.net | equal if and only if they | |http://www.velocet.net/~dgilbert | are precisely opposite. | =========================================================GLO================ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Tue Nov 30 11:44:41 1999 Delivered-To: freebsd-stable@freebsd.org Received: from bingnet2.cc.binghamton.edu (bingnet2.cc.binghamton.edu [128.226.1.18]) by hub.freebsd.org (Postfix) with ESMTP id AE0E215A1D for ; Tue, 30 Nov 1999 11:44:22 -0800 (PST) (envelope-from zzhang@cs.binghamton.edu) Received: from sol.cs.binghamton.edu (cs1-gw.cs.binghamton.edu [128.226.171.72]) by bingnet2.cc.binghamton.edu (8.9.3/8.9.3) with SMTP id OAA23043; Tue, 30 Nov 1999 14:44:16 -0500 (EST) Date: Tue, 30 Nov 1999 13:31:23 -0500 (EST) From: Zhihui Zhang To: David Gilbert Cc: freebsd-stable@FreeBSD.ORG Subject: Re: stack up or stack down. In-Reply-To: <14404.5187.497998.940864@trooper.velocet.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 30 Nov 1999, David Gilbert wrote: > I'm trying to track down where vinum is trashing the kernel stack. It > has been suggested that the only way to attack this it to rummage > around the stack for a valid frame. To that end, does the kernel > stack build up (from low to high addresses) or down (high to low > addresses) in FreeBSD? > This is a question determined by the Intel hardware, not by FreeBSD. So it should grow downwards (to lower addresses). Wait, it may depend on how an OS like FreeBSD sets the stack segment attributes... I'd like to know the answer. -Zhihui To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Tue Nov 30 12:59: 2 1999 Delivered-To: freebsd-stable@freebsd.org Received: from alcanet.com.au (border.alcanet.com.au [203.62.196.10]) by hub.freebsd.org (Postfix) with ESMTP id EDAF115A4E for ; Tue, 30 Nov 1999 12:58:57 -0800 (PST) (envelope-from jeremyp@gsmx07.alcatel.com.au) Received: by border.alcanet.com.au id <40322>; Wed, 1 Dec 1999 07:51:13 +1100 Content-return: prohibited Date: Wed, 1 Dec 1999 07:58:30 +1100 From: Peter Jeremy Subject: Re: stack up or stack down. In-reply-to: To: Zhihui Zhang Cc: David Gilbert , freebsd-stable@FreeBSD.ORG Reply-To: peter.jeremy@alcatel.com.au Message-Id: <99Dec1.075113est.40322@border.alcanet.com.au> MIME-version: 1.0 X-Mailer: Mutt 1.0pre3i Content-type: text/plain; charset=us-ascii References: <14404.5187.497998.940864@trooper.velocet.net> Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 1999-Dec-01 05:31:23 +1100, Zhihui Zhang wrote: >On Tue, 30 Nov 1999, David Gilbert wrote: >> To that end, does the kernel >> stack build up (from low to high addresses) or down (high to low >> addresses) in FreeBSD? > >This is a question determined by the Intel hardware, not by FreeBSD. So it >should grow downwards (to lower addresses). Wait, it may depend on how >an OS like FreeBSD sets the stack segment attributes... I'd like to know >the answer. On i386, it always goes high to low - this is hard-wired into the stack manipulating instructions. The segment attributes just select between `normal' and `stack' segments - the difference being how the base/limit is calculated (it's easy to extend a normal segment towards higher addresses and a stack segment towards lower addresses). On the Alpha, there is no hardware support for a stack, so the stack growth direction is determined by the OS and development tools. (Though I think all Alpha systems use high-to-low stacks). Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Tue Nov 30 14:13:31 1999 Delivered-To: freebsd-stable@freebsd.org Received: from alcanet.com.au (border.alcanet.com.au [203.62.196.10]) by hub.freebsd.org (Postfix) with ESMTP id 0DB6D14C97 for ; Tue, 30 Nov 1999 14:13:18 -0800 (PST) (envelope-from jeremyp@gsmx07.alcatel.com.au) Received: by border.alcanet.com.au id <40328>; Wed, 1 Dec 1999 09:05:47 +1100 Content-return: prohibited Date: Wed, 1 Dec 1999 09:13:04 +1100 From: Peter Jeremy Subject: Re: Stack/i386-type ugh question. In-reply-to: <14404.9723.200774.823194@trooper.velocet.net> To: David Gilbert Cc: stable@FreeBSD.ORG Reply-To: peter.jeremy@alcatel.com.au Message-Id: <99Dec1.090547est.40328@border.alcanet.com.au> MIME-version: 1.0 X-Mailer: Mutt 1.0pre3i Content-type: text/plain; charset=us-ascii References: <14404.9723.200774.823194@trooper.velocet.net> Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 1999-Dec-01 06:31:07 +1100, David Gilbert wrote: >Ok... chasing down some memory corruption in FreeBSD's new vinum >code. I have the following: ... > So. Which of those registers is the program counter? As a full address, the PC is %cs:%eip (tf_cs and tf_eif in the trap frame). > I need to find the stack frame #6, >basically... but I suppose I need to know a few things... > >Is frame #6 > or < the address of frame #5? An i386 function call looks like: pushl argN ... pushl arg2 pushl arg1 call func addl #...,%esp Note that the `addl' can be deferred to improve speed (see -fno-defer-pop), but the effect remains the same. And a normal function looks like: func: pushl %ebp movl %esp,%ebp subl #locals_size,%esp ... movl %ebp,%esp popl %ebp ret There are also enter and leave instructions which handle the prologue and epilogue, but the above code shows the linkage more clearly. It is also possible to disable the linked frame generation, but this isn't done by default (see -fomit-frame-pointer). Assuming a function in frame M calls frame (M-1), this gives a stack frame as follows: | | high memory |----------------| | argN | | ... | | arg2 | | arg1 | |----------------| Frame M | return address | |----------------| | previous frame |<+ |----------------| | | local vars | | |----------------| | ------------------------- | argN | | | ... | | | arg2 | | | arg1 | | Frame M-1 |----------------| | | return address | | |----------------| | | previous frame |-+ <-- %ebp |----------------| | local vars | |----------------| <-- %esp | | | | low memory gdb and ddb normally rely on the frame pointer (%ebp) to work out the stack frames during a backtrace. The problem here is that it looks like there has been a buffer overflow within a local variable which has trashed the saved frame pointer and return address. It should be possible to locate a stack by rummaging through kernel memory looking for the {previous frame},{return address} pairs, where {previous frame} can be recognised by being an int aligned memory address slightly higher (between 8 and ~200 bytes) than the current address, which points to another {previous frame}. {return address} can be recognised as being within the kernel text segment. (Finding the correct stack will be more difficult). If you are in a process context, then you should be able to find the kernel stack associated with the active process (though I can't remember how). Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Tue Nov 30 16:50:51 1999 Delivered-To: freebsd-stable@freebsd.org Received: from notrecords.com (228-121.ppp.ripco.net [209.100.228.121]) by hub.freebsd.org (Postfix) with ESMTP id E885415A03 for ; Tue, 30 Nov 1999 16:50:47 -0800 (PST) (envelope-from aphor@ripco.com) Received: from ripco.com (nell.notrecords.com [192.168.1.123]) by notrecords.com (8.9.3/8.9.3) with ESMTP id SAA02629; Tue, 30 Nov 1999 18:51:56 -0600 (CST) (envelope-from aphor@ripco.com) Message-ID: <3844714A.4944130E@ripco.com> Date: Tue, 30 Nov 1999 18:52:26 -0600 From: Jeremy McMillan Reply-To: aphor@ripco.com Organization: Loose.. X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 3.3-STABLE i386) X-Accept-Language: en MIME-Version: 1.0 To: matt Cc: FreeBSD-STABLE Subject: Re: Login.conf and tweaking. References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This is not really a FreeBSD-STABLE issue, but the rtprio stuff is relatively new, and I would like to see discussion about *that* on here. man idprio and see if that excites you. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Tue Nov 30 17:16:17 1999 Delivered-To: freebsd-stable@freebsd.org Received: from awfulhak.org (dynamic-110.max4-du-ws.dialnetwork.pavilion.co.uk [212.74.9.238]) by hub.freebsd.org (Postfix) with ESMTP id 975B814F03 for ; Tue, 30 Nov 1999 17:16:07 -0800 (PST) (envelope-from brian@Awfulhak.org) Received: from hak.lan.Awfulhak.org (root@hak.lan.Awfulhak.org [172.16.0.12]) by awfulhak.org (8.9.3/8.9.3) with ESMTP id BAA05757; Wed, 1 Dec 1999 01:07:40 GMT (envelope-from brian@lan.awfulhak.org) Received: from hak.lan.Awfulhak.org (brian@localhost.lan.Awfulhak.org [127.0.0.1]) by hak.lan.Awfulhak.org (8.9.3/8.9.3) with ESMTP id BAA06973; Wed, 1 Dec 1999 01:08:09 GMT (envelope-from brian@hak.lan.Awfulhak.org) Message-Id: <199912010108.BAA06973@hak.lan.Awfulhak.org> X-Mailer: exmh version 2.1.0 09/18/1999 To: administrator@grbs.org Cc: freebsd-stable@FreeBSD.ORG, brian@hak.lan.Awfulhak.org Subject: Re: PPP Problems In-Reply-To: Message from administrator@grbs.org of "Tue, 30 Nov 1999 14:09:55 EST." <3.0.6.32.19991130140955.008e5320@pooh> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 01 Dec 1999 01:08:09 +0000 From: Brian Somers Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG You forgot to attach the log... set log phase lcp ipcp would probably be sufficient. The rtinit warning is gone now (in -current). > Hello everyone. I have set up PPP over an ISDN modem and it appears to > work well. Unfortunately looks aren't everything. We have to pay for each > time we dial out on our ISDN modem. I have ppp set on -ddial so the > conection automatically stays up. In my logs it appears to be > disconnecting after a number of packets. I don't know what to make of. > I've attached the logs so you can see for yourself. If anything else needs > to be include, just notify me. > > Also I have a message at the end of my dmesg conerning "rtinit" that I > haven't investigated yet if anyone would like to enlighten me :) > > Thank You, > > Dan Diephouse [.....] -- Brian Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Tue Nov 30 18:28:50 1999 Delivered-To: freebsd-stable@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 758) id 121CD14CD1; Tue, 30 Nov 1999 18:28:49 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 031A31CD7F4; Tue, 30 Nov 1999 18:28:48 -0800 (PST) (envelope-from kris@hub.freebsd.org) Date: Tue, 30 Nov 1999 18:28:48 -0800 (PST) From: Kris Kennaway To: Antonio Bemfica Cc: freebsd-stable@freebsd.org Subject: Re: Is UNION fs still broken? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 30 Nov 1999, Antonio Bemfica wrote: > The subject says it all. I've seen warnings over the years about the UNION > fs not really being usable. Has the situation changed? Is it safe to use? Probably not really..it hasn't been touched in a long while, because fixing it is difficult. Work is happening in a related area in current (nullfs) which will hopefully bring it back to usefulness eventually. Kris To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Tue Nov 30 18:37:47 1999 Delivered-To: freebsd-stable@freebsd.org Received: from mta4.snfc21.pbi.net (mta4.snfc21.pbi.net [206.13.28.142]) by hub.freebsd.org (Postfix) with ESMTP id 0E4D215A54 for ; Tue, 30 Nov 1999 18:37:43 -0800 (PST) (envelope-from adagio_v@pacbell.net) Received: from pacbell.net ([63.194.212.226]) by mta4.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.1999.09.16.21.57.p8) with ESMTP id <0FM100KIDJ7L39@mta4.snfc21.pbi.net> for stable@freebsd.org; Tue, 30 Nov 1999 18:35:45 -0800 (PST) Date: Tue, 30 Nov 1999 19:44:40 -0800 From: Adagio V Subject: Re: Stack/i386-type ugh question To: stable@freebsd.org Reply-To: adagio_v@pacbell.net Message-id: <384499A8.9E67458F@pacbell.net> MIME-version: 1.0 X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.2.5-15 i586) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit X-Accept-Language: en Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > If you are in a process context, then you should be able to find the > kernel stack associated with the active process (though I can't > remember how). I'm curios too. it'll be a question best answered by DG, or Matt? adagio. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Wed Dec 1 2:32:10 1999 Delivered-To: freebsd-stable@freebsd.org Received: from mass.cdrom.com (castles561.castles.com [208.214.165.125]) by hub.freebsd.org (Postfix) with ESMTP id 52CCB14D6D; Wed, 1 Dec 1999 02:32:02 -0800 (PST) (envelope-from msmith@mass.cdrom.com) Received: from mass.cdrom.com (localhost [127.0.0.1]) by mass.cdrom.com (8.9.3/8.9.3) with ESMTP id CAA00917; Wed, 1 Dec 1999 02:33:20 -0800 (PST) (envelope-from msmith@mass.cdrom.com) Message-Id: <199912011033.CAA00917@mass.cdrom.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: stable@freebsd.org Cc: current@freebsd.org Subject: AMI MegaRAID driver compatibility update Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 01 Dec 1999 02:33:20 -0800 From: Mike Smith Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG For those who are keeping track of this, just a quick update. The 'amr' driver for AMI MegaRAID controllers in -current and available for -stable at http://www.freebsd.org/~msmith/RAID/ami has now been tested with the following AMI MegaRAID controllers: Enterprise 1500 aka 467 (new) Enterprise 1300 aka 434 (new) Enterprise 1200 aka 428 aka Dell PERC Enterprise 1100(?) aka 418 Express 200 aka 466 aka Dell PERC 2/SC It is expected to also work with: Enterprise 1400 (we expect a loan unit in a few days) Enterprise 300 (no loan unit forthcoming) Enterprise 1500-H (RAID 0/1 only) Enterprise 1400-H (RAID 0/1 only) Users have also reported success with various HP NetRAID adapters based on AMI products. Thanks to ASA Computers (www.asacomputers.com) for the loan of the Enterprise 1500 and 1300 controllers that were used in this validation. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ msmith@freebsd.org \\ and he'll hate you for a lifetime. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Wed Dec 1 2:55:22 1999 Delivered-To: freebsd-stable@freebsd.org Received: from sand2.sentex.ca (sand2.sentex.ca [209.167.248.3]) by hub.freebsd.org (Postfix) with ESMTP id 017FD14C13; Wed, 1 Dec 1999 02:55:20 -0800 (PST) (envelope-from mike@sentex.net) Received: from gravel (ospf-mdt.sentex.net [205.211.164.81]) by sand2.sentex.ca (8.8.8/8.8.8) with SMTP id FAA24084; Wed, 1 Dec 1999 05:55:30 -0500 (EST) (envelope-from mike@sentex.net) Message-Id: <4.1.19991201055408.052aca90@granite.sentex.ca> X-Sender: mdtancsa@granite.sentex.ca X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Wed, 01 Dec 1999 05:55:14 -0500 To: Mike Smith , stable@FreeBSD.ORG From: Mike Tancsa Subject: Re: AMI MegaRAID driver compatibility update In-Reply-To: <199912011033.CAA00917@mass.cdrom.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At 05:33 AM 12/1/99 , Mike Smith wrote: > >For those who are keeping track of this, just a quick update. The 'amr' Any thoughts as to when this will be officially merged with STABLE ? Will it make the next release ? ---Mike ********************************************************************** Mike Tancsa * mike@sentex.net Sentex Communications Corp, * http://www.sentex.net/mike Cambridge, Ontario * 519 651 3400 Canada * To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Wed Dec 1 5:28:14 1999 Delivered-To: freebsd-stable@freebsd.org Received: from trooper.velocet.net (trooper.velocet.net [216.126.82.226]) by hub.freebsd.org (Postfix) with ESMTP id DEC1414C80 for ; Wed, 1 Dec 1999 05:28:11 -0800 (PST) (envelope-from dgilbert@trooper.velocet.net) Received: (from dgilbert@localhost) by trooper.velocet.net (8.9.3/8.9.3) id IAA81650; Wed, 1 Dec 1999 08:28:11 -0500 (EST) (envelope-from dgilbert) From: David Gilbert MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14405.8810.777783.992833@trooper.velocet.net> Date: Wed, 1 Dec 1999 08:28:10 -0500 (EST) To: stable@freeBSD.org Subject: vinum experiences. X-Mailer: VM 6.75 under 20.4 "Emerald" XEmacs Lucid Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG While I'm still chasing the memory corruption bug in vinum, I have a couple of observations. 1. Removing a device (at least, with the ahc controller) locks the bus even though I have a RAID hot-swap ready chassy (that properly isolates the bus between commands). In my test, I had a completely quiet SCSI bus when I removed one of the drives. I then wrote to the RAID array. I got: Nov 30 18:31:51 raid1 /kernel: (da8:ahc1:0:11:0): Invalidating pack Nov 30 18:31:51 raid1 /kernel: raid.p0.s6: fatal read I/O error Nov 30 18:31:51 raid1 /kernel: vinum: raid.p0.s6 is crashed by force Nov 30 18:31:52 raid1 /kernel: vinum: raid.p0 is degraded Nov 30 18:31:52 raid1 /kernel: d7: fatal drive I/O error Nov 30 18:31:52 raid1 /kernel: vinum: drive d7 is down Nov 30 18:31:52 raid1 /kernel: raid.p0.s6: fatal write I/O error Nov 30 18:31:52 raid1 /kernel: vinum: raid.p0.s6 is stale by force Nov 30 18:31:52 raid1 /kernel: d7: fatal drive I/O error Nov 30 18:31:52 raid1 /kernel: biodone: buffer already done Nov 30 18:31:52 raid1 /kernel: (da8:ahc1:0:11:0): Synchronize cache failed, status == 0x4a, scsi status == 0x0 Nov 30 18:33:16 raid1 /kernel: (da8:ahc1:0:11:0): lost device Nov 30 18:33:16 raid1 /kernel: (da8:ahc1:0:11:0): removing device entry ... I got more than one of the Synchronize cache failed. the "lost device" was when I "camcontrol rescan 1" ... I did do a "camcontrol reset 1", but it didn't affect things. The net result is that SCSI bus 1 was wedged after this. I would conjecture that removing a device (and running with this device removed is precisely what the chassy was designed to do) should not wedge things. In fact, since the camcontrol rescan 1 was successful, I suggest that it was cam, not the ahc driver that was somehow wedged. 2. It's not obvious how to replace a dead drive with vinum. I have tried several times to perform this action without success. Vinum attach says it should do it. It refuses. It would appear that vinum can currently only be backed up when it fails (because the degraded RAID-5 still works) because adding a new drive to the system fails. Dave. -- ============================================================================ |David Gilbert, Velocet Communications. | Two things can only be | |Mail: dgilbert@velocet.net | equal if and only if they | |http://www.velocet.net/~dgilbert | are precisely opposite. | =========================================================GLO================ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Wed Dec 1 6: 4:59 1999 Delivered-To: freebsd-stable@freebsd.org Received: from dozer.skynet.be (dozer.skynet.be [195.238.2.36]) by hub.freebsd.org (Postfix) with ESMTP id DA2C614D68 for ; Wed, 1 Dec 1999 06:04:55 -0800 (PST) (envelope-from root@foxbert.skynet.be) Received: from foxbert.skynet.be (foxbert.skynet.be [195.238.1.45]) by dozer.skynet.be (8.9.3/odie-relay-v1.0) with ESMTP id PAA25851; Wed, 1 Dec 1999 15:04:53 +0100 (MET) Received: (from root@localhost) by foxbert.skynet.be (8.9.1/jovi-pop-2.1) id PAA11273; Wed, 1 Dec 1999 15:04:42 +0100 (MET) Mime-Version: 1.0 X-Sender: blk@foxbert.skynet.be Message-Id: In-Reply-To: <14405.8810.777783.992833@trooper.velocet.net> References: <14405.8810.777783.992833@trooper.velocet.net> Date: Wed, 1 Dec 1999 15:03:34 +0100 To: David Gilbert , stable@FreeBSD.ORG From: Brad Knowles Subject: Re: vinum experiences. Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At 8:28 AM -0500 1999/12/1, David Gilbert wrote: > 1. Removing a device (at least, with the ahc controller) locks the bus > even though I have a RAID hot-swap ready chassy (that properly > isolates the bus between commands). In my test, I had a completely > quiet SCSI bus when I removed one of the drives. I then wrote to the > RAID array. I got: Vinum does not (currently) support any kind of hot-swap capability. See and . > 2. It's not obvious how to replace a dead drive with vinum. I have > tried several times to perform this action without success. Vinum > attach says it should do it. It refuses. Assuming that the system has been safely shutdown and is physically powered off, I believe that the following process will work: 1. Remove the old drive, noting it's physical position in the SCSI chain, it's SCSI id, it's termination status, etc... 2. Replace the drive with an *identical* new one (same model number, same number of heads and platters, same firmware revision, etc...), and make sure that the new drive sits in the same physical position in the SCSI chain, has the same SCSI id, same termination status, etc... 3. Reboot the machine. 4. Bring up vinum (but don't attempt to mount the affected filesystem) and init the drive. 5. Use the "rebuildparity" command to start the recovery process. 6. When complete, try mounting the filesystem. Of course, I haven't actually tested this procedure (and I hope I never have to), so YMMV and use at your own risk. -- These are my opinions -- not to be taken as official Skynet policy ____________________________________________________________________ |o| Brad Knowles, Belgacom Skynet NV/SA |o| |o| Systems Architect, News & FTP Admin Rue Col. Bourg, 124 |o| |o| Phone/Fax: +32-2-706.11.11/12.49 B-1140 Brussels |o| |o| http://www.skynet.be Belgium |o| \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ Unix is like a wigwam -- no Gates, no Windows, and an Apache inside. Unix is very user-friendly. It's just picky who its friends are. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Wed Dec 1 6:28:44 1999 Delivered-To: freebsd-stable@freebsd.org Received: from trooper.velocet.net (trooper.velocet.net [216.126.82.226]) by hub.freebsd.org (Postfix) with ESMTP id 4BCC414F9F for ; Wed, 1 Dec 1999 06:28:37 -0800 (PST) (envelope-from dgilbert@trooper.velocet.net) Received: (from dgilbert@localhost) by trooper.velocet.net (8.9.3/8.9.3) id JAA83318; Wed, 1 Dec 1999 09:28:33 -0500 (EST) (envelope-from dgilbert) From: David Gilbert MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14405.12433.220410.215813@trooper.velocet.net> Date: Wed, 1 Dec 1999 09:28:33 -0500 (EST) To: Brad Knowles Cc: David Gilbert , stable@FreeBSD.ORG Subject: Re: vinum experiences. In-Reply-To: References: <14405.8810.777783.992833@trooper.velocet.net> X-Mailer: VM 6.75 under 20.4 "Emerald" XEmacs Lucid Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >>>>> "Brad" == Brad Knowles writes: Brad> At 8:28 AM -0500 1999/12/1, David Gilbert wrote: >> 1. Removing a device (at least, with the ahc controller) locks the >> bus even though I have a RAID hot-swap ready chassy (that properly >> isolates the bus between commands). In my test, I had a completely >> quiet SCSI bus when I removed one of the drives. I then wrote to >> the RAID array. I got: Brad> Vinum does not (currently) support any kind of hot-swap Brad> capability. See and Brad> . Actually, I don't think this is a vinum problem. It appears that the SCSI layer locks hard when a drive is missing, but I could be wrong. >> 2. It's not obvious how to replace a dead drive with vinum. I have >> tried several times to perform this action without success. Vinum >> attach says it should do it. It refuses. Brad> Assuming that the system has been safely shutdown and is Brad> physically powered off, I believe that the following process Brad> will work: Brad> 1. Remove the old drive, noting it's physical position in the Brad> SCSI chain, it's SCSI id, it's termination status, etc... Brad> 2. Replace the drive with an *identical* new one (same model Brad> number, same number of heads and platters, same firmware Brad> revision, etc...), and make sure that the new drive sits in the Brad> same physical position in the SCSI chain, has the same SCSI id, Brad> same termination status, etc... Brad> 3. Reboot the machine. Brad> 4. Bring up vinum (but don't attempt to mount the affected Brad> filesystem) and init the drive. Brad> 5. Use the "rebuildparity" command to start the recovery Brad> process. Brad> 6. When complete, try mounting the filesystem. Brad> Of course, I haven't actually tested this procedure (and I Brad> hope I never have to), so YMMV and use at your own risk. Problem is that we have to program for this case... if it doesn't work, then there's literally no point in vinum supporting RAID-5. The big problem is that the barrier-to-entry in this experiement is a few thousand $$, and people likely only get to work on it in the few weeks between equipment arriving and equipment going into production. Dave. -- ============================================================================ |David Gilbert, Velocet Communications. | Two things can only be | |Mail: dgilbert@velocet.net | equal if and only if they | |http://www.velocet.net/~dgilbert | are precisely opposite. | =========================================================GLO================ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Wed Dec 1 6:39:17 1999 Delivered-To: freebsd-stable@freebsd.org Received: from dozer.skynet.be (dozer.skynet.be [195.238.2.36]) by hub.freebsd.org (Postfix) with ESMTP id AE34414D70 for ; Wed, 1 Dec 1999 06:39:14 -0800 (PST) (envelope-from root@foxbert.skynet.be) Received: from foxbert.skynet.be (foxbert.skynet.be [195.238.1.45]) by dozer.skynet.be (8.9.3/odie-relay-v1.0) with ESMTP id PAA06141; Wed, 1 Dec 1999 15:39:09 +0100 (MET) Received: (from root@localhost) by foxbert.skynet.be (8.9.1/jovi-pop-2.1) id PAA11561; Wed, 1 Dec 1999 15:39:04 +0100 (MET) Mime-Version: 1.0 X-Sender: blk@foxbert.skynet.be Message-Id: In-Reply-To: References: <14405.8810.777783.992833@trooper.velocet.net> Date: Wed, 1 Dec 1999 15:36:54 +0100 To: David Gilbert , stable@FreeBSD.ORG From: Brad Knowles Subject: Re: vinum experiences. Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At 3:03 PM +0100 1999/12/1, Brad Knowles wrote: > 2. Replace the drive with an *identical* new one (same model > number, same number of heads and platters, same firmware revision, > etc...), and make sure that the new drive sits in the same > physical position in the SCSI chain, has the same SCSI id, same > termination status, etc... Oh, yeah -- you're also going to need to make sure that you've already run fdisk on this drive, and set up the volume tables to exactly match those of the drive it's replacing. Same with the drive label and volume partition map. -- These are my opinions -- not to be taken as official Skynet policy ____________________________________________________________________ |o| Brad Knowles, Belgacom Skynet NV/SA |o| |o| Systems Architect, News & FTP Admin Rue Col. Bourg, 124 |o| |o| Phone/Fax: +32-2-706.11.11/12.49 B-1140 Brussels |o| |o| http://www.skynet.be Belgium |o| \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ Unix is like a wigwam -- no Gates, no Windows, and an Apache inside. Unix is very user-friendly. It's just picky who its friends are. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Wed Dec 1 7:45:41 1999 Delivered-To: freebsd-stable@freebsd.org Received: from tank.skynet.be (tank.skynet.be [195.238.2.35]) by hub.freebsd.org (Postfix) with ESMTP id 6C51414CC5 for ; Wed, 1 Dec 1999 07:45:37 -0800 (PST) (envelope-from root@foxbert.skynet.be) Received: from foxbert.skynet.be (foxbert.skynet.be [195.238.1.45]) by tank.skynet.be (8.9.3/odie-relay-v1.0) with ESMTP id QAA21863; Wed, 1 Dec 1999 16:45:25 +0100 (MET) Received: (from root@localhost) by foxbert.skynet.be (8.9.1/jovi-pop-2.1) id QAA11631; Wed, 1 Dec 1999 16:45:17 +0100 (MET) Mime-Version: 1.0 X-Sender: blk@foxbert.skynet.be Message-Id: In-Reply-To: <14405.12433.220410.215813@trooper.velocet.net> References: <14405.8810.777783.992833@trooper.velocet.net> <14405.12433.220410.215813@trooper.velocet.net> Date: Wed, 1 Dec 1999 16:20:01 +0100 To: David Gilbert From: Brad Knowles Subject: Re: vinum experiences. Cc: David Gilbert , stable@FreeBSD.ORG Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At 9:28 AM -0500 1999/12/1, David Gilbert wrote: > Actually, I don't think this is a vinum problem. It appears that the > SCSI layer locks hard when a drive is missing, but I could be wrong. It is entirely possible that the problems you saw are with the cam SCSI driver locking up, but even if it didn't lock up, you'd also need support within vinum, otherwise it would do you no good. > Problem is that we have to program for this case... if it doesn't > work, then there's literally no point in vinum supporting RAID-5. Vinum is very much a work-in-progress. In fact, the RAID-5 part was only very recently publicly available (you used to have to write into another company, get a license approval from them, and then Greg could send you pre-compiled binaries). There's a lot of stuff within the RAID-5 implementation that continues to need work, and the whole failure/replacement process is a big part of that. > The big problem is that the barrier-to-entry in this experiement is a > few thousand $$, and people likely only get to work on it in the few > weeks between equipment arriving and equipment going into production. Hardware-wise, you can get controllers that support RAID-5, work under FreeBSD, and are not excessively expensive. However, their performance is likely to be less than desirable -- see for my personal experiences. At this stage, although vinum seems to work just fine for striping and mirroring (although you have to mirror the stripes, instead of being able to stripe the mirrors), it seems to have a number of open problems in the RAID-5 arena. Although I would (and do) use vinum for striping or mirroring on production servers, I would not yet choose to use vinum RAID-5 on a production server. -- These are my opinions -- not to be taken as official Skynet policy ____________________________________________________________________ |o| Brad Knowles, Belgacom Skynet NV/SA |o| |o| Systems Architect, News & FTP Admin Rue Col. Bourg, 124 |o| |o| Phone/Fax: +32-2-706.11.11/12.49 B-1140 Brussels |o| |o| http://www.skynet.be Belgium |o| \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ Unix is like a wigwam -- no Gates, no Windows, and an Apache inside. Unix is very user-friendly. It's just picky who its friends are. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Wed Dec 1 9:17:36 1999 Delivered-To: freebsd-stable@freebsd.org Received: from zgia.zp.ua (Eagle.ZGIA.zp.ua [194.183.182.2]) by hub.freebsd.org (Postfix) with SMTP id 6F82114C93 for ; Wed, 1 Dec 1999 09:17:21 -0800 (PST) (envelope-from laa@zgia.zp.ua) Received: from localhost (laa@localhost) by zgia.zp.ua (8.9.3/8.9.3) with ESMTP id UAA00557 for ; Wed, 1 Dec 1999 20:16:20 GMT Date: Wed, 1 Dec 1999 20:16:20 +0000 (GMT) From: Alexandr Listopad To: freebsd-stable@freebsd.org Subject: subscribe Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG subscribe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Wed Dec 1 10: 7:52 1999 Delivered-To: freebsd-stable@freebsd.org Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169]) by hub.freebsd.org (Postfix) with ESMTP id 59F791506F for ; Wed, 1 Dec 1999 10:07:44 -0800 (PST) (envelope-from ken@panzer.kdm.org) Received: (from ken@localhost) by panzer.kdm.org (8.9.3/8.9.1) id LAA43219; Wed, 1 Dec 1999 11:06:35 -0700 (MST) (envelope-from ken) Message-Id: <199912011806.LAA43219@panzer.kdm.org> Subject: Re: vinum experiences. In-Reply-To: <14405.8810.777783.992833@trooper.velocet.net> from David Gilbert at "Dec 1, 1999 08:28:10 am" To: dgilbert@velocet.ca (David Gilbert) Date: Wed, 1 Dec 1999 11:06:35 -0700 (MST) Cc: stable@FreeBSD.ORG From: "Kenneth D. Merry" X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG [ If you want to comment on SCSI issues, I would suggest mailing the -scsi list, since you'll get a wider audience of people who know about SCSI. ] David Gilbert wrote... > While I'm still chasing the memory corruption bug in vinum, I have a > couple of observations. > > 1. Removing a device (at least, with the ahc controller) locks the bus > even though I have a RAID hot-swap ready chassy (that properly > isolates the bus between commands). In my test, I had a completely > quiet SCSI bus when I removed one of the drives. I then wrote to the > RAID array. I got: > > Nov 30 18:31:51 raid1 /kernel: (da8:ahc1:0:11:0): Invalidating pack > Nov 30 18:31:51 raid1 /kernel: raid.p0.s6: fatal read I/O error > Nov 30 18:31:51 raid1 /kernel: vinum: raid.p0.s6 is crashed by force > Nov 30 18:31:52 raid1 /kernel: vinum: raid.p0 is degraded > Nov 30 18:31:52 raid1 /kernel: d7: fatal drive I/O error > Nov 30 18:31:52 raid1 /kernel: vinum: drive d7 is down > Nov 30 18:31:52 raid1 /kernel: raid.p0.s6: fatal write I/O error > Nov 30 18:31:52 raid1 /kernel: vinum: raid.p0.s6 is stale by force > Nov 30 18:31:52 raid1 /kernel: d7: fatal drive I/O error > Nov 30 18:31:52 raid1 /kernel: biodone: buffer already done That looks like it may be a vinum issue. You shouldn't be getting buffers done twice, as that error message indicates. Have you talked to Greg at all about this? If you're chasing down bugs in Vinum, it would make sense to contact the author and work with him to either find the problem, or trace it to some other part of the system. > Nov 30 18:31:52 raid1 /kernel: (da8:ahc1:0:11:0): Synchronize cache failed, status == 0x4a, scsi status == 0x0 > Nov 30 18:33:16 raid1 /kernel: (da8:ahc1:0:11:0): lost device > Nov 30 18:33:16 raid1 /kernel: (da8:ahc1:0:11:0): removing device entry > > ... I got more than one of the Synchronize cache failed. the "lost > device" was when I "camcontrol rescan 1" ... I did do a "camcontrol > reset 1", but it didn't affect things. All of that is normal. The synchronize cache failed since there was no device there to talk to. You probably got more than one of those because it was retried. > The net result is that SCSI bus 1 was wedged after this. I would > conjecture that removing a device (and running with this device > removed is precisely what the chassy was designed to do) should not > wedge things. How do you know the bus was wedged? Could you issue SCSI commands with camcontrol? e.g.: camcontrol tur da10 -v Will issue a test unit ready to da10. If it responds, the bus isn't wedged. > In fact, since the camcontrol rescan 1 was successful, I suggest that > it was cam, not the ahc driver that was somehow wedged. I don't think it's clear at all what wedged. The fact that you were able to rescan the bus indicates that the CAM side of things is probably working properly. One of the things that a rescan does is send a SCSI inquiry command to every possible target ID on the bus. You can't do that if the bus is wedged. Ken -- Kenneth Merry ken@kdm.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Wed Dec 1 10: 8: 2 1999 Delivered-To: freebsd-stable@freebsd.org Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169]) by hub.freebsd.org (Postfix) with ESMTP id 4A0571506F for ; Wed, 1 Dec 1999 10:07:55 -0800 (PST) (envelope-from ken@panzer.kdm.org) Received: (from ken@localhost) by panzer.kdm.org (8.9.3/8.9.1) id LAA43219; Wed, 1 Dec 1999 11:06:35 -0700 (MST) (envelope-from ken) Message-Id: <199912011806.LAA43219@panzer.kdm.org> Subject: Re: vinum experiences. In-Reply-To: <14405.8810.777783.992833@trooper.velocet.net> from David Gilbert at "Dec 1, 1999 08:28:10 am" To: dgilbert@velocet.ca (David Gilbert) Date: Wed, 1 Dec 1999 11:06:35 -0700 (MST) Cc: stable@FreeBSD.ORG From: "Kenneth D. Merry" X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG [ If you want to comment on SCSI issues, I would suggest mailing the -scsi list, since you'll get a wider audience of people who know about SCSI. ] David Gilbert wrote... > While I'm still chasing the memory corruption bug in vinum, I have a > couple of observations. > > 1. Removing a device (at least, with the ahc controller) locks the bus > even though I have a RAID hot-swap ready chassy (that properly > isolates the bus between commands). In my test, I had a completely > quiet SCSI bus when I removed one of the drives. I then wrote to the > RAID array. I got: > > Nov 30 18:31:51 raid1 /kernel: (da8:ahc1:0:11:0): Invalidating pack > Nov 30 18:31:51 raid1 /kernel: raid.p0.s6: fatal read I/O error > Nov 30 18:31:51 raid1 /kernel: vinum: raid.p0.s6 is crashed by force > Nov 30 18:31:52 raid1 /kernel: vinum: raid.p0 is degraded > Nov 30 18:31:52 raid1 /kernel: d7: fatal drive I/O error > Nov 30 18:31:52 raid1 /kernel: vinum: drive d7 is down > Nov 30 18:31:52 raid1 /kernel: raid.p0.s6: fatal write I/O error > Nov 30 18:31:52 raid1 /kernel: vinum: raid.p0.s6 is stale by force > Nov 30 18:31:52 raid1 /kernel: d7: fatal drive I/O error > Nov 30 18:31:52 raid1 /kernel: biodone: buffer already done That looks like it may be a vinum issue. You shouldn't be getting buffers done twice, as that error message indicates. Have you talked to Greg at all about this? If you're chasing down bugs in Vinum, it would make sense to contact the author and work with him to either find the problem, or trace it to some other part of the system. > Nov 30 18:31:52 raid1 /kernel: (da8:ahc1:0:11:0): Synchronize cache failed, status == 0x4a, scsi status == 0x0 > Nov 30 18:33:16 raid1 /kernel: (da8:ahc1:0:11:0): lost device > Nov 30 18:33:16 raid1 /kernel: (da8:ahc1:0:11:0): removing device entry > > ... I got more than one of the Synchronize cache failed. the "lost > device" was when I "camcontrol rescan 1" ... I did do a "camcontrol > reset 1", but it didn't affect things. All of that is normal. The synchronize cache failed since there was no device there to talk to. You probably got more than one of those because it was retried. > The net result is that SCSI bus 1 was wedged after this. I would > conjecture that removing a device (and running with this device > removed is precisely what the chassy was designed to do) should not > wedge things. How do you know the bus was wedged? Could you issue SCSI commands with camcontrol? e.g.: camcontrol tur da10 -v Will issue a test unit ready to da10. If it responds, the bus isn't wedged. > In fact, since the camcontrol rescan 1 was successful, I suggest that > it was cam, not the ahc driver that was somehow wedged. I don't think it's clear at all what wedged. The fact that you were able to rescan the bus indicates that the CAM side of things is probably working properly. One of the things that a rescan does is send a SCSI inquiry command to every possible target ID on the bus. You can't do that if the bus is wedged. Ken -- Kenneth Merry ken@kdm.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Wed Dec 1 10:57: 3 1999 Delivered-To: freebsd-stable@freebsd.org Received: from p.wl.vg (209-9-69-194.sdsl.cais.net [209.9.69.194]) by hub.freebsd.org (Postfix) with ESMTP id C02B115B2D for ; Wed, 1 Dec 1999 10:57:00 -0800 (PST) (envelope-from patrick@p.wl.vg) Received: (from patrick@localhost) by p.wl.vg (8.9.3/8.9.3) id NAA01176 for freebsd-stable@freebsd.org; Wed, 1 Dec 1999 13:56:01 -0500 (EST) (envelope-from patrick) Message-Id: <199912011856.NAA01176@p.wl.vg> Date: Wed, 1 Dec 1999 13:56:01 -0500 (EST) From: patrick@whetstonelogic.com Subject: VMWare on FreeBSD To: freebsd-stable@freebsd.org MIME-Version: 1.0 Content-Type: TEXT/plain; CHARSET=US-ASCII Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG It looks like Vladimir N. Silyaev has gotten vmware to work on -current. (See http://www.mindspring.com/~vsilyaev/vmware/ ). Has anyone gotten this to work on -stable? I tried, but not for very long. Patrick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Wed Dec 1 11:15:43 1999 Delivered-To: freebsd-stable@freebsd.org Received: from trooper.velocet.net (trooper.velocet.net [216.126.82.226]) by hub.freebsd.org (Postfix) with ESMTP id E0A2214C3F for ; Wed, 1 Dec 1999 11:15:39 -0800 (PST) (envelope-from dgilbert@trooper.velocet.net) Received: (from dgilbert@localhost) by trooper.velocet.net (8.9.3/8.9.3) id OAA97820; Wed, 1 Dec 1999 14:15:35 -0500 (EST) (envelope-from dgilbert) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14405.29655.226854.708506@trooper.velocet.net> Date: Wed, 1 Dec 1999 14:15:35 -0500 (EST) From: David Gilbert To: freebsd-stable@freebsd.org Subject: finding the missing stack frame. X-Mailer: VM 6.75 under 20.4 "Emerald" XEmacs Lucid Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Several people have written lately about how the stack frame is structured. It seems, however, that the only possible search here is by hand... that gdb does not have any means by which to automate the search. If I was tempted to have a go with Python or perl, what is the format of a crash dump --- how would I find the area that I'm looking at with gdb? Dave. -- ============================================================================ |David Gilbert, Velocet Communications. | Two things can only be | |Mail: dgilbert@velocet.net | equal if and only if they | |http://www.velocet.net/~dgilbert | are precisely opposite. | =========================================================GLO================ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Wed Dec 1 12:51:34 1999 Delivered-To: freebsd-stable@freebsd.org Received: from mail.rdc2.on.home.com (ha1.rdc2.on.home.com [24.9.0.15]) by hub.freebsd.org (Postfix) with ESMTP id 462E215220 for ; Wed, 1 Dec 1999 12:51:22 -0800 (PST) (envelope-from bullfighter@home.com) Received: from home.com ([24.64.153.201]) by mail.rdc2.on.home.com (InterMail v4.01.01.07 201-229-111-110) with ESMTP id <19991201205057.KUEA26733.mail.rdc2.on.home.com@home.com>; Wed, 1 Dec 1999 12:50:57 -0800 Message-ID: <384589FD.14CCA8BB@home.com> Date: Wed, 01 Dec 1999 15:50:05 -0500 From: M a t a d o r X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.3-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: "Kenneth D. Merry" Cc: David Gilbert , stable@FreeBSD.ORG Subject: Re: vinum experiences. References: <199912011806.LAA43219@panzer.kdm.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > While I'm still chasing the memory corruption bug in vinum, I have a > > couple of observations. > > > > 1. Removing a device (at least, with the ahc controller) locks the bus > > even though I have a RAID hot-swap ready chassy (that properly > > isolates the bus between commands). In my test, I had a completely > > quiet SCSI bus when I removed one of the drives. I then wrote to the > > RAID array. I got: > > > > Nov 30 18:31:51 raid1 /kernel: (da8:ahc1:0:11:0): Invalidating pack > > Nov 30 18:31:51 raid1 /kernel: raid.p0.s6: fatal read I/O error > > Nov 30 18:31:51 raid1 /kernel: vinum: raid.p0.s6 is crashed by force > > Nov 30 18:31:52 raid1 /kernel: vinum: raid.p0 is degraded > That looks like it may be a vinum issue. You shouldn't be getting buffers > done twice, as that error message indicates. Have you talked to Greg at > all about this? If you're chasing down bugs in Vinum, it would make sense > to contact the author and work with him to either find the problem, or > trace it to some other part of the system. > > > Nov 30 18:31:52 raid1 /kernel: (da8:ahc1:0:11:0): Synchronize cache failed, status == 0x4a, scsi status == 0x0 > > Nov 30 18:33:16 raid1 /kernel: (da8:ahc1:0:11:0): lost device > > Nov 30 18:33:16 raid1 /kernel: (da8:ahc1:0:11:0): removing device entry > > > > ... I got more than one of the Synchronize cache failed. the "lost > > device" was when I "camcontrol rescan 1" ... I did do a "camcontrol > > reset 1", but it didn't affect things. > > All of that is normal. The synchronize cache failed since there was no > device there to talk to. You probably got more than one of those because > it was retried. > > > The net result is that SCSI bus 1 was wedged after this. I would > > conjecture that removing a device (and running with this device > > removed is precisely what the chassy was designed to do) should not > > wedge things. > > How do you know the bus was wedged? Could you issue SCSI commands with > camcontrol? e.g.: > > camcontrol tur da10 -v > > Will issue a test unit ready to da10. If it responds, the bus isn't > wedged. > > > In fact, since the camcontrol rescan 1 was successful, I suggest that > > it was cam, not the ahc driver that was somehow wedged. > > I don't think it's clear at all what wedged. The fact that you were able > to rescan the bus indicates that the CAM side of things is probably working > properly. One of the things that a rescan does is send a SCSI inquiry > command to every possible target ID on the bus. You can't do that if the > bus is wedged. Doesn't this all mean and conclude that vinum is not yet 100%, or even 70%, supportive of RAID-5, AND Hot-Swap. I thought vinum didn't support hot-swap. I've been tuning into this discussion, staying relatively silent as it wooshes above my head, but anyway, feel free to ignore my comment. :) Ciao, Matador matador@techie.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Wed Dec 1 13:59:52 1999 Delivered-To: freebsd-stable@freebsd.org Received: from 24-25-220-29.san.rr.com (24-25-220-29.san.rr.com [24.25.220.29]) by hub.freebsd.org (Postfix) with ESMTP id 569FD14BC6 for ; Wed, 1 Dec 1999 13:59:50 -0800 (PST) (envelope-from Doug@gorean.org) Received: from gateway.gorean.org (gateway.gorean.org [10.0.0.1]) by 24-25-220-29.san.rr.com (8.9.3/8.8.8) with ESMTP id NAA52864; Wed, 1 Dec 1999 13:57:06 -0800 (PST) (envelope-from Doug@gorean.org) Date: Wed, 1 Dec 1999 13:56:36 -0800 (PST) From: Doug Barton X-Sender: doug@24-25-220-29.san.rr.com To: "Jordan K. Hubbard" Cc: David Gilbert , stable@FreeBSD.ORG Subject: Re: vinum crash... how to proceed. In-Reply-To: <87232.943908696@zippy.cdrom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 29 Nov 1999, Jordan K. Hubbard wrote: > > Ok... on my 8 drive vinum system, I can cause a crash with a simple > > "du" in a directory which is a copy of a normal usr filesystem. My > > problem is that the kernel dump (as follows) is less-than-helpful. > > Why is the 5th frame on the stack 0x0? How do I find out what caused > > the trap() call? > > Look at frame 3 - it's quite obvious. Well, "obvious" here is a relative term Jordan. :) It seems to me that he was asking for just the information you provided, but since he actually did what we ask people to do (send in full info, traces, etc.) let's not jump his case for not already knowing how to debug trace backs, eh? Doug (who had to learn this stuff too, way back when) -- "Welcome to the desert of the real." - Laurence Fishburne as Morpheus, "The Matrix" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Wed Dec 1 14: 4:11 1999 Delivered-To: freebsd-stable@freebsd.org Received: from trooper.velocet.net (trooper.velocet.net [216.126.82.226]) by hub.freebsd.org (Postfix) with ESMTP id 43AEA14F94 for ; Wed, 1 Dec 1999 14:04:08 -0800 (PST) (envelope-from dgilbert@trooper.velocet.net) Received: (from dgilbert@localhost) by trooper.velocet.net (8.9.3/8.9.3) id RAA04625; Wed, 1 Dec 1999 17:02:48 -0500 (EST) (envelope-from dgilbert) From: David Gilbert MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14405.39687.664218.939146@trooper.velocet.net> Date: Wed, 1 Dec 1999 17:02:47 -0500 (EST) To: Doug Barton Cc: "Jordan K. Hubbard" , David Gilbert , stable@FreeBSD.ORG Subject: Re: vinum crash... how to proceed. In-Reply-To: References: <87232.943908696@zippy.cdrom.com> X-Mailer: VM 6.75 under 20.4 "Emerald" XEmacs Lucid Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >>>>> "Doug" == Doug Barton writes: Doug> Well, "obvious" here is a relative term Jordan. :) It seems to Doug> me that he was asking for just the information you provided, but Doug> since he actually did what we ask people to do (send in full Doug> info, traces, etc.) let's not jump his case for not already Doug> knowing how to debug trace backs, eh? Doug> Doug (who had to learn this stuff too, way back when) -- Doug> "Welcome to the desert of the real." :) Well... I don't know if I can sensibly identify where the next stack frame is --- visual inspection leads quicker to sleepyness than anything else. The only thing I've come up with is to add a unique "string" to the top (and/or bottom) of the stack variables. This string could help me find the stack frame (something more "obvious" to look for) ... it's also possible that one could check the string on entry/exit to key vinum functions ... but there is a chance that we're not in the vinum code when things crash. Dave. -- ============================================================================ |David Gilbert, Velocet Communications. | Two things can only be | |Mail: dgilbert@velocet.net | equal if and only if they | |http://www.velocet.net/~dgilbert | are precisely opposite. | =========================================================GLO================ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Wed Dec 1 22:57:11 1999 Delivered-To: freebsd-stable@freebsd.org Received: from cricket.paradox.net.au (cricket.paradox.net.au [202.61.225.33]) by hub.freebsd.org (Postfix) with ESMTP id 7CB9115202 for ; Wed, 1 Dec 1999 22:57:01 -0800 (PST) (envelope-from peter@paradox.net.au) Received: from paradox.net.au (peter@locust.per.paradox.net.au [202.61.225.19]) by cricket.paradox.net.au (8.9.3/8.9.1) with ESMTP id OAA28905 for ; Thu, 2 Dec 1999 14:56:05 +0800 (WST) Message-ID: <3846188F.1C8631E8@paradox.net.au> Date: Thu, 02 Dec 1999 14:58:23 +0800 From: Peter Caffin X-Mailer: Mozilla 4.61 [en] (X11; I; FreeBSD 4.0-CURRENT i386) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-stable@FreeBSD.org Subject: subscribe peter@paradox.net.au Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Thu Dec 2 4:33: 8 1999 Delivered-To: freebsd-stable@freebsd.org Received: from mail.rdc1.tn.home.com (ha1.rdc1.tn.home.com [24.2.7.66]) by hub.freebsd.org (Postfix) with ESMTP id B806B14DBA for ; Thu, 2 Dec 1999 04:33:06 -0800 (PST) (envelope-from williamsl@Home.Com) Received: from RELIABLE ([24.4.115.31]) by mail.rdc1.tn.home.com (InterMail v4.01.01.00 201-229-111) with ESMTP id <19991202123245.IDRO7535.mail.rdc1.tn.home.com@RELIABLE> for ; Thu, 2 Dec 1999 04:32:45 -0800 Date: Thu, 2 Dec 1999 07:30:05 -0500 From: Ben WIlliams X-Mailer: The Bat! (v1.34a) UNREG / CD5BF9353B3B7091 Reply-To: Ben WIlliams X-Priority: 3 (Normal) Message-ID: <11312.991202@Home.Com> To: freebsd-stable@freebsd.org Subject: kernel compile succeeds but is unusable Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I have a Pentium 100 that I am trying to compile a kernel for 3.2-RELEASE on and it doesn't seem to matter -what- I try to put in the config file but whenever I try to boot from a custom kernel it dies right after it finds the npx. The step that immediately follows this while booting off the GENERIC kernel is it installs the Pentium F00F hack. Instead with whatever custom kernel I try to boot I get the (in)famous "supevisor read, page not present" crash. Following the instructions at "Making the most of a kernel panic" ( http://www.freebsd.org/FAQ/book.html#AEN3789 ) I got this: (c019a63b was the instruction pointer) bash-2.03# nm kernel.DEBUG | grep -i "c019a63b" bash-2.03# nm kernel.DEBUG | grep -i "c019a63" bash-2.03# nm kernel.DEBUG | grep -i "c019a6" c019a648 t cnuninit c019a6a0 t sysctl_kern_consmute bash-2.03# So this tell me the fault was either in cnuninit or sysctl_kern_consmute. I'm stuck now. I don't know what to look in or what to look for. -- Ben mailto:williamsl@Home.Com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Thu Dec 2 7:54:38 1999 Delivered-To: freebsd-stable@freebsd.org Received: from sstar.com (sstar.com [209.102.160.1]) by hub.freebsd.org (Postfix) with ESMTP id BE69C14D06 for ; Thu, 2 Dec 1999 07:54:35 -0800 (PST) (envelope-from king@sstar.com) Received: from JKING ([134.132.75.164]) by sstar.com with ESMTP (IPAD 2.52) id 6545400; Thu, 02 Dec 1999 09:53:27 -0600 Message-Id: <4.2.0.58.19991202095115.00aa9648@mail.sstar.com> X-Sender: king@mail.sstar.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Thu, 02 Dec 1999 09:53:27 -0600 To: freebsd-stable@freebsd.org From: Jim King Subject: swap_pager: indefinite wait buffer? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Sorry if this doesn't belong on -stable, but I didn't get a response on -questions. I got this in my messages file: Dec 1 09:10:20 cgi /kernel: swap_pager: indefinite wait buffer: device: 0x20401, blkno: 776, size: 4096 Dec 1 09:11:31 cgi /kernel: swap_pager: indefinite wait buffer: device: 0x20401, blkno: 776, size: 4096 Dec 1 09:11:32 cgi last message repeated 2 times What exactly does this mean? I'm afraid that it means some disk hardware is flaking out. If that's the case how do I know which disk had the problem? (I have swap space on two drives.) Jim To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Thu Dec 2 9:52:33 1999 Delivered-To: freebsd-stable@freebsd.org Received: from sstar.com (sstar.com [209.102.160.1]) by hub.freebsd.org (Postfix) with ESMTP id 666BD14D09 for ; Thu, 2 Dec 1999 09:52:03 -0800 (PST) (envelope-from king@sstar.com) Received: from JKING ([134.132.75.164]) by sstar.com with ESMTP (IPAD 2.52) id 6608800; Thu, 02 Dec 1999 11:49:19 -0600 Message-Id: <4.2.0.58.19991202114512.00a47948@mail.sstar.com> X-Sender: king@mail.sstar.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Thu, 02 Dec 1999 11:49:19 -0600 To: freebsd-stable@freebsd.org From: Jim King Subject: Re: swap_pager: indefinite wait buffer? In-Reply-To: <4.2.0.58.19991202095115.00aa9648@mail.sstar.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At 09:53 AM 12/2/1999 -0600, Jim King wrote: >Sorry if this doesn't belong on -stable, but I didn't get a response on >-questions. > >I got this in my messages file: > >Dec 1 09:10:20 cgi /kernel: swap_pager: indefinite wait buffer: device: >0x20401, blkno: 776, size: 4096 >Dec 1 09:11:31 cgi /kernel: swap_pager: indefinite wait buffer: device: >0x20401, blkno: 776, size: 4096 >Dec 1 09:11:32 cgi last message repeated 2 times > >What exactly does this mean? I'm afraid that it means some disk hardware >is flaking out. If that's the case how do I know which disk had the >problem? (I have swap space on two drives.) OK, call me a doofus for not searching the mailing list archives. To answer my own question, this means that a pageout took longer than 20 seconds on device major 4, minor 0x20001, which happens to be /dev/da0s1b on my system (swap space on the first drive). The usual advice is that this is harmless. It does NOT indicate failing hardware. However, it does indicate a busy disk, and if it happens a lot you should probably add swap space on another drive (already done, unfortunately) and/or more memory. I saw this question a lot in the archives. Would this be a good one for the FAQ? Jim To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Thu Dec 2 10:21:22 1999 Delivered-To: freebsd-stable@freebsd.org Received: from jerry.kfunigraz.ac.at (GIGAJERRY.kfunigraz.ac.at [143.50.55.161]) by hub.freebsd.org (Postfix) with ESMTP id 63AF214E06 for ; Thu, 2 Dec 1999 10:21:08 -0800 (PST) (envelope-from mkamm@tom.kfunigraz.ac.at) Received: from tom.kfunigraz.ac.at (mc_tom [10.10.1.160]) by jerry.kfunigraz.ac.at (8.9.3/8.9.3) with ESMTP id TAA15026 for ; Thu, 2 Dec 1999 19:20:50 +0100 (MET) Received: from localhost.kfunigraz.ac.at (BONLINEB85.kfunigraz.ac.at [143.50.33.85]) by tom.kfunigraz.ac.at (8.9.3/8.9.3) with ESMTP id TAA12698 for ; Thu, 2 Dec 1999 19:20:48 +0100 (MET) Received: from localhost (mkamm@localhost) by localhost.kfunigraz.ac.at (8.9.3/8.9.3) with ESMTP id TAA68290 for ; Thu, 2 Dec 1999 19:11:56 +0100 (CET) (envelope-from mkamm@localhost.kfunigraz.ac.at) Date: Thu, 2 Dec 1999 19:11:56 +0100 (CET) From: Martin Kammerhofer Reply-To: Martin Kammerhofer To: freebsd-stable@freebsd.org Subject: status of USB support in -stable Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG What is the status of USB in -stable? Can I expect problems connecting a USB printer to a FreeBSD 3.4 box? TIA, Martin P.S.: I've checked the list archives but couldn't answer this question myself. The FAQ at http://www.etla.net/~n_hibma/usb/FAQ.pl refers to 3.2 only. The 3.3 release notes only state that USB support has been improved. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Thu Dec 2 11: 0:18 1999 Delivered-To: freebsd-stable@freebsd.org Received: from trooper.velocet.net (trooper.velocet.net [216.126.82.226]) by hub.freebsd.org (Postfix) with ESMTP id E93C614CE5 for ; Thu, 2 Dec 1999 11:00:13 -0800 (PST) (envelope-from dgilbert@trooper.velocet.net) Received: (from dgilbert@localhost) by trooper.velocet.net (8.9.3/8.9.3) id NAA50369; Thu, 2 Dec 1999 13:59:18 -0500 (EST) (envelope-from dgilbert) From: David Gilbert MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14406.49542.335305.256245@trooper.velocet.net> Date: Thu, 2 Dec 1999 13:59:18 -0500 (EST) To: freebsd-stable@freebsd.org Subject: kernel not patching? X-Mailer: VM 6.75 under 20.4 "Emerald" XEmacs Lucid Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG OK... in my ongoing strange saga, I added char *dgilbert_bre5_top = "dgilbert_bre5_top"; as a global variable in vinumraid5.c --- I'm doing this as part of a strategy to track down a memory (stack) corruption bug. Anyways... when I recompile the kernel, it compiles this one module... and this global variable is referenced. When I then search for this string (by lessing the kernel and searching for dgilbert), I can't find it in the kernel's image. What's up? Dave. -- ============================================================================ |David Gilbert, Velocet Communications. | Two things can only be | |Mail: dgilbert@velocet.net | equal if and only if they | |http://www.velocet.net/~dgilbert | are precisely opposite. | =========================================================GLO================ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Thu Dec 2 11: 8:13 1999 Delivered-To: freebsd-stable@freebsd.org Received: from misha.cisco.com (misha.cisco.com [171.69.206.50]) by hub.freebsd.org (Postfix) with ESMTP id 2FEA914D26 for ; Thu, 2 Dec 1999 11:08:11 -0800 (PST) (envelope-from mi@misha.cisco.com) Received: (from mi@localhost) by misha.cisco.com (8.9.3/8.9.1) id OAA82987; Thu, 2 Dec 1999 14:07:32 -0500 (EST) (envelope-from mi) Message-Id: <199912021907.OAA82987@misha.cisco.com> Subject: Re: kernel not patching? In-Reply-To: <14406.49542.335305.256245@trooper.velocet.net> from David Gilbert at "Dec 2, 1999 01:59:18 pm" To: David Gilbert Date: Thu, 2 Dec 1999 14:07:32 -0500 (EST) Cc: freebsd-stable@FreeBSD.ORG Reply-To: mi@aldan.algebra.com From: Mikhail Teterin X-Mailer: ELM [version 2.4ME+ PL60 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG David Gilbert once wrote: > char *dgilbert_bre5_top = "dgilbert_bre5_top"; > > as a global variable in vinumraid5.c --- I'm doing this as part of a > strategy to track down a memory (stack) corruption bug. > > Anyways... when I recompile the kernel, it compiles this one module... > and this global variable is referenced. When I then search for this > string (by lessing the kernel and searching for dgilbert), I can't > find it in the kernel's image. What's up? Well, if you use vinum module, the string will not be in kernel, but in /modules/vinum.ko :) -mi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Thu Dec 2 11:22:15 1999 Delivered-To: freebsd-stable@freebsd.org Received: from trooper.velocet.net (trooper.velocet.net [216.126.82.226]) by hub.freebsd.org (Postfix) with ESMTP id 4A27D14BFC for ; Thu, 2 Dec 1999 11:22:10 -0800 (PST) (envelope-from dgilbert@trooper.velocet.net) Received: (from dgilbert@localhost) by trooper.velocet.net (8.9.3/8.9.3) id OAA50864; Thu, 2 Dec 1999 14:20:25 -0500 (EST) (envelope-from dgilbert) From: David Gilbert MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14406.50809.85166.622558@trooper.velocet.net> Date: Thu, 2 Dec 1999 14:20:25 -0500 (EST) To: mi@aldan.algebra.com Cc: David Gilbert , freebsd-stable@FreeBSD.ORG Subject: Re: kernel not patching? In-Reply-To: <199912021907.OAA82987@misha.cisco.com> References: <14406.49542.335305.256245@trooper.velocet.net> <199912021907.OAA82987@misha.cisco.com> X-Mailer: VM 6.75 under 20.4 "Emerald" XEmacs Lucid Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >>>>> "Mikhail" == Mikhail Teterin writes: Mikhail> Well, if you use vinum module, the string will not be in Mikhail> kernel, but in /modules/vinum.ko :) I have 'options vinum' in the kernel ... and typing 'make' give: [2:20:320]root@raid1:/sys/compile/RAID> make cc -c -O -Wreturn-type -Wcomment -Wredundant-decls -Wimplicit -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wuninitialized -Wformat -Wunused -fformat-extensions -ansi -g -nostdinc -I- -I. -I../.. -I../../../include -DKERNEL -DVM_STACK -include opt_global.h -elf ../../dev/vinum/vinumraid5.c cc -c -O -Wreturn-type -Wcomment -Wredundant-decls -Wimplicit -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wuninitialized -Wformat -Wunused -fformat-extensions -ansi -g -nostdinc -I- -I. -I../.. -I../../../include -DKERNEL -DVM_STACK -include opt_global.h -elf setdef0.c cc -c -O -Wreturn-type -Wcomment -Wredundant-decls -Wimplicit -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wuninitialized -Wformat -Wunused -fformat-extensions -ansi -g -nostdinc -I- -I. -I../.. -I../../../include -DKERNEL -DVM_STACK -include opt_global.h -elf setdef1.c sh ../../conf/newvers.sh RAID cc -c -O -Wreturn-type -Wcomment -Wredundant-decls -Wimplicit -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wuninitialized -Wformat -Wunused -fformat-extensions -ansi -g -nostdinc -I- -I. -I../.. -I../../../include -DKERNEL -DVM_STACK -include opt_global.h -elf vers.c loading kernel Dave. -- ============================================================================ |David Gilbert, Velocet Communications. | Two things can only be | |Mail: dgilbert@velocet.net | equal if and only if they | |http://www.velocet.net/~dgilbert | are precisely opposite. | =========================================================GLO================ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Thu Dec 2 11:38:33 1999 Delivered-To: freebsd-stable@freebsd.org Received: from jade.chc-chimes.com (jade.chc-chimes.com [216.28.46.6]) by hub.freebsd.org (Postfix) with ESMTP id D1F5C14E39 for ; Thu, 2 Dec 1999 11:38:31 -0800 (PST) (envelope-from billf@chc-chimes.com) Received: by jade.chc-chimes.com (Postfix, from userid 1001) id 781591C57; Thu, 2 Dec 1999 13:39:29 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by jade.chc-chimes.com (Postfix) with ESMTP id 74817381B; Thu, 2 Dec 1999 13:39:29 -0500 (EST) Date: Thu, 2 Dec 1999 13:39:29 -0500 (EST) From: Bill Fumerola To: David Gilbert Cc: mi@aldan.algebra.com, freebsd-stable@FreeBSD.ORG Subject: Re: kernel not patching? In-Reply-To: <14406.50809.85166.622558@trooper.velocet.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 2 Dec 1999, David Gilbert wrote: > I have 'options vinum' in the kernel ... and typing 'make' give: pseudo-device vinum #Vinum concat/mirror/raid driver -- - bill fumerola - billf@chc-chimes.com - BF1560 - computer horizons corp - - ph:(800) 252-2421 - bfumerol@computerhorizons.com - billf@FreeBSD.org - To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Thu Dec 2 12:30:19 1999 Delivered-To: freebsd-stable@freebsd.org Received: from alcanet.com.au (border.alcanet.com.au [203.62.196.10]) by hub.freebsd.org (Postfix) with ESMTP id 09DEC14EC7 for ; Thu, 2 Dec 1999 12:30:10 -0800 (PST) (envelope-from jeremyp@gsmx07.alcatel.com.au) Received: by border.alcanet.com.au id <40324>; Fri, 3 Dec 1999 07:20:37 +1100 Content-return: prohibited Date: Fri, 3 Dec 1999 07:28:03 +1100 From: Peter Jeremy Subject: Re: kernel not patching? In-reply-to: <14406.50809.85166.622558@trooper.velocet.net> To: David Gilbert Cc: freebsd-stable@FreeBSD.ORG Reply-To: peter.jeremy@alcatel.com.au Message-Id: <99Dec3.072037est.40324@border.alcanet.com.au> MIME-version: 1.0 X-Mailer: Mutt 1.0pre3i Content-type: text/plain; charset=us-ascii References: <14406.49542.335305.256245@trooper.velocet.net> <199912021907.OAA82987@misha.cisco.com> <14406.50809.85166.622558@trooper.velocet.net> Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 1999-Dec-03 06:20:25 +1100, David Gilbert wrote: >I have 'options vinum' in the kernel ... and typing 'make' give: I presume you read the warning in LINT: # Configuring Vinum into the kernel is not necessary, since the kld # module gets started automatically when vinum(8) starts. This # device is also untested. Use at your own risk. Maybe you should switch to using vinum as a KLD and see if your problem goes away. (BTW, auto char *foo = "foo"; means that the stack contains a pointer to a string foo. The string will be in static storage - ie to find the stack, you need to work out the KVA for "foo" and then search for this address). Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Thu Dec 2 12:34: 6 1999 Delivered-To: freebsd-stable@freebsd.org Received: from trooper.velocet.net (trooper.velocet.net [216.126.82.226]) by hub.freebsd.org (Postfix) with ESMTP id 420D214EC7 for ; Thu, 2 Dec 1999 12:33:54 -0800 (PST) (envelope-from dgilbert@trooper.velocet.net) Received: (from dgilbert@localhost) by trooper.velocet.net (8.9.3/8.9.3) id PAA52413; Thu, 2 Dec 1999 15:32:53 -0500 (EST) (envelope-from dgilbert) From: David Gilbert MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14406.55156.963240.177647@trooper.velocet.net> Date: Thu, 2 Dec 1999 15:32:52 -0500 (EST) To: peter.jeremy@alcatel.com.au Cc: David Gilbert , freebsd-stable@FreeBSD.ORG Subject: Re: kernel not patching? In-Reply-To: <99Dec3.072037est.40324@border.alcanet.com.au> References: <14406.49542.335305.256245@trooper.velocet.net> <199912021907.OAA82987@misha.cisco.com> <14406.50809.85166.622558@trooper.velocet.net> <99Dec3.072037est.40324@border.alcanet.com.au> X-Mailer: VM 6.75 under 20.4 "Emerald" XEmacs Lucid Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >>>>> "Peter" == Peter Jeremy writes: Peter> (BTW, auto char *foo = "foo"; means that the stack contains a Peter> pointer to a string foo. The string will be in static storage Peter> - ie to find the stack, you need to work out the KVA for "foo" Peter> and then search for this address). Mmm.... knew that. May not have hacked kernel too much, but I have a fair grasp of C uglyness. the char *foo was put in as a global to check the value of the char foo[]="foostring" that I put into the functions. Now... this is not strictly C-legal, but with gcc, it will autosize foo[] and copy "foostring" into it. The cool thing is that sizeof(foo) == strlen(foo)+1. Dave. -- ============================================================================ |David Gilbert, Velocet Communications. | Two things can only be | |Mail: dgilbert@velocet.net | equal if and only if they | |http://www.velocet.net/~dgilbert | are precisely opposite. | =========================================================GLO================ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Thu Dec 2 14: 5:48 1999 Delivered-To: freebsd-stable@freebsd.org Received: from mass.cdrom.com (mass.cdrom.com [204.216.28.184]) by hub.freebsd.org (Postfix) with ESMTP id 5559C14F54 for ; Thu, 2 Dec 1999 14:05:43 -0800 (PST) (envelope-from msmith@mass.cdrom.com) Received: from mass.cdrom.com (localhost [127.0.0.1]) by mass.cdrom.com (8.9.3/8.9.3) with ESMTP id OAA00583; Thu, 2 Dec 1999 14:06:01 -0800 (PST) (envelope-from msmith@mass.cdrom.com) Message-Id: <199912022206.OAA00583@mass.cdrom.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: David Gilbert Cc: freebsd-stable@freebsd.org Subject: Re: kernel not patching? In-reply-to: Your message of "Thu, 02 Dec 1999 13:59:18 EST." <14406.49542.335305.256245@trooper.velocet.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 02 Dec 1999 14:06:01 -0800 From: Mike Smith Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > OK... in my ongoing strange saga, I added > > char *dgilbert_bre5_top = "dgilbert_bre5_top"; > > as a global variable in vinumraid5.c --- I'm doing this as part of a > strategy to track down a memory (stack) corruption bug. > > Anyways... when I recompile the kernel, it compiles this one > module... and this global variable is referenced. When I then search > for this string (by lessing the kernel and searching for dgilbert), I > can't find it in the kernel's image. What's up? Module != kernel -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ msmith@freebsd.org \\ and he'll hate you for a lifetime. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Thu Dec 2 14:26:34 1999 Delivered-To: freebsd-stable@freebsd.org Received: from zippy.cdrom.com (zippy.cdrom.com [204.216.27.228]) by hub.freebsd.org (Postfix) with ESMTP id 40B1614BD7 for ; Thu, 2 Dec 1999 14:26:32 -0800 (PST) (envelope-from jkh@zippy.cdrom.com) Received: from zippy.cdrom.com (localhost [127.0.0.1]) by zippy.cdrom.com (8.9.3/8.9.3) with ESMTP id OAA13197; Thu, 2 Dec 1999 14:26:22 -0800 (PST) (envelope-from jkh@zippy.cdrom.com) To: Jim King Cc: freebsd-stable@FreeBSD.ORG Subject: Re: swap_pager: indefinite wait buffer? In-reply-to: Your message of "Thu, 02 Dec 1999 11:49:19 CST." <4.2.0.58.19991202114512.00a47948@mail.sstar.com> Date: Thu, 02 Dec 1999 14:26:22 -0800 Message-ID: <13193.944173582@zippy.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I saw this question a lot in the archives. Would this be a good one for > the FAQ? Any question you see a lot in the archives is, by definition, good for a FAQ entry. :-) - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Thu Dec 2 15: 4:29 1999 Delivered-To: freebsd-stable@freebsd.org Received: from trooper.velocet.net (trooper.velocet.net [216.126.82.226]) by hub.freebsd.org (Postfix) with ESMTP id D8C5214C5A for ; Thu, 2 Dec 1999 15:04:25 -0800 (PST) (envelope-from dgilbert@trooper.velocet.net) Received: (from dgilbert@localhost) by trooper.velocet.net (8.9.3/8.9.3) id SAA57340; Thu, 2 Dec 1999 18:04:20 -0500 (EST) (envelope-from dgilbert) From: David Gilbert MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14406.64244.148532.144009@trooper.velocet.net> Date: Thu, 2 Dec 1999 18:04:20 -0500 (EST) To: stable@freebsd.org Subject: wierd SCSI error prevents dump? X-Mailer: VM 6.75 under 20.4 "Emerald" XEmacs Lucid Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I'm getting the following error after a panic... it appears to be preventing the system from dumping. Is there anything I can do to help this? syncing disks... Timedout SCB handled by another timeout Timedout SCB handled by another timeout Dave. -- ============================================================================ |David Gilbert, Velocet Communications. | Two things can only be | |Mail: dgilbert@velocet.net | equal if and only if they | |http://www.velocet.net/~dgilbert | are precisely opposite. | =========================================================GLO================ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Thu Dec 2 16: 4:37 1999 Delivered-To: freebsd-stable@freebsd.org Received: from mail.rdc1.tn.home.com (ha1.rdc1.tn.home.com [24.2.7.66]) by hub.freebsd.org (Postfix) with ESMTP id 5149614CCD for ; Thu, 2 Dec 1999 16:04:31 -0800 (PST) (envelope-from williamsl@Home.Com) Received: from RELIABLE ([24.4.115.31]) by mail.rdc1.tn.home.com (InterMail v4.01.01.00 201-229-111) with ESMTP id <19991203000356.TDBC7535.mail.rdc1.tn.home.com@RELIABLE> for ; Thu, 2 Dec 1999 16:03:56 -0800 Date: Thu, 2 Dec 1999 19:01:52 -0500 From: Ben WIlliams X-Mailer: The Bat! (v1.34a) UNREG / CD5BF9353B3B7091 Reply-To: Ben WIlliams X-Priority: 3 (Normal) Message-ID: <17792.991202@Home.Com> To: freebsd-stable@freebsd.org Subject: kernel compile succeeds but is unusable, take two X-Sender: Ben WIlliams Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG It was suggested to me that I should post my config file along with the exact commands I issue to build my kernel so here they are. In /usr/src/sys/i386/conf the file DELTA_9: # # GENERIC -- Generic machine with WD/AHx/NCR/BTx family disks # # For more information read the handbook part System Administration -> # Configuring the FreeBSD Kernel -> The Configuration File. # The handbook is available in /usr/share/doc/handbook or online as # latest version from the FreeBSD World Wide Web server # # # An exhaustive list of options and more detailed explanations of the # device lines is present in the ./LINT configuration file. If you are # in doubt as to the purpose or necessity of a line, check first in LINT. # # $Id: GENERIC,v 1.143.2.12 1999/05/14 15:12:26 jkh Exp $ machine "i386" cpu "I586_CPU" ident "DELTA_9" maxusers 32 options MATH_EMULATE #Support for x87 emulation options INET #InterNETworking options FFS #Berkeley Fast Filesystem options FFS_ROOT #FFS usable as root device [keep this!] # options NFS #Network Filesystem # options MSDOSFS #MSDOS Filesystem # options "CD9660" #ISO 9660 Filesystem options PROCFS #Process filesystem options "COMPAT_43" #Compatible with BSD 4.3 [KEEP THIS!] options UCONSOLE #Allow users to grab the console options FAILSAFE #Be conservative options USERCONFIG #boot -c editor options VISUAL_USERCONFIG #visual boot -c editor config kernel root on wd0 controller isa0 controller pnp0 controller eisa0 controller pci0 controller fdc0 at isa? port "IO_FD1" bio irq 6 drq 2 disk fd0 at fdc0 drive 0 # disk fd1 at fdc0 drive 1 controller wdc0 at isa? port "IO_WD1" bio irq 14 disk wd0 at wdc0 drive 0 flags 0xb0ff disk wd1 at wdc0 drive 1 flags 0xb0ff controller wdc1 at isa? port "IO_WD2" bio irq 15 disk wd2 at wdc1 drive 0 disk wd3 at wdc1 drive 1 options ATAPI #Enable ATAPI support for IDE bus options ATAPI_STATIC #Don't do it as an LKM device acd0 #IDE CD-ROM # device wfd0 #IDE Floppy (e.g. LS-120) # atkbdc0 controlls both the keyboard and the PS/2 mouse controller atkbdc0 at isa? port IO_KBD tty device atkbd0 at isa? tty irq 1 device vga0 at isa? port ? conflicts # splash screen/screen saver pseudo-device splash # syscons is the default console driver, resembling an SCO console device sc0 at isa? tty # Enable this and PCVT_FREEBSD for pcvt vt220 compatible console driver device vt0 at isa? tty #options XSERVER # support for X server #options FAT_CURSOR # start with block cursor # If you have a ThinkPAD, uncomment this along with the rest of the PCVT lines #options PCVT_SCANSET=2 # IBM keyboards are non-std # device npx0 at isa? port IO_NPX irq 13 device npx0 at isa? port IO_NPX device sio0 at isa? port "IO_COM1" flags 0x10 tty irq 4 device sio1 at isa? port "IO_COM2" tty irq 3 # device sio2 at isa? disable port "IO_COM3" tty irq 5 # device sio3 at isa? disable port "IO_COM4" tty irq 9 # Parallel port #device ppc0 at isa? port? flags 0x40 net irq 7 #controller ppbus0 #device lpt0 at ppbus? # device plip0 at ppbus? # device ppi0 at ppbus? #controller vpo0 at ppbus? # # The following Ethernet NICs are all PCI devices. # device pn0 # Lite-On 82c168/82c169 (``PNIC'') device pn1 # second "Lite-On" ''PNIC'' pseudo-device loop pseudo-device ether # pseudo-device sl 1 # pseudo-device ppp 1 # pseudo-device tun 1 # pseudo-device pty 16 # pseudo-device gzip # Exec gzipped a.out's # KTRACE enables the system-call tracing facility ktrace(2). # This adds 4 KB bloat to your kernel, and slightly increases # the costs of each syscall. options KTRACE #kernel tracing # This provides support for System V shared memory and message queues. # options SYSVSHM options SYSVMSG options SYSVSEM # The `bpfilter' pseudo-device enables the Berkeley Packet Filter. Be # aware of the legal and administrative consequences of enabling this # option. The number of devices determines the maximum number of # simultaneous BPF clients programs runnable. pseudo-device bpfilter 4 #Berkeley packet filter # Doesn't seem to make any difference if this is here or not, it still crashes. # options SOFTUPDATES And the commands: $ su - Password: delta# bash bash-2.03# cd /usr/src/sys/i386/conf bash-2.03# /usr/sbin/config -r DELTA_9 Removing old directory ../../compile/DELTA_9: Done. Don't forget to do a ``make depend'' Kernel build directory is ../../compile/DELTA_9 bash-2.03# cd ../../compile/DELTA_9 bash-2.03# make depend [ whole buncha make output cut ] rm -f .depend mv -f .newdep .depend bash-2.03# make [ whole buncha make output cut ] loading kernel text data bss dec hex filename 905521 83556 131496 1120573 11193d kernel bash-2.03# make install chflags noschg /kernel mv /kernel /kernel.old PATH=${PATH}:/sbin:/usr/sbin; if [ `sysctl -n kern.bootfile` = /kernel ] ; then sysctl -w kern.bootfile=/kernel.old ; if [ -f /var/db/kvm_kernel.db ] ; then mv -f /var/db/kvm_kernel.db /var/db/kvm_kernel.old.db ; fi fi install -c -m 555 -o root -g wheel -fschg kernel / bash-2.03# reboot [ yadda yadda yadda ] // something about npx0 being found on the mb // something about npx0 being an INT 16 device Help! -- Ben mailto:williamsl@Home.Com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Thu Dec 2 16:13: 4 1999 Delivered-To: freebsd-stable@freebsd.org Received: from mass.cdrom.com (mass.cdrom.com [204.216.28.184]) by hub.freebsd.org (Postfix) with ESMTP id 980DF14D7E for ; Thu, 2 Dec 1999 16:13:02 -0800 (PST) (envelope-from msmith@mass.cdrom.com) Received: from mass.cdrom.com (localhost [127.0.0.1]) by mass.cdrom.com (8.9.3/8.9.3) with ESMTP id QAA01853; Thu, 2 Dec 1999 16:14:26 -0800 (PST) (envelope-from msmith@mass.cdrom.com) Message-Id: <199912030014.QAA01853@mass.cdrom.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Ben WIlliams Cc: freebsd-stable@freebsd.org Subject: Re: kernel compile succeeds but is unusable, take two In-reply-to: Your message of "Thu, 02 Dec 1999 19:01:52 EST." <17792.991202@Home.Com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 02 Dec 1999 16:14:26 -0800 From: Mike Smith Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > It was suggested to me that I should post my config file along with > the exact commands I issue to build my kernel so here they are. > # device npx0 at isa? port IO_NPX irq 13 > device npx0 at isa? port IO_NPX Why did you do this? You MUST NOT dink with this line. > # pseudo-device pty 16 Taking pty's out is a bad idea too. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ msmith@freebsd.org \\ and he'll hate you for a lifetime. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Thu Dec 2 16:13:11 1999 Delivered-To: freebsd-stable@freebsd.org Received: from jade.chc-chimes.com (jade.chc-chimes.com [216.28.46.6]) by hub.freebsd.org (Postfix) with ESMTP id 6045B14D80 for ; Thu, 2 Dec 1999 16:13:08 -0800 (PST) (envelope-from billf@chc-chimes.com) Received: by jade.chc-chimes.com (Postfix, from userid 1001) id C7B761C58; Thu, 2 Dec 1999 18:13:57 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by jade.chc-chimes.com (Postfix) with ESMTP id C2F32381B; Thu, 2 Dec 1999 18:13:57 -0500 (EST) Date: Thu, 2 Dec 1999 18:13:57 -0500 (EST) From: Bill Fumerola To: Ben WIlliams Cc: freebsd-stable@freebsd.org Subject: Re: kernel compile succeeds but is unusable, take two In-Reply-To: <17792.991202@Home.Com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 2 Dec 1999, Ben WIlliams wrote: > # device npx0 at isa? port IO_NPX irq 13 > device npx0 at isa? port IO_NPX Why did you change this? > # The following Ethernet NICs are all PCI devices. > # > device pn0 # Lite-On 82c168/82c169 (``PNIC'') > device pn1 # second "Lite-On" ''PNIC'' Not needed, the code will make more as it needs them. > pseudo-device loop > pseudo-device ether > # pseudo-device sl 1 > # pseudo-device ppp 1 > # pseudo-device tun 1 > # pseudo-device pty 16 You didn't want to comment 'pty' out. > [ yadda yadda yadda ] > // something about npx0 being found on the mb > // something about npx0 being an INT 16 device > I would have looked at the npx0 device that you changed, and then reverted the change. That's just the logical approach though. -- - bill fumerola - billf@chc-chimes.com - BF1560 - computer horizons corp - - ph:(800) 252-2421 - bfumerol@computerhorizons.com - billf@FreeBSD.org - To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Thu Dec 2 18:46:43 1999 Delivered-To: freebsd-stable@freebsd.org Received: from mail.rdc1.tn.home.com (ha1.rdc1.tn.home.com [24.2.7.66]) by hub.freebsd.org (Postfix) with ESMTP id E217814DAE for ; Thu, 2 Dec 1999 18:46:36 -0800 (PST) (envelope-from williamsl@Home.Com) Received: from RELIABLE ([24.4.115.31]) by mail.rdc1.tn.home.com (InterMail v4.01.01.00 201-229-111) with ESMTP id <19991203024617.VZNW7535.mail.rdc1.tn.home.com@RELIABLE> for ; Thu, 2 Dec 1999 18:46:17 -0800 Date: Thu, 2 Dec 1999 21:44:14 -0500 From: Ben WIlliams X-Mailer: The Bat! (v1.34a) UNREG / CD5BF9353B3B7091 Reply-To: Ben WIlliams X-Priority: 3 (Normal) Message-ID: <4905.991202@Home.Com> To: freebsd-stable@FreeBSD.ORG Subject: Re[2]: kernel compile succeeds but is unusable, take two In-reply-To: <199912030014.QAA01853@mass.cdrom.com> References: <199912030014.QAA01853@mass.cdrom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hello Mike, Thursday, December 02, 1999, 19:14:26 noAuth, you wrote: >> It was suggested to me that I should post my config file along with >> the exact commands I issue to build my kernel so here they are. >> # device npx0 at isa? port IO_NPX irq 13 >> device npx0 at isa? port IO_NPX MS> Why did you do this? You MUST NOT dink with this line. >> # pseudo-device pty 16 MS> Taking pty's out is a bad idea too. I changed with that line because that's the last thing that shows during a boot of a new kernel and I figured that it must be misallocating or misreading something to do with the npx. dmesg contains: npx0 on motherboard npx0: INT 16 interface ...why is IRQ set to 13 on the npx0 line? Maybe I should change the 13 to a 16? (Or actually a 15 .. IIRC IRQ's go from 0-15 or 0x0-0xf.) The next thing that happens when booting with the GENERIC kernel is it installs the pentium f00f hack. I put the pty's back in and reverted the npx line to the original way it was and I'm building the kernel again now. I got a different Instruction Pointer at the crash which translates to: bash-2.03$ nm /kernel | grep -i "c019d4" c019d418 T cninit_finish c019d474 t cnuninit c019d4cc t sysctl_kern_consmute bash-2.03$ In order to build this kernel I edited the DELTA_9 file: Changed ident to "DELTA_9.1" Reverted the npx0 line to its original form Removed the line for pn1 Uncommented the pty line More help please! I don't understand why this machine is being recalcitrant about compiling the kernel. I've compiled kernels on my AMD K6/350 and a P][/233 without any of this kind of trouble. What have I done? -- Ben mailto:williamsl@Home.Com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Thu Dec 2 18:48:33 1999 Delivered-To: freebsd-stable@freebsd.org Received: from sand2.sentex.ca (sand2.sentex.ca [209.167.248.3]) by hub.freebsd.org (Postfix) with ESMTP id 040B914F16 for ; Thu, 2 Dec 1999 18:48:30 -0800 (PST) (envelope-from mike@sentex.net) Received: from gravel (ospf-mdt.sentex.net [205.211.164.81]) by sand2.sentex.ca (8.8.8/8.8.8) with SMTP id VAA25572 for ; Thu, 2 Dec 1999 21:48:55 -0500 (EST) (envelope-from mike@sentex.net) Message-Id: <4.1.19991202214739.044dc100@granite.sentex.ca> X-Sender: mdtancsa@granite.sentex.ca X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Thu, 02 Dec 1999 21:48:18 -0500 To: freebsd-stable@freebsd.org From: Mike Tancsa Subject: Denial of Service attacks Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Has there been any change of status on these two DoSes ? http://www.securityfocus.com/vdb/bottom.html?vid=622 http://www.securityfocus.com/vdb/bottom.html?vid=526 They are the setsockopt() and mmap DoSes... There was talk of the mmap being patched up in Current, but I havent seen anything. Bugtraq still lists all versions of FreeBSD vulnerable. ---Mike ********************************************************************** Mike Tancsa * mike@sentex.net Sentex Communications Corp, * http://www.sentex.net/mike Cambridge, Ontario * 519 651 3400 Canada * To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Fri Dec 3 2: 4:19 1999 Delivered-To: freebsd-stable@freebsd.org Received: from ramstind.gtf.ol.no (ramstind.gtf.ol.no [128.39.174.16]) by hub.freebsd.org (Postfix) with ESMTP id 6F6B1150A3 for ; Fri, 3 Dec 1999 02:04:11 -0800 (PST) (envelope-from trond@ramstind.gtf.ol.no) Received: from localhost (trond@localhost) by ramstind.gtf.ol.no (8.9.3/8.9.3) with ESMTP id LAA03531; Fri, 3 Dec 1999 11:02:32 +0100 (CET) (envelope-from trond@ramstind.gtf.ol.no) Date: Fri, 3 Dec 1999 11:02:32 +0100 (CET) From: Trond Endrestol To: Ben WIlliams Cc: freebsd-stable@FreeBSD.ORG Subject: Re: kernel compile succeeds but is unusable, take two In-Reply-To: <4905.991202@Home.Com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I noticed in your kernel config file that you have enabled both syscons and the vt220 emulation. Could this be causing your problems? Perhaps you should comment out the device vt0 at isa? port "IO_KBD" tty irq 1 vector pcrint line? ---------------------------------------------------------------------- Trond Endrestøl | trond@gtf.ol.no Merkantilvegen 59HB7, | trond@ramstind.gtf.ol.no N-2815 GJØVIK, NORWAY |+47 61139424 || +47 63874242 Patron of The Art of Computer Programming| FreeBSD 3.3 & Pine 4.10 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Fri Dec 3 3:30:13 1999 Delivered-To: freebsd-stable@freebsd.org Received: from mail.rdc1.tn.home.com (ha1.rdc1.tn.home.com [24.2.7.66]) by hub.freebsd.org (Postfix) with ESMTP id 34BF114F1F for ; Fri, 3 Dec 1999 03:30:10 -0800 (PST) (envelope-from williamsl@Home.Com) Received: from RELIABLE ([24.4.115.31]) by mail.rdc1.tn.home.com (InterMail v4.01.01.00 201-229-111) with ESMTP id <19991203112852.CHJG7535.mail.rdc1.tn.home.com@RELIABLE> for ; Fri, 3 Dec 1999 03:28:52 -0800 Date: Fri, 3 Dec 1999 06:26:47 -0500 From: Ben WIlliams X-Mailer: The Bat! (v1.34a) UNREG / CD5BF9353B3B7091 Reply-To: Ben WIlliams X-Priority: 3 (Normal) Message-ID: <0268.991203@Home.Com> To: freebsd-stable@FreeBSD.ORG Subject: Re[2]: kernel compile succeeds but is unusable, take two In-reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Friday, December 03, 1999 I just finished re-getting /usr/src/sys from freebsd2 and removing the "device vt0..." line and the compiled kernel BOOTED! I want to say a warm and deep Thank You for all their help to: Trond Endrestol Mike Smith Bill Fumerola John Reynolds~ Geff Hanoian Among them they answered all my questions and even some I didn't think to ask! Thanks a lot guys. -- Ben Williams. Friday, December 03, 1999, 5:02:32 AM, you wrote: TE> I noticed in your kernel config file that you have enabled both TE> syscons and the vt220 emulation. Could this be causing your problems? TE> Perhaps you should comment out the TE> device vt0 at isa? port "IO_KBD" tty irq 1 vector pcrint TE> line? TE> ---------------------------------------------------------------------- TE> Trond Endrestøl | trond@gtf.ol.no TE> Merkantilvegen 59HB7, | trond@ramstind.gtf.ol.no TE> N-2815 GJØVIK, NORWAY |+47 61139424 || +47 63874242 TE> Patron of The Art of Computer Programming| FreeBSD 3.3 & Pine 4.10 TE> To Unsubscribe: send mail to majordomo@FreeBSD.org TE> with "unsubscribe freebsd-stable" in the body of the message -- Ben mailto:williamsl@Home.Com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Fri Dec 3 5:55:36 1999 Delivered-To: freebsd-stable@freebsd.org Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by hub.freebsd.org (Postfix) with ESMTP id B41A514CA1 for ; Fri, 3 Dec 1999 05:55:21 -0800 (PST) (envelope-from usenet@erix.ericsson.se) Received: from super.du.uab.ericsson.se (root@super.du.uab.ericsson.se [134.138.176.16]) by penguin.wise.edt.ericsson.se (8.9.3/8.9.3/WIREfire-1.5) with ESMTP id OAA17325 for ; Fri, 3 Dec 1999 14:54:31 +0100 (MET) Received: from news.du.uab.ericsson.se (news [134.138.176.24]) by super.du.uab.ericsson.se (8.9.3/8.9.3/erix-1.7) with ESMTP id OAA21485 for ; Fri, 3 Dec 1999 14:54:30 +0100 (MET) Received: (from news@localhost) by news.du.uab.ericsson.se (8.9.1b+Sun/8.9.1/news-1.1) id OAA06759 for freebsd-stable@freebsd.org; Fri, 3 Dec 1999 14:54:29 +0100 (MET) Received: from GATEWAY by news with netnews for freebsd-stable@freebsd.org (freebsd-stable@freebsd.org) To: freebsd-stable@freebsd.org Date: 03 Dec 1999 14:54:28 +0100 From: Kent Boortz Message-ID: Organization: Ericsson Telecom AB, Stockholm, Sweden Content-Type: text/plain; charset=us-ascii Subject: Out of swap hangs machine Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Maybe I'm a bit confused about the expected bahaviour but I was under the impression that running a program as an ordinary user is not supposed to make an Unix system unusable. That is what makes a big difference between Unix and operating systems like Windows98 or MacOS. I have had several crashes where I can't access my machine console, i.e. X-Windows has hung, I can't terminate X with ctrl-alt-backspace and I can't switch console with ctlr-alt-F1. The cause has been running an ordinary program, ImageMagick, with a rather large file reaching the swap space limit. In my /var/log/messages I can see Dec 1 01:48:48 lolo /kernel: swap_pager: out of swap space Dec 1 01:48:49 lolo /kernel: pid 34092 (montage), uid 825, was killed: out of swap space Dec 1 01:59:23 lolo /kernel: swap_pager: out of swap space Dec 1 02:00:27 lolo /kernel: pid 34113 (montage), uid 825, was killed: out of swap space Dec 1 02:00:29 lolo last message repeated 3 times Dec 1 02:07:27 lolo /kernel: swap_pager: out of swap space At this stage the machine is unusable and I had to reboot with the hardware switch, no more log entries. Dec 1 04:53:01 lolo /kernel: swap_pager: I/O error - pagein failed; blkno 856138, size 4096, error 22 Dec 1 04:53:01 lolo /kernel: vm_fault: pager read error, pid 544 (convert) I had to use the hardware switch this time as well, nothing more in the log. I run FreeBSD 3.3-STABLE #2 (cvsup 22 Nov) Could someone clearify this matter? Is it my setup that allow ordinary users too much freedom or is this a problem with FreeBSD? kent To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Fri Dec 3 7:16:47 1999 Delivered-To: freebsd-stable@freebsd.org Received: from melete.ch.intel.com (melete.ch.intel.com [143.182.246.25]) by hub.freebsd.org (Postfix) with ESMTP id 3220314BD0 for ; Fri, 3 Dec 1999 07:16:41 -0800 (PST) (envelope-from jreynold@sedona.ch.intel.com) Received: from sedona.intel.com (sedona.ch.intel.com [143.182.218.21]) by melete.ch.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.11 1999/11/10 17:27:15 spurcell Exp $) with ESMTP id PAA11006; Fri, 3 Dec 1999 15:16:00 GMT Received: from hip186.ch.intel.com (hip186.ch.intel.com [143.182.225.68]) by sedona.intel.com (8.9.1a/8.9.1/d: sendmail.cf,v 1.8 1999/04/16 15:25:49 steved Exp steved $) with ESMTP id IAA09253; Fri, 3 Dec 1999 08:16:30 -0700 (MST) X-Envelope-From: jreynold@sedona.ch.intel.com Received: (from jreynold@localhost) by hip186.ch.intel.com (8.9.1a/8.9.1/d: client.m4,v 1.3 1998/09/29 16:36:11 sedayao Exp sedayao $) id KAA11231; Fri, 3 Dec 1999 10:17:02 -0500 (EST) From: John Reynolds~ MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14407.57069.87434.611698@hip186.ch.intel.com> Date: Fri, 3 Dec 1999 08:17:01 -0700 (MST) To: Ben WIlliams Subject: Re: Re[2]: kernel compile succeeds but is unusable, take two In-Reply-To: <4905.991202@Home.Com> References: <199912030014.QAA01853@mass.cdrom.com> <4905.991202@Home.Com> X-Mailer: VM 6.75 under Emacs 19.34.1 Cc: stable@freebsd.org Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG [ On Thursday, December 2, Ben WIlliams wrote: ] > > More help please! I don't understand why this machine is being > recalcitrant about compiling the kernel. I've compiled kernels on my > AMD K6/350 and a P][/233 without any of this kind of trouble. What > have I done? > Ok. Let's start with a baseline. Can you do the following (in the conf dir): cp /kernel.GENERIC /kernel.GENERIC.save config GENERIC cd ../../compile/GENERIC make depend && make && make install reboot and have the GENERIC kernel you just rebuilt come up and work? If so, I suggest taking that config file and just tweaking it to add support for the devices you need and taking slowly taking away things you don't need. -Jr -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= | John Reynolds CEG, CCE, Next Generation Flows, HLA | | Intel Corporation MS: CH6-210 Phone: 480-554-9092 pgr: 602-868-6512 | | jreynold@sedona.ch.intel.com http://www-aec.ch.intel.com/~jreynold/ | =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Fri Dec 3 7:51:57 1999 Delivered-To: freebsd-stable@freebsd.org Received: from midget.dons.net.au (daniel.lnk.telstra.net [139.130.137.70]) by hub.freebsd.org (Postfix) with ESMTP id 456A514BE4 for ; Fri, 3 Dec 1999 07:51:50 -0800 (PST) (envelope-from darius@dons.net.au) Received: from guppy.dons.net.au (guppy.dons.net.au [203.31.81.9]) by midget.dons.net.au (8.9.3/8.9.1) with ESMTP id AAA02724; Sat, 4 Dec 1999 00:49:10 +1030 (CST) (envelope-from darius@dons.net.au) Message-ID: X-Mailer: XFMail 1.3 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Sat, 04 Dec 1999 00:47:16 +1030 (CST) From: "Daniel J. O'Connor" To: Kent Boortz Subject: RE: Out of swap hangs machine Cc: freebsd-stable@freebsd.org Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 03-Dec-99 Kent Boortz wrote: > Could someone clearify this matter? Is it my setup that allow ordinary > users too much freedom or is this a problem with FreeBSD? How much swap did you give it? How much RAM do you have? It should be of the order of 2x your RAM.. --- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Fri Dec 3 7:59: 8 1999 Delivered-To: freebsd-stable@freebsd.org Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by hub.freebsd.org (Postfix) with ESMTP id D788F151F5 for ; Fri, 3 Dec 1999 07:58:58 -0800 (PST) (envelope-from kent@erix.ericsson.se) Received: from super.du.uab.ericsson.se (kent@super.du.uab.ericsson.se [134.138.176.16]) by penguin.wise.edt.ericsson.se (8.9.3/8.9.3/WIREfire-1.5) with ESMTP id QAA29572; Fri, 3 Dec 1999 16:58:52 +0100 (MET) Received: (from kent@localhost) by super.du.uab.ericsson.se (8.9.3/8.9.3/erix-1.7) id QAA26810; Fri, 3 Dec 1999 16:58:52 +0100 (MET) To: "Daniel J. O'Connor" Cc: freebsd-stable@freebsd.org Subject: Re: Out of swap hangs machine References: From: Kent Boortz Date: 03 Dec 1999 16:58:52 +0100 In-Reply-To: "Daniel J. O'Connor"'s message of "Sat, 04 Dec 1999 00:47:16 +1030 (CST)" Message-ID: Lines: 26 User-Agent: Gnus/5.070095 (Pterodactyl Gnus v0.95) Emacs/20.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG "Daniel J. O'Connor" writes: > On 03-Dec-99 Kent Boortz wrote: > > Could someone clearify this matter? Is it my setup that allow ordinary > > users too much freedom or is this a problem with FreeBSD? > > How much swap did you give it? > > How much RAM do you have? > > It should be of the order of 2x your RAM.. I have 128 Mb of real RAM and 256 Mb swap. I increased the swap to 517 Mb to be able to run ImageMagick on the files I had (added a swap file in the file system). Made the machine almost single tasking ;-) Freezed the mouse pointer in X for some time but worked ok. I will buy more RAM but was more curious about the philosophy behind these memory problems. I thought that the kernel reserved some memory to be able to handle the situation. Is an ordinary user taking up all RAM, swap and CPU supposed to make the console unresponsive? I have to admit I forgot to check if I could ping or log in to the machine from another machine, I only checked that the console was dead. I will do that next time. kent To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Fri Dec 3 10:25: 4 1999 Delivered-To: freebsd-stable@freebsd.org Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by hub.freebsd.org (Postfix) with ESMTP id 9F3F414F4F for ; Fri, 3 Dec 1999 10:25:03 -0800 (PST) (envelope-from randy@psg.com) Received: from randy by rip.psg.com with local (Exim 3.11 #1) id 11txMw-000ABx-00 for freebsd-stable@freebsd.org; Fri, 03 Dec 1999 10:23:46 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: FreeBSD Stable Subject: /usr/ports/net/ntp build problems Message-Id: Date: Fri, 03 Dec 1999 10:23:46 -0800 Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG on 3.3-stable as of yesterday, i can not build ntp. actually, this has been true for at least a week. clues? randy cc -DHAVE_CONFIG_H -I. -I. -I.. -I../include -O -pipe -Wall -Wshadow -Wwrite-strings -Wconversion -Wpointer-arith -Wcast-qual -Wstrict-prototypes -pipe -c ntp_refclock.c ntp_refclock.c: In function `refclock_gtlin': ntp_refclock.c:654: warning: passing arg 2 of `time_pps_fetch' makes integer from pointer without a cast ntp_refclock.c:654: too few arguments to function `time_pps_fetch' *** Error code 1 Stop. *** Error code 1 Stop. *** Error code 1 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Fri Dec 3 11:27:35 1999 Delivered-To: freebsd-stable@freebsd.org Received: from shell.webmaster.com (mail.webmaster.com [209.133.28.73]) by hub.freebsd.org (Postfix) with ESMTP id 22D2C14ED0 for ; Fri, 3 Dec 1999 11:27:33 -0800 (PST) (envelope-from davids@webmaster.com) Received: from whenever ([209.133.29.2]) by shell.webmaster.com (Post.Office MTA v3.5.3 release 223 ID# 0-12345L500S10000V35) with SMTP id com; Fri, 3 Dec 1999 11:26:35 -0800 From: "David Schwartz" To: "Randy Bush" , "FreeBSD Stable" Subject: RE: /usr/ports/net/ntp build problems Date: Fri, 3 Dec 1999 11:26:35 -0800 Message-ID: <000701bf3dc4$4fc2e400$021d85d1@youwant.to> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Importance: Normal Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG There was a HEADS-UP about this. The PPS API changed. If you have the latest version of NTP, you need to rerun 'configure'. DS > on 3.3-stable as of yesterday, i can not build ntp. actually, > this has been > true for at least a week. clues? > > randy > > > cc -DHAVE_CONFIG_H -I. -I. -I.. -I../include -O -pipe -Wall > -Wshadow -Wwrite-strings -Wconversion -Wpointer-arith -Wcast-qual > -Wstrict-prototypes -pipe -c ntp_refclock.c > ntp_refclock.c: In function `refclock_gtlin': > ntp_refclock.c:654: warning: passing arg 2 of `time_pps_fetch' > makes integer from pointer without a cast > ntp_refclock.c:654: too few arguments to function `time_pps_fetch' > *** Error code 1 > > Stop. > *** Error code 1 > > Stop. > *** Error code 1 > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-stable" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Fri Dec 3 12:14:54 1999 Delivered-To: freebsd-stable@freebsd.org Received: from alijku04.edvz.uni-linz.ac.at (alijku04.edvz.uni-linz.ac.at [140.78.182.1]) by hub.freebsd.org (Postfix) with ESMTP id 5934E14FF9 for ; Fri, 3 Dec 1999 12:14:49 -0800 (PST) (envelope-from ferdl@atommuell.oeh.uni-linz.ac.at) Received: from sondermuell.oeh.uni-linz.ac.at (sondermuell.oeh.uni-linz.ac.at [140.78.214.105]) by alijku04.edvz.uni-linz.ac.at (8.8.8/8.8.8) with ESMTP id VAA27954 for ; Fri, 3 Dec 1999 21:14:23 +0100 Received: from atommuell.oeh.uni-linz.ac.at (root@atommuell.oeh.uni-linz.ac.at [140.78.214.101]) by sondermuell.oeh.uni-linz.ac.at (8.9.3/8.9.3) with ESMTP id VAA01057 for ; Fri, 3 Dec 1999 21:12:31 +0100 Received: from localhost (ferdl@localhost) by atommuell.oeh.uni-linz.ac.at (8.9.3/8.9.3) with ESMTP id VAA87158 for ; Fri, 3 Dec 1999 21:14:38 +0100 (CET) (envelope-from ferdl@atommuell.oeh.uni-linz.ac.at) Date: Fri, 3 Dec 1999 21:14:38 +0100 (CET) From: Ferdinand Goldmann To: freebsd-stable@freebsd.org Subject: Re: Denial of Service attacks In-Reply-To: <4.1.19991202214739.044dc100@granite.sentex.ca> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 2 Dec 1999, Mike Tancsa wrote: > > Has there been any change of status on these two DoSes ? > > http://www.securityfocus.com/vdb/bottom.html?vid=622 This one just cold-booted my 3.3-RELEASE system. I currently have no newer systems here to test it out, but someone with 3.3-STABLE or 4.0-CURRENT please test this... ferdinand To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Fri Dec 3 12:21: 5 1999 Delivered-To: freebsd-stable@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id F2C6215252 for ; Fri, 3 Dec 1999 12:20:57 -0800 (PST) (envelope-from bright@wintelcom.net) Received: from localhost (bright@localhost) by fw.wintelcom.net (8.9.3/8.9.3) with ESMTP id MAA26486; Fri, 3 Dec 1999 12:47:32 -0800 (PST) Date: Fri, 3 Dec 1999 12:47:32 -0800 (PST) From: Alfred Perlstein To: Ferdinand Goldmann Cc: freebsd-stable@FreeBSD.ORG Subject: Re: Denial of Service attacks In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, 3 Dec 1999, Ferdinand Goldmann wrote: > On Thu, 2 Dec 1999, Mike Tancsa wrote: > > > > > Has there been any change of status on these two DoSes ? > > > > http://www.securityfocus.com/vdb/bottom.html?vid=622 > > This one just cold-booted my 3.3-RELEASE system. > > I currently have no newer systems here to test it out, but someone with > 3.3-STABLE or 4.0-CURRENT please test this... There are now login limits to mbuf allocation to catch idiot users, an alternate and more effective approach is 'rmuser'. -Alfred To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Fri Dec 3 12:33:16 1999 Delivered-To: freebsd-stable@freebsd.org Received: from alijku04.edvz.uni-linz.ac.at (alijku04.edvz.uni-linz.ac.at [140.78.182.1]) by hub.freebsd.org (Postfix) with ESMTP id 825AE14D57 for ; Fri, 3 Dec 1999 12:33:11 -0800 (PST) (envelope-from ferdl@atommuell.oeh.uni-linz.ac.at) Received: from sondermuell.oeh.uni-linz.ac.at (sondermuell.oeh.uni-linz.ac.at [140.78.214.105]) by alijku04.edvz.uni-linz.ac.at (8.8.8/8.8.8) with ESMTP id VAA29922; Fri, 3 Dec 1999 21:32:26 +0100 Received: from atommuell.oeh.uni-linz.ac.at (root@atommuell.oeh.uni-linz.ac.at [140.78.214.101]) by sondermuell.oeh.uni-linz.ac.at (8.9.3/8.9.3) with ESMTP id VAA01348; Fri, 3 Dec 1999 21:30:33 +0100 Received: from localhost (ferdl@localhost) by atommuell.oeh.uni-linz.ac.at (8.9.3/8.9.3) with ESMTP id VAA87297; Fri, 3 Dec 1999 21:32:40 +0100 (CET) (envelope-from ferdl@atommuell.oeh.uni-linz.ac.at) Date: Fri, 3 Dec 1999 21:32:40 +0100 (CET) From: Ferdinand Goldmann To: Alfred Perlstein Cc: freebsd-stable@FreeBSD.ORG Subject: Re: Denial of Service attacks In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, 3 Dec 1999, Alfred Perlstein wrote: > > I currently have no newer systems here to test it out, but someone with > > 3.3-STABLE or 4.0-CURRENT please test this... > > There are now login limits to mbuf allocation to catch idiot users, ^^^ > an alternate and more effective approach is 'rmuser'. Hmm.. Please define 'now'. I have just tried with the following resource limits: $ limits Resource limits (current): cputime infinity secs filesize 51200 kb datasize 49152 kb stacksize 16384 kb coredumpsize 10240 kb memoryuse 49152 kb memorylocked 32768 kb maxprocesses 64 openfiles 128 Still, it reboots.... ferdinand To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Fri Dec 3 12:35:50 1999 Delivered-To: freebsd-stable@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 5A2BB14C34 for ; Fri, 3 Dec 1999 12:35:47 -0800 (PST) (envelope-from bright@wintelcom.net) Received: from localhost (bright@localhost) by fw.wintelcom.net (8.9.3/8.9.3) with ESMTP id NAA26854; Fri, 3 Dec 1999 13:04:03 -0800 (PST) Date: Fri, 3 Dec 1999 13:04:03 -0800 (PST) From: Alfred Perlstein To: Ferdinand Goldmann Cc: freebsd-stable@FreeBSD.ORG Subject: Re: Denial of Service attacks In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, 3 Dec 1999, Ferdinand Goldmann wrote: > On Fri, 3 Dec 1999, Alfred Perlstein wrote: > > > > I currently have no newer systems here to test it out, but someone with > > > 3.3-STABLE or 4.0-CURRENT please test this... > > > > There are now login limits to mbuf allocation to catch idiot users, > ^^^ > > an alternate and more effective approach is 'rmuser'. > > Hmm.. Please define 'now'. I have just tried with the following resource > limits: > > $ limits > Resource limits (current): > cputime infinity secs > filesize 51200 kb > datasize 49152 kb > stacksize 16384 kb > coredumpsize 10240 kb > memoryuse 49152 kb > memorylocked 32768 kb > maxprocesses 64 > openfiles 128 > > Still, it reboots.... you need a 3.3-stable or 4.0-current box, the login paramter is 'sbsize' -Alfred To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Fri Dec 3 12:44:49 1999 Delivered-To: freebsd-stable@freebsd.org Received: from unicorn.blackhats.org (unicorn.blackhats.org [194.109.83.155]) by hub.freebsd.org (Postfix) with ESMTP id 99BE514C34 for ; Fri, 3 Dec 1999 12:44:41 -0800 (PST) (envelope-from unicorn@blackhats.org) Received: by unicorn.blackhats.org (Postfix, from userid 1002) id 52A1A12C2A; Fri, 3 Dec 1999 21:44:01 +0100 (CET) Date: Fri, 3 Dec 1999 21:44:01 +0100 From: The Unicorn To: freebsd-stable@freebsd.org Subject: SetAttrs src/contrib/diff/diff3.c,v Message-ID: <19991203214401.H33150@unicorn.blackhats.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre4i X-Files: The Truth Is Out There! Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi Guys (F/M), Just wondering why I see a *LOT* (as in one for each source file on the system) of SetAttrs messages coming over my screen, when I am cvsupping 3.3-STABLE on one system I own. While other systems act normally (loading delta's and other stuff)... Can anyone help me to return to the normal behaviour? aTdHvAaNnKcSe, Unicorn. -- ======= _ __,;;;/ TimeWaster ================================================ ,;( )_, )~\| A Truly Wise Man Never Plays PGP: 64 07 5D 4C 3F 81 22 73 ;; // `--; Leapfrog With A Unicorn... 52 9D 87 08 51 AA 35 F0 ==='= ;\ = | ==== Youth is Not a Time in Life, It is a State of Mind! ======= Echelon Teasers: NSA CIA FBI Mossad BVD MI5 Cocaine Cuba Revolution Espionage To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Fri Dec 3 13: 8:35 1999 Delivered-To: freebsd-stable@freebsd.org Received: from vinyl.sentex.ca (vinyl.sentex.ca [209.112.4.14]) by hub.freebsd.org (Postfix) with ESMTP id EC0BE14A0D for ; Fri, 3 Dec 1999 13:08:31 -0800 (PST) (envelope-from mike@sentex.net) Received: from granite.sentex.net (granite-atm.sentex.ca [209.112.4.1]) by vinyl.sentex.ca (8.9.3/8.9.3) with ESMTP id QAA55948; Fri, 3 Dec 1999 16:07:27 -0500 (EST) (envelope-from mike@sentex.net) Received: from simoeon (simeon.sentex.ca [209.112.4.47]) by granite.sentex.net (8.8.8/8.6.9) with SMTP id QAA16047; Fri, 3 Dec 1999 16:07:27 -0500 (EST) Message-Id: <3.0.5.32.19991203160626.01a658a0@staff.sentex.ca> X-Sender: mdtpop@staff.sentex.ca X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32) Date: Fri, 03 Dec 1999 16:06:26 -0500 To: Alfred Perlstein From: Mike Tancsa Subject: Re: Denial of Service attacks Cc: freebsd-stable@FreeBSD.ORG In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At 01:04 PM 12/3/99 -0800, Alfred Perlstein wrote: >you need a 3.3-stable or 4.0-current box, the login paramter is >'sbsize' Is this documented anywhere I dont see any reference to it in STABLE from today ? Also, the problem with rmuser for an ISP, is that its after the fact With 7,000 users, you have a potential for a lot of little kiddies trying out the latest scripts they got from IRC :-( ---Mike ------------------------------------------------------------------------ Mike Tancsa, tel +1 519 651 3400 Network Administrator, mike@sentex.net Sentex Communications www.sentex.net Cambridge, Ontario Canada To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Fri Dec 3 15:31:31 1999 Delivered-To: freebsd-stable@freebsd.org Received: from oracle.dsuper.net (oracle.dsuper.net [205.205.255.1]) by hub.freebsd.org (Postfix) with ESMTP id 31F6115366 for ; Fri, 3 Dec 1999 15:31:12 -0800 (PST) (envelope-from bmilekic@dsuper.net) Received: from oracle.dsuper.net (oracle.dsuper.net [205.205.255.1]) by oracle.dsuper.net (8.9.3/8.9.3) with ESMTP id SAA22824; Fri, 3 Dec 1999 18:31:06 -0500 (EST) Date: Fri, 3 Dec 1999 18:31:04 -0500 (EST) From: Bosko Milekic To: Mike Tancsa Cc: Alfred Perlstein , freebsd-stable@FreeBSD.ORG Subject: Re: Denial of Service attacks In-Reply-To: <3.0.5.32.19991203160626.01a658a0@staff.sentex.ca> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, 3 Dec 1999, Mike Tancsa wrote: !>At 01:04 PM 12/3/99 -0800, Alfred Perlstein wrote: !>>you need a 3.3-stable or 4.0-current box, the login paramter is !>>'sbsize' !> !> !>Is this documented anywhere I dont see any reference to it in STABLE from !>today ? Also, the problem with rmuser for an ISP, is that its after the !>fact With 7,000 users, you have a potential for a lot of little kiddies !>trying out the latest scripts they got from IRC :-( !> !> ---Mike Actually, as far as I can tell, this is only valid for -CURRENT. It was implemented originally by green (Brian F.). On another note, I have some code that would perhaps indirectly influence the behavior of the system in the mbuf shortage situation. But this issue has been beaten up so many times on this mailing list and failure to review (commit?) the code seems to be leading me to give up on this area of the tree. So, if you're interested, here's the present URL to the most recent patch on what I've done so far: http://pages.infinit.net/bmilekic/mbuf.patch Later, Bosko. -- Bosko Milekic To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Fri Dec 3 17:12:51 1999 Delivered-To: freebsd-stable@freebsd.org Received: from midget.dons.net.au (daniel.lnk.telstra.net [139.130.137.70]) by hub.freebsd.org (Postfix) with ESMTP id 615FF15334 for ; Fri, 3 Dec 1999 17:12:22 -0800 (PST) (envelope-from darius@dons.net.au) Received: from guppy.dons.net.au (guppy.dons.net.au [203.31.81.9]) by midget.dons.net.au (8.9.3/8.9.1) with ESMTP id LAA07004; Sat, 4 Dec 1999 11:41:23 +1030 (CST) (envelope-from darius@dons.net.au) Message-ID: X-Mailer: XFMail 1.3 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Sat, 04 Dec 1999 11:39:29 +1030 (CST) From: "Daniel J. O'Connor" To: Kent Boortz Subject: Re: Out of swap hangs machine Cc: freebsd-stable@freebsd.org Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 03-Dec-99 Kent Boortz wrote: > Freezed the mouse pointer in X for some time but worked ok. I will buy > more RAM but was more curious about the philosophy behind these memory > problems. I thought that the kernel reserved some memory to be able to > handle the situation. Is an ordinary user taking up all RAM, swap and Well 'the console' works, but login and getty are userland processes too, so they get swapped. The machine probably still responds to pings OK. --- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Fri Dec 3 17:36:49 1999 Delivered-To: freebsd-stable@freebsd.org Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by hub.freebsd.org (Postfix) with ESMTP id C11F014D7B for ; Fri, 3 Dec 1999 17:36:42 -0800 (PST) (envelope-from randy@psg.com) Received: from randy by rip.psg.com with local (Exim 3.11 #1) id 11u47t-000Dtj-00 for freebsd-stable@freebsd.org; Fri, 03 Dec 1999 17:36:41 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: FreeBSD Stable Subject: -stable of 99.12.2 hoistile to ntpd? Message-Id: Date: Fri, 03 Dec 1999 17:36:41 -0800 Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG built new -stable, running old ntpd 93a. now i get ... Dec 3 04:55:18 /kernel: cmd ntpd pid 303 tried to use non-present sched_get_priority_max Dec 3 04:55:18 /kernel: cmd ntpd pid 303 tried to use non-present sched_setscheduler Dec 3 04:55:18 ntpd[303]: sched_setscheduler(): Function not implemented Dec 3 05:02:56 ntpd[303]: kernel pll status change 2041 Dec 3 06:40:54 /kernel: cmd ntpd pid 303 tried to use non-present sched_get_priority_max Dec 3 06:40:54 /kernel: cmd ntpd pid 303 tried to use non-present sched_setscheduler Dec 3 06:40:54 ntpd[303]: sched_setscheduler(): Function not implemented Dec 3 06:48:41 ntpd[303]: kernel pll status change 2041 Dec 3 07:11:20 /kernel: pid 303 (ntpd), uid 0: exited on signal 8 (core dumped) and it is reproducable Dec 3 16:40:26 /kernel: cmd ntpd pid 37008 tried to use non-present sched_get_priority_max Dec 3 16:40:26 /kernel: cmd ntpd pid 37008 tried to use non-present sched_setscheduler Dec 3 16:40:26 ntpd[37008]: sched_setscheduler(): Function not implemented Dec 3 16:48:16 ntpd[37008]: kernel pll status change 2041 Dec 3 17:10:56 /kernel: pid 37008 (ntpd), uid 0: exited on signal 8 (core dumped) randy To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Sat Dec 4 4:58:12 1999 Delivered-To: freebsd-stable@freebsd.org Received: from sand2.sentex.ca (sand2.sentex.ca [209.167.248.3]) by hub.freebsd.org (Postfix) with ESMTP id B2DBB15021 for ; Sat, 4 Dec 1999 04:58:08 -0800 (PST) (envelope-from mike@sentex.net) Received: from gravel (ospf-mdt.sentex.net [205.211.164.81]) by sand2.sentex.ca (8.8.8/8.8.8) with SMTP id HAA26665; Sat, 4 Dec 1999 07:58:11 -0500 (EST) (envelope-from mike@sentex.net) Message-Id: <4.1.19991204075344.05480220@granite.sentex.ca> X-Sender: mdtancsa@granite.sentex.ca X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Sat, 04 Dec 1999 07:57:14 -0500 To: Bosko Milekic From: Mike Tancsa Subject: Re: Denial of Service attacks Cc: freebsd-stable@FreeBSD.ORG In-Reply-To: References: <3.0.5.32.19991203160626.01a658a0@staff.sentex.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At 06:31 PM 12/3/99 , Bosko Milekic wrote: > this area of the tree. So, if you're interested, here's the present URL to > the most recent patch on what I've done so far: > > http://pages.infinit.net/bmilekic/mbuf.patch > Thanks! I will try them out on my test machine. I am only really concerned about my public web server, as we have caught ex-customer'd kids trying out various hacking tools/scripts before :-( ---Mike ********************************************************************** Mike Tancsa * mike@sentex.net Sentex Communications Corp, * http://www.sentex.net/mike Cambridge, Ontario * 519 651 3400 Canada * To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Sat Dec 4 11:28:13 1999 Delivered-To: freebsd-stable@freebsd.org Received: from hotmail.com (f247.law3.hotmail.com [209.185.241.247]) by hub.freebsd.org (Postfix) with SMTP id 44C0615062 for ; Sat, 4 Dec 1999 11:28:09 -0800 (PST) (envelope-from xy127@hotmail.com) Received: (qmail 28981 invoked by uid 0); 4 Dec 1999 19:28:08 -0000 Message-ID: <19991204192808.28980.qmail@hotmail.com> Received: from 130.207.226.69 by www.hotmail.com with HTTP; Sat, 04 Dec 1999 11:28:08 PST X-Originating-IP: [130.207.226.69] From: "xy 127" To: freebsd-questions@freebsd.org Cc: freebsd-stable@freebsd.org Subject: making a port?? Date: Sat, 04 Dec 1999 14:28:08 EST Mime-Version: 1.0 Content-Type: text/plain; format=flowed Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hey, I'm running FreeBSD 3.3 on a HP Pavilioin with a pentium-300 MHz. My question is regarding building a port. Since I've installed FreeBSD this is the first port I tried to build and it failed. I downloaded cdrecord.tar.gz from the FreeBSD Ports collection and extracted it and typed ``make'' and here's the error I got: bash-2.03$ make "/usr/share/mk/bsd.port.mk", line 2: Could not find /usr/ports/Mk/bsd.port.mk make: fatal errors encountered -- cannot continue bash-2.03$ bash-2.03$ more /usr/share/mk/bsd.port.mk PORTSDIR?= /usr/ports .include "${PORTSDIR}/Mk/bsd.port.mk" bash-2.03$ My /usr/ports directory is empty. Where can I get /usr/ports/Mk/bsd.port.mk??? Also why is it when I extract cdrecord.tar.gz with `tar zxvf cdrecord.tar.gz` it puts the files in pub/FreeBSD/branches/-current/ports/sysutils/?? Why doesn't it just extract the files you need, whats the deal with all the extra dirs? Please send replys to my email address, because I do not subscribe to the mailing list. Thanks. ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Sat Dec 4 12:57:30 1999 Delivered-To: freebsd-stable@freebsd.org Received: from typhoon.mail.pipex.net (typhoon.mail.pipex.net [158.43.128.27]) by hub.freebsd.org (Postfix) with SMTP id C722414E24 for ; Sat, 4 Dec 1999 12:57:24 -0800 (PST) (envelope-from mark@dogma.freebsd-uk.eu.org) Received: (qmail 29699 invoked from network); 4 Dec 1999 20:55:12 -0000 Received: from userat43.uk.uudial.com (HELO marder-1.) (62.188.137.146) by smtp.dial.pipex.com with SMTP; 4 Dec 1999 20:55:12 -0000 Received: (from mark@localhost) by marder-1. (8.9.3/8.8.8) id UAA00490; Sat, 4 Dec 1999 20:55:11 GMT (envelope-from mark) Date: Sat, 4 Dec 1999 20:55:11 +0000 From: Mark Ovens To: xy 127 Cc: freebsd-questions@freebsd.org, freebsd-stable@freebsd.org Subject: Re: making a port?? Message-ID: <19991204205511.B319@marder-1> References: <19991204192808.28980.qmail@hotmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre2i In-Reply-To: <19991204192808.28980.qmail@hotmail.com> Organization: Total lack of Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, Dec 04, 1999 at 02:28:08PM -0500, xy 127 wrote: > Hey, > > I'm running FreeBSD 3.3 on a HP Pavilioin with a pentium-300 MHz. > My question is regarding building a port. Since I've installed > FreeBSD this is the first port I tried to build and it failed. > > I downloaded cdrecord.tar.gz from the FreeBSD Ports collection and > extracted it and typed ``make'' and here's the error I got: > > bash-2.03$ make ^ Firstly, you should run this as root. > "/usr/share/mk/bsd.port.mk", line 2: Could not find > /usr/ports/Mk/bsd.port.mk > make: fatal errors encountered -- cannot continue > bash-2.03$ > bash-2.03$ more /usr/share/mk/bsd.port.mk > PORTSDIR?= /usr/ports > .include "${PORTSDIR}/Mk/bsd.port.mk" > bash-2.03$ > > My /usr/ports directory is empty. Where can I get > /usr/ports/Mk/bsd.port.mk??? > Run /stand/sysinstall; Custom->Distributions->Custom(press SPACE to select, not RETURN) then check Ports > Also why is it when I extract cdrecord.tar.gz with > `tar zxvf cdrecord.tar.gz` it puts the files in > pub/FreeBSD/branches/-current/ports/sysutils/?? > Why doesn't it just extract the files you need, whats the > deal with all the extra dirs? > Hmm, not sure, but it will work OK once you've got the ports tree installed. HTH > Please send replys to my email address, because I do not subscribe > to the mailing list. Thanks. > > > > > ______________________________________________________ > Get Your Private, Free Email at http://www.hotmail.com > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-questions" in the body of the message -- PERL has been described as "the duct tape of the Internet" and "the Unix Swiss Army chainsaw" - Computer Shopper 12/99 ________________________________________________________________ FreeBSD - The Power To Serve http://www.freebsd.org My Webpage http://ukug.uk.freebsd.org/~mark/ mailto:mark@ukug.uk.freebsd.org http://www.radan.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Sat Dec 4 13: 5:59 1999 Delivered-To: freebsd-stable@freebsd.org Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by hub.freebsd.org (Postfix) with ESMTP id 7786914E24 for ; Sat, 4 Dec 1999 13:05:56 -0800 (PST) (envelope-from randy@psg.com) Received: from randy by rip.psg.com with local (Exim 3.11 #1) id 11uMN5-000Ju5-00 for freebsd-stable@freebsd.org; Sat, 04 Dec 1999 13:05:35 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: FreeBSD Stable Subject: Re: -stable of 99.12.2 hoistile to ntpd? Message-Id: Date: Sat, 04 Dec 1999 13:05:35 -0800 Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > built new -stable, running old ntpd 93a. now i get ... > > Dec 3 04:55:18 cmd ntpd pid 303 tried to use non-present sched_get_priority_max > Dec 3 04:55:18 cmd ntpd pid 303 tried to use non-present sched_setscheduler > Dec 3 04:55:18 ntpd[303]: sched_setscheduler(): Function not implemented > Dec 3 05:02:56 ntpd[303]: kernel pll status change 2041 > Dec 3 06:40:54 cmd ntpd pid 303 tried to use non-present sched_get_priority_max > Dec 3 06:40:54 cmd ntpd pid 303 tried to use non-present sched_setscheduler > Dec 3 06:40:54 ntpd[303]: sched_setscheduler(): Function not implemented > Dec 3 06:48:41 ntpd[303]: kernel pll status change 2041 > Dec 3 07:11:20 pid 303 (ntpd), uid 0: exited on signal 8 (core dumped) john polstra gave me the fix options "P1003_1B" options "_KPOSIX_PRIORITY_SCHEDULING" randy To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Sat Dec 4 16:10: 0 1999 Delivered-To: freebsd-stable@freebsd.org Received: from mail.rdc3.on.home.com (ha1.rdc3.on.home.com [24.2.9.68]) by hub.freebsd.org (Postfix) with ESMTP id BF2CF1529A for ; Sat, 4 Dec 1999 16:09:56 -0800 (PST) (envelope-from willwong@anime.ca) Received: from mail.anime.ca ([24.112.80.104]) by mail.rdc3.on.home.com (InterMail v4.01.01.02 201-229-111-106) with ESMTP id <19991205000639.FFIE21594.mail.rdc3.on.home.com@mail.anime.ca> for ; Sat, 4 Dec 1999 16:06:39 -0800 Received: from magus (HSE-Toronto-ppp98185.sympatico.ca [216.209.69.38]) by mail.anime.ca (8.9.3/8.9.3) with SMTP id TAA89027 for ; Sat, 4 Dec 1999 19:08:33 -0500 (EST) (envelope-from willwong@anime.ca) Message-ID: <001f01bf3eb4$e09ec480$0300a8c0@anime.ca> From: "William Wong" To: Subject: Netgraph + PPPoE Date: Sat, 4 Dec 1999 19:08:31 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Has netgraph and pppoe support been included in -STABLE yet? - Will To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Sat Dec 4 17:40:41 1999 Delivered-To: freebsd-stable@freebsd.org Received: from switzcpl.lib.in.us (switzcpl.lib.in.us [208.18.164.10]) by hub.freebsd.org (Postfix) with ESMTP id 3B13D15429 for ; Sat, 4 Dec 1999 17:40:24 -0800 (PST) (envelope-from leclaire@sprintmail.com) Received: from [192.168.0.2] (cvx-dial172.seidata.com [208.15.172.172]) by switzcpl.lib.in.us (8.9.3/8.9.3) with ESMTP id UAA04212; Sat, 4 Dec 1999 20:39:17 -0500 (EST) (envelope-from leclaire@sprintmail.com) Date: Sat, 4 Dec 1999 20:39:10 -0500 (EST) From: Andre LeClaire Reply-To: leclaire@switzcpl.lib.in.us To: "Jordan K. Hubbard" Cc: stable@FreeBSD.ORG Subject: Re: Anticipated release date for 3.4 In-Reply-To: <14724.942862880@localhost> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Just wondering, does this mean there will be a 3.3 Toolkit release soon? Andre > Will be December 15th. The traditional code slush will go into effect > on the 1st. November would be an excellent month for merging your > changes, after which I'll be exercising my usual perogative of > inspecting all potential changes with a more jaundiced eye. :) > > - Jordan > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Sat Dec 4 18:45: 5 1999 Delivered-To: freebsd-stable@freebsd.org Received: from s02.arpa-canada.net (s02.arpa-canada.net [209.104.118.66]) by hub.freebsd.org (Postfix) with SMTP id D0A57153B7 for ; Sat, 4 Dec 1999 18:45:00 -0800 (PST) (envelope-from matt@S02.ARPA-CANADA.NET) Received: (qmail 41602 invoked by uid 1000); 5 Dec 1999 02:44:42 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 5 Dec 1999 02:44:42 -0000 Date: Sat, 4 Dec 1999 21:44:42 -0500 (EST) From: matt To: FreeBSD-Stable@FreeBSD.ORG Subject: Little whois patch. Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-1212485093-944361882=:41590" Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --0-1212485093-944361882=:41590 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi, I noticed that the Canadian Internic was being left out of the whois command line opts, so I thought I'd add it to the options. I really have no clue who to send this to, or if I should use send-pr maybe, but it's technically not a problem. Hopefully one of the committers can give me feedback on where this should go. It's diffed against 3.3-stable, does nothing but give 'whois -c' for whois.internic.ca, us Canadians feel left out, cheers. =) Matt --0-1212485093-944361882=:41590 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="whois.diff" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="whois.diff" ZGlmZiAtdXJiTiB3aG9pcy5vbGQvd2hvaXMuMSB3aG9pcy93aG9pcy4xDQot LS0gd2hvaXMub2xkL3dob2lzLjEJRnJpIFNlcCAxNyAxMDozNTo1NiAxOTk5 DQorKysgd2hvaXMvd2hvaXMuMQlTYXQgRGVjICA0IDIxOjI1OjUxIDE5OTkN CkBAIC00MCw3ICs0MCw3IEBADQogLk5kIEludGVybmV0IGRvbWFpbiBuYW1l IGFuZCBuZXR3b3JrIG51bWJlciBkaXJlY3Rvcnkgc2VydmljZQ0KIC5TaCBT WU5PUFNJUw0KIC5ObSB3aG9pcw0KLS5PcCBGbCBhZGdwclINCisuT3AgRmwg YWNkZ3ByUg0KIC5PcCBGbCBoIEFyIGhvc3QNCiAuQXIgbmFtZSAuLi4NCiAu U2ggREVTQ1JJUFRJT04NCkBAIC01OCw2ICs1OCwxMCBAQA0KIGNvdmVyZWQg bmVpdGhlciBieQ0KIC5UbiBBUE5JQyBub3IgYnkNCiAuVG4gUklQRSAuDQor Lkl0IEZsIGMNCitVc2UgdGhlIENhbmFkaWFuIEludGVybmljIFJlZ2lzdHJ5 IA0KK2RhdGFiYXNlLiBJdCBjb250YWlucyBwb2ludHMgb2YgY29udGFjdCBm b3Igc3ViZG9tYWlucyBvZg0KKy5UbiBcJi5DQSAuDQogLkl0IEZsIGQNCiBV c2UgdGhlIFVTIERlcGFydG1lbnQgb2YgRGVmZW5zZQ0KIGRhdGFiYXNlLiAg SXQgY29udGFpbnMgcG9pbnRzIG9mIGNvbnRhY3QgZm9yIHN1YmRvbWFpbnMg b2YNCmRpZmYgLXVyYk4gd2hvaXMub2xkL3dob2lzLmMgd2hvaXMvd2hvaXMu Yw0KLS0tIHdob2lzLm9sZC93aG9pcy5jCVNhdCBEZWMgIDQgMjE6MjE6Mjgg MTk5OQ0KKysrIHdob2lzL3dob2lzLmMJU2F0IERlYyAgNCAyMToyNTo1MSAx OTk5DQpAQCAtNTcsNiArNTcsNyBAQA0KICNpbmNsdWRlIDx1bmlzdGQuaD4N CiANCiAjZGVmaW5lCU5JQ0hPU1QJCSJ3aG9pcy5pbnRlcm5pYy5uZXQiDQor I2RlZmluZQlDTklDSE9TVAkid2hvaXMuaW50ZXJuaWMuY2EiDQogI2RlZmlu ZQlETklDSE9TVAkid2hvaXMubmljLm1pbCINCiAjZGVmaW5lCUdOSUNIT1NU CSJ3aG9pcy5uaWMuZ292Ig0KICNkZWZpbmUJQU5JQ0hPU1QJIndob2lzLmFy aW4ubmV0Ig0KQEAgLTg1LDExICs4NiwxNCBAQA0KICNlbmRpZg0KIA0KIAlo b3N0ID0gTklDSE9TVDsNCi0Jd2hpbGUgKChjaCA9IGdldG9wdChhcmdjLCBh cmd2LCAiYWRnaDpwclIiKSkgIT0gLTEpDQorCXdoaWxlICgoY2ggPSBnZXRv cHQoYXJnYywgYXJndiwgImFjZGdoOnByUiIpKSAhPSAtMSkNCiAJCXN3aXRj aCgoY2hhciljaCkgew0KIAkJY2FzZSAnYSc6DQogCQkJaG9zdCA9IEFOSUNI T1NUOw0KIAkJCWJyZWFrOw0KKwkJY2FzZSAnYyc6DQorCQkJaG9zdCA9IENO SUNIT1NUOw0KKwkJCWJyZWFrOw0KIAkJY2FzZSAnZCc6DQogCQkJaG9zdCA9 IEROSUNIT1NUOw0KIAkJCWJyZWFrOw0KQEAgLTE1OSw2ICsxNjMsNiBAQA0K IHN0YXRpYyB2b2lkDQogdXNhZ2UoKQ0KIHsNCi0JZnByaW50ZihzdGRlcnIs ICJ1c2FnZTogd2hvaXMgWy1hZGdwclJdIFstaCBob3N0bmFtZV0gbmFtZSAu Li5cbiIpOw0KKwlmcHJpbnRmKHN0ZGVyciwgInVzYWdlOiB3aG9pcyBbLWFj ZGdwclJdIFstaCBob3N0bmFtZV0gbmFtZSAuLi5cbiIpOw0KIAlleGl0KEVY X1VTQUdFKTsNCiB9DQo= --0-1212485093-944361882=:41590-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Sat Dec 4 21:30:12 1999 Delivered-To: freebsd-stable@freebsd.org Received: from florence.pavilion.net (florence.pavilion.net [194.242.128.25]) by hub.freebsd.org (Postfix) with ESMTP id EF821153CF for ; Sat, 4 Dec 1999 21:30:05 -0800 (PST) (envelope-from joe@florence.pavilion.net) Received: (from joe@localhost) by florence.pavilion.net (8.9.3/8.8.8) id FAA28840; Sun, 5 Dec 1999 05:30:02 GMT (envelope-from joe) Date: Sun, 5 Dec 1999 05:30:01 +0000 From: Josef Karthauser To: William Wong Cc: freebsd-stable@FreeBSD.ORG Subject: Re: Netgraph + PPPoE Message-ID: <19991205053001.A28637@florence.pavilion.net> References: <001f01bf3eb4$e09ec480$0300a8c0@anime.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre2i In-Reply-To: <001f01bf3eb4$e09ec480$0300a8c0@anime.ca> X-NCC-RegID: uk.pavilion Organisation: Pavilion Internet plc, Lees House, 21-23 Dyke Road, Brighton, England Phone: +44-845-333-5000 Fax: +44-845-333-5001 Mobile: +44-403-596893 Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, Dec 04, 1999 at 07:08:31PM -0500, William Wong wrote: > Has netgraph and pppoe support been included in -STABLE yet? > > - Will Yes. Joe -- Josef Karthauser FreeBSD: How many times have you booted today? Technical Manager Viagra for your server (http://www.uk.freebsd.org) Pavilion Internet plc. [joe@pavilion.net, joe@uk.freebsd.org, joe@tao.org.uk] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message