From owner-freebsd-stable@FreeBSD.ORG Thu Nov 20 18:34:42 2003 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0229C16A4CE for ; Thu, 20 Nov 2003 18:34:42 -0800 (PST) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id BA0C143FE5 for ; Thu, 20 Nov 2003 18:34:39 -0800 (PST) (envelope-from doconnor@gsoft.com.au) Received: from localhost (localhost [127.0.0.1]) by cain.gsoft.com.au (8.12.9/8.12.8) with ESMTP id hAL2YBhk063933; Fri, 21 Nov 2003 13:04:12 +1030 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: freebsd-stable@freebsd.org User-Agent: KMail/1.5.3 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200311211304.11267.doconnor@gsoft.com.au> X-Spam-Score: -2.3 () CARRIAGE_RETURNS,SPAM_PHRASE_00_01,USER_AGENT,USER_AGENT_KMAIL X-Scanned-By: MIMEDefang 2.16 (www . roaringpenguin . com / mimedefang) cc: brian@Awfulhak.org Subject: Strange intermittent PPP problem X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Date: Fri, 21 Nov 2003 02:34:42 -0000 X-Original-Date: Fri, 21 Nov 2003 13:04:11 +1030 X-List-Received-Date: Fri, 21 Nov 2003 02:34:42 -0000 Hi, We have a radar system sited at Rarotonga and it has a modem connection to a (the?) local ISP (Oyster). It used to work fine, but in the last 2 weeks or so it has been having problems dialling up at it's usual time (1am UT). The ISP claims no changes have been made at that time. If I ring the system and tell it to call back it seems to connect fine. Here is a log extract from a dud session -> Nov 16 01:00:35 rarotonga ppp[67972]: tun0: LCP: FSM: Using "deflink" as a transport Nov 16 01:00:35 rarotonga ppp[67972]: tun0: LCP: deflink: State change Initial --> Closed Nov 16 01:00:35 rarotonga ppp[67972]: tun0: LCP: deflink: State change Closed --> Stopped Nov 16 01:00:36 rarotonga ppp[67972]: tun0: LCP: deflink: LayerStart Nov 16 01:00:36 rarotonga ppp[67972]: tun0: LCP: deflink: SendConfigReq(1) state = Stopped Nov 16 01:00:36 rarotonga ppp[67972]: tun0: LCP: ACFCOMP[2] Nov 16 01:00:36 rarotonga ppp[67972]: tun0: LCP: PROTOCOMP[2] Nov 16 01:00:36 rarotonga ppp[67972]: tun0: LCP: ACCMAP[6] 0x00000000 Nov 16 01:00:36 rarotonga ppp[67972]: tun0: LCP: MRU[4] 1500 Nov 16 01:00:36 rarotonga ppp[67972]: tun0: LCP: MAGICNUM[6] 0x24cb74f5 Nov 16 01:00:36 rarotonga ppp[67972]: tun0: LCP: deflink: State change Stopped --> Req-Sent Nov 16 01:00:39 rarotonga ppp[67972]: tun0: LCP: deflink: SendConfigReq(1) state = Req-Sent Nov 16 01:00:39 rarotonga ppp[67972]: tun0: LCP: ACFCOMP[2] Nov 16 01:00:39 rarotonga ppp[67972]: tun0: LCP: PROTOCOMP[2] Nov 16 01:00:39 rarotonga ppp[67972]: tun0: LCP: ACCMAP[6] 0x00000000 Nov 16 01:00:39 rarotonga ppp[67972]: tun0: LCP: MRU[4] 1500 Nov 16 01:00:39 rarotonga ppp[67972]: tun0: LCP: MAGICNUM[6] 0x24cb74f5 Nov 16 01:00:42 rarotonga ppp[67972]: tun0: LCP: deflink: SendConfigReq(1) state = Req-Sent Nov 16 01:00:42 rarotonga ppp[67972]: tun0: LCP: ACFCOMP[2] Nov 16 01:00:42 rarotonga ppp[67972]: tun0: LCP: PROTOCOMP[2] Nov 16 01:00:42 rarotonga ppp[67972]: tun0: LCP: ACCMAP[6] 0x00000000 Nov 16 01:00:42 rarotonga ppp[67972]: tun0: LCP: MRU[4] 1500 Nov 16 01:00:42 rarotonga ppp[67972]: tun0: LCP: MAGICNUM[6] 0x24cb74f5 Nov 16 01:00:45 rarotonga ppp[67972]: tun0: LCP: deflink: SendConfigReq(1) state = Req-Sent Nov 16 01:00:45 rarotonga ppp[67972]: tun0: LCP: ACFCOMP[2] Nov 16 01:00:45 rarotonga ppp[67972]: tun0: LCP: PROTOCOMP[2] Nov 16 01:00:45 rarotonga ppp[67972]: tun0: LCP: ACCMAP[6] 0x00000000 Nov 16 01:00:45 rarotonga ppp[67972]: tun0: LCP: MRU[4] 1500 Nov 16 01:00:45 rarotonga ppp[67972]: tun0: LCP: MAGICNUM[6] 0x24cb74f5 Nov 16 01:00:48 rarotonga ppp[67972]: tun0: LCP: deflink: SendConfigReq(1) state = Req-Sent Nov 16 01:00:48 rarotonga ppp[67972]: tun0: LCP: ACFCOMP[2] Nov 16 01:00:48 rarotonga ppp[67972]: tun0: LCP: PROTOCOMP[2] Nov 16 01:00:48 rarotonga ppp[67972]: tun0: LCP: ACCMAP[6] 0x00000000 Nov 16 01:00:48 rarotonga ppp[67972]: tun0: LCP: MRU[4] 1500 Nov 16 01:00:48 rarotonga ppp[67972]: tun0: LCP: MAGICNUM[6] 0x24cb74f5 Nov 16 01:00:48 rarotonga ppp[67972]: tun0: Warning: Packet too large (4102), discarding. Nov 16 01:00:51 rarotonga ppp[67972]: tun0: LCP: deflink: LayerFinish Nov 16 01:00:51 rarotonga ppp[67972]: tun0: LCP: deflink: State change Req-Sent --> Stopped Nov 16 01:00:51 rarotonga ppp[67972]: tun0: LCP: deflink: State change Stopped --> Closed Nov 16 01:00:51 rarotonga ppp[67972]: tun0: LCP: deflink: State change Closed --> Initial Nov 16 01:00:52 rarotonga ppp[67972]: tun0: Phase: deflink: Disconnected! And from a working session -> Nov 18 23:09:34 rarotonga ppp[64554]: tun0: LCP: FSM: Using "deflink" as a transport Nov 18 23:09:34 rarotonga ppp[64554]: tun0: LCP: deflink: State change Initial --> Closed Nov 18 23:09:34 rarotonga ppp[64554]: tun0: LCP: deflink: State change Closed --> Stopped Nov 18 23:09:35 rarotonga ppp[64554]: tun0: LCP: deflink: LayerStart Nov 18 23:09:35 rarotonga ppp[64554]: tun0: LCP: deflink: SendConfigReq(1) state = Stopped Nov 18 23:09:35 rarotonga ppp[64554]: tun0: LCP: ACFCOMP[2] Nov 18 23:09:35 rarotonga ppp[64554]: tun0: LCP: PROTOCOMP[2] Nov 18 23:09:35 rarotonga ppp[64554]: tun0: LCP: ACCMAP[6] 0x00000000 Nov 18 23:09:35 rarotonga ppp[64554]: tun0: LCP: MRU[4] 1500 Nov 18 23:09:35 rarotonga ppp[64554]: tun0: LCP: MAGICNUM[6] 0x15a16783 Nov 18 23:09:35 rarotonga ppp[64554]: tun0: LCP: AUTHPROTO[4] 0xc023 (PAP) Nov 18 23:09:35 rarotonga ppp[64554]: tun0: LCP: deflink: State change Stopped --> Req-Sent Nov 18 23:09:36 rarotonga ppp[64554]: tun0: LCP: deflink: RecvConfigReq(1) state = Req-Sent Nov 18 23:09:36 rarotonga ppp[64554]: tun0: LCP: ACFCOMP[2] Nov 18 23:09:36 rarotonga ppp[64554]: tun0: LCP: PROTOCOMP[2] Nov 18 23:09:36 rarotonga ppp[64554]: tun0: LCP: ACCMAP[6] 0x00000000 Nov 18 23:09:36 rarotonga ppp[64554]: tun0: LCP: MRU[4] 1500 Nov 18 23:09:36 rarotonga ppp[64554]: tun0: LCP: MAGICNUM[6] 0xac742603 Nov 18 23:09:36 rarotonga ppp[64554]: tun0: LCP: deflink: SendConfigAck(1) state = Req-Sent Nov 18 23:09:36 rarotonga ppp[64554]: tun0: LCP: ACFCOMP[2] Nov 18 23:09:36 rarotonga ppp[64554]: tun0: LCP: PROTOCOMP[2] Nov 18 23:09:36 rarotonga ppp[64554]: tun0: LCP: ACCMAP[6] 0x00000000 Nov 18 23:09:36 rarotonga ppp[64554]: tun0: LCP: MRU[4] 1500 Nov 18 23:09:36 rarotonga ppp[64554]: tun0: LCP: MAGICNUM[6] 0xac742603 Nov 18 23:09:36 rarotonga ppp[64554]: tun0: LCP: deflink: State change Req-Sent --> Ack-Sent Nov 18 23:09:36 rarotonga ppp[64554]: tun0: LCP: deflink: RecvConfigAck(1) state = Ack-Sent Nov 18 23:09:36 rarotonga ppp[64554]: tun0: LCP: ACFCOMP[2] Nov 18 23:09:36 rarotonga ppp[64554]: tun0: LCP: PROTOCOMP[2] Nov 18 23:09:36 rarotonga ppp[64554]: tun0: LCP: ACCMAP[6] 0x00000000 Nov 18 23:09:36 rarotonga ppp[64554]: tun0: LCP: MRU[4] 1500 Nov 18 23:09:36 rarotonga ppp[64554]: tun0: LCP: MAGICNUM[6] 0x15a16783 Nov 18 23:09:36 rarotonga ppp[64554]: tun0: LCP: AUTHPROTO[4] 0xc023 (PAP) Nov 18 23:09:36 rarotonga ppp[64554]: tun0: LCP: deflink: State change Ack-Sent --> Opened Nov 18 23:09:36 rarotonga ppp[64554]: tun0: LCP: deflink: LayerUp Nov 18 23:09:36 rarotonga ppp[64554]: tun0: LCP: deflink: SendIdent(0) state = Opened Nov 18 23:09:36 rarotonga ppp[64554]: tun0: LCP: MAGICNUM 15a16783 Nov 18 23:09:36 rarotonga ppp[64554]: tun0: LCP: TEXT user-ppp 3.1 (built Jan 9 2003) It seems like one end (dunno which end is which for these messages) isn't responding properly..? Also, the size it complains about is right on the edge of what the code checks for - perhaps it's an off by one error? The PPP is a little old, but I am somewhat reluctant to upgrade it given it's the sole means of communication :) Anyone got any hints? -- 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 GPG Fingerprint - 9A8C 569F 685A D928 5140 AE4B 319B 41F4 5D17 FDD5 From owner-freebsd-stable@FreeBSD.ORG Mon Nov 24 12:35:02 2003 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5C06B16A4CE for ; Mon, 24 Nov 2003 12:35:02 -0800 (PST) Received: from mandarin.fruitsalad.org (pc117.net160.koping.net [81.16.160.117]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9962F43F85 for ; Mon, 24 Nov 2003 12:35:00 -0800 (PST) (envelope-from matt@hasta.se) Received: from [192.168.15.88] (helo=klementin) by mandarin.fruitsalad.org with smtp (Exim 4.14) id 1AONQ4-000LFA-JH; Mon, 24 Nov 2003 21:34:52 +0100 From: "Matt Douhan" To: "Francisco Reyes" Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <20031124145242.E80167@zoraida.natserv.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal cc: Brett Glass cc: stable@freebsd.org Subject: SV: SV: Does 4.9-RELEASE work with 3Ware RAID card? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Date: Mon, 24 Nov 2003 20:35:02 -0000 X-Original-Date: Mon, 24 Nov 2003 21:35:05 +0100 X-List-Received-Date: Mon, 24 Nov 2003 20:35:02 -0000 <-----Ursprungligt meddelande----- Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E7EAC16A4CE for ; Tue, 9 Dec 2003 07:31:19 -0800 (PST) Received: from tonij.jolt.nu (as4-6-3.lk.bonet.se [217.215.176.200]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6EDF043D1F for ; Tue, 9 Dec 2003 07:31:15 -0800 (PST) (envelope-from c4@portad.se) Received: from na.portad.se (na.nat.jolt.nu [10.0.0.2]) by tonij.jolt.nu (8.12.9/8.12.9) with ESMTP id hB9FWbWC079082 for ; Tue, 9 Dec 2003 16:32:37 +0100 (CET) (envelope-from c4@portad.se) Message-Id: <6.0.1.1.2.20031209160743.023fa910@jolt.nu> X-Sender: c4@jolt.nu X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 To: freebsd-stable@freebsd.org From: Tobias Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=1.9 required=5.0 tests=HTML_00_10,MSG_ID_ADDED_BY_MTA_3 version=2.55 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Subject: Problem with large amounts of IDE drives X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Date: Tue, 09 Dec 2003 15:31:20 -0000 X-Original-Date: Tue, 09 Dec 2003 16:30:22 +0100 X-List-Received-Date: Tue, 09 Dec 2003 15:31:20 -0000 Has anyone except me had trouble (or success) running 16 or more IDE drives on 4.8-RELEASE? Currently we run perf on 14 drives, 2 connected to motherboard ide and 12 connected to 2 HighPoint Tech RocketRaid 454. The 454 has no native driver for freebsd as of yet and we are told by hpt to run it using the 404's driver. We ran perf with 18 drives about one week ago, and after we mounted the last 4 (raided that is) it worked fine for like half an hour or maybe a whole hour then it locked the mount point. It's not reported in any logs and the hpt374.status sysctl that is set reports no trouble neither. I'm thinking that it might be a driver problem but I don't see why it ONLY occurs when we have the raid mounted... never if we have 1 or 2 out of 3 mounted. But as soon as all drives are mounted. Oh yeah, it doesn't matter which raid we mount as the last... it's always the LAST one mounted that f00bars... The computer has a 550W PSU so power should not really be a problem. Nor does it have any i/o to talk about... I'd say in a given day it reads about 50gig and writes about 10-30gig. Any clues? :o) dmesg follows for perf Copyright (c) 1992-2003 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 4.8-RELEASE #1: Sat Dec 6 12:32:45 GMT 2003 c4@perf:/usr/src/sys/compile/perf Timecounter "i8254" frequency 1193182 Hz CPU: Intel Pentium III (863.87-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x68a Stepping = 10 Features=0x383f9ff real memory = 535560192 (523008K bytes) avail memory = 515723264 (503636K bytes) Preloaded elf kernel "kernel" at 0xc053c000. Preloaded elf module "hpt374.ko" at 0xc053c09c. Pentium Pro MTRR support enabled md0: Malloc disk Using $PIR table, 12 entries at 0xc00f2c00 npx0: on motherboard npx0: INT 16 interface pcib0: on motherboard pci0: on pcib0 agp0: mem 0xffa80000-0xffafffff,0xf8000000-0xfbffffff irq 11 at device 2.0 on pci0 pcib1: at device 30.0 on pci0 pci1: on pcib1 hpt3740: port 0xde00-0xdeff,0xdf54-0xdf57,0xdf58-0xdf5f,0xdf7c-0xdf7f,0xdf60-0xdf67 irq 9 at device 9.0 on pci1 hpt3741: port 0xd000-0xd0ff,0xdf80-0xdf83,0xdf68-0xdf6f,0xdf84-0xdf87,0xdf88-0xdf8f irq 9 at device 9.1 on pci1 xl0: <3Com 3c905B-TX Fast Etherlink XL> port 0xdc00-0xdc7f mem 0xff8dfc00-0xff8dfc7f irq 10 at device 11.0 on pci1 xl0: Ethernet address: 00:10:5a:a5:0a:fc miibus0: on xl0 xlphy0: <3Com internal media interface> on miibus0 xlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto hpt3742: port 0xd400-0xd4ff,0xdf98-0xdf9b,0xdf90-0xdf97,0xdf9c-0xdf9f,0xdfa0-0xdfa7 irq 9 at device 13.0 on pci1 hpt3743: port 0xd800-0xd8ff,0xdfe0-0xdfe3,0xdfa8-0xdfaf,0xdfe4-0xdfe7,0xdff0-0xdff7 irq 9 at device 13.1 on pci1 isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0xffa0-0xffaf at device 31.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 uhci0: port 0xef40-0xef5f irq 7 at device 31.2 on pci0 usb0: on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered pci0: (vendor=0x8086, dev=0x2443) at 31.3 irq 3 uhci1: port 0xef80-0xef9f irq 10 at device 31.4 on pci0 usb1: on uhci1 usb1: USB revision 1.0 uhub1: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered orm0: