From owner-freebsd-current@FreeBSD.ORG Sun May 15 04:33: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 5A885106564A; Sun, 15 May 2011 04:33:53 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.187]) by mx1.freebsd.org (Postfix) with ESMTP id 063808FC12; Sun, 15 May 2011 04:33:52 +0000 (UTC) Received: from maxlap.localnet ([24.114.252.238]) by mrelayeu.kundenserver.de (node=mreu2) with ESMTP (Nemesis) id 0MWOFC-1QEGxw3gvS-00XYSG; Sun, 15 May 2011 06:33:51 +0200 From: Max Laier To: freebsd-current@freebsd.org Date: Sun, 15 May 2011 00:33:40 -0400 User-Agent: KMail/1.13.6 (FreeBSD/9.0-CURRENT; KDE/4.6.1; amd64; ; ) References: <4DCD357D.6000109@FreeBSD.org> <4DCE9EF0.3050803@FreeBSD.org> In-Reply-To: <4DCE9EF0.3050803@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201105150033.40788.max@love2party.net> X-Provags-ID: V02:K0:owSsRojbawdFjXdb0E/8J6XoOlWr6cYjdpFF246qd+H Ei96iisn86Hbfz9aO2JIuZxDqk1QW+FnwUvY3gc2+MBPSvi5Jl 20reUIVc0zRn+jJZufURXVIVqktitJPYYMCMTWMqLCi/L2S2TE 9SW3Fwhxo4iqadgLSQPIvVqyzackGUhWRZExGFgUzBAx61OuVj SkqlLZAi1/4gp3QgmpyWA== Cc: Andriy Gapon , Peter Grehan Subject: Re: proposed smp_rendezvous change 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, 15 May 2011 04:33:53 -0000 On Saturday 14 May 2011 11:25:36 John Baldwin wrote: > On 5/13/11 9:43 AM, Andriy Gapon wrote: > > This is a change in vein of what I've been doing in the xcpu branch and > > it's supposed to fix the issue by the recent commit that (probably > > unintentionally) stress-tests smp_rendezvous in TSC code. > > > > Non-essential changes: > > - ditch initial, and in my opinion useless, pre-setup rendezvous in > > smp_rendezvous_action() > > As long as IPIs ensure all data is up to date (I think this is certainly > true on x86) that is fine. Presumably sending an IPI has an implicit > store barrier on all other platforms as well? Note that if the barrier is required on any platform, then we have to move all the initializations after the _acq, otherwise it is pointless indeed. > > > Essential changes (the fix): > > - re-use freed smp_rv_waiters[2] to indicate that a slave/target is > > really fully done with rendezvous (i.e. it's not going to access any > > members of smp_rv_* pseudo-structure) > > - spin on smp_rv_waiters[2] upon _entry_ to smp_rendezvous_cpus() to not > > re-use the smp_rv_* pseudo-structure too early > > Hmmm, so this is not actually sufficient. NetApp ran into a very > similar race with virtual CPUs in BHyVe. In their case because virtual > CPUs are threads that can be preempted, they have a chance at a longer > race. > > The problem that they see is that even though the values have been > updated, the next CPU to start a rendezvous can clear smp_rv_waiters[2] > to zero before one of the other CPUs notices that it has finished. > > A more concrete example: > > Suppose you have 3 CPUs doing a rendezvous where CPU 1 is the initiator. > > All three CPUs run the rendezvous down to the point of increasing > smp_rv_waiters[2]. CPU 1 is the last one to rendezvous for some reason > so he notices smp_rv_waiters[2] being correct first and exits the > rendezvous. It immediately does a new rendezvous. Even with your > change, it will see that smp_rv_waiters[2] is correct and will proceed > to clear it before starting the next rendezvous. > > Meanwhile one of the other CPUs never sees the final update by CPU 1 to > smp_rv_waiters[2], instead it sees the value go from 2 to 0 (e.g. if CPU > 1's two writes were coalesced, or in the case of the hypervisor, CPU 2 > or 3's backing thread is preempted and both writes have posted before > the thread backing CPU 2 or 3 gets to run again). > > At this point that CPU (call it CPU 2) will spin forever. When CPU 1 > sends a second rendezvous IPI it will be held in the local APIC of CPU 2 > because CPU 2 hasn't EOI'd the first IPI, and so CPU 2 will never bump > smp_rv_waiters[2] and the entire system will deadlock. > > NetApp's solution is to add a monotonically increasing generation count > to the rendezvous data set, which is cached in the rendezvous handler > and to exit the last synchronization point if either smp_rv_waiters[2] > is high enough, or the generation count has changed. > > I think this would also handle the case the TSC changes have provoked. > I'm not sure if this would be sufficient for the error case Max Laier > has encountered. It seems to address the issue, albeit a bit difficult to understand why this is correct. I'd like to see some comments in the code instead of just the commit log, but otherwise ... please go ahead with this. I'll open a new thread with the second issue we have been seeing wrt rmlocks, which is related, but different. > NetApp's patch: > > Extra protection for consecutive smp_rendezvous() calls. > > We need this because interrupts are not really disabled when > executing the smp_rendezvous_action() when running inside a > virtual machine. > > In particular it is possible for the last cpu to increment > smp_rv_waiters[2] so that the exit rendezvous condition is > satisfied and then get interrupted by a hardware interrupt. > > When the execution of the interrupted vcpu continues it is > possible that one of the other vcpus that did *not* get > interrupted exited the old smp_rendezvous() and started a > new smp_rendezvous(). In this case 'smp_rv_waiters[2]' is > again reset to 0. This would mean that the vcpu that got > interrupted will spin forever on the exit rendezvous. > > We protect this by spinning on the exit rendezvous only if > the generation of the smp_rendezvous() matches what we > started out with before incrementing 'smp_rv_waiters[2]'. > > Differences ... > > ==== //private/xxxx/sys/kern/subr_smp.c#3 (text) ==== > > @@ -127,6 +127,7 @@ > static void (*volatile smp_rv_teardown_func)(void *arg); > static void * volatile smp_rv_func_arg; > static volatile int smp_rv_waiters[3]; > +static volatile int smp_rv_generation; > > /* > * Shared mutex to restrict busywaits between smp_rendezvous() and > @@ -418,6 +419,7 @@ > void > smp_rendezvous_action(void) > { > + int generation; > void* local_func_arg = smp_rv_func_arg; > void (*local_setup_func)(void*) = smp_rv_setup_func; > void (*local_action_func)(void*) = smp_rv_action_func; > @@ -457,11 +459,14 @@ > if (local_action_func != NULL) > local_action_func(local_func_arg); > > + generation = atomic_load_acq_int(&smp_rv_generation); > + > /* spin on exit rendezvous */ > atomic_add_int(&smp_rv_waiters[2], 1); > if (local_teardown_func == smp_no_rendevous_barrier) > return; > - while (smp_rv_waiters[2] < smp_rv_ncpus) > + while (smp_rv_waiters[2] < smp_rv_ncpus && > + generation == smp_rv_generation) > cpu_spinwait(); > > /* > @@ -565,6 +570,8 @@ > /* obtain rendezvous lock */ > mtx_lock_spin(&smp_ipi_mtx); > > + atomic_add_acq_int(&smp_rv_generation, 1); > + > /* set static function pointers */ > smp_rv_ncpus = ncpus; > smp_rv_setup_func = setup_func; From owner-freebsd-current@FreeBSD.ORG Sun May 15 07:10: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 28B651065672; Sun, 15 May 2011 07:10:19 +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 3CF858FC12; Sun, 15 May 2011 07:10:17 +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 KAA09849; Sun, 15 May 2011 10:10:15 +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 1QLVSw-0004wB-U8; Sun, 15 May 2011 10:10:14 +0300 Message-ID: <4DCF7C55.3030404@FreeBSD.org> Date: Sun, 15 May 2011 10:10:13 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.17) Gecko/20110503 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: John Baldwin References: <4DCD357D.6000109@FreeBSD.org> <4DCE9EF0.3050803@FreeBSD.org> In-Reply-To: <4DCE9EF0.3050803@FreeBSD.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD current , Peter Grehan Subject: Re: proposed smp_rendezvous change 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, 15 May 2011 07:10:19 -0000 on 14/05/2011 18:25 John Baldwin said the following: > On 5/13/11 9:43 AM, Andriy Gapon wrote: >> >> This is a change in vein of what I've been doing in the xcpu branch and it's >> supposed to fix the issue by the recent commit that (probably unintentionally) >> stress-tests smp_rendezvous in TSC code. >> >> Non-essential changes: >> - ditch initial, and in my opinion useless, pre-setup rendezvous in >> smp_rendezvous_action() > > As long as IPIs ensure all data is up to date (I think this is certainly true on > x86) that is fine. Presumably sending an IPI has an implicit store barrier on > all other platforms as well? Well, one certainly can use IPIs as memory barrier, but my point was that we have other ways to have a memory barrier and using IPI for that was not necessary (and a little bit harmful to performance) in this case. >> Essential changes (the fix): >> - re-use freed smp_rv_waiters[2] to indicate that a slave/target is really fully >> done with rendezvous (i.e. it's not going to access any members of smp_rv_* >> pseudo-structure) >> - spin on smp_rv_waiters[2] upon _entry_ to smp_rendezvous_cpus() to not re-use >> the smp_rv_* pseudo-structure too early > > Hmmm, so this is not actually sufficient. NetApp ran into a very similar race > with virtual CPUs in BHyVe. In their case because virtual CPUs are threads that > can be preempted, they have a chance at a longer race. Just a quick question - have you noticed that because of the change above the smp_rv_waiters[2] of which I spoke was not the same smp_rv_waiters[2] as in the original cod? Because I "removed" smp_rv_waiters[0], smp_rv_waiters[2] is actually some new smp_rv_waiters[3]. And well, I think I described exactly the same scenario as you did in my email on the svn mailing list. So of course I had it in mind: http://www.mail-archive.com/svn-src-all@freebsd.org/msg38637.html My problem, I should have not mixed different changes into the same patch, for clarity. I should have provided two patches: one that adds smp_rv_waiters[3] and its handling and one that "removes" smp_rv_waiters[0]. I would to see my proposed patch actually tested, if possible, before it's dismissed :-) -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Sun May 15 07:12:52 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 8B54F1065673; Sun, 15 May 2011 07:12:52 +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 9D7598FC17; Sun, 15 May 2011 07:12:50 +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 KAA09861; Sun, 15 May 2011 10:12:49 +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 1QLVVQ-0004wJ-SL; Sun, 15 May 2011 10:12:48 +0300 Message-ID: <4DCF7CF0.1080508@FreeBSD.org> Date: Sun, 15 May 2011 10:12:48 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.17) Gecko/20110503 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: John Baldwin References: <4DCD357D.6000109@FreeBSD.org> <4DCE9EF0.3050803@FreeBSD.org> In-Reply-To: <4DCE9EF0.3050803@FreeBSD.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD current , Peter Grehan Subject: Re: proposed smp_rendezvous change 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, 15 May 2011 07:12:52 -0000 on 14/05/2011 18:25 John Baldwin said the following: > Hmmm, so this is not actually sufficient. NetApp ran into a very similar race > with virtual CPUs in BHyVe. In their case because virtual CPUs are threads that > can be preempted, they have a chance at a longer race. > > The problem that they see is that even though the values have been updated, the > next CPU to start a rendezvous can clear smp_rv_waiters[2] to zero before one of > the other CPUs notices that it has finished. As a follow up to my previous question. Have you noticed that in my patch no slave CPU actually waits/spins on smp_rv_waiters[2]? It's always only master CPU (and under smp_ipi_mtx). -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Sun May 15 08:13: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 8B03D106566B; Sun, 15 May 2011 08:13:53 +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 6335D8FC08; Sun, 15 May 2011 08:13:52 +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 LAA10242; Sun, 15 May 2011 11:13:50 +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 1QLWST-0004yI-Kz; Sun, 15 May 2011 11:13:49 +0300 Message-ID: <4DCF8B3C.2060008@FreeBSD.org> Date: Sun, 15 May 2011 11:13:48 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.17) Gecko/20110503 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Max Laier References: <4DCD357D.6000109@FreeBSD.org> <4DCE9EF0.3050803@FreeBSD.org> <201105150033.40788.max@love2party.net> In-Reply-To: <201105150033.40788.max@love2party.net> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org, Peter Grehan , John Baldwin Subject: Re: proposed smp_rendezvous change 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, 15 May 2011 08:13:53 -0000 on 15/05/2011 07:33 Max Laier said the following: > On Saturday 14 May 2011 11:25:36 John Baldwin wrote: >> On 5/13/11 9:43 AM, Andriy Gapon wrote: >>> This is a change in vein of what I've been doing in the xcpu branch and >>> it's supposed to fix the issue by the recent commit that (probably >>> unintentionally) stress-tests smp_rendezvous in TSC code. >>> >>> Non-essential changes: >>> - ditch initial, and in my opinion useless, pre-setup rendezvous in >>> smp_rendezvous_action() >> >> As long as IPIs ensure all data is up to date (I think this is certainly >> true on x86) that is fine. Presumably sending an IPI has an implicit >> store barrier on all other platforms as well? > > Note that if the barrier is required on any platform, then we have to move all > the initializations after the _acq, otherwise it is pointless indeed. Yeah, I still would like to get an explanation why that synchronization is needed. I can understand "better safe than sorry" mentality, I often stick to it myself. But for the benefit of improving objective knowledge it would be useful to understand why that spin-waiting could it useful, especially given your observation about where the assignment are made. >>> Essential changes (the fix): >>> - re-use freed smp_rv_waiters[2] to indicate that a slave/target is >>> really fully done with rendezvous (i.e. it's not going to access any >>> members of smp_rv_* pseudo-structure) >>> - spin on smp_rv_waiters[2] upon _entry_ to smp_rendezvous_cpus() to not >>> re-use the smp_rv_* pseudo-structure too early >> >> Hmmm, so this is not actually sufficient. NetApp ran into a very >> similar race with virtual CPUs in BHyVe. In their case because virtual >> CPUs are threads that can be preempted, they have a chance at a longer >> race. >> >> The problem that they see is that even though the values have been >> updated, the next CPU to start a rendezvous can clear smp_rv_waiters[2] >> to zero before one of the other CPUs notices that it has finished. >> >> A more concrete example: >> >> Suppose you have 3 CPUs doing a rendezvous where CPU 1 is the initiator. >> >> All three CPUs run the rendezvous down to the point of increasing >> smp_rv_waiters[2]. CPU 1 is the last one to rendezvous for some reason >> so he notices smp_rv_waiters[2] being correct first and exits the >> rendezvous. It immediately does a new rendezvous. Even with your >> change, it will see that smp_rv_waiters[2] is correct and will proceed >> to clear it before starting the next rendezvous. >> >> Meanwhile one of the other CPUs never sees the final update by CPU 1 to >> smp_rv_waiters[2], instead it sees the value go from 2 to 0 (e.g. if CPU >> 1's two writes were coalesced, or in the case of the hypervisor, CPU 2 >> or 3's backing thread is preempted and both writes have posted before >> the thread backing CPU 2 or 3 gets to run again). >> >> At this point that CPU (call it CPU 2) will spin forever. When CPU 1 >> sends a second rendezvous IPI it will be held in the local APIC of CPU 2 >> because CPU 2 hasn't EOI'd the first IPI, and so CPU 2 will never bump >> smp_rv_waiters[2] and the entire system will deadlock. >> >> NetApp's solution is to add a monotonically increasing generation count >> to the rendezvous data set, which is cached in the rendezvous handler >> and to exit the last synchronization point if either smp_rv_waiters[2] >> is high enough, or the generation count has changed. >> >> I think this would also handle the case the TSC changes have provoked. >> I'm not sure if this would be sufficient for the error case Max Laier >> has encountered. > > It seems to address the issue, albeit a bit difficult to understand why this > is correct. I'd like to see some comments in the code instead of just the > commit log, but otherwise ... please go ahead with this. I think it works approximately the same as what I suggested. Only my patch forces the next master CPU to wait until all slave CPUs are fully done with the previous rendezvous (and ware of that fact), while this patch provides a "side-channel" to tell late slave CPUs that their rendezvous was completed when there is a new rendezvous started by a new master CPU. >> NetApp's patch: >> >> Extra protection for consecutive smp_rendezvous() calls. >> >> We need this because interrupts are not really disabled when >> executing the smp_rendezvous_action() when running inside a >> virtual machine. >> >> In particular it is possible for the last cpu to increment >> smp_rv_waiters[2] so that the exit rendezvous condition is >> satisfied and then get interrupted by a hardware interrupt. >> >> When the execution of the interrupted vcpu continues it is >> possible that one of the other vcpus that did *not* get >> interrupted exited the old smp_rendezvous() and started a >> new smp_rendezvous(). In this case 'smp_rv_waiters[2]' is >> again reset to 0. This would mean that the vcpu that got >> interrupted will spin forever on the exit rendezvous. >> >> We protect this by spinning on the exit rendezvous only if >> the generation of the smp_rendezvous() matches what we >> started out with before incrementing 'smp_rv_waiters[2]'. >> >> Differences ... >> >> ==== //private/xxxx/sys/kern/subr_smp.c#3 (text) ==== >> >> @@ -127,6 +127,7 @@ >> static void (*volatile smp_rv_teardown_func)(void *arg); >> static void * volatile smp_rv_func_arg; >> static volatile int smp_rv_waiters[3]; >> +static volatile int smp_rv_generation; >> >> /* >> * Shared mutex to restrict busywaits between smp_rendezvous() and >> @@ -418,6 +419,7 @@ >> void >> smp_rendezvous_action(void) >> { >> + int generation; >> void* local_func_arg = smp_rv_func_arg; >> void (*local_setup_func)(void*) = smp_rv_setup_func; >> void (*local_action_func)(void*) = smp_rv_action_func; >> @@ -457,11 +459,14 @@ >> if (local_action_func != NULL) >> local_action_func(local_func_arg); >> >> + generation = atomic_load_acq_int(&smp_rv_generation); >> + >> /* spin on exit rendezvous */ >> atomic_add_int(&smp_rv_waiters[2], 1); >> if (local_teardown_func == smp_no_rendevous_barrier) >> return; >> - while (smp_rv_waiters[2] < smp_rv_ncpus) >> + while (smp_rv_waiters[2] < smp_rv_ncpus && >> + generation == smp_rv_generation) >> cpu_spinwait(); >> >> /* >> @@ -565,6 +570,8 @@ >> /* obtain rendezvous lock */ >> mtx_lock_spin(&smp_ipi_mtx); >> >> + atomic_add_acq_int(&smp_rv_generation, 1); >> + >> /* set static function pointers */ >> smp_rv_ncpus = ncpus; >> smp_rv_setup_func = setup_func; -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Sun May 15 14:53: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 4A8D2106566B; Sun, 15 May 2011 14:53:49 +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 29A928FC14; Sun, 15 May 2011 14:53:47 +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 RAA12928; Sun, 15 May 2011 17:53:46 +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 1QLchW-0000Cy-Je; Sun, 15 May 2011 17:53:46 +0300 Message-ID: <4DCFE8FA.6080005@FreeBSD.org> Date: Sun, 15 May 2011 17:53:46 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.17) Gecko/20110503 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: John Baldwin , Peter Grehan , Max Laier References: <4DCD357D.6000109@FreeBSD.org> <4DCE9EF0.3050803@FreeBSD.org> <4DCF7CF0.1080508@FreeBSD.org> In-Reply-To: <4DCF7CF0.1080508@FreeBSD.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD current Subject: Re: proposed smp_rendezvous change 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, 15 May 2011 14:53:49 -0000 on 15/05/2011 10:12 Andriy Gapon said the following: > on 14/05/2011 18:25 John Baldwin said the following: >> Hmmm, so this is not actually sufficient. NetApp ran into a very similar race >> with virtual CPUs in BHyVe. In their case because virtual CPUs are threads that >> can be preempted, they have a chance at a longer race. >> >> The problem that they see is that even though the values have been updated, the >> next CPU to start a rendezvous can clear smp_rv_waiters[2] to zero before one of >> the other CPUs notices that it has finished. > > As a follow up to my previous question. Have you noticed that in my patch no > slave CPU actually waits/spins on smp_rv_waiters[2]? It's always only master > CPU (and under smp_ipi_mtx). > Here's a cleaner version of my approach to the fix. This one does not remove the initial wait on smp_rv_waiters[0] in smp_rendezvous_action() and thus does not renumber all smp_rv_waiters[] members and thus hopefully should be clearer. Index: sys/kern/subr_smp.c =================================================================== --- sys/kern/subr_smp.c (revision 221943) +++ sys/kern/subr_smp.c (working copy) @@ -110,7 +110,7 @@ static void (*volatile smp_rv_setup_func)(void *ar static void (*volatile smp_rv_action_func)(void *arg); static void (*volatile smp_rv_teardown_func)(void *arg); static void *volatile smp_rv_func_arg; -static volatile int smp_rv_waiters[3]; +static volatile int smp_rv_waiters[4]; /* * Shared mutex to restrict busywaits between smp_rendezvous() and @@ -338,11 +338,15 @@ smp_rendezvous_action(void) /* spin on exit rendezvous */ atomic_add_int(&smp_rv_waiters[2], 1); - if (local_teardown_func == smp_no_rendevous_barrier) + if (local_teardown_func == smp_no_rendevous_barrier) { + atomic_add_int(&smp_rv_waiters[3], 1); return; + } while (smp_rv_waiters[2] < smp_rv_ncpus) cpu_spinwait(); + atomic_add_int(&smp_rv_waiters[3], 1); + /* teardown function */ if (local_teardown_func != NULL) local_teardown_func(local_func_arg); @@ -377,6 +381,9 @@ smp_rendezvous_cpus(cpumask_t map, /* obtain rendezvous lock */ mtx_lock_spin(&smp_ipi_mtx); + while (smp_rv_waiters[3] < smp_rv_ncpus) + cpu_spinwait(); + /* set static function pointers */ smp_rv_ncpus = ncpus; smp_rv_setup_func = setup_func; @@ -385,6 +392,7 @@ smp_rendezvous_cpus(cpumask_t map, smp_rv_func_arg = arg; smp_rv_waiters[1] = 0; smp_rv_waiters[2] = 0; + smp_rv_waiters[3] = 0; atomic_store_rel_int(&smp_rv_waiters[0], 0); /* signal other processors, which will enter the IPI with interrupts off */ -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Sun May 15 15:16: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 6EA4C1065672; Sun, 15 May 2011 15:16:05 +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 2EA758FC0A; Sun, 15 May 2011 15:16:05 +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 BBCA046B23; Sun, 15 May 2011 11:16:04 -0400 (EDT) Received: from John-Baldwins-Macbook-Pro.local (unknown [192.75.139.251]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 0E8F78A04F; Sun, 15 May 2011 11:16:04 -0400 (EDT) Message-ID: <4DCFEE33.5090808@FreeBSD.org> Date: Sun, 15 May 2011 11:16:03 -0400 From: John Baldwin User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Andriy Gapon References: <4DCD357D.6000109@FreeBSD.org> <4DCE9EF0.3050803@FreeBSD.org> <4DCF7CF0.1080508@FreeBSD.org> <4DCFE8FA.6080005@FreeBSD.org> In-Reply-To: <4DCFE8FA.6080005@FreeBSD.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 (bigwig.baldwin.cx); Sun, 15 May 2011 11:16:04 -0400 (EDT) Cc: Max Laier , FreeBSD current , neel@FreeBSD.org, Peter Grehan Subject: Re: proposed smp_rendezvous change 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, 15 May 2011 15:16:05 -0000 On 5/15/11 10:53 AM, Andriy Gapon wrote: > on 15/05/2011 10:12 Andriy Gapon said the following: >> on 14/05/2011 18:25 John Baldwin said the following: >>> Hmmm, so this is not actually sufficient. NetApp ran into a very similar race >>> with virtual CPUs in BHyVe. In their case because virtual CPUs are threads that >>> can be preempted, they have a chance at a longer race. >>> >>> The problem that they see is that even though the values have been updated, the >>> next CPU to start a rendezvous can clear smp_rv_waiters[2] to zero before one of >>> the other CPUs notices that it has finished. >> >> As a follow up to my previous question. Have you noticed that in my patch no >> slave CPU actually waits/spins on smp_rv_waiters[2]? It's always only master >> CPU (and under smp_ipi_mtx). >> > > Here's a cleaner version of my approach to the fix. > This one does not remove the initial wait on smp_rv_waiters[0] in > smp_rendezvous_action() and thus does not renumber all smp_rv_waiters[] members > and thus hopefully should be clearer. > > Index: sys/kern/subr_smp.c > =================================================================== > --- sys/kern/subr_smp.c (revision 221943) > +++ sys/kern/subr_smp.c (working copy) > @@ -110,7 +110,7 @@ static void (*volatile smp_rv_setup_func)(void *ar > static void (*volatile smp_rv_action_func)(void *arg); > static void (*volatile smp_rv_teardown_func)(void *arg); > static void *volatile smp_rv_func_arg; > -static volatile int smp_rv_waiters[3]; > +static volatile int smp_rv_waiters[4]; > > /* > * Shared mutex to restrict busywaits between smp_rendezvous() and > @@ -338,11 +338,15 @@ smp_rendezvous_action(void) > > /* spin on exit rendezvous */ > atomic_add_int(&smp_rv_waiters[2], 1); > - if (local_teardown_func == smp_no_rendevous_barrier) > + if (local_teardown_func == smp_no_rendevous_barrier) { > + atomic_add_int(&smp_rv_waiters[3], 1); > return; > + } > while (smp_rv_waiters[2]< smp_rv_ncpus) > cpu_spinwait(); > > + atomic_add_int(&smp_rv_waiters[3], 1); > + > /* teardown function */ > if (local_teardown_func != NULL) > local_teardown_func(local_func_arg); > @@ -377,6 +381,9 @@ smp_rendezvous_cpus(cpumask_t map, > /* obtain rendezvous lock */ > mtx_lock_spin(&smp_ipi_mtx); > > + while (smp_rv_waiters[3]< smp_rv_ncpus) > + cpu_spinwait(); > + > /* set static function pointers */ > smp_rv_ncpus = ncpus; > smp_rv_setup_func = setup_func; > @@ -385,6 +392,7 @@ smp_rendezvous_cpus(cpumask_t map, > smp_rv_func_arg = arg; > smp_rv_waiters[1] = 0; > smp_rv_waiters[2] = 0; > + smp_rv_waiters[3] = 0; > atomic_store_rel_int(&smp_rv_waiters[0], 0); > > /* signal other processors, which will enter the IPI with interrupts off */ Ahh, so the bump is after the change. I do think this will still be ok and I probably just didn't explain it well to Neel. I wonder though if the bump shouldn't happen until after the call of the local teardown function? -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Sun May 15 15:37:04 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4AD22106564A; Sun, 15 May 2011 15:37:04 +0000 (UTC) (envelope-from yanegomi@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 D189C8FC14; Sun, 15 May 2011 15:37:03 +0000 (UTC) Received: by vxc34 with SMTP id 34so3679473vxc.13 for ; Sun, 15 May 2011 08:37:03 -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=D4yMKEn/F4TfX8dvq//M325iYuISsj0QjHcS13Ons8s=; b=WCQU7vDjMasL3S6ujOZ+IxFs20LxKTjrfX7RjWOmZtFQclamjDeBEa1DtSFby1mG2t RpkdKrBAB9BgsV18eAAx6eGNa2NuUxf6VqGTrustk55AHMrgtBsS0QDdFW4lEzUrivWV IqpTFnwkFilK91iGHz492v01oofLEViBOC8ec= 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=aBR2EoEPzgxNPIfUPMFud8ZBps8Wl7VZmrJc9fpbnMzyHWhg4147Fv3wTewrnodW9f 0cVkr0qFIGEB4QveRbTVjbWLaRv/0TrvWjCHNLFFqLGEVHCFR/SqL5gyR6ZFRPA2bwXs SJWDrKpGBFwGhl1reIbFOQhxj5OuFEYwJ2maE= MIME-Version: 1.0 Received: by 10.52.181.168 with SMTP id dx8mr4804384vdc.172.1305473822740; Sun, 15 May 2011 08:37:02 -0700 (PDT) Received: by 10.220.188.202 with HTTP; Sun, 15 May 2011 08:37:02 -0700 (PDT) In-Reply-To: References: <201105140256.p4E2uLCU024407@freebsd-current.sentex.ca> <86zkmpkmdo.fsf@ds4.des.no> Date: Sun, 15 May 2011 08:37:02 -0700 Message-ID: From: Garrett Cooper To: Attilio Rao Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: current@freebsd.org, =?ISO-8859-1?Q?Dag=2DErling_Sm=F8rgrav?= , FreeBSD Tinderbox , sparc64@freebsd.org Subject: Re: [head tinderbox] failure on sparc64/sun4v 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, 15 May 2011 15:37:04 -0000 2011/5/14 Attilio Rao : > 2011/5/14 Dag-Erling Sm=F8rgrav : >> Attilio Rao writes: >>> So, am I missing something when removing sun4v or the tinderbox >>> machine needs to be updated someway? >> >> Yes, you should have warned me in advance. > > Ok, sorry for not doing that. > > Can you please do something for it? Why not use something like this with tinderbox? $ make -C /usr/src/ targets | awk 'NR > 1' | sed 's,/,:,g' amd64:amd64 arm:arm arm:armeb i386:i386 ia64:ia64 mips:mipsel mips:mipseb mips:mips64el mips:mips64eb mips:mipsn32eb pc98:i386 powerpc:powerpc powerpc:powerpc64 sparc64:sparc64 sun4v:sparc64 Thanks! -Garrett PS This was from an old tree. From owner-freebsd-current@FreeBSD.ORG Sun May 15 15:56:26 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 65950106566B; Sun, 15 May 2011 15:56:26 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 236CE8FC16; Sun, 15 May 2011 15:56:25 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id 42A411FFC35; Sun, 15 May 2011 15:56:25 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id 0FB6784530; Sun, 15 May 2011 17:56:25 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Attilio Rao References: <201105140256.p4E2uLCU024407@freebsd-current.sentex.ca> <86zkmpkmdo.fsf@ds4.des.no> Date: Sun, 15 May 2011 17:56:24 +0200 In-Reply-To: (Attilio Rao's message of "Sat, 14 May 2011 23:24:15 +0200") Message-ID: <86r580klef.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: sparc64@freebsd.org, FreeBSD Tinderbox , current@freebsd.org Subject: Re: [head tinderbox] failure on sparc64/sun4v 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, 15 May 2011 15:56:26 -0000 Attilio Rao writes: > Dag-Erling Sm=C3=B8rgrav writes: > > Attilio Rao writes: > > > So, am I missing something when removing sun4v or the tinderbox > > > machine needs to be updated someway? > > Yes, you should have warned me in advance. > Ok, sorry for not doing that. > > Can you please do something for it? I already have. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Sun May 15 15:58:50 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2CF6E1065673; Sun, 15 May 2011 15:58:50 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id DD5578FC0C; Sun, 15 May 2011 15:58:49 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id 228201FFC58; Sun, 15 May 2011 15:58:49 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id E80EE84530; Sun, 15 May 2011 17:58:48 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Garrett Cooper References: <201105140256.p4E2uLCU024407@freebsd-current.sentex.ca> <86zkmpkmdo.fsf@ds4.des.no> Date: Sun, 15 May 2011 17:58:48 +0200 In-Reply-To: (Garrett Cooper's message of "Sun, 15 May 2011 08:37:02 -0700") Message-ID: <86mxioklaf.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Attilio Rao , current@freebsd.org, FreeBSD Tinderbox , sparc64@freebsd.org Subject: Re: [head tinderbox] failure on sparc64/sun4v 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, 15 May 2011 15:58:50 -0000 Garrett Cooper writes: > Why not use something like this with tinderbox? > > $ make -C /usr/src/ targets | awk 'NR > 1' | sed 's,/,:,g' Because that's not how the tinderbox works; you may not necessarily want to build all existing targets. I *could* modify the supervisor script so it doesn't start the build script for targets that don't exist, but that would be like disabling compiler warnings instead of fixing the bugs that cause them. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Sun May 15 15:59:19 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 88073106567D; Sun, 15 May 2011 15:59:19 +0000 (UTC) (envelope-from asmrookie@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 17C488FC23; Sun, 15 May 2011 15:59:18 +0000 (UTC) Received: by gyg13 with SMTP id 13so1626985gyg.13 for ; Sun, 15 May 2011 08:59:18 -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 :content-transfer-encoding; bh=AldR3e1HJPvaazCcBBOQgkb7JjW1XRSM0eleoF+Yy0E=; b=NGapwtXtPOrLA7Jj1e4ApoJo9dc1NyxNV2YX/l1cSw9DE2AJqQ3xNv387pnZveGl0J Vxvtt55hdeQBCHfGuF/ELeVmx8Id11jbFX2C2p5I4dUpZA8MRJtk1YZkEkk2fZCXMIny 2MRuiFWCyh7XzOwqoq0hzkUXxardBiBw8Mjdc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=N6CfGrlaaWvOv26rnTk6kf5/cbHbnBoojraTF8MfsdhVxZOKKe02ZbpsNJ8JH77yR2 vkAialMnb9bPFafxl3dYolPS1Zbko0zvYXAsgTjekmLJhsLOh8pCsDUZkhN6Dx5vswtO 6NjRE6x+1cCwRHYoe40uv26VZLe82PQuoSDLc= MIME-Version: 1.0 Received: by 10.236.183.193 with SMTP id q41mr3432060yhm.80.1305475158206; Sun, 15 May 2011 08:59:18 -0700 (PDT) Sender: asmrookie@gmail.com Received: by 10.236.103.130 with HTTP; Sun, 15 May 2011 08:59:18 -0700 (PDT) In-Reply-To: <86r580klef.fsf@ds4.des.no> References: <201105140256.p4E2uLCU024407@freebsd-current.sentex.ca> <86zkmpkmdo.fsf@ds4.des.no> <86r580klef.fsf@ds4.des.no> Date: Sun, 15 May 2011 17:59:18 +0200 X-Google-Sender-Auth: jLUptmS3SgGb_MS5cjO46wVlxxY Message-ID: From: Attilio Rao To: =?UTF-8?Q?Dag=2DErling_Sm=C3=B8rgrav?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: sparc64@freebsd.org, FreeBSD Tinderbox , current@freebsd.org Subject: Re: [head tinderbox] failure on sparc64/sun4v 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, 15 May 2011 15:59:19 -0000 2011/5/15 Dag-Erling Sm=C3=B8rgrav : > Attilio Rao writes: >> Dag-Erling Sm=C3=B8rgrav writes: >> > Attilio Rao writes: >> > > So, am I missing something when removing sun4v or the tinderbox >> > > machine needs to be updated someway? >> > Yes, you should have warned me in advance. >> Ok, sorry for not doing that. >> >> Can you please do something for it? > > I already have. Thanks, much appreciated. Attilio --=20 Peace can only be achieved by understanding - A. Einstein From owner-freebsd-current@FreeBSD.ORG Sun May 15 16:11: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 206CA1065741; Sun, 15 May 2011 16:11:18 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.171]) by mx1.freebsd.org (Postfix) with ESMTP id BBAA08FC18; Sun, 15 May 2011 16:11:17 +0000 (UTC) Received: from maxlap.localnet (wsp04373635wss.cr.net.cable.rogers.com [24.235.98.20]) by mrelayeu.kundenserver.de (node=mreu4) with ESMTP (Nemesis) id 0Li6Ap-1PycxU3h4d-00nOZe; Sun, 15 May 2011 18:11:16 +0200 From: Max Laier To: John Baldwin Date: Sun, 15 May 2011 12:09:13 -0400 User-Agent: KMail/1.13.6 (FreeBSD/9.0-CURRENT; KDE/4.6.1; amd64; ; ) References: <4DCD357D.6000109@FreeBSD.org> <4DCFE8FA.6080005@FreeBSD.org> <4DCFEE33.5090808@FreeBSD.org> In-Reply-To: <4DCFEE33.5090808@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201105151209.13846.max@love2party.net> X-Provags-ID: V02:K0:Nm0LRuUw7utpDrjdHqQI/D0DwK4xrpCSytV18EYFGs3 LEDI/00ufxbYWIVk9My4ethAPAp3LdZ0ErC/rgX6aRoueGrtYG rgsaRUoV3KhRwrSWJlrlTfTzEWc8vU11LojlBrNmQTA2tV6gnN NzYlvoazLm7H7lS7n3ol7cnqY5dqI3tZM2886vDTFIwxQRbS5H fAEdvThYp3yhW+jIlK+Xg== Cc: FreeBSD current , Peter Grehan , Andriy Gapon , neel@freebsd.org Subject: Re: proposed smp_rendezvous change 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, 15 May 2011 16:11:18 -0000 On Sunday 15 May 2011 11:16:03 John Baldwin wrote: > On 5/15/11 10:53 AM, Andriy Gapon wrote: > > on 15/05/2011 10:12 Andriy Gapon said the following: > >> on 14/05/2011 18:25 John Baldwin said the following: > >>> Hmmm, so this is not actually sufficient. NetApp ran into a very > >>> similar race with virtual CPUs in BHyVe. In their case because > >>> virtual CPUs are threads that can be preempted, they have a chance at > >>> a longer race. > >>> > >>> The problem that they see is that even though the values have been > >>> updated, the next CPU to start a rendezvous can clear > >>> smp_rv_waiters[2] to zero before one of the other CPUs notices that it > >>> has finished. > >> > >> As a follow up to my previous question. Have you noticed that in my > >> patch no slave CPU actually waits/spins on smp_rv_waiters[2]? It's > >> always only master CPU (and under smp_ipi_mtx). > > > > Here's a cleaner version of my approach to the fix. > > This one does not remove the initial wait on smp_rv_waiters[0] in > > smp_rendezvous_action() and thus does not renumber all smp_rv_waiters[] > > members and thus hopefully should be clearer. > > > > Index: sys/kern/subr_smp.c > > =================================================================== > > --- sys/kern/subr_smp.c (revision 221943) > > +++ sys/kern/subr_smp.c (working copy) > > @@ -110,7 +110,7 @@ static void (*volatile smp_rv_setup_func)(void *ar > > > > static void (*volatile smp_rv_action_func)(void *arg); > > static void (*volatile smp_rv_teardown_func)(void *arg); > > static void *volatile smp_rv_func_arg; > > > > -static volatile int smp_rv_waiters[3]; > > +static volatile int smp_rv_waiters[4]; > > > > /* > > > > * Shared mutex to restrict busywaits between smp_rendezvous() and > > > > @@ -338,11 +338,15 @@ smp_rendezvous_action(void) > > > > /* spin on exit rendezvous */ > > atomic_add_int(&smp_rv_waiters[2], 1); > > > > - if (local_teardown_func == smp_no_rendevous_barrier) > > + if (local_teardown_func == smp_no_rendevous_barrier) { > > + atomic_add_int(&smp_rv_waiters[3], 1); > > > > return; > > > > + } > > > > while (smp_rv_waiters[2]< smp_rv_ncpus) > > > > cpu_spinwait(); > > > > + atomic_add_int(&smp_rv_waiters[3], 1); > > + > > > > /* teardown function */ > > if (local_teardown_func != NULL) > > > > local_teardown_func(local_func_arg); > > > > @@ -377,6 +381,9 @@ smp_rendezvous_cpus(cpumask_t map, > > > > /* obtain rendezvous lock */ > > mtx_lock_spin(&smp_ipi_mtx); > > > > + while (smp_rv_waiters[3]< smp_rv_ncpus) > > + cpu_spinwait(); > > + > > > > /* set static function pointers */ > > smp_rv_ncpus = ncpus; > > smp_rv_setup_func = setup_func; > > > > @@ -385,6 +392,7 @@ smp_rendezvous_cpus(cpumask_t map, > > > > smp_rv_func_arg = arg; > > smp_rv_waiters[1] = 0; > > smp_rv_waiters[2] = 0; > > > > + smp_rv_waiters[3] = 0; > > > > atomic_store_rel_int(&smp_rv_waiters[0], 0); > > > > /* signal other processors, which will enter the IPI with interrupts > > off */ > > Ahh, so the bump is after the change. I do think this will still be ok > and I probably just didn't explain it well to Neel. I wonder though > if the bump shouldn't happen until after the call of the local teardown > function? I don't think we ever intended to synchronize the local teardown part, and I believe that is the correct behavior for this API. This version is sufficiently close to what I have, so I am resonably sure that it will work for us. It seems, however, that if we move to check to after picking up the lock anyway, the generation approach has even less impact and I am starting to prefer that solution. Andriy, is there any reason why you'd prefer your approach over the generation version? Thanks, Max From owner-freebsd-current@FreeBSD.ORG Sun May 15 16:24: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 61C45106564A; Sun, 15 May 2011 16:24:54 +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 10D8A8FC0A; Sun, 15 May 2011 16:24:52 +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 TAA13756; Sun, 15 May 2011 19:24:50 +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 1QLe7e-0000I2-H1; Sun, 15 May 2011 19:24:50 +0300 Message-ID: <4DCFFE52.1090002@FreeBSD.org> Date: Sun, 15 May 2011 19:24:50 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.17) Gecko/20110503 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Max Laier References: <4DCD357D.6000109@FreeBSD.org> <4DCFE8FA.6080005@FreeBSD.org> <4DCFEE33.5090808@FreeBSD.org> <201105151209.13846.max@love2party.net> In-Reply-To: <201105151209.13846.max@love2party.net> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD current , Peter Grehan , John Baldwin , neel@FreeBSD.org Subject: Re: proposed smp_rendezvous change 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, 15 May 2011 16:24:54 -0000 on 15/05/2011 19:09 Max Laier said the following: > > I don't think we ever intended to synchronize the local teardown part, and I > believe that is the correct behavior for this API. > > This version is sufficiently close to what I have, so I am resonably sure that > it will work for us. It seems, however, that if we move to check to after > picking up the lock anyway, the generation approach has even less impact and I > am starting to prefer that solution. > > Andriy, is there any reason why you'd prefer your approach over the generation > version? No reason. And I even haven't said that I prefer it :-) I just wanted to show and explain it as apparently there was some misunderstanding about it. I think that generation count approach could even have a little bit better performance while perhaps being a tiny bit less obvious. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Sun May 15 16:36: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 8AA04106566B; Sun, 15 May 2011 16:36:49 +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 48FDE8FC1E; Sun, 15 May 2011 16:36:47 +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 TAA13892; Sun, 15 May 2011 19:36:46 +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 1QLeJC-0000If-Az; Sun, 15 May 2011 19:36:46 +0300 Message-ID: <4DD0011D.40000@FreeBSD.org> Date: Sun, 15 May 2011 19:36:45 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.17) Gecko/20110503 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: John Baldwin References: <4DCD357D.6000109@FreeBSD.org> <4DCE9EF0.3050803@FreeBSD.org> <4DCF7CF0.1080508@FreeBSD.org> <4DCFE8FA.6080005@FreeBSD.org> <4DCFEE33.5090808@FreeBSD.org> In-Reply-To: <4DCFEE33.5090808@FreeBSD.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Max Laier , FreeBSD current , neel@FreeBSD.org, Peter Grehan Subject: Re: proposed smp_rendezvous change 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, 15 May 2011 16:36:49 -0000 on 15/05/2011 18:16 John Baldwin said the following: > On 5/15/11 10:53 AM, Andriy Gapon wrote: >> on 15/05/2011 10:12 Andriy Gapon said the following: >>> on 14/05/2011 18:25 John Baldwin said the following: >>>> Hmmm, so this is not actually sufficient. NetApp ran into a very similar race >>>> with virtual CPUs in BHyVe. In their case because virtual CPUs are threads >>>> that >>>> can be preempted, they have a chance at a longer race. >>>> >>>> The problem that they see is that even though the values have been updated, the >>>> next CPU to start a rendezvous can clear smp_rv_waiters[2] to zero before >>>> one of >>>> the other CPUs notices that it has finished. >>> >>> As a follow up to my previous question. Have you noticed that in my patch no >>> slave CPU actually waits/spins on smp_rv_waiters[2]? It's always only master >>> CPU (and under smp_ipi_mtx). >>> >> >> Here's a cleaner version of my approach to the fix. >> This one does not remove the initial wait on smp_rv_waiters[0] in >> smp_rendezvous_action() and thus does not renumber all smp_rv_waiters[] members >> and thus hopefully should be clearer. >> >> Index: sys/kern/subr_smp.c >> =================================================================== >> --- sys/kern/subr_smp.c (revision 221943) >> +++ sys/kern/subr_smp.c (working copy) >> @@ -110,7 +110,7 @@ static void (*volatile smp_rv_setup_func)(void *ar >> static void (*volatile smp_rv_action_func)(void *arg); >> static void (*volatile smp_rv_teardown_func)(void *arg); >> static void *volatile smp_rv_func_arg; >> -static volatile int smp_rv_waiters[3]; >> +static volatile int smp_rv_waiters[4]; >> >> /* >> * Shared mutex to restrict busywaits between smp_rendezvous() and >> @@ -338,11 +338,15 @@ smp_rendezvous_action(void) >> >> /* spin on exit rendezvous */ >> atomic_add_int(&smp_rv_waiters[2], 1); >> - if (local_teardown_func == smp_no_rendevous_barrier) >> + if (local_teardown_func == smp_no_rendevous_barrier) { >> + atomic_add_int(&smp_rv_waiters[3], 1); >> return; >> + } >> while (smp_rv_waiters[2]< smp_rv_ncpus) >> cpu_spinwait(); >> >> + atomic_add_int(&smp_rv_waiters[3], 1); >> + >> /* teardown function */ >> if (local_teardown_func != NULL) >> local_teardown_func(local_func_arg); >> @@ -377,6 +381,9 @@ smp_rendezvous_cpus(cpumask_t map, >> /* obtain rendezvous lock */ >> mtx_lock_spin(&smp_ipi_mtx); >> >> + while (smp_rv_waiters[3]< smp_rv_ncpus) >> + cpu_spinwait(); >> + >> /* set static function pointers */ >> smp_rv_ncpus = ncpus; >> smp_rv_setup_func = setup_func; >> @@ -385,6 +392,7 @@ smp_rendezvous_cpus(cpumask_t map, >> smp_rv_func_arg = arg; >> smp_rv_waiters[1] = 0; >> smp_rv_waiters[2] = 0; >> + smp_rv_waiters[3] = 0; >> atomic_store_rel_int(&smp_rv_waiters[0], 0); >> >> /* signal other processors, which will enter the IPI with interrupts off */ > > Ahh, so the bump is after the change. I do think this will still be ok > and I probably just didn't explain it well to Neel. I wonder though > if the bump shouldn't happen until after the call of the local teardown > function? That should not be necessary according to my understanding unless we have a reason to care about potentially disappearing function text. Teardown function pointer and argument are locally cached and I don't see any problems with a new rendezvous being setup and run while teardowns of the previous one are still running. On the other hand, you might be onto something here. If the argument is allocated in temporary storage (e.g. on stack) and the teardown function actually uses the argument, then it's not safe to deallocate the argument until all of the teardowns are done. In this case the master CPU should wait not only until all actions are done, but also until all teardowns are done. The current code doesn't do that. And I am not sure if we actually would want to add this safety net or just document the behavior and put a burden on smp_rendezvous API users. BTW, I don't think that we ever use smp_rendezvous() in its full glory, i.e. with non-trivial setup, action and teardown (except perhaps for jkim's stress test). OpenSolaris seems to be doing just fine with the following three types of simpler CPU cross-calls (as they call them): 1. async - a master CPU requests an action to be executed on target CPUs but doesn't wait for anything - we have no explicit equivalent for this 2. call - a master CPU requests an action to be executed on target CPUs and waits until all the target CPUs have finished executing it - this would be equivalent smp_rendezvous_cpus(no_barrier, action, no_barrier) 3. synch - a master CPU requests an action to be executed on target CPUs and waits until all the target CPUs have finished executing it and the slave CPUs are also waiting for their siblings to be done - this would be equivalent smp_rendezvous_cpus(no_barrier, action, NULL) Seems that our current code doesn't use/need more than that as well. But I really like the capability that smp_rendezvous_cpus() potentially provides. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Sun May 15 18: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 25E61106566C for ; Sun, 15 May 2011 18:22:33 +0000 (UTC) (envelope-from boland37@xs4all.nl) Received: from smtp-vbr2.xs4all.nl (smtp-vbr2.xs4all.nl [194.109.24.22]) by mx1.freebsd.org (Postfix) with ESMTP id AB3758FC15 for ; Sun, 15 May 2011 18:22:31 +0000 (UTC) Received: from charlemagne.boland.org (59-36-215.ftth.xms.internl.net [82.215.36.59]) (authenticated bits=0) by smtp-vbr2.xs4all.nl (8.13.8/8.13.8) with ESMTP id p4FI5bno068086 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Sun, 15 May 2011 20:05:37 +0200 (CEST) (envelope-from boland37@xs4all.nl) Message-ID: <4DD015F1.6090203@xs4all.nl> Date: Sun, 15 May 2011 20:05:37 +0200 From: Michiel Boland User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.17) Gecko/20110502 Thunderbird/3.1.10 MIME-Version: 1.0 To: FreeBSD Current Content-Type: multipart/mixed; boundary="------------080509060508010808060307" X-Virus-Scanned: by XS4ALL Virus Scanner Subject: -CURRENT: mountroot failed 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, 15 May 2011 18:22:33 -0000 This is a multi-part message in MIME format. --------------080509060508010808060307 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Recent current (from today) is unable to mount root. (AMD64 with ICH7 and SATA disk) After boot it halts with Mounting from ufs:/dev/ada0s1a failed with error 19 A kernel from 1 May does not exhibit this problem. It's basically a GENERIC kernel, with WITNESS and INVARIANTS taken out. I've attached verbose boot logs from both the old and the new kernel Any ideas how to troubleshoot this further? Cheers Michiel --------------080509060508010808060307 Content-Type: text/plain; name="boot-old.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="boot-old.txt" GDB: no debug ports present KDB: debugger backends: ddb KDB: current backend: ddb SMAP type=01 base=0000000000000000 len=000000000009fc00 SMAP type=02 base=000000000009fc00 len=0000000000000400 SMAP type=02 base=00000000000e4000 len=000000000001c000 SMAP type=01 base=0000000000100000 len=00000000ddc80000 SMAP type=03 base=00000000ddd80000 len=000000000000e000 SMAP type=04 base=00000000ddd8e000 len=0000000000042000 SMAP type=02 base=00000000dddd0000 len=0000000000010000 SMAP type=02 base=00000000ddde0000 len=0000000000020000 SMAP type=02 base=00000000fee00000 len=0000000000001000 SMAP type=02 base=00000000fff00000 len=0000000000100000 SMAP type=01 base=0000000100000000 len=0000000020000000 Table 'FACP' at 0xddd80290 Table 'APIC' at 0xddd80390 APIC: Found table at 0xddd80390 APIC: Using the MADT enumerator. MADT: Found CPU APIC ID 0 ACPI ID 1: enabled SMP: Added CPU 0 (AP) MADT: Found CPU APIC ID 1 ACPI ID 2: enabled SMP: Added CPU 1 (AP) MADT: Found CPU APIC ID 2 ACPI ID 3: enabled SMP: Added CPU 2 (AP) MADT: Found CPU APIC ID 3 ACPI ID 4: enabled SMP: Added CPU 3 (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. FreeBSD 9.0-CURRENT #0: Sun May 1 15:34:17 CEST 2011 root@charlemagne.boland.org:/usr/obj/usr/src/sys/CHARLEMAGNE amd64 Table 'FACP' at 0xddd80290 Table 'APIC' at 0xddd80390 Table 'MCFG' at 0xddd80400 Table 'OEMB' at 0xddd8e040 Table 'HPET' at 0xddd87630 Table 'GSCI' at 0xddd8e0d0 ACPI: No SRAT table found Preloaded elf kernel "/boot/kernel.ok/kernel" at 0xffffffff81369000. Preloaded elf obj module "/boot/kernel.ok/snd_hda.ko" at 0xffffffff813691f8. Preloaded elf obj module "/boot/kernel.ok/sound.ko" at 0xffffffff81369828. Calibrating TSC clock ... TSC clock: 2500056788 Hz CPU: Intel(R) Core(TM)2 Quad CPU Q8300 @ 2.50GHz (2500.06-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x1067a Family = 6 Model = 17 Stepping = 10 Features=0xbfebfbff Features2=0x408e39d AMD Features=0x20100800 AMD Features2=0x1 TSC: P-state invariant, performance statistics real memory = 4294967296 (4096 MB) Physical memory chunk(s): 0x0000000000001000 - 0x000000000009bfff, 634880 bytes (155 pages) 0x0000000000100000 - 0x00000000001fffff, 1048576 bytes (256 pages) 0x0000000001399000 - 0x00000000d5607fff, 3559321600 bytes (868975 pages) 0x0000000100000000 - 0x000000011ffeffff, 536805376 bytes (131056 pages) avail memory = 4069261312 (3880 MB) Event timer "LAPIC" quality 400 ACPI APIC Table: INTR: Adding local APIC 1 as a target INTR: Adding local APIC 2 as a target INTR: Adding local APIC 3 as a target FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs FreeBSD/SMP: 1 package(s) x 4 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 x86bios: IVT 0x000000-0x0004ff at 0xfffffe0000000000 x86bios: SSEG 0x001000-0x001fff at 0xffffff8000023000 x86bios: EBDA 0x09f000-0x09ffff at 0xfffffe000009f000 x86bios: ROM 0x0a0000-0x0fefff at 0xfffffe00000a0000 APIC: CPU 0 has ACPI ID 1 APIC: CPU 1 has ACPI ID 2 APIC: CPU 2 has ACPI ID 3 APIC: CPU 3 has ACPI ID 4 ULE: setup cpu 0 ULE: setup cpu 1 ULE: setup cpu 2 ULE: setup cpu 3 ACPI: RSDP 0xfbd50 00024 (v02 ACPIAM) ACPI: XSDT 0xddd80100 00054 (v01 A_M_I_ OEMXSDT 11000912 MSFT 00000097) ACPI: FACP 0xddd80290 000F4 (v03 A_M_I_ OEMFACP 11000912 MSFT 00000097) ACPI: DSDT 0xddd80440 071EA (v01 A1434 A1434000 00000000 INTL 20060113) ACPI: FACS 0xddd8e000 00040 ACPI: APIC 0xddd80390 0006C (v01 A_M_I_ OEMAPIC 11000912 MSFT 00000097) ACPI: MCFG 0xddd80400 0003C (v01 A_M_I_ OEMMCFG 11000912 MSFT 00000097) ACPI: OEMB 0xddd8e040 00089 (v01 A_M_I_ AMI_OEM 11000912 MSFT 00000097) ACPI: HPET 0xddd87630 00038 (v01 A_M_I_ OEMHPET 11000912 MSFT 00000097) ACPI: GSCI 0xddd8e0d0 02024 (v01 A_M_I_ GMCHSCI 11000912 MSFT 00000097) MADT: Found IO APIC ID 4, Interrupt 0 at 0xfec00000 ioapic0: Routing external 8259A's -> intpin 0 MADT: Interrupt override: source 0, irq 2 ioapic0: Routing IRQ 0 -> intpin 2 MADT: Interrupt override: source 9, irq 9 ioapic0: intpin 9 trigger: level ioapic0 irqs 0-23 on motherboard cpu0 BSP: ID: 0x00000000 VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000100ef therm: 0x00010000 err: 0x000000f0 pmc: 0x00010400 snd_unit_init() u=0x00ff8000 [512] d=0x00007c00 [32] c=0x000003ff [1024] feeder_register: snd_unit=-1 snd_maxautovchans=16 latency=5 feeder_rate_min=1 feeder_rate_max=2016000 feeder_rate_round=25 wlan: <802.11 Link Layer> kbd: new array size 4 kbd1 at kbdmux0 mem: nfslock: pseudo-device null: random: io: hptrr: RocketRAID 17xx/2xxx SATA controller driver v1.2 acpi0: on motherboard PCIe: Memory Mapped configuration base @ 0xf0000000 ioapic0: routing intpin 9 (ISA IRQ 9) to lapic 0 vector 48 ACPI: Executed 1 blocks of module-level executable AML code acpi0: Power Button (fixed) acpi0: reservation of fed1c000, 4000 (3) failed acpi0: reservation of fed20000, 70000 (3) failed acpi0: reservation of ffc00000, 300000 (3) failed acpi0: reservation of fec00000, 1000 (3) failed acpi0: reservation of fee00000, 1000 (3) failed acpi0: reservation of f0000000, 4000000 (3) failed acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, ddd00000 (3) failed ACPI timer: 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 -> 10 Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 cpu0: on acpi0 cpu0: switching to generic Cx mode cpu1: on acpi0 cpu2: on acpi0 cpu3: on acpi0 pci_link0: Index IRQ Rtd Ref IRQs Initial Probe 0 3 N 0 3 4 5 6 7 10 12 14 15 Validation 0 3 N 0 3 4 5 6 7 10 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 10 12 14 15 pci_link1: Index IRQ Rtd Ref IRQs Initial Probe 0 5 N 0 3 4 5 6 7 10 12 14 15 Validation 0 5 N 0 3 4 5 6 7 10 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 10 12 14 15 pci_link2: Index IRQ Rtd Ref IRQs Initial Probe 0 10 N 0 3 4 5 6 7 10 12 14 15 Validation 0 10 N 0 3 4 5 6 7 10 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 10 12 14 15 pci_link3: Index IRQ Rtd Ref IRQs Initial Probe 0 10 N 0 3 4 5 6 7 10 12 14 15 Validation 0 10 N 0 3 4 5 6 7 10 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 10 12 14 15 pci_link4: Index IRQ Rtd Ref IRQs Initial Probe 0 5 N 0 3 4 5 6 7 10 12 14 15 Validation 0 5 N 0 3 4 5 6 7 10 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 10 12 14 15 pci_link5: Index IRQ Rtd Ref IRQs Initial Probe 0 7 N 0 3 4 5 6 7 10 12 14 15 Validation 0 7 N 0 3 4 5 6 7 10 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 10 12 14 15 pci_link6: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 11 Validation 0 11 N 0 11 After Disable 0 255 N 0 11 pci_link7: Index IRQ Rtd Ref IRQs Initial Probe 0 6 N 0 3 4 5 6 7 10 12 14 15 Validation 0 6 N 0 3 4 5 6 7 10 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 10 12 14 15 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pci0: domain=0, physical bus=0 found-> vendor=0x8086, dev=0x2e30, revid=0x03 domain=0, bus=0, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x2090, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x2e32, revid=0x03 domain=0, bus=0, slot=2, func=0 class=03-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0090, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=3 powerspec 2 supports D0 D3 current D0 MSI supports 1 message map[10]: type Memory, range 64, base 0xfe400000, size 22, enabled map[18]: type Prefetchable Memory, range 64, base 0xe0000000, size 28, enabled map[20]: type I/O Port, range 32, base 0xcc00, size 3, enabled pcib0: matched entry for 0.2.INTA pcib0: slot 2 INTA hardwired to IRQ 16 found-> vendor=0x8086, dev=0x27d8, revid=0x01 domain=0, bus=0, slot=27, func=0 class=04-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0010, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=7 powerspec 2 supports D0 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Memory, range 64, base 0xfe3f8000, size 14, enabled pcib0: matched entry for 0.27.INTA pcib0: slot 27 INTA hardwired to IRQ 21 found-> vendor=0x8086, dev=0x27d0, revid=0x01 domain=0, bus=0, slot=28, func=0 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0104, statreg=0x0010, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x02 (500 ns), maxlat=0x00 (0 ns) intpin=a, irq=3 powerspec 2 supports D0 D3 current D0 MSI supports 1 message pcib0: matched entry for 0.28.INTA pcib0: slot 28 INTA hardwired to IRQ 16 found-> vendor=0x8086, dev=0x27d2, revid=0x01 domain=0, bus=0, slot=28, func=1 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0107, statreg=0x0010, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x02 (500 ns), maxlat=0x00 (0 ns) intpin=b, irq=5 powerspec 2 supports D0 D3 current D0 MSI supports 1 message pcib0: matched entry for 0.28.INTB pcib0: slot 28 INTB hardwired to IRQ 17 found-> vendor=0x8086, dev=0x27d4, revid=0x01 domain=0, bus=0, slot=28, func=2 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0104, statreg=0x0010, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x02 (500 ns), maxlat=0x00 (0 ns) intpin=c, irq=10 powerspec 2 supports D0 D3 current D0 MSI supports 1 message pcib0: matched entry for 0.28.INTC pcib0: slot 28 INTC hardwired to IRQ 18 found-> vendor=0x8086, dev=0x27c8, revid=0x01 domain=0, bus=0, slot=29, func=0 class=0c-03-00, hdrtype=0x00, mfdev=1 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=6 map[20]: type I/O Port, range 32, base 0xc400, size 5, enabled pcib0: matched entry for 0.29.INTA pcib0: slot 29 INTA hardwired to IRQ 23 found-> vendor=0x8086, dev=0x27c9, revid=0x01 domain=0, bus=0, slot=29, func=1 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=10 map[20]: type I/O Port, range 32, base 0xc480, size 5, enabled pcib0: matched entry for 0.29.INTB pcib0: slot 29 INTB hardwired to IRQ 19 found-> vendor=0x8086, dev=0x27ca, revid=0x01 domain=0, bus=0, slot=29, func=2 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=10 map[20]: type I/O Port, range 32, base 0xc800, size 5, enabled pcib0: matched entry for 0.29.INTC pcib0: slot 29 INTC hardwired to IRQ 18 found-> vendor=0x8086, dev=0x27cb, revid=0x01 domain=0, bus=0, slot=29, func=3 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=d, irq=3 map[20]: type I/O Port, range 32, base 0xc880, size 5, enabled pcib0: matched entry for 0.29.INTD pcib0: slot 29 INTD hardwired to IRQ 16 found-> vendor=0x8086, dev=0x27cc, revid=0x01 domain=0, bus=0, slot=29, func=7 class=0c-03-20, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=6 powerspec 2 supports D0 D3 current D0 map[10]: type Memory, range 32, base 0xfe3f7c00, size 10, enabled pcib0: matched entry for 0.29.INTA pcib0: slot 29 INTA hardwired to IRQ 23 found-> vendor=0x8086, dev=0x244e, revid=0xe1 domain=0, bus=0, slot=30, func=0 class=06-04-01, hdrtype=0x01, mfdev=0 cmdreg=0x0107, statreg=0x0010, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x02 (500 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x27b8, revid=0x01 domain=0, bus=0, slot=31, func=0 class=06-01-00, hdrtype=0x00, mfdev=1 cmdreg=0x0007, statreg=0x0210, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x27df, revid=0x01 domain=0, bus=0, slot=31, func=1 class=01-01-8a, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0288, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=255 map[20]: type I/O Port, range 32, base 0xffa0, size 4, enabled found-> vendor=0x8086, dev=0x27c0, revid=0x01 domain=0, bus=0, slot=31, func=2 class=01-01-8f, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x02b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=11 powerspec 2 supports D0 D3 current D0 map[10]: type I/O Port, range 32, base 0xc080, size 3, enabled map[14]: type I/O Port, range 32, base 0xc000, size 2, enabled map[18]: type I/O Port, range 32, base 0xbc00, size 3, enabled map[1c]: type I/O Port, range 32, base 0xb880, size 2, enabled map[20]: type I/O Port, range 32, base 0xb800, size 4, enabled pcib0: matched entry for 0.31.INTB pcib0: slot 31 INTB hardwired to IRQ 22 vgapci0: port 0xcc00-0xcc07 mem 0xfe400000-0xfe7fffff,0xe0000000-0xefffffff irq 16 at device 2.0 on pci0 agp0: on vgapci0 agp0: aperture size is 256M, detected 32764k stolen memory hdac0: mem 0xfe3f8000-0xfe3fbfff irq 21 at device 27.0 on pci0 hdac0: HDA Driver Revision: 20100226_0142 hdac0: attempting to allocate 1 MSI vectors (1 supported) msi: routing MSI IRQ 256 to local APIC 0 vector 49 hdac0: using IRQ 256 for MSI hdac0: Caps: OSS 4, ISS 4, BSS 0, NSDO 1, 64bit, CORB 256, RIRB 256 pcib1: irq 16 at device 28.0 on pci0 pcib1: domain 0 pcib1: secondary bus 3 pcib1: subordinate bus 3 pcib1: I/O decode 0x0-0x0 pcib1: no prefetched decode pci3: on pcib1 pci3: domain=0, physical bus=3 pcib2: irq 17 at device 28.1 on pci0 pcib2: domain 0 pcib2: secondary bus 2 pcib2: subordinate bus 2 pcib2: I/O decode 0xd000-0xdfff pcib2: memory decode 0xfe800000-0xfe8fffff pcib2: prefetched decode 0xfdf00000-0xfdffffff pci2: on pcib2 pci2: domain=0, physical bus=2 found-> vendor=0x10ec, dev=0x8136, revid=0x02 domain=0, bus=2, slot=0, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0010, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=5 powerspec 3 supports D0 D1 D2 D3 current D0 MSI supports 1 message, 64 bit MSI-X supports 2 messages in map 0x20 map[10]: type I/O Port, range 32, base 0xd800, size 8, enabled pcib2: requested I/O range 0xd800-0xd8ff: in range map[18]: type Prefetchable Memory, range 64, base 0xfdfff000, size 12, enabled pcib2: requested memory range 0xfdfff000-0xfdffffff: good map[20]: type Prefetchable Memory, range 64, base 0xfdfe0000, size 16, enabled pcib2: requested memory range 0xfdfe0000-0xfdfeffff: good pcib2: matched entry for 2.0.INTA pcib2: slot 0 INTA hardwired to IRQ 17 re0: port 0xd800-0xd8ff mem 0xfdfff000-0xfdffffff,0xfdfe0000-0xfdfeffff irq 17 at device 0.0 on pci2 re0: MSI count : 1 re0: MSI-X count : 2 re0: attempting to allocate 1 MSI-X vectors (2 supported) msi: routing MSI-X IRQ 257 to local APIC 0 vector 50 re0: using IRQ 257 for MSI-X re0: Using 1 MSI-X message re0: Chip rev. 0x24800000 re0: MAC rev. 0x00400000 miibus0: on re0 rlphy0: PHY 1 on miibus0 rlphy0: 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, 100baseTX-FDX, 100baseTX-FDX-flow, auto, auto-flow re0: bpf attached re0: Ethernet address: 90:e6:ba:8a:36:a2 pcib3: irq 18 at device 28.2 on pci0 pcib3: domain 0 pcib3: secondary bus 1 pcib3: subordinate bus 1 pcib3: I/O decode 0x0-0x0 pcib3: no prefetched decode pci1: on pcib3 pci1: domain=0, physical bus=1 uhci0: port 0xc400-0xc41f irq 23 at device 29.0 on pci0 ioapic0: routing intpin 23 (PCI IRQ 23) to lapic 0 vector 51 uhci0: LegSup = 0x2f00 usbus0: on uhci0 usbus0: bpf attached uhci0: usbpf: Attached uhci1: port 0xc480-0xc49f irq 19 at device 29.1 on pci0 ioapic0: routing intpin 19 (PCI IRQ 19) to lapic 0 vector 52 uhci1: LegSup = 0x2f00 usbus1: on uhci1 usbus1: bpf attached uhci1: usbpf: Attached uhci2: port 0xc800-0xc81f irq 18 at device 29.2 on pci0 ioapic0: routing intpin 18 (PCI IRQ 18) to lapic 0 vector 53 uhci2: LegSup = 0x2f00 usbus2: on uhci2 usbus2: bpf attached uhci2: usbpf: Attached uhci3: port 0xc880-0xc89f irq 16 at device 29.3 on pci0 ioapic0: routing intpin 16 (PCI IRQ 16) to lapic 0 vector 54 uhci3: LegSup = 0x2f00 usbus3: on uhci3 usbus3: bpf attached uhci3: usbpf: Attached ehci0: mem 0xfe3f7c00-0xfe3f7fff irq 23 at device 29.7 on pci0 usbus4: EHCI version 1.0 usbus4: on ehci0 usbus4: bpf attached ehci0: usbpf: Attached pcib4: at device 30.0 on pci0 pcib4: domain 0 pcib4: secondary bus 4 pcib4: subordinate bus 4 pcib4: I/O decode 0xe000-0xefff pcib4: memory decode 0xfe900000-0xfebfffff pcib4: no prefetched decode pcib4: Subtractively decoded bridge. pci4: on pcib4 pci4: domain=0, physical bus=4 found-> vendor=0x8086, dev=0x1229, revid=0x08 domain=0, bus=4, slot=0, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0017, statreg=0x0290, cachelnsz=8 (dwords) lattimer=0x40 (1920 ns), mingnt=0x08 (2000 ns), maxlat=0x38 (14000 ns) intpin=a, irq=5 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type Memory, range 32, base 0xfebff000, size 12, enabled pcib4: requested memory range 0xfebff000-0xfebfffff: good map[14]: type I/O Port, range 32, base 0xec00, size 6, enabled pcib4: requested I/O range 0xec00-0xec3f: in range map[18]: type Memory, range 32, base 0xfea00000, size 20, enabled pcib4: requested memory range 0xfea00000-0xfeafffff: good pcib4: matched entry for 4.0.INTA pcib4: slot 0 INTA hardwired to IRQ 20 fxp0: port 0xec00-0xec3f mem 0xfebff000-0xfebfffff,0xfea00000-0xfeafffff irq 20 at device 0.0 on pci4 fxp0: using memory space register mapping fxp0: PCI IDs: 8086 1229 8086 000c 0008 fxp0: Dynamic Standby mode is disabled miibus1: on fxp0 inphy0: PHY 1 on miibus1 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto, auto-flow fxp0: bpf attached fxp0: Ethernet address: 00:d0:b7:70:12:7f ioapic0: routing intpin 20 (PCI IRQ 20) to lapic 0 vector 55 isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xffa0-0xffaf at device 31.1 on pci0 ata0: on atapci0 ioapic0: routing intpin 14 (ISA IRQ 14) to lapic 0 vector 56 atapci1: port 0xc080-0xc087,0xc000-0xc003,0xbc00-0xbc07,0xb880-0xb883,0xb800-0xb80f irq 22 at device 31.2 on pci0 ioapic0: routing intpin 22 (PCI IRQ 22) to lapic 0 vector 57 ata2: on atapci1 ata3: on atapci1 acpi_button0: on acpi0 attimer0: port 0x40-0x43 irq 0 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 ioapic0: routing intpin 2 (ISA IRQ 0) to lapic 0 vector 58 Event timer "i8254" frequency 1193182 Hz quality 100 atrtc0: port 0x70-0x71 irq 8 on acpi0 atrtc0: registered as a time-of-day clock (resolution 1000000us, adjustment 0.500000000s) ioapic0: routing intpin 8 (ISA IRQ 8) to lapic 0 vector 59 Event timer "RTC" frequency 32768 Hz quality 0 hpet0: iomem 0xfed00000-0xfed003ff on acpi0 hpet0: vendor 0x8086, rev 0x1, 14318180Hz 64bit, 3 timers, legacy route hpet0: t0: irqs 0x00f00000 (0), 64bit, periodic hpet0: t1: irqs 0x00f00000 (0) hpet0: t2: irqs 0x00f00800 (0) Timecounter "HPET" frequency 14318180 Hz quality 900 ioapic0: routing intpin 21 (PCI IRQ 21) to lapic 0 vector 60 Event timer "HPET" frequency 14318180 Hz quality 450 Event timer "HPET1" frequency 14318180 Hz quality 440 Event timer "HPET2" frequency 14318180 Hz quality 440 uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 ioapic0: routing intpin 4 (ISA IRQ 4) to lapic 0 vector 61 uart0: fast interrupt uart0: console (9600,n,8,1) acpi0: wakeup code va 0xffffff8117c6e000 pa 0x4000 ahc_isa_probe 0: ioport 0xc00 alloc failed ahc_isa_probe 11: ioport 0xbc00 alloc failed ahc_isa_probe 12: ioport 0xcc00 alloc failed ahc_isa_probe 14: ioport 0xec00 alloc failed ex_isa_identify() isa_probe_children: disabling PnP devices atrtc: atrtc0 already exists; skipping it attimer: attimer0 already exists; skipping it sc: sc0 already exists; skipping it uart: uart0 already exists; skipping it isa_probe_children: probing non-PnP devices orm0: at iomem 0xcc800-0xcd7ff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x100> sc0: fb0, kbd1, terminal emulator: scteken (teken terminal) vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 kbd0: atkbd0, generic (0), config:0x0, flags:0x3f0000 ioapic0: routing intpin 1 (ISA IRQ 1) to lapic 0 vector 62 atkbd0: [GIANT-LOCKED] psm0: unable to allocate IRQ fdc0 failed to probe at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 ppc0: cannot reserve I/O port range ppc0: failed to probe at irq 7 on isa0 uart1: failed to probe at port 0x2f8-0x2ff irq 3 on isa0 isa_probe_children: probing PnP devices est0: on cpu0 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 616472506004725 device_attach: est0 attach returned 6 p4tcc0: on cpu0 est1: on cpu1 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 616472506004725 device_attach: est1 attach returned 6 p4tcc1: on cpu1 est2: on cpu2 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 616472506004725 device_attach: est2 attach returned 6 p4tcc2: on cpu2 est3: on cpu3 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 616472506004725 device_attach: est3 attach returned 6 p4tcc3: on cpu3 Device configuration finished. procfs registered Timecounter "TSC" frequency 2500056788 Hz quality -100 Timecounters tick every 1.000 msec vlan: initialized, using hash tables with chaining lo0: bpf attached hptrr: no controller detected. hdac0: Probing codec #0... hdac0: HDA Codec #0: Realtek ALC662 hdac0: HDA Codec ID: 0x10ec0662 hdac0: Vendor: 0x10ec hdac0: Device: 0x0662 hdac0: Revision: 0x01 hdac0: Stepping: 0x01 hdac0: PCI Subvendor: 0x83901043 hdac0: Found audio FG nid=1 startnode=2 endnode=39 total=37 hdac0: hdac0: Processing audio FG cad=0 nid=1... hdac0: GPIO: 0x40000002 NumGPIO=2 NumGPO=0 NumGPI=0 GPIWake=0 GPIUnsol=1 hdac0: nid 20 0x01014010 as 1 seq 0 Line-out Jack jack 1 loc 1 color Green misc 0 hdac0: nid 21 0x411111f0 as 15 seq 0 Speaker None jack 1 loc 1 color Black misc 1 hdac0: nid 22 0x411111f0 as 15 seq 0 Speaker None jack 1 loc 1 color Black misc 1 hdac0: nid 24 0x01a19830 as 3 seq 0 Mic Jack jack 1 loc 1 color Pink misc 8 hdac0: nid 25 0x02a19840 as 4 seq 0 Mic Jack jack 1 loc 2 color Pink misc 8 hdac0: nid 26 0x0181303f as 3 seq 15 Line-in Jack jack 1 loc 1 color Blue misc 0 hdac0: nid 27 0x02214020 as 2 seq 0 Headphones Jack jack 1 loc 2 color Green misc 0 hdac0: nid 28 0x411111f0 as 15 seq 0 Speaker None jack 1 loc 1 color Black misc 1 hdac0: nid 29 0x4004c601 as 0 seq 1 Line-out None jack 4 loc 0 color Res.C misc 6 hdac0: nid 30 0x411111f0 as 15 seq 0 Speaker None jack 1 loc 1 color Black misc 1 hdac0: Patched pins configuration: hdac0: nid 20 0x01014010 as 1 seq 0 Line-out Jack jack 1 loc 1 color Green misc 0 hdac0: nid 21 0x411111f0 as 15 seq 0 Speaker None jack 1 loc 1 color Black misc 1 [DISABLED] hdac0: nid 22 0x411111f0 as 15 seq 0 Speaker None jack 1 loc 1 color Black misc 1 [DISABLED] hdac0: nid 24 0x01a19830 as 3 seq 0 Mic Jack jack 1 loc 1 color Pink misc 8 hdac0: nid 25 0x02a19840 as 4 seq 0 Mic Jack jack 1 loc 2 color Pink misc 8 hdac0: nid 26 0x0181303f as 3 seq 15 Line-in Jack jack 1 loc 1 color Blue misc 0 hdac0: nid 27 0x02214020 as 2 seq 0 Headphones Jack jack 1 loc 2 color Green misc 0 hdac0: nid 28 0x411111f0 as 15 seq 0 Speaker None jack 1 loc 1 color Black misc 1 [DISABLED] hdac0: nid 29 0x4004c601 as 0 seq 1 Line-out None jack 4 loc 0 color Res.C misc 6 [DISABLED] hdac0: nid 30 0x411111f0 as 15 seq 0 Speaker None jack 1 loc 1 color Black misc 1 [DISABLED] hdac0: 4 associations found: hdac0: Association 0 (1) out: hdac0: Pin nid=20 seq=0 hdac0: Association 1 (2) out: hdac0: Pin nid=27 seq=0 hdac0: Association 2 (3) in: hdac0: Pin nid=24 seq=0 hdac0: Pin nid=26 seq=15 hdac0: Association 3 (4) in: hdac0: Pin nid=25 seq=0 hdac0: Tracing association 0 (1) hdac0: Pin 20 traced to DAC 2 hdac0: Association 0 (1) trace succeeded hdac0: Tracing association 1 (2) hdac0: Pin 27 traced to DAC 4 hdac0: Association 1 (2) trace succeeded hdac0: Tracing association 2 (3) hdac0: Pin 24 traced to ADC 8 hdac0: Pin 26 traced to ADC 8 hdac0: Association 2 (3) trace succeeded hdac0: Tracing association 3 (4) hdac0: Pin 25 traced to ADC 9 hdac0: Association 3 (4) trace succeeded hdac0: Tracing input monitor hdac0: Tracing nid 11 to out hdac0: nid 11 is input monitor hdac0: Tracing nid 34 to out hdac0: Tracing nid 35 to out hdac0: Tracing other input monitors hdac0: Tracing nid 24 to out hdac0: Tracing nid 25 to out hdac0: Tracing nid 26 to out hdac0: Tracing beeper hdac0: FG config/quirks: forcestereo ivref50 ivref80 ivref100 ivref hdac0: hdac0: +-------------------+ hdac0: | DUMPING HDA NODES | hdac0: +-------------------+ hdac0: hdac0: Default Parameter hdac0: ----------------- hdac0: Stream cap: 0x00000001 hdac0: PCM hdac0: PCM cap: 0x000e0160 hdac0: 16 20 24 bits, 44 48 96 KHz hdac0: IN amp: 0x00000000 hdac0: OUT amp: 0x00000000 hdac0: hdac0: nid: 2 hdac0: Name: audio output hdac0: Widget cap: 0x0000001d hdac0: STEREO hdac0: Association: 0 (0x00000001) hdac0: OSS: pcm (pcm) hdac0: Stream cap: 0x00000001 hdac0: PCM hdac0: PCM cap: 0x000e0160 hdac0: 16 20 24 bits, 44 48 96 KHz hdac0: Output amp: 0x00034040 hdac0: mute=0 step=64 size=3 offset=64 hdac0: hdac0: nid: 3 [DISABLED] hdac0: Name: audio output hdac0: Widget cap: 0x0000001d hdac0: STEREO hdac0: Stream cap: 0x00000001 hdac0: PCM hdac0: PCM cap: 0x000e0160 hdac0: 16 20 24 bits, 44 48 96 KHz hdac0: Output amp: 0x00034040 hdac0: mute=0 step=64 size=3 offset=64 hdac0: hdac0: nid: 4 hdac0: Name: audio output hdac0: Widget cap: 0x0000001d hdac0: STEREO hdac0: Association: 1 (0x00000001) hdac0: OSS: pcm (pcm) hdac0: Stream cap: 0x00000001 hdac0: PCM hdac0: PCM cap: 0x000e0160 hdac0: 16 20 24 bits, 44 48 96 KHz hdac0: Output amp: 0x00034040 hdac0: mute=0 step=64 size=3 offset=64 hdac0: hdac0: nid: 5 [DISABLED] hdac0: Name: vendor widget hdac0: Widget cap: 0x00f00000 hdac0: hdac0: nid: 6 [DISABLED] hdac0: Name: audio output hdac0: Widget cap: 0x00000211 hdac0: DIGITAL STEREO hdac0: Stream cap: 0x00000001 hdac0: PCM hdac0: PCM cap: 0x000e0160 hdac0: 16 20 24 bits, 44 48 96 KHz hdac0: hdac0: nid: 7 [DISABLED] hdac0: Name: vendor widget hdac0: Widget cap: 0x00f00000 hdac0: hdac0: nid: 8 hdac0: Name: audio input hdac0: Widget cap: 0x0010011b hdac0: STEREO hdac0: Association: 2 (0x00008001) hdac0: Stream cap: 0x00000001 hdac0: PCM hdac0: PCM cap: 0x00060160 hdac0: 16 20 bits, 44 48 96 KHz hdac0: Input amp: 0x80051f09 hdac0: mute=1 step=31 size=5 offset=9 hdac0: connections: 1 hdac0: | hdac0: + <- nid=35 [audio mixer] hdac0: hdac0: nid: 9 hdac0: Name: audio input hdac0: Widget cap: 0x0010011b hdac0: STEREO hdac0: Association: 3 (0x00000001) hdac0: Stream cap: 0x00000001 hdac0: PCM hdac0: PCM cap: 0x00060160 hdac0: 16 20 bits, 44 48 96 KHz hdac0: Input amp: 0x80051f09 hdac0: mute=1 step=31 size=5 offset=9 hdac0: connections: 1 hdac0: | hdac0: + <- nid=34 [audio mixer] hdac0: hdac0: nid: 10 [DISABLED] hdac0: Name: vendor widget hdac0: Widget cap: 0x00f00000 hdac0: hdac0: nid: 11 hdac0: Name: audio mixer hdac0: Widget cap: 0x0020010b hdac0: STEREO hdac0: Association: 2 (0x00008001) hdac0: OSS: mix (mix) hdac0: Input amp: 0x80051f17 hdac0: mute=1 step=31 size=5 offset=23 hdac0: connections: 9 hdac0: | hdac0: + <- nid=24 [pin: Mic (Pink Jack)] hdac0: + [DISABLED] <- nid=25 [pin: Mic (Pink Jack)] hdac0: + <- nid=26 [pin: Line-in (Blue Jack)] hdac0: + [DISABLED] <- nid=27 [pin: Headphones (Green Jack)] hdac0: + [DISABLED] <- nid=28 [pin: Speaker (None)] [DISABLED] hdac0: + [DISABLED] <- nid=29 [pin: Line-out (None)] [DISABLED] hdac0: + [DISABLED] <- nid=20 [pin: Line-out (Green Jack)] hdac0: + [DISABLED] <- nid=21 [pin: Speaker (None)] [DISABLED] hdac0: + [DISABLED] <- nid=22 [pin: Speaker (None)] [DISABLED] hdac0: hdac0: nid: 12 hdac0: Name: audio mixer hdac0: Widget cap: 0x0020010b hdac0: STEREO hdac0: Association: 0 (0x00000001) hdac0: OSS: pcm, mix hdac0: Input amp: 0x80000000 hdac0: mute=1 step=0 size=0 offset=0 hdac0: connections: 2 hdac0: | hdac0: + <- nid=2 [audio output] hdac0: + <- nid=11 [audio mixer] hdac0: hdac0: nid: 13 [DISABLED] hdac0: Name: audio mixer hdac0: Widget cap: 0x0020010b hdac0: STEREO hdac0: Input amp: 0x80000000 hdac0: mute=1 step=0 size=0 offset=0 hdac0: connections: 2 hdac0: | hdac0: + [DISABLED] <- nid=3 [audio output] [DISABLED] hdac0: + [DISABLED] <- nid=11 [audio mixer] hdac0: hdac0: nid: 14 hdac0: Name: audio mixer hdac0: Widget cap: 0x0020010b hdac0: STEREO hdac0: Association: 1 (0x00000001) hdac0: OSS: pcm, mix hdac0: Input amp: 0x80000000 hdac0: mute=1 step=0 size=0 offset=0 hdac0: connections: 2 hdac0: | hdac0: + <- nid=4 [audio output] hdac0: + <- nid=11 [audio mixer] hdac0: hdac0: nid: 15 [DISABLED] hdac0: Name: vendor widget hdac0: Widget cap: 0x00f00000 hdac0: hdac0: nid: 16 [DISABLED] hdac0: Name: vendor widget hdac0: Widget cap: 0x00f00000 hdac0: hdac0: nid: 17 [DISABLED] hdac0: Name: vendor widget hdac0: Widget cap: 0x00f00000 hdac0: hdac0: nid: 18 [DISABLED] hdac0: Name: vendor widget hdac0: Widget cap: 0x00f00000 hdac0: hdac0: nid: 19 [DISABLED] hdac0: Name: vendor widget hdac0: Widget cap: 0x00f00000 hdac0: hdac0: nid: 20 hdac0: Name: pin: Line-out (Green Jack) hdac0: Widget cap: 0x0040018d hdac0: UNSOL STEREO hdac0: Association: 0 (0x00000001) hdac0: Pin cap: 0x0001003c hdac0: PDC HP OUT IN EAPD hdac0: Pin config: 0x01014010 hdac0: Pin control: 0x00000040 OUT hdac0: EAPD: 0x00000002 hdac0: Output amp: 0x80000000 hdac0: mute=1 step=0 size=0 offset=0 hdac0: connections: 1 hdac0: | hdac0: + <- nid=12 [audio mixer] hdac0: hdac0: nid: 21 [DISABLED] hdac0: Name: pin: Speaker (None) hdac0: Widget cap: 0x0040018d hdac0: UNSOL STEREO hdac0: Pin cap: 0x00010034 hdac0: PDC OUT IN EAPD hdac0: Pin config: 0x411111f0 hdac0: Pin control: 0x00000000 hdac0: EAPD: 0x00000002 hdac0: Output amp: 0x80000000 hdac0: mute=1 step=0 size=0 offset=0 hdac0: connections: 1 hdac0: | hdac0: + [DISABLED] <- nid=13 [audio mixer] [DISABLED] hdac0: hdac0: nid: 22 [DISABLED] hdac0: Name: pin: Speaker (None) hdac0: Widget cap: 0x0040018d hdac0: UNSOL STEREO hdac0: Pin cap: 0x00000034 hdac0: PDC OUT IN hdac0: Pin config: 0x411111f0 hdac0: Pin control: 0x00000000 hdac0: Output amp: 0x80000000 hdac0: mute=1 step=0 size=0 offset=0 hdac0: connections: 1 hdac0: | hdac0: + [DISABLED] <- nid=14 [audio mixer] hdac0: hdac0: nid: 23 [DISABLED] hdac0: Name: vendor widget hdac0: Widget cap: 0x00f00000 hdac0: hdac0: nid: 24 hdac0: Name: pin: Mic (Pink Jack) hdac0: Widget cap: 0x0040018f hdac0: UNSOL STEREO hdac0: Association: 2 (0x00000001) hdac0: OSS: mic (mic) hdac0: Pin cap: 0x00001734 hdac0: PDC OUT IN VREF[ 50 80 GROUND HIZ ] hdac0: Pin config: 0x01a19830 hdac0: Pin control: 0x00000024 IN VREFs hdac0: Output amp: 0x80000000 hdac0: mute=1 step=0 size=0 offset=0 hdac0: Input amp: 0x00270300 hdac0: mute=0 step=3 size=39 offset=0 hdac0: connections: 1 hdac0: | hdac0: + [DISABLED] <- nid=14 [audio mixer] hdac0: hdac0: nid: 25 hdac0: Name: pin: Mic (Pink Jack) hdac0: Widget cap: 0x0040018f hdac0: UNSOL STEREO hdac0: Association: 3 (0x00000001) hdac0: OSS: monitor (monitor) hdac0: Pin cap: 0x0000173c hdac0: PDC HP OUT IN VREF[ 50 80 GROUND HIZ ] hdac0: Pin config: 0x02a19840 hdac0: Pin control: 0x00000024 IN VREFs hdac0: Output amp: 0x80000000 hdac0: mute=1 step=0 size=0 offset=0 hdac0: Input amp: 0x00270300 hdac0: mute=0 step=3 size=39 offset=0 hdac0: connections: 2 hdac0: | hdac0: + [DISABLED] <- nid=12 [audio mixer] (selected) hdac0: + [DISABLED] <- nid=14 [audio mixer] hdac0: hdac0: nid: 26 hdac0: Name: pin: Line-in (Blue Jack) hdac0: Widget cap: 0x0040018d hdac0: UNSOL STEREO hdac0: Association: 2 (0x00008000) hdac0: OSS: line (line) hdac0: Pin cap: 0x00000034 hdac0: PDC OUT IN hdac0: Pin config: 0x0181303f hdac0: Pin control: 0x00000020 IN hdac0: Output amp: 0x80000000 hdac0: mute=1 step=0 size=0 offset=0 hdac0: connections: 1 hdac0: | hdac0: + [DISABLED] <- nid=13 [audio mixer] [DISABLED] hdac0: hdac0: nid: 27 hdac0: Name: pin: Headphones (Green Jack) hdac0: Widget cap: 0x0040018f hdac0: UNSOL STEREO hdac0: Association: 1 (0x00000001) hdac0: Pin cap: 0x0000173c hdac0: PDC HP OUT IN VREF[ 50 80 GROUND HIZ ] hdac0: Pin config: 0x02214020 hdac0: Pin control: 0x000000c0 HP OUT hdac0: Output amp: 0x80000000 hdac0: mute=1 step=0 size=0 offset=0 hdac0: Input amp: 0x00270300 hdac0: mute=0 step=3 size=39 offset=0 hdac0: connections: 2 hdac0: | hdac0: + [DISABLED] <- nid=12 [audio mixer] hdac0: + <- nid=14 [audio mixer] (selected) hdac0: hdac0: nid: 28 [DISABLED] hdac0: Name: pin: Speaker (None) hdac0: Widget cap: 0x00400001 hdac0: STEREO hdac0: Pin cap: 0x00000020 hdac0: IN hdac0: Pin config: 0x411111f0 hdac0: Pin control: 0x00000000 hdac0: hdac0: nid: 29 [DISABLED] hdac0: Name: pin: Line-out (None) hdac0: Widget cap: 0x00400000 hdac0: Pin cap: 0x00000020 hdac0: IN hdac0: Pin config: 0x4004c601 hdac0: Pin control: 0x00000000 hdac0: hdac0: nid: 30 [DISABLED] hdac0: Name: pin: Speaker (None) hdac0: Widget cap: 0x00400300 hdac0: DIGITAL hdac0: Pin cap: 0x00000010 hdac0: OUT hdac0: Pin config: 0x411111f0 hdac0: Pin control: 0x00000000 hdac0: connections: 1 hdac0: | hdac0: + <- nid=6 [audio output] [DISABLED] hdac0: hdac0: nid: 31 [DISABLED] hdac0: Name: vendor widget hdac0: Widget cap: 0x00f00000 hdac0: hdac0: nid: 32 [DISABLED] hdac0: Name: vendor widget hdac0: Widget cap: 0x00f00040 hdac0: PROC hdac0: hdac0: nid: 33 [DISABLED] hdac0: Name: vendor widget hdac0: Widget cap: 0x00f00000 hdac0: hdac0: nid: 34 hdac0: Name: audio mixer hdac0: Widget cap: 0x0020010b hdac0: STEREO hdac0: Association: 3 (0x00000001) hdac0: OSS: monitor hdac0: Input amp: 0x80000000 hdac0: mute=1 step=0 size=0 offset=0 hdac0: connections: 10 hdac0: | hdac0: + [DISABLED] <- nid=24 [pin: Mic (Pink Jack)] hdac0: + <- nid=25 [pin: Mic (Pink Jack)] hdac0: + [DISABLED] <- nid=26 [pin: Line-in (Blue Jack)] hdac0: + [DISABLED] <- nid=27 [pin: Headphones (Green Jack)] hdac0: + [DISABLED] <- nid=28 [pin: Speaker (None)] [DISABLED] hdac0: + [DISABLED] <- nid=29 [pin: Line-out (None)] [DISABLED] hdac0: + [DISABLED] <- nid=20 [pin: Line-out (Green Jack)] hdac0: + [DISABLED] <- nid=21 [pin: Speaker (None)] [DISABLED] hdac0: + [DISABLED] <- nid=22 [pin: Speaker (None)] [DISABLED] hdac0: + [DISABLED] <- nid=11 [audio mixer] hdac0: hdac0: nid: 35 hdac0: Name: audio mixer hdac0: Widget cap: 0x0020010b hdac0: STEREO hdac0: Association: 2 (0x00008001) hdac0: OSS: line, mic, mix hdac0: Input amp: 0x80000000 hdac0: mute=1 step=0 size=0 offset=0 hdac0: connections: 10 hdac0: | hdac0: + <- nid=24 [pin: Mic (Pink Jack)] hdac0: + [DISABLED] <- nid=25 [pin: Mic (Pink Jack)] hdac0: + <- nid=26 [pin: Line-in (Blue Jack)] hdac0: + [DISABLED] <- nid=27 [pin: Headphones (Green Jack)] hdac0: + [DISABLED] <- nid=28 [pin: Speaker (None)] [DISABLED] hdac0: + [DISABLED] <- nid=29 [pin: Line-out (None)] [DISABLED] hdac0: + [DISABLED] <- nid=20 [pin: Line-out (Green Jack)] hdac0: + [DISABLED] <- nid=21 [pin: Speaker (None)] [DISABLED] hdac0: + [DISABLED] <- nid=22 [pin: Speaker (None)] [DISABLED] hdac0: + <- nid=11 [audio mixer] hdac0: hdac0: nid: 36 [DISABLED] hdac0: Name: vendor widget hdac0: Widget cap: 0x00f00000 hdac0: hdac0: nid: 37 [DISABLED] hdac0: Name: vendor widget hdac0: Widget cap: 0x00f00000 hdac0: hdac0: nid: 38 [DISABLED] hdac0: Name: vendor widget hdac0: Widget cap: 0x00f00000 hdac0: pcm0: at cad 0 nid 1 on hdac0 pcm0: +--------------------------------------+ pcm0: | DUMPING PCM Playback/Record Channels | pcm0: +--------------------------------------+ pcm0: pcm0: Playback: pcm0: pcm0: Stream cap: 0x00000001 pcm0: PCM pcm0: PCM cap: 0x000e0160 pcm0: 16 20 24 bits, 44 48 96 KHz pcm0: DAC: 2 pcm0: pcm0: Record: pcm0: pcm0: Stream cap: 0x00000001 pcm0: PCM pcm0: PCM cap: 0x00060160 pcm0: 16 20 bits, 44 48 96 KHz pcm0: ADC: 8 pcm0: pcm0: +-------------------------------+ pcm0: | DUMPING Playback/Record Paths | pcm0: +-------------------------------+ pcm0: pcm0: Playback: pcm0: pcm0: nid=20 [pin: Line-out (Green Jack)] pcm0: | pcm0: + <- nid=12 [audio mixer] [src: pcm, mix] pcm0: | pcm0: + <- nid=2 [audio output] [src: pcm] pcm0: + <- nid=11 [audio mixer] [src: mix] pcm0: pcm0: Record: pcm0: pcm0: nid=8 [audio input] pcm0: | pcm0: + <- nid=35 [audio mixer] [src: line, mic, mix] pcm0: | pcm0: + <- nid=24 [pin: Mic (Pink Jack)] [src: mic] pcm0: + <- nid=26 [pin: Line-in (Blue Jack)] [src: line] pcm0: + <- nid=11 [audio mixer] [src: mix] pcm0: pcm0: Input Mix: pcm0: pcm0: nid=11 [audio mixer] pcm0: | pcm0: + <- nid=24 [pin: Mic (Pink Jack)] [src: mic] pcm0: + <- nid=26 [pin: Line-in (Blue Jack)] [src: line] pcm0: pcm0: +-------------------------+ pcm0: | DUMPING Volume Controls | pcm0: +-------------------------+ pcm0: pcm0: Master Volume (OSS: vol) pcm0: | pcm0: +- ctl 1 (nid 2 out): -64/0dB (65 steps) pcm0: +- ctl 15 (nid 12 in 0): mute pcm0: +- ctl 16 (nid 12 in 1): mute pcm0: +- ctl 21 (nid 20 in ): mute pcm0: pcm0: PCM Volume (OSS: pcm) pcm0: | pcm0: +- ctl 1 (nid 2 out): -64/0dB (65 steps) pcm0: +- ctl 15 (nid 12 in 0): mute pcm0: pcm0: Microphone Volume (OSS: mic) pcm0: | pcm0: +- ctl 25 (nid 24 out): 0/30dB (4 steps) pcm0: +- ctl 41 (nid 35 in 0): mute pcm0: pcm0: Line-in Volume (OSS: line) pcm0: | pcm0: +- ctl 8 (nid 11 in 2): -34/12dB (32 steps) + mute pcm0: +- ctl 43 (nid 35 in 2): mute pcm0: pcm0: Recording Level (OSS: rec) pcm0: | pcm0: +- ctl 4 (nid 8 in 0): -13/33dB (32 steps) + mute pcm0: +- ctl 41 (nid 35 in 0): mute pcm0: +- ctl 43 (nid 35 in 2): mute pcm0: +- ctl 50 (nid 35 in 9): mute pcm0: pcm0: Input Mix Level (OSS: mix) pcm0: | pcm0: +- ctl 6 (nid 11 in 0): -34/12dB (32 steps) + mute pcm0: +- ctl 8 (nid 11 in 2): -34/12dB (32 steps) + mute pcm0: +- ctl 16 (nid 12 in 1): mute pcm0: +- ctl 50 (nid 35 in 9): mute pcm0: pcm0: Input Monitoring Level (OSS: igain) pcm0: | pcm0: +- ctl 16 (nid 12 in 1): mute pcm0: pcm0: Mixer "vol": pcm0: Mixer "pcm": pcm0: Mixer "line": pcm0: Mixer "mic": pcm0: Mixer "mix": pcm0: Mixer "rec": pcm0: Mixer "igain": pcm0: Mixer "ogain": pcm0: clone manager: deadline=750ms flags=0x8000001e pcm0: sndbuf_setmap 11ff90000, 4000; 0xffffff8117c86000 -> 11ff90000 pcm0: sndbuf_setmap 11ffa0000, 4000; 0xffffff8117c96000 -> 11ffa0000 pcm1: at cad 0 nid 1 on hdac0 pcm1: +--------------------------------------+ pcm1: | DUMPING PCM Playback/Record Channels | pcm1: +--------------------------------------+ pcm1: pcm1: Playback: pcm1: pcm1: Stream cap: 0x00000001 pcm1: PCM pcm1: PCM cap: 0x000e0160 pcm1: 16 20 24 bits, 44 48 96 KHz pcm1: DAC: 4 pcm1: pcm1: Record: pcm1: pcm1: Stream cap: 0x00000001 pcm1: PCM pcm1: PCM cap: 0x00060160 pcm1: 16 20 bits, 44 48 96 KHz pcm1: ADC: 9 pcm1: pcm1: +-------------------------------+ pcm1: | DUMPING Playback/Record Paths | pcm1: +-------------------------------+ pcm1: pcm1: Playback: pcm1: pcm1: nid=27 [pin: Headphones (Green Jack)] pcm1: | pcm1: + <- nid=14 [audio mixer] [src: pcm, mix] pcm1: | pcm1: + <- nid=4 [audio output] [src: pcm] pcm1: + <- nid=11 [audio mixer] [src: mix] pcm1: pcm1: Record: pcm1: pcm1: nid=9 [audio input] pcm1: | pcm1: + <- nid=34 [audio mixer] [src: monitor] pcm1: | pcm1: + <- nid=25 [pin: Mic (Pink Jack)] [src: monitor] pcm1: pcm1: +-------------------------+ pcm1: | DUMPING Volume Controls | pcm1: +-------------------------+ pcm1: pcm1: Master Volume (OSS: vol) pcm1: | pcm1: +- ctl 3 (nid 4 out): -64/0dB (65 steps) pcm1: +- ctl 19 (nid 14 in 0): mute pcm1: +- ctl 20 (nid 14 in 1): mute pcm1: +- ctl 29 (nid 27 in ): mute pcm1: pcm1: PCM Volume (OSS: pcm) pcm1: | pcm1: +- ctl 3 (nid 4 out): -64/0dB (65 steps) pcm1: +- ctl 19 (nid 14 in 0): mute pcm1: pcm1: Microphone2 Volume (OSS: monitor) pcm1: | pcm1: +- ctl 27 (nid 25 out): 0/30dB (4 steps) pcm1: +- ctl 32 (nid 34 in 1): mute pcm1: pcm1: Recording Level (OSS: rec) pcm1: | pcm1: +- ctl 5 (nid 9 in 0): -13/33dB (32 steps) + mute pcm1: +- ctl 32 (nid 34 in 1): mute pcm1: pcm1: Input Mix Level (OSS: mix) pcm1: | pcm1: +- ctl 20 (nid 14 in 1): mute pcm1: pcm1: Input Monitoring Level (OSS: igain) pcm1: | pcm1: +- ctl 20 (nid 14 in 1): mute pcm1: pcm1: Mixer "vol": pcm1: Mixer "pcm": pcm1: Mixer "mix": pcm1: Mixer "rec": pcm1: Mixer "igain": pcm1: Mixer "monitor": pcm1: clone manager: deadline=750ms flags=0x8000001e pcm1: sndbuf_setmap 11ffb0000, 4000; 0xffffff8117ca6000 -> 11ffb0000 pcm1: sndbuf_setmap 4070000, 4000; 0xffffff8117cb6000 -> 4070000 fxp0: link state changed to DOWN usbus0: 12Mbps Full Speed USB v1.0 usbus1: 12Mbps Full Speed USB v1.0 ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 usbus2: 12Mbps Full Speed USB v1.0 usbus3: 12Mbps Full Speed USB v1.0 ugen2.1: at usbus2 uhub2: on usbus2 ugen3.1: at usbus3 uhub3: on usbus3 usbus4: 480Mbps High Speed USB v2.0 ata0: reset tp1 mask=03 ostat0=7f ostat1=7f ugen4.1: at usbus4 uhub4: on usbus4 uhub0: 2 ports with 2 removable, self powered uhub1: 2 ports with 2 removable, self powered ata0: stat0=0x00 err=0x00 lsb=0x00 msb=0x00 ata0: stat1=0x7f err=0x7f lsb=0x7f msb=0x7f uhub2: 2 ports with 2 removable, self powered uhub3: 2 ports with 2 removable, self powered ata0: stat1=0x00 err=0x00 lsb=0x00 msb=0x00 ata0: reset tp2 stat0=00 stat1=00 devices=0x0 ata2: SATA reset: ports status=0x05 ata2: reset tp1 mask=03 ostat0=50 ostat1=00 ata2: stat0=0x50 err=0x01 lsb=0x00 msb=0x00 ata2: stat1=0x00 err=0x01 lsb=0x14 msb=0xeb ata2: reset tp2 stat0=50 stat1=00 devices=0x20001 (aprobe0:ata2:0:0:0): SIGNATURE: 0000 ata3: SATA reset: ports status=0x00 (aprobe0:ata2:0:1:0): SIGNATURE: eb14 ada0 at ata2 bus 0 scbus1 target 0 lun 0 GEOM: new disk ada0 ada0: ATA-8 SATA 2.x device ada0: Serial Number WD-WCAV55611064 ada0: 150.000MB/s transfers (SATA, UDMA5, PIO 8192bytes) ada0: 953869MB (1953525168 512 byte sectors: 16H 63S/T 16383C) ada0: Previously was known as ad4 pass0 at ata2 bus 0 scbus1 target 0 lun 0 pass0: ATA-8 SATA 2.x device pass0: Serial Number WD-WCAV55611064 pass0: 150.000MB/s transfers (SATA, UDMA5, PIO 8192bytes) pass1 at ata2 bus 0 scbus1 target 1 lun 0 pass1: Removable CD-ROM SCSI-0 device pass1: Serial Number K1Z9C4B0949 pass1: 150.000MB/s transfers (SATA, UDMA5, ATAPI 12bytes, PIO 8192bytes) SMP: AP CPU #3 Launched! (cd0:cpu3 AP: ata2:0: ID: 0x03000000 VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff 1: lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff 0): timer: 0x000100ef therm: 0x00010000 err: 0x000000f0 pmc: 0x00010400SCSI status error (cd0:ata2:0:1:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 SMP: AP CPU #1 Launched! cpu1 AP: (cd0:ata2:0:1:0): CAM status: SCSI Status Error ID: 0x01000000 VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff (cd0:ata2:0:1:0): SCSI status: Check Condition lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff (cd0:ata2:0:1:0): SCSI sense: NOT READY asc:3a,1 (Medium not present - tray closed) timer: 0x000100ef therm: 0x00010000 err: 0x000000f0 pmc: 0x00010400 (cd0:SMP: AP CPU #2 Launched! ata2:0:cpu2 AP: 1: ID: 0x02000000 VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff 0): lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff Error 6, Unretryable error timer: 0x000100ef therm: 0x00010000 err: 0x000000f0cd0 at ata2 bus 0 scbus1 target 1 lun 0 pmc: 0x00010400cd0: Removable CD-ROM SCSI-0 device ioapic0: routing intpin 1 (cd0: Serial Number K1Z9C4B0949 ISA IRQ 1cd0: 150.000MB/s transfers) to lapic 1 vector 48 (SATA, UDMA5, ATAPI 12bytes, PIO 8192bytes) cd0: Attempt to query device size failed: NOT READY, Medium not present - tray closed ioapic0: routing intpin 4 (ISA IRQ 4) to lapic 2 vector 48 ioapic0: routing intpin 9 (ISA IRQ 9) to lapic 3 vector 48 ioapic0: routing intpin 16 (PCI IRQ 16) to lapic 1 vector 49 ioapic0: routing intpin 18 (PCI IRQ 18) to lapic 2 vector 49 ioapic0: routing intpin 19 (PCI IRQ 19) to lapic 3 vector 49 ioapic0: routing intpin 22 (PCI IRQ 22) to lapic 1 vector 50 ioapic0: routing intpin 23 (PCI IRQ 23) to lapic 2 vector 50 msi: Assigning MSI IRQ 256 to local APIC 3 vector 50 GEOM: new disk cd0 GEOM: ada0s1: geometry does not match label (32h,32s != 16h,63s). (cd0:ata2:0:1:0): SCSI status error (cd0:ata2:0:1:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 (cd0:ata2:0:1:0): CAM status: SCSI Status Error (cd0:ata2:0:1:0): SCSI status: Check Condition (cd0:ata2:0:1:0): SCSI sense: NOT READY asc:3a,1 (Medium not present - tray closed) (cd0:ata2:0:1:0): Error 6, Unretryable error (cd0:ata2:0:1:0): SCSI status error (cd0:ata2:0:1:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 (cd0:ata2:0:1:0): CAM status: SCSI Status Error (cd0:ata2:0:1:0): SCSI status: Check Condition (cd0:ata2:0:1:0): SCSI sense: NOT READY asc:3a,1 (Medium not present - tray closed) (cd0:ata2:0:1:0): Error 6, Unretryable error Root mount waiting for: usbus4 uhub4: 8 ports with 8 removable, self powered Root mount waiting for: usbus4 ugen4.2: at usbus4 umass0: on usbus4 umass0: SCSI over Bulk-Only; quirks = 0x0000 ugen1.2: at usbus1 ukbd0: on usbus1 Root mount waiting for: usbus4 kbd2 at ukbd0 kbd2: ukbd0, generic (0), config:0x0, flags:0x3d0000 umass0:3:0:-1: Attached to scbus3 (probe0:umass-sim0:0:0:0): Down reving Protocol Version from 2 to 0? Root mount waiting for: usbus4 (probe0:umass-sim0:0:Trying to mount root from ufs:/dev/ada0s1a [rw]... 0:0): SCSI status error (probe0:umass-sim0:0:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 (probe0:umass-sim0:0:0:0): CAM status: SCSI Status Error (probe0:umass-sim0:0:0:0): SCSI status: Check Condition (probe0:umass-sim0:0:0:0): SCSI sense: NOT READY asc:3a,0 (Medium not present) (probe0:umass-sim0:0:0:0): Error 6, Unretryable error pass2 at umass-sim0 bus 0 scbus3 target 0 lun 0 pass2: Removable Direct Access SCSI-0 device pass2: Serial Number 606569746801 pass2: 40.000MB/s transfers GEOM: new disk da0 (da0:umass-sim0:0:0:0): SCSI status error (da0:umass-sim0:0:0:0): READ CAPACITY(10). CDB: 25 0 0 0 0 0 0 0 0 0 (da0:umass-sim0:0:0:0): CAM status: SCSI Status Error (da0:umass-sim0:0:0:0): SCSI status: Check Condition (da0:umass-sim0:0:0:0): SCSI sense: NOT READY asc:3a,0 (Medium not present) (da0:umass-sim0:0:0:0): Error 6, Unretryable error da0 at umass-sim0 bus 0 scbus3 target 0 lun 0 da0: Removable Direct Access SCSI-0 device da0: Serial Number 606569746801 da0: 40.000MB/s transfers da0: Attempt to query device size failed: NOT READY, Medium not present (da0:umass-sim0:0:start_init: trying /sbin/init 0:0): SCSI status error (da0:umass-sim0:0:0:0): READ CAPACITY(10). CDB: 25 0 0 0 0 0 0 0 0 0 (da0:umass-sim0:0:0:0): CAM status: SCSI Status Error (da0:umass-sim0:0:0:0): SCSI status: Check Condition (da0:umass-sim0:0:0:0): SCSI sense: NOT READY asc:3a,0 (Medium not present) (da0:umass-sim0:0:0:0): Error 6, Unretryable error Opened disk da0 -> 6 (da0:umass-sim0:0:0:0): SCSI status error (da0:umass-sim0:0:0:0): READ CAPACITY(10). CDB: 25 0 0 0 0 0 0 0 0 0 (da0:umass-sim0:0:0:0): CAM status: SCSI Status Error (da0:umass-sim0:0:0:0): SCSI status: Check Condition (da0:umass-sim0:0:0:0): SCSI sense: NOT READY asc:3a,0 (Medium not present) (da0:umass-sim0:0:0:0): Error 6, Unretryable error Opened disk da0 -> 6 ugen3.2: at usbus3 (probe0:umass-sim0:0:0:1): ukbd1: Down reving Protocol Version from 2 to 0? on usbus3 kbd3 at ukbd1 kbd3: ukbd1, generic (0), config:0x0, flags:0x3d0000 ums0: on usbus3 ums0: 5 buttons and [XYZT] coordinates ID=26 ums0: 0 buttons and [T] coordinates ID=0 uhid0: on usbus3 (probe0:umass-sim0:0:0:1): SCSI status error (probe0:umass-sim0:0:0:1): TEST UNIT READY. CDB: 0 20 0 0 0 0 (probe0:umass-sim0:0:0:1): CAM status: SCSI Status Error (probe0:umass-sim0:0:0:1): SCSI status: Check Condition (probe0:umass-sim0:0:0:1): SCSI sense: NOT READY asc:3a,0 (Medium not present) (probe0:umass-sim0:0:0:1): Error 6, Unretryable error pass3 at umass-sim0 bus 0 scbus3 target 0 lun 1 pass3: Removable Direct Access SCSI-0 device pass3: Serial Number 606569746801 pass3: 40.000MB/s transfers GEOM: new disk da1 (da1:umass-sim0:0:0:1): SCSI status error (da1:umass-sim0:0:0:1): READ CAPACITY(10). CDB: 25 20 0 0 0 0 0 0 0 0 (da1:umass-sim0:0:0:1): CAM status: SCSI Status Error (da1:umass-sim0:0:0:1): SCSI status: Check Condition (da1:umass-sim0:0:0:1): SCSI sense: NOT READY asc:3a,0 (Medium not present) (da1:umass-sim0:0:0:1): Error 6, Unretryable error da1 at umass-sim0 bus 0 scbus3 target 0 lun 1 da1: Removable Direct Access SCSI-0 device da1: Serial Number 606569746801 da1: 40.000MB/s transfers da1: Attempt to query device size failed: NOT READY, Medium not present (da1:uEnter full pathnmass-sim0:0:0:ame of shell or 1): RETURN for /bin/SCSI status error sh: (da1:umass-sim0:0:0:1): READ CAPACITY(10). CDB: 25 20 0 0 0 0 0 0 0 0 (da1:umass-sim0:0:0:1): CAM status: SCSI Status Error (da1:umass-sim0:0:0:1): SCSI status: Check Condition (da1:umass-sim0:0:0:1): SCSI sense: NOT READY asc:3a,0 (Medium not present) (da1:umass-sim0:0:0:1): Error 6, Unretryable error Opened disk da1 -> 6 (probe0:umass-sim0:0:0:2): Down reving Protocol Version from 2 to 0? (probe0:umass-sim0:0:0:2): SCSI status error (probe0:umass-sim0:0:0:2): TEST UNIT READY. CDB: 0 40 0 0 0 0 (probe0:umass-sim0:0:0:2): CAM status: SCSI Status Error (probe0:umass-sim0:0:0:2): SCSI status: Check Condition (probe0:umass-sim0:0:0:2): SCSI sense: NOT READY asc:3a,0 (Medium not present) (probe0:umass-sim0:0:0:2): Error 6, Unretryable error pass4 at umass-sim0 bus 0 scbus3 target 0 lun 2 pass4: Removable Direct Access SCSI-0 device pass4: Serial Number 606569746801 pass4: 40.000MB/s transfers (da1:umass-sim0:0:0:1): SCSI status error (da1:umass-sim0:0:0:1): READ CAPACITY(10). CDB: 25 20 0 0 0 0 0 0 0 0 (da1:umass-sim0:0:0:1): CAM status: SCSI Status Error (da1:umass-sim0:0:0:1): SCSI status: Check Condition (da1:umass-sim0:0:0:1): SCSI sense: NOT READY asc:3a,0 (Medium not present) (da1:umass-sim0:0:0:1): Error 6, Unretryable error Opened disk da1 -> 6 (da2:GEOM: new disk da2 umass-sim0:0:0:2): SCSI status error (da2:umass-sim0:0:0:2): READ CAPACITY(10). CDB: 25 40 0 0 0 0 0 0 0 0 (da2:umass-sim0:0:0:2): CAM status: SCSI Status Error (da2:umass-sim0:0:0:2): SCSI status: Check Condition (da2:umass-sim0:0:0:2): SCSI sense: NOT READY asc:3a,0 (Medium not present) (da2:umass-sim0:0:0:2): Error 6, Unretryable error da2 at umass-sim0 bus 0 scbus3 target 0 lun 2 da2: Removable Direct Access SCSI-0 device da2: Serial Number 606569746801 da2: 40.000MB/s transfers da2: Attempt to query device size failed: NOT READY, Medium not present (da2:umass-sim0:0:0:2): SCSI status error (da2:umass-sim0:0:0:2): READ CAPACITY(10). CDB: 25 40 0 0 0 0 0 0 0 0 (da2:umass-sim0:0:0:2): CAM status: SCSI Status Error (da2:umass-sim0:0:0:2): SCSI status: Check Condition (da2:umass-sim0:0:0:2): SCSI sense: NOT READY asc:3a,0 (Medium not present) (da2:umass-sim0:0:0:2): Error 6, Unretryable error Opened disk da2 -> 6 (probe0:umass-sim0:0:0:3): Down reving Protocol Version from 2 to 0? (probe0:umass-sim0:0:0:3): SCSI status error (probe0:umass-sim0:0:0:3): TEST UNIT READY. CDB: 0 60 0 0 0 0 (probe0:umass-sim0:0:0:3): CAM status: SCSI Status Error (probe0:umass-sim0:0:0:3): SCSI status: Check Condition (probe0:umass-sim0:0:0:3): SCSI sense: NOT READY asc:3a,0 (Medium not present) (probe0:umass-sim0:0:0:3): Error 6, Unretryable error pass5 at umass-sim0 bus 0 scbus3 target 0 lun 3 pass5: Removable Direct Access SCSI-0 device pass5: Serial Number 606569746801 pass5: 40.000MB/s transfers (da2:umass-sim0:0:0:2): SCSI status error (da2:umass-sim0:0:0:2): READ CAPACITY(10). CDB: 25 40 0 0 0 0 0 0 0 0 (da2:umass-sim0:0:0:2): CAM status: SCSI Status Error (da2:umass-sim0:0:0:2): SCSI status: Check Condition (da2:umass-sim0:0:0:2): SCSI sense: NOT READY asc:3a,0 (Medium not present) (da2:umass-sim0:0:0:2): Error 6, Unretryable error Opened disk da2 -> 6 (da3:GEOM: new disk da3 umass-sim0:0:0:3): SCSI status error (da3:umass-sim0:0:0:3): READ CAPACITY(10). CDB: 25 60 0 0 0 0 0 0 0 0 (da3:umass-sim0:0:0:3): CAM status: SCSI Status Error (da3:umass-sim0:0:0:3): SCSI status: Check Condition (da3:umass-sim0:0:0:3): SCSI sense: NOT READY asc:3a,0 (Medium not present) (da3:umass-sim0:0:0:3): Error 6, Unretryable error da3 at umass-sim0 bus 0 scbus3 target 0 lun 3 da3: Removable Direct Access SCSI-0 device da3: Serial Number 606569746801 da3: 40.000MB/s transfers da3: Attempt to query device size failed: NOT READY, Medium not present (da3:umass-sim0:0:0:3): SCSI status error (da3:umass-sim0:0:0:3): READ CAPACITY(10). CDB: 25 60 0 0 0 0 0 0 0 0 (da3:umass-sim0:0:0:3): CAM status: SCSI Status Error (da3:umass-sim0:0:0:3): SCSI status: Check Condition (da3:umass-sim0:0:0:3): SCSI sense: NOT READY asc:3a,0 (Medium not present) (da3:umass-sim0:0:0:3): Error 6, Unretryable error Opened disk da3 -> 6 (da3:umass-sim0:0:0:3): SCSI status error (da3:umass-sim0:0:0:3): READ CAPACITY(10). CDB: 25 60 0 0 0 0 0 0 0 0 (da3:umass-sim0:0:0:3): CAM status: SCSI Status Error (da3:umass-sim0:0:0:3): SCSI status: Check Condition (da3:umass-sim0:0:0:3): SCSI sense: NOT READY asc:3a,0 (Medium not present) (da3:umass-sim0:0:0:3): Error 6, Unretryable error Opened disk da3 -> 6 Cannot read termcap database; using dumb terminal settings. # mount -w / --------------080509060508010808060307 Content-Type: text/plain; name="boot-new.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="boot-new.txt" GDB: no debug ports present KDB: debugger backends: ddb KDB: current backend: ddb SMAP type=01 base=0000000000000000 len=000000000009fc00 SMAP type=02 base=000000000009fc00 len=0000000000000400 SMAP type=02 base=00000000000e4000 len=000000000001c000 SMAP type=01 base=0000000000100000 len=00000000ddc80000 SMAP type=03 base=00000000ddd80000 len=000000000000e000 SMAP type=04 base=00000000ddd8e000 len=0000000000042000 SMAP type=02 base=00000000dddd0000 len=0000000000010000 SMAP type=02 base=00000000ddde0000 len=0000000000020000 SMAP type=02 base=00000000fee00000 len=0000000000001000 SMAP type=02 base=00000000fff00000 len=0000000000100000 SMAP type=01 base=0000000100000000 len=0000000020000000 Table 'FACP' at 0xddd80290 Table 'APIC' at 0xddd80390 APIC: Found table at 0xddd80390 APIC: Using the MADT enumerator. MADT: Found CPU APIC ID 0 ACPI ID 1: enabled SMP: Added CPU 0 (AP) MADT: Found CPU APIC ID 1 ACPI ID 2: enabled SMP: Added CPU 1 (AP) MADT: Found CPU APIC ID 2 ACPI ID 3: enabled SMP: Added CPU 2 (AP) MADT: Found CPU APIC ID 3 ACPI ID 4: enabled SMP: Added CPU 3 (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. FreeBSD 9.0-CURRENT #0: Sun May 15 19:04:45 CEST 2011 root@charlemagne.boland.org:/usr/obj/usr/src/sys/CHARLEMAGNE amd64 Table 'FACP' at 0xddd80290 Table 'APIC' at 0xddd80390 Table 'MCFG' at 0xddd80400 Table 'OEMB' at 0xddd8e040 Table 'HPET' at 0xddd87630 Table 'GSCI' at 0xddd8e0d0 ACPI: No SRAT table found Preloaded elf kernel "/boot/kernel/kernel" at 0xffffffff813cd000. Preloaded elf obj module "/boot/kernel/snd_hda.ko" at 0xffffffff813cd1f8. Preloaded elf obj module "/boot/kernel/sound.ko" at 0xffffffff813cd820. Calibrating TSC clock ... TSC clock: 2500055430 Hz CPU: Intel(R) Core(TM)2 Quad CPU Q8300 @ 2.50GHz (2500.06-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x1067a Family = 6 Model = 17 Stepping = 10 Features=0xbfebfbff Features2=0x408e39d AMD Features=0x20100800 AMD Features2=0x1 TSC: P-state invariant, performance statistics real memory = 4294967296 (4096 MB) Physical memory chunk(s): 0x0000000000001000 - 0x000000000009bfff, 634880 bytes (155 pages) 0x0000000000100000 - 0x00000000001fffff, 1048576 bytes (256 pages) 0x00000000013fd000 - 0x00000000d5607fff, 3558912000 bytes (868875 pages) 0x0000000100000000 - 0x000000011ffeffff, 536805376 bytes (131056 pages) avail memory = 4068827136 (3880 MB) Event timer "LAPIC" quality 400 ACPI APIC Table: INTR: Adding local APIC 1 as a target INTR: Adding local APIC 2 as a target INTR: Adding local APIC 3 as a target FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs FreeBSD/SMP: 1 package(s) x 4 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 x86bios: IVT 0x000000-0x0004ff at 0xfffffe0000000000 x86bios: SSEG 0x001000-0x001fff at 0xffffff8000223000 x86bios: EBDA 0x09f000-0x09ffff at 0xfffffe000009f000 x86bios: ROM 0x0a0000-0x0fefff at 0xfffffe00000a0000 APIC: CPU 0 has ACPI ID 1 APIC: CPU 1 has ACPI ID 2 APIC: CPU 2 has ACPI ID 3 APIC: CPU 3 has ACPI ID 4 ULE: setup cpu 0 ULE: setup cpu 1 ULE: setup cpu 2 ULE: setup cpu 3 ACPI: RSDP 0xfbd50 00024 (v02 ACPIAM) ACPI: XSDT 0xddd80100 00054 (v01 A_M_I_ OEMXSDT 11000912 MSFT 00000097) ACPI: FACP 0xddd80290 000F4 (v03 A_M_I_ OEMFACP 11000912 MSFT 00000097) ACPI: DSDT 0xddd80440 071EA (v01 A1434 A1434000 00000000 INTL 20060113) ACPI: FACS 0xddd8e000 00040 ACPI: APIC 0xddd80390 0006C (v01 A_M_I_ OEMAPIC 11000912 MSFT 00000097) ACPI: MCFG 0xddd80400 0003C (v01 A_M_I_ OEMMCFG 11000912 MSFT 00000097) ACPI: OEMB 0xddd8e040 00089 (v01 A_M_I_ AMI_OEM 11000912 MSFT 00000097) ACPI: HPET 0xddd87630 00038 (v01 A_M_I_ OEMHPET 11000912 MSFT 00000097) ACPI: GSCI 0xddd8e0d0 02024 (v01 A_M_I_ GMCHSCI 11000912 MSFT 00000097) MADT: Found IO APIC ID 4, Interrupt 0 at 0xfec00000 ioapic0: Routing external 8259A's -> intpin 0 MADT: Interrupt override: source 0, irq 2 ioapic0: Routing IRQ 0 -> intpin 2 MADT: Interrupt override: source 9, irq 9 ioapic0: intpin 9 trigger: level ioapic0 irqs 0-23 on motherboard cpu0 BSP: ID: 0x00000000 VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000100ef therm: 0x00010000 err: 0x000000f0 pmc: 0x00010400 snd_unit_init() u=0x00ff8000 [512] d=0x00007c00 [32] c=0x000003ff [1024] feeder_register: snd_unit=-1 snd_maxautovchans=16 latency=5 feeder_rate_min=1 feeder_rate_max=2016000 feeder_rate_round=25 wlan: <802.11 Link Layer> kbd: new array size 4 kbd1 at kbdmux0 mem: nfslock: pseudo-device null: random: io: hptrr: RocketRAID 17xx/2xxx SATA controller driver v1.2 acpi0: on motherboard PCIe: Memory Mapped configuration base @ 0xf0000000 ioapic0: routing intpin 9 (ISA IRQ 9) to lapic 0 vector 48 ACPI: Executed 1 blocks of module-level executable AML code acpi0: Power Button (fixed) acpi0: reservation of fed1c000, 4000 (3) failed acpi0: reservation of fed20000, 70000 (3) failed acpi0: reservation of ffc00000, 300000 (3) failed acpi0: reservation of fec00000, 1000 (3) failed acpi0: reservation of fee00000, 1000 (3) failed acpi0: reservation of f0000000, 4000000 (3) failed acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, ddd00000 (3) failed ACPI timer: 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 -> 10 Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 cpu0: on acpi0 cpu0: switching to generic Cx mode cpu1: on acpi0 cpu2: on acpi0 cpu3: on acpi0 pci_link0: Index IRQ Rtd Ref IRQs Initial Probe 0 3 N 0 3 4 5 6 7 10 12 14 15 Validation 0 3 N 0 3 4 5 6 7 10 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 10 12 14 15 pci_link1: Index IRQ Rtd Ref IRQs Initial Probe 0 5 N 0 3 4 5 6 7 10 12 14 15 Validation 0 5 N 0 3 4 5 6 7 10 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 10 12 14 15 pci_link2: Index IRQ Rtd Ref IRQs Initial Probe 0 10 N 0 3 4 5 6 7 10 12 14 15 Validation 0 10 N 0 3 4 5 6 7 10 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 10 12 14 15 pci_link3: Index IRQ Rtd Ref IRQs Initial Probe 0 10 N 0 3 4 5 6 7 10 12 14 15 Validation 0 10 N 0 3 4 5 6 7 10 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 10 12 14 15 pci_link4: Index IRQ Rtd Ref IRQs Initial Probe 0 5 N 0 3 4 5 6 7 10 12 14 15 Validation 0 5 N 0 3 4 5 6 7 10 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 10 12 14 15 pci_link5: Index IRQ Rtd Ref IRQs Initial Probe 0 7 N 0 3 4 5 6 7 10 12 14 15 Validation 0 7 N 0 3 4 5 6 7 10 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 10 12 14 15 pci_link6: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 11 Validation 0 11 N 0 11 After Disable 0 255 N 0 11 pci_link7: Index IRQ Rtd Ref IRQs Initial Probe 0 6 N 0 3 4 5 6 7 10 12 14 15 Validation 0 6 N 0 3 4 5 6 7 10 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 10 12 14 15 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pci0: domain=0, physical bus=0 found-> vendor=0x8086, dev=0x2e30, revid=0x03 domain=0, bus=0, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x2090, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x2e32, revid=0x03 domain=0, bus=0, slot=2, func=0 class=03-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0090, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=3 powerspec 2 supports D0 D3 current D0 MSI supports 1 message map[10]: type Memory, range 64, base 0xfe400000, size 22, enabled map[18]: type Prefetchable Memory, range 64, base 0xe0000000, size 28, enabled map[20]: type I/O Port, range 32, base 0xcc00, size 3, enabled pcib0: matched entry for 0.2.INTA pcib0: slot 2 INTA hardwired to IRQ 16 found-> vendor=0x8086, dev=0x27d8, revid=0x01 domain=0, bus=0, slot=27, func=0 class=04-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0010, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=7 powerspec 2 supports D0 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Memory, range 64, base 0xfe3f8000, size 14, enabled pcib0: matched entry for 0.27.INTA pcib0: slot 27 INTA hardwired to IRQ 21 found-> vendor=0x8086, dev=0x27d0, revid=0x01 domain=0, bus=0, slot=28, func=0 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0104, statreg=0x0010, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x02 (500 ns), maxlat=0x00 (0 ns) intpin=a, irq=3 powerspec 2 supports D0 D3 current D0 MSI supports 1 message pcib0: matched entry for 0.28.INTA pcib0: slot 28 INTA hardwired to IRQ 16 found-> vendor=0x8086, dev=0x27d2, revid=0x01 domain=0, bus=0, slot=28, func=1 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0107, statreg=0x0010, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x02 (500 ns), maxlat=0x00 (0 ns) intpin=b, irq=5 powerspec 2 supports D0 D3 current D0 MSI supports 1 message pcib0: matched entry for 0.28.INTB pcib0: slot 28 INTB hardwired to IRQ 17 found-> vendor=0x8086, dev=0x27d4, revid=0x01 domain=0, bus=0, slot=28, func=2 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0104, statreg=0x0010, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x02 (500 ns), maxlat=0x00 (0 ns) intpin=c, irq=10 powerspec 2 supports D0 D3 current D0 MSI supports 1 message pcib0: matched entry for 0.28.INTC pcib0: slot 28 INTC hardwired to IRQ 18 found-> vendor=0x8086, dev=0x27c8, revid=0x01 domain=0, bus=0, slot=29, func=0 class=0c-03-00, hdrtype=0x00, mfdev=1 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=6 map[20]: type I/O Port, range 32, base 0xc400, size 5, enabled pcib0: matched entry for 0.29.INTA pcib0: slot 29 INTA hardwired to IRQ 23 found-> vendor=0x8086, dev=0x27c9, revid=0x01 domain=0, bus=0, slot=29, func=1 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=10 map[20]: type I/O Port, range 32, base 0xc480, size 5, enabled pcib0: matched entry for 0.29.INTB pcib0: slot 29 INTB hardwired to IRQ 19 found-> vendor=0x8086, dev=0x27ca, revid=0x01 domain=0, bus=0, slot=29, func=2 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=10 map[20]: type I/O Port, range 32, base 0xc800, size 5, enabled pcib0: matched entry for 0.29.INTC pcib0: slot 29 INTC hardwired to IRQ 18 found-> vendor=0x8086, dev=0x27cb, revid=0x01 domain=0, bus=0, slot=29, func=3 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=d, irq=3 map[20]: type I/O Port, range 32, base 0xc880, size 5, enabled pcib0: matched entry for 0.29.INTD pcib0: slot 29 INTD hardwired to IRQ 16 found-> vendor=0x8086, dev=0x27cc, revid=0x01 domain=0, bus=0, slot=29, func=7 class=0c-03-20, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=6 powerspec 2 supports D0 D3 current D0 map[10]: type Memory, range 32, base 0xfe3f7c00, size 10, enabled pcib0: matched entry for 0.29.INTA pcib0: slot 29 INTA hardwired to IRQ 23 found-> vendor=0x8086, dev=0x244e, revid=0xe1 domain=0, bus=0, slot=30, func=0 class=06-04-01, hdrtype=0x01, mfdev=0 cmdreg=0x0107, statreg=0x0010, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x02 (500 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x27b8, revid=0x01 domain=0, bus=0, slot=31, func=0 class=06-01-00, hdrtype=0x00, mfdev=1 cmdreg=0x0007, statreg=0x0210, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x27df, revid=0x01 domain=0, bus=0, slot=31, func=1 class=01-01-8a, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0288, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=255 map[20]: type I/O Port, range 32, base 0xffa0, size 4, enabled found-> vendor=0x8086, dev=0x27c0, revid=0x01 domain=0, bus=0, slot=31, func=2 class=01-01-8f, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x02b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=11 powerspec 2 supports D0 D3 current D0 map[10]: type I/O Port, range 32, base 0xc080, size 3, enabled map[14]: type I/O Port, range 32, base 0xc000, size 2, enabled map[18]: type I/O Port, range 32, base 0xbc00, size 3, enabled map[1c]: type I/O Port, range 32, base 0xb880, size 2, enabled map[20]: type I/O Port, range 32, base 0xb800, size 4, enabled pcib0: matched entry for 0.31.INTB pcib0: slot 31 INTB hardwired to IRQ 22 vgapci0: port 0xcc00-0xcc07 mem 0xfe400000-0xfe7fffff,0xe0000000-0xefffffff irq 16 at device 2.0 on pci0 agp0: on vgapci0 agp0: aperture size is 256M, detected 32764k stolen memory hdac0: mem 0xfe3f8000-0xfe3fbfff irq 21 at device 27.0 on pci0 hdac0: HDA Driver Revision: 20100226_0142 hdac0: attempting to allocate 1 MSI vectors (1 supported) msi: routing MSI IRQ 256 to local APIC 0 vector 49 hdac0: using IRQ 256 for MSI hdac0: Caps: OSS 4, ISS 4, BSS 0, NSDO 1, 64bit, CORB 256, RIRB 256 pcib1: irq 16 at device 28.0 on pci0 pcib1: domain 0 pcib1: secondary bus 3 pcib1: subordinate bus 3 pcib1: no prefetched decode pci3: on pcib1 pci3: domain=0, physical bus=3 pcib2: irq 17 at device 28.1 on pci0 pcib2: domain 0 pcib2: secondary bus 2 pcib2: subordinate bus 2 pcib2: I/O decode 0xd000-0xdfff pcib2: memory decode 0xfe800000-0xfe8fffff pcib2: prefetched decode 0xfdf00000-0xfdffffff pci2: on pcib2 pci2: domain=0, physical bus=2 found-> vendor=0x10ec, dev=0x8136, revid=0x02 domain=0, bus=2, slot=0, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0010, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=5 powerspec 3 supports D0 D1 D2 D3 current D0 MSI supports 1 message, 64 bit MSI-X supports 2 messages in map 0x20 map[10]: type I/O Port, range 32, base 0xd800, size 8, enabled pcib2: allocated I/O port range (0xd800-0xd8ff) for rid 10 of pci0:2:0:0 map[18]: type Prefetchable Memory, range 64, base 0xfdfff000, size 12, enabled pcib2: allocated prefetch range (0xfdfff000-0xfdffffff) for rid 18 of pci0:2:0:0 map[20]: type Prefetchable Memory, range 64, base 0xfdfe0000, size 16, enabled pcib2: allocated prefetch range (0xfdfe0000-0xfdfeffff) for rid 20 of pci0:2:0:0 pcib2: matched entry for 2.0.INTA pcib2: slot 0 INTA hardwired to IRQ 17 re0: port 0xd800-0xd8ff mem 0xfdfff000-0xfdffffff,0xfdfe0000-0xfdfeffff irq 17 at device 0.0 on pci2 re0: MSI count : 1 re0: MSI-X count : 2 re0: attempting to allocate 1 MSI-X vectors (2 supported) msi: routing MSI-X IRQ 257 to local APIC 0 vector 50 re0: using IRQ 257 for MSI-X re0: Using 1 MSI-X message re0: Chip rev. 0x24800000 re0: MAC rev. 0x00400000 miibus0: on re0 rlphy0: PHY 1 on miibus0 rlphy0: OUI 0x000004, model 0x0020, rev. 1 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto, auto-flow re0: bpf attached re0: Ethernet address: 90:e6:ba:8a:36:a2 pcib3: irq 18 at device 28.2 on pci0 pcib3: domain 0 pcib3: secondary bus 1 pcib3: subordinate bus 1 pcib3: no prefetched decode pci1: on pcib3 pci1: domain=0, physical bus=1 uhci0: port 0xc400-0xc41f irq 23 at device 29.0 on pci0 ioapic0: routing intpin 23 (PCI IRQ 23) to lapic 0 vector 51 uhci0: LegSup = 0x2f00 usbus0: on uhci0 usbus0: bpf attached uhci0: usbpf: Attached uhci1: port 0xc480-0xc49f irq 19 at device 29.1 on pci0 ioapic0: routing intpin 19 (PCI IRQ 19) to lapic 0 vector 52 uhci1: LegSup = 0x2f00 usbus1: on uhci1 usbus1: bpf attached uhci1: usbpf: Attached uhci2: port 0xc800-0xc81f irq 18 at device 29.2 on pci0 ioapic0: routing intpin 18 (PCI IRQ 18) to lapic 0 vector 53 uhci2: LegSup = 0x2f00 usbus2: on uhci2 usbus2: bpf attached uhci2: usbpf: Attached uhci3: port 0xc880-0xc89f irq 16 at device 29.3 on pci0 ioapic0: routing intpin 16 (PCI IRQ 16) to lapic 0 vector 54 uhci3: LegSup = 0x2f00 usbus3: on uhci3 usbus3: bpf attached uhci3: usbpf: Attached ehci0: mem 0xfe3f7c00-0xfe3f7fff irq 23 at device 29.7 on pci0 usbus4: EHCI version 1.0 usbus4: on ehci0 usbus4: bpf attached ehci0: usbpf: Attached pcib4: at device 30.0 on pci0 pcib4: domain 0 pcib4: secondary bus 4 pcib4: subordinate bus 4 pcib4: I/O decode 0xe000-0xefff pcib4: memory decode 0xfe900000-0xfebfffff pcib4: no prefetched decode pcib4: Subtractively decoded bridge. pci4: on pcib4 pci4: domain=0, physical bus=4 found-> vendor=0x8086, dev=0x1229, revid=0x08 domain=0, bus=4, slot=0, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0017, statreg=0x0290, cachelnsz=8 (dwords) lattimer=0x40 (1920 ns), mingnt=0x08 (2000 ns), maxlat=0x38 (14000 ns) intpin=a, irq=5 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type Memory, range 32, base 0xfebff000, size 12, enabled pcib4: allocated memory range (0xfebff000-0xfebfffff) for rid 10 of pci0:4:0:0 map[14]: type I/O Port, range 32, base 0xec00, size 6, enabled pcib4: allocated I/O port range (0xec00-0xec3f) for rid 14 of pci0:4:0:0 map[18]: type Memory, range 32, base 0xfea00000, size 20, enabled pcib4: allocated memory range (0xfea00000-0xfeafffff) for rid 18 of pci0:4:0:0 pcib4: matched entry for 4.0.INTA pcib4: slot 0 INTA hardwired to IRQ 20 fxp0: port 0xec00-0xec3f mem 0xfebff000-0xfebfffff,0xfea00000-0xfeafffff irq 20 at device 0.0 on pci4 fxp0: using memory space register mapping fxp0: PCI IDs: 8086 1229 8086 000c 0008 fxp0: Dynamic Standby mode is disabled miibus1: on fxp0 inphy0: PHY 1 on miibus1 inphy0: OUI 0x005500, model 0x0015, rev. 4 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto, auto-flow fxp0: bpf attached fxp0: Ethernet address: 00:d0:b7:70:12:7f ioapic0: routing intpin 20 (PCI IRQ 20) to lapic 0 vector 55 isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xffa0-0xffaf at device 31.1 on pci0 ata0: on atapci0 ioapic0: routing intpin 14 (ISA IRQ 14) to lapic 0 vector 56 atapci1: port 0xc080-0xc087,0xc000-0xc003,0xbc00-0xbc07,0xb880-0xb883,0xb800-0xb80f irq 22 at device 31.2 on pci0 ioapic0: routing intpin 22 (PCI IRQ 22) to lapic 0 vector 57 ata2: on atapci1 ata3: on atapci1 acpi_button0: on acpi0 attimer0: port 0x40-0x43 irq 0 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 ioapic0: routing intpin 2 (ISA IRQ 0) to lapic 0 vector 58 Event timer "i8254" frequency 1193182 Hz quality 100 atrtc0: port 0x70-0x71 irq 8 on acpi0 atrtc0: registered as a time-of-day clock (resolution 1000000us, adjustment 0.500000000s) ioapic0: routing intpin 8 (ISA IRQ 8) to lapic 0 vector 59 Event timer "RTC" frequency 32768 Hz quality 0 hpet0: iomem 0xfed00000-0xfed003ff on acpi0 hpet0: vendor 0x8086, rev 0x1, 14318180Hz 64bit, 3 timers, legacy route hpet0: t0: irqs 0x00f00000 (0), 64bit, periodic hpet0: t1: irqs 0x00f00000 (0) hpet0: t2: irqs 0x00f00800 (0) Timecounter "HPET" frequency 14318180 Hz quality 900 ioapic0: routing intpin 21 (PCI IRQ 21) to lapic 0 vector 60 Event timer "HPET" frequency 14318180 Hz quality 450 Event timer "HPET1" frequency 14318180 Hz quality 440 Event timer "HPET2" frequency 14318180 Hz quality 440 uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 ioapic0: routing intpin 4 (ISA IRQ 4) to lapic 0 vector 61 uart0: fast interrupt uart0: console (9600,n,8,1) acpi0: wakeup code va 0xffffff8117dff000 pa 0x4000 ahc_isa_probe 0: ioport 0xc00 alloc failed ahc_isa_probe 1: ioport 0x1c00 alloc failed ahc_isa_probe 2: ioport 0x2c00 alloc failed ahc_isa_probe 3: ioport 0x3c00 alloc failed ahc_isa_probe 4: ioport 0x4c00 alloc failed ahc_isa_probe 5: ioport 0x5c00 alloc failed ahc_isa_probe 6: ioport 0x6c00 alloc failed ahc_isa_probe 7: ioport 0x7c00 alloc failed ahc_isa_probe 8: ioport 0x8c00 alloc failed ahc_isa_probe 9: ioport 0x9c00 alloc failed ahc_isa_probe 10: ioport 0xac00 alloc failed ahc_isa_probe 11: ioport 0xbc00 alloc failed ahc_isa_probe 12: ioport 0xcc00 alloc failed ahc_isa_probe 13: ioport 0xdc00 alloc failed ahc_isa_probe 14: ioport 0xec00 alloc failed ex_isa_identify() isa_probe_children: disabling PnP devices atrtc: atrtc0 already exists; skipping it attimer: attimer0 already exists; skipping it sc: sc0 already exists; skipping it uart: uart0 already exists; skipping it isa_probe_children: probing non-PnP devices orm0: at iomem 0xcc800-0xcd7ff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x100> sc0: fb0, kbd1, terminal emulator: scteken (teken terminal) vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 kbd0: atkbd0, generic (0), config:0x0, flags:0x3f0000 ioapic0: routing intpin 1 (ISA IRQ 1) to lapic 0 vector 62 atkbd0: [GIANT-LOCKED] psm0: unable to allocate IRQ fdc0 failed to probe at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 ppc0: cannot reserve I/O port range ppc0: failed to probe at irq 7 on isa0 uart1: failed to probe at port 0x2f8-0x2ff irq 3 on isa0 isa_probe_children: probing PnP devices est0: on cpu0 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 616472506004725 device_attach: est0 attach returned 6 p4tcc0: on cpu0 est1: on cpu1 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 616472506004725 device_attach: est1 attach returned 6 p4tcc1: on cpu1 est2: on cpu2 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 616472506004725 device_attach: est2 attach returned 6 p4tcc2: on cpu2 est3: on cpu3 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 616472506004725 device_attach: est3 attach returned 6 p4tcc3: on cpu3 Device configuration finished. procfs registered Timecounters tick every 1.000 msec vlan: initialized, using hash tables with chaining lo0: bpf attached hptrr: no controller detected. hdac0: Probing codec #0... hdac0: HDA Codec #0: Realtek ALC662 hdac0: HDA Codec ID: 0x10ec0662 hdac0: Vendor: 0x10ec hdac0: Device: 0x0662 hdac0: Revision: 0x01 hdac0: Stepping: 0x01 hdac0: PCI Subvendor: 0x83901043 hdac0: Found audio FG nid=1 startnode=2 endnode=39 total=37 hdac0: hdac0: Processing audio FG cad=0 nid=1... hdac0: GPIO: 0x40000002 NumGPIO=2 NumGPO=0 NumGPI=0 GPIWake=0 GPIUnsol=1 hdac0: nid 20 0x01014010 as 1 seq 0 Line-out Jack jack 1 loc 1 color Green misc 0 hdac0: nid 21 0x411111f0 as 15 seq 0 Speaker None jack 1 loc 1 color Black misc 1 hdac0: nid 22 0x411111f0 as 15 seq 0 Speaker None jack 1 loc 1 color Black misc 1 hdac0: nid 24 0x01a19830 as 3 seq 0 Mic Jack jack 1 loc 1 color Pink misc 8 hdac0: nid 25 0x02a19840 as 4 seq 0 Mic Jack jack 1 loc 2 color Pink misc 8 hdac0: nid 26 0x0181303f as 3 seq 15 Line-in Jack jack 1 loc 1 color Blue misc 0 hdac0: nid 27 0x02214020 as 2 seq 0 Headphones Jack jack 1 loc 2 color Green misc 0 hdac0: nid 28 0x411111f0 as 15 seq 0 Speaker None jack 1 loc 1 color Black misc 1 hdac0: nid 29 0x4004c601 as 0 seq 1 Line-out None jack 4 loc 0 color Res.C misc 6 hdac0: nid 30 0x411111f0 as 15 seq 0 Speaker None jack 1 loc 1 color Black misc 1 hdac0: Patched pins configuration: hdac0: nid 20 0x01014010 as 1 seq 0 Line-out Jack jack 1 loc 1 color Green misc 0 hdac0: nid 21 0x411111f0 as 15 seq 0 Speaker None jack 1 loc 1 color Black misc 1 [DISABLED] hdac0: nid 22 0x411111f0 as 15 seq 0 Speaker None jack 1 loc 1 color Black misc 1 [DISABLED] hdac0: nid 24 0x01a19830 as 3 seq 0 Mic Jack jack 1 loc 1 color Pink misc 8 hdac0: nid 25 0x02a19840 as 4 seq 0 Mic Jack jack 1 loc 2 color Pink misc 8 hdac0: nid 26 0x0181303f as 3 seq 15 Line-in Jack jack 1 loc 1 color Blue misc 0 hdac0: nid 27 0x02214020 as 2 seq 0 Headphones Jack jack 1 loc 2 color Green misc 0 hdac0: nid 28 0x411111f0 as 15 seq 0 Speaker None jack 1 loc 1 color Black misc 1 [DISABLED] hdac0: nid 29 0x4004c601 as 0 seq 1 Line-out None jack 4 loc 0 color Res.C misc 6 [DISABLED] hdac0: nid 30 0x411111f0 as 15 seq 0 Speaker None jack 1 loc 1 color Black misc 1 [DISABLED] hdac0: 4 associations found: hdac0: Association 0 (1) out: hdac0: Pin nid=20 seq=0 hdac0: Association 1 (2) out: hdac0: Pin nid=27 seq=0 hdac0: Association 2 (3) in: hdac0: Pin nid=24 seq=0 hdac0: Pin nid=26 seq=15 hdac0: Association 3 (4) in: hdac0: Pin nid=25 seq=0 hdac0: Tracing association 0 (1) hdac0: Pin 20 traced to DAC 2 hdac0: Association 0 (1) trace succeeded hdac0: Tracing association 1 (2) hdac0: Pin 27 traced to DAC 4 hdac0: Association 1 (2) trace succeeded hdac0: Tracing association 2 (3) hdac0: Pin 24 traced to ADC 8 hdac0: Pin 26 traced to ADC 8 hdac0: Association 2 (3) trace succeeded hdac0: Tracing association 3 (4) hdac0: Pin 25 traced to ADC 9 hdac0: Association 3 (4) trace succeeded hdac0: Tracing input monitor hdac0: Tracing nid 11 to out hdac0: nid 11 is input monitor hdac0: Tracing nid 34 to out hdac0: Tracing nid 35 to out hdac0: Tracing other input monitors hdac0: Tracing nid 24 to out hdac0: Tracing nid 25 to out hdac0: Tracing nid 26 to out hdac0: Tracing beeper hdac0: FG config/quirks: forcestereo ivref50 ivref80 ivref100 ivref hdac0: hdac0: +-------------------+ hdac0: | DUMPING HDA NODES | hdac0: +-------------------+ hdac0: hdac0: Default Parameter hdac0: ----------------- hdac0: Stream cap: 0x00000001 hdac0: PCM hdac0: PCM cap: 0x000e0160 hdac0: 16 20 24 bits, 44 48 96 KHz hdac0: IN amp: 0x00000000 hdac0: OUT amp: 0x00000000 hdac0: hdac0: nid: 2 hdac0: Name: audio output hdac0: Widget cap: 0x0000001d hdac0: STEREO hdac0: Association: 0 (0x00000001) hdac0: OSS: pcm (pcm) hdac0: Stream cap: 0x00000001 hdac0: PCM hdac0: PCM cap: 0x000e0160 hdac0: 16 20 24 bits, 44 48 96 KHz hdac0: Output amp: 0x00034040 hdac0: mute=0 step=64 size=3 offset=64 hdac0: hdac0: nid: 3 [DISABLED] hdac0: Name: audio output hdac0: Widget cap: 0x0000001d hdac0: STEREO hdac0: Stream cap: 0x00000001 hdac0: PCM hdac0: PCM cap: 0x000e0160 hdac0: 16 20 24 bits, 44 48 96 KHz hdac0: Output amp: 0x00034040 hdac0: mute=0 step=64 size=3 offset=64 hdac0: hdac0: nid: 4 hdac0: Name: audio output hdac0: Widget cap: 0x0000001d hdac0: STEREO hdac0: Association: 1 (0x00000001) hdac0: OSS: pcm (pcm) hdac0: Stream cap: 0x00000001 hdac0: PCM hdac0: PCM cap: 0x000e0160 hdac0: 16 20 24 bits, 44 48 96 KHz hdac0: Output amp: 0x00034040 hdac0: mute=0 step=64 size=3 offset=64 hdac0: hdac0: nid: 5 [DISABLED] hdac0: Name: vendor widget hdac0: Widget cap: 0x00f00000 hdac0: hdac0: nid: 6 [DISABLED] hdac0: Name: audio output hdac0: Widget cap: 0x00000211 hdac0: DIGITAL STEREO hdac0: Stream cap: 0x00000001 hdac0: PCM hdac0: PCM cap: 0x000e0160 hdac0: 16 20 24 bits, 44 48 96 KHz hdac0: hdac0: nid: 7 [DISABLED] hdac0: Name: vendor widget hdac0: Widget cap: 0x00f00000 hdac0: hdac0: nid: 8 hdac0: Name: audio input hdac0: Widget cap: 0x0010011b hdac0: STEREO hdac0: Association: 2 (0x00008001) hdac0: Stream cap: 0x00000001 hdac0: PCM hdac0: PCM cap: 0x00060160 hdac0: 16 20 bits, 44 48 96 KHz hdac0: Input amp: 0x80051f09 hdac0: mute=1 step=31 size=5 offset=9 hdac0: connections: 1 hdac0: | hdac0: + <- nid=35 [audio mixer] hdac0: hdac0: nid: 9 hdac0: Name: audio input hdac0: Widget cap: 0x0010011b hdac0: STEREO hdac0: Association: 3 (0x00000001) hdac0: Stream cap: 0x00000001 hdac0: PCM hdac0: PCM cap: 0x00060160 hdac0: 16 20 bits, 44 48 96 KHz hdac0: Input amp: 0x80051f09 hdac0: mute=1 step=31 size=5 offset=9 hdac0: connections: 1 hdac0: | hdac0: + <- nid=34 [audio mixer] hdac0: hdac0: nid: 10 [DISABLED] hdac0: Name: vendor widget hdac0: Widget cap: 0x00f00000 hdac0: hdac0: nid: 11 hdac0: Name: audio mixer hdac0: Widget cap: 0x0020010b hdac0: STEREO hdac0: Association: 2 (0x00008001) hdac0: OSS: mix (mix) hdac0: Input amp: 0x80051f17 hdac0: mute=1 step=31 size=5 offset=23 hdac0: connections: 9 hdac0: | hdac0: + <- nid=24 [pin: Mic (Pink Jack)] hdac0: + [DISABLED] <- nid=25 [pin: Mic (Pink Jack)] hdac0: + <- nid=26 [pin: Line-in (Blue Jack)] hdac0: + [DISABLED] <- nid=27 [pin: Headphones (Green Jack)] hdac0: + [DISABLED] <- nid=28 [pin: Speaker (None)] [DISABLED] hdac0: + [DISABLED] <- nid=29 [pin: Line-out (None)] [DISABLED] hdac0: + [DISABLED] <- nid=20 [pin: Line-out (Green Jack)] hdac0: + [DISABLED] <- nid=21 [pin: Speaker (None)] [DISABLED] hdac0: + [DISABLED] <- nid=22 [pin: Speaker (None)] [DISABLED] hdac0: hdac0: nid: 12 hdac0: Name: audio mixer hdac0: Widget cap: 0x0020010b hdac0: STEREO hdac0: Association: 0 (0x00000001) hdac0: OSS: pcm, mix hdac0: Input amp: 0x80000000 hdac0: mute=1 step=0 size=0 offset=0 hdac0: connections: 2 hdac0: | hdac0: + <- nid=2 [audio output] hdac0: + <- nid=11 [audio mixer] hdac0: hdac0: nid: 13 [DISABLED] hdac0: Name: audio mixer hdac0: Widget cap: 0x0020010b hdac0: STEREO hdac0: Input amp: 0x80000000 hdac0: mute=1 step=0 size=0 offset=0 hdac0: connections: 2 hdac0: | hdac0: + [DISABLED] <- nid=3 [audio output] [DISABLED] hdac0: + [DISABLED] <- nid=11 [audio mixer] hdac0: hdac0: nid: 14 hdac0: Name: audio mixer hdac0: Widget cap: 0x0020010b hdac0: STEREO hdac0: Association: 1 (0x00000001) hdac0: OSS: pcm, mix hdac0: Input amp: 0x80000000 hdac0: mute=1 step=0 size=0 offset=0 hdac0: connections: 2 hdac0: | hdac0: + <- nid=4 [audio output] hdac0: + <- nid=11 [audio mixer] hdac0: hdac0: nid: 15 [DISABLED] hdac0: Name: vendor widget hdac0: Widget cap: 0x00f00000 hdac0: hdac0: nid: 16 [DISABLED] hdac0: Name: vendor widget hdac0: Widget cap: 0x00f00000 hdac0: hdac0: nid: 17 [DISABLED] hdac0: Name: vendor widget hdac0: Widget cap: 0x00f00000 hdac0: hdac0: nid: 18 [DISABLED] hdac0: Name: vendor widget hdac0: Widget cap: 0x00f00000 hdac0: hdac0: nid: 19 [DISABLED] hdac0: Name: vendor widget hdac0: Widget cap: 0x00f00000 hdac0: hdac0: nid: 20 hdac0: Name: pin: Line-out (Green Jack) hdac0: Widget cap: 0x0040018d hdac0: UNSOL STEREO hdac0: Association: 0 (0x00000001) hdac0: Pin cap: 0x0001003c hdac0: PDC HP OUT IN EAPD hdac0: Pin config: 0x01014010 hdac0: Pin control: 0x00000040 OUT hdac0: EAPD: 0x00000002 hdac0: Output amp: 0x80000000 hdac0: mute=1 step=0 size=0 offset=0 hdac0: connections: 1 hdac0: | hdac0: + <- nid=12 [audio mixer] hdac0: hdac0: nid: 21 [DISABLED] hdac0: Name: pin: Speaker (None) hdac0: Widget cap: 0x0040018d hdac0: UNSOL STEREO hdac0: Pin cap: 0x00010034 hdac0: PDC OUT IN EAPD hdac0: Pin config: 0x411111f0 hdac0: Pin control: 0x00000000 hdac0: EAPD: 0x00000002 hdac0: Output amp: 0x80000000 hdac0: mute=1 step=0 size=0 offset=0 hdac0: connections: 1 hdac0: | hdac0: + [DISABLED] <- nid=13 [audio mixer] [DISABLED] hdac0: hdac0: nid: 22 [DISABLED] hdac0: Name: pin: Speaker (None) hdac0: Widget cap: 0x0040018d hdac0: UNSOL STEREO hdac0: Pin cap: 0x00000034 hdac0: PDC OUT IN hdac0: Pin config: 0x411111f0 hdac0: Pin control: 0x00000000 hdac0: Output amp: 0x80000000 hdac0: mute=1 step=0 size=0 offset=0 hdac0: connections: 1 hdac0: | hdac0: + [DISABLED] <- nid=14 [audio mixer] hdac0: hdac0: nid: 23 [DISABLED] hdac0: Name: vendor widget hdac0: Widget cap: 0x00f00000 hdac0: hdac0: nid: 24 hdac0: Name: pin: Mic (Pink Jack) hdac0: Widget cap: 0x0040018f hdac0: UNSOL STEREO hdac0: Association: 2 (0x00000001) hdac0: OSS: mic (mic) hdac0: Pin cap: 0x00001734 hdac0: PDC OUT IN VREF[ 50 80 GROUND HIZ ] hdac0: Pin config: 0x01a19830 hdac0: Pin control: 0x00000024 IN VREFs hdac0: Output amp: 0x80000000 hdac0: mute=1 step=0 size=0 offset=0 hdac0: Input amp: 0x00270300 hdac0: mute=0 step=3 size=39 offset=0 hdac0: connections: 1 hdac0: | hdac0: + [DISABLED] <- nid=14 [audio mixer] hdac0: hdac0: nid: 25 hdac0: Name: pin: Mic (Pink Jack) hdac0: Widget cap: 0x0040018f hdac0: UNSOL STEREO hdac0: Association: 3 (0x00000001) hdac0: OSS: monitor (monitor) hdac0: Pin cap: 0x0000173c hdac0: PDC HP OUT IN VREF[ 50 80 GROUND HIZ ] hdac0: Pin config: 0x02a19840 hdac0: Pin control: 0x00000024 IN VREFs hdac0: Output amp: 0x80000000 hdac0: mute=1 step=0 size=0 offset=0 hdac0: Input amp: 0x00270300 hdac0: mute=0 step=3 size=39 offset=0 hdac0: connections: 2 hdac0: | hdac0: + [DISABLED] <- nid=12 [audio mixer] (selected) hdac0: + [DISABLED] <- nid=14 [audio mixer] hdac0: hdac0: nid: 26 hdac0: Name: pin: Line-in (Blue Jack) hdac0: Widget cap: 0x0040018d hdac0: UNSOL STEREO hdac0: Association: 2 (0x00008000) hdac0: OSS: line (line) hdac0: Pin cap: 0x00000034 hdac0: PDC OUT IN hdac0: Pin config: 0x0181303f hdac0: Pin control: 0x00000020 IN hdac0: Output amp: 0x80000000 hdac0: mute=1 step=0 size=0 offset=0 hdac0: connections: 1 hdac0: | hdac0: + [DISABLED] <- nid=13 [audio mixer] [DISABLED] hdac0: hdac0: nid: 27 hdac0: Name: pin: Headphones (Green Jack) hdac0: Widget cap: 0x0040018f hdac0: UNSOL STEREO hdac0: Association: 1 (0x00000001) hdac0: Pin cap: 0x0000173c hdac0: PDC HP OUT IN VREF[ 50 80 GROUND HIZ ] hdac0: Pin config: 0x02214020 hdac0: Pin control: 0x000000c0 HP OUT hdac0: Output amp: 0x80000000 hdac0: mute=1 step=0 size=0 offset=0 hdac0: Input amp: 0x00270300 hdac0: mute=0 step=3 size=39 offset=0 hdac0: connections: 2 hdac0: | hdac0: + [DISABLED] <- nid=12 [audio mixer] hdac0: + <- nid=14 [audio mixer] (selected) hdac0: hdac0: nid: 28 [DISABLED] hdac0: Name: pin: Speaker (None) hdac0: Widget cap: 0x00400001 hdac0: STEREO hdac0: Pin cap: 0x00000020 hdac0: IN hdac0: Pin config: 0x411111f0 hdac0: Pin control: 0x00000000 hdac0: hdac0: nid: 29 [DISABLED] hdac0: Name: pin: Line-out (None) hdac0: Widget cap: 0x00400000 hdac0: Pin cap: 0x00000020 hdac0: IN hdac0: Pin config: 0x4004c601 hdac0: Pin control: 0x00000000 hdac0: hdac0: nid: 30 [DISABLED] hdac0: Name: pin: Speaker (None) hdac0: Widget cap: 0x00400300 hdac0: DIGITAL hdac0: Pin cap: 0x00000010 hdac0: OUT hdac0: Pin config: 0x411111f0 hdac0: Pin control: 0x00000000 hdac0: connections: 1 hdac0: | hdac0: + <- nid=6 [audio output] [DISABLED] hdac0: hdac0: nid: 31 [DISABLED] hdac0: Name: vendor widget hdac0: Widget cap: 0x00f00000 hdac0: hdac0: nid: 32 [DISABLED] hdac0: Name: vendor widget hdac0: Widget cap: 0x00f00040 hdac0: PROC hdac0: hdac0: nid: 33 [DISABLED] hdac0: Name: vendor widget hdac0: Widget cap: 0x00f00000 hdac0: hdac0: nid: 34 hdac0: Name: audio mixer hdac0: Widget cap: 0x0020010b hdac0: STEREO hdac0: Association: 3 (0x00000001) hdac0: OSS: monitor hdac0: Input amp: 0x80000000 hdac0: mute=1 step=0 size=0 offset=0 hdac0: connections: 10 hdac0: | hdac0: + [DISABLED] <- nid=24 [pin: Mic (Pink Jack)] hdac0: + <- nid=25 [pin: Mic (Pink Jack)] hdac0: + [DISABLED] <- nid=26 [pin: Line-in (Blue Jack)] hdac0: + [DISABLED] <- nid=27 [pin: Headphones (Green Jack)] hdac0: + [DISABLED] <- nid=28 [pin: Speaker (None)] [DISABLED] hdac0: + [DISABLED] <- nid=29 [pin: Line-out (None)] [DISABLED] hdac0: + [DISABLED] <- nid=20 [pin: Line-out (Green Jack)] hdac0: + [DISABLED] <- nid=21 [pin: Speaker (None)] [DISABLED] hdac0: + [DISABLED] <- nid=22 [pin: Speaker (None)] [DISABLED] hdac0: + [DISABLED] <- nid=11 [audio mixer] hdac0: hdac0: nid: 35 hdac0: Name: audio mixer hdac0: Widget cap: 0x0020010b hdac0: STEREO hdac0: Association: 2 (0x00008001) hdac0: OSS: line, mic, mix hdac0: Input amp: 0x80000000 hdac0: mute=1 step=0 size=0 offset=0 hdac0: connections: 10 hdac0: | hdac0: + <- nid=24 [pin: Mic (Pink Jack)] hdac0: + [DISABLED] <- nid=25 [pin: Mic (Pink Jack)] hdac0: + <- nid=26 [pin: Line-in (Blue Jack)] hdac0: + [DISABLED] <- nid=27 [pin: Headphones (Green Jack)] hdac0: + [DISABLED] <- nid=28 [pin: Speaker (None)] [DISABLED] hdac0: + [DISABLED] <- nid=29 [pin: Line-out (None)] [DISABLED] hdac0: + [DISABLED] <- nid=20 [pin: Line-out (Green Jack)] hdac0: + [DISABLED] <- nid=21 [pin: Speaker (None)] [DISABLED] hdac0: + [DISABLED] <- nid=22 [pin: Speaker (None)] [DISABLED] hdac0: + <- nid=11 [audio mixer] hdac0: hdac0: nid: 36 [DISABLED] hdac0: Name: vendor widget hdac0: Widget cap: 0x00f00000 hdac0: hdac0: nid: 37 [DISABLED] hdac0: Name: vendor widget hdac0: Widget cap: 0x00f00000 hdac0: hdac0: nid: 38 [DISABLED] hdac0: Name: vendor widget hdac0: Widget cap: 0x00f00000 hdac0: pcm0: at cad 0 nid 1 on hdac0 pcm0: +--------------------------------------+ pcm0: | DUMPING PCM Playback/Record Channels | pcm0: +--------------------------------------+ pcm0: pcm0: Playback: pcm0: pcm0: Stream cap: 0x00000001 pcm0: PCM pcm0: PCM cap: 0x000e0160 pcm0: 16 20 24 bits, 44 48 96 KHz pcm0: DAC: 2 pcm0: pcm0: Record: pcm0: pcm0: Stream cap: 0x00000001 pcm0: PCM pcm0: PCM cap: 0x00060160 pcm0: 16 20 bits, 44 48 96 KHz pcm0: ADC: 8 pcm0: pcm0: +-------------------------------+ pcm0: | DUMPING Playback/Record Paths | pcm0: +-------------------------------+ pcm0: pcm0: Playback: pcm0: pcm0: nid=20 [pin: Line-out (Green Jack)] pcm0: | pcm0: + <- nid=12 [audio mixer] [src: pcm, mix] pcm0: | pcm0: + <- nid=2 [audio output] [src: pcm] pcm0: + <- nid=11 [audio mixer] [src: mix] pcm0: pcm0: Record: pcm0: pcm0: nid=8 [audio input] pcm0: | pcm0: + <- nid=35 [audio mixer] [src: line, mic, mix] pcm0: | pcm0: + <- nid=24 [pin: Mic (Pink Jack)] [src: mic] pcm0: + <- nid=26 [pin: Line-in (Blue Jack)] [src: line] pcm0: + <- nid=11 [audio mixer] [src: mix] pcm0: pcm0: Input Mix: pcm0: pcm0: nid=11 [audio mixer] pcm0: | pcm0: + <- nid=24 [pin: Mic (Pink Jack)] [src: mic] pcm0: + <- nid=26 [pin: Line-in (Blue Jack)] [src: line] pcm0: pcm0: +-------------------------+ pcm0: | DUMPING Volume Controls | pcm0: +-------------------------+ pcm0: pcm0: Master Volume (OSS: vol) pcm0: | pcm0: +- ctl 1 (nid 2 out): -64/0dB (65 steps) pcm0: +- ctl 15 (nid 12 in 0): mute pcm0: +- ctl 16 (nid 12 in 1): mute pcm0: +- ctl 21 (nid 20 in ): mute pcm0: pcm0: PCM Volume (OSS: pcm) pcm0: | pcm0: +- ctl 1 (nid 2 out): -64/0dB (65 steps) pcm0: +- ctl 15 (nid 12 in 0): mute pcm0: pcm0: Microphone Volume (OSS: mic) pcm0: | pcm0: +- ctl 25 (nid 24 out): 0/30dB (4 steps) pcm0: +- ctl 41 (nid 35 in 0): mute pcm0: pcm0: Line-in Volume (OSS: line) pcm0: | pcm0: +- ctl 8 (nid 11 in 2): -34/12dB (32 steps) + mute pcm0: +- ctl 43 (nid 35 in 2): mute pcm0: pcm0: Recording Level (OSS: rec) pcm0: | pcm0: +- ctl 4 (nid 8 in 0): -13/33dB (32 steps) + mute pcm0: +- ctl 41 (nid 35 in 0): mute pcm0: +- ctl 43 (nid 35 in 2): mute pcm0: +- ctl 50 (nid 35 in 9): mute pcm0: pcm0: Input Mix Level (OSS: mix) pcm0: | pcm0: +- ctl 6 (nid 11 in 0): -34/12dB (32 steps) + mute pcm0: +- ctl 8 (nid 11 in 2): -34/12dB (32 steps) + mute pcm0: +- ctl 16 (nid 12 in 1): mute pcm0: +- ctl 50 (nid 35 in 9): mute pcm0: pcm0: Input Monitoring Level (OSS: igain) pcm0: | pcm0: +- ctl 16 (nid 12 in 1): mute pcm0: pcm0: Mixer "vol": pcm0: Mixer "pcm": pcm0: Mixer "line": pcm0: Mixer "mic": pcm0: Mixer "mix": pcm0: Mixer "rec": pcm0: Mixer "igain": pcm0: Mixer "ogain": pcm0: clone manager: deadline=750ms flags=0x8000001e pcm0: sndbuf_setmap 41b0000, 4000; 0xffffff8117e17000 -> 41b0000 pcm0: sndbuf_setmap 3e60000, 4000; 0xffffff8117e27000 -> 3e60000 pcm1: at cad 0 nid 1 on hdac0 pcm1: +--------------------------------------+ pcm1: | DUMPING PCM Playback/Record Channels | pcm1: +--------------------------------------+ pcm1: pcm1: Playback: pcm1: pcm1: Stream cap: 0x00000001 pcm1: PCM pcm1: PCM cap: 0x000e0160 pcm1: 16 20 24 bits, 44 48 96 KHz pcm1: DAC: 4 pcm1: pcm1: Record: pcm1: pcm1: Stream cap: 0x00000001 pcm1: PCM pcm1: PCM cap: 0x00060160 pcm1: 16 20 bits, 44 48 96 KHz pcm1: ADC: 9 pcm1: pcm1: +-------------------------------+ pcm1: | DUMPING Playback/Record Paths | pcm1: +-------------------------------+ pcm1: pcm1: Playback: pcm1: pcm1: nid=27 [pin: Headphones (Green Jack)] pcm1: | pcm1: + <- nid=14 [audio mixer] [src: pcm, mix] pcm1: | pcm1: + <- nid=4 [audio output] [src: pcm] pcm1: + <- nid=11 [audio mixer] [src: mix] pcm1: pcm1: Record: pcm1: pcm1: nid=9 [audio input] pcm1: | pcm1: + <- nid=34 [audio mixer] [src: monitor] pcm1: | pcm1: + <- nid=25 [pin: Mic (Pink Jack)] [src: monitor] pcm1: pcm1: +-------------------------+ pcm1: | DUMPING Volume Controls | pcm1: +-------------------------+ pcm1: pcm1: Master Volume (OSS: vol) pcm1: | pcm1: +- ctl 3 (nid 4 out): -64/0dB (65 steps) pcm1: +- ctl 19 (nid 14 in 0): mute pcm1: +- ctl 20 (nid 14 in 1): mute pcm1: +- ctl 29 (nid 27 in ): mute pcm1: pcm1: PCM Volume (OSS: pcm) pcm1: | pcm1: +- ctl 3 (nid 4 out): -64/0dB (65 steps) pcm1: +- ctl 19 (nid 14 in 0): mute pcm1: pcm1: Microphone2 Volume (OSS: monitor) pcm1: | pcm1: +- ctl 27 (nid 25 out): 0/30dB (4 steps) pcm1: +- ctl 32 (nid 34 in 1): mute pcm1: pcm1: Recording Level (OSS: rec) pcm1: | pcm1: +- ctl 5 (nid 9 in 0): -13/33dB (32 steps) + mute pcm1: +- ctl 32 (nid 34 in 1): mute pcm1: pcm1: Input Mix Level (OSS: mix) pcm1: | pcm1: +- ctl 20 (nid 14 in 1): mute pcm1: pcm1: Input Monitoring Level (OSS: igain) pcm1: | pcm1: +- ctl 20 (nid 14 in 1): mute pcm1: pcm1: Mixer "vol": pcm1: Mixer "pcm": pcm1: Mixer "mix": pcm1: Mixer "rec": pcm1: Mixer "igain": pcm1: Mixer "monitor": pcm1: clone manager: deadline=750ms flags=0x8000001e pcm1: sndbuf_setmap 3e70000, 4000; 0xffffff8117e37000 -> 3e70000 pcm1: sndbuf_setmap 41c0000, 4000; 0xffffff8117e47000 -> 41c0000 fxp0: link state changed to DOWN usbus0: 12Mbps Full Speed USB v1.0 usbus1: 12Mbps Full Speed USB v1.0 ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 usbus2: 12Mbps Full Speed USB v1.0 usbus3: 12Mbps Full Speed USB v1.0 ugen2.1: at usbus2 uhub2: on usbus2 ugen3.1: at usbus3 uhub3: on usbus3 usbus4: 480Mbps High Speed USB v2.0 ata0: reset tp1 mask=03 ostat0=7f ostat1=7f ugen4.1: at usbus4 uhub4: on usbus4 uhub0: 2 ports with 2 removable, self powered uhub1: 2 ports with 2 removable, self powered ata0: stat0=0x00 err=0x00 lsb=0x00 msb=0x00 ata0: stat1=0x7f err=0x7f lsb=0x7f msb=0x7f uhub2: 2 ports with 2 removable, self powered uhub3: 2 ports with 2 removable, self powered ata0: stat1=0x7f err=0x7f lsb=0x7f msb=0x7f ata0: stat1=0x7f err=0x7f lsb=0x7f msb=0x7f ata0: stat1=0x7f err=0x7f lsb=0x7f msb=0x7f ata0: stat1=0x00 err=0x00 lsb=0x00 msb=0x00 ata0: reset tp2 stat0=00 stat1=00 devices=0x0 ata2: SATA reset: ports status=0x05 ata2: reset tp1 mask=03 ostat0=50 ostat1=00 ata2: stat0=0x50 err=0x01 lsb=0x00 msb=0x00 ata2: stat1=0x00 err=0x01 lsb=0x14 msb=0xeb ata2: reset tp2 stat0=50 stat1=00 devices=0x20001 (aprobe0:ata2:0:0:0): SIGNATURE: 0000 ata3: SATA reset: ports status=0x00 (aprobe0:ata2:0:1:0): SIGNATURE: eb14 pass0 at ata2 bus 0 scbus1 target 0 lun 0 pass0: ATA-8 SATA 2.x device pass0: Serial Number WD-WCAV55611064 pass0: 150.000MB/s transfers (SATA, UDMA5, PIO 8192bytes) pass1 at ata2 bus 0 scbus1 target 1 lun 0 pass1: Removable CD-ROM SCSI-0 device pass1: Serial Number K1Z9C4B0949 pass1: 150.000MB/s transfers (SATA, UDMA5, ATAPI 12bytes, PIO 8192bytes) ada0 at ata2 bus 0 scbus1 target 0 lun 0 GEOM: new disk ada0 ada0: ATA-8 SATA 2.x device ada0: Serial Number WD-WCAV55611064 ada0: 150.000MB/s transfers (SATA, UDMA5, PIO 8192bytes) ada0: 953869MB (1953525168 512 byte sectors: 16H 63S/T 16383C) ada0: Previously was known as ad4 SMP: AP CPU #1 Launched! (cd0:cpu1 AP: ata2:0: ID: 0x01000000 VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff 1: lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff 0): timer: 0x000100ef therm: 0x00010000 err: 0x000000f0SCSI status error pmc: 0x00010400 (cd0:ata2:0:1:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 SMP: AP CPU #3 Launched! cpu3 AP: (cd0:ata2:0:1:0): CAM status: SCSI Status Error ID: 0x03000000 VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff (cd0:ata2:0:1:0): SCSI status: Check Condition lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff (cd0:ata2:0:1:0): SCSI sense: NOT READY asc:3a,1 (Medium not present - tray closed) timer: 0x000100ef therm: 0x00010000 err: 0x000000f0(cd0: pmc: 0x00010400ata2:0: 1:SMP: AP CPU #2 Launched! 0): cpu2 AP: Error 6, Unretryable error ID: 0x02000000 VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff cd0 at ata2 bus 0 scbus1 target 1 lun 0 lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff cd0: timer: 0x000100ef therm: 0x00010000 err: 0x000000f0 Removable CD-ROM SCSI-0 device pmc: 0x00010400cd0: Serial Number K1Z9C4B0949 cd0: 150.000MB/s transfersioapic0: routing intpin 1 ( (ISA IRQ 1SATA, ) to lapic 1 vector 48 UDMA5, ATAPI 12bytes, PIO 8192bytes) cd0: Attempt to query device size failed: NOT READY, Medium not present - tray closed ioapic0: routing intpin 4 (ISA IRQ 4) to lapic 2 vector 48 ioapic0: routing intpin 9 (ISA IRQ 9) to lapic 3 vector 48 ioapic0: routing intpin 16 (PCI IRQ 16) to lapic 1 vector 49 ioapic0: routing intpin 18 (PCI IRQ 18) to lapic 2 vector 49 ioapic0: routing intpin 19 (PCI IRQ 19) to lapic 3 vector 49 ioapic0: routing intpin 22 (GEOM_PART: integrity check failed (ada0, MBR) PCI IRQ 22) to lapic 1 vector 50 ioapic0: routing intpin 23 (PCI IRQ 23) to lapic 2 vector 50 msi: Assigning MSI IRQ 256 to local APIC 3 vector 50 SMP: passed TSC synchronization test Timecounter "TSC" frequency 2500055430 Hz quality 800 GEOM: new disk cd0 (cd0:ata2:0:1:0): SCSI status error (cd0:ata2:0:1:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 (cd0:ata2:0:1:0): CAM status: SCSI Status Error (cd0:ata2:0:1:0): SCSI status: Check Condition (cd0:ata2:0:1:0): SCSI sense: NOT READY asc:3a,1 (Medium not present - tray closed) (cd0:ata2:0:1:0): Error 6, Unretryable error uhub4: (cd0:8 ports with 8 removable, self powered ata2:0:1:0): SCSI status error (cd0:ata2:0:1:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 (cd0:ata2:0:1:0): CAM status: SCSI Status Error (cd0:ata2:0:1:0): SCSI status: Check Condition (cd0:ata2:0:1:0): SCSI sense: NOT READY asc:3a,1 (Medium not present - tray closed) (cd0:ata2:0:1:0): Error 6, Unretryable error Root mount waiting for: usbus4 ugen4.2: at usbus4 umass0: on usbus4 umass0: SCSI over Bulk-Only; quirks = 0x0000 Root mount waiting for: usbus4 ugen1.2: at usbus1 ukbd0: on usbus1 kbd2 at ukbd0 kbd2: ukbd0, generic (0), config:0x0, flags:0x3d0000 umass0:3:0:-1: Attached to scbus3 (probe0:umass-sim0:0:0:0): Root mount waiting for:Down reving Protocol Version from 2 to 0? usbus4 Trying to mount root from ufs:/dev/ada0s1a [rw]... (probe0:mountroot: waiting for device /dev/ada0s1a ... umass-sim0:0:0:0): SCSI status error (probe0:umass-sim0:0:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 (probe0:umass-sim0:0:0:0): CAM status: SCSI Status Error (probe0:umass-sim0:0:0:0): SCSI status: Check Condition (probe0:umass-sim0:0:0:0): SCSI sense: NOT READY asc:3a,0 (Medium not present) (probe0:umass-sim0:0:0:0): Error 6, Unretryable error GEOM: new disk da0 pass2 at umass-sim0 bus 0 scbus3 target 0 lun 0 pass2: Removable Direct Access SCSI-0 device pass2: Serial Number 606569746801 pass2: 40.000MB/s transfers (da0:umass-sim0:0:0:0): SCSI status error (da0:umass-sim0:0:0:0): READ CAPACITY(10). CDB: 25 0 0 0 0 0 0 0 0 0 (da0:umass-sim0:0:0:0): CAM status: SCSI Status Error (da0:umass-sim0:0:0:0): SCSI status: Check Condition (da0:umass-sim0:0:0:0): SCSI sense: NOT READY asc:3a,0 (Medium not present) (da0:umass-sim0:0:0:0): Error 6, Unretryable error da0 at umass-sim0 bus 0 scbus3 target 0 lun 0 da0: Removable Direct Access SCSI-0 device da0: Serial Number 606569746801 da0: 40.000MB/s transfers da0: Attempt to query device size failed: NOT READY, Medium not present (da0:umass-sim0:0:0:0): SCSI status error (da0:umass-sim0:0:0:0): READ CAPACITY(10). CDB: 25 0 0 0 0 0 0 0 0 0 (da0:umass-sim0:0:0:0): CAM status: SCSI Status Error (da0:umass-sim0:0:0:0): SCSI status: Check Condition ugen3.2: at usbus3 (da0:umass-sim0:0:0:0): SCSI sense: NOT READY asc:3a,0 (Medium not present) (da0:umass-sim0:0:0:0): Error 6, Unretryable error ukbd1: Opened disk da0 -> 6 (probe0: on usbus3 umass-sim0:0:kbd3 at ukbd1 0:kbd3: ukbd1, generic (0), config:0x0, flags:0x3d00001): Down reving Protocol Version from 2 to 0? ums0: on usbus3 ums0: 5 buttons and [XYZT] coordinates ID=26 ums0: 0 buttons and [T] coordinates ID=0 uhid0: on usbus3 (probe0:umass-sim0:0:0:1): SCSI status error (probe0:umass-sim0:0:0:1): TEST UNIT READY. CDB: 0 20 0 0 0 0 (probe0:umass-sim0:0:0:1): CAM status: SCSI Status Error (probe0:umass-sim0:0:0:1): SCSI status: Check Condition (probe0:umass-sim0:0:0:1): SCSI sense: NOT READY asc:3a,0 (Medium not present) (probe0:umass-sim0:0:0:1): Error 6, Unretryable error pass3 at umass-sim0 bus 0 scbus3 target 0 lun 1 pass3: Removable Direct Access SCSI-0 device pass3: Serial Number 606569746801 pass3: 40.000MB/s transfers (da0:umass-sim0:0:0:0): SCSI status error Mounting from ufs:/dev/ada0s1a failed with error 19(da0:umass-sim0:0:0:0): READ CAPACITY(10). CDB: 25 0 0 0 0 0 0 0 0 0 . (da0:umass-sim0:0:0:0): CAM status: SCSI Status Error (da0:umass-sim0:0:0:0): SCSI status: Check Condition Loader variables: (da0:umass-sim0:0:0:0): SCSI sense: NOT READY asc:3a,0 (Medium not present) vfs.root.mountfrom=ufs:/dev/ada0s1a (da0: vfs.root.mountfrom.options=rw umass-sim0:0: 0:Manual root filesystem specification: 0): : [options] Error 6, Unretryable error Mount using filesystem Opened disk da0 -> 6 and with the specified (optional) option list. (da1: umass-sim0:0: eg. ufs:/dev/da0s1a 0: zfs:tank 1): cd9660:/dev/acd0 ro SCSI status error (which is equivalent to: (da1:umass-sim0:0:0:1): READ CAPACITY(10). CDB: 25 20 0 0 0 0 0 0 0 0 mount -t cd9660 -o ro /dev/acd0 /) (da1:umass-sim0:0:0:1): CAM status: SCSI Status Error (da1:umass-sim0:0:0:1): SCSI status: Check Condition ? List valid disk boot devices (da1:umass-sim0:0:0:1): SCSI sense: NOT READY asc:3a,0 (Medium not present) . Yield 1 second (for background tasks) (da1: Abort manual input umass-sim0:0: 0:mountroot> 1): Error 6, Unretryable error da1 at umass-sim0 bus 0 scbus3 target 0 lun 1 da1: Removable Direct Access SCSI-0 device da1: Serial Number 606569746801 da1: 40.000MB/s transfers da1: Attempt to query device size failed: NOT READY, Medium not present (probe0:umass-sim0:0:0:2): Down reving Protocol Version from 2 to 0? (probe0:umass-sim0:0:0:2): SCSI status error (probe0:umass-sim0:0:0:2): TEST UNIT READY. CDB: 0 40 0 0 0 0 (probe0:umass-sim0:0:0:2): CAM status: SCSI Status Error (probe0:umass-sim0:0:0:2): SCSI status: Check Condition (probe0:umass-sim0:0:0:2): SCSI sense: NOT READY asc:3a,0 (Medium not present) (probe0:umass-sim0:0:0:2): Error 6, Unretryable error pass4 at umass-sim0 bus 0 scbus3 target 0 lun 2 pass4: Removable Direct Access SCSI-0 device pass4: Serial Number 606569746801 pass4: 40.000MB/s transfers (da2:umass-sim0:0:0:2): SCSI status error (da2:umass-sim0:0:0:2): READ CAPACITY(10). CDB: 25 40 0 0 0 0 0 0 0 0 (da2:umass-sim0:0:0:2): CAM status: SCSI Status Error (da2:umass-sim0:0:0:2): SCSI status: Check Condition (da2:umass-sim0:0:0:2): SCSI sense: NOT READY asc:3a,0 (Medium not present) (da2:umass-sim0:0:0:2): Error 6, Unretryable error da2 at umass-sim0 bus 0 scbus3 target 0 lun 2 da2: Removable Direct Access SCSI-0 device da2: Serial Number 606569746801 da2: 40.000MB/s transfers da2: Attempt to query device size failed: NOT READY, Medium not present (probe0:umass-sim0:0:0:3): Down reving Protocol Version from 2 to 0? (probe0:umass-sim0:0:0:3): SCSI status error (probe0:umass-sim0:0:0:3): TEST UNIT READY. CDB: 0 60 0 0 0 0 (probe0:umass-sim0:0:0:3): CAM status: SCSI Status Error (probe0:umass-sim0:0:0:3): SCSI status: Check Condition (probe0:umass-sim0:0:0:3): SCSI sense: NOT READY asc:3a,0 (Medium not present) (probe0:umass-sim0:0:0:3): Error 6, Unretryable error pass5 at umass-sim0 bus 0 scbus3 target 0 lun 3 pass5: Removable Direct Access SCSI-0 device pass5: Serial Number 606569746801 pass5: 40.000MB/s transfers (da3:umass-sim0:0:0:3): SCSI status error (da3:umass-sim0:0:0:3): READ CAPACITY(10). CDB: 25 60 0 0 0 0 0 0 0 0 (da3:umass-sim0:0:0:3): CAM status: SCSI Status Error (da3:umass-sim0:0:0:3): SCSI status: Check Condition (da3:umass-sim0:0:0:3): SCSI sense: NOT READY asc:3a,0 (Medium not present) (da3:umass-sim0:0:0:3): Error 6, Unretryable error da3 at umass-sim0 bus 0 scbus3 target 0 lun 3 da3: Removable Direct Access SCSI-0 device da3: Serial Number 606569746801 da3: 40.000MB/s transfers da3: Attempt to query device size failed: NOT READY, Medium not present panic: mountroot: unable to (re-)mount root. cpuid = 3 KDB: enter: panic [ thread pid 1 tid 100002 ] Stopped at kdb_enter+0x3b: movq $0,0x8c5bb2(%rip) --------------080509060508010808060307-- From owner-freebsd-current@FreeBSD.ORG Sun May 15 18:27:55 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9B66C106566B; Sun, 15 May 2011 18:27:55 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 6C89F8FC08; Sun, 15 May 2011 18:27:55 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.4) with ESMTP id p4FIRsQ5077233; Sun, 15 May 2011 14:27:54 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.4/Submit) id p4FIRs6V077197; Sun, 15 May 2011 18:27:54 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 15 May 2011 18:27:54 GMT Message-Id: <201105151827.p4FIRs6V077197@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on i386/i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 May 2011 18:27:55 -0000 TB --- 2011-05-15 16:10:00 - tinderbox 2.7 running on freebsd-current.sentex.ca TB --- 2011-05-15 16:10:00 - starting HEAD tinderbox run for i386/i386 TB --- 2011-05-15 16:10:00 - cleaning the object tree TB --- 2011-05-15 16:10:23 - cvsupping the source tree TB --- 2011-05-15 16:10:23 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/i386/supfile TB --- 2011-05-15 16:12:01 - building world TB --- 2011-05-15 16:12:01 - MAKEOBJDIRPREFIX=/obj TB --- 2011-05-15 16:12:01 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-05-15 16:12:01 - TARGET=i386 TB --- 2011-05-15 16:12:01 - TARGET_ARCH=i386 TB --- 2011-05-15 16:12:01 - TZ=UTC TB --- 2011-05-15 16:12:01 - __MAKE_CONF=/dev/null TB --- 2011-05-15 16:12:01 - cd /src TB --- 2011-05-15 16:12:01 - /usr/bin/make -B buildworld >>> World build started on Sun May 15 16:12:02 UTC 2011 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sun May 15 18:10:44 UTC 2011 TB --- 2011-05-15 18:10:44 - generating LINT kernel config TB --- 2011-05-15 18:10:44 - cd /src/sys/i386/conf TB --- 2011-05-15 18:10:44 - /usr/bin/make -B LINT TB --- 2011-05-15 18:10:44 - building LINT kernel TB --- 2011-05-15 18:10:44 - MAKEOBJDIRPREFIX=/obj TB --- 2011-05-15 18:10:44 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-05-15 18:10:44 - TARGET=i386 TB --- 2011-05-15 18:10:44 - TARGET_ARCH=i386 TB --- 2011-05-15 18:10:44 - TZ=UTC TB --- 2011-05-15 18:10:44 - __MAKE_CONF=/dev/null TB --- 2011-05-15 18:10:44 - cd /src TB --- 2011-05-15 18:10:44 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun May 15 18:10:44 UTC 2011 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-sse -mno-mmx -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/fdc/fdc_acpi.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-sse -mno-mmx -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/fdc/fdc_isa.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-sse -mno-mmx -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/fdc/fdc_pccard.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-sse -mno-mmx -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/fe/if_fe_isa.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-sse -mno-mmx -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/glxiic/glxiic.c /src/sys/dev/glxiic/glxiic.c:158:1: error: "DEBUG" redefined In file included from :0: ./opt_global.h:36:1: error: this is the location of the previous definition *** Error code 1 Stop in /obj/i386.i386/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-05-15 18:27:53 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-05-15 18:27:53 - ERROR: failed to build lint kernel TB --- 2011-05-15 18:27:53 - 6620.68 user 1076.66 system 8273.19 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Sun May 15 18:29:16 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A154B106564A; Sun, 15 May 2011 18:29:16 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 7344F8FC22; Sun, 15 May 2011 18:29:16 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.4) with ESMTP id p4FITFH0085017; Sun, 15 May 2011 14:29:15 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.4/Submit) id p4FITF3p085012; Sun, 15 May 2011 18:29:15 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 15 May 2011 18:29:15 GMT Message-Id: <201105151829.p4FITF3p085012@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on i386/pc98 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 May 2011 18:29:16 -0000 TB --- 2011-05-15 16:10:00 - tinderbox 2.7 running on freebsd-current.sentex.ca TB --- 2011-05-15 16:10:00 - starting HEAD tinderbox run for i386/pc98 TB --- 2011-05-15 16:10:00 - cleaning the object tree TB --- 2011-05-15 16:10:20 - cvsupping the source tree TB --- 2011-05-15 16:10:20 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/pc98/supfile TB --- 2011-05-15 16:12:01 - building world TB --- 2011-05-15 16:12:01 - MAKEOBJDIRPREFIX=/obj TB --- 2011-05-15 16:12:01 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-05-15 16:12:01 - TARGET=pc98 TB --- 2011-05-15 16:12:01 - TARGET_ARCH=i386 TB --- 2011-05-15 16:12:01 - TZ=UTC TB --- 2011-05-15 16:12:01 - __MAKE_CONF=/dev/null TB --- 2011-05-15 16:12:01 - cd /src TB --- 2011-05-15 16:12:01 - /usr/bin/make -B buildworld >>> World build started on Sun May 15 16:12:02 UTC 2011 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sun May 15 18:10:19 UTC 2011 TB --- 2011-05-15 18:10:19 - generating LINT kernel config TB --- 2011-05-15 18:10:19 - cd /src/sys/pc98/conf TB --- 2011-05-15 18:10:19 - /usr/bin/make -B LINT TB --- 2011-05-15 18:10:19 - building LINT kernel TB --- 2011-05-15 18:10:19 - MAKEOBJDIRPREFIX=/obj TB --- 2011-05-15 18:10:19 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-05-15 18:10:19 - TARGET=pc98 TB --- 2011-05-15 18:10:19 - TARGET_ARCH=i386 TB --- 2011-05-15 18:10:19 - TZ=UTC TB --- 2011-05-15 18:10:19 - __MAKE_CONF=/dev/null TB --- 2011-05-15 18:10:19 - cd /src TB --- 2011-05-15 18:10:19 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun May 15 18:10:19 UTC 2011 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] awk -f /src/sys/conf/kmod_syms.awk geom_zero.kld export_syms | xargs -J% objcopy % geom_zero.kld ld -Bshareable -d -warn-common -o geom_zero.ko geom_zero.kld objcopy --strip-debug geom_zero.ko ===> glxiic (all) cc -O2 -pipe -DPC98 -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/pc98.i386/src/sys/LINT/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -I/obj/pc98.i386/src/sys/LINT -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-sse -mno-mmx -msoft-float -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -c /src/sys/modules/glxiic/../../dev/glxiic/glxiic.c /src/sys/modules/glxiic/../../dev/glxiic/glxiic.c:158:1: error: "DEBUG" redefined In file included from :0: /obj/pc98.i386/src/sys/LINT/opt_global.h:5:1: error: this is the location of the previous definition *** Error code 1 Stop in /src/sys/modules/glxiic. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/pc98.i386/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-05-15 18:29:15 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-05-15 18:29:15 - ERROR: failed to build lint kernel TB --- 2011-05-15 18:29:15 - 6680.30 user 1103.41 system 8354.98 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Sun May 15 19:27:54 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C53EB1065670; Sun, 15 May 2011 19:27:54 +0000 (UTC) (envelope-from brix@FreeBSD.org) Received: from solow.pil.dk (relay.pil.dk [195.41.47.164]) by mx1.freebsd.org (Postfix) with ESMTP id 3FC3C8FC0C; Sun, 15 May 2011 19:27:54 +0000 (UTC) Received: from druadan.brixandersen.dk (0x55534f5f.adsl.cybercity.dk [85.83.79.95]) by solow.pil.dk (Postfix) with ESMTPA id 9D0B91CC004; Sun, 15 May 2011 21:11:13 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-13-761955596" From: Henrik Brix Andersen In-Reply-To: <201105151829.p4FITF3p085012@freebsd-current.sentex.ca> Date: Sun, 15 May 2011 21:11:09 +0200 Content-Transfer-Encoding: 7bit Message-Id: <8CFB2BA5-7032-4155-A1F3-B504D61552C7@FreeBSD.org> References: <201105151829.p4FITF3p085012@freebsd-current.sentex.ca> To: FreeBSD Tinderbox X-Pgp-Agent: GPGMail 1.3.3 X-Mailer: Apple Mail (2.1084) Cc: current@freebsd.org, i386@freebsd.org Subject: Re: [head tinderbox] failure on i386/pc98 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, 15 May 2011 19:27:54 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-13-761955596 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On May 15, 2011, at 20:29, FreeBSD Tinderbox wrote: > =3D=3D=3D> glxiic (all) > cc -O2 -pipe -DPC98 -fno-strict-aliasing -Werror -D_KERNEL = -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include = /obj/pc98.i386/src/sys/LINT/opt_global.h -I. -I@ -I@/contrib/altq = -finline-limit=3D8000 --param inline-unit-growth=3D100 --param = large-function-growth=3D1000 -fno-common -I/obj/pc98.i386/src/sys/LINT = -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=3D2 = -mno-sse -mno-mmx -msoft-float -ffreestanding -fstack-protector = -std=3Diso9899:1999 -fstack-protector -Wall -Wredundant-decls = -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes = -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign = -fformat-extensions -Wmissing-include-dirs -c = /src/sys/modules/glxiic/../../dev/glxiic/glxiic.c > /src/sys/modules/glxiic/../../dev/glxiic/glxiic.c:158:1: error: = "DEBUG" redefined > In file included from :0: > /obj/pc98.i386/src/sys/LINT/opt_global.h:5:1: error: this is the = location of the previous definition > *** Error code 1 Fixed, my apologies. Brix --=20 Henrik Brix Andersen --Apple-Mail-13-761955596 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iEYEARECAAYFAk3QJU4ACgkQv+Q4flTiePjy7gCePxohwizdslFvpk5dXBgHlK/P UhAAn0IpOxEeBXrO3mdUOvtXDdTzClDu =VZ/8 -----END PGP SIGNATURE----- --Apple-Mail-13-761955596-- From owner-freebsd-current@FreeBSD.ORG Sun May 15 19:37:41 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 9788E106564A for ; Sun, 15 May 2011 19:37:41 +0000 (UTC) (envelope-from ae@FreeBSD.org) Received: from [127.0.0.1] (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id D89B814E052; Sun, 15 May 2011 19:37:40 +0000 (UTC) Message-ID: <4DD02B73.10807@FreeBSD.org> Date: Sun, 15 May 2011 23:37:23 +0400 From: "Andrey V. Elsukov" User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.17) Gecko/20110429 Thunderbird/3.1.10 MIME-Version: 1.0 To: Michiel Boland References: <4DD015F1.6090203@xs4all.nl> In-Reply-To: <4DD015F1.6090203@xs4all.nl> X-Enigmail-Version: 1.1.2 OpenPGP: id=10C8A17A Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigF3C31134E010876CFAE365A0" Cc: FreeBSD Current Subject: Re: -CURRENT: mountroot failed 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, 15 May 2011 19:37:41 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigF3C31134E010876CFAE365A0 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable On 15.05.2011 22:05, Michiel Boland wrote: > ioapic0: routing intpin 22 (GEOM_PART: integrity check failed (ada0, MB= R) Can you send me a binary image of the first sector of ada0? Also, output of `gpart list ada0` would be helpful. --=20 WBR, Andrey V. Elsukov --------------enigF3C31134E010876CFAE365A0 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (FreeBSD) iQEcBAEBAgAGBQJN0Ct4AAoJEAHF6gQQyKF6rLsH/iei2eeBrDK+YnoBPJD253EV Cd0Jbd3U7lTw+juNMZ9XqVAB+fRr4vYBxQNExZjQJMeG5b07i5/9tQflM++h6ibu 9oDv0RYqxIxuWvGUTB+1Oy3d61LQOQMoV/MOEEaQQjQcz/4fomn+uAfmmRGb8DAG 5irhdJkIyRD6BfDYNRQFCl+Wjhy4Gpb5jPsQCEcPPPDRP38OeNvtidaHhweptPWn Bvf9T6d/sBeJawwln23A7CvPT4xWCkGXMM+g6pksYaHGFTw96Ojzinf/O4/wqLZb 1BDOy5FX0tny2oFQBJQC3Pgtjy8f028iAoyyk/CaKe+hRU9TxHMKQ9/1hdcvyfU= =xAiS -----END PGP SIGNATURE----- --------------enigF3C31134E010876CFAE365A0-- From owner-freebsd-current@FreeBSD.ORG Mon May 16 00:50: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 F0AB9106564A for ; Mon, 16 May 2011 00:50:04 +0000 (UTC) (envelope-from deeptech71@gmail.com) Received: from mail-pw0-f54.google.com (mail-pw0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id BEFA48FC16 for ; Mon, 16 May 2011 00:50:04 +0000 (UTC) Received: by pwj8 with SMTP id 8so2501590pwj.13 for ; Sun, 15 May 2011 17:50:04 -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:content-type; bh=A7vf9xaVv9ysd4ENd52uPBNz/hYAREAWGl8Z7is97SY=; b=eN8kZwZ7ctKrDuv8MH1GL+lkKZLXVd/DcYb3NmFerurJ/2LrsuT+Ul2xLLeb43CBhD +5C4PBNpH8rk12HZPslaYaksa3JU0WpokxSQpC3Nz9tOOsx1O490ofh3te9rJZgmxwly 68+UpamubXCSSTG+2fLVvXpl+7h9cJIpWaYNw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=pTvksUw/HXXTEmo3C5nrBU0OOYT9du/QbyfM9htxqKWLjIEPxt7Zgl+2PtFx3D0s67 aA52tfgpKyjqr4vzS9DaM53siMYmIWTbs8aNEy3A2fJnEwljQSr209aIhmHo1GzFBrCd xoDgCHzk12b1MOMf271aHHyHxugdf+cOGK2tY= MIME-Version: 1.0 Received: by 10.68.1.35 with SMTP id 3mr6617669pbj.7.1305507004178; Sun, 15 May 2011 17:50:04 -0700 (PDT) Received: by 10.68.71.130 with HTTP; Sun, 15 May 2011 17:50:04 -0700 (PDT) In-Reply-To: References: Date: Mon, 16 May 2011 02:50:04 +0200 Message-ID: From: "deeptech71@gmail.com" To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: pcib allocation failure 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, 16 May 2011 00:50:05 -0000 On Sat, May 14, 2011 at 6:27 PM, deeptech71@gmail.com wrote: > pcib1: at device 1.0 on pci0 > pcib1: failed to allocate initial prefetch window: 0xd0000000-0xfaffffff > > this happens with a the r221862 kernel, but not with the r221309 kernel. > a quick search reveals something: > http://www.freebsd.org/cgi/query-pr.cgi?pr=143874 (i have no idea what > that is). indeed, r221394 introduced the said behaviour by using a new PCI bus driver or something. with "nooptions NEW_PCIB", even the latest sources (r221970) do not exhibit the said behaviour. i conclude that the new PCI bus driver basically sux. From owner-freebsd-current@FreeBSD.ORG Mon May 16 00:56:47 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 476E4106564A for ; Mon, 16 May 2011 00:56:47 +0000 (UTC) (envelope-from yanegomi@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 01B168FC1A for ; Mon, 16 May 2011 00:56:46 +0000 (UTC) Received: by vxc34 with SMTP id 34so3868681vxc.13 for ; Sun, 15 May 2011 17:56:46 -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=duwpVHiIE1jtfqAhL1pYbBWsowpdTVRAWkhPdY6QDpQ=; b=FDEehRibTu3rdTputMgTjN2BLm8xnXtu2vV/J2uI7nqY1M62jkAFtNeCCmbtiTgCdW hBRuic49L199SuhJVEmn6ykM9guLgS+QRJ5E2aH7ROzcx6NUEyQHFj/wicJuaGJyySQv vhtRnMathGHFXz1FX77d8BeOk2m2Qexo4TQR4= 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=CulUJFp2Oy/Q//Sqvt30puw2+3NogGfXHckRvrTer65k3ztpWNNc8g0gxTWLeQ5eYc 7DeZJDEw9YuzrhzxXbKzzDBIdXST/64nqgDTgQ/R6GIiKtZ8gTmejrw42i6Xt9IGltVr s7NIMHHIHk0upZMmITeN96Mlo9OE8MQXRCoYw= MIME-Version: 1.0 Received: by 10.52.74.74 with SMTP id r10mr5351505vdv.212.1305507406253; Sun, 15 May 2011 17:56:46 -0700 (PDT) Received: by 10.220.188.202 with HTTP; Sun, 15 May 2011 17:56:46 -0700 (PDT) In-Reply-To: References: Date: Sun, 15 May 2011 17:56:46 -0700 Message-ID: From: Garrett Cooper To: "deeptech71@gmail.com" Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current@freebsd.org Subject: Re: pcib allocation failure 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, 16 May 2011 00:56:47 -0000 On Sun, May 15, 2011 at 5:50 PM, deeptech71@gmail.com wrote: > On Sat, May 14, 2011 at 6:27 PM, deeptech71@gmail.com > wrote: >> pcib1: at device 1.0 on pci0 >> pcib1: failed to allocate initial prefetch window: 0xd0000000-0xfaffffff >> >> this happens with a the r221862 kernel, but not with the r221309 kernel. >> a quick search reveals something: >> http://www.freebsd.org/cgi/query-pr.cgi?pr=143874 (i have no idea what >> that is). > > indeed, r221394 introduced the said behaviour by using a new PCI bus > driver or something. with "nooptions NEW_PCIB", even the latest > sources (r221970) do not exhibit the said behaviour. i conclude that > the new PCI bus driver basically sux. Could you please provide more details, like boot -v output, etc? Thanks! -Garrett From owner-freebsd-current@FreeBSD.ORG Mon May 16 00:35: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 2914E1065670 for ; Mon, 16 May 2011 00:35:59 +0000 (UTC) (envelope-from dieterich.joh@googlemail.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 E7D998FC1B for ; Mon, 16 May 2011 00:35:58 +0000 (UTC) Received: by iwn33 with SMTP id 33so4913235iwn.13 for ; Sun, 15 May 2011 17:35:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=+yevxFYjJ/2iB9g9uH/1CnYGLp60Dyvz0pzIWNJxqAQ=; b=O94rlKQUPz/QQ3bxc/qTsmzVw/kVkZ4cjtA/wKatNlU7+BelJcA1DmB6zPydLV2p1w zNyW33Ws3gfu3+XvR/waJ6gownn26qJja9eu4GDKuTWmdOj6QAFJX+YxFOgKO1GViLuf DJH2n0OJJ4/hnKUA8SNkfvLBZHza5bvflypKo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=WmdZBqnuCN2HmiiliuD/+ZC7dm3RE8FbBvN9ymDMMteiVsp5VsKgbK+aGx0dzo5EQ+ BCp25JYHysu6q6IHqt/7OUgXX5dJECEoNJ6ZnUSHWtZ4kB5zAtua5pgBELXm/PCUiUK/ cBonaT1atJyPO5WYmwFkvr2mDuLi/gjRZPYGw= MIME-Version: 1.0 Received: by 10.231.66.69 with SMTP id m5mr2793579ibi.55.1305504561785; Sun, 15 May 2011 17:09:21 -0700 (PDT) Received: by 10.231.14.140 with HTTP; Sun, 15 May 2011 17:09:21 -0700 (PDT) Date: Mon, 16 May 2011 02:09:21 +0200 Message-ID: From: Johannes Dieterich To: freebsd-current@freebsd.org X-Mailman-Approved-At: Mon, 16 May 2011 01:04:10 +0000 Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Boot halts on Thinkpad X220 (Sandy Bridge) 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, 16 May 2011 00:35:59 -0000 Hello everybody, on a Thinkpad X220 (Sandy Bridge/Cougar Point based) the installation medium loads but halts during boot. I tested the following versions of FreeBSD * 8.2-RELEASE * 9-CURRENT (latest official snapshot from 02/2011) * 9-CURRENT (latest snapshot from Nathan Whitehorn as of 20/04/2011 [1]) * 9-CURRENT (own release medium as of today prepared with the generate-release script) With 8.2, I see the same error messages as [2] with PCBSD-8 (not surprising, of course, but please note that there is no Firewire in this notebook). I do not see what the error message is with 9.0 before it halts. Anyway, according to Kris Moore this is a "known issue with FreeBSD". I have not found anything about such problem in the mailing list archives (apologies if I am wrong). Therefore my question simply is, whether this problem is known and (if yes) there is a fix or workaround available for CURRENT. If needed, I can post a dmesg of a successful boot of the openSUSE-11.4-LiveCD as reference (not doing so now because I assume the list will anyway eat the attachment). Also, I can provide whatever can be obtained using said Linux. Thanks a lot or any replies! :-) Johannes Dieterich [1] http://people.freebsd.org/~nwhitehorn/ [2] http://forums.pcbsd.org/showthread.php?p=87366 From owner-freebsd-current@FreeBSD.ORG Mon May 16 13:40: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 4D8D4106564A for ; Mon, 16 May 2011 13:40:20 +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 246398FC0A for ; Mon, 16 May 2011 13:40:20 +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 CBA9646B09; Mon, 16 May 2011 09:40:19 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 6CA4B8A04F; Mon, 16 May 2011 09:40:19 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Date: Mon, 16 May 2011 09:37:53 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110325; KDE/4.5.5; amd64; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201105160937.53197.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Mon, 16 May 2011 09:40:19 -0400 (EDT) Cc: "deeptech71@gmail.com" Subject: Re: pcib allocation failure 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, 16 May 2011 13:40:20 -0000 On Sunday, May 15, 2011 8:50:04 pm deeptech71@gmail.com wrote: > On Sat, May 14, 2011 at 6:27 PM, deeptech71@gmail.com > wrote: > > pcib1: at device 1.0 on pci0 > > pcib1: failed to allocate initial prefetch window: 0xd0000000-0xfaffffff > > > > this happens with a the r221862 kernel, but not with the r221309 kernel. > > a quick search reveals something: > > http://www.freebsd.org/cgi/query-pr.cgi?pr=143874 (i have no idea what > > that is). > > indeed, r221394 introduced the said behaviour by using a new PCI bus > driver or something. with "nooptions NEW_PCIB", even the latest > sources (r221970) do not exhibit the said behaviour. i conclude that > the new PCI bus driver basically sux. A more helpful approach would be to provide a verbose dmesg, devinfo -ur, and devinfo -rv output. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Mon May 16 13:40: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 B4BE21065672 for ; Mon, 16 May 2011 13:40:20 +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 8B8038FC0C for ; Mon, 16 May 2011 13:40:20 +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 3EC9E46B23; Mon, 16 May 2011 09:40:20 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id D60F18A050; Mon, 16 May 2011 09:40:19 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Date: Mon, 16 May 2011 09:40:18 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110325; KDE/4.5.5; amd64; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201105160940.18935.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Mon, 16 May 2011 09:40:19 -0400 (EDT) Cc: Johannes Dieterich Subject: Re: Boot halts on Thinkpad X220 (Sandy Bridge) 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, 16 May 2011 13:40:20 -0000 On Sunday, May 15, 2011 8:09:21 pm Johannes Dieterich wrote: > Hello everybody, > > on a Thinkpad X220 (Sandy Bridge/Cougar Point based) the installation > medium loads but halts during boot. I tested the following versions of > FreeBSD > > * 8.2-RELEASE > * 9-CURRENT (latest official snapshot from 02/2011) > * 9-CURRENT (latest snapshot from Nathan Whitehorn as of 20/04/2011 [1]) > * 9-CURRENT (own release medium as of today prepared with the > generate-release script) > > With 8.2, I see the same error messages as [2] with PCBSD-8 (not > surprising, of course, but please note that there is no Firewire in this > notebook). I do not see what the error message is with 9.0 before it > halts. Anyway, according to Kris Moore this is a "known issue with > FreeBSD". I have not found anything about such problem in the mailing > list archives (apologies if I am wrong). > > Therefore my question simply is, whether this problem is known and (if > yes) there is a fix or workaround available for CURRENT. > > If needed, I can post a dmesg of a successful boot of the > openSUSE-11.4-LiveCD as reference (not doing so now because I assume the > list will anyway eat the attachment). Also, I can provide whatever can > be obtained using said Linux. > > Thanks a lot or any replies! :-) Hmm, is this booting amd64 or i386? Can you try i386 if you haven't? If i386 doesn't work at first, you might need to try disabling APIC via 'set hint.apic.0.disabled=1' at the loader prompt. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Mon May 16 15:00:14 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 9B55A1065670 for ; Mon, 16 May 2011 15:00:14 +0000 (UTC) (envelope-from ae@FreeBSD.org) Received: from [127.0.0.1] (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 65B0314F120; Mon, 16 May 2011 14:59:52 +0000 (UTC) Message-ID: <4DD13BE2.8020405@FreeBSD.org> Date: Mon, 16 May 2011 18:59:46 +0400 From: "Andrey V. Elsukov" User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.17) Gecko/20110429 Thunderbird/3.1.10 MIME-Version: 1.0 To: Michiel Boland References: <4DD015F1.6090203@xs4all.nl> <4DD02B73.10807@FreeBSD.org> <4DD114FE.9080406@xs4all.nl> In-Reply-To: <4DD114FE.9080406@xs4all.nl> X-Enigmail-Version: 1.1.2 OpenPGP: id=10C8A17A Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig870E5149951134557DC223F4" Cc: FreeBSD Current Subject: Re: -CURRENT: mountroot failed 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, 16 May 2011 15:00:14 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig870E5149951134557DC223F4 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable On 16.05.2011 16:13, Michiel Boland wrote: >> Can you send me a binary image of the first sector of ada0? >> Also, output of `gpart list ada0` would be helpful. > charlemagne# gpart list ada0 > Geom name: ada0 > modified: false > state: OK > fwheads: 16 > fwsectors: 63 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D> last: 1953525167 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D> first: 63 > entries: 4 > scheme: MBR > Providers: > 1. Name: ada0s1 > Mediasize: 1000204648448 (931G) > Sectorsize: 512 > Mode: r5w5e9 > attrib: active > rawtype: 165 > length: 1000204648448 > offset: 16384 > type: freebsd > index: 1 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D> end: 1953524735 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D> start: 32 Your partition has start offset below the first LBA. As temporary workaround you can set loader tunable kern.geom.part.check_integrity=3D0 (recently added to CURRENT) > (Note that I partitioned the disk so that partition 1 starts at a > multiple of 4096 bytes; this is one of those 4kb-sector disks that > performs extremely badly if access is not aligned on a 4k boundary.) What tool did you use for partitioning? --=20 WBR, Andrey V. Elsukov --------------enig870E5149951134557DC223F4 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (FreeBSD) iQEcBAEBAgAGBQJN0TvnAAoJEAHF6gQQyKF6lqEIAKQ1BTL1SmdjgsvNDUFRydxr VxO9nlGlbRabEH33qVRZ7otmmxd7FHq83MMk5C7zGz3TqkpeCFfw+yDDvbRAGp60 AFkXwE0H9Dq401MV4KbC3bRiowPyZmY3Xx8ch3bPe3WhGdXKqUu5SUTv3+G1BLrK ZNmacRVNraKJFfEGiRBEt1ogUbQI2lsCLxEiPhDgZN9SOTdTuGgnE5uTklsPPRoD n+ZlDD7VGrdtl3R2oh/1SucRpPDN2iZmM4Ofd7oO3iIEvP5VXKuxvl/JRJE5I5lt eZePseCVOoRP5x6QrVLg3HJcB8dkoOsU9cexBUqqdaF1y0B9AdtdaVBdxD3v0e4= =PRoc -----END PGP SIGNATURE----- --------------enig870E5149951134557DC223F4-- From owner-freebsd-current@FreeBSD.ORG Mon May 16 14:05: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 DE2AC1065672 for ; Mon, 16 May 2011 14:05:13 +0000 (UTC) (envelope-from dieterich.joh@googlemail.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 966AC8FC19 for ; Mon, 16 May 2011 14:05:13 +0000 (UTC) Received: by iwn33 with SMTP id 33so5477179iwn.13 for ; Mon, 16 May 2011 07:05:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=HIKhrurEyF9oggK+Cm95eG9DnsRgugVl2yrwbdR2ReQ=; b=carOYOsCVy7Srw8e/pEqvV7PvteQa44gSEWl1f26cL/PhQGp1EnJF9ubq9Gf7K9LCg dMfKI33q/yiLC9ZpYrwy+Cfy1UJbcKWJQOLph4KvDIMYRmR7HMgxZnEyvCwhaLCiLakr SR8WpNSAE+U9jYnjsjSrhMvBe3SsmsR6eN/Nw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Y5zxQ6nv5yvOSD4CcxmjYBeUsyNsqNTvBB9blRi/cfvtMaEoFeFrOHEv82UbajfnR4 2X60XnIf4ADiXCvLZ44VJP/PsrrlfUUbp1co8AsVG8wmDwRwzMHNOVYOc+abFsvI3XeV Zhp/W2JJs6/moPA0QHQeRzyAa/wstvhlqCBOM= MIME-Version: 1.0 Received: by 10.231.194.165 with SMTP id dy37mr3262548ibb.30.1305554712780; Mon, 16 May 2011 07:05:12 -0700 (PDT) Received: by 10.231.14.140 with HTTP; Mon, 16 May 2011 07:05:12 -0700 (PDT) In-Reply-To: <201105160940.18935.jhb@freebsd.org> References: <201105160940.18935.jhb@freebsd.org> Date: Mon, 16 May 2011 16:05:12 +0200 Message-ID: From: Johannes Dieterich To: John Baldwin X-Mailman-Approved-At: Mon, 16 May 2011 15:25:25 +0000 Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current@freebsd.org Subject: Re: Boot halts on Thinkpad X220 (Sandy Bridge) 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, 16 May 2011 14:05:13 -0000 On Mon, May 16, 2011 at 3:40 PM, John Baldwin wrote: > On Sunday, May 15, 2011 8:09:21 pm Johannes Dieterich wrote: > > Hello everybody, > > > > on a Thinkpad X220 (Sandy Bridge/Cougar Point based) the installation > > medium loads but halts during boot. I tested the following versions of > > FreeBSD > > > > * 8.2-RELEASE > > * 9-CURRENT (latest official snapshot from 02/2011) > > * 9-CURRENT (latest snapshot from Nathan Whitehorn as of 20/04/2011 [1]) > > * 9-CURRENT (own release medium as of today prepared with the > > generate-release script) > > > > With 8.2, I see the same error messages as [2] with PCBSD-8 (not > > surprising, of course, but please note that there is no Firewire in this > > notebook). I do not see what the error message is with 9.0 before it > > halts. Anyway, according to Kris Moore this is a "known issue with > > FreeBSD". I have not found anything about such problem in the mailing > > list archives (apologies if I am wrong). > > > > Therefore my question simply is, whether this problem is known and (if > > yes) there is a fix or workaround available for CURRENT. > > > > If needed, I can post a dmesg of a successful boot of the > > openSUSE-11.4-LiveCD as reference (not doing so now because I assume the > > list will anyway eat the attachment). Also, I can provide whatever can > > be obtained using said Linux. > > > > Thanks a lot or any replies! :-) > > Hmm, is this booting amd64 or i386? Can you try i386 if you haven't? If > i386 > doesn't work at first, you might need to try disabling APIC via 'set > hint.apic.0.disabled=1' at the loader prompt. > Sorry, forgot to mention it. Machine has 8 GB of RAM so I have been using amd64 images for all tests. I will try tonight with an i386 snapshot. Would the one provided by Nathan Whitehorn be recent enough? Anything in particular that you would be interested in if it should work (verbose dmesg, ...)? Thanks a lot for the reply! Johannes Dieterich From owner-freebsd-current@FreeBSD.ORG Mon May 16 15:52:11 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 E642B106566B for ; Mon, 16 May 2011 15:52:11 +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 BBA268FC1E for ; Mon, 16 May 2011 15:52:11 +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 740FC46B2C; Mon, 16 May 2011 11:52:11 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id E62D18A050; Mon, 16 May 2011 11:52:10 -0400 (EDT) From: John Baldwin To: Johannes Dieterich Date: Mon, 16 May 2011 11:48:53 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110325; KDE/4.5.5; amd64; ; ) References: <201105160940.18935.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201105161148.53382.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Mon, 16 May 2011 11:52:11 -0400 (EDT) Cc: freebsd-current@freebsd.org Subject: Re: Boot halts on Thinkpad X220 (Sandy Bridge) 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, 16 May 2011 15:52:12 -0000 On Monday, May 16, 2011 10:05:12 am Johannes Dieterich wrote: > On Mon, May 16, 2011 at 3:40 PM, John Baldwin wrote: > > > On Sunday, May 15, 2011 8:09:21 pm Johannes Dieterich wrote: > > > Hello everybody, > > > > > > on a Thinkpad X220 (Sandy Bridge/Cougar Point based) the installation > > > medium loads but halts during boot. I tested the following versions of > > > FreeBSD > > > > > > * 8.2-RELEASE > > > * 9-CURRENT (latest official snapshot from 02/2011) > > > * 9-CURRENT (latest snapshot from Nathan Whitehorn as of 20/04/2011 [1]) > > > * 9-CURRENT (own release medium as of today prepared with the > > > generate-release script) > > > > > > With 8.2, I see the same error messages as [2] with PCBSD-8 (not > > > surprising, of course, but please note that there is no Firewire in this > > > notebook). I do not see what the error message is with 9.0 before it > > > halts. Anyway, according to Kris Moore this is a "known issue with > > > FreeBSD". I have not found anything about such problem in the mailing > > > list archives (apologies if I am wrong). > > > > > > Therefore my question simply is, whether this problem is known and (if > > > yes) there is a fix or workaround available for CURRENT. > > > > > > If needed, I can post a dmesg of a successful boot of the > > > openSUSE-11.4-LiveCD as reference (not doing so now because I assume the > > > list will anyway eat the attachment). Also, I can provide whatever can > > > be obtained using said Linux. > > > > > > Thanks a lot or any replies! :-) > > > > Hmm, is this booting amd64 or i386? Can you try i386 if you haven't? If > > i386 > > doesn't work at first, you might need to try disabling APIC via 'set > > hint.apic.0.disabled=1' at the loader prompt. > > > Sorry, forgot to mention it. Machine has 8 GB of RAM so I have been using > amd64 images for all tests. I will try tonight with an i386 snapshot. Would > the one provided by Nathan Whitehorn be recent enough? Anything in > particular that you would be interested in if it should work (verbose dmesg, > ...)? Yes, a verbose dmesg would be ideal, I just figured it would be hard to get that on a laptop for the non-booting case. :) A verbose dmesg from a working boot would probably be helpful if you can get it though. > Thanks a lot for the reply! > > Johannes Dieterich > -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Mon May 16 15:52: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 3159B106566C; Mon, 16 May 2011 15:52:12 +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 06EBF8FC1F; Mon, 16 May 2011 15:52:12 +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 ABF3546B3B; Mon, 16 May 2011 11:52:11 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 4F6DC8A051; Mon, 16 May 2011 11:52:11 -0400 (EDT) From: John Baldwin To: Andriy Gapon Date: Mon, 16 May 2011 11:52:10 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110325; KDE/4.5.5; amd64; ; ) References: <4DCD357D.6000109@FreeBSD.org> <4DCFEE33.5090808@FreeBSD.org> <4DD0011D.40000@FreeBSD.org> In-Reply-To: <4DD0011D.40000@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201105161152.10458.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Mon, 16 May 2011 11:52:11 -0400 (EDT) Cc: Max Laier , FreeBSD current , neel@freebsd.org, Peter Grehan Subject: Re: proposed smp_rendezvous change 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, 16 May 2011 15:52:12 -0000 On Sunday, May 15, 2011 12:36:45 pm Andriy Gapon wrote: > on 15/05/2011 18:16 John Baldwin said the following: > > On 5/15/11 10:53 AM, Andriy Gapon wrote: > >> on 15/05/2011 10:12 Andriy Gapon said the following: > >>> on 14/05/2011 18:25 John Baldwin said the following: > >>>> Hmmm, so this is not actually sufficient. NetApp ran into a very similar race > >>>> with virtual CPUs in BHyVe. In their case because virtual CPUs are threads > >>>> that > >>>> can be preempted, they have a chance at a longer race. > >>>> > >>>> The problem that they see is that even though the values have been updated, the > >>>> next CPU to start a rendezvous can clear smp_rv_waiters[2] to zero before > >>>> one of > >>>> the other CPUs notices that it has finished. > >>> > >>> As a follow up to my previous question. Have you noticed that in my patch no > >>> slave CPU actually waits/spins on smp_rv_waiters[2]? It's always only master > >>> CPU (and under smp_ipi_mtx). > >>> > >> > >> Here's a cleaner version of my approach to the fix. > >> This one does not remove the initial wait on smp_rv_waiters[0] in > >> smp_rendezvous_action() and thus does not renumber all smp_rv_waiters[] members > >> and thus hopefully should be clearer. > >> > >> Index: sys/kern/subr_smp.c > >> =================================================================== > >> --- sys/kern/subr_smp.c (revision 221943) > >> +++ sys/kern/subr_smp.c (working copy) > >> @@ -110,7 +110,7 @@ static void (*volatile smp_rv_setup_func)(void *ar > >> static void (*volatile smp_rv_action_func)(void *arg); > >> static void (*volatile smp_rv_teardown_func)(void *arg); > >> static void *volatile smp_rv_func_arg; > >> -static volatile int smp_rv_waiters[3]; > >> +static volatile int smp_rv_waiters[4]; > >> > >> /* > >> * Shared mutex to restrict busywaits between smp_rendezvous() and > >> @@ -338,11 +338,15 @@ smp_rendezvous_action(void) > >> > >> /* spin on exit rendezvous */ > >> atomic_add_int(&smp_rv_waiters[2], 1); > >> - if (local_teardown_func == smp_no_rendevous_barrier) > >> + if (local_teardown_func == smp_no_rendevous_barrier) { > >> + atomic_add_int(&smp_rv_waiters[3], 1); > >> return; > >> + } > >> while (smp_rv_waiters[2]< smp_rv_ncpus) > >> cpu_spinwait(); > >> > >> + atomic_add_int(&smp_rv_waiters[3], 1); > >> + > >> /* teardown function */ > >> if (local_teardown_func != NULL) > >> local_teardown_func(local_func_arg); > >> @@ -377,6 +381,9 @@ smp_rendezvous_cpus(cpumask_t map, > >> /* obtain rendezvous lock */ > >> mtx_lock_spin(&smp_ipi_mtx); > >> > >> + while (smp_rv_waiters[3]< smp_rv_ncpus) > >> + cpu_spinwait(); > >> + > >> /* set static function pointers */ > >> smp_rv_ncpus = ncpus; > >> smp_rv_setup_func = setup_func; > >> @@ -385,6 +392,7 @@ smp_rendezvous_cpus(cpumask_t map, > >> smp_rv_func_arg = arg; > >> smp_rv_waiters[1] = 0; > >> smp_rv_waiters[2] = 0; > >> + smp_rv_waiters[3] = 0; > >> atomic_store_rel_int(&smp_rv_waiters[0], 0); > >> > >> /* signal other processors, which will enter the IPI with interrupts off */ > > > > Ahh, so the bump is after the change. I do think this will still be ok > > and I probably just didn't explain it well to Neel. I wonder though > > if the bump shouldn't happen until after the call of the local teardown > > function? > > That should not be necessary according to my understanding unless we have a > reason to care about potentially disappearing function text. Teardown function > pointer and argument are locally cached and I don't see any problems with a new > rendezvous being setup and run while teardowns of the previous one are still > running. > > On the other hand, you might be onto something here. If the argument is > allocated in temporary storage (e.g. on stack) and the teardown function > actually uses the argument, then it's not safe to deallocate the argument until > all of the teardowns are done. In this case the master CPU should wait not only > until all actions are done, but also until all teardowns are done. > The current code doesn't do that. And I am not sure if we actually would want > to add this safety net or just document the behavior and put a burden on > smp_rendezvous API users. As we chatted about on IRC, I think we should err on the side of making this API less complex (so that all of the actions for a given rendezvous finish before the next rendezvous begins) as this stuff is already fairly complex. We should only add more complexity if we really need it. > BTW, I don't think that we ever use smp_rendezvous() in its full glory, i.e. > with non-trivial setup, action and teardown (except perhaps for jkim's stress > test). OpenSolaris seems to be doing just fine with the following three types > of simpler CPU cross-calls (as they call them): > 1. async - a master CPU requests an action to be executed on target CPUs but > doesn't wait for anything > - we have no explicit equivalent for this > > 2. call - a master CPU requests an action to be executed on target CPUs and > waits until all the target CPUs have finished executing it > - this would be equivalent smp_rendezvous_cpus(no_barrier, action, no_barrier) > > 3. synch - a master CPU requests an action to be executed on target CPUs and > waits until all the target CPUs have finished executing it and the slave CPUs > are also waiting for their siblings to be done > - this would be equivalent smp_rendezvous_cpus(no_barrier, action, NULL) > > Seems that our current code doesn't use/need more than that as well. > But I really like the capability that smp_rendezvous_cpus() potentially provides. I would be fine with stripping down our rendezvous API a bit. They could all still use a single IPI and handler but perhaps prevent a few wrapper APIs that provide simpler semantics like this. Back to my statement above, we've had this uber-generic rendezvous API for a while, but if we don't really need it to be quite so complex I'd be happy to dumb down the API to what we really need so the implementation and use can be simpler. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Mon May 16 17:38: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 22B931065670 for ; Mon, 16 May 2011 17:38:33 +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 E9E658FC13 for ; Mon, 16 May 2011 17:38:32 +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 p4GHcSRM090288 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 16 May 2011 10:38:31 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <4DD16111.6090904@freebsd.org> Date: Mon, 16 May 2011 13:38:25 -0400 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: "deeptech71@gmail.com" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: pcib allocation failure 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, 16 May 2011 17:38:33 -0000 On 5/15/11 8:50 PM, deeptech71@gmail.com wrote: > On Sat, May 14, 2011 at 6:27 PM, deeptech71@gmail.com > wrote: >> pcib1: at device 1.0 on pci0 >> pcib1: failed to allocate initial prefetch window: 0xd0000000-0xfaffffff >> >> this happens with a the r221862 kernel, but not with the r221309 kernel. >> a quick search reveals something: >> http://www.freebsd.org/cgi/query-pr.cgi?pr=143874 (i have no idea what >> that is). > indeed, r221394 introduced the said behaviour by using a new PCI bus > driver or something. with "nooptions NEW_PCIB", even the latest > sources (r221970) do not exhibit the said behaviour. i conclude that > the new PCI bus driver basically sux. Since "sux" was not one of the design criteria for the new driver it would seem that your best course of action is to contact the author with large amounts of useful information and offer to help him fix it by providing a test platform. From owner-freebsd-current@FreeBSD.ORG Mon May 16 17:46:38 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 4D6E6106564A; Mon, 16 May 2011 17:46:38 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.171]) by mx1.freebsd.org (Postfix) with ESMTP id D6CD88FC13; Mon, 16 May 2011 17:46:37 +0000 (UTC) Received: from maxlap.localnet (gw-100.extranet.sea01.isilon.com [74.85.160.100]) by mrelayeu.kundenserver.de (node=mrbap1) with ESMTP (Nemesis) id 0LtUJA-1PfAaN31vg-011Lte; Mon, 16 May 2011 19:46:36 +0200 From: Max Laier To: John Baldwin Date: Mon, 16 May 2011 13:46:33 -0400 User-Agent: KMail/1.13.6 (FreeBSD/9.0-CURRENT; KDE/4.6.1; amd64; ; ) References: <4DCD357D.6000109@FreeBSD.org> <4DD0011D.40000@FreeBSD.org> <201105161152.10458.jhb@freebsd.org> In-Reply-To: <201105161152.10458.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201105161346.34134.max@love2party.net> X-Provags-ID: V02:K0:qPY8H9g8XnEMnk4FsNNDCMRqaoOPkaBx/Ir4Pegt18J rcnTW9vIeT/ilHN4q35y7Gn1cfdniWwaXgSzn73HAjA9dIIFcL G2Ek3xlfOPxyAGDkQxckY5jxWnJ4rVL0vgGZdLLYPmgQRitZQ0 z27qwqKp4uE9iZZneZ3W7LW8moPYo8i+QccvshhIKvvcTdcwVw trLi8VggZsCVuUL1MFI2Q== Cc: FreeBSD current , Peter Grehan , Andriy Gapon , neel@freebsd.org Subject: Re: proposed smp_rendezvous change 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, 16 May 2011 17:46:38 -0000 I'd like to propose that we move forward with fixing the race, before redesigning the API - please. We agree that there is a problem with the exit rendezvous. Let's fix that. We agree that the generation approach proposed by NetAPP is the right way to go? Can we check it in, then? Again, I'd like some comments in the code if at all possible. A second commit should take care of the entry sync - which may or may not be required on some architectures. If we decide that we don't need it, we should remove it. Otherwise, we must move all the assignments from global smp_rv_* to the stack in smp_rendezvous_action to after the sync. Otherwise we should just kill it. In any case, it would be nice to clean this up. After that, I have one more bugfix for rmlock(9) - one of the three consumers of this API (that I am aware of). As it uses a spinlock inside its IPI action, we have to mark smp_rendezvous_action a critical section otherwise the spin unlock might yield ... with the expected consequences. It is arguable if you should be allowed to use spinlocks in the rendevous at all, but that's beside the point. On Monday 16 May 2011 11:52:10 John Baldwin wrote: > On Sunday, May 15, 2011 12:36:45 pm Andriy Gapon wrote: ... > As we chatted about on IRC, I think we should err on the side of making > this API less complex (so that all of the actions for a given rendezvous > finish before the next rendezvous begins) as this stuff is already fairly > complex. We should only add more complexity if we really need it. +1 > > BTW, I don't think that we ever use smp_rendezvous() in its full glory, > > i.e. with non-trivial setup, action and teardown (except perhaps for > > jkim's stress test). OpenSolaris seems to be doing just fine with the > > following three types of simpler CPU cross-calls (as they call them): > > 1. async - a master CPU requests an action to be executed on target CPUs > > but doesn't wait for anything > > - we have no explicit equivalent for this I'd like to see something like this. Otherwise we end up with hacks like callouts that sched_bind and stuff like that. I can think of plenty use cases for this API. > > 2. call - a master CPU requests an action to be executed on target CPUs > > and waits until all the target CPUs have finished executing it > > - this would be equivalent smp_rendezvous_cpus(no_barrier, action, > > no_barrier) > > > > 3. synch - a master CPU requests an action to be executed on target CPUs > > and waits until all the target CPUs have finished executing it and the > > slave CPUs are also waiting for their siblings to be done > > - this would be equivalent smp_rendezvous_cpus(no_barrier, action, NULL) > > > > Seems that our current code doesn't use/need more than that as well. > > But I really like the capability that smp_rendezvous_cpus() potentially > > provides. > > I would be fine with stripping down our rendezvous API a bit. They could > all still use a single IPI and handler but perhaps prevent a few wrapper > APIs that provide simpler semantics like this. Back to my statement > above, we've had this uber-generic rendezvous API for a while, but if we > don't really need it to be quite so complex I'd be happy to dumb down the > API to what we really need so the implementation and use can be simpler. Again, agreed. From owner-freebsd-current@FreeBSD.ORG Mon May 16 18:21: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 3B25F106566C; Mon, 16 May 2011 18:21:29 +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 10B438FC15; Mon, 16 May 2011 18:21:29 +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 9CD7946B38; Mon, 16 May 2011 14:21:28 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 2CD518A04F; Mon, 16 May 2011 14:21:28 -0400 (EDT) From: John Baldwin To: Max Laier Date: Mon, 16 May 2011 14:21:27 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110325; KDE/4.5.5; amd64; ; ) References: <4DCD357D.6000109@FreeBSD.org> <201105161152.10458.jhb@freebsd.org> <201105161346.34134.max@love2party.net> In-Reply-To: <201105161346.34134.max@love2party.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201105161421.27665.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Mon, 16 May 2011 14:21:28 -0400 (EDT) Cc: FreeBSD current , Peter Grehan , Andriy Gapon , neel@freebsd.org Subject: Re: proposed smp_rendezvous change 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, 16 May 2011 18:21:29 -0000 On Monday, May 16, 2011 1:46:33 pm Max Laier wrote: > I'd like to propose that we move forward with fixing the race, before > redesigning the API - please. > > We agree that there is a problem with the exit rendezvous. Let's fix that. > We agree that the generation approach proposed by NetAPP is the right way to > go? Can we check it in, then? Again, I'd like some comments in the code if > at all possible. How about this: Index: subr_smp.c =================================================================== --- subr_smp.c (revision 221939) +++ subr_smp.c (working copy) @@ -111,6 +111,7 @@ static void (*volatile smp_rv_action_func)(void *a static void (*volatile smp_rv_teardown_func)(void *arg); static void *volatile smp_rv_func_arg; static volatile int smp_rv_waiters[3]; +static volatile int smp_rv_generation; /* * Shared mutex to restrict busywaits between smp_rendezvous() and @@ -311,39 +312,62 @@ restart_cpus(cpumask_t map) void smp_rendezvous_action(void) { - void* local_func_arg = smp_rv_func_arg; - void (*local_setup_func)(void*) = smp_rv_setup_func; - void (*local_action_func)(void*) = smp_rv_action_func; - void (*local_teardown_func)(void*) = smp_rv_teardown_func; + void *local_func_arg; + void (*local_setup_func)(void*); + void (*local_action_func)(void*); + void (*local_teardown_func)(void*); + int generation; /* Ensure we have up-to-date values. */ atomic_add_acq_int(&smp_rv_waiters[0], 1); while (smp_rv_waiters[0] < smp_rv_ncpus) cpu_spinwait(); - /* setup function */ + /* Fetch rendezvous parameters after acquire barrier. */ + local_func_arg = smp_rv_func_arg; + local_setup_func = smp_rv_setup_func; + local_action_func = smp_rv_action_func; + local_teardown_func = smp_rv_teardown_func; + generation = smp_rv_generation; + + /* + * If requested, run a setup function before the main action + * function. Ensure all CPUs have completed the setup + * function before moving on to the action function. + */ if (local_setup_func != smp_no_rendevous_barrier) { if (smp_rv_setup_func != NULL) smp_rv_setup_func(smp_rv_func_arg); - - /* spin on entry rendezvous */ atomic_add_int(&smp_rv_waiters[1], 1); while (smp_rv_waiters[1] < smp_rv_ncpus) cpu_spinwait(); } - /* action function */ if (local_action_func != NULL) local_action_func(local_func_arg); - /* spin on exit rendezvous */ + /* + * Signal that the main action has been completed. If a + * full exit rendezvous is requested, then all CPUs will + * wait here until all CPUs have finished the main action. + * + * Note that the write by the last CPU to finish the action + * may become visible to different CPUs at different times. + * As a result, the CPU that initiated the rendezvous may + * exit the rendezvous and drop the lock allowing another + * rendezvous to be initiated on the same CPU or a different + * CPU. In that case the exit sentinel may be cleared before + * all CPUs have noticed causing those CPUs to hang forever. + * Workaround this by using a generation count to notice when + * this race occurs and to exit the rendezvous in that case. + */ atomic_add_int(&smp_rv_waiters[2], 1); if (local_teardown_func == smp_no_rendevous_barrier) return; - while (smp_rv_waiters[2] < smp_rv_ncpus) + while (smp_rv_waiters[2] < smp_rv_ncpus && + generation == smp_rv_generation) cpu_spinwait(); - /* teardown function */ if (local_teardown_func != NULL) local_teardown_func(local_func_arg); } @@ -374,10 +398,11 @@ smp_rendezvous_cpus(cpumask_t map, if (ncpus == 0) panic("ncpus is 0 with map=0x%x", map); - /* obtain rendezvous lock */ mtx_lock_spin(&smp_ipi_mtx); - /* set static function pointers */ + atomic_add_acq_int(&smp_rv_generation, 1); + + /* Pass rendezvous parameters via global variables. */ smp_rv_ncpus = ncpus; smp_rv_setup_func = setup_func; smp_rv_action_func = action_func; @@ -387,18 +412,25 @@ smp_rendezvous_cpus(cpumask_t map, smp_rv_waiters[2] = 0; atomic_store_rel_int(&smp_rv_waiters[0], 0); - /* signal other processors, which will enter the IPI with interrupts off */ + /* + * Signal other processors, which will enter the IPI with + * interrupts off. + */ ipi_selected(map & ~(1 << curcpu), IPI_RENDEZVOUS); /* Check if the current CPU is in the map */ if ((map & (1 << curcpu)) != 0) smp_rendezvous_action(); + /* + * If the caller did not request an exit barrier to be enforced + * on each CPU, ensure that this CPU waits for all the other + * CPUs to finish the rendezvous. + */ if (teardown_func == smp_no_rendevous_barrier) while (atomic_load_acq_int(&smp_rv_waiters[2]) < ncpus) cpu_spinwait(); - /* release lock */ mtx_unlock_spin(&smp_ipi_mtx); } > A second commit should take care of the entry sync - which may or may not be > required on some architectures. If we decide that we don't need it, we should > remove it. Otherwise, we must move all the assignments from global smp_rv_* > to the stack in smp_rendezvous_action to after the sync. Otherwise we should > just kill it. In any case, it would be nice to clean this up. The patch also fixes this in the cautious fashion (not removing the early rendezvous). > After that, I have one more bugfix for rmlock(9) - one of the three consumers > of this API (that I am aware of). As it uses a spinlock inside its IPI > action, we have to mark smp_rendezvous_action a critical section otherwise the > spin unlock might yield ... with the expected consequences. Yes, we need to fix that. Humm, it doesn't preempt when you do a critical_exit() though? Or do you use a hand-rolled critical exit that doesn't do a deferred preemption? Actually, I'm curious how the spin unlock inside the IPI could yield the CPU. Oh, is rmlock doing a wakeup inside the IPI handler? I guess that is ok as long as the critical_exit() just defers the preemption to the end of the IPI handler. > It is arguable if you should be allowed to use spinlocks in the rendevous at > all, but that's beside the point. I'm less convinced this is bad since we don't use NMIs for these, so we know the interrupted thread doesn't have any spin locks in the scheduler, etc. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Mon May 16 18:57: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 5330A1065670 for ; Mon, 16 May 2011 18:57:31 +0000 (UTC) (envelope-from dieterich.johannes@googlemail.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 CD7A58FC15 for ; Mon, 16 May 2011 18:57:30 +0000 (UTC) Received: by fxm11 with SMTP id 11so4634372fxm.13 for ; Mon, 16 May 2011 11:57:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=S057Wd84WLeN9kuNUmkUysV/SEg8QQXDPmO94SHyjcg=; b=e9OD9jhUQMkCWXeNxNcZFhkg83J2ISytDrMPHsYSCJFAqNIMdyft4heFanDZCfgbBn y8E7ZsllXHU+MCXDzSFw/qaMcvpncJbN42/cH8NKN61dRGy5E3wmLDd9zZDhpxxlDA/v bvjrBllJXx70NpSWHUsZyFS+0cn5FH51y6H00= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; b=f7ov9mmD8Ryb7RvXDBqa/+i8aHutavkRgH75w1gQQCJUJ9rhcUmRqEg0z7zrM4aaLs Fg7qr3eqlOpYD5M8OdmTAsBDRBVD8Tg2Q5+52pGnkJ2hbKi8P/aw27h4moTVv7b7PzZj knhJ6wV5Ix0gpp442bbbnP9xGqYBmRfFszNX4= Received: by 10.223.98.4 with SMTP id o4mr3861731fan.120.1305572249303; Mon, 16 May 2011 11:57:29 -0700 (PDT) Received: from [192.168.1.86] (gtng-4d08adc8.pool.mediaWays.net [77.8.173.200]) by mx.google.com with ESMTPS id s17sm1954271fau.37.2011.05.16.11.57.25 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 16 May 2011 11:57:27 -0700 (PDT) Message-ID: <4DD17391.2030008@gmail.com> Date: Mon, 16 May 2011 20:57:21 +0200 From: Johannes Dieterich User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110424 Thunderbird/3.1.10 MIME-Version: 1.0 To: John Baldwin , freebsd-current@freebsd.org References: <201105160940.18935.jhb@freebsd.org> In-Reply-To: <201105160940.18935.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 16 May 2011 19:00:04 +0000 Cc: Subject: Re: Boot halts on Thinkpad X220 (Sandy Bridge) 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, 16 May 2011 18:57:31 -0000 On 05/16/2011 03:40 PM, John Baldwin wrote: > On Sunday, May 15, 2011 8:09:21 pm Johannes Dieterich wrote: >> Hello everybody, >> >> on a Thinkpad X220 (Sandy Bridge/Cougar Point based) the installation >> medium loads but halts during boot. I tested the following versions of >> FreeBSD >> >> * 8.2-RELEASE >> * 9-CURRENT (latest official snapshot from 02/2011) >> * 9-CURRENT (latest snapshot from Nathan Whitehorn as of 20/04/2011 [1]) >> * 9-CURRENT (own release medium as of today prepared with the >> generate-release script) >> >> With 8.2, I see the same error messages as [2] with PCBSD-8 (not >> surprising, of course, but please note that there is no Firewire in this >> notebook). I do not see what the error message is with 9.0 before it >> halts. Anyway, according to Kris Moore this is a "known issue with >> FreeBSD". I have not found anything about such problem in the mailing >> list archives (apologies if I am wrong). >> >> Therefore my question simply is, whether this problem is known and (if >> yes) there is a fix or workaround available for CURRENT. >> >> If needed, I can post a dmesg of a successful boot of the >> openSUSE-11.4-LiveCD as reference (not doing so now because I assume the >> list will anyway eat the attachment). Also, I can provide whatever can >> be obtained using said Linux. >> >> Thanks a lot or any replies! :-) > > Hmm, is this booting amd64 or i386? Can you try i386 if you haven't? If i386 > doesn't work at first, you might need to try disabling APIC via 'set > hint.apic.0.disabled=1' at the loader prompt. The i386 image as of 11/04/2011 of Nathan Whitehorn booted into the live system without problems. The hint was not needed. Please find a verbose dmesg at http://pastebin.com/4UTHsg7F Does this tell you anything? If you (or anybody else) should need anything more, just let me know how to obtain it! :-) Best regards Johannes Dieterich From owner-freebsd-current@FreeBSD.ORG Mon May 16 19:27:51 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 6A283106564A; Mon, 16 May 2011 19:27:51 +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 135E38FC1D; Mon, 16 May 2011 19:27:49 +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 WAA07226; Mon, 16 May 2011 22:27:48 +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 1QM3SG-00044E-73; Mon, 16 May 2011 22:27:48 +0300 Message-ID: <4DD17AB3.1070606@FreeBSD.org> Date: Mon, 16 May 2011 22:27:47 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.17) Gecko/20110503 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: John Baldwin References: <4DCD357D.6000109@FreeBSD.org> <201105161152.10458.jhb@freebsd.org> <201105161346.34134.max@love2party.net> <201105161421.27665.jhb@freebsd.org> In-Reply-To: <201105161421.27665.jhb@freebsd.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Max Laier , FreeBSD current , neel@FreeBSD.org, Peter Grehan Subject: Re: proposed smp_rendezvous change 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, 16 May 2011 19:27:51 -0000 on 16/05/2011 21:21 John Baldwin said the following: > How about this: ... > /* > * Shared mutex to restrict busywaits between smp_rendezvous() and > @@ -311,39 +312,62 @@ restart_cpus(cpumask_t map) > void > smp_rendezvous_action(void) > { > - void* local_func_arg = smp_rv_func_arg; > - void (*local_setup_func)(void*) = smp_rv_setup_func; > - void (*local_action_func)(void*) = smp_rv_action_func; > - void (*local_teardown_func)(void*) = smp_rv_teardown_func; > + void *local_func_arg; > + void (*local_setup_func)(void*); > + void (*local_action_func)(void*); > + void (*local_teardown_func)(void*); > + int generation; > > /* Ensure we have up-to-date values. */ > atomic_add_acq_int(&smp_rv_waiters[0], 1); > while (smp_rv_waiters[0] < smp_rv_ncpus) > cpu_spinwait(); > > - /* setup function */ > + /* Fetch rendezvous parameters after acquire barrier. */ > + local_func_arg = smp_rv_func_arg; > + local_setup_func = smp_rv_setup_func; > + local_action_func = smp_rv_action_func; > + local_teardown_func = smp_rv_teardown_func; I want to ask once again - please pretty please convince me that the above cpu_spinwait() loop is really needed and, by extension, that the assignments should be moved behind it. Please :) -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Mon May 16 20:30: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 A596D106564A; Mon, 16 May 2011 20:30:48 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.9]) by mx1.freebsd.org (Postfix) with ESMTP id 4D8368FC12; Mon, 16 May 2011 20:30:48 +0000 (UTC) Received: from maxlap.localnet (gw-100.extranet.sea01.isilon.com [74.85.160.100]) by mrelayeu.kundenserver.de (node=mrbap3) with ESMTP (Nemesis) id 0Lnjkl-1PlvOz0OoZ-00hvmw; Mon, 16 May 2011 22:30:47 +0200 From: Max Laier To: John Baldwin Date: Mon, 16 May 2011 16:30:44 -0400 User-Agent: KMail/1.13.6 (FreeBSD/9.0-CURRENT; KDE/4.6.1; amd64; ; ) References: <4DCD357D.6000109@FreeBSD.org> <201105161346.34134.max@love2party.net> <201105161421.27665.jhb@freebsd.org> In-Reply-To: <201105161421.27665.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201105161630.44577.max@love2party.net> X-Provags-ID: V02:K0:6byTI43OCGMB95tZ45MIaapu6SewSDu1vnTaZVMX5n0 eXOH8lYmXCfLEskX9NLvfl1SHTo9empHg/98n6UFvvQLAC94EF Tx6cWPiKSP1IXjuKqSeQmVMqxSw8TItscK6bU/Xzdszc3vLQR8 3BHugIDjBkLd+2meTXE9KGM2Xro4FOdeQV28MkM6yPMrSrrPdl 0W6oKAUdG/HPVCyHKmCfw== Cc: FreeBSD current , Peter Grehan , Andriy Gapon , neel@freebsd.org Subject: Re: proposed smp_rendezvous change 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, 16 May 2011 20:30:48 -0000 On Monday 16 May 2011 14:21:27 John Baldwin wrote: > On Monday, May 16, 2011 1:46:33 pm Max Laier wrote: > > I'd like to propose that we move forward with fixing the race, before > > redesigning the API - please. > > > > We agree that there is a problem with the exit rendezvous. Let's fix > > that. We agree that the generation approach proposed by NetAPP is the > > right way to go? Can we check it in, then? Again, I'd like some > > comments in the code if at all possible. > > How about this: > > Index: subr_smp.c > =================================================================== > --- subr_smp.c (revision 221939) > +++ subr_smp.c (working copy) > @@ -111,6 +111,7 @@ static void (*volatile smp_rv_action_func)(void *a > static void (*volatile smp_rv_teardown_func)(void *arg); > static void *volatile smp_rv_func_arg; > static volatile int smp_rv_waiters[3]; > +static volatile int smp_rv_generation; > > /* > * Shared mutex to restrict busywaits between smp_rendezvous() and > @@ -311,39 +312,62 @@ restart_cpus(cpumask_t map) > void > smp_rendezvous_action(void) > { > - void* local_func_arg = smp_rv_func_arg; > - void (*local_setup_func)(void*) = smp_rv_setup_func; > - void (*local_action_func)(void*) = smp_rv_action_func; > - void (*local_teardown_func)(void*) = smp_rv_teardown_func; > + void *local_func_arg; > + void (*local_setup_func)(void*); > + void (*local_action_func)(void*); > + void (*local_teardown_func)(void*); > + int generation; > > /* Ensure we have up-to-date values. */ > atomic_add_acq_int(&smp_rv_waiters[0], 1); > while (smp_rv_waiters[0] < smp_rv_ncpus) > cpu_spinwait(); > > - /* setup function */ > + /* Fetch rendezvous parameters after acquire barrier. */ > + local_func_arg = smp_rv_func_arg; > + local_setup_func = smp_rv_setup_func; > + local_action_func = smp_rv_action_func; > + local_teardown_func = smp_rv_teardown_func; > + generation = smp_rv_generation; > + > + /* > + * If requested, run a setup function before the main action > + * function. Ensure all CPUs have completed the setup > + * function before moving on to the action function. > + */ > if (local_setup_func != smp_no_rendevous_barrier) { > if (smp_rv_setup_func != NULL) > smp_rv_setup_func(smp_rv_func_arg); > - > - /* spin on entry rendezvous */ > atomic_add_int(&smp_rv_waiters[1], 1); > while (smp_rv_waiters[1] < smp_rv_ncpus) > cpu_spinwait(); > } > > - /* action function */ > if (local_action_func != NULL) > local_action_func(local_func_arg); > > - /* spin on exit rendezvous */ > + /* > + * Signal that the main action has been completed. If a > + * full exit rendezvous is requested, then all CPUs will > + * wait here until all CPUs have finished the main action. > + * > + * Note that the write by the last CPU to finish the action > + * may become visible to different CPUs at different times. > + * As a result, the CPU that initiated the rendezvous may > + * exit the rendezvous and drop the lock allowing another > + * rendezvous to be initiated on the same CPU or a different > + * CPU. In that case the exit sentinel may be cleared before > + * all CPUs have noticed causing those CPUs to hang forever. > + * Workaround this by using a generation count to notice when > + * this race occurs and to exit the rendezvous in that case. > + */ MPASS(generation == smp_rv_generation); > atomic_add_int(&smp_rv_waiters[2], 1); > if (local_teardown_func == smp_no_rendevous_barrier) > return; > - while (smp_rv_waiters[2] < smp_rv_ncpus) > + while (smp_rv_waiters[2] < smp_rv_ncpus && > + generation == smp_rv_generation) > cpu_spinwait(); > > - /* teardown function */ > if (local_teardown_func != NULL) > local_teardown_func(local_func_arg); > } > @@ -374,10 +398,11 @@ smp_rendezvous_cpus(cpumask_t map, > if (ncpus == 0) > panic("ncpus is 0 with map=0x%x", map); > > - /* obtain rendezvous lock */ > mtx_lock_spin(&smp_ipi_mtx); > > - /* set static function pointers */ > + atomic_add_acq_int(&smp_rv_generation, 1); > + > + /* Pass rendezvous parameters via global variables. */ > smp_rv_ncpus = ncpus; > smp_rv_setup_func = setup_func; > smp_rv_action_func = action_func; > @@ -387,18 +412,25 @@ smp_rendezvous_cpus(cpumask_t map, > smp_rv_waiters[2] = 0; > atomic_store_rel_int(&smp_rv_waiters[0], 0); > > - /* signal other processors, which will enter the IPI with interrupts off > */ + /* > + * Signal other processors, which will enter the IPI with > + * interrupts off. > + */ > ipi_selected(map & ~(1 << curcpu), IPI_RENDEZVOUS); > > /* Check if the current CPU is in the map */ > if ((map & (1 << curcpu)) != 0) > smp_rendezvous_action(); > > + /* > + * If the caller did not request an exit barrier to be enforced > + * on each CPU, ensure that this CPU waits for all the other > + * CPUs to finish the rendezvous. > + */ > if (teardown_func == smp_no_rendevous_barrier) > while (atomic_load_acq_int(&smp_rv_waiters[2]) < ncpus) > cpu_spinwait(); > > - /* release lock */ > mtx_unlock_spin(&smp_ipi_mtx); > } > > > A second commit should take care of the entry sync - which may or may not > > be required on some architectures. If we decide that we don't need it, > > we should remove it. Otherwise, we must move all the assignments from > > global smp_rv_* to the stack in smp_rendezvous_action to after the sync. > > Otherwise we should just kill it. In any case, it would be nice to > > clean this up. > > The patch also fixes this in the cautious fashion (not removing the early > rendezvous). Good idea for now. We can always remove the sync later and the assign on declare is a style(9) violation anyways. > > After that, I have one more bugfix for rmlock(9) - one of the three > > consumers of this API (that I am aware of). As it uses a spinlock > > inside its IPI action, we have to mark smp_rendezvous_action a critical > > section otherwise the spin unlock might yield ... with the expected > > consequences. > > Yes, we need to fix that. Humm, it doesn't preempt when you do a > critical_exit() though? Or do you use a hand-rolled critical exit that > doesn't do a deferred preemption? Right now I just did a manual td_critnest++/--, but I guess ... > Actually, I'm curious how the spin unlock inside the IPI could yield the > CPU. Oh, is rmlock doing a wakeup inside the IPI handler? I guess that is > ok as long as the critical_exit() just defers the preemption to the end of > the IPI handler. ... the earliest point where it is safe to preempt is after doing the atomic_add_int(&smp_rv_waiters[2], 1); so that we can start other IPIs again. However, since we don't accept new IPIs until we signal EOI in the MD code (on amd64), this might still not be a good place to do the yield?!? The spin unlock boils down to a critical_exit() and unless we did a critical_enter() at some point during the redenvouz setup, we will yield() if we owepreempt. I'm not quite sure how that can happen, but it seems like there is a path that allows the scheduler to set it from a foreign CPU. > > It is arguable if you should be allowed to use spinlocks in the rendevous > > at all, but that's beside the point. > > I'm less convinced this is bad since we don't use NMIs for these, so we > know the interrupted thread doesn't have any spin locks in the scheduler, > etc. Agreed. I'll send a patch as soon as this one's in, but it really is a simple matter of adding critical_enter/exit (or the manual version thereof) to the right places. Thanks, Max From owner-freebsd-current@FreeBSD.ORG Mon May 16 20:46: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 3E66E106564A; Mon, 16 May 2011 20:46:05 +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 147068FC0C; Mon, 16 May 2011 20:46:05 +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 A879546B09; Mon, 16 May 2011 16:46:04 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 121298A050; Mon, 16 May 2011 16:46:04 -0400 (EDT) From: John Baldwin To: Andriy Gapon Date: Mon, 16 May 2011 16:09:21 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110325; KDE/4.5.5; amd64; ; ) References: <4DCD357D.6000109@FreeBSD.org> <201105161421.27665.jhb@freebsd.org> <4DD17AB3.1070606@FreeBSD.org> In-Reply-To: <4DD17AB3.1070606@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201105161609.21898.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Mon, 16 May 2011 16:46:04 -0400 (EDT) Cc: Max Laier , FreeBSD current , neel@freebsd.org, Peter Grehan Subject: Re: proposed smp_rendezvous change 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, 16 May 2011 20:46:05 -0000 On Monday, May 16, 2011 3:27:47 pm Andriy Gapon wrote: > on 16/05/2011 21:21 John Baldwin said the following: > > How about this: > ... > > /* > > * Shared mutex to restrict busywaits between smp_rendezvous() and > > @@ -311,39 +312,62 @@ restart_cpus(cpumask_t map) > > void > > smp_rendezvous_action(void) > > { > > - void* local_func_arg = smp_rv_func_arg; > > - void (*local_setup_func)(void*) = smp_rv_setup_func; > > - void (*local_action_func)(void*) = smp_rv_action_func; > > - void (*local_teardown_func)(void*) = smp_rv_teardown_func; > > + void *local_func_arg; > > + void (*local_setup_func)(void*); > > + void (*local_action_func)(void*); > > + void (*local_teardown_func)(void*); > > + int generation; > > > > /* Ensure we have up-to-date values. */ > > atomic_add_acq_int(&smp_rv_waiters[0], 1); > > while (smp_rv_waiters[0] < smp_rv_ncpus) > > cpu_spinwait(); > > > > - /* setup function */ > > + /* Fetch rendezvous parameters after acquire barrier. */ > > + local_func_arg = smp_rv_func_arg; > > + local_setup_func = smp_rv_setup_func; > > + local_action_func = smp_rv_action_func; > > + local_teardown_func = smp_rv_teardown_func; > > I want to ask once again - please pretty please convince me that the above > cpu_spinwait() loop is really needed and, by extension, that the assignments > should be moved behind it. > Please :) Well, moving the assignments down is a style fix for one, and we can always remove the first rendezvous as a follow up if desired. However, suppose you have an arch where sending an IPI is not a barrier (this seems unlikely). In that case, the atomic_add_acq_int() will not succeed (and return) until it has seen the earlier write by the CPU initiating the rendezvous to clear smp_rv_waiters[0] to zero. The actual spin on the smp_rv_waiters[] value is not strictly necessary however and is probably just cut and pasted to match the other uses of values in the smp_rv_waiters[] array. (atomic_add_acq_int() could spin on architectures where it is implemented using compare-and-swap (e.g. sparc64) or locked-load conditional-store (e.g. Alpha).) -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Mon May 16 20:46: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 E29DF1065670; Mon, 16 May 2011 20:46:05 +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 B8AFF8FC12; Mon, 16 May 2011 20:46:05 +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 6E39446B3B; Mon, 16 May 2011 16:46:05 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 0BBCA8A052; Mon, 16 May 2011 16:46:05 -0400 (EDT) From: John Baldwin To: Max Laier Date: Mon, 16 May 2011 16:46:03 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110325; KDE/4.5.5; amd64; ; ) References: <4DCD357D.6000109@FreeBSD.org> <201105161421.27665.jhb@freebsd.org> <201105161630.44577.max@love2party.net> In-Reply-To: <201105161630.44577.max@love2party.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201105161646.03338.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Mon, 16 May 2011 16:46:05 -0400 (EDT) Cc: FreeBSD current , Peter Grehan , Andriy Gapon , neel@freebsd.org Subject: Re: proposed smp_rendezvous change 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, 16 May 2011 20:46:06 -0000 On Monday, May 16, 2011 4:30:44 pm Max Laier wrote: > On Monday 16 May 2011 14:21:27 John Baldwin wrote: > > Yes, we need to fix that. Humm, it doesn't preempt when you do a > > critical_exit() though? Or do you use a hand-rolled critical exit that > > doesn't do a deferred preemption? > > Right now I just did a manual td_critnest++/--, but I guess ... Ah, ok, so you would "lose" a preemption. That's not really ideal. > > Actually, I'm curious how the spin unlock inside the IPI could yield the > > CPU. Oh, is rmlock doing a wakeup inside the IPI handler? I guess that is > > ok as long as the critical_exit() just defers the preemption to the end of > > the IPI handler. > > ... the earliest point where it is safe to preempt is after doing the > > atomic_add_int(&smp_rv_waiters[2], 1); > > so that we can start other IPIs again. However, since we don't accept new > IPIs until we signal EOI in the MD code (on amd64), this might still not be a > good place to do the yield?!? Hmm, yeah, you would want to do the EOI before you yield. However, we could actually move the EOI up before calling the MI code so long as we leave interrupts disabled for the duration of the handler (which we do). > The spin unlock boils down to a critical_exit() and unless we did a > critical_enter() at some point during the redenvouz setup, we will yield() if > we owepreempt. I'm not quite sure how that can happen, but it seems like > there is a path that allows the scheduler to set it from a foreign CPU. No, it is only set on curthread by curthread. This is actually my main question. I've no idea how this could happen unless the rmlock code is actually triggering a wakeup or sched_add() in its rendezvous handler. I don't see anything in rm_cleanIPI() that would do that however. I wonder if your original issue was really fixed just by the first patch you had which fixed the race in smp_rendezvous()? -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Mon May 16 21:38: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 31DF7106564A; Mon, 16 May 2011 21:38:57 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.187]) by mx1.freebsd.org (Postfix) with ESMTP id CF2758FC08; Mon, 16 May 2011 21:38:56 +0000 (UTC) Received: from maxlap.localnet (gw-100.extranet.sea01.isilon.com [74.85.160.100]) by mrelayeu.kundenserver.de (node=mreu1) with ESMTP (Nemesis) id 0MOVOL-1QIV0F3TJV-005qXi; Mon, 16 May 2011 23:38:55 +0200 From: Max Laier To: John Baldwin Date: Mon, 16 May 2011 17:38:53 -0400 User-Agent: KMail/1.13.6 (FreeBSD/9.0-CURRENT; KDE/4.6.1; amd64; ; ) References: <4DCD357D.6000109@FreeBSD.org> <201105161630.44577.max@love2party.net> <201105161646.03338.jhb@freebsd.org> In-Reply-To: <201105161646.03338.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201105161738.53366.max@love2party.net> X-Provags-ID: V02:K0:nb4PwT0wL+4DuhIBzSJHxGn1wUbcB7b36jB4ucvVoBH SqmLe9quuoTGHgnkbwh2keruQMXRf4957SX+FUodF99Na4xYBP LrMwf7H/SLpk3l4Wwjq5LDP5PKeMa6GuA7rAGOoObHScAaipCD OoCChN0RELmdpImunKAuXwl3P+texOL/gBu+0tQk27L56/xENp r89dtIsUo7eoflbuduoZg== Cc: FreeBSD current , Peter Grehan , Andriy Gapon , neel@freebsd.org Subject: Re: proposed smp_rendezvous change 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, 16 May 2011 21:38:57 -0000 On Monday 16 May 2011 16:46:03 John Baldwin wrote: > On Monday, May 16, 2011 4:30:44 pm Max Laier wrote: > > On Monday 16 May 2011 14:21:27 John Baldwin wrote: > > > Yes, we need to fix that. Humm, it doesn't preempt when you do a > > > critical_exit() though? Or do you use a hand-rolled critical exit that > > > doesn't do a deferred preemption? > > > > Right now I just did a manual td_critnest++/--, but I guess ... > > Ah, ok, so you would "lose" a preemption. That's not really ideal. > > > > Actually, I'm curious how the spin unlock inside the IPI could yield > > > the CPU. Oh, is rmlock doing a wakeup inside the IPI handler? I > > > guess that is ok as long as the critical_exit() just defers the > > > preemption to the end of the IPI handler. > > > > ... the earliest point where it is safe to preempt is after doing the > > > > atomic_add_int(&smp_rv_waiters[2], 1); > > > > so that we can start other IPIs again. However, since we don't accept > > new IPIs until we signal EOI in the MD code (on amd64), this might still > > not be a good place to do the yield?!? > > Hmm, yeah, you would want to do the EOI before you yield. However, we > could actually move the EOI up before calling the MI code so long as we > leave interrupts disabled for the duration of the handler (which we do). > > > The spin unlock boils down to a critical_exit() and unless we did a > > critical_enter() at some point during the redenvouz setup, we will > > yield() if we owepreempt. I'm not quite sure how that can happen, but > > it seems like there is a path that allows the scheduler to set it from a > > foreign CPU. > > No, it is only set on curthread by curthread. This is actually my main > question. I've no idea how this could happen unless the rmlock code is > actually triggering a wakeup or sched_add() in its rendezvous handler. > > I don't see anything in rm_cleanIPI() that would do that however. > > I wonder if your original issue was really fixed just by the first patch > you had which fixed the race in smp_rendezvous()? I found the stack that lead me to this patch in the first place: #0 sched_switch (td=0xffffff011a970000, newtd=0xffffff006e6784b0, flags=4) at src/sys/kern/sched_ule.c:1939 #1 0xffffffff80285c7f in mi_switch (flags=6, newtd=0x0) at src/sys/kern/kern_synch.c:475 #2 0xffffffff802a2cb3 in critical_exit () at src/sys/kern/kern_switch.c:185 #3 0xffffffff80465807 in spinlock_exit () at src/sys/amd64/amd64/machdep.c:1458 #4 0xffffffff8027adea in rm_cleanIPI (arg=) at src/sys/kern/kern_rmlock.c:180 #5 0xffffffff802b9887 in smp_rendezvous_action () at src/sys/kern/subr_smp.c:402 #6 0xffffffff8045e2a4 in Xrendezvous () at src/sys/amd64/amd64/apic_vector.S:235 #7 0xffffffff802a2c6e in critical_exit () at src/sys/kern/kern_switch.c:179 #8 0xffffffff804365ba in uma_zfree_arg (zone=0xffffff009ff4b5a0, item=0xffffff000f34cd40, udata=0xffffff000f34ce08) at src/sys/vm/uma_core.c:2370 . . . and now that I look at it again, it is clear that critical_exit() just isn't interrupt safe. I'm not sure how to fix that, yet ... but this: if (td->td_critnest == 1) { td->td_critnest = 0; if (td->td_owepreempt) { td->td_critnest = 1; clearly doesn't work. Max From owner-freebsd-current@FreeBSD.ORG Mon May 16 22:05:55 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 55258106566C; Mon, 16 May 2011 22:05:55 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.10]) by mx1.freebsd.org (Postfix) with ESMTP id E6BC88FC14; Mon, 16 May 2011 22:05:54 +0000 (UTC) Received: from maxlap.localnet (gw-100.extranet.sea01.isilon.com [74.85.160.100]) by mrelayeu.kundenserver.de (node=mrbap1) with ESMTP (Nemesis) id 0MN728-1QJrwG2q9g-007Joq; Tue, 17 May 2011 00:05:53 +0200 From: Max Laier To: Attilio Rao Date: Mon, 16 May 2011 18:05:50 -0400 User-Agent: KMail/1.13.6 (FreeBSD/9.0-CURRENT; KDE/4.6.1; amd64; ; ) References: <4DCD357D.6000109@FreeBSD.org> <201105161738.53366.max@love2party.net> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201105161805.51188.max@love2party.net> X-Provags-ID: V02:K0:J1eHK2hscrXA73KTICIFY/Ps0IbGJK51Y/Byo2xpKRr mlq+/ZfDyVf4iPcBt+XI+q4raXjt8WwMbNQazbd/Ou+gQ4Th3V 59Xf+wPTpz6SLJyu6jr3cwy+qZIbC3atvEcSAvE2Rzt1c4/H83 w0yEFqsWe216F8Mqh3Y6wyPDG2jhcIuLQvVH3qELqV/jZQrV/A OWvfHEYdOG36iE+925Fog== Cc: Andriy Gapon , FreeBSD current , Peter Grehan , neel@freebsd.org Subject: Re: proposed smp_rendezvous change 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, 16 May 2011 22:05:55 -0000 On Monday 16 May 2011 17:54:54 Attilio Rao wrote: > 2011/5/16 Max Laier : > > On Monday 16 May 2011 16:46:03 John Baldwin wrote: > >> On Monday, May 16, 2011 4:30:44 pm Max Laier wrote: > >> > On Monday 16 May 2011 14:21:27 John Baldwin wrote: > >> > > Yes, we need to fix that. Humm, it doesn't preempt when you do a > >> > > critical_exit() though? Or do you use a hand-rolled critical exit > >> > > that doesn't do a deferred preemption? > >> > > >> > Right now I just did a manual td_critnest++/--, but I guess ... > >> > >> Ah, ok, so you would "lose" a preemption. That's not really ideal. > >> > >> > > Actually, I'm curious how the spin unlock inside the IPI could yield > >> > > the CPU. Oh, is rmlock doing a wakeup inside the IPI handler? I > >> > > guess that is ok as long as the critical_exit() just defers the > >> > > preemption to the end of the IPI handler. > >> > > >> > ... the earliest point where it is safe to preempt is after doing the > >> > > >> > atomic_add_int(&smp_rv_waiters[2], 1); > >> > > >> > so that we can start other IPIs again. However, since we don't accept > >> > new IPIs until we signal EOI in the MD code (on amd64), this might > >> > still not be a good place to do the yield?!? > >> > >> Hmm, yeah, you would want to do the EOI before you yield. However, we > >> could actually move the EOI up before calling the MI code so long as we > >> leave interrupts disabled for the duration of the handler (which we do). > >> > >> > The spin unlock boils down to a critical_exit() and unless we did a > >> > critical_enter() at some point during the redenvouz setup, we will > >> > yield() if we owepreempt. I'm not quite sure how that can happen, but > >> > it seems like there is a path that allows the scheduler to set it from > >> > a foreign CPU. > >> > >> No, it is only set on curthread by curthread. This is actually my main > >> question. I've no idea how this could happen unless the rmlock code is > >> actually triggering a wakeup or sched_add() in its rendezvous handler. > >> > >> I don't see anything in rm_cleanIPI() that would do that however. > >> > >> I wonder if your original issue was really fixed just by the first > >> patch you had which fixed the race in smp_rendezvous()? > > > > I found the stack that lead me to this patch in the first place: > > > > #0 sched_switch (td=0xffffff011a970000, newtd=0xffffff006e6784b0, > > flags=4) at src/sys/kern/sched_ule.c:1939 > > #1 0xffffffff80285c7f in mi_switch (flags=6, newtd=0x0) at > > src/sys/kern/kern_synch.c:475 > > #2 0xffffffff802a2cb3 in critical_exit () at > > src/sys/kern/kern_switch.c:185 #3 0xffffffff80465807 in spinlock_exit > > () at > > src/sys/amd64/amd64/machdep.c:1458 > > #4 0xffffffff8027adea in rm_cleanIPI (arg=) at > > src/sys/kern/kern_rmlock.c:180 > > #5 0xffffffff802b9887 in smp_rendezvous_action () at > > src/sys/kern/subr_smp.c:402 > > #6 0xffffffff8045e2a4 in Xrendezvous () at > > src/sys/amd64/amd64/apic_vector.S:235 > > #7 0xffffffff802a2c6e in critical_exit () at > > src/sys/kern/kern_switch.c:179 #8 0xffffffff804365ba in uma_zfree_arg > > (zone=0xffffff009ff4b5a0, item=0xffffff000f34cd40, > > udata=0xffffff000f34ce08) at > > src/sys/vm/uma_core.c:2370 > > . > > . > > . > > > > and now that I look at it again, it is clear that critical_exit() just > > isn't interrupt safe. I'm not sure how to fix that, yet ... but this: > > > > > > if (td->td_critnest == 1) { > > td->td_critnest = 0; > > if (td->td_owepreempt) { > > td->td_critnest = 1; > > > > clearly doesn't work. > > I'm sorry if I didn't reply to the whole rendezvous thread, but as > long as there is so many people taking care of it, I'll stay hidden in > my corner. > > I just wanted to tell that I think you are misunderstanding what > critical section is supposed to do. > > When an interrupt fires, it goes on the old "interrupt/kernel context" > which means it has not a context of his own. That is the reason why we > disable interrupts on spinlocks (or similar workaround for !x86 > architectures) and this is why spinlocks are the only protection > usable in code that runs in interrupt context. > > Preempting just means another thread will be scheduler in the middle > of another thread execution path. > > This code is perfectly fine if you consider curthread won't be > descheduled while it is executing. Well, no - it is not. With this you can end up with a curthread that has td_critnest=0 and td_owepreempt=1 in interrupt context. If you use a spinlock on such a thread, it will do the preemption at the point where you drop the spinlock, this is bad in some circumstances. One example is the smp_rendevous case we are discussing here. Max From owner-freebsd-current@FreeBSD.ORG Mon May 16 22:09: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 606FC106566C for ; Mon, 16 May 2011 22:09:06 +0000 (UTC) (envelope-from deeptech71@gmail.com) Received: from mail-px0-f176.google.com (mail-px0-f176.google.com [209.85.212.176]) by mx1.freebsd.org (Postfix) with ESMTP id 3699B8FC0A for ; Mon, 16 May 2011 22:09:05 +0000 (UTC) Received: by pxi11 with SMTP id 11so4212609pxi.7 for ; Mon, 16 May 2011 15:09:05 -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:content-type; bh=m75kClqZUbIrM/luIy46tfxxmGnYBwpYamENN4dq+fs=; b=RhhB/JmUKO3zhYOZxdroucgjk3cbaes32qYuST3ZXl6ew1KyBMZ8rBlWRf9L8aZLuA uET4U1i4KFuJISisLSzY5VhPSCWWClB5v7jbqv7JZeUOkoAEFuyKwZDMZ6h/WzhY2aqL AX1PMGO0hcJ0SqgTQS+rdJVtgOUm2dbEHNcCQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=EZpZSB84jb2bEnJCmoAj28teZTkoOCOn57y8i0BDHHQ9n0OXr7iS4wuI+QLWerxwhX S2pgN+g/HYOm/JxMTppSGlpAornnWziUNP2niuatBLnmkrL3aIS6hzKj7d7jDMgcECkA tLOaedhCjH3J//ZF6qCIYfsrOAFaW6Fw2+drQ= MIME-Version: 1.0 Received: by 10.68.1.35 with SMTP id 3mr8432579pbj.7.1305583745589; Mon, 16 May 2011 15:09:05 -0700 (PDT) Received: by 10.68.71.130 with HTTP; Mon, 16 May 2011 15:09:05 -0700 (PDT) In-Reply-To: References: Date: Tue, 17 May 2011 00:09:05 +0200 Message-ID: From: "deeptech71@gmail.com" To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: pcib allocation failure 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, 16 May 2011 22:09:06 -0000 ========== good kernel configuration begins ========== cpu I686_CPU ident HQ #makeoptions DEBUG=-g # Build kernel with gdb(1) debug symbols options SCHED_ULE # ULE scheduler options PREEMPTION # Enable kernel thread preemption options INET # InterNETworking options INET6 # IPv6 communications protocols options SCTP # Stream Control Transmission Protocol options FFS # Berkeley Fast Filesystem options SOFTUPDATES # Enable FFS soft updates support options UFS_ACL # Support for access control lists options UFS_DIRHASH # Improve performance on big directories options MD_ROOT # MD is a potential root device options NFSCL # New Network Filesystem Client options NFSD # New Network Filesystem Server options NFSLOCKD # Network Lock Manager options NFS_ROOT # NFS usable as /, requires NFSCLIENT options MSDOSFS # MSDOS Filesystem options CD9660 # ISO 9660 Filesystem options GEOM_LABEL # Provides labelization options COMPAT_FREEBSD4 # Compatible with FreeBSD4 options COMPAT_FREEBSD5 # Compatible with FreeBSD5 options COMPAT_FREEBSD6 # Compatible with FreeBSD6 options COMPAT_FREEBSD7 # Compatible with FreeBSD7 options SCSI_DELAY=1000 # Delay (in ms) before probing SCSI options SYSVSHM # SYSV-style shared memory options SYSVMSG # SYSV-style message queues options SYSVSEM # SYSV-style semaphores options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time extensions options PRINTF_BUFR_SIZE=128 # Prevent printf output being interspersed. options KBD_INSTALL_CDEV # install a CDEV entry in /dev options MAC # TrustedBSD MAC Framework # To make an SMP kernel, the next two lines are needed options SMP # Symmetric MultiProcessor Kernel device apic # I/O APIC # CPU frequency control device cpufreq # Bus support. device acpi device pci nooptions NEW_PCIB # h4x ! # ATA controllers device ata # Legacy ATA/SATA controllers options ATA_CAM # Handle legacy controllers with CAM options ATA_STATIC_ID # Static device numbering # ATA/SCSI peripherals device scbus # SCSI bus (required for ATA/SCSI) device ch # SCSI media changers device da # Direct Access (disks) device sa # Sequential Access (tape etc) device cd # CD device pass # Passthrough device (direct ATA/SCSI access) device ses # SCSI Environmental Services (and SAF-TE) # atkbdc0 controls both the keyboard and the PS/2 mouse device atkbdc # AT keyboard controller device atkbd # AT keyboard device psm # PS/2 mouse device kbdmux # keyboard multiplexer device vga # VGA video card driver # syscons is the default console driver, resembling an SCO console device sc device agp # support several AGP chipsets # Power management support (see NOTES for more options) #device apm # Add suspend/resume support for the i8254. device pmtimer # PCI Ethernet NICs that use the common MII bus controller code. # NOTE: Be sure to keep the 'device miibus' line in order to use these NICs! device miibus # MII bus support device sk # SysKonnect SK-984x & SK-982x gigabit Ethernet # Pseudo devices. device loop # Network loopback device random # Entropy device device ether # Ethernet support device tun # Packet tunnel. device pty # BSD-style compatibility pseudo ttys device md # Memory "disks" device gif # IPv6 and IPv4 tunneling device faith # IPv6-to-IPv4 relaying (translation) device firmware # firmware assist module # The `bpf' device enables the Berkeley Packet Filter. # Be aware of the administrative consequences of enabling this! # Note that 'bpf' is required for DHCP. device bpf # Berkeley packet filter # USB support options USB_DEBUG # enable debug msgs device uhci # UHCI PCI->USB interface device ohci # OHCI PCI->USB interface device ehci # EHCI PCI->USB interface (USB 2.0) device usb # USB Bus (required) #device udbp # USB Double Bulk Pipe devices (needs netgraph) device uhid # "Human Interface Devices" device ukbd # Keyboard device ulpt # Printer device umass # Disks/Mass storage - Requires scbus and da device ums # Mouse device drm device radeondrm device sound device snd_es137x ========== good kernel configuration ends ========== the only difference between the good and the bad kernel configuration, is that the bad kernel configuration configuration does not contain ``nooptions NEW_PCIB''. ========== ``devinfo -rv'' for the bad kernel configuration begins ========== nexus0 npx0 apic0 ram0 I/O memory addresses: 0x0-0x9fbff 0x100000-0x1ff2ffff acpi0 Interrupt request lines: 9 I/O ports: 0x10-0x1f 0x22-0x3f 0x44-0x5f 0x62-0x63 0x65-0x6f 0x72-0x7f 0x80 0x84-0x86 0x88 0x8c-0x8e 0x90-0x9f 0xa2-0xbf 0xe0-0xef 0x290-0x297 0x480-0x4bf 0x4d0-0x4d1 0x680-0x6ff 0x800-0x87f I/O memory addresses: 0xc0000-0xdffff 0xe0000-0xfffff 0xfec00000-0xfec00fff 0xfed20000-0xfed8ffff 0xfee00000-0xfee00fff 0xffb00000-0xffbfffff 0xfff00000-0xffffffff cpu0 pnpinfo _HID=none _UID=0 at handle=\_PR_.CPU1 p4tcc0 cpufreq0 cpu1 pnpinfo _HID=none _UID=0 at handle=\_PR_.CPU2 p4tcc1 cpufreq1 pcib0 pnpinfo _HID=PNP0A03 _UID=0 at handle=\_SB_.PCI0 I/O ports: 0xcf8-0xcff pci0 hostb0 pnpinfo vendor=0x8086 device=0x2570 subvendor=0x1043 subdevice=0x80f2 class=0x060000 at slot=0 function=0 I/O memory addresses: 0xf0000000-0xf7ffffff agp0 pcib1 pnpinfo vendor=0x8086 device=0x2571 subvendor=0x0000 subdevice=0x0000 class=0x060400 at slot=1 function=0 handle=\_SB_.PCI0.P0P1 I/O ports: 0xd000-0xdfff I/O memory addresses: 0xd0000000-0xdfffffff 0xfbe00000-0xfbefffff pci1 vgapci0 pnpinfo vendor=0x1002 device=0x4150 subvendor=0x17ee subdevice=0x2002 class=0x030000 at slot=0 function=0 Interrupt request lines: 16 pcib1 I/O port window: 0xd000-0xd0ff pcib1 memory window: 0xfbee0000-0xfbeeffff pcib1 prefetch window: 0xd0000000-0xdfffffff vgapm0 drm0 vgapci1 pnpinfo vendor=0x1002 device=0x4170 subvendor=0x17ee subdevice=0x2003 class=0x038000 at slot=0 function=1 pcib1 memory window: 0xfbef0000-0xfbefffff drm1 uhci0 pnpinfo vendor=0x8086 device=0x24d2 subvendor=0x1043 subdevice=0x80a6 class=0x0c0300 at slot=29 function=0 handle=\_SB_.PCI0.USB1 Interrupt request lines: 16 I/O ports: 0xc880-0xc89f usbus0 uhub0 uhci1 pnpinfo vendor=0x8086 device=0x24d4 subvendor=0x1043 subdevice=0x80a6 class=0x0c0300 at slot=29 function=1 handle=\_SB_.PCI0.USB2 Interrupt request lines: 19 I/O ports: 0xcc00-0xcc1f usbus1 uhub1 ums0 pnpinfo vendor=0x04fc product=0x0801 devclass=0x00 devsubclass=0x00 sernum="" release=0x1611 intclass=0x03 intsubclass=0x01 at bus=1 hubaddr=2 port=1 devaddr=2 interface=0 ehci0 pnpinfo vendor=0x8086 device=0x24dd subvendor=0x1043 subdevice=0x80a6 class=0x0c0320 at slot=29 function=7 handle=\_SB_.PCI0.EUSB Interrupt request lines: 23 I/O memory addresses: 0xfbdffc00-0xfbdfffff usbus2 uhub2 pcib2 pnpinfo vendor=0x8086 device=0x244e subvendor=0x0000 subdevice=0x0000 class=0x060400 at slot=30 function=0 handle=\_SB_.PCI0.P0P4 I/O ports: 0xe000-0xefff I/O memory addresses: 0xfbf00000-0xfbffffff pci2 skc0 pnpinfo vendor=0x10b7 device=0x1700 subvendor=0x1043 subdevice=0x80eb class=0x020000 at slot=5 function=0 Interrupt request lines: 22 pcib2 I/O port window: 0xe800-0xe8ff pcib2 memory window: 0xfbffc000-0xfbffffff sk0 miibus0 e1000phy0 pnpinfo oui=0xac2 model=0x2 rev=0x3 at phyno=0 pcm0 pnpinfo vendor=0x1274 device=0x5880 subvendor=0x1274 subdevice=0x8001 class=0x040100 at slot=12 function=0 Interrupt request lines: 20 pcib2 I/O port window: 0xec00-0xec3f isab0 pnpinfo vendor=0x8086 device=0x24d0 subvendor=0x0000 subdevice=0x0000 class=0x060100 at slot=31 function=0 handle=\_SB_.PCI0.SBRG isa0 pmtimer0 sc0 vga0 I/O ports: 0x3c0-0x3df I/O memory addresses: 0xa0000-0xbffff orm0 pnpinfo pnpid=ORM0000 ACPI I/O memory addresses: 0xc0000-0xccfff fdc0 ppc0 uart0 uart1 atapci0 pnpinfo vendor=0x8086 device=0x24db subvendor=0x1043 subdevice=0x80a6 class=0x01018a at slot=31 function=1 handle=\_SB_.PCI0.IDE0 I/O ports: 0x170-0x177 0x1f0-0x1f7 0x376 0x3f6 0xfc00-0xfc0f ata0 at channel=0 Interrupt request lines: 14 ata1 at channel=1 Interrupt request lines: 15 unknown pnpinfo vendor=0x8086 device=0x24d3 subvendor=0x1043 subdevice=0x80a6 class=0x0c0500 at slot=31 function=3 I/O ports: 0x400-0x41f unknown pnpinfo _HID=none _UID=0 at handle=\_SB_.PCI0.IDE0.CHN0 unknown pnpinfo _HID=none _UID=0 at handle=\_SB_.PCI0.IDE0.CHN0.DRV0 unknown pnpinfo _HID=none _UID=0 at handle=\_SB_.PCI0.IDE0.CHN0.DRV1 unknown pnpinfo _HID=none _UID=0 at handle=\_SB_.PCI0.IDE0.CHN1 unknown pnpinfo _HID=none _UID=0 at handle=\_SB_.PCI0.IDE0.CHN1.DRV0 unknown pnpinfo _HID=none _UID=0 at handle=\_SB_.PCI0.IDE0.CHN1.DRV1 unknown pnpinfo _HID=none _UID=0 at handle=\_SB_.PCI0.IDE1 unknown pnpinfo _HID=none _UID=0 at handle=\_SB_.PCI0.MC97 unknown pnpinfo _HID=none _UID=0 at handle=\_SB_.PCI0.USB3 unknown pnpinfo _HID=none _UID=0 at handle=\_SB_.PCI0.USB4 atpic0 pnpinfo _HID=PNP0000 _UID=0 at handle=\_SB_.PCI0.SBRG.PIC_ I/O ports: 0x20-0x21 0xa0-0xa1 atdma0 pnpinfo _HID=PNP0200 _UID=0 at handle=\_SB_.PCI0.SBRG.DMAD DMA request lines: 4 I/O ports: 0x0-0xf 0x81-0x83 0x87 0x89-0x8b 0x8f 0xc0-0xdf attimer0 pnpinfo _HID=PNP0100 _UID=0 at handle=\_SB_.PCI0.SBRG.TMR_ Interrupt request lines: 0 I/O ports: 0x40-0x43 atrtc0 pnpinfo _HID=PNP0B00 _UID=0 at handle=\_SB_.PCI0.SBRG.RTC0 Interrupt request lines: 8 I/O ports: 0x70-0x71 atkbdc0 pnpinfo _HID=PNP0303 _UID=0 at handle=\_SB_.PCI0.SBRG.PS2K Interrupt request lines: 1 I/O ports: 0x60 0x64 atkbd0 psm0 psmcpnp0 pnpinfo _HID=PNP0F03 _UID=0 at handle=\_SB_.PCI0.SBRG.PS2M unknown pnpinfo _HID=PNP0800 _UID=0 at handle=\_SB_.PCI0.SBRG.SPKR I/O ports: 0x61 npxisa0 pnpinfo _HID=PNP0C04 _UID=0 at handle=\_SB_.PCI0.SBRG.COPR I/O ports: 0xf0-0xff unknown pnpinfo _HID=PNP0501 _UID=1 at handle=\_SB_.PCI0.SBRG.UAR1 I/O ports: 0x3f8-0x3ff unknown pnpinfo _HID=PNP0501 _UID=2 at handle=\_SB_.PCI0.SBRG.UAR2 I/O ports: 0x2f8-0x2ff unknown pnpinfo _HID=PNP0700 _UID=0 at handle=\_SB_.PCI0.SBRG.FDC_ unknown pnpinfo _HID=PNP0401 _UID=1 at handle=\_SB_.PCI0.SBRG.LPTE DMA request lines: 3 I/O ports: 0x378-0x37f 0x778-0x77b unknown pnpinfo _HID=PNPB02F _UID=0 at handle=\_SB_.PCI0.SBRG.GAME unknown pnpinfo _HID=PNPB006 _UID=0 at handle=\_SB_.PCI0.SBRG.MIDI acpi_sysresource0 pnpinfo _HID=PNP0C02 _UID=46 at handle=\_SB_.PCI0.SBRG.SIOR acpi_sysresource1 pnpinfo _HID=PNP0C02 _UID=16 at handle=\_SB_.PCI0.SBRG.RMSC unknown pnpinfo _HID=PNP0C02 _UID=1014 at handle=\_SB_.PCI0.SBRG.P3F6 acpi_sysresource2 pnpinfo _HID=PNP0C02 _UID=0 at handle=\_SB_.PCI0.SBRG.OMSC unknown pnpinfo _HID=none _UID=0 at handle=\_SB_.PCI0.P0P2 unknown pnpinfo _HID=none _UID=0 at handle=\_SB_.PCI0.P0P2.ILAN acpi_sysresource3 pnpinfo _HID=PNP0C01 _UID=1 at handle=\_SB_.RMEM acpi_button0 pnpinfo _HID=PNP0C0C _UID=170 at handle=\_SB_.PWRB pci_link0 pnpinfo _HID=PNP0C0F _UID=1 at handle=\_SB_.LNKA pci_link1 pnpinfo _HID=PNP0C0F _UID=2 at handle=\_SB_.LNKB pci_link2 pnpinfo _HID=PNP0C0F _UID=3 at handle=\_SB_.LNKC pci_link3 pnpinfo _HID=PNP0C0F _UID=4 at handle=\_SB_.LNKD pci_link4 pnpinfo _HID=PNP0C0F _UID=5 at handle=\_SB_.LNKE pci_link5 pnpinfo _HID=PNP0C0F _UID=6 at handle=\_SB_.LNKF pci_link6 pnpinfo _HID=PNP0C0F _UID=7 at handle=\_SB_.LNKG pci_link7 pnpinfo _HID=PNP0C0F _UID=8 at handle=\_SB_.LNKH acpi_timer0 pnpinfo unknown at unknown ACPI I/O ports: 0x808-0x80b ========== ``devinfo -rv'' for the bad kernel configuration ends ========== ========== ``devinfo -u'' for the bad kernel configuration begins ========== Interrupt request lines: 0 (attimer0) 1 (atkbdc0) 3-7 (root0) 8 (atrtc0) 9 (acpi0) 10-13 (root0) 14 (ata0) 15 (ata1) 16 (uhci0) 16 (vgapci0) 17-18 (root0) 19 (uhci1) 20 (pcm0) 21 (root0) 22 (skc0) 23 (ehci0) DMA request lines: 0-2 (root0) 3 ---- 4 (atdma0) 5-7 (root0) I/O ports: 0x0-0xf (atdma0) 0x10-0x1f (acpi0) 0x20-0x21 (atpic0) 0x22-0x3f (acpi0) 0x40-0x43 (attimer0) 0x44-0x5f (acpi0) 0x60 (atkbdc0) 0x61 ---- 0x62-0x63 (acpi0) 0x64 (atkbdc0) 0x65-0x6f (acpi0) 0x70-0x71 (atrtc0) 0x72-0x7f (acpi0) 0x80 (acpi0) 0x81-0x83 (atdma0) 0x84-0x86 (acpi0) 0x87 (atdma0) 0x88 (acpi0) 0x89-0x8b (atdma0) 0x8c-0x8e (acpi0) 0x8f (atdma0) 0x90-0x9f (acpi0) 0xa0-0xa1 (atpic0) 0xa2-0xbf (acpi0) 0xc0-0xdf (atdma0) 0xe0-0xef (acpi0) 0xf0-0xff (npxisa0) 0x100-0x16f (root0) 0x170-0x177 (atapci0) 0x178-0x1ef (root0) 0x1f0-0x1f7 (atapci0) 0x1f8-0x28f (root0) 0x290-0x297 (acpi0) 0x298-0x2f7 (root0) 0x2f8-0x2ff ---- 0x300-0x375 (root0) 0x376 (atapci0) 0x377 (root0) 0x378-0x37f ---- 0x380-0x3bf (root0) 0x3c0-0x3df (vga0) 0x3e0-0x3f5 (root0) 0x3f6 (atapci0) 0x3f7 (root0) 0x3f8-0x3ff ---- 0x400-0x41f ---- 0x420-0x47f (root0) 0x480-0x4bf (acpi0) 0x4c0-0x4cf (root0) 0x4d0-0x4d1 (acpi0) 0x4d2-0x67f (root0) 0x680-0x6ff (acpi0) 0x700-0x777 (root0) 0x778-0x77b ---- 0x77c-0x7ff (root0) 0x800-0x87f (acpi0) 0x880-0xcf7 (root0) 0xcf8-0xcff (pcib0) 0xd00-0xc87f (root0) 0xc880-0xc89f (uhci0) 0xc8a0-0xcbff (root0) 0xcc00-0xcc1f (uhci1) 0xcc20-0xcfff (root0) 0xd000-0xdfff (pcib1) 0xe000-0xefff (pcib2) 0xf000-0xfbff (root0) 0xfc00-0xfc0f (atapci0) 0xfc10-0xffff (root0) I/O memory addresses: 0x0-0x9fbff (ram0) 0x9fc00-0x9ffff (root0) 0xa0000-0xbffff (vga0) 0xc0000-0xdffff (acpi0) 0xe0000-0xfffff (acpi0) 0x100000-0x1ff2ffff (ram0) 0x1ff30000-0xcfffffff (root0) 0xd0000000-0xdfffffff (pcib1) 0xe0000000-0xefffffff (root0) 0xf0000000-0xf7ffffff (hostb0) 0xf8000000-0xfbdffbff (root0) 0xfbdffc00-0xfbdfffff (ehci0) 0xfbe00000-0xfbefffff (pcib1) 0xfbf00000-0xfbffffff (pcib2) 0xfc000000-0xfebfffff (root0) 0xfec00000-0xfec00fff (acpi0) 0xfec01000-0xfed1ffff (root0) 0xfed20000-0xfed8ffff (acpi0) 0xfed90000-0xfedfffff (root0) 0xfee00000-0xfee00fff (acpi0) 0xfee01000-0xffafffff (root0) 0xffb00000-0xffbfffff (acpi0) 0xffc00000-0xffefffff (root0) 0xfff00000-0xffffffff (acpi0) ACPI I/O ports: 0x10-0x1f (root0) 0x22-0x3f (root0) 0x44-0x5f (root0) 0x62-0x63 (root0) 0x65-0x6f (root0) 0x72-0x80 (root0) 0x84-0x86 (root0) 0x88 (root0) 0x8c-0x8e (root0) 0x90-0x9f (root0) 0xa2-0xbf (root0) 0xe0-0xef (root0) 0x290-0x297 (root0) 0x480-0x4bf (root0) 0x4d0-0x4d1 (root0) 0x680-0x6ff (root0) 0x800-0x807 (root0) 0x808-0x80b (acpi_timer0) 0x80c-0x87f (root0) ACPI I/O memory addresses: 0xc0000-0xccfff (orm0) 0xcd000-0xfffff (root0) 0xfec00000-0xfec00fff (root0) 0xfed20000-0xfed8ffff (root0) 0xfee00000-0xfee00fff (root0) 0xffb00000-0xffbfffff (root0) 0xfff00000-0xffffffff (root0) pcib1 I/O port window: 0xd000-0xd0ff (vgapci0) 0xd100-0xdfff (root0) pcib1 memory window: 0xfbe00000-0xfbedffff (root0) 0xfbee0000-0xfbeeffff (vgapci0) 0xfbef0000-0xfbefffff (vgapci1) pcib1 prefetch window: 0xd0000000-0xdfffffff (vgapci0) pcib2 I/O port window: 0xe000-0xe7ff (root0) 0xe800-0xe8ff (skc0) 0xe900-0xebff (root0) 0xec00-0xec3f (pcm0) 0xec40-0xefff (root0) pcib2 memory window: 0xfbf00000-0xfbffbfff (root0) 0xfbffc000-0xfbffffff (skc0) pcib2 prefetch window: ========== ``devinfo -u'' for the bad kernel configuration ends ========== ========== ``dmesg'' for the bad kernel configuration begins ========== MP Configuration Table version 1.1 found at 0xc00f1280 Table 'FACP' at 0x1ff30290 Table 'APIC' at 0x1ff30390 APIC: Found table at 0x1ff30390 APIC: Using the MADT enumerator. MADT: Found CPU APIC ID 0 ACPI ID 1: enabled SMP: Added CPU 0 (AP) MADT: Found CPU APIC ID 1 ACPI ID 2: enabled SMP: Added CPU 1 (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. FreeBSD 9.0-CURRENT #1 r221970M: Mon May 16 13:38:16 CEST 2011 devhc@:/usr/obj/usr/src/sys/HQ i386 Table 'FACP' at 0x1ff30290 Table 'APIC' at 0x1ff30390 Table 'OEMB' at 0x1ff40040 ACPI: No SRAT table found Preloaded elf kernel "/boot/kernel.HQ.r221970.copyin2.opie.newpcib/kernel" at 0xc0b9c000. Calibrating TSC clock ... TSC clock: 2798716096 Hz CPU: Intel(R) Pentium(R) 4 CPU 2.80GHz (2798.72-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf29 Family = f Model = 2 Stepping = 9 Features=0xbfebfbff Features2=0x4400 Instruction TLB: 4 KB, 2 MB or 4 MB pages, fully associative, 64 entries Data TLB: 4 KB or 4 MB pages, fully associative, 64 entries 1st-level data cache: 8 KB, 4-way set associative, sectored cache, 64 byte line size Trace cache: 12K-uops, 8-way set associative 2nd-level cache: 512 KB, 8-way set associative, sectored cache, 64 byte line size real memory = 536870912 (512 MB) Physical memory chunk(s): 0x0000000000001000 - 0x000000000009efff, 647168 bytes (158 pages) 0x0000000000100000 - 0x00000000003fffff, 3145728 bytes (768 pages) 0x0000000000c26000 - 0x000000001f5ecfff, 513568768 bytes (125383 pages) avail memory = 513884160 (490 MB) Event timer "LAPIC" quality 400 ACPI APIC Table: INTR: Adding local APIC 1 as a target FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 2 package(s) x 1 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 bios32: Found BIOS32 Service Directory header at 0xc00f0000 bios32: Entry = 0xf0010 (c00f0010) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xf0000+0x31 pnpbios: Found PnP BIOS data at 0xc00f5020 pnpbios: Entry = f0000:5c0a Rev = 1.0 Other BIOS signatures found: APIC: CPU 0 has ACPI ID 1 APIC: CPU 1 has ACPI ID 2 ULE: setup cpu 0 ULE: setup cpu 1 ACPI: RSDP 0xf9e30 00021 (v02 ACPIAM) ACPI: XSDT 0x1ff30100 0003C (v01 A M I OEMXSDT 10000414 MSFT 00000097) ACPI: FACP 0x1ff30290 000F4 (v03 A M I OEMFACP 10000414 MSFT 00000097) ACPI: DSDT 0x1ff303f0 0382D (v01 P4P81 P4P81104 00000104 INTL 02002026) ACPI: FACS 0x1ff40000 00040 ACPI: APIC 0x1ff30390 0005C (v01 A M I OEMAPIC 10000414 MSFT 00000097) ACPI: OEMB 0x1ff40040 0003F (v01 A M I OEMBIOS 10000414 MSFT 00000097) MADT: Found IO APIC ID 2, Interrupt 0 at 0xfec00000 ioapic0: Routing external 8259A's -> intpin 0 MADT: Interrupt override: source 0, irq 2 ioapic0: Routing IRQ 0 -> intpin 2 MADT: Interrupt override: source 9, irq 9 ioapic0: intpin 9 trigger: level ioapic0 irqs 0-23 on motherboard cpu0 BSP: ID: 0x00000000 VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000100ef therm: 0x00010000 err: 0x000000f0 pmc: 0x00010400 snd_unit_init() u=0x00ff8000 [512] d=0x00007c00 [32] c=0x000003ff [1024] feeder_register: snd_unit=-1 snd_maxautovchans=16 latency=5 feeder_rate_min=1 feeder_rate_max=2016000 feeder_rate_round=25 null: nfslock: pseudo-device random: io: kbd: new array size 4 kbd1 at kbdmux0 mem: Pentium Pro MTRR support enabled acpi0: on motherboard ioapic0: routing intpin 9 (ISA IRQ 9) to lapic 0 vector 48 ACPI: Executed 1 blocks of module-level executable AML code acpi0: Power Button (fixed) acpi0: wakeup code va 0xc2694000 pa 0x1000 pci_open(1): mode 1 addr port (0x0cf8) is 0x80000090 pci_open(1a): mode1res=0x80000000 (0x80000000) pci_cfgcheck: device 0 [class=060000] [hdr=00] is there (id=25708086) pcibios: BIOS version 2.10 acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, 1fef0000 (3) failed ACPI timer: 1/0 1/0 1/0 1/0 1/0 1/0 1/0 1/0 1/0 1/0 -> 10 Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 cpu0: on acpi0 cpu0: switching to generic Cx mode cpu1: on acpi0 pci_link0: Index IRQ Rtd Ref IRQs Initial Probe 0 10 N 0 3 4 5 6 7 10 11 12 14 15 Validation 0 10 N 0 3 4 5 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 10 11 12 14 15 pci_link1: Index IRQ Rtd Ref IRQs Initial Probe 0 10 N 0 3 4 5 6 7 10 11 12 14 15 Validation 0 10 N 0 3 4 5 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 10 11 12 14 15 pci_link2: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 4 5 6 7 10 11 12 14 15 Validation 0 255 N 0 3 4 5 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 10 11 12 14 15 pci_link3: Index IRQ Rtd Ref IRQs Initial Probe 0 5 N 0 3 4 5 6 7 10 11 12 14 15 Validation 0 5 N 0 3 4 5 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 10 11 12 14 15 pci_link4: Index IRQ Rtd Ref IRQs Initial Probe 0 5 N 0 3 4 5 6 7 10 11 12 14 15 Validation 0 5 N 0 3 4 5 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 10 11 12 14 15 pci_link5: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 4 5 6 7 10 11 12 14 15 Validation 0 255 N 0 3 4 5 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 10 11 12 14 15 pci_link6: Index IRQ Rtd Ref IRQs Initial Probe 0 10 N 0 3 4 5 6 7 10 11 12 14 15 Validation 0 10 N 0 3 4 5 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 10 11 12 14 15 pci_link7: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 3 4 5 6 7 10 11 12 14 15 Validation 0 11 N 0 3 4 5 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 10 11 12 14 15 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pci0: domain=0, physical bus=0 found-> vendor=0x8086, dev=0x2570, revid=0x02 domain=0, bus=0, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x2090, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) map[10]: type Prefetchable Memory, range 32, base 0xf0000000, size 27, enabled found-> vendor=0x8086, dev=0x2571, revid=0x02 domain=0, bus=0, slot=1, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0107, statreg=0x00a0, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x08 (2000 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x24d2, revid=0x02 domain=0, bus=0, slot=29, func=0 class=0c-03-00, hdrtype=0x00, mfdev=1 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 map[20]: type I/O Port, range 32, base 0xc880, size 5, enabled pcib0: matched entry for 0.29.INTA pcib0: slot 29 INTA hardwired to IRQ 16 found-> vendor=0x8086, dev=0x24d4, revid=0x02 domain=0, bus=0, slot=29, func=1 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=5 map[20]: type I/O Port, range 32, base 0xcc00, size 5, enabled pcib0: matched entry for 0.29.INTB pcib0: slot 29 INTB hardwired to IRQ 19 found-> vendor=0x8086, dev=0x24dd, revid=0x02 domain=0, bus=0, slot=29, func=7 class=0c-03-20, hdrtype=0x00, mfdev=0 cmdreg=0x0106, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=d, irq=11 powerspec 2 supports D0 D3 current D0 map[10]: type Memory, range 32, base 0xfbdffc00, size 10, enabled pcib0: matched entry for 0.29.INTD pcib0: slot 29 INTD hardwired to IRQ 23 found-> vendor=0x8086, dev=0x244e, revid=0xc2 domain=0, bus=0, slot=30, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0107, statreg=0x0080, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x06 (1500 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x24d0, revid=0x02 domain=0, bus=0, slot=31, func=0 class=06-01-00, hdrtype=0x00, mfdev=1 cmdreg=0x000f, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x24db, revid=0x02 domain=0, bus=0, slot=31, func=1 class=01-01-8a, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=255 map[20]: type I/O Port, range 32, base 0xfc00, size 4, enabled map[24]: type Memory, range 32, base 0, size 10, memory disabled found-> vendor=0x8086, dev=0x24d3, revid=0x02 domain=0, bus=0, slot=31, func=3 class=0c-05-00, hdrtype=0x00, mfdev=0 cmdreg=0x0001, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=10 map[20]: type I/O Port, range 32, base 0x400, size 5, enabled pcib0: matched entry for 0.31.INTB pcib0: slot 31 INTB hardwired to IRQ 17 agp0: on hostb0 agp0: allocating GATT for aperture of size 128M pcib1: at device 1.0 on pci0 pcib1: failed to allocate initial prefetch window: 0xd0000000-0xfaffffff pcib1: domain 0 pcib1: secondary bus 1 pcib1: subordinate bus 1 pcib1: I/O decode 0xd000-0xdfff pcib1: memory decode 0xfbe00000-0xfbefffff pcib1: no prefetched decode pcib1: could not get PCI interrupt routing table for \\_SB_.PCI0.P0P1 - AE_NOT_FOUND pci1: on pcib1 pci1: domain=0, physical bus=1 found-> vendor=0x1002, dev=0x4150, revid=0x00 domain=0, bus=1, slot=0, func=0 class=03-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0107, statreg=0x02b0, cachelnsz=4 (dwords) lattimer=0x40 (1920 ns), mingnt=0x08 (2000 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type Prefetchable Memory, range 32, base 0xd0000000, size 28, enabled pcib1: allocated initial prefetch window of 0xd0000000-0xdfffffff pcib1: allocated prefetch range (0xd0000000-0xdfffffff) for rid 10 of pci0:1:0:0 map[14]: type I/O Port, range 32, base 0xd000, size 8, enabled pcib1: allocated I/O port range (0xd000-0xd0ff) for rid 14 of pci0:1:0:0 map[18]: type Memory, range 32, base 0xfbee0000, size 16, enabled pcib1: allocated memory range (0xfbee0000-0xfbeeffff) for rid 18 of pci0:1:0:0 pcib0: matched entry for 0.1.INTA pcib0: slot 1 INTA hardwired to IRQ 16 pcib1: slot 0 INTA is routed to irq 16 found-> vendor=0x1002, dev=0x4170, revid=0x00 domain=0, bus=1, slot=0, func=1 class=03-80-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x02b0, cachelnsz=4 (dwords) lattimer=0x40 (1920 ns), mingnt=0x08 (2000 ns), maxlat=0x00 (0 ns) powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type Prefetchable Memory, range 32, base 0xe0000000, size 28, enabled pcib1: attempting to grow prefetch window for (0xe0000000-0xefffffff,0x10000000) pcib1: attempting to grow memory window for (0xe0000000-0xefffffff,0x10000000) map[14]: type Memory, range 32, base 0xfbef0000, size 16, enabled pcib1: allocated memory range (0xfbef0000-0xfbefffff) for rid 14 of pci0:1:0:1 vgapci0: port 0xd000-0xd0ff mem 0xd0000000-0xdfffffff,0xfbee0000-0xfbeeffff irq 16 at device 0.0 on pci1 drm0: on vgapci0 info: [drm] AGP at 0xf0000000 128MB info: [drm] Initialized radeon 1.31.0 20080613 vgapci1: mem 0xfbef0000-0xfbefffff at device 0.1 on pci1 uhci0: port 0xc880-0xc89f irq 16 at device 29.0 on pci0 ioapic0: routing intpin 16 (PCI IRQ 16) to lapic 0 vector 49 usbus0: on uhci0 usbus0: bpf attached uhci0: usbpf: Attached uhci1: port 0xcc00-0xcc1f irq 19 at device 29.1 on pci0 ioapic0: routing intpin 19 (PCI IRQ 19) to lapic 0 vector 50 usbus1: on uhci1 usbus1: bpf attached uhci1: usbpf: Attached ehci0: mem 0xfbdffc00-0xfbdfffff irq 23 at device 29.7 on pci0 ioapic0: routing intpin 23 (PCI IRQ 23) to lapic 0 vector 51 usbus2: EHCI version 1.0 usbus2: on ehci0 usbus2: bpf attached ehci0: usbpf: Attached pcib2: at device 30.0 on pci0 pcib2: domain 0 pcib2: secondary bus 2 pcib2: subordinate bus 2 pcib2: I/O decode 0xe000-0xefff pcib2: memory decode 0xfbf00000-0xfbffffff pcib2: no prefetched decode pcib2: Subtractively decoded bridge. pci2: on pcib2 pci2: domain=0, physical bus=2 found-> vendor=0x10b7, dev=0x1700, revid=0x12 domain=0, bus=2, slot=5, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0117, statreg=0x02b0, cachelnsz=4 (dwords) lattimer=0x40 (1920 ns), mingnt=0x17 (5750 ns), maxlat=0x1f (7750 ns) intpin=a, irq=10 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type Memory, range 32, base 0xfbffc000, size 14, enabled pcib2: allocated memory range (0xfbffc000-0xfbffffff) for rid 10 of pci0:2:5:0 map[14]: type I/O Port, range 32, base 0xe800, size 8, enabled pcib2: allocated I/O port range (0xe800-0xe8ff) for rid 14 of pci0:2:5:0 pcib2: matched entry for 2.5.INTA pcib2: slot 5 INTA hardwired to IRQ 22 found-> vendor=0x1274, dev=0x5880, revid=0x04 domain=0, bus=2, slot=12, func=0 class=04-01-00, hdrtype=0x00, mfdev=0 cmdreg=0x0105, statreg=0x0410, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x0c (3000 ns), maxlat=0x80 (32000 ns) intpin=a, irq=5 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type I/O Port, range 32, base 0xec00, size 6, enabled pcib2: allocated I/O port range (0xec00-0xec3f) for rid 10 of pci0:2:12:0 pcib2: matched entry for 2.12.INTA pcib2: slot 12 INTA hardwired to IRQ 20 skc0: <3Com 3C940 Gigabit Ethernet> port 0xe800-0xe8ff mem 0xfbffc000-0xfbffffff irq 22 at device 5.0 on pci2 skc0: interrupt moderation is 100 us skc0: 3Com Gigabit LOM (3C940) rev. (0x1) skc0: chip ver = 0xb0 skc0: chip rev = 0x01 skc0: SK_EPROM0 = 0x00 skc0: SRAM size = 0x020000 sk0: on skc0 sk0: bpf attached sk0: Ethernet address: 00:0e:a6:35:15:91 miibus0: on sk0 e1000phy0: PHY 0 on miibus0 e1000phy0: OUI 0x000ac2, model 0x0002, rev. 3 e1000phy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto ioapic0: routing intpin 22 (PCI IRQ 22) to lapic 0 vector 52 pcm0: port 0xec00-0xec3f irq 20 at device 12.0 on pci2 pcm0: pcm0: Codec features 18 bit DAC, 18 bit ADC, 5 bit master volume, no 3D Stereo Enhancement pcm0: Primary codec extended features surround DAC, AMAP pcm0: ac97 codec dac ready count: 0 pcm0: Mixer "vol": pcm0: Mixer "pcm": pcm0: Mixer "speaker": pcm0: Mixer "line": pcm0: Mixer "mic": pcm0: Mixer "cd": pcm0: Mixer "rec": pcm0: Mixer "igain": pcm0: Mixer "ogain": pcm0: Mixer "line1": pcm0: Mixer "phin": pcm0: Mixer "phout": pcm0: Mixer "video": ioapic0: routing intpin 20 (PCI IRQ 20) to lapic 0 vector 53 pcm0: clone manager: deadline=750ms flags=0x8000001e pcm0: sndbuf_setmap 169d000, 1000; 0xc2a9d000 -> 169d000 pcm0: sndbuf_setmap 169b000, 1000; 0xc2a9b000 -> 169b000 pcm0: sndbuf_setmap 1699000, 1000; 0xc2a99000 -> 1699000 pcm0: isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xfc00-0xfc0f at device 31.1 on pci0 ata0: on atapci0 ioapic0: routing intpin 14 (ISA IRQ 14) to lapic 0 vector 54 ata1: on atapci0 ioapic0: routing intpin 15 (ISA IRQ 15) to lapic 0 vector 55 pci0: at device 31.3 (no driver attached) acpi_button0: on acpi0 attimer0: port 0x40-0x43 irq 0 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 ioapic0: routing intpin 2 (ISA IRQ 0) to lapic 0 vector 56 Event timer "i8254" frequency 1193182 Hz quality 100 atrtc0: port 0x70-0x71 irq 8 on acpi0 atrtc0: registered as a time-of-day clock (resolution 1000000us, adjustment 0.500000000s) ioapic0: routing intpin 8 (ISA IRQ 8) to lapic 0 vector 57 Event timer "RTC" frequency 32768 Hz quality 0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 atkbd: the current kbd controller command byte 0065 atkbd: keyboard ID 0x41ab (2) kbd0 at atkbd0 kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x3d0000 ioapic0: routing intpin 1 (ISA IRQ 1) to lapic 0 vector 58 atkbd0: [GIANT-LOCKED] psm0: unable to allocate IRQ psmcpnp0: irq 12 on acpi0 psm0: current command byte:0065 psm0: failed to reset the aux device. pnp_identify: Trying Read_Port at 203 pnp_identify: Trying Read_Port at 243 pnp_identify: Trying Read_Port at 283 pnp_identify: Trying Read_Port at 2c3 pnp_identify: Trying Read_Port at 303 pnp_identify: Trying Read_Port at 343 pnp_identify: Trying Read_Port at 383 pnp_identify: Trying Read_Port at 3c3 PNP Identify complete isa_probe_children: disabling PnP devices pmtimer0 on isa0 ata: ata0 already exists; skipping it ata: ata1 already exists; skipping it atkbdc: atkbdc0 already exists; skipping it atrtc: atrtc0 already exists; skipping it attimer: attimer0 already exists; skipping it sc: sc0 already exists; skipping it isa_probe_children: probing non-PnP devices orm0: at iomem 0xc0000-0xccfff pnpid ORM0000 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sc0: fb0, kbd1, terminal emulator: scteken (teken terminal) vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 fdc0 failed to probe at port 0x3f0 irq 6 drq 2 on isa0 ppc0 failed to probe at irq 7 on isa0 uart0 failed to probe at port 0x3f8 irq 4 on isa0 uart1 failed to probe at port 0x2f8 irq 3 on isa0 isa_probe_children: probing PnP devices p4tcc0: on cpu0 p4tcc1: on cpu1 Device configuration finished. lapic: Divisor 2, Frequency 99952278 Hz Timecounters tick every 1.000 msec lo0: bpf attached usbus0: 12Mbps Full Speed USB v1.0 usbus1: 12Mbps Full Speed USB v1.0 usbus2: 480Mbps High Speed USB v2.0 ata0: reset tp1 mask=03 ostat0=50 ostat1=00 ata0: stat0=0x50 err=0x01 lsb=0x00 msb=0x00 ata0: stat1=0x00 err=0x01 lsb=0x00 msb=0x00 ata0: reset tp2 stat0=50 stat1=00 devices=0x1 (aprobe0:ata0:0:0:0): SIGNATURE: 0000 ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 ugen2.1: at usbus2 uhub2: on usbus2 ata1: reset tp1 mask=03 ostat0=50 ostat1=00 ata1: stat0=0x00 err=0x01 lsb=0x14 msb=0xeb ata1: stat1=0x00 err=0x00 lsb=0x00 msb=0x00 ata1: reset tp2 stat0=00 stat1=00 devices=0x10000 (aprobe0:ata1:0:0:0): SIGNATURE: eb14 ata1: DMA limited to UDMA33, controller found non-ATA66 cable ada0 at ata0 bus 0 scbus0 target 0 lun 0 ada0: ATA-7 device ada0: Serial Number Y2JPFJPE ada0: 100.000MB/s transfers (UDMA5, PIO 8192bytes) ada0: 78167MB (160086528 512 byte sectors: 16H 63S/T 16383C) ada0: Previously was known as ad0 GEOM: new disk ada0 pass0 at ata0 bus 0 scbus0 target 0 lun 0 pass0: ATA-7 device pass0: Serial Number Y2JPFJPE(cd0:ata1:0:0:0): SCSI status error (cd0:ata1:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 (cd0:ata1:0:0:0): CAM status: SCSI Status Error (cd0:ata1:0:0:0): SCSI status: Check Condition (cd0:ata1:0:0:0): SCSI sense: UNIT ATTENTION asc:29,0 (Power on, reset, or bus device reset occurred) (cd0:ata1:0:0:0): Retrying command (per sense data) pass0: 100.000MB/s transfers (UDMA5, PIO 8192bytes) pass1 at ata1 bus 0 scbus1 target 0 lun 0 pass1: Removable CD-ROM SCSI-0 device pass1: 33.300MB/s transfers (UDMA2, ATAPI 12bytes, PIO 65534bytes) (cd0:ata1:0:0:0): SCSI status error (cd0:ata1:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 (cd0:ata1:0:0:0): CAM status: SCSI Status Error (cd0:ata1:0:0:0): SCSI status: Check Condition (cd0:ata1:0:0:0): SCSI sense: NOT READY asc:3a,0 (Medium not present) (cd0:ata1:0:0:0): Error 6, Unretryable error cd0 at ata1 bus 0 scbus1 target 0 lun 0 cd0: Removable CD-ROM SCSI-0 device cd0: 33.300MB/s transfers (UDMA2, ATAPI 12bytes, PIO 65534bytes) cd0: Attempt to query device size failed: NOT READY, Medium not present SMP: AP CPU #1 Launched! cpu1 AP: ID: 0x01000000 VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000100ef therm: 0x00010000 err: 0x000000f0 pmc: 0x00010400 ioapic0: routing intpin 1 (ISA IRQ 1) to lapic 1 vector 48 ioapic0: routing intpin 14 (ISA IRQ 14) to lapic 1 vector 49 ioapic0: routing intpin 16 (PCI IRQ 16) to lapic 1 vector 50 ioapic0: routing intpin 20 (PCI IRQ 20) to lapic 1 vector 51 ioapic0: routing intpin 23 (PCI IRQ 23) to lapic 1 vector 52 Timecounter "TSC" frequency 2798716096 Hz quality -100 GEOM: new disk cd0 GEOM: ada0s1: geometry does not match label (255h,63s != 16h,63s). (cd0:ata1:0:0:0): SCSI status error (cd0:ata1:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 (cd0:ata1:0:0:0): CAM status: SCSI Status Error (cd0:ata1:0:0:0): SCSI status: Check Condition (cd0:ata1:0:0:0): SCSI sense: NOT READY asc:3a,0 (Medium not present) (cd0:ata1:0:0:0): Error 6, Unretryable error (cd0:ata1:0:0:0): SCSI status error (cd0:ata1:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 (cd0:ata1:0:0:0): CAM status: SCSI Status Error (cd0:ata1:0:0:0): SCSI status: Check Condition (cd0:ata1:0:0:0): SCSI sense: NOT READY asc:3a,0 (Medium not present) (cd0:ata1:0:0:0): Error 6, Unretryable error Root mount waiting for: usbus2 usbus1 usbus0 uhub0: 2 ports with 2 removable, self powered uhub1: 2 ports with 2 removable, self powered Root mount waiting for: usbus2 uhub2: 4 ports with 4 removable, self powered Root mount waiting for: usbus2 Trying to mount root from ufs:/dev/ada0s1a [rw,noatime]... start_init: trying /sbin/init ugen1.2: at usbus1 ums0: on usbus1 ums0: 5 buttons and [XYZT] coordinates ID=1 procfs registered Linux ELF exec handler installed linprocfs registered ========== ``dmesg'' for the bad kernel configuration ends ========== ========== ``devinfo -rv'' for the good kernel configuration begins ========== nexus0 npx0 apic0 ram0 I/O memory addresses: 0x0-0x9fbff 0x100000-0x1ff2ffff acpi0 Interrupt request lines: 9 I/O ports: 0x10-0x1f 0x22-0x3f 0x44-0x5f 0x62-0x63 0x65-0x6f 0x72-0x7f 0x80 0x84-0x86 0x88 0x8c-0x8e 0x90-0x9f 0xa2-0xbf 0xe0-0xef 0x290-0x297 0x480-0x4bf 0x4d0-0x4d1 0x680-0x6ff 0x800-0x87f I/O memory addresses: 0xc0000-0xdffff 0xe0000-0xfffff 0xfec00000-0xfec00fff 0xfed20000-0xfed8ffff 0xfee00000-0xfee00fff 0xffb00000-0xffbfffff 0xfff00000-0xffffffff cpu0 pnpinfo _HID=none _UID=0 at handle=\_PR_.CPU1 p4tcc0 cpufreq0 cpu1 pnpinfo _HID=none _UID=0 at handle=\_PR_.CPU2 p4tcc1 cpufreq1 pcib0 pnpinfo _HID=PNP0A03 _UID=0 at handle=\_SB_.PCI0 I/O ports: 0xcf8-0xcff pci0 hostb0 pnpinfo vendor=0x8086 device=0x2570 subvendor=0x1043 subdevice=0x80f2 class=0x060000 at slot=0 function=0 I/O memory addresses: 0xf0000000-0xf7ffffff agp0 pcib1 pnpinfo vendor=0x8086 device=0x2571 subvendor=0x0000 subdevice=0x0000 class=0x060400 at slot=1 function=0 handle=\_SB_.PCI0.P0P1 pci1 vgapci0 pnpinfo vendor=0x1002 device=0x4150 subvendor=0x17ee subdevice=0x2002 class=0x030000 at slot=0 function=0 Interrupt request lines: 16 I/O ports: 0xd000-0xd0ff I/O memory addresses: 0xd0000000-0xdfffffff 0xfbee0000-0xfbeeffff vgapm0 drm0 vgapci1 pnpinfo vendor=0x1002 device=0x4170 subvendor=0x17ee subdevice=0x2003 class=0x038000 at slot=0 function=1 I/O memory addresses: 0xe0000000-0xefffffff 0xfbef0000-0xfbefffff drm1 uhci0 pnpinfo vendor=0x8086 device=0x24d2 subvendor=0x1043 subdevice=0x80a6 class=0x0c0300 at slot=29 function=0 handle=\_SB_.PCI0.USB1 Interrupt request lines: 16 I/O ports: 0xc880-0xc89f usbus0 uhub0 uhci1 pnpinfo vendor=0x8086 device=0x24d4 subvendor=0x1043 subdevice=0x80a6 class=0x0c0300 at slot=29 function=1 handle=\_SB_.PCI0.USB2 Interrupt request lines: 19 I/O ports: 0xcc00-0xcc1f usbus1 uhub1 ums0 pnpinfo vendor=0x04fc product=0x0801 devclass=0x00 devsubclass=0x00 sernum="" release=0x1611 intclass=0x03 intsubclass=0x01 at bus=1 hubaddr=2 port=1 devaddr=2 interface=0 ehci0 pnpinfo vendor=0x8086 device=0x24dd subvendor=0x1043 subdevice=0x80a6 class=0x0c0320 at slot=29 function=7 handle=\_SB_.PCI0.EUSB Interrupt request lines: 23 I/O memory addresses: 0xfbdffc00-0xfbdfffff usbus2 uhub2 pcib2 pnpinfo vendor=0x8086 device=0x244e subvendor=0x0000 subdevice=0x0000 class=0x060400 at slot=30 function=0 handle=\_SB_.PCI0.P0P4 pci2 skc0 pnpinfo vendor=0x10b7 device=0x1700 subvendor=0x1043 subdevice=0x80eb class=0x020000 at slot=5 function=0 Interrupt request lines: 22 I/O ports: 0xe800-0xe8ff I/O memory addresses: 0xfbffc000-0xfbffffff sk0 miibus0 e1000phy0 pnpinfo oui=0xac2 model=0x2 rev=0x3 at phyno=0 pcm0 pnpinfo vendor=0x1274 device=0x5880 subvendor=0x1274 subdevice=0x8001 class=0x040100 at slot=12 function=0 Interrupt request lines: 20 I/O ports: 0xec00-0xec3f isab0 pnpinfo vendor=0x8086 device=0x24d0 subvendor=0x0000 subdevice=0x0000 class=0x060100 at slot=31 function=0 handle=\_SB_.PCI0.SBRG isa0 pmtimer0 sc0 vga0 I/O ports: 0x3c0-0x3df I/O memory addresses: 0xa0000-0xbffff orm0 pnpinfo pnpid=ORM0000 ACPI I/O memory addresses: 0xc0000-0xccfff fdc0 ppc0 uart0 uart1 atapci0 pnpinfo vendor=0x8086 device=0x24db subvendor=0x1043 subdevice=0x80a6 class=0x01018a at slot=31 function=1 handle=\_SB_.PCI0.IDE0 I/O ports: 0x170-0x177 0x1f0-0x1f7 0x376 0x3f6 0xfc00-0xfc0f ata0 at channel=0 Interrupt request lines: 14 ata1 at channel=1 Interrupt request lines: 15 unknown pnpinfo vendor=0x8086 device=0x24d3 subvendor=0x1043 subdevice=0x80a6 class=0x0c0500 at slot=31 function=3 I/O ports: 0x400-0x41f unknown pnpinfo _HID=none _UID=0 at handle=\_SB_.PCI0.IDE0.CHN0 unknown pnpinfo _HID=none _UID=0 at handle=\_SB_.PCI0.IDE0.CHN0.DRV0 unknown pnpinfo _HID=none _UID=0 at handle=\_SB_.PCI0.IDE0.CHN0.DRV1 unknown pnpinfo _HID=none _UID=0 at handle=\_SB_.PCI0.IDE0.CHN1 unknown pnpinfo _HID=none _UID=0 at handle=\_SB_.PCI0.IDE0.CHN1.DRV0 unknown pnpinfo _HID=none _UID=0 at handle=\_SB_.PCI0.IDE0.CHN1.DRV1 unknown pnpinfo _HID=none _UID=0 at handle=\_SB_.PCI0.IDE1 unknown pnpinfo _HID=none _UID=0 at handle=\_SB_.PCI0.MC97 unknown pnpinfo _HID=none _UID=0 at handle=\_SB_.PCI0.USB3 unknown pnpinfo _HID=none _UID=0 at handle=\_SB_.PCI0.USB4 atpic0 pnpinfo _HID=PNP0000 _UID=0 at handle=\_SB_.PCI0.SBRG.PIC_ I/O ports: 0x20-0x21 0xa0-0xa1 atdma0 pnpinfo _HID=PNP0200 _UID=0 at handle=\_SB_.PCI0.SBRG.DMAD DMA request lines: 4 I/O ports: 0x0-0xf 0x81-0x83 0x87 0x89-0x8b 0x8f 0xc0-0xdf attimer0 pnpinfo _HID=PNP0100 _UID=0 at handle=\_SB_.PCI0.SBRG.TMR_ Interrupt request lines: 0 I/O ports: 0x40-0x43 atrtc0 pnpinfo _HID=PNP0B00 _UID=0 at handle=\_SB_.PCI0.SBRG.RTC0 Interrupt request lines: 8 I/O ports: 0x70-0x71 atkbdc0 pnpinfo _HID=PNP0303 _UID=0 at handle=\_SB_.PCI0.SBRG.PS2K Interrupt request lines: 1 I/O ports: 0x60 0x64 atkbd0 psm0 psmcpnp0 pnpinfo _HID=PNP0F03 _UID=0 at handle=\_SB_.PCI0.SBRG.PS2M unknown pnpinfo _HID=PNP0800 _UID=0 at handle=\_SB_.PCI0.SBRG.SPKR I/O ports: 0x61 npxisa0 pnpinfo _HID=PNP0C04 _UID=0 at handle=\_SB_.PCI0.SBRG.COPR I/O ports: 0xf0-0xff unknown pnpinfo _HID=PNP0501 _UID=1 at handle=\_SB_.PCI0.SBRG.UAR1 I/O ports: 0x3f8-0x3ff unknown pnpinfo _HID=PNP0501 _UID=2 at handle=\_SB_.PCI0.SBRG.UAR2 I/O ports: 0x2f8-0x2ff unknown pnpinfo _HID=PNP0700 _UID=0 at handle=\_SB_.PCI0.SBRG.FDC_ unknown pnpinfo _HID=PNP0401 _UID=1 at handle=\_SB_.PCI0.SBRG.LPTE DMA request lines: 3 I/O ports: 0x378-0x37f 0x778-0x77b unknown pnpinfo _HID=PNPB02F _UID=0 at handle=\_SB_.PCI0.SBRG.GAME unknown pnpinfo _HID=PNPB006 _UID=0 at handle=\_SB_.PCI0.SBRG.MIDI acpi_sysresource0 pnpinfo _HID=PNP0C02 _UID=46 at handle=\_SB_.PCI0.SBRG.SIOR acpi_sysresource1 pnpinfo _HID=PNP0C02 _UID=16 at handle=\_SB_.PCI0.SBRG.RMSC unknown pnpinfo _HID=PNP0C02 _UID=1014 at handle=\_SB_.PCI0.SBRG.P3F6 acpi_sysresource2 pnpinfo _HID=PNP0C02 _UID=0 at handle=\_SB_.PCI0.SBRG.OMSC unknown pnpinfo _HID=none _UID=0 at handle=\_SB_.PCI0.P0P2 unknown pnpinfo _HID=none _UID=0 at handle=\_SB_.PCI0.P0P2.ILAN acpi_sysresource3 pnpinfo _HID=PNP0C01 _UID=1 at handle=\_SB_.RMEM acpi_button0 pnpinfo _HID=PNP0C0C _UID=170 at handle=\_SB_.PWRB pci_link0 pnpinfo _HID=PNP0C0F _UID=1 at handle=\_SB_.LNKA pci_link1 pnpinfo _HID=PNP0C0F _UID=2 at handle=\_SB_.LNKB pci_link2 pnpinfo _HID=PNP0C0F _UID=3 at handle=\_SB_.LNKC pci_link3 pnpinfo _HID=PNP0C0F _UID=4 at handle=\_SB_.LNKD pci_link4 pnpinfo _HID=PNP0C0F _UID=5 at handle=\_SB_.LNKE pci_link5 pnpinfo _HID=PNP0C0F _UID=6 at handle=\_SB_.LNKF pci_link6 pnpinfo _HID=PNP0C0F _UID=7 at handle=\_SB_.LNKG pci_link7 pnpinfo _HID=PNP0C0F _UID=8 at handle=\_SB_.LNKH acpi_timer0 pnpinfo unknown at unknown ACPI I/O ports: 0x808-0x80b ========== ``devinfo -rv'' for the good kernel configuration ends ========== ========== ``devinfo -u'' for the good kernel configuration begins ========== Interrupt request lines: 0 (attimer0) 1 (atkbdc0) 3-7 (root0) 8 (atrtc0) 9 (acpi0) 10-13 (root0) 14 (ata0) 15 (ata1) 16 (uhci0) 16 (vgapci0) 17-18 (root0) 19 (uhci1) 20 (pcm0) 21 (root0) 22 (skc0) 23 (ehci0) DMA request lines: 0-2 (root0) 3 ---- 4 (atdma0) 5-7 (root0) I/O ports: 0x0-0xf (atdma0) 0x10-0x1f (acpi0) 0x20-0x21 (atpic0) 0x22-0x3f (acpi0) 0x40-0x43 (attimer0) 0x44-0x5f (acpi0) 0x60 (atkbdc0) 0x61 ---- 0x62-0x63 (acpi0) 0x64 (atkbdc0) 0x65-0x6f (acpi0) 0x70-0x71 (atrtc0) 0x72-0x7f (acpi0) 0x80 (acpi0) 0x81-0x83 (atdma0) 0x84-0x86 (acpi0) 0x87 (atdma0) 0x88 (acpi0) 0x89-0x8b (atdma0) 0x8c-0x8e (acpi0) 0x8f (atdma0) 0x90-0x9f (acpi0) 0xa0-0xa1 (atpic0) 0xa2-0xbf (acpi0) 0xc0-0xdf (atdma0) 0xe0-0xef (acpi0) 0xf0-0xff (npxisa0) 0x100-0x16f (root0) 0x170-0x177 (atapci0) 0x178-0x1ef (root0) 0x1f0-0x1f7 (atapci0) 0x1f8-0x28f (root0) 0x290-0x297 (acpi0) 0x298-0x2f7 (root0) 0x2f8-0x2ff ---- 0x300-0x375 (root0) 0x376 (atapci0) 0x377 (root0) 0x378-0x37f ---- 0x380-0x3bf (root0) 0x3c0-0x3df (vga0) 0x3e0-0x3f5 (root0) 0x3f6 (atapci0) 0x3f7 (root0) 0x3f8-0x3ff ---- 0x400-0x41f ---- 0x420-0x47f (root0) 0x480-0x4bf (acpi0) 0x4c0-0x4cf (root0) 0x4d0-0x4d1 (acpi0) 0x4d2-0x67f (root0) 0x680-0x6ff (acpi0) 0x700-0x777 (root0) 0x778-0x77b ---- 0x77c-0x7ff (root0) 0x800-0x87f (acpi0) 0x880-0xcf7 (root0) 0xcf8-0xcff (pcib0) 0xd00-0xc87f (root0) 0xc880-0xc89f (uhci0) 0xc8a0-0xcbff (root0) 0xcc00-0xcc1f (uhci1) 0xcc20-0xcfff (root0) 0xd000-0xd0ff (vgapci0) 0xd100-0xe7ff (root0) 0xe800-0xe8ff (skc0) 0xe900-0xebff (root0) 0xec00-0xec3f (pcm0) 0xec40-0xfbff (root0) 0xfc00-0xfc0f (atapci0) 0xfc10-0xffff (root0) I/O memory addresses: 0x0-0x9fbff (ram0) 0x9fc00-0x9ffff (root0) 0xa0000-0xbffff (vga0) 0xc0000-0xdffff (acpi0) 0xe0000-0xfffff (acpi0) 0x100000-0x1ff2ffff (ram0) 0x1ff30000-0xcfffffff (root0) 0xd0000000-0xdfffffff (vgapci0) 0xe0000000-0xefffffff (vgapci1) 0xf0000000-0xf7ffffff (hostb0) 0xf8000000-0xfbdffbff (root0) 0xfbdffc00-0xfbdfffff (ehci0) 0xfbe00000-0xfbedffff (root0) 0xfbee0000-0xfbeeffff (vgapci0) 0xfbef0000-0xfbefffff (vgapci1) 0xfbf00000-0xfbffbfff (root0) 0xfbffc000-0xfbffffff (skc0) 0xfc000000-0xfebfffff (root0) 0xfec00000-0xfec00fff (acpi0) 0xfec01000-0xfed1ffff (root0) 0xfed20000-0xfed8ffff (acpi0) 0xfed90000-0xfedfffff (root0) 0xfee00000-0xfee00fff (acpi0) 0xfee01000-0xffafffff (root0) 0xffb00000-0xffbfffff (acpi0) 0xffc00000-0xffefffff (root0) 0xfff00000-0xffffffff (acpi0) ACPI I/O ports: 0x10-0x1f (root0) 0x22-0x3f (root0) 0x44-0x5f (root0) 0x62-0x63 (root0) 0x65-0x6f (root0) 0x72-0x80 (root0) 0x84-0x86 (root0) 0x88 (root0) 0x8c-0x8e (root0) 0x90-0x9f (root0) 0xa2-0xbf (root0) 0xe0-0xef (root0) 0x290-0x297 (root0) 0x480-0x4bf (root0) 0x4d0-0x4d1 (root0) 0x680-0x6ff (root0) 0x800-0x807 (root0) 0x808-0x80b (acpi_timer0) 0x80c-0x87f (root0) ACPI I/O memory addresses: 0xc0000-0xccfff (orm0) 0xcd000-0xfffff (root0) 0xfec00000-0xfec00fff (root0) 0xfed20000-0xfed8ffff (root0) 0xfee00000-0xfee00fff (root0) 0xffb00000-0xffbfffff (root0) 0xfff00000-0xffffffff (root0) ========== ``devinfo -u'' for the good kernel configuration ends ========== ========== ``dmesg'' for the good kernel configuration begins ========== MP Configuration Table version 1.1 found at 0xc00f1280 Table 'FACP' at 0x1ff30290 Table 'APIC' at 0x1ff30390 APIC: Found table at 0x1ff30390 APIC: Using the MADT enumerator. MADT: Found CPU APIC ID 0 ACPI ID 1: enabled SMP: Added CPU 0 (AP) MADT: Found CPU APIC ID 1 ACPI ID 2: enabled SMP: Added CPU 1 (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. FreeBSD 9.0-CURRENT #0 r221970M: Mon May 16 01:16:26 CEST 2011 devhc@:/usr/obj/usr/src/sys/HQ i386 Table 'FACP' at 0x1ff30290 Table 'APIC' at 0x1ff30390 Table 'OEMB' at 0x1ff40040 ACPI: No SRAT table found Preloaded elf kernel "/boot/kernel.HQ.r221970.copyin2.opie/kernel" at 0xc0b9b000. Calibrating TSC clock ... TSC clock: 2798712296 Hz CPU: Intel(R) Pentium(R) 4 CPU 2.80GHz (2798.71-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf29 Family = f Model = 2 Stepping = 9 Features=0xbfebfbff Features2=0x4400 Instruction TLB: 4 KB, 2 MB or 4 MB pages, fully associative, 64 entries Data TLB: 4 KB or 4 MB pages, fully associative, 64 entries 1st-level data cache: 8 KB, 4-way set associative, sectored cache, 64 byte line size Trace cache: 12K-uops, 8-way set associative 2nd-level cache: 512 KB, 8-way set associative, sectored cache, 64 byte line size real memory = 536870912 (512 MB) Physical memory chunk(s): 0x0000000000001000 - 0x000000000009efff, 647168 bytes (158 pages) 0x0000000000100000 - 0x00000000003fffff, 3145728 bytes (768 pages) 0x0000000000c26000 - 0x000000001f5ecfff, 513568768 bytes (125383 pages) avail memory = 513884160 (490 MB) Event timer "LAPIC" quality 400 ACPI APIC Table: INTR: Adding local APIC 1 as a target FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 2 package(s) x 1 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 bios32: Found BIOS32 Service Directory header at 0xc00f0000 bios32: Entry = 0xf0010 (c00f0010) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xf0000+0x31 pnpbios: Found PnP BIOS data at 0xc00f5020 pnpbios: Entry = f0000:5c0a Rev = 1.0 Other BIOS signatures found: APIC: CPU 0 has ACPI ID 1 APIC: CPU 1 has ACPI ID 2 ULE: setup cpu 0 ULE: setup cpu 1 ACPI: RSDP 0xf9e30 00021 (v02 ACPIAM) ACPI: XSDT 0x1ff30100 0003C (v01 A M I OEMXSDT 10000414 MSFT 00000097) ACPI: FACP 0x1ff30290 000F4 (v03 A M I OEMFACP 10000414 MSFT 00000097) ACPI: DSDT 0x1ff303f0 0382D (v01 P4P81 P4P81104 00000104 INTL 02002026) ACPI: FACS 0x1ff40000 00040 ACPI: APIC 0x1ff30390 0005C (v01 A M I OEMAPIC 10000414 MSFT 00000097) ACPI: OEMB 0x1ff40040 0003F (v01 A M I OEMBIOS 10000414 MSFT 00000097) MADT: Found IO APIC ID 2, Interrupt 0 at 0xfec00000 ioapic0: Routing external 8259A's -> intpin 0 MADT: Interrupt override: source 0, irq 2 ioapic0: Routing IRQ 0 -> intpin 2 MADT: Interrupt override: source 9, irq 9 ioapic0: intpin 9 trigger: level ioapic0 irqs 0-23 on motherboard cpu0 BSP: ID: 0x00000000 VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000100ef therm: 0x00010000 err: 0x000000f0 pmc: 0x00010400 snd_unit_init() u=0x00ff8000 [512] d=0x00007c00 [32] c=0x000003ff [1024] feeder_register: snd_unit=-1 snd_maxautovchans=16 latency=5 feeder_rate_min=1 feeder_rate_max=2016000 feeder_rate_round=25 null: nfslock: pseudo-device random: io: kbd: new array size 4 kbd1 at kbdmux0 mem: Pentium Pro MTRR support enabled acpi0: on motherboard ioapic0: routing intpin 9 (ISA IRQ 9) to lapic 0 vector 48 ACPI: Executed 1 blocks of module-level executable AML code acpi0: Power Button (fixed) acpi0: wakeup code va 0xc2694000 pa 0x1000 pci_open(1): mode 1 addr port (0x0cf8) is 0x80000090 pci_open(1a): mode1res=0x80000000 (0x80000000) pci_cfgcheck: device 0 [class=060000] [hdr=00] is there (id=25708086) pcibios: BIOS version 2.10 acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, 1fef0000 (3) failed ACPI timer: 1/0 1/0 1/0 1/0 1/0 1/0 1/0 1/0 1/0 1/0 -> 10 Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 cpu0: on acpi0 cpu0: switching to generic Cx mode cpu1: on acpi0 pci_link0: Index IRQ Rtd Ref IRQs Initial Probe 0 10 N 0 3 4 5 6 7 10 11 12 14 15 Validation 0 10 N 0 3 4 5 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 10 11 12 14 15 pci_link1: Index IRQ Rtd Ref IRQs Initial Probe 0 10 N 0 3 4 5 6 7 10 11 12 14 15 Validation 0 10 N 0 3 4 5 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 10 11 12 14 15 pci_link2: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 4 5 6 7 10 11 12 14 15 Validation 0 255 N 0 3 4 5 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 10 11 12 14 15 pci_link3: Index IRQ Rtd Ref IRQs Initial Probe 0 5 N 0 3 4 5 6 7 10 11 12 14 15 Validation 0 5 N 0 3 4 5 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 10 11 12 14 15 pci_link4: Index IRQ Rtd Ref IRQs Initial Probe 0 5 N 0 3 4 5 6 7 10 11 12 14 15 Validation 0 5 N 0 3 4 5 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 10 11 12 14 15 pci_link5: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 4 5 6 7 10 11 12 14 15 Validation 0 255 N 0 3 4 5 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 10 11 12 14 15 pci_link6: Index IRQ Rtd Ref IRQs Initial Probe 0 10 N 0 3 4 5 6 7 10 11 12 14 15 Validation 0 10 N 0 3 4 5 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 10 11 12 14 15 pci_link7: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 3 4 5 6 7 10 11 12 14 15 Validation 0 11 N 0 3 4 5 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 10 11 12 14 15 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pci0: domain=0, physical bus=0 found-> vendor=0x8086, dev=0x2570, revid=0x02 domain=0, bus=0, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x2090, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) map[10]: type Prefetchable Memory, range 32, base 0xf0000000, size 27, enabled found-> vendor=0x8086, dev=0x2571, revid=0x02 domain=0, bus=0, slot=1, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0107, statreg=0x00a0, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x08 (2000 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x24d2, revid=0x02 domain=0, bus=0, slot=29, func=0 class=0c-03-00, hdrtype=0x00, mfdev=1 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 map[20]: type I/O Port, range 32, base 0xc880, size 5, enabled pcib0: matched entry for 0.29.INTA pcib0: slot 29 INTA hardwired to IRQ 16 found-> vendor=0x8086, dev=0x24d4, revid=0x02 domain=0, bus=0, slot=29, func=1 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=5 map[20]: type I/O Port, range 32, base 0xcc00, size 5, enabled pcib0: matched entry for 0.29.INTB pcib0: slot 29 INTB hardwired to IRQ 19 found-> vendor=0x8086, dev=0x24dd, revid=0x02 domain=0, bus=0, slot=29, func=7 class=0c-03-20, hdrtype=0x00, mfdev=0 cmdreg=0x0106, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=d, irq=11 powerspec 2 supports D0 D3 current D0 map[10]: type Memory, range 32, base 0xfbdffc00, size 10, enabled pcib0: matched entry for 0.29.INTD pcib0: slot 29 INTD hardwired to IRQ 23 found-> vendor=0x8086, dev=0x244e, revid=0xc2 domain=0, bus=0, slot=30, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0107, statreg=0x0080, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x06 (1500 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x24d0, revid=0x02 domain=0, bus=0, slot=31, func=0 class=06-01-00, hdrtype=0x00, mfdev=1 cmdreg=0x000f, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x24db, revid=0x02 domain=0, bus=0, slot=31, func=1 class=01-01-8a, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=255 map[20]: type I/O Port, range 32, base 0xfc00, size 4, enabled map[24]: type Memory, range 32, base 0, size 10, memory disabled found-> vendor=0x8086, dev=0x24d3, revid=0x02 domain=0, bus=0, slot=31, func=3 class=0c-05-00, hdrtype=0x00, mfdev=0 cmdreg=0x0001, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=10 map[20]: type I/O Port, range 32, base 0x400, size 5, enabled pcib0: matched entry for 0.31.INTB pcib0: slot 31 INTB hardwired to IRQ 17 agp0: on hostb0 agp0: allocating GATT for aperture of size 128M pcib1: at device 1.0 on pci0 pcib1: domain 0 pcib1: secondary bus 1 pcib1: subordinate bus 1 pcib1: I/O decode 0xd000-0xdfff pcib1: memory decode 0xfbe00000-0xfbefffff pcib1: prefetched decode 0xd0000000-0xfaffffff pcib1: could not get PCI interrupt routing table for \\_SB_.PCI0.P0P1 - AE_NOT_FOUND pci1: on pcib1 pci1: domain=0, physical bus=1 found-> vendor=0x1002, dev=0x4150, revid=0x00 domain=0, bus=1, slot=0, func=0 class=03-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0107, statreg=0x02b0, cachelnsz=4 (dwords) lattimer=0x40 (1920 ns), mingnt=0x08 (2000 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type Prefetchable Memory, range 32, base 0xd0000000, size 28, enabled pcib1: requested memory range 0xd0000000-0xdfffffff: good map[14]: type I/O Port, range 32, base 0xd000, size 8, enabled pcib1: requested I/O range 0xd000-0xd0ff: in range map[18]: type Memory, range 32, base 0xfbee0000, size 16, enabled pcib1: requested memory range 0xfbee0000-0xfbeeffff: good pcib0: matched entry for 0.1.INTA pcib0: slot 1 INTA hardwired to IRQ 16 pcib1: slot 0 INTA is routed to irq 16 found-> vendor=0x1002, dev=0x4170, revid=0x00 domain=0, bus=1, slot=0, func=1 class=03-80-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x02b0, cachelnsz=4 (dwords) lattimer=0x40 (1920 ns), mingnt=0x08 (2000 ns), maxlat=0x00 (0 ns) powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type Prefetchable Memory, range 32, base 0xe0000000, size 28, enabled pcib1: requested memory range 0xe0000000-0xefffffff: good map[14]: type Memory, range 32, base 0xfbef0000, size 16, enabled pcib1: requested memory range 0xfbef0000-0xfbefffff: good vgapci0: port 0xd000-0xd0ff mem 0xd0000000-0xdfffffff,0xfbee0000-0xfbeeffff irq 16 at device 0.0 on pci1 drm0: on vgapci0 info: [drm] AGP at 0xf0000000 128MB info: [drm] Initialized radeon 1.31.0 20080613 vgapci1: mem 0xe0000000-0xefffffff,0xfbef0000-0xfbefffff at device 0.1 on pci1 uhci0: port 0xc880-0xc89f irq 16 at device 29.0 on pci0 ioapic0: routing intpin 16 (PCI IRQ 16) to lapic 0 vector 49 usbus0: on uhci0 usbus0: bpf attached uhci0: usbpf: Attached uhci1: port 0xcc00-0xcc1f irq 19 at device 29.1 on pci0 ioapic0: routing intpin 19 (PCI IRQ 19) to lapic 0 vector 50 usbus1: on uhci1 usbus1: bpf attached uhci1: usbpf: Attached ehci0: mem 0xfbdffc00-0xfbdfffff irq 23 at device 29.7 on pci0 ioapic0: routing intpin 23 (PCI IRQ 23) to lapic 0 vector 51 usbus2: EHCI version 1.0 usbus2: on ehci0 usbus2: bpf attached ehci0: usbpf: Attached pcib2: at device 30.0 on pci0 pcib2: domain 0 pcib2: secondary bus 2 pcib2: subordinate bus 2 pcib2: I/O decode 0xe000-0xefff pcib2: memory decode 0xfbf00000-0xfbffffff pcib2: no prefetched decode pcib2: Subtractively decoded bridge. pci2: on pcib2 pci2: domain=0, physical bus=2 found-> vendor=0x10b7, dev=0x1700, revid=0x12 domain=0, bus=2, slot=5, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0117, statreg=0x02b0, cachelnsz=4 (dwords) lattimer=0x40 (1920 ns), mingnt=0x17 (5750 ns), maxlat=0x1f (7750 ns) intpin=a, irq=10 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type Memory, range 32, base 0xfbffc000, size 14, enabled pcib2: requested memory range 0xfbffc000-0xfbffffff: good map[14]: type I/O Port, range 32, base 0xe800, size 8, enabled pcib2: requested I/O range 0xe800-0xe8ff: in range pcib2: matched entry for 2.5.INTA pcib2: slot 5 INTA hardwired to IRQ 22 found-> vendor=0x1274, dev=0x5880, revid=0x04 domain=0, bus=2, slot=12, func=0 class=04-01-00, hdrtype=0x00, mfdev=0 cmdreg=0x0105, statreg=0x0410, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x0c (3000 ns), maxlat=0x80 (32000 ns) intpin=a, irq=5 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type I/O Port, range 32, base 0xec00, size 6, enabled pcib2: requested I/O range 0xec00-0xec3f: in range pcib2: matched entry for 2.12.INTA pcib2: slot 12 INTA hardwired to IRQ 20 skc0: <3Com 3C940 Gigabit Ethernet> port 0xe800-0xe8ff mem 0xfbffc000-0xfbffffff irq 22 at device 5.0 on pci2 skc0: interrupt moderation is 100 us skc0: 3Com Gigabit LOM (3C940) rev. (0x1) skc0: chip ver = 0xb0 skc0: chip rev = 0x01 skc0: SK_EPROM0 = 0x00 skc0: SRAM size = 0x020000 sk0: on skc0 sk0: bpf attached sk0: Ethernet address: 00:0e:a6:35:15:91 miibus0: on sk0 e1000phy0: PHY 0 on miibus0 e1000phy0: OUI 0x000ac2, model 0x0002, rev. 3 e1000phy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto ioapic0: routing intpin 22 (PCI IRQ 22) to lapic 0 vector 52 pcm0: port 0xec00-0xec3f irq 20 at device 12.0 on pci2 pcm0: pcm0: Codec features 18 bit DAC, 18 bit ADC, 5 bit master volume, no 3D Stereo Enhancement pcm0: Primary codec extended features surround DAC, AMAP pcm0: ac97 codec dac ready count: 0 pcm0: Mixer "vol": pcm0: Mixer "pcm": pcm0: Mixer "speaker": pcm0: Mixer "line": pcm0: Mixer "mic": pcm0: Mixer "cd": pcm0: Mixer "rec": pcm0: Mixer "igain": pcm0: Mixer "ogain": pcm0: Mixer "line1": pcm0: Mixer "phin": pcm0: Mixer "phout": pcm0: Mixer "video": ioapic0: routing intpin 20 (PCI IRQ 20) to lapic 0 vector 53 pcm0: clone manager: deadline=750ms flags=0x8000001e pcm0: sndbuf_setmap 169c000, 1000; 0xc2a9c000 -> 169c000 pcm0: sndbuf_setmap 169a000, 1000; 0xc2a9a000 -> 169a000 pcm0: sndbuf_setmap 1698000, 1000; 0xc2a98000 -> 1698000 pcm0: isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xfc00-0xfc0f at device 31.1 on pci0 ata0: on atapci0 ioapic0: routing intpin 14 (ISA IRQ 14) to lapic 0 vector 54 ata1: on atapci0 ioapic0: routing intpin 15 (ISA IRQ 15) to lapic 0 vector 55 pci0: at device 31.3 (no driver attached) acpi_button0: on acpi0 attimer0: port 0x40-0x43 irq 0 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 ioapic0: routing intpin 2 (ISA IRQ 0) to lapic 0 vector 56 Event timer "i8254" frequency 1193182 Hz quality 100 atrtc0: port 0x70-0x71 irq 8 on acpi0 atrtc0: registered as a time-of-day clock (resolution 1000000us, adjustment 0.500000000s) ioapic0: routing intpin 8 (ISA IRQ 8) to lapic 0 vector 57 Event timer "RTC" frequency 32768 Hz quality 0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 atkbd: the current kbd controller command byte 0065 atkbd: keyboard ID 0x41ab (2) kbd0 at atkbd0 kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x3d0000 ioapic0: routing intpin 1 (ISA IRQ 1) to lapic 0 vector 58 atkbd0: [GIANT-LOCKED] psm0: unable to allocate IRQ psmcpnp0: irq 12 on acpi0 psm0: current command byte:0065 psm0: failed to reset the aux device. pnp_identify: Trying Read_Port at 203 pnp_identify: Trying Read_Port at 243 pnp_identify: Trying Read_Port at 283 pnp_identify: Trying Read_Port at 2c3 pnp_identify: Trying Read_Port at 303 pnp_identify: Trying Read_Port at 343 pnp_identify: Trying Read_Port at 383 pnp_identify: Trying Read_Port at 3c3 PNP Identify complete isa_probe_children: disabling PnP devices pmtimer0 on isa0 ata: ata0 already exists; skipping it ata: ata1 already exists; skipping it atkbdc: atkbdc0 already exists; skipping it atrtc: atrtc0 already exists; skipping it attimer: attimer0 already exists; skipping it sc: sc0 already exists; skipping it isa_probe_children: probing non-PnP devices orm0: at iomem 0xc0000-0xccfff pnpid ORM0000 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sc0: fb0, kbd1, terminal emulator: scteken (teken terminal) vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 fdc0 failed to probe at port 0x3f0 irq 6 drq 2 on isa0 ppc0 failed to probe at irq 7 on isa0 uart0 failed to probe at port 0x3f8 irq 4 on isa0 uart1 failed to probe at port 0x2f8 irq 3 on isa0 isa_probe_children: probing PnP devices p4tcc0: on cpu0 p4tcc1: on cpu1 Device configuration finished. lapic: Divisor 2, Frequency 99952211 Hz Timecounters tick every 1.000 msec lo0: bpf attached usbus0: 12Mbps Full Speed USB v1.0 usbus1: 12Mbps Full Speed USB v1.0 usbus2: 480Mbps High Speed USB v2.0 ata0: reset tp1 mask=03 ostat0=50 ostat1=00 ata0: stat0=0x50 err=0x01 lsb=0x00 msb=0x00 ata0: stat1=0x00 err=0x01 lsb=0x00 msb=0x00 ata0: reset tp2 stat0=50 stat1=00 devices=0x1 (aprobe0:ata0:0:0:0): SIGNATURE: 0000 ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 ugen2.1: at usbus2 uhub2: on usbus2 ata1: reset tp1 mask=03 ostat0=50 ostat1=00 ata1: stat0=0x00 err=0x01 lsb=0x14 msb=0xeb ata1: stat1=0x00 err=0x00 lsb=0x00 msb=0x00 ata1: reset tp2 stat0=00 stat1=00 devices=0x10000 (aprobe0:ata1:0:0:0): SIGNATURE: eb14 ata1: DMA limited to UDMA33, controller found non-ATA66 cable ada0 at ata0 bus 0 scbus0 target 0 lun 0 ada0: ATA-7 device ada0: Serial Number Y2JPFJPE ada0: 100.000MB/s transfers (UDMA5, PIO 8192bytes) ada0: 78167MB (160086528 512 byte sectors: 16H 63S/T 16383C) ada0: Previously was known as ad0 GEOM: new disk ada0 pass0 at ata0 bus 0 scbus0 target 0 lun 0 pass0: ATA-7 device pass0: Serial Number Y2JPFJPE(cd0:ata1:0:0:0): SCSI status error (cd0:ata1:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 (cd0:ata1:0:0:0): CAM status: SCSI Status Error (cd0:ata1:0:0:0): SCSI status: Check Condition (cd0:ata1:0:0:0): SCSI sense: UNIT ATTENTION asc:29,0 (Power on, reset, or bus device reset occurred) (cd0:ata1:0:0:0): Retrying command (per sense data) pass0: 100.000MB/s transfers (UDMA5, PIO 8192bytes) pass1 at ata1 bus 0 scbus1 target 0 lun 0 pass1: Removable CD-ROM SCSI-0 device pass1: 33.300MB/s transfers (UDMA2, ATAPI 12bytes, PIO 65534bytes) (cd0:ata1:0:0:0): SCSI status error (cd0:ata1:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 (cd0:ata1:0:0:0): CAM status: SCSI Status Error (cd0:ata1:0:0:0): SCSI status: Check Condition (cd0:ata1:0:0:0): SCSI sense: NOT READY asc:3a,0 (Medium not present) (cd0:ata1:0:0:0): Error 6, Unretryable error cd0 at ata1 bus 0 scbus1 target 0 lun 0 cd0: Removable CD-ROM SCSI-0 device cd0: 33.300MB/s transfers (UDMA2, ATAPI 12bytes, PIO 65534bytes) cd0: Attempt to query device size failed: NOT READY, Medium not present SMP: AP CPU #1 Launched! cpu1 AP: ID: 0x01000000 VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000100ef therm: 0x00010000 err: 0x000000f0 pmc: 0x00010400 ioapic0: routing intpin 1 (ISA IRQ 1) to lapic 1 vector 48 ioapic0: routing intpin 14 (ISA IRQ 14) to lapic 1 vector 49 ioapic0: routing intpin 16 (PCI IRQ 16) to lapic 1 vector 50 ioapic0: routing intpin 20 (PCI IRQ 20) to lapic 1 vector 51 ioapic0: routing intpin 23 (PCI IRQ 23) to lapic 1 vector 52 Timecounter "TSC" frequency 2798712296 Hz quality -100 GEOM: new disk cd0 GEOM: ada0s1: geometry does not match label (255h,63s != 16h,63s). (cd0:ata1:0:0:0): SCSI status error (cd0:ata1:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 (cd0:ata1:0:0:0): CAM status: SCSI Status Error (cd0:ata1:0:0:0): SCSI status: Check Condition (cd0:ata1:0:0:0): SCSI sense: NOT READY asc:3a,0 (Medium not present) (cd0:ata1:0:0:0): Error 6, Unretryable error (cd0:ata1:0:0:0): SCSI status error (cd0:ata1:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 (cd0:ata1:0:0:0): CAM status: SCSI Status Error (cd0:ata1:0:0:0): SCSI status: Check Condition (cd0:ata1:0:0:0): SCSI sense: NOT READY asc:3a,0 (Medium not present) (cd0:ata1:0:0:0): Error 6, Unretryable error Root mount waiting for: usbus2 usbus1 usbus0 uhub0: 2 ports with 2 removable, self powered uhub1: 2 ports with 2 removable, self powered Root mount waiting for: usbus2 uhub2: 4 ports with 4 removable, self powered Root mount waiting for: usbus2 Trying to mount root from ufs:/dev/ada0s1a [rw,noatime]... start_init: trying /sbin/init ugen1.2: at usbus1 ums0: on usbus1 ums0: 5 buttons and [XYZT] coordinates ID=1 procfs registered Linux ELF exec handler installed linprocfs registered ========== ``dmesg'' for the good kernel configuration ends ========== From owner-freebsd-current@FreeBSD.ORG Mon May 16 22:12: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 44C08106566B; Mon, 16 May 2011 22:12:30 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id B7FC98FC15; Mon, 16 May 2011 22:12:29 +0000 (UTC) Received: by ywf7 with SMTP id 7so2106033ywf.13 for ; Mon, 16 May 2011 15:12:29 -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 :content-transfer-encoding; bh=4MRN5oeAB+eMpTmIWPz8Ewly09ZafaL+31zB8/0seSw=; b=kowkfuf11TvAN7YN6K0D0k9NCrJVFhy8KoKcVcMO0mgaGed3a8sah0vJNOhLURJiw2 SDbPbBctLQsI+GJSz4qVO0y37XyQCYPUgLxSWv+sj9/ltPZdNPcRy7bFz/a+S/rJR8tD HgvnXjhtMnWvGbz5wGAhAM4fZjeko6jGxt6HM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=ECtXGWeQP4YQyB+v2/ROntwOl27E8uwyIK1XJLxDPNF9O+UARLIM9CljPpSUVjLEBK nuvYCS4fD9QoqtC4gd9/8BbCG0WClQmTBk9FUP1KMbw/AXgqoW2Iu6+wjndPTQlWsemA Hh66hPBbqmn2F/Q5Z/iL6/dW6AgfsXfsx5f/8= MIME-Version: 1.0 Received: by 10.236.80.41 with SMTP id j29mr4554606yhe.214.1305583948935; Mon, 16 May 2011 15:12:28 -0700 (PDT) Sender: asmrookie@gmail.com Received: by 10.236.103.130 with HTTP; Mon, 16 May 2011 15:12:28 -0700 (PDT) In-Reply-To: <201105161805.51188.max@love2party.net> References: <4DCD357D.6000109@FreeBSD.org> <201105161738.53366.max@love2party.net> <201105161805.51188.max@love2party.net> Date: Tue, 17 May 2011 00:12:28 +0200 X-Google-Sender-Auth: ihWvFVVwVW1IrnT_S9j2BSX-VWQ Message-ID: From: Attilio Rao To: Max Laier Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD current , Peter Grehan , Andriy Gapon , neel@freebsd.org Subject: Re: proposed smp_rendezvous change 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, 16 May 2011 22:12:30 -0000 2011/5/17 Max Laier : > On Monday 16 May 2011 17:54:54 Attilio Rao wrote: >> 2011/5/16 Max Laier : >> > On Monday 16 May 2011 16:46:03 John Baldwin wrote: >> >> On Monday, May 16, 2011 4:30:44 pm Max Laier wrote: >> >> > On Monday 16 May 2011 14:21:27 John Baldwin wrote: >> >> > > Yes, we need to fix that. =C2=A0Humm, it doesn't preempt when you= do a >> >> > > critical_exit() though? =C2=A0Or do you use a hand-rolled critica= l exit >> >> > > that doesn't do a deferred preemption? >> >> > >> >> > Right now I just did a manual td_critnest++/--, but I guess ... >> >> >> >> Ah, ok, so you would "lose" a preemption. =C2=A0That's not really ide= al. >> >> >> >> > > Actually, I'm curious how the spin unlock inside the IPI could yi= eld >> >> > > the CPU. =C2=A0Oh, is rmlock doing a wakeup inside the IPI handle= r? =C2=A0I >> >> > > guess that is ok as long as the critical_exit() just defers the >> >> > > preemption to the end of the IPI handler. >> >> > >> >> > ... the earliest point where it is safe to preempt is after doing t= he >> >> > >> >> > =C2=A0 =C2=A0atomic_add_int(&smp_rv_waiters[2], 1); >> >> > >> >> > so that we can start other IPIs again. =C2=A0However, since we don'= t accept >> >> > new IPIs until we signal EOI in the MD code (on amd64), this might >> >> > still not be a good place to do the yield?!? >> >> >> >> Hmm, yeah, you would want to do the EOI before you yield. =C2=A0Howev= er, we >> >> could actually move the EOI up before calling the MI code so long as = we >> >> leave interrupts disabled for the duration of the handler (which we d= o). >> >> >> >> > The spin unlock boils down to a critical_exit() and unless we did a >> >> > critical_enter() at some point during the redenvouz setup, we will >> >> > yield() if we owepreempt. =C2=A0I'm not quite sure how that can hap= pen, but >> >> > it seems like there is a path that allows the scheduler to set it f= rom >> >> > a foreign CPU. >> >> >> >> No, it is only set on curthread by curthread. =C2=A0This is actually = my main >> >> question. =C2=A0I've no idea how this could happen unless the rmlock = code is >> >> actually triggering a wakeup or sched_add() in its rendezvous handler= . >> >> >> >> I don't see anything in rm_cleanIPI() that would do that however. >> >> >> >> I wonder if your original issue was really fixed =C2=A0just by the fi= rst >> >> patch you had which fixed the race in smp_rendezvous()? >> > >> > I found the stack that lead me to this patch in the first place: >> > >> > #0 =C2=A0sched_switch (td=3D0xffffff011a970000, newtd=3D0xffffff006e67= 84b0, >> > flags=3D4) at src/sys/kern/sched_ule.c:1939 >> > #1 =C2=A00xffffffff80285c7f in mi_switch (flags=3D6, newtd=3D0x0) at >> > src/sys/kern/kern_synch.c:475 >> > #2 =C2=A00xffffffff802a2cb3 in critical_exit () at >> > src/sys/kern/kern_switch.c:185 #3 =C2=A00xffffffff80465807 in spinlock= _exit >> > () at >> > src/sys/amd64/amd64/machdep.c:1458 >> > #4 =C2=A00xffffffff8027adea in rm_cleanIPI (arg=3D) at >> > src/sys/kern/kern_rmlock.c:180 >> > #5 =C2=A00xffffffff802b9887 in smp_rendezvous_action () at >> > src/sys/kern/subr_smp.c:402 >> > #6 =C2=A00xffffffff8045e2a4 in Xrendezvous () at >> > src/sys/amd64/amd64/apic_vector.S:235 >> > #7 =C2=A00xffffffff802a2c6e in critical_exit () at >> > src/sys/kern/kern_switch.c:179 #8 =C2=A00xffffffff804365ba in uma_zfre= e_arg >> > (zone=3D0xffffff009ff4b5a0, item=3D0xffffff000f34cd40, >> > udata=3D0xffffff000f34ce08) at >> > src/sys/vm/uma_core.c:2370 >> > . >> > . >> > . >> > >> > and now that I look at it again, it is clear that critical_exit() just >> > isn't interrupt safe. =C2=A0I'm not sure how to fix that, yet ... but = this: >> > >> > >> > =C2=A0 =C2=A0 =C2=A0 =C2=A0if (td->td_critnest =3D=3D 1) { >> > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0td->td_critnest= =3D 0; >> > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0if (td->td_owep= reempt) { >> > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0td->td_critnest =3D 1; >> > >> > clearly doesn't work. >> >> I'm sorry if I didn't reply to the whole rendezvous thread, but as >> long as there is so many people taking care of it, I'll stay hidden in >> my corner. >> >> I just wanted to tell that I think you are misunderstanding what >> critical section is supposed to do. >> >> When an interrupt fires, it goes on the old "interrupt/kernel context" >> which means it has not a context of his own. That is the reason why we >> disable interrupts on spinlocks (or similar workaround for !x86 >> architectures) and this is why spinlocks are the only protection >> usable in code that runs in interrupt context. >> >> Preempting just means another thread will be scheduler in the middle >> of another thread execution path. >> >> This code is perfectly fine if you consider curthread won't be >> descheduled while it is executing. > > Well, no - it is not. =C2=A0With this you can end up with a curthread tha= t has > td_critnest=3D0 and td_owepreempt=3D1 in interrupt context. =C2=A0If you = use a spinlock > on such a thread, it will do the preemption at the point where you drop t= he > spinlock, this is bad in some circumstances. =C2=A0One example is the smp= _rendevous > case we are discussing here. This circumstances are further protected by another call to critical_enter(), by consumers or however upper layer calls. This is why, for example, spinlock_enter() does call critical_enter() even if it actually disables interrupts or why we disable preemption in other cases where the interrupts are already disabled. Attilio --=20 Peace can only be achieved by understanding - A. Einstein From owner-freebsd-current@FreeBSD.ORG Mon May 16 22:22: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 7B8581065670; Mon, 16 May 2011 22:22:39 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id 1CA2C8FC12; Mon, 16 May 2011 22:22:38 +0000 (UTC) Received: by yxl31 with SMTP id 31so2113350yxl.13 for ; Mon, 16 May 2011 15:22:38 -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 :content-transfer-encoding; bh=sEEGKaB60OhtBpbWkg18Mh4/aFvdGMGZQJMqmQVwt+k=; b=U9qrKfJDe75GxxEEsAg7M/H17AdvX2f8Z2xRjZyZ8NkSjrIfe+hIpPUWX1tLRj82DK SdudYZgK/ru5kvHmuBcu1Dw7NUZADPEMyvpwzuD2l11ik28RKguiS90GaiOckvnwzP3f NG22ygXevTZUmEF+ODYZdeZ02AXBA9MhHlmZ0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=Bld46MqwrPbpD8cTDu4l6eph7wkXr+M1OdwudU5T9nroE3xKR+ERGNBARo4lnjVNPu kEkK8kFbg6Bc1aiRqg9d7jqZH7Dtm4vi7b21xkNMqOJCMk2PfsLLyXQUnexkjM94sNtC zcEZi5dyGOM9M0w9H/2UJ23TjvlzlBegaU1Ns= MIME-Version: 1.0 Received: by 10.236.80.41 with SMTP id j29mr4543221yhe.214.1305582894873; Mon, 16 May 2011 14:54:54 -0700 (PDT) Sender: asmrookie@gmail.com Received: by 10.236.103.130 with HTTP; Mon, 16 May 2011 14:54:54 -0700 (PDT) In-Reply-To: <201105161738.53366.max@love2party.net> References: <4DCD357D.6000109@FreeBSD.org> <201105161630.44577.max@love2party.net> <201105161646.03338.jhb@freebsd.org> <201105161738.53366.max@love2party.net> Date: Mon, 16 May 2011 23:54:54 +0200 X-Google-Sender-Auth: YUynXOhpRrimBc3cZn_zGD9p2MM Message-ID: From: Attilio Rao To: Max Laier Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Andriy Gapon , FreeBSD current , Peter Grehan , neel@freebsd.org Subject: Re: proposed smp_rendezvous change 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, 16 May 2011 22:22:39 -0000 2011/5/16 Max Laier : > On Monday 16 May 2011 16:46:03 John Baldwin wrote: >> On Monday, May 16, 2011 4:30:44 pm Max Laier wrote: >> > On Monday 16 May 2011 14:21:27 John Baldwin wrote: >> > > Yes, we need to fix that. =C2=A0Humm, it doesn't preempt when you do= a >> > > critical_exit() though? =C2=A0Or do you use a hand-rolled critical e= xit that >> > > doesn't do a deferred preemption? >> > >> > Right now I just did a manual td_critnest++/--, but I guess ... >> >> Ah, ok, so you would "lose" a preemption. =C2=A0That's not really ideal. >> >> > > Actually, I'm curious how the spin unlock inside the IPI could yield >> > > the CPU. =C2=A0Oh, is rmlock doing a wakeup inside the IPI handler? = =C2=A0I >> > > guess that is ok as long as the critical_exit() just defers the >> > > preemption to the end of the IPI handler. >> > >> > ... the earliest point where it is safe to preempt is after doing the >> > >> > =C2=A0 =C2=A0atomic_add_int(&smp_rv_waiters[2], 1); >> > >> > so that we can start other IPIs again. =C2=A0However, since we don't a= ccept >> > new IPIs until we signal EOI in the MD code (on amd64), this might sti= ll >> > not be a good place to do the yield?!? >> >> Hmm, yeah, you would want to do the EOI before you yield. =C2=A0However,= we >> could actually move the EOI up before calling the MI code so long as we >> leave interrupts disabled for the duration of the handler (which we do). >> >> > The spin unlock boils down to a critical_exit() and unless we did a >> > critical_enter() at some point during the redenvouz setup, we will >> > yield() if we owepreempt. =C2=A0I'm not quite sure how that can happen= , but >> > it seems like there is a path that allows the scheduler to set it from= a >> > foreign CPU. >> >> No, it is only set on curthread by curthread. =C2=A0This is actually my = main >> question. =C2=A0I've no idea how this could happen unless the rmlock cod= e is >> actually triggering a wakeup or sched_add() in its rendezvous handler. >> >> I don't see anything in rm_cleanIPI() that would do that however. >> >> I wonder if your original issue was really fixed =C2=A0just by the first= patch >> you had which fixed the race in smp_rendezvous()? > > I found the stack that lead me to this patch in the first place: > > #0 =C2=A0sched_switch (td=3D0xffffff011a970000, newtd=3D0xffffff006e6784b= 0, > flags=3D4) at src/sys/kern/sched_ule.c:1939 > #1 =C2=A00xffffffff80285c7f in mi_switch (flags=3D6, newtd=3D0x0) at > src/sys/kern/kern_synch.c:475 > #2 =C2=A00xffffffff802a2cb3 in critical_exit () at src/sys/kern/kern_swit= ch.c:185 > #3 =C2=A00xffffffff80465807 in spinlock_exit () at > src/sys/amd64/amd64/machdep.c:1458 > #4 =C2=A00xffffffff8027adea in rm_cleanIPI (arg=3D) = at > src/sys/kern/kern_rmlock.c:180 > #5 =C2=A00xffffffff802b9887 in smp_rendezvous_action () at > src/sys/kern/subr_smp.c:402 > #6 =C2=A00xffffffff8045e2a4 in Xrendezvous () at > src/sys/amd64/amd64/apic_vector.S:235 > #7 =C2=A00xffffffff802a2c6e in critical_exit () at src/sys/kern/kern_swit= ch.c:179 > #8 =C2=A00xffffffff804365ba in uma_zfree_arg (zone=3D0xffffff009ff4b5a0, > item=3D0xffffff000f34cd40, udata=3D0xffffff000f34ce08) at > src/sys/vm/uma_core.c:2370 > . > . > . > > and now that I look at it again, it is clear that critical_exit() just is= n't > interrupt safe. =C2=A0I'm not sure how to fix that, yet ... but this: > > > =C2=A0 =C2=A0 =C2=A0 =C2=A0if (td->td_critnest =3D=3D 1) { > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0td->td_critnest = =3D 0; > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0if (td->td_owepree= mpt) { > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0td->td_critnest =3D 1; > > clearly doesn't work. I'm sorry if I didn't reply to the whole rendezvous thread, but as long as there is so many people taking care of it, I'll stay hidden in my corner. I just wanted to tell that I think you are misunderstanding what critical section is supposed to do. When an interrupt fires, it goes on the old "interrupt/kernel context" which means it has not a context of his own. That is the reason why we disable interrupts on spinlocks (or similar workaround for !x86 architectures) and this is why spinlocks are the only protection usable in code that runs in interrupt context. Preempting just means another thread will be scheduler in the middle of another thread execution path. This code is perfectly fine if you consider curthread won't be descheduled while it is executing. Attilio --=20 Peace can only be achieved by understanding - A. Einstein From owner-freebsd-current@FreeBSD.ORG Tue May 17 02:36: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 B087D106564A for ; Tue, 17 May 2011 02:36:07 +0000 (UTC) (envelope-from giffunip@tutopia.com) Received: from nm11-vm0.bullet.mail.sp2.yahoo.com (nm11-vm0.bullet.mail.sp2.yahoo.com [98.139.91.240]) by mx1.freebsd.org (Postfix) with SMTP id 8CD2F8FC14 for ; Tue, 17 May 2011 02:36:07 +0000 (UTC) Received: from [98.139.91.61] by nm11.bullet.mail.sp2.yahoo.com with NNFMP; 17 May 2011 02:36:07 -0000 Received: from [98.139.91.27] by tm1.bullet.mail.sp2.yahoo.com with NNFMP; 17 May 2011 02:36:07 -0000 Received: from [127.0.0.1] by omp1027.mail.sp2.yahoo.com with NNFMP; 17 May 2011 02:36:07 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 157208.55967.bm@omp1027.mail.sp2.yahoo.com Received: (qmail 27837 invoked by uid 60001); 17 May 2011 02:36:06 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1305599766; bh=cHrDj4P9K6i8i/y+mHtUl1xMQOEojLIQiIrtMnYWO2k=; h=Message-ID:X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=me/tkO3nnJVAkV7rr9S2w5yuVayfe3QG0qnNJZj+0QnrQqDs5d/OISkT62vvcHWVzDncIdsmd3E37ENpv1hSUsu3HiYSthsRl7Ii/fyGXQzf28iAbt1OmjlPTNssjCK1hcosw/eI6NS8P9DebIchaGK0alIikvGVDaCmOsnit40= Message-ID: <706617.91542.qm@web113511.mail.gq1.yahoo.com> X-YMail-OSG: qc5tl9cVM1mgPYsEjtw9pmMRYFeA8aBI6ydmNPKs3LNm_UF NzURoOYgKPbYcNfc.KuwGDWSnb2dIP4B2ZTvpMpPl_96u3Raf5QanmUSVMRM cfNz5yoMyK8ZKiJGjbxboHVS83gMLO3r6jDCpxUHkYrmDj7RA.ByJW.Mv0X3 dOV_0jD3V0qj30S3BL593crBVxaI3N8oaKEd3RUbZG1pYAxCeZ1k11.s18nU oHqgQhl_E29Vs2HJJnBvsfO791A2yz3k.6FtvHYDfl9vQbgTyDB8hm2MITCh u613DGSqkl7VW_qzrYmdeKp4Pl228XaVqfEHyPAygEf.E1kaDC.tUW5X7OrO aQUEnXsVbfXqDpZ31c9W8f5rhTNZyWXwGQ6Rdd03nW2MbC4d0b2E9MPYXPyt 2ivXccazU6l8ZPtPc97IT94ipy9PaXW3oVp5Y.v.fPkHI6ZMkpTeGDXJZqhQ qCzvTH58LcGl2B_iyERQEO7twJyeyOg7BjqZenVlVUG_ELagZYx7YcqPmlJf JZ_tWHoMClIchoyRi7WS7aSLNedbjjzPgPTCgtNLYpdfVSDXXbj29V4Xf5MY 3 Received: from [200.118.158.177] by web113511.mail.gq1.yahoo.com via HTTP; Mon, 16 May 2011 19:36:06 PDT X-RocketYMMF: giffunip X-Mailer: YahooMailClassic/14.0.1 YahooMailWebService/0.8.111.303096 Date: Mon, 16 May 2011 19:36:06 -0700 (PDT) From: "Pedro F. Giffuni" To: freebsd-current@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailman-Approved-At: Tue, 17 May 2011 02:40:28 +0000 Cc: Subject: Anyone that can check a dtrace bug/fix? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: giffunip@tutopia.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, 17 May 2011 02:36:07 -0000 Hello; I was checking out some dtrace links and I noticed a bug found by Bryan Cantrill here: http://dtrace.org/blogs/bmc/2011/03/09/when-magic-collides/ the patch is rather easy and looks like it applies to our code (i386 and amd64) too: http://dtrace.org/resources/bmc/dtrace-signal.patch I don't really use Dtrace and the bug itself is pretty rare to bitten by so I am not the right guy to even PR it. While here, I should also mention that the Joyent llquantize patch is here: http://dtrace.org/resources/bmc/dtrace-llquantize.patch And if you are curious on what the Joyent/dtrace guys are doing lately, you can watch about 2 Hrs of video here: http://www.ustream.tv/recorded/12123446 cheers, Pedro. cheers, Pedro. From owner-freebsd-current@FreeBSD.ORG Tue May 17 04:16: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 5F95F1065670 for ; Tue, 17 May 2011 04:16:31 +0000 (UTC) (envelope-from tiredashell@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 EAF5C8FC0A for ; Tue, 17 May 2011 04:16:30 +0000 (UTC) Received: by wyf23 with SMTP id 23so101594wyf.13 for ; Mon, 16 May 2011 21:16:29 -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=lPz5R/XWjWycg3K3dbkKa26JiuVHUmmmtKIvK7xppnY=; b=sstZuqwG2042eHKFmyvc2o+iuFBcH2W2QPHhPIAyLJX1GlZYp2r8cQiYDFS1sQxbWN sczARlTWCkAhtrbPnvwl/wADYEvS1h9/izbMgjj08g5ZukPbTgxLuesVvAaLFo3Y0K0A S9ZaWwRPfLjXBJZRl+p+QCOCUwNTn3jKU0Pe0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=M8Go2kQnYyT4jtvHbLMqs4dKRR4lkMtg1B6QJgODZi0to7FIwDNnYfWTsBjK51GLeP 5Is8kVUwgXDY0CWfipwTM5LQiUE0hJ1fjTWpivjKJjevb+0ulE8TZGQBnX8OwVmW+bOE 1tteDi+a7+gUg9hiNEd6EAcGB+m6nTFgcQ/Iw= MIME-Version: 1.0 Received: by 10.216.37.78 with SMTP id x56mr133542wea.27.1305603974698; Mon, 16 May 2011 20:46:14 -0700 (PDT) Received: by 10.216.28.146 with HTTP; Mon, 16 May 2011 20:46:14 -0700 (PDT) Date: Mon, 16 May 2011 23:46:14 -0400 Message-ID: From: "tiredashell@gmail.com" To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: Boot halts on Thinkpad X220 (Sandy Bridge) 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, 17 May 2011 04:16:31 -0000 On May 16, 2:57 pm, dieterich.johan...@googlemail.com (Johannes Dieterich) wrote: > > The i386 image as of 11/04/2011 of Nathan Whitehorn booted into the live > system without problems. The hint was not needed. Yep, my T420 boots the i386 version just fine, so it definitely looks like an amd64 issue. From owner-freebsd-current@FreeBSD.ORG Tue May 17 07:19: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 9F4BF1065672; Tue, 17 May 2011 07:19:15 +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 7F0A88FC17; Tue, 17 May 2011 07:19:14 +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 KAA17067; Tue, 17 May 2011 10:19:12 +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 1QMEYi-0006yO-6y; Tue, 17 May 2011 10:19:12 +0300 Message-ID: <4DD2216F.6080908@FreeBSD.org> Date: Tue, 17 May 2011 10:19:11 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.17) Gecko/20110503 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Hans Petter Selasky References: <201104051321.56319.hselasky@freebsd.org> <201104060933.47350.hselasky@freebsd.org> <4D9C68CF.1060101@FreeBSD.org> <201104061528.13220.hselasky@freebsd.org> In-Reply-To: <201104061528.13220.hselasky@freebsd.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "freebsd-current@FreeBSD.org" , freebsd-usb@FreeBSD.org 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, 17 May 2011 07:19:15 -0000 on 06/04/2011 16:28 Hans Petter Selasky said the following: > > Run a kernel test compile including all modules. If that's OK it should be > fine. So I am going to commit this. If it breaks anything for anyone and the problem would not be really trivial, the I'll just revert the change. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Tue May 17 08:03: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 F273A1065674; Tue, 17 May 2011 08:03:40 +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 7B7018FC13; Tue, 17 May 2011 08:03:39 +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 LAA18348; Tue, 17 May 2011 11:03:38 +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 1QMFFh-00070m-PJ; Tue, 17 May 2011 11:03:37 +0300 Message-ID: <4DD22BD9.6070504@FreeBSD.org> Date: Tue, 17 May 2011 11:03:37 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.17) Gecko/20110503 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: John Baldwin References: <4DCD357D.6000109@FreeBSD.org> <201105161421.27665.jhb@freebsd.org> <4DD17AB3.1070606@FreeBSD.org> <201105161609.21898.jhb@freebsd.org> In-Reply-To: <201105161609.21898.jhb@freebsd.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Max Laier , FreeBSD current , neel@FreeBSD.org, Peter Grehan Subject: Re: proposed smp_rendezvous change 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, 17 May 2011 08:03:41 -0000 on 16/05/2011 23:09 John Baldwin said the following: > On Monday, May 16, 2011 3:27:47 pm Andriy Gapon wrote: >> on 16/05/2011 21:21 John Baldwin said the following: >>> How about this: >> ... >>> /* >>> * Shared mutex to restrict busywaits between smp_rendezvous() and >>> @@ -311,39 +312,62 @@ restart_cpus(cpumask_t map) >>> void >>> smp_rendezvous_action(void) >>> { >>> - void* local_func_arg = smp_rv_func_arg; >>> - void (*local_setup_func)(void*) = smp_rv_setup_func; >>> - void (*local_action_func)(void*) = smp_rv_action_func; >>> - void (*local_teardown_func)(void*) = smp_rv_teardown_func; >>> + void *local_func_arg; >>> + void (*local_setup_func)(void*); >>> + void (*local_action_func)(void*); >>> + void (*local_teardown_func)(void*); >>> + int generation; >>> >>> /* Ensure we have up-to-date values. */ >>> atomic_add_acq_int(&smp_rv_waiters[0], 1); >>> while (smp_rv_waiters[0] < smp_rv_ncpus) >>> cpu_spinwait(); >>> >>> - /* setup function */ >>> + /* Fetch rendezvous parameters after acquire barrier. */ >>> + local_func_arg = smp_rv_func_arg; >>> + local_setup_func = smp_rv_setup_func; >>> + local_action_func = smp_rv_action_func; >>> + local_teardown_func = smp_rv_teardown_func; >> >> I want to ask once again - please pretty please convince me that the above >> cpu_spinwait() loop is really needed and, by extension, that the assignments >> should be moved behind it. >> Please :) > > Well, moving the assignments down is a style fix for one, and we can always > remove the first rendezvous as a follow up if desired. OK, makes sense. > However, suppose you have an arch where sending an IPI is not a barrier > (this seems unlikely). In that case, the atomic_add_acq_int() will not > succeed (and return) until it has seen the earlier write by the CPU > initiating the rendezvous to clear smp_rv_waiters[0] to zero. The actual > spin on the smp_rv_waiters[] value is not strictly necessary however and On this below. > is probably just cut and pasted to match the other uses of values in > the smp_rv_waiters[] array. > > (atomic_add_acq_int() could spin on architectures where it is implemented > using compare-and-swap (e.g. sparc64) or locked-load conditional-store (e.g. > Alpha).) When you say "not strictly necessary", do you mean "not necessary"? If you do not mean that, then when could it be (non-strictly) necessary? :) Couldn't [Shouldn't] the whole: >>> /* Ensure we have up-to-date values. */ >>> atomic_add_acq_int(&smp_rv_waiters[0], 1); >>> while (smp_rv_waiters[0] < smp_rv_ncpus) >>> cpu_spinwait(); be just replaced with: rmb(); Or a proper MI function that does just a read memory barrier, if rmb() is not that. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Tue May 17 08:37:27 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 495A21065670 for ; Tue, 17 May 2011 08:37:27 +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 01C428FC1A for ; Tue, 17 May 2011 08:37:26 +0000 (UTC) Received: by vxc34 with SMTP id 34so226564vxc.13 for ; Tue, 17 May 2011 01:37:26 -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:content-type; bh=S6mdoTOnlyMctoqusD+kvhLuHpwkgiMxfBbMUekCLLA=; b=MkDPr7/TRvKCY5bkvsEgW+Y06EIOJDDmXiUR7soHnesUgDL8/ABlxpHyoLPMNDzFnm SUfvV63IJoFjbPNkwyZuWdT2g/bi2w4O2fO7uBw0wo2Yz/5n74+Q3FCU+1Sfh++TlvvN bd5WrwEu+4Tek5PFlF+dJSwm7gfJmvdAP3PfA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=yG0q/eX3FAyHtIc815byGbyshOhtIDq5u/++VApifY7wNHTEtcTVG5JWLwXzko4I/u fOWYU9Q+qUZxvEkFdnfaLNdvS/RrddG2c44BmT+nSx2pnAxdGBgATEfNXbwNCLzYLTpm QBtoNzj6QttK9cLVEohqtjBH7QujOHYUMMGxE= MIME-Version: 1.0 Received: by 10.52.92.45 with SMTP id cj13mr503299vdb.105.1305621446270; Tue, 17 May 2011 01:37:26 -0700 (PDT) Received: by 10.52.159.73 with HTTP; Tue, 17 May 2011 01:37:26 -0700 (PDT) In-Reply-To: References: Date: Tue, 17 May 2011 09:37:26 +0100 Message-ID: From: "Sevan / Venture37" To: freebsd-current@freebsd.org Content-Type: text/plain; charset=UTF-8 Subject: Re: Boot halts on Thinkpad X220 (Sandy Bridge) 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, 17 May 2011 08:37:27 -0000 Hiya If it's any help, I tried booting OpenBSD-Current on a ThinkPad X220 yesterday & it worked just fine (I forget to take my copy of 8-STABLE snapshot which I downloaded from the allbsd site, otherwise I would've post that too) dmesg: http://www.nycbug.org/?NAV=dmesgd;f_dmesg=;f_bsd=;f_nick=;f_descr=;dmesgid=2068#2068 Pcidump -vxx output: http://pastebin.com/KqVMcqza acpidump & Xorg.log: http://www.sendspace.com/file/qtmkte Sevan / Venture37 From owner-freebsd-current@FreeBSD.ORG Tue May 17 11:56: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 23C0A106566B; Tue, 17 May 2011 11:56:08 +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 EC7808FC08; Tue, 17 May 2011 11:56:07 +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 8A7CC46B0A; Tue, 17 May 2011 07:56:07 -0400 (EDT) Received: from jhbmac.hudson-trading.com (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 172D68A04F; Tue, 17 May 2011 07:56:07 -0400 (EDT) Message-ID: <4DD26256.2070008@FreeBSD.org> Date: Tue, 17 May 2011 07:56:06 -0400 From: John Baldwin User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Andriy Gapon References: <4DCD357D.6000109@FreeBSD.org> <201105161421.27665.jhb@freebsd.org> <4DD17AB3.1070606@FreeBSD.org> <201105161609.21898.jhb@freebsd.org> <4DD22BD9.6070504@FreeBSD.org> In-Reply-To: <4DD22BD9.6070504@FreeBSD.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 (bigwig.baldwin.cx); Tue, 17 May 2011 07:56:07 -0400 (EDT) Cc: Max Laier , FreeBSD current , neel@FreeBSD.org, Peter Grehan Subject: Re: proposed smp_rendezvous change 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, 17 May 2011 11:56:08 -0000 On 5/17/11 4:03 AM, Andriy Gapon wrote: > on 16/05/2011 23:09 John Baldwin said the following: >> is probably just cut and pasted to match the other uses of values in >> the smp_rv_waiters[] array. >> >> (atomic_add_acq_int() could spin on architectures where it is implemented >> using compare-and-swap (e.g. sparc64) or locked-load conditional-store (e.g. >> Alpha).) > > > When you say "not strictly necessary", do you mean "not necessary"? > If you do not mean that, then when could it be (non-strictly) necessary? :) > > Couldn't [Shouldn't] the whole: > >>>> /* Ensure we have up-to-date values. */ >>>> atomic_add_acq_int(&smp_rv_waiters[0], 1); >>>> while (smp_rv_waiters[0]< smp_rv_ncpus) >>>> cpu_spinwait(); > > be just replaced with: > > rmb(); > > Or a proper MI function that does just a read memory barrier, if rmb() is not that. No, you could replace it with: atomic_add_acq_int(&smp_rv_waiters[0], 1); The key being that atomic_add_acq_int() will block (either in hardware or software) until it can safely perform the atomic operation. That means waiting until the write to set smp_rv_waiters[0] to 0 by the rendezvous initiator is visible to the current CPU. On some platforms a write by one CPU may not post instantly to other CPUs (e.g. it may sit in a store buffer). That is fine so long as an attempt to update that value atomically (using cas or a conditional-store, etc.) fails. For those platforms, the atomic(9) API is required to spin until it succeeds. This is why the mtx code spins if it can't set MTX_CONTESTED for example. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Tue May 17 12:16: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 45D1C1065672; Tue, 17 May 2011 12:16:33 +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 E38948FC14; Tue, 17 May 2011 12:16:32 +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 95E3246B03; Tue, 17 May 2011 08:16:32 -0400 (EDT) Received: from jhbmac.hudson-trading.com (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 2A6A68A04F; Tue, 17 May 2011 08:16:32 -0400 (EDT) Message-ID: <4DD26720.3000001@FreeBSD.org> Date: Tue, 17 May 2011 08:16:32 -0400 From: John Baldwin User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Max Laier References: <4DCD357D.6000109@FreeBSD.org> <201105161738.53366.max@love2party.net> <201105161805.51188.max@love2party.net> In-Reply-To: <201105161805.51188.max@love2party.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Tue, 17 May 2011 08:16:32 -0400 (EDT) Cc: neel@freebsd.org, Andriy Gapon , Attilio Rao , FreeBSD current , Stephan Uphoff , Peter Grehan Subject: Re: proposed smp_rendezvous change 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, 17 May 2011 12:16:33 -0000 On 5/16/11 6:05 PM, Max Laier wrote: > On Monday 16 May 2011 17:54:54 Attilio Rao wrote: >> 2011/5/16 Max Laier: >>> On Monday 16 May 2011 16:46:03 John Baldwin wrote: >>>> On Monday, May 16, 2011 4:30:44 pm Max Laier wrote: >>>>> On Monday 16 May 2011 14:21:27 John Baldwin wrote: >>>>>> Yes, we need to fix that. Humm, it doesn't preempt when you do a >>>>>> critical_exit() though? Or do you use a hand-rolled critical exit >>>>>> that doesn't do a deferred preemption? >>>>> >>>>> Right now I just did a manual td_critnest++/--, but I guess ... >>>> >>>> Ah, ok, so you would "lose" a preemption. That's not really ideal. >>>> >>>>>> Actually, I'm curious how the spin unlock inside the IPI could yield >>>>>> the CPU. Oh, is rmlock doing a wakeup inside the IPI handler? I >>>>>> guess that is ok as long as the critical_exit() just defers the >>>>>> preemption to the end of the IPI handler. >>>>> >>>>> ... the earliest point where it is safe to preempt is after doing the >>>>> >>>>> atomic_add_int(&smp_rv_waiters[2], 1); >>>>> >>>>> so that we can start other IPIs again. However, since we don't accept >>>>> new IPIs until we signal EOI in the MD code (on amd64), this might >>>>> still not be a good place to do the yield?!? >>>> >>>> Hmm, yeah, you would want to do the EOI before you yield. However, we >>>> could actually move the EOI up before calling the MI code so long as we >>>> leave interrupts disabled for the duration of the handler (which we do). >>>> >>>>> The spin unlock boils down to a critical_exit() and unless we did a >>>>> critical_enter() at some point during the redenvouz setup, we will >>>>> yield() if we owepreempt. I'm not quite sure how that can happen, but >>>>> it seems like there is a path that allows the scheduler to set it from >>>>> a foreign CPU. >>>> >>>> No, it is only set on curthread by curthread. This is actually my main >>>> question. I've no idea how this could happen unless the rmlock code is >>>> actually triggering a wakeup or sched_add() in its rendezvous handler. >>>> >>>> I don't see anything in rm_cleanIPI() that would do that however. >>>> >>>> I wonder if your original issue was really fixed just by the first >>>> patch you had which fixed the race in smp_rendezvous()? >>> >>> I found the stack that lead me to this patch in the first place: >>> >>> #0 sched_switch (td=0xffffff011a970000, newtd=0xffffff006e6784b0, >>> flags=4) at src/sys/kern/sched_ule.c:1939 >>> #1 0xffffffff80285c7f in mi_switch (flags=6, newtd=0x0) at >>> src/sys/kern/kern_synch.c:475 >>> #2 0xffffffff802a2cb3 in critical_exit () at >>> src/sys/kern/kern_switch.c:185 #3 0xffffffff80465807 in spinlock_exit >>> () at >>> src/sys/amd64/amd64/machdep.c:1458 >>> #4 0xffffffff8027adea in rm_cleanIPI (arg=) at >>> src/sys/kern/kern_rmlock.c:180 >>> #5 0xffffffff802b9887 in smp_rendezvous_action () at >>> src/sys/kern/subr_smp.c:402 >>> #6 0xffffffff8045e2a4 in Xrendezvous () at >>> src/sys/amd64/amd64/apic_vector.S:235 >>> #7 0xffffffff802a2c6e in critical_exit () at >>> src/sys/kern/kern_switch.c:179 #8 0xffffffff804365ba in uma_zfree_arg >>> (zone=0xffffff009ff4b5a0, item=0xffffff000f34cd40, >>> udata=0xffffff000f34ce08) at >>> src/sys/vm/uma_core.c:2370 >>> . >>> . >>> . >>> >>> and now that I look at it again, it is clear that critical_exit() just >>> isn't interrupt safe. I'm not sure how to fix that, yet ... but this: >>> >>> >>> if (td->td_critnest == 1) { >>> td->td_critnest = 0; >>> if (td->td_owepreempt) { >>> td->td_critnest = 1; >>> >>> clearly doesn't work. >> >> I'm sorry if I didn't reply to the whole rendezvous thread, but as >> long as there is so many people taking care of it, I'll stay hidden in >> my corner. >> >> I just wanted to tell that I think you are misunderstanding what >> critical section is supposed to do. >> >> When an interrupt fires, it goes on the old "interrupt/kernel context" >> which means it has not a context of his own. That is the reason why we >> disable interrupts on spinlocks (or similar workaround for !x86 >> architectures) and this is why spinlocks are the only protection >> usable in code that runs in interrupt context. >> >> Preempting just means another thread will be scheduler in the middle >> of another thread execution path. >> >> This code is perfectly fine if you consider curthread won't be >> descheduled while it is executing. > > Well, no - it is not. With this you can end up with a curthread that has > td_critnest=0 and td_owepreempt=1 in interrupt context. If you use a spinlock > on such a thread, it will do the preemption at the point where you drop the > spinlock, this is bad in some circumstances. One example is the smp_rendevous > case we are discussing here. Yes, the 'owepreempt' flag can leak because we allow it to be set while td_critnest is 0. That is the problem, and I think we added this as an optimization in the last round of changes to this routine to avoid excessive context switches. However, I think we will just have to revert that optimization and prevent that state from occurring. Hmm, the log message for the change said it was to avoid races. http://svnweb.freebsd.org/base?view=revision&revision=144777 That is what introduced the bug of mixing those two states. Hmmm, the reason for moving the td_critnest == 0 up according to my old e-mails was to avoid a problem with losing preemptions. I think the best way to fix this is to clear owepreempt earlier while td_critnest is still 1 and cache it locally in critical_exit(). So something like this: Index: kern/sched_ule.c =================================================================== --- kern/sched_ule.c (revision 221536) +++ kern/sched_ule.c (working copy) @@ -1785,7 +1785,7 @@ td->td_oncpu = NOCPU; if (!(flags & SW_PREEMPT)) td->td_flags &= ~TDF_NEEDRESCHED; - td->td_owepreempt = 0; + MPASS(td->td_owepreempt == 0); tdq->tdq_switchcnt++; /* * The lock pointer in an idle thread should never change. Reset it Index: kern/kern_switch.c =================================================================== --- kern/kern_switch.c (revision 221536) +++ kern/kern_switch.c (working copy) @@ -192,15 +192,22 @@ critical_exit(void) { struct thread *td; - int flags; + int flags, owepreempt; td = curthread; KASSERT(td->td_critnest != 0, ("critical_exit: td_critnest == 0")); if (td->td_critnest == 1) { + owepreempt = td->td_owepreempt; + td->td_owepreempt = 0; + /* + * XXX: Should move compiler_memory_barrier() from + * rmlock to a header. + */ + __asm __volatile("":::"memory"); td->td_critnest = 0; - if (td->td_owepreempt) { + if (owepreempt) { td->td_critnest = 1; thread_lock(td); td->td_critnest--; Index: kern/kern_synch.c =================================================================== --- kern/kern_synch.c (revision 221536) +++ kern/kern_synch.c (working copy) @@ -400,9 +400,7 @@ if (!TD_ON_LOCK(td) && !TD_IS_RUNNING(td)) mtx_assert(&Giant, MA_NOTOWNED); #endif - KASSERT(td->td_critnest == 1 || (td->td_critnest == 2 && - (td->td_owepreempt) && (flags & SW_INVOL) != 0 && - newtd == NULL) || panicstr, + KASSERT(td->td_critnest == 1 || panicstr, ("mi_switch: switch in a critical section")); KASSERT((flags & (SW_INVOL | SW_VOL)) != 0, ("mi_switch: switch must be voluntary or involuntary")); Index: kern/sched_4bsd.c =================================================================== --- kern/sched_4bsd.c (revision 221536) +++ kern/sched_4bsd.c (working copy) @@ -947,7 +947,7 @@ td->td_lastcpu = td->td_oncpu; if (!(flags & SW_PREEMPT)) td->td_flags &= ~TDF_NEEDRESCHED; - td->td_owepreempt = 0; + MPASS(td->td_owepreempt == 0); td->td_oncpu = NOCPU; /* Hmm, I'm also not sure if I really need the compiler barrier since td_owepreempt and td_critnest are marked volatile? -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Tue May 17 13:44: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 19ED91065728 for ; Tue, 17 May 2011 13:44:18 +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 E12178FC21 for ; Tue, 17 May 2011 13:44:17 +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 8DB8646B0A; Tue, 17 May 2011 09:44:17 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 26AB48A050; Tue, 17 May 2011 09:44:17 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Date: Tue, 17 May 2011 09:44:16 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110325; KDE/4.5.5; amd64; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201105170944.16261.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Tue, 17 May 2011 09:44:17 -0400 (EDT) Cc: "deeptech71@gmail.com" Subject: Re: pcib allocation failure 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, 17 May 2011 13:44:18 -0000 On Saturday, May 14, 2011 12:27:59 pm deeptech71@gmail.com wrote: > pcib1: at device 1.0 on pci0 > pcib1: failed to allocate initial prefetch window: 0xd0000000-0xfaffffff > > the console output is cut shortly after those 2 lines (but the machine > seems to continue booting, as i have reset'd the machine, after which > "/" was found to be improperly dismounted). So it actually boots fine, but video output breaks during the boot? Does it ever come back or it is permanently broken until reboot? Your BIOS is actually violating the PCI spec by assigning the same resource ranges to two devices on the same PCI bus (the hostb device and the AGP bridge device). It's also doing so unnecessarily. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Tue May 17 13:46:38 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 4BA05106568A; Tue, 17 May 2011 13:46:38 +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 F002D8FC12; Tue, 17 May 2011 13:46:36 +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 QAA27157; Tue, 17 May 2011 16:46:35 +0300 (EEST) (envelope-from avg@FreeBSD.org) Message-ID: <4DD27C3A.3040509@FreeBSD.org> Date: Tue, 17 May 2011 16:46:34 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.17) Gecko/20110504 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: John Baldwin References: <4DCD357D.6000109@FreeBSD.org> <201105161421.27665.jhb@freebsd.org> <4DD17AB3.1070606@FreeBSD.org> <201105161609.21898.jhb@freebsd.org> <4DD22BD9.6070504@FreeBSD.org> <4DD26256.2070008@FreeBSD.org> In-Reply-To: <4DD26256.2070008@FreeBSD.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Max Laier , FreeBSD current , neel@FreeBSD.org, Peter Grehan Subject: Re: proposed smp_rendezvous change 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, 17 May 2011 13:46:38 -0000 on 17/05/2011 14:56 John Baldwin said the following: > On 5/17/11 4:03 AM, Andriy Gapon wrote: >> Couldn't [Shouldn't] the whole: >> >>>>> /* Ensure we have up-to-date values. */ >>>>> atomic_add_acq_int(&smp_rv_waiters[0], 1); >>>>> while (smp_rv_waiters[0]< smp_rv_ncpus) >>>>> cpu_spinwait(); >> >> be just replaced with: >> >> rmb(); >> >> Or a proper MI function that does just a read memory barrier, if rmb() is not that. > > No, you could replace it with: > > atomic_add_acq_int(&smp_rv_waiters[0], 1); What about (void)atomic_load_acq(&smp_rv_waiters[0]); In my opinion that should ensure that the hardware must post the latest value from a master CPU to memory of smp_rv_waiters[0] and a slave CPU gets it from there. And also, because of memory barriers inserted by store_rel on the master CPU and load_acq on the slave CPU, the latest values of all other smp_rv_* fields should become visible to the slave CPU. > The key being that atomic_add_acq_int() will block (either in hardware or > software) until it can safely perform the atomic operation. That means waiting > until the write to set smp_rv_waiters[0] to 0 by the rendezvous initiator is > visible to the current CPU. > > On some platforms a write by one CPU may not post instantly to other CPUs (e.g. it > may sit in a store buffer). That is fine so long as an attempt to update that > value atomically (using cas or a conditional-store, etc.) fails. For those > platforms, the atomic(9) API is required to spin until it succeeds. > > This is why the mtx code spins if it can't set MTX_CONTESTED for example. > Thank you for the great explanation! Taking sparc64 as an example, I think that atomic_load_acq uses a degenerate cas call, which should take care of hardware synchronization. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Tue May 17 13:58: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 790731065672; Tue, 17 May 2011 13:58:18 +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 35D058FC0A; Tue, 17 May 2011 13:58:18 +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 C2BD646B06; Tue, 17 May 2011 09:58:17 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 557528A04F; Tue, 17 May 2011 09:58:17 -0400 (EDT) From: John Baldwin To: Andriy Gapon Date: Tue, 17 May 2011 09:58:16 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110325; KDE/4.5.5; amd64; ; ) References: <4DCD357D.6000109@FreeBSD.org> <4DD26256.2070008@FreeBSD.org> <4DD27C3A.3040509@FreeBSD.org> In-Reply-To: <4DD27C3A.3040509@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201105170958.16847.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Tue, 17 May 2011 09:58:17 -0400 (EDT) Cc: Max Laier , FreeBSD current , neel@freebsd.org, Peter Grehan Subject: Re: proposed smp_rendezvous change 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, 17 May 2011 13:58:18 -0000 On Tuesday, May 17, 2011 9:46:34 am Andriy Gapon wrote: > on 17/05/2011 14:56 John Baldwin said the following: > > On 5/17/11 4:03 AM, Andriy Gapon wrote: > >> Couldn't [Shouldn't] the whole: > >> > >>>>> /* Ensure we have up-to-date values. */ > >>>>> atomic_add_acq_int(&smp_rv_waiters[0], 1); > >>>>> while (smp_rv_waiters[0]< smp_rv_ncpus) > >>>>> cpu_spinwait(); > >> > >> be just replaced with: > >> > >> rmb(); > >> > >> Or a proper MI function that does just a read memory barrier, if rmb() is not that. > > > > No, you could replace it with: > > > > atomic_add_acq_int(&smp_rv_waiters[0], 1); > > What about > (void)atomic_load_acq(&smp_rv_waiters[0]); > > In my opinion that should ensure that the hardware must post the latest value from > a master CPU to memory of smp_rv_waiters[0] and a slave CPU gets it from there. > And also, because of memory barriers inserted by store_rel on the master CPU and > load_acq on the slave CPU, the latest values of all other smp_rv_* fields should > become visible to the slave CPU. No, it doesn't quite work that way. It wouldn't work on Alpha for example. All load_acq is a load with a memory barrier to order other loads after it. It is still free to load stale data. Only a read-modify-write operation would actually block until it could access an up-to-date value. > > > The key being that atomic_add_acq_int() will block (either in hardware or > > software) until it can safely perform the atomic operation. That means waiting > > until the write to set smp_rv_waiters[0] to 0 by the rendezvous initiator is > > visible to the current CPU. > > > > On some platforms a write by one CPU may not post instantly to other CPUs (e.g. it > > may sit in a store buffer). That is fine so long as an attempt to update that > > value atomically (using cas or a conditional-store, etc.) fails. For those > > platforms, the atomic(9) API is required to spin until it succeeds. > > > > This is why the mtx code spins if it can't set MTX_CONTESTED for example. > > > > Thank you for the great explanation! > Taking sparc64 as an example, I think that atomic_load_acq uses a degenerate cas > call, which should take care of hardware synchronization. sparc64's load_acq() is stronger than the MI effect of load_acq(). On ia64 which uses ld.acq or Alpha (originally) which uses a membar and simple load, the guarantees are only what I stated above (and would not be sufficient). Note that Alpha borrowed heavily from MIPS, and the MIPS atomic implementation is mostly identical to the old Alpha one (using conditional stores, etc.). The MIPS atomic_load_acq(): #define ATOMIC_STORE_LOAD(WIDTH) \ static __inline uint##WIDTH##_t \ atomic_load_acq_##WIDTH(__volatile uint##WIDTH##_t *p) \ { \ uint##WIDTH##_t v; \ \ v = *p; \ mips_sync(); \ return (v); \ } \ -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Tue May 17 14:34:45 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 DA25A106564A; Tue, 17 May 2011 14:34:45 +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 8A2EF8FC12; Tue, 17 May 2011 14:34:44 +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 RAA27833; Tue, 17 May 2011 17:34:42 +0300 (EEST) (envelope-from avg@FreeBSD.org) Message-ID: <4DD28781.6050002@FreeBSD.org> Date: Tue, 17 May 2011 17:34:41 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.17) Gecko/20110504 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: John Baldwin References: <4DCD357D.6000109@FreeBSD.org> <4DD26256.2070008@FreeBSD.org> <4DD27C3A.3040509@FreeBSD.org> <201105170958.16847.jhb@freebsd.org> In-Reply-To: <201105170958.16847.jhb@freebsd.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Max Laier , FreeBSD current , neel@FreeBSD.org, Peter Grehan Subject: Re: proposed smp_rendezvous change 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, 17 May 2011 14:34:45 -0000 on 17/05/2011 16:58 John Baldwin said the following: > No, it doesn't quite work that way. It wouldn't work on Alpha for example. > > All load_acq is a load with a memory barrier to order other loads after it. > It is still free to load stale data. Only a read-modify-write operation > would actually block until it could access an up-to-date value. Hmm, ok. How about atomic_add_acq_int(&smp_rv_waiters[0], 0) ? :-) Or an equivalent MI action that doesn't actually change smp_rv_waiters[0] value, if there could be any. Maybe explicit atomic_cmpset_acq_int(&smp_rv_waiters[0], 0, 0) ? You see at what I am getting? >>> The key being that atomic_add_acq_int() will block (either in hardware or >>> software) until it can safely perform the atomic operation. That means waiting >>> until the write to set smp_rv_waiters[0] to 0 by the rendezvous initiator is >>> visible to the current CPU. >>> >>> On some platforms a write by one CPU may not post instantly to other CPUs (e.g. it >>> may sit in a store buffer). That is fine so long as an attempt to update that >>> value atomically (using cas or a conditional-store, etc.) fails. For those >>> platforms, the atomic(9) API is required to spin until it succeeds. >>> >>> This is why the mtx code spins if it can't set MTX_CONTESTED for example. >>> >> >> Thank you for the great explanation! >> Taking sparc64 as an example, I think that atomic_load_acq uses a degenerate cas >> call, which should take care of hardware synchronization. > > sparc64's load_acq() is stronger than the MI effect of load_acq(). On ia64 Oh, well, my expectation was that MI effect of atomic_load (emphasis on atomic_) was to get a non-stale value. > which uses ld.acq or Alpha (originally) which uses a membar and simple load, > the guarantees are only what I stated above (and would not be sufficient). > > Note that Alpha borrowed heavily from MIPS, and the MIPS atomic implementation > is mostly identical to the old Alpha one (using conditional stores, etc.). > > The MIPS atomic_load_acq(): > > #define ATOMIC_STORE_LOAD(WIDTH) \ > static __inline uint##WIDTH##_t \ > atomic_load_acq_##WIDTH(__volatile uint##WIDTH##_t *p) \ > { \ > uint##WIDTH##_t v; \ > \ > v = *p; \ > mips_sync(); \ > return (v); \ > } \ I should have checked this myself. Thank you for patiently explaining these things to me. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Tue May 17 14:43:46 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BB39E106566C; Tue, 17 May 2011 14:43:46 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 85D878FC12; Tue, 17 May 2011 14:43:46 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.4) with ESMTP id p4HEhjl6098524; Tue, 17 May 2011 10:43:45 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.4/Submit) id p4HEhjkA098523; Tue, 17 May 2011 14:43:45 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 17 May 2011 14:43:45 GMT Message-Id: <201105171443.p4HEhjkA098523@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on arm/arm X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 May 2011 14:43:46 -0000 TB --- 2011-05-17 13:50:00 - tinderbox 2.7 running on freebsd-current.sentex.ca TB --- 2011-05-17 13:50:00 - starting HEAD tinderbox run for arm/arm TB --- 2011-05-17 13:50:00 - cleaning the object tree TB --- 2011-05-17 13:50:16 - cvsupping the source tree TB --- 2011-05-17 13:50:16 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/arm/arm/supfile TB --- 2011-05-17 13:51:03 - building world TB --- 2011-05-17 13:51:03 - MAKEOBJDIRPREFIX=/obj TB --- 2011-05-17 13:51:03 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-05-17 13:51:03 - TARGET=arm TB --- 2011-05-17 13:51:03 - TARGET_ARCH=arm TB --- 2011-05-17 13:51:03 - TZ=UTC TB --- 2011-05-17 13:51:03 - __MAKE_CONF=/dev/null TB --- 2011-05-17 13:51:03 - cd /src TB --- 2011-05-17 13:51:03 - /usr/bin/make -B buildworld >>> World build started on Tue May 17 13:51:03 UTC 2011 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Tue May 17 14:43:07 UTC 2011 TB --- 2011-05-17 14:43:07 - WARNING: no kernel config for LINT TB --- 2011-05-17 14:43:07 - cd /src/sys/arm/conf TB --- 2011-05-17 14:43:07 - /usr/sbin/config -m AVILA TB --- 2011-05-17 14:43:07 - building AVILA kernel TB --- 2011-05-17 14:43:07 - MAKEOBJDIRPREFIX=/obj TB --- 2011-05-17 14:43:07 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-05-17 14:43:07 - TARGET=arm TB --- 2011-05-17 14:43:07 - TARGET_ARCH=arm TB --- 2011-05-17 14:43:07 - TZ=UTC TB --- 2011-05-17 14:43:07 - __MAKE_CONF=/dev/null TB --- 2011-05-17 14:43:07 - cd /src TB --- 2011-05-17 14:43:07 - /usr/bin/make -B buildkernel KERNCONF=AVILA >>> Kernel build for AVILA started on Tue May 17 14:43:07 UTC 2011 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -mbig-endian -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mcpu=xscale -ffreestanding -Werror /src/sys/dev/ath/ath_hal/ar5212/ar5212_gpio.c -I/src/sys/dev/ath -I/src/sys/dev/ath/ath_hal cc -mbig-endian -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mcpu=xscale -ffreestanding -Werror /src/sys/dev/ath/ath_hal/ar5212/ar5212_interrupts.c -I/src/sys/dev/ath -I/src/sys/dev/ath/ath_hal cc -mbig-endian -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mcpu=xscale -ffreestanding -Werror /src/sys/dev/ath/ath_hal/ar5212/ar5212_keycache.c -I/src/sys/dev/ath -I/src/sys/dev/ath/ath_hal cc -mbig-endian -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mcpu=xscale -ffreestanding -Werror /src/sys/dev/ath/ath_hal/ar5212/ar5212_misc.c -I/src/sys/dev/ath -I/src/sys/dev/ath/ath_hal /src/sys/dev/ath/ath_hal/ar5212/ar5212_misc.c: In function 'ar5212GetCapability': /src/sys/dev/ath/ath_hal/ar5212/ar5212_misc.c:860: error: 'pcap' undeclared (first use in this function) /src/sys/dev/ath/ath_hal/ar5212/ar5212_misc.c:860: error: (Each undeclared identifier is reported only once /src/sys/dev/ath/ath_hal/ar5212/ar5212_misc.c:860: error: for each function it appears in.) *** Error code 1 Stop in /obj/arm.arm/src/sys/AVILA. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-05-17 14:43:44 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-05-17 14:43:44 - ERROR: failed to build AVILA kernel TB --- 2011-05-17 14:43:44 - 2316.28 user 650.51 system 3224.22 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-arm-arm.full From owner-freebsd-current@FreeBSD.ORG Tue May 17 15:51:55 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B08931065670; Tue, 17 May 2011 15:51:55 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 6E94A8FC14; Tue, 17 May 2011 15:51:55 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.4) with ESMTP id p4HFpsDo078945; Tue, 17 May 2011 11:51:54 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.4/Submit) id p4HFpsrC078919; Tue, 17 May 2011 15:51:54 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 17 May 2011 15:51:54 GMT Message-Id: <201105171551.p4HFpsrC078919@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on i386/pc98 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 May 2011 15:51:55 -0000 TB --- 2011-05-17 13:50:00 - tinderbox 2.7 running on freebsd-current.sentex.ca TB --- 2011-05-17 13:50:00 - starting HEAD tinderbox run for i386/pc98 TB --- 2011-05-17 13:50:00 - cleaning the object tree TB --- 2011-05-17 13:50:18 - cvsupping the source tree TB --- 2011-05-17 13:50:18 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/pc98/supfile TB --- 2011-05-17 13:51:03 - building world TB --- 2011-05-17 13:51:03 - MAKEOBJDIRPREFIX=/obj TB --- 2011-05-17 13:51:03 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-05-17 13:51:03 - TARGET=pc98 TB --- 2011-05-17 13:51:03 - TARGET_ARCH=i386 TB --- 2011-05-17 13:51:03 - TZ=UTC TB --- 2011-05-17 13:51:03 - __MAKE_CONF=/dev/null TB --- 2011-05-17 13:51:03 - cd /src TB --- 2011-05-17 13:51:03 - /usr/bin/make -B buildworld >>> World build started on Tue May 17 13:51:03 UTC 2011 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Tue May 17 15:46:50 UTC 2011 TB --- 2011-05-17 15:46:51 - generating LINT kernel config TB --- 2011-05-17 15:46:51 - cd /src/sys/pc98/conf TB --- 2011-05-17 15:46:51 - /usr/bin/make -B LINT TB --- 2011-05-17 15:46:51 - building LINT kernel TB --- 2011-05-17 15:46:51 - MAKEOBJDIRPREFIX=/obj TB --- 2011-05-17 15:46:51 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-05-17 15:46:51 - TARGET=pc98 TB --- 2011-05-17 15:46:51 - TARGET_ARCH=i386 TB --- 2011-05-17 15:46:51 - TZ=UTC TB --- 2011-05-17 15:46:51 - __MAKE_CONF=/dev/null TB --- 2011-05-17 15:46:51 - cd /src TB --- 2011-05-17 15:46:51 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue May 17 15:46:51 UTC 2011 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-sse -mno-mmx -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ath/ath_hal/ar5212/ar5212_gpio.c -I/src/sys/dev/ath -I/src/sys/dev/ath/ath_hal cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-sse -mno-mmx -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ath/ath_hal/ar5212/ar5212_interrupts.c -I/src/sys/dev/ath -I/src/sys/dev/ath/ath_hal cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-sse -mno-mmx -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ath/ath_hal/ar5212/ar5212_keycache.c -I/src/sys/dev/ath -I/src/sys/dev/ath/ath_hal cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-sse -mno-mmx -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ath/ath_hal/ar5212/ar5212_misc.c -I/src/sys/dev/ath -I/src/sys/dev/ath/ath_hal /src/sys/dev/ath/ath_hal/ar5212/ar5212_misc.c: In function 'ar5212GetCapability': /src/sys/dev/ath/ath_hal/ar5212/ar5212_misc.c:860: error: 'pcap' undeclared (first use in this function) /src/sys/dev/ath/ath_hal/ar5212/ar5212_misc.c:860: error: (Each undeclared identifier is reported only once /src/sys/dev/ath/ath_hal/ar5212/ar5212_misc.c:860: error: for each function it appears in.) *** Error code 1 Stop in /obj/pc98.i386/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-05-17 15:51:53 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-05-17 15:51:53 - ERROR: failed to build lint kernel TB --- 2011-05-17 15:51:53 - 5847.72 user 1002.84 system 7313.22 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Tue May 17 15:58:35 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9CAF51065670; Tue, 17 May 2011 15:58:35 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 5EF588FC13; Tue, 17 May 2011 15:58:35 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.4) with ESMTP id p4HFwY0U047907; Tue, 17 May 2011 11:58:34 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.4/Submit) id p4HFwYf9047902; Tue, 17 May 2011 15:58:34 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 17 May 2011 15:58:34 GMT Message-Id: <201105171558.p4HFwYf9047902@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on i386/i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 May 2011 15:58:35 -0000 TB --- 2011-05-17 13:50:00 - tinderbox 2.7 running on freebsd-current.sentex.ca TB --- 2011-05-17 13:50:00 - starting HEAD tinderbox run for i386/i386 TB --- 2011-05-17 13:50:00 - cleaning the object tree TB --- 2011-05-17 13:50:25 - cvsupping the source tree TB --- 2011-05-17 13:50:25 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/i386/supfile TB --- 2011-05-17 13:55:49 - building world TB --- 2011-05-17 13:55:49 - MAKEOBJDIRPREFIX=/obj TB --- 2011-05-17 13:55:49 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-05-17 13:55:49 - TARGET=i386 TB --- 2011-05-17 13:55:49 - TARGET_ARCH=i386 TB --- 2011-05-17 13:55:49 - TZ=UTC TB --- 2011-05-17 13:55:49 - __MAKE_CONF=/dev/null TB --- 2011-05-17 13:55:49 - cd /src TB --- 2011-05-17 13:55:49 - /usr/bin/make -B buildworld >>> World build started on Tue May 17 13:55:50 UTC 2011 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Tue May 17 15:52:35 UTC 2011 TB --- 2011-05-17 15:52:35 - generating LINT kernel config TB --- 2011-05-17 15:52:35 - cd /src/sys/i386/conf TB --- 2011-05-17 15:52:35 - /usr/bin/make -B LINT TB --- 2011-05-17 15:52:36 - building LINT kernel TB --- 2011-05-17 15:52:36 - MAKEOBJDIRPREFIX=/obj TB --- 2011-05-17 15:52:36 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-05-17 15:52:36 - TARGET=i386 TB --- 2011-05-17 15:52:36 - TARGET_ARCH=i386 TB --- 2011-05-17 15:52:36 - TZ=UTC TB --- 2011-05-17 15:52:36 - __MAKE_CONF=/dev/null TB --- 2011-05-17 15:52:36 - cd /src TB --- 2011-05-17 15:52:36 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue May 17 15:52:36 UTC 2011 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-sse -mno-mmx -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ath/ath_hal/ar5212/ar5212_gpio.c -I/src/sys/dev/ath -I/src/sys/dev/ath/ath_hal cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-sse -mno-mmx -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ath/ath_hal/ar5212/ar5212_interrupts.c -I/src/sys/dev/ath -I/src/sys/dev/ath/ath_hal cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-sse -mno-mmx -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ath/ath_hal/ar5212/ar5212_keycache.c -I/src/sys/dev/ath -I/src/sys/dev/ath/ath_hal cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-sse -mno-mmx -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ath/ath_hal/ar5212/ar5212_misc.c -I/src/sys/dev/ath -I/src/sys/dev/ath/ath_hal /src/sys/dev/ath/ath_hal/ar5212/ar5212_misc.c: In function 'ar5212GetCapability': /src/sys/dev/ath/ath_hal/ar5212/ar5212_misc.c:860: error: 'pcap' undeclared (first use in this function) /src/sys/dev/ath/ath_hal/ar5212/ar5212_misc.c:860: error: (Each undeclared identifier is reported only once /src/sys/dev/ath/ath_hal/ar5212/ar5212_misc.c:860: error: for each function it appears in.) *** Error code 1 Stop in /obj/i386.i386/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-05-17 15:58:34 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-05-17 15:58:34 - ERROR: failed to build lint kernel TB --- 2011-05-17 15:58:34 - 5929.34 user 997.70 system 7713.68 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Tue May 17 16:15:09 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 74D0E1065675; Tue, 17 May 2011 16:15:09 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 3D3658FC1E; Tue, 17 May 2011 16:15:08 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.4) with ESMTP id p4HGF8Mi090973; Tue, 17 May 2011 12:15:08 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.4/Submit) id p4HGF8Kk090951; Tue, 17 May 2011 16:15:08 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 17 May 2011 16:15:08 GMT Message-Id: <201105171615.p4HGF8Kk090951@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on ia64/ia64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 May 2011 16:15:09 -0000 TB --- 2011-05-17 14:43:45 - tinderbox 2.7 running on freebsd-current.sentex.ca TB --- 2011-05-17 14:43:45 - starting HEAD tinderbox run for ia64/ia64 TB --- 2011-05-17 14:43:45 - cleaning the object tree TB --- 2011-05-17 14:43:56 - cvsupping the source tree TB --- 2011-05-17 14:43:56 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/ia64/ia64/supfile TB --- 2011-05-17 14:44:08 - building world TB --- 2011-05-17 14:44:08 - MAKEOBJDIRPREFIX=/obj TB --- 2011-05-17 14:44:08 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-05-17 14:44:08 - TARGET=ia64 TB --- 2011-05-17 14:44:08 - TARGET_ARCH=ia64 TB --- 2011-05-17 14:44:08 - TZ=UTC TB --- 2011-05-17 14:44:08 - __MAKE_CONF=/dev/null TB --- 2011-05-17 14:44:08 - cd /src TB --- 2011-05-17 14:44:08 - /usr/bin/make -B buildworld >>> World build started on Tue May 17 14:44:09 UTC 2011 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Tue May 17 16:09:24 UTC 2011 TB --- 2011-05-17 16:09:24 - generating LINT kernel config TB --- 2011-05-17 16:09:24 - cd /src/sys/ia64/conf TB --- 2011-05-17 16:09:24 - /usr/bin/make -B LINT TB --- 2011-05-17 16:09:24 - building LINT kernel TB --- 2011-05-17 16:09:24 - MAKEOBJDIRPREFIX=/obj TB --- 2011-05-17 16:09:24 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-05-17 16:09:24 - TARGET=ia64 TB --- 2011-05-17 16:09:24 - TARGET_ARCH=ia64 TB --- 2011-05-17 16:09:24 - TZ=UTC TB --- 2011-05-17 16:09:24 - __MAKE_CONF=/dev/null TB --- 2011-05-17 16:09:24 - cd /src TB --- 2011-05-17 16:09:24 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue May 17 16:09:24 UTC 2011 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/dev/ath/ath_hal/ar5212/ar5212_gpio.c -I/src/sys/dev/ath -I/src/sys/dev/ath/ath_hal cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/dev/ath/ath_hal/ar5212/ar5212_interrupts.c -I/src/sys/dev/ath -I/src/sys/dev/ath/ath_hal cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/dev/ath/ath_hal/ar5212/ar5212_keycache.c -I/src/sys/dev/ath -I/src/sys/dev/ath/ath_hal cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/dev/ath/ath_hal/ar5212/ar5212_misc.c -I/src/sys/dev/ath -I/src/sys/dev/ath/ath_hal /src/sys/dev/ath/ath_hal/ar5212/ar5212_misc.c: In function 'ar5212GetCapability': /src/sys/dev/ath/ath_hal/ar5212/ar5212_misc.c:860: error: 'pcap' undeclared (first use in this function) /src/sys/dev/ath/ath_hal/ar5212/ar5212_misc.c:860: error: (Each undeclared identifier is reported only once /src/sys/dev/ath/ath_hal/ar5212/ar5212_misc.c:860: error: for each function it appears in.) *** Error code 1 Stop in /obj/ia64.ia64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-05-17 16:15:07 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-05-17 16:15:07 - ERROR: failed to build lint kernel TB --- 2011-05-17 16:15:07 - 4357.74 user 794.30 system 5482.07 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Tue May 17 16:20:46 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 9518C1065673; Tue, 17 May 2011 16:20:46 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.9]) by mx1.freebsd.org (Postfix) with ESMTP id 272B98FC16; Tue, 17 May 2011 16:20:45 +0000 (UTC) Received: from [10.54.190.172] (gw-105.extranet.sea01.isilon.com [74.85.160.105]) by mrelayeu.kundenserver.de (node=mrbap1) with ESMTP (Nemesis) id 0LrqPu-1Ph2Em3AzO-0130km; Tue, 17 May 2011 18:20:45 +0200 Message-ID: <4DD2A058.6050400@love2party.net> Date: Tue, 17 May 2011 09:20:40 -0700 From: Max Laier User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.15) Gecko/20110419 Lightning/1.0b2pre Thunderbird/3.1.9 MIME-Version: 1.0 To: John Baldwin References: <4DCD357D.6000109@FreeBSD.org> <201105161738.53366.max@love2party.net> <201105161805.51188.max@love2party.net> <4DD26720.3000001@FreeBSD.org> In-Reply-To: <4DD26720.3000001@FreeBSD.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V02:K0:pSf713jrCwEO/x85+AO8ETnUL95ISZAe1a6Exk40nOF s/m9q5zNeEkttabSG8t0KT1kCCoMo8mqfkwR38oE2F7+3ognQl n8hkceb0SFYT06Z+2jB5y5rH0wfBo//hYgv0w5WJZEzsEo0qFu iURY4VpyYe07DjQ7wIZJGoAMzMiWlJnRjzaiaQ9APLFETjWxnm vHlvhlQvZYovs1u9nonjA== Cc: neel@freebsd.org, Andriy Gapon , Attilio Rao , FreeBSD current , Stephan Uphoff , Peter Grehan Subject: Re: proposed smp_rendezvous change 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, 17 May 2011 16:20:46 -0000 On 05/17/2011 05:16 AM, John Baldwin wrote: ... > Index: kern/kern_switch.c > =================================================================== > --- kern/kern_switch.c (revision 221536) > +++ kern/kern_switch.c (working copy) > @@ -192,15 +192,22 @@ > critical_exit(void) > { > struct thread *td; > - int flags; > + int flags, owepreempt; > > td = curthread; > KASSERT(td->td_critnest != 0, > ("critical_exit: td_critnest == 0")); > > if (td->td_critnest == 1) { > + owepreempt = td->td_owepreempt; > + td->td_owepreempt = 0; > + /* > + * XXX: Should move compiler_memory_barrier() from > + * rmlock to a header. > + */ XXX: If we get an interrupt at this point and td_owepreempt was zero, the new interrupt will re-set it, because td_critnest is still non-zero. So we still end up with a thread that is leaking an owepreempt *and* lose a preemption. We really need an atomic_readandclear() which gives us a local copy of td_owepreempt *and* clears critnest in the same operation. Sadly, that is rather expensive. It is possible to implement with a flag for owepreempt, but that means that all writes to critnest must then be atomic. Either because we know we have interrupts disabled (i.e. setting owepreempt can be a RMW), or with a proper atomic_add/set/... I'm not sure what the performance impact of this will be. One would hope that atomic_add without a memory barrier isn't much more expensive than a compiler generated read-modify-write, tho. Especially, since this cacheline should be local and exclusive to us, anyway. > + __asm __volatile("":::"memory"); > td->td_critnest = 0; > - if (td->td_owepreempt) { > + if (owepreempt) { > td->td_critnest = 1; > thread_lock(td); > td->td_critnest--; From owner-freebsd-current@FreeBSD.ORG Tue May 17 16:22:48 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B866D1065706; Tue, 17 May 2011 16:22:48 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 8A65C8FC18; Tue, 17 May 2011 16:22:48 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.4) with ESMTP id p4HGMlhV084143; Tue, 17 May 2011 12:22:47 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.4/Submit) id p4HGMlZS084138; Tue, 17 May 2011 16:22:47 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 17 May 2011 16:22:47 GMT Message-Id: <201105171622.p4HGMlZS084138@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 May 2011 16:22:48 -0000 TB --- 2011-05-17 13:50:00 - tinderbox 2.7 running on freebsd-current.sentex.ca TB --- 2011-05-17 13:50:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2011-05-17 13:50:00 - cleaning the object tree TB --- 2011-05-17 13:50:25 - cvsupping the source tree TB --- 2011-05-17 13:50:25 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/amd64/amd64/supfile TB --- 2011-05-17 13:51:03 - building world TB --- 2011-05-17 13:51:03 - MAKEOBJDIRPREFIX=/obj TB --- 2011-05-17 13:51:03 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-05-17 13:51:03 - TARGET=amd64 TB --- 2011-05-17 13:51:03 - TARGET_ARCH=amd64 TB --- 2011-05-17 13:51:03 - TZ=UTC TB --- 2011-05-17 13:51:03 - __MAKE_CONF=/dev/null TB --- 2011-05-17 13:51:03 - cd /src TB --- 2011-05-17 13:51:03 - /usr/bin/make -B buildworld >>> World build started on Tue May 17 13:51:03 UTC 2011 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Tue May 17 16:16:41 UTC 2011 TB --- 2011-05-17 16:16:41 - generating LINT kernel config TB --- 2011-05-17 16:16:41 - cd /src/sys/amd64/conf TB --- 2011-05-17 16:16:41 - /usr/bin/make -B LINT TB --- 2011-05-17 16:16:41 - building LINT kernel TB --- 2011-05-17 16:16:41 - MAKEOBJDIRPREFIX=/obj TB --- 2011-05-17 16:16:41 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-05-17 16:16:41 - TARGET=amd64 TB --- 2011-05-17 16:16:41 - TARGET_ARCH=amd64 TB --- 2011-05-17 16:16:41 - TZ=UTC TB --- 2011-05-17 16:16:41 - __MAKE_CONF=/dev/null TB --- 2011-05-17 16:16:41 - cd /src TB --- 2011-05-17 16:16:41 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue May 17 16:16:41 UTC 2011 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mno-sse -mcmodel=kernel -mno-red-zone -mno-mmx -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ath/ath_hal/ar5212/ar5212_gpio.c -I/src/sys/dev/ath -I/src/sys/dev/ath/ath_hal cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mno-sse -mcmodel=kernel -mno-red-zone -mno-mmx -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ath/ath_hal/ar5212/ar5212_interrupts.c -I/src/sys/dev/ath -I/src/sys/dev/ath/ath_hal cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mno-sse -mcmodel=kernel -mno-red-zone -mno-mmx -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ath/ath_hal/ar5212/ar5212_keycache.c -I/src/sys/dev/ath -I/src/sys/dev/ath/ath_hal cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mno-sse -mcmodel=kernel -mno-red-zone -mno-mmx -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ath/ath_hal/ar5212/ar5212_misc.c -I/src/sys/dev/ath -I/src/sys/dev/ath/ath_hal /src/sys/dev/ath/ath_hal/ar5212/ar5212_misc.c: In function 'ar5212GetCapability': /src/sys/dev/ath/ath_hal/ar5212/ar5212_misc.c:860: error: 'pcap' undeclared (first use in this function) /src/sys/dev/ath/ath_hal/ar5212/ar5212_misc.c:860: error: (Each undeclared identifier is reported only once /src/sys/dev/ath/ath_hal/ar5212/ar5212_misc.c:860: error: for each function it appears in.) *** Error code 1 Stop in /obj/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-05-17 16:22:47 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-05-17 16:22:47 - ERROR: failed to build lint kernel TB --- 2011-05-17 16:22:47 - 7230.69 user 1336.02 system 9166.90 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-amd64-amd64.full From owner-freebsd-current@FreeBSD.ORG Tue May 17 16:49:51 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 D0F4F106564A for ; Tue, 17 May 2011 16:49:51 +0000 (UTC) (envelope-from DStaal@usa.net) Received: from mail.magehandbook.com (173-8-4-45-WashingtonDC.hfc.comcastbusiness.net [173.8.4.45]) by mx1.freebsd.org (Postfix) with ESMTP id AAD3C8FC1E for ; Tue, 17 May 2011 16:49:51 +0000 (UTC) Received: from [192.168.1.50] (Mac-Pro.magehandbook.com [192.168.1.50]) by mail.magehandbook.com (Postfix) with ESMTP id 4D1A2259 for ; Tue, 17 May 2011 12:31:13 -0400 (EDT) Date: Tue, 17 May 2011 12:31:12 -0400 From: Daniel Staal To: freebsd-current@freebsd.org Message-ID: <19EF3F42C9518C4C0FA4219F@mac-pro.magehandbook.com> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Re: Boot halts on Thinkpad X220 (Sandy Bridge) 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, 17 May 2011 16:49:51 -0000 (Sorry I can't reply to anyone, I just joined the list. I saw this discussion in the archives and thought I should join in.) I've managed to boot a X220i using -CURRENT as of last night. I got some help on -questions to get it done though. From a blank machine, you'll need either a non-USB boot device with FreeBSD media (untested) or a USB keyboard. If you are using a USB keyboard set hint.atkbd.0.disabled=1 to install, and use the USB keyboard during installation. Then on the first reboot in the BIOS set 'USB UEFI BIOS' to disabled. (This means you can't boot from a USB device.) At that point, the machine will boot fine. I've tried 8.2-RELEASE, the last amd64 -CURRENT I could find on the FreeBSD website, and -CURRENT as of 2011-05-16. I'm building a couple of ports at the moment, and want to reboot with a couple of config changes in the loader to see if I can get the WiFi recognized. As soon as I do that I can post my dmesg someplace. Daniel T. Staal --------------------------------------------------------------- This email copyright the author. Unless otherwise noted, you are expressly allowed to retransmit, quote, or otherwise use the contents for non-commercial purposes. This copyright will expire 5 years after the author's death, or in 30 years, whichever is longer, unless such a period is in excess of local copyright law. --------------------------------------------------------------- From owner-freebsd-current@FreeBSD.ORG Tue May 17 17:01: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 ADE8D106566B; Tue, 17 May 2011 17:01:19 +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 852F28FC0A; Tue, 17 May 2011 17:01:19 +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 38A0546B03; Tue, 17 May 2011 13:01:19 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 879EE8A04F; Tue, 17 May 2011 13:01:18 -0400 (EDT) From: John Baldwin To: Andriy Gapon Date: Tue, 17 May 2011 11:51:17 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110325; KDE/4.5.5; amd64; ; ) References: <4DCD357D.6000109@FreeBSD.org> <201105170958.16847.jhb@freebsd.org> <4DD28781.6050002@FreeBSD.org> In-Reply-To: <4DD28781.6050002@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201105171151.18038.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Tue, 17 May 2011 13:01:18 -0400 (EDT) Cc: Max Laier , FreeBSD current , neel@freebsd.org, Peter Grehan Subject: Re: proposed smp_rendezvous change 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, 17 May 2011 17:01:19 -0000 On Tuesday, May 17, 2011 10:34:41 am Andriy Gapon wrote: > on 17/05/2011 16:58 John Baldwin said the following: > > No, it doesn't quite work that way. It wouldn't work on Alpha for example. > > > > All load_acq is a load with a memory barrier to order other loads after it. > > It is still free to load stale data. Only a read-modify-write operation > > would actually block until it could access an up-to-date value. > > Hmm, ok. > How about atomic_add_acq_int(&smp_rv_waiters[0], 0) ? :-) > Or an equivalent MI action that doesn't actually change smp_rv_waiters[0] value, > if there could be any. > Maybe explicit atomic_cmpset_acq_int(&smp_rv_waiters[0], 0, 0) ? > > You see at what I am getting? Yeah, either of those would work. At this point just leaving the atomic_add_int() as-is would be the smallest diff. :) -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Tue May 17 17:01: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 0AB521065672; Tue, 17 May 2011 17:01:21 +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 D48FD8FC0C; Tue, 17 May 2011 17:01:20 +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 89C7246B06; Tue, 17 May 2011 13:01:20 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 0C7B98A052; Tue, 17 May 2011 13:01:20 -0400 (EDT) From: John Baldwin To: Max Laier Date: Tue, 17 May 2011 12:56:40 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110325; KDE/4.5.5; amd64; ; ) References: <4DCD357D.6000109@FreeBSD.org> <4DD26720.3000001@FreeBSD.org> <4DD2A058.6050400@love2party.net> In-Reply-To: <4DD2A058.6050400@love2party.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201105171256.41091.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Tue, 17 May 2011 13:01:20 -0400 (EDT) Cc: neel@freebsd.org, Andriy Gapon , Attilio Rao , FreeBSD current , Stephan Uphoff , Peter Grehan Subject: Re: proposed smp_rendezvous change 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, 17 May 2011 17:01:21 -0000 On Tuesday, May 17, 2011 12:20:40 pm Max Laier wrote: > On 05/17/2011 05:16 AM, John Baldwin wrote: > ... > > Index: kern/kern_switch.c > > =================================================================== > > --- kern/kern_switch.c (revision 221536) > > +++ kern/kern_switch.c (working copy) > > @@ -192,15 +192,22 @@ > > critical_exit(void) > > { > > struct thread *td; > > - int flags; > > + int flags, owepreempt; > > > > td = curthread; > > KASSERT(td->td_critnest != 0, > > ("critical_exit: td_critnest == 0")); > > > > if (td->td_critnest == 1) { > > + owepreempt = td->td_owepreempt; > > + td->td_owepreempt = 0; > > + /* > > + * XXX: Should move compiler_memory_barrier() from > > + * rmlock to a header. > > + */ > > XXX: If we get an interrupt at this point and td_owepreempt was zero, > the new interrupt will re-set it, because td_critnest is still non-zero. > > So we still end up with a thread that is leaking an owepreempt *and* > lose a preemption. I don't see how this can still leak owepreempt. The nested interrupt should do nothing (except for possibly set owepreempt) until td_critnest is 0. However, we can certainly lose preemptions. I wonder if we can abuse the high bit of td_critnest for the owepreempt flag so it is all stored in one cookie. We only set owepreempt while holding thread_lock() (so interrupts are disabled), so I think we would be ok and not need atomic ops. Hmm, actually, the top-half code would have to use atomic ops. Nuts. Let me think some more. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Tue May 17 18:05: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 65068106564A for ; Tue, 17 May 2011 18:05:09 +0000 (UTC) (envelope-from deeptech71@gmail.com) Received: from mail-pw0-f54.google.com (mail-pw0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 3527F8FC15 for ; Tue, 17 May 2011 18:05:08 +0000 (UTC) Received: by pwj8 with SMTP id 8so500877pwj.13 for ; Tue, 17 May 2011 11:05:08 -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:content-type; bh=xrXoOsc1MEL3oAiFobZTPCYaN/3NWpPIGAybBcAvd6M=; b=J+HZ10Dn6Rv25q/pBwCjojY8ggs2w8rh3Q/0sBeIb0zxRkPt+jRPvsd+Cpu1idk1n7 YHiMK1qjfcCeFbD6n4alpkcIxxolga72KLspf03dgnGnLp7QjNGOSqRs8vg4HTfWHNQB /8c9zEzBICN6/nXg6+QnmE8np580hUKxLvSWM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=nuFBYy2+V0YK8osPp4rY+ee6L5BRNGPU/wMDsKBHwi6im0jMK1OvCFSYVkYCvbmICF x82luN9BX+/KUuMUJG4ciJj6IVAJ5t8FOGww2+1JOZiBv/CXBFqrBwdq5ZDicNYHmQe5 W2lYLSRoncJsOpbsUviwrBnmPFgOngwwF90Ak= MIME-Version: 1.0 Received: by 10.68.69.114 with SMTP id d18mr1521820pbu.275.1305655508495; Tue, 17 May 2011 11:05:08 -0700 (PDT) Received: by 10.68.71.130 with HTTP; Tue, 17 May 2011 11:05:08 -0700 (PDT) In-Reply-To: <201105170944.16261.jhb@freebsd.org> References: <201105170944.16261.jhb@freebsd.org> Date: Tue, 17 May 2011 20:05:08 +0200 Message-ID: From: "deeptech71@gmail.com" To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: pcib allocation failure 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, 17 May 2011 18:05:09 -0000 On Tue, May 17, 2011 at 3:44 PM, John Baldwin wrote: > On Saturday, May 14, 2011 12:27:59 pm deeptech71@gmail.com wrote: >> pcib1: at device 1.0 on pci0 >> pcib1: failed to allocate initial prefetch window: 0xd0000000-0xfaffffff >> >> the console output is cut shortly after those 2 lines (but the machine >> seems to continue booting, as i have reset'd the machine, after which >> "/" was found to be improperly dismounted). > > So it actually boots fine, but video output breaks during the boot? Does it > ever come back or it is permanently broken until reboot? the video output is permanently broken until reboot (i was able to gather logs by using delayed rc.d scripts). > Your BIOS is actually violating the PCI spec by assigning the same resource > ranges to two devices on the same PCI bus (the hostb device and the AGP bridge > device). It's also doing so unnecessarily. ok, i've tried changing random BIOS settings, and found that changing "AGP Aperture Size" from 128M to 64M solved the problem with the new PCI bus driver. (i have a computer with 512MiB of RAM and an AGP video card with 128MiB of RAM.) weird. any comments on that? From owner-freebsd-current@FreeBSD.ORG Tue May 17 19:16:52 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 E7DBA106564A; Tue, 17 May 2011 19:16:52 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.171]) by mx1.freebsd.org (Postfix) with ESMTP id 75C6B8FC16; Tue, 17 May 2011 19:16:52 +0000 (UTC) Received: from [10.54.190.172] (gw-105.extranet.sea01.isilon.com [74.85.160.105]) by mrelayeu.kundenserver.de (node=mrbap2) with ESMTP (Nemesis) id 0MTNxP-1QEPYN1JwN-00RxOJ; Tue, 17 May 2011 21:16:50 +0200 Message-ID: <4DD2C99D.50203@love2party.net> Date: Tue, 17 May 2011 12:16:45 -0700 From: Max Laier User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.15) Gecko/20110419 Lightning/1.0b2pre Thunderbird/3.1.9 MIME-Version: 1.0 To: John Baldwin References: <4DCD357D.6000109@FreeBSD.org> <4DD26720.3000001@FreeBSD.org> <4DD2A058.6050400@love2party.net> <201105171256.41091.jhb@freebsd.org> In-Reply-To: <201105171256.41091.jhb@freebsd.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V02:K0:dEpsw3ObiyUerVhf/DkEQATOSUtHuKmYbekOmF+Nu2k m/oijrgTqwSsy/C2YrXyMdKL875HNK9mkiuE58SevWb9HisZPw kEyAbXhaXdPih4OmWIjB4FmdTi6NxgBe84FmwWhoYLZ+gMIAC6 OpSeCx7WZKrA5unI5GbitggTEUJXXgjyDgVY/37Gf1wDw397oz Vv404iXiPdMHTxipygdMg== Cc: neel@freebsd.org, Andriy Gapon , Attilio Rao , FreeBSD current , Stephan Uphoff , Peter Grehan Subject: Re: proposed smp_rendezvous change 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, 17 May 2011 19:16:53 -0000 On 05/17/2011 09:56 AM, John Baldwin wrote: > On Tuesday, May 17, 2011 12:20:40 pm Max Laier wrote: >> On 05/17/2011 05:16 AM, John Baldwin wrote: >> ... >>> Index: kern/kern_switch.c >>> =================================================================== >>> --- kern/kern_switch.c (revision 221536) >>> +++ kern/kern_switch.c (working copy) >>> @@ -192,15 +192,22 @@ >>> critical_exit(void) >>> { >>> struct thread *td; >>> - int flags; >>> + int flags, owepreempt; >>> >>> td = curthread; >>> KASSERT(td->td_critnest != 0, >>> ("critical_exit: td_critnest == 0")); >>> >>> if (td->td_critnest == 1) { >>> + owepreempt = td->td_owepreempt; >>> + td->td_owepreempt = 0; >>> + /* >>> + * XXX: Should move compiler_memory_barrier() from >>> + * rmlock to a header. >>> + */ >> >> XXX: If we get an interrupt at this point and td_owepreempt was zero, >> the new interrupt will re-set it, because td_critnest is still non-zero. >> >> So we still end up with a thread that is leaking an owepreempt *and* >> lose a preemption. > > I don't see how this can still leak owepreempt. The nested interrupt should > do nothing (except for possibly set owepreempt) until td_critnest is 0. Exactly. The interrupt sets owepreempt and after we return here, we set td_critnest to 0 and exit without clearing owepreempt. Hence we leak the owepreempt. > However, we can certainly lose preemptions. > > I wonder if we can abuse the high bit of td_critnest for the owepreempt flag > so it is all stored in one cookie. We only set owepreempt while holding > thread_lock() (so interrupts are disabled), so I think we would be ok and not > need atomic ops. > > Hmm, actually, the top-half code would have to use atomic ops. Nuts. Let me > think some more. I think these two really belong into one single variable. Setting the owepreempt flag can be a normal RMW. Increasing and decreasing critnest must be atomic (otherwise we could lose the flag) and dropping the final reference would work like this: if ((curthread->td_critnest & TD_CRITNEST_MASK) == 1) { unsigned int owe; owe = atomic_readandclear(&curthread->td_critnest); if (owe & TD_OWEPREEMPT_FLAG) { /* do the switch */ } That should do it ... I can put that into a patch, if we agree that's the right thing to do. Thanks, Max From owner-freebsd-current@FreeBSD.ORG Tue May 17 19:31: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 8E90B1065677 for ; Tue, 17 May 2011 19:31:17 +0000 (UTC) (envelope-from DStaal@usa.net) Received: from mail.magehandbook.com (173-8-4-45-WashingtonDC.hfc.comcastbusiness.net [173.8.4.45]) by mx1.freebsd.org (Postfix) with ESMTP id 663228FC18 for ; Tue, 17 May 2011 19:31:17 +0000 (UTC) Received: from [192.168.1.50] (Mac-Pro.magehandbook.com [192.168.1.50]) by mail.magehandbook.com (Postfix) with ESMTP id 5369F2D1 for ; Tue, 17 May 2011 15:31:16 -0400 (EDT) Date: Tue, 17 May 2011 15:31:16 -0400 From: Daniel Staal To: freebsd-current@freebsd.org Message-ID: In-Reply-To: <19EF3F42C9518C4C0FA4219F@mac-pro.magehandbook.com> References: <19EF3F42C9518C4C0FA4219F@mac-pro.magehandbook.com> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Re: Boot halts on Thinkpad X220 (Sandy Bridge) 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, 17 May 2011 19:31:17 -0000 > I'm building a couple of ports at the moment, and want to reboot with a > couple of config changes in the loader to see if I can get the WiFi > recognized. As soon as I do that I can post my dmesg someplace. And my promised dmesg: Note that this is with 'USB UEFI BIOS' _off._ Daniel T. Staal --------------------------------------------------------------- This email copyright the author. Unless otherwise noted, you are expressly allowed to retransmit, quote, or otherwise use the contents for non-commercial purposes. This copyright will expire 5 years after the author's death, or in 30 years, whichever is longer, unless such a period is in excess of local copyright law. --------------------------------------------------------------- From owner-freebsd-current@FreeBSD.ORG Tue May 17 20:16: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 E78C21065673; Tue, 17 May 2011 20:16:25 +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 89F4C8FC12; Tue, 17 May 2011 20:16:24 +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 XAA03539; Tue, 17 May 2011 23:16:22 +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 1QMQgo-0007df-Gf; Tue, 17 May 2011 23:16:22 +0300 Message-ID: <4DD2D795.6020106@FreeBSD.org> Date: Tue, 17 May 2011 23:16:21 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.17) Gecko/20110503 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: John Baldwin References: <4DCD357D.6000109@FreeBSD.org> <201105170958.16847.jhb@freebsd.org> <4DD28781.6050002@FreeBSD.org> <201105171151.18038.jhb@freebsd.org> In-Reply-To: <201105171151.18038.jhb@freebsd.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Max Laier , FreeBSD current , neel@FreeBSD.org, Peter Grehan Subject: Re: proposed smp_rendezvous change 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, 17 May 2011 20:16:26 -0000 on 17/05/2011 18:51 John Baldwin said the following: > On Tuesday, May 17, 2011 10:34:41 am Andriy Gapon wrote: >> on 17/05/2011 16:58 John Baldwin said the following: >>> No, it doesn't quite work that way. It wouldn't work on Alpha for example. >>> >>> All load_acq is a load with a memory barrier to order other loads after it. >>> It is still free to load stale data. Only a read-modify-write operation >>> would actually block until it could access an up-to-date value. >> >> Hmm, ok. >> How about atomic_add_acq_int(&smp_rv_waiters[0], 0) ? :-) >> Or an equivalent MI action that doesn't actually change smp_rv_waiters[0] value, >> if there could be any. >> Maybe explicit atomic_cmpset_acq_int(&smp_rv_waiters[0], 0, 0) ? >> >> You see at what I am getting? > > Yeah, either of those would work. At this point just leaving the > atomic_add_int() as-is would be the smallest diff. :) Yes, I agree about the smallest diff. But if we are going to remove that first spin-loop, then we would effectively be wasting one volatile variable. Only a tiny waste, but it could be confusing. Whatever we decide, this was very educational for me. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Tue May 17 20:28:37 2011 Return-Path: Delivered-To: current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8D8E9106564A; Tue, 17 May 2011 20:28:37 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: from mail.sippysoft.com (mail.sippysoft.com [4.59.13.245]) by mx1.freebsd.org (Postfix) with ESMTP id 2E3DC8FC0C; Tue, 17 May 2011 20:28:37 +0000 (UTC) Received: from [4.59.13.245] (helo=[192.168.1.79]) by mail.sippysoft.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1QMQse-0009X1-IX; Tue, 17 May 2011 13:28:36 -0700 Message-ID: <4DD2DA65.5060103@FreeBSD.org> Date: Tue, 17 May 2011 13:28:21 -0700 From: Maxim Sobolev Organization: Sippy Software, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Pawel Jakub Dawidek , "current@freebsd.org" Content-Type: text/plain; charset=KOI8-U; format=flowed Content-Transfer-Encoding: 7bit Sender: sobomax@sippysoft.com X-ssp-trusted: yes Cc: Subject: Randomization in hastd(8) synchronization thread 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, 17 May 2011 20:28:37 -0000 Hi Pawel, I am trying to use hastd(8) over slow links and one problem is apparent right now - current approach with synchronizing content sequentially is not working in this case. What happens is that hastd hits the first frequently updated block and cannot make any progress anymore. In my case I have 30GB of dirty space to be synchronized over just 1mbps uplink. The quick fix that I've applied is randomization in the block selection code. This way eventually all least used blocks will be synchronized, leaving only hot ones dirty. More effective approach would be to use some kind of LRU selection algorithm, but statistical approach would work just as good in this case. Please review the patch below: http://sobomax.sippysoft.com/activemap.c.diff The next thing to make it usable is to make "async" mode working. I think simple support for that mode can be easily implemented by not sending write request to the remote note at all, but instead just doing it locally and kicking the synchronization thread to do it's magic in the background. I hope to follow up with the patch soon. -Maxim From owner-freebsd-current@FreeBSD.ORG Tue May 17 20:35: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 92D3D1065672; Tue, 17 May 2011 20:35:19 +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 3AC588FC0C; Tue, 17 May 2011 20:35:19 +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 B978A46B2C; Tue, 17 May 2011 16:35:18 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 5703C8A04F; Tue, 17 May 2011 16:35:18 -0400 (EDT) From: John Baldwin To: Max Laier Date: Tue, 17 May 2011 16:35:17 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110325; KDE/4.5.5; amd64; ; ) References: <4DCD357D.6000109@FreeBSD.org> <201105171256.41091.jhb@freebsd.org> <4DD2C99D.50203@love2party.net> In-Reply-To: <4DD2C99D.50203@love2party.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201105171635.17704.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Tue, 17 May 2011 16:35:18 -0400 (EDT) Cc: neel@freebsd.org, Andriy Gapon , Attilio Rao , FreeBSD current , Stephan Uphoff , Peter Grehan Subject: Re: proposed smp_rendezvous change 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, 17 May 2011 20:35:19 -0000 On Tuesday, May 17, 2011 3:16:45 pm Max Laier wrote: > On 05/17/2011 09:56 AM, John Baldwin wrote: > > On Tuesday, May 17, 2011 12:20:40 pm Max Laier wrote: > >> On 05/17/2011 05:16 AM, John Baldwin wrote: > >> ... > >>> Index: kern/kern_switch.c > >>> =================================================================== > >>> --- kern/kern_switch.c (revision 221536) > >>> +++ kern/kern_switch.c (working copy) > >>> @@ -192,15 +192,22 @@ > >>> critical_exit(void) > >>> { > >>> struct thread *td; > >>> - int flags; > >>> + int flags, owepreempt; > >>> > >>> td = curthread; > >>> KASSERT(td->td_critnest != 0, > >>> ("critical_exit: td_critnest == 0")); > >>> > >>> if (td->td_critnest == 1) { > >>> + owepreempt = td->td_owepreempt; > >>> + td->td_owepreempt = 0; > >>> + /* > >>> + * XXX: Should move compiler_memory_barrier() from > >>> + * rmlock to a header. > >>> + */ > >> > >> XXX: If we get an interrupt at this point and td_owepreempt was zero, > >> the new interrupt will re-set it, because td_critnest is still non-zero. > >> > >> So we still end up with a thread that is leaking an owepreempt *and* > >> lose a preemption. > > > > I don't see how this can still leak owepreempt. The nested interrupt should > > do nothing (except for possibly set owepreempt) until td_critnest is 0. > > Exactly. The interrupt sets owepreempt and after we return here, we set > td_critnest to 0 and exit without clearing owepreempt. Hence we leak > the owepreempt. > > > However, we can certainly lose preemptions. > > > > I wonder if we can abuse the high bit of td_critnest for the owepreempt flag > > so it is all stored in one cookie. We only set owepreempt while holding > > thread_lock() (so interrupts are disabled), so I think we would be ok and not > > need atomic ops. > > > > Hmm, actually, the top-half code would have to use atomic ops. Nuts. Let me > > think some more. > > I think these two really belong into one single variable. Setting the > owepreempt flag can be a normal RMW. Increasing and decreasing critnest > must be atomic (otherwise we could lose the flag) and dropping the final > reference would work like this: > > if ((curthread->td_critnest & TD_CRITNEST_MASK) == 1) { > unsigned int owe; > owe = atomic_readandclear(&curthread->td_critnest); > if (owe & TD_OWEPREEMPT_FLAG) { > /* do the switch */ > } > > That should do it ... I can put that into a patch, if we agree that's > the right thing to do. Yeah, I already have a patch to do that, but hadn't added atomic ops to critical_enter() and critical_exit(). But it also wasn't as fancy in the critical_exit() case. Here is what I have and I think it might actually be ok (it doesn't use an atomic read and clear, but I think it is safe). Hmm, actually, it will need to use the read and clear: Index: kern/sched_ule.c =================================================================== --- kern/sched_ule.c (revision 222024) +++ kern/sched_ule.c (working copy) @@ -1785,7 +1785,6 @@ td->td_oncpu = NOCPU; if (!(flags & SW_PREEMPT)) td->td_flags &= ~TDF_NEEDRESCHED; - td->td_owepreempt = 0; tdq->tdq_switchcnt++; /* * The lock pointer in an idle thread should never change. Reset it @@ -2066,7 +2065,7 @@ flags = SW_INVOL | SW_PREEMPT; if (td->td_critnest > 1) - td->td_owepreempt = 1; + td->td_critnest |= TD_OWEPREEMPT; else if (TD_IS_IDLETHREAD(td)) mi_switch(flags | SWT_REMOTEWAKEIDLE, NULL); else @@ -2261,7 +2260,7 @@ return; if (!sched_shouldpreempt(pri, cpri, 0)) return; - ctd->td_owepreempt = 1; + ctd->td_critnest |= TD_OWEPREEMPT; } /* Index: kern/kern_switch.c =================================================================== --- kern/kern_switch.c (revision 222024) +++ kern/kern_switch.c (working copy) @@ -183,7 +183,7 @@ struct thread *td; td = curthread; - td->td_critnest++; + atomic_add_int(&td->td_critnest, 1); CTR4(KTR_CRITICAL, "critical_enter by thread %p (%ld, %s) to %d", td, (long)td->td_proc->p_pid, td->td_name, td->td_critnest); } @@ -192,18 +192,16 @@ critical_exit(void) { struct thread *td; - int flags; + int flags, owepreempt; td = curthread; KASSERT(td->td_critnest != 0, ("critical_exit: td_critnest == 0")); - if (td->td_critnest == 1) { - td->td_critnest = 0; - if (td->td_owepreempt) { - td->td_critnest = 1; + if (td->td_critnest && ~TD_OWEPREEMPT == 1) { + owepreempt = atomic_readandclear_int(&td->td_owepreempt); + if (owepreempt & TD_OWEPREEMPT) { thread_lock(td); - td->td_critnest--; flags = SW_INVOL | SW_PREEMPT; if (TD_IS_IDLETHREAD(td)) flags |= SWT_IDLE; @@ -213,7 +211,7 @@ thread_unlock(td); } } else - td->td_critnest--; + atomic_subtract_int(&td->td_critnest, 1); CTR4(KTR_CRITICAL, "critical_exit by thread %p (%ld, %s) to %d", td, (long)td->td_proc->p_pid, td->td_name, td->td_critnest); Index: kern/kern_synch.c =================================================================== --- kern/kern_synch.c (revision 222024) +++ kern/kern_synch.c (working copy) @@ -400,9 +400,7 @@ if (!TD_ON_LOCK(td) && !TD_IS_RUNNING(td)) mtx_assert(&Giant, MA_NOTOWNED); #endif - KASSERT(td->td_critnest == 1 || (td->td_critnest == 2 && - (td->td_owepreempt) && (flags & SW_INVOL) != 0 && - newtd == NULL) || panicstr, + KASSERT(td->td_critnest == 1 || panicstr, ("mi_switch: switch in a critical section")); KASSERT((flags & (SW_INVOL | SW_VOL)) != 0, ("mi_switch: switch must be voluntary or involuntary")); Index: kern/sched_4bsd.c =================================================================== --- kern/sched_4bsd.c (revision 222024) +++ kern/sched_4bsd.c (working copy) @@ -335,7 +335,7 @@ if (ctd->td_critnest > 1) { CTR1(KTR_PROC, "maybe_preempt: in critical section %d", ctd->td_critnest); - ctd->td_owepreempt = 1; + ctd->td_critnest |= TD_OWEPREEMPT; return (0); } /* @@ -949,7 +949,6 @@ td->td_lastcpu = td->td_oncpu; if (!(flags & SW_PREEMPT)) td->td_flags &= ~TDF_NEEDRESCHED; - td->td_owepreempt = 0; td->td_oncpu = NOCPU; /* @@ -1437,7 +1436,7 @@ { thread_lock(td); if (td->td_critnest > 1) - td->td_owepreempt = 1; + td->td_critnest |= TD_OWEPREEMPT; else mi_switch(SW_INVOL | SW_PREEMPT | SWT_PREEMPT, NULL); thread_unlock(td); Index: kern/kern_rmlock.c =================================================================== --- kern/kern_rmlock.c (revision 222024) +++ kern/kern_rmlock.c (working copy) @@ -366,7 +366,8 @@ * Fast path to combine two common conditions into a single * conditional jump. */ - if (0 == (td->td_owepreempt | (rm->rm_writecpus & pc->pc_cpumask))) + if (0 == ((td->td_critnest & TD_OWEPREEMPT) | + (rm->rm_writecpus & pc->pc_cpumask))) return (1); /* We do not have a read token and need to acquire one. */ @@ -377,7 +378,7 @@ _rm_unlock_hard(struct thread *td,struct rm_priotracker *tracker) { - if (td->td_owepreempt) { + if (td->td_critnest & TD_OWEPREEMPT) { td->td_critnest++; critical_exit(); } @@ -418,7 +419,7 @@ td->td_critnest--; sched_unpin(); - if (0 == (td->td_owepreempt | tracker->rmp_flags)) + if (0 == ((td->td_critnest & TD_OWEPREEMPT) | tracker->rmp_flags)) return; _rm_unlock_hard(td, tracker); Index: sys/proc.h =================================================================== --- sys/proc.h (revision 222024) +++ sys/proc.h (working copy) @@ -228,7 +228,6 @@ const char *td_wmesg; /* (t) Reason for sleep. */ u_char td_lastcpu; /* (t) Last cpu we were on. */ u_char td_oncpu; /* (t) Which cpu we are on. */ - volatile u_char td_owepreempt; /* (k*) Preempt on last critical_exit */ u_char td_tsqueue; /* (t) Turnstile queue blocked on. */ short td_locks; /* (k) Count of non-spin locks. */ short td_rw_rlocks; /* (k) Count of rwlock read locks. */ @@ -465,6 +464,12 @@ #define TD_SET_CAN_RUN(td) (td)->td_state = TDS_CAN_RUN /* + * The high bit of td_critnest is used to determine if a preemption is + * pending. + */ +#define TD_OWEPREEMPT ((u_int)INT_MAX + 1) + +/* * Process structure. */ struct proc { -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Tue May 17 20:40:00 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DBF361065675; Tue, 17 May 2011 20:40:00 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 7C3D98FC15; Tue, 17 May 2011 20:40:00 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.4) with ESMTP id p4HKdxwI091541; Tue, 17 May 2011 16:39:59 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.4/Submit) id p4HKdxdW091524; Tue, 17 May 2011 20:39:59 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 17 May 2011 20:39:59 GMT Message-Id: <201105172039.p4HKdxdW091524@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on ia64/ia64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 May 2011 20:40:01 -0000 TB --- 2011-05-17 20:17:07 - tinderbox 2.7 running on freebsd-current.sentex.ca TB --- 2011-05-17 20:17:07 - starting HEAD tinderbox run for ia64/ia64 TB --- 2011-05-17 20:17:07 - cleaning the object tree TB --- 2011-05-17 20:17:15 - cvsupping the source tree TB --- 2011-05-17 20:17:15 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/ia64/ia64/supfile TB --- 2011-05-17 20:17:31 - building world TB --- 2011-05-17 20:17:31 - MAKEOBJDIRPREFIX=/obj TB --- 2011-05-17 20:17:31 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-05-17 20:17:31 - TARGET=ia64 TB --- 2011-05-17 20:17:31 - TARGET_ARCH=ia64 TB --- 2011-05-17 20:17:31 - TZ=UTC TB --- 2011-05-17 20:17:31 - __MAKE_CONF=/dev/null TB --- 2011-05-17 20:17:31 - cd /src TB --- 2011-05-17 20:17:31 - /usr/bin/make -B buildworld >>> World build started on Tue May 17 20:17:32 UTC 2011 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries [...] cc -O2 -pipe -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /src/lib/libsbuf/../../sys/kern/subr_sbuf.c building static sbuf library ranlib libsbuf.a cat /src/lib/libsbuf/Symbol.map | cpp - - | awk -v vfile=/src/lib/libsbuf/Version.def -f /src/share/mk/version_gen.awk > Version.map File /src/lib/libsbuf/Version.def: Unknown directive: `/*'. File /src/lib/libsbuf/Version.def: Unknown directive: `* $FreeBSD: src/lib/libsbuf/Version.def,v 1.1 2011/05/17 17:37:58 phk Exp $'. File /src/lib/libsbuf/Version.def: Unknown directive: `*/'. 3 error(s) total. *** Error code 1 Stop in /src/lib/libsbuf. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-05-17 20:39:58 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-05-17 20:39:58 - ERROR: failed to build world TB --- 2011-05-17 20:39:59 - 1046.34 user 236.60 system 1371.80 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Tue May 17 20:53:59 2011 Return-Path: Delivered-To: current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 74F06106566C; Tue, 17 May 2011 20:53:59 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: from mail.sippysoft.com (mail.sippysoft.com [4.59.13.245]) by mx1.freebsd.org (Postfix) with ESMTP id 1CE198FC0A; Tue, 17 May 2011 20:53:59 +0000 (UTC) Received: from [4.59.13.245] (helo=[192.168.1.79]) by mail.sippysoft.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1QMRHC-0009gp-GA; Tue, 17 May 2011 13:53:58 -0700 Message-ID: <4DD2E065.5040006@FreeBSD.org> Date: Tue, 17 May 2011 13:53:57 -0700 From: Maxim Sobolev Organization: Sippy Software, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Pawel Jakub Dawidek , "current@freebsd.org" References: <4DD2DA65.5060103@FreeBSD.org> In-Reply-To: <4DD2DA65.5060103@FreeBSD.org> Content-Type: text/plain; charset=KOI8-U; format=flowed Content-Transfer-Encoding: 7bit Sender: sobomax@sippysoft.com X-ssp-trusted: yes Cc: Subject: Making hastd working over WAN links (was: Randomization in hastd(8) synchronization thread) 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, 17 May 2011 20:53:59 -0000 On 5/17/2011 1:28 PM, Maxim Sobolev wrote: > The next thing to make it usable is to make "async" mode working. I > think simple support for that mode can be easily implemented by not > sending write request to the remote note at all, but instead just doing > it locally and kicking the synchronization thread to do it's magic in > the background. I hope to follow up with the patch soon. Here is a proof of concept path, which simply fails any non-synchronization requests in the send thread when in the async mode. This is non-optimal, as it would cause additional latency in the write path when the send thread is busy with synchronization requests. But it works for me, making it possible to use my virtual machine while synchronizing the disk image. http://sobomax.sippysoft.com/primary.c.diff -Maxim From owner-freebsd-current@FreeBSD.ORG Tue May 17 20:59:53 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8B805106566C; Tue, 17 May 2011 20:59:53 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 2F1EB8FC13; Tue, 17 May 2011 20:59:53 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.4) with ESMTP id p4HKxq2g067189; Tue, 17 May 2011 16:59:52 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.4/Submit) id p4HKxqSs067188; Tue, 17 May 2011 20:59:52 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 17 May 2011 20:59:52 GMT Message-Id: <201105172059.p4HKxqSs067188@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on mips/mips X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 May 2011 20:59:53 -0000 TB --- 2011-05-17 20:39:59 - tinderbox 2.7 running on freebsd-current.sentex.ca TB --- 2011-05-17 20:39:59 - starting HEAD tinderbox run for mips/mips TB --- 2011-05-17 20:39:59 - cleaning the object tree TB --- 2011-05-17 20:40:06 - cvsupping the source tree TB --- 2011-05-17 20:40:06 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/mips/mips/supfile TB --- 2011-05-17 20:40:19 - building world TB --- 2011-05-17 20:40:19 - MAKEOBJDIRPREFIX=/obj TB --- 2011-05-17 20:40:19 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-05-17 20:40:19 - TARGET=mips TB --- 2011-05-17 20:40:19 - TARGET_ARCH=mips TB --- 2011-05-17 20:40:19 - TZ=UTC TB --- 2011-05-17 20:40:19 - __MAKE_CONF=/dev/null TB --- 2011-05-17 20:40:19 - cd /src TB --- 2011-05-17 20:40:19 - /usr/bin/make -B buildworld >>> World build started on Tue May 17 20:40:19 UTC 2011 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries [...] cc -O -pipe -G0 -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /src/lib/libsbuf/../../sys/kern/subr_sbuf.c building static sbuf library ranlib libsbuf.a cat /src/lib/libsbuf/Symbol.map | cpp - - | awk -v vfile=/src/lib/libsbuf/Version.def -f /src/share/mk/version_gen.awk > Version.map File /src/lib/libsbuf/Version.def: Unknown directive: `/*'. File /src/lib/libsbuf/Version.def: Unknown directive: `* $FreeBSD: src/lib/libsbuf/Version.def,v 1.1 2011/05/17 17:37:58 phk Exp $'. File /src/lib/libsbuf/Version.def: Unknown directive: `*/'. 3 error(s) total. *** Error code 1 Stop in /src/lib/libsbuf. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-05-17 20:59:52 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-05-17 20:59:52 - ERROR: failed to build world TB --- 2011-05-17 20:59:52 - 840.77 user 218.09 system 1192.66 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-mips-mips.full From owner-freebsd-current@FreeBSD.ORG Tue May 17 20:20:10 2011 Return-Path: Delivered-To: current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EBBA8106566C for ; Tue, 17 May 2011 20:20:10 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: from mail.sippysoft.com (mail.sippysoft.com [4.59.13.245]) by mx1.freebsd.org (Postfix) with ESMTP id BF7028FC1A for ; Tue, 17 May 2011 20:20:10 +0000 (UTC) Received: from [4.59.13.245] (helo=[192.168.1.79]) by mail.sippysoft.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1QMQ6y-0009MW-GP; Tue, 17 May 2011 12:39:21 -0700 Message-ID: <4DD2CEE7.1070805@sippysoft.com> Date: Tue, 17 May 2011 12:39:19 -0700 From: Maxim Sobolev Organization: Sippy Software, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Pawel Jakub Dawidek , "current@freebsd.org" Content-Type: text/plain; charset=KOI8-U; format=flowed Content-Transfer-Encoding: 7bit X-ssp-trusted: yes X-Mailman-Approved-At: Tue, 17 May 2011 21:12:30 +0000 Cc: Subject: Randomization in hastd(8) synchronization thread 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, 17 May 2011 20:20:11 -0000 Hi Pawel, I am trying to use hastd(8) over slow links and one problem is apparent right now - current approach with synchronizing content sequentially is not working in this case. What happens is that hastd hits the first frequently updated block and cannot make any progress anymore. In my case I have 30GB of dirty space to be synchronized over just 1mbps uplink. The quick fix that I've applied is randomization in the block selection code. This way eventually all least used blocks will be synchronized, leaving only hot ones dirty. More effective approach would be to use some kind of LRU selection algorithm, but statistical approach would work just as good in this case. Please review the patch below: http://sobomax.sippysoft.com/activemap.c.diff The next thing to make it usable is to make "async" mode working. I think simple support for that mode can be easily implemented by not sending write request to the remote note at all, but instead just doing it locally and kicking the synchronization thread to do it's magic in the background. I hope to follow up with the patch soon. Regards, -- Maksym Sobolyev Sippy Software, Inc. Internet Telephony (VoIP) Experts Tel: +1-646-651-1110 Fax: +1-866-857-6942 Web: http://www.sippysoft.com MSN: sales@sippysoft.com Skype: SippySoft From owner-freebsd-current@FreeBSD.ORG Tue May 17 23:51: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 39B761065672 for ; Tue, 17 May 2011 23:51:05 +0000 (UTC) (envelope-from dieterich.johannes@googlemail.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 B2F4D8FC08 for ; Tue, 17 May 2011 23:51:04 +0000 (UTC) Received: by fxm11 with SMTP id 11so1091103fxm.13 for ; Tue, 17 May 2011 16:51:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=sa/OUzzXgHO12zusRu4LhrC/ofxpNQ8MIjbf3yZw48Y=; b=jTRSsyyUdsu+3Z21xCxseuZC2KFYzpKtmnk3fq4wc7PuA4s9u2iHiDL0HGBSO6ELls c0LKTC2w0mKQgzrldGQs4g9nmimHp1IN20jB8eXlFzejpH3mHTswEtaYyAhuJryEPaQ6 M/xvwyoibteqF72vyZBgOJoUV6XOlSmxWy1mg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; b=HhD3v7EniGUBioO3vNZb76iTJqCpziKZ5GYsNNFGb1vjOhKGDA8C7gIvMUVghqqnl/ k6cOb6kLv4o+jSQGCM2NT9FHbblpetI/DT/tmSp7dJTObnMcHhxXlM/fjsQd3pEOSYSR r/sFrM/jqUGwvR5l4jak6HYe4jci2bYYmdAsA= Received: by 10.223.6.11 with SMTP id 11mr1528300fax.100.1305676263804; Tue, 17 May 2011 16:51:03 -0700 (PDT) Received: from [192.168.1.86] (gtng-4d08ad6a.pool.mediaWays.net [77.8.173.106]) by mx.google.com with ESMTPS id j18sm391341faa.42.2011.05.17.16.50.59 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 17 May 2011 16:51:00 -0700 (PDT) Message-ID: <4DD309DE.4020301@gmail.com> Date: Wed, 18 May 2011 01:50:54 +0200 From: Johannes Dieterich User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110424 Thunderbird/3.1.10 MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <19EF3F42C9518C4C0FA4219F@mac-pro.magehandbook.com> In-Reply-To: <19EF3F42C9518C4C0FA4219F@mac-pro.magehandbook.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 18 May 2011 01:14:21 +0000 Subject: Re: Boot halts on Thinkpad X220 (Sandy Bridge) 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, 17 May 2011 23:51:05 -0000 On 05/17/2011 06:31 PM, Daniel Staal wrote: > > (Sorry I can't reply to anyone, I just joined the list. I saw this > discussion in the archives and thought I should join in.) > > I've managed to boot a X220i using -CURRENT as of last night. I got > some help on -questions to get it done though. From a blank machine, > you'll need either a non-USB boot device with FreeBSD media (untested) > or a USB keyboard. If you are using a USB keyboard > > set hint.atkbd.0.disabled=1 > > to install, and use the USB keyboard during installation. Then on the > first reboot in the BIOS set 'USB UEFI BIOS' to disabled. (This means > you can't boot from a USB device.) > > At that point, the machine will boot fine. I've tried 8.2-RELEASE, the > last amd64 -CURRENT I could find on the FreeBSD website, and -CURRENT as > of 2011-05-16. > > I'm building a couple of ports at the moment, and want to reboot with a > couple of config changes in the loader to see if I can get the WiFi > recognized. As soon as I do that I can post my dmesg someplace. Thanks a lot for the very valuable hint! :-) Booting the amd64 installation medium works now, I will report after the install whether the second part also works for me (but I am pretty sure of it). Thanks a lot again! :-) Johannes Dieterich From owner-freebsd-current@FreeBSD.ORG Wed May 18 06:37: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 B4FDD106564A for ; Wed, 18 May 2011 06:37:31 +0000 (UTC) (envelope-from sendtomatt@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 77F998FC0A for ; Wed, 18 May 2011 06:37:31 +0000 (UTC) Received: by iwn33 with SMTP id 33so1456319iwn.13 for ; Tue, 17 May 2011 23:37:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=QxqB5qP/BkUnqCLOwiBSrwqPpQsyZ2ICB/WJjsyqfKc=; b=riYkIXMWR3lV6VkxU2zCmz9XKtmrWtlAo9OXefUNwRYJB8YPvu3pn9WQy1H172wFZ/ 41/w+aiyUz83n1ef/cam7H2psc+Twg6JcP3guswQ7NrV3M5XtHuZijitxbDs6iR+Ki0N KENmPE92mf1L9xkvslmqw8hTRYu+L6x+wj2tw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=m+f8dhK10ueE/kjCwKoo1LrAl63sgQxyGR7gh4nw3I0qFlSRcKpyDXNkyBhwIjbhTp fy5etM6opStAhcPCzTcNcGp+HDbjnNWBy5BIKOGLLGQv2pc/BgSKSP50+RFauIFCNLYj +A96pS7GRc/RsFzrdCtPNP+/jm4wSSYmuEpDA= Received: by 10.231.210.148 with SMTP id gk20mr1119441ibb.110.1305698956716; Tue, 17 May 2011 23:09:16 -0700 (PDT) Received: from sidhe.local ([75.111.37.204]) by mx.google.com with ESMTPS id y10sm551155iba.29.2011.05.17.23.09.14 (version=SSLv3 cipher=OTHER); Tue, 17 May 2011 23:09:15 -0700 (PDT) Message-ID: <4DD3628E.5070604@gmail.com> Date: Tue, 17 May 2011 23:09:18 -0700 From: Matt User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.17) Gecko/20110502 Thunderbird/3.1.10 MIME-Version: 1.0 To: Johannes Dieterich References: <19EF3F42C9518C4C0FA4219F@mac-pro.magehandbook.com> <4DD309DE.4020301@gmail.com> In-Reply-To: <4DD309DE.4020301@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: Boot halts on Thinkpad X220 (Sandy Bridge) 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, 18 May 2011 06:37:31 -0000 On 05/17/11 16:50, Johannes Dieterich wrote: > On 05/17/2011 06:31 PM, Daniel Staal wrote: >> (Sorry I can't reply to anyone, I just joined the list. I saw this >> discussion in the archives and thought I should join in.) >> >> I've managed to boot a X220i using -CURRENT as of last night. I got >> some help on -questions to get it done though. From a blank machine, >> you'll need either a non-USB boot device with FreeBSD media (untested) >> or a USB keyboard. If you are using a USB keyboard >> >> set hint.atkbd.0.disabled=1 >> >> to install, and use the USB keyboard during installation. Then on the >> first reboot in the BIOS set 'USB UEFI BIOS' to disabled. (This means >> you can't boot from a USB device.) >> >> At that point, the machine will boot fine. I've tried 8.2-RELEASE, the >> last amd64 -CURRENT I could find on the FreeBSD website, and -CURRENT as >> of 2011-05-16. >> >> I'm building a couple of ports at the moment, and want to reboot with a >> couple of config changes in the loader to see if I can get the WiFi >> recognized. As soon as I do that I can post my dmesg someplace. > Thanks a lot for the very valuable hint! :-) Booting the amd64 > installation medium works now, I will report after the install whether > the second part also works for me (but I am pretty sure of it). > > Thanks a lot again! :-) > > Johannes Dieterich > _______________________________________________ > 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" > I'm not on a sandy bridge, but a core2 based lenovo thinkpad (SL410, I seem to have this thing fully supported finally...f-keys, sd card etc!). I've noticed that BTX halts about 60% of the time for me via DVD. My keyboard also does not work at login prompt or elsewhere (during fsck...faster!) until after about 2-3 keypresses, after which it's fine. BTX via CD/DVD actually seems to work better if i start impatiently hitting the keyboard when "-" appears. I'm not sure if this is a related issue. I also had amd64 btx problems on a Dell desktop, so it might be a SATA/scsi/cam timeout thing. Never had a problem on server hardware, although most of those boxes were Opterons (and thus associated chipsets). I've come to view FreeBSD dvd boots as a form of gambling. Matt From owner-freebsd-current@FreeBSD.ORG Wed May 18 07:41: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 4B7D7106566C; Wed, 18 May 2011 07:41:49 +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 2E8AF8FC1C; Wed, 18 May 2011 07:41:47 +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 KAA13177; Wed, 18 May 2011 10:41:45 +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 1QMbO5-000ANC-JL; Wed, 18 May 2011 10:41:45 +0300 Message-ID: <4DD37837.3060408@FreeBSD.org> Date: Wed, 18 May 2011 10:41:43 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.17) Gecko/20110503 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: freebsd-usb@FreeBSD.org, "freebsd-current@FreeBSD.org" References: <201104051321.56319.hselasky@freebsd.org> <201104060933.47350.hselasky@freebsd.org> <4D9C68CF.1060101@FreeBSD.org> <201104061528.13220.hselasky@freebsd.org> <4DD2216F.6080908@FreeBSD.org> In-Reply-To: <4DD2216F.6080908@FreeBSD.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: 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, 18 May 2011 07:41:49 -0000 on 17/05/2011 10:19 Andriy Gapon said the following: > So I am going to commit this. > If it breaks anything for anyone and the problem would not be really trivial, > the I'll just revert the change. > r222051. Please take this commit in consideration if you run into any USB-related problems. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Wed May 18 08:24:59 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 7357E1065672; Wed, 18 May 2011 08:24:59 +0000 (UTC) Date: Wed, 18 May 2011 08:24:59 +0000 From: Alexander Best To: freebsd-current@freebsd.org Message-ID: <20110518082459.GA71662@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Cc: freebsd-cam@freebsd.org Subject: issues with new sata dvd-drive 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, 18 May 2011 08:24:59 -0000 hi there, i recently switched my old pata dvd-drive with a new sata one: cd0: Removable CD-ROM SCSI-0 device cd0: 150.000MB/s transfers (SATA 1.x, UDMA5, ATAPI 12bytes, PIO 8192bytes) cd0: cd present [355062 x 2048 byte records] however now i experience the following issues: 1) otaku% recoverdisk /dev/cd0 ~/test.iso Bigsize = 1048576, medsize = 65536, minsize = 2048 start size block-len state done remaining % done 617611264 514048 514048 0 617611264 514048 99.91684 617611264 514048 failed (Device not configured) 2) otaku% dd if=/dev/cd0 of=/home/arundel/test.iso bs=1048576 dd: /dev/cd0: Device not configured 589+0 records in 589+0 records out 617611264 bytes transferred in 120.144189 secs (5140584 bytes/sec) 3) otaku% dd if=/dev/cd0 of=/home/arundel/test.iso bs=65536 dd: /dev/cd0: Device not configured 9431+0 records in 9431+0 records out 618070016 bytes transferred in 120.345870 secs (5135781 bytes/sec) 4) otaku% dd if=/dev/cd0 of=/home/arundel/test.iso bs=2048 load: 0.20 cmd: dd 50488 [physrd] 219.96r 0.17u 8.41s 1% 1016k 203127+0 records in 203127+0 records out 416004096 bytes transferred in 219.746150 secs (1893112 bytes/sec) dd: /dev/cd0: Device not configured 301817+0 records in 301817+0 records out 618121216 bytes transferred in 371.835266 secs (1662352 bytes/sec) ...also when issuing this command (4)), at some point the drive starts spinning down and then up again several times. this doesn't happen with a larger blocksize (see 1-3)). i hit ctrl+t at the exact moment the drive started spinning down the first time. i'm seeing the following warnings via dmesg: (cd0:ahcich2:0:0:0): READ(10). CDB: 28 0 0 4 9a c0 0 0 3b 0 (cd0:ahcich2:0:0:0): CAM status: SCSI Status Error (cd0:ahcich2:0:0:0): SCSI status: Check Condition (cd0:ahcich2:0:0:0): SCSI sense: ILLEGAL REQUEST csi:28,a,0,80 asc:64,0 (Illegal mode for this track) (cd0:ahcich2:0:0:0): cddone: got error 0x6 back (cd0:ahcich2:0:0:0): READ(10). CDB: 28 0 0 4 9a c0 0 0 3b 0 (cd0:ahcich2:0:0:0): CAM status: SCSI Status Error (cd0:ahcich2:0:0:0): SCSI status: Check Condition (cd0:ahcich2:0:0:0): SCSI sense: ILLEGAL REQUEST csi:28,a,0,80 asc:64,0 (Illegal mode for this track) (cd0:ahcich2:0:0:0): cddone: got error 0x6 back (cd0:ahcich2:0:0:0): READ(10). CDB: 28 0 0 4 9a c0 0 0 3b 0 (cd0:ahcich2:0:0:0): CAM status: SCSI Status Error (cd0:ahcich2:0:0:0): SCSI status: Check Condition (cd0:ahcich2:0:0:0): SCSI sense: ILLEGAL REQUEST csi:28,a,0,80 asc:64,0 (Illegal mode for this track) (cd0:ahcich2:0:0:0): cddone: got error 0x6 back i'm running a recent HEAD (r221878) on amd64. my kernel contains device ahci device scbus device cd device pass this my sata controller: ahci0: port 0xe600-0xe607,0xe700-0xe703,0xe800-0xe807,0xe900-0xe903,0xea00-0xea1f mem 0xfa206000-0xfa2067ff irq 19 at device 31.2 on pci0 ahci0: AHCI v1.20 with 6 3Gbps ports, Port Multiplier supported two other issues i'm experiencing (if their really are issues and not me doing something wrong are: 1) when running cdrecord(1) to burn a DVD (DVD+R) i get the following warning: cdrecord: DMA speed too slow (OK for 10x). Cannot write at speed 18x. 2) otaku% sudo cdrecord blank=fast Cdrecord-ProDVD-ProBD-Clone 3.01a04 (amd64-unknown-freebsd9.0) Copyright (C) 1995-2010 Joerg Schilling Using libscg version 'schily-0.9'. No target specified, trying to find one... Using dev=2,0,0. Device type : Removable CD-ROM Version : 0 Response Format: 2 Capabilities : Vendor_info : 'HL-DT-ST' Identifikation : 'DVDRAM GH24NS50 ' Revision : 'XP02' Device seems to be: Generic mmc2 DVD-R/DVD-RW/DVD-RAM. Using generic SCSI-3/mmc CD-R/CD-RW driver (mmc_cdr). Driver flags : MMC-3 SWABAUDIO BURNFREE Supported modes: TAO PACKET SAO SAO/R96P SAO/R96R RAW/R16 RAW/R96P RAW/R96R LAYER_JUMP Starting to write CD/DVD/BD at speed 4 in real BLANK mode for single session. Last chance to quit, starting real write 0 seconds. Operation starts. taku% dd if=/dev/random of=./test.file bs=1m count=10 10+0 records in 10+0 records out 10485760 bytes transferred in 0.635699 secs (16494850 bytes/sec) otaku% sudo cdrecord test.file cdrecord: No write mode specified. cdrecord: Assuming -sao mode. cdrecord: If your drive does not accept -sao, try -tao. cdrecord: Future versions of cdrecord may have different drive dependent defaults. Cdrecord-ProDVD-ProBD-Clone 3.01a04 (amd64-unknown-freebsd9.0) Copyright (C) 1995-2010 Joerg Schilling Using libscg version 'schily-0.9'. No target specified, trying to find one... Using dev=2,0,0. Device type : Removable CD-ROM Version : 0 Response Format: 2 Capabilities : Vendor_info : 'HL-DT-ST' Identifikation : 'DVDRAM GH24NS50 ' Revision : 'XP02' Device seems to be: Generic mmc2 DVD-R/DVD-RW/DVD-RAM. Using generic SCSI-3/mmc CD-R/CD-RW driver (mmc_cdr). Driver flags : MMC-3 SWABAUDIO BURNFREE Supported modes: TAO PACKET SAO SAO/R96P SAO/R96R RAW/R16 RAW/R96P RAW/R96R LAYER_JUMP Starting to write CD/DVD/BD at speed 4 in real SAO mode for single session. Last chance to quit, starting real write 0 seconds. Operation starts. Turning BURN-Free off cdrecord: WARNING: Drive returns wrong startsec (0) using -150 Track 01: Total bytes read/written: 10485760/10485760 (5120 sectors). otaku% dd if=/dev/cd0 of=./test.dao bs=1m count=10 10+0 records in 10+0 records out 10485760 bytes transferred in 9.587938 secs (1093641 bytes/sec) otaku% sudo cdrecord blank=fast Cdrecord-ProDVD-ProBD-Clone 3.01a04 (amd64-unknown-freebsd9.0) Copyright (C) 1995-2010 Joerg Schilling Using libscg version 'schily-0.9'. No target specified, trying to find one... Using dev=2,0,0. Device type : Removable CD-ROM Version : 0 Response Format: 2 Capabilities : Vendor_info : 'HL-DT-ST' Identifikation : 'DVDRAM GH24NS50 ' Revision : 'XP02' Device seems to be: Generic mmc2 DVD-R/DVD-RW/DVD-RAM. Using generic SCSI-3/mmc CD-R/CD-RW driver (mmc_cdr). Driver flags : MMC-3 SWABAUDIO BURNFREE Supported modes: TAO PACKET SAO SAO/R96P SAO/R96R RAW/R16 RAW/R96P RAW/R96R LAYER_JUMP Starting to write CD/DVD/BD at speed 4 in real BLANK mode for single session. Last chance to quit, starting real write 0 seconds. Operation starts. otaku% sudo cdrecord -tao test.file Cdrecord-ProDVD-ProBD-Clone 3.01a04 (amd64-unknown-freebsd9.0) Copyright (C) 1995-2010 Joerg Schilling Using libscg version 'schily-0.9'. No target specified, trying to find one... Using dev=2,0,0. Device type : Removable CD-ROM Version : 0 Response Format: 2 Capabilities : Vendor_info : 'HL-DT-ST' Identifikation : 'DVDRAM GH24NS50 ' Revision : 'XP02' Device seems to be: Generic mmc2 DVD-R/DVD-RW/DVD-RAM. Using generic SCSI-3/mmc CD-R/CD-RW driver (mmc_cdr). Driver flags : MMC-3 SWABAUDIO BURNFREE Supported modes: TAO PACKET SAO SAO/R96P SAO/R96R RAW/R16 RAW/R96P RAW/R96R LAYER_JUMP Starting to write CD/DVD/BD at speed 4 in real TAO mode for single session. Last chance to quit, starting real write 0 seconds. Operation starts. Track 01: Total bytes read/written: 10485760/10485760 (5120 sectors). otaku% dd if=/dev/cd0 of=./test.tao bs=1m count=10 10+0 records in 10+0 records out 10485760 bytes transferred in 6.694222 secs (1566390 bytes/sec) otaku% diff test.file test.dao otaku% diff test.file test.tao ...so eventually nothing gets broken by the warning about the wrong startsec. cheers. alex -- a13x From owner-freebsd-current@FreeBSD.ORG Wed May 18 08:27:47 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 616BC106566B; Wed, 18 May 2011 08:27:47 +0000 (UTC) Date: Wed, 18 May 2011 08:27:47 +0000 From: Alexander Best To: freebsd-current@freebsd.org Message-ID: <20110518082747.GA75790@freebsd.org> References: <20110518082459.GA71662@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110518082459.GA71662@freebsd.org> Cc: freebsd-scsi@freebsd.org Subject: Re: issues with new sata dvd-drive 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, 18 May 2011 08:27:47 -0000 sorry. i wanted to cc freebsd-scsi and accidently wrote freebsd-cam. On Wed May 18 11, Alexander Best wrote: > hi there, > > i recently switched my old pata dvd-drive with a new sata one: > > cd0: Removable CD-ROM SCSI-0 device > cd0: 150.000MB/s transfers (SATA 1.x, UDMA5, ATAPI 12bytes, PIO 8192bytes) > cd0: cd present [355062 x 2048 byte records] > > however now i experience the following issues: > > 1) > otaku% recoverdisk /dev/cd0 ~/test.iso > Bigsize = 1048576, medsize = 65536, minsize = 2048 > start size block-len state done remaining % done > 617611264 514048 514048 0 617611264 514048 99.91684 > 617611264 514048 failed (Device not configured) > > 2) > otaku% dd if=/dev/cd0 of=/home/arundel/test.iso bs=1048576 > dd: /dev/cd0: Device not configured > 589+0 records in > 589+0 records out > 617611264 bytes transferred in 120.144189 secs (5140584 bytes/sec) > > 3) > otaku% dd if=/dev/cd0 of=/home/arundel/test.iso bs=65536 > dd: /dev/cd0: Device not configured > 9431+0 records in > 9431+0 records out > 618070016 bytes transferred in 120.345870 secs (5135781 bytes/sec) > > 4) > otaku% dd if=/dev/cd0 of=/home/arundel/test.iso bs=2048 > load: 0.20 cmd: dd 50488 [physrd] 219.96r 0.17u 8.41s 1% 1016k > 203127+0 records in > 203127+0 records out > 416004096 bytes transferred in 219.746150 secs (1893112 bytes/sec) > dd: /dev/cd0: Device not configured > 301817+0 records in > 301817+0 records out > 618121216 bytes transferred in 371.835266 secs (1662352 bytes/sec) > > ...also when issuing this command (4)), at some point the drive starts spinning > down and then up again several times. this doesn't happen with a larger > blocksize (see 1-3)). i hit ctrl+t at the exact moment the drive started > spinning down the first time. > > i'm seeing the following warnings via dmesg: > > (cd0:ahcich2:0:0:0): READ(10). CDB: 28 0 0 4 9a c0 0 0 3b 0 > (cd0:ahcich2:0:0:0): CAM status: SCSI Status Error > (cd0:ahcich2:0:0:0): SCSI status: Check Condition > (cd0:ahcich2:0:0:0): SCSI sense: ILLEGAL REQUEST csi:28,a,0,80 asc:64,0 (Illegal mode for this track) > (cd0:ahcich2:0:0:0): cddone: got error 0x6 back > (cd0:ahcich2:0:0:0): READ(10). CDB: 28 0 0 4 9a c0 0 0 3b 0 > (cd0:ahcich2:0:0:0): CAM status: SCSI Status Error > (cd0:ahcich2:0:0:0): SCSI status: Check Condition > (cd0:ahcich2:0:0:0): SCSI sense: ILLEGAL REQUEST csi:28,a,0,80 asc:64,0 (Illegal mode for this track) > (cd0:ahcich2:0:0:0): cddone: got error 0x6 back > (cd0:ahcich2:0:0:0): READ(10). CDB: 28 0 0 4 9a c0 0 0 3b 0 > (cd0:ahcich2:0:0:0): CAM status: SCSI Status Error > (cd0:ahcich2:0:0:0): SCSI status: Check Condition > (cd0:ahcich2:0:0:0): SCSI sense: ILLEGAL REQUEST csi:28,a,0,80 asc:64,0 (Illegal mode for this track) > (cd0:ahcich2:0:0:0): cddone: got error 0x6 back > > i'm running a recent HEAD (r221878) on amd64. my kernel contains > > device ahci > device scbus > device cd > device pass > > this my sata controller: > > ahci0: port 0xe600-0xe607,0xe700-0xe703,0xe800-0xe807,0xe900-0xe903,0xea00-0xea1f mem 0xfa206000-0xfa2067ff irq 19 at device 31.2 on pci0 > ahci0: AHCI v1.20 with 6 3Gbps ports, Port Multiplier supported > > two other issues i'm experiencing (if their really are issues and not me doing > something wrong are: > > 1) > when running cdrecord(1) to burn a DVD (DVD+R) i get the following warning: > > cdrecord: DMA speed too slow (OK for 10x). Cannot write at speed 18x. > > 2) > otaku% sudo cdrecord blank=fast > Cdrecord-ProDVD-ProBD-Clone 3.01a04 (amd64-unknown-freebsd9.0) Copyright (C) 1995-2010 Joerg Schilling > Using libscg version 'schily-0.9'. > No target specified, trying to find one... > Using dev=2,0,0. > Device type : Removable CD-ROM > Version : 0 > Response Format: 2 > Capabilities : > Vendor_info : 'HL-DT-ST' > Identifikation : 'DVDRAM GH24NS50 ' > Revision : 'XP02' > Device seems to be: Generic mmc2 DVD-R/DVD-RW/DVD-RAM. > Using generic SCSI-3/mmc CD-R/CD-RW driver (mmc_cdr). > Driver flags : MMC-3 SWABAUDIO BURNFREE > Supported modes: TAO PACKET SAO SAO/R96P SAO/R96R RAW/R16 RAW/R96P RAW/R96R LAYER_JUMP > Starting to write CD/DVD/BD at speed 4 in real BLANK mode for single session. > Last chance to quit, starting real write 0 seconds. Operation starts. > > taku% dd if=/dev/random of=./test.file bs=1m count=10 > 10+0 records in > 10+0 records out > 10485760 bytes transferred in 0.635699 secs (16494850 bytes/sec) > > otaku% sudo cdrecord test.file > cdrecord: No write mode specified. > cdrecord: Assuming -sao mode. > cdrecord: If your drive does not accept -sao, try -tao. > cdrecord: Future versions of cdrecord may have different drive dependent defaults. > Cdrecord-ProDVD-ProBD-Clone 3.01a04 (amd64-unknown-freebsd9.0) Copyright (C) 1995-2010 Joerg Schilling > Using libscg version 'schily-0.9'. > No target specified, trying to find one... > Using dev=2,0,0. > Device type : Removable CD-ROM > Version : 0 > Response Format: 2 > Capabilities : > Vendor_info : 'HL-DT-ST' > Identifikation : 'DVDRAM GH24NS50 ' > Revision : 'XP02' > Device seems to be: Generic mmc2 DVD-R/DVD-RW/DVD-RAM. > Using generic SCSI-3/mmc CD-R/CD-RW driver (mmc_cdr). > Driver flags : MMC-3 SWABAUDIO BURNFREE > Supported modes: TAO PACKET SAO SAO/R96P SAO/R96R RAW/R16 RAW/R96P RAW/R96R LAYER_JUMP > Starting to write CD/DVD/BD at speed 4 in real SAO mode for single session. > Last chance to quit, starting real write 0 seconds. Operation starts. > Turning BURN-Free off > cdrecord: WARNING: Drive returns wrong startsec (0) using -150 > Track 01: Total bytes read/written: 10485760/10485760 (5120 sectors). > > otaku% dd if=/dev/cd0 of=./test.dao bs=1m count=10 > 10+0 records in > 10+0 records out > 10485760 bytes transferred in 9.587938 secs (1093641 bytes/sec) > > otaku% sudo cdrecord blank=fast > Cdrecord-ProDVD-ProBD-Clone 3.01a04 (amd64-unknown-freebsd9.0) Copyright (C) 1995-2010 Joerg Schilling > Using libscg version 'schily-0.9'. > No target specified, trying to find one... > Using dev=2,0,0. > Device type : Removable CD-ROM > Version : 0 > Response Format: 2 > Capabilities : > Vendor_info : 'HL-DT-ST' > Identifikation : 'DVDRAM GH24NS50 ' > Revision : 'XP02' > Device seems to be: Generic mmc2 DVD-R/DVD-RW/DVD-RAM. > Using generic SCSI-3/mmc CD-R/CD-RW driver (mmc_cdr). > Driver flags : MMC-3 SWABAUDIO BURNFREE > Supported modes: TAO PACKET SAO SAO/R96P SAO/R96R RAW/R16 RAW/R96P RAW/R96R LAYER_JUMP > Starting to write CD/DVD/BD at speed 4 in real BLANK mode for single session. > Last chance to quit, starting real write 0 seconds. Operation starts. > > otaku% sudo cdrecord -tao test.file > Cdrecord-ProDVD-ProBD-Clone 3.01a04 (amd64-unknown-freebsd9.0) Copyright (C) 1995-2010 Joerg Schilling > Using libscg version 'schily-0.9'. > No target specified, trying to find one... > Using dev=2,0,0. > Device type : Removable CD-ROM > Version : 0 > Response Format: 2 > Capabilities : > Vendor_info : 'HL-DT-ST' > Identifikation : 'DVDRAM GH24NS50 ' > Revision : 'XP02' > Device seems to be: Generic mmc2 DVD-R/DVD-RW/DVD-RAM. > Using generic SCSI-3/mmc CD-R/CD-RW driver (mmc_cdr). > Driver flags : MMC-3 SWABAUDIO BURNFREE > Supported modes: TAO PACKET SAO SAO/R96P SAO/R96R RAW/R16 RAW/R96P RAW/R96R LAYER_JUMP > Starting to write CD/DVD/BD at speed 4 in real TAO mode for single session. > Last chance to quit, starting real write 0 seconds. Operation starts. > Track 01: Total bytes read/written: 10485760/10485760 (5120 sectors). > otaku% dd if=/dev/cd0 of=./test.tao bs=1m count=10 > 10+0 records in > 10+0 records out > 10485760 bytes transferred in 6.694222 secs (1566390 bytes/sec) > > otaku% diff test.file test.dao > > otaku% diff test.file test.tao > > ...so eventually nothing gets broken by the warning about the wrong startsec. > > cheers. > alex > > -- > a13x > -- a13x From owner-freebsd-current@FreeBSD.ORG Wed May 18 09: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 9EA69106566B; Wed, 18 May 2011 09:34:17 +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 75ADF8FC0A; Wed, 18 May 2011 09:34:16 +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 MAA15794; Wed, 18 May 2011 12:34:15 +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 1QMd8w-000ARr-Mj; Wed, 18 May 2011 12:34:14 +0300 Message-ID: <4DD39296.2090805@FreeBSD.org> Date: Wed, 18 May 2011 12:34:14 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.17) Gecko/20110503 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Alexander Best References: <20110518082459.GA71662@freebsd.org> <20110518082747.GA75790@freebsd.org> In-Reply-To: <20110518082747.GA75790@freebsd.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-scsi@FreeBSD.org, freebsd-current@FreeBSD.org Subject: Re: issues with new sata dvd-drive 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, 18 May 2011 09:34:17 -0000 on 18/05/2011 11:27 Alexander Best said the following: > sorry. i wanted to cc freebsd-scsi and accidently wrote freebsd-cam. > > On Wed May 18 11, Alexander Best wrote: >> hi there, >> >> i recently switched my old pata dvd-drive with a new sata one: >> >> cd0: Removable CD-ROM SCSI-0 device >> cd0: 150.000MB/s transfers (SATA 1.x, UDMA5, ATAPI 12bytes, PIO 8192bytes) >> cd0: cd present [355062 x 2048 byte records] >> >> however now i experience the following issues: Just some sanity checks: 1. does the same happen with any media you try? 2. does the same not happen with the media you tried with any other drive? -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Wed May 18 10:08:06 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 01CC11065673; Wed, 18 May 2011 10:08:06 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id C7B498FC18; Wed, 18 May 2011 10:08:05 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.4) with ESMTP id p4IA84Ri087583; Wed, 18 May 2011 06:08:04 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.4/Submit) id p4IA84kx087512; Wed, 18 May 2011 10:08:04 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 18 May 2011 10:08:04 GMT Message-Id: <201105181008.p4IA84kx087512@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2011 10:08:06 -0000 TB --- 2011-05-18 08:56:59 - tinderbox 2.7 running on freebsd-current.sentex.ca TB --- 2011-05-18 08:56:59 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2011-05-18 08:56:59 - cleaning the object tree TB --- 2011-05-18 08:57:10 - cvsupping the source tree TB --- 2011-05-18 08:57:10 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2011-05-18 08:57:32 - building world TB --- 2011-05-18 08:57:32 - MAKEOBJDIRPREFIX=/obj TB --- 2011-05-18 08:57:32 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-05-18 08:57:32 - TARGET=sparc64 TB --- 2011-05-18 08:57:32 - TARGET_ARCH=sparc64 TB --- 2011-05-18 08:57:32 - TZ=UTC TB --- 2011-05-18 08:57:32 - __MAKE_CONF=/dev/null TB --- 2011-05-18 08:57:32 - cd /src TB --- 2011-05-18 08:57:32 - /usr/bin/make -B buildworld >>> World build started on Wed May 18 08:57:33 UTC 2011 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Wed May 18 09:57:27 UTC 2011 TB --- 2011-05-18 09:57:27 - generating LINT kernel config TB --- 2011-05-18 09:57:27 - cd /src/sys/sparc64/conf TB --- 2011-05-18 09:57:27 - /usr/bin/make -B LINT TB --- 2011-05-18 09:57:27 - building LINT kernel TB --- 2011-05-18 09:57:27 - MAKEOBJDIRPREFIX=/obj TB --- 2011-05-18 09:57:27 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-05-18 09:57:27 - TARGET=sparc64 TB --- 2011-05-18 09:57:27 - TARGET_ARCH=sparc64 TB --- 2011-05-18 09:57:27 - TZ=UTC TB --- 2011-05-18 09:57:27 - __MAKE_CONF=/dev/null TB --- 2011-05-18 09:57:27 - cd /src TB --- 2011-05-18 09:57:27 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed May 18 09:57:27 UTC 2011 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/netgraph/atm/sscfu/ng_sscfu.c -I/src/sys/contrib/ngatm cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/netgraph/atm/sscop/ng_sscop.c -I/src/sys/contrib/ngatm cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/netgraph/atm/uni/ng_uni.c -I/src/sys/contrib/ngatm cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/netgraph/bluetooth/common/ng_bluetooth.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/netgraph/bluetooth/drivers/bt3c/ng_bt3c_pccard.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/netgraph/bluetooth/drivers/ubt/ng_ubt.c /src/sys/netgraph/bluetooth/drivers/ubt/ng_ubt.c: In function 'ubt_probe': /src/sys/netgraph/bluetooth/drivers/ubt/ng_ubt.c:419: error: 'struct usb_attach_arg' has no member named 'use_generic' *** Error code 1 Stop in /obj/sparc64.sparc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-05-18 10:08:04 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-05-18 10:08:04 - ERROR: failed to build lint kernel TB --- 2011-05-18 10:08:04 - 3369.79 user 703.09 system 4265.46 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Wed May 18 10:24:49 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 0D5FA1065670; Wed, 18 May 2011 10:24:49 +0000 (UTC) Date: Wed, 18 May 2011 10:24:49 +0000 From: Alexander Best To: Andriy Gapon Message-ID: <20110518102448.GA88446@freebsd.org> References: <20110518082459.GA71662@freebsd.org> <20110518082747.GA75790@freebsd.org> <4DD39296.2090805@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4DD39296.2090805@FreeBSD.org> Cc: freebsd-scsi@FreeBSD.org, freebsd-current@FreeBSD.org Subject: Re: issues with new sata dvd-drive 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, 18 May 2011 10:24:49 -0000 On Wed May 18 11, Andriy Gapon wrote: > on 18/05/2011 11:27 Alexander Best said the following: > > sorry. i wanted to cc freebsd-scsi and accidently wrote freebsd-cam. > > > > On Wed May 18 11, Alexander Best wrote: > >> hi there, > >> > >> i recently switched my old pata dvd-drive with a new sata one: > >> > >> cd0: Removable CD-ROM SCSI-0 device > >> cd0: 150.000MB/s transfers (SATA 1.x, UDMA5, ATAPI 12bytes, PIO 8192bytes) > >> cd0: cd present [355062 x 2048 byte records] > >> > >> however now i experience the following issues: > > Just some sanity checks: > 1. does the same happen with any media you try? > 2. does the same not happen with the media you tried with any other drive? i dug into this a little further and it appears that this only happens with CD-Rs. using CD-ROMs, DVDs or DVD+Rs this doesn't happen. i tested this with CD-Rs recorded under windows and freebsd (created with burncd(1), growisofs(1) and cdrecord(1)) and they all suffer the same issue. i also tried this with audio cds and here recoverdisk(1) fails no matter, if it's a CD-R or a CD-ROM: otaku% recoverdisk /dev/cd0 ./test10.iso Bigsize = 1048576, medsize = 65536, minsize = 2048 start size block-len state done remaining % done 0 1048576 243052544 0 0 243052544 0.00000 0 1048576 failed (Device not configured) cheers. alex > > -- > Andriy Gapon -- a13x From owner-freebsd-current@FreeBSD.ORG Wed May 18 10:30:17 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C0FC2106564A; Wed, 18 May 2011 10:30:17 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 9073E8FC19; Wed, 18 May 2011 10:30:17 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.4) with ESMTP id p4IAUGjG075176; Wed, 18 May 2011 06:30:16 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.4/Submit) id p4IAUGC0075161; Wed, 18 May 2011 10:30:16 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 18 May 2011 10:30:16 GMT Message-Id: <201105181030.p4IAUGC0075161@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on powerpc64/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2011 10:30:17 -0000 TB --- 2011-05-18 08:49:33 - tinderbox 2.7 running on freebsd-current.sentex.ca TB --- 2011-05-18 08:49:33 - starting HEAD tinderbox run for powerpc64/powerpc TB --- 2011-05-18 08:49:33 - cleaning the object tree TB --- 2011-05-18 08:49:53 - cvsupping the source tree TB --- 2011-05-18 08:49:53 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc64/powerpc/supfile TB --- 2011-05-18 08:50:28 - building world TB --- 2011-05-18 08:50:28 - MAKEOBJDIRPREFIX=/obj TB --- 2011-05-18 08:50:28 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-05-18 08:50:28 - TARGET=powerpc TB --- 2011-05-18 08:50:28 - TARGET_ARCH=powerpc64 TB --- 2011-05-18 08:50:28 - TZ=UTC TB --- 2011-05-18 08:50:28 - __MAKE_CONF=/dev/null TB --- 2011-05-18 08:50:28 - cd /src TB --- 2011-05-18 08:50:28 - /usr/bin/make -B buildworld >>> World build started on Wed May 18 08:50:28 UTC 2011 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Wed May 18 10:20:09 UTC 2011 TB --- 2011-05-18 10:20:09 - generating LINT kernel config TB --- 2011-05-18 10:20:09 - cd /src/sys/powerpc/conf TB --- 2011-05-18 10:20:09 - /usr/bin/make -B LINT TB --- 2011-05-18 10:20:09 - building LINT kernel TB --- 2011-05-18 10:20:09 - MAKEOBJDIRPREFIX=/obj TB --- 2011-05-18 10:20:09 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-05-18 10:20:09 - TARGET=powerpc TB --- 2011-05-18 10:20:09 - TARGET_ARCH=powerpc64 TB --- 2011-05-18 10:20:09 - TZ=UTC TB --- 2011-05-18 10:20:09 - __MAKE_CONF=/dev/null TB --- 2011-05-18 10:20:09 - cd /src TB --- 2011-05-18 10:20:09 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed May 18 10:20:09 UTC 2011 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -mno-altivec -mcall-aixdesc -ffreestanding -fstack-protector -Werror /src/sys/netgraph/atm/sscfu/ng_sscfu.c -I/src/sys/contrib/ngatm cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -mno-altivec -mcall-aixdesc -ffreestanding -fstack-protector -Werror /src/sys/netgraph/atm/sscop/ng_sscop.c -I/src/sys/contrib/ngatm cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -mno-altivec -mcall-aixdesc -ffreestanding -fstack-protector -Werror /src/sys/netgraph/atm/uni/ng_uni.c -I/src/sys/contrib/ngatm cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -mno-altivec -mcall-aixdesc -ffreestanding -fstack-protector -Werror /src/sys/netgraph/bluetooth/common/ng_bluetooth.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -mno-altivec -mcall-aixdesc -ffreestanding -fstack-protector -Werror /src/sys/netgraph/bluetooth/drivers/bt3c/ng_bt3c_pccard.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -mno-altivec -mcall-aixdesc -ffreestanding -fstack-protector -Werror /src/sys/netgraph/bluetooth/drivers/ubt/ng_ubt.c /src/sys/netgraph/bluetooth/drivers/ubt/ng_ubt.c: In function 'ubt_probe': /src/sys/netgraph/bluetooth/drivers/ubt/ng_ubt.c:419: error: 'struct usb_attach_arg' has no member named 'use_generic' *** Error code 1 Stop in /obj/powerpc.powerpc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-05-18 10:30:16 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-05-18 10:30:16 - ERROR: failed to build lint kernel TB --- 2011-05-18 10:30:16 - 4795.84 user 1017.29 system 6042.97 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc64-powerpc.full From owner-freebsd-current@FreeBSD.ORG Wed May 18 11:23:11 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 0AB55106566B; Wed, 18 May 2011 11:23:11 +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 E4DB78FC12; Wed, 18 May 2011 11:23:09 +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 OAA18829; Wed, 18 May 2011 14:23:08 +0300 (EEST) (envelope-from avg@FreeBSD.org) Message-ID: <4DD3AC1B.9080208@FreeBSD.org> Date: Wed, 18 May 2011 14:23:07 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.17) Gecko/20110504 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Alexander Best References: <20110518082459.GA71662@freebsd.org> <20110518082747.GA75790@freebsd.org> <4DD39296.2090805@FreeBSD.org> <20110518102448.GA88446@freebsd.org> In-Reply-To: <20110518102448.GA88446@freebsd.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-scsi@FreeBSD.org, freebsd-current@FreeBSD.org Subject: Re: issues with new sata dvd-drive 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, 18 May 2011 11:23:11 -0000 on 18/05/2011 13:24 Alexander Best said the following: > i dug into this a little further and it appears that this only happens with > CD-Rs. using CD-ROMs, DVDs or DVD+Rs this doesn't happen. i tested this with > CD-Rs recorded under windows and freebsd (created with burncd(1), growisofs(1) > and cdrecord(1)) and they all suffer the same issue. Are the CD-Rs from the same vendor/batch? Could it possibly be that there is some problem with firmware recognizing those disks? > i also tried this with audio cds and here recoverdisk(1) fails no matter, if > it's a CD-R or a CD-ROM: I think that it's not supposed to work for Audio-CDs with cd(4) [unlike acd(4) and then with bs of 2352]. To digitally extract audio data you have to go via pass(4) and appropriate SCSI/MMC commands. > otaku% recoverdisk /dev/cd0 ./test10.iso > Bigsize = 1048576, medsize = 65536, minsize = 2048 > start size block-len state done remaining % done > 0 1048576 243052544 0 0 243052544 0.00000 > 0 1048576 failed (Device not configured) -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Wed May 18 12:07:50 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 76DA71065670; Wed, 18 May 2011 12:07:50 +0000 (UTC) Date: Wed, 18 May 2011 12:07:50 +0000 From: Alexander Best To: Andriy Gapon Message-ID: <20110518120750.GA2642@freebsd.org> References: <20110518082459.GA71662@freebsd.org> <20110518082747.GA75790@freebsd.org> <4DD39296.2090805@FreeBSD.org> <20110518102448.GA88446@freebsd.org> <4DD3AC1B.9080208@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4DD3AC1B.9080208@FreeBSD.org> Cc: freebsd-scsi@FreeBSD.org, freebsd-current@FreeBSD.org Subject: Re: issues with new sata dvd-drive 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, 18 May 2011 12:07:50 -0000 On Wed May 18 11, Andriy Gapon wrote: > on 18/05/2011 13:24 Alexander Best said the following: > > i dug into this a little further and it appears that this only happens with > > CD-Rs. using CD-ROMs, DVDs or DVD+Rs this doesn't happen. i tested this with > > CD-Rs recorded under windows and freebsd (created with burncd(1), growisofs(1) > > and cdrecord(1)) and they all suffer the same issue. > > Are the CD-Rs from the same vendor/batch? > Could it possibly be that there is some problem with firmware recognizing those disks? > > > i also tried this with audio cds and here recoverdisk(1) fails no matter, if > > it's a CD-R or a CD-ROM: > > I think that it's not supposed to work for Audio-CDs with cd(4) [unlike acd(4) and > then with bs of 2352]. > To digitally extract audio data you have to go via pass(4) and appropriate > SCSI/MMC commands. i ran cdda2wav(1) and also got an error with a CD-R audio cd: No target specified, trying to find one... Using dev=2,0,0. Type: ROM, Vendor 'HL-DT-ST' Model 'DVDRAM GH24NS50 ' Revision 'XP02' MMC+CDDA 307200 bytes buffer memory requested, transfer size 65536 bytes, 4 buffers, 27 sectors #Cdda2wav version 3.01a04_freebsd_9.0-current_amd64_amd64, real time sched., soundcard, libparanoia support AUDIOtrack pre-emphasis copy-permitted tracktype channels 1-14 no no audio 2 Table of Contents: total tracks:14, (total time 60:03.00) 1.( 4:31.10), 2.( 3:07.55), 3.( 3:31.07), 4.( 3:46.15), 5.( 4:37.00), 6.( 3:36.63), 7.( 6:40.32), 8.( 3:24.18), 9.( 4:34.67), 10.( 4:25.38), 11.( 4:16.70), 12.( 4:11.12), 13.( 3:48.15), 14.( 5:31.48) Table of Contents: starting sectors 1.( 0), 2.( 20335), 3.( 34415), 4.( 50247), 5.( 67212), 6.( 87987), 7.( 104250), 8.( 134282), 9.( 149600), 10.( 170217), 11.( 190130), 12.( 209400), 13.( 228237), 14.( 245352), lead-out( 270225) CDINDEX discid: qYTN3dI8JolIM00IDYXcVYWwNYw- CDDB discid: 0xd60e130e CD-Text: not detected CD-Extra: not detected No media catalog number present. scanning for ISRCs: 14 ... index scan: 14...cdda2wav: Could not find index transition for pre-gap. samplefile size will be 635569244 bytes. recording 3603.0000 seconds stereo with 16 bits @ 44100.0 Hz ->'audio'... percent_done: 100% track 1 recorded successfully 100% track 2 recorded successfully 100% track 3 recorded successfully 100% track 4 recorded successfully 100% track 5 recorded successfully 100% track 6 recorded successfully 100% track 7 recorded successfully 100% track 8 recorded successfully 100% track 9 recorded successfully 100% track 10 recorded successfully 100% track 11 recorded successfully 100% track 12 recorded successfully 100% track 13 recorded successfully 99%cdda2wav: Input/output error. ReadCD MMC 12: scsi sendcmd: retryable error CDB: BE 04 00 04 1F 88 00 00 09 10 00 00 status: 0x2 (CHECK CONDITION) Sense Bytes: 70 00 03 00 00 00 00 0A 00 00 00 80 10 90 00 00 00 00 Sense Key: 0x3 Medium Error, Segment 0 Sense Code: 0x10 Qual 0x90 (id crc or ecc error) [No matching qualifier] Fru 0x0 Sense flags: Blk 0 (not valid) resid: 11760 cmd finished after 8.904s timeout 60s 100% track 14 recorded successfully with a retail audio CD i don't get any error. so this is the same as with data cds. i tried with three different manufacturers: Disk type: Long strategy type (Cyanine, AZO or similar) Manuf. index: 26 Manufacturer: TDK Corporation Disk type: Long strategy type (Cyanine, AZO or similar) Manuf. index: 11 Manufacturer: Mitsubishi Chemical Corporation Disk type: Short strategy type (Phthalocyanine or similar) Manuf. index: 27 Manufacturer: Prodisc Technology Inc. ...all suffer from the same issue. my drive's firmware is XP02 and i believe it's the latest one. cheers. alex > > > otaku% recoverdisk /dev/cd0 ./test10.iso > > Bigsize = 1048576, medsize = 65536, minsize = 2048 > > start size block-len state done remaining % done > > 0 1048576 243052544 0 0 243052544 0.00000 > > 0 1048576 failed (Device not configured) > > > -- > Andriy Gapon -- a13x From owner-freebsd-current@FreeBSD.ORG Wed May 18 12:27:28 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3FCB8106566B; Wed, 18 May 2011 12:27:28 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id EBD938FC13; Wed, 18 May 2011 12:27:27 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.4) with ESMTP id p4ICRR67042427; Wed, 18 May 2011 08:27:27 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.4/Submit) id p4ICRRUO042370; Wed, 18 May 2011 12:27:27 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 18 May 2011 12:27:27 GMT Message-Id: <201105181227.p4ICRRUO042370@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on arm/arm X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2011 12:27:28 -0000 TB --- 2011-05-18 11:00:01 - tinderbox 2.7 running on freebsd-current.sentex.ca TB --- 2011-05-18 11:00:01 - starting HEAD tinderbox run for arm/arm TB --- 2011-05-18 11:00:01 - cleaning the object tree TB --- 2011-05-18 11:00:15 - cvsupping the source tree TB --- 2011-05-18 11:00:15 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/arm/arm/supfile TB --- 2011-05-18 11:01:16 - building world TB --- 2011-05-18 11:01:16 - MAKEOBJDIRPREFIX=/obj TB --- 2011-05-18 11:01:16 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-05-18 11:01:16 - TARGET=arm TB --- 2011-05-18 11:01:16 - TARGET_ARCH=arm TB --- 2011-05-18 11:01:16 - TZ=UTC TB --- 2011-05-18 11:01:16 - __MAKE_CONF=/dev/null TB --- 2011-05-18 11:01:16 - cd /src TB --- 2011-05-18 11:01:16 - /usr/bin/make -B buildworld >>> World build started on Wed May 18 11:01:17 UTC 2011 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Wed May 18 11:53:20 UTC 2011 TB --- 2011-05-18 11:53:20 - WARNING: no kernel config for LINT TB --- 2011-05-18 11:53:20 - cd /src/sys/arm/conf TB --- 2011-05-18 11:53:20 - /usr/sbin/config -m AVILA TB --- 2011-05-18 11:53:20 - building AVILA kernel TB --- 2011-05-18 11:53:20 - MAKEOBJDIRPREFIX=/obj TB --- 2011-05-18 11:53:20 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-05-18 11:53:20 - TARGET=arm TB --- 2011-05-18 11:53:20 - TARGET_ARCH=arm TB --- 2011-05-18 11:53:20 - TZ=UTC TB --- 2011-05-18 11:53:20 - __MAKE_CONF=/dev/null TB --- 2011-05-18 11:53:20 - cd /src TB --- 2011-05-18 11:53:20 - /usr/bin/make -B buildkernel KERNCONF=AVILA >>> Kernel build for AVILA started on Wed May 18 11:53:20 UTC 2011 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for AVILA completed on Wed May 18 11:56:07 UTC 2011 TB --- 2011-05-18 11:56:07 - cd /src/sys/arm/conf TB --- 2011-05-18 11:56:07 - /usr/sbin/config -m BWCT TB --- 2011-05-18 11:56:07 - building BWCT kernel TB --- 2011-05-18 11:56:07 - MAKEOBJDIRPREFIX=/obj TB --- 2011-05-18 11:56:07 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-05-18 11:56:07 - TARGET=arm TB --- 2011-05-18 11:56:07 - TARGET_ARCH=arm TB --- 2011-05-18 11:56:07 - TZ=UTC TB --- 2011-05-18 11:56:07 - __MAKE_CONF=/dev/null TB --- 2011-05-18 11:56:07 - cd /src TB --- 2011-05-18 11:56:07 - /usr/bin/make -B buildkernel KERNCONF=BWCT >>> Kernel build for BWCT started on Wed May 18 11:56:07 UTC 2011 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for BWCT completed on Wed May 18 11:58:02 UTC 2011 TB --- 2011-05-18 11:58:02 - cd /src/sys/arm/conf TB --- 2011-05-18 11:58:02 - /usr/sbin/config -m CAMBRIA TB --- 2011-05-18 11:58:02 - building CAMBRIA kernel TB --- 2011-05-18 11:58:02 - MAKEOBJDIRPREFIX=/obj TB --- 2011-05-18 11:58:02 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-05-18 11:58:02 - TARGET=arm TB --- 2011-05-18 11:58:02 - TARGET_ARCH=arm TB --- 2011-05-18 11:58:02 - TZ=UTC TB --- 2011-05-18 11:58:02 - __MAKE_CONF=/dev/null TB --- 2011-05-18 11:58:02 - cd /src TB --- 2011-05-18 11:58:02 - /usr/bin/make -B buildkernel KERNCONF=CAMBRIA >>> Kernel build for CAMBRIA started on Wed May 18 11:58:03 UTC 2011 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for CAMBRIA completed on Wed May 18 12:00:45 UTC 2011 TB --- 2011-05-18 12:00:45 - cd /src/sys/arm/conf TB --- 2011-05-18 12:00:45 - /usr/sbin/config -m CNS11XXNAS TB --- 2011-05-18 12:00:45 - building CNS11XXNAS kernel TB --- 2011-05-18 12:00:45 - MAKEOBJDIRPREFIX=/obj TB --- 2011-05-18 12:00:45 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-05-18 12:00:45 - TARGET=arm TB --- 2011-05-18 12:00:45 - TARGET_ARCH=arm TB --- 2011-05-18 12:00:45 - TZ=UTC TB --- 2011-05-18 12:00:45 - __MAKE_CONF=/dev/null TB --- 2011-05-18 12:00:45 - cd /src TB --- 2011-05-18 12:00:45 - /usr/bin/make -B buildkernel KERNCONF=CNS11XXNAS >>> Kernel build for CNS11XXNAS started on Wed May 18 12:00:45 UTC 2011 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for CNS11XXNAS completed on Wed May 18 12:03:01 UTC 2011 TB --- 2011-05-18 12:03:01 - cd /src/sys/arm/conf TB --- 2011-05-18 12:03:01 - /usr/sbin/config -m CRB TB --- 2011-05-18 12:03:01 - building CRB kernel TB --- 2011-05-18 12:03:01 - MAKEOBJDIRPREFIX=/obj TB --- 2011-05-18 12:03:01 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-05-18 12:03:01 - TARGET=arm TB --- 2011-05-18 12:03:01 - TARGET_ARCH=arm TB --- 2011-05-18 12:03:01 - TZ=UTC TB --- 2011-05-18 12:03:01 - __MAKE_CONF=/dev/null TB --- 2011-05-18 12:03:01 - cd /src TB --- 2011-05-18 12:03:01 - /usr/bin/make -B buildkernel KERNCONF=CRB >>> Kernel build for CRB started on Wed May 18 12:03:01 UTC 2011 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for CRB completed on Wed May 18 12:06:05 UTC 2011 TB --- 2011-05-18 12:06:05 - cd /src/sys/arm/conf TB --- 2011-05-18 12:06:05 - /usr/sbin/config -m DOCKSTAR TB --- 2011-05-18 12:06:05 - building DOCKSTAR kernel TB --- 2011-05-18 12:06:05 - MAKEOBJDIRPREFIX=/obj TB --- 2011-05-18 12:06:05 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-05-18 12:06:05 - TARGET=arm TB --- 2011-05-18 12:06:05 - TARGET_ARCH=arm TB --- 2011-05-18 12:06:05 - TZ=UTC TB --- 2011-05-18 12:06:05 - __MAKE_CONF=/dev/null TB --- 2011-05-18 12:06:05 - cd /src TB --- 2011-05-18 12:06:05 - /usr/bin/make -B buildkernel KERNCONF=DOCKSTAR >>> Kernel build for DOCKSTAR started on Wed May 18 12:06:05 UTC 2011 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for DOCKSTAR completed on Wed May 18 12:08:25 UTC 2011 TB --- 2011-05-18 12:08:25 - cd /src/sys/arm/conf TB --- 2011-05-18 12:08:25 - /usr/sbin/config -m EP80219 TB --- 2011-05-18 12:08:25 - building EP80219 kernel TB --- 2011-05-18 12:08:25 - MAKEOBJDIRPREFIX=/obj TB --- 2011-05-18 12:08:25 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-05-18 12:08:25 - TARGET=arm TB --- 2011-05-18 12:08:25 - TARGET_ARCH=arm TB --- 2011-05-18 12:08:25 - TZ=UTC TB --- 2011-05-18 12:08:25 - __MAKE_CONF=/dev/null TB --- 2011-05-18 12:08:25 - cd /src TB --- 2011-05-18 12:08:25 - /usr/bin/make -B buildkernel KERNCONF=EP80219 >>> Kernel build for EP80219 started on Wed May 18 12:08:25 UTC 2011 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for EP80219 completed on Wed May 18 12:11:02 UTC 2011 TB --- 2011-05-18 12:11:02 - WARNING: no kernel config for GENERIC TB --- 2011-05-18 12:11:02 - cd /src/sys/arm/conf TB --- 2011-05-18 12:11:02 - /usr/sbin/config -m GUMSTIX TB --- 2011-05-18 12:11:02 - building GUMSTIX kernel TB --- 2011-05-18 12:11:02 - MAKEOBJDIRPREFIX=/obj TB --- 2011-05-18 12:11:02 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-05-18 12:11:02 - TARGET=arm TB --- 2011-05-18 12:11:02 - TARGET_ARCH=arm TB --- 2011-05-18 12:11:02 - TZ=UTC TB --- 2011-05-18 12:11:02 - __MAKE_CONF=/dev/null TB --- 2011-05-18 12:11:02 - cd /src TB --- 2011-05-18 12:11:02 - /usr/bin/make -B buildkernel KERNCONF=GUMSTIX >>> Kernel build for GUMSTIX started on Wed May 18 12:11:02 UTC 2011 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for GUMSTIX completed on Wed May 18 12:13:04 UTC 2011 TB --- 2011-05-18 12:13:04 - cd /src/sys/arm/conf TB --- 2011-05-18 12:13:04 - /usr/sbin/config -m HL200 TB --- 2011-05-18 12:13:06 - building HL200 kernel TB --- 2011-05-18 12:13:06 - MAKEOBJDIRPREFIX=/obj TB --- 2011-05-18 12:13:06 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-05-18 12:13:06 - TARGET=arm TB --- 2011-05-18 12:13:06 - TARGET_ARCH=arm TB --- 2011-05-18 12:13:06 - TZ=UTC TB --- 2011-05-18 12:13:06 - __MAKE_CONF=/dev/null TB --- 2011-05-18 12:13:06 - cd /src TB --- 2011-05-18 12:13:06 - /usr/bin/make -B buildkernel KERNCONF=HL200 >>> Kernel build for HL200 started on Wed May 18 12:13:06 UTC 2011 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for HL200 completed on Wed May 18 12:15:30 UTC 2011 TB --- 2011-05-18 12:15:30 - cd /src/sys/arm/conf TB --- 2011-05-18 12:15:30 - /usr/sbin/config -m HL201 TB --- 2011-05-18 12:15:30 - building HL201 kernel TB --- 2011-05-18 12:15:30 - MAKEOBJDIRPREFIX=/obj TB --- 2011-05-18 12:15:30 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-05-18 12:15:30 - TARGET=arm TB --- 2011-05-18 12:15:30 - TARGET_ARCH=arm TB --- 2011-05-18 12:15:30 - TZ=UTC TB --- 2011-05-18 12:15:30 - __MAKE_CONF=/dev/null TB --- 2011-05-18 12:15:30 - cd /src TB --- 2011-05-18 12:15:30 - /usr/bin/make -B buildkernel KERNCONF=HL201 >>> Kernel build for HL201 started on Wed May 18 12:15:31 UTC 2011 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for HL201 completed on Wed May 18 12:17:37 UTC 2011 TB --- 2011-05-18 12:17:37 - cd /src/sys/arm/conf TB --- 2011-05-18 12:17:37 - /usr/sbin/config -m IQ31244 TB --- 2011-05-18 12:17:37 - building IQ31244 kernel TB --- 2011-05-18 12:17:37 - MAKEOBJDIRPREFIX=/obj TB --- 2011-05-18 12:17:37 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-05-18 12:17:37 - TARGET=arm TB --- 2011-05-18 12:17:37 - TARGET_ARCH=arm TB --- 2011-05-18 12:17:37 - TZ=UTC TB --- 2011-05-18 12:17:37 - __MAKE_CONF=/dev/null TB --- 2011-05-18 12:17:37 - cd /src TB --- 2011-05-18 12:17:37 - /usr/bin/make -B buildkernel KERNCONF=IQ31244 >>> Kernel build for IQ31244 started on Wed May 18 12:17:37 UTC 2011 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for IQ31244 completed on Wed May 18 12:20:35 UTC 2011 TB --- 2011-05-18 12:20:35 - cd /src/sys/arm/conf TB --- 2011-05-18 12:20:35 - /usr/sbin/config -m KB920X TB --- 2011-05-18 12:20:35 - building KB920X kernel TB --- 2011-05-18 12:20:35 - MAKEOBJDIRPREFIX=/obj TB --- 2011-05-18 12:20:35 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-05-18 12:20:35 - TARGET=arm TB --- 2011-05-18 12:20:35 - TARGET_ARCH=arm TB --- 2011-05-18 12:20:35 - TZ=UTC TB --- 2011-05-18 12:20:35 - __MAKE_CONF=/dev/null TB --- 2011-05-18 12:20:35 - cd /src TB --- 2011-05-18 12:20:35 - /usr/bin/make -B buildkernel KERNCONF=KB920X >>> Kernel build for KB920X started on Wed May 18 12:20:35 UTC 2011 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] awk -f /src/sys/conf/kmod_syms.awk ng_bt3c.kld export_syms | xargs -J% objcopy % ng_bt3c.kld ld -Bshareable -d -warn-common -o ng_bt3c.ko.debug ng_bt3c.kld objcopy --only-keep-debug ng_bt3c.ko.debug ng_bt3c.ko.symbols objcopy --strip-debug --add-gnu-debuglink=ng_bt3c.ko.symbols ng_bt3c.ko.debug ng_bt3c.ko ===> netgraph/bluetooth/ubt (all) cc -O -pipe -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I/src/sys/modules/netgraph/bluetooth/ubt/../../../../netgraph/bluetooth/include -I/src/sys/modules/netgraph/bluetooth/ubt/../../../../netgraph/bluetooth/drivers/ubt -DHAVE_KERNEL_OPTION_HEADERS -include /obj/arm.arm/src/sys/KB920X/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -I/obj/arm.arm/src/sys/KB920X -mcpu=arm9 -ffreestanding -std=iso9899:1999 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -c /src/sys/modules/netgraph/bluetooth/ubt/../../../../netgraph/bluetooth/drivers/ubt/ng_ubt.c /src/sys/modules/netgraph/bluetooth/ubt/../../../../netgraph/bluetooth/drivers/ubt/ng_ubt.c: In function 'ubt_probe': /src/sys/modules/netgraph/bluetooth/ubt/../../../../netgraph/bluetooth/drivers/ubt/ng_ubt.c:419: error: 'struct usb_attach_arg' has no member named 'use_generic' *** Error code 1 Stop in /src/sys/modules/netgraph/bluetooth/ubt. *** Error code 1 Stop in /src/sys/modules/netgraph/bluetooth. *** Error code 1 Stop in /src/sys/modules/netgraph. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/arm.arm/src/sys/KB920X. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-05-18 12:27:26 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-05-18 12:27:26 - ERROR: failed to build KB920X kernel TB --- 2011-05-18 12:27:26 - 3900.62 user 938.16 system 5245.41 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-arm-arm.full From owner-freebsd-current@FreeBSD.ORG Wed May 18 12:47:55 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: by hub.freebsd.org (Postfix, from userid 1233) id D97381065670; Wed, 18 May 2011 12:47:55 +0000 (UTC) Date: Wed, 18 May 2011 12:47:55 +0000 From: Alexander Best To: Andriy Gapon Message-ID: <20110518124755.GA8500@freebsd.org> References: <20110518082459.GA71662@freebsd.org> <20110518082747.GA75790@freebsd.org> <4DD39296.2090805@FreeBSD.org> <20110518102448.GA88446@freebsd.org> <4DD3AC1B.9080208@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4DD3AC1B.9080208@FreeBSD.org> Cc: freebsd-scsi@FreeBSD.org, freebsd-current@FreeBSD.org Subject: Re: issues with new sata dvd-drive 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, 18 May 2011 12:47:55 -0000 On Wed May 18 11, Andriy Gapon wrote: > on 18/05/2011 13:24 Alexander Best said the following: > > i dug into this a little further and it appears that this only happens with > > CD-Rs. using CD-ROMs, DVDs or DVD+Rs this doesn't happen. i tested this with > > CD-Rs recorded under windows and freebsd (created with burncd(1), growisofs(1) > > and cdrecord(1)) and they all suffer the same issue. > > Are the CD-Rs from the same vendor/batch? > Could it possibly be that there is some problem with firmware recognizing those disks? > > > i also tried this with audio cds and here recoverdisk(1) fails no matter, if > > it's a CD-R or a CD-ROM: > > I think that it's not supposed to work for Audio-CDs with cd(4) [unlike acd(4) and > then with bs of 2352]. > To digitally extract audio data you have to go via pass(4) and appropriate > SCSI/MMC commands. btw i also got an error when trying to blank an entire CD-RW: otaku% clear ; sudo cdrecord -v blank=all Cdrecord-ProDVD-ProBD-Clone 3.01a04 (amd64-unknown-freebsd9.0) Copyright (C) 1995-2010 Joerg Schilling TOC Type: 1 = CD-ROM Using libscg version 'schily-0.9'. SCSI buffer size: 65536 No target specified, trying to find one... Using dev=2,0,0. atapi: 0 Device type : Removable CD-ROM Version : 0 Response Format: 2 Capabilities : Vendor_info : 'HL-DT-ST' Identifikation : 'DVDRAM GH24NS50 ' Revision : 'XP02' Device seems to be: Generic mmc2 DVD-R/DVD-RW/DVD-RAM. Current: CD-RW Profile: DVD-RAM Profile: DVD-R sequential recording Profile: DVD-R/DL sequential recording Profile: DVD-R/DL layer jump recording Profile: DVD-RW sequential recording Profile: DVD-RW restricted overwrite Profile: DVD+RW Profile: DVD+R Profile: DVD+R/DL Profile: DVD-ROM Profile: CD-R Profile: CD-RW (current) Profile: CD-ROM (current) Profile: Removable Disk Using generic SCSI-3/mmc CD-R/CD-RW driver (mmc_cdr). Driver flags : MMC-3 SWABAUDIO BURNFREE Supported modes: TAO PACKET SAO SAO/R96P SAO/R96R RAW/R16 RAW/R96P RAW/R96R LAYER_JUMP Drive buf size : 1053696 = 1029 KB Drive pbuf size: 1966080 = 1920 KB Drive DMA Speed: 16803 kB/s 95x CD 12x DVD 3x BD Current Secsize: 2048 ATIP info from disk: Indicated writing power: 6 Reference speed: 2 Disk Is not unrestricted Disk Is erasable ATIP start of lead in: -11078 (97:34/22) ATIP start of lead out: 359849 (79:59/74) 1T speed low: 0 (reserved val 0) 1T speed high: 4 2T speed low: 0 (reserved val 5) 2T speed high: 0 (reserved val 12) power mult factor: 3 5 recommended erase/write power: 3 A1 values: 02 3A B0 A2 values: 5C C6 26 Disk type: Phase change Manuf. index: 11 Manufacturer: Mitsubishi Chemical Corporation Capacity Blklen/Sparesz. Format-type Type 5122 2048 0x00 Formatted Media Starting to write CD/DVD/BD at speed 4 in real BLANK mode for single session. Last chance to quit, starting real write 0 seconds. Operation starts. Performing OPC... Blanking entire disk cdrecord: Input/output error. blank unit: scsi sendcmd: cmd timeout after 1010.067 (9600) s CDB: A1 00 00 00 00 00 00 00 00 00 00 00 cmd finished after 1010.067s timeout 9600s cdrecord: Cannot blank disk, aborting. dmesg says: (cd0:ahcich2:0:0:0): READ(10). CDB: 28 0 0 5 70 80 0 0 3c 0 (cd0:ahcich2:0:0:0): CAM status: SCSI Status Error (cd0:ahcich2:0:0:0): SCSI status: Check Condition (cd0:ahcich2:0:0:0): SCSI sense: ILLEGAL REQUEST csi:28,a,0,80 asc:64,0 (Illegal mode for this track) (cd0:ahcich2:0:0:0): cddone: got error 0x6 back ahcich2: Timeout on slot 4 ahcich2: is 00000000 cs 00000010 ss 00000000 rs 00000010 tfd c0 serr 00000000 cheers. alex > > > otaku% recoverdisk /dev/cd0 ./test10.iso > > Bigsize = 1048576, medsize = 65536, minsize = 2048 > > start size block-len state done remaining % done > > 0 1048576 243052544 0 0 243052544 0.00000 > > 0 1048576 failed (Device not configured) > > > -- > Andriy Gapon -- a13x From owner-freebsd-current@FreeBSD.ORG Wed May 18 13:07:17 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 584D4106566B; Wed, 18 May 2011 13:07:17 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 15E688FC0C; Wed, 18 May 2011 13:07:16 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.4) with ESMTP id p4ID7GRZ054218; Wed, 18 May 2011 09:07:16 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.4/Submit) id p4ID7GKR054157; Wed, 18 May 2011 13:07:16 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 18 May 2011 13:07:16 GMT Message-Id: <201105181307.p4ID7GKR054157@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on i386/pc98 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2011 13:07:17 -0000 TB --- 2011-05-18 11:00:01 - tinderbox 2.7 running on freebsd-current.sentex.ca TB --- 2011-05-18 11:00:01 - starting HEAD tinderbox run for i386/pc98 TB --- 2011-05-18 11:00:01 - cleaning the object tree TB --- 2011-05-18 11:00:17 - cvsupping the source tree TB --- 2011-05-18 11:00:17 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/pc98/supfile TB --- 2011-05-18 11:01:16 - building world TB --- 2011-05-18 11:01:16 - MAKEOBJDIRPREFIX=/obj TB --- 2011-05-18 11:01:16 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-05-18 11:01:16 - TARGET=pc98 TB --- 2011-05-18 11:01:16 - TARGET_ARCH=i386 TB --- 2011-05-18 11:01:16 - TZ=UTC TB --- 2011-05-18 11:01:16 - __MAKE_CONF=/dev/null TB --- 2011-05-18 11:01:16 - cd /src TB --- 2011-05-18 11:01:16 - /usr/bin/make -B buildworld >>> World build started on Wed May 18 11:01:17 UTC 2011 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Wed May 18 12:55:56 UTC 2011 TB --- 2011-05-18 12:55:57 - generating LINT kernel config TB --- 2011-05-18 12:55:57 - cd /src/sys/pc98/conf TB --- 2011-05-18 12:55:57 - /usr/bin/make -B LINT TB --- 2011-05-18 12:55:57 - building LINT kernel TB --- 2011-05-18 12:55:57 - MAKEOBJDIRPREFIX=/obj TB --- 2011-05-18 12:55:57 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-05-18 12:55:57 - TARGET=pc98 TB --- 2011-05-18 12:55:57 - TARGET_ARCH=i386 TB --- 2011-05-18 12:55:57 - TZ=UTC TB --- 2011-05-18 12:55:57 - __MAKE_CONF=/dev/null TB --- 2011-05-18 12:55:57 - cd /src TB --- 2011-05-18 12:55:57 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed May 18 12:55:57 UTC 2011 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-sse -mno-mmx -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/netgraph/atm/sscfu/ng_sscfu.c -I/src/sys/contrib/ngatm cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-sse -mno-mmx -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/netgraph/atm/sscop/ng_sscop.c -I/src/sys/contrib/ngatm cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-sse -mno-mmx -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/netgraph/atm/uni/ng_uni.c -I/src/sys/contrib/ngatm cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-sse -mno-mmx -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/netgraph/bluetooth/common/ng_bluetooth.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-sse -mno-mmx -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/netgraph/bluetooth/drivers/bt3c/ng_bt3c_pccard.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-sse -mno-mmx -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/netgraph/bluetooth/drivers/ubt/ng_ubt.c /src/sys/netgraph/bluetooth/drivers/ubt/ng_ubt.c: In function 'ubt_probe': /src/sys/netgraph/bluetooth/drivers/ubt/ng_ubt.c:419: error: 'struct usb_attach_arg' has no member named 'use_generic' *** Error code 1 Stop in /obj/pc98.i386/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-05-18 13:07:15 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-05-18 13:07:15 - ERROR: failed to build lint kernel TB --- 2011-05-18 13:07:15 - 6105.87 user 1036.30 system 7634.42 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Wed May 18 13:15:07 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0E71F106564A; Wed, 18 May 2011 13:15:07 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id B7F598FC0A; Wed, 18 May 2011 13:15:06 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.4) with ESMTP id p4IDF5mZ010471; Wed, 18 May 2011 09:15:05 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.4/Submit) id p4IDF5dO010470; Wed, 18 May 2011 13:15:05 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 18 May 2011 13:15:05 GMT Message-Id: <201105181315.p4IDF5dO010470@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on i386/i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2011 13:15:07 -0000 TB --- 2011-05-18 11:00:01 - tinderbox 2.7 running on freebsd-current.sentex.ca TB --- 2011-05-18 11:00:01 - starting HEAD tinderbox run for i386/i386 TB --- 2011-05-18 11:00:01 - cleaning the object tree TB --- 2011-05-18 11:00:26 - cvsupping the source tree TB --- 2011-05-18 11:00:26 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/i386/supfile TB --- 2011-05-18 11:05:56 - building world TB --- 2011-05-18 11:05:56 - MAKEOBJDIRPREFIX=/obj TB --- 2011-05-18 11:05:56 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-05-18 11:05:56 - TARGET=i386 TB --- 2011-05-18 11:05:56 - TARGET_ARCH=i386 TB --- 2011-05-18 11:05:56 - TZ=UTC TB --- 2011-05-18 11:05:56 - __MAKE_CONF=/dev/null TB --- 2011-05-18 11:05:56 - cd /src TB --- 2011-05-18 11:05:56 - /usr/bin/make -B buildworld >>> World build started on Wed May 18 11:05:57 UTC 2011 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Wed May 18 13:01:37 UTC 2011 TB --- 2011-05-18 13:01:37 - generating LINT kernel config TB --- 2011-05-18 13:01:37 - cd /src/sys/i386/conf TB --- 2011-05-18 13:01:37 - /usr/bin/make -B LINT TB --- 2011-05-18 13:01:37 - building LINT kernel TB --- 2011-05-18 13:01:37 - MAKEOBJDIRPREFIX=/obj TB --- 2011-05-18 13:01:37 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-05-18 13:01:37 - TARGET=i386 TB --- 2011-05-18 13:01:37 - TARGET_ARCH=i386 TB --- 2011-05-18 13:01:37 - TZ=UTC TB --- 2011-05-18 13:01:37 - __MAKE_CONF=/dev/null TB --- 2011-05-18 13:01:37 - cd /src TB --- 2011-05-18 13:01:37 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed May 18 13:01:37 UTC 2011 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-sse -mno-mmx -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/netgraph/atm/sscfu/ng_sscfu.c -I/src/sys/contrib/ngatm cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-sse -mno-mmx -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/netgraph/atm/sscop/ng_sscop.c -I/src/sys/contrib/ngatm cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-sse -mno-mmx -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/netgraph/atm/uni/ng_uni.c -I/src/sys/contrib/ngatm cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-sse -mno-mmx -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/netgraph/bluetooth/common/ng_bluetooth.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-sse -mno-mmx -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/netgraph/bluetooth/drivers/bt3c/ng_bt3c_pccard.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-sse -mno-mmx -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/netgraph/bluetooth/drivers/ubt/ng_ubt.c /src/sys/netgraph/bluetooth/drivers/ubt/ng_ubt.c: In function 'ubt_probe': /src/sys/netgraph/bluetooth/drivers/ubt/ng_ubt.c:419: error: 'struct usb_attach_arg' has no member named 'use_generic' *** Error code 1 Stop in /obj/i386.i386/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-05-18 13:15:05 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-05-18 13:15:05 - ERROR: failed to build lint kernel TB --- 2011-05-18 13:15:05 - 6255.59 user 1029.48 system 8104.43 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Wed May 18 13:38:23 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CDB831065670; Wed, 18 May 2011 13:38:23 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 989FB8FC0C; Wed, 18 May 2011 13:38:23 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.4) with ESMTP id p4IDcMo6004312; Wed, 18 May 2011 09:38:22 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.4/Submit) id p4IDcM3T004289; Wed, 18 May 2011 13:38:22 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 18 May 2011 13:38:22 GMT Message-Id: <201105181338.p4IDcM3T004289@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2011 13:38:23 -0000 TB --- 2011-05-18 11:00:01 - tinderbox 2.7 running on freebsd-current.sentex.ca TB --- 2011-05-18 11:00:01 - starting HEAD tinderbox run for amd64/amd64 TB --- 2011-05-18 11:00:01 - cleaning the object tree TB --- 2011-05-18 11:00:25 - cvsupping the source tree TB --- 2011-05-18 11:00:25 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/amd64/amd64/supfile TB --- 2011-05-18 11:01:16 - building world TB --- 2011-05-18 11:01:16 - MAKEOBJDIRPREFIX=/obj TB --- 2011-05-18 11:01:16 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-05-18 11:01:16 - TARGET=amd64 TB --- 2011-05-18 11:01:16 - TARGET_ARCH=amd64 TB --- 2011-05-18 11:01:16 - TZ=UTC TB --- 2011-05-18 11:01:16 - __MAKE_CONF=/dev/null TB --- 2011-05-18 11:01:16 - cd /src TB --- 2011-05-18 11:01:16 - /usr/bin/make -B buildworld >>> World build started on Wed May 18 11:01:17 UTC 2011 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Wed May 18 13:25:30 UTC 2011 TB --- 2011-05-18 13:25:31 - generating LINT kernel config TB --- 2011-05-18 13:25:31 - cd /src/sys/amd64/conf TB --- 2011-05-18 13:25:31 - /usr/bin/make -B LINT TB --- 2011-05-18 13:25:31 - building LINT kernel TB --- 2011-05-18 13:25:31 - MAKEOBJDIRPREFIX=/obj TB --- 2011-05-18 13:25:31 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-05-18 13:25:31 - TARGET=amd64 TB --- 2011-05-18 13:25:31 - TARGET_ARCH=amd64 TB --- 2011-05-18 13:25:31 - TZ=UTC TB --- 2011-05-18 13:25:31 - __MAKE_CONF=/dev/null TB --- 2011-05-18 13:25:31 - cd /src TB --- 2011-05-18 13:25:31 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed May 18 13:25:31 UTC 2011 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mno-sse -mcmodel=kernel -mno-red-zone -mno-mmx -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/netgraph/atm/sscfu/ng_sscfu.c -I/src/sys/contrib/ngatm cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mno-sse -mcmodel=kernel -mno-red-zone -mno-mmx -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/netgraph/atm/sscop/ng_sscop.c -I/src/sys/contrib/ngatm cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mno-sse -mcmodel=kernel -mno-red-zone -mno-mmx -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/netgraph/atm/uni/ng_uni.c -I/src/sys/contrib/ngatm cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mno-sse -mcmodel=kernel -mno-red-zone -mno-mmx -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/netgraph/bluetooth/common/ng_bluetooth.c cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mno-sse -mcmodel=kernel -mno-red-zone -mno-mmx -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/netgraph/bluetooth/drivers/bt3c/ng_bt3c_pccard.c cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mno-sse -mcmodel=kernel -mno-red-zone -mno-mmx -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/netgraph/bluetooth/drivers/ubt/ng_ubt.c /src/sys/netgraph/bluetooth/drivers/ubt/ng_ubt.c: In function 'ubt_probe': /src/sys/netgraph/bluetooth/drivers/ubt/ng_ubt.c:419: error: 'struct usb_attach_arg' has no member named 'use_generic' *** Error code 1 Stop in /obj/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-05-18 13:38:22 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-05-18 13:38:22 - ERROR: failed to build lint kernel TB --- 2011-05-18 13:38:22 - 7537.41 user 1360.23 system 9501.16 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-amd64-amd64.full From owner-freebsd-current@FreeBSD.ORG Wed May 18 14:08:30 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AB98A106566C; Wed, 18 May 2011 14:08:30 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 766BD8FC0C; Wed, 18 May 2011 14:08:30 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.4) with ESMTP id p4IE8T6q013974; Wed, 18 May 2011 10:08:29 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.4/Submit) id p4IE8TLj013965; Wed, 18 May 2011 14:08:29 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 18 May 2011 14:08:29 GMT Message-Id: <201105181408.p4IE8TLj013965@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on ia64/ia64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2011 14:08:30 -0000 TB --- 2011-05-18 12:27:27 - tinderbox 2.7 running on freebsd-current.sentex.ca TB --- 2011-05-18 12:27:27 - starting HEAD tinderbox run for ia64/ia64 TB --- 2011-05-18 12:27:27 - cleaning the object tree TB --- 2011-05-18 12:27:39 - cvsupping the source tree TB --- 2011-05-18 12:27:39 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/ia64/ia64/supfile TB --- 2011-05-18 12:27:58 - building world TB --- 2011-05-18 12:27:58 - MAKEOBJDIRPREFIX=/obj TB --- 2011-05-18 12:27:58 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-05-18 12:27:58 - TARGET=ia64 TB --- 2011-05-18 12:27:58 - TARGET_ARCH=ia64 TB --- 2011-05-18 12:27:58 - TZ=UTC TB --- 2011-05-18 12:27:58 - __MAKE_CONF=/dev/null TB --- 2011-05-18 12:27:58 - cd /src TB --- 2011-05-18 12:27:58 - /usr/bin/make -B buildworld >>> World build started on Wed May 18 12:27:59 UTC 2011 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Wed May 18 13:52:43 UTC 2011 TB --- 2011-05-18 13:52:43 - generating LINT kernel config TB --- 2011-05-18 13:52:43 - cd /src/sys/ia64/conf TB --- 2011-05-18 13:52:43 - /usr/bin/make -B LINT TB --- 2011-05-18 13:52:43 - building LINT kernel TB --- 2011-05-18 13:52:43 - MAKEOBJDIRPREFIX=/obj TB --- 2011-05-18 13:52:43 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-05-18 13:52:43 - TARGET=ia64 TB --- 2011-05-18 13:52:43 - TARGET_ARCH=ia64 TB --- 2011-05-18 13:52:43 - TZ=UTC TB --- 2011-05-18 13:52:43 - __MAKE_CONF=/dev/null TB --- 2011-05-18 13:52:43 - cd /src TB --- 2011-05-18 13:52:43 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed May 18 13:52:43 UTC 2011 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/netgraph/atm/sscfu/ng_sscfu.c -I/src/sys/contrib/ngatm cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/netgraph/atm/sscop/ng_sscop.c -I/src/sys/contrib/ngatm cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/netgraph/atm/uni/ng_uni.c -I/src/sys/contrib/ngatm cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/netgraph/bluetooth/common/ng_bluetooth.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/netgraph/bluetooth/drivers/bt3c/ng_bt3c_pccard.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/netgraph/bluetooth/drivers/ubt/ng_ubt.c /src/sys/netgraph/bluetooth/drivers/ubt/ng_ubt.c: In function 'ubt_probe': /src/sys/netgraph/bluetooth/drivers/ubt/ng_ubt.c:419: error: 'struct usb_attach_arg' has no member named 'use_generic' *** Error code 1 Stop in /obj/ia64.ia64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-05-18 14:08:29 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-05-18 14:08:29 - ERROR: failed to build lint kernel TB --- 2011-05-18 14:08:29 - 4889.66 user 830.52 system 6061.69 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Wed May 18 16:40: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 BD7BB106564A; Wed, 18 May 2011 16:40:06 +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 CDD178FC13; Wed, 18 May 2011 16:40:04 +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 TAA25040; Wed, 18 May 2011 19:40:03 +0300 (EEST) (envelope-from avg@FreeBSD.org) Message-ID: <4DD3F662.9040603@FreeBSD.org> Date: Wed, 18 May 2011 19:40:02 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.17) Gecko/20110504 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: freebsd-arch@FreeBSD.org, freebsd-current@FreeBSD.org X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Subject: [rfc] remove hlt_cpus et al sysctls and related code 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, 18 May 2011 16:40:06 -0000 I think that it is a well known fact that currently we do not have any support for dynamically offlining processors. Yet, we have some code that looks like it does provide that support and even provides a user interface to supposedly do that. What we don't currently do specifically: - rebinding interrupts away from an offlined processor - updating relevant cpu sets and masks - protecting the above for concurrent access - moving threads away from an offlined processor - notifying potentially interested parties - maybe more... The code has been in this shape for a long while and I would dare to say that it never really worked, not in "production ready" sense anyway. An example of troubles caused by using that code can be found e.g. in the followups to the following PR: http://www.freebsd.org/cgi/query-pr.cgi?pr=145385 And also discussed here: http://thread.gmane.org/gmane.os.freebsd.stable/74462/focus=74510 I think that there already have been a proposal to remove the systcls and the code. I would like to re-submit that proposal. Removing that code would: 1) prevent users from hurting themselves by executing broken code 2) potentially make things easier for largeSMP project Once we grow correct code for offlining CPUs, then we could re-introduce the sysctls without any problems. While the offlining code doesn't seem terribly hard to develop, it's a big piece of work and requires time and effort. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Wed May 18 16:43: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 14A801065672; Wed, 18 May 2011 16:43:08 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id A0D0F8FC15; Wed, 18 May 2011 16:43:07 +0000 (UTC) Received: by vws18 with SMTP id 18so1698531vws.13 for ; Wed, 18 May 2011 09:43:07 -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=/ctk06kF8iSm+jaH13/MBau//5kkKXr0aFQ1hE+aK54=; b=PhkV0NUbMA+bEHgUcywxXd3eULssNBdBF2ZK9iMS4k9R0q58KL3bnfijb4sypjTZ2v Zmo/1Kaq2pUE5tTqMtzD6uIIW99K4d02AvWP4tndXia4EgN42gvS7N4uIICntgCzKoVv j2mrPnjjalUm+Rq54N2zVEim/zGohMTD6BegQ= 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=ls8saRNdrExG20lNoljlpMYbu4epL/An2gX7VSHfHNH+5uHC13SK/DY7w57nKQW8Fw pyfvPI+aFvAptiAFQaRA9+Fnb7DSCLueQGm/0V6V5tVdymFaEhfXglXA3Uahb0c5RFhG XYa+BEtFD6DLr2Vmy4HyjMTw//PshvyD6gq6w= MIME-Version: 1.0 Received: by 10.220.247.139 with SMTP id mc11mr620238vcb.107.1305736987000; Wed, 18 May 2011 09:43:07 -0700 (PDT) Received: by 10.220.188.202 with HTTP; Wed, 18 May 2011 09:43:06 -0700 (PDT) In-Reply-To: <4DD3F662.9040603@FreeBSD.org> References: <4DD3F662.9040603@FreeBSD.org> Date: Wed, 18 May 2011 09:43:06 -0700 Message-ID: From: Garrett Cooper To: Andriy Gapon Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org, freebsd-arch@freebsd.org Subject: Re: [rfc] remove hlt_cpus et al sysctls and related code 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, 18 May 2011 16:43:08 -0000 On Wed, May 18, 2011 at 9:40 AM, Andriy Gapon wrote: > > I think that it is a well known fact that currently we do not have any su= pport for > dynamically offlining processors. =A0Yet, we have some code that looks li= ke it does > provide that support and even provides a user interface to supposedly do = that. > > What we don't currently do specifically: > - rebinding interrupts away from an offlined processor > - updating relevant cpu sets and masks > - protecting the above for concurrent access > - moving threads away from an offlined processor > - notifying potentially interested parties > - maybe more... > > The code has been in this shape for a long while and I would dare to say = that it > never really worked, not in "production ready" sense anyway. > An example of troubles caused by using that code can be found e.g. in the > followups to the following PR: > http://www.freebsd.org/cgi/query-pr.cgi?pr=3D145385 > And also discussed here: > http://thread.gmane.org/gmane.os.freebsd.stable/74462/focus=3D74510 > > I think that there already have been a proposal to remove the systcls and= the > code. =A0I would like to re-submit that proposal. > Removing that code would: > 1) prevent users from hurting themselves by executing broken code > 2) potentially make things easier for largeSMP project > > Once we grow correct code for offlining CPUs, then we could re-introduce = the > sysctls without any problems. > While the offlining code doesn't seem terribly hard to develop, it's a bi= g piece > of work and requires time and effort. What would be nice too (even though it might not be possible) is to make this more MI than it is today (i.e. sysctls that work for amd64, sparc64, etc), but that might be a pipe dream. Thanks! -Garrett From owner-freebsd-current@FreeBSD.ORG Wed May 18 16:49:03 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 7CCEF1065670; Wed, 18 May 2011 16:49:03 +0000 (UTC) (envelope-from asmrookie@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 EE3398FC12; Wed, 18 May 2011 16:49:02 +0000 (UTC) Received: by vxc34 with SMTP id 34so1734450vxc.13 for ; Wed, 18 May 2011 09:49:02 -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 :content-transfer-encoding; bh=gZowLRemBSQ+DEqXAswmBiyJy7dF78EqgQWIbO+XtXg=; b=w3xck7nMXkmhaImQpQ/H6WLKVSnyyyiHONkelKBCQ7Pvv/EaOtusvHIa/HdUTBpu43 6w/6VScEHN+0u7L2aNLPiaF+b3e5hxgI3xLBnHxV8XGMwoGYsXmQNtm1nHNtaVVvc01l qZWXvYKg7ngbjs/RcqnC5bnA9TOOrrVOuwVJo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=JOCFrIuWvcniZSI8R4OmP16ohTS20Sq5cizNTw2ZKxuYP0T5wI8hnvHFC3WqJeHhr8 mKe6P1CdDsHT0j6JcI1jVzxoY+V0gbxBtkKENUQN/5jqKdc5fMNMu9HrL6cWhIxfPOaL npbNXMBPmNjYO/A8tOvcUajbWhcY8ydaQHOZ8= MIME-Version: 1.0 Received: by 10.52.95.203 with SMTP id dm11mr2987039vdb.213.1305737341821; Wed, 18 May 2011 09:49:01 -0700 (PDT) Sender: asmrookie@gmail.com Received: by 10.220.201.3 with HTTP; Wed, 18 May 2011 09:49:01 -0700 (PDT) In-Reply-To: References: <4DD3F662.9040603@FreeBSD.org> Date: Wed, 18 May 2011 12:49:01 -0400 X-Google-Sender-Auth: IRtDwsPfj1ipkk9E6aqWWBUQ3GI Message-ID: From: Attilio Rao To: Garrett Cooper Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org, Andriy Gapon , freebsd-arch@freebsd.org Subject: Re: [rfc] remove hlt_cpus et al sysctls and related code 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, 18 May 2011 16:49:03 -0000 2011/5/18 Garrett Cooper : > On Wed, May 18, 2011 at 9:40 AM, Andriy Gapon wrote: >> >> I think that it is a well known fact that currently we do not have any s= upport for >> dynamically offlining processors. =C2=A0Yet, we have some code that look= s like it does >> provide that support and even provides a user interface to supposedly do= that. >> >> What we don't currently do specifically: >> - rebinding interrupts away from an offlined processor >> - updating relevant cpu sets and masks >> - protecting the above for concurrent access >> - moving threads away from an offlined processor >> - notifying potentially interested parties >> - maybe more... >> >> The code has been in this shape for a long while and I would dare to say= that it >> never really worked, not in "production ready" sense anyway. >> An example of troubles caused by using that code can be found e.g. in th= e >> followups to the following PR: >> http://www.freebsd.org/cgi/query-pr.cgi?pr=3D145385 >> And also discussed here: >> http://thread.gmane.org/gmane.os.freebsd.stable/74462/focus=3D74510 >> >> I think that there already have been a proposal to remove the systcls an= d the >> code. =C2=A0I would like to re-submit that proposal. >> Removing that code would: >> 1) prevent users from hurting themselves by executing broken code >> 2) potentially make things easier for largeSMP project >> >> Once we grow correct code for offlining CPUs, then we could re-introduce= the >> sysctls without any problems. >> While the offlining code doesn't seem terribly hard to develop, it's a b= ig piece >> of work and requires time and effort. > > =C2=A0 =C2=A0What would be nice too (even though it might not be possible= ) is > to make this more MI than it is today (i.e. sysctls that work for > amd64, sparc64, etc), but that might be a pipe dream. > Thanks! > -Garrett That is actually the purpose. We should have a real online/offline system for hotplugging CPUs, not only tied to x86 hyperthreading. The htt specific parts are mostly hacks that don't take into account all the necessary handover for it. Andryi, I'll look into the patch asap, but I'm in favor of this change for = sure. Attilio --=20 Peace can only be achieved by understanding - A. Einstein From owner-freebsd-current@FreeBSD.ORG Wed May 18 16:52:45 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 6C911106566C; Wed, 18 May 2011 16:52:45 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id E0CDF8FC12; Wed, 18 May 2011 16:52:44 +0000 (UTC) Received: by vws18 with SMTP id 18so1708612vws.13 for ; Wed, 18 May 2011 09:52:44 -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 :content-transfer-encoding; bh=EhXRXlZ8nSay9Px+S38WHZyx8P+G4wR7rNXw26tOz1E=; b=sdIYad8c4hnPB72fXZmiiR8yG4phec9M6rEzAjme+UQAC7/54xxD4dOS9z8rk23VcL daUsbpW0FjTTQwq5xT8Fbkv1FJ3yIW0ylNjfldU9Vs308LEijWTIe/dMiuPw2DfvuPHx qtYHXqtH5Yf0ha1l9JYyjlhuFtWB5frIMXej8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=hWlSTEXxuAUD56bM77uyDn028PJ+r4NkSNRnnY6BPR5Enc7Fbkh+Lldc6bxKRTOePi QQAfuUxYtEAHCXX8AhhB0OO+pWRC15uegY1fGltB0PS39Hh0ipvgCrKcxpEhKZurmhCQ d71B4UaySJZzjJfQHltA2FUIptwYxzbVZ53YI= MIME-Version: 1.0 Received: by 10.220.42.74 with SMTP id r10mr621813vce.132.1305737563927; Wed, 18 May 2011 09:52:43 -0700 (PDT) Sender: asmrookie@gmail.com Received: by 10.220.201.3 with HTTP; Wed, 18 May 2011 09:52:43 -0700 (PDT) In-Reply-To: References: <4DD3F662.9040603@FreeBSD.org> Date: Wed, 18 May 2011 12:52:43 -0400 X-Google-Sender-Auth: asD9RAhrk3Z7Osbh5T6nMVum8Cg Message-ID: From: Attilio Rao To: Garrett Cooper Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org, Andriy Gapon , freebsd-arch@freebsd.org Subject: Re: [rfc] remove hlt_cpus et al sysctls and related code 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, 18 May 2011 16:52:45 -0000 2011/5/18 Attilio Rao : > 2011/5/18 Garrett Cooper : >> On Wed, May 18, 2011 at 9:40 AM, Andriy Gapon wrote: >>> >>> I think that it is a well known fact that currently we do not have any = support for >>> dynamically offlining processors. =C2=A0Yet, we have some code that loo= ks like it does >>> provide that support and even provides a user interface to supposedly d= o that. >>> >>> What we don't currently do specifically: >>> - rebinding interrupts away from an offlined processor >>> - updating relevant cpu sets and masks >>> - protecting the above for concurrent access >>> - moving threads away from an offlined processor >>> - notifying potentially interested parties >>> - maybe more... >>> >>> The code has been in this shape for a long while and I would dare to sa= y that it >>> never really worked, not in "production ready" sense anyway. >>> An example of troubles caused by using that code can be found e.g. in t= he >>> followups to the following PR: >>> http://www.freebsd.org/cgi/query-pr.cgi?pr=3D145385 >>> And also discussed here: >>> http://thread.gmane.org/gmane.os.freebsd.stable/74462/focus=3D74510 >>> >>> I think that there already have been a proposal to remove the systcls a= nd the >>> code. =C2=A0I would like to re-submit that proposal. >>> Removing that code would: >>> 1) prevent users from hurting themselves by executing broken code >>> 2) potentially make things easier for largeSMP project >>> >>> Once we grow correct code for offlining CPUs, then we could re-introduc= e the >>> sysctls without any problems. >>> While the offlining code doesn't seem terribly hard to develop, it's a = big piece >>> of work and requires time and effort. >> >> =C2=A0 =C2=A0What would be nice too (even though it might not be possibl= e) is >> to make this more MI than it is today (i.e. sysctls that work for >> amd64, sparc64, etc), but that might be a pipe dream. >> Thanks! >> -Garrett > > That is actually the purpose. =C2=A0We should have a real online/offline > system for hotplugging CPUs, not only tied to x86 hyperthreading. > The htt specific parts are mostly hacks that don't take into account > all the necessary handover for it. For instance, I always promised to implement them and I never did, mostly because it is quite a bit of work in my idea and we don't really have a big pressure for it and there are really bigger things on my plate. If someone wants to step up and implementing offline/online CPUs I would be glad to discuss approaches I have in mind and help formalizing a plan for it, thus offering guidance for the implementation. Attilio --=20 Peace can only be achieved by understanding - A. Einstein From owner-freebsd-current@FreeBSD.ORG Wed May 18 17:01:27 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 7E2A9106564A; Wed, 18 May 2011 17:01:27 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-pw0-f54.google.com (mail-pw0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 3982B8FC12; Wed, 18 May 2011 17:01:27 +0000 (UTC) Received: by pwj8 with SMTP id 8so1084977pwj.13 for ; Wed, 18 May 2011 10:01:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:references:in-reply-to:mime-version :content-transfer-encoding:content-type:message-id:cc:x-mailer:from :subject:date:to; bh=lFG374beTWD8niyTMihkFgrXD5hw4AGaErMjy3i3syk=; b=ZPMbvhdWObaFcAtWLCg8fEZXli5rV54lUnsCNvVN9iUUUDuTw64FbI3vIeob5VE3zo E8BtoWwTUyt6mtcwMz/ven8Vhug/YGwIIZ1Bu+OU6PS0OccwQ18WSjJXtSjY1YCv3D5X 0VRcd45xbQ3zi2WhjY0oZhx6YTB+i0SuBpe4U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; b=r2EkusCyAnYA8M2OFYywsebagFYn3823ZuaWXR7yZTsaaIuj4L5uq824nbHRtuhQnr 8jNtHIWKUEZQqedEpsmIc7R2M9xAbB5xeGaDaPkzGb28tjOBfcN/SIB5OOtigrpoVDod LYmKM7ePe/+kljQoeaVGeo5gOTRaV7lP4n0u4= Received: by 10.68.46.195 with SMTP id x3mr3173696pbm.442.1305737620640; Wed, 18 May 2011 09:53:40 -0700 (PDT) Received: from [192.168.20.56] ([24.6.49.154]) by mx.google.com with ESMTPS id b10sm1162323pbq.22.2011.05.18.09.53.39 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 18 May 2011 09:53:39 -0700 (PDT) References: <4DD3F662.9040603@FreeBSD.org> In-Reply-To: Mime-Version: 1.0 (iPhone Mail 8J2) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPhone Mail (8J2) From: Garrett Cooper Date: Wed, 18 May 2011 09:53:34 -0700 To: Attilio Rao Cc: "freebsd-current@freebsd.org" , Andriy Gapon , "freebsd-arch@freebsd.org" Subject: Re: [rfc] remove hlt_cpus et al sysctls and related code 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, 18 May 2011 17:01:27 -0000 On May 18, 2011, at 9:49 AM, Attilio Rao wrote: > 2011/5/18 Garrett Cooper : >> On Wed, May 18, 2011 at 9:40 AM, Andriy Gapon wrote: >>>=20 >>> I think that it is a well known fact that currently we do not have any s= upport for >>> dynamically offlining processors. Yet, we have some code that looks lik= e it does >>> provide that support and even provides a user interface to supposedly do= that. >>>=20 >>> What we don't currently do specifically: >>> - rebinding interrupts away from an offlined processor >>> - updating relevant cpu sets and masks >>> - protecting the above for concurrent access >>> - moving threads away from an offlined processor >>> - notifying potentially interested parties >>> - maybe more... >>>=20 >>> The code has been in this shape for a long while and I would dare to say= that it >>> never really worked, not in "production ready" sense anyway. >>> An example of troubles caused by using that code can be found e.g. in th= e >>> followups to the following PR: >>> http://www.freebsd.org/cgi/query-pr.cgi?pr=3D145385 >>> And also discussed here: >>> http://thread.gmane.org/gmane.os.freebsd.stable/74462/focus=3D74510 >>>=20 >>> I think that there already have been a proposal to remove the systcls an= d the >>> code. I would like to re-submit that proposal. >>> Removing that code would: >>> 1) prevent users from hurting themselves by executing broken code >>> 2) potentially make things easier for largeSMP project >>>=20 >>> Once we grow correct code for offlining CPUs, then we could re-introduce= the >>> sysctls without any problems. >>> While the offlining code doesn't seem terribly hard to develop, it's a b= ig piece >>> of work and requires time and effort. >>=20 >> What would be nice too (even though it might not be possible) is >> to make this more MI than it is today (i.e. sysctls that work for >> amd64, sparc64, etc), but that might be a pipe dream. >> Thanks! >> -Garrett >=20 > That is actually the purpose. We should have a real online/offline > system for hotplugging CPUs, not only tied to x86 hyperthreading. > The htt specific parts are mostly hacks that don't take into account > all the necessary handover for it. >=20 > Andryi, I'll look into the patch asap, but I'm in favor of this change for= sure. We use this internally at work still with a software config that uses 4B= SD so as long as there is an equivalent tunable, that's good enough for us m= oving forward. Thanks! -Garrett= From owner-freebsd-current@FreeBSD.ORG Wed May 18 17:04: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 A64D3106564A; Wed, 18 May 2011 17:04:14 +0000 (UTC) (envelope-from asmrookie@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 3156A8FC08; Wed, 18 May 2011 17:04:14 +0000 (UTC) Received: by vxc34 with SMTP id 34so1750361vxc.13 for ; Wed, 18 May 2011 10:04:13 -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 :content-transfer-encoding; bh=CQIaPuMYI9b7eS795opJ4SRZNJfv/Ta3oH9sN6WBzi8=; b=lnTD3/FXWxfk9IN5E1shaMhrPUu/IlWHJjaYaJEcpyccfTvXZkmnBPtFIvO7+M9Vx7 bTF/mkNXWerEtbETIQ8Vepi9jxSEDVbbgBOTkjGMzstoW/qlSq7qmzON3m71kHHTUznX Kvf3mkLg7y9PkvImvgeY13S1jzn8RMghoeYgI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=hU1RT7Zub8Dp6V7xENOzW8AS1JhNzbls9VuRxj9AfEvDJUtXHfLXSiokP5Y2HMJJtO YCAxTfkyx+35gusZFjaC2DKGzgZTMwEvdP/T4/eZubz41mxhj/wOQUHCpf9Qk6nsiDPa u3fi1esIbdP36oUkqDvJJ2tuaf/+QaTaMXkEA= MIME-Version: 1.0 Received: by 10.52.95.203 with SMTP id dm11mr3010286vdb.213.1305738253465; Wed, 18 May 2011 10:04:13 -0700 (PDT) Sender: asmrookie@gmail.com Received: by 10.220.201.3 with HTTP; Wed, 18 May 2011 10:04:13 -0700 (PDT) In-Reply-To: References: <4DD3F662.9040603@FreeBSD.org> Date: Wed, 18 May 2011 13:04:13 -0400 X-Google-Sender-Auth: WR1UlXTHniDXxPwzAE-lGuHJEXw Message-ID: From: Attilio Rao To: Garrett Cooper Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "freebsd-current@freebsd.org" , Andriy Gapon , "freebsd-arch@freebsd.org" Subject: Re: [rfc] remove hlt_cpus et al sysctls and related code 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, 18 May 2011 17:04:14 -0000 2011/5/18 Garrett Cooper : > On May 18, 2011, at 9:49 AM, Attilio Rao wrote: > >> 2011/5/18 Garrett Cooper : >>> On Wed, May 18, 2011 at 9:40 AM, Andriy Gapon wrote: >>>> >>>> I think that it is a well known fact that currently we do not have any= support for >>>> dynamically offlining processors. =C2=A0Yet, we have some code that lo= oks like it does >>>> provide that support and even provides a user interface to supposedly = do that. >>>> >>>> What we don't currently do specifically: >>>> - rebinding interrupts away from an offlined processor >>>> - updating relevant cpu sets and masks >>>> - protecting the above for concurrent access >>>> - moving threads away from an offlined processor >>>> - notifying potentially interested parties >>>> - maybe more... >>>> >>>> The code has been in this shape for a long while and I would dare to s= ay that it >>>> never really worked, not in "production ready" sense anyway. >>>> An example of troubles caused by using that code can be found e.g. in = the >>>> followups to the following PR: >>>> http://www.freebsd.org/cgi/query-pr.cgi?pr=3D145385 >>>> And also discussed here: >>>> http://thread.gmane.org/gmane.os.freebsd.stable/74462/focus=3D74510 >>>> >>>> I think that there already have been a proposal to remove the systcls = and the >>>> code. =C2=A0I would like to re-submit that proposal. >>>> Removing that code would: >>>> 1) prevent users from hurting themselves by executing broken code >>>> 2) potentially make things easier for largeSMP project >>>> >>>> Once we grow correct code for offlining CPUs, then we could re-introdu= ce the >>>> sysctls without any problems. >>>> While the offlining code doesn't seem terribly hard to develop, it's a= big piece >>>> of work and requires time and effort. >>> >>> =C2=A0 =C2=A0What would be nice too (even though it might not be possib= le) is >>> to make this more MI than it is today (i.e. sysctls that work for >>> amd64, sparc64, etc), but that might be a pipe dream. >>> Thanks! >>> -Garrett >> >> That is actually the purpose. =C2=A0We should have a real online/offline >> system for hotplugging CPUs, not only tied to x86 hyperthreading. >> The htt specific parts are mostly hacks that don't take into account >> all the necessary handover for it. >> >> Andryi, I'll look into the patch asap, but I'm in favor of this change f= or sure. > > =C2=A0 =C2=A0We use this internally at work still with a software config = that uses 4BSD so as long as there is an equivalent tunable, that's good en= ough for us moving forward. Tunables are pretty much acceptable for this case. What is really broken is the on-the-fly ability to mark CPUs active/inactive and subsequent handovers. I thought Andriy attached a patch to the tree, but it doesn't seem so... anyway, yes, I think that adding tunables for this is very reasonable and not as dangerous as the current mechanism. Attilio --=20 Peace can only be achieved by understanding - A. Einstein From owner-freebsd-current@FreeBSD.ORG Wed May 18 17:40:46 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 7955C106566B; Wed, 18 May 2011 17:40:46 +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 20B8E8FC16; Wed, 18 May 2011 17:40:46 +0000 (UTC) Received: from mail.geekcn.org (tarsier.geekcn.org [211.166.10.233]) by tarsier.geekcn.org (Postfix) with ESMTP id 30F6DA6A7E2; Thu, 19 May 2011 01:40:45 +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 v-b2Snop99dE; Thu, 19 May 2011 01:40:39 +0800 (CST) Received: from delta.delphij.net (drawbridge.ixsystems.com [206.40.55.65]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTPSA id 5CC0BA6A7DF; Thu, 19 May 2011 01:40:36 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=delphij.net; c=nofws; q=dns; h=message-id:date:from:reply-to:organization:user-agent: mime-version:to:cc:subject:references:in-reply-to: x-enigmail-version:openpgp:content-type; b=GyxO2Io8kjS5tzgROE1k4oBaMusBZ31dZSLZXzVTowY9FBFD3DbFUan1xTTLj62Ip SywydfMDxT0NCQX2ES2Ug== Message-ID: <4DD4048F.8030207@delphij.net> Date: Wed, 18 May 2011 10:40:31 -0700 From: Xin LI Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.17) Gecko/20110502 Thunderbird/3.1.10 ThunderBrowse/3.3.5 MIME-Version: 1.0 To: freebsd-current@freebsd.org References: In-Reply-To: X-Enigmail-Version: 1.1.2 OpenPGP: id=3FCA37C1; url=http://www.delphij.net/delphij.asc Content-Type: multipart/mixed; boundary="------------030004070901040408050302" Cc: "George V. Neville-Neil" , Jung-uk Kim Subject: Re: Boot halts on Thinkpad X220 (Sandy Bridge) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: d@delphij.net List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2011 17:40:46 -0000 This is a multi-part message in MIME format. --------------030004070901040408050302 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Try this patch? (I'm still opted to disable the typematic rate detection by default at least for amd64, as we don't do it in the past for amd64) Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (FreeBSD) iQEcBAEBCAAGBQJN1ASPAAoJEATO+BI/yjfBmsMH/0/VmxTyIAK2maoihg+/BhGR 5hwWnlCrW7i8a5If77o9e6apishlIgUMuf71WBAIVG+BF71I2QyEWNz+NsR9A+DM N2YPok+oUVASyUIMHvvPC5gNEctcEnaFDOQ1fUWjPeQBoIZajxm0LYeRF7PDKA6R n3HfstrQRwfzzRms96gkwCXdmffOuokqPK0EMwub+Dd+1NkLcnv/VaaJFR9OwlBd cxayhNbTMSbW92x9GBz4O9HrQ1UBhYdi+jru2GBTbeNegh8bZGppoV8rfZQXvq5x MU37Wgt0DolJY05BB58TTVW8weKRPiqUkHBc1aCK9X0AojXo76aXSUwdk40xSfs= =+die -----END PGP SIGNATURE----- --------------030004070901040408050302 Content-Type: text/plain; name="atkbd.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="atkbd.diff" Index: sys/dev/atkbdc/atkbd.c =================================================================== --- sys/dev/atkbdc/atkbd.c (revision 221536) +++ sys/dev/atkbdc/atkbd.c (working copy) @@ -1097,6 +1097,9 @@ x86regs_t regs; uint8_t *p; + if (!(kbd->kb_config & KB_CONF_PROBE_TYPEMATIC)) + return (ENODEV); + if (x86bios_get_intr(0x15) == 0 || x86bios_get_intr(0x16) == 0) return (ENODEV); Index: sys/dev/atkbdc/atkbdreg.h =================================================================== --- sys/dev/atkbdc/atkbdreg.h (revision 221536) +++ sys/dev/atkbdc/atkbdreg.h (working copy) @@ -36,6 +36,7 @@ #define KB_CONF_NO_RESET (1 << 1) /* don't reset the keyboard */ #define KB_CONF_ALT_SCANCODESET (1 << 2) /* assume the XT type keyboard */ #define KB_CONF_NO_PROBE_TEST (1 << 3) /* don't test keyboard during probe */ +#define KB_CONF_PROBE_TYPEMATIC (1 << 4) /* probe keyboard typematic */ #ifdef _KERNEL --------------030004070901040408050302-- From owner-freebsd-current@FreeBSD.ORG Wed May 18 20:27:56 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 8BBB51065673; Wed, 18 May 2011 20:27:56 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.8]) by mx1.freebsd.org (Postfix) with ESMTP id 0406B8FC0C; Wed, 18 May 2011 20:27:55 +0000 (UTC) Received: from [10.54.190.172] (gw-105.extranet.sea01.isilon.com [74.85.160.105]) by mrelayeu.kundenserver.de (node=mrbap4) with ESMTP (Nemesis) id 0LoZAI-1Pm5gY3BIg-00gYPe; Wed, 18 May 2011 22:27:55 +0200 Message-ID: <4DD42BC6.80104@love2party.net> Date: Wed, 18 May 2011 13:27:50 -0700 From: Max Laier User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.15) Gecko/20110419 Lightning/1.0b2pre Thunderbird/3.1.9 MIME-Version: 1.0 To: John Baldwin References: <4DCD357D.6000109@FreeBSD.org> <201105171256.41091.jhb@freebsd.org> <4DD2C99D.50203@love2party.net> <201105171635.17704.jhb@freebsd.org> In-Reply-To: <201105171635.17704.jhb@freebsd.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V02:K0:C9bOm2M9KQKK1EBcln6j0sWPEAPxc7N/2/aNyWXj071 F/FH5D7i1TMxpbvgBiNL0d6ZEsuPXq2G4/C8ib1choUgl/wDO7 Mjg2zNYsYdXn++4oVPmlSqTUrdEDBLF09LDAyvnv6QIwlHWo8k si/D/bxZN9ld3bKzQpqufjSMiyFDO+XzAA+xgsZ0EeqKHYprKL s/fJWyK485Ysgg533WOXQ== Cc: neel@freebsd.org, Andriy Gapon , Attilio Rao , FreeBSD current , Stephan Uphoff , Peter Grehan Subject: Re: proposed smp_rendezvous change 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, 18 May 2011 20:27:56 -0000 On 05/17/2011 01:35 PM, John Baldwin wrote: ... > Yeah, I already have a patch to do that, but hadn't added atomic ops to > critical_enter() and critical_exit(). But it also wasn't as fancy in the > critical_exit() case. Here is what I have and I think it might actually > be ok (it doesn't use an atomic read and clear, but I think it is safe). > Hmm, actually, it will need to use the read and clear: Looks good to me. I was slightly surprised by this: > Index: kern/kern_synch.c > =================================================================== > --- kern/kern_synch.c (revision 222024) > +++ kern/kern_synch.c (working copy) > @@ -400,9 +400,7 @@ > if (!TD_ON_LOCK(td)&& !TD_IS_RUNNING(td)) > mtx_assert(&Giant, MA_NOTOWNED); > #endif > - KASSERT(td->td_critnest == 1 || (td->td_critnest == 2&& > - (td->td_owepreempt)&& (flags& SW_INVOL) != 0&& > - newtd == NULL) || panicstr, > + KASSERT(td->td_critnest == 1 || panicstr, > ("mi_switch: switch in a critical section")); > KASSERT((flags& (SW_INVOL | SW_VOL)) != 0, > ("mi_switch: switch must be voluntary or involuntary")); part of the patch. But that is in fact correct and much more expressive and safe than the version we had before. Thanks, Max P.S. I'd like to see this and the rendezvous changes in stable/7 in the not too distant future. Mind if I MFH these when you are done - unless you are planing to do it already, anyways. From owner-freebsd-current@FreeBSD.ORG Thu May 19 09:23: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 268C01065679 for ; Thu, 19 May 2011 09:23:44 +0000 (UTC) (envelope-from deeptech71@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 BE2FA8FC16 for ; Thu, 19 May 2011 09:23:43 +0000 (UTC) Received: by gwb15 with SMTP id 15so1048594gwb.13 for ; Thu, 19 May 2011 02:23:43 -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:content-type:content-transfer-encoding; bh=J6jKlRXbcy4cJY4Ob2W/qLbdB2ikLcJQr7gGYGn9Vfo=; b=Ls6pF5ucRl6azxUTvPIlnwtyNHWlDWtzcNmA+WMxSO6enxyjDgDadBkoEHeysy3vPy KAh8UK0zmefkkqZ0WmSr0lkupk0vBNBUdYa0KQr5ddbCEKY1PQ8Ccst53ZgxjLUS1ttu BrF+YWgY1DQc3NUzP5WNbxH5W3Vs+Aq7RD7kw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=Y4bnX3aLB6uJH97Y9yfpsm/fHzYUwAI56m0AUTLVPSZbcS7IloIW3EJytONdquOT/x JYnD9Zx362KFJdaavLoYqL5ARt6oT7cWKMsNBW977mJZYpYcD9waa3bTZwkI2XiI2zB9 ZpGp9jh+NZYBic33Gt8iy76ghaTuHYuYkknh8= MIME-Version: 1.0 Received: by 10.236.186.38 with SMTP id v26mr3185130yhm.415.1305797022923; Thu, 19 May 2011 02:23:42 -0700 (PDT) Received: by 10.236.107.197 with HTTP; Thu, 19 May 2011 02:23:42 -0700 (PDT) In-Reply-To: <201105171640.11148.jhb@freebsd.org> References: <201105170944.16261.jhb@freebsd.org> <201105171640.11148.jhb@freebsd.org> Date: Thu, 19 May 2011 11:23:42 +0200 Message-ID: From: "deeptech71@gmail.com" To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: pcib allocation failure 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, 19 May 2011 09:23:44 -0000 On Tue, May 17, 2011 at 10:40 PM, John Baldwin wrote: > On Tuesday, May 17, 2011 2:03:42 pm deeptech71@gmail.com wrote: >> On Tue, May 17, 2011 at 3:44 PM, John Baldwin wrote: >> > On Saturday, May 14, 2011 12:27:59 pm deeptech71@gmail.com wrote: >> >> pcib1: at device 1.0 on pci0 >> >> pcib1: failed to allocate initial prefetch window: 0xd0000000-0xfafff= fff >> >> >> >> the console output is cut shortly after those 2 lines (but the machin= e >> >> seems to continue booting, as i have reset'd the machine, after which >> >> "/" was found to be improperly dismounted). >> > >> > So it actually boots fine, but video output breaks during the boot? = =A0Does it >> > ever come back or it is permanently broken until reboot? >> >> the video output is permanently broken until reboot (i was able to >> gather logs by using delayed rc.d scripts). >> >> > Your BIOS is actually violating the PCI spec by assigning the same res= ource >> > ranges to two devices on the same PCI bus (the hostb device and the AG= P bridge >> > device). =A0It's also doing so unnecessarily. >> >> ok, i've tried changing random BIOS settings, and found that changing >> "AGP Aperture Size" from 128M to 64M solved the problem with the new >> PCI bus driver. (i have a computer with 512MiB of RAM and an AGP video >> card with 128MiB of RAM.) weird. any comments on that? (also, i have noticed a ~64Mi detraction in resource ranges) > Does it still fail to alloc the initial prefetch window in that case? hmm! good question, there does seem to be another failure with pcib2, although without any noticable effect on the system's functionality: pcib2: failed to allocate initial memory window: 0xf7f00000-0xfbffffff for the sake of completeness, here r the logs, coming from an r222043 kernel with the new PCI bus driver: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D ``devinfo -rv'' begins =3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D nexus0 npx0 apic0 ram0 I/O memory addresses: 0x0-0x9fbff 0x100000-0x1ff2ffff acpi0 Interrupt request lines: 9 I/O ports: 0x10-0x1f 0x22-0x3f 0x44-0x5f 0x62-0x63 0x65-0x6f 0x72-0x7f 0x80 0x84-0x86 0x88 0x8c-0x8e 0x90-0x9f 0xa2-0xbf 0xe0-0xef 0x290-0x297 0x480-0x4bf 0x4d0-0x4d1 0x680-0x6ff 0x800-0x87f I/O memory addresses: 0xc0000-0xdffff 0xe0000-0xfffff 0xfec00000-0xfec00fff 0xfed20000-0xfed8ffff 0xfee00000-0xfee00fff 0xffb00000-0xffbfffff 0xfff00000-0xffffffff cpu0 pnpinfo _HID=3Dnone _UID=3D0 at handle=3D\_PR_.CPU1 p4tcc0 cpufreq0 cpu1 pnpinfo _HID=3Dnone _UID=3D0 at handle=3D\_PR_.CPU2 p4tcc1 cpufreq1 pcib0 pnpinfo _HID=3DPNP0A03 _UID=3D0 at handle=3D\_SB_.PCI0 I/O ports: 0xcf8-0xcff pci0 hostb0 pnpinfo vendor=3D0x8086 device=3D0x2570 subvendor=3D0x1043 subdevice=3D0x80f2 class=3D0x060000 at slot=3D0 function=3D0 I/O memory addresses: 0xf8000000-0xfbffffff agp0 pcib1 pnpinfo vendor=3D0x8086 device=3D0x2571 subvendor=3D0x0000 subdevice=3D0x0000 class=3D0x060400 at slot=3D1 function=3D0 handle=3D\_SB_.PCI0.P0P1 I/O ports: 0xd000-0xdfff I/O memory addresses: 0xd0000000-0xf6ffffff 0xf7e00000-0xf7efffff pci1 vgapci0 pnpinfo vendor=3D0x1002 device=3D0x4150 subvendor=3D0x17ee subdevice=3D0x2002 class=3D0x030000 at slot=3D0 function= =3D0 Interrupt request lines: 16 pcib1 I/O port window: 0xd000-0xd0ff pcib1 memory window: 0xf7ee0000-0xf7eeffff pcib1 prefetch window: 0xd0000000-0xdfffffff vgapm0 drm0 vgapci1 pnpinfo vendor=3D0x1002 device=3D0x4170 subvendor=3D0x17ee subdevice=3D0x2003 class=3D0x038000 at slot=3D0 function= =3D1 pcib1 memory window: 0xf7ef0000-0xf7efffff pcib1 prefetch window: 0xe0000000-0xefffffff drm1 uhci0 pnpinfo vendor=3D0x8086 device=3D0x24d2 subvendor=3D0x1043 subdevice=3D0x80a6 class=3D0x0c0300 at slot=3D29 function=3D0 handle=3D\_SB_.PCI0.USB1 Interrupt request lines: 16 I/O ports: 0xc880-0xc89f usbus0 uhub0 uhci1 pnpinfo vendor=3D0x8086 device=3D0x24d4 subvendor=3D0x1043 subdevice=3D0x80a6 class=3D0x0c0300 at slot=3D29 function=3D1 handle=3D\_SB_.PCI0.USB2 Interrupt request lines: 19 I/O ports: 0xcc00-0xcc1f usbus1 uhub1 ums0 pnpinfo vendor=3D0x04fc product=3D0x0801 devclass=3D0x00 devsubclass=3D0x00 sernum=3D"" release=3D0x1611 intclass=3D0x03 intsubclass=3D0x01 at bus=3D1 hubaddr=3D2 port=3D1 devaddr=3D2 interface=3D= 0 ehci0 pnpinfo vendor=3D0x8086 device=3D0x24dd subvendor=3D0x1043 subdevice=3D0x80a6 class=3D0x0c0320 at slot=3D29 function=3D7 handle=3D\_SB_.PCI0.EUSB Interrupt request lines: 23 I/O memory addresses: 0xf7dffc00-0xf7dfffff usbus2 uhub2 pcib2 pnpinfo vendor=3D0x8086 device=3D0x244e subvendor=3D0x0000 subdevice=3D0x0000 class=3D0x060400 at slot=3D30 function=3D0 handle=3D\_SB_.PCI0.P0P4 I/O ports: 0xe000-0xefff I/O memory addresses: 0xf7f00000-0xf7ffffff pci2 skc0 pnpinfo vendor=3D0x10b7 device=3D0x1700 subvendor=3D0x1043 subdevice=3D0x80eb class=3D0x020000 at slot=3D5 function=3D0 Interrupt request lines: 22 pcib2 I/O port window: 0xe800-0xe8ff pcib2 memory window: 0xf7ffc000-0xf7ffffff sk0 miibus0 e1000phy0 pnpinfo oui=3D0xac2 model=3D0x2 rev=3D0x3 at ph= yno=3D0 pcm0 pnpinfo vendor=3D0x1274 device=3D0x5880 subvendor=3D0x1274 subdevice=3D0x8001 class=3D0x040100 at slot=3D12 function=3D0 Interrupt request lines: 20 pcib2 I/O port window: 0xec00-0xec3f isab0 pnpinfo vendor=3D0x8086 device=3D0x24d0 subvendor=3D0x0000 subdevice=3D0x0000 class=3D0x060100 at slot=3D31 function=3D0 handle=3D\_SB_.PCI0.SBRG isa0 pmtimer0 sc0 vga0 I/O ports: 0x3c0-0x3df I/O memory addresses: 0xa0000-0xbffff orm0 pnpinfo pnpid=3DORM0000 ACPI I/O memory addresses: 0xc0000-0xccfff fdc0 ppc0 uart0 uart1 atapci0 pnpinfo vendor=3D0x8086 device=3D0x24db subvendor=3D0x1043 subdevice=3D0x80a6 class=3D0x01018a at slot=3D31 function=3D1 handle=3D\_SB_.PCI0.IDE0 I/O ports: 0x170-0x177 0x1f0-0x1f7 0x376 0x3f6 0xfc00-0xfc0f ata0 at channel=3D0 Interrupt request lines: 14 ata1 at channel=3D1 Interrupt request lines: 15 unknown pnpinfo vendor=3D0x8086 device=3D0x24d3 subvendor=3D0x1043 subdevice=3D0x80a6 class=3D0x0c0500 at slot=3D31 function=3D3 I/O ports: 0x400-0x41f unknown pnpinfo _HID=3Dnone _UID=3D0 at handle=3D\_SB_.PCI0.IDE0.CHN0 unknown pnpinfo _HID=3Dnone _UID=3D0 at handle=3D\_SB_.PCI0.IDE0.CHN0.D= RV0 unknown pnpinfo _HID=3Dnone _UID=3D0 at handle=3D\_SB_.PCI0.IDE0.CHN0.D= RV1 unknown pnpinfo _HID=3Dnone _UID=3D0 at handle=3D\_SB_.PCI0.IDE0.CHN1 unknown pnpinfo _HID=3Dnone _UID=3D0 at handle=3D\_SB_.PCI0.IDE0.CHN1.D= RV0 unknown pnpinfo _HID=3Dnone _UID=3D0 at handle=3D\_SB_.PCI0.IDE0.CHN1.D= RV1 unknown pnpinfo _HID=3Dnone _UID=3D0 at handle=3D\_SB_.PCI0.IDE1 unknown pnpinfo _HID=3Dnone _UID=3D0 at handle=3D\_SB_.PCI0.MC97 unknown pnpinfo _HID=3Dnone _UID=3D0 at handle=3D\_SB_.PCI0.USB3 unknown pnpinfo _HID=3Dnone _UID=3D0 at handle=3D\_SB_.PCI0.USB4 atpic0 pnpinfo _HID=3DPNP0000 _UID=3D0 at handle=3D\_SB_.PCI0.SBRG.PIC_ I/O ports: 0x20-0x21 0xa0-0xa1 atdma0 pnpinfo _HID=3DPNP0200 _UID=3D0 at handle=3D\_SB_.PCI0.SBRG.DMAD DMA request lines: 4 I/O ports: 0x0-0xf 0x81-0x83 0x87 0x89-0x8b 0x8f 0xc0-0xdf attimer0 pnpinfo _HID=3DPNP0100 _UID=3D0 at handle=3D\_SB_.PCI0.SBRG.TM= R_ Interrupt request lines: 0 I/O ports: 0x40-0x43 atrtc0 pnpinfo _HID=3DPNP0B00 _UID=3D0 at handle=3D\_SB_.PCI0.SBRG.RTC0 Interrupt request lines: 8 I/O ports: 0x70-0x71 atkbdc0 pnpinfo _HID=3DPNP0303 _UID=3D0 at handle=3D\_SB_.PCI0.SBRG.PS2= K Interrupt request lines: 1 I/O ports: 0x60 0x64 atkbd0 psm0 psmcpnp0 pnpinfo _HID=3DPNP0F03 _UID=3D0 at handle=3D\_SB_.PCI0.SBRG.PS= 2M unknown pnpinfo _HID=3DPNP0800 _UID=3D0 at handle=3D\_SB_.PCI0.SBRG.SPK= R I/O ports: 0x61 npxisa0 pnpinfo _HID=3DPNP0C04 _UID=3D0 at handle=3D\_SB_.PCI0.SBRG.COP= R I/O ports: 0xf0-0xff unknown pnpinfo _HID=3DPNP0501 _UID=3D1 at handle=3D\_SB_.PCI0.SBRG.UAR= 1 unknown pnpinfo _HID=3DPNP0501 _UID=3D2 at handle=3D\_SB_.PCI0.SBRG.UAR= 2 unknown pnpinfo _HID=3DPNP0700 _UID=3D0 at handle=3D\_SB_.PCI0.SBRG.FDC= _ unknown pnpinfo _HID=3DPNP0400 _UID=3D1 at handle=3D\_SB_.PCI0.SBRG.LPT= E unknown pnpinfo _HID=3DPNPB02F _UID=3D0 at handle=3D\_SB_.PCI0.SBRG.GAM= E unknown pnpinfo _HID=3DPNPB006 _UID=3D0 at handle=3D\_SB_.PCI0.SBRG.MID= I acpi_sysresource0 pnpinfo _HID=3DPNP0C02 _UID=3D46 at handle=3D\_SB_.PCI0.SBRG.SIOR acpi_sysresource1 pnpinfo _HID=3DPNP0C02 _UID=3D16 at handle=3D\_SB_.PCI0.SBRG.RMSC unknown pnpinfo _HID=3DPNP0C02 _UID=3D1014 at handle=3D\_SB_.PCI0.SBRG.= P3F6 acpi_sysresource2 pnpinfo _HID=3DPNP0C02 _UID=3D0 at handle=3D\_SB_.PCI= 0.SBRG.OMSC unknown pnpinfo _HID=3Dnone _UID=3D0 at handle=3D\_SB_.PCI0.P0P2 unknown pnpinfo _HID=3Dnone _UID=3D0 at handle=3D\_SB_.PCI0.P0P2.ILAN acpi_sysresource3 pnpinfo _HID=3DPNP0C01 _UID=3D1 at handle=3D\_SB_.RME= M acpi_button0 pnpinfo _HID=3DPNP0C0C _UID=3D170 at handle=3D\_SB_.PWRB pci_link0 pnpinfo _HID=3DPNP0C0F _UID=3D1 at handle=3D\_SB_.LNKA pci_link1 pnpinfo _HID=3DPNP0C0F _UID=3D2 at handle=3D\_SB_.LNKB pci_link2 pnpinfo _HID=3DPNP0C0F _UID=3D3 at handle=3D\_SB_.LNKC pci_link3 pnpinfo _HID=3DPNP0C0F _UID=3D4 at handle=3D\_SB_.LNKD pci_link4 pnpinfo _HID=3DPNP0C0F _UID=3D5 at handle=3D\_SB_.LNKE pci_link5 pnpinfo _HID=3DPNP0C0F _UID=3D6 at handle=3D\_SB_.LNKF pci_link6 pnpinfo _HID=3DPNP0C0F _UID=3D7 at handle=3D\_SB_.LNKG pci_link7 pnpinfo _HID=3DPNP0C0F _UID=3D8 at handle=3D\_SB_.LNKH acpi_timer0 pnpinfo unknown at unknown ACPI I/O ports: 0x808-0x80b =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D ``devinfo -rv'' ends =3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D ``devinfo -u'' begins =3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D Interrupt request lines: 0 (attimer0) 1 (atkbdc0) 3-7 (root0) 8 (atrtc0) 9 (acpi0) 10-13 (root0) 14 (ata0) 15 (ata1) 16 (uhci0) 16 (vgapci0) 17-18 (root0) 19 (uhci1) 20 (pcm0) 21 (root0) 22 (skc0) 23 (ehci0) DMA request lines: 0-3 (root0) 4 (atdma0) 5-7 (root0) I/O ports: 0x0-0xf (atdma0) 0x10-0x1f (acpi0) 0x20-0x21 (atpic0) 0x22-0x3f (acpi0) 0x40-0x43 (attimer0) 0x44-0x5f (acpi0) 0x60 (atkbdc0) 0x61 ---- 0x62-0x63 (acpi0) 0x64 (atkbdc0) 0x65-0x6f (acpi0) 0x70-0x71 (atrtc0) 0x72-0x7f (acpi0) 0x80 (acpi0) 0x81-0x83 (atdma0) 0x84-0x86 (acpi0) 0x87 (atdma0) 0x88 (acpi0) 0x89-0x8b (atdma0) 0x8c-0x8e (acpi0) 0x8f (atdma0) 0x90-0x9f (acpi0) 0xa0-0xa1 (atpic0) 0xa2-0xbf (acpi0) 0xc0-0xdf (atdma0) 0xe0-0xef (acpi0) 0xf0-0xff (npxisa0) 0x100-0x16f (root0) 0x170-0x177 (atapci0) 0x178-0x1ef (root0) 0x1f0-0x1f7 (atapci0) 0x1f8-0x28f (root0) 0x290-0x297 (acpi0) 0x298-0x375 (root0) 0x376 (atapci0) 0x377-0x3bf (root0) 0x3c0-0x3df (vga0) 0x3e0-0x3f5 (root0) 0x3f6 (atapci0) 0x3f7-0x3ff (root0) 0x400-0x41f ---- 0x420-0x47f (root0) 0x480-0x4bf (acpi0) 0x4c0-0x4cf (root0) 0x4d0-0x4d1 (acpi0) 0x4d2-0x67f (root0) 0x680-0x6ff (acpi0) 0x700-0x7ff (root0) 0x800-0x87f (acpi0) 0x880-0xcf7 (root0) 0xcf8-0xcff (pcib0) 0xd00-0xc87f (root0) 0xc880-0xc89f (uhci0) 0xc8a0-0xcbff (root0) 0xcc00-0xcc1f (uhci1) 0xcc20-0xcfff (root0) 0xd000-0xdfff (pcib1) 0xe000-0xefff (pcib2) 0xf000-0xfbff (root0) 0xfc00-0xfc0f (atapci0) 0xfc10-0xffff (root0) I/O memory addresses: 0x0-0x9fbff (ram0) 0x9fc00-0x9ffff (root0) 0xa0000-0xbffff (vga0) 0xc0000-0xdffff (acpi0) 0xe0000-0xfffff (acpi0) 0x100000-0x1ff2ffff (ram0) 0x1ff30000-0xcfffffff (root0) 0xd0000000-0xf6ffffff (pcib1) 0xf7000000-0xf7dffbff (root0) 0xf7dffc00-0xf7dfffff (ehci0) 0xf7e00000-0xf7efffff (pcib1) 0xf7f00000-0xf7ffffff (pcib2) 0xf8000000-0xfbffffff (hostb0) 0xfc000000-0xfebfffff (root0) 0xfec00000-0xfec00fff (acpi0) 0xfec01000-0xfed1ffff (root0) 0xfed20000-0xfed8ffff (acpi0) 0xfed90000-0xfedfffff (root0) 0xfee00000-0xfee00fff (acpi0) 0xfee01000-0xffafffff (root0) 0xffb00000-0xffbfffff (acpi0) 0xffc00000-0xffefffff (root0) 0xfff00000-0xffffffff (acpi0) ACPI I/O ports: 0x10-0x1f (root0) 0x22-0x3f (root0) 0x44-0x5f (root0) 0x62-0x63 (root0) 0x65-0x6f (root0) 0x72-0x80 (root0) 0x84-0x86 (root0) 0x88 (root0) 0x8c-0x8e (root0) 0x90-0x9f (root0) 0xa2-0xbf (root0) 0xe0-0xef (root0) 0x290-0x297 (root0) 0x480-0x4bf (root0) 0x4d0-0x4d1 (root0) 0x680-0x6ff (root0) 0x800-0x807 (root0) 0x808-0x80b (acpi_timer0) 0x80c-0x87f (root0) ACPI I/O memory addresses: 0xc0000-0xccfff (orm0) 0xcd000-0xfffff (root0) 0xfec00000-0xfec00fff (root0) 0xfed20000-0xfed8ffff (root0) 0xfee00000-0xfee00fff (root0) 0xffb00000-0xffbfffff (root0) 0xfff00000-0xffffffff (root0) pcib1 I/O port window: 0xd000-0xd0ff (vgapci0) 0xd100-0xdfff (root0) pcib1 memory window: 0xf7e00000-0xf7edffff (root0) 0xf7ee0000-0xf7eeffff (vgapci0) 0xf7ef0000-0xf7efffff (vgapci1) pcib1 prefetch window: 0xd0000000-0xdfffffff (vgapci0) 0xe0000000-0xefffffff (vgapci1) 0xf0000000-0xf6ffffff (root0) pcib2 I/O port window: 0xe000-0xe7ff (root0) 0xe800-0xe8ff (skc0) 0xe900-0xebff (root0) 0xec00-0xec3f (pcm0) 0xec40-0xefff (root0) pcib2 memory window: 0xf7f00000-0xf7ffbfff (root0) 0xf7ffc000-0xf7ffffff (skc0) pcib2 prefetch window: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D ``devinfo -u'' ends =3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D ``dmesg'' begins =3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D MP Configuration Table version 1.1 found at 0xc00f1280 Table 'FACP' at 0x1ff30290 Table 'APIC' at 0x1ff30390 APIC: Found table at 0x1ff30390 APIC: Using the MADT enumerator. MADT: Found CPU APIC ID 0 ACPI ID 1: enabled SMP: Added CPU 0 (AP) MADT: Found CPU APIC ID 1 ACPI ID 2: enabled SMP: Added CPU 1 (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. FreeBSD 9.0-CURRENT #0 r222043M: Wed May 18 05:21:58 CEST 2011 devhc@:/usr/obj/usr/src/sys/HQ i386 Table 'FACP' at 0x1ff30290 Table 'APIC' at 0x1ff30390 Table 'OEMB' at 0x1ff40040 ACPI: No SRAT table found Preloaded elf kernel "/boot/kernel.HQ.r222043.copyin2.opie/kernel" at 0xc0b9d000. Calibrating TSC clock ... TSC clock: 2798716448 Hz CPU: Intel(R) Pentium(R) 4 CPU 2.80GHz (2798.72-MHz 686-class CPU) Origin =3D "GenuineIntel" Id =3D 0xf29 Family =3D f Model =3D 2 Stepp= ing =3D 9 Features=3D0xbfebfbff Features2=3D0x4400 Instruction TLB: 4 KB, 2 MB or 4 MB pages, fully associative, 64 entries Data TLB: 4 KB or 4 MB pages, fully associative, 64 entries 1st-level data cache: 8 KB, 4-way set associative, sectored cache, 64 byte line size Trace cache: 12K-uops, 8-way set associative 2nd-level cache: 512 KB, 8-way set associative, sectored cache, 64 byte line size real memory =3D 536870912 (512 MB) Physical memory chunk(s): 0x0000000000001000 - 0x000000000009efff, 647168 bytes (158 pages) 0x0000000000100000 - 0x00000000003fffff, 3145728 bytes (768 pages) 0x0000000000c26000 - 0x000000001f5ecfff, 513568768 bytes (125383 pages) avail memory =3D 513884160 (490 MB) Event timer "LAPIC" quality 400 ACPI APIC Table: INTR: Adding local APIC 1 as a target FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 2 package(s) x 1 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 bios32: Found BIOS32 Service Directory header at 0xc00f0000 bios32: Entry =3D 0xf0010 (c00f0010) Rev =3D 0 Len =3D 1 pcibios: PCI BIOS entry at 0xf0000+0x31 pnpbios: Found PnP BIOS data at 0xc00f5020 pnpbios: Entry =3D f0000:5c0a Rev =3D 1.0 Other BIOS signatures found: APIC: CPU 0 has ACPI ID 1 APIC: CPU 1 has ACPI ID 2 ULE: setup cpu 0 ULE: setup cpu 1 ACPI: RSDP 0xf9e30 00021 (v02 ACPIAM) ACPI: XSDT 0x1ff30100 0003C (v01 A M I OEMXSDT 10000414 MSFT 00000097) ACPI: FACP 0x1ff30290 000F4 (v03 A M I OEMFACP 10000414 MSFT 00000097) ACPI: DSDT 0x1ff303f0 0382D (v01 P4P81 P4P81104 00000104 INTL 02002026) ACPI: FACS 0x1ff40000 00040 ACPI: APIC 0x1ff30390 0005C (v01 A M I OEMAPIC 10000414 MSFT 00000097) ACPI: OEMB 0x1ff40040 0003F (v01 A M I OEMBIOS 10000414 MSFT 00000097) MADT: Found IO APIC ID 2, Interrupt 0 at 0xfec00000 ioapic0: Routing external 8259A's -> intpin 0 MADT: Interrupt override: source 0, irq 2 ioapic0: Routing IRQ 0 -> intpin 2 MADT: Interrupt override: source 9, irq 9 ioapic0: intpin 9 trigger: level ioapic0 irqs 0-23 on motherboard cpu0 BSP: ID: 0x00000000 VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000100ef therm: 0x00010000 err: 0x000000f0 pmc: 0x00010400 snd_unit_init() u=3D0x00ff8000 [512] d=3D0x00007c00 [32] c=3D0x000003ff [10= 24] feeder_register: snd_unit=3D-1 snd_maxautovchans=3D16 latency=3D5 feeder_rate_min=3D1 feeder_rate_max=3D2016000 feeder_rate_round=3D25 null: nfslock: pseudo-device random: io: kbd: new array size 4 kbd1 at kbdmux0 mem: Pentium Pro MTRR support enabled acpi0: on motherboard ioapic0: routing intpin 9 (ISA IRQ 9) to lapic 0 vector 48 ACPI: Executed 1 blocks of module-level executable AML code acpi0: Power Button (fixed) acpi0: wakeup code va 0xc2694000 pa 0x1000 pci_open(1): mode 1 addr port (0x0cf8) is 0x80000090 pci_open(1a): mode1res=3D0x80000000 (0x80000000) pci_cfgcheck: device 0 [class=3D060000] [hdr=3D00] is there (id=3D25708086) pcibios: BIOS version 2.10 acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, 1fef0000 (3) failed ACPI timer: 1/0 1/0 1/0 1/0 1/0 1/0 1/0 1/0 1/0 1/0 -> 10 Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 cpu0: on acpi0 cpu0: switching to generic Cx mode cpu1: on acpi0 pci_link0: Index IRQ Rtd Ref IRQs Initial Probe 0 10 N 0 3 4 5 6 7 10 11 12 14 15 Validation 0 10 N 0 3 4 5 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 10 11 12 14 15 pci_link1: Index IRQ Rtd Ref IRQs Initial Probe 0 10 N 0 3 4 5 6 7 10 11 12 14 15 Validation 0 10 N 0 3 4 5 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 10 11 12 14 15 pci_link2: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 4 5 6 7 10 11 12 14 15 Validation 0 255 N 0 3 4 5 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 10 11 12 14 15 pci_link3: Index IRQ Rtd Ref IRQs Initial Probe 0 5 N 0 3 4 5 6 7 10 11 12 14 15 Validation 0 5 N 0 3 4 5 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 10 11 12 14 15 pci_link4: Index IRQ Rtd Ref IRQs Initial Probe 0 7 N 0 3 4 5 6 7 10 11 12 14 15 Validation 0 7 N 0 3 4 5 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 10 11 12 14 15 pci_link5: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 4 5 6 7 10 11 12 14 15 Validation 0 255 N 0 3 4 5 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 10 11 12 14 15 pci_link6: Index IRQ Rtd Ref IRQs Initial Probe 0 3 N 0 3 4 5 6 7 10 11 12 14 15 Validation 0 3 N 0 3 4 5 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 10 11 12 14 15 pci_link7: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 3 4 5 6 7 10 11 12 14 15 Validation 0 11 N 0 3 4 5 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 10 11 12 14 15 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pci0: domain=3D0, physical bus=3D0 found-> vendor=3D0x8086, dev=3D0x2570, revid=3D0x02 domain=3D0, bus=3D0, slot=3D0, func=3D0 class=3D06-00-00, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0006, statreg=3D0x2090, cachelnsz=3D0 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) map[10]: type Prefetchable Memory, range 32, base 0xf8000000, size 26, ena= bled found-> vendor=3D0x8086, dev=3D0x2571, revid=3D0x02 domain=3D0, bus=3D0, slot=3D1, func=3D0 class=3D06-04-00, hdrtype=3D0x01, mfdev=3D0 cmdreg=3D0x0107, statreg=3D0x00a0, cachelnsz=3D0 (dwords) lattimer=3D0x40 (1920 ns), mingnt=3D0x08 (2000 ns), maxlat=3D0x00 (0 ns) found-> vendor=3D0x8086, dev=3D0x24d2, revid=3D0x02 domain=3D0, bus=3D0, slot=3D29, func=3D0 class=3D0c-03-00, hdrtype=3D0x00, mfdev=3D1 cmdreg=3D0x0005, statreg=3D0x0280, cachelnsz=3D0 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) intpin=3Da, irq=3D10 map[20]: type I/O Port, range 32, base 0xc880, size 5, enabled pcib0: matched entry for 0.29.INTA pcib0: slot 29 INTA hardwired to IRQ 16 found-> vendor=3D0x8086, dev=3D0x24d4, revid=3D0x02 domain=3D0, bus=3D0, slot=3D29, func=3D1 class=3D0c-03-00, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0005, statreg=3D0x0280, cachelnsz=3D0 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) intpin=3Db, irq=3D5 map[20]: type I/O Port, range 32, base 0xcc00, size 5, enabled pcib0: matched entry for 0.29.INTB pcib0: slot 29 INTB hardwired to IRQ 19 found-> vendor=3D0x8086, dev=3D0x24dd, revid=3D0x02 domain=3D0, bus=3D0, slot=3D29, func=3D7 class=3D0c-03-20, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0106, statreg=3D0x0290, cachelnsz=3D0 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) intpin=3Dd, irq=3D11 powerspec 2 supports D0 D3 current D0 map[10]: type Memory, range 32, base 0xf7dffc00, size 10, enabled pcib0: matched entry for 0.29.INTD pcib0: slot 29 INTD hardwired to IRQ 23 found-> vendor=3D0x8086, dev=3D0x244e, revid=3D0xc2 domain=3D0, bus=3D0, slot=3D30, func=3D0 class=3D06-04-00, hdrtype=3D0x01, mfdev=3D0 cmdreg=3D0x0107, statreg=3D0x0080, cachelnsz=3D0 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x06 (1500 ns), maxlat=3D0x00 (0 ns) found-> vendor=3D0x8086, dev=3D0x24d0, revid=3D0x02 domain=3D0, bus=3D0, slot=3D31, func=3D0 class=3D06-01-00, hdrtype=3D0x00, mfdev=3D1 cmdreg=3D0x000f, statreg=3D0x0280, cachelnsz=3D0 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) found-> vendor=3D0x8086, dev=3D0x24db, revid=3D0x02 domain=3D0, bus=3D0, slot=3D31, func=3D1 class=3D01-01-8a, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0005, statreg=3D0x0280, cachelnsz=3D0 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) intpin=3Da, irq=3D255 map[20]: type I/O Port, range 32, base 0xfc00, size 4, enabled map[24]: type Memory, range 32, base 0, size 10, memory disabled found-> vendor=3D0x8086, dev=3D0x24d3, revid=3D0x02 domain=3D0, bus=3D0, slot=3D31, func=3D3 class=3D0c-05-00, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0001, statreg=3D0x0280, cachelnsz=3D0 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) intpin=3Db, irq=3D10 map[20]: type I/O Port, range 32, base 0x400, size 5, enabled pcib0: matched entry for 0.31.INTB pcib0: slot 31 INTB hardwired to IRQ 17 agp0: on hostb0 agp0: allocating GATT for aperture of size 64M pcib1: at device 1.0 on pci0 pcib1: domain 0 pcib1: secondary bus 1 pcib1: subordinate bus 1 pcib1: I/O decode 0xd000-0xdfff pcib1: memory decode 0xf7e00000-0xf7efffff pcib1: prefetched decode 0xd0000000-0xf6ffffff pcib1: could not get PCI interrupt routing table for \\_SB_.PCI0.P0P1 - AE_NOT_FOUND pci1: on pcib1 pci1: domain=3D0, physical bus=3D1 found-> vendor=3D0x1002, dev=3D0x4150, revid=3D0x00 domain=3D0, bus=3D1, slot=3D0, func=3D0 class=3D03-00-00, hdrtype=3D0x00, mfdev=3D1 cmdreg=3D0x0107, statreg=3D0x02b0, cachelnsz=3D4 (dwords) lattimer=3D0x40 (1920 ns), mingnt=3D0x08 (2000 ns), maxlat=3D0x00 (0 ns) intpin=3Da, irq=3D10 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type Prefetchable Memory, range 32, base 0xd0000000, size 28, ena= bled pcib1: allocated prefetch range (0xd0000000-0xdfffffff) for rid 10 of pci0:= 1:0:0 map[14]: type I/O Port, range 32, base 0xd000, size 8, enabled pcib1: allocated I/O port range (0xd000-0xd0ff) for rid 14 of pci0:1:0:0 map[18]: type Memory, range 32, base 0xf7ee0000, size 16, enabled pcib1: allocated memory range (0xf7ee0000-0xf7eeffff) for rid 18 of pci0:1:= 0:0 pcib0: matched entry for 0.1.INTA pcib0: slot 1 INTA hardwired to IRQ 16 pcib1: slot 0 INTA is routed to irq 16 found-> vendor=3D0x1002, dev=3D0x4170, revid=3D0x00 domain=3D0, bus=3D1, slot=3D0, func=3D1 class=3D03-80-00, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0007, statreg=3D0x02b0, cachelnsz=3D4 (dwords) lattimer=3D0x40 (1920 ns), mingnt=3D0x08 (2000 ns), maxlat=3D0x00 (0 ns) powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type Prefetchable Memory, range 32, base 0xe0000000, size 28, ena= bled pcib1: allocated prefetch range (0xe0000000-0xefffffff) for rid 10 of pci0:= 1:0:1 map[14]: type Memory, range 32, base 0xf7ef0000, size 16, enabled pcib1: allocated memory range (0xf7ef0000-0xf7efffff) for rid 14 of pci0:1:= 0:1 vgapci0: port 0xd000-0xd0ff mem 0xd0000000-0xdfffffff,0xf7ee0000-0xf7eeffff irq 16 at device 0.0 on pci1 drm0: on vgapci0 info: [drm] AGP at 0xf8000000 64MB info: [drm] Initialized radeon 1.31.0 20080613 vgapci1: mem 0xe0000000-0xefffffff,0xf7ef0000-0xf7efffff at device 0.1 on pci1 uhci0: port 0xc880-0xc89f irq 16 at device 29.0 on pci0 ioapic0: routing intpin 16 (PCI IRQ 16) to lapic 0 vector 49 usbus0: on uhci0 usbus0: bpf attached uhci0: usbpf: Attached uhci1: port 0xcc00-0xcc1f irq 19 at device 29.1 on pci0 ioapic0: routing intpin 19 (PCI IRQ 19) to lapic 0 vector 50 usbus1: on uhci1 usbus1: bpf attached uhci1: usbpf: Attached ehci0: mem 0xf7dffc00-0xf7dfffff irq 23 at device 29.7 on pci0 ioapic0: routing intpin 23 (PCI IRQ 23) to lapic 0 vector 51 usbus2: EHCI version 1.0 usbus2: on ehci0 usbus2: bpf attached ehci0: usbpf: Attached pcib2: at device 30.0 on pci0 pcib2: failed to allocate initial memory window: 0xf7f00000-0xfbffffff pcib2: domain 0 pcib2: secondary bus 2 pcib2: subordinate bus 2 pcib2: I/O decode 0xe000-0xefff pcib2: no prefetched decode pcib2: Subtractively decoded bridge. pci2: on pcib2 pci2: domain=3D0, physical bus=3D2 found-> vendor=3D0x10b7, dev=3D0x1700, revid=3D0x12 domain=3D0, bus=3D2, slot=3D5, func=3D0 class=3D02-00-00, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0117, statreg=3D0x02b0, cachelnsz=3D4 (dwords) lattimer=3D0x40 (1920 ns), mingnt=3D0x17 (5750 ns), maxlat=3D0x1f (7750 ns= ) intpin=3Da, irq=3D3 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type Memory, range 32, base 0xf7ffc000, size 14, enabled pcib2: allocated initial memory window of 0xf7f00000-0xf7ffffff pcib2: allocated memory range (0xf7ffc000-0xf7ffffff) for rid 10 of pci0:2:= 5:0 map[14]: type I/O Port, range 32, base 0xe800, size 8, enabled pcib2: allocated I/O port range (0xe800-0xe8ff) for rid 14 of pci0:2:5:0 pcib2: matched entry for 2.5.INTA pcib2: slot 5 INTA hardwired to IRQ 22 found-> vendor=3D0x1274, dev=3D0x5880, revid=3D0x04 domain=3D0, bus=3D2, slot=3D12, func=3D0 class=3D04-01-00, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0105, statreg=3D0x0410, cachelnsz=3D0 (dwords) lattimer=3D0x40 (1920 ns), mingnt=3D0x0c (3000 ns), maxlat=3D0x80 (32000 n= s) intpin=3Da, irq=3D7 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type I/O Port, range 32, base 0xec00, size 6, enabled pcib2: allocated I/O port range (0xec00-0xec3f) for rid 10 of pci0:2:12:0 pcib2: matched entry for 2.12.INTA pcib2: slot 12 INTA hardwired to IRQ 20 skc0: <3Com 3C940 Gigabit Ethernet> port 0xe800-0xe8ff mem 0xf7ffc000-0xf7ffffff irq 22 at device 5.0 on pci2 skc0: interrupt moderation is 100 us skc0: 3Com Gigabit LOM (3C940) rev. (0x1) skc0: chip ver =3D 0xb0 skc0: chip rev =3D 0x01 skc0: SK_EPROM0 =3D 0x00 skc0: SRAM size =3D 0x020000 sk0: on skc0 sk0: bpf attached sk0: Ethernet address: 00:0e:a6:35:15:91 miibus0: on sk0 e1000phy0: PHY 0 on miibus0 e1000phy0: OUI 0x000ac2, model 0x0002, rev. 3 e1000phy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto ioapic0: routing intpin 22 (PCI IRQ 22) to lapic 0 vector 52 pcm0: port 0xec00-0xec3f irq 20 at device 12.0 on pci2 pcm0: pcm0: Codec features 18 bit DAC, 18 bit ADC, 5 bit master volume, no 3D Stereo Enhancement pcm0: Primary codec extended features surround DAC, AMAP pcm0: ac97 codec dac ready count: 0 pcm0: Mixer "vol": pcm0: Mixer "pcm": pcm0: Mixer "speaker": pcm0: Mixer "line": pcm0: Mixer "mic": pcm0: Mixer "cd": pcm0: Mixer "rec": pcm0: Mixer "igain": pcm0: Mixer "ogain": pcm0: Mixer "line1": pcm0: Mixer "phin": pcm0: Mixer "phout": pcm0: Mixer "video": ioapic0: routing intpin 20 (PCI IRQ 20) to lapic 0 vector 53 pcm0: clone manager: deadline=3D750ms flags=3D0x8000001e pcm0: sndbuf_setmap 169d000, 1000; 0xc2a9d000 -> 169d000 pcm0: sndbuf_setmap 169b000, 1000; 0xc2a9b000 -> 169b000 pcm0: sndbuf_setmap 1699000, 1000; 0xc2a99000 -> 1699000 pcm0: isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xfc00-0xfc0f at device 31.1 on pci0 ata0: on atapci0 ioapic0: routing intpin 14 (ISA IRQ 14) to lapic 0 vector 54 ata1: on atapci0 ioapic0: routing intpin 15 (ISA IRQ 15) to lapic 0 vector 55 pci0: at device 31.3 (no driver attached) acpi_button0: on acpi0 attimer0: port 0x40-0x43 irq 0 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 ioapic0: routing intpin 2 (ISA IRQ 0) to lapic 0 vector 56 Event timer "i8254" frequency 1193182 Hz quality 100 atrtc0: port 0x70-0x71 irq 8 on acpi0 atrtc0: registered as a time-of-day clock (resolution 1000000us, adjustment 0.500000000s) ioapic0: routing intpin 8 (ISA IRQ 8) to lapic 0 vector 57 Event timer "RTC" frequency 32768 Hz quality 0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 atkbd: the current kbd controller command byte 0065 atkbd: keyboard ID 0x41ab (2) kbd0 at atkbd0 kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x3d0000 ioapic0: routing intpin 1 (ISA IRQ 1) to lapic 0 vector 58 atkbd0: [GIANT-LOCKED] psm0: unable to allocate IRQ psmcpnp0: irq 12 on acpi0 psm0: current command byte:0065 psm0: failed to reset the aux device. pnp_identify: Trying Read_Port at 203 pnp_identify: Trying Read_Port at 243 pnp_identify: Trying Read_Port at 283 pnp_identify: Trying Read_Port at 2c3 pnp_identify: Trying Read_Port at 303 pnp_identify: Trying Read_Port at 343 pnp_identify: Trying Read_Port at 383 pnp_identify: Trying Read_Port at 3c3 PNP Identify complete isa_probe_children: disabling PnP devices pmtimer0 on isa0 ata: ata0 already exists; skipping it ata: ata1 already exists; skipping it atkbdc: atkbdc0 already exists; skipping it atrtc: atrtc0 already exists; skipping it attimer: attimer0 already exists; skipping it sc: sc0 already exists; skipping it isa_probe_children: probing non-PnP devices orm0: at iomem 0xc0000-0xccfff pnpid ORM0000 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=3D0x300> sc0: fb0, kbd1, terminal emulator: scteken (teken terminal) vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 fdc0 failed to probe at port 0x3f0 irq 6 drq 2 on isa0 ppc0 failed to probe at irq 7 on isa0 uart0 failed to probe at port 0x3f8 irq 4 on isa0 uart1 failed to probe at port 0x2f8 irq 3 on isa0 isa_probe_children: probing PnP devices p4tcc0: on cpu0 p4tcc1: on cpu1 Device configuration finished. lapic: Divisor 2, Frequency 99952197 Hz Timecounters tick every 1.000 msec lo0: bpf attached usbus0: 12Mbps Full Speed USB v1.0 usbus1: 12Mbps Full Speed USB v1.0 usbus2: 480Mbps High Speed USB v2.0 ata0: reset tp1 mask=3D03 ostat0=3D50 ostat1=3D00 ata0: stat0=3D0x50 err=3D0x01 lsb=3D0x00 msb=3D0x00 ata0: stat1=3D0x00 err=3D0x01 lsb=3D0x00 msb=3D0x00 ata0: reset tp2 stat0=3D50 stat1=3D00 devices=3D0x1 (aprobe0:ata0:0:0:0): SIGNATURE: 0000 ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 ugen2.1: at usbus2 uhub2: on usbus2 ata1: reset tp1 mask=3D03 ostat0=3D50 ostat1=3D00 ata1: stat0=3D0x00 err=3D0x01 lsb=3D0x14 msb=3D0xeb ata1: stat1=3D0x00 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata1: reset tp2 stat0=3D00 stat1=3D00 devices=3D0x10000 (aprobe0:ata1:0:0:0): SIGNATURE: eb14 ata1: DMA limited to UDMA33, controller found non-ATA66 cable ada0 at ata0 bus 0 scbus0 target 0 lun 0 ada0: ATA-7 device ada0: Serial Number Y2JPFJPE ada0: 100.000MB/s transfers (UDMA5, PIO 8192bytes) ada0: 78167MB (160086528 512 byte sectors: 16H 63S/T 16383C) ada0: Previously was known as ad0 GEOM: new disk ada0 pass0 at ata0 bus 0 scbus0 target 0 lun 0 pass0: ATA-7 device pass0: Serial Number Y2JPFJPE(cd0:ata1:0:0:0): SCSI status error (cd0:ata1:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 (cd0:ata1:0:0:0): CAM status: SCSI Status Error (cd0:ata1:0:0:0): SCSI status: Check Condition (cd0:ata1:0:0:0): SCSI sense: UNIT ATTENTION asc:29,0 (Power on, reset, or bus device reset occurred) (cd0:ata1:0:0:0): Retrying command (per sense data) pass0: 100.000MB/s transfers (UDMA5, PIO 8192bytes) pass1 at ata1 bus 0 scbus1 target 0 lun 0 pass1: Removable CD-ROM SCSI-0 device pass1: 33.300MB/s transfers (UDMA2, ATAPI 12bytes, PIO 65534bytes) (cd0:ata1:0:0:0): SCSI status error (cd0:ata1:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 (cd0:ata1:0:0:0): CAM status: SCSI Status Error (cd0:ata1:0:0:0): SCSI status: Check Condition (cd0:ata1:0:0:0): SCSI sense: NOT READY asc:3a,0 (Medium not present) (cd0:ata1:0:0:0): Error 6, Unretryable error cd0 at ata1 bus 0 scbus1 target 0 lun 0 cd0: Removable CD-ROM SCSI-0 device cd0: 33.300MB/s transfers (UDMA2, ATAPI 12bytes, PIO 65534bytes) cd0: Attempt to query device size failed: NOT READY, Medium not present SMP: AP CPU #1 Launched! cpu1 AP: ID: 0x01000000 VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000100ef therm: 0x00010000 err: 0x000000f0 pmc: 0x00010400 ioapic0: routing intpin 1 (ISA IRQ 1) to lapic 1 vector 48 ioapic0: routing intpin 14 (ISA IRQ 14) to lapic 1 vector 49 ioapic0: routing intpin 16 (PCI IRQ 16) to lapic 1 vector 50 ioapic0: routing intpin 20 (PCI IRQ 20) to lapic 1 vector 51 ioapic0: routing intpin 23 (PCI IRQ 23) to lapic 1 vector 52 Timecounter "TSC" frequency 2798716448 Hz quality -100 GEOM: new disk cd0 GEOM: ada0s1: geometry does not match label (255h,63s !=3D 16h,63s). (cd0:ata1:0:0:0): SCSI status error (cd0:ata1:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 (cd0:ata1:0:0:0): CAM status: SCSI Status Error (cd0:ata1:0:0:0): SCSI status: Check Condition (cd0:ata1:0:0:0): SCSI sense: NOT READY asc:3a,0 (Medium not present) (cd0:ata1:0:0:0): Error 6, Unretryable error (cd0:ata1:0:0:0): SCSI status error (cd0:ata1:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 (cd0:ata1:0:0:0): CAM status: SCSI Status Error (cd0:ata1:0:0:0): SCSI status: Check Condition (cd0:ata1:0:0:0): SCSI sense: NOT READY asc:3a,0 (Medium not present) (cd0:ata1:0:0:0): Error 6, Unretryable error Root mount waiting for: usbus2 usbus1 usbus0 uhub0: 2 ports with 2 removable, self powered uhub1: 2 ports with 2 removable, self powered Root mount waiting for: usbus2 uhub2: 4 ports with 4 removable, self powered Root mount waiting for: usbus2 Trying to mount root from ufs:/dev/ada0s1a [rw,noatime]... start_init: trying /sbin/init ugen1.2: at usbus1 ums0: on usbus1 ums0: 5 buttons and [XYZT] coordinates ID=3D1 procfs registered Linux ELF exec handler installed linprocfs registered =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D ``dmesg'' ends =3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D From owner-freebsd-current@FreeBSD.ORG Thu May 19 11:51:26 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 B7F83106564A; Thu, 19 May 2011 11:51:26 +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 8C6058FC0A; Thu, 19 May 2011 11:51:26 +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 27DE446B03; Thu, 19 May 2011 07:51:26 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id A75338A050; Thu, 19 May 2011 07:51:25 -0400 (EDT) From: John Baldwin To: Max Laier Date: Wed, 18 May 2011 17:34:55 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110325; KDE/4.5.5; amd64; ; ) References: <4DCD357D.6000109@FreeBSD.org> <201105171635.17704.jhb@freebsd.org> <4DD42BC6.80104@love2party.net> In-Reply-To: <4DD42BC6.80104@love2party.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201105181734.55988.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Thu, 19 May 2011 07:51:25 -0400 (EDT) Cc: neel@freebsd.org, Andriy Gapon , Attilio Rao , FreeBSD current , Stephan Uphoff , Peter Grehan Subject: Re: proposed smp_rendezvous change 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, 19 May 2011 11:51:26 -0000 On Wednesday, May 18, 2011 4:27:50 pm Max Laier wrote: > On 05/17/2011 01:35 PM, John Baldwin wrote: > ... > > Yeah, I already have a patch to do that, but hadn't added atomic ops to > > critical_enter() and critical_exit(). But it also wasn't as fancy in the > > critical_exit() case. Here is what I have and I think it might actually > > be ok (it doesn't use an atomic read and clear, but I think it is safe). > > Hmm, actually, it will need to use the read and clear: > > Looks good to me. I was slightly surprised by this: > > > Index: kern/kern_synch.c > > =================================================================== > > --- kern/kern_synch.c (revision 222024) > > +++ kern/kern_synch.c (working copy) > > @@ -400,9 +400,7 @@ > > if (!TD_ON_LOCK(td)&& !TD_IS_RUNNING(td)) > > mtx_assert(&Giant, MA_NOTOWNED); > > #endif > > - KASSERT(td->td_critnest == 1 || (td->td_critnest == 2&& > > - (td->td_owepreempt)&& (flags& SW_INVOL) != 0&& > > - newtd == NULL) || panicstr, > > + KASSERT(td->td_critnest == 1 || panicstr, > > ("mi_switch: switch in a critical section")); > > KASSERT((flags& (SW_INVOL | SW_VOL)) != 0, > > ("mi_switch: switch must be voluntary or involuntary")); > > part of the patch. But that is in fact correct and much more expressive > and safe than the version we had before. Ok, I need to stress test this some first. > Thanks, > Max > > P.S. I'd like to see this and the rendezvous changes in stable/7 in the > not too distant future. Mind if I MFH these when you are done - unless > you are planing to do it already, anyways. I will merge them certainly. These are critical fixes. :( -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Thu May 19 12:07: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 779A1106564A; Thu, 19 May 2011 12:07:36 +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 4AF878FC0C; Thu, 19 May 2011 12:07:36 +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 D27D646B06; Thu, 19 May 2011 08:07:35 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 6F2968A04F; Thu, 19 May 2011 08:07:35 -0400 (EDT) From: John Baldwin To: Max Laier Date: Thu, 19 May 2011 08:07:34 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110325; KDE/4.5.5; amd64; ; ) References: <4DCD357D.6000109@FreeBSD.org> <201105171635.17704.jhb@freebsd.org> <4DD42BC6.80104@love2party.net> In-Reply-To: <4DD42BC6.80104@love2party.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201105190807.34978.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Thu, 19 May 2011 08:07:35 -0400 (EDT) Cc: neel@freebsd.org, Andriy Gapon , Attilio Rao , FreeBSD current , Stephan Uphoff , Peter Grehan Subject: Re: proposed smp_rendezvous change 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, 19 May 2011 12:07:36 -0000 On Wednesday, May 18, 2011 4:27:50 pm Max Laier wrote: > On 05/17/2011 01:35 PM, John Baldwin wrote: > ... > > Yeah, I already have a patch to do that, but hadn't added atomic ops to > > critical_enter() and critical_exit(). But it also wasn't as fancy in the > > critical_exit() case. Here is what I have and I think it might actually > > be ok (it doesn't use an atomic read and clear, but I think it is safe). > > Hmm, actually, it will need to use the read and clear: > > Looks good to me. I was slightly surprised by this: > > > Index: kern/kern_synch.c > > =================================================================== > > --- kern/kern_synch.c (revision 222024) > > +++ kern/kern_synch.c (working copy) > > @@ -400,9 +400,7 @@ > > if (!TD_ON_LOCK(td)&& !TD_IS_RUNNING(td)) > > mtx_assert(&Giant, MA_NOTOWNED); > > #endif > > - KASSERT(td->td_critnest == 1 || (td->td_critnest == 2&& > > - (td->td_owepreempt)&& (flags& SW_INVOL) != 0&& > > - newtd == NULL) || panicstr, > > + KASSERT(td->td_critnest == 1 || panicstr, > > ("mi_switch: switch in a critical section")); > > KASSERT((flags& (SW_INVOL | SW_VOL)) != 0, > > ("mi_switch: switch must be voluntary or involuntary")); > > part of the patch. But that is in fact correct and much more expressive > and safe than the version we had before. Actually, this is something that was made obsolete by ups's change to critical_exit() several years ago. However, after sleeping on this last night, I think that critical_enter() and critical_exit() are a very hot path and that it may be worth adding some additional complexity to keep them as cheap as possible. Also, your original patch for rm locks is actually correct. They will not miss a preemption because rm_cleanIPI will not schedule a thread to run while it holds the spin lock. However, I'd like to be a bit more future proof so that other IPI handler authors don't have to deal with this obscure race. Given that, I've generalized your fix and moved it up into the SMP rendezvous code itself along with a big comment to explain why it works and a KASSERT(). I think this is also MFC'able back to 7 as well: Index: kern/subr_smp.c =================================================================== --- kern/subr_smp.c (revision 222032) +++ kern/subr_smp.c (working copy) @@ -316,6 +316,9 @@ void (*local_action_func)(void*); void (*local_teardown_func)(void*); int generation; +#ifdef INVARIANTS + int owepreempt; +#endif /* Ensure we have up-to-date values. */ atomic_add_acq_int(&smp_rv_waiters[0], 1); @@ -330,6 +333,33 @@ generation = smp_rv_generation; /* + * Use a nested critical section to prevent any preemptions + * from occurring during a rendezvous action routine. + * Specifically, if a rendezvous handler is invoked via an IPI + * and the interrupted thread was in the critical_exit() + * function after setting td_critnest to 0 but before + * performing a deferred preemption, this routine can be + * invoked with td_critnest set to 0 and td_owepreempt true. + * In that case, a critical_exit() during the rendezvous + * action would trigger a preemption which is not permitted in + * a rendezvous action. To fix this, wrap all of the + * rendezvous action handlers in a critical section. We + * cannot use a regular critical section however as having + * critical_exit() preempt from this routine would also be + * problematic (the preemption must not occur before the IPI + * has been acknowleged via an EOI). Instead, we + * intentionally ignore td_owepreempt when leaving the + * critical setion. This should be harmless because we do not + * permit rendezvous action routines to schedule threads, and + * thus td_owepreempt should never transition from 0 to 1 + * during this routine. + */ + td->td_critnest++; +#ifdef INVARIANTS + owepreempt = td->td_owepreempt; +#endif + + /* * If requested, run a setup function before the main action * function. Ensure all CPUs have completed the setup * function before moving on to the action function. @@ -362,14 +392,18 @@ */ MPASS(generation == smp_rv_generation); atomic_add_int(&smp_rv_waiters[2], 1); - if (local_teardown_func == smp_no_rendevous_barrier) - return; - while (smp_rv_waiters[2] < smp_rv_ncpus && - generation == smp_rv_generation) - cpu_spinwait(); + if (local_teardown_func != smp_no_rendevous_barrier) { + while (smp_rv_waiters[2] < smp_rv_ncpus && + generation == smp_rv_generation) + cpu_spinwait(); - if (local_teardown_func != NULL) - local_teardown_func(local_func_arg); + if (local_teardown_func != NULL) + local_teardown_func(local_func_arg); + } + + td->td_critnest--; + KASSERT(owepreempt == td->td_owepreempt, + ("rendezvous action changed td_owepreempt")); } void Index: kern/kern_synch.c =================================================================== --- kern/kern_synch.c (revision 222024) +++ kern/kern_synch.c (working copy) @@ -400,9 +400,7 @@ if (!TD_ON_LOCK(td) && !TD_IS_RUNNING(td)) mtx_assert(&Giant, MA_NOTOWNED); #endif - KASSERT(td->td_critnest == 1 || (td->td_critnest == 2 && - (td->td_owepreempt) && (flags & SW_INVOL) != 0 && - newtd == NULL) || panicstr, + KASSERT(td->td_critnest == 1 || panicstr, ("mi_switch: switch in a critical section")); KASSERT((flags & (SW_INVOL | SW_VOL)) != 0, ("mi_switch: switch must be voluntary or involuntary")); -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Thu May 19 12:13: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 3E6F7106566C for ; Thu, 19 May 2011 12:13:39 +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 13F7E8FC0C for ; Thu, 19 May 2011 12:13:39 +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 BE9FC46B23; Thu, 19 May 2011 08:13:38 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 5D94A8A04F; Thu, 19 May 2011 08:13:38 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Date: Thu, 19 May 2011 08:13:37 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110325; KDE/4.5.5; amd64; ; ) References: <201105171640.11148.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201105190813.37908.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Thu, 19 May 2011 08:13:38 -0400 (EDT) Cc: "deeptech71@gmail.com" Subject: Re: pcib allocation failure 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, 19 May 2011 12:13:39 -0000 On Thursday, May 19, 2011 5:23:42 am deeptech71@gmail.com wrote: > On Tue, May 17, 2011 at 10:40 PM, John Baldwin wrote: > > On Tuesday, May 17, 2011 2:03:42 pm deeptech71@gmail.com wrote: > >> On Tue, May 17, 2011 at 3:44 PM, John Baldwin wrote: > >> > On Saturday, May 14, 2011 12:27:59 pm deeptech71@gmail.com wrote: > >> >> pcib1: at device 1.0 on pci0 > >> >> pcib1: failed to allocate initial prefetch window: 0xd0000000-0xfaffffff > >> >> > >> >> the console output is cut shortly after those 2 lines (but the machine > >> >> seems to continue booting, as i have reset'd the machine, after which > >> >> "/" was found to be improperly dismounted). > >> > > >> > So it actually boots fine, but video output breaks during the boot? Does it > >> > ever come back or it is permanently broken until reboot? > >> > >> the video output is permanently broken until reboot (i was able to > >> gather logs by using delayed rc.d scripts). > >> > >> > Your BIOS is actually violating the PCI spec by assigning the same resource > >> > ranges to two devices on the same PCI bus (the hostb device and the AGP bridge > >> > device). It's also doing so unnecessarily. > >> > >> ok, i've tried changing random BIOS settings, and found that changing > >> "AGP Aperture Size" from 128M to 64M solved the problem with the new > >> PCI bus driver. (i have a computer with 512MiB of RAM and an AGP video > >> card with 128MiB of RAM.) weird. any comments on that? > > (also, i have noticed a ~64Mi detraction in resource ranges) > > > Does it still fail to alloc the initial prefetch window in that case? > > hmm! good question, there does seem to be another failure with pcib2, > although without any noticable effect on the system's functionality: > pcib2: failed to allocate initial memory window: 0xf7f00000-0xfbffffff > > for the sake of completeness, here r the logs, coming from an r222043 > kernel with the new PCI bus driver: Yeah, your BIOS continues to behave very poorly. Please try this hack to see if it allows your video to still work with any AGP aperture size: Index: pci_pci.c =================================================================== --- pci_pci.c (revision 222093) +++ pci_pci.c (working copy) @@ -231,7 +231,9 @@ pcib_alloc_window(struct pcib_softc *sc, struct pc w->name, (uintmax_t)w->base, (uintmax_t)w->limit); w->base = max_address; w->limit = 0; +#if 0 pcib_write_windows(sc, w->mask); +#endif return; } pcib_activate_window(sc, type); -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Thu May 19 12:18: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 2C0D81065670 for ; Thu, 19 May 2011 12:18:36 +0000 (UTC) (envelope-from dieterich.joh@googlemail.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 D7D2C8FC0C for ; Thu, 19 May 2011 12:18:35 +0000 (UTC) Received: by iwn33 with SMTP id 33so2975090iwn.13 for ; Thu, 19 May 2011 05:18:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=BB6O1XMgH6PNQehdqlY5EutQ/RPF2cwwCB7r1lSJbiM=; b=FuC3e1NlwmdEu/kMdMsSupzWlqXjExJqjCEXK5ZLw5FDSHTjaq3R2sFeB21w2jgXTI mlEWHDFWpiFXXTbJ7kJADHXjH1AiWBLqPgjR6wee0FEkZUZRsYlGNXdcfXqIoqhVQAVX 3CGdC4pQGRqLYvQHO2tCbrAMaYNOHl6zFPoqA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=wFgjpvjU8TxuSmKLo+Vka9EMEyvbncp/Ydh38/gcOAr1aJBY0kBT7po8cGdvI3ufc4 bn4PKWzvH1jyjMRuqnjB9L4SHSCUM8JM/4zLO8YO9N86hNzAjImyzKyzD1jQeOHwHg0v j436Gbm6UQ1CYhjiodI6Qh72tb6iZP3Er6C+g= MIME-Version: 1.0 Received: by 10.231.53.10 with SMTP id k10mr2307044ibg.1.1305807513864; Thu, 19 May 2011 05:18:33 -0700 (PDT) Received: by 10.231.32.74 with HTTP; Thu, 19 May 2011 05:18:33 -0700 (PDT) In-Reply-To: <4DD4048F.8030207@delphij.net> References: <4DD4048F.8030207@delphij.net> Date: Thu, 19 May 2011 14:18:33 +0200 Message-ID: From: Johannes Dieterich To: d@delphij.net Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: "George V. Neville-Neil" , freebsd-current@freebsd.org, Jung-uk Kim Subject: Re: Boot halts on Thinkpad X220 (Sandy Bridge) 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, 19 May 2011 12:18:36 -0000 On Wed, May 18, 2011 at 7:40 PM, Xin LI wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > Try this patch? > The attached patch makes 9-CURRENT-amd64 boot on the X220 w/o any hints or BIOS fixes needed. Thanks a lot! :-) > > (I'm still opted to disable the typematic rate detection by default at > least for amd64, as we don't do it in the past for amd64) > What does this mean concerning getting the fix into CURRENT? Best regards Johannes Dieterich > > Cheers, > - -- > Xin LI http://www.delphij.net/ > FreeBSD - The Power to Serve! Live free or die > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.17 (FreeBSD) > > iQEcBAEBCAAGBQJN1ASPAAoJEATO+BI/yjfBmsMH/0/VmxTyIAK2maoihg+/BhGR > 5hwWnlCrW7i8a5If77o9e6apishlIgUMuf71WBAIVG+BF71I2QyEWNz+NsR9A+DM > N2YPok+oUVASyUIMHvvPC5gNEctcEnaFDOQ1fUWjPeQBoIZajxm0LYeRF7PDKA6R > n3HfstrQRwfzzRms96gkwCXdmffOuokqPK0EMwub+Dd+1NkLcnv/VaaJFR9OwlBd > cxayhNbTMSbW92x9GBz4O9HrQ1UBhYdi+jru2GBTbeNegh8bZGppoV8rfZQXvq5x > MU37Wgt0DolJY05BB58TTVW8weKRPiqUkHBc1aCK9X0AojXo76aXSUwdk40xSfs= > =+die > -----END PGP SIGNATURE----- > > _______________________________________________ > 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 Thu May 19 14:07: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 3BBF1106576C for ; Thu, 19 May 2011 14:07:38 +0000 (UTC) (envelope-from timothyk@devel.njit.edu) Received: from mail-gw5.njit.edu (mail-gw5.njit.edu [128.235.251.153]) by mx1.freebsd.org (Postfix) with ESMTP id 14A658FC0C for ; Thu, 19 May 2011 14:07:37 +0000 (UTC) Received: from beta.maestro.njit.edu (dhcp114-27.njit.edu [128.235.114.27]) by mail-gw5.njit.edu (8.13.8/8.13.8) with ESMTP id p4JDSfgh008892; Thu, 19 May 2011 09:28:41 -0400 (EDT) Message-ID: <4DD51B09.1090604@devel.njit.edu> Date: Thu, 19 May 2011 09:28:41 -0400 From: Tim Kellers User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.17) Gecko/20110506 Thunderbird/3.1.10 MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Tim Kellers Subject: make install fails when updating /etc/localtime 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, 19 May 2011 14:07:40 -0000 From sources csuped May 18, 2:00 PM EDT. make buildworld completed with no error. uname -a FreeBSD news.smsdsite.com 9.0-CURRENT FreeBSD 9.0-CURRENT #0: Tue May 17 14:35:44 EDT 2011 timothyk@news.smsdsite.com:/usr/obj/usr/src/sys/MAY17 amd64 ===> share/zoneinfo (install) umask 022; cd /usr/src/share/zoneinfo; zic -D -d /usr/share/zoneinfo -p America/New_York -u root -g wheel -m 444 -y /usr/obj/usr/src/share/zoneinfo/yearistype /usr/src/share/zoneinfo/../../contrib/tzdata/africa /usr/src/share/zoneinfo/../../contrib/tzdata/antarctica /usr/src/share/zoneinfo/../../contrib/tzdata/asia /usr/src/share/zoneinfo/../../contrib/tzdata/australasia /usr/src/share/zoneinfo/../../contrib/tzdata/etcetera /usr/src/share/zoneinfo/../../contrib/tzdata/europe /usr/src/share/zoneinfo/../../contrib/tzdata/factory /usr/src/share/zoneinfo/../../contrib/tzdata/northamerica /usr/src/share/zoneinfo/../../contrib/tzdata/southamerica install -o root -g wheel -m 444 /usr/src/share/zoneinfo/../../contrib/tzdata//zone.tab /usr/share/zoneinfo/ Updating /etc/localtime tzsetup: /usr/share/zoneinfo/zone.tab:35: country code `AN' unknown *** Error code 1 Stop in /usr/src/share/zoneinfo. *** Error code 1 Stop in /usr/src/share. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. news# tzsetup tzsetup: /usr/share/zoneinfo/zone.tab:35: country code `AN' unknown From owner-freebsd-current@FreeBSD.ORG Thu May 19 14:44: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 0D4691065673 for ; Thu, 19 May 2011 14:44:02 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-pw0-f54.google.com (mail-pw0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id D20518FC12 for ; Thu, 19 May 2011 14:44:01 +0000 (UTC) Received: by pwj8 with SMTP id 8so1632953pwj.13 for ; Thu, 19 May 2011 07:44:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:references:in-reply-to:mime-version :content-transfer-encoding:content-type:message-id:cc:x-mailer:from :subject:date:to; bh=q6tJNiQ+ITHY34oo2bXOvOkIcoyjdwpDuip59YDLnAk=; b=ZXfFRDlLIEPrGqKOmYMPo46YGDM6EuL2+VvEgd3IqNbWQH3sJK/EOOE5yx6GIuX3C7 ETv9AwNN4NOIH/nkCoPEHisZlWaRGhLbbT4GCynYhSrkbMbY9UsVWy5GaKy7CmEYL0tq /84ilaTDrksqvnoFbukfm5MAT0sHqaYUSn+tA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; b=FXOOjWUiU0fahCmNSocqP/2ucoJ5dUNnf0ybEIH8RCQpZ5cUr4P/HJzutlU7QLsl56 dAop3vRQKdSmS9H39TiaF0XcGOdfQKwwM7Uxwdi0elNolVR5Is4wYv8FO99khiMwMhWT MU2yQPoYtbo09CROnzV5L5z/Zuz7QXFK+vBxU= Received: by 10.68.5.233 with SMTP id v9mr4637429pbv.215.1305816240448; Thu, 19 May 2011 07:44:00 -0700 (PDT) Received: from [192.168.20.56] (c-24-6-49-154.hsd1.ca.comcast.net [24.6.49.154]) by mx.google.com with ESMTPS id i7sm1793280pbs.7.2011.05.19.07.43.57 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 19 May 2011 07:43:58 -0700 (PDT) References: <4DD51B09.1090604@devel.njit.edu> In-Reply-To: <4DD51B09.1090604@devel.njit.edu> Mime-Version: 1.0 (iPhone Mail 8J2) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <96B648CD-F47F-437C-B585-FB5F8DBDDE37@gmail.com> X-Mailer: iPhone Mail (8J2) From: Garrett Cooper Date: Thu, 19 May 2011 07:43:53 -0700 To: Tim Kellers Cc: "freebsd-current@freebsd.org" , Tim Kellers Subject: Re: make install fails when updating /etc/localtime 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, 19 May 2011 14:44:02 -0000 On May 19, 2011, at 6:28 AM, Tim Kellers wrote: > =46rom sources csuped May 18, 2:00 PM EDT. make buildworld completed with= no error. >=20 > uname -a >=20 > FreeBSD news.smsdsite.com 9.0-CURRENT FreeBSD 9.0-CURRENT #0: Tue May 17 1= 4:35:44 EDT 2011 timothyk@news.smsdsite.com:/usr/obj/usr/src/sys/MAY17 a= md64 >=20 >=20 >=20 > =3D=3D=3D> share/zoneinfo (install) > umask 022; cd /usr/src/share/zoneinfo; zic -D -d /usr/share/zoneinfo -p A= merica/New_York -u root -g wheel -m 444 -y /usr/obj/usr/src/share/zoneinf= o/yearistype /usr/src/share/zoneinfo/../../contrib/tzdata/africa /usr/src/sh= are/zoneinfo/../../contrib/tzdata/antarctica /usr/src/share/zoneinfo/../../c= ontrib/tzdata/asia /usr/src/share/zoneinfo/../../contrib/tzdata/australasia /= usr/src/share/zoneinfo/../../contrib/tzdata/etcetera /usr/src/share/zoneinfo= /../../contrib/tzdata/europe /usr/src/share/zoneinfo/../../contrib/tzdata/fa= ctory /usr/src/share/zoneinfo/../../contrib/tzdata/northamerica /usr/src/sha= re/zoneinfo/../../contrib/tzdata/southamerica > install -o root -g wheel -m 444 /usr/src/share/zoneinfo/../../contrib/tzd= ata//zone.tab /usr/share/zoneinfo/ > Updating /etc/localtime > tzsetup: /usr/share/zoneinfo/zone.tab:35: country code `AN' unknown > *** Error code 1 >=20 > Stop in /usr/src/share/zoneinfo. > *** Error code 1 >=20 > Stop in /usr/src/share. > *** Error code 1 >=20 > Stop in /usr/src. > *** Error code 1 >=20 > Stop in /usr/src. > *** Error code 1 >=20 > Stop in /usr/src. > *** Error code 1 >=20 > Stop in /usr/src. > news# tzsetup > tzsetup: /usr/share/zoneinfo/zone.tab:35: country code `AN' unknown Edwin just fixed the iso3166 file so it should work now. Cheers! -Garrett= From owner-freebsd-current@FreeBSD.ORG Thu May 19 16:11: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 A5C1A106566B for ; Thu, 19 May 2011 16:11:53 +0000 (UTC) (envelope-from timothyk@devel.njit.edu) Received: from mail-gw6.njit.edu (mail-gw6.njit.edu [128.235.251.154]) by mx1.freebsd.org (Postfix) with ESMTP id 690B48FC0A for ; Thu, 19 May 2011 16:11:53 +0000 (UTC) Received: from beta.maestro.njit.edu (dhcp114-27.njit.edu [128.235.114.27]) by mail-gw6.njit.edu (8.14.3/8.14.3) with ESMTP id p4JGBa03019507 for ; Thu, 19 May 2011 12:11:41 -0400 (EDT) Message-ID: <4DD5412E.6030308@devel.njit.edu> Date: Thu, 19 May 2011 12:11:26 -0400 From: Tim Kellers User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.17) Gecko/20110506 Thunderbird/3.1.10 MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <4DD51B09.1090604@devel.njit.edu> <96B648CD-F47F-437C-B585-FB5F8DBDDE37@gmail.com> In-Reply-To: <96B648CD-F47F-437C-B585-FB5F8DBDDE37@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: make install fails when updating /etc/localtime 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, 19 May 2011 16:11:53 -0000 On 05/19/11 10:43, Garrett Cooper wrote: > On May 19, 2011, at 6:28 AM, Tim Kellers wrote: > >> From sources csuped May 18, 2:00 PM EDT. make buildworld completed with no error. >> >> uname -a >> >> FreeBSD news.smsdsite.com 9.0-CURRENT FreeBSD 9.0-CURRENT #0: Tue May 17 14:35:44 EDT 2011 timothyk@news.smsdsite.com:/usr/obj/usr/src/sys/MAY17 amd64 >> >> >> >> ===> share/zoneinfo (install) >> umask 022; cd /usr/src/share/zoneinfo; zic -D -d /usr/share/zoneinfo -p America/New_York -u root -g wheel -m 444 -y /usr/obj/usr/src/share/zoneinfo/yearistype /usr/src/share/zoneinfo/../../contrib/tzdata/africa /usr/src/share/zoneinfo/../../contrib/tzdata/antarctica /usr/src/share/zoneinfo/../../contrib/tzdata/asia /usr/src/share/zoneinfo/../../contrib/tzdata/australasia /usr/src/share/zoneinfo/../../contrib/tzdata/etcetera /usr/src/share/zoneinfo/../../contrib/tzdata/europe /usr/src/share/zoneinfo/../../contrib/tzdata/factory /usr/src/share/zoneinfo/../../contrib/tzdata/northamerica /usr/src/share/zoneinfo/../../contrib/tzdata/southamerica >> install -o root -g wheel -m 444 /usr/src/share/zoneinfo/../../contrib/tzdata//zone.tab /usr/share/zoneinfo/ >> Updating /etc/localtime >> tzsetup: /usr/share/zoneinfo/zone.tab:35: country code `AN' unknown >> *** Error code 1 >> >> Stop in /usr/src/share/zoneinfo. >> *** Error code 1 >> >> Stop in /usr/src/share. >> *** Error code 1 >> >> Stop in /usr/src. >> *** Error code 1 >> >> Stop in /usr/src. >> *** Error code 1 >> >> Stop in /usr/src. >> *** Error code 1 >> >> Stop in /usr/src. >> news# tzsetup >> tzsetup: /usr/share/zoneinfo/zone.tab:35: country code `AN' unknown > Edwin just fixed the iso3166 file so it should work now. > Cheers! > -Garrett_______________________________________________ > 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" > Thank you. I csupped again and saw the changes. building world again, now. Tim From owner-freebsd-current@FreeBSD.ORG Thu May 19 16:28:47 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 7C7071065670 for ; Thu, 19 May 2011 16:28:47 +0000 (UTC) (envelope-from deeptech71@gmail.com) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id 39F218FC0A for ; Thu, 19 May 2011 16:28:46 +0000 (UTC) Received: by ywf7 with SMTP id 7so1246307ywf.13 for ; Thu, 19 May 2011 09:28:46 -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:content-type:content-transfer-encoding; bh=WcZlnmiim8l8Rswih6ND9BZ+YUlUFDFAW5j0xOBcYCQ=; b=u0MmyiQCiyEjn53FvkDrFusghq1bOn/en4LTJ8D8myynLr8Rs2XbE3mhSBMTntzgfq WO2mZsSm34b4hG+oegIpiYJw3ULcPRtphHUn9W807JCrAUqm6eURvcEIjr3ADjbPkip8 BEZXJT52dv0kg4z0vUh1Z3H8K87NFBt2DDqr0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=f6HY4Qc5ulvdalCfxEDC3B5xGb8y1GolRyFsKiJ4MnR4L67Eag2hQcNM6UbEMOIADY dMNiE/0Y5xPklce4+NRJVVHOocGuFK/CRFpG2T4p4vGYdHiPVPpOFzhmPQtY67FpJJ0x i+yeSpHyWsPA7rlrR7TNHMKxcD2QkZK+0wOSg= MIME-Version: 1.0 Received: by 10.236.92.116 with SMTP id i80mr3558617yhf.348.1305822526418; Thu, 19 May 2011 09:28:46 -0700 (PDT) Received: by 10.236.107.197 with HTTP; Thu, 19 May 2011 09:28:46 -0700 (PDT) In-Reply-To: <201105190813.37908.jhb@freebsd.org> References: <201105171640.11148.jhb@freebsd.org> <201105190813.37908.jhb@freebsd.org> Date: Thu, 19 May 2011 18:28:46 +0200 Message-ID: From: "deeptech71@gmail.com" To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: pcib allocation failure 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, 19 May 2011 16:28:47 -0000 On Thu, May 19, 2011 at 2:13 PM, John Baldwin wrote: > Yeah, your BIOS continues to behave very poorly. =A0Please try this hack = to see > if it allows your video to still work with any AGP aperture size: > > Index: pci_pci.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- pci_pci.c =A0 (revision 222093) > +++ pci_pci.c =A0 (working copy) > @@ -231,7 +231,9 @@ pcib_alloc_window(struct pcib_softc *sc, struct pc > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0w->name, (uintmax_t)w->base, (uint= max_t)w->limit); > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0w->base =3D max_address; > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0w->limit =3D 0; > +#if 0 > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0pcib_write_windows(sc, w->mask); > +#endif > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0return; > =A0 =A0 =A0 =A0} > =A0 =A0 =A0 =A0pcib_activate_window(sc, type); does not. From owner-freebsd-current@FreeBSD.ORG Thu May 19 16:58: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 164081065670; Thu, 19 May 2011 16:58:04 +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 E5EB78FC15; Thu, 19 May 2011 16:58:02 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id TAA17489; Thu, 19 May 2011 19:58:01 +0300 (EEST) (envelope-from avg@FreeBSD.org) Message-ID: <4DD54C18.8050305@FreeBSD.org> Date: Thu, 19 May 2011 19:58:00 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.17) Gecko/20110504 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Attilio Rao , Garrett Cooper References: <4DD3F662.9040603@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: "freebsd-current@freebsd.org" , "freebsd-arch@freebsd.org" Subject: Re: [rfc] remove hlt_cpus et al sysctls and related code 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, 19 May 2011 16:58:04 -0000 on 18/05/2011 20:04 Attilio Rao said the following: > 2011/5/18 Garrett Cooper : >> We use this internally at work still with a software config that uses 4BSD so >> as long as there is an equivalent tunable, that's good enough for us moving >> forward. Can you please clarify which exactly tunable(s) do you use/need? Just turning hyperthreading on/off or more? (BTW, doing that via BIOS is inconvenient / not feasible?) BTW, I think that if we switch hyperthreading off then we better off not sending Start IPI to the logical CPUs at all. > Tunables are pretty much acceptable for this case. What is really broken is the > on-the-fly ability to mark CPUs active/inactive and subsequent handovers. Yes, I completely agree. Static disabling of CPUs doesn't have any problems, and IMO, currently the best way to do it is with hint.lapic.X.disabled. > I thought Andriy attached a patch to the tree, but it doesn't seem so... > anyway, yes, I think that adding tunables for this is very reasonable and not > as dangerous as the current mechanism. I agree. I haven't sent a patch, because I don't have it yet :) I decided to solicit opinions before getting to hacking code. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Thu May 19 18:20: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 54D94106566C for ; Thu, 19 May 2011 18:20:29 +0000 (UTC) (envelope-from timothyk@devel.njit.edu) Received: from mail-gw5.njit.edu (mail-gw5.njit.edu [128.235.251.153]) by mx1.freebsd.org (Postfix) with ESMTP id 18AA28FC1C for ; Thu, 19 May 2011 18:20:28 +0000 (UTC) Received: from beta.maestro.njit.edu (dhcp114-27.njit.edu [128.235.114.27]) by mail-gw5.njit.edu (8.13.8/8.13.8) with ESMTP id p4JIKSXh020046; Thu, 19 May 2011 14:20:28 -0400 (EDT) Message-ID: <4DD55F6C.7010104@devel.njit.edu> Date: Thu, 19 May 2011 14:20:28 -0400 From: Tim Kellers User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.17) Gecko/20110506 Thunderbird/3.1.10 MIME-Version: 1.0 References: <4DD51B09.1090604@devel.njit.edu> <96B648CD-F47F-437C-B585-FB5F8DBDDE37@gmail.com> In-Reply-To: <96B648CD-F47F-437C-B585-FB5F8DBDDE37@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-current@freebsd.org" , Tim Kellers Subject: Re: make install fails when updating /etc/localtime 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, 19 May 2011 18:20:29 -0000 On 05/19/11 10:43, Garrett Cooper wrote: > On May 19, 2011, at 6:28 AM, Tim Kellers wrote: > >> From sources csuped May 18, 2:00 PM EDT. make buildworld completed with no error. >> >> uname -a >> >> FreeBSD news.smsdsite.com 9.0-CURRENT FreeBSD 9.0-CURRENT #0: Tue May 17 14:35:44 EDT 2011 timothyk@news.smsdsite.com:/usr/obj/usr/src/sys/MAY17 amd64 >> >> >> >> ===> share/zoneinfo (install) >> umask 022; cd /usr/src/share/zoneinfo; zic -D -d /usr/share/zoneinfo -p America/New_York -u root -g wheel -m 444 -y /usr/obj/usr/src/share/zoneinfo/yearistype /usr/src/share/zoneinfo/../../contrib/tzdata/africa /usr/src/share/zoneinfo/../../contrib/tzdata/antarctica /usr/src/share/zoneinfo/../../contrib/tzdata/asia /usr/src/share/zoneinfo/../../contrib/tzdata/australasia /usr/src/share/zoneinfo/../../contrib/tzdata/etcetera /usr/src/share/zoneinfo/../../contrib/tzdata/europe /usr/src/share/zoneinfo/../../contrib/tzdata/factory /usr/src/share/zoneinfo/../../contrib/tzdata/northamerica /usr/src/share/zoneinfo/../../contrib/tzdata/southamerica >> install -o root -g wheel -m 444 /usr/src/share/zoneinfo/../../contrib/tzdata//zone.tab /usr/share/zoneinfo/ >> Updating /etc/localtime >> tzsetup: /usr/share/zoneinfo/zone.tab:35: country code `AN' unknown >> *** Error code 1 >> >> Stop in /usr/src/share/zoneinfo. >> *** Error code 1 >> >> Stop in /usr/src/share. >> *** Error code 1 >> >> Stop in /usr/src. >> *** Error code 1 >> >> Stop in /usr/src. >> *** Error code 1 >> >> Stop in /usr/src. >> *** Error code 1 >> >> Stop in /usr/src. >> news# tzsetup >> tzsetup: /usr/share/zoneinfo/zone.tab:35: country code `AN' unknown > Edwin just fixed the iso3166 file so it should work now. > Cheers! > -Garrett buildworld and installworld completed just fine. Thanks Tim From owner-freebsd-current@FreeBSD.ORG Thu May 19 21:35:55 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 702981065670 for ; Thu, 19 May 2011 21:35:55 +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 0D19B8FC15 for ; Thu, 19 May 2011 21:35:55 +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 B64F046B09; Thu, 19 May 2011 17:35:54 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 54A718A04F; Thu, 19 May 2011 17:35:54 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Date: Thu, 19 May 2011 17:35:53 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110325; KDE/4.5.5; amd64; ; ) References: <201105190813.37908.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201105191735.53889.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Thu, 19 May 2011 17:35:54 -0400 (EDT) Cc: "deeptech71@gmail.com" Subject: Re: pcib allocation failure 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, 19 May 2011 21:35:55 -0000 On Thursday, May 19, 2011 12:28:46 pm deeptech71@gmail.com wrote: > On Thu, May 19, 2011 at 2:13 PM, John Baldwin wrote: > > Yeah, your BIOS continues to behave very poorly. Please try this hack to see > > if it allows your video to still work with any AGP aperture size: > > > > Index: pci_pci.c > > =================================================================== > > --- pci_pci.c (revision 222093) > > +++ pci_pci.c (working copy) > > @@ -231,7 +231,9 @@ pcib_alloc_window(struct pcib_softc *sc, struct pc > > w->name, (uintmax_t)w->base, (uintmax_t)w->limit); > > w->base = max_address; > > w->limit = 0; > > +#if 0 > > pcib_write_windows(sc, w->mask); > > +#endif > > return; > > } > > pcib_activate_window(sc, type); > > does not. Hummm, that should leave the PCI-PCI bridge unchanged until we write the new values in place so it's never "turned off" (only updated to use a smaller range at some point). You could try patching write_windows to disable IO and memory decoding in the PCI command register while the windows are frobbed. Index: pci_pci.c =================================================================== --- pci_pci.c (revision 222093) +++ pci_pci.c (working copy) @@ -162,8 +162,13 @@ pcib_write_windows(struct pcib_softc *sc, int mask { device_t dev; uint32_t val; + uint16_t cmd; dev = sc->dev; + cmd = pci_read_config(dev, PCIR_COMMAND, 2); + if (cmd & (PCIM_CMD_PORTEN | PCIM_CMD_MEMEN)) + pci_write_config(dev, PCIR_COMMAND, + cmd & ~(PCIM_CMD_PORTEN | PCIM_CMD_MEMEN), 2); if (sc->io.valid && mask & WIN_IO) { val = pci_read_config(dev, PCIR_IOBASEL_1, 1); if ((val & PCIM_BRIO_MASK) == PCIM_BRIO_32) { @@ -192,6 +197,8 @@ pcib_write_windows(struct pcib_softc *sc, int mask pci_write_config(dev, PCIR_PMBASEL_1, sc->pmem.base >> 16, 2); pci_write_config(dev, PCIR_PMLIMITL_1, sc->pmem.limit >> 16, 2); } + if (cmd & (PCIM_CMD_PORTEN | PCIM_CMD_MEMEN)) + pci_write_config(dev, PCIR_COMMAND, cmd, 2); } static void @@ -231,7 +238,9 @@ pcib_alloc_window(struct pcib_softc *sc, struct pc w->name, (uintmax_t)w->base, (uintmax_t)w->limit); w->base = max_address; w->limit = 0; +#if 0 pcib_write_windows(sc, w->mask); +#endif return; } pcib_activate_window(sc, type); -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Sat May 21 06:46:21 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 688A7106566B; Sat, 21 May 2011 06:46:21 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 22F5E8FC14; Sat, 21 May 2011 06:46:20 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.4) with ESMTP id p4L6kJtR067333; Sat, 21 May 2011 02:46:20 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.4/Submit) id p4L6kJFH067321; Sat, 21 May 2011 06:46:19 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 21 May 2011 06:46:19 GMT Message-Id: <201105210646.p4L6kJFH067321@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on arm/arm X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 May 2011 06:46:21 -0000 TB --- 2011-05-21 06:10:01 - tinderbox 2.7 running on freebsd-current.sentex.ca TB --- 2011-05-21 06:10:01 - starting HEAD tinderbox run for arm/arm TB --- 2011-05-21 06:10:01 - cleaning the object tree TB --- 2011-05-21 06:10:18 - cvsupping the source tree TB --- 2011-05-21 06:10:18 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/arm/arm/supfile TB --- 2011-05-21 06:11:35 - building world TB --- 2011-05-21 06:11:35 - MAKEOBJDIRPREFIX=/obj TB --- 2011-05-21 06:11:35 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-05-21 06:11:35 - TARGET=arm TB --- 2011-05-21 06:11:35 - TARGET_ARCH=arm TB --- 2011-05-21 06:11:35 - TZ=UTC TB --- 2011-05-21 06:11:35 - __MAKE_CONF=/dev/null TB --- 2011-05-21 06:11:35 - cd /src TB --- 2011-05-21 06:11:35 - /usr/bin/make -B buildworld >>> World build started on Sat May 21 06:11:35 UTC 2011 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] cc -O -pipe -DBFD_DEFAULT_TARGET_SIZE=32 -I. -I/src/gnu/usr.bin/binutils/ld -I/src/gnu/usr.bin/binutils/ld/../libbfd -I/obj/arm.arm/src/gnu/usr.bin/binutils/ld/../libbfd -I/src/gnu/usr.bin/binutils/ld/../../../../contrib/binutils/include -DTARGET=\"arm-unknown-freebsd\" -DDEFAULT_EMULATION=\"armelf_fbsd\" -DSCRIPTDIR=\"/usr/libdata\" -DBFD_VERSION_STRING=\""2.17.50 [FreeBSD] 2007-07-03"\" -DBINDIR=\"/usr/bin\" -DTARGET_SYSTEM_ROOT=\"\" -DTOOLBINDIR=\"//usr/bin/libexec\" -D_GNU_SOURCE -I/src/gnu/usr.bin/binutils/ld/../../../../contrib/binutils/ld -I/src/gnu/usr.bin/binutils/ld/../../../../contrib/binutils/bfd -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c /src/gnu/usr.bin/binutils/ld/../../../../contrib/binutils/ld/ldlang.c cc -O -pipe -DBFD_DEFAULT_TARGET_SIZE=32 -I. -I/src/gnu/usr.bin/binutils/ld -I/src/gnu/usr.bin/binutils/ld/../libbfd -I/obj/arm.arm/src/gnu/usr.bin/binutils/ld/../libbfd -I/src/gnu/usr.bin/binutils/ld/../../../../contrib/binutils/include -DTARGET=\"arm-unknown-freebsd\" -DDEFAULT_EMULATION=\"armelf_fbsd\" -DSCRIPTDIR=\"/usr/libdata\" -DBFD_VERSION_STRING=\""2.17.50 [FreeBSD] 2007-07-03"\" -DBINDIR=\"/usr/bin\" -DTARGET_SYSTEM_ROOT=\"\" -DTOOLBINDIR=\"//usr/bin/libexec\" -D_GNU_SOURCE -I/src/gnu/usr.bin/binutils/ld/../../../../contrib/binutils/ld -I/src/gnu/usr.bin/binutils/ld/../../../../contrib/binutils/bfd -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c ldlex.c cc -O -pipe -DBFD_DEFAULT_TARGET_SIZE=32 -I. -I/src/gnu/usr.bin/binutils/ld -I/src/gnu/usr.bin/binutils/ld/../libbfd -I/obj/arm.arm/src/gnu/usr.bin/binutils/ld/../libbfd -I/src/gnu/usr.bin/binutils/ld/../../../../contrib/binutils/include -DTARGET=\"arm-unknown-freebsd\" -DDEFAULT_EMULATION=\"armelf_fbsd\" -DSCRIPTDIR=\"/usr/libdata\" -DBFD_VERSION_STRING=\""2.17.50 [FreeBSD] 2007-07-03"\" -DBINDIR=\"/usr/bin\" -DTARGET_SYSTEM_ROOT=\"\" -DTOOLBINDIR=\"//usr/bin/libexec\" -D_GNU_SOURCE -I/src/gnu/usr.bin/binutils/ld/../../../../contrib/binutils/ld -I/src/gnu/usr.bin/binutils/ld/../../../../contrib/binutils/bfd -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c /src/gnu/usr.bin/binutils/ld/../../../../contrib/binutils/ld/ldmain.c /src/gnu/usr.bin/binutils/ld/../../../../contrib/binutils/ld/ldmain.c: In function 'main': /src/gnu/usr.bin/binutils/ld/../../../../contrib/binutils/ld/ldmain.c:185: internal compiler error: in var_ann, at tree-flow-inline.h:128 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. *** Error code 1 Stop in /src/gnu/usr.bin/binutils/ld. *** Error code 1 Stop in /src/gnu/usr.bin/binutils. *** Error code 1 Stop in /src/gnu/usr.bin. *** Error code 1 Stop in /src/gnu. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-05-21 06:46:19 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-05-21 06:46:19 - ERROR: failed to build world TB --- 2011-05-21 06:46:19 - 1449.23 user 480.12 system 2178.75 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-arm-arm.full From owner-freebsd-current@FreeBSD.ORG Sat May 21 13:59: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 A7A0F1065672 for ; Sat, 21 May 2011 13:59:57 +0000 (UTC) (envelope-from deeptech71@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 633BE8FC12 for ; Sat, 21 May 2011 13:59:57 +0000 (UTC) Received: by yie12 with SMTP id 12so2071923yie.13 for ; Sat, 21 May 2011 06:59:56 -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:content-type:content-transfer-encoding; bh=V1eLzZpaCQhc4MljoKRUrlGYSagfiZte57sy/ovEOoU=; b=KNr0CZBR1KK33HFvy1Gkjq0O4ulifpHsdYSFIPhftKVL3mLLnJMt1MZ0e3IvFkL6aO LRn5RL0HpcgIGysXZ4EWrE8Yp6rw5/SH6qRsUIkJu4yTEkgGBvBuOhqiJiYdoCOvRgMV SeHpoRI4panBRXFudNaD4GhXn2n9FBk2hiBTU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=fI3Zpu0wZBcPchVPDYaA2WivBFfsQod93VliIbVyXVJ3RMdSAX+GmOdhVYNDcMMbxy aTiJIBlODF+Zgpg0KgXqr/8l2hP8GlHkJIRuJD+W3hhKk2z5PtAmHWVKfWaRe3u9BCbx DzpOxGOXPNbr8imNg8fx1hGcUAKEs+hLnUJLE= MIME-Version: 1.0 Received: by 10.236.153.130 with SMTP id f2mr696667yhk.281.1305986396592; Sat, 21 May 2011 06:59:56 -0700 (PDT) Received: by 10.236.107.197 with HTTP; Sat, 21 May 2011 06:59:56 -0700 (PDT) In-Reply-To: <201105191735.53889.jhb@freebsd.org> References: <201105190813.37908.jhb@freebsd.org> <201105191735.53889.jhb@freebsd.org> Date: Sat, 21 May 2011 15:59:56 +0200 Message-ID: From: "deeptech71@gmail.com" To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: pcib allocation failure 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, 21 May 2011 13:59:57 -0000 On Thu, May 19, 2011 at 11:35 PM, John Baldwin wrote: > On Thursday, May 19, 2011 12:28:46 pm deeptech71@gmail.com wrote: >> On Thu, May 19, 2011 at 2:13 PM, John Baldwin wrote: >> > Yeah, your BIOS continues to behave very poorly. =A0Please try this ha= ck to > see >> > if it allows your video to still work with any AGP aperture size: >> > >> > Index: pci_pci.c >> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> > --- pci_pci.c =A0 (revision 222093) >> > +++ pci_pci.c =A0 (working copy) >> > @@ -231,7 +231,9 @@ pcib_alloc_window(struct pcib_softc *sc, struct pc >> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0w->name, (uintmax_t)w->base, (u= intmax_t)w->limit); >> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0w->base =3D max_address; >> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0w->limit =3D 0; >> > +#if 0 >> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0pcib_write_windows(sc, w->mask); >> > +#endif >> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0return; >> > =A0 =A0 =A0 =A0} >> > =A0 =A0 =A0 =A0pcib_activate_window(sc, type); >> >> does not. > > Hummm, that should leave the PCI-PCI bridge unchanged until we write the = new > values in place so it's never "turned off" (only updated to use a smaller > range at some point). =A0You could try patching write_windows to disable = IO and > memory decoding in the PCI command register while the windows are frobbed= . > > Index: pci_pci.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- pci_pci.c =A0 (revision 222093) > +++ pci_pci.c =A0 (working copy) > @@ -162,8 +162,13 @@ pcib_write_windows(struct pcib_softc *sc, int mask > =A0{ > =A0 =A0 =A0 =A0device_t dev; > =A0 =A0 =A0 =A0uint32_t val; > + =A0 =A0 =A0 uint16_t cmd; > > =A0 =A0 =A0 =A0dev =3D sc->dev; > + =A0 =A0 =A0 cmd =3D pci_read_config(dev, PCIR_COMMAND, 2); > + =A0 =A0 =A0 if (cmd & (PCIM_CMD_PORTEN | PCIM_CMD_MEMEN)) > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 pci_write_config(dev, PCIR_COMMAND, > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 cmd & ~(PCIM_CMD_PORTEN | PCIM_CMD_= MEMEN), 2); > =A0 =A0 =A0 =A0if (sc->io.valid && mask & WIN_IO) { > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0val =3D pci_read_config(dev, PCIR_IOBASEL_= 1, 1); > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if ((val & PCIM_BRIO_MASK) =3D=3D PCIM_BRI= O_32) { > @@ -192,6 +197,8 @@ pcib_write_windows(struct pcib_softc *sc, int mask > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0pci_write_config(dev, PCIR_PMBASEL_1, sc->= pmem.base >> 16, 2); > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0pci_write_config(dev, PCIR_PMLIMITL_1, sc-= >pmem.limit >> 16, 2); > =A0 =A0 =A0 =A0} > + =A0 =A0 =A0 if (cmd & (PCIM_CMD_PORTEN | PCIM_CMD_MEMEN)) > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 pci_write_config(dev, PCIR_COMMAND, cmd, 2)= ; > =A0} > > =A0static void > @@ -231,7 +238,9 @@ pcib_alloc_window(struct pcib_softc *sc, struct pc > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0w->name, (uintmax_t)w->base, (uint= max_t)w->limit); > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0w->base =3D max_address; > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0w->limit =3D 0; > +#if 0 > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0pcib_write_windows(sc, w->mask); > +#endif > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0return; > =A0 =A0 =A0 =A0} > =A0 =A0 =A0 =A0pcib_activate_window(sc, type); that seems to work. From owner-freebsd-current@FreeBSD.ORG Sat May 21 16:26:23 2011 Return-Path: Delivered-To: current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6E490106566B for ; Sat, 21 May 2011 16:26:23 +0000 (UTC) (envelope-from pawel@dawidek.net) Received: from mail.garage.freebsd.pl (60.wheelsystems.com [83.12.187.60]) by mx1.freebsd.org (Postfix) with ESMTP id 1B9488FC12 for ; Sat, 21 May 2011 16:26:22 +0000 (UTC) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 7F67F45EA4; Sat, 21 May 2011 17:58:25 +0200 (CEST) Received: from localhost (89-73-195-149.dynamic.chello.pl [89.73.195.149]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 5CAC345E5C; Sat, 21 May 2011 17:58:19 +0200 (CEST) Date: Sat, 21 May 2011 17:57:55 +0200 From: Pawel Jakub Dawidek To: Maxim Sobolev Message-ID: <20110521155755.GC3326@garage.freebsd.pl> References: <4DD2CEE7.1070805@sippysoft.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="p2kqVDKq5asng8Dg" Content-Disposition: inline In-Reply-To: <4DD2CEE7.1070805@sippysoft.com> X-OS: FreeBSD 9.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-0.6 required=4.5 tests=BAYES_00,RCVD_IN_SORBS_DUL autolearn=no version=3.0.4 Cc: "current@freebsd.org" Subject: Re: Randomization in hastd(8) synchronization thread 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, 21 May 2011 16:26:23 -0000 --p2kqVDKq5asng8Dg Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, May 17, 2011 at 12:39:19PM -0700, Maxim Sobolev wrote: > Hi Pawel, >=20 > I am trying to use hastd(8) over slow links and one problem is > apparent right now - current approach with synchronizing content > sequentially is not working in this case. What happens is that hastd > hits the first frequently updated block and cannot make any progress > anymore. In my case I have 30GB of dirty space to be synchronized > over just 1mbps uplink. >=20 > The quick fix that I've applied is randomization in the block > selection code. This way eventually all least used blocks will be > synchronized, leaving only hot ones dirty. More effective approach > would be to use some kind of LRU selection algorithm, but > statistical approach would work just as good in this case. >=20 > Please review the patch below: >=20 > http://sobomax.sippysoft.com/activemap.c.diff Hmm, hastd keeps separate bitmap for synchronization. It is stored in am_syncmap field. Blocks that are dirtied during regular writes should not effect on synchronization bitmap and synchronization progress. --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://yomoli.com --p2kqVDKq5asng8Dg Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAk3X4QMACgkQForvXbEpPzREzQCfc7d0K2hj9txaPeZs1XpRdAQH UioAoNJx0Oee2AZL37etZ+LD4ukNPAS5 =4ZL3 -----END PGP SIGNATURE----- --p2kqVDKq5asng8Dg--