From owner-freebsd-current@FreeBSD.ORG Sun Apr 10 05:02:24 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ED6F1106564A; Sun, 10 Apr 2011 05:02:24 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id 8DB878FC0C; Sun, 10 Apr 2011 05:02:23 +0000 (UTC) Received: from julian-mac.elischer.org (home-nat.elischer.org [67.100.89.137]) (authenticated bits=0) by vps1.elischer.org (8.14.4/8.14.4) with ESMTP id p3A4jnYO084127 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sat, 9 Apr 2011 21:45:53 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <4DA13620.7060407@freebsd.org> Date: Sat, 09 Apr 2011 21:46:24 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Chris Richardson References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, freebsd-emulation@freebsd.org, freebsd-current@freebsd.org Subject: Re: Kernel Tracking Question.. regarding kernel and boot files X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Apr 2011 05:02:25 -0000 On 4/9/11 2:51 PM, Chris Richardson wrote: > On Sat, Apr 9, 2011 at 10:34 PM, Chuck Swiger wrote: > >> Hi, Chris-- >> >> [ ...Reply-to: set to direct towards the most appropriate list... ] >> >> On Apr 9, 2011, at 8:31 AM, Chris Richardson wrote: >>> I am totally new to FreeBSD. I was involved within project which will >>> trace the kernel. I used ktrace but I could not get appropriate results >>> about the files being opened. I don't see any of the boot files boot0-1 >> or 2 >>> in the ktrace.out file. Where did they go? >> The bootstrap loader stages are what loads and runs the kernel. >> ktrace isn't available until afterwards, when the kernel is running. >> >>> Is ktrace the best "trace suite" for freebsd kernel? >> Kinda depends on what you are doing. Setting up good logging and making >> userland >> interfaces for getting to useful information (cf vmstat, ps, iostat, etc) >> is >> more likely to be useful over the longer run. >> >> > What about if I wanna see the interaction between boot process and kernel > loading. either you run it under an emulator that allows you to single step it. or you just add a lot of printf() to the boot loader. (some parts are required to fit in small code sizes to adding prints will cause overflow..) best to read the docs and then the sources. then it wil become apparent to you what you want to find out. > >>> What about going through source code .. Is it better to >>> use Combination of Ecllipse/Qemu and FreeBSD Source tree? >> Eclipse is an editor. If you like it in particular, free free to use it, >> otherwise pick something else you'd prefer to use for C code. >> >>> Does this method will provide us with someway to see how booting process >> invokes >>> the kernel to memory ? Any help will be appreciated. >> You're asking about the process here: >> >> >> http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/boot-blocks.html >> >> ...? Frankly, none of these are especially big, start by reviewing the >> source >> code for 'em. >> >> > Yeah. this file provides me with the stages in theoretical way. How about > implementing it using qemu to emulate livecd to see what is going on boot0. > Do you have an idea about that ? > > Good Luck, > > >> Regards, >> -- >> -Chuck >> >> >> > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Sun Apr 10 07:15:34 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 008E31065670; Sun, 10 Apr 2011 07:15:33 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id D13FB8FC16; Sun, 10 Apr 2011 07:15:32 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id KAA03366; Sun, 10 Apr 2011 10:15:29 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1Q8orp-000Npb-7Z; Sun, 10 Apr 2011 10:15:29 +0300 Message-ID: <4DA15910.4070600@FreeBSD.org> Date: Sun, 10 Apr 2011 10:15:28 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.15) Gecko/20110308 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: Chris Richardson References: In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@FreeBSD.org, freebsd-emulation@FreeBSD.org, freebsd-current@FreeBSD.org Subject: Re: Kernel Tracking Question.. regarding kernel and boot files X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Apr 2011 07:15:34 -0000 on 10/04/2011 00:51 Chris Richardson said the following: > Yeah. this file provides me with the stages in theoretical way. How about > implementing it using qemu to emulate livecd to see what is going on boot0. > Do you have an idea about that ? Yes, that's perfectly possible. You have to be familiar with assembly and know basic behavior of BIOS booting (supposing we talk about x86) and FreeBSD boot blocks, e.g. what is loaded at what address. Here's an example of something related: http://lists.freebsd.org/pipermail/freebsd-fs/2010-May/008580.html -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Sun Apr 10 07:29:04 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C0EF8106566C for ; Sun, 10 Apr 2011 07:29:04 +0000 (UTC) (envelope-from Devin.Teske@fisglobal.com) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) by mx1.freebsd.org (Postfix) with ESMTP id 843A38FC16 for ; Sun, 10 Apr 2011 07:29:04 +0000 (UTC) Received: from sbhfislrext01.fnfis.com ([192.168.249.167]) by SCSFISLTC02 (8.14.3/8.14.3) with ESMTP id p3A7SnvB023344; Sun, 10 Apr 2011 02:28:49 -0500 Received: from SBHFISLTCGW04.FNFIS.COM (Not Verified[10.132.248.123]) by sbhfislrext01.fnfis.com with MailMarshal (v6, 5, 4, 7535) id ; Sun, 10 Apr 2011 02:29:00 -0500 Received: from SBHFISLTCGW04.FNFIS.COM ([10.132.248.123]) by SBHFISLTCGW04.FNFIS.COM with Microsoft SMTPSVC(6.0.3790.4675); Sun, 10 Apr 2011 02:28:49 -0500 Received: from [127.0.0.1] ([10.132.254.135]) by SBHFISLTCGW04.FNFIS.COM over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Sun, 10 Apr 2011 02:28:48 -0500 References: <4DA13620.7060407@freebsd.org> In-Reply-To: <4DA13620.7060407@freebsd.org> Mime-Version: 1.0 (iPad Mail 8G4) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPad Mail (8G4) From: Devin Teske Date: Sun, 10 Apr 2011 00:28:51 -0700 To: Julian Elischer X-OriginalArrivalTime: 10 Apr 2011 07:28:48.0742 (UTC) FILETIME=[EEE1F060:01CBF750] X-Mailman-Approved-At: Sun, 10 Apr 2011 11:10:17 +0000 Cc: "freebsd-hackers@freebsd.org" , Chris Richardson , "freebsd-current@freebsd.org" , "freebsd-emulation@freebsd.org" Subject: Re: Kernel Tracking Question.. regarding kernel and boot files X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Apr 2011 07:29:04 -0000 On Apr 9, 2011, at 9:46 PM, Julian Elischer wrote: > On 4/9/11 2:51 PM, Chris Richardson wrote: >> On Sat, Apr 9, 2011 at 10:34 PM, Chuck Swiger wrote: >>=20 >>> Hi, Chris-- >>>=20 >>> [ ...Reply-to: set to direct towards the most appropriate list... ] >>>=20 >>> On Apr 9, 2011, at 8:31 AM, Chris Richardson wrote: >>>> I am totally new to FreeBSD. I was involved within project which will >>>> trace the kernel. I used ktrace but I could not get appropriate results >>>> about the files being opened. I don't see any of the boot files boot0-1 >>> or 2 >>>> in the ktrace.out file. Where did they go? >>> The bootstrap loader stages are what loads and runs the kernel. >>> ktrace isn't available until afterwards, when the kernel is running. >>>=20 >>>> Is ktrace the best "trace suite" for freebsd kernel? >>> Kinda depends on what you are doing. Setting up good logging and making >>> userland >>> interfaces for getting to useful information (cf vmstat, ps, iostat, et= c) >>> is >>> more likely to be useful over the longer run. >>>=20 >>>=20 >> What about if I wanna see the interaction between boot process and kernel >> loading. >=20 > either you run it under an emulator that allows you to single step it. > or you just add a lot of printf() to the boot loader. > (some parts are required to fit in small code sizes to adding prints will= cause overflow..) > best to read the docs and then the sources. then it wil become apparent t= o you > what you want to find out. You also have the option of writing Forth modules for the boot-loader. Even= dropping to the "ok" prompt is enough to give you full access to the built= -in Forth interpreter. You can query the variables that are set in the "env= ironment" (which are different depending whether you've booted via pxeboot,= cdboot, or other method). You can even do some limited device poking and f= ile-io (both read and write). The benefit of the forth modules is that you can use it to produce the nece= ssary debug output whilst avoiding the overflow issue. That is to say, that= one technique I've used is to add code to the loader to export some string= or value of interest to a variable in the environment that I would then ad= d something like 'echo "debug =3D=3D $debug"' to loader.rc. Keeps the loade= r small and the human fluff off to the interpreter. >=20 >>=20 >>>> What about going through source code .. Is it better to >>>> use Combination of Ecllipse/Qemu and FreeBSD Source tree? >>> Eclipse is an editor. If you like it in particular, free free to use i= t, >>> otherwise pick something else you'd prefer to use for C code. I use a combination of vim (as my editor) and CVSweb (URL is in the handboo= k) for historical research as necessary. Just my "tuppence." --=20 Devin >>>=20 >>>> Does this method will provide us with someway to see how booting proce= ss >>> invokes >>>> the kernel to memory ? Any help will be appreciated. >>> You're asking about the process here: >>>=20 >>>=20 >>> http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/boot-blocks.h= tml >>>=20 >>> ...? Frankly, none of these are especially big, start by reviewing the >>> source >>> code for 'em. >>>=20 >>>=20 >> Yeah. this file provides me with the stages in theoretical way. How about >> implementing it using qemu to emulate livecd to see what is going on boo= t0. >> Do you have an idea about that ? >>=20 >> Good Luck, >>=20 >>=20 >>> Regards, >>> -- >>> -Chuck >>>=20 >>>=20 >>>=20 >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.or= g" >>=20 >=20 > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" _____________ The information contained in this message is proprietary and/or confidentia= l. If you are not the intended recipient, please: (i) delete the message an= d all copies; (ii) do not disclose, distribute or use the message in any ma= nner; and (iii) notify the sender immediately. In addition, please be aware= that any message addressed to our domain is subject to archiving and revie= w by persons other than the intended recipient. Thank you. _____________ From owner-freebsd-current@FreeBSD.ORG Sun Apr 10 11:56:44 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id C75621065673; Sun, 10 Apr 2011 11:56:44 +0000 (UTC) Date: Sun, 10 Apr 2011 11:56:44 +0000 From: Alexander Best To: Alexander Motin Message-ID: <20110410115644.GA55815@freebsd.org> References: <20110331223339.GA13682@freebsd.org> <201104010843.47367.jhb@freebsd.org> <20110404204316.GA11367@freebsd.org> <4D9D9917.3030102@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4D9D9917.3030102@FreeBSD.org> Cc: freebsd-scsi@freebsd.org, freebsd-current@freebsd.org Subject: Re: multiple issues with devstat_*(9) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Apr 2011 11:56:44 -0000 On Thu Apr 7 11, Alexander Motin wrote: > Alexander Best wrote: > > On Fri Apr 1 11, John Baldwin wrote: > >> On Thursday, March 31, 2011 6:33:39 pm Alexander Best wrote: > >>> i think there are multiple issues with devstat. i found the following in > >>> devicestat.h: > > ... > > >>> funny thing is i found the following in scsi_pass.c: > >>> > >>> softc->device_stats = devstat_new_entry("pass", > >>> periph->unit_number, 0, > >>> DEVSTAT_NO_BLOCKSIZE > >>> | (no_tags ? DEVSTAT_NO_ORDERED_TAGS : 0), > >>> softc->pd_type | > >>> DEVSTAT_TYPE_IF_SCSI | > >>> DEVSTAT_TYPE_PASS, > >>> DEVSTAT_PRIORITY_PASS); > >>> > >>> ...so pass* *should* show up under iostat -t scsi. > > As I can see, this is a bug (or feature) of the libdevstat / > devstat_selectdevs(). If you specify any -t, then pass devices will be > reported only if you request "pass" specifically. > > >> Hmm, pass devices for adaX should not be SCSI though, they should be ide I > >> think. > > > > i think the situation with ATA_CAM should be discussed further. still besides > > this issue there are many more with devstat(3). > > > > i'll try to track all the "devstat_new_entry()" occurrences and see if some > > issues can be fixed. maybe only the proper DEVSTAT_* args were forgotten. > > Assuming that SCSI and IDE in -t option means transport type, and > assuming that we count everything except ATA and SATA as SCSI, I've made > following patch, that should fix issues from the CAM side: > http://people.freebsd.org/~mav/cam.devstat.patch with your patch i get the following output: otaku% iostat -t ide tty ada0 ada1 cpu tin tout KB/t tps MB/s KB/t tps MB/s us ni sy in id 6 144 14.21 6 0.09 20.46 40 0.81 2 0 3 0 95 otaku% iostat -t scsi tty cd0 cpu tin tout KB/t tps MB/s us ni sy in id 6 146 2.32 0 0.00 2 0 3 0 95 otaku% iostat -t pass tty pass0 pass1 pass2 cpu tin tout KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s us ni sy in id 6 147 0.36 0 0.00 0.36 0 0.00 0.00 0 0.00 2 0 3 0 95 otaku% iostat -t da tty ada0 ada1 cpu tin tout KB/t tps MB/s KB/t tps MB/s us ni sy in id 6 147 14.21 6 0.08 20.46 37 0.75 1 0 3 0 95 otaku% iostat -t cd tty cd0 cpu tin tout KB/t tps MB/s us ni sy in id 7 147 2.32 0 0.00 1 0 3 0 95 otaku% iostat -t other tty cpu tin tout us ni sy in id 7 149 1 0 3 0 95 otaku% iostat -n 100 tty ada0 ada1 cd0 pass0 pass1 pass2 cpu tin tout KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s us ni sy in id 6 135 14.21 5 0.07 20.44 32 0.64 2.32 0 0.00 0.36 0 0.00 0.36 0 0.00 0.00 0 0.00 1 0 3 0 96 the the remaining issues imho are: 1) ada* and cd* are SATA/ATA devices. so i think they should show up together either under ide *or* scsi. i don't have any *real* scsi devices. 2) the pass* devices still don't show up under ide/scsi/other. that's ok, but then the src comments and manual pages need to be changed accordingly. 3) md0 should show up under iostat -t other cheers. alex > > Any objections? Or SCSI/IDE there expected to mean command set? > > -- > Alexander Motin -- a13x From owner-freebsd-current@FreeBSD.ORG Sun Apr 10 12:00:40 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 1069410657DA; Sun, 10 Apr 2011 12:00:40 +0000 (UTC) Date: Sun, 10 Apr 2011 12:00:40 +0000 From: Alexander Best To: Alexander Motin Message-ID: <20110410120040.GA56629@freebsd.org> References: <20110331223339.GA13682@freebsd.org> <201104010843.47367.jhb@freebsd.org> <20110404204316.GA11367@freebsd.org> <4D9D9917.3030102@FreeBSD.org> <20110410115644.GA55815@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110410115644.GA55815@freebsd.org> Cc: freebsd-scsi@freebsd.org, freebsd-current@freebsd.org Subject: Re: multiple issues with devstat_*(9) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Apr 2011 12:00:40 -0000 On Sun Apr 10 11, Alexander Best wrote: > On Thu Apr 7 11, Alexander Motin wrote: > > Alexander Best wrote: > > > On Fri Apr 1 11, John Baldwin wrote: > > >> On Thursday, March 31, 2011 6:33:39 pm Alexander Best wrote: > > >>> i think there are multiple issues with devstat. i found the following in > > >>> devicestat.h: > > > > ... > > > > >>> funny thing is i found the following in scsi_pass.c: > > >>> > > >>> softc->device_stats = devstat_new_entry("pass", > > >>> periph->unit_number, 0, > > >>> DEVSTAT_NO_BLOCKSIZE > > >>> | (no_tags ? DEVSTAT_NO_ORDERED_TAGS : 0), > > >>> softc->pd_type | > > >>> DEVSTAT_TYPE_IF_SCSI | > > >>> DEVSTAT_TYPE_PASS, > > >>> DEVSTAT_PRIORITY_PASS); > > >>> > > >>> ...so pass* *should* show up under iostat -t scsi. > > > > As I can see, this is a bug (or feature) of the libdevstat / > > devstat_selectdevs(). If you specify any -t, then pass devices will be > > reported only if you request "pass" specifically. > > > > >> Hmm, pass devices for adaX should not be SCSI though, they should be ide I > > >> think. > > > > > > i think the situation with ATA_CAM should be discussed further. still besides > > > this issue there are many more with devstat(3). > > > > > > i'll try to track all the "devstat_new_entry()" occurrences and see if some > > > issues can be fixed. maybe only the proper DEVSTAT_* args were forgotten. > > > > Assuming that SCSI and IDE in -t option means transport type, and > > assuming that we count everything except ATA and SATA as SCSI, I've made > > following patch, that should fix issues from the CAM side: > > http://people.freebsd.org/~mav/cam.devstat.patch > > with your patch i get the following output: > > otaku% iostat -t ide > tty ada0 ada1 cpu > tin tout KB/t tps MB/s KB/t tps MB/s us ni sy in id > 6 144 14.21 6 0.09 20.46 40 0.81 2 0 3 0 95 > otaku% iostat -t scsi > tty cd0 cpu > tin tout KB/t tps MB/s us ni sy in id > 6 146 2.32 0 0.00 2 0 3 0 95 > otaku% iostat -t pass > tty pass0 pass1 pass2 cpu > tin tout KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s us ni sy in id > 6 147 0.36 0 0.00 0.36 0 0.00 0.00 0 0.00 2 0 3 0 95 > otaku% iostat -t da > tty ada0 ada1 cpu > tin tout KB/t tps MB/s KB/t tps MB/s us ni sy in id > 6 147 14.21 6 0.08 20.46 37 0.75 1 0 3 0 95 > otaku% iostat -t cd > tty cd0 cpu > tin tout KB/t tps MB/s us ni sy in id > 7 147 2.32 0 0.00 1 0 3 0 95 > otaku% iostat -t other > tty cpu > tin tout us ni sy in id > 7 149 1 0 3 0 95 > otaku% iostat -n 100 > tty ada0 ada1 cd0 pass0 pass1 pass2 cpu > tin tout KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s us ni sy in id > 6 135 14.21 5 0.07 20.44 32 0.64 2.32 0 0.00 0.36 0 0.00 0.36 0 0.00 0.00 0 0.00 1 0 3 0 96 > > the the remaining issues imho are: > > 1) ada* and cd* are SATA/ATA devices. so i think they should show up together > either under ide *or* scsi. i don't have any *real* scsi devices. > 2) the pass* devices still don't show up under ide/scsi/other. that's ok, but > then the src comments and manual pages need to be changed accordingly. > 3) md0 should show up under iostat -t other sorry this was my fault. there was no md* configured at the time i ran the test. md0 showx up under iostat -t da and iostat -t other, just like it's supposd to. so please forget about point 3). cheers. alex > > cheers. > alex > > > > > Any objections? Or SCSI/IDE there expected to mean command set? > > > > -- > > Alexander Motin > > -- > a13x -- a13x From owner-freebsd-current@FreeBSD.ORG Sun Apr 10 13:53:18 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AE379106566C for ; Sun, 10 Apr 2011 13:53:18 +0000 (UTC) (envelope-from freebsd-listen@fabiankeil.de) Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.31.25]) by mx1.freebsd.org (Postfix) with ESMTP id F01E98FC0A for ; Sun, 10 Apr 2011 13:53:17 +0000 (UTC) Received: from [87.78.60.163] (helo=fabiankeil.de) by smtprelay02.ispgateway.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1Q8uq8-0003w9-Sr for freebsd-current@freebsd.org; Sun, 10 Apr 2011 15:38:13 +0200 Date: Sun, 10 Apr 2011 15:37:59 +0200 From: Fabian Keil To: FreeBSD Current Message-ID: <20110410153759.025aa4e2@fabiankeil.de> X-PGP-KEY-URL: http://www.fabiankeil.de/gpg-keys/freebsd-listen-2008-08-18.asc Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/4Y4l7W31jqEr+83ZrQmmKDx"; protocol="application/pgp-signature" X-Df-Sender: 775067 Subject: panic: _mtx_lock_sleep: recursed on non-recursive mutex process lock @ /usr/src/sys/kern/kern_exit.c:912 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Apr 2011 13:53:18 -0000 --Sig_/4Y4l7W31jqEr+83ZrQmmKDx Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable The following panic seems to be reliably reproducible with sources from yesterday (and today) by running claws-mail in X, switching to the console and trying to attach gdb to it with 'gdb -p $(pgrep claws-mail)= '. gdb somehow fails to attach, and after leaving gdb the panic occurs. fk@r500 /usr/crash $cat info.0=20 Dump header from device /dev/ada0s1b Architecture: amd64 =20 Architecture Version: 2 =20 Dump Length: 347676672B (331 MB) Blocksize: 512 =20 Dumptime: Sat Apr 9 22:48:15 2011 Hostname: r500.local =20 Magic: FreeBSD Kernel Dump =20 Version String: FreeBSD 9.0-CURRENT #284 r+1c500d9: Sat Apr 9 15:44:51 C= EST 2011 fk@r500.local:/usr/obj/usr/src/sys/ZOEY Panic String: _mtx_lock_sleep: recursed on non-recursive mutex process lo= ck @ /usr/src/sys/kern/kern_exit.c:912 Dump Parity: 1557143341 Bounds: 0 Dump Status: good fk@r500 /usr/crash $kgdb /boot/kernel/kernel vmcore.0=20 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 "amd64-marcel-freebsd"... Unread portion of the kernel message buffer: panic: _mtx_lock_sleep: recursed on non-recursive mutex process lock @ /usr= /src/sys/kern/kern_exit.c:912 cpuid =3D 0 KDB: enter: panic panic: from debugger cpuid =3D 0 Uptime: 3m48s Physical memory: 1974 MB Dumping 331 MB: 316 300 284 268 252 236 220 204 188 172 156 140 124 108 92 = 76 60 44 28 12 Reading symbols from /boot/kernel/zfs.ko...Reading symbols from /boot/kerne= l/zfs.ko.symbols...done. done. [...] Loaded symbols for /boot/kernel/drm.ko #0 doadump () at /usr/src/sys/kern/kern_shutdown.c:250 250 if (textdump_pending) (kgdb) where #0 doadump () at /usr/src/sys/kern/kern_shutdown.c:250 #1 0xffffffff80531fb7 in kern_reboot (howto=3D260) at /usr/src/sys/kern/ke= rn_shutdown.c:418 #2 0xffffffff80531a51 in panic (fmt=3DVariable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:591 #3 0xffffffff803202b7 in db_panic (addr=3DVariable "addr" is not available. ) at /usr/src/sys/ddb/db_command.c:478 #4 0xffffffff80320761 in db_command (last_cmdp=3D0xffffffff80c9fb60, cmd_t= able=3DVariable "cmd_table" is not available. ) at /usr/src/sys/ddb/db_command.c:445 #5 0xffffffff803209b0 in db_command_loop () at /usr/src/sys/ddb/db_command= .c:498 #6 0xffffffff80322a99 in db_trap (type=3DVariable "type" is not available. ) at /usr/src/sys/ddb/db_main.c:229 #7 0xffffffff80567ba1 in kdb_trap (type=3D3, code=3D0, tf=3D0xffffff800001= 7740) at /usr/src/sys/kern/subr_kdb.c:533 #8 0xffffffff807cee06 in trap (frame=3D0xffffff8000017740) at /usr/src/sys= /amd64/amd64/trap.c:590 #9 0xffffffff807b9303 in calltrap () at /usr/src/sys/amd64/amd64/exception= .S:228 #10 0xffffffff805679fb in kdb_enter (why=3D0xffffffff80955faf "panic", msg= =3D0xa
) at cpufunc.h:63 #11 0xffffffff80531a60 in panic (fmt=3DVariable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:574 #12 0xffffffff805222f9 in _mtx_lock_sleep (m=3DVariable "m" is not availabl= e. ) at /usr/src/sys/kern/kern_mutex.c:341 #13 0xffffffff805223a5 in _mtx_lock_flags (m=3DVariable "m" is not availabl= e. ) at /usr/src/sys/kern/kern_mutex.c:203 #14 0xffffffff80503789 in proc_reparent (child=3D0xfffffe001290a000, parent= =3D0xfffffe0012e48900) at /usr/src/sys/kern/kern_exit.c:912 #15 0xffffffff80503ed8 in kern_wait (td=3D0xffffff8000017adc, pid=3DVariabl= e "pid" is not available. ) at /usr/src/sys/kern/kern_exit.c:708 #16 0xffffffff805043e5 in wait4 (td=3DVariable "td" is not available. ) at /usr/src/sys/kern/kern_exit.c:653 #17 0xffffffff805751ab in syscallenter (td=3D0xfffffe00028838c0, sa=3D0xfff= fff8000017bb0) at /usr/src/sys/kern/subr_trap.c:344 #18 0xffffffff807ce8bc in syscall (frame=3D0xffffff8000017c50) at /usr/src/= sys/amd64/amd64/trap.c:910 #19 0xffffffff807b95cd in Xfast_syscall () at /usr/src/sys/amd64/amd64/exce= ption.S:384 #20 0x000000000040cb8c in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) f 14 #14 0xffffffff80503789 in proc_reparent (child=3D0xfffffe001290a000, parent= =3D0xfffffe0012e48900) at /usr/src/sys/kern/kern_exit.c:912 912 PROC_LOCK(parent); (kgdb) p *child $2 =3D {p_list =3D {le_next =3D 0x0, le_prev =3D 0xffffffff80cba328}, p_thr= eads =3D {tqh_first =3D 0xfffffe001287c000, tqh_last =3D 0xfffffe001287c010= }, p_slock =3D {lock_object =3D { lo_name =3D 0xffffffff80954527 "process slock", lo_flags =3D 720896, = lo_data =3D 0, lo_witness =3D 0x0}, mtx_lock =3D 4}, p_ucred =3D 0xfffffe00= 427b5a00, p_fd =3D 0x0,=20 p_fdtol =3D 0x0, p_stats =3D 0xfffffe0005d82800, p_limit =3D 0x0, p_limco= =3D {c_links =3D {sle =3D {sle_next =3D 0x0}, tqe =3D {tqe_next =3D 0x0, t= qe_prev =3D 0x0}}, c_time =3D 0, c_arg =3D 0x0,=20 c_func =3D 0, c_lock =3D 0xfffffe001290a0f8, c_flags =3D 0, c_cpu =3D 0= }, p_sigacts =3D 0xfffffe0042634000, p_flag =3D 268460034, p_state =3D PRS_= ZOMBIE, p_pid =3D 3515, p_hash =3D { le_next =3D 0x0, le_prev =3D 0xffffff8000222dd8}, p_pglist =3D {le_next= =3D 0x0, le_prev =3D 0xfffffe004a876790}, p_pptr =3D 0xfffffe0002881900, p= _sibling =3D { le_next =3D 0xfffffe0042640900, le_prev =3D 0xfffffe00028819f0}, p_chil= dren =3D {lh_first =3D 0x0}, p_mtx =3D {lock_object =3D {lo_name =3D 0xffff= ffff8095451a "process lock",=20 lo_flags =3D 21168128, lo_data =3D 0, lo_witness =3D 0x0}, mtx_lock = =3D 18446741874728777920}, p_ksi =3D 0xfffffe0005c60150, p_sigqueue =3D {sq= _signals =3D {__bits =3D {0, 0, 0, 0}},=20 sq_kill =3D {__bits =3D {0, 0, 0, 0}}, sq_list =3D {tqh_first =3D 0x0, = tqh_last =3D 0xfffffe001290a140}, sq_proc =3D 0xfffffe001290a000, sq_flags = =3D 1}, p_oppid =3D 0,=20 p_vmspace =3D 0xffffffff80cb7760, p_swtick =3D 21105, p_realtimer =3D {it= _interval =3D {tv_sec =3D 0, tv_usec =3D 0}, it_value =3D {tv_sec =3D 0, tv= _usec =3D 0}}, p_ru =3D {ru_utime =3D { tv_sec =3D 0, tv_usec =3D 0}, ru_stime =3D {tv_sec =3D 0, tv_usec =3D= 0}, ru_maxrss =3D 21044, ru_ixrss =3D 544640, ru_idrss =3D 334244, ru_isrs= s =3D 27264, ru_minflt =3D 2745,=20 ru_majflt =3D 2158, ru_nswap =3D 0, ru_inblock =3D 3, ru_oublock =3D 0,= ru_msgsnd =3D 134, ru_msgrcv =3D 103, ru_nsignals =3D 0, ru_nvcsw =3D 473,= ru_nivcsw =3D 533}, p_rux =3D { rux_runtime =3D 2346291660, rux_uticks =3D 119, rux_sticks =3D 29, rux_= iticks =3D 0, rux_uu =3D 948699, rux_su =3D 223223, rux_tu =3D 1171923}, p_= crux =3D {rux_runtime =3D 0,=20 rux_uticks =3D 0, rux_sticks =3D 0, rux_iticks =3D 0, rux_uu =3D 0, rux= _su =3D 0, rux_tu =3D 0}, p_profthreads =3D 0, p_exitthreads =3D 0, p_trace= flag =3D 0, p_tracevp =3D 0x0,=20 p_tracecred =3D 0x0, p_textvp =3D 0x0, p_lock =3D 0, p_sigiolst =3D {slh_= first =3D 0x0}, p_sigparent =3D 20, p_sig =3D 0, p_code =3D 0, p_stops =3D = 0, p_stype =3D 0, p_step =3D 0 '\0',=20 p_pfsflags =3D 0 '\0', p_nlminfo =3D 0x0, p_aioinfo =3D 0x0, p_singlethre= ad =3D 0x0, p_suspcount =3D 0, p_xthread =3D 0xfffffe001287c000, p_boundary= _count =3D 0, p_pendingcnt =3D 0,=20 p_itimers =3D 0x0, p_magic =3D 3203398350, p_osrel =3D 900034, p_comm =3D= "claws-mail\000\000\000\000\000\000\000\000\000", p_pgrp =3D 0xfffffe004a8= 76780,=20 p_sysent =3D 0xffffffff80c6b320, p_args =3D 0xfffffe0005c8b3c0, p_cpulimi= t =3D 9223372036854775807, p_nice =3D 0 '\0', p_fibnum =3D 0, p_xstat =3D 9= , p_klist =3D {kl_list =3D { slh_first =3D 0x0}, kl_lock =3D 0, kl_unlock =3D 0, kl_assert_locked = =3D 0xffffffff804fd960 ,=20 kl_assert_unlocked =3D 0xffffffff804fd940 ,= kl_lockarg =3D 0x0}, p_numthreads =3D 1, p_md =3D {md_ldt =3D 0x0, md_ldt_= sd =3D {sd_lolimit =3D 0,=20 sd_lobase =3D 0, sd_type =3D 0, sd_dpl =3D 0, sd_p =3D 0, sd_hilimit = =3D 0, sd_xx0 =3D 0, sd_gran =3D 0, sd_hibase =3D 0, sd_xx1 =3D 0, sd_mbz = =3D 0, sd_xx2 =3D 0}}, p_itcallout =3D { c_links =3D {sle =3D {sle_next =3D 0x0}, tqe =3D {tqe_next =3D 0x0, tqe= _prev =3D 0x0}}, c_time =3D 0, c_arg =3D 0x0, c_func =3D 0, c_lock =3D 0x0,= c_flags =3D 16, c_cpu =3D 0}, p_acflag =3D 16,=20 p_peers =3D 0x0, p_leader =3D 0xfffffe001290a000, p_emuldata =3D 0x0, p_l= abel =3D 0x0, p_sched =3D 0xfffffe001290a480, p_ktr =3D {stqh_first =3D 0x0= , stqh_last =3D 0xfffffe001290a430},=20 p_mqnotifier =3D {lh_first =3D 0x0}, p_dtrace =3D 0xfffffe0005c7a740, p_p= wait =3D {cv_description =3D 0xffffffff80954fbe "ppwait", cv_waiters =3D 0}= , p_dbgwait =3D { cv_description =3D 0xffffffff80954fc5 "dbgwait", cv_waiters =3D 0}, p_p= rev_runtime =3D 0, p_racct =3D 0x0} (kgdb) p *parent $3 =3D {p_list =3D {le_next =3D 0xfffffe004261b000, le_prev =3D 0xffffffff8= 0cba320}, p_threads =3D {tqh_first =3D 0xfffffe0005e0d8c0, tqh_last =3D 0xf= ffffe0005e0d8d0}, p_slock =3D { lock_object =3D {lo_name =3D 0xffffffff80954527 "process slock", lo_fla= gs =3D 720896, lo_data =3D 0, lo_witness =3D 0x0}, mtx_lock =3D 4}, p_ucred= =3D 0xfffffe00427b5a00,=20 p_fd =3D 0xfffffe00128b1c00, p_fdtol =3D 0x0, p_stats =3D 0xfffffe001290c= 800, p_limit =3D 0xfffffe00427b5300, p_limco =3D {c_links =3D {sle =3D {sle= _next =3D 0x0}, tqe =3D {tqe_next =3D 0x0,=20 tqe_prev =3D 0x0}}, c_time =3D 0, c_arg =3D 0x0, c_func =3D 0, c_lo= ck =3D 0xfffffe0012e489f8, c_flags =3D 0, c_cpu =3D 0}, p_sigacts =3D 0xfff= ffe0012e9c000, p_flag =3D 268451842,=20 p_state =3D PRS_NORMAL, p_pid =3D 3407, p_hash =3D {le_next =3D 0x0, le_p= rev =3D 0xffffff8000222a78}, p_pglist =3D {le_next =3D 0x0, le_prev =3D 0xf= ffffe0005e59310},=20 p_pptr =3D 0xfffffe004261b000, p_sibling =3D {le_next =3D 0x0, le_prev = =3D 0xfffffe004261b0f0}, p_children =3D {lh_first =3D 0x0}, p_mtx =3D {lock= _object =3D { lo_name =3D 0xffffffff8095451a "process lock", lo_flags =3D 21168128,= lo_data =3D 0, lo_witness =3D 0x0}, mtx_lock =3D 18446741874728777920}, p_= ksi =3D 0xfffffe0005c5eb60,=20 p_sigqueue =3D {sq_signals =3D {__bits =3D {0, 0, 0, 0}}, sq_kill =3D {__= bits =3D {0, 0, 0, 0}}, sq_list =3D {tqh_first =3D 0x0, tqh_last =3D 0xffff= fe0012e48a40},=20 sq_proc =3D 0xfffffe0012e48900, sq_flags =3D 1}, p_oppid =3D 0, p_vmspa= ce =3D 0xfffffe00128c5310, p_swtick =3D 12384, p_realtimer =3D {it_interval= =3D {tv_sec =3D 0, tv_usec =3D 0},=20 it_value =3D {tv_sec =3D 0, tv_usec =3D 0}}, p_ru =3D {ru_utime =3D {tv= _sec =3D 0, tv_usec =3D 0}, ru_stime =3D {tv_sec =3D 0, tv_usec =3D 0}, ru_= maxrss =3D 0, ru_ixrss =3D 0, ru_idrss =3D 0,=20 ru_isrss =3D 0, ru_minflt =3D 0, ru_majflt =3D 0, ru_nswap =3D 0, ru_in= block =3D 0, ru_oublock =3D 0, ru_msgsnd =3D 0, ru_msgrcv =3D 0, ru_nsignal= s =3D 0, ru_nvcsw =3D 0, ru_nivcsw =3D 0},=20 p_rux =3D {rux_runtime =3D 1633285860, rux_uticks =3D 63, rux_sticks =3D = 44, rux_iticks =3D 0, rux_uu =3D 482021, rux_su =3D 336649, rux_tu =3D 8186= 71}, p_crux =3D {rux_runtime =3D 770335510,=20 rux_uticks =3D 11, rux_sticks =3D 39, rux_iticks =3D 0, rux_uu =3D 8494= 7, rux_su =3D 301176, rux_tu =3D 386124}, p_profthreads =3D 0, p_exitthread= s =3D 0, p_traceflag =3D 0,=20 p_tracevp =3D 0x0, p_tracecred =3D 0x0, p_textvp =3D 0xfffffe00427ae780, = p_lock =3D 0, p_sigiolst =3D {slh_first =3D 0x0}, p_sigparent =3D 20, p_sig= =3D 0, p_code =3D 0, p_stops =3D 0,=20 p_stype =3D 0, p_step =3D 0 '\0', p_pfsflags =3D 0 '\0', p_nlminfo =3D 0x= 0, p_aioinfo =3D 0x0, p_singlethread =3D 0x0, p_suspcount =3D 0, p_xthread = =3D 0x0, p_boundary_count =3D 0,=20 p_pendingcnt =3D 0, p_itimers =3D 0x0, p_magic =3D 3203398350, p_osrel = =3D 900025, p_comm =3D "bash", '\0' , p_pgrp =3D 0xfffffe= 0005e59300,=20 p_sysent =3D 0xffffffff80c6b320, p_args =3D 0xfffffe0002ba2880, p_cpulimi= t =3D 9223372036854775807, p_nice =3D 0 '\0', p_fibnum =3D 0, p_xstat =3D 0= , p_klist =3D {kl_list =3D { slh_first =3D 0x0}, kl_lock =3D 0xffffffff804fd660 ,= kl_unlock =3D 0xffffffff804fd680 ,=20 kl_assert_locked =3D 0xffffffff804fd960 , kl_= assert_unlocked =3D 0xffffffff804fd940 , kl_loc= karg =3D 0xfffffe0012e489f8},=20 p_numthreads =3D 1, p_md =3D {md_ldt =3D 0x0, md_ldt_sd =3D {sd_lolimit = =3D 0, sd_lobase =3D 0, sd_type =3D 0, sd_dpl =3D 0, sd_p =3D 0, sd_hilimit= =3D 0, sd_xx0 =3D 0, sd_gran =3D 0,=20 sd_hibase =3D 0, sd_xx1 =3D 0, sd_mbz =3D 0, sd_xx2 =3D 0}}, p_itcall= out =3D {c_links =3D {sle =3D {sle_next =3D 0x0}, tqe =3D {tqe_next =3D 0x0= , tqe_prev =3D 0x0}}, c_time =3D 0,=20 c_arg =3D 0x0, c_func =3D 0, c_lock =3D 0x0, c_flags =3D 16, c_cpu =3D = 0}, p_acflag =3D 0, p_peers =3D 0x0, p_leader =3D 0xfffffe0012e48900, p_emu= ldata =3D 0x0, p_label =3D 0x0,=20 p_sched =3D 0xfffffe0012e48d80, p_ktr =3D {stqh_first =3D 0x0, stqh_last = =3D 0xfffffe0012e48d30}, p_mqnotifier =3D {lh_first =3D 0x0}, p_dtrace =3D = 0xfffffe0005d85b80, p_pwait =3D { cv_description =3D 0xffffffff80954fbe "ppwait", cv_waiters =3D 0}, p_db= gwait =3D {cv_description =3D 0xffffffff80954fc5 "dbgwait", cv_waiters =3D = 0}, p_prev_runtime =3D 0,=20 p_racct =3D 0x0} I'm not sure if switching to the console first matters. Before the panic, the states of gdb and claws-mail were: fk@r500 ~ $procstat -kk $(pgrep claws-mail) PID TID COMM TDNAME KSTACK = =20 15813 100528 claws-mail initial thread mi_switch+0x21d thread_suspe= nd_switch+0x103 ptracestop+0x7a cursig+0x4af ast+0x198 doreti_ast+0x1f=20 fk@r500 ~ $procstat -kk $(pgrep gdb) PID TID COMM TDNAME KSTACK = =20 15823 100928 gdb - mi_switch+0x21d sleepq_switc= h+0x123 sleepq_catch_signals+0x2a2 sleepq_wait_sig+0x16 _cv_wait_sig+0x14c = tty_wait+0x48 ttydisc_read+0xd4 ttydev_read+0xab devfs_read_f+0x88 dofilere= ad+0xa1 kern_readv+0x60 read+0x55 syscallenter+0x1cb syscall+0x4c Xfast_sys= call+0xdd=20 I believe I also reproduced the problem with a kernel from Tuesday, but dumping core from ddb failed so I can't check. I cannot reproduce the panic with a kernel from 2011-03-12 which I haven't deleted yet, but didn't try to bisect it further. gdb can't attach to claws-mail either, but the panic doesn't occur: fk@r500 ~ $gdb -p $(pgrep claws-mail) 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 "amd64-marcel-freebsd". Attaching to process 3432 /usr/src/gnu/usr.bin/gdb/libgdb/../../../../contrib/gdb/gdb/solib-svr4.c:14= 44: i nternal-error: legacy_fetch_link_map_offsets called without legacy link_map= supp ort enabled. A problem internal to GDB has been detected, further debugging may prove unreliable. Quit this debugging session? (y or n) y /usr/src/gnu/usr.bin/gdb/libgdb/../../../../contrib/gdb/gdb/solib-svr4.c:14= 44: i nternal-error: legacy_fetch_link_map_offsets called without legacy link_map= supp ort enabled. A problem internal to GDB has been detected, further debugging may prove unreliable. Create a core file of GDB? (y or n) n In related news, the kernel from yesterday also seems to panic/hang/whatever when claws-mail segfaults due to an invalid memory access, but as I was run= ning X, I got no core dumps for those problems either. Fabian --Sig_/4Y4l7W31jqEr+83ZrQmmKDx Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (FreeBSD) iEYEARECAAYFAk2hssMACgkQBYqIVf93VJ0bJQCeJwg50nhOvOXneJOKmkSHwlR5 b/QAnAhWDnDvo45HlOe+wpGcKGixfp9m =Epdi -----END PGP SIGNATURE----- --Sig_/4Y4l7W31jqEr+83ZrQmmKDx-- From owner-freebsd-current@FreeBSD.ORG Sun Apr 10 15:18:54 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C5828106564A for ; Sun, 10 Apr 2011 15:18:54 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id AF07B8FC14 for ; Sun, 10 Apr 2011 15:18:53 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id p3AFIlE1022552 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 10 Apr 2011 18:18:47 +0300 (EEST) (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.14.4/8.14.4) with ESMTP id p3AFIl9Q059622; Sun, 10 Apr 2011 18:18:47 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id p3AFIlIf059621; Sun, 10 Apr 2011 18:18:47 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 10 Apr 2011 18:18:47 +0300 From: Kostik Belousov To: Fabian Keil Message-ID: <20110410151847.GT78089@deviant.kiev.zoral.com.ua> References: <20110410153759.025aa4e2@fabiankeil.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="KEQY95CNCHRmtrVV" Content-Disposition: inline In-Reply-To: <20110410153759.025aa4e2@fabiankeil.de> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-2.1 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_50, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: FreeBSD Current Subject: Re: panic: _mtx_lock_sleep: recursed on non-recursive mutex process lock @ /usr/src/sys/kern/kern_exit.c:912 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Apr 2011 15:18:54 -0000 --KEQY95CNCHRmtrVV Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Apr 10, 2011 at 03:37:59PM +0200, Fabian Keil wrote: > The following panic seems to be reliably reproducible with sources > from yesterday (and today) by running claws-mail in X, switching to > the console and trying to attach gdb to it with 'gdb -p $(pgrep claws-mai= l)'. >=20 > gdb somehow fails to attach, and after leaving gdb the panic occurs. >=20 > fk@r500 /usr/crash $cat info.0=20 > Dump header from device /dev/ada0s1b > Architecture: amd64 =20 > Architecture Version: 2 =20 > Dump Length: 347676672B (331 MB) > Blocksize: 512 =20 > Dumptime: Sat Apr 9 22:48:15 2011 > Hostname: r500.local =20 > Magic: FreeBSD Kernel Dump =20 > Version String: FreeBSD 9.0-CURRENT #284 r+1c500d9: Sat Apr 9 15:44:51= CEST 2011 > fk@r500.local:/usr/obj/usr/src/sys/ZOEY > Panic String: _mtx_lock_sleep: recursed on non-recursive mutex process = lock @ /usr/src/sys/kern/kern_exit.c:912 >=20 > Dump Parity: 1557143341 > Bounds: 0 > Dump Status: good >=20 > fk@r500 /usr/crash $kgdb /boot/kernel/kernel vmcore.0=20 > 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 "amd64-marcel-freebsd"... >=20 > Unread portion of the kernel message buffer: > panic: _mtx_lock_sleep: recursed on non-recursive mutex process lock @ /u= sr/src/sys/kern/kern_exit.c:912 >=20 > cpuid =3D 0 > KDB: enter: panic > panic: from debugger > cpuid =3D 0 > Uptime: 3m48s > Physical memory: 1974 MB > Dumping 331 MB: 316 300 284 268 252 236 220 204 188 172 156 140 124 108 9= 2 76 60 44 28 12 >=20 > Reading symbols from /boot/kernel/zfs.ko...Reading symbols from /boot/ker= nel/zfs.ko.symbols...done. > done. > [...] > Loaded symbols for /boot/kernel/drm.ko > #0 doadump () at /usr/src/sys/kern/kern_shutdown.c:250 > 250 if (textdump_pending) > (kgdb) where > #0 doadump () at /usr/src/sys/kern/kern_shutdown.c:250 > #1 0xffffffff80531fb7 in kern_reboot (howto=3D260) at /usr/src/sys/kern/= kern_shutdown.c:418 > #2 0xffffffff80531a51 in panic (fmt=3DVariable "fmt" is not available. > ) at /usr/src/sys/kern/kern_shutdown.c:591 > #3 0xffffffff803202b7 in db_panic (addr=3DVariable "addr" is not availab= le. > ) at /usr/src/sys/ddb/db_command.c:478 > #4 0xffffffff80320761 in db_command (last_cmdp=3D0xffffffff80c9fb60, cmd= _table=3DVariable "cmd_table" is not available. > ) at /usr/src/sys/ddb/db_command.c:445 > #5 0xffffffff803209b0 in db_command_loop () at /usr/src/sys/ddb/db_comma= nd.c:498 > #6 0xffffffff80322a99 in db_trap (type=3DVariable "type" is not availabl= e. > ) at /usr/src/sys/ddb/db_main.c:229 > #7 0xffffffff80567ba1 in kdb_trap (type=3D3, code=3D0, tf=3D0xffffff8000= 017740) at /usr/src/sys/kern/subr_kdb.c:533 > #8 0xffffffff807cee06 in trap (frame=3D0xffffff8000017740) at /usr/src/s= ys/amd64/amd64/trap.c:590 > #9 0xffffffff807b9303 in calltrap () at /usr/src/sys/amd64/amd64/excepti= on.S:228 > #10 0xffffffff805679fb in kdb_enter (why=3D0xffffffff80955faf "panic", ms= g=3D0xa
) at cpufunc.h:63 > #11 0xffffffff80531a60 in panic (fmt=3DVariable "fmt" is not available. > ) at /usr/src/sys/kern/kern_shutdown.c:574 > #12 0xffffffff805222f9 in _mtx_lock_sleep (m=3DVariable "m" is not availa= ble. > ) at /usr/src/sys/kern/kern_mutex.c:341 > #13 0xffffffff805223a5 in _mtx_lock_flags (m=3DVariable "m" is not availa= ble. > ) at /usr/src/sys/kern/kern_mutex.c:203 > #14 0xffffffff80503789 in proc_reparent (child=3D0xfffffe001290a000, pare= nt=3D0xfffffe0012e48900) at /usr/src/sys/kern/kern_exit.c:912 > #15 0xffffffff80503ed8 in kern_wait (td=3D0xffffff8000017adc, pid=3DVaria= ble "pid" is not available. > ) at /usr/src/sys/kern/kern_exit.c:708 > #16 0xffffffff805043e5 in wait4 (td=3DVariable "td" is not available. > ) at /usr/src/sys/kern/kern_exit.c:653 > #17 0xffffffff805751ab in syscallenter (td=3D0xfffffe00028838c0, sa=3D0xf= fffff8000017bb0) at /usr/src/sys/kern/subr_trap.c:344 > #18 0xffffffff807ce8bc in syscall (frame=3D0xffffff8000017c50) at /usr/sr= c/sys/amd64/amd64/trap.c:910 > #19 0xffffffff807b95cd in Xfast_syscall () at /usr/src/sys/amd64/amd64/ex= ception.S:384 > #20 0x000000000040cb8c in ?? () > Previous frame inner to this frame (corrupt stack?) > (kgdb) f 14 > #14 0xffffffff80503789 in proc_reparent (child=3D0xfffffe001290a000, pare= nt=3D0xfffffe0012e48900) at /usr/src/sys/kern/kern_exit.c:912 > 912 PROC_LOCK(parent); > (kgdb) p *child > $2 =3D {p_list =3D {le_next =3D 0x0, le_prev =3D 0xffffffff80cba328}, p_t= hreads =3D {tqh_first =3D 0xfffffe001287c000, tqh_last =3D 0xfffffe001287c0= 10}, p_slock =3D {lock_object =3D { > lo_name =3D 0xffffffff80954527 "process slock", lo_flags =3D 720896= , lo_data =3D 0, lo_witness =3D 0x0}, mtx_lock =3D 4}, p_ucred =3D 0xfffffe= 00427b5a00, p_fd =3D 0x0,=20 > p_fdtol =3D 0x0, p_stats =3D 0xfffffe0005d82800, p_limit =3D 0x0, p_lim= co =3D {c_links =3D {sle =3D {sle_next =3D 0x0}, tqe =3D {tqe_next =3D 0x0,= tqe_prev =3D 0x0}}, c_time =3D 0, c_arg =3D 0x0,=20 > c_func =3D 0, c_lock =3D 0xfffffe001290a0f8, c_flags =3D 0, c_cpu =3D= 0}, p_sigacts =3D 0xfffffe0042634000, p_flag =3D 268460034, p_state =3D PR= S_ZOMBIE, p_pid =3D 3515, p_hash =3D { > le_next =3D 0x0, le_prev =3D 0xffffff8000222dd8}, p_pglist =3D {le_ne= xt =3D 0x0, le_prev =3D 0xfffffe004a876790}, p_pptr =3D 0xfffffe0002881900,= p_sibling =3D { > le_next =3D 0xfffffe0042640900, le_prev =3D 0xfffffe00028819f0}, p_ch= ildren =3D {lh_first =3D 0x0}, p_mtx =3D {lock_object =3D {lo_name =3D 0xff= ffffff8095451a "process lock",=20 > lo_flags =3D 21168128, lo_data =3D 0, lo_witness =3D 0x0}, mtx_lock= =3D 18446741874728777920}, p_ksi =3D 0xfffffe0005c60150, p_sigqueue =3D {s= q_signals =3D {__bits =3D {0, 0, 0, 0}},=20 > sq_kill =3D {__bits =3D {0, 0, 0, 0}}, sq_list =3D {tqh_first =3D 0x0= , tqh_last =3D 0xfffffe001290a140}, sq_proc =3D 0xfffffe001290a000, sq_flag= s =3D 1}, p_oppid =3D 0,=20 > p_vmspace =3D 0xffffffff80cb7760, p_swtick =3D 21105, p_realtimer =3D {= it_interval =3D {tv_sec =3D 0, tv_usec =3D 0}, it_value =3D {tv_sec =3D 0, = tv_usec =3D 0}}, p_ru =3D {ru_utime =3D { > tv_sec =3D 0, tv_usec =3D 0}, ru_stime =3D {tv_sec =3D 0, tv_usec = =3D 0}, ru_maxrss =3D 21044, ru_ixrss =3D 544640, ru_idrss =3D 334244, ru_i= srss =3D 27264, ru_minflt =3D 2745,=20 > ru_majflt =3D 2158, ru_nswap =3D 0, ru_inblock =3D 3, ru_oublock =3D = 0, ru_msgsnd =3D 134, ru_msgrcv =3D 103, ru_nsignals =3D 0, ru_nvcsw =3D 47= 3, ru_nivcsw =3D 533}, p_rux =3D { > rux_runtime =3D 2346291660, rux_uticks =3D 119, rux_sticks =3D 29, ru= x_iticks =3D 0, rux_uu =3D 948699, rux_su =3D 223223, rux_tu =3D 1171923}, = p_crux =3D {rux_runtime =3D 0,=20 > rux_uticks =3D 0, rux_sticks =3D 0, rux_iticks =3D 0, rux_uu =3D 0, r= ux_su =3D 0, rux_tu =3D 0}, p_profthreads =3D 0, p_exitthreads =3D 0, p_tra= ceflag =3D 0, p_tracevp =3D 0x0,=20 > p_tracecred =3D 0x0, p_textvp =3D 0x0, p_lock =3D 0, p_sigiolst =3D {sl= h_first =3D 0x0}, p_sigparent =3D 20, p_sig =3D 0, p_code =3D 0, p_stops = =3D 0, p_stype =3D 0, p_step =3D 0 '\0',=20 > p_pfsflags =3D 0 '\0', p_nlminfo =3D 0x0, p_aioinfo =3D 0x0, p_singleth= read =3D 0x0, p_suspcount =3D 0, p_xthread =3D 0xfffffe001287c000, p_bounda= ry_count =3D 0, p_pendingcnt =3D 0,=20 > p_itimers =3D 0x0, p_magic =3D 3203398350, p_osrel =3D 900034, p_comm = =3D "claws-mail\000\000\000\000\000\000\000\000\000", p_pgrp =3D 0xfffffe00= 4a876780,=20 > p_sysent =3D 0xffffffff80c6b320, p_args =3D 0xfffffe0005c8b3c0, p_cpuli= mit =3D 9223372036854775807, p_nice =3D 0 '\0', p_fibnum =3D 0, p_xstat =3D= 9, p_klist =3D {kl_list =3D { > slh_first =3D 0x0}, kl_lock =3D 0, kl_unlock =3D 0, kl_assert_locke= d =3D 0xffffffff804fd960 ,=20 > kl_assert_unlocked =3D 0xffffffff804fd940 , kl_lockarg =3D 0x0}, p_numthreads =3D 1, p_md =3D {md_ldt =3D 0x0, md_ld= t_sd =3D {sd_lolimit =3D 0,=20 > sd_lobase =3D 0, sd_type =3D 0, sd_dpl =3D 0, sd_p =3D 0, sd_hilimi= t =3D 0, sd_xx0 =3D 0, sd_gran =3D 0, sd_hibase =3D 0, sd_xx1 =3D 0, sd_mbz= =3D 0, sd_xx2 =3D 0}}, p_itcallout =3D { > c_links =3D {sle =3D {sle_next =3D 0x0}, tqe =3D {tqe_next =3D 0x0, t= qe_prev =3D 0x0}}, c_time =3D 0, c_arg =3D 0x0, c_func =3D 0, c_lock =3D 0x= 0, c_flags =3D 16, c_cpu =3D 0}, p_acflag =3D 16,=20 > p_peers =3D 0x0, p_leader =3D 0xfffffe001290a000, p_emuldata =3D 0x0, p= _label =3D 0x0, p_sched =3D 0xfffffe001290a480, p_ktr =3D {stqh_first =3D 0= x0, stqh_last =3D 0xfffffe001290a430},=20 > p_mqnotifier =3D {lh_first =3D 0x0}, p_dtrace =3D 0xfffffe0005c7a740, p= _pwait =3D {cv_description =3D 0xffffffff80954fbe "ppwait", cv_waiters =3D = 0}, p_dbgwait =3D { > cv_description =3D 0xffffffff80954fc5 "dbgwait", cv_waiters =3D 0}, p= _prev_runtime =3D 0, p_racct =3D 0x0} > (kgdb) p *parent > $3 =3D {p_list =3D {le_next =3D 0xfffffe004261b000, le_prev =3D 0xfffffff= f80cba320}, p_threads =3D {tqh_first =3D 0xfffffe0005e0d8c0, tqh_last =3D 0= xfffffe0005e0d8d0}, p_slock =3D { > lock_object =3D {lo_name =3D 0xffffffff80954527 "process slock", lo_f= lags =3D 720896, lo_data =3D 0, lo_witness =3D 0x0}, mtx_lock =3D 4}, p_ucr= ed =3D 0xfffffe00427b5a00,=20 > p_fd =3D 0xfffffe00128b1c00, p_fdtol =3D 0x0, p_stats =3D 0xfffffe00129= 0c800, p_limit =3D 0xfffffe00427b5300, p_limco =3D {c_links =3D {sle =3D {s= le_next =3D 0x0}, tqe =3D {tqe_next =3D 0x0,=20 > tqe_prev =3D 0x0}}, c_time =3D 0, c_arg =3D 0x0, c_func =3D 0, c_= lock =3D 0xfffffe0012e489f8, c_flags =3D 0, c_cpu =3D 0}, p_sigacts =3D 0xf= ffffe0012e9c000, p_flag =3D 268451842,=20 > p_state =3D PRS_NORMAL, p_pid =3D 3407, p_hash =3D {le_next =3D 0x0, le= _prev =3D 0xffffff8000222a78}, p_pglist =3D {le_next =3D 0x0, le_prev =3D 0= xfffffe0005e59310},=20 > p_pptr =3D 0xfffffe004261b000, p_sibling =3D {le_next =3D 0x0, le_prev = =3D 0xfffffe004261b0f0}, p_children =3D {lh_first =3D 0x0}, p_mtx =3D {lock= _object =3D { > lo_name =3D 0xffffffff8095451a "process lock", lo_flags =3D 2116812= 8, lo_data =3D 0, lo_witness =3D 0x0}, mtx_lock =3D 18446741874728777920}, = p_ksi =3D 0xfffffe0005c5eb60,=20 > p_sigqueue =3D {sq_signals =3D {__bits =3D {0, 0, 0, 0}}, sq_kill =3D {= __bits =3D {0, 0, 0, 0}}, sq_list =3D {tqh_first =3D 0x0, tqh_last =3D 0xff= fffe0012e48a40},=20 > sq_proc =3D 0xfffffe0012e48900, sq_flags =3D 1}, p_oppid =3D 0, p_vms= pace =3D 0xfffffe00128c5310, p_swtick =3D 12384, p_realtimer =3D {it_interv= al =3D {tv_sec =3D 0, tv_usec =3D 0},=20 > it_value =3D {tv_sec =3D 0, tv_usec =3D 0}}, p_ru =3D {ru_utime =3D {= tv_sec =3D 0, tv_usec =3D 0}, ru_stime =3D {tv_sec =3D 0, tv_usec =3D 0}, r= u_maxrss =3D 0, ru_ixrss =3D 0, ru_idrss =3D 0,=20 > ru_isrss =3D 0, ru_minflt =3D 0, ru_majflt =3D 0, ru_nswap =3D 0, ru_= inblock =3D 0, ru_oublock =3D 0, ru_msgsnd =3D 0, ru_msgrcv =3D 0, ru_nsign= als =3D 0, ru_nvcsw =3D 0, ru_nivcsw =3D 0},=20 > p_rux =3D {rux_runtime =3D 1633285860, rux_uticks =3D 63, rux_sticks = =3D 44, rux_iticks =3D 0, rux_uu =3D 482021, rux_su =3D 336649, rux_tu =3D = 818671}, p_crux =3D {rux_runtime =3D 770335510,=20 > rux_uticks =3D 11, rux_sticks =3D 39, rux_iticks =3D 0, rux_uu =3D 84= 947, rux_su =3D 301176, rux_tu =3D 386124}, p_profthreads =3D 0, p_exitthre= ads =3D 0, p_traceflag =3D 0,=20 > p_tracevp =3D 0x0, p_tracecred =3D 0x0, p_textvp =3D 0xfffffe00427ae780= , p_lock =3D 0, p_sigiolst =3D {slh_first =3D 0x0}, p_sigparent =3D 20, p_s= ig =3D 0, p_code =3D 0, p_stops =3D 0,=20 > p_stype =3D 0, p_step =3D 0 '\0', p_pfsflags =3D 0 '\0', p_nlminfo =3D = 0x0, p_aioinfo =3D 0x0, p_singlethread =3D 0x0, p_suspcount =3D 0, p_xthrea= d =3D 0x0, p_boundary_count =3D 0,=20 > p_pendingcnt =3D 0, p_itimers =3D 0x0, p_magic =3D 3203398350, p_osrel = =3D 900025, p_comm =3D "bash", '\0' , p_pgrp =3D 0xfffffe= 0005e59300,=20 > p_sysent =3D 0xffffffff80c6b320, p_args =3D 0xfffffe0002ba2880, p_cpuli= mit =3D 9223372036854775807, p_nice =3D 0 '\0', p_fibnum =3D 0, p_xstat =3D= 0, p_klist =3D {kl_list =3D { > slh_first =3D 0x0}, kl_lock =3D 0xffffffff804fd660 , kl_unlock =3D 0xffffffff804fd680 ,=20 > kl_assert_locked =3D 0xffffffff804fd960 , k= l_assert_unlocked =3D 0xffffffff804fd940 , kl_l= ockarg =3D 0xfffffe0012e489f8},=20 > p_numthreads =3D 1, p_md =3D {md_ldt =3D 0x0, md_ldt_sd =3D {sd_lolimit= =3D 0, sd_lobase =3D 0, sd_type =3D 0, sd_dpl =3D 0, sd_p =3D 0, sd_hilimi= t =3D 0, sd_xx0 =3D 0, sd_gran =3D 0,=20 > sd_hibase =3D 0, sd_xx1 =3D 0, sd_mbz =3D 0, sd_xx2 =3D 0}}, p_itca= llout =3D {c_links =3D {sle =3D {sle_next =3D 0x0}, tqe =3D {tqe_next =3D 0= x0, tqe_prev =3D 0x0}}, c_time =3D 0,=20 > c_arg =3D 0x0, c_func =3D 0, c_lock =3D 0x0, c_flags =3D 16, c_cpu = =3D 0}, p_acflag =3D 0, p_peers =3D 0x0, p_leader =3D 0xfffffe0012e48900, p= _emuldata =3D 0x0, p_label =3D 0x0,=20 > p_sched =3D 0xfffffe0012e48d80, p_ktr =3D {stqh_first =3D 0x0, stqh_las= t =3D 0xfffffe0012e48d30}, p_mqnotifier =3D {lh_first =3D 0x0}, p_dtrace = =3D 0xfffffe0005d85b80, p_pwait =3D { > cv_description =3D 0xffffffff80954fbe "ppwait", cv_waiters =3D 0}, p_= dbgwait =3D {cv_description =3D 0xffffffff80954fc5 "dbgwait", cv_waiters = =3D 0}, p_prev_runtime =3D 0,=20 > p_racct =3D 0x0} >=20 > I'm not sure if switching to the console first matters. >=20 > Before the panic, the states of gdb and claws-mail were: >=20 > fk@r500 ~ $procstat -kk $(pgrep claws-mail) > PID TID COMM TDNAME KSTACK = =20 > 15813 100528 claws-mail initial thread mi_switch+0x21d thread_sus= pend_switch+0x103 ptracestop+0x7a cursig+0x4af ast+0x198 doreti_ast+0x1f=20 > fk@r500 ~ $procstat -kk $(pgrep gdb) > PID TID COMM TDNAME KSTACK = =20 > 15823 100928 gdb - mi_switch+0x21d sleepq_swi= tch+0x123 sleepq_catch_signals+0x2a2 sleepq_wait_sig+0x16 _cv_wait_sig+0x14= c tty_wait+0x48 ttydisc_read+0xd4 ttydev_read+0xab devfs_read_f+0x88 dofile= read+0xa1 kern_readv+0x60 read+0x55 syscallenter+0x1cb syscall+0x4c Xfast_s= yscall+0xdd=20 >=20 > I believe I also reproduced the problem with a kernel from Tuesday, > but dumping core from ddb failed so I can't check. >=20 > I cannot reproduce the panic with a kernel from 2011-03-12 > which I haven't deleted yet, but didn't try to bisect it further. >=20 > gdb can't attach to claws-mail either, but the panic doesn't occur: >=20 > fk@r500 ~ $gdb -p $(pgrep claws-mail) > 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 "amd64-marcel-freebsd". > Attaching to process 3432 > /usr/src/gnu/usr.bin/gdb/libgdb/../../../../contrib/gdb/gdb/solib-svr4.c:= 1444: i > nternal-error: legacy_fetch_link_map_offsets called without legacy link_m= ap supp > ort enabled. > A problem internal to GDB has been detected, > further debugging may prove unreliable. > Quit this debugging session? (y or n) y >=20 > /usr/src/gnu/usr.bin/gdb/libgdb/../../../../contrib/gdb/gdb/solib-svr4.c:= 1444: i > nternal-error: legacy_fetch_link_map_offsets called without legacy link_m= ap supp > ort enabled. > A problem internal to GDB has been detected, > further debugging may prove unreliable. > Create a core file of GDB? (y or n) n >=20 > In related news, the kernel from yesterday also seems to panic/hang/whate= ver > when claws-mail segfaults due to an invalid memory access, but as I was r= unning > X, I got no core dumps for those problems either. For the first problem, try patch at the end. Regarding the 'panic/hang/whatever', I cannot reproduce it with a program that specifically access unmapped memory. You would need to catch core dump and provide the backtrace. diff --git a/sys/kern/kern_exit.c b/sys/kern/kern_exit.c index 5fec31b..2d35ed5 100644 --- a/sys/kern/kern_exit.c +++ b/sys/kern/kern_exit.c @@ -903,15 +903,19 @@ loop: void proc_reparent(struct proc *child, struct proc *parent) { + int locked; =20 sx_assert(&proctree_lock, SX_XLOCKED); PROC_LOCK_ASSERT(child, MA_OWNED); if (child->p_pptr =3D=3D parent) return; =20 - PROC_LOCK(parent); + locked =3D PROC_LOCKED(parent); + if (!locked) + PROC_LOCK(parent); racct_add_force(parent, RACCT_NPROC, 1); - PROC_UNLOCK(parent); + if (!locked) + PROC_UNLOCK(parent); PROC_LOCK(child->p_pptr); racct_sub(child->p_pptr, RACCT_NPROC, 1); sigqueue_take(child->p_ksi); --KEQY95CNCHRmtrVV Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk2hylYACgkQC3+MBN1Mb4hNmACghS1QdoHXjnkmm1prDKizRcAD 8OMAmgPRn9T8JuIvI7vyaWE6LczVdrTG =R4wT -----END PGP SIGNATURE----- --KEQY95CNCHRmtrVV-- From owner-freebsd-current@FreeBSD.ORG Sun Apr 10 16:36:31 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C62F4106564A for ; Sun, 10 Apr 2011 16:36:31 +0000 (UTC) (envelope-from freebsd-listen@fabiankeil.de) Received: from smtprelay05.ispgateway.de (smtprelay05.ispgateway.de [80.67.31.100]) by mx1.freebsd.org (Postfix) with ESMTP id 549118FC08 for ; Sun, 10 Apr 2011 16:36:31 +0000 (UTC) Received: from [87.78.60.163] (helo=fabiankeil.de) by smtprelay05.ispgateway.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1Q8xcg-0005lP-Rl; Sun, 10 Apr 2011 18:36:29 +0200 Date: Sun, 10 Apr 2011 18:36:23 +0200 From: Fabian Keil To: Kostik Belousov Message-ID: <20110410183623.29b3671e@fabiankeil.de> In-Reply-To: <20110410151847.GT78089@deviant.kiev.zoral.com.ua> References: <20110410153759.025aa4e2@fabiankeil.de> <20110410151847.GT78089@deviant.kiev.zoral.com.ua> X-PGP-KEY-URL: http://www.fabiankeil.de/gpg-keys/freebsd-listen-2008-08-18.asc Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/QM0JLb2yJWMd3dtFlJb+upg"; protocol="application/pgp-signature" X-Df-Sender: 775067 Cc: FreeBSD Current Subject: Re: panic: _mtx_lock_sleep: recursed on non-recursive mutex process lock @ /usr/src/sys/kern/kern_exit.c:912 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Apr 2011 16:36:31 -0000 --Sig_/QM0JLb2yJWMd3dtFlJb+upg Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Kostik Belousov wrote: > On Sun, Apr 10, 2011 at 03:37:59PM +0200, Fabian Keil wrote: > > The following panic seems to be reliably reproducible with sources > > from yesterday (and today) by running claws-mail in X, switching to > > the console and trying to attach gdb to it with 'gdb -p $(pgrep claws-m= ail)'. > >=20 > > gdb somehow fails to attach, and after leaving gdb the panic occurs. > > fk@r500 /usr/crash $kgdb /boot/kernel/kernel vmcore.0=20 > > GNU gdb 6.1.1 [FreeBSD] > > Copyright 2004 Free Software Foundation, Inc. > > GDB is free software, covered by the GNU General Public License, and yo= u are > > welcome to change it and/or distribute copies of it under certain condi= tions. > > Type "show copying" to see the conditions. > > There is absolutely no warranty for GDB. Type "show warranty" for deta= ils. > > This GDB was configured as "amd64-marcel-freebsd"... > >=20 > > Unread portion of the kernel message buffer: > > panic: _mtx_lock_sleep: recursed on non-recursive mutex process lock @ = /usr/src/sys/kern/kern_exit.c:912 > >=20 > > cpuid =3D 0 > > KDB: enter: panic > > panic: from debugger > > cpuid =3D 0 > > Uptime: 3m48s > > Physical memory: 1974 MB > > Dumping 331 MB: 316 300 284 268 252 236 220 204 188 172 156 140 124 108= 92 76 60 44 28 12 > >=20 > > Reading symbols from /boot/kernel/zfs.ko...Reading symbols from /boot/k= ernel/zfs.ko.symbols...done. > > done. > > [...] > > Loaded symbols for /boot/kernel/drm.ko > > #0 doadump () at /usr/src/sys/kern/kern_shutdown.c:250 > > 250 if (textdump_pending) > > (kgdb) where > > #0 doadump () at /usr/src/sys/kern/kern_shutdown.c:250 > > #11 0xffffffff80531a60 in panic (fmt=3DVariable "fmt" is not available. > > ) at /usr/src/sys/kern/kern_shutdown.c:574 > > #12 0xffffffff805222f9 in _mtx_lock_sleep (m=3DVariable "m" is not avai= lable. > > ) at /usr/src/sys/kern/kern_mutex.c:341 > > #13 0xffffffff805223a5 in _mtx_lock_flags (m=3DVariable "m" is not avai= lable. > > ) at /usr/src/sys/kern/kern_mutex.c:203 > > #14 0xffffffff80503789 in proc_reparent (child=3D0xfffffe001290a000, pa= rent=3D0xfffffe0012e48900) at /usr/src/sys/kern/kern_exit.c:912 > > #15 0xffffffff80503ed8 in kern_wait (td=3D0xffffff8000017adc, pid=3DVar= iable "pid" is not available. > > ) at /usr/src/sys/kern/kern_exit.c:708 > > #16 0xffffffff805043e5 in wait4 (td=3DVariable "td" is not available. > > ) at /usr/src/sys/kern/kern_exit.c:653 > > #17 0xffffffff805751ab in syscallenter (td=3D0xfffffe00028838c0, sa=3D0= xffffff8000017bb0) at /usr/src/sys/kern/subr_trap.c:344 > > #18 0xffffffff807ce8bc in syscall (frame=3D0xffffff8000017c50) at /usr/= src/sys/amd64/amd64/trap.c:910 > > #19 0xffffffff807b95cd in Xfast_syscall () at /usr/src/sys/amd64/amd64/= exception.S:384 > > #20 0x000000000040cb8c in ?? () > > Previous frame inner to this frame (corrupt stack?) > > (kgdb) f 14 > > #14 0xffffffff80503789 in proc_reparent (child=3D0xfffffe001290a000, pa= rent=3D0xfffffe0012e48900) at /usr/src/sys/kern/kern_exit.c:912 > > 912 PROC_LOCK(parent); =20 > > I cannot reproduce the panic with a kernel from 2011-03-12 > > which I haven't deleted yet, but didn't try to bisect it further. =20 > > In related news, the kernel from yesterday also seems to panic/hang/wha= tever > > when claws-mail segfaults due to an invalid memory access, but as I was= running > > X, I got no core dumps for those problems either. >=20 > For the first problem, try patch at the end. It solves the problem. > Regarding the 'panic/hang/whatever', I cannot reproduce it with a program > that specifically access unmapped memory. You would need to catch core > dump and provide the backtrace. With your patch, I can no longer reproduce the second issue either. Maybe the segfault itself wasn't the problem and claws-mail's forked crash handler simply triggered the same panic. Thanks a lot. Fabian --Sig_/QM0JLb2yJWMd3dtFlJb+upg Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (FreeBSD) iEYEARECAAYFAk2h3I4ACgkQBYqIVf93VJ3OAwCbBTCs/Khmm/SkHAn7dFYHQZaI F1AAoMeTEjxXPfEYdyZcif78+5beq3dx =rrU+ -----END PGP SIGNATURE----- --Sig_/QM0JLb2yJWMd3dtFlJb+upg-- From owner-freebsd-current@FreeBSD.ORG Sun Apr 10 19:36:29 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2F646106566B; Sun, 10 Apr 2011 19:36:29 +0000 (UTC) (envelope-from to.my.trociny@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 060348FC1A; Sun, 10 Apr 2011 19:36:27 +0000 (UTC) Received: by fxm11 with SMTP id 11so4226105fxm.13 for ; Sun, 10 Apr 2011 12:36:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:from:to:cc:subject:references:x-comment-to :sender:date:in-reply-to:message-id:user-agent:mime-version :content-type; bh=KyOZAmSsjuZU3q1tbNSbI4Flcnl7HSZRedPVlWIwVTs=; b=ohFrU7IhQIhND9zMUaT8Z68aHGDyNrehgjkq/D33Wm6Q5HW12PNTDHMUlbgg0KIToe TD6dG36rWvcnDi9OHx1hxIFOVCKym4TTrsBYbrSHXzxk43w5qyUdOAlgX1mjwnWXp7fq qtATBxKoKx9snLT1Yaj4XN9YQMHlpZx53vVA4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:subject:references:x-comment-to:sender:date:in-reply-to :message-id:user-agent:mime-version:content-type; b=ov2ZQbw+RoN9yQ57EYmcipRnowH+imMzp+mHbbCy0I7NMdieIz6U88hdbo2ugbJAd1 9248gi1eh9DMiCSm2b6kMxAR7fNVbjBJuVDueeRuHj8t69wF5dXdjmsBmaZU3s9bWreL Wtzw+kY7Gllanl3uncGhxEtlWYobUnYzWU+r4= Received: by 10.223.23.195 with SMTP id s3mr1453799fab.83.1302464187046; Sun, 10 Apr 2011 12:36:27 -0700 (PDT) Received: from localhost ([95.69.172.154]) by mx.google.com with ESMTPS id t2sm1377341faa.23.2011.04.10.12.36.23 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 10 Apr 2011 12:36:24 -0700 (PDT) From: Mikolaj Golub To: Freddie Cash References: <20110402084431.GB1849@garage.freebsd.pl> X-Comment-To: Freddie Cash Sender: Mikolaj Golub Date: Sun, 10 Apr 2011 22:36:22 +0300 In-Reply-To: (Freddie Cash's message of "Mon, 4 Apr 2011 11:08:16 -0700") Message-ID: <86aafxx5jd.fsf@kopusha.home.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: FreeBSD Filesystems , FreeBSD Stable , FreeBSD-Current , Pawel Jakub Dawidek Subject: Re: Any success stories for HAST + ZFS? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Apr 2011 19:36:29 -0000 On Mon, 4 Apr 2011 11:08:16 -0700 Freddie Cash wrote: FC> Once the deadlock patches above are MFC'd to -STABLE, I can do an FC> upgrade cycle and test them. Committed to STABLE. -- Mikolaj Golub From owner-freebsd-current@FreeBSD.ORG Sun Apr 10 20:19:59 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 127F5106566C; Sun, 10 Apr 2011 20:19:59 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 0B8DF8FC14; Sun, 10 Apr 2011 20:19:57 +0000 (UTC) Received: by bwz12 with SMTP id 12so5186504bwz.13 for ; Sun, 10 Apr 2011 13:19:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=Mx78LRKRvuwHnOi+q2hCAyBhIvWsSHXZueFWQCImCxQ=; b=kVaSRX6IOIri9BUg2B2fE9+/lukMlqH0qEn+DiXm9yZSUqHsautf5blKa9RXbyXZ3J WE79q10T4QkJxJks0Yz2FE/nyjzP0OIpLuYwzfpcC9/8AhAIZTC/kyyk/ctHrSscQVAA fBwYdQ5xy3JofT3qRpd4EsxK38gRoBClStUXY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=TkrEDw/ltdxlzjJYf+hM5VZJFlfGIbJHTc+HV6RFPAwCErYB/8mLFECzMykaOd5CCW N0i9UPbl6aguJMuXn7S+GHHD2kYCoHoDZztUXp2tgyPvnmpjqYurLrEIoFSDj0TjpWMb 823i/GusButnPDmWT4uGSJd9dV/DCSYTnDaKM= Received: by 10.204.81.213 with SMTP id y21mr3425752bkk.63.1302466781406; Sun, 10 Apr 2011 13:19:41 -0700 (PDT) Received: from mavbook2.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id t1sm2823228bkx.19.2011.04.10.13.19.39 (version=SSLv3 cipher=OTHER); Sun, 10 Apr 2011 13:19:40 -0700 (PDT) Sender: Alexander Motin Message-ID: <4DA210D3.5090807@FreeBSD.org> Date: Sun, 10 Apr 2011 23:19:31 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: Alexander Best References: <20110331223339.GA13682@freebsd.org> <201104010843.47367.jhb@freebsd.org> <20110404204316.GA11367@freebsd.org> <4D9D9917.3030102@FreeBSD.org> <20110410115644.GA55815@freebsd.org> In-Reply-To: <20110410115644.GA55815@freebsd.org> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-scsi@freebsd.org, freebsd-current@freebsd.org Subject: Re: multiple issues with devstat_*(9) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Apr 2011 20:19:59 -0000 Alexander Best wrote: > On Thu Apr 7 11, Alexander Motin wrote: >> Alexander Best wrote: >>> On Fri Apr 1 11, John Baldwin wrote: >>>> On Thursday, March 31, 2011 6:33:39 pm Alexander Best wrote: >>>>> i think there are multiple issues with devstat. i found the following in >>>>> devicestat.h: >> ... >> >>>>> funny thing is i found the following in scsi_pass.c: >>>>> >>>>> softc->device_stats = devstat_new_entry("pass", >>>>> periph->unit_number, 0, >>>>> DEVSTAT_NO_BLOCKSIZE >>>>> | (no_tags ? DEVSTAT_NO_ORDERED_TAGS : 0), >>>>> softc->pd_type | >>>>> DEVSTAT_TYPE_IF_SCSI | >>>>> DEVSTAT_TYPE_PASS, >>>>> DEVSTAT_PRIORITY_PASS); >>>>> >>>>> ...so pass* *should* show up under iostat -t scsi. >> As I can see, this is a bug (or feature) of the libdevstat / >> devstat_selectdevs(). If you specify any -t, then pass devices will be >> reported only if you request "pass" specifically. >> >>>> Hmm, pass devices for adaX should not be SCSI though, they should be ide I >>>> think. >>> i think the situation with ATA_CAM should be discussed further. still besides >>> this issue there are many more with devstat(3). >>> >>> i'll try to track all the "devstat_new_entry()" occurrences and see if some >>> issues can be fixed. maybe only the proper DEVSTAT_* args were forgotten. >> Assuming that SCSI and IDE in -t option means transport type, and >> assuming that we count everything except ATA and SATA as SCSI, I've made >> following patch, that should fix issues from the CAM side: >> http://people.freebsd.org/~mav/cam.devstat.patch > > with your patch i get the following output: > > otaku% iostat -t ide > tty ada0 ada1 cpu > tin tout KB/t tps MB/s KB/t tps MB/s us ni sy in id > 6 144 14.21 6 0.09 20.46 40 0.81 2 0 3 0 95 > otaku% iostat -t scsi > tty cd0 cpu > tin tout KB/t tps MB/s us ni sy in id > 6 146 2.32 0 0.00 2 0 3 0 95 > otaku% iostat -t pass > tty pass0 pass1 pass2 cpu > tin tout KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s us ni sy in id > 6 147 0.36 0 0.00 0.36 0 0.00 0.00 0 0.00 2 0 3 0 95 > otaku% iostat -t da > tty ada0 ada1 cpu > tin tout KB/t tps MB/s KB/t tps MB/s us ni sy in id > 6 147 14.21 6 0.08 20.46 37 0.75 1 0 3 0 95 > otaku% iostat -t cd > tty cd0 cpu > tin tout KB/t tps MB/s us ni sy in id > 7 147 2.32 0 0.00 1 0 3 0 95 > otaku% iostat -t other > tty cpu > tin tout us ni sy in id > 7 149 1 0 3 0 95 > otaku% iostat -n 100 > tty ada0 ada1 cd0 pass0 pass1 pass2 cpu > tin tout KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s us ni sy in id > 6 135 14.21 5 0.07 20.44 32 0.64 2.32 0 0.00 0.36 0 0.00 0.36 0 0.00 0.00 0 0.00 1 0 3 0 96 > > the the remaining issues imho are: > > 1) ada* and cd* are SATA/ATA devices. so i think they should show up together > either under ide *or* scsi. i don't have any *real* scsi devices. I've just retested the patch and haven't reproduced your problem: %iostat -d da0 ada0 da1 cd0 KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s 0.01 0 0.00 3.27 1 0.00 2.65 1 0.00 0.00 0 0.00 %iostat -d -t ide da0 ada0 cd0 KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s 0.01 0 0.00 3.27 1 0.00 0.00 0 0.00 %iostat -d -t scsi da1 KB/t tps MB/s 2.65 1 0.00 %iostat -d -t pass pass0 pass1 pass2 pass3 KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s 0.00 0 0.00 0.00 0 0.00 0.00 0 0.00 0.00 0 0.00 %iostat -d -t ide,pass pass0 pass1 pass2 KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s 0.00 0 0.00 0.00 0 0.00 0.00 0 0.00 %iostat -d -t scsi,pass pass3 KB/t tps MB/s 0.00 0 0.00 da0 is an PATA ATAPI ZIP, da1 - USB floppy, ada0 - SATA HDD, cd0 - PATA ATAPI CD-ROM. Just an idea, aren't you are using legacy ata(4) + atapicam for your cd0? atapicam lies that it's buses are SPI (SCSI). > 2) the pass* devices still don't show up under ide/scsi/other. that's ok, but > then the src comments and manual pages need to be changed accordingly. As I have told - it is a bug/feature of libdevstat. It should not be difficult to fix, if it is really a bug. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Mon Apr 11 02:56:46 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 25FFB1065673; Mon, 11 Apr 2011 02:56:46 +0000 (UTC) Date: Mon, 11 Apr 2011 02:56:46 +0000 From: Alexander Best To: Alexander Motin Message-ID: <20110411025646.GA46088@freebsd.org> References: <20110331223339.GA13682@freebsd.org> <201104010843.47367.jhb@freebsd.org> <20110404204316.GA11367@freebsd.org> <4D9D9917.3030102@FreeBSD.org> <20110410115644.GA55815@freebsd.org> <4DA210D3.5090807@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4DA210D3.5090807@FreeBSD.org> Cc: freebsd-scsi@freebsd.org, freebsd-current@freebsd.org Subject: Re: multiple issues with devstat_*(9) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2011 02:56:46 -0000 On Sun Apr 10 11, Alexander Motin wrote: > Alexander Best wrote: > > On Thu Apr 7 11, Alexander Motin wrote: > >> Alexander Best wrote: > >>> On Fri Apr 1 11, John Baldwin wrote: > >>>> On Thursday, March 31, 2011 6:33:39 pm Alexander Best wrote: > >>>>> i think there are multiple issues with devstat. i found the following in > >>>>> devicestat.h: > >> ... > >> > >>>>> funny thing is i found the following in scsi_pass.c: > >>>>> > >>>>> softc->device_stats = devstat_new_entry("pass", > >>>>> periph->unit_number, 0, > >>>>> DEVSTAT_NO_BLOCKSIZE > >>>>> | (no_tags ? DEVSTAT_NO_ORDERED_TAGS : 0), > >>>>> softc->pd_type | > >>>>> DEVSTAT_TYPE_IF_SCSI | > >>>>> DEVSTAT_TYPE_PASS, > >>>>> DEVSTAT_PRIORITY_PASS); > >>>>> > >>>>> ...so pass* *should* show up under iostat -t scsi. > >> As I can see, this is a bug (or feature) of the libdevstat / > >> devstat_selectdevs(). If you specify any -t, then pass devices will be > >> reported only if you request "pass" specifically. > >> > >>>> Hmm, pass devices for adaX should not be SCSI though, they should be ide I > >>>> think. > >>> i think the situation with ATA_CAM should be discussed further. still besides > >>> this issue there are many more with devstat(3). > >>> > >>> i'll try to track all the "devstat_new_entry()" occurrences and see if some > >>> issues can be fixed. maybe only the proper DEVSTAT_* args were forgotten. > >> Assuming that SCSI and IDE in -t option means transport type, and > >> assuming that we count everything except ATA and SATA as SCSI, I've made > >> following patch, that should fix issues from the CAM side: > >> http://people.freebsd.org/~mav/cam.devstat.patch > > > > with your patch i get the following output: > > > > otaku% iostat -t ide > > tty ada0 ada1 cpu > > tin tout KB/t tps MB/s KB/t tps MB/s us ni sy in id > > 6 144 14.21 6 0.09 20.46 40 0.81 2 0 3 0 95 > > otaku% iostat -t scsi > > tty cd0 cpu > > tin tout KB/t tps MB/s us ni sy in id > > 6 146 2.32 0 0.00 2 0 3 0 95 > > otaku% iostat -t pass > > tty pass0 pass1 pass2 cpu > > tin tout KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s us ni sy in id > > 6 147 0.36 0 0.00 0.36 0 0.00 0.00 0 0.00 2 0 3 0 95 > > otaku% iostat -t da > > tty ada0 ada1 cpu > > tin tout KB/t tps MB/s KB/t tps MB/s us ni sy in id > > 6 147 14.21 6 0.08 20.46 37 0.75 1 0 3 0 95 > > otaku% iostat -t cd > > tty cd0 cpu > > tin tout KB/t tps MB/s us ni sy in id > > 7 147 2.32 0 0.00 1 0 3 0 95 > > otaku% iostat -t other > > tty cpu > > tin tout us ni sy in id > > 7 149 1 0 3 0 95 > > otaku% iostat -n 100 > > tty ada0 ada1 cd0 pass0 pass1 pass2 cpu > > tin tout KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s us ni sy in id > > 6 135 14.21 5 0.07 20.44 32 0.64 2.32 0 0.00 0.36 0 0.00 0.36 0 0.00 0.00 0 0.00 1 0 3 0 96 > > > > the the remaining issues imho are: > > > > 1) ada* and cd* are SATA/ATA devices. so i think they should show up together > > either under ide *or* scsi. i don't have any *real* scsi devices. > > I've just retested the patch and haven't reproduced your problem: > %iostat -d > da0 ada0 da1 cd0 > KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s > 0.01 0 0.00 3.27 1 0.00 2.65 1 0.00 0.00 0 0.00 > %iostat -d -t ide > da0 ada0 cd0 > KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s > 0.01 0 0.00 3.27 1 0.00 0.00 0 0.00 > %iostat -d -t scsi > da1 > KB/t tps MB/s > 2.65 1 0.00 > %iostat -d -t pass > pass0 pass1 pass2 pass3 > KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s > 0.00 0 0.00 0.00 0 0.00 0.00 0 0.00 0.00 0 0.00 > %iostat -d -t ide,pass > pass0 pass1 pass2 > KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s > 0.00 0 0.00 0.00 0 0.00 0.00 0 0.00 > %iostat -d -t scsi,pass > pass3 > KB/t tps MB/s > 0.00 0 0.00 > > da0 is an PATA ATAPI ZIP, da1 - USB floppy, ada0 - SATA HDD, cd0 - PATA > ATAPI CD-ROM. > > Just an idea, aren't you are using legacy ata(4) + atapicam for your > cd0? atapicam lies that it's buses are SPI (SCSI). my cd0 is a pata atapi dvdrom drive and i have the following in my kernel conf: device atacore device ahci device atajmicron device atapci #device atapicd device atapicam device umass device scbus device cd device pass device da device random device pty device md the dmesg entries for cd0 are: cam_periph_alloc: attempt to re-allocate valid device cd0 rejected cdasync: Unable to attach new device due to status 0x6 cd0 at ata2 bus 0 scbus8 target 0 lun 0 cd0: Removable CD-ROM SCSI-0 device cd0: 3.300MB/s transfers cd0: cd present [2149024 x 2048 byte records] cheers. alex > > > 2) the pass* devices still don't show up under ide/scsi/other. that's ok, but > > then the src comments and manual pages need to be changed accordingly. > > As I have told - it is a bug/feature of libdevstat. It should not be > difficult to fix, if it is really a bug. > > -- > Alexander Motin -- a13x From owner-freebsd-current@FreeBSD.ORG Mon Apr 11 06:44:25 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E2606106564A; Mon, 11 Apr 2011 06:44:25 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id A3D6F8FC18; Mon, 11 Apr 2011 06:44:24 +0000 (UTC) Received: by bwz12 with SMTP id 12so5497436bwz.13 for ; Sun, 10 Apr 2011 23:44:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=nMN585lCtONI+mcTgwDbhuSTBdHhSt41BK2knSHyINg=; b=WuYn5pV4WYTTFn0P/ryKrDhVsGCyMgajaqFDIcxzCreStmWUtowX+358h9LwDtZ2VV GQ+oxSeuY70NmkWPnBPTIWnhYMJfbNryP/SR8YxTGSn6WmvBVDfQdL8K6LP9O/M4Y7gW A+q5cjLK0GMw9mQ8WKmnT4q/TJagK3h4Wf+1s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=UO7Q1Low/AKnqb2rvZtJ9tPcaVpKk+yhg4SmNaYjI1kdsRyW61AFev7jnhMqI39c+T qLhCZZKMng1GlbKj6mAG+fJx1llkCuD0jT8gRBL6nqYBzBLFs5qrVtSVM1qNiCOEBJWs lhyS9LvwG2+lrJnqP7zlfSI0jpbmMMkXwoQ5o= Received: by 10.204.81.27 with SMTP id v27mr4518536bkk.115.1302504263042; Sun, 10 Apr 2011 23:44:23 -0700 (PDT) Received: from mavbook2.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id x6sm3008062bkv.12.2011.04.10.23.44.21 (version=SSLv3 cipher=OTHER); Sun, 10 Apr 2011 23:44:22 -0700 (PDT) Sender: Alexander Motin Message-ID: <4DA2A33B.8010807@FreeBSD.org> Date: Mon, 11 Apr 2011 09:44:11 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: Alexander Best References: <20110331223339.GA13682@freebsd.org> <201104010843.47367.jhb@freebsd.org> <20110404204316.GA11367@freebsd.org> <4D9D9917.3030102@FreeBSD.org> <20110410115644.GA55815@freebsd.org> <4DA210D3.5090807@FreeBSD.org> <20110411025646.GA46088@freebsd.org> In-Reply-To: <20110411025646.GA46088@freebsd.org> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-scsi@freebsd.org, freebsd-current@freebsd.org Subject: Re: multiple issues with devstat_*(9) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2011 06:44:26 -0000 Alexander Best wrote: > On Sun Apr 10 11, Alexander Motin wrote: >> Alexander Best wrote: >>> On Thu Apr 7 11, Alexander Motin wrote: >>>> Assuming that SCSI and IDE in -t option means transport type, and >>>> assuming that we count everything except ATA and SATA as SCSI, I've made >>>> following patch, that should fix issues from the CAM side: >>>> http://people.freebsd.org/~mav/cam.devstat.patch >>> with your patch i get the following output: >>> >>> otaku% iostat -t ide >>> tty ada0 ada1 cpu >>> tin tout KB/t tps MB/s KB/t tps MB/s us ni sy in id >>> 6 144 14.21 6 0.09 20.46 40 0.81 2 0 3 0 95 >>> otaku% iostat -t scsi >>> tty cd0 cpu >>> tin tout KB/t tps MB/s us ni sy in id >>> 6 146 2.32 0 0.00 2 0 3 0 95 >>> otaku% iostat -t pass >>> tty pass0 pass1 pass2 cpu >>> tin tout KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s us ni sy in id >>> 6 147 0.36 0 0.00 0.36 0 0.00 0.00 0 0.00 2 0 3 0 95 >>> otaku% iostat -t da >>> tty ada0 ada1 cpu >>> tin tout KB/t tps MB/s KB/t tps MB/s us ni sy in id >>> 6 147 14.21 6 0.08 20.46 37 0.75 1 0 3 0 95 >>> otaku% iostat -t cd >>> tty cd0 cpu >>> tin tout KB/t tps MB/s us ni sy in id >>> 7 147 2.32 0 0.00 1 0 3 0 95 >>> otaku% iostat -t other >>> tty cpu >>> tin tout us ni sy in id >>> 7 149 1 0 3 0 95 >>> otaku% iostat -n 100 >>> tty ada0 ada1 cd0 pass0 pass1 pass2 cpu >>> tin tout KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s us ni sy in id >>> 6 135 14.21 5 0.07 20.44 32 0.64 2.32 0 0.00 0.36 0 0.00 0.36 0 0.00 0.00 0 0.00 1 0 3 0 96 >>> >>> the the remaining issues imho are: >>> >>> 1) ada* and cd* are SATA/ATA devices. so i think they should show up together >>> either under ide *or* scsi. i don't have any *real* scsi devices. >> I've just retested the patch and haven't reproduced your problem: >> %iostat -d >> da0 ada0 da1 cd0 >> KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s >> 0.01 0 0.00 3.27 1 0.00 2.65 1 0.00 0.00 0 0.00 >> %iostat -d -t ide >> da0 ada0 cd0 >> KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s >> 0.01 0 0.00 3.27 1 0.00 0.00 0 0.00 >> %iostat -d -t scsi >> da1 >> KB/t tps MB/s >> 2.65 1 0.00 >> %iostat -d -t pass >> pass0 pass1 pass2 pass3 >> KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s >> 0.00 0 0.00 0.00 0 0.00 0.00 0 0.00 0.00 0 0.00 >> %iostat -d -t ide,pass >> pass0 pass1 pass2 >> KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s >> 0.00 0 0.00 0.00 0 0.00 0.00 0 0.00 >> %iostat -d -t scsi,pass >> pass3 >> KB/t tps MB/s >> 0.00 0 0.00 >> >> da0 is an PATA ATAPI ZIP, da1 - USB floppy, ada0 - SATA HDD, cd0 - PATA >> ATAPI CD-ROM. >> >> Just an idea, aren't you are using legacy ata(4) + atapicam for your >> cd0? atapicam lies that it's buses are SPI (SCSI). > > my cd0 is a pata atapi dvdrom drive and i have the following in my kernel conf: > > device atacore > device ahci > device atajmicron > device atapci > #device atapicd > device atapicam > > device umass > device scbus > device cd > device pass > device da > device random > device pty > device md > > the dmesg entries for cd0 are: > > cam_periph_alloc: attempt to re-allocate valid device cd0 rejected > cdasync: Unable to attach new device due to status 0x6 > cd0 at ata2 bus 0 scbus8 target 0 lun 0 > cd0: Removable CD-ROM SCSI-0 device > cd0: 3.300MB/s transfers > cd0: cd present [2149024 x 2048 byte records] Aha, that's it. It is atapicam's lie. atapicam is one of a things that will go away during migration to CAM ATA. If you remove `device atapicam`, but add `options ATA_CAM` instead, CAM will manage that bus directly and report it as ATA. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Mon Apr 11 07:31:57 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8C79D106566C for ; Mon, 11 Apr 2011 07:31:57 +0000 (UTC) (envelope-from ftp51246-2575596@sh4-5.1blu.de) Received: from sh4-5.1blu.de (sh4-5.1blu.de [213.83.63.54]) by mx1.freebsd.org (Postfix) with ESMTP id 0DC188FC0A for ; Mon, 11 Apr 2011 07:31:56 +0000 (UTC) Received: from ftp51246-2575596 by sh4-5.1blu.de with local (Exim 4.50) id 1Q9BbC-000542-Ba; Mon, 11 Apr 2011 09:31:50 +0200 Date: Mon, 11 Apr 2011 09:31:49 +0200 From: Matthias Apitz To: Alexander Kabaev Message-ID: <20110411073145.GA18454@sh4-5.1blu.de> References: <20110408084232.GA28116@sh4-5.1blu.de> <4D9EE09F.6050409@FreeBSD.org> <20110408120335.GA2648@sh4-5.1blu.de> <20110408172459.78c5d730@kan.dnsalias.net> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="YiEDa0DAkWCtVeE4" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20110408172459.78c5d730@kan.dnsalias.net> X-Operating-System: FreeBSD 7.0-RELEASE (i386) User-Agent: Mutt/1.5.9i Cc: freebsd-current@freebsd.org Subject: Re: vmware-tools-freebsd && "No drivers for x.org version: 7.6.5." X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Matthias Apitz List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2011 07:31:57 -0000 --YiEDa0DAkWCtVeE4 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit El día Friday, April 08, 2011 a las 05:24:59PM -0400, Alexander Kabaev escribió: > > > X.org 7.5 already has VMware drivers, so you can just install the > > > x11-drivers/xf86-input-vmmouse and x11-drivers/xf86-video-vmware > > > ports. > > > > > > Alternatively, run "make config" in x11-drivers/xorg-drivers, check > > > the "VMMOUSE" and "VMWARE" entries, and rebuild this meta-port. > > > > Dimitry, > > > > Thanks for your kind & fast answer; does this also mean that I could > > completely get rid of the VMware' vmware-tools-freebsd? I'm using on > > the 8-CURRENT system the emulators/open-vom-tools and will install > > them in the 9-CURRENT too. > > > > Thanks again > > > > matthias > > > I am not Dmirty, but I will answer anyway. If you install open-vm-tools > and xf86-input-vmmouse and xf86-video-vmware drivers, you won't need to > bother fighting with vmware tools anymore. The open-vm-tools port > installs vmware-user-suid-wrapper binary without SUID bit, you will > need to fix that. Also, vmblock driver currently crashes > FreeBSD-current kernel, so you will need to remove or > rename /boot/modules/vmblock.ko > and /usr/local/lib/vmware-tools/modules/drivers/vmblock.ko so that > vmware-user-suid-wrapper does not load it for you automatically. Hello, I removed the VMware' vmware-tools-freebsd and installed from the ports x11-drivers/xf86-input-vmmouse and x11-drivers/xf86-video-vmware; When I now run 'X -configure' the X.org server Seg faults after loading the /usr/local/lib/xorg/modules/drivers/vmware_drv.so (a complete Xorg.0.log is attached) Any ideas or should I file a bug report? matthias -- Matthias Apitz t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 e - w http://www.unixarea.de/ --YiEDa0DAkWCtVeE4 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="Xorg.0.log" X.Org X Server 1.7.5 Release Date: 2010-02-16 X Protocol Version 11, Revision 0 Build Operating System: FreeBSD 9.0-CURRENT i386 Current Operating System: FreeBSD vm-9Current 9.0-CURRENT FreeBSD 9.0-CURRENT #1 r214444: Thu Oct 28 10:56:32 CEST 2010 guru@current.Sisis.de:/usr/home/guru/myThings/FreeBSD/9-CURRENT/obj/usr/home/guru/myThings/FreeBSD/9-CURRENT/src/sys/GENERIC i386 Build Date: 01 November 2010 11:23:53AM Current version of pixman: 0.16.6 Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: "/var/log/Xorg.0.log", Time: Mon Apr 11 07:10:53 2011 (II) Loader magic: 0x81def20 (II) Module ABI versions: X.Org ANSI C Emulation: 0.4 X.Org Video Driver: 6.0 X.Org XInput driver : 7.0 X.Org Server Extension : 2.0 (--) Using syscons driver with X support (version 2.0) (--) using VT number 9 (--) PCI:*(0:0:15:0) 15ad:0405:15ad:0405 VMware SVGA II Adapter rev 0, Mem @ 0xd0000000/134217728, 0xd8000000/8388608, I/O @ 0x000010d0/16, BIOS @ 0x????????/65536 List of video drivers: intel openchrome vmwlegacy radeonhd r128 nv mach64 ati radeon vmware vesa (II) LoadModule: "intel" (II) Loading /usr/local/lib/xorg/modules/drivers/intel_drv.so (II) Module intel: vendor="X.Org Foundation" compiled for 1.7.5, module version = 2.7.1 Module class: X.Org Video Driver ABI class: X.Org Video Driver, version 6.0 (II) LoadModule: "openchrome" (II) Loading /usr/local/lib/xorg/modules/drivers/openchrome_drv.so (II) Module openchrome: vendor="http://openchrome.org/" compiled for 1.7.5, module version = 0.2.904 Module class: X.Org Video Driver ABI class: X.Org Video Driver, version 6.0 (II) LoadModule: "vmwlegacy" (II) Loading /usr/local/lib/xorg/modules/drivers/vmwlegacy_drv.so (II) Module vmwlegacy: vendor="X.Org Foundation" compiled for 1.7.5, module version = 11.0.1 Module class: X.Org Video Driver ABI class: X.Org Video Driver, version 6.0 (II) LoadModule: "radeonhd" (II) Loading /usr/local/lib/xorg/modules/drivers/radeonhd_drv.so (II) Module radeonhd: vendor="AMD GPG" compiled for 1.7.5, module version = 1.3.0 Module class: X.Org Video Driver ABI class: X.Org Video Driver, version 6.0 (II) LoadModule: "r128" (II) Loading /usr/local/lib/xorg/modules/drivers/r128_drv.so (II) Module r128: vendor="X.Org Foundation" compiled for 1.7.5, module version = 6.8.1 Module class: X.Org Video Driver ABI class: X.Org Video Driver, version 6.0 (II) LoadModule: "nv" (II) Loading /usr/local/lib/xorg/modules/drivers/nv_drv.so (II) Module nv: vendor="X.Org Foundation" compiled for 1.7.5, module version = 2.1.17 Module class: X.Org Video Driver ABI class: X.Org Video Driver, version 6.0 (II) LoadModule: "mach64" (II) Loading /usr/local/lib/xorg/modules/drivers/mach64_drv.so (II) Module mach64: vendor="X.Org Foundation" compiled for 1.7.5, module version = 6.8.2 Module class: X.Org Video Driver ABI class: X.Org Video Driver, version 6.0 (II) LoadModule: "ati" (II) Loading /usr/local/lib/xorg/modules/drivers/ati_drv.so (II) Module ati: vendor="X.Org Foundation" compiled for 1.7.5, module version = 6.13.0 Module class: X.Org Video Driver ABI class: X.Org Video Driver, version 6.0 (II) LoadModule: "radeon" (II) Loading /usr/local/lib/xorg/modules/drivers/radeon_drv.so (II) Module radeon: vendor="X.Org Foundation" compiled for 1.7.5, module version = 6.13.0 Module class: X.Org Video Driver ABI class: X.Org Video Driver, version 6.0 (II) LoadModule: "vmware" (II) Loading /usr/local/lib/xorg/modules/drivers/vmware_drv.so (II) Module vmware: vendor="X.Org Foundation" compiled for 1.7.5, module version = 11.0.1 Module class: X.Org Video Driver ABI class: X.Org Video Driver, version 6.0 (--) vmware: X configured to use vmwgfx X driver assume who ever did that knows what they are doing (--) vmware: Please ignore above "[drm] failed to load kernel module "vmwgfx"" (II) vmware: Using vmwlegacy driver everything is fine. Segmentation fault: 11 at address 0x0 Fatal server error: Caught signal 11 (Segmentation fault: 11). Server aborting Please consult the The X.Org Foundation support at http://wiki.x.org for help. Please also check the log file at "/var/log/Xorg.0.log" for additional information. --YiEDa0DAkWCtVeE4-- From owner-freebsd-current@FreeBSD.ORG Mon Apr 11 08:38:22 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 03DD71065672; Mon, 11 Apr 2011 08:38:22 +0000 (UTC) Date: Mon, 11 Apr 2011 08:38:22 +0000 From: Alexander Best To: Alexander Motin Message-ID: <20110411083821.GA80320@freebsd.org> References: <20110331223339.GA13682@freebsd.org> <201104010843.47367.jhb@freebsd.org> <20110404204316.GA11367@freebsd.org> <4D9D9917.3030102@FreeBSD.org> <20110410115644.GA55815@freebsd.org> <4DA210D3.5090807@FreeBSD.org> <20110411025646.GA46088@freebsd.org> <4DA2A33B.8010807@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4DA2A33B.8010807@FreeBSD.org> Cc: freebsd-scsi@freebsd.org, freebsd-current@freebsd.org Subject: Re: multiple issues with devstat_*(9) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2011 08:38:22 -0000 On Mon Apr 11 11, Alexander Motin wrote: > Alexander Best wrote: > > On Sun Apr 10 11, Alexander Motin wrote: > >> Alexander Best wrote: > >>> On Thu Apr 7 11, Alexander Motin wrote: > >>>> Assuming that SCSI and IDE in -t option means transport type, and > >>>> assuming that we count everything except ATA and SATA as SCSI, I've made > >>>> following patch, that should fix issues from the CAM side: > >>>> http://people.freebsd.org/~mav/cam.devstat.patch > >>> with your patch i get the following output: > >>> > >>> otaku% iostat -t ide > >>> tty ada0 ada1 cpu > >>> tin tout KB/t tps MB/s KB/t tps MB/s us ni sy in id > >>> 6 144 14.21 6 0.09 20.46 40 0.81 2 0 3 0 95 > >>> otaku% iostat -t scsi > >>> tty cd0 cpu > >>> tin tout KB/t tps MB/s us ni sy in id > >>> 6 146 2.32 0 0.00 2 0 3 0 95 > >>> otaku% iostat -t pass > >>> tty pass0 pass1 pass2 cpu > >>> tin tout KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s us ni sy in id > >>> 6 147 0.36 0 0.00 0.36 0 0.00 0.00 0 0.00 2 0 3 0 95 > >>> otaku% iostat -t da > >>> tty ada0 ada1 cpu > >>> tin tout KB/t tps MB/s KB/t tps MB/s us ni sy in id > >>> 6 147 14.21 6 0.08 20.46 37 0.75 1 0 3 0 95 > >>> otaku% iostat -t cd > >>> tty cd0 cpu > >>> tin tout KB/t tps MB/s us ni sy in id > >>> 7 147 2.32 0 0.00 1 0 3 0 95 > >>> otaku% iostat -t other > >>> tty cpu > >>> tin tout us ni sy in id > >>> 7 149 1 0 3 0 95 > >>> otaku% iostat -n 100 > >>> tty ada0 ada1 cd0 pass0 pass1 pass2 cpu > >>> tin tout KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s us ni sy in id > >>> 6 135 14.21 5 0.07 20.44 32 0.64 2.32 0 0.00 0.36 0 0.00 0.36 0 0.00 0.00 0 0.00 1 0 3 0 96 > >>> > >>> the the remaining issues imho are: > >>> > >>> 1) ada* and cd* are SATA/ATA devices. so i think they should show up together > >>> either under ide *or* scsi. i don't have any *real* scsi devices. > >> I've just retested the patch and haven't reproduced your problem: > >> %iostat -d > >> da0 ada0 da1 cd0 > >> KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s > >> 0.01 0 0.00 3.27 1 0.00 2.65 1 0.00 0.00 0 0.00 > >> %iostat -d -t ide > >> da0 ada0 cd0 > >> KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s > >> 0.01 0 0.00 3.27 1 0.00 0.00 0 0.00 > >> %iostat -d -t scsi > >> da1 > >> KB/t tps MB/s > >> 2.65 1 0.00 > >> %iostat -d -t pass > >> pass0 pass1 pass2 pass3 > >> KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s > >> 0.00 0 0.00 0.00 0 0.00 0.00 0 0.00 0.00 0 0.00 > >> %iostat -d -t ide,pass > >> pass0 pass1 pass2 > >> KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s > >> 0.00 0 0.00 0.00 0 0.00 0.00 0 0.00 > >> %iostat -d -t scsi,pass > >> pass3 > >> KB/t tps MB/s > >> 0.00 0 0.00 > >> > >> da0 is an PATA ATAPI ZIP, da1 - USB floppy, ada0 - SATA HDD, cd0 - PATA > >> ATAPI CD-ROM. > >> > >> Just an idea, aren't you are using legacy ata(4) + atapicam for your > >> cd0? atapicam lies that it's buses are SPI (SCSI). > > > > my cd0 is a pata atapi dvdrom drive and i have the following in my kernel conf: > > > > device atacore > > device ahci > > device atajmicron > > device atapci > > #device atapicd > > device atapicam > > > > device umass > > device scbus > > device cd > > device pass > > device da > > device random > > device pty > > device md > > > > the dmesg entries for cd0 are: > > > > cam_periph_alloc: attempt to re-allocate valid device cd0 rejected > > cdasync: Unable to attach new device due to status 0x6 > > cd0 at ata2 bus 0 scbus8 target 0 lun 0 > > cd0: Removable CD-ROM SCSI-0 device > > cd0: 3.300MB/s transfers > > cd0: cd present [2149024 x 2048 byte records] > > Aha, that's it. It is atapicam's lie. atapicam is one of a things that > will go away during migration to CAM ATA. If you remove `device > atapicam`, but add `options ATA_CAM` instead, CAM will manage that bus > directly and report it as ATA. thanks for the hint. i also read the following in the ahci(4) man page: " Driver features include support for Serial ATA and ATAPI devices, ..." ...does that mean that my DVD drive can also attach to the ahci driver? cheers. alex > > -- > Alexander Motin -- a13x From owner-freebsd-current@FreeBSD.ORG Mon Apr 11 08:52:44 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8C7461065686; Mon, 11 Apr 2011 08:52:44 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 7C12F8FC23; Mon, 11 Apr 2011 08:52:43 +0000 (UTC) Received: by bwz12 with SMTP id 12so5576141bwz.13 for ; Mon, 11 Apr 2011 01:52:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=mpZfbr5qraS8QRXJ2YKqTToA9s82G1xieDYTXydojYk=; b=BQj3wrC/MKDZZ+nDHuLxnxLtv3WRF8kDDErSgqdrLIpt1WMhhocNTjpmF+1WccRO5N ijCjEM+cg6oVoBWSq7CTGRkRi22s4SzXz4cRXK3+ie5t174GKju76LI6MKkWPSPFGDqf f44eNtPrqBD00HmW/vXgOcPLIRz17nUthV7+0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=ELnncj49monS57z8VgJzQRZZNhjk3q4Qbj5WcvjZBroWnC5MIpO4xPN8YWjGNY6fBx pLgnndN6Rq95+IpRy1Nwx4JN4YHS9nGa5x5sW1UsBnsdRTlhicPpKJzFoa/1W9KRUi/f rdumQcblHfTWQx5yOUKK2yD2vL85nR/DZ1ozg= Received: by 10.204.16.72 with SMTP id n8mr784611bka.8.1302511962256; Mon, 11 Apr 2011 01:52:42 -0700 (PDT) Received: from mavbook2.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id q24sm3067627bks.21.2011.04.11.01.52.40 (version=SSLv3 cipher=OTHER); Mon, 11 Apr 2011 01:52:41 -0700 (PDT) Sender: Alexander Motin Message-ID: <4DA2C14F.60905@FreeBSD.org> Date: Mon, 11 Apr 2011 11:52:31 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: Alexander Best References: <20110331223339.GA13682@freebsd.org> <201104010843.47367.jhb@freebsd.org> <20110404204316.GA11367@freebsd.org> <4D9D9917.3030102@FreeBSD.org> <20110410115644.GA55815@freebsd.org> <4DA210D3.5090807@FreeBSD.org> <20110411025646.GA46088@freebsd.org> <4DA2A33B.8010807@FreeBSD.org> <20110411083821.GA80320@freebsd.org> In-Reply-To: <20110411083821.GA80320@freebsd.org> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-scsi@freebsd.org, freebsd-current@freebsd.org Subject: Re: multiple issues with devstat_*(9) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2011 08:52:44 -0000 Alexander Best wrote: > On Mon Apr 11 11, Alexander Motin wrote: >> Alexander Best wrote: >>> my cd0 is a pata atapi dvdrom drive and i have the following in my kernel conf: >>> >>> device atacore >>> device ahci >>> device atajmicron >>> device atapci >>> #device atapicd >>> device atapicam >>> >>> device umass >>> device scbus >>> device cd >>> device pass >>> device da >>> device random >>> device pty >>> device md >>> >>> the dmesg entries for cd0 are: >>> >>> cam_periph_alloc: attempt to re-allocate valid device cd0 rejected >>> cdasync: Unable to attach new device due to status 0x6 >>> cd0 at ata2 bus 0 scbus8 target 0 lun 0 >>> cd0: Removable CD-ROM SCSI-0 device >>> cd0: 3.300MB/s transfers >>> cd0: cd present [2149024 x 2048 byte records] >> Aha, that's it. It is atapicam's lie. atapicam is one of a things that >> will go away during migration to CAM ATA. If you remove `device >> atapicam`, but add `options ATA_CAM` instead, CAM will manage that bus >> directly and report it as ATA. > > thanks for the hint. i also read the following in the ahci(4) man page: > > " Driver features include support for Serial ATA and ATAPI devices, ..." > > ...does that mean that my DVD drive can also attach to the ahci driver? If it is SATA and you connect it to AHCI controller -- yes, it will work with ahci(4) controller driver. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Mon Apr 11 09:34:15 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id C93E31065670; Mon, 11 Apr 2011 09:34:15 +0000 (UTC) Date: Mon, 11 Apr 2011 09:34:15 +0000 From: Alexander Best To: Alexander Motin Message-ID: <20110411093415.GA87477@freebsd.org> References: <20110331223339.GA13682@freebsd.org> <201104010843.47367.jhb@freebsd.org> <20110404204316.GA11367@freebsd.org> <4D9D9917.3030102@FreeBSD.org> <20110410115644.GA55815@freebsd.org> <4DA210D3.5090807@FreeBSD.org> <20110411025646.GA46088@freebsd.org> <4DA2A33B.8010807@FreeBSD.org> <20110411083821.GA80320@freebsd.org> <4DA2C14F.60905@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4DA2C14F.60905@FreeBSD.org> Cc: freebsd-scsi@freebsd.org, freebsd-current@freebsd.org Subject: Re: multiple issues with devstat_*(9) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2011 09:34:15 -0000 On Mon Apr 11 11, Alexander Motin wrote: > Alexander Best wrote: > > On Mon Apr 11 11, Alexander Motin wrote: > >> Alexander Best wrote: > >>> my cd0 is a pata atapi dvdrom drive and i have the following in my kernel conf: > >>> > >>> device atacore > >>> device ahci > >>> device atajmicron > >>> device atapci > >>> #device atapicd > >>> device atapicam > >>> > >>> device umass > >>> device scbus > >>> device cd > >>> device pass > >>> device da > >>> device random > >>> device pty > >>> device md > >>> > >>> the dmesg entries for cd0 are: > >>> > >>> cam_periph_alloc: attempt to re-allocate valid device cd0 rejected > >>> cdasync: Unable to attach new device due to status 0x6 > >>> cd0 at ata2 bus 0 scbus8 target 0 lun 0 > >>> cd0: Removable CD-ROM SCSI-0 device > >>> cd0: 3.300MB/s transfers > >>> cd0: cd present [2149024 x 2048 byte records] > >> Aha, that's it. It is atapicam's lie. atapicam is one of a things that > >> will go away during migration to CAM ATA. If you remove `device > >> atapicam`, but add `options ATA_CAM` instead, CAM will manage that bus > >> directly and report it as ATA. > > > > thanks for the hint. i also read the following in the ahci(4) man page: > > > > " Driver features include support for Serial ATA and ATAPI devices, ..." > > > > ...does that mean that my DVD drive can also attach to the ahci driver? > > If it is SATA and you connect it to AHCI controller -- yes, it will work > with ahci(4) controller driver. no it's PATA. thanks for the help. i'll remove atapicam from my kernel conf and add ATA_CAM. maybe we could have a list of supported controllers in the ahci(4) man page. will the ataahci driver also dissapear soon? cheers. alex > > -- > Alexander Motin -- a13x From owner-freebsd-current@FreeBSD.ORG Mon Apr 11 11:45:37 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0A0F91065670; Mon, 11 Apr 2011 11:45:37 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 2E8768FC12; Mon, 11 Apr 2011 11:45:35 +0000 (UTC) Received: by bwz12 with SMTP id 12so5701341bwz.13 for ; Mon, 11 Apr 2011 04:45:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=G9BQ3zwgHBT7BdwUZNdsYv68G14r1GwnTtE2M1D3eVU=; b=VvVf2MGuC8i0q3NMg+UGmOt9xCJHuW5PPxylD/kTyXKlZNBH9hL62mj3YIS50B5xdv XErvPyaWyIOWuXMOFVj1PBX5NEQNQqVyCWBZXU5whLPXAW29dxxxqJnRzLuEMPL3OyTk 5mQpy4+43qSfVZzhsequIl5d1Od4EtwCS9lhg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=cXDU94NzZ8kc/HuPG9RvomWLzm41cIEnzRRr5IJnKzABrSafkh0aqnhcvkuh2QeYcW te8Bms1oJi35EYpEanUqIPLqvmTkE5g35xv5ac5d61/0j9aVABMtXx9kYzX/VTc4KIRM ZYinK189nI8EJkUnpRb4+SG4Yi7cAGE5p9Z8k= Received: by 10.204.19.70 with SMTP id z6mr2234940bka.204.1302522335053; Mon, 11 Apr 2011 04:45:35 -0700 (PDT) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id b6sm3161321bkb.22.2011.04.11.04.45.33 (version=SSLv3 cipher=OTHER); Mon, 11 Apr 2011 04:45:34 -0700 (PDT) Sender: Alexander Motin Message-ID: <4DA2E9DC.108@FreeBSD.org> Date: Mon, 11 Apr 2011 14:45:32 +0300 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.15) Gecko/20110310 Thunderbird/3.1.9 MIME-Version: 1.0 To: Alexander Best References: <20110331223339.GA13682@freebsd.org> <201104010843.47367.jhb@freebsd.org> <20110404204316.GA11367@freebsd.org> <4D9D9917.3030102@FreeBSD.org> <20110410115644.GA55815@freebsd.org> <4DA210D3.5090807@FreeBSD.org> <20110411025646.GA46088@freebsd.org> <4DA2A33B.8010807@FreeBSD.org> <20110411083821.GA80320@freebsd.org> <4DA2C14F.60905@FreeBSD.org> <20110411093415.GA87477@freebsd.org> In-Reply-To: <20110411093415.GA87477@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-scsi@freebsd.org, freebsd-current@freebsd.org Subject: Re: multiple issues with devstat_*(9) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2011 11:45:37 -0000 On 11.04.2011 12:34, Alexander Best wrote: > On Mon Apr 11 11, Alexander Motin wrote: >> Alexander Best wrote: >>> On Mon Apr 11 11, Alexander Motin wrote: >>>> Alexander Best wrote: >>>>> my cd0 is a pata atapi dvdrom drive and i have the following in my kernel conf: >>>>> >>>>> device atacore >>>>> device ahci >>>>> device atajmicron >>>>> device atapci >>>>> #device atapicd >>>>> device atapicam >>>>> >>>>> device umass >>>>> device scbus >>>>> device cd >>>>> device pass >>>>> device da >>>>> device random >>>>> device pty >>>>> device md >>>>> >>>>> the dmesg entries for cd0 are: >>>>> >>>>> cam_periph_alloc: attempt to re-allocate valid device cd0 rejected >>>>> cdasync: Unable to attach new device due to status 0x6 >>>>> cd0 at ata2 bus 0 scbus8 target 0 lun 0 >>>>> cd0: Removable CD-ROM SCSI-0 device >>>>> cd0: 3.300MB/s transfers >>>>> cd0: cd present [2149024 x 2048 byte records] >>>> Aha, that's it. It is atapicam's lie. atapicam is one of a things that >>>> will go away during migration to CAM ATA. If you remove `device >>>> atapicam`, but add `options ATA_CAM` instead, CAM will manage that bus >>>> directly and report it as ATA. >>> >>> thanks for the hint. i also read the following in the ahci(4) man page: >>> >>> " Driver features include support for Serial ATA and ATAPI devices, ..." >>> >>> ...does that mean that my DVD drive can also attach to the ahci driver? >> >> If it is SATA and you connect it to AHCI controller -- yes, it will work >> with ahci(4) controller driver. > > no it's PATA. thanks for the help. i'll remove atapicam from my kernel conf > and add ATA_CAM. > > maybe we could have a list of supported controllers in the ahci(4) man page. We could do it (you can find list of known inside ahci.c), but unlike others, AHCI is an open specification, so that list will never be complete. Also on some chipsets AHCI support also depends on BIOS, so specification of just a chipset revisions can be inaccurate. > will the ataahci driver also dissapear soon? Yes, at least disabled. Same as most part of the atasiliconimage and the atamarvell. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Mon Apr 11 12:27:28 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C936A106566B for ; Mon, 11 Apr 2011 12:27:28 +0000 (UTC) (envelope-from boogie@lazybytes.org) Received: from mail.lazybytes.org (mail.lazybytes.org [195.54.209.3]) by mx1.freebsd.org (Postfix) with ESMTP id 13A3B8FC0C for ; Mon, 11 Apr 2011 12:27:27 +0000 (UTC) Received: from [95.108.170.237] (dhcp170-237-red.yandex.net [95.108.170.237]) by mail.lazybytes.org (Postfix) with ESMTPSA id 28F4AC78 for ; Mon, 11 Apr 2011 16:10:48 +0400 (MSD) Message-ID: <4DA2EFEF.3010004@lazybytes.org> Date: Mon, 11 Apr 2011 16:11:27 +0400 From: Sergey Vinogradov User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.15) Gecko/20110307 Lanikai/3.1.9 MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: multipart/mixed; boundary="------------020809060003010109060206" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (mail.lazybytes.org); Mon, 11 Apr 2011 16:10:49 +0400 (MSD) Subject: [PATCH] ifconfig(8) flag to display IPv4 netmasks in dot-decimal format X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2011 12:27:28 -0000 This is a multi-part message in MIME format. --------------020809060003010109060206 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, I've written a tiny-tiny patch, which adds the '-t' flag to ifconfig(8). It modifies the output to display IPv4 netmasks in dotted decimal notation: % ifconfig msk0 msk0: flags=8843 metric 0 mtu 1500 options=c011a ether 00:16:e6:88:0f:89 inet 10.10.0.1 netmask 0xffffff00 broadcast 10.10.0.255 media: Ethernet autoselect (none) status: no carrier % ifconfig -t msk0 msk0: flags=8843 metric 0 mtu 1500 options=c011a ether 00:16:e6:88:0f:89 inet 10.10.0.1 netmask 255.255.255.0 broadcast 10.10.0.255 media: Ethernet autoselect (none) status: no carrier There was a discussion [1] in freebsd-hackers@ about adding such functionality to ifconfig(8), which urged me write this patch. The default behavior of ifconfig(8) is kept unmodified, so there shouldn't be any compatibility breakages. At least, it works fine for me :) [1] http://lists.freebsd.org/pipermail/freebsd-hackers/2011-April/034997.html -- wbr, Boo --------------020809060003010109060206 Content-Type: text/plain; name="ifconfig.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="ifconfig.patch" Index: sbin/ifconfig/af_inet.c =================================================================== RCS file: /home/ncvs/src/sbin/ifconfig/af_inet.c,v retrieving revision 1.5.2.2.2.1 diff -u -r1.5.2.2.2.1 af_inet.c --- sbin/ifconfig/af_inet.c 21 Dec 2010 17:09:25 -0000 1.5.2.2.2.1 +++ sbin/ifconfig/af_inet.c 11 Apr 2011 12:03:32 -0000 @@ -79,7 +79,10 @@ sin = (struct sockaddr_in *)ifa->ifa_netmask; if (sin == NULL) sin = &null_sin; - printf("netmask 0x%lx ", (unsigned long)ntohl(sin->sin_addr.s_addr)); + if (dotmask) + printf("netmask %s ", inet_ntoa(sin->sin_addr)); + else + printf("netmask 0x%lx ", (unsigned long)ntohl(sin->sin_addr.s_addr)); if (ifa->ifa_flags & IFF_BROADCAST) { sin = (struct sockaddr_in *)ifa->ifa_broadaddr; Index: sbin/ifconfig/ifconfig.8 =================================================================== RCS file: /home/ncvs/src/sbin/ifconfig/ifconfig.8,v retrieving revision 1.159.2.6.4.1 diff -u -r1.159.2.6.4.1 ifconfig.8 --- sbin/ifconfig/ifconfig.8 21 Dec 2010 17:09:25 -0000 1.159.2.6.4.1 +++ sbin/ifconfig/ifconfig.8 11 Apr 2011 12:03:32 -0000 @@ -40,6 +40,7 @@ .Op Fl k .Op Fl m .Op Fl n +.Op Fl t .Ar interface .Op Cm create .Op Ar address_family @@ -56,6 +57,7 @@ .Op Fl L .Op Fl d .Op Fl m +.Op Fl t .Op Fl u .Op Fl v .Op Ar address_family @@ -69,6 +71,7 @@ .Op Fl d .Op Fl k .Op Fl m +.Op Fl t .Op Fl u .Op Fl v .Op Fl C @@ -2400,6 +2403,9 @@ .Fl L flag is supplied, address lifetime is displayed for IPv6 addresses, as time offset string. +The +.Fl t +flag makes IPv4 netmasks being displayed in dotted decimal notation. .Pp Optionally, the .Fl a Index: sbin/ifconfig/ifconfig.c =================================================================== RCS file: /home/ncvs/src/sbin/ifconfig/ifconfig.c,v retrieving revision 1.146.2.5.4.1 diff -u -r1.146.2.5.4.1 ifconfig.c --- sbin/ifconfig/ifconfig.c 21 Dec 2010 17:09:25 -0000 1.146.2.5.4.1 +++ sbin/ifconfig/ifconfig.c 11 Apr 2011 12:03:32 -0000 @@ -90,6 +90,7 @@ int clearaddr; int newaddr = 1; int verbose; +int dotmask; int noload; int supmedia = 0; @@ -132,9 +133,9 @@ "usage: ifconfig %sinterface address_family [address [dest_address]]\n" " [parameters]\n" " ifconfig interface create\n" - " ifconfig -a %s[-d] [-m] [-u] [-v] [address_family]\n" + " ifconfig -a %s[-d] [-m] [-t] [-u] [-v] [address_family]\n" " ifconfig -l [-d] [-u] [address_family]\n" - " ifconfig %s[-d] [-m] [-u] [-v]\n", + " ifconfig %s[-d] [-m] [-t] [-u] [-v]\n", options, options, options); exit(1); } @@ -156,7 +157,7 @@ all = downonly = uponly = namesonly = noload = verbose = 0; /* Parse leading line options */ - strlcpy(options, "adklmnuv", sizeof(options)); + strlcpy(options, "adklmntuv", sizeof(options)); for (p = opts; p != NULL; p = p->next) strlcat(options, p->opt, sizeof(options)); while ((c = getopt(argc, argv, options)) != -1) { @@ -179,6 +180,9 @@ case 'n': /* suppress module loading */ noload++; break; + case 't': /* show IPv4 netmask in dotted decimal notation */ + dotmask++; + break; case 'u': /* restrict scan to "up" interfaces */ uponly++; break; @@ -199,8 +203,8 @@ argc -= optind; argv += optind; - /* -l cannot be used with -a or -m */ - if (namesonly && (all || supmedia)) + /* -l cannot be used with -a, -m or -t */ + if (namesonly && (all || supmedia || dotmask)) usage(); /* nonsense.. */ Index: sbin/ifconfig/ifconfig.h =================================================================== RCS file: /home/ncvs/src/sbin/ifconfig/ifconfig.h,v retrieving revision 1.24.2.1.6.1 diff -u -r1.24.2.1.6.1 ifconfig.h --- sbin/ifconfig/ifconfig.h 21 Dec 2010 17:09:25 -0000 1.24.2.1.6.1 +++ sbin/ifconfig/ifconfig.h 11 Apr 2011 12:03:33 -0000 @@ -132,6 +132,7 @@ extern int printkeys; extern int newaddr; extern int verbose; +extern int dotmask; void setifcap(const char *, int value, int s, const struct afswtch *); --------------020809060003010109060206-- From owner-freebsd-current@FreeBSD.ORG Mon Apr 11 15:17:20 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 21E9C1065672 for ; Mon, 11 Apr 2011 15:17:20 +0000 (UTC) (envelope-from gljennjohn@googlemail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 9A8A18FC1C for ; Mon, 11 Apr 2011 15:17:19 +0000 (UTC) Received: by bwz12 with SMTP id 12so5920922bwz.13 for ; Mon, 11 Apr 2011 08:17:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:date:from:to:cc:subject:message-id:in-reply-to :references:reply-to:x-mailer:mime-version:content-type :content-transfer-encoding; bh=vVHAfFdtM3ay/rqqinwZG8t2SzUL2Qnj1q3bP1A9Vdc=; b=m8h9cFymVghEAezoaIpE602/cRTW9zQiKb79HMO9yBjrTSQ+hqOAdTF3dI6fy9UuQQ 5dLdRcdAqiZazihGXPJ6zGBW6FHijr12wvr7ZdBTByRAJo0tpobF2BqJsakG/z81QK5Q aFrVcQubW+k7uMSFoDoJs5JuK+iC7P8jWLoMk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=date:from:to:cc:subject:message-id:in-reply-to:references:reply-to :x-mailer:mime-version:content-type:content-transfer-encoding; b=dWKLhaIN2DOrdHFzQ0y6colWMB4QobItnVBQzWdozCtBClHyQcuKXCyV2FoUfDzThx jPwVcPY1Y8TiikADsCFQ18XbqtbHKBFI15NUh1T/KIXvNwrP2gQ2mBO8M9vsoRCGrZGF yOt6O2iztrtVSnXTnjKEnM1ETLEWJg7rD6hJw= Received: by 10.204.128.219 with SMTP id l27mr1121373bks.99.1302535038221; Mon, 11 Apr 2011 08:17:18 -0700 (PDT) Received: from ernst.jennejohn.org (p578E309E.dip.t-dialin.net [87.142.48.158]) by mx.google.com with ESMTPS id b6sm3277581bkb.22.2011.04.11.08.17.15 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 11 Apr 2011 08:17:16 -0700 (PDT) Date: Mon, 11 Apr 2011 17:17:13 +0200 From: Gary Jennejohn To: Sergey Vinogradov Message-ID: <20110411171713.144d9a72@ernst.jennejohn.org> In-Reply-To: <4DA2EFEF.3010004@lazybytes.org> References: <4DA2EFEF.3010004@lazybytes.org> X-Mailer: Claws Mail 3.7.8 (GTK+ 2.18.7; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: [PATCH] ifconfig(8) flag to display IPv4 netmasks in dot-decimal format X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gljennjohn@googlemail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2011 15:17:20 -0000 On Mon, 11 Apr 2011 16:11:27 +0400 Sergey Vinogradov wrote: > I've written a tiny-tiny patch, which adds the '-t' flag to ifconfig(8). > It modifies the output to display IPv4 netmasks in dotted decimal notation: > > % ifconfig msk0 > msk0: flags=8843 metric 0 mtu 1500 > > options=c011a > ether 00:16:e6:88:0f:89 > inet 10.10.0.1 netmask 0xffffff00 broadcast 10.10.0.255 > media: Ethernet autoselect (none) > status: no carrier > > % ifconfig -t msk0 > msk0: flags=8843 metric 0 mtu 1500 > > options=c011a > ether 00:16:e6:88:0f:89 > inet 10.10.0.1 netmask 255.255.255.0 broadcast 10.10.0.255 > media: Ethernet autoselect (none) > status: no carrier > > There was a discussion [1] in freebsd-hackers@ about adding such > functionality to ifconfig(8), which urged me write this patch. The > default behavior of ifconfig(8) is kept unmodified, so there shouldn't > be any compatibility breakages. At least, it works fine for me :) > > [1] > http://lists.freebsd.org/pipermail/freebsd-hackers/2011-April/034997.html > Looks good, except I'd change this line to read like this: +The +.Fl t +flag makes IPv4 netmasks being displayed in dotted decimal notation. ^^^^^ results in -- Gary Jennejohn From owner-freebsd-current@FreeBSD.ORG Mon Apr 11 16:07:41 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 397FF106564A; Mon, 11 Apr 2011 16:07:41 +0000 (UTC) (envelope-from ken@kdm.org) Received: from nargothrond.kdm.org (nargothrond.kdm.org [70.56.43.81]) by mx1.freebsd.org (Postfix) with ESMTP id D9EA38FC19; Mon, 11 Apr 2011 16:07:40 +0000 (UTC) Received: from nargothrond.kdm.org (localhost [127.0.0.1]) by nargothrond.kdm.org (8.14.2/8.14.2) with ESMTP id p3BFcvNY063281; Mon, 11 Apr 2011 09:38:57 -0600 (MDT) (envelope-from ken@nargothrond.kdm.org) Received: (from ken@localhost) by nargothrond.kdm.org (8.14.2/8.14.2/Submit) id p3BFcvfT063280; Mon, 11 Apr 2011 09:38:57 -0600 (MDT) (envelope-from ken) Date: Mon, 11 Apr 2011 09:38:57 -0600 From: "Kenneth D. Merry" To: Alexander Motin Message-ID: <20110411153857.GA63246@nargothrond.kdm.org> References: <20110331223339.GA13682@freebsd.org> <201104010843.47367.jhb@freebsd.org> <20110404204316.GA11367@freebsd.org> <4D9D9917.3030102@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4D9D9917.3030102@FreeBSD.org> User-Agent: Mutt/1.4.2i Cc: Alexander Best , freebsd-current@freebsd.org, freebsd-scsi@freebsd.org Subject: Re: multiple issues with devstat_*(9) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2011 16:07:41 -0000 On Thu, Apr 07, 2011 at 13:59:35 +0300, Alexander Motin wrote: > Alexander Best wrote: > > On Fri Apr 1 11, John Baldwin wrote: > >> On Thursday, March 31, 2011 6:33:39 pm Alexander Best wrote: > >>> i think there are multiple issues with devstat. i found the following in > >>> devicestat.h: > > ... > > >>> funny thing is i found the following in scsi_pass.c: > >>> > >>> softc->device_stats = devstat_new_entry("pass", > >>> periph->unit_number, 0, > >>> DEVSTAT_NO_BLOCKSIZE > >>> | (no_tags ? DEVSTAT_NO_ORDERED_TAGS : 0), > >>> softc->pd_type | > >>> DEVSTAT_TYPE_IF_SCSI | > >>> DEVSTAT_TYPE_PASS, > >>> DEVSTAT_PRIORITY_PASS); > >>> > >>> ...so pass* *should* show up under iostat -t scsi. > > As I can see, this is a bug (or feature) of the libdevstat / > devstat_selectdevs(). If you specify any -t, then pass devices will be > reported only if you request "pass" specifically. > > >> Hmm, pass devices for adaX should not be SCSI though, they should be ide I > >> think. > > > > i think the situation with ATA_CAM should be discussed further. still besides > > this issue there are many more with devstat(3). > > > > i'll try to track all the "devstat_new_entry()" occurrences and see if some > > issues can be fixed. maybe only the proper DEVSTAT_* args were forgotten. > > Assuming that SCSI and IDE in -t option means transport type, and > assuming that we count everything except ATA and SATA as SCSI, I've made > following patch, that should fix issues from the CAM side: > http://people.freebsd.org/~mav/cam.devstat.patch > > Any objections? Or SCSI/IDE there expected to mean command set? For what it's worth, I think the above patch is the right approach. The device type stuff in devstat has been broken since GEOM went in, so I'm glad to see you step up to fix it! Ken -- Kenneth Merry ken@FreeBSD.ORG From owner-freebsd-current@FreeBSD.ORG Mon Apr 11 16:07:41 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9585B106566C; Mon, 11 Apr 2011 16:07:41 +0000 (UTC) (envelope-from ken@kdm.org) Received: from nargothrond.kdm.org (nargothrond.kdm.org [70.56.43.81]) by mx1.freebsd.org (Postfix) with ESMTP id 5FAA68FC1A; Mon, 11 Apr 2011 16:07:41 +0000 (UTC) Received: from nargothrond.kdm.org (localhost [127.0.0.1]) by nargothrond.kdm.org (8.14.2/8.14.2) with ESMTP id p3BFhdOJ063502; Mon, 11 Apr 2011 09:43:39 -0600 (MDT) (envelope-from ken@nargothrond.kdm.org) Received: (from ken@localhost) by nargothrond.kdm.org (8.14.2/8.14.2/Submit) id p3BFhdDR063501; Mon, 11 Apr 2011 09:43:39 -0600 (MDT) (envelope-from ken) Date: Mon, 11 Apr 2011 09:43:39 -0600 From: "Kenneth D. Merry" To: Alexander Motin Message-ID: <20110411154339.GB63246@nargothrond.kdm.org> References: <20110331223339.GA13682@freebsd.org> <201104010843.47367.jhb@freebsd.org> <20110404204316.GA11367@freebsd.org> <4D9D9917.3030102@FreeBSD.org> <20110410115644.GA55815@freebsd.org> <4DA210D3.5090807@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4DA210D3.5090807@FreeBSD.org> User-Agent: Mutt/1.4.2i Cc: Alexander Best , freebsd-current@freebsd.org, freebsd-scsi@freebsd.org Subject: Re: multiple issues with devstat_*(9) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2011 16:07:41 -0000 On Sun, Apr 10, 2011 at 23:19:31 +0300, Alexander Motin wrote: > Alexander Best wrote: > > On Thu Apr 7 11, Alexander Motin wrote: > >> Alexander Best wrote: > >>> On Fri Apr 1 11, John Baldwin wrote: > >>>> On Thursday, March 31, 2011 6:33:39 pm Alexander Best wrote: > >>>>> i think there are multiple issues with devstat. i found the following in > >>>>> devicestat.h: > >> ... > >> > >>>>> funny thing is i found the following in scsi_pass.c: > >>>>> > >>>>> softc->device_stats = devstat_new_entry("pass", > >>>>> periph->unit_number, 0, > >>>>> DEVSTAT_NO_BLOCKSIZE > >>>>> | (no_tags ? DEVSTAT_NO_ORDERED_TAGS : 0), > >>>>> softc->pd_type | > >>>>> DEVSTAT_TYPE_IF_SCSI | > >>>>> DEVSTAT_TYPE_PASS, > >>>>> DEVSTAT_PRIORITY_PASS); > >>>>> > >>>>> ...so pass* *should* show up under iostat -t scsi. > >> As I can see, this is a bug (or feature) of the libdevstat / > >> devstat_selectdevs(). If you specify any -t, then pass devices will be > >> reported only if you request "pass" specifically. > >> > >>>> Hmm, pass devices for adaX should not be SCSI though, they should be ide I > >>>> think. > >>> i think the situation with ATA_CAM should be discussed further. still besides > >>> this issue there are many more with devstat(3). > >>> > >>> i'll try to track all the "devstat_new_entry()" occurrences and see if some > >>> issues can be fixed. maybe only the proper DEVSTAT_* args were forgotten. > >> Assuming that SCSI and IDE in -t option means transport type, and > >> assuming that we count everything except ATA and SATA as SCSI, I've made > >> following patch, that should fix issues from the CAM side: > >> http://people.freebsd.org/~mav/cam.devstat.patch > > > > with your patch i get the following output: > > > > otaku% iostat -t ide > > tty ada0 ada1 cpu > > tin tout KB/t tps MB/s KB/t tps MB/s us ni sy in id > > 6 144 14.21 6 0.09 20.46 40 0.81 2 0 3 0 95 > > otaku% iostat -t scsi > > tty cd0 cpu > > tin tout KB/t tps MB/s us ni sy in id > > 6 146 2.32 0 0.00 2 0 3 0 95 > > otaku% iostat -t pass > > tty pass0 pass1 pass2 cpu > > tin tout KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s us ni sy in id > > 6 147 0.36 0 0.00 0.36 0 0.00 0.00 0 0.00 2 0 3 0 95 > > otaku% iostat -t da > > tty ada0 ada1 cpu > > tin tout KB/t tps MB/s KB/t tps MB/s us ni sy in id > > 6 147 14.21 6 0.08 20.46 37 0.75 1 0 3 0 95 > > otaku% iostat -t cd > > tty cd0 cpu > > tin tout KB/t tps MB/s us ni sy in id > > 7 147 2.32 0 0.00 1 0 3 0 95 > > otaku% iostat -t other > > tty cpu > > tin tout us ni sy in id > > 7 149 1 0 3 0 95 > > otaku% iostat -n 100 > > tty ada0 ada1 cd0 pass0 pass1 pass2 cpu > > tin tout KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s us ni sy in id > > 6 135 14.21 5 0.07 20.44 32 0.64 2.32 0 0.00 0.36 0 0.00 0.36 0 0.00 0.00 0 0.00 1 0 3 0 96 > > > > the the remaining issues imho are: > > > > 1) ada* and cd* are SATA/ATA devices. so i think they should show up together > > either under ide *or* scsi. i don't have any *real* scsi devices. > > I've just retested the patch and haven't reproduced your problem: > %iostat -d > da0 ada0 da1 cd0 > KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s > 0.01 0 0.00 3.27 1 0.00 2.65 1 0.00 0.00 0 0.00 > %iostat -d -t ide > da0 ada0 cd0 > KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s > 0.01 0 0.00 3.27 1 0.00 0.00 0 0.00 > %iostat -d -t scsi > da1 > KB/t tps MB/s > 2.65 1 0.00 > %iostat -d -t pass > pass0 pass1 pass2 pass3 > KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s > 0.00 0 0.00 0.00 0 0.00 0.00 0 0.00 0.00 0 0.00 > %iostat -d -t ide,pass > pass0 pass1 pass2 > KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s > 0.00 0 0.00 0.00 0 0.00 0.00 0 0.00 > %iostat -d -t scsi,pass > pass3 > KB/t tps MB/s > 0.00 0 0.00 > > da0 is an PATA ATAPI ZIP, da1 - USB floppy, ada0 - SATA HDD, cd0 - PATA > ATAPI CD-ROM. > > Just an idea, aren't you are using legacy ata(4) + atapicam for your > cd0? atapicam lies that it's buses are SPI (SCSI). > > > 2) the pass* devices still don't show up under ide/scsi/other. that's ok, but > > then the src comments and manual pages need to be changed accordingly. > > As I have told - it is a bug/feature of libdevstat. It should not be > difficult to fix, if it is really a bug. That was intentional, if I can remember what I intended in 1997/1998. The reason was that since there is one passthrough device created for every device that CAM manages, you don't want to show pass(4) devices when the user says 'iostat -t scsi'. Otherwise he might get all pass(4) devices, depending on the order of devices in the system. But, if it's pass(4) devices you want, you can ask for them specifically, or for all SCSI/IDE pass(4) devices, as mav did above. Ken -- Kenneth Merry ken@FreeBSD.ORG From owner-freebsd-current@FreeBSD.ORG Mon Apr 11 16:09:05 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6EC6A106567E; Mon, 11 Apr 2011 16:09:05 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id BD3508FC1F; Mon, 11 Apr 2011 16:09:04 +0000 (UTC) Received: by bwz12 with SMTP id 12so5977002bwz.13 for ; Mon, 11 Apr 2011 09:09:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=LZs8j6Pi47+4b5ubVwMj/g+yzvXfzo0BHGm8d6XWf6k=; b=AvP+15Pl3Ua0bZJe8D+t78AwuD9eLOexM9qM7L52d+lsjLvbMVvJKAJaQT0CPA8d8W aXEXLyVFwRhr2+PH72MeMN8tSnn9zG3APvJ9GlslRpRmE4kLqIixNN/lECWcpp/ooPPi oc8kjQ6XBQTxvCxGMrhGrSetRPWqQTMj9Nu1M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=P/HBh7AFT44seTq+jYYUBsNZTML3cglLchtALgQUEbM73Cw3zET/SCSc7cfM6JYsqL CzWn//roBn2LDyNN1LsvNsDXTygX6H52+Et0R3oxk9BB0xnXvHGLoV3zhcWwIwT3oHef 9DtTKBLMg0XLevCmmu2pdjl5kQaAHn6oakL7g= Received: by 10.204.20.147 with SMTP id f19mr89029bkb.163.1302538143238; Mon, 11 Apr 2011 09:09:03 -0700 (PDT) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id j13sm736693faa.3.2011.04.11.09.09.01 (version=SSLv3 cipher=OTHER); Mon, 11 Apr 2011 09:09:02 -0700 (PDT) Sender: Alexander Motin Message-ID: <4DA3279C.5090409@FreeBSD.org> Date: Mon, 11 Apr 2011 19:09:00 +0300 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.15) Gecko/20110310 Thunderbird/3.1.9 MIME-Version: 1.0 To: "Kenneth D. Merry" References: <20110331223339.GA13682@freebsd.org> <201104010843.47367.jhb@freebsd.org> <20110404204316.GA11367@freebsd.org> <4D9D9917.3030102@FreeBSD.org> <20110410115644.GA55815@freebsd.org> <4DA210D3.5090807@FreeBSD.org> <20110411154339.GB63246@nargothrond.kdm.org> In-Reply-To: <20110411154339.GB63246@nargothrond.kdm.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-scsi@freebsd.org, freebsd-current@freebsd.org Subject: Re: multiple issues with devstat_*(9) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2011 16:09:05 -0000 On 11.04.2011 18:43, Kenneth D. Merry wrote: > On Sun, Apr 10, 2011 at 23:19:31 +0300, Alexander Motin wrote: >> Alexander Best wrote: >>> 2) the pass* devices still don't show up under ide/scsi/other. that's ok, but >>> then the src comments and manual pages need to be changed accordingly. >> >> As I have told - it is a bug/feature of libdevstat. It should not be >> difficult to fix, if it is really a bug. > > That was intentional, if I can remember what I intended in 1997/1998. > > The reason was that since there is one passthrough device created for every > device that CAM manages, you don't want to show pass(4) devices when the > user says 'iostat -t scsi'. Otherwise he might get all pass(4) devices, > depending on the order of devices in the system. > > But, if it's pass(4) devices you want, you can ask for them specifically, > or for all SCSI/IDE pass(4) devices, as mav did above. But it is impossible to get, for example, all SCSI devices including pass. Either only non-pass, or pass only. It is strange that if I won't specify "-t" (most probable for inexperienced users), I'll gel all devices including pass, but if specify "-t scsi" (as more advanced user who knows what to ask), I'll get only non-pass. It is at least inconsistent. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Mon Apr 11 16:50:02 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 38A131065679; Mon, 11 Apr 2011 16:50:02 +0000 (UTC) (envelope-from ken@kdm.org) Received: from nargothrond.kdm.org (nargothrond.kdm.org [70.56.43.81]) by mx1.freebsd.org (Postfix) with ESMTP id 9C5558FC15; Mon, 11 Apr 2011 16:50:01 +0000 (UTC) Received: from nargothrond.kdm.org (localhost [127.0.0.1]) by nargothrond.kdm.org (8.14.2/8.14.2) with ESMTP id p3BGo1JC065258; Mon, 11 Apr 2011 10:50:01 -0600 (MDT) (envelope-from ken@nargothrond.kdm.org) Received: (from ken@localhost) by nargothrond.kdm.org (8.14.2/8.14.2/Submit) id p3BGo1Qq065251; Mon, 11 Apr 2011 10:50:01 -0600 (MDT) (envelope-from ken) Date: Mon, 11 Apr 2011 10:50:01 -0600 From: "Kenneth D. Merry" To: Alexander Motin Message-ID: <20110411165001.GA65146@nargothrond.kdm.org> References: <20110331223339.GA13682@freebsd.org> <201104010843.47367.jhb@freebsd.org> <20110404204316.GA11367@freebsd.org> <4D9D9917.3030102@FreeBSD.org> <20110410115644.GA55815@freebsd.org> <4DA210D3.5090807@FreeBSD.org> <20110411154339.GB63246@nargothrond.kdm.org> <4DA3279C.5090409@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4DA3279C.5090409@FreeBSD.org> User-Agent: Mutt/1.4.2i Cc: freebsd-scsi@FreeBSD.org, freebsd-current@FreeBSD.org Subject: Re: multiple issues with devstat_*(9) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2011 16:50:02 -0000 On Mon, Apr 11, 2011 at 19:09:00 +0300, Alexander Motin wrote: > On 11.04.2011 18:43, Kenneth D. Merry wrote: > >On Sun, Apr 10, 2011 at 23:19:31 +0300, Alexander Motin wrote: > >>Alexander Best wrote: > >>>2) the pass* devices still don't show up under ide/scsi/other. that's > >>>ok, but > >>> then the src comments and manual pages need to be changed > >>> accordingly. > >> > >>As I have told - it is a bug/feature of libdevstat. It should not be > >>difficult to fix, if it is really a bug. > > > >That was intentional, if I can remember what I intended in 1997/1998. > > > >The reason was that since there is one passthrough device created for every > >device that CAM manages, you don't want to show pass(4) devices when the > >user says 'iostat -t scsi'. Otherwise he might get all pass(4) devices, > >depending on the order of devices in the system. > > > >But, if it's pass(4) devices you want, you can ask for them specifically, > >or for all SCSI/IDE pass(4) devices, as mav did above. > > But it is impossible to get, for example, all SCSI devices including > pass. Either only non-pass, or pass only. > > It is strange that if I won't specify "-t" (most probable for > inexperienced users), I'll gel all devices including pass, but if > specify "-t scsi" (as more advanced user who knows what to ask), I'll > get only non-pass. It is at least inconsistent. Perhaps it is somewhat inconsistent, and we should do some filtering by default to not show pass(4) devices. The idea was that in most cases, people will not want to see the pass(4) devices. That is not where most of the I/O typically happens. If they want to see the pass(4) devices, they can ask for them specifically by type or by name. When I have a system full of drives and I want to look at one particular pass(4) device, I always specify it manually, e.g.: 'iostat -d pass4 1' Ken -- Kenneth Merry ken@FreeBSD.ORG From owner-freebsd-current@FreeBSD.ORG Mon Apr 11 16:51:34 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 820DC106567C; Mon, 11 Apr 2011 16:51:34 +0000 (UTC) Date: Mon, 11 Apr 2011 16:51:34 +0000 From: Alexander Best To: "Kenneth D. Merry" Message-ID: <20110411165134.GA46762@freebsd.org> References: <20110331223339.GA13682@freebsd.org> <201104010843.47367.jhb@freebsd.org> <20110404204316.GA11367@freebsd.org> <4D9D9917.3030102@FreeBSD.org> <20110410115644.GA55815@freebsd.org> <4DA210D3.5090807@FreeBSD.org> <20110411154339.GB63246@nargothrond.kdm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110411154339.GB63246@nargothrond.kdm.org> Cc: freebsd-scsi@freebsd.org, Alexander Motin , freebsd-current@freebsd.org Subject: Re: multiple issues with devstat_*(9) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2011 16:51:34 -0000 On Mon Apr 11 11, Kenneth D. Merry wrote: > On Sun, Apr 10, 2011 at 23:19:31 +0300, Alexander Motin wrote: > > Alexander Best wrote: > > > On Thu Apr 7 11, Alexander Motin wrote: > > >> Alexander Best wrote: > > >>> On Fri Apr 1 11, John Baldwin wrote: > > >>>> On Thursday, March 31, 2011 6:33:39 pm Alexander Best wrote: > > >>>>> i think there are multiple issues with devstat. i found the following in > > >>>>> devicestat.h: > > >> ... > > >> > > >>>>> funny thing is i found the following in scsi_pass.c: > > >>>>> > > >>>>> softc->device_stats = devstat_new_entry("pass", > > >>>>> periph->unit_number, 0, > > >>>>> DEVSTAT_NO_BLOCKSIZE > > >>>>> | (no_tags ? DEVSTAT_NO_ORDERED_TAGS : 0), > > >>>>> softc->pd_type | > > >>>>> DEVSTAT_TYPE_IF_SCSI | > > >>>>> DEVSTAT_TYPE_PASS, > > >>>>> DEVSTAT_PRIORITY_PASS); > > >>>>> > > >>>>> ...so pass* *should* show up under iostat -t scsi. > > >> As I can see, this is a bug (or feature) of the libdevstat / > > >> devstat_selectdevs(). If you specify any -t, then pass devices will be > > >> reported only if you request "pass" specifically. > > >> > > >>>> Hmm, pass devices for adaX should not be SCSI though, they should be ide I > > >>>> think. > > >>> i think the situation with ATA_CAM should be discussed further. still besides > > >>> this issue there are many more with devstat(3). > > >>> > > >>> i'll try to track all the "devstat_new_entry()" occurrences and see if some > > >>> issues can be fixed. maybe only the proper DEVSTAT_* args were forgotten. > > >> Assuming that SCSI and IDE in -t option means transport type, and > > >> assuming that we count everything except ATA and SATA as SCSI, I've made > > >> following patch, that should fix issues from the CAM side: > > >> http://people.freebsd.org/~mav/cam.devstat.patch > > > > > > with your patch i get the following output: > > > > > > otaku% iostat -t ide > > > tty ada0 ada1 cpu > > > tin tout KB/t tps MB/s KB/t tps MB/s us ni sy in id > > > 6 144 14.21 6 0.09 20.46 40 0.81 2 0 3 0 95 > > > otaku% iostat -t scsi > > > tty cd0 cpu > > > tin tout KB/t tps MB/s us ni sy in id > > > 6 146 2.32 0 0.00 2 0 3 0 95 > > > otaku% iostat -t pass > > > tty pass0 pass1 pass2 cpu > > > tin tout KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s us ni sy in id > > > 6 147 0.36 0 0.00 0.36 0 0.00 0.00 0 0.00 2 0 3 0 95 > > > otaku% iostat -t da > > > tty ada0 ada1 cpu > > > tin tout KB/t tps MB/s KB/t tps MB/s us ni sy in id > > > 6 147 14.21 6 0.08 20.46 37 0.75 1 0 3 0 95 > > > otaku% iostat -t cd > > > tty cd0 cpu > > > tin tout KB/t tps MB/s us ni sy in id > > > 7 147 2.32 0 0.00 1 0 3 0 95 > > > otaku% iostat -t other > > > tty cpu > > > tin tout us ni sy in id > > > 7 149 1 0 3 0 95 > > > otaku% iostat -n 100 > > > tty ada0 ada1 cd0 pass0 pass1 pass2 cpu > > > tin tout KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s us ni sy in id > > > 6 135 14.21 5 0.07 20.44 32 0.64 2.32 0 0.00 0.36 0 0.00 0.36 0 0.00 0.00 0 0.00 1 0 3 0 96 > > > > > > the the remaining issues imho are: > > > > > > 1) ada* and cd* are SATA/ATA devices. so i think they should show up together > > > either under ide *or* scsi. i don't have any *real* scsi devices. > > > > I've just retested the patch and haven't reproduced your problem: > > %iostat -d > > da0 ada0 da1 cd0 > > KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s > > 0.01 0 0.00 3.27 1 0.00 2.65 1 0.00 0.00 0 0.00 > > %iostat -d -t ide > > da0 ada0 cd0 > > KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s > > 0.01 0 0.00 3.27 1 0.00 0.00 0 0.00 > > %iostat -d -t scsi > > da1 > > KB/t tps MB/s > > 2.65 1 0.00 > > %iostat -d -t pass > > pass0 pass1 pass2 pass3 > > KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s > > 0.00 0 0.00 0.00 0 0.00 0.00 0 0.00 0.00 0 0.00 > > %iostat -d -t ide,pass > > pass0 pass1 pass2 > > KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s > > 0.00 0 0.00 0.00 0 0.00 0.00 0 0.00 > > %iostat -d -t scsi,pass > > pass3 > > KB/t tps MB/s > > 0.00 0 0.00 > > > > da0 is an PATA ATAPI ZIP, da1 - USB floppy, ada0 - SATA HDD, cd0 - PATA > > ATAPI CD-ROM. > > > > Just an idea, aren't you are using legacy ata(4) + atapicam for your > > cd0? atapicam lies that it's buses are SPI (SCSI). > > > > > 2) the pass* devices still don't show up under ide/scsi/other. that's ok, but > > > then the src comments and manual pages need to be changed accordingly. > > > > As I have told - it is a bug/feature of libdevstat. It should not be > > difficult to fix, if it is really a bug. > > That was intentional, if I can remember what I intended in 1997/1998. > > The reason was that since there is one passthrough device created for every > device that CAM manages, you don't want to show pass(4) devices when the > user says 'iostat -t scsi'. Otherwise he might get all pass(4) devices, > depending on the order of devices in the system. i understand. however i think then we are being faced with a few doc bugs. have a look at this passage from devstat(9) e.g.: " Each device is given a device type. Pass-through devices have the same underlying device type and interface as the device they provide an inter- face for, but they also have the pass-through flag set. The base device types are identical to the SCSI device type numbers, so with SCSI periph- erals, the device type returned from an inquiry is usually ORed with the SCSI interface type and the pass-through flag if appropriate. The device type flags are as follows:" ...i also found some comments in the source mentioning the above behavior. cheers. alex > > But, if it's pass(4) devices you want, you can ask for them specifically, > or for all SCSI/IDE pass(4) devices, as mav did above. > > Ken > -- > Kenneth Merry > ken@FreeBSD.ORG -- a13x From owner-freebsd-current@FreeBSD.ORG Mon Apr 11 18:08:21 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5934B106566C for ; Mon, 11 Apr 2011 18:08:21 +0000 (UTC) (envelope-from eng.mufic@gmail.com) Received: from mail-pv0-f182.google.com (mail-pv0-f182.google.com [74.125.83.182]) by mx1.freebsd.org (Postfix) with ESMTP id 0FA3E8FC18 for ; Mon, 11 Apr 2011 18:08:20 +0000 (UTC) Received: by pvg11 with SMTP id 11so2788554pvg.13 for ; Mon, 11 Apr 2011 11:08:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=yj7OxTifM7Iso8t5iG69RTFyZz/hxRn/cFpLKqfGW4Y=; b=rxdosvUbXB1mt1trWP/ct/BEzvsXhWgsLNpBrsv/4myHxHxMWkWiOImot0F7MOIau7 vmqGUL9vpabGQ0np7zoupSIPA72JX3OAuXHZEUwnGp9zJpoWL3XgJum4tT6UHkUe0XuS 5nYAXeEQfdluGYtwgZDfT9E/PcFSJhIx1xKTo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=pYCVzm67ZKN10/4qjO8FqezmHQiiIZyPYh1WvJ7NHBeJND3mZ9RXSm0kuQgOhCgK6m Nc3f4rG4yg/LqWFuwAHIAMrcXVgoQsy9itFzRV6noD5rBiWkaBKhSCT9agiXxSFA++Kf mPKUpytWmsGv/jPiM7JIiPn8aZQ3sYNfGKDUQ= MIME-Version: 1.0 Received: by 10.142.150.32 with SMTP id x32mr5646118wfd.287.1302545300458; Mon, 11 Apr 2011 11:08:20 -0700 (PDT) Sender: eng.mufic@gmail.com Received: by 10.68.65.200 with HTTP; Mon, 11 Apr 2011 11:08:20 -0700 (PDT) In-Reply-To: References: <4DA13620.7060407@freebsd.org> Date: Mon, 11 Apr 2011 20:08:20 +0200 X-Google-Sender-Auth: MP6NfP0IpqboLpRddkefuhVOdGs Message-ID: From: Mohammed Farrag To: Devin Teske Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: "freebsd-hackers@freebsd.org" , Chris Richardson , "freebsd-current@freebsd.org" , "freebsd-emulation@freebsd.org" Subject: Re: Kernel Tracking Question.. regarding kernel and boot files X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2011 18:08:21 -0000 Hey All, Please check this. Check this to use Eclipse/Qemu for Kernel Debugging. http://issaris.blogspot.com/2007/12/download-linux-kernel-sourcecode-from.html It was designed to debug linux kernel. Regards, Mohammed On Sun, Apr 10, 2011 at 9:28 AM, Devin Teske wrote: > On Apr 9, 2011, at 9:46 PM, Julian Elischer wrote: > > > On 4/9/11 2:51 PM, Chris Richardson wrote: > >> On Sat, Apr 9, 2011 at 10:34 PM, Chuck Swiger wrote: > >> > >>> Hi, Chris-- > >>> > >>> [ ...Reply-to: set to direct towards the most appropriate list... ] > >>> > >>> On Apr 9, 2011, at 8:31 AM, Chris Richardson wrote: > >>>> I am totally new to FreeBSD. I was involved within project which > will > >>>> trace the kernel. I used ktrace but I could not get appropriate > results > >>>> about the files being opened. I don't see any of the boot files > boot0-1 > >>> or 2 > >>>> in the ktrace.out file. Where did they go? > >>> The bootstrap loader stages are what loads and runs the kernel. > >>> ktrace isn't available until afterwards, when the kernel is running. > >>> > >>>> Is ktrace the best "trace suite" for freebsd kernel? > >>> Kinda depends on what you are doing. Setting up good logging and > making > >>> userland > >>> interfaces for getting to useful information (cf vmstat, ps, iostat, > etc) > >>> is > >>> more likely to be useful over the longer run. > >>> > >>> > >> What about if I wanna see the interaction between boot process and > kernel > >> loading. > > > > either you run it under an emulator that allows you to single step it. > > or you just add a lot of printf() to the boot loader. > > (some parts are required to fit in small code sizes to adding prints will > cause overflow..) > > best to read the docs and then the sources. then it wil become apparent > to you > > what you want to find out. > > You also have the option of writing Forth modules for the boot-loader. Even > dropping to the "ok" prompt is enough to give you full access to the > built-in Forth interpreter. You can query the variables that are set in the > "environment" (which are different depending whether you've booted via > pxeboot, cdboot, or other method). You can even do some limited device > poking and file-io (both read and write). > > The benefit of the forth modules is that you can use it to produce the > necessary debug output whilst avoiding the overflow issue. That is to say, > that one technique I've used is to add code to the loader to export some > string or value of interest to a variable in the environment that I would > then add something like 'echo "debug == $debug"' to loader.rc. Keeps the > loader small and the human fluff off to the interpreter. > > > > >> > >>>> What about going through source code .. Is it better to > >>>> use Combination of Ecllipse/Qemu and FreeBSD Source tree? > >>> Eclipse is an editor. If you like it in particular, free free to use > it, > >>> otherwise pick something else you'd prefer to use for C code. > > I use a combination of vim (as my editor) and CVSweb (URL is in the > handbook) for historical research as necessary. > > Just my "tuppence." > -- > Devin > > >>> > >>>> Does this method will provide us with someway to see how booting > process > >>> invokes > >>>> the kernel to memory ? Any help will be appreciated. > >>> You're asking about the process here: > >>> > >>> > >>> > http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/boot-blocks.html > >>> > >>> ...? Frankly, none of these are especially big, start by reviewing the > >>> source > >>> code for 'em. > >>> > >>> > >> Yeah. this file provides me with the stages in theoretical way. How > about > >> implementing it using qemu to emulate livecd to see what is going on > boot0. > >> Do you have an idea about that ? > >> > >> Good Luck, > >> > >> > >>> Regards, > >>> -- > >>> -Chuck > >>> > >>> > >>> > >> _______________________________________________ > >> freebsd-current@freebsd.org mailing list > >> http://lists.freebsd.org/mailman/listinfo/freebsd-current > >> To unsubscribe, send any mail to " > freebsd-current-unsubscribe@freebsd.org" > >> > > > > _______________________________________________ > > freebsd-hackers@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > > To unsubscribe, send any mail to " > freebsd-hackers-unsubscribe@freebsd.org" > > _____________ > > The information contained in this message is proprietary and/or > confidential. If you are not the intended recipient, please: (i) delete the > message and all copies; (ii) do not disclose, distribute or use the message > in any manner; and (iii) notify the sender immediately. In addition, please > be aware that any message addressed to our domain is subject to archiving > and review by persons other than the intended recipient. Thank you. > _____________ > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > -- *Mohammed Farrag* *FreeBSD Contributor* From owner-freebsd-current@FreeBSD.ORG Mon Apr 11 18:26:17 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5C5DA1065670; Mon, 11 Apr 2011 18:26:17 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-yi0-f54.google.com (mail-yi0-f54.google.com [209.85.218.54]) by mx1.freebsd.org (Postfix) with ESMTP id C17398FC08; Mon, 11 Apr 2011 18:26:16 +0000 (UTC) Received: by yie12 with SMTP id 12so2687750yie.13 for ; Mon, 11 Apr 2011 11:26:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=UJMMtolQWTT4fQ+9HTtbK9IgHf+m4L3tOdO3FJZHnrg=; b=MNE9uyrVxcJtlR7L0JaYR8sVI7oPUELKT9A+jbpqBt0eWXK1X3STrahSw3iqlJc9jV Swt+OCC9UOu0p33CTdPDix7nocXIayziRJpndos27+dSI1g83kVeZ5DKB5+y8cWR5GTN jv1OWzXf1UU4Bx8W86+T69nIGCjcyaYn44iDE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=qAvmKvB7awCxquNEzj649QG6PEFhytT17BT6ABjQO34Hu0cfkQ7JI9PQnHhkV4eO/v WxBdFypln28Iq0IyAsJwT4yIFr1tEVSpDphJcSPHwILezH7yD3B3HlMUX8QEmxllZdD0 2nxe6gZcMRwNi0XikDjfaKUei+kL5H/PJLrIM= MIME-Version: 1.0 Received: by 10.90.249.25 with SMTP id w25mr3166759agh.55.1302546375731; Mon, 11 Apr 2011 11:26:15 -0700 (PDT) Received: by 10.90.67.9 with HTTP; Mon, 11 Apr 2011 11:26:15 -0700 (PDT) In-Reply-To: <86aafxx5jd.fsf@kopusha.home.net> References: <20110402084431.GB1849@garage.freebsd.pl> <86aafxx5jd.fsf@kopusha.home.net> Date: Mon, 11 Apr 2011 11:26:15 -0700 Message-ID: From: Freddie Cash To: Mikolaj Golub Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD Filesystems , FreeBSD Stable , FreeBSD-Current , Pawel Jakub Dawidek Subject: Re: Any success stories for HAST + ZFS? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2011 18:26:17 -0000 On Sun, Apr 10, 2011 at 12:36 PM, Mikolaj Golub wrote= : > On Mon, 4 Apr 2011 11:08:16 -0700 Freddie Cash wrote: > =C2=A0FC> Once the deadlock patches above are MFC'd to -STABLE, I can do = an > =C2=A0FC> upgrade cycle and test them. > > Committed to STABLE. Updated src tree to r220537. Recompiled world, kernel, etc. Installed world, kernel, etc. ZFSv28 patch was not affected. Everything is detected correctly, everything comes up correctly. See a new option (reload) in the RC script for hast. Can create/change role for 24 hast devices simultaneously. Can switch between master/slave modes. Have 5 rsyncs running in parallel without any issues, transferring 80-120 Mbps over the network (just under 100 Mbps seems to be the average right now). Switching roles while the rsyncs are running succeeds without deadlocking (obviously, rsync complains a whole bunch while the switch happens as the pool disappears out from underneath it, but it picks up again when the pool is back in place). Hitting the reset switch on the box while the rsyncs are running doesn't affect the hast devices or the pool, beyond losing the last 5 seconds of writes. It's only been a couple of hours of testing and hammering, but so far things are much more stable/performant than before. Anything else I should test? --=20 Freddie Cash fjwcash@gmail.com From owner-freebsd-current@FreeBSD.ORG Mon Apr 11 18:44:07 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8BB36106566B for ; Mon, 11 Apr 2011 18:44:07 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id C04488FC0A for ; Mon, 11 Apr 2011 18:44:06 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id VAA03364 for ; Mon, 11 Apr 2011 21:44:05 +0300 (EEST) (envelope-from avg@FreeBSD.org) Message-ID: <4DA34BF4.9010107@FreeBSD.org> Date: Mon, 11 Apr 2011 21:44:04 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.15) Gecko/20110309 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: freebsd-current@FreeBSD.org X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Subject: amd family 15h topology detection X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2011 18:44:07 -0000 Here is a patch that should prepare us for AMD Bulldozer CPUs: http://people.freebsd.org/~avg/amd-f15h-topo.diff The patch should not affect pre-10h systems at all, on 10h systems the new code path should be taken, but the result should be the same as the legacy method. P.S. I think that the legacy method will keep working with Bulldozer, but I am not completely sure. Anyway, I hope to find some time to improve our topology detection code so that it doesn't assume uniformity and also takes into account cache topology. And then this change will be more useful. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Mon Apr 11 19:52:44 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9E2041065677; Mon, 11 Apr 2011 19:52:44 +0000 (UTC) (envelope-from to.my.trociny@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 3EB9F8FC08; Mon, 11 Apr 2011 19:52:43 +0000 (UTC) Received: by bwz12 with SMTP id 12so6206625bwz.13 for ; Mon, 11 Apr 2011 12:52:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:from:to:cc:subject:references:x-comment-to :sender:date:in-reply-to:message-id:user-agent:mime-version :content-type:content-transfer-encoding; bh=kXIXPANkKpQfDqNW8Pj3qaLyTIsoM6htLetHO/WepfM=; b=GkXOfFDsMseHPfCbnfV05SMG63JFgMyNdjrU3qz/eiHxSChcDFk7z+8QorA2aXDyk4 b115IhM4Vu/6WO1nIKjyFn3+viqXL4Logymdz47Rkl1iK5hgpY2uaJ6Te4tDyg9c+foJ I/qofbOfLwT3bD4dmNuCuk8Q7tMI2+UII/ZyI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:subject:references:x-comment-to:sender:date:in-reply-to :message-id:user-agent:mime-version:content-type :content-transfer-encoding; b=kEIoJBv+Jxh+KJFQ0dzA0L2IUtnEKySaFI07inqX/cZn7S6m/gyOSotY50Fm2o9I6t jDjtdtrhoAqTB6/lWxG/bATgH6OKYOLEZq9rLx91q7JbuJcD2Oqvbbk4B1/gsor7ctCp AanzG2HzMG0XS2B6v2t1/Oqjmjubdarzl3sOM= Received: by 10.204.19.80 with SMTP id z16mr1150205bka.198.1302551562281; Mon, 11 Apr 2011 12:52:42 -0700 (PDT) Received: from localhost ([95.69.172.154]) by mx.google.com with ESMTPS id l1sm3411966bkl.1.2011.04.11.12.52.39 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 11 Apr 2011 12:52:40 -0700 (PDT) From: Mikolaj Golub To: Freddie Cash References: <20110402084431.GB1849@garage.freebsd.pl> <86aafxx5jd.fsf@kopusha.home.net> X-Comment-To: Freddie Cash Sender: Mikolaj Golub Date: Mon, 11 Apr 2011 22:52:37 +0300 In-Reply-To: (Freddie Cash's message of "Mon, 11 Apr 2011 11:26:15 -0700") Message-ID: <867hb0tvju.fsf@kopusha.home.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 8bit Cc: Mikolaj Golub , FreeBSD Filesystems , FreeBSD-Current , Pawel Jakub Dawidek , FreeBSD Stable Subject: Re: Any success stories for HAST + ZFS? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2011 19:52:44 -0000 On Mon, 11 Apr 2011 11:26:15 -0700 Freddie Cash wrote: FC> On Sun, Apr 10, 2011 at 12:36 PM, Mikolaj Golub wrote: >> On Mon, 4 Apr 2011 11:08:16 -0700 Freddie Cash wrote: >> šFC> Once the deadlock patches above are MFC'd to -STABLE, I can do an >> šFC> upgrade cycle and test them. >> >> Committed to STABLE. FC> Updated src tree to r220537. Recompiled world, kernel, etc. FC> Installed world, kernel, etc. ZFSv28 patch was not affected. FC> Everything is detected correctly, everything comes up correctly. See FC> a new option (reload) in the RC script for hast. FC> Can create/change role for 24 hast devices simultaneously. FC> Can switch between master/slave modes. FC> Have 5 rsyncs running in parallel without any issues, transferring FC> 80-120 Mbps over the network (just under 100 Mbps seems to be the FC> average right now). FC> Switching roles while the rsyncs are running succeeds without FC> deadlocking (obviously, rsync complains a whole bunch while the switch FC> happens as the pool disappears out from underneath it, but it picks up FC> again when the pool is back in place). FC> Hitting the reset switch on the box while the rsyncs are running FC> doesn't affect the hast devices or the pool, beyond losing the last 5 FC> seconds of writes. FC> It's only been a couple of hours of testing and hammering, but so far FC> things are much more stable/performant than before. Cool! Thanks for reporting! FC> Anything else I should test? Nothing particular, but any tests and reports are appreciated. E.g. ones of the recent features Pawel has added are checksum and compression. You could try different options and compare :-) -- Mikolaj Golub From owner-freebsd-current@FreeBSD.ORG Tue Apr 12 05:09:59 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6A343106564A for ; Tue, 12 Apr 2011 05:09:59 +0000 (UTC) (envelope-from naylor.b.david@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id F0AA18FC0C for ; Tue, 12 Apr 2011 05:09:58 +0000 (UTC) Received: by wwc33 with SMTP id 33so7045294wwc.31 for ; Mon, 11 Apr 2011 22:09:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:from:to:subject:date:user-agent:mime-version :content-type:content-transfer-encoding:message-id; bh=RSpfX7IAFCf0uMnSGky8uecAfc8OSnIUXn2bN0WjXNM=; b=jInylu2s7jRJctLjDBAskzVeArDobxxFUpvXRuP/N2QN3dxQQyay3bnSe8BQ+8SkBa pS3kzo10mWKE22kCixvJT4flUu6IQz6SIx3IQKAo16UbIcttYL8wW/s6eblEZN2lVTTE rUtUz/yEx3/xpFm5jJqfgKFpkJvD8Gv9r9FU4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:date:user-agent:mime-version:content-type :content-transfer-encoding:message-id; b=ViJH3ufs/gqFQe/rcqohr9kvwfvfBYMoYbm+NmvOZobpC/4ffqH4RIKv0Rtp74W0qR 1k+KabW1x7SRvT7VsX6xev0gYG7uQBAeriWvdKQyT2uOCqUXiK27O2n0M5B/xeAMXB0w QXH+nmhsAdIhejTPmXEI5DLK2Ef5ZX4Ym2Rts= Received: by 10.227.9.196 with SMTP id m4mr6135925wbm.196.1302583208396; Mon, 11 Apr 2011 21:40:08 -0700 (PDT) Received: from dragon.dg (41-135-148-75.dsl.mweb.co.za [41.135.148.75]) by mx.google.com with ESMTPS id ed10sm3776872wbb.66.2011.04.11.21.40.06 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 11 Apr 2011 21:40:07 -0700 (PDT) From: David Naylor To: freebsd-current@freebsd.org Date: Tue, 12 Apr 2011 06:39:46 +0200 User-Agent: KMail/1.13.5 (FreeBSD/9.0-CURRENT; KDE/4.6.1; amd64; ; ) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1319163.Hord9qiUMS"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201104120639.49459.naylor.b.david@gmail.com> Subject: [regression] unable to boot: no GEOM devices found. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2011 05:09:59 -0000 --nextPart1319163.Hord9qiUMS Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I am running -current and since a few days ago (at least 2011/04/11) I am=20 unable to boot. =20 The boot process stops when it looks to find a bootable device. The prompt= =20 (when pressing '?') does not display any device and yielding one second (or= =20 more) to the kernel (by pressing '.') does not improve the situation. =20 A known working date is 2011/02/20. =20 I am running amd64 on a nVidia MCP51 chipset. =20 I am willing to help any way I can. =20 Regards, David --nextPart1319163.Hord9qiUMS Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (FreeBSD) iEYEABECAAYFAk2j15UACgkQUaaFgP9pFrLbCgCcCIz67saVnCl1qOeMYF3r8v8x rcsAn3NeMJdpt2c1ESt+9HlBKfjaptJI =HPm+ -----END PGP SIGNATURE----- --nextPart1319163.Hord9qiUMS-- From owner-freebsd-current@FreeBSD.ORG Tue Apr 12 06:18:06 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 61456106566B for ; Tue, 12 Apr 2011 06:18:06 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id E588F8FC12 for ; Tue, 12 Apr 2011 06:18:05 +0000 (UTC) Received: by fxm11 with SMTP id 11so5414278fxm.13 for ; Mon, 11 Apr 2011 23:18:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=45lyZidrI/VKKo45xKWcvMGy5gOd6EK+cNETC93/wjI=; b=brD1k//Ow3ITui2wP9ty/nEYAG2dHtbR45rsYLbQrrA1blat6+/ptQGQnrzUlpZpr7 5qGdw2Jhx5MqTMEOXTury9f0dRzWI0s2U8suhstDgIXRV3WOYsC7Y7ceeBq+I+Bz7Afb UnAs3m7NCy4KsPXYqeYPwQ3iYB4nDbNOPsu94= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=H6iq87LnwRbIOiX/2MwjiQYulJHEB/2KLCG429Qac1syzxFA3NHYcresn17RvKp3dH HjSRFrQs7xmOs5MEJ1GP0xGBzucF1fkcC3tyrxzIC5ZuJ0Sl0//S/TrUUcte8S7zDUJ1 oLKkpgiOwZGQ+vCT51floJ3frQq+kCI6/es4I= Received: by 10.223.106.78 with SMTP id w14mr6462360fao.35.1302589084854; Mon, 11 Apr 2011 23:18:04 -0700 (PDT) Received: from mavbook2.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id l3sm949892fap.12.2011.04.11.23.18.03 (version=SSLv3 cipher=OTHER); Mon, 11 Apr 2011 23:18:04 -0700 (PDT) Sender: Alexander Motin Message-ID: <4DA3EE8F.8050306@FreeBSD.org> Date: Tue, 12 Apr 2011 09:17:51 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: David Naylor References: In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD-Current Subject: Re: [regression] unable to boot: no GEOM devices found. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2011 06:18:06 -0000 David Naylor wrote: > I am running -current and since a few days ago (at least 2011/04/11) I am > unable to boot. > > The boot process stops when it looks to find a bootable device. The prompt > (when pressing '?') does not display any device and yielding one second (or > more) to the kernel (by pressing '.') does not improve the situation. > > A known working date is 2011/02/20. > > I am running amd64 on a nVidia MCP51 chipset. MCP51... again... > I am willing to help any way I can. You could start from capturing and showing verbose dmesg. Full or at least in parts related to disks. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Tue Apr 12 08:04:16 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8A361106566C; Tue, 12 Apr 2011 08:04:16 +0000 (UTC) (envelope-from gljennjohn@googlemail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id DFACE8FC16; Tue, 12 Apr 2011 08:04:15 +0000 (UTC) Received: by bwz12 with SMTP id 12so6682367bwz.13 for ; Tue, 12 Apr 2011 01:04:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:date:from:to:cc:subject:message-id:in-reply-to :references:reply-to:x-mailer:mime-version:content-type :content-transfer-encoding; bh=3jI1MZkFe1S0IrlivhXxBZPCeS9WooM24e7ltYMaERk=; b=HNtkCCw+fsXWcmKOMUdd2ujaFU7MhPY16uKD+D/dxGaePULM/KaXy0n9t64nhSXfqn WQwl4aUh4SR38Tbd4s26RLQQDLDaDnB6CDTTxYj/4ejMVhDGC65sNvbURApz6SGq9Car /ExdYraKsP+cQq/T7mpAlGsmNbo9P1epnnv78= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=date:from:to:cc:subject:message-id:in-reply-to:references:reply-to :x-mailer:mime-version:content-type:content-transfer-encoding; b=rUvcGhfw2NHoyI6mMpP2KEDmv08VZPyTmqbkN5LC1GCJz5s0hlx9n+di3ZcLt7QOvx LQIi3M8ySFreCosAEJYe0WiQoNe0WoVt8hYS0GQz0cL2e1d0w4FHLhlAmasOASufKQyh 4xsUUsbG06nFccyCyk1DznZAc5wrQ4hyZYf8k= Received: by 10.204.168.66 with SMTP id t2mr5556005bky.53.1302595454602; Tue, 12 Apr 2011 01:04:14 -0700 (PDT) Received: from ernst.jennejohn.org (p578E252E.dip.t-dialin.net [87.142.37.46]) by mx.google.com with ESMTPS id t1sm3674025bkx.19.2011.04.12.01.04.12 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 12 Apr 2011 01:04:13 -0700 (PDT) Date: Tue, 12 Apr 2011 10:04:11 +0200 From: Gary Jennejohn To: Andriy Gapon Message-ID: <20110412100411.54a3f7eb@ernst.jennejohn.org> In-Reply-To: <4DA34BF4.9010107@FreeBSD.org> References: <4DA34BF4.9010107@FreeBSD.org> X-Mailer: Claws Mail 3.7.8 (GTK+ 2.18.7; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org Subject: Re: amd family 15h topology detection X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gljennjohn@googlemail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2011 08:04:16 -0000 On Mon, 11 Apr 2011 21:44:04 +0300 Andriy Gapon wrote: > Here is a patch that should prepare us for AMD Bulldozer CPUs: > http://people.freebsd.org/~avg/amd-f15h-topo.diff The patch should not > affect pre-10h systems at all, on 10h systems the new code path should > be taken, but the result should be the same as the legacy method. > I can verify that there are no changes for my pre-f10h model. I have an old f6b stepping 2 model and AFAICT the output is the same. -- Gary Jennejohn From owner-freebsd-current@FreeBSD.ORG Tue Apr 12 09:24:31 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7A1151065670 for ; Tue, 12 Apr 2011 09:24:31 +0000 (UTC) (envelope-from ftp51246-2575596@sh4-5.1blu.de) Received: from sh4-5.1blu.de (sh4-5.1blu.de [213.83.63.54]) by mx1.freebsd.org (Postfix) with ESMTP id 427928FC1B for ; Tue, 12 Apr 2011 09:24:30 +0000 (UTC) Received: from ftp51246-2575596 by sh4-5.1blu.de with local (Exim 4.50) id 1Q9Zpf-0004hF-Cb; Tue, 12 Apr 2011 11:24:24 +0200 Date: Tue, 12 Apr 2011 11:24:23 +0200 From: Matthias Apitz To: Alexander Kabaev , freebsd-current@freebsd.org Message-ID: <20110412092422.GA16146@sh4-5.1blu.de> References: <20110408084232.GA28116@sh4-5.1blu.de> <4D9EE09F.6050409@FreeBSD.org> <20110408120335.GA2648@sh4-5.1blu.de> <20110408172459.78c5d730@kan.dnsalias.net> <20110411073145.GA18454@sh4-5.1blu.de> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20110411073145.GA18454@sh4-5.1blu.de> X-Operating-System: FreeBSD 7.0-RELEASE (i386) User-Agent: Mutt/1.5.9i Cc: Subject: Re: vmware-tools-freebsd && "No drivers for x.org version: 7.6.5." X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Matthias Apitz List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2011 09:24:31 -0000 El día Monday, April 11, 2011 a las 09:31:47AM +0200, Matthias Apitz escribió: > Hello, > > I removed the VMware' vmware-tools-freebsd and installed from the ports > x11-drivers/xf86-input-vmmouse and x11-drivers/xf86-video-vmware; > > When I now run 'X -configure' the X.org server Seg faults after loading > the /usr/local/lib/xorg/modules/drivers/vmware_drv.so > (a complete Xorg.0.log is attached) > > Any ideas or should I file a bug report? I filed a bug report http://www.freebsd.org/cgi/query-pr.cgi?pr=156330 which was ofc closed because I should update the ports tree (mine is from November 2010); I will do this later in another VM. To overcome the current problem I have just copied over the file /etc/X11/xorg.conf from another VM where it was generated using the VMware's driver in 8.x; it works just fine there in 9-CURRENT with the x11-drivers/xf86-video-vmware driver in high res 1920x1200 and cut&paste between the VM's and Win apps. Thanks matthias -- Matthias Apitz t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 e - w http://www.unixarea.de/ From owner-freebsd-current@FreeBSD.ORG Tue Apr 12 10:44:43 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EFA2B106566B for ; Tue, 12 Apr 2011 10:44:42 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id A5C4D8FC1B for ; Tue, 12 Apr 2011 10:44:42 +0000 (UTC) Received: by iwn33 with SMTP id 33so7930167iwn.13 for ; Tue, 12 Apr 2011 03:44:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:date:from:to:cc:subject:message-id :references:mime-version:content-type:content-disposition :in-reply-to:x-openpgp-key-id:x-openpgp-key-fingerprint :x-openpgp-key-url; bh=A5Tc3+ZX7BPMDpqE56Idz5vbXTOjwhqjIVtMDWaJNu8=; b=FQGBND3RHrJ8zF9I58zJTSRTZ/NOAqjtjQ8rytKA7pmSfvVv21HwXaYUjAz8/WHTDw P58fMDO9sxb4EUMimQyxUjLEq2YJTd2hfvOSUemfQr6WzVn//0mevtS+KafmRms+5AUF 96ZrjX5ARIcfQCY6XWHm76strSZIRfYNeuqiw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:x-openpgp-key-id :x-openpgp-key-fingerprint:x-openpgp-key-url; b=k5c96h7fAmFoPUllwOO49DKqhONRHaRRF0NB0pjx5S458i+m7zGS3FmvPZMQxSSFce 0J+wmHp1dtFys/GVnY/wp4cOa0oxlK/CCrppPSW+h/2lbK37FFselPryzKdDuYApk+jU iY9Sccb/TF5eOuFJ3xUJEPjm8TCQppH3eM7dg= Received: by 10.42.161.197 with SMTP id u5mr9725548icx.466.1302605081998; Tue, 12 Apr 2011 03:44:41 -0700 (PDT) Received: from DataIX.net (adsl-99-181-151-134.dsl.klmzmi.sbcglobal.net [99.181.151.134]) by mx.google.com with ESMTPS id d9sm4871264ibb.36.2011.04.12.03.44.39 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 12 Apr 2011 03:44:40 -0700 (PDT) Sender: "J. Hellenthal" Received: from DataIX.net (localhost [127.0.0.1]) by DataIX.net (8.14.4/8.14.4) with ESMTP id p3CAiaHu041629 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 12 Apr 2011 06:44:37 -0400 (EDT) (envelope-from jhell@DataIX.net) Received: (from jhell@localhost) by DataIX.net (8.14.4/8.14.4/Submit) id p3CAiYMf041589; Tue, 12 Apr 2011 06:44:34 -0400 (EDT) (envelope-from jhell@DataIX.net) Date: Tue, 12 Apr 2011 06:44:34 -0400 From: "J. Hellenthal" To: Sergey Vinogradov Message-ID: <20110412104433.GA29090@DataIX.net> References: <4DA2EFEF.3010004@lazybytes.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="PEIAKu/WMn1b1Hv9" Content-Disposition: inline In-Reply-To: <4DA2EFEF.3010004@lazybytes.org> X-OpenPGP-Key-Id: 0x89D8547E X-OpenPGP-Key-Fingerprint: 85EF E26B 07BB 3777 76BE B12A 9057 8789 89D8 547E X-OpenPGP-Key-URL: http://bit.ly/0x89D8547E Cc: freebsd-current@freebsd.org Subject: Re: [PATCH] ifconfig(8) flag to display IPv4 netmasks in dot-decimal format X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2011 10:44:43 -0000 --PEIAKu/WMn1b1Hv9 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Apr 11, 2011 at 04:11:27PM +0400, Sergey Vinogradov wrote: >Hi, >I've written a tiny-tiny patch, which adds the '-t' flag to >ifconfig(8). It modifies the output to display IPv4 netmasks in dotted >decimal notation: > Sorry but as much as I would like to see this happen and change the display of the netmask I just cannot seem to come to a genuine consensus that justifies adding a '-t' flag or any flag for that matter just to modify the output of one field in the display of ifconfig(8) In general flags to programs usually should carry some sort of meaning to what they are meant to do and I dont really see that for '-t' and netmask display. What I feel would be a better approach to this is checking the environ(7) for some sort of variable that can be specified on a per-user basis or the system as a whole. As to what that variable would be called I could only suggest in a naming convention to be ``HUMANIZE'' or something similiar and then ifconfig(8) could be the first consumer of that variable and probably shortly following du(1) & df(1). This variable could also be one that acts as BLOCKSIZE does to df(1) output and also be available for consumption by other utilities that may need fine tuning without breaking existing interfaces. --=20 Regards, J. Hellenthal --PEIAKu/WMn1b1Hv9 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (FreeBSD) Comment: http://bit.ly/0x89D8547E iQEcBAEBAgAGBQJNpC0RAAoJEJBXh4mJ2FR+EVsIAIfhHRL9qSsiiCw8k0aLecBt 4lAbXEvD0oHsY6bVYye/SHpBSS8e5qdKxpMKRL6zLJWcqV1CjFF7CInrMvsGNnRN lfmk0qibHfpKpVOUSr4HH38YUBDXpRObY9x1VkZ27UHPho+5SO6aADEzOf5CQ0V5 luohivA4FMCZ1EuPRLqdPhPtlANZKgQXFKqNv9ZUY+eOYN8XI/puTu9TeA+31m8M sOts1cktrpetCspdAfyh7W1GzsFFAlISe/N1x+ZlkdQZwq2ds3fuapBk+GO1SxXY kDTfeugJljjZYp8aZxYKjlbXx6NxBFAPZBMBiJCDLmm2BTy6WC9DRCbEd9HKQnY= =WUvQ -----END PGP SIGNATURE----- --PEIAKu/WMn1b1Hv9-- From owner-freebsd-current@FreeBSD.ORG Tue Apr 12 08:37:28 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 93BDB106566C; Tue, 12 Apr 2011 08:37:28 +0000 (UTC) (envelope-from petefrench@ingresso.co.uk) Received: from constantine.ingresso.co.uk (constantine.ingresso.co.uk [IPv6:2001:470:1f09:176e::3]) by mx1.freebsd.org (Postfix) with ESMTP id 5EAA08FC0C; Tue, 12 Apr 2011 08:37:28 +0000 (UTC) Received: from dilbert.london-internal.ingresso.co.uk ([10.64.50.6] helo=dilbert.ticketswitch.com) by constantine.ingresso.co.uk with esmtps (TLSv1:AES256-SHA:256) (Exim 4.73 (FreeBSD)) (envelope-from ) id 1Q9Z6E-000623-Ju; Tue, 12 Apr 2011 09:37:26 +0100 Received: from petefrench by dilbert.ticketswitch.com with local (Exim 4.74 (FreeBSD)) (envelope-from ) id 1Q9Z6E-0002qY-J0; Tue, 12 Apr 2011 09:37:26 +0100 To: fjwcash@gmail.com, trociny@freebsd.org In-Reply-To: Message-Id: From: Pete French Date: Tue, 12 Apr 2011 09:37:26 +0100 X-Mailman-Approved-At: Tue, 12 Apr 2011 11:14:46 +0000 Cc: freebsd-fs@freebsd.org, pjd@freebsd.org, freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: Re: Any success stories for HAST + ZFS? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2011 08:37:28 -0000 > Everything is detected correctly, everything comes up correctly. See > a new option (reload) in the RC script for hast. same here - have patched the master databse achines, all came up fine, everything running erfectly, have flip-flopped between the two machines with no ill effects whatsoever, and all looking very good. cheers, -pete. From owner-freebsd-current@FreeBSD.ORG Tue Apr 12 12:26:48 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7201F106566C for ; Tue, 12 Apr 2011 12:26:48 +0000 (UTC) (envelope-from inyaoo@gmail.com) Received: from mail-yi0-f54.google.com (mail-yi0-f54.google.com [209.85.218.54]) by mx1.freebsd.org (Postfix) with ESMTP id 2922A8FC0A for ; Tue, 12 Apr 2011 12:26:47 +0000 (UTC) Received: by yie12 with SMTP id 12so2996220yie.13 for ; Tue, 12 Apr 2011 05:26:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-type; bh=/Rt05+ZPA3Qsvsw1gd5wHYfSueSb8Ai0DgUnXkUN1RM=; b=wvZDwaS2SVTEDitPSZtV6YW//YBDS5u7xSo+8sYKLT35rTD1MuWuX4xcJuhvjDyG3J qlhIjCFZ6Q0Q69HuiZUJcJpznTskU29cJIMRgfkdm+lHteM9l6Nmv/KfCTKqdXf4NHTV Be/vdcJRi2Lf2eSwiOwk7FK7KCkRnk4Vn1bpQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-type; b=IlURnTuSPn4MA53JtRmz32n9u2ES+2vLiJi4bNgYSLY+dsBzz/nURKCOIq64ZrvZWu E0MGL5qcs4fipTq1o7UVScugjPfUT3BPlbY6sPnK88B9CT9nmADJMG+mn4KMaQBR1Jqe 7xwbySROpbWM+/NYvBK+Wm5R5XtVVzaNH2GcQ= Received: by 10.151.6.6 with SMTP id j6mr5548215ybi.322.1302609323735; Tue, 12 Apr 2011 04:55:23 -0700 (PDT) Received: from localhost (zeller.torservers.net [74.120.12.135]) by mx.google.com with ESMTPS id b4sm1596780ybn.8.2011.04.12.04.55.20 (version=SSLv3 cipher=OTHER); Tue, 12 Apr 2011 04:55:21 -0700 (PDT) From: Pan Tsu To: Sergey Vinogradov References: <4DA2EFEF.3010004@lazybytes.org> Date: Tue, 12 Apr 2011 15:55:11 +0400 In-Reply-To: <4DA2EFEF.3010004@lazybytes.org> (Sergey Vinogradov's message of "Mon, 11 Apr 2011 16:11:27 +0400") Message-ID: <86oc4blm5c.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain Cc: freebsd-current@freebsd.org Subject: Re: [PATCH] ifconfig(8) flag to display IPv4 netmasks in dot-decimal format X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2011 12:26:48 -0000 Sergey Vinogradov writes: > Hi, > I've written a tiny-tiny patch, which adds the '-t' flag to > ifconfig(8). It modifies the output to display IPv4 netmasks in dotted > decimal notation: [...] > % ifconfig -t msk0 [...] > inet 10.10.0.1 netmask 255.255.255.0 broadcast 10.10.0.255 Isn't netstat(8) a better place for such an option? domask() already converts netmask to CIDR notation if possible, e.g. `netstat -ni' 10.10.0.1/24 10.10.0.1&0xff00ff00 Unfortunately, Network column is always truncated to 13 characters even with -W flag while it can be up to 26 characters long with `-n' flag or more with a symbolic network name. From owner-freebsd-current@FreeBSD.ORG Tue Apr 12 13:33:20 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 922AF1065673 for ; Tue, 12 Apr 2011 13:33:20 +0000 (UTC) (envelope-from s.seira@cdmon.com) Received: from correo.cdmon.com (correo.cdmon.com [212.36.82.9]) by mx1.freebsd.org (Postfix) with ESMTP id 4EB2A8FC12 for ; Tue, 12 Apr 2011 13:33:19 +0000 (UTC) Received: from genocida (localhost.cdmon.com [127.0.0.1]) by correo.cdmon.com (Postfix) with ESMTP id 01CE8130F3C for ; Tue, 12 Apr 2011 15:14:39 +0200 (CEST) Received: from antispam (localhost.cdmon.com [127.0.0.1]) by correo.cdmon.com (Postfix) with ESMTP id ADA89130E84 for ; Tue, 12 Apr 2011 15:14:38 +0200 (CEST) Received: from [192.168.0.30] (155.Red-88-2-251.staticIP.rima-tde.net [88.2.251.155]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by correo.cdmon.com (Postfix) with ESMTP id 50FCC130E38 for ; Tue, 12 Apr 2011 15:14:38 +0200 (CEST) Message-ID: <4DA45042.5060204@cdmon.com> Date: Tue, 12 Apr 2011 15:14:42 +0200 From: Sergi Seira User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100515 Lightning/1.0b1 Icedove/3.0.4 MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: background fsck high load on 8.1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2011 13:33:20 -0000 Hello, we've experienced that background fsck on 8.1 degrades server performance on a higher degree than in previous fbsd versions (6.3, 7.3; amd64). We've noticed it after upgrading - same hardware - to a 8.1-RELEASE. Now, performance of other services (i.e. apache, mysql) during a background fsck falls miserably. Is there any way to calm fsck down?, nice(1)?, some sysctl? We have also gmirror, but we prevent to rebuild it if there is a fsck running in background. Thanks for your help, regards, Sergi From owner-freebsd-current@FreeBSD.ORG Tue Apr 12 14:24:13 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0F8FD106564A for ; Tue, 12 Apr 2011 14:24:13 +0000 (UTC) (envelope-from venture37@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id B217D8FC0C for ; Tue, 12 Apr 2011 14:24:12 +0000 (UTC) Received: by vxc34 with SMTP id 34so6077129vxc.13 for ; Tue, 12 Apr 2011 07:24:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=CH0Xr5uGT++4NHCpLyeLgUVYEau2d1Ms7IzQyCldJBI=; b=HsfF57IssFK0KQMb54rYlVpEgCy+BLoDWPm8df/tQoCXW7u4lFyU2DCrBGv2Xz3LLt jnsEMzIEDFVUtm31OdCAwwm7FBadGncy1fr6JzL5eFG5MPGf23ZUOQkHpKfiVV5FgWj8 zLk0lYAMWgfzKibtt8G2T4b8FxwPHbJ9S4cVs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=lYMJuXhlyuBcBj4D/YYs0KCO8cF6vGgLlZyeXy4p83zpiI/GuJ5Et2nQBQ9vO7rogC vq1q8ShhQTscfh0zO2csj0gbMPUi/fMlzr4tRp67ueOXsjDEokg2vrgZo7It1+XmeoGE MS2Y3J6SmdP03b3wTc0xNBiGcolu5ZQmsS4SI= MIME-Version: 1.0 Received: by 10.220.88.155 with SMTP id a27mr1804340vcm.249.1302618251298; Tue, 12 Apr 2011 07:24:11 -0700 (PDT) Received: by 10.220.16.212 with HTTP; Tue, 12 Apr 2011 07:24:11 -0700 (PDT) In-Reply-To: References: <20110314162936.d3f8fd5b.ray@dlink.ua> <4D80EE33.7010703@janh.de> <20110317100804.2dde85ba@gmail.com> <20110317110700.05191e8f@gmail.com> <20110320153604.e8245880.ray@ddteam.net> <20110331120710.b5c5f24b.ray@dlink.ua> Date: Tue, 12 Apr 2011 15:24:11 +0100 Message-ID: From: "Sevan / Venture37" To: freebsd-current@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Aleksandr Rybalko Subject: Re: [CFT]RT28xx/RT30xx wireless was [CFR]RT305xF support, w/o attachment X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2011 14:24:13 -0000 On 31 March 2011 16:50, Sevan / Venture37 wrote: > On 31 March 2011 10:07, Aleksandr Rybalko wrote: >> Now good peoples help me with rework of driver, then this driver will be= available under ral(4). >> So you need to wait some time. > > Excellent, I'm happy to be a tester for patches, the card is a > Azurewave RT2700E out of a EEPC if I remember right AzureWave AW-NE766-VOA to be exact Model No: RT2700E >>>> I will post dmesg & pciconf output tomorrow once I have an ethernet >>>> cable or removable media near me if you need more info. >> >> Yeah, post please. at minimum I've interesting which RF used in your dev= ice. > > rt28600: mem 0xf7f00000-0xf7f0ffff irq 17 at > device 0.0 on pci3 > rt28600: invalid EEPROM LNA gain #2: 0x00 > rt28600: invalid EEPROM LNA gain #3: 0x00 > rt28600: invalid EEPROM powersave level > rt28600: MAC/BBP RT2860 (rev 0x28720200), RF RT3022 2.4G 2T2R > rt28600: skip channel 10, could not find extension channel > rt28600: skip channel 11, could not find extension channel > rt28600: skip channel 12, could not find extension channel > rt28600: skip channel 13, could not find extension channel > rt28600: skip channel 14, could not find extension channel > > > rt28600@pci0:3:0:0: =C2=A0 =C2=A0 class=3D0x028000 card=3D0x27901814 chip= =3D0x07811814 > rev=3D0x00 hdr=3D0x00 > =C2=A0 =C2=A0vendor =C2=A0 =C2=A0 =3D 'Ralink Technology, Corp.' > =C2=A0 =C2=A0device =C2=A0 =C2=A0 =3D 'Wireless (RT2860/RT2890)' > =C2=A0 =C2=A0class =C2=A0 =C2=A0 =C2=A0=3D network > > > Sevan > From owner-freebsd-current@FreeBSD.ORG Tue Apr 12 15:02:44 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1F7541065675 for ; Tue, 12 Apr 2011 15:02:44 +0000 (UTC) (envelope-from gkontos.mail@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id DE9AB8FC16 for ; Tue, 12 Apr 2011 15:02:43 +0000 (UTC) Received: by iwn33 with SMTP id 33so8188774iwn.13 for ; Tue, 12 Apr 2011 08:02:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=tO7nym4XDnEFLOL/V2nJSc/ieFZ+8JfbYReHHmeaFb8=; b=D2fzs3PqEhaPIwnhklvhMQ6uesT4B4Mz7FTpojxO9wfgs0jxE51LV/7o/FMpaO3o1U GhpKc9G4CmDkC12w/c8KWK7KwByGJevuY5CLC8nAvOcF2Z4GXZKPk26vmuVzkU09BZ8M 2spmOVEVIUrVOFfMPiQyDlwo0yyHl5gRDXrf4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=YtyWKsSlZljLjIMRA2hKQ1JxhXqH1P/EEXh9cAAVIk8iYu4z5yuoHIZT+3+xywCTGO a+ot5PNQz59VvvDkNlhedLkN92jrEl6C8QaQyV+3zn/X4MOZl5qPlLM2PjtGFYfkntXm +GOLLGoBJSQ1IVwAV8uHyzbVvl4KKMkyjJB40= MIME-Version: 1.0 Received: by 10.42.83.140 with SMTP id h12mr1440636icl.389.1302620563233; Tue, 12 Apr 2011 08:02:43 -0700 (PDT) Received: by 10.231.11.196 with HTTP; Tue, 12 Apr 2011 08:02:43 -0700 (PDT) Date: Tue, 12 Apr 2011 18:02:43 +0300 Message-ID: From: George Kontostanos To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: make release X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2011 15:02:44 -0000 I am trying to make a release with the following arguments: make release CHROOTDIR=/usr/home/current BUILDNAME=9-CURRENT EXTSRCDIR=/usr/src NOPORTS=YES MAKE_ISOS=YES however /usr/home/current is being ignored completely and everything ends up in /usr/obj/usr/src. Am I doing something wrong ? Thanks -- George Kontostanos aisecure.net From owner-freebsd-current@FreeBSD.ORG Tue Apr 12 15:14:05 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 43EAD1065672 for ; Tue, 12 Apr 2011 15:14:05 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (unknown [IPv6:2001:44b8:7c07:5581:266:e1ff:fe0c:8f16]) by mx1.freebsd.org (Postfix) with ESMTP id CFB3B8FC0A for ; Tue, 12 Apr 2011 15:14:03 +0000 (UTC) Received: from [192.168.42.215] (maarsy.rocketrange.no [128.39.153.30]) (authenticated bits=0) by cain.gsoft.com.au (8.14.4/8.14.3) with ESMTP id p3CFDtrk099318 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 13 Apr 2011 00:43:59 +0930 (CST) (envelope-from doconnor@gsoft.com.au) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Daniel O'Connor" In-Reply-To: Date: Tue, 12 Apr 2011 17:13:53 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <31E29A16-D83E-405E-8489-286FB58191D5@gsoft.com.au> References: To: George Kontostanos X-Mailer: Apple Mail (2.1084) X-Spam-Score: -1.5 () BAYES_00 X-Scanned-By: MIMEDefang 2.67 on 203.31.81.10 Cc: freebsd-current@freebsd.org Subject: Re: make release X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2011 15:14:05 -0000 On 12/04/2011, at 17:02, George Kontostanos wrote: > I am trying to make a release with the following arguments: >=20 > make release CHROOTDIR=3D/usr/home/current BUILDNAME=3D9-CURRENT > EXTSRCDIR=3D/usr/src NOPORTS=3DYES MAKE_ISOS=3DYES >=20 > however /usr/home/current is being ignored completely and everything = ends up > in /usr/obj/usr/src. Am I doing something wrong ? I found this too, I think it's "the new way". (I think the makefile still mentions CHROOTDIR though.. not sure if it = does anything with it or not though) -- 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-current@FreeBSD.ORG Tue Apr 12 15:14:30 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BB5B3106566C for ; Tue, 12 Apr 2011 15:14:30 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from argol.doit.wisc.edu (argol.doit.wisc.edu [144.92.197.212]) by mx1.freebsd.org (Postfix) with ESMTP id 8F81E8FC0A for ; Tue, 12 Apr 2011 15:14:30 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from avs-daemon.smtpauth3.wiscmail.wisc.edu by smtpauth3.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 7u2-7.05 32bit (built Jul 30 2009)) id <0LJJ0020KP05P300@smtpauth3.wiscmail.wisc.edu> for freebsd-current@freebsd.org; Tue, 12 Apr 2011 10:14:29 -0500 (CDT) Received: from comporellon.tachypleus.net ([unknown] [76.210.65.155]) by smtpauth3.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 7u2-7.05 32bit (built Jul 30 2009)) with ESMTPSA id <0LJJ000C0OZWTJ10@smtpauth3.wiscmail.wisc.edu> for freebsd-current@freebsd.org; Tue, 12 Apr 2011 10:14:23 -0500 (CDT) Date: Tue, 12 Apr 2011 10:14:20 -0500 From: Nathan Whitehorn In-reply-to: To: George Kontostanos Message-id: <4DA46C4C.6090206@freebsd.org> X-Spam-Report: AuthenticatedSender=yes, SenderIP=76.210.65.155 X-Spam-PmxInfo: Server=avs-11, Version=5.6.0.2009776, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.4.12.150616, SenderIP=76.210.65.155 References: User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.15) Gecko/20110305 Thunderbird/3.1.9 Cc: freebsd-current@freebsd.org Subject: Re: make release X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2011 15:14:30 -0000 On 04/12/11 10:02, George Kontostanos wrote: > I am trying to make a release with the following arguments: > > make release CHROOTDIR=/usr/home/current BUILDNAME=9-CURRENT > EXTSRCDIR=/usr/src NOPORTS=YES MAKE_ISOS=YES > > however /usr/home/current is being ignored completely and everything ends up > in /usr/obj/usr/src. Am I doing something wrong ? Following switching the default installer away from sysinstall, make release works differently now (see release(7), which has been updated to reflect the new release-building process). The closest analog to the command above (though you may want to do something different) is: cd /usr/src/release ./generate-release.sh head /usr/home/current -Nathan From owner-freebsd-current@FreeBSD.ORG Tue Apr 12 15:32:39 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ABC881065674 for ; Tue, 12 Apr 2011 15:32:39 +0000 (UTC) (envelope-from gkontos.mail@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 663848FC1A for ; Tue, 12 Apr 2011 15:32:39 +0000 (UTC) Received: by iwn33 with SMTP id 33so8221982iwn.13 for ; Tue, 12 Apr 2011 08:32:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=gPlLgkynDljQscJpwMCyxLCMp1y8fGoFDWzCcu5wBS8=; b=x870NhexP6d3JlL8xoB69VGwxWQdDmwu91OhrKtiZ3aL4GB5yeh+2IKXOOjl1kQquK CECdbb71RG3OCKMbNxxb7Csa9yBFURWF4lnw8L5CFB3KElUlJwuVT2AKobmBR8z6k/j3 r7zb1r4id5A1U9YIDRfdzj5fiFKSfsqGOnnXA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Ov3gAnRnpR8R6x4mBQEhbWl9xCzs6s59BstAHXGgF594v/JRxWQ+Z5ga7XbBXPUl/I UR58l61KPtha1oSbPZtX07bwwfutfn4Z28JSJqRkr/5DtL0hMn9/3XRKJHoE7uLznHTs mzwmfHBQsmx/Ro98h+0Ovbq09guOGLL9caD1g= MIME-Version: 1.0 Received: by 10.43.53.201 with SMTP id vr9mr9264114icb.456.1302622358740; Tue, 12 Apr 2011 08:32:38 -0700 (PDT) Received: by 10.231.11.196 with HTTP; Tue, 12 Apr 2011 08:32:38 -0700 (PDT) In-Reply-To: <4DA46C4C.6090206@freebsd.org> References: <4DA46C4C.6090206@freebsd.org> Date: Tue, 12 Apr 2011 18:32:38 +0300 Message-ID: From: George Kontostanos To: Nathan Whitehorn Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current@freebsd.org Subject: Re: make release X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2011 15:32:39 -0000 Sorry I didn't read the man pages lately! release Meta-target to build all release media and distributions applicable to this platform. All output goes to ${.OBJDIR}, which will likely be either src/release or the equivalent path in /usr/obj. The following sequence of commands can be used to build a ``-CURRENT snapshot'' in a clean environment, including ports and documentation: cd /usr/src make buildworld cd release export CVSUP_HOST=cvsupN.freebsd.org sh generate-release.sh head /local3/release On Tue, Apr 12, 2011 at 6:14 PM, Nathan Whitehorn wrote: > On 04/12/11 10:02, George Kontostanos wrote: > >> I am trying to make a release with the following arguments: >> >> make release CHROOTDIR=/usr/home/current BUILDNAME=9-CURRENT >> EXTSRCDIR=/usr/src NOPORTS=YES MAKE_ISOS=YES >> >> however /usr/home/current is being ignored completely and everything ends >> up >> in /usr/obj/usr/src. Am I doing something wrong ? >> > > Following switching the default installer away from sysinstall, make > release works differently now (see release(7), which has been updated to > reflect the new release-building process). The closest analog to the command > above (though you may want to do something different) is: > cd /usr/src/release > ./generate-release.sh head /usr/home/current > -Nathan > -- George Kontostanos aisecure.net From owner-freebsd-current@FreeBSD.ORG Tue Apr 12 19:32:48 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2964C106564A; Tue, 12 Apr 2011 19:32:47 +0000 (UTC) (envelope-from naylor.b.david@gmail.com) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id 3D6388FC14; Tue, 12 Apr 2011 19:32:47 +0000 (UTC) Received: by gyg13 with SMTP id 13so3169803gyg.13 for ; Tue, 12 Apr 2011 12:32:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:from:to:subject:date:user-agent:cc:references :in-reply-to:mime-version:content-type:content-transfer-encoding :message-id; bh=fc6cIvJ2hpS+f4paMaLlPvMHc7djjKGMIddT1cyO+bc=; b=MmShzWzZ0naOcBFAm85x2Xpj4yuKsp5mvQJm3dS8ZOZPXlXlQTLMxeaVC5lyWI1Bvu BKzsp21H6JU2ESL6PYEIvo5jEZS1iiPZqUUCKYXxLHqtJd5vZ3C+goJvYrNVkz9hR4ww v8jGTJxDfWp6ZM1AVQaNB2frnbkBCSD+yasKM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; b=JBSbdHDRYnvERzokLgSA469YV8T258qCgIjuY8XAaHkk53NeNLuVqNttFtRC5JWL1I owHg/LqedyMJhwPntvLM94CvCChUM7seeRR/B/1wwtF3KBLOK27JTiTYoepw3THQwGrH 9ZdJ76/f6JrOETcgGrxbRz6eq7/AbhsVIvk6w= Received: by 10.151.106.2 with SMTP id i2mr5954451ybm.397.1302636766683; Tue, 12 Apr 2011 12:32:46 -0700 (PDT) Received: from dragon.dg (41-135-148-75.dsl.mweb.co.za [41.135.148.75]) by mx.google.com with ESMTPS id x4sm3299115ybl.23.2011.04.12.12.32.41 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 12 Apr 2011 12:32:45 -0700 (PDT) From: David Naylor To: Alexander Motin Date: Tue, 12 Apr 2011 21:32:20 +0200 User-Agent: KMail/1.13.5 (FreeBSD/9.0-CURRENT; KDE/4.6.1; amd64; ; ) References: <4DA3EE8F.8050306@FreeBSD.org> In-Reply-To: <4DA3EE8F.8050306@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart3394349.yoO1nZosXY"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201104122132.23809.naylor.b.david@gmail.com> Cc: FreeBSD-Current Subject: Re: [regression] unable to boot: no GEOM devices found. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2011 19:32:48 -0000 --nextPart3394349.yoO1nZosXY Content-Type: multipart/mixed; boundary="Boundary-01=_EjKpNEGvnSpqhAB" Content-Transfer-Encoding: 7bit --Boundary-01=_EjKpNEGvnSpqhAB Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Tuesday 12 April 2011 08:17:51 Alexander Motin wrote: > David Naylor wrote: > > I am running -current and since a few days ago (at least 2011/04/11) I = am > > unable to boot. > >=20 > > The boot process stops when it looks to find a bootable device. The > > prompt (when pressing '?') does not display any device and yielding one > > second (or more) to the kernel (by pressing '.') does not improve the > > situation. > >=20 > > A known working date is 2011/02/20. > >=20 > > I am running amd64 on a nVidia MCP51 chipset. >=20 > MCP51... again... >=20 > > I am willing to help any way I can. >=20 > You could start from capturing and showing verbose dmesg. Full or at > least in parts related to disks. I captured the dmesg output for both the old (working) kernel and the new=20 (bad) kernel. See attached for the difference between the two. If you nee= d=20 the full dmesg please let me know. =20 One thing I found is that the old kernel would not boot if I simply reboote= d=20 from the bad kernel. I had to do a hard power off before the old kernel wo= uld=20 work again. Is some device state surviving between reboots? =20 Regards, David --Boundary-01=_EjKpNEGvnSpqhAB Content-Type: text/x-patch; charset="UTF-8"; name="dmesg.diff" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="dmesg.diff" =2D-- dmesg.old 2011-04-12 21:26:44.000000000 +0200 +++ dmesg.new 2011-04-12 21:24:12.000000000 +0200 @@ -16,17 +16,17 @@ APIC: Using the MADT enumerator. MADT: Found CPU APIC ID 0 ACPI ID 0: enabled SMP: Added CPU 0 (AP) =2DMADT: Found CPU APIC ID 3 ACPI ID 1: enabled =2DSMP: Added CPU 3 (AP) =2DMADT: Found CPU APIC ID 1 ACPI ID 2: enabled +MADT: Found CPU APIC ID 1 ACPI ID 1: enabled SMP: Added CPU 1 (AP) +MADT: Found CPU APIC ID 3 ACPI ID 2: enabled +SMP: Added CPU 3 (AP) MADT: Found CPU APIC ID 2 ACPI ID 3: enabled SMP: Added CPU 2 (AP) Copyright (c) 1992-2011 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 is a registered trademark of The FreeBSD Foundation. =2DFreeBSD 9.0-CURRENT #0: Mon Mar 7 17:47:26 SAST 2011 +FreeBSD 9.0-CURRENT #0: Tue Apr 12 21:09:23 SAST 2011 root@dragon.dg:/tmp/home/freebsd9/src/sys/DRAGON amd64 Table 'FACP' at 0xcfff30c0 Table 'HPET' at 0xcfff7940 @@ -35,25 +35,24 @@ Table 'SSDT' at 0xcfff7a40 Table 'SSDT' at 0xcfff7ff0 ACPI: No SRAT table found =2DPreloaded elf kernel "/boot/dragon/kernel" at 0xffffffff819ce000. =2DPreloaded elf obj module "/boot/modules/cuse4bsd.ko" at 0xffffffff819ce1= d0. =2DPreloaded elf obj module "/boot/dragon/geom_sched.ko" at 0xffffffff819ce= 7c0. =2DPreloaded elf obj module "/boot/dragon/gsched_rr.ko" at 0xffffffff819cee= 70. =2DPreloaded elf obj module "/boot/modules/nvidia.ko" at 0xffffffff819cf3e0. =2DCalibrating TSC clock ... TSC clock: 2400024582 Hz =2DCPU: Intel(R) Core(TM)2 Quad CPU @ 2.40GHz (2400.02-MHz K8-cla= ss CPU) +Preloaded elf kernel "/boot/kernel/kernel" at 0xffffffff81a01000. +Preloaded elf obj module "/boot/modules/cuse4bsd.ko" at 0xffffffff81a011d0. +Preloaded elf obj module "/boot/kernel/geom_sched.ko" at 0xffffffff81a017c= 0. +Preloaded elf obj module "/boot/kernel/gsched_rr.ko" at 0xffffffff81a01e70. +Preloaded elf obj module "/boot/modules/nvidia.ko" at 0xffffffff81a023e0. +CPU: Intel(R) Core(TM)2 Quad CPU @ 2.40GHz (K8-class CPU) Origin =3D "GenuineIntel" Id =3D 0x6f7 Family =3D 6 Model =3D f Step= ping =3D 7 Features=3D0xbfebfbff Features2=3D0xe3bd AMD Features=3D0x20100800 AMD Features2=3D0x1 =2D TSC: P-state invariant real memory =3D 6442450944 (6144 MB) Physical memory chunk(s): 0x0000000000001000 - 0x000000000009bfff, 634880 bytes (155 pages) =2D0x0000000001a01000 - 0x00000000c34d3fff, 3249352704 bytes (793299 pages) +0x0000000000100000 - 0x00000000001fffff, 1048576 bytes (256 pages) +0x0000000001a34000 - 0x00000000c34d3fff, 3249143808 bytes (793248 pages) 0x0000000100000000 - 0x00000001affeffff, 2952724480 bytes (720880 pages) =2Davail memory =3D 6161305600 (5875 MB) +avail memory =3D 6162554880 (5877 MB) Event timer "LAPIC" quality 400 ACPI APIC Table: INTR: Adding local APIC 1 as a target @@ -65,14 +64,14 @@ cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 +APIC: CPU 0 has ACPI ID 0 +APIC: CPU 1 has ACPI ID 1 +APIC: CPU 2 has ACPI ID 3 +APIC: CPU 3 has ACPI ID 2 x86bios: IVT 0x000000-0x0004ff at 0xfffffe0000000000 x86bios: SSEG 0x001000-0x001fff at 0xffffff800002a000 x86bios: EBDA 0x09f000-0x09ffff at 0xfffffe000009f000 x86bios: ROM 0x0a0000-0x0fefff at 0xfffffe00000a0000 =2DAPIC: CPU 0 has ACPI ID 0 =2DAPIC: CPU 1 has ACPI ID 2 =2DAPIC: CPU 2 has ACPI ID 3 =2DAPIC: CPU 3 has ACPI ID 1 ULE: setup cpu 0 ULE: setup cpu 1 ULE: setup cpu 2 @@ -99,12 +98,12 @@ lapic0: Routing NMI -> LINT1 lapic0: LINT1 trigger: edge lapic0: LINT1 polarity: high =2Dlapic3: Routing NMI -> LINT1 =2Dlapic3: LINT1 trigger: edge =2Dlapic3: LINT1 polarity: high lapic1: Routing NMI -> LINT1 lapic1: LINT1 trigger: edge lapic1: LINT1 polarity: high +lapic3: Routing NMI -> LINT1 +lapic3: LINT1 trigger: edge +lapic3: LINT1 polarity: high lapic2: Routing NMI -> LINT1 lapic2: LINT1 trigger: edge lapic2: LINT1 polarity: high @@ -114,10 +113,9 @@ lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000100ef therm: 0x00010000 err: 0x000000f0 pmc: 0x00010400 Cuse4BSD v0.1.13 @ /dev/cuse =2Dwlan: <802.11 Link Layer> snd_unit_init() u=3D0x00ff8000 [512] d=3D0x00007c00 [32] c=3D0x000003ff [1= 024] feeder_register: snd_unit=3D-1 snd_maxautovchans=3D16 latency=3D5 feeder_r= ate_min=3D1 feeder_rate_max=3D2016000 feeder_rate_round=3D25 =2Dnull: +wlan: <802.11 Link Layer> random: kbd: new array size 4 kbd1 at kbdmux0 @@ -161,6 +159,7 @@ VESA: NVIDIA VESA: NVIDIA Corporation G73 Board - p345h0 Chip Rev =20 io: +null: GEOM_SCHED: Modevent 0. GEOM_SCHED: Initializing global data. GEOM_SCHED: Loaded module rr error 0. @@ -452,6 +451,7 @@ lattimer=3D0x00 (0 ns), mingnt=3D0x08 (2000 ns), maxlat=3D0x00 (0 = ns) powerspec 2 supports D0 D3 current D0 MSI supports 2 messages, 64 bit +pcib0: Enabling MSI window for HyperTransport slave at pci0:0:9:0 found-> vendor=3D0x10de, dev=3D0x0270, revid=3D0xa2 domain=3D0, bus=3D0, slot=3D9, func=3D0 class=3D05-00-00, hdrtype=3D0x00, mfdev=3D0 @@ -490,13 +490,13 @@ pcib0: matched entry for 0.11.INTA (src \_SB_.PCI0.APCF:0) pci_link28: Picked IRQ 21 with weight 0 pcib0: slot 11 INTA routed to irq 21 via \_SB_.PCI0.APCF =2D found-> vendor=3D0x10de, dev=3D0x026e, revid=3D0xa3 domain=3D0, bus=3D0, slot=3D11, func=3D1 class=3D0c-03-20, hdrtype=3D0x00, mfdev=3D1 cmdreg=3D0x0006, statreg=3D0x00b0, cachelnsz=3D0 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x03 (750 ns), maxlat=3D0x01 (250= ns) intpin=3Db, irq=3D10 + powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type Memory, range 32, base 0xe7006000, size 8, enabled pcib0: matched entry for 0.11.INTB (src \_SB_.PCI0.APCL:0) @@ -616,14 +616,14 @@ ioapic0: routing intpin 21 (PCI IRQ 21) to lapic 0 vector 50 usbus0: on ohci0 usbus0: bpf attached =2Dohci0: usbpf attached +ohci0: usbpf: Attached ehci0: mem 0xe7006000-0xe70060ff irq 2= 2 at device 11.1 on pci0 ioapic0: routing intpin 22 (PCI IRQ 22) to lapic 0 vector 51 ehci0: Doorbell workaround enabled usbus1: EHCI version 1.0 usbus1: on ehci0 usbus1: bpf attached =2Dehci0: usbpf attached +ehci0: usbpf: Attached atapci0: port 0x1f0-0x1f7,0x3f6,0= x170-0x177,0x376,0xf000-0xf00f at device 13.0 on pci0 ata0: on atapci0 ata0: reset tp1 mask=3D03 ostat0=3D50 ostat1=3D50 @@ -737,7 +737,7 @@ psm0: model IntelliMouse, device ID 3-00, 3 buttons psm0: config:00000000, flags:00000008, packet size:4 psm0: syncmask:08, syncbits:00 =2Dacpi0: wakeup code va 0xffffff81b14cd000 pa 0x4000 +acpi0: wakeup code va 0xffffff81a4d89000 pa 0x4000 isa_probe_children: disabling PnP devices atkbdc: atkbdc0 already exists; skipping it atrtc: atrtc0 already exists; skipping it @@ -777,8 +777,7 @@ Device configuration finished. linprocfs registered procfs registered =2DTimecounter "TSC" frequency 2400024582 Hz quality -100 =2Dlapic: Divisor 2, Frequency 133334705 Hz +lapic: Divisor 2, Frequency 133332449 Hz Timecounters tick every 10.000 msec vlan: initialized, using hash tables with chaining Linux ELF exec handler installed @@ -791,24 +790,71 @@ uhub0: on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 =2Data0-slave: pio=3DPIO4 wdma=3DWDMA2 udma=3DUDMA33 cable=3D40 wire =2D: ata0-master: pio=3DPIO4 wdma=3DWDMA2 udma=3DUDMA66 cable=3D40 wire +: Loading: mp =3D 0xffffffff80c4f0c0, g_sched_class =3D 0xffffffff80c4f0c0. +uhub0: 8 ports with 8 removable, self powered +ata0: reiniting channel .. +ata0: reset tp1 mask=3D03 ostat0=3D10 ostat1=3D58 +ata0: stat0=3D0x10 err=3D0x01 lsb=3D0x14 msb=3D0xeb +ata0: stat1=3D0x00 err=3D0x01 lsb=3D0x14 msb=3D0xeb +ata0: reset tp2 stat0=3D10 stat1=3D00 devices=3D0x30000 +ata0: reinit done .. +unknown: FAILURE - ATAPI_IDENTIFY timed out LBA=3D0 +ata0: reiniting channel .. +ata0: reset tp1 mask=3D03 ostat0=3D10 ostat1=3D58 +ata0: stat0=3D0x10 err=3D0x01 lsb=3D0x14 msb=3D0xeb +ata0: stat1=3D0x00 err=3D0x01 lsb=3D0x14 msb=3D0xeb +ata0: reset tp2 stat0=3D10 stat1=3D00 devices=3D0x30000 +ata0: reinit done .. +unknown: FAILURE - ATAPI_IDENTIFY timed out LBA=3D0 +ata0: reiniting channel .. +ata0: reset tp1 mask=3D03 ostat0=3D58 ostat1=3D00 +ata0: stat0=3D0x10 err=3D0x01 lsb=3D0x14 msb=3D0xeb +ata0: stat1=3D0x00 err=3D0x01 lsb=3D0x14 msb=3D0xeb +ata0: reset tp2 stat0=3D10 stat1=3D00 devices=3D0x30000 +ata0: reinit done .. +unknown: FAILURE - ATAPI_IDENTIFY timed out LBA=3D0 +uhub1: 8 ports with 8 removable, self powered +ata0: reiniting channel .. +ata0: reset tp1 mask=3D03 ostat0=3D58 ostat1=3D00 +ata0: stat0=3D0x10 err=3D0x01 lsb=3D0x14 msb=3D0xeb +ata0: stat1=3D0x00 err=3D0x01 lsb=3D0x14 msb=3D0xeb +ata0: reset tp2 stat0=3D10 stat1=3D00 devices=3D0x30000 +ata0: reinit done .. +unknown: FAILURE - ATAPI_IDENTIFY timed out LBA=3D0 ata1: Identifying devices: 00000000 ata1: New devices: 00000000 ata2: Identifying devices: 00000001 ata2: New devices: 00000001 =2DLoading: mp =3D 0xffffffff80c1be60, g_sched_class =3D 0xffffffff80c1be60= =2Eata2-master: pio=3DPIO4 wdma=3DWDMA2 udma=3DUDMA133 cable=3D40 wire =2D =2Dad4: setting UDMA100 =2Dad4: 305244MB at ata2-master UDMA100 SATA 1.= 5Gb/s =2Dad4: 625140335 sectors [620178C/16H/63S] 16 sectors/interrupt 1 depth qu= eue +ata2: reiniting channel .. +ata2: SATA connect time=3D0ms status=3D00000113 +ata2: reset tp1 mask=3D01 ostat0=3D58 ostat1=3D00 +ata2: stat0=3D0x50 err=3D0x01 lsb=3D0x00 msb=3D0x00 +ata2: reset tp2 stat0=3D50 stat1=3D00 devices=3D0x1 +ata2: reinit done .. +unknown: FAILURE - ATA_IDENTIFY timed out LBA=3D0 +ata2: reiniting channel .. +ata2: SATA connect time=3D0ms status=3D00000113 +ata2: reset tp1 mask=3D01 ostat0=3D58 ostat1=3D00 +ata2: stat0=3D0x50 err=3D0x01 lsb=3D0x00 msb=3D0x00 +ata2: reset tp2 stat0=3D50 stat1=3D00 devices=3D0x1 +ata2: reinit done .. +unknown: FAILURE - ATA_IDENTIFY timed out LBA=3D0 ata3: Identifying devices: 00000001 ata3: New devices: 00000001 =2DGEOM: new disk ad4 =2Data3-master: pio=3DPIO4 wdma=3DWDMA2 udma=3DUDMA133 cable=3D40 wire =2Dad6: setting UDMA100 =2Dad6: 476938MB at ata3-master UDMA100 SATA 1.5= Gb/s =2Dad6: 976771055 sectors [969018C/16H/63S] 16 sectors/interrupt 1 depth qu= eue +ata3: reiniting channel .. +ata3: SATA connect time=3D0ms status=3D00000113 +ata3: reset tp1 mask=3D01 ostat0=3D58 ostat1=3D00 +ata3: stat0=3D0x50 err=3D0x01 lsb=3D0x00 msb=3D0x00 +ata3: reset tp2 stat0=3D50 stat1=3D00 devices=3D0x1 +ata3: reinit done .. +unknown: FAILURE - ATA_IDENTIFY timed out LBA=3D0 +ata3: reiniting channel .. +ata3: SATA connect time=3D0ms status=3D00000113 +ata3: reset tp1 mask=3D01 ostat0=3D58 ostat1=3D00 +ata3: stat0=3D0x50 err=3D0x01 lsb=3D0x00 msb=3D0x00 +ata3: reset tp2 stat0=3D50 stat1=3D00 devices=3D0x1 +ata3: reinit done .. +unknown: FAILURE - ATA_IDENTIFY timed out LBA=3D0 hdac0: Probing codec #0... hdac0: HDA Codec #0: Realtek ALC888 hdac0: HDA Codec ID: 0x10ec0888 @@ -918,6 +964,7 @@ hdac0: Widget cap: 0x00000011 hdac0: STEREO hdac0: Association: 0 (0x00000001) + hdac0: OSS: pcm (pcm) hdac0: Stream cap: 0x00000001 hdac0: PCM @@ -957,7 +1004,6 @@ hdac0: PCM cap: 0x000e0560 hdac0: 16 20 24 bits, 44 48 96 192 KHz hdac0:=20 =2D hdac0: nid: 6 hdac0: Name: audio output hdac0: Widget cap: 0x00000211 @@ -1419,6 +1465,7 @@ pcm0: PCM pcm0: PCM cap: 0x000e0560 pcm0: 16 20 24 bits, 44 48 96 192 KHz + pcm0: DAC: 2 3 4 5 pcm0:=20 pcm0: Record: @@ -1458,7 +1505,6 @@ pcm0:=20 pcm0: nid=3D23 [pin: Line-out (Grey Jack)] pcm0: | =2D pcm0: + <- nid=3D15 [audio mixer] [src: pcm, mix] pcm0: | pcm0: + <- nid=3D5 [audio output] [src: pcm] @@ -1575,8 +1621,8 @@ pcm0: Mixer "igain": pcm0: Soft PCM mixer ENABLED pcm0: clone manager: deadline=3D750ms flags=3D0x8000001e =2Dpcm0: sndbuf_setmap 49e0000, 4000; 0xffffff81b14db000 -> 49e0000 =2Dpcm0: sndbuf_setmap 49f0000, 4000; 0xffffff81b14eb000 -> 49f0000 +pcm0: sndbuf_setmap 1aff90000, 4000; 0xffffff81a4d97000 -> 1aff90000 +pcm0: sndbuf_setmap 1affa0000, 4000; 0xffffff81a4da7000 -> 1affa0000 pcm1: at cad 0 nid 1 on hdac0 pcm1: +--------------------------------------+ pcm1: | DUMPING PCM Playback/Record Channels | @@ -1668,8 +1714,8 @@ pcm1: Mixer "monitor": pcm1: Soft PCM mixer ENABLED pcm1: clone manager: deadline=3D750ms flags=3D0x8000001e =2Dpcm1: sndbuf_setmap 4b10000, 4000; 0xffffff81b14fb000 -> 4b10000 =2Dpcm1: sndbuf_setmap 4b20000, 4000; 0xffffff81b150b000 -> 4b20000 +pcm1: sndbuf_setmap 1affb0000, 4000; 0xffffff81a4db7000 -> 1affb0000 +pcm1: sndbuf_setmap 49f0000, 4000; 0xffffff81a4dc7000 -> 49f0000 pcm2: at cad 0 nid 1 on hdac0 pcm2: +--------------------------------------+ pcm2: | DUMPING PCM Playback/Record Channels | @@ -1717,18 +1763,18 @@ pcm2: Mixer "pcm": parent=3D"vol" pcm2: Soft PCM mixer ENABLED pcm2: clone manager: deadline=3D750ms flags=3D0x8000001e =2Dpcm2: sndbuf_setmap 4b30000, 4000; 0xffffff81b151b000 -> 4b30000 =2Dpcm2: sndbuf_setmap 4b50000, 4000; 0xffffff81b152b000 -> 4b50000 =2DSMP: AP CPU #2 Launched! =2Dcpu2 AP: =2D ID: 0x02000000 VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff =2D lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff =2D timer: 0x000100ef therm: 0x00010000 err: 0x000000f0 pmc: 0x00010400 +pcm2: sndbuf_setmap 47c0000, 4000; 0xffffff81a4dd7000 -> 47c0000 +pcm2: sndbuf_setmap 47d0000, 4000; 0xffffff81a4de7000 -> 47d0000 SMP: AP CPU #3 Launched! cpu3 AP: ID: 0x03000000 VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000100ef therm: 0x00010000 err: 0x000000f0 pmc: 0x00010400 +SMP: AP CPU #2 Launched! +cpu2 AP: + ID: 0x02000000 VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff + lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff + timer: 0x000100ef therm: 0x00010000 err: 0x000000f0 pmc: 0x00010400 SMP: AP CPU #1 Launched! cpu1 AP: ID: 0x01000000 VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff @@ -1742,114 +1788,29 @@ nioapic0: routing intpin 16 (ePCI IRQ 16r) to lapic 3 vector 49 ioapic0: routing intpin 20 (sPCI IRQ 20t) to lapic 1 vector 50 aioapic0: routing intpin 21 (rPCI IRQ 21t) to lapic 2 vector 50 =2Deioapic0: routing intpin 22 (dPCI IRQ 22 =2D) to lapic 3 vector 50 =2Dunknown: FAILURE - INQUIRY ILLEGAL REQUEST asc=3D0x24 ascq=3D0x00=20 =2D(probe0:ata0:0:0:unknown: 0): FAILURE - INQUIRY ILLEGAL REQUEST asc=3D0x= 24 ascq=3D0x00 uhub0: sks=3D0x48 0x00 0x01 =2D8 ports with 8 removable, self powered =2DSCSI status error =2DGEOM: new disk ad6 =2D(probe0:ata0:0:0:0): INQUIRY. CDB: 12 1 0 0 ff 0=20 =2D(probe0:ata0:0:0:0): CAM status: SCSI Status Error =2D(probe0:ata0:0:0:0): SCSI status: Check Condition =2D(probe0:ata0:0:0:0): SCSI sense: ILLEGAL REQUEST asc:24,0 (Invalid field= in CDB) =2D(probe0:ata0:0:0:0): Error 22, Unretryable error =2D(probe0:ata0:0:0:0): Down reving Protocol Version from 2 to 0? =2D(probe1:GEOM: ad4s1: geometry does not match label (255h,63s !=3D 16h,63= s). =2Data0:0:GEOM: ad4s1: media size does not match label. =2D1:0): SCSI status error =2D(probe1:ata0:0:1:0): INQUIRY. CDB: 12 1 0 0 ff 0=20 =2D(probe1:ata0:0:1:0): CAM status: SCSI Status Error =2D(probe1:ata0:0:1:0): SCSI status: Check Condition =2D(probe1:ata0:0:1:0): SCSI sense: ILLEGAL REQUEST asc:24,0 (Invalid field= in CDB): Command byte 1 bit 0 is invalid =2D(probe1:ata0:0:1:0): Error 22, Unretryable error =2D(probe1:ata0:0:1:0): Down reving Protocol Version from 2 to 0? =2DGEOM: ad6s1: geometry does not match label (255h,63s !=3D 16h,63s). =2DGEOM: ad6s1: media size does not match label. =2DGEOM_MIRROR: Device mirror/gm0 launched (2/2). =2DRoot mount waiting for: usbus1 =2D(probe0:ata0:0:0:0): SCSI status error =2D(probe0:ata0:0:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0=20 =2D(probe0:ata0:0:0:0): CAM status: SCSI Status Error =2D(probe0:ata0:0:0:0): SCSI status: Check Condition =2D(probe0:ata0:0:0:0): SCSI sense: NOT READY asc:3a,1 (Medium not present = =2D tray closed) =2D(probe0:ata0:0:0:0): Error 6, Unretryable error =2DGEOM: new disk cd0 =2Dpass0 at ata0 bus 0 scbus0 target 0 lun 0 =2Dpass0: Removable CD-ROM SCSI-0 device=20 =2Dpass0: 3.300MB/s transfers =2Duhub1: 8 ports with 8 removable, self powered =2D(probe1:ata0:0:1:0): SCSI status error =2D(probe1:ata0:0:1:0): TEST UNIT READY. CDB: 0 0 0 0 0 0=20 =2D(probe1:ata0:0:1:0): CAM status: SCSI Status Error =2D(probe1:ata0:0:1:0): SCSI status: Check Condition =2D(probe1:ata0:0:1:0): SCSI sense: UNIT ATTENTION asc:29,0 (Power on, rese= t, or bus device reset occurred) =2D(probe1:ata0:0:1:0): Retrying command (per sense data) =2D(cd0:ata0:0:0:0): SCSI status error =2D(cd0:ata0:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0=20 =2D(cd0:ata0:0:0:0): CAM status: SCSI Status Error =2D(cd0:ata0:0:0:0): SCSI status: Check Condition =2D(cd0:ata0:0:0:0): SCSI sense: NOT READY asc:3a,1 (Medium not present - t= ray closed) =2D(cd0:ata0:0:0:0): Error 6, Unretryable error =2Dcd0 at ata0 bus 0 scbus0 target 0 lun 0 =2Dcd0: Removable CD-ROM SCSI-0 device=20 =2Dcd0: 3.300MB/s transfers =2Dcd0: Attempt to query device size failed: NOT READY, Medium not present = =2D tray closed =2D(probe1:ata0:0:1:0): SCSI status error =2D(probe1:ata0:0:1:0): TEST UNIT READY. CDB: 0 0 0 0 0 0=20 =2D(probe1:ata0:0:1:0): CAM status: SCSI Status Error =2D(probe1:ata0:0:1:0): SCSI status: Check Condition =2D(probe1:ata0:0:1:0): SCSI sense: NOT READY asc:3a,0 (Medium not present) =2D(probe1:ata0:0:1:0): Error 6, Unretryable error =2Dpass1 at ata0 bus 0 scbus0 target 1 lun 0 =2Dpass1: Removable CD-ROM SCSI-0 device=20 =2Dpass1: 3.300MB/s transfers =2D(cd1:ata0:0:1:0): SCSI status error =2D(cd1:ata0:0:1:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0=20 =2D(cd1:ata0:0:1:0): CAM status: SCSI Status Error =2D(cd1:ata0:0:1:0): SCSI status: Check Condition =2D(cd1:ata0:0:1:0): SCSI sense: NOT READY asc:3a,0 (Medium not present) =2D(cd1:ata0:0:1:0): Error 6, Unretryable error =2Dcd1 at ata0 bus 0 scbus0 target 1 lun 0 =2Dcd1: Removable CD-ROM SCSI-0 device=20 =2Dcd1: 3.300MB/s transfers =2Dcd1: Attempt to query device size failed: NOT READY, Medium not present =2D(cd0:ata0:0:0:0): SCSI status error =2D(cd0:ata0:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0=20 =2D(cd0:ata0:0:0:0): CAM status: SCSI Status Error =2D(cd0:ata0:0:0:0): SCSI status: Check Condition =2D(cd0:ata0:0:0:0): SCSI sense: NOT READY asc:3a,1 (Medium not present - t= ray closed) =2D(cd0:ata0:0:0:0): Error 6, Unretryable error =2D(cd0:ata0:0:0:0): SCSI status error =2D(cd0:ata0:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0=20 =2D(cd0:ata0:0:0:0): CAM status: SCSI Status Error =2D(cd0:ata0:0:0:0): SCSI status: Check Condition =2D(cd0:ata0:0:0:0): SCSI sense: NOT READY asc:3a,1 (Medium not present - t= ray closed) =2D(cd0:ata0:0:0:0): Error 6, Unretryable error =2D(cd0:ata0:0:0:0): SCSI status error =2D(cd0:ata0:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0=20 =2D(cd0:ata0:0:0:0): CAM status: SCSI Status Error =2D(cd0:ata0:0:0:0): SCSI status: Check Condition =2D(cd0:ata0:0:0:0): SCSI sense: NOT READY asc:3a,1 (Medium not present - t= ray closed) =2D(cd0:ata0:0:0:0): Error 6, Unretryable error =2DGEOM: new disk cd1 =2D(cd1:ata0:0:1:0): SCSI status error =2D(cd1:ata0:0:1:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0=20 =2D(cd1:ata0:0:1:0): CAM status: SCSI Status Error =2D(cd1:ata0:0:1:0): SCSI status: Check Condition =2D(cd1:ata0:0:1:0): SCSI sense: NOT READY asc:3a,0 (Medium not present) =2D(cd1:ata0:0:1:0): Error 6, Unretryable error =2D(cd1:ata0:0:1:0): SCSI status error =2D(cd1:ata0:0:1:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0=20 =2D(cd1:ata0:0:1:0): CAM status: SCSI Status Error =2D(cd1:ata0:0:1:0): SCSI status: Check Condition =2D(cd1:ata0:0:1:0): SCSI sense: NOT READY asc:3a,0 (Medium not present) =2D(cd1:ata0:0:1:0): Error 6, Unretryable error =2D(cd1:ata0:0:1:0): SCSI status error =2D(cd1:ata0:0:1:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0=20 =2D(cd1:ata0:0:1:0): CAM status: SCSI Status Error =2D(cd1:ata0:0:1:0): SCSI status: Check Condition =2D(cd1:ata0:0:1:0): SCSI sense: NOT READY asc:3a,0 (Medium not present) =2D(cd1:ata0:0:1:0): Error 6, Unretryable error +) to lap: routing intpin 22 (dPCI IRQ 22 + ic 3 vector 50 Trying to mount root from ufs:/dev/mirror/gm0a [rw]... =2Dstart_init: trying /sbin/init +mountroot: waiting for device /dev/mirror/gm0a ... +Mounting from ufs:/dev/mirror/gm0a failed with error 19. + +Loader variables: + vfs.root.mountfrom=3Dufs:/dev/mirror/gm0a + vfs.root.mountfrom.options=3Drw + +Manual root filesystem specification: + : [options] + Mount using filesystem + and with the specified (optional) option list. + + eg. ufs:/dev/da0s1a + zfs:tank + cd9660:/dev/acd0 ro + (which is equivalent to: mount -t cd9660 -o ro /dev/acd0 /) + + ? List valid disk boot devices + . Yield 1 second (for background tasks) + Abort manual input + +mountroot>=20 + --Boundary-01=_EjKpNEGvnSpqhAB-- --nextPart3394349.yoO1nZosXY Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (FreeBSD) iEYEABECAAYFAk2kqMcACgkQUaaFgP9pFrKQ4gCeNAlV3aF7JDzpGCKfk7VD6Gk6 SMUAnjXkXwdhwRnwF0+27RawwgCOYUSG =FMDh -----END PGP SIGNATURE----- --nextPart3394349.yoO1nZosXY-- From owner-freebsd-current@FreeBSD.ORG Tue Apr 12 20:13:12 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E03AD106566C; Tue, 12 Apr 2011 20:13:11 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 477658FC08; Tue, 12 Apr 2011 20:13:10 +0000 (UTC) Received: by fxm11 with SMTP id 11so16831fxm.13 for ; Tue, 12 Apr 2011 13:13:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=KaKSfzWM0TctN0LmMQXqabTUHgBNTuzEEAdP1gz9OKE=; b=Txvsi+CVUhD2rnxTHXD4bSQG5L6zG6zTORre7KO0gwoyrv1sRKWr9zlZwMG5Ohw/4M Faa+obCZtc14nCtifaAc+4BOTnOtpaygrdOE7fO/h0nBxQGq4XtetLhP9KrkyuSJ7GqA fs+eTJ9Mg0PTsPj3FzmEBfIQY4fTLL22k2B6I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=n74J4BLgE3vO2ZfT7vurvQiZGnLTPfPOXKCuGRTOIWV0gdVrAlLg9/wX09MxIKjyfM rM8KAgRxX4GoubkW+NIzUInrlb2/3LBY3erc7yEeFr97LOaT9bWaStnXgLBwjzHUnaWi xhlOiBJt18h247qIOR8dq5ECBx5cpQLQIuJj0= Received: by 10.223.159.14 with SMTP id h14mr816577fax.20.1302639190103; Tue, 12 Apr 2011 13:13:10 -0700 (PDT) Received: from mavbook2.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id k5sm2105603faa.39.2011.04.12.13.13.08 (version=SSLv3 cipher=OTHER); Tue, 12 Apr 2011 13:13:09 -0700 (PDT) Sender: Alexander Motin Message-ID: <4DA4B247.6010901@FreeBSD.org> Date: Tue, 12 Apr 2011 23:12:55 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: David Naylor References: <4DA3EE8F.8050306@FreeBSD.org> <201104122132.23809.naylor.b.david@gmail.com> In-Reply-To: <201104122132.23809.naylor.b.david@gmail.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit Cc: FreeBSD-Current Subject: Re: [regression] unable to boot: no GEOM devices found. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2011 20:13:12 -0000 David Naylor wrote: > On Tuesday 12 April 2011 08:17:51 Alexander Motin wrote: >> David Naylor wrote: >>> I am running -current and since a few days ago (at least 2011/04/11) I am >>> unable to boot. >>> >>> The boot process stops when it looks to find a bootable device. The >>> prompt (when pressing '?') does not display any device and yielding one >>> second (or more) to the kernel (by pressing '.') does not improve the >>> situation. >>> >>> A known working date is 2011/02/20. >>> >>> I am running amd64 on a nVidia MCP51 chipset. >> MCP51... again... >> >>> I am willing to help any way I can. >> You could start from capturing and showing verbose dmesg. Full or at >> least in parts related to disks. > > I captured the dmesg output for both the old (working) kernel and the new > (bad) kernel. See attached for the difference between the two. If you need > the full dmesg please let me know. > > One thing I found is that the old kernel would not boot if I simply rebooted > from the bad kernel. I had to do a hard power off before the old kernel would > work again. Is some device state surviving between reboots? +ata2: reiniting channel .. +ata2: SATA connect time=0ms status=00000113 +ata2: reset tp1 mask=01 ostat0=58 ostat1=00 +ata2: stat0=0x50 err=0x01 lsb=0x00 msb=0x00 +ata2: reset tp2 stat0=50 stat1=00 devices=0x1 +ata2: reinit done .. +unknown: FAILURE - ATA_IDENTIFY timed out LBA=0 As soon as all devices detected but not responding to commands, I would suppose that there is something wrong with ATA interrupts. There is a long chain of interrupt problems in this chipset. I have already tried to debug one case where ATA wasn't generating interrupts at all. Unfortunately, without success -- requests were executing, but not generating interrupts, it wasn't looked like ATA driver problem. What's about possible candidate to revision triggering your problem, I would look on this message: +pcib0: Enabling MSI window for HyperTransport slave at pci0:0:9:0 At least it is recent (SVN revs 219737,219740 on 2011-03-18 by jhb) and it is interrupt related. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Tue Apr 12 20:51:59 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id B76D9106566C; Tue, 12 Apr 2011 20:51:59 +0000 (UTC) Date: Tue, 12 Apr 2011 20:51:59 +0000 From: Alexander Best To: "Kenneth D. Merry" Message-ID: <20110412205159.GA49821@freebsd.org> References: <20110331223339.GA13682@freebsd.org> <201104010843.47367.jhb@freebsd.org> <20110404204316.GA11367@freebsd.org> <4D9D9917.3030102@FreeBSD.org> <20110411153857.GA63246@nargothrond.kdm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110411153857.GA63246@nargothrond.kdm.org> Cc: freebsd-scsi@freebsd.org, Alexander Motin , freebsd-current@freebsd.org Subject: Re: multiple issues with devstat_*(9) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2011 20:51:59 -0000 On Mon Apr 11 11, Kenneth D. Merry wrote: > On Thu, Apr 07, 2011 at 13:59:35 +0300, Alexander Motin wrote: > > Alexander Best wrote: > > > On Fri Apr 1 11, John Baldwin wrote: > > >> On Thursday, March 31, 2011 6:33:39 pm Alexander Best wrote: > > >>> i think there are multiple issues with devstat. i found the following in > > >>> devicestat.h: > > > > ... > > > > >>> funny thing is i found the following in scsi_pass.c: > > >>> > > >>> softc->device_stats = devstat_new_entry("pass", > > >>> periph->unit_number, 0, > > >>> DEVSTAT_NO_BLOCKSIZE > > >>> | (no_tags ? DEVSTAT_NO_ORDERED_TAGS : 0), > > >>> softc->pd_type | > > >>> DEVSTAT_TYPE_IF_SCSI | > > >>> DEVSTAT_TYPE_PASS, > > >>> DEVSTAT_PRIORITY_PASS); > > >>> > > >>> ...so pass* *should* show up under iostat -t scsi. > > > > As I can see, this is a bug (or feature) of the libdevstat / > > devstat_selectdevs(). If you specify any -t, then pass devices will be > > reported only if you request "pass" specifically. > > > > >> Hmm, pass devices for adaX should not be SCSI though, they should be ide I > > >> think. > > > > > > i think the situation with ATA_CAM should be discussed further. still besides > > > this issue there are many more with devstat(3). > > > > > > i'll try to track all the "devstat_new_entry()" occurrences and see if some > > > issues can be fixed. maybe only the proper DEVSTAT_* args were forgotten. > > > > Assuming that SCSI and IDE in -t option means transport type, and > > assuming that we count everything except ATA and SATA as SCSI, I've made > > following patch, that should fix issues from the CAM side: > > http://people.freebsd.org/~mav/cam.devstat.patch i just tried again with ATA_CAM and the patch works perfectly. iostat -t scsi doesn't show any devices and iostat -t ide shows all my ata/sata devices in addition to pass* under iostat -t pass and md* under iostat -t other. +1 for committing it. :) cheers. alex > > > > Any objections? Or SCSI/IDE there expected to mean command set? > > For what it's worth, I think the above patch is the right approach. The > device type stuff in devstat has been broken since GEOM went in, so I'm > glad to see you step up to fix it! > > Ken > -- > Kenneth Merry > ken@FreeBSD.ORG -- a13x From owner-freebsd-current@FreeBSD.ORG Tue Apr 12 21:09:14 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 31AE9106568E for ; Tue, 12 Apr 2011 21:09:14 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id AF2388FC1D for ; Tue, 12 Apr 2011 21:09:13 +0000 (UTC) Received: by fxm11 with SMTP id 11so60854fxm.13 for ; Tue, 12 Apr 2011 14:09:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=oSK5SGThSGLAWvkh3XxqqJCcPj4Tr0z+FFa4xhFwlcU=; b=lnkOL32DklqP+SI4bLMzJG1nRim6x2mLsYquLS2SNrPWi5EwN5HYI8pzguhPFqAP0n CY+oDjiPTWULVFBw7q6/Q/DWefkRF7/d/gqhQPNb3c4w+JUdK67CDiS0tkkwcMoAxJdm RD8E4685lQINc6CMXVXHy3A6tXYm11p02/hPM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=oGZc0T/jdYznTQ5AxlD50I6E8c9Ye8YzUA+FkuJRdhPNSmwiAh9rGl+r/6PSGAcxEL H+QDJ9t8Rc/wSnpyxIWDT65YZFZT0VIPRV+zA5MxBmrI8Ot0vQMXTWDPFoEV/ww34Bjy CKop4e3DD/DA9qAFGYsSnUY2/SSvsakG4tP3w= Received: by 10.223.83.130 with SMTP id f2mr1772503fal.80.1302642552777; Tue, 12 Apr 2011 14:09:12 -0700 (PDT) Received: from mavbook2.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id k5sm2116714faa.39.2011.04.12.14.09.11 (version=SSLv3 cipher=OTHER); Tue, 12 Apr 2011 14:09:12 -0700 (PDT) Sender: Alexander Motin Message-ID: <4DA4BF6A.7010806@FreeBSD.org> Date: Wed, 13 Apr 2011 00:08:58 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: pyunyh@gmail.com References: <4DA3EE8F.8050306@FreeBSD.org> <201104122132.23809.naylor.b.david@gmail.com> <4DA4B247.6010901@FreeBSD.org> <20110412210354.GC1421@michelle.cdnetworks.com> In-Reply-To: <20110412210354.GC1421@michelle.cdnetworks.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD-Current , David Naylor Subject: Re: [regression] unable to boot: no GEOM devices found. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2011 21:09:14 -0000 YongHyeon PYUN wrote: > On Tue, Apr 12, 2011 at 11:12:55PM +0300, Alexander Motin wrote: >> David Naylor wrote: >>> On Tuesday 12 April 2011 08:17:51 Alexander Motin wrote: >>>> David Naylor wrote: >>>>> I am running -current and since a few days ago (at least 2011/04/11) I am >>>>> unable to boot. >>>>> >>>>> The boot process stops when it looks to find a bootable device. The >>>>> prompt (when pressing '?') does not display any device and yielding one >>>>> second (or more) to the kernel (by pressing '.') does not improve the >>>>> situation. >>>>> >>>>> A known working date is 2011/02/20. >>>>> >>>>> I am running amd64 on a nVidia MCP51 chipset. >>>> MCP51... again... >>>> >>>>> I am willing to help any way I can. >>>> You could start from capturing and showing verbose dmesg. Full or at >>>> least in parts related to disks. >>> I captured the dmesg output for both the old (working) kernel and the new >>> (bad) kernel. See attached for the difference between the two. If you need >>> the full dmesg please let me know. >>> >>> One thing I found is that the old kernel would not boot if I simply rebooted >>> from the bad kernel. I had to do a hard power off before the old kernel would >>> work again. Is some device state surviving between reboots? >> +ata2: reiniting channel .. >> +ata2: SATA connect time=0ms status=00000113 >> +ata2: reset tp1 mask=01 ostat0=58 ostat1=00 >> +ata2: stat0=0x50 err=0x01 lsb=0x00 msb=0x00 >> +ata2: reset tp2 stat0=50 stat1=00 devices=0x1 >> +ata2: reinit done .. >> +unknown: FAILURE - ATA_IDENTIFY timed out LBA=0 >> >> As soon as all devices detected but not responding to commands, I would >> suppose that there is something wrong with ATA interrupts. There is a >> long chain of interrupt problems in this chipset. I have already tried >> to debug one case where ATA wasn't generating interrupts at all. >> Unfortunately, without success -- requests were executing, but not >> generating interrupts, it wasn't looked like ATA driver problem. >> >> What's about possible candidate to revision triggering your problem, I >> would look on this message: >> +pcib0: Enabling MSI window for HyperTransport slave at pci0:0:9:0 >> >> At least it is recent (SVN revs 219737,219740 on 2011-03-18 by jhb) and >> it is interrupt related. > > Does the driver disable MSI for MCP51? ata(4) doesn't uses MSI by default and I doubt this controller supports them any way. But if I am not mixing something, there were very strange situations with MSI on that chipset, when enabling them one one device caused interrupt problems on another. > I think jhb's patch fixed one MSI issue of all MCP chipset. I am not telling it is wrong. It could just trigger something. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Tue Apr 12 21:34:09 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DF07E106564A for ; Tue, 12 Apr 2011 21:34:08 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 9A0258FC0A for ; Tue, 12 Apr 2011 21:34:08 +0000 (UTC) Received: by iyj12 with SMTP id 12so8655346iyj.13 for ; Tue, 12 Apr 2011 14:34:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:from:date:to:cc:subject:message-id:reply-to :references:mime-version:content-type:content-disposition :in-reply-to:user-agent; bh=j/gog2zCbGBBbbOArEcWHtBDi9h+3/XDLbKkbZWT3xE=; b=qxyfQK1upa18mZtqmq0H5Z2roRQ8OrzlnQl/6zmIyu+Rk9d2mXVe9BGjXqpw7FWgVi bWLM/M+RIanZR0ShWZtlgQv/KJ5EM3NSDr5iaDUtl8D4pbD+nKDJLUeSvgBKI/nOSUeF rHhNUV0XxLloiUCZmE0vE+9QRDmkT3HuvlBDU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=OnbT22NHiHtZB4oXksVDwe3YrIGF8MtFswgvmqxRdOp2QLlLEfVBqywgsEeY5zvReQ yaMQsEkIoESM05il5Tu3reD/HblN6G/UJqPJBT88FW0XhRvbLEWIVEAFNfY43hwG21zx DqAL6gFh317R3WGDVxbJY3lLPgrb02p/Ou+sQ= Received: by 10.42.96.135 with SMTP id j7mr11272842icn.245.1302642255154; Tue, 12 Apr 2011 14:04:15 -0700 (PDT) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id i26sm4068567iby.7.2011.04.12.14.04.05 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 12 Apr 2011 14:04:07 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Tue, 12 Apr 2011 14:03:54 -0700 From: YongHyeon PYUN Date: Tue, 12 Apr 2011 14:03:54 -0700 To: Alexander Motin Message-ID: <20110412210354.GC1421@michelle.cdnetworks.com> References: <4DA3EE8F.8050306@FreeBSD.org> <201104122132.23809.naylor.b.david@gmail.com> <4DA4B247.6010901@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4DA4B247.6010901@FreeBSD.org> User-Agent: Mutt/1.4.2.3i Cc: FreeBSD-Current , David Naylor Subject: Re: [regression] unable to boot: no GEOM devices found. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2011 21:34:09 -0000 On Tue, Apr 12, 2011 at 11:12:55PM +0300, Alexander Motin wrote: > David Naylor wrote: > > On Tuesday 12 April 2011 08:17:51 Alexander Motin wrote: > >> David Naylor wrote: > >>> I am running -current and since a few days ago (at least 2011/04/11) I am > >>> unable to boot. > >>> > >>> The boot process stops when it looks to find a bootable device. The > >>> prompt (when pressing '?') does not display any device and yielding one > >>> second (or more) to the kernel (by pressing '.') does not improve the > >>> situation. > >>> > >>> A known working date is 2011/02/20. > >>> > >>> I am running amd64 on a nVidia MCP51 chipset. > >> MCP51... again... > >> > >>> I am willing to help any way I can. > >> You could start from capturing and showing verbose dmesg. Full or at > >> least in parts related to disks. > > > > I captured the dmesg output for both the old (working) kernel and the new > > (bad) kernel. See attached for the difference between the two. If you need > > the full dmesg please let me know. > > > > One thing I found is that the old kernel would not boot if I simply rebooted > > from the bad kernel. I had to do a hard power off before the old kernel would > > work again. Is some device state surviving between reboots? > > +ata2: reiniting channel .. > +ata2: SATA connect time=0ms status=00000113 > +ata2: reset tp1 mask=01 ostat0=58 ostat1=00 > +ata2: stat0=0x50 err=0x01 lsb=0x00 msb=0x00 > +ata2: reset tp2 stat0=50 stat1=00 devices=0x1 > +ata2: reinit done .. > +unknown: FAILURE - ATA_IDENTIFY timed out LBA=0 > > As soon as all devices detected but not responding to commands, I would > suppose that there is something wrong with ATA interrupts. There is a > long chain of interrupt problems in this chipset. I have already tried > to debug one case where ATA wasn't generating interrupts at all. > Unfortunately, without success -- requests were executing, but not > generating interrupts, it wasn't looked like ATA driver problem. > > What's about possible candidate to revision triggering your problem, I > would look on this message: > +pcib0: Enabling MSI window for HyperTransport slave at pci0:0:9:0 > > At least it is recent (SVN revs 219737,219740 on 2011-03-18 by jhb) and > it is interrupt related. > Does the driver disable MSI for MCP51? I think jhb's patch fixed one MSI issue of all MCP chipset. From owner-freebsd-current@FreeBSD.ORG Tue Apr 12 21:39:30 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C58A71065670; Tue, 12 Apr 2011 21:39:30 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-px0-f172.google.com (mail-px0-f172.google.com [209.85.212.172]) by mx1.freebsd.org (Postfix) with ESMTP id 918ED8FC16; Tue, 12 Apr 2011 21:39:30 +0000 (UTC) Received: by pxi6 with SMTP id 6so5862pxi.17 for ; Tue, 12 Apr 2011 14:39:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=85VK5oy9JvUPHsgnLAI5DCDGm3/vGskmR9kDxaLWchg=; b=P4AY2DTPCAue6NtUumSGvWgchJruT8mT/czwWkc+oYLYQNhQdRXF0A2Dm7lqMbvAZj 68nurU+YPz7Bs68OfttxDVL9BMGrlE7I5ACphOZMb/GlPQ9dlPEMAUSjprsApczBi0dh HHuw2L7a6pllwfprGfcyQYZ8e4g3DKUjFyCBY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=dModY+uwUsADg+9j6mZ1SBFP3w3skGtYWsvhyTjKbmEl89EL3aqyVB02+RY1i91s0u +/8XNxp6OH/erhmlSfiNbEr9WaQquDwhsuKDhBoCuz8ebWfYuhIOgDVkkBz2AvEA9a4G N6HTYoYUl4lgn78jQbDpynXpy/1N1/OgcZOGw= MIME-Version: 1.0 Received: by 10.143.153.13 with SMTP id f13mr209395wfo.380.1302644370251; Tue, 12 Apr 2011 14:39:30 -0700 (PDT) Received: by 10.68.42.3 with HTTP; Tue, 12 Apr 2011 14:39:30 -0700 (PDT) In-Reply-To: <4DA4BF6A.7010806@FreeBSD.org> References: <4DA3EE8F.8050306@FreeBSD.org> <201104122132.23809.naylor.b.david@gmail.com> <4DA4B247.6010901@FreeBSD.org> <20110412210354.GC1421@michelle.cdnetworks.com> <4DA4BF6A.7010806@FreeBSD.org> Date: Tue, 12 Apr 2011 14:39:30 -0700 Message-ID: From: Garrett Cooper To: Alexander Motin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: pyunyh@gmail.com, FreeBSD-Current , David Naylor Subject: Re: [regression] unable to boot: no GEOM devices found. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2011 21:39:30 -0000 On Tue, Apr 12, 2011 at 2:08 PM, Alexander Motin wrote: > YongHyeon PYUN wrote: >> On Tue, Apr 12, 2011 at 11:12:55PM +0300, Alexander Motin wrote: >>> David Naylor wrote: >>>> On Tuesday 12 April 2011 08:17:51 Alexander Motin wrote: >>>>> David Naylor wrote: >>>>>> I am running -current and since a few days ago (at least 2011/04/11)= I am >>>>>> unable to boot. >>>>>> >>>>>> The boot process stops when it looks to find a bootable device. =A0T= he >>>>>> prompt (when pressing '?') does not display any device and yielding = one >>>>>> second (or more) to the kernel (by pressing '.') does not improve th= e >>>>>> situation. >>>>>> >>>>>> A known working date is 2011/02/20. >>>>>> >>>>>> I am running amd64 on a nVidia MCP51 chipset. >>>>> MCP51... again... >>>>> >>>>>> I am willing to help any way I can. >>>>> You could start from capturing and showing verbose dmesg. Full or at >>>>> least in parts related to disks. >>>> I captured the dmesg output for both the old (working) kernel and the = new >>>> (bad) kernel. =A0See attached for the difference between the two. =A0I= f you need >>>> the full dmesg please let me know. >>>> >>>> One thing I found is that the old kernel would not boot if I simply re= booted >>>> from the bad kernel. =A0I had to do a hard power off before the old ke= rnel would >>>> work again. =A0Is some device state surviving between reboots? >>> +ata2: reiniting channel .. >>> +ata2: SATA connect time=3D0ms status=3D00000113 >>> +ata2: reset tp1 mask=3D01 ostat0=3D58 ostat1=3D00 >>> +ata2: stat0=3D0x50 err=3D0x01 lsb=3D0x00 msb=3D0x00 >>> +ata2: reset tp2 stat0=3D50 stat1=3D00 devices=3D0x1 >>> +ata2: reinit done .. >>> +unknown: FAILURE - ATA_IDENTIFY timed out LBA=3D0 >>> >>> As soon as all devices detected but not responding to commands, I would >>> suppose that there is something wrong with ATA interrupts. There is a >>> long chain of interrupt problems in this chipset. I have already tried >>> to debug one case where ATA wasn't generating interrupts at all. >>> Unfortunately, without success -- requests were executing, but not >>> generating interrupts, it wasn't looked like ATA driver problem. >>> >>> What's about possible candidate to revision triggering your problem, I >>> would look on this message: >>> +pcib0: Enabling MSI window for HyperTransport slave at pci0:0:9:0 >>> >>> At least it is recent (SVN revs 219737,219740 on 2011-03-18 by jhb) and >>> it is interrupt related. >> >> Does the driver disable MSI for MCP51? > > ata(4) doesn't uses MSI by default and I doubt this controller supports > them any way. But if I am not mixing something, there were very strange > situations with MSI on that chipset, when enabling them one one device > caused interrupt problems on another. > >> I think jhb's patch fixed one MSI issue of all MCP chipset. > > I am not telling it is wrong. It could just trigger something. Could the OP try disabling MSI[X] to see whether or not the issue still occurs then? -Garrett From owner-freebsd-current@FreeBSD.ORG Tue Apr 12 22:00:24 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DCE8D1065672; Tue, 12 Apr 2011 22:00:24 +0000 (UTC) (envelope-from nick@van-laarhoven.org) Received: from cpsmtpb-ews10.kpnxchange.com (cpsmtpb-ews10.kpnxchange.com [213.75.39.15]) by mx1.freebsd.org (Postfix) with ESMTP id 6674A8FC1B; Tue, 12 Apr 2011 22:00:24 +0000 (UTC) Received: from cpbrm-ews21.kpnxchange.com ([10.94.84.152]) by cpsmtpb-ews10.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 12 Apr 2011 23:48:19 +0200 Received: from CPSMTPM-CMT101.kpnxchange.com ([195.121.3.17]) by cpbrm-ews21.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 12 Apr 2011 23:48:19 +0200 Received: from uitsmijter.van-laarhoven.org ([81.207.207.222]) by CPSMTPM-CMT101.kpnxchange.com with Microsoft SMTPSVC(7.0.6002.18264); Tue, 12 Apr 2011 23:48:18 +0200 Received: from hillary.lan (unknown [81.207.207.222]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by uitsmijter.van-laarhoven.org (Postfix) with ESMTPSA id 8723E40E2; Tue, 12 Apr 2011 23:48:18 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Nick Hibma In-Reply-To: <4D9B473F.8020607@FreeBSD.org> Date: Tue, 12 Apr 2011 23:48:17 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <87909196-8EAB-4255-A1C7-6AAB22FA46E8@van-laarhoven.org> References: <201104051321.56319.hselasky@freebsd.org> <4D9B1023.7020407@FreeBSD.org> <201104051455.33853.hselasky@freebsd.org> <4D9B473F.8020607@FreeBSD.org> To: Hans Petter Selasky , Andriy Gapon X-Mailer: Apple Mail (2.1084) X-OriginalArrivalTime: 12 Apr 2011 21:48:18.0852 (UTC) FILETIME=[55E3BE40:01CBF95B] X-RcptDomain: freebsd.org Cc: =?windows-1252?Q?=93FreeBSD_Current_Mailing_List=93?= , =?windows-1252?Q?=93FreeBSD_USB_Mailing_List=93?= Subject: Re: use_generic and usb probing X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2011 22:00:25 -0000 > Well, I think that that's what probe priorities actually for. > I also think that typically ivars should be set by a bus driver. So = maybe it's > not such a good idea to pass data from probe to attach via ivars in = child drivers. > But I could be mistaken about that. >=20 > Practically speaking, you most likely don't have to worry about that = for drivers > that return BUS_PROBE_SPECIFIC (=3D0) from their probe methods. And = there is only a > few "generic" drivers that can be handled on a case by case basis. Newbus priorities where specifically implemented on my request by Doug = Rabson to cater for fallback attachments: usb.h (the old code) contained = a list of priorities. ugen had the lowest priority and attached if no = one else did. An example was a keyboard with a built-in mouse on one = interface. It would be attached by either mouse or keyboard but not = both. An additional driver could probide both devices. We ended up = implementing that differently though: attachment to interfaces instead = of devices. A probe should not pass any information to the attach phase if it can at = all avoid it. Or at least that is the assumption. If a driver needs info = in both phases, it needs to regenerate it again. The fact that usb_probe = is called again is a kludge, specifically for the description. I guess that documenting this kludge and updating the comment to state = this fact would be sufficient to solve the problem. Nick= From owner-freebsd-current@FreeBSD.ORG Wed Apr 13 04:52:06 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D7E15106564A; Wed, 13 Apr 2011 04:52:06 +0000 (UTC) (envelope-from naylor.b.david@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 2EB348FC08; Wed, 13 Apr 2011 04:52:06 +0000 (UTC) Received: by wwc33 with SMTP id 33so236226wwc.31 for ; Tue, 12 Apr 2011 21:52:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:from:to:subject:date:user-agent:cc:references :in-reply-to:mime-version:content-type:content-transfer-encoding :message-id; bh=WD+GuTscdb+OrtcrKt47M3o5Qh+45fZEQTWk8CHbrxo=; b=cwHVZcDbrLYjt3LDyC/zYoQ/vqccBWssSXoa3f5S9jUHY8LjA0g2IwFvKVpjYNBWLn A/WgrAqmYaFb2JH8wh7pA96GuSYyqkZxrIUr0crkDd91TLzM2C0R8FBRB4Pikr9k1Luf HJMX4IanZr9YUfq+OcZ0qTdR3BBcJAERj4mVc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; b=G2reJT1pcbS3VJKw0G1onAgeTi2kMyLesl2PB7rgvFO4cNGcYDSb80ZP2qW5azNQp9 Il6xwA2VnlVa62j8e3XdXGzvPpDkbceLhEJKzRNTOHvUoaMwfG+dhzLBao/h/H1iMRda RnuyRrGO78QC2wyEOGsuTOMZxFOhu64FQgG7M= Received: by 10.227.168.138 with SMTP id u10mr1973380wby.186.1302670325234; Tue, 12 Apr 2011 21:52:05 -0700 (PDT) Received: from dragon.dg (41-135-148-75.dsl.mweb.co.za [41.135.148.75]) by mx.google.com with ESMTPS id b20sm84549wbb.33.2011.04.12.21.52.01 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 12 Apr 2011 21:52:04 -0700 (PDT) From: David Naylor To: Garrett Cooper Date: Wed, 13 Apr 2011 06:51:41 +0200 User-Agent: KMail/1.13.5 (FreeBSD/9.0-CURRENT; KDE/4.6.1; amd64; ; ) References: <4DA4BF6A.7010806@FreeBSD.org> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1709355.o4kG2Z27Zl"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201104130651.45408.naylor.b.david@gmail.com> Cc: pyunyh@gmail.com, Alexander Motin , FreeBSD-Current Subject: Re: [regression] unable to boot: no GEOM devices found. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 04:52:06 -0000 --nextPart1709355.o4kG2Z27Zl Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Tuesday 12 April 2011 23:39:30 Garrett Cooper wrote: > On Tue, Apr 12, 2011 at 2:08 PM, Alexander Motin wrote: > > YongHyeon PYUN wrote: > >> On Tue, Apr 12, 2011 at 11:12:55PM +0300, Alexander Motin wrote: > >>> David Naylor wrote: > >>>> On Tuesday 12 April 2011 08:17:51 Alexander Motin wrote: > >>>>> David Naylor wrote: > >>>>>> I am running -current and since a few days ago (at least 2011/04/1= 1) > >>>>>> I am unable to boot. > >>>>>>=20 > >>>>>> The boot process stops when it looks to find a bootable device. T= he > >>>>>> prompt (when pressing '?') does not display any device and yielding > >>>>>> one second (or more) to the kernel (by pressing '.') does not > >>>>>> improve the situation. > >>>>>>=20 > >>>>>> A known working date is 2011/02/20. > >>>>>>=20 > >>>>>> I am running amd64 on a nVidia MCP51 chipset. > >>>>>=20 > >>>>> MCP51... again... > >>>>>=20 > >>>>>> I am willing to help any way I can. > >>>>>=20 > >>>>> You could start from capturing and showing verbose dmesg. Full or at > >>>>> least in parts related to disks. > >>>>=20 > >>>> I captured the dmesg output for both the old (working) kernel and the > >>>> new (bad) kernel. See attached for the difference between the two. > >>>> If you need the full dmesg please let me know. > >>>>=20 > >>>> One thing I found is that the old kernel would not boot if I simply > >>>> rebooted from the bad kernel. I had to do a hard power off before > >>>> the old kernel would work again. Is some device state surviving > >>>> between reboots? > >>>=20 > >>> +ata2: reiniting channel .. > >>> +ata2: SATA connect time=3D0ms status=3D00000113 > >>> +ata2: reset tp1 mask=3D01 ostat0=3D58 ostat1=3D00 > >>> +ata2: stat0=3D0x50 err=3D0x01 lsb=3D0x00 msb=3D0x00 > >>> +ata2: reset tp2 stat0=3D50 stat1=3D00 devices=3D0x1 > >>> +ata2: reinit done .. > >>> +unknown: FAILURE - ATA_IDENTIFY timed out LBA=3D0 > >>>=20 > >>> As soon as all devices detected but not responding to commands, I wou= ld > >>> suppose that there is something wrong with ATA interrupts. There is a > >>> long chain of interrupt problems in this chipset. I have already tried > >>> to debug one case where ATA wasn't generating interrupts at all. > >>> Unfortunately, without success -- requests were executing, but not > >>> generating interrupts, it wasn't looked like ATA driver problem. > >>>=20 > >>> What's about possible candidate to revision triggering your problem, I > >>> would look on this message: > >>> +pcib0: Enabling MSI window for HyperTransport slave at pci0:0:9:0 > >>>=20 > >>> At least it is recent (SVN revs 219737,219740 on 2011-03-18 by jhb) a= nd > >>> it is interrupt related. > >>=20 > >> Does the driver disable MSI for MCP51? > >=20 > > ata(4) doesn't uses MSI by default and I doubt this controller supports > > them any way. But if I am not mixing something, there were very strange > > situations with MSI on that chipset, when enabling them one one device > > caused interrupt problems on another. > >=20 > >> I think jhb's patch fixed one MSI issue of all MCP chipset. > >=20 > > I am not telling it is wrong. It could just trigger something. >=20 > Could the OP try disabling MSI[X] to see whether or not the issue > still occurs then? > -Garrett I added: hw.pci.enable_msi=3D0 hw.pci.enable_msix=3D0 to loader.conf but the problem persisted. =20 @mav: I will revert r219737 and r219740 and try again but this will be in += 10=20 hours... =20 Thanks --nextPart1709355.o4kG2Z27Zl Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (FreeBSD) iEYEABECAAYFAk2lK+EACgkQUaaFgP9pFrKtkwCcDMr2BtREyyB5Q4EF4F4s6M8P eQ8AnRf8/qPwSmW7kGWm2ve6otlr9+1Q =m91d -----END PGP SIGNATURE----- --nextPart1709355.o4kG2Z27Zl-- From owner-freebsd-current@FreeBSD.ORG Wed Apr 13 13:02:15 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 189361065670 for ; Wed, 13 Apr 2011 13:02:15 +0000 (UTC) (envelope-from boogie@lazybytes.org) Received: from mail.lazybytes.org (mail.lazybytes.org [195.54.209.3]) by mx1.freebsd.org (Postfix) with ESMTP id C56508FC19 for ; Wed, 13 Apr 2011 13:02:14 +0000 (UTC) Received: from [95.108.170.237] (dhcp170-237-red.yandex.net [95.108.170.237]) by mail.lazybytes.org (Postfix) with ESMTPSA id 46A0A95B; Wed, 13 Apr 2011 17:02:12 +0400 (MSD) Message-ID: <4DA59F0C.3060708@lazybytes.org> Date: Wed, 13 Apr 2011 17:03:08 +0400 From: Sergey Vinogradov User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.15) Gecko/20110307 Lanikai/3.1.9 MIME-Version: 1.0 To: gljennjohn@googlemail.com References: <4DA2EFEF.3010004@lazybytes.org> <20110411171713.144d9a72@ernst.jennejohn.org> In-Reply-To: <20110411171713.144d9a72@ernst.jennejohn.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (mail.lazybytes.org); Wed, 13 Apr 2011 17:02:13 +0400 (MSD) Cc: freebsd-current@freebsd.org Subject: Re: [PATCH] ifconfig(8) flag to display IPv4 netmasks in dot-decimal format X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 13:02:15 -0000 On 11.04.2011 19:17, Gary Jennejohn wrote: > On Mon, 11 Apr 2011 16:11:27 +0400 > Sergey Vinogradov wrote: > >> I've written a tiny-tiny patch, which adds the '-t' flag to ifconfig(8). >> It modifies the output to display IPv4 netmasks in dotted decimal notation: >> >> % ifconfig msk0 >> msk0: flags=8843 metric 0 mtu 1500 >> >> options=c011a >> ether 00:16:e6:88:0f:89 >> inet 10.10.0.1 netmask 0xffffff00 broadcast 10.10.0.255 >> media: Ethernet autoselect (none) >> status: no carrier >> >> % ifconfig -t msk0 >> msk0: flags=8843 metric 0 mtu 1500 >> >> options=c011a >> ether 00:16:e6:88:0f:89 >> inet 10.10.0.1 netmask 255.255.255.0 broadcast 10.10.0.255 >> media: Ethernet autoselect (none) >> status: no carrier >> >> There was a discussion [1] in freebsd-hackers@ about adding such >> functionality to ifconfig(8), which urged me write this patch. The >> default behavior of ifconfig(8) is kept unmodified, so there shouldn't >> be any compatibility breakages. At least, it works fine for me :) >> >> [1] >> http://lists.freebsd.org/pipermail/freebsd-hackers/2011-April/034997.html >> > > Looks good, except I'd change this line to read like this: > +The > +.Fl t > +flag makes IPv4 netmasks being displayed in dotted decimal notation. > ^^^^^ results in > Note taken, fix will appear in the next patch version (if any). -- wbr, Boo From owner-freebsd-current@FreeBSD.ORG Wed Apr 13 14:24:02 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3E1331065673; Wed, 13 Apr 2011 14:24:02 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 445628FC12; Wed, 13 Apr 2011 14:24:00 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id RAA18424; Wed, 13 Apr 2011 17:22:37 +0300 (EEST) (envelope-from avg@FreeBSD.org) Message-ID: <4DA5B1AD.5070703@FreeBSD.org> Date: Wed, 13 Apr 2011 17:22:37 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.15) Gecko/20110309 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: Nick Hibma References: <201104051321.56319.hselasky@freebsd.org> <4D9B1023.7020407@FreeBSD.org> <201104051455.33853.hselasky@freebsd.org> <4D9B473F.8020607@FreeBSD.org> <87909196-8EAB-4255-A1C7-6AAB22FA46E8@van-laarhoven.org> In-Reply-To: <87909196-8EAB-4255-A1C7-6AAB22FA46E8@van-laarhoven.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: =?windows-1252?Q?Current_Mailing_List=93?= , =?windows-1252?Q?=93FreeBSD_USB_Mailing_List=93?= , =?windows-1252?Q?=93FreeBSD_?=, Hans Petter Selasky Subject: Re: use_generic and usb probing X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 14:24:02 -0000 on 13/04/2011 00:48 Nick Hibma said the following: >> Well, I think that that's what probe priorities actually for. I also think >> that typically ivars should be set by a bus driver. So maybe it's not such a >> good idea to pass data from probe to attach via ivars in child drivers. But I >> could be mistaken about that. >> >> Practically speaking, you most likely don't have to worry about that for >> drivers that return BUS_PROBE_SPECIFIC (=0) from their probe methods. And >> there is only a few "generic" drivers that can be handled on a case by case >> basis. > > Newbus priorities where specifically implemented on my request by Doug Rabson > to cater for fallback attachments: usb.h (the old code) contained a list of > priorities. ugen had the lowest priority and attached if no one else did. An > example was a keyboard with a built-in mouse on one interface. It would be > attached by either mouse or keyboard but not both. An additional driver could > probide both devices. We ended up implementing that differently though: > attachment to interfaces instead of devices. OK. Though I don't see how that is related to the question that I raised. > A probe should not pass any information to the attach phase if it can at all > avoid it. Or at least that is the assumption. If a driver needs info in both > phases, it needs to regenerate it again. The fact that usb_probe is called > again is a kludge, specifically for the description. I am not sure that I understood this part. > I guess that documenting this kludge and updating the comment to state this > fact would be sufficient to solve the problem. I don't see how this follows from what you've written above. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Wed Apr 13 16:34:17 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4C4A2106564A; Wed, 13 Apr 2011 16:34:17 +0000 (UTC) (envelope-from buganini@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id DDE698FC12; Wed, 13 Apr 2011 16:34:16 +0000 (UTC) Received: by iyj12 with SMTP id 12so901222iyj.13 for ; Wed, 13 Apr 2011 09:34:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=fWEOHKKI9Ho86q14Dk2OeVZCU1Tr3bR9Y9CU+ErCHDc=; b=Z2C/TZGgfL5V4sfVi14i6G4iKUiF+inTFsoBioaxbd6UHcZW4eY9ThOMMgzYw/1dal ddyo0r52UIlx4/4ToGknxTTKyHkIyOD2oHPp9r5TkHLCs/jDhg6M5N5Wyj8DYuEEnHKg aXkAI4C5ab1A+o4It5UAsyxTf2UrrG4U/CqI4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=sfd1I9lGxGCAT/w/MPaXe1lUJavVhkwmvDZ6hYUGQG5tG+28ePJgYcxHitwMJMLfSe bLT3OeCyMZwkQXExoYMZRwTAMjxKGm1LgsrR7QV6W16RNRTbF2++jYM9fOXRqyIu3i+f SvfpK7YBtN5DUUVpPYwWKXQt08jWEVDuM5rj4= MIME-Version: 1.0 Received: by 10.42.158.132 with SMTP id h4mr19012icx.202.1302712231495; Wed, 13 Apr 2011 09:30:31 -0700 (PDT) Received: by 10.231.30.203 with HTTP; Wed, 13 Apr 2011 09:30:31 -0700 (PDT) In-Reply-To: <4CD45209.5010607@FreeBSD.org> References: <4CD45209.5010607@FreeBSD.org> Date: Thu, 14 Apr 2011 00:30:31 +0800 Message-ID: From: Buganini To: Alexander Motin Content-Type: text/plain; charset=UTF-8 Cc: freebsd-scsi@freebsd.org, FreeBSD-Current , FreeBSD Stable Subject: Re: Sense fetching [Was: cdrtools /devel ...] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 16:34:17 -0000 does r22056{3,5,6,9} supercede these patches ? my dvd burning with ahci seems to be fixed by those commits, without these patches. I've just burned a DVD successful, and it's readable. Thanks, Buganini From owner-freebsd-current@FreeBSD.ORG Wed Apr 13 16:39:20 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7694D106564A; Wed, 13 Apr 2011 16:39:20 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id A60728FC12; Wed, 13 Apr 2011 16:39:19 +0000 (UTC) Received: by fxm11 with SMTP id 11so776458fxm.13 for ; Wed, 13 Apr 2011 09:39:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=1V/ej9kEPFQ8GtxpHLmcyxUsTxRYSwIchTQ1XxY+7jE=; b=WtYbttk3CfpeI8w9f2wuFAYWoDUzCldon87jnLG2VHnTgrr1GOHgudtzOQvbLJDhHt x3fhmWTVdXMe0WNDL6HXhVLIc5TTJoksllh/rGK51oKtAa211vOI3XE45PhuvpaAovCc 4WKxt4nJUrwWQCmIslSr8iKSonci7IvUemIC4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=s5vnI287MZwAmAwnyXtF3faelBxiyDL8NWdOAjLAqMBoBDhUDwhnjGIdgWb5VWH8DU EgJ9blh9Mcg8IRp/kSuW6ztqJM8nAcC65OfTih+BoTkN/gPYTbSz8ThdV/MZcRv902Gh w0MNgW+/zbxuOV/UyMCNm2RsIAGK4U1SGTaOU= Received: by 10.223.91.79 with SMTP id l15mr2453584fam.53.1302712758516; Wed, 13 Apr 2011 09:39:18 -0700 (PDT) Received: from mavbook2.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id g5sm234002faa.26.2011.04.13.09.39.16 (version=SSLv3 cipher=OTHER); Wed, 13 Apr 2011 09:39:17 -0700 (PDT) Sender: Alexander Motin Message-ID: <4DA5D1A5.6090806@FreeBSD.org> Date: Wed, 13 Apr 2011 19:39:01 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: Buganini References: <4CD45209.5010607@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-scsi@freebsd.org, FreeBSD-Current , FreeBSD Stable Subject: Re: Sense fetching [Was: cdrtools /devel ...] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 16:39:20 -0000 Buganini wrote: > does r22056{3,5,6,9} supercede these patches ? Yes. They solve problem from different side. > my dvd burning with ahci seems to be fixed by those commits, > without these patches. > > I've just burned a DVD successful, and it's readable. Yea, I've also burned few DVDs with cdrecord-devel for testing. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Wed Apr 13 17:07:34 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E1DFE106566B; Wed, 13 Apr 2011 17:07:34 +0000 (UTC) (envelope-from naylor.b.david@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id DE6518FC0A; Wed, 13 Apr 2011 17:07:33 +0000 (UTC) Received: by wyf23 with SMTP id 23so799272wyf.13 for ; Wed, 13 Apr 2011 10:07:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:from:to:subject:date:user-agent:cc:references :in-reply-to:mime-version:content-type:content-transfer-encoding :message-id; bh=w95RgQReyJarOo05+mvs1w4yno95tg6uOv1urrKzWxQ=; b=hliYCsW35RWLvcadezetgsGoJg0zSwusrKoZ2M9IRbCYFy4GvofGOBUhm8Kd/WrMri 7D4lUyEB+i3yvW6t/Ks6YdNO2XWYZp8GQ+YSnr+BkpyWcSuKKWU1bOJM1HnBy1CbTgY/ PlYDz+5PlHY+4ANY2UtF8DQBB6xpZdOmgVg6s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; b=CmK/0OMgf+U8G3tWjPaCyPqEm+rU1gg5GO97DASeQsCS1V++8VCOg3Wemp5YwtBMub GO2yl4X4Sv3rJOR47QrkdSWxwY/qD/+BmGzWtrdnyuKD0aYHARGL82aNE7vzYlsUAO5O E4Bklmba04HOonHXkKGc26C1VIAmlauNLAKsE= Received: by 10.227.198.199 with SMTP id ep7mr8095557wbb.40.1302714452851; Wed, 13 Apr 2011 10:07:32 -0700 (PDT) Received: from dragon.dg (41-135-148-75.dsl.mweb.co.za [41.135.148.75]) by mx.google.com with ESMTPS id e13sm464034wbi.40.2011.04.13.10.07.28 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 13 Apr 2011 10:07:30 -0700 (PDT) From: David Naylor To: Alexander Motin Date: Wed, 13 Apr 2011 19:07:06 +0200 User-Agent: KMail/1.13.5 (FreeBSD/9.0-CURRENT; KDE/4.6.1; amd64; ; ) References: <201104122132.23809.naylor.b.david@gmail.com> <4DA4B247.6010901@FreeBSD.org> In-Reply-To: <4DA4B247.6010901@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2602315.0xpPBTegJJ"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201104131907.12368.naylor.b.david@gmail.com> Cc: FreeBSD-Current Subject: Re: [regression] unable to boot: no GEOM devices found. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 17:07:35 -0000 --nextPart2602315.0xpPBTegJJ Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Tuesday 12 April 2011 22:12:55 Alexander Motin wrote: > David Naylor wrote: > > On Tuesday 12 April 2011 08:17:51 Alexander Motin wrote: > >> David Naylor wrote: > >>> I am running -current and since a few days ago (at least 2011/04/11) I > >>> am unable to boot. > >>>=20 > >>> The boot process stops when it looks to find a bootable device. The > >>> prompt (when pressing '?') does not display any device and yielding o= ne > >>> second (or more) to the kernel (by pressing '.') does not improve the > >>> situation. > >>>=20 > >>> A known working date is 2011/02/20. > >>>=20 > >>> I am running amd64 on a nVidia MCP51 chipset. > >>=20 > >> MCP51... again... > > +ata2: reiniting channel .. > +ata2: SATA connect time=3D0ms status=3D00000113 > +ata2: reset tp1 mask=3D01 ostat0=3D58 ostat1=3D00 > +ata2: stat0=3D0x50 err=3D0x01 lsb=3D0x00 msb=3D0x00 > +ata2: reset tp2 stat0=3D50 stat1=3D00 devices=3D0x1 > +ata2: reinit done .. > +unknown: FAILURE - ATA_IDENTIFY timed out LBA=3D0 >=20 > As soon as all devices detected but not responding to commands, I would > suppose that there is something wrong with ATA interrupts. There is a > long chain of interrupt problems in this chipset. I have already tried > to debug one case where ATA wasn't generating interrupts at all. > Unfortunately, without success -- requests were executing, but not > generating interrupts, it wasn't looked like ATA driver problem. >=20 > What's about possible candidate to revision triggering your problem, I > would look on this message: > +pcib0: Enabling MSI window for HyperTransport slave at pci0:0:9:0 >=20 > At least it is recent (SVN revs 219737,219740 on 2011-03-18 by jhb) and > it is interrupt related. I reverted those two revs and everything works again. =20 --nextPart2602315.0xpPBTegJJ Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (FreeBSD) iEYEABECAAYFAk2l2EAACgkQUaaFgP9pFrJDLQCePItyLO3BLrvcHI8ISfqZCx5q RvwAn3bXKUipMEDNYHydD+WosTwhvSDX =G3GB -----END PGP SIGNATURE----- --nextPart2602315.0xpPBTegJJ-- From owner-freebsd-current@FreeBSD.ORG Thu Apr 14 09:19:53 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ADF8E106564A; Thu, 14 Apr 2011 09:19:53 +0000 (UTC) (envelope-from geo.liaskos@gmail.com) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id 5895F8FC16; Thu, 14 Apr 2011 09:19:53 +0000 (UTC) Received: by gxk28 with SMTP id 28so770720gxk.13 for ; Thu, 14 Apr 2011 02:19:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to:cc :content-type; bh=MgSRtXtmrSRRM4u1s/YuPCMvWOhbh9feAMlhGENEHxY=; b=Il7KFgnX09LHro4gJlzR12hsB9NjbhIOhCKdGZexC/D+WaOyGON4V5vDRSABA4C25D zXxOCYF3c3UXEUjMx9qEUO1FeJQiJGffpUokHDoP0gH/X+u1Un/CiQYSoFGV6TyAMIVi xRLwEGSNtXGuKYx755q4NYWCBfvHGXRZgLlB4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=SYWvDtnQCeVCwqlCYsH4Y6JnnvLwZS2f5e3RmCAqpXdUe4n/a8IUfJb+b+dEfCmXMR qxw2McWtCITt6aRTL1rU/lsQkI2RimHubeoWeVoRDZg0QRBfWJHVrCwVqpEi2ai0W8JV kroKj3GaJ8OyNvzynckZUy3/b30n3bGEfMRxE= MIME-Version: 1.0 Received: by 10.101.139.15 with SMTP id r15mr283577ann.137.1302771486404; Thu, 14 Apr 2011 01:58:06 -0700 (PDT) Received: by 10.100.215.10 with HTTP; Thu, 14 Apr 2011 01:58:06 -0700 (PDT) Date: Thu, 14 Apr 2011 11:58:06 +0300 Message-ID: From: George Liaskos To: freebsd-current@freebsd.org Content-Type: text/plain; charset=UTF-8 Cc: kde@freebsd.org Subject: KDE related compile errors on CURRENT. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 09:19:53 -0000 Hi list. It seems that ssse3 support on base gcc is causing some compile errors on KDE related ports, all of them so far are tracked down to eigen2. More precisely, /usr/local/include/eigen2/Eigen/Core : 37 #ifdef __SSE3__ 38 #include 39 #endif 40 #ifdef __SSSE3__ 41 #include 42 #endif I have tmmintrin.h only under /usr/include/clang/2.9, using r220528 - amd64. [ 78%] Building CXX object wallpapers/mandelbrot/CMakeFiles/plasma_wallpaper_mandelbrot.dir/mix.o In file included from /usr/ports/deskutils/kdeplasma-addons/work/kdeplasma-addons-4.6.2/wallpapers/mandelbrot/mix.h:23, from /usr/ports/deskutils/kdeplasma-addons/work/kdeplasma-addons-4.6.2/wallpapers/mandelbrot/mix.cpp:19: /usr/local/include/eigen2/Eigen/Core:41:29: error: tmmintrin.h: No such file or directory [ 78%] [ 78%] Building CXX object containments/groupingdesktop/lib/CMakeFiles/plasma_groupingcontainment.dir/plasma_groupingcontainment_automoc.o Building CXX object containments/groupingdesktop/lib/CMakeFiles/plasma_groupingcontainment.dir/abstractgroup.o Linking CXX shared module ../../lib/plasma_wallpaper_virus.so Linking CXX shared module ../../lib/plasma_wallpaper_marble.so [ 78%] [ 78%] Building CXX object containments/groupingdesktop/lib/CMakeFiles/plasma_groupingcontainment.dir/groupinfo.o [ 78%] Built target plasma_wallpaper_virus Built target plasma_wallpaper_marble [ 78%] Building CXX object containments/groupingdesktop/lib/CMakeFiles/plasma_groupingcontainment.dir/groupfactory.o Scanning dependencies of target rtmlogin In file included from /usr/local/include/eigen2/Eigen/Core:109, from /usr/ports/deskutils/kdeplasma-addons/work/kdeplasma-addons-4.6.2/wallpapers/mandelbrot/mix.h:23, from /usr/ports/deskutils/kdeplasma-addons/work/kdeplasma-addons-4.6.2/wallpapers/mandelbrot/render_impl.cpp:20, from /usr/ports/deskutils/kdeplasma-addons/work/kdeplasma-addons-4.6.2/wallpapers/mandelbrot/render_with_arch_defaults.cpp:1: /usr/local/include/eigen2/Eigen/src/Core/arch/SSE/PacketMath.h: In static member function 'static void Eigen::ei_palign_impl::run(float __vector__&, const float __vector__&)': /usr/local/include/eigen2/Eigen/src/Core/arch/SSE/PacketMath.h:239: error: there are no arguments to '_mm_alignr_epi8' that depend on a template parameter, so a declaration of '_mm_alignr_epi8' must be available /usr/local/include/eigen2/Eigen/src/Core/arch/SSE/PacketMath.h:239: error: (if you use '-fpermissive', G++ will accept your code, but allowing the use of an undeclared name is deprecated) [ 78%] /usr/local/include/eigen2/Eigen/src/Core/arch/SSE/PacketMath.h: In static member function 'static void Eigen::ei_palign_impl::run(long long int __vector__&, const long long int __vector__&)': /usr/local/include/eigen2/Eigen/src/Core/arch/SSE/PacketMath.h:249: error: there are no arguments to '_mm_alignr_epi8' that depend on a template parameter, so a declaration of '_mm_alignr_epi8' must be available /usr/local/include/eigen2/Eigen/src/Core/arch/SSE/PacketMath.h: In static member function 'static void Eigen::ei_palign_impl::run(double __vector__&, const double __vector__&)': /usr/local/include/eigen2/Eigen/src/Core/arch/SSE/PacketMath.h:259: error: there are no arguments to '_mm_alignr_epi8' that depend on a template parameter, so a declaration of '_mm_alignr_epi8' must be available Building CXX object libs/rtm/tests/CMakeFiles/rtmlogin.dir/rtmlogin_automoc.o In file included from /usr/local/include/eigen2/Eigen/Core:109, from /usr/ports/deskutils/kdeplasma-addons/work/kdeplasma-addons-4.6.2/wallpapers/mandelbrot/mix.h:23, from /usr/ports/deskutils/kdeplasma-addons/work/kdeplasma-addons-4.6.2/wallpapers/mandelbrot/mix.cpp:19: /usr/local/include/eigen2/Eigen/src/Core/arch/SSE/PacketMath.h: In static member function 'static void Eigen::ei_palign_impl::run(float __vector__&, const float __vector__&)': /usr/local/include/eigen2/Eigen/src/Core/arch/SSE/PacketMath.h:239: error: there are no arguments to '_mm_alignr_epi8' that depend on a template parameter, so a declaration of '_mm_alignr_epi8' must be available[ 78%] /usr/local/include/eigen2/Eigen/src/Core/arch/SSE/PacketMath.h:239: error: (if you use '-fpermissive', G++ will accept your code, but allowing the use of an undeclared name is deprecated) /usr/local/include/eigen2/Eigen/src/Core/arch/SSE/PacketMath.h: In static member function 'static void Eigen::ei_palign_impl::run(long long int __vector__&, const long long int __vector__&)': /usr/local/include/eigen2/Eigen/src/Core/arch/SSE/PacketMath.h:249: error: there are no arguments to '_mm_alignr_epi8' that depend on a template parameter, so a declaration of '_mm_alignr_epi8' must be available Scanning dependencies of target rtmrefresh /usr/local/include/eigen2/Eigen/src/Core/arch/SSE/PacketMath.h: In static member function 'static void Eigen::ei_palign_impl::run(double __vector__&, const double __vector__&)': /usr/local/include/eigen2/Eigen/src/Core/arch/SSE/PacketMath.h:259: error: there are no arguments to '_mm_alignr_epi8' that depend on a template parameter, so a declaration of '_mm_alignr_epi8' must be available Building CXX object libs/rtm/tests/CMakeFiles/rtmlogin.dir/login.o [ 79%] Building CXX object libs/rtm/tests/CMakeFiles/rtmrefresh.dir/rtmrefresh_automoc.o [ 79%] Building CXX object libs/rtm/tests/CMakeFiles/rtmrefresh.dir/refresh.o gmake[2]: *** [wallpapers/mandelbrot/CMakeFiles/plasma_wallpaper_mandelbrot.dir/render_with_arch_defaults.o] Error 1 gmake[2]: *** Waiting for unfinished jobs.... [ 80%] Building CXX object containments/groupingdesktop/lib/CMakeFiles/plasma_groupingcontainment.dir/groupingcontainment.o [ 80%] gmake[2]: *** [wallpapers/mandelbrot/CMakeFiles/plasma_wallpaper_mandelbrot.dir/mix.o] Error 1 gmake[1]: *** [wallpapers/mandelbrot/CMakeFiles/plasma_wallpaper_mandelbrot.dir/all] Error 2 [ 80%] gmake[1]: *** Waiting for unfinished jobs.... Generating kopete_interface.cpp, kopete_interface.h Building CXX object containments/groupingdesktop/lib/CMakeFiles/plasma_groupingcontainment.dir/handle.o Regards From owner-freebsd-current@FreeBSD.ORG Thu Apr 14 10:30:19 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F3755106564A for ; Thu, 14 Apr 2011 10:30:19 +0000 (UTC) (envelope-from gljennjohn@googlemail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 509258FC08 for ; Thu, 14 Apr 2011 10:30:18 +0000 (UTC) Received: by bwz12 with SMTP id 12so1651317bwz.13 for ; Thu, 14 Apr 2011 03:30:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:date:from:to:cc:subject:message-id:in-reply-to :references:reply-to:x-mailer:mime-version:content-type :content-transfer-encoding; bh=wOE9pLF5KVzJ9nPx2rYtd8huymNaKmI5/cmEkY2zX4w=; b=ddEUhUU8d9OnrSEfh8GpzF9fXS0Bl5r29qLRLux4JD/D1pW8W5awocBVRSlvex5wXY W1BkEjbA3RQkNFpMK+FpzBtihuEYFbmEY9pYwNO8Hz12IUUC65YaUbn46vANBfSw65q6 c5j+nTCuhwEVj7hchQYHIcHW8sSa8DlmJi8aw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=date:from:to:cc:subject:message-id:in-reply-to:references:reply-to :x-mailer:mime-version:content-type:content-transfer-encoding; b=hr3WvEEm8tUl2i6ehB/inqst7iFtkp33OMyfeC/QMRI00hiFlIxp75qaRM7NEBQIIH nKlYVa0p3fo7F5gkDWKj0jr4jHJpFYEQlofsWQsh9MjLMWp1e4Dv1oaQrW7Bg0gkFWUS FVRCvuf1Yvho/fFRUW10BFHvhuVIYUTU2wcDU= Received: by 10.204.7.213 with SMTP id e21mr393363bke.209.1302777018102; Thu, 14 Apr 2011 03:30:18 -0700 (PDT) Received: from ernst.jennejohn.org (p578E3543.dip.t-dialin.net [87.142.53.67]) by mx.google.com with ESMTPS id v21sm848314bkt.11.2011.04.14.03.30.15 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 14 Apr 2011 03:30:16 -0700 (PDT) Date: Thu, 14 Apr 2011 12:30:13 +0200 From: Gary Jennejohn To: George Liaskos Message-ID: <20110414123013.744ec7d7@ernst.jennejohn.org> In-Reply-To: References: X-Mailer: Claws Mail 3.7.8 (GTK+ 2.18.7; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, kde@freebsd.org Subject: Re: KDE related compile errors on CURRENT. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gljennjohn@googlemail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 10:30:20 -0000 On Thu, 14 Apr 2011 11:58:06 +0300 George Liaskos wrote: > Hi list. > > It seems that ssse3 support on base gcc is causing some compile errors > on KDE related ports, all of them so far are tracked down to eigen2. > > More precisely, /usr/local/include/eigen2/Eigen/Core : > > 37 #ifdef __SSE3__ > 38 #include > 39 #endif > 40 #ifdef __SSSE3__ > 41 #include > 42 #endif > > I have tmmintrin.h only under /usr/include/clang/2.9, using r220528 - amd64. > These are part of the gcc sources, but apparently tmmintrin.h is not installed under /usr/include. On my AMD64-current machine I have /usr/include/gcc/4.2/pmmintrin.h and /usr/src/contrib/gcc/config/i386/tmmintrin.h Don't have clang installed. -- Gary Jennejohn From owner-freebsd-current@FreeBSD.ORG Thu Apr 14 11:50:12 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4FA5110656AE; Thu, 14 Apr 2011 11:50:12 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id 0AE8C8FC18; Thu, 14 Apr 2011 11:50:12 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:dd48:486e:166b:644] (unknown [IPv6:2001:7b8:3a7:0:dd48:486e:166b:644]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 45F3F5C59; Thu, 14 Apr 2011 13:50:11 +0200 (CEST) Message-ID: <4DA6DF88.2040005@FreeBSD.org> Date: Thu, 14 Apr 2011 13:50:32 +0200 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.16pre) Gecko/20110319 Lanikai/3.1.10pre MIME-Version: 1.0 To: George Liaskos References: In-Reply-To: Content-Type: multipart/mixed; boundary="------------050905050405080700090709" Cc: freebsd-current@freebsd.org, kde@freebsd.org Subject: Re: KDE related compile errors on CURRENT. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 11:50:12 -0000 This is a multi-part message in MIME format. --------------050905050405080700090709 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 2011-04-14 10:58, George Liaskos wrote: ... > More precisely, /usr/local/include/eigen2/Eigen/Core : > > 37 #ifdef __SSE3__ > 38 #include > 39 #endif > 40 #ifdef __SSSE3__ > 41 #include > 42 #endif > > I have tmmintrin.h only under /usr/include/clang/2.9, using r220528 - amd64. You can just copy /usr/src/contrib/gcc/config/i386/tmmintrin.h to /usr/include/gcc/4.2 for now, or apply the attached patch and run "make install" in /usr/src/gnu/usr.bin/cc/include. I'll commit a fix to -current tonight. --------------050905050405080700090709 Content-Type: text/plain; name="add-tmmintrin-1.diff" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="add-tmmintrin-1.diff" SW5kZXg6IGdudS91c3IuYmluL2NjL2luY2x1ZGUvTWFrZWZpbGUKPT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQot LS0gZ251L3Vzci5iaW4vY2MvaW5jbHVkZS9NYWtlZmlsZQkocmV2aXNpb24gMjIwNjIwKQor KysgZ251L3Vzci5iaW4vY2MvaW5jbHVkZS9NYWtlZmlsZQkod29ya2luZyBjb3B5KQpAQCAt Nyw3ICs3LDcgQEAgSU5DU0RJUj0ke0lOQ0xVREVESVJ9L2djYy8ke0dDQ1ZFUn0KIC5QQVRI OiAke0dDQ0RJUn0vY29uZmlnLyR7R0NDX0NQVX0KIAogLmlmICR7VEFSR0VUX0FSQ0h9ID09 ICJpMzg2IiB8fCAke1RBUkdFVF9BUkNIfSA9PSAiYW1kNjQiCi1JTkNTPQllbW1pbnRyaW4u aCBtbWludHJpbi5oIHBtbWludHJpbi5oIHhtbWludHJpbi5oIG1tX21hbGxvYy5oCitJTkNT PQllbW1pbnRyaW4uaCBtbWludHJpbi5oIHBtbWludHJpbi5oIHRtbWludHJpbi5oIHhtbWlu dHJpbi5oIG1tX21hbGxvYy5oCiAuZWxpZiAke1RBUkdFVF9BUkNIfSA9PSAiaWE2NCIKIElO Q1M9CWlhNjRpbnRyaW4uaAogLmVsaWYgJHtUQVJHRVRfQVJDSH0gPT0gImFybSIK --------------050905050405080700090709-- From owner-freebsd-current@FreeBSD.ORG Thu Apr 14 12:20:22 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7CD65106566B; Thu, 14 Apr 2011 12:20:22 +0000 (UTC) (envelope-from geo.liaskos@gmail.com) Received: from mail-yi0-f54.google.com (mail-yi0-f54.google.com [209.85.218.54]) by mx1.freebsd.org (Postfix) with ESMTP id 0C9468FC0A; Thu, 14 Apr 2011 12:20:21 +0000 (UTC) Received: by yie12 with SMTP id 12so833744yie.13 for ; Thu, 14 Apr 2011 05:20:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=kEGbNmm/xpiWoEqxr9J+THVkIl2XPpAhz7OdFQzJTuw=; b=DDXaRG9ZfXXQFUc5wnVvs67xW4Yh/jYp0NyRD+yoE4ovQ1+3L5dSFSbddYnJM3FXSm H7jLYAI6H7TdfuA3/MqlCTMTKerKO+G5OAxzb1ML2O56WzgWxGmtkx+DbY8Mt8VlAWS8 lQffDFJu64ewk49AuSRh0ccZQ/BsYRjlpQ5Po= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=Ms/YedwzGi8Cn3Dkm/6LOvIcORbR8ZWHrODbuWsHW2vSZ0Uhn+jD9VNnVxwHvxp61i vmGH7IbgiDdPHCwM+ms6/1JgsbnHz2Pj9AxOhcVhhY77WyWPKmEo7oA86eOHPRtVtagU 6NHghiNE47RYTpoap9+wo2qghMctjHAwcAJzI= MIME-Version: 1.0 Received: by 10.151.5.20 with SMTP id h20mr1499723ybi.229.1302783621284; Thu, 14 Apr 2011 05:20:21 -0700 (PDT) Received: by 10.100.215.10 with HTTP; Thu, 14 Apr 2011 05:20:21 -0700 (PDT) In-Reply-To: <4DA6DF88.2040005@FreeBSD.org> References: <4DA6DF88.2040005@FreeBSD.org> Date: Thu, 14 Apr 2011 15:20:21 +0300 Message-ID: From: George Liaskos To: Dimitry Andric Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org, kde@freebsd.org Subject: Re: KDE related compile errors on CURRENT. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 12:20:22 -0000 > You can just copy /usr/src/contrib/gcc/config/i386/tmmintrin.h to > /usr/include/gcc/4.2 for now, or apply the attached patch and run "make > install" in /usr/src/gnu/usr.bin/cc/include. =C2=A0I'll commit a fix to > -current tonight. This is great, thank you very much. There's one more minor hiccup described here http://lists.freebsd.org/pipermail/freebsd-current/2011-March/023415.html This issue as of r220528 is not resolved. Regards From owner-freebsd-current@FreeBSD.ORG Thu Apr 14 13:20:06 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 6DB141065670; Thu, 14 Apr 2011 13:20:06 +0000 (UTC) Date: Thu, 14 Apr 2011 13:20:06 +0000 From: Alexander Best To: George Liaskos Message-ID: <20110414132006.GA49440@freebsd.org> References: <4DA6DF88.2040005@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Cc: kde@freebsd.org, freebsd-current@freebsd.org, Dimitry Andric Subject: Re: KDE related compile errors on CURRENT. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 13:20:06 -0000 On Thu Apr 14 11, George Liaskos wrote: > > You can just copy /usr/src/contrib/gcc/config/i386/tmmintrin.h to > > /usr/include/gcc/4.2 for now, or apply the attached patch and run "make > > install" in /usr/src/gnu/usr.bin/cc/include.  I'll commit a fix to > > -current tonight. > > This is great, thank you very much. > > There's one more minor hiccup described here > http://lists.freebsd.org/pipermail/freebsd-current/2011-March/023415.html > > This issue as of r220528 is not resolved. odd. r219697 should have taken care of that. maybe you might want to ping Martin Matuska? cheers. alex > > Regards -- a13x From owner-freebsd-current@FreeBSD.ORG Thu Apr 14 13:47:40 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3135C106564A; Thu, 14 Apr 2011 13:47:40 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id E00518FC0A; Thu, 14 Apr 2011 13:47:39 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:dd48:486e:166b:644] (unknown [IPv6:2001:7b8:3a7:0:dd48:486e:166b:644]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 289B95C59; Thu, 14 Apr 2011 15:47:39 +0200 (CEST) Message-ID: <4DA6FB0E.1000005@FreeBSD.org> Date: Thu, 14 Apr 2011 15:47:58 +0200 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.16pre) Gecko/20110319 Lanikai/3.1.10pre MIME-Version: 1.0 To: Alexander Best References: <4DA6DF88.2040005@FreeBSD.org> <20110414132006.GA49440@freebsd.org> In-Reply-To: <20110414132006.GA49440@freebsd.org> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Cc: George Liaskos , freebsd-current@freebsd.org, kde@freebsd.org Subject: Re: KDE related compile errors on CURRENT. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 13:47:40 -0000 On 2011-04-14 15:20, Alexander Best wrote: ... >> There's one more minor hiccup described here >> http://lists.freebsd.org/pipermail/freebsd-current/2011-March/023415.html >> >> This issue as of r220528 is not resolved. > > odd. r219697 should have taken care of that. maybe you might want to ping > Martin Matuska? It works fine here: $ gcc -### -march=native -S empty.c Using built-in specs. Target: i386-undermydesk-freebsd Configured with: FreeBSD/i386 system compiler Thread model: posix gcc version 4.2.2 20070831 prerelease [FreeBSD] "/usr/libexec/cc1" "-quiet" "-D_LONGLONG" "empty.c" "-march=core2" "-mtune=generic" "-quiet" "-dumpbase" "empty.c" "-auxbase" "empty" "-o" "empty.s" and also for clang: $ clang -### -march=native -S empty.c FreeBSD clang version 3.0 (trunk 129512) 20110414 Target: i386-undermydesk-freebsd9.0 Thread model: posix "/usr/bin/clang" "-cc1" "-triple" "i386-undermydesk-freebsd9.0" "-S" "-disable-free" "-main-file-name" "empty.c" "-mrelocation-model" "static" "-mdisable-fp-elim" "-masm-verbose" "-mconstructor-aliases" "-target-cpu" "corei7" "-momit-leaf-frame-pointer" "-resource-dir" "/usr/bin/../lib/clang/3.0" "-ferror-limit" "19" "-fmessage-length" "0" "-fgnu-runtime" "-fdiagnostics-show-option" "-o" "empty.s" "-x" "c" "empty.c" From owner-freebsd-current@FreeBSD.ORG Thu Apr 14 14:03:03 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 8EF311065670; Thu, 14 Apr 2011 14:03:03 +0000 (UTC) Date: Thu, 14 Apr 2011 14:03:03 +0000 From: Alexander Best To: Dimitry Andric Message-ID: <20110414140303.GA54786@freebsd.org> References: <4DA6DF88.2040005@FreeBSD.org> <20110414132006.GA49440@freebsd.org> <4DA6FB0E.1000005@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4DA6FB0E.1000005@FreeBSD.org> Cc: George Liaskos , freebsd-current@freebsd.org, kde@freebsd.org Subject: Re: KDE related compile errors on CURRENT. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 14:03:03 -0000 On Thu Apr 14 11, Dimitry Andric wrote: > On 2011-04-14 15:20, Alexander Best wrote: > ... > >>There's one more minor hiccup described here > >>http://lists.freebsd.org/pipermail/freebsd-current/2011-March/023415.html > >> > >>This issue as of r220528 is not resolved. > > > >odd. r219697 should have taken care of that. maybe you might want to ping > >Martin Matuska? > > It works fine here: for me too when using clang. i cannot say anything about base gcc because it's dated march 13th on my machine, which is before r219697 was committed. are you sure you are running a copy of base gcc built from a recent HEAD? cheers. alex > > $ gcc -### -march=native -S empty.c > Using built-in specs. > Target: i386-undermydesk-freebsd > Configured with: FreeBSD/i386 system compiler > Thread model: posix > gcc version 4.2.2 20070831 prerelease [FreeBSD] > "/usr/libexec/cc1" "-quiet" "-D_LONGLONG" "empty.c" "-march=core2" > "-mtune=generic" "-quiet" "-dumpbase" "empty.c" "-auxbase" "empty" "-o" > "empty.s" > > and also for clang: > > $ clang -### -march=native -S empty.c > FreeBSD clang version 3.0 (trunk 129512) 20110414 > Target: i386-undermydesk-freebsd9.0 > Thread model: posix > "/usr/bin/clang" "-cc1" "-triple" "i386-undermydesk-freebsd9.0" "-S" > "-disable-free" "-main-file-name" "empty.c" "-mrelocation-model" "static" > "-mdisable-fp-elim" "-masm-verbose" "-mconstructor-aliases" "-target-cpu" > "corei7" "-momit-leaf-frame-pointer" "-resource-dir" > "/usr/bin/../lib/clang/3.0" "-ferror-limit" "19" "-fmessage-length" "0" > "-fgnu-runtime" "-fdiagnostics-show-option" "-o" "empty.s" "-x" "c" > "empty.c" -- a13x From owner-freebsd-current@FreeBSD.ORG Thu Apr 14 14:22:33 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 693A01065675; Thu, 14 Apr 2011 14:22:33 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id 24AFB8FC1F; Thu, 14 Apr 2011 14:22:33 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:dd48:486e:166b:644] (unknown [IPv6:2001:7b8:3a7:0:dd48:486e:166b:644]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 0F2105C59; Thu, 14 Apr 2011 16:22:32 +0200 (CEST) Message-ID: <4DA7033C.3080408@FreeBSD.org> Date: Thu, 14 Apr 2011 16:22:52 +0200 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.16pre) Gecko/20110319 Lanikai/3.1.10pre MIME-Version: 1.0 To: Alexander Best References: <4DA6DF88.2040005@FreeBSD.org> <20110414132006.GA49440@freebsd.org> <4DA6FB0E.1000005@FreeBSD.org> <20110414140303.GA54786@freebsd.org> In-Reply-To: <20110414140303.GA54786@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: George Liaskos , freebsd-current@freebsd.org, kde@freebsd.org Subject: Re: KDE related compile errors on CURRENT. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 14:22:33 -0000 On 2011-04-14 16:03, Alexander Best wrote: ... > for me too when using clang. i cannot say anything about base gcc because it's > dated march 13th on my machine, which is before r219697 was committed. > > are you sure you are running a copy of base gcc built from a recent HEAD? Yep, built today from r220620. From owner-freebsd-current@FreeBSD.ORG Thu Apr 14 14:23:59 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id E4310106566B; Thu, 14 Apr 2011 14:23:59 +0000 (UTC) Date: Thu, 14 Apr 2011 14:23:59 +0000 From: Alexander Best To: Dimitry Andric Message-ID: <20110414142359.GA58940@freebsd.org> References: <4DA6DF88.2040005@FreeBSD.org> <20110414132006.GA49440@freebsd.org> <4DA6FB0E.1000005@FreeBSD.org> <20110414140303.GA54786@freebsd.org> <4DA7033C.3080408@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4DA7033C.3080408@FreeBSD.org> Cc: George Liaskos , freebsd-current@freebsd.org, kde@freebsd.org Subject: Re: KDE related compile errors on CURRENT. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 14:24:00 -0000 On Thu Apr 14 11, Dimitry Andric wrote: > On 2011-04-14 16:03, Alexander Best wrote: > ... > >for me too when using clang. i cannot say anything about base gcc because > >it's > >dated march 13th on my machine, which is before r219697 was committed. > > > >are you sure you are running a copy of base gcc built from a recent HEAD? > > Yep, built today from r220620. actually i meant George Liaskos, since he is having the issue. ;) -- a13x From owner-freebsd-current@FreeBSD.ORG Thu Apr 14 14:42:29 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E5C2D106566C; Thu, 14 Apr 2011 14:42:29 +0000 (UTC) (envelope-from geo.liaskos@gmail.com) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id 64E458FC17; Thu, 14 Apr 2011 14:42:29 +0000 (UTC) Received: by gyg13 with SMTP id 13so578928gyg.13 for ; Thu, 14 Apr 2011 07:42:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=+H9/nvlNXmVoAisTHL3tyjQ4X/rLqtreDhjUfHTG5VA=; b=LFExXqwC/nXjFMQBzDtZ9DrFegZ9aB8+kXP3w83KhhGcm5dZ7Owhv2WdtxwTI2w7DY FPFZKSXpAnN+1q2TYLp0iP3AnBjH2BNM8AlFOVjCQh+6rXMEM6NktTnSY6jxw6i1/8/e oWL5He1PkomayqisunHGMqAMopv1XyRWnYuDE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=cesOhmdD73RKVBnDIiN82GNdumN7ZByDOSy7XSOG+IzFA6s6CPu655pA+hhrjCQMCZ rNtM683HNG1PIXE5+0UXuoLea4ns1Ef4S5fwAqao41/QXbX92Lb2mipnojPpbY0hHRkv gGyONErqJ08SewnrroqfOvQgSKgCdcDYmWU/M= MIME-Version: 1.0 Received: by 10.101.208.8 with SMTP id k8mr488730anq.159.1302792148450; Thu, 14 Apr 2011 07:42:28 -0700 (PDT) Received: by 10.100.215.10 with HTTP; Thu, 14 Apr 2011 07:42:28 -0700 (PDT) In-Reply-To: <4DA6FB0E.1000005@FreeBSD.org> References: <4DA6DF88.2040005@FreeBSD.org> <20110414132006.GA49440@freebsd.org> <4DA6FB0E.1000005@FreeBSD.org> Date: Thu, 14 Apr 2011 17:42:28 +0300 Message-ID: From: George Liaskos To: Dimitry Andric Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Alexander Best , freebsd-current@freebsd.org, kde@freebsd.org Subject: Re: KDE related compile errors on CURRENT. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 14:42:30 -0000 > It works fine here: > > $ gcc -### -march=3Dnative -S empty.c > Using built-in specs. > Target: i386-undermydesk-freebsd > Configured with: FreeBSD/i386 system compiler > Thread model: posix > gcc version 4.2.2 20070831 prerelease [FreeBSD] > =C2=A0"/usr/libexec/cc1" "-quiet" "-D_LONGLONG" "empty.c" "-march=3Dcore2= " > "-mtune=3Dgeneric" "-quiet" "-dumpbase" "empty.c" "-auxbase" "empty" "-o" > "empty.s" It doesn't work for me on two different boxes 1. r220269: Sat Apr 2 19:15:49 EEST 2011, CPU: Intel(R) Core(TM)2 CPU 6700 @ 2.66GHz (2666.82-MHz K8-class CPU) cc -### -march=3Dnative -S foo.c Using built-in specs. Target: amd64-undermydesk-freebsd Configured with: FreeBSD/amd64 system compiler Thread model: posix gcc version 4.2.2 20070831 prerelease [FreeBSD] "/usr/libexec/cc1" "-quiet" "-D_LONGLONG" "foo.c" "-march=3Dnocona" "-mtune=3Dgeneric" "-quiet" "-dumpbase" "foo.c" "-auxbase" "foo" "-o" "foo.s" 2. r220528: Sun Apr 10 23:17:57 EEST 2011, CPU: Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz (2400.03-MHz K8-class CPU) cc -### -march=3Dnative -S foo.c Using built-in specs. Target: amd64-undermydesk-freebsd Configured with: FreeBSD/amd64 system compiler Thread model: posix gcc version 4.2.2 20070831 prerelease [FreeBSD] "/usr/libexec/cc1" "-quiet" "-D_LONGLONG" "foo.c" "-march=3Dnocona" "-mtune=3Dgeneric" "-quiet" "-dumpbase" "foo.c" "-auxbase" "foo" "-o" "foo.s" Anyone else on amd64? Regards From owner-freebsd-current@FreeBSD.ORG Thu Apr 14 15:31:45 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 89DA11065672; Thu, 14 Apr 2011 15:31:45 +0000 (UTC) Date: Thu, 14 Apr 2011 15:31:45 +0000 From: Alexander Best To: George Liaskos Message-ID: <20110414153145.GA68494@freebsd.org> References: <4DA6DF88.2040005@FreeBSD.org> <20110414132006.GA49440@freebsd.org> <4DA6FB0E.1000005@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Cc: kde@freebsd.org, freebsd-current@freebsd.org, Dimitry Andric Subject: Re: KDE related compile errors on CURRENT. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 15:31:45 -0000 On Thu Apr 14 11, George Liaskos wrote: > > It works fine here: > > > > $ gcc -### -march=native -S empty.c > > Using built-in specs. > > Target: i386-undermydesk-freebsd > > Configured with: FreeBSD/i386 system compiler > > Thread model: posix > > gcc version 4.2.2 20070831 prerelease [FreeBSD] > >  "/usr/libexec/cc1" "-quiet" "-D_LONGLONG" "empty.c" "-march=core2" > > "-mtune=generic" "-quiet" "-dumpbase" "empty.c" "-auxbase" "empty" "-o" > > "empty.s" > > It doesn't work for me on two different boxes > > 1. r220269: Sat Apr 2 19:15:49 EEST 2011, CPU: Intel(R) Core(TM)2 CPU > 6700 @ 2.66GHz (2666.82-MHz K8-class CPU) > cc -### -march=native -S foo.c > Using built-in specs. > Target: amd64-undermydesk-freebsd > Configured with: FreeBSD/amd64 system compiler > Thread model: posix > gcc version 4.2.2 20070831 prerelease [FreeBSD] > "/usr/libexec/cc1" "-quiet" "-D_LONGLONG" "foo.c" "-march=nocona" > "-mtune=generic" "-quiet" "-dumpbase" "foo.c" "-auxbase" "foo" "-o" > "foo.s" > > 2. r220528: Sun Apr 10 23:17:57 EEST 2011, CPU: Intel(R) Core(TM)2 > Quad CPU Q6600 @ 2.40GHz (2400.03-MHz K8-class CPU) > cc -### -march=native -S foo.c > Using built-in specs. > Target: amd64-undermydesk-freebsd > Configured with: FreeBSD/amd64 system compiler > Thread model: posix > gcc version 4.2.2 20070831 prerelease [FreeBSD] > "/usr/libexec/cc1" "-quiet" "-D_LONGLONG" "foo.c" "-march=nocona" > "-mtune=generic" "-quiet" "-dumpbase" "foo.c" "-auxbase" "foo" "-o" > "foo.s" > > Anyone else on amd64? could you give us the output of `ls -laT /usr/bin|grep gcc` and also can you send us the CU features which get reported? (dmesg -a) i think core2 only gets enabled with native, if sse3 was detected. maybe freebsd isn't properly detecting sse3 support for your cpu. i'll rebuild gcc later on and check whether i experience the same issue. cheers. alex > > Regards -- a13x From owner-freebsd-current@FreeBSD.ORG Thu Apr 14 15:46:12 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 5F153106566C; Thu, 14 Apr 2011 15:46:12 +0000 (UTC) Date: Thu, 14 Apr 2011 15:46:12 +0000 From: Alexander Best To: George Liaskos Message-ID: <20110414154612.GA70532@freebsd.org> References: <4DA6DF88.2040005@FreeBSD.org> <20110414132006.GA49440@freebsd.org> <4DA6FB0E.1000005@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Cc: kde@freebsd.org, freebsd-current@freebsd.org, Dimitry Andric Subject: Re: KDE related compile errors on CURRENT. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 15:46:12 -0000 On Thu Apr 14 11, George Liaskos wrote: > > It works fine here: > > > > $ gcc -### -march=native -S empty.c > > Using built-in specs. > > Target: i386-undermydesk-freebsd > > Configured with: FreeBSD/i386 system compiler > > Thread model: posix > > gcc version 4.2.2 20070831 prerelease [FreeBSD] > >  "/usr/libexec/cc1" "-quiet" "-D_LONGLONG" "empty.c" "-march=core2" > > "-mtune=generic" "-quiet" "-dumpbase" "empty.c" "-auxbase" "empty" "-o" > > "empty.s" > > It doesn't work for me on two different boxes > > 1. r220269: Sat Apr 2 19:15:49 EEST 2011, CPU: Intel(R) Core(TM)2 CPU > 6700 @ 2.66GHz (2666.82-MHz K8-class CPU) > cc -### -march=native -S foo.c > Using built-in specs. > Target: amd64-undermydesk-freebsd > Configured with: FreeBSD/amd64 system compiler > Thread model: posix > gcc version 4.2.2 20070831 prerelease [FreeBSD] > "/usr/libexec/cc1" "-quiet" "-D_LONGLONG" "foo.c" "-march=nocona" > "-mtune=generic" "-quiet" "-dumpbase" "foo.c" "-auxbase" "foo" "-o" > "foo.s" > > 2. r220528: Sun Apr 10 23:17:57 EEST 2011, CPU: Intel(R) Core(TM)2 > Quad CPU Q6600 @ 2.40GHz (2400.03-MHz K8-class CPU) > cc -### -march=native -S foo.c > Using built-in specs. > Target: amd64-undermydesk-freebsd > Configured with: FreeBSD/amd64 system compiler > Thread model: posix > gcc version 4.2.2 20070831 prerelease [FreeBSD] > "/usr/libexec/cc1" "-quiet" "-D_LONGLONG" "foo.c" "-march=nocona" > "-mtune=generic" "-quiet" "-dumpbase" "foo.c" "-auxbase" "foo" "-o" > "foo.s" > > Anyone else on amd64? i just rebuilt gcc and can verify your issue: otaku% pwd /usr/obj/usr/git-freebsd-head/gnu/usr.bin/cc/cc otaku% cc -### -march=native -S foo.c Using built-in specs. Target: amd64-undermydesk-freebsd Configured with: FreeBSD/amd64 system compiler Thread model: posix gcc version 4.2.2 20070831 prerelease [FreeBSD] "/usr/libexec/cc1" "-quiet" "-D_LONGLONG" "/home/arundel/test_fpu.c" "-march=nocona" "-mtune=generic" "-quiet" "-dumpbase" "test_fpu.c" "-auxbase" "test_fpu" "-o" "test_fpu.s" my CPU is: CPU: Intel(R) Pentium(R) Dual CPU E2160 @ 1.80GHz (1800.00-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x6fd Family = 6 Model = f Stepping = 13 Features=0xbfebfbff Features2=0xe39d AMD Features=0x20100800 AMD Features2=0x1 TSC: P-state invariant, performance statistics cheers. alex > > Regards -- a13x From owner-freebsd-current@FreeBSD.ORG Fri Apr 15 07:03:37 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E958C1065670 for ; Fri, 15 Apr 2011 07:03:36 +0000 (UTC) (envelope-from mrossi@swin.edu.au) Received: from gpo3.cc.swin.edu.au (gpo3.cc.swin.edu.au [136.186.1.32]) by mx1.freebsd.org (Postfix) with ESMTP id 8522A8FC0C for ; Fri, 15 Apr 2011 07:03:36 +0000 (UTC) Received: from mrossi.caia.swin.edu.au (mrossi.caia.swin.edu.au [136.186.229.109]) by gpo3.cc.swin.edu.au (8.14.3/8.14.3) with ESMTP id p3F6oU6P004205 for ; Fri, 15 Apr 2011 16:50:30 +1000 Message-ID: <4DA7EAB5.9090204@swin.edu.au> Date: Fri, 15 Apr 2011 16:50:29 +1000 From: Mattia Rossi User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.15) Gecko/20110406 Thunderbird/3.1.9 MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: IPv6 tunnel problem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 07:03:37 -0000 Hi all, I'm having some trouble with my IPv6 tunnel lately (net/gateway6 port). I'm running revision 220613. The tunnel runs fine on 8.2, I can ping6 ipv6.google.com from all interfaces using all IPv6 addresses. Route Advertisements are sent, Linux Machines, Mac OS X machiens and FreeBSD 8.2/8.1 machines are all receiveing the advertisements and are able to ping and use the IPv6 network. On the machines running CURRENT anyhow, route advertisements don't work. They arrive at the interface, but nothing happens. If i set up an IPv6 address and route by hand, I don't get anywhere, as it's permanently marked as "tentative", and trying to use that address as source address in ping6 results in: ping6: bind: Can't assign requested address This brings me to my main problem: the tunnel. If I set up a tunnel on a CURRENT machine, the tunnel gets set up (because it's IPv4) but the IPv6 part does not work. I'm not able to send pings (which means KEEPALIVES are not sent either), so it just doesn't work. I'm using IPv6 in UDP over IPv4 tunneling, as that's what I use on the 8.2 machine as well. The error when trying to ping on the CURRENT machine where the tunnel runs( for the short period the tunnel is up) is: ping6: sendmsg: Network is down Route advertisements are not sent either, as again, the IPv6 address assigned to the interface by the tunnel is marked as tentative, so rtadvd refuses to work. Something is badly broken with IPv6 and/or NDP. More info about the systems: Interfaces in use on the machines running CURRENT: bge0 and em0 Interfaces on the working 8.2 machine: fxp0 and em0 sysctls on the broken machines when in router mode: net.inet6.ip6.forwarding: 1 net.inet6.ip6.redirect: 1 net.inet6.ip6.hlim: 64 net.inet6.ip6.maxfragpackets: 6400 net.inet6.ip6.accept_rtadv: 0 net.inet6.ip6.keepfaith: 0 net.inet6.ip6.log_interval: 5 net.inet6.ip6.hdrnestlimit: 15 net.inet6.ip6.dad_count: 1 net.inet6.ip6.auto_flowlabel: 1 net.inet6.ip6.defmcasthlim: 1 net.inet6.ip6.gifhlim: 30 net.inet6.ip6.kame_version: FreeBSD net.inet6.ip6.use_deprecated: 1 net.inet6.ip6.rr_prune: 5 net.inet6.ip6.v6only: 1 net.inet6.ip6.rtexpire: 3600 net.inet6.ip6.rtminexpire: 10 net.inet6.ip6.rtmaxcache: 128 net.inet6.ip6.use_tempaddr: 0 net.inet6.ip6.temppltime: 86400 net.inet6.ip6.tempvltime: 604800 net.inet6.ip6.auto_linklocal: 1 net.inet6.ip6.prefer_tempaddr: 0 net.inet6.ip6.use_defaultzone: 0 net.inet6.ip6.maxfrags: 6400 net.inet6.ip6.mcast_pmtu: 0 net.inet6.ip6.mcast.loop: 1 net.inet6.ip6.mcast.maxsocksrc: 128 net.inet6.ip6.mcast.maxgrpsrc: 512 security.jail.param.ip6.saddrsel: 0 security.jail.param.ip6.: 0 on the working machine router mode: net.inet6.ip6.forwarding: 1 net.inet6.ip6.redirect: 1 net.inet6.ip6.hlim: 64 net.inet6.ip6.maxfragpackets: 6400 net.inet6.ip6.accept_rtadv: 0 net.inet6.ip6.keepfaith: 0 net.inet6.ip6.log_interval: 5 net.inet6.ip6.hdrnestlimit: 15 net.inet6.ip6.dad_count: 1 net.inet6.ip6.auto_flowlabel: 1 net.inet6.ip6.defmcasthlim: 1 net.inet6.ip6.gifhlim: 30 net.inet6.ip6.kame_version: FreeBSD net.inet6.ip6.use_deprecated: 1 net.inet6.ip6.rr_prune: 5 net.inet6.ip6.v6only: 1 net.inet6.ip6.rtexpire: 3600 net.inet6.ip6.rtminexpire: 10 net.inet6.ip6.rtmaxcache: 128 net.inet6.ip6.use_tempaddr: 0 net.inet6.ip6.temppltime: 86400 net.inet6.ip6.tempvltime: 604800 net.inet6.ip6.auto_linklocal: 1 net.inet6.ip6.prefer_tempaddr: 0 net.inet6.ip6.use_defaultzone: 0 net.inet6.ip6.maxfrags: 6400 net.inet6.ip6.mcast_pmtu: 0 net.inet6.ip6.mcast.loop: 1 net.inet6.ip6.mcast.maxsocksrc: 128 net.inet6.ip6.mcast.maxgrpsrc: 512 If they're not routers: net.inet6.ip6.forwarding: 0 net.inet6.ip6.redirect: 0 net.inet6.ip6.accept_rtadv: 1 And on the interfaces ifconfig em0 inet6 accept_rtadv And finally I have a question: Why is there a net.inet6.ip6.accept_rtadv sysctl? If we have to enable/disable route advertisements per interface, this sysctl shouldn't be there at all. Immagine a system (like mine) where you have multiple interfaces, and which acts as IPv6 router amongst other stuff. Shouldn't you be able to deactivate route advertisements on one interface, which is where route advertisements are sent from, but enable it on the other ones, so you don't need to statically configure them? If there's a sysctl, you'll disable and enable route advertisements for the whole machine, so the per interface stuff is useless, or am I wrong? Mat From owner-freebsd-current@FreeBSD.ORG Fri Apr 15 07:54:20 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 44A161065675 for ; Fri, 15 Apr 2011 07:54:20 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id F38178FC16 for ; Fri, 15 Apr 2011 07:54:19 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1QAdr8-00072L-4D for freebsd-current@freebsd.org; Fri, 15 Apr 2011 09:54:18 +0200 Received: from l.saper.info ([91.121.203.103]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 15 Apr 2011 09:54:18 +0200 Received: from saper by l.saper.info with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 15 Apr 2011 09:54:18 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Marcin Cieslak Date: Fri, 15 Apr 2011 07:54:05 +0000 (UTC) Organization: http://saper.info Lines: 18 Message-ID: References: <4DA7EAB5.9090204@swin.edu.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: l.saper.info User-Agent: slrn/0.9.9p1 (FreeBSD) Subject: Re: IPv6 tunnel problem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 07:54:20 -0000 >> Mattia Rossi wrote: > fxp0 and em0 Can you show us what does "ifconfig" say on your interfaces? There are few parameters for the ICMPv6 Neighbor Discovery Protocol that might be needed: "ifconfig em0 inet6 accept_rtadv" Those are nicely documented in ifconfig(8). This is usually handled by the /etc/rc.d/* stuff IF you have a current version of /etc/rc.conf settings. (They changed a bit in the meantime). //Marcin From owner-freebsd-current@FreeBSD.ORG Fri Apr 15 13:30:33 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 37319106564A for ; Fri, 15 Apr 2011 13:30:33 +0000 (UTC) (envelope-from mrossi@swin.edu.au) Received: from gpo1.cc.swin.edu.au (gpo1.cc.swin.edu.au [136.186.1.30]) by mx1.freebsd.org (Postfix) with ESMTP id C58678FC14 for ; Fri, 15 Apr 2011 13:30:32 +0000 (UTC) Received: from mrossi.caia.swin.edu.au (mrossi.caia.swin.edu.au [136.186.229.109]) by gpo1.cc.swin.edu.au (8.14.3/8.14.3) with ESMTP id p3FDUUxG015656; Fri, 15 Apr 2011 23:30:31 +1000 Message-ID: <4DA84876.9020402@swin.edu.au> Date: Fri, 15 Apr 2011 23:30:30 +1000 From: Mattia Rossi User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.15) Gecko/20110406 Thunderbird/3.1.9 MIME-Version: 1.0 To: Marcin Cieslak References: <4DA7EAB5.9090204@swin.edu.au> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: IPv6 tunnel problem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 13:30:33 -0000 I have accept_rtadv enabled if it's not a router. See my post. ifconfig with tunnel up is: ifconfig bge0: flags=8843 metric 0 mtu 1500 options=8009b ether 00:0d:9d:51:d4:7e inet 136.186.229.112 netmask 0xffffff00 broadcast xxx.xxx.xxx.xxx inet6 fe80::xxxx:xxxx:xxxx:xxxx%bge0 prefixlen 64 scopeid 0x5 inet6 xxxx:xxxx:xxxx:xxxx::xxxx prefixlen 64 duplicated nd6 options=23 media: Ethernet autoselect (1000baseT ) status: active fxp0: flags=8802 metric 0 mtu 1500 options=4219b ether 00:02:b3:eb:28:b0 media: Ethernet autoselect (none) status: no carrier plip0: flags=8810 metric 0 mtu 1500 lo0: flags=8049 metric 0 mtu 16384 options=3 inet 127.0.0.1 netmask 0xff000000 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x8 nd6 options=21 tun0: flags=8051 metric 0 mtu 1280 options=80000 inet6 fe80::xxxx:xxxx:xxxx:xxxx%tun0 prefixlen 64 scopeid 0x9 inet6 xxxx:xxxx:xxxx::xxxx --> xxxx:xxxx:xxxx::xxxx prefixlen 128 nd6 options=29 Opened by PID 17726 I canceled the address in case you wonder. Mat On 15/04/2011 17:54, Marcin Cieslak wrote: >>> Mattia Rossi wrote: >> fxp0 and em0 > > Can you show us what does "ifconfig" say on > your interfaces? There are few parameters > for the ICMPv6 Neighbor Discovery Protocol > that might be needed: > "ifconfig em0 inet6 accept_rtadv" > > Those are nicely documented in ifconfig(8). > > This is usually handled by the /etc/rc.d/* > stuff IF you have a current version of > /etc/rc.conf settings. (They changed a bit > in the meantime). > > //Marcin > > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Fri Apr 15 13:58:17 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 39923106564A for ; Fri, 15 Apr 2011 13:58:17 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id B41638FC14 for ; Fri, 15 Apr 2011 13:58:16 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1QAjXL-0003T6-5w for freebsd-current@freebsd.org; Fri, 15 Apr 2011 15:58:15 +0200 Received: from l.saper.info ([91.121.203.103]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 15 Apr 2011 15:58:15 +0200 Received: from saper by l.saper.info with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 15 Apr 2011 15:58:15 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Marcin Cieslak Date: Fri, 15 Apr 2011 13:58:03 +0000 (UTC) Organization: http://saper.info Lines: 55 Message-ID: References: <4DA7EAB5.9090204@swin.edu.au> <4DA84876.9020402@swin.edu.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: l.saper.info User-Agent: slrn/0.9.9p1 (FreeBSD) Subject: Re: IPv6 tunnel problem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 13:58:17 -0000 >> Mattia Rossi wrote: > I have accept_rtadv enabled if it's not a router. See my post. I think I have a similar setup (only using sixxs-aiccu). Since my machine is a gateway to the outside IPv6 world (via www.sixxs.net) I am not accepting router adverisements there, but I'm running rtadvd and sending them to other hosts on the LAN: nd6 options=21 > ifconfig with tunnel up is: > > ifconfig > bge0: flags=8843 metric 0 mtu 1500 > > options=8009b > ether 00:0d:9d:51:d4:7e > inet 136.186.229.112 netmask 0xffffff00 broadcast xxx.xxx.xxx.xxx > inet6 fe80::xxxx:xxxx:xxxx:xxxx%bge0 prefixlen 64 scopeid 0x5 > inet6 xxxx:xxxx:xxxx:xxxx::xxxx prefixlen 64 duplicated ********** what's up here? > nd6 options=23 > media: Ethernet autoselect (1000baseT ) > status: active Why is this address "duplicated"? If this machine *is* the gateway to the outside IPv6 world, should *not* it be accepting rtadv and have a global IPv6 address configured statically > tun0: flags=8051 metric 0 mtu 1280 > options=80000 > inet6 fe80::xxxx:xxxx:xxxx:xxxx%tun0 prefixlen 64 scopeid 0x9 > inet6 xxxx:xxxx:xxxx::xxxx --> xxxx:xxxx:xxxx::xxxx prefixlen 128 > nd6 options=29 ********** Does "ifconfig tun0 inet6 -ifdisabled" help? I don't know why gateway6 (I don't use this software) leaves it as "IFDISABLED" This is /etc/rc.conf from my tunnel gateway machine (two tunnels, tun0 and tun1) - it runs a few-month-old -CURRENT: ipv6_gateway_enable="YES" rtadvd_enable="YES" # Internal WLAN rtadvd_interfaces="wlan0" ifconfig_wlan0_ipv6="inet6 aaaaa:bbbb:cccc::1/64" # Tunnel via tun0 is configured automatically by aiccu # and has NO /etc/rc.conf entry at all # Tunnel via tun1 is configured statically (it serves only some networks) ifconfig_tun1_ipv6="inet6 aaaaa:bbbb:cccc:8000::1" //Marcin From owner-freebsd-current@FreeBSD.ORG Fri Apr 15 15:28:08 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 711C61065673; Fri, 15 Apr 2011 15:28:08 +0000 (UTC) (envelope-from gkontos.mail@gmail.com) Received: from mail-gw0-f54.google.com (mail-gw0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id 1E1598FC18; Fri, 15 Apr 2011 15:28:07 +0000 (UTC) Received: by gwb15 with SMTP id 15so1393769gwb.13 for ; Fri, 15 Apr 2011 08:28:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=C92CY4cS/9jLfoyko+5GUz4zltuMes9Gaudai+8hby8=; b=Kck7W5Qp5/JPRevmUD471JDO8HAOAFTQQg+fOlxy6ZIRWCGuwaYyLCXosBSj/y8VAe kG0JEo2AfwS0kkgANbe++R7CD8uEUZqlOziYjXWK4UmYLnTYnNCmgeHiMPIJRDlgw85M ybCd9MczIc+M7b8aWNM2US+TIzFtHfAzaRNqs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=c+mAh99GNMQqMjHZnoXj7y3AQoJ1Dl/xNNY77JhChJUXf1xVQdLJAo5UTF41FxoFf6 ylOO/RIZS8p6NmmEjac6xZyDTfGjf85kVnbskYktPWtp8PBUQcpzbNeUMPpxpPH0FOip Rrdpramg1js0bZgAwtRGXFZOzGrgLitfILaJY= MIME-Version: 1.0 Received: by 10.42.220.70 with SMTP id hx6mr2855704icb.322.1302881287184; Fri, 15 Apr 2011 08:28:07 -0700 (PDT) Received: by 10.231.11.196 with HTTP; Fri, 15 Apr 2011 08:28:07 -0700 (PDT) Date: Fri, 15 Apr 2011 18:28:07 +0300 Message-ID: From: George Kontostanos To: freebsd-stable@freebsd.org, freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: ZFS V28 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 15:28:08 -0000 I was wondering if ZFS v28 is going to be MFC to 8-Stable or not. Regards, -- George Kontostanos aisecure.net From owner-freebsd-current@FreeBSD.ORG Fri Apr 15 16:42:42 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4FA331065672; Fri, 15 Apr 2011 16:42:42 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 248278FC13; Fri, 15 Apr 2011 16:42:42 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id CC3E146BA1; Fri, 15 Apr 2011 12:42:41 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 645D78A02A; Fri, 15 Apr 2011 12:42:41 -0400 (EDT) From: John Baldwin To: David Naylor Date: Fri, 15 Apr 2011 12:28:06 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110325; KDE/4.5.5; amd64; ; ) References: <4DA4B247.6010901@FreeBSD.org> <201104131907.12368.naylor.b.david@gmail.com> In-Reply-To: <201104131907.12368.naylor.b.david@gmail.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201104151228.06105.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Fri, 15 Apr 2011 12:42:41 -0400 (EDT) Cc: Alexander Motin , FreeBSD-Current Subject: Re: [regression] unable to boot: no GEOM devices found. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 16:42:42 -0000 On Wednesday, April 13, 2011 1:07:06 pm David Naylor wrote: > On Tuesday 12 April 2011 22:12:55 Alexander Motin wrote: > > David Naylor wrote: > > > On Tuesday 12 April 2011 08:17:51 Alexander Motin wrote: > > >> David Naylor wrote: > > >>> I am running -current and since a few days ago (at least 2011/04/11) I > > >>> am unable to boot. > > >>> > > >>> The boot process stops when it looks to find a bootable device. The > > >>> prompt (when pressing '?') does not display any device and yielding one > > >>> second (or more) to the kernel (by pressing '.') does not improve the > > >>> situation. > > >>> > > >>> A known working date is 2011/02/20. > > >>> > > >>> I am running amd64 on a nVidia MCP51 chipset. > > >> > > >> MCP51... again... > > > > +ata2: reiniting channel .. > > +ata2: SATA connect time=0ms status=00000113 > > +ata2: reset tp1 mask=01 ostat0=58 ostat1=00 > > +ata2: stat0=0x50 err=0x01 lsb=0x00 msb=0x00 > > +ata2: reset tp2 stat0=50 stat1=00 devices=0x1 > > +ata2: reinit done .. > > +unknown: FAILURE - ATA_IDENTIFY timed out LBA=0 > > > > As soon as all devices detected but not responding to commands, I would > > suppose that there is something wrong with ATA interrupts. There is a > > long chain of interrupt problems in this chipset. I have already tried > > to debug one case where ATA wasn't generating interrupts at all. > > Unfortunately, without success -- requests were executing, but not > > generating interrupts, it wasn't looked like ATA driver problem. > > > > What's about possible candidate to revision triggering your problem, I > > would look on this message: > > +pcib0: Enabling MSI window for HyperTransport slave at pci0:0:9:0 > > > > At least it is recent (SVN revs 219737,219740 on 2011-03-18 by jhb) and > > it is interrupt related. > > I reverted those two revs and everything works again. Hmm, can you provide a full boot verbose dmesg? Alternatively, can you see if the device at pci0:0:9:0 is a PCI-PCI bridge? -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Fri Apr 15 19:20:23 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D8A8C106566C for ; Fri, 15 Apr 2011 19:20:23 +0000 (UTC) (envelope-from elon@emmi.physik-pool.tu-berlin.de) Received: from emmi.physik-pool.tu-berlin.de (emmi.physik-pool.tu-berlin.de [130.149.58.146]) by mx1.freebsd.org (Postfix) with ESMTP id 5DA3B8FC1A for ; Fri, 15 Apr 2011 19:20:22 +0000 (UTC) Received: from emmi.physik-pool.tu-berlin.de (localhost.physik-pool.tu-berlin.de [127.0.0.1]) by emmi.physik-pool.tu-berlin.de (8.14.4/8.14.4) with ESMTP id p3FImOq4072387; Fri, 15 Apr 2011 20:48:24 +0200 (CEST) (envelope-from elon@emmi.physik-pool.tu-berlin.de) Received: (from elon@localhost) by emmi.physik-pool.tu-berlin.de (8.14.4/8.14.4/Submit) id p3FImO32072386; Fri, 15 Apr 2011 20:48:24 +0200 (CEST) (envelope-from elon) Date: Fri, 15 Apr 2011 20:48:24 +0200 From: Leon =?iso-8859-15?Q?Me=DFner?= To: George Kontostanos Message-ID: <20110415184823.GH9116@emmi.physik-pool.tu-berlin.de> Mail-Followup-To: George Kontostanos , freebsd-stable@freebsd.org, freebsd-current@freebsd.org References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) X-Mailman-Approved-At: Fri, 15 Apr 2011 20:07:22 +0000 Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: Re: ZFS V28 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 19:20:23 -0000 On Fri, Apr 15, 2011 at 06:28:07PM +0300, George Kontostanos wrote: > I was wondering if ZFS v28 is going to be MFC to 8-Stable or not. On Fri, Apr 15, 2011 at 06:28:07PM +0300, George Kontostanos wrote: > I was wondering if ZFS v28 is going to be MFC to 8-Stable or not. Is there a recent patch against stable sources ? I tried the following: http://people.freebsd.org/~mm/patches/zfs/v28/stable-8-zfsv28-20110317.patch.xz This patch failes at sys/cddl/compat/opensolaris/sys/sysmacros.h which i think should just be deleted. I tried deleting this file and then building produces some errors then walls of text and then aborts. The first errors look like this: Script started on Fri Apr 15 18:32:36 2011 make -j 6 buildworld "/usr/share/mk/bsd.prog.mk", line 128: warning: duplicate script for target "_EXTRADEPEND" ignored "Makefile", line 222: warning: duplicate script for target "clean" ignored "Makefile", line 222: warning: duplicate script for target "cleandepend" ignored "Makefile", line 222: warning: duplicate script for target "distribute" ignored "Makefile", line 222: warning: duplicate script for target "lint" ignored "Makefile", line 222: warning: duplicate script for target "obj" ignored "Makefile", line 222: warning: duplicate script for target "objlink" ignored "Makefile", line 222: warning: duplicate script for target "tags" ignored "Makefile", line 222: warning: duplicate script for target "files" ignored "Makefile", line 222: warning: duplicate script for target "includes" ignored -------------------------------------------------------------- >>> World build started on Fri Apr 15 18:32:36 UTC 2011 -------------------------------------------------------------- cherio, Leon > Regards, From owner-freebsd-current@FreeBSD.ORG Fri Apr 15 21:30:23 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6293D10656D6; Fri, 15 Apr 2011 21:30:23 +0000 (UTC) (envelope-from naylor.b.david@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 8A90E8FC08; Fri, 15 Apr 2011 21:30:22 +0000 (UTC) Received: by wyf23 with SMTP id 23so3133198wyf.13 for ; Fri, 15 Apr 2011 14:30:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:from:to:subject:date:user-agent:cc:references :in-reply-to:mime-version:content-type:content-transfer-encoding :message-id; bh=BAXfHEu3jXYnjwyUDgQ5W0utNs8NGnVt/ILmtanqIvY=; b=AAu8i2UCe4WGnEV+z30o8VkC0Oyt3TRYRmLjTsFw4PIcXBoBFPj+trbiz6TrnUJSq4 2Vn4C7Hd6zkdCDiZQTUG8zocJzHo8HSxe1834ynEU9yuKnbN9eCycoxNpq6ASUF9lTwO D9luoeW6nnsjJvmklYut0bAEpAuTJVL/UPbLM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; b=diRM7tXH8xgA87Z8KoA61hvUIbQ6/zCAL55Nvp/qJr9LgaslnHO+LXWpKs7tKTnOIp HqQj5SrLbM2hLmEvpAcGvu5OFbiR6qHhqMl0yiob/SCinmtnmd6rUKTan/5kqG1LQ/ec 7AxkRsMn60fLe6uAdB0smajmm9I9FbPI/JqjI= Received: by 10.227.153.145 with SMTP id k17mr2447050wbw.18.1302903021012; Fri, 15 Apr 2011 14:30:21 -0700 (PDT) Received: from dragon.dg (41-132-133-242.dsl.mweb.co.za [41.132.133.242]) by mx.google.com with ESMTPS id b20sm1846381wbb.33.2011.04.15.14.30.14 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 15 Apr 2011 14:30:19 -0700 (PDT) From: David Naylor To: John Baldwin Date: Fri, 15 Apr 2011 23:29:55 +0200 User-Agent: KMail/1.13.5 (FreeBSD/9.0-CURRENT; KDE/4.6.1; amd64; ; ) References: <201104131907.12368.naylor.b.david@gmail.com> <201104151228.06105.jhb@freebsd.org> In-Reply-To: <201104151228.06105.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart9654497.r4CEEp21uq"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201104152329.59294.naylor.b.david@gmail.com> Cc: Alexander Motin , FreeBSD-Current Subject: Re: [regression] unable to boot: no GEOM devices found. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 21:30:23 -0000 --nextPart9654497.r4CEEp21uq Content-Type: multipart/mixed; boundary="Boundary-01=_TjLqNZHKjZ9td1f" Content-Transfer-Encoding: 7bit --Boundary-01=_TjLqNZHKjZ9td1f Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Friday 15 April 2011 18:28:06 John Baldwin wrote: > On Wednesday, April 13, 2011 1:07:06 pm David Naylor wrote: > > On Tuesday 12 April 2011 22:12:55 Alexander Motin wrote: > > > David Naylor wrote: > > > > On Tuesday 12 April 2011 08:17:51 Alexander Motin wrote: > > > >> David Naylor wrote: > > > >>> I am running -current and since a few days ago (at least > > > >>> 2011/04/11) I am unable to boot. > > > >>>=20 > > > >>> The boot process stops when it looks to find a bootable device.=20 > > > >>> The prompt (when pressing '?') does not display any device and > > > >>> yielding >=20 > one >=20 > > > >>> second (or more) to the kernel (by pressing '.') does not improve > > > >>> the situation. > > > >>>=20 > > > >>> A known working date is 2011/02/20. > > > >>>=20 > > > >>> I am running amd64 on a nVidia MCP51 chipset. > > > >>=20 > > > >> MCP51... again... > > >=20 > > > +ata2: reiniting channel .. > > > +ata2: SATA connect time=3D0ms status=3D00000113 > > > +ata2: reset tp1 mask=3D01 ostat0=3D58 ostat1=3D00 > > > +ata2: stat0=3D0x50 err=3D0x01 lsb=3D0x00 msb=3D0x00 > > > +ata2: reset tp2 stat0=3D50 stat1=3D00 devices=3D0x1 > > > +ata2: reinit done .. > > > +unknown: FAILURE - ATA_IDENTIFY timed out LBA=3D0 > > >=20 > > > As soon as all devices detected but not responding to commands, I wou= ld > > > suppose that there is something wrong with ATA interrupts. There is a > > > long chain of interrupt problems in this chipset. I have already tried > > > to debug one case where ATA wasn't generating interrupts at all. > > > Unfortunately, without success -- requests were executing, but not > > > generating interrupts, it wasn't looked like ATA driver problem. > > >=20 > > > What's about possible candidate to revision triggering your problem, I > > > would look on this message: > > > +pcib0: Enabling MSI window for HyperTransport slave at pci0:0:9:0 > > >=20 > > > At least it is recent (SVN revs 219737,219740 on 2011-03-18 by jhb) a= nd > > > it is interrupt related. > >=20 > > I reverted those two revs and everything works again. >=20 > Hmm, can you provide a full boot verbose dmesg? Alternatively, can you s= ee > if the device at pci0:0:9:0 is a PCI-PCI bridge? I can provide a verbose dmesg if the following is not enough: none17@pci0:0:9:0: class=3D0x050000 card=3D0x50011458 chip=3D0x027010d= e=20 rev=3D0xa2 hdr=3D0x00 vendor =3D 'NVIDIA Corporation' device =3D 'MCP51 Host Bridge' class =3D memory subclass =3D RAM I see two PCI-PCI bridges at pci0:0:3:0 and pci0:0:16:0. I've attached the= =20 full `pciconf -lv` output. =20 --Boundary-01=_TjLqNZHKjZ9td1f Content-Type: text/plain; charset="ISO-8859-1"; name="pciconf.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="pciconf.txt" hostb0@pci0:0:0:0: class=0x060000 card=0x00000000 chip=0x03a310de rev=0xa2 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'C55 Host Bridge' class = bridge subclass = HOST-PCI none0@pci0:0:0:1: class=0x050000 card=0x00000000 chip=0x03ac10de rev=0xa1 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'C55 Memory Controller' class = memory subclass = RAM none1@pci0:0:0:2: class=0x050000 card=0x00000000 chip=0x03aa10de rev=0xa1 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'C55 Memory Controller' class = memory subclass = RAM none2@pci0:0:0:3: class=0x050000 card=0x00000000 chip=0x03a910de rev=0xa1 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'C55 Memory Controller' class = memory subclass = RAM none3@pci0:0:0:4: class=0x050000 card=0x00000000 chip=0x03ab10de rev=0xa1 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'C55 Memory Controller' class = memory subclass = RAM none4@pci0:0:0:5: class=0x050000 card=0x00000000 chip=0x03a810de rev=0xa2 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'C55 Memory Controller' class = memory subclass = RAM none5@pci0:0:0:6: class=0x050000 card=0x00000000 chip=0x03b510de rev=0xa1 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'C55 Memory Controller' class = memory subclass = RAM none6@pci0:0:0:7: class=0x050000 card=0x00000000 chip=0x03b410de rev=0xa1 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'C55 Memory Controller' class = memory subclass = RAM none7@pci0:0:1:0: class=0x050000 card=0x00000000 chip=0x03ad10de rev=0xa1 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'C55 Memory Controller' class = memory subclass = RAM none8@pci0:0:1:1: class=0x050000 card=0x00000000 chip=0x03ae10de rev=0xa1 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'C55 Memory Controller' class = memory subclass = RAM none9@pci0:0:1:2: class=0x050000 card=0x00000000 chip=0x03af10de rev=0xa1 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'C55 Memory Controller' class = memory subclass = RAM none10@pci0:0:1:3: class=0x050000 card=0x00000000 chip=0x03b010de rev=0xa1 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'C55 Memory Controller' class = memory subclass = RAM none11@pci0:0:1:4: class=0x050000 card=0x00000000 chip=0x03b110de rev=0xa1 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'C55 Memory Controller' class = memory subclass = RAM none12@pci0:0:1:5: class=0x050000 card=0x00000000 chip=0x03b210de rev=0xa1 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'C55 Memory Controller' class = memory subclass = RAM none13@pci0:0:1:6: class=0x050000 card=0x00000000 chip=0x03b310de rev=0xa1 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'C55 Memory Controller' class = memory subclass = RAM none14@pci0:0:2:0: class=0x050000 card=0x00000000 chip=0x03b610de rev=0xa1 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'C55 Memory Controller' class = memory subclass = RAM none15@pci0:0:2:1: class=0x050000 card=0x00000000 chip=0x03bc10de rev=0xa1 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'C55 Memory Controller' class = memory subclass = RAM none16@pci0:0:2:2: class=0x050000 card=0x00000000 chip=0x03ba10de rev=0xa1 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'C55 Memory Controller' class = memory subclass = RAM pcib1@pci0:0:3:0: class=0x060400 card=0x0c5510de chip=0x03b710de rev=0xa1 hdr=0x01 vendor = 'NVIDIA Corporation' device = 'C55 PCIe bridge' class = bridge subclass = PCI-PCI none17@pci0:0:9:0: class=0x050000 card=0x50011458 chip=0x027010de rev=0xa2 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'MCP51 Host Bridge' class = memory subclass = RAM isab0@pci0:0:10:0: class=0x060100 card=0x50011458 chip=0x026010de rev=0xa3 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'MCP51 LPC Bridge' class = bridge subclass = PCI-ISA none18@pci0:0:10:1: class=0x0c0500 card=0x02641458 chip=0x026410de rev=0xa3 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'NVIDIA nForce PCI System Management (NVIDIA SMB Bus Controller)' class = serial bus subclass = SMBus none19@pci0:0:10:2: class=0x050000 card=0x02641458 chip=0x027210de rev=0xa3 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'MCP51 Memory Controller 0' class = memory subclass = RAM ohci0@pci0:0:11:0: class=0x0c0310 card=0x50041458 chip=0x026d10de rev=0xa3 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'MCP51 USB Controller' class = serial bus subclass = USB ehci0@pci0:0:11:1: class=0x0c0320 card=0x50041458 chip=0x026e10de rev=0xa3 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'MCP51 USB Controller' class = serial bus subclass = USB atapci0@pci0:0:13:0: class=0x01018a card=0xb0001458 chip=0x026510de rev=0xa1 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'MCP51 Parallel ATA Controller' class = mass storage subclass = ATA atapci1@pci0:0:14:0: class=0x010185 card=0xb0021458 chip=0x026610de rev=0xa1 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'NVIDIA nForce 430/410 Serial ATA Controller (MCP51S)' class = mass storage subclass = ATA pcib2@pci0:0:16:0: class=0x060401 card=0xcb8410de chip=0x026f10de rev=0xa2 hdr=0x01 vendor = 'NVIDIA Corporation' device = 'MCP51 PCI Bridge' class = bridge subclass = PCI-PCI hdac0@pci0:0:16:1: class=0x040300 card=0xa0021458 chip=0x026c10de rev=0xa2 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'High Definition Audio Controller (MCP51)' class = multimedia subclass = HDA nfe0@pci0:0:20:0: class=0x068000 card=0xe0001458 chip=0x026910de rev=0xa3 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'MCP51 Network Bus Enumerator' class = bridge vgapci0@pci0:1:0:0: class=0x030000 card=0x00000000 chip=0x039110de rev=0xa1 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'NVIDIA GeForce 7600 GT (G73)' class = display subclass = VGA dc0@pci0:2:7:0: class=0x020000 card=0xa25510b8 chip=0x12161113 rev=0x11 hdr=0x00 vendor = 'Accton Technology Corporation' device = 'EN-5251 Based Fast Ethernet Adapter' class = network subclass = ethernet --Boundary-01=_TjLqNZHKjZ9td1f-- --nextPart9654497.r4CEEp21uq Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (FreeBSD) iEYEABECAAYFAk2ouNcACgkQUaaFgP9pFrJMFQCeIJGNZ5yjDqrPVUf+XirNH6sd jM0AnAp9kMPWqSjsuwN0TNSRvnXW9aqv =paXl -----END PGP SIGNATURE----- --nextPart9654497.r4CEEp21uq-- From owner-freebsd-current@FreeBSD.ORG Fri Apr 15 23:26:36 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0CB151065670; Fri, 15 Apr 2011 23:26:36 +0000 (UTC) (envelope-from gkontos.mail@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id B51658FC08; Fri, 15 Apr 2011 23:26:35 +0000 (UTC) Received: by iwn33 with SMTP id 33so3280627iwn.13 for ; Fri, 15 Apr 2011 16:26:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=fmasJWAWi4q/nJfhT2lpqS23Md3RRZOqsngssJ9aQlY=; b=V/BaQ+5nG1tHgR8SFEPMS8nw1cNSsx3Ov5eEObCMxR+dtf18VkxMZCTl/nJ61gQa+B 3pU2LwwCl3M89/N0kpL7b3mvz3G5qtqJftMhxyvTpqyO3tmNZ2IjQktKoCvIepQzzVKM oyf9mfH/jT7+XXVWzHB7+0gXMMesrZntMMLW8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=OrzscBj3Ct3uZevPl/KQntTS4tyNVmWWmEQXie/mRuzIBasfi/yhvyNhm0biXESc0x k5l5cfO3UmiDtMnnccirMnpPOM2MGKcSXbvypJgcd/cXRJcrS6c4OAl8O3Y1G0UrazlJ wKfG/JsboDKAS39H4+Iz588Wy0XIMj++Mxw+Y= MIME-Version: 1.0 Received: by 10.231.60.73 with SMTP id o9mr2119091ibh.33.1302909994754; Fri, 15 Apr 2011 16:26:34 -0700 (PDT) Received: by 10.231.11.196 with HTTP; Fri, 15 Apr 2011 16:26:34 -0700 (PDT) In-Reply-To: <20110415184823.GH9116@emmi.physik-pool.tu-berlin.de> References: <20110415184823.GH9116@emmi.physik-pool.tu-berlin.de> Date: Sat, 16 Apr 2011 02:26:34 +0300 Message-ID: From: George Kontostanos To: freebsd-stable@freebsd.org, freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: =?ISO-8859-1?Q?Leon_Me=DFner?= Subject: Re: ZFS V28 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 23:26:36 -0000 I think that at this point it takes more than a patch. That is way I am asking if there is a plan to MFC to 8-Stable. On Fri, Apr 15, 2011 at 9:48 PM, Leon Me=DFner wrote: > On Fri, Apr 15, 2011 at 06:28:07PM +0300, George Kontostanos wrote: > > I was wondering if ZFS v28 is going to be MFC to 8-Stable or not. > > On Fri, Apr 15, 2011 at 06:28:07PM +0300, George Kontostanos wrote: > > I was wondering if ZFS v28 is going to be MFC to 8-Stable or not. > > Is there a recent patch against stable sources ? I tried the following: > > > http://people.freebsd.org/~mm/patches/zfs/v28/stable-8-zfsv28-20110317.pa= tch.xz > > This patch failes at sys/cddl/compat/opensolaris/sys/sysmacros.h which i > think should just be deleted. I tried deleting this file and then > building produces some errors then walls of text and then aborts. > The first errors look like this: > > Script started on Fri Apr 15 18:32:36 2011 > make -j 6 buildworld > "/usr/share/mk/bsd.prog.mk", line 128: warning: duplicate script for > target "_EXTRADEPEND" ignored > "Makefile", line 222: warning: duplicate script for target "clean" > ignored > "Makefile", line 222: warning: duplicate script for target "cleandepend" > ignored > "Makefile", line 222: warning: duplicate script for target "distribute" > ignored > "Makefile", line 222: warning: duplicate script for target "lint" > ignored > "Makefile", line 222: warning: duplicate script for target "obj" ignored > "Makefile", line 222: warning: duplicate script for target "objlink" > ignored > "Makefile", line 222: warning: duplicate script for target "tags" > ignored > "Makefile", line 222: warning: duplicate script for target "files" > ignored > "Makefile", line 222: warning: duplicate script for target "includes" > ignored > -------------------------------------------------------------- > >>> World build started on Fri Apr 15 18:32:36 UTC 2011 > -------------------------------------------------------------- > > cherio, > Leon > > > Regards, > --=20 George Kontostanos aisecure.net From owner-freebsd-current@FreeBSD.ORG Sat Apr 16 00:29:49 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D4AD21065670; Sat, 16 Apr 2011 00:29:49 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [IPv6:2001:470:a803::1]) by mx1.freebsd.org (Postfix) with ESMTP id 440B08FC0A; Sat, 16 Apr 2011 00:29:49 +0000 (UTC) Received: from mail.geekcn.org (tarsier.geekcn.org [211.166.10.233]) by tarsier.geekcn.org (Postfix) with ESMTP id 1535EAACCB4; Sat, 16 Apr 2011 08:29:48 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([211.166.10.233]) by mail.geekcn.org (mail.geekcn.org [211.166.10.233]) (amavisd-new, port 10024) with LMTP id K4qpF-Wh00Yr; Sat, 16 Apr 2011 08:29:41 +0800 (CST) Received: from charlie.delphij.net (unknown [124.126.234.61]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTPSA id 4A830AACC4A; Sat, 16 Apr 2011 08:29:40 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=delphij.net; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:subject: references:in-reply-to:x-enigmail-version:openpgp:content-type:content-transfer-encoding; b=b1CSgaq9dwNIjuaKJMs9qiC+9XffpGZCjlG+jbQliQbIh3BYiGIbinJk2ThoVm+c3 c6o5XejhGws4NsJVnFH3Q== Message-ID: <4DA8E2BD.40206@delphij.net> Date: Sat, 16 Apr 2011 08:28:45 +0800 From: Xin LI User-Agent: Thunderbird 2.0.0.14 (X11/20080603) MIME-Version: 1.0 To: George Kontostanos , freebsd-stable@freebsd.org, freebsd-current@freebsd.org References: <20110415184823.GH9116@emmi.physik-pool.tu-berlin.de> In-Reply-To: <20110415184823.GH9116@emmi.physik-pool.tu-berlin.de> X-Enigmail-Version: 0.95.6 OpenPGP: url=http://www.delphij.net/delphij.asc Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: Subject: Re: ZFS V28 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Apr 2011 00:29:49 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Leon Meßner wrote: | On Fri, Apr 15, 2011 at 06:28:07PM +0300, George Kontostanos wrote: |> I was wondering if ZFS v28 is going to be MFC to 8-Stable or not. | | On Fri, Apr 15, 2011 at 06:28:07PM +0300, George Kontostanos wrote: |> I was wondering if ZFS v28 is going to be MFC to 8-Stable or not. | | Is there a recent patch against stable sources ? I tried the following: | | http://people.freebsd.org/~mm/patches/zfs/v28/stable-8-zfsv28-20110317.patch.xz | | This patch failes at sys/cddl/compat/opensolaris/sys/sysmacros.h which i | think should just be deleted. I tried deleting this file and then | building produces some errors then walls of text and then aborts. | The first errors look like this: This file should be removed. The rejection might be caused by SCM tag from checkout, which depends on your configuration, and can be safely ignored. Cheers, -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAk2o4r0ACgkQOfuToMruuMCQkwCfZZtClSQmciKJt81t79NyyH1k WgIAn0gJj075PeieFsg6gzpTmG7EDb9O =CTU7 -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Sat Apr 16 07:32:02 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AAF441065670 for ; Sat, 16 Apr 2011 07:32:02 +0000 (UTC) (envelope-from m.seaman@infracaninophile.co.uk) Received: from smtp.infracaninophile.co.uk (smtp6.infracaninophile.co.uk [IPv6:2001:8b0:151:1:3fd3:cd67:fafa:3d78]) by mx1.freebsd.org (Postfix) with ESMTP id 17EE58FC15 for ; Sat, 16 Apr 2011 07:32:01 +0000 (UTC) Received: from seedling.black-earth.co.uk (seedling.black-earth.co.uk [81.187.76.163]) (authenticated bits=0) by smtp.infracaninophile.co.uk (8.14.4/8.14.4) with ESMTP id p3G7VuZB036109 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Sat, 16 Apr 2011 08:31:56 +0100 (BST) (envelope-from m.seaman@infracaninophile.co.uk) X-DKIM: Sendmail DKIM Filter v2.8.3 smtp.infracaninophile.co.uk p3G7VuZB036109 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=infracaninophile.co.uk; s=201001-infracaninophile; t=1302939116; bh=WmZQnWRLyE2szQJGlLHyrIa9q5eUAeKBRz1SxSpXs7Q=; h=Message-ID:Date:From:MIME-Version:To:Subject:References: In-Reply-To:Content-Type:Cc:Content-Type:Date:From:In-Reply-To: Message-ID:Mime-Version:References:To; z=Message-ID:=20<4DA945E4.1030708@infracaninophile.co.uk>|Date:=20S at,=2016=20Apr=202011=2008:31:48=20+0100|From:=20Matthew=20Seaman= 20|User-Agent:=20Mozilla/5.0=20(M acintosh=3B=20U=3B=20Intel=20Mac=20OS=20X=2010.6=3B=20en-US=3B=20r v:1.9.2.15)=20Gecko/20110303=20Thunderbird/3.1.9|MIME-Version:=201 .0|To:=20freebsd-current@freebsd.org|Subject:=20Re:=20ZFS=20V28|Re ferences:=20=0 9<20110415184823.GH9116@emmi.physik-pool.tu-berlin.de>=20|In-Reply-To:=20|X-Enigmail-Versi on:=201.1.1|OpenPGP:=20id=3D60AE908C|Content-Type:=20multipart/sig ned=3B=20micalg=3Dpgp-sha1=3B=0D=0A=20protocol=3D"application/pgp- signature"=3B=0D=0A=20boundary=3D"------------enig85FA9696C2D14C80 29BA015E"; b=ta33fO+tQH36W87Rb9nui3M/4gMvqtIbHPLUcXLYBKg4HAGvLgtTs+b8rg//TfFqM AJJ0Lq24Cmt7EcTWHR/aU9tom5apUwVw+EwUL5Nidgnb3oLmOSgD3VklS2cceG9qai jfzKX9ZFQOskwoXvgd+dAp2bxbAIBPC8Ea6rzQfw= Message-ID: <4DA945E4.1030708@infracaninophile.co.uk> Date: Sat, 16 Apr 2011 08:31:48 +0100 From: Matthew Seaman User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <20110415184823.GH9116@emmi.physik-pool.tu-berlin.de> In-Reply-To: X-Enigmail-Version: 1.1.1 OpenPGP: id=60AE908C Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig85FA9696C2D14C8029BA015E" X-Virus-Scanned: clamav-milter 0.97 at lucid-nonsense.infracaninophile.co.uk X-Virus-Status: Clean X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,SPF_FAIL autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on lucid-nonsense.infracaninophile.co.uk Subject: Re: ZFS V28 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Apr 2011 07:32:02 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig85FA9696C2D14C8029BA015E Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 16/04/2011 00:26, George Kontostanos wrote: > http://people.freebsd.org/~mm/patches/zfs/v28/stable-8-zfsv28-20110317.= patch.xz >> >> This patch failes at sys/cddl/compat/opensolaris/sys/sysmacros.h which= i >> think should just be deleted. I tried deleting this file and then >> building produces some errors then walls of text and then aborts. >> The first errors look like this: Hmmm... this worked for me on stable/8 r220471 a week ago Yes, you do have to delete sysmacros.h by hand. I never did understand why that header couldn't be deleted cleanly by the patch, but wotthehell: it's just one file out of the hundreds touched by this patch.= Also use the -E flag to patch to remove empty files. Cheers, Matthew --=20 Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate JID: matthew@infracaninophile.co.uk Kent, CT11 9PW --------------enig85FA9696C2D14C8029BA015E Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.16 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk2pRewACgkQ8Mjk52CukIzGTQCfStqkmPymWXAmJIevHAkyfIZP njsAn1Nscbit/0x5ryigKNIeX6VF7zOX =bGSK -----END PGP SIGNATURE----- --------------enig85FA9696C2D14C8029BA015E-- From owner-freebsd-current@FreeBSD.ORG Sat Apr 16 09:35:17 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8E159106564A for ; Sat, 16 Apr 2011 09:35:17 +0000 (UTC) (envelope-from mattia.rossi.mate@gmail.com) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by mx1.freebsd.org (Postfix) with ESMTP id 5ACC58FC15 for ; Sat, 16 Apr 2011 09:35:17 +0000 (UTC) Received: by pzk27 with SMTP id 27so1722634pzk.13 for ; Sat, 16 Apr 2011 02:35:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:reply-to:organization :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=+cmBdkFyfPgYa7dMjvEgxMPjts6/6fCJKqXM9ZR4byg=; b=dbZNKfb4jV47FD8hm4QTqw7vw1Y8RppY0+hBaMfPz67EIMy3LvQeTcQ+HOctCy/yQj z0N6lEIjK+KUZSk+5pXPsV6yUbyeq9tAS2+mkpm7L83Zm+1qRzlK2qmS32HPIQ8MptpB oHb4ScmZ7rW6GG1Sqh0rMKoIpTmjNdj4Crm0M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:reply-to:organization:user-agent:mime-version :to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; b=SN5HJN9PVZHAmFFNu9Ffu93dV0AzLQ5iPPgxrtdZv3WOCllMY0ODNKwPwimIJMm315 8axujIqh86mLgBUuSDWn6x6hUwS946YQCrDEN8AHmXt0JzjvzFBViSsYEvYQsnaInjYm uPJv//uvWxmyxYq0Lu3pCMjXdlP9dtSrF1nmM= Received: by 10.142.200.1 with SMTP id x1mr1361296wff.82.1302944630605; Sat, 16 Apr 2011 02:03:50 -0700 (PDT) Received: from [192.168.15.65] (124-168-216-221.dyn.iinet.net.au [124.168.216.221]) by mx.google.com with ESMTPS id m10sm4796020wfl.11.2011.04.16.02.03.47 (version=SSLv3 cipher=OTHER); Sat, 16 Apr 2011 02:03:49 -0700 (PDT) Message-ID: <4DA95BAF.1080909@swin.edu.au> Date: Sat, 16 Apr 2011 19:04:47 +1000 From: Mattia Rossi Organization: Swinburne University of Technology User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Marcin Cieslak References: <4DA7EAB5.9090204@swin.edu.au> <4DA84876.9020402@swin.edu.au> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: IPv6 tunnel problem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mrossi@swin.edu.au List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Apr 2011 09:35:17 -0000 On 15/04/11 23:58, Marcin Cieslak wrote: >>> Mattia Rossi wrote: >> I have accept_rtadv enabled if it's not a router. See my post. > > I think I have a similar setup (only using sixxs-aiccu). Since > my machine is a gateway to the outside IPv6 world (via www.sixxs.net) > I am not accepting router adverisements there, but I'm running > rtadvd and sending them to other hosts on the LAN: > > nd6 options=21 > Having ACCEPT_RTADV doesn't change anything. I can disable it by hand, so my options are 21 as well and it doesn't work. >> ifconfig with tunnel up is: >> >> ifconfig >> bge0: flags=8843 metric 0 mtu 1500 >> >> options=8009b >> ether 00:0d:9d:51:d4:7e >> inet 136.186.229.112 netmask 0xffffff00 broadcast xxx.xxx.xxx.xxx >> inet6 fe80::xxxx:xxxx:xxxx:xxxx%bge0 prefixlen 64 scopeid 0x5 >> inet6 xxxx:xxxx:xxxx:xxxx::xxxx prefixlen 64 duplicated > ********** > what's up here? >> nd6 options=23 >> media: Ethernet autoselect (1000baseT) >> status: active > > Why is this address "duplicated"? If this machine *is* the gateway > to the outside IPv6 world, should *not* it be accepting rtadv > and have a global IPv6 address configured statically > There's no duplicate, maybe obfuscating the IPv6 address was not so smart.. There's a link local address (scopeid 0x5) starting with fe80 installed by auto_linklocal, and the proper address set by the tunnel > >> tun0: flags=8051 metric 0 mtu 1280 >> options=80000 >> inet6 fe80::xxxx:xxxx:xxxx:xxxx%tun0 prefixlen 64 scopeid 0x9 >> inet6 xxxx:xxxx:xxxx::xxxx --> xxxx:xxxx:xxxx::xxxx prefixlen 128 >> nd6 options=29 > ********** > Does "ifconfig tun0 inet6 -ifdisabled" help? > > I don't know why gateway6 (I don't use this software) leaves it as "IFDISABLED" > Haven't realized there was an ifdisabled set. But it doesn't change anything unsetting it. Still no IPv6 > This is /etc/rc.conf from my tunnel gateway machine (two tunnels, tun0 and > tun1) - it runs a few-month-old -CURRENT: > > ipv6_gateway_enable="YES" > rtadvd_enable="YES" > # Internal WLAN > rtadvd_interfaces="wlan0" > ifconfig_wlan0_ipv6="inet6 aaaaa:bbbb:cccc::1/64" > # Tunnel via tun0 is configured automatically by aiccu > # and has NO /etc/rc.conf entry at all > # Tunnel via tun1 is configured statically (it serves only some networks) > ifconfig_tun1_ipv6="inet6 aaaaa:bbbb:cccc:8000::1" > > //Marcin > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"