From owner-freebsd-stable@FreeBSD.ORG Sun May 9 05:26:53 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1BF67106566C; Sun, 9 May 2010 05:26:53 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id CDB1B8FC13; Sun, 9 May 2010 05:26:52 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o495QpYg079208; Sun, 9 May 2010 01:26:51 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o495QpcX079207; Sun, 9 May 2010 05:26:51 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 9 May 2010 05:26:51 GMT Message-Id: <201005090526.o495QpcX079207@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [releng_8_0 tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 May 2010 05:26:53 -0000 TB --- 2010-05-09 04:47:53 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-05-09 04:47:53 - starting RELENG_8_0 tinderbox run for amd64/amd64 TB --- 2010-05-09 04:47:53 - cleaning the object tree TB --- 2010-05-09 04:48:26 - cvsupping the source tree TB --- 2010-05-09 04:48:26 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8_0/amd64/amd64/supfile TB --- 2010-05-09 05:26:51 - WARNING: /usr/bin/csup returned exit code 1 TB --- 2010-05-09 05:26:51 - ERROR: unable to cvsup the source tree TB --- 2010-05-09 05:26:51 - 1.00 user 13.12 system 2338.07 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8_0-amd64-amd64.full From owner-freebsd-stable@FreeBSD.ORG Sun May 9 05:27:42 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 12FCD1065670; Sun, 9 May 2010 05:27:42 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id C68498FC1B; Sun, 9 May 2010 05:27:41 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o495Rfsq081366; Sun, 9 May 2010 01:27:41 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o495RfGJ081365; Sun, 9 May 2010 05:27:41 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 9 May 2010 05:27:41 GMT Message-Id: <201005090527.o495RfGJ081365@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [releng_8_0 tinderbox] failure on i386/i386 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 May 2010 05:27:42 -0000 TB --- 2010-05-09 04:47:53 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-05-09 04:47:53 - starting RELENG_8_0 tinderbox run for i386/i386 TB --- 2010-05-09 04:47:53 - cleaning the object tree TB --- 2010-05-09 04:48:24 - cvsupping the source tree TB --- 2010-05-09 04:48:24 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8_0/i386/i386/supfile TB --- 2010-05-09 05:27:41 - WARNING: /usr/bin/csup returned exit code 1 TB --- 2010-05-09 05:27:41 - ERROR: unable to cvsup the source tree TB --- 2010-05-09 05:27:41 - 0.83 user 11.31 system 2387.44 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8_0-i386-i386.full From owner-freebsd-stable@FreeBSD.ORG Sun May 9 06:07:42 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B1134106566B; Sun, 9 May 2010 06:07:42 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 47E3B8FC0A; Sun, 9 May 2010 06:07:42 +0000 (UTC) Received: by vws17 with SMTP id 17so1688189vws.13 for ; Sat, 08 May 2010 23:07:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:subject:x-enigmail-version:content-type :content-transfer-encoding; bh=IKQAGlw8fdZ5fsNBIUHCjTx7r7HkbDpbs7+KR8kzbMA=; b=juxKku4buassmqdUXAeN/tj7o5cYuZgBbe13n6rheKeTO2r3BKrZ2oLD6JnC+cvQ6F B+AKmstN0CzpekJCMkHdzavwMsbQrpORgPuybOsr2mpwDSMsjjKOmNTh/9ZJwaTRucbp GHsV7uZUSjpBBTFbVOxC9daL9tmI42PENXWoY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :x-enigmail-version:content-type:content-transfer-encoding; b=U1OIMOirMJotUAMOQjzaRXDaV+D77xjqWBNYhuB1SqERg0NFgcgdJ6eJWLfLzN/W5i gfpQlJTZNXuT8ibX1jF1cHVVrNuuyvE7b1JwqTqNMCg55HN49xENz5EIUZd1ABPGqFJk nRp1wVSGGgFx8jIS2iARbR7P4xGBqW8HCiVeU= Received: by 10.220.107.8 with SMTP id z8mr1919347vco.74.1273385261159; Sat, 08 May 2010 23:07:41 -0700 (PDT) Received: from centel.dataix.local (adsl-99-19-41-129.dsl.klmzmi.sbcglobal.net [99.19.41.129]) by mx.google.com with ESMTPS id m13sm29163146vcs.13.2010.05.08.23.07.39 (version=SSLv3 cipher=RC4-MD5); Sat, 08 May 2010 23:07:40 -0700 (PDT) Sender: "J. Hellenthal" Message-ID: <4BE6512B.5030202@dataix.net> Date: Sun, 09 May 2010 02:07:39 -0400 From: jhell User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.9) Gecko/20100331 Thunderbird/3.0.4 MIME-Version: 1.0 To: Doug Barton , FreeBSD Stable X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Subject: MFC of r206686 r179870 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 May 2010 06:07:42 -0000 The following two commits to stable/7 may be responsible for dirtying the console with messages pertaining to setting values in rc.conf. Though these messages are harmless and daemons will continue to run as normal; they should be looked into & fixed. reverting to revision 201272 of rc.subr relieves this problem. r207801 | dougb | 2010-05-08 18:15:05 -0400 (Sat, 08 May 2010) | 4 lines Changed paths: M /stable/7/etc M /stable/7/etc/rc.subr MFC r206686: Make 'stop' work even if ${name}_enable is not set. r207800 | dougb | 2010-05-08 18:13:48 -0400 (Sat, 08 May 2010) | 8 lines Changed paths: M /stable/7/etc M /stable/7/etc/rc.subr MFC r179870: Move the check for enabled knobs further down in run_rc_command() so that bogus commands cause usage information to be printed instead of diagnostics about enabling the knob. This is a prerequisite for merging r206686. Regards, -- jhell From owner-freebsd-stable@FreeBSD.ORG Sun May 9 06:10:44 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 47DAB1065670; Sun, 9 May 2010 06:10:44 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 08FD18FC14; Sun, 9 May 2010 06:10:43 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o496AhB2069710; Sun, 9 May 2010 02:10:43 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o496AhH6069709; Sun, 9 May 2010 06:10:43 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 9 May 2010 06:10:43 GMT Message-Id: <201005090610.o496AhH6069709@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [releng_8_0 tinderbox] failure on powerpc/powerpc X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 May 2010 06:10:44 -0000 TB --- 2010-05-09 05:30:31 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-05-09 05:30:31 - starting RELENG_8_0 tinderbox run for powerpc/powerpc TB --- 2010-05-09 05:30:31 - cleaning the object tree TB --- 2010-05-09 05:30:45 - cvsupping the source tree TB --- 2010-05-09 05:30:45 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8_0/powerpc/powerpc/supfile TB --- 2010-05-09 06:10:43 - WARNING: /usr/bin/csup returned exit code 1 TB --- 2010-05-09 06:10:43 - ERROR: unable to cvsup the source tree TB --- 2010-05-09 06:10:43 - 0.58 user 7.03 system 2411.64 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8_0-powerpc-powerpc.full From owner-freebsd-stable@FreeBSD.ORG Sun May 9 06:10:57 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 37F22106564A; Sun, 9 May 2010 06:10:57 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id E91658FC16; Sun, 9 May 2010 06:10:56 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o496Au5P069907; Sun, 9 May 2010 02:10:56 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o496Au5w069906; Sun, 9 May 2010 06:10:56 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 9 May 2010 06:10:56 GMT Message-Id: <201005090610.o496Au5w069906@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [releng_8_0 tinderbox] failure on ia64/ia64 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 May 2010 06:10:57 -0000 TB --- 2010-05-09 05:26:52 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-05-09 05:26:52 - starting RELENG_8_0 tinderbox run for ia64/ia64 TB --- 2010-05-09 05:26:52 - cleaning the object tree TB --- 2010-05-09 05:27:05 - cvsupping the source tree TB --- 2010-05-09 05:27:05 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8_0/ia64/ia64/supfile TB --- 2010-05-09 06:10:56 - WARNING: /usr/bin/csup returned exit code 1 TB --- 2010-05-09 06:10:56 - ERROR: unable to cvsup the source tree TB --- 2010-05-09 06:10:56 - 0.61 user 7.75 system 2644.28 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8_0-ia64-ia64.full From owner-freebsd-stable@FreeBSD.ORG Sun May 9 06:12:34 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B941C1065674; Sun, 9 May 2010 06:12:34 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 761918FC20; Sun, 9 May 2010 06:12:34 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o496CXfo071625; Sun, 9 May 2010 02:12:33 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o496CXmi071615; Sun, 9 May 2010 06:12:33 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 9 May 2010 06:12:33 GMT Message-Id: <201005090612.o496CXmi071615@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [releng_8_0 tinderbox] failure on mips/mips X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 May 2010 06:12:34 -0000 TB --- 2010-05-09 05:27:41 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-05-09 05:27:41 - starting RELENG_8_0 tinderbox run for mips/mips TB --- 2010-05-09 05:27:41 - cleaning the object tree TB --- 2010-05-09 05:27:47 - cvsupping the source tree TB --- 2010-05-09 05:27:47 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8_0/mips/mips/supfile TB --- 2010-05-09 06:12:33 - WARNING: /usr/bin/csup returned exit code 1 TB --- 2010-05-09 06:12:33 - ERROR: unable to cvsup the source tree TB --- 2010-05-09 06:12:33 - 0.36 user 4.34 system 2692.45 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8_0-mips-mips.full From owner-freebsd-stable@FreeBSD.ORG Sun May 9 06:46:17 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 47560106566B for ; Sun, 9 May 2010 06:46:17 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by mx1.freebsd.org (Postfix) with ESMTP id CE92F8FC08 for ; Sun, 9 May 2010 06:46:16 +0000 (UTC) Received: (qmail 3501 invoked by uid 399); 9 May 2010 06:46:16 -0000 Received: from localhost (HELO foreign.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 9 May 2010 06:46:16 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4BE65A36.1000309@FreeBSD.org> Date: Sat, 08 May 2010 23:46:14 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.9) Gecko/20100330 Thunderbird/3.0.4 MIME-Version: 1.0 To: jhell References: <4BE6512B.5030202@dataix.net> In-Reply-To: <4BE6512B.5030202@dataix.net> X-Enigmail-Version: 1.0.1 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD Stable Subject: Re: MFC of r206686 r179870 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 May 2010 06:46:17 -0000 On 05/08/10 23:07, jhell wrote: > The following two commits to stable/7 may be responsible for dirtying > the console with messages pertaining to setting values in rc.conf. I appreciate the problem report, but pasting the commit logs from commits that I actually did doesn't provide me any useful information. What WOULD be useful are examples of "dirtying the console," along with some additional information about the settings that it is complaining about. Also, did you upgrade all of /etc, do you have an /etc/defaults/rc.conf file, what are the contents of /etc/rc.conf and /etc/rc.conf.local? In my testing the changes did not produce any unexpected results, but that doesn't mean I didn't miss something. Doug From owner-freebsd-stable@FreeBSD.ORG Sun May 9 06:50:57 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BF8AD106564A; Sun, 9 May 2010 06:50:57 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 7F8178FC0C; Sun, 9 May 2010 06:50:57 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o496ou94079492; Sun, 9 May 2010 02:50:56 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o496ouwV079491; Sun, 9 May 2010 06:50:56 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 9 May 2010 06:50:56 GMT Message-Id: <201005090650.o496ouwV079491@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [releng_8 tinderbox] failure on arm/arm X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 May 2010 06:50:57 -0000 TB --- 2010-05-09 06:12:33 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-05-09 06:12:33 - starting RELENG_8 tinderbox run for arm/arm TB --- 2010-05-09 06:12:33 - cleaning the object tree TB --- 2010-05-09 06:12:41 - cvsupping the source tree TB --- 2010-05-09 06:12:41 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8/arm/arm/supfile TB --- 2010-05-09 06:50:56 - WARNING: /usr/bin/csup returned exit code 1 TB --- 2010-05-09 06:50:56 - ERROR: unable to cvsup the source tree TB --- 2010-05-09 06:50:56 - 0.31 user 4.55 system 2302.71 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8-arm-arm.full From owner-freebsd-stable@FreeBSD.ORG Sun May 9 06:53:37 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7BADF1065673; Sun, 9 May 2010 06:53:37 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 3C8058FC13; Sun, 9 May 2010 06:53:36 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o496raRK079500; Sun, 9 May 2010 02:53:36 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o496raRw079499; Sun, 9 May 2010 06:53:36 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 9 May 2010 06:53:36 GMT Message-Id: <201005090653.o496raRw079499@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [releng_8_0 tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 May 2010 06:53:37 -0000 TB --- 2010-05-09 06:10:43 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-05-09 06:10:43 - starting RELENG_8_0 tinderbox run for sparc64/sparc64 TB --- 2010-05-09 06:10:43 - cleaning the object tree TB --- 2010-05-09 06:10:55 - cvsupping the source tree TB --- 2010-05-09 06:10:55 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8_0/sparc64/sparc64/supfile TB --- 2010-05-09 06:53:36 - WARNING: /usr/bin/csup returned exit code 1 TB --- 2010-05-09 06:53:36 - ERROR: unable to cvsup the source tree TB --- 2010-05-09 06:53:36 - 0.63 user 7.18 system 2573.08 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8_0-sparc64-sparc64.full From owner-freebsd-stable@FreeBSD.ORG Sun May 9 06:54:59 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B1BF11065672; Sun, 9 May 2010 06:54:59 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 718778FC17; Sun, 9 May 2010 06:54:59 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o496swFn079508; Sun, 9 May 2010 02:54:58 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o496swCN079507; Sun, 9 May 2010 06:54:58 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 9 May 2010 06:54:58 GMT Message-Id: <201005090654.o496swCN079507@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [releng_8 tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 May 2010 06:54:59 -0000 TB --- 2010-05-09 06:10:56 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-05-09 06:10:56 - starting RELENG_8 tinderbox run for amd64/amd64 TB --- 2010-05-09 06:10:56 - cleaning the object tree TB --- 2010-05-09 06:11:22 - cvsupping the source tree TB --- 2010-05-09 06:11:22 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8/amd64/amd64/supfile TB --- 2010-05-09 06:54:58 - WARNING: /usr/bin/csup returned exit code 1 TB --- 2010-05-09 06:54:58 - ERROR: unable to cvsup the source tree TB --- 2010-05-09 06:54:58 - 0.77 user 9.97 system 2642.34 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8-amd64-amd64.full From owner-freebsd-stable@FreeBSD.ORG Sun May 9 06:58:08 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C52F7106564A; Sun, 9 May 2010 06:58:08 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 866748FC1A; Sun, 9 May 2010 06:58:08 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o496w7eD079536; Sun, 9 May 2010 02:58:07 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o496w7mQ079535; Sun, 9 May 2010 06:58:07 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 9 May 2010 06:58:07 GMT Message-Id: <201005090658.o496w7mQ079535@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [releng_8 tinderbox] failure on i386/i386 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 May 2010 06:58:08 -0000 TB --- 2010-05-09 06:18:34 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-05-09 06:18:34 - starting RELENG_8 tinderbox run for i386/i386 TB --- 2010-05-09 06:18:34 - cleaning the object tree TB --- 2010-05-09 06:18:49 - cvsupping the source tree TB --- 2010-05-09 06:18:49 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8/i386/i386/supfile TB --- 2010-05-09 06:58:07 - WARNING: /usr/bin/csup returned exit code 1 TB --- 2010-05-09 06:58:07 - ERROR: unable to cvsup the source tree TB --- 2010-05-09 06:58:07 - 0.52 user 8.74 system 2372.80 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8-i386-i386.full From owner-freebsd-stable@FreeBSD.ORG Sun May 9 07:19:37 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CAFDA106566C for ; Sun, 9 May 2010 07:19:37 +0000 (UTC) (envelope-from demelier.david@gmail.com) Received: from mail-ww0-f54.google.com (mail-ww0-f54.google.com [74.125.82.54]) by mx1.freebsd.org (Postfix) with ESMTP id 58A048FC14 for ; Sun, 9 May 2010 07:19:37 +0000 (UTC) Received: by wwd20 with SMTP id 20so418249wwd.13 for ; Sun, 09 May 2010 00:19:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:subject :message-id:mime-version:content-type:content-disposition:user-agent; bh=nKFCTI5McfLzXTdfXuGmSaeIlD7C9wL2lZWn+J6kiT8=; b=HP9HRTLaTIoX2pU2v7hUhehLo0twyByeNEzd3BYYmsHe5oIX9VFH6PPZT1a1KIF/Sk BLW0818+wXFVeeSCMDMObIajHgkI4T236Noz1fAOKy1/g+87f2dk91AiYznbLAnZeYsd GImo1vJhLtfPdT+IU8Hmk+tuHFJ4uUqPwZKgA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:subject:message-id:mime-version:content-type :content-disposition:user-agent; b=F9YuFxlgETaCPqfZezFGA85vzRc5ZrEProHojIaMSCGZKjaKRLIctvG88revZ1DX7n 5078ojmOzzr8CmufbOafHytKsrGrMGPNaN0pJHCmOZyAXQes8h8TFyv+rfqIZpKefivO G0lQcg9MD6f0ukUSQGDqAHPD1WUTgAEz54KxI= Received: by 10.227.136.20 with SMTP id p20mr2170486wbt.37.1273389575304; Sun, 09 May 2010 00:19:35 -0700 (PDT) Received: from Melon.malikania.fr (121.21.102-84.rev.gaoland.net [84.102.21.121]) by mx.google.com with ESMTPS id u8sm30477852wbc.17.2010.05.09.00.19.34 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 09 May 2010 00:19:34 -0700 (PDT) Date: Sun, 9 May 2010 09:19:26 +0200 From: Demelier David To: freebsd-stable@freebsd.org Message-ID: <20100509071926.GA1758@Melon.malikania.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) Subject: DVD device unusable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 May 2010 07:19:37 -0000 Hi freebsd-stable@, I wanted to play a DVD on my laptop (HP ProBook 4510s) and I just can't, it does libdvdread: Get key for /VIDEO_TS/VIDEO_TS.VOB at 0x00000150 libdvdread: Error cracking CSS key for /VIDEO_TS/VIDEO_TS.VOB (0x00000150) libdvdread: Elapsed time 10 So I check the dmesg and the surprise was : acd0: FAILURE - SEND_KEY timed out acd0: FAILURE - SEND_KEY timed out acd0: FAILURE - SEND_KEY timed out (last message repeated many times) I added atapicam to my kernel config to see if it will fix the problem and it doesn't. sudo camcontrol devlist at scbus1 target 0 lun 0 (pass0,cd0) In dmesg : acd0: DVDR at ata3-master UDMA100 SATA 1.5Gb/s If I remember well it was working on -RELEASE (it should because I installed from the -RELEASE device) King regards. -- Demelier David From owner-freebsd-stable@FreeBSD.ORG Sun May 9 07:29:38 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 366A3106566C; Sun, 9 May 2010 07:29:38 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id EA0818FC13; Sun, 9 May 2010 07:29:37 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o497TbYe079909; Sun, 9 May 2010 03:29:37 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o497Tbvo079908; Sun, 9 May 2010 07:29:37 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 9 May 2010 07:29:37 GMT Message-Id: <201005090729.o497Tbvo079908@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [releng_8 tinderbox] failure on i386/pc98 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 May 2010 07:29:38 -0000 TB --- 2010-05-09 06:50:56 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-05-09 06:50:56 - starting RELENG_8 tinderbox run for i386/pc98 TB --- 2010-05-09 06:50:56 - cleaning the object tree TB --- 2010-05-09 06:51:12 - cvsupping the source tree TB --- 2010-05-09 06:51:12 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8/i386/pc98/supfile TB --- 2010-05-09 07:29:37 - WARNING: /usr/bin/csup returned exit code 1 TB --- 2010-05-09 07:29:37 - ERROR: unable to cvsup the source tree TB --- 2010-05-09 07:29:37 - 0.57 user 8.20 system 2320.29 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8-i386-pc98.full From owner-freebsd-stable@FreeBSD.ORG Sun May 9 07:33:23 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A944A106566C; Sun, 9 May 2010 07:33:23 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 66B878FC0A; Sun, 9 May 2010 07:33:23 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o497XMTr079939; Sun, 9 May 2010 03:33:22 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o497XMjn079938; Sun, 9 May 2010 07:33:22 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 9 May 2010 07:33:22 GMT Message-Id: <201005090733.o497XMjn079938@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [releng_8 tinderbox] failure on ia64/ia64 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 May 2010 07:33:23 -0000 TB --- 2010-05-09 06:53:36 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-05-09 06:53:36 - starting RELENG_8 tinderbox run for ia64/ia64 TB --- 2010-05-09 06:53:36 - cleaning the object tree TB --- 2010-05-09 06:53:49 - cvsupping the source tree TB --- 2010-05-09 06:53:49 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8/ia64/ia64/supfile TB --- 2010-05-09 07:33:22 - WARNING: /usr/bin/csup returned exit code 1 TB --- 2010-05-09 07:33:22 - ERROR: unable to cvsup the source tree TB --- 2010-05-09 07:33:22 - 0.52 user 7.65 system 2385.90 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8-ia64-ia64.full From owner-freebsd-stable@FreeBSD.ORG Sun May 9 07:37:53 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 124B4106566C; Sun, 9 May 2010 07:37:53 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id C849B8FC17; Sun, 9 May 2010 07:37:52 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o497bq7b079953; Sun, 9 May 2010 03:37:52 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o497bqjq079952; Sun, 9 May 2010 07:37:52 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 9 May 2010 07:37:52 GMT Message-Id: <201005090737.o497bqjq079952@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [releng_8 tinderbox] failure on powerpc/powerpc X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 May 2010 07:37:53 -0000 TB --- 2010-05-09 06:58:07 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-05-09 06:58:07 - starting RELENG_8 tinderbox run for powerpc/powerpc TB --- 2010-05-09 06:58:07 - cleaning the object tree TB --- 2010-05-09 06:58:18 - cvsupping the source tree TB --- 2010-05-09 06:58:18 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8/powerpc/powerpc/supfile TB --- 2010-05-09 07:37:52 - WARNING: /usr/bin/csup returned exit code 1 TB --- 2010-05-09 07:37:52 - ERROR: unable to cvsup the source tree TB --- 2010-05-09 07:37:52 - 0.50 user 7.32 system 2384.20 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8-powerpc-powerpc.full From owner-freebsd-stable@FreeBSD.ORG Sun May 9 08:25:28 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id F38761065674 for ; Sun, 9 May 2010 08:25:27 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by mx1.freebsd.org (Postfix) with ESMTP id 8641E8FC17 for ; Sun, 9 May 2010 08:25:27 +0000 (UTC) Received: (qmail 29727 invoked by uid 399); 9 May 2010 08:25:24 -0000 Received: from localhost (HELO foreign.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 9 May 2010 08:25:24 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4BE67173.4000403@FreeBSD.org> Date: Sun, 09 May 2010 01:25:23 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.9) Gecko/20100330 Thunderbird/3.0.4 MIME-Version: 1.0 To: jhell References: <4BE6512B.5030202@dataix.net> In-Reply-To: <4BE6512B.5030202@dataix.net> X-Enigmail-Version: 1.0.1 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD Stable Subject: Re: MFC of r206686 r179870 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 May 2010 08:25:28 -0000 On 05/08/10 23:07, jhell wrote: > The following two commits to stable/7 may be responsible for dirtying > the console with messages pertaining to setting values in rc.conf. I found the problem, and just committed r207811 which should fix it. The issue was only relevant to booting (which I did not test) as opposed to running rc.d scripts on the command line (which I did). Sorry for the hassle, and thanks for bringing this to my attention. Doug From owner-freebsd-stable@FreeBSD.ORG Sun May 9 14:47:32 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7354B1065670; Sun, 9 May 2010 14:47:32 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-qy0-f181.google.com (mail-qy0-f181.google.com [209.85.221.181]) by mx1.freebsd.org (Postfix) with ESMTP id 159668FC1D; Sun, 9 May 2010 14:47:31 +0000 (UTC) Received: by qyk11 with SMTP id 11so4163023qyk.13 for ; Sun, 09 May 2010 07:47:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:subject:x-enigmail-version:content-type :content-transfer-encoding; bh=AxQqbYY7CmqHl/3XV8IKGYTDUd6/RygdhgdBiOSRZ94=; b=QkAvKfLBFCpSNa2FWSrxjJGo0JLoPsO7vqS9Mzv1i0mIB0Ttc2raV1voAmIf3D/2Sz 8knOPSJJWevQ4ir95Y7J6YQ+UTwUyhz5E0GJkpSLSG6+Efzi5nJcL6pzDEuBVCntJq3a bOcNjSoN52dIb62rOq/88KYcWmhvbOGUyu1+o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :x-enigmail-version:content-type:content-transfer-encoding; b=yCIH35me2Q5CREaAzoM90OgrEuiZ/QhuNzCl/ImedgGb4YtfW9KQAVtpNlAIAB5Yuu EFRvauyDkVt7/64TBQuT9WZ03+cyYsvJMK+L2DtmH1A48aoUAQgvZdbz2JXOyyfHI0hd ED2y/yLbBBjJig9ZQDdfQajeZZZPXnaHVR49U= Received: by 10.229.217.206 with SMTP id hn14mr2036936qcb.70.1273416451142; Sun, 09 May 2010 07:47:31 -0700 (PDT) Received: from centel.dataix.local (adsl-99-19-41-129.dsl.klmzmi.sbcglobal.net [99.19.41.129]) by mx.google.com with ESMTPS id g19sm2911132qcq.5.2010.05.09.07.47.29 (version=SSLv3 cipher=RC4-MD5); Sun, 09 May 2010 07:47:30 -0700 (PDT) Sender: "J. Hellenthal" Message-ID: <4BE6CB01.9070505@dataix.net> Date: Sun, 09 May 2010 10:47:29 -0400 From: jhell User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.9) Gecko/20100331 Thunderbird/3.0.4 MIME-Version: 1.0 To: Doug Barton , FreeBSD Stable X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Subject: r207811 rc.subr X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 May 2010 14:47:32 -0000 Hi again Doug, Just another report about rc.subr r207811. Cannot 'resync' ipfilter. Set ipfilter_enable to YES in /etc/rc.conf or use 'one resync' instead of 'resync'. Cannot 'resync' ipfilter. Set ipfilter_enable to YES in /etc/rc.conf or use 'one resync' instead of 'resync'. This happens during boot... This is also on a system that does not have ipfilter, built WITHOUT_IPFILTER=yes. -- jhell From owner-freebsd-stable@FreeBSD.ORG Sun May 9 18:53:17 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 52BC9106566C for ; Sun, 9 May 2010 18:53:17 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by mx1.freebsd.org (Postfix) with ESMTP id DBCA78FC0A for ; Sun, 9 May 2010 18:53:16 +0000 (UTC) Received: (qmail 30073 invoked by uid 399); 9 May 2010 18:53:15 -0000 Received: from localhost (HELO foreign.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 9 May 2010 18:53:15 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4BE70499.8020203@FreeBSD.org> Date: Sun, 09 May 2010 11:53:13 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.9) Gecko/20100330 Thunderbird/3.0.4 MIME-Version: 1.0 To: jhell References: <4BE6CB01.9070505@dataix.net> In-Reply-To: <4BE6CB01.9070505@dataix.net> X-Enigmail-Version: 1.0.1 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD Stable Subject: Re: r207811 rc.subr X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 May 2010 18:53:17 -0000 On 05/09/10 07:47, jhell wrote: > Hi again Doug, > > Just another report about rc.subr r207811. > > Cannot 'resync' ipfilter. Set ipfilter_enable to YES in /etc/rc.conf or > use 'one resync' instead of 'resync'. You need to update ALL of your /etc, including /etc/rc.d/netif. -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ From owner-freebsd-stable@FreeBSD.ORG Mon May 10 01:22:54 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 58A0B1065670; Mon, 10 May 2010 01:22:54 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-yx0-f175.google.com (mail-yx0-f175.google.com [209.85.210.175]) by mx1.freebsd.org (Postfix) with ESMTP id EC8548FC0C; Mon, 10 May 2010 01:22:53 +0000 (UTC) Received: by yxe5 with SMTP id 5so1465437yxe.3 for ; Sun, 09 May 2010 18:22:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=BiKtvRu11jWwG4nsfqnqazyZCj3WIwcss92zYVTr/BU=; b=PsJ4kwL9/yJVL/yqYFTgtqRNULRTv7Txe9jw0sMXKEVKo0ZUsPnE05c3dMV23+OI0e 1XbFdURUu8cEokl1Pueo+h5KG+rOnMzqhfSYg3+4NCUrRMyxVx2dAIBMyMSTeMaIBz5g qPkEmGJGb1oGR6ZZt8z1oG5yVfukeQ0dm0ufk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=cVMUJ7aTHFkVpM6OJM7M80PHx4qh/khs92LNvhelYYBxvKdDi2TDdyyaR4kWdTEObb U7BDU1//rgOq3LLa3YycxIFckSb8UNhyrvsMuDRfDQAsHDHzVQJ6pLUBywYFzut2mJT0 HWNCgC3Uc5C2YFMSpawbPM0MwHQILB45A2Xl0= Received: by 10.231.172.203 with SMTP id m11mr1627560ibz.15.1273454572967; Sun, 09 May 2010 18:22:52 -0700 (PDT) Received: from centel.dataix.local (adsl-99-19-41-129.dsl.klmzmi.sbcglobal.net [99.19.41.129]) by mx.google.com with ESMTPS id bh40sm1411578ibb.12.2010.05.09.18.22.51 (version=SSLv3 cipher=RC4-MD5); Sun, 09 May 2010 18:22:52 -0700 (PDT) Sender: "J. Hellenthal" Message-ID: <4BE75FEC.5090800@dataix.net> Date: Sun, 09 May 2010 21:22:52 -0400 From: jhell User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.9) Gecko/20100331 Thunderbird/3.0.4 MIME-Version: 1.0 To: Doug Barton References: <4BE6CB01.9070505@dataix.net> <4BE70499.8020203@FreeBSD.org> In-Reply-To: <4BE70499.8020203@FreeBSD.org> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD Stable Subject: Re: r207811 rc.subr X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 May 2010 01:22:54 -0000 On 05/09/2010 14:53, Doug Barton wrote: > On 05/09/10 07:47, jhell wrote: >> Hi again Doug, >> >> Just another report about rc.subr r207811. >> >> Cannot 'resync' ipfilter. Set ipfilter_enable to YES in /etc/rc.conf or >> use 'one resync' instead of 'resync'. > > You need to update ALL of your /etc, including /etc/rc.d/netif. > Woh sorry, at some point I lost track of the modifications and missed a couple. Thanks for clearing that up for me Doug. -- jhell From owner-freebsd-stable@FreeBSD.ORG Mon May 10 02:21:45 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1B7DE106566B for ; Mon, 10 May 2010 02:21:45 +0000 (UTC) (envelope-from joji@eskimo.com) Received: from ultra7.eskimo.com (ultra7.eskimo.com [204.122.16.70]) by mx1.freebsd.org (Postfix) with ESMTP id D5F3E8FC08 for ; Mon, 10 May 2010 02:21:44 +0000 (UTC) Received: from shell.eskimo.com (root@shell.eskimo.com [204.122.16.72]) by ultra7.eskimo.com (8.14.0/8.14.3) with ESMTP id o4A24xBo032472 for ; Sun, 9 May 2010 19:04:59 -0700 Received: from shell.eskimo.com (joji@localhost [127.0.0.1]) by shell.eskimo.com (8.14.3/8.14.3) with ESMTP id o4A253Kd023998 for ; Sun, 9 May 2010 19:05:03 -0700 Received: (from joji@localhost) by shell.eskimo.com (8.14.3/8.12.10/Submit) id o4A253TD023997 for freebsd-stable@freebsd.org; Sun, 9 May 2010 19:05:03 -0700 Date: Sun, 9 May 2010 19:05:03 -0700 From: Joseph Olatt To: freebsd-stable@freebsd.org Message-ID: <20100510020503.GA23941@shell.eskimo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.2i Subject: FreeBSD Release 8.0 floppy images X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 May 2010 02:21:45 -0000 Hi, Are floppy images no longer supplied with FreeBSD 8? The folling link [1] in the Handbook: ftp://ftp.FreeBSD.org/pub/FreeBSD/releases/i386/8.0-RELEASE/floppies/ results in the following error: 550 /pub/FreeBSD/releases/i386/8.0-RELEASE/floppies/: No such file or directory regards, joseph [1]: http://www.freebsd.org/doc/en/books/handbook/install-pre.html#INSTALL-FLOPPIES From owner-freebsd-stable@FreeBSD.ORG Mon May 10 03:08:24 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id ACCF71065675 for ; Mon, 10 May 2010 03:08:24 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 4265B8FC1A for ; Mon, 10 May 2010 03:08:23 +0000 (UTC) Received: by fxm15 with SMTP id 15so2424119fxm.13 for ; Sun, 09 May 2010 20:08:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=LgCUFZEfo5MLqlJyTo/4wcJt4f2Mbal8V44LkzOx7qI=; b=F/qOVuWLnPqHoRKl20A0BmdzqPEeTZaCrLA+CXUUk1aLRhHS1xCw9KCOEUoKahkZC7 VKHF7OnlYHikBkagcKuZqRWSktCllunfMdbGBXIqSHOi486/uISHlvMYOu8u42kgbD5n IKwYHBJsP8iXxFNc/PodCXkTGsDbObqB6nu+U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=MIfzdzQw52DWAfx58wl7uEfnieIkYJfm53uylOahJFugVyqWtOVIf2kKgW71ZDpAma jx+0Xk6Ki7YvyotphuaLWPPRYdVuZbRK2W2JUS3vKxfd10353uSlP+UVMfVVMpT4HgS/ UDPwFKcpJ/2rSE7/cB5jXFPLX/wyTShGncKR4= MIME-Version: 1.0 Received: by 10.102.237.3 with SMTP id k3mr1892394muh.125.1273460902976; Sun, 09 May 2010 20:08:22 -0700 (PDT) Received: by 10.103.214.4 with HTTP; Sun, 9 May 2010 20:08:22 -0700 (PDT) In-Reply-To: <20100510020503.GA23941@shell.eskimo.com> References: <20100510020503.GA23941@shell.eskimo.com> Date: Mon, 10 May 2010 07:08:22 +0400 Message-ID: From: pluknet To: Joseph Olatt Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-stable@freebsd.org Subject: Re: FreeBSD Release 8.0 floppy images X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 May 2010 03:08:24 -0000 On 10 May 2010 06:05, Joseph Olatt wrote: > Hi, > > Are floppy images no longer supplied with FreeBSD 8? > > The folling link [1] in the Handbook: > ftp://ftp.FreeBSD.org/pub/FreeBSD/releases/i386/8.0-RELEASE/floppies/ > > results in the following error: > > 550 /pub/FreeBSD/releases/i386/8.0-RELEASE/floppies/: No such file or directory > As for floppies building, it was turned off intentionally starting from 8.0. See http://svn.freebsd.org/viewvc/base?view=revision&revision=188437 -- wbr, pluknet From owner-freebsd-stable@FreeBSD.ORG Mon May 10 11:17:27 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3BFF8106564A for ; Mon, 10 May 2010 11:17:27 +0000 (UTC) (envelope-from hausen@punkt.de) Received: from kagate.punkt.de (kagate.punkt.de [217.29.33.131]) by mx1.freebsd.org (Postfix) with ESMTP id BF4CD8FC18 for ; Mon, 10 May 2010 11:17:26 +0000 (UTC) Received: from hugo10.ka.punkt.de (hugo10.ka.punkt.de [10.0.0.110]) by gate1.intern.punkt.de with ESMTP id o4ABHOv9040488 for ; Mon, 10 May 2010 13:17:24 +0200 (CEST) Received: from hugo10.ka.punkt.de (localhost [127.0.0.1]) by hugo10.ka.punkt.de (8.14.2/8.14.2) with ESMTP id o4ABHOAk094030 for ; Mon, 10 May 2010 13:17:24 +0200 (CEST) (envelope-from ry93@hugo10.ka.punkt.de) Received: (from ry93@localhost) by hugo10.ka.punkt.de (8.14.2/8.14.2/Submit) id o4ABHO2Q094029 for freebsd-stable@freebsd.org; Mon, 10 May 2010 13:17:24 +0200 (CEST) (envelope-from ry93) Date: Mon, 10 May 2010 13:17:24 +0200 From: "Patrick M. Hausen" To: FreeBSD Stable Mailing List Message-ID: <20100510111724.GD85988@hugo10.ka.punkt.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.5.17 (2007-11-01) Subject: Bypassing boot0/1/2? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 May 2010 11:17:27 -0000 Hi, all, I have two brand new systems on my desk with Adaptec 5404 SAS RAID cards. I booted an install CD from an USB drive and could install on the RAID 10 just finde. Both 7.3 and an 8.0 snapshot from April. Amd64, of course. Now something weird happens when I boot from hard disk. The "boot:" prompt appears to be waiting for me to hit unconditionally. The system does not autoboot by itself. If I install the bootmanager (boot0cfg -B) instead of a standard MBR, the result is the same. The "F1" prompt times out and switches to the next stage, then it's waiting again for me to press a key. When I do that, the audible alarm of the RAID HA goes off and the loading of /boot/loader and the kernel (?) takes "forever" - around five minutes, during which the HA beeps the entire time. Once the FreeBSD boot menu (former "Beastie" menu) appears, everything is silent, again, and the rest of the boot process continues normally. The system, once booted, is running perfectly fine. I tried to replace the first stages of the FreeBSD boot loader with Grub, loading /boot/loader as the next stage - same result. I can boot any current FreeBSD from any external device, normally - but not from the internal RAID volume. As I see this, I could try to skip as much as possible of the standard boot process by using a "dangerously dedicated" disk if that is still supported? Would there be a chance that this might help? We used dedicated disks for years with FreeBSD 2, 3 and 4, but stopped using them around 5, IIRC. Or, if all else fails, I could boot everything up to /boot/loader from a flash module and direct it to the kernel on hard disk. Not pretty, but probably workable. Any suggestions are very welcome. Thanks, Patrick -- punkt.de GmbH * Kaiserallee 13a * 76133 Karlsruhe Tel. 0721 9109 0 * Fax 0721 9109 100 info@punkt.de http://www.punkt.de Gf: Jürgen Egeling AG Mannheim 108285 From owner-freebsd-stable@FreeBSD.ORG Mon May 10 12:15:05 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 130D6106567B for ; Mon, 10 May 2010 12:15:05 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id BCA448FC1E for ; Mon, 10 May 2010 12:15:04 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1OBRt1-0007xa-4c for freebsd-stable@freebsd.org; Mon, 10 May 2010 14:15:03 +0200 Received: from cpe-24-210-63-182.columbus.res.rr.com ([24.210.63.182]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 10 May 2010 14:15:03 +0200 Received: from dsamms by cpe-24-210-63-182.columbus.res.rr.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 10 May 2010 14:15:03 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org connect(): No such file or directory From: David Samms Date: Mon, 10 May 2010 08:14:53 -0400 Lines: 15 Message-ID: References: <4BE6512B.5030202@dataix.net> <4BE67173.4000403@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: cpe-24-210-63-182.columbus.res.rr.com User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.9) Gecko/20100331 Thunderbird/3.0.4 In-Reply-To: <4BE67173.4000403@FreeBSD.org> Subject: Re: MFC of r206686 r179870 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 May 2010 12:15:05 -0000 On 05/09/10 04:25, Doug Barton wrote: > On 05/08/10 23:07, jhell wrote: >> The following two commits to stable/7 may be responsible for dirtying >> the console with messages pertaining to setting values in rc.conf. > > I found the problem, and just committed r207811 which should fix it. The > issue was only relevant to booting (which I did not test) as opposed to > running rc.d scripts on the command line (which I did). > > Sorry for the hassle, and thanks for bringing this to my attention. > > > Doug Doug, your the best! Thanks for all the work you do for FreeBSD. From owner-freebsd-stable@FreeBSD.ORG Mon May 10 15:02:22 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id ABEAD106566C for ; Mon, 10 May 2010 15:02:22 +0000 (UTC) (envelope-from royce.williams@gmail.com) Received: from mail-gw0-f54.google.com (mail-gw0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id 5F60C8FC08 for ; Mon, 10 May 2010 15:02:22 +0000 (UTC) Received: by gwj15 with SMTP id 15so582015gwj.13 for ; Mon, 10 May 2010 08:02:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:content-type; bh=4C8ZU/pRCqTR2RWEA8GJ4/tbYW6SAbCiOPh5AbGr1a4=; b=qqN53YawbM/LoZ/WhgU5V7ymqwBfEbEr1pemwnQITBLUfgA8aWYw4MPqxY2mbDJ1BQ tsHP0FpeDG8SAIDvZnY7GuupcGSxhi254xT+NmfYN3CYtMtVNibGETs3xoxVtn6eDCNs dhjoKiTzAHJCINsNnHaoc8q3uY5UuooSeftck= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; b=iTJgdcmYFuCE3oNo4TSwMotkrVug3ojkOHdpDzeiv4srMUhxoli4Jlbj0/Ua10JL4I XSkqndfv9hvwaYDrfWix4pHa6bt8s2naxT5HGqLjHGaysa0ETw3ltHDpsXsJdd/7qJN7 LecWZ/A8IoBRbpEYvRtojzzU6N3A4zYK2EXIg= Received: by 10.150.14.20 with SMTP id 20mr6947608ybn.440.1273503740845; Mon, 10 May 2010 08:02:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.190.4 with HTTP; Mon, 10 May 2010 08:01:59 -0700 (PDT) In-Reply-To: References: <20100510020503.GA23941@shell.eskimo.com> From: Royce Williams Date: Mon, 10 May 2010 07:01:59 -0800 Message-ID: To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: FreeBSD Release 8.0 floppy images X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 May 2010 15:02:22 -0000 On Sun, May 9, 2010 at 7:08 PM, pluknet wrote: > On 10 May 2010 06:05, Joseph Olatt wrote: > > As for floppies building, it was turned off intentionally starting from 8.0. > See http://svn.freebsd.org/viewvc/base?view=revision&revision=188437 I'm guessing that this because of resource constraints (getting everything to fit)? I assume that if it was just that folks weren't using them, it would be easy to keep them. A few data points: * We have some older Dell DRAC systems that don't support PXE very well, but do support loading remote floppy images. * There are still folks in countries where computer hardware doesn't get refreshed as quickly as in the U.S., and floppies are still a viable install option. * When I'm not at $WORK, one of my hobbies is restoring old computers (Whistle Interjets, Qubes, etc.) the way that some people restore old cars -- with the twist of using modern OSes. Of course, they can run NetBSD :-), but freebsd-update is a killer feature for keeping slower systems patched. Of course, some of them don't support floppies, either. In practice, once the initial install is done, floppies aren't needed. And we can always pop out the drive, and put it in a system that supports CD booting and install from there. But it's more work. :-) Royce From owner-freebsd-stable@FreeBSD.ORG Mon May 10 15:55:12 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 19D30106566B for ; Mon, 10 May 2010 15:55:12 +0000 (UTC) (envelope-from mandrews@bit0.com) Received: from magnum.bit0.com (magnum.bit0.com [207.246.88.226]) by mx1.freebsd.org (Postfix) with ESMTP id D8ACB8FC19 for ; Mon, 10 May 2010 15:55:11 +0000 (UTC) Received: from magnum.bit0.com (localhost [127.0.0.1]) by magnum.bit0.com (Postfix) with ESMTP id D26271105B for ; Mon, 10 May 2010 11:55:10 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=bit0.com; h=message-id :date:from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; s=boogity; bh=uDTXi9kma 9/YBys41W7fWNQlAbk6ZN99YCQOssth4QY=; b=krU0RqHnuNlTk7nqnteLpQqkI bLcs2EMq5SFrqR7UzceNV1bmxfOFsAtImxR4THnlN8rvqRp5Us/P1BB9OwiSwrpN oxwGiftj5vTXAEZrnGzviXWPxpcWUarIyHPZnWlv1XWQN1uUs/AE6OtG6XgS39UJ tofzxWLKN4uSMYs1tk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=bit0.com; h=message-id:date :from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=boogity; b=xGZ lgEAdfeATV6V7D8jtivUda9r0qJYNzSZPqJsgg8fa1RfsoAoCHm0sEpidZQo7dR9 dVVOwUlqzneFTleOTfCgy8sHQPvquvrrsNpf4ywOGGoDgPvShAvu9VCetJ+KCcIz WTtABVuhJ5zxHwP4Q/QULVgVfy9lnSzYqHGfeh3Y= Received: from millenniumforce.int.bit0.com (207-246-87-56.dsl.static.blueone.net [207.246.87.56]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by magnum.bit0.com (Postfix) with ESMTPSA id 845AE11058 for ; Mon, 10 May 2010 11:55:10 -0400 (EDT) Message-ID: <4BE82C5D.1080806@bit0.com> Date: Mon, 10 May 2010 11:55:09 -0400 From: Mike Andrews User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <4BDEA86E.3050109@zirakzigil.org> <20100503110100.GA93137@icarus.home.lan> <4BDEC106.3040807@zirakzigil.org> <4BE110E3.8040902@zirakzigil.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Freebsd 8.0 kmem map too small X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 May 2010 15:55:12 -0000 On 5/5/10 11:19 AM, Freddie Cash wrote: > On Tue, May 4, 2010 at 11:32 PM, Giulio Ferro wrote: > >> Giulio Ferro wrote: >> >>> Thanks, I'll try these settings. >>> >>> I'll keep you posted. >>> >> >> Nope, it's happened again... Now I've tried to rise vm.kmem_size to 6G... >> I'm really astounded at how unstable zfs is, it's causing me a lot of >> problem. >> Why isn't it stated in the handbook that zfs isn't up to production yet? >> > > As with everything related to computers, it all depends on your uses. Sorry to semi-hijack this, but... I'm also running into frequent "kmem_map too small" panics on 8-STABLE, such as: panic: kmem_malloc(131072): kmem_map too small: 2023780352 total allocated panic: kmem_malloc(131072): kmem_map too small: 2011525120 total allocated panic: kmem_malloc(114688): kmem_map too small: 1849356288 total allocated panic: kmem_malloc(114688): kmem_map too small: 1849356288 total allocated panic: kmem_malloc(114688): kmem_map too small: 1849356288 total allocated panic: kmem_malloc(131072): kmem_map too small: 2020409344 total allocated panic: kmem_malloc(536576): kmem_map too small: 2022957056 total allocated (those are over the course of 3-4 days) On this specific system, it has 32 GB physical memory and has vfs.zfs.arc_max="2G" and vm.kmem_size="64G" in /boot/loader.conf. The latter was added per earlier suggestions on this list, but appears to be ignored as "sysctl vm.kmem_size" returns about 2 GB (2172452864) anyway. Unfortunately I have not yet found a way to reliably reproduce the panic on demand, so it's hard to iteratively narrow down which date the potentially offending commit was on. It happened at least twice overnight, where several memory-intensive jobs run. Backing out to a previous 8-STABLE kernel from March 28 appears (so far) to have stabilized things, so the offending code was likely somewhere between then and May 5 or so. I do have KDB/DDB and serial console on this box, if there's any more info I can give to help troubleshoot other than just a one-month vague date range :) This is happening to more than just one system, but I figure it's easier to troubleshoot memory settings on the 32 GB i7 server instead of the 2 GB Atom one... From owner-freebsd-stable@FreeBSD.ORG Mon May 10 16:03:15 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 75B3A1065674 for ; Mon, 10 May 2010 16:03:15 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta14.westchester.pa.mail.comcast.net (qmta14.westchester.pa.mail.comcast.net [76.96.59.212]) by mx1.freebsd.org (Postfix) with ESMTP id 22DDF8FC17 for ; Mon, 10 May 2010 16:03:14 +0000 (UTC) Received: from omta17.westchester.pa.mail.comcast.net ([76.96.62.89]) by qmta14.westchester.pa.mail.comcast.net with comcast id FnJo1e0031vXlb85Es3FvS; Mon, 10 May 2010 16:03:15 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta17.westchester.pa.mail.comcast.net with comcast id Fs3E1e0013S48mS3ds3E2T; Mon, 10 May 2010 16:03:15 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 8EE919B425; Mon, 10 May 2010 09:03:12 -0700 (PDT) Date: Mon, 10 May 2010 09:03:12 -0700 From: Jeremy Chadwick To: Mike Andrews Message-ID: <20100510160312.GA62178@icarus.home.lan> References: <4BDEA86E.3050109@zirakzigil.org> <20100503110100.GA93137@icarus.home.lan> <4BDEC106.3040807@zirakzigil.org> <4BE110E3.8040902@zirakzigil.org> <4BE82C5D.1080806@bit0.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4BE82C5D.1080806@bit0.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-stable@freebsd.org Subject: Re: Freebsd 8.0 kmem map too small X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 May 2010 16:03:15 -0000 On Mon, May 10, 2010 at 11:55:09AM -0400, Mike Andrews wrote: > Sorry to semi-hijack this, but... I'm also running into frequent > "kmem_map too small" panics on 8-STABLE, such as: > > panic: kmem_malloc(131072): kmem_map too small: 2023780352 total allocated > panic: kmem_malloc(131072): kmem_map too small: 2011525120 total allocated > panic: kmem_malloc(114688): kmem_map too small: 1849356288 total allocated > panic: kmem_malloc(114688): kmem_map too small: 1849356288 total allocated > panic: kmem_malloc(114688): kmem_map too small: 1849356288 total allocated > panic: kmem_malloc(131072): kmem_map too small: 2020409344 total allocated > panic: kmem_malloc(536576): kmem_map too small: 2022957056 total allocated > > (those are over the course of 3-4 days) > > On this specific system, it has 32 GB physical memory and has > vfs.zfs.arc_max="2G" and vm.kmem_size="64G" in /boot/loader.conf. > The latter was added per earlier suggestions on this list, but > appears to be ignored as "sysctl vm.kmem_size" returns about 2 GB > (2172452864) anyway. > > ... In your case, vm.kmem_size being stuck at 2GB (despite you setting it larger) is the problem. A workaround would be for you to set vfs.zfs.arc_max to something smaller, such as 1G or 512M. Can you please provide output from the following 5 commands: uname -a sysctl vm.kmem_size_min vm.kmem_size_max vm.kmem_size vm.kmem_size_scale sysctl hw.physmem hw.usermem hw.realmem sysctl hw.machine_arch sysctl hw.pagesize hw.pagesizes hw.availpages Thanks. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Mon May 10 16:03:38 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 56B8A1065782 for ; Mon, 10 May 2010 16:03:38 +0000 (UTC) (envelope-from artemb@gmail.com) Received: from mail-px0-f182.google.com (mail-px0-f182.google.com [209.85.212.182]) by mx1.freebsd.org (Postfix) with ESMTP id 263428FC17 for ; Mon, 10 May 2010 16:03:37 +0000 (UTC) Received: by pxi20 with SMTP id 20so1836764pxi.13 for ; Mon, 10 May 2010 09:03:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=lZ6fHs4ITlV3hIE6HEUwuRaW9xKFnHLduSmfY2kJGhY=; b=dyKoQDnOgNizPfX+IgMd6sbVL7+KoVo3ezeqPoTSM2CCM3xiZWDS/e+nl/jc63v7z2 y9NuYwJV9MM7pcspA74UOKUb1fWAv7TMpzYJIQBeOj3V4EHZ4CeZ8RowLKo5sWhRYcoO SnCeCqqUqUjj6gGCwrrrX0Qfr9SfBeVDoQhzk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=EFZCru21jrgWhTNcM5+BBxfSNVuaSkQBHoqwZhw/sc8eqgiuR3pOPs4/r3p7h2fbsu 9TMljUxkUkEXQXG9Ap/iCzz05bLPbw31xAqzVhBzlgBCgCFAMtBDFojUTx+ornmXJ5J2 R0XzM7qIfY78MEGqe+sRn8mGCQymVdex7Qigo= MIME-Version: 1.0 Received: by 10.141.106.21 with SMTP id i21mr2811357rvm.40.1273507417619; Mon, 10 May 2010 09:03:37 -0700 (PDT) Sender: artemb@gmail.com Received: by 10.141.40.4 with HTTP; Mon, 10 May 2010 09:03:37 -0700 (PDT) In-Reply-To: <4BE82C5D.1080806@bit0.com> References: <4BDEA86E.3050109@zirakzigil.org> <20100503110100.GA93137@icarus.home.lan> <4BDEC106.3040807@zirakzigil.org> <4BE110E3.8040902@zirakzigil.org> <4BE82C5D.1080806@bit0.com> Date: Mon, 10 May 2010 09:03:37 -0700 X-Google-Sender-Auth: 445fac100e68265b Message-ID: From: Artem Belevich To: Mike Andrews Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable@freebsd.org Subject: Re: Freebsd 8.0 kmem map too small X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 May 2010 16:03:38 -0000 > On this specific system, it has 32 GB physical memory and has > vfs.zfs.arc_max=3D"2G" and vm.kmem_size=3D"64G" in /boot/loader.conf. =A0= The > latter was added per earlier suggestions on this list, but appears to be > ignored as "sysctl vm.kmem_size" returns about 2 GB (2172452864) anyway. Set vm.kmem_size to slightly below 2x the amount of physical memory your kernel *sees* (sysctl hw.physmem) . Chances are that real amount of physical memory available to kernel is slightly below 32G so your tunable is ignored. My guess would be that vm.kmem_size=3D63G would work much better. --Artem On Mon, May 10, 2010 at 8:55 AM, Mike Andrews wrote: > On 5/5/10 11:19 AM, Freddie Cash wrote: >> >> On Tue, May 4, 2010 at 11:32 PM, Giulio Ferro >> =A0wrote: >> >>> Giulio Ferro wrote: >>> >>>> Thanks, I'll try these settings. >>>> >>>> I'll keep you posted. >>>> >>> >>> Nope, it's happened again... Now I've tried to rise vm.kmem_size to 6G.= .. >>> I'm really astounded at how unstable zfs is, it's causing me a lot of >>> problem. >>> Why isn't it stated in the handbook that zfs isn't up to production yet= ? >>> >> >> As with everything related to computers, it all depends on your uses. > > Sorry to semi-hijack this, but... =A0I'm also running into frequent "kmem= _map > too small" panics on 8-STABLE, such as: > > panic: kmem_malloc(131072): kmem_map too small: 2023780352 total allocate= d > panic: kmem_malloc(131072): kmem_map too small: 2011525120 total allocate= d > panic: kmem_malloc(114688): kmem_map too small: 1849356288 total allocate= d > panic: kmem_malloc(114688): kmem_map too small: 1849356288 total allocate= d > panic: kmem_malloc(114688): kmem_map too small: 1849356288 total allocate= d > panic: kmem_malloc(131072): kmem_map too small: 2020409344 total allocate= d > panic: kmem_malloc(536576): kmem_map too small: 2022957056 total allocate= d > > (those are over the course of 3-4 days) > > On this specific system, it has 32 GB physical memory and has > vfs.zfs.arc_max=3D"2G" and vm.kmem_size=3D"64G" in /boot/loader.conf. =A0= The > latter was added per earlier suggestions on this list, but appears to be > ignored as "sysctl vm.kmem_size" returns about 2 GB (2172452864) anyway. > > Unfortunately I have not yet found a way to reliably reproduce the panic = on > demand, so it's hard to iteratively narrow down which date the potentiall= y > offending commit was on. =A0It happened at least twice overnight, where > several memory-intensive jobs run. =A0Backing out to a previous 8-STABLE > kernel from March 28 appears (so far) to have stabilized things, so the > offending code was likely somewhere between then and May 5 or so. =A0I do= have > KDB/DDB and serial console on this box, if there's any more info I can gi= ve > to help troubleshoot other than just a one-month vague date range :) > > This is happening to more than just one system, but I figure it's easier = to > troubleshoot memory settings on the 32 GB i7 server instead of the 2 GB A= tom > one... > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > From owner-freebsd-stable@FreeBSD.ORG Mon May 10 16:36:26 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1D2B51065673 for ; Mon, 10 May 2010 16:36:26 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from tower.berklix.org (tower.berklix.org [83.236.223.114]) by mx1.freebsd.org (Postfix) with ESMTP id 9BAD88FC1B for ; Mon, 10 May 2010 16:36:25 +0000 (UTC) Received: from park.js.berklix.net (p549A5DA3.dip.t-dialin.net [84.154.93.163]) (authenticated bits=0) by tower.berklix.org (8.14.2/8.14.2) with ESMTP id o4AGaNlL085840; Mon, 10 May 2010 16:36:23 GMT (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (fire.js.berklix.net [192.168.91.41]) by park.js.berklix.net (8.13.8/8.13.8) with ESMTP id o4AGaC3Z062793; Mon, 10 May 2010 18:36:12 +0200 (CEST) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (localhost [127.0.0.1]) by fire.js.berklix.net (8.14.3/8.14.3) with ESMTP id o4AGa2pF053050; Mon, 10 May 2010 18:36:07 +0200 (CEST) (envelope-from jhs@fire.js.berklix.net) Message-Id: <201005101636.o4AGa2pF053050@fire.js.berklix.net> To: Royce Williams From: "Julian H. Stacey" Organization: http://www.berklix.com BSD Unix Linux Consultancy, Munich Germany User-agent: EXMH on FreeBSD http://www.berklix.com/free/ X-URL: http://www.berklix.com In-reply-to: Your message "Mon, 10 May 2010 07:01:59 -0800." Date: Mon, 10 May 2010 18:36:02 +0200 Sender: jhs@berklix.com Cc: freebsd-stable@freebsd.org, kensmith@freebsd.org Subject: Re: FreeBSD Release 8.0 floppy images X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 May 2010 16:36:26 -0000 > > As for floppies building, it was turned off intentionally starting from 8.0. > > See http://svn.freebsd.org/viewvc/base?view=revision&revision=188437 I looked earlier at URL above earlier, but just kensmith (CC added) Log Message: Turn off the building of boot floppies for amd64/i386. No reason in there, why or URL pointer to a list discussion. > I'm guessing that this because of resource constraints (getting > everything to fit)? I assume that if it was just that folks weren't > using them, it would be easy to keep them. A few data points: Seconded. Ken, I'd suggest it would be good to commit & post a comment why removed. It will later affect rescue capability of some older servers when they get upgraded, (I guess many/most legacy production servers still are 7.*, at least till 8.1 comes out). Thanks Cheers, Julian -- Julian Stacey: BSD Unix Linux C Sys Eng Consultants Munich http://berklix.com Mail plain text, Not HTML quoted-printable Base64 http://www.asciiribbon.org From owner-freebsd-stable@FreeBSD.ORG Mon May 10 17:00:24 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9EEB9106566B for ; Mon, 10 May 2010 17:00:24 +0000 (UTC) (envelope-from korvus@comcast.net) Received: from qmta15.emeryville.ca.mail.comcast.net (qmta15.emeryville.ca.mail.comcast.net [76.96.27.228]) by mx1.freebsd.org (Postfix) with ESMTP id 856838FC14 for ; Mon, 10 May 2010 17:00:24 +0000 (UTC) Received: from omta06.emeryville.ca.mail.comcast.net ([76.96.30.51]) by qmta15.emeryville.ca.mail.comcast.net with comcast id FoLU1e00316AWCUAFt0Rvs; Mon, 10 May 2010 17:00:25 +0000 Received: from [192.168.2.164] ([206.210.89.202]) by omta06.emeryville.ca.mail.comcast.net with comcast id Ft0D1e0044Mx3R28St0Fg2; Mon, 10 May 2010 17:00:23 +0000 Message-ID: <4BE83B9B.5030209@comcast.net> Date: Mon, 10 May 2010 13:00:11 -0400 From: Steve Polyack User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.7) Gecko/20100311 Thunderbird/3.0.1 MIME-Version: 1.0 To: Mike Andrews References: <4BDEA86E.3050109@zirakzigil.org> <20100503110100.GA93137@icarus.home.lan> <4BDEC106.3040807@zirakzigil.org> <4BE110E3.8040902@zirakzigil.org> <4BE82C5D.1080806@bit0.com> In-Reply-To: <4BE82C5D.1080806@bit0.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: Freebsd 8.0 kmem map too small X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 May 2010 17:00:24 -0000 On 05/10/10 11:55, Mike Andrews wrote: > On 5/5/10 11:19 AM, Freddie Cash wrote: >> On Tue, May 4, 2010 at 11:32 PM, Giulio Ferro >> wrote: >> >>> Giulio Ferro wrote: >>> >>>> Thanks, I'll try these settings. >>>> >>>> I'll keep you posted. >>>> >>> >>> Nope, it's happened again... Now I've tried to rise vm.kmem_size to >>> 6G... >>> I'm really astounded at how unstable zfs is, it's causing me a lot of >>> problem. >>> Why isn't it stated in the handbook that zfs isn't up to production >>> yet? >>> >> >> As with everything related to computers, it all depends on your uses. > > Sorry to semi-hijack this, but... I'm also running into frequent > "kmem_map too small" panics on 8-STABLE, such as: > > panic: kmem_malloc(131072): kmem_map too small: 2023780352 total > allocated > panic: kmem_malloc(131072): kmem_map too small: 2011525120 total > allocated > panic: kmem_malloc(114688): kmem_map too small: 1849356288 total > allocated > panic: kmem_malloc(114688): kmem_map too small: 1849356288 total > allocated > panic: kmem_malloc(114688): kmem_map too small: 1849356288 total > allocated > panic: kmem_malloc(131072): kmem_map too small: 2020409344 total > allocated > panic: kmem_malloc(536576): kmem_map too small: 2022957056 total > allocated > > (those are over the course of 3-4 days) > > On this specific system, it has 32 GB physical memory and has > vfs.zfs.arc_max="2G" and vm.kmem_size="64G" in /boot/loader.conf. The > latter was added per earlier suggestions on this list, but appears to > be ignored as "sysctl vm.kmem_size" returns about 2 GB (2172452864) > anyway. > > As Artem stated in another reply, you will need to set vm.kmem_size slightly under 2x the physical memory. The kernel will default to 2GB if you pass this limit. 1.5x physical memory size should be sufficient, so try "48G" and verify that it gets set correctly on the next boot. From owner-freebsd-stable@FreeBSD.ORG Mon May 10 17:30:36 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 279DB106564A for ; Mon, 10 May 2010 17:30:36 +0000 (UTC) (envelope-from slackbie@gmail.com) Received: from mail-px0-f182.google.com (mail-px0-f182.google.com [209.85.212.182]) by mx1.freebsd.org (Postfix) with ESMTP id F11298FC16 for ; Mon, 10 May 2010 17:30:35 +0000 (UTC) Received: by pxi20 with SMTP id 20so1884171pxi.13 for ; Mon, 10 May 2010 10:30:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=mRPDyh1fwN5Om5EarubciAgTAcfnZgitdayXxw7qBho=; b=o9PWlX+OcmTHor3rzyyMDiz9WwKeeJHRtNPKfSMnTsIPUeFoL8pCfOmizzHFuatXqM d5/FhK2MiRWEDuEivSDdSZtSUNTEuBAre8w3T4UTKyM8t2jAX3uy74yTFvQMtJyW4zvh vOQwc+yNXdC8nDPad+IXMZ0V1MoMi+3s+C2Yg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=t/3bFk7E6XlEiovQbv04ebMSY0IzVYo44bzzcpFMMTUcF9kZ+SS8ZoXuSR2nf2tF0j zOue8ZY+0ubt5Ech3/AfLBerK4Eb09tSjb6Fxb/wXRYPyPxQ/prEptQkcoRnY7WAAHE7 T06znBRaWYId1fYd1moJ77YBTA3BBz2cUO5Ks= MIME-Version: 1.0 Received: by 10.115.84.4 with SMTP id m4mr3383678wal.222.1273512635334; Mon, 10 May 2010 10:30:35 -0700 (PDT) Received: by 10.114.25.20 with HTTP; Mon, 10 May 2010 10:30:35 -0700 (PDT) In-Reply-To: References: Date: Tue, 11 May 2010 00:30:35 +0700 Message-ID: From: "~Lst" To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: vlan and openbgpd X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 May 2010 17:30:36 -0000 Hi, There might be no one had same experience with me, or should I ask to another (freebsd-net@) or..? On Sun, May 9, 2010 at 5:28 AM, ~Lst wrote: > Hi, > > I had an experienced in FreeBSD 8.0 (not with FreeBSD 7.3), that if we > removed any vlan in any interfaces it makes sessions in openbgpd with > connect but never get established. > The logs only said like this, ``received notification: HoldTimer > expired, unknown subcode 0'' and ``socket error: Connection refused'' > and ``socket error: No route to host''. > When I tried to ping to the neighbor, it worked fine. I tried to > restart daemon openbgpd but sessions never established, then I should > to reboot our router and the session was =A0established. > > Does anyone have same experienced with me ? > Rgds, -- ~Lst From owner-freebsd-stable@FreeBSD.ORG Mon May 10 17:39:20 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9352E106566B; Mon, 10 May 2010 17:39:20 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: from mail.soaustin.net (lefty.soaustin.net [66.135.55.46]) by mx1.freebsd.org (Postfix) with ESMTP id 755FC8FC14; Mon, 10 May 2010 17:39:20 +0000 (UTC) Received: by mail.soaustin.net (Postfix, from userid 502) id C458C8C07D; Mon, 10 May 2010 12:39:19 -0500 (CDT) Date: Mon, 10 May 2010 12:39:19 -0500 From: Mark Linimon To: "Julian H. Stacey" Message-ID: <20100510173919.GA11737@lonesome.com> References: <201005101636.o4AGa2pF053050@fire.js.berklix.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201005101636.o4AGa2pF053050@fire.js.berklix.net> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: freebsd-stable@freebsd.org, Royce Williams , kensmith@freebsd.org Subject: Re: FreeBSD Release 8.0 floppy images X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 May 2010 17:39:20 -0000 You can still build them. They just won't be built by default. mcl From owner-freebsd-stable@FreeBSD.ORG Mon May 10 18:43:42 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5A897106566C for ; Mon, 10 May 2010 18:43:42 +0000 (UTC) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by mx1.freebsd.org (Postfix) with ESMTP id 201138FC1D for ; Mon, 10 May 2010 18:43:41 +0000 (UTC) Received: from mdt-xp.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.14.3/8.14.3) with ESMTP id o4AIhdA0061913 for ; Mon, 10 May 2010 14:43:40 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <201005101843.o4AIhdA0061913@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 10 May 2010 14:43:32 -0400 To: freebsd-stable@freebsd.org From: Mike Tancsa Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: sockstat / netstat output 8.x vs 7.x X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 May 2010 18:43:42 -0000 I noticed that apache on RELENG_8 and RELENG_7 shows up with output I cant seem to understand from sockstat -l and netstat -naW On RELENG_7, sockstat -l makes sense to me .... www httpd 83005 4 tcp4 *:443 *:* www httpd 82217 3 tcp4 *:80 *:* www httpd 82217 4 tcp4 *:443 *:* www httpd 38942 3 tcp4 *:80 *:* www httpd 38942 4 tcp4 *:443 *:* root httpd 1169 3 tcp4 *:80 *:* root httpd 1169 4 tcp4 *:443 *:* various processes listening on all bound IP addresses on ports 80 and 443. On RELENG_8 however, it shows up with an extra entry (at the end) www httpd 29005 4 tcp4 *:* *:* www httpd 29004 3 tcp4 6 *:80 *:* www httpd 29004 4 tcp4 *:* *:* www httpd 29003 3 tcp4 6 *:80 *:* www httpd 29003 4 tcp4 *:* *:* www httpd 66731 3 tcp4 6 *:80 *:* www httpd 66731 4 tcp4 *:* *:* root httpd 72197 3 tcp4 6 *:80 *:* root httpd 72197 4 tcp4 *:* *:* *:80 makes sense to me... process is listening on all IPs for port 80. What does *:* mean then ? Netstat gives a slightly different version of it Active Internet connections (including servers) Proto Recv-Q Send-Q Local Address Foreign Address (state) tcp4 0 0 *.1984 *.* LISTEN tcp4 0 0 *.* *.* CLOSED tcp46 0 0 *.80 *.* LISTEN state closed ? ---Mike -------------------------------------------------------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet since 1994 www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike From owner-freebsd-stable@FreeBSD.ORG Mon May 10 20:45:10 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D5FB1106566B for ; Mon, 10 May 2010 20:45:10 +0000 (UTC) (envelope-from mandrews@bit0.com) Received: from magnum.bit0.com (magnum.bit0.com [207.246.88.226]) by mx1.freebsd.org (Postfix) with ESMTP id AB4E08FC14 for ; Mon, 10 May 2010 20:45:10 +0000 (UTC) Received: from magnum.int.bit0.com (localhost [127.0.0.1]) by magnum.bit0.com (Postfix) with ESMTP id 13655114B1; Mon, 10 May 2010 16:45:10 -0400 (EDT) X-Virus-Scanned: amavisd-new at bit0.com Received: from magnum.bit0.com ([127.0.0.1]) by magnum.int.bit0.com (magnum.int.bit0.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7eo0zH5WuSkO; Mon, 10 May 2010 16:45:05 -0400 (EDT) Received: from beast.int.bit0.com (beast.int.bit0.com [172.27.0.2]) by magnum.bit0.com (Postfix) with ESMTP; Mon, 10 May 2010 16:45:05 -0400 (EDT) Date: Mon, 10 May 2010 16:45:05 -0400 (EDT) From: Mike Andrews X-X-Sender: mandrews@beast.int.bit0.com To: Steve Polyack In-Reply-To: <4BE83B9B.5030209@comcast.net> Message-ID: References: <4BDEA86E.3050109@zirakzigil.org> <20100503110100.GA93137@icarus.home.lan> <4BDEC106.3040807@zirakzigil.org> <4BE110E3.8040902@zirakzigil.org> <4BE82C5D.1080806@bit0.com> <4BE83B9B.5030209@comcast.net> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-stable@freebsd.org Subject: Re: Freebsd 8.0 kmem map too small X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 May 2010 20:45:10 -0000 On Mon, 10 May 2010, Steve Polyack wrote: > On 05/10/10 11:55, Mike Andrews wrote: >> On 5/5/10 11:19 AM, Freddie Cash wrote: >>> On Tue, May 4, 2010 at 11:32 PM, Giulio Ferro >>> wrote: >>> >>>> Giulio Ferro wrote: >>>> >>>>> Thanks, I'll try these settings. >>>>> >>>>> I'll keep you posted. >>>>> >>>> >>>> Nope, it's happened again... Now I've tried to rise vm.kmem_size to 6G... >>>> I'm really astounded at how unstable zfs is, it's causing me a lot of >>>> problem. >>>> Why isn't it stated in the handbook that zfs isn't up to production yet? >>>> >>> >>> As with everything related to computers, it all depends on your uses. >> >> Sorry to semi-hijack this, but... I'm also running into frequent "kmem_map >> too small" panics on 8-STABLE, such as: >> >> panic: kmem_malloc(131072): kmem_map too small: 2023780352 total allocated >> panic: kmem_malloc(131072): kmem_map too small: 2011525120 total allocated >> panic: kmem_malloc(114688): kmem_map too small: 1849356288 total allocated >> panic: kmem_malloc(114688): kmem_map too small: 1849356288 total allocated >> panic: kmem_malloc(114688): kmem_map too small: 1849356288 total allocated >> panic: kmem_malloc(131072): kmem_map too small: 2020409344 total allocated >> panic: kmem_malloc(536576): kmem_map too small: 2022957056 total allocated >> >> (those are over the course of 3-4 days) >> >> On this specific system, it has 32 GB physical memory and has >> vfs.zfs.arc_max="2G" and vm.kmem_size="64G" in /boot/loader.conf. The >> latter was added per earlier suggestions on this list, but appears to be >> ignored as "sysctl vm.kmem_size" returns about 2 GB (2172452864) anyway. >> >> > As Artem stated in another reply, you will need to set vm.kmem_size slightly > under 2x the physical memory. The kernel will default to 2GB if you pass > this limit. 1.5x physical memory size should be sufficient, so try "48G" and > verify that it gets set correctly on the next boot. OK, I've got vm.kmem_size set a bit lower and it now accepts it. It's still not clear why this just recently (April?) became necessary to do at all :) Meanwhile, I'll see if things get more stable now... From owner-freebsd-stable@FreeBSD.ORG Mon May 10 20:53:47 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4C0C2106566B for ; Mon, 10 May 2010 20:53:47 +0000 (UTC) (envelope-from artemb@gmail.com) Received: from mail-px0-f182.google.com (mail-px0-f182.google.com [209.85.212.182]) by mx1.freebsd.org (Postfix) with ESMTP id 19D998FC08 for ; Mon, 10 May 2010 20:53:47 +0000 (UTC) Received: by pxi20 with SMTP id 20so1985549pxi.13 for ; Mon, 10 May 2010 13:53:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=3VizkY9PtQH6qEZyvb7l6uNLGIhQm43rQmB0Qz5XzGs=; b=i74doXgZRSRARx+jJDKCWapHdeOh8FykwoTF65OSnYby5jsb9tS23wyWt/2MuY/euN 6VZqlBTja25NXJifxQRqZ2XfTvGK+hkhGS72LR7JFPQWGmTp4lFXd0Nj/u6H+AC2pk8M o0pHbIiUzPF511FpioU8nQA+oMGZKyGpQ6SV4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=vnlk9V7jx+aDDCI0N42KhPRNYKp5oo8Z/eAOaQjmYFZQ1zA6kDw+33Y6Mz5dwdFNU+ 9qgSwdLnymZgvm83X73ckfJnxdBrcIxGWkYgvU0hcQuGYuSfAD1w+eUY7v3x2UHUYWT+ U5mUPA2f/viFE9BweHzB9FuZNZ+Lg4IKRzebM= MIME-Version: 1.0 Received: by 10.140.58.5 with SMTP id g5mr3079095rva.157.1273524826579; Mon, 10 May 2010 13:53:46 -0700 (PDT) Sender: artemb@gmail.com Received: by 10.141.40.4 with HTTP; Mon, 10 May 2010 13:53:46 -0700 (PDT) In-Reply-To: References: <4BDEA86E.3050109@zirakzigil.org> <20100503110100.GA93137@icarus.home.lan> <4BDEC106.3040807@zirakzigil.org> <4BE110E3.8040902@zirakzigil.org> <4BE82C5D.1080806@bit0.com> <4BE83B9B.5030209@comcast.net> Date: Mon, 10 May 2010 13:53:46 -0700 X-Google-Sender-Auth: 9e70efb62066c102 Message-ID: From: Artem Belevich To: Mike Andrews Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable@freebsd.org, Steve Polyack Subject: Re: Freebsd 8.0 kmem map too small X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 May 2010 20:53:47 -0000 vm.kmem_size limitation has been this way for a pretty long time. What's changed recently is that ZFS ARC now uses UMA for its memory allocations. If I understand it correctly, this would make ARC's memory use more efficient as allocated chunks will end up in a zone tuned for allocations of particular size. Increased fragmentation could be the side effect of this change, but I'm guessing here. --Artem On Mon, May 10, 2010 at 1:45 PM, Mike Andrews wrote: > On Mon, 10 May 2010, Steve Polyack wrote: > >> On 05/10/10 11:55, Mike Andrews wrote: >>> >>> On 5/5/10 11:19 AM, Freddie Cash wrote: >>>> >>>> On Tue, May 4, 2010 at 11:32 PM, Giulio Ferro >>>> wrote: >>>> >>>>> Giulio Ferro wrote: >>>>> >>>>>> Thanks, I'll try these settings. >>>>>> >>>>>> I'll keep you posted. >>>>>> >>>>> >>>>> Nope, it's happened again... Now I've tried to rise vm.kmem_size to >>>>> 6G... >>>>> I'm really astounded at how unstable zfs is, it's causing me a lot of >>>>> problem. >>>>> Why isn't it stated in the handbook that zfs isn't up to production >>>>> yet? >>>>> >>>> >>>> As with everything related to computers, it all depends on your uses. >>> >>> Sorry to semi-hijack this, but... =A0I'm also running into frequent >>> "kmem_map too small" panics on 8-STABLE, such as: >>> >>> panic: kmem_malloc(131072): kmem_map too small: 2023780352 total >>> allocated >>> panic: kmem_malloc(131072): kmem_map too small: 2011525120 total >>> allocated >>> panic: kmem_malloc(114688): kmem_map too small: 1849356288 total >>> allocated >>> panic: kmem_malloc(114688): kmem_map too small: 1849356288 total >>> allocated >>> panic: kmem_malloc(114688): kmem_map too small: 1849356288 total >>> allocated >>> panic: kmem_malloc(131072): kmem_map too small: 2020409344 total >>> allocated >>> panic: kmem_malloc(536576): kmem_map too small: 2022957056 total >>> allocated >>> >>> (those are over the course of 3-4 days) >>> >>> On this specific system, it has 32 GB physical memory and has >>> vfs.zfs.arc_max=3D"2G" and vm.kmem_size=3D"64G" in /boot/loader.conf. = =A0The >>> latter was added per earlier suggestions on this list, but appears to b= e >>> ignored as "sysctl vm.kmem_size" returns about 2 GB (2172452864) anyway= . >>> >>> >> As Artem stated in another reply, you will need to set vm.kmem_size >> slightly under 2x the physical memory. =A0The kernel will default to 2GB= if >> you pass this limit. =A01.5x physical memory size should be sufficient, = so try >> "48G" and verify that it gets set correctly on the next boot. > > > OK, I've got vm.kmem_size set a bit lower and it now accepts it. =A0It's = still > not clear why this just recently (April?) became necessary to do at all := ) > > Meanwhile, I'll see if things get more stable now... > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > From owner-freebsd-stable@FreeBSD.ORG Mon May 10 23:29:53 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6079D106566B; Mon, 10 May 2010 23:29:53 +0000 (UTC) (envelope-from rpp@ci.com.au) Received: from mippet.ci.com.au (mippet.ci.com.au [192.65.182.30]) by mx1.freebsd.org (Postfix) with ESMTP id EF2578FC21; Mon, 10 May 2010 23:29:52 +0000 (UTC) Received: from mippet.ci.com.au (localhost [127.0.0.1]) by mippet.ci.com.au (8.14.4/8.14.3/CE070809/cml) with ESMTP id o4ANEPUB046926; Tue, 11 May 2010 09:14:26 +1000 (EST) (envelope-from rpp@mippet.ci.com.au) Received: (from rpp@localhost) by mippet.ci.com.au (8.14.4/8.14.3/Submit) id o4ANEOQw046921; Tue, 11 May 2010 09:14:24 +1000 (EST) (envelope-from rpp) Date: Tue, 11 May 2010 09:14:24 +1000 From: Richard Perini To: freebsd-fs@freebsd.org, freebsd-stable@freebsd.org Message-ID: <20100510231424.GA38308@mippet.ci.com.au> References: <4BDEA86E.3050109@zirakzigil.org> <20100503110100.GA93137@icarus.home.lan> <4BDEC106.3040807@zirakzigil.org> <4BE110E3.8040902@zirakzigil.org> <20100505075242.GA57550@icarus.home.lan> <4BE13067.1060606@zirakzigil.org> <20100505133302.GB1626@garage.freebsd.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100505133302.GB1626@garage.freebsd.pl> X-Scanned-By: MIMEDefang 2.67 on 192.65.182.30 Cc: Subject: Re: Freebsd 8.0 kmem map too small X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 May 2010 23:29:53 -0000 On Wed, May 05, 2010 at 03:33:02PM +0200, Pawel Jakub Dawidek wrote: > On Wed, May 05, 2010 at 10:46:31AM +0200, Giulio Ferro wrote: > > On 05.05.2010 09:52, Jeremy Chadwick wrote: > > > > Nope, it's happened again... Now I've tried to rise vm.kmem_size to 6G... > > [ ... ] > Could you try to track down the commit that is causing your problems? > Could you try 8-STABLE kernel from before r206815? A quick note to say "same here", but on i386. FreeBSD 8.0-STABLE as of 8/5/2010 paniced last night with same symptoms, approx 48 hours uptime. Previous kernel was FreeBSD 8.0-STABLE from Sun Mar 7 14:31:45 EST 2010, perfectly stable for intervening 2 months, about 2 months uptime. Please let me know if full details would help (as opposed to just adding noise :-) -- Richard Perini Internet: rpp@ci.com.au Corinthian Engineering Pty Ltd PHONE: +61 2 9552 5500 Sydney, Australia FAX: +61 2 9552 5549 From owner-freebsd-stable@FreeBSD.ORG Mon May 10 23:43:27 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 41A9E106564A; Mon, 10 May 2010 23:43:27 +0000 (UTC) (envelope-from artemb@gmail.com) Received: from mail-pw0-f54.google.com (mail-pw0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 0A77C8FC12; Mon, 10 May 2010 23:43:26 +0000 (UTC) Received: by pwi9 with SMTP id 9so2062517pwi.13 for ; Mon, 10 May 2010 16:43:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=mTHuXlbFRPTGjQzy4V0IdkhQr7Ii8QjtzbR+yd5MGkk=; b=DoSlkJ8MwzLpdHNVvOagYiuTtErddKBMT3qDkmAMTEdoniUI+e2kG/B87VerlkWCVL ygD+8aAvnKTevcaivY9QS1vhiVYFLNwVgI+Ka19HOPA6VkNe0cBcJ8Cqhl/4DJ8sYdDd 0cR9DZhAV0Y/bJpMJS4RLHQrXDpltFW3VHfOQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=dtgNMxcpSj4eP76jK3jLBO2u0VijDNAXv/jqLW6hzV26CGlZ7n/lFs81Z7Q9FoLMD9 EOaMtoMZQt4Kzjk1+mX9VK98Kerlooh+lz9RCHWlG6+hSz7V5FiADA/DKi4Asac6KzX7 r+T/4lkce6lGleEJhec8hEu81u7zgrX3q7eTE= MIME-Version: 1.0 Received: by 10.141.214.24 with SMTP id r24mr3132223rvq.273.1273535006377; Mon, 10 May 2010 16:43:26 -0700 (PDT) Sender: artemb@gmail.com Received: by 10.141.40.4 with HTTP; Mon, 10 May 2010 16:43:26 -0700 (PDT) In-Reply-To: <20100510231424.GA38308@mippet.ci.com.au> References: <4BDEA86E.3050109@zirakzigil.org> <20100503110100.GA93137@icarus.home.lan> <4BDEC106.3040807@zirakzigil.org> <4BE110E3.8040902@zirakzigil.org> <20100505075242.GA57550@icarus.home.lan> <4BE13067.1060606@zirakzigil.org> <20100505133302.GB1626@garage.freebsd.pl> <20100510231424.GA38308@mippet.ci.com.au> Date: Mon, 10 May 2010 16:43:26 -0700 X-Google-Sender-Auth: 0iSU8Di4EwKPCpYRnK4zoX7Oh_M Message-ID: From: Artem Belevich To: Richard Perini Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@freebsd.org, freebsd-stable@freebsd.org Subject: Re: Freebsd 8.0 kmem map too small X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 May 2010 23:43:27 -0000 You can try disabling ZIO_USE_UMA in sys/modules/zfs/Makefile Comment out following line in that file: CFLAGS+=3D-DZIO_USE_UMA This should revert memory allocation method back to its previous mode. Let us know whether it helps or not. --Artem On Mon, May 10, 2010 at 4:14 PM, Richard Perini wrote: > On Wed, May 05, 2010 at 03:33:02PM +0200, Pawel Jakub Dawidek wrote: >> On Wed, May 05, 2010 at 10:46:31AM +0200, Giulio Ferro wrote: >> > On 05.05.2010 09:52, Jeremy Chadwick wrote: >> > >> > Nope, it's happened again... Now I've tried to rise vm.kmem_size to 6G= ... >> > > > [ ... ] > >> Could you try to track down the commit that is causing your problems? >> Could you try 8-STABLE kernel from before r206815? > > A quick note to say "same here", but on i386. > > FreeBSD 8.0-STABLE as of 8/5/2010 paniced last night with same symptoms, > approx 48 hours uptime. > > Previous kernel was FreeBSD 8.0-STABLE from Sun Mar =A07 14:31:45 EST 201= 0, > perfectly stable for intervening 2 months, about 2 months uptime. > > Please let me know if full details would help (as opposed to just adding = noise :-) > > -- > Richard Perini =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 Internet: =A0rpp@ci.com.au > Corinthian Engineering Pty Ltd =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 PHONE: =A0 +61 2 9552 5500 > Sydney, Australia =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0FAX: =A0 =A0 +61 2 9552 5549 > _______________________________________________ > freebsd-fs@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" > From owner-freebsd-stable@FreeBSD.ORG Mon May 10 23:57:58 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0DC621065673; Mon, 10 May 2010 23:57:57 +0000 (UTC) (envelope-from rpp@ci.com.au) Received: from mippet.ci.com.au (mippet.ci.com.au [192.65.182.30]) by mx1.freebsd.org (Postfix) with ESMTP id 663438FC0A; Mon, 10 May 2010 23:57:57 +0000 (UTC) Received: from mippet.ci.com.au (localhost [127.0.0.1]) by mippet.ci.com.au (8.14.4/8.14.3/CE070809/cml) with ESMTP id o4ANvs9G079379; Tue, 11 May 2010 09:57:55 +1000 (EST) (envelope-from rpp@mippet.ci.com.au) Received: (from rpp@localhost) by mippet.ci.com.au (8.14.4/8.14.3/Submit) id o4ANvr7H079365; Tue, 11 May 2010 09:57:53 +1000 (EST) (envelope-from rpp) Date: Tue, 11 May 2010 09:57:53 +1000 From: Richard Perini To: Artem Belevich Message-ID: <20100510235753.GA74801@mippet.ci.com.au> References: <4BDEA86E.3050109@zirakzigil.org> <20100503110100.GA93137@icarus.home.lan> <4BDEC106.3040807@zirakzigil.org> <4BE110E3.8040902@zirakzigil.org> <20100505075242.GA57550@icarus.home.lan> <4BE13067.1060606@zirakzigil.org> <20100505133302.GB1626@garage.freebsd.pl> <20100510231424.GA38308@mippet.ci.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Scanned-By: MIMEDefang 2.67 on 192.65.182.30 Cc: freebsd-fs@freebsd.org, freebsd-stable@freebsd.org Subject: Re: Freebsd 8.0 kmem map too small X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 May 2010 23:57:58 -0000 On Mon, May 10, 2010 at 04:43:26PM -0700, Artem Belevich wrote: > You can try disabling ZIO_USE_UMA in sys/modules/zfs/Makefile > > Comment out following line in that file: > CFLAGS+=-DZIO_USE_UMA > > This should revert memory allocation method back to its previous mode. > Let us know whether it helps or not. Thanks Artem, I'll try the suggestion and report back. I'll give it 72 hours. The workload of the machine is fairly consistent day to day. Cheers, -- Richard Perini Internet: rpp@ci.com.au Corinthian Engineering Pty Ltd PHONE: +61 2 9552 5500 Sydney, Australia FAX: +61 2 9552 5549 From owner-freebsd-stable@FreeBSD.ORG Tue May 11 00:17:21 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D7562106566C for ; Tue, 11 May 2010 00:17:21 +0000 (UTC) (envelope-from kensmith@buffalo.edu) Received: from localmailD.acsu.buffalo.edu (localmailD.acsu.buffalo.edu [128.205.5.208]) by mx1.freebsd.org (Postfix) with ESMTP id A9AB48FC15 for ; Tue, 11 May 2010 00:17:21 +0000 (UTC) Received: from localmailD.acsu.buffalo.edu (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id B109F19F6D for ; Mon, 10 May 2010 20:17:20 -0400 (EDT) Received: from localmailD.acsu.buffalo.edu (localhost [127.0.0.1]) by localmailD.acsu.buffalo.edu (Postfix) with ESMTP id 04DABC1847 for ; Mon, 10 May 2010 20:17:20 -0400 (EDT) Received: from mweb2.acsu.buffalo.edu (mweb2.acsu.buffalo.edu [128.205.5.239]) by localmailD.acsu.buffalo.edu (Prefixe) with ESMTP id F3004C1802 for ; Mon, 10 May 2010 20:17:19 -0400 (EDT) Received: from ken-smiths-macbook-pro.local (unknown [24.114.252.231]) by mweb2.acsu.buffalo.edu (Postfix) with ESMTP id BD6A2207A9 for ; Mon, 10 May 2010 20:17:19 -0400 (EDT) Message-ID: <4BE8A20C.3010708@buffalo.edu> Date: Mon, 10 May 2010 20:17:16 -0400 From: Ken Smith User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <201005101636.o4AGa2pF053050@fire.js.berklix.net> In-Reply-To: <201005101636.o4AGa2pF053050@fire.js.berklix.net> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-PM-EL-Spam-Prob: : 8% Subject: Re: FreeBSD Release 8.0 floppy images X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 May 2010 00:17:21 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 5/10/10 12:36 PM, Julian H. Stacey wrote: > I'd suggest it would be good to commit & post a comment why removed. > It will later affect rescue capability of some older servers when > they get upgraded, (I guess many/most legacy production servers > still are 7.*, at least till 8.1 comes out). When I started down the pathway to removing them it was with the intention of removing *all* mention of floppies as part of system installation. There are quite a few things it would be really nice to rip out of sysinstall (they're hindering other progress) that are there because of floppies. We figured it had reached the point progress on making sysinstall better (or at least less annoying) in various ways being hindered by floppy support wasn't in the majority of peoples' best interest. It turned out progressing on that isn't going as well as hoped, pc98 has stronger ties to floppies than was originally thought. So, after turning off the building of floppies things got a bit stalled on the removal of what I'll call "floppy-isms" in sysinstall. It's still the basic path we'd like to follow, it's just slowed down a bit. As for building them at all goes... It turns out that by mistake (a system doing automated release builds on a regular interval) we discovered that building them now fails due to another of the handful of reasons we wanted to abandon floppies goes (above mentioned ripping out of stuff was just one). Most of the floppies involved can go multi-volume if necessary (e.g. the mfs floppy can span more than one physical floppy) but the 'livefs' one can't and it recently started overflowing. Those reasons combined with the fact I can't even test them any more all combined to convince the developer community 8.0 was a reasonable point to let floppy support fall by the wayside. - -- Ken Smith - - From there to here, from here to | kensmith@buffalo.edu there, funny things are everywhere. | - Theodore Geisel | -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkvoogwACgkQ/G14VSmup/bC3ACfbuczpAnz1FuC3gzzSWa3BM3I TPsAnRE/KnBwM2v9akXNuQJJmtJGnBF6 =p7a/ -----END PGP SIGNATURE----- From owner-freebsd-stable@FreeBSD.ORG Tue May 11 03:34:58 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C320F1065676 for ; Tue, 11 May 2010 03:34:58 +0000 (UTC) (envelope-from lhmwzy@gmail.com) Received: from mail-qy0-f181.google.com (mail-qy0-f181.google.com [209.85.221.181]) by mx1.freebsd.org (Postfix) with ESMTP id 766558FC16 for ; Tue, 11 May 2010 03:34:58 +0000 (UTC) Received: by qyk11 with SMTP id 11so6683633qyk.13 for ; Mon, 10 May 2010 20:34:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=RqUlTB/Jwmb2XFuQLlLolZD5lHEyE2D5msVedgERa/Q=; b=CDHuvTtyN/yfaTccO4RIfbtyXRnD6wWjUU7p9CEyRTD6oVJ2/HzxlEqL6D5tUaKkwT ksidlHddMV+oUqBERNdr8jG4su9/LDh2sw0bi1c1QisbkNArNY0jSHZpCT6jCf0ULcw8 KcGmSQKplMPNHt2zWZvLXR7xaTFcM6K3WoFv4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=uwQD88Zz4krqufLbJE/LXlYxxMCCBPwbWsI2lgdeYIiLlT/A6c+Al991TR2D0SOFSS 04wqdGkZVopQNB/CuDa+iFWTYB863SU+OW305ZgPGjUV+oaMPcCRgFQ7SLXWINtm1NdQ mvngGx7E77eG9vjIM7tTYTyetJ2Ze4YSzod4U= MIME-Version: 1.0 Received: by 10.229.237.142 with SMTP id ko14mr4278781qcb.11.1273547494508; Mon, 10 May 2010 20:11:34 -0700 (PDT) Received: by 10.229.104.194 with HTTP; Mon, 10 May 2010 20:11:34 -0700 (PDT) Date: Tue, 11 May 2010 11:11:34 +0800 Message-ID: From: lhmwzy To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: How to clear the 32-bit ldconfig error in 64-bit FreeBSD? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 May 2010 03:34:58 -0000 like this: ELF ldconfig path: /lib /usr/lib /usr/lib/compat /usr/local/lib /usr/local/lib/compat 32-bit compatibility ldconfig path: /usr/local/lib32/compat .: Can't open %%RC_SUBR%%: No such file or directory uname -a: FreeBSD lanshuweb2 8.0-RELEASE FreeBSD 8.0-RELEASE #2: Tue May 11 10:04:28 UTC 2010 root@lanshuweb2:/usr/obj/usr/src/sys/mlh amd6 /usr/src/sys/amd64/conf/mlh: ... options SCHED_ULE # ULE scheduler options PREEMPTION # Enable kernel thread preemption options INET # InterNETworking #options INET6 # IPv6 communications protocols options SCTP # Stream Control Transmission Protocol options FFS # Berkeley Fast Filesystem options SOFTUPDATES # Enable FFS soft updates support options UFS_ACL # Support for access control lists options UFS_DIRHASH # Improve performance on big directories options UFS_GJOURNAL # Enable gjournal-based UFS journaling options MD_ROOT # MD is a potential root device #options NFSCLIENT # Network Filesystem Client #options NFSSERVER # Network Filesystem Server #options NFSLOCKD # Network Lock Manager #options NFS_ROOT # NFS usable as /, requires NFSCLIENT #options MSDOSFS # MSDOS Filesystem options CD9660 # ISO 9660 Filesystem options PROCFS # Process filesystem (requires PSEUDOFS) options PSEUDOFS # Pseudo-filesystem framework options GEOM_PART_GPT # GUID Partition Tables. options GEOM_LABEL # Provides labelization options COMPAT_43TTY # BSD 4.3 TTY compat (sgtty) #options COMPAT_IA32 # Compatible with i386 binaries #options COMPAT_FREEBSD4 # Compatible with FreeBSD4 #options COMPAT_FREEBSD5 # Compatible with FreeBSD5 options COMPAT_FREEBSD6 # Compatible with FreeBSD6 options COMPAT_FREEBSD7 # Compatible with FreeBSD7 options SCSI_DELAY=5000 # Delay (in ms) before probing SCSI #options KTRACE # ktrace(1) support #options STACK # stack(9) support options SYSVSHM # SYSV-style shared memory options SYSVMSG # SYSV-style message queues options SYSVSEM # SYSV-style semaphores options P1003_1B_SEMAPHORES # POSIX-style semaphores options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time extensions options PRINTF_BUFR_SIZE=128 # Prevent printf output being interspersed. options KBD_INSTALL_CDEV # install a CDEV entry in /dev options HWPMC_HOOKS # Necessary kernel hooks for hwpmc(4) options AUDIT # Security event auditing options MAC # TrustedBSD MAC Framework options FLOWTABLE # per-cpu routing cache #options KDTRACE_FRAME # Ensure frames are compiled in #options KDTRACE_HOOKS # Kernel DTrace hooks # Make an SMP-capable kernel by default options SMP # Symmetric MultiProcessor Kernel ....... From owner-freebsd-stable@FreeBSD.ORG Tue May 11 04:04:20 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B663E1065672 for ; Tue, 11 May 2010 04:04:20 +0000 (UTC) (envelope-from g4m4r4l@gmail.com) Received: from mail-pv0-f182.google.com (mail-pv0-f182.google.com [74.125.83.182]) by mx1.freebsd.org (Postfix) with ESMTP id 80A548FC12 for ; Tue, 11 May 2010 04:04:20 +0000 (UTC) Received: by pvc30 with SMTP id 30so201615pvc.13 for ; Mon, 10 May 2010 21:04:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:received:date:from:to :subject:message-id:reply-to:mime-version:content-type :content-disposition:x-operating-system:x-crypto:x-gpg-key :x-gpg-fingerprint:user-agent; bh=E8BVXovRMilb2dBZt21OCfKRMhLkKSM44obf7Qz/DOw=; b=JGBw4zhf9VBkiGifi8a1EzxYXYBOFvPtg9F3qYg18KZ3hY+yHQj0Hf1aza5LSgmw8I y84VNJwHBZVu7PdzyxVZhSqU5dxDfHrhP3HFryspmDVMyPu1XWskCFTJ+O66JrZIIFtv +7kwY3gsXEC7EKoKqFEdVl2j//XZl57FDqyyQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:date:from:to:bcc:subject:message-id:reply-to:mime-version :content-type:content-disposition:x-operating-system:x-crypto :x-gpg-key:x-gpg-fingerprint:user-agent; b=uH4V/dIIs/DBxF8FK2JmPznFu3lrPwR5jtL0usSsFzbbj+hFweEYYuD9w16xBSlRwt kG59xgQqkrYPEnF4j/Oc4lrZ2ZbgPw8UdgCvtexf/2KNNsUgsCNO6qn2O62RlzeZ6YEf Xf7KAXHczGoqvQ0CMmNfpHBKzrfCJLHYApIDU= Received: by 10.141.109.10 with SMTP id l10mr3351784rvm.30.1273549106772; Mon, 10 May 2010 20:38:26 -0700 (PDT) Received: from daedalus (201.171.66.237.dsl.dyn.telnor.net [201.171.66.237]) by mx.google.com with ESMTPS id g14sm2433496rvb.1.2010.05.10.20.38.25 (version=SSLv3 cipher=RC4-MD5); Mon, 10 May 2010 20:38:26 -0700 (PDT) Sender: Guillermo Amaral Received: by daedalus (nbSMTP-1.00) for uid 1001 (using TLSv1/SSLv3 with cipher RC4-MD5 (128/128 bits)) g@maral.me; Mon, 10 May 2010 20:38:23 -0700 (PDT) Date: Mon, 10 May 2010 20:38:21 -0700 From: Guillermo Amaral To: freebsd-stable@freebsd.org Message-ID: <20100511033821.GA1807@daedalus.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Operating-System: FreeBSD/8.0-STABLE (amd64) X-Crypto: GnuPG/2.0.11 http://www.gnupg.org X-GPG-Key: http://dl.guillermoamaral.com/public.asc X-GPG-Fingerprint: E068 811D 4AA2 7FDA A327 38BD 640D 014C 76FE 7D5A User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Problem with ath(4) RELENG_8 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: g@maral.me List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 May 2010 04:04:20 -0000 Hi guys, I have been using RELENG_8 for a while and some time ago the wireless driver started acting funny, by this I mean that for example in RELENG_8_0 the ath driver radio switch works, I can connect AND stay connected with out a hitch. In RELENG_8 it has progressively gone from good to bad to worse, at first the radio on/off switch stopped working (it did change color but the driver never really turned off the radio), then any wifi I connected to stopped responding after about 5 minutes, I then need to restart wlan0 for it to reconnect and give me 5 more minutes, now the wifi radio switch won't even change color. I thought maybe this was something temporary but just in case it's not and nobody knows that this is going on I decided to send this mail. ---- MODEL HP Pavilion DV7-3063CL ---- PCICONFIG hostb0@pci0:0:0:0: class=0x060000 card=0x3638103c chip=0x96011022 rev=0x00 hdr=0x00 vendor = 'Advanced Micro Devices (AMD)' class = bridge subclass = HOST-PCI pcib1@pci0:0:1:0: class=0x060400 card=0x3638103c chip=0x9602103c rev=0x00 hdr=0x01 vendor = 'Hewlett-Packard Company' class = bridge subclass = PCI-PCI pcib2@pci0:0:4:0: class=0x060400 card=0x3638103c chip=0x96041022 rev=0x00 hdr=0x01 vendor = 'Advanced Micro Devices (AMD)' class = bridge subclass = PCI-PCI pcib3@pci0:0:5:0: class=0x060400 card=0x3638103c chip=0x96051022 rev=0x00 hdr=0x01 vendor = 'Advanced Micro Devices (AMD)' class = bridge subclass = PCI-PCI pcib4@pci0:0:6:0: class=0x060400 card=0x3638103c chip=0x96061022 rev=0x00 hdr=0x01 vendor = 'Advanced Micro Devices (AMD)' class = bridge subclass = PCI-PCI atapci0@pci0:0:17:0: class=0x010601 card=0x3638103c chip=0x43911002 rev=0x00 hdr=0x00 vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' device = 'SB700 SATA Controller [AHCI mode]' class = mass storage subclass = SATA ohci0@pci0:0:18:0: class=0x0c0310 card=0x3638103c chip=0x43971002 rev=0x00 hdr=0x00 vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' device = 'SB700 USB OHCI0 Controller' class = serial bus subclass = USB ohci1@pci0:0:18:1: class=0x0c0310 card=0x3638103c chip=0x43981002 rev=0x00 hdr=0x00 vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' device = 'Standard OpenHCD USB-Hostcontroller (SB700)' class = serial bus subclass = USB ehci0@pci0:0:18:2: class=0x0c0320 card=0x3638103c chip=0x43961002 rev=0x00 hdr=0x00 vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' device = 'SB700 USB EHCI Controller' class = serial bus subclass = USB ohci2@pci0:0:19:0: class=0x0c0310 card=0x3638103c chip=0x43971002 rev=0x00 hdr=0x00 vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' device = 'SB700 USB OHCI0 Controller' class = serial bus subclass = USB ohci3@pci0:0:19:1: class=0x0c0310 card=0x3638103c chip=0x43981002 rev=0x00 hdr=0x00 vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' device = 'Standard OpenHCD USB-Hostcontroller (SB700)' class = serial bus subclass = USB ehci1@pci0:0:19:2: class=0x0c0320 card=0x3638103c chip=0x43961002 rev=0x00 hdr=0x00 vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' device = 'SB700 USB EHCI Controller' class = serial bus subclass = USB none0@pci0:0:20:0: class=0x0c0500 card=0x3638103c chip=0x43851002 rev=0x3c hdr=0x00 vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' device = 'ATI SMBus (ATI RD600/RS600)' class = serial bus subclass = SMBus hdac1@pci0:0:20:2: class=0x040300 card=0x3638103c chip=0x43831002 rev=0x00 hdr=0x00 vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' device = 'IXP SB600 High Definition Audio Controller' class = multimedia subclass = HDA isab0@pci0:0:20:3: class=0x060100 card=0x3638103c chip=0x439d1002 rev=0x00 hdr=0x00 vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' device = 'SB700 LPC host controller' class = bridge subclass = PCI-ISA pcib5@pci0:0:20:4: class=0x060401 card=0x00000000 chip=0x43841002 rev=0x00 hdr=0x01 vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' device = 'IXP SB600 PCI to PCI Bridge' class = bridge subclass = PCI-PCI hostb1@pci0:0:24:0: class=0x060000 card=0x00000000 chip=0x12001022 rev=0x00 hdr=0x00 vendor = 'Advanced Micro Devices (AMD)' device = '(Family 10h) Athlon64/Opteron/Sempron HyperTransport Technology Configuration' class = bridge subclass = HOST-PCI hostb2@pci0:0:24:1: class=0x060000 card=0x00000000 chip=0x12011022 rev=0x00 hdr=0x00 vendor = 'Advanced Micro Devices (AMD)' device = '(Family 10h) Athlon64/Opteron/Sempron Address Map' class = bridge subclass = HOST-PCI hostb3@pci0:0:24:2: class=0x060000 card=0x00000000 chip=0x12021022 rev=0x00 hdr=0x00 vendor = 'Advanced Micro Devices (AMD)' device = '(Family 10h) Athlon64/Opteron/Sempron DRAM Controller' class = bridge subclass = HOST-PCI hostb4@pci0:0:24:3: class=0x060000 card=0x00000000 chip=0x12031022 rev=0x00 hdr=0x00 vendor = 'Advanced Micro Devices (AMD)' device = '(Family 10h) Athlon64/Opteron/Sempron Miscellaneous Control' class = bridge subclass = HOST-PCI hostb5@pci0:0:24:4: class=0x060000 card=0x00000000 chip=0x12041022 rev=0x00 hdr=0x00 vendor = 'Advanced Micro Devices (AMD)' device = '(Family 10h) Athlon64/Opteron/Sempron Link Control' class = bridge subclass = HOST-PCI vgapci0@pci0:1:5:0: class=0x030000 card=0x3638103c chip=0x97121002 rev=0x00 hdr=0x00 vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' device = 'ATI Mobility Radeon HD 4200 (RS880)' class = display subclass = VGA hdac0@pci0:1:5:1: class=0x040300 card=0x3638103c chip=0x970f1002 rev=0x00 hdr=0x00 vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' class = multimedia subclass = HDA ath0@pci0:8:0:0: class=0x028000 card=0x3041103c chip=0x002a168c rev=0x01 hdr=0x00 vendor = 'Atheros Communications Inc.' device = 'Atheros AR5B91 Wireless Network Adapter (0001)' class = network re0@pci0:9:0:0: class=0x020000 card=0x3638103c chip=0x813610ec rev=0x02 hdr=0x00 vendor = 'Realtek Semiconductor' device = 'Realtek 10/100/1000 PCI-E NIC Family all in one NDIS Driver v5.728.0604.2009 06/04/2009 (Rtl8023)' class = network subclass = ethernet -- gamaral From owner-freebsd-stable@FreeBSD.ORG Tue May 11 04:11:21 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5981F1065673 for ; Tue, 11 May 2010 04:11:21 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta07.emeryville.ca.mail.comcast.net (qmta07.emeryville.ca.mail.comcast.net [76.96.30.64]) by mx1.freebsd.org (Postfix) with ESMTP id 4023D8FC08 for ; Tue, 11 May 2010 04:11:20 +0000 (UTC) Received: from omta18.emeryville.ca.mail.comcast.net ([76.96.30.74]) by qmta07.emeryville.ca.mail.comcast.net with comcast id Foi41e0081bwxycA74BMw8; Tue, 11 May 2010 04:11:21 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta18.emeryville.ca.mail.comcast.net with comcast id G4BL1e00L3S48mS8e4BMYv; Tue, 11 May 2010 04:11:21 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 75D279B425; Mon, 10 May 2010 21:11:19 -0700 (PDT) Date: Mon, 10 May 2010 21:11:19 -0700 From: Jeremy Chadwick To: lhmwzy Message-ID: <20100511041119.GA78693@icarus.home.lan> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-stable@freebsd.org Subject: Re: How to clear the 32-bit ldconfig error in 64-bit FreeBSD? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 May 2010 04:11:21 -0000 On Tue, May 11, 2010 at 11:11:34AM +0800, lhmwzy wrote: > like this: > > ELF ldconfig path: /lib /usr/lib /usr/lib/compat /usr/local/lib > /usr/local/lib/compat > 32-bit compatibility ldconfig path: /usr/local/lib32/compat > .: Can't open %%RC_SUBR%%: No such file or directory This looks like a problem with a port or part of your system where some expandos (%%RC_SUBR%%) did not get expanded to /etc/rc.subr. > uname -a: > FreeBSD lanshuweb2 8.0-RELEASE FreeBSD 8.0-RELEASE #2: Tue May 11 > 10:04:28 UTC 2010 root@lanshuweb2:/usr/obj/usr/src/sys/mlh amd6 Regarding 32-bit support on amd64, this is what you need: 1) Make sure /etc/src.conf does not contain WITHOUT_LIB32. This will inhibit FreeBSD's buildworld from building 32-bit binaries. By default FreeBSD *does* build 32-bit binaries on amd64. The only reason I'm pointing this out is that some administrators set WITHOUT_LIB32 in src.conf but then later need i386 compatibility and forget all about the option they set. 2) Your kernel configuration file needs "options COMPAT_IA32" in it. You have it commented out. Be aware that the name of this option has changed in RELENG_8 (not 8.0-RELEASE) from COMPAT_IA32 to COMPAT_FREEBSD32. So if you upgrade in the future, you may need to rename this option. You should view /sys/amd64/conf/GENERIC or /sys/amd64/conf/NOTES to see what other semantics may have changed since you made your kernel configuration file. I also advocate watching CVS commits for parts of the tree around there and reading what changes happen, especially if you follow -STABLE. Ex: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/amd64/conf/GENERIC http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/amd64/conf/NOTES -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Tue May 11 15:43:03 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EEA5F106564A for ; Tue, 11 May 2010 15:43:03 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from tower.berklix.org (tower.berklix.org [83.236.223.114]) by mx1.freebsd.org (Postfix) with ESMTP id 757C48FC14 for ; Tue, 11 May 2010 15:43:02 +0000 (UTC) Received: from park.js.berklix.net (p549A6BA2.dip.t-dialin.net [84.154.107.162]) (authenticated bits=0) by tower.berklix.org (8.14.2/8.14.2) with ESMTP id o4BFgp3Y006253; Tue, 11 May 2010 15:42:59 GMT (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (fire.js.berklix.net [192.168.91.41]) by park.js.berklix.net (8.13.8/8.13.8) with ESMTP id o4BFgaWm098537; Tue, 11 May 2010 17:42:39 +0200 (CEST) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (localhost [127.0.0.1]) by fire.js.berklix.net (8.14.3/8.14.3) with ESMTP id o4BFg0qS010723; Tue, 11 May 2010 17:42:17 +0200 (CEST) (envelope-from jhs@fire.js.berklix.net) Message-Id: <201005111542.o4BFg0qS010723@fire.js.berklix.net> to: freebsd-stable@freebsd.org From: "Julian H. Stacey" Organization: http://www.berklix.com BSD Unix Linux Consultancy, Munich Germany User-agent: EXMH on FreeBSD http://www.berklix.com/free/ X-URL: http://www.berklix.com In-reply-to: Your message "Mon, 10 May 2010 12:39:19 CDT." <20100510173919.GA11737@lonesome.com> Date: Tue, 11 May 2010 17:42:00 +0200 Sender: jhs@berklix.com Cc: Mark Linimon , Royce Williams , Ken Smith Subject: Re: FreeBSD Release 8.0 floppy images X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 May 2010 15:43:04 -0000 Hi, Mark Linimon wrote: > You can still build them. They just won't be built by default. Trying that now on 8.0-RELEASE amd64 Thanks. Ken Smith wrote: > building them now > fails due to another of the handful of reasons we wanted > to abandon floppies > ... > the 'livefs' > one can't and it recently started overflowing. I hope that's stable or current & not 8.0-RELEASE. > Those reasons combined with the fact I can't even test > them any more all combined to convince the developer > community 8.0 was a reasonable point to let floppy > support fall by the wayside. Thanks for the reply. Understandable that developers hosts have lost interest in floppies. But a lot of old servers & laptops used as spare terminas etc may have floppy & ether but no cdrom or USB, inc eg this laptop running 7.2: http://www.berklix.org/~jhs/hardware/laptops/dell_latitude_xpi_p133st/ I suspect people who live near you may sometime offer to drop off a spare old PC with a floppy ;-) Cheers, Julian -- Julian Stacey: BSD Unix Linux C Sys Eng Consultants Munich http://berklix.com Mail plain text, Not HTML quoted-printable Base64 http://www.asciiribbon.org From owner-freebsd-stable@FreeBSD.ORG Tue May 11 17:18:54 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 88E461065674 for ; Tue, 11 May 2010 17:18:54 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by mx1.freebsd.org (Postfix) with ESMTP id 14CD38FC1C for ; Tue, 11 May 2010 17:18:53 +0000 (UTC) Received: (qmail 17129 invoked by uid 399); 11 May 2010 17:18:52 -0000 Received: from localhost (HELO foreign.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 11 May 2010 17:18:52 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4BE9917B.3090104@FreeBSD.org> Date: Tue, 11 May 2010 10:18:51 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.9) Gecko/20100330 Thunderbird/3.0.4 MIME-Version: 1.0 To: Jeremy Chadwick References: <20100511041119.GA78693@icarus.home.lan> In-Reply-To: <20100511041119.GA78693@icarus.home.lan> X-Enigmail-Version: 1.0.1 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org, lhmwzy Subject: Re: How to clear the 32-bit ldconfig error in 64-bit FreeBSD? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 May 2010 17:18:54 -0000 On 05/10/10 21:11, Jeremy Chadwick wrote: > On Tue, May 11, 2010 at 11:11:34AM +0800, lhmwzy wrote: >> like this: >> >> ELF ldconfig path: /lib /usr/lib /usr/lib/compat /usr/local/lib >> /usr/local/lib/compat >> 32-bit compatibility ldconfig path: /usr/local/lib32/compat >> .: Can't open %%RC_SUBR%%: No such file or directory This looks like an artifact from before the change removing the %%RC_SUBR%% macro. If you still have that in the rc.d file then reinstalling the port should fix it up. If it does not, please report that issue on freebsd-ports@. hth, Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ From owner-freebsd-stable@FreeBSD.ORG Wed May 12 00:57:20 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A730F106564A for ; Wed, 12 May 2010 00:57:20 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.freebsd.org (Postfix) with ESMTP id 253968FC15 for ; Wed, 12 May 2010 00:57:18 +0000 (UTC) Received: from ur.dons.net.au (Ur.gsoft.com.au [203.31.81.44]) (authenticated bits=0) by cain.gsoft.com.au (8.14.4/8.14.3) with ESMTP id o4C0vAi0063283 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 12 May 2010 10:27:16 +0930 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 12 May 2010 09:39:44 +0930 To: FreeBSD Stable Message-Id: Mime-Version: 1.0 (Apple Message framework v1078) X-Mailer: Apple Mail (2.1078) X-Spam-Score: -2.51 () ALL_TRUSTED,BAYES_00,T_RP_MATCHES_RCVD X-Scanned-By: MIMEDefang 2.67 on 203.31.81.10 Subject: .zfs directory broken on an FS X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 May 2010 00:57:20 -0000 I recently switched over to ZFS at work and it seems pretty good (so far = at least!) however I was writing a script to do snapshots and one of the = file systems now gives.. [cain 9:37] ~ >ls -la /usr/local/Genesis/archive/.zfs ls: snapshot: Bad file descriptor total 0 Other file systems in the same pool work fine though.. [cain 9:36] ~ >ll /usr/local/Genesis/MeteorData/.zfs/snapshot total 4 drwxrwxr-x 32 metdata radar 38 Mar 21 03:11 20100512-0900 (All other snapshot directories are OK) I haven't tried rebooting it yet. Any suggestions, or information to help debug it? The system is.. FreeBSD cain.gsoft.com.au 8.0-STABLE FreeBSD 8.0-STABLE #0 r206332: Wed = Apr 7 11:01:52 CST 2010 = root@cain3.gsoft.com.au:/usr/obj/usr/src/sys/GENERIC amd64 -- 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 - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C From owner-freebsd-stable@FreeBSD.ORG Wed May 12 03:44:59 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 07AFD106564A for ; Wed, 12 May 2010 03:44:59 +0000 (UTC) (envelope-from giovanni.trematerra@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 838D98FC1E for ; Wed, 12 May 2010 03:44:58 +0000 (UTC) Received: by fxm1 with SMTP id 1so446636fxm.13 for ; Tue, 11 May 2010 20:44:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=OwGQbcMqX8tNGyI2sR/+9qIQ9J3xNmEff+Kzp1rtlXQ=; b=RO9CLSWzzffFYNo6LLY4fek92FbxxIxq0YVihm6Lt7ZF9mMj/h60oIdNZi2ttGVfod Bx5SJPlsp/tPgmnU2Gnh3B9wTbvD5UeGKlYeMaEEd31CDsUf6zS/IYlWRnXQOiwmtbeN 98BlvyF/IHSMt1dRew+s6+pwNyouypGLuLFUM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=BNglRDct9lZw3V0OD0D4Rh3xRU/B3HyfkZfqkCswhEt2I8GD7HndF73Yh4Mv3iwFhE WMeyHWwtHu1OjaJY/2CmbZbgeJAFHHILXdJeY8EP+rt8UTqBWzshJEOz2iG3D2nur4gZ h3iFtqU2BsDRub3cpu+Xl+yycdllUo0YFX6eI= MIME-Version: 1.0 Received: by 10.223.56.212 with SMTP id z20mr7445046fag.1.1273635897411; Tue, 11 May 2010 20:44:57 -0700 (PDT) Received: by 10.223.103.209 with HTTP; Tue, 11 May 2010 20:44:57 -0700 (PDT) In-Reply-To: <1273257226.1671.3.camel@malikania.fr> References: <4DEBDE2C-C0D2-469D-AC42-DD5027926424@FreeBSD.org> <20100507120843.GA1738@Melon.malikania.fr> <1273257226.1671.3.camel@malikania.fr> Date: Wed, 12 May 2010 05:44:57 +0200 Message-ID: From: Giovanni Trematerra To: Demelier David Content-Type: multipart/mixed; boundary=0015174733ce3d093504865d77b5 Cc: freebsd-stable@freebsd.org Subject: Re: Kernel panic when unpluggin AC adaptor X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 May 2010 03:44:59 -0000 --0015174733ce3d093504865d77b5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Fri, May 7, 2010 at 8:33 PM, Demelier David w= rote: > Le Vendredi 07 mai 2010 =E0 18:22 +0200, Giovanni Trematerra a =E9crit : >> On Fri, May 7, 2010 at 2:08 PM, Demelier David wrote: >> > Hi, >> > =A0 =A0 =A0 =A0I noticed that pluggin the AC adaptor when I boot witho= ut it does not >> > =A0 =A0 =A0 =A0panic. It only panic when removing it. >> > >> > =A0 =A0 =A0 =A0Maybe that could help ? >> > >> >> Good to know. The problem lies somewhere when performance state change. >> In your case it happens when you remove AC adaptor. Let's hope someone o= n >> acpi@ ml comes up with a good idea. >> > > Okay so for the moment no change, I'll wait for someone with an idea > that could solve my problem. For me because the panic only happens when > changing profile from ac plugged -> ac unplugged (and not the reverse) I > would think it's a cpu related acpi issue. > I looked deeper and it seems to me that when you unplug the AC adapter, acpi_cpu_notify calls acpi_cpu_cx_cst that try to allocate a new cx_ptr->p_lvlx via acpi_PkgGas. If acpi_PkgGas set cx_ptr->p_lvlx to NULL for any reasons you'll have the panic that you reported. A solution would be to set acpi_cpu_hook to NULL so acpi_cpu_idle won't cal= l it. I need some time to have a patch because of the possible race between acpi_cpu_notify and acpi_cpu_idle during set acpi_cpu_hook to NULL. if you have time and want panic your system you could try the attached patch, just to be sure that we catch it. Thanks -- Gianni --0015174733ce3d093504865d77b5 Content-Type: text/plain; charset=US-ASCII; name="lvlx.diff.txt" Content-Disposition: attachment; filename="lvlx.diff.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_g93ls0t80 SW5kZXg6IHN5cy9kZXYvYWNwaWNhL2FjcGlfY3B1LmMKPT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gc3lzL2Rldi9h Y3BpY2EvYWNwaV9jcHUuYwkocmV2aXNpb24gMjA3OTQ3KQorKysgc3lzL2Rldi9hY3BpY2EvYWNw aV9jcHUuYwkod29ya2luZyBjb3B5KQpAQCAtNjA5LDcgKzYwOSw5IEBAIGFjcGlfY3B1X2dlbmVy aWNfY3hfcHJvYmUoc3RydWN0IGFjcGlfY3B1X3NvZnRjICpzCiAJICAgIGN4X3B0ci0+dHJhbnNf bGF0ID0gQWNwaUdibF9GQURULkMyTGF0ZW5jeTsKIAkgICAgY3hfcHRyKys7CiAJICAgIHNjLT5j cHVfY3hfY291bnQrKzsKLQl9CisJfSBlbHNlCisJCXBhbmljKCIlczogQ2Fubm90IGFsbG9jYXRl IHJlc291cmNlICVkIGZvciBDMyBzdGF0ZSIsIF9fZnVuY19fLCAKKwkJICAgIGN4X3B0ci0+cmVz X3R5cGUpOwogICAgIH0KICAgICBpZiAoc2MtPmNwdV9wX2Jsa19sZW4gPCA2KQogCXJldHVybjsK QEAgLTYyNSw3ICs2MjcsOSBAQCBhY3BpX2NwdV9nZW5lcmljX2N4X3Byb2JlKHN0cnVjdCBhY3Bp X2NwdV9zb2Z0YyAqcwogCSAgICBjeF9wdHItPnRyYW5zX2xhdCA9IEFjcGlHYmxfRkFEVC5DM0xh dGVuY3k7CiAJICAgIGN4X3B0cisrOwogCSAgICBzYy0+Y3B1X2N4X2NvdW50Kys7Ci0JfQorCX0g ZWxzZQorCQlwYW5pYygiJXM6IENhbm5vdCBhbGxvY2F0ZSByZXNvdXJjZSAlZCBmb3IgQzMgc3Rh dGUiLCBfX2Z1bmNfXywgCisJCSAgICBjeF9wdHItPnJlc190eXBlKTsKICAgICB9CiB9CiAKQEAg LTczMiw3ICs3MzYsOCBAQCBhY3BpX2NwdV9jeF9jc3Qoc3RydWN0IGFjcGlfY3B1X3NvZnRjICpz YykKIAkJCSAgICAgY3hfcHRyLT50cmFuc19sYXQpKTsKIAkgICAgY3hfcHRyKys7CiAJICAgIHNj LT5jcHVfY3hfY291bnQrKzsKLQl9CisJfSBlbHNlCisJCXBhbmljKCJHb3QgaXQhIGFjcGlfUGtn R2FzIHNldCBwX2x2bHggdG8gTlVMTCIpOwogICAgIH0KICAgICBBY3BpT3NGcmVlKGJ1Zi5Qb2lu dGVyKTsKIAo= --0015174733ce3d093504865d77b5-- From owner-freebsd-stable@FreeBSD.ORG Wed May 12 05:09:33 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CDC5C1065670 for ; Wed, 12 May 2010 05:09:33 +0000 (UTC) (envelope-from ukrzilla@gmail.com) Received: from mail-ww0-f54.google.com (mail-ww0-f54.google.com [74.125.82.54]) by mx1.freebsd.org (Postfix) with ESMTP id DCD628FC0A for ; Wed, 12 May 2010 05:09:32 +0000 (UTC) Received: by wwd20 with SMTP id 20so3053689wwd.13 for ; Tue, 11 May 2010 22:09:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=UibmFYAEP171hg9mPj1CqIy45EioKvxY+S2dLusi0GY=; b=ZCTvf0ZEpuqjm+LlbnINFp0DNxI57UENOmNtkgZnYPznqCPf09AmuZC46/vffgRQcX HKvunCgqcXUDLfWQ3LWZJgbL4YuNXY/tn4exKaTVM1d0Xy1JUznI8Tuh7Qzp5cZfbTuz ge2t9wFacNDWE4+n5oZzjTz4z8s/s6AvoykBo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=RNieATY6SndHFmC6Jp7lnHANwNl7MHcL5yozMOKIPw42TeuZZzhJe0QZY+sGQL2wC/ JCAHuOrsaFg3SY91CbfiHuRLwnGZc7uC7UzS5gilXaNAlklUskTnW3ofqNLi2CTrEriq 2flydlwUK0+G/jFNrnfxxbr6fLuzC/rUytNIE= MIME-Version: 1.0 Received: by 10.216.89.84 with SMTP id b62mr4141892wef.226.1273640970694; Tue, 11 May 2010 22:09:30 -0700 (PDT) Received: by 10.216.39.139 with HTTP; Tue, 11 May 2010 22:09:30 -0700 (PDT) Date: Wed, 12 May 2010 08:09:30 +0300 Message-ID: From: Denis Lamanov To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Kernel panic at m_copym/m_copydata X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 May 2010 05:09:33 -0000 Hi I am using mpd5.5 with FreeBSD from 7.2-STABLE ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/201001/FreeBSD-7.2-STABLE-20100= 1-i386-disc1.iso to 7.3-RELEASE and 7.3-STABLE, 8.0-STABLE and every 1-2 day server kernel panic with kernel trap 12 Few people have the same error. This error in the code was entered presumably in early January 2010. In 7.2-RELEASE so no this problem. (kgdb) bt #0 doadump () at pcpu.h:196 #1 0x807f9c67 in boot (howto=3D260) at /usr/src/sys/kern/kern_ shutdown.c:418 #2 0x807f9f39 in panic (fmt=3DVariable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:574 #3 0x80b156ec in trap_fatal (frame=3D0x8e6b0438, eva=3D12) at /usr/src/sys/i386/i386/trap.c:950 #4 0x80b15970 in trap_pfault (frame=3D0x8e6b0438, usermode=3D0, eva=3D12) = at /usr/src/sys/i386/i386/trap.c:863 #5 0x80b16365 in trap (frame=3D0x8e6b0438) at /usr/src/sys/i386/i386/trap.c:541 #6 0x80af964b in calltrap () at /usr/src/sys/i386/i386/exception.s:166 #7 0x8084cdf8 in m_copydata (m=3D0x0, off=3D0, len=3D164, cp=3D0x8f67095c "=D0=AA=D0=97=D0=AA=D1=91s=D0=96o=D1=97E=D0=B9=E2=95=92n=D0=B2\233t=D1=80\2= 06X=D1=8CAYci\006\031=D0=B3\a=D0=98w=E2=95=A1=D1=8D<,\236=D0=9A\0041l\204\2= 07\0028pX~\n=D0=B1=D0=AE4=D0=9Fd=D1=80L\032I=D1=86\2178>\201\004: \021\001=D0=B0\036\2155\237=E2=95=A1N=D0=94!=E2=95=A7\022\006=D0=AE=D2=91=D0=87=D0=A8\1= 775=C2=A9=D0=90=D0=A8=D0=B2=D0=A7\21 6=D1=96=D0=92") at /usr/src/sys/kern/uipc_mbuf.c:815 #8 0x808ef068 in ip_forward (m=3D0x8f37bb00, srcrt=3D0) at /usr/src/sys/netinet/ip_input.c:1307 #9 0x808f0813 in ip_input (m=3D0x8f37bb00) at /usr/src/sys/netinet/ip_input.c:609 #10 0x808a88b5 in netisr_dispatch (num=3D2, m=3D0x8f37bb00) at /usr/src/sys/net/netisr.c:185 #11 0x8f50cdc5 in ng_iface_rcvdata (hook=3D0x8fdbf300, item=3D0x8f411030) at /usr/src/sys/modules/netgraph/iface/../../../netgraph/ng_iface.c:777 #12 0x8f2ea7e4 in ng_apply_item (node=3D0x8f83cb00, item=3D0x8f411030, rw= =3D0) at /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:2336 #13 0x8f2e97ec in ng_snd_item (item=3D0x8f411030, flags=3DVariable "flags" = is not available. ) at /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:2254 #14 0x8f2ea7e4 in ng_apply_item (node=3D0x8fc8b580, item=3D0x8f411030, rw= =3D0) at /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:2336 #15 0x8f2e97ec in ng_snd_item (item=3D0x8f411030, flags=3DVariable "flags" = is not available. ) at /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:2254 #16 0x8f55a266 in ng_car_rcvdata (hook=3D0x8fca7180, item=3D0x8f411030) at /usr/src/sys/modules/netgraph/car/../../../netgraph/ng_car.c:367 #17 0x8f2ea7e4 in ng_apply_item (node=3D0x8f891e00, item=3D0x8f411030, rw= =3D0) at /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:2336 #18 0x8f2e97ec in ng_snd_item (item=3D0x8f411030, flags=3DVariable "flags" = is not available. ) at /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:2254 #19 0x8f2ea7e4 in ng_apply_item (node=3D0x8fc8b580, item=3D0x8f411030, rw= =3D0) at /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:2336 #20 0x8f2e97ec in ng_snd_item (item=3D0x8f411030, flags=3DVariable "flags" = is not available. ) at /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:2254 #21 0x8f2ea7e4 in ng_apply_item (node=3D0x8fcde100, item=3D0x8f411030, rw= =3D0) at /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:2336 #22 0x8f2e97ec in ng_snd_item (item=3D0x8f411030, flags=3DVariable "flags" = is not available. ) at /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:2254 ---Type to continue, or q to quit--- #23 0x8f516ca0 in ng_ppp_proto_recv (node=3D0x8faba400, item=3D0x8f411030, proto=3DVariable "proto" is not available. ) at /usr/src/sys/modules/netgraph/ppp/../../../netgraph/ng_ppp.c:934 #24 0x8f517995 in ng_ppp_rcvdata (hook=3D0x8f8fd880, item=3D0x8f411030) at /usr/src/sys/modules/netgraph/ppp/../../../netgraph/ng_ppp.c:1509 #25 0x8f2ea7e4 in ng_apply_item (node=3D0x8faba400, item=3D0x8f411030, rw= =3D0) at /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:2336 #26 0x8f2e97ec in ng_snd_item (item=3D0x8f411030, flags=3DVariable "flags" = is not available. ) at /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:2254 #27 0x8f2ea7e4 in ng_apply_item (node=3D0x8f7c7580, item=3D0x8f411030, rw= =3D0) at /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:2336 #28 0x8f2e97ec in ng_snd_item (item=3D0x8f411030, flags=3DVariable "flags" = is not available. ) at /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:2254 #29 0x8f2ea7e4 in ng_apply_item (node=3D0x8f0b4c80, item=3D0x8f411030, rw= =3D0) at /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:2336 #30 0x8f2e97ec in ng_snd_item (item=3D0x8f411030, flags=3DVariable "flags" = is not available. ) at /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:2254 #31 0x8f3de8bc in ng_ksocket_incoming2 (node=3D0x8f7bbe00, hook=3D0x0, arg1=3D0x8fae3820, arg2=3D0) at /usr/src/sys/modules/netgraph/ksocket/../../../netgraph/ng_ksocket.c:1143 #32 0x8f2ea91b in ng_apply_item (node=3D0x8f7bbe00, item=3D0x8f568810, rw= =3D1) at /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:2407 #33 0x8f2ebaaf in ngthread (arg=3D0x0) at /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:3304 #34 0x807d2c59 in fork_exit (callout=3D0x8f2eb940 , arg=3D0x0, frame=3D0x8e6b0d38) at /usr/src/sys/kern/kern_fork.c:811 #35 0x80af96c0 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:271 2) (kgdb) bt #0 doadump () at pcpu.h:196 #1 0x807f9c67 in boot (howto=3D260) at /usr/src/sys/kern/kern_shutdown.c:4= 18 #2 0x807f9f39 in panic (fmt=3DVariable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:574 #3 0x80b156ec in trap_fatal (frame=3D0x8e6c4438, eva=3D12) at /usr/src/sys/i386/i386/trap.c:950 #4 0x80b15970 in trap_pfault (frame=3D0x8e6c4438, usermode=3D0, eva=3D12) = at /usr/src/sys/i386/i386/trap.c:863 #5 0x80b16365 in trap (frame=3D0x8e6c4438) at /usr/src/sys/i386/i386/trap.c:541 #6 0x80af964b in calltrap () at /usr/src/sys/i386/i386/exception.s:166 #7 0x8084cdf8 in m_copydata (m=3D0x0, off=3D0, len=3D156, cp=3D0x8ee0b264 "=D1=97-#=D0=9A?=D0=90=D0=B0&\236\225\211h=D1=87=D0=B4=E2=95=9A\215\\=D0=A5= =E2=95=9E\216=D0=9F\230#=D0=BBn%e~\0247\t\204o~A\017$X\217=E2=95=9B\\=D0=B0= =D0=B0\027e=E2=95=A0CU=D1=8Cvp\037$=D1=8E\n=E2=95=A9G=E2=95=A7\224\v=E2=95= =9Bp=D0=90=D1=88\236\002=D1=87@\f=D0=BBl=D0=AA=E2=95=9AC_J=E2=95=9F;\215\23= 2\004\006=E2=95=99E=D2=90=D0=B4[=E2=95=92\203=D0=9BJt\b=D0=9D\024#\002q=D0= =AC\v,\n\027y=D0=A1.\020\037S=D0=AF\032=D0=A0*eDPS=D1=94\b") at /usr/src/sys/kern/uipc_mbuf.c:815 #8 0x808ef068 in ip_forward (m=3D0x8f870600, srcrt=3D0) at /usr/src/sys/netinet/ip_input.c:1307 #9 0x808f0813 in ip_input (m=3D0x8f870600) at /usr/src/sys/netinet/ip_input.c:609 #10 0x808a88b5 in netisr_dispatch (num=3D2, m=3D0x8f870600) at /usr/src/sys/net/netisr.c:185 #11 0x8f527dc5 in ng_iface_rcvdata (hook=3D0x9353e100, item=3D0x8f524a80) a= t /usr/src/sys/modules/netgraph/iface/../../../netgraph/ng_iface.c:777 #12 0x8f30e7e4 in ng_apply_item (node=3D0x9324d200, item=3D0x8f524a80, rw= =3D0) at /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:2336 #13 0x8f30d7ec in ng_snd_item (item=3D0x8f524a80, flags=3DVariable "flags" = is not available. ) at /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:225= 4 #14 0x8f30e7e4 in ng_apply_item (node=3D0x93239d80, item=3D0x8f524a80, rw= =3D0) at /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:2336 #15 0x8f30d7ec in ng_snd_item (item=3D0x8f524a80, flags=3DVariable "flags" = is not available. ) at /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:225= 4 #16 0x8f57f266 in ng_car_rcvdata (hook=3D0x93305800, item=3D0x8f524a80) at /usr/src/sys/modules/netgraph/car/../../../netgraph/ng_car.c:367 #17 0x8f30e7e4 in ng_apply_item (node=3D0x9313a500, item=3D0x8f524a80, rw= =3D0) at /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:2336 #18 0x8f30d7ec in ng_snd_item (item=3D0x8f524a80, flags=3DVariable "flags" = is not available. ) at /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:225= 4 #19 0x8f30e7e4 in ng_apply_item (node=3D0x93239d80, item=3D0x8f524a80, rw= =3D0) at /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:2336 #20 0x8f30d7ec in ng_snd_item (item=3D0x8f524a80, flags=3DVariable "flags" = is not available. ) at /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:225= 4 #21 0x8f30e7e4 in ng_apply_item (node=3D0x8f72f300, item=3D0x8f524a80, rw= =3D0) at /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:2336 #22 0x8f30d7ec in ng_snd_item (item=3D0x8f524a80, flags=3DVariable "flags" = is not available. ) at /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:225= 4 #23 0x8f569ca0 in ng_ppp_proto_recv (node=3D0x8f79fd80, item=3D0x8f524a80, proto=3DVariable "proto" is not available. ) at /usr/src/sys/modules/netgraph/ppp/../../../netgraph/ng_ppp.c:934 #24 0x8f56a995 in ng_ppp_rcvdata (hook=3D0x9312b300, item=3D0x8f524a80) at /usr/src/sys/modules/netgraph/ppp/../../../netgraph/ng_ppp.c:1509 #25 0x8f30e7e4 in ng_apply_item (node=3D0x8f79fd80, item=3D0x8f524a80, rw= =3D0) at /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:2336 #26 0x8f30d7ec in ng_snd_item (item=3D0x8f524a80, flags=3DVariable "flags" = is not available. ) at /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:225= 4 #27 0x8f30e7e4 in ng_apply_item (node=3D0x931bcb80, item=3D0x8f524a80, rw= =3D0) at /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:2336 #28 0x8f30d7ec in ng_snd_item (item=3D0x8f524a80, flags=3DVariable "flags" = is not available. ) at /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:225= 4 #29 0x8f30e7e4 in ng_apply_item (node=3D0x8f6d6080, item=3D0x8f524a80, rw= =3D0) at /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:2336 #30 0x8f30d7ec in ng_snd_item (item=3D0x8f524a80, flags=3DVariable "flags" = is not available. ) at /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:225= 4 #31 0x8f4f38bc in ng_ksocket_incoming2 (node=3D0x8fa81580, hook=3D0x0, arg1=3D0x8f9b51a0, arg2=3D0) at /usr/src/sys/modules/netgraph/ksocket/../../../netgraph/ng_ksocket.c:1143 #32 0x8f30e91b in ng_apply_item (node=3D0x8fa81580, item=3D0x8f5b5a80, rw= =3D1) at /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:2407 #33 0x8f30faaf in ngthread (arg=3D0x0) at /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:3304 #34 0x807d2c59 in fork_exit (callout=3D0x8f30f940 , arg=3D0x0, frame=3D0x8e6c4d38) at /usr/src/sys/kern/kern_fork.c:811 #35 0x80af96c0 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:271 Fatal trap 12: page fault while in kernel mode cpuid =3D 2; apic id =3D 06 fault virtual address =3D 0xc fault code =3D supervisor read, page not present instruction pointer =3D 0x20:0x8084dfe6 stack pointer =3D 0x28:0x8e502b28 frame pointer =3D 0x28:0x8e502b54 code segment =3D base 0x0, limit 0xfffff, type 0x1b =3D DPL 0, pres 1, def32 1, gran 1 processor eflags =3D interrupt enabled, resume, IOPL =3D 0 current process =3D 29 (irq26: bge1) trap number =3D 12 panic: page fault cpuid =3D 2 Uptime: 2h29m46s Physical memory: 2035 MB Dumping 144 MB: 129 113 97 81 65 49 33bge1: watchdog timeout -- resetting <5>bge1: link state changed to DOWN 17 1 (kgdb) bt #0 doadump () at pcpu.h:196 #1 0x807f9c67 in boot (howto=3D260) at /usr/src/sys/kern/kern_shutdown.c:4= 18 #2 0x807f9f39 in panic (fmt=3DVariable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:574 #3 0x80b156ec in trap_fatal (frame=3D0x8e502ae8, eva=3D12) at /usr/src/sys/i386/i386/trap.c: 950 #4 0x80b15970 in trap_pfault (frame=3D0x8e502ae8, usermode=3D0, eva=3D12) = at /usr/src/sys/i386/i386/trap.c:863 #5 0x80b16365 in trap (frame=3D0x8e502ae8) at /usr/src/sys/i386/i386/trap.c:541 #6 0x80af964b in calltrap () at /usr/src/sys/i386/i386/exception.s:166 #7 0x8084dfe6 in m_copym (m=3D0x0, off0=3D1396, len=3D1376, wait=3D1) at /usr/src/sys/kern/uipc_mbuf.c:539 #8 0x808f17c5 in ip_fragment (ip=3D0x8f0e6810, m_frag=3D0x8e502c04, mtu=3D= 1400, if_hwassist_flags=3D0, sw_csum=3D1) at /usr/src/sys/netinet/ip_output.c:731 #9 0x808e47b5 in ip_fastforward (m=3D0x8f3afe00) at /usr/src/sys/netinet/ip_fastfwd.c:568 #10 0x8089c525 in ether_demux (ifp=3D0x8ec1f000, m=3D0x8f3afe00) at /usr/src/sys/net/if_ethersubr.c:770 #11 0x8089c953 in ether_input (ifp=3D0x8ec1f000, m=3D0x8f3afe00) at /usr/src/sys/net/if_ethersubr.c:692 #12 0x8058a042 in bge_rxeof (sc=3D0x8ec2c000, rx_prod=3D12, holdlck=3D1) at /usr/src/sys/dev/bge/if_bge.c:3392 #13 0x8058c0c2 in bge_intr (xsc=3D0x8ec2c000) at /usr/src/sys/dev/bge/if_bge.c:3653 #14 0x807d64bb in ithread_loop (arg=3D0x8ec257b0) at /usr/src/sys/kern/kern_intr.c:1181 #15 0x807d2c59 in fork_exit (callout=3D0x807d6310 , arg=3D0x8ec257b0, frame=3D0x8e502d38) at /usr/src/sys/kern/kern_fork.c:811 #16 0x80af96c0 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:271 Fatal trap 12: page fault while in kernel mode cpuid =3D 0; apic id =3D 00 fault virtual address =3D 0xc fault code =3D supervisor read, page not present instruction pointer =3D 0x20:0xc084bde8 stack pointer =3D 0x28:0xcbb4c474 frame pointer =3D 0x28:0xcbb4c490 code segment =3D base 0x0, limit 0xfffff, type 0x1b =3D DPL 0, pres 1, def32 1, gran 1 processor eflags =3D interrupt enabled, resume, IOPL =3D 0 current process =3D 514 (ng_queue0) trap number =3D 12 (kgdb) bt #0 doadump () at pcpu.h:196 #1 0xc07f8c57 in boot (howto=3D260) at /usr/src/sys/kern/kern_ shutdown.c:418 #2 0xc07f8f29 in panic (fmt=3DVariable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:574 #3 0xc0b010dc in trap_fatal (frame=3D0xcbb4c434, eva=3D12) at /usr/src/sys/i386/i386/trap.c:950 #4 0xc0b01360 in trap_pfault (frame=3D0xcbb4c434, usermode=3D0, eva=3D12) = at /usr/src/sys/i386/i386/trap.c:863 #5 0xc0b01d55 in trap (frame=3D0xcbb4c434) at /usr/src/sys/i386/i386/trap.c:541 #6 0xc0ae503b in calltrap () at /usr/src/sys/i386/i386/exception.s:166 #7 0xc084bde8 in m_copydata (m=3D0x0, off=3D0, len=3D164, cp=3D0xcca98a5c = "") at /usr/src/sys/kern/uipc_mbuf.c:815 #8 0xc08e1398 in ip_forward (m=3D0xcd7bed00, srcrt=3D0) at /usr/src/sys/netinet/ip_input.c:1307 #9 0xc08e2b00 in ip_input (m=3D0xcd7bed00) at /usr/src/sys/netinet/ip_input.c:609 #10 0xc08a78a5 in netisr_dispatch (num=3D2, m=3D0xcd7bed00) at /usr/src/sys/net/netisr.c:185 #11 0xcc6dfdc5 in ng_iface_rcvdata (hook=3D0xcc802280, item=3D0xcc4442a0) at /usr/src/sys/modules/netgraph/iface/../../../netgraph/ng_iface.c:777 #12 0xcc3fc7e4 in ng_apply_item (node=3D0xcc887700, item=3D0xcc4442a0, rw= =3D0) at /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:2336 #13 0xcc3fb7ec in ng_snd_item (item=3D0xcc4442a0, flags=3DVariable "flags" = is not available. ) at /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:2254 #14 0xcc3fc7e4 in ng_apply_item (node=3D0xcc837080, item=3D0xcc4442a0, rw= =3D0) at /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:2336 #15 0xcc3fb7ec in ng_snd_item (item=3D0xcc4442a0, flags=3DVariable "flags" = is not available. ) at /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:2254 #16 0xcc6f5266 in ng_car_rcvdata (hook=3D0xcc842200, item=3D0xcc4442a0) at /usr/src/sys/modules/netgraph/car/../../../netgraph/ng_car.c:367 #17 0xcc3fc7e4 in ng_apply_item (node=3D0xcc837100, item=3D0xcc4442a0, rw= =3D0) at /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:2336 #18 0xcc3fb7ec in ng_snd_item (item=3D0xcc4442a0, flags=3DVariable "flags" = is not available. ) at /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:2254 #19 0xcc3fc7e4 in ng_apply_item (node=3D0xcc837080, item=3D0xcc4442a0, rw= =3D0) at /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:2336 #20 0xcc3fb7ec in ng_snd_item (item=3D0xcc4442a0, flags=3DVariable "flags" = is not available. ) at /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:2254 #21 0xcc3fc7e4 in ng_apply_item (node=3D0xcc7c9d00, item=3D0xcc4442a0, rw= =3D0) at /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:2336 #22 0xcc3fb7ec in ng_snd_item (item=3D0xcc4442a0, flags=3DVariable "flags" = is not available. ) at /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:2254 #23 0xcc6e3ca0 in ng_ppp_proto_recv (node=3D0xcc872180, item=3D0xcc4442a0, proto=3DVariable "proto" is not available. ) at /usr/src/sys/modules/netgraph/ppp/../../../netgraph/ng_ppp.c:934 #24 0xcc6e4995 in ng_ppp_rcvdata (hook=3D0xcc884c80, item=3D0xcc4442a0) at /usr/src/sys/modules/netgraph/ppp/../../../netgraph/ng_ppp.c:1509 #25 0xcc3fc7e4 in ng_apply_item (node=3D0xcc872180, item=3D0xcc4442a0, rw= =3D0) at /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:2336 #26 0xcc3fb7ec in ng_snd_item (item=3D0xcc4442a0, flags=3DVariable "flags" = is not available. ) at /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:2254 #27 0xcc3fc7e4 in ng_apply_item (node=3D0xcc86f180, item=3D0xcc4442a0, rw= =3D0) ---Type to continue, or q to quit--- at /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:2336 #28 0xcc3fb7ec in ng_snd_item (item=3D0xcc4442a0, flags=3DVariable "flags" = is not available. ) at /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:2254 #29 0xcc3fc7e4 in ng_apply_item (node=3D0xcc85ca80, item=3D0xcc4442a0, rw= =3D0) at /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:2336 #30 0xcc3fb7ec in ng_snd_item (item=3D0xcc4442a0, flags=3DVariable "flags" = is not available. ) at /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:2254 #31 0xcc6db8bc in ng_ksocket_incoming2 (node=3D0xcc85c880, hook=3D0x0, arg1=3D0xcc7e5680, arg2=3D0) at /usr/src/sys/modules/netgraph/ksocket/../../../netgraph/ng_ksocket.c:1143 #32 0xcc3fc91b in ng_apply_item (node=3D0xcc85c880, item=3D0xcc47d5a0, rw= =3D1) at /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:2407 #33 0xcc3fdaaf in ngthread (arg=3D0x0) at /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:3304 #34 0xc07d1c49 in fork_exit (callout=3D0xcc3fd940 , arg=3D0x0, frame=3D0xcbb4cd38) at /usr/src/sys/kern/kern_fork.c:811 #35 0xc0ae50b0 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:271 (kgdb) frame 8 #8 0xc08e1398 in ip_forward (m=3D0xcd7bed00, srcrt=3D0) at /usr/src/sys/netinet/ip_input.c:1307 1307 m_copydata(m, 0, mcopy->m_len, mtod(mcopy, caddr_t)); (kgdb) p *ip $1 =3D {ip_hl =3D 5, ip_v =3D 4, ip_tos =3D 0 '\0', ip_len =3D 10240, ip_id= =3D 2126, ip_off =3D 64, ip_ttl =3D 128 '\200', ip_p =3D 6 '\006', ip_sum =3D 28842, ip_src =3D {s_addr =3D 3641104562}, = ip_dst =3D {s_addr =3D 3958028893}} (kgdb) Fatal trap 12: page fault while in kernel mode cpuid =3D 1; apic id =3D 06 fault virtual address =3D 0xc fault code =3D supervisor read, page not present instruction pointer =3D 0x20:0xc084cfd6 stack pointer =3D 0x28:0xcba6ea50 frame pointer =3D 0x28:0xcba6ea7c code segment =3D base 0x0, limit 0xfffff, type 0x1b =3D DPL 0, pres 1, def32 1, gran 1 processor eflags =3D interrupt enabled, resume, IOPL =3D 0 current process =3D 27 (irq26: bge1) trap number =3D 12 (kgdb) bt #0 doadump () at pcpu.h:196 #1 0xc07f8c57 in boot (howto=3D260) at /usr/src/sys/kern/kern_shutdown.c:4= 18 #2 0xc07f8f29 in panic (fmt=3DVariable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:574 #3 0xc0b010dc in trap_fatal (frame=3D0xcba6ea10, eva=3D12) at /usr/src/sys/i386/i386/trap.c:950 #4 0xc0b01360 in trap_pfault (frame=3D0xcba6ea10, usermode=3D0, eva=3D12) = at /usr/src/sys/i386/i386/trap.c:863 #5 0xc0b01d55 in trap (frame=3D0xcba6ea10) at /usr/src/sys/i386/i386/trap.c:541 #6 0xc0ae503b in calltrap () at /usr/src/sys/i386/i386/exception.s:166 #7 0xc084cfd6 in m_copym (m=3D0x0, off0=3D2772, len=3D1376, wait=3D1) at /usr/src/sys/kern/uipc_mbuf.c:539 #8 0xc08e3aa5 in ip_fragment (ip=3D0xccb5e810, m_frag=3D0xcba6eb44, mtu=3D= 1400, if_hwassist_flags=3D0, sw_csum=3D1) at /usr/src/sys/netinet/ip_output.c:731 #9 0xc08e46d2 in ip_output (m=3D0xcde4fa00, opt=3D0x0, ro=3D0xcba6eb7c, fl= ags=3D1, imo=3D0x0, inp=3D0x0) at /usr/src/sys/netinet/ip_output.c:570 #10 0xc08e1554 in ip_forward (m=3D0xcde4fa00, srcrt=3D0) at /usr/src/sys/netinet/ip_input.c:1366 #11 0xc08e2b00 in ip_input (m=3D0xcde4fa00) at /usr/src/sys/netinet/ip_input.c:609 #12 0xc08a78a5 in netisr_dispatch (num=3D2, m=3D0xcde4fa00) at /usr/src/sys/net/netisr.c:185 #13 0xc089b551 in ether_demux (ifp=3D0xcbefd000, m=3D0xcde4fa00) at /usr/src/sys/net/if_ethersubr.c:834 #14 0xc089b943 in ether_input (ifp=3D0xcbefd000, m=3D0xcde4fa00) at /usr/src/sys/net/if_ethersubr.c:692 #15 0xc0589032 in bge_rxeof (sc=3D0xcbf07000, rx_prod=3D439, holdlck=3D1) a= t /usr/src/sys/dev/bge/if_bge.c:3392 #16 0xc058b0b2 in bge_intr (xsc=3D0xcbf07000) at /usr/src/sys/dev/bge/if_bge.c:3653 #17 0xc07d54ab in ithread_loop (arg=3D0xcbf037b0) at /usr/src/sys/kern/kern_intr.c:1181 #18 0xc07d1c49 in fork_exit (callout=3D0xc07d5300 , arg=3D0xcbf037b0, frame=3D0xcba6ed38) at /usr/src/sys/kern/kern_fork.c:811 #19 0xc0ae50b0 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:271 (kgdb) frame 8 #8 0xc08e3aa5 in ip_fragment (ip=3D0xccb5e810, m_frag=3D0xcba6eb44, mtu=3D= 1400, if_hwassist_flags=3D0, sw_csum=3D1) at /usr/src/sys/netinet/ip_output.c:731 731 m->m_next =3D m_copy(m0, off, len); (kgdb) p *ip $1 =3D {ip_hl =3D 5, ip_v =3D 4, ip_tos =3D 0 '\0', ip_len =3D 30725, ip_id= =3D 43824, ip_off =3D 64, ip_ttl =3D 51 '3', ip_p =3D 6 '\006', ip_sum =3D 2651, ip_src =3D {s_addr =3D 2377912389}, ip_dst =3D {s_addr = =3D 1426184370}} Fatal trap 12: page fault while in kernel mode cpuid =3D 0; apic id =3D 00 fault virtual address =3D 0xc fault code =3D supervisor read, page not present instruction pointer =3D 0x20:0xc084cfd6 stack pointer =3D 0x28:0xcba5ba50 frame pointer =3D 0x28:0xcba5ba7c code segment =3D base 0x0, limit 0xfffff, type 0x1b =3D DPL 0, pres 1, def32 1, gran 1 processor eflags =3D interrupt enabled, resume, IOPL =3D 0 current process =3D 23 (irq26: bge1) trap number =3D 12 #0 doadump () at pcpu.h:196 #1 0xc07f8c57 in boot (howto=3D260) at /usr/src/sys/kern/kern_shutdown.c:4= 18 #2 0xc07f8f29 in panic (fmt=3DVariable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:574 #3 0xc0b010dc in trap_fatal (frame=3D0xcba5ba10, eva=3D12) at /usr/src/sys/i386/i386/trap.c:950 #4 0xc0b01360 in trap_pfault (frame=3D0xcba5ba10, usermode=3D0, eva=3D12) = at /usr/src/sys/i386/i386/trap.c:863 #5 0xc0b01d55 in trap (frame=3D0xcba5ba10) at /usr/src/sys/i386/i386/trap.c:541 #6 0xc0ae503b in calltrap () at /usr/src/sys/i386/i386/exception.s:166 #7 0xc084cfd6 in m_copym (m=3D0x0, off0=3D16380, len=3D3332, wait=3D1) at /usr/src/sys/kern/uipc_mbuf.c:539 #8 0xc08e3aa5 in ip_fragment (ip=3D0xcc45d810, m_frag=3D0xcba5bb44, mtu=3D= 16384, if_hwassist_flags=3D0, sw_csum=3D1) at /usr/src/sys/netinet/ip_output.c:731 #9 0xc08e46d2 in ip_output (m=3D0xcc2bb000, opt=3D0x0, ro=3D0xcba5bb7c, fl= ags=3D1, imo=3D0x0, inp=3D0x0) at /usr/src/sys/netinet/ip_output.c:570 #10 0xc08e1554 in ip_forward (m=3D0xcc2bb000, srcrt=3D0) at /usr/src/sys/netinet/ip_input.c:1366 #11 0xc08e2b00 in ip_input (m=3D0xcc2bb000) at /usr/src/sys/netinet/ip_input.c:609 #12 0xc08a78a5 in netisr_dispatch (num=3D2, m=3D0xcc2bb000) at /usr/src/sys/net/netisr.c:185 #13 0xc089b551 in ether_demux (ifp=3D0xcbec9c00, m=3D0xcc2bb000) at /usr/src/sys/net/if_ethersubr.c:834 #14 0xc089b943 in ether_input (ifp=3D0xcbec9c00, m=3D0xcc2bb000) at /usr/src/sys/net/if_ethersubr.c:692 #15 0xc0589032 in bge_rxeof (sc=3D0xcbedf000, rx_prod=3D333, holdlck=3D1) a= t /usr/src/sys/dev/bge/if_bge.c:3392 #16 0xc058b0b2 in bge_intr (xsc=3D0xcbedf000) at /usr/src/sys/dev/bge/if_bge.c:3653 #17 0xc07d54ab in ithread_loop (arg=3D0xcbed44c0) at /usr/src/sys/kern/kern_intr.c:1181 #18 0xc07d1c49 in fork_exit (callout=3D0xc07d5300 , arg=3D0xcbed44c0, frame=3D0xcba5bd38) at /usr/src/sys/kern/kern_fork.c:811 #19 0xc0ae50b0 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:271 (kgdb) frame 8 #8 0xc08e3aa5 in ip_fragment (ip=3D0xcc45d810, m_frag=3D0xcba5bb44, mtu=3D= 16384, if_hwassist_flags=3D0, sw_csum=3D1) at /usr/src/sys/netinet/ip_output.c:731 731 m->m_next =3D m_copy(m0, off, len); (kgdb) p *ip $1 =3D {ip_hl =3D 5, ip_v =3D 4, ip_tos =3D 0 '\0', ip_len =3D 19712, ip_id= =3D 18546, ip_off =3D 0, ip_ttl =3D 126 '~', ip_p =3D 47 '/', ip_sum =3D 49301, ip_src =3D {s_addr =3D 2132803594}, ip_dst =3D {s_addr = =3D 4210950154}} Fatal trap 12: page fault while in kernel mode cpuid =3D 0; apic id =3D 00 fault virtual address =3D 0xc fault code =3D supervisor read, page not present instruction pointer =3D 0x20:0xc084cfd6 stack pointer =3D 0x28:0xcbae93a4 frame pointer =3D 0x28:0xcbae93d0 code segment =3D base 0x0, limit 0xfffff, type 0x1b =3D DPL 0, pres 1, def32 1, gran 1 processor eflags =3D interrupt enabled, resume, IOPL =3D 0 current process =3D 505 (ng_queue1) trap number =3D 12 (kgdb) bt #0 doadump () at pcpu.h:196 #1 0xc07f8c57 in boot (howto=3D260) at /usr/src/sys/kern/kern_shutdown.c:4= 18 #2 0xc07f8f29 in panic (fmt=3DVariable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:574 #3 0xc0b010dc in trap_fatal (frame=3D0xcbae9364, eva=3D12) at /usr/src/sys/i386/i386/trap.c:950 #4 0xc0b01360 in trap_pfault (frame=3D0xcbae9364, usermode=3D0, eva=3D12) = at /usr/src/sys/i386/i386/trap.c:863 #5 0xc0b01d55 in trap (frame=3D0xcbae9364) at /usr/src/sys/i386/i386/trap.c:541 #6 0xc0ae503b in calltrap () at /usr/src/sys/i386/i386/exception.s:166 #7 0xc084cfd6 in m_copym (m=3D0x0, off0=3D1500, len=3D1480, wait=3D1) at /usr/src/sys/kern/uipc_mbuf.c:539 #8 0xc08e3aa5 in ip_fragment (ip=3D0xcc29e835, m_frag=3D0xcbae9498, mtu=3D= 1500, if_hwassist_flags=3D0, sw_csum=3D1) at /usr/src/sys/netinet/ip_output.c:731 #9 0xc08e46d2 in ip_output (m=3D0xcc270500, opt=3D0x0, ro=3D0xcbae94d0, fl= ags=3D1, imo=3D0x0, inp=3D0x0) at /usr/src/sys/netinet/ip_output.c:570 #10 0xc08e1554 in ip_forward (m=3D0xcc270500, srcrt=3D0) at /usr/src/sys/netinet/ip_input.c:1366 #11 0xc08e2b00 in ip_input (m=3D0xcc270500) at /usr/src/sys/netinet/ip_input.c:609 #12 0xc08a78a5 in netisr_dispatch (num=3D2, m=3D0xcc270500) at /usr/src/sys/net/netisr.c:185 #13 0xcc689dc5 in ng_iface_rcvdata (hook=3D0xcc0f3c00, item=3D0xcc5270f0) at /usr/src/sys/modules/netgraph/iface/../../../netgraph/ng_iface.c:777 #14 0xcc4b17e4 in ng_apply_item (node=3D0xcc6b3100, item=3D0xcc5270f0, rw= =3D0) at /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:2336 #15 0xcc4b07ec in ng_snd_item (item=3D0xcc5270f0, flags=3DVariable "flags" = is not available. ) at /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:2254 #16 0xcc4b17e4 in ng_apply_item (node=3D0xcc71b600, item=3D0xcc5270f0, rw= =3D0) at /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:2336 #17 0xcc4b07ec in ng_snd_item (item=3D0xcc5270f0, flags=3DVariable "flags" = is not available. ) at /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:2254 #18 0xcc6a5266 in ng_car_rcvdata (hook=3D0xcc6b2a80, item=3D0xcc5270f0) at /usr/src/sys/modules/netgraph/car/../../../netgraph/ng_car.c:367 #19 0xcc4b17e4 in ng_apply_item (node=3D0xcc6b1380, item=3D0xcc5270f0, rw= =3D0) at /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:2336 #20 0xcc4b07ec in ng_snd_item (item=3D0xcc5270f0, flags=3DVariable "flags" = is not available. ) at /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:2254 #21 0xcc4b17e4 in ng_apply_item (node=3D0xcc71b600, item=3D0xcc5270f0, rw= =3D0) at /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:2336 #22 0xcc4b07ec in ng_snd_item (item=3D0xcc5270f0, flags=3DVariable "flags" = is not available. ) at /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:2254 #23 0xcc4b17e4 in ng_apply_item (node=3D0xcc798d80, item=3D0xcc5270f0, rw= =3D0) at /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:2336 #24 0xcc4b07ec in ng_snd_item (item=3D0xcc5270f0, flags=3DVariable "flags" = is not available. ) at /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:2254 #25 0xcc692ca0 in ng_ppp_proto_recv (node=3D0xcc681a80, item=3D0xcc5270f0, proto=3DVariable "proto" is not available. ) at /usr/src/sys/modules/netgraph/ppp/../../../netgraph/ng_ppp.c:934 #26 0xcc693995 in ng_ppp_rcvdata (hook=3D0xcc680d80, item=3D0xcc5270f0) at /usr/src/sys/modules/netgraph/ppp/../../../netgraph/ng_ppp.c:1509 #27 0xcc4b17e4 in ng_apply_item (node=3D0xcc681a80, item=3D0xcc5270f0, rw= =3D0) ---Type to continue, or q to quit--- at /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:2336 #28 0xcc4b07ec in ng_snd_item (item=3D0xcc5270f0, flags=3DVariable "flags" = is not available. ) at /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:2254 #29 0xcc4b17e4 in ng_apply_item (node=3D0xcc6b2d80, item=3D0xcc5270f0, rw= =3D0) at /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:2336 #30 0xcc4b07ec in ng_snd_item (item=3D0xcc5270f0, flags=3DVariable "flags" = is not available. ) at /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:2254 #31 0xcc4b17e4 in ng_apply_item (node=3D0xcc6ace80, item=3D0xcc5270f0, rw= =3D0) at /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:2336 #32 0xcc4b07ec in ng_snd_item (item=3D0xcc5270f0, flags=3DVariable "flags" = is not available. ) at /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:2254 #33 0xcc5568bc in ng_ksocket_incoming2 (node=3D0xcc6ac980, hook=3D0x0, arg1=3D0xcc76dd00, arg2=3D0) at /usr/src/sys/modules/netgraph/ksocket/../../../netgraph/ng_ksocket.c:1143 #34 0xcc4b191b in ng_apply_item (node=3D0xcc6ac980, item=3D0xcc515d20, rw= =3D1) at /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:2407 #35 0xcc4b2aaf in ngthread (arg=3D0x0) at /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:3304 #36 0xc07d1c49 in fork_exit (callout=3D0xcc4b2940 , arg=3D0x0, frame=3D0xcbae9d38) at /usr/src/sys/kern/kern_fork.c:811 #37 0xc0ae50b0 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:271 (kgdb) frame 8 #8 0xc08e3aa5 in ip_fragment (ip=3D0xcc29e835, m_frag=3D0xcbae9498, mtu=3D= 1500, if_hwassist_flags=3D0, sw_csum=3D1) at /usr/src/sys/netinet/ip_output.c:731 731 m->m_next =3D m_copy(m0, off, len); (kgdb) p *ip $1 =3D {ip_hl =3D 5, ip_v =3D 4, ip_tos =3D 0 '\0', ip_len =3D 14848, ip_id= =3D 1822, ip_off =3D 0, ip_ttl =3D 127 '\177', ip_p =3D 17 '\021', ip_sum =3D 42256, ip_src =3D {s_addr =3D 3120879794},= ip_dst =3D {s_addr =3D 519394911}} Fatal trap 12: page fault while in kernel mode cpuid =3D 0; apic id =3D 00 fault virtual address =3D 0xc fault code =3D supervisor read, page not present instruction pointer =3D 0x20:0xc084cfd6 stack pointer =3D 0x28:0xcba78a50 frame pointer =3D 0x28:0xcba78a7c code segment =3D base 0x0, limit 0xfffff, type 0x1b =3D DPL 0, pres 1, def32 1, gran 1 processor eflags =3D interrupt enabled, resume, IOPL =3D 0 current process =3D 29 (irq26: bge1) trap number =3D 12 #0 doadump () at pcpu.h:196 #1 0xc07f8c57 in boot (howto=3D260) at /usr/src/sys/kern/kern_shutdown.c:4= 18 #2 0xc07f8f29 in panic (fmt=3DVariable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:574 #3 0xc0b010dc in trap_fatal (frame=3D0xcba78a10, eva=3D12) at /usr/src/sys/i386/i386/trap.c:950 #4 0xc0b01360 in trap_pfault (frame=3D0xcba78a10, usermode=3D0, eva=3D12) = at /usr/src/sys/i386/i386/trap.c:863 #5 0xc0b01d55 in trap (frame=3D0xcba78a10) at /usr/src/sys/i386/i386/trap.c:541 #6 0xc0ae503b in calltrap () at /usr/src/sys/i386/i386/exception.s:166 #7 0xc084cfd6 in m_copym (m=3D0x0, off0=3D16380, len=3D9476, wait=3D1) at /usr/src/sys/kern/uipc_mbuf.c:539 #8 0xc08e3aa5 in ip_fragment (ip=3D0xcd7c5010, m_frag=3D0xcba78b44, mtu=3D= 16384, if_hwassist_flags=3D0, sw_csum=3D3073) at /usr/src/sys/netinet/ip_output.c:731 #9 0xc08e46d2 in ip_output (m=3D0xcd8fc300, opt=3D0x0, ro=3D0xcba78b7c, fl= ags=3D1, imo=3D0x0, inp=3D0x0) at /usr/src/sys/netinet/ip_output.c:570 #10 0xc08e1554 in ip_forward (m=3D0xcd8fc300, srcrt=3D0) at /usr/src/sys/netinet/ip_input.c:1366 #11 0xc08e2b00 in ip_input (m=3D0xcd8fc300) at /usr/src/sys/netinet/ip_input.c:609 #12 0xc08a78a5 in netisr_dispatch (num=3D2, m=3D0xcd8fc300) at /usr/src/sys/net/netisr.c:185 #13 0xc089b551 in ether_demux (ifp=3D0xcbefd000, m=3D0xcd8fc300) at /usr/src/sys/net/if_ethersubr.c:834 #14 0xc089b943 in ether_input (ifp=3D0xcbefd000, m=3D0xcd8fc300) at /usr/src/sys/net/if_ethersubr.c:692 #15 0xc0589032 in bge_rxeof (sc=3D0xcbf0b000, rx_prod=3D514, holdlck=3D1) a= t /usr/src/sys/dev/bge/if_bge.c:3392 #16 0xc058b0b2 in bge_intr (xsc=3D0xcbf0b000) at /usr/src/sys/dev/bge/if_bge.c:3653 #17 0xc07d54ab in ithread_loop (arg=3D0xcbf037b0) at /usr/src/sys/kern/kern_intr.c:1181 #18 0xc07d1c49 in fork_exit (callout=3D0xc07d5300 , arg=3D0xcbf037b0, frame=3D0xcba78d38) at /usr/src/sys/kern/kern_fork.c:811 #19 0xc0ae50b0 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:271 (kgdb) frame 8 #8 0xc08e3aa5 in ip_fragment (ip=3D0xcd7c5010, m_frag=3D0xcba78b44, mtu=3D= 16384, if_hwassist_flags=3D0, sw_csum=3D3073) at /usr/src/sys/netinet/ip_output.c:731 731 m->m_next =3D m_copy(m0, off, len); (kgdb) p *ip $1 =3D {ip_hl =3D 5, ip_v =3D 4, ip_tos =3D 0 '\0', ip_len =3D 25856, ip_id= =3D 16977, ip_off =3D 0, ip_ttl =3D 126 '~', ip_p =3D 47 '/', ip_sum =3D 12998, ip_src =3D {s_addr =3D 4212129802}, ip_dst =3D {s_addr = =3D 4210950154}} From owner-freebsd-stable@FreeBSD.ORG Wed May 12 13:35:53 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 563231065670 for ; Wed, 12 May 2010 13:35:53 +0000 (UTC) (envelope-from demelier.david@gmail.com) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by mx1.freebsd.org (Postfix) with ESMTP id D76AF8FC13 for ; Wed, 12 May 2010 13:35:52 +0000 (UTC) Received: by fxm7 with SMTP id 7so64413fxm.17 for ; Wed, 12 May 2010 06:35:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=yPplcUV5Hf3q4LdhtxNvqrqvcm9G1dYrryeEJKA8Tzw=; b=l+36GwZgKHElYI6dcACppGVgHXGwwGlFmjULsbph9PbaKwyxuFJVARZNRz7PEAVTPM sa4ceIhGOxC21tyDF/ZmDCm+q0PXHhkbcGZSBxvoGH99TwT1JyBjbIkp1f6kzzmbH7Mw 3I4MoMHGBH+1wRgyKQO/++ywWMq015nL1XQyw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=bCyIZrb6xdFgEj2JNzsfWw1F4JMO3Bds0NumJx7mPTN/JBOXOVukw3SoslOyGyET98 ov1GkFWKAezRqEWqAFmHINrhLTZ7Z+EUvdp6c0m3iqZuzzILfiWFX5pYmEm+PHHHl92m 5CBs24+Qj1LJSZQMPh4a18j5hOgHaO5t3G4cM= MIME-Version: 1.0 Received: by 10.204.162.133 with SMTP id v5mr1181918bkx.60.1273671351591; Wed, 12 May 2010 06:35:51 -0700 (PDT) Received: by 10.204.77.15 with HTTP; Wed, 12 May 2010 06:35:51 -0700 (PDT) In-Reply-To: References: <4DEBDE2C-C0D2-469D-AC42-DD5027926424@FreeBSD.org> <20100507120843.GA1738@Melon.malikania.fr> <1273257226.1671.3.camel@malikania.fr> Date: Wed, 12 May 2010 15:35:51 +0200 Message-ID: From: David DEMELIER To: Giovanni Trematerra Content-Type: text/plain; charset=UTF-8 Cc: freebsd-stable@freebsd.org Subject: Re: Kernel panic when unpluggin AC adaptor X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 May 2010 13:35:53 -0000 Hi, I tested your patch and it didn't panic. I checked the dev.cpu sysctl nodes to see if the CPU freq is changing or not. I unplugged the cable : markand@Melon ~ $ sysctl dev.cpu dev.cpu.0.%desc: ACPI CPU dev.cpu.0.%driver: cpu dev.cpu.0.%location: handle=\_PR_.CPU0 dev.cpu.0.%pnpinfo: _HID=none _UID=0 dev.cpu.0.%parent: acpi0 dev.cpu.0.freq: 450 dev.cpu.0.freq_levels: 2101/35000 1837/30625 1600/23888 1400/20902 1200/15000 1050/13125 900/11250 750/9375 600/7500 450/5625 300/3750 150/1875 dev.cpu.0.cx_supported: C1/1 C2/1 C3/162 dev.cpu.0.cx_lowest: C3 dev.cpu.0.cx_usage: 0.00% 99.99% 0.00% last 131us dev.cpu.1.%desc: ACPI CPU dev.cpu.1.%driver: cpu dev.cpu.1.%location: handle=\_PR_.CPU1 dev.cpu.1.%pnpinfo: _HID=none _UID=0 dev.cpu.1.%parent: acpi0 dev.cpu.1.cx_supported: C1/1 C2/1 C3/162 dev.cpu.1.cx_lowest: C3 dev.cpu.1.cx_usage: 0.00% 99.99% 0.00% last 260us I plugged the cable : markand@Melon ~ $ sysctl dev.cpu dev.cpu.0.%desc: ACPI CPU dev.cpu.0.%driver: cpu dev.cpu.0.%location: handle=\_PR_.CPU0 dev.cpu.0.%pnpinfo: _HID=none _UID=0 dev.cpu.0.%parent: acpi0 dev.cpu.0.freq: 2101 dev.cpu.0.freq_levels: 2101/35000 1837/30625 1600/23888 1400/20902 1200/15000 1050/13125 900/11250 750/9375 600/7500 450/5625 300/3750 150/1875 dev.cpu.0.cx_supported: C1/1 C2/57 dev.cpu.0.cx_lowest: C1 dev.cpu.0.cx_usage: 100.00% 0.00% last 497us dev.cpu.1.%desc: ACPI CPU dev.cpu.1.%driver: cpu dev.cpu.1.%location: handle=\_PR_.CPU1 dev.cpu.1.%pnpinfo: _HID=none _UID=0 dev.cpu.1.%parent: acpi0 dev.cpu.1.cx_supported: C1/1 C2/57 dev.cpu.1.cx_lowest: C1 dev.cpu.1.cx_usage: 100.00% 0.00% last 497us Of course I enabled # Little power management. performance_cx_lowest="HIGH" performance_cpu_freq=${performance_cx_lowest} economy_cx_lowest="LOW" economy_cpu_freq=${economy_cx_lowest} in my /etc/rc.conf, it the behavior expected ? Thanks for your answers :-). -- Demelier David From owner-freebsd-stable@FreeBSD.ORG Wed May 12 14:14:23 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 92454106564A for ; Wed, 12 May 2010 14:14:23 +0000 (UTC) (envelope-from giovanni.trematerra@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 1F1CB8FC0A for ; Wed, 12 May 2010 14:14:22 +0000 (UTC) Received: by fxm1 with SMTP id 1so113808fxm.13 for ; Wed, 12 May 2010 07:14:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=9itA9Ac7xmPi17BAuaR6BNlsHbLHQLJWPAuxOfRLKrY=; b=oMSdQT4QBt5Z/fFC5ZxoK57SKk933hUGjdmCVukigU7OTH4rVpucswjlD+OX28rmwY w+GOQP7YinZOJAxsOh0RrUm1S5lZ13X0PFT62vHMMC1YpBLU5zyjtnBnBFa9nEyvFh/C FxnIpGF3GNdgGCEDPzOTZOzRNR2a+EtaxCUok= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=IzE4f5kQ2CidO6PbSOFy6a6bJeIUbs8Oog+68TKxagz4sTcUXGAE4nJ487GZzdejUY v+iv0TMwAUi9CBjCm2mMRwK8Q1CygKjwojpmRksCFrNYrhNEBF0HqU64CU/CO0HsT1fQ nwyFsXQ1NXtos7DesPfZQdJTU5+uLdBFRFksw= MIME-Version: 1.0 Received: by 10.223.117.164 with SMTP id r36mr8268081faq.28.1273673661659; Wed, 12 May 2010 07:14:21 -0700 (PDT) Received: by 10.223.103.209 with HTTP; Wed, 12 May 2010 07:14:21 -0700 (PDT) In-Reply-To: References: <4DEBDE2C-C0D2-469D-AC42-DD5027926424@FreeBSD.org> <20100507120843.GA1738@Melon.malikania.fr> <1273257226.1671.3.camel@malikania.fr> Date: Wed, 12 May 2010 16:14:21 +0200 Message-ID: From: Giovanni Trematerra To: David DEMELIER Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-stable@freebsd.org Subject: Re: Kernel panic when unpluggin AC adaptor X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 May 2010 14:14:23 -0000 On Wed, May 12, 2010 at 3:35 PM, David DEMELIER wrote: > Hi, I tested your patch and it didn't panic. I checked the dev.cpu > sysctl nodes to see if the CPU freq is changing or not. > It's very odd. I did nothing to prevent panic. in fact you should have seen a panic. did you apply the patch on a vanilla src? Do you still get panic without the patch when you unplug your AC adapter? Thank you -- GIanni From owner-freebsd-stable@FreeBSD.ORG Wed May 12 14:17:02 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1385F106566C for ; Wed, 12 May 2010 14:17:02 +0000 (UTC) (envelope-from oberman@es.net) Received: from mailgw.es.net (mail1.es.net [198.129.252.210]) by mx1.freebsd.org (Postfix) with ESMTP id EE7688FC12 for ; Wed, 12 May 2010 14:17:01 +0000 (UTC) Received: from ptavv.es.net (ptavv.es.net [IPv6:2001:400:910::29]) by mailgw.es.net (8.14.3/8.14.3) with ESMTP id o4CDvPSs007998 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 12 May 2010 06:57:25 -0700 Received: from ptavv.es.net (localhost [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id 7D85F1CC24; Wed, 12 May 2010 06:57:24 -0700 (PDT) To: David DEMELIER In-reply-to: Your message of "Wed, 12 May 2010 15:35:51 +0200." Date: Wed, 12 May 2010 06:57:24 -0700 From: "Kevin Oberman" Message-Id: <20100512135724.7D85F1CC24@ptavv.es.net> X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5, 1.2.40, 4.0.166 definitions=2010-05-12_03:2010-02-06, 2010-05-12, 2010-05-12 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-0908210000 definitions=main-1005120065 Cc: Giovanni Trematerra , freebsd-stable@freebsd.org Subject: Re: Kernel panic when unpluggin AC adaptor X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 May 2010 14:17:02 -0000 > Date: Wed, 12 May 2010 15:35:51 +0200 > From: David DEMELIER > Sender: owner-freebsd-stable@freebsd.org > > Hi, I tested your patch and it didn't panic. I checked the dev.cpu > sysctl nodes to see if the CPU freq is changing or not. > > I unplugged the cable : > markand@Melon ~ $ sysctl dev.cpu > dev.cpu.0.%desc: ACPI CPU > dev.cpu.0.%driver: cpu > dev.cpu.0.%location: handle=\_PR_.CPU0 > dev.cpu.0.%pnpinfo: _HID=none _UID=0 > dev.cpu.0.%parent: acpi0 > dev.cpu.0.freq: 450 > dev.cpu.0.freq_levels: 2101/35000 1837/30625 1600/23888 1400/20902 > 1200/15000 1050/13125 900/11250 750/9375 600/7500 450/5625 300/3750 > 150/1875 > dev.cpu.0.cx_supported: C1/1 C2/1 C3/162 > dev.cpu.0.cx_lowest: C3 > dev.cpu.0.cx_usage: 0.00% 99.99% 0.00% last 131us > dev.cpu.1.%desc: ACPI CPU > dev.cpu.1.%driver: cpu > dev.cpu.1.%location: handle=\_PR_.CPU1 > dev.cpu.1.%pnpinfo: _HID=none _UID=0 > dev.cpu.1.%parent: acpi0 > dev.cpu.1.cx_supported: C1/1 C2/1 C3/162 > dev.cpu.1.cx_lowest: C3 > dev.cpu.1.cx_usage: 0.00% 99.99% 0.00% last 260us > > I plugged the cable : > > markand@Melon ~ $ sysctl dev.cpu > dev.cpu.0.%desc: ACPI CPU > dev.cpu.0.%driver: cpu > dev.cpu.0.%location: handle=\_PR_.CPU0 > dev.cpu.0.%pnpinfo: _HID=none _UID=0 > dev.cpu.0.%parent: acpi0 > dev.cpu.0.freq: 2101 > dev.cpu.0.freq_levels: 2101/35000 1837/30625 1600/23888 1400/20902 > 1200/15000 1050/13125 900/11250 750/9375 600/7500 450/5625 300/3750 > 150/1875 > dev.cpu.0.cx_supported: C1/1 C2/57 > dev.cpu.0.cx_lowest: C1 > dev.cpu.0.cx_usage: 100.00% 0.00% last 497us > dev.cpu.1.%desc: ACPI CPU > dev.cpu.1.%driver: cpu > dev.cpu.1.%location: handle=\_PR_.CPU1 > dev.cpu.1.%pnpinfo: _HID=none _UID=0 > dev.cpu.1.%parent: acpi0 > dev.cpu.1.cx_supported: C1/1 C2/57 > dev.cpu.1.cx_lowest: C1 > dev.cpu.1.cx_usage: 100.00% 0.00% last 497us > > Of course I enabled > > # Little power management. > performance_cx_lowest="HIGH" > performance_cpu_freq=${performance_cx_lowest} > economy_cx_lowest="LOW" > economy_cpu_freq=${economy_cx_lowest} > > in my /etc/rc.conf, it the behavior expected ? I won't say that it is expected, but it is not unusual. It looks like more and more laptops don't offer higher 'C' states when on AC power. My ThinkPad gives me C3 on AC power and adds C4 on battery. You have an awful lot of available frequencies. I really recommend turning off TCC/Throttling, if they are active. They don't really save power and can cause problems at low values. They also impact powerd's responsiveness to changes in CPU load. What you REALLY want are the true power management clock/voltage step which are usually between 2 and 6. My old T30 only had two. My not quite as old T43 has 5 ranging from 2 GHz down to 800 MHz. I really wish TCC and throttling would be disabled by default or totally removed. they were intended for thermal management, not power management. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 From owner-freebsd-stable@FreeBSD.ORG Wed May 12 14:39:20 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4E8D51065678 for ; Wed, 12 May 2010 14:39:20 +0000 (UTC) (envelope-from demelier.david@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id CE9FB8FC0A for ; Wed, 12 May 2010 14:39:19 +0000 (UTC) Received: by fxm1 with SMTP id 1so144611fxm.13 for ; Wed, 12 May 2010 07:39:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=q7KGMYqdlFkbU4hAaJIXS6dKuT+K38uw2bCwMENnuuA=; b=ZqxhZM32ZVg8FnadldCFplPOuNLHD/tOq4i4LQDIsuX1DjGGeSPqZ2c3xk6r98wDpS H0W8cTr8eWQ8xYSaq26nR0jRnpqVPPvJynSnE6VvaSbJcTg6l0IPnzZQZgCbuhN1fAqX w0+AmW7U/YPuHOP/N7frtY306C3G3/81kGI0k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=WGoP8tqJt57zc5/PvaNVAmYuVD07WYHliurHP8LIPAqbHsC7u/Y5IlUmZuMo6Eb4cC MlmE0EwofNpjtTTAyuOP0Ew4mpZINwpbGZN74rcdd+p2M5eyCDuYoSI/9s1J/PoKEWjd SOWLoPxuxxC0DaJ+LNsCXvxDTifnnnU/HDTN4= MIME-Version: 1.0 Received: by 10.204.81.134 with SMTP id x6mr782932bkk.32.1273675158579; Wed, 12 May 2010 07:39:18 -0700 (PDT) Received: by 10.204.77.15 with HTTP; Wed, 12 May 2010 07:39:18 -0700 (PDT) In-Reply-To: References: <4DEBDE2C-C0D2-469D-AC42-DD5027926424@FreeBSD.org> <20100507120843.GA1738@Melon.malikania.fr> <1273257226.1671.3.camel@malikania.fr> Date: Wed, 12 May 2010 16:39:18 +0200 Message-ID: From: David DEMELIER To: Giovanni Trematerra Content-Type: text/plain; charset=UTF-8 Cc: freebsd-stable@freebsd.org Subject: Re: Kernel panic when unpluggin AC adaptor X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 May 2010 14:39:20 -0000 I remove the patch, and built the kernel (I updated the src this morning) and it does not panic now. It's really odd. If it reappears soon I will tell you. Thanks. -- Demelier David From owner-freebsd-stable@FreeBSD.ORG Wed May 12 14:41:47 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B2FAA106567D for ; Wed, 12 May 2010 14:41:47 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-ew0-f224.google.com (mail-ew0-f224.google.com [209.85.219.224]) by mx1.freebsd.org (Postfix) with ESMTP id 3D2828FC26 for ; Wed, 12 May 2010 14:41:47 +0000 (UTC) Received: by ewy24 with SMTP id 24so50143ewy.13 for ; Wed, 12 May 2010 07:41:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=UW1R8GpMiehr3cweAJuUPVhw3YYrfebOCY/+fK91sSk=; b=IS9tYfWzqftm1G172FQ8F5lDl+LdJoEa5+cjE3xfReBeU49V1uIlEMIrPH+P36bXNk u1pU5Ewp4+p15h4aPBFOZszrSOB+hrtd3ECsUNEF1G8KPqt9OWpOERkDTPuMywB0gQQL v8xTuVWwc7EF22/2F+cNAhgLA/nLzfy+zlhoI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=LHkkNZJ28ICybO1TnTNYK3AgwVtW8EkGceFpoUQJDQCVGtj4M2kvizjNrMwOUNJWZ5 5/rUudR0rRHaMgrcwN90U4mZw+wTY8m4nVt3k+BHnlHldilNRWMpuIUApCYqfxzuhFC7 l2MqHvaBTdo1XZR9UKoNLinDLEb7g2vAaLjmw= MIME-Version: 1.0 Received: by 10.239.187.71 with SMTP id k7mr678489hbh.11.1273675306293; Wed, 12 May 2010 07:41:46 -0700 (PDT) Sender: asmrookie@gmail.com Received: by 10.239.129.207 with HTTP; Wed, 12 May 2010 07:41:46 -0700 (PDT) In-Reply-To: References: <4DEBDE2C-C0D2-469D-AC42-DD5027926424@FreeBSD.org> <20100507120843.GA1738@Melon.malikania.fr> <1273257226.1671.3.camel@malikania.fr> Date: Wed, 12 May 2010 16:41:46 +0200 X-Google-Sender-Auth: 60b2674c045ffcec Message-ID: From: Attilio Rao To: David DEMELIER Content-Type: text/plain; charset=UTF-8 Cc: Giovanni Trematerra , freebsd-stable@freebsd.org Subject: Re: Kernel panic when unpluggin AC adaptor X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 May 2010 14:41:47 -0000 2010/5/12 David DEMELIER : > I remove the patch, and built the kernel (I updated the src this > morning) and it does not panic now. It's really odd. If it reappears > soon I will tell you. I looked at the code with Giovanni and I have the feeling that the race with the idle thread may still be fatal. We need to fix that. Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-stable@FreeBSD.ORG Wed May 12 21:08:24 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5D92E106564A for ; Wed, 12 May 2010 21:08:24 +0000 (UTC) (envelope-from michaud.matthieu@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id E77908FC0A for ; Wed, 12 May 2010 21:08:23 +0000 (UTC) Received: by wyg36 with SMTP id 36so283654wyg.13 for ; Wed, 12 May 2010 14:08:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:content-type :content-transfer-encoding; bh=ud2k2IKmTdGOf9KD+wOYagNa1M5Y0Gr5Ewqx94YeLoQ=; b=bPhQy8hGb0eYTap6OtxdbowI666jRyxdM7J3EFaEoeVMCbA4Ev9YdlVIWFIu89Bh6+ NKV8jpNnFH27IzaYf/xcbFwTq/K4oS38ZQXqiiz5R8WSJxFUvfTSChCZpQcTBY2IiGda b26KdrDFV3mGFHBGtL3KilcS7FW/hABVFi8kQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; b=A++TEA9JrCPjBOLyXQUM306/oH/3Y4upd987pK6g1xBr9g1bcGXDmKn4+jzdq5WXyO MRNX9hc2GbqGmg4B+ACDYaC0nwm1sN0TSniPwShPCDbqBaY6fobc4RyLjZu8+X7dXCb+ fMvgsFa2ftlR7TkOqG1oU+wUcy9LMMp5Vm+AQ= Received: by 10.227.156.7 with SMTP id u7mr7276225wbw.143.1273696919851; Wed, 12 May 2010 13:41:59 -0700 (PDT) Received: from donut.nxdomain.fr (home.nxdomain.fr [82.66.115.22]) by mx.google.com with ESMTPS id y22sm3404600wby.17.2010.05.12.13.41.58 (version=SSLv3 cipher=RC4-MD5); Wed, 12 May 2010 13:41:58 -0700 (PDT) Message-ID: <4BEB1298.80408@nxdomain.fr> Date: Wed, 12 May 2010 22:42:00 +0200 From: Matthieu Michaud User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.9) Gecko/20100511 Thunderbird/3.0.4 MIME-Version: 1.0 To: stable@freebsd.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: OpenSSH 5.4 bug fixed in 5.5 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 May 2010 21:08:24 -0000 I would like to share a solution of a problem I faced with the current version of OpenSSH in 8-STABLE (5.4p1). Last upgrade of my system updated OpenSSH from 5.2p1 to 5.4p1 which has a regression for those using a non-default AuthorizedKeysFile option set to a relative path (".ssh/keys" in my case). If you are using the default you are not affected. As I had authentication mechanism restricted to public keys and this parameter expands to //.ssh/keys with the regression I wasn't able to access my server after restart. It's fixed in 5.5p1 which is not yet imported in the 8-STABLE branch. To get back this option working you either have to wait for 5.5p1 merge to 8-STABLE, install it yourself or import the following patch from the vendor and rebuild sshd. I opted for the last solution. Here's how I did it : cd /usr/src/crypto/openssh fetch -o - 'http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/servconf.c.diff?r1=1.207;r2=1.204' | patch cd /usr/src/secure/usr.sbin/sshd make obj depend make all make install Hope it helps, Matthieu From owner-freebsd-stable@FreeBSD.ORG Wed May 12 21:22:58 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 314751065677 for ; Wed, 12 May 2010 21:22:58 +0000 (UTC) (envelope-from peter@simons-rock.edu) Received: from hedwig.simons-rock.edu (hedwig.simons-rock.edu [208.81.88.14]) by mx1.freebsd.org (Postfix) with ESMTP id 0D8888FC16 for ; Wed, 12 May 2010 21:22:56 +0000 (UTC) Received: from cesium.hyperfine.info (c2.8d.5646.static.theplanet.com [70.86.141.194]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hedwig.simons-rock.edu (Postfix) with ESMTP id AEEA02BB346; Wed, 12 May 2010 17:22:55 -0400 (EDT) Date: Wed, 12 May 2010 17:22:54 -0400 From: "Peter C. Lai" To: Matthieu Michaud Message-ID: <20100512212254.GQ56212@cesium.hyperfine.info> References: <4BEB1298.80408@nxdomain.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4BEB1298.80408@nxdomain.fr> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: stable@freebsd.org Subject: Re: OpenSSH 5.4 bug fixed in 5.5 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 May 2010 21:22:58 -0000 Or install the version from ports and deactivate the base version... On 2010-05-12 10:42:00PM +0200, Matthieu Michaud wrote: > I would like to share a solution of a problem I faced with the current > version of OpenSSH in 8-STABLE (5.4p1). > > Last upgrade of my system updated OpenSSH from 5.2p1 to 5.4p1 which has a > regression for those using a non-default AuthorizedKeysFile option set to a > relative path (".ssh/keys" in my case). If you are using the default you > are not affected. > > As I had authentication mechanism restricted to public keys and this > parameter expands to //.ssh/keys with the regression I wasn't able to > access my server after restart. > > It's fixed in 5.5p1 which is not yet imported in the 8-STABLE branch. > > To get back this option working you either have to wait for 5.5p1 merge to > 8-STABLE, install it yourself or import the following patch from the vendor > and rebuild sshd. I opted for the last solution. Here's how I did it : > > cd /usr/src/crypto/openssh > > fetch -o - > 'http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/servconf.c.diff?r1=1.207;r2=1.204' > | patch > > cd /usr/src/secure/usr.sbin/sshd > make obj depend > make all > make install > > Hope it helps, > Matthieu > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" -- =========================================================== Peter C. Lai | Bard College at Simon's Rock Systems Administrator | 84 Alford Rd. Information Technology Svcs. | Gt. Barrington, MA 01230 USA peter AT simons-rock.edu | (413) 528-7428 =========================================================== From owner-freebsd-stable@FreeBSD.ORG Wed May 12 21:23:17 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F1A8E10657A5 for ; Wed, 12 May 2010 21:23:17 +0000 (UTC) (envelope-from stb@lassitu.de) Received: from gilb.zs64.net (gilb.zs64.net [212.12.50.234]) by mx1.freebsd.org (Postfix) with ESMTP id B94F88FC1D for ; Wed, 12 May 2010 21:23:17 +0000 (UTC) Received: by gilb.zs64.net (Postfix, from stb@lassitu.de) id BD3B86CC48; Wed, 12 May 2010 21:23:16 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Stefan Bethke In-Reply-To: Date: Wed, 12 May 2010 23:23:16 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Daniel O'Connor X-Mailer: Apple Mail (2.1078) Cc: FreeBSD Stable Subject: Re: .zfs directory broken on an FS X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 May 2010 21:23:18 -0000 Am 12.05.2010 um 02:09 schrieb Daniel O'Connor: > I recently switched over to ZFS at work and it seems pretty good (so = far at least!) however I was writing a script to do snapshots and one of = the file systems now gives.. >=20 > [cain 9:37] ~ >ls -la /usr/local/Genesis/archive/.zfs > ls: snapshot: Bad file descriptor > total 0 >=20 > Other file systems in the same pool work fine though.. > [cain 9:36] ~ >ll /usr/local/Genesis/MeteorData/.zfs/snapshot > total 4 > drwxrwxr-x 32 metdata radar 38 Mar 21 03:11 20100512-0900 >=20 > (All other snapshot directories are OK) This appears to be a long standing issue with no solution. I used to = get this a lot during daily rsync backups; since switching to a zfs = send/recv based script I don't get these problems anymore. Be aware that trying to unmount that snapshot or it's filesystem might = panic or hang the system, including when you try to reboot. Stefan --=20 Stefan Bethke Fon +49 151 14070811 From owner-freebsd-stable@FreeBSD.ORG Wed May 12 23:09:03 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C6D841065673; Wed, 12 May 2010 23:09:03 +0000 (UTC) (envelope-from jamesbrandongooch@gmail.com) Received: from mail-pv0-f182.google.com (mail-pv0-f182.google.com [74.125.83.182]) by mx1.freebsd.org (Postfix) with ESMTP id 71C048FC0C; Wed, 12 May 2010 23:09:02 +0000 (UTC) Received: by pvf33 with SMTP id 33so458466pvf.13 for ; Wed, 12 May 2010 16:09:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=zWptNo4KrIuhul/CbVpaBFzYqxH7bP6++33a7I3TGdY=; b=NoSBGlSN4q5YXhd1ZTEqojHGllInWV4I409Vd6UgdgoM2nTzgz2VgyR1XIzSJlgwzF iooFTHhXlRpXJ6075OUjUfZmvpYEzHNPB6BJ2LEyYP4JbaLCZ/1XswXZ54gNbivdSyh0 CTVPMYJn2RGIfIAG09I1GusFC0mv6ZG60fQF4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=ASbRluvz1x/L0EVIt+hwz10Kj/kOCqYEnVxU/wZlxGEFMbGrsBgBhGZt4AUviXKuT/ zCK7tbbvoe1vTXfkPk/Oh3gzUu9P1gfwyQfejWCYm0CdK96vR7xJwAvgieouPwnasBzI Icq4gEveqsfqtRxoEQAUzzku3mn1k0HmY6oFA= MIME-Version: 1.0 Received: by 10.143.26.20 with SMTP id d20mr5669411wfj.31.1273705742210; Wed, 12 May 2010 16:09:02 -0700 (PDT) Received: by 10.142.52.15 with HTTP; Wed, 12 May 2010 16:09:02 -0700 (PDT) In-Reply-To: References: <4DEBDE2C-C0D2-469D-AC42-DD5027926424@FreeBSD.org> <20100507120843.GA1738@Melon.malikania.fr> <1273257226.1671.3.camel@malikania.fr> Date: Wed, 12 May 2010 18:09:02 -0500 Message-ID: From: Brandon Gooch To: Attilio Rao Content-Type: text/plain; charset=ISO-8859-1 Cc: David DEMELIER , Giovanni Trematerra , freebsd-stable@freebsd.org Subject: Re: Kernel panic when unpluggin AC adaptor X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 May 2010 23:09:03 -0000 On Wed, May 12, 2010 at 9:41 AM, Attilio Rao wrote: > 2010/5/12 David DEMELIER : >> I remove the patch, and built the kernel (I updated the src this >> morning) and it does not panic now. It's really odd. If it reappears >> soon I will tell you. > > I looked at the code with Giovanni and I have the feeling that the > race with the idle thread may still be fatal. > We need to fix that. > > Attilio > That seems to be the case, as my laptop shows about an 80-85 % chance of experiencing a panic if left idle for long-ish periods of time (2 to 4 hours). I usually rebuild world or big ports overnight, and more often than not I wake up to a panicked machine, same situation every time: ... rman_get_bushandle() at rman_get_bushandle+0x1 sched_idletd() at sched_idletd+0x123 fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe ... The kernel/userland is rebuilt, the ports are finished compiling -- it's in the time AFTER the completion of all tasks that the machine gets bored and tries to kill itself :) I have seen the AC adapter plug/unplug "hang" in the past on this laptop, but I never made the connection between the events, as nowadays my laptop usually stays plugged in :( Attilio, I hope you can track this one down, let me know if I can do anything to help or test... -Brandon From owner-freebsd-stable@FreeBSD.ORG Thu May 13 00:10:52 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 55FF2106566B for ; Thu, 13 May 2010 00:10:52 +0000 (UTC) (envelope-from andy@xecu.net) Received: from shell.xecu.net (shell.xecu.net [216.127.136.216]) by mx1.freebsd.org (Postfix) with ESMTP id 343D78FC13 for ; Thu, 13 May 2010 00:10:51 +0000 (UTC) Received: from shell.xecu.net (shell.xecu.net [216.127.136.216]) by shell.xecu.net (Postfix) with ESMTP id 3F26C251C0C for ; Wed, 12 May 2010 19:46:25 -0400 (EDT) Date: Wed, 12 May 2010 19:46:25 -0400 (EDT) From: Andy Dills To: freebsd-stable@freebsd.org Message-ID: <20100512193814.L37652@shell.xecu.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Why doesn't this startup script execute on boot? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 May 2010 00:10:52 -0000 I'm working on getting p0f integrated with amavisd-new. Everything is great, with the exception that I can't get the neccessary commands to execute on boot. I started with rc.local and that didn't work. So I made this simple script in /usr/local/etc/rc.d/p0f: --- #!/bin/sh # PROVIDE: p0f # REQUIRE: LOGIN # BEFORE: securelevel # KEYWORD: shutdown . "/etc/rc.subr" name="p0f" rcvar=`set_rcvar` command="/usr/local/bin/p0f" command_args="-l 'tcp dst port 25' 2>&1 | /usr/local/bin/p0f-analyzer.pl 2345 &" pidfile="/var/run/$name.pid" # read configuration and set defaults load_rc_config "$name" : ${p0f_enable="NO"} run_rc_command "$1" --- It does not execute on boot (yes, it's executable). It executes just fine by hand. I'm assuming it has something to do with redirecting stdout and stderr to another script which is then shoved into the background? How do I work around this? (BTW, FreeBSD 8.0-STABLE #2: Wed May 12 13:28:18 EDT 2010) Thanks, Andy --- Andy Dills Xecunet, Inc. www.xecu.net 301-682-9972 --- From owner-freebsd-stable@FreeBSD.ORG Thu May 13 00:57:43 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 47746106566C for ; Thu, 13 May 2010 00:57:43 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from asmtpout026.mac.com (asmtpout026.mac.com [17.148.16.101]) by mx1.freebsd.org (Postfix) with ESMTP id 2E9E78FC0C for ; Thu, 13 May 2010 00:57:42 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from cswiger1.apple.com ([17.209.4.71]) by asmtp026.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0L2C00J8U2O6S180@asmtp026.mac.com> for freebsd-stable@freebsd.org; Wed, 12 May 2010 17:57:42 -0700 (PDT) X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=6.0.2-1004200000 definitions=main-1005120173 X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5,1.2.40,4.0.166 definitions=2010-05-12_04:2010-02-06, 2010-05-13, 2010-05-12 signatures=0 From: Chuck Swiger In-reply-to: <20100512193814.L37652@shell.xecu.net> Date: Wed, 12 May 2010 17:57:42 -0700 Message-id: <3C6E6C70-756E-407B-97C5-B453138D8294@mac.com> References: <20100512193814.L37652@shell.xecu.net> To: Andy Dills X-Mailer: Apple Mail (2.1078) Cc: freebsd-stable@freebsd.org Subject: Re: Why doesn't this startup script execute on boot? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 May 2010 00:57:43 -0000 Hi-- On May 12, 2010, at 4:46 PM, Andy Dills wrote: > I'm working on getting p0f integrated with amavisd-new. Everything is > great, with the exception that I can't get the neccessary commands to > execute on boot. The amavid-p0fanalyzer script should have been installed if you used the port: % cat /usr/local/etc/rc.d/amavis-p0fanalyzer #!/bin/sh # $FreeBSD: ports/security/amavisd-new/files/amavis-p0fanalyzer.sh.in,v 1.6 2007/03/30 21:52:10 gabor Exp $ # PROVIDE: amavis_p0fanalyzer # REQUIRE: DAEMON # BEFORE: amavisd amavis_p0fanalyzer_enable="${amavis_p0fanalyzer_enable-NO}" amavis_p0fanalyzer_p0f_filter="${amavis_p0fanalyzer_p0f_filter-"tcp dst port 25"}" amavis_p0fanalyzer_pidfile1="${amavis_p0fanalyzer_pidfile1-/var/run/p0fanalyzer1.pid}" amavis_p0fanalyzer_pidfile2="${amavis_p0fanalyzer_pidfile2-/var/run/p0fanalyzer2.pid}" amavis_p0f_daemon_flags="${amavis_p0f_daemon_flags--l}" amavis_p0fanalyzer_flags="${amavis_p0fanalyzer_flags-2345}" . /etc/rc.subr name="amavis_p0fanalyzer" rcvar=`set_rcvar` start_cmd=p0fanalyzer_start stop_cmd=p0fanalyzer_stop p0fanalyzer_start() { echo "Starting p0f-analyzer." && \ /usr/sbin/daemon -p ${amavis_p0fanalyzer_pidfile1} \ /usr/local/bin/p0f ${amavis_p0f_daemon_flags} \ "${amavis_p0fanalyzer_p0f_filter}" 2>&1 | \ /usr/sbin/daemon -p ${amavis_p0fanalyzer_pidfile2} \ /usr/local/sbin/p0f-analyzer.pl ${amavis_p0fanalyzer_flags} } p0fanalyzer_stop() { /bin/kill `cat ${amavis_p0fanalyzer_pidfile2}` && rm ${amavis_p0fanalyzer_pidfile2} /bin/kill `cat ${amavis_p0fanalyzer_pidfile1}` && rm ${amavis_p0fanalyzer_pidfile1} } load_rc_config $name run_rc_command "$1" Regards, -- -Chuck From owner-freebsd-stable@FreeBSD.ORG Thu May 13 01:49:52 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5AE6D106564A for ; Thu, 13 May 2010 01:49:52 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.freebsd.org (Postfix) with ESMTP id C82408FC16 for ; Thu, 13 May 2010 01:49:51 +0000 (UTC) Received: from ur.dons.net.au (ppp121-45-158-147.lns6.adl6.internode.on.net [121.45.158.147]) (authenticated bits=0) by cain.gsoft.com.au (8.14.4/8.14.3) with ESMTP id o4D1ngRb067427 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 13 May 2010 11:19:49 +0930 (CST) (envelope-from doconnor@gsoft.com.au) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: "Daniel O'Connor" In-Reply-To: Date: Thu, 13 May 2010 11:19:41 +0930 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Stefan Bethke X-Mailer: Apple Mail (2.1078) X-Spam-Score: 0.163 () BAYES_00,RDNS_DYNAMIC X-Scanned-By: MIMEDefang 2.67 on 203.31.81.10 Cc: FreeBSD Stable Subject: Re: .zfs directory broken on an FS X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 May 2010 01:49:52 -0000 On 13/05/2010, at 6:53, Stefan Bethke wrote: > Am 12.05.2010 um 02:09 schrieb Daniel O'Connor: >> [cain 9:37] ~ >ls -la /usr/local/Genesis/archive/.zfs >> ls: snapshot: Bad file descriptor >> total 0 >>=20 > This appears to be a long standing issue with no solution. I used to = get this a lot during daily rsync backups; since switching to a zfs = send/recv based script I don't get these problems anymore. >=20 > Be aware that trying to unmount that snapshot or it's filesystem might = panic or hang the system, including when you try to reboot. OK thanks for the warning! Odd though as that FS gets very little action. -- 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 - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C From owner-freebsd-stable@FreeBSD.ORG Thu May 13 02:09:17 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2FB3E106566C for ; Thu, 13 May 2010 02:09:17 +0000 (UTC) (envelope-from andy@xecu.net) Received: from shell.xecu.net (shell.xecu.net [216.127.136.216]) by mx1.freebsd.org (Postfix) with ESMTP id 0BF028FC0A for ; Thu, 13 May 2010 02:09:16 +0000 (UTC) Received: from shell.xecu.net (shell.xecu.net [216.127.136.216]) by shell.xecu.net (Postfix) with ESMTP id 50CE6251C0C; Wed, 12 May 2010 22:09:16 -0400 (EDT) Date: Wed, 12 May 2010 22:09:16 -0400 (EDT) From: Andy Dills To: Chuck Swiger In-Reply-To: <3C6E6C70-756E-407B-97C5-B453138D8294@mac.com> Message-ID: <20100512215907.F37652@shell.xecu.net> References: <20100512193814.L37652@shell.xecu.net> <3C6E6C70-756E-407B-97C5-B453138D8294@mac.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-stable@freebsd.org Subject: Re: Why doesn't this startup script execute on boot? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 May 2010 02:09:17 -0000 On Wed, 12 May 2010, Chuck Swiger wrote: > Hi-- > > On May 12, 2010, at 4:46 PM, Andy Dills wrote: > > I'm working on getting p0f integrated with amavisd-new. Everything is > > great, with the exception that I can't get the neccessary commands to > > execute on boot. > > The amavid-p0fanalyzer script should have been installed if you used the port: Well, isn't that convenient! I decided after I had installed amavisd to add on the p0f support, I didn't realize there was an option to install that via port...I had just gone in and installed the p0f port by itself. But looking at the options for the amavisd-new, there it is indeed. Thanks for your help. Andy --- Andy Dills Xecunet, Inc. www.xecu.net 301-682-9972 --- From owner-freebsd-stable@FreeBSD.ORG Thu May 13 07:12:42 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3383B1065673 for ; Thu, 13 May 2010 07:12:42 +0000 (UTC) (envelope-from perryh@pluto.rain.com) Received: from agora.rdrop.com (unknown [IPv6:2607:f678:1010::34]) by mx1.freebsd.org (Postfix) with ESMTP id 10DD78FC18 for ; Thu, 13 May 2010 07:12:42 +0000 (UTC) Received: from agora.rdrop.com (66@localhost [127.0.0.1]) by agora.rdrop.com (8.13.1/8.12.7) with ESMTP id o4D7Bt8u042158 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 13 May 2010 00:11:56 -0700 (PDT) (envelope-from perryh@pluto.rain.com) Received: (from uucp@localhost) by agora.rdrop.com (8.13.1/8.12.9/Submit) with UUCP id o4D7BtXl042157; Thu, 13 May 2010 00:11:55 -0700 (PDT) Received: from fbsd61 by pluto.rain.com (4.1/SMI-4.1-pluto-M2060407) id AA06394; Thu, 13 May 10 00:11:10 PDT Date: Thu, 13 May 2010 00:09:05 -0700 From: perryh@pluto.rain.com To: oberman@es.net Message-Id: <4beba591.QTM0CCHZfkh0AKNv%perryh@pluto.rain.com> References: <20100512135724.7D85F1CC24@ptavv.es.net> In-Reply-To: <20100512135724.7D85F1CC24@ptavv.es.net> User-Agent: nail 11.25 7/29/05 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: Kernel panic when unpluggin AC adaptor X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 May 2010 07:12:42 -0000 "Kevin Oberman" wrote: > ... TCC and throttling ... > they were intended for thermal management, not power management. Shouldn't the two be equivalent? Heat generated is directly related to power consumed. From owner-freebsd-stable@FreeBSD.ORG Thu May 13 09:09:05 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AC78C106566C for ; Thu, 13 May 2010 09:09:05 +0000 (UTC) (envelope-from eugen@grosbein.pp.ru) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [62.231.161.221]) by mx1.freebsd.org (Postfix) with ESMTP id E6C798FC1B for ; Thu, 13 May 2010 09:09:04 +0000 (UTC) Received: from eg.sd.rdtc.ru (localhost [127.0.0.1]) by eg.sd.rdtc.ru (8.14.4/8.14.4) with ESMTP id o4D8ovVH002565; Thu, 13 May 2010 15:50:58 +0700 (NOVST) (envelope-from eugen@grosbein.pp.ru) Message-ID: <4BEBBD71.5020305@grosbein.pp.ru> Date: Thu, 13 May 2010 15:50:57 +0700 From: Eugene Grosbein User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; ru-RU; rv:1.9.1.9) Gecko/20100511 Thunderbird/3.0.4 MIME-Version: 1.0 To: Andy Dills References: <20100512193814.L37652@shell.xecu.net> In-Reply-To: <20100512193814.L37652@shell.xecu.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: Why doesn't this startup script execute on boot? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 May 2010 09:09:05 -0000 On 13.05.2010 06:46, Andy Dills wrote: > > I'm working on getting p0f integrated with amavisd-new. Everything is > great, with the exception that I can't get the neccessary commands to > execute on boot. > > I started with rc.local and that didn't work. So I made this simple script > in /usr/local/etc/rc.d/p0f: > > --- > > #!/bin/sh > > # PROVIDE: p0f > # REQUIRE: LOGIN > # BEFORE: securelevel > # KEYWORD: shutdown > > > . "/etc/rc.subr" > > name="p0f" > rcvar=`set_rcvar` > > command="/usr/local/bin/p0f" > command_args="-l 'tcp dst port 25' 2>&1 | /usr/local/bin/p0f-analyzer.pl 2345 &" > pidfile="/var/run/$name.pid" Perhaps, your "BEFORE: securelevel" may be a culprit, it's too early to run something from /usr/local/bin. Try to remove this line. From owner-freebsd-stable@FreeBSD.ORG Thu May 13 16:39:03 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EC882106566C for ; Thu, 13 May 2010 16:39:03 +0000 (UTC) (envelope-from oberman@es.net) Received: from mailgw.es.net (mail1.es.net [IPv6:2001:400:201:1::2]) by mx1.freebsd.org (Postfix) with ESMTP id 9F0AD8FC1A for ; Thu, 13 May 2010 16:39:03 +0000 (UTC) Received: from ptavv.es.net (ptavv.es.net [IPv6:2001:400:910::29]) by mailgw.es.net (8.14.3/8.14.3) with ESMTP id o4DGd1AQ020821 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 13 May 2010 09:39:02 -0700 Received: from ptavv.es.net (localhost [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id C71E71CC24; Thu, 13 May 2010 09:39:01 -0700 (PDT) To: perryh@pluto.rain.com In-reply-to: Your message of "Thu, 13 May 2010 00:09:05 PDT." <4beba591.QTM0CCHZfkh0AKNv%perryh@pluto.rain.com> Date: Thu, 13 May 2010 09:39:01 -0700 From: "Kevin Oberman" Message-Id: <20100513163901.C71E71CC24@ptavv.es.net> X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5, 1.2.40, 4.0.166 definitions=2010-05-13_02:2010-02-06, 2010-05-13, 2010-05-13 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-0908210000 definitions=main-1005130107 Cc: freebsd-stable@freebsd.org Subject: Re: Kernel panic when unpluggin AC adaptor X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 May 2010 16:39:04 -0000 > Date: Thu, 13 May 2010 00:09:05 -0700 > From: perryh@pluto.rain.com > > "Kevin Oberman" wrote: > > > ... TCC and throttling ... > > they were intended for thermal management, not power management. > > Shouldn't the two be equivalent? Heat generated is directly related > to power consumed. They are roughly equivalent. TCC performs slightly better as it is internal to the CPU and can run automatically with no OS involvement. Throttling requires the OS set the number of cycles to skip on pins of the CPU. My testing has shown only about a 5% difference on the worst case in a P4-Mobile CPU. FreeBSD will use TCC when it is available and throttling when it is not. It never uses both. (It did for a short while and it was not pretty!) Heat generated is almost directly proportional to power consumed. Unfortunately, when you use TCC or throttling the performance is also directly proportional to the power consumed. the result is that, to perform any operation, you end up using almost the same power. Testing has shown that it is really a net loss to do this. For an excellent review of the situation, please read Alexandar Motin's paper on FreeBSD power tuning at: http://wiki.freebsd.org/TuningPowerConsumption He performed the same testing I had performed about two years prior and went well beyond what I had done. More importantly, he wrote up an excellent document which describes how to set up a system for best power/performance and explains why. I think is is a 'must read' for anyone who wants to run a power efficient system. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 From owner-freebsd-stable@FreeBSD.ORG Thu May 13 19:14:36 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4526B106564A for ; Thu, 13 May 2010 19:14:36 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by mx1.freebsd.org (Postfix) with ESMTP id CA4AA8FC1F for ; Thu, 13 May 2010 19:14:35 +0000 (UTC) Received: (qmail 5336 invoked by uid 399); 13 May 2010 19:14:34 -0000 Received: from localhost (HELO foreign.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 13 May 2010 19:14:34 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4BEC4F99.9050502@FreeBSD.org> Date: Thu, 13 May 2010 12:14:33 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.9) Gecko/20100330 Thunderbird/3.0.4 MIME-Version: 1.0 To: Eugene Grosbein References: <20100512193814.L37652@shell.xecu.net> <4BEBBD71.5020305@grosbein.pp.ru> In-Reply-To: <4BEBBD71.5020305@grosbein.pp.ru> X-Enigmail-Version: 1.0.1 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Andy Dills , freebsd-stable@freebsd.org Subject: Re: Why doesn't this startup script execute on boot? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 May 2010 19:14:36 -0000 On 05/13/10 01:50, Eugene Grosbein wrote: > > Perhaps, your "BEFORE: securelevel" may be a culprit, it's too early > to run something from /usr/local/bin. securelevel is one of the last things to run, and must run after all the file systems are mounted. Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ From owner-freebsd-stable@FreeBSD.ORG Thu May 13 23:09:34 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A48FC106564A for ; Thu, 13 May 2010 23:09:34 +0000 (UTC) (envelope-from ambrisko@ambrisko.com) Received: from mail.ambrisko.com (mail.ambrisko.com [64.174.51.43]) by mx1.freebsd.org (Postfix) with ESMTP id 7FA2E8FC1C for ; Thu, 13 May 2010 23:09:34 +0000 (UTC) X-Ambrisko-Me: Yes Received: from server2.ambrisko.com (HELO www.ambrisko.com) ([192.168.1.2]) by ironport.ambrisko.com with ESMTP; 13 May 2010 16:09:40 -0700 Received: from ambrisko.com (localhost [127.0.0.1]) by www.ambrisko.com (8.14.3/8.14.3) with ESMTP id o4DNDDPh078237; Thu, 13 May 2010 16:13:13 -0700 (PDT) (envelope-from ambrisko@ambrisko.com) Received: (from ambrisko@localhost) by ambrisko.com (8.14.3/8.14.3/Submit) id o4DNDBrp078232; Thu, 13 May 2010 16:13:11 -0700 (PDT) (envelope-from ambrisko) From: Doug Ambrisko Message-Id: <201005132313.o4DNDBrp078232@ambrisko.com> In-Reply-To: <4BE561C7.70702@mail.ru> To: rihad Date: Thu, 13 May 2010 16:13:11 -0700 (PDT) X-Mailer: ELM [version 2.4ME+ PL94b (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Cc: freebsd-stable@FreeBSD.org Subject: Re: Enabling watchdog X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 May 2010 23:09:34 -0000 rihad writes: | Hi, I'm thinking of enabling the watchdog on our Dell PowerEdge 2950 / | FreeBSD 8.0 amd64, so that it reboots the machine in case of lockups. | Right now it doesn't work: | | # watchdog | watchdog: patting the dog: Operation not supported | # | Looking through the kernel configuration I found two relevant settings: | In /sys/conf/NOTES: | # | # Add software watchdog routines. | # | options SW_WATCHDOG | | and in /sys/amd64/conf/NOTES: | # | # Watchdog routines. | # | options MP_WATCHDOG | | Which of them should I rebuild the kernel with? BTW, the existing kernel | is built with the default "options SCHED_ULE" to make good use of | multiple CPUs, does watchdog work with it? If no one has said yet, kldload ipmi then run watchdogd. ... or compile it into the kernel. This will enable the IPMI HW watchdog. If it triggers, it will appear in the IPMI SEL (ipmitool sel list). Doug A. From owner-freebsd-stable@FreeBSD.ORG Fri May 14 00:25:56 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 10BFD1065670; Fri, 14 May 2010 00:25:56 +0000 (UTC) (envelope-from giovanni.trematerra@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 2A2528FC0A; Fri, 14 May 2010 00:25:54 +0000 (UTC) Received: by fxm17 with SMTP id 17so1026334fxm.13 for ; Thu, 13 May 2010 17:25:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=elRavDTTTKXlR69opOuGaAcxNvtrMN+0xbdgMZ1m8iw=; b=GGweRQ8PnTwKLHmUKSQu1aZd0QDiWVrTEt6z5xlX8ZL+XhXxeOPWoPgd2VXobQeb4y 5Y87sQuLza26XwgP4aCjESN8pga7bFaiYj91EfGn2QjG1DNjZBvbI9H/fkAytIhg0JnX rkKaXbPgcdpJ6II6p5LucHktE/tIJUDoMNqeg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=jS1V38tJZki6+77nQKYJ3ZPMxGMNSDCdQzplY8ALCqpeDU5TKyINdzF7Ecw1C7K9DW 1nNZ96kMZ70TeMJi8wvMqKtAKcmZMRGsu3I/lHtVspnPkrd5mM+pKhESMy6PHWGcf7Zn 95ww6hsDqxGqSDaCIC+jqcFq1tdnj+7Do8GpI= MIME-Version: 1.0 Received: by 10.223.44.86 with SMTP id z22mr707658fae.13.1273796754033; Thu, 13 May 2010 17:25:54 -0700 (PDT) Received: by 10.223.103.209 with HTTP; Thu, 13 May 2010 17:25:53 -0700 (PDT) In-Reply-To: References: <4DEBDE2C-C0D2-469D-AC42-DD5027926424@FreeBSD.org> <20100507120843.GA1738@Melon.malikania.fr> <1273257226.1671.3.camel@malikania.fr> Date: Fri, 14 May 2010 02:25:53 +0200 Message-ID: From: Giovanni Trematerra To: Brandon Gooch Content-Type: multipart/mixed; boundary=0015174410d60a4c7e048682ebd4 Cc: Attilio Rao , David DEMELIER , freebsd-acpi@freebsd.org, freebsd-stable@freebsd.org Subject: Re: Kernel panic when unpluggin AC adaptor X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 May 2010 00:25:56 -0000 --0015174410d60a4c7e048682ebd4 Content-Type: text/plain; charset=ISO-8859-1 On Thu, May 13, 2010 at 1:09 AM, Brandon Gooch wrote: > On Wed, May 12, 2010 at 9:41 AM, Attilio Rao wrote: >> 2010/5/12 David DEMELIER : >>> I remove the patch, and built the kernel (I updated the src this >>> morning) and it does not panic now. It's really odd. If it reappears >>> soon I will tell you. >> >> I looked at the code with Giovanni and I have the feeling that the >> race with the idle thread may still be fatal. >> We need to fix that. >> >> Attilio >> > > That seems to be the case, as my laptop shows about an 80-85 % chance > of experiencing a panic if left idle for long-ish periods of time (2 > to 4 hours). I usually rebuild world or big ports overnight, and more > often than not I wake up to a panicked machine, same situation every > time: > > ... > rman_get_bushandle() at rman_get_bushandle+0x1 > sched_idletd() at sched_idletd+0x123 > fork_exit() at fork_exit+0x12a > fork_trampoline() at fork_trampoline+0xe > ... > > The kernel/userland is rebuilt, the ports are finished compiling -- > it's in the time AFTER the completion of all tasks that the machine > gets bored and tries to kill itself :) > > I have seen the AC adapter plug/unplug "hang" in the past on this > laptop, but I never made the connection between the events, as > nowadays my laptop usually stays plugged in :( > > Attilio, I hope you can track this one down, let me know if I can do > anything to help or test... > Attilio and I came up with this patch. It seems ready for stress testing and review Please test and report back. Thank you P.S: all the faults are only mine. -- Gianni --0015174410d60a4c7e048682ebd4 Content-Type: text/plain; charset=US-ASCII; name="acpi_idle4.diff.txt" Content-Disposition: attachment; filename="acpi_idle4.diff.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_g969lyt20 ZGlmZiAtciBkN2QwZTA0ZjQyZTMgc3lzL2Rldi9hY3BpY2EvYWNwaV9jcHUuYwotLS0gYS9zeXMv ZGV2L2FjcGljYS9hY3BpX2NwdS5jCVdlZCBNYXkgMTIgMDQ6MDE6NTYgMjAxMCArMDIwMAorKysg Yi9zeXMvZGV2L2FjcGljYS9hY3BpX2NwdS5jCUZyaSBNYXkgMTQgMDI6MjA6MTggMjAxMCArMDIw MApAQCAtODgsNiArODgsNyBAQCBzdHJ1Y3QgYWNwaV9jcHVfc29mdGMgewogICAgIGludAkJCSBj cHVfY3hfbG93ZXN0OwogICAgIGNoYXIgCQkgY3B1X2N4X3N1cHBvcnRlZFs2NF07CiAgICAgaW50 CQkJIGNwdV9yaWQ7CisJc3RydWN0IG10eAkgY3B1X2xvY2s7CiB9OwogCiBzdHJ1Y3QgYWNwaV9j cHVfZGV2aWNlIHsKQEAgLTEwMCw2ICsxMDEsMTAgQEAgc3RydWN0IGFjcGlfY3B1X2RldmljZSB7 CiAjZGVmaW5lIENQVV9TRVRfUkVHKHJlZywgd2lkdGgsIHZhbCkJCQkJCVwKICAgICAoYnVzX3Nw YWNlX3dyaXRlXyAjIyB3aWR0aChybWFuX2dldF9idXN0YWcoKHJlZykpLCAJCQlcCiAJCSAgICAg ICBybWFuX2dldF9idXNoYW5kbGUoKHJlZykpLCAwLCAodmFsKSkpCisjZGVmaW5lIEFDUElfQ1BV X0xPQ0soc2MpIFwKKwltdHhfbG9ja19zcGluKCZzYy0+Y3B1X2xvY2spCisjZGVmaW5lIEFDUElf Q1BVX1VOTE9DSyhzYykgXAorCW10eF91bmxvY2tfc3Bpbigmc2MtPmNwdV9sb2NrKQogCiAjZGVm aW5lIFBNX1VTRUMoeCkJICgoeCkgPj4gMikJLyogfjQgY2xvY2tzIHBlciB1c2VjICgzLjU3OTU1 IE1oeikgKi8KIApAQCAtMjg0LDYgKzI4OSw3IEBAIGFjcGlfY3B1X2F0dGFjaChkZXZpY2VfdCBk ZXYpCiAgICAgQUNQSV9GVU5DVElPTl9UUkFDRSgoY2hhciAqKSh1aW50cHRyX3QpX19mdW5jX18p OwogCiAgICAgc2MgPSBkZXZpY2VfZ2V0X3NvZnRjKGRldik7CisJbXR4X2luaXQoJnNjLT5jcHVf bG9jaywgIm50ZmxjayIsIE5VTEwsIE1UWF9TUElOKTsKICAgICBzYy0+Y3B1X2RldiA9IGRldjsK ICAgICBzYy0+Y3B1X2hhbmRsZSA9IGFjcGlfZ2V0X2hhbmRsZShkZXYpOwogICAgIGNwdV9pZCA9 IChpbnQpKGludHB0cl90KWFjcGlfZ2V0X3ByaXZhdGUoZGV2KTsKQEAgLTQwOSwyNiArNDE1LDI2 IEBAIGFjcGlfY3B1X3Bvc3RhdHRhY2godm9pZCAqdW51c2VkIF9fdW51c2UKIFNZU0lOSVQoYWNw aV9jcHUsIFNJX1NVQl9DT05GSUdVUkUsIFNJX09SREVSX01JRERMRSwKICAgICBhY3BpX2NwdV9w b3N0YXR0YWNoLCBOVUxMKTsKIAotLyoKLSAqIERpc2FibGUgYW55IGVudHJ5IHRvIHRoZSBpZGxl IGZ1bmN0aW9uIGR1cmluZyBzdXNwZW5kIGFuZCByZS1lbmFibGUgaXQKLSAqIGR1cmluZyByZXN1 bWUuCi0gKi8KIHN0YXRpYyBpbnQKIGFjcGlfY3B1X3N1c3BlbmQoZGV2aWNlX3QgZGV2KQogewor ICAgIHN0cnVjdCBhY3BpX2NwdV9zb2Z0YyAqc2M7CiAgICAgaW50IGVycm9yOwogCisgICAgc2Mg PSBkZXZpY2VfZ2V0X3NvZnRjKGRldik7CiAgICAgZXJyb3IgPSBidXNfZ2VuZXJpY19zdXNwZW5k KGRldik7CiAgICAgaWYgKGVycm9yKQogCXJldHVybiAoZXJyb3IpOworCUFDUElfQ1BVX0xPQ0so c2MpOwogICAgIGNwdV9kaXNhYmxlX2lkbGUgPSBUUlVFOworCUFDUElfQ1BVX1VOTE9DSyhzYyk7 CisKICAgICByZXR1cm4gKDApOwogfQogCiBzdGF0aWMgaW50CiBhY3BpX2NwdV9yZXN1bWUoZGV2 aWNlX3QgZGV2KQogewotCiAgICAgY3B1X2Rpc2FibGVfaWRsZSA9IEZBTFNFOwogICAgIHJldHVy biAoYnVzX2dlbmVyaWNfcmVzdW1lKGRldikpOwogfQpAQCAtNjA5LDcgKzYxNSw5IEBAIGFjcGlf Y3B1X2dlbmVyaWNfY3hfcHJvYmUoc3RydWN0IGFjcGlfY3AKIAkgICAgY3hfcHRyLT50cmFuc19s YXQgPSBBY3BpR2JsX0ZBRFQuQzJMYXRlbmN5OwogCSAgICBjeF9wdHIrKzsKIAkgICAgc2MtPmNw dV9jeF9jb3VudCsrOwotCX0KKwl9IGVsc2UKKwkJcGFuaWMoIiVzOiBDYW5ub3QgYWxsb2NhdGUg cmVzb3VyY2UgJWQgZm9yIEMzIHN0YXRlIiwgX19mdW5jX18sIAorCQkgICAgY3hfcHRyLT5yZXNf dHlwZSk7CiAgICAgfQogICAgIGlmIChzYy0+Y3B1X3BfYmxrX2xlbiA8IDYpCiAJcmV0dXJuOwpA QCAtNjI1LDcgKzYzMyw5IEBAIGFjcGlfY3B1X2dlbmVyaWNfY3hfcHJvYmUoc3RydWN0IGFjcGlf Y3AKIAkgICAgY3hfcHRyLT50cmFuc19sYXQgPSBBY3BpR2JsX0ZBRFQuQzNMYXRlbmN5OwogCSAg ICBjeF9wdHIrKzsKIAkgICAgc2MtPmNwdV9jeF9jb3VudCsrOwotCX0KKwl9IGVsc2UKKwkJcGFu aWMoIiVzOiBDYW5ub3QgYWxsb2NhdGUgcmVzb3VyY2UgJWQgZm9yIEMzIHN0YXRlIiwgX19mdW5j X18sIAorCQkgICAgY3hfcHRyLT5yZXNfdHlwZSk7CiAgICAgfQogfQogCkBAIC03MjEsNiArNzMx LDggQEAgYWNwaV9jcHVfY3hfY3N0KHN0cnVjdCBhY3BpX2NwdV9zb2Z0YyAqcwogCX0KICNlbmRp ZgogCisJQUNQSV9DUFVfTE9DSyhzYyk7CisKIAkvKiBBbGxvY2F0ZSB0aGUgY29udHJvbCByZWdp c3RlciBmb3IgQzIgb3IgQzMuICovCiAJYWNwaV9Qa2dHYXMoc2MtPmNwdV9kZXYsIHBrZywgMCwg JmN4X3B0ci0+cmVzX3R5cGUsICZzYy0+Y3B1X3JpZCwKIAkgICAgJmN4X3B0ci0+cF9sdmx4LCBS Rl9TSEFSRUFCTEUpOwpAQCAtNzMyLDcgKzc0NCwxNyBAQCBhY3BpX2NwdV9jeF9jc3Qoc3RydWN0 IGFjcGlfY3B1X3NvZnRjICpzCiAJCQkgICAgIGN4X3B0ci0+dHJhbnNfbGF0KSk7CiAJICAgIGN4 X3B0cisrOwogCSAgICBzYy0+Y3B1X2N4X2NvdW50Kys7CisJCWNwdV9kaXNhYmxlX2lkbGUgPSBG QUxTRTsKKwl9IGVsc2UgeworCQlkZXZpY2VfcHJpbnRmKHNjLT5jcHVfZGV2LCAiY2Fubm90IGFs bG9jYXRlIGNvbnRyb2wgcmVnaXN0ZXIiCisJCSAgICAiIGZvciBDMiBvIEMzLiIpOworCisJCS8q CisJCSAqIGRpc2FibGUgYWNwaV9jcHVfaWRsZSBvdGhlcndpc2Ugd2UgZ2V0IGEgcGFuaWMKKwkJ ICovCisJCWNwdV9kaXNhYmxlX2lkbGUgPSBUUlVFOwogCX0KKwlBQ1BJX0NQVV9VTkxPQ0soc2Mp OwogICAgIH0KICAgICBBY3BpT3NGcmVlKGJ1Zi5Qb2ludGVyKTsKIApAQCAtOTAwLDYgKzkyMywx NSBAQCBhY3BpX2NwdV9pZGxlKCkKIAlyZXR1cm47CiAgICAgfQogCisJQUNQSV9DUFVfTE9DSyhz Yyk7CisKKyAgICAvKiBpbiB0aGUgbWVhbnRpbWUgYWNwaV9jcHVfbm90aWZ5IGNvdWxkIGJlIGRp c2FibGVkIHRoZSBob29rICovCisgICAgaWYgKGNwdV9kaXNhYmxlX2lkbGUpIHsKKwlBQ1BJX0NQ VV9VTkxPQ0soc2MpOworCUFDUElfRU5BQkxFX0lSUVMoKTsKKwlyZXR1cm47CisgICAgfQorCQog ICAgIC8qIEZpbmQgdGhlIGxvd2VzdCBzdGF0ZSB0aGF0IGhhcyBzbWFsbCBlbm91Z2ggbGF0ZW5j eS4gKi8KICAgICBjeF9uZXh0X2lkeCA9IDA7CiAgICAgZm9yIChpID0gc2MtPmNwdV9jeF9sb3dl c3Q7IGkgPj0gMDsgaS0tKSB7CkBAIC05MzUsNiArOTY3LDcgQEAgYWNwaV9jcHVfaWRsZSgpCiAg ICAgICovCiAgICAgaWYgKGN4X25leHQtPnR5cGUgPT0gQUNQSV9TVEFURV9DMSkgewogCXNjLT5j cHVfcHJldl9zbGVlcCA9IChzYy0+Y3B1X3ByZXZfc2xlZXAgKiAzICsgNTAwMDAwIC8gaHopIC8g NDsKKwlBQ1BJX0NQVV9VTkxPQ0soc2MpOwogCWFjcGlfY3B1X2MxKCk7CiAJcmV0dXJuOwogICAg IH0KQEAgLTk3NSw2ICsxMDA4LDcgQEAgYWNwaV9jcHVfaWRsZSgpCiAJQWNwaVdyaXRlQml0UmVn aXN0ZXIoQUNQSV9CSVRSRUdfQVJCX0RJU0FCTEUsIDApOwogCUFjcGlXcml0ZUJpdFJlZ2lzdGVy KEFDUElfQklUUkVHX0JVU19NQVNURVJfUkxELCAwKTsKICAgICB9CisJQUNQSV9DUFVfVU5MT0NL KHNjKTsKICAgICBBQ1BJX0VOQUJMRV9JUlFTKCk7CiAKICAgICAvKiBGaW5kIHRoZSBhY3R1YWwg dGltZSBhc2xlZXAgaW4gbWljcm9zZWNvbmRzLiAqLwo= --0015174410d60a4c7e048682ebd4-- From owner-freebsd-stable@FreeBSD.ORG Fri May 14 00:54:15 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D2A7F106566B for ; Fri, 14 May 2010 00:54:15 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.158]) by mx1.freebsd.org (Postfix) with ESMTP id 311118FC13 for ; Fri, 14 May 2010 00:54:14 +0000 (UTC) Received: by fg-out-1718.google.com with SMTP id 22so21709fge.13 for ; Thu, 13 May 2010 17:54:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=IZier/nLVzWlChzrlXu1CH1m3zljmHpgd7KtU2rP0Ag=; b=MHSGCbixZFu8wvs/o++9ukhmirDbMkLP46au6okJve+SLrjPmfoqfT/JCJ43OBvdBh eSaAq2xb461IsPy0KSZDo50NyB6jb6KlnLyh/16DH6I4HBBCQbU2b3BtuMD1wcl9IWgo o3zOml9ln32lK3cOz/xhznSkLK6ToeBcTMBdM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=tbenMWUhxmfHbBG1p7hutkqeq4aPEBYUd4fys2n1DhGIcjM9UdDqfdVTFjQp9yivDw GPJ/2itbiZTqNFuiEjz6W3NFccqGpIBAZjiuHmsB+ZmEJyHAp1bzlfxv2Ivv5aSsrbvX Jztl4JwM9aBu/BI000dsA1obWwgCdBHGRHMPg= MIME-Version: 1.0 Received: by 10.239.193.3 with SMTP id g3mr62764hbi.122.1273798453869; Thu, 13 May 2010 17:54:13 -0700 (PDT) Sender: asmrookie@gmail.com Received: by 10.239.129.207 with HTTP; Thu, 13 May 2010 17:54:13 -0700 (PDT) In-Reply-To: References: <4DEBDE2C-C0D2-469D-AC42-DD5027926424@FreeBSD.org> <1273257226.1671.3.camel@malikania.fr> Date: Fri, 14 May 2010 02:54:13 +0200 X-Google-Sender-Auth: _7Gcp8glvFU6PNK8m-oa2Msp8HE Message-ID: From: Attilio Rao To: Giovanni Trematerra Content-Type: text/plain; charset=UTF-8 Cc: Brandon Gooch , David DEMELIER , freebsd-acpi@freebsd.org, freebsd-stable@freebsd.org Subject: Re: Kernel panic when unpluggin AC adaptor X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 May 2010 00:54:16 -0000 2010/5/14 Giovanni Trematerra : > On Thu, May 13, 2010 at 1:09 AM, Brandon Gooch > wrote: >> On Wed, May 12, 2010 at 9:41 AM, Attilio Rao wrote: >>> 2010/5/12 David DEMELIER : >>>> I remove the patch, and built the kernel (I updated the src this >>>> morning) and it does not panic now. It's really odd. If it reappears >>>> soon I will tell you. >>> >>> I looked at the code with Giovanni and I have the feeling that the >>> race with the idle thread may still be fatal. >>> We need to fix that. >>> >>> Attilio >>> >> >> That seems to be the case, as my laptop shows about an 80-85 % chance >> of experiencing a panic if left idle for long-ish periods of time (2 >> to 4 hours). I usually rebuild world or big ports overnight, and more >> often than not I wake up to a panicked machine, same situation every >> time: >> >> ... >> rman_get_bushandle() at rman_get_bushandle+0x1 >> sched_idletd() at sched_idletd+0x123 >> fork_exit() at fork_exit+0x12a >> fork_trampoline() at fork_trampoline+0xe >> ... >> >> The kernel/userland is rebuilt, the ports are finished compiling -- >> it's in the time AFTER the completion of all tasks that the machine >> gets bored and tries to kill itself :) >> >> I have seen the AC adapter plug/unplug "hang" in the past on this >> laptop, but I never made the connection between the events, as >> nowadays my laptop usually stays plugged in :( >> >> Attilio, I hope you can track this one down, let me know if I can do >> anything to help or test... >> > > Attilio and I came up with this patch. It seems ready for stress > testing and review > Please test and report back. I have still to review it completely, hope to do that asap. Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-stable@FreeBSD.ORG Fri May 14 02:29:26 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B8FAD1065670 for ; Fri, 14 May 2010 02:29:26 +0000 (UTC) (envelope-from fred@storming.org) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 3B1918FC19 for ; Fri, 14 May 2010 02:29:25 +0000 (UTC) Received: by fxm17 with SMTP id 17so1095977fxm.13 for ; Thu, 13 May 2010 19:29:25 -0700 (PDT) Received: by 10.239.155.73 with SMTP id h9mr73092hbc.31.1273802458162; Thu, 13 May 2010 19:00:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.239.148.78 with HTTP; Thu, 13 May 2010 19:00:38 -0700 (PDT) From: Fred Souza Date: Thu, 13 May 2010 23:00:38 -0300 Message-ID: To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Mount root error / New device numbering? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 May 2010 02:29:26 -0000 Hello, I recently reinstalled FreeBSD 8.0 on my computer, after a long hiatus (last version before that was 7-CURRENT before 7.0-RELEASE, on an old computer). I read a lot of documentation to try and make sure I caught up with any important changes before messing too much with the system. I did a similar procedure as I used to on the old system, grabbed a fresh ports.tar.gz, uncompressed it under /usr, installed cvsup and proceeded to updating /usr/src to -STABLE (using the RELENG_8 tag).=A0So far, so good. I made a custom kernel config file based off of GENERIC, added only a few options (like sound and console customization options), and followed the steps listed on /usr/src/UPDATING: # cd /usr/src # make buildworld # make kernel KERNCONF=3DMYKERNELNAME .. Or so I wish. During boot, I got a MOUNT ROOT ERROR (nothing after that). By pressing '?' I could see that it was recognizing my hard drives and slices all differently than the -RELEASE (GENERIC) kernel did. The old one saw my first disk as ad8 (2 NTFS partitions, ad8s1 and ad8s2), then the second disk as ad14 (with a NTFS partition as ad14s1 and then the FreeBSD slices as ad14s[a-f]). The -STABLE kernel sees them as ad10 and ad16 respectively. I then tried to finish the boot process by entering "ufs:/dev/ad16s2a" at the prompt, but it threw me at a single mode shell. I do believe it had shown some error there, but it got pushed off screen by the stream of "interrupt storm (irq21)" messages that have plagued me on this computer (that usually magically stops if I mount a cdrom, but in this case that didn't do it). Trying to fix the issue, I manually mount /usr (now being seen as ad16s2f instead of ad14s2f) and proceed to replacing /etc/fstab's entries with their "new" device numbers. A couple of commands later, the file looks correctly updated with this new scheme. I do an exit on that shell just to get to a kernel panic message and a quick reboot. I tried to unload the -STABLE kernel and boot from the -RELEASE one, but now the system hangs right after it tries to find my disks. I give up and reinstall (that first install had given me quite a headache with incorrect drive geometry [that I had to fix with a lot of research to get to TestDisk and GAG], so I thought it was best to just start fresh). I do the same procedure this time, but paying extra attention to any details I could have overlooked before. One of them was to make a kernel (-STABLE) out of a renamed copy of GENERIC (no options added or removed). I also decided on doing the remaining steps listed on /usr/src/UPDATING before rebooting; I thought the drive numbering difference could be related to something in userland that was missing when booting the -STABLE kernel with -RELEASE userland. And I got the same mount root error message, and again it shows the drives as ad10 and ad16 instead of ad8 and ad14. The difference is that this time I did not try to update /etc/fstab before resorting to this list (I had been browsing it for the past 3 days trying to find any hints on this, as well as reading /usr/src/UPDATING in full again). I can get the system to boot normally if I unload the -STABLE kernel and load the -RELEASE one. But I can't figure out for the life of me why does -STABLE shift my drive numbers around. I also understand how I'm supposed to provide logs and more information, but I'm unsure what to give for this. Just tell me what kind of info/log you need and I'll try to get them. Could anyone please enlighten me? Thank you very much in advance, Fred From owner-freebsd-stable@FreeBSD.ORG Fri May 14 02:51:26 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9F365106564A for ; Fri, 14 May 2010 02:51:26 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta10.emeryville.ca.mail.comcast.net (qmta10.emeryville.ca.mail.comcast.net [76.96.30.17]) by mx1.freebsd.org (Postfix) with ESMTP id 868228FC13 for ; Fri, 14 May 2010 02:51:26 +0000 (UTC) Received: from omta17.emeryville.ca.mail.comcast.net ([76.96.30.73]) by qmta10.emeryville.ca.mail.comcast.net with comcast id HCx51e0051afHeLAAErTmh; Fri, 14 May 2010 02:51:27 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta17.emeryville.ca.mail.comcast.net with comcast id HErS1e00a3S48mS8dErSFr; Fri, 14 May 2010 02:51:27 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 8AE229B419; Thu, 13 May 2010 19:51:25 -0700 (PDT) Date: Thu, 13 May 2010 19:51:25 -0700 From: Jeremy Chadwick To: Fred Souza Message-ID: <20100514025125.GA84336@icarus.home.lan> References: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-stable@freebsd.org Subject: Re: Mount root error / New device numbering? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 May 2010 02:51:26 -0000 On Thu, May 13, 2010 at 11:00:38PM -0300, Fred Souza wrote: > I did a similar procedure as I used to on the old system, grabbed a > fresh ports.tar.gz, uncompressed it under /usr, installed cvsup and > proceeded to updating /usr/src to -STABLE (using the RELENG_8 tag). So > far, so good. 1) We use csup now, not cvsup. csup comes with the base system, so there's no need to install cvsup. 2) I'm not sure why you're downloading ports.tar.gz and extracting it. This means that /var/db/sup/ports-all won't match what's in /usr/ports. You should just use csup to populate /usr/ports. You can do this by doing: csup -h -L 2 /usr/share/examples/cvsup/ports-supfile You can also populate /usr/src (and thus /var/db/sup/src-all) by doing: csup -h -L 2 /usr/share/example/cvsup/stable-supfile There are also /etc/make.conf variables you can set to make this process easier once you've populated /usr/ports and /usr/src; you can do something like "cd /usr/ports ; make update". > I made a custom kernel config file based off of GENERIC, added only a > few options (like sound and console customization options), and > followed the steps listed on /usr/src/UPDATING: > > # cd /usr/src > # make buildworld > # make kernel KERNCONF=MYKERNELNAME > > > ... > > Could anyone please enlighten me? Well, if what you're doing is an "in-place" 7.x upgrade to 8.x, I don't know how to do this or if it works. Others can help. Otherwise, the steps you're describing for building a system are not what's in src/Makefile (not src/UPDATING). These are the steps: # 1. `cd /usr/src' (or to the directory containing your source tree). # 2. `make buildworld' # 3. `make buildkernel KERNCONF=YOUR_KERNEL_HERE' (default is GENERIC). # 4. `make installkernel KERNCONF=YOUR_KERNEL_HERE' (default is GENERIC). # [steps 3. & 4. can be combined by using the "kernel" target] # 5. `reboot' (in single user mode: boot -s from the loader prompt). # 6. `mergemaster -p' # 7. `make installworld' # 8. `make delete-old' # 9. `mergemaster' (you may wish to use -U or -ai). # 10. `reboot' # 11. `make delete-old-libs' (in case no 3rd party program uses them anymore) -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Fri May 14 03:06:34 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1523C106566B for ; Fri, 14 May 2010 03:06:34 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from QMTA11.westchester.pa.mail.comcast.net (qmta11.westchester.pa.mail.comcast.net [76.96.59.211]) by mx1.freebsd.org (Postfix) with ESMTP id B7A0D8FC0A for ; Fri, 14 May 2010 03:06:33 +0000 (UTC) Received: from omta23.westchester.pa.mail.comcast.net ([76.96.62.74]) by QMTA11.westchester.pa.mail.comcast.net with comcast id HEz01e0041c6gX85BF6Zla; Fri, 14 May 2010 03:06:33 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta23.westchester.pa.mail.comcast.net with comcast id HF6X1e00M3S48mS3jF6YXB; Fri, 14 May 2010 03:06:33 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id A74319B419; Thu, 13 May 2010 20:06:30 -0700 (PDT) Date: Thu, 13 May 2010 20:06:30 -0700 From: Jeremy Chadwick To: Fred Souza Message-ID: <20100514030630.GA84755@icarus.home.lan> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-stable@freebsd.org Subject: Re: Mount root error / New device numbering? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 May 2010 03:06:34 -0000 On Thu, May 13, 2010 at 11:00:38PM -0300, Fred Souza wrote: > I give up and reinstall (that first install had given me quite a > headache with incorrect drive geometry [that I had to fix with a lot > of research to get to TestDisk and GAG], so I thought it was best to > just start fresh). I do the same procedure this time, but paying extra > attention to any details I could have overlooked before. One of them > was to make a kernel (-STABLE) out of a renamed copy of GENERIC (no > options added or removed). I also decided on doing the remaining steps > listed on /usr/src/UPDATING before rebooting; I thought the drive > numbering difference could be related to something in userland that > was missing when booting the -STABLE kernel with -RELEASE userland. > ... > And I got the same mount root error message, and again it shows the > drives as ad10 and ad16 instead of ad8 and ad14. The difference is > that this time I did not try to update /etc/fstab before resorting to > this list (I had been browsing it for the past 3 days trying to find > any hints on this, as well as reading /usr/src/UPDATING in full > again). I can get the system to boot normally if I unload the -STABLE > kernel and load the -RELEASE one. But I can't figure out for the life > of me why does -STABLE shift my drive numbers around. There is probably an ata(4) device layer change which either fixes (yes really), breaks (possibly), or enhances (likely) support for your ATA or SATA controller. This is pretty much how the ata(4) layer has behaved for years upon years -- that's just how it goes. If this is your first time encountering it, congratulations. :-) The device names *should not* change on you once you stick with that kernel; it just indicates something changed between -RELEASE and -STABLE. I'd recommend booting/trying an actual 8.0-STABLE snapshot image from here: ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/201004/ This will allow you to boot and install 8.0-STABLE on your system. You should see devices ad10 and ad16 there as well. It would at least save you the pain of installing the kernel, rebooting, and finding you have to manually deal with /etc/fstab changes and so on. Give this a shot first. It also might help in debugging the "stray IRQ" problem you see (it would be useful to know what's sitting on IRQ 21; it may be an unused device in your BIOS which you can disable there, or try to find a FreeBSD driver for the device which can attach to the IRQ). -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Fri May 14 03:12:11 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BF30C106566B for ; Fri, 14 May 2010 03:12:11 +0000 (UTC) (envelope-from fred@storming.org) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 5EFE88FC18 for ; Fri, 14 May 2010 03:12:10 +0000 (UTC) Received: by fxm17 with SMTP id 17so1118373fxm.13 for ; Thu, 13 May 2010 20:12:10 -0700 (PDT) Received: by 10.239.129.197 with SMTP id 5mr77623hbg.77.1273806730143; Thu, 13 May 2010 20:12:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.239.148.78 with HTTP; Thu, 13 May 2010 20:11:50 -0700 (PDT) In-Reply-To: <20100514025125.GA84336@icarus.home.lan> References: <20100514025125.GA84336@icarus.home.lan> From: Fred Souza Date: Fri, 14 May 2010 00:11:50 -0300 Message-ID: To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: Mount root error / New device numbering? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 May 2010 03:12:11 -0000 On Thu, May 13, 2010 at 23:51, Jeremy Chadwick w= rote: > 1) We use csup now, not cvsup. =A0csup comes with the base system, so > =A0 there's no need to install cvsup. > > 2) I'm not sure why you're downloading ports.tar.gz and extracting it. > =A0 This means that /var/db/sup/ports-all won't match what's in > =A0 /usr/ports. =A0You should just use csup to populate /usr/ports. > =A0 You can do this by doing: > > =A0 csup -h -L 2 /usr/share/examples/cvsup/ports-supfile > > =A0 You can also populate /usr/src (and thus /var/db/sup/src-all) by > =A0 doing: > > =A0 csup -h -L 2 /usr/share/example/cvsup/stable-supfile > > =A0 There are also /etc/make.conf variables you can set to make this > =A0 process easier once you've populated /usr/ports and /usr/src; you > =A0 can do something like "cd /usr/ports ; make update". Thank you, that is something I didn't see changing. I will try that out from now on. > Well, if what you're doing is an "in-place" 7.x upgrade to 8.x, I don't > know how to do this or if it works. =A0Others can help. No, I did a fresh 8.0-RELEASE install and then tried updating it to -STABL= E. > Otherwise, the steps you're describing for building a system are not > what's in src/Makefile (not src/UPDATING). =A0These are the steps: > > # =A01. =A0`cd /usr/src' =A0 =A0 =A0 (or to the directory containing your= source tree). > # =A02. =A0`make buildworld' > # =A03. =A0`make buildkernel KERNCONF=3DYOUR_KERNEL_HERE' =A0 =A0 (defaul= t is GENERIC). > # =A04. =A0`make installkernel KERNCONF=3DYOUR_KERNEL_HERE' =A0 (default = is GENERIC). > # =A0 =A0 =A0 [steps 3. & 4. can be combined by using the "kernel" target= ] > # =A05. =A0`reboot' =A0 =A0 =A0 =A0(in single user mode: boot -s from the= loader prompt). > # =A06. =A0`mergemaster -p' > # =A07. =A0`make installworld' > # =A08. =A0`make delete-old' > # =A09. =A0`mergemaster' =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = (you may wish to use -U or -ai). > # 10. =A0`reboot' > # 11. =A0`make delete-old-libs' (in case no 3rd party program uses them a= nymore) Yeah, that is very close to what I did: # cd /usr/src # make buildworld # make kernel KERNCONF=3DLIGHTNING # reboot That was for the first install, that got completely borked after rebooting and me trying to change the contents of /etc/fstab. On this current install, I did this: # cd /usr/src # make buildworld # make kernel KERNCONF=3DLIGHTNING # mergemaster -p # make installworld # make delete-old # mergemaster -i # make delete-old-libs # reboot The reason for me to try all that before rebooting, like I said on the first e-mail, was that I thought the drive numbers changing could be related to the -STABLE kernel running on top of -RELEASE userland. All those steps ran just fine, though. But when I reboot, I still see the kernel assigning ad10 to my first drive (it's ad8 with the -RELEASE kernel) and ad16 for the second (ad14 with -RELEASE). I have no idea what is causing this change in numbering. Thanks, Fred From owner-freebsd-stable@FreeBSD.ORG Fri May 14 03:17:08 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EBB421065670 for ; Fri, 14 May 2010 03:17:08 +0000 (UTC) (envelope-from fred@storming.org) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 7567A8FC18 for ; Fri, 14 May 2010 03:17:08 +0000 (UTC) Received: by fxm17 with SMTP id 17so1120872fxm.13 for ; Thu, 13 May 2010 20:17:07 -0700 (PDT) Received: by 10.239.193.136 with SMTP id j8mr76066hbi.143.1273807027178; Thu, 13 May 2010 20:17:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.239.148.78 with HTTP; Thu, 13 May 2010 20:16:47 -0700 (PDT) In-Reply-To: <20100514030630.GA84755@icarus.home.lan> References: <20100514030630.GA84755@icarus.home.lan> From: Fred Souza Date: Fri, 14 May 2010 00:16:47 -0300 Message-ID: To: Jeremy Chadwick Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable@freebsd.org Subject: Re: Mount root error / New device numbering? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 May 2010 03:17:09 -0000 On Fri, May 14, 2010 at 00:06, Jeremy Chadwick w= rote: > There is probably an ata(4) device layer change which either fixes (yes > really), breaks (possibly), or enhances (likely) support for your ATA or > SATA controller. =A0This is pretty much how the ata(4) layer has behaved > for years upon years -- that's just how it goes. =A0If this is your first > time encountering it, congratulations. =A0:-) =A0The device names *should > not* change on you once you stick with that kernel; it just indicates > something changed between -RELEASE and -STABLE. Hmmm.. Ok, then that may not be me messing up. Good news for me!.. I guess.= . > I'd recommend booting/trying an actual 8.0-STABLE snapshot image from > here: > > ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/201004/ > > This will allow you to boot and install 8.0-STABLE on your system. =A0You > should see devices ad10 and ad16 there as well. =A0It would at least save > you the pain of installing the kernel, rebooting, and finding you have > to manually deal with /etc/fstab changes and so on. =A0Give this a shot > first. > > It also might help in debugging the "stray IRQ" problem you see (it > would be useful to know what's sitting on IRQ 21; it may be an unused > device in your BIOS which you can disable there, or try to find a > FreeBSD driver for the device which can attach to the IRQ). I will try that, thank you very much. But as future reference.. Should it work if I just get to that shell prompt, change /etc/fstab to match those number changes and reboot? I'm asking because that sounded like the way to go when I first encountered this problem, but I ended making my system unusable. It is possible that I left anything out when I tried that, or that I changed something incorrectly.. But the idea should work, right? Thank you, Fred From owner-freebsd-stable@FreeBSD.ORG Fri May 14 03:25:41 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 19D361065676 for ; Fri, 14 May 2010 03:25:41 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta01.emeryville.ca.mail.comcast.net (qmta01.emeryville.ca.mail.comcast.net [76.96.30.16]) by mx1.freebsd.org (Postfix) with ESMTP id F37BB8FC17 for ; Fri, 14 May 2010 03:25:40 +0000 (UTC) Received: from omta13.emeryville.ca.mail.comcast.net ([76.96.30.52]) by qmta01.emeryville.ca.mail.comcast.net with comcast id HFJk1e00217UAYkA1FRhRA; Fri, 14 May 2010 03:25:41 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta13.emeryville.ca.mail.comcast.net with comcast id HFRh1e0023S48mS8ZFRho9; Fri, 14 May 2010 03:25:41 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 151299B419; Thu, 13 May 2010 20:25:40 -0700 (PDT) Date: Thu, 13 May 2010 20:25:40 -0700 From: Jeremy Chadwick To: Fred Souza Message-ID: <20100514032540.GA85214@icarus.home.lan> References: <20100514030630.GA84755@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-stable@freebsd.org Subject: Re: Mount root error / New device numbering? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 May 2010 03:25:41 -0000 On Fri, May 14, 2010 at 12:16:47AM -0300, Fred Souza wrote: > > I'd recommend booting/trying an actual 8.0-STABLE snapshot image from > > here: > > > > ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/201004/ > > > > This will allow you to boot and install 8.0-STABLE on your system.  You > > should see devices ad10 and ad16 there as well.  It would at least save > > you the pain of installing the kernel, rebooting, and finding you have > > to manually deal with /etc/fstab changes and so on.  Give this a shot > > first. > > > > It also might help in debugging the "stray IRQ" problem you see (it > > would be useful to know what's sitting on IRQ 21; it may be an unused > > device in your BIOS which you can disable there, or try to find a > > FreeBSD driver for the device which can attach to the IRQ). > > I will try that, thank you very much. But as future reference.. Should > it work if I just get to that shell prompt, change /etc/fstab to match > those number changes and reboot? I'm asking because that sounded like > the way to go when I first encountered this problem, but I ended > making my system unusable. It is possible that I left anything out > when I tried that, or that I changed something incorrectly.. But the > idea should work, right? Absolutely. I've done it myself many times over the years, including remotely over serial console. However, you said you did that then typed "exit" rather than "reboot", and the end result was a kernel panic. Honestly, I'm not surprised; the system was probably still confused about the root device. I'm guessing some kernel innards (or maybe something picked up from boot2/loader) still referenced the "unknown root device" and caused the panic. > I do an exit on that shell just to get to a kernel panic message and a > quick reboot. I tried to unload the -STABLE kernel and boot from the > -RELEASE one, but now the system hangs right after it tries to find my > disks. Even on other operating systems, if I'm dropped (unintentionally or intentionally/by choice) into single-user mode, I reboot the system rather than exit out of single-user and hope that multi-user works from that point forward. I've seen "exit" on Solaris fail and cause all sorts of mayhem (all sorts of system startup services (not rc/init!) failing, machine ending up in some sort of catatonic state). -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Fri May 14 03:32:33 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A52C11065673 for ; Fri, 14 May 2010 03:32:33 +0000 (UTC) (envelope-from fred@storming.org) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 3F4FF8FC0A for ; Fri, 14 May 2010 03:32:33 +0000 (UTC) Received: by fxm17 with SMTP id 17so1128585fxm.13 for ; Thu, 13 May 2010 20:32:32 -0700 (PDT) Received: by 10.239.189.139 with SMTP id t11mr88106hbh.17.1273807952132; Thu, 13 May 2010 20:32:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.239.148.78 with HTTP; Thu, 13 May 2010 20:32:12 -0700 (PDT) In-Reply-To: <20100514032540.GA85214@icarus.home.lan> References: <20100514030630.GA84755@icarus.home.lan> <20100514032540.GA85214@icarus.home.lan> From: Fred Souza Date: Fri, 14 May 2010 00:32:12 -0300 Message-ID: To: Jeremy Chadwick Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable@freebsd.org Subject: Re: Mount root error / New device numbering? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 May 2010 03:32:33 -0000 On Fri, May 14, 2010 at 00:25, Jeremy Chadwick w= rote: > Absolutely. =A0I've done it myself many times over the years, including > remotely over serial console. =A0However, you said you did that then type= d > "exit" rather than "reboot", and the end result was a kernel panic. Yes, I should have given it another clean try after changing /etc/fstab. I guess my rustiness with the Good Stuff(tm) plus the unexpected behavior made me panic myself. > Honestly, I'm not surprised; the system was probably still confused > about the root device. =A0I'm guessing some kernel innards (or maybe > something picked up from boot2/loader) still referenced the "unknown > root device" and caused the panic. Could be. The system had just too many possible points of failure at that point (its original kernel refused to boot for a few hours due to the geometry mess, then all of a sudden started working normally, for instance), so I take whatever I learned from that install as experience. I'm glad I thought about the right thing to do, it may have failed for a number of things in the way. > Even on other operating systems, if I'm dropped (unintentionally or > intentionally/by choice) into single-user mode, I reboot the system > rather than exit out of single-user and hope that multi-user works from > that point forward. =A0I've seen "exit" on Solaris fail and cause all > sorts of mayhem (all sorts of system startup services (not rc/init!) > failing, machine ending up in some sort of catatonic state). Good to know, I never really paid much attention to those details (I will from now on). Thank you a lot for the help, Jeremy. I will try your suggestions in the morning and post back to tell what did I find out. Best regards, Fred From owner-freebsd-stable@FreeBSD.ORG Fri May 14 03:37:37 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A0EAE1065670 for ; Fri, 14 May 2010 03:37:37 +0000 (UTC) (envelope-from TERRY@tmk.com) Received: from server.tmk.com (server.tmk.com [204.141.35.63]) by mx1.freebsd.org (Postfix) with ESMTP id 7C7378FC08 for ; Fri, 14 May 2010 03:37:37 +0000 (UTC) Received: from tmk.com by tmk.com (PMDF V6.4 #37010) id <01NN3295HL34006UN1@tmk.com> for freebsd-stable@freebsd.org; Thu, 13 May 2010 23:08:25 -0400 (EDT) Date: Thu, 13 May 2010 23:04:41 -0400 (EDT) From: Terry Kennedy To: freebsd-stable@freebsd.org Message-id: <01NN32EOXMYC006UN1@tmk.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=us-ascii Subject: Crash dump problem - sleeping thread owns a non-sleepable lock during crash dump write X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 May 2010 03:37:37 -0000 I'm reposting this over here at the suggestion of the Forums moderator. The original post is at http://forums.freebsd.org/showthread.php?t=14163 Got an interesting crash just now (well, as interesting as a crash on a soon-to-be production system can be). This is 8-STABLE/amd64, last cvsup'd early in the morning of May 9th. The system didn't complete the crash dump, so it needed a manual reset to get it going again. The crash was a "page fault while in kernel mode" with the current process being the interrupt service routine for the bce0 GigE. Things progressed reasonably until partway through the dump, when the system locked up with a "Sleeping thread (tid 100028, pid 12) owns a non-sleepable lock". That's the same PID as reported in the main crash. Screen capture at http://www.tmk.com/transient/crash-20100513002317.png Complete dmesg, etc. available on request. As I mentioned above, the system needed a hard reset to get going again. savecore doesn't think there's a usable dump, so I don't think there's any more info to gather. I just cvsup'd the box and built a new kernel, in case the previous cvsup was in between related commits, or to see if anything changed since. I still have the old kernel around in case any useful info can be gathered from it. So, a couple questions: 1) Anything known to be funky w/ bce? 2) Should the part of the system that caused the panic be able to lock up the crash dump process? Obviously, if the disk driver causes a panic, all bets are off when trying to use it to write the dump, but this crash seems to have been from a network driver. Shouldn't a double panic just give up on the dump and try a reboot? 3) Is there any way to rig the system to obtain more info if this happens again? Right now I'm using an embedded remote console server, but I could switch the system to a serial port if enabling the kernel debugger might help. But I think that the sleeping thread bit would happen even at the debugger prompt, wouldn't it? I just booted the new kernel and tried this again, and got another crash. The message is identical to the first, except that the instruction pointer changed by 0x10 (presumably due to code differences between the old and new kernels) and it got 6MB further writing the crash dump. Since it seems I can reproduce this at will, I'll be glad to either perform additional information-gathering or give a developer access to the box for testing purposes. Is it possible to correlate the source line in the kernel with the instruction pointer in the panic? Terry Kennedy http://www.tmk.com terry@tmk.com New York, NY USA From owner-freebsd-stable@FreeBSD.ORG Fri May 14 04:30:06 2010 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1C3A3106564A for ; Fri, 14 May 2010 04:30:06 +0000 (UTC) (envelope-from rihad@mail.ru) Received: from mx33.mail.ru (mx33.mail.ru [94.100.176.47]) by mx1.freebsd.org (Postfix) with ESMTP id CD50E8FC0A for ; Fri, 14 May 2010 04:30:05 +0000 (UTC) Received: from [217.25.27.27] (port=35370 helo=[217.25.27.27]) by mx33.mail.ru with asmtp id 1OCmXD-0002vl-00; Fri, 14 May 2010 08:30:03 +0400 Message-ID: <4BECD1CB.9060902@mail.ru> Date: Fri, 14 May 2010 09:30:03 +0500 From: rihad User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100423 Thunderbird/3.0.4 MIME-Version: 1.0 To: Doug Ambrisko References: <201005132313.o4DNDBrp078232@ambrisko.com> In-Reply-To: <201005132313.o4DNDBrp078232@ambrisko.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam: Not detected X-Mras: Ok Cc: freebsd-stable@FreeBSD.org Subject: Re: Enabling watchdog X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 May 2010 04:30:06 -0000 On 05/14/2010 04:13 AM, Doug Ambrisko wrote: > rihad writes: > | Hi, I'm thinking of enabling the watchdog on our Dell PowerEdge 2950 / > | FreeBSD 8.0 amd64, so that it reboots the machine in case of lockups. > | Right now it doesn't work: > | > | # watchdog > | watchdog: patting the dog: Operation not supported > | # > | Looking through the kernel configuration I found two relevant settings: > | In /sys/conf/NOTES: > | # > | # Add software watchdog routines. > | # > | options SW_WATCHDOG > | > | and in /sys/amd64/conf/NOTES: > | # > | # Watchdog routines. > | # > | options MP_WATCHDOG > | > | Which of them should I rebuild the kernel with? BTW, the existing kernel > | is built with the default "options SCHED_ULE" to make good use of > | multiple CPUs, does watchdog work with it? > > If no one has said yet, kldload ipmi then run watchdogd. ... or compile > it into the kernel. This will enable the IPMI HW watchdog. If it triggers, > it will appear in the IPMI SEL (ipmitool sel list). > Thanks. So did I understand it right that I should first install sysutils/ipmitool, then start polling "ipmitool sel list" in a shell script from a cron job run once a minute, and reboot in case IPMI triggers? But if it's a kernel lockup, none of the user level code might run at all. Any way to fall back to a hard and fast kernel level machine reset? From owner-freebsd-stable@FreeBSD.ORG Fri May 14 06:42:29 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6463F1065673; Fri, 14 May 2010 06:42:29 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 3659D8FC15; Fri, 14 May 2010 06:42:27 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id JAA26633; Fri, 14 May 2010 09:42:25 +0300 (EEST) (envelope-from avg@icyb.net.ua) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1OCobI-000LPZ-Jy; Fri, 14 May 2010 09:42:24 +0300 Message-ID: <4BECF0CC.4060800@icyb.net.ua> Date: Fri, 14 May 2010 09:42:20 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.24 (X11/20100321) MIME-Version: 1.0 To: Giovanni Trematerra References: <4DEBDE2C-C0D2-469D-AC42-DD5027926424@FreeBSD.org> <20100507120843.GA1738@Melon.malikania.fr> <1273257226.1671.3.camel@malikania.fr> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Attilio Rao , freebsd-acpi@freebsd.org, freebsd-stable@freebsd.org Subject: Re: Kernel panic when unpluggin AC adaptor X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 May 2010 06:42:29 -0000 on 14/05/2010 03:25 Giovanni Trematerra said the following: > Attilio and I came up with this patch. It seems ready for stress > testing and review > Please test and report back. It seems that there is inconsistent indentation for some of new lines. Original style seems to be softtabstop=4 tabstop=8 noexpandtab in vim-speak. -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Fri May 14 09:17:34 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F04661065670 for ; Fri, 14 May 2010 09:17:34 +0000 (UTC) (envelope-from petefrench@ticketswitch.com) Received: from constantine.ticketswitch.com (constantine.ticketswitch.com [IPv6:2002:57e0:1d4e:1::3]) by mx1.freebsd.org (Postfix) with ESMTP id B9A258FC1C for ; Fri, 14 May 2010 09:17:34 +0000 (UTC) Received: from dilbert.rattatosk ([10.64.50.6] helo=dilbert.ticketswitch.com) by constantine.ticketswitch.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1OCr1H-000Obv-5T; Fri, 14 May 2010 10:17:23 +0100 Received: from petefrench by dilbert.ticketswitch.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OCr1H-000EZs-4b; Fri, 14 May 2010 10:17:23 +0100 Date: Fri, 14 May 2010 10:17:23 +0100 Message-Id: To: freebsd-stable@freebsd.org, uqs@spoerlein.net From: Pete French Cc: Subject: Re: Any chance of someone commiting the patch in bin/131861 ? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 May 2010 09:17:35 -0000 > Postfix will re-write this as part of sanitization, so I had to revert > to creating mbox files by hand. Anyway, could you please test the > following patch with a wider variety of mails? I've been testing your patch for a few weeks now as my main email client, and I havent encountered any problems - it also does fix the reply issues I was originally having. Do you want to attach it to the PR ? After that maybe someone could commit it - I am pretty certain it doesnt actualy break any exising behaviour. cheers, -pete. From owner-freebsd-stable@FreeBSD.ORG Fri May 14 09:29:37 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D6CEA1065672 for ; Fri, 14 May 2010 09:29:37 +0000 (UTC) (envelope-from spil.oss@gmail.com) Received: from mail-pv0-f182.google.com (mail-pv0-f182.google.com [74.125.83.182]) by mx1.freebsd.org (Postfix) with ESMTP id AFDAE8FC16 for ; Fri, 14 May 2010 09:29:37 +0000 (UTC) Received: by pvh11 with SMTP id 11so957181pvh.13 for ; Fri, 14 May 2010 02:29:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:reply-to:date :message-id:subject:from:to:content-type; bh=SN8/M7XUdCln11sMcxYh3A4oQXQGQnDA7baOz3evuXc=; b=xZq/0A0sMnehDnm/2biSFfZ9oKacLkzP26NUXltVcf9R/I965BGaVaRnUR7pA3PuZi 6jIY7YxPN3UkLgCEz3DGp9Dm93b1niIXKi61wyba+nCV1dA6tlR9aPsm41cFELTaAOt0 sdt+Q3r4sRNHBy6Mx07gsnrHLXha4mv5f2go0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:date:message-id:subject:from:to:content-type; b=kwTClnBXbfiIGdDYIjxpOGfB0eOzTLR0GKz+DQoslU2eUitQEJf+YZ/9ph/h+u2pbL A2EMcXtSAmY1JmvqkJsSy7tzQrSGM9HPFiASZHF1smZt7HjPv49+dWZDvRz0/FkSgVUG aFLxOjtfBmi2beWIBGAlpZy9JWUuz0qsLJ+8Y= MIME-Version: 1.0 Received: by 10.141.105.19 with SMTP id h19mr577874rvm.281.1273828043623; Fri, 14 May 2010 02:07:23 -0700 (PDT) Received: by 10.140.136.18 with HTTP; Fri, 14 May 2010 02:07:23 -0700 (PDT) Date: Fri, 14 May 2010 11:07:23 +0200 Message-ID: From: Spil Oss To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: ipv6_ifconfig__alias not working X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: spil.oss@gmail.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 May 2010 09:29:37 -0000 Hi, I'm trying to set ipv6 aliases for my jails in my rc.conf but it doesn't seem to work as advertised. I have a /48 range assigned to me (for this example 2001:dead:beef) and am trying to assign ipv6 addresses to a jail. The jails will all have ipv6 addresses in the 2001:dead:beef:1 range. >From man rc.conf "Aliases should be set as ipv6_ifconfig__alias" My bge0 config in /etc/rc.conf: ifconfig_bge0="inet6 2001:dead:beef:2222::1/64 up" ipv4_addrs_bge0="10.10.2.1/24 10.10.2.2/24 10.10.2.3/24 10.10.2.5/24 10.10.2.6/24" ipv6_ifconfig_bge0_alias0="2001:dead:beef:1::5/64" rtadvd_interfaces="wlan0 bge0" Additional ipv6 config in /etc/rc.conf ipv6_enable="YES" ipv6_gateway_enable="YES" The "2001:dead:beef:1::5/64" address is not assigned to bge0. There must be some stupid mistake I'm making in my config. Is it perhaps the ifconfig_bge0 line that screws up my config? Kind regards, Spil. From owner-freebsd-stable@FreeBSD.ORG Fri May 14 09:40:47 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5EEA61065674 for ; Fri, 14 May 2010 09:40:47 +0000 (UTC) (envelope-from m.seaman@infracaninophile.co.uk) Received: from smtp.infracaninophile.co.uk (gate6.infracaninophile.co.uk [IPv6:2001:8b0:151:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id CD3808FC0A for ; Fri, 14 May 2010 09:40:46 +0000 (UTC) Received: from seedling.black-earth.co.uk (seedling.black-earth.co.uk [81.187.76.163]) (authenticated bits=0) by smtp.infracaninophile.co.uk (8.14.4/8.14.4) with ESMTP id o4E9ehUF005479 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Fri, 14 May 2010 10:40:43 +0100 (BST) (envelope-from m.seaman@infracaninophile.co.uk) Message-ID: <4BED1A9A.10706@infracaninophile.co.uk> Date: Fri, 14 May 2010 10:40:42 +0100 From: Matthew Seaman Organization: Infracaninophile User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: In-Reply-To: X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.96 at happy-idiot-talk.infracaninophile.co.uk X-Virus-Status: Clean X-Spam-Status: No, score=-1.1 required=5.0 tests=BAYES_00,DKIM_ADSP_ALL, SPF_FAIL autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on happy-idiot-talk.infracaninophile.co.uk Subject: Re: ipv6_ifconfig__alias not working X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 May 2010 09:40:47 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 14/05/2010 10:07:23, Spil Oss wrote: > I'm trying to set ipv6 aliases for my jails in my rc.conf but it > doesn't seem to work as advertised. I have a /48 range assigned to me > (for this example 2001:dead:beef) and am trying to assign ipv6 > addresses to a jail. The jails will all have ipv6 addresses in the > 2001:dead:beef:1 range. > >>From man rc.conf "Aliases should be set as ipv6_ifconfig__alias" > > My bge0 config in /etc/rc.conf: > ifconfig_bge0= > ipv4_addrs_bge0="10.10.2.1/24 10.10.2.2/24 10.10.2.3/24 10.10.2.5/24 > 10.10.2.6/24" > ipv6_ifconfig_bge0_alias0=" > rtadvd_interfaces="wlan0 bge0" > > Additional ipv6 config in /etc/rc.conf > ipv6_enable="YES" > ipv6_gateway_enable="YES" > > The "2001:dead:beef:1::5/64" address is not assigned to bge0. > There must be some stupid mistake I'm making in my config. Is it > perhaps the ifconfig_bge0 line that screws up my config? Hmmm... for consistencies' sake you should probably be using: ipv6_ifconfig_bge0="2001:dead:beef:2222::1/64" ipv6_ifconfig_bge0_alias0="2001:dead:beef:1::5/64" or, to make things absolutely parallel to your IPv4 settings: ipv6_addrs_bge0="2001:dead:beef:2222::1/64 2001:dead:beef:1::5/64" Cheers, Matthew - -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate Kent, CT11 9PW -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.14 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkvtGpoACgkQ8Mjk52CukIyauACeIVpsDf2VfGT0IpJXf0DQ2wLc ROQAoIomIPblYcDCtYDU1pjDakzHMbWN =OwJ5 -----END PGP SIGNATURE----- From owner-freebsd-stable@FreeBSD.ORG Fri May 14 10:30:29 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 35D181065670 for ; Fri, 14 May 2010 10:30:29 +0000 (UTC) (envelope-from spil.oss@gmail.com) Received: from mail-px0-f182.google.com (mail-px0-f182.google.com [209.85.212.182]) by mx1.freebsd.org (Postfix) with ESMTP id 0A3EF8FC13 for ; Fri, 14 May 2010 10:30:28 +0000 (UTC) Received: by pxi20 with SMTP id 20so1454252pxi.13 for ; Fri, 14 May 2010 03:30:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:reply-to :in-reply-to:references:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=sSUG478rgi8LBTOHeFOfSqPaUVDPtnTFyt/32IzulTc=; b=ALTsvrIfZUTX4iLWqChQmsTwZY/SAif86yPlqQFHWGY2T9YdSkAhCE4ILf4Or9mWTY VeAvz08OdfDexcJ0AxC/fHJ9KQ6eIPvGq6e3+z8xj05nbtJ8vRnglKAh05Ystzgo16mI fWvmxBjZW3YJ1XcYDaUASr9TskPcbncOfEWnw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:content-type:content-transfer-encoding; b=S4p9RIuYrowZD9cj3491SaqKaTBWz6UlQH3X9yvIXUT0pAzQ/AriupZDbwt7BvzE52 WJU/1hXZvpZdv0mDA4Fc8/7BhwqzVTPVDtRvMl5vwq/TS2vamNxm6Xaqeoww+VUVaI/x /iuHls1nF/J7pOoCfLyAVwPGLddM7WC0FfqiM= MIME-Version: 1.0 Received: by 10.141.91.19 with SMTP id t19mr659652rvl.104.1273833028450; Fri, 14 May 2010 03:30:28 -0700 (PDT) Received: by 10.140.136.18 with HTTP; Fri, 14 May 2010 03:30:28 -0700 (PDT) In-Reply-To: <4BED1A9A.10706@infracaninophile.co.uk> References: <4BED1A9A.10706@infracaninophile.co.uk> Date: Fri, 14 May 2010 12:30:28 +0200 Message-ID: From: Spil Oss To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: ipv6_ifconfig__alias not working X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: spil.oss@gmail.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 May 2010 10:30:29 -0000 Thanks for the hints Matthew! Cleaning up my config I found the culprit..... Copied ipv6_network_interfaces=3D"gif0" from some guide which off course defeated all my efforts to configure ipv6 on the other interfaces. The ipv6_addrs_ knob doesn't seem to work (this is 8.0-p2), can't find any references to it in the subr files either. Saw that there's quite a bit of changes in -head though.... Kind regards, Spil. On Fri, May 14, 2010 at 11:40 AM, Matthew Seaman wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 14/05/2010 10:07:23, Spil Oss wrote: > >> I'm trying to set ipv6 aliases for my jails in my rc.conf but it >> doesn't seem to work as advertised. I have a /48 range assigned to me >> (for this example 2001:dead:beef) and am trying to assign ipv6 >> addresses to a jail. The jails will all have ipv6 addresses in the >> 2001:dead:beef:1 range. >> >>>From man rc.conf "Aliases should be set as ipv6_ifconfig__ali= as" >> >> My bge0 config in /etc/rc.conf: >> ifconfig_bge0=3D >> ipv4_addrs_bge0=3D"10.10.2.1/24 10.10.2.2/24 10.10.2.3/24 10.10.2.5/24 >> 10.10.2.6/24" >> ipv6_ifconfig_bge0_alias0=3D" >> rtadvd_interfaces=3D"wlan0 bge0" >> >> Additional ipv6 config in /etc/rc.conf >> ipv6_enable=3D"YES" >> ipv6_gateway_enable=3D"YES" >> >> The "2001:dead:beef:1::5/64" address is not assigned to bge0. >> There must be some stupid mistake I'm making in my config. Is it >> perhaps the ifconfig_bge0 line that screws up my config? > > Hmmm... for consistencies' sake you should probably be using: > > ipv6_ifconfig_bge0=3D"2001:dead:beef:2222::1/64" > ipv6_ifconfig_bge0_alias0=3D"2001:dead:beef:1::5/64" > > or, to make things absolutely parallel to your IPv4 settings: > > ipv6_addrs_bge0=3D"2001:dead:beef:2222::1/64 2001:dead:beef:1::5/64" > > =A0 =A0 =A0 =A0Cheers, > > =A0 =A0 =A0 =A0Matthew > > - -- > Dr Matthew J Seaman MA, D.Phil. =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 7 Pri= ory Courtyard > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0Flat 3 > PGP: http://www.infracaninophile.co.uk/pgpkey =A0 =A0 Ramsgate > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0Kent, CT11 9PW > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.14 (Darwin) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAkvtGpoACgkQ8Mjk52CukIyauACeIVpsDf2VfGT0IpJXf0DQ2wLc > ROQAoIomIPblYcDCtYDU1pjDakzHMbWN > =3DOwJ5 > -----END PGP SIGNATURE----- > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > From owner-freebsd-stable@FreeBSD.ORG Fri May 14 11:53:25 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C64701065672 for ; Fri, 14 May 2010 11:53:25 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 9894B8FC1C for ; Fri, 14 May 2010 11:53:25 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 466FA46B99; Fri, 14 May 2010 07:53:25 -0400 (EDT) Received: from John-Baldwins-Macbook-Pro.local (localhost [IPv6:::1]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 5DAC28A021; Fri, 14 May 2010 07:53:24 -0400 (EDT) Message-ID: <4BED3912.9080509@FreeBSD.org> Date: Fri, 14 May 2010 07:50:42 -0400 From: John Baldwin User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Terry Kennedy References: <01NN32EOXMYC006UN1@tmk.com> In-Reply-To: <01NN32EOXMYC006UN1@tmk.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Fri, 14 May 2010 07:53:24 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=BAYES_00,NO_RELAYS autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: freebsd-stable@freebsd.org Subject: Re: Crash dump problem - sleeping thread owns a non-sleepable lock during crash dump write X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 May 2010 11:53:25 -0000 Terry Kennedy wrote: > I'm reposting this over here at the suggestion of the Forums moderator. > The original post is at http://forums.freebsd.org/showthread.php?t=14163 > > Got an interesting crash just now (well, as interesting as a crash on a > soon-to-be production system can be). > > This is 8-STABLE/amd64, last cvsup'd early in the morning of May 9th. > > The system didn't complete the crash dump, so it needed a manual reset to get > it going again. > > The crash was a "page fault while in kernel mode" with the current process > being the interrupt service routine for the bce0 GigE. Things progressed > reasonably until partway through the dump, when the system locked up with a > "Sleeping thread (tid 100028, pid 12) owns a non-sleepable lock". That's the > same PID as reported in the main crash. Hmm. You could try changing the code to not do a nested panic in that case. You would update subr_turnstile.c to just return if panicstr is not NULL rather than calling panic. However, there is still a good chance you will end up deadlocking in that case. I have another patch I can send you next week that prevents blocking on mutexes duing a panic which may also help. > 3) Is there any way to rig the system to obtain more info if this happens > again? Right now I'm using an embedded remote console server, but I could > switch the system to a serial port if enabling the kernel debugger might help. > But I think that the sleeping thread bit would happen even at the debugger > prompt, wouldn't it? Include DDB and enable the 'trace_on_panic' sysctl knob perhaps. > I just booted the new kernel and tried this again, and got another crash. The > message is identical to the first, except that the instruction pointer changed > by 0x10 (presumably due to code differences between the old and new kernels) > and it got 6MB further writing the crash dump. > > Since it seems I can reproduce this at will, I'll be glad to either perform > additional information-gathering or give a developer access to the box for > testing purposes. > > Is it possible to correlate the source line in the kernel with the instruction > pointer in the panic? If you are booted into the same kernel with the same modules loaded, you can probably run 'kgdb' as root do 'l *'. -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Fri May 14 11:53:27 2010 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6079F106567F for ; Fri, 14 May 2010 11:53:27 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 332368FC27 for ; Fri, 14 May 2010 11:53:27 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id D812146B92; Fri, 14 May 2010 07:53:26 -0400 (EDT) Received: from John-Baldwins-Macbook-Pro.local (localhost [IPv6:::1]) by bigwig.baldwin.cx (Postfix) with ESMTPA id AE3328A026; Fri, 14 May 2010 07:53:25 -0400 (EDT) Message-ID: <4BED3974.1000704@FreeBSD.org> Date: Fri, 14 May 2010 07:52:20 -0400 From: John Baldwin User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: rihad References: <201005132313.o4DNDBrp078232@ambrisko.com> <4BECD1CB.9060902@mail.ru> In-Reply-To: <4BECD1CB.9060902@mail.ru> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Fri, 14 May 2010 07:53:25 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=BAYES_00,NO_RELAYS autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: freebsd-stable@FreeBSD.org Subject: Re: Enabling watchdog X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 May 2010 11:53:27 -0000 rihad wrote: > On 05/14/2010 04:13 AM, Doug Ambrisko wrote: >> rihad writes: >> | Hi, I'm thinking of enabling the watchdog on our Dell PowerEdge 2950 / >> | FreeBSD 8.0 amd64, so that it reboots the machine in case of lockups. >> | Right now it doesn't work: >> | >> | # watchdog >> | watchdog: patting the dog: Operation not supported >> | # >> | Looking through the kernel configuration I found two relevant settings: >> | In /sys/conf/NOTES: >> | # >> | # Add software watchdog routines. >> | # >> | options SW_WATCHDOG >> | >> | and in /sys/amd64/conf/NOTES: >> | # >> | # Watchdog routines. >> | # >> | options MP_WATCHDOG >> | >> | Which of them should I rebuild the kernel with? BTW, the existing >> kernel >> | is built with the default "options SCHED_ULE" to make good use of >> | multiple CPUs, does watchdog work with it? >> >> If no one has said yet, kldload ipmi then run watchdogd. ... or compile >> it into the kernel. This will enable the IPMI HW watchdog. If it >> triggers, >> it will appear in the IPMI SEL (ipmitool sel list). >> > Thanks. So did I understand it right that I should first install > sysutils/ipmitool, then start polling "ipmitool sel list" in a shell > script from a cron job run once a minute, and reboot in case IPMI > triggers? But if it's a kernel lockup, none of the user level code might > run at all. Any way to fall back to a hard and fast kernel level machine > reset? No, watchdogd and the IPMI driver will manage the watchdog. You can use 'sel elist' after a reboot to see if the reboot was triggered via the watchdog. -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Fri May 14 12:12:15 2010 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D3974106566C for ; Fri, 14 May 2010 12:12:15 +0000 (UTC) (envelope-from TERRY@tmk.com) Received: from server.tmk.com (server.tmk.com [204.141.35.63]) by mx1.freebsd.org (Postfix) with ESMTP id 8B5A28FC0C for ; Fri, 14 May 2010 12:12:15 +0000 (UTC) Received: from tmk.com by tmk.com (PMDF V6.4 #37010) id <01NN3KQSDKWW006QOF@tmk.com>; Fri, 14 May 2010 08:12:13 -0400 (EDT) Date: Fri, 14 May 2010 07:59:40 -0400 (EDT) From: Terry Kennedy In-reply-to: "Your message dated Fri, 14 May 2010 07:50:42 -0400" <4BED3912.9080509@FreeBSD.org> To: John Baldwin Message-id: <01NN3LDWWAQ6006QOF@tmk.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed References: <01NN32EOXMYC006UN1@tmk.com> Cc: freebsd-stable@FreeBSD.org Subject: Re: Crash dump problem - sleeping thread owns a non-sleepable lock during crash dump write X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 May 2010 12:12:15 -0000 > > The crash was a "page fault while in kernel mode" with the current process > > being the interrupt service routine for the bce0 GigE. Things progressed > > reasonably until partway through the dump, when the system locked up with a > > "Sleeping thread (tid 100028, pid 12) owns a non-sleepable lock". That's the > > same PID as reported in the main crash. > > Hmm. You could try changing the code to not do a nested panic in that > case. You would update subr_turnstile.c to just return if panicstr is > not NULL rather than calling panic. However, there is still a good > chance you will end up deadlocking in that case. I have another patch I > can send you next week that prevents blocking on mutexes duing a panic > which may also help. Ok, I'll be glad to try that. > > 3) Is there any way to rig the system to obtain more info if this happens > > again? Right now I'm using an embedded remote console server, but I could > > switch the system to a serial port if enabling the kernel debugger might help. > > But I think that the sleeping thread bit would happen even at the debugger > > prompt, wouldn't it? > > Include DDB and enable the 'trace_on_panic' sysctl knob perhaps. Hmmm. Do you think it will get very far before the sleeping thread business locks it up? > > Is it possible to correlate the source line in the kernel with the instruction > > pointer in the panic? > > If you are booted into the same kernel with the same modules loaded, you > can probably run 'kgdb' as root do 'l *'. I did that and discovered that the 0x20: prefix is probably unwanted: (kgdb) l *0x20:0xffffffff801e3c06 A syntax error in expression, near `:0xffffffff801e3c06'. (kgdb) l *0xffffffff801e3c06 0xffffffff801e3c06 is in bce_start_locked (/usr/src/sys/dev/bce/if_bce.c:6996). 6991 } 6992 6993 count++; 6994 6995 /* Send a copy of the frame to any BPF listeners. */ 6996 ETHER_BPF_MTAP(ifp, m_head); 6997 } 6998 6999 /* Exit if no packets were dequeued. */ 7000 if (count == 0) { (kgdb) This kernel does have BPF compiled in, but I don't think it was in use at the time. Any further suggestions to look at (remember, this system is in another state from me and all I have is remote access to the framebuffer - I'd have to go there and set up a serial console to be able to talk to the debugger if it crashes). Thanks, Terry Kennedy http://www.tmk.com terry@tmk.com New York, NY USA From owner-freebsd-stable@FreeBSD.ORG Fri May 14 12:14:04 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EAB2C106567D for ; Fri, 14 May 2010 12:14:03 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id D26208FC14 for ; Fri, 14 May 2010 12:14:02 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id PAA04818; Fri, 14 May 2010 15:13:58 +0300 (EEST) (envelope-from avg@icyb.net.ua) Message-ID: <4BED3E85.5000803@icyb.net.ua> Date: Fri, 14 May 2010 15:13:57 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.24 (X11/20100319) MIME-Version: 1.0 To: Chris Buechler References: In-Reply-To: X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD Stable , net@freebsd.org Subject: Re: regression in dc(4) from 7.2 to RELENG_8 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 May 2010 12:14:04 -0000 on 14/05/2010 09:42 Chris Buechler said the following: > one of our users has reported a regression in dc(4) on RELENG_8, the > cards work fine on 7.2 and previous versions, but no longer function at > all with RELENG_8 as of about a week ago. > http://forum.pfsense.org/index.php/topic,24964.msg129488.html#msg129488 Perhaps this might be a cardbus issue (or even a more general issue) rather than a dc(4) issue. But first please try this patch reversed: --- a/sys/dev/dc/if_dc.c +++ b/sys/dev/dc/if_dc.c @@ -331,7 +331,6 @@ static driver_t dc_driver = { static devclass_t dc_devclass; -DRIVER_MODULE(dc, cardbus, dc_driver, dc_devclass, 0, 0); DRIVER_MODULE(dc, pci, dc_driver, dc_devclass, 0, 0); DRIVER_MODULE(miibus, dc, miibus_driver, miibus_devclass, 0, 0); > dmesg from it working, from 7.2: > cbb0: at device 11.0 on pci0 > cardbus0: on cbb0 > pccard0: <16-bit PCCard bus> on cbb0 > cbb0: [ITHREAD] > cbb1: at device 11.1 on pci0 > cardbus1: on cbb1 > pccard1: <16-bit PCCard bus> on cbb1 > cbb1: [ITHREAD] > dc0: port 0x1080-0x10ff mem > 0x88000000-0x880007ff,0x88001000-0x880017ff irq 11 at device 0.0 on > cardbus0 > miibus1: on dc0 > tdkphy0: PHY 0 on miibus1 > tdkphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > dc0: Ethernet address: 00:xx:xx:xx:xx:56 > dc0: [ITHREAD] > dc1: port 0x1100-0x117f mem > 0x88002000-0x880027ff,0x88003000-0x880037ff irq 11 at device 0.0 on > cardbus1 > miibus2: on dc1 > tdkphy1: PHY 0 on miibus2 > tdkphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > dc1: Ethernet address: 00:xx:xx:xx:xx:66 > dc1: [ITHREAD] > > Not working, RELENG_8: > cbb0: at device 11.0 on pci0 > cardbus0: on cbb0 > pccard0: <16-bit PCCard bus> on cbb0 > cbb0: [FILTER] > cbb1: at device 11.1 on pci0 > cardbus1: on cbb1 > pccard1: <16-bit PCCard bus> on cbb1 > cbb1: [FILTER] > cardbus0: Unable to allocate resource to read CIS. > cardbus0: Unable to allocate resources for CIS > cardbus0: Unable to allocate resource to read CIS. > cardbus0: Unable to allocate resources for CIS > dc0: port 0x1080-0x10ff mem > 0x88000000-0x880007ff,0x88001000-0x880017ff irq 11 at device 0.0 on > cardbus0 > dc0: No station address in CIS! > device_attach: dc0 attach returned 6 > cardbus1: Unable to allocate resource to read CIS. > cardbus1: Unable to allocate resources for CIS > cardbus1: Unable to allocate resource to read CIS. > cardbus1: Unable to allocate resources for CIS > dc1: port 0x1080-0x10ff mem > 0x88002000-0x880027ff,0x88003000-0x880037ff irq 11 at device 0.0 on > cardbus1 > dc1: No station address in CIS! > device_attach: dc1 attach returned 6 > > > We can apply patches to our builds for this person and others to test > and confirm the fix, before it's committed into FreeBSD. > > Chris > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Fri May 14 12:49:52 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CFD6D1065670 for ; Fri, 14 May 2010 12:49:52 +0000 (UTC) (envelope-from fred@storming.org) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 6B3788FC13 for ; Fri, 14 May 2010 12:49:52 +0000 (UTC) Received: by fxm17 with SMTP id 17so1602343fxm.13 for ; Fri, 14 May 2010 05:49:51 -0700 (PDT) Received: by 10.239.129.197 with SMTP id 5mr128877hbg.77.1273841391183; Fri, 14 May 2010 05:49:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.239.148.78 with HTTP; Fri, 14 May 2010 05:49:31 -0700 (PDT) In-Reply-To: References: <20100514030630.GA84755@icarus.home.lan> <20100514032540.GA85214@icarus.home.lan> From: Fred Souza Date: Fri, 14 May 2010 09:49:31 -0300 Message-ID: To: Jeremy Chadwick Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-stable@freebsd.org Subject: Re: Mount root error / New device numbering? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 May 2010 12:49:52 -0000 On Fri, May 14, 2010 at 00:32, Fred Souza wrote: > Good to know, I never really paid much attention to those details (I > will from now on). Thank you a lot for the help, Jeremy. I will try > your suggestions in the morning and post back to tell what did I find > out. Like I said, here are my findings: Jeremy's pointers were very correct, the difference in numbering seems to be just an ata(4) change. Manually changing entries in /etc/fstab does fix it, and I found out that the kernel panic I was getting was merely a simple detail I overlooked: The 3rd-party nvidia driver had been compiled on -RELEASE and was causing the kernel panics on -STABLE. Simply disabling its loading at the boot loader prompt, then booting with /etc/fstab properly updated and then reinstalling the nvidia-driver port (`portmaster nvidia-driver`) fixed it. Just to be on the safe side, I also reinstalled the other 3rd-party kernel module I use (fusefs-ntfs3g), even though it wasn't giving me any errors. I did try the -STABLE snapshot image as Jeremy suggested, that's how I figured he was right about the numering difference being an ata(4) change. I preferred to just manually change the previous install's /etc/fstab, though (but maybe there was a better way of doing this with the -STABLE snapshot DVD). The interrupt storm on irq21 is still happening, and I'm going to work on that next. Mounting any non-audio CD/DVD stops it, so I'll keep doing that until I actually find a fix for the issue. So thank you very much, Jeremy. Your pointers were very helpful in fixing my problem. Best regards, Fred From owner-freebsd-stable@FreeBSD.ORG Fri May 14 13:29:26 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9D6B31065670; Fri, 14 May 2010 13:29:26 +0000 (UTC) (envelope-from matthew.fleming@isilon.com) Received: from seaxch09.isilon.com (seaxch09.isilon.com [74.85.160.25]) by mx1.freebsd.org (Postfix) with ESMTP id 7C0BB8FC0A; Fri, 14 May 2010 13:29:26 +0000 (UTC) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 14 May 2010 06:29:25 -0700 Message-ID: <06D5F9F6F655AD4C92E28B662F7F853E021D4D5D@seaxch09.desktop.isilon.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Crash dump problem - sleeping thread owns a non-sleepable lock during crash dump write Thread-Index: AcrzXGrdo0fQ/XSoSiSYh2lkHhaY0wADA90D References: <01NN32EOXMYC006UN1@tmk.com> <4BED3912.9080509@FreeBSD.org> From: "Matthew Fleming" To: "John Baldwin" , "Terry Kennedy" Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable@freebsd.org Subject: RE: Crash dump problem - sleeping thread owns a non-sleepable lock during crash dump write X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 May 2010 13:29:26 -0000 > > The crash was a "page fault while in kernel mode" with the current = process=20 > > being the interrupt service routine for the bce0 GigE. Things = progressed=20 > > reasonably until partway through the dump, when the system locked up = with a=20 > > "Sleeping thread (tid 100028, pid 12) owns a non-sleepable lock". = Thats the=20 > > same PID as reported in the main crash. >=20 > Hmm. You could try changing the code to not do a nested panic in that = > case. You would update subr_turnstile.c to just return if panicstr is = > not NULL rather than calling panic. However, there is still a good=20 > chance you will end up deadlocking in that case. I have another patch = I=20 > can send you next week that prevents blocking on mutexes duing a panic = > which may also help. It would be instructive to know exactly why we were in turnstile(9) but = its likely due to mtx contention. AIX has some code at the beginning of all the locking operations to = avoid taking locks if we were running code out of kdb, though getting = that worked out was slightly tricky with our variant of mtx_assert(9). = I seem to recall there was also some "lockbusting" code that forcibly = reset all owned locks to have no owner, at least in some paths. Given that the system is single-cpu and should be single-threaded when = dumping, this seems to me to be something worth working through to get = more reliable dumps. Except for mtx_assert(9) I cant think of a reason = to take locks once we start dumping or when in the debugger. As an aside, with terribly corrupted locks Ive seen double panics when = the attempt to print the lock name faulted in strlen(9) called for = printf(9), due to a bad lockname pointer. We have been able to get = enough info off these crashes to debug them, but its useful to remember = that the system may be in a very unstable state depending on why it = panics. Thanks, matthew From owner-freebsd-stable@FreeBSD.ORG Fri May 14 14:12:46 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2F8CD1065673 for ; Fri, 14 May 2010 14:12:46 +0000 (UTC) (envelope-from ambrisko@ambrisko.com) Received: from mail.ambrisko.com (mail.ambrisko.com [64.174.51.43]) by mx1.freebsd.org (Postfix) with ESMTP id 05B0F8FC17 for ; Fri, 14 May 2010 14:12:45 +0000 (UTC) X-Ambrisko-Me: Yes Received: from server2.ambrisko.com (HELO www.ambrisko.com) ([192.168.1.2]) by ironport.ambrisko.com with ESMTP; 14 May 2010 07:12:52 -0700 Received: from ambrisko.com (localhost [127.0.0.1]) by www.ambrisko.com (8.14.3/8.14.3) with ESMTP id o4EEGTGC057681; Fri, 14 May 2010 07:16:29 -0700 (PDT) (envelope-from ambrisko@ambrisko.com) Received: (from ambrisko@localhost) by ambrisko.com (8.14.3/8.14.3/Submit) id o4EEGS6E057680; Fri, 14 May 2010 07:16:28 -0700 (PDT) (envelope-from ambrisko) From: Doug Ambrisko Message-Id: <201005141416.o4EEGS6E057680@ambrisko.com> In-Reply-To: <4BECD1CB.9060902@mail.ru> To: rihad Date: Fri, 14 May 2010 07:16:28 -0700 (PDT) X-Mailer: ELM [version 2.4ME+ PL94b (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Cc: freebsd-stable@FreeBSD.org Subject: Re: Enabling watchdog X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 May 2010 14:12:46 -0000 rihad writes: | On 05/14/2010 04:13 AM, Doug Ambrisko wrote: | > rihad writes: | > | Hi, I'm thinking of enabling the watchdog on our Dell PowerEdge 2950 / | > | FreeBSD 8.0 amd64, so that it reboots the machine in case of lockups. | > | Right now it doesn't work: | > | | > | # watchdog | > | watchdog: patting the dog: Operation not supported | > | # | > | Looking through the kernel configuration I found two relevant settings: | > | In /sys/conf/NOTES: | > | # | > | # Add software watchdog routines. | > | # | > | options SW_WATCHDOG | > | | > | and in /sys/amd64/conf/NOTES: | > | # | > | # Watchdog routines. | > | # | > | options MP_WATCHDOG | > | | > | Which of them should I rebuild the kernel with? BTW, the existing kernel | > | is built with the default "options SCHED_ULE" to make good use of | > | multiple CPUs, does watchdog work with it? | > | > If no one has said yet, kldload ipmi then run watchdogd. ... or compile | > it into the kernel. This will enable the IPMI HW watchdog. If it triggers, | > it will appear in the IPMI SEL (ipmitool sel list). | | Thanks. So did I understand it right that I should first install | sysutils/ipmitool, then start polling "ipmitool sel list" in a shell | script from a cron job run once a minute, and reboot in case IPMI | triggers? But if it's a kernel lockup, none of the user level code might | run at all. Any way to fall back to a hard and fast kernel level machine | reset? Nope, when you load the ipmi driver it provides a HW watchdog via ipmi and works with watchdogd. Now if you want to know if your machines rebooted due to the watchdog then check the ipmi sel for the watchdog event. Doug A. From owner-freebsd-stable@FreeBSD.ORG Fri May 14 14:15:17 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A321D106566C for ; Fri, 14 May 2010 14:15:17 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [76.96.59.243]) by mx1.freebsd.org (Postfix) with ESMTP id 5285F8FC25 for ; Fri, 14 May 2010 14:15:16 +0000 (UTC) Received: from omta17.westchester.pa.mail.comcast.net ([76.96.62.89]) by qmta13.westchester.pa.mail.comcast.net with comcast id HNHT1e0011vXlb85DSFHlH; Fri, 14 May 2010 14:15:17 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta17.westchester.pa.mail.comcast.net with comcast id HSFF1e0073S48mS3dSFG1a; Fri, 14 May 2010 14:15:16 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 1EED49B419; Fri, 14 May 2010 07:15:14 -0700 (PDT) Date: Fri, 14 May 2010 07:15:14 -0700 From: Jeremy Chadwick To: Doug Ambrisko Message-ID: <20100514141514.GA1075@icarus.home.lan> References: <4BECD1CB.9060902@mail.ru> <201005141416.o4EEGS6E057680@ambrisko.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201005141416.o4EEGS6E057680@ambrisko.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: rihad , freebsd-stable@FreeBSD.org Subject: Re: Enabling watchdog X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 May 2010 14:15:17 -0000 On Fri, May 14, 2010 at 07:16:28AM -0700, Doug Ambrisko wrote: > rihad writes: > | On 05/14/2010 04:13 AM, Doug Ambrisko wrote: > | > rihad writes: > | > | Hi, I'm thinking of enabling the watchdog on our Dell PowerEdge 2950 / > | > | FreeBSD 8.0 amd64, so that it reboots the machine in case of lockups. > | > | Right now it doesn't work: > | > | > | > | # watchdog > | > | watchdog: patting the dog: Operation not supported > | > | # > | > | Looking through the kernel configuration I found two relevant settings: > | > | In /sys/conf/NOTES: > | > | # > | > | # Add software watchdog routines. > | > | # > | > | options SW_WATCHDOG > | > | > | > | and in /sys/amd64/conf/NOTES: > | > | # > | > | # Watchdog routines. > | > | # > | > | options MP_WATCHDOG > | > | > | > | Which of them should I rebuild the kernel with? BTW, the existing kernel > | > | is built with the default "options SCHED_ULE" to make good use of > | > | multiple CPUs, does watchdog work with it? > | > > | > If no one has said yet, kldload ipmi then run watchdogd. ... or compile > | > it into the kernel. This will enable the IPMI HW watchdog. If it triggers, > | > it will appear in the IPMI SEL (ipmitool sel list). > | > | Thanks. So did I understand it right that I should first install > | sysutils/ipmitool, then start polling "ipmitool sel list" in a shell > | script from a cron job run once a minute, and reboot in case IPMI > | triggers? But if it's a kernel lockup, none of the user level code might > | run at all. Any way to fall back to a hard and fast kernel level machine > | reset? > > Nope, when you load the ipmi driver it provides a HW watchdog via ipmi > and works with watchdogd. Now if you want to know if your machines > rebooted due to the watchdog then check the ipmi sel for the watchdog > event. I'm a bit confused at this point, Doug. At what point did the OP state he has IPMI support or IPMI cards in his system? -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Fri May 14 14:16:49 2010 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0F5C91065673; Fri, 14 May 2010 14:16:49 +0000 (UTC) (envelope-from TERRY@tmk.com) Received: from server.tmk.com (server.tmk.com [204.141.35.63]) by mx1.freebsd.org (Postfix) with ESMTP id D4CB58FC08; Fri, 14 May 2010 14:16:48 +0000 (UTC) Received: from tmk.com by tmk.com (PMDF V6.4 #37010) id <01NN3OVWEKKW006UN1@tmk.com>; Fri, 14 May 2010 10:16:46 -0400 (EDT) Date: Fri, 14 May 2010 09:56:47 -0400 (EDT) From: Terry Kennedy In-reply-to: "Your message dated Fri, 14 May 2010 06:29:25 -0700" <06D5F9F6F655AD4C92E28B662F7F853E021D4D5D@seaxch09.desktop.isilon.com> To: Matthew Fleming Message-id: <01NN3PQCOFHE006UN1@tmk.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=iso-8859-1 References: <01NN32EOXMYC006UN1@tmk.com> <4BED3912.9080509@FreeBSD.org> Cc: freebsd-stable@FreeBSD.org, John Baldwin Subject: RE: Crash dump problem - sleeping thread owns a non-sleepable lock during crash dump write X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 May 2010 14:16:49 -0000 > > Hmm. You could try changing the code to not do a nested panic in that > > case. You would update subr_turnstile.c to just return if panicstr is > > not NULL rather than calling panic. However, there is still a good > > chance you will end up deadlocking in that case. I have another patch I > > can send you next week that prevents blocking on mutexes duing a panic > > which may also help. > > It would be instructive to know exactly why we were in turnstile(9) but > its likely due to mtx contention. > > AIX has some code at the beginning of all the locking operations to avoid > taking locks if we were running code out of kdb, though getting that worked > out was slightly tricky with our variant of mtx_assert(9). I seem to recall > there was also some "lockbusting" code that forcibly reset all owned locks > to have no owner, at least in some paths. > Given that the system is single-cpu and should be single-threaded when > dumping, this seems to me to be something worth working through to get > more reliable dumps. Except for mtx_assert(9) I cant think of a reason > to take locks once we start dumping or when in the debugger. As an aside, this is a quad-core in one package CPU (an X3363). On both this box and a similar one with an X5470, console messages continue to print out after "the system has been halted - press any key to reboot" - in particular, the shutdown makes a bunch of the "behind the scenes" man- agement stuff like the virtual keyboard and monitor appear. Plugging or unplugging USB devices will go through the whole deal of detecting and making their service available. I know the other CPUs are considered to still be running (hence the "halting other CPUs" when you press a key to reboot), but this is the first time I've seen device detection, attachment, etc. show up on the console after a shutdown. Is this behavior to be expected, or is it as unexpected as it was to me? Systems are Dell Poweredge R300's, 8-STABLE amd64. > As an aside, with terribly corrupted locks Ive seen double panics when the > attempt to print the lock name faulted in strlen(9) called for printf(9), > due to a bad lockname pointer. We have been able to get enough info off > these crashes to debug them, but its useful to remember that the system > may be in a very unstable state depending on why it panics. True. In these crashes, the system is doing essentially nothing except the one application (which, unfortunately, I don't have the source code for). The second crash happened right after booting the system, logging in, and firing off the application. It left an identical footprint (other than the 0x10 byte offset due to a recompiled kernel) from the first one, where the system had been up for 13+ hours. So, in this case I don't think there was a bunch of corruption piling up which triggered the fault, but instead the one simple operation and right away - splat! As I mentioned in the original posting, I'd be glad to give a developer complete access to the system via the remote console (Dell DRAC 5 web interface) and to the underlying FreeBSD if it'll help pin down the prob- lem. Another thing I could try (would take a couple days until I could get someone to the site) would be to try this using a bge port instead of the bce one. That might help pin it down to either something in the bce- specific code path, or somewhere else in the stack. Thanks, Terry Kennedy http://www.tmk.com terry@tmk.com New York, NY USA From owner-freebsd-stable@FreeBSD.ORG Fri May 14 14:33:03 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2C7A9106566C for ; Fri, 14 May 2010 14:33:03 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [76.96.62.40]) by mx1.freebsd.org (Postfix) with ESMTP id CE0D98FC16 for ; Fri, 14 May 2010 14:33:02 +0000 (UTC) Received: from omta20.westchester.pa.mail.comcast.net ([76.96.62.71]) by qmta04.westchester.pa.mail.comcast.net with comcast id HNis1e0031YDfWL54SZ2sN; Fri, 14 May 2010 14:33:02 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta20.westchester.pa.mail.comcast.net with comcast id HSZ01e00U3S48mS3gSZ1q8; Fri, 14 May 2010 14:33:02 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id B29BD9B419; Fri, 14 May 2010 07:32:59 -0700 (PDT) Date: Fri, 14 May 2010 07:32:59 -0700 From: Jeremy Chadwick To: Terry Kennedy Message-ID: <20100514143259.GA1259@icarus.home.lan> References: <01NN32EOXMYC006UN1@tmk.com> <4BED3912.9080509@FreeBSD.org> <01NN3PQCOFHE006UN1@tmk.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <01NN3PQCOFHE006UN1@tmk.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-stable@FreeBSD.org, John Baldwin , Matthew Fleming Subject: Re: Crash dump problem - sleeping thread owns a non-sleepable lock during crash dump write X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 May 2010 14:33:03 -0000 On Fri, May 14, 2010 at 09:56:47AM -0400, Terry Kennedy wrote: > As an aside, this is a quad-core in one package CPU (an X3363). On both > this box and a similar one with an X5470, console messages continue to > print out after "the system has been halted - press any key to reboot" - > in particular, the shutdown makes a bunch of the "behind the scenes" man- > agement stuff like the virtual keyboard and monitor appear. Plugging or > unplugging USB devices will go through the whole deal of detecting and > making their service available. > > I know the other CPUs are considered to still be running (hence the > "halting other CPUs" when you press a key to reboot), but this is the > first time I've seen device detection, attachment, etc. show up on the > console after a shutdown. > > Is this behavior to be expected, or is it as unexpected as it was to > me? Systems are Dell Poweredge R300's, 8-STABLE amd64. I've seen this behaviour before (on non-Dell hardware). I'm under the impression there's an interrupt handler that isn't being unloaded, and that the driver framework within the kernel does not "unload" on FreeBSD. What exactly does FreeBSD do on a system halt? I'm under the impression the OS should be unloading its interrupt handlers and then execute the HLT opcode on each processor/core. I don't have a tendency to halt my Supermicro systems, but shutdown -r now or shutdown -p now is pretty common. I've noticed an overall improvement with regards to the shutdown procedure and how long things take during the final phases (after filesystems are unmounted, etc.) with the below sysctl set (in /etc/sysctl.conf, but you can set it in real-time via command-line). hw.acpi.handle_reboot=1 -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Fri May 14 14:39:26 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 361211065674 for ; Fri, 14 May 2010 14:39:26 +0000 (UTC) (envelope-from ambrisko@ambrisko.com) Received: from mail.ambrisko.com (mail.ambrisko.com [64.174.51.43]) by mx1.freebsd.org (Postfix) with ESMTP id E74C48FC19 for ; Fri, 14 May 2010 14:39:25 +0000 (UTC) X-Ambrisko-Me: Yes Received: from server2.ambrisko.com (HELO www.ambrisko.com) ([192.168.1.2]) by ironport.ambrisko.com with ESMTP; 14 May 2010 07:39:32 -0700 Received: from ambrisko.com (localhost [127.0.0.1]) by www.ambrisko.com (8.14.3/8.14.3) with ESMTP id o4EEh9bn060058; Fri, 14 May 2010 07:43:09 -0700 (PDT) (envelope-from ambrisko@ambrisko.com) Received: (from ambrisko@localhost) by ambrisko.com (8.14.3/8.14.3/Submit) id o4EEh9EJ060057; Fri, 14 May 2010 07:43:09 -0700 (PDT) (envelope-from ambrisko) From: Doug Ambrisko Message-Id: <201005141443.o4EEh9EJ060057@ambrisko.com> In-Reply-To: To: Tom Evans Date: Fri, 14 May 2010 07:43:09 -0700 (PDT) X-Mailer: ELM [version 2.4ME+ PL94b (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Cc: freebsd-stable@freebsd.org, Jeremy Chadwick Subject: Re: Enabling watchdog X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 May 2010 14:39:26 -0000 Tom Evans writes: | On Fri, May 14, 2010 at 3:15 PM, Jeremy Chadwick | wrote: | > | > I'm a bit confused at this point, Doug. ?At what point did the OP state | > he has IPMI support or IPMI cards in his system? | | He said he had a Dell PowerEdge 2950 - iirc these all have IPMI. ... and although HW WD doesn't have to be in IPMI, I know for a fact it is on the base config. of a Dell PE2950 and has been since the PE2650. However, on the 2650 I saw false trips. It was one of the reasons I wrote ipmi(4). Eventually, I need to get in sync with jhb to add kernel back-trace support to it. I have some code at work to do it but it needs some work to ensure it works in every case etc. BTW, there is code/patches floating around to control the LCD on these Dell machines via ipmitool and on the r710 control attributes of the LCD. Unfortunately the ipmitool folks haven't pick it up. Doug A. From owner-freebsd-stable@FreeBSD.ORG Fri May 14 14:45:08 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 722CE1065675 for ; Fri, 14 May 2010 14:45:08 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta08.emeryville.ca.mail.comcast.net (qmta08.emeryville.ca.mail.comcast.net [76.96.30.80]) by mx1.freebsd.org (Postfix) with ESMTP id 5832C8FC17 for ; Fri, 14 May 2010 14:45:08 +0000 (UTC) Received: from omta01.emeryville.ca.mail.comcast.net ([76.96.30.11]) by qmta08.emeryville.ca.mail.comcast.net with comcast id HRhl1e0060EPchoA8Sl8VA; Fri, 14 May 2010 14:45:08 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta01.emeryville.ca.mail.comcast.net with comcast id HSl81e00H3S48mS8MSl8bK; Fri, 14 May 2010 14:45:08 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id A9D709B419; Fri, 14 May 2010 07:45:07 -0700 (PDT) Date: Fri, 14 May 2010 07:45:07 -0700 From: Jeremy Chadwick To: Tom Evans Message-ID: <20100514144507.GA1901@icarus.home.lan> References: <4BECD1CB.9060902@mail.ru> <201005141416.o4EEGS6E057680@ambrisko.com> <20100514141514.GA1075@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-stable@freebsd.org Subject: Re: Enabling watchdog X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 May 2010 14:45:08 -0000 On Fri, May 14, 2010 at 03:21:42PM +0100, Tom Evans wrote: > On Fri, May 14, 2010 at 3:15 PM, Jeremy Chadwick > wrote: > > > > I'm a bit confused at this point, Doug.  At what point did the OP state > > he has IPMI support or IPMI cards in his system? > > > > He said he had a Dell PowerEdge 2950 - iirc these all have IPMI. Ah, thanks Tom! I had no idea. It surprised me when the conversation turned from software watchdogs to IPMI hardware watchdogs. :-) -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Fri May 14 14:45:15 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D89F41065691 for ; Fri, 14 May 2010 14:45:15 +0000 (UTC) (envelope-from uqs@spoerlein.net) Received: from acme.spoerlein.net (acme.spoerlein.net [IPv6:2001:470:9a47::1]) by mx1.freebsd.org (Postfix) with ESMTP id 70BF68FC08 for ; Fri, 14 May 2010 14:45:15 +0000 (UTC) Received: from acme.spoerlein.net (localhost.spoerlein.net [IPv6:::1]) by acme.spoerlein.net (8.14.4/8.14.4) with ESMTP id o4EEjEdu043583 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 14 May 2010 16:45:14 +0200 (CEST) (envelope-from uqs@spoerlein.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=spoerlein.net; s=dkim200908; t=1273848314; bh=ENUVzTiy6jeNENo0+AgTDY0AWcxkFGz0hxovw9VXnqU=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:In-Reply-To; b=tS7nPf6I8BJqA9GQuSyUW+PQioh2EKe2/o7upTltTLX+l/SvrSxf5RfEIDTwK1xsw EktFYVVinpx17jmR+3XcoNYBpNH7mGX9Yi5xohNUsy+HPpiLbfq6uRojtJk8LYR22h umjZyNRJOp40fj+sIFgCM3ORHEOUjUvGqfDWWlJg= Received: (from uqs@localhost) by acme.spoerlein.net (8.14.4/8.14.4/Submit) id o4EEjEZg043552; Fri, 14 May 2010 16:45:14 +0200 (CEST) (envelope-from uqs@spoerlein.net) Date: Fri, 14 May 2010 16:45:14 +0200 From: Ulrich =?utf-8?B?U3DDtnJsZWlu?= To: Pete French Message-ID: <20100514144513.GK88504@acme.spoerlein.net> Mail-Followup-To: Pete French , freebsd-stable@freebsd.org References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-stable@freebsd.org Subject: Re: Any chance of someone commiting the patch in bin/131861 ? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 May 2010 14:45:15 -0000 On Fri, 14.05.2010 at 10:17:23 +0100, Pete French wrote: > > > Postfix will re-write this as part of sanitization, so I had to revert > > to creating mbox files by hand. Anyway, could you please test the > > following patch with a wider variety of mails? > > I've been testing your patch for a few weeks now as my main email > client, and I havent encountered any problems - it also does fix > the reply issues I was originally having. Do you want to attach it > to the PR ? After that maybe someone could commit it - I am pretty > certain it doesnt actualy break any exising behaviour. > > cheers, > > -pete. I'll try to get review by some fellow FreeBSD dev that is more familiar with our mail(1) history and then commit the changed eventually. Do you feel strongly about merging the fix to 8 or 7 or both? Regards, Uli From owner-freebsd-stable@FreeBSD.ORG Fri May 14 14:46:29 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DE1F81065679 for ; Fri, 14 May 2010 14:46:29 +0000 (UTC) (envelope-from tevans.uk@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 6BCD48FC20 for ; Fri, 14 May 2010 14:46:29 +0000 (UTC) Received: by fxm17 with SMTP id 17so1746521fxm.13 for ; Fri, 14 May 2010 07:46:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=RAAILuSvspWEQfphl5jSXwMY6TTjzXkV++NzLnEGY9s=; b=M2m8xyYQPdpoC7qtRQ54EjjPF+Variq2hE8BpZAekl7l4FaroS96QquusPi1sDWzKm bTngFoIwnPSNFVfYrsn42AqgsnsjN6eX8cbTYpqzSM87SKtZ/ddkd6BPzMbEh1cDzIut Qr8fPDtANKNGRqxXsgJzgglFegCVx4ibf7udY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=hcAFYsGoazw/HrH7rqN7bVMXIEyvj7jWHbAHy0Kk4IDjoUJrws4Pk38l6IEmS5s10m KnJABsFzha2WMy5Pg5vVEjlszhe5OzWpsK7+SrcE93be33ZnRJH/q93+HWn5/j73wdLK PgmqemcbOE19E0IM3ZRHMLMiWLpPBzGRFa7ug= MIME-Version: 1.0 Received: by 10.239.151.78 with SMTP id q14mr140669hbb.152.1273846902253; Fri, 14 May 2010 07:21:42 -0700 (PDT) Received: by 10.239.142.17 with HTTP; Fri, 14 May 2010 07:21:42 -0700 (PDT) In-Reply-To: <20100514141514.GA1075@icarus.home.lan> References: <4BECD1CB.9060902@mail.ru> <201005141416.o4EEGS6E057680@ambrisko.com> <20100514141514.GA1075@icarus.home.lan> Date: Fri, 14 May 2010 15:21:42 +0100 Message-ID: From: Tom Evans To: Jeremy Chadwick Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable@freebsd.org Subject: Re: Enabling watchdog X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 May 2010 14:46:29 -0000 On Fri, May 14, 2010 at 3:15 PM, Jeremy Chadwick wrote: > > I'm a bit confused at this point, Doug. =C2=A0At what point did the OP st= ate > he has IPMI support or IPMI cards in his system? > He said he had a Dell PowerEdge 2950 - iirc these all have IPMI. Cheers Tom From owner-freebsd-stable@FreeBSD.ORG Fri May 14 15:29:35 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 409ED106566C for ; Fri, 14 May 2010 15:29:35 +0000 (UTC) (envelope-from petefrench@ticketswitch.com) Received: from constantine.ticketswitch.com (constantine.ticketswitch.com [IPv6:2002:57e0:1d4e:1::3]) by mx1.freebsd.org (Postfix) with ESMTP id 09CE28FC08 for ; Fri, 14 May 2010 15:29:35 +0000 (UTC) Received: from dilbert.rattatosk ([10.64.50.6] helo=dilbert.ticketswitch.com) by constantine.ticketswitch.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1OCwpN-00019G-06; Fri, 14 May 2010 16:29:29 +0100 Received: from petefrench by dilbert.ticketswitch.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OCwpM-000Ift-VR; Fri, 14 May 2010 16:29:28 +0100 Date: Fri, 14 May 2010 16:29:28 +0100 Message-Id: To: uqs@spoerlein.net In-Reply-To: <20100514144513.GK88504@acme.spoerlein.net> From: Pete French Cc: freebsd-stable@freebsd.org Subject: Re: Any chance of someone commiting the patch in bin/131861 ? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 May 2010 15:29:35 -0000 > Do you feel strongly about merging the fix to 8 or 7 or both? Not really - it;s such a small change that it would seem a shame not to commit it to earlier releases, but then I used 7 thoughout it;s lifetime with the bug only being a minor annoyance. -pete. From owner-freebsd-stable@FreeBSD.ORG Fri May 14 15:42:45 2010 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1DDE71065672; Fri, 14 May 2010 15:42:45 +0000 (UTC) (envelope-from matthew.fleming@isilon.com) Received: from seaxch09.isilon.com (seaxch09.isilon.com [74.85.160.25]) by mx1.freebsd.org (Postfix) with ESMTP id EF6488FC0A; Fri, 14 May 2010 15:42:44 +0000 (UTC) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 14 May 2010 08:42:44 -0700 Message-ID: <06D5F9F6F655AD4C92E28B662F7F853E021D4D5E@seaxch09.desktop.isilon.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Crash dump problem - sleeping thread owns a non-sleepable lock during crash dump write Thread-Index: AcrzcBgZpUhlL2PhT9OENHWVaOT1DQAChHTp References: <01NN32EOXMYC006UN1@tmk.com> <4BED3912.9080509@FreeBSD.org> <01NN3PQCOFHE006UN1@tmk.com> From: "Matthew Fleming" To: "Terry Kennedy" Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current@freebsd.org, freebsd-stable@FreeBSD.org, John Baldwin Subject: RE: Crash dump problem - sleeping thread owns a non-sleepable lock during crash dump write X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 May 2010 15:42:45 -0000 > As an aside, this is a quad-core in one package CPU (an X3363). On = both > this box and a similar one with an X5470, console messages continue to > print out after "the system has been halted - press any key to reboot" = - > in particular, the shutdown makes a bunch of the "behind the scenes" = man- > agement stuff like the virtual keyboard and monitor appear. Plugging = or > unplugging USB devices will go through the whole deal of detecting and > making their service available. Oops, youre right that other CPUs are running. The stop_cpus() call is only made if kdb is entered. doadump() is = called out of boot() which comes later. At Isilon weve been running = with a patch that does stop_cpus() pretty close to the front of = panic(9). As an design decision it seems reasonable to call stop_cpus() early in = panic(9) simply because most causes for panic means something = unexpected, and the sooner the other CPUs arent running the more likely = it is that they dont do more damage, leaving the system in a more useful = state for dump or {g,d}db analysis. This should be done before dump or = entering kdb. Im ccing -current@ since I would like a small discussion of moving the = stop_cpus() to earlier in panic. If this change is agreeable I can roll = up a patch and test it on CURRENT. Im not sure yet how much of the = other panic-related changes we have made at Isilon would be required. Thanks, matthew From owner-freebsd-stable@FreeBSD.ORG Fri May 14 17:15:55 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3214A1065670 for ; Fri, 14 May 2010 17:15:55 +0000 (UTC) (envelope-from mj@feral.com) Received: from ns1.feral.com (ns1.feral.com [192.67.166.1]) by mx1.freebsd.org (Postfix) with ESMTP id E0B2F8FC0C for ; Fri, 14 May 2010 17:15:54 +0000 (UTC) Received: from [192.168.221.2] (remotevpn [192.168.221.2]) by ns1.feral.com (8.14.3/8.14.3) with ESMTP id o4EH4wfR078128; Fri, 14 May 2010 10:04:58 -0700 (PDT) (envelope-from mj@feral.com) Message-ID: <4BED82BA.4060904@feral.com> Date: Fri, 14 May 2010 10:04:58 -0700 From: Matthew Jacob Organization: Feral Software User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) To: Matthew Fleming References: <01NN32EOXMYC006UN1@tmk.com> <4BED3912.9080509@FreeBSD.org> <01NN3PQCOFHE006UN1@tmk.com> <06D5F9F6F655AD4C92E28B662F7F853E021D4D5E@seaxch09.desktop.isilon.com> In-Reply-To: <06D5F9F6F655AD4C92E28B662F7F853E021D4D5E@seaxch09.desktop.isilon.com> Content-Transfer-Encoding: 7bit X-Greylist: Sender DNS name whitelisted, not delayed by milter-greylist-4.2.3 (ns1.feral.com [192.168.221.1]); Fri, 14 May 2010 10:04:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org, John Baldwin , Terry Kennedy Subject: Re: Crash dump problem - sleeping thread owns a non-sleepable lock during crash dump write X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 May 2010 17:15:55 -0000 Matthew Fleming wrote: As an aside, this is a quad-core in one package CPU (an X3363). On both this box and a similar one with an X5470, console messages continue to print out after "the system has been halted - press any key to reboot" - in particular, the shutdown makes a bunch of the "behind the scenes" man- agement stuff like the virtual keyboard and monitor appear. Plugging or unplugging USB devices will go through the whole deal of detecting and making their service available. Oops, youre right that other CPUs are running. The stop_cpus() call is only made if kdb is entered. doadump() is called out o f boot() which comes later. At Isilon weve been running with a patch that does stop_cpus() pretty close to the front of panic(9). As an design decision it seems reasonable to call stop_cpus() early in panic(9) simply because most causes for panic means something unexpected, and the soone r the other CPUs arent running the more likely it is that they dont do more dam age, leaving the system in a more useful state for dump or {g,d}db analysis. T his should be done before dump or entering kdb. Im ccing -current@ since I would like a small discussion of moving the stop_cpu s() to earlier in panic. If this change is agreeable I can roll up a patch and test it on CURRENT. Im not sure yet how much of the other panic-related chang es we have made at Isilon would be required. Work along this lines has been done at Panasas. We were planning on put it back to the community. There turns out to be lots of edge cases by changing this that we're still sorting thru. From owner-freebsd-stable@FreeBSD.ORG Fri May 14 17:42:35 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CC0971065674 for ; Fri, 14 May 2010 17:42:35 +0000 (UTC) (envelope-from pieter@os3.nl) Received: from mail.thelostparadise.com (router.thelostparadise.com [IPv6:2a02:898:0:30::30:1]) by mx1.freebsd.org (Postfix) with ESMTP id 753E18FC19 for ; Fri, 14 May 2010 17:42:35 +0000 (UTC) Received: by mail.thelostparadise.com (Postfix, from userid 127) id 45E337303B; Fri, 14 May 2010 19:42:34 +0200 (CEST) Received: from localhost by mail.thelostparadise.com (Postfix) with ESMTP id 1DB8B73039 for ; Fri, 14 May 2010 19:42:34 +0200 (CEST) Message-ID: <4BED8B89.6010901@os3.nl> Date: Fri, 14 May 2010 19:42:33 +0200 From: Pieter de Boer MIME-Version: 1.0 To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Read / write timeouts on SATA disks connected to ICH9 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 May 2010 17:42:35 -0000 Hi list, I'm running FreeBSD 8.0-RELEASE-p1 on a Dell R300 which has a ICH9 SATA controller on-board (do not have the RAID controller). The system has 2 disks in a gmirror setup. Every now and then, probably under some load, one of the disks gets read or write timeouts like: May 5 03:01:37 aberdeen kernel: ad4: timeout waiting to issue command May 5 03:01:37 aberdeen kernel: ad4: error issuing WRITE_DMA48 command May 5 03:01:37 aberdeen kernel: GEOM_MIRROR: Request failed (error=5). ad4[WRITE(offset=200404975104, length=16384)] May 5 03:01:37 aberdeen kernel: GEOM_MIRROR: Device gm0: provider ad4 disconnected. or: May 13 14:41:26 aberdeen kernel: ad6: TIMEOUT - READ_DMA48 retrying (1 retry left) LBA=975513887 Sometimes the read/write succeeds after a few retries, but sometimes it does not, so geom_mirror throws the disk out of the mirror. Tonight ad6 was thrown out of the mirror and ad4 then gave actual read errors, resulting in a big mess :( My question: does anyone have experience with FreeBSD on a Dell R300 or can anyone give me some help in trying to fix the timeouts? I was told using AHCI could be better for SATA disks, but apparently (http://permalink.gmane.org/gmane.linux.kernel.pci/8267) the BIOS does not support turning that on, so that does not appear to be an option. Thanks, Pieter From owner-freebsd-stable@FreeBSD.ORG Fri May 14 17:53:52 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CDE691065675 for ; Fri, 14 May 2010 17:53:52 +0000 (UTC) (envelope-from amvandemore@gmail.com) Received: from mail-qy0-f190.google.com (mail-qy0-f190.google.com [209.85.221.190]) by mx1.freebsd.org (Postfix) with ESMTP id 82B2C8FC13 for ; Fri, 14 May 2010 17:53:52 +0000 (UTC) Received: by qyk28 with SMTP id 28so438631qyk.27 for ; Fri, 14 May 2010 10:53:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=gP/O9nHLEt50BDfVt6rX9fjGcCeHsRYBYVhdtFibYc8=; b=GqoRr35TIpFw8jhwfGro2j0FVRZGiBnX4tEzG9DIihDyDeDlsFijmLJ5+Ny97eu/7o L8/LFlU3C3Vd9f761snyrVdyapcCBUXojugm/lIX+DJggQXx85dHboZsh1oG4ZdG654H YNVPQRuDDmQRl1BAR9PMjFzR71F9dMKiTAIho= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=nzfFEsbaVo3FmqnrHePyI9NnCO0RYEGSixi/oPwfLOWKmlccKC6XLpRn2+Mi5YD7CL iFDp8jPV26Yu/Kn4rH7cNew6W4N1Wt2US8aylz9u7pQ/urxmvescHgUBLuDtFZQDHUZM dtITHBnjvHu2hgAYM9Hi6g66EbbQhcre2DPTQ= MIME-Version: 1.0 Received: by 10.224.66.206 with SMTP id o14mr811250qai.264.1273859631300; Fri, 14 May 2010 10:53:51 -0700 (PDT) Received: by 10.229.99.67 with HTTP; Fri, 14 May 2010 10:53:51 -0700 (PDT) In-Reply-To: <4BED8B89.6010901@os3.nl> References: <4BED8B89.6010901@os3.nl> Date: Fri, 14 May 2010 12:53:51 -0500 Message-ID: From: Adam Vande More To: Pieter de Boer Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable@freebsd.org Subject: Re: Read / write timeouts on SATA disks connected to ICH9 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 May 2010 17:53:53 -0000 On Fri, May 14, 2010 at 12:42 PM, Pieter de Boer wrote: > I'm running FreeBSD 8.0-RELEASE-p1 on a Dell R300 which has a ICH9 SATA > controller on-board (do not have the RAID controller). > > The system has 2 disks in a gmirror setup. Every now and then, probably > under some load, one of the disks gets read or write timeouts like: > May 5 03:01:37 aberdeen kernel: ad4: timeout waiting to issue command > May 5 03:01:37 aberdeen kernel: ad4: error issuing WRITE_DMA48 command > May 5 03:01:37 aberdeen kernel: GEOM_MIRROR: Request failed (error=5). > ad4[WRITE(offset=200404975104, length=16384)] > May 5 03:01:37 aberdeen kernel: GEOM_MIRROR: Device gm0: provider ad4 > disconnected. > Have you tried replacing/checking the cables? Does it always happen to ad4? Your drive could be dying, try swapping it out and see if the errors persist. -- Adam Vande More From owner-freebsd-stable@FreeBSD.ORG Fri May 14 18:05:18 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D7A44106566C for ; Fri, 14 May 2010 18:05:18 +0000 (UTC) (envelope-from pieter@os3.nl) Received: from mail.thelostparadise.com (router.thelostparadise.com [IPv6:2a02:898:0:30::30:1]) by mx1.freebsd.org (Postfix) with ESMTP id A26488FC17 for ; Fri, 14 May 2010 18:05:18 +0000 (UTC) Received: by mail.thelostparadise.com (Postfix, from userid 127) id B43CC7303B; Fri, 14 May 2010 20:05:17 +0200 (CEST) Received: from localhost by mail.thelostparadise.com (Postfix) with ESMTP id 8926673039; Fri, 14 May 2010 20:05:17 +0200 (CEST) Message-ID: <4BED90DC.6060804@os3.nl> Date: Fri, 14 May 2010 20:05:16 +0200 From: Pieter de Boer MIME-Version: 1.0 To: Adam Vande More References: <4BED8B89.6010901@os3.nl> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: Read / write timeouts on SATA disks connected to ICH9 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 May 2010 18:05:18 -0000 Adam Vande More wrote: >> May 5 03:01:37 aberdeen kernel: ad4: timeout waiting to issue command >> May 5 03:01:37 aberdeen kernel: ad4: error issuing WRITE_DMA48 command >> May 5 03:01:37 aberdeen kernel: GEOM_MIRROR: Request failed (error=5). >> ad4[WRITE(offset=200404975104, length=16384)] >> May 5 03:01:37 aberdeen kernel: GEOM_MIRROR: Device gm0: provider ad4 >> disconnected. > Have you tried replacing/checking the cables? Does it always happen to ad4? > Your drive could be dying, try swapping it out and see if the errors > persist. > It happens to both drives and to both drives I replaced a month ago with these. Didn't replace the cables back then, but they were correctly attached and are now. Also it would be odd that both cables are broken at the same time. -- Pieter From owner-freebsd-stable@FreeBSD.ORG Fri May 14 18:08:27 2010 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5426A1065670; Fri, 14 May 2010 18:08:27 +0000 (UTC) (envelope-from TERRY@tmk.com) Received: from server.tmk.com (server.tmk.com [204.141.35.63]) by mx1.freebsd.org (Postfix) with ESMTP id 2AFB58FC15; Fri, 14 May 2010 18:08:26 +0000 (UTC) Received: from tmk.com by tmk.com (PMDF V6.4 #37010) id <01NN3XLDKJ28006UN1@tmk.com>; Fri, 14 May 2010 14:08:24 -0400 (EDT) Date: Fri, 14 May 2010 14:02:47 -0400 (EDT) From: Terry Kennedy In-reply-to: "Your message dated Fri, 14 May 2010 08:42:44 -0700" <06D5F9F6F655AD4C92E28B662F7F853E021D4D5E@seaxch09.desktop.isilon.com> To: Matthew Fleming Message-id: <01NN3XTJDNMS006UN1@tmk.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=iso-8859-1 References: <01NN32EOXMYC006UN1@tmk.com> <4BED3912.9080509@FreeBSD.org> <01NN3PQCOFHE006UN1@tmk.com> Cc: freebsd-current@FreeBSD.org, freebsd-stable@FreeBSD.org, John Baldwin Subject: RE: Crash dump problem - sleeping thread owns a non-sleepable lock during crash dump write X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 May 2010 18:08:27 -0000 > Oops, youre right that other CPUs are running. > > The stop_cpus() call is only made if kdb is entered. doadump() is called > out of boot() which comes later. At Isilon weve been running with a patch > that does stop_cpus() pretty close to the front of panic(9). This is interesting, and changing the behavior will probably allow the crash dump for the original problem (repeatable crash in the bce driver) to be analyzed. At the moment, I'm more interested in dealing with the original problem of the crash in bce. Right now, I'm running this vendor's product under Linux compatibility mode. The vendor is hard at work building a native FreeBSD version of their product. One of two things is going to happen here: 1) the crash doesn't happen in native mode due to different code paths being taken, and I lose the ability to reproduce the crash when the box goes into production, or 2) the crash continues to happen and the ven- dor gets the impression FreeBSD is unstable and not worth supporting. I'd like to avoid that. So, any ideas on how to troubleshoot the panic in bce? Thanks, Terry Kennedy http://www.tmk.com terry@tmk.com New York, NY USA From owner-freebsd-stable@FreeBSD.ORG Fri May 14 19:53:51 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1D9D9106566C for ; Fri, 14 May 2010 19:53:51 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [76.96.62.40]) by mx1.freebsd.org (Postfix) with ESMTP id C19CC8FC0A for ; Fri, 14 May 2010 19:53:50 +0000 (UTC) Received: from omta18.westchester.pa.mail.comcast.net ([76.96.62.90]) by qmta04.westchester.pa.mail.comcast.net with comcast id HUHx1e0061wpRvQ54Xtqzt; Fri, 14 May 2010 19:53:50 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta18.westchester.pa.mail.comcast.net with comcast id HXtp1e0033S48mS3eXtpkS; Fri, 14 May 2010 19:53:50 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id D55889B419; Fri, 14 May 2010 12:53:46 -0700 (PDT) Date: Fri, 14 May 2010 12:53:46 -0700 From: Jeremy Chadwick To: Pieter de Boer Message-ID: <20100514195346.GA8977@icarus.home.lan> References: <4BED8B89.6010901@os3.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4BED8B89.6010901@os3.nl> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-stable@freebsd.org Subject: Re: Read / write timeouts on SATA disks connected to ICH9 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 May 2010 19:53:51 -0000 On Fri, May 14, 2010 at 07:42:33PM +0200, Pieter de Boer wrote: > Hi list, > > I'm running FreeBSD 8.0-RELEASE-p1 on a Dell R300 which has a ICH9 > SATA controller on-board (do not have the RAID controller). > > The system has 2 disks in a gmirror setup. Every now and then, > probably under some load, one of the disks gets read or write > timeouts like: > May 5 03:01:37 aberdeen kernel: ad4: timeout waiting to issue command > May 5 03:01:37 aberdeen kernel: ad4: error issuing WRITE_DMA48 command > May 5 03:01:37 aberdeen kernel: GEOM_MIRROR: Request failed > (error=5). ad4[WRITE(offset=200404975104, length=16384)] > May 5 03:01:37 aberdeen kernel: GEOM_MIRROR: Device gm0: provider > ad4 disconnected. > > or: > > May 13 14:41:26 aberdeen kernel: ad6: TIMEOUT - READ_DMA48 retrying > (1 retry left) LBA=975513887 > > Sometimes the read/write succeeds after a few retries, but sometimes > it does not, so geom_mirror throws the disk out of the mirror. > > Tonight ad6 was thrown out of the mirror and ad4 then gave actual > read errors, resulting in a big mess :( > > My question: does anyone have experience with FreeBSD on a Dell R300 > or can anyone give me some help in trying to fix the timeouts? Could you please do the following: - Provide output from "vmstat -i" - Provide output from "dmesg | grep -i ata" - Install ports/sysutils/smartmontools (5.40 or later) and provide full output from commands "smartctl -a /dev/ad4" and "smartctl -a /dev/ad6" -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Fri May 14 21:09:32 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 472A8106564A for ; Fri, 14 May 2010 21:09:32 +0000 (UTC) (envelope-from pieter@os3.nl) Received: from mail.thelostparadise.com (router.thelostparadise.com [IPv6:2a02:898:0:30::30:1]) by mx1.freebsd.org (Postfix) with ESMTP id D4DAB8FC16 for ; Fri, 14 May 2010 21:09:30 +0000 (UTC) Received: by mail.thelostparadise.com (Postfix, from userid 127) id B4B417303B; Fri, 14 May 2010 23:09:29 +0200 (CEST) Received: from localhost by mail.thelostparadise.com (Postfix) with ESMTP id 353D473039; Fri, 14 May 2010 23:09:29 +0200 (CEST) Message-ID: <4BEDBC08.2040002@os3.nl> Date: Fri, 14 May 2010 23:09:28 +0200 From: Pieter de Boer MIME-Version: 1.0 To: Jeremy Chadwick References: <4BED8B89.6010901@os3.nl> <20100514195346.GA8977@icarus.home.lan> In-Reply-To: <20100514195346.GA8977@icarus.home.lan> Content-Type: multipart/mixed; boundary="------------090406050902030903010601" Cc: freebsd-stable@freebsd.org Subject: Re: Read / write timeouts on SATA disks connected to ICH9 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 May 2010 21:09:32 -0000 This is a multi-part message in MIME format. --------------090406050902030903010601 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit >> My question: does anyone have experience with FreeBSD on a Dell R300 >> or can anyone give me some help in trying to fix the timeouts? > > Could you please do the following: > > - Provide output from "vmstat -i" > > - Provide output from "dmesg | grep -i ata" > > - Install ports/sysutils/smartmontools (5.40 or later) and provide > full output from commands "smartctl -a /dev/ad4" and "smartctl -a > /dev/ad6" The ad4 SMART output is showing errors, as this disk is indeed broken now. It wasn't before and it is a replacement of another disk that wasn't broken either. Grmbl, I now see reallocated sectors on ad6 as well, in the smartctl output. So both disks look wonky; although afaik that's not the main issue here. I've attached the smartctl output as separate files. smartmontools 5.40 does not appear to exist; I used 5.39.1, the latest port version. Attached also the vmstat -i and dmesg output. -- Pieter --------------090406050902030903010601 Content-Type: text/plain; name="smartctl-ad4.txt" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="smartctl-ad4.txt" c21hcnRjdGwgNS4zOS4xIDIwMTAtMDEtMjggcjMwNTQgW0ZyZWVCU0QgOC4wLVJFTEVBU0Ut cDEgaTM4Nl0gKGxvY2FsIGJ1aWxkKQpDb3B5cmlnaHQgKEMpIDIwMDItMTAgYnkgQnJ1Y2Ug QWxsZW4sIGh0dHA6Ly9zbWFydG1vbnRvb2xzLnNvdXJjZWZvcmdlLm5ldAoKPT09IFNUQVJU IE9GIElORk9STUFUSU9OIFNFQ1RJT04gPT09Ck1vZGVsIEZhbWlseTogICAgIFdlc3Rlcm4g RGlnaXRhbCBDYXZpYXIgQmxhY2sgZmFtaWx5CkRldmljZSBNb2RlbDogICAgIFdEQyBXRDUw MDFBQUxTLTAwTDNCMgpTZXJpYWwgTnVtYmVyOiAgICBXRC1XQ0FTWUE5NjQwNjMKRmlybXdh cmUgVmVyc2lvbjogMDEuMDNCMDEKVXNlciBDYXBhY2l0eTogICAgNTAwLDEwNyw4NjIsMDE2 IGJ5dGVzCkRldmljZSBpczogICAgICAgIEluIHNtYXJ0Y3RsIGRhdGFiYXNlIFtmb3IgZGV0 YWlscyB1c2U6IC1QIHNob3ddCkFUQSBWZXJzaW9uIGlzOiAgIDgKQVRBIFN0YW5kYXJkIGlz OiAgRXhhY3QgQVRBIHNwZWNpZmljYXRpb24gZHJhZnQgdmVyc2lvbiBub3QgaW5kaWNhdGVk CkxvY2FsIFRpbWUgaXM6ICAgIEZyaSBNYXkgMTQgMjM6MDE6NDkgMjAxMCBDRVNUClNNQVJU IHN1cHBvcnQgaXM6IEF2YWlsYWJsZSAtIGRldmljZSBoYXMgU01BUlQgY2FwYWJpbGl0eS4K U01BUlQgc3VwcG9ydCBpczogRW5hYmxlZAoKPT09IFNUQVJUIE9GIFJFQUQgU01BUlQgREFU QSBTRUNUSU9OID09PQpTTUFSVCBvdmVyYWxsLWhlYWx0aCBzZWxmLWFzc2Vzc21lbnQgdGVz dCByZXN1bHQ6IFBBU1NFRAoKR2VuZXJhbCBTTUFSVCBWYWx1ZXM6Ck9mZmxpbmUgZGF0YSBj b2xsZWN0aW9uIHN0YXR1czogICgweDg1KQlPZmZsaW5lIGRhdGEgY29sbGVjdGlvbiBhY3Rp dml0eQoJCQkJCXdhcyBhYm9ydGVkIGJ5IGFuIGludGVycnVwdGluZyBjb21tYW5kIGZyb20g aG9zdC4KCQkJCQlBdXRvIE9mZmxpbmUgRGF0YSBDb2xsZWN0aW9uOiBFbmFibGVkLgpTZWxm LXRlc3QgZXhlY3V0aW9uIHN0YXR1czogICAgICAoIDI0MSkJU2VsZi10ZXN0IHJvdXRpbmUg aW4gcHJvZ3Jlc3MuLi4KCQkJCQkxMCUgb2YgdGVzdCByZW1haW5pbmcuClRvdGFsIHRpbWUg dG8gY29tcGxldGUgT2ZmbGluZSAKZGF0YSBjb2xsZWN0aW9uOiAJCSAoMTExNjApIHNlY29u ZHMuCk9mZmxpbmUgZGF0YSBjb2xsZWN0aW9uCmNhcGFiaWxpdGllczogCQkJICgweDdiKSBT TUFSVCBleGVjdXRlIE9mZmxpbmUgaW1tZWRpYXRlLgoJCQkJCUF1dG8gT2ZmbGluZSBkYXRh IGNvbGxlY3Rpb24gb24vb2ZmIHN1cHBvcnQuCgkJCQkJU3VzcGVuZCBPZmZsaW5lIGNvbGxl Y3Rpb24gdXBvbiBuZXcKCQkJCQljb21tYW5kLgoJCQkJCU9mZmxpbmUgc3VyZmFjZSBzY2Fu IHN1cHBvcnRlZC4KCQkJCQlTZWxmLXRlc3Qgc3VwcG9ydGVkLgoJCQkJCUNvbnZleWFuY2Ug U2VsZi10ZXN0IHN1cHBvcnRlZC4KCQkJCQlTZWxlY3RpdmUgU2VsZi10ZXN0IHN1cHBvcnRl ZC4KU01BUlQgY2FwYWJpbGl0aWVzOiAgICAgICAgICAgICgweDAwMDMpCVNhdmVzIFNNQVJU IGRhdGEgYmVmb3JlIGVudGVyaW5nCgkJCQkJcG93ZXItc2F2aW5nIG1vZGUuCgkJCQkJU3Vw cG9ydHMgU01BUlQgYXV0byBzYXZlIHRpbWVyLgpFcnJvciBsb2dnaW5nIGNhcGFiaWxpdHk6 ICAgICAgICAoMHgwMSkJRXJyb3IgbG9nZ2luZyBzdXBwb3J0ZWQuCgkJCQkJR2VuZXJhbCBQ dXJwb3NlIExvZ2dpbmcgc3VwcG9ydGVkLgpTaG9ydCBzZWxmLXRlc3Qgcm91dGluZSAKcmVj b21tZW5kZWQgcG9sbGluZyB0aW1lOiAJICggICAyKSBtaW51dGVzLgpFeHRlbmRlZCBzZWxm LXRlc3Qgcm91dGluZQpyZWNvbW1lbmRlZCBwb2xsaW5nIHRpbWU6IAkgKCAxMzEpIG1pbnV0 ZXMuCkNvbnZleWFuY2Ugc2VsZi10ZXN0IHJvdXRpbmUKcmVjb21tZW5kZWQgcG9sbGluZyB0 aW1lOiAJICggICA1KSBtaW51dGVzLgpTQ1QgY2FwYWJpbGl0aWVzOiAJICAgICAgICgweDMw MzcpCVNDVCBTdGF0dXMgc3VwcG9ydGVkLgoJCQkJCVNDVCBGZWF0dXJlIENvbnRyb2wgc3Vw cG9ydGVkLgoJCQkJCVNDVCBEYXRhIFRhYmxlIHN1cHBvcnRlZC4KClNNQVJUIEF0dHJpYnV0 ZXMgRGF0YSBTdHJ1Y3R1cmUgcmV2aXNpb24gbnVtYmVyOiAxNgpWZW5kb3IgU3BlY2lmaWMg U01BUlQgQXR0cmlidXRlcyB3aXRoIFRocmVzaG9sZHM6CklEIyBBVFRSSUJVVEVfTkFNRSAg ICAgICAgICBGTEFHICAgICBWQUxVRSBXT1JTVCBUSFJFU0ggVFlQRSAgICAgIFVQREFURUQg IFdIRU5fRkFJTEVEIFJBV19WQUxVRQogIDEgUmF3X1JlYWRfRXJyb3JfUmF0ZSAgICAgMHgw MDJmICAgMjAwICAgMjAwICAgMDUxICAgIFByZS1mYWlsICBBbHdheXMgICAgICAgLSAgICAg ICA3OAogIDMgU3Bpbl9VcF9UaW1lICAgICAgICAgICAgMHgwMDI3ICAgMTg0ICAgMTY4ICAg MDIxICAgIFByZS1mYWlsICBBbHdheXMgICAgICAgLSAgICAgICAzNzkxCiAgNCBTdGFydF9T dG9wX0NvdW50ICAgICAgICAweDAwMzIgICAxMDAgICAxMDAgICAwMDAgICAgT2xkX2FnZSAg IEFsd2F5cyAgICAgICAtICAgICAgIDk5MgogIDUgUmVhbGxvY2F0ZWRfU2VjdG9yX0N0ICAg MHgwMDMzICAgMjAwICAgMjAwICAgMTQwICAgIFByZS1mYWlsICBBbHdheXMgICAgICAgLSAg ICAgICAwCiAgNyBTZWVrX0Vycm9yX1JhdGUgICAgICAgICAweDAwMmUgICAyMDAgICAyMDAg ICAwMDAgICAgT2xkX2FnZSAgIEFsd2F5cyAgICAgICAtICAgICAgIDAKICA5IFBvd2VyX09u X0hvdXJzICAgICAgICAgIDB4MDAzMiAgIDA5OSAgIDA5OSAgIDAwMCAgICBPbGRfYWdlICAg QWx3YXlzICAgICAgIC0gICAgICAgODI3CiAxMCBTcGluX1JldHJ5X0NvdW50ICAgICAgICAw eDAwMzIgICAxMDAgICAxMDAgICAwMDAgICAgT2xkX2FnZSAgIEFsd2F5cyAgICAgICAtICAg ICAgIDAKIDExIENhbGlicmF0aW9uX1JldHJ5X0NvdW50IDB4MDAzMiAgIDEwMCAgIDEwMCAg IDAwMCAgICBPbGRfYWdlICAgQWx3YXlzICAgICAgIC0gICAgICAgMAogMTIgUG93ZXJfQ3lj bGVfQ291bnQgICAgICAgMHgwMDMyICAgMTAwICAgMTAwICAgMDAwICAgIE9sZF9hZ2UgICBB bHdheXMgICAgICAgLSAgICAgICA5OTAKMTkyIFBvd2VyLU9mZl9SZXRyYWN0X0NvdW50IDB4 MDAzMiAgIDE5OSAgIDE5OSAgIDAwMCAgICBPbGRfYWdlICAgQWx3YXlzICAgICAgIC0gICAg ICAgOTg5CjE5MyBMb2FkX0N5Y2xlX0NvdW50ICAgICAgICAweDAwMzIgICAyMDAgICAyMDAg ICAwMDAgICAgT2xkX2FnZSAgIEFsd2F5cyAgICAgICAtICAgICAgIDk5MgoxOTQgVGVtcGVy YXR1cmVfQ2Vsc2l1cyAgICAgMHgwMDIyICAgMTI1ICAgMTA5ICAgMDAwICAgIE9sZF9hZ2Ug ICBBbHdheXMgICAgICAgLSAgICAgICAyMgoxOTYgUmVhbGxvY2F0ZWRfRXZlbnRfQ291bnQg MHgwMDMyICAgMjAwICAgMjAwICAgMDAwICAgIE9sZF9hZ2UgICBBbHdheXMgICAgICAgLSAg ICAgICAwCjE5NyBDdXJyZW50X1BlbmRpbmdfU2VjdG9yICAweDAwMzIgICAyMDAgICAxOTgg ICAwMDAgICAgT2xkX2FnZSAgIEFsd2F5cyAgICAgICAtICAgICAgIDAKMTk4IE9mZmxpbmVf VW5jb3JyZWN0YWJsZSAgIDB4MDAzMCAgIDIwMCAgIDIwMCAgIDAwMCAgICBPbGRfYWdlICAg T2ZmbGluZSAgICAgIC0gICAgICAgMQoxOTkgVURNQV9DUkNfRXJyb3JfQ291bnQgICAgMHgw MDMyICAgMjAwICAgMjAwICAgMDAwICAgIE9sZF9hZ2UgICBBbHdheXMgICAgICAgLSAgICAg ICAwCjIwMCBNdWx0aV9ab25lX0Vycm9yX1JhdGUgICAweDAwMDggICAyMDAgICAyMDAgICAw MDAgICAgT2xkX2FnZSAgIE9mZmxpbmUgICAgICAtICAgICAgIDAKClNNQVJUIEVycm9yIExv ZyBWZXJzaW9uOiAxCldhcm5pbmc6IEFUQSBlcnJvciBjb3VudCA0OCBpbmNvbnNpc3RlbnQg d2l0aCBlcnJvciBsb2cgcG9pbnRlciAxCgpBVEEgRXJyb3IgQ291bnQ6IDQ4IChkZXZpY2Ug bG9nIGNvbnRhaW5zIG9ubHkgdGhlIG1vc3QgcmVjZW50IGZpdmUgZXJyb3JzKQoJQ1IgPSBD b21tYW5kIFJlZ2lzdGVyIFtIRVhdCglGUiA9IEZlYXR1cmVzIFJlZ2lzdGVyIFtIRVhdCglT QyA9IFNlY3RvciBDb3VudCBSZWdpc3RlciBbSEVYXQoJU04gPSBTZWN0b3IgTnVtYmVyIFJl Z2lzdGVyIFtIRVhdCglDTCA9IEN5bGluZGVyIExvdyBSZWdpc3RlciBbSEVYXQoJQ0ggPSBD eWxpbmRlciBIaWdoIFJlZ2lzdGVyIFtIRVhdCglESCA9IERldmljZS9IZWFkIFJlZ2lzdGVy IFtIRVhdCglEQyA9IERldmljZSBDb21tYW5kIFJlZ2lzdGVyIFtIRVhdCglFUiA9IEVycm9y IHJlZ2lzdGVyIFtIRVhdCglTVCA9IFN0YXR1cyByZWdpc3RlciBbSEVYXQpQb3dlcmVkX1Vw X1RpbWUgaXMgbWVhc3VyZWQgZnJvbSBwb3dlciBvbiwgYW5kIHByaW50ZWQgYXMKRERkK2ho Om1tOlNTLnNzcyB3aGVyZSBERD1kYXlzLCBoaD1ob3VycywgbW09bWludXRlcywKU1M9c2Vj LCBhbmQgc3NzPW1pbGxpc2VjLiBJdCAid3JhcHMiIGFmdGVyIDQ5LjcxMCBkYXlzLgoKRXJy b3IgNDggb2NjdXJyZWQgYXQgZGlzayBwb3dlci1vbiBsaWZldGltZTogODE3IGhvdXJzICgz NCBkYXlzICsgMSBob3VycykKICBXaGVuIHRoZSBjb21tYW5kIHRoYXQgY2F1c2VkIHRoZSBl cnJvciBvY2N1cnJlZCwgdGhlIGRldmljZSB3YXMgYWN0aXZlIG9yIGlkbGUuCgogIEFmdGVy IGNvbW1hbmQgY29tcGxldGlvbiBvY2N1cnJlZCwgcmVnaXN0ZXJzIHdlcmU6CiAgRVIgU1Qg U0MgU04gQ0wgQ0ggREgKICAtLSAtLSAtLSAtLSAtLSAtLSAtLQogIDQwIDUxIDAwIDlkIDg0 IDBlIGUwICBFcnJvcjogVU5DIGF0IExCQSA9IDB4MDAwZTg0OWQgPSA5NTE0NTMKCiAgQ29t bWFuZHMgbGVhZGluZyB0byB0aGUgY29tbWFuZCB0aGF0IGNhdXNlZCB0aGUgZXJyb3Igd2Vy ZToKICBDUiBGUiBTQyBTTiBDTCBDSCBESCBEQyAgIFBvd2VyZWRfVXBfVGltZSAgQ29tbWFu ZC9GZWF0dXJlX05hbWUKICAtLSAtLSAtLSAtLSAtLSAtLSAtLSAtLSAgLS0tLS0tLS0tLS0t LS0tLSAgLS0tLS0tLS0tLS0tLS0tLS0tLS0KICBjOCAwMCAyMCA4MCA4NCAwZSAwMCAwMCAg ICAgIDAwOjQ1OjE4LjIwNCAgUkVBRCBETUEKICBjOCAwMCAyMCA2MCA4NCAwZSAwMCAwMCAg ICAgIDAwOjQ1OjE4LjIwNCAgUkVBRCBETUEKICBjOCAwMCAyMCA0MCA4NCAwZSAwMCAwMCAg ICAgIDAwOjQ1OjE4LjIwNCAgUkVBRCBETUEKICBjOCAwMCAyMCAyMCA4NCAwZSAwMCAwMCAg ICAgIDAwOjQ1OjE4LjIwNCAgUkVBRCBETUEKICBjOCAwMCAyMCAwMCA4NCAwZSAwMCAwMCAg ICAgIDAwOjQ1OjE4LjIwNCAgUkVBRCBETUEKCkVycm9yIDQ3IG9jY3VycmVkIGF0IGRpc2sg cG93ZXItb24gbGlmZXRpbWU6IDgxNyBob3VycyAoMzQgZGF5cyArIDEgaG91cnMpCiAgV2hl biB0aGUgY29tbWFuZCB0aGF0IGNhdXNlZCB0aGUgZXJyb3Igb2NjdXJyZWQsIHRoZSBkZXZp Y2Ugd2FzIGFjdGl2ZSBvciBpZGxlLgoKICBBZnRlciBjb21tYW5kIGNvbXBsZXRpb24gb2Nj dXJyZWQsIHJlZ2lzdGVycyB3ZXJlOgogIEVSIFNUIFNDIFNOIENMIENIIERICiAgLS0gLS0g LS0gLS0gLS0gLS0gLS0KICA0MCA1MSAwMCAwYyA5ZCAwZSBlMCAgRXJyb3I6IFVOQyBhdCBM QkEgPSAweDAwMGU5ZDBjID0gOTU3NzA4CgogIENvbW1hbmRzIGxlYWRpbmcgdG8gdGhlIGNv bW1hbmQgdGhhdCBjYXVzZWQgdGhlIGVycm9yIHdlcmU6CiAgQ1IgRlIgU0MgU04gQ0wgQ0gg REggREMgICBQb3dlcmVkX1VwX1RpbWUgIENvbW1hbmQvRmVhdHVyZV9OYW1lCiAgLS0gLS0g LS0gLS0gLS0gLS0gLS0gLS0gIC0tLS0tLS0tLS0tLS0tLS0gIC0tLS0tLS0tLS0tLS0tLS0t LS0tCiAgYzggMDAgODAgMDAgOWQgMGUgMDAgMDAgICAgICAwMDowMzowOC42MTQgIFJFQUQg RE1BCiAgYzggMDAgODAgODAgOWMgMGUgMDAgMDAgICAgICAwMDowMzowOC42MTEgIFJFQUQg RE1BCiAgYzggMDAgODAgMDAgOWMgMGUgMDAgMDAgICAgICAwMDowMzowOC42MTAgIFJFQUQg RE1BCiAgYzggMDAgODAgODAgOWIgMGUgMDAgMDAgICAgICAwMDowMzowOC42MDYgIFJFQUQg RE1BCiAgYzggMDAgODAgMDAgOWIgMGUgMDAgMDAgICAgICAwMDowMzowOC42MDUgIFJFQUQg RE1BCgpFcnJvciA0NiBvY2N1cnJlZCBhdCBkaXNrIHBvd2VyLW9uIGxpZmV0aW1lOiA4MTcg aG91cnMgKDM0IGRheXMgKyAxIGhvdXJzKQogIFdoZW4gdGhlIGNvbW1hbmQgdGhhdCBjYXVz ZWQgdGhlIGVycm9yIG9jY3VycmVkLCB0aGUgZGV2aWNlIHdhcyBhY3RpdmUgb3IgaWRsZS4K CiAgQWZ0ZXIgY29tbWFuZCBjb21wbGV0aW9uIG9jY3VycmVkLCByZWdpc3RlcnMgd2VyZToK ICBFUiBTVCBTQyBTTiBDTCBDSCBESAogIC0tIC0tIC0tIC0tIC0tIC0tIC0tCiAgNDAgNTEg MDAgOWQgODQgMGUgZTAgIEVycm9yOiBVTkMgYXQgTEJBID0gMHgwMDBlODQ5ZCA9IDk1MTQ1 MwoKICBDb21tYW5kcyBsZWFkaW5nIHRvIHRoZSBjb21tYW5kIHRoYXQgY2F1c2VkIHRoZSBl cnJvciB3ZXJlOgogIENSIEZSIFNDIFNOIENMIENIIERIIERDICAgUG93ZXJlZF9VcF9UaW1l ICBDb21tYW5kL0ZlYXR1cmVfTmFtZQogIC0tIC0tIC0tIC0tIC0tIC0tIC0tIC0tICAtLS0t LS0tLS0tLS0tLS0tICAtLS0tLS0tLS0tLS0tLS0tLS0tLQogIGM4IDAwIDgwIDgwIDg0IDBl IDAwIDAwICAgICAgMDA6MDM6MDUuMTc5ICBSRUFEIERNQQogIGM4IDAwIDgwIDAwIDg0IDBl IDAwIDAwICAgICAgMDA6MDM6MDUuMTc4ICBSRUFEIERNQQogIGM4IDAwIDgwIDgwIDgzIDBl IDAwIDAwICAgICAgMDA6MDM6MDUuMTc3ICBSRUFEIERNQQogIGM4IDAwIDgwIDAwIDgzIDBl IDAwIDAwICAgICAgMDA6MDM6MDUuMTc3ICBSRUFEIERNQQogIGM4IDAwIDgwIDgwIDgyIDBl IDAwIDAwICAgICAgMDA6MDM6MDUuMTc2ICBSRUFEIERNQQoKRXJyb3IgNDUgb2NjdXJyZWQg YXQgZGlzayBwb3dlci1vbiBsaWZldGltZTogODE3IGhvdXJzICgzNCBkYXlzICsgMSBob3Vy cykKICBXaGVuIHRoZSBjb21tYW5kIHRoYXQgY2F1c2VkIHRoZSBlcnJvciBvY2N1cnJlZCwg dGhlIGRldmljZSB3YXMgYWN0aXZlIG9yIGlkbGUuCgogIEFmdGVyIGNvbW1hbmQgY29tcGxl dGlvbiBvY2N1cnJlZCwgcmVnaXN0ZXJzIHdlcmU6CiAgRVIgU1QgU0MgU04gQ0wgQ0ggREgK ICAtLSAtLSAtLSAtLSAtLSAtLSAtLQogIDQwIDUxIDA4IDIwIDQ3IDZjIGUwICBFcnJvcjog VU5DIGF0IExCQSA9IDB4MDA2YzQ3MjAgPSA3MDk2MDk2CgogIENvbW1hbmRzIGxlYWRpbmcg dG8gdGhlIGNvbW1hbmQgdGhhdCBjYXVzZWQgdGhlIGVycm9yIHdlcmU6CiAgQ1IgRlIgU0Mg U04gQ0wgQ0ggREggREMgICBQb3dlcmVkX1VwX1RpbWUgIENvbW1hbmQvRmVhdHVyZV9OYW1l CiAgLS0gLS0gLS0gLS0gLS0gLS0gLS0gLS0gIC0tLS0tLS0tLS0tLS0tLS0gIC0tLS0tLS0t LS0tLS0tLS0tLS0tCiAgYzQgZmYgMDggMWYgNDcgNmMgMDAgMDAgICAgICAwMDowMTowOS40 NjcgIFJFQUQgTVVMVElQTEUKICBjNCBmZiAwOCAxNyA0NyA2YyAwMCAwMCAgICAgIDAwOjAx OjA5LjQ2NSAgUkVBRCBNVUxUSVBMRQogIGM0IGZmIDA4IDBmIDQ3IDZjIDAwIDAwICAgICAg MDA6MDE6MDkuNDYzICBSRUFEIE1VTFRJUExFCiAgYzQgZmYgMDggMDcgNDcgNmMgMDAgMDAg ICAgICAwMDowMTowOS40NjEgIFJFQUQgTVVMVElQTEUKICBjNCBmZiAwOCBmZiA0NiA2YyAw MCAwMCAgICAgIDAwOjAxOjA5LjQ1OSAgUkVBRCBNVUxUSVBMRQoKRXJyb3IgNDQgb2NjdXJy ZWQgYXQgZGlzayBwb3dlci1vbiBsaWZldGltZTogODE3IGhvdXJzICgzNCBkYXlzICsgMSBo b3VycykKICBXaGVuIHRoZSBjb21tYW5kIHRoYXQgY2F1c2VkIHRoZSBlcnJvciBvY2N1cnJl ZCwgdGhlIGRldmljZSB3YXMgYWN0aXZlIG9yIGlkbGUuCgogIEFmdGVyIGNvbW1hbmQgY29t cGxldGlvbiBvY2N1cnJlZCwgcmVnaXN0ZXJzIHdlcmU6CiAgRVIgU1QgU0MgU04gQ0wgQ0gg REgKICAtLSAtLSAtLSAtLSAtLSAtLSAtLQogIDQwIDUxIDA4IDIxIDhlIDY3IGUwICBFcnJv cjogVU5DIGF0IExCQSA9IDB4MDA2NzhlMjEgPSA2Nzg2NTkzCgogIENvbW1hbmRzIGxlYWRp bmcgdG8gdGhlIGNvbW1hbmQgdGhhdCBjYXVzZWQgdGhlIGVycm9yIHdlcmU6CiAgQ1IgRlIg U0MgU04gQ0wgQ0ggREggREMgICBQb3dlcmVkX1VwX1RpbWUgIENvbW1hbmQvRmVhdHVyZV9O YW1lCiAgLS0gLS0gLS0gLS0gLS0gLS0gLS0gLS0gIC0tLS0tLS0tLS0tLS0tLS0gIC0tLS0t LS0tLS0tLS0tLS0tLS0tCiAgYzQgZmYgMDggMWYgOGUgNjcgMDAgMDAgICAgICAwMDowMTow MC43NDggIFJFQUQgTVVMVElQTEUKICBjNCBmZiAwOCA2NyA1ZiA2NyAwMCAwMCAgICAgIDAw OjAxOjAwLjc0NiAgUkVBRCBNVUxUSVBMRQogIGM0IGZmIDA0IDlmIDVlIDY3IDAwIDAwICAg ICAgMDA6MDE6MDAuNzQzICBSRUFEIE1VTFRJUExFCiAgYzQgZmYgMDggNWYgNWYgNjcgMDAg MDAgICAgICAwMDowMTowMC43MjggIFJFQUQgTVVMVElQTEUKICBjNCBmZiAwNCAzZiAyZiAw MCAwMCAwMCAgICAgIDAwOjAxOjAwLjcyNCAgUkVBRCBNVUxUSVBMRQoKU01BUlQgU2VsZi10 ZXN0IGxvZyBzdHJ1Y3R1cmUgcmV2aXNpb24gbnVtYmVyIDEKTnVtICBUZXN0X0Rlc2NyaXB0 aW9uICAgIFN0YXR1cyAgICAgICAgICAgICAgICAgIFJlbWFpbmluZyAgTGlmZVRpbWUoaG91 cnMpICBMQkFfb2ZfZmlyc3RfZXJyb3IKIyAxICBFeHRlbmRlZCBvZmZsaW5lICAgIENvbXBs ZXRlZCB3aXRob3V0IGVycm9yICAgICAgIDAwJSAgICAgICAgIDIgICAgICAgICAtCgpTTUFS VCBTZWxlY3RpdmUgc2VsZi10ZXN0IGxvZyBkYXRhIHN0cnVjdHVyZSByZXZpc2lvbiBudW1i ZXIgMQogU1BBTiAgTUlOX0xCQSAgTUFYX0xCQSAgQ1VSUkVOVF9URVNUX1NUQVRVUwogICAg MSAgICAgICAgMCAgICAgICAgMCAgTm90X3Rlc3RpbmcKICAgIDIgICAgICAgIDAgICAgICAg IDAgIE5vdF90ZXN0aW5nCiAgICAzICAgICAgICAwICAgICAgICAwICBOb3RfdGVzdGluZwog ICAgNCAgICAgICAgMCAgICAgICAgMCAgTm90X3Rlc3RpbmcKICAgIDUgICAgICAgIDAgICAg ICAgIDAgIE5vdF90ZXN0aW5nClNlbGVjdGl2ZSBzZWxmLXRlc3QgZmxhZ3MgKDB4MCk6CiAg QWZ0ZXIgc2Nhbm5pbmcgc2VsZWN0ZWQgc3BhbnMsIGRvIE5PVCByZWFkLXNjYW4gcmVtYWlu ZGVyIG9mIGRpc2suCklmIFNlbGVjdGl2ZSBzZWxmLXRlc3QgaXMgcGVuZGluZyBvbiBwb3dl ci11cCwgcmVzdW1lIGFmdGVyIDAgbWludXRlIGRlbGF5LgoK --------------090406050902030903010601 Content-Type: text/plain; name="smartctl-ad6.txt" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="smartctl-ad6.txt" c21hcnRjdGwgNS4zOS4xIDIwMTAtMDEtMjggcjMwNTQgW0ZyZWVCU0QgOC4wLVJFTEVBU0Ut cDEgaTM4Nl0gKGxvY2FsIGJ1aWxkKQpDb3B5cmlnaHQgKEMpIDIwMDItMTAgYnkgQnJ1Y2Ug QWxsZW4sIGh0dHA6Ly9zbWFydG1vbnRvb2xzLnNvdXJjZWZvcmdlLm5ldAoKPT09IFNUQVJU IE9GIElORk9STUFUSU9OIFNFQ1RJT04gPT09Ck1vZGVsIEZhbWlseTogICAgIFNlYWdhdGUg QmFycmFjdWRhIEVTLjIKRGV2aWNlIE1vZGVsOiAgICAgU1QzNTAwMzIwTlMKU2VyaWFsIE51 bWJlcjogICAgOVFNQzhHUzAKRmlybXdhcmUgVmVyc2lvbjogU04wNgpVc2VyIENhcGFjaXR5 OiAgICA1MDAsMTA3LDg2MiwwMTYgYnl0ZXMKRGV2aWNlIGlzOiAgICAgICAgSW4gc21hcnRj dGwgZGF0YWJhc2UgW2ZvciBkZXRhaWxzIHVzZTogLVAgc2hvd10KQVRBIFZlcnNpb24gaXM6 ICAgOApBVEEgU3RhbmRhcmQgaXM6ICBBVEEtOC1BQ1MgcmV2aXNpb24gNApMb2NhbCBUaW1l IGlzOiAgICBGcmkgTWF5IDE0IDIzOjAxOjUyIDIwMTAgQ0VTVApTTUFSVCBzdXBwb3J0IGlz OiBBdmFpbGFibGUgLSBkZXZpY2UgaGFzIFNNQVJUIGNhcGFiaWxpdHkuClNNQVJUIHN1cHBv cnQgaXM6IEVuYWJsZWQKCj09PSBTVEFSVCBPRiBSRUFEIFNNQVJUIERBVEEgU0VDVElPTiA9 PT0KU01BUlQgb3ZlcmFsbC1oZWFsdGggc2VsZi1hc3Nlc3NtZW50IHRlc3QgcmVzdWx0OiBQ QVNTRUQKCkdlbmVyYWwgU01BUlQgVmFsdWVzOgpPZmZsaW5lIGRhdGEgY29sbGVjdGlvbiBz dGF0dXM6ICAoMHg4MikJT2ZmbGluZSBkYXRhIGNvbGxlY3Rpb24gYWN0aXZpdHkKCQkJCQl3 YXMgY29tcGxldGVkIHdpdGhvdXQgZXJyb3IuCgkJCQkJQXV0byBPZmZsaW5lIERhdGEgQ29s bGVjdGlvbjogRW5hYmxlZC4KU2VsZi10ZXN0IGV4ZWN1dGlvbiBzdGF0dXM6ICAgICAgKCAg IDApCVRoZSBwcmV2aW91cyBzZWxmLXRlc3Qgcm91dGluZSBjb21wbGV0ZWQKCQkJCQl3aXRo b3V0IGVycm9yIG9yIG5vIHNlbGYtdGVzdCBoYXMgZXZlciAKCQkJCQliZWVuIHJ1bi4KVG90 YWwgdGltZSB0byBjb21wbGV0ZSBPZmZsaW5lIApkYXRhIGNvbGxlY3Rpb246IAkJICggNjUw KSBzZWNvbmRzLgpPZmZsaW5lIGRhdGEgY29sbGVjdGlvbgpjYXBhYmlsaXRpZXM6IAkJCSAo MHg3YikgU01BUlQgZXhlY3V0ZSBPZmZsaW5lIGltbWVkaWF0ZS4KCQkJCQlBdXRvIE9mZmxp bmUgZGF0YSBjb2xsZWN0aW9uIG9uL29mZiBzdXBwb3J0LgoJCQkJCVN1c3BlbmQgT2ZmbGlu ZSBjb2xsZWN0aW9uIHVwb24gbmV3CgkJCQkJY29tbWFuZC4KCQkJCQlPZmZsaW5lIHN1cmZh Y2Ugc2NhbiBzdXBwb3J0ZWQuCgkJCQkJU2VsZi10ZXN0IHN1cHBvcnRlZC4KCQkJCQlDb252 ZXlhbmNlIFNlbGYtdGVzdCBzdXBwb3J0ZWQuCgkJCQkJU2VsZWN0aXZlIFNlbGYtdGVzdCBz dXBwb3J0ZWQuClNNQVJUIGNhcGFiaWxpdGllczogICAgICAgICAgICAoMHgwMDAzKQlTYXZl cyBTTUFSVCBkYXRhIGJlZm9yZSBlbnRlcmluZwoJCQkJCXBvd2VyLXNhdmluZyBtb2RlLgoJ CQkJCVN1cHBvcnRzIFNNQVJUIGF1dG8gc2F2ZSB0aW1lci4KRXJyb3IgbG9nZ2luZyBjYXBh YmlsaXR5OiAgICAgICAgKDB4MDEpCUVycm9yIGxvZ2dpbmcgc3VwcG9ydGVkLgoJCQkJCUdl bmVyYWwgUHVycG9zZSBMb2dnaW5nIHN1cHBvcnRlZC4KU2hvcnQgc2VsZi10ZXN0IHJvdXRp bmUgCnJlY29tbWVuZGVkIHBvbGxpbmcgdGltZTogCSAoICAgMSkgbWludXRlcy4KRXh0ZW5k ZWQgc2VsZi10ZXN0IHJvdXRpbmUKcmVjb21tZW5kZWQgcG9sbGluZyB0aW1lOiAJICggMTIw KSBtaW51dGVzLgpDb252ZXlhbmNlIHNlbGYtdGVzdCByb3V0aW5lCnJlY29tbWVuZGVkIHBv bGxpbmcgdGltZTogCSAoICAgMikgbWludXRlcy4KU0NUIGNhcGFiaWxpdGllczogCSAgICAg ICAoMHgxMDNkKQlTQ1QgU3RhdHVzIHN1cHBvcnRlZC4KCQkJCQlTQ1QgRmVhdHVyZSBDb250 cm9sIHN1cHBvcnRlZC4KCQkJCQlTQ1QgRGF0YSBUYWJsZSBzdXBwb3J0ZWQuCgpTTUFSVCBB dHRyaWJ1dGVzIERhdGEgU3RydWN0dXJlIHJldmlzaW9uIG51bWJlcjogMTAKVmVuZG9yIFNw ZWNpZmljIFNNQVJUIEF0dHJpYnV0ZXMgd2l0aCBUaHJlc2hvbGRzOgpJRCMgQVRUUklCVVRF X05BTUUgICAgICAgICAgRkxBRyAgICAgVkFMVUUgV09SU1QgVEhSRVNIIFRZUEUgICAgICBV UERBVEVEICBXSEVOX0ZBSUxFRCBSQVdfVkFMVUUKICAxIFJhd19SZWFkX0Vycm9yX1JhdGUg ICAgIDB4MDAwZiAgIDA4MCAgIDA2NCAgIDA0NCAgICBQcmUtZmFpbCAgQWx3YXlzICAgICAg IC0gICAgICAgMTA4NjE4MjkwCiAgMyBTcGluX1VwX1RpbWUgICAgICAgICAgICAweDAwMDMg ICAwOTkgICAwOTkgICAwMDAgICAgUHJlLWZhaWwgIEFsd2F5cyAgICAgICAtICAgICAgIDAK ICA0IFN0YXJ0X1N0b3BfQ291bnQgICAgICAgIDB4MDAzMiAgIDEwMCAgIDEwMCAgIDAyMCAg ICBPbGRfYWdlICAgQWx3YXlzICAgICAgIC0gICAgICAgMTMKICA1IFJlYWxsb2NhdGVkX1Nl Y3Rvcl9DdCAgIDB4MDAzMyAgIDA5OCAgIDA5OCAgIDAzNiAgICBQcmUtZmFpbCAgQWx3YXlz ICAgICAgIC0gICAgICAgNTAKICA3IFNlZWtfRXJyb3JfUmF0ZSAgICAgICAgIDB4MDAwZiAg IDA3MiAgIDA2MCAgIDAzMCAgICBQcmUtZmFpbCAgQWx3YXlzICAgICAgIC0gICAgICAgMTgx MzY0NzUKICA5IFBvd2VyX09uX0hvdXJzICAgICAgICAgIDB4MDAzMiAgIDEwMCAgIDEwMCAg IDAwMCAgICBPbGRfYWdlICAgQWx3YXlzICAgICAgIC0gICAgICAgODI2CiAxMCBTcGluX1Jl dHJ5X0NvdW50ICAgICAgICAweDAwMTMgICAxMDAgICAxMDAgICAwOTcgICAgUHJlLWZhaWwg IEFsd2F5cyAgICAgICAtICAgICAgIDAKIDEyIFBvd2VyX0N5Y2xlX0NvdW50ICAgICAgIDB4 MDAzMiAgIDEwMCAgIDEwMCAgIDAyMCAgICBPbGRfYWdlICAgQWx3YXlzICAgICAgIC0gICAg ICAgMTMKMTg0IEVuZC10by1FbmRfRXJyb3IgICAgICAgIDB4MDAzMiAgIDEwMCAgIDEwMCAg IDA5OSAgICBPbGRfYWdlICAgQWx3YXlzICAgICAgIC0gICAgICAgMAoxODcgUmVwb3J0ZWRf VW5jb3JyZWN0ICAgICAgMHgwMDMyICAgMDk5ICAgMDk5ICAgMDAwICAgIE9sZF9hZ2UgICBB bHdheXMgICAgICAgLSAgICAgICAxCjE4OCBDb21tYW5kX1RpbWVvdXQgICAgICAgICAweDAw MzIgICAxMDAgICAwOTkgICAwMDAgICAgT2xkX2FnZSAgIEFsd2F5cyAgICAgICAtICAgICAg IDEzMTA3NAoxODkgSGlnaF9GbHlfV3JpdGVzICAgICAgICAgMHgwMDNhICAgMTAwICAgMTAw ICAgMDAwICAgIE9sZF9hZ2UgICBBbHdheXMgICAgICAgLSAgICAgICAwCjE5MCBBaXJmbG93 X1RlbXBlcmF0dXJlX0NlbCAweDAwMjIgICAwNzkgICAwNjUgICAwNDUgICAgT2xkX2FnZSAg IEFsd2F5cyAgICAgICAtICAgICAgIDIxIChMaWZldGltZSBNaW4vTWF4IDIxLzIyKQoxOTQg VGVtcGVyYXR1cmVfQ2Vsc2l1cyAgICAgMHgwMDIyICAgMDIxICAgMDQwICAgMDAwICAgIE9s ZF9hZ2UgICBBbHdheXMgICAgICAgLSAgICAgICAyMSAoMCAxOSAwIDApCjE5NSBIYXJkd2Fy ZV9FQ0NfUmVjb3ZlcmVkICAweDAwMWEgICAwNTMgICAwMzUgICAwMDAgICAgT2xkX2FnZSAg IEFsd2F5cyAgICAgICAtICAgICAgIDEwODYxODI5MAoxOTcgQ3VycmVudF9QZW5kaW5nX1Nl Y3RvciAgMHgwMDEyICAgMTAwICAgMTAwICAgMDAwICAgIE9sZF9hZ2UgICBBbHdheXMgICAg ICAgLSAgICAgICAwCjE5OCBPZmZsaW5lX1VuY29ycmVjdGFibGUgICAweDAwMTAgICAxMDAg ICAxMDAgICAwMDAgICAgT2xkX2FnZSAgIE9mZmxpbmUgICAgICAtICAgICAgIDAKMTk5IFVE TUFfQ1JDX0Vycm9yX0NvdW50ICAgIDB4MDAzZSAgIDIwMCAgIDIwMCAgIDAwMCAgICBPbGRf YWdlICAgQWx3YXlzICAgICAgIC0gICAgICAgMAoKU01BUlQgRXJyb3IgTG9nIFZlcnNpb246 IDEKTm8gRXJyb3JzIExvZ2dlZAoKU01BUlQgU2VsZi10ZXN0IGxvZyBzdHJ1Y3R1cmUgcmV2 aXNpb24gbnVtYmVyIDEKTnVtICBUZXN0X0Rlc2NyaXB0aW9uICAgIFN0YXR1cyAgICAgICAg ICAgICAgICAgIFJlbWFpbmluZyAgTGlmZVRpbWUoaG91cnMpICBMQkFfb2ZfZmlyc3RfZXJy b3IKIyAxICBFeHRlbmRlZCBvZmZsaW5lICAgIENvbXBsZXRlZCB3aXRob3V0IGVycm9yICAg ICAgIDAwJSAgICAgICAgIDIgICAgICAgICAtCgpTTUFSVCBTZWxlY3RpdmUgc2VsZi10ZXN0 IGxvZyBkYXRhIHN0cnVjdHVyZSByZXZpc2lvbiBudW1iZXIgMQogU1BBTiAgTUlOX0xCQSAg TUFYX0xCQSAgQ1VSUkVOVF9URVNUX1NUQVRVUwogICAgMSAgICAgICAgMCAgICAgICAgMCAg Tm90X3Rlc3RpbmcKICAgIDIgICAgICAgIDAgICAgICAgIDAgIE5vdF90ZXN0aW5nCiAgICAz ICAgICAgICAwICAgICAgICAwICBOb3RfdGVzdGluZwogICAgNCAgICAgICAgMCAgICAgICAg MCAgTm90X3Rlc3RpbmcKICAgIDUgICAgICAgIDAgICAgICAgIDAgIE5vdF90ZXN0aW5nClNl bGVjdGl2ZSBzZWxmLXRlc3QgZmxhZ3MgKDB4MCk6CiAgQWZ0ZXIgc2Nhbm5pbmcgc2VsZWN0 ZWQgc3BhbnMsIGRvIE5PVCByZWFkLXNjYW4gcmVtYWluZGVyIG9mIGRpc2suCklmIFNlbGVj dGl2ZSBzZWxmLXRlc3QgaXMgcGVuZGluZyBvbiBwb3dlci11cCwgcmVzdW1lIGFmdGVyIDAg bWludXRlIGRlbGF5LgoK --------------090406050902030903010601 Content-Type: text/plain; name="vmstat-i.txt" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="vmstat-i.txt" IyB2bXN0YXQgLWkKaW50ZXJydXB0ICAgICAgICAgICAgICAgICAgICAgICAgICB0b3RhbCAg ICAgICByYXRlCmlycTQ6IHVhcnQwICAgICAgICAgICAgICAgICAgICAgICAgIDEzMjUgICAg ICAgICAgMAppcnEyMTogdWhjaTAgdWhjaSsgICAgICAgICAgICAgICAgIDE3ODA2ICAgICAg ICAgIDAKaXJxMjM6IGF0YXBjaTAgICAgICAgICAgICAgICAgIDM3MTAyMTI5OSAgICAgIDEw NDIzCmNwdTA6IHRpbWVyICAgICAgICAgICAgICAgICAgICAgNzExNTk4OTkgICAgICAgMTk5 OQppcnEyNTY6IGJnZTAgICAgICAgICAgICAgICAgICAgICAxNDcxMDA0ICAgICAgICAgNDEK Y3B1MTogdGltZXIgICAgICAgICAgICAgICAgICAgICA3MTE2NTEyOCAgICAgICAxOTk5ClRv dGFsICAgICAgICAgICAgICAgICAgICAgICAgICA1MTQ4MzY0NjEgICAgICAxNDQ2MwoK --------------090406050902030903010601 Content-Type: text/plain; name="dmesg-ata.txt" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="dmesg-ata.txt" YXRhcGNpMDogPEludGVsIElDSDkgU0FUQTMwMCBjb250cm9sbGVyPiBwb3J0IDB4ZGMyMC0w eGRjMjcsMHhkYzEwLTB4ZGMxMywweGRjMjgtMHhkYzJmLDB4ZGMxNC0weGRjMTcsMHhkYzQw LTB4ZGM0ZiwweGRjNTAtMHhkYzVmIGlycSAyMyBhdCBkZXZpY2UgMzEuMiBvbiBwY2kwCmF0 YXBjaTA6IFtJVEhSRUFEXQphdGEyOiA8QVRBIGNoYW5uZWwgMD4gb24gYXRhcGNpMAphdGEy OiBbSVRIUkVBRF0KYXRhMzogPEFUQSBjaGFubmVsIDE+IG9uIGF0YXBjaTAKYXRhMzogW0lU SFJFQURdCmF0YXBjaTE6IDxJbnRlbCBJQ0g5IFNBVEEzMDAgY29udHJvbGxlcj4gcG9ydCAw eGRjMzAtMHhkYzM3LDB4ZGMxOC0weGRjMWIsMHhkYzM4LTB4ZGMzZiwweGRjMWMtMHhkYzFm LDB4ZGM2MC0weGRjNmYsMHhkYzcwLTB4ZGM3ZiBpcnEgMjIgYXQgZGV2aWNlIDMxLjUgb24g cGNpMAphdGFwY2kxOiBbSVRIUkVBRF0KYXRhNDogPEFUQSBjaGFubmVsIDA+IG9uIGF0YXBj aTEKYXRhNDogW0lUSFJFQURdCmF0YTU6IDxBVEEgY2hhbm5lbCAxPiBvbiBhdGFwY2kxCmF0 YTU6IFtJVEhSRUFEXQphdGEwIGF0IHBvcnQgMHgxZjAtMHgxZjcsMHgzZjYgaXJxIDE0IG9u IGlzYTAKYXRhMDogW0lUSFJFQURdCmF0YTEgYXQgcG9ydCAweDE3MC0weDE3NywweDM3NiBp cnEgMTUgb24gaXNhMAphdGExOiBbSVRIUkVBRF0KYWQ0OiA0NzY5NDBNQiA8V0RDIFdENTAw MUFBTFMtMDBMM0IyIDAxLjAzQjAxPiBhdCBhdGEyLW1hc3RlciBTQVRBMzAwCmFjZDA6IERW RFJPTSA8VEVBQyBEVkQtUk9NIERWMjhTVi9ELjBKPiBhdCBhdGEyLXNsYXZlIFNBVEExNTAK YWQ2OiA0NzY5NDBNQiA8U2VhZ2F0ZSBTVDM1MDAzMjBOUyBTTjA2PiBhdCBhdGEzLW1hc3Rl ciBTQVRBMzAwCgo= --------------090406050902030903010601-- From owner-freebsd-stable@FreeBSD.ORG Fri May 14 22:42:38 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DECFD106566B for ; Fri, 14 May 2010 22:42:37 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta14.emeryville.ca.mail.comcast.net (qmta14.emeryville.ca.mail.comcast.net [76.96.27.212]) by mx1.freebsd.org (Postfix) with ESMTP id C68E48FC16 for ; Fri, 14 May 2010 22:42:37 +0000 (UTC) Received: from omta15.emeryville.ca.mail.comcast.net ([76.96.30.71]) by qmta14.emeryville.ca.mail.comcast.net with comcast id HT921e0041Y3wxoAEaiebU; Fri, 14 May 2010 22:42:38 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta15.emeryville.ca.mail.comcast.net with comcast id Haid1e0083S48mS8baidhu; Fri, 14 May 2010 22:42:38 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 289E89B419; Fri, 14 May 2010 15:42:36 -0700 (PDT) Date: Fri, 14 May 2010 15:42:36 -0700 From: Jeremy Chadwick To: Pieter de Boer Message-ID: <20100514224236.GA11680@icarus.home.lan> References: <4BED8B89.6010901@os3.nl> <20100514195346.GA8977@icarus.home.lan> <4BEDBC08.2040002@os3.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4BEDBC08.2040002@os3.nl> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-stable@freebsd.org Subject: Re: Read / write timeouts on SATA disks connected to ICH9 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 May 2010 22:42:38 -0000 On Fri, May 14, 2010 at 11:09:28PM +0200, Pieter de Boer wrote: > The ad4 SMART output is showing errors, as this disk is indeed > broken now. It wasn't before and it is a replacement of another disk > that wasn't broken either. Grmbl, I now see reallocated sectors on > ad6 as well, in the smartctl output. So both disks look wonky; > although afaik that's not the main issue here. Lots to say about all of this. Focusing on drive ad4 (Western Digital): The disk has 1 uncorrected sector (Attribute 198). This means the drive tried to remap it and was not successful. This could have happened any time during the lifetime of the drive. There are no pending sector reallocations (Attribute 197) (meaning there aren't others which are bad which the drive is waiting to attempt remapping for), and there are no remapped sectors (Attribute 5). There have been no successful reallocation attempts during the drive's lifetime (Attribute 196). In general, I would say this is acceptable. If Attribute 198 was higher, or you had other pending sectors which needed to be remapped, I'd say replace the disk. UDMA/CRC error count (Attribute 199) is zero. That's good -- it means that most likely cabling issues can be ruled out, since the attribute tracks the number of communication errors between the controller and the disk PCB. Drive temperature looks good, so nothing to worry about there. The drive itself has detected numerous error conditions in the SMART error log during its lifetime -- a total of 48, but SMART only lists the most recent 5. The drive has been online for a total of 827 hours (Attribute 9), which we can use to determine how recent the drive experienced said errors. Let's examine the first 3: > Error 48 occurred at disk power-on lifetime: 817 hours (34 days + 1 hours) > 40 51 00 9d 84 0e e0 Error: UNC at LBA = 0x000e849d = 951453 > c8 00 20 00 84 0e 00 00 00:45:18.204 READ DMA > > Error 47 occurred at disk power-on lifetime: 817 hours (34 days + 1 hours) > 40 51 00 0c 9d 0e e0 Error: UNC at LBA = 0x000e9d0c = 957708 > c8 00 80 00 9b 0e 00 00 00:03:08.605 READ DMA > > Error 46 occurred at disk power-on lifetime: 817 hours (34 days + 1 hours) > 40 51 00 9d 84 0e e0 Error: UNC at LBA = 0x000e849d = 951453 > c8 00 80 80 82 0e 00 00 00:03:05.176 READ DMA Okay, it's probably safe to assume these are all signs of the uncorrected sector. When a drive attempts a LBA remap -- which in this case it did, but failed -- it can spend quite a bit of time doing that; in some cases minutes, not seconds. The drive essentially "locks up" during this time (from the perspective of the SATA controller) -- it's literally spending all of its time trying to read and re-read the LBA/sector in different ways, hoping to get the data out of it (and/or correct it with ECC) so that it can be written to a spare block and then internally the bad LBA won't ever be used again. What the OS ends up seeing in this situation is disk timeouts. This is completely normal. The WD Caviar Black drives have a useful feature called TLER -- it's disabled by default, for reasons which I don't want to get into here -- which can force the drive to internally give up after X seconds (it's user-selectable) when dealing with such remapping/errors. The idea is to keep the drive from being deemed dead from the OS/controller's point of view. I believe Seagate, Hitachi, or Samsung (I forget which) have this feature as well, but it's not called TLER. Anyway, so this is probably the cause of one detachment/timeout you've seen FreeBSD report. Let's move on to the 2 remaining errors: > Error 45 occurred at disk power-on lifetime: 817 hours (34 days + 1 hours) > 40 51 08 20 47 6c e0 Error: UNC at LBA = 0x006c4720 = 7096096 > c4 ff 08 ff 46 6c 00 00 00:01:09.459 READ MULTIPLE > > Error 44 occurred at disk power-on lifetime: 817 hours (34 days + 1 hours) > 40 51 08 21 8e 67 e0 Error: UNC at LBA = 0x00678e21 = 6786593 > c4 ff 04 3f 2f 00 00 00 00:01:00.724 READ MULTIPLE These two happened around the same time (10 seconds within one another). I'm under the impression that these are *probably* the result of the above uncorrected sector issue, but I'm not 100% certain. Here's why I think that: - The errors occurred within the same hour mark (817) as the previous 3 errors, - The errors happened only 2 minutes prior to the preceding 3, - The drive was in the process of executing READ MULTIPLE (cmd 0xc4), which tells the disk to read multiple logical sectors within 1 pass. The ATA-8 specification states that READ MULTIPLE is a PIO command. I'm not sure how/why FreeBSD would be submitting this to a disk unless the communication protocol had been downgraded from DMA to PIO. mav@ might have some insights on this, as well as how to decode some of the SMART error data shown. It looks like the 48-bit read input block is written in reverse order (word 5 to word 0). If you want to find out the exact LBA that has the problem (there may be more than one), I can step you through performing a selective LBA scan using SMART, since this model of disk does support such. It's easy to do, easy to understand the results, and can be done while the drive is in operation (though I would recommend trying to keep disk I/O to a minimum during this test). Let me know. Focusing on drive ad6 (Seagate): This drive has 0 uncorrected sectors (Attribute 198); however, I don't know what Attribute 187 represents on this model of drive. The disk has successfully remapped 50 sectors (Attribute 5) during its lifetime. There are no pending sector reallocations (Attribute 197). Drive temperature looks good. I would recommend you consider replacing this drive "down the road" sometime, since it does indicate 50 reallocated sectors. One or two is fine, but 50 is a bit much. At least the drive was able to re-read them and reallocate the data successfully. It's very possible that said remappings caused the drive to time out during some I/O operations (from the perspective of the controller and OS); I went over this with regards to ad4. Finally, your vmstat -i output: > # vmstat -i > interrupt total rate > irq23: atapci0 371021299 10423 Good to know there's no IRQ sharing going on, but what does worry me is the interrupt rate (10K interrupts/second). That seems *extremely* high, but it also depends on what kind of disk I/O is happening on this system -- especially since you have 2 disks attached to the same controller. "iostat 1", "iostat -x 1", or "gstat" might come in handy to tell you what kind of disk I/O is going on. If actual I/O is very little, then something weird is going on with regards to the number of interrupts being seen on IRQ 23. mav@ might have some ideas, otherwise I'd recommend rebooting the machine and seeing if the number drops. If so, it may be that the OS has some sort of bug where a disk timing out or falling off the bus causes interrupt problems. (It's too bad you don't have AHCI on this system. It handles stuff like this much more elegantly...) -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Fri May 14 23:58:36 2010 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C178C1065672 for ; Fri, 14 May 2010 23:58:36 +0000 (UTC) (envelope-from TERRY@tmk.com) Received: from server.tmk.com (server.tmk.com [204.141.35.63]) by mx1.freebsd.org (Postfix) with ESMTP id A0C168FC14 for ; Fri, 14 May 2010 23:58:36 +0000 (UTC) Received: from tmk.com by tmk.com (PMDF V6.4 #37010) id <01NN49MTRW7K006QOF@tmk.com> for freebsd-stable@FreeBSD.org; Fri, 14 May 2010 19:58:34 -0400 (EDT) Date: Fri, 14 May 2010 19:47:42 -0400 (EDT) From: Terry Kennedy To: freebsd-stable@FreeBSD.org Message-id: <01NN4A2NF0M4006QOF@tmk.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=us-ascii Cc: Subject: RE: Read / write timeouts on SATA disks connected to ICH9 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 May 2010 23:58:36 -0000 On Fri May 14 22:42:38 UTC 2010, Jeremy Chadwick wrote: > Finally, your vmstat -i output: > > > # vmstat -i > > interrupt total rate > > irq23: atapci0 371021299 10423 > > Good to know there's no IRQ sharing going on, but what does worry me is > the interrupt rate (10K interrupts/second). That seems *extremely* > high, but it also depends on what kind of disk I/O is happening on this > system -- especially since you have 2 disks attached to the same > controller. I have a bunch of R300's here. From one that is using the on-board SATA and 2 drives in a gmirror setup (very similar to the OP) after 18 hours of uptime: [0:2] speedtest:~> vmstat -i interrupt total rate irq23: atapci0 254116 3 I haven't specifically done any stress testing on this box, though I did do a "make -j8 buildworld" during the initial gmirror synchronization. 8-} The drives are a pair of Dell-labeled 160GB "SAMSUNG HE161HJ 1AC01121" that shipped with the box. I also have another R300 with Dell's "SAS 6/iR" card (a re-branded LSI 1068-something, seen as "mpt" by FreeBSD). While Dell only sells that as part of a package deal with the hot-swap backplane and redundant power supplies, there's no reason you couldn't pick one up on eBay and add it yourself. You'll need some sort of breakout cable to get from the big connector on the SAS 6 to individual SATA ports. Terry Kennedy http://www.tmk.com terry@tmk.com New York, NY USA From owner-freebsd-stable@FreeBSD.ORG Sat May 15 03:40:25 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BCE85106564A; Sat, 15 May 2010 03:40:25 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.freebsd.org (Postfix) with ESMTP id 7478B8FC16; Sat, 15 May 2010 03:40:25 +0000 (UTC) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost2.sentex.ca (8.14.3/8.14.3) with ESMTP id o4F3eNT6029438; Fri, 14 May 2010 23:40:23 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-stable.sentex.ca (freebsd-stable.sentex.ca [64.7.128.103]) by smtp1.sentex.ca (8.14.3/8.14.3) with ESMTP id o4F3eNY8094421; Fri, 14 May 2010 23:40:23 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-stable.sentex.ca (Postfix, from userid 666) id 157111B5060; Fri, 14 May 2010 23:40:23 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20100515034023.157111B5060@freebsd-stable.sentex.ca> Date: Fri, 14 May 2010 23:40:23 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at smtp1.sentex.ca X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 205.211.164.50 Cc: Subject: [releng_7 tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 May 2010 03:40:25 -0000 TB --- 2010-05-15 02:06:57 - tinderbox 2.6 running on freebsd-stable.sentex.ca TB --- 2010-05-15 02:06:57 - starting RELENG_7 tinderbox run for amd64/amd64 TB --- 2010-05-15 02:06:57 - cleaning the object tree TB --- 2010-05-15 02:07:27 - cvsupping the source tree TB --- 2010-05-15 02:07:27 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/RELENG_7/amd64/amd64/supfile TB --- 2010-05-15 02:07:38 - building world TB --- 2010-05-15 02:07:38 - MAKEOBJDIRPREFIX=/obj TB --- 2010-05-15 02:07:38 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-05-15 02:07:38 - TARGET=amd64 TB --- 2010-05-15 02:07:38 - TARGET_ARCH=amd64 TB --- 2010-05-15 02:07:38 - TZ=UTC TB --- 2010-05-15 02:07:38 - __MAKE_CONF=/dev/null TB --- 2010-05-15 02:07:38 - cd /src TB --- 2010-05-15 02:07:38 - /usr/bin/make -B buildworld >>> World build started on Sat May 15 02:07:39 UTC 2010 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Sat May 15 03:38:13 UTC 2010 TB --- 2010-05-15 03:38:13 - generating LINT kernel config TB --- 2010-05-15 03:38:13 - cd /src/sys/amd64/conf TB --- 2010-05-15 03:38:13 - /usr/bin/make -B LINT TB --- 2010-05-15 03:38:13 - building LINT kernel TB --- 2010-05-15 03:38:13 - MAKEOBJDIRPREFIX=/obj TB --- 2010-05-15 03:38:13 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-05-15 03:38:13 - TARGET=amd64 TB --- 2010-05-15 03:38:13 - TARGET_ARCH=amd64 TB --- 2010-05-15 03:38:13 - TZ=UTC TB --- 2010-05-15 03:38:13 - __MAKE_CONF=/dev/null TB --- 2010-05-15 03:38:13 - cd /src TB --- 2010-05-15 03:38:13 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat May 15 03:38:13 UTC 2010 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies [...] ===> em (depend) @ -> /src/sys machine -> /src/sys/amd64/include awk -f @/tools/makeobjops.awk @/kern/device_if.m -h awk -f @/tools/makeobjops.awk @/kern/bus_if.m -h awk -f @/tools/makeobjops.awk @/dev/pci/pci_if.m -h ln -sf /obj/amd64/src/sys/LINT/opt_inet.h opt_inet.h make: don't know how to make if_lem.c. Stop *** Error code 2 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/amd64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-05-15 03:40:22 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-05-15 03:40:22 - ERROR: failed to build lint kernel TB --- 2010-05-15 03:40:22 - 4650.35 user 524.41 system 5605.26 real http://tinderbox.freebsd.org/tinderbox-releng_7-RELENG_7-amd64-amd64.full From owner-freebsd-stable@FreeBSD.ORG Sat May 15 04:29:07 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5917D1065670; Sat, 15 May 2010 04:29:07 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 0F73E8FC08; Sat, 15 May 2010 04:29:06 +0000 (UTC) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.14.3/8.14.3) with ESMTP id o4F4T45C019915; Sat, 15 May 2010 00:29:04 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-stable.sentex.ca (freebsd-stable.sentex.ca [64.7.128.103]) by smtp2.sentex.ca (8.14.4/8.14.4) with ESMTP id o4F4T4rE055544; Sat, 15 May 2010 00:29:04 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-stable.sentex.ca (Postfix, from userid 666) id 45BF21B5060; Sat, 15 May 2010 00:29:04 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20100515042904.45BF21B5060@freebsd-stable.sentex.ca> Date: Sat, 15 May 2010 00:29:04 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at smtp2.sentex.ca X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: Subject: [releng_7 tinderbox] failure on i386/i386 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 May 2010 04:29:07 -0000 TB --- 2010-05-15 03:21:53 - tinderbox 2.6 running on freebsd-stable.sentex.ca TB --- 2010-05-15 03:21:53 - starting RELENG_7 tinderbox run for i386/i386 TB --- 2010-05-15 03:21:53 - cleaning the object tree TB --- 2010-05-15 03:22:18 - cvsupping the source tree TB --- 2010-05-15 03:22:18 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/RELENG_7/i386/i386/supfile TB --- 2010-05-15 03:22:30 - building world TB --- 2010-05-15 03:22:30 - MAKEOBJDIRPREFIX=/obj TB --- 2010-05-15 03:22:30 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-05-15 03:22:30 - TARGET=i386 TB --- 2010-05-15 03:22:30 - TARGET_ARCH=i386 TB --- 2010-05-15 03:22:30 - TZ=UTC TB --- 2010-05-15 03:22:30 - __MAKE_CONF=/dev/null TB --- 2010-05-15 03:22:30 - cd /src TB --- 2010-05-15 03:22:30 - /usr/bin/make -B buildworld >>> World build started on Sat May 15 03:22:31 UTC 2010 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sat May 15 04:26:42 UTC 2010 TB --- 2010-05-15 04:26:42 - generating LINT kernel config TB --- 2010-05-15 04:26:42 - cd /src/sys/i386/conf TB --- 2010-05-15 04:26:42 - /usr/bin/make -B LINT TB --- 2010-05-15 04:26:42 - building LINT kernel TB --- 2010-05-15 04:26:42 - MAKEOBJDIRPREFIX=/obj TB --- 2010-05-15 04:26:42 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-05-15 04:26:42 - TARGET=i386 TB --- 2010-05-15 04:26:42 - TARGET_ARCH=i386 TB --- 2010-05-15 04:26:42 - TZ=UTC TB --- 2010-05-15 04:26:42 - __MAKE_CONF=/dev/null TB --- 2010-05-15 04:26:42 - cd /src TB --- 2010-05-15 04:26:42 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat May 15 04:26:42 UTC 2010 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies [...] ===> em (depend) @ -> /src/sys machine -> /src/sys/i386/include awk -f @/tools/makeobjops.awk @/kern/device_if.m -h awk -f @/tools/makeobjops.awk @/kern/bus_if.m -h awk -f @/tools/makeobjops.awk @/dev/pci/pci_if.m -h ln -sf /obj/src/sys/LINT/opt_inet.h opt_inet.h make: don't know how to make if_lem.c. Stop *** Error code 2 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-05-15 04:29:04 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-05-15 04:29:04 - ERROR: failed to build lint kernel TB --- 2010-05-15 04:29:04 - 3362.72 user 358.23 system 4030.56 real http://tinderbox.freebsd.org/tinderbox-releng_7-RELENG_7-i386-i386.full From owner-freebsd-stable@FreeBSD.ORG Sat May 15 04:46:46 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0F1501065673; Sat, 15 May 2010 04:46:46 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.freebsd.org (Postfix) with ESMTP id BC08E8FC14; Sat, 15 May 2010 04:46:45 +0000 (UTC) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost2.sentex.ca (8.14.3/8.14.3) with ESMTP id o4F4kh2V032411; Sat, 15 May 2010 00:46:43 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-stable.sentex.ca (freebsd-stable.sentex.ca [64.7.128.103]) by smtp1.sentex.ca (8.14.3/8.14.3) with ESMTP id o4F4khGh015529; Sat, 15 May 2010 00:46:43 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-stable.sentex.ca (Postfix, from userid 666) id 9A1181B5060; Sat, 15 May 2010 00:46:43 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20100515044643.9A1181B5060@freebsd-stable.sentex.ca> Date: Sat, 15 May 2010 00:46:43 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at smtp1.sentex.ca X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 205.211.164.50 Cc: Subject: [releng_7 tinderbox] failure on i386/pc98 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 May 2010 04:46:46 -0000 TB --- 2010-05-15 03:40:23 - tinderbox 2.6 running on freebsd-stable.sentex.ca TB --- 2010-05-15 03:40:23 - starting RELENG_7 tinderbox run for i386/pc98 TB --- 2010-05-15 03:40:23 - cleaning the object tree TB --- 2010-05-15 03:40:43 - cvsupping the source tree TB --- 2010-05-15 03:40:43 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/RELENG_7/i386/pc98/supfile TB --- 2010-05-15 03:40:52 - building world TB --- 2010-05-15 03:40:52 - MAKEOBJDIRPREFIX=/obj TB --- 2010-05-15 03:40:52 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-05-15 03:40:52 - TARGET=pc98 TB --- 2010-05-15 03:40:52 - TARGET_ARCH=i386 TB --- 2010-05-15 03:40:52 - TZ=UTC TB --- 2010-05-15 03:40:52 - __MAKE_CONF=/dev/null TB --- 2010-05-15 03:40:52 - cd /src TB --- 2010-05-15 03:40:52 - /usr/bin/make -B buildworld >>> World build started on Sat May 15 03:40:54 UTC 2010 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sat May 15 04:44:43 UTC 2010 TB --- 2010-05-15 04:44:43 - generating LINT kernel config TB --- 2010-05-15 04:44:43 - cd /src/sys/pc98/conf TB --- 2010-05-15 04:44:43 - /usr/bin/make -B LINT TB --- 2010-05-15 04:44:43 - building LINT kernel TB --- 2010-05-15 04:44:43 - MAKEOBJDIRPREFIX=/obj TB --- 2010-05-15 04:44:43 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-05-15 04:44:43 - TARGET=pc98 TB --- 2010-05-15 04:44:43 - TARGET_ARCH=i386 TB --- 2010-05-15 04:44:43 - TZ=UTC TB --- 2010-05-15 04:44:43 - __MAKE_CONF=/dev/null TB --- 2010-05-15 04:44:43 - cd /src TB --- 2010-05-15 04:44:43 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat May 15 04:44:43 UTC 2010 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies [...] @ -> /src/sys machine -> /src/sys/pc98/include i386 -> /src/sys/i386/include awk -f @/tools/makeobjops.awk @/kern/device_if.m -h awk -f @/tools/makeobjops.awk @/kern/bus_if.m -h awk -f @/tools/makeobjops.awk @/dev/pci/pci_if.m -h ln -sf /obj/pc98/src/sys/LINT/opt_inet.h opt_inet.h make: don't know how to make if_lem.c. Stop *** Error code 2 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/pc98/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-05-15 04:46:43 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-05-15 04:46:43 - ERROR: failed to build lint kernel TB --- 2010-05-15 04:46:43 - 3309.74 user 364.98 system 3980.45 real http://tinderbox.freebsd.org/tinderbox-releng_7-RELENG_7-i386-pc98.full From owner-freebsd-stable@FreeBSD.ORG Sat May 15 04:54:11 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 554C2106564A for ; Sat, 15 May 2010 04:54:11 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta06.emeryville.ca.mail.comcast.net (qmta06.emeryville.ca.mail.comcast.net [76.96.30.56]) by mx1.freebsd.org (Postfix) with ESMTP id 3D8988FC12 for ; Sat, 15 May 2010 04:54:09 +0000 (UTC) Received: from omta08.emeryville.ca.mail.comcast.net ([76.96.30.12]) by qmta06.emeryville.ca.mail.comcast.net with comcast id HgUz1e0020FhH24A6guAxc; Sat, 15 May 2010 04:54:10 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta08.emeryville.ca.mail.comcast.net with comcast id HguA1e0023S48mS8UguAPp; Sat, 15 May 2010 04:54:10 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 547E59B423; Fri, 14 May 2010 21:54:09 -0700 (PDT) Date: Fri, 14 May 2010 21:54:09 -0700 From: Jeremy Chadwick To: jfvogel@gmail.com Message-ID: <20100515045409.GA22196@icarus.home.lan> References: <20100515034023.157111B5060@freebsd-stable.sentex.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100515034023.157111B5060@freebsd-stable.sentex.ca> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-stable@freebsd.org Subject: Re: [releng_7 tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 May 2010 04:54:11 -0000 On Fri, May 14, 2010 at 11:40:23PM -0400, FreeBSD Tinderbox wrote: > ===> em (depend) > @ -> /src/sys > machine -> /src/sys/amd64/include > awk -f @/tools/makeobjops.awk @/kern/device_if.m -h > awk -f @/tools/makeobjops.awk @/kern/bus_if.m -h > awk -f @/tools/makeobjops.awk @/dev/pci/pci_if.m -h > ln -sf /obj/amd64/src/sys/LINT/opt_inet.h opt_inet.h > make: don't know how to make if_lem.c. Stop > *** Error code 2 > > Stop in /src/sys/modules. > *** Error code 1 > > Stop in /obj/amd64/src/sys/LINT. > *** Error code 1 Jack, did you break em(4) (or lem in this case) again? :-) -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Sat May 15 05:57:26 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D4FD41065672; Sat, 15 May 2010 05:57:26 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 8B7798FC0C; Sat, 15 May 2010 05:57:26 +0000 (UTC) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.14.3/8.14.3) with ESMTP id o4F5vNFv022590; Sat, 15 May 2010 01:57:24 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-stable.sentex.ca (freebsd-stable.sentex.ca [64.7.128.103]) by smtp1.sentex.ca (8.14.3/8.14.3) with ESMTP id o4F5vNPM040293; Sat, 15 May 2010 01:57:23 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-stable.sentex.ca (Postfix, from userid 666) id 9DF711B5060; Sat, 15 May 2010 01:57:23 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20100515055723.9DF711B5060@freebsd-stable.sentex.ca> Date: Sat, 15 May 2010 01:57:23 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at smtp1.sentex.ca X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: Subject: [releng_7 tinderbox] failure on ia64/ia64 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 May 2010 05:57:27 -0000 TB --- 2010-05-15 04:29:04 - tinderbox 2.6 running on freebsd-stable.sentex.ca TB --- 2010-05-15 04:29:04 - starting RELENG_7 tinderbox run for ia64/ia64 TB --- 2010-05-15 04:29:04 - cleaning the object tree TB --- 2010-05-15 04:29:28 - cvsupping the source tree TB --- 2010-05-15 04:29:28 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/RELENG_7/ia64/ia64/supfile TB --- 2010-05-15 04:29:40 - building world TB --- 2010-05-15 04:29:40 - MAKEOBJDIRPREFIX=/obj TB --- 2010-05-15 04:29:40 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-05-15 04:29:40 - TARGET=ia64 TB --- 2010-05-15 04:29:40 - TARGET_ARCH=ia64 TB --- 2010-05-15 04:29:40 - TZ=UTC TB --- 2010-05-15 04:29:40 - __MAKE_CONF=/dev/null TB --- 2010-05-15 04:29:40 - cd /src TB --- 2010-05-15 04:29:40 - /usr/bin/make -B buildworld >>> World build started on Sat May 15 04:29:41 UTC 2010 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sat May 15 05:55:48 UTC 2010 TB --- 2010-05-15 05:55:48 - generating LINT kernel config TB --- 2010-05-15 05:55:48 - cd /src/sys/ia64/conf TB --- 2010-05-15 05:55:48 - /usr/bin/make -B LINT TB --- 2010-05-15 05:55:48 - building LINT kernel TB --- 2010-05-15 05:55:48 - MAKEOBJDIRPREFIX=/obj TB --- 2010-05-15 05:55:48 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-05-15 05:55:48 - TARGET=ia64 TB --- 2010-05-15 05:55:48 - TARGET_ARCH=ia64 TB --- 2010-05-15 05:55:48 - TZ=UTC TB --- 2010-05-15 05:55:48 - __MAKE_CONF=/dev/null TB --- 2010-05-15 05:55:48 - cd /src TB --- 2010-05-15 05:55:48 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat May 15 05:55:49 UTC 2010 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies [...] ===> em (depend) @ -> /src/sys machine -> /src/sys/ia64/include awk -f @/tools/makeobjops.awk @/kern/device_if.m -h awk -f @/tools/makeobjops.awk @/kern/bus_if.m -h awk -f @/tools/makeobjops.awk @/dev/pci/pci_if.m -h ln -sf /obj/ia64/src/sys/LINT/opt_inet.h opt_inet.h make: don't know how to make if_lem.c. Stop *** Error code 2 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/ia64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-05-15 05:57:23 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-05-15 05:57:23 - ERROR: failed to build lint kernel TB --- 2010-05-15 05:57:23 - 4602.17 user 363.85 system 5299.09 real http://tinderbox.freebsd.org/tinderbox-releng_7-RELENG_7-ia64-ia64.full From owner-freebsd-stable@FreeBSD.ORG Sat May 15 06:38:35 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6182C106564A for ; Sat, 15 May 2010 06:38:35 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-ww0-f54.google.com (mail-ww0-f54.google.com [74.125.82.54]) by mx1.freebsd.org (Postfix) with ESMTP id E9AEE8FC13 for ; Sat, 15 May 2010 06:38:34 +0000 (UTC) Received: by wwb18 with SMTP id 18so884659wwb.13 for ; Fri, 14 May 2010 23:38:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=vIzbXo4J3WHQwUfs5Vy71XdVNOZOzVabkprTv9m7t4Y=; b=WJjmz49TV73O8ZJjW6IQ9b0cBLNevD+++bv/kfYNrBxKsyi+Qb6sqbQ2q2RT4MLPoI yD6SMQsQsGjsKlwRBioZ+YU1rsII4GEf8fwUXWsKLjfqEgvS0cqPm0Bt36bydnE2s54m Kqq0fJDO/vUBGtoPb1OcnrF9eAbE6D4p/Fmxk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=cOyfXVQG3bGMqkFQdsuY5OA1bXr2VC7S+RlRsDGTruDvVAbYjF/LFP3K+LVVDHEHNO wexKmwlMFwrji5Xy26+9z2h2Wur9J8CWoDbdege883zm8o4/8qh2QKtOThT5KGnc/owD nbb07zhzkOSnDIwG5QIylt5sCZUaD9nGGfAxY= MIME-Version: 1.0 Received: by 10.216.85.148 with SMTP id u20mr1402423wee.219.1273905513818; Fri, 14 May 2010 23:38:33 -0700 (PDT) Received: by 10.216.29.129 with HTTP; Fri, 14 May 2010 23:38:33 -0700 (PDT) In-Reply-To: <20100515045409.GA22196@icarus.home.lan> References: <20100515034023.157111B5060@freebsd-stable.sentex.ca> <20100515045409.GA22196@icarus.home.lan> Date: Fri, 14 May 2010 23:38:33 -0700 Message-ID: From: Jack Vogel To: Jeremy Chadwick Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable@freebsd.org Subject: Re: [releng_7 tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 May 2010 06:38:35 -0000 DUH, forgot to add the file, lol. Fix coming shortly.... Jack On Fri, May 14, 2010 at 9:54 PM, Jeremy Chadwick wrote: > On Fri, May 14, 2010 at 11:40:23PM -0400, FreeBSD Tinderbox wrote: > > ===> em (depend) > > @ -> /src/sys > > machine -> /src/sys/amd64/include > > awk -f @/tools/makeobjops.awk @/kern/device_if.m -h > > awk -f @/tools/makeobjops.awk @/kern/bus_if.m -h > > awk -f @/tools/makeobjops.awk @/dev/pci/pci_if.m -h > > ln -sf /obj/amd64/src/sys/LINT/opt_inet.h opt_inet.h > > make: don't know how to make if_lem.c. Stop > > *** Error code 2 > > > > Stop in /src/sys/modules. > > *** Error code 1 > > > > Stop in /obj/amd64/src/sys/LINT. > > *** Error code 1 > > Jack, did you break em(4) (or lem in this case) again? :-) > > -- > | Jeremy Chadwick jdc@parodius.com | > | Parodius Networking http://www.parodius.com/ | > | UNIX Systems Administrator Mountain View, CA, USA | > | Making life hard for others since 1977. PGP: 4BD6C0CB | > > From owner-freebsd-stable@FreeBSD.ORG Sat May 15 07:00:17 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 43A3B1065678; Sat, 15 May 2010 07:00:17 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.freebsd.org (Postfix) with ESMTP id 8B1A18FC0C; Sat, 15 May 2010 07:00:09 +0000 (UTC) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost2.sentex.ca (8.14.3/8.14.3) with ESMTP id o4F707hf038171; Sat, 15 May 2010 03:00:07 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-stable.sentex.ca (freebsd-stable.sentex.ca [64.7.128.103]) by smtp1.sentex.ca (8.14.3/8.14.3) with ESMTP id o4F707HV061654; Sat, 15 May 2010 03:00:07 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-stable.sentex.ca (Postfix, from userid 666) id 2173D1B5060; Sat, 15 May 2010 03:00:07 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20100515070007.2173D1B5060@freebsd-stable.sentex.ca> Date: Sat, 15 May 2010 03:00:07 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at smtp1.sentex.ca X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 205.211.164.50 Cc: Subject: [releng_7 tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 May 2010 07:00:17 -0000 TB --- 2010-05-15 05:57:23 - tinderbox 2.6 running on freebsd-stable.sentex.ca TB --- 2010-05-15 05:57:23 - starting RELENG_7 tinderbox run for sparc64/sparc64 TB --- 2010-05-15 05:57:23 - cleaning the object tree TB --- 2010-05-15 05:57:51 - cvsupping the source tree TB --- 2010-05-15 05:57:51 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/RELENG_7/sparc64/sparc64/supfile TB --- 2010-05-15 05:58:04 - building world TB --- 2010-05-15 05:58:04 - MAKEOBJDIRPREFIX=/obj TB --- 2010-05-15 05:58:04 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-05-15 05:58:04 - TARGET=sparc64 TB --- 2010-05-15 05:58:04 - TARGET_ARCH=sparc64 TB --- 2010-05-15 05:58:04 - TZ=UTC TB --- 2010-05-15 05:58:04 - __MAKE_CONF=/dev/null TB --- 2010-05-15 05:58:04 - cd /src TB --- 2010-05-15 05:58:04 - /usr/bin/make -B buildworld >>> World build started on Sat May 15 05:58:05 UTC 2010 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sat May 15 06:58:39 UTC 2010 TB --- 2010-05-15 06:58:39 - generating LINT kernel config TB --- 2010-05-15 06:58:39 - cd /src/sys/sparc64/conf TB --- 2010-05-15 06:58:39 - /usr/bin/make -B LINT TB --- 2010-05-15 06:58:39 - building LINT kernel TB --- 2010-05-15 06:58:39 - MAKEOBJDIRPREFIX=/obj TB --- 2010-05-15 06:58:39 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-05-15 06:58:39 - TARGET=sparc64 TB --- 2010-05-15 06:58:39 - TARGET_ARCH=sparc64 TB --- 2010-05-15 06:58:39 - TZ=UTC TB --- 2010-05-15 06:58:39 - __MAKE_CONF=/dev/null TB --- 2010-05-15 06:58:39 - cd /src TB --- 2010-05-15 06:58:39 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat May 15 06:58:39 UTC 2010 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies [...] ===> em (depend) @ -> /src/sys machine -> /src/sys/sparc64/include awk -f @/tools/makeobjops.awk @/kern/device_if.m -h awk -f @/tools/makeobjops.awk @/kern/bus_if.m -h awk -f @/tools/makeobjops.awk @/dev/pci/pci_if.m -h ln -sf /obj/sparc64/src/sys/LINT/opt_inet.h opt_inet.h make: don't know how to make if_lem.c. Stop *** Error code 2 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/sparc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-05-15 07:00:06 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-05-15 07:00:06 - ERROR: failed to build lint kernel TB --- 2010-05-15 07:00:06 - 3200.38 user 331.62 system 3763.34 real http://tinderbox.freebsd.org/tinderbox-releng_7-RELENG_7-sparc64-sparc64.full From owner-freebsd-stable@FreeBSD.ORG Sat May 15 07:04:17 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2CD71106566C for ; Sat, 15 May 2010 07:04:17 +0000 (UTC) (envelope-from pieter@os3.nl) Received: from mail.thelostparadise.com (router.thelostparadise.com [IPv6:2a02:898:0:30::30:1]) by mx1.freebsd.org (Postfix) with ESMTP id C5D3B8FC0A for ; Sat, 15 May 2010 07:04:16 +0000 (UTC) Received: by mail.thelostparadise.com (Postfix, from userid 127) id 7B5CD7303B; Sat, 15 May 2010 09:04:15 +0200 (CEST) Received: from localhost by mail.thelostparadise.com (Postfix) with ESMTP id C79F373039; Sat, 15 May 2010 09:04:13 +0200 (CEST) Message-ID: <4BEE476B.6020407@os3.nl> Date: Sat, 15 May 2010 09:04:11 +0200 From: Pieter de Boer MIME-Version: 1.0 To: Jeremy Chadwick References: <4BED8B89.6010901@os3.nl> <20100514195346.GA8977@icarus.home.lan> <4BEDBC08.2040002@os3.nl> <20100514224236.GA11680@icarus.home.lan> In-Reply-To: <20100514224236.GA11680@icarus.home.lan> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: Read / write timeouts on SATA disks connected to ICH9 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 May 2010 07:04:17 -0000 Hi Jeremy, > Lots to say about all of this. Thanks for your elaborate reply, it was very useful to see smartctl output explained a bit :) I still think there's something else in play beside disk failure. I've checked one of the drives I replaced earlier, but that one doesn't have any of the errors in its SMART output you described, although it did drop out of the mirror multiple times during its lifetime. > The WD Caviar Black drives have a useful feature called TLER -- it's > disabled by default, for reasons which I don't want to get into here -- > which can force the drive to internally give up after X seconds (it's > user-selectable) when dealing with such remapping/errors. The idea is > to keep the drive from being deemed dead from the OS/controller's point > of view. I believe Seagate, Hitachi, or Samsung (I forget which) have > this feature as well, but it's not called TLER. I've read about this feature, but didn't have the time to try to get it turned on (iirc you'd need a specific Western Digital DOS-based util or something). > If you want to find out the exact LBA that has the problem (there may be > more than one), I can step you through performing a selective LBA scan > using SMART, since this model of disk does support such. It's easy to > do, easy to understand the results, and can be done while the drive is > in operation (though I would recommend trying to keep disk I/O to a > minimum during this test). Let me know. At a certain point in time I had read errors from specific LBA's on ad4. Using dd I was able to pinpoint those to single sectors. Overwriting those sectors with what was on ad6 made them readable again. What is odd is that the 'remapped sector' count of ad4 is 0. Still I'd like to know how do perform such a scan. > Finally, your vmstat -i output: > >> # vmstat -i >> interrupt total rate >> irq23: atapci0 371021299 10423 > > Good to know there's no IRQ sharing going on, but what does worry me is > the interrupt rate (10K interrupts/second). That seems *extremely* > high, but it also depends on what kind of disk I/O is happening on this > system -- especially since you have 2 disks attached to the same > controller. The rate is higher than 10000 also at idle. During a gmirror sync from ad6 to ad4, it's about 10670. > "iostat 1", "iostat -x 1", or "gstat" might come in handy to tell you > what kind of disk I/O is going on. If actual I/O is very little, then > something weird is going on with regards to the number of interrupts > being seen on IRQ 23. mav@ might have some ideas, otherwise I'd > recommend rebooting the machine and seeing if the number drops. If so, > it may be that the OS has some sort of bug where a disk timing out or > falling off the bus causes interrupt problems. (It's too bad you don't > have AHCI on this system. It handles stuff like this much more > elegantly...) If mav@ or anyone else doesn't have another insight in the interrupt rate, I guess a reboot will at least show if it's persistent or related to the errors. I'll try to do a reboot when convenient (probably sunday morning or something). Thanks, Pieter From owner-freebsd-stable@FreeBSD.ORG Sat May 15 07:14:51 2010 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 698441065670 for ; Sat, 15 May 2010 07:14:51 +0000 (UTC) (envelope-from pieter@thedarkside.nl) Received: from mail.thelostparadise.com (router.thelostparadise.com [IPv6:2a02:898:0:30::30:1]) by mx1.freebsd.org (Postfix) with ESMTP id 347908FC14 for ; Sat, 15 May 2010 07:14:51 +0000 (UTC) Received: by mail.thelostparadise.com (Postfix, from userid 127) id 5CE737303B; Sat, 15 May 2010 09:14:47 +0200 (CEST) Received: from localhost by mail.thelostparadise.com (Postfix) with ESMTP id 0FA5B73039; Sat, 15 May 2010 09:14:47 +0200 (CEST) Message-ID: <4BEE49E5.1040005@thedarkside.nl> Date: Sat, 15 May 2010 09:14:45 +0200 From: Pieter de Boer MIME-Version: 1.0 To: Terry Kennedy References: <01NN4A2NF0M4006QOF@tmk.com> In-Reply-To: <01NN4A2NF0M4006QOF@tmk.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@FreeBSD.org Subject: Re: Read / write timeouts on SATA disks connected to ICH9 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 May 2010 07:14:51 -0000 Hi Terry, > I have a bunch of R300's here. From one that is using the on-board SATA > and 2 drives in a gmirror setup (very similar to the OP) after 18 hours > of uptime: > > [0:2] speedtest:~> vmstat -i > interrupt total rate > irq23: atapci0 254116 3 Interesting. Which version of FreeBSD is this system running? I guess you didn't experience any of the timeouts I'm seeing? > I also have another R300 with Dell's "SAS 6/iR" card (a re-branded LSI > 1068-something, seen as "mpt" by FreeBSD). While Dell only sells that as > part of a package deal with the hot-swap backplane and redundant power > supplies, there's no reason you couldn't pick one up on eBay and add it > yourself. You'll need some sort of breakout cable to get from the big > connector on the SAS 6 to individual SATA ports. Yeah, this R300 was bought second-hand and unfortunately the owner pulled the RAID card out. It's something to consider, getting one of those cards. Do you use the RAID-features of the drive and if so, does that work well? I'm a bit hesitant to use hardware raid; it would be a big plus if the RAID disks could also be used stand-alone if need be (which is easy with gmirror because of its metadata being stored in the drive's last sector). Thanks, Pieter From owner-freebsd-stable@FreeBSD.ORG Sat May 15 12:48:37 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3D7CD106567B; Sat, 15 May 2010 12:48:37 +0000 (UTC) (envelope-from stb@lassitu.de) Received: from gilb.zs64.net (gilb.zs64.net [IPv6:2001:470:1f0b:105e::1ea]) by mx1.freebsd.org (Postfix) with ESMTP id 07DDF8FC0C; Sat, 15 May 2010 12:48:37 +0000 (UTC) Received: by gilb.zs64.net (Postfix, from stb@lassitu.de) id D40486133C; Sat, 15 May 2010 12:48:35 +0000 (UTC) From: Stefan Bethke Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sat, 15 May 2010 14:48:35 +0200 Message-Id: <5492BFD9-B2F9-4194-878C-6413007FAB73@lassitu.de> To: apache@FreeBSD.org Mime-Version: 1.0 (Apple Message framework v1078) X-Mailer: Apple Mail (2.1078) Cc: FreeBSD Stable Subject: www/apache22: purpose of WITHOUT_APACHE_OPTIONS? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 May 2010 12:48:37 -0000 Hi, I was quite surprised that I need to set WITHOUT_APACHE_OPTIONS to have = any command line options honored by the makefile. All other ports seem = to override the config options (that may or not may be set) with the = WITH and WITHOUT variables specifed on the make commandline or through = pkgtools.conf. What's the reason for this difference? Thanks, Stefan --=20 Stefan Bethke Fon +49 151 14070811 From owner-freebsd-stable@FreeBSD.ORG Sat May 15 13:09:45 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 789B01065673 for ; Sat, 15 May 2010 13:09:45 +0000 (UTC) (envelope-from pieter@os3.nl) Received: from mail.thelostparadise.com (router.thelostparadise.com [IPv6:2a02:898:0:30::30:1]) by mx1.freebsd.org (Postfix) with ESMTP id 1EE218FC15 for ; Sat, 15 May 2010 13:09:45 +0000 (UTC) Received: by mail.thelostparadise.com (Postfix, from userid 127) id E829B73054; Sat, 15 May 2010 15:09:43 +0200 (CEST) Received: from localhost by mail.thelostparadise.com (Postfix) with ESMTP id 9D03073008; Sat, 15 May 2010 15:09:41 +0200 (CEST) Message-ID: <4BEE9D13.9060702@os3.nl> Date: Sat, 15 May 2010 15:09:39 +0200 From: Pieter de Boer MIME-Version: 1.0 To: Jeremy Chadwick References: <4BED8B89.6010901@os3.nl> <20100514195346.GA8977@icarus.home.lan> <4BEDBC08.2040002@os3.nl> <20100514224236.GA11680@icarus.home.lan> In-Reply-To: <20100514224236.GA11680@icarus.home.lan> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: Read / write timeouts on SATA disks connected to ICH9 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 May 2010 13:09:45 -0000 Hi there, > what kind of disk I/O is going on. If actual I/O is very little, then > something weird is going on with regards to the number of interrupts > being seen on IRQ 23. mav@ might have some ideas, otherwise I'd > recommend rebooting the machine and seeing if the number drops. If so, > it may be that the OS has some sort of bug where a disk timing out or > falling off the bus causes interrupt problems. (It's too bad you don't > have AHCI on this system. It handles stuff like this much more > elegantly...) Well, due to a UFS snapshot panic the box was rebooted, and now I only see around 1500 interrupts per second, while syncing the mirror. -- Pieter From owner-freebsd-stable@FreeBSD.ORG Sat May 15 14:30:33 2010 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B1E6410656C4 for ; Sat, 15 May 2010 14:30:33 +0000 (UTC) (envelope-from TERRY@tmk.com) Received: from server.tmk.com (server.tmk.com [204.141.35.63]) by mx1.freebsd.org (Postfix) with ESMTP id 8CA738FC0C for ; Sat, 15 May 2010 14:30:33 +0000 (UTC) Received: from tmk.com by tmk.com (PMDF V6.4 #37010) id <01NN548EB31C006UN1@tmk.com> for freebsd-stable@FreeBSD.org; Sat, 15 May 2010 10:30:31 -0400 (EDT) Date: Sat, 15 May 2010 10:22:26 -0400 (EDT) From: Terry Kennedy In-reply-to: "Your message dated Sat, 15 May 2010 09:14:45 +0200" <4BEE49E5.1040005@thedarkside.nl> To: Pieter de Boer Message-id: <01NN54IPR7I0006UN1@tmk.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=UTF-8; format=flowed References: <01NN4A2NF0M4006QOF@tmk.com> Cc: freebsd-stable@FreeBSD.org Subject: Re: Read / write timeouts on SATA disks connected to ICH9 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 May 2010 14:30:33 -0000 > Interesting. Which version of FreeBSD is this system running? I guess > you didn't experience any of the timeouts I'm seeing? 8-STABLE as of the 11th of this month, or thereabouts. No, I've never seen a disk timeout on that box. > Yeah, this R300 was bought second-hand and unfortunately the owner > pulled the RAID card out. It's something to consider, getting one of > those cards. Do you use the RAID-features of the drive and if so, does > that work well? I'm a bit hesitant to use hardware raid; it would be a > big plus if the RAID disks could also be used stand-alone if need be > (which is easy with gmirror because of its metadata being stored in the > drive's last sector). Does your system have hot-swap drive bays and the SAS backplane? If it at least has hot-swap bays, then you could always add the backplane, cable, and controller. I'm using the hardware mirroring on the SAS 6/iR card (with a pair of WD3000HLFS drives, since the previous owner took the factory drives out before selling the system). I haven't tried taking one of those drives and seeing if it will boot on a standalone SATA port. I have removed both drives, installed a scratch drive, and installed Windows on it to run one of the Dell update install- ers (not all of them come in DOS or Linux flavors). The controller didn't mind the swap a bit (or the swap back to the 2 RAID drives). That's a lot better than the old amr-based RAID cards. Terry Kennedy http://www.tmk.com terry@tmk.com New York, NY USA From owner-freebsd-stable@FreeBSD.ORG Sat May 15 16:18:53 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A817E106566C for ; Sat, 15 May 2010 16:18:53 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [94.124.105.4]) by mx1.freebsd.org (Postfix) with ESMTP id 5F4858FC18 for ; Sat, 15 May 2010 16:18:52 +0000 (UTC) Received: from elsa.codelab.cz (localhost.codelab.cz [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id 4E67B19E027; Sat, 15 May 2010 18:18:51 +0200 (CEST) Received: from [192.168.1.2] (r5bb235.net.upc.cz [86.49.61.235]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id 0EC7119E023; Sat, 15 May 2010 18:18:49 +0200 (CEST) Message-ID: <4BEEC968.3050704@quip.cz> Date: Sat, 15 May 2010 18:18:48 +0200 From: Miroslav Lachman <000.fbsd@quip.cz> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.1.9) Gecko/20100317 SeaMonkey/2.0.4 MIME-Version: 1.0 To: Pieter de Boer References: <4BED8B89.6010901@os3.nl> <20100514195346.GA8977@icarus.home.lan> <4BEDBC08.2040002@os3.nl> <20100514224236.GA11680@icarus.home.lan> <4BEE9D13.9060702@os3.nl> In-Reply-To: <4BEE9D13.9060702@os3.nl> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org, Jeremy Chadwick Subject: Re: Read / write timeouts on SATA disks connected to ICH9 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 May 2010 16:18:53 -0000 Pieter de Boer wrote: > Hi there, > >> what kind of disk I/O is going on. If actual I/O is very little, then >> something weird is going on with regards to the number of interrupts >> being seen on IRQ 23. mav@ might have some ideas, otherwise I'd >> recommend rebooting the machine and seeing if the number drops. If so, >> it may be that the OS has some sort of bug where a disk timing out or >> falling off the bus causes interrupt problems. (It's too bad you don't >> have AHCI on this system. It handles stuff like this much more >> elegantly...) > Well, due to a UFS snapshot panic the box was rebooted, and now I only > see around 1500 interrupts per second, while syncing the mirror. I seen high interrupts on 7.x systems after pulling out/in one drive in gmirror [1] even if it was successfully disconnected by gmirror remove + atacontrol detach and reconnected by atacontrol attach + gmirror insert. It was not 100% reproducible, but it seems the bug is still there in 8.x. [1] http://lists.freebsd.org/pipermail/freebsd-stable/2008-October/046003.html Miroslav Lachman From owner-freebsd-stable@FreeBSD.ORG Sat May 15 16:26:28 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 16774106566C for ; Sat, 15 May 2010 16:26:28 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [76.96.62.24]) by mx1.freebsd.org (Postfix) with ESMTP id B71AF8FC1D for ; Sat, 15 May 2010 16:26:27 +0000 (UTC) Received: from omta17.westchester.pa.mail.comcast.net ([76.96.62.89]) by qmta02.westchester.pa.mail.comcast.net with comcast id HsMC1e0021vXlb852sSTJ3; Sat, 15 May 2010 16:26:27 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta17.westchester.pa.mail.comcast.net with comcast id HsSS1e0023S48mS3dsSS8g; Sat, 15 May 2010 16:26:27 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id B838E9B419; Sat, 15 May 2010 09:26:24 -0700 (PDT) Date: Sat, 15 May 2010 09:26:24 -0700 From: Jeremy Chadwick To: Pieter de Boer Message-ID: <20100515162624.GA39585@icarus.home.lan> References: <4BED8B89.6010901@os3.nl> <20100514195346.GA8977@icarus.home.lan> <4BEDBC08.2040002@os3.nl> <20100514224236.GA11680@icarus.home.lan> <4BEE476B.6020407@os3.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4BEE476B.6020407@os3.nl> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-stable@freebsd.org Subject: Re: Read / write timeouts on SATA disks connected to ICH9 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 May 2010 16:26:28 -0000 On Sat, May 15, 2010 at 09:04:11AM +0200, Pieter de Boer wrote: > Thanks for your elaborate reply, it was very useful to see smartctl > output explained a bit :) I still think there's something else in > play beside disk failure. I've checked one of the drives I replaced > earlier, but that one doesn't have any of the errors in its SMART > output you described, although it did drop out of the mirror > multiple times during its lifetime. That could be caused by a multitude of other known things. For example, some Western Digital "Green" drives (including the Enterprise class ones) are known to perform head parking/offloading excessively, which could result in the drive spending more time doing that than actually serving overall I/O requests. There are some other reports of Samsung Spinpoint drives experiencing other issues (I've since forgotten and would have to dig up the threads). If you could provide full SMART stats for that drive, it might help. > >The WD Caviar Black drives have a useful feature called TLER -- it's > >disabled by default, for reasons which I don't want to get into here -- > >which can force the drive to internally give up after X seconds (it's > >user-selectable) when dealing with such remapping/errors. The idea is > >to keep the drive from being deemed dead from the OS/controller's point > >of view. I believe Seagate, Hitachi, or Samsung (I forget which) have > >this feature as well, but it's not called TLER. > > I've read about this feature, but didn't have the time to try to get > it turned on (iirc you'd need a specific Western Digital DOS-based > util or something). Yes, it's a DOS-based utility (like most firmware upgraders these days). I can provide it if you'd like. I've been meaning to spend some time trying to reverse-engineer the binary to figure out what ATA commands it sends to the disk to toggle/adjust the feature (so that one could do it in real-time rather than have to boot into DOS). > >If you want to find out the exact LBA that has the problem (there may be > >more than one), I can step you through performing a selective LBA scan > >using SMART, since this model of disk does support such. It's easy to > >do, easy to understand the results, and can be done while the drive is > >in operation (though I would recommend trying to keep disk I/O to a > >minimum during this test). Let me know. > > At a certain point in time I had read errors from specific LBA's on > ad4. Using dd I was able to pinpoint those to single sectors. This isn't very effective (dd will read large chunks/amounts of data (read: multiple LBAs) from the underlying disk at once, rather than the disk itself performing a per-LBA test). My opinion is that the "dd method" should only be used on drives which don't support selective LBA scanning via SMART. > Overwriting those sectors with what was on ad6 made them readable > again. What is odd is that the 'remapped sector' count of ad4 is 0. What may have happened is that the drive took a while to read certain LBAs (long enough for the OS/controller to time out), but that internal drive ECC was used to correct the reads and the sectors therefore *did not* need to be remapped. I do see that Attribute 1 on ad4 is non-zero, which could indicate said situation, but WD doesn't provide Attribute 195 (ECC recovery rate), which could help here. SMART implementations are usually quite good (particularly in recent WD drives), but I have seen situations where certain counters are, erroneously, not being incremented or changed. I've seen a couple brand new disks come out of the factory with non-zero values (indicating someone at the fab forgot to clear them before shipping). I'd love to get my hands on a WD utility that zeros out the counters and re-flashes the drive firmware to rule out any oddities. It's been proven already that WD will re-uses the same F/W version number despite some code being changed. There was a FreeBSD user who got a F/W fix from WD for the head offloading/parking ordeal (see above, re: WD GP), and the firmware version between the old and the new were the same. Tracking stuff like this down is basically impossible unless MD5/SHAs of the firmware files can be provided (good luck). All HD vendors have their own quirks/ordeals right now. You basically just have to go with one who works wells for you, then if things start going downhill, switch to another. None of them are perfect. > Still I'd like to know how do perform such a scan. smartctl -t select,0-max This will start a selective LBA scan from LBA 0 to the end of the disk. If any error is encountered, the scan stops and the error -- including the LBA where an error was seen -- is output in the SMART self-test and SMART selective self-test logs. You can then write down the LBA, and then re-run the above command replacing "0" with the LBA+1 where the error was seen. Here's an example of what a failed selective scan looks like (taken from a Hitachi disk I just dealt with at work a few weeks ago, starting at LBA 100000): === START OF READ SMART DATA SECTION === SMART Self-test log structure revision number 1 Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error # 1 Selective offline Completed: read failure 90% 4931 6153934 SMART Selective self-test log data structure revision number 1 SPAN MIN_LBA MAX_LBA CURRENT_TEST_STATUS 1 100000 1953525167 Completed_read_failure [90% left] (6153934-6219469) > >># vmstat -i > >>interrupt total rate > >>irq23: atapci0 371021299 10423 > > The rate is higher than 10000 also at idle. During a gmirror sync > from ad6 to ad4, it's about 10670. In your other post, we determined that your interrupt rate dropped to a completely normal value (1500 during a gmirror scan or rebuild) after a system reboot. I'm not surprised a reboot addressed it (for now...). What this indicates to me is that if a disk falls off the bus on an ICH9 controller in Enhanced (non-AHCI) mode, FreeBSD starts seeing an absurd number of interrupts generated from the ICH9. My guess is FreeBSD isn't doing something correctly with the controller when this happens; maybe certain commands aren't being sent back to the controller or handling of certain events are being done improperly when it comes to ICH9 (or possibly earlier ICH revisions too). This should be *very* easy to reproduce. > >"iostat 1", "iostat -x 1", or "gstat" might come in handy to tell you > >what kind of disk I/O is going on. If actual I/O is very little, then > >something weird is going on with regards to the number of interrupts > >being seen on IRQ 23. mav@ might have some ideas, otherwise I'd > >recommend rebooting the machine and seeing if the number drops. If so, > >it may be that the OS has some sort of bug where a disk timing out or > >falling off the bus causes interrupt problems. (It's too bad you don't > >have AHCI on this system. It handles stuff like this much more > >elegantly...) > If mav@ or anyone else doesn't have another insight in the interrupt > rate, I guess a reboot will at least show if it's persistent or > related to the errors. I'll try to do a reboot when convenient > (probably sunday morning or something). If you see any of your disks on the ICH9 controller fall off the bus or report ATA errors (doesn't matter what kind), please make note of the timestamp (should be in the kernel log), and ASAP run "smartctl -a" on the disk. You should compare attributes before and after the event. You might also want to consider using smartd, which can log SMART attribute changes on its own. Note that you might have to tune the arguments in smartd.conf to ignore some attributes which fluctuate naturally (such as drive temperature and seek error rate). -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Sat May 15 19:12:57 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E90C6106566C; Sat, 15 May 2010 19:12:56 +0000 (UTC) (envelope-from jamesbrandongooch@gmail.com) Received: from mail-pv0-f182.google.com (mail-pv0-f182.google.com [74.125.83.182]) by mx1.freebsd.org (Postfix) with ESMTP id A23438FC21; Sat, 15 May 2010 19:12:56 +0000 (UTC) Received: by pvh11 with SMTP id 11so1719811pvh.13 for ; Sat, 15 May 2010 12:12:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=ZUBcEnge1gD0DivkJ5PsZ4gtoLXOIEuzwNlcJ1igj6E=; b=e9+HdlTWdA7S6bJ6wzZBlVii9O/KIZKo/VrUfgvnBAlJIxx6BCLdrDRAfv1gE+8st0 lTRCS8glkPypKAr2RKdfFL8+XaTid0o9TbYyU816BbK+1+O2qR/K8OKH/wo+ILKRUInL mg/N94gEdDzS1KyKZRujvL4t66HnCh3w37ldI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=jfwoAxREqkadS0zveGWkC4Z6vtQHTVuYxKE1m1aDVFGWLtoy7jaQHveNbNl7lSi/zZ qfUnoSRWSNAN9J20nHGIYgJvsIAxqWq7qBD8kpxMftrsIC411yy5ny28oGqoPTDaJhx1 tlxBv6BnIxc2wCqt/3htmWTHwR+TGWh0gDv2E= MIME-Version: 1.0 Received: by 10.143.24.25 with SMTP id b25mr2012450wfj.90.1273950776065; Sat, 15 May 2010 12:12:56 -0700 (PDT) Received: by 10.142.52.15 with HTTP; Sat, 15 May 2010 12:12:56 -0700 (PDT) In-Reply-To: References: <4DEBDE2C-C0D2-469D-AC42-DD5027926424@FreeBSD.org> <1273257226.1671.3.camel@malikania.fr> Date: Sat, 15 May 2010 14:12:56 -0500 Message-ID: From: Brandon Gooch To: Giovanni Trematerra Content-Type: text/plain; charset=ISO-8859-1 Cc: Attilio Rao , David DEMELIER , freebsd-acpi@freebsd.org, freebsd-stable@freebsd.org Subject: Re: Kernel panic when unpluggin AC adaptor X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 May 2010 19:12:57 -0000 On Thu, May 13, 2010 at 7:25 PM, Giovanni Trematerra wrote: > On Thu, May 13, 2010 at 1:09 AM, Brandon Gooch > wrote: >> On Wed, May 12, 2010 at 9:41 AM, Attilio Rao wrote: >>> 2010/5/12 David DEMELIER : >>>> I remove the patch, and built the kernel (I updated the src this >>>> morning) and it does not panic now. It's really odd. If it reappears >>>> soon I will tell you. >>> >>> I looked at the code with Giovanni and I have the feeling that the >>> race with the idle thread may still be fatal. >>> We need to fix that. >>> >>> Attilio >>> >> >> That seems to be the case, as my laptop shows about an 80-85 % chance >> of experiencing a panic if left idle for long-ish periods of time (2 >> to 4 hours). I usually rebuild world or big ports overnight, and more >> often than not I wake up to a panicked machine, same situation every >> time: >> >> ... >> rman_get_bushandle() at rman_get_bushandle+0x1 >> sched_idletd() at sched_idletd+0x123 >> fork_exit() at fork_exit+0x12a >> fork_trampoline() at fork_trampoline+0xe >> ... >> >> The kernel/userland is rebuilt, the ports are finished compiling -- >> it's in the time AFTER the completion of all tasks that the machine >> gets bored and tries to kill itself :) >> >> I have seen the AC adapter plug/unplug "hang" in the past on this >> laptop, but I never made the connection between the events, as >> nowadays my laptop usually stays plugged in :( >> >> Attilio, I hope you can track this one down, let me know if I can do >> anything to help or test... >> > > Attilio and I came up with this patch. It seems ready for stress > testing and review > Please test and report back. > > Thank you > > P.S: all the faults are only mine. I tried the patch, and my kernel panics I panic on boot. I have 8.5MB(!) of JPG images (6 of them) if anyone needs to see them. I'm looking for a place to post them, but if anyone wants, I can send via e-mail... -Brandon From owner-freebsd-stable@FreeBSD.ORG Sat May 15 20:39:17 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EB60B106564A for ; Sat, 15 May 2010 20:39:17 +0000 (UTC) (envelope-from pieter@os3.nl) Received: from mail.thelostparadise.com (router.thelostparadise.com [IPv6:2a02:898:0:30::30:1]) by mx1.freebsd.org (Postfix) with ESMTP id 469E98FC0A for ; Sat, 15 May 2010 20:39:17 +0000 (UTC) Received: by mail.thelostparadise.com (Postfix, from userid 127) id 25E2C73061; Sat, 15 May 2010 22:39:16 +0200 (CEST) Received: from localhost by mail.thelostparadise.com (Postfix) with ESMTP id 854B573038; Sat, 15 May 2010 22:39:15 +0200 (CEST) Message-ID: <4BEF066F.3090703@os3.nl> Date: Sat, 15 May 2010 22:39:11 +0200 From: Pieter de Boer MIME-Version: 1.0 To: Jeremy Chadwick References: <4BED8B89.6010901@os3.nl> <20100514195346.GA8977@icarus.home.lan> <4BEDBC08.2040002@os3.nl> <20100514224236.GA11680@icarus.home.lan> <4BEE476B.6020407@os3.nl> <20100515162624.GA39585@icarus.home.lan> In-Reply-To: <20100515162624.GA39585@icarus.home.lan> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: Read / write timeouts on SATA disks connected to ICH9 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 May 2010 20:39:18 -0000 Hi, > That could be caused by a multitude of other known things. For > example, some Western Digital "Green" drives (including the > Enterprise class ones) are known to perform head parking/offloading > excessively, which could result in the drive spending more time doing > that than actually serving overall I/O requests. There are some > other reports of Samsung Spinpoint drives experiencing other issues > (I've since forgotten and would have to dig up the threads). > If you could provide full SMART stats for that drive, it might help. Attached the SMART output of both disks I replaced about a month ago. It appears I replaced perfectly fine drives with the current disks with errors ;( One of the old disks is in a USB-enclosure now, so 'da0'. > Yes, it's a DOS-based utility (like most firmware upgraders these > days). I can provide it if you'd like. I've been meaning to spend > some time trying to reverse-engineer the binary to figure out what > ATA commands it sends to the disk to toggle/adjust the feature (so > that one could do it in real-time rather than have to boot into DOS). > I'd like to try that tool. Since the old WD disks are now lying around at home, I have some time to get a DOS boot working to try it out. A FreeBSD-implementation of the WD tool and possibly other brands would be really useful indeed. >> At a certain point in time I had read errors from specific LBA's on >> ad4. Using dd I was able to pinpoint those to single sectors. > This isn't very effective (dd will read large chunks/amounts of data > (read: multiple LBAs) from the underlying disk at once, rather than > the disk itself performing a per-LBA test). My opinion is that the > "dd method" should only be used on drives which don't support > selective LBA scanning via SMART. Will dd read multiple LBAs even when using 'bs=512'? The process I used was reading using bs=8192, then zooming in on the LBA's mentioned in the errors in dmesg with bs=512 to find the actual LBA. A selective scan on ad4 did not reveal any errors today: it 'completed without error'. On ad6 it's a whole lot slower; at the time of writing it's at 2/3. > All HD vendors have their own quirks/ordeals right now. You > basically just have to go with one who works wells for you, then if > things start going downhill, switch to another. None of them are > perfect. I figured as much. What irritates though is that I've had consistent problems with 4 disks in this specific system, but not (such) issues with any other disk in other systems I've had. I generally replace disks when I grow out of them, not because they break down. > What this indicates to me is that if a disk falls off the bus on an > ICH9 controller in Enhanced (non-AHCI) mode, FreeBSD starts seeing an > absurd number of interrupts generated from the ICH9. My guess is > FreeBSD isn't doing something correctly with the controller when this > happens; maybe certain commands aren't being sent back to the > controller or handling of certain events are being done improperly > when it comes to ICH9 (or possibly earlier ICH revisions too). This > should be *very* easy to reproduce. Unfortunately I'm not really in a position to help reproducing this or testing possible fixes; downtime is currently very unwelcome. Although one of the previous disks indeed fell of the bus entirely (couldn't get it back with atacontrol either), that hasn't happened again so far. I only see timeouts (and a few days ago read errors on ad4) which gmirror doesn't like. I guess those aren't that simple to reproduce (apart from on my system ;). > If you see any of your disks on the ICH9 controller fall off the bus > or report ATA errors (doesn't matter what kind), please make note of > the timestamp (should be in the kernel log), and ASAP run "smartctl > -a" on the disk. You should compare attributes before and after the > event. > You might also want to consider using smartd, which can log SMART > attribute changes on its own. Note that you might have to tune the > arguments in smartd.conf to ignore some attributes which fluctuate > naturally (such as drive temperature and seek error rate). I've configured smartd to poll both disks every 5 minutes. I -think- the issues happen specifically under load: the periodic scripts of the host and its 4 jails appear to trigger it sometimes. At that time I'm normally trying to get some sleep, so smartd will have to do for now. Although I'll run a "smartctl -a" asap anyway. -- Pieter From owner-freebsd-stable@FreeBSD.ORG Sat May 15 21:16:37 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1ED1F1065670 for ; Sat, 15 May 2010 21:16:37 +0000 (UTC) (envelope-from pieter@thedarkside.nl) Received: from mail.thelostparadise.com (router.thelostparadise.com [IPv6:2a02:898:0:30::30:1]) by mx1.freebsd.org (Postfix) with ESMTP id 1DE628FC16 for ; Sat, 15 May 2010 21:16:36 +0000 (UTC) Received: by mail.thelostparadise.com (Postfix, from userid 127) id 13FBD73054; Sat, 15 May 2010 23:16:35 +0200 (CEST) Received: from localhost by mail.thelostparadise.com (Postfix) with ESMTP id 74A3673008; Sat, 15 May 2010 23:16:34 +0200 (CEST) Message-ID: <4BEF0F31.9050405@thedarkside.nl> Date: Sat, 15 May 2010 23:16:33 +0200 From: Pieter de Boer MIME-Version: 1.0 To: Jeremy Chadwick References: <4BED8B89.6010901@os3.nl> <20100514195346.GA8977@icarus.home.lan> <4BEDBC08.2040002@os3.nl> <20100514224236.GA11680@icarus.home.lan> <4BEE476B.6020407@os3.nl> <20100515162624.GA39585@icarus.home.lan> <4BEF066F.3090703@os3.nl> In-Reply-To: <4BEF066F.3090703@os3.nl> Content-Type: multipart/mixed; boundary="------------050404000100060209050409" Cc: freebsd-stable@freebsd.org Subject: Re: Read / write timeouts on SATA disks connected to ICH9 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 May 2010 21:16:37 -0000 This is a multi-part message in MIME format. --------------050404000100060209050409 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit > Attached the SMART output of both disks I replaced about a month ago. It > appears I replaced perfectly fine drives with the current disks with > errors ;( One of the old disks is in a USB-enclosure now, so 'da0'. Let's send those attachments, then. -- Pieter --------------050404000100060209050409 Content-Type: text/plain; name="smartctl-disk1.txt" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="smartctl-disk1.txt" c21hcnRjdGwgNS4zOSAyMDA5LTEyLTA5IHIyOTk1IFtGcmVlQlNEIDguMC1TVEFCTEUgaTM4 Nl0gKGxvY2FsIGJ1aWxkKQpDb3B5cmlnaHQgKEMpIDIwMDItOSBieSBCcnVjZSBBbGxlbiwg aHR0cDovL3NtYXJ0bW9udG9vbHMuc291cmNlZm9yZ2UubmV0Cgo9PT0gU1RBUlQgT0YgSU5G T1JNQVRJT04gU0VDVElPTiA9PT0KTW9kZWwgRmFtaWx5OiAgICAgV2VzdGVybiBEaWdpdGFs IFJFMyBTZXJpYWwgQVRBIGZhbWlseQpEZXZpY2UgTW9kZWw6ICAgICBXREMgV0Q1MDAyQUJZ Uy0xOEIxQjAKU2VyaWFsIE51bWJlcjogICAgV0QtV01BU1k1NDc0MDg5CkZpcm13YXJlIFZl cnNpb246IDAyLjAzQjAzClVzZXIgQ2FwYWNpdHk6ICAgIDUwMCwxMDcsODYyLDAxNiBieXRl cwpEZXZpY2UgaXM6ICAgICAgICBJbiBzbWFydGN0bCBkYXRhYmFzZSBbZm9yIGRldGFpbHMg dXNlOiAtUCBzaG93XQpBVEEgVmVyc2lvbiBpczogICA4CkFUQSBTdGFuZGFyZCBpczogIEV4 YWN0IEFUQSBzcGVjaWZpY2F0aW9uIGRyYWZ0IHZlcnNpb24gbm90IGluZGljYXRlZApMb2Nh bCBUaW1lIGlzOiAgICBTYXQgTWF5IDE1IDIxOjUzOjA0IDIwMTAgQ0VTVApTTUFSVCBzdXBw b3J0IGlzOiBBdmFpbGFibGUgLSBkZXZpY2UgaGFzIFNNQVJUIGNhcGFiaWxpdHkuClNNQVJU IHN1cHBvcnQgaXM6IEVuYWJsZWQKCj09PSBTVEFSVCBPRiBSRUFEIFNNQVJUIERBVEEgU0VD VElPTiA9PT0KU01BUlQgb3ZlcmFsbC1oZWFsdGggc2VsZi1hc3Nlc3NtZW50IHRlc3QgcmVz dWx0OiBQQVNTRUQKCkdlbmVyYWwgU01BUlQgVmFsdWVzOgpPZmZsaW5lIGRhdGEgY29sbGVj dGlvbiBzdGF0dXM6ICAoMHg4MikJT2ZmbGluZSBkYXRhIGNvbGxlY3Rpb24gYWN0aXZpdHkK CQkJCQl3YXMgY29tcGxldGVkIHdpdGhvdXQgZXJyb3IuCgkJCQkJQXV0byBPZmZsaW5lIERh dGEgQ29sbGVjdGlvbjogRW5hYmxlZC4KU2VsZi10ZXN0IGV4ZWN1dGlvbiBzdGF0dXM6ICAg ICAgKCAgIDApCVRoZSBwcmV2aW91cyBzZWxmLXRlc3Qgcm91dGluZSBjb21wbGV0ZWQKCQkJ CQl3aXRob3V0IGVycm9yIG9yIG5vIHNlbGYtdGVzdCBoYXMgZXZlciAKCQkJCQliZWVuIHJ1 bi4KVG90YWwgdGltZSB0byBjb21wbGV0ZSBPZmZsaW5lIApkYXRhIGNvbGxlY3Rpb246IAkJ ICg5NDgwKSBzZWNvbmRzLgpPZmZsaW5lIGRhdGEgY29sbGVjdGlvbgpjYXBhYmlsaXRpZXM6 IAkJCSAoMHg3YikgU01BUlQgZXhlY3V0ZSBPZmZsaW5lIGltbWVkaWF0ZS4KCQkJCQlBdXRv IE9mZmxpbmUgZGF0YSBjb2xsZWN0aW9uIG9uL29mZiBzdXBwb3J0LgoJCQkJCVN1c3BlbmQg T2ZmbGluZSBjb2xsZWN0aW9uIHVwb24gbmV3CgkJCQkJY29tbWFuZC4KCQkJCQlPZmZsaW5l IHN1cmZhY2Ugc2NhbiBzdXBwb3J0ZWQuCgkJCQkJU2VsZi10ZXN0IHN1cHBvcnRlZC4KCQkJ CQlDb252ZXlhbmNlIFNlbGYtdGVzdCBzdXBwb3J0ZWQuCgkJCQkJU2VsZWN0aXZlIFNlbGYt dGVzdCBzdXBwb3J0ZWQuClNNQVJUIGNhcGFiaWxpdGllczogICAgICAgICAgICAoMHgwMDAz KQlTYXZlcyBTTUFSVCBkYXRhIGJlZm9yZSBlbnRlcmluZwoJCQkJCXBvd2VyLXNhdmluZyBt b2RlLgoJCQkJCVN1cHBvcnRzIFNNQVJUIGF1dG8gc2F2ZSB0aW1lci4KRXJyb3IgbG9nZ2lu ZyBjYXBhYmlsaXR5OiAgICAgICAgKDB4MDEpCUVycm9yIGxvZ2dpbmcgc3VwcG9ydGVkLgoJ CQkJCUdlbmVyYWwgUHVycG9zZSBMb2dnaW5nIHN1cHBvcnRlZC4KU2hvcnQgc2VsZi10ZXN0 IHJvdXRpbmUgCnJlY29tbWVuZGVkIHBvbGxpbmcgdGltZTogCSAoICAgMikgbWludXRlcy4K RXh0ZW5kZWQgc2VsZi10ZXN0IHJvdXRpbmUKcmVjb21tZW5kZWQgcG9sbGluZyB0aW1lOiAJ ICggMTEyKSBtaW51dGVzLgpDb252ZXlhbmNlIHNlbGYtdGVzdCByb3V0aW5lCnJlY29tbWVu ZGVkIHBvbGxpbmcgdGltZTogCSAoICAgNSkgbWludXRlcy4KU0NUIGNhcGFiaWxpdGllczog CSAgICAgICAoMHgzMDNmKQlTQ1QgU3RhdHVzIHN1cHBvcnRlZC4KCQkJCQlTQ1QgRmVhdHVy ZSBDb250cm9sIHN1cHBvcnRlZC4KCQkJCQlTQ1QgRGF0YSBUYWJsZSBzdXBwb3J0ZWQuCgpT TUFSVCBBdHRyaWJ1dGVzIERhdGEgU3RydWN0dXJlIHJldmlzaW9uIG51bWJlcjogMTYKVmVu ZG9yIFNwZWNpZmljIFNNQVJUIEF0dHJpYnV0ZXMgd2l0aCBUaHJlc2hvbGRzOgpJRCMgQVRU UklCVVRFX05BTUUgICAgICAgICAgRkxBRyAgICAgVkFMVUUgV09SU1QgVEhSRVNIIFRZUEUg ICAgICBVUERBVEVEICBXSEVOX0ZBSUxFRCBSQVdfVkFMVUUKICAxIFJhd19SZWFkX0Vycm9y X1JhdGUgICAgIDB4MDAyZiAgIDIwMCAgIDIwMCAgIDA1MSAgICBQcmUtZmFpbCAgQWx3YXlz ICAgICAgIC0gICAgICAgMAogIDMgU3Bpbl9VcF9UaW1lICAgICAgICAgICAgMHgwMDI3ICAg MTc5ICAgMTc5ICAgMDIxICAgIFByZS1mYWlsICBBbHdheXMgICAgICAgLSAgICAgICA0MDMz CiAgNCBTdGFydF9TdG9wX0NvdW50ICAgICAgICAweDAwMzIgICAxMDAgICAxMDAgICAwMDAg ICAgT2xkX2FnZSAgIEFsd2F5cyAgICAgICAtICAgICAgIDg5CiAgNSBSZWFsbG9jYXRlZF9T ZWN0b3JfQ3QgICAweDAwMzMgICAyMDAgICAyMDAgICAxNDAgICAgUHJlLWZhaWwgIEFsd2F5 cyAgICAgICAtICAgICAgIDAKICA3IFNlZWtfRXJyb3JfUmF0ZSAgICAgICAgIDB4MDAyZSAg IDIwMCAgIDIwMCAgIDAwMCAgICBPbGRfYWdlICAgQWx3YXlzICAgICAgIC0gICAgICAgMAog IDkgUG93ZXJfT25fSG91cnMgICAgICAgICAgMHgwMDMyICAgMDkzICAgMDkzICAgMDAwICAg IE9sZF9hZ2UgICBBbHdheXMgICAgICAgLSAgICAgICA1NTM2CiAxMCBTcGluX1JldHJ5X0Nv dW50ICAgICAgICAweDAwMzIgICAxMDAgICAyNTMgICAwMDAgICAgT2xkX2FnZSAgIEFsd2F5 cyAgICAgICAtICAgICAgIDAKIDExIENhbGlicmF0aW9uX1JldHJ5X0NvdW50IDB4MDAzMiAg IDEwMCAgIDI1MyAgIDAwMCAgICBPbGRfYWdlICAgQWx3YXlzICAgICAgIC0gICAgICAgMAog MTIgUG93ZXJfQ3ljbGVfQ291bnQgICAgICAgMHgwMDMyICAgMTAwICAgMTAwICAgMDAwICAg IE9sZF9hZ2UgICBBbHdheXMgICAgICAgLSAgICAgICA3NAoxOTIgUG93ZXItT2ZmX1JldHJh Y3RfQ291bnQgMHgwMDMyICAgMjAwICAgMjAwICAgMDAwICAgIE9sZF9hZ2UgICBBbHdheXMg ICAgICAgLSAgICAgICA3MQoxOTMgTG9hZF9DeWNsZV9Db3VudCAgICAgICAgMHgwMDMyICAg MjAwICAgMjAwICAgMDAwICAgIE9sZF9hZ2UgICBBbHdheXMgICAgICAgLSAgICAgICA4OQox OTQgVGVtcGVyYXR1cmVfQ2Vsc2l1cyAgICAgMHgwMDIyICAgMTAwICAgMDk0ICAgMDAwICAg IE9sZF9hZ2UgICBBbHdheXMgICAgICAgLSAgICAgICA0NwoxOTYgUmVhbGxvY2F0ZWRfRXZl bnRfQ291bnQgMHgwMDMyICAgMjAwICAgMjAwICAgMDAwICAgIE9sZF9hZ2UgICBBbHdheXMg ICAgICAgLSAgICAgICAwCjE5NyBDdXJyZW50X1BlbmRpbmdfU2VjdG9yICAweDAwMzIgICAy MDAgICAyMDAgICAwMDAgICAgT2xkX2FnZSAgIEFsd2F5cyAgICAgICAtICAgICAgIDAKMTk4 IE9mZmxpbmVfVW5jb3JyZWN0YWJsZSAgIDB4MDAzMCAgIDIwMCAgIDIwMCAgIDAwMCAgICBP bGRfYWdlICAgT2ZmbGluZSAgICAgIC0gICAgICAgMAoxOTkgVURNQV9DUkNfRXJyb3JfQ291 bnQgICAgMHgwMDMyICAgMjAwICAgMjAwICAgMDAwICAgIE9sZF9hZ2UgICBBbHdheXMgICAg ICAgLSAgICAgICAwCjIwMCBNdWx0aV9ab25lX0Vycm9yX1JhdGUgICAweDAwMDggICAyMDAg ICAyMDAgICAwMDAgICAgT2xkX2FnZSAgIE9mZmxpbmUgICAgICAtICAgICAgIDAKClNNQVJU IEVycm9yIExvZyBWZXJzaW9uOiAxCk5vIEVycm9ycyBMb2dnZWQKClNNQVJUIFNlbGYtdGVz dCBsb2cgc3RydWN0dXJlIHJldmlzaW9uIG51bWJlciAxCk51bSAgVGVzdF9EZXNjcmlwdGlv biAgICBTdGF0dXMgICAgICAgICAgICAgICAgICBSZW1haW5pbmcgIExpZmVUaW1lKGhvdXJz KSAgTEJBX29mX2ZpcnN0X2Vycm9yCiMgMSAgRXh0ZW5kZWQgb2ZmbGluZSAgICBDb21wbGV0 ZWQgd2l0aG91dCBlcnJvciAgICAgICAwMCUgICAgICA1NDg3ICAgICAgICAgLQojIDIgIEV4 dGVuZGVkIG9mZmxpbmUgICAgQ29tcGxldGVkIHdpdGhvdXQgZXJyb3IgICAgICAgMDAlICAg ICAgNDkyNSAgICAgICAgIC0KIyAzICBTaG9ydCBvZmZsaW5lICAgICAgIENvbXBsZXRlZCB3 aXRob3V0IGVycm9yICAgICAgIDAwJSAgICAgIDQ5MjMgICAgICAgICAtCiMgNCAgU2hvcnQg b2ZmbGluZSAgICAgICBDb21wbGV0ZWQgd2l0aG91dCBlcnJvciAgICAgICAwMCUgICAgICAy ODMzICAgICAgICAgLQojIDUgIFNob3J0IG9mZmxpbmUgICAgICAgQ29tcGxldGVkIHdpdGhv dXQgZXJyb3IgICAgICAgMDAlICAgICAgMjgzMCAgICAgICAgIC0KIyA2ICBFeHRlbmRlZCBv ZmZsaW5lICAgIENvbXBsZXRlZCB3aXRob3V0IGVycm9yICAgICAgIDAwJSAgICAgICAgODQg ICAgICAgICAtCiMgNyAgU2hvcnQgb2ZmbGluZSAgICAgICBDb21wbGV0ZWQgd2l0aG91dCBl cnJvciAgICAgICAwMCUgICAgICAgIDgyICAgICAgICAgLQoKU01BUlQgU2VsZWN0aXZlIHNl bGYtdGVzdCBsb2cgZGF0YSBzdHJ1Y3R1cmUgcmV2aXNpb24gbnVtYmVyIDEKIFNQQU4gIE1J Tl9MQkEgIE1BWF9MQkEgIENVUlJFTlRfVEVTVF9TVEFUVVMKICAgIDEgICAgICAgIDAgICAg ICAgIDAgIE5vdF90ZXN0aW5nCiAgICAyICAgICAgICAwICAgICAgICAwICBOb3RfdGVzdGlu ZwogICAgMyAgICAgICAgMCAgICAgICAgMCAgTm90X3Rlc3RpbmcKICAgIDQgICAgICAgIDAg ICAgICAgIDAgIE5vdF90ZXN0aW5nCiAgICA1ICAgICAgICAwICAgICAgICAwICBOb3RfdGVz dGluZwpTZWxlY3RpdmUgc2VsZi10ZXN0IGZsYWdzICgweDApOgogIEFmdGVyIHNjYW5uaW5n IHNlbGVjdGVkIHNwYW5zLCBkbyBOT1QgcmVhZC1zY2FuIHJlbWFpbmRlciBvZiBkaXNrLgpJ ZiBTZWxlY3RpdmUgc2VsZi10ZXN0IGlzIHBlbmRpbmcgb24gcG93ZXItdXAsIHJlc3VtZSBh ZnRlciAwIG1pbnV0ZSBkZWxheS4KCg== --------------050404000100060209050409 Content-Type: text/plain; name="smartctl-disk2.txt" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="smartctl-disk2.txt" c21hcnRjdGwgNS4zOSAyMDA5LTEyLTA5IHIyOTk1IFtGcmVlQlNEIDguMC1TVEFCTEUgaTM4 Nl0gKGxvY2FsIGJ1aWxkKQpDb3B5cmlnaHQgKEMpIDIwMDItOSBieSBCcnVjZSBBbGxlbiwg aHR0cDovL3NtYXJ0bW9udG9vbHMuc291cmNlZm9yZ2UubmV0Cgo9PT0gU1RBUlQgT0YgSU5G T1JNQVRJT04gU0VDVElPTiA9PT0KTW9kZWwgRmFtaWx5OiAgICAgV2VzdGVybiBEaWdpdGFs IFJFMyBTZXJpYWwgQVRBIGZhbWlseQpEZXZpY2UgTW9kZWw6ICAgICBXREMgV0Q1MDAyQUJZ Uy0xOEIxQjAKU2VyaWFsIE51bWJlcjogICAgV0QtV01BU1k1NDc0NzI3CkZpcm13YXJlIFZl cnNpb246IDAyLjAzQjAzClVzZXIgQ2FwYWNpdHk6ICAgIDUwMCwxMDcsODYyLDAxNiBieXRl cwpEZXZpY2UgaXM6ICAgICAgICBJbiBzbWFydGN0bCBkYXRhYmFzZSBbZm9yIGRldGFpbHMg dXNlOiAtUCBzaG93XQpBVEEgVmVyc2lvbiBpczogICA4CkFUQSBTdGFuZGFyZCBpczogIEV4 YWN0IEFUQSBzcGVjaWZpY2F0aW9uIGRyYWZ0IHZlcnNpb24gbm90IGluZGljYXRlZApMb2Nh bCBUaW1lIGlzOiAgICBTYXQgTWF5IDE1IDIyOjAwOjQ3IDIwMTAgQ0VTVApTTUFSVCBzdXBw b3J0IGlzOiBBdmFpbGFibGUgLSBkZXZpY2UgaGFzIFNNQVJUIGNhcGFiaWxpdHkuClNNQVJU IHN1cHBvcnQgaXM6IEVuYWJsZWQKCj09PSBTVEFSVCBPRiBSRUFEIFNNQVJUIERBVEEgU0VD VElPTiA9PT0KU01BUlQgb3ZlcmFsbC1oZWFsdGggc2VsZi1hc3Nlc3NtZW50IHRlc3QgcmVz dWx0OiBQQVNTRUQKCkdlbmVyYWwgU01BUlQgVmFsdWVzOgpPZmZsaW5lIGRhdGEgY29sbGVj dGlvbiBzdGF0dXM6ICAoMHg4NCkJT2ZmbGluZSBkYXRhIGNvbGxlY3Rpb24gYWN0aXZpdHkK CQkJCQl3YXMgc3VzcGVuZGVkIGJ5IGFuIGludGVycnVwdGluZyBjb21tYW5kIGZyb20gaG9z dC4KCQkJCQlBdXRvIE9mZmxpbmUgRGF0YSBDb2xsZWN0aW9uOiBFbmFibGVkLgpTZWxmLXRl c3QgZXhlY3V0aW9uIHN0YXR1czogICAgICAoICAgMCkJVGhlIHByZXZpb3VzIHNlbGYtdGVz dCByb3V0aW5lIGNvbXBsZXRlZAoJCQkJCXdpdGhvdXQgZXJyb3Igb3Igbm8gc2VsZi10ZXN0 IGhhcyBldmVyIAoJCQkJCWJlZW4gcnVuLgpUb3RhbCB0aW1lIHRvIGNvbXBsZXRlIE9mZmxp bmUgCmRhdGEgY29sbGVjdGlvbjogCQkgKDk0ODApIHNlY29uZHMuCk9mZmxpbmUgZGF0YSBj b2xsZWN0aW9uCmNhcGFiaWxpdGllczogCQkJICgweDdiKSBTTUFSVCBleGVjdXRlIE9mZmxp bmUgaW1tZWRpYXRlLgoJCQkJCUF1dG8gT2ZmbGluZSBkYXRhIGNvbGxlY3Rpb24gb24vb2Zm IHN1cHBvcnQuCgkJCQkJU3VzcGVuZCBPZmZsaW5lIGNvbGxlY3Rpb24gdXBvbiBuZXcKCQkJ CQljb21tYW5kLgoJCQkJCU9mZmxpbmUgc3VyZmFjZSBzY2FuIHN1cHBvcnRlZC4KCQkJCQlT ZWxmLXRlc3Qgc3VwcG9ydGVkLgoJCQkJCUNvbnZleWFuY2UgU2VsZi10ZXN0IHN1cHBvcnRl ZC4KCQkJCQlTZWxlY3RpdmUgU2VsZi10ZXN0IHN1cHBvcnRlZC4KU01BUlQgY2FwYWJpbGl0 aWVzOiAgICAgICAgICAgICgweDAwMDMpCVNhdmVzIFNNQVJUIGRhdGEgYmVmb3JlIGVudGVy aW5nCgkJCQkJcG93ZXItc2F2aW5nIG1vZGUuCgkJCQkJU3VwcG9ydHMgU01BUlQgYXV0byBz YXZlIHRpbWVyLgpFcnJvciBsb2dnaW5nIGNhcGFiaWxpdHk6ICAgICAgICAoMHgwMSkJRXJy b3IgbG9nZ2luZyBzdXBwb3J0ZWQuCgkJCQkJR2VuZXJhbCBQdXJwb3NlIExvZ2dpbmcgc3Vw cG9ydGVkLgpTaG9ydCBzZWxmLXRlc3Qgcm91dGluZSAKcmVjb21tZW5kZWQgcG9sbGluZyB0 aW1lOiAJICggICAyKSBtaW51dGVzLgpFeHRlbmRlZCBzZWxmLXRlc3Qgcm91dGluZQpyZWNv bW1lbmRlZCBwb2xsaW5nIHRpbWU6IAkgKCAxMTIpIG1pbnV0ZXMuCkNvbnZleWFuY2Ugc2Vs Zi10ZXN0IHJvdXRpbmUKcmVjb21tZW5kZWQgcG9sbGluZyB0aW1lOiAJICggICA1KSBtaW51 dGVzLgpTQ1QgY2FwYWJpbGl0aWVzOiAJICAgICAgICgweDMwM2YpCVNDVCBTdGF0dXMgc3Vw cG9ydGVkLgoJCQkJCVNDVCBGZWF0dXJlIENvbnRyb2wgc3VwcG9ydGVkLgoJCQkJCVNDVCBE YXRhIFRhYmxlIHN1cHBvcnRlZC4KClNNQVJUIEF0dHJpYnV0ZXMgRGF0YSBTdHJ1Y3R1cmUg cmV2aXNpb24gbnVtYmVyOiAxNgpWZW5kb3IgU3BlY2lmaWMgU01BUlQgQXR0cmlidXRlcyB3 aXRoIFRocmVzaG9sZHM6CklEIyBBVFRSSUJVVEVfTkFNRSAgICAgICAgICBGTEFHICAgICBW QUxVRSBXT1JTVCBUSFJFU0ggVFlQRSAgICAgIFVQREFURUQgIFdIRU5fRkFJTEVEIFJBV19W QUxVRQogIDEgUmF3X1JlYWRfRXJyb3JfUmF0ZSAgICAgMHgwMDJmICAgMjAwICAgMjAwICAg MDUxICAgIFByZS1mYWlsICBBbHdheXMgICAgICAgLSAgICAgICAwCiAgMyBTcGluX1VwX1Rp bWUgICAgICAgICAgICAweDAwMjcgICAyMzggICAyMzggICAwMjEgICAgUHJlLWZhaWwgIEFs d2F5cyAgICAgICAtICAgICAgIDEwODMKICA0IFN0YXJ0X1N0b3BfQ291bnQgICAgICAgIDB4 MDAzMiAgIDEwMCAgIDEwMCAgIDAwMCAgICBPbGRfYWdlICAgQWx3YXlzICAgICAgIC0gICAg ICAgODEKICA1IFJlYWxsb2NhdGVkX1NlY3Rvcl9DdCAgIDB4MDAzMyAgIDIwMCAgIDIwMCAg IDE0MCAgICBQcmUtZmFpbCAgQWx3YXlzICAgICAgIC0gICAgICAgMAogIDcgU2Vla19FcnJv cl9SYXRlICAgICAgICAgMHgwMDJlICAgMjAwICAgMjAwICAgMDAwICAgIE9sZF9hZ2UgICBB bHdheXMgICAgICAgLSAgICAgICAwCiAgOSBQb3dlcl9Pbl9Ib3VycyAgICAgICAgICAweDAw MzIgICAwOTMgICAwOTMgICAwMDAgICAgT2xkX2FnZSAgIEFsd2F5cyAgICAgICAtICAgICAg IDUzMTYKIDEwIFNwaW5fUmV0cnlfQ291bnQgICAgICAgIDB4MDAzMiAgIDEwMCAgIDI1MyAg IDAwMCAgICBPbGRfYWdlICAgQWx3YXlzICAgICAgIC0gICAgICAgMAogMTEgQ2FsaWJyYXRp b25fUmV0cnlfQ291bnQgMHgwMDMyICAgMTAwICAgMjUzICAgMDAwICAgIE9sZF9hZ2UgICBB bHdheXMgICAgICAgLSAgICAgICAwCiAxMiBQb3dlcl9DeWNsZV9Db3VudCAgICAgICAweDAw MzIgICAxMDAgICAxMDAgICAwMDAgICAgT2xkX2FnZSAgIEFsd2F5cyAgICAgICAtICAgICAg IDc5CjE5MiBQb3dlci1PZmZfUmV0cmFjdF9Db3VudCAweDAwMzIgICAyMDAgICAyMDAgICAw MDAgICAgT2xkX2FnZSAgIEFsd2F5cyAgICAgICAtICAgICAgIDc3CjE5MyBMb2FkX0N5Y2xl X0NvdW50ICAgICAgICAweDAwMzIgICAyMDAgICAyMDAgICAwMDAgICAgT2xkX2FnZSAgIEFs d2F5cyAgICAgICAtICAgICAgIDgxCjE5NCBUZW1wZXJhdHVyZV9DZWxzaXVzICAgICAweDAw MjIgICAxMjUgICAxMDUgICAwMDAgICAgT2xkX2FnZSAgIEFsd2F5cyAgICAgICAtICAgICAg IDIyCjE5NiBSZWFsbG9jYXRlZF9FdmVudF9Db3VudCAweDAwMzIgICAyMDAgICAyMDAgICAw MDAgICAgT2xkX2FnZSAgIEFsd2F5cyAgICAgICAtICAgICAgIDAKMTk3IEN1cnJlbnRfUGVu ZGluZ19TZWN0b3IgIDB4MDAzMiAgIDIwMCAgIDIwMCAgIDAwMCAgICBPbGRfYWdlICAgQWx3 YXlzICAgICAgIC0gICAgICAgMAoxOTggT2ZmbGluZV9VbmNvcnJlY3RhYmxlICAgMHgwMDMw ICAgMjAwICAgMjAwICAgMDAwICAgIE9sZF9hZ2UgICBPZmZsaW5lICAgICAgLSAgICAgICAw CjE5OSBVRE1BX0NSQ19FcnJvcl9Db3VudCAgICAweDAwMzIgICAyMDAgICAyMDAgICAwMDAg ICAgT2xkX2FnZSAgIEFsd2F5cyAgICAgICAtICAgICAgIDAKMjAwIE11bHRpX1pvbmVfRXJy b3JfUmF0ZSAgIDB4MDAwOCAgIDIwMCAgIDIwMCAgIDAwMCAgICBPbGRfYWdlICAgT2ZmbGlu ZSAgICAgIC0gICAgICAgMAoKU01BUlQgRXJyb3IgTG9nIFZlcnNpb246IDEKTm8gRXJyb3Jz IExvZ2dlZAoKU01BUlQgU2VsZi10ZXN0IGxvZyBzdHJ1Y3R1cmUgcmV2aXNpb24gbnVtYmVy IDEKTnVtICBUZXN0X0Rlc2NyaXB0aW9uICAgIFN0YXR1cyAgICAgICAgICAgICAgICAgIFJl bWFpbmluZyAgTGlmZVRpbWUoaG91cnMpICBMQkFfb2ZfZmlyc3RfZXJyb3IKIyAxICBTaG9y dCBvZmZsaW5lICAgICAgIENvbXBsZXRlZCB3aXRob3V0IGVycm9yICAgICAgIDAwJSAgICAg IDI4MzQgICAgICAgICAtCiMgMiAgRXh0ZW5kZWQgb2ZmbGluZSAgICBDb21wbGV0ZWQgd2l0 aG91dCBlcnJvciAgICAgICAwMCUgICAgICAgIDg0ICAgICAgICAgLQojIDMgIFNob3J0IG9m ZmxpbmUgICAgICAgQ29tcGxldGVkIHdpdGhvdXQgZXJyb3IgICAgICAgMDAlICAgICAgICA4 MyAgICAgICAgIC0KClNNQVJUIFNlbGVjdGl2ZSBzZWxmLXRlc3QgbG9nIGRhdGEgc3RydWN0 dXJlIHJldmlzaW9uIG51bWJlciAxCiBTUEFOICBNSU5fTEJBICBNQVhfTEJBICBDVVJSRU5U X1RFU1RfU1RBVFVTCiAgICAxICAgICAgICAwICAgICAgICAwICBOb3RfdGVzdGluZwogICAg MiAgICAgICAgMCAgICAgICAgMCAgTm90X3Rlc3RpbmcKICAgIDMgICAgICAgIDAgICAgICAg IDAgIE5vdF90ZXN0aW5nCiAgICA0ICAgICAgICAwICAgICAgICAwICBOb3RfdGVzdGluZwog ICAgNSAgICAgICAgMCAgICAgICAgMCAgTm90X3Rlc3RpbmcKU2VsZWN0aXZlIHNlbGYtdGVz dCBmbGFncyAoMHgwKToKICBBZnRlciBzY2FubmluZyBzZWxlY3RlZCBzcGFucywgZG8gTk9U IHJlYWQtc2NhbiByZW1haW5kZXIgb2YgZGlzay4KSWYgU2VsZWN0aXZlIHNlbGYtdGVzdCBp cyBwZW5kaW5nIG9uIHBvd2VyLXVwLCByZXN1bWUgYWZ0ZXIgMCBtaW51dGUgZGVsYXkuCgo= --------------050404000100060209050409-- From owner-freebsd-stable@FreeBSD.ORG Sat May 15 23:30:20 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0CF5F1065673 for ; Sat, 15 May 2010 23:30:20 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta01.emeryville.ca.mail.comcast.net (qmta01.emeryville.ca.mail.comcast.net [76.96.30.16]) by mx1.freebsd.org (Postfix) with ESMTP id E651C8FC0C for ; Sat, 15 May 2010 23:30:19 +0000 (UTC) Received: from omta18.emeryville.ca.mail.comcast.net ([76.96.30.74]) by qmta01.emeryville.ca.mail.comcast.net with comcast id HzVE1e0011bwxycA1zWLy5; Sat, 15 May 2010 23:30:20 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta18.emeryville.ca.mail.comcast.net with comcast id HzWK1e00P3S48mS8ezWKaW; Sat, 15 May 2010 23:30:20 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 9F61C9B419; Sat, 15 May 2010 16:30:18 -0700 (PDT) Date: Sat, 15 May 2010 16:30:18 -0700 From: Jeremy Chadwick To: Pieter de Boer Message-ID: <20100515233018.GA50125@icarus.home.lan> References: <4BED8B89.6010901@os3.nl> <20100514195346.GA8977@icarus.home.lan> <4BEDBC08.2040002@os3.nl> <20100514224236.GA11680@icarus.home.lan> <4BEE476B.6020407@os3.nl> <20100515162624.GA39585@icarus.home.lan> <4BEF066F.3090703@os3.nl> <4BEF0F31.9050405@thedarkside.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4BEF0F31.9050405@thedarkside.nl> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-stable@freebsd.org Subject: Re: Read / write timeouts on SATA disks connected to ICH9 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 May 2010 23:30:20 -0000 On Sat, May 15, 2010 at 11:16:33PM +0200, Pieter de Boer wrote: > >Attached the SMART output of both disks I replaced about a month ago. It > >appears I replaced perfectly fine drives with the current disks with > >errors ;( One of the old disks is in a USB-enclosure now, so 'da0'. Regarding the Western Digital RE3 disk (serial WD-WMASY5474089): The disk looks fine. The only thing of interest here is the temperature, which is extremely high (47C). If this is the drive which is located in an (non-fan-cooled) enclosure, that would explain it. There are no UDMA/CRC errors, so I'm not of the belief that there were bad cables in use either. Finally, there's no sign of the disk powering on/off excessively either. In summary, I can't explain how this disk would fall off the bus given its condition. Regarding the Western Digital RE3 disk (serial WD-WMASY5474727): Similar to the first RE3 disk; everything here looks great, including disk temperature. I do wish the FreeBSD ATA layer would give full diagnostic messages when encountering these conditions. The request buffer could be printed, and the response (error) could also be printed. SCSI CAM's error output is what I'd be hoping for (sans SK/ASC/ASCQ, which AFAIK ATA doesn't have). Yes, I know this is available if you use ahci.ko, but this isn't available to the OP. Anyway, if heavy disk/controller load appears to be causing these problems, you could have power-related issues. Possibly the combination of two disks + heavy I/O causes enough power draw that the ICH9 starts to behave oddly. Voltages which deviate too much can cause odd things to happen to hardware. If you have the time/money, you might try replacing the PSU in your system to see if there's any improvement; your BIOS should be able to provide you Hardware Monitoring statistics (voltages). Write these down before and after the PSU swap. You don't need to go crazy and buy a 1000W PSU or anything, but 450-750W is pretty normal these days. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB |