From owner-freebsd-stable@FreeBSD.ORG Mon Jan 1 10:52:40 2007 Return-Path: X-Original-To: stable@freebsd.org 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 5533516A403; Mon, 1 Jan 2007 10:52:40 +0000 (UTC) (envelope-from wsk@gddsn.org.cn) Received: from gddsn.org.cn (gddsn.org.cn [218.19.164.145]) by mx1.freebsd.org (Postfix) with ESMTP id C890813C43E; Mon, 1 Jan 2007 10:52:39 +0000 (UTC) (envelope-from wsk@gddsn.org.cn) Received: from [10.123.0.100] (unknown [80.249.66.245]) by gddsn.org.cn (Postfix) with ESMTP id D1C3C38CB88; Mon, 1 Jan 2007 18:19:09 +0800 (CST) Message-ID: <45995025.8000103@gddsn.org.cn> Date: Mon, 01 Jan 2007 18:17:09 +0000 From: wsk User-Agent: Thunderbird 1.5.0.7 (X11/20061022) MIME-Version: 1.0 To: stable@freebsd.org, current@freebsd.org Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 7bit Cc: Subject: mpt0 timed out 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, 01 Jan 2007 10:52:40 -0000 hi, scsi card connected to a disk array.and get follow error after less than 10 days thanks in advance. mpt0: port 0xcc00-0xccff mem 0xfcef0000-0xfceffff f,0xfcee0000-0xfceeffff irq 24 at device 3.0 on pci2 mpt0: [GIANT-LOCKED] mpt0: MPI Version=1.2.12.0 Trying to mount root from ufs:/dev/da1s1a mpt0: request 0xc4bf9fd0:2297 timed out for ccb 0xc6d20000 (req->ccb 0xc6d20000) mpt0: attempting to abort req 0xc4bf9fd0:2297 function 0 mpt0: completing timedout/aborted req 0xc4bf9fd0:2297 mpt0: abort of req 0xc4bf9fd0:0 completed mpt0: request 0xc4bfa450:2321 timed out for ccb 0xc6d17c00 (req->ccb 0xc6d17c00) mpt0: attempting to abort req 0xc4bfa450:2321 function 0 mpt0: completing timedout/aborted req 0xc4bfa450:2321 mpt0: abort of req 0xc4bfa450:0 completed mpt0: request 0xc4bfa4e0:2324 timed out for ccb 0xc4bf2000 (req->ccb 0xc4bf2000) mpt0: attempting to abort req 0xc4bfa4e0:2324 function 0 mpt0: completing timedout/aborted req 0xc4bfa4e0:2324 mpt0: abort of req 0xc4bfa4e0:0 completed mpt0: request 0xc4bfa660:2332 timed out for ccb 0xc6d19000 (req->ccb 0xc6d19000) mpt0: attempting to abort req 0xc4bfa660:2332 function 0 mpt0: completing timedout/aborted req 0xc4bfa660:2332 mpt0: abort of req 0xc4bfa660:0 completed mpt0: request 0xc4bfa780:2338 timed out for ccb 0xc6d0e800 (req->ccb 0xc6d0e800) mpt0: attempting to abort req 0xc4bfa780:2338 function 0 mpt0: completing timedout/aborted req 0xc4bfa780:2338 mpt0: abort of req 0xc4bfa780:0 completed mpt0: request 0xc4bfa810:2342 timed out for ccb 0xc6d20000 (req->ccb 0xc6d20000) mpt0: attempting to abort req 0xc4bfa810:2342 function 0 mpt0: completing timedout/aborted req 0xc4bfa810:2342 mpt0: abort of req 0xc4bfa810:0 completed mpt0: request 0xc4bfa840:2344 timed out for ccb 0xc6d17c00 (req->ccb 0xc6d17c00) mpt0: attempting to abort req 0xc4bfa840:2344 function 0 mpt0: completing timedout/aborted req 0xc4bfa840:2344 mpt0: abort of req 0xc4bfa840:0 completed mpt0: request 0xc4bfa870:2346 timed out for ccb 0xc4bf2000 (req->ccb 0xc4bf2000) mpt0: attempting to abort req 0xc4bfa870:2346 function 0 mpt0: completing timedout/aborted req 0xc4bfa870:2346 mpt0: abort of req 0xc4bfa870:0 completed mpt0: request 0xc4bfa900:2350 timed out for ccb 0xc6d19000 (req->ccb 0xc6d19000) mpt0: attempting to abort req 0xc4bfa900:2350 function 0 mpt0: completing timedout/aborted req 0xc4bfa900:2350 mpt0: abort of req 0xc4bfa900:0 completed mpt0: request 0xc4bfa930:2352 timed out for ccb 0xc6d0e800 (req->ccb 0xc6d0e800) mpt0: attempting to abort req 0xc4bfa930:2352 function 0 mpt0: completing timedout/aborted req 0xc4bfa930:2352 mpt0: abort of req 0xc4bfa930:0 completed mpt0: request 0xc4bfa9c0:2356 timed out for ccb 0xc6d20000 (req->ccb 0xc6d20000) mpt0: attempting to abort req 0xc4bfa9c0:2356 function 0 mpt0: completing timedout/aborted req 0xc4bfa9c0:2356 mpt0: abort of req 0xc4bfa9c0:0 completed mpt0: request 0xc4bfa9f0:2358 timed out for ccb 0xc6d17c00 (req->ccb 0xc6d17c00) mpt0: attempting to abort req 0xc4bfa9f0:2358 function 0 mpt0: completing timedout/aborted req 0xc4bfa9f0:2358 mpt0: abort of req 0xc4bfa9f0:0 completed mpt0: request 0xc4bfaa20:2360 timed out for ccb 0xc4bf2000 (req->ccb 0xc4bf2000) mpt0: attempting to abort req 0xc4bfaa20:2360 function 0 mpt0: completing timedout/aborted req 0xc4bfaa20:2360 mpt0: abort of req 0xc4bfaa20:0 completed mpt0: request 0xc4bfaab0:2364 timed out for ccb 0xc6d19000 (req->ccb 0xc6d19000) mpt0: attempting to abort req 0xc4bfaab0:2364 function 0 mpt0: completing timedout/aborted req 0xc4bfaab0:2364 mpt0: abort of req 0xc4bfaab0:0 completed mpt0: request 0xc4bfaae0:2366 timed out for ccb 0xc6d0e800 (req->ccb 0xc6d0e800) mpt0: attempting to abort req 0xc4bfaae0:2366 function 0 mpt0: completing timedout/aborted req 0xc4bfaae0:2366 mpt0: abort of req 0xc4bfaae0:0 completed mpt0: request 0xc4bfab70:2370 timed out for ccb 0xc6d20000 (req->ccb 0xc6d20000) mpt0: attempting to abort req 0xc4bfab70:2370 function 0 mpt0: completing timedout/aborted req 0xc4bfab70:2370 mpt0: abort of req 0xc4bfab70:0 completed mpt0: request 0xc4bfaba0:2372 timed out for ccb 0xc6d17c00 (req->ccb 0xc6d17c00) mpt0: attempting to abort req 0xc4bfaba0:2372 function 0 mpt0: completing timedout/aborted req 0xc4bfaba0:2372 mpt0: abort of req 0xc4bfaba0:0 completed mpt0: request 0xc4bfabd0:2374 timed out for ccb 0xc4bf2000 (req->ccb 0xc4bf2000) mpt0: attempting to abort req 0xc4bfabd0:2374 function 0 mpt0: completing timedout/aborted req 0xc4bfabd0:2374 mpt0: abort of req 0xc4bfabd0:0 completed mpt0: request 0xc4bfac60:2378 timed out for ccb 0xc6d19000 (req->ccb 0xc6d19000) mpt0: attempting to abort req 0xc4bfac60:2378 function 0 mpt0: completing timedout/aborted req 0xc4bfac60:2378 mpt0: abort of req 0xc4bfac60:0 completed mpt0: request 0xc4bfac90:2380 timed out for ccb 0xc6d0e800 (req->ccb 0xc6d0e800) mpt0: attempting to abort req 0xc4bfac90:2380 function 0 mpt0: completing timedout/aborted req 0xc4bfac90:2380 mpt0: abort of req 0xc4bfac90:0 completed mpt0: request 0xc4bfad20:2384 timed out for ccb 0xc6d20000 (req->ccb 0xc6d20000) mpt0: attempting to abort req 0xc4bfad20:2384 function 0 mpt0: completing timedout/aborted req 0xc4bfad20:2384 g_vfs_done():da0s1d[WRITE(offset=641334870016, length=131072)]error = 5 mpt0: abort of req 0xc4bfad20:0 completed mpt0: request 0xc4bfad50:2386 timed out for ccb 0xc6d17c00 (req->ccb 0xc6d17c00) mpt0: attempting to abort req 0xc4bfad50:2386 function 0 mpt0: completing timedout/aborted req 0xc4bfad50:2386 g_vfs_done():da0s1d[WRITE(offset=641332428800, length=16384)]error = 5 mpt0: abort of req 0xc4bfad50:0 completed mpt0: request 0xc4bfad80:2388 timed out for ccb 0xc4bf2000 (req->ccb 0xc4bf2000) mpt0: attempting to abort req 0xc4bfad80:2388 function 0 mpt0: completing timedout/aborted req 0xc4bfad80:2388 g_vfs_done():da0s1d[WRITE(offset=641336442880, length=32768)]error = 5 mpt0: abort of req 0xc4bfad80:0 completed mpt0: request 0xc4bfae10:2392 timed out for ccb 0xc6d19000 (req->ccb 0xc6d19000) mpt0: attempting to abort req 0xc4bfae10:2392 function 0 mpt0: completing timedout/aborted req 0xc4bfae10:2392 g_vfs_done():da0s1d[WRITE(offset=641279819776, length=16384)]error = 5 mpt0: abort of req 0xc4bfae10:0 completed mpt0: request 0xc4bfae40:2394 timed out for ccb 0xc6d0e800 (req->ccb 0xc6d0e800) mpt0: attempting to abort req 0xc4bfae40:2394 function 0 mpt0: completing timedout/aborted req 0xc4bfae40:2394 g_vfs_done():da0s1d[WRITE(offset=641332477952, length=16384)]error = 5 mpt0: abort of req 0xc4bfae40:0 completed mpt0: request 0xc4bfaed0:2399 timed out for ccb 0xc6d17c00 (req->ccb 0xc6d17c00) mpt0: attempting to abort req 0xc4bfaed0:2399 function 0 mpt0: completing timedout/aborted req 0xc4bfaed0:2399 mpt0: abort of req 0xc4bfaed0:0 completed mpt0: request 0xc4bfaf60:2405 timed out for ccb 0xc6d0e800 (req->ccb 0xc6d0e800) mpt0: request 0xc4bfaf90:2406 timed out for ccb 0xc6d20000 (req->ccb 0xc6d20000) mpt0: request 0xc4bfafc0:2407 timed out for ccb 0xc4c74000 (req->ccb 0xc4c74000) mpt0: request 0xc4bfaff0:2408 timed out for ccb 0xc4bf2000 (req->ccb 0xc4bf2000) mpt0: attempting to abort req 0xc4bfaf60:2405 function 0 mpt0: completing timedout/aborted req 0xc4bfaf60:2405 mpt0: abort of req 0xc4bfaf60:0 completed mpt0: attempting to abort req 0xc4bfaf90:2406 function 0 mpt0: completing timedout/aborted req 0xc4bfaf90:2406 mpt0: abort of req 0xc4bfaf90:0 completed mpt0: attempting to abort req 0xc4bfafc0:2407 function 0 mpt0: completing timedout/aborted req 0xc4bfafc0:2407 mpt0: abort of req 0xc4bfafc0:0 completed mpt0: attempting to abort req 0xc4bfaff0:2408 function 0 mpt0: completing timedout/aborted req 0xc4bfaff0:2408 mpt0: abort of req 0xc4bfaff0:0 completed mpt0: request 0xc4bfb020:2409 timed out for ccb 0xc6d1e400 (req->ccb 0xc6d1e400) mpt0: attempting to abort req 0xc4bfb020:2409 function 0 mpt0: completing timedout/aborted req 0xc4bfb020:2409 mpt0: abort of req 0xc4bfb020:0 completed mpt0: request 0xc4bfb0b0:2412 timed out for ccb 0xc6d18000 (req->ccb 0xc6d18000) mpt0: attempting to abort req 0xc4bfb0b0:2412 function 0 mpt0: completing timedout/aborted req 0xc4bfb0b0:2412 mpt0: abort of req 0xc4bfb0b0:0 completed mpt0: request 0xc4bfb1d0:2419 timed out for ccb 0xc6d17c00 (req->ccb 0xc6d17c00) mpt0: attempting to abort req 0xc4bfb1d0:2419 function 0 mpt0: completing timedout/aborted req 0xc4bfb1d0:2419 mpt0: abort of req 0xc4bfb1d0:0 completed From owner-freebsd-stable@FreeBSD.ORG Mon Jan 1 11:31:23 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org 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 7FDF416A412 for ; Mon, 1 Jan 2007 11:31:23 +0000 (UTC) (envelope-from chrcoluk@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.187]) by mx1.freebsd.org (Postfix) with ESMTP id 1A70D13C44C for ; Mon, 1 Jan 2007 11:31:22 +0000 (UTC) (envelope-from chrcoluk@gmail.com) Received: by nf-out-0910.google.com with SMTP id x37so6430251nfc for ; Mon, 01 Jan 2007 03:31:22 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=VjgpX8dP5c260Reip+imOUXrD+n+py7Mh7XaYhsv6f4O0D2Jb/8Xug8oxwRCRh3r9MkIkRfxmqp/5zWRsrrCjwZ94aFQ4DXQSHDZoZtF9T2WnILKP/Io0RxudzgiUjvoCmrQohlx7vbsPWw4RIa5rV+GvYhLQToxzyJ4eCKTbiM= Received: by 10.82.116.15 with SMTP id o15mr331257buc.1167651081919; Mon, 01 Jan 2007 03:31:21 -0800 (PST) Received: by 10.82.135.17 with HTTP; Mon, 1 Jan 2007 03:31:21 -0800 (PST) Message-ID: <3aaaa3a0701010331u72d70e90p714a0171fe9f292a@mail.gmail.com> Date: Mon, 1 Jan 2007 11:31:21 +0000 From: Chris To: "Ivan Voras" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20061230035722.L39715@thebighonker.lerctr.org> <4596543D.2090700@orchid.homeunix.org> Cc: freebsd-stable@freebsd.org Subject: Re: 6.2-PRE: Fatal Trap? 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, 01 Jan 2007 11:31:23 -0000 On 30/12/06, Ivan Voras wrote: > Karol Kwiatkowski wrote: > > > This works: FreeBSD 6.2-PRERELEASE #0: Thu Dec 14 11:34:36 CET 2006 > > This doesn't: FreeBSD 6.2-PRERELEASE #0: Sat Dec 30 11:27:11 CET 2006 > > > I'm not sure it that's all that matters, I can supply more information > > if needed. > > Yes, you'll need to send at least a kernel stack backtrace. See here: > http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug-online-ddb.html > > Get it to start the debugger on panic and post the backtrace (bt). > > > > Is it possible to make it auto run debugger, then auto run backtrace then dump the output to disk so people who have no local access can get backtraces? Chris From owner-freebsd-stable@FreeBSD.ORG Mon Jan 1 14:10:20 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org 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 7A0BB16A4CA for ; Mon, 1 Jan 2007 14:10:20 +0000 (UTC) (envelope-from ianchov@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.191]) by mx1.freebsd.org (Postfix) with ESMTP id 0C3BB13C441 for ; Mon, 1 Jan 2007 14:10:18 +0000 (UTC) (envelope-from ianchov@gmail.com) Received: by nf-out-0910.google.com with SMTP id x37so6465018nfc for ; Mon, 01 Jan 2007 06:10:17 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=P4FBwIGr9t6o3YrTKKwYoXGrkAPaxrqnl6UPXCFJnlsRDWyVpoWD/3+rgAFFtKtucfDzOYwuZrIhVsykULb0GW1kK9W924DbELpxw0L3WSsp5GwZ0PILDQ8LwC7/WG9YsOFh8RcE10EnoW2jJJy/H/MFuWsBK8D/6AFa+mKy1QA= Received: by 10.82.153.5 with SMTP id a5mr3423643bue.1167658892842; Mon, 01 Jan 2007 05:41:32 -0800 (PST) Received: by 10.82.189.12 with HTTP; Mon, 1 Jan 2007 05:41:32 -0800 (PST) Message-ID: <18e02bd30701010541s14daa891ib7f1e30540ca128a@mail.gmail.com> Date: Mon, 1 Jan 2007 15:41:32 +0200 From: "Iantcho Vassilev" To: "freebsd-stable@freebsd.org" In-Reply-To: <3aaaa3a0701010331u72d70e90p714a0171fe9f292a@mail.gmail.com> MIME-Version: 1.0 References: <20061230035722.L39715@thebighonker.lerctr.org> <4596543D.2090700@orchid.homeunix.org> <3aaaa3a0701010331u72d70e90p714a0171fe9f292a@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: 6.2-PRE: Fatal Trap? 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, 01 Jan 2007 14:10:20 -0000 Yesterda I had also a kernel trap - process (sendmail) on a Compaq Deskpro with the 6.2 Prerelease.. I revert every option in make.conf, tried Generic kernel as well..no success... Awaiting for more info And now compiling today sources On 1/1/07, Chris wrote: > > On 30/12/06, Ivan Voras wrote: > > Karol Kwiatkowski wrote: > > > > > This works: FreeBSD 6.2-PRERELEASE #0: Thu Dec 14 11:34:36 CET 2006 > > > This doesn't: FreeBSD 6.2-PRERELEASE #0: Sat Dec 30 11:27:11 CET 2006 > > > > > I'm not sure it that's all that matters, I can supply more information > > > if needed. > > > > Yes, you'll need to send at least a kernel stack backtrace. See here: > > > http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug-online-ddb.html > > > > Get it to start the debugger on panic and post the backtrace (bt). > > > > > > > > > > Is it possible to make it auto run debugger, then auto run backtrace > then dump the output to disk so people who have no local access can > get backtraces? > > Chris > _______________________________________________ > 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" > -- --- ianchov@hushmail.com From owner-freebsd-stable@FreeBSD.ORG Mon Jan 1 14:55:13 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org 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 2516816A403 for ; Mon, 1 Jan 2007 14:55:13 +0000 (UTC) (envelope-from ohartman@mail.zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id 9CF5513C45B for ; Mon, 1 Jan 2007 14:55:12 +0000 (UTC) (envelope-from ohartman@mail.zedat.fu-berlin.de) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.64) with esmtp (envelope-from ) id <1H1OFi-0006iA-J2>; Mon, 01 Jan 2007 15:35:02 +0100 Received: from e178035029.adsl.alicedsl.de ([85.178.35.29] helo=[192.168.1.128]) by inpost2.zedat.fu-berlin.de (Exim 4.64) with esmtpsa (envelope-from ) id <1H1OFi-0006SV-GB>; Mon, 01 Jan 2007 15:35:02 +0100 Message-ID: <45991C12.1020308@mail.zedat.fu-berlin.de> Date: Mon, 01 Jan 2007 15:34:58 +0100 From: "O. Hartmann" User-Agent: Thunderbird 1.5.0.9 (X11/20061223) MIME-Version: 1.0 To: Iantcho Vassilev References: <20061230035722.L39715@thebighonker.lerctr.org> <4596543D.2090700@orchid.homeunix.org> <3aaaa3a0701010331u72d70e90p714a0171fe9f292a@mail.gmail.com> <18e02bd30701010541s14daa891ib7f1e30540ca128a@mail.gmail.com> In-Reply-To: <18e02bd30701010541s14daa891ib7f1e30540ca128a@mail.gmail.com> X-Enigmail-Version: 0.94.1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Originating-IP: 85.178.35.29 Cc: "freebsd-stable@freebsd.org" Subject: Re: 6.2-PRE: Fatal Trap? 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, 01 Jan 2007 14:55:13 -0000 Iantcho Vassilev wrote: > Yesterda I had also a kernel trap - process (sendmail) on a Compaq > Deskpro > with the 6.2 Prerelease.. > I revert every option in make.conf, tried Generic kernel as well..no > success... > > > > Awaiting for more info > > And now compiling today sources > > > > > On 1/1/07, Chris wrote: >> >> On 30/12/06, Ivan Voras wrote: >> > Karol Kwiatkowski wrote: >> > >> > > This works: FreeBSD 6.2-PRERELEASE #0: Thu Dec 14 11:34:36 CET 2006 >> > > This doesn't: FreeBSD 6.2-PRERELEASE #0: Sat Dec 30 11:27:11 CET >> 2006 >> > >> > > I'm not sure it that's all that matters, I can supply more >> information >> > > if needed. >> > >> > Yes, you'll need to send at least a kernel stack backtrace. See here: >> > >> http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug-online-ddb.html >> >> > >> > Get it to start the debugger on panic and post the backtrace (bt). >> > >> > >> > >> > >> >> Is it possible to make it auto run debugger, then auto run backtrace >> then dump the output to disk so people who have no local access can >> get backtraces? >> I also ran into a trap after yesterday's cvsupdate (rpcbind traps with trap 12). Running the prvious kernel now and it works, compiling just now a new system with the today's cvsupdates (but there was no kernel stuff, so I expect no success on that). The box ist running FreeBSD fauxpas.dyn.org 6.2-PRERELEASE FreeBSD 6.2-PRERELEASE #47: Tue Dec 26 14:12:56 UTC 2006 root@fauxpas.dyn.org:/usr/obj/usr/src/sys/THOR amd64 The date of this uname output is the date of my last kernel build that works ... Regards, Oliver From owner-freebsd-stable@FreeBSD.ORG Mon Jan 1 15:01:33 2007 Return-Path: X-Original-To: stable@freebsd.org 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 C1CFA16A403; Mon, 1 Jan 2007 15:01:33 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [210.51.165.229]) by mx1.freebsd.org (Postfix) with ESMTP id 2BD6313C457; Mon, 1 Jan 2007 15:01:32 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from localhost (tarsier.geekcn.org [210.51.165.229]) by tarsier.geekcn.org (Postfix) with ESMTP id 4353BEB52C5; Mon, 1 Jan 2007 22:42:17 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([210.51.165.229]) by localhost (mail.geekcn.org [210.51.165.229]) (amavisd-new, port 10024) with ESMTP id crg+SQar2TWk; Mon, 1 Jan 2007 22:41:59 +0800 (CST) Received: from [192.168.1.32] (unknown [61.51.104.180]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTP id 252E2EB52BF; Mon, 1 Jan 2007 22:41:58 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=delphij.net; c=nofws; q=dns; h=message-id:date:from:organization:user-agent:mime-version:to:cc: subject:references:in-reply-to:x-enigmail-version:content-type; b=bSlIGqKrZt0qlVZL62/+wJ3oXNvJSqjebUdgTbgOLvpJ7OM5OZsClwNQKZPQALxe8 KRxCG84ZnwtskEazDcZpQ== Message-ID: <45991D72.4010205@delphij.net> Date: Mon, 01 Jan 2007 22:40:50 +0800 From: LI Xin Organization: The FreeBSD Project User-Agent: Thunderbird 1.5.0.9 (Macintosh/20061207) MIME-Version: 1.0 To: wsk References: <45995025.8000103@gddsn.org.cn> In-Reply-To: <45995025.8000103@gddsn.org.cn> X-Enigmail-Version: 0.94.1.0 Content-Type: multipart/signed; micalg=pgp-ripemd160; protocol="application/pgp-signature"; boundary="------------enigC30EA5E8B375A3E43A638ED8" Cc: stable@freebsd.org, current@freebsd.org Subject: Re: mpt0 timed out 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, 01 Jan 2007 15:01:33 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigC30EA5E8B375A3E43A638ED8 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable wsk wrote: > hi, scsi card connected to a disk array.and get follow error after less= > than 10 days > thanks in advance. You did not mentioned which release are you using... BTW. Have you tried if lowering down the connection speed (i.e. use 160M/s instead of 320M/s) would make things better? If that helps, check the cable. Cheers, --=20 Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! --------------enigC30EA5E8B375A3E43A638ED8 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFmR1yOfuToMruuMARA5LFAJ9QhAganChhTW+OKY7JwvWhMNugJACfdlk2 80rNhrT+cPIEDOgGIwWMGKg= =N6oo -----END PGP SIGNATURE----- --------------enigC30EA5E8B375A3E43A638ED8-- From owner-freebsd-stable@FreeBSD.ORG Mon Jan 1 15:10:18 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org 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 DA81616A412 for ; Mon, 1 Jan 2007 15:10:18 +0000 (UTC) (envelope-from stb@lassitu.de) Received: from koef.zs64.net (koef.zs64.net [212.12.50.230]) by mx1.freebsd.org (Postfix) with ESMTP id 737BC13C442 for ; Mon, 1 Jan 2007 15:10:18 +0000 (UTC) (envelope-from stb@lassitu.de) Received: (from stb@koef.zs64.net) (authenticated) by koef.zs64.net (8.13.8/8.13.8) with ESMTP id l01Evlev041340 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 1 Jan 2007 15:57:48 +0100 (CET) (envelope-from stb@lassitu.de) In-Reply-To: <3aaaa3a0701010331u72d70e90p714a0171fe9f292a@mail.gmail.com> References: <20061230035722.L39715@thebighonker.lerctr.org> <4596543D.2090700@orchid.homeunix.org> <3aaaa3a0701010331u72d70e90p714a0171fe9f292a@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Stefan Bethke Date: Mon, 1 Jan 2007 15:57:46 +0100 To: Chris X-Mailer: Apple Mail (2.752.2) Cc: FreeBSD Stable Subject: Re: 6.2-PRE: Fatal Trap? 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, 01 Jan 2007 15:10:18 -0000 Am 01.01.2007 um 12:31 schrieb Chris: > Is it possible to make it auto run debugger, then auto run backtrace > then dump the output to disk so people who have no local access can > get backtraces? No, but you can enable crashdumps and run the debugger on the dump afterwards. Add dumpdev="AUTO" to /etc/rc.conf, then run /etc/rc.d/dumpon start. When the next panic occurs, the kernel will write the dump to the configured swap space, and the system will save the dump to /var/crash on rebooting. See http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/ kerneldebug-gdb.html on how to get a backtrace from that dump. If you're short on space in /var, and/or you have a large amount of RAM, you can set the sysctl debug.minidump to 1 to have the kernel only dump relevant portions of memory, instead of everything. This, however, is experimental in -stable, afaik. Stefan -- Stefan Bethke Fon +49 170 346 0140 From owner-freebsd-stable@FreeBSD.ORG Mon Jan 1 22:53:11 2007 Return-Path: X-Original-To: stable@freebsd.org 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 02C3716A40F for ; Mon, 1 Jan 2007 22:53:11 +0000 (UTC) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.freebsd.org (Postfix) with ESMTP id E75A413C428 for ; Mon, 1 Jan 2007 22:53:10 +0000 (UTC) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.11/8.13.6) with ESMTP id l01Mr9s3035067; Mon, 1 Jan 2007 14:53:09 -0800 (PST) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.11/8.12.3/Submit) id l01Mr9xS035066; Mon, 1 Jan 2007 14:53:09 -0800 (PST) (envelope-from rizzo) Date: Mon, 1 Jan 2007 14:53:09 -0800 From: Luigi Rizzo To: stable@freebsd.org Message-ID: <20070101145309.A35044@xorpc.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i Cc: Subject: Re: drm and i915 issue on Dell Latitude X1 ? 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, 01 Jan 2007 22:53:11 -0000 a curious thing... on my Dell Latitude X1 (scanpci -v output at the end) the drm module did not recognise the video card until i added this patch: Index: drm_pciids.h =================================================================== RCS file: /home/ncvs/src/sys/dev/drm/drm_pciids.h,v retrieving revision 1.2.2.3 diff -u -r1.2.2.3 drm_pciids.h --- drm_pciids.h 17 May 2006 07:40:11 -0000 1.2.2.3 +++ drm_pciids.h 1 Jan 2007 18:04:08 -0000 @@ -286,6 +286,7 @@ {0x8086, 0x2572, 0, "Intel i865G GMCH"}, \ {0x8086, 0x2582, 0, "Intel i915G"}, \ {0x8086, 0x2592, 0, "Intel i915GM"}, \ + {0x8086, 0x2792, 0, "Intel i915GML"}, \ {0x8086, 0x2772, 0, "Intel i945G"}, \ {0x8086, 0x27A2, 0, "Intel i945GM"}, \ {0, 0, 0, NULL} The board has two PCI IDs, 0x2592 (at PCI 0:2:0, which is the one that drives the LCD screen) and 0x2792 (perhaps this is a dual-head card ?). Apparently the drm module only looks for the latter even though it is not the one that drives the LCD screen. I am not sure what is the appropriate fix here, whether the drm module should look for all PCI IDs of the card, or something else. Further info below: the output of scanpci -v and the relevant lines from /var/log/Xorg.0.log cheers luigi % scanpci -v pci bus 0x0000 cardnum 0x00 function 0x00: vendor 0x8086 device 0x2590 Intel Corporation Mobile 915GM/PM/GMS/910GML Express Processor to DRAM Controller CardVendor 0x1028 card 0x01a3 (Dell, Card unknown) STATUS 0x2090 COMMAND 0x0006 CLASS 0x06 0x00 0x00 REVISION 0x03 BIST 0x00 HEADER 0x00 LATENCY 0x00 CACHE 0x00 BYTE_0 0x00 BYTE_1 0x50 BYTE_2 0x00 BYTE_3 0xf0 pci bus 0x0000 cardnum 0x02 function 0x00: vendor 0x8086 device 0x2592 Intel Corporation Mobile 915GM/GMS/910GML Express Graphics Controller CardVendor 0x1028 card 0x01a3 (Dell, Card unknown) STATUS 0x0090 COMMAND 0x0007 CLASS 0x03 0x00 0x00 REVISION 0x03 BIST 0x00 HEADER 0x80 LATENCY 0x00 CACHE 0x00 BASE0 0xdff00000 addr 0xdff00000 MEM BASE1 0x0000ec39 addr 0x0000ec38 I/O BASE2 0xc0000008 addr 0xc0000000 MEM PREFETCHABLE BASE3 0xdfec0000 addr 0xdfec0000 MEM MAX_LAT 0x00 MIN_GNT 0x00 INT_PIN 0x01 INT_LINE 0x10 pci bus 0x0000 cardnum 0x02 function 0x01: vendor 0x8086 device 0x2792 Intel Corporation Mobile 915GM/GMS/910GML Express Graphics Controller CardVendor 0x1028 card 0x01a3 (Dell, Card unknown) STATUS 0x0090 COMMAND 0x0007 CLASS 0x03 0x80 0x00 REVISION 0x03 BIST 0x00 HEADER 0x80 LATENCY 0x00 CACHE 0x00 BASE0 0xdff80000 addr 0xdff80000 MEM pci bus 0x0000 cardnum 0x1c function 0x00: vendor 0x8086 device 0x2660 Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) PCI Express Port 1 STATUS 0x0010 COMMAND 0x0007 CLASS 0x06 0x04 0x00 REVISION 0x03 HEADER 0x81 LATENCY 0x00 PRIBUS 0x00 SECBUS 0x01 SUBBUS 0x01 SECLT 0x00 SECSTATUS 0x2000 IOBASE 0xf000 IOLIM 0x0fff NOPREFETCH_MEMBASE 0xdfd00000 MEMLIM 0xdfdfffff PREFETCH_MEMBASE 0x00000000fff00000 MEMLIM 0x00000000000fffff NO_FAST_B2B NO_SEC_BUS_RST NO_M_ABRT NO_VGA_EN NO_ISA_EN SERR_EN NO_PERR_EN pci bus 0x0000 cardnum 0x1d function 0x00: vendor 0x8086 device 0x2658 Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #1 CardVendor 0x1028 card 0x01a3 (Dell, Card unknown) STATUS 0x0280 COMMAND 0x0005 CLASS 0x0c 0x03 0x00 REVISION 0x03 BIST 0x00 HEADER 0x80 LATENCY 0x00 CACHE 0x00 BASE4 0x0000bf81 addr 0x0000bf80 I/O MAX_LAT 0x00 MIN_GNT 0x00 INT_PIN 0x01 INT_LINE 0x10 pci bus 0x0000 cardnum 0x1d function 0x01: vendor 0x8086 device 0x2659 Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #2 CardVendor 0x1028 card 0x01a3 (Dell, Card unknown) STATUS 0x0280 COMMAND 0x0005 CLASS 0x0c 0x03 0x00 REVISION 0x03 BIST 0x00 HEADER 0x00 LATENCY 0x00 CACHE 0x00 BASE4 0x0000bf61 addr 0x0000bf60 I/O MAX_LAT 0x00 MIN_GNT 0x00 INT_PIN 0x02 INT_LINE 0x11 pci bus 0x0000 cardnum 0x1d function 0x02: vendor 0x8086 device 0x265a Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #3 CardVendor 0x1028 card 0x01a3 (Dell, Card unknown) STATUS 0x0280 COMMAND 0x0005 CLASS 0x0c 0x03 0x00 REVISION 0x03 BIST 0x00 HEADER 0x00 LATENCY 0x00 CACHE 0x00 BASE4 0x0000bf41 addr 0x0000bf40 I/O MAX_LAT 0x00 MIN_GNT 0x00 INT_PIN 0x03 INT_LINE 0x12 pci bus 0x0000 cardnum 0x1d function 0x03: vendor 0x8086 device 0x265b Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #4 CardVendor 0x1028 card 0x01a3 (Dell, Card unknown) STATUS 0x0280 COMMAND 0x0005 CLASS 0x0c 0x03 0x00 REVISION 0x03 BIST 0x00 HEADER 0x00 LATENCY 0x00 CACHE 0x00 BASE4 0x0000bf21 addr 0x0000bf20 I/O MAX_LAT 0x00 MIN_GNT 0x00 INT_PIN 0x04 INT_LINE 0x13 pci bus 0x0000 cardnum 0x1d function 0x07: vendor 0x8086 device 0x265c Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB2 EHCI Controller CardVendor 0x1028 card 0x01a3 (Dell, Card unknown) STATUS 0x0290 COMMAND 0x0106 CLASS 0x0c 0x03 0x20 REVISION 0x03 BIST 0x00 HEADER 0x00 LATENCY 0x00 CACHE 0x00 BASE0 0xffa80800 addr 0xffa80800 MEM MAX_LAT 0x00 MIN_GNT 0x00 INT_PIN 0x01 INT_LINE 0x10 pci bus 0x0000 cardnum 0x1e function 0x00: vendor 0x8086 device 0x2448 Intel Corporation 82801 Mobile PCI Bridge STATUS 0x0010 COMMAND 0x0107 CLASS 0x06 0x04 0x01 REVISION 0xd3 HEADER 0x81 LATENCY 0x00 PRIBUS 0x00 SECBUS 0x02 SUBBUS 0x03 SECLT 0x20 SECSTATUS 0x2280 IOBASE 0xf000 IOLIM 0x0fff NOPREFETCH_MEMBASE 0xdfc00000 MEMLIM 0xdfcfffff PREFETCH_MEMBASE 0x00000000fff00000 MEMLIM 0x00000000000fffff NO_FAST_B2B NO_SEC_BUS_RST NO_M_ABRT NO_VGA_EN NO_ISA_EN SERR_EN NO_PERR_EN pci bus 0x0000 cardnum 0x1e function 0x02: vendor 0x8086 device 0x266e Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) AC'97 Audio Controller CardVendor 0x1028 card 0x01a3 (Dell, Card unknown) STATUS 0x0290 COMMAND 0x0007 CLASS 0x04 0x01 0x00 REVISION 0x03 BIST 0x00 HEADER 0x00 LATENCY 0x00 CACHE 0x00 BASE0 0x0000ed01 addr 0x0000ed00 I/O BASE1 0x0000ec41 addr 0x0000ec40 I/O BASE2 0xdfebfe00 addr 0xdfebfe00 MEM BASE3 0xdfebfd00 addr 0xdfebfd00 MEM MAX_LAT 0x00 MIN_GNT 0x00 INT_PIN 0x01 INT_LINE 0x10 BYTE_0 0x09 BYTE_1 0x01 BYTE_2 0x00 BYTE_3 0x00 pci bus 0x0000 cardnum 0x1e function 0x03: vendor 0x8086 device 0x266d Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) AC'97 Modem Controller CardVendor 0x14f1 card 0x5423 (Conexant, Card unknown) STATUS 0x0290 COMMAND 0x0005 CLASS 0x07 0x03 0x00 REVISION 0x03 BIST 0x00 HEADER 0x00 LATENCY 0x00 CACHE 0x00 BASE0 0x0000ee01 addr 0x0000ee00 I/O BASE1 0x0000ec81 addr 0x0000ec80 I/O MAX_LAT 0x00 MIN_GNT 0x00 INT_PIN 0x02 INT_LINE 0x11 pci bus 0x0000 cardnum 0x1f function 0x00: vendor 0x8086 device 0x2641 Intel Corporation 82801FBM (ICH6M) LPC Interface Bridge CardVendor 0x1028 card 0x01a3 (Dell, Card unknown) STATUS 0x0200 COMMAND 0x0107 CLASS 0x06 0x01 0x00 REVISION 0x03 BIST 0x00 HEADER 0x80 LATENCY 0x00 CACHE 0x00 BYTE_0 0x01 BYTE_1 0x10 BYTE_2 0x00 BYTE_3 0x00 pci bus 0x0000 cardnum 0x1f function 0x01: vendor 0x8086 device 0x266f Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) IDE Controller CardVendor 0x1028 card 0x01a3 (Dell, Card unknown) STATUS 0x0280 COMMAND 0x0005 CLASS 0x01 0x01 0x8a REVISION 0x03 BIST 0x00 HEADER 0x00 LATENCY 0x00 CACHE 0x00 BASE0 0x000001f1 addr 0x000001f0 I/O BASE1 0x000003f5 addr 0x000003f4 I/O BASE2 0x00000171 addr 0x00000170 I/O BASE3 0x00000375 addr 0x00000374 I/O BASE4 0x0000bfa1 addr 0x0000bfa0 I/O MAX_LAT 0x00 MIN_GNT 0x00 INT_PIN 0x01 INT_LINE 0x10 BYTE_0 0x77 BYTE_1 0xe3 BYTE_2 0x77 BYTE_3 0x40 pci bus 0x0000 cardnum 0x1f function 0x03: vendor 0x8086 device 0x266a Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) SMBus Controller CardVendor 0x1028 card 0x01a3 (Dell, Card unknown) STATUS 0x0280 COMMAND 0x0101 CLASS 0x0c 0x05 0x00 REVISION 0x03 BIST 0x00 HEADER 0x00 LATENCY 0x00 CACHE 0x00 BASE4 0x000010c1 addr 0x000010c0 I/O MAX_LAT 0x00 MIN_GNT 0x00 INT_PIN 0x02 INT_LINE 0x11 BYTE_0 0x03 BYTE_1 0x00 BYTE_2 0x00 BYTE_3 0x00 pci bus 0x0001 cardnum 0x00 function 0x00: vendor 0x14e4 device 0x1677 Broadcom Corporation NetXtreme BCM5751 Gigabit Ethernet PCI Express CardVendor 0x1028 card 0x01a3 (Dell, Card unknown) STATUS 0x0010 COMMAND 0x0106 CLASS 0x02 0x00 0x00 REVISION 0x01 BIST 0x00 HEADER 0x00 LATENCY 0x00 CACHE 0x10 BASE0 0x00000000dfdf0004 addr 0x00000000dfdf0000 MEM 64BIT MAX_LAT 0x00 MIN_GNT 0x00 INT_PIN 0x01 INT_LINE 0x10 pci bus 0x0002 cardnum 0x01 function 0x00: vendor 0x1180 device 0x0476 Ricoh Co Ltd RL5c476 II STATUS 0x0210 COMMAND 0x0007 CLASS 0x06 0x07 0x00 REVISION 0xb3 BIST 0x00 HEADER 0x82 LATENCY 0x40 CACHE 0x00 BASE0 0xdfc00000 addr 0xdfc00000 MEM BASE1 0x20030302020000dc addr 0x20030302020000d0 MEM PREFETCHABLE 64BIT BASE3 0xfffff000 addr 0xfffff000 MEM BASE5 0xfffff000 addr 0xfffff000 MEM MAX_LAT 0x07 MIN_GNT 0x40 INT_PIN 0x01 INT_LINE 0x13 BYTE_0 0x28 BYTE_1 0x10 BYTE_2 0xa3 BYTE_3 0x01 pci bus 0x0002 cardnum 0x01 function 0x01: vendor 0x1180 device 0x0552 Ricoh Co Ltd R5C552 IEEE 1394 Controller CardVendor 0x1028 card 0x01a3 (Dell, Card unknown) STATUS 0x0210 COMMAND 0x0006 CLASS 0x0c 0x00 0x10 REVISION 0x08 BIST 0x00 HEADER 0x80 LATENCY 0x40 CACHE 0x00 BASE0 0xdfcfe800 addr 0xdfcfe800 MEM MAX_LAT 0x04 MIN_GNT 0x02 INT_PIN 0x02 INT_LINE 0x12 pci bus 0x0002 cardnum 0x01 function 0x02: vendor 0x1180 device 0x0822 Ricoh Co Ltd R5C822 SD/SDIO/MMC/MS/MSPro Host Adapter CardVendor 0x1028 card 0x01a3 (Dell, Card unknown) STATUS 0x0210 COMMAND 0x0106 CLASS 0x08 0x05 0x01 REVISION 0x17 BIST 0x00 HEADER 0x80 LATENCY 0x40 CACHE 0x00 BASE0 0xdfcfe700 addr 0xdfcfe700 MEM MAX_LAT 0x00 MIN_GNT 0x00 INT_PIN 0x03 INT_LINE 0x11 pci bus 0x0002 cardnum 0x03 function 0x00: vendor 0x8086 device 0x4220 Intel Corporation PRO/Wireless 2200BG CardVendor 0x8086 card 0x2721 (Intel Corporation, Card unknown) STATUS 0x0290 COMMAND 0x0116 CLASS 0x02 0x80 0x00 REVISION 0x05 BIST 0x00 HEADER 0x00 LATENCY 0x40 CACHE 0x10 BASE0 0xdfcff000 addr 0xdfcff000 MEM MAX_LAT 0x18 MIN_GNT 0x03 INT_PIN 0x01 INT_LINE 0x11 BYTE_0 0x80 BYTE_1 0x00 BYTE_2 0x00 BYTE_3 0x00 relevant part of /var/log/Xorg.0.log drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is -1, (No such file or directory) drmOpenDevice: open result is -1, (No such file or directory) drmOpenDevice: Open failed drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is -1, (No such file or directory) drmOpenDevice: open result is -1, (No such file or directory) drmOpenDevice: Open failed drmOpenByBusid: Searching for BusID pci:0000:00:02.0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 9, (OK) drmOpenByBusid: drmOpenMinor returns 9 drmOpenByBusid: drmGetBusid reports pci:0000:00:02.0 (II) I810(0): [drm] loaded kernel module for "i915" driver (II) I810(0): [drm] DRM interface version 1.2 (II) I810(0): [drm] created "i915" driver at busid "pci:0000:00:02.0" (II) I810(0): [drm] added 8192 byte SAREA at 0xc3f6a000 (II) I810(0): [drm] mapped SAREA 0xc3f6a000 to 0x286ec000 (II) I810(0): [drm] framebuffer handle = 0xc0020000 From owner-freebsd-stable@FreeBSD.ORG Mon Jan 1 23:02:26 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org 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 751E216A407 for ; Mon, 1 Jan 2007 23:02:26 +0000 (UTC) (envelope-from stephen.liss@gmail.com) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.236]) by mx1.freebsd.org (Postfix) with ESMTP id E4F9713C4C1 for ; Mon, 1 Jan 2007 23:02:25 +0000 (UTC) (envelope-from stephen.liss@gmail.com) Received: by wx-out-0506.google.com with SMTP id s18so5480856wxc for ; Mon, 01 Jan 2007 15:02:25 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:content-transfer-encoding:reply-to:references:in-reply-to:sensitivity:importance:to:subject:date:content-type:mime-version:from; b=tymzIs88aPnZe4OLauHfVfULbep3JJJiDj7xVpEf/U9Dxnrvp3EkQ8BKN3UcWBdG+A+x5BRIfrpVsk4Tm//j9hRgtO+xpYF3RLQi20/ybFsPUNTMH3uIvQ5g6o2ZCS1PCvWM1DdrKHRZSWuFG6CPahDqwR0oOVJ1XKY38t4YrJk= Received: by 10.70.132.2 with SMTP id f2mr35453843wxd.1167691027011; Mon, 01 Jan 2007 14:37:07 -0800 (PST) Received: from bda054-cell00.bisx.prod.on.blackberry ( [216.9.249.54]) by mx.google.com with ESMTP id i16sm27405930wxd.2007.01.01.14.37.04; Mon, 01 Jan 2007 14:37:05 -0800 (PST) Message-ID: <703963423-1167691020-cardhu_blackberry.rim.net-1984568267-@bwe020-cell00.bisx.prod.on.blackberry> Content-Transfer-Encoding: base64 References: <20070101120042.8E48616A63E@hub.freebsd.org> In-Reply-To: <20070101120042.8E48616A63E@hub.freebsd.org> Sensitivity: Normal Importance: Normal To: freebsd-stable@freebsd.org Date: Mon, 1 Jan 2007 22:35:45 +0000 Content-type: text/plain MIME-Version: 1.0 From: =?UTF-8?B?U3RlcGhlbiBMaXNz?= Subject: Re: freebsd-stable Digest, Vol 188, Issue 10 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Stephen.Liss@gmail.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jan 2007 23:02:26 -0000 SGVscA0KLS0NClN0ZXBoZW4gTGlzcw0KODQ3LTg1OC02NTQ5IChtb2JpbGUpDQpZYWhvbyEgSU06 IGljX3N0ZXBoZW5fbGlzcw0KICAgICAgICANCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N CkZyb206IGZyZWVic2Qtc3RhYmxlLXJlcXVlc3RAZnJlZWJzZC5vcmcNCkRhdGU6IE1vbiwgIDEg SmFuIDIwMDcgMTI6MDA6NDIgDQpUbzpmcmVlYnNkLXN0YWJsZUBmcmVlYnNkLm9yZw0KU3ViamVj dDogZnJlZWJzZC1zdGFibGUgRGlnZXN0LCBWb2wgMTg4LCBJc3N1ZSAxMA0KDQpTZW5kIGZyZWVi c2Qtc3RhYmxlIG1haWxpbmcgbGlzdCBzdWJtaXNzaW9ucyB0bw0KCWZyZWVic2Qtc3RhYmxlQGZy ZWVic2Qub3JnDQoNClRvIHN1YnNjcmliZSBvciB1bnN1YnNjcmliZSB2aWEgdGhlIFdvcmxkIFdp ZGUgV2ViLCB2aXNpdA0KCWh0dHA6Ly9saXN0cy5mcmVlYnNkLm9yZy9tYWlsbWFuL2xpc3RpbmZv L2ZyZWVic2Qtc3RhYmxlDQpvciwgdmlhIGVtYWlsLCBzZW5kIGEgbWVzc2FnZSB3aXRoIHN1Ympl Y3Qgb3IgYm9keSAnaGVscCcgdG8NCglmcmVlYnNkLXN0YWJsZS1yZXF1ZXN0QGZyZWVic2Qub3Jn DQoNCllvdSBjYW4gcmVhY2ggdGhlIHBlcnNvbiBtYW5hZ2luZyB0aGUgbGlzdCBhdA0KCWZyZWVi c2Qtc3RhYmxlLW93bmVyQGZyZWVic2Qub3JnDQoNCldoZW4gcmVwbHlpbmcsIHBsZWFzZSBlZGl0 IHlvdXIgU3ViamVjdCBsaW5lIHNvIGl0IGlzIG1vcmUgc3BlY2lmaWMNCnRoYW4gIlJlOiBDb250 ZW50cyBvZiBmcmVlYnNkLXN0YWJsZSBkaWdlc3QuLi4iDQoNCg0KVG9kYXkncyBUb3BpY3M6DQoN CiAgIDEuIEF1ZGlvIChSZWNvcmQpIG5vdCBmdW5jdGlvbmluZy4uLiAocmVjb3JkIGludGVycnVw dCB0aW1lb3V0KQ0KICAgICAgKEJlbiBILikNCiAgIDIuIFJlOiBCSU5ELTkuMy4yIChmcm9tIDUu NS1TVEFCTEUpIHNlZ2ZhdWx0IHVuZGVyIGxvYWQuLi4NCiAgICAgIChDaHVjayBTd2lnZXIpDQog ICAzLiA2LjItUkMyIGF0a2JkMCBmcmVlemVzIHN5c3RlbSAoR2FyZG5lciBCZWxsKQ0KICAgNC4g bXB0MCB0aW1lZCBvdXQgKHdzaykNCiAgIDUuIFJlOiA2LjItUFJFOiBGYXRhbCBUcmFwPyAoQ2hy aXMpDQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQpNZXNzYWdlOiAxDQpEYXRlOiBTYXQsIDMwIERlYyAy MDA2IDE5OjUxOjUxIC0wODAwIChQU1QpDQpGcm9tOiAiQmVuIEguIiA8c3RyYmVuanJAeWFob28u Y29tPg0KU3ViamVjdDogQXVkaW8gKFJlY29yZCkgbm90IGZ1bmN0aW9uaW5nLi4uIChyZWNvcmQg aW50ZXJydXB0IHRpbWVvdXQpDQpUbzogcXVlc3Rpb25zIEZCU0QgPGZyZWVic2QtcXVlc3Rpb25z QEZyZWVCU0QuT1JHPiwJU3RhYmxlIEZCU0QNCgk8ZnJlZWJzZC1zdGFibGVARnJlZUJTRC5PUkc+ DQpNZXNzYWdlLUlEOiA8MjAwNjEyMzEwMzUxNTEuNjgzNTAucW1haWxAd2ViMzMwMDUubWFpbC5t dWQueWFob28uY29tPg0KQ29udGVudC1UeXBlOiB0ZXh0L3BsYWluOyBjaGFyc2V0PWFzY2lpDQoN ClRoYW5rcyBpbiBhZHZhbmNlIGZvciBhbnkgaGVscCB5b3UgY2FuIHByb3ZpZGUuLi4gIE9uIHJl cGx5IHBsZWFzZSBjYyBteSBlbWFpbCBhZGRyZXNzLg0KDQpodHRwOi8vd3d3LmJzZGZvcnVtcy5v cmcvZm9ydW1zL3Nob3d0aHJlYWQucGhwP3Q9NDU1MTQgIFtISVNUT1JZXQ0KDQoNCmh0dHA6Ly9s aXN0cy5mcmVlYnNkLm9yZy9waXBlcm1haWwvLi4ucmNoLzAwMzg3Ny5odG1sIFtSZWxhdGVkIExp bmtdDQoNCg0KDQpJIGFtIHRyeWluZyB0byBnZXQgU2t5cGUgIG9yIFZvbmFnZSBzb2Z0cGhvbmUo dmlhIHdpbmUpIHdvcmtpbmcgb24gbXkgbm90ZWJvb2suDQoNCg0KDQpNeSBwcm9ibGVtIGlzIGdl dHRpbmcgdGhlIGlucHV0IGZyb20gdGhlIG1pYyB0byB0aGUgYXBwbGljYXRpb24uDQoNCg0KDQpU aGUgIm1pYyIgaXMgd29ya2luZyBiZWNhdXNlIEkgY2FuIHRhbGsgYW5kIGhlYXIgdGhlIHNvdW5k IHZpYSB0aGUNCmV4dGVybmFsIHNwZWFrZXJzLiBJZiAob24gY29tbWFuZCBsaW5lIG1peGVyKSBJ IHR1cm4gdGhlICJyZWMiIGFuZA0KImlnYWluIiB0byAwIHRoZSBJIENBTiBzdGlsbCBoZWFyIGFu eSBzb3VuZCBJIG1ha2UgdmlhIHRoZSBtaWMgb24gdGhlDQphdHRhY2hlZCBzcGVha2Vycy4gSWYg SSB0dXJuICJtaWMiIHRvIDAgdGhlbiBJIGNhbm5vdCBoZWFyIGFueSBzb3VuZCBJDQptYWtlIHZp YSB0aGUgbWljIG9uIHRoZSBhdHRhY2hlZCBzcGVha2Vycy4gDQoNCg0KDQpIZXJlIGlzIHRoZSBl cnJvciBJIGFtIHNlZWluZyBvbiB0aGUgc3lzdGVtIGNvbnNvbGU6DQoNCg0KDQogICAgIHBjbTA6 cmVjb3JkOjA6ZHNwMC4wOiByZWNvcmQgaW50ZXJydXB0IHRpbWVvdXQsIGNoYW5uZWwgZGVhZA0K DQoNCg0KSGVyZSBhcmUgbXkgc2V0dGluZ3M6DQoNCg0KDQp1c2VyQHNvbnkkIHVuYW1lIC1hDQoN CkZyZWVCU0Qgc29ueS5mYW1pbHkuaG9tIDYuMi1QUkVSRUxFQVNFIEZyZWVCU0QgNi4yLVBSRVJF TEVBU0UgIzI6IFR1ZSBEZWMgMTkgMTY6NTU6NTAgRVNUIDIwMDYgICAgIHJvb3RAc29ueS5mYW1p bHkuaG9tOi91c3Ivb2JqL3Vzci9zcmMvc3lzL1NPTlkwMSAgaTM4Ng0KDQoNCg0KdXNlckBzb255 JCBjYXQgL2Rldi9zbmRzdGF0DQoNCkZyZWVCU0QgQXVkaW8gRHJpdmVyIChuZXdwY20pDQoNCklu c3RhbGxlZCBkZXZpY2VzOg0KDQpwY20wOiA8QWNlciBMYWJzIE01NDUxPiBhdCBpbyAweDE4MDAg aXJxIDkga2xkIHNuZF90NGR3YXZlICg0cC8xci80diBjaGFubmVscyBkdXBsZXggZGVmYXVsdCkN Cg0KDQoNCnVzZXJAc29ueSQgZG1lc2cgfCBncmVwIHBjbQ0KDQpwY20wOiA8QWNlciBMYWJzIE01 NDUxPiBwb3J0IDB4MTgwMC0weDE4ZmYgbWVtIDB4ZTgxMDAwMDAtMHhlODEwMGZmZiBhdCBkZXZp Y2UgNi4wIG9uIHBjaTANCg0KcGNtMDogPFlhbWFoYSBZTUY3NTMgQUM5NyBDb2RlYz4NCg0KcGNt MDogW0dJQU5ULUxPQ0tFRF0NCg0KcGNtMDpyZWNvcmQ6MDpkc3AwLjA6IHJlY29yZCBpbnRlcnJ1 cHQgdGltZW91dCwgY2hhbm5lbCBkZWFkDQoNCnBjbTA6cmVjb3JkOjA6ZHNwMC4wOiByZWNvcmQg aW50ZXJydXB0IHRpbWVvdXQsIGNoYW5uZWwgZGVhZA0KDQoNCg0KdXNlckBzb255JCBzeXNjdGwg aHcuc25kDQoNCmh3LnNuZC5yZXBvcnRfc29mdF9mb3JtYXRzOiAxDQoNCmh3LnNuZC50YXJnZXRp cnFyYXRlOiAzMg0KDQpody5zbmQudmVyYm9zZTogMQ0KDQpody5zbmQubWF4YXV0b3ZjaGFuczog NA0KDQpody5zbmQudW5pdDogMA0KDQpody5zbmQucGNtMC5idWZmZXJzaXplOiA0MDk2DQoNCmh3 LnNuZC5wY20wLnZjaGFuczogNA0KDQoNCk1vcmUgaW5mbyBhdDogIGh0dHA6Ly93d3cuYnNkZm9y dW1zLm9yZy9mb3J1bXMvc2hvd3RocmVhZC5waHA/dD00NjQ2OQ0KDQoNCiAgU1RSQmVuDQpzdHJi ZW5qcnthfXlhaG9vLmNvbSANCiBiZW5faGFja2Vye2F9aW50ZXItb3AubmV0IA0KLS0gLS0gLS0g DQogaHR0cDovL3d3dy5jb2ViYS5vcmcgDQogaHR0cDovL3d3dy5pbnRlci1vcC5uZXQNCg0KDQoN Cg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KTWVzc2FnZTogMg0KRGF0ZTog U3VuLCAzMSBEZWMgMjAwNiAxMTo0NTo0MyAtMDUwMA0KRnJvbTogQ2h1Y2sgU3dpZ2VyIDxjc3dp Z2VyQG1hYy5jb20+DQpTdWJqZWN0OiBSZTogQklORC05LjMuMiAoZnJvbSA1LjUtU1RBQkxFKSBz ZWdmYXVsdCB1bmRlciBsb2FkLi4uDQpUbzogRG91ZyBCYXJ0b24gPGRvdWdiQEZyZWVCU0Qub3Jn Pg0KQ2M6IEZyZWVCU0QgbWFpbGluZyBsaXN0IDxmcmVlYnNkLXN0YWJsZUBmcmVlYnNkLm9yZz4N Ck1lc3NhZ2UtSUQ6IDw0NTk3RTkzNy45MDMwMEBtYWMuY29tPg0KQ29udGVudC1UeXBlOiB0ZXh0 L3BsYWluOyBjaGFyc2V0PUlTTy04ODU5LTE7IGZvcm1hdD1mbG93ZWQNCg0KRG91ZyBCYXJ0b24g d3JvdGU6DQo+IENodWNrIFN3aWdlciB3cm90ZToNCj4+IEhpLS0NCj4+DQo+PiBJIGhhZCBuYW1l ZCBzZWdmYXVsdCBhIGRheSBvciBzbyBhZ28gdW5kZXIgaGlnaCBsb2FkICgiYWRuc2xvZ3JlcyAt Yw0KPj4gMjAwIiBhZ2FpbnN0IGEgd2Vic2VydmVyIGxvZ2ZpbGUpIGFmdGVyIGxvZ2dpbmcgdGhl IGZvbGxvd2luZzoNCj4gDQo+IEhhcmQgdG8gdGVsbCBpZiB5b3VyIHByb2JsZW0gaGVyZSBpcyBy ZWxhdGVkIHRvIHJ1bm5pbmcgb24gNS41IG9yIG5vdCwNCj4gYnV0IG9mIGNvdXJzZSByZWNvbW1l bmRhdGlvbiBudW1iZXIgb25lIGlzIHRvIGNvbnNpZGVyIHVwZ3JhZGluZyB0bw0KPiA2LnguIFJl Y29tbWVuZGF0aW9uIG51bWJlciB0d28gaXMgdG8gdXBncmFkZSBCSU5EIHRvIDkuMy4zLCBwcmVm ZXJhYmx5DQo+IGJ5IHVwZ3JhZGluZyB0byA2LjItUkMyLCBvciBieSB1cGdyYWRpbmcgdG8gdGhl IGhlYWQgb2YgUkVMRU5HXzUsIG9yDQo+IGFzIGEgbGFzdCByZXNvcnQgYnkgdXNpbmcgdGhlIHBv cnQsIHdpdGggb3Igd2l0aG91dCB0aGUgb3B0aW9uIHRvDQo+IHJlcGxhY2UgdGhlIGJhc2UgQklO RC4NCg0KTm90ZWQsIHRoYW5rcy4gIEkndmUgYmVlbiBmb2xsb3dpbmcgNi1TVEFCTEUgb24gYSBw YWlyIG9mIHRlc3QgbWFjaGluZXMsIGJ1dCANCkkndmUgcmVjZW50bHkgYmVlbiBiaXR0ZW4gYnkg d2hhdGV2ZXIgdGhlIGJ1ZyB3YXMgZWFybGllciB0aGlzIHdlZWsgb3IgbGFzdCANCndoaWNoIHJl c3VsdGVkIGluIGRhZW1vbiBwcm9jZXNzZXMgZHlpbmcgZWFybHkgaW4gdGhlIGJvb3QsIHNvIEkn ZCBwcmVmZXIgdG8gDQpiZSBhIGJpdCBtb3JlIGNvbnNlcnZhdGl2ZSB1bnRpbCA2LVNUQUJMRSBz ZXR0bGVzIGRvd24gbW9yZS4NCg0KPj4gWyAuLi4gXQ0KPj4+IERlYyAyOCAwMzozODo1NiA8ZGFl bW9uLm5vdGljZT4gcGkgbmFtZWRbMTg1M106IGVuZm9yY2VkDQo+Pj4gZGVsZWdhdGlvbi1vbmx5 IGZvciAnQVInIChjdGluYS5hci9BL0lOKSBmcm9tIDEzNy4zOS4xLjMjNTMNCj4gDQo+IElmIHlv dSdyZSB1c2luZyB0aGlzIG9wdGlvbiwgcGxlYXNlIG1ha2Ugc3VyZSB0aGF0IHlvdSBrbm93IHdo eSB5b3UNCj4gYXJlIHVzaW5nIGl0LCBhbmQgd2hhdCB0aGUgcG90ZW50aWFsIHNpZGUgZWZmZWN0 cyBhcmUuIFRoYXQgZGlzY3Vzc2lvbg0KPiBpcyBvZmYgdG9waWMgZm9yIHRoaXMgbGlzdCwgYnV0 IGZlZWwgZnJlZSB0byB0YWtlIGl0IHVwIG9uDQo+IGJpbmQtdXNlcnNAaXNjLm9yZyBpZiB5b3Ug d2lzaC4NCg0KVGhlIHByaW1hcnkgZnVuY3Rpb24gb2YgdGhlIG1hY2hpbmUgaW4gcXVlc3Rpb24g aXMgYSBTTVRQIHJlbGF5OyBhIHNlY29uZGFyeSANCm1ham9yIHB1cnBvc2UgaXMgcnVubmluZyBB cGFjaGUuICBIYXZpbmcgdmFyaW91cyB0b3AtbGV2ZWwgZG9tYWlucyByZXR1cm4gDQpub24tZGVs ZWdhdGlvbiByZWNvcmRzIChpZSBTaXRlRmluZGVyKSBicmVha3Mgc29tZSBvZiBteSBhbnRpLXNw YW0gY2hlY2tpbmcuLi4NCg0KPj4+IERlYyAyOCAwMzo1MDoyMyA8ZGFlbW9uLndhcm4+IHBpIG5h bWVkWzE4NTNdOiBjbGllbnQgMTI3LjAuMC4xIzUzMDc3Og0KPj4+IG5vIG1vcmUgcmVjdXJzaXZl IGNsaWVudHM6IHF1b3RhIHJlYWNoZWQNCj4gDQo+IFRoZXJlIGlzIGV4dGVuc2l2ZSBkaXNjdXNz aW9uIGFib3V0IHRoaXMgcHJvYmxlbSBpbiB0aGUgYmluZC11c2Vycw0KPiBhcmNoaXZlcy4gVGFr ZSBhIGxvb2sgYXQgZmlsZTovLy91c3Ivc2hhcmUvZG9jL2JpbmQ5L2FybS8gYW5kIGNoZWNrDQo+ IG91dCB0aGUgcXVvdGEgb3B0aW9ucyB0byBnZXQgdGhpcyBhZGp1c3RlZCB0byB3aGVyZSBpdCBu ZWVkcyB0byBiZSBmb3INCj4geW91ciBzaXR1YXRpb24uIEFsdGVybmF0aXZlbHksIGlmIHlvdSdy ZSBzdXJlIHRoYXQgdGhlIGV4Y2VzcyBsb2FkIGlzDQo+IGNhdXNlZCBieSB0aGUgYWRuc2xvZ3Jl cyBwcm9ncmFtLCB0cnkgbG93ZXJpbmcgdGhlIG51bWJlciBvZg0KPiBjb25jdXJyZW50IGNvbm5l Y3Rpb25zLg0KDQpJJ20gcXVpdGUgc3VyZSB0aGUgbG9hZCBpcyBiZWluZyBjYXVzZWQgYnkgYWRu c2xvZ3JlczsgdGhlICItYyAyMDAiIGZsYWcgDQpyZWZlcnMgdG8gdGhlIG51bWJlciBvZiBvdXRz dGFuZGluZyBjb25uZWN0aW9uIHJlcXVlc3RzIHRoYXQgcHJvZ3JhbSB3aWxsIA0KY3JlYXRlLiAg V2hlbiBwZXJmb3JtaW5nIEROUyByZXNvbHV0aW9uIG9mIHZhcmlvdXMgSVBzIGZyb20gYSBsb2dm aWxlLCB0aGUgDQptb3JlIGNvbm5lY3Rpb25zIHBlcm1pdHRlZCwgdGhlIGZhc3RlciB0aGUgcmVz b2x1dGlvbiBvZiB0aGUgZmlsZSBjb21wbGV0ZXMgYXMgDQp5b3UgYXJlIG1vc3RseSBiZWluZyBo ZWxkIHVwIGJ5IG5vbi1yZXNwb25zaXZlIG5hbWVzZXJ2ZXJzIHdoaWNoIHdpbGwgdGltZS1vdXQu DQoNCldoYXQgc3RyaWtlcyBtZSBhcyBvZGQgaXMgdGhhdCB0aGUgQklORCBkb2NzIGNsYWltIHRo YXQgcmVjdXJzaXZlLWNsaWVudHMgDQpkZWZhdWx0cyB0byBhIHZhbHVlIG9mIDEwMDAuLi4/ICBU aGUgbmFtZWQgcHJvY2Vzc2VzJyBtZW1vcnkgdXNhZ2Ugc2hvb3RzIHVwIA0KZnJvbSBhIG5vbWlu YWwgc3RhcnRpbmcgcG9pbnQgb2YgNSBNQiB0byBhcm91bmQgNDUgTUIgYWZ0ZXIgYmVpbmcgcXVl cmllZCANCnVuZGVyIHRoaXMgbG9hZC4NCg0KQW55d2F5LCBJJ3ZlIHJlZHVjZWQgYWRuc2xvZ3Jl cyB0byB1c2luZyA1MCBvdXRzdGFuZGluZyBjb25uZWN0aW9uIHJlcXVlc3RzLg0KDQo+PiBBcyB0 aGUgc3ViamVjdCBtZW50aW9ucywgdGhpcyBpcyBhIERlbGwgMTg1MCAocmFja21vdW50IFBvd2Vy RWRnZSkNCj4+IHJ1bm5pbmcgRnJlZUJTRC01LjUgJiBCSU5ELTkuMy4yOyB1bnRpbCBqdXN0IG5v dywgZXZlcnl0aGluZyBoYWQgYmVlbg0KPj4gcnVubmluZyBzdGFibHkgZm9yIG1vbnRocyBhdCBh IHRpbWUuDQo+IA0KPiBJIGFzc3VtZSB5b3UndmUgY2hlY2tlZCB0aGUgdXN1YWwgc3VzcGVjdHMs IGRlYWQgZmFucywgb3RoZXIgaGFyZHdhcmUNCj4gcHJvYmxlbXMsIGV0Yz8NCg0KV2l0aGluIHJl YXNvbiwgeWVzLiAgSSBoYXZlbid0IHRha2VuIHRoZSBzeXN0ZW0gZG93biB0byBwZXJmb3JtIDI0 LWhvdXJzIG9mIA0KdGVzdGluZyB3aXRoIE1lbXRlc3Q4NiBvciBzb21ldGhpbmcgbGlrZSB0aGF0 LCBidXQgdGhlIGZhbnMgYXJlIE9LIChpdCdzIGEgDQpQMy1iYXNlZCBzeXN0ZW07IGl0IGRvZXNu J3QgcnVuIG5lYXJseSBhcyBob3QgYXMgdGhlIGxhdGVyIFhlb24tYmFzZWQgbW9kZWxzKSwgDQph bmQgdGhlcmUgYXJlIG5vIEVDQyB3YXJuaW5ncyBmcm9tIHRoZSBSQU0sIGFuZCBkcml2ZXMgYXJl IGluIGEgUkFJRC0xIG1pcnJvciANCndoaWNoIGlzIHJlcG9ydGluZyBubyBzaWducyBvZiB0cm91 YmxlLg0KDQpUaGFua3MgZm9yIHlvdXIgZmVlZGJhY2ssDQotLSANCi1DaHVjaw0KDQoNCi0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQpNZXNzYWdlOiAzDQpEYXRlOiBTdW4sIDMxIERl YyAyMDA2IDE0OjM4OjU1IC0wNTAwIChFU1QpDQpGcm9tOiBHYXJkbmVyIEJlbGwgPGdiZWxsNzJA cm9nZXJzLmNvbT4NClN1YmplY3Q6IDYuMi1SQzIgYXRrYmQwIGZyZWV6ZXMgc3lzdGVtDQpUbzog ZnJlZWJzZC1zdGFibGVAZnJlZWJzZC5vcmcNCk1lc3NhZ2UtSUQ6IDwyMDA2MTIzMTE5Mzg1NS45 NDkyLnFtYWlsQHdlYjg4MDEzLm1haWwucmUyLnlhaG9vLmNvbT4NCkNvbnRlbnQtVHlwZTogdGV4 dC9wbGFpbjsgY2hhcnNldD1pc28tODg1OS0xDQoNCkltbWVkaWF0ZWx5IGFmdGVyIGJvb3Rpbmcg aW50byA2LjItUkMyIG15IHN5c3RlbSBmcm96ZSB1cCBhbmQgZHJvcHBlZA0KaW50byBkZGIuICBI ZXJlIGlzIHRoZSByZWxldmFudCBpbmZvcm1hdGlvbi4gIElmIGFueSBmdXJ0aGVyIGluZm8gaXMN CnJlcXVpcmVkIHBsZWFzZSBsZXQgbWUga25vdy4NCg0KZGI+IHRyYWNlDQpUcmFjaW5nIHBpZCAy NCB0aWQgMTAwMDIwIHRkIDB4ZmZmZmZmMDAzZDgwNzAwMA0Ka2RiX2VudGVyKCkgYXQga2RiX2Vu dGVyKzB4MmYNCnNjZ2V0YygpIGF0IHNjZ2V0YysweDM0Mg0Kc2NrYmRldmVudCgpIGF0IHNja2Jk ZXZlbnQrMHg4Mw0KYXRrYmRfaW50cigpIGF0IGF0a2JkX2ludHIrMHg1Mw0KaXRocmVhZF9sb29w KCkgYXQgaXRocmVhZF9sb29wKzB4MTYzDQpmb3JrX2V4aXQoKSBhdCBmb3JrX2V4aXQrMHg4Ng0K Zm9ya190cmFtcG9saW5lKCkgYXQgZm9ya190cmFtcG9saW5lKzB4ZQ0KLS0tIHRyYXAgMCwgcmlw ID0gMCwgcnNwID0gMHhmZmZmZmZmZmE1MzE4ZDAwLCByYnAgPSAwIC0tLQ0KDQpkYj4gcw0KW3Ro cmVhZCBwaWQgMjQgdGlkIDEwMDAyMF0NClN0b3BwZWQgYXQga2RiX2VudGVyKzB4MzA6IGxlYXZl DQoNCmRiPiBwcw0KcGlkICBwcGlkIHBncnAgdWlkICBzdGF0ZSB3bWVzZyAgIHdjaGFuICAgICAg ICAgICAgICAgY21kDQo2MTMgIDYwNiAgNjEzICAxMDAxIFMrICAgIHNlbGVjdCAgMHhmZmZmZmZm ZjgwNGM4YmIwICB0b3ANCjYwNiAgNTgxICA2MDYgIDEwMDEgUysgICAgd2FpdCAgICAweGZmZmZm ZjAwMmUwMjEzNTggIHNoDQo2MDAgIDU4MCAgNjAwICAxMDAxIFMrICAgIHR0eWluICAgMHhmZmZm ZmYwMDAwNzdlODEwICBzaA0KNTgzICAgIDEgIDU4MyAgICAgMCBTcysgICB0dHlpbiAgIDB4ZmZm ZmZmMDAwMDY4NGMxMCAgZ2V0dHkNCjU4MiAgICAxICA1ODIgICAgIDAgU3MrICAgdHR5aW4gICAw eGZmZmZmZjAwMDA2ODU4MTAgIGdldHR5DQo1ODEgICAgMSAgNTgxICAgICAwIFNzKyAgIHdhaXQg ICAgMHhmZmZmZmYwMDNkODBlYTA4ICBsb2dpbg0KNTgwICAgIDEgIDU4MCAgICAgMCBTcysgICB3 YWl0ICAgIDB4ZmZmZmZmMDAyZGUxZWEwOCAgbG9naW4NCjU3OCAgNTc3ICAgMzQgICAgIDAgUysg ICAgbmFuc2xwICAweGZmZmZmZmZmODA0YmJiNjAgIHNsZWVwDQo1NzcgIDU3NSAgIDM0ICAgICAw IFMrICAgIHdhaXQgICAgMHhmZmZmZmYwMDI1NjE1MDAwICBzaA0KNTc2ICAgIDEgICAzNCAgICAg MCBTKyAgICBwaXBlcmQgIDB4ZmZmZmZmMDAyNmMxODkwMCAgbG9nZ2VyDQo1NzUgICAgMSAgIDM0 ICAgICAwIFMrICAgIHdhaXQgICAgMHhmZmZmZmYwMDJmZGRmMDAwICBzaA0KNTM1ICAgIDEgIDUz NSAgICAgMCBTcyAgICBuYW5zbHAgIDB4ZmZmZmZmZmY4MDRiYmI2MCAgY3Jvbg0KNDE1ICAgIDEg IDQxNSAgICAgMCBTcyAgICBzZWxlY3QgIDB4ZmZmZmZmZmY4MDRjOGJiMCAgc3lzbG9nZA0KMjk0 ICAgIDEgIDI5NCAgICA2NSBTcyAgICBzZWxlY3QgIDB4ZmZmZmZmZmY4MDRjOGJiMCAgZGhjbGll bnQNCjI3NCAgICAxICAgMzQgICAgIDAgUysgICAgc2VsZWN0ICAweGZmZmZmZmZmODA0YzhiYjAg IGRoY2xpZW50DQoxNDUgICAgMSAgMTQ1ICAgICAwIFNzICAgIHBhdXNlICAgMHhmZmZmZmYwMDI1 NDEwNzE4ICBhZGprZXJudHoNCiAzMyAgICAwICAgIDAgICAgIDAgU0wgICAgICAtICAgICAweGZm ZmZmZmZmYTUzNGZiZTQgIFtzY2hlZGNwdV0NCiAzMiAgICAwICAgIDAgICAgIDAgU0wgICAgc2Rm bHVzaCAweGZmZmZmZmZmODA0Y2Q1YTAgIFtzb2Z0ZGVwZmx1c2hdDQogMzEgICAgMCAgICAwICAg ICAwIFNMICAgIHN5bmNlciAgMHhmZmZmZmZmZjgwNGJiODQwICBbc3luY2VyXQ0KIDMwICAgIDAg ICAgMCAgICAgMCBTTCAgICB2bHJ1d3QgIDB4ZmZmZmZmMDAzZGFhNmEwOCAgW3ZubHJ1XQ0KIDI5 ICAgIDAgICAgMCAgICAgMCBTTCAgICBwc2xlZXAgIDB4ZmZmZmZmZmY4MDRjOTQ3OCAgW2J1ZmRh ZW1vbl0NCiAyOCAgICAwICAgIDAgICAgIDAgU0wgICAgcGd6ZXJvICAweGZmZmZmZmZmODA0ZDI3 MjAgIFtwYWdlemVyb10NCiAyNyAgICAwICAgIDAgICAgIDAgU0wgICAgcHNsZWVwICAweGZmZmZm ZmZmODA0Y2U1ZWMgIFt2bWRhZW1vbl0NCiAyNiAgICAwICAgIDAgICAgIDAgU0wgICAgcHNsZWVw ICAweGZmZmZmZmZmODA0Y2U1OWMgIFtwYWdlZGFlbW9uXQ0KIDI1ICAgIDAgICAgMCAgICAgMCBX TCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgW3N3aTA6IHNpb10NCiAyNCAgICAwICAg IDAgICAgIDAgUkwgICAgQ1BVIDAgICAgICAgICAgICAgICAgICAgICAgIFtpcnExOiBhdGtiZDBd DQogMjMgICAgMCAgICAwICAgICAwIFdMICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBb aXJxMjk6IGJnZTFdDQogMjIgICAgMCAgICAwICAgICAwIFdMICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBbaXJxMjg6IGJnZTBdDQogMjEgICAgMCAgICAwICAgICAwIFdMICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBbaXJxMTU6IGF0YTFdDQogMjAgICAgMCAgICAwICAgICAw IFdMICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBbaXJxMTQ6IGF0YTBdDQogMTkgICAg MCAgICAwICAgICAwIFdMICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBbaXJxOTogYWNw aTBdDQogIDkgICAgMCAgICAwICAgICAwIFNMICAgICAgLSAgICAgMHhmZmZmZmYwMDAwMDk2YTAw ICBba3F1ZXVlX3Rhc2txXQ0KICA4ICAgIDAgICAgMCAgICAgMCBTTCAgICAgIC0gICAgIDB4ZmZm ZmZmMDAwMDA5NmIwMCAgW2FjcGlfdGFza18yXQ0KICA3ICAgIDAgICAgMCAgICAgMCBTTCAgICAg IC0gICAgIDB4ZmZmZmZmMDAwMDA5NmIwMCAgW2FjcGlfdGFza18xXQ0KICA2ICAgIDAgICAgMCAg ICAgMCBTTCAgICAgIC0gICAgIDB4ZmZmZmZmMDAwMDA5NmIwMCAgW2FjcGlfdGFza18wXQ0KIDE4 ICAgIDAgICAgMCAgICAgMCBXTCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgW3N3aTY6 IHRhc2sNCnF1ZXVlXQ0KIDE3ICAgIDAgICAgMCAgICAgMCBXTCAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgW3N3aTY6IEdpYW50DQp0YXNrcV0NCiAgNSAgICAwICAgIDAgICAgIDAgU0wg ICAgICAtICAgICAweGZmZmZmZjAwMDA4MDQxMDAgIFt0aHJlYWQgdGFza3FdDQogMTYgICAgMCAg ICAwICAgICAwIFdMICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBbc3dpNTogK10NCiAx NSAgICAwICAgIDAgICAgIDAgU0wgICAgICAtICAgICAweGZmZmZmZmZmODA0YjY2YzAgIFt5YXJy b3ddDQogIDQgICAgMCAgICAwICAgICAwIFNMICAgICAgLSAgICAgMHhmZmZmZmZmZjgwNGI3Mjg4 ICBbZ19kb3duXQ0KICAzICAgIDAgICAgMCAgICAgMCBTTCAgICAgIC0gICAgIDB4ZmZmZmZmZmY4 MDRiNzI4MCAgW2dfdXBdDQogIDIgICAgMCAgICAwICAgICAwIFNMICAgICAgLSAgICAgMHhmZmZm ZmZmZjgwNGI3MjcwICBbZ19ldmVudF0NCiAxNCAgICAwICAgIDAgICAgIDAgV0wgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIFtzd2kxOiBuZXRdDQogMTMgICAgMCAgICAwICAgICAwIFdM ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBbc3dpMzogdm1dDQogMTIgICAgMCAgICAw ICAgICAwIFdMICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBbc3dpNDogY2xvY2sgc2lv XQ0KIDExICAgIDAgICAgMCAgICAgMCBSTCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg W2lkbGU6IGNwdTBdDQogMTAgICAgMCAgICAwICAgICAwIFJMICAgICAgQ1BVMSAgICAgICAgICAg ICAgICAgICAgICBbaWRsZTogY3B1MV0NCiAgMSAgICAwICAgIDEgICAgIDAgU0xzICAgICB3YWl0 ICAweGZmZmZmZjAwM2RiNWMwMDAgIFtpbml0XQ0KICAwICAgIDAgICAgMCAgICAgMCBXTHMgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgW3N3YXBwZXJdDQoNCmRiPiBzaG93IHBjcHUNCmNw dWlkICAgICAgICA9IDANCmN1cnRocmVhZCAgICA9IDB4ZmZmZmZmMDAzZDgwNzAwMDogcGlkIDI0 ICJpcnExOiBhdGtiZDAiDQpjdXJwY2IgICAgICAgPSAweGZmZmZmZmZmYTUzMThkMTANCmZwY3Vy dGhyZWFkICA9IG5vbmUNCmlkbGV0aHJlYWQgICA9IDB4ZmZmZmZmMDAzZGI1ODk4MDogcGlkIDEx ICJpZGxlOiBjcHUwIiANCg0KSSBoYWQgdG8gbWFudWFsbHkgdHlwZSB0aGlzIGFsbCBpbiBhcyBJ IGRvbid0IGhhdmUgYSBudWxsIG1vZGVtDQphdmFpbGFibGUgd2hlcmUgSSBhbS4gIFBsZWFzZSBD YyBtZSBhcyBJJ20gbm90IHN1YnNjcmliZWQgdG8gdGhlIGxpc3QuDQoNClJlZ2FyZHMNCg0KR2Fy ZG5lcg0KDQoNCg0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQpNZXNzYWdl OiA0DQpEYXRlOiBNb24sIDAxIEphbiAyMDA3IDE4OjE3OjA5ICswMDAwDQpGcm9tOiB3c2sgPHdz a0BnZGRzbi5vcmcuY24+DQpTdWJqZWN0OiBtcHQwIHRpbWVkIG91dA0KVG86IHN0YWJsZUBmcmVl YnNkLm9yZywgY3VycmVudEBmcmVlYnNkLm9yZw0KTWVzc2FnZS1JRDogPDQ1OTk1MDI1LjgwMDAx MDNAZ2Rkc24ub3JnLmNuPg0KQ29udGVudC1UeXBlOiB0ZXh0L3BsYWluOyBjaGFyc2V0PUdCMjMx Mg0KDQpoaSwgc2NzaSBjYXJkIGNvbm5lY3RlZCB0byBhIGRpc2sgYXJyYXkuYW5kIGdldCBmb2xs b3cgZXJyb3IgYWZ0ZXIgbGVzcw0KdGhhbiAxMCBkYXlzDQp0aGFua3MgaW4gYWR2YW5jZS4NCg0K bXB0MDogPExTSUxvZ2ljIDEwMzAgVWx0cmE0IEFkYXB0ZXI+IHBvcnQgMHhjYzAwLTB4Y2NmZiBt ZW0NCjB4ZmNlZjAwMDAtMHhmY2VmZmZmDQpmLDB4ZmNlZTAwMDAtMHhmY2VlZmZmZiBpcnEgMjQg YXQgZGV2aWNlIDMuMCBvbiBwY2kyDQptcHQwOiBbR0lBTlQtTE9DS0VEXQ0KbXB0MDogTVBJIFZl cnNpb249MS4yLjEyLjANClRyeWluZyB0byBtb3VudCByb290IGZyb20gdWZzOi9kZXYvZGExczFh DQptcHQwOiByZXF1ZXN0IDB4YzRiZjlmZDA6MjI5NyB0aW1lZCBvdXQgZm9yIGNjYiAweGM2ZDIw MDAwIChyZXEtPmNjYg0KMHhjNmQyMDAwMCkNCm1wdDA6IGF0dGVtcHRpbmcgdG8gYWJvcnQgcmVx IDB4YzRiZjlmZDA6MjI5NyBmdW5jdGlvbiAwDQptcHQwOiBjb21wbGV0aW5nIHRpbWVkb3V0L2Fi b3J0ZWQgcmVxIDB4YzRiZjlmZDA6MjI5Nw0KbXB0MDogYWJvcnQgb2YgcmVxIDB4YzRiZjlmZDA6 MCBjb21wbGV0ZWQNCm1wdDA6IHJlcXVlc3QgMHhjNGJmYTQ1MDoyMzIxIHRpbWVkIG91dCBmb3Ig Y2NiIDB4YzZkMTdjMDAgKHJlcS0+Y2NiDQoweGM2ZDE3YzAwKQ0KbXB0MDogYXR0ZW1wdGluZyB0 byBhYm9ydCByZXEgMHhjNGJmYTQ1MDoyMzIxIGZ1bmN0aW9uIDANCm1wdDA6IGNvbXBsZXRpbmcg dGltZWRvdXQvYWJvcnRlZCByZXEgMHhjNGJmYTQ1MDoyMzIxDQptcHQwOiBhYm9ydCBvZiByZXEg MHhjNGJmYTQ1MDowIGNvbXBsZXRlZA0KbXB0MDogcmVxdWVzdCAweGM0YmZhNGUwOjIzMjQgdGlt ZWQgb3V0IGZvciBjY2IgMHhjNGJmMjAwMCAocmVxLT5jY2INCjB4YzRiZjIwMDApDQptcHQwOiBh dHRlbXB0aW5nIHRvIGFib3J0IHJlcSAweGM0YmZhNGUwOjIzMjQgZnVuY3Rpb24gMA0KbXB0MDog Y29tcGxldGluZyB0aW1lZG91dC9hYm9ydGVkIHJlcSAweGM0YmZhNGUwOjIzMjQNCm1wdDA6IGFi b3J0IG9mIHJlcSAweGM0YmZhNGUwOjAgY29tcGxldGVkDQptcHQwOiByZXF1ZXN0IDB4YzRiZmE2 NjA6MjMzMiB0aW1lZCBvdXQgZm9yIGNjYiAweGM2ZDE5MDAwIChyZXEtPmNjYg0KMHhjNmQxOTAw MCkNCm1wdDA6IGF0dGVtcHRpbmcgdG8gYWJvcnQgcmVxIDB4YzRiZmE2NjA6MjMzMiBmdW5jdGlv biAwDQptcHQwOiBjb21wbGV0aW5nIHRpbWVkb3V0L2Fib3J0ZWQgcmVxIDB4YzRiZmE2NjA6MjMz Mg0KbXB0MDogYWJvcnQgb2YgcmVxIDB4YzRiZmE2NjA6MCBjb21wbGV0ZWQNCm1wdDA6IHJlcXVl c3QgMHhjNGJmYTc4MDoyMzM4IHRpbWVkIG91dCBmb3IgY2NiIDB4YzZkMGU4MDAgKHJlcS0+Y2Ni DQoweGM2ZDBlODAwKQ0KbXB0MDogYXR0ZW1wdGluZyB0byBhYm9ydCByZXEgMHhjNGJmYTc4MDoy MzM4IGZ1bmN0aW9uIDANCm1wdDA6IGNvbXBsZXRpbmcgdGltZWRvdXQvYWJvcnRlZCByZXEgMHhj NGJmYTc4MDoyMzM4DQptcHQwOiBhYm9ydCBvZiByZXEgMHhjNGJmYTc4MDowIGNvbXBsZXRlZA0K bXB0MDogcmVxdWVzdCAweGM0YmZhODEwOjIzNDIgdGltZWQgb3V0IGZvciBjY2IgMHhjNmQyMDAw MCAocmVxLT5jY2INCjB4YzZkMjAwMDApDQptcHQwOiBhdHRlbXB0aW5nIHRvIGFib3J0IHJlcSAw eGM0YmZhODEwOjIzNDIgZnVuY3Rpb24gMA0KbXB0MDogY29tcGxldGluZyB0aW1lZG91dC9hYm9y dGVkIHJlcSAweGM0YmZhODEwOjIzNDINCm1wdDA6IGFib3J0IG9mIHJlcSAweGM0YmZhODEwOjAg Y29tcGxldGVkDQptcHQwOiByZXF1ZXN0IDB4YzRiZmE4NDA6MjM0NCB0aW1lZCBvdXQgZm9yIGNj YiAweGM2ZDE3YzAwIChyZXEtPmNjYg0KMHhjNmQxN2MwMCkNCm1wdDA6IGF0dGVtcHRpbmcgdG8g YWJvcnQgcmVxIDB4YzRiZmE4NDA6MjM0NCBmdW5jdGlvbiAwDQptcHQwOiBjb21wbGV0aW5nIHRp bWVkb3V0L2Fib3J0ZWQgcmVxIDB4YzRiZmE4NDA6MjM0NA0KbXB0MDogYWJvcnQgb2YgcmVxIDB4 YzRiZmE4NDA6MCBjb21wbGV0ZWQNCm1wdDA6IHJlcXVlc3QgMHhjNGJmYTg3MDoyMzQ2IHRpbWVk IG91dCBmb3IgY2NiIDB4YzRiZjIwMDAgKHJlcS0+Y2NiDQoweGM0YmYyMDAwKQ0KbXB0MDogYXR0 ZW1wdGluZyB0byBhYm9ydCByZXEgMHhjNGJmYTg3MDoyMzQ2IGZ1bmN0aW9uIDANCm1wdDA6IGNv bXBsZXRpbmcgdGltZWRvdXQvYWJvcnRlZCByZXEgMHhjNGJmYTg3MDoyMzQ2DQptcHQwOiBhYm9y dCBvZiByZXEgMHhjNGJmYTg3MDowIGNvbXBsZXRlZA0KbXB0MDogcmVxdWVzdCAweGM0YmZhOTAw OjIzNTAgdGltZWQgb3V0IGZvciBjY2IgMHhjNmQxOTAwMCAocmVxLT5jY2INCjB4YzZkMTkwMDAp DQptcHQwOiBhdHRlbXB0aW5nIHRvIGFib3J0IHJlcSAweGM0YmZhOTAwOjIzNTAgZnVuY3Rpb24g MA0KbXB0MDogY29tcGxldGluZyB0aW1lZG91dC9hYm9ydGVkIHJlcSAweGM0YmZhOTAwOjIzNTAN Cm1wdDA6IGFib3J0IG9mIHJlcSAweGM0YmZhOTAwOjAgY29tcGxldGVkDQptcHQwOiByZXF1ZXN0 IDB4YzRiZmE5MzA6MjM1MiB0aW1lZCBvdXQgZm9yIGNjYiAweGM2ZDBlODAwIChyZXEtPmNjYg0K MHhjNmQwZTgwMCkNCm1wdDA6IGF0dGVtcHRpbmcgdG8gYWJvcnQgcmVxIDB4YzRiZmE5MzA6MjM1 MiBmdW5jdGlvbiAwDQptcHQwOiBjb21wbGV0aW5nIHRpbWVkb3V0L2Fib3J0ZWQgcmVxIDB4YzRi ZmE5MzA6MjM1Mg0KbXB0MDogYWJvcnQgb2YgcmVxIDB4YzRiZmE5MzA6MCBjb21wbGV0ZWQNCm1w dDA6IHJlcXVlc3QgMHhjNGJmYTljMDoyMzU2IHRpbWVkIG91dCBmb3IgY2NiIDB4YzZkMjAwMDAg KHJlcS0+Y2NiDQoweGM2ZDIwMDAwKQ0KbXB0MDogYXR0ZW1wdGluZyB0byBhYm9ydCByZXEgMHhj NGJmYTljMDoyMzU2IGZ1bmN0aW9uIDANCm1wdDA6IGNvbXBsZXRpbmcgdGltZWRvdXQvYWJvcnRl ZCByZXEgMHhjNGJmYTljMDoyMzU2DQptcHQwOiBhYm9ydCBvZiByZXEgMHhjNGJmYTljMDowIGNv bXBsZXRlZA0KbXB0MDogcmVxdWVzdCAweGM0YmZhOWYwOjIzNTggdGltZWQgb3V0IGZvciBjY2Ig MHhjNmQxN2MwMCAocmVxLT5jY2INCjB4YzZkMTdjMDApDQptcHQwOiBhdHRlbXB0aW5nIHRvIGFi b3J0IHJlcSAweGM0YmZhOWYwOjIzNTggZnVuY3Rpb24gMA0KbXB0MDogY29tcGxldGluZyB0aW1l ZG91dC9hYm9ydGVkIHJlcSAweGM0YmZhOWYwOjIzNTgNCm1wdDA6IGFib3J0IG9mIHJlcSAweGM0 YmZhOWYwOjAgY29tcGxldGVkDQptcHQwOiByZXF1ZXN0IDB4YzRiZmFhMjA6MjM2MCB0aW1lZCBv dXQgZm9yIGNjYiAweGM0YmYyMDAwIChyZXEtPmNjYg0KMHhjNGJmMjAwMCkNCm1wdDA6IGF0dGVt cHRpbmcgdG8gYWJvcnQgcmVxIDB4YzRiZmFhMjA6MjM2MCBmdW5jdGlvbiAwDQptcHQwOiBjb21w bGV0aW5nIHRpbWVkb3V0L2Fib3J0ZWQgcmVxIDB4YzRiZmFhMjA6MjM2MA0KbXB0MDogYWJvcnQg b2YgcmVxIDB4YzRiZmFhMjA6MCBjb21wbGV0ZWQNCm1wdDA6IHJlcXVlc3QgMHhjNGJmYWFiMDoy MzY0IHRpbWVkIG91dCBmb3IgY2NiIDB4YzZkMTkwMDAgKHJlcS0+Y2NiDQoweGM2ZDE5MDAwKQ0K bXB0MDogYXR0ZW1wdGluZyB0byBhYm9ydCByZXEgMHhjNGJmYWFiMDoyMzY0IGZ1bmN0aW9uIDAN Cm1wdDA6IGNvbXBsZXRpbmcgdGltZWRvdXQvYWJvcnRlZCByZXEgMHhjNGJmYWFiMDoyMzY0DQpt cHQwOiBhYm9ydCBvZiByZXEgMHhjNGJmYWFiMDowIGNvbXBsZXRlZA0KbXB0MDogcmVxdWVzdCAw eGM0YmZhYWUwOjIzNjYgdGltZWQgb3V0IGZvciBjY2IgMHhjNmQwZTgwMCAocmVxLT5jY2INCjB4 YzZkMGU4MDApDQptcHQwOiBhdHRlbXB0aW5nIHRvIGFib3J0IHJlcSAweGM0YmZhYWUwOjIzNjYg ZnVuY3Rpb24gMA0KbXB0MDogY29tcGxldGluZyB0aW1lZG91dC9hYm9ydGVkIHJlcSAweGM0YmZh YWUwOjIzNjYNCm1wdDA6IGFib3J0IG9mIHJlcSAweGM0YmZhYWUwOjAgY29tcGxldGVkDQptcHQw OiByZXF1ZXN0IDB4YzRiZmFiNzA6MjM3MCB0aW1lZCBvdXQgZm9yIGNjYiAweGM2ZDIwMDAwIChy ZXEtPmNjYg0KMHhjNmQyMDAwMCkNCm1wdDA6IGF0dGVtcHRpbmcgdG8gYWJvcnQgcmVxIDB4YzRi ZmFiNzA6MjM3MCBmdW5jdGlvbiAwDQptcHQwOiBjb21wbGV0aW5nIHRpbWVkb3V0L2Fib3J0ZWQg cmVxIDB4YzRiZmFiNzA6MjM3MA0KbXB0MDogYWJvcnQgb2YgcmVxIDB4YzRiZmFiNzA6MCBjb21w bGV0ZWQNCm1wdDA6IHJlcXVlc3QgMHhjNGJmYWJhMDoyMzcyIHRpbWVkIG91dCBmb3IgY2NiIDB4 YzZkMTdjMDAgKHJlcS0+Y2NiDQoweGM2ZDE3YzAwKQ0KbXB0MDogYXR0ZW1wdGluZyB0byBhYm9y dCByZXEgMHhjNGJmYWJhMDoyMzcyIGZ1bmN0aW9uIDANCm1wdDA6IGNvbXBsZXRpbmcgdGltZWRv dXQvYWJvcnRlZCByZXEgMHhjNGJmYWJhMDoyMzcyDQptcHQwOiBhYm9ydCBvZiByZXEgMHhjNGJm YWJhMDowIGNvbXBsZXRlZA0KbXB0MDogcmVxdWVzdCAweGM0YmZhYmQwOjIzNzQgdGltZWQgb3V0 IGZvciBjY2IgMHhjNGJmMjAwMCAocmVxLT5jY2INCjB4YzRiZjIwMDApDQptcHQwOiBhdHRlbXB0 aW5nIHRvIGFib3J0IHJlcSAweGM0YmZhYmQwOjIzNzQgZnVuY3Rpb24gMA0KbXB0MDogY29tcGxl dGluZyB0aW1lZG91dC9hYm9ydGVkIHJlcSAweGM0YmZhYmQwOjIzNzQNCm1wdDA6IGFib3J0IG9m IHJlcSAweGM0YmZhYmQwOjAgY29tcGxldGVkDQptcHQwOiByZXF1ZXN0IDB4YzRiZmFjNjA6MjM3 OCB0aW1lZCBvdXQgZm9yIGNjYiAweGM2ZDE5MDAwIChyZXEtPmNjYg0KMHhjNmQxOTAwMCkNCm1w dDA6IGF0dGVtcHRpbmcgdG8gYWJvcnQgcmVxIDB4YzRiZmFjNjA6MjM3OCBmdW5jdGlvbiAwDQpt cHQwOiBjb21wbGV0aW5nIHRpbWVkb3V0L2Fib3J0ZWQgcmVxIDB4YzRiZmFjNjA6MjM3OA0KbXB0 MDogYWJvcnQgb2YgcmVxIDB4YzRiZmFjNjA6MCBjb21wbGV0ZWQNCm1wdDA6IHJlcXVlc3QgMHhj NGJmYWM5MDoyMzgwIHRpbWVkIG91dCBmb3IgY2NiIDB4YzZkMGU4MDAgKHJlcS0+Y2NiDQoweGM2 ZDBlODAwKQ0KbXB0MDogYXR0ZW1wdGluZyB0byBhYm9ydCByZXEgMHhjNGJmYWM5MDoyMzgwIGZ1 bmN0aW9uIDANCm1wdDA6IGNvbXBsZXRpbmcgdGltZWRvdXQvYWJvcnRlZCByZXEgMHhjNGJmYWM5 MDoyMzgwDQptcHQwOiBhYm9ydCBvZiByZXEgMHhjNGJmYWM5MDowIGNvbXBsZXRlZA0KbXB0MDog cmVxdWVzdCAweGM0YmZhZDIwOjIzODQgdGltZWQgb3V0IGZvciBjY2IgMHhjNmQyMDAwMCAocmVx LT5jY2INCjB4YzZkMjAwMDApDQptcHQwOiBhdHRlbXB0aW5nIHRvIGFib3J0IHJlcSAweGM0YmZh ZDIwOjIzODQgZnVuY3Rpb24gMA0KbXB0MDogY29tcGxldGluZyB0aW1lZG91dC9hYm9ydGVkIHJl cSAweGM0YmZhZDIwOjIzODQNCmdfdmZzX2RvbmUoKTpkYTBzMWRbV1JJVEUob2Zmc2V0PTY0MTMz NDg3MDAxNiwgbGVuZ3RoPTEzMTA3MildZXJyb3IgPSA1DQptcHQwOiBhYm9ydCBvZiByZXEgMHhj NGJmYWQyMDowIGNvbXBsZXRlZA0KbXB0MDogcmVxdWVzdCAweGM0YmZhZDUwOjIzODYgdGltZWQg b3V0IGZvciBjY2IgMHhjNmQxN2MwMCAocmVxLT5jY2INCjB4YzZkMTdjMDApDQptcHQwOiBhdHRl bXB0aW5nIHRvIGFib3J0IHJlcSAweGM0YmZhZDUwOjIzODYgZnVuY3Rpb24gMA0KbXB0MDogY29t cGxldGluZyB0aW1lZG91dC9hYm9ydGVkIHJlcSAweGM0YmZhZDUwOjIzODYNCmdfdmZzX2RvbmUo KTpkYTBzMWRbV1JJVEUob2Zmc2V0PTY0MTMzMjQyODgwMCwgbGVuZ3RoPTE2Mzg0KV1lcnJvciA9 IDUNCm1wdDA6IGFib3J0IG9mIHJlcSAweGM0YmZhZDUwOjAgY29tcGxldGVkDQptcHQwOiByZXF1 ZXN0IDB4YzRiZmFkODA6MjM4OCB0aW1lZCBvdXQgZm9yIGNjYiAweGM0YmYyMDAwIChyZXEtPmNj Yg0KMHhjNGJmMjAwMCkNCm1wdDA6IGF0dGVtcHRpbmcgdG8gYWJvcnQgcmVxIDB4YzRiZmFkODA6 MjM4OCBmdW5jdGlvbiAwDQptcHQwOiBjb21wbGV0aW5nIHRpbWVkb3V0L2Fib3J0ZWQgcmVxIDB4 YzRiZmFkODA6MjM4OA0KZ192ZnNfZG9uZSgpOmRhMHMxZFtXUklURShvZmZzZXQ9NjQxMzM2NDQy ODgwLCBsZW5ndGg9MzI3NjgpXWVycm9yID0gNQ0KbXB0MDogYWJvcnQgb2YgcmVxIDB4YzRiZmFk ODA6MCBjb21wbGV0ZWQNCm1wdDA6IHJlcXVlc3QgMHhjNGJmYWUxMDoyMzkyIHRpbWVkIG91dCBm b3IgY2NiIDB4YzZkMTkwMDAgKHJlcS0+Y2NiDQoweGM2ZDE5MDAwKQ0KbXB0MDogYXR0ZW1wdGlu ZyB0byBhYm9ydCByZXEgMHhjNGJmYWUxMDoyMzkyIGZ1bmN0aW9uIDANCm1wdDA6IGNvbXBsZXRp bmcgdGltZWRvdXQvYWJvcnRlZCByZXEgMHhjNGJmYWUxMDoyMzkyDQpnX3Zmc19kb25lKCk6ZGEw czFkW1dSSVRFKG9mZnNldD02NDEyNzk4MTk3NzYsIGxlbmd0aD0xNjM4NCldZXJyb3IgPSA1DQpt cHQwOiBhYm9ydCBvZiByZXEgMHhjNGJmYWUxMDowIGNvbXBsZXRlZA0KbXB0MDogcmVxdWVzdCAw eGM0YmZhZTQwOjIzOTQgdGltZWQgb3V0IGZvciBjY2IgMHhjNmQwZTgwMCAocmVxLT5jY2INCjB4 YzZkMGU4MDApDQptcHQwOiBhdHRlbXB0aW5nIHRvIGFib3J0IHJlcSAweGM0YmZhZTQwOjIzOTQg ZnVuY3Rpb24gMA0KbXB0MDogY29tcGxldGluZyB0aW1lZG91dC9hYm9ydGVkIHJlcSAweGM0YmZh ZTQwOjIzOTQNCmdfdmZzX2RvbmUoKTpkYTBzMWRbV1JJVEUob2Zmc2V0PTY0MTMzMjQ3Nzk1Miwg bGVuZ3RoPTE2Mzg0KV1lcnJvciA9IDUNCm1wdDA6IGFib3J0IG9mIHJlcSAweGM0YmZhZTQwOjAg Y29tcGxldGVkDQptcHQwOiByZXF1ZXN0IDB4YzRiZmFlZDA6MjM5OSB0aW1lZCBvdXQgZm9yIGNj YiAweGM2ZDE3YzAwIChyZXEtPmNjYg0KMHhjNmQxN2MwMCkNCm1wdDA6IGF0dGVtcHRpbmcgdG8g YWJvcnQgcmVxIDB4YzRiZmFlZDA6MjM5OSBmdW5jdGlvbiAwDQptcHQwOiBjb21wbGV0aW5nIHRp bWVkb3V0L2Fib3J0ZWQgcmVxIDB4YzRiZmFlZDA6MjM5OQ0KbXB0MDogYWJvcnQgb2YgcmVxIDB4 YzRiZmFlZDA6MCBjb21wbGV0ZWQNCm1wdDA6IHJlcXVlc3QgMHhjNGJmYWY2MDoyNDA1IHRpbWVk IG91dCBmb3IgY2NiIDB4YzZkMGU4MDAgKHJlcS0+Y2NiDQoweGM2ZDBlODAwKQ0KbXB0MDogcmVx dWVzdCAweGM0YmZhZjkwOjI0MDYgdGltZWQgb3V0IGZvciBjY2IgMHhjNmQyMDAwMCAocmVxLT5j Y2INCjB4YzZkMjAwMDApDQptcHQwOiByZXF1ZXN0IDB4YzRiZmFmYzA6MjQwNyB0aW1lZCBvdXQg Zm9yIGNjYiAweGM0Yzc0MDAwIChyZXEtPmNjYg0KMHhjNGM3NDAwMCkNCm1wdDA6IHJlcXVlc3Qg MHhjNGJmYWZmMDoyNDA4IHRpbWVkIG91dCBmb3IgY2NiIDB4YzRiZjIwMDAgKHJlcS0+Y2NiDQow eGM0YmYyMDAwKQ0KbXB0MDogYXR0ZW1wdGluZyB0byBhYm9ydCByZXEgMHhjNGJmYWY2MDoyNDA1 IGZ1bmN0aW9uIDANCm1wdDA6IGNvbXBsZXRpbmcgdGltZWRvdXQvYWJvcnRlZCByZXEgMHhjNGJm YWY2MDoyNDA1DQptcHQwOiBhYm9ydCBvZiByZXEgMHhjNGJmYWY2MDowIGNvbXBsZXRlZA0KbXB0 MDogYXR0ZW1wdGluZyB0byBhYm9ydCByZXEgMHhjNGJmYWY5MDoyNDA2IGZ1bmN0aW9uIDANCm1w dDA6IGNvbXBsZXRpbmcgdGltZWRvdXQvYWJvcnRlZCByZXEgMHhjNGJmYWY5MDoyNDA2DQptcHQw OiBhYm9ydCBvZiByZXEgMHhjNGJmYWY5MDowIGNvbXBsZXRlZA0KbXB0MDogYXR0ZW1wdGluZyB0 byBhYm9ydCByZXEgMHhjNGJmYWZjMDoyNDA3IGZ1bmN0aW9uIDANCm1wdDA6IGNvbXBsZXRpbmcg dGltZWRvdXQvYWJvcnRlZCByZXEgMHhjNGJmYWZjMDoyNDA3DQptcHQwOiBhYm9ydCBvZiByZXEg MHhjNGJmYWZjMDowIGNvbXBsZXRlZA0KbXB0MDogYXR0ZW1wdGluZyB0byBhYm9ydCByZXEgMHhj NGJmYWZmMDoyNDA4IGZ1bmN0aW9uIDANCm1wdDA6IGNvbXBsZXRpbmcgdGltZWRvdXQvYWJvcnRl ZCByZXEgMHhjNGJmYWZmMDoyNDA4DQptcHQwOiBhYm9ydCBvZiByZXEgMHhjNGJmYWZmMDowIGNv bXBsZXRlZA0KbXB0MDogcmVxdWVzdCAweGM0YmZiMDIwOjI0MDkgdGltZWQgb3V0IGZvciBjY2Ig MHhjNmQxZTQwMCAocmVxLT5jY2INCjB4YzZkMWU0MDApDQptcHQwOiBhdHRlbXB0aW5nIHRvIGFi b3J0IHJlcSAweGM0YmZiMDIwOjI0MDkgZnVuY3Rpb24gMA0KbXB0MDogY29tcGxldGluZyB0aW1l ZG91dC9hYm9ydGVkIHJlcSAweGM0YmZiMDIwOjI0MDkNCm1wdDA6IGFib3J0IG9mIHJlcSAweGM0 YmZiMDIwOjAgY29tcGxldGVkDQptcHQwOiByZXF1ZXN0IDB4YzRiZmIwYjA6MjQxMiB0aW1lZCBv dXQgZm9yIGNjYiAweGM2ZDE4MDAwIChyZXEtPmNjYg0KMHhjNmQxODAwMCkNCm1wdDA6IGF0dGVt cHRpbmcgdG8gYWJvcnQgcmVxIDB4YzRiZmIwYjA6MjQxMiBmdW5jdGlvbiAwDQptcHQwOiBjb21w bGV0aW5nIHRpbWVkb3V0L2Fib3J0ZWQgcmVxIDB4YzRiZmIwYjA6MjQxMg0KbXB0MDogYWJvcnQg b2YgcmVxIDB4YzRiZmIwYjA6MCBjb21wbGV0ZWQNCm1wdDA6IHJlcXVlc3QgMHhjNGJmYjFkMDoy NDE5IHRpbWVkIG91dCBmb3IgY2NiIDB4YzZkMTdjMDAgKHJlcS0+Y2NiDQoweGM2ZDE3YzAwKQ0K bXB0MDogYXR0ZW1wdGluZyB0byBhYm9ydCByZXEgMHhjNGJmYjFkMDoyNDE5IGZ1bmN0aW9uIDAN Cm1wdDA6IGNvbXBsZXRpbmcgdGltZWRvdXQvYWJvcnRlZCByZXEgMHhjNGJmYjFkMDoyNDE5DQpt cHQwOiBhYm9ydCBvZiByZXEgMHhjNGJmYjFkMDowIGNvbXBsZXRlZA0KDQoNCg0KLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCk1lc3NhZ2U6IDUNCkRhdGU6IE1vbiwgMSBKYW4gMjAw NyAxMTozMToyMSArMDAwMA0KRnJvbTogQ2hyaXMgPGNocmNvbHVrQGdtYWlsLmNvbT4NClN1Ympl Y3Q6IFJlOiA2LjItUFJFOiBGYXRhbCBUcmFwPw0KVG86ICJJdmFuIFZvcmFzIiA8aXZvcmFzQGZl ci5ocj4NCkNjOiBmcmVlYnNkLXN0YWJsZUBmcmVlYnNkLm9yZw0KTWVzc2FnZS1JRDoNCgk8M2Fh YWEzYTA3MDEwMTAzMzF1NzJkNzBlOTBwNzE0YTAxNzFmZTlmMjkyYUBtYWlsLmdtYWlsLmNvbT4N CkNvbnRlbnQtVHlwZTogdGV4dC9wbGFpbjsgY2hhcnNldD1JU08tODg1OS0xOyBmb3JtYXQ9Zmxv d2VkDQoNCk9uIDMwLzEyLzA2LCBJdmFuIFZvcmFzIDxpdm9yYXNAZmVyLmhyPiB3cm90ZToNCj4g S2Fyb2wgS3dpYXRrb3dza2kgd3JvdGU6DQo+DQo+ID4gVGhpcyB3b3JrczogRnJlZUJTRCA2LjIt UFJFUkVMRUFTRSAjMDogVGh1IERlYyAxNCAxMTozNDozNiBDRVQgMjAwNg0KPiA+IFRoaXMgZG9l c24ndDogRnJlZUJTRCA2LjItUFJFUkVMRUFTRSAjMDogU2F0IERlYyAzMCAxMToyNzoxMSBDRVQg MjAwNg0KPg0KPiA+IEknbSBub3Qgc3VyZSBpdCB0aGF0J3MgYWxsIHRoYXQgbWF0dGVycywgSSBj YW4gc3VwcGx5IG1vcmUgaW5mb3JtYXRpb24NCj4gPiBpZiBuZWVkZWQuDQo+DQo+IFllcywgeW91 J2xsIG5lZWQgdG8gc2VuZCBhdCBsZWFzdCBhIGtlcm5lbCBzdGFjayBiYWNrdHJhY2UuIFNlZSBo ZXJlOg0KPiBodHRwOi8vd3d3LmZyZWVic2Qub3JnL2RvYy9lbl9VUy5JU084ODU5LTEvYm9va3Mv ZGV2ZWxvcGVycy1oYW5kYm9vay9rZXJuZWxkZWJ1Zy1vbmxpbmUtZGRiLmh0bWwNCj4NCj4gR2V0 IGl0IHRvIHN0YXJ0IHRoZSBkZWJ1Z2dlciBvbiBwYW5pYyBhbmQgcG9zdCB0aGUgYmFja3RyYWNl IChidCkuDQo+DQo+DQo+DQo+DQoNCklzIGl0IHBvc3NpYmxlIHRvIG1ha2UgaXQgYXV0byBydW4g ZGVidWdnZXIsIHRoZW4gYXV0byBydW4gYmFja3RyYWNlDQp0aGVuIGR1bXAgdGhlIG91dHB1dCB0 byBkaXNrIHNvIHBlb3BsZSB3aG8gaGF2ZSBubyBsb2NhbCBhY2Nlc3MgY2FuDQpnZXQgYmFja3Ry YWNlcz8NCg0KQ2hyaXMNCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCmZyZWVic2Qtc3Rh YmxlQGZyZWVic2Qub3JnIG1haWxpbmcgbGlzdA0KaHR0cDovL2xpc3RzLmZyZWVic2Qub3JnL21h aWxtYW4vbGlzdGluZm8vZnJlZWJzZC1zdGFibGUNClRvIHVuc3Vic2NyaWJlLCBzZW5kIGFueSBt YWlsIHRvICJmcmVlYnNkLXN0YWJsZS11bnN1YnNjcmliZUBmcmVlYnNkLm9yZyINCg0KRW5kIG9m IGZyZWVic2Qtc3RhYmxlIERpZ2VzdCwgVm9sIDE4OCwgSXNzdWUgMTANCioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqDQo= From owner-freebsd-stable@FreeBSD.ORG Tue Jan 2 03:04:18 2007 Return-Path: X-Original-To: stable@freebsd.org 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 8D00316A40F for ; Tue, 2 Jan 2007 03:04:18 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out4.smtp.messagingengine.com (out4.smtp.messagingengine.com [66.111.4.28]) by mx1.freebsd.org (Postfix) with ESMTP id 6306A13C44B for ; Tue, 2 Jan 2007 03:04:18 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out1.internal (unknown [10.202.2.149]) by out1.messagingengine.com (Postfix) with ESMTP id C8BC75A074; Mon, 1 Jan 2007 22:02:10 -0500 (EST) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by out1.internal (MEProxy); Mon, 01 Jan 2007 22:02:10 -0500 X-Sasl-enc: JYZeAMqJQIHRy2JCHcJJ7ctxPVJlJVKzyH8trtnRq0vU 1167706930 Received: from [192.168.123.18] (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTP id 2A2E83403; Mon, 1 Jan 2007 22:02:08 -0500 (EST) Message-ID: <4599CBAE.4000300@FreeBSD.org> Date: Tue, 02 Jan 2007 03:04:14 +0000 From: "Bruce M. Simpson" User-Agent: Thunderbird 1.5.0.5 (X11/20060825) MIME-Version: 1.0 To: Luigi Rizzo References: <20070101145309.A35044@xorpc.icir.org> In-Reply-To: <20070101145309.A35044@xorpc.icir.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: stable@freebsd.org Subject: Re: drm and i915 issue on Dell Latitude X1 ? 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, 02 Jan 2007 03:04:18 -0000 JFYI Luigi Rizzo wrote: > a curious thing... on my Dell Latitude X1 (scanpci -v output > at the end) the drm module did not recognise the video card > until i added this patch: > This is odd. I have the same vendor/device IDs on the ThinkPad T43 and yet X.org's DRM loads fine here without this patch: pci bus 0x0000 cardnum 0x02 function 0x00: vendor 0x8086 device 0x2592 Intel Corporation Mobile 915GM/GMS/910GML Express Graphics Controller pci bus 0x0000 cardnum 0x02 function 0x01: vendor 0x8086 device 0x2792 Intel Corporation Mobile 915GM/GMS/910GML Express Graphics Controller With the following difference: CardVendor 0x1014 card 0x0582 (IBM, Card unknown) FreeBSD empiric.lon.incunabulum.net 6.2-RC1 FreeBSD 6.2-RC1 #2: Sun Dec 24 11:20:48 GMT 2006 bms@empiric.lon.incunabulum.net:/usr/src/sys/i386/compile/EMPIRIC i386 empiric:/var/log % dmesg | grep drm drmsub0: : (child of agp_i810.c) on agp0 info: [drm] AGP at 0x90080000 0MB info: [drm] Initialized i915 1.4.0 20060119 DRM, GLX modules show up in xdpyinfo. By the way, there doesn't appear to be an 'ident' field for drm_pciids.h in the binaries, though I'm on 1.2.2.3. glxgears runs as expected (~260fps in default scale at 1024x768x32bpp). I tested with an application by running games/gltron, which claims 25-40fps in 512x384 full-screen. It still seemed jerky. [Except after an ACPI suspend/resume via zzz, in which case, it cains the CPU on resume and only achieves 60fps-150fps, and acpi_video cannot attach, and gltron is jerky/doesn't work properly.] Regards, BMS From owner-freebsd-stable@FreeBSD.ORG Tue Jan 2 05:04:15 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org 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 4870616A412 for ; Tue, 2 Jan 2007 05:04:15 +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 EAACB13C4B5 for ; Tue, 2 Jan 2007 05:04:14 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from inchoate.gsoft.com.au (inchoate.gsoft.com.au [203.31.81.37]) (authenticated bits=0) by cain.gsoft.com.au (8.13.5/8.13.4) with ESMTP id l024mxWF056036 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 2 Jan 2007 15:19:00 +1030 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: freebsd-stable@freebsd.org Date: Tue, 2 Jan 2007 15:18:51 +1030 User-Agent: KMail/1.9.4 MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <200701021518.52231.doconnor@gsoft.com.au> X-Spam-Score: -1.36 () ALL_TRUSTED X-Scanned-By: MIMEDefang 2.57 on 203.31.81.10 Subject: twe on amd64 hangs 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, 02 Jan 2007 05:04:15 -0000 Hi, We have recently bought some new Supermicro P8SCT boards with 3ware 8006LP2's and are using the amd64 port, however if I put the 3ware in the PCI-X slot it hangs probing the disks (eg at the end of the boot if it's in the kernel, or at load time if I use kldload). If I put it in a 32 bit slot it works fine. I tried reducing the PCI-X clock down to 100MHz but it made no difference. If I boot an i386 kernel it works fine (I tried 6.2RC2). Unfortunately the hang is solid and I can't break into the debugger :( Any help appreciated, I am happy to test patches, etc.. Thanks. -- 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 Tue Jan 2 05:27:26 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org 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 7886516A501 for ; Tue, 2 Jan 2007 05:27:26 +0000 (UTC) (envelope-from cperciva@freebsd.org) Received: from pd3mo2so.prod.shaw.ca (shawidc-mo1.cg.shawcable.net [24.71.223.10]) by mx1.freebsd.org (Postfix) with ESMTP id 4E98713C43E for ; Tue, 2 Jan 2007 05:27:26 +0000 (UTC) (envelope-from cperciva@freebsd.org) Received: from pd4mr7so.prod.shaw.ca (pd4mr7so-qfe3.prod.shaw.ca [10.0.141.84]) by l-daemon (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with ESMTP id <0JB800CUC4CQD330@l-daemon> for freebsd-stable@freebsd.org; Mon, 01 Jan 2007 21:26:50 -0700 (MST) Received: from pn2ml5so.prod.shaw.ca ([10.0.121.149]) by pd4mr7so.prod.shaw.ca (Sun Java System Messaging Server 6.2-2.05 (built Apr 28 2005)) with ESMTP id <0JB800H1K4CPOBT0@pd4mr7so.prod.shaw.ca> for freebsd-stable@freebsd.org; Mon, 01 Jan 2007 21:26:50 -0700 (MST) Received: from hexahedron.daemonology.net ([24.82.18.31]) by l-daemon (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with SMTP id <0JB8009BR4CODXV0@l-daemon> for freebsd-stable@freebsd.org; Mon, 01 Jan 2007 21:26:49 -0700 (MST) Received: (qmail 49188 invoked from network); Tue, 02 Jan 2007 04:26:42 +0000 Received: from unknown (HELO ?127.0.0.1?) (127.0.0.1) by localhost with SMTP; Tue, 02 Jan 2007 04:26:42 +0000 Date: Mon, 01 Jan 2007 20:26:42 -0800 From: FreeBSD Security Officer To: FreeBSD Security Message-id: <4599DF02.5030002@freebsd.org> Organization: FreeBSD Project MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7bit X-Enigmail-Version: 0.94.0.0 User-Agent: Thunderbird 1.5.0.9 (X11/20061227) Cc: FreeBSD Stable Subject: HEADS UP: FreeBSD 4.11, 6.0 EoLs coming soon X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: security-officer@freebsd.org List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jan 2007 05:27:26 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello Everyone, On January 31st, FreeBSD 4.11 and FreeBSD 6.0 will have reached their End of Life dates and will no longer be supported by the FreeBSD Security Team. Users of either of these FreeBSD releases are strongly encouraged to upgrade to FreeBSD 5.5, FreeBSD 6.1, or the upcoming FreeBSD 6.2 before that date. Discussion concerning FreeBSD releases which are no longer supported should take place on the freebsd-eol@freebsd.org mailing list. For an explanation of the rationale behind the EoL of FreeBSD 4.11, please see my earlier mailing list post on this subject: http://lists.freebsd.org/pipermail/freebsd-security/2006-October/004111.html The current supported branches and expected EoL dates are: +--------------------------------------------------------------------+ | Branch | Release | Type | Release date | Estimated EoL | |-----------+------------+--------+----------------+-----------------| |RELENG_4 |n/a |n/a |n/a |January 31, 2007 | |-----------+------------+--------+----------------+-----------------| |RELENG_4_11|4.11-RELEASE|Extended|January 25, 2005|January 31, 2007 | |-----------+------------+--------+----------------+-----------------| |RELENG_5 |n/a |n/a |n/a |May 31, 2008 | |-----------+------------+--------+----------------+-----------------| |RELENG_5_5 |5.5-RELEASE |Extended|May 25, 2006 |May 31, 2008 | |-----------+------------+--------+----------------+-----------------| |RELENG_6 |n/a |n/a |n/a |last release + 2y| |-----------+------------+--------+----------------+-----------------| |RELENG_6_0 |6.0-RELEASE |Normal |November 4, 2005|January 31, 2007 | |-----------+------------+--------+----------------+-----------------| |RELENG_6_1 |6.1-RELEASE |Extended|May 9, 2006 |May 31, 2008 | +--------------------------------------------------------------------+ Once it is released, FreeBSD 6.2 will be supported until January 31, 2008. Colin Percival FreeBSD Security Officer -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFFmd8BFdaIBMps37IRAk3DAKCKK69yVuOce4g2O97XH5OjPWrAvgCeO2sb 1cXUw0P3RUN11PLHmj6kN+Y= =tb5N -----END PGP SIGNATURE----- From owner-freebsd-stable@FreeBSD.ORG Tue Jan 2 13:06:26 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org 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 F28AE16A403 for ; Tue, 2 Jan 2007 13:06:26 +0000 (UTC) (envelope-from kiorky@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.169]) by mx1.freebsd.org (Postfix) with ESMTP id 9095D13C428 for ; Tue, 2 Jan 2007 13:06:26 +0000 (UTC) (envelope-from kiorky@gmail.com) Received: by ug-out-1314.google.com with SMTP id o2so4330472uge for ; Tue, 02 Jan 2007 05:06:25 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type; b=QQcHHolwqJKlrkc38JNh1c9XoVF1WQjUMmvlcRcM6mZr08Bl5aFvFTv4IcBrf1P/vTAgwd1BqOO8M6wSiA7Ppq3Vki3nLxgBWjxGB3Em+eseyfrqtMhgOZUFc3QZVmfqHTxUW8ndg2g0vMMbPGiuVRzNG8eeNoI0TDI7fr+xme8= Received: by 10.78.97.7 with SMTP id u7mr21453hub.1167741490628; Tue, 02 Jan 2007 04:38:10 -0800 (PST) Received: by 10.78.41.1 with HTTP; Tue, 2 Jan 2007 04:38:10 -0800 (PST) Message-ID: <9908ec200701020438y11348fe8k6ef1080802e0024e@mail.gmail.com> Date: Tue, 2 Jan 2007 13:38:10 +0100 From: KiORKY To: freebsd-stable@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: keyboard shorcut 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, 02 Jan 2007 13:06:27 -0000 Hello folks, i don't remember the keyboard shorcut to kill a process at boot and i'm wondering if someone could tell me it. Thanks From owner-freebsd-stable@FreeBSD.ORG Tue Jan 2 13:10:49 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org 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 6665016A403 for ; Tue, 2 Jan 2007 13:10:49 +0000 (UTC) (envelope-from clay@milos.co.za) Received: from bart.milos.co.za (bart.milos.co.za [196.38.18.66]) by mx1.freebsd.org (Postfix) with ESMTP id 2A24013C442 for ; Tue, 2 Jan 2007 13:10:47 +0000 (UTC) (envelope-from clay@milos.co.za) Received: (qmail 23257 invoked by uid 89); 2 Jan 2007 13:10:45 -0000 Received: from unknown (HELO claylaptop) (clay@milos.za.net@192.168.3.254) by bart.milos.co.za with SMTP; 2 Jan 2007 13:10:45 -0000 Message-ID: <024f01c72e6f$6677c000$9603a8c0@claylaptop> From: "Clayton Milos" To: "KiORKY" , References: <9908ec200701020438y11348fe8k6ef1080802e0024e@mail.gmail.com> Date: Tue, 2 Jan 2007 15:10:39 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Cc: Subject: Re: keyboard shorcut 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, 02 Jan 2007 13:10:49 -0000 c ----- Original Message ----- From: "KiORKY" To: Sent: Tuesday, January 02, 2007 2:38 PM Subject: keyboard shorcut > Hello folks, i don't remember the keyboard shorcut to kill a process at > boot > and i'm wondering if someone could tell me it. > Thanks > _______________________________________________ > 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 Tue Jan 2 13:22:36 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org 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 359AF16A40F for ; Tue, 2 Jan 2007 13:22:36 +0000 (UTC) (envelope-from kiorky@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.169]) by mx1.freebsd.org (Postfix) with ESMTP id C408413C465 for ; Tue, 2 Jan 2007 13:22:35 +0000 (UTC) (envelope-from kiorky@gmail.com) Received: by ug-out-1314.google.com with SMTP id o2so4333334uge for ; Tue, 02 Jan 2007 05:22:34 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=fY+YWhTZO2GakkRXvkv+PQ2SSooRuhAYntWe2bwEKRSDB2bzvCBbDynpk6aYNI1bPZZQuejf3blgXpub+7Tx7oFoHaackE4G7dursX78HxV36MBsYjIDvj0d69ICeN3/uax19x5mB/eiNKEY+GTOiBKJ+n92CXovYSToBC5JnOA= Received: by 10.78.171.20 with SMTP id t20mr1912737hue.1167744154605; Tue, 02 Jan 2007 05:22:34 -0800 (PST) Received: by 10.78.41.1 with HTTP; Tue, 2 Jan 2007 05:22:34 -0800 (PST) Message-ID: <9908ec200701020522k411f83eas2ba8c9f76605433f@mail.gmail.com> Date: Tue, 2 Jan 2007 14:22:34 +0100 From: KiORKY To: "Clayton Milos" In-Reply-To: <024f01c72e6f$6677c000$9603a8c0@claylaptop> MIME-Version: 1.0 References: <9908ec200701020438y11348fe8k6ef1080802e0024e@mail.gmail.com> <024f01c72e6f$6677c000$9603a8c0@claylaptop> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable@freebsd.org Subject: Re: keyboard shorcut 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, 02 Jan 2007 13:22:36 -0000 that's the one i tried without sucess. 2007/1/2, Clayton Milos : > > c > > > ----- Original Message ----- > From: "KiORKY" > To: > Sent: Tuesday, January 02, 2007 2:38 PM > Subject: keyboard shorcut > > > > Hello folks, i don't remember the keyboard shorcut to kill a process at > > boot > > and i'm wondering if someone could tell me it. > > Thanks > > _______________________________________________ > > 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 Tue Jan 2 15:36:12 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org 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 A801716A412 for ; Tue, 2 Jan 2007 15:36:12 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from rwcrmhc11.comcast.net (rwcrmhc11.comcast.net [204.127.192.81]) by mx1.freebsd.org (Postfix) with ESMTP id 96F5413C459 for ; Tue, 2 Jan 2007 15:36:12 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from icarus.home.lan (c-67-174-220-97.hsd1.ca.comcast.net[67.174.220.97]) by comcast.net (rwcrmhc11) with ESMTP id <20070102153608m11003vtt7e>; Tue, 2 Jan 2007 15:36:12 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 444B81FA037; Tue, 2 Jan 2007 07:36:08 -0800 (PST) Date: Tue, 2 Jan 2007 07:36:08 -0800 From: Jeremy Chadwick To: freebsd-stable@FreeBSD.org Message-ID: <20070102153608.GA78405@icarus.home.lan> Mail-Followup-To: freebsd-stable@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-PGP-Key: http://jdc.parodius.com/pubkey.asc User-Agent: Mutt/1.5.13 (2006-08-11) Cc: Subject: Interrupt (SCSI?) hang on 4.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: Tue, 02 Jan 2007 15:36:12 -0000 Yes, I know 4.11 is EOL'd at the end of this month, but hopefully someone can shed some light on this problem anyways. I simply don't have the knowledge of what's going on on a low-level to determine the cause. I do have serial console on this box, and after enabling some debugging for the ahc(4) driver a few months back, was able to get something intelligent out of the system regarding SCBs this morning. This may not be useful (or the cause), though. I also cannot enable drop-to-DDB-on-serial-break because our Portmaster 2 has been known to send a serial break on rare occasion. :-( Every so often (sometimes hours, sometimes months -- usually months), the 4.11 box we have "locks up" in the sense that both NICs on the box stop working, and the SCSI controller also appears hung. This problem has existed for a couple years; it's not specific to 4.11 (versus 4.10 or 4.9). I have to hard reset or power cycle the box to get it working again. The problem will continue indefinitely until the machine is reset; meaning it does not recover on its own. Naturally this means quite an ugly fsck when the machine comes back up. The initial symptoms are: fxp0: device timeout fxp1: device timeout ahc0: Timedout SCBs already complete. Interrupts may not be functioning. Hardware: * 2x Pentium III 933MHz * Tyan Tiger 200 - VIA NB/SB chipset (probably the cause of all this :) ) - Mainboard running latest BIOS - 2x Intel 82559 on-board NIC * 512MB RAM (ECC; has built world for years no problem) * Adaptec 29160 U160 controller (physical card, not on-board); not sure what Adaptec BIOS revision (anyway to check via FreeBSD?) * Hard disk is a single 16GB U160/SCSI-3 drive * Kernel is SMP Devices and associated IRQs: fxp0: port 0xe000-0xe03f mem 0xd6000000-0xd60fffff,0xd6202000-0xd6202fff irq 10 at device 13.0 on pci0 fxp1: port 0xe400-0xe43f mem 0xd6100000-0xd61fffff,0xd6201000-0xd6201fff irq 11 at device 14.0 on pci0 ahc0: port 0xe800-0xe8ff mem 0xd6203000-0xd6203fff irq 11 at device 16.0 on pci0 da0: Fixed Direct Access SCSI-3 device # vmstat -i ata0 irq14 6 0 fxp0 irq10 14874 28 mux irq11 65028 125 fdc0 irq6 1 0 sio0 irq4 948 1 clk irq0 516187 998 rtc irq8 66071 127 Total 663115 1282 # pciconf -l agp0@pci0:0:0: class=0x060000 card=0x00000000 chip=0x06911106 rev=0xc4 hdr=0x00 pcib2@pci0:1:0: class=0x060400 card=0x00000080 chip=0x85981106 rev=0x00 hdr=0x01 none0@pci0:6:0: class=0x030000 card=0x00081002 chip=0x47521002 rev=0x27 hdr=0x00 isab0@pci0:7:0: class=0x060100 card=0x00001106 chip=0x06861106 rev=0x40 hdr=0x00 atapci0@pci0:7:1: class=0x01018a card=0x05711106 chip=0x05711106 rev=0x06 hdr=0x00 viapropm0@pci0:7:4: class=0x060000 card=0x00000000 chip=0x30571106 rev=0x40 hdr=0x00 fxp0@pci0:13:0: class=0x020000 card=0x000c8086 chip=0x12298086 rev=0x08 hdr=0x00 fxp1@pci0:14:0: class=0x020000 card=0x000c8086 chip=0x12298086 rev=0x08 hdr=0x00 ahc0@pci0:16:0: class=0x010000 card=0xe2209005 chip=0x00809005 rev=0x02 hdr=0x00 I can include my kernel configuration if need be, but it's fairly standard. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | === SNIP === FreeBSD/i386 (pentarou.parodius.com) (ttyd0) login: fxp0: device timeout ahc0: Recovery Initiated >>>>>>>>>>>>>>>>>> Dump Card State Begins <<<<<<<<<<<<<<<<< ahc0: Dumping Card State in Message-out phase, at SEQADDR 0x16c Card was paused ACCUM = 0xa0, SINDEX = 0x61, DINDEX = 0xe4, ARG_2 = 0x10 HCNT = 0x0 SCBPTR = 0x1f SCSIPHASE[0x4] SCSISIGI[0xb6] ERROR[0x0] SCSIBUSL[0x41] LASTPHASE[0xa0] SCSISEQ[0x12] SBLKCTL[0xa] SCSIRATE[0x0] SEQCTL[0x10] SEQ_FLAGS[0x40] SSTAT0[0x2] SSTAT1[0x1] SSTAT2[0x0] SSTAT3[0x0] SIMODE0[0x8] SIMODE1[0xac] SXFRCTL0[0x88] DFCNTRL[0x0] DFSTATUS[0x89] STACK: 0xe2 0xe2 0xe2 0x179 SCB count = 130 Kernel NEXTQSCB = 98 Card NEXTQSCB = 124 QINFIFO entries: 124 76 86 37 106 30 87 80 59 104 127 110 22 Waiting Queue entries: Disconnected Queue entries: QOUTFIFO entries: Sequencer Free SCB List: 24 10 4 12 17 22 15 5 7 28 8 18 30 6 23 26 14 21 1 19 27 29 11 25 3 2 9 13 20 16 0 Sequencer SCB Info: 0 SCB_CONTROL[0xe0] SCB_SCSIID[0x7] SCB_LUN[0x0] SCB_TAG[0xff] 1 SCB_CONTROL[0xe0] SCB_SCSIID[0x7] SCB_LUN[0x0] SCB_TAG[0xff] 2 SCB_CONTROL[0xe0] SCB_SCSIID[0x7] SCB_LUN[0x0] SCB_TAG[0xff] 3 SCB_CONTROL[0xe0] SCB_SCSIID[0x7] SCB_LUN[0x0] SCB_TAG[0xff] 4 SCB_CONTROL[0x0] SCB_SCSIID[0x7] SCB_LUN[0x0] SCB_TAG[0xff] 5 SCB_CONTROL[0x0] SCB_SCSIID[0x7] SCB_LUN[0x0] SCB_TAG[0xff] 6 SCB_CONTROL[0xe0] SCB_SCSIID[0x7] SCB_LUN[0x0] SCB_TAG[0xff] 7 SCB_CONTROL[0x0] SCB_SCSIID[0x7] SCB_LUN[0x0] SCB_TAG[0xff] 8 SCB_CONTROL[0xe0] SCB_SCSIID[0x7] SCB_LUN[0x0] SCB_TAG[0xff] 9 SCB_CONTROL[0xe0] SCB_SCSIID[0x7] SCB_LUN[0x0] SCB_TAG[0xff] 10 SCB_CONTROL[0x0] SCB_SCSIID[0x7] SCB_LUN[0x0] SCB_TAG[0xff] 11 SCB_CONTROL[0xe0] SCB_SCSIID[0x7] SCB_LUN[0x0] SCB_TAG[0xff] 12 SCB_CONTROL[0x0] SCB_SCSIID[0x7] SCB_LUN[0x0] SCB_TAG[0xff] 13 SCB_CONTROL[0xe0] SCB_SCSIID[0x7] SCB_LUN[0x0] SCB_TAG[0xff] 14 SCB_CONTROL[0xe0] SCB_SCSIID[0x7] SCB_LUN[0x0] SCB_TAG[0xff] 15 SCB_CONTROL[0x0] SCB_SCSIID[0x7] SCB_LUN[0x0] SCB_TAG[0xff] 16 SCB_CONTROL[0xe0] SCB_SCSIID[0x7] SCB_LUN[0x0] SCB_TAG[0xff] 17 SCB_CONTROL[0x0] SCB_SCSIID[0x7] SCB_LUN[0x0] SCB_TAG[0xff] 18 SCB_CONTROL[0xe0] SCB_SCSIID[0x7] SCB_LUN[0x0] SCB_TAG[0xff] 19 SCB_CONTROL[0xe0] SCB_SCSIID[0x7] SCB_LUN[0x0] SCB_TAG[0xff] 20 SCB_CONTROL[0xe0] SCB_SCSIID[0x7] SCB_LUN[0x0] SCB_TAG[0xff] 21 SCB_CONTROL[0xe0] SCB_SCSIID[0x7] SCB_LUN[0x0] SCB_TAG[0xff] 22 SCB_CONTROL[0x0] SCB_SCSIID[0x7] SCB_LUN[0x0] SCB_TAG[0xff] 23 SCB_CONTROL[0xe0] SCB_SCSIID[0x7] SCB_LUN[0x0] SCB_TAG[0xff] 24 SCB_CONTROL[0x0] SCB_SCSIID[0x7] SCB_LUN[0x0] SCB_TAG[0xff] 25 SCB_CONTROL[0xe0] SCB_SCSIID[0x7] SCB_LUN[0x0] SCB_TAG[0xff] 26 SCB_CONTROL[0xe0] SCB_SCSIID[0x7] SCB_LUN[0x0] SCB_TAG[0xff] 27 SCB_CONTROL[0xe0] SCB_SCSIID[0x7] SCB_LUN[0x0] SCB_TAG[0xff] 28 SCB_CONTROL[0xe0] SCB_SCSIID[0x7] SCB_LUN[0x0] SCB_TAG[0xff] 29 SCB_CONTROL[0xe0] SCB_SCSIID[0x7] SCB_LUN[0x0] SCB_TAG[0xff] 30 SCB_CONTROL[0xe0] SCB_SCSIID[0x7] SCB_LUN[0x0] SCB_TAG[0xff] 31 SCB_CONTROL[0x60] SCB_SCSIID[0x7] SCB_LUN[0x0] SCB_TAG[0x41] Pending list: 22 SCB_CONTROL[0x72] SCB_SCSIID[0x7] SCB_LUN[0x0] 110 SCB_CONTROL[0x70] SCB_SCSIID[0x7] SCB_LUN[0x0] 127 SCB_CONTROL[0x72] SCB_SCSIID[0x7] SCB_LUN[0x0] 104 SCB_CONTROL[0x72] SCB_SCSIID[0x7] SCB_LUN[0x0] 59 SCB_CONTROL[0x70] SCB_SCSIID[0x7] SCB_LUN[0x0] 80 SCB_CONTROL[0x70] SCB_SCSIID[0x7] SCB_LUN[0x0] 87 SCB_CONTROL[0x70] SCB_SCSIID[0x7] SCB_LUN[0x0] 30 SCB_CONTROL[0x70] SCB_SCSIID[0x7] SCB_LUN[0x0] 106 SCB_CONTROL[0x70] SCB_SCSIID[0x7] SCB_LUN[0x0] 37 SCB_CONTROL[0x70] SCB_SCSIID[0x7] SCB_LUN[0x0] 86 SCB_CONTROL[0x70] SCB_SCSIID[0x7] SCB_LUN[0x0] 76 SCB_CONTROL[0x70] SCB_SCSIID[0x7] SCB_LUN[0x0] 124 SCB_CONTROL[0x70] SCB_SCSIID[0x7] SCB_LUN[0x0] 65 SCB_CONTROL[0x60] SCB_SCSIID[0x7] SCB_LUN[0x0] Kernel Free SCB list: 5 118 81 94 27 97 14 56 1 115 93 128 33 41 31 36 12 54 64 79 4 55 63 107 70 119 15 39 77 69 66 17 67 95 58 16 75 100 53 29 47 125 60 111 71 10 129 114 82 25 35 99 117 83 44 38 123 92 74 126 90 85 50 46 32 68 45 21 48 102 96 57 42 89 43 78 109 62 23 72 0 116 120 2 11 105 20 103 52 101 26 24 121 51 122 40 112 18 34 84 73 13 7 91 28 108 19 9 8 88 3 61 49 6 113 <<<<<<<<<<<<<<<<< Dump Card State Ends >>>>>>>>>>>>>>>>>> (da0:ahc0:0:0:0): SCB 0x16 - timed out sg[0] - Addr 0x6b39000 : Length 4096 sg[1] - Addr 0x6bba000 : Length 4096 (da0:ahc0:0:0:0): Other SCB Timeout (da0:ahc0:0:0:0): SCB 0x6e - timed out sg[0] - Addr 0x9f79000 : Length 4096 sg[1] - Addr 0x1b63a000 : Length 2560 (da0:ahc0:0:0:0): Other SCB Timeout (da0:ahc0:0:0:0): SCB 0x7f - timed out sg[0] - Addr 0x64e7000 : Length 4096 sg[1] - Addr 0x64c8000 : Length 4096 (da0:ahc0:0:0:0): Other SCB Timeout (da0:ahc0:0:0:0): SCB 0x68 - timed out sg[0] - Addr 0x88e6000 : Length 4096 (da0:ahc0:0:0:0): Other SCB Timeout (da0:ahc0:0:0:0): SCB 0x3b - timed out sg[0] - Addr 0x5e05000 : Length 4096 sg[1] - Addr 0x2fa6000 : Length 2048 (da0:ahc0:0:0:0): Other SCB Timeout (da0:ahc0:0:0:0): SCB 0x50 - timed out sg[0] - Addr 0xef5b000 : Length 4096 sg[1] - Addr 0xf05c000 : Length 4096 (da0:ahc0:0:0:0): Other SCB Timeout (da0:ahc0:0:0:0): SCB 0x57 - timed out sg[0] - Addr 0x14c7000 : Length 4096 sg[1] - Addr 0x111a8000 : Length 4096 (da0:ahc0:0:0:0): Other SCB Timeout (da0:ahc0:0:0:0): SCB 0x1e - timed out sg[0] - Addr 0x19de9000 : Length 4096 sg[1] - Addr 0x1cdaa000 : Length 4096 (da0:ahc0:0:0:0): Other SCB Timeout (da0:ahc0:0:0:0): SCB 0x6a - timed out sg[0] - Addr 0x725d000 : Length 4096 sg[1] - Addr 0x709e000 : Length 4096 (da0:ahc0:0:0:0): Other SCB Timeout (da0:ahc0:0:0:0): SCB 0x25 - timed out sg[0] - Addr 0x1db1b000 : Length 4096 sg[1] - Addr 0xf95c000 : Length 4096 (da0:ahc0:0:0:0): Other SCB Timeout (da0:ahc0:0:0:0): SCB 0x56 - timed out sg[0] - Addr 0x91b1000 : Length 4096 sg[1] - Addr 0x94f2000 : Length 4096 (da0:ahc0:0:0:0): Other SCB Timeout (da0:ahc0:0:0:0): SCB 0x4c - timed out sg[0] - Addr 0x7087000 : Length 4096 sg[1] - Addr 0x6f48000 : Length 4096 (da0:ahc0:0:0:0): Other SCB Timeout (da0:ahc0:0:0:0): SCB 0x7c - timed out sg[0] - Addr 0x63b1000 : Length 4096 sg[1] - Addr 0x66b2000 : Length 4096 (da0:ahc0:0:0:0): Other SCB Timeout (da0:ahc0:0:0:0): SCB 0x41 - timed out sg[0] - Addr 0x62cd000 : Length 4096 sg[1] - Addr 0x656e000 : Length 4096 (da0:ahc0:0:0:0): BDR message in message buffer ahc0: Timedout SCBs already complete. Interrupts may not be functioning. ahc0: Recovery Initiated >>>>>>>>>>>>>>>>>> Dump Card State Begins <<<<<<<<<<<<<<<<< ahc0: Dumping Card State in Message-out phase, at SEQADDR 0x16c Card was paused ACCUM = 0xa0, SINDEX = 0x61, DINDEX = 0xe4, ARG_2 = 0x10 HCNT = 0x0 SCBPTR = 0x1f SCSIPHASE[0x4] SCSISIGI[0xb6] ERROR[0x0] SCSIBUSL[0x6] LASTPHASE[0xa0] SCSISEQ[0x12] SBLKCTL[0xa] SCSIRATE[0x0] SEQCTL[0x10] SEQ_FLAGS[0x40] SSTAT0[0x2] SSTAT1[0x1] SSTAT2[0x0] SSTAT3[0x0] SIMODE0[0x8] SIMODE1[0xac] SXFRCTL0[0x88] DFCNTRL[0x0] DFSTATUS[0x89] STACK: 0xe2 0xe2 0xe2 0x179 SCB count = 130 Kernel NEXTQSCB = 98 Card NEXTQSCB = 124 QINFIFO entries: 124 76 86 37 106 30 87 80 59 104 127 110 22 Waiting Queue entries: Disconnected Queue entries: QOUTFIFO entries: Sequencer Free SCB List: 24 10 4 12 17 22 15 5 7 28 8 18 30 6 23 26 14 21 1 19 27 29 11 25 3 2 9 13 20 16 0 Sequencer SCB Info: 0 SCB_CONTROL[0xe0] SCB_SCSIID[0x7] SCB_LUN[0x0] SCB_TAG[0xff] 1 SCB_CONTROL[0xe0] SCB_SCSIID[0x7] SCB_LUN[0x0] SCB_TAG[0xff] 2 SCB_CONTROL[0xe0] SCB_SCSIID[0x7] SCB_LUN[0x0] SCB_TAG[0xff] 3 SCB_CONTROL[0xe0] SCB_SCSIID[0x7] SCB_LUN[0x0] SCB_TAG[0xff] 4 SCB_CONTROL[0x0] SCB_SCSIID[0x7] SCB_LUN[0x0] SCB_TAG[0xff] 5 SCB_CONTROL[0x0] SCB_SCSIID[0x7] SCB_LUN[0x0] SCB_TAG[0xff] 6 SCB_CONTROL[0xe0] SCB_SCSIID[0x7] SCB_LUN[0x0] SCB_TAG[0xff] 7 SCB_CONTROL[0x0] SCB_SCSIID[0x7] SCB_LUN[0x0] SCB_TAG[0xff] 8 SCB_CONTROL[0xe0] SCB_SCSIID[0x7] SCB_LUN[0x0] SCB_TAG[0xff] 9 SCB_CONTROL[0xe0] SCB_SCSIID[0x7] SCB_LUN[0x0] SCB_TAG[0xff] 10 SCB_CONTROL[0x0] SCB_SCSIID[0x7] SCB_LUN[0x0] SCB_TAG[0xff] 11 SCB_CONTROL[0xe0] SCB_SCSIID[0x7] SCB_LUN[0x0] SCB_TAG[0xff] 12 SCB_CONTROL[0x0] SCB_SCSIID[0x7] SCB_LUN[0x0] SCB_TAG[0xff] 13 SCB_CONTROL[0xe0] SCB_SCSIID[0x7] SCB_LUN[0x0] SCB_TAG[0xff] 14 SCB_CONTROL[0xe0] SCB_SCSIID[0x7] SCB_LUN[0x0] SCB_TAG[0xff] 15 SCB_CONTROL[0x0] SCB_SCSIID[0x7] SCB_LUN[0x0] SCB_TAG[0xff] 16 SCB_CONTROL[0xe0] SCB_SCSIID[0x7] SCB_LUN[0x0] SCB_TAG[0xff] 17 SCB_CONTROL[0x0] SCB_SCSIID[0x7] SCB_LUN[0x0] SCB_TAG[0xff] 18 SCB_CONTROL[0xe0] SCB_SCSIID[0x7] SCB_LUN[0x0] SCB_TAG[0xff] 19 SCB_CONTROL[0xe0] SCB_SCSIID[0x7] SCB_LUN[0x0] SCB_TAG[0xff] 20 SCB_CONTROL[0xe0] SCB_SCSIID[0x7] SCB_LUN[0x0] SCB_TAG[0xff] 21 SCB_CONTROL[0xe0] SCB_SCSIID[0x7] SCB_LUN[0x0] SCB_TAG[0xff] 22 SCB_CONTROL[0x0] SCB_SCSIID[0x7] SCB_LUN[0x0] SCB_TAG[0xff] 23 SCB_CONTROL[0xe0] SCB_SCSIID[0x7] SCB_LUN[0x0] SCB_TAG[0xff] 24 SCB_CONTROL[0x0] SCB_SCSIID[0x7] SCB_LUN[0x0] SCB_TAG[0xff] 25 SCB_CONTROL[0xe0] SCB_SCSIID[0x7] SCB_LUN[0x0] SCB_TAG[0xff] 26 SCB_CONTROL[0xe0] SCB_SCSIID[0x7] SCB_LUN[0x0] SCB_TAG[0xff] 27 SCB_CONTROL[0xe0] SCB_SCSIID[0x7] SCB_LUN[0x0] SCB_TAG[0xff] 28 SCB_CONTROL[0xe0] SCB_SCSIID[0x7] SCB_LUN[0x0] SCB_TAG[0xff] 29 SCB_CONTROL[0xe0] SCB_SCSIID[0x7] SCB_LUN[0x0] SCB_TAG[0xff] 30 SCB_CONTROL[0xe0] SCB_SCSIID[0x7] SCB_LUN[0x0] SCB_TAG[0xff] 31 SCB_CONTROL[0x60] SCB_SCSIID[0x7] SCB_LUN[0x0] SCB_TAG[0x41] Pending list: 22 SCB_CONTROL[0x72] SCB_SCSIID[0x7] SCB_LUN[0x0] 110 SCB_CONTROL[0x70] SCB_SCSIID[0x7] SCB_LUN[0x0] 127 SCB_CONTROL[0x72] SCB_SCSIID[0x7] SCB_LUN[0x0] 104 SCB_CONTROL[0x72] SCB_SCSIID[0x7] SCB_LUN[0x0] 59 SCB_CONTROL[0x70] SCB_SCSIID[0x7] SCB_LUN[0x0] 80 SCB_CONTROL[0x70] SCB_SCSIID[0x7] SCB_LUN[0x0] 87 SCB_CONTROL[0x70] SCB_SCSIID[0x7] SCB_LUN[0x0] 30 SCB_CONTROL[0x70] SCB_SCSIID[0x7] SCB_LUN[0x0] 106 SCB_CONTROL[0x70] SCB_SCSIID[0x7] SCB_LUN[0x0] 37 SCB_CONTROL[0x70] SCB_SCSIID[0x7] SCB_LUN[0x0] 86 SCB_CONTROL[0x70] SCB_SCSIID[0x7] SCB_LUN[0x0] 76 SCB_CONTROL[0x70] SCB_SCSIID[0x7] SCB_LUN[0x0] 124 SCB_CONTROL[0x70] SCB_SCSIID[0x7] SCB_LUN[0x0] 65 SCB_CONTROL[0x60] SCB_SCSIID[0x7] SCB_LUN[0x0] Kernel Free SCB list: 5 118 81 94 27 97 14 56 1 115 93 128 33 41 31 36 12 54 64 79 4 55 63 107 70 119 15 39 77 69 66 17 67 95 58 16 75 100 53 29 47 125 60 111 71 10 129 114 82 25 35 99 117 83 44 38 123 92 74 126 90 85 50 46 32 68 45 21 48 102 96 57 42 89 43 78 109 62 23 72 0 116 120 2 11 105 20 103 52 101 26 24 121 51 122 40 112 18 34 84 73 13 7 91 28 108 19 9 8 88 3 61 49 6 113 <<<<<<<<<<<<<<<<< Dump Card State Ends >>>>>>>>>>>>>>>>>> (da0:ahc0:0:0:0): SCB 0x41 - timed out sg[0] - Addr 0x62cd000 : Length 4096 sg[1] - Addr 0x656e000 : Length 4096 (da0:ahc0:0:0:0): no longer in timeout, status = 34b ahc0: Issued Channel A Bus Reset. 14 SCBs aborted ahc0: Timedout SCBs already complete. Interrupts may not be functioning. fxp1: device timeout From owner-freebsd-stable@FreeBSD.ORG Tue Jan 2 15:37:16 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org 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 2348A16A407 for ; Tue, 2 Jan 2007 15:37:16 +0000 (UTC) (envelope-from dashmoho@gmail.com) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.237]) by mx1.freebsd.org (Postfix) with ESMTP id 9C7BD13C465 for ; Tue, 2 Jan 2007 15:37:15 +0000 (UTC) (envelope-from dashmoho@gmail.com) Received: by wx-out-0506.google.com with SMTP id s18so5685660wxc for ; Tue, 02 Jan 2007 07:37:15 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=iPwHomfb/WguNP+f7BEfLB+x2U6KGmmb82X4w1bI4HwaPQ0/067QF3iBQ0WL7ZLXkfde7zjsK+dVxS+zLDQCcs+3xzPneNcWMN47phafUTNVpvYuhBHyLJHgl9UvckOLTgYNQLHKSJ4BXEZWGtQNFtbWxFRWL28n8Usa59DmkW0= Received: by 10.90.71.12 with SMTP id t12mr5337521aga.1167750689886; Tue, 02 Jan 2007 07:11:29 -0800 (PST) Received: by 10.90.27.14 with HTTP; Tue, 2 Jan 2007 07:11:29 -0800 (PST) Message-ID: <2dcd50ec0701020711y2d9920e1x815d923e518d1ac0@mail.gmail.com> Date: Tue, 2 Jan 2007 16:11:29 +0100 From: "Daniel Horecki" Sender: dashmoho@gmail.com To: KiORKY In-Reply-To: <9908ec200701020522k411f83eas2ba8c9f76605433f@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <9908ec200701020438y11348fe8k6ef1080802e0024e@mail.gmail.com> <024f01c72e6f$6677c000$9603a8c0@claylaptop> <9908ec200701020522k411f83eas2ba8c9f76605433f@mail.gmail.com> X-Google-Sender-Auth: 5abb24f76bc20149 Cc: freebsd-stable@freebsd.org Subject: Re: keyboard shorcut 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, 02 Jan 2007 15:37:16 -0000 On 1/2/07, KiORKY wrote: > that's the one i tried without sucess. Then try ctrl-\ -- Daniel 'Shinden' Horecki From owner-freebsd-stable@FreeBSD.ORG Tue Jan 2 16:24:41 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org 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 0830416A415 for ; Tue, 2 Jan 2007 16:24:41 +0000 (UTC) (envelope-from lydianconcepts@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.240]) by mx1.freebsd.org (Postfix) with ESMTP id C286413C457 for ; Tue, 2 Jan 2007 16:24:40 +0000 (UTC) (envelope-from lydianconcepts@gmail.com) Received: by an-out-0708.google.com with SMTP id c24so1590696ana for ; Tue, 02 Jan 2007 08:24:40 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=eOwRrEeaKr9HvIeAlKHllCMFObm7WqAyPVRSIF5FQnQ39xfCw3vbrIEtB6PqezAEsFQmoZwi8DZLo3NaMaCE1YQQMJkTYIvnpvis/djMzyYEWmTIXYoniu1PXATd9G3kEUBXNQtrBfbHvnZlPleZFZYGc2iTv3u2R0hQ2tk3SaE= Received: by 10.78.149.15 with SMTP id w15mr3365087hud.1167753468324; Tue, 02 Jan 2007 07:57:48 -0800 (PST) Received: by 10.78.201.14 with HTTP; Tue, 2 Jan 2007 07:57:48 -0800 (PST) Message-ID: <7579f7fb0701020757t27c11a8au729cf12a55311cf5@mail.gmail.com> Date: Tue, 2 Jan 2007 07:57:48 -0800 From: "Matthew Jacob" To: freebsd-stable@freebsd.org In-Reply-To: <20070102153608.GA78405@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20070102153608.GA78405@icarus.home.lan> Subject: Re: Interrupt (SCSI?) hang on 4.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: Tue, 02 Jan 2007 16:24:41 -0000 Brute force things to try, IMO: a) Try a different (non-adaptec) SCSI controller b) Run non-SMP c) Swap motherboard From owner-freebsd-stable@FreeBSD.ORG Tue Jan 2 16:56:07 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org 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 7A72616A416 for ; Tue, 2 Jan 2007 16:56:07 +0000 (UTC) (envelope-from zingelman@fnal.gov) Received: from mailgw2.fnal.gov (mailgw2.fnal.gov [131.225.111.12]) by mx1.freebsd.org (Postfix) with ESMTP id 4F53913C45D for ; Tue, 2 Jan 2007 16:56:07 +0000 (UTC) (envelope-from zingelman@fnal.gov) Received: from mailav2.fnal.gov (mailav2.fnal.gov [131.225.111.20]) by mailgw2.fnal.gov (iPlanet Messaging Server 5.2 HotFix 2.06 (built Mar 28 2005)) with SMTP id <0JB900HV707PHY@mailgw2.fnal.gov> for freebsd-stable@freebsd.org; Tue, 02 Jan 2007 09:55:24 -0600 (CST) Received: from mailgw2.fnal.gov ([131.225.111.12]) by mailav2.fnal.gov (SAVSMTP 3.1.7.47) with SMTP id M2007010209552417369 for ; Tue, 02 Jan 2007 09:55:24 -0600 Received: from conversion-daemon.mailgw2.fnal.gov by mailgw2.fnal.gov (iPlanet Messaging Server 5.2 HotFix 2.06 (built Mar 28 2005)) id <0JB900301041I7@mailgw2.fnal.gov> (original mail from zingelman@fnal.gov) for freebsd-stable@freebsd.org; Tue, 02 Jan 2007 09:55:24 -0600 (CST) Received: from nova.fnal.gov (nova.fnal.gov [131.225.121.207]) by mailgw2.fnal.gov (iPlanet Messaging Server 5.2 HotFix 2.06 (built Mar 28 2005)) with ESMTP id <0JB900GVF08CBH@mailgw2.fnal.gov> for freebsd-stable@freebsd.org; Tue, 02 Jan 2007 09:55:24 -0600 (CST) Received: from nova.fnal.gov (localhost [127.0.0.1]) by nova.fnal.gov (8.13.8+Sun/8.13.8) with ESMTP id l02FtN0t009149 for ; Tue, 02 Jan 2007 09:55:23 -0600 (CST) Received: from localhost (tez@localhost) by nova.fnal.gov (8.13.8+Sun/8.13.8/Submit) with ESMTP id l02FtM3V009145 for ; Tue, 02 Jan 2007 09:55:23 -0600 (CST) Date: Tue, 02 Jan 2007 09:55:22 -0600 (CST) From: Tim Zingelman X-X-Sender: tez@nova.fnal.gov To: freebsd-stable@freebsd.org Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Content-transfer-encoding: 7BIT X-Authentication-warning: nova.fnal.gov: tez owned process doing -bs Subject: panic: vn_finished_write: neg cnt X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Tim Zingelman List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jan 2007 16:56:07 -0000 # cd /usr/obj/usr/src/sys/SMP/ # kgdb kernel.debug /var/crash/vmcore.0 [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so: Undefined symbol "ps_pglobal_lookup"] GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd". Unread portion of the kernel message buffer: panic: vn_finished_write: neg cnt cpuid = 1 Uptime: 4d21h14m32s Dumping 2047 MB (2 chunks) chunk 0: 1MB (159 pages) ... ok chunk 1: 2047MB (524016 pages) 2031 2015 1999 1983 1967 1951 1935 1919 1903 1887 1871 1855 1839 1823 1807 1791 1775 1759 1743 1727 1711 1695 1679 1663 1647 1631 1615 1599 1583 1567 1551 1535 1519 1503 1487 1471 1455 1439 1423 1407 1391 1375 1359 1343 1327 1311 1295 1279 1263 1247 1231 1215 1199 1183 1167 1151 1135 1119 1103 1087 1071 1055 1039 1023 1007 991 975 959 943 927 911 895 879 863 847 831 815 799 783 767 751 735 719 703 687 671 655 639 623 607 591 575 559 543 527 511 495 479 463 447 431 415 399 383 367 351 335 319 303 287 271 255 239 223 207 191 175 159 143 127 111 95 79 63 47 31 15 #0 doadump () at pcpu.h:165 165 __asm __volatile("movl %%fs:0,%0" : "=r" (td)); (kgdb) backtrace #0 doadump () at pcpu.h:165 #1 0xc06754ea in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409 #2 0xc0675811 in panic (fmt=0xc090613a "vn_finished_write: neg cnt") at /usr/src/sys/kern/kern_shutdown.c:565 #3 0xc06dc82f in vn_finished_write (mp=0xc675d530) at /usr/src/sys/kern/vfs_vnops.c:1048 #4 0xc06dbb68 in vn_write (fp=0xccded2d0, uio=0xea002cbc, active_cred=0xc6e5a580, flags=0, td=0xc8623900) at /usr/src/sys/kern/vfs_vnops.c:583 #5 0xc0698f43 in dofilewrite (td=0xc8623900, fd=11, fp=0xccded2d0, auio=0xea002cbc, offset=Unhandled dwarf expression opcode 0x93 ) at file.h:252 #6 0xc0698de7 in kern_writev (td=0xc8623900, fd=11, auio=0xea002cbc) at /usr/src/sys/kern/sys_generic.c:402 #7 0xc0698d0d in write (td=0xc8623900, uap=0x0) at /usr/src/sys/kern/sys_generic.c:326 #8 0xc088e583 in syscall (frame= {tf_fs = 59, tf_es = 59, tf_ds = 59, tf_edi = 134973792, tf_esi = 135065600, tf_ebp = -1077968696, tf_isp = -369087132, tf_ebx = 4096, tf_edx = 4096, tf_ecx = 0, tf_eax = 4, tf_trapno = 4096, tf_err = 2, tf_eip = 134840319, tf_cs = 51, tf_eflags = 582, tf_esp = -1077968756, tf_ss = 59}) at /usr/src/sys/i386/i386/trap.c:983 #9 0xc0879d3f in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:200 #10 0x00000033 in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) up 3 #3 0xc06dc82f in vn_finished_write (mp=0xc675d530) at /usr/src/sys/kern/vfs_vnops.c:1048 1048 panic("vn_finished_write: neg cnt"); (kgdb) list 1043 if (mp == NULL) 1044 return; 1045 MNT_ILOCK(mp); 1046 mp->mnt_writeopcount--; 1047 if (mp->mnt_writeopcount < 0) 1048 panic("vn_finished_write: neg cnt"); 1049 if ((mp->mnt_kern_flag & MNTK_SUSPEND) != 0 && 1050 mp->mnt_writeopcount <= 0) 1051 wakeup(&mp->mnt_writeopcount); 1052 MNT_IUNLOCK(mp); (kgdb) print *mp $1 = {mnt_list = {tqe_next = 0xc675d298, tqe_prev = 0xc675d7c8}, mnt_op = 0xc09ae620, mnt_vfc = 0xc09ae660, mnt_vnodecovered = 0xc6794660, mnt_syncer = 0xc694b660, mnt_nvnodelist = {tqh_first = 0xc7595330, tqh_last = 0xcab48014}, mnt_lock = {lk_interlock = 0xc09dceb8, lk_flags = 0, lk_sharecount = 0, lk_waitcount = 0, lk_exclusivecount = 0, lk_prio = 80, lk_wmesg = 0xc09056c9 "vfslock", lk_timo = 0, lk_lockholder = 0xffffffff, lk_newlock = 0x0}, mnt_mtx = {mtx_object = { lo_class = 0xc09750e4, lo_name = 0xc09056b8 "struct mount mtx", lo_type = 0xc09056b8 "struct mount mtx", lo_flags = 196608, lo_list = { tqe_next = 0x0, tqe_prev = 0x0}, lo_witness = 0x0}, mtx_lock = 3361880322, mtx_recurse = 0}, mnt_writeopcount = -1, mnt_flag = 2101504, mnt_opt = 0xc68098e0, mnt_optnew = 0x0, mnt_kern_flag = 536870912, mnt_maxsymlinklen = 120, mnt_stat = { f_version = 537068824, f_type = 7, f_flags = 2101504, f_bsize = 2048, f_iosize = 16384, f_blocks = 292488222, f_bfree = 188891807, f_bavail = 165492750, f_files = 75601918, f_ffree = 66247979, f_syncwrites = 0, f_asyncwrites = 0, f_syncreads = 0, f_asyncreads = 0, f_spare = {0, 0, 0, 0, 0, 0, 0, 0, 0, 0}, f_namemax = 255, f_owner = 0, f_fsid = {val = {1164144299, -1500130876}}, f_charspare = '\0' , f_fstypename = "ufs", '\0' , f_mntfromname = "/dev/da0s1f", '\0' , f_mntonname = "/usr", '\0' }, mnt_cred = 0xc695ad00, mnt_data = 0xc6749b00, mnt_time = 0, mnt_iosize_max = 131072, mnt_export = 0xc674cc00, mnt_mntlabel = 0x0, mnt_fslabel = 0x0, mnt_nvnodelistsize = 58931, mnt_hashseed = 3969027219, mnt_markercnt = 0, mnt_holdcnt = 0, mnt_holdcntwaiters = 0, mnt_secondary_writes = 0, mnt_secondary_accwrites = 504046284, mnt_ref = 58931, mnt_gen = 1} (kgdb) up #4 0xc06dbb68 in vn_write (fp=0xccded2d0, uio=0xea002cbc, active_cred=0xc6e5a580, flags=0, td=0xc8623900) at /usr/src/sys/kern/vfs_vnops.c:583 583 vn_finished_write(mp); (kgdb) list 578 if ((flags & FOF_OFFSET) == 0) 579 fp->f_offset = uio->uio_offset; 580 fp->f_nextoff = uio->uio_offset; 581 VOP_UNLOCK(vp, 0, td); 582 if (vp->v_type != VCHR) 583 vn_finished_write(mp); 584 unlock: 585 VFS_UNLOCK_GIANT(vfslocked); 586 return (error); 587 } (kgdb) print flags $5 = 0 (kgdb) print *uio $6 = {uio_iov = 0xea002cb4, uio_iovcnt = 1, uio_offset = 1245192, uio_resid = 0, uio_segflg = UIO_USERSPACE, uio_rw = UIO_WRITE, uio_td = 0xc8623900} (kgdb) print *vp $3 = {v_type = VREG, v_tag = 0xc0904786 "ufs", v_op = 0xc09ae980, v_data = 0xcce7edec, v_mount = 0xc675d530, v_nmntvnodes = { tqe_next = 0xcd9dc660, tqe_prev = 0xc7902014}, v_un = {vu_mount = 0x0, vu_socket = 0x0, vu_cdev = 0x0, vu_fifoinfo = 0x0}, v_hashlist = { le_next = 0xcda56770, le_prev = 0xc65f5b14}, v_hash = 26239538, v_cache_src = {lh_first = 0x0}, v_cache_dst = {tqh_first = 0xc86c3594, tqh_last = 0xc86c35a4}, v_dd = 0x0, v_cstart = 72, v_lasta = 419301280, v_lastw = 75, v_clen = 7, v_lock = {lk_interlock = 0xc09dd218, lk_flags = 64, lk_sharecount = 0, lk_waitcount = 0, lk_exclusivecount = 0, lk_prio = 80, lk_wmesg = 0xc0904786 "ufs", lk_timo = 51, lk_lockholder = 0xffffffff, lk_newlock = 0x0}, v_interlock = { mtx_object = {lo_class = 0xc09750e4, lo_name = 0xc0905d01 "vnode interlock", lo_type = 0xc0905d01 "vnode interlock", lo_flags = 196608, lo_list = { tqe_next = 0x0, tqe_prev = 0x0}, lo_witness = 0x0}, mtx_lock = 4, mtx_recurse = 0}, v_vnlock = 0xc8de09e8, v_holdcnt = 80, v_usecount = 1, v_iflag = 0, v_vflag = 0, v_writecount = 1, v_freelist = {tqe_next = 0x0, tqe_prev = 0x0}, v_bufobj = {bo_mtx = 0xc8de0a0c, bo_clean = {bv_hd = { tqh_first = 0xda668910, tqh_last = 0xda524060}, bv_root = 0xda524028, bv_cnt = 72}, bo_dirty = {bv_hd = {tqh_first = 0xda6651f8, tqh_last = 0xda560670}, bv_root = 0xda560638, bv_cnt = 6}, bo_numoutput = 0, bo_flag = 1, bo_ops = 0xc097b364, bo_bsize = 16384, bo_object = 0xcd26c39c, bo_synclist = {le_next = 0xca39c3f0, le_prev = 0xcab480f8}, bo_private = 0xc8de0990, __bo_vnode = 0xc8de0990}, v_pollinfo = 0x0, v_label = 0x0} (kgdb) print *td $7 = {td_proc = 0xcda11430, td_ksegrp = 0xcd9f2ba0, td_plist = { tqe_next = 0x0, tqe_prev = 0xcda11440}, td_kglist = {tqe_next = 0x0, tqe_prev = 0xcd9f2bac}, td_slpq = {tqe_next = 0x0, tqe_prev = 0xc7b0a880}, td_lockq = {tqe_next = 0x0, tqe_prev = 0xe9fdbb1c}, td_runq = { tqe_next = 0x0, tqe_prev = 0x0}, td_selq = {tqh_first = 0x0, tqh_last = 0xc8623930}, td_sleepqueue = 0xc7b0a880, td_turnstile = 0xc8072280, td_umtxq = 0xc72a8800, td_tid = 101129, td_flags = 83951619, td_inhibitors = 0, td_pflags = 0, td_dupfd = 0, td_wchan = 0x0, td_wmesg = 0x0, td_lastcpu = 1 '\001', td_oncpu = 0 '\0', td_owepreempt = 0 '\0', td_locks = 3, td_blocked = 0x0, td_ithd = 0x0, td_lockname = 0x0, td_contested = {lh_first = 0xcd213c00}, td_sleeplocks = 0x0, td_intr_nesting_level = 0, td_pinned = 0, td_mailbox = 0x0, td_ucred = 0xc6e5a580, td_standin = 0x0, td_upcall = 0x0, td_sticks = 2330, td_uuticks = 0, td_usticks = 0, td_intrval = 0, td_oldsigmask = {__bits = {0, 0, 0, 0}}, td_sigmask = {__bits = {0, 0, 0, 0}}, td_siglist = {__bits = {0, 0, 0, 0}}, td_generation = 451, td_sigstk = {ss_sp = 0x0, ss_size = 0, ss_flags = 4}, td_kflags = 0, td_xsig = 0, td_profil_addr = 0, td_profil_ticks = 0, td_base_pri = 216 'X', td_priority = 211 'S', td_pcb = 0xea002d90, td_state = TDS_RUNNING, td_retval = {0, 4096}, td_slpcallout = {c_links = {sle = {sle_next = 0x0}, tqe = {tqe_next = 0x0, tqe_prev = 0xda412da8}}, c_time = 422055083, c_arg = 0xc8623900, c_func = 0xc0695340 , c_mtx = 0x0, c_flags = 18}, td_frame = 0xea002d38, td_kstack_obj = 0xcd578738, td_kstack = 3925872640, td_kstack_pages = 2, td_altkstack_obj = 0x0, td_altkstack = 0, td_altkstack_pages = 0, td_critnest = 1, td_md = { md_spinlock_count = 1, md_saved_flags = 582}, td_sched = 0xc8623a58, td_ar = 0x0} (kgdb) print *fp $4 = {f_list = {le_next = 0xce1440d8, le_prev = 0xc6801900}, f_type = 1, f_data = 0xc8de0990, f_flag = 3, f_mtxp = 0xc63dbd00, f_ops = 0xc097cfe0, f_cred = 0xc6e5a580, f_count = 2, f_vnode = 0xc8de0990, f_offset = 1245192, f_vnread_flags = 0, f_gcflag = 0, f_msgcount = 0, f_seqcount = 127, f_nextoff = 1245192, f_label = 0x0} What other info might be of use? System was doing a buildworld -j26 and downloading a port distfile at the time of the crash. System has been attempting to build a package for every port in the tree while looping over buildworld with various large -j numbers to try and prove the system is stable. Twice I have seen: twa0: WARNING: (0x04: 0x0036): Verify fixed data/parity mismatch: unit=2 a couple of times... but nothing else. Here is the interesting part of the dmesg output... more details available if anyone wants to look at this. FreeBSD 6.2-RC2 #3: Wed Dec 27 15:22:35 CST 2006 toor@host.name.xyz:/usr/obj/usr/src/sys/SMP Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Dual Core AMD Opteron(tm) Processor 280 (2393.19-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x20f12 Stepping = 2 Features=0x178bfbff Features2=0x1 AMD Features=0xe2500800 AMD Features2=0x3 Cores per package: 2 real memory = 2147418112 (2047 MB) avail memory = 2096295936 (1999 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 MADT: Forcing active-low polarity and level trigger for SCI ioapic0 irqs 0-23 on motherboard ioapic1 irqs 24-27 on motherboard ioapic2 irqs 28-31 on motherboard kbd1 at kbdmux0 ath_hal: 0.9.17.2 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) acpi0: on motherboard acpi0: Power Button (fixed) Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x5008-0x500b on acpi0 bge0: mem 0xfc9e0000-0xfc9effff irq 26 at device 5.0 on pci2 miibus0: on bge0 brgphy0: on miibus0 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, 1000baseTX-FDX, auto bge0: Ethernet address: 00:30:48:5a:8f:92 bge1: mem 0xfc9b0000-0xfc9bffff irq 27 at device 5.1 on pci2 miibus1: on bge1 brgphy1: on miibus1 brgphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, 1000baseTX-FDX, auto bge1: Ethernet address: 00:30:48:5a:8f:93 3ware device driver for 9000 series storage controllers, version: 3.60.02.012 twa0: <3ware 9000 series Storage Controller> port 0xac00-0xac3f mem 0xfa000000-0xfbffffff,0xfc8ff000-0xfc8fffff irq 29 at device 3.0 on pci1 twa0: [FAST] twa0: INFO: (0x04: 0x0053): Battery capacity test is overdue: twa0: INFO: (0x15: 0x1300): Controller details:: Model 9550SX-12MI, 12 ports, Firmware FE9X 3.04.00.005, BIOS BE9X 3.04.00.002 da0 at twa0 bus 0 target 2 lun 0 da0: Fixed Direct Access SCSI-3 device da0: 100.000MB/s transfers da0: 915495MB (1874933760 512 byte sectors: 255H 63S/T 116709C) SMP: AP CPU #1 Launched! SMP: AP CPU #3 Launched! SMP: AP CPU #2 Launched! Trying to mount root from ufs:/dev/da0s1a bge0: link state changed to UP vmmon: SMP support for this release is BROKEN. module_register_init: MOD_LOAD (vmmon, 0xc6c020b4, 0) error 22 vmnet1: Ethernet address: 00:bd:a0:4f:00:01 (note that vmmon is not used, just loaded because I've been building packages for the whole ports tree to burn in this box) From owner-freebsd-stable@FreeBSD.ORG Tue Jan 2 17:10:43 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org 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 0AADD16A504; Tue, 2 Jan 2007 17:10:43 +0000 (UTC) (envelope-from gavin.atkinson@ury.york.ac.uk) Received: from mail-gw4.york.ac.uk (mail-gw4.york.ac.uk [144.32.128.249]) by mx1.freebsd.org (Postfix) with ESMTP id 98F5213C45D; Tue, 2 Jan 2007 17:10:42 +0000 (UTC) (envelope-from gavin.atkinson@ury.york.ac.uk) Received: from buffy.york.ac.uk (buffy-128.york.ac.uk [144.32.128.160]) by mail-gw4.york.ac.uk (8.13.6/8.13.6) with ESMTP id l02Gdq4p009466; Tue, 2 Jan 2007 16:39:52 GMT Received: from buffy.york.ac.uk (localhost [127.0.0.1]) by buffy.york.ac.uk (8.13.8/8.13.6) with ESMTP id l02GdqRN086561; Tue, 2 Jan 2007 16:39:52 GMT (envelope-from gavin.atkinson@ury.york.ac.uk) Received: (from ga9@localhost) by buffy.york.ac.uk (8.13.8/8.13.6/Submit) id l02Gdqjw086560; Tue, 2 Jan 2007 16:39:52 GMT (envelope-from gavin.atkinson@ury.york.ac.uk) X-Authentication-Warning: buffy.york.ac.uk: ga9 set sender to gavin.atkinson@ury.york.ac.uk using -f From: Gavin Atkinson To: Jeremy Chadwick In-Reply-To: <20070102153608.GA78405@icarus.home.lan> References: <20070102153608.GA78405@icarus.home.lan> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Tue, 02 Jan 2007 16:39:51 +0000 Message-Id: <1167755991.84652.6.camel@buffy.york.ac.uk> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 FreeBSD GNOME Team Port X-York-MailScanner: Found to be clean X-York-MailScanner-From: gavin.atkinson@ury.york.ac.uk Cc: freebsd-stable@freebsd.org Subject: Re: Interrupt (SCSI?) hang on 4.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: Tue, 02 Jan 2007 17:10:43 -0000 On Tue, 2007-01-02 at 07:36 -0800, Jeremy Chadwick wrote: > Yes, I know 4.11 is EOL'd at the end of this month, but hopefully > someone can shed some light on this problem anyways. I simply don't > have the knowledge of what's going on on a low-level to determine > the cause. > > I do have serial console on this box, and after enabling some > debugging for the ahc(4) driver a few months back, was able to > get something intelligent out of the system regarding SCBs this > morning. This may not be useful (or the cause), though. I also > cannot enable drop-to-DDB-on-serial-break because our Portmaster 2 > has been known to send a serial break on rare occasion. :-( > > Every so often (sometimes hours, sometimes months -- usually months), > the 4.11 box we have "locks up" in the sense that both NICs on the > box stop working, and the SCSI controller also appears hung. This > problem has existed for a couple years; it's not specific to 4.11 > (versus 4.10 or 4.9). > > # vmstat -i > ata0 irq14 6 0 > fxp0 irq10 14874 28 > mux irq11 65028 125 > fdc0 irq6 1 0 > sio0 irq4 948 1 > clk irq0 516187 998 > rtc irq8 66071 127 > Total 663115 1282 Do any of these numbers continue to increase after the hang? You may find that if you are already logged in over the serial port before the hang and have run vmstat recently, it'll still be runnable due to it being cached. If the serial port is dead, you will probably still find you can get output from the serial port, so start "date; vmstat -i" in a loop over the serial port before it hangs, and watch the output once it wedges. Gavin From owner-freebsd-stable@FreeBSD.ORG Tue Jan 2 18:04:40 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org 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 47C9916A412 for ; Tue, 2 Jan 2007 18:04:40 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from sccrmhc11.comcast.net (sccrmhc11.comcast.net [204.127.200.81]) by mx1.freebsd.org (Postfix) with ESMTP id 11D2B13C458 for ; Tue, 2 Jan 2007 18:04:39 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from icarus.home.lan (c-67-174-220-97.hsd1.ca.comcast.net[67.174.220.97]) by comcast.net (sccrmhc11) with ESMTP id <2007010218043901100pmln8e>; Tue, 2 Jan 2007 18:04:39 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id BD8C61FA038; Tue, 2 Jan 2007 10:04:38 -0800 (PST) Date: Tue, 2 Jan 2007 10:04:38 -0800 From: Jeremy Chadwick To: Gavin Atkinson Message-ID: <20070102180438.GA81454@icarus.home.lan> Mail-Followup-To: Gavin Atkinson , freebsd-stable@freebsd.org References: <20070102153608.GA78405@icarus.home.lan> <1167755991.84652.6.camel@buffy.york.ac.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1167755991.84652.6.camel@buffy.york.ac.uk> X-PGP-Key: http://jdc.parodius.com/pubkey.asc User-Agent: Mutt/1.5.13 (2006-08-11) Cc: freebsd-stable@freebsd.org Subject: Re: Interrupt (SCSI?) hang on 4.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: Tue, 02 Jan 2007 18:04:40 -0000 On Tue, Jan 02, 2007 at 04:39:51PM +0000, Gavin Atkinson wrote: > On Tue, 2007-01-02 at 07:36 -0800, Jeremy Chadwick wrote: > > # vmstat -i > > ata0 irq14 6 0 > > fxp0 irq10 14874 28 > > mux irq11 65028 125 > > fdc0 irq6 1 0 > > sio0 irq4 948 1 > > clk irq0 516187 998 > > rtc irq8 66071 127 > > Total 663115 1282 > > Do any of these numbers continue to increase after the hang? You may > find that if you are already logged in over the serial port before the > hang and have run vmstat recently, it'll still be runnable due to it > being cached. When this problem is happening, at the login: prompt (via serial console) once one types "root" and hits enter, one never gets a Password: prompt. This is likely because getpwent(3) and friends attempt to read passwd/master.passwd from the disk, which obviously hung due to the SCSI controller. Therefore, one cannot log in and run any commands. > If the serial port is dead, you will probably still find you can get > output from the serial port, so start "date; vmstat -i" in a loop over > the serial port before it hangs, and watch the output once it wedges. Once the machine is hung like described, since running shell commands (date/vmstat/even spawning sh itself) involves disk I/O, this won't work. If date and vmstat could be cached in memory somewhere, this might work, but I don't know how one would do that. (A memory filesystem could work, but pretty much all of / would have to be there for this to work...) The best I could do would be to have a cronjob or a process running in a screen session which does date && vmstat -i over and over to a log file, and examine that log once the machine hung like described. This wouldn't tell us if the numbers were increasing/fluxuating *after* the hang, though. :-( -- | Jeremy Chadwick jdc at 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 Jan 2 18:49:55 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org 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 080B516A407 for ; Tue, 2 Jan 2007 18:49:55 +0000 (UTC) (envelope-from mike@jellydonut.org) Received: from mail2.secureworks.net (mail2.secureworks.net [65.114.32.154]) by mx1.freebsd.org (Postfix) with ESMTP id D739513C458 for ; Tue, 2 Jan 2007 18:49:54 +0000 (UTC) (envelope-from mike@jellydonut.org) Received: from localhost (localhost [127.0.0.1]) by mail2.secureworks.net (Postfix) with ESMTP id 490C517298; Tue, 2 Jan 2007 13:20:03 -0500 (EST) X-Virus-Scanned: amavisd-new at secureworks.net Received: from mail2.secureworks.net ([127.0.0.1]) by localhost (mail2.secureworks.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Pg2M3gIkLbA; Tue, 2 Jan 2007 13:20:03 -0500 (EST) Received: from [192.168.23.35] (mole1.secureworks.net [63.239.86.3]) by mail2.secureworks.net (Postfix) with ESMTP id 105B51729F; Tue, 2 Jan 2007 13:20:03 -0500 (EST) Message-ID: <459AA253.20603@jellydonut.org> Date: Tue, 02 Jan 2007 13:20:03 -0500 From: Michael Proto User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.8.0.9) Gecko/20061228 Thunderbird/1.5.0.9 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: Gavin Atkinson , freebsd-stable@freebsd.org References: <20070102153608.GA78405@icarus.home.lan> <1167755991.84652.6.camel@buffy.york.ac.uk> <20070102180438.GA81454@icarus.home.lan> In-Reply-To: <20070102180438.GA81454@icarus.home.lan> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Subject: Re: Interrupt (SCSI?) hang on 4.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: Tue, 02 Jan 2007 18:49:55 -0000 Jeremy Chadwick wrote: > Once the machine is hung like described, since running shell > commands (date/vmstat/even spawning sh itself) involves disk I/O, > this won't work. If date and vmstat could be cached in memory > somewhere, this might work, but I don't know how one would do that. > (A memory filesystem could work, but pretty much all of / would > have to be there for this to work...) > > The best I could do would be to have a cronjob or a process running > in a screen session which does date && vmstat -i over and over to a > log file, and examine that log once the machine hung like described. > This wouldn't tell us if the numbers were increasing/fluxuating > *after* the hang, though. :-( > You *could* create a small ramdisk, copy /lib into it (along with /usr/bin/vmstat, /bin/sh, and any other needed utils), then set the LD_LIBRARAY_PATH to /mnt/lib or wherever the ramdisk is mounted and run vmstat. If you are already logged-in prior to the hang then utils on the mfs should run provided all their libraries are also on the mfs. I use a very similar process on a small Soekris box when I do an in-place flash upgrade which runs dd over the entire disk (a 32 MB compact flash card) while the box is still running from the same disk. My pre-upgrade script copies /sbin/reboot, /bin/dd, /lib/libc.so.6, and /lib/libutil.so.5 to a small mfs mounted at /mnt and sets LD_LIBRARY_PATH to /mnt prior to running dd (after which "reboot -lnq" is run, also from the mfs). -Proto From owner-freebsd-stable@FreeBSD.ORG Tue Jan 2 20:33:36 2007 Return-Path: X-Original-To: stable@freebsd.org 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 BAF6816A407 for ; Tue, 2 Jan 2007 20:33:36 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from mail.digiware.nl (www.tegenbosch28.nl [217.21.251.97]) by mx1.freebsd.org (Postfix) with ESMTP id 7CF9813C458 for ; Tue, 2 Jan 2007 20:33:36 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from [192.168.2.10] (www.tegenbosch28.nl [217.21.251.97]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.digiware.nl (Postfix) with ESMTP id 4D64317150 for ; Tue, 2 Jan 2007 21:06:19 +0100 (CET) Message-ID: <459ABB40.7050603@digiware.nl> Date: Tue, 02 Jan 2007 21:06:24 +0100 From: Willem Jan Withagen Organization: Digiware User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: running mksnap_ffs 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, 02 Jan 2007 20:33:36 -0000 Hi, I got the following Filesystem: Filesystem Size Used Avail Capacity iused ifree %iused /dev/da0a 1.3T 422G 823G 34% 565952 182833470 0% Running of a 3ware 9550, on a dual core Opteron 242 with 1Gb. The system is used as SMB/NFS server for my other systems here. I would like to make weekly snapshots, but manually running mksnap_ffs freezes access to the disk (I sort of expected that) but the process never terminates. So I let is sit overnight, but looking a gstat did not reveil any activity what so ever... The disk was not released, mksnap_ffs could not be terminated. And things resulted in me rebooting the system. So: - How long should I expect making a snapshot to take: 5, 15, 30min, 1, 2 hour or even more??? - How do I diagnose the reason why it is not terminating? --WjW From owner-freebsd-stable@FreeBSD.ORG Tue Jan 2 21:36:35 2007 Return-Path: X-Original-To: stable@freebsd.org 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 0954D16A415 for ; Tue, 2 Jan 2007 21:36:35 +0000 (UTC) (envelope-from mike@jellydonut.org) Received: from mail2.secureworks.net (mail2.secureworks.net [65.114.32.154]) by mx1.freebsd.org (Postfix) with ESMTP id B1E1F13C468 for ; Tue, 2 Jan 2007 21:36:34 +0000 (UTC) (envelope-from mike@jellydonut.org) Received: from localhost (localhost [127.0.0.1]) by mail2.secureworks.net (Postfix) with ESMTP id 6152D172F5; Tue, 2 Jan 2007 16:10:52 -0500 (EST) X-Virus-Scanned: amavisd-new at secureworks.net Received: from mail2.secureworks.net ([127.0.0.1]) by localhost (mail2.secureworks.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c+pMgM6uxTyo; Tue, 2 Jan 2007 16:10:52 -0500 (EST) Received: from [192.168.23.35] (mole1.secureworks.net [63.239.86.3]) by mail2.secureworks.net (Postfix) with ESMTP id 29811172F3; Tue, 2 Jan 2007 16:10:52 -0500 (EST) Message-ID: <459ACA5D.4010208@jellydonut.org> Date: Tue, 02 Jan 2007 16:10:53 -0500 From: Michael Proto User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.8.0.9) Gecko/20061228 Thunderbird/1.5.0.9 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: Willem Jan Withagen References: <459ABB40.7050603@digiware.nl> In-Reply-To: <459ABB40.7050603@digiware.nl> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: stable@freebsd.org Subject: Re: running mksnap_ffs 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, 02 Jan 2007 21:36:35 -0000 Willem Jan Withagen wrote: > Hi, > > I got the following Filesystem: > Filesystem Size Used Avail Capacity iused ifree %iused > /dev/da0a 1.3T 422G 823G 34% 565952 182833470 0% > > Running of a 3ware 9550, on a dual core Opteron 242 with 1Gb. > The system is used as SMB/NFS server for my other systems here. > > I would like to make weekly snapshots, but manually running mksnap_ffs > freezes access to the disk (I sort of expected that) but the process > never terminates. So I let is sit overnight, but looking a gstat did not > reveil any activity what so ever... > The disk was not released, mksnap_ffs could not be terminated. > And things resulted in me rebooting the system. > > So: > - How long should I expect making a snapshot to take: > 5, 15, 30min, 1, 2 hour or even more??? > - How do I diagnose the reason why it is not terminating? > > --WjW For a point of reference, I have 2 300GB SerialATA disks in a RAID1 config that I take daily snapshots of. df info: Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/ar0s1d 283810134 160945668 117188264 58% /r1 As of last night, this snapshot took 18m59.77s to complete. -Proto From owner-freebsd-stable@FreeBSD.ORG Tue Jan 2 22:03:35 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org 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 32F6A16A688 for ; Tue, 2 Jan 2007 22:03:35 +0000 (UTC) (envelope-from uspoerlein@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.190]) by mx1.freebsd.org (Postfix) with ESMTP id BADD713C441 for ; Tue, 2 Jan 2007 22:03:34 +0000 (UTC) (envelope-from uspoerlein@gmail.com) Received: by nf-out-0910.google.com with SMTP id x37so6951760nfc for ; Tue, 02 Jan 2007 14:03:33 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:date:from:to:cc:subject:message-id:mail-followup-to:references:mime-version:content-type:content-disposition:in-reply-to; b=Rf/eSy25JAFokDx/jU/VlWI1LarZvikB8eF1pk/+BO8ZHH5rfb7WRC/AvWfilCGE7VVShmpMeMJPRF4poVOXXk1m/EwFunLKdT0il71QnPV6Aa62sYROvalgaKvAT3Y/YBJ4SDnRNGiukkBBMc9SMzm5HXZy8/07yL/rjmAx3TY= Received: by 10.49.19.5 with SMTP id w5mr23477510nfi.1167773741796; Tue, 02 Jan 2007 13:35:41 -0800 (PST) Received: from roadrunner.q.local ( [85.180.173.128]) by mx.google.com with ESMTP id l27sm86242343nfa.2007.01.02.13.35.40; Tue, 02 Jan 2007 13:35:41 -0800 (PST) Received: from roadrunner.q.local (localhost [127.0.0.1]) by roadrunner.q.local (8.13.8/8.13.8) with ESMTP id l02LZWIb003961; Tue, 2 Jan 2007 22:35:32 +0100 (CET) (envelope-from uspoerlein@gmail.com) Received: (from q@localhost) by roadrunner.q.local (8.13.8/8.13.8/Submit) id l02LP3Rk003572; Tue, 2 Jan 2007 22:25:03 +0100 (CET) (envelope-from uspoerlein@gmail.com) Date: Tue, 2 Jan 2007 22:25:03 +0100 From: Ulrich Spoerlein To: "Christopher Harper (05056409)" <05056409@students.lincoln.ac.uk> Message-ID: <20070102212503.GC1603@roadrunner.q.local> Mail-Followup-To: "Christopher Harper (05056409)" <05056409@students.lincoln.ac.uk>, freebsd-stable@freebsd.org References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Cc: freebsd-stable@freebsd.org Subject: Re: Page Fault in 6.2-PRE RELEASE 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, 02 Jan 2007 22:03:35 -0000 Christopher Harper (05056409) wrote: > The system freezes randomly and no longer accepts any input and after a minute of being 'frozen' reboots. > (kgdb) backtrace > #0 doadump () at pcpu.h:165 > #1 0xc051a6ca in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409 > #2 0xc051a9f1 in panic (fmt=0xc06d94cf "%s") at /usr/src/sys/kern/kern_shutdown.c:565 > #3 0xc06a795c in trap_fatal (frame=0xe6dc6bac, eva=4) at /usr/src/sys/i386/i386/trap.c:837 > #4 0xc06a769b in trap_pfault (frame=0xe6dc6bac, usermode=0, eva=4) at /usr/src/sys/i386/i386/trap.c:745 > #5 0xc06a72d5 in trap (frame= > {tf_fs = 8, tf_es = -963641304, tf_ds = -961019864, tf_edi = -963964928, tf_esi = 0, tf_ebp = -421762056, tf_isp = -421762088, tf_ebx = -963961644, tf_edx = -421655072, tf_ecx = -964085760, tf_eax = 0, tf_trapno = 12, tf_err = 0, tf_eip = -1067808807, tf_cs = 32, tf_eflags = 66118, tf_esp = -963961644, tf_ss = -963615744}) > at /usr/src/sys/i386/i386/trap.c:435 > #6 0xc069342a in calltrap () at /usr/src/sys/i386/i386/exception.s:139 > #7 0xc05a87d9 in ieee80211_free_node (ni=0x0) at /usr/src/sys/net80211/ieee80211_node.c:1605 > #8 0xc04b1923 in ural_txeof (xfer=0xc6b82d00, priv=0xc68b1cd4, status=USBD_NORMAL_COMPLETION) at /usr/src/sys/dev/usb/if_ural.c:888 > #9 0xc04c9b1a in usb_transfer_complete (xfer=0xc6b82d00) at /usr/src/sys/dev/usb/usbdi.c:863 > #10 0xc04acbae in ehci_idone (ex=0xc6b82d00) at /usr/src/sys/dev/usb/ehci.c:852 > #11 0xc04acaeb in ehci_check_intr (sc=0xc6893800, ex=0xc6b82d00) at /usr/src/sys/dev/usb/ehci.c:759 > #12 0xc04aca25 in ehci_softintr (v=0xc6893800) at /usr/src/sys/dev/usb/ehci.c:693 > #13 0xc04c6e55 in usb_schedsoftintr (bus=0x0) at /usr/src/sys/dev/usb/usb.c:871 > #14 0xc04ac806 in ehci_intr1 (sc=0xc6893800) at /usr/src/sys/dev/usb/ehci.c:593 > #15 0xc04ac746 in ehci_intr (v=0xc6893800) at /usr/src/sys/dev/usb/ehci.c:552 > #16 0xc0505059 in ithread_execute_handlers (p=0xc68ff648, ie=0xc67e3b00) at /usr/src/sys/kern/kern_intr.c:682 > #17 0xc0505169 in ithread_loop (arg=0xc68b7480) at /usr/src/sys/kern/kern_intr.c:765 > #18 0xc0503e0d in fork_exit (callout=0xc0505114 , arg=0xc68b7480, frame=0xe6dc6d38) at /usr/src/sys/kern/kern_fork.c:821 > #19 0xc069348c in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:208 This is the same as kern/92083 [1] I could suggest, that you try with the new USB stack by Hans-Petter Selasky. But there is a different bug in his ural(4), that makes it unusable too. http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/92083 Ulrich Spoerlein -- A: Yes. >Q: Are you sure? > >A: Because it reverses the logical flow of conversation. > >>Q: Why is top posting frowned upon? From owner-freebsd-stable@FreeBSD.ORG Tue Jan 2 22:55:33 2007 Return-Path: X-Original-To: stable@freebsd.org 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 5F90616A407 for ; Tue, 2 Jan 2007 22:55:33 +0000 (UTC) (envelope-from gpalmer@freebsd.org) Received: from noop.in-addr.com (noop.in-addr.com [208.58.23.51]) by mx1.freebsd.org (Postfix) with ESMTP id 3999013C457 for ; Tue, 2 Jan 2007 22:55:33 +0000 (UTC) (envelope-from gpalmer@freebsd.org) Received: from gjp by noop.in-addr.com with local (Exim 4.54 (FreeBSD)) id 1H1rzH-000POW-39; Tue, 02 Jan 2007 17:20:03 -0500 Date: Tue, 2 Jan 2007 17:20:03 -0500 From: Gary Palmer To: Willem Jan Withagen Message-ID: <20070102222003.GB90174@in-addr.com> Mail-Followup-To: Willem Jan Withagen , stable@freebsd.org References: <459ABB40.7050603@digiware.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <459ABB40.7050603@digiware.nl> Cc: stable@freebsd.org Subject: Re: running mksnap_ffs 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, 02 Jan 2007 22:55:33 -0000 On Tue, Jan 02, 2007 at 09:06:24PM +0100, Willem Jan Withagen wrote: > Hi, > > I got the following Filesystem: > Filesystem Size Used Avail Capacity iused ifree %iused > /dev/da0a 1.3T 422G 823G 34% 565952 182833470 0% > > Running of a 3ware 9550, on a dual core Opteron 242 with 1Gb. > The system is used as SMB/NFS server for my other systems here. > > I would like to make weekly snapshots, but manually running mksnap_ffs > freezes access to the disk (I sort of expected that) but the process > never terminates. So I let is sit overnight, but looking a gstat did not > reveil any activity what so ever... > The disk was not released, mksnap_ffs could not be terminated. > And things resulted in me rebooting the system. > > So: > - How long should I expect making a snapshot to take: > 5, 15, 30min, 1, 2 hour or even more??? > - How do I diagnose the reason why it is not terminating? You forgot to mention what revision of FreeBSD you are running, and if you are using quotas or anything else on the filesystem that could impact this. From owner-freebsd-stable@FreeBSD.ORG Tue Jan 2 23:20:16 2007 Return-Path: X-Original-To: stable@freebsd.org 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 BA59416A40F for ; Tue, 2 Jan 2007 23:20:16 +0000 (UTC) (envelope-from wjw@withagen.nl) Received: from mail.digiware.nl (www.tegenbosch28.nl [217.21.251.97]) by mx1.freebsd.org (Postfix) with ESMTP id 7592B13C455 for ; Tue, 2 Jan 2007 23:20:16 +0000 (UTC) (envelope-from wjw@withagen.nl) Received: from [212.61.27.67] (opteron.digiware.nl [212.61.27.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.digiware.nl (Postfix) with ESMTP id ECA7917125 for ; Wed, 3 Jan 2007 00:03:25 +0100 (CET) Message-ID: <459AE536.5040007@withagen.nl> Date: Wed, 03 Jan 2007 00:05:26 +0100 From: Willem Jan Withagen User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: stable@freebsd.org References: <459ABB40.7050603@digiware.nl> <20070102222003.GB90174@in-addr.com> In-Reply-To: <20070102222003.GB90174@in-addr.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: running mksnap_ffs 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, 02 Jan 2007 23:20:16 -0000 Gary Palmer wrote: > On Tue, Jan 02, 2007 at 09:06:24PM +0100, Willem Jan Withagen wrote: >> Hi, >> >> I got the following Filesystem: >> Filesystem Size Used Avail Capacity iused ifree %iused >> /dev/da0a 1.3T 422G 823G 34% 565952 182833470 0% >> >> Running of a 3ware 9550, on a dual core Opteron 242 with 1Gb. >> The system is used as SMB/NFS server for my other systems here. >> >> I would like to make weekly snapshots, but manually running mksnap_ffs >> freezes access to the disk (I sort of expected that) but the process >> never terminates. So I let is sit overnight, but looking a gstat did not >> reveil any activity what so ever... >> The disk was not released, mksnap_ffs could not be terminated. >> And things resulted in me rebooting the system. >> >> So: >> - How long should I expect making a snapshot to take: >> 5, 15, 30min, 1, 2 hour or even more??? >> - How do I diagnose the reason why it is not terminating? > > You forgot to mention what revision of FreeBSD you are running, and > if you are using quotas or anything else on the filesystem that > could impact this. Yes, I pressed send somewhat to fast: [~] wjw@bigsurf> uname -a FreeBSD bigsurf.digiware.nl 6.2-PRERELEASE FreeBSD 6.2-PRERELEASE #3: Wed Sep 27 15:57:20 CEST 2006 wjw@bigsurf.digiware.nl:/usr/obj/usr/src/sys/BIGSURF amd64 --WjW From owner-freebsd-stable@FreeBSD.ORG Wed Jan 3 08:45:16 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org 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 5957616A403 for ; Wed, 3 Jan 2007 08:45:16 +0000 (UTC) (envelope-from michael@ranner.eu) Received: from files.jawa.at (jawa.at [213.229.17.146]) by mx1.freebsd.org (Postfix) with ESMTP id 8AE7613C471 for ; Wed, 3 Jan 2007 08:45:15 +0000 (UTC) (envelope-from michael@ranner.eu) Received: from localhost (localhost [127.0.0.1]) by files.jawa.at (Postfix) with ESMTP id 42A1FCA447 for ; Wed, 3 Jan 2007 09:24:29 +0100 (CET) X-Virus-Scanned: amavisd-new at jawa.at Received: from files.jawa.at ([127.0.0.1]) by localhost (files.jawa.at [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p6efES0g5793 for ; Wed, 3 Jan 2007 09:24:28 +0100 (CET) Received: by files.jawa.at (Postfix, from userid 60) id 52B22CA2C4; Wed, 3 Jan 2007 09:24:28 +0100 (CET) X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on files.jawa.at X-Spam-Level: X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.1.1 Received: from thing.jawa.at (thing.jawa.at [192.168.200.51]) by files.jawa.at (Postfix) with ESMTP id DF025C94C3 for ; Wed, 3 Jan 2007 09:24:25 +0100 (CET) From: Michael Ranner To: freebsd-stable@freebsd.org Date: Wed, 3 Jan 2007 09:24:27 +0100 User-Agent: KMail/1.9.1 X-Face: #9%^GysNTDxI*%"_&lAc2.*)yY/E/Ir-rb7q Subject: Panic with 6.2-RC2 on halt -p 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, 03 Jan 2007 08:45:16 -0000 Hello there! Since updating from 6.1 to 6.2-RC2 I have nearly every time a panic on shutdown or halting my Athlon X2 Dual Core system. It seems, that it happens only after mounting filesystems rw, because it does not happen after starting in single user mode. The panic occurs sometime immediate on pressing the power button, I think when init 0 is invoked or yesterday after entering halt -p, the systems shuts down and during or after the syncing (6 6 6 4 4 2 0 0) but before the kernel power down the system. Has someone similar observed? I will setup a debug kernel this evening. -- /\/\ichael Ranner mranner@inode.at - mranner@jawa.at - mranner@bugat.at ----------------------------------------------------- BSD Usergroup Austria - http://www.bugat.at/ -----BEGIN GEEK CODE BLOCK----- GIT/CS/AT dx(-) s+:(++:) a- C++ UBLVS++++$ P++>+++$ L-(+)$ E--- W+++$ N+(++) o-- K- w--()$ O-(--) M@ V-(--) PS+>++ PE(-) Y+ PGP(-) t+ 5+ X+++(++++) R* tv++ b+(++) DI++ D-(--) G- e h--(*) r++ y? ------END GEEK CODE BLOCK------ From owner-freebsd-stable@FreeBSD.ORG Wed Jan 3 10:40:03 2007 Return-Path: X-Original-To: stable@freebsd.org 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 7660716A403 for ; Wed, 3 Jan 2007 10:40:03 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from relay02.kiev.sovam.com (relay02.kiev.sovam.com [62.64.120.197]) by mx1.freebsd.org (Postfix) with ESMTP id 0085613C448 for ; Wed, 3 Jan 2007 10:40:02 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from [212.82.216.227] (helo=fw.zoral.com.ua) by relay02.kiev.sovam.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60) (envelope-from ) id 1H23Gh-000Jmb-BG for stable@freebsd.org; Wed, 03 Jan 2007 12:22:55 +0200 Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by fw.zoral.com.ua (8.13.4/8.13.4) with ESMTP id l03AMh0P092848 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 3 Jan 2007 12:22:43 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.13.8/8.13.8) with ESMTP id l03AMg8Y036817; Wed, 3 Jan 2007 12:22:42 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.13.8/8.13.8/Submit) id l03AMgb0036816; Wed, 3 Jan 2007 12:22:42 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 3 Jan 2007 12:22:42 +0200 From: Kostik Belousov To: Willem Jan Withagen Message-ID: <20070103102242.GB21325@deviant.kiev.zoral.com.ua> References: <459ABB40.7050603@digiware.nl> <20070102222003.GB90174@in-addr.com> <459AE536.5040007@withagen.nl> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="7oQ1FFvyVKNZi+9s" Content-Disposition: inline In-Reply-To: <459AE536.5040007@withagen.nl> User-Agent: Mutt/1.4.2.2i X-Virus-Scanned: ClamAV version 0.88.7, clamav-milter version 0.88.7 on fw.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-0.1 required=5.0 tests=ALL_TRUSTED,SPF_NEUTRAL autolearn=failed version=3.1.7 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on fw.zoral.com.ua X-Scanner-Signature: 6dc4245230f22f3abb357b69a6da667e X-DrWeb-checked: yes X-SpamTest-Envelope-From: kostikbel@gmail.com X-SpamTest-Group-ID: 00000000 X-SpamTest-Info: Profiles 661 [Dec 30 2006] X-SpamTest-Info: helo_type=3 X-SpamTest-Info: {received from trusted relay: not dialup} X-SpamTest-Method: none X-SpamTest-Method: Local Lists X-SpamTest-Rate: 0 X-SpamTest-Status: Not detected X-SpamTest-Status-Extended: not_detected X-SpamTest-Version: SMTP-Filter Version 3.0.0 [0255], KAS30/Release Cc: stable@freebsd.org Subject: Re: running mksnap_ffs 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, 03 Jan 2007 10:40:03 -0000 --7oQ1FFvyVKNZi+9s Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jan 03, 2007 at 12:05:26AM +0100, Willem Jan Withagen wrote: > Gary Palmer wrote: > >On Tue, Jan 02, 2007 at 09:06:24PM +0100, Willem Jan Withagen wrote: > >>Hi, > >> > >>I got the following Filesystem: > >>Filesystem Size Used Avail Capacity iused ifree %iused=20 > >>/dev/da0a 1.3T 422G 823G 34% 565952 182833470 0% > >> > >>Running of a 3ware 9550, on a dual core Opteron 242 with 1Gb. > >>The system is used as SMB/NFS server for my other systems here. > >> > >>I would like to make weekly snapshots, but manually running mksnap_ffs= =20 > >>freezes access to the disk (I sort of expected that) but the process=20 > >>never terminates. So I let is sit overnight, but looking a gstat did no= t=20 > >>reveil any activity what so ever... > >>The disk was not released, mksnap_ffs could not be terminated. > >>And things resulted in me rebooting the system. > >> > >>So: > >> - How long should I expect making a snapshot to take: > >> 5, 15, 30min, 1, 2 hour or even more??? > >> - How do I diagnose the reason why it is not terminating? > > > >You forgot to mention what revision of FreeBSD you are running, and > >if you are using quotas or anything else on the filesystem that > >could impact this. >=20 > Yes, I pressed send somewhat to fast: >=20 > [~] wjw@bigsurf> uname -a > FreeBSD bigsurf.digiware.nl 6.2-PRERELEASE FreeBSD 6.2-PRERELEASE #3: Wed= =20 > Sep 27 15:57:20 CEST 2006 =20 > wjw@bigsurf.digiware.nl:/usr/obj/usr/src/sys/BIGSURF amd64 See http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kernel= debug-deadlocks.html for instruction how to gather information needed to debug the problem. --7oQ1FFvyVKNZi+9s Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFFm4PyC3+MBN1Mb4gRAglOAKCwqzl43xDEXWR+2p/r5SueP38KSgCfR7Qd 7fQCwQqCBGNkB/4BNzOZoj8= =uFpu -----END PGP SIGNATURE----- --7oQ1FFvyVKNZi+9s-- From owner-freebsd-stable@FreeBSD.ORG Wed Jan 3 13:24:14 2007 Return-Path: X-Original-To: stable@freebsd.org 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 C2A3516A492 for ; Wed, 3 Jan 2007 13:24:14 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [210.51.165.229]) by mx1.freebsd.org (Postfix) with ESMTP id 2B18413C44B for ; Wed, 3 Jan 2007 13:24:13 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from localhost (tarsier.geekcn.org [210.51.165.229]) by tarsier.geekcn.org (Postfix) with ESMTP id DD7EDEB5820; Wed, 3 Jan 2007 21:23:59 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([210.51.165.229]) by localhost (mail.geekcn.org [210.51.165.229]) (amavisd-new, port 10024) with ESMTP id DgxB1JX3iWMJ; Wed, 3 Jan 2007 21:23:56 +0800 (CST) Received: from [192.168.1.32] (unknown [221.222.203.216]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTP id 46B07EB57FD; Wed, 3 Jan 2007 21:23:56 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=delphij.net; c=nofws; q=dns; h=message-id:date:from:organization:user-agent:mime-version:to:cc: subject:references:in-reply-to:x-enigmail-version:content-type; b=oDvmsm/SaoBGtHelEhufR7krQfmJrYrah6j7e3ybtykfDLgxqveHXB7R9RVow/z2l dvkMHfpIVjlb8Yp+pZUqQ== Message-ID: <459BAE28.5070300@delphij.net> Date: Wed, 03 Jan 2007 21:22:48 +0800 From: LI Xin Organization: The FreeBSD Project User-Agent: Thunderbird 1.5.0.9 (Macintosh/20061207) MIME-Version: 1.0 To: Willem Jan Withagen References: <459ABB40.7050603@digiware.nl> In-Reply-To: <459ABB40.7050603@digiware.nl> X-Enigmail-Version: 0.94.1.0 Content-Type: multipart/signed; micalg=pgp-ripemd160; protocol="application/pgp-signature"; boundary="------------enigA16E0A95EA09DBDD90D1573B" Cc: stable@freebsd.org Subject: Re: running mksnap_ffs 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, 03 Jan 2007 13:24:14 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigA16E0A95EA09DBDD90D1573B Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Willem Jan Withagen wrote: > Hi, >=20 > I got the following Filesystem: > Filesystem Size Used Avail Capacity iused ifree %iused > /dev/da0a 1.3T 422G 823G 34% 565952 182833470 0% >=20 > Running of a 3ware 9550, on a dual core Opteron 242 with 1Gb. > The system is used as SMB/NFS server for my other systems here. >=20 > I would like to make weekly snapshots, but manually running mksnap_ffs > freezes access to the disk (I sort of expected that) but the process > never terminates. So I let is sit overnight, but looking a gstat did no= t > reveil any activity what so ever... > The disk was not released, mksnap_ffs could not be terminated. > And things resulted in me rebooting the system. >=20 > So: > - How long should I expect making a snapshot to take: > 5, 15, 30min, 1, 2 hour or even more??? This depends how much cylinder groups do you have. If you have a lot of large files, using "newfs -b 32768" instead of the default settings would speed up the process drastically. Note that this might be unfeasable because you already have data on the disk. Another suggestion is to separate the volume into smaller slices, this would reduce the impact. BTW. Our experience with a semi full 1.3T volume is that the snapshot would take about 1 hour on FreeBSD 5.x, but I doubt that it is not really comparable to your situation as the hardware is very different. > - How do I diagnose the reason why it is not terminating? This might be somewhat complicated. Check out the developers' handbook. Cheers, --=20 Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! --------------enigA16E0A95EA09DBDD90D1573B Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFm64oOfuToMruuMARA148AJ9n/zFEbqXAaGk178NEizOlxtuorwCfSOye A7iQGPedfxTRDmAPLrLx/jA= =bJlV -----END PGP SIGNATURE----- --------------enigA16E0A95EA09DBDD90D1573B-- From owner-freebsd-stable@FreeBSD.ORG Wed Jan 3 13:45:20 2007 Return-Path: X-Original-To: stable@freebsd.org 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 7C7C716A403; Wed, 3 Jan 2007 13:45:20 +0000 (UTC) (envelope-from eugen@www.svzserv.kemerovo.su) Received: from www.svzserv.kemerovo.su (www.svzserv.kemerovo.su [213.184.65.80]) by mx1.freebsd.org (Postfix) with ESMTP id D29D613C441; Wed, 3 Jan 2007 13:45:19 +0000 (UTC) (envelope-from eugen@www.svzserv.kemerovo.su) Received: from www.svzserv.kemerovo.su (eugen@localhost [127.0.0.1]) by www.svzserv.kemerovo.su (8.13.8/8.13.8) with ESMTP id l03DjHNq072005; Wed, 3 Jan 2007 20:45:17 +0700 (KRAT) (envelope-from eugen@www.svzserv.kemerovo.su) Received: (from eugen@localhost) by www.svzserv.kemerovo.su (8.13.8/8.13.8/Submit) id l03DjGbh072004; Wed, 3 Jan 2007 20:45:16 +0700 (KRAT) (envelope-from eugen) Date: Wed, 3 Jan 2007 20:45:16 +0700 From: Eugene Grosbein To: Remko Lodder Message-ID: <20070103134516.GA70826@svzserv.kemerovo.su> References: <200701022021.l02KLXkf001599@grosbein.pp.ru> <459ACC8B.1080105@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <459ACC8B.1080105@FreeBSD.org> User-Agent: Mutt/1.4.2.1i Cc: stable@freebsd.org Subject: Re: kern/107439: 6.2-PRE repeatable panic: userret: Returning with 1 locks held X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bug-followup@freebsd.org List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jan 2007 13:45:20 -0000 On Tue, Jan 02, 2007 at 10:20:11PM +0100, Remko Lodder wrote: > It is generally known that the NTFS code is not for > general read/write access; > > From the manual page: > > WRITING > There is limited writing ability. Limitations: file must be > nonresident > and must not contain any sparces (uninitialized areas); compressed > files > are also not supported. The file name must not contain multibyte > charac- > ters. > > I think you are hitting this issue.. Hmm, I've just tried to move file from one fs to another, for NTFS this basically means unlink attempt, isn't it? The manual does not say that unlinking's not supported. Eugene From owner-freebsd-stable@FreeBSD.ORG Wed Jan 3 14:20:20 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org 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 CF55716A415 for ; Wed, 3 Jan 2007 14:20:20 +0000 (UTC) (envelope-from lists@mschuette.name) Received: from mail.asta.uni-potsdam.de (mail.asta.uni-potsdam.de [141.89.58.198]) by mx1.freebsd.org (Postfix) with ESMTP id 6FD3F13C459 for ; Wed, 3 Jan 2007 14:20:20 +0000 (UTC) (envelope-from lists@mschuette.name) Received: from localhost (mail.asta.uni-potsdam.de [141.89.58.198]) by mail.asta.uni-potsdam.de (Postfix) with ESMTP id EF9F3EBC32 for ; Wed, 3 Jan 2007 14:54:24 +0100 (CET) X-Virus-Scanned: on mail at asta.uni-potsdam.de Received: from mail.asta.uni-potsdam.de ([141.89.58.198]) by localhost (mail.asta.uni-potsdam.de [141.89.58.198]) (amavisd-new, port 10024) with ESMTP id hkvHbAN1P6v1 for ; Wed, 3 Jan 2007 14:54:13 +0100 (CET) Received: from [192.168.178.21] (V9d43.v.pppool.de [89.57.157.67]) by mail.asta.uni-potsdam.de (Postfix) with ESMTP id 06F8CEBC23 for ; Wed, 3 Jan 2007 14:54:12 +0100 (CET) Message-ID: <459BB587.7060007@mschuette.name> Date: Wed, 03 Jan 2007 14:54:15 +0100 From: =?ISO-8859-15?Q?Martin_Sch=FCtte?= User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <20061219073943.W74584@polaris.astro.ufl.edu> <20061227035530.GC9859@xor.obsecurity.org> In-Reply-To: <20061227035530.GC9859@xor.obsecurity.org> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: "swap_pager" loop? 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, 03 Jan 2007 14:20:20 -0000 Kris Kennaway schrieb: >> The machine has 4gb of ram, a 4gb swap partition on /dev/amrd0s1b, and >> provides nfs/nis/samba/printing (cups) services. I have the same problem with FreeBSD 6.1-RELEASE on my SMP-System (2xAthlon MP) with an asr-RAID (Adaptec 2110S). The disks are OK (complete read with 'dd if=/dev/da...' showed no errors). The deadlocks often occured during backups, so I suspect a race condition or too many interrupts to be the cause. > You could try increasing the timeout in the msleep() in > vm/swap_pager.c. If your system is just so heavily loaded that the > I/O command really is taking more than 20 seconds to complete, you may > be getting false positives. I set my timeout to 40 secs, without deadlocks since then. But instead I got two Crashes with Trap 12: page fault. lock order reversal: sleepable after non-sleepable 1st 0x... unp@/usr/src/sys/kern/uipc_usrreq.c:981 2nd 0x... usermap@/usr/src/sys/vm/vm_map.c:2997 Any suggestions are welcome. -- Martin Schütte From owner-freebsd-stable@FreeBSD.ORG Wed Jan 3 15:21:36 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org 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 983F216A505 for ; Wed, 3 Jan 2007 15:21:36 +0000 (UTC) (envelope-from xuchen66@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.173]) by mx1.freebsd.org (Postfix) with ESMTP id 32C9313C459 for ; Wed, 3 Jan 2007 15:21:36 +0000 (UTC) (envelope-from xuchen66@gmail.com) Received: by ug-out-1314.google.com with SMTP id o2so4605742uge for ; Wed, 03 Jan 2007 07:21:35 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=jTIjxOPLUeAaD/LYGmQiVph/ETq1wH52b6cSWfKeYU9jphfsnZUsXaauzWN9KvmvNtF4jFyR23U7zzw4IMWb33rCMi3BSNNVqjWvpdmMiUtMlE6I1Lf/ROP7Lsn3BMHAPeMMGZ3GHhWZncXrtVgxVcwreYC56NOGzX11KPXBIcM= Received: by 10.82.167.5 with SMTP id p5mr2111968bue.1167836216766; Wed, 03 Jan 2007 06:56:56 -0800 (PST) Received: by 10.82.161.6 with HTTP; Wed, 3 Jan 2007 06:56:56 -0800 (PST) Message-ID: <184b087c0701030656q1cfc57b5k1c6325eda97b9451@mail.gmail.com> Date: Wed, 3 Jan 2007 09:56:56 -0500 From: "Chen Xu" To: "Michael Ranner" In-Reply-To: <200701030924.27456.michael@ranner.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200701030924.27456.michael@ranner.eu> Cc: freebsd-stable@freebsd.org Subject: Re: Panic with 6.2-RC2 on halt -p 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, 03 Jan 2007 15:21:36 -0000 Hi all, I had a very similar kernel panic after cvsuping at Dec 29th afternoon USA eastern time. Any application related to network or x-window will cause panic. I even could not cvsup anymore. Luckily, I have another box which has source at 24th. I reversed everything to that day. Regards, Chen On 1/3/07, Michael Ranner wrote: > Hello there! > > Since updating from 6.1 to 6.2-RC2 I have nearly every time a panic on > shutdown or halting my Athlon X2 Dual Core system. It seems, that it happens > only after mounting filesystems rw, because it does not happen after starting > in single user mode. > > The panic occurs sometime immediate on pressing the power button, I think when > init 0 is invoked or yesterday after entering halt -p, the systems shuts down > and during or after the syncing (6 6 6 4 4 2 0 0) but before the kernel power > down the system. > > Has someone similar observed? > > I will setup a debug kernel this evening. > > -- > /\/\ichael Ranner > > mranner@inode.at - mranner@jawa.at - mranner@bugat.at > ----------------------------------------------------- > BSD Usergroup Austria - http://www.bugat.at/ > > -----BEGIN GEEK CODE BLOCK----- > GIT/CS/AT dx(-) s+:(++:) a- C++ UBLVS++++$ P++>+++$ L-(+)$ E--- > W+++$ N+(++) o-- K- w--()$ O-(--) M@ V-(--) PS+>++ PE(-) Y+ PGP(-) > t+ 5+ X+++(++++) R* tv++ b+(++) DI++ D-(--) G- e h--(*) r++ y? > ------END GEEK CODE BLOCK------ > _______________________________________________ > 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 Wed Jan 3 16:19:11 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org 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 D09A416A407 for ; Wed, 3 Jan 2007 16:19:11 +0000 (UTC) (envelope-from sven@dmv.com) Received: from smtp-gw-cl-d.dmv.com (smtp-gw-cl-d.dmv.com [216.240.97.42]) by mx1.freebsd.org (Postfix) with ESMTP id 9589613C458 for ; Wed, 3 Jan 2007 16:19:11 +0000 (UTC) (envelope-from sven@dmv.com) Received: from mail-gw-cl-b.dmv.com (mail-gw-cl-b.dmv.com [216.240.97.39]) by smtp-gw-cl-d.dmv.com (8.12.10/8.12.10) with ESMTP id l03GJAJX037861 for ; Wed, 3 Jan 2007 11:19:10 -0500 (EST) (envelope-from sven@dmv.com) Received: from lanshark.dmv.com (lanshark.dmv.com [216.240.97.46]) by mail-gw-cl-b.dmv.com (8.12.9/8.12.9) with ESMTP id l03GJA8s081277 for ; Wed, 3 Jan 2007 11:19:10 -0500 (EST) (envelope-from sven@dmv.com) From: Sven Willenberger To: freebsd-stable@freebsd.org Content-Type: text/plain Date: Wed, 03 Jan 2007 11:24:39 -0500 Message-Id: <1167841479.30890.17.camel@lanshark.dmv.com> Mime-Version: 1.0 X-Mailer: Evolution 2.6.3 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.48 on 216.240.97.42 X-Scanned-By: MIMEDefang 2.48 on 216.240.97.39 Subject: Verifying serial setup for KDB_UNATTENDED 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, 03 Jan 2007 16:19:11 -0000 We have a RELENG_6 amd64 box that has been experiencing lockups/panics every 4 days or so. The box is at a remote location and trying to get a full trace has been nigh impossible with the staffing constraints. As such I would like to set up a serial console (using another FreeBSD box and minicom or cu). I would like to verify that the following will work to allow a) the other FreeBSD box to have a terminal session via COM1 b) have it work regardless of whether a keyboard and/or monitor is plugged into the target box and c) still allow terminal redirection to internal or serial console if a keyboard is attached : /boot/loader.conf hint.sio.0.flags="0x30" console="comconsole,vidconsole" boot_multicons="YES" boot_console="YES" comsconsole_speed="19200" /etc/ttys ttyd0 "/usr/libexec/getty std.19200" vt100 on secure As this is basically a 6.2 system, I assume I don't need to do anything re: boot blocks or /etc/make.conf or the like? Kernel has already been built with options DDB, options KDB_UNATTENDED, options KDB, options KDB_TRACE. Would the modifications to the 2 files listed above be sufficient to meet my wishes above and allow me to see the panic to terminal when the system does panic (and allow me to even trace, etc via the kdb debugger) ? Thanks, Sven From owner-freebsd-stable@FreeBSD.ORG Wed Jan 3 19:24:50 2007 Return-Path: X-Original-To: stable@freebsd.org 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 703FB16A4C9 for ; Wed, 3 Jan 2007 19:24:50 +0000 (UTC) (envelope-from ShopAETV@newsletters.aetv.com) Received: from mta.newsletters.aetv.com (mta.newsletters.aetv.com [198.31.62.43]) by mx1.freebsd.org (Postfix) with ESMTP id 4D60A13C471 for ; Wed, 3 Jan 2007 19:24:50 +0000 (UTC) (envelope-from ShopAETV@newsletters.aetv.com) Date: Wed, 03 Jan 2007 14:24:50 -0500 (EST) Message-Id: From: "A&E/The History Channel" To: stable@freebsd.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: Subject: Up to 85% off DVDs during our New Year's Sale! 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, 03 Jan 2007 19:24:50 -0000 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Come Join Our New Year's Party: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Up to 85% off over 100 DVDs, plus get a bonus $25 gift card when you spend over $100 dollars. Shop Now http://newsletters.aetv.com/cgi-bin15/DM/y/eX6M0K6nDL0EWk0U8V0Eh ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ We are in celebration mode! Check out our staff's Top 10 for the best titles of 2006-- now up to 85% off! ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ #1 The World At War: Collector's Edition DVD set More than 30 years after its initial broadcast, THE WORLD AT WAR remains the definitive visual history of World War II. Narrated by Academy Award(R) winner Laurence Olivier and digitally re-mastered for DVD, this is epic history at its absolute best. What our staff thinks: "an unvarnished look at WWII, from every perspective" http://newsletters.aetv.com/cgi-bin15/DM/y/eX6M0K6nDL0EWk0U8X0Ej #2 Ultimate Mysteries DVD Collection Gathered together in one stellar DVD collection is the best that mystery has to offer. What our staff thinks: "don't watch it while you're home alone" http://newsletters.aetv.com/cgi-bin15/DM/y/eX6M0K6nDL0EWk0U8Z0El #3 The Revolution: The Series DVD Set Available for the first time in a single DVD set, this sweeping, acclaimed series definitively depicts the foundation of the United States of America. What our staff thinks: "the best recounting of the American Revolution in existence." http://newsletters.aetv.com/cgi-bin15/DM/y/eX6M0K6nDL0EWk0U8b0Et #4 The Best of A&E DVD Collection Like a Greatest Hits for our dedicated viewers, A&E put together the year's best shows in a single incredible DVD collection. What our staff thinks: "the best A&E has to offer -- all in one place." http://newsletters.aetv.com/cgi-bin15/DM/y/eX6M0K6nDL0EWk0U8d0Ev #5 Best of The History Channel DVD Collection 2006 Don't miss this unique opportunity to collect the year's best programming from THE HISTORY CHANNEL at one incredibly low price! What our staff thinks: "It is a best hits collection for the History fan." http://newsletters.aetv.com/cgi-bin15/DM/y/eX6M0K6nDL0EWk0U8f0Ex #6 Ultimate World History Collection DVD Explore the glories of Britannia, the majesty of Russia, the horrors of the French Revolution and the brutal Conquest of America, all inside this comprehensive DVD set. What our staff thinks: "Span the critical moments throughout the World in one set." http://newsletters.aetv.com/cgi-bin15/DM/y/eX6M0K6nDL0EWk0U8h0Ez #7 A&E Network Studios: Romance Classics Collection 1 & 2 DVD Set All your romance favorites are available together for the first time in this extraordinary 28-Volume DVD set. What our staff thinks: "best viewed from the couch with a blanket and a big bowl of popcorn." http://newsletters.aetv.com/cgi-bin15/DM/y/eX6M0K6nDL0EWk0U8k0E3 #8 Desperate Crossing: The Untold Story of the Mayflower DVD So much more than simply the story of the Thanksgiving meal, the epic saga of the Pilgrims - fully realized in this vibrant DVD. What our staff thinks: "a totally new way of looking at the Pilgrims -- fact IS better than fiction." http://newsletters.aetv.com/cgi-bin15/DM/y/eX6M0K6nDL0EWk0U8n0E6 #9 Horatio Hornblower Collector's Edition DVD Set >From midshipman to commander, experience the thrilling escapades of the ultimate high-seas hero with the HORATIO HORNBLOWER COLLECTOR'S EDITION, an eight-volume treasure chest of sweeping naval adventure and lavish historical drama. What our staff thinks: "Horatio does a great job of mixing drama and action together into one fantastic series." http://newsletters.aetv.com/cgi-bin15/DM/y/eX6M0K6nDL0EWk0U8q0EA #10 JFK: A Presidency Revealed DVD set He was a young hero who brought the promise of a new era to the Oval Office. Forty years after his death, the legacy--and mystery--of John F. Kennedy continues to grow. What our staff thinks: "the best history of the man and his legacy I've ever seen." http://newsletters.aetv.com/cgi-bin15/DM/y/eX6M0K6nDL0EWk0U8t0ED For more BEST SELLERS from A&E click here http://newsletters.aetv.com/cgi-bin15/DM/y/eX6M0K6nDL0EWk0U8w0EG For more BEST SELLERS from The History Channel click here http://newsletters.aetv.com/cgi-bin15/DM/y/eX6M0K6nDL0EWk0U8z0EJ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ To ensure delivery of Special Offers from A&E/The History Channel to your inbox (not bulk or junk folders), please add ShopAETV@newsletters.aetv.com to your address book. Your email address, stable@freebsd.org, is signed up to receive new release info and offers from our store. If you do not wish to receive any future email offers from our store, simply send an email to unsub_shop@newsletters.aetv.com We respect your privacy. For more information, view our privacy policy: http://newsletters.aetv.com/cgi-bin15/DM/y/eX6M0K6nDL0EWk0U830E7 A&E Television Networks, Email Marketing 250 Harbor Drive, Stamford, CT 06902 From owner-freebsd-stable@FreeBSD.ORG Wed Jan 3 21:12:19 2007 Return-Path: X-Original-To: freebsd-stable@FreeBSD.ORG 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 7D59C16A412 for ; Wed, 3 Jan 2007 21:12:19 +0000 (UTC) (envelope-from strbenjr@yahoo.com) Received: from smtp106.plus.mail.mud.yahoo.com (smtp106.plus.mail.mud.yahoo.com [68.142.206.239]) by mx1.freebsd.org (Postfix) with SMTP id 434FF13C461 for ; Wed, 3 Jan 2007 21:12:19 +0000 (UTC) (envelope-from strbenjr@yahoo.com) Received: (qmail 91026 invoked from network); 3 Jan 2007 20:45:38 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Received:X-YMail-OSG:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:Content-Type:Content-Transfer-Encoding; b=sFlFeT+pa5nstri298kyzHrALGe/lGHvmmMYKS0JXmyvUBhMzblZiOuv/VGwqPYpCjwf6axmvB2kFJt5SGhqy9QecVU9525/A76x1lVlv9fxAocdR5zPXQEhxvZWl+D1H29jbqci/K/l9N33fkI6KGDrpCRgIZO08l0DYF+BYoA= ; Received: from unknown (HELO ?192.168.7.202?) (strbenjr@69.143.49.135 with plain) by smtp106.plus.mail.mud.yahoo.com with SMTP; 3 Jan 2007 20:45:38 -0000 X-YMail-OSG: v0oZcqUVM1mrN7MWPmoa9q2Wull9MTtUxbUDEqO15qm_nEv7lGJ_tVnSjzQtcF3fNnx0djXl6R.CaMoF68dPUycOOCamoKtFpA8BC7OSpYSI8gUUa39iDsTUObQL6vy3o.NdfcL9GIlpVYXdVjH6TJ7qDYNSmI2vzgxqhws_CZ.rN.a75iKFMJSosbvH Message-ID: <459C15E5.2000904@yahoo.com> Date: Wed, 03 Jan 2007 15:45:25 -0500 From: Ben Hacker Jr User-Agent: Thunderbird 1.5.0.4 (X11/20060702) MIME-Version: 1.0 To: Stable FBSD Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Curitel PC5740 Wireless Modem (EVDO) 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, 03 Jan 2007 21:12:19 -0000 Dear Sir, I am attempting to get a Broad Band Modem working on: sony# uname -a FreeBSD sony.family.hom 6.2-PRERELEASE FreeBSD 6.2-PRERELEASE #2: Tue Dec 19 16:55:50 EST 2006 root@sony.family.hom:/usr/obj/usr/src/sys/SONY01 i386 The device is a Sprint PC5740 pc card. When I perform a "man umodem" the card is listed (vendor = Curitel) UMODEM(4) FreeBSD Kernel Interfaces Manual UMODEM(4) NAME umodem -- USB modem support SYNOPSIS device umodem device ucom DESCRIPTION The umodem driver provides support for USB modems in the Communication Device Class using the Abstract Control Model. ... The device is accessed through the ucom(4) driver which makes it behave like a tty(4). HARDWARE Devices supported by the umodem driver include: o 3Com 5605 o Curitel PC5740 Wireless Modem o Metricom Ricochet GS USB wireless modem ... As stated above this should be recognized as a usb "ucom" device. I stopped the usbd and restarted using "usbd -dv". When I inserted the device I received the following console message: sony# usbd -dv & [1] 753 sony# usbd: opened /dev/usb0 usbd: opened /dev/usb1 usbd: reading configuration file /etc/usbd.conf usbd: opened /dev/usb sony# usbd: ctrlr-attach event bus=2 USB_EVENT_CTRLR_ATTACH USB_EVENT_CTRLR_ATTACH USB_EVENT_CTRLR_ATTACH usbd: driver-attach event cookie=4 devname=uhub2 USB_EVENT_DRIVER_ATTACH USB_EVENT_DRIVER_ATTACH usbd: device-attach event at 1167852825.963798000, OHCI root hub, NEC: vndr=0x0000 prdct=0x0000 rlse=0x0100 clss=0x0009 subclss=0x0000 prtcl=0x0000 device names: uhub2 usbd: Found action 'USB device' for OHCI root hub, NEC at uhub2 usbd: ctrlr-attach event bus=3 USB_EVENT_CTRLR_ATTACH USB_EVENT_CTRLR_ATTACH usbd: driver-attach event cookie=5 devname=uhub3 USB_EVENT_DRIVER_ATTACH USB_EVENT_DRIVER_ATTACH usbd: device-attach event at 1167852826.599332000, OHCI root hub, NEC: vndr=0x0000 prdct=0x0000 rlse=0x0100 clss=0x0009 subclss=0x0000 prtcl=0x0000 device names: uhub3 usbd: Found action 'USB device' for OHCI root hub, NEC at uhub3 usbd: driver-attach event cookie=6 devname=ugen0 USB_EVENT_DRIVER_ATTACH USB_EVENT_DRIVER_ATTACH usbd: device-attach event at 1167852828.349083000, Curitel Communications, Inc., Curitel Communications, Inc.: vndr=0x106c prdct=0x3701 rlse=0x0000 clss=0x0002 subclss=0x0000 prtcl=0x0000 device names: ugen0 usbd: Found action 'USB device' for Curitel Communications, Inc., Curitel Communications, Inc. at ugen0 Please notice that the last two lines indicate that the device was attached to "ugen0" rather then the "ucom0" that I was expecting (and need). I tried to make sure the proper devices were available by manually loading them prior to inserting the card. Here are my loaded modules: (See items 4 & 5 below) sony# kldstat Id Refs Address Size Name 1 13 0xc0400000 47ca94 kernel 2 1 0xc087d000 45b8 snd_t4dwave.ko 3 2 0xc0882000 22b88 sound.ko 4 1 0xc08a5000 3000 uftdi.ko <<<< 5 2 0xc08a8000 32a8 ucom.ko <<<< 6 1 0xc08ac000 59fa4 acpi.ko 7 1 0xc2c4e000 16000 linux.ko Any help will be greatly appreciated! Please reply directly as well as to the list. I am not currently subscribed. http://bsdforums.org/forums/showthread.php?t=45602 (More info on my efforts...) -- Ben Hacker, Jr. Network Systems Administrator strbenjr {at} yahoo.com ben_hacker {at} inter-op.net 703.751.3757 (h) -- -- -- http://www.coeba.org http://www.inter-op.net From owner-freebsd-stable@FreeBSD.ORG Wed Jan 3 21:55:20 2007 Return-Path: X-Original-To: freebsd-stable@FreeBSD.ORG 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 44CF416A416 for ; Wed, 3 Jan 2007 21:55:20 +0000 (UTC) (envelope-from gpalmer@freebsd.org) Received: from noop.in-addr.com (noop.in-addr.com [208.58.23.51]) by mx1.freebsd.org (Postfix) with ESMTP id 1943613C4B0 for ; Wed, 3 Jan 2007 21:55:20 +0000 (UTC) (envelope-from gpalmer@freebsd.org) Received: from gjp by noop.in-addr.com with local (Exim 4.54 (FreeBSD)) id 1H2DdT-0003Hv-53; Wed, 03 Jan 2007 16:26:59 -0500 Date: Wed, 3 Jan 2007 16:26:59 -0500 From: Gary Palmer To: Ben Hacker Jr Message-ID: <20070103212659.GA97624@in-addr.com> Mail-Followup-To: Ben Hacker Jr , Stable FBSD References: <459C15E5.2000904@yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <459C15E5.2000904@yahoo.com> Cc: Stable FBSD Subject: Re: Curitel PC5740 Wireless Modem (EVDO) 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, 03 Jan 2007 21:55:20 -0000 On Wed, Jan 03, 2007 at 03:45:25PM -0500, Ben Hacker Jr wrote: > > Dear Sir, > > I am attempting to get a Broad Band Modem working on: > > sony# uname -a > FreeBSD sony.family.hom 6.2-PRERELEASE FreeBSD 6.2-PRERELEASE #2: > Tue Dec 19 16:55:50 EST 2006 > root@sony.family.hom:/usr/obj/usr/src/sys/SONY01 i386 > > The device is a Sprint PC5740 pc card. When I perform a "man umodem" > the card is listed (vendor = Curitel) > > UMODEM(4) FreeBSD Kernel Interfaces Manual > UMODEM(4) > NAME > umodem -- USB modem support > SYNOPSIS > device umodem > device ucom > DESCRIPTION > The umodem driver provides support for USB modems in the > Communication > Device Class using the Abstract Control Model. ... > > The device is accessed through the ucom(4) driver which makes > it behave > like a tty(4). > > HARDWARE > Devices supported by the umodem driver include: > > o 3Com 5605 > o Curitel PC5740 Wireless Modem > o Metricom Ricochet GS USB wireless modem > ... > > As stated above this should be recognized as a usb "ucom" device. I > stopped the usbd and restarted using "usbd -dv". When I inserted the > device I received the following console message: > > sony# usbd -dv & > [1] 753 > sony# usbd: opened /dev/usb0 > usbd: opened /dev/usb1 > usbd: reading configuration file /etc/usbd.conf > usbd: opened /dev/usb > > sony# usbd: ctrlr-attach event bus=2 > USB_EVENT_CTRLR_ATTACH > USB_EVENT_CTRLR_ATTACH > USB_EVENT_CTRLR_ATTACH > usbd: driver-attach event cookie=4 devname=uhub2 > USB_EVENT_DRIVER_ATTACH > USB_EVENT_DRIVER_ATTACH > usbd: device-attach event at 1167852825.963798000, OHCI root hub, NEC: > vndr=0x0000 prdct=0x0000 rlse=0x0100 clss=0x0009 subclss=0x0000 > prtcl=0x0000 > device names: uhub2 > usbd: Found action 'USB device' for OHCI root hub, NEC at uhub2 > usbd: ctrlr-attach event bus=3 > USB_EVENT_CTRLR_ATTACH > USB_EVENT_CTRLR_ATTACH > usbd: driver-attach event cookie=5 devname=uhub3 > USB_EVENT_DRIVER_ATTACH > USB_EVENT_DRIVER_ATTACH > usbd: device-attach event at 1167852826.599332000, OHCI root hub, NEC: > vndr=0x0000 prdct=0x0000 rlse=0x0100 clss=0x0009 subclss=0x0000 > prtcl=0x0000 > device names: uhub3 > usbd: Found action 'USB device' for OHCI root hub, NEC at uhub3 > usbd: driver-attach event cookie=6 devname=ugen0 > USB_EVENT_DRIVER_ATTACH > USB_EVENT_DRIVER_ATTACH > usbd: device-attach event at 1167852828.349083000, Curitel > Communications, Inc., Curitel Communications, Inc.: > vndr=0x106c prdct=0x3701 rlse=0x0000 clss=0x0002 subclss=0x0000 > prtcl=0x0000 > device names: ugen0 > usbd: Found action 'USB device' for Curitel Communications, Inc., > Curitel Communications, Inc. at ugen0 > > Please notice that the last two lines indicate that the device was > attached to "ugen0" rather then the "ucom0" that I was expecting (and need). > > I tried to make sure the proper devices were available by manually > loading them prior to inserting the card. Here are my loaded modules: > (See items 4 & 5 below) > > sony# kldstat > Id Refs Address Size Name > 1 13 0xc0400000 47ca94 kernel > 2 1 0xc087d000 45b8 snd_t4dwave.ko > 3 2 0xc0882000 22b88 sound.ko > 4 1 0xc08a5000 3000 uftdi.ko <<<< > 5 2 0xc08a8000 32a8 ucom.ko <<<< > 6 1 0xc08ac000 59fa4 acpi.ko > 7 1 0xc2c4e000 16000 linux.ko > > Any help will be greatly appreciated! Please reply directly as well as > to the list. I am not currently subscribed. > > http://bsdforums.org/forums/showthread.php?t=45602 (More info on my > efforts...) The man page isn't 100% clear, but you need to load both ucom and umodem to recognize the device. Try loading umodem and ucom and then attaching (or detaching and reattaching) the device The umodem code does have the vendor/product IDs in it that match the debug info above, so I expect it will be recognized From owner-freebsd-stable@FreeBSD.ORG Wed Jan 3 22:03:08 2007 Return-Path: X-Original-To: freebsd-stable@FreeBSD.ORG 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 1355D16A415 for ; Wed, 3 Jan 2007 22:03:08 +0000 (UTC) (envelope-from strbenjr@yahoo.com) Received: from smtp112.plus.mail.re2.yahoo.com (smtp112.plus.mail.re2.yahoo.com [206.190.53.37]) by mx1.freebsd.org (Postfix) with SMTP id CD23613C45B for ; Wed, 3 Jan 2007 22:03:07 +0000 (UTC) (envelope-from strbenjr@yahoo.com) Received: (qmail 31531 invoked from network); 3 Jan 2007 21:36:27 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Received:X-YMail-OSG:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type; b=bCxBuOOuh23+x1NlvcmVG8CMgkczRkHhvyWTwNOKZCtNvWgTjTG8va6OSOW3UlTFH0HICiiQ+7CsEhiOpN5vMUE5245cKm92wIVpcMBMZTpWGwnavGs1tLUlCmvJJqQALItl1bkkTD7jsO+wnOdjHhXLByuaXt4Lth5IDn6sabU= ; Received: from unknown (HELO ?192.168.7.202?) (strbenjr@69.143.49.135 with plain) by smtp112.plus.mail.re2.yahoo.com with SMTP; 3 Jan 2007 21:36:27 -0000 X-YMail-OSG: Tg_ny5IVM1lxXN3UvgCtfCN1DZ9yzb8wlDZvU50kcxFpsK_woOlfoIj.mS5iKGlXvMwOiRxh49HnMi2fkdSoh2FftZzSAYpsVn.nXS9ZZ9RAm7rJeIeAvOERKGYbGUzBcavaVNGsE_haUcqDPjagGdNvnGpQdC93ZhskeAGPb5KdWWF3Kf2etCw6Xsrf Message-ID: <459C21CF.1010706@yahoo.com> Date: Wed, 03 Jan 2007 16:36:15 -0500 From: Ben Hacker Jr User-Agent: Thunderbird 1.5.0.4 (X11/20060702) MIME-Version: 1.0 To: Gary Palmer , Stable FBSD References: <459C15E5.2000904@yahoo.com> <20070103212659.GA97624@in-addr.com> In-Reply-To: <20070103212659.GA97624@in-addr.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Re: Curitel PC5740 Wireless Modem (EVDO) 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, 03 Jan 2007 22:03:08 -0000 Yep... I just tried that just moments prior to your email. THANKS!!! That solved it.. I only needed to add: umodem_load="YES" to my /boot/loader.conf. The rest was automatic... Thanks so much for taking the time to reply! Gary Palmer wrote: > On Wed, Jan 03, 2007 at 03:45:25PM -0500, Ben Hacker Jr wrote: >> Dear Sir, >> >> I am attempting to get a Broad Band Modem working on: >> >> sony# uname -a >> FreeBSD sony.family.hom 6.2-PRERELEASE FreeBSD 6.2-PRERELEASE #2: >> Tue Dec 19 16:55:50 EST 2006 >> root@sony.family.hom:/usr/obj/usr/src/sys/SONY01 i386 >> >> The device is a Sprint PC5740 pc card. When I perform a "man umodem" >> the card is listed (vendor = Curitel) >> >> --- >> >> As stated (in the umodem man page) this should be recognized as a usb "ucom" device. I >> stopped the usbd and restarted using "usbd -dv". When I inserted the >> device I received the following console message: >> >> sony# usbd -dv & >> [1] 753 >> sony# usbd: opened /dev/usb0 >> usbd: opened /dev/usb1 >> usbd: reading configuration file /etc/usbd.conf >> usbd: opened /dev/usb >> >> sony# usbd: ctrlr-attach event bus=2 >> USB_EVENT_CTRLR_ATTACH >> ... >> USB_EVENT_DRIVER_ATTACH >> usbd: device-attach event at 1167852828.349083000, Curitel >> Communications, Inc., Curitel Communications, Inc.: >> vndr=0x106c prdct=0x3701 rlse=0x0000 clss=0x0002 subclss=0x0000 >> prtcl=0x0000 >> device names: ugen0 >> usbd: Found action 'USB device' for Curitel Communications, Inc., >> Curitel Communications, Inc. at ugen0 >> >> Please notice that the last two lines indicate that the device was >> attached to "ugen0" rather then the "ucom0" that I was expecting (and need). >> >> I tried to make sure the proper devices were available by manually >> loading them prior to inserting the card. Here are my loaded modules: >> (See items 4 & 5 below) >> >> sony# kldstat >> Id Refs Address Size Name >> 1 13 0xc0400000 47ca94 kernel >> 2 1 0xc087d000 45b8 snd_t4dwave.ko >> 3 2 0xc0882000 22b88 sound.ko >> 4 1 0xc08a5000 3000 uftdi.ko <<<< >> 5 2 0xc08a8000 32a8 ucom.ko <<<< >> 6 1 0xc08ac000 59fa4 acpi.ko >> 7 1 0xc2c4e000 16000 linux.ko >> >> Any help will be greatly appreciated! Please reply directly as well as >> to the list. I am not currently subscribed. >> >> http://bsdforums.org/forums/showthread.php?t=45602 (More info on my >> efforts...) > > The man page isn't 100% clear, but you need to load both ucom and > umodem to recognize the device. Try loading umodem and ucom and > then attaching (or detaching and reattaching) the device > > The umodem code does have the vendor/product IDs in it that match > the debug info above, so I expect it will be recognized -- Ben Hacker, Jr. Network Systems Administrator strbenjr {at} yahoo.com ben_hacker {at} inter-op.net 703.751.3757 (h) -- -- -- http://www.coeba.org http://www.inter-op.net From owner-freebsd-stable@FreeBSD.ORG Thu Jan 4 02:15:31 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org 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 97C8816A403 for ; Thu, 4 Jan 2007 02:15:31 +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 9972213C44C for ; Thu, 4 Jan 2007 02:15:30 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from inchoate.gsoft.com.au (inchoate.gsoft.com.au [203.31.81.25]) (authenticated bits=0) by cain.gsoft.com.au (8.13.5/8.13.4) with ESMTP id l042FSuQ093992 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 4 Jan 2007 12:45:28 +1030 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: freebsd-stable@freebsd.org Date: Thu, 4 Jan 2007 12:45:23 +1030 User-Agent: KMail/1.9.4 References: <200701021518.52231.doconnor@gsoft.com.au> In-Reply-To: <200701021518.52231.doconnor@gsoft.com.au> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1621194.FAf6GWvh0M"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200701041245.24593.doconnor@gsoft.com.au> X-Spam-Score: -1.36 () ALL_TRUSTED X-Scanned-By: MIMEDefang 2.57 on 203.31.81.10 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: twe on amd64 hangs 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, 04 Jan 2007 02:15:31 -0000 --nextPart1621194.FAf6GWvh0M Content-Type: multipart/mixed; boundary="Boundary-01=_8MGnFA+sFGf+NkD" Content-Transfer-Encoding: 7bit Content-Disposition: inline --Boundary-01=_8MGnFA+sFGf+NkD Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Tuesday 02 January 2007 15:18, Daniel O'Connor wrote: > Hi, > We have recently bought some new Supermicro P8SCT boards with 3ware > 8006LP2's and are using the amd64 port, however if I put the 3ware in the > PCI-X slot it hangs probing the disks (eg at the end of the boot if it's = in > the kernel, or at load time if I use kldload). If I put it in a 32 bit sl= ot > it works fine. > > I tried reducing the PCI-X clock down to 100MHz but it made no difference. > > If I boot an i386 kernel it works fine (I tried 6.2RC2). > > Unfortunately the hang is solid and I can't break into the debugger :( I just put an Adaptec 29160 card in it (which is a 64 bit PCI card) and it= =20 also hangs if I put it in the PCI-X slot, it works fine in a PCI32 slot. (I= =20 haven't tried booting i386 to see if it works there though) I have also tried the latest BIOS with the fail-safe defaults set - no chan= ge. I have grabbed a slab of info from DDB over Firewire (plus NMI switch :) wh= ich=20 is attached. =2D-=20 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 --Boundary-01=_8MGnFA+sFGf+NkD-- --nextPart1621194.FAf6GWvh0M Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQBFnGM85ZPcIHs/zowRAugsAJ9BeyuZnijUr21syIGpZISg8aF6/ACfTREz L2yE+p9c8ecUTE3atbb5zp4= =uQUA -----END PGP SIGNATURE----- --nextPart1621194.FAf6GWvh0M-- From owner-freebsd-stable@FreeBSD.ORG Wed Jan 3 21:33:57 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org 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 B3EBA16A47C for ; Wed, 3 Jan 2007 21:33:57 +0000 (UTC) (envelope-from r00t_0101@yahoo.com) Received: from web32710.mail.mud.yahoo.com (web32710.mail.mud.yahoo.com [68.142.207.254]) by mx1.freebsd.org (Postfix) with SMTP id 5C0E113C457 for ; Wed, 3 Jan 2007 21:33:57 +0000 (UTC) (envelope-from r00t_0101@yahoo.com) Received: (qmail 17656 invoked by uid 60001); 3 Jan 2007 21:07:16 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=sdg3nAt+uOor1YSWm/I0rpreHpUsuLKeb0LZX9zmNzHUnvxgtTdXE2ju9aSFz6Wjn+ATokdY3dI1DPkakyswQIYQSu+nVfdUdZ1u/8RxYAiwnPUnb4b3zyqkJgYdV51j0whiN3KgW+IDCfGFfW4krSAEcUyCpbwiQtwSgvyRFJU=; X-YMail-OSG: o1t2WooVM1kxIqChgwZxXdrfnqyCgiPSpMBtDylGCwuqoYeqJzc6pcA3L3SW5wMqJbubWE44dndPRUWqJeChNRxGLD3FrcunEFho3nXZjFg3oQCFJ39CWc.ZPA7WSoaRSVNydfgSg3GF_w-- Received: from [63.144.132.78] by web32710.mail.mud.yahoo.com via HTTP; Wed, 03 Jan 2007 13:07:16 PST Date: Wed, 3 Jan 2007 13:07:16 -0800 (PST) From: r00t_0101 To: freebsd-stable@freebsd.org In-Reply-To: <20070103120043.3A90A16A604@hub.freebsd.org> MIME-Version: 1.0 Message-ID: <438465.16988.qm@web32710.mail.mud.yahoo.com> X-Mailman-Approved-At: Thu, 04 Jan 2007 06:09:58 +0000 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: win32-codecs question ... 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, 03 Jan 2007 21:33:57 -0000 Folks, I was wondering if the win32-codecs will be available when the final 6.2 is released? Currently I am using the 6.1 release and unable to use many of the multimedia packages that depend on this specific port. Would anyone know if there's a way of manually installing these codecs or maybe use another package that has these binaries? Thanks -r00t_0101 __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From owner-freebsd-stable@FreeBSD.ORG Thu Jan 4 06:41:50 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org 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 C533B16A403 for ; Thu, 4 Jan 2007 06:41:50 +0000 (UTC) (envelope-from aline@riseup.net) Received: from mx1.riseup.net (mx1.riseup.net [204.13.164.34]) by mx1.freebsd.org (Postfix) with ESMTP id 9B47913C458 for ; Thu, 4 Jan 2007 06:41:50 +0000 (UTC) (envelope-from aline@riseup.net) Received: from tern.riseup.net (unknown [10.0.1.12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "tern.riseup.net", Issuer "CA Cert Signing Authority" (verified OK)) by mx1.riseup.net (Postfix) with ESMTP id 8E80257179D for ; Wed, 3 Jan 2007 22:22:02 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by tern.riseup.net (Postfix) with ESMTP id 380C814C0EC for ; Wed, 3 Jan 2007 22:22:02 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at tern.riseup.net Received: from tern.riseup.net ([127.0.0.1]) by localhost (tern.riseup.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SUUgccfszdVk for ; Wed, 3 Jan 2007 22:22:01 -0800 (PST) Received: by tern.riseup.net (Postfix, from userid 33) id A783514C11D; Wed, 3 Jan 2007 22:22:01 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by aline@tern.riseup.net (Horde MIME library) with HTTP; Thu, 04 Jan 2007 04:22:01 -0200 Message-ID: <20070104042201.9qjsp2ad28o4w8ks@tern.riseup.net> Date: Thu, 04 Jan 2007 04:22:01 -0200 From: Aline de Freitas To: freebsd-stable@freebsd.org References: <438465.16988.qm@web32710.mail.mud.yahoo.com> In-Reply-To: <438465.16988.qm@web32710.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=_40670zyriuck"; protocol="application/pgp-signature"; micalg="pgp-sha1" Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.1.3) X-Spam-Status: No, score=-1.0 required=8.0 tests=BAYES_00,UNPARSEABLE_RELAY, URIBL_SBL autolearn=no version=3.1.7 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on spamd1 Subject: Re: win32-codecs question ... 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, 04 Jan 2007 06:41:50 -0000 This message is in MIME format and has been PGP signed. --=_40670zyriuck Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Citando r00t_0101 : > Folks, > I was wondering if the win32-codecs will be available when the =20 > final 6.2 is released? Currently I am using the 6.1 release and =20 > unable to use many of the multimedia packages that depend on this =20 > specific port. Would anyone know if there's a way of manually =20 > installing these codecs or maybe use another package that has these =20 > binaries? > > Thanks > -r00t_0101 But no one sayd that you can't use the package... Just do this: rm /var/db/ports/win32-codecs and portinstall win32-codecs or cd /usr/ports/multimedia/win32-codecs; make install clean And DON'T select quicktime in the menu. Aline > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com > _______________________________________________ > 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" > --=20 Aline de Freitas - Chave p=FAblica: ID DE632016 / keys.indymedia.org gpg --keyserver keys.indymedia.org --recv-keys DE632016 --=_40670zyriuck Content-Type: application/pgp-signature Content-Description: Assinatura Digital PGP Content-Disposition: inline Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQBFnJ0JhLRvs95jIBYRAoaNAJ47y5GHLVgPKaMc0FviPkipa0h44gCeOFai pugaivLWx/qyMvzUTGjzoy4= =iiZX -----END PGP SIGNATURE----- --=_40670zyriuck-- From owner-freebsd-stable@FreeBSD.ORG Thu Jan 4 07:38:11 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org 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 2C21116A415 for ; Thu, 4 Jan 2007 07:38:11 +0000 (UTC) (envelope-from dsyphers@u.washington.edu) Received: from mxout7.cac.washington.edu (mxout7.cac.washington.edu [140.142.32.178]) by mx1.freebsd.org (Postfix) with ESMTP id E0BBF13C455 for ; Thu, 4 Jan 2007 07:38:10 +0000 (UTC) (envelope-from dsyphers@u.washington.edu) Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.141] (may be forged)) by mxout7.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW06.09) with ESMTP id l047cAXQ012309 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 3 Jan 2007 23:38:10 -0800 X-Auth-Received: from [192.168.1.10] (c-24-19-52-201.hsd1.wa.comcast.net [24.19.52.201]) (authenticated authid=dsyphers) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW06.09) with ESMTP id l047c85V012965 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 3 Jan 2007 23:38:09 -0800 From: David Syphers To: freebsd-stable@freebsd.org Date: Wed, 3 Jan 2007 23:38:44 -0800 User-Agent: KMail/1.9.4 References: <438465.16988.qm@web32710.mail.mud.yahoo.com> In-Reply-To: <438465.16988.qm@web32710.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200701032338.44752.dsyphers@u.washington.edu> X-PMX-Version: 5.2.2.285561, Antispam-Engine: 2.5.0.283055, Antispam-Data: 2007.1.3.231932 X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CD 0, __CT 0, __CTE 0, __CTYPE_CHARSET_QUOTED 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __USER_AGENT 0' Cc: r00t_0101 Subject: Re: win32-codecs question ... 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, 04 Jan 2007 07:38:11 -0000 On Wednesday 03 January 2007 13:07, r00t_0101 wrote: > Folks, > I was wondering if the win32-codecs will be available when the final 6.2 > is released? Currently I am using the 6.1 release and unable to use many of > the multimedia packages that depend on this specific port. Would anyone > know if there's a way of manually installing these codecs or maybe use > another package that has these binaries? You can hack the Makefile in /usr/ports/multimedia/win32-codecs/. Just change line 56 to something that's always false (I used '.if defined(NARBLE_WITH_QUICKTIME)'). This is clearly an ugly hack and probably not at all recommended, but it works. -David -- Everyone who believes in telekinesis, raise my hand. From owner-freebsd-stable@FreeBSD.ORG Thu Jan 4 09:08:16 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org 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 BB19416A412 for ; Thu, 4 Jan 2007 09:08:16 +0000 (UTC) (envelope-from jacardenasm@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.185]) by mx1.freebsd.org (Postfix) with ESMTP id 566E713C45E for ; Thu, 4 Jan 2007 09:08:16 +0000 (UTC) (envelope-from jacardenasm@gmail.com) Received: by nf-out-0910.google.com with SMTP id x37so7445438nfc for ; Thu, 04 Jan 2007 01:08:15 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Vny7aImEODteradGHdDM5pz47Z+rxuMYdi6vBXPywVBk6RXJT4dxpWiNefZjD8w3RKs6ychV1bzE3fvhIJg5yvu6htayWdP6hW/9Fl69KDYP408ybPb8bPHUXr+81WkXueZ1KRyiCuho8ExoeRI9lnaZD4bi2QUpdRuEXrN6sls= Received: by 10.49.29.2 with SMTP id g2mr6284700nfj.1167900055188; Thu, 04 Jan 2007 00:40:55 -0800 (PST) Received: by 10.49.18.6 with HTTP; Thu, 4 Jan 2007 00:40:55 -0800 (PST) Message-ID: <7c58fcfc0701040040w4c76096ej9edd28a7ef193681@mail.gmail.com> Date: Thu, 4 Jan 2007 03:40:55 -0500 From: "Jose Alonso Cardenas Marquez" To: "David Syphers" In-Reply-To: <200701032338.44752.dsyphers@u.washington.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <438465.16988.qm@web32710.mail.mud.yahoo.com> <200701032338.44752.dsyphers@u.washington.edu> Cc: r00t_0101 , freebsd-stable@freebsd.org Subject: Re: win32-codecs question ... 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, 04 Jan 2007 09:08:16 -0000 2007/1/4, David Syphers : > On Wednesday 03 January 2007 13:07, r00t_0101 wrote: > > Folks, > > I was wondering if the win32-codecs will be available when the final 6.2 > > is released? Currently I am using the 6.1 release and unable to use many of > > the multimedia packages that depend on this specific port. Would anyone > > know if there's a way of manually installing these codecs or maybe use > > another package that has these binaries? > > You can hack the Makefile in /usr/ports/multimedia/win32-codecs/. Just change > line 56 to something that's always false (I used '.if > defined(NARBLE_WITH_QUICKTIME)'). This is clearly an ugly hack and probably > not at all recommended, but it works. > > -David > > -- hi David :) why do you not use "make config" in multimedia/win32-codecs and you not select the QUICKTIME option? Greetings From owner-freebsd-stable@FreeBSD.ORG Thu Jan 4 13:04:30 2007 Return-Path: X-Original-To: stable@freebsd.org 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 F131F16A47E for ; Thu, 4 Jan 2007 13:04:30 +0000 (UTC) (envelope-from wjw@withagen.nl) Received: from mail.digiware.nl (www.tegenbosch28.nl [217.21.251.97]) by mx1.freebsd.org (Postfix) with ESMTP id A791813C46A for ; Thu, 4 Jan 2007 13:04:28 +0000 (UTC) (envelope-from wjw@withagen.nl) Received: from [212.61.27.67] (opteron.digiware.nl [212.61.27.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.digiware.nl (Postfix) with ESMTP id D9E7A1707D; Thu, 4 Jan 2007 14:04:21 +0100 (CET) Message-ID: <459CFBCE.804@withagen.nl> Date: Thu, 04 Jan 2007 14:06:22 +0100 From: Willem Jan Withagen User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: LI Xin References: <459ABB40.7050603@digiware.nl> <459BAE28.5070300@delphij.net> In-Reply-To: <459BAE28.5070300@delphij.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: stable@freebsd.org, Willem Jan Withagen Subject: Re: running mksnap_ffs 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, 04 Jan 2007 13:04:31 -0000 LI Xin wrote: > Willem Jan Withagen wrote: >> Hi, >> >> I got the following Filesystem: >> Filesystem Size Used Avail Capacity iused ifree %iused >> /dev/da0a 1.3T 422G 823G 34% 565952 182833470 0% >> >> Running of a 3ware 9550, on a dual core Opteron 242 with 1Gb. >> The system is used as SMB/NFS server for my other systems here. >> >> I would like to make weekly snapshots, but manually running mksnap_ffs >> freezes access to the disk (I sort of expected that) but the process >> never terminates. So I let is sit overnight, but looking a gstat did not >> reveil any activity what so ever... >> The disk was not released, mksnap_ffs could not be terminated. >> And things resulted in me rebooting the system. >> >> So: >> - How long should I expect making a snapshot to take: >> 5, 15, 30min, 1, 2 hour or even more??? > > This depends how much cylinder groups do you have. If you have a lot of > large files, using "newfs -b 32768" instead of the default settings > would speed up the process drastically. Note that this might be > unfeasable because you already have data on the disk. Well the disk is loaded with very different types of files.... It is my home file server and contains 10 years of Email in Mailbox/ format, al types of development work, my complete ripped CD collection (and more), next to that I've started to see how I can networkstream my DvD collection. So it depends on what you call a large file. :) > Another suggestion is to separate the volume into smaller slices, this > would reduce the impact. I always seem to make the wrong sizes, run out of space, and start to symlink. Which drives me completely crazy. So this time I went for one big slice, but makeing backups now starts to become a serious point of attention. :~} > BTW. Our experience with a semi full 1.3T volume is that the snapshot > would take about 1 hour on FreeBSD 5.x, but I doubt that it is not > really comparable to your situation as the hardware is very different. Can you give me an idea of what type of HW you're running. So I can guestimate from there on. This means that you don't have access to the volume for about 1 hour? >> - How do I diagnose the reason why it is not terminating? > > This might be somewhat complicated. Check out the developers' handbook. Done that, but mucking on a system that important makes me hesitate. Although not being able to make backups nerves me too. --WjW From owner-freebsd-stable@FreeBSD.ORG Thu Jan 4 16:25:38 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org 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 F223516A416 for ; Thu, 4 Jan 2007 16:25:38 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id DEBC113C442 for ; Thu, 4 Jan 2007 16:25:38 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (elvis.mu.org [192.203.228.196]) by elvis.mu.org (Postfix) with ESMTP id BF5D31A4D8E; Thu, 4 Jan 2007 08:25:38 -0800 (PST) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 1C2485218F; Thu, 4 Jan 2007 11:25:38 -0500 (EST) Date: Thu, 4 Jan 2007 11:25:38 -0500 From: Kris Kennaway To: Martin Sch?tte Message-ID: <20070104162537.GA10454@xor.obsecurity.org> References: <20061219073943.W74584@polaris.astro.ufl.edu> <20061227035530.GC9859@xor.obsecurity.org> <459BB587.7060007@mschuette.name> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="SUOF0GtieIMvvwua" Content-Disposition: inline In-Reply-To: <459BB587.7060007@mschuette.name> User-Agent: Mutt/1.4.2.2i Cc: freebsd-stable@freebsd.org Subject: Re: "swap_pager" loop? 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, 04 Jan 2007 16:25:39 -0000 --SUOF0GtieIMvvwua Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jan 03, 2007 at 02:54:15PM +0100, Martin Sch?tte wrote: > Kris Kennaway schrieb: > >>The machine has 4gb of ram, a 4gb swap partition on /dev/amrd0s1b, and > >>provides nfs/nis/samba/printing (cups) services. >=20 > I have the same problem with FreeBSD 6.1-RELEASE on my SMP-System=20 > (2xAthlon MP) with an asr-RAID (Adaptec 2110S). > The disks are OK (complete read with 'dd if=3D/dev/da...' showed no error= s). >=20 > The deadlocks often occured during backups, so I suspect a race=20 > condition or too many interrupts to be the cause. That does not sound like the same problem then, since the OP didn't see deadlocks. Please follow up your issue separately (including a full debugging backtrace, etc). Kris --SUOF0GtieIMvvwua Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFFnSqBWry0BWjoQKURAg3OAJ9cCVFGg4X2GYwBvOTRl4nVVWmE7wCg5U+o 9y374O3sTfrKQz27HB7auaM= =zbv9 -----END PGP SIGNATURE----- --SUOF0GtieIMvvwua-- From owner-freebsd-stable@FreeBSD.ORG Thu Jan 4 16:49:40 2007 Return-Path: X-Original-To: freebsd-stable@FreeBSD.ORG 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 F380216A403 for ; Thu, 4 Jan 2007 16:49:39 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [83.120.8.8]) by mx1.freebsd.org (Postfix) with ESMTP id E71DF13C467 for ; Thu, 4 Jan 2007 16:49:38 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (evuhup@localhost [127.0.0.1]) by lurza.secnetix.de (8.13.4/8.13.4) with ESMTP id l04GnU5a064483; Thu, 4 Jan 2007 17:49:36 +0100 (CET) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.13.4/8.13.1/Submit) id l04GnTiM064482; Thu, 4 Jan 2007 17:49:29 +0100 (CET) (envelope-from olli) Date: Thu, 4 Jan 2007 17:49:29 +0100 (CET) Message-Id: <200701041649.l04GnTiM064482@lurza.secnetix.de> From: Oliver Fromme To: freebsd-stable@FreeBSD.ORG, jacardenasm@gmail.com In-Reply-To: <7c58fcfc0701040040w4c76096ej9edd28a7ef193681@mail.gmail.com> X-Newsgroups: list.freebsd-stable User-Agent: tin/1.8.2-20060425 ("Shillay") (UNIX) (FreeBSD/4.11-STABLE (i386)) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Thu, 04 Jan 2007 17:49:36 +0100 (CET) Cc: Subject: Re: win32-codecs question ... X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-stable@FreeBSD.ORG, jacardenasm@gmail.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jan 2007 16:49:40 -0000 Jose Alonso Cardenas Marquez wrote: > why do you not use "make config" in multimedia/win32-codecs and you > not select the QUICKTIME option? What if you actually have to be able to view quicktime .mov files? (Well, mplayer seems to have some native support for certain older quicktime versions, but that doesn't work for me, unfortunately.) Best regards Oliver PS: I solved the problem by installing an old version of the port. Of course I'm aware of the security implications, but I don't play .mov files from untrusted sources, so I'm not worried. -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. Python is executable pseudocode. Perl is executable line noise. From owner-freebsd-stable@FreeBSD.ORG Thu Jan 4 21:27:14 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org 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 983BF16A407 for ; Thu, 4 Jan 2007 21:27:14 +0000 (UTC) (envelope-from dsyphers@u.washington.edu) Received: from mxout7.cac.washington.edu (mxout7.cac.washington.edu [140.142.32.178]) by mx1.freebsd.org (Postfix) with ESMTP id 776A013C43E for ; Thu, 4 Jan 2007 21:27:14 +0000 (UTC) (envelope-from dsyphers@u.washington.edu) Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout7.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW06.09) with ESMTP id l04LRDUp012103 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 4 Jan 2007 13:27:14 -0800 X-Auth-Received: from [192.168.1.10] (c-24-19-52-201.hsd1.wa.comcast.net [24.19.52.201]) (authenticated authid=dsyphers) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW06.09) with ESMTP id l04LRChk008605 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 4 Jan 2007 13:27:13 -0800 From: David Syphers To: freebsd-stable@freebsd.org Date: Thu, 4 Jan 2007 13:27:51 -0800 User-Agent: KMail/1.9.4 References: <438465.16988.qm@web32710.mail.mud.yahoo.com> <200701032338.44752.dsyphers@u.washington.edu> <7c58fcfc0701040040w4c76096ej9edd28a7ef193681@mail.gmail.com> In-Reply-To: <7c58fcfc0701040040w4c76096ej9edd28a7ef193681@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200701041327.52134.dsyphers@u.washington.edu> X-PMX-Version: 5.2.2.285561, Antispam-Engine: 2.5.0.283055, Antispam-Data: 2007.1.4.130933 X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CD 0, __CT 0, __CTE 0, __CTYPE_CHARSET_QUOTED 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __USER_AGENT 0' Cc: Jose Alonso Cardenas Marquez Subject: Re: win32-codecs question ... 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, 04 Jan 2007 21:27:14 -0000 On Thursday 04 January 2007 00:40, Jose Alonso Cardenas Marquez wrote: > why do you not use "make config" in multimedia/win32-codecs and you > not select the QUICKTIME option? Largely because I'd never heard of 'make config'. Thanks for enlightening me. But... configurations like that are supposed to pop up under a normal 'make', aren't they? And most ports work on a system like 'make WITHOUT_QUICKTIME=yes' or similar. In any case, like Oliver Fromme, I'm aware of the security issues and may want to use it with Quicktime anyway. -David -- Everyone who believes in telekinesis, raise my hand. From owner-freebsd-stable@FreeBSD.ORG Thu Jan 4 21:39:44 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org 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 CE1C716A416 for ; Thu, 4 Jan 2007 21:39:44 +0000 (UTC) (envelope-from fcash@ocis.net) Received: from smtp.sd73.bc.ca (smtp.sd73.bc.ca [142.24.13.140]) by mx1.freebsd.org (Postfix) with ESMTP id B11A613C448 for ; Thu, 4 Jan 2007 21:39:44 +0000 (UTC) (envelope-from fcash@ocis.net) Received: from localhost (localhost [127.0.0.1]) by localhost.sd73.bc.ca (Postfix) with ESMTP id E91651A0007B8 for ; Thu, 4 Jan 2007 13:39:43 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at smtp.sd73.bc.ca Received: from smtp.sd73.bc.ca ([127.0.0.1]) by localhost (smtp.sd73.bc.ca [127.0.0.1]) (amavisd-new, port 10024) with LMTP id ZIlMbPayEk36 for ; Thu, 4 Jan 2007 13:39:37 -0800 (PST) Received: from s10.sbo (s10.sbo [192.168.0.10]) by smtp.sd73.bc.ca (Postfix) with ESMTP id 17C531A0007AC for ; Thu, 4 Jan 2007 13:39:37 -0800 (PST) From: Freddie Cash To: freebsd-stable@freebsd.org Date: Thu, 4 Jan 2007 13:39:35 -0800 User-Agent: KMail/1.9.5 References: <438465.16988.qm@web32710.mail.mud.yahoo.com> <7c58fcfc0701040040w4c76096ej9edd28a7ef193681@mail.gmail.com> <200701041327.52134.dsyphers@u.washington.edu> In-Reply-To: <200701041327.52134.dsyphers@u.washington.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200701041339.36221.fcash@ocis.net> Subject: Re: win32-codecs question ... 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, 04 Jan 2007 21:39:44 -0000 On Thursday 04 January 2007 01:27 pm, David Syphers wrote: > On Thursday 04 January 2007 00:40, Jose Alonso Cardenas Marquez wrote: > > why do you not use "make config" in multimedia/win32-codecs and you > > not select the QUICKTIME option? > Largely because I'd never heard of 'make config'. Thanks for > enlightening me. But... configurations like that are supposed to pop up > under a normal 'make', aren't they? If a port supports the OPTION framework, then the first time you run make it will pop up the blue screen where you select the options you want. These are saved in a text file called /var/db/ports//options. You can view saved options using "make showconfig". You can delete the saved options using "make rmconfig". And you can bring up the options screen at anytime using "make config". This is all nicely documented in the ports(7) man page. :) And there were a bunch of head's ups on the -ports mailing list back when this first hit the ports tree. I believe there's also a blurb about this in the handbook. And a mention of it in /usr/ports/UPDATING and/or /usr/ports/CHANGES. > And most ports work on a system > like 'make > WITHOUT_QUICKTIME=yes' or similar. Most ports use the OPTIONS framework, and more are being converted over to it all the time. Eventually, hopefully, all ports will use the OPTIONS framework, although there will always be a few items that can't be squeezed into OPTIONS that will require a -DWITH_BLAH or WITH_BLAH=whatever. -- Freddie Cash fcash@ocis.net From owner-freebsd-stable@FreeBSD.ORG Thu Jan 4 22:06:18 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org 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 A57E416A415 for ; Thu, 4 Jan 2007 22:06:18 +0000 (UTC) (envelope-from swhetzel@gmail.com) Received: from nz-out-0506.google.com (nz-out-0506.google.com [64.233.162.237]) by mx1.freebsd.org (Postfix) with ESMTP id 6B6BE13C467 for ; Thu, 4 Jan 2007 22:06:18 +0000 (UTC) (envelope-from swhetzel@gmail.com) Received: by nz-out-0506.google.com with SMTP id i11so3051044nzh for ; Thu, 04 Jan 2007 14:06:17 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=dIJtxuDDq9+ekFIEJ+IimJEfA3Vl/vHLb9GbEYCwBKa55ztlIxFp2cbqhVRjZlodrs1hpRKJh6Q+D6tNQiisB4wfgam0MvRxYzcbTNZHrh3Gu8kzP4x+avslHVIm6tGlyOPQuZ4irC16aaCwaGMfqigQu4Md/GMqMtsD2y4QuQQ= Received: by 10.65.154.10 with SMTP id g10mr14848257qbo.1167948377822; Thu, 04 Jan 2007 14:06:17 -0800 (PST) Received: by 10.65.61.1 with HTTP; Thu, 4 Jan 2007 14:06:17 -0800 (PST) Message-ID: <790a9fff0701041406x7d038294xe2e140f2182b02a8@mail.gmail.com> Date: Thu, 4 Jan 2007 16:06:17 -0600 From: "Scot Hetzel" To: "David Syphers" In-Reply-To: <200701041327.52134.dsyphers@u.washington.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <438465.16988.qm@web32710.mail.mud.yahoo.com> <200701032338.44752.dsyphers@u.washington.edu> <7c58fcfc0701040040w4c76096ej9edd28a7ef193681@mail.gmail.com> <200701041327.52134.dsyphers@u.washington.edu> Cc: freebsd-stable@freebsd.org Subject: Re: win32-codecs question ... 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, 04 Jan 2007 22:06:18 -0000 On 1/4/07, David Syphers wrote: > On Thursday 04 January 2007 00:40, Jose Alonso Cardenas Marquez wrote: > > why do you not use "make config" in multimedia/win32-codecs and you > > not select the QUICKTIME option? > > Largely because I'd never heard of 'make config'. Thanks for enlightening me. > But... configurations like that are supposed to pop up under a normal 'make', > aren't they? And most ports work on a system like 'make > WITHOUT_QUICKTIME=yes' or similar. > The options menu only appears the first time you build the port. Then the next time you build the port, if the /var/db/ports//options file exists, it won't show the options menu again. The only way to override these options is to use 'make config' or 'make rmconfig'. 'make rmconfig' removes the options file, so the next time you build the port, the options menus will appear. To see the current settings: make showconfig Ports that use the options menu don't allow you to use 'make WITHOUT_QUICKTIME=yes' or entries in /etc/make.conf to override the options. Scot -- DISCLAIMER: No electrons were mamed while sending this message. Only slightly bruised. From owner-freebsd-stable@FreeBSD.ORG Thu Jan 4 23:33:15 2007 Return-Path: X-Original-To: stable@FreeBSD.org 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 454F316A407; Thu, 4 Jan 2007 23:33:15 +0000 (UTC) (envelope-from marck@rinet.ru) Received: from woozle.rinet.ru (woozle.rinet.ru [195.54.192.68]) by mx1.freebsd.org (Postfix) with ESMTP id 4C55B13C458; Thu, 4 Jan 2007 23:33:14 +0000 (UTC) (envelope-from marck@rinet.ru) Received: from localhost (localhost [127.0.0.1]) by woozle.rinet.ru (8.13.8/8.13.8) with ESMTP id l04NFXgp033507; Fri, 5 Jan 2007 02:15:33 +0300 (MSK) (envelope-from marck@rinet.ru) Date: Fri, 5 Jan 2007 02:15:33 +0300 (MSK) From: Dmitry Morozovsky To: sos@FreeBSD.org Message-ID: <20070105015404.M32468@woozle.rinet.ru> X-NCC-RegID: ru.rinet X-OpenPGP-Key-ID: 6B691B03 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (woozle.rinet.ru [0.0.0.0]); Fri, 05 Jan 2007 02:15:33 +0300 (MSK) Cc: stable@FreeBSD.org Subject: on the fly attach detection SATA troubles 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, 04 Jan 2007 23:33:15 -0000 Dear Soeren, RELENG_6_2 on TYAN Tomcat K8E (S2865) motherboard with onboard NVidia SATA controller: atapci1: port 0x9f0-0x9f7,0xbf0-0xbf3,0x970-0x977,0xb70-0xb73,0xd400-0xd40f mem 0xfebfc000-0xfebfcfff irq 23 at device 7.0 on pci0 atapci1: Reserved 0x10 bytes for rid 0x20 type 4 at 0xd400 atapci1: [MPSAFE] atapci1: Reserved 0x1000 bytes for rid 0x24 type 3 at 0xfebfc000 ata2: on atapci1 atapci1: Reserved 0x8 bytes for rid 0x10 type 4 at 0x9f0 atapci1: Reserved 0x4 bytes for rid 0x14 type 4 at 0xbf0 ata2: SATA connect ready time=0ms ata2: sata_connect devices=0x1 ata2: [MPSAFE] ata3: on atapci1 atapci1: Reserved 0x8 bytes for rid 0x18 type 4 at 0x970 atapci1: Reserved 0x4 bytes for rid 0x1c type 4 at 0xb70 ata3: SATA connect ready time=0ms ata3: sata_connect devices=0x1 ata3: [MPSAFE] ata4: on atapci2 ata4: SATA connect ready time=0ms ata4: sata_connect devices=0x1 ata4: [MPSAFE] ata5: on atapci2 ata5: SATA connect ready time=0ms ata5: sata_connect devices=0x1 ata5: [MPSAFE] ata2-master: pio=PIO4 wdma=WDMA2 udma=UDMA133 cable=40 wire ad4: 476940MB at ata2-master SATA300 ata3-master: pio=PIO4 wdma=WDMA2 udma=UDMA133 cable=40 wire ad6: 476940MB at ata3-master SATA300 ata4-master: pio=PIO4 wdma=WDMA2 udma=UDMA133 cable=40 wire ad8: 476940MB at ata4-master SATA300 ata5-master: pio=PIO4 wdma=WDMA2 udma=UDMA133 cable=40 wire ad10: 476940MB at ata5-master SATA300 When connecting/dictonnecting SATA drive (I tried ad8 and ad10) on the fly I've got Jan 4 22:30:41 ogre kernel: ata5: CONNECTED Jan 4 22:30:41 ogre kernel: ata5: SATA connect ready time=10000ms Jan 4 22:30:41 ogre kernel: ata5: sata_connect devices=0x0 Jan 4 22:31:13 ogre kernel: ata5: SATA connect ready time=10000ms Jan 4 22:31:13 ogre kernel: ata5: sata_connect devices=0x0 Jan 4 22:31:13 ogre kernel: ata5: [MPSAFE] Jan 4 22:31:30 ogre kernel: ad8: detached Jan 4 22:32:02 ogre kernel: ata4: SATA connect ready time=10000ms Jan 4 22:32:02 ogre kernel: ata4: sata_connect devices=0x0 Jan 4 22:32:02 ogre kernel: ata4: [MPSAFE] and the drive(s) is not detected. atacontrol detach/attach or atacontrol reinit does not help either. When booting with the drive connected everything's detected fine. Is it normal? Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------ From owner-freebsd-stable@FreeBSD.ORG Fri Jan 5 00:38:11 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org 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 C254A16A4D0 for ; Fri, 5 Jan 2007 00:38:11 +0000 (UTC) (envelope-from itetcu@FreeBSD.org) Received: from it.buh.tecnik93.com (it.buh.tecnik93.com [81.196.204.98]) by mx1.freebsd.org (Postfix) with ESMTP id 7FF4B13C469 for ; Fri, 5 Jan 2007 00:38:11 +0000 (UTC) (envelope-from itetcu@FreeBSD.org) Received: from it.buh.tecnik93.com (localhost [127.0.0.1]) by it.buh.tecnik93.com (Postfix) with ESMTP id 90EC717123; Fri, 5 Jan 2007 02:09:29 +0200 (EET) Date: Fri, 5 Jan 2007 02:09:29 +0200 From: Ion-Mihai "IOnut" Tetcu To: "Craig St. Jean" Message-ID: <20070105020929.7c261c97@it.buh.tecnik93.com> In-Reply-To: <1a5509630612301353i4a731008o44eb1c5bd332335e@mail.gmail.com> References: <1a5509630612301353i4a731008o44eb1c5bd332335e@mail.gmail.com> X-Mailer: Claws Mail 2.6.1 (GTK+ 2.10.6; i386-portbld-freebsd6.2) Mime-Version: 1.0 Content-Type: multipart/signed; boundary="Sig_eF8MP=pHF8Xniw/UQQPCC42"; protocol="application/pgp-signature"; micalg=PGP-SHA1 Cc: freebsd-stable@freebsd.org Subject: Re: make buildkernel erroring on latest sources 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, 05 Jan 2007 00:38:11 -0000 --Sig_eF8MP=pHF8Xniw/UQQPCC42 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Sat, 30 Dec 2006 16:53:48 -0500 "Craig St. Jean" wrote: > Updated my sources to STABLE today, and followed the handbook as I > normally do to make sure I don't forget anything, however on `make > buildkernel KERNCONF=3DGENERIC` I got the following: >=20 > ... > MAKE=3Dmake sh /usr/src/sys/conf/newvers.sh GENERIC > cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls > -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes > -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=3Dc99 > -nostdinc -I- -I. -I/usr/src/sys -I/usr/src/sys/contrib/altq > -I/usr/src/sys/contrib/ipfilter -I/usr/src/sys/contrib/pf > -I/usr/src/sys/dev/ath -I/usr/src/sys/contrib/ngatm > -I/usr/src/sys/dev/twa -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS > -include opt_global.h -fno-common -finline-limit=3D8000 --param > inline-unit-growth=3D100 --param large-function-growth=3D1000 > -mno-align-long-strings -mpreferred-stack-boundary=3D2 -mno-mmx > -mno-3dnow -mno-sse -mno-sse2 -ffreestanding -Werror vers.c > linking kernel > if_ural.o(.text+0x66): In function `ural_free_tx_list': > : undefined reference to `ieee80211_free_node' If you build with NO_CLEAN and friends drop it, If that doesn't solve it remove /usr/obj/* (or at lest the dir for if_ural). --=20 IOnut - Un^d^dregistered ;) FreeBSD "user" "Intellectual Property" is nowhere near as valuable as "Intellect" BOFH excuse #18: excess surge protection --Sig_eF8MP=pHF8Xniw/UQQPCC42 Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFFnZc5BX6fi0k6KXsRAvQYAJ9PvRp+LxboKhxhuTAJ27WCA+wQsgCaA9ZO 6lVlaRrhhddG1mIFGr278lg= =oLKY -----END PGP SIGNATURE----- --Sig_eF8MP=pHF8Xniw/UQQPCC42-- From owner-freebsd-stable@FreeBSD.ORG Fri Jan 5 05:28:21 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org 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 9CC5316A403 for ; Fri, 5 Jan 2007 05:28:21 +0000 (UTC) (envelope-from dsyphers@u.washington.edu) Received: from mxout1.cac.washington.edu (mxout1.cac.washington.edu [140.142.32.134]) by mx1.freebsd.org (Postfix) with ESMTP id 7C91013C44B for ; Fri, 5 Jan 2007 05:28:21 +0000 (UTC) (envelope-from dsyphers@u.washington.edu) Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9] (may be forged)) by mxout1.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW06.09) with ESMTP id l055SKHo003027 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 4 Jan 2007 21:28:21 -0800 X-Auth-Received: from [192.168.1.10] (c-24-19-52-201.hsd1.wa.comcast.net [24.19.52.201]) (authenticated authid=dsyphers) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW06.09) with ESMTP id l055SKiJ008687 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 4 Jan 2007 21:28:20 -0800 From: David Syphers To: freebsd-stable@freebsd.org Date: Thu, 4 Jan 2007 21:28:59 -0800 User-Agent: KMail/1.9.4 References: <438465.16988.qm@web32710.mail.mud.yahoo.com> <200701041327.52134.dsyphers@u.washington.edu> <200701041339.36221.fcash@ocis.net> In-Reply-To: <200701041339.36221.fcash@ocis.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200701042129.00139.dsyphers@u.washington.edu> X-PMX-Version: 5.2.2.285561, Antispam-Engine: 2.5.0.283055, Antispam-Data: 2007.1.4.211436 X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CD 0, __CP_NAME_BODY 0, __CT 0, __CTE 0, __CTYPE_CHARSET_QUOTED 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __USER_AGENT 0' Cc: Subject: Re: win32-codecs question ... 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, 05 Jan 2007 05:28:21 -0000 On Thursday 04 January 2007 13:39, Freddie Cash wrote: > If a port supports the OPTION framework, then the first time you run make ... > > This is all nicely documented in the ports(7) man page. Where I wouldn't think to look unless I knew something had changed, or something failed to build with a "look at ports(7)" error. > And there were a bunch of head's ups on the -ports mailing list Which I don't read... I don't think I was subscribed to this even back when I read -current, -cvs-all, -hackers, -ipfw, -mobile, -questions, -security, and -stable. > I believe there's also a blurb about this in the handbook. I haven't read the handbook on ports since the 1990's. I'm just a poster child for all that the doc people hate, aren't I? :) > And a mention of it in /usr/ports/UPDATING > and/or /usr/ports/CHANGES. Now, this I read. And no, it's not documented there. The only mentions in UPDATING are under postfix entries, and I don't use postfix. The entries in CHANGES wouldn't catch your eye unless you knew what you were looking for - everything assumes prior knowledge of what OPTIONS is and what it implies. Nonetheless, I am now enlightened. And I feel like an old fogey even though I'm not even 30 :) -David -- Everyone who believes in telekinesis, raise my hand. From owner-freebsd-stable@FreeBSD.ORG Fri Jan 5 09:52:42 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org 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 4787616A417 for ; Fri, 5 Jan 2007 09:52:42 +0000 (UTC) (envelope-from pokui@psg.com) Received: from mail.trueafrican.com (mail.trueafrican.com [212.88.98.117]) by mx1.freebsd.org (Postfix) with ESMTP id DE3E213C474 for ; Fri, 5 Jan 2007 09:52:40 +0000 (UTC) (envelope-from pokui@psg.com) X-Virus-Scanned: by amavisd-new at trueafrican.com Received: from mail.trueafrican.com ([127.0.0.1]) by localhost (mail.trueafrican.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7TZQIgocdmBx for ; Fri, 5 Jan 2007 12:50:41 +0300 (EAT) Received: from pjo.trueafrican.com (pokui.trueafrican.com [169.254.0.7]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.trueafrican.com (Postfix) with ESMTP id E3A40269FA6 for ; Fri, 5 Jan 2007 12:50:39 +0300 (EAT) Received: from [127.0.0.1] (helo=andromeda.trueafrican.com) by pjo.trueafrican.com with esmtp (Exim 4.62) (envelope-from ) id 1H2lkK-0004Y5-DP; Fri, 05 Jan 2007 12:52:20 +0300 From: Patrick Okui To: freebsd-stable@freebsd.org Date: Fri, 5 Jan 2007 12:52:17 +0300 User-Agent: KMail/1.8 References: <438465.16988.qm@web32710.mail.mud.yahoo.com> <200701041327.52134.dsyphers@u.washington.edu> <200701041339.36221.fcash@ocis.net> In-Reply-To: <200701041339.36221.fcash@ocis.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200701051252.18102.pokui@psg.com> Cc: Subject: Re: win32-codecs question ... 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, 05 Jan 2007 09:52:42 -0000 On Friday 05 January 2007 00:39, Freddie Cash wrote: > This is all nicely documented in the ports(7) man page. ahh.. didn't even know there was one. I found out about make config (as well as showconfig and rmconfig and ...) by reading Mk/bsd.ports.mk -- patrick From owner-freebsd-stable@FreeBSD.ORG Fri Jan 5 11:31:27 2007 Return-Path: X-Original-To: stable@FreeBSD.org 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 11C5B16A403 for ; Fri, 5 Jan 2007 11:31:27 +0000 (UTC) (envelope-from ceri@submonkey.net) Received: from shrike.submonkey.net (cpc2-cdif2-0-0-cust107.cdif.cable.ntl.com [81.104.168.108]) by mx1.freebsd.org (Postfix) with ESMTP id 729D413C44B for ; Fri, 5 Jan 2007 11:31:26 +0000 (UTC) (envelope-from ceri@submonkey.net) Received: from ceri by shrike.submonkey.net with local (Exim 4.64 (FreeBSD)) (envelope-from ) id 1H2n75-0004wz-4e; Fri, 05 Jan 2007 11:19:55 +0000 Date: Fri, 5 Jan 2007 11:19:55 +0000 From: Ceri Davies To: stable@FreeBSD.org Message-ID: <20070105111954.GA51511@submonkey.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="xHFwDpU9dbj6ez1V" Content-Disposition: inline X-PGP: finger ceri@FreeBSD.org User-Agent: Mutt/1.5.13 (2006-08-11) Sender: Ceri Davies Cc: rwatson@FreeBSD.org Subject: (audit?) Panic in 6.2-PRERELEASE 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, 05 Jan 2007 11:31:27 -0000 --xHFwDpU9dbj6ez1V Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable For the last two mornings, my system decided to panic() in the exact same place. I have dumps from both but they almost exactly the same. Any pointers on where to go next are welcomed. Here's the first, and I don't see much in there: {root@shrike}-{~} # uname -a FreeBSD shrike.private.submonkey.net 6.2-PRERELEASE FreeBSD 6.2-PRERELEASE = #69: Fri Dec 29 00:25:52 GMT 2006 root@shrike.private.submonkey.net:/us= r/obj/usr/src/sys/SHRIKE i386 {root@shrike}-{~} # kgdb /usr/obj/usr/src/sys/SHRIKE/kernel.debug /var/cras= h/vmcore.29 kgdb: kvm_nlist(_stopped_cpus):=20 kgdb: kvm_nlist(_stoppcbs):=20 [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so:= Undefined symbol "ps_pglobal_lookup"] GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain condition= s. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd". Unread portion of the kernel message buffer: Fatal trap 12: page fault while in kernel mode fault virtual address =3D 0x53892047 fault code =3D supervisor write, page not present instruction pointer =3D 0x20:0xc05cda7c stack pointer =3D 0x28:0xd610dc48 frame pointer =3D 0x28:0xd610dc60 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 65381 (imapd) trap number =3D 12 panic: page fault Uptime: 5d19h44m40s Dumping 503 MB (2 chunks) chunk 0: 1MB (160 pages) ... ok chunk 1: 503MB (128752 pages) 487 471 455 439 423 407 391 375 359 343 327= 311 295 279 263 247 231 215 199 183 167 151 135 119 103 87 71 55 39 23 7 #0 doadump () at pcpu.h:165 165 pcpu.h: No such file or directory. in pcpu.h (kgdb) where #0 doadump () at pcpu.h:165 #1 0xc04e85aa in boot (howto=3D260) at /usr/src/sys/kern/kern_shutdown.c:4= 09 #2 0xc04e8840 in panic (fmt=3D0xc066f61a "%s") at /usr/src/sys/kern/kern_s= hutdown.c:565 #3 0xc0653ed4 in trap_fatal (frame=3D0xd610dc08, eva=3D1401495623) at /usr/src/sys/i386/i386/trap.c:837 #4 0xc0653c3b in trap_pfault (frame=3D0xd610dc08, usermode=3D0, eva=3D1401= 495623) at /usr/src/sys/i386/i386/trap.c:745 #5 0xc0653899 in trap (frame=3D {tf_fs =3D 8, tf_es =3D 40, tf_ds =3D 40, tf_edi =3D -1024544384, tf_= esi =3D -1024544384, tf_ebp =3D -703538080, tf_isp =3D -703538124, tf_ebx = =3D 0, tf_edx =3D -703538092, tf_ecx =3D 4, tf_eax =3D 0, tf_trapno =3D 12,= tf_err =3D 2, tf_eip =3D -1067656580, tf_cs =3D 32, tf_eflags =3D 66050, t= f_esp =3D -1068742797, tf_ss =3D -1022955520}) at /usr/src/sys/i386/i386/tr= ap.c:435 #6 0xc064287a in calltrap () at /usr/src/sys/i386/i386/exception.s:139 #7 0xc05cda7c in audit_arg_auditon () at /usr/src/sys/security/audit/audit= _arg.c:586 #8 0xc04c470d in fstat (td=3D0xc2eeb180, uap=3D0xd610dc74) at /usr/src/sys= /kern/kern_descrip.c:1075 #9 0xc0654203 in syscall (frame=3D {tf_fs =3D 59, tf_es =3D 59, tf_ds =3D 59, tf_edi =3D -1077949408, tf= _esi =3D 135666752, tf_ebp =3D -1077949448, tf_isp =3D -703537820, tf_ebx = =3D 135432156, tf_edx =3D -1077949112, tf_ecx =3D 135826416, tf_eax =3D 189= , tf_trapno =3D 0, tf_err =3D 2, tf_eip =3D 675755895, tf_cs =3D 51, tf_efl= ags =3D 662, tf_esp =3D -1077949732, tf_ss =3D 59}) at /usr/src/sys/i386/i3= 86/trap.c:983 #10 0xc06428cf in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s= :200 #11 0x00000033 in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) up 8 #8 0xc04c470d in fstat (td=3D0xc2eeb180, uap=3D0xd610dc74) at /usr/src/sys= /kern/kern_descrip.c:1075 1075 error =3D kern_fstat(td, uap->fd, &ub); (kgdb) p ub $1 =3D {st_dev =3D 89, st_ino =3D 1907905, st_mode =3D 33152, st_nlink =3D = 1, st_uid =3D 60, st_gid =3D 60,=20 st_rdev =3D 7624272, st_atimespec =3D {tv_sec =3D 1167893059, tv_nsec =3D= -703537996}, st_mtimespec =3D { tv_sec =3D -703537916, tv_nsec =3D -1024544384}, st_ctimespec =3D {tv_s= ec =3D 43018, tv_nsec =3D 43018},=20 st_size =3D -3021672509244264064, st_blocks =3D -1067658896, st_blksize = =3D 43018, st_flags =3D 4,=20 st_gen =3D 3, st_lspare =3D 0, st_birthtimespec =3D {tv_sec =3D -1, tv_ns= ec =3D 4}} (kgdb) p td $2 =3D (struct thread *) 0xc2eeb180 (kgdb) p uap->fd $3 =3D 89 (kgdb) The second one seems more promising, in that the fd seems to be rubbish. {root@shrike}-{~} # kgdb /usr/obj/usr/src/sys/SHRIKE/kernel.debug /var/cras= h/vmcore.30 kgdb: kvm_nlist(_stopped_cpus):=20 kgdb: kvm_nlist(_stoppcbs):=20 [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so:= Undefined symbol "ps_pglobal_lookup"] GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain condition= s. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd". Unread portion of the kernel message buffer: Fatal trap 12: page fault while in kernel mode fault virtual address =3D 0x53892047 fault code =3D supervisor write, page not present instruction pointer =3D 0x20:0xc05cda7c stack pointer =3D 0x28:0xd617ec48 frame pointer =3D 0x28:0xd617ec60 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 9943 (imapd) trap number =3D 12 panic: page fault Uptime: 22h39m3s Dumping 503 MB (2 chunks) chunk 0: 1MB (160 pages) ... ok chunk 1: 503MB (128752 pages) 487 471 455 439 423 407 391 375 359 343 327= 311 295 279 263 247 231 215 199 183 167 151 135 119 103 87 71 55 39 23 7 #0 doadump () at pcpu.h:165 165 pcpu.h: No such file or directory. in pcpu.h (kgdb) where #0 doadump () at pcpu.h:165 #1 0xc04e85aa in boot (howto=3D260) at /usr/src/sys/kern/kern_shutdown.c:4= 09 #2 0xc04e8840 in panic (fmt=3D0xc066f61a "%s") at /usr/src/sys/kern/kern_s= hutdown.c:565 #3 0xc0653ed4 in trap_fatal (frame=3D0xd617ec08, eva=3D1401495623) at /usr/src/sys/i386/i386/trap.c:837 #4 0xc0653c3b in trap_pfault (frame=3D0xd617ec08, usermode=3D0, eva=3D1401= 495623) at /usr/src/sys/i386/i386/trap.c:745 #5 0xc0653899 in trap (frame=3D {tf_fs =3D 8, tf_es =3D 40, tf_ds =3D 40, tf_edi =3D -1022323968, tf_= esi =3D -1022323968, tf_ebp =3D -703075232, tf_isp =3D -703075276, tf_ebx = =3D 0, tf_edx =3D -703075244, tf_ecx =3D 4, tf_eax =3D 0, tf_trapno =3D 12,= tf_err =3D 2, tf_eip =3D -1067656580, tf_cs =3D 32, tf_eflags =3D 66050, t= f_esp =3D -1068742797, tf_ss =3D -1022327760}) at /usr/src/sys/i386/i386/tr= ap.c:435 #6 0xc064287a in calltrap () at /usr/src/sys/i386/i386/exception.s:139 #7 0xc05cda7c in audit_arg_auditon () at /usr/src/sys/security/audit/audit= _arg.c:586 #8 0xc04c470d in fstat (td=3D0xc3109300, uap=3D0xd617ec74) at /usr/src/sys= /kern/kern_descrip.c:1075 #9 0xc0654203 in syscall (frame=3D {tf_fs =3D 59, tf_es =3D 59, tf_ds =3D 59, tf_edi =3D 135488384, tf_e= si =3D -1077948560, tf_ebp =3D -1077948888, tf_isp =3D -703074972, tf_ebx = =3D 135432156, tf_edx =3D -1077948712, tf_ecx =3D 25, tf_eax =3D 189, tf_tr= apno =3D 0, tf_err =3D 2, tf_eip =3D 675755895, tf_cs =3D 51, tf_eflags =3D= 662, tf_esp =3D -1077949124, tf_ss =3D 59}) at /usr/src/sys/i386/i386/trap= =2Ec:983 #10 0xc06428cf in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s= :200 #11 0x00000033 in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) up 8 #8 0xc04c470d in fstat (td=3D0xc3109300, uap=3D0xd617ec74) at /usr/src/sys= /kern/kern_descrip.c:1075 1075 error =3D kern_fstat(td, uap->fd, &ub); (kgdb) p uap->fd $1 =3D -1023449232 (kgdb)=20 Ceri --=20 That must be wonderful! I don't understand it at all. -- Moliere --xHFwDpU9dbj6ez1V Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFFnjRaocfcwTS3JF8RAks0AKCtTVVI95FO06d7M5OuK1pNMn2XLQCgjNMO bHB45pHbhSA0CRUBFYXH3vg= =TaBm -----END PGP SIGNATURE----- --xHFwDpU9dbj6ez1V-- From owner-freebsd-stable@FreeBSD.ORG Fri Jan 5 11:49:22 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org 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 18ED516A416 for ; Fri, 5 Jan 2007 11:49:22 +0000 (UTC) (envelope-from 05056409@students.lincoln.ac.uk) Received: from atreides.lincoln.ac.uk (mailhub.lincoln.ac.uk [194.80.59.181]) by mx1.freebsd.org (Postfix) with ESMTP id A59A013C465 for ; Fri, 5 Jan 2007 11:49:21 +0000 (UTC) (envelope-from 05056409@students.lincoln.ac.uk) Received: from aexcmb01.network.uni ([194.80.57.1]) by atreides.lincoln.ac.uk with esmtp (Exim 4.63) (envelope-from <05056409@students.lincoln.ac.uk>) id 1H2nZV-0000EO-Ug; Fri, 05 Jan 2007 11:49:20 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 5 Jan 2007 11:48:03 -0000 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Page Fault in 6.2-PRE RELEASE Thread-Index: AccuucezfG/rY9onQYiBG2zvNAvH6ACBZP0G References: <20070102212503.GC1603@roadrunner.q.local> From: "Christopher Harper \(05056409\)" <05056409@students.lincoln.ac.uk> To: "Ulrich Spoerlein" X-AntiVirus-Scanner: Virus checked by atreides.lincoln.ac.uk using Sophie and Sophos AV X-SA-Exim-Connect-IP: 194.80.57.1 X-SA-Exim-Mail-From: 05056409@students.lincoln.ac.uk X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on atreides.lincoln.ac.uk X-Spam-Level: ** X-Spam-Status: No, score=2.6 required=9.0 tests=ALL_TRUSTED, AWL, FROM_ALL_NUMS, FROM_STARTS_WITH_NUMS,TW_EB,TW_TX autolearn=no version=3.1.7 X-SA-Exim-Version: 4.2.1 (built Sun, 22 Oct 2006 09:17:32 +0100) X-SA-Exim-Scanned: Yes (on atreides.lincoln.ac.uk) Cc: freebsd-stable@freebsd.org Subject: RE: Page Fault in 6.2-PRE RELEASE 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, 05 Jan 2007 11:49:22 -0000 Thank you for your help , Ill keep my eye on this and just use a = crossover cable for the time being. ---------------------------------- Christopher Harper (05056409) wrote: > The system freezes randomly and no longer accepts any input and after = a minute of being 'frozen' reboots. > (kgdb) backtrace > #0 doadump () at pcpu.h:165 > #1 0xc051a6ca in boot (howto=3D260) at = /usr/src/sys/kern/kern_shutdown.c:409 > #2 0xc051a9f1 in panic (fmt=3D0xc06d94cf "%s") at = /usr/src/sys/kern/kern_shutdown.c:565 > #3 0xc06a795c in trap_fatal (frame=3D0xe6dc6bac, eva=3D4) at = /usr/src/sys/i386/i386/trap.c:837 > #4 0xc06a769b in trap_pfault (frame=3D0xe6dc6bac, usermode=3D0, = eva=3D4) at /usr/src/sys/i386/i386/trap.c:745 > #5 0xc06a72d5 in trap (frame=3D > {tf_fs =3D 8, tf_es =3D -963641304, tf_ds =3D -961019864, tf_edi = =3D -963964928, tf_esi =3D 0, tf_ebp =3D -421762056, tf_isp =3D = -421762088, tf_ebx =3D -963961644, tf_edx =3D -421655072, tf_ecx =3D = -964085760, tf_eax =3D 0, tf_trapno =3D 12, tf_err =3D 0, tf_eip =3D = -1067808807, tf_cs =3D 32, tf_eflags =3D 66118, tf_esp =3D -963961644, = tf_ss =3D -963615744}) > at /usr/src/sys/i386/i386/trap.c:435 > #6 0xc069342a in calltrap () at = /usr/src/sys/i386/i386/exception.s:139 > #7 0xc05a87d9 in ieee80211_free_node (ni=3D0x0) at = /usr/src/sys/net80211/ieee80211_node.c:1605 > #8 0xc04b1923 in ural_txeof (xfer=3D0xc6b82d00, priv=3D0xc68b1cd4, = status=3DUSBD_NORMAL_COMPLETION) at /usr/src/sys/dev/usb/if_ural.c:888 > #9 0xc04c9b1a in usb_transfer_complete (xfer=3D0xc6b82d00) at = /usr/src/sys/dev/usb/usbdi.c:863 > #10 0xc04acbae in ehci_idone (ex=3D0xc6b82d00) at = /usr/src/sys/dev/usb/ehci.c:852 > #11 0xc04acaeb in ehci_check_intr (sc=3D0xc6893800, ex=3D0xc6b82d00) = at /usr/src/sys/dev/usb/ehci.c:759 > #12 0xc04aca25 in ehci_softintr (v=3D0xc6893800) at = /usr/src/sys/dev/usb/ehci.c:693 > #13 0xc04c6e55 in usb_schedsoftintr (bus=3D0x0) at = /usr/src/sys/dev/usb/usb.c:871 > #14 0xc04ac806 in ehci_intr1 (sc=3D0xc6893800) at = /usr/src/sys/dev/usb/ehci.c:593 > #15 0xc04ac746 in ehci_intr (v=3D0xc6893800) at = /usr/src/sys/dev/usb/ehci.c:552 > #16 0xc0505059 in ithread_execute_handlers (p=3D0xc68ff648, = ie=3D0xc67e3b00) at /usr/src/sys/kern/kern_intr.c:682 > #17 0xc0505169 in ithread_loop (arg=3D0xc68b7480) at = /usr/src/sys/kern/kern_intr.c:765 > #18 0xc0503e0d in fork_exit (callout=3D0xc0505114 , = arg=3D0xc68b7480, frame=3D0xe6dc6d38) at = /usr/src/sys/kern/kern_fork.c:821 > #19 0xc069348c in fork_trampoline () at = /usr/src/sys/i386/i386/exception.s:208 This is the same as kern/92083 [1] I could suggest, that you try with the new USB stack by Hans-Petter Selasky. But there is a different bug in his ural(4), that makes it unusable too. http://www.freebsd.org/cgi/query-pr.cgi?pr=3Dkern/92083 Ulrich Spoerlein --=20 A: Yes. >Q: Are you sure? > >A: Because it reverses the logical flow of conversation. > >>Q: Why is top posting frowned upon? From owner-freebsd-stable@FreeBSD.ORG Fri Jan 5 12:13:33 2007 Return-Path: X-Original-To: stable@FreeBSD.org 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 92DE716A407 for ; Fri, 5 Jan 2007 12:13:33 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id 0BFAF13C458 for ; Fri, 5 Jan 2007 12:13:30 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id A75A348822; Fri, 5 Jan 2007 07:13:30 -0500 (EST) Date: Fri, 5 Jan 2007 12:13:30 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Ceri Davies In-Reply-To: <20070105111954.GA51511@submonkey.net> Message-ID: <20070105120539.H46119@fledge.watson.org> References: <20070105111954.GA51511@submonkey.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: stable@FreeBSD.org Subject: Re: (audit?) Panic in 6.2-PRERELEASE 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, 05 Jan 2007 12:13:33 -0000 On Fri, 5 Jan 2007, Ceri Davies wrote: > For the last two mornings, my system decided to panic() in the exact same > place. I have dumps from both but they almost exactly the same. Any > pointers on where to go next are welcomed. > > Here's the first, and I don't see much in there: In principle, kern_fstat() should not call audit_arg_auditon(), so either we're looking at a compile problem or at stack corruption. Am I correct in thinking that this is running on a cyrus server? Much as I would love to trust the contents of ub there, I suspect they can't be trusted. Could you print the contents of *fp in kern_fstat() in both of those stacks? I'd particularly like to know the value of fp->f_type, and then depending on the type, possibly the contents of *(struct vnode *)fp->f_vnode for DTYPE_VNODE/TYPE_FIFO or *(struct socket *)fp->f_data in the case of DTYPE_SOCKET. Thanks, Robert N M Watson Computer Laboratory University of Cambridge > > {root@shrike}-{~} # uname -a > FreeBSD shrike.private.submonkey.net 6.2-PRERELEASE FreeBSD 6.2-PRERELEASE #69: Fri Dec 29 00:25:52 GMT 2006 root@shrike.private.submonkey.net:/usr/obj/usr/src/sys/SHRIKE i386 > {root@shrike}-{~} # kgdb /usr/obj/usr/src/sys/SHRIKE/kernel.debug /var/crash/vmcore.29 > kgdb: kvm_nlist(_stopped_cpus): > kgdb: kvm_nlist(_stoppcbs): > [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so: Undefined symbol "ps_pglobal_lookup"] > GNU gdb 6.1.1 [FreeBSD] > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you are > welcome to change it and/or distribute copies of it under certain conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for details. > This GDB was configured as "i386-marcel-freebsd". > > Unread portion of the kernel message buffer: > > > Fatal trap 12: page fault while in kernel mode > fault virtual address = 0x53892047 > fault code = supervisor write, page not present > instruction pointer = 0x20:0xc05cda7c > stack pointer = 0x28:0xd610dc48 > frame pointer = 0x28:0xd610dc60 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 65381 (imapd) > trap number = 12 > panic: page fault > Uptime: 5d19h44m40s > Dumping 503 MB (2 chunks) > chunk 0: 1MB (160 pages) ... ok > chunk 1: 503MB (128752 pages) 487 471 455 439 423 407 391 375 359 343 327 311 295 279 263 247 231 215 199 183 167 151 135 119 103 87 71 55 39 23 7 > > #0 doadump () at pcpu.h:165 > 165 pcpu.h: No such file or directory. > in pcpu.h > (kgdb) where > #0 doadump () at pcpu.h:165 > #1 0xc04e85aa in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409 > #2 0xc04e8840 in panic (fmt=0xc066f61a "%s") at /usr/src/sys/kern/kern_shutdown.c:565 > #3 0xc0653ed4 in trap_fatal (frame=0xd610dc08, eva=1401495623) > at /usr/src/sys/i386/i386/trap.c:837 > #4 0xc0653c3b in trap_pfault (frame=0xd610dc08, usermode=0, eva=1401495623) > at /usr/src/sys/i386/i386/trap.c:745 > #5 0xc0653899 in trap (frame= > {tf_fs = 8, tf_es = 40, tf_ds = 40, tf_edi = -1024544384, tf_esi = -1024544384, tf_ebp = -703538080, tf_isp = -703538124, tf_ebx = 0, tf_edx = -703538092, tf_ecx = 4, tf_eax = 0, tf_trapno = 12, tf_err = 2, tf_eip = -1067656580, tf_cs = 32, tf_eflags = 66050, tf_esp = -1068742797, tf_ss = -1022955520}) at /usr/src/sys/i386/i386/trap.c:435 > #6 0xc064287a in calltrap () at /usr/src/sys/i386/i386/exception.s:139 > #7 0xc05cda7c in audit_arg_auditon () at /usr/src/sys/security/audit/audit_arg.c:586 > #8 0xc04c470d in fstat (td=0xc2eeb180, uap=0xd610dc74) at /usr/src/sys/kern/kern_descrip.c:1075 > #9 0xc0654203 in syscall (frame= > {tf_fs = 59, tf_es = 59, tf_ds = 59, tf_edi = -1077949408, tf_esi = 135666752, tf_ebp = -1077949448, tf_isp = -703537820, tf_ebx = 135432156, tf_edx = -1077949112, tf_ecx = 135826416, tf_eax = 189, tf_trapno = 0, tf_err = 2, tf_eip = 675755895, tf_cs = 51, tf_eflags = 662, tf_esp = -1077949732, tf_ss = 59}) at /usr/src/sys/i386/i386/trap.c:983 > #10 0xc06428cf in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:200 > #11 0x00000033 in ?? () > Previous frame inner to this frame (corrupt stack?) > (kgdb) up 8 > #8 0xc04c470d in fstat (td=0xc2eeb180, uap=0xd610dc74) at /usr/src/sys/kern/kern_descrip.c:1075 > 1075 error = kern_fstat(td, uap->fd, &ub); > (kgdb) p ub > $1 = {st_dev = 89, st_ino = 1907905, st_mode = 33152, st_nlink = 1, st_uid = 60, st_gid = 60, > st_rdev = 7624272, st_atimespec = {tv_sec = 1167893059, tv_nsec = -703537996}, st_mtimespec = { > tv_sec = -703537916, tv_nsec = -1024544384}, st_ctimespec = {tv_sec = 43018, tv_nsec = 43018}, > st_size = -3021672509244264064, st_blocks = -1067658896, st_blksize = 43018, st_flags = 4, > st_gen = 3, st_lspare = 0, st_birthtimespec = {tv_sec = -1, tv_nsec = 4}} > (kgdb) p td > $2 = (struct thread *) 0xc2eeb180 > (kgdb) p uap->fd > $3 = 89 > (kgdb) > > The second one seems more promising, in that the fd seems to be rubbish. > > {root@shrike}-{~} # kgdb /usr/obj/usr/src/sys/SHRIKE/kernel.debug /var/crash/vmcore.30 > kgdb: kvm_nlist(_stopped_cpus): > kgdb: kvm_nlist(_stoppcbs): > [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so: Undefined symbol "ps_pglobal_lookup"] > GNU gdb 6.1.1 [FreeBSD] > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you are > welcome to change it and/or distribute copies of it under certain conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for details. > This GDB was configured as "i386-marcel-freebsd". > > Unread portion of the kernel message buffer: > > > Fatal trap 12: page fault while in kernel mode > fault virtual address = 0x53892047 > fault code = supervisor write, page not present > instruction pointer = 0x20:0xc05cda7c > stack pointer = 0x28:0xd617ec48 > frame pointer = 0x28:0xd617ec60 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 9943 (imapd) > trap number = 12 > panic: page fault > Uptime: 22h39m3s > Dumping 503 MB (2 chunks) > chunk 0: 1MB (160 pages) ... ok > chunk 1: 503MB (128752 pages) 487 471 455 439 423 407 391 375 359 343 327 311 295 279 263 247 231 215 199 183 167 151 135 119 103 87 71 55 39 23 7 > > #0 doadump () at pcpu.h:165 > 165 pcpu.h: No such file or directory. > in pcpu.h > (kgdb) where > #0 doadump () at pcpu.h:165 > #1 0xc04e85aa in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409 > #2 0xc04e8840 in panic (fmt=0xc066f61a "%s") at /usr/src/sys/kern/kern_shutdown.c:565 > #3 0xc0653ed4 in trap_fatal (frame=0xd617ec08, eva=1401495623) > at /usr/src/sys/i386/i386/trap.c:837 > #4 0xc0653c3b in trap_pfault (frame=0xd617ec08, usermode=0, eva=1401495623) > at /usr/src/sys/i386/i386/trap.c:745 > #5 0xc0653899 in trap (frame= > {tf_fs = 8, tf_es = 40, tf_ds = 40, tf_edi = -1022323968, tf_esi = -1022323968, tf_ebp = -703075232, tf_isp = -703075276, tf_ebx = 0, tf_edx = -703075244, tf_ecx = 4, tf_eax = 0, tf_trapno = 12, tf_err = 2, tf_eip = -1067656580, tf_cs = 32, tf_eflags = 66050, tf_esp = -1068742797, tf_ss = -1022327760}) at /usr/src/sys/i386/i386/trap.c:435 > #6 0xc064287a in calltrap () at /usr/src/sys/i386/i386/exception.s:139 > #7 0xc05cda7c in audit_arg_auditon () at /usr/src/sys/security/audit/audit_arg.c:586 > #8 0xc04c470d in fstat (td=0xc3109300, uap=0xd617ec74) at /usr/src/sys/kern/kern_descrip.c:1075 > #9 0xc0654203 in syscall (frame= > {tf_fs = 59, tf_es = 59, tf_ds = 59, tf_edi = 135488384, tf_esi = -1077948560, tf_ebp = -1077948888, tf_isp = -703074972, tf_ebx = 135432156, tf_edx = -1077948712, tf_ecx = 25, tf_eax = 189, tf_trapno = 0, tf_err = 2, tf_eip = 675755895, tf_cs = 51, tf_eflags = 662, tf_esp = -1077949124, tf_ss = 59}) at /usr/src/sys/i386/i386/trap.c:983 > #10 0xc06428cf in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:200 > #11 0x00000033 in ?? () > Previous frame inner to this frame (corrupt stack?) > (kgdb) up 8 > #8 0xc04c470d in fstat (td=0xc3109300, uap=0xd617ec74) at /usr/src/sys/kern/kern_descrip.c:1075 > 1075 error = kern_fstat(td, uap->fd, &ub); > (kgdb) p uap->fd > $1 = -1023449232 > (kgdb) > > Ceri > -- > That must be wonderful! I don't understand it at all. > -- Moliere > From owner-freebsd-stable@FreeBSD.ORG Fri Jan 5 13:15:33 2007 Return-Path: X-Original-To: stable@FreeBSD.org 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 152A216A412; Fri, 5 Jan 2007 13:15:33 +0000 (UTC) (envelope-from ceri@submonkey.net) Received: from shrike.submonkey.net (cpc2-cdif2-0-0-cust107.cdif.cable.ntl.com [81.104.168.108]) by mx1.freebsd.org (Postfix) with ESMTP id AB0A913C45D; Fri, 5 Jan 2007 13:15:32 +0000 (UTC) (envelope-from ceri@submonkey.net) Received: from ceri by shrike.submonkey.net with local (Exim 4.64 (FreeBSD)) (envelope-from ) id 1H2ouu-000Dz4-GH; Fri, 05 Jan 2007 13:15:28 +0000 Date: Fri, 5 Jan 2007 13:15:28 +0000 From: Ceri Davies To: Robert Watson Message-ID: <20070105131528.GB7088@submonkey.net> References: <20070105111954.GA51511@submonkey.net> <20070105120539.H46119@fledge.watson.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="AqsLC8rIMeq19msA" Content-Disposition: inline In-Reply-To: <20070105120539.H46119@fledge.watson.org> X-PGP: finger ceri@FreeBSD.org User-Agent: Mutt/1.5.13 (2006-08-11) Sender: Ceri Davies Cc: stable@FreeBSD.org Subject: Re: (audit?) Panic in 6.2-PRERELEASE 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, 05 Jan 2007 13:15:33 -0000 --AqsLC8rIMeq19msA Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jan 05, 2007 at 12:13:30PM +0000, Robert Watson wrote: > On Fri, 5 Jan 2007, Ceri Davies wrote: >=20 > >For the last two mornings, my system decided to panic() in the exact sam= e=20 > >place. I have dumps from both but they almost exactly the same. Any=20 > >pointers on where to go next are welcomed. > > > >Here's the first, and I don't see much in there: >=20 > In principle, kern_fstat() should not call audit_arg_auditon(), so either= =20 > we're looking at a compile problem or at stack corruption. Am I correct = in=20 > thinking that this is running on a cyrus server? Correct. > Much as I would love to=20 > trust the contents of ub there, I suspect they can't be trusted. Could y= ou=20 > print the contents of *fp in kern_fstat() in both of those stacks? I'd= =20 > particularly like to know the value of fp->f_type, and then depending on= =20 > the type, possibly the contents of *(struct vnode *)fp->f_vnode for=20 > DTYPE_VNODE/TYPE_FIFO or *(struct socket *)fp->f_data in the case of=20 > DTYPE_SOCKET. Can you tell me how to get at *fp given that the stack trace shows fstat() and not kern_fstat()? Sorry if I'm being dumb but I don't know how to step into the kern_fstat() call from fstat(). > >#7 0xc05cda7c in audit_arg_auditon () at /usr/src/sys/security/audit/au= dit_arg.c:586 > >#8 0xc04c470d in fstat (td=3D0xc2eeb180, uap=3D0xd610dc74) at /usr/src/= sys/kern/kern_descrip.c:1075 Ceri --=20 That must be wonderful! I don't understand it at all. -- Moliere --AqsLC8rIMeq19msA Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFFnk9wocfcwTS3JF8RAhWfAJ9ARadsmsIULy/Xt5ccMoD5d0wZ4wCfeAcP 0dXwrJs78cBhH2rXc7VVEwg= =Jl7z -----END PGP SIGNATURE----- --AqsLC8rIMeq19msA-- From owner-freebsd-stable@FreeBSD.ORG Fri Jan 5 13:34:05 2007 Return-Path: X-Original-To: stable@FreeBSD.org 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 E7B9F16A407 for ; Fri, 5 Jan 2007 13:34:05 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id 767C613C467 for ; Fri, 5 Jan 2007 13:34:05 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 7E434476EF; Fri, 5 Jan 2007 08:34:04 -0500 (EST) Date: Fri, 5 Jan 2007 13:34:04 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Ceri Davies In-Reply-To: <20070105131528.GB7088@submonkey.net> Message-ID: <20070105133028.F98541@fledge.watson.org> References: <20070105111954.GA51511@submonkey.net> <20070105120539.H46119@fledge.watson.org> <20070105131528.GB7088@submonkey.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: stable@FreeBSD.org Subject: Re: (audit?) Panic in 6.2-PRERELEASE 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, 05 Jan 2007 13:34:06 -0000 On Fri, 5 Jan 2007, Ceri Davies wrote: >> Much as I would love to trust the contents of ub there, I suspect they >> can't be trusted. Could you print the contents of *fp in kern_fstat() in >> both of those stacks? I'd particularly like to know the value of >> fp->f_type, and then depending on the type, possibly the contents of >> *(struct vnode *)fp->f_vnode for DTYPE_VNODE/TYPE_FIFO or *(struct socket >> *)fp->f_data in the case of DTYPE_SOCKET. > > Can you tell me how to get at *fp given that the stack trace shows fstat() > and not kern_fstat()? Sorry if I'm being dumb but I don't know how to step > into the kern_fstat() call from fstat(). It could be that the stack is hosed losing the frame, or maybe it's inlined (more likely the former I think, as kern_fstat() is a symbol used elsewhere in the kernel). The best bet may be to use the file descriptor number (uap->fd) to pull the struct file reference out of the process. Something on the order of (td->td_proc->p_fd->fd_ofiles[fd]) should return the right struct file *. How reproduceable is this? Robert N M Watson Computer Laboratory University of Cambridge > >>> #7 0xc05cda7c in audit_arg_auditon () at /usr/src/sys/security/audit/audit_arg.c:586 >>> #8 0xc04c470d in fstat (td=0xc2eeb180, uap=0xd610dc74) at /usr/src/sys/kern/kern_descrip.c:1075 > > Ceri > -- > That must be wonderful! I don't understand it at all. > -- Moliere > From owner-freebsd-stable@FreeBSD.ORG Fri Jan 5 14:55:12 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org 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 61D7C16A417 for ; Fri, 5 Jan 2007 14:55:12 +0000 (UTC) (envelope-from HellerK@gsicommerce.com) Received: from relay.globalsportsinc.com (relay.globalsportsinc.com [208.247.73.130]) by mx1.freebsd.org (Postfix) with ESMTP id 11D8F13C471 for ; Fri, 5 Jan 2007 14:55:11 +0000 (UTC) (envelope-from HellerK@gsicommerce.com) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 5 Jan 2007 09:43:09 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Firewire card not recognized. Thread-Index: Accw19FbGI9+oR+6Rb27LFeJt3laUw== From: "Karl Heller" To: Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Firewire card not recognized. 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, 05 Jan 2007 14:55:12 -0000 With Firewire support enabled in i386 6.0 release and 6.1 release I can't seem to get my card to be recognized or at least have devices show up that are attached to it. =20 The FW card is a Belkin F5U503 with TI TSB43AB23. =20 The boot shows: at device 3.0 (no driver attached)" =20 Here is the relevant steps I've taken to diagnose this.. =20 # kldload /boot/kernel/firewire.ko kldload: can't load /boot/kernel/firewire.ko: File exists=20 I assume that is because I statically link it into the kernel. # fwcontrol fwcontrol: open: No such file or directory # ls /dev/fw* ls: /dev/fw*: No such file or directory In my kernel.conf: # FireWire support device firewire # FireWire bus code device sbp # SCSI over FireWire (Requires scbus and da) device fwe # Ethernet over FireWire (non-standard!) # kldstat -v |grep -i fire 55 fwohci/firewire 58 firewire/fwe 59 firewire/sbp lspci -lv =20 none6@pci1:3:0: class=3D0x0c0000 card=3D0x00000000 chip=3D0x8024004c = rev=3D0x00 hdr=3D0x00 class =3D serial bus subclass =3D FireWire What am I missing? What does it mean "no driver attached"? The man pages say that specific TI chip is supported, is this card not recognized? =20 Thanks, =20 Karl =20 From owner-freebsd-stable@FreeBSD.ORG Fri Jan 5 15:09:09 2007 Return-Path: X-Original-To: stable@FreeBSD.org 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 A65AE16A403; Fri, 5 Jan 2007 15:09:09 +0000 (UTC) (envelope-from ceri@submonkey.net) Received: from shrike.submonkey.net (cpc2-cdif2-0-0-cust107.cdif.cable.ntl.com [81.104.168.108]) by mx1.freebsd.org (Postfix) with ESMTP id EE5FD13C478; Fri, 5 Jan 2007 15:09:08 +0000 (UTC) (envelope-from ceri@submonkey.net) Received: from ceri by shrike.submonkey.net with local (Exim 4.64 (FreeBSD)) (envelope-from ) id 1H2qgj-000JmE-OU; Fri, 05 Jan 2007 15:08:57 +0000 Date: Fri, 5 Jan 2007 15:08:57 +0000 From: Ceri Davies To: Robert Watson Message-ID: <20070105150857.GC7088@submonkey.net> References: <20070105111954.GA51511@submonkey.net> <20070105120539.H46119@fledge.watson.org> <20070105131528.GB7088@submonkey.net> <20070105133028.F98541@fledge.watson.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="NKoe5XOeduwbEQHU" Content-Disposition: inline In-Reply-To: <20070105133028.F98541@fledge.watson.org> X-PGP: finger ceri@FreeBSD.org User-Agent: Mutt/1.5.13 (2006-08-11) Sender: Ceri Davies Cc: stable@FreeBSD.org Subject: Re: (audit?) Panic in 6.2-PRERELEASE 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, 05 Jan 2007 15:09:09 -0000 --NKoe5XOeduwbEQHU Content-Type: multipart/mixed; boundary="VrqPEDrXMn8OVzN4" Content-Disposition: inline --VrqPEDrXMn8OVzN4 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jan 05, 2007 at 01:34:04PM +0000, Robert Watson wrote: >=20 > On Fri, 5 Jan 2007, Ceri Davies wrote: >=20 > >>Much as I would love to trust the contents of ub there, I suspect they= =20 > >>can't be trusted. Could you print the contents of *fp in kern_fstat() = in=20 > >>both of those stacks? I'd particularly like to know the value of=20 > >>fp->f_type, and then depending on the type, possibly the contents of=20 > >>*(struct vnode *)fp->f_vnode for DTYPE_VNODE/TYPE_FIFO or *(struct sock= et=20 > >>*)fp->f_data in the case of DTYPE_SOCKET. > > > >Can you tell me how to get at *fp given that the stack trace shows fstat= ()=20 > >and not kern_fstat()? Sorry if I'm being dumb but I don't know how to= =20 > >step into the kern_fstat() call from fstat(). >=20 > It could be that the stack is hosed losing the frame, or maybe it's inlin= ed=20 > (more likely the former I think, as kern_fstat() is a symbol used elsewhe= re=20 > in the kernel). The best bet may be to use the file descriptor number=20 > (uap->fd) to pull the struct file reference out of the process. Somethin= g=20 > on the order of (td->td_proc->p_fd->fd_ofiles[fd]) should return the righ= t=20 > struct file *. OK, got it. They're both sockets, data in the attachments. > How reproduceable is this? So far it's happened this morning and yesterday morning. I haven't seen it before that. I don't know the cause so I can't reproduce it at will, but the logs don't give any indication. Chances are that it will happen again tomorrow, but we'll see. Thanks, Ceri --=20 That must be wonderful! I don't understand it at all. -- Moliere --VrqPEDrXMn8OVzN4 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=panic1 Content-Transfer-Encoding: quoted-printable {root@shrike}-{~} # kgdb /usr/obj/usr/src/sys/SHRIKE/kernel.debug /var/cras= h/vmcore.29 kgdb: kvm_nlist(_stopped_cpus):=20 kgdb: kvm_nlist(_stoppcbs):=20 [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so:= Undefined symbol "ps_pglobal_lookup"] GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain condition= s. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd". Unread portion of the kernel message buffer: Fatal trap 12: page fault while in kernel mode fault virtual address =3D 0x53892047 fault code =3D supervisor write, page not present instruction pointer =3D 0x20:0xc05cda7c stack pointer =3D 0x28:0xd610dc48 frame pointer =3D 0x28:0xd610dc60 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 65381 (imapd) trap number =3D 12 panic: page fault Uptime: 5d19h44m40s Dumping 503 MB (2 chunks) chunk 0: 1MB (160 pages) ... ok chunk 1: 503MB (128752 pages) 487 471 455 439 423 407 391 375 359 343 327= 311 295 279 263 247 231 215 199 183 167 151 135 119 103 87 71 55 39 23 7 #0 doadump () at pcpu.h:165 165 pcpu.h: No such file or directory. in pcpu.h (kgdb) up 8 #8 0xc04c470d in fstat (td=3D0xc2eeb180, uap=3D0xd610dc74) at /usr/src/sys= /kern/kern_descrip.c:1075 1075 error =3D kern_fstat(td, uap->fd, &ub); (kgdb) p *td->td_proc->p_fd->fd_ofiles $1 =3D (struct file *) 0xc32f73f0 (kgdb) p*$1 $2 =3D {f_list =3D {le_next =3D 0xc32ddd38, le_prev =3D 0xc4062048}, f_type= =3D 2, f_data =3D 0xc38f62c8,=20 f_flag =3D 3, f_mtxp =3D 0xc2a67154, f_ops =3D 0xc06b1040, f_cred =3D 0xc= 2e4a580, f_count =3D 3,=20 f_vnode =3D 0x0, f_offset =3D 0, f_vnread_flags =3D 0, f_gcflag =3D 0, f_= msgcount =3D 0, f_seqcount =3D 0,=20 f_nextoff =3D 0, f_label =3D 0x0} (kgdb) p $2->f_data $3 =3D (void *) 0xc38f62c8 (kgdb) p *(struct socket *)$2->f_data $4 =3D {so_count =3D 1, so_type =3D 1, so_options =3D 4, so_linger =3D 0, s= o_state =3D 2, so_qstate =3D 0,=20 so_pcb =3D 0xc38eaec4, so_proto =3D 0xc06b8148, so_head =3D 0x0, so_incom= p =3D {tqh_first =3D 0x0,=20 tqh_last =3D 0x0}, so_comp =3D {tqh_first =3D 0x0, tqh_last =3D 0x0}, s= o_list =3D {tqe_next =3D 0x0,=20 tqe_prev =3D 0xc2e5087c}, so_qlen =3D 0, so_incqlen =3D 0, so_qlimit = =3D 0, so_timeo =3D 0,=20 so_error =3D 0, so_sigio =3D 0x0, so_oobmark =3D 0, so_aiojobq =3D {tqh_f= irst =3D 0x0,=20 tqh_last =3D 0xc38f6310}, so_rcv =3D {sb_sel =3D {si_thrlist =3D {tqe_n= ext =3D 0x0,=20 tqe_prev =3D 0xc2eeb1b0}, si_thread =3D 0x0, si_note =3D {kl_list = =3D {slh_first =3D 0x0},=20 kl_lock =3D 0xc04cd13c , kl_unlock =3D 0xc04cd170 = ,=20 kl_locked =3D 0xc04cd1ac , kl_lockarg =3D 0xc38f= 633c}, si_flags =3D 0},=20 sb_mtx =3D {mtx_object =3D {lo_class =3D 0xc06ad4c4, lo_name =3D 0xc068= 133e "so_rcv",=20 lo_type =3D 0xc068133e "so_rcv", lo_flags =3D 196608, lo_list =3D {= tqe_next =3D 0x0,=20 tqe_prev =3D 0x0}, lo_witness =3D 0x0}, mtx_lock =3D 4, mtx_recur= se =3D 0}, sb_state =3D 0,=20 sb_mb =3D 0x0, sb_mbtail =3D 0x0, sb_lastrecord =3D 0x0, sb_cc =3D 0, s= b_hiwat =3D 66608, sb_mbcnt =3D 0,=20 sb_mbmax =3D 262144, sb_ctl =3D 0, sb_lowat =3D 1, sb_timeo =3D 0, sb_f= lags =3D 0}, so_snd =3D {sb_sel =3D { si_thrlist =3D {tqe_next =3D 0x0, tqe_prev =3D 0x0}, si_thread =3D 0x= 0, si_note =3D {kl_list =3D { slh_first =3D 0x0}, kl_lock =3D 0xc04cd13c ,=20 kl_unlock =3D 0xc04cd170 , kl_locked =3D 0xc04cd= 1ac ,=20 kl_lockarg =3D 0xc38f63b4}, si_flags =3D 0}, sb_mtx =3D {mtx_object= =3D {lo_class =3D 0xc06ad4c4,=20 lo_name =3D 0xc0681337 "so_snd", lo_type =3D 0xc0681337 "so_snd", l= o_flags =3D 196608,=20 lo_list =3D {tqe_next =3D 0x0, tqe_prev =3D 0x0}, lo_witness =3D 0x= 0}, mtx_lock =3D 4,=20 mtx_recurse =3D 0}, sb_state =3D 0, sb_mb =3D 0x0, sb_mbtail =3D 0x0,= sb_lastrecord =3D 0x0,=20 sb_cc =3D 0, sb_hiwat =3D 33304, sb_mbcnt =3D 0, sb_mbmax =3D 262144, s= b_ctl =3D 0, sb_lowat =3D 2048,=20 sb_timeo =3D 0, sb_flags =3D 0}, so_upcall =3D 0, so_upcallarg =3D 0x0,= so_cred =3D 0xc2a7ad00,=20 so_label =3D 0x0, so_peerlabel =3D 0x0, so_gencnt =3D 92385, so_emuldata = =3D 0x0, so_accf =3D 0x0} (kgdb) --VrqPEDrXMn8OVzN4 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=panic2 Content-Transfer-Encoding: quoted-printable {root@shrike}=1B[m-{~} # kgdb /usr/obj/usr/src/sys/SHRIKE/kernel.debug /var= /crash/vmcore.30 kgdb: kvm_nlist(_stopped_cpus):=20 kgdb: kvm_nlist(_stoppcbs):=20 [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so:= Undefined symbol "ps_pglobal_lookup"] GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain condition= s. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd". Unread portion of the kernel message buffer: Fatal trap 12: page fault while in kernel mode fault virtual address =3D 0x53892047 fault code =3D supervisor write, page not present instruction pointer =3D 0x20:0xc05cda7c stack pointer =3D 0x28:0xd617ec48 frame pointer =3D 0x28:0xd617ec60 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 9943 (imapd) trap number =3D 12 panic: page fault Uptime: 22h39m3s Dumping 503 MB (2 chunks) chunk 0: 1MB (160 pages) ... ok chunk 1: 503MB (128752 pages) 487 471 455 439 423 407 391 375 359 343 327= 311 295 279 263 247 231 215 199 183 167 151 135 119 103 87 71 55 39 23 7 #0 doadump () at pcpu.h:165 165 pcpu.h: No such file or directory. in pcpu.h (kgdb) up 8 #8 0xc04c470d in fstat (td=3D0xc3109300, uap=3D0xd617ec74) at /usr/src/sys= /kern/kern_descrip.c:1075 1075 error =3D kern_fstat(td, uap->fd, &ub); (kgdb) p *td->td_proc->p_fd->fd_ofiles $1 =3D (struct file *) 0xc33fd1f8 (kgdb) p *$1 $2 =3D {f_list =3D {le_next =3D 0xc30a6678, le_prev =3D 0xc3790b88}, f_type= =3D 2, f_data =3D 0xc347f590,=20 f_flag =3D 3, f_mtxp =3D 0xc2a67a30, f_ops =3D 0xc06b1040, f_cred =3D 0xc= 3592a80, f_count =3D 3,=20 f_vnode =3D 0x0, f_offset =3D 0, f_vnread_flags =3D 0, f_gcflag =3D 0, f_= msgcount =3D 0, f_seqcount =3D 0,=20 f_nextoff =3D 0, f_label =3D 0x0} (kgdb) p *(struct socket *)$2->f_data $3 =3D {so_count =3D 1, so_type =3D 1, so_options =3D 4, so_linger =3D 0, s= o_state =3D 2, so_qstate =3D 0,=20 so_pcb =3D 0xc317b168, so_proto =3D 0xc06b8148, so_head =3D 0x0, so_incom= p =3D {tqh_first =3D 0x0,=20 tqh_last =3D 0x0}, so_comp =3D {tqh_first =3D 0x0, tqh_last =3D 0x0}, s= o_list =3D {tqe_next =3D 0x0,=20 tqe_prev =3D 0xc2e5ab44}, so_qlen =3D 0, so_incqlen =3D 0, so_qlimit = =3D 0, so_timeo =3D 0,=20 so_error =3D 0, so_sigio =3D 0x0, so_oobmark =3D 0, so_aiojobq =3D {tqh_f= irst =3D 0x0,=20 tqh_last =3D 0xc347f5d8}, so_rcv =3D {sb_sel =3D {si_thrlist =3D {tqe_n= ext =3D 0x0,=20 tqe_prev =3D 0xc3109330}, si_thread =3D 0x0, si_note =3D {kl_list = =3D {slh_first =3D 0x0},=20 kl_lock =3D 0xc04cd13c , kl_unlock =3D 0xc04cd170 = ,=20 kl_locked =3D 0xc04cd1ac , kl_lockarg =3D 0xc347= f604}, si_flags =3D 0},=20 sb_mtx =3D {mtx_object =3D {lo_class =3D 0xc06ad4c4, lo_name =3D 0xc068= 133e "so_rcv",=20 lo_type =3D 0xc068133e "so_rcv", lo_flags =3D 196608, lo_list =3D {= tqe_next =3D 0x0,=20 tqe_prev =3D 0x0}, lo_witness =3D 0x0}, mtx_lock =3D 4, mtx_recur= se =3D 0}, sb_state =3D 0,=20 sb_mb =3D 0x0, sb_mbtail =3D 0x0, sb_lastrecord =3D 0x0, sb_cc =3D 0, s= b_hiwat =3D 66608, sb_mbcnt =3D 0,=20 sb_mbmax =3D 262144, sb_ctl =3D 0, sb_lowat =3D 1, sb_timeo =3D 0, sb_f= lags =3D 0}, so_snd =3D {sb_sel =3D { si_thrlist =3D {tqe_next =3D 0x0, tqe_prev =3D 0x0}, si_thread =3D 0x= 0, si_note =3D {kl_list =3D { slh_first =3D 0x0}, kl_lock =3D 0xc04cd13c ,=20 kl_unlock =3D 0xc04cd170 , kl_locked =3D 0xc04cd= 1ac ,=20 kl_lockarg =3D 0xc347f67c}, si_flags =3D 0}, sb_mtx =3D {mtx_object= =3D {lo_class =3D 0xc06ad4c4,=20 lo_name =3D 0xc0681337 "so_snd", lo_type =3D 0xc0681337 "so_snd", l= o_flags =3D 196608,=20 lo_list =3D {tqe_next =3D 0x0, tqe_prev =3D 0x0}, lo_witness =3D 0x= 0}, mtx_lock =3D 4,=20 mtx_recurse =3D 0}, sb_state =3D 0, sb_mb =3D 0x0, sb_mbtail =3D 0x0,= sb_lastrecord =3D 0x0,=20 sb_cc =3D 0, sb_hiwat =3D 33304, sb_mbcnt =3D 0, sb_mbmax =3D 262144, s= b_ctl =3D 0, sb_lowat =3D 2048,=20 sb_timeo =3D 0, sb_flags =3D 0}, so_upcall =3D 0, so_upcallarg =3D 0x0,= so_cred =3D 0xc2a7ad00,=20 so_label =3D 0x0, so_peerlabel =3D 0x0, so_gencnt =3D 22107, so_emuldata = =3D 0x0, so_accf =3D 0x0} (kgdb) --VrqPEDrXMn8OVzN4-- --NKoe5XOeduwbEQHU Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFFnmoJocfcwTS3JF8RAvRrAJ0cIWI5KunoJMHvGiGdyFp3FfNYAgCgtMY7 FcV0jf4O/FUWBUijhF8d+4U= =sSv7 -----END PGP SIGNATURE----- --NKoe5XOeduwbEQHU-- From owner-freebsd-stable@FreeBSD.ORG Fri Jan 5 15:45:29 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org 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 26CD716A415 for ; Fri, 5 Jan 2007 15:45:29 +0000 (UTC) (envelope-from vincent_delft@yahoo.com) Received: from web30512.mail.mud.yahoo.com (web30512.mail.mud.yahoo.com [68.142.201.240]) by mx1.freebsd.org (Postfix) with SMTP id B27ED13C455 for ; Fri, 5 Jan 2007 15:45:28 +0000 (UTC) (envelope-from vincent_delft@yahoo.com) Received: (qmail 57872 invoked by uid 60001); 5 Jan 2007 15:17:12 -0000 Message-ID: <20070105151712.57870.qmail@web30512.mail.mud.yahoo.com> DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=X5wC0XfkOkpAqx0+3DGp4RwO4GLk1Zuu/s93ahv8Dhtk4aDN/EObKEovvjtlQyI4kAxUR5NTO1vh2/I+QpjTsJWYLP2Mbii0J1QJfIC7eG5hxS0vLxWrARy8o0eO022y5MY4DbsRssYSuMvX8gYRaRMebz/gqfPxqAXN3XLVqZQ=; X-YMail-OSG: AsnnKfoVM1ngMX77Dy0IMlePsy00dW2MIRO8ThYTXPVYNYWLrX38T6lisBBtx1DbdctCRt1gbHTsovwyI3.HeeYUuTdf2vq91yCJ7wkioPW9Tx8D0SSOgdhQ1fVx1sl9ng6f21aPbCIGKEg- Received: from [81.242.159.5] by web30512.mail.mud.yahoo.com via HTTP; Fri, 05 Jan 2007 07:17:12 PST Date: Fri, 5 Jan 2007 07:17:12 -0800 (PST) From: vincent delft To: freebsd-stable@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Subject: Shutdown problem "Stray IRQ9" 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, 05 Jan 2007 15:45:29 -0000 As new to FreeBSD I'm looking for info to solve my shutdown problem. When I shutdown the system (shutdown -h now), the messages displayed are: " No buffers busy after final sync Uptime: 1h3m35s Shutting down ACPI stray irq9 " then hang ;-(. I've google a bit on "stray irq9" and found several mails where people says that this is a known problem, or saying that we should don't care about this, ... What's the current status ? (parameters, options, patches, ...) Could I let this like that ? I'm on a ECS K7S5A with FBSD-6.1-Stable. Thanks. PS: On the same machine, my gentoo can shutdown correctly. Thus I would conclude that this is not HW related. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From owner-freebsd-stable@FreeBSD.ORG Fri Jan 5 16:09:12 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org 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 0E53D16A407 for ; Fri, 5 Jan 2007 16:09:12 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from sccrmhc12.comcast.net (sccrmhc12.comcast.net [204.127.200.82]) by mx1.freebsd.org (Postfix) with ESMTP id CA47813C442 for ; Fri, 5 Jan 2007 16:09:11 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from icarus.home.lan (c-71-198-0-135.hsd1.ca.comcast.net[71.198.0.135]) by comcast.net (sccrmhc12) with ESMTP id <20070105160909012004g0b2e>; Fri, 5 Jan 2007 16:09:09 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 1F0F11FA037; Fri, 5 Jan 2007 08:09:09 -0800 (PST) Date: Fri, 5 Jan 2007 08:09:09 -0800 From: Jeremy Chadwick To: vincent delft Message-ID: <20070105160909.GA63680@icarus.home.lan> Mail-Followup-To: vincent delft , freebsd-stable@freebsd.org References: <20070105151712.57870.qmail@web30512.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070105151712.57870.qmail@web30512.mail.mud.yahoo.com> X-PGP-Key: http://jdc.parodius.com/pubkey.asc User-Agent: Mutt/1.5.13 (2006-08-11) Cc: freebsd-stable@freebsd.org Subject: Re: Shutdown problem "Stray IRQ9" 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, 05 Jan 2007 16:09:12 -0000 On Fri, Jan 05, 2007 at 07:17:12AM -0800, vincent delft wrote: > As new to FreeBSD I'm looking for info to solve my > shutdown problem. > > When I shutdown the system (shutdown -h now), the > messages displayed are: > " > No buffers busy after final sync > Uptime: 1h3m35s > Shutting down ACPI > stray irq9 > " > then hang ;-(. I've seen this problem on different machines with different hardware. I don't think it's a hardware problem, though -- I think it's more along the lines of either an interrupt routing problem, or possibly an SMP issue. This is all pure hearsay on my part, but it's the only thing that stands out. I'll add that I have an Asus A8N-E (nForce chipset, AMD CPU) board that exhibits the above behaviour, but _does not_ print the stray irq9 bit. "halt" and "shutdown -h" simply hang after shutting down ACPI; there is no "Press enter to reboot" message, and the keyboard handler appears locked up too. If a developer wants one of these motherboards (no CPU or RAM or other stuff though :) ), I can ship one out for free. I have a working spare. > I've google a bit on "stray irq9" and found several > mails where people says that this is a known problem, > or saying that we should don't care about this, ... I've seen this message mainly on Intel chipset boards. I believe IRQ 9 is commonly assigned by the BIOS to ACPI functionality. I believe what's happening (again, hearsay) is that FreeBSD shuts down ACPI capability, and the interrupt handler reports that nothing is tied to IRQ 9 any more. In comparison, you can search for "stray irq7" and see that others have seen this message on certain boards where the LPT/printer port has been disabled in the BIOS, but lpt support is enabled in FreeBSD. (What I'm trying to say is that the "stray irq" stuff stems from what I described in the above paragraph. > PS: > On the same machine, my gentoo can shutdown correctly. > Thus I would conclude that this is not HW related. I agree. -- | Jeremy Chadwick jdc at 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 Jan 5 16:59:42 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org 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 39DB016A407 for ; Fri, 5 Jan 2007 16:59:42 +0000 (UTC) (envelope-from quetzal@zone3000.net) Received: from mx1.sitevalley.com (sitevalley.com [209.67.60.43]) by mx1.freebsd.org (Postfix) with SMTP id F1E7413C428 for ; Fri, 5 Jan 2007 16:59:41 +0000 (UTC) (envelope-from quetzal@zone3000.net) Received: from unknown (HELO localhost) (217.144.69.37) by 209.67.61.254 with SMTP; 5 Jan 2007 16:59:41 -0000 Date: Fri, 5 Jan 2007 18:59:10 +0200 From: Nikolay Pavlov To: freebsd-stable@freebsd.org Message-ID: <20070105165910.GA37906@zone3000.net> Mail-Followup-To: Nikolay Pavlov , freebsd-stable@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Mutt/1.4.2.1i X-Operating-System: FreeBSD 6.1-RELEASE-p10 Subject: kernel panic on 6.2-RC2 with GENERIC. 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, 05 Jan 2007 16:59:42 -0000 Hello folks. I have kernel panic on GENERIC kernel while executing postmark. Before panic there were messages like this: g_vfs_done():da1s1d[WRITE(offset=3D772363010048, length=3D16384)]error =3D 5 g_vfs_done():da1s1d[WRITE(offset=3D772363026432, length=3D16384)]error =3D 5 g_vfs_done():da1s1d[WRITE(offset=3D772363042816, length=3D16384)]error =3D 5 g_vfs_done():da1s1d[WRITE(offset=3D772363059200, length=3D16384)]error =3D 5 and=20 initiate_write_filepage: already started And finaly here is a panic: kgdb kernel.debug /mnt/mnt2/crash/vmcore.2 [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so:= Undefined symbol "ps_pglobal_lookup"] GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain condition= s. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd". Unread portion of the kernel message buffer: panic: initiate_write_inodeblock_ufs2: already started Uptime: 9m27s Dumping 3583 MB (2 chunks) chunk 0: 1MB (156 pages) ... ok chunk 1: 3583MB (917216 pages) 3567 3551 3535 3519 3503 3487 3471 3455 34= 39 3423 3407 3391 3375 3359 3343 3327 3311 3295 3279 3263 3247 3231 3215 31= 99 3183 3167 3151 3135 3119 3103 3087 3071 3055 3039 3023 3007 2991 2975 29= 59 2943 2927 2911 2895 2879 2863 2847 2831 2815 2799 2783 2767 2751 2735 27= 19 2703 2687 2671 2655 2639 2623 2607 2591 2575 2559 2543 2527 2511 2495 24= 79 2463 2447 2431 2415 2399 2383 2367 2351 2335 2319 2303 2287 2271 2255 22= 39 2223 2207 2191 2175 2159 2143 2127 2111 2095 2079 2063 2047 2031 2015 19= 99 1983 1967 1951 1935 1919 1903 1887 1871 1855 1839 1823 1807 1791 1775 17= 59 1743 1727 1711 1695 1679 1663 1647 1631 1615 1599 1583 1567 1551 1535 15= 19 1503 1487 1471 1455 1439 1423 1407 1391 1375 1359 1343 1327 1311 1295 12= 79 1263 1247 1231 1215 1199 1183 1167 1151 1135 1119 1103 1087 1071 1055 10= 39 1023 1007 991 975 959 943 927 911 895 879 863 847 831 815 799 783 767 75= 1 735 719 703 687 671 655 639 623 607 591 575 559 543 527 511 495 479 463 4= 47 431 415 399 383 367 351 335 319 303 287 271 255 239 223 207 191 175 159 = 143 127 111 95 79 63 47 31 15 #0 doadump () at pcpu.h:165 165 pcpu.h: No such file or directory. in pcpu.h (kgdb) bt #0 doadump () at pcpu.h:165 #1 0xc0672a26 in boot (howto=3D260) at /usr/src/sys/kern/kern_shutdown.c:4= 09 #2 0xc0672cbc in panic (fmt=3D0xc0909c75 "initiate_write_inodeblock_ufs2: = already started") at /usr/src/sys/kern/kern_shutdown.c:565 #3 0xc07c00ca in initiate_write_inodeblock_ufs2 (inodedep=3D0xc9c54000, bp= =3D0x0) at /usr/src/sys/ufs/ffs/ffs_softdep.c:4022 #4 0xc07bf897 in softdep_disk_io_initiation (bp=3D0xdc9c63b8) at /usr/src/= sys/ufs/ffs/ffs_softdep.c:3757 #5 0xc07c8411 in ffs_geom_strategy (bo=3D0xc8c5a830, bp=3D0xdc9c63b8) at b= uf.h:433 #6 0xc06b8048 in bufwrite (bp=3D0xdc9c63b8) at buf.h:426 #7 0xc07c82d2 in ffs_bufwrite (bp=3D0xdc9c63b8) at /usr/src/sys/ufs/ffs/ff= s_vfsops.c:1740 #8 0xc06b9a77 in vfs_bio_awrite (bp=3D0xdc9c63b8) at buf.h:410 #9 0xc06ba8bd in flushbufqueues (flushdeps=3D0) at /usr/src/sys/kern/vfs_b= io.c:2125 #10 0xc06ba3bf in buf_daemon () at /usr/src/sys/kern/vfs_bio.c:1999 #11 0xc065cc5c in fork_exit (callout=3D0xc06ba2d0 , arg=3D0x0, = frame=3D0xe8f9fd38) at /usr/src/sys/kern/kern_fork.c:821 #12 0xc087397c in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:= 208 This box is using ARECA RAID with GENERIC UP kernel: arcmsr0@pci3:14:0: class=3D0x010400 card=3D0x116017d3 chip=3D0x116017d= 3 rev=3D0x00 hdr=3D0x00 vendor =3D 'Areca Technology Corporation' device =3D 'ARC-1160 16-Port PCI-X to SATA RAID Controller' class =3D mass storage subclass =3D RAID From owner-freebsd-stable@FreeBSD.ORG Fri Jan 5 17:19:21 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org 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 E715D16A403 for ; Fri, 5 Jan 2007 17:19:21 +0000 (UTC) (envelope-from quetzal@zone3000.net) Received: from mx1.sitevalley.com (sitevalley.com [209.67.60.43]) by mx1.freebsd.org (Postfix) with SMTP id AB35813C455 for ; Fri, 5 Jan 2007 17:19:21 +0000 (UTC) (envelope-from quetzal@zone3000.net) Received: from unknown (HELO localhost) (217.144.69.37) by 209.67.61.254 with SMTP; 5 Jan 2007 17:19:19 -0000 Date: Fri, 5 Jan 2007 19:18:49 +0200 From: Nikolay Pavlov To: freebsd-stable@freebsd.org Message-ID: <20070105171849.GA38686@zone3000.net> Mail-Followup-To: Nikolay Pavlov , freebsd-stable@freebsd.org References: <20070105165910.GA37906@zone3000.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: <20070105165910.GA37906@zone3000.net> User-Agent: Mutt/1.4.2.1i X-Operating-System: FreeBSD 6.1-RELEASE-p10 Subject: Re: kernel panic on 6.2-RC2 with GENERIC. 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, 05 Jan 2007 17:19:22 -0000 On Friday, 5 January 2007 at 18:59:10 +0200, Nikolay Pavlov wrote: > Hello folks. I want to add that i can't triger this panic in 6.1-RELEASE-p11. > I have kernel panic on GENERIC kernel while executing postmark. >=20 > Before panic there were messages like this: > g_vfs_done():da1s1d[WRITE(offset=3D772363010048, length=3D16384)]error = =3D 5 > g_vfs_done():da1s1d[WRITE(offset=3D772363026432, length=3D16384)]error = =3D 5 > g_vfs_done():da1s1d[WRITE(offset=3D772363042816, length=3D16384)]error = =3D 5 > g_vfs_done():da1s1d[WRITE(offset=3D772363059200, length=3D16384)]error = =3D 5 >=20 > and=20 >=20 > initiate_write_filepage: already started >=20 > And finaly here is a panic: >=20 > kgdb kernel.debug /mnt/mnt2/crash/vmcore.2 > [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.s= o: Undefined symbol "ps_pglobal_lookup"] > GNU gdb 6.1.1 [FreeBSD] > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you = are > welcome to change it and/or distribute copies of it under certain conditi= ons. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for detail= s. > This GDB was configured as "i386-marcel-freebsd". >=20 > Unread portion of the kernel message buffer: > panic: initiate_write_inodeblock_ufs2: already started > Uptime: 9m27s > Dumping 3583 MB (2 chunks) > chunk 0: 1MB (156 pages) ... ok > chunk 1: 3583MB (917216 pages) 3567 3551 3535 3519 3503 3487 3471 3455 = 3439 3423 3407 3391 3375 3359 3343 3327 3311 3295 3279 3263 3247 3231 3215 = 3199 3183 3167 3151 3135 3119 3103 3087 3071 3055 3039 3023 3007 2991 2975 = 2959 2943 2927 2911 2895 2879 2863 2847 2831 2815 2799 2783 2767 2751 2735 = 2719 2703 2687 2671 2655 2639 2623 2607 2591 2575 2559 2543 2527 2511 2495 = 2479 2463 2447 2431 2415 2399 2383 2367 2351 2335 2319 2303 2287 2271 2255 = 2239 2223 2207 2191 2175 2159 2143 2127 2111 2095 2079 2063 2047 2031 2015 = 1999 1983 1967 1951 1935 1919 1903 1887 1871 1855 1839 1823 1807 1791 1775 = 1759 1743 1727 1711 1695 1679 1663 1647 1631 1615 1599 1583 1567 1551 1535 = 1519 1503 1487 1471 1455 1439 1423 1407 1391 1375 1359 1343 1327 1311 1295 = 1279 1263 1247 1231 1215 1199 1183 1167 1151 1135 1119 1103 1087 1071 1055 = 1039 1023 1007 991 975 959 943 927 911 895 879 863 847 831 815 799 783 767 = 751 735 719 703 687 671 655 639 623 607 591 575 559 543 527 511 495 479 463= 447 431 415 399 383 367 351 335 319 303 287 271 255 239 223 207 191 175 15= 9 143 127 111 95 79 63 47 31 15 >=20 > #0 doadump () at pcpu.h:165 > 165 pcpu.h: No such file or directory. > in pcpu.h > (kgdb) bt > #0 doadump () at pcpu.h:165 > #1 0xc0672a26 in boot (howto=3D260) at /usr/src/sys/kern/kern_shutdown.c= :409 > #2 0xc0672cbc in panic (fmt=3D0xc0909c75 "initiate_write_inodeblock_ufs2= : already started") at /usr/src/sys/kern/kern_shutdown.c:565 > #3 0xc07c00ca in initiate_write_inodeblock_ufs2 (inodedep=3D0xc9c54000, = bp=3D0x0) at /usr/src/sys/ufs/ffs/ffs_softdep.c:4022 > #4 0xc07bf897 in softdep_disk_io_initiation (bp=3D0xdc9c63b8) at /usr/sr= c/sys/ufs/ffs/ffs_softdep.c:3757 > #5 0xc07c8411 in ffs_geom_strategy (bo=3D0xc8c5a830, bp=3D0xdc9c63b8) at= buf.h:433 > #6 0xc06b8048 in bufwrite (bp=3D0xdc9c63b8) at buf.h:426 > #7 0xc07c82d2 in ffs_bufwrite (bp=3D0xdc9c63b8) at /usr/src/sys/ufs/ffs/= ffs_vfsops.c:1740 > #8 0xc06b9a77 in vfs_bio_awrite (bp=3D0xdc9c63b8) at buf.h:410 > #9 0xc06ba8bd in flushbufqueues (flushdeps=3D0) at /usr/src/sys/kern/vfs= _bio.c:2125 > #10 0xc06ba3bf in buf_daemon () at /usr/src/sys/kern/vfs_bio.c:1999 > #11 0xc065cc5c in fork_exit (callout=3D0xc06ba2d0 , arg=3D0x0= , frame=3D0xe8f9fd38) at /usr/src/sys/kern/kern_fork.c:821 > #12 0xc087397c in fork_trampoline () at /usr/src/sys/i386/i386/exception.= s:208 >=20 >=20 > This box is using ARECA RAID with GENERIC UP kernel: >=20 > arcmsr0@pci3:14:0: class=3D0x010400 card=3D0x116017d3 chip=3D0x11601= 7d3 rev=3D0x00 hdr=3D0x00 > vendor =3D 'Areca Technology Corporation' > device =3D 'ARC-1160 16-Port PCI-X to SATA RAID Controller' > class =3D mass storage > subclass =3D RAID >=20 > _______________________________________________ > 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" --=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =20 - Best regards, Nikolay Pavlov. <<<----------------------------------- = =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =20 From owner-freebsd-stable@FreeBSD.ORG Fri Jan 5 17:43:53 2007 Return-Path: X-Original-To: stable@freebsd.org 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 2DC4016A40F for ; Fri, 5 Jan 2007 17:43:53 +0000 (UTC) (envelope-from eugen@www.svzserv.kemerovo.su) Received: from www.svzserv.kemerovo.su (www.svzserv.kemerovo.su [213.184.65.80]) by mx1.freebsd.org (Postfix) with ESMTP id 79CAE13C458 for ; Fri, 5 Jan 2007 17:43:51 +0000 (UTC) (envelope-from eugen@www.svzserv.kemerovo.su) Received: from www.svzserv.kemerovo.su (eugen@localhost [127.0.0.1]) by www.svzserv.kemerovo.su (8.13.8/8.13.8) with ESMTP id l05HhoGA022108; Sat, 6 Jan 2007 00:43:50 +0700 (KRAT) (envelope-from eugen@www.svzserv.kemerovo.su) Received: (from eugen@localhost) by www.svzserv.kemerovo.su (8.13.8/8.13.8/Submit) id l05Hho0U022107; Sat, 6 Jan 2007 00:43:50 +0700 (KRAT) (envelope-from eugen) Date: Sat, 6 Jan 2007 00:43:50 +0700 From: Eugene Grosbein To: performance@freebsd.org Message-ID: <20070105174350.GA21615@svzserv.kemerovo.su> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Cc: stable@freebsd.org Subject: benchmark 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, 05 Jan 2007 17:43:53 -0000 Hi! I'm trying to meashure network throughput between two 6.2-PRERELEASE boxes, basically get maximim IP packets per second transmitted/received. Tried to use iperf from ports in UDP mode with 64 byte payload, but it calls gettimeofday() after each write and gives me about 80Kpps only for Pentium D 2.8Ghz. What alternative should I use? May be, a netgraph node? Eugene From owner-freebsd-stable@FreeBSD.ORG Fri Jan 5 18:00:05 2007 Return-Path: X-Original-To: stable@freebsd.org 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 AD1C116A403; Fri, 5 Jan 2007 18:00:05 +0000 (UTC) (envelope-from eugen@www.svzserv.kemerovo.su) Received: from www.svzserv.kemerovo.su (www.svzserv.kemerovo.su [213.184.65.80]) by mx1.freebsd.org (Postfix) with ESMTP id 0201C13C43E; Fri, 5 Jan 2007 18:00:04 +0000 (UTC) (envelope-from eugen@www.svzserv.kemerovo.su) Received: from www.svzserv.kemerovo.su (eugen@localhost [127.0.0.1]) by www.svzserv.kemerovo.su (8.13.8/8.13.8) with ESMTP id l05I03Gv023590; Sat, 6 Jan 2007 01:00:03 +0700 (KRAT) (envelope-from eugen@www.svzserv.kemerovo.su) Received: (from eugen@localhost) by www.svzserv.kemerovo.su (8.13.8/8.13.8/Submit) id l05I03G3023588; Sat, 6 Jan 2007 01:00:03 +0700 (KRAT) (envelope-from eugen) Date: Sat, 6 Jan 2007 01:00:03 +0700 From: Eugene Grosbein To: pete wright Message-ID: <20070105180003.GA23331@svzserv.kemerovo.su> References: <20070105174350.GA21615@svzserv.kemerovo.su> <57d710000701050956j36433495v72b62a9404a25a5d@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <57d710000701050956j36433495v72b62a9404a25a5d@mail.gmail.com> User-Agent: Mutt/1.4.2.1i Cc: stable@freebsd.org, performance@freebsd.org Subject: Re: benchmark 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, 05 Jan 2007 18:00:05 -0000 On Fri, Jan 05, 2007 at 09:56:31AM -0800, pete wright wrote: > >Tried to use iperf from ports in UDP mode with 64 byte payload, > >but it calls gettimeofday() after each write and gives me about 80Kpps only > >for Pentium D 2.8Ghz. > > > >What alternative should I use? May be, a netgraph node? > > I've done some benchmarking/testing of 10gig-e NIC's using a combo of > iperf/netgraph and ttcp with good results. all are available in > ports. What pps numbers had you obtained? What CPU had you used? I don't like iperf for gettimeofday() overhead. Eugene From owner-freebsd-stable@FreeBSD.ORG Fri Jan 5 18:05:38 2007 Return-Path: X-Original-To: stable@freebsd.org 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 6267816A403 for ; Fri, 5 Jan 2007 18:05:38 +0000 (UTC) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.freebsd.org (Postfix) with ESMTP id 4ED5413C461 for ; Fri, 5 Jan 2007 18:05:38 +0000 (UTC) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.11/8.13.6) with ESMTP id l05I5cgr091195; Fri, 5 Jan 2007 10:05:38 -0800 (PST) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.11/8.12.3/Submit) id l05I5cf6091194; Fri, 5 Jan 2007 10:05:38 -0800 (PST) (envelope-from rizzo) Date: Fri, 5 Jan 2007 10:05:38 -0800 From: Luigi Rizzo To: Eugene Grosbein Message-ID: <20070105100537.A90952@xorpc.icir.org> References: <20070105174350.GA21615@svzserv.kemerovo.su> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20070105174350.GA21615@svzserv.kemerovo.su>; from eugen@kuzbass.ru on Sat, Jan 06, 2007 at 12:43:50AM +0700 Cc: stable@freebsd.org, performance@freebsd.org Subject: Re: benchmark 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, 05 Jan 2007 18:05:38 -0000 On Sat, Jan 06, 2007 at 12:43:50AM +0700, Eugene Grosbein wrote: > Hi! > > I'm trying to meashure network throughput between two 6.2-PRERELEASE boxes, > basically get maximim IP packets per second transmitted/received. > > Tried to use iperf from ports in UDP mode with 64 byte payload, > but it calls gettimeofday() after each write and gives me about 80Kpps only > for Pentium D 2.8Ghz. just write your own program that repeatedly calls send() on an udp socket, and you should be able to go way up. in the past (2001-2002) i tweaked the kernel with a sysctl that generated multiple (e.g. 100 or so) copies of each packet for a single send(), just for testing purposes, and on a 700 MHz machine i think i reached something in the order of 5-700kpps on a 4.x At the time the limit was the Gig-E card mounted on a PCI-66/64 bus. These days with a decent card on a PCI-X bus you shouldn't have these problems. cheers luigi > What alternative should I use? May be, a netgraph node? > > Eugene > _______________________________________________ > 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 Jan 5 18:13:24 2007 Return-Path: X-Original-To: stable@freebsd.org 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 A55BF16A47C for ; Fri, 5 Jan 2007 18:13:24 +0000 (UTC) (envelope-from nomadlogic@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.171]) by mx1.freebsd.org (Postfix) with ESMTP id 40E0913C455 for ; Fri, 5 Jan 2007 18:13:24 +0000 (UTC) (envelope-from nomadlogic@gmail.com) Received: by ug-out-1314.google.com with SMTP id o2so5138150uge for ; Fri, 05 Jan 2007 10:13:23 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=JZ2f71KY1ViPP3UM/nHSv7FvR5ZvNws59PS4ucsF+84xV/ZGCyulsFRWpVxbG6wGv1oh0+OJSKcZ4fh9zsMNTxS5g7/4Erw0dsXb8WnKNXnFbPxga+NzNo1M1p/Zlj2zrgFsnY+FqTIoJFkJa/08fkceJSMvlfiQrF6vaOa1r48= Received: by 10.78.200.3 with SMTP id x3mr6703771huf.1168020373572; Fri, 05 Jan 2007 10:06:13 -0800 (PST) Received: by 10.78.162.12 with HTTP; Fri, 5 Jan 2007 10:06:13 -0800 (PST) Message-ID: <57d710000701051006n278c44b4x9da019f3d8d8275c@mail.gmail.com> Date: Fri, 5 Jan 2007 10:06:13 -0800 From: "pete wright" To: "Eugene Grosbein" In-Reply-To: <20070105180003.GA23331@svzserv.kemerovo.su> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20070105174350.GA21615@svzserv.kemerovo.su> <57d710000701050956j36433495v72b62a9404a25a5d@mail.gmail.com> <20070105180003.GA23331@svzserv.kemerovo.su> Cc: stable@freebsd.org, performance@freebsd.org Subject: Re: benchmark 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, 05 Jan 2007 18:13:24 -0000 On 1/5/07, Eugene Grosbein wrote: > On Fri, Jan 05, 2007 at 09:56:31AM -0800, pete wright wrote: > > > >Tried to use iperf from ports in UDP mode with 64 byte payload, > > >but it calls gettimeofday() after each write and gives me about 80Kpps only > > >for Pentium D 2.8Ghz. > > > > > >What alternative should I use? May be, a netgraph node? > > > > I've done some benchmarking/testing of 10gig-e NIC's using a combo of > > iperf/netgraph and ttcp with good results. all are available in > > ports. > > What pps numbers had you obtained? What CPU had you used? > I don't like iperf for gettimeofday() overhead. > yea that was an issue, hence us using multiple benchmarks to get a better picture of performance. sorry can't really get into the specifics on the hardware/stat's of the benchmark. used 10gig-e as example to illustrate that all these utilities functioned well under heavy tcp and udp loads. -pete -- ~~o0OO0o~~ Pete Wright www.nycbug.org NYC's *BSD User Group From owner-freebsd-stable@FreeBSD.ORG Fri Jan 5 18:16:44 2007 Return-Path: X-Original-To: stable@FreeBSD.org 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 D275F16A412; Fri, 5 Jan 2007 18:16:44 +0000 (UTC) (envelope-from erwin@mail.droso.net) Received: from mail.droso.net (koala.droso.net [193.88.12.38]) by mx1.freebsd.org (Postfix) with ESMTP id 9CD6C13C44C; Fri, 5 Jan 2007 18:16:44 +0000 (UTC) (envelope-from erwin@mail.droso.net) Received: by mail.droso.net (Postfix, from userid 1001) id 1C76E1CC28; Fri, 5 Jan 2007 19:03:31 +0100 (CET) Date: Fri, 5 Jan 2007 19:03:31 +0100 From: FreeBSD portmgr secretary To: ports@FreeBSD.org, stable@FreeBSD.org Message-ID: <20070105180330.GU16049@droso.net> Mail-Followup-To: ports@FreeBSD.org, stable@FreeBSD.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="V/VNt6jARIhH3MER" Content-Disposition: inline User-Agent: Mutt/1.5.13 (2006-08-11) Cc: Subject: HEADS UP: FreeBSD ports 4.11 EoL coming soon 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, 05 Jan 2007 18:16:44 -0000 --V/VNt6jARIhH3MER Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On January 31st, FreeBSD 4.11 and earlier releases will have reached its End of Life dates and will no longer be supported by the FreeBSD Ports Team. Users are encouraged to upgrade to FreeBSD 6.1, or the upcoming FreeBSD 6.2 release. Packages for binary installations will no longer be built for FreeBSD 4.11. Building ports from source will no longer be supported and will no longer be tested on the pointyhat cluster. Additionally, INDEX will not be built anymore and available for the 'make fetchindex' target. Patches for individual ports specific for their functioning on FreeBSD 4.11 may be accepted at the maintainers digression, but ports will not be required to be marked BROKEN or IGNORE if they do not build or run. The FreeBSD 6.X branch, which is a stable and mature platform, is the 'reference' FreeBSD branch for the Ports Collection. We again wish to strongly encourage users to upgrade to this branch. -erwin Portmgr secratary --=20 Erwin Lansing http://droso.org Security is like an onion. (o_ _o) It's made up of several layers \\\_\ /_/// erwin@FreeBSD.org And it makes you cry. <____) (____> erwin@aauug.dk --V/VNt6jARIhH3MER Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFFnpLyefbgcXQUYpwRAnVyAJ9qmIJBC26TmfpV62Btrz5yFfKwrACgkqWE 5D1hH179OhvQsDnfcesLjwY= =8av4 -----END PGP SIGNATURE----- --V/VNt6jARIhH3MER-- From owner-freebsd-stable@FreeBSD.ORG Fri Jan 5 18:25:09 2007 Return-Path: X-Original-To: stable@freebsd.org 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 941C216A40F for ; Fri, 5 Jan 2007 18:25:09 +0000 (UTC) (envelope-from nomadlogic@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.171]) by mx1.freebsd.org (Postfix) with ESMTP id 2390013C467 for ; Fri, 5 Jan 2007 18:25:08 +0000 (UTC) (envelope-from nomadlogic@gmail.com) Received: by ug-out-1314.google.com with SMTP id o2so5140676uge for ; Fri, 05 Jan 2007 10:25:08 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=VNQmMwHfLjrXzSKc006S3kRGZB90N0lnyQfiHncNi/lNKAGUT1Y3++xqqE8VGDfOOe/OLkwL+I4jfzxzqrL8JL4pdIJh7xGVjVeCndbK56vyCG+a/nPR6N183tiSCgS0RdTsavfMc+XySCfEEvgdOTo2UvRx22E0HKZevpw3vw4= Received: by 10.78.185.15 with SMTP id i15mr5087243huf.1168019791276; Fri, 05 Jan 2007 09:56:31 -0800 (PST) Received: by 10.78.162.12 with HTTP; Fri, 5 Jan 2007 09:56:31 -0800 (PST) Message-ID: <57d710000701050956j36433495v72b62a9404a25a5d@mail.gmail.com> Date: Fri, 5 Jan 2007 09:56:31 -0800 From: "pete wright" To: "Eugene Grosbein" In-Reply-To: <20070105174350.GA21615@svzserv.kemerovo.su> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20070105174350.GA21615@svzserv.kemerovo.su> Cc: stable@freebsd.org, performance@freebsd.org Subject: Re: benchmark 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, 05 Jan 2007 18:25:09 -0000 On 1/5/07, Eugene Grosbein wrote: > Hi! > > I'm trying to meashure network throughput between two 6.2-PRERELEASE boxes, > basically get maximim IP packets per second transmitted/received. > > Tried to use iperf from ports in UDP mode with 64 byte payload, > but it calls gettimeofday() after each write and gives me about 80Kpps only > for Pentium D 2.8Ghz. > > What alternative should I use? May be, a netgraph node? > I've done some benchmarking/testing of 10gig-e NIC's using a combo of iperf/netgraph and ttcp with good results. all are available in ports. -pete -- ~~o0OO0o~~ Pete Wright www.nycbug.org NYC's *BSD User Group From owner-freebsd-stable@FreeBSD.ORG Fri Jan 5 18:54:37 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org 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 974AD16A412; Fri, 5 Jan 2007 18:54:37 +0000 (UTC) (envelope-from sam@kalessin.jpl.nasa.gov) Received: from mfbak.jpl.nasa.gov (mfbak.jpl.nasa.gov [137.78.160.179]) by mx1.freebsd.org (Postfix) with ESMTP id 624FE13C448; Fri, 5 Jan 2007 18:54:37 +0000 (UTC) (envelope-from sam@kalessin.jpl.nasa.gov) Received: from nmta2.jpl.nasa.gov (nmta.jpl.nasa.gov [137.78.160.215]) by mfbak.jpl.nasa.gov (Switch-3.1.9/Switch-3.1.7) with ESMTP id l05IAJdt015047; Fri, 5 Jan 2007 10:10:19 -0800 Received: from xmta2.jpl.nasa.gov (xmta2.jpl.nasa.gov [137.78.160.56]) by nmta2.jpl.nasa.gov (Switch-3.1.9/Switch-3.1.9) with ESMTP id l05IAHCR023976; Fri, 5 Jan 2007 10:10:17 -0800 Received: from kalessin.jpl.nasa.gov (kalessin.jpl.nasa.gov [128.149.29.130]) by xmta2.jpl.nasa.gov (Switch-3.1.9/Switch-3.1.9) with ESMTP id l05IAGHU021131; Fri, 5 Jan 2007 10:10:16 -0800 Received: (from sam@localhost) by kalessin.jpl.nasa.gov (8.13.7+Sun/8.12.10/Submit) id l05IAGNs022972; Fri, 5 Jan 2007 10:10:16 -0800 (PST) Date: Fri, 5 Jan 2007 10:10:16 -0800 (PST) Message-Id: <200701051810.l05IAGNs022972@kalessin.jpl.nasa.gov> From: Sam Sirlin To: koitsu@freebsd.org In-reply-to: <20070105160909.GA63680@icarus.home.lan> (message from Jeremy Chadwick on Fri, 5 Jan 2007 08:09:09 -0800) References: <20070105151712.57870.qmail@web30512.mail.mud.yahoo.com> <20070105160909.GA63680@icarus.home.lan> X-Source-IP: kalessin.jpl.nasa.gov [128.149.29.130] X-Source-Sender: sam@kalessin.jpl.nasa.gov X-AUTH: Authorized Cc: vincent_delft@yahoo.com, freebsd-stable@freebsd.org Subject: Re: Shutdown problem "Stray IRQ9" 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, 05 Jan 2007 18:54:37 -0000 Date: Fri, 5 Jan 2007 08:09:09 -0800 From: Jeremy Chadwick On Fri, Jan 05, 2007 at 07:17:12AM -0800, vincent delft wrote: > As new to FreeBSD I'm looking for info to solve my > shutdown problem. > > When I shutdown the system (shutdown -h now), the > messages displayed are: ... I think shutdown -h should just hang (always has on my amd64 machine). I think you want to do shutdown -p which should (and does for me) turn off power. Sam Sirlin Email: samuel.w.sirlin@jpl.nasa.gov From owner-freebsd-stable@FreeBSD.ORG Sat Jan 6 01:00:09 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org 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 33ABC16A50C for ; Sat, 6 Jan 2007 01:00:09 +0000 (UTC) (envelope-from frode@nordahl.net) Received: from smtp1.powertech.no (smtp1.powertech.no [195.159.0.145]) by mx1.freebsd.org (Postfix) with ESMTP id A8E9713C448 for ; Sat, 6 Jan 2007 01:00:08 +0000 (UTC) (envelope-from frode@nordahl.net) Received: from [195.159.148.126] (dhcp7.xu.nordahl.net [195.159.148.126]) by smtp1.powertech.no (Postfix) with ESMTP id 90789845B for ; Sat, 6 Jan 2007 01:34:02 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: <0491A255-404B-4802-851C-43F4691C19E2@nordahl.net> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: freebsd-stable@freebsd.org From: Frode Nordahl Date: Sat, 6 Jan 2007 01:34:02 +0100 X-Mailer: Apple Mail (2.752.3) Subject: Livelock in 6.2-RC1 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, 06 Jan 2007 01:00:09 -0000 Hello colleagues, I am experiencing a rare livelock on four of my backend mail servers running 6.1-STABLE, 6.2-BETA2 and 6.2-RC1. They are running OpenLDAP slapd, postfix and UW-IMAPD. The servers can run for months without any problem, but nevertheless I have experienced this problem on multiple versions and different hardware configurations about 5 times since september / october 2006. Server is responding to pings, but all other activity halts. On one occasion when one of the servers displayed this behaviour it managed to recover from the situation by itself after being gone for 20-30 minutes. Typical hardware configuration: CPU 2x Xeon 3.06GHz or 1x Core2Duo 2.00GHz (SMP) RAM 4 GB RAM DISK Intel SRCU42X (amr) or Dell PERC 5/i (mfi) Kernel config: include GENERIC options KDB # Enable kernel debugger support. options BREAK_TO_DEBUGGER options DDB # Support DDB. options GDB # Support remote GDB. options QUOTA options SMP On the last crash i collected the following info from DDB: db> tr Tracing pid 11 tid 100005 td 0xc8f90780 kdb_enter(c092f08b) at kdb_enter+0x2b siointr1(c9120800) at siointr1+0xce siointr(c9120800) at siointr+0x5e intr_execute_handlers(c8f864c8,e7b14c94,4,e7b14cd8,c0889503,...) at intr_execute_handlers+0xe1 lapic_handle_intr(3d) at lapic_handle_intr+0x2e Xapic_isr1() at Xapic_isr1+0x33 --- interrupt, eip = 0xc0b5b0e5, esp = 0xe7b14cd8, ebp = 0xe7b14cd8 --- acpi_cpu_c1(0,0,e7b14cf8,c8f90780,1,...) at acpi_cpu_c1+0x5 acpi_cpu_idle(e7b14d10,c066a779,c8f8fa78,c066a6e4,e7b14d24,...) at acpi_cpu_idle+0x152 cpu_idle(c8f8fa78,c066a6e4,e7b14d24,c066a465,0,...) at cpu_idle+0x28 idle_proc(0,e7b14d38) at idle_proc+0x95 fork_exit(c066a6e4,0,e7b14d38) at fork_exit+0x71 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xe7b14d6c, ebp = 0 --- db> show lockedbufs buf at 0xdd08cbd0 b_flags = 0x20000000 b_error = 0, b_bufsize = 16384, b_bcount = 16384, b_resid = 0 b_bufobj = (0xc937ed80), b_data = 0xdea14000, b_blkno = 14386688 b_npages = 4, pages(OBJ, IDX, PA): (0xc1045210, 0x1b70c0, 0xdbe35000), (0xc1045210, 0x1b70c1, 0xc17d6000),(0xc1045210, 0x1b70c2, 0x582d7000), (0xc1045210, 0x1b70c3, 0x84498000) I have a crashdump or two available for further investigation. -- Frode Nordahl From owner-freebsd-stable@FreeBSD.ORG Sat Jan 6 05:14:41 2007 Return-Path: X-Original-To: stable@freebsd.org 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 A17F316A407; Sat, 6 Jan 2007 05:14:41 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 4ADB713C44B; Sat, 6 Jan 2007 05:14:39 +0000 (UTC) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by smarthost1.sentex.ca (8.13.6/8.13.6) with ESMTP id l064mGt8000387; Fri, 5 Jan 2007 23:48:16 -0500 (EST) (envelope-from mike@sentex.net) Received: from mdt-xp.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.13.6/8.13.3) with ESMTP id l064mE1t007611 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 5 Jan 2007 23:48:15 -0500 (EST) (envelope-from mike@sentex.net) Message-Id: <200701060448.l064mE1t007611@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 05 Jan 2007 23:50:23 -0500 To: Eugene Grosbein , performance@freebsd.org From: Mike Tancsa In-Reply-To: <20070105174350.GA21615@svzserv.kemerovo.su> References: <20070105174350.GA21615@svzserv.kemerovo.su> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: ClamAV version 0.88.3, clamav-milter version 0.88.3 on clamscanner2 X-Virus-Status: Clean Cc: stable@freebsd.org Subject: Re: benchmark 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, 06 Jan 2007 05:14:41 -0000 At 12:43 PM 1/5/2007, Eugene Grosbein wrote: >Hi! > >I'm trying to meashure network throughput between two 6.2-PRERELEASE boxes, >basically get maximim IP packets per second transmitted/received. Try /usr/src/tools/tools/netrate/ I did some tests with the results at http://www.tancsa.com/blast.html ---Mike From owner-freebsd-stable@FreeBSD.ORG Sat Jan 6 07:19:50 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org 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 9A54916A403 for ; Sat, 6 Jan 2007 07:19:50 +0000 (UTC) (envelope-from scrappy@freebsd.org) Received: from hub.org (hub.org [200.46.204.220]) by mx1.freebsd.org (Postfix) with ESMTP id 4E63E13C441 for ; Sat, 6 Jan 2007 07:19:50 +0000 (UTC) (envelope-from scrappy@freebsd.org) Received: from localhost (unknown [200.46.204.187]) by hub.org (Postfix) with ESMTP id 0C3B1118B421 for ; Sat, 6 Jan 2007 03:19:42 -0400 (AST) Received: from hub.org ([200.46.204.220]) by localhost (mx1.hub.org [200.46.204.187]) (amavisd-new, port 10024) with ESMTP id 35428-06 for ; Sat, 6 Jan 2007 03:19:41 -0400 (AST) Received: from ganymede.hub.org (blk-137-79-174.eastlink.ca [24.137.79.174]) by hub.org (Postfix) with ESMTP id 66BC0118B417 for ; Sat, 6 Jan 2007 03:19:41 -0400 (AST) Received: from localhost (localhost [127.0.0.1]) by ganymede.hub.org (Postfix) with ESMTP id 1DAD13A76A for ; Sat, 6 Jan 2007 03:19:49 -0400 (AST) Date: Sat, 06 Jan 2007 03:19:47 -0400 From: "Marc G. Fournier" To: freebsd-stable@freebsd.org Message-ID: <8FF1D577DF1087259D6F71E0@ganymede.hub.org> X-Mailer: Mulberry/4.0.6 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Subject: Fatal trap 12: page fault while in kernel mode 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, 06 Jan 2007 07:19:50 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Just had the following happen on a FreeBSD 6.2-PRERELEASE #7: Sun Dec 17=20 01:28:52 AST 2006 system ... amd64, HP Proliant, 6G of RAM ... have core if=20 there is information that I can provide out of it ... Fatal trap 12: page fault while in kernel mode cpuid =3D 0; apic id =3D 00 fault virtual address =3D 0x18c fault code =3D supervisor read, page not present instruction pointer =3D 0x8:0xffffffff801f9053 stack pointer =3D 0x10:0xffffffffb5c78b30 frame pointer =3D 0x10:0xffffffffb5c78b60 code segment =3D base 0x0, limit 0xfffff, type 0x1b =3D DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags =3D resume, IOPL =3D 0 current process =3D 5 (thread taskq) trap number =3D 12 panic: page fault cpuid =3D 0 Uptime: 8d22h25m40s (kgdb) where #0 doadump () at pcpu.h:172 #1 0xffffffff80203955 in boot (howto=3D260) at=20 /usr/src/sys/kern/kern_shutdown.c:409 #2 0xffffffff80204065 in panic (fmt=3D0xffffff019b667720=20 "X\223f\233\001=C3=BF=C3=BF=C3=BF\020=C2=B5c\233\001=C3=BF=C3=BF=C3=BF") at=20 /usr/src/sys/kern/kern_shutdown.c:565 #3 0xffffffff803287a6 in trap_fatal (frame=3D0xc, eva=3D18446742981100074784) = at=20 /usr/src/sys/amd64/amd64/trap.c:660 #4 0xffffffff80328cd8 in trap (frame=3D {tf_rdi =3D 112, tf_rsi =3D -1092609476832, tf_rdx =3D 6, tf_rcx =3D = 3221225730,=20 tf_r8 =3D -1245213424, tf_r9 =3D -1092609476832, tf_rax =3D 1, tf_rbx =3D=20 - -1096874331952, tf_rbp =3D -1245213856, tf_r10 =3D -2142258536, tf_r11 =3D 0, = tf_r12=20 =3D 4, tf_r13 =3D -1092609476832, tf_r14 =3D 4, tf_r15 =3D 1, tf_trapno =3D 12, = tf_addr =3D=20 396, tf_flags =3D -2145197496, tf_err =3D 0, tf_rip =3D -2145415085, tf_cs =3D = 8,=20 tf_rflags =3D 65538, tf_rsp =3D -1245213888, tf_ss =3D 16}) at=20 /usr/src/sys/amd64/amd64/trap.c:238 #5 0xffffffff80313c6b in calltrap () at=20 /usr/src/sys/amd64/amd64/exception.S:168 #6 0xffffffff801f9053 in _mtx_lock_sleep (m=3D0xffffff009d31f0d0,=20 tid=3D18446742981100074784, opts=3D6, file=3D0xc0000102
, line=3D-1245213424) at /usr/src/sys/kern/kern_mutex.c:546 #7 0xffffffff8025b1ac in unp_gc (arg=3D0x70, pending=3D-1687783648) at=20 /usr/src/sys/kern/uipc_usrreq.c:1714 #8 0xffffffff8022c314 in taskqueue_run (queue=3D0xffffff0000844800) at=20 /usr/src/sys/kern/subr_taskqueue.c:257 #9 0xffffffff8022d0e7 in taskqueue_thread_loop (arg=3D0x70) at=20 /usr/src/sys/kern/subr_taskqueue.c:376 #10 0xffffffff801e7b76 in fork_exit (callout=3D0xffffffff8022d060=20 , arg=3D0xffffffff805030d0, frame=3D0xffffffffb5c78c50) = at=20 /usr/src/sys/kern/kern_fork.c:821 #11 0xffffffff80313fce in fork_trampoline () at=20 /usr/src/sys/amd64/amd64/exception.S:394 #12 0x0000000000000000 in ?? () #13 0x0000000000000000 in ?? () #14 0x0000000000000001 in ?? () #15 0x0000000000000000 in ?? () #16 0x0000000000000000 in ?? () #17 0x0000000000000000 in ?? () #18 0x0000000000000000 in ?? () #19 0x0000000000000000 in ?? () #20 0x0000000000000000 in ?? () #21 0x0000000000000000 in ?? () #22 0x0000000000000000 in ?? () #23 0x0000000000000000 in ?? () #24 0x0000000000000000 in ?? () #25 0x0000000000000000 in ?? () #26 0x0000000000000000 in ?? () #27 0x0000000000000000 in ?? () #28 0x0000000000000000 in ?? () #29 0x0000000000000000 in ?? () #30 0x0000000000000000 in ?? () #31 0x0000000000000000 in ?? () #32 0x0000000000000000 in ?? () #33 0x0000000000000000 in ?? () #34 0x0000000000000000 in ?? () #35 0x0000000000000000 in ?? () #36 0x0000000000000000 in ?? () #37 0x0000000000000000 in ?? () #38 0x0000000000000000 in ?? () #39 0x0000000000000000 in ?? () #40 0x0000000000000000 in ?? () #41 0x0000000000000000 in ?? () #42 0x0000000000000000 in ?? () #43 0x0000000000000000 in ?? () #44 0x00000000006bc000 in ?? () #45 0xffffffff805054c0 in turnstile_chains () #46 0x0000000000000001 in ?? () #47 0xffffff019b669358 in ?? () #48 0xffffff008d5bc720 in ?? () #49 0xffffffffb5c78aa0 in ?? () #50 0xffffffffb5c78a78 in ?? () #51 0xffffff019b667720 in ?? () #52 0xffffffff8021a69f in sched_switch (td=3D0xffffffff805030d0,=20 newtd=3D0xffffffff8022d060, flags=3D0) at /usr/src/sys/kern/sched_4bsd.c:973 Previous frame inner to this frame (corrupt stack?) - ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . scrappy@hub.org MSN . scrappy@hub.org Yahoo . yscrappy Skype: hub.org ICQ . 7615664 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFFn02U4QvfyHIvDvMRArpcAJ9O14aZsWCJ97wQeLKvxKd9DW6bTQCfWSMm nm/uEw6zK2jBPXN6/0OTC34=3D =3D4IGH -----END PGP SIGNATURE----- From owner-freebsd-stable@FreeBSD.ORG Sat Jan 6 08:46:04 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org 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 E172C16A407 for ; Sat, 6 Jan 2007 08:46:04 +0000 (UTC) (envelope-from robertsg@westnet.com.au) Received: from vscan02.westnet.com.au (vscan02.westnet.com.au [203.10.1.132]) by mx1.freebsd.org (Postfix) with ESMTP id 3747513C459 for ; Sat, 6 Jan 2007 08:46:04 +0000 (UTC) (envelope-from robertsg@westnet.com.au) Received: from localhost (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 89A4111CCB4 for ; Sat, 6 Jan 2007 17:14:46 +0900 (WST) Received: from vscan02.westnet.com.au ([127.0.0.1]) by localhost (vscan02.westnet.com.au [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12130-06 for ; Sat, 6 Jan 2007 16:14:46 +0800 (WST) Received: from dsl-202-173-129-2.nsw.westnet.com.au (dsl-202-173-129-2.nsw.westnet.com.au [202.173.129.2]) by vscan02.westnet.com.au (Postfix) with ESMTP id F0EA311B299 for ; Sat, 6 Jan 2007 17:14:45 +0900 (WST) From: Geoff Roberts Organization: Strategic I.C.T. Pty Ltd To: freebsd-stable@freebsd.org Date: Sat, 6 Jan 2007 19:14:41 +1100 User-Agent: KMail/1.8 MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="Boundary-00=_xp1nFR22c0MewHj" Message-Id: <200701061914.41528.robertsg@westnet.com.au> Subject: System freeze on 6.1/2 when running makeworld and dump X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: robertsg@westnet.com.au List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jan 2007 08:46:05 -0000 --Boundary-00=_xp1nFR22c0MewHj Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi, I can consistantly make my system freeze when building makeworld and running dump at the same time. The system actually locks - I have to hit the reset switch to bring the system back to life. I also get a core dump on current. I have mounted the file systems as follows: / /tmp /usr /usr/obj /var The freeze always happens when using dump on the /usr mount point. Most of the writes are going to /usr/obj. I have tried both SCSI hardware and IDE. I have completely swapped RAM (a few times) so I am only as confident as you can be it is not a hardware issue :) I've also tried various CPU burn and RAM testers to make sure there is no issue there. I can also duplicate the issue dumping to /dev/null as opposed to an actual tape drive through the SCSI card. If I run dump without doing a makeworld in the background the system backs up fine. If I run buildworld by itself without dump all is fine as well. Below is some information about my system configuration: GENERIC 6.1 or 6.2 kernel (or current without SMP) (note in the dmesg output it does not say GENERIC, but the CUSTOM config is an exact copy of GENERIC). I can freeze the system using either /dev/null or /dev/nsa0 below: dump -C 32 -0 -a -L -u -f /dev/null /usr The freeze does not happen till dump starts to write the files. Has anyone else experienced this? Kind regards, Geoff --Boundary-00=_xp1nFR22c0MewHj Content-Type: text/plain; charset="us-ascii"; name="dmesg.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="dmesg.txt" Copyright (c) 1992-2006 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 6.1-RELEASE #0: Sun May 7 04:32:43 UTC 2006 root@opus.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: AMD Athlon(tm) Processor (908.09-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x642 Stepping = 2 Features=0x183f9ff AMD Features=0xc0440800,MMX+,3DNow+,3DNow> real memory = 1073659904 (1023 MB) avail memory = 1041719296 (993 MB) kbd1 at kbdmux0 acpi0: on motherboard acpi0: Power Button (fixed) Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0xe408-0xe40b on acpi0 cpu0: on acpi0 acpi_throttle0: on cpu0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 agp0: mem 0xe7800000-0xe7bfffff at device 0.0 on pci0 pcib1: at device 1.0 on pci0 pci1: on pcib1 pci1: at device 0.0 (no driver attached) isab0: at device 4.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xd800-0xd80f at device 4.1 on pci0 ata0: on atapci0 ata1: on atapci0 uhci0: port 0xd400-0xd41f irq 7 at device 4.2 on pci0 uhci0: [GIANT-LOCKED] usb0: on uhci0 usb0: USB revision 1.0 uhub0: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhci1: port 0xd000-0xd01f irq 7 at device 4.3 on pci0 uhci1: [GIANT-LOCKED] usb1: on uhci1 usb1: USB revision 1.0 uhub1: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered pci0: at device 4.4 (no driver attached) pcib2: at device 10.0 on pci0 pci2: on pcib2 amr0: mem 0xe3000000-0xe300ffff irq 3 at device 10.1 on pci0 amr0: Firmware GH8E, BIOS 1.46, 16MB RAM fxp0: port 0x9800-0x983f mem 0xe0800000-0xe0800fff,0xe0000000-0xe001ffff irq 11 at device 12.0 on pci0 miibus0: on fxp0 inphy0: on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fxp0: Ethernet address: 00:02:b3:b7:14:52 atapci1: port 0x9400-0x9407,0x9000-0x9003,0x8800-0x8807,0x8400-0x8403,0x8000-0x803f mem 0xdf800000-0xdf81ffff irq 10 at device 17.0 on pci0 ata2: on atapci1 ata3: on atapci1 fdc0: port 0x3f2-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: [FAST] fd0: <1440-KB 3.5" drive> on fdc0 drive 0 sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model IntelliMouse, device ID 3 pmtimer0 on isa0 orm0: at iomem 0xc0000-0xcafff,0xd0000-0xd17ff on isa0 ppc0: parallel port not found. sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 uhub2: ALCOR Generic USB Hub, class 9/0, rev 1.10/1.00, addr 2 uhub2: 4 ports with 4 removable, self powered Timecounter "TSC" frequency 908090887 Hz quality 800 Timecounters tick every 1.000 msec acd0: CDRW at ata1-master PIO4 amrd0: on amr0 amrd0: 21552MB (44138496 sectors) RAID 0 (optimal) Trying to mount root from ufs:/dev/amrd0s1a fxp0: link state changed to UP --Boundary-00=_xp1nFR22c0MewHj Content-Type: text/plain; charset="us-ascii"; name="mount.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="mount.txt" /dev/ad0s1a on / (ufs, local, soft-updates) devfs on /dev (devfs, local) /dev/ad0s1e on /tmp (ufs, local, soft-updates) /dev/ad0s2e on /usr (ufs, local, soft-updates) /dev/ad0s2d on /usr/obj (ufs, local, soft-updates) /dev/ad0s1d on /var (ufs, local, soft-updates) --Boundary-00=_xp1nFR22c0MewHj-- From owner-freebsd-stable@FreeBSD.ORG Sat Jan 6 11:44:31 2007 Return-Path: X-Original-To: stable@FreeBSD.org 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 C2FBD16A407; Sat, 6 Jan 2007 11:44:31 +0000 (UTC) (envelope-from ceri@submonkey.net) Received: from shrike.submonkey.net (cpc2-cdif2-0-0-cust107.cdif.cable.ntl.com [81.104.168.108]) by mx1.freebsd.org (Postfix) with ESMTP id 7BA1F13C465; Sat, 6 Jan 2007 11:44:31 +0000 (UTC) (envelope-from ceri@submonkey.net) Received: from ceri by shrike.submonkey.net with local (Exim 4.64 (FreeBSD)) (envelope-from ) id 1H39yQ-000Jnc-Fh; Sat, 06 Jan 2007 11:44:30 +0000 Date: Sat, 6 Jan 2007 11:44:30 +0000 From: Ceri Davies To: Robert Watson Message-ID: <20070106114430.GF7088@submonkey.net> References: <20070105111954.GA51511@submonkey.net> <20070105120539.H46119@fledge.watson.org> <20070105131528.GB7088@submonkey.net> <20070105133028.F98541@fledge.watson.org> <20070105150857.GC7088@submonkey.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="cYtjc4pxslFTELvY" Content-Disposition: inline In-Reply-To: <20070105150857.GC7088@submonkey.net> X-PGP: finger ceri@FreeBSD.org User-Agent: Mutt/1.5.13 (2006-08-11) Sender: Ceri Davies Cc: stable@FreeBSD.org Subject: Re: (audit?) Panic in 6.2-PRERELEASE 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, 06 Jan 2007 11:44:31 -0000 --cYtjc4pxslFTELvY Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jan 05, 2007 at 03:08:57PM +0000, Ceri Davies wrote: > > How reproduceable is this? >=20 > So far it's happened this morning and yesterday morning. I haven't seen > it before that. I don't know the cause so I can't reproduce it at will, > but the logs don't give any indication. Chances are that it will happen > again tomorrow, but we'll see. This prediction didn't bear out; no panic today. Ceri --=20 That must be wonderful! I don't understand it at all. -- Moliere --cYtjc4pxslFTELvY Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFFn4ueocfcwTS3JF8RAgNPAJwPH0pupzcMddZ6dhZESMoXSr7xHgCfZdAr pww7YHCrE96xPKOAvgzd2Zw= =Kic4 -----END PGP SIGNATURE----- --cYtjc4pxslFTELvY-- From owner-freebsd-stable@FreeBSD.ORG Sat Jan 6 12:01:51 2007 Return-Path: X-Original-To: stable@FreeBSD.org 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 D426016A412 for ; Sat, 6 Jan 2007 12:01:51 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id AB55413C46A for ; Sat, 6 Jan 2007 12:01:51 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 1630047911; Sat, 6 Jan 2007 07:01:51 -0500 (EST) Date: Sat, 6 Jan 2007 12:01:51 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Ceri Davies In-Reply-To: <20070105150857.GC7088@submonkey.net> Message-ID: <20070106120040.N46119@fledge.watson.org> References: <20070105111954.GA51511@submonkey.net> <20070105120539.H46119@fledge.watson.org> <20070105131528.GB7088@submonkey.net> <20070105133028.F98541@fledge.watson.org> <20070105150857.GC7088@submonkey.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: stable@FreeBSD.org Subject: Re: (audit?) Panic in 6.2-PRERELEASE 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, 06 Jan 2007 12:01:51 -0000 On Fri, 5 Jan 2007, Ceri Davies wrote: > On Fri, Jan 05, 2007 at 01:34:04PM +0000, Robert Watson wrote: >> >> On Fri, 5 Jan 2007, Ceri Davies wrote: >> >>>> Much as I would love to trust the contents of ub there, I suspect they >>>> can't be trusted. Could you print the contents of *fp in kern_fstat() in >>>> both of those stacks? I'd particularly like to know the value of >>>> fp->f_type, and then depending on the type, possibly the contents of >>>> *(struct vnode *)fp->f_vnode for DTYPE_VNODE/TYPE_FIFO or *(struct socket >>>> *)fp->f_data in the case of DTYPE_SOCKET. >>> >>> Can you tell me how to get at *fp given that the stack trace shows fstat() >>> and not kern_fstat()? Sorry if I'm being dumb but I don't know how to >>> step into the kern_fstat() call from fstat(). >> >> It could be that the stack is hosed losing the frame, or maybe it's inlined >> (more likely the former I think, as kern_fstat() is a symbol used elsewhere >> in the kernel). The best bet may be to use the file descriptor number >> (uap->fd) to pull the struct file reference out of the process. Something >> on the order of (td->td_proc->p_fd->fd_ofiles[fd]) should return the right >> struct file *. > > OK, got it. They're both sockets, data in the attachments. > >> How reproduceable is this? > > So far it's happened this morning and yesterday morning. I haven't seen it > before that. I don't know the cause so I can't reproduce it at will, but > the logs don't give any indication. Chances are that it will happen again > tomorrow, but we'll see. Hmm. It looks like you printf *(td->td_proc->p_fd->fd_ofiles) without the array index. Could you repeat that, but with the array index -- i.e., td->td_proc->p_fd->fd_ofiles[uap->fd]? Also, it would probably be useful to print uap->fd. Right now you're printing stdin (index 0), but if the index is non-0, we want a different file. thanks, Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-stable@FreeBSD.ORG Sat Jan 6 13:25:47 2007 Return-Path: X-Original-To: stable@FreeBSD.org 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 6A43416A403; Sat, 6 Jan 2007 13:25:47 +0000 (UTC) (envelope-from ceri@submonkey.net) Received: from shrike.submonkey.net (cpc2-cdif2-0-0-cust107.cdif.cable.ntl.com [81.104.168.108]) by mx1.freebsd.org (Postfix) with ESMTP id 0997413C428; Sat, 6 Jan 2007 13:25:44 +0000 (UTC) (envelope-from ceri@submonkey.net) Received: from ceri by shrike.submonkey.net with local (Exim 4.64 (FreeBSD)) (envelope-from ) id 1H3BYL-000JnI-6p; Sat, 06 Jan 2007 13:25:41 +0000 Date: Sat, 6 Jan 2007 13:25:41 +0000 From: Ceri Davies To: Robert Watson Message-ID: <20070106132540.GG7088@submonkey.net> References: <20070105111954.GA51511@submonkey.net> <20070105120539.H46119@fledge.watson.org> <20070105131528.GB7088@submonkey.net> <20070105133028.F98541@fledge.watson.org> <20070105150857.GC7088@submonkey.net> <20070106120040.N46119@fledge.watson.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="fwqqG+mf3f7vyBCB" Content-Disposition: inline In-Reply-To: <20070106120040.N46119@fledge.watson.org> X-PGP: finger ceri@FreeBSD.org User-Agent: Mutt/1.5.13 (2006-08-11) Sender: Ceri Davies Cc: stable@FreeBSD.org Subject: Re: (audit?) Panic in 6.2-PRERELEASE 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, 06 Jan 2007 13:25:47 -0000 --fwqqG+mf3f7vyBCB Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jan 06, 2007 at 12:01:51PM +0000, Robert Watson wrote: > On Fri, 5 Jan 2007, Ceri Davies wrote: >=20 > >On Fri, Jan 05, 2007 at 01:34:04PM +0000, Robert Watson wrote: > >> > >>On Fri, 5 Jan 2007, Ceri Davies wrote: > >> > >>>>Much as I would love to trust the contents of ub there, I suspect the= y=20 > >>>>can't be trusted. Could you print the contents of *fp in kern_fstat(= )=20 > >>>>in both of those stacks? I'd particularly like to know the value of= =20 > >>>>fp->f_type, and then depending on the type, possibly the contents of= =20 > >>>>*(struct vnode *)fp->f_vnode for DTYPE_VNODE/TYPE_FIFO or *(struct=20 > >>>>socket *)fp->f_data in the case of DTYPE_SOCKET. > >>> > >>>Can you tell me how to get at *fp given that the stack trace shows=20 > >>>fstat() and not kern_fstat()? Sorry if I'm being dumb but I don't kno= w=20 > >>>how to step into the kern_fstat() call from fstat(). > >> > >>It could be that the stack is hosed losing the frame, or maybe it's=20 > >>inlined (more likely the former I think, as kern_fstat() is a symbol us= ed=20 > >>elsewhere in the kernel). The best bet may be to use the file descript= or=20 > >>number (uap->fd) to pull the struct file reference out of the process. = =20 > >>Something on the order of (td->td_proc->p_fd->fd_ofiles[fd]) should=20 > >>return the right struct file *. > > > >OK, got it. They're both sockets, data in the attachments. > > > >>How reproduceable is this? > > > >So far it's happened this morning and yesterday morning. I haven't seen= =20 > >it before that. I don't know the cause so I can't reproduce it at will,= =20 > >but the logs don't give any indication. Chances are that it will happen= =20 > >again tomorrow, but we'll see. >=20 > Hmm. It looks like you printf *(td->td_proc->p_fd->fd_ofiles) without th= e=20 > array index. Could you repeat that, but with the array index -- i.e.,=20 > td->td_proc->p_fd->fd_ofiles[uap->fd]? Also, it would probably be useful= =20 > to print uap->fd. Right now you're printing stdin (index 0), but if the= =20 > index is non-0, we want a different file. Very tactfully put :) Sorry about that. None of the uap->fd's seem to be valid. In the first case, uap->fd is way too high for the length of fd_ofiles, which only has 21 elements: (kgdb) up 8 #8 0xc04c470d in fstat (td=3D0xc2eeb180, uap=3D0xd610dc74) at /usr/src/sys= /kern/kern_descrip.c:1075 1075 error =3D kern_fstat(td, uap->fd, &ub); (kgdb) p uap->fd $1 =3D 89 (kgdb) p *td->td_proc->p_fd->fd_ofiles[uap->fd] Cannot access memory at address 0x0 In the second, uap->fd is nonsense: (kgdb) up 8 #8 0xc04c470d in fstat (td=3D0xc3109300, uap=3D0xd617ec74) at /usr/src/sys= /kern/kern_descrip.c:1075 1075 error =3D kern_fstat(td, uap->fd, &ub); (kgdb) p uap->fd $1 =3D -1023449232 (kgdb) Ceri --=20 That must be wonderful! I don't understand it at all. -- Moliere --fwqqG+mf3f7vyBCB Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFFn6NUocfcwTS3JF8RAuGMAJ9NSURkDLMAtJmidmVcDCbseAql5gCdEZ3M VvijBqCGdsYmBlTpQ7hOIKI= =UgOl -----END PGP SIGNATURE----- --fwqqG+mf3f7vyBCB-- From owner-freebsd-stable@FreeBSD.ORG Sat Jan 6 13:44:27 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org 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 F34D916A403 for ; Sat, 6 Jan 2007 13:44:26 +0000 (UTC) (envelope-from aw1@stade.co.uk) Received: from lon-mail-1.gradwell.net (lon-mail-1.gradwell.net [193.111.201.125]) by mx1.freebsd.org (Postfix) with ESMTP id 5A78613C428 for ; Sat, 6 Jan 2007 13:44:26 +0000 (UTC) (envelope-from aw1@stade.co.uk) Received: from alsager-adsl.stade.co.uk ([81.6.222.119] helo=access2.hanley.stade.co.uk country=GB) by lon-mail-1.gradwell.net with esmtp (Gradwell gwh-smtpd 1.238) id 459f9e2e.b3f5.6c for freebsd-stable@freebsd.org; Sat, 6 Jan 2007 13:03:42 +0000 (envelope-sender ) Received: from steerpike.hanley.stade.co.uk (steerpike [192.168.1.10]) by access2.hanley.stade.co.uk (8.13.8/8.13.8) with ESMTP id l06D3ffT020551 for ; Sat, 6 Jan 2007 13:03:41 GMT (envelope-from aw1@steerpike.hanley.stade.co.uk) Received: from steerpike.hanley.stade.co.uk (localhost [127.0.0.1]) by steerpike.hanley.stade.co.uk (8.13.8/8.13.8) with ESMTP id l06D3dTt055959 for ; Sat, 6 Jan 2007 13:03:39 GMT (envelope-from aw1@steerpike.hanley.stade.co.uk) Received: (from aw1@localhost) by steerpike.hanley.stade.co.uk (8.13.8/8.13.8/Submit) id l06D3cxk055958 for freebsd-stable@freebsd.org; Sat, 6 Jan 2007 13:03:38 GMT (envelope-from aw1) Date: Sat, 6 Jan 2007 13:03:38 +0000 From: Adrian Wontroba To: freebsd-stable@freebsd.org Message-ID: <20070106130338.GA55798@steerpike.hanley.stade.co.uk> Mail-Followup-To: Adrian Wontroba , freebsd-stable@freebsd.org References: <200701061914.41528.robertsg@westnet.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200701061914.41528.robertsg@westnet.com.au> User-Agent: Mutt/1.4.2.2i X-Operating-System: FreeBSD 6.2-PRERELEASE Organization: Oh dear, I've joined one again. X-Virus-Scanned: ClamAV 0.88.6/2416/Sat Jan 6 04:54:14 2007 on access2.hanley.stade.co.uk X-Virus-Scanned: ClamAV 0.88.6/2416/Sat Jan 6 04:54:14 2007 on steerpike.hanley.stade.co.uk X-Virus-Status: Clean Subject: Re: System freeze on 6.1/2 when running makeworld and dump X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: aw1@stade.co.uk List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jan 2007 13:44:27 -0000 On Sat, Jan 06, 2007 at 07:14:41PM +1100, Geoff Roberts wrote: > I can consistantly make my system freeze when building makeworld and > running dump at the same time. The system actually locks - I have to > hit the reset switch to bring the system back to life. I have an old SMP machine at work which sometimes does something similar during its daily housekeeping, where Apache and Nagios are bounced and a small MySQL database dumped. It sometimes appears to hang during the database dump. The debugger shows many processes waiting for UFS. I suspect that the problem starts several minutes earlier. All of the following help to keep the problem away: Upgrading from a several months old 5-STABLE to 6-STABLE. Inserting 60 second delays at various points. Disabling SMP. No core dump available (Mylex disk controller). My next diagnostic step will be a serial console. -- Adrian Wontroba The biggest mistake you can make is to believe that you are working for someone else. From owner-freebsd-stable@FreeBSD.ORG Sat Jan 6 14:25:30 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org 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 B541A16A492 for ; Sat, 6 Jan 2007 14:25:30 +0000 (UTC) (envelope-from zkolic@sbb.co.yu) Received: from smtp1.sbb.co.yu (smtp1.sbb.co.yu [82.117.194.21]) by mx1.freebsd.org (Postfix) with ESMTP id 2FAF813C469 for ; Sat, 6 Jan 2007 14:25:29 +0000 (UTC) (envelope-from zkolic@sbb.co.yu) Received: from faust.net (cable-89-216-167-189.dynamic.sbb.co.yu [89.216.167.189]) by smtp1.sbb.co.yu (8.13.7/8.13.7) with ESMTP id l06EEaLb029117 for ; Sat, 6 Jan 2007 15:14:36 +0100 Received: by faust.net (Postfix, from userid 1001) id 945191704B; Sat, 6 Jan 2007 15:15:05 +0100 (CET) Date: Sat, 6 Jan 2007 15:15:05 +0100 From: Zoran Kolic To: freebsd-stable@freebsd.org Message-ID: <20070106141505.GA638@faust.net> References: <20070106120048.EBB4016A62D@hub.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070106120048.EBB4016A62D@hub.freebsd.org> X-SMTP-Vilter-Version: 1.3.2 X-SBB-Virus-Status: clean X-SBB-Spam-Score: 0.7 X-SBB-Spam-Level: X Subject: Re: Shutdown problem "Stray IRQ9" 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, 06 Jan 2007 14:25:30 -0000 > In comparison, you can search for "stray irq7" and see that > others have seen this message on certain boards where the > LPT/printer port has been disabled in the BIOS, but lpt > support is enabled in FreeBSD. (What I'm trying to say is > that the "stray irq" stuff stems from what I described in > the above paragraph. Hm! My Compaq laptop 9020 has no paralel port. In the kernel I removed all lines regarding it. I still have irq7 messages in console. They are benign, no hang. Intel; could be some controler wants to "hallo, I'm here!". Some BIOSes need full atention. If original poster has motherboard book, he could tweak over options. I recall an issue prior to remove apic on nforce3 mobo. Zoran From owner-freebsd-stable@FreeBSD.ORG Sat Jan 6 16:22:24 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org 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 48C1516A412 for ; Sat, 6 Jan 2007 16:22:24 +0000 (UTC) (envelope-from vseifert@gmx.de) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.freebsd.org (Postfix) with SMTP id 921CD13C442 for ; Sat, 6 Jan 2007 16:22:23 +0000 (UTC) (envelope-from vseifert@gmx.de) Received: (qmail invoked by alias); 06 Jan 2007 15:55:41 -0000 Received: from p54A763E0.dip.t-dialin.net (EHLO [84.167.99.224]) [84.167.99.224] by mail.gmx.net (mp007) with SMTP; 06 Jan 2007 16:55:41 +0100 X-Authenticated: #10682956 Message-ID: <459FC68A.3040509@gmx.de> Date: Sat, 06 Jan 2007 16:55:54 +0100 From: Viktor Seifert User-Agent: Thunderbird 1.5.0.9 (X11/20070103) MIME-Version: 1.0 To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Subject: Odd GNOME login behaviour 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, 06 Jan 2007 16:22:24 -0000 Hi, all. A few days ago I intstalled freebsd 6.1 on my laptop(Samsung X20). I am tracking RELENG_6. I updated all the ports and with it GNOME to 2.16. Now I am experiencing some odd behaviour when logging in into GNOME. gdm starts up ok and I can type my username and password. Than the splask shows up but hangs after displaying "Window Manager". But if I, before logging in, connect to the internet by assigning an adress to bge0 and adding a default route, the login proceeds smoothly. I actually have to connected it doesn't suffice to just assign an adress and a route. I am at loss here how to track down the problem. It confuses me that GNOME needs a connection anyway. And besides: I am running freebsd on a laptop so I won't be able to provide a connection to the internet all the time. Has anybody got any ideas on what is going wrong? Regards and a happy 2007, Viktor Seifert From owner-freebsd-stable@FreeBSD.ORG Sat Jan 6 19:15:05 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org 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 ABDE816A416; Sat, 6 Jan 2007 19:15:05 +0000 (UTC) (envelope-from David.Boyd@insightbb.com) Received: from asav00.insightbb.com (gateway.insightbb.com [74.128.0.19]) by mx1.freebsd.org (Postfix) with ESMTP id 2064613C441; Sat, 6 Jan 2007 19:15:02 +0000 (UTC) (envelope-from David.Boyd@insightbb.com) Received: from 74-129-155-218.dhcp.insightbb.com (HELO sneezy) ([74.129.155.218]) by asav00.insightbb.com with SMTP; 06 Jan 2007 13:54:34 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgoXAI5/n0VKgZvaUGdsb2JhbACCYoQIhkgBASo From: "David Boyd" To: Date: Sat, 6 Jan 2007 13:54:22 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Cc: gnn@freebsd.org Subject: Panic in 6.2-RC2 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, 06 Jan 2007 19:15:05 -0000 The following panic occurs every one to three hours with 6.2-RC2. This is the same problem as kern/88472 which is still open. GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd". Unread portion of the kernel message buffer: <7>key_spddelete: no SP found. Fatal trap 12: page fault while in kernel mode fault virtual address = 0x23 fault code = supervisor read, page not present instruction pointer = 0x20:0xc074fc0c stack pointer = 0x28:0xd0a4e8f8 frame pointer = 0x28:0xd0a4e908 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 695 (isakmpd) trap number = 12 panic: page fault Uptime: 1h2m52s Dumping 255 MB (2 chunks) chunk 0: 1MB (159 pages) ... ok chunk 1: 255MB (65216 pages) 239 223 207 191 175 159 143 127 111 95 79 63 47 31 15 #0 doadump () at pcpu.h:165 165 __asm __volatile("movl %%fs:0,%0" : "=r" (td)); (kgdb) by t #0 doadump () at pcpu.h:165 #1 0xc068c76e in boot (howto=260) at /var/cvsup/usr/src/sys/kern/kern_shutdown.c:409 #2 0xc068ca04 in panic (fmt=0xc08c386a "%s") at /var/cvsup/usr/src/sys/kern/kern_shutdown.c:565 #3 0xc08690b4 in trap_fatal (frame=0xd0a4e8b8, eva=35) at /var/cvsup/usr/src/sys/i386/i386/trap.c:837 #4 0xc0868e1b in trap_pfault (frame=0xd0a4e8b8, usermode=0, eva=35) at /var/cvsup/usr/src/sys/i386/i386/trap.c:745 #5 0xc0868a59 in trap (frame= {tf_fs = -1035665400, tf_es = -1035665368, tf_ds = 40, tf_edi = 3, tf_esi = -1037761536, tf_ebp = -794498808, tf_isp = -794498844, tf_ebx = -1030032896, tf_edx = 1, tf_ecx = 1466671235, tf_eax = 3, tf_trapno = 12, tf_err = 0, tf_eip = -1066075124, tf_cs = 32, tf_eflags = 66054, tf_esp = 0, tf_ss = -1030032896}) at /var/cvsup/usr/src/sys/i386/i386/trap.c:435 #6 0xc085712a in calltrap () at /var/cvsup/usr/src/sys/i386/i386/exception.s:139 #7 0xc074fc0c in key_getsavbyspi (sah=0xc2250400, spi=1466671235) at /var/cvsup/usr/src/sys/netkey/key.c:2977 #8 0xc07527cd in key_delete (so=0xc2452164, m=0xc29af200, mhp=0xd0a4ea64) at /var/cvsup/usr/src/sys/netkey/key.c:5427 #9 0xc07548b9 in key_parse (m=0xc29af200, so=0xc2452164) at /var/cvsup/usr/src/sys/netkey/key.c:7149 #10 0xc0756081 in key_output (m=0xc29af200, so=0xc2452164) at /var/cvsup/usr/src/sys/netkey/keysock.c:119 #11 0xc07074b0 in raw_usend (so=0x576ba083, flags=0, m=0x1, nam=0x0, control=0x3, td=0xc22a6a80) at /var/cvsup/usr/src/sys/net/raw_usrreq.c:263 #12 0xc07565e7 in key_send (so=0xc2452164, flags=0, m=0xc29af200, nam=0x0, control=0x0, p=0xc22a6a80) at /var/cvsup/usr/src/sys/netkey/keysock.c:430 #13 0xc06c5863 in sosend (so=0xc2452164, addr=0x0, uio=0xc2602100, top=0xc29af200, control=0x0, flags=0, td=0xc22a6a80) at /var/cvsup/usr/src/sys/kern/uipc_socket.c:836 #14 0xc06b40ee in soo_write (fp=0x3, uio=0xc2602100, active_cred=0xc2447480, flags=0, td=0xc22a6a80) at /var/cvsup/usr/src/sys/kern/sys_socket.c:118 #15 0xc06ae7f7 in dofilewrite (td=0xc22a6a80, fd=5, fp=0xc23a2288, auio=0xc2602100, offset= ) at file.h:252 #16 0xc06ae69b in kern_writev (td=0xc22a6a80, fd=5, auio=0xc2602100) at /var/cvsup/usr/src/sys/kern/sys_generic.c:402 #17 0xc06ae644 in writev (td=0xc22a6a80, uap=0xd0a4ed04) at /var/cvsup/usr/src/sys/kern/sys_generic.c:388 #18 0xc08693cb in syscall (frame= {tf_fs = 59, tf_es = -1078001605, tf_ds = -1078001605, tf_edi = 136368064, tf_esi = -1077941328, tf_ebp = -1077941224, tf_isp = -794497692, tf_ebx = 5, tf_edx = 23, tf_ecx = 0, tf_eax = 121, tf_trapno = 0, tf_err = 2, tf_eip = 673519919, tf_cs = 51, tf_eflags = 582, tf_esp = -1077941364, tf_ss = 59}) at /var/cvsup/usr/src/sys/i386/i386/trap.c:983 #19 0xc085717f in Xint0x80_syscall () at /var/cvsup/usr/src/sys/i386/i386/exception.s:200 #20 0x00000033 in ?? () (kgdb) q The following messages are logged just before the panic. Jan 6 00:34:28 vpn-gateway2 isakmpd[452]: isakmpd: quick mode done: src: xxx.xxx.xxx.xxx dst: yyy.yyy.yyy.yyy Jan 6 00:34:28 vpn-gateway2 isakmpd[452]: pf_key_v2_set_spi: ADD: Invalid argument The other end of the connection is reported to be "Cisco-based". From owner-freebsd-stable@FreeBSD.ORG Sat Jan 6 21:02:13 2007 Return-Path: X-Original-To: stable@freebsd.org 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 5934B16A403 for ; Sat, 6 Jan 2007 21:02:13 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from turion.vk2pj.dyndns.org (c220-239-3-125.belrs4.nsw.optusnet.com.au [220.239.3.125]) by mx1.freebsd.org (Postfix) with ESMTP id C30FE13C468 for ; Sat, 6 Jan 2007 21:02:12 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from turion.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by turion.vk2pj.dyndns.org (8.13.8/8.13.8) with ESMTP id l06L2Ben015177 for ; Sun, 7 Jan 2007 08:02:11 +1100 (EST) (envelope-from peter@turion.vk2pj.dyndns.org) Received: (from peter@localhost) by turion.vk2pj.dyndns.org (8.13.8/8.13.8/Submit) id l06L2BWU015176 for stable@freebsd.org; Sun, 7 Jan 2007 08:02:11 +1100 (EST) (envelope-from peter) Date: Sun, 7 Jan 2007 08:02:11 +1100 From: Peter Jeremy To: stable@freebsd.org Message-ID: <20070106210211.GF839@turion.vk2pj.dyndns.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="/QKKmeG/X/bPShih" Content-Disposition: inline X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.13 (2006-08-11) Cc: Subject: Source MAC addresses when bridge(4) used 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, 06 Jan 2007 21:02:13 -0000 --/QKKmeG/X/bPShih Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I've just noticed an number of unpexected "IP address changed MAC" messages on one of the hosts in my network. It is connected via a FreeBSD bridge to the rest of my network (there aren't enuf network ports in my son's bedroom). The configuration looks like: +---------+ +---------+ | | | | | laptop1 |---------| desktop |------> Rest of network | |dc0 tl0| |rl0 via dumb switch +---------+ +---------+ The desktop network configuration is: tl0: flags=3D8943 mtu 1500 ether 00:00:24:28:98:9a media: Ethernet autoselect (100baseTX ) status: active rl0: flags=3D8943 mtu 1500 options=3D8 inet 192.168.123.36 netmask 0xffffff00 broadcast 192.168.123.255 ether 00:20:ed:78:9c:a3 media: Ethernet autoselect (100baseTX ) status: active lo0: flags=3D8049 mtu 16384 inet 127.0.0.1 netmask 0xff000000=20 bridge0: flags=3D8043 mtu 1500 ether ca:a9:aa:1e:71:32 priority 32768 hellotime 2 fwddelay 15 maxage 20 member: tl0 flags=3D3 member: rl0 flags=3D3 laptop1 is regularly reporting that 192.168.123.36 (the IP address of the desktop) is switching between the two adapters in it: Jan 6 07:27:09 laptop1 kernel: arp: 192.168.123.36 moved from 00:00:24:28:= 98:9a to 00:20:ed:78:9c:a3 on dc0 Jan 6 08:09:45 laptop1 kernel: arp: 192.168.123.36 moved from 00:20:ed:78:= 9c:a3 to 00:00:24:28:98:9a on dc0 Jan 6 08:46:11 laptop1 kernel: arp: 192.168.123.36 moved from 00:00:24:28:= 98:9a to 00:20:ed:78:9c:a3 on dc0 Jan 6 09:29:00 laptop1 kernel: arp: 192.168.123.36 moved from 00:00:24:28:= 98:9a to 00:20:ed:78:9c:a3 on dc0 Jan 6 12:12:12 laptop1 kernel: arp: 192.168.123.36 moved from 00:20:ed:78:= 9c:a3 to 00:00:24:28:98:9a on dc0 Jan 6 12:15:31 laptop1 kernel: arp: 192.168.123.36 moved from 00:00:24:28:= 98:9a to 00:20:ed:78:9c:a3 on dc0 Jan 6 13:06:42 laptop1 kernel: arp: 192.168.123.36 moved from 00:00:24:28:= 98:9a to 00:20:ed:78:9c:a3 on dc0 Jan 6 16:48:45 laptop1 kernel: arp: 192.168.123.36 moved from 00:00:24:28:= 98:9a to 00:20:ed:78:9c:a3 on dc0 Jan 6 17:32:22 laptop1 kernel: arp: 192.168.123.36 moved from 00:20:ed:78:= 9c:a3 to 00:00:24:28:98:9a on dc0 Jan 6 17:33:33 laptop1 kernel: arp: 192.168.123.36 moved from 00:00:24:28:= 98:9a to 00:20:ed:78:9c:a3 on dc0 Jan 6 17:53:45 laptop1 kernel: arp: 192.168.123.36 moved from 00:20:ed:78:= 9c:a3 to 00:00:24:28:98:9a on dc0 Jan 6 17:57:05 laptop1 kernel: arp: 192.168.123.36 moved from 00:00:24:28:= 98:9a to 00:20:ed:78:9c:a3 on dc0 Jan 6 18:17:20 laptop1 kernel: arp: 192.168.123.36 moved from 00:20:ed:78:= 9c:a3 to 00:00:24:28:98:9a on dc0 Jan 6 18:24:48 laptop1 kernel: arp: 192.168.123.36 moved from 00:00:24:28:= 98:9a to 00:20:ed:78:9c:a3 on dc0 Jan 6 18:45:08 laptop1 kernel: arp: 192.168.123.36 moved from 00:20:ed:78:= 9c:a3 to 00:00:24:28:98:9a on dc0 Jan 6 18:48:19 laptop1 kernel: arp: 192.168.123.36 moved from 00:00:24:28:= 98:9a to 00:20:ed:78:9c:a3 on dc0 Jan 6 19:08:45 laptop1 kernel: arp: 192.168.123.36 moved from 00:20:ed:78:= 9c:a3 to 00:00:24:28:98:9a on dc0 Jan 6 19:11:50 laptop1 kernel: arp: 192.168.123.36 moved from 00:00:24:28:= 98:9a to 00:20:ed:78:9c:a3 on dc0 Jan 6 19:32:15 laptop1 kernel: arp: 192.168.123.36 moved from 00:20:ed:78:= 9c:a3 to 00:00:24:28:98:9a on dc0 Jan 6 19:33:07 laptop1 kernel: arp: 192.168.123.36 moved from 00:00:24:28:= 98:9a to 00:20:ed:78:9c:a3 on dc0 Jan 6 19:56:34 laptop1 kernel: arp: 192.168.123.36 moved from 00:00:24:28:= 98:9a to 00:20:ed:78:9c:a3 on dc0 Jan 6 22:44:24 laptop1 kernel: arp: 192.168.123.36 moved from 00:20:ed:78:= 9c:a3 to 00:00:24:28:98:9a on dc0 Jan 6 23:04:26 laptop1 kernel: arp: 192.168.123.36 moved from 00:00:24:28:= 98:9a to 00:20:ed:78:9c:a3 on dc0 Even more unexpectedly, laptop1 is repeating the same "moved" message: Jan 7 00:46:55 laptop1 kernel: arp: 192.168.123.36 moved from 00:00:24:28:= 98:9a to 00:20:ed:78:9c:a3 on dc0 Jan 7 01:38:09 laptop1 kernel: arp: 192.168.123.36 moved from 00:00:24:28:= 98:9a to 00:20:ed:78:9c:a3 on dc0 Jan 7 02:29:26 laptop1 kernel: arp: 192.168.123.36 moved from 00:00:24:28:= 98:9a to 00:20:ed:78:9c:a3 on dc0 Jan 7 03:20:39 laptop1 kernel: arp: 192.168.123.36 moved from 00:00:24:28:= 98:9a to 00:20:ed:78:9c:a3 on dc0 Jan 7 04:28:59 laptop1 kernel: arp: 192.168.123.36 moved from 00:00:24:28:= 98:9a to 00:20:ed:78:9c:a3 on dc0 Jan 7 05:18:50 laptop1 kernel: arp: 192.168.123.36 moved from 00:00:24:28:= 98:9a to 00:20:ed:78:9c:a3 on dc0 Jan 7 06:28:31 laptop1 kernel: arp: 192.168.123.36 moved from 00:00:24:28:= 98:9a to 00:20:ed:78:9c:a3 on dc0 Jan 7 07:16:05 laptop1 kernel: arp: 192.168.123.36 moved from 00:00:24:28:= 98:9a to 00:20:ed:78:9c:a3 on dc0 Both hosts are running 6.1-STABLE: laptop1: FreeBSD laptop1.vk2pj.dyndns.org 6.1-STABLE FreeBSD 6.1-STABLE #0:= Wed Nov 15 18:40:00 EST 2006 root@laptop1.vk2pj.dyndns.org:/usr/obj/us= r/src/sys/laptop i386 desktop: FreeBSD jashank.vk2pj.dyndns.org 6.1-STABLE FreeBSD 6.1-STABLE #15= : Wed Aug 2 18:35:57 EST 2006 root@jashank.vk2pj.dyndns.org:/usr/obj/u= sr/src/sys/jashank i386 I'm not seeing similar messages on other hosts in my network, it seems that the desktop is always sending traffic to the rest of my network via rl0. This leaves two questions: Firstly, why is laptop1 seeing packets coming from both interfaces on the desktop? I had expected that the desktop would always originate packets from the interface with the IP address ("netstat -r" on it shows laptop1 associated with rl0). Secondly, why is laptop1 reporting a list of "address moved" messages =66rom tl0 to rl0 without matching movements from rl0 to tl0? --=20 Peter Jeremy --/QKKmeG/X/bPShih Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFFoA5T/opHv/APuIcRAgzzAJ9YKzvuKy5vhfQb3mcaexIBB/mlsACdEfyJ UwcTteWYTGNU9ZxaOHqa8nw= =3I95 -----END PGP SIGNATURE----- --/QKKmeG/X/bPShih-- From owner-freebsd-stable@FreeBSD.ORG Sat Jan 6 21:09:59 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org 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 39B4016A412 for ; Sat, 6 Jan 2007 21:09:59 +0000 (UTC) (envelope-from dandee@hellteam.net) Received: from pipa.vshosting.cz (pipa.vshosting.cz [81.0.201.10]) by mx1.freebsd.org (Postfix) with ESMTP id BF46C13C45B for ; Sat, 6 Jan 2007 21:09:58 +0000 (UTC) (envelope-from dandee@hellteam.net) Received: from localhost (localhost [127.0.0.1]) by pipa.vshosting.cz (Postfix) with ESMTP id 64B1D1C97F8 for ; Sat, 6 Jan 2007 21:43:05 +0100 (CET) Received: from pipa.vshosting.cz ([127.0.0.1]) by localhost (pipa [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24600-09 for ; Sat, 6 Jan 2007 21:42:59 +0100 (CET) Received: from gandalf (unknown [81.0.245.205]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by pipa.vshosting.cz (Postfix) with ESMTP id 37E861C97F5 for ; Sat, 6 Jan 2007 21:42:59 +0100 (CET) From: =?UTF-8?Q?Daniel_Dvo=C5=99=C3=A1k?= To: Date: Sat, 6 Jan 2007 21:43:02 +0100 Organization: Projekt HELL Message-ID: <002d01c731d3$42f06620$6508280a@tocnet28.jspoj.czf> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: Accx00IjS74L3jwjQr2q3NZHcBZyHg== X-Virus-Scanned: by amavisd-new at pipa.vshosting.cz Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: MultipleBSS and WDS and WPA for adhoc mode X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dandee@hellteam.net List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jan 2007 21:09:59 -0000 Hello all, =20 I would like to find out if these features ( MultipleBSS, WDS, WPA for = adhoc mode) are supposed to be committed to stable branch RELENG_6 or if = it is only in current branch RELENG_7. =20 The features were described in the following PDF=C2=B4s: =20 http://www.bsdcan.org/2005/papers/FreeBSDWirelessNetwokringSupport.pdf =20 http://people.freebsd.org/~sam/BAFUG2006.pdf =20 Thank you Dan