From owner-freebsd-current@FreeBSD.ORG Sun Feb 17 01:04:24 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id A8FC7466 for ; Sun, 17 Feb 2013 01:04:24 +0000 (UTC) (envelope-from erichsfreebsdlist@alogt.com) Received: from alogt.com (alogt.com [69.36.191.58]) by mx1.freebsd.org (Postfix) with ESMTP id 37E04273 for ; Sun, 17 Feb 2013 01:04:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=alogt.com; s=default; h=Content-Transfer-Encoding:Content-Type:Mime-Version:References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date; bh=V4esnXTLhA4/+nnqEH++auR9VZisvB7MmfzBPeIXsxc=; b=MOFUoSFGqKZkTfCjpgl/UPloUdmXwX94t9hL429pRfQv+KLLMlqxTzjMiQUpok/e1b/V0Ad6Z7pqMZA0f8AkF3myTkRMoE8kHguySfyEV9XyNBSqLXdcX91mxByB3WRO; Received: from [122.129.203.50] (port=27715 helo=X220.ovitrap.com) by sl-508-2.slc.westdc.net with esmtpsa (SSLv3:DHE-RSA-AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1U6sfw-004BUy-4E; Sat, 16 Feb 2013 18:04:16 -0700 Date: Sun, 17 Feb 2013 08:04:12 +0700 From: Erich Dollansky To: Warren Block Subject: Re: gpart, slice starts at 0 Message-ID: <20130217080412.205899fd@X220.ovitrap.com> In-Reply-To: References: <20130216145122.3db70652@X220.ovitrap.com> X-Mailer: Claws Mail 3.9.0 (GTK+ 2.24.6; amd64-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - sl-508-2.slc.westdc.net X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - alogt.com X-Get-Message-Sender-Via: sl-508-2.slc.westdc.net: authenticated_id: erichsfreebsdlist@alogt.com X-Source: X-Source-Args: X-Source-Dir: Cc: current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 17 Feb 2013 01:04:24 -0000 Hi, On Sat, 16 Feb 2013 08:44:50 -0700 (MST) Warren Block wrote: > On Sat, 16 Feb 2013, Erich Dollansky wrote: > > > I did this to get a disk partitioned: > > > > #!/bin/tcsh > > Gah! > it is a generated script. > > gpart destroy -F da0 > > diskinfo da0 > > dd if=/dev/zero of=/dev/da0 bs=512 count=34 > > dd if=/dev/zero of=/dev/da0 bs=512 count=34 seek=312581774 > > Someone here on the lists (I unfortunately forget who) showed a > sneaky easier way to do this: > > gpart destroy -F da0 > gpart create -s gpt da0 > gpart destroy -F da0 > This did not make a difference. > > gpart show -p da0 > > gpart create -s MBR da0 > > gpart add -t freebsd da0 > > gpart show -p da0 > > gpart show -p da0s1 > > gpart set -a active -i 1 da0 > > # > > # The following line always gives an error: > > # > > # gpart create -s BSD da0s1 > > 'destroy' is not recursive. It destroys the geom found on the device > given, but does not write to any geoms inside those geoms. > This is obvious. What surprises me is that create does not write a new and empty description to the disk. > MBR/bsdlabel puts FreeBSD partitions inside MBR slices. > > So da0 has been erased, but the bsdlabel blocks for da0s1 are still > present. If you recreate da0, da0s1 will magically reappear. > This is what I struggeled with all the time. > Destroy the FreeBSD disklabel stuff in the slices first: > gpart destroy -F da0s1 And this was the solution. Thanks! > > Or instead, use GPT partitioning to avoid dealing with the problem of > one type of partitions inside a different type of partitions. GPT > makes disk partitioning a lot easier. I am bit tired of having to read handbooks/manuals whenever I get a new device. Out of this, I am currently writing a small program which allows me easy 'formatting' of the device. MBR is just one option the program has. I will publish it when it is really working as I want it to. It will take some time as I do this on the side only. > > The second part of your question, about da0 starting a block zero: > > > [X220]...Appl/Some Tools (root) > gpart show da0 > > => 63 312581745 da0 MBR (149G) > > 63 312581745 1 freebsd [active] (149G) > > > > [X220]...Appl/Some Tools (root) > gpart show da0s1 > > => 0 312581745 da0s1 BSD (149G) > > 0 312581745 - free - (149G) > > That shows slice one starts at block 63, standard for MBR. The space > inside the slice (da0s1) starts at block 0 *of the slice*. This is a bit confusing for me but it does not really matter as long as the programs get it straight. Erich > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to > "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Sun Feb 17 01:58:17 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id ABBD39EA for ; Sun, 17 Feb 2013 01:58:17 +0000 (UTC) (envelope-from hiren.panchasara@gmail.com) Received: from mail-ee0-f51.google.com (mail-ee0-f51.google.com [74.125.83.51]) by mx1.freebsd.org (Postfix) with ESMTP id 27B2634E for ; Sun, 17 Feb 2013 01:58:16 +0000 (UTC) Received: by mail-ee0-f51.google.com with SMTP id d17so2352988eek.10 for ; Sat, 16 Feb 2013 17:58:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=c6FQE4lUA9/sYmRC9GmaXkAJoX/RQq5bSshoe+7nm7E=; b=zgWms6XS1SMaSmqm7BE+qSzly4eJOcf/or79CQ+crfxePQqLxgbhrCvqBuijpytuX/ TPZbtVKEuomS0dlkbOVqhdAI1PjgzRZyttT8tb6GrcElgfYCtMVerQyYxn4nVnSaY6SY VV0yf9oGLyshbv2vTc7IlI9xX/nHxS8t6Xl1zoxgDnkXW8Qt3kruAewN8s8in8v4bReY rNsWDroah89E1dMho0JW9BQDM0lbzcW1fjzFpBSmWP3BCsYYVUOpPDQiCQvdrhHEJnl+ J4/QU7GDVd0UrDy1JSCpTH9MnMxBihfy418A4W0oQvLDVw09mAympEg+qhFsuxq454sT dziA== MIME-Version: 1.0 X-Received: by 10.14.223.69 with SMTP id u45mr26867509eep.23.1361066295727; Sat, 16 Feb 2013 17:58:15 -0800 (PST) Received: by 10.14.133.204 with HTTP; Sat, 16 Feb 2013 17:58:15 -0800 (PST) Date: Sat, 16 Feb 2013 17:58:15 -0800 Message-ID: Subject: Running out of bits p_flag (sys/sys/proc.h) From: hiren panchasara To: freebsd-current Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 17 Feb 2013 01:58:17 -0000 With revision=246484, it seems we have hit the limit. At $WORK we have one more flag and to accommodate that we need to bump this up. Can p_flag be bumped up to u_long? Index: proc.h =================================================================== --- proc.h (revision 245937) +++ proc.h (working copy) @@ -497,7 +497,7 @@ * The following don't make too much sense. * See the td_ or ke_ versions of the same flags. */ - int p_flag; /* (c) P_* flags. */ + u_long p_flag; /* (c) P_* flags. */ enum { PRS_NEW = 0, /* In creation */ PRS_NORMAL, /* threads can be run. */ Thanks, Hiren From owner-freebsd-current@FreeBSD.ORG Sun Feb 17 02:42:08 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id B668437F; Sun, 17 Feb 2013 02:42:08 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id C157A662; Sun, 17 Feb 2013 02:42:07 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id A262B7300A; Sun, 17 Feb 2013 03:42:20 +0100 (CET) Date: Sun, 17 Feb 2013 03:42:20 +0100 From: Luigi Rizzo To: Alfred Perlstein Subject: Re: [RFC/RFT] calloutng Message-ID: <20130217024220.GA81224@onelab2.iet.unipi.it> References: <50D03173.9080904@FreeBSD.org> <20121225232126.GA47692@alchemy.franken.de> <50DB4EFE.2020600@FreeBSD.org> <20130106152313.GD26039@alchemy.franken.de> <50EBF921.2000304@FreeBSD.org> <20130113180940.GM26039@alchemy.franken.de> <50F30CAB.3000001@FreeBSD.org> <20130121095457.GL85306@alchemy.franken.de> <511DEA46.5010509@mu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <511DEA46.5010509@mu.org> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Davide Italiano , Alexander Motin , Marius Strobl , Poul-Henning Kamp , FreeBSD Current , freebsd-arch@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 17 Feb 2013 02:42:08 -0000 On Thu, Feb 14, 2013 at 11:56:54PM -0800, Alfred Perlstein wrote: > [ added Luigi Rizzo to thread ] > > > On 2/11/13 12:26 PM, Davide Italiano wrote: > > [trimmed old mails] > > > > Here's a new version of the patch: > > http://people.freebsd.org/~davide/patches/calloutng-11022012.diff > > > > Significant bits changed (after wider discussion and suggestion by phk@): > > - Introduction of the new sbintime_t type (32.32 fixed point) with the > > respective conversion (sbintime2bintime, sbintime2timeval etc...) > > - switch from 64.64 (struct bintime) format to measure time to sbintime_t > > - Use sbintime_t to represent expected sleep time instead of measuring > > it in microseconds (cpu_idle_acpi(), cpu_idle_spin() ...). > > > Luigi and I discussed this at BAFUG tonight and he expressed an interest > in shepherding the code in at this point. > > Luigi, can you reiterate any points that still remain before we > integrate this code? I am mostly ok with the patch in the current state. I have few comments/suggestions below but they are mostly on documenting/style/trivial bugfixes. So now I would really like to see this code go in HEAD, to give people a chance to see how it works and possibly figure out whether the new API needs modifications. To recall, my major concerns were the following: - API explosion, with multiple versions of the callout routines. This seems to be solved now, with only one version (the *_sbt() functions) and macros remapping the old functions to the new ones. - the use of struct bintime for timeouts and precision. This is also solved thanks to the introduction of sbintime_t values (fixed-point 32.32 times) - Some measurements also indicated that the default "precision" could give large (absolute) errors on the timeouts, especially with large timeouts. I am not sure what is the situation with this new version, but i believe this a relatively minor issue because it surely simple to customize, e.g. having a couple of sysctl setting the default precision (percentage) and maximum error (absolute time). So users could e.g. set a 5% precision and a maximum error of 100us on a desktop, and 10% and 10ms on a laptop. - Another thing that we should do (but after the patch is in) is to see if any existing code is converting times to ticks just to call the timeout routines -- right now the macros convert back to times, clearly it would be best to avoid the double conversion. comments inline below, search for XXX-lr thanks again for your work on this, and for following up with changes after the previous discussion cheers luigi Index: sys/dev/acpica/acpi_cpu.c =================================================================== --- sys/dev/acpica/acpi_cpu.c (.../head) (revision 246685) +++ sys/dev/acpica/acpi_cpu.c (.../projects/calloutng) (revision 246685) @@ -980,13 +980,16 @@ } /* Find the lowest state that has small enough latency. */ + us = sc->cpu_prev_sleep; + if (sbt >= 0 && us > sbt / SBT_1US) XXX-lr can we have us2sbt() , ms2sbt() and the like ? + us = sbt / SBT_1US; cx_next_idx = 0; if (cpu_disable_deep_sleep) i = min(sc->cpu_cx_lowest, sc->cpu_non_c3); else i = sc->cpu_cx_lowest; for (; i >= 0; i--) { - if (sc->cpu_cx_states[i].trans_lat * 3 <= sc->cpu_prev_sleep) { + if (sc->cpu_cx_states[i].trans_lat * 3 <= us) { cx_next_idx = i; break; } Index: sys/kern/kern_synch.c =================================================================== --- sys/kern/kern_synch.c (.../head) (revision 246685) +++ sys/kern/kern_synch.c (.../projects/calloutng) (revision 246685) @@ -146,12 +146,12 @@ */ int _sleep(void *ident, struct lock_object *lock, int priority, - const char *wmesg, int timo) + const char *wmesg, sbintime_t sbt, sbintime_t pr, int flags) { struct thread *td; struct proc *p; struct lock_class *class; - int catch, flags, lock_state, pri, rval; + int catch, sleepq_flags, lock_state, pri, rval; XXX-lr keep flags, use _sleep_flags as function argument ? WITNESS_SAVE_DECL(lock_witness); td = curthread; @@ -348,28 +349,30 @@ * to a "timo" value of one. */ int -pause(const char *wmesg, int timo) +pause_sbt(const char *wmesg, sbintime_t sbt, sbintime_t pr, int flags) { - KASSERT(timo >= 0, ("pause: timo must be >= 0")); + int sbt_sec; XXX-lr localize to the cold block + sbt_sec = sbintime_getsec(sbt); + KASSERT(sbt_sec >= 0, ("pause: timo must be >= 0")); + /* silently convert invalid timeouts */ - if (timo < 1) - timo = 1; + if (sbt == 0) + sbt = tick_sbt; if (cold) { /* - * We delay one HZ at a time to avoid overflowing the + * We delay one second at a time to avoid overflowing the * system specific DELAY() function(s): */ - while (timo >= hz) { + while (sbt_sec > 0) { DELAY(1000000); - timo -= hz; + sbt_sec--; } - if (timo > 0) - DELAY(timo * tick); + DELAY((sbt & 0xffffffff) / SBT_1US); XXX-lr sbt2us() ? return (0); } - return (tsleep(&pause_wchan, 0, wmesg, timo)); + return (_sleep(&pause_wchan, NULL, 0, wmesg, sbt, pr, flags)); } /* @@ -560,8 +563,9 @@ * random variation to avoid synchronisation with processes that * run at regular intervals. */ - callout_reset(&loadav_callout, hz * 4 + (int)(random() % (hz * 2 + 1)), - loadav, NULL); + callout_reset_sbt(&loadav_callout, XXX-lr we have better resolution than HZ here ? + tick_sbt * (hz * 4 + (int)(random() % (hz * 2 + 1))), 0, + loadav, NULL, C_DIRECT_EXEC | C_HARDCLOCK); } /* ARGSUSED */ Index: sys/kern/sys_generic.c =================================================================== --- sys/kern/sys_generic.c (.../head) (revision 246685) +++ sys/kern/sys_generic.c (.../projects/calloutng) (revision 246685) @@ -995,35 +996,29 @@ if (nbufbytes != 0) bzero(selbits, nbufbytes / 2); + precision = 0; if (tvp != NULL) { - atv = *tvp; - if (itimerfix(&atv)) { + rtv = *tvp; + if (rtv.tv_sec < 0 || rtv.tv_usec < 0 || XXX-lr itimerfix or some check routine ? several places + rtv.tv_usec >= 1000000) { error = EINVAL; goto done; } - getmicrouptime(&rtv); - timevaladd(&atv, &rtv); - } else { - atv.tv_sec = 0; - atv.tv_usec = 0; - } - timo = 0; + rsbt = timeval2sbintime(rtv); + precision = rsbt; + precision >>= tc_precexp; + if (TIMESEL(&asbt, rsbt)) + asbt += tc_tick_sbt; + asbt += rsbt; + } else + asbt = -1; seltdinit(td); /* Iterate until the timeout expires or descriptors become ready. */ for (;;) { error = selscan(td, ibits, obits, nd); if (error || td->td_retval[0] != 0) break; - if (atv.tv_sec || atv.tv_usec) { - getmicrouptime(&rtv); - if (timevalcmp(&rtv, &atv, >=)) - break; - ttv = atv; - timevalsub(&ttv, &rtv); - timo = ttv.tv_sec > 24 * 60 * 60 ? - 24 * 60 * 60 * hz : tvtohz(&ttv); - } - error = seltdwait(td, timo); + error = seltdwait(td, asbt, precision); if (error) break; error = selrescan(td, ibits, obits); Index: sys/kern/kern_tc.c =================================================================== --- sys/kern/kern_tc.c (.../head) (revision 246685) +++ sys/kern/kern_tc.c (.../projects/calloutng) (revision 246685) @@ -119,6 +120,21 @@ SYSCTL_INT(_kern_timecounter, OID_AUTO, stepwarnings, CTLFLAG_RW, ×tepwarnings, 0, "Log time steps"); +struct bintime bt_timethreshold; XXX-lr document these variables +struct bintime bt_tickthreshold; +sbintime_t sbt_timethreshold; +sbintime_t sbt_tickthreshold; +struct bintime tc_tick_bt; +sbintime_t tc_tick_sbt; +int tc_precexp; +int tc_timepercentage = TC_DEFAULTPERC; +TUNABLE_INT("kern.timecounter.alloweddeviation", &tc_timepercentage); +static int sysctl_kern_timecounter_adjprecision(SYSCTL_HANDLER_ARGS); +SYSCTL_PROC(_kern_timecounter, OID_AUTO, alloweddeviation, + CTLTYPE_INT | CTLFLAG_RW | CTLFLAG_MPSAFE, 0, 0, + sysctl_kern_timecounter_adjprecision, "I", + "Allowed time interval deviation in percents"); + static void tc_windup(void); static void cpu_tick_calibrate(int); @@ -883,6 +919,16 @@ } void +sbinuptime(sbintime_t sbt) XXX-lr wrong argument ? not compile-tested ? Index: sys/kern/kern_timeout.c =================================================================== --- sys/kern/kern_timeout.c (.../head) (revision 246685) +++ sys/kern/kern_timeout.c (.../projects/calloutng) (revision 246685) @@ -87,58 +105,62 @@ int callwheelsize, callwheelmask; /* - * The callout cpu migration entity represents informations necessary for - * describing the migrating callout to the new callout cpu. + * The callout cpu exec entities represent informations necessary for + * describing the state of callouts currently running on the CPU and the ones + * necessary for migrating callouts to the new callout cpu. In particular, + * the first entry of the array cc_exec_entity holds informations for callout + * running in SWI thread context, while the second one holds informations + * for callout running directly from hardware interrupt context. * The cached informations are very important for deferring migration when * the migrating callout is already running. */ -struct cc_mig_ent { +struct cc_exec { + struct callout *cc_next; + struct callout *cc_curr; #ifdef SMP - void (*ce_migration_func)(void *); - void *ce_migration_arg; - int ce_migration_cpu; - int ce_migration_ticks; + void (*ce_migration_func)(void *); + void *ce_migration_arg; + int ce_migration_cpu; + sbintime_t ce_migration_time; #endif + int cc_cancel; + int cc_waiting; }; - + /* - * There is one struct callout_cpu per cpu, holding all relevant + * There is one struct callou_cpu per cpu, holding all relevant * state for the callout processing thread on the individual CPU. - * In particular: - * cc_ticks is incremented once per tick in callout_cpu(). - * It tracks the global 'ticks' but in a way that the individual - * threads should not worry about races in the order in which - * hardclock() and hardclock_cpu() run on the various CPUs. - * cc_softclock is advanced in callout_cpu() to point to the - * first entry in cc_callwheel that may need handling. In turn, - * a softclock() is scheduled so it can serve the various entries i - * such that cc_softclock <= i <= cc_ticks . - * XXX maybe cc_softclock and cc_ticks should be volatile ? - * - * cc_ticks is also used in callout_reset_cpu() to determine - * when the callout should be served. */ struct callout_cpu { struct mtx_padalign cc_lock; - struct cc_mig_ent cc_migrating_entity; + struct cc_exec cc_exec_entity[2]; XXX-lr repeat (short) explanation on why 2 entities struct callout *cc_callout; struct callout_tailq *cc_callwheel; + struct callout_tailq cc_expireq; struct callout_list cc_callfree; - struct callout *cc_next; - struct callout *cc_curr; + sbintime_t cc_firstevent; + sbintime_t cc_lastscan; void *cc_cookie; - int cc_ticks; - int cc_softticks; - int cc_cancel; - int cc_waiting; - int cc_firsttick; }; +#define cc_exec_curr cc_exec_entity[0].cc_curr +#define cc_exec_next cc_exec_entity[0].cc_next +#define cc_exec_cancel cc_exec_entity[0].cc_cancel +#define cc_exec_waiting cc_exec_entity[0].cc_waiting +#define cc_exec_curr_dir cc_exec_entity[1].cc_curr +#define cc_exec_next_dir cc_exec_entity[1].cc_next +#define cc_exec_cancel_dir cc_exec_entity[1].cc_cancel +#define cc_exec_waiting_dir cc_exec_entity[1].cc_waiting + #ifdef SMP -#define cc_migration_func cc_migrating_entity.ce_migration_func -#define cc_migration_arg cc_migrating_entity.ce_migration_arg -#define cc_migration_cpu cc_migrating_entity.ce_migration_cpu -#define cc_migration_ticks cc_migrating_entity.ce_migration_ticks +#define cc_migration_func cc_exec_entity[0].ce_migration_func +#define cc_migration_arg cc_exec_entity[0].ce_migration_arg +#define cc_migration_cpu cc_exec_entity[0].ce_migration_cpu +#define cc_migration_time cc_exec_entity[0].ce_migration_time +#define cc_migration_func_dir cc_exec_entity[1].ce_migration_func +#define cc_migration_arg_dir cc_exec_entity[1].ce_migration_arg +#define cc_migration_cpu_dir cc_exec_entity[1].ce_migration_cpu +#define cc_migration_time_dir cc_exec_entity[1].ce_migration_time struct callout_cpu cc_cpu[MAXCPU]; #define CPUBLOCK MAXCPU Index: sys/ia64/ia64/machdep.c =================================================================== --- sys/ia64/ia64/machdep.c (.../head) (revision 246685) +++ sys/ia64/ia64/machdep.c (.../projects/calloutng) (revision 246685) @@ -404,7 +405,7 @@ if (sched_runnable()) ia64_enable_intr(); else if (cpu_idle_hook != NULL) { - (*cpu_idle_hook)(); XXX-lr style ? just use cpu_idle_hook(sbt); + (*cpu_idle_hook)(sbt); /* The hook must enable interrupts! */ } else { ia64_call_pal_static(PAL_HALT_LIGHT, 0, 0, 0); Index: sys/ofed/include/linux/timer.h =================================================================== --- sys/ofed/include/linux/timer.h (.../head) (revision 246685) +++ sys/ofed/include/linux/timer.h (.../projects/calloutng) (revision 246685) @@ -65,13 +64,16 @@ callout_init(&(timer)->timer_callout, CALLOUT_MPSAFE); \ } while (0) -#define mod_timer(timer, expire) \ XXX-lr gratuitous rename - callout_reset(&(timer)->timer_callout, (expire) - jiffies, \ - _timer_fn, (timer)) +#define mod_timer(timer, exp) \ +do { \ + (timer)->expires = exp; \ + callout_reset(&(timer)->timer_callout, (exp) - jiffies, \ + _timer_fn, (timer)); \ +} while (0) #define add_timer(timer) \ callout_reset(&(timer)->timer_callout, \ - (timer)->timer_callout.c_time - jiffies, _timer_fn, (timer)) + (timer)->expires - jiffies, _timer_fn, (timer)) #define del_timer(timer) callout_stop(&(timer)->timer_callout) #define del_timer_sync(timer) callout_drain(&(timer)->timer_callout) Index: sys/sys/callout.h =================================================================== --- sys/sys/callout.h (.../head) (revision 246685) +++ sys/sys/callout.h (.../projects/calloutng) (revision 246685) @@ -47,7 +47,17 @@ #define CALLOUT_RETURNUNLOCKED 0x0010 /* handler returns with mtx unlocked */ #define CALLOUT_SHAREDLOCK 0x0020 /* callout lock held in shared mode */ #define CALLOUT_DFRMIGRATION 0x0040 /* callout in deferred migration mode */ +#define CALLOUT_PROCESSED 0x0080 /* callout in wheel or processing list? */ +#define CALLOUT_DIRECT 0x0100 /* allow exec from hw int context */ +#define C_DIRECT_EXEC 0x0001 /* direct execution of callout */ +#define C_PRELBITS 7 XXX-lr document all +#define C_PRELRANGE ((1 << C_PRELBITS) - 1) +#define C_PREL(x) (((x) + 1) << 1) +#define C_PRELGET(x) (int)((((x) >> 1) & C_PRELRANGE) - 1) +#define C_HARDCLOCK 0x0100 /* align to hardclock() calls */ +#define C_ABSOLUTE 0x0200 /* event time is absolute. */ + struct callout_handle { struct callout *callout; }; Index: sys/sys/time.h =================================================================== --- sys/sys/time.h (.../head) (revision 246685) +++ sys/sys/time.h (.../projects/calloutng) (revision 246685) @@ -109,6 +124,45 @@ ((a)->frac cmp (b)->frac) : \ ((a)->sec cmp (b)->sec)) +typedef int64_t sbintime_t; XXX-lr add function ns2sbt(), us2sbt(), ms2sbt() +#define SBT_1S ((sbintime_t)1 << 32) +#define SBT_1M (SBT_1S * 60) +#define SBT_1MS (SBT_1S / 1000) +#define SBT_1US (SBT_1S / 1000000) +#define SBT_1NS (SBT_1S / 1000000000) + +static __inline int +sbintime_getsec(sbintime_t sbt) +{ + + return (int)(sbt >> 32); +} + +static __inline sbintime_t +bintime2sbintime(const struct bintime bt) +{ + + return (((sbintime_t)bt.sec << 32) + (bt.frac >> 32)); +} + +static __inline struct bintime +sbintime2bintime(sbintime_t sbt) +{ + struct bintime bt; + + bt.sec = sbt >> 32; + bt.frac = sbt << 32; + return (bt); + +} + +#ifdef _KERNEL + +extern struct bintime tick_bt; +extern sbintime_t tick_sbt; + +#endif /* KERNEL */ + /*- * Background information: * @@ -290,7 +381,15 @@ extern volatile time_t time_second; extern volatile time_t time_uptime; extern struct bintime boottimebin; +extern struct bintime tc_tick_bt; +extern sbintime_t tc_tick_sbt; XXX-lr comment the new vars extern struct timeval boottime; +extern int tc_precexp; XXX-lr comment +extern int tc_timepercentage; +extern struct bintime bt_timethreshold; +extern struct bintime bt_tickthreshold; +extern sbintime_t sbt_timethreshold; +extern sbintime_t sbt_tickthreshold; /* * Functions for looking at our clock: [get]{bin,nano,micro}[up]time() @@ -337,6 +438,23 @@ void timevaladd(struct timeval *t1, const struct timeval *t2); void timevalsub(struct timeval *t1, const struct timeval *t2); int tvtohz(struct timeval *tv); + +#define TC_DEFAULTPERC 5 XXX-lr comment + +#define BT2FREQ(bt) \ + (((uint64_t)0x8000000000000000 + ((bt)->frac >> 2)) / \ + ((bt)->frac >> 1)) + +#define FREQ2BT(freq, bt) \ +{ \ + (bt)->sec = 0; \ + (bt)->frac = ((uint64_t)0x8000000000000000 / (freq)) << 1; \ +} + +#define TIMESEL(sbt, sbt2) \ + (((sbt2) >= sbt_timethreshold) ? \ + (getsbinuptime(sbt), 1) : (sbinuptime(sbt), 0)) + #else /* !_KERNEL */ #include Index: sys/netinet/tcp_timer.c =================================================================== --- sys/netinet/tcp_timer.c (.../head) (revision 246685) +++ sys/netinet/tcp_timer.c (.../projects/calloutng) (revision 246685) @@ -719,20 +719,24 @@ #define ticks_to_msecs(t) (1000*(t) / hz) void -tcp_timer_to_xtimer(struct tcpcb *tp, struct tcp_timer *timer, struct xtcp_timer *xtimer) +tcp_timer_to_xtimer(struct tcpcb *tp, struct tcp_timer *timer, + struct xtcp_timer *xtimer) { - bzero(xtimer, sizeof(struct xtcp_timer)); + sbintime_t now; + + bzero(xtimer, sizeof(*xtimer)); XXX-lr use sbd2ms() if (timer == NULL) return; + getsbinuptime(&now); if (callout_active(&timer->tt_delack)) - xtimer->tt_delack = ticks_to_msecs(timer->tt_delack.c_time - ticks); + xtimer->tt_delack = (timer->tt_delack.c_time - now) / SBT_1MS; if (callout_active(&timer->tt_rexmt)) - xtimer->tt_rexmt = ticks_to_msecs(timer->tt_rexmt.c_time - ticks); + xtimer->tt_rexmt = (timer->tt_rexmt.c_time - now) / SBT_1MS; if (callout_active(&timer->tt_persist)) - xtimer->tt_persist = ticks_to_msecs(timer->tt_persist.c_time - ticks); + xtimer->tt_persist = (timer->tt_persist.c_time - now) / SBT_1MS; if (callout_active(&timer->tt_keep)) - xtimer->tt_keep = ticks_to_msecs(timer->tt_keep.c_time - ticks); + xtimer->tt_keep = (timer->tt_keep.c_time - now) / SBT_1MS; if (callout_active(&timer->tt_2msl)) - xtimer->tt_2msl = ticks_to_msecs(timer->tt_2msl.c_time - ticks); + xtimer->tt_2msl = (timer->tt_2msl.c_time - now) / SBT_1MS; xtimer->t_rcvtime = ticks_to_msecs(ticks - tp->t_rcvtime); } From owner-freebsd-current@FreeBSD.ORG Sun Feb 17 03:25:29 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id CF638985 for ; Sun, 17 Feb 2013 03:25:29 +0000 (UTC) (envelope-from davide.italiano@gmail.com) Received: from mail-ve0-f172.google.com (mail-ve0-f172.google.com [209.85.128.172]) by mx1.freebsd.org (Postfix) with ESMTP id 828847E7 for ; Sun, 17 Feb 2013 03:25:29 +0000 (UTC) Received: by mail-ve0-f172.google.com with SMTP id cz11so4004437veb.31 for ; Sat, 16 Feb 2013 19:25:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=vlgnOzpjecnx7DPfgjDHjeCDWm6JIJm+5WMl0Dqt63I=; b=n6bdw9H6fiw1cgtp1Hn8uFbak6z0kB1H0/QaUC9OOCflDKQ9hbgKbhpEBaQb7dHCXS y/wHY4uqDC5s3oS0fFVXAQQDt43pDto2DaFQtqvzP/5YbmWEwIsXgAF6+IIYrXl5mgUC by9KDxdJ3TKPzMWCd/uA6LpVU1yge7J0ZtgKnrRZ9m3V5UeVnslrFefObbAyMOtdzW6X gBr2Ghxr5UosxJnoGSjQBsSvfJcPL/DibdOSkJuf/TnNziQ5hDu2/doBO0wgL+wLT/Yh ZSvP+6SgPh0xYCixTvlMuMxyyKqXIGc/87udIhQIdZKOIZC3VjVop8BjGJbe1yYNCyTy 2OAw== MIME-Version: 1.0 X-Received: by 10.58.134.16 with SMTP id pg16mr10357573veb.12.1361071522528; Sat, 16 Feb 2013 19:25:22 -0800 (PST) Sender: davide.italiano@gmail.com Received: by 10.220.114.134 with HTTP; Sat, 16 Feb 2013 19:25:22 -0800 (PST) In-Reply-To: References: Date: Sun, 17 Feb 2013 04:25:22 +0100 X-Google-Sender-Auth: LVzAXiihxKNF6hK_a_j1Pw7amxU Message-ID: Subject: Re: Running out of bits p_flag (sys/sys/proc.h) From: Davide Italiano To: hiren panchasara Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 17 Feb 2013 03:25:29 -0000 On Sun, Feb 17, 2013 at 2:58 AM, hiren panchasara wrote: > With revision=246484, it seems we have hit the limit. > At $WORK we have one more flag and to accommodate that we need to bump this up. > > Can p_flag be bumped up to u_long? > > Index: proc.h > =================================================================== > --- proc.h (revision 245937) > +++ proc.h (working copy) > @@ -497,7 +497,7 @@ > * The following don't make too much sense. > * See the td_ or ke_ versions of the same flags. > */ > - int p_flag; /* (c) P_* flags. */ > + u_long p_flag; /* (c) P_* flags. */ > enum { > PRS_NEW = 0, /* In creation */ > PRS_NORMAL, /* threads can be run. */ > > Thanks, > Hiren > _______________________________________________ > 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 see at least two problems here: - The change you propose may result in a KBI breakage. - sizeof(unsigned long) == 4 on some archs, e.g. my i386 Atom, which makes the change uneffective. Thanks, Davide From owner-freebsd-current@FreeBSD.ORG Sun Feb 17 04:17:11 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 543BBFCE; Sun, 17 Feb 2013 04:17:11 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id DD6198E6; Sun, 17 Feb 2013 04:17:10 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.6/8.14.6) with ESMTP id r1H4H67j006222; Sun, 17 Feb 2013 06:17:06 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.7.4 kib.kiev.ua r1H4H67j006222 Received: (from kostik@localhost) by tom.home (8.14.6/8.14.6/Submit) id r1H4H64D006221; Sun, 17 Feb 2013 06:17:06 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 17 Feb 2013 06:17:06 +0200 From: Konstantin Belousov To: Davide Italiano Subject: Re: Running out of bits p_flag (sys/sys/proc.h) Message-ID: <20130217041706.GA2522@kib.kiev.ua> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="j+blFMWKY/m72zgp" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: freebsd-current , hiren panchasara X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 17 Feb 2013 04:17:11 -0000 --j+blFMWKY/m72zgp Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Feb 17, 2013 at 04:25:22AM +0100, Davide Italiano wrote: > On Sun, Feb 17, 2013 at 2:58 AM, hiren panchasara > wrote: > > With revision=3D246484, it seems we have hit the limit. > > At $WORK we have one more flag and to accommodate that we need to bump = this up. > > > > Can p_flag be bumped up to u_long? > > > > Index: proc.h > > =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 > > --- proc.h (revision 245937) > > +++ proc.h (working copy) > > @@ -497,7 +497,7 @@ > > * The following don't make too much sense. > > * See the td_ or ke_ versions of the same flags. > > */ > > - int p_flag; /* (c) P_* flags. */ > > + u_long p_flag; /* (c) P_* flags. */ > > enum { > > PRS_NEW =3D 0, /* In creation */ > > PRS_NORMAL, /* threads can be run. */ > > > > Thanks, > > Hiren > > _______________________________________________ > > freebsd-current@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.o= rg" >=20 > I see at least two problems here: > - The change you propose may result in a KBI breakage. > - sizeof(unsigned long) =3D=3D 4 on some archs, e.g. my i386 Atom, which > makes the change uneffective. You are right. The solution is to add one more flags member, e.g. p_flag2. They are free. The issue I see with the approach, is with the kinfo and userspace reporting of the flag2. I think that some uninteresting (for usermode) flag could be moved to flag2 outright. --j+blFMWKY/m72zgp Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJRIFnBAAoJEJDCuSvBvK1BwgUP/RNb0Uk0IU/YD5U201rdjDZE OKdtlZKMSjkvRtc2Bmu6gHErJeYcS2evQ1v9bPEevS+38/OcJhbX219W4DKZUTsb KfJUVFTGL65hz5pgGgttguus6G9TQYmdTq6aJuamFTvzdWXazFGZtb4YcNk6x+Ao JX8qNGYUaRXg8CvZLtd1KVmlT8qstRswAbRPZopdAlhFK/Q64xAaAvnEHR89xkkw xGT9IT/ylUnln9Gjb9etMwxCTzHaER2GNufp+vnOWbYKXbWkA4jt1B8+vSwbLWjl rvLF83HJoju/xp/wrJ3jbrpHG75VF882zX1UE4Uv/3Sv9LrwLbs5fWVSRqciKgZQ u2PrdIUAq5CqZ9YLNV8+kxq2U0BU9XPY5x3eZ+T++4+bystHKe5lZRT1G5Fd5l0j uN82XepGzgEhzvDZoJuKec/l2Yn8jLo8GaCiXu/0rp/rC5dpatnBPqVQ9+lAII+2 rQw6KLZI0T8HC/1NKB8GPgzagSzMzxr1SEQUFHIAfvUQHOtEgq1LznukxH0Oz9cG Yl2uBvd/uG4nXavip4xhyfEocmiYBk0nvqjUYzFsucsngnijfJVQ6adCT4vs5yHo 8ck8xV+6yaVouVKX8jNbuKehS+RPQ1ASmFF3g3pXbQT6AVgbH/+5SfRbYmz6jc05 h/vhc7ZMmZdKSQYVFMB/ =nvSg -----END PGP SIGNATURE----- --j+blFMWKY/m72zgp-- From owner-freebsd-current@FreeBSD.ORG Sun Feb 17 11:09:26 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 440DEE21; Sun, 17 Feb 2013 11:09:26 +0000 (UTC) (envelope-from chagin.dmitry@gmail.com) Received: from mail-lb0-f181.google.com (mail-lb0-f181.google.com [209.85.217.181]) by mx1.freebsd.org (Postfix) with ESMTP id 01D6318A; Sun, 17 Feb 2013 11:09:24 +0000 (UTC) Received: by mail-lb0-f181.google.com with SMTP id gm6so3596332lbb.40 for ; Sun, 17 Feb 2013 03:09:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:date:from:to:cc:subject:message-id:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=wwHJfhxM4FjQRQAZwUvEBtXFP2YAcRjKb1jvQjpgTcc=; b=KJwPQ1BeCNekxo5cOd7KAW3I5mq/9StSchvje4LnbLtbHzMt07ZKftswIdLcfdxINH 0wh8PGNShbXbx3pNbk/0dq2c2Tml9wMgAAlx+xazcrgLNRkBVQ8bPD4DCS0y8/ttazUA KFF6nlZIzhFUdHDvhvrkO49gdbcNBoLTvzK1/OUk3rZcRp7Pthl4215WgZUcIOtvjTIq 0nMfBwhdu5OmcufuRBD7OPTv8b7t29+LvIFy/Hy2NcYKXkWmPXT8rRqF/MjRLpvOSmtO usYRMlQG43zx+4xBkoTWMF1tnQ1eE76D9ROZr/pe0FzhP4UHW8Bcx98NDJ6DuBecFahA Lr7A== X-Received: by 10.152.109.84 with SMTP id hq20mr2344325lab.48.1361099363511; Sun, 17 Feb 2013 03:09:23 -0800 (PST) Received: from dchagin.static.corbina.net (dchagin.static.corbina.ru. [78.107.232.239]) by mx.google.com with ESMTPS id er8sm19644410lbb.9.2013.02.17.03.09.19 (version=TLSv1.2 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 17 Feb 2013 03:09:20 -0800 (PST) Sender: Dmitry Chagin Received: from dchagin.static.corbina.net (localhost [127.0.0.1]) by dchagin.static.corbina.net (8.14.6/8.14.6) with ESMTP id r1HB9Heu024265; Sun, 17 Feb 2013 15:09:17 +0400 (MSK) (envelope-from dchagin@dchagin.static.corbina.net) Received: (from dchagin@localhost) by dchagin.static.corbina.net (8.14.6/8.14.6/Submit) id r1HB9G43024264; Sun, 17 Feb 2013 15:09:16 +0400 (MSK) (envelope-from dchagin) Date: Sun, 17 Feb 2013 15:09:16 +0400 From: Chagin Dmitry To: Hans Petter Selasky Subject: Re: some usb troubles Message-ID: <20130217110916.GA24219@dchagin.static.corbina.net> References: <20130209180124.GA1783@dchagin.static.corbina.net> <201302101203.36647.hselasky@c2i.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="AqsLC8rIMeq19msA" Content-Disposition: inline In-Reply-To: <201302101203.36647.hselasky@c2i.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-acpi@freebsd.org, freebsd-current@freebsd.org, jkim@freebsd.org, freebsd-usb@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 17 Feb 2013 11:09:26 -0000 --AqsLC8rIMeq19msA Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Feb 10, 2013 at 12:03:36PM +0100, Hans Petter Selasky wrote: > On Saturday 09 February 2013 19:01:25 Chagin Dmitry wrote: > > Hi all, > >=20 > > trying to run macbookpro10,1 on HEAD: > >=20 > > 1) usb3.0 does not work at 9.1 and HEAD (r246587) > > 2) Between stable/9 and HEAD (r246587) we are lost uhid devices > > (external keyboard and mouse) and umass. dmesg on the same hw can find > > here: > >=20 > > http://people.freebsd.org/~dchagin/macbookpro/dmesg.generic.stable9.txt > > http://people.freebsd.org/~dchagin/macbookpro/dmesg.generic.HEAD.txt > >=20 I found the commit that broke usb support: r239340 - merge acpica. > > pciconf: > >=20 > > http://people.freebsd.org/~dchagin/macbookpro/pciconf.txt > >=20 > > any help would be greatly apprecated. >=20 --=20 Have fun! chd --AqsLC8rIMeq19msA Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlEgulwACgkQ0t2Tb3OO/O24CwCfbDyuOBRg942QWAKbpRDCrw+s AWwAoL5liNIYj4YZtsCEZCgxv+ZFqkwk =G7KT -----END PGP SIGNATURE----- --AqsLC8rIMeq19msA-- From owner-freebsd-current@FreeBSD.ORG Sun Feb 17 11:24:30 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 71FE81B9; Sun, 17 Feb 2013 11:24:30 +0000 (UTC) (envelope-from yamayan@kbh.biglobe.ne.jp) Received: from rcpt-expgw.biglobe.ne.jp (rcpt-expgw.biglobe.ne.jp [IPv6:2001:260:401:16::1]) by mx1.freebsd.org (Postfix) with ESMTP id D26371EE; Sun, 17 Feb 2013 11:24:29 +0000 (UTC) Received: from vc-gw.biglobe.ne.jp by rcpt-expgw.biglobe.ne.jp (shby/5910021009) with SMTP id r1HBORiV030112; Sun, 17 Feb 2013 20:24:27 +0900 Received: from smtp-gw.biglobe.ne.jp ([172.21.175.155]) by vc-gw.biglobe.ne.jp (kbkr/0716090908) with ESMTP id r1HBORBd027094; Sun, 17 Feb 2013 20:24:27 +0900 X-Biglobe-Sender: Received: from [192.168.0.100] (KD027083060020.ppp-bb.dion.ne.jp [27.83.60.20]) by smtp-gw.biglobe.ne.jp id UACKAC15AFDB; Sun, 17 Feb 2013 20:24:27 +0900 (JST) Message-ID: <5120BDF9.7030300@kbh.biglobe.ne.jp> Date: Sun, 17 Feb 2013 20:24:41 +0900 From: Yamaya Takashi User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130129 Thunderbird/17.0.2 MIME-Version: 1.0 To: "O. Hartmann" Subject: Re: ports include /etc/src.conf? i.e. graphics/libfpx References: <511B662C.7030602@zedat.fu-berlin.de> <511B874A.7080901@kbh.biglobe.ne.jp> <511CE470.4070003@kbh.biglobe.ne.jp> <511D4FD3.2070605@zedat.fu-berlin.de> In-Reply-To: <511D4FD3.2070605@zedat.fu-berlin.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sun, 17 Feb 2013 12:42:01 +0000 Cc: Tom Evans , "free >> Current FreeBSD" , Ports FreeBSD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 17 Feb 2013 11:24:30 -0000 On 2013/02/15 05:57, O. Hartmann wrote: > Am 02/14/13 14:19, schrieb Yamaya Takashi: >> On 2013/02/13 22:33, Tom Evans wrote: >>> On Wed, Feb 13, 2013 at 12:30 PM, Yamaya Takashi >>> wrote: >>>> On 2013/02/13 19:08, O. Hartmann wrote: >>>>> Setting only base system source compiler optins in /etc/src.conf, for >>>>> instance >>>>> >>>>> # >>>>> CXXFLAGS+= -stdlib=libc++ >>>>> CXXFLAGS+= -std=c++11 >>>>> >>>>> >>>>> which do NOT appear in /etc/make.conf, make building port >>>>> grahpics/libfpx complaining about unrecognized compiler options. >>>>> >>>>> As far a sI know, /etc/src.conf is ONLY for building the source tree of >>>>> the operating system and make.conf is supposed to contain all stuff >>>>> necessary for compiling both world and ports, but /etc/src.conf is world >>>>> only. >>>>> >>>>> Am I wrong? >>>>> >>>>> Oliver >>>>> >>>> Yes. >>>> Because files/Makefile.bsd includes , >>>> /etc/src.conf is included. >>>> >>>> >>> src.conf(5) says: >>> >>> The only purpose of src.conf is to control the compilation of the FreeBSD >>> source code, which is usually located in /usr/src. >>> >>> Cheers >>> >>> Tom >>> >>> >> src.conf(5) says: >> The values of variables are ignored regardless of their setting; >> even if >> they would be set to ``FALSE'' or ``NO''. Just the existence of an >> option will cause it to be honoured by make(1). >> >> The following list provides a name and short description for variables >> that can be used for source builds. >> >> Does it mean ONLY WITH_* and WITHOUT_* variables are allowed in >> /etc/src.conf? >> >> > > Shortly, there was a discussion about a fully installed LLVM/CLANG and > the portion of LLVM/CLANG, that is only needed to compile the system's > source. In this case, a strict separartion was intended. Not about llvm/clang. Including /etc/src.conf has problem of conflicting world knob and port knob. Skipping to include /etc/src.conf by is needed. It's difficult for base system. Then define _WITHOUT_SRCCONF and skip including /etc/src.conf. But some ports include (exclude ) has bug, because they don't define _WITHOUT_SRCCONF. > If the manpage of /etc/src.conf says that only bool knobs are allowed > like WITH_XXX or WITHOUT_XXX, then: where to put the options? NOT bool, the variable is defined or not. The options are written in /etc/make.conf From owner-freebsd-current@FreeBSD.ORG Sun Feb 17 13:16:05 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id D6847433; Sun, 17 Feb 2013 13:16:05 +0000 (UTC) (envelope-from kpaasial@gmail.com) Received: from mail-we0-x234.google.com (mail-we0-x234.google.com [IPv6:2a00:1450:400c:c03::234]) by mx1.freebsd.org (Postfix) with ESMTP id 2A57681A; Sun, 17 Feb 2013 13:16:04 +0000 (UTC) Received: by mail-we0-f180.google.com with SMTP id k14so3934880wer.25 for ; Sun, 17 Feb 2013 05:16:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=s4QB0piSvN+2v1/uPjxZ4A4iUt+0vkayd1YG7SlQuEg=; b=XDZEqdELQkbAGHtZrnYIZhdRyq80+23BgLAMYdaOBI0pqjlCuhE5NkmpRqhIEPJK5I 22+yKY4kTFJU0Lh/LNBJB/2ivLEe0ts0HI+UNq9ngfrTlULC7eOrQYAYj8hfyUScHfkE W9Y1x2eCkbmlpj0GsCUBvFrBIZAVd7QF/+wgJXyjaWhU8825HuWhkmMn5hLwA65ZpN8b PkvqEtogV9r77s9pZF/LUDLgVuhI4Yp2djiSkdd0gmhZlKZogN/otyXm2d4dGSMZO1KI QEJhhTByU9inIsVav5wUsfcHylXqFnMwZyh8VRIDW9uEiKcyjBMu+GTJE+XH0DPb0Iir CO2A== MIME-Version: 1.0 X-Received: by 10.194.122.199 with SMTP id lu7mr13499261wjb.42.1361106964377; Sun, 17 Feb 2013 05:16:04 -0800 (PST) Received: by 10.216.120.193 with HTTP; Sun, 17 Feb 2013 05:16:04 -0800 (PST) In-Reply-To: <20130213022215.GK99263@hades.panopticon> References: <20130213022215.GK99263@hades.panopticon> Date: Sun, 17 Feb 2013 15:16:04 +0200 Message-ID: Subject: Re: CLANG and -fstack-protector From: Kimmo Paasiala To: Dmitry Marakasov Content-Type: text/plain; charset=UTF-8 Cc: FreeBSD current , freebsd-stable@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 17 Feb 2013 13:16:05 -0000 On Wed, Feb 13, 2013 at 4:22 AM, Dmitry Marakasov wrote: > * Kimmo Paasiala (kpaasial@gmail.com) wrote: > >> Does the -fstack-protector option work on CLANG 3.1 and 3.2? >> >> There is thread on FreeBSD forums about the stack protector and ports >> and I'm wondering if it's possible to use the -fstack-protector option >> with CLANG. >> >> http://forums.freebsd.org/showthread.php?t=36927 > > You might be interested in this patch: > > https://github.com/AMDmi3/freebsd-ports-mk/compare/master...stack-protector > > afaik, in prior discussion some years ago an issue was mentioned that > some ports don't build with stack-protector, so I suggested to introduce > STACK_PROTECTOR_SAFE/_UNSAFE knobs similar to what we have for > MAKE_JOBS_SAFE_/_UNSAFE (we might actually only need > STACK_PROTECTOR_UNSAFE, as unlike MAKE_JOBS, build errors caused by > enabling stack protector are not transient, so we can have an exp-run > to just mark all uncompatible ports and consider all others compatible). > > If there's interest in this, I can refresh the patch and submit it. > Yes, this is very much what I had in mind. Please submit it :) -Kimmo From owner-freebsd-current@FreeBSD.ORG Sun Feb 17 13:46:49 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id E08169E1 for ; Sun, 17 Feb 2013 13:46:49 +0000 (UTC) (envelope-from lokedhs@gmail.com) Received: from mail-lb0-f178.google.com (mail-lb0-f178.google.com [209.85.217.178]) by mx1.freebsd.org (Postfix) with ESMTP id 5AC668E7 for ; Sun, 17 Feb 2013 13:46:48 +0000 (UTC) Received: by mail-lb0-f178.google.com with SMTP id n1so3673088lba.37 for ; Sun, 17 Feb 2013 05:46:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=y0FM5+ndHtxyrRzNocpygmCNHrm9OiOPIiXB+T+/XcU=; b=XmpwyHnUiXgjdQJ3Ij11ap8w+qwQBlGdvjxQW0yqIcrXiqcubZmdrmsjB2gWAuk3bK 4B3Yc28PWxh+PyzY6hcIuLTNNSIV/azMMI3NaQwQGQdIT1T3zBcoe7ziC4wix3fzcynn znNnfyWirxOURAMe7dF+HZuM4cqE/euE0YPcE3Lhfi5X9vTSu/bcEoleOOsxs2Zjwyyp 9+BJq3PsgoiJMrPx91v1eyl6A8xnwwuZDqtmvkR32GJv6TfgiX3tXWrpZy01JjhVX4Jk NKu6foTbTsdCqpVzxmADm1dVSylmy3ds3HJ5S1vmBqghXXnZpOTcTw8zFS5cwrWLesrf Z5PQ== MIME-Version: 1.0 X-Received: by 10.112.37.194 with SMTP id a2mr4453156lbk.40.1361108802373; Sun, 17 Feb 2013 05:46:42 -0800 (PST) Received: by 10.112.41.68 with HTTP; Sun, 17 Feb 2013 05:46:42 -0800 (PST) In-Reply-To: References: <336731055.3000548.1360798935813.JavaMail.root@erie.cs.uoguelph.ca> Date: Sun, 17 Feb 2013 21:46:42 +0800 Message-ID: Subject: Re: Possible bug in NFSv4 with krb5p security? From: =?ISO-8859-1?Q?Elias_M=E5rtenson?= To: Doug Rabson Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Rick Macklem , Benjamin Kaduk , freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 17 Feb 2013 13:46:49 -0000 On 17 February 2013 02:17, Doug Rabson wrote: > > I think it was Rick that mentioned the patch. I would apply the patch and > rebuild your kernel in the interests of changing as little as possible > while debugging the original issue. > Fair enough. I did this. Thanks. Now, I'm sorry for asking something that should be obvious, but how can I rebuild crypto/heimdal? There is no Makefile in this directory, but when I did "make world" it did build it. So how does this actually work? Is there a special Makefile somewhere else that I should use? I need to be able to rebuild these things withou thaving to do a full "make world", which is the only way I figured out so far. (of course, I could do a automake/configure/make sequence, but it seems as though the official FreeBSD build doesn't do this (I couldn't find any config.log file dropped from the configure script)). Regards, Elias From owner-freebsd-current@FreeBSD.ORG Sun Feb 17 14:59:02 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 89F358EA for ; Sun, 17 Feb 2013 14:59:02 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.net.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id 45425AA7 for ; Sun, 17 Feb 2013 14:59:01 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqEEAGrvIFGDaFvO/2dsb2JhbABEhkm5U4EUc4IfAQEBAwEBAQEgKyALBRYYAgINGQIpAQkmBggHBAEcBIdrBgysF5FGgSOMU4ENNAeCLYETA4hniw2COIEdjzuDJU+BBTU X-IronPort-AV: E=Sophos;i="4.84,682,1355115600"; d="scan'208";a="14487723" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-annu.net.uoguelph.ca with ESMTP; 17 Feb 2013 09:58:55 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 3F58CB403D; Sun, 17 Feb 2013 09:58:55 -0500 (EST) Date: Sun, 17 Feb 2013 09:58:55 -0500 (EST) From: Rick Macklem To: =?utf-8?Q?Elias_M=C3=A5rtenson?= Message-ID: <477291850.3084864.1361113135205.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: Subject: Re: Possible bug in NFSv4 with krb5p security? MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.203] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - FF3.0 (Win)/6.0.10_GA_2692) Cc: freebsd-current@freebsd.org, Benjamin Kaduk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 17 Feb 2013 14:59:02 -0000 Elias Martenson wrote: > On 17 February 2013 02:17, Doug Rabson wrote: > > > > > I think it was Rick that mentioned the patch. I would apply the > > patch and > > rebuild your kernel in the interests of changing as little as > > possible > > while debugging the original issue. > > > > Fair enough. I did this. Thanks. > > Now, I'm sorry for asking something that should be obvious, but how > can I > rebuild crypto/heimdal? I think the Makefiles are in the kerberos5 directory. Since the only function you care about is the one in kerberos5/lib/libgssapi_krb5/pname_to_uid.c, I'd just put a copy of that file in usr.sbin/gssd and modify the Makefile there to compile it and link its .o into gssd, avoiding rebuilding any libraries. I'd put a couple of fprintf(stderr, ...) in it and then run "gssd -d" and see what it says. Just how I'd attack it, rick > There is no Makefile in this directory, but > when I > did "make world" it did build it. So how does this actually work? Is > there > a special Makefile somewhere else that I should use? I need to be able > to > rebuild these things withou thaving to do a full "make world", which > is the > only way I figured out so far. > > (of course, I could do a automake/configure/make sequence, but it > seems as > though the official FreeBSD build doesn't do this (I couldn't find any > config.log file dropped from the configure script)). > > Regards, > Elias > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to > "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Sun Feb 17 16:11:57 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id D0D5F492 for ; Sun, 17 Feb 2013 16:11:57 +0000 (UTC) (envelope-from wblock@wonkity.com) Received: from wonkity.com (wonkity.com [67.158.26.137]) by mx1.freebsd.org (Postfix) with ESMTP id 6D488DA8 for ; Sun, 17 Feb 2013 16:11:57 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.6/8.14.6) with ESMTP id r1HGBmQT095086; Sun, 17 Feb 2013 09:11:48 -0700 (MST) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.6/8.14.6/Submit) with ESMTP id r1HGBmmU095083; Sun, 17 Feb 2013 09:11:48 -0700 (MST) (envelope-from wblock@wonkity.com) Date: Sun, 17 Feb 2013 09:11:48 -0700 (MST) From: Warren Block To: Erich Dollansky Subject: Re: gpart, slice starts at 0 In-Reply-To: <20130217080412.205899fd@X220.ovitrap.com> Message-ID: References: <20130216145122.3db70652@X220.ovitrap.com> <20130217080412.205899fd@X220.ovitrap.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (wonkity.com [127.0.0.1]); Sun, 17 Feb 2013 09:11:49 -0700 (MST) Cc: current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 17 Feb 2013 16:11:57 -0000 On Sun, 17 Feb 2013, Erich Dollansky wrote: >>> gpart destroy -F da0 >>> diskinfo da0 >>> dd if=/dev/zero of=/dev/da0 bs=512 count=34 >>> dd if=/dev/zero of=/dev/da0 bs=512 count=34 seek=312581774 >> >> Someone here on the lists (I unfortunately forget who) showed a >> sneaky easier way to do this: >> >> gpart destroy -F da0 >> gpart create -s gpt da0 >> gpart destroy -F da0 >> > This did not make a difference. It's an easier way to destroy the backup table at the end of the disk, whether one was there before or not, without having to calculate the location. >>> gpart show -p da0 >>> gpart create -s MBR da0 >>> gpart add -t freebsd da0 >>> gpart show -p da0 >>> gpart show -p da0s1 >>> gpart set -a active -i 1 da0 >>> # >>> # The following line always gives an error: >>> # >>> # gpart create -s BSD da0s1 >> >> 'destroy' is not recursive. It destroys the geom found on the device >> given, but does not write to any geoms inside those geoms. >> > This is obvious. What surprises me is that create does not write a new > and empty description to the disk. It does, but not being recursive, it does not destroy the geoms inside the one given to the command (da0). You had: da0 (MBR) da0s1 (bsdlabel) After the destroy, it became da0 (null) da0s1 (bsdlabel) This can happen with any of the setups where there are geoms inside other geoms. >> The second part of your question, about da0 starting a block zero: >> >>> [X220]...Appl/Some Tools (root) > gpart show da0 >>> => 63 312581745 da0 MBR (149G) >>> 63 312581745 1 freebsd [active] (149G) >>> >>> [X220]...Appl/Some Tools (root) > gpart show da0s1 >>> => 0 312581745 da0s1 BSD (149G) >>> 0 312581745 - free - (149G) >> >> That shows slice one starts at block 63, standard for MBR. The space >> inside the slice (da0s1) starts at block 0 *of the slice*. > > This is a bit confusing for me but it does not really matter as long as > the programs get it straight. This is again because of the geom inside a geom setup. The actual start block is the start of the slice (block 63) plus the start of the FreeBSD partition inside the slice (currently 0). When you create FreeBSD partitions inside da0s1, they will have nonzero offsets from the start of the slice. There are examples shown here: http://forums.freebsd.org/showpost.php?p=206204&postcount=11 From owner-freebsd-current@FreeBSD.ORG Sun Feb 17 21:13:16 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 95FF3889; Sun, 17 Feb 2013 21:13:16 +0000 (UTC) (envelope-from marcel@xcllnt.net) Received: from mail.xcllnt.net (mail.xcllnt.net [70.36.220.4]) by mx1.freebsd.org (Postfix) with ESMTP id 716A48D7; Sun, 17 Feb 2013 21:13:16 +0000 (UTC) Received: from lrust-sslvpn-nc.jnpr.net (natint3.juniper.net [66.129.224.36]) (authenticated bits=0) by mail.xcllnt.net (8.14.6/8.14.6) with ESMTP id r1HLDBWP003862 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 17 Feb 2013 13:13:13 -0800 (PST) (envelope-from marcel@xcllnt.net) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: [head tinderbox] failure on powerpc64/powerpc From: Marcel Moolenaar In-Reply-To: <86ehgfc3th.fsf@ds4.des.no> Date: Sun, 17 Feb 2013 13:13:06 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <8FED3AA7-C2B7-4A8C-A5B3-45A098B7C67A@xcllnt.net> References: <201302162137.r1GLbn0B037655@freebsd-current.sentex.ca> <86ehgfc3th.fsf@ds4.des.no> To: =?iso-8859-1?Q?Dag-Erling_Sm=F8rgrav?= X-Mailer: Apple Mail (2.1499) Cc: powerpc64@freebsd.org, FreeBSD Tinderbox , current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 17 Feb 2013 21:13:16 -0000 On Feb 16, 2013, at 2:05 PM, Dag-Erling Sm=F8rgrav wrote: > FreeBSD Tinderbox writes: >> cc -O2 -pipe -I/src/lib/libldns/../../contrib/ldns -std=3Dgnu99 = -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W = -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes = -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c = /src/lib/libldns/../../contrib/ldns/dnssec_verify.c -o dnssec_verify.o >> cc1: warnings being treated as errors >> /src/lib/libldns/../../contrib/ldns/dnssec_verify.c:638: warning: >> ldns_dnssec_trust_tree_print_sm' defined but not used >> *** [dnssec_verify.o] Error code 1 >>=20 >> Stop in /src/lib/libldns. >=20 > Why is this happening? The Makefile sets WARNS to 3, which adds > -Wno-unused-function to CFLAGS, which should suppress this warning. I don't see -Wno-unused-function above. I only see = -Wno-unused-parameter. I also don't see -Wno-parentheses-equality nor -Wno-conversion, so I guess that means that the set of flags applicable for WARNS=3D3 isn't = being taken. It looks like WARNS is in fact 3: eris% make -V WARNS 3 Since bsd.sys.mk has grown unreadable, try unraveling the conditionals to see if WARNS for GCC does the equivalent for CLANG. Is the problem specific to architectures that don't use CLANG? =20 --=20 Marcel Moolenaar marcel@xcllnt.net From owner-freebsd-current@FreeBSD.ORG Mon Feb 18 01:01:13 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id D44F672D for ; Mon, 18 Feb 2013 01:01:13 +0000 (UTC) (envelope-from erichsfreebsdlist@alogt.com) Received: from alogt.com (alogt.com [69.36.191.58]) by mx1.freebsd.org (Postfix) with ESMTP id 8E8F114E for ; Mon, 18 Feb 2013 01:01:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=alogt.com; s=default; h=Content-Transfer-Encoding:Content-Type:Mime-Version:References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date; bh=zhIKuuMFJWugSysTCNTKQLUpqNBao4CPyb3IzixSgdg=; b=pDEzuzZm8jHWEYW3L8QohVilUsKn23FL7OM4w8pJhAB5lK+DKZx/b9pQAIRlBylbePE3goMSWvWCElnSoox9hixPi/VkZFiGkE76vmKpkmcUB0xGBeqbHs6t8D3l/e6o; Received: from [122.129.203.50] (port=45721 helo=X220.ovitrap.com) by sl-508-2.slc.westdc.net with esmtpsa (SSLv3:DHE-RSA-AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1U7F6V-001Hm0-FI; Sun, 17 Feb 2013 18:01:12 -0700 Date: Mon, 18 Feb 2013 08:01:07 +0700 From: Erich Dollansky To: Warren Block Subject: Re: gpart, slice starts at 0 Message-ID: <20130218080107.07e74f64@X220.ovitrap.com> In-Reply-To: References: <20130216145122.3db70652@X220.ovitrap.com> <20130217080412.205899fd@X220.ovitrap.com> X-Mailer: Claws Mail 3.9.0 (GTK+ 2.24.6; amd64-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - sl-508-2.slc.westdc.net X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - alogt.com X-Get-Message-Sender-Via: sl-508-2.slc.westdc.net: authenticated_id: erichsfreebsdlist@alogt.com X-Source: X-Source-Args: X-Source-Dir: Cc: current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 18 Feb 2013 01:01:13 -0000 Hi, On Sun, 17 Feb 2013 09:11:48 -0700 (MST) Warren Block wrote: > On Sun, 17 Feb 2013, Erich Dollansky wrote: > > >>> gpart destroy -F da0 > >>> diskinfo da0 > >>> dd if=/dev/zero of=/dev/da0 bs=512 count=34 > >>> dd if=/dev/zero of=/dev/da0 bs=512 count=34 seek=312581774 > >> > >> Someone here on the lists (I unfortunately forget who) showed a > >> sneaky easier way to do this: > >> > >> gpart destroy -F da0 > >> gpart create -s gpt da0 > >> gpart destroy -F da0 > >> > > This did not make a difference. > > It's an easier way to destroy the backup table at the end of the > disk, whether one was there before or not, without having to > calculate the location. ok, so, I should keep this then. > > >>> gpart show -p da0 > >>> gpart create -s MBR da0 > >>> gpart add -t freebsd da0 > >>> gpart show -p da0 > >>> gpart show -p da0s1 > >>> gpart set -a active -i 1 da0 > >>> # > >>> # The following line always gives an error: > >>> # > >>> # gpart create -s BSD da0s1 > >> > >> 'destroy' is not recursive. It destroys the geom found on the > >> device given, but does not write to any geoms inside those geoms. > >> > > This is obvious. What surprises me is that create does not write a > > new and empty description to the disk. > > It does, but not being recursive, it does not destroy the geoms > inside the one given to the command (da0). You had: > > da0 (MBR) > da0s1 (bsdlabel) > > After the destroy, it became > da0 (null) > da0s1 (bsdlabel) It seems that we talk here about the same with very different words. The effect comes from the fact that the entries are always on the same location on a disk. The advantage is that repartitioning a disk stills leaves some room for recovery. > > This can happen with any of the setups where there are geoms inside > other geoms. > > >> The second part of your question, about da0 starting a block zero: > >> > >>> [X220]...Appl/Some Tools (root) > gpart show da0 > >>> => 63 312581745 da0 MBR (149G) > >>> 63 312581745 1 freebsd [active] (149G) > >>> > >>> [X220]...Appl/Some Tools (root) > gpart show da0s1 > >>> => 0 312581745 da0s1 BSD (149G) > >>> 0 312581745 - free - (149G) > >> > >> That shows slice one starts at block 63, standard for MBR. The > >> space inside the slice (da0s1) starts at block 0 *of the slice*. > > > > This is a bit confusing for me but it does not really matter as > > long as the programs get it straight. > > This is again because of the geom inside a geom setup. The actual > start block is the start of the slice (block 63) plus the start of > the FreeBSD partition inside the slice (currently 0). When you > create FreeBSD partitions inside da0s1, they will have nonzero > offsets from the start of the slice. There are examples shown here: > http://forums.freebsd.org/showpost.php?p=206204&postcount=11 And I saw there how to overcome the alignment problems. It is so simple. Just understanding it was not so simple for me. Thanks! Erich > _______________________________________________ > 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 Mon Feb 18 05:58:32 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 9BAA1495 for ; Mon, 18 Feb 2013 05:58:32 +0000 (UTC) (envelope-from deeptech71@gmail.com) Received: from mail-ee0-f42.google.com (mail-ee0-f42.google.com [74.125.83.42]) by mx1.freebsd.org (Postfix) with ESMTP id 04070DC9 for ; Mon, 18 Feb 2013 05:58:31 +0000 (UTC) Received: by mail-ee0-f42.google.com with SMTP id b47so2644949eek.29 for ; Sun, 17 Feb 2013 21:58:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=D8JVVNLKseKS5RmmZwtpNBi8PdSOql6hY52dP5ANw18=; b=G8iPrUCz48PiaDZn/ZztreyA3GHFVs8v8j/SVUr2zypqNRm+pvI493CwS30Yisko+i VrrPxCjUrB0o87o5IvpAdOWbCPRTGD/LiQSf34KnA/IDNgrjloMNAuJeuMhiH5x86ILc jG+9wnaVUe6yUQIptAi3c5N/0UpeyOp2aMzVroVG4XAEoH6XmoOvlFiA0X83MLUJ+9qG Y6fU7mMtYSJQtXuH3HFdlGi3r77u0gxd4FNdFhUunpEqwKBmu0U3hqGrhzfFwUkskNA0 VSr+CJYYpA/ZEF4/dkBuwSFw6JNTCABaxrsmExAbG3GJTaxy3m31Osv2Feym34JiYRRA 4/Gw== X-Received: by 10.14.219.7 with SMTP id l7mr16954173eep.12.1361167105288; Sun, 17 Feb 2013 21:58:25 -0800 (PST) Received: from [192.168.1.80] (54021263.dsl.pool.telekom.hu. [84.2.18.99]) by mx.google.com with ESMTPS id 3sm96546486eej.6.2013.02.17.21.58.22 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 17 Feb 2013 21:58:23 -0800 (PST) Message-ID: <5121B4F3.8020008@gmail.com> Date: Mon, 18 Feb 2013 05:58:27 +0100 From: deeptech71 User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:18.0) Gecko/20100101 SeaMonkey/2.15 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: the latest version of Clang/LLVM for the world and kernel References: <511E378E.3090200@gmail.com> <511E5B05.5050402@FreeBSD.org> <511EBEFE.5010406@gmail.com> <511FB105.7040004@FreeBSD.org> In-Reply-To: <511FB105.7040004@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 18 Feb 2013 05:58:32 -0000 On 02/16/2013 17:17, Dimitry Andric wrote: > On 2013-02-16 00:04, deeptech71 wrote: >> First of all, you should understand that these are compilation errors > > No, they are only errors because we have turned on -Werror. You meant to say: Yes, but they are only errors because we have turned on -Werror. > Regarding this particular warning, it could be fixed by casting status > to int, or adding -Wno-tautological-constant-out-of-range-compare to the > flags for its WARNS= level (which is 2, if I looked it up correctly). I'd change the variable to an int. >> Second of all, you should understand that these are real errors; in this case, the compiler may omit generating code to check for a boolean condition, if the value of that condition is known at compile time, and thus generating a program with an undesired mode of operation. > > No, this is not the case with enums, unless you use the -fstrict-enums > flag, which we don't use at the moment. And even with that flag, I did > not see any change in the resulting assembly. > > This is probably because it would break too much software, if such an > optimization was implemented, even if that optimization is strictly > speaking completely legal to do. What makes you think that no semantic changes will occur in the future? What about other compilers? As the makefile comments say, some warnings are kept enabled to create an incentive to fix the code. But the real incentive should be that fixing the code makes the difference between WRONG and non-WRONG. >>>> * /usr/src/lib/libugidfw/ugidfw.c:74:10: error: comparison of unsigned expression < 0 is always false [-Werror,-Wtautological-compare] >>>> * if (len < 0 || len > left) >>>> * ~~~ ^ ~ > > Normally, they are not errors, but just warnings, unless you changed > something in the bsd.*.mk logic to not detect clang. WRONG. Clang detection measures are intact here: /etc/make.conf contains: CC=/dir1/clang CPP=/dir1/clang-cpp CXX=/dir1/clang++ TBLGEN=/dir1/clang-tblgen From owner-freebsd-current@FreeBSD.ORG Mon Feb 18 07:24:32 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 6BC33E5A for ; Mon, 18 Feb 2013 07:24:32 +0000 (UTC) (envelope-from deeptech71@gmail.com) Received: from mail-ee0-f45.google.com (mail-ee0-f45.google.com [74.125.83.45]) by mx1.freebsd.org (Postfix) with ESMTP id D1988FF7 for ; Mon, 18 Feb 2013 07:24:31 +0000 (UTC) Received: by mail-ee0-f45.google.com with SMTP id b57so2603464eek.32 for ; Sun, 17 Feb 2013 23:24:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=14rg2LrjJ5vM76mpVLk9umMINMKpOSW2cbuQKzVP46s=; b=LqJ/1F021o9JhYZICq1LGm/MqxzvCaIcpDUhoHziqY8lJ0/AGwwoBk4gjQzKpDU0xo 8IiVnYMz0GuidrsZgZ7dl/ks+AXwl5RMf4b+QHahTIsrzmsEz6M3u1ij6riNFxK3uMXY JE91k8/P5gDa/iKGEDa5WRjDjYQx4npwddwsnkvSt+U0mLhTDboSw0EQ1nqrY1iSsj2L Q1QXi8xM0/lEjui8PGH538l5wMRdybF+QhsBFimNbCeebWs4qyhsOgaEI8tOJ4NQaKi6 3FsAl6iRwVxnfS/jmqAqgRtn4MbISPkOrMw7roORQYtZ7IGW3YNz0uoFXTmQwLHvcM8k b9gg== X-Received: by 10.14.211.132 with SMTP id w4mr41247312eeo.36.1361171871659; Sun, 17 Feb 2013 23:17:51 -0800 (PST) Received: from [192.168.1.80] (BC069DC1.dsl.pool.telekom.hu. [188.6.157.193]) by mx.google.com with ESMTPS id 3sm96826682eej.6.2013.02.17.23.17.49 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 17 Feb 2013 23:17:50 -0800 (PST) Message-ID: <5121C793.7040006@gmail.com> Date: Mon, 18 Feb 2013 07:17:55 +0100 From: deeptech71 User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:18.0) Gecko/20100101 SeaMonkey/2.15 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: conflicting types for 'EC_KEY_insert_key_method_data' Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 18 Feb 2013 07:24:32 -0000 /llvm_installation/bin/clang -O2 -pipe -march=native -DTERMIOS -DANSI_SOURCE -I/usr/src/secure/lib/libcrypto/../../../crypto/openssl -I/usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto -I/usr/obj/usr/src/secure/lib/libcrypto -DOPENSSL_THREADS -DDSO_DLFCN -DHAVE_DLFCN_H -DOPENSSL_NO_IDEA -DL_ENDIAN -DOPENSSL_IA32_SSE2 -DAES_ASM -DVPAES_ASM -DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DMD5_ASM -DGHASH_ASM -DRMD160_ASM -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DWHIRLPOOL_ASM -I/usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/asn1 -I/usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/evp -I/usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/modes -DNO_IDEA -std=gnu89 -Qunused-arguments -fstack-protector -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno - parentheses -c /usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/ec/ec_key.c -o ec_key.o /usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/ec/ec_key.c:532:7: error: conflicting types for 'EC_KEY_insert_key_method_data' void *EC_KEY_insert_key_method_data(EC_KEY *key, void *data, ^ /usr/include/openssl/ec.h:809:6: note: previous declaration is here void EC_KEY_insert_key_method_data(EC_KEY *, void *data, ^ Fix include paths (-I) in the makefiles? From owner-freebsd-current@FreeBSD.ORG Mon Feb 18 12:44:42 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id BA9B7BD3 for ; Mon, 18 Feb 2013 12:44:42 +0000 (UTC) (envelope-from onwahe@gmail.com) Received: from mail-qc0-f169.google.com (mail-qc0-f169.google.com [209.85.216.169]) by mx1.freebsd.org (Postfix) with ESMTP id 76A419EF for ; Mon, 18 Feb 2013 12:44:42 +0000 (UTC) Received: by mail-qc0-f169.google.com with SMTP id t2so2068581qcq.14 for ; Mon, 18 Feb 2013 04:44:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=clj2jLuBS6szYBXrwNXIVjHIef6VYc3YFNEmyRWOnRY=; b=OcR+2piBHeEDhRkK1xYMU6e2RncKvWAv8aKeIBQMmMttqMniR1wjmk4Op2IiIuPvwE Cm1wfr+9opxpPCwjmEcp1WtIyG5uz3SKvmBhzmN/4RMBdJMRpzsMP97segR+EsRzjRO0 1XG3tR6uIn5lYv+utbDHJNkR13TPHQrGLCjgNkdAEOkEaUhbAcerHlEnAa143dVyrvnS yQXnM9lDF8u7pzbKCrmCE+b7fCExPHLh6VLOjM9+AcBigKHdoXuv3uplMNaEF8Dn7arC +KA7IOd08QOfmIAg/coEanHUj0A85SzJS06ZE1VfzGl9MwhKlpCIdTAc+1vTVzDhHl0Y kD+g== MIME-Version: 1.0 X-Received: by 10.49.108.9 with SMTP id hg9mr4830469qeb.34.1361191476028; Mon, 18 Feb 2013 04:44:36 -0800 (PST) Received: by 10.49.121.198 with HTTP; Mon, 18 Feb 2013 04:44:35 -0800 (PST) Date: Mon, 18 Feb 2013 13:44:35 +0100 Message-ID: Subject: [patch] i386 pmap sysmaps_pcpu[] atomic access From: Svatopluk Kraus To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 18 Feb 2013 12:44:42 -0000 Hi, the access to sysmaps_pcpu[] should be atomic with respect to thread migration. Otherwise, a sysmaps for one CPU can be stolen by another CPU and the purpose of per CPU sysmaps is broken. A patch is enclosed. Svata Index: sys/i386/i386/pmap.c =================================================================== --- sys/i386/i386/pmap.c (revision 246831) +++ sys/i386/i386/pmap.c (working copy) @@ -4146,11 +4146,11 @@ { struct sysmaps *sysmaps; + sched_pin(); sysmaps = &sysmaps_pcpu[PCPU_GET(cpuid)]; mtx_lock(&sysmaps->lock); if (*sysmaps->CMAP2) panic("pmap_zero_page: CMAP2 busy"); - sched_pin(); *sysmaps->CMAP2 = PG_V | PG_RW | VM_PAGE_TO_PHYS(m) | PG_A | PG_M | pmap_cache_bits(m->md.pat_mode, 0); invlcaddr(sysmaps->CADDR2); @@ -4171,11 +4171,11 @@ { struct sysmaps *sysmaps; + sched_pin(); sysmaps = &sysmaps_pcpu[PCPU_GET(cpuid)]; mtx_lock(&sysmaps->lock); if (*sysmaps->CMAP2) panic("pmap_zero_page_area: CMAP2 busy"); - sched_pin(); *sysmaps->CMAP2 = PG_V | PG_RW | VM_PAGE_TO_PHYS(m) | PG_A | PG_M | pmap_cache_bits(m->md.pat_mode, 0); invlcaddr(sysmaps->CADDR2); @@ -4220,13 +4220,13 @@ { struct sysmaps *sysmaps; + sched_pin(); sysmaps = &sysmaps_pcpu[PCPU_GET(cpuid)]; mtx_lock(&sysmaps->lock); if (*sysmaps->CMAP1) panic("pmap_copy_page: CMAP1 busy"); if (*sysmaps->CMAP2) panic("pmap_copy_page: CMAP2 busy"); - sched_pin(); invlpg((u_int)sysmaps->CADDR1); invlpg((u_int)sysmaps->CADDR2); *sysmaps->CMAP1 = PG_V | VM_PAGE_TO_PHYS(src) | PG_A | @@ -5072,11 +5072,11 @@ vm_offset_t sva, eva; if ((cpu_feature & CPUID_CLFSH) != 0) { + sched_pin(); sysmaps = &sysmaps_pcpu[PCPU_GET(cpuid)]; mtx_lock(&sysmaps->lock); if (*sysmaps->CMAP2) panic("pmap_flush_page: CMAP2 busy"); - sched_pin(); *sysmaps->CMAP2 = PG_V | PG_RW | VM_PAGE_TO_PHYS(m) | PG_A | PG_M | pmap_cache_bits(m->md.pat_mode, 0); invlcaddr(sysmaps->CADDR2); From owner-freebsd-current@FreeBSD.ORG Mon Feb 18 13:03:26 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 88350115 for ; Mon, 18 Feb 2013 13:03:26 +0000 (UTC) (envelope-from mexas@bristol.ac.uk) Received: from dirj.bris.ac.uk (dirj.bris.ac.uk [137.222.10.78]) by mx1.freebsd.org (Postfix) with ESMTP id 2A15FAD6 for ; Mon, 18 Feb 2013 13:03:25 +0000 (UTC) Received: from irix.bris.ac.uk ([137.222.10.39] helo=ncs.bris.ac.uk) by dirj.bris.ac.uk with esmtp (Exim 4.72) (envelope-from ) id 1U7QNN-0001cd-FQ for freebsd-current@freebsd.org; Mon, 18 Feb 2013 13:03:25 +0000 Received: from mech-cluster241.men.bris.ac.uk ([137.222.187.241]) by ncs.bris.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1U7QNN-0000io-Bg for freebsd-current@freebsd.org; Mon, 18 Feb 2013 13:03:21 +0000 Received: from mech-cluster241.men.bris.ac.uk (localhost [127.0.0.1]) by mech-cluster241.men.bris.ac.uk (8.14.6/8.14.6) with ESMTP id r1ID3LOJ004511 for ; Mon, 18 Feb 2013 13:03:21 GMT (envelope-from mexas@mech-cluster241.men.bris.ac.uk) Received: (from mexas@localhost) by mech-cluster241.men.bris.ac.uk (8.14.6/8.14.6/Submit) id r1ID3KPi004510 for freebsd-current@freebsd.org; Mon, 18 Feb 2013 13:03:20 GMT (envelope-from mexas) Date: Mon, 18 Feb 2013 13:03:20 GMT From: Anton Shterenlikht Message-Id: <201302181303.r1ID3KPi004510@mech-cluster241.men.bris.ac.uk> To: freebsd-current@freebsd.org Subject: panic: Assertion t->t_cursor.tp_row <= t->t_winsize.tp_row failed at /usr/src/sys/teken/teken_subr.h:94 X-Spam-Score: -3.7 X-Spam-Level: --- X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: mexas@bristol.ac.uk List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2013 13:03:26 -0000 I got this panic when playing with the docking station for lenovo T61p. I tried to attach/detach it. I got a complete crash dump, but don't know what to do with it. root@zzz:/var/crash # cat info.1 Dump header from device /dev/ada0p3 Architecture: amd64 Architecture Version: 2 Dump Length: 357797888B (341 MB) Blocksize: 512 Dumptime: Mon Feb 18 11:51:27 2013 Hostname: zzz Magic: FreeBSD Kernel Dump Version String: FreeBSD 10.0-CURRENT #2 r246552: Fri Feb 15 20:41:10 GMT 2013 root@zzz:/usr/obj/usr/src/sys/MINKY Panic String: Assertion t->t_cursor.tp_row <= t->t_winsize.tp_row failed at /u sr/src/sys/teken/teken_subr.h:94 Dump Parity: 3806418789 Bounds: 1 Dump Status: good root@zzz:/var/crash # The core.txt: http://eis.bris.ac.uk/~mexas/core.txt.1 Please advise Thanks Anton From owner-freebsd-current@FreeBSD.ORG Mon Feb 18 15:08:25 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 5F112A12 for ; Mon, 18 Feb 2013 15:08:25 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id B0EAD295 for ; Mon, 18 Feb 2013 15:08:24 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.6/8.14.6) with ESMTP id r1IF8AUR019342; Mon, 18 Feb 2013 17:08:10 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.7.4 kib.kiev.ua r1IF8AUR019342 Received: (from kostik@localhost) by tom.home (8.14.6/8.14.6/Submit) id r1IF8AFE019341; Mon, 18 Feb 2013 17:08:10 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 18 Feb 2013 17:08:09 +0200 From: Konstantin Belousov To: Svatopluk Kraus Subject: Re: [patch] i386 pmap sysmaps_pcpu[] atomic access Message-ID: <20130218150809.GG2598@kib.kiev.ua> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="GdbWtwDHkcXqP16f" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 18 Feb 2013 15:08:25 -0000 --GdbWtwDHkcXqP16f Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Feb 18, 2013 at 01:44:35PM +0100, Svatopluk Kraus wrote: > Hi, >=20 > the access to sysmaps_pcpu[] should be atomic with respect to > thread migration. Otherwise, a sysmaps for one CPU can be stolen by > another CPU and the purpose of per CPU sysmaps is broken. A patch is > enclosed. And, what are the problem caused by the 'otherwise' ? I do not see any. Really, taking the mutex while bind to a CPU could be deadlock-prone under some situations. This was discussed at least one more time. Might be, a comment saying that there is no issue should be added. >=20 > Svata >=20 > Index: sys/i386/i386/pmap.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 > --- sys/i386/i386/pmap.c (revision 246831) > +++ sys/i386/i386/pmap.c (working copy) > @@ -4146,11 +4146,11 @@ > { > struct sysmaps *sysmaps; >=20 > + sched_pin(); > sysmaps =3D &sysmaps_pcpu[PCPU_GET(cpuid)]; > mtx_lock(&sysmaps->lock); > if (*sysmaps->CMAP2) > panic("pmap_zero_page: CMAP2 busy"); > - sched_pin(); > *sysmaps->CMAP2 =3D PG_V | PG_RW | VM_PAGE_TO_PHYS(m) | PG_A | PG_M | > pmap_cache_bits(m->md.pat_mode, 0); > invlcaddr(sysmaps->CADDR2); > @@ -4171,11 +4171,11 @@ > { > struct sysmaps *sysmaps; >=20 > + sched_pin(); > sysmaps =3D &sysmaps_pcpu[PCPU_GET(cpuid)]; > mtx_lock(&sysmaps->lock); > if (*sysmaps->CMAP2) > panic("pmap_zero_page_area: CMAP2 busy"); > - sched_pin(); > *sysmaps->CMAP2 =3D PG_V | PG_RW | VM_PAGE_TO_PHYS(m) | PG_A | PG_M | > pmap_cache_bits(m->md.pat_mode, 0); > invlcaddr(sysmaps->CADDR2); > @@ -4220,13 +4220,13 @@ > { > struct sysmaps *sysmaps; >=20 > + sched_pin(); > sysmaps =3D &sysmaps_pcpu[PCPU_GET(cpuid)]; > mtx_lock(&sysmaps->lock); > if (*sysmaps->CMAP1) > panic("pmap_copy_page: CMAP1 busy"); > if (*sysmaps->CMAP2) > panic("pmap_copy_page: CMAP2 busy"); > - sched_pin(); > invlpg((u_int)sysmaps->CADDR1); > invlpg((u_int)sysmaps->CADDR2); > *sysmaps->CMAP1 =3D PG_V | VM_PAGE_TO_PHYS(src) | PG_A | > @@ -5072,11 +5072,11 @@ > vm_offset_t sva, eva; >=20 > if ((cpu_feature & CPUID_CLFSH) !=3D 0) { > + sched_pin(); > sysmaps =3D &sysmaps_pcpu[PCPU_GET(cpuid)]; > mtx_lock(&sysmaps->lock); > if (*sysmaps->CMAP2) > panic("pmap_flush_page: CMAP2 busy"); > - sched_pin(); > *sysmaps->CMAP2 =3D PG_V | PG_RW | VM_PAGE_TO_PHYS(m) | > PG_A | PG_M | pmap_cache_bits(m->md.pat_mode, 0); > invlcaddr(sysmaps->CADDR2); > _______________________________________________ > 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" --GdbWtwDHkcXqP16f Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJRIkPZAAoJEJDCuSvBvK1B5JcP/RIJxvumbc5eMO4xE8z19rT/ jDjkcKCRUQMKkc0D2NrtI3La1jyj6Hgen7hL5HE4rZBZPm57pNXbF/L4rf7hCQtt yg0AJddHI+ZpBIhoDGpUTZA7P476hFckwcDe++3+eOe104JFVs4QbhnfjI3Duc2K fa+epN4gWeeKXI7GSm64T9XNfsSJXzhRq+fgvN6U5dTTY45oiz/LXqO7/Jz7yZVR gaGoIgSBWxaproCm0hvXCI5dQ0BHfimgvHQgtUGI9t9JyTVPVymjKMdcDUk55ksc e1v977j8nECWjlR0Jhq9WPeQaSVy/M0J12BJtdoRZL5Z4IEst8vd/a8s8XA98dV/ 77LDD6E6KJXhCrMG0TphEm1c2Kh1ZWn3YyjCFEUVpjJ4K7IUfK7J3sRKvCeilTzk bm2mQnkCvEMw7vsri/AZApBnNkCsYBDMj/B4PezfDIeSqEN0547MxpITLp43QwiU viLriUs9hPOrIdOQ7jgKaSL7Gr+G+/zHW4hBdOwhHi7TWcpov0NZbdJiAQTLeFJr v9NLglj2czAqAcspBf28UNm03y8M0ClItCC3MOTR936RLzgntKXcliFowcWKnW0b YoiODZECGTTA9DFB0GQtb28nrTQC3cXcQSVxAfz1iKD0ThqA5/r3CNV48+diOa+t I8JhVjY4CGJCexr46TCX =xOUl -----END PGP SIGNATURE----- --GdbWtwDHkcXqP16f-- From owner-freebsd-current@FreeBSD.ORG Mon Feb 18 16:06:15 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 5D5AB5BA for ; Mon, 18 Feb 2013 16:06:15 +0000 (UTC) (envelope-from lokedhs@gmail.com) Received: from mail-lb0-f181.google.com (mail-lb0-f181.google.com [209.85.217.181]) by mx1.freebsd.org (Postfix) with ESMTP id B5D59709 for ; Mon, 18 Feb 2013 16:06:14 +0000 (UTC) Received: by mail-lb0-f181.google.com with SMTP id gm6so4292225lbb.26 for ; Mon, 18 Feb 2013 08:06:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=AjYu5h10RZ3NCbIKTZaI/rhuz8QRF4I8ne5kbj9dQSs=; b=SAenXA2aqQwZTNlaKQ02hAyQnBMoNyHKlrwZsB2BSLdgfqZdHuuV1aSfOBhkQoWK9m xx3mOFnzK8DVPZWV3m0TEjHrGuHzA+2CSswYjM3bcJHuCgh8yaeCrn13mwMxhbQ3VNmR JfJAcQ0TUEihnD2B7uR11dtnC01ZsBYl2LkVNsoeiY8o1oE9XU9hDiHe+6AD99NM1jJl Vuju9A1ROxz08TFDaDdmED2GH/r9a9LcpBcImOUJFeookATGb5BsMSPIIBJUJ6Hw0qXy 96bUo2zZ7j4DyMFseCnBqjpgFOknkBryrpElMauCJ3+juJrvXKl1107j2tUxLnvTq+sW eemw== MIME-Version: 1.0 X-Received: by 10.112.26.10 with SMTP id h10mr5962539lbg.63.1361203573289; Mon, 18 Feb 2013 08:06:13 -0800 (PST) Received: by 10.112.41.68 with HTTP; Mon, 18 Feb 2013 08:06:13 -0800 (PST) In-Reply-To: <477291850.3084864.1361113135205.JavaMail.root@erie.cs.uoguelph.ca> References: <477291850.3084864.1361113135205.JavaMail.root@erie.cs.uoguelph.ca> Date: Tue, 19 Feb 2013 00:06:13 +0800 Message-ID: Subject: Re: Possible bug in NFSv4 with krb5p security? From: =?ISO-8859-1?Q?Elias_M=E5rtenson?= To: Rick Macklem Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-current@freebsd.org, Benjamin Kaduk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 18 Feb 2013 16:06:15 -0000 On 17 February 2013 22:58, Rick Macklem wrote: I think the Makefiles are in the kerberos5 directory. > > Since the only function you care about is the one in > kerberos5/lib/libgssapi_krb5/pname_to_uid.c, I'd > just put a copy of that file in usr.sbin/gssd and > modify the Makefile there to compile it and link > its .o into gssd, avoiding rebuilding any libraries. > > I'd put a couple of fprintf(stderr, ...) in it and > then run "gssd -d" and see what it says. > > Just how I'd attack it, rick Good news! The problem is solved! You were right, the problem was in pname_to_uid.c. In it, the following code can be found: char lname[MAXLOGNAME + 1], buf[1024]; /* some code snipped for brevity... */ getpwnam_r(lname, &pwd, buf, sizeof(buf), &pw); if (pw) { *uidp = pw->pw_uid; return (GSS_S_COMPLETE); } else { return (GSS_S_FAILURE); } As it turns out, the getpwnam_r() call fails with ERANGE (I had to check the return value from getpwnam_r() in order to determine this, as pw is set to NULL both if there was an error or if the user name can't be found). Now, increasing the size of buf to 1024 solved the problem, and now the lookup works correctly. I wrote a small test program that issued the same call to getpwnam_r() and it worked. Until I su'ed to root, and then it failed. It seems as though the buffer needs to be bigger if you're root. I have no idea why, but there you have it. Problem solved. Should this be fixed in the main codebase? Oh, and thanks so much to all of you for being patient with me while solving this. I really appreciate it. Also, I'd like to say that the code base was quite pleasant to work with. Thanks for that too. :-) Regards, Elias From owner-freebsd-current@FreeBSD.ORG Mon Feb 18 16:15:11 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 4DC6E78E for ; Mon, 18 Feb 2013 16:15:11 +0000 (UTC) (envelope-from lokedhs@gmail.com) Received: from mail-la0-x22b.google.com (la-in-x022b.1e100.net [IPv6:2a00:1450:4010:c03::22b]) by mx1.freebsd.org (Postfix) with ESMTP id D05A0789 for ; Mon, 18 Feb 2013 16:15:10 +0000 (UTC) Received: by mail-la0-f43.google.com with SMTP id ek20so5677695lab.16 for ; Mon, 18 Feb 2013 08:15:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=Ji1JxeInZv7FFzBC0muXhQLY6kGMq1n3GizNhOyN/JI=; b=TNQRpvGVeloyGhVpEjms8xX4W4b4KcfB+6dqUOuOPng/GxEFmj+UthAhWcWkZKxwrb UPnc+ZGp60ltmTAgtyL3cm+aggymRoCHX7iC+7DAKObfrjiBv6KG295zzDz9YzWHrwyB ibneZsPR9Mln7fRYyMM8oM7fALrDuqapqfrBC0yhbcm8Mc8KeG5iQMpLTxGoDFr1v6Gf qz4xS9dTobey/BXl5SSAHBDuzMhjzq1M1SjRbi4+fFap+be9Nzsn92R877/nrShERewQ VUO+ofbM6UQkc9JaLlMTNBjykCwHZvJy7TT1J4FZbi6YZH8Pc7XGE23bL5eGtgqLJUxm vBSQ== MIME-Version: 1.0 X-Received: by 10.112.37.194 with SMTP id a2mr5946926lbk.40.1361204109450; Mon, 18 Feb 2013 08:15:09 -0800 (PST) Received: by 10.112.41.68 with HTTP; Mon, 18 Feb 2013 08:15:09 -0800 (PST) In-Reply-To: References: <477291850.3084864.1361113135205.JavaMail.root@erie.cs.uoguelph.ca> Date: Tue, 19 Feb 2013 00:15:09 +0800 Message-ID: Subject: Re: Possible bug in NFSv4 with krb5p security? From: =?ISO-8859-1?Q?Elias_M=E5rtenson?= To: Rick Macklem Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-current@freebsd.org, Benjamin Kaduk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 18 Feb 2013 16:15:11 -0000 On 19 February 2013 00:06, Elias M=E5rtenson wrote: char lname[MAXLOGNAME + 1], buf[1024]; > Oops. Here I am, replying to myself. The above is a typo. That's by modified code. In the original source, buf is 128 bytes in size. Regards, Elias From owner-freebsd-current@FreeBSD.ORG Mon Feb 18 17:10:08 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 035FD5DF for ; Mon, 18 Feb 2013 17:10:08 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 6BD5BA16 for ; Mon, 18 Feb 2013 17:10:07 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.6/8.14.6) with ESMTP id r1IH9vob032859; Mon, 18 Feb 2013 19:09:57 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.7.4 kib.kiev.ua r1IH9vob032859 Received: (from kostik@localhost) by tom.home (8.14.6/8.14.6/Submit) id r1IH9vn8032858; Mon, 18 Feb 2013 19:09:57 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 18 Feb 2013 19:09:57 +0200 From: Konstantin Belousov To: Svatopluk Kraus Subject: Re: [patch] i386 pmap sysmaps_pcpu[] atomic access Message-ID: <20130218170957.GJ2598@kib.kiev.ua> References: <20130218150809.GG2598@kib.kiev.ua> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="tKy6e3LXpfmanBFM" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 18 Feb 2013 17:10:08 -0000 --tKy6e3LXpfmanBFM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Feb 18, 2013 at 06:06:42PM +0100, Svatopluk Kraus wrote: > On Mon, Feb 18, 2013 at 4:08 PM, Konstantin Belousov > wrote: > > On Mon, Feb 18, 2013 at 01:44:35PM +0100, Svatopluk Kraus wrote: > >> Hi, > >> > >> the access to sysmaps_pcpu[] should be atomic with respect to > >> thread migration. Otherwise, a sysmaps for one CPU can be stolen by > >> another CPU and the purpose of per CPU sysmaps is broken. A patch is > >> enclosed. > > And, what are the problem caused by the 'otherwise' ? > > I do not see any. >=20 > The 'otherwise' issue is the following: >=20 > 1. A thread is running on CPU0. >=20 > sysmaps =3D &sysmaps_pcpu[PCPU_GET(cpuid)]; >=20 > 2. A sysmaps variable contains a pointer to 'CPU0' sysmaps. > 3. Now, the thread migrates into CPU1. > 4. However, the sysmaps variable still contains a pointers to 'CPU0' sysm= aps. >=20 > mtx_lock(&sysmaps->lock); >=20 > 4. The thread running on CPU1 locked 'CPU0' sysmaps mutex, so the > thread uselessly can block another thread running on CPU0. Maybe, it's > not a problem. However, it definitely goes against the reason why the > submaps (one for each CPU) exist. So what ? >=20 >=20 > > Really, taking the mutex while bind to a CPU could be deadlock-prone > > under some situations. > > > > This was discussed at least one more time. Might be, a comment saying t= hat > > there is no issue should be added. >=20 > I missed the discussion. Can you point me to it, please? A deadlock is > not problem here, however, I can be wrong, as I can't imagine now how > a simple pinning could lead into a deadlock at all. Because some other load on the bind cpu might prevent the thread from being scheduled. >=20 > >> > >> Svata > >> > >> Index: sys/i386/i386/pmap.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 > >> --- sys/i386/i386/pmap.c (revision 246831) > >> +++ sys/i386/i386/pmap.c (working copy) > >> @@ -4146,11 +4146,11 @@ > >> { > >> struct sysmaps *sysmaps; > >> > >> + sched_pin(); > >> sysmaps =3D &sysmaps_pcpu[PCPU_GET(cpuid)]; > >> mtx_lock(&sysmaps->lock); > >> if (*sysmaps->CMAP2) > >> panic("pmap_zero_page: CMAP2 busy"); > >> - sched_pin(); > >> *sysmaps->CMAP2 =3D PG_V | PG_RW | VM_PAGE_TO_PHYS(m) | PG_A | P= G_M | > >> pmap_cache_bits(m->md.pat_mode, 0); > >> invlcaddr(sysmaps->CADDR2); > >> @@ -4171,11 +4171,11 @@ > >> { > >> struct sysmaps *sysmaps; > >> > >> + sched_pin(); > >> sysmaps =3D &sysmaps_pcpu[PCPU_GET(cpuid)]; > >> mtx_lock(&sysmaps->lock); > >> if (*sysmaps->CMAP2) > >> panic("pmap_zero_page_area: CMAP2 busy"); > >> - sched_pin(); > >> *sysmaps->CMAP2 =3D PG_V | PG_RW | VM_PAGE_TO_PHYS(m) | PG_A | P= G_M | > >> pmap_cache_bits(m->md.pat_mode, 0); > >> invlcaddr(sysmaps->CADDR2); > >> @@ -4220,13 +4220,13 @@ > >> { > >> struct sysmaps *sysmaps; > >> > >> + sched_pin(); > >> sysmaps =3D &sysmaps_pcpu[PCPU_GET(cpuid)]; > >> mtx_lock(&sysmaps->lock); > >> if (*sysmaps->CMAP1) > >> panic("pmap_copy_page: CMAP1 busy"); > >> if (*sysmaps->CMAP2) > >> panic("pmap_copy_page: CMAP2 busy"); > >> - sched_pin(); > >> invlpg((u_int)sysmaps->CADDR1); > >> invlpg((u_int)sysmaps->CADDR2); > >> *sysmaps->CMAP1 =3D PG_V | VM_PAGE_TO_PHYS(src) | PG_A | > >> @@ -5072,11 +5072,11 @@ > >> vm_offset_t sva, eva; > >> > >> if ((cpu_feature & CPUID_CLFSH) !=3D 0) { > >> + sched_pin(); > >> sysmaps =3D &sysmaps_pcpu[PCPU_GET(cpuid)]; > >> mtx_lock(&sysmaps->lock); > >> if (*sysmaps->CMAP2) > >> panic("pmap_flush_page: CMAP2 busy"); > >> - sched_pin(); > >> *sysmaps->CMAP2 =3D PG_V | PG_RW | VM_PAGE_TO_PHYS(m) | > >> PG_A | PG_M | pmap_cache_bits(m->md.pat_mode, 0); > >> invlcaddr(sysmaps->CADDR2); > >> _______________________________________________ > >> 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" --tKy6e3LXpfmanBFM Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJRImBlAAoJEJDCuSvBvK1B//oQAIMCufPgLM/CyH3EaA9ngDQb RlNOrGI6IZD38h9RX5fLbdsa1kakWcWFMFy9qxqpdNzWEF7r7tYt0N9/D6rxM8hB 2uUNIxhyGLTA6ZOgHKufauUQ7GMP4Eo8wUsehI1/smH6EpxmuSr3OMe7tJIOxzIx N1pveX1OZGixpojxQR6/zYIklZhbAIOuR6YYpO7mass8jm1XyxDWHSEGzE+x5Cdk H2bFwtaarwrDp02KrculRlxIqs2tLq7eeSD6fnDrUj1jDmY471TeaaOAxOkqd2Uy 78tbh6VGnNfT8lE28gLCIH2P2YnNDLhjn28wFy23Ltf6N2USvDmvmHQRqI3GWIU8 msoEg8axsKt/cA7dDotZE+Cbiq7cmby+H2VxHmZzL+PsiH23NpGhF6V9qtxj5RaF vS4XYnEuC4jWPPYIZouPDWiA8iWsnvcd2G521ZX6FSUhHcybS05vYbHr9QyJFEqw sNOl687yEv+z9yj3qc+bNMpnI7EjAmY98DzcbVtHp88cv0zAqRSDMY2xQKP1XWxX 5ZahBjc8da68ZZF98E2XGBiiKCU4hzpQi+XkzPUUdJ5Cwq3cEhBxCaED1JmHtYWw vTv004xPmfhDmtPcd9pMpE1GuK8N6qZP3xw/Yv1Os/8gA2pVcIT47xmVReOJEph7 vE1lYuc7Vrfst/KSKgFP =nHOR -----END PGP SIGNATURE----- --tKy6e3LXpfmanBFM-- From owner-freebsd-current@FreeBSD.ORG Mon Feb 18 17:34:10 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id DCA11A04 for ; Mon, 18 Feb 2013 17:34:10 +0000 (UTC) (envelope-from onwahe@gmail.com) Received: from mail-qe0-f51.google.com (mail-qe0-f51.google.com [209.85.128.51]) by mx1.freebsd.org (Postfix) with ESMTP id A3C68B23 for ; Mon, 18 Feb 2013 17:34:10 +0000 (UTC) Received: by mail-qe0-f51.google.com with SMTP id 6so2557950qea.24 for ; Mon, 18 Feb 2013 09:34:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=n/dbKeHdMBK5TVM6p5WLOl5jxC2RNdNIxoHvUZsiO6g=; b=pqCr+H7EyQqKDw0lF7EtZplfYyUyN2sTXi3uWzUSu3stoHDJkE0nU77utZYs/fIZ12 ejhtP5wCeoyM+oM5Ks5OeE4N6UBvQYN6YSZNOxAyqLSyTjWe1QlJiL2lX+XtedlzJPwc VC4qDT8vAMU/USa1zfDCO7Hrmza7N2NXx1+3cG1nGJwmoY9F5uCBZaBpiNVvV6yJWbRw Iye1ErGBV/GYIhg6YVPXrBEzvdh/7huOiErIAWPn8QumEOSJx5RATInlNt92SMmNIf5p B8eo0wvFQS6SL1bS+Vs5z2VDY6ROqShoMy55vzmuw5R3FptdvAYiWX+h2f7zRLeoSzae 6tkA== MIME-Version: 1.0 X-Received: by 10.49.105.73 with SMTP id gk9mr5547956qeb.40.1361207202501; Mon, 18 Feb 2013 09:06:42 -0800 (PST) Received: by 10.49.121.198 with HTTP; Mon, 18 Feb 2013 09:06:42 -0800 (PST) In-Reply-To: <20130218150809.GG2598@kib.kiev.ua> References: <20130218150809.GG2598@kib.kiev.ua> Date: Mon, 18 Feb 2013 18:06:42 +0100 Message-ID: Subject: Re: [patch] i386 pmap sysmaps_pcpu[] atomic access From: Svatopluk Kraus To: Konstantin Belousov Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 18 Feb 2013 17:34:10 -0000 On Mon, Feb 18, 2013 at 4:08 PM, Konstantin Belousov wrote: > On Mon, Feb 18, 2013 at 01:44:35PM +0100, Svatopluk Kraus wrote: >> Hi, >> >> the access to sysmaps_pcpu[] should be atomic with respect to >> thread migration. Otherwise, a sysmaps for one CPU can be stolen by >> another CPU and the purpose of per CPU sysmaps is broken. A patch is >> enclosed. > And, what are the problem caused by the 'otherwise' ? > I do not see any. The 'otherwise' issue is the following: 1. A thread is running on CPU0. sysmaps = &sysmaps_pcpu[PCPU_GET(cpuid)]; 2. A sysmaps variable contains a pointer to 'CPU0' sysmaps. 3. Now, the thread migrates into CPU1. 4. However, the sysmaps variable still contains a pointers to 'CPU0' sysmaps. mtx_lock(&sysmaps->lock); 4. The thread running on CPU1 locked 'CPU0' sysmaps mutex, so the thread uselessly can block another thread running on CPU0. Maybe, it's not a problem. However, it definitely goes against the reason why the submaps (one for each CPU) exist. > Really, taking the mutex while bind to a CPU could be deadlock-prone > under some situations. > > This was discussed at least one more time. Might be, a comment saying that > there is no issue should be added. I missed the discussion. Can you point me to it, please? A deadlock is not problem here, however, I can be wrong, as I can't imagine now how a simple pinning could lead into a deadlock at all. >> >> Svata >> >> Index: sys/i386/i386/pmap.c >> =================================================================== >> --- sys/i386/i386/pmap.c (revision 246831) >> +++ sys/i386/i386/pmap.c (working copy) >> @@ -4146,11 +4146,11 @@ >> { >> struct sysmaps *sysmaps; >> >> + sched_pin(); >> sysmaps = &sysmaps_pcpu[PCPU_GET(cpuid)]; >> mtx_lock(&sysmaps->lock); >> if (*sysmaps->CMAP2) >> panic("pmap_zero_page: CMAP2 busy"); >> - sched_pin(); >> *sysmaps->CMAP2 = PG_V | PG_RW | VM_PAGE_TO_PHYS(m) | PG_A | PG_M | >> pmap_cache_bits(m->md.pat_mode, 0); >> invlcaddr(sysmaps->CADDR2); >> @@ -4171,11 +4171,11 @@ >> { >> struct sysmaps *sysmaps; >> >> + sched_pin(); >> sysmaps = &sysmaps_pcpu[PCPU_GET(cpuid)]; >> mtx_lock(&sysmaps->lock); >> if (*sysmaps->CMAP2) >> panic("pmap_zero_page_area: CMAP2 busy"); >> - sched_pin(); >> *sysmaps->CMAP2 = PG_V | PG_RW | VM_PAGE_TO_PHYS(m) | PG_A | PG_M | >> pmap_cache_bits(m->md.pat_mode, 0); >> invlcaddr(sysmaps->CADDR2); >> @@ -4220,13 +4220,13 @@ >> { >> struct sysmaps *sysmaps; >> >> + sched_pin(); >> sysmaps = &sysmaps_pcpu[PCPU_GET(cpuid)]; >> mtx_lock(&sysmaps->lock); >> if (*sysmaps->CMAP1) >> panic("pmap_copy_page: CMAP1 busy"); >> if (*sysmaps->CMAP2) >> panic("pmap_copy_page: CMAP2 busy"); >> - sched_pin(); >> invlpg((u_int)sysmaps->CADDR1); >> invlpg((u_int)sysmaps->CADDR2); >> *sysmaps->CMAP1 = PG_V | VM_PAGE_TO_PHYS(src) | PG_A | >> @@ -5072,11 +5072,11 @@ >> vm_offset_t sva, eva; >> >> if ((cpu_feature & CPUID_CLFSH) != 0) { >> + sched_pin(); >> sysmaps = &sysmaps_pcpu[PCPU_GET(cpuid)]; >> mtx_lock(&sysmaps->lock); >> if (*sysmaps->CMAP2) >> panic("pmap_flush_page: CMAP2 busy"); >> - sched_pin(); >> *sysmaps->CMAP2 = PG_V | PG_RW | VM_PAGE_TO_PHYS(m) | >> PG_A | PG_M | pmap_cache_bits(m->md.pat_mode, 0); >> invlcaddr(sysmaps->CADDR2); >> _______________________________________________ >> 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 Mon Feb 18 18:42:35 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 3B35C9AA for ; Mon, 18 Feb 2013 18:42:35 +0000 (UTC) (envelope-from jeffreybouquet@yahoo.com) Received: from nm12-vm6.bullet.mail.gq1.yahoo.com (nm12-vm6.bullet.mail.gq1.yahoo.com [98.136.218.205]) by mx1.freebsd.org (Postfix) with SMTP id EBCD0E94 for ; Mon, 18 Feb 2013 18:42:34 +0000 (UTC) Received: from [98.137.12.62] by nm12.bullet.mail.gq1.yahoo.com with NNFMP; 18 Feb 2013 18:42:28 -0000 Received: from [98.137.12.243] by tm7.bullet.mail.gq1.yahoo.com with NNFMP; 18 Feb 2013 18:42:28 -0000 Received: from [127.0.0.1] by omp1051.mail.gq1.yahoo.com with NNFMP; 18 Feb 2013 18:42:28 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 757798.82933.bm@omp1051.mail.gq1.yahoo.com Received: (qmail 93638 invoked by uid 60001); 18 Feb 2013 18:42:28 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1361212948; bh=1nVk44JLmbYod/pw3UUWWIxDgvxIvfMDK4Lq37ivGj0=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=ukuViqLbmxgJOlyM8rFCw7FXAOIOkpuFyeUIUzPCsM/TgIWBWJ/RVDIHmOWojRE+nubr3NkgJthE0LHsSQy5JyYig3sJouNwOrQI+TgxCAP/BlRCQeWXcblF7SgNy5AVbH5KE0VEE9vdxiLASaNnY8iZchubzhux7zG0kz9M7Ms= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=WFjsQ8d+pHjb+FhdvOPsAHcXRnLKGbUTBy6/tUnA5xaAY9LEaLd4KkKQ9BKd39mc1IFcnd0/eAFbeAZ2xo3vxhyrZ589QAunSOkBGNbuAKUf0CGB70GSZ9Er04IAXbc/XPv7FUMhFOvlRsN9oBiOlSA1AJeQRDhU2Xn8j9q3spU=; X-YMail-OSG: DylQYoUVM1kqSAzLSIRamrKXae27bN7xke99_eW.2o.dja2 LeGYOHE9MfkEdYMofxp1KnmNsKo9hEtmw9hFUSRowvJDyZmgQo3g1Hmk83OB RZdat1rbbRnDcwfxeO1_izVixr_5rORHgzvoC5Uks.p1p8ErAQuwmLFRffDr sNlz8F3ucLNNs68b2HZFDnlrtoIUUockKcnmujLh2KOHjxpmzBnd.Z3yh7sn yxH4ZK_ur.luUw0uRBEXzQBz_j29V8h1kjhNllDplGbR6QvmjTvfKy1koGtc 4m1aZeLR0tt0nwnzbZ9pfPm2Beii1PlzBDo7nbf9gN60kAvD4DRburKbru1n dWgQ8mwDmzYchuU2aWOUgQGXmd2.tPO5HHOnmDC8_A__MSEiEHl.Zxtysgqr 0gwOtoO8BP_eumdqb0Wm56wSiMkhCAEvnT8f4UkYlH2.nkb_I1hPlGVBMgiS mllC6PRrYfYhiVSCLH3Hd_LuNFBLNo3h417SDjBT3xn8ykgk7EeHzNHgx6DV cRGdRYpRxsPg17wfcwMkCZnhjctAeMHeUyuQBUQHyyEzdt168PjAbZX9mRmP G Received: from [66.92.43.99] by web164004.mail.gq1.yahoo.com via HTTP; Mon, 18 Feb 2013 10:42:28 PST X-Rocket-MIMEInfo: 001.001, DQoNCi0tLSBPbiBNb24sIDIvMTgvMTMsIENocmlzIFJlZXMgPHV0aXNvZnRAZ21haWwuY29tPiB3cm90ZToNCg0KRnJvbTogQ2hyaXMgUmVlcyA8dXRpc29mdEBnbWFpbC5jb20.DQpTdWJqZWN0OiBSZTogSXMgdGhlcmUgYW4gZWFzeSB3YXkgdG8gZmluZCBvdXQgd2hpY2ggcG9ydCBsb2FkcyB3aGljaCBsaWJyYXJ5Pw0KVG86ICJKZWZmcmV5IEJvdXF1ZXQiIDxqZWZmcmV5Ym91cXVldEB5YWhvby5jb20.DQpDYzogIkZyZWVCU0QgTWFpbGluZyBMaXN0IiA8ZnJlZWJzZC1wb3J0c0BmcmVlYnNkLm9yZz4NCkQBMAEBAQE- X-Mailer: YahooMailClassic/15.1.2 YahooMailWebService/0.8.134.513 Message-ID: <1361212948.92531.YahooMailClassic@web164004.mail.gq1.yahoo.com> Date: Mon, 18 Feb 2013 10:42:28 -0800 (PST) From: Jeffrey Bouquet Subject: Re: Is there an easy way to find out which port loads which library? To: Chris Rees , freebsd-ports@freebsd.org, freebsd-current@freebsd.org In-Reply-To: MIME-Version: 1.0 X-Mailman-Approved-At: Mon, 18 Feb 2013 18:48:59 +0000 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 18 Feb 2013 18:42:35 -0000 --- On Mon, 2/18/13, Chris Rees wrote: From: Chris Rees Subject: Re: Is there an easy way to find out which port loads which librar= y? To: "Jeffrey Bouquet" Cc: "FreeBSD Mailing List" Date: Monday, February 18, 2013, 1:01 AM On 18 Feb 2013 05:35, "Jeffrey Bouquet" wrote: > > > >=20 > >Subject: Re: Is there an easy way to find out which port loads which library? >=20 > >Bernard Higonnet wrote: > > > Is there a simple, direct, complete, and unequivocal way to find out > > which port(s) install which libraries? > > >Something like this perhaps? > ># grep libfoobar.so /usr/ports/*/*/pkg-plist > > >AvW > > None of these replies mention > pkg which /usr/local/lib/libfoobar.so > pkg_which /usr/local/lib/libfoobar.so > ... > I typically use one or both (still using /var/db/pkg after running pkg2ng once a > long time ago...) >Why??? >Chris Unsure of the question. Why did I run pkg2ng?=A0 I was uncognizant of all the immediate consequence= s. Why did I revert?=A0 Not ready to make /var/db/pkg disappear until I've see= n=20 guides explaining the new usages which fit the present workflow here... Why do not I implement it at this time?=A0 I've still too much to do in the= short term on a daily basis vs. implement anything new until I am one of the *last* to= do so, so I would do it in the quickest and most expedient manner.=20 pkg_delete -f /var/db/pkg/rubygem-mime-types-1.19 && pkg_add rubygem-mime-t= ypes-1.21.tbz. I don't have to know the 1.19 (the shell does).=A0 I do not recall anyone m= entioning how the equivalent would work in a pkg system.=A0 They may have, but if it was a re= ply, I archived it somewhere, as I would prefer to switch all the machines I use w= eekly all at once, and prefer to wait as long as expedient. That works on legacy laptops as well as modern 4-core CPU, aided by the she= ll doing expansion, and I can type it without thinking, aided by the shell. The subdirectory is directly available to grep, awk, less... without an .so= . I've not yet had time to implement a /var/db/pkg/ on=A0 a machine running p= kg (by script maybe) so that it could continue. I've posted several times why the progress of /pkg/ has not been shown to [= 1] not slow down the workflow to which I am accustomed to upgrade multiple = machines has not been reliably demonstrated... and edge cases in which the = legacy method is preferable.=A0 Unfortunately, I ran out of time a long time ago to respond = more in depth; my views on the matter are scattered in the lists archives and forum= archives [further content redacted so as to not waste anyone's time.] J. Bouquet [1] I am not asking for anyone's efforts,=20 nor trying to sound negative; just trying to respond to the question with a wait-and-see=20 viewpoint... From owner-freebsd-current@FreeBSD.ORG Mon Feb 18 19:30:20 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id B2926A6F for ; Mon, 18 Feb 2013 19:30:20 +0000 (UTC) (envelope-from nick@van-laarhoven.org) Received: from vps.van-laarhoven.org (www.hibma.org [178.21.117.90]) by mx1.freebsd.org (Postfix) with ESMTP id 3520A154 for ; Mon, 18 Feb 2013 19:30:19 +0000 (UTC) Received: from hitske-lan.fritz.box (thuis.van-laarhoven.org [80.100.41.4]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by vps.van-laarhoven.org (Postfix) with ESMTPSA id 0470A5262A9 for ; Mon, 18 Feb 2013 20:28:27 +0100 (CET) From: Nick Hibma Subject: No console, not even serial, does not work (init fails) Message-Id: <96A2B40B-4191-4C4F-8AA5-39526E252D40@van-laarhoven.org> Date: Mon, 18 Feb 2013 20:30:11 +0100 To: =?windows-1252?Q?=93FreeBSD_Current_Mailing_List=94?= Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 18 Feb 2013 19:30:20 -0000 We run our NanoBSD images on Soekris and ALIX hardware. In some cases we = need all available serial ports for other hardware like GPS, and modems. = The boards have no video, so with all serial ports unavailable as a = console no other console is available. The problem is that FreeBSD does not handle well the case where there is = no console at all: 1) http://www.freebsd.org/cgi/query-pr.cgi?pr=3Dbin/102515 fsck_ufs crashes (6.1-STABLE). Because of the unitialised console libc = somehow gets corrupted and crashes fsck_ufs. This problem can be = circumvented by replacing 'fsck -p' with 'fsck < /dev/null > /dev/null'. 2) In 8.3-RELEASE init exits prematurely because it cannot open = /dev/console for reading and writing in setctty(). Removing the calls to = _exit(1) in that function makes the boot complete. I haven't checked = whether the fsck_ufs problem still appears as our builds run with a = patched rc.d script. As far as I can see this is still a problem in CURRENT. My attempt at resolving this was to create a null terminal in = dev/null/null.c, see the patch below, but that did not work as expected. = After booting the system with a modified init the response to 'echo > = /dev/console' was 'Device not configured'. I've added another CN_* = priority to make sure a null console does not take precedence over for = example gdb console. Any pointers as to who/how to resolve this issue? Any reason why the = null console approach does not work? Nick Hibma nick@van-laarhoven.org GTD: Time management for chaotic people. Index: /usr/src/sys/sys/cons.h =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 --- /usr/src/sys/sys/cons.h (revision 242660) +++ /usr/src/sys/sys/cons.h (working copy) @@ -69,10 +69,11 @@ =20 /* values for cn_pri - reflect our policy for console selection */ #define CN_DEAD 0 /* device doesn't exist */ -#define CN_LOW 1 /* device is a last restort only */ -#define CN_NORMAL 2 /* device exists but is nothing special = */ -#define CN_INTERNAL 3 /* "internal" bit-mapped display */ -#define CN_REMOTE 4 /* serial interface with remote bit set = */ +#define CN_NULL 1 /* no console at all */ +#define CN_LOW 2 /* device is a last restort only */ +#define CN_NORMAL 3 /* device exists but is nothing special = */ +#define CN_INTERNAL 4 /* "internal" bit-mapped display */ +#define CN_REMOTE 5 /* serial interface with remote bit set = */ =20 /* Values for cn_flags. */ #define CN_FLAG_NODEBUG 0x00000001 /* Not supported with = debugger. */ Index: /usr/src/sys/dev/null/null.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 --- /usr/src/sys/dev/null/null.c (revision 242660) +++ /usr/src/sys/dev/null/null.c (working copy) @@ -41,6 +41,9 @@ #include #include =20 +#include +#include + #include =20 /* For use with destroy_dev(9). */ @@ -173,3 +176,45 @@ =20 DEV_MODULE(null, null_modevent, NULL); MODULE_VERSION(null, 1); + +static cn_probe_t null_cnprobe; +static cn_init_t null_cninit; +static cn_term_t null_cnterm; +static cn_getc_t null_cngetc; +static cn_putc_t null_cnputc; + +CONSOLE_DRIVER(null); + +static void +null_cnprobe(struct consdev *cp) +{ + sprintf(cp->cn_name, "null"); + cp->cn_pri =3D CN_NULL; +} + +static void +null_cninit(struct consdev *cp) +{ +} + + +static void +null_cnputc(struct consdev *cp, int c) +{ + (void) cp; + + (void) c; +} + +static int +null_cngetc(struct consdev * cp) +{ + (void) cp; +=09 + return -1; +} + +static void +null_cnterm(struct consdev * cp) +{ +} From owner-freebsd-current@FreeBSD.ORG Mon Feb 18 19:29:47 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id B07FF993; Mon, 18 Feb 2013 19:29:47 +0000 (UTC) (envelope-from fonz@skysmurf.nl) Received: from spectrum.skysmurf.nl (spectrum.skysmurf.nl [82.95.125.145]) by mx1.freebsd.org (Postfix) with ESMTP id 1DAFB141; Mon, 18 Feb 2013 19:29:46 +0000 (UTC) Received: from spectrum.skysmurf.nl (localhost [127.0.0.1]) by spectrum.skysmurf.nl (8.14.4/8.14.4) with ESMTP id r1IJTeRO069563; Mon, 18 Feb 2013 20:29:40 +0100 (CET) (envelope-from fonz@spectrum.skysmurf.nl) Received: (from fonz@localhost) by spectrum.skysmurf.nl (8.14.4/8.14.4/Submit) id r1IJTel1069562; Mon, 18 Feb 2013 20:29:40 +0100 (CET) (envelope-from fonz) Date: Mon, 18 Feb 2013 20:29:40 +0100 From: "A.J. 'Fonz' van Werven" To: Jeffrey Bouquet Subject: Re: Is there an easy way to find out which port loads which library? Message-ID: <20130218192940.GA69551@spectrum.skysmurf.nl> References: <1361212948.92531.YahooMailClassic@web164004.mail.gq1.yahoo.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="M9NhX3UHpAaciwkO" Content-Disposition: inline In-Reply-To: <1361212948.92531.YahooMailClassic@web164004.mail.gq1.yahoo.com> User-Agent: Mutt/1.4.2.3i X-PGP-Key: http://www.skysmurf.nl/pgp/fonz.asc X-Mailman-Approved-At: Mon, 18 Feb 2013 19:54:20 +0000 Cc: freebsd-current@freebsd.org, freebsd-ports@freebsd.org, Chris Rees X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 18 Feb 2013 19:29:47 -0000 --M9NhX3UHpAaciwkO Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Not answering anyone in particular, but I feel compelled to point out that as far as I know pkg_info only works with packages/ports that are already installed (or at least created/downloaded), whereas the grep/find method also works for finding out which not-yet-installed package/port *will* install a certain file. But do of course correct me if I'm mistaken. AvW --=20 I'm not completely useless, I can be used as a bad example. --M9NhX3UHpAaciwkO Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJRIoEkAAoJEAfP7gJTaCe83rIP/300Q8rzyhUni3tN+Knsn0cX NwRLS5sW4DegMPdegYGyWkpWFmhzPw12KSognQ5o3oqIXgf7Ki6cZvMKY5EPsldM ENSq/C7s5/9+52IPT8mRtpn/nozRXPdDvoGlVBDKnHA73ni5gMP3OSUC+2Vrdcdr 5tXuMueE0glM2s3rqMrYm4L3aL1Cz5FM9diQEpVYIGprDb6zs0GWhgJu6ylAgsx+ 94pkRC2E2RdMuj8+yBMpAmjEvgw2ur4F8MAmUM6wNuj49LYNhq5L2b63wqtCicDC KaaTszQ954IG/ovcIdOhfgO0mrVeTcwI9nLu3jwIoAA5uiTx9Ye+7VHSFDZ74NP2 CoaM+4kPk7lROIU6jq1sMROHRJ4f4yHhdw7dPVYLMaFt2r6231+fWu8kYEAoTnCR R8Kxq4je/TrH/+ZJcKENthUTY8py08VkQ1aV32GiwXjBC1Ltd1V4aB5dVvhQhj9c WOJesDfv5hcjJOPxhfxupfG/063ln2YQN5KUm6KSkvgNzTBySoagtQW/k3wO8aSV aGCmNQiBLV33EkevRiWakOJAz3R2NbG/SCplmvq0BVwxBk+npeA1mdGObu6h7sHA HHS/GcusKoKJNg/M+FJqyEVFgNV3fwwIRloYZj41sLZrQ7IrPqdJY7PQ3cwaGVlF oN2sOryssv04WnqF8WPt =J2ZY -----END PGP SIGNATURE----- --M9NhX3UHpAaciwkO-- From owner-freebsd-current@FreeBSD.ORG Mon Feb 18 20:18:21 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 9722A9D2; Mon, 18 Feb 2013 20:18:21 +0000 (UTC) (envelope-from utisoft@gmail.com) Received: from mail-ee0-f52.google.com (mail-ee0-f52.google.com [74.125.83.52]) by mx1.freebsd.org (Postfix) with ESMTP id CD0D7373; Mon, 18 Feb 2013 20:18:20 +0000 (UTC) Received: by mail-ee0-f52.google.com with SMTP id b15so2966187eek.25 for ; Mon, 18 Feb 2013 12:18:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=6yQD+hFmVrfuH7rny4KRNWYIMuk63ZY/eYFLhPjQAyY=; b=Ve5SAQUMkh/nzTqyZXWnf8jlK6E+8bJAwS4Fu7XEDxittNhKq6+yFE2RJO4Bw1FDYP 57LZ9bDAlaRy8g0+ibOWxCv+6FYl6z9RuETX+5W0yI6txsNLmXU1MlAFdiwR64CPoqyz r8yysGLoMPY3gWXYclpBs7BKoQXvN+TviBndncE7SE8J3b/9LMVTLl/DcIDXnvcXjBt5 4MhRQjdE1NNWcMbCu1NezH/3oUyRxAZrnNQ1oKu/Esm9tNvEGtOm3lEF4BYEwGeFiTpY og23AO/mIb1TVyIBHNCtqbZRgnqTxnnLzdEWtTuuKe2rvgBDJCIbnaATAC+rdiAd/Y1Z UHQw== X-Received: by 10.14.175.70 with SMTP id y46mr48253230eel.6.1361218693815; Mon, 18 Feb 2013 12:18:13 -0800 (PST) MIME-Version: 1.0 Received: by 10.14.124.7 with HTTP; Mon, 18 Feb 2013 12:17:43 -0800 (PST) In-Reply-To: <1361212948.92531.YahooMailClassic@web164004.mail.gq1.yahoo.com> References: <1361212948.92531.YahooMailClassic@web164004.mail.gq1.yahoo.com> From: Chris Rees Date: Mon, 18 Feb 2013 20:17:43 +0000 Message-ID: Subject: Re: Is there an easy way to find out which port loads which library? To: Jeffrey Bouquet Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current , FreeBSD Mailing List X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 18 Feb 2013 20:18:21 -0000 On 18 Feb 2013 18:42, "Jeffrey Bouquet" wrote: > > > > --- On Mon, 2/18/13, Chris Rees wrote: >> >> >> From: Chris Rees >> >> Subject: Re: Is there an easy way to find out which port loads which library? >> To: "Jeffrey Bouquet" >> Cc: "FreeBSD Mailing List" >> Date: Monday, February 18, 2013, 1:01 AM >> >> On 18 Feb 2013 05:35, "Jeffrey Bouquet" wrote: >> > >> > >> > >> > >> > >Subject: Re: Is there an easy way to find out which port loads which >> library? >> > >> > >Bernard Higonnet wrote: >> > >> > > Is there a simple, direct, complete, and unequivocal way to find out >> > > which port(s) install which libraries? >> > >> > >Something like this perhaps? >> > ># grep libfoobar.so /usr/ports/*/*/pkg-plist >> > >> > >AvW >> > >> > None of these replies mention >> > pkg which /usr/local/lib/libfoobar.so >> > pkg_which /usr/local/lib/libfoobar.so >> > ... >> > I typically use one or both (still using /var/db/pkg after running pkg2ng >> once a >> > long time ago...) >> >> >Why??? >> >> >Chris >> >> Unsure of the question. >> >> Why did I run pkg2ng? I was uncognizant of all the immediate consequences. >> Why did I revert? Not ready to make /var/db/pkg disappear until I've seen >> guides explaining the new usages which fit the present workflow here... >> >> Why do not I implement it at this time? I've still too much to do in the short term >> on a daily basis vs. implement anything new until I am one of the *last* to do so, so I would do it in the quickest and most expedient manner. >> >> >> pkg_delete -f /var/db/pkg/rubygem-mime-types-1.19 && pkg_add rubygem-mime-types-1.21.tbz. >> I don't have to know the 1.19 (the shell does). I do not recall anyone mentioning how the >> equivalent would work in a pkg system. They may have, but if it was a reply, I >> archived it somewhere, as I would prefer to switch all the machines I use weekly >> all at once, and prefer to wait as long as expedient. You can use pkg delete -x rubygem-mime-types, or pkg update && pkg upgrade is really what you need there. >> That works on legacy laptops as well as modern 4-core CPU, aided by the shell doing expansion, and I can type it without thinking, aided by the shell. >> The subdirectory is directly available to grep, awk, less... without an .so. >> I've not yet had time to implement a /var/db/pkg/ on a machine running pkg >> (by script maybe) so that it could continue. Man pkg-query, but see below. >> I've posted several times why the progress of /pkg/ has not been shown to [1] not slow down the workflow to which I am accustomed to upgrade multiple machines has not been reliably demonstrated... and edge cases in which the legacy method is >> preferable. Unfortunately, I ran out of time a long time ago to respond more in >> depth; my views on the matter are scattered in the lists archives and forum archives >> [further content redacted so as to not waste anyone's time.] Shell autocomplete should be pretty easy to implement should you choose, but given that many of the steps you describe are automated anyway, it's hard to see any real advantage to manually manipulating the data! Rather than describing your current methods, you may be better off (in a new thread) describing the *outcomes* that you would like, and we can help you achieve them. Chris From owner-freebsd-current@FreeBSD.ORG Mon Feb 18 20:27:42 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 0060AEEC for ; Mon, 18 Feb 2013 20:27:41 +0000 (UTC) (envelope-from onwahe@gmail.com) Received: from mail-qe0-f49.google.com (mail-qe0-f49.google.com [209.85.128.49]) by mx1.freebsd.org (Postfix) with ESMTP id BD3B8620 for ; Mon, 18 Feb 2013 20:27:41 +0000 (UTC) Received: by mail-qe0-f49.google.com with SMTP id 5so2648766qea.22 for ; Mon, 18 Feb 2013 12:27:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=XLrsWld1oo43LPdfv68K5RO9QVyv5/kWCT3iomBMkrs=; b=ispEaPfFnuuVeU860+Wx9eGDMi6GyckWX4pBEaaQzKD6+ZjL38F5inAXZ331lu3ReL lSEZ07YzB5Lw9ZdO4AQqZs3UKcYQUxwgVq9xkcxI4Fj5KRXUnmWmEuJjnL6wegxC4/2R oMmsfVjO99EKPT9pYj2s5eTatZz23QkmpUu/UGjXHNzwfBb3CTuhRc4DCaz3+PQHm3Be Dbg/HHNK7PUw7v/LxjANn/4ZcDJKc2pgzi7y5JOvKv92P422UnEY/1jRqYwsR0yZ/ACS Z0UTcKq/6v7sZxKbcagAj1dVie8oCLRtycMtjsWfk9j/PO0WZRI/jHu1VIK2Wr28boIg 01fA== MIME-Version: 1.0 X-Received: by 10.49.108.9 with SMTP id hg9mr5682352qeb.34.1361219260816; Mon, 18 Feb 2013 12:27:40 -0800 (PST) Received: by 10.49.121.198 with HTTP; Mon, 18 Feb 2013 12:27:40 -0800 (PST) In-Reply-To: <20130218170957.GJ2598@kib.kiev.ua> References: <20130218150809.GG2598@kib.kiev.ua> <20130218170957.GJ2598@kib.kiev.ua> Date: Mon, 18 Feb 2013 21:27:40 +0100 Message-ID: Subject: Re: [patch] i386 pmap sysmaps_pcpu[] atomic access From: Svatopluk Kraus To: Konstantin Belousov Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 18 Feb 2013 20:27:42 -0000 On Mon, Feb 18, 2013 at 6:09 PM, Konstantin Belousov wrote: > On Mon, Feb 18, 2013 at 06:06:42PM +0100, Svatopluk Kraus wrote: >> On Mon, Feb 18, 2013 at 4:08 PM, Konstantin Belousov >> wrote: >> > On Mon, Feb 18, 2013 at 01:44:35PM +0100, Svatopluk Kraus wrote: >> >> Hi, >> >> >> >> the access to sysmaps_pcpu[] should be atomic with respect to >> >> thread migration. Otherwise, a sysmaps for one CPU can be stolen by >> >> another CPU and the purpose of per CPU sysmaps is broken. A patch is >> >> enclosed. >> > And, what are the problem caused by the 'otherwise' ? >> > I do not see any. >> >> The 'otherwise' issue is the following: >> >> 1. A thread is running on CPU0. >> >> sysmaps = &sysmaps_pcpu[PCPU_GET(cpuid)]; >> >> 2. A sysmaps variable contains a pointer to 'CPU0' sysmaps. >> 3. Now, the thread migrates into CPU1. >> 4. However, the sysmaps variable still contains a pointers to 'CPU0' sysmaps. >> >> mtx_lock(&sysmaps->lock); >> >> 4. The thread running on CPU1 locked 'CPU0' sysmaps mutex, so the >> thread uselessly can block another thread running on CPU0. Maybe, it's >> not a problem. However, it definitely goes against the reason why the >> submaps (one for each CPU) exist. > So what ? It depends. You don't understand it or you think it's ok? Tell me. >> >> >> > Really, taking the mutex while bind to a CPU could be deadlock-prone >> > under some situations. >> > >> > This was discussed at least one more time. Might be, a comment saying that >> > there is no issue should be added. >> >> I missed the discussion. Can you point me to it, please? A deadlock is >> not problem here, however, I can be wrong, as I can't imagine now how >> a simple pinning could lead into a deadlock at all. > Because some other load on the bind cpu might prevent the thread from > being scheduled. I'm afraid I still have no idea. On single CPU, a binding has no meaning. Thus, if any deadlock exists then exists without binding too. Hmm, you are talking about a deadlock caused by heavy CPU load? Is it a deadlock at all? Anyhow, mutex is a lock with priority propagation, isn't it? > >> >> >> >> >> Svata >> >> >> >> Index: sys/i386/i386/pmap.c >> >> =================================================================== >> >> --- sys/i386/i386/pmap.c (revision 246831) >> >> +++ sys/i386/i386/pmap.c (working copy) >> >> @@ -4146,11 +4146,11 @@ >> >> { >> >> struct sysmaps *sysmaps; >> >> >> >> + sched_pin(); >> >> sysmaps = &sysmaps_pcpu[PCPU_GET(cpuid)]; >> >> mtx_lock(&sysmaps->lock); >> >> if (*sysmaps->CMAP2) >> >> panic("pmap_zero_page: CMAP2 busy"); >> >> - sched_pin(); >> >> *sysmaps->CMAP2 = PG_V | PG_RW | VM_PAGE_TO_PHYS(m) | PG_A | PG_M | >> >> pmap_cache_bits(m->md.pat_mode, 0); >> >> invlcaddr(sysmaps->CADDR2); >> >> @@ -4171,11 +4171,11 @@ >> >> { >> >> struct sysmaps *sysmaps; >> >> >> >> + sched_pin(); >> >> sysmaps = &sysmaps_pcpu[PCPU_GET(cpuid)]; >> >> mtx_lock(&sysmaps->lock); >> >> if (*sysmaps->CMAP2) >> >> panic("pmap_zero_page_area: CMAP2 busy"); >> >> - sched_pin(); >> >> *sysmaps->CMAP2 = PG_V | PG_RW | VM_PAGE_TO_PHYS(m) | PG_A | PG_M | >> >> pmap_cache_bits(m->md.pat_mode, 0); >> >> invlcaddr(sysmaps->CADDR2); >> >> @@ -4220,13 +4220,13 @@ >> >> { >> >> struct sysmaps *sysmaps; >> >> >> >> + sched_pin(); >> >> sysmaps = &sysmaps_pcpu[PCPU_GET(cpuid)]; >> >> mtx_lock(&sysmaps->lock); >> >> if (*sysmaps->CMAP1) >> >> panic("pmap_copy_page: CMAP1 busy"); >> >> if (*sysmaps->CMAP2) >> >> panic("pmap_copy_page: CMAP2 busy"); >> >> - sched_pin(); >> >> invlpg((u_int)sysmaps->CADDR1); >> >> invlpg((u_int)sysmaps->CADDR2); >> >> *sysmaps->CMAP1 = PG_V | VM_PAGE_TO_PHYS(src) | PG_A | >> >> @@ -5072,11 +5072,11 @@ >> >> vm_offset_t sva, eva; >> >> >> >> if ((cpu_feature & CPUID_CLFSH) != 0) { >> >> + sched_pin(); >> >> sysmaps = &sysmaps_pcpu[PCPU_GET(cpuid)]; >> >> mtx_lock(&sysmaps->lock); >> >> if (*sysmaps->CMAP2) >> >> panic("pmap_flush_page: CMAP2 busy"); >> >> - sched_pin(); >> >> *sysmaps->CMAP2 = PG_V | PG_RW | VM_PAGE_TO_PHYS(m) | >> >> PG_A | PG_M | pmap_cache_bits(m->md.pat_mode, 0); >> >> invlcaddr(sysmaps->CADDR2); >> >> _______________________________________________ >> >> 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 Mon Feb 18 20:36:34 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id CD17A2C4 for ; Mon, 18 Feb 2013 20:36:34 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 2B6996BB for ; Mon, 18 Feb 2013 20:36:33 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.6/8.14.6) with ESMTP id r1IKaUiO071593; Mon, 18 Feb 2013 22:36:30 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.7.4 kib.kiev.ua r1IKaUiO071593 Received: (from kostik@localhost) by tom.home (8.14.6/8.14.6/Submit) id r1IKaUjY071592; Mon, 18 Feb 2013 22:36:30 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 18 Feb 2013 22:36:30 +0200 From: Konstantin Belousov To: Svatopluk Kraus Subject: Re: [patch] i386 pmap sysmaps_pcpu[] atomic access Message-ID: <20130218203630.GO2598@kib.kiev.ua> References: <20130218150809.GG2598@kib.kiev.ua> <20130218170957.GJ2598@kib.kiev.ua> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="4ickEXl+ukcSQ/3E" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 18 Feb 2013 20:36:34 -0000 --4ickEXl+ukcSQ/3E Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Feb 18, 2013 at 09:27:40PM +0100, Svatopluk Kraus wrote: > On Mon, Feb 18, 2013 at 6:09 PM, Konstantin Belousov > wrote: > > On Mon, Feb 18, 2013 at 06:06:42PM +0100, Svatopluk Kraus wrote: > >> On Mon, Feb 18, 2013 at 4:08 PM, Konstantin Belousov > >> wrote: > >> > On Mon, Feb 18, 2013 at 01:44:35PM +0100, Svatopluk Kraus wrote: > >> >> Hi, > >> >> > >> >> the access to sysmaps_pcpu[] should be atomic with respect to > >> >> thread migration. Otherwise, a sysmaps for one CPU can be stolen by > >> >> another CPU and the purpose of per CPU sysmaps is broken. A patch is > >> >> enclosed. > >> > And, what are the problem caused by the 'otherwise' ? > >> > I do not see any. > >> > >> The 'otherwise' issue is the following: > >> > >> 1. A thread is running on CPU0. > >> > >> sysmaps =3D &sysmaps_pcpu[PCPU_GET(cpuid)]; > >> > >> 2. A sysmaps variable contains a pointer to 'CPU0' sysmaps. > >> 3. Now, the thread migrates into CPU1. > >> 4. However, the sysmaps variable still contains a pointers to 'CPU0' s= ysmaps. > >> > >> mtx_lock(&sysmaps->lock); > >> > >> 4. The thread running on CPU1 locked 'CPU0' sysmaps mutex, so the > >> thread uselessly can block another thread running on CPU0. Maybe, it's > >> not a problem. However, it definitely goes against the reason why the > >> submaps (one for each CPU) exist. > > So what ? >=20 > It depends. You don't understand it or you think it's ok? Tell me. >=20 Both. I do not understand your concern, and I think that the code is fine. Both threads in your description make useful progress, and computation proceeds correctly. >=20 > >> > >> > >> > Really, taking the mutex while bind to a CPU could be deadlock-prone > >> > under some situations. > >> > > >> > This was discussed at least one more time. Might be, a comment sayin= g that > >> > there is no issue should be added. > >> > >> I missed the discussion. Can you point me to it, please? A deadlock is > >> not problem here, however, I can be wrong, as I can't imagine now how > >> a simple pinning could lead into a deadlock at all. > > Because some other load on the bind cpu might prevent the thread from > > being scheduled. >=20 > I'm afraid I still have no idea. On single CPU, a binding has no > meaning. Thus, if any deadlock exists then exists without binding too. > Hmm, you are talking about a deadlock caused by heavy CPU load? Is it > a deadlock at all? Anyhow, mutex is a lock with priority propagation, > isn't it? >=20 When executing on single cpu, kernel sometimes make different decisions. Yes, the deadlock can be more precisely described as livelock. It might not make any matter for exactly this case, but still is useful to remember. --4ickEXl+ukcSQ/3E Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJRIpDNAAoJEJDCuSvBvK1BOtkP/36bapDMkUKdt8xwGxgDNstB OzAHtfGsIgHKnkk3vbFlAFyL40+6ifHOnFpEeq/wdKe8Dcj7TX11brlDa9BG7rzX MWimfwmhLA2tfodraRTN6pMteMTFva2kIgyBS2UYT1lxhI3txnuhfP4H4IzZd2gR QCG1gAu28RXv61B4lKbBS4b5enXwDkV5YO9b6Wn57IC3FoXYLY09pSBSYT8pB96n 2ApV/vFN8C2EzPE5ISG9FQLVRCcIUvpTwu5+E0OLPZj7KWUcxfhecuowkOzyanvu vETWYswmSlJIQJvOWEUgyjSRKCAOXTG19KiFwEEDV9Tcq4HRUolxy4AmYMwWG92+ MKxBlBAr1hQFfy+bY/zotFAVcvq7uWXpmolMreNQGNneQNCeDVj7CvIRyS/H4yA7 jMDQqR27QV9kZhQS449+cT84f5CShNzyRO8+brT7cLOSYF7NYoEhQCbmlcHcOXaH BAZYDtfwYYz9GmgHdU9JgyqcWEARAv9LuCJNLr4/EbC3yzzYF1Gs05qhnW2pfGCe dJuxJlwihqR4oj6iudO06GuukZ/K2/payLCKuXmKQwk1Fry0MlpNH7qLLj8mx58h +Lu5AKrfK/JhFRRW6TWGQ5GMrg0vAy7jI5AcaQ/oCzySna9wEkO25QSFHLyvGtwe XchettfJnn+anLvwug9q =mp0d -----END PGP SIGNATURE----- --4ickEXl+ukcSQ/3E-- From owner-freebsd-current@FreeBSD.ORG Mon Feb 18 22:18:18 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 0AEC5E7B for ; Mon, 18 Feb 2013 22:18:18 +0000 (UTC) (envelope-from onwahe@gmail.com) Received: from mail-qe0-f51.google.com (mail-qe0-f51.google.com [209.85.128.51]) by mx1.freebsd.org (Postfix) with ESMTP id BD1D2A6D for ; Mon, 18 Feb 2013 22:18:17 +0000 (UTC) Received: by mail-qe0-f51.google.com with SMTP id 6so2718822qea.38 for ; Mon, 18 Feb 2013 14:18:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=xX7AsK3mUfI7CTwtmICG+mpF5L+e/M2qnzA20YVMM1o=; b=FRkalGzVuSICutRmp/DhWMSuNn8lDY9/ZW4LA4L7FpIejV+siwU0FtF6JQ5Do9KIwR jFxt8BQ0cgek/yJyNB5DTZAczP9Fa1bJvLfX/Uosk1bhc7GGFUqQmHg/7ZPAxLCZbtyq nXcM5UzSvmCO3EdTMa5UyHYE0qlaEAFdBD/TxH7pKTtUW2fx8EN7jSyUI8ruUMQZe8tE UvQoJzyNlY2CyD1V169HDiWPF/VHBq+XDXxA0vl4O8kTiTM1zgb1O1dkIZPAQ1b5IFNa /sHAbZJMJB+ZCkNf6ptauNRd+KgX8nsPTPpgmy6peopZuBblFZCP8WaWaJg4PBV20ZRQ iQOA== MIME-Version: 1.0 X-Received: by 10.49.105.73 with SMTP id gk9mr6078723qeb.40.1361225896853; Mon, 18 Feb 2013 14:18:16 -0800 (PST) Received: by 10.49.121.198 with HTTP; Mon, 18 Feb 2013 14:18:16 -0800 (PST) In-Reply-To: <20130218203630.GO2598@kib.kiev.ua> References: <20130218150809.GG2598@kib.kiev.ua> <20130218170957.GJ2598@kib.kiev.ua> <20130218203630.GO2598@kib.kiev.ua> Date: Mon, 18 Feb 2013 23:18:16 +0100 Message-ID: Subject: Re: [patch] i386 pmap sysmaps_pcpu[] atomic access From: Svatopluk Kraus To: Konstantin Belousov Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 18 Feb 2013 22:18:18 -0000 On Mon, Feb 18, 2013 at 9:36 PM, Konstantin Belousov wrote: > On Mon, Feb 18, 2013 at 09:27:40PM +0100, Svatopluk Kraus wrote: >> On Mon, Feb 18, 2013 at 6:09 PM, Konstantin Belousov >> wrote: >> > On Mon, Feb 18, 2013 at 06:06:42PM +0100, Svatopluk Kraus wrote: >> >> On Mon, Feb 18, 2013 at 4:08 PM, Konstantin Belousov >> >> wrote: >> >> > On Mon, Feb 18, 2013 at 01:44:35PM +0100, Svatopluk Kraus wrote: >> >> >> Hi, >> >> >> >> >> >> the access to sysmaps_pcpu[] should be atomic with respect to >> >> >> thread migration. Otherwise, a sysmaps for one CPU can be stolen by >> >> >> another CPU and the purpose of per CPU sysmaps is broken. A patch is >> >> >> enclosed. >> >> > And, what are the problem caused by the 'otherwise' ? >> >> > I do not see any. >> >> >> >> The 'otherwise' issue is the following: >> >> >> >> 1. A thread is running on CPU0. >> >> >> >> sysmaps = &sysmaps_pcpu[PCPU_GET(cpuid)]; >> >> >> >> 2. A sysmaps variable contains a pointer to 'CPU0' sysmaps. >> >> 3. Now, the thread migrates into CPU1. >> >> 4. However, the sysmaps variable still contains a pointers to 'CPU0' sysmaps. >> >> >> >> mtx_lock(&sysmaps->lock); >> >> >> >> 4. The thread running on CPU1 locked 'CPU0' sysmaps mutex, so the >> >> thread uselessly can block another thread running on CPU0. Maybe, it's >> >> not a problem. However, it definitely goes against the reason why the >> >> submaps (one for each CPU) exist. >> > So what ? >> >> It depends. You don't understand it or you think it's ok? Tell me. >> > Both. I do not understand your concern, and I think that the code is fine. Well, I'm taking a part on porting FreeBSD to ARM11mpcore. UP case was simple. SMP case is more complex and rather new for me. Recently, I was solving a problem with PCPU stuff. For example, PCPU_GET is implemented by one instruction on i386 arch. So, a need of atomicity with respect to interrupts can be overlooked. On load-store archs, the implementation which works in SMP case is not so simple. And what works in UP case (single PCPU), not works in SMP case. Believe me, mysterious and sporadic 'mutex not owned' assertions and others ones caused by curthreads mess, it takes a while ... After this, I took a look at how PCPU stuff is used in whole kernel and found out mentioned here i386 pmap issue. So, my concern is following: 1. to verify my newly gained ideas how per CPU data should be used, 2. to decide how to change my implementation of pmap on ARM11mpcore, as it's based on i386 pmap, 3. to make FreeBSD code better. In the meanwhile, it looks that using data dedicated to one CPU on another one is OK. However, I can't agree. At least, without comments, it is misleading for anyone new in FreeBSD and makes code misty. > Both threads in your description make useful progress, and computation > proceeds correctly. I thought, there is only one thread in my example. One thread running on CPU1, but holding sysmaps dedicated to CPU0 instead of holding sysmaps dedicated to CPU1. So, any thread running on CPU0 must wait because the thread running on CPU1 is a thief. Futhermore, the idea that a thread on CPU1 should hold data for CPU1 is not valid. So, either some comment is missing in the code that it's OK or the using of PCPU_GET(cpuid) is unneeded and some kind of free sysmaps list can be used and it will serve better. >> >> >> >> >> >> >> > Really, taking the mutex while bind to a CPU could be deadlock-prone >> >> > under some situations. >> >> > >> >> > This was discussed at least one more time. Might be, a comment saying that >> >> > there is no issue should be added. >> >> >> >> I missed the discussion. Can you point me to it, please? A deadlock is >> >> not problem here, however, I can be wrong, as I can't imagine now how >> >> a simple pinning could lead into a deadlock at all. >> > Because some other load on the bind cpu might prevent the thread from >> > being scheduled. >> >> I'm afraid I still have no idea. On single CPU, a binding has no >> meaning. Thus, if any deadlock exists then exists without binding too. >> Hmm, you are talking about a deadlock caused by heavy CPU load? Is it >> a deadlock at all? Anyhow, mutex is a lock with priority propagation, >> isn't it? >> > > When executing on single cpu, kernel sometimes make different decisions. > Yes, the deadlock can be more precisely described as livelock. > > It might not make any matter for exactly this case, but still is useful > to remember. From owner-freebsd-current@FreeBSD.ORG Mon Feb 18 23:44:59 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id EA55091 for ; Mon, 18 Feb 2013 23:44:59 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.net.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id AA513DF3 for ; Mon, 18 Feb 2013 23:44:58 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqEEACy8IlGDaFvO/2dsb2JhbABEhkm5W4Ebc4IfAQEBAwEBAQEgBCcgCwUWGAICDQUUAikBCSYGCAcEARkDBIdrBgyueZI2gSOMSoENNAcSDYIOgRMDiGeKBoEHgjiBHY87gyVPgQU1 X-IronPort-AV: E=Sophos;i="4.84,691,1355115600"; d="scan'208";a="14643689" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-annu.net.uoguelph.ca with ESMTP; 18 Feb 2013 18:44:51 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 17CDDB3F51; Mon, 18 Feb 2013 18:44:52 -0500 (EST) Date: Mon, 18 Feb 2013 18:44:52 -0500 (EST) From: Rick Macklem To: =?utf-8?Q?Elias_M=C3=A5rtenson?= Message-ID: <1789218505.3102975.1361231092074.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: Subject: Re: Possible bug in NFSv4 with krb5p security? MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.203] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - FF3.0 (Win)/6.0.10_GA_2692) Cc: freebsd-current@freebsd.org, Benjamin Kaduk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 18 Feb 2013 23:45:00 -0000 Elias Martenson wrote: > On 17 February 2013 22:58, Rick Macklem wrote: > > I think the Makefiles are in the kerberos5 directory. > > > > Since the only function you care about is the one in > > kerberos5/lib/libgssapi_krb5/pname_to_uid.c, I'd > > just put a copy of that file in usr.sbin/gssd and > > modify the Makefile there to compile it and link > > its .o into gssd, avoiding rebuilding any libraries. > > > > I'd put a couple of fprintf(stderr, ...) in it and > > then run "gssd -d" and see what it says. > > > > Just how I'd attack it, rick > > > Good news! The problem is solved! > > You were right, the problem was in pname_to_uid.c. In it, the > following > code can be found: > > char lname[MAXLOGNAME + 1], buf[1024]; > > /* some code snipped for brevity... */ > > getpwnam_r(lname, &pwd, buf, sizeof(buf), &pw); > if (pw) { > *uidp = pw->pw_uid; > return (GSS_S_COMPLETE); > } else { > return (GSS_S_FAILURE); > } > > As it turns out, the getpwnam_r() call fails with ERANGE (I had to > check > the return value from getpwnam_r() in order to determine this, as pw > is set > to NULL both if there was an error or if the user name can't be > found). > > Now, increasing the size of buf to 1024 solved the problem, and now > the > lookup works correctly. > > I wrote a small test program that issued the same call to getpwnam_r() > and > it worked. Until I su'ed to root, and then it failed. > > It seems as though the buffer needs to be bigger if you're root. I > have no > idea why, but there you have it. Problem solved. > > Should this be fixed in the main codebase? > Yes, I would definitely say so. I won't be able to do a commit until April, but meybe someone else can do a commit sooner? > Oh, and thanks so much to all of you for being patient with me while > solving this. I really appreciate it. Also, I'd like to say that the > code > base was quite pleasant to work with. Thanks for that too. :-) > And thanks for working through this, so we now have a fix, rick > Regards, > Elias > _______________________________________________ > 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 Tue Feb 19 05:51:56 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 0113CBBD for ; Tue, 19 Feb 2013 05:51:55 +0000 (UTC) (envelope-from tahir.rauf1@gmail.com) Received: from mail-ve0-f175.google.com (mail-ve0-f175.google.com [209.85.128.175]) by mx1.freebsd.org (Postfix) with ESMTP id BD118DB9 for ; Tue, 19 Feb 2013 05:51:55 +0000 (UTC) Received: by mail-ve0-f175.google.com with SMTP id cy12so5469740veb.6 for ; Mon, 18 Feb 2013 21:51:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=DBV/jColqj7jvBWzFaao9Kwy83gLLIQkS17VkZpcwWs=; b=B5dBS0QUxy88empiuuzoJ4+4yls1NBZtV3LQPV3tQ3sWn95BCqDWIKeJsCU+Dfe/bq M6iqrA7RJi8Ohr2ptL8ajOVuhGLsFOZ/grizUb4hXp0iTmEcTm5a9IDQUqKpurFjTatr FJ2DTSapxB/uPOcKrMcNoKtURHY0s7M7FGensQlOvUBVGTHUTc0cX2R9BUrP97QmPnuj Qk7jOOaDCPMvIBerAGIL3rbWvMmiN7SCMjv8XvjSSU+9bLuXIZJbfmyaqRFpgiNMt/mS woHH2zZYj0JpcUPDU7lLq4bpSw1lC+seY7zYGDbPlmdRZEtaKi8ZwY8GSH1qI02bVPIo 9yHw== MIME-Version: 1.0 X-Received: by 10.58.239.38 with SMTP id vp6mr19749952vec.13.1361253108952; Mon, 18 Feb 2013 21:51:48 -0800 (PST) Received: by 10.58.155.97 with HTTP; Mon, 18 Feb 2013 21:51:48 -0800 (PST) Date: Tue, 19 Feb 2013 10:51:48 +0500 Message-ID: Subject: netmap error (Unable to get if info for eth1) From: Tahir Rauf To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 19 Feb 2013 05:51:56 -0000 Hi all, I am giving netmap a try and have tested it on my Realtech and Intel 1G NICs (by using r8169 and e1000e kernel modules), and it is working fine. However, I am facing problem while running it on my intel 10G NIC (82598EB 10-Gigabit AF Dual Port Network Connection). Whenever, I run the pkt-gen example with 10G interface, it shows me following error ======================================================================= sudo ./pkt-gen -i eth1 -f tx -l 60 extract_ip_range [119] extract IP range from 10.0.0.1 extract_ip_range [129] 10.0.0.1 starts at 10.0.0.1 extract_ip_range [119] extract IP range from 10.1.0.1 extract_ip_range [129] 10.1.0.1 starts at 10.1.0.1 extract_mac_range [135] extract MAC range from 00:1b:21:ce:f3:6a extract_mac_range [150] 00:1b:21:ce:f3:6a starts at 0:1b:21:ce:f3:6a extract_mac_range [135] extract MAC range from ff:ff:ff:ff:ff:ff extract_mac_range [150] ff:ff:ff:ff:ff:ff starts at ff:ff:ff:ff:ff:ff main [1053] map size is 207712 Kb main [1059] Unable to get if info for eth1 main [1066] bad nthreads 1, have 0 queues main [1075] mmapping 207712 Kbytes main [1094] Unable to register interface eth1 Sending on eth1: 0 queues, 1 threads and 1 cpus. 10.0.0.1 -> 10.1.0.1 (00:1b:21:ce:f3:6a -> ff:ff:ff:ff:ff:ff) main [1128] Wait 2 secs for phy reset main [1130] Ready... main [1181] Unable to register eth1 main [1242] 0 pps Sent 0 packets, 60 bytes each, in 0.00 seconds. ======================================================================= Any idea that what's going wrong here? Regards Tahir Rauf (+92) 312-7767761 -------------------------------------------------------------------------------------------------------------------------------------------------------------- This electronic message transmission contains information from the Company that may be proprietary, confidential and/or privileged. The information is intended only for the use of the individuals or entity named above. If you are not the intended recipient, be aware that any disclosure, copying or distribution or use of the contents of this information is prohibited. If you have received this electronic transmission in error, please notify the sender immediately by replying to this email. From owner-freebsd-current@FreeBSD.ORG Tue Feb 19 05:57:06 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id B1CB3D74 for ; Tue, 19 Feb 2013 05:57:06 +0000 (UTC) (envelope-from rizzo.unipi@gmail.com) Received: from mail-la0-x232.google.com (mail-la0-x232.google.com [IPv6:2a00:1450:4010:c03::232]) by mx1.freebsd.org (Postfix) with ESMTP id 2ABC7DFF for ; Tue, 19 Feb 2013 05:57:05 +0000 (UTC) Received: by mail-la0-f50.google.com with SMTP id ec20so6247182lab.9 for ; Mon, 18 Feb 2013 21:57:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=4cw5ylxZGf534+RxoSbUWCY/r2lpJppCR/C5dMa32MQ=; b=J9HldM+P/ASf0JPV0wRcxMG5H6Hp9WHrO+r6mOWT1nDJOYFqwzvrQRFSMB7EYy+2u8 djgZGtisxXQIWdqYvTsYAEjBvWZw88Jr4m7w1l2ftuJCjjHerPecBRLBxBpksSOwPzRo eZc9CZ96Ay2lYjFc9MmDjPs9tG7wCJ+bj0mQljz1Z6S6ybtv3KWupa06y6Ij0aE/P4VW SC3OCO9aWxqyhWr1EEhPC3DMN+CVcs37J4y+ROJmB3aPDo1gptQocvZp28Jp3pxq0YYZ RQz8XR1RdiBn0rSTqZrmyLubFK88gqGGEsJ9A5d0aYQTrrP5A5nZqnr07AGlN79B0cIq Avag== MIME-Version: 1.0 X-Received: by 10.112.101.34 with SMTP id fd2mr6595440lbb.100.1361253424913; Mon, 18 Feb 2013 21:57:04 -0800 (PST) Sender: rizzo.unipi@gmail.com Received: by 10.114.3.36 with HTTP; Mon, 18 Feb 2013 21:57:04 -0800 (PST) In-Reply-To: References: Date: Mon, 18 Feb 2013 21:57:04 -0800 X-Google-Sender-Auth: tp1zX6RugfrXW-DREduW76rO34g Message-ID: Subject: Re: netmap error (Unable to get if info for eth1) From: Luigi Rizzo To: Tahir Rauf Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 19 Feb 2013 05:57:06 -0000 On Mon, Feb 18, 2013 at 9:51 PM, Tahir Rauf wrote: > Hi all, > > I am giving netmap a try and have tested it on my Realtech and Intel 1G > NICs (by using r8169 and e1000e kernel modules), and it is working fine. > > However, I am facing problem while running it on my intel 10G NIC (82598EB > 10-Gigabit AF Dual Port Network Connection). Whenever, I run the pkt-gen > example with 10G interface, it shows me following error > > likely you are running an unpatched version of the ixgbe driver. Does dmesg say anything about netmap when loading the ixgbe driver ? (also which version of the code are you using ? it seems you are running linux...) cheers luigi ======================================================================= > sudo ./pkt-gen -i eth1 -f tx -l 60 > extract_ip_range [119] extract IP range from 10.0.0.1 > extract_ip_range [129] 10.0.0.1 starts at 10.0.0.1 > extract_ip_range [119] extract IP range from 10.1.0.1 > extract_ip_range [129] 10.1.0.1 starts at 10.1.0.1 > extract_mac_range [135] extract MAC range from 00:1b:21:ce:f3:6a > extract_mac_range [150] 00:1b:21:ce:f3:6a starts at 0:1b:21:ce:f3:6a > extract_mac_range [135] extract MAC range from ff:ff:ff:ff:ff:ff > extract_mac_range [150] ff:ff:ff:ff:ff:ff starts at ff:ff:ff:ff:ff:ff > main [1053] map size is 207712 Kb > main [1059] Unable to get if info for eth1 > main [1066] bad nthreads 1, have 0 queues > main [1075] mmapping 207712 Kbytes > main [1094] Unable to register interface eth1 > Sending on eth1: 0 queues, 1 threads and 1 cpus. > 10.0.0.1 -> 10.1.0.1 (00:1b:21:ce:f3:6a -> ff:ff:ff:ff:ff:ff) > main [1128] Wait 2 secs for phy reset > main [1130] Ready... > main [1181] Unable to register eth1 > main [1242] 0 pps > Sent 0 packets, 60 bytes each, in 0.00 seconds. > ======================================================================= > > Any idea that what's going wrong here? > > Regards > > Tahir Rauf > (+92) 312-7767761 > > -------------------------------------------------------------------------------------------------------------------------------------------------------------- > This electronic message transmission contains information from the Company > that may be proprietary, confidential and/or privileged. The information is > intended only for the use of the individuals or entity named above. If you > are not the intended recipient, be aware that any disclosure, copying or > distribution or use of the contents of this information is prohibited. If > you have received this electronic transmission in error, please notify the > sender immediately by replying to this email. > _______________________________________________ > 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" > -- -----------------------------------------+------------------------------- Prof. Luigi RIZZO, rizzo@iet.unipi.it . Dip. di Ing. dell'Informazione http://www.iet.unipi.it/~luigi/ . Universita` di Pisa TEL +39-050-2211611 . via Diotisalvi 2 Mobile +39-338-6809875 . 56122 PISA (Italy) -----------------------------------------+------------------------------- From owner-freebsd-current@FreeBSD.ORG Tue Feb 19 06:35:45 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 461C51E3 for ; Tue, 19 Feb 2013 06:35:45 +0000 (UTC) (envelope-from tahir.rauf1@gmail.com) Received: from mail-ve0-f180.google.com (mail-ve0-f180.google.com [209.85.128.180]) by mx1.freebsd.org (Postfix) with ESMTP id E747EF0B for ; Tue, 19 Feb 2013 06:35:44 +0000 (UTC) Received: by mail-ve0-f180.google.com with SMTP id jx10so5412361veb.25 for ; Mon, 18 Feb 2013 22:35:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=VDXJ31M3Peg1bt4GHL2JwuNk53W8o8CHU/8NYWMQy+0=; b=LjlWMoYHIrNsPxm0yrbLRBErV/Q0aSnwNmWU3xJcF34kQ9t9nZxJmwo6Evk8xsV0VM jEXq/Q9BvCd7RvYT2S7A+/9Hee2FUuvOYA3XLYy11+JbjqHbu2eO3z2XgBVbPxqCFFEG mrQVlSBXT9H4CeELFMdpz2T5JPdKoqA+++E3doQxvS4M49wqzX23OBHBt7ANcjgTDjlC 0yNyoDJ2TXxPjPpo6CpjIdVn0/T0NWvu6HzzdPxj1P7Z43eCCujVjpdQ4r3I0Mxuwcgt gT85g2Zt7rwLYogG5F+rNffom6ddkARvV2RGbbirikYxpXaGaqhFkF8fAVwBMXneFMqx OVCw== MIME-Version: 1.0 X-Received: by 10.52.92.225 with SMTP id cp1mr16680873vdb.41.1361255743463; Mon, 18 Feb 2013 22:35:43 -0800 (PST) Received: by 10.58.155.97 with HTTP; Mon, 18 Feb 2013 22:35:43 -0800 (PST) In-Reply-To: References: Date: Tue, 19 Feb 2013 11:35:43 +0500 Message-ID: Subject: Re: netmap error (Unable to get if info for eth1) From: Tahir Rauf To: Luigi Rizzo Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 19 Feb 2013 06:35:45 -0000 Dear Luigui, Thanks for your prompt answer. Below I try to give complete information so that it becomes easy for you to identify the problem. *netmap version used*: 20120813 new unified source code for Linux and FreeBSD *System credentials:* O/S: Ubuntu 12.04 LTS machine: x86_64 processor: x86_64 O/S kernel version: #51-Ubuntu SMP Wed Sep 26 21:33:09 UTC 2012 O/S kernel release: 3.2.0-32-generic *10G NIC used* product: 82598EB 10-Gigabit AF Dual Port Network Connection vendor: Intel Corporation physical id: 0 bus info: pci@0000:01:00.0 logical name: eth1 version: 01 serial: 00:1b:21:c1:6d:e3 width: 32 bits capabilities: pm msi msix pciexpress bus_master cap_list ethernet physical fibre configuration: autonegotiation=off broadcast=yes driver=ixgbe driverversion=3.6.7-k duplex=full firmware=0xc1b30000 latency=0 link=yes multicast=yes resources: irq:16 memory:f7ba0000-f7bbffff memory:f7b40000-f7b7ffff ioport:e020(size=32) memory:f7bc4000-f7bc7fff *Pkt-gen command* sudo ./pkt-gen -i eth1 tx -n 500111222 -l 60 -w 5 *Output of pkt-gen program* tahir@tahir-desktop:~/Desktop/netmap-old/examples$ sudo ./pkt-gen -i eth1 tx -n 500111222 -l 60 -w 5 extract_ip_range [119] extract IP range from 10.0.0.1 extract_ip_range [129] 10.0.0.1 starts at 10.0.0.1 extract_ip_range [119] extract IP range from 10.1.0.1 extract_ip_range [129] 10.1.0.1 starts at 10.1.0.1 extract_mac_range [135] extract MAC range from 00:1b:21:c1:6d:e3 extract_mac_range [150] 00:1b:21:c1:6d:e3 starts at 0:1b:21:c1:6d:e3 extract_mac_range [135] extract MAC range from ff:ff:ff:ff:ff:ff extract_mac_range [150] ff:ff:ff:ff:ff:ff starts at ff:ff:ff:ff:ff:ff main [1053] map size is 207712 Kb main [1059] Unable to get if info for eth1 main [1066] bad nthreads 1, have 0 queues main [1075] mmapping 207712 Kbytes main [1094] Unable to register interface eth1 Receiving from eth1: 0 queues, 1 threads and 1 cpus. main [1128] Wait 5 secs for phy reset main [1130] Ready... main [1181] Unable to register eth1 main [1242] 0 pps Received 0 packets, in 0.00 seconds. Speed: -nanpps. *Sequence of commands used* sudo insmod netmap_lin.ko sudo rmmod ixgbe sudo insmod ixgbe/ixgbe.ko sudo ./pkt-gen -i eth1 tx -n 500111222 -l 60 -w 5 *Dmesg output* [82904.219757] 549.080148 netmap_new_obj_allocator [426] objsize 1024 clustsize 4096 objects 4 [82904.219837] 549.080229 netmap_new_obj_allocator [504] Pre-allocated 128 clusters (4/512KB) for 'netmap_if' [82904.219841] 549.080233 netmap_new_obj_allocator [426] objsize 36864 clustsize 36864 objects 1 [82904.221431] 549.081825 netmap_new_obj_allocator [504] Pre-allocated 200 clusters (36/7200KB) for 'netmap_ring' [82904.221436] 549.081833 netmap_new_obj_allocator [426] objsize 2048 clustsize 4096 objects 2 [82904.251034] 549.111513 netmap_new_obj_allocator [504] Pre-allocated 50000 clusters (4/200000KB) for 'netmap_buf' [82904.251038] 549.111520 netmap_memory_init [554] Have 512 KB for interfaces, 7200 KB for rings and 195 MB for buffers [82904.251039] netmap: loaded module with 202 Mbytes [82918.659224] ixgbe: Intel(R) 10 Gigabit PCI Express Network Driver - version 3.6.7-k [82918.659228] ixgbe: Copyright (c) 1999-2011 Intel Corporation. [82918.659260] ixgbe 0000:01:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16 [82918.659276] ixgbe 0000:01:00.0: setting latency timer to 64 [82920.223583] ixgbe 0000:01:00.0: irq 53 for MSI/MSI-X [82920.223592] ixgbe 0000:01:00.0: irq 54 for MSI/MSI-X [82920.223597] ixgbe 0000:01:00.0: irq 55 for MSI/MSI-X [82920.223603] ixgbe 0000:01:00.0: irq 56 for MSI/MSI-X [82920.223608] ixgbe 0000:01:00.0: irq 57 for MSI/MSI-X [82920.223614] ixgbe 0000:01:00.0: irq 58 for MSI/MSI-X [82920.223619] ixgbe 0000:01:00.0: irq 59 for MSI/MSI-X [82920.223625] ixgbe 0000:01:00.0: irq 60 for MSI/MSI-X [82920.223630] ixgbe 0000:01:00.0: irq 61 for MSI/MSI-X [82920.223649] ixgbe 0000:01:00.0: Multiqueue Enabled: Rx Queue count = 8, Tx Queue count = 8 [82920.223797] ixgbe 0000:01:00.0: (PCI Express:2.5GT/s:Width x8) 00:1b:21:c1:6d:e3 [82920.223871] ixgbe 0000:01:00.0: MAC: 1, PHY: 7, SFP+: 0, PBA No: E37002-011 [82920.224934] ixgbe 0000:01:00.0: Intel(R) 10 Gigabit Network Connection [82920.224957] ixgbe 0000:01:00.1: PCI INT B -> GSI 17 (level, low) -> IRQ 17 [82920.224971] ixgbe 0000:01:00.1: setting latency timer to 64 [82920.305560] ADDRCONF(NETDEV_UP): eth1: link is not ready [82920.306249] ADDRCONF(NETDEV_UP): eth1: link is not ready [82921.727292] ixgbe 0000:01:00.1: irq 62 for MSI/MSI-X [82921.727301] ixgbe 0000:01:00.1: irq 63 for MSI/MSI-X [82921.727307] ixgbe 0000:01:00.1: irq 64 for MSI/MSI-X [82921.727313] ixgbe 0000:01:00.1: irq 65 for MSI/MSI-X [82921.727319] ixgbe 0000:01:00.1: irq 66 for MSI/MSI-X [82921.727324] ixgbe 0000:01:00.1: irq 67 for MSI/MSI-X [82921.727330] ixgbe 0000:01:00.1: irq 68 for MSI/MSI-X [82921.727336] ixgbe 0000:01:00.1: irq 69 for MSI/MSI-X [82921.727341] ixgbe 0000:01:00.1: irq 70 for MSI/MSI-X [82921.727359] ixgbe 0000:01:00.1: Multiqueue Enabled: Rx Queue count = 8, Tx Queue count = 8 [82921.727508] ixgbe 0000:01:00.1: (PCI Express:2.5GT/s:Width x8) 00:1b:21:c1:6d:e2 [82921.727582] ixgbe 0000:01:00.1: MAC: 1, PHY: 7, SFP+: 0, PBA No: E37002-011 [82921.728677] ixgbe 0000:01:00.1: Intel(R) 10 Gigabit Network Connection [82921.754094] ADDRCONF(NETDEV_UP): eth2: link is not ready [82921.754635] ADDRCONF(NETDEV_UP): eth2: link is not ready [82921.793753] ixgbe 0000:01:00.0: eth1: detected SFP+: 0 [82923.189007] ixgbe 0000:01:00.1: eth2: detected SFP+: 0 [82925.922486] ixgbe 0000:01:00.1: eth2: NIC Link is Up 10 Gbps, Flow Control: RX/TX [82925.923286] ADDRCONF(NETDEV_CHANGE): eth2: link becomes ready [82925.958596] ixgbe 0000:01:00.0: eth1: NIC Link is Up 10 Gbps, Flow Control: RX/TX [82925.959037] ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready [82936.420026] eth2: no IPv6 routers present [82937.840689] eth1: no IPv6 routers present *NOTE*: It is important to note that both realteck and igb is working. I made little change in if_e1000e_netmap.h file and add following lines to eliminate few problems for my linux kernel version Ubuntu 3.2.0-32.51-generic. #define E1000_GET_DESC(R, i, type) (&(((struct type *)((R).desc))[i])) #define E1000_RX_DESC(R, i) E1000_GET_DESC(R, i, e1000_rx_desc) Regards On Tue, Feb 19, 2013 at 10:57 AM, Luigi Rizzo wrote: > On Mon, Feb 18, 2013 at 9:51 PM, Tahir Rauf wrote: > >> Hi all, >> >> I am giving netmap a try and have tested it on my Realtech and Intel 1G >> NICs (by using r8169 and e1000e kernel modules), and it is working fine. >> >> However, I am facing problem while running it on my intel 10G NIC (82598EB >> 10-Gigabit AF Dual Port Network Connection). Whenever, I run the pkt-gen >> example with 10G interface, it shows me following error >> >> > likely you are running an unpatched version of the ixgbe driver. > Does dmesg say anything about netmap when loading the ixgbe driver ? > (also which version of the code are you using ? it seems you > are running linux...) > > cheers > luigi > > ======================================================================= >> sudo ./pkt-gen -i eth1 -f tx -l 60 >> extract_ip_range [119] extract IP range from 10.0.0.1 >> extract_ip_range [129] 10.0.0.1 starts at 10.0.0.1 >> extract_ip_range [119] extract IP range from 10.1.0.1 >> extract_ip_range [129] 10.1.0.1 starts at 10.1.0.1 >> extract_mac_range [135] extract MAC range from 00:1b:21:ce:f3:6a >> extract_mac_range [150] 00:1b:21:ce:f3:6a starts at 0:1b:21:ce:f3:6a >> extract_mac_range [135] extract MAC range from ff:ff:ff:ff:ff:ff >> extract_mac_range [150] ff:ff:ff:ff:ff:ff starts at ff:ff:ff:ff:ff:ff >> main [1053] map size is 207712 Kb >> main [1059] Unable to get if info for eth1 >> main [1066] bad nthreads 1, have 0 queues >> main [1075] mmapping 207712 Kbytes >> main [1094] Unable to register interface eth1 >> Sending on eth1: 0 queues, 1 threads and 1 cpus. >> 10.0.0.1 -> 10.1.0.1 (00:1b:21:ce:f3:6a -> ff:ff:ff:ff:ff:ff) >> main [1128] Wait 2 secs for phy reset >> main [1130] Ready... >> main [1181] Unable to register eth1 >> main [1242] 0 pps >> Sent 0 packets, 60 bytes each, in 0.00 seconds. >> ======================================================================= >> >> Any idea that what's going wrong here? >> >> Regards >> >> Tahir Rauf >> (+92) 312-7767761 >> >> -------------------------------------------------------------------------------------------------------------------------------------------------------------- >> This electronic message transmission contains information from the Company >> that may be proprietary, confidential and/or privileged. The information >> is >> intended only for the use of the individuals or entity named above. If you >> are not the intended recipient, be aware that any disclosure, copying or >> distribution or use of the contents of this information is prohibited. If >> you have received this electronic transmission in error, please notify the >> sender immediately by replying to this email. >> _______________________________________________ >> 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 >> " >> > > > > -- > -----------------------------------------+------------------------------- > Prof. Luigi RIZZO, rizzo@iet.unipi.it . Dip. di Ing. dell'Informazione > http://www.iet.unipi.it/~luigi/ . Universita` di Pisa > TEL +39-050-2211611 . via Diotisalvi 2 > Mobile +39-338-6809875 . 56122 PISA (Italy) > -----------------------------------------+------------------------------- > -- Tahir Rauf From owner-freebsd-current@FreeBSD.ORG Tue Feb 19 08:23:02 2013 Return-Path: Delivered-To: current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1033) id C97233C7; Tue, 19 Feb 2013 08:23:02 +0000 (UTC) Date: Tue, 19 Feb 2013 08:23:02 +0000 From: Alexey Dokuchaev To: current@freebsd.org Subject: ale(4) cannot negotiate as GigE Message-ID: <20130219082302.GA86501@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 19 Feb 2013 08:23:02 -0000 Hi there, I've recently put back online one of my home servers, updated to the latest -CURRENT code. All went fine, but one thing bothers me. This box bears Asus P5Q Pro mobo, with the following onboard NIC: ale0@pci0:2:0:0: class=0x020000 card=0x82261043 chip=0x10261969 rev=0xb0 hdr=0x00 vendor = 'Atheros Communications Inc.' device = 'AR8121/AR8113/AR8114 Gigabit or Fast Ethernet' class = network subclass = ethernet According the the specs, it should be GigE. In fact, when plugged into a capable switch, it displays "green" (gig) status (same on the switch), but once being initialized by the kernel, it downgrades to yellowish 100mbps (real speeds agree). I'm not sure why it happens; maybe it's somehow related to a handful of those "ale0: link state changed to DOWN/UP" flip-flops I see in dmesg(8), before it can finally obtain DHCP lease? I remember these adapters had problems in the past, like infamous "Corrupted MAC on input" disconnect messages, but I don't recall that I could not use it in GigE mode. Anything I can do about it? Googling did not help much: most reports date back to ca. 2009, and apparently were ironed out in later revisions (e.g. selectively disabling checksum offloading). Thanks, ./danfe From owner-freebsd-current@FreeBSD.ORG Tue Feb 19 09:03:24 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 44020EF8 for ; Tue, 19 Feb 2013 09:03:24 +0000 (UTC) (envelope-from nick@van-laarhoven.org) Received: from vps.van-laarhoven.org (www.hibma.org [178.21.117.90]) by mx1.freebsd.org (Postfix) with ESMTP id B17E89E3 for ; Tue, 19 Feb 2013 09:03:23 +0000 (UTC) Received: from hitske-lan.fritz.box (thuis.van-laarhoven.org [80.100.41.4]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by vps.van-laarhoven.org (Postfix) with ESMTPSA id C67335F2099 for ; Tue, 19 Feb 2013 10:01:37 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: No console, not even serial, does not work (init fails) From: Nick Hibma In-Reply-To: <96A2B40B-4191-4C4F-8AA5-39526E252D40@van-laarhoven.org> Date: Tue, 19 Feb 2013 10:03:20 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <96A2B40B-4191-4C4F-8AA5-39526E252D40@van-laarhoven.org> To: =?windows-1252?Q?=93FreeBSD_Current_Mailing_List=94?= X-Mailer: Apple Mail (2.1499) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 19 Feb 2013 09:03:24 -0000 Ed sent me a answer to my ramblings: "It is indeed true that init(8) is a bit picky when you don't have a console. If /dev/console cannot be opened, init(8) will just break completely. This has been fixed in FreeBSD -HEAD, where I've extended init(8) to handle this gracefully, specifically for cases where you have hardware without a console or potentially want to run init(8) in a jail (though we're not there yet)." http://svnweb.freebsd.org/base?view=3Drevision&revision=3D232977 I'll try that, and will follow up here. Nick Hibma nick@van-laarhoven.org Collect, process, organize, review and do. - GTD On 18 Feb 2013, at 20:30, Nick Hibma wrote: > We run our NanoBSD images on Soekris and ALIX hardware. In some cases = we need all available serial ports for other hardware like GPS, and = modems. The boards have no video, so with all serial ports unavailable = as a console no other console is available. >=20 > The problem is that FreeBSD does not handle well the case where there = is no console at all: >=20 > 1) http://www.freebsd.org/cgi/query-pr.cgi?pr=3Dbin/102515 >=20 > fsck_ufs crashes (6.1-STABLE). Because of the unitialised console libc = somehow gets corrupted and crashes fsck_ufs. This problem can be = circumvented by replacing 'fsck -p' with 'fsck < /dev/null > /dev/null'. >=20 > 2) In 8.3-RELEASE init exits prematurely because it cannot open = /dev/console for reading and writing in setctty(). Removing the calls to = _exit(1) in that function makes the boot complete. I haven't checked = whether the fsck_ufs problem still appears as our builds run with a = patched rc.d script. >=20 >=20 > As far as I can see this is still a problem in CURRENT. >=20 >=20 > My attempt at resolving this was to create a null terminal in = dev/null/null.c, see the patch below, but that did not work as expected. = After booting the system with a modified init the response to 'echo > = /dev/console' was 'Device not configured'. I've added another CN_* = priority to make sure a null console does not take precedence over for = example gdb console. >=20 >=20 > Any pointers as to who/how to resolve this issue? Any reason why the = null console approach does not work? >=20 > Nick Hibma > nick@van-laarhoven.org >=20 > GTD: Time management for chaotic people. >=20 > Index: /usr/src/sys/sys/cons.h > =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 > --- /usr/src/sys/sys/cons.h (revision 242660) > +++ /usr/src/sys/sys/cons.h (working copy) > @@ -69,10 +69,11 @@ > =20 > /* values for cn_pri - reflect our policy for console selection */ > #define CN_DEAD 0 /* device doesn't exist */ > -#define CN_LOW 1 /* device is a last restort only = */ > -#define CN_NORMAL 2 /* device exists but is nothing special = */ > -#define CN_INTERNAL 3 /* "internal" bit-mapped display */ > -#define CN_REMOTE 4 /* serial interface with remote bit set = */ > +#define CN_NULL 1 /* no console at all */ > +#define CN_LOW 2 /* device is a last restort only = */ > +#define CN_NORMAL 3 /* device exists but is nothing special = */ > +#define CN_INTERNAL 4 /* "internal" bit-mapped display */ > +#define CN_REMOTE 5 /* serial interface with remote bit set = */ > =20 > /* Values for cn_flags. */ > #define CN_FLAG_NODEBUG 0x00000001 /* Not supported with = debugger. */ > Index: /usr/src/sys/dev/null/null.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 > --- /usr/src/sys/dev/null/null.c (revision 242660) > +++ /usr/src/sys/dev/null/null.c (working copy) > @@ -41,6 +41,9 @@ > #include > #include > =20 > +#include > +#include > + > #include > =20 > /* For use with destroy_dev(9). */ > @@ -173,3 +176,45 @@ > =20 > DEV_MODULE(null, null_modevent, NULL); > MODULE_VERSION(null, 1); > + > +static cn_probe_t null_cnprobe; > +static cn_init_t null_cninit; > +static cn_term_t null_cnterm; > +static cn_getc_t null_cngetc; > +static cn_putc_t null_cnputc; > + > +CONSOLE_DRIVER(null); > + > +static void > +null_cnprobe(struct consdev *cp) > +{ > + sprintf(cp->cn_name, "null"); > + cp->cn_pri =3D CN_NULL; > +} > + > +static void > +null_cninit(struct consdev *cp) > +{ > +} > + > + > +static void > +null_cnputc(struct consdev *cp, int c) > +{ > + (void) cp; > + > + (void) c; > +} > + > +static int > +null_cngetc(struct consdev * cp) > +{ > + (void) cp; > +=09 > + return -1; > +} > + > +static void > +null_cnterm(struct consdev * cp) > +{ > +} >=20 From owner-freebsd-current@FreeBSD.ORG Tue Feb 19 09:31:47 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 873DB772 for ; Tue, 19 Feb 2013 09:31:47 +0000 (UTC) (envelope-from simon@comsys.ntu-kpi.kiev.ua) Received: from comsys.kpi.ua (comsys.kpi.ua [77.47.192.42]) by mx1.freebsd.org (Postfix) with ESMTP id 41FC9B3D for ; Tue, 19 Feb 2013 09:31:46 +0000 (UTC) Received: from pm513-1.comsys.kpi.ua ([10.18.52.101] helo=pm513-1.comsys.ntu-kpi.kiev.ua) by comsys.kpi.ua with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1U7jY7-0006IZ-4y; Tue, 19 Feb 2013 11:31:43 +0200 Received: by pm513-1.comsys.ntu-kpi.kiev.ua (Postfix, from userid 1001) id 12C4C1CC1E; Tue, 19 Feb 2013 11:31:43 +0200 (EET) Date: Tue, 19 Feb 2013 11:31:42 +0200 From: Andrey Simonenko To: Elias Martenson Subject: Re: Possible bug in NFSv4 with krb5p security? Message-ID: <20130219093142.GA1459@pm513-1.comsys.ntu-kpi.kiev.ua> References: <477291850.3084864.1361113135205.JavaMail.root@erie.cs.uoguelph.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Authenticated-User: simon@comsys.ntu-kpi.kiev.ua X-Authenticator: plain X-Sender-Verify: SUCCEEDED (sender exists & accepts mail) X-Exim-Version: 4.63 (build at 28-Apr-2011 07:11:12) X-Date: 2013-02-19 11:31:43 X-Connected-IP: 10.18.52.101:48741 X-Message-Linecount: 79 X-Body-Linecount: 61 X-Message-Size: 2983 X-Body-Size: 2071 Cc: Rick Macklem , Benjamin Kaduk , freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 19 Feb 2013 09:31:47 -0000 On Tue, Feb 19, 2013 at 12:06:13AM +0800, Elias Martenson wrote: > > You were right, the problem was in pname_to_uid.c. In it, the following > code can be found: > > char lname[MAXLOGNAME + 1], buf[1024]; > > /* some code snipped for brevity... */ > > getpwnam_r(lname, &pwd, buf, sizeof(buf), &pw); > if (pw) { > *uidp = pw->pw_uid; > return (GSS_S_COMPLETE); > } else { > return (GSS_S_FAILURE); > } > > As it turns out, the getpwnam_r() call fails with ERANGE (I had to check > the return value from getpwnam_r() in order to determine this, as pw is set > to NULL both if there was an error or if the user name can't be found). > > Now, increasing the size of buf to 1024 solved the problem, and now the > lookup works correctly. > > I wrote a small test program that issued the same call to getpwnam_r() and > it worked. Until I su'ed to root, and then it failed. > > It seems as though the buffer needs to be bigger if you're root. I have no > idea why, but there you have it. Problem solved. It can require bigger buffer, since root can get the pw_password field in the struct passwd{}. Since sysconf(_SC_GETPW_R_SIZE_MAX) does not work on FreeBSD, the buffer for getpwnam_r() call should have at least (2 * MAXLOGNAME + 2 * MAXPATHLEN + _PASSWORD_LEN + 1) bytes (it is unclear how much is required for pw_gecos). This buffer can be dynamically reallocated until getpwnam_r() is not return ERANGE error (the following code has not been compiled and verified): #define PWBUF_SIZE_INI (2 * MAXLOGNAME + 2 * MAXPATHLEN + _PASSWORD_LEN + 1) #define PWBUF_SIZE_INC 128 size = PWBUF_SIZE_INI; for (;;) { size += PWBUF_SIZE_INC; buf = malloc(size); if (buf == NULL) return (GSS_S_FAILURE); error = getpwnam_r(lname, &pwd, buf, size, &pw); free(buf); if (pw != NULL) { *uidp = pw->pw_uid; return (GSS_S_COMPLETE); } else { if (error == ERANGE && size <= SIZE_MAX - PWBUF_SIZE_INC) continue; return (GSS_S_FAILURE); } } From owner-freebsd-current@FreeBSD.ORG Tue Feb 19 09:35:51 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 8DE3A8EC for ; Tue, 19 Feb 2013 09:35:51 +0000 (UTC) (envelope-from lokedhs@gmail.com) Received: from mail-ie0-x22d.google.com (ie-in-x022d.1e100.net [IPv6:2607:f8b0:4001:c03::22d]) by mx1.freebsd.org (Postfix) with ESMTP id 62B87B90 for ; Tue, 19 Feb 2013 09:35:51 +0000 (UTC) Received: by mail-ie0-f173.google.com with SMTP id 9so8177285iec.32 for ; Tue, 19 Feb 2013 01:35:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=W5YCDERy42Y1LxVMQWOC05e/Y8YyUG9ApX+AxftNu8c=; b=GXqpt7UGzKWKLZVfVRzrSQ4Bt/Gx0YBy9NM4nvO/juptVZF490lj17kx/FUTwHNEj/ 4/+RLiTkBMOPDJzJU2yjcm0fkxT+Yc2LTvJ0hXIXiRWxVn14pT/06MJTTx6/Q+qF4I92 cqSoIDX+0nyU2pln5iJG2U35+i8iOyJhacaCVpadaJNgsURlhirFINxJ9lxfQAGJdGUi SdRj4xOxF4h+Jb1/YpJVN0vNpCh0fG/Qnb6tjxc4GW1ohULiOVhQVvfUxN7jtTFwSysH /wy2bEX81+NnOb8MldTMK0vU0I3PjpmAbBDXs6UulevVd9P7vodsS0kudNulAycAsJ+5 zkyQ== MIME-Version: 1.0 X-Received: by 10.50.150.167 with SMTP id uj7mr9227937igb.1.1361266551120; Tue, 19 Feb 2013 01:35:51 -0800 (PST) Received: by 10.64.110.162 with HTTP; Tue, 19 Feb 2013 01:35:50 -0800 (PST) In-Reply-To: <20130219093142.GA1459@pm513-1.comsys.ntu-kpi.kiev.ua> References: <477291850.3084864.1361113135205.JavaMail.root@erie.cs.uoguelph.ca> <20130219093142.GA1459@pm513-1.comsys.ntu-kpi.kiev.ua> Date: Tue, 19 Feb 2013 17:35:50 +0800 Message-ID: Subject: Re: Possible bug in NFSv4 with krb5p security? From: =?ISO-8859-1?Q?Elias_M=E5rtenson?= To: Andrey Simonenko Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Rick Macklem , Benjamin Kaduk , freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 19 Feb 2013 09:35:51 -0000 On 19 February 2013 17:31, Andrey Simonenko wrote: It can require bigger buffer, since root can get the pw_password field > in the struct passwd{}. > > Since sysconf(_SC_GETPW_R_SIZE_MAX) does not work on FreeBSD, the buffer > for getpwnam_r() call should have at least (2 * MAXLOGNAME + 2 * > MAXPATHLEN + > _PASSWORD_LEN + 1) bytes (it is unclear how much is required for pw_gecos). > > This buffer can be dynamically reallocated until getpwnam_r() is not > return ERANGE error (the following code has not been compiled and > verified): > Is this really a better solution than to aim high right away? A series of malloc() calls should certainly have much higher overhead than the previous stack-allocated solution. A better compromise would be to do the lookup in a separate function, that allocates the buffer using alloca() instead, yes? Regards, Elias From owner-freebsd-current@FreeBSD.ORG Tue Feb 19 09:37:45 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id A3DD1A1E for ; Tue, 19 Feb 2013 09:37:45 +0000 (UTC) (envelope-from lars@netapp.com) Received: from mx11.netapp.com (mx11.netapp.com [216.240.18.76]) by mx1.freebsd.org (Postfix) with ESMTP id 8DCD3BF7 for ; Tue, 19 Feb 2013 09:37:45 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.84,694,1355126400"; d="scan'208";a="8315773" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx11-out.netapp.com with ESMTP; 19 Feb 2013 01:36:22 -0800 Received: from vmwexceht03-prd.hq.netapp.com (exchsmtp.hq.netapp.com [10.106.76.241]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id r1J9aMWu002445 for ; Tue, 19 Feb 2013 01:36:22 -0800 (PST) Received: from SACEXCMBX01-PRD.hq.netapp.com ([169.254.2.54]) by vmwexceht03-prd.hq.netapp.com ([10.106.76.241]) with mapi id 14.02.0328.009; Tue, 19 Feb 2013 01:36:22 -0800 From: "Eggert, Lars" To: "current@freebsd.org" Subject: system 20% busy at all times? Thread-Topic: system 20% busy at all times? Thread-Index: AQHODoSUIkOKNPDzb0yS23V/tl+klw== Date: Tue, 19 Feb 2013 09:36:22 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.106.53.51] Content-Type: text/plain; charset="us-ascii" Content-ID: <832B79550A4F3246BE467DD57A355188@tahoe.netapp.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 19 Feb 2013 09:37:45 -0000 Hi, I have a system running -CURRENT that in top(1) is showing ~20% CPU usage f= or the system at all times. Any ideas what could be causing this, or how I = would go about diagnosing this further? Nothing in the logs. Thanks, Lars PS: dmesg attached, in case it helps: Copyright (c) 1992-2013 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 10.0-CURRENT #11 r+2fc9b3d: Tue Feb 12 19:32:15 CET 2013 elars@stanley.muccbc.hq.netapp.com:/home/elars/obj/usr/home/elars/src/s= ys/FAS3270 amd64 FreeBSD clang version 3.2 (tags/RELEASE_32/final 170710) 20121221 CPU: Intel(R) Xeon(R) CPU E5240 @ 3.00GHz (3000.17-MHz K8-class = CPU) Origin =3D "GenuineIntel" Id =3D 0x1067a Family =3D 0x6 Model =3D 0x17= Stepping =3D 10 Features=3D0xbfebfbff Features2=3D0xc0ce3bd AMD Features=3D0x20100800 AMD Features2=3D0x1 TSC: P-state invariant, performance statistics real memory =3D 18253611008 (17408 MB) avail memory =3D 16526143488 (15760 MB) Event timer "LAPIC" quality 400 ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs FreeBSD/SMP: 2 package(s) x 2 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 6 cpu3 (AP): APIC ID: 7 ioapic0 irqs 0-23 on motherboard kbd0 at kbdmux0 ctl: CAM Target Layer loaded smbios0: at iomem 0xf6c00-0xf6c1e on motherboard smbios0: Version: 2.5 cryptosoft0: on motherboard acpi0: on motherboard acpi0: Power Button (fixed) cpu0: on acpi0 ACPI Error: [\134_SB_.PCI0.LPC0.BCMD] Namespace lookup failure, AE_NOT_FOUN= D (20130117/psargs-393) ACPI Error: Method parse/execution failed [\134_PR_.CPU0._OSC] (Node 0xffff= fe0007630c00), AE_NOT_FOUND (20130117/psparse-560) ACPI Error: [\134_SB_.PCI0.LPC0.BCMD] Namespace lookup failure, AE_NOT_FOUN= D (20130117/psargs-393) ACPI Error: Method parse/execution failed [\134_PR_.CPU0._OSC] (Node 0xffff= fe0007630c00), AE_NOT_FOUND (20130117/psparse-560) ACPI Error: Method parse/execution failed [\134_PR_.CPU0._PDC] (Node 0xffff= fe0007630c40), AE_NOT_FOUND (20130117/psparse-560) cpu1: on acpi0 cpu2: on acpi0 cpu3: on acpi0 atrtc0: port 0x70-0x71 irq 8 on acpi0 Event timer "RTC" frequency 32768 Hz quality 0 attimer0: port 0x40-0x43,0x50-0x53 irq 0 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 Event timer "i8254" frequency 1193182 Hz quality 100 Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: at device 2.0 on pci0 pci1: on pcib1 pci1: at device 0.0 (no driver attached) pcib2: at device 3.0 on pci0 pci2: on pcib2 pcib3: at device 4.0 on pci0 pci3: on pcib3 pcib4: mem 0xdeb00000-0xdeb1ffff irq 16 at device 0.0= on pci3 pci4: on pcib4 pcib4: no PRT entry for 4.4.INTA pcib4: no PRT entry for 4.5.INTA pcib4: no PRT entry for 4.8.INTA pcib5: irq 5 at device 4.0 on pci4 pci5: on pcib5 pcib6: irq 10 at device 5.0 on pci4 pci6: on pcib6 pcib4: no PRT entry for 4.5.INTA pcib4: no PRT entry for 4.5.INTB ix0: mem 0= xdec00000-0xdec7ffff,0xded00000-0xded03fff irq 10 at device 0.0 on pci6 ix0: Using MSIX interrupts with 5 vectors ix0: Ethernet address: 90:e2:ba:2b:3b:6c ix0: PCI Express Bus: Speed 5.0Gb/s Width x8 ix1: mem 0= xdec80000-0xdecfffff,0xded04000-0xded07fff irq 11 at device 0.1 on pci6 ix1: Using MSIX interrupts with 5 vectors ix1: Ethernet address: 90:e2:ba:2b:3b:6d ix1: PCI Express Bus: Speed 5.0Gb/s Width x8 pcib7: irq 5 at device 8.0 on pci4 pci7: on pcib7 pcib8: at device 5.0 on pci0 pci8: on pcib8 pcib9: at device 6.0 on pci0 pci9: on pcib9 pcib10: mem 0xdee00000-0xdee1ffff irq 16 at device 0.0 on = pci9 pci10: on pcib10 pcib11: irq 16 at device 0.0 on pci10 pci11: on pcib11 pcib12: mem 0xdef00000-0xdef1ffff irq 16 at device 0.0 on = pci11 pci12: on pcib12 pcib13: irq 17 at device 1.0 on pci12 pci13: on pcib13 pcib14: irq 16 at device 4.0 on pci12 pci14: on pcib14 pcib15: irq 17 at device 5.0 on pci12 pci15: on pcib15 pcib16: irq 16 at device 8.0 on pci12 pci16: on pcib16 pcib17: at device 0.0 on pci16 pci17: on pcib17 pcib18: at device 0.0 on pci17 pci18: on pcib18 em0: mem 0xdf020000-0xdf03ffff= ,0xdf000000-0xdf01ffff irq 16 at device 0.0 on pci18 em0: Using an MSI interrupt em0: Ethernet address: 00:1b:21:a8:a5:58 em1: mem 0xdf060000-0xdf07ffff= ,0xdf040000-0xdf05ffff irq 17 at device 0.1 on pci18 em1: Using an MSI interrupt em1: Ethernet address: 00:1b:21:a8:a5:59 pcib19: at device 1.0 on pci17 pci19: on pcib19 em2: mem 0xdf120000-0xdf13ffff= ,0xdf100000-0xdf11ffff irq 17 at device 0.0 on pci19 em2: Using an MSI interrupt em2: Ethernet address: 00:1b:21:a8:a5:5a em3: mem 0xdf160000-0xdf17ffff= ,0xdf140000-0xdf15ffff irq 18 at device 0.1 on pci19 em3: Using an MSI interrupt em3: Ethernet address: 00:1b:21:a8:a5:5b pcib20: irq 17 at device 9.0 on pci12 pci20: on pcib20 pcib21: mem 0xdf200000-0xdf21ffff irq 17 at device 0.0 on = pci20 pci21: on pcib21 pcib22: irq 17 at device 4.0 on pci21 pci22: on pcib22 pcib23: irq 18 at device 5.0 on pci21 pci23: on pcib23 pci23: at device 0.0 (no driver attached) pcib24: irq 17 at device 8.0 on pci21 pci24: on pcib24 pci24: at device 0.0 (no driver attached) pcib25: irq 16 at device 4.0 on pci10 pci25: on pcib25 pcib26: irq 17 at device 5.0 on pci10 pci26: on pcib26 pci26: at device 0.0 (no driver attached) pci26: at device 0.1 (no driver attached) pcib27: irq 18 at device 6.0 on pci10 pci27: on pcib27 pci27: at device 0.0 (no driver attached) pcib28: at device 7.0 on pci0 pci28: on pcib28 pci0: at device 8.0 (no driver attached) uhci0: port 0x1820-0x183f irq 16 at de= vice 26.0 on pci0 usbus0 on uhci0 ehci0: mem 0xdfa01000-0xdfa013ff i= rq 18 at device 26.7 on pci0 usbus1: EHCI version 1.0 usbus1 on ehci0 pcib29: irq 16 at device 28.0 on pci0 pci29: on pcib29 em4: port 0x3000-0x301f mem 0x= df720000-0xdf73ffff,0xdf700000-0xdf71ffff irq 16 at device 0.0 on pci29 em4: Using an MSI interrupt em4: Ethernet address: 00:a0:98:30:91:24 em5: port 0x3020-0x303f mem 0x= df760000-0xdf77ffff,0xdf740000-0xdf75ffff irq 17 at device 0.1 on pci29 em5: Using an MSI interrupt em5: Ethernet address: 00:a0:98:30:91:25 pcib30: irq 16 at device 28.4 on pci0 pci30: on pcib30 bge0: = mem 0xdf800000-0xdf80ffff irq 16 at device 0.0 on pci30 bge0: CHIP ID 0x00004201; ASIC REV 0x04; CHIP REV 0x42; PCI-E miibus0: on bge0 brgphy0: PHY 1 on miibus0 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000ba= seT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow bge0: Ethernet address: 00:a0:98:30:91:28 pcib31: irq 17 at device 28.5 on pci0 pci31: on pcib31 bge1: = mem 0xdf900000-0xdf90ffff irq 17 at device 0.0 on pci31 bge1: CHIP ID 0x00004201; ASIC REV 0x04; CHIP REV 0x42; PCI-E miibus1: on bge1 brgphy1: PHY 1 on miibus1 brgphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000ba= seT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow bge1: Ethernet address: 00:a0:98:30:91:29 uhci1: port 0x1840-0x185f irq 16 at de= vice 29.0 on pci0 usbus2 on uhci1 ehci1: mem 0xdfa01400-0xdfa017ff i= rq 16 at device 29.7 on pci0 usbus3: EHCI version 1.0 usbus3 on ehci1 pcib32: at device 30.0 on pci0 pci32: on pcib32 isab0: at device 31.0 on pci0 isa0: on isab0 ichsmb0: port 0x1860-0x187f mem 0xdf= a01800-0xdfa018ff irq 17 at device 31.3 on pci0 smbus0: on ichsmb0 smb0: on smbus0 pci0: at device 31.6 (no driver attached) acpi_button0: on acpi0 uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 uart0: console (9600,n,8,1) uart1: <16550 or compatible> port 0x2f8-0x2ff irq 3 on acpi0 ichwd0 on isa0 ichwd0: ICH WDT present but disabled in BIOS or hardware device_attach: ichwd0 attach returned 6 ipmi0: on isa0 ipmi0: KCS mode found at io 0xca2 alignment 0x1 on isa ichwd0 at port 0x1030-0x1037,0x1060-0x107f on isa0 ichwd0: ICH WDT present but disabled in BIOS or hardware device_attach: ichwd0 attach returned 6 orm0: at iomem 0xc0800-0xc17ff,0xc1800-0xc27ff,0xdc000-0x= dffff on isa0 coretemp0: on cpu0 est0: on cpu0 p4tcc0: on cpu0 coretemp1: on cpu1 est1: on cpu1 p4tcc1: on cpu1 coretemp2: on cpu2 est2: on cpu2 p4tcc2: on cpu2 coretemp3: on cpu3 est3: on cpu3 p4tcc3: on cpu3 Timecounters tick every 1.000 msec usbus0: 12Mbps Full Speed USB v1.0 usbus1: 480Mbps High Speed USB v2.0 ipfw2 (+ipv6) initialized, divert enabled, nat enabled, default to accept, = logging disabled ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 usbus2: 12Mbps Full Speed USB v1.0 usbus3: 480Mbps High Speed USB v2.0 ugen2.1: at usbus2 uhub2: on usbus2 ugen3.1: at usbus3 uhub3: on usbus3 ipmi0: IPMI device rev. 1, firmware rev. 1.00, version 2.0 ipmi0: Number of channels 0 ipmi0: Attached watchdog bootpc_init: wired to interface 'em4' Sending DHCP Discover packet from interface em4 (00:a0:98:30:91:24) uhub0: 2 ports with 2 removable, self powered uhub2: 2 ports with 2 removable, self powered uhub1: 2 ports with 2 removable, self powered uhub3: 2 ports with 2 removable, self powered ugen3.2: at usbus3 umass0: on usbus3 umass0: SCSI over Bulk-Only; quirks =3D 0x4000 umass0:1:0:-1: Attached to scbus1 da0 at umass-sim0 bus 0 scbus1 target 0 lun 0 da0: Fixed Direct Access SCSI-0 device=20 da0: 40.000MB/s transfers da0: 1936MB (3964928 512 byte sectors: 255H 63S/T 246C) Received DHCP Offer packet on em4 from 0.0.0.0 (accepted) (no root path) Sending DHCP Request packet from interface em4 (00:a0:98:30:91:24) Received DHCP Ack packet on em4 from 0.0.0.0 (accepted) (got root path) em4 at 10.11.12.5 server 0.0.0.0 subnet mask 255.255.255.0 router 10.11.12.13 rootfs 10.11.12.13:/usr/home/e= lars/dst=20 Adjusted interface em4 SMP: AP CPU #3 Launched! SMP: AP CPU #2 Launched! SMP: AP CPU #1 Launched! Timecounter "TSC-low" frequency 1500084729 Hz quality 1000 hwpmc: SOFT/16/64/0x67 TSC/1/64/0x20 IAP/2/40/0x3= ff IAF/3/40/0x67 Trying to mount root from nfs: []... NFS ROOT: 10.11.12.13:/usr/home/elars/dst= From owner-freebsd-current@FreeBSD.ORG Tue Feb 19 09:40:21 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id BF601B81 for ; Tue, 19 Feb 2013 09:40:21 +0000 (UTC) (envelope-from ml@my.gd) Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 280AEC2F for ; Tue, 19 Feb 2013 09:40:20 +0000 (UTC) Received: by mail-wg0-f50.google.com with SMTP id es5so5401407wgb.5 for ; Tue, 19 Feb 2013 01:40:20 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=h1jg41+MY+aPBF2U+75sxTXWUucu/bo1d6MH8LJKWZo=; b=mfbIgI+OEXWn9mpz+9up+QB9tNTrFa6/iPQcvhg4YoV05nxF3zGvwdz/qy8jjyzn98 +fEw6Eda4aNcx6XNXmCAoMPvAWBMRq6YYi/YOoq6JkeNWOWY0IBtiX9JVGM4Ti0bhO+l fJcsQpot8Y581xiHUpHBexSnSBk1Q52EDD0pyWaidLz4cvON4k0YNZ4Ncod/UUo5T3V9 yu2dyh6Y4ppimG2vuC+dMd0QeCl6fYUf5uz4GHoo51o9HHahc5HqteW5NRUYE+TT07/s mCMA7w3kfKhWFurmObhD8iWBAD6zwa7NqjsCTRIObxcGHJ32b8tTXm4/5Ef/35cW/zNq KIHA== X-Received: by 10.194.92.65 with SMTP id ck1mr24706165wjb.54.1361266820009; Tue, 19 Feb 2013 01:40:20 -0800 (PST) Received: from dfleuriot-at-hi-media.com ([83.167.62.196]) by mx.google.com with ESMTPS id bg5sm26604272wib.8.2013.02.19.01.40.17 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 19 Feb 2013 01:40:18 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: system 20% busy at all times? From: Fleuriot Damien In-Reply-To: Date: Tue, 19 Feb 2013 10:40:19 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "Eggert, Lars" X-Mailer: Apple Mail (2.1499) X-Gm-Message-State: ALoCoQkWBfReD4wdzjRurN0vu2KRHNBDEk7BG9pu5bBWI2djEgf5LTtjz7o6ENXKlTwiDRf6m7dW Cc: "current@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 19 Feb 2013 09:40:21 -0000 On Feb 19, 2013, at 10:36 AM, "Eggert, Lars" wrote: > Hi, >=20 > I have a system running -CURRENT that in top(1) is showing ~20% CPU = usage for the system at all times. Any ideas what could be causing this, = or how I would go about diagnosing this further? Nothing in the logs. >=20 > Thanks, > Lars >=20 > PS: dmesg attached, in case it helps: >=20 > Copyright (c) 1992-2013 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 10.0-CURRENT #11 r+2fc9b3d: Tue Feb 12 19:32:15 CET 2013 > = elars@stanley.muccbc.hq.netapp.com:/home/elars/obj/usr/home/elars/src/sys/= FAS3270 amd64 > FreeBSD clang version 3.2 (tags/RELEASE_32/final 170710) 20121221 > CPU: Intel(R) Xeon(R) CPU E5240 @ 3.00GHz (3000.17-MHz = K8-class CPU) > Origin =3D "GenuineIntel" Id =3D 0x1067a Family =3D 0x6 Model =3D = 0x17 Stepping =3D 10 > = Features=3D0xbfebfbff > = Features2=3D0xc0ce3bd > AMD Features=3D0x20100800 > AMD Features2=3D0x1 > TSC: P-state invariant, performance statistics > real memory =3D 18253611008 (17408 MB) > avail memory =3D 16526143488 (15760 MB) > Event timer "LAPIC" quality 400 > ACPI APIC Table: > FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs > FreeBSD/SMP: 2 package(s) x 2 core(s) > cpu0 (BSP): APIC ID: 0 > cpu1 (AP): APIC ID: 1 > cpu2 (AP): APIC ID: 6 > cpu3 (AP): APIC ID: 7 > ioapic0 irqs 0-23 on motherboard > kbd0 at kbdmux0 > ctl: CAM Target Layer loaded > smbios0: at iomem 0xf6c00-0xf6c1e on = motherboard > smbios0: Version: 2.5 > cryptosoft0: on motherboard > acpi0: on motherboard > acpi0: Power Button (fixed) > cpu0: on acpi0 > ACPI Error: [\134_SB_.PCI0.LPC0.BCMD] Namespace lookup failure, = AE_NOT_FOUND (20130117/psargs-393) > ACPI Error: Method parse/execution failed [\134_PR_.CPU0._OSC] (Node = 0xfffffe0007630c00), AE_NOT_FOUND (20130117/psparse-560) > ACPI Error: [\134_SB_.PCI0.LPC0.BCMD] Namespace lookup failure, = AE_NOT_FOUND (20130117/psargs-393) > ACPI Error: Method parse/execution failed [\134_PR_.CPU0._OSC] (Node = 0xfffffe0007630c00), AE_NOT_FOUND (20130117/psparse-560) > ACPI Error: Method parse/execution failed [\134_PR_.CPU0._PDC] (Node = 0xfffffe0007630c40), AE_NOT_FOUND (20130117/psparse-560) > cpu1: on acpi0 > cpu2: on acpi0 > cpu3: on acpi0 > atrtc0: port 0x70-0x71 irq 8 on acpi0 > Event timer "RTC" frequency 32768 Hz quality 0 > attimer0: port 0x40-0x43,0x50-0x53 irq 0 on acpi0 > Timecounter "i8254" frequency 1193182 Hz quality 0 > Event timer "i8254" frequency 1193182 Hz quality 100 > Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 > acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 > pcib0: port 0xcf8-0xcff on acpi0 > pci0: on pcib0 > pcib1: at device 2.0 on pci0 > pci1: on pcib1 > pci1: at device 0.0 (no driver attached) > pcib2: at device 3.0 on pci0 > pci2: on pcib2 > pcib3: at device 4.0 on pci0 > pci3: on pcib3 > pcib4: mem 0xdeb00000-0xdeb1ffff irq 16 at = device 0.0 on pci3 > pci4: on pcib4 > pcib4: no PRT entry for 4.4.INTA > pcib4: no PRT entry for 4.5.INTA > pcib4: no PRT entry for 4.8.INTA > pcib5: irq 5 at device 4.0 on pci4 > pci5: on pcib5 > pcib6: irq 10 at device 5.0 on pci4 > pci6: on pcib6 > pcib4: no PRT entry for 4.5.INTA > pcib4: no PRT entry for 4.5.INTB > ix0: = mem 0xdec00000-0xdec7ffff,0xded00000-0xded03fff irq 10 at device 0.0 on = pci6 > ix0: Using MSIX interrupts with 5 vectors > ix0: Ethernet address: 90:e2:ba:2b:3b:6c > ix0: PCI Express Bus: Speed 5.0Gb/s Width x8 > ix1: = mem 0xdec80000-0xdecfffff,0xded04000-0xded07fff irq 11 at device 0.1 on = pci6 > ix1: Using MSIX interrupts with 5 vectors > ix1: Ethernet address: 90:e2:ba:2b:3b:6d > ix1: PCI Express Bus: Speed 5.0Gb/s Width x8 > pcib7: irq 5 at device 8.0 on pci4 > pci7: on pcib7 > pcib8: at device 5.0 on pci0 > pci8: on pcib8 > pcib9: at device 6.0 on pci0 > pci9: on pcib9 > pcib10: mem 0xdee00000-0xdee1ffff irq 16 at device = 0.0 on pci9 > pci10: on pcib10 > pcib11: irq 16 at device 0.0 on pci10 > pci11: on pcib11 > pcib12: mem 0xdef00000-0xdef1ffff irq 16 at device = 0.0 on pci11 > pci12: on pcib12 > pcib13: irq 17 at device 1.0 on pci12 > pci13: on pcib13 > pcib14: irq 16 at device 4.0 on pci12 > pci14: on pcib14 > pcib15: irq 17 at device 5.0 on pci12 > pci15: on pcib15 > pcib16: irq 16 at device 8.0 on pci12 > pci16: on pcib16 > pcib17: at device 0.0 on pci16 > pci17: on pcib17 > pcib18: at device 0.0 on pci17 > pci18: on pcib18 > em0: mem = 0xdf020000-0xdf03ffff,0xdf000000-0xdf01ffff irq 16 at device 0.0 on = pci18 > em0: Using an MSI interrupt > em0: Ethernet address: 00:1b:21:a8:a5:58 > em1: mem = 0xdf060000-0xdf07ffff,0xdf040000-0xdf05ffff irq 17 at device 0.1 on = pci18 > em1: Using an MSI interrupt > em1: Ethernet address: 00:1b:21:a8:a5:59 > pcib19: at device 1.0 on pci17 > pci19: on pcib19 > em2: mem = 0xdf120000-0xdf13ffff,0xdf100000-0xdf11ffff irq 17 at device 0.0 on = pci19 > em2: Using an MSI interrupt > em2: Ethernet address: 00:1b:21:a8:a5:5a > em3: mem = 0xdf160000-0xdf17ffff,0xdf140000-0xdf15ffff irq 18 at device 0.1 on = pci19 > em3: Using an MSI interrupt > em3: Ethernet address: 00:1b:21:a8:a5:5b > pcib20: irq 17 at device 9.0 on pci12 > pci20: on pcib20 > pcib21: mem 0xdf200000-0xdf21ffff irq 17 at device = 0.0 on pci20 > pci21: on pcib21 > pcib22: irq 17 at device 4.0 on pci21 > pci22: on pcib22 > pcib23: irq 18 at device 5.0 on pci21 > pci23: on pcib23 > pci23: at device 0.0 (no driver attached) > pcib24: irq 17 at device 8.0 on pci21 > pci24: on pcib24 > pci24: at device 0.0 (no driver attached) > pcib25: irq 16 at device 4.0 on pci10 > pci25: on pcib25 > pcib26: irq 17 at device 5.0 on pci10 > pci26: on pcib26 > pci26: at device 0.0 (no driver attached) > pci26: at device 0.1 (no driver attached) > pcib27: irq 18 at device 6.0 on pci10 > pci27: on pcib27 > pci27: at device 0.0 (no driver attached) > pcib28: at device 7.0 on pci0 > pci28: on pcib28 > pci0: at device 8.0 (no driver attached) > uhci0: port 0x1820-0x183f irq 16 = at device 26.0 on pci0 > usbus0 on uhci0 > ehci0: mem = 0xdfa01000-0xdfa013ff irq 18 at device 26.7 on pci0 > usbus1: EHCI version 1.0 > usbus1 on ehci0 > pcib29: irq 16 at device 28.0 on pci0 > pci29: on pcib29 > em4: port 0x3000-0x301f = mem 0xdf720000-0xdf73ffff,0xdf700000-0xdf71ffff irq 16 at device 0.0 on = pci29 > em4: Using an MSI interrupt > em4: Ethernet address: 00:a0:98:30:91:24 > em5: port 0x3020-0x303f = mem 0xdf760000-0xdf77ffff,0xdf740000-0xdf75ffff irq 17 at device 0.1 on = pci29 > em5: Using an MSI interrupt > em5: Ethernet address: 00:a0:98:30:91:25 > pcib30: irq 16 at device 28.4 on pci0 > pci30: on pcib30 > bge0: mem 0xdf800000-0xdf80ffff irq 16 at device 0.0 on pci30 > bge0: CHIP ID 0x00004201; ASIC REV 0x04; CHIP REV 0x42; PCI-E > miibus0: on bge0 > brgphy0: PHY 1 on miibus0 > brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, = 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow > bge0: Ethernet address: 00:a0:98:30:91:28 > pcib31: irq 17 at device 28.5 on pci0 > pci31: on pcib31 > bge1: mem 0xdf900000-0xdf90ffff irq 17 at device 0.0 on pci31 > bge1: CHIP ID 0x00004201; ASIC REV 0x04; CHIP REV 0x42; PCI-E > miibus1: on bge1 > brgphy1: PHY 1 on miibus1 > brgphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, = 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow > bge1: Ethernet address: 00:a0:98:30:91:29 > uhci1: port 0x1840-0x185f irq 16 = at device 29.0 on pci0 > usbus2 on uhci1 > ehci1: mem = 0xdfa01400-0xdfa017ff irq 16 at device 29.7 on pci0 > usbus3: EHCI version 1.0 > usbus3 on ehci1 > pcib32: at device 30.0 on pci0 > pci32: on pcib32 > isab0: at device 31.0 on pci0 > isa0: on isab0 > ichsmb0: port 0x1860-0x187f mem = 0xdfa01800-0xdfa018ff irq 17 at device 31.3 on pci0 > smbus0: on ichsmb0 > smb0: on smbus0 > pci0: at device 31.6 (no driver attached) > acpi_button0: on acpi0 > uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on = acpi0 > uart0: console (9600,n,8,1) > uart1: <16550 or compatible> port 0x2f8-0x2ff irq 3 on acpi0 > ichwd0 on isa0 > ichwd0: ICH WDT present but disabled in BIOS or hardware > device_attach: ichwd0 attach returned 6 > ipmi0: on isa0 > ipmi0: KCS mode found at io 0xca2 alignment 0x1 on isa > ichwd0 at port 0x1030-0x1037,0x1060-0x107f on isa0 > ichwd0: ICH WDT present but disabled in BIOS or hardware > device_attach: ichwd0 attach returned 6 > orm0: at iomem = 0xc0800-0xc17ff,0xc1800-0xc27ff,0xdc000-0xdffff on isa0 > coretemp0: on cpu0 > est0: on cpu0 > p4tcc0: on cpu0 > coretemp1: on cpu1 > est1: on cpu1 > p4tcc1: on cpu1 > coretemp2: on cpu2 > est2: on cpu2 > p4tcc2: on cpu2 > coretemp3: on cpu3 > est3: on cpu3 > p4tcc3: on cpu3 > Timecounters tick every 1.000 msec > usbus0: 12Mbps Full Speed USB v1.0 > usbus1: 480Mbps High Speed USB v2.0 > ipfw2 (+ipv6) initialized, divert enabled, nat enabled, default to = accept, logging disabled > ugen0.1: at usbus0 > uhub0: on = usbus0 > ugen1.1: at usbus1 > uhub1: on = usbus1 > usbus2: 12Mbps Full Speed USB v1.0 > usbus3: 480Mbps High Speed USB v2.0 > ugen2.1: at usbus2 > uhub2: on = usbus2 > ugen3.1: at usbus3 > uhub3: on = usbus3 > ipmi0: IPMI device rev. 1, firmware rev. 1.00, version 2.0 > ipmi0: Number of channels 0 > ipmi0: Attached watchdog > bootpc_init: wired to interface 'em4' > Sending DHCP Discover packet from interface em4 (00:a0:98:30:91:24) > uhub0: 2 ports with 2 removable, self powered > uhub2: 2 ports with 2 removable, self powered > uhub1: 2 ports with 2 removable, self powered > uhub3: 2 ports with 2 removable, self powered > ugen3.2: at usbus3 > umass0: on usbus3 > umass0: SCSI over Bulk-Only; quirks =3D 0x4000 > umass0:1:0:-1: Attached to scbus1 > da0 at umass-sim0 bus 0 scbus1 target 0 lun 0 > da0: Fixed Direct Access SCSI-0 device=20 > da0: 40.000MB/s transfers > da0: 1936MB (3964928 512 byte sectors: 255H 63S/T 246C) > Received DHCP Offer packet on em4 from 0.0.0.0 (accepted) (no root = path) > Sending DHCP Request packet from interface em4 (00:a0:98:30:91:24) > Received DHCP Ack packet on em4 from 0.0.0.0 (accepted) (got root = path) > em4 at 10.11.12.5 server 0.0.0.0 > subnet mask 255.255.255.0 router 10.11.12.13 rootfs = 10.11.12.13:/usr/home/elars/dst=20 > Adjusted interface em4 > SMP: AP CPU #3 Launched! > SMP: AP CPU #2 Launched! > SMP: AP CPU #1 Launched! > Timecounter "TSC-low" frequency 1500084729 Hz quality 1000 > hwpmc: SOFT/16/64/0x67 TSC/1/64/0x20 = IAP/2/40/0x3ff = IAF/3/40/0x67 > Trying to mount root from nfs: []... > NFS ROOT: 10.11.12.13:/usr/home/elars/dst What about reviewing top(1) ? or possibly ps(1) aufx At least you should be able to see what takes up CPU: - system - user processes - interrupts Kindly attach at least your ps output :) From owner-freebsd-current@FreeBSD.ORG Tue Feb 19 09:45:02 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 6F2BCDA3 for ; Tue, 19 Feb 2013 09:45:02 +0000 (UTC) (envelope-from lars@netapp.com) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) by mx1.freebsd.org (Postfix) with ESMTP id 4916FCD8 for ; Tue, 19 Feb 2013 09:45:02 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.84,694,1355126400"; d="scan'208";a="23752910" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx12-out.netapp.com with ESMTP; 19 Feb 2013 01:44:55 -0800 Received: from vmwexceht02-prd.hq.netapp.com (vmwexceht02-prd.hq.netapp.com [10.106.76.240]) by smtp1.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id r1J9it8O016045; Tue, 19 Feb 2013 01:44:55 -0800 (PST) Received: from SACEXCMBX01-PRD.hq.netapp.com ([169.254.2.54]) by vmwexceht02-prd.hq.netapp.com ([10.106.76.240]) with mapi id 14.02.0328.009; Tue, 19 Feb 2013 01:44:55 -0800 From: "Eggert, Lars" To: Fleuriot Damien Subject: Re: system 20% busy at all times? Thread-Topic: system 20% busy at all times? Thread-Index: AQHODoSUIkOKNPDzb0yS23V/tl+kl5iBc1WAgAABSAA= Date: Tue, 19 Feb 2013 09:44:54 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.106.53.51] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "current@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 19 Feb 2013 09:45:02 -0000 Hi, On Feb 19, 2013, at 10:40, Fleuriot Damien wrote: > What about reviewing top(1) ? top shows the ~20% I mentioned: last pid: 3176; load averages: 0.79, 0.80, 0.84 = up 0+14:49:49= 09:43:51 17 processes: 1 running, 16 sleeping CPU: 0.0% user, 0.0% nice, 18.7% system, 0.0% interrupt, 81.3% idle Mem: 32M Active, 9456K Inact, 196M Wired, 19M Buf, 15G Free Swap:=20 PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAN= D 3002 root 1 20 0 14264K 1664K select 0 0:02 0.00% powerd 2999 root 1 20 0 25120K 3304K select 3 0:01 0.00% ntpd 3084 root 1 20 0 81420K 6120K select 0 0:00 0.00% sshd 3094 root 1 20 0 17180K 3956K pause 1 0:00 0.00% csh 3062 root 1 21 0 17180K 3900K ttyin 2 0:00 0.00% csh 2867 root 1 20 0 14296K 2028K select 1 0:00 0.00% syslog= d 2959 root 1 52 0 20500K 7512K rpcsvc 3 0:00 0.00% rpc.lo= ckd 2943 root 1 20 0 16376K 2064K select 2 0:00 0.00% rpcbin= d 3061 root 1 20 0 47504K 2604K wait 3 0:00 0.00% login 2945 root 1 20 0 274M 7448K select 1 0:00 0.00% rpc.st= atd 3176 root 1 20 0 19608K 2996K CPU3 1 0:00 0.00% top 2676 root 1 20 0 9016K 4652K select 0 0:00 0.00% devd 3014 root 1 20 0 56152K 4964K select 2 0:00 0.00% sshd 2562 root 1 29 0 14416K 2224K select 1 0:00 0.00% dhclie= nt 2629 _dhcp 1 20 0 14416K 2240K select 2 0:00 0.00% dhclie= nt 3065 root 1 20 0 14528K 1708K select 2 0:00 0.00% netser= ver 2708 root 1 20 0 14232K 1568K select 2 0:00 0.00% rtsold > or possibly ps(1) aufx # ps -aufx USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND root 10 346.8 0.0 0 64 - RL 6:54PM 2862:46.43 [idle] root 0 64.1 0.0 0 496 - DLs 6:54PM 694:47.32 [kernel] root 1 0.0 0.0 9344 792 - ILs 6:54PM 0:00.09 /sbin/init -- root 2 0.0 0.0 0 16 - DL 6:54PM 0:00.00 [crypto] root 3 0.0 0.0 0 16 - DL 6:54PM 0:00.00 [crypto retur= ns] root 4 0.0 0.0 0 16 - DL 6:54PM 0:00.00 [ctl_thrd] root 5 0.0 0.0 0 16 - DL 6:54PM 0:00.00 [xpt_thrd] root 6 0.0 0.0 0 16 - DL 6:54PM 0:00.00 [ipmi0: kcs] root 7 0.0 0.0 0 16 - DL 6:54PM 0:00.04 [pagedaemon] root 8 0.0 0.0 0 16 - DL 6:54PM 0:00.00 [pagezero] root 9 0.0 0.0 0 16 - DL 6:54PM 0:00.15 [bufdaemon] root 11 0.0 0.0 0 416 - WL 6:54PM 0:10.47 [intr] root 12 0.0 0.0 0 48 - DL 6:54PM 0:00.03 [geom] root 13 0.0 0.0 0 16 - DL 6:54PM 0:01.87 [yarrow] root 14 0.0 0.0 0 256 - DL 6:54PM 0:00.50 [usb] root 15 0.0 0.0 0 16 - DL 6:54PM 0:00.17 [vnlru] root 16 0.0 0.0 0 16 - DL 6:54PM 0:00.56 [syncer] root 17 0.0 0.0 0 16 - DL 6:54PM 0:00.21 [softdepflush= ] root 42 0.0 0.0 0 16 - DL 6:54PM 0:00.03 [md0] root 53 0.0 0.0 0 16 - DL 6:54PM 0:00.00 [md1] root 120 0.0 0.0 0 16 - DL 6:54PM 0:00.00 [md2] root 125 0.0 0.0 0 16 - DL 6:54PM 0:00.00 [md3] root 2562 0.0 0.0 14416 2224 - Is 6:54PM 0:00.00 dhclient: em4= [priv] (dhclient) _dhcp 2629 0.0 0.0 14416 2240 - Is 6:54PM 0:00.00 dhclient: em4= (dhclient) root 2676 0.0 0.0 9016 4652 - Is 6:54PM 0:00.01 /sbin/devd root 2708 0.0 0.0 14232 1568 - Is 6:54PM 0:00.00 /usr/sbin/rts= old -a root 2867 0.0 0.0 14296 2028 - Ss 6:54PM 0:00.04 /usr/sbin/sys= logd -s root 2943 0.0 0.0 16376 2064 - Ss 6:54PM 0:00.03 /usr/sbin/rpc= bind root 2945 0.0 0.0 280472 7448 - Ss 6:54PM 0:00.02 /usr/sbin/rpc= .statd root 2959 0.0 0.0 20500 7512 - Ss 6:54PM 0:00.04 /usr/sbin/rpc= .lockd root 2999 0.0 0.0 25120 3304 - Ss 6:54PM 0:00.85 /usr/sbin/ntp= d -g -c /etc/ntp.conf -p /var/run/ntpd.pid -f /var/db/ntpd.drift root 3002 0.0 0.0 14264 1664 - Ss 6:54PM 0:01.61 /usr/sbin/pow= erd root 3014 0.0 0.0 56152 4964 - Is 6:54PM 0:00.00 /usr/sbin/ssh= d -o PermitRootLogin=3Dwithout-password root 3065 0.0 0.0 14528 1708 - Is 6:54PM 0:00.00 netserver root 3084 0.0 0.0 81420 6120 - Ss 9:21AM 0:00.09 sshd: root@pt= s/0 (sshd) root 3061 0.0 0.0 47504 2604 u0 Is 6:54PM 0:00.02 login [pam] (= login) root 3062 0.0 0.0 17180 3900 u0 I+ 6:54PM 0:00.05 -csh (csh) root 3094 0.0 0.0 17180 3956 0 Ss 9:32AM 0:00.05 -csh (csh) root 3177 0.0 0.0 16436 1900 0 R+ 9:44AM 0:00.00 ps -aufx > At least you should be able to see what takes up CPU: > - system > - user processes > - interrupts # vmstat -i interrupt total rate irq3: uart1 11535 0 irq4: uart0 1227 0 irq9: acpi0 1989762564 37379 irq16: uhci0 uhci1+ 393 0 cpu0:timer 32147924 603 irq270: em4 1907258 35 cpu3:timer 63027976 1184 cpu2:timer 56428246 1060 cpu1:timer 44799884 841 Total 2188087007 41104 So it seems that irq 9 is firing a whole lot. Why? Thanks, Lars= From owner-freebsd-current@FreeBSD.ORG Tue Feb 19 09:54:38 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 785342E7 for ; Tue, 19 Feb 2013 09:54:38 +0000 (UTC) (envelope-from ml@my.gd) Received: from mail-wg0-f49.google.com (mail-wg0-f49.google.com [74.125.82.49]) by mx1.freebsd.org (Postfix) with ESMTP id 0FCE8D76 for ; Tue, 19 Feb 2013 09:54:37 +0000 (UTC) Received: by mail-wg0-f49.google.com with SMTP id 15so5204177wgd.28 for ; Tue, 19 Feb 2013 01:54:31 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=9hucVFXNLVKd027vzNXvydJF12POTddTkIY4Wh/u9rY=; b=fss+WRqGwn1KYBaDUR9MKFKzJ7PJYFXjxMYxRDRA0G/zDjJIoJZhEuLCskxnN5JGGK 111RhbMnNa0nl71uJjNCm/CxPH9yBhSMxlTLwOwVi4lRF+JPL78VEFbPM4VD6wu98H/u ugIwps3HkzxlC/cvZXv3PTp4j3m91AfL+GLIixFJJhA2RC6ldg7iyV+Lu70pq5RfLacp EibAi7hEw9+aDYE54u9MXnsQS2UYbMaiwy+/dQlmDA/QyAKqttodjjI143l/ax6TrCZN 592eK2FfvX3jkqiPuQWWF49/EwzSS1oOjDMDGTFjphIj0rS5eeHDSlGm3KgGy2FBmcdY xkXg== X-Received: by 10.180.107.70 with SMTP id ha6mr11032210wib.10.1361267671339; Tue, 19 Feb 2013 01:54:31 -0800 (PST) Received: from dfleuriot-at-hi-media.com ([83.167.62.196]) by mx.google.com with ESMTPS id cf8sm14181083wib.1.2013.02.19.01.54.29 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 19 Feb 2013 01:54:30 -0800 (PST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: system 20% busy at all times? From: Fleuriot Damien In-Reply-To: Date: Tue, 19 Feb 2013 10:54:31 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <36DD2FB4-E26A-4F03-95D9-FFD855957269@my.gd> References: To: "Eggert, Lars" X-Mailer: Apple Mail (2.1499) X-Gm-Message-State: ALoCoQn0MiljYngA8pz/+hpDItUGfmnB1La6kJVAEiWtTvw9g4U9XVPgrARuiLsia4K99Nuy9IxZ Cc: "current@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 19 Feb 2013 09:54:38 -0000 On Feb 19, 2013, at 10:44 AM, "Eggert, Lars" wrote: > Hi, >=20 > On Feb 19, 2013, at 10:40, Fleuriot Damien > wrote: >> What about reviewing top(1) ? >=20 > top shows the ~20% I mentioned: >=20 > last pid: 3176; load averages: 0.79, 0.80, 0.84 = up = 0+14:49:49 09:43:51 > 17 processes: 1 running, 16 sleeping > CPU: 0.0% user, 0.0% nice, 18.7% system, 0.0% interrupt, 81.3% idle > Mem: 32M Active, 9456K Inact, 196M Wired, 19M Buf, 15G Free > Swap:=20 >=20 Ok the ~20% is from the system itself. >=20 >> or possibly ps(1) aufx >=20 > # ps -aufx > USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND > root 10 346.8 0.0 0 64 - RL 6:54PM 2862:46.43 [idle] > root 0 64.1 0.0 0 496 - DLs 6:54PM 694:47.32 [kernel] >=20 65% of a CPU core only for the kernel... >=20 >=20 >> At least you should be able to see what takes up CPU: >> - system >> - user processes >> - interrupts >=20 > # vmstat -i > interrupt total rate > irq3: uart1 11535 0 > irq4: uart0 1227 0 > irq9: acpi0 1989762564 37379 > irq16: uhci0 uhci1+ 393 0 > cpu0:timer 32147924 603 > irq270: em4 1907258 35 > cpu3:timer 63027976 1184 > cpu2:timer 56428246 1060 > cpu1:timer 44799884 841 > Total 2188087007 41104 >=20 > So it seems that irq 9 is firing a whole lot. Why? And indeed we find your answer here, acpi0 firing up a lot of = interrupts. Don't you get any message about that in dmesg -a or /var/log/messages ? I'd expect something like "interrupt storm blabla=85 source throttled = blabla.." =46rom man 4 acpi , in /boot/loader.conf : hint.acpi.0.disabled=3D1 Set this to 1 to disable all of ACPI. If ACPI has been = disabled on your system due to a blacklist entry for your BIOS, you = can set this to 0 to re-enable ACPI for testing. Any chance you could reboot the host with ACPI disabled ? If that helps your CPU load, try setting this in /boot/loader.conf : hw.acpi.verbose=3D1 Turn on verbose debugging information about what ACPI is doing. Hoping this gets some logs :) From owner-freebsd-current@FreeBSD.ORG Tue Feb 19 10:16:56 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 3591AD81 for ; Tue, 19 Feb 2013 10:16:56 +0000 (UTC) (envelope-from lars@netapp.com) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) by mx1.freebsd.org (Postfix) with ESMTP id 19D151B9 for ; Tue, 19 Feb 2013 10:16:55 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.84,694,1355126400"; d="scan'208";a="23761864" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx12-out.netapp.com with ESMTP; 19 Feb 2013 02:16:55 -0800 Received: from vmwexceht03-prd.hq.netapp.com (vmwexceht03-prd.hq.netapp.com [10.106.76.241]) by smtp1.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id r1JAGt0c024203; Tue, 19 Feb 2013 02:16:55 -0800 (PST) Received: from SACEXCMBX01-PRD.hq.netapp.com ([169.254.2.54]) by vmwexceht03-prd.hq.netapp.com ([10.106.76.241]) with mapi id 14.02.0328.009; Tue, 19 Feb 2013 02:16:55 -0800 From: "Eggert, Lars" To: Fleuriot Damien Subject: Re: system 20% busy at all times? Thread-Topic: system 20% busy at all times? Thread-Index: AQHODoSUIkOKNPDzb0yS23V/tl+kl5iBc1WAgAABSACAAAKwgIAABj+A Date: Tue, 19 Feb 2013 10:16:54 +0000 Message-ID: References: <36DD2FB4-E26A-4F03-95D9-FFD855957269@my.gd> In-Reply-To: <36DD2FB4-E26A-4F03-95D9-FFD855957269@my.gd> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.106.53.51] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "current@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 19 Feb 2013 10:16:56 -0000 Hi, On Feb 19, 2013, at 10:54, Fleuriot Damien wrote: > And indeed we find your answer here, acpi0 firing up a lot of interrupts. >=20 > Don't you get any message about that in dmesg -a or /var/log/messages ? >=20 > I'd expect something like "interrupt storm blabla=85 source throttled bla= bla.." nope. The only odd ACPI-related messages I see in dmesg are these: ACPI Error: [\134_SB_.PCI0.LPC0.BCMD] Namespace lookup failure, AE_NOT_FOUN= D (20130117/psargs-393) ACPI Error: Method parse/execution failed [\134_PR_.CPU0._OSC] (Node 0xffff= fe0007630c00), AE_NOT_FOUND (20130117/psparse-560) ACPI Error: [\134_SB_.PCI0.LPC0.BCMD] Namespace lookup failure, AE_NOT_FOUN= D (20130117/psargs-393) ACPI Error: Method parse/execution failed [\134_PR_.CPU0._OSC] (Node 0xffff= fe0007630c00), AE_NOT_FOUND (20130117/psparse-560) ACPI Error: Method parse/execution failed [\134_PR_.CPU0._PDC] (Node 0xffff= fe0007630c40), AE_NOT_FOUND (20130117/psparse-560) Nothing in syslog. > From man 4 acpi , in /boot/loader.conf : > hint.acpi.0.disabled=3D1 > Set this to 1 to disable all of ACPI. If ACPI has been disab= led > on your system due to a blacklist entry for your BIOS, you ca= n > set this to 0 to re-enable ACPI for testing. >=20 > Any chance you could reboot the host with ACPI disabled ? If I do that, I get an early kernel crash: Loading 10.11.12.13/~elars/kernel/kernel:0x200000/7634255 0xb47d50/473552 0= xbbb720/890736 Entry at 0x802746f0 Closing network. Starting program at 0x802746f0 GDB: no debug ports present KDB: debugger backends: ddb KDB: current backend: ddb panic: running without device atpic requires a local APIC cpuid =3D 0 KDB: stack backtrace: kernel trap 12 with interrupts disabled Fatal trap 12: page fault while in kernel mode cpuid =3D 0; apic id =3D 00 fault virtual address =3D 0x0 fault code =3D supervisor read data, page not present instruction pointer =3D 0x20:0xffffffff805c2973 stack pointer =3D 0x28:0xffffffff80c9a960 frame pointer =3D 0x28:0xffffffff80c9aa80 code segment =3D base 0x0, limit 0xfffff, type 0x1b =3D DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags =3D resume, IOPL =3D 0 current process =3D 0 () [ thread pid 0 tid 0 ] Stopped at 0xffffffff805c2973: movzbl (%rdi),%ecx > If that helps your CPU load, try setting this in /boot/loader.conf : > hw.acpi.verbose=3D1 > Turn on verbose debugging information about what ACPI is doing. Done, but it doesn't really result in any additional messages: # dmesg | grep -i acpi Features=3D0xbfebfbff ACPI APIC Table: acpi0: on motherboard acpi0: Power Button (fixed) cpu0: on acpi0 ACPI Error: [\134_SB_.PCI0.LPC0.BCMD] Namespace lookup failure, AE_NOT_FOUN= D (20130117/psargs-393) ACPI Error: Method parse/execution failed [\134_PR_.CPU0._OSC] (Node 0xffff= fe0007630c00), AE_NOT_FOUND (20130117/psparse-560) ACPI Error: [\134_SB_.PCI0.LPC0.BCMD] Namespace lookup failure, AE_NOT_FOUN= D (20130117/psargs-393) ACPI Error: Method parse/execution failed [\134_PR_.CPU0._OSC] (Node 0xffff= fe0007630c00), AE_NOT_FOUND (20130117/psparse-560) ACPI Error: Method parse/execution failed [\134_PR_.CPU0._PDC] (Node 0xffff= fe0007630c40), AE_NOT_FOUND (20130117/psparse-560) cpu1: on acpi0 cpu2: on acpi0 cpu3: on acpi0 atrtc0: port 0x70-0x71 irq 8 on acpi0 attimer0: port 0x40-0x43,0x50-0x53 irq 0 on acpi0 Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: at device 2.0 on pci0 pci1: on pcib1 pcib3: at device 4.0 on pci0 pci3: on pcib3 pcib4: mem 0xdeb00000-0xdeb1ffff irq 16 at device 0.0= on pci3 pci4: on pcib4 pcib7: irq 5 at device 8.0 on pci4 pci7: on pcib7 pcib29: irq 16 at device 28.0 on pci0 pci29: on pcib29 pcib30: irq 16 at device 28.4 on pci0 pci30: on pcib30 pcib31: irq 17 at device 28.5 on pci0 pci31: on pcib31 pcib32: at device 30.0 on pci0 pci32: on pcib32 acpi_button0: on acpi0 uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 uart1: <16550 or compatible> port 0x2f8-0x2ff irq 3 on acpi0 Lars From owner-freebsd-current@FreeBSD.ORG Tue Feb 19 10:21:21 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 4F0B8EFE for ; Tue, 19 Feb 2013 10:21:21 +0000 (UTC) (envelope-from ml@my.gd) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by mx1.freebsd.org (Postfix) with ESMTP id D9C79201 for ; Tue, 19 Feb 2013 10:21:20 +0000 (UTC) Received: by mail-wi0-f178.google.com with SMTP id o1so4579317wic.11 for ; Tue, 19 Feb 2013 02:21:19 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=CzgsnYXrHYRRs2uCN+6jJJtLv2lDz6O4ixc0Y//4cvs=; b=VFJDPtQPTSnSy6RhkYMOYjZLMohjoy0QNX2szyb4GkAmZjCgoKmckdFF3Wlji5U2x/ UBXnJ823gZSWogCMjqxA3I2YPMuCoeAPTDAl0iH9Cctcf+06BFzSYtp27d/hZh4AQtFu VDSKpV6xlfoYDJY04fZQLhzisr+hfWbzY971dm0o3QxeYduH0MF/cfPncUb9ndsz9WiP 0fNXIAIPhWxFyDgXQV+DBetWz8P7oTcEH1W3Mrgkx3g6ASYhOBhsUsr1PNJbuiAu4SIu Z5olwGEseD7uXZSmOvaOzyJdG8WY8YO81evafCkQdiGY8Pnv5IBRuoGg6dugJOCpUjqz YWbA== X-Received: by 10.194.108.229 with SMTP id hn5mr25169313wjb.8.1361269270142; Tue, 19 Feb 2013 02:21:10 -0800 (PST) Received: from dfleuriot-at-hi-media.com ([83.167.62.196]) by mx.google.com with ESMTPS id m6sm26829947wic.2.2013.02.19.02.21.08 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 19 Feb 2013 02:21:09 -0800 (PST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: system 20% busy at all times? From: Fleuriot Damien In-Reply-To: Date: Tue, 19 Feb 2013 11:21:10 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <8F861CF6-D0FA-4BD2-B73D-24CB247584A1@my.gd> References: <36DD2FB4-E26A-4F03-95D9-FFD855957269@my.gd> To: "Eggert, Lars" X-Mailer: Apple Mail (2.1499) X-Gm-Message-State: ALoCoQnKBeGpQjKMBgNTLR4yETf+FRpKPiSk0q4bKn9RSeLge9mRdzLOL13ySaYkGHR+AD0qOMg5 Cc: "current@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 19 Feb 2013 10:21:21 -0000 On Feb 19, 2013, at 11:16 AM, "Eggert, Lars" wrote: > Hi, >=20 > On Feb 19, 2013, at 10:54, Fleuriot Damien > wrote: >> And indeed we find your answer here, acpi0 firing up a lot of = interrupts. >>=20 >> Don't you get any message about that in dmesg -a or /var/log/messages = ? >>=20 >> I'd expect something like "interrupt storm blabla=85 source throttled = blabla.." >=20 > nope. The only odd ACPI-related messages I see in dmesg are these: >=20 > ACPI Error: [\134_SB_.PCI0.LPC0.BCMD] Namespace lookup failure, = AE_NOT_FOUND (20130117/psargs-393) > ACPI Error: Method parse/execution failed [\134_PR_.CPU0._OSC] (Node = 0xfffffe0007630c00), AE_NOT_FOUND (20130117/psparse-560) > ACPI Error: [\134_SB_.PCI0.LPC0.BCMD] Namespace lookup failure, = AE_NOT_FOUND (20130117/psargs-393) > ACPI Error: Method parse/execution failed [\134_PR_.CPU0._OSC] (Node = 0xfffffe0007630c00), AE_NOT_FOUND (20130117/psparse-560) > ACPI Error: Method parse/execution failed [\134_PR_.CPU0._PDC] (Node = 0xfffffe0007630c40), AE_NOT_FOUND (20130117/psparse-560) >=20 > Nothing in syslog. >=20 >> =46rom man 4 acpi , in /boot/loader.conf : >> hint.acpi.0.disabled=3D1 >> Set this to 1 to disable all of ACPI. If ACPI has been = disabled >> on your system due to a blacklist entry for your BIOS, you = can >> set this to 0 to re-enable ACPI for testing. >>=20 >> Any chance you could reboot the host with ACPI disabled ? >=20 > If I do that, I get an early kernel crash: >=20 > Loading 10.11.12.13/~elars/kernel/kernel:0x200000/7634255 = 0xb47d50/473552 0xbbb720/890736 Entry at 0x802746f0 > Closing network. > Starting program at 0x802746f0 > GDB: no debug ports present > KDB: debugger backends: ddb > KDB: current backend: ddb > panic: running without device atpic requires a local APIC > cpuid =3D 0 > KDB: stack backtrace: > kernel trap 12 with interrupts disabled >=20 >=20 > Fatal trap 12: page fault while in kernel mode > cpuid =3D 0; apic id =3D 00 > fault virtual address =3D 0x0 > fault code =3D supervisor read data, page not present > instruction pointer =3D 0x20:0xffffffff805c2973 > stack pointer =3D 0x28:0xffffffff80c9a960 > frame pointer =3D 0x28:0xffffffff80c9aa80 > code segment =3D base 0x0, limit 0xfffff, type 0x1b > =3D DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags =3D resume, IOPL =3D 0 > current process =3D 0 () > [ thread pid 0 tid 0 ] > Stopped at 0xffffffff805c2973: movzbl (%rdi),%ecx >=20 >=20 >> If that helps your CPU load, try setting this in /boot/loader.conf : >> hw.acpi.verbose=3D1 >> Turn on verbose debugging information about what ACPI is doing. >=20 > Done, but it doesn't really result in any additional messages: >=20 > # dmesg | grep -i acpi > = Features=3D0xbfebfbff > ACPI APIC Table: > acpi0: on motherboard > acpi0: Power Button (fixed) > cpu0: on acpi0 > ACPI Error: [\134_SB_.PCI0.LPC0.BCMD] Namespace lookup failure, = AE_NOT_FOUND (20130117/psargs-393) > ACPI Error: Method parse/execution failed [\134_PR_.CPU0._OSC] (Node = 0xfffffe0007630c00), AE_NOT_FOUND (20130117/psparse-560) > ACPI Error: [\134_SB_.PCI0.LPC0.BCMD] Namespace lookup failure, = AE_NOT_FOUND (20130117/psargs-393) > ACPI Error: Method parse/execution failed [\134_PR_.CPU0._OSC] (Node = 0xfffffe0007630c00), AE_NOT_FOUND (20130117/psparse-560) > ACPI Error: Method parse/execution failed [\134_PR_.CPU0._PDC] (Node = 0xfffffe0007630c40), AE_NOT_FOUND (20130117/psparse-560) > cpu1: on acpi0 > cpu2: on acpi0 > cpu3: on acpi0 > atrtc0: port 0x70-0x71 irq 8 on acpi0 > attimer0: port 0x40-0x43,0x50-0x53 irq 0 on acpi0 > Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 > acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 > pcib0: port 0xcf8-0xcff on acpi0 > pci0: on pcib0 > pcib1: at device 2.0 on pci0 > pci1: on pcib1 > pcib3: at device 4.0 on pci0 > pci3: on pcib3 > pcib4: mem 0xdeb00000-0xdeb1ffff irq 16 at = device 0.0 on pci3 > pci4: on pcib4 > pcib7: irq 5 at device 8.0 on pci4 > pci7: on pcib7 > pcib29: irq 16 at device 28.0 on pci0 > pci29: on pcib29 > pcib30: irq 16 at device 28.4 on pci0 > pci30: on pcib30 > pcib31: irq 17 at device 28.5 on pci0 > pci31: on pcib31 > pcib32: at device 30.0 on pci0 > pci32: on pcib32 > acpi_button0: on acpi0 > uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on = acpi0 > uart1: <16550 or compatible> port 0x2f8-0x2ff irq 3 on acpi0 >=20 Jeez, I certainly hope people more knowledgeable than me about the = kernel will be able to make something of all this. What about a newly build kernel without the line "device acpi" and = without the options ACPI_DEBUG ? Hoping that this kernel: 1/ won't crash on boot 2/ will make the 20% cpu load and high interrupt rates disappear From owner-freebsd-current@FreeBSD.ORG Tue Feb 19 10:26:37 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id F0FBA283 for ; Tue, 19 Feb 2013 10:26:37 +0000 (UTC) (envelope-from uqs@FreeBSD.org) Received: from acme.spoerlein.net (acme.spoerlein.net [IPv6:2a01:4f8:131:23c2::1]) by mx1.freebsd.org (Postfix) with ESMTP id 8A35A24D for ; Tue, 19 Feb 2013 10:26:37 +0000 (UTC) Received: from localhost (acme.spoerlein.net [IPv6:2a01:4f8:131:23c2::1]) by acme.spoerlein.net (8.14.6/8.14.6) with ESMTP id r1JAQYAm028985 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 19 Feb 2013 11:26:35 +0100 (CET) (envelope-from uqs@FreeBSD.org) Date: Tue, 19 Feb 2013 11:26:34 +0100 From: Ulrich =?utf-8?B?U3DDtnJsZWlu?= To: Matt Burke Subject: Re: [PATCH] Minor spelling error in sound/pci/hda Message-ID: <20130219102634.GF35868@acme.spoerlein.net> Mail-Followup-To: Matt Burke , freebsd-current@freebsd.org References: <511CC6C6.4080009@icritical.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <511CC6C6.4080009@icritical.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 19 Feb 2013 10:26:38 -0000 On Thu, 2013-02-14 at 11:13:10 +0000, Matt Burke wrote: > Only a simple spelling error, but it's been driving me nuts... > > > --- a/sys/dev/sound/pci/hda/hdaa.c > +++ b/sys/dev/sound/pci/hda/hdaa.c > @@ -557,7 +557,7 @@ hdaa_presence_handler(struct hdaa_widget *w) > HDA_BOOTVERBOSE( > if (connected || old != 2) { > device_printf(devinfo->dev, > - "Pin sense: nid=%d sence=0x%08x (%sconnected)\n", > + "Pin sense: nid=%d sense=0x%08x (%sconnected)\n", > w->nid, res, !connected ? "dis" : ""); > } > ); > @@ -706,7 +706,7 @@ hdaa_eld_handler(struct hdaa_widget *w) > } > HDA_BOOTVERBOSE( > device_printf(devinfo->dev, > - "Pin sense: nid=%d sence=0x%08x " > + "Pin sense: nid=%d sense=0x%08x " > "(%sconnected, ELD %svalid)\n", > w->nid, res, > (res & HDA_CMD_GET_PIN_SENSE_PRESENCE_DETECT) ? "" : "dis", Committed, thanks! Uli From owner-freebsd-current@FreeBSD.ORG Tue Feb 19 10:27:47 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 19CB23A7 for ; Tue, 19 Feb 2013 10:27:47 +0000 (UTC) (envelope-from simon@comsys.ntu-kpi.kiev.ua) Received: from comsys.kpi.ua (comsys.kpi.ua [77.47.192.42]) by mx1.freebsd.org (Postfix) with ESMTP id C898C26C for ; Tue, 19 Feb 2013 10:27:46 +0000 (UTC) Received: from pm513-1.comsys.kpi.ua ([10.18.52.101] helo=pm513-1.comsys.ntu-kpi.kiev.ua) by comsys.kpi.ua with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1U7kQJ-0007Pa-SL; Tue, 19 Feb 2013 12:27:43 +0200 Received: by pm513-1.comsys.ntu-kpi.kiev.ua (Postfix, from userid 1001) id 3D5921CC1E; Tue, 19 Feb 2013 12:27:44 +0200 (EET) Date: Tue, 19 Feb 2013 12:27:44 +0200 From: Andrey Simonenko To: Elias Martenson Subject: Re: Possible bug in NFSv4 with krb5p security? Message-ID: <20130219102744.GA2426@pm513-1.comsys.ntu-kpi.kiev.ua> References: <477291850.3084864.1361113135205.JavaMail.root@erie.cs.uoguelph.ca> <20130219093142.GA1459@pm513-1.comsys.ntu-kpi.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Authenticated-User: simon@comsys.ntu-kpi.kiev.ua X-Authenticator: plain X-Sender-Verify: SUCCEEDED (sender exists & accepts mail) X-Exim-Version: 4.63 (build at 28-Apr-2011 07:11:12) X-Date: 2013-02-19 12:27:43 X-Connected-IP: 10.18.52.101:19328 X-Message-Linecount: 90 X-Body-Linecount: 70 X-Message-Size: 3637 X-Body-Size: 2599 Cc: Rick Macklem , Benjamin Kaduk , freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 19 Feb 2013 10:27:47 -0000 On Tue, Feb 19, 2013 at 05:35:50PM +0800, Elias Martenson wrote: > On 19 February 2013 17:31, Andrey Simonenko wrote: > > It can require bigger buffer, since root can get the pw_password field > > in the struct passwd{}. > > > > Since sysconf(_SC_GETPW_R_SIZE_MAX) does not work on FreeBSD, the buffer > > for getpwnam_r() call should have at least (2 * MAXLOGNAME + 2 * > > MAXPATHLEN + > > _PASSWORD_LEN + 1) bytes (it is unclear how much is required for pw_gecos). > > > > This buffer can be dynamically reallocated until getpwnam_r() is not > > return ERANGE error (the following code has not been compiled and > > verified): > > > > Is this really a better solution than to aim high right away? A series of > malloc() calls should certainly have much higher overhead than the previous > stack-allocated solution. > > A better compromise would be to do the lookup in a separate function, that > allocates the buffer using alloca() instead, yes? I cannot find how to get information about maximum buffer size for the getpwnam_r() function. This information should be returned by sysconf(_SC_GETPW_R_SIZE_MAX), but since it does not work on FreeBSD it is necessary to guess its size. Original value is 128 and it works for somebody, 1024 works for your environment, but it can fail for another environment. SUSv4 specifies "Storage referenced by the structure is allocated from the memory provided with the buffer parameter", but then tells about groups in EXAMPLE for getpwnam_r() "Note that sysconf(_SC_GETPW_R_SIZE_MAX) may return -1 if there is no hard limit on the size of the buffer needed to store all the groups returned". malloc() can give overhead, but that function can try to call getpwnam_r() with buffer allocated from stack and if getpwnam_r() failed with ERANGE use dynamically allocated buffer. #define PWBUF_SIZE_INI (2 * MAXLOGNAME + 2 * MAXPATHLEN + _PASSWORD_LEN + 1) #define PWBUF_SIZE_INC 128 char bufs[2 * MAXLOGNAME + MAXPATHLEN + PASSWORD_LEN + 1 + 32]; error = getpwnam_r(lname, &pwd, bufs, sizeof(bufs), &pw); if (pw != NULL) { *uidp = pw->pw_uid; return (GSS_S_COMPLETE); } else if (error != ERANGE) return (GSS_S_FAILURE); size = PWBUF_SIZE_INI; for (;;) { size += PWBUF_SIZE_INC; buf = malloc(size); if (buf == NULL) return (GSS_S_FAILURE); error = getpwnam_r(lname, &pwd, buf, size, &pw); free(buf); if (pw != NULL) { *uidp = pw->pw_uid; return (GSS_S_COMPLETE); } else { if (error == ERANGE && size <= SIZE_MAX - PWBUF_SIZE_INC) continue; return (GSS_S_FAILURE); } } From owner-freebsd-current@FreeBSD.ORG Tue Feb 19 10:27:59 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 011C64AE for ; Tue, 19 Feb 2013 10:27:58 +0000 (UTC) (envelope-from lars@netapp.com) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) by mx1.freebsd.org (Postfix) with ESMTP id BA675274 for ; Tue, 19 Feb 2013 10:27:58 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.84,694,1355126400"; d="scan'208";a="23764784" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx12-out.netapp.com with ESMTP; 19 Feb 2013 02:27:58 -0800 Received: from vmwexceht05-prd.hq.netapp.com (vmwexceht05-prd.hq.netapp.com [10.106.77.35]) by smtp1.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id r1JARw1Z006327; Tue, 19 Feb 2013 02:27:58 -0800 (PST) Received: from VMWEXCEHT06-PRD.hq.netapp.com (10.106.77.104) by vmwexceht05-prd.hq.netapp.com (10.106.77.35) with Microsoft SMTP Server (TLS) id 14.2.328.9; Tue, 19 Feb 2013 02:27:57 -0800 Received: from SACEXCMBX01-PRD.hq.netapp.com ([169.254.2.54]) by vmwexceht06-prd.hq.netapp.com ([10.106.77.104]) with mapi id 14.02.0328.009; Tue, 19 Feb 2013 02:27:57 -0800 From: "Eggert, Lars" To: Fleuriot Damien Subject: Re: system 20% busy at all times? Thread-Topic: system 20% busy at all times? Thread-Index: AQHODoSUIkOKNPDzb0yS23V/tl+kl5iBc1WAgAABSACAAAKwgIAABj+AgAABMwCAAAHkAA== Date: Tue, 19 Feb 2013 10:27:56 +0000 Message-ID: References: <36DD2FB4-E26A-4F03-95D9-FFD855957269@my.gd> <8F861CF6-D0FA-4BD2-B73D-24CB247584A1@my.gd> In-Reply-To: <8F861CF6-D0FA-4BD2-B73D-24CB247584A1@my.gd> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.106.53.51] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "current@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 19 Feb 2013 10:27:59 -0000 Hi, On Feb 19, 2013, at 11:21, Fleuriot Damien wrote: > What about a newly build kernel without the line "device acpi" and withou= t the options ACPI_DEBUG ? > Hoping that this kernel: > 1/ won't crash on boot > 2/ will make the 20% cpu load and high interrupt rates disappear I added "device atpic" to my kernel config and rebooted with hint.acpi.0.di= sabled=3D1 in the loader. I get further during boot, but then get a "panic:= No usable event timer found!" Also, my is devices showed errors trying to = allocate bus resources. Lars= From owner-freebsd-current@FreeBSD.ORG Tue Feb 19 11:14:55 2013 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 4F9A3D31 for ; Tue, 19 Feb 2013 11:14:55 +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 9884D680 for ; Tue, 19 Feb 2013 11:14:54 +0000 (UTC) Received: from porto.starpoint.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 NAA12202; Tue, 19 Feb 2013 13:14:49 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1U7l9t-00052C-0a; Tue, 19 Feb 2013 13:14:49 +0200 Message-ID: <51235EA7.6000208@FreeBSD.org> Date: Tue, 19 Feb 2013 13:14:47 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130121 Thunderbird/17.0.2 MIME-Version: 1.0 To: "Eggert, Lars" Subject: Re: system 20% busy at all times? References: <36DD2FB4-E26A-4F03-95D9-FFD855957269@my.gd> <8F861CF6-D0FA-4BD2-B73D-24CB247584A1@my.gd> In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "current@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 19 Feb 2013 11:14:55 -0000 Completely disabling ACPI rarely works with modern machines. Please try to run the following DTrace script (dtrace -s script-file) and capture its output. #pragma D option flowindent fbt::acpi_intr_handler:entry { self->trace = 1; } fbt:::entry /self->trace/ { printf("arg0 = %#x, arg1 = %#x, arg2 = %#x", arg0, arg1, arg2); } fbt:::return /self->trace/ { printf("@%p ret = %u", arg0, arg1); } fbt::acpi_intr_handler:return { self->trace = 0; exit(0); } -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Tue Feb 19 11:57:34 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id BEBB6716; Tue, 19 Feb 2013 11:57:34 +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 7A9FB801; Tue, 19 Feb 2013 11:57:34 +0000 (UTC) Received: from ds4.des.no (smtp.des.no [194.63.250.102]) by smtp-int.des.no (Postfix) with ESMTP id 54EAA6B00; Tue, 19 Feb 2013 11:57:26 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id 2F6E69428; Tue, 19 Feb 2013 12:57:26 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: "Constantine A. Murenin" Subject: Re: announcing mdoc.su, short manual page URLs References: <20130219082700.GA9938@Cns.Cns.SU> Date: Tue, 19 Feb 2013 12:57:26 +0100 In-Reply-To: <20130219082700.GA9938@Cns.Cns.SU> (Constantine A. Murenin's message of "Tue, 19 Feb 2013 00:27:01 -0800") Message-ID: <86k3q4zfbt.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-doc@FreeBSD.org, freebsd-current@FreeBSD.org, freebsd-chat@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 19 Feb 2013 11:57:34 -0000 "Constantine A. Murenin" writes: > I would like to announce and introduce , a > deterministic URL shortener for BSD manual pages, written entirely in > nginx.conf. [...] This looks awesome, thank you very much! DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Tue Feb 19 12:12:40 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 5B503E11; Tue, 19 Feb 2013 12:12:40 +0000 (UTC) (envelope-from lars@netapp.com) Received: from mx1.netapp.com (mx1.netapp.com [216.240.18.38]) by mx1.freebsd.org (Postfix) with ESMTP id 3E748901; Tue, 19 Feb 2013 12:12:40 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.84,695,1355126400"; d="scan'208";a="242445850" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx1-out.netapp.com with ESMTP; 19 Feb 2013 04:12:34 -0800 Received: from vmwexceht01-prd.hq.netapp.com (vmwexceht01-prd.hq.netapp.com [10.106.76.239]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id r1JCCYUr015977; Tue, 19 Feb 2013 04:12:34 -0800 (PST) Received: from SACEXCMBX01-PRD.hq.netapp.com ([169.254.2.54]) by vmwexceht01-prd.hq.netapp.com ([10.106.76.239]) with mapi id 14.02.0328.009; Tue, 19 Feb 2013 04:12:34 -0800 From: "Eggert, Lars" To: Andriy Gapon Subject: Re: system 20% busy at all times? Thread-Topic: system 20% busy at all times? Thread-Index: AQHODoSUIkOKNPDzb0yS23V/tl+kl5iBc1WAgAABSACAAAKwgIAABj+AgAABMwCAAAHkAIAADReAgAAQIgA= Date: Tue, 19 Feb 2013 12:12:32 +0000 Message-ID: References: <36DD2FB4-E26A-4F03-95D9-FFD855957269@my.gd> <8F861CF6-D0FA-4BD2-B73D-24CB247584A1@my.gd> <51235EA7.6000208@FreeBSD.org> In-Reply-To: <51235EA7.6000208@FreeBSD.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.106.53.51] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <2F2594DDABF2364C85B2A788B8E6BECB@tahoe.netapp.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "current@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 19 Feb 2013 12:12:40 -0000 Hi, thanks for looking into this! On Feb 19, 2013, at 12:14, Andriy Gapon wrote: > Please try to run the following DTrace script (dtrace -s script-file) and > capture its output. I get this error: # dtrace -s x dtrace: failed to compile script x: "/usr/lib/dtrace/psinfo.d", line 90: fa= iled to resolve type kernel`struct thread * for identifier curthread: Modul= e is no longer loaded (New to dtrace, so no clue what this means.) Lars= From owner-freebsd-current@FreeBSD.ORG Tue Feb 19 12:15:47 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 3994AFED for ; Tue, 19 Feb 2013 12:15:47 +0000 (UTC) (envelope-from lars@e-new.0x20.net) Received: from mail.0x20.net (mail.0x20.net [217.69.76.211]) by mx1.freebsd.org (Postfix) with ESMTP id D946893D for ; Tue, 19 Feb 2013 12:15:46 +0000 (UTC) Received: from e-new.0x20.net (mail.0x20.net [IPv6:2001:aa8:fffb:1::3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.0x20.net (Postfix) with ESMTPS id 128556A601E; Tue, 19 Feb 2013 13:15:45 +0100 (CET) Received: from e-new.0x20.net (localhost [127.0.0.1]) by e-new.0x20.net (8.14.5/8.14.5) with ESMTP id r1JCFiM1033710; Tue, 19 Feb 2013 13:15:44 +0100 (CET) (envelope-from lars@e-new.0x20.net) Received: (from lars@localhost) by e-new.0x20.net (8.14.5/8.14.5/Submit) id r1JCFiYj033256; Tue, 19 Feb 2013 13:15:44 +0100 (CET) (envelope-from lars) Date: Tue, 19 Feb 2013 13:15:44 +0100 From: Lars Engels To: "Eggert, Lars" Subject: Re: system 20% busy at all times? Message-ID: <20130219121544.GU83110@e-new.0x20.net> References: <36DD2FB4-E26A-4F03-95D9-FFD855957269@my.gd> <8F861CF6-D0FA-4BD2-B73D-24CB247584A1@my.gd> <51235EA7.6000208@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="YMf7pJGz0wcApMUv" Content-Disposition: inline In-Reply-To: X-Editor: VIM - Vi IMproved 7.3 X-Operation-System: FreeBSD 8.3-RELEASE-p4 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "current@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 19 Feb 2013 12:15:47 -0000 --YMf7pJGz0wcApMUv Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Feb 19, 2013 at 12:12:32PM +0000, Eggert, Lars wrote: > Hi, >=20 > thanks for looking into this! >=20 > On Feb 19, 2013, at 12:14, Andriy Gapon wrote: > > Please try to run the following DTrace script (dtrace -s script-file) a= nd > > capture its output. >=20 > I get this error: >=20 > # dtrace -s x > dtrace: failed to compile script x: "/usr/lib/dtrace/psinfo.d", line 90: = failed to resolve type kernel`struct thread * for identifier curthread: Mod= ule is no longer loaded >=20 > (New to dtrace, so no clue what this means.) You need to recompile your Kernel to use DTrace: https://wiki.freebsd.org/DTrace The other Lars :) --YMf7pJGz0wcApMUv Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlEjbPAACgkQKc512sD3afhpSACcD/Rkc4cA/F1xyWXg2McEa5++ 0XAAoIEB45gIDLpcogCDBB3YyQn3vK6H =QHQs -----END PGP SIGNATURE----- --YMf7pJGz0wcApMUv-- From owner-freebsd-current@FreeBSD.ORG Tue Feb 19 08:27:03 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 3A310630; Tue, 19 Feb 2013 08:27:03 +0000 (UTC) (envelope-from cnst++@FreeBSD.org) Received: from Cns.Cns.SU (unknown [IPv6:2001:470:7240::]) by mx1.freebsd.org (Postfix) with ESMTP id B8ECA6B4; Tue, 19 Feb 2013 08:27:02 +0000 (UTC) Received: from Cns.Cns.SU (cnst@localhost [127.0.0.1]) by Cns.Cns.SU (8.14.5/8.14.5) with ESMTP id r1J8R17I007714; Tue, 19 Feb 2013 00:27:01 -0800 (PST) Received: (from cnst@localhost) by Cns.Cns.SU (8.14.5/8.14.5/Submit) id r1J8R1rs023311; Tue, 19 Feb 2013 00:27:01 -0800 (PST) X-Authentication-Warning: Cns.Cns.SU: cnst set sender to cnst++@FreeBSD.org using -f Date: Tue, 19 Feb 2013 00:27:01 -0800 From: "Constantine A. Murenin" To: freebsd-chat@FreeBSD.org, freebsd-current@FreeBSD.org, freebsd-doc@FreeBSD.org Subject: announcing mdoc.su, short manual page URLs Message-ID: <20130219082700.GA9938@Cns.Cns.SU> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-Mailman-Approved-At: Tue, 19 Feb 2013 12:20:03 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 19 Feb 2013 08:27:03 -0000 Dear freebsd-{chat,current,doc}@, I would like to announce and introduce , a deterministic URL shortener for BSD manual pages, written entirely in nginx.conf. It supports several address schemes, for example: http://mdoc.su/f/zfs http://mdoc.su/f/zfs.8 http://mdoc.su/f/8/zfs http://mdoc.su/freebsd/zfs http://mdoc.su/FreeBSD/zfs http://mdoc.su/d/hammer.5 http://mdoc.su/d/hammer.8 etc. Source code for the whole mdoc.su.nginx.conf is available at: https://github.com/cnst/mdoc.su https://bitbucket.org/cnst/mdoc.su Specifically, the following currently controls FreeBSD rewriting: location /FreeBSD { rewrite ^/FreeBSD(/.*)?$ /f$1; } location /f { set $fb "http://www.freebsd.org/cgi/man.cgi?query="; set $fs "&sektion="; rewrite ^/freebsd(/.*)?$ /.$1; rewrite ^/./([^/.]+)/([^/]+)$ $fb$2$fs$1 redirect; rewrite ^/./([^/]+)\.([1-9])$ $fb$1$fs$2 redirect; rewrite ^/./([^/]+)$ $fb$1$fs redirect; rewrite ^/./?$ / last; return 404; } Translation: "/FreeBSD" and "/freebsd" get rewritten to "/f" internally, without any extra replies to the user, and then the rest of the URI is analysed, and a "302 Found" redirect is finally issued to the user. Pages like http://mdoc.su/f/ redirect to the main "/" page internally, without affecting the URL that's visible to the user, making it easier to keep a starting page specifically for one BSD. Questions, comments and suggestions are very welcome. Available through IPv4 and IPv6. Enjoy! Best regards, Constantine. From owner-freebsd-current@FreeBSD.ORG Tue Feb 19 12:37:31 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 58247417 for ; Tue, 19 Feb 2013 12:37:31 +0000 (UTC) (envelope-from lars@netapp.com) Received: from mx1.netapp.com (mx1.netapp.com [216.240.18.38]) by mx1.freebsd.org (Postfix) with ESMTP id 3BB4EA13 for ; Tue, 19 Feb 2013 12:37:30 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.84,695,1355126400"; d="scan'208";a="242451013" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx1-out.netapp.com with ESMTP; 19 Feb 2013 04:37:31 -0800 Received: from vmwexceht04-prd.hq.netapp.com (vmwexceht04-prd.hq.netapp.com [10.106.77.34]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id r1JCbT5X013928; Tue, 19 Feb 2013 04:37:30 -0800 (PST) Received: from SACEXCMBX01-PRD.hq.netapp.com ([169.254.2.54]) by vmwexceht04-prd.hq.netapp.com ([10.106.77.34]) with mapi id 14.02.0328.009; Tue, 19 Feb 2013 04:37:30 -0800 From: "Eggert, Lars" To: Lars Engels Subject: Re: system 20% busy at all times? Thread-Topic: system 20% busy at all times? Thread-Index: AQHODoSUIkOKNPDzb0yS23V/tl+kl5iBc1WAgAABSACAAAKwgIAABj+AgAABMwCAAAHkAIAADReAgAAQIgCAAADlAIAABhMA Date: Tue, 19 Feb 2013 12:37:28 +0000 Message-ID: References: <36DD2FB4-E26A-4F03-95D9-FFD855957269@my.gd> <8F861CF6-D0FA-4BD2-B73D-24CB247584A1@my.gd> <51235EA7.6000208@FreeBSD.org> <20130219121544.GU83110@e-new.0x20.net> In-Reply-To: <20130219121544.GU83110@e-new.0x20.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.106.53.51] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "current@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 19 Feb 2013 12:37:31 -0000 Hi, On Feb 19, 2013, at 13:15, Lars Engels wrote: > You need to recompile your Kernel to use DTrace: > https://wiki.freebsd.org/DTrace I did. But I still get that error, even with the sample from the wiki: # dtrace -n 'syscall:::entry { @num[execname] =3D count(); }' dtrace: invalid probe specifier syscall:::entry { @num[execname] =3D count(= ); }: "/usr/lib/dtrace/psinfo.d", line 90: failed to resolve type kernel`st= ruct thread * for identifier curthread: Module is no longer loaded I cross-compile the -CURRENT world and kernel under -STABLE for netbooting.= Could doing that cause this issue? Lars= From owner-freebsd-current@FreeBSD.ORG Tue Feb 19 13:27:48 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 86FFE618 for ; Tue, 19 Feb 2013 13:27:48 +0000 (UTC) (envelope-from lars@netapp.com) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) by mx1.freebsd.org (Postfix) with ESMTP id 69B06D3F for ; Tue, 19 Feb 2013 13:27:48 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.84,695,1355126400"; d="scan'208";a="23833076" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx12-out.netapp.com with ESMTP; 19 Feb 2013 05:27:46 -0800 Received: from vmwexceht04-prd.hq.netapp.com (vmwexceht04-prd.hq.netapp.com [10.106.77.34]) by smtp1.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id r1JDRkEF011185; Tue, 19 Feb 2013 05:27:46 -0800 (PST) Received: from SACEXCMBX01-PRD.hq.netapp.com ([169.254.2.54]) by vmwexceht04-prd.hq.netapp.com ([10.106.77.34]) with mapi id 14.02.0328.009; Tue, 19 Feb 2013 05:27:46 -0800 From: "Eggert, Lars" To: Lars Engels Subject: Re: system 20% busy at all times? Thread-Topic: system 20% busy at all times? Thread-Index: AQHODoSUIkOKNPDzb0yS23V/tl+kl5iBc1WAgAABSACAAAKwgIAABj+AgAABMwCAAAHkAIAADReAgAAQIgCAAADlAIAABhMAgAAOCwA= Date: Tue, 19 Feb 2013 13:27:45 +0000 Message-ID: References: <36DD2FB4-E26A-4F03-95D9-FFD855957269@my.gd> <8F861CF6-D0FA-4BD2-B73D-24CB247584A1@my.gd> <51235EA7.6000208@FreeBSD.org> <20130219121544.GU83110@e-new.0x20.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.106.53.51] Content-Type: text/plain; charset="us-ascii" Content-ID: <45E884206902B945AFCFC544CF71BE17@tahoe.netapp.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "current@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 19 Feb 2013 13:27:48 -0000 Hi, On Feb 19, 2013, at 13:37, "Eggert, Lars" wrote: > On Feb 19, 2013, at 13:15, Lars Engels wrote: >> You need to recompile your Kernel to use DTrace: >> https://wiki.freebsd.org/DTrace >=20 > I did. But I still get that error, even with the sample from the wiki: >=20 > # dtrace -n 'syscall:::entry { @num[execname] =3D count(); }' > dtrace: invalid probe specifier syscall:::entry { @num[execname] =3D coun= t(); }: "/usr/lib/dtrace/psinfo.d", line 90: failed to resolve type kernel`= struct thread * for identifier curthread: Module is no longer loaded >=20 > I cross-compile the -CURRENT world and kernel under -STABLE for netbootin= g. Could doing that cause this issue? FWIW, a full buildworld/installworld of the latest -CURRENT also didn't hel= p, the error remains. Lars= From owner-freebsd-current@FreeBSD.ORG Tue Feb 19 13:49:21 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id A38C2EE7; Tue, 19 Feb 2013 13:49:21 +0000 (UTC) (envelope-from lars@netapp.com) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) by mx1.freebsd.org (Postfix) with ESMTP id 87BD6E4C; Tue, 19 Feb 2013 13:49:21 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.84,695,1355126400"; d="scan'208";a="23846549" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx12-out.netapp.com with ESMTP; 19 Feb 2013 05:49:21 -0800 Received: from vmwexceht03-prd.hq.netapp.com (vmwexceht03-prd.hq.netapp.com [10.106.76.241]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id r1JDnKlG003813; Tue, 19 Feb 2013 05:49:21 -0800 (PST) Received: from SACEXCMBX01-PRD.hq.netapp.com ([169.254.2.54]) by vmwexceht03-prd.hq.netapp.com ([10.106.76.241]) with mapi id 14.02.0328.009; Tue, 19 Feb 2013 05:49:21 -0800 From: "Eggert, Lars" To: Monthadar Al Jaberi Subject: Re: Dtrace: Module is no longer loaded Thread-Topic: Dtrace: Module is no longer loaded Thread-Index: AQHNtcLm1S6KYZ4TpEy+jQm/JkH2r5fQtzwAgAAZWQCAAAQdgIAAChUAgLGLo4A= Date: Tue, 19 Feb 2013 13:49:20 +0000 Message-ID: References: <508E98E1.7010502@FreeBSD.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.106.53.51] Content-Type: text/plain; charset="us-ascii" Content-ID: <0881D6B546F7DD47A97667B58D64CFC2@tahoe.netapp.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: freebsd-current , Ryan Stone , Andriy Gapon X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 19 Feb 2013 13:49:21 -0000 Hi, did you ever figure this out? I'm seeing the same thing. Lars From owner-freebsd-current@FreeBSD.ORG Tue Feb 19 14:22:52 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 9EF9D9D for ; Tue, 19 Feb 2013 14:22:52 +0000 (UTC) (envelope-from simon@qxnitro.org) Received: from mail-oa0-f48.google.com (mail-oa0-f48.google.com [209.85.219.48]) by mx1.freebsd.org (Postfix) with ESMTP id 6DF468D9 for ; Tue, 19 Feb 2013 14:22:52 +0000 (UTC) Received: by mail-oa0-f48.google.com with SMTP id j1so6923867oag.21 for ; Tue, 19 Feb 2013 06:22:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qxnitro.org; s=google; h=mime-version:x-received:x-originating-ip:date:message-id:subject :from:to:cc:content-type; bh=Rc56hNhmAhpbsaYlCBUyDBtTQ7JEkYLTDRrXSRCfgSI=; b=jzbNBEWPCA4nNWR8jWtcN+URB4GK5rmbHo+FH9dWyd2YuFNDTEcxF0LTGkzlr/40ym umy6yDZv13xSLUnQqm4W+fLZsq87dNm33++Hhoh7XTtuv85xS723C2//cYkSVmrq6LvI 6fJWS4M2U0i7hBrr2YD96oGdMHI+eQp1QXpV0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:date:message-id:subject :from:to:cc:content-type:x-gm-message-state; bh=Rc56hNhmAhpbsaYlCBUyDBtTQ7JEkYLTDRrXSRCfgSI=; b=CBTPvKvK1hv5hcwR/dmJEmhc+MIyT+QHnRJWzm6ODWGLEUp9cDv4hskc35gT4QeW9A 9iOTy/pdkvZGUiwS0q1qR9GWPkik5mZ+qMdDszdK7Ni8M+NEp3XLVPslBWTBmVdsG1xc 5lY5oWpnl5jSmvKP+4omhrUJd7I/gAdN7LwEftTuf2hnqCUzG4muhdHAZ18RNPfmEQE2 z7DvVt5sNb0JpYXpWzUKxZp6OzOagl7a2w9LqIhTwLClnt4JftGMTGV8GHHW971m6N52 lgP2Ru/G7Un4p4Tvix7rWzFc3x9l5irufbbrkNr5Qi+n8sjaqgNHVtM8+rzfkLoP/v/R 9CDQ== MIME-Version: 1.0 X-Received: by 10.182.159.98 with SMTP id xb2mr7892928obb.35.1361283765900; Tue, 19 Feb 2013 06:22:45 -0800 (PST) Received: by 10.76.86.41 with HTTP; Tue, 19 Feb 2013 06:22:45 -0800 (PST) X-Originating-IP: [2620:0:1040:407:742d:a4be:df21:4d26] Date: Tue, 19 Feb 2013 14:22:45 +0000 Message-ID: Subject: r246916 probably broke amd64 build From: "Simon L. B. Nielsen" To: mav@FreeBSD.org Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQnbVrWeVR3nHySxuBPo8duwq0H+rdCZmUd9h/MVguxoZ8AMQFb7/lnMqi3fzNKvhnAtmNt4 X-Mailman-Approved-At: Tue, 19 Feb 2013 14:44:43 +0000 Cc: freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 19 Feb 2013 14:22:52 -0000 Hey, I think r246916 broke the build. I get the following when building amd64 kernel: cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -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 -fdiagnostics-show-option -nostdinc -I. -I/usr/src/sys -I/usr/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 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror /usr/src/sys/x86/isa/clock.c cc1: warnings being treated as errors /usr/src/sys/x86/isa/clock.c: In function 'set_i8254_freq': /usr/src/sys/x86/isa/clock.c:409: warning: 'new_mode' may be used uninitialized in this function Could you have a look? Thanks. -- Simon L. B. Nielsen From owner-freebsd-current@FreeBSD.ORG Tue Feb 19 15:03:25 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id B09BF438 for ; Tue, 19 Feb 2013 15:03: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 04136BD8 for ; Tue, 19 Feb 2013 15:03:24 +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 RAA15183; Tue, 19 Feb 2013 17:03:19 +0200 (EET) (envelope-from avg@FreeBSD.org) Message-ID: <51239437.2020503@FreeBSD.org> Date: Tue, 19 Feb 2013 17:03:19 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130206 Thunderbird/17.0.2 MIME-Version: 1.0 To: "Eggert, Lars" Subject: Re: Dtrace: Module is no longer loaded References: <508E98E1.7010502@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Monthadar Al Jaberi , freebsd-current , Ryan Stone X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 19 Feb 2013 15:03:25 -0000 on 19/02/2013 15:49 Eggert, Lars said the following: > Hi, > > did you ever figure this out? I'm seeing the same thing. Couple of thoughts: - is your kernel installed in the typical location? - what does the following produce? readelf -a -W /boot/kernel/kernel | fgrep shstrtab readelf -a -W /boot/kernel/kernel | fgrep SUNW_ctf -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Tue Feb 19 15:28:50 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id B35CABA9 for ; Tue, 19 Feb 2013 15:28:50 +0000 (UTC) (envelope-from cpghost@cordula.ws) Received: from mail-pa0-f41.google.com (mail-pa0-f41.google.com [209.85.220.41]) by mx1.freebsd.org (Postfix) with ESMTP id 799E4D8F for ; Tue, 19 Feb 2013 15:28:50 +0000 (UTC) Received: by mail-pa0-f41.google.com with SMTP id fb11so3443191pad.14 for ; Tue, 19 Feb 2013 07:28:50 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding:x-gm-message-state; bh=phhJ20imlx3Uv1pwVrSIFMPU2hzi6EQwImCyiR3Df1M=; b=NfdS5r3k5plVuXnZg2YpQZwTKV6+boGfox574JcL+YiRF5KhRkHtdjz6TKtUz//tIr QEiJJtAD5lYqizdgNmF5SGr2SY1Ep7uOpsqpv49eYIsZWLm9z3zSCJxyR/HF7xYVAMUP ACUEDAo9PpmYmTP0szkUBkbzJVewbPyTVUocwTxkl9tV3yazDqYXPglO5MwSi6I3tbN3 Q/aCENppDTsxrJdg0OzU+W8rCo8O0QUXB/9f1inmJb4DGh+4lHcelXohvNOwOdzvwuFb BSXZHi3HIKlolG1PRmraIC2+UkbQ418DsU3zUqIqxbZXm90FAebUWQ1NNm/P5tKMuXfm BAXg== MIME-Version: 1.0 X-Received: by 10.68.224.225 with SMTP id rf1mr41987331pbc.9.1361287730120; Tue, 19 Feb 2013 07:28:50 -0800 (PST) Received: by 10.68.58.194 with HTTP; Tue, 19 Feb 2013 07:28:49 -0800 (PST) X-Originating-IP: [93.221.172.178] In-Reply-To: <86k3q4zfbt.fsf@ds4.des.no> References: <20130219082700.GA9938@Cns.Cns.SU> <86k3q4zfbt.fsf@ds4.des.no> Date: Tue, 19 Feb 2013 16:28:49 +0100 Message-ID: Subject: Re: announcing mdoc.su, short manual page URLs From: "C. P. Ghost" To: =?ISO-8859-1?Q?Dag=2DErling_Sm=F8rgrav?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQnrTbpAxzGPc8NNO0o1GNXOHq7/zGwQsjfGzeiWe3lAMCB7616iHhrRq4oDQ8Y20LXe0Vsr Cc: freebsd-doc@freebsd.org, "Constantine A. Murenin" , freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 19 Feb 2013 15:28:50 -0000 On Tue, Feb 19, 2013 at 12:57 PM, Dag-Erling Sm=F8rgrav wrote: > "Constantine A. Murenin" writes: >> I would like to announce and introduce , a >> deterministic URL shortener for BSD manual pages, written entirely in >> nginx.conf. [...] > > This looks awesome, thank you very much! Does that mean that linking to FreeBSD manpages would soon require shorter URLs than those imposed by man.cgi? That would be awesome (as long as it doesn't break the old URLs, of course). > DES > -- > Dag-Erling Sm=F8rgrav - des@des.no -cpghost. --=20 Cordula's Web. http://www.cordula.ws/ From owner-freebsd-current@FreeBSD.ORG Tue Feb 19 16:21:56 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id E8E9E363 for ; Tue, 19 Feb 2013 16:21:56 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: from nm30-vm4.bullet.mail.ne1.yahoo.com (nm30-vm4.bullet.mail.ne1.yahoo.com [98.138.91.190]) by mx1.freebsd.org (Postfix) with ESMTP id 944AF151 for ; Tue, 19 Feb 2013 16:21:56 +0000 (UTC) Received: from [98.138.90.49] by nm30.bullet.mail.ne1.yahoo.com with NNFMP; 19 Feb 2013 16:21:49 -0000 Received: from [98.138.89.240] by tm2.bullet.mail.ne1.yahoo.com with NNFMP; 19 Feb 2013 16:21:49 -0000 Received: from [127.0.0.1] by omp1013.mail.ne1.yahoo.com with NNFMP; 19 Feb 2013 16:21:49 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 609841.61070.bm@omp1013.mail.ne1.yahoo.com Received: (qmail 41730 invoked by uid 60001); 19 Feb 2013 16:21:49 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1361290909; bh=Z+wv8OSgj47AFbfe5TcXV1FhKNKNSzV8pfjMEr1GNUI=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=b2FCrafDcKYHjqdCbStZIXTUZ7bCNa1XxIM1bbUv9qcTFyKsrpVonyGjeDHqaSj1ZKV+iP4j+XirUEE4vrbCP88dNfXdx4Z8q3oLOChPjBdqEt/ECw+WGN9RJf+R5Fb/WOlxH9x9TeifBJkA/GiNqVulzcBg/R//wbpYFJCGpq4= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=1+7xa9C+zDfuM0veVn+l/CLay7rUk8oLW+dkVhgf54Wcoj83bivZyfSyy+r68473Js+n0DMBuByns4fCiCtfSochjFhlV3MRFATsZV3CuMrYxH7YJ3jirDYeOcFonLkjpxN92hGNomIB6gN6zWt1JL4aO/N+aQ6Xqxxr1Nc9BIc=; X-YMail-OSG: CJH1Rx8VM1kTHT.GNBHegKfprzsWnz1E2nm1N5y7meizZDS ija9VGeHi.6eyKk3x320QGp8_TbJl8GnMkxgGxurQABaIrAAdoySMUZDmdEY jRZ9akpAX0foDuFKunQVW0zwU4zJCQ5usTXltz9EgEEYEBUz8wKc0VgDT6CU P6KBg4Rfu8DsQQ23iLRHWB3TECx20C7E4pEn8MZ2spNliToGq6XINaP29T5c VUkcAHp1RQ3WT1cP_l9jErUeu2bvicj8JWtFp5d0hl0_aTrR6n2cE53kG9ks WpsJWN7zHPf1f8TdxyrKiKQcNpHZrf2MmnQ2I6.sM9dJBmngSQs_WUU1cZqW S0h9UKYCEmJMz_3I15SXjsj0b9692cIydPbZoNlvfoRUiOKJ8thfpP0mYTZc rk1RoO2Jmj.Ix.TG6hO0AEB4gpxXog6m40swKtj0nZgONiomBPzUkMAR4n_u kRsAYHqDmqpiv2rvf381Del2X58gouwKYY6kPwsBnU5BXJcxImWtUz7tAxWN z7w_vYqrQ4Jo1QRGFg07zfbGzETMXKyvb.fqhCUBd_IObs3ybY6TrmC6ff3W O_WRku0jMxrXzaxAZOacorzrf7YWBSeMSN7cPWkunNQtmoWg- Received: from [208.102.228.236] by web121603.mail.ne1.yahoo.com via HTTP; Tue, 19 Feb 2013 08:21:49 PST X-Rocket-MIMEInfo: 001.001, aHR0cDovL3d3dy5iYXVlci1tYy5kZS9sbGNma3JyL3QyY3gzZWx6eXZmcS9oNms1Z3hrbjh2d2pqMmR2cGYBMAEBAQE- X-Mailer: YahooMailWebService/0.8.134.513 Message-ID: <1361290909.39265.YahooMailNeo@web121603.mail.ne1.yahoo.com> Date: Tue, 19 Feb 2013 08:21:49 -0800 (PST) From: Barney Cordoba Subject: Barney Cordoba To: freebsd-net@freebsd.org, erichsfreebsdlist , linimon , freebsd-isp@freebsd.org, khatfield , squid-users-subscribe@squid-cache.org, friends , freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Barney Cordoba List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2013 16:21:57 -0000 http://www.bauer-mc.de/llcfkrr/t2cx3elzyvfq/h6k5gxkn8vwjj2dvpf From owner-freebsd-current@FreeBSD.ORG Tue Feb 19 16:21:59 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 30022365 for ; Tue, 19 Feb 2013 16:21:59 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: from nm19-vm3.bullet.mail.ne1.yahoo.com (nm19-vm3.bullet.mail.ne1.yahoo.com [98.138.91.149]) by mx1.freebsd.org (Postfix) with ESMTP id B99C8153 for ; Tue, 19 Feb 2013 16:21:58 +0000 (UTC) Received: from [98.138.90.57] by nm19.bullet.mail.ne1.yahoo.com with NNFMP; 19 Feb 2013 16:21:52 -0000 Received: from [98.138.89.197] by tm10.bullet.mail.ne1.yahoo.com with NNFMP; 19 Feb 2013 16:21:52 -0000 Received: from [127.0.0.1] by omp1055.mail.ne1.yahoo.com with NNFMP; 19 Feb 2013 16:21:52 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 55557.57640.bm@omp1055.mail.ne1.yahoo.com Received: (qmail 41796 invoked by uid 60001); 19 Feb 2013 16:21:50 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1361290910; bh=grorc43x3UQ6v99+SiVmBAc4QcSPiaT2PF9U2BPtTzo=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=6YkPlAVHicFbS5fkekAnmqO4TNSOqDQgck7QQlbN78Yu2ow1k7NWe8oUYIzR5q6oetocRbBslISHE15B1MkJ+Bg3jR9SbQ5AYDzu9IygyfxujN9HDS1dJXGm+zUvT8vBSf0mLYZPOYQymFxIIQ9+p0yWZyCHgfy2/TFGy0ayTzY= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=NxviEqYd9NMt61cjiW0zgVy5SGHzqqJSKeR0guvWXrd3S6iI4V4PhjY7BRroIBovomQGdUhrW7r6xurg5ZG6YGnkH+R0lp6FhpAD3mEpg2pXKwOedeze2msiVekbzXTg4jjsUWlZXonlkYGxEir8pNkGHEe19xzTiv5QtuFV4oc=; X-YMail-OSG: C8o0asgVM1neAVCt3weStuLYtbKkzZhKKeXteLoKLSCyX0C aoWKJ35zTJygKIvNdLsPjv1rPXqop3HWANyjfehADOWYT1gGK2jn.Yud.ui. PPkT2BmOsCaOHU8eUavNze91hlwvswZM0GmX0KFaMX_G.5AjQfxUZhJ5MCCi kbGbWMskbCmokjnA.qV9uYzL08DUuYMLdQyeNhydeNPd48XQ6zCANa.KZKTB d4yhOHnJ5k8iQtBE6Lb1glOsxtMDRbheSIn5K51MVMSoN1nYrqTzKb.BujGd 3Bfdb5kDiE7EwOaFRR6Urll4OQ59R0SZzVXRCEledqnLN95oWGWHcVEjT14I OhGbTbxNqTFQCcG6iysvFj0vgu8wY3kZaQ_V1XycWhfqz5.qe.VCA30UsD9a .qPluSHe5bo_zSnxt1OHK1f.N8733EQFogOa_Vi5goCJGv81NmYtJOfmOz78 GI1RPQ3s.8UI0G923t8hqVhfGUT2_s.ezDBSRSYUzY0SCtMwBe0Vdf3MEQ2D VOJ.YzxLNKcOa9A1RU2JMrvmtVO2E_YjkcbcwODWDWsj3DvBSBAl40o_el0r N0Y1HZijJiZsvKwMN4KYHwEtzZA6hT7WkpPxPCfVK48YpHCdwomlDhIDe0Xy pqdLsKkK2jUASv9YtJG_rpJOjhuZ9LLtVt7duvsrxIvYsOt7Ki_CtmaI0dJo B0Es- Received: from [208.102.228.236] by web121603.mail.ne1.yahoo.com via HTTP; Tue, 19 Feb 2013 08:21:50 PST X-Rocket-MIMEInfo: 001.001, aHR0cDovL25vbGVnZ2lvYXV0b3R1cmNoaWEuY29tL29sdnMvbHQwdzJ3emZicDR3MXlsZ2cyNmgzeWdpMHR5dG9jJmYxb2xuMmRsMGRwOWNpOWo5bzNicWQ3eWdoZjJzbgEwAQEBAQ-- X-Mailer: YahooMailWebService/0.8.134.513 Message-ID: <1361290910.19426.YahooMailNeo@web121603.mail.ne1.yahoo.com> Date: Tue, 19 Feb 2013 08:21:50 -0800 (PST) From: Barney Cordoba Subject: Barney Cordoba To: current , peterjeremy , alexpalias-bsdnet@yahoo.com, d , domain_info@nymodels.com, squawk , joel.sherman@nypost.com, cs MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Barney Cordoba List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2013 16:21:59 -0000 http://noleggioautoturchia.com/olvs/lt0w2wzfbp4w1ylgg26h3ygi0tytoc&f1oln2dl0dp9ci9j9o3bqd7yghf2sn From owner-freebsd-current@FreeBSD.ORG Tue Feb 19 16:45:49 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 64E7691C; Tue, 19 Feb 2013 16:45:49 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:131:60a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id 21F18328; Tue, 19 Feb 2013 16:45:49 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:509e:5349:4e7a:bf0a]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPA id 2444D4AC57; Tue, 19 Feb 2013 20:45:41 +0400 (MSK) Date: Tue, 19 Feb 2013 20:45:37 +0400 From: Lev Serebryakov Organization: FreeBSD X-Priority: 3 (Normal) Message-ID: <321757294.20130219204537@serebryakov.spb.ru> To: freebsd-current Subject: Kernel is broken (at least for i386) from r246916 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: mav@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: lev@FreeBSD.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2013 16:45:49 -0000 Hello, freebsd-current. cc -c -O2 -pipe -fno-strict-aliasing -march=geode -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 -fdiagnostics-show-option -nostdinc -I. -I/data/src/sys -I/data/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 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -Werror /data/src/sys/x86/isa/clock.c cc1: warnings being treated as errors /data/src/sys/x86/isa/clock.c: In function 'set_i8254_freq': /data/src/sys/x86/isa/clock.c:409: warning: 'new_mode' may be used uninitialized in this function *** [clock.o] Error code 1 -- // Black Lion AKA Lev Serebryakov From owner-freebsd-current@FreeBSD.ORG Tue Feb 19 16:46:35 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id F292CA41; Tue, 19 Feb 2013 16:46:34 +0000 (UTC) (envelope-from davide.italiano@gmail.com) Received: from mail-vc0-f176.google.com (mail-vc0-f176.google.com [209.85.220.176]) by mx1.freebsd.org (Postfix) with ESMTP id 93082347; Tue, 19 Feb 2013 16:46:34 +0000 (UTC) Received: by mail-vc0-f176.google.com with SMTP id fk10so4396968vcb.35 for ; Tue, 19 Feb 2013 08:46:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=DOO6/FnXmpwgDvYLqlPMhBd8B8xeGwQ6cqga/cYkozc=; b=Thg2ND4CG5teVl7F8a9/kBpy+h6S/MIAUa3XpHfOB7/qj1o2muAjvzT9TJ/TIp7K41 irzPAi3tqLofDoZ2XlnYM5U126tAvaBbZmKT/9hBTdJm775rVCPGhHlqGeyR3aSB4nJv WDtnNPNE6JU3CKJdsTSjLQjRwoU0mHyuw65s2xTbQgABH46UVzbDNbsopo7Xg9vNKFcL wOBr4E6ppVeybhyEomqUVejd3aVEoYIvfUzKmr1w6o4/6smEA+PIVSrQyiqIZoxk13tI GadJqPkiLeMOOTLXM6QAtEmg7SmrTpiTcACcjYJXTnLi5yAI9IGv98R9iDWFmRH6vM9n 43hQ== MIME-Version: 1.0 X-Received: by 10.52.88.237 with SMTP id bj13mr18758606vdb.75.1361292393764; Tue, 19 Feb 2013 08:46:33 -0800 (PST) Sender: davide.italiano@gmail.com Received: by 10.220.114.134 with HTTP; Tue, 19 Feb 2013 08:46:33 -0800 (PST) In-Reply-To: References: Date: Tue, 19 Feb 2013 17:46:33 +0100 X-Google-Sender-Auth: qvLcaqB-1m1_W6kcPog1_URRib0 Message-ID: Subject: Re: r246916 probably broke amd64 build From: Davide Italiano To: "Simon L. B. Nielsen" Content-Type: text/plain; charset=ISO-8859-1 Cc: mav@freebsd.org, freebsd-current , des@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 19 Feb 2013 16:46:35 -0000 On Tue, Feb 19, 2013 at 3:22 PM, Simon L. B. Nielsen wrote: > Hey, > > I think r246916 broke the build. I get the following when building amd64 kernel: > > cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -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 > -fdiagnostics-show-option -nostdinc -I. -I/usr/src/sys > -I/usr/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 > -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx > -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding > -fstack-protector -Werror /usr/src/sys/x86/isa/clock.c > cc1: warnings being treated as errors > /usr/src/sys/x86/isa/clock.c: In function 'set_i8254_freq': > /usr/src/sys/x86/isa/clock.c:409: warning: 'new_mode' may be used > uninitialized in this function > > Could you have a look? Thanks. > > -- > Simon L. B. Nielsen > _______________________________________________ > 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" It's fixed (r247000). Unfortunately tinderbox didn't catch this bug because it's triggered only when gcc is used to build kernel. Thanks, Davide From owner-freebsd-current@FreeBSD.ORG Tue Feb 19 16:58:29 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id C05C7D85 for ; Tue, 19 Feb 2013 16:58:29 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wi0-f181.google.com (mail-wi0-f181.google.com [209.85.212.181]) by mx1.freebsd.org (Postfix) with ESMTP id 23BC861D for ; Tue, 19 Feb 2013 16:58:28 +0000 (UTC) Received: by mail-wi0-f181.google.com with SMTP id hm6so5067788wib.14 for ; Tue, 19 Feb 2013 08:58:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=BKo3o8AozglL1pVT/csniAeCPG+ophCycDngw5F0UrE=; b=bHwPhZlx+4GzdF8BWhCySEFGpcXS3o42Vhdjnw1hlu9gjVjOJZ7LRuIpVu2JjXTvI5 mNNVJnNjC7CUX1eaMUbs0J4ubLwbKSiSh5mq48Z1V27KAf2NifhRYfev8sbURNeQybnb nzMVSfX481lYD/IfN/iPDWBRY72lDH7eLkFwSmo+Sx81/erlz4hIoEzxOMRhoeNOQjwB YTK1CLBTdMHXZk6YkkeeBOtACfXO4+LqFieBhJKET7DlcRLFCHlEUH5FpqW0EzYcMrMJ SREcjatSTBHYhNGGuXaNtuNtT5rrlvllCjqt+81nmNoYPbpOi8GyLXgIn4X6Kx9OHbMt v6+w== MIME-Version: 1.0 X-Received: by 10.194.161.135 with SMTP id xs7mr27936942wjb.41.1361293107844; Tue, 19 Feb 2013 08:58:27 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.236.88 with HTTP; Tue, 19 Feb 2013 08:58:27 -0800 (PST) In-Reply-To: References: <36DD2FB4-E26A-4F03-95D9-FFD855957269@my.gd> <8F861CF6-D0FA-4BD2-B73D-24CB247584A1@my.gd> <51235EA7.6000208@FreeBSD.org> <20130219121544.GU83110@e-new.0x20.net> Date: Tue, 19 Feb 2013 08:58:27 -0800 X-Google-Sender-Auth: h0OUqxlxK8l2P8X73SsC5kHsvg4 Message-ID: Subject: Re: system 20% busy at all times? From: Adrian Chadd To: "Eggert, Lars" Content-Type: text/plain; charset=ISO-8859-1 Cc: Lars Engels , "current@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 19 Feb 2013 16:58:29 -0000 Try top -HS .. to try and break down the kernel threads. Adrian From owner-freebsd-current@FreeBSD.ORG Tue Feb 19 17:07:25 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id E4B98FC8 for ; Tue, 19 Feb 2013 17:07:25 +0000 (UTC) (envelope-from kolyasir@gmail.com) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by mx1.freebsd.org (Postfix) with ESMTP id AEE9869F for ; Tue, 19 Feb 2013 17:07:25 +0000 (UTC) Received: by mail-qa0-f51.google.com with SMTP id cr7so1937198qab.17 for ; Tue, 19 Feb 2013 09:07:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=FOM2lNpOH/aeQiDF9GoqL6Gfs2D4p/BHjeHHKAcpwjA=; b=hkzN9/mgTBlnFCz3/GT7X63cOHBs0WV86EkCB9odk64q3viQtqizbLJ7O9otGLQrLy LNO3m61pKO83YYbFEB+BXTURprUjfY8Hl7I23ImSGteAflxTmKUxnOLtenmRIc/qpoll DLKXsqDSYyua1MqUNUAWagLNbuAA8Ey5pIq6ceFF5914B2f2oij6AqDheqr89ux5JXqY xXEY2SG9QMxiGiQ0VR4lQw38l8faPCLZBwKXkjNfQCA2kO7BTWCczsyv9X1olQN28tGk D+SsjnILiTs7e2bh/I0Mjf7LL2RpyrJ2YM5jsaxgZvvfsCjIbQhwr8VArRB+0HfCCfM/ YTZQ== MIME-Version: 1.0 X-Received: by 10.224.33.208 with SMTP id i16mr3112816qad.45.1361293639427; Tue, 19 Feb 2013 09:07:19 -0800 (PST) Received: by 10.49.71.232 with HTTP; Tue, 19 Feb 2013 09:07:19 -0800 (PST) Date: Tue, 19 Feb 2013 12:07:19 -0500 Message-ID: Subject: fail to load vlans into the vlan translation unit From: Yasir hussan To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 19 Feb 2013 17:07:26 -0000 hi, i am trying to build up vlan feature for chip ar8316 in freebsd, i am yet able to make a single defualt vlan which is working properly, where i am failing is i guess is in calculate the port destination masks and load vlansinto the vlan translation unit, i am tring to copy style of open-wrt, u can also brows it from https://dev.openwrt.org/browser/trunk/target/linux/generic-2.6/files/drivers/net/phy/ar8216.c?rev=20083 the vlan i tried to add in last is working as defualt vlan but switch should also add the previous one vlans.I think it should even work if i dont use loop and just use ar8216_vtu_op funtion to add each vlan, but it does`t work on me, kindly anyone body have idea what i am missing or have any suggestion would be arpiciotive.. Thanks, From owner-freebsd-current@FreeBSD.ORG Tue Feb 19 17:27:57 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 98587955 for ; Tue, 19 Feb 2013 17:27:57 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wi0-f175.google.com (mail-wi0-f175.google.com [209.85.212.175]) by mx1.freebsd.org (Postfix) with ESMTP id 250307ED for ; Tue, 19 Feb 2013 17:27:56 +0000 (UTC) Received: by mail-wi0-f175.google.com with SMTP id l13so5120854wie.2 for ; Tue, 19 Feb 2013 09:27:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=7b47M/nTgYzYLWIrKn9qvfg5ZBzd5i/Y9BrJ5BhiRy0=; b=oh6bMyQS87WvzCD3OOZvvVXfbLJfJ9VXEJ1xJtVW3uYBpxvvN7A+WARsZTvIctN2Gq 5gWMXW3BvQLP0mRDHLOFtTweuQaCfG6nkFeWd5m2o5sKpMs9KrQMRT7BHLgLMR0znww0 DuXlsTvRHWmikexCnR6Q+Z0P+w8T8Mgo5vIpU2P1yoFFVaGL5LqU5RMsPCJdlM+r30Ym fSKfp16umu4KkIfeRYm0bNi5u4Z6OJqLQZB7tmD10ArbmvHU3uhV25jeijI7bG1/GpP6 Xpf1fpEUEFyTSQCOzeWa7g4T4loJNvxAWVSbY4fOmobCXDW7jSPkH3MV1Qyrxm8H9+YD drKA== MIME-Version: 1.0 X-Received: by 10.180.91.106 with SMTP id cd10mr10116289wib.6.1361294875985; Tue, 19 Feb 2013 09:27:55 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.236.88 with HTTP; Tue, 19 Feb 2013 09:27:55 -0800 (PST) In-Reply-To: References: Date: Tue, 19 Feb 2013 09:27:55 -0800 X-Google-Sender-Auth: -o9rJTg0EOSWZ3eme2kN_7bNap0 Message-ID: Subject: Re: fail to load vlans into the vlan translation unit From: Adrian Chadd To: Yasir hussan Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 19 Feb 2013 17:27:57 -0000 Do you have any example code that you've written that's failing? Thanks, adrian On 19 February 2013 09:07, Yasir hussan wrote: > hi, > > i am trying to build up vlan feature for chip ar8316 in freebsd, i am yet > able to make a single defualt vlan which is working properly, where i am > failing is i guess is in calculate the port destination masks and load > vlansinto the vlan translation unit, i am tring to copy style of > open-wrt, u can > also brows it from > https://dev.openwrt.org/browser/trunk/target/linux/generic-2.6/files/drivers/net/phy/ar8216.c?rev=20083 > > > the vlan i tried to add in last is working as defualt vlan but switch > should also add the previous one vlans.I think it should even work if i > dont use loop and just use ar8216_vtu_op funtion to add each vlan, but it > does`t work on me, kindly anyone body have idea what i am missing or have > any suggestion would be arpiciotive.. > > Thanks, > _______________________________________________ > 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 Tue Feb 19 17:42:23 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 5EF514A3; Tue, 19 Feb 2013 17:42:23 +0000 (UTC) (envelope-from utisoft@gmail.com) Received: from mail-ia0-x235.google.com (mail-ia0-x235.google.com [IPv6:2607:f8b0:4001:c02::235]) by mx1.freebsd.org (Postfix) with ESMTP id 136048E9; Tue, 19 Feb 2013 17:42:23 +0000 (UTC) Received: by mail-ia0-f181.google.com with SMTP id e16so6006805iaa.26 for ; Tue, 19 Feb 2013 09:42:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=Br0F8gPay9a8oJIwI2TlM6r981zQ+LwNnpmZvt34BdI=; b=MwTqBUtWOtrv98MPcgmD/pNB3PNHLdq2whutJRQQRx45mg9qAOu35snDFxu9DZmA7B uChRDVpnaMfW9EH1hhEb5g2t3HOkdXkASfWYaayde5gbWr+GDNWv9dFEW2v1gkWEudfw ppAjh17GSxZ3xqM58A+0mPaCTShSQhvJ1tQM28OEirs3lP5pjA6mMAWE0hFxA6afYNWD VQx+l+sdB8fl8BaCFNkHJ6L+bdAj+xwtSvWd8VXFPCS/W+1AD5QctVavzOj5kXgKE87P p0NRS+0VDEiO5On/4Cks+vD8bIA8IuaOOtvV2kUrbf3g4SwSc1iJafEUXLx0TH2Wzn0e q8dQ== MIME-Version: 1.0 X-Received: by 10.50.178.10 with SMTP id cu10mr9875147igc.75.1361295726931; Tue, 19 Feb 2013 09:42:06 -0800 (PST) Received: by 10.64.63.12 with HTTP; Tue, 19 Feb 2013 09:42:06 -0800 (PST) Received: by 10.64.63.12 with HTTP; Tue, 19 Feb 2013 09:42:06 -0800 (PST) In-Reply-To: <321757294.20130219204537@serebryakov.spb.ru> References: <321757294.20130219204537@serebryakov.spb.ru> Date: Tue, 19 Feb 2013 17:42:06 +0000 Message-ID: Subject: Re: Kernel is broken (at least for i386) from r246916 From: Chris Rees To: Lev Serebryakov , Davide Italiano Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: mav@freebsd.org, freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 19 Feb 2013 17:42:23 -0000 On 19 Feb 2013 16:45, "Lev Serebryakov" wrote: > > Hello, freebsd-current. > > > cc -c -O2 -pipe -fno-strict-aliasing -march=geode -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 -fdiagnostics-show-option -nostdinc -I. -I/data/src/sys -I/data/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 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -Werror /data/src/sys/x86/isa/clock.c > cc1: warnings being treated as errors > /data/src/sys/x86/isa/clock.c: In function 'set_i8254_freq': > /data/src/sys/x86/isa/clock.c:409: warning: 'new_mode' may be used uninitialized in this function > *** [clock.o] Error code 1 I believe this is fixed in r247000. Chris From owner-freebsd-current@FreeBSD.ORG Tue Feb 19 18:51:42 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 14F1D379 for ; Tue, 19 Feb 2013 18:51:42 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 52E13E14 for ; Tue, 19 Feb 2013 18:51:41 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.6/8.14.6) with ESMTP id r1JIpUNn025696; Tue, 19 Feb 2013 20:51:30 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.7.4 kib.kiev.ua r1JIpUNn025696 Received: (from kostik@localhost) by tom.home (8.14.6/8.14.6/Submit) id r1JIpTiJ025695; Tue, 19 Feb 2013 20:51:29 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 19 Feb 2013 20:51:29 +0200 From: Konstantin Belousov To: Svatopluk Kraus Subject: Re: [patch] i386 pmap sysmaps_pcpu[] atomic access Message-ID: <20130219185129.GC2598@kib.kiev.ua> References: <20130218150809.GG2598@kib.kiev.ua> <20130218170957.GJ2598@kib.kiev.ua> <20130218203630.GO2598@kib.kiev.ua> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="6dGMKdYe2Ft9UtxE" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 19 Feb 2013 18:51:42 -0000 --6dGMKdYe2Ft9UtxE Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Feb 18, 2013 at 11:18:16PM +0100, Svatopluk Kraus wrote: > On Mon, Feb 18, 2013 at 9:36 PM, Konstantin Belousov > wrote: > Well, I'm taking a part on porting FreeBSD to ARM11mpcore. UP case was > simple. SMP case is more complex and rather new for me. Recently, I > was solving a problem with PCPU stuff. For example, PCPU_GET is > implemented by one instruction on i386 arch. So, a need of atomicity > with respect to interrupts can be overlooked. On load-store archs, the > implementation which works in SMP case is not so simple. And what > works in UP case (single PCPU), not works in SMP case. Believe me, > mysterious and sporadic 'mutex not owned' assertions and others ones > caused by curthreads mess, it takes a while ... Note that PCPU_GET() is not needed to be atomic. The reason is that the code which uses its result would not be atomic (single-instruction or whatever, = see below). Thus, either the preemption should not matter since the action with the per-cpu data is advisory, as is in the case of i386 pmap you noted. or some external measures should be applied in advance to the containing region (which you proposed, by bracing with sched_pin()). Also, note that it is not interrupts but preemption which is concern. >=20 > After this, I took a look at how PCPU stuff is used in whole kernel > and found out mentioned here i386 pmap issue. So, my concern is > following: >=20 > 1. to verify my newly gained ideas how per CPU data should be used, > 2. to decide how to change my implementation of pmap on ARM11mpcore, > as it's based on i386 pmap, > 3. to make FreeBSD code better. >=20 > In the meanwhile, it looks that using data dedicated to one CPU on > another one is OK. However, I can't agree. At least, without comments, > it is misleading for anyone new in FreeBSD and makes code misty. >=20 > > Both threads in your description make useful progress, and computation > > proceeds correctly. >=20 > I thought, there is only one thread in my example. One thread running > on CPU1, but holding sysmaps dedicated to CPU0 instead of holding > sysmaps dedicated to CPU1. So, any thread running on CPU0 must wait > because the thread running on CPU1 is a thief. Futhermore, the idea > that a thread on CPU1 should hold data for CPU1 is not valid. So, > either some comment is missing in the code that it's OK or the using > of PCPU_GET(cpuid) is unneeded and some kind of free sysmaps list can > be used and it will serve better. What is wrong on almost all architectures except x86 is PCPU_ADD(), which is usually supposed by the MD code to be atomic in regard to _both_ interrupts and preemption. I said almost all, but in fact I am not aware of any architecture except x86 where it is right. And, RISCs with the load-link and store-conditional (ll/sc) primitives are well capable of doing the PCPU_ADD() correctly. You could look at the projects/counters branch, where single-instruction increment is used on x86 for dynamic per-cpu counters, and critical_enter() for other architectures. I might do some work for other arches, but the counters are correct but slower that it could be, on !x86. --6dGMKdYe2Ft9UtxE Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJRI8mxAAoJEJDCuSvBvK1B5koQAKa2FXuEJYXOp77FYXQqME1r b73a6IqZFz68RHwKVe66CLMqCWt3Ej+r8EoqQKbl9N3DbvEWWkNrJthSAEYZqT6q jcfMoJTI4qNhTPtuuRnY4mJYyFNAe74/aabIRSEJyzEGEPekJ2M7+K06drRPtD5Y PkqKavZwtPOgAgRDnEuMZcztNjsQbWFkAP15tpTfMyhFeDhpLZy+FFJ1Rus8aFKK lwqWXZK7+yBdNULi5XwgN3lb+Qu6e2thaDEh2psRKsfpwvrPc35jYlBftXQjYfUb rR5qDO6LgHxOEIpunAEo6CQsfH4LK69XhMeQgBELMRlNbkWcfyMr0+ussymvFm9X s6goFnlX9ajbEq/XkrlDDmkR5aKCVr8l6Y2j7o3zT6FESccBXMF4mLLo3KFnv0nM rAaonT+RIWzwXw6Y+zrY/rAjJ0pam6vxo5sazd3L9EEaiCfpCNmRNbmFr0k3ONP8 4PHPxVBrL3GCLG6uLeiWpTfw09S5UligzutcIf9C37QUPBAzTQNS52z9sgyR+F/E L78hp9TeWs89OHJKwKksYzgvT3c1huH4H97uKhv5U0jwt7cb+cmU+DCMNXT2CrCF qYttncg6WGpKn6wcrthZ5nTZBehw06ma1WFN5hjRJFNyGrLh5hNKSoUvHUOQFFjD wS47WRblh+H98bLPHECY =cqAF -----END PGP SIGNATURE----- --6dGMKdYe2Ft9UtxE-- From owner-freebsd-current@FreeBSD.ORG Tue Feb 19 18:54:21 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 844ED670 for ; Tue, 19 Feb 2013 18:54:21 +0000 (UTC) (envelope-from kolyasir@gmail.com) Received: from mail-qa0-f47.google.com (mail-qa0-f47.google.com [209.85.216.47]) by mx1.freebsd.org (Postfix) with ESMTP id 4CF25E6D for ; Tue, 19 Feb 2013 18:54:21 +0000 (UTC) Received: by mail-qa0-f47.google.com with SMTP id j8so1992912qah.6 for ; Tue, 19 Feb 2013 10:54:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=UhX5I6DMqGGLo9651b+jZIlUSFiadCsDTgpvUMLIuC4=; b=VdyMskP8QBV6XNGGpLrXTmBZlgx1ykhZScL2QhNa85sy30olSOUcFg+43TwfaZLVn9 s8JDGeIJch8wSzbl7WwnKe1BePUEBjCPtVb6BstXv+jR6qI+BSjQaYSeIepqg2uP+yYd 0V6xJjBnxoq2aNxg6XUHarJfdh/iRmNyOKbBKrimHB89MXlUxxh7xr93Oxg8tTbZiwjV 5nX+JkesBD44O1AphYIFzpivvRFdmQWJbYBxU+NQgyTW3Re2wijrLrqMsNjG3td17R0g zMT6XxYWGytyaHllkCrPXzCSaPx+hVuT5gjszGydYPa0x+fqtsSmkqQitf46//uawwSR yhjg== MIME-Version: 1.0 X-Received: by 10.229.75.140 with SMTP id y12mr1540815qcj.98.1361300054944; Tue, 19 Feb 2013 10:54:14 -0800 (PST) Received: by 10.49.71.232 with HTTP; Tue, 19 Feb 2013 10:54:14 -0800 (PST) In-Reply-To: References: Date: Tue, 19 Feb 2013 23:54:14 +0500 Message-ID: Subject: Re: fail to load vlans into the vlan translation unit From: Yasir hussan To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 19 Feb 2013 18:54:21 -0000 i can`t send u complete patch yet, i will send u main point where i think am getting failer, its not bug free code, plz to understand logic u8 portmask=0;//[AR8216_NUM_PORTS]; int i, j; /* flush all vlan translation unit entries */ ar8216_vtu_op(priv, AR8216_VTU_OP_FLUSH, 0); ar8316_vtu_op(sc, AR8316_VTU_OP_LOAD | (1/*vlanid*/ << AR8316_VTU_VID_SHIFT), (3 /*ports*/<< 1) | (1 << AR8316_CPU_PORT)); ar8316_vtu_op(sc, AR8316_VTU_OP_LOAD | (2/*vlanid*/ << AR8316_VTU_VID_SHIFT), (12 /*ports*/<< 1) | (1 << AR8316_CPU_PORT)); /* update the port destination mask registers and tag settings */ for (i = 0; i < AR8216_NUM_PORTS; i++) { int egress, ingress; int pvid; if ( i<3) { pvid =1;//priv->vlan_id[priv->pvid[i]]; } else { pvid = 2//i; } egress = AR8216_OUT_STRIP_VLAN; ingress = AR8216_IN_SECURE; ar8316_reg_update(sc->sc_pdev, AR8316_REG_PORT_CTRL(i), AR8316_PORT_CTRL_LEARN | AR8316_PORT_CTRL_VLAN_MODE | AR8316_PORT_CTRL_SINGLE_VLAN | AR8316_PORT_CTRL_STATE | AR8316_PORT_CTRL_HEADER | AR8316_PORT_CTRL_LEARN_LOCK, AR8316_PORT_CTRL_LEARN | (egress << AR8316_PORT_CTRL_VLAN_MODE_SHIFT) | (AR8316_PORT_STATE_FORWARD << AR8316_PORT_CTRL_STATE_SHIFT)); ar8316_reg_update(sc->sc_pdev, AR8316_REG_PORT_VLAN(i), AR8316_PORT_VLAN_DEST_PORTS | AR8316_PORT_VLAN_MODE | AR8316_PORT_VLAN_DEFAULT_ID, (portmask << AR8316_PORT_VLAN_DEST_PORTS_SHIFT) | (ingress << AR8316_PORT_VLAN_MODE_SHIFT) | (pvid << AR8316_PORT_VLAN_DEFAULT_ID_SHIFT)); } I think two vlan with ids 1,2 should be created which would be working fine by just upgrading registers, if i am missing something u can it... Thanks, On Tue, Feb 19, 2013 at 10:07 PM, Yasir hussan wrote: > hi, > > i am trying to build up vlan feature for chip ar8316 in freebsd, i am yet > able to make a single defualt vlan which is working properly, where i am > failing is i guess is in calculate the port destination masks and load > vlans into the vlan translation unit, i am tring to copy style of > open-wrt, u can also brows it from > https://dev.openwrt.org/browser/trunk/target/linux/generic-2.6/files/drivers/net/phy/ar8216.c?rev=20083 > > > the vlan i tried to add in last is working as defualt vlan but switch > should also add the previous one vlans.I think it should even work if i > dont use loop and just use ar8216_vtu_op funtion to add each vlan, but it > does`t work on me, kindly anyone body have idea what i am missing or have > any suggestion would be arpiciotive.. > > Thanks, > From owner-freebsd-current@FreeBSD.ORG Tue Feb 19 19:02:42 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 7E254CDF; Tue, 19 Feb 2013 19:02:42 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 2C8A8F68; Tue, 19 Feb 2013 19:02:42 +0000 (UTC) Received: from pakbsde14.localnet (unknown [38.105.238.108]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 769EAB93B; Tue, 19 Feb 2013 14:02:41 -0500 (EST) From: John Baldwin To: freebsd-current@freebsd.org Subject: Re: Unable to build audio/sox: undefined reference to 'open_memstream' Date: Tue, 19 Feb 2013 13:10:03 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p25; 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: <201302191310.03524.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 19 Feb 2013 14:02:41 -0500 (EST) Cc: Ian FREISLICH , current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 19 Feb 2013 19:02:42 -0000 On Saturday, February 16, 2013 3:20:34 am Ian FREISLICH wrote: > Hi > > I get this error building building sox on amd64, but not i386. CC > is gcc on both systems. I can't figure out what the configure > options difference is between the two hosts that has it fail on the > amd64 system. All the dependencies have the same options configured. > > /bin/sh ../libtool --silent --tag=CC --silent --mode=link cc -Wconversion -I/usr/local/include -O2 -pipe -march=nocona -fno-strict-aliasing - D_FORTIFY_SOURCE=2 -Wall -W -Wmissing-prototypes -Wstrict-prototypes -pedantic -fopenmp -version-info 1:0:0 -lltdl -L/usr/local/lib -pthread -o libsox.la - rpath /usr/local/lib libsox_la-adpcms.lo libsox_la-aiff.lo libsox_la-cvsd.lo libsox_la-g711.lo libsox_la-g721.lo libsox_la-g723_24.lo libsox_la-g723_40.lo libsox_la-g72x.lo libsox_la-vox.lo libsox_la-raw.lo libsox_la-formats.lo libsox_la-formats_i.lo libsox_la-skelform.lo libsox_la-xmalloc.lo libsox_la- getopt.lo libsox_la-getopt1.lo libsox_la-util.lo libsox_la-libsox.lo libsox_la-libsox_i.lo libsox_la-sox-fmt.lo libsox_la-bend.lo libsox_la- biquad.lo libsox_la-biquads.lo libsox_la-chorus.lo libsox_la-compand.lo libsox_la-crop.lo libsox_la-compandt.lo libsox_la-contrast.lo libsox_la- dcshift.lo libsox_la-delay.lo libsox_la-dft_filter.lo libsox_la-dither.lo libsox_la-divid > e.lo libsox_la-earwax.lo libsox_la-echo.lo libsox_la-echos.lo libsox_la- effects.lo libsox_la-effects_i.lo libsox_la-effects_i_dsp.lo libsox_la- fade.lo libsox_la-fft4g.lo libsox_la-filter.lo libsox_la-fir.lo libsox_la- firfit.lo libsox_la-flanger.lo libsox_la-gain.lo libsox_la-input.lo libsox_la-ladspa.lo libsox_la-loudness.lo libsox_la-mcompand.lo libsox_la- mixer.lo libsox_la-noiseprof.lo libsox_la-noisered.lo libsox_la-output.lo libsox_la-overdrive.lo libsox_la-pad.lo libsox_la-pan.lo libsox_la-phaser.lo libsox_la-rate.lo libsox_la-remix.lo libsox_la-repeat.lo libsox_la-reverb.lo libsox_la-reverse.lo libsox_la-silence.lo libsox_la-sinc.lo libsox_la- skeleff.lo libsox_la-speed.lo libsox_la-speexdsp.lo libsox_la-splice.lo libsox_la-stat.lo libsox_la-stats.lo libsox_la-stretch.lo libsox_la-swap.lo libsox_la-synth.lo libsox_la-tempo.lo libsox_la-tremolo.lo libsox_la-trim.lo libsox_la-vad.lo libsox_la-vol.lo libsox_la-spectrogram.lo libsox_la-raw- fmt.lo libsox_la > -s1-fmt.lo libsox_la-s2-fmt.lo libsox_la-s3-fmt.lo libsox_la-s4-fmt.lo libsox_la-u1-fmt.lo libsox_la-u2-fmt.lo libsox_la-u3-fmt.lo libsox_la-u4- fmt.lo libsox_la-al-fmt.lo libsox_la-la-fmt.lo libsox_la-ul-fmt.lo libsox_la- lu-fmt.lo libsox_la-8svx.lo libsox_la-aiff-fmt.lo libsox_la-aifc-fmt.lo libsox_la-au.lo libsox_la-avr.lo libsox_la-cdr.lo libsox_la-cvsd-fmt.lo libsox_la-dvms-fmt.lo libsox_la-dat.lo libsox_la-hcom.lo libsox_la-htk.lo libsox_la-maud.lo libsox_la-prc.lo libsox_la-sf.lo libsox_la-smp.lo libsox_la-sounder.lo libsox_la-soundtool.lo libsox_la-sphere.lo libsox_la- tx16w.lo libsox_la-voc.lo libsox_la-vox-fmt.lo libsox_la-ima-fmt.lo libsox_la-adpcm.lo libsox_la-ima_rw.lo libsox_la-wav.lo libsox_la-wve.lo libsox_la-xa.lo libsox_la-nulfile.lo libsox_la-f4-fmt.lo libsox_la-f8-fmt.lo libsox_la-gsrt.lo libsox_la-alsa.lo libsox_la-ao.lo libsox_la-ffmpeg.lo libsox_la-flac.lo libsox_la-gsm.lo libsox_la-lpc10.lo libsox_la-mp3.lo libsox_la-oss.lo lib > sox_la-vorbis.lo libsox_la-sndfile.lo libsox_la-caf.lo libsox_la-mat4.lo libsox_la-mat5.lo libsox_la-paf.lo libsox_la-fap.lo libsox_la-w64.lo libsox_la-xi.lo libsox_la-pvf.lo libsox_la-sd2.lo -lpng -lz -lmagic -lgomp -lgsm ../lpc10/liblpc10.la -lasound -lao -lavformat -lavcodec - L/usr/local/lib -lavutil -lFLAC -lvorbisenc -lvorbisfile -lvorbis -logg - lgsm -lmad -lid3tag -lz -lmp3lame -lvorbisenc -lvorbisfile -lvorbis -logg -L/usr/local/lib -lsndfile -lm > /bin/sh ../libtool --silent --tag=CC --silent --mode=link cc -Wconversion -O2 -pipe -march=nocona -fno-strict-aliasing -D_FORTIFY_SOURCE=2 -Wall -W - Wmissing-prototypes -Wstrict-prototypes -pedantic -fopenmp -avoid-version - module -L/usr/local/lib -pthread -o sox sox.o libsox.la -lm > ./.libs/libsox.so: undefined reference to `open_memstream' I'm guessing it thinks that we have open_memstream() because someone added fmemopen() recently. I have an implementation of open_memstream() that I will commit soon. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Tue Feb 19 19:33:33 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id C21F8B74 for ; Tue, 19 Feb 2013 19:33:33 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wi0-f179.google.com (mail-wi0-f179.google.com [209.85.212.179]) by mx1.freebsd.org (Postfix) with ESMTP id 629B21B7 for ; Tue, 19 Feb 2013 19:33:33 +0000 (UTC) Received: by mail-wi0-f179.google.com with SMTP id ez12so5293331wid.6 for ; Tue, 19 Feb 2013 11:33:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=fdExXxjvo+vEC+fLzNZHQH8SgkGjsxhQpUiV6kuucss=; b=PTq0xTNLbY59dJ33/fKqj/MSTiCVPd6fzEHEQpmasE1nnMMhgBQ5aSohD0UVjgedcC NCrHQ2h9tmZqfNQmPSJpU/wPc+TzGPzDN4c+lCuDVA3cTV9aXgrDrqfPcoSfQg74OfOt ZBs/zRRTwLkJ5zZJYYBQNY2Og+/fk1pwVHMOcrU8wUi+tfgzub6K+9E8Kr6rvm+2gW57 vSnFXkOLVSOoq8depDbEDWHn5q1dPeUAAJbroC68jKao/dlWjKgYKO4VKL+qLjaNMrPj mK+UXdiUD1BRlB4dlJBh0A/6A7WKZ8nE7tMym2Z3u3aCTiV6Kt3pKPKRA/jJ6xEdGWs/ EmjQ== MIME-Version: 1.0 X-Received: by 10.180.79.227 with SMTP id m3mr26031681wix.12.1361302412187; Tue, 19 Feb 2013 11:33:32 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.236.88 with HTTP; Tue, 19 Feb 2013 11:33:32 -0800 (PST) In-Reply-To: References: Date: Tue, 19 Feb 2013 11:33:32 -0800 X-Google-Sender-Auth: LV3zPLEQsTtF3ZaGDr46EXGBNSQ Message-ID: Subject: Re: fail to load vlans into the vlan translation unit From: Adrian Chadd To: Yasir hussan Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 19 Feb 2013 19:33:33 -0000 On 19 February 2013 10:54, Yasir hussan wrote: > i can`t send u complete patch yet, i will send u main point where i think > am getting failer, its not bug free code, plz to understand logic Thanks. What's the zrouter ar8316 switch driver do? adrian From owner-freebsd-current@FreeBSD.ORG Tue Feb 19 22:01:11 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id CA38AB76; Tue, 19 Feb 2013 22:01:11 +0000 (UTC) (envelope-from list_freebsd@bluerosetech.com) Received: from rush.bluerosetech.com (rush.bluerosetech.com [199.48.134.58]) by mx1.freebsd.org (Postfix) with ESMTP id 9D749A32; Tue, 19 Feb 2013 22:01:11 +0000 (UTC) Received: from chombo.houseloki.net (montesse-2-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:19b9::2]) by rush.bluerosetech.com (Postfix) with ESMTPSA id 630591146A; Tue, 19 Feb 2013 14:01:05 -0800 (PST) Received: from [127.0.0.1] (ivo.houseloki.net [10.9.70.20]) by chombo.houseloki.net (Postfix) with ESMTPSA id 127B012C; Tue, 19 Feb 2013 14:01:03 -0800 (PST) Message-ID: <5123F61F.40807@bluerosetech.com> Date: Tue, 19 Feb 2013 14:01:03 -0800 From: Darren Pilgrim User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: "Constantine A. Murenin" Subject: Re: announcing mdoc.su, short manual page URLs References: <20130219082700.GA9938@Cns.Cns.SU> In-Reply-To: <20130219082700.GA9938@Cns.Cns.SU> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-doc@FreeBSD.org, freebsd-current@FreeBSD.org, freebsd-chat@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 19 Feb 2013 22:01:11 -0000 One of the really cool things Constantine didn't mention is the entire site is just the nginx config! It's done with what some might consider slight abuses of rewrite rules, but it does mean the whole thing is completely memory resident. The full config on github is definitely worth a read. From owner-freebsd-current@FreeBSD.ORG Tue Feb 19 23:10:03 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 87FFA119; Tue, 19 Feb 2013 23:10:03 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id 30B00F93; Tue, 19 Feb 2013 23:10:02 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) with esmtp (envelope-from ) id <1U7wJw-003NOT-Jy>; Wed, 20 Feb 2013 00:09:56 +0100 Received: from e178020162.adsl.alicedsl.de ([85.178.20.162] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1U7wJw-002uBQ-G1>; Wed, 20 Feb 2013 00:09:56 +0100 Message-ID: <5124063D.2060604@zedat.fu-berlin.de> Date: Wed, 20 Feb 2013 00:09:49 +0100 From: "O. Hartmann" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130131 Thunderbird/17.0.2 MIME-Version: 1.0 To: Current FreeBSD , freebsd-performance@freebsd.org Subject: PathScale EKO Path 5 not for FreeBSD anymore? X-Enigmail-Version: 1.4.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigDF36890EC952228A8D9A2C83" X-Originating-IP: 85.178.20.162 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 19 Feb 2013 23:10:03 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigDF36890EC952228A8D9A2C83 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable A while ago - approximately three years from now, i was looking for a GPGPU capable solution for usage on FreeBSD and I stepped into the compilers from PathScale which are supposed to handle OpenACC (like OpenMP #pragma omp, but in this case #pragma openacc instead). Well, there was hope since PathScale obviously had a FreeBSD commercial solution. It was in BETA stage that time, I applied for getting a testing copy, but never got an answer, even having had contact to Christopher Bergstr=F6m, CTO at PathScale. Looking today at Phoronix, (http://www.phoronix.com/scan.php?page=3Darticle&item=3Dpathscale_ekopath= _5beta&num=3D1), I read this benchmarking and followed the links which say that PathScale opensourced their compiler suite a while ago (http://www.phoronix.com/scan.php?page=3Darticle&item=3Dpathscale_ekopath= 4_open&num=3D1) I was curious and looked at PathScales website where I found three years ago also FreeBSD mentioned as a supported platform, but see foryourself, what supported platforms today mentioned there: http://www.pathscale.com/ekopath-compiler-suite Well, at the end, this means there is simply no binary or package that could be installed easily for scientists interested in that compiler. I do not know whether there are motivations to produce a FreeBSD 10/9 compatible package from the newly emitted PathScale EKO Patch 5 Beta compiler sources, which are available at github: https://github.com/path64/compiler Well, the official website of PathScale doens't mention FreeBSD anymore and this must have a reason why they droped support or any intention to support that OS. From the perspective of a "user", I'm the lonely "idiot" within kilometres using FreeBSD for my day-to-day scientifice work and sacrifice myself not having GPGPU capabilities. Something is really going into the wrong direction here. I'm very interested in the reasoning why PathScale droped FreeBSD and I guess it would be nice to reveal the reasons. Am I blind or is this again another erosion process of an operating system usefull even for scientific purposes? Well, I'm aware that my posting triggers again a lot of emotional discussions (I guess), since it did in the past. I try to evaluate the situation from the perspective of a "user", not someone who needs to be a Os engineer to use an OS. It is a kind of deep running frustration to see how the next great compiler suite for scientific purpose is simply vanishing - as it did with the NAG compilers which were offered for freeBSD as well as other OSs at the end of 1990s. Now there is no offering anymore. Regards, Oliver --------------enigDF36890EC952228A8D9A2C83 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.19 (FreeBSD) iQEcBAEBAgAGBQJRJAZDAAoJEOgBcD7A/5N8AzAIAM3mS2GJqQqZIskvfKUh4MjB 4lIunyq7XcD/PvkrV/epTl36wEswPTWjTgEUCmStbaHd6EvfJCNkTuGYp2/uP+u1 QMOQBBmhOtIeFMNrW9oxi0nGV/jbN5bSXzV1Tki2/0DIUnoCzBWtATLsBiJZ58Su mAenGSclKXjBFJAPEZ9akX4k4GMpChulQ551X6ZFHsN79f4HFzJpm9sS8lcFp51d frgbEUNbG789RSyTf383J3zo85hCJlzPK8zGERZBRv+ylIYbym30WVz48J2FN+MJ q3aafx+1llpA5OZhVxNFFatgtN0q9cD4jCxG36277Egbetb3/7ASt41sin4KQjI= =UC73 -----END PGP SIGNATURE----- --------------enigDF36890EC952228A8D9A2C83-- From owner-freebsd-current@FreeBSD.ORG Wed Feb 20 01:24:35 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id D0F92CA9 for ; Wed, 20 Feb 2013 01:24:35 +0000 (UTC) (envelope-from oliver.pntr@gmail.com) Received: from mail-ob0-f177.google.com (mail-ob0-f177.google.com [209.85.214.177]) by mx1.freebsd.org (Postfix) with ESMTP id A2D107A9 for ; Wed, 20 Feb 2013 01:24:35 +0000 (UTC) Received: by mail-ob0-f177.google.com with SMTP id wc18so7105436obb.8 for ; Tue, 19 Feb 2013 17:24:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=lJuMjXbOCL4EjDMwdcNu4O6Mwl4ibc22SuON7zDnoEA=; b=wDHJdjs3ZHrBw4bV4CfkTi8y1Ol7Kh1dLKNmcLmTMsNv8vYnHWt500w4fF78oyZ7Eh AP/2cKmVhhMc2mUYfEnDDa91AQrvQy7lnNfWJW06KwSAZCkxE+X3TY2BHk5geuDRo29n 3pVxsxG2CTB5cURIi79r8PT7bEuAD5abcnb3lhSIBYdLEGUUj/Q/US3gz64uqzCP8LRS VieTWiWF3Cd7kC4Ui5DmrldWtl3JR/SoIG23QGCr2Jlg8BGVEkQ+rfjVc8Gbks3jcyae FjXui19FAr//q9z2A36a+QxBKHoViup0qj1SxJQNtwS9sR3i7hEDX3WZOz2aDKoNh3MI U6qQ== MIME-Version: 1.0 X-Received: by 10.60.172.80 with SMTP id ba16mr8625712oec.116.1361323469307; Tue, 19 Feb 2013 17:24:29 -0800 (PST) Received: by 10.182.161.100 with HTTP; Tue, 19 Feb 2013 17:24:29 -0800 (PST) In-Reply-To: References: Date: Wed, 20 Feb 2013 02:24:29 +0100 Message-ID: Subject: Re: system 20% busy at all times? From: Oliver Pinter To: "Eggert, Lars" Content-Type: text/plain; charset=ISO-8859-1 Cc: "current@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 20 Feb 2013 01:24:35 -0000 try other event timer source http://comments.gmane.org/gmane.os.freebsd.bugs/59695 On 2/19/13, Eggert, Lars wrote: > Hi, > > I have a system running -CURRENT that in top(1) is showing ~20% CPU usage > for the system at all times. Any ideas what could be causing this, or how I > would go about diagnosing this further? Nothing in the logs. > > Thanks, > Lars > > PS: dmesg attached, in case it helps: > > Copyright (c) 1992-2013 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 10.0-CURRENT #11 r+2fc9b3d: Tue Feb 12 19:32:15 CET 2013 > > elars@stanley.muccbc.hq.netapp.com:/home/elars/obj/usr/home/elars/src/sys/FAS3270 > amd64 > FreeBSD clang version 3.2 (tags/RELEASE_32/final 170710) 20121221 > CPU: Intel(R) Xeon(R) CPU E5240 @ 3.00GHz (3000.17-MHz K8-class > CPU) > Origin = "GenuineIntel" Id = 0x1067a Family = 0x6 Model = 0x17 > Stepping = 10 > > Features=0xbfebfbff > > Features2=0xc0ce3bd > AMD Features=0x20100800 > AMD Features2=0x1 > TSC: P-state invariant, performance statistics > real memory = 18253611008 (17408 MB) > avail memory = 16526143488 (15760 MB) > Event timer "LAPIC" quality 400 > ACPI APIC Table: > FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs > FreeBSD/SMP: 2 package(s) x 2 core(s) > cpu0 (BSP): APIC ID: 0 > cpu1 (AP): APIC ID: 1 > cpu2 (AP): APIC ID: 6 > cpu3 (AP): APIC ID: 7 > ioapic0 irqs 0-23 on motherboard > kbd0 at kbdmux0 > ctl: CAM Target Layer loaded > smbios0: at iomem 0xf6c00-0xf6c1e on motherboard > smbios0: Version: 2.5 > cryptosoft0: on motherboard > acpi0: on motherboard > acpi0: Power Button (fixed) > cpu0: on acpi0 > ACPI Error: [\134_SB_.PCI0.LPC0.BCMD] Namespace lookup failure, AE_NOT_FOUND > (20130117/psargs-393) > ACPI Error: Method parse/execution failed [\134_PR_.CPU0._OSC] (Node > 0xfffffe0007630c00), AE_NOT_FOUND (20130117/psparse-560) > ACPI Error: [\134_SB_.PCI0.LPC0.BCMD] Namespace lookup failure, AE_NOT_FOUND > (20130117/psargs-393) > ACPI Error: Method parse/execution failed [\134_PR_.CPU0._OSC] (Node > 0xfffffe0007630c00), AE_NOT_FOUND (20130117/psparse-560) > ACPI Error: Method parse/execution failed [\134_PR_.CPU0._PDC] (Node > 0xfffffe0007630c40), AE_NOT_FOUND (20130117/psparse-560) > cpu1: on acpi0 > cpu2: on acpi0 > cpu3: on acpi0 > atrtc0: port 0x70-0x71 irq 8 on acpi0 > Event timer "RTC" frequency 32768 Hz quality 0 > attimer0: port 0x40-0x43,0x50-0x53 irq 0 on acpi0 > Timecounter "i8254" frequency 1193182 Hz quality 0 > Event timer "i8254" frequency 1193182 Hz quality 100 > Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 > acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 > pcib0: port 0xcf8-0xcff on acpi0 > pci0: on pcib0 > pcib1: at device 2.0 on pci0 > pci1: on pcib1 > pci1: at device 0.0 (no driver attached) > pcib2: at device 3.0 on pci0 > pci2: on pcib2 > pcib3: at device 4.0 on pci0 > pci3: on pcib3 > pcib4: mem 0xdeb00000-0xdeb1ffff irq 16 at device 0.0 > on pci3 > pci4: on pcib4 > pcib4: no PRT entry for 4.4.INTA > pcib4: no PRT entry for 4.5.INTA > pcib4: no PRT entry for 4.8.INTA > pcib5: irq 5 at device 4.0 on pci4 > pci5: on pcib5 > pcib6: irq 10 at device 5.0 on pci4 > pci6: on pcib6 > pcib4: no PRT entry for 4.5.INTA > pcib4: no PRT entry for 4.5.INTB > ix0: mem > 0xdec00000-0xdec7ffff,0xded00000-0xded03fff irq 10 at device 0.0 on pci6 > ix0: Using MSIX interrupts with 5 vectors > ix0: Ethernet address: 90:e2:ba:2b:3b:6c > ix0: PCI Express Bus: Speed 5.0Gb/s Width x8 > ix1: mem > 0xdec80000-0xdecfffff,0xded04000-0xded07fff irq 11 at device 0.1 on pci6 > ix1: Using MSIX interrupts with 5 vectors > ix1: Ethernet address: 90:e2:ba:2b:3b:6d > ix1: PCI Express Bus: Speed 5.0Gb/s Width x8 > pcib7: irq 5 at device 8.0 on pci4 > pci7: on pcib7 > pcib8: at device 5.0 on pci0 > pci8: on pcib8 > pcib9: at device 6.0 on pci0 > pci9: on pcib9 > pcib10: mem 0xdee00000-0xdee1ffff irq 16 at device 0.0 on > pci9 > pci10: on pcib10 > pcib11: irq 16 at device 0.0 on pci10 > pci11: on pcib11 > pcib12: mem 0xdef00000-0xdef1ffff irq 16 at device 0.0 on > pci11 > pci12: on pcib12 > pcib13: irq 17 at device 1.0 on pci12 > pci13: on pcib13 > pcib14: irq 16 at device 4.0 on pci12 > pci14: on pcib14 > pcib15: irq 17 at device 5.0 on pci12 > pci15: on pcib15 > pcib16: irq 16 at device 8.0 on pci12 > pci16: on pcib16 > pcib17: at device 0.0 on pci16 > pci17: on pcib17 > pcib18: at device 0.0 on pci17 > pci18: on pcib18 > em0: mem > 0xdf020000-0xdf03ffff,0xdf000000-0xdf01ffff irq 16 at device 0.0 on pci18 > em0: Using an MSI interrupt > em0: Ethernet address: 00:1b:21:a8:a5:58 > em1: mem > 0xdf060000-0xdf07ffff,0xdf040000-0xdf05ffff irq 17 at device 0.1 on pci18 > em1: Using an MSI interrupt > em1: Ethernet address: 00:1b:21:a8:a5:59 > pcib19: at device 1.0 on pci17 > pci19: on pcib19 > em2: mem > 0xdf120000-0xdf13ffff,0xdf100000-0xdf11ffff irq 17 at device 0.0 on pci19 > em2: Using an MSI interrupt > em2: Ethernet address: 00:1b:21:a8:a5:5a > em3: mem > 0xdf160000-0xdf17ffff,0xdf140000-0xdf15ffff irq 18 at device 0.1 on pci19 > em3: Using an MSI interrupt > em3: Ethernet address: 00:1b:21:a8:a5:5b > pcib20: irq 17 at device 9.0 on pci12 > pci20: on pcib20 > pcib21: mem 0xdf200000-0xdf21ffff irq 17 at device 0.0 on > pci20 > pci21: on pcib21 > pcib22: irq 17 at device 4.0 on pci21 > pci22: on pcib22 > pcib23: irq 18 at device 5.0 on pci21 > pci23: on pcib23 > pci23: at device 0.0 (no driver attached) > pcib24: irq 17 at device 8.0 on pci21 > pci24: on pcib24 > pci24: at device 0.0 (no driver attached) > pcib25: irq 16 at device 4.0 on pci10 > pci25: on pcib25 > pcib26: irq 17 at device 5.0 on pci10 > pci26: on pcib26 > pci26: at device 0.0 (no driver attached) > pci26: at device 0.1 (no driver attached) > pcib27: irq 18 at device 6.0 on pci10 > pci27: on pcib27 > pci27: at device 0.0 (no driver attached) > pcib28: at device 7.0 on pci0 > pci28: on pcib28 > pci0: at device 8.0 (no driver attached) > uhci0: port 0x1820-0x183f irq 16 at > device 26.0 on pci0 > usbus0 on uhci0 > ehci0: mem 0xdfa01000-0xdfa013ff > irq 18 at device 26.7 on pci0 > usbus1: EHCI version 1.0 > usbus1 on ehci0 > pcib29: irq 16 at device 28.0 on pci0 > pci29: on pcib29 > em4: port 0x3000-0x301f mem > 0xdf720000-0xdf73ffff,0xdf700000-0xdf71ffff irq 16 at device 0.0 on pci29 > em4: Using an MSI interrupt > em4: Ethernet address: 00:a0:98:30:91:24 > em5: port 0x3020-0x303f mem > 0xdf760000-0xdf77ffff,0xdf740000-0xdf75ffff irq 17 at device 0.1 on pci29 > em5: Using an MSI interrupt > em5: Ethernet address: 00:a0:98:30:91:25 > pcib30: irq 16 at device 28.4 on pci0 > pci30: on pcib30 > bge0: > mem 0xdf800000-0xdf80ffff irq 16 at device 0.0 on pci30 > bge0: CHIP ID 0x00004201; ASIC REV 0x04; CHIP REV 0x42; PCI-E > miibus0: on bge0 > brgphy0: PHY 1 on miibus0 > brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, > 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow > bge0: Ethernet address: 00:a0:98:30:91:28 > pcib31: irq 17 at device 28.5 on pci0 > pci31: on pcib31 > bge1: > mem 0xdf900000-0xdf90ffff irq 17 at device 0.0 on pci31 > bge1: CHIP ID 0x00004201; ASIC REV 0x04; CHIP REV 0x42; PCI-E > miibus1: on bge1 > brgphy1: PHY 1 on miibus1 > brgphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, > 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow > bge1: Ethernet address: 00:a0:98:30:91:29 > uhci1: port 0x1840-0x185f irq 16 at > device 29.0 on pci0 > usbus2 on uhci1 > ehci1: mem 0xdfa01400-0xdfa017ff > irq 16 at device 29.7 on pci0 > usbus3: EHCI version 1.0 > usbus3 on ehci1 > pcib32: at device 30.0 on pci0 > pci32: on pcib32 > isab0: at device 31.0 on pci0 > isa0: on isab0 > ichsmb0: port 0x1860-0x187f mem > 0xdfa01800-0xdfa018ff irq 17 at device 31.3 on pci0 > smbus0: on ichsmb0 > smb0: on smbus0 > pci0: at device 31.6 (no driver attached) > acpi_button0: on acpi0 > uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 > uart0: console (9600,n,8,1) > uart1: <16550 or compatible> port 0x2f8-0x2ff irq 3 on acpi0 > ichwd0 on isa0 > ichwd0: ICH WDT present but disabled in BIOS or hardware > device_attach: ichwd0 attach returned 6 > ipmi0: on isa0 > ipmi0: KCS mode found at io 0xca2 alignment 0x1 on isa > ichwd0 at port 0x1030-0x1037,0x1060-0x107f on isa0 > ichwd0: ICH WDT present but disabled in BIOS or hardware > device_attach: ichwd0 attach returned 6 > orm0: at iomem > 0xc0800-0xc17ff,0xc1800-0xc27ff,0xdc000-0xdffff on isa0 > coretemp0: on cpu0 > est0: on cpu0 > p4tcc0: on cpu0 > coretemp1: on cpu1 > est1: on cpu1 > p4tcc1: on cpu1 > coretemp2: on cpu2 > est2: on cpu2 > p4tcc2: on cpu2 > coretemp3: on cpu3 > est3: on cpu3 > p4tcc3: on cpu3 > Timecounters tick every 1.000 msec > usbus0: 12Mbps Full Speed USB v1.0 > usbus1: 480Mbps High Speed USB v2.0 > ipfw2 (+ipv6) initialized, divert enabled, nat enabled, default to accept, > logging disabled > ugen0.1: at usbus0 > uhub0: on usbus0 > ugen1.1: at usbus1 > uhub1: on usbus1 > usbus2: 12Mbps Full Speed USB v1.0 > usbus3: 480Mbps High Speed USB v2.0 > ugen2.1: at usbus2 > uhub2: on usbus2 > ugen3.1: at usbus3 > uhub3: on usbus3 > ipmi0: IPMI device rev. 1, firmware rev. 1.00, version 2.0 > ipmi0: Number of channels 0 > ipmi0: Attached watchdog > bootpc_init: wired to interface 'em4' > Sending DHCP Discover packet from interface em4 (00:a0:98:30:91:24) > uhub0: 2 ports with 2 removable, self powered > uhub2: 2 ports with 2 removable, self powered > uhub1: 2 ports with 2 removable, self powered > uhub3: 2 ports with 2 removable, self powered > ugen3.2: at usbus3 > umass0: addr 2> on usbus3 > umass0: SCSI over Bulk-Only; quirks = 0x4000 > umass0:1:0:-1: Attached to scbus1 > da0 at umass-sim0 bus 0 scbus1 target 0 lun 0 > da0: Fixed Direct Access SCSI-0 device > da0: 40.000MB/s transfers > da0: 1936MB (3964928 512 byte sectors: 255H 63S/T 246C) > Received DHCP Offer packet on em4 from 0.0.0.0 (accepted) (no root path) > Sending DHCP Request packet from interface em4 (00:a0:98:30:91:24) > Received DHCP Ack packet on em4 from 0.0.0.0 (accepted) (got root path) > em4 at 10.11.12.5 server 0.0.0.0 > subnet mask 255.255.255.0 router 10.11.12.13 rootfs > 10.11.12.13:/usr/home/elars/dst > Adjusted interface em4 > SMP: AP CPU #3 Launched! > SMP: AP CPU #2 Launched! > SMP: AP CPU #1 Launched! > Timecounter "TSC-low" frequency 1500084729 Hz quality 1000 > hwpmc: SOFT/16/64/0x67 TSC/1/64/0x20 > IAP/2/40/0x3ff > IAF/3/40/0x67 > Trying to mount root from nfs: []... > NFS ROOT: 10.11.12.13:/usr/home/elars/dst > _______________________________________________ > 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 Wed Feb 20 01:52:56 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id BC3C83C3 for ; Wed, 20 Feb 2013 01:52:56 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id 74E2A8B7 for ; Wed, 20 Feb 2013 01:52:56 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqEEAGMrJFGDaFvO/2dsb2JhbABFhkm6AYEkc4IfAQEBBAEBASAEJyALBRYOCgICDRkCKQEJJgYIBwQBGgIEh3EMrWyCQJAggSOMJQUGgQc0B4ItgRMDiGaLDYI4gR2PO4MlT30IFx4 X-IronPort-AV: E=Sophos;i="4.84,698,1355115600"; d="scan'208";a="17368554" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-jnhn.mail.uoguelph.ca with ESMTP; 19 Feb 2013 20:52:49 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id DCA7CB3F17; Tue, 19 Feb 2013 20:52:49 -0500 (EST) Date: Tue, 19 Feb 2013 20:52:49 -0500 (EST) From: Rick Macklem To: Andrey Simonenko Message-ID: <747768617.3137250.1361325169865.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <20130219102744.GA2426@pm513-1.comsys.ntu-kpi.kiev.ua> Subject: Re: Possible bug in NFSv4 with krb5p security? MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.203] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - FF3.0 (Win)/6.0.10_GA_2692) Cc: freebsd-current@freebsd.org, Elias Martenson , Benjamin Kaduk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 20 Feb 2013 01:52:56 -0000 Andrey Simonenko wrote: > On Tue, Feb 19, 2013 at 05:35:50PM +0800, Elias Martenson wrote: > > On 19 February 2013 17:31, Andrey Simonenko > > wrote: > > > > It can require bigger buffer, since root can get the pw_password > > field > > > in the struct passwd{}. > > > > > > Since sysconf(_SC_GETPW_R_SIZE_MAX) does not work on FreeBSD, the > > > buffer > > > for getpwnam_r() call should have at least (2 * MAXLOGNAME + 2 * > > > MAXPATHLEN + > > > _PASSWORD_LEN + 1) bytes (it is unclear how much is required for > > > pw_gecos). > > > > > > This buffer can be dynamically reallocated until getpwnam_r() is > > > not > > > return ERANGE error (the following code has not been compiled and > > > verified): > > > > > > > Is this really a better solution than to aim high right away? A > > series of > > malloc() calls should certainly have much higher overhead than the > > previous > > stack-allocated solution. > > > > A better compromise would be to do the lookup in a separate > > function, that > > allocates the buffer using alloca() instead, yes? > > I cannot find how to get information about maximum buffer size for > the getpwnam_r() function. This information should be returned by > sysconf(_SC_GETPW_R_SIZE_MAX), but since it does not work on FreeBSD > it is necessary to guess its size. Original value is 128 and it works > for somebody, 1024 works for your environment, but it can fail for > another environment. > > SUSv4 specifies "Storage referenced by the structure is allocated from > the memory provided with the buffer parameter", but then tells about > groups > in EXAMPLE for getpwnam_r() "Note that sysconf(_SC_GETPW_R_SIZE_MAX) > may > return -1 if there is no hard limit on the size of the buffer needed > to > store all the groups returned". > > malloc() can give overhead, but that function can try to call > getpwnam_r() > with buffer allocated from stack and if getpwnam_r() failed with > ERANGE > use dynamically allocated buffer. > > #define PWBUF_SIZE_INI (2 * MAXLOGNAME + 2 * MAXPATHLEN + > _PASSWORD_LEN + 1) > #define PWBUF_SIZE_INC 128 > > char bufs[2 * MAXLOGNAME + MAXPATHLEN + PASSWORD_LEN + 1 + 32]; > > error = getpwnam_r(lname, &pwd, bufs, sizeof(bufs), &pw); > if (pw != NULL) { > *uidp = pw->pw_uid; > return (GSS_S_COMPLETE); > } else if (error != ERANGE) > return (GSS_S_FAILURE); > > size = PWBUF_SIZE_INI; > for (;;) { > size += PWBUF_SIZE_INC; > buf = malloc(size); > if (buf == NULL) > return (GSS_S_FAILURE); > error = getpwnam_r(lname, &pwd, buf, size, &pw); > free(buf); > if (pw != NULL) { > *uidp = pw->pw_uid; > return (GSS_S_COMPLETE); > } else { > if (error == ERANGE && > size <= SIZE_MAX - PWBUF_SIZE_INC) > continue; > return (GSS_S_FAILURE); > } > } Just my opinion, but I think the above is a good approach. (ie. First trying a fairly large buffer on the stack that will succeed 99.99% of the time, but check for ERANGE and loop trying progressively larger malloc'd buffers until it stops reporting ERANGE.) I suspect the overheads behind getpwnam_r() are larger than the difference between using a buffer on the stack vs malloc, so I think it should use a fairly large buffer the first time. Personally, I might have coded it as a single do { } while(), with the first attempt in it, but that's just personal stylistic taste. (You can check for buf != bufs before doing a free() of it.) And, if you wanted to be clever, the code could use a static "bufsiz_hint", which is set to the largest size needed sofar and that is used as the initial malloc size. That way it wouldn't loop as much for a site with huge passwd entries. (An entire bio in the GECOS field or ???) Btw, the same fix is needed in gssd.c, where it calls getpwuid_r(). { Interesting that for Elias's case, it must work for 128, although the getpwnam_r() didn't quite fit in 128. } Also, FYI, kuserok.c uses a 2048 byte buffer and doesn't check for ERANGE. rick > _______________________________________________ > 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 Wed Feb 20 04:02:19 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id F0886A1F for ; Wed, 20 Feb 2013 04:02:19 +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 AFE19E29 for ; Wed, 20 Feb 2013 04:02:19 +0000 (UTC) Received: from JRE-MBP-2.local (c-98-210-232-101.hsd1.ca.comcast.net [98.210.232.101]) (authenticated bits=0) by vps1.elischer.org (8.14.5/8.14.5) with ESMTP id r1K42BXo030570 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Tue, 19 Feb 2013 20:02:11 -0800 (PST) (envelope-from julian@freebsd.org) Message-ID: <51244AC2.9030207@freebsd.org> Date: Tue, 19 Feb 2013 20:02:10 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: system 20% busy at all times? References: <36DD2FB4-E26A-4F03-95D9-FFD855957269@my.gd> <8F861CF6-D0FA-4BD2-B73D-24CB247584A1@my.gd> In-Reply-To: <8F861CF6-D0FA-4BD2-B73D-24CB247584A1@my.gd> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 20 Feb 2013 04:02:20 -0000 On 2/19/13 2:21 AM, Fleuriot Damien wrote: > On Feb 19, 2013, at 11:16 AM, "Eggert, Lars" wrote: > >> Hi, >> >> On Feb 19, 2013, at 10:54, Fleuriot Damien >> wrote: >>> And indeed we find your answer here, acpi0 firing up a lot of interrupts. >>> >>> Don't you get any message about that in dmesg -a or /var/log/messages ? >>> >>> I'd expect something like "interrupt storm blabla… source throttled blabla.." >> nope. The only odd ACPI-related messages I see in dmesg are these: >> >> ACPI Error: [\134_SB_.PCI0.LPC0.BCMD] Namespace lookup failure, AE_NOT_FOUND (20130117/psargs-393) >> ACPI Error: Method parse/execution failed [\134_PR_.CPU0._OSC] (Node 0xfffffe0007630c00), AE_NOT_FOUND (20130117/psparse-560) >> ACPI Error: [\134_SB_.PCI0.LPC0.BCMD] Namespace lookup failure, AE_NOT_FOUND (20130117/psargs-393) >> ACPI Error: Method parse/execution failed [\134_PR_.CPU0._OSC] (Node 0xfffffe0007630c00), AE_NOT_FOUND (20130117/psparse-560) >> ACPI Error: Method parse/execution failed [\134_PR_.CPU0._PDC] (Node 0xfffffe0007630c40), AE_NOT_FOUND (20130117/psparse-560) >> >> Nothing in syslog. >> >>> From man 4 acpi , in /boot/loader.conf : >>> hint.acpi.0.disabled=1 >>> Set this to 1 to disable all of ACPI. If ACPI has been disabled >>> on your system due to a blacklist entry for your BIOS, you can >>> set this to 0 to re-enable ACPI for testing. >>> >>> Any chance you could reboot the host with ACPI disabled ? >> If I do that, I get an early kernel crash: >> >> Loading 10.11.12.13/~elars/kernel/kernel:0x200000/7634255 0xb47d50/473552 0xbbb720/890736 Entry at 0x802746f0 >> Closing network. >> Starting program at 0x802746f0 >> GDB: no debug ports present >> KDB: debugger backends: ddb >> KDB: current backend: ddb >> panic: running without device atpic requires a local APIC >> cpuid = 0 >> KDB: stack backtrace: >> kernel trap 12 with interrupts disabled >> >> >> Fatal trap 12: page fault while in kernel mode >> cpuid = 0; apic id = 00 >> fault virtual address = 0x0 >> fault code = supervisor read data, page not present >> instruction pointer = 0x20:0xffffffff805c2973 >> stack pointer = 0x28:0xffffffff80c9a960 >> frame pointer = 0x28:0xffffffff80c9aa80 >> code segment = base 0x0, limit 0xfffff, type 0x1b >> = DPL 0, pres 1, long 1, def32 0, gran 1 >> processor eflags = resume, IOPL = 0 >> current process = 0 () >> [ thread pid 0 tid 0 ] >> Stopped at 0xffffffff805c2973: movzbl (%rdi),%ecx >> >> >>> If that helps your CPU load, try setting this in /boot/loader.conf : >>> hw.acpi.verbose=1 >>> Turn on verbose debugging information about what ACPI is doing. >> Done, but it doesn't really result in any additional messages: >> >> # dmesg | grep -i acpi >> Features=0xbfebfbff >> ACPI APIC Table: >> acpi0: on motherboard >> acpi0: Power Button (fixed) >> cpu0: on acpi0 >> ACPI Error: [\134_SB_.PCI0.LPC0.BCMD] Namespace lookup failure, AE_NOT_FOUND (20130117/psargs-393) >> ACPI Error: Method parse/execution failed [\134_PR_.CPU0._OSC] (Node 0xfffffe0007630c00), AE_NOT_FOUND (20130117/psparse-560) >> ACPI Error: [\134_SB_.PCI0.LPC0.BCMD] Namespace lookup failure, AE_NOT_FOUND (20130117/psargs-393) >> ACPI Error: Method parse/execution failed [\134_PR_.CPU0._OSC] (Node 0xfffffe0007630c00), AE_NOT_FOUND (20130117/psparse-560) >> ACPI Error: Method parse/execution failed [\134_PR_.CPU0._PDC] (Node 0xfffffe0007630c40), AE_NOT_FOUND (20130117/psparse-560) >> cpu1: on acpi0 >> cpu2: on acpi0 >> cpu3: on acpi0 >> atrtc0: port 0x70-0x71 irq 8 on acpi0 >> attimer0: port 0x40-0x43,0x50-0x53 irq 0 on acpi0 >> Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 >> acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 >> pcib0: port 0xcf8-0xcff on acpi0 >> pci0: on pcib0 >> pcib1: at device 2.0 on pci0 >> pci1: on pcib1 >> pcib3: at device 4.0 on pci0 >> pci3: on pcib3 >> pcib4: mem 0xdeb00000-0xdeb1ffff irq 16 at device 0.0 on pci3 >> pci4: on pcib4 >> pcib7: irq 5 at device 8.0 on pci4 >> pci7: on pcib7 >> pcib29: irq 16 at device 28.0 on pci0 >> pci29: on pcib29 >> pcib30: irq 16 at device 28.4 on pci0 >> pci30: on pcib30 >> pcib31: irq 17 at device 28.5 on pci0 >> pci31: on pcib31 >> pcib32: at device 30.0 on pci0 >> pci32: on pcib32 >> acpi_button0: on acpi0 >> uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 >> uart1: <16550 or compatible> port 0x2f8-0x2ff irq 3 on acpi0 >> > > > Jeez, I certainly hope people more knowledgeable than me about the kernel will be able to make something of all this. > > > What about a newly build kernel without the line "device acpi" and without the options ACPI_DEBUG ? > Hoping that this kernel: > 1/ won't crash on boot > 2/ will make the 20% cpu load and high interrupt rates disappear you need top -S or hit 'S' while running, to see system processes. you may also benefit from 'H' > > _______________________________________________ > 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 Wed Feb 20 04:37:49 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 71AD0D9; Wed, 20 Feb 2013 04:37:49 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-pb0-f45.google.com (mail-pb0-f45.google.com [209.85.160.45]) by mx1.freebsd.org (Postfix) with ESMTP id 23A04F66; Wed, 20 Feb 2013 04:37:48 +0000 (UTC) Received: by mail-pb0-f45.google.com with SMTP id ro8so2646591pbb.32 for ; Tue, 19 Feb 2013 20:37:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:date:to:cc:subject:message-id:reply-to:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=VhrYFAZmirpVhYOZfEICpqf2CJB70AG0DTNgLhJ28RU=; b=GigZn0ur4DnxTQi/BiHkILxzNHL/ZsPyY5KCU/LnixmLxp/T423hbiZWwGOHeYiOCY d+TIMXP90nHAl2F/AZkW4pF3vXmIu9jY1IrE/F2L8+imNxd77mcrYgj80gk9h+jfINcw jb0zGGNOaAKigAS2dzxWIulz6GyUNqDABf9Imf+0xqNamtzIXpb12HV/Of3023DepD0V Fsmdq/k2pqo4mpUPjpk1xtSyzTyW/IKa1Uafm7p3l8FmG1VjY9j5WHpSyyD//6+KQw1A Iv9iCvqTEwJEUBBYZK6zyIx1qaRqWue82qJjBz+ohiLsFW/ltzxszgJEs3SCfrRWdSnf FJlQ== X-Received: by 10.66.250.169 with SMTP id zd9mr384255pac.134.1361335068608; Tue, 19 Feb 2013 20:37:48 -0800 (PST) Received: from pyunyh@gmail.com (lpe4.p59-icn.cdngp.net. [114.111.62.249]) by mx.google.com with ESMTPS id w2sm104337167pax.22.2013.02.19.20.37.45 (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 19 Feb 2013 20:37:47 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Wed, 20 Feb 2013 13:37:39 +0900 From: YongHyeon PYUN Date: Wed, 20 Feb 2013 13:37:39 +0900 To: Alexey Dokuchaev Subject: Re: ale(4) cannot negotiate as GigE Message-ID: <20130220043739.GA1469@michelle.cdnetworks.com> References: <20130219082302.GA86501@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130219082302.GA86501@FreeBSD.org> User-Agent: Mutt/1.4.2.3i Cc: current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 04:37:49 -0000 On Tue, Feb 19, 2013 at 08:23:02AM +0000, Alexey Dokuchaev wrote: > Hi there, > > I've recently put back online one of my home servers, updated to the latest > -CURRENT code. All went fine, but one thing bothers me. This box bears > Asus P5Q Pro mobo, with the following onboard NIC: > > ale0@pci0:2:0:0: class=0x020000 card=0x82261043 chip=0x10261969 > rev=0xb0 hdr=0x00 > vendor = 'Atheros Communications Inc.' > device = 'AR8121/AR8113/AR8114 Gigabit or Fast Ethernet' > class = network > subclass = ethernet > > According the the specs, it should be GigE. In fact, when plugged into a > capable switch, it displays "green" (gig) status (same on the switch), but > once being initialized by the kernel, it downgrades to yellowish 100mbps > (real speeds agree). There is a fast etherenet version(L2E) so I'm not sure what you have. Could you show me dmesg output(ale(4) & atphy(4) only) and "devinfo -rv| grep atphy"? > > I'm not sure why it happens; maybe it's somehow related to a handful of > those "ale0: link state changed to DOWN/UP" flip-flops I see in dmesg(8), > before it can finally obtain DHCP lease? That's normal when you initiates auto-negotiation with dhclient. > > I remember these adapters had problems in the past, like infamous "Corrupted > MAC on input" disconnect messages, but I don't recall that I could not use > it in GigE mode. Anything I can do about it? Googling did not help much: > most reports date back to ca. 2009, and apparently were ironed out in later > revisions (e.g. selectively disabling checksum offloading). Thanks, > If you still see the "Corrupted MAC on input" message, let me know. > ./danfe From owner-freebsd-current@FreeBSD.ORG Wed Feb 20 06:08:53 2013 Return-Path: Delivered-To: current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1033) id 150A6E14; Wed, 20 Feb 2013 06:08:53 +0000 (UTC) Date: Wed, 20 Feb 2013 06:08:53 +0000 From: Alexey Dokuchaev To: YongHyeon PYUN Subject: Re: ale(4) cannot negotiate as GigE Message-ID: <20130220060853.GA83110@FreeBSD.org> References: <20130219082302.GA86501@FreeBSD.org> <20130220043739.GA1469@michelle.cdnetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20130220043739.GA1469@michelle.cdnetworks.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 20 Feb 2013 06:08:53 -0000 On Wed, Feb 20, 2013 at 01:37:39PM +0900, YongHyeon PYUN wrote: > On Tue, Feb 19, 2013 at 08:23:02AM +0000, Alexey Dokuchaev wrote: > > ale0@pci0:2:0:0: class=0x020000 card=0x82261043 chip=0x10261969 > > rev=0xb0 hdr=0x00 > > vendor = 'Atheros Communications Inc.' > > device = 'AR8121/AR8113/AR8114 Gigabit or Fast Ethernet' > > class = network > > subclass = ethernet > > > > According the the specs, it should be GigE. [...] > > There is a fast etherenet version(L2E) so I'm not sure what you > have. Could you show me dmesg output(ale(4) & atphy(4) only) and > "devinfo -rv | grep atphy"? $ dmesg | egrep ale\|atphy ale0: port 0xcc00-0xcc7f mem 0xfe9c0000-0xfe9fffff irq 17 at device 0.0 on pci2 ale0: 960 Tx FIFO, 1024 Rx FIFO ale0: Using 1 MSI messages. ale0: 4GB boundary crossed, switching to 32bit DMA addressing mode. miibus0: on ale0 atphy0: PHY 0 on miibus0 atphy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow $ devinfo -rv | grep atphy atphy0 pnpinfo oui=0xc82e model=0x1 rev=0x9 at phyno=0 > > I'm not sure why it happens; maybe it's somehow related to a handful of > > those "ale0: link state changed to DOWN/UP" flip-flops I see in dmesg(8), > > before it can finally obtain DHCP lease? > > That's normal when you initiate auto-negotiation with dhclient. Yes, I've already seen your lengthy explanation [1], thanks! > > I remember these adapters had problems in the past, like infamous > > "Corrupted MAC on input" disconnect messages, but I don't recall that I > > could not use it in GigE mode. [...] > > If you still see the "Corrupted MAC on input" message, let me know. No, those are long gone now (hopefully; at least I haven't seen them for a while). ./danfe [1] http://lists.freebsd.org/pipermail/freebsd-net/2009-January/020662.html From owner-freebsd-current@FreeBSD.ORG Wed Feb 20 09:10:12 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 4E4CCCC0; Wed, 20 Feb 2013 09:10:12 +0000 (UTC) (envelope-from mexas@bristol.ac.uk) Received: from dirj.bris.ac.uk (dirj.bris.ac.uk [137.222.10.78]) by mx1.freebsd.org (Postfix) with ESMTP id 044D3DB5; Wed, 20 Feb 2013 09:10:11 +0000 (UTC) Received: from irix.bris.ac.uk ([137.222.10.39] helo=ncs.bris.ac.uk) by dirj.bris.ac.uk with esmtp (Exim 4.72) (envelope-from ) id 1U85gS-00003U-C9; Wed, 20 Feb 2013 09:10:09 +0000 Received: from mech-cluster241.men.bris.ac.uk ([137.222.187.241]) by ncs.bris.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1U85gS-0006Zd-3e; Wed, 20 Feb 2013 09:09:48 +0000 Received: from mech-cluster241.men.bris.ac.uk (localhost [127.0.0.1]) by mech-cluster241.men.bris.ac.uk (8.14.6/8.14.6) with ESMTP id r1K99lxY029376; Wed, 20 Feb 2013 09:09:47 GMT (envelope-from mexas@mech-cluster241.men.bris.ac.uk) Received: (from mexas@localhost) by mech-cluster241.men.bris.ac.uk (8.14.6/8.14.6/Submit) id r1K99lx0029375; Wed, 20 Feb 2013 09:09:47 GMT (envelope-from mexas) Date: Wed, 20 Feb 2013 09:09:47 GMT From: Anton Shterenlikht Message-Id: <201302200909.r1K99lx0029375@mech-cluster241.men.bris.ac.uk> To: freebsd-current@FreeBSD.org, freebsd-performance@freebsd.org, ohartman@zedat.fu-berlin.de Subject: Re: PathScale EKO Path 5 not for FreeBSD anymore? In-Reply-To: <5124063D.2060604@zedat.fu-berlin.de> X-Spam-Score: -3.7 X-Spam-Level: --- X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: mexas@bristol.ac.uk List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 09:10:12 -0000 Oliver I try to use FreeBSD for day-to-day numerical work, as far as possible. I have to complement it with linux cluster systems, largely due to a range of compilers available there. Anyway, keep me posted if you get anywhere with this. Anton From owner-freebsd-current@FreeBSD.ORG Wed Feb 20 09:39:01 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 35EEC5DF; Wed, 20 Feb 2013 09:39:01 +0000 (UTC) (envelope-from lars@netapp.com) Received: from mx1.netapp.com (mx1.netapp.com [216.240.18.38]) by mx1.freebsd.org (Postfix) with ESMTP id 11886F42; Wed, 20 Feb 2013 09:39:00 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.84,699,1355126400"; d="scan'208";a="242733681" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx1-out.netapp.com with ESMTP; 20 Feb 2013 01:39:00 -0800 Received: from vmwexceht01-prd.hq.netapp.com (vmwexceht01-prd.hq.netapp.com [10.106.76.239]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id r1K9d07G026610; Wed, 20 Feb 2013 01:39:00 -0800 (PST) Received: from SACEXCMBX01-PRD.hq.netapp.com ([169.254.2.54]) by vmwexceht01-prd.hq.netapp.com ([10.106.76.239]) with mapi id 14.02.0328.009; Wed, 20 Feb 2013 01:38:59 -0800 From: "Eggert, Lars" To: Adrian Chadd Subject: Re: system 20% busy at all times? Thread-Topic: system 20% busy at all times? Thread-Index: AQHODoSUIkOKNPDzb0yS23V/tl+kl5iBc1WAgAABSACAAAKwgIAABj+AgAABMwCAAAHkAIAADReAgAAQIgCAAADlAIAABhMAgAAOCwCAADrggIABF46A Date: Wed, 20 Feb 2013 09:38:58 +0000 Message-ID: References: <36DD2FB4-E26A-4F03-95D9-FFD855957269@my.gd> <8F861CF6-D0FA-4BD2-B73D-24CB247584A1@my.gd> <51235EA7.6000208@FreeBSD.org> <20130219121544.GU83110@e-new.0x20.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.106.53.51] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <02863F937BB2814EB100AD2CC282CB8A@tahoe.netapp.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Lars Engels , "current@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 20 Feb 2013 09:39:01 -0000 Hi, On Feb 19, 2013, at 17:58, Adrian Chadd wrote: > Try top -HS .. to try and break down the kernel threads. ACPI is eating the cycles, according to top: 0 root 8 0 0K 496K - 2 1:13 27.88% kernel{acpi= _task_2} 0 root 8 0 0K 496K - 0 1:13 25.68% kernel{acpi= _task_1} 0 root 8 0 0K 496K CPU1 1 1:07 23.68% kernel{acpi= _task_0} I got an off-list hint that the machine in question requires "device mptabl= e" instead of relying on ACPI. I will try that. As for dtrace, a complete buildworld/installworld cycle didn't change thing= s, I still get: # dtrace -n 'syscall:::entry { @num[execname] =3D count(); }' dtrace: invalid probe specifier syscall:::entry { @num[execname] =3D count(= ); }: "/usr/lib/dtrace/psinfo.d", line 90: failed to resolve type kernel`st= ruct thread * for identifier curthread: Module is no longer loaded Thanks for all the help! Lars= From owner-freebsd-current@FreeBSD.ORG Wed Feb 20 09:55:02 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 11F87D0B; Wed, 20 Feb 2013 09:55:02 +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 C9FB6C8; Wed, 20 Feb 2013 09:55:01 +0000 (UTC) Received: from ds4.des.no (smtp.des.no [194.63.250.102]) by smtp-int.des.no (Postfix) with ESMTP id 4A6636BF9; Wed, 20 Feb 2013 09:55:00 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id 0A0B594DA; Wed, 20 Feb 2013 10:54:59 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Davide Italiano Subject: Re: r246916 probably broke amd64 build References: Date: Wed, 20 Feb 2013 10:54:59 +0100 In-Reply-To: (Davide Italiano's message of "Tue, 19 Feb 2013 17:46:33 +0100") Message-ID: <86ip5nxqbw.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: "Simon L. B. Nielsen" , freebsd-current , mav@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 20 Feb 2013 09:55:02 -0000 Davide Italiano writes: > Unfortunately tinderbox didn't catch this bug because it's triggered > only when gcc is used to build kernel. In this particular case, the broken code is only built on platforms which default to clang. Otherwise, it would have been caught when building one of the platforms that default to gcc. The tinderbox servers simply donn't have enough CPU power to build all possible combinations. There isn't even enough for a standard build of all platforms at a reasonable frequency. I have a stack of new servers, but nowhere to host them - see the donations wantlist for details. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Wed Feb 20 10:18:54 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id D9DA677B; Wed, 20 Feb 2013 10:18:54 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from theravensnest.org (theraven.freebsd.your.org [216.14.102.27]) by mx1.freebsd.org (Postfix) with ESMTP id 9F13C240; Wed, 20 Feb 2013 10:18:51 +0000 (UTC) Received: from [192.168.0.2] (cpc10-cmbg15-2-0-cust123.5-4.cable.virginmedia.com [86.30.246.124]) (authenticated bits=0) by theravensnest.org (8.14.5/8.14.5) with ESMTP id r1KAIhxs051546 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 20 Feb 2013 10:18:44 GMT (envelope-from theraven@FreeBSD.org) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: PathScale EKO Path 5 not for FreeBSD anymore? From: David Chisnall In-Reply-To: <5124063D.2060604@zedat.fu-berlin.de> Date: Wed, 20 Feb 2013 10:18:43 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5124063D.2060604@zedat.fu-berlin.de> To: "O. Hartmann" X-Mailer: Apple Mail (2.1499) Cc: freebsd-performance@FreeBSD.org, Current FreeBSD , =?iso-8859-1?Q?=22C=2E_Bergstr=F6m=22?= X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 20 Feb 2013 10:18:54 -0000 I forwarded this thread to Christopher Bergst=F6m and got this reply: > ---------------- > FreeBSD simply isn't a scientific computing platform - There isn't any = market demand, it's not designed for it, many of the tools commonly used = aren't available and the amount of work to change that is significant. = (I don't just mean technical, but also mindshare for those in the = technical computing field) > ---------------- > However, we haven't dropped support for it > = http://c591116.r16.cf2.rackcdn.com/enzo/nightly/FreeBSD/enzo-2013-02-19-in= staller.run >=20 > There's a few GPGPU related bugs we'd have to fix for it to work for = you, but those are pretty small and wouldn't take more than a few days. > ---------------- > We made some big changes in EKOPath 5/ENZO and development is closed = for now. We're trying to figure out a strategy which will have an = impact and be win/win for everyone. > ---------------- > Apologies if I may have dropped the ball on communication. I'm not = subscribed to -current or -performance and please cc me on any replies. >=20 > ./C A few additional comments: - FreeBSD libm really needs to get the missing C99 functions committed. = We have good versions of these written now (with better accuracy than = several competing operating systems that are successful scientific = computing platforms), but they need committing. Of the 31 test failures = in the libc++ test suite (which covers most of C++11) that I see = currently, 18 are due to missing C99 functionality. Most of the missing = functions are implemented, but committing them was held up by style nits = in the source code. This is just embarrassing. =20 - GPU support has been quite poor on FreeBSD, and this has a knock-on = effect on GPGPU. It's a mistake to think of GPUs as just things gamers = need and therefore not too important for FreeBSD - they're currently the = best performance-per-dollar accelerators available on the market and so = are of interest in a number of markets. If you or your company is using = FreeBSD and wants to do GPGPU things, then make sure that AMD, Intel, = and nVidia all know, and ideally let Qualcomm and ARM know too. The = FreeBSD Foundation has funded work on KMS, GEM and TTM, and so open = source driver support is improving. If you're willing to fund some more = of this work, then please get in touch with the Foundation. Most of the = companies in this space don't care what we say, they care what their = customers (and potential customers) say. They won't support FreeBSD if = there's no (perceived) demand, so it's important to make sure that = they're aware of the demand. - A big part of the problem is mindshare. Linux is seen as the thing to = use on clusters and supercomputers, even when it isn't the best tool for = the job. It's hard to contradict this view when there aren't any = (public) large-scale deployments of FreeBSD for scientific computing. = If you have one that you're willing to talk about, please contact the = Foundation and let them know. =20 David= From owner-freebsd-current@FreeBSD.ORG Wed Feb 20 10:21:10 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 8EC4993A; Wed, 20 Feb 2013 10:21:10 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id 50D1A269; Wed, 20 Feb 2013 10:21:09 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) with esmtp (envelope-from ) id <1U86nU-0015oc-V3>; Wed, 20 Feb 2013 11:21:09 +0100 Received: from e178026106.adsl.alicedsl.de ([85.178.26.106] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1U86nU-003Se9-Rk>; Wed, 20 Feb 2013 11:21:08 +0100 Message-ID: <5124A38B.7020700@zedat.fu-berlin.de> Date: Wed, 20 Feb 2013 11:20:59 +0100 From: "O. Hartmann" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130131 Thunderbird/17.0.2 MIME-Version: 1.0 To: Current FreeBSD , "freebsd-ports >> Ports FreeBSD" Subject: WITH_BMAKE: make: "/usr/ports/Mk/bsd.port.mk" line 5137: warning: using previous script for "-depends" defined here X-Enigmail-Version: 1.4.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigFBB784384238197BFF7E9E8B" X-Originating-IP: 85.178.26.106 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 20 Feb 2013 10:21:10 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigFBB784384238197BFF7E9E8B Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable Well, I'm brave and switched several "beta switches" on my FreeBSD 10.0-CUR systems on and I realize, that I receive a lot of make: "/usr/ports/Mk/bsd.port.mk" line 5137: warning: using previous script for "-depends" defined here make: "/usr/ports/Mk/bsd.port.mk" line 5140: warning: duplicate script for target "-depends" ignored messages when doing updates with portmaster or installing ports. I think this is "BETA-normal", but a re there serious implications apart from some performance issues at the moment using bmake as the replacement for the oldish make in FreeBSD? I'm just curious, so feel free to answer if you like. Oliver --------------enigFBB784384238197BFF7E9E8B 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.19 (FreeBSD) iQEcBAEBAgAGBQJRJKOUAAoJEOgBcD7A/5N8kEcH/2J9PyAOIsjvAU8ok/fJlLXA Vh6Z7UEezL6vWZ2wBtMKSDahCdA+pwD2VRjTZxgS2wQ2oN74zy0Amrlr7nXbdUwq fIUAlPOL6xgyfHJSsWjm2UPYhC6DktEIQFpS06D+K0sd5+J3Fn0mfqDB5z6CRjeb TMu3gc0lctMfdGB/0mnhfc9y8bIZt+v98TjT6EuqrLQ6L8mfKAc4vknrfSgeEGJn jDRPzbGmvIQ3TgX4TxN2/7Abm6y9e+/DVPeCNH7Xl12DQTmDDu5UuR+/1mj1aDyv yRf4lHhsJe5qE1TqE/nT8p3WYW9b0otk3i/+st4oW0hNqtxIHjye9eDNcrdM+6Y= =g/os -----END PGP SIGNATURE----- --------------enigFBB784384238197BFF7E9E8B-- From owner-freebsd-current@FreeBSD.ORG Wed Feb 20 11:09:19 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 1A551F79 for ; Wed, 20 Feb 2013 11:09:19 +0000 (UTC) (envelope-from mexas@bristol.ac.uk) Received: from dirj.bris.ac.uk (dirj.bris.ac.uk [137.222.10.78]) by mx1.freebsd.org (Postfix) with ESMTP id B9D7E7AC for ; Wed, 20 Feb 2013 11:09:18 +0000 (UTC) Received: from irix.bris.ac.uk ([137.222.10.39] helo=ncs.bris.ac.uk) by dirj.bris.ac.uk with esmtp (Exim 4.72) (envelope-from ) id 1U87Y3-00036P-Az for freebsd-current@freebsd.org; Wed, 20 Feb 2013 11:09:17 +0000 Received: from mech-cluster241.men.bris.ac.uk ([137.222.187.241]) by ncs.bris.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1U87Y3-0004ff-53 for freebsd-current@freebsd.org; Wed, 20 Feb 2013 11:09:15 +0000 Received: from mech-cluster241.men.bris.ac.uk (localhost [127.0.0.1]) by mech-cluster241.men.bris.ac.uk (8.14.6/8.14.6) with ESMTP id r1KB9E2J062501 for ; Wed, 20 Feb 2013 11:09:14 GMT (envelope-from mexas@mech-cluster241.men.bris.ac.uk) Received: (from mexas@localhost) by mech-cluster241.men.bris.ac.uk (8.14.6/8.14.6/Submit) id r1KB9E89062500 for freebsd-current@freebsd.org; Wed, 20 Feb 2013 11:09:14 GMT (envelope-from mexas) Date: Wed, 20 Feb 2013 11:09:14 GMT From: Anton Shterenlikht Message-Id: <201302201109.r1KB9E89062500@mech-cluster241.men.bris.ac.uk> To: freebsd-current@freebsd.org Subject: Re: daily otput: rejected mail hosts? X-Spam-Score: -3.8 X-Spam-Level: --- X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: mexas@bristol.ac.uk List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 11:09:19 -0000 From mexas Thu Feb 14 09:51:50 2013 To: freebsd-questions@freebsd.org Subject: daily otput: rejected mail hosts? Reply-To: mexas@bristol.ac.uk I see in the daily output: Checking for rejected mail hosts: 172 553 check_mail system.mail exist 129 553 check_mail tsvpt014.vpt.co.uk exist 43 553 check_mail unix.dedicated.com.tr exist 43 553 check_mail ubs.net exist 43 553 check_mail localhost.localdomain exist 43 553 check_mail journal-cfp.org exist 43 553 check_mail italiasito.it exist What is that about? Is this described somewhere in sendmail manuals? I got no reply from questions@, so trying my luck here. Thanks Anton From owner-freebsd-current@FreeBSD.ORG Wed Feb 20 11:18:49 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 9A31C91A; Wed, 20 Feb 2013 11:18:49 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id 425CA871; Wed, 20 Feb 2013 11:18:48 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) with esmtp (envelope-from ) id <1U87hH-001P7Z-Pt>; Wed, 20 Feb 2013 12:18:47 +0100 Received: from e178025207.adsl.alicedsl.de ([85.178.25.207] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1U87hH-003XTV-Kw>; Wed, 20 Feb 2013 12:18:47 +0100 Message-ID: <5124B115.70707@zedat.fu-berlin.de> Date: Wed, 20 Feb 2013 12:18:45 +0100 From: "O. Hartmann" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130131 Thunderbird/17.0.2 MIME-Version: 1.0 To: mexas@bristol.ac.uk Subject: Re: PathScale EKO Path 5 not for FreeBSD anymore? References: <201302200909.r1K99lx0029375@mech-cluster241.men.bris.ac.uk> In-Reply-To: <201302200909.r1K99lx0029375@mech-cluster241.men.bris.ac.uk> X-Enigmail-Version: 1.4.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigBB5DB0F6429156B22412AB2A" X-Originating-IP: 85.178.25.207 Cc: freebsd-performance@freebsd.org, freebsd-current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 20 Feb 2013 11:18:49 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigBB5DB0F6429156B22412AB2A Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Am 02/20/13 10:09, schrieb Anton Shterenlikht: > Oliver >=20 > I try to use FreeBSD for day-to-day numerical > work, as far as possible. I have to complement > it with linux cluster systems, largely due to > a range of compilers available there. >=20 > Anyway, keep me posted if you get anywhere with this. >=20 > Anton Hello Anton. The good German wine was talking yesterday, I guess. On PathScales EKOPath 4 website, FreeBSD and OpenSOLARIS are still mentioned and its HMPP, not OpenACC, that is used inline code. I have first to apologize for the depressive mood I spread around. It is EKOPath 5 BETA (webpage) that doesn't mention FreeBSD as supported platform - as one can easily see and watch at the intro page right bottom corner. The "community" of FreeBSD systems is decreasing from year to year and as David Chisnall reported in a reply on my posting, it seems to be a "mindshare" thing. Too many people are talking about "business" - business isn't the motivator, science is and this may be a special view of my country. BSD was developed at Berkeley in a very scientific manner and therefore it is a very strong "logical" system - apart from the crap Lnux started with. I think it is unwise to talk about philosphy at this moment. The fact is, that I'm the only one in my department that is using FreeBSD on two remaining servers (one is a small storage server) and my personal lab workstation - my private systems are all FreeBSD, but that is not the matter here. The equipment I bought when we had to spend money on the project's funding is quite "impressive" for a under the desk workstation - I guess. We also had the chance to purchase a Dell Precision 7500 workstation with a TESLA 2075 board and two 6-core Westmere CPUs at 2,6 GHz with 96 GB RAM - for modelling and rendering purposes (sometimes our scientific work in the planetology field requires to do PR for funding, so we render also ...). Having FreeBSD in the first place on that box everything worked quite well, since the drivers were applicable to the provided hardware, even the TESLA card was accepted by the nVidia BLOB. But that's it. We swapped to Suse Linux since the developer working on that system required OpenCL thriving the GPU for large DTM rendering. Our cluster system (Rocks) is pure Linux. We have a lot of Dell stuff around here, equipted with expensive iDRAC modules. They're supposed to get accessed via JAVA. From FreeBSD/Firefox, I can not start the console due to a JAVA error. Dell rejects support, since FreeBSD isn't supported. Yes, and this is the meaning of platform indepenedency ... It is also a political thing. Another thing, that seems unlogical is the MIT/BSD/CDDL versus GPLv3 licensing issue. FreeBSD, as the other *BSDs, are supposed to have the most "advanced" licensing model in terms of academic freedom and even for companies benefit from such a free licensing model. GPLv3 is curcified as the evil license and even companies which have an interest protecting their code should look at the BSD systems - but the fact is: Linux all over the place. What is wrong with this picture? The opinion shared within THIS community or a real blindness? Funding companies or professional developers for developing KMS, GEM and other stuff is one thing. Why is there no effort to fund students working on their Diploma Thesis or Dissertation with regards to develop methods, code or functionality to FreeBSD in a "wide and open manner", so that it can be used platform independend? It is just an idea and it is a question that the FreeBSD Foundation has to answer and to decide on.= The other very bad thing is the information I have to gather. Somehow I feel lost when looking for software for my work, even it is very popular. Gathering informations from many places - as it is with "WHICH PROFESSIONAL COMPILER WORKS ON FREEBSD WITH PROFESSIONAL HIGH PERFORMANCE MATH LIBS" is horrible and time consuming. try it on Google with the tag "Linux" makes you happy within seconds. And back to our case. For instance, meshalb is a very powerful tool used by many people working with point cloud data. Since more than half a year that port is broken on FreeBSD and that drove to scientists away from my FreeBSD installation to Linux - where is works perfectly - magically. Well, we have now devel/freeocl in the ports to provide a bit OpenCL stuff on FreeBSD - but on the CPU, not the GPU. My next attempt is to provide a port of devel/pocl, which isn't fit for FreeBSD in version 0.7 as there is a typo regarding amd64 and the x86_64 terminology, but those guys from Finnlandia are very, very nice and also PRO(!) freeBSd, so they told me that there is alsready a patch in the GIT. I haven't had the time to look at this since I'm consumed due to writing my thesis at the moment, but THERE IS STUFF of interest, but if it is a lonely-hunter-work only and the interest of the community is so low on such stuff even of the professional people hired to code for FreeBSD, then ... well, I lack in the necessary words. I'm too young to talk with the old guys from the great time of X11 (Leffler) or BSD (McKusick) and all the pioneer work done in that time, but the great spirit seems to be lost due to "companies" and this golden-valve-people attitude of money, money, money. Sorry about the last sentence, as i said, philosphie in a depressive mood can be devastating. Well ... regards, Oliver --------------enigBB5DB0F6429156B22412AB2A 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.19 (FreeBSD) iQEcBAEBAgAGBQJRJLEXAAoJEOgBcD7A/5N8mjEH/ReS2FRdFubGquV/IM/e7DYp bm+7QLok4+C/hqHzlkRauiTzbnIQo7QtuhBSBAwqqSqqIYOt/xK8G5q1AdzvdrGH 4EqZhCiolRTYtZYxsiDepq8lsDjodpjIVaH2F/tKv/xIBO6eZgA8g34VblWtRu9V Hjqw1bqySak8C8ES4uWKDnOMQXhGvc7xl0WIeAZPFVC5iAUsPNrn0F+qsIfrJJvm 3UKzUH5n48RJFvSzyrHLFBXwaJqpfzQGAFwcdiYBU5FH73JQvUEf+4PurKSu1V5M 3eJ4TgpFjFtE7JEWb3QlZfBepnW9RS50NjSh9qPONPjayDddRNWa9okSIhuHD2M= =Z9jA -----END PGP SIGNATURE----- --------------enigBB5DB0F6429156B22412AB2A-- From owner-freebsd-current@FreeBSD.ORG Wed Feb 20 12:28:30 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 5C1BB6EC for ; Wed, 20 Feb 2013 12:28:30 +0000 (UTC) (envelope-from simon@comsys.ntu-kpi.kiev.ua) Received: from comsys.kpi.ua (comsys.kpi.ua [77.47.192.42]) by mx1.freebsd.org (Postfix) with ESMTP id 16AAADF9 for ; Wed, 20 Feb 2013 12:28:29 +0000 (UTC) Received: from pm513-1.comsys.kpi.ua ([10.18.52.101] helo=pm513-1.comsys.ntu-kpi.kiev.ua) by comsys.kpi.ua with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1U88mg-0004JQ-2U; Wed, 20 Feb 2013 14:28:26 +0200 Received: by pm513-1.comsys.ntu-kpi.kiev.ua (Postfix, from userid 1001) id 8785F1E08A; Wed, 20 Feb 2013 14:28:26 +0200 (EET) Date: Wed, 20 Feb 2013 14:28:26 +0200 From: Andrey Simonenko To: Rick Macklem Subject: Re: Possible bug in NFSv4 with krb5p security? Message-ID: <20130220122826.GA13613@pm513-1.comsys.ntu-kpi.kiev.ua> References: <20130219102744.GA2426@pm513-1.comsys.ntu-kpi.kiev.ua> <747768617.3137250.1361325169865.JavaMail.root@erie.cs.uoguelph.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <747768617.3137250.1361325169865.JavaMail.root@erie.cs.uoguelph.ca> User-Agent: Mutt/1.5.21 (2010-09-15) X-Authenticated-User: simon@comsys.ntu-kpi.kiev.ua X-Authenticator: plain X-Sender-Verify: SUCCEEDED (sender exists & accepts mail) X-Exim-Version: 4.63 (build at 28-Apr-2011 07:11:12) X-Date: 2013-02-20 14:28:26 X-Connected-IP: 10.18.52.101:49381 X-Message-Linecount: 170 X-Body-Linecount: 153 X-Message-Size: 5301 X-Body-Size: 4473 Cc: freebsd-current@freebsd.org, Elias Martenson , Benjamin Kaduk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 20 Feb 2013 12:28:30 -0000 On Tue, Feb 19, 2013 at 08:52:49PM -0500, Rick Macklem wrote: > > > > I cannot find how to get information about maximum buffer size for > > the getpwnam_r() function. This information should be returned by > > sysconf(_SC_GETPW_R_SIZE_MAX), but since it does not work on FreeBSD > > it is necessary to guess its size. Original value is 128 and it works > > for somebody, 1024 works for your environment, but it can fail for > > another environment. > > > > SUSv4 specifies "Storage referenced by the structure is allocated from > > the memory provided with the buffer parameter", but then tells about > > groups > > in EXAMPLE for getpwnam_r() "Note that sysconf(_SC_GETPW_R_SIZE_MAX) > > may > > return -1 if there is no hard limit on the size of the buffer needed > > to > > store all the groups returned". > > > > malloc() can give overhead, but that function can try to call > > getpwnam_r() > > with buffer allocated from stack and if getpwnam_r() failed with > > ERANGE > > use dynamically allocated buffer. > > > > #define PWBUF_SIZE_INI (2 * MAXLOGNAME + 2 * MAXPATHLEN + > > _PASSWORD_LEN + 1) > > #define PWBUF_SIZE_INC 128 > > > > char bufs[2 * MAXLOGNAME + MAXPATHLEN + PASSWORD_LEN + 1 + 32]; > > > > error = getpwnam_r(lname, &pwd, bufs, sizeof(bufs), &pw); > > if (pw != NULL) { > > *uidp = pw->pw_uid; > > return (GSS_S_COMPLETE); > > } else if (error != ERANGE) > > return (GSS_S_FAILURE); > > > > size = PWBUF_SIZE_INI; > > for (;;) { > > size += PWBUF_SIZE_INC; > > buf = malloc(size); > > if (buf == NULL) > > return (GSS_S_FAILURE); > > error = getpwnam_r(lname, &pwd, buf, size, &pw); > > free(buf); > > if (pw != NULL) { > > *uidp = pw->pw_uid; > > return (GSS_S_COMPLETE); > > } else { > > if (error == ERANGE && > > size <= SIZE_MAX - PWBUF_SIZE_INC) > > continue; > > return (GSS_S_FAILURE); > > } > > } > > Just my opinion, but I think the above is a good approach. > (ie. First trying a fairly large buffer on the stack that > will succeed 99.99% of the time, but check for ERANGE and > loop trying progressively larger malloc'd buffers until > it stops reporting ERANGE.) > > I suspect the overheads behind getpwnam_r() are larger than > the difference between using a buffer on the stack vs malloc, > so I think it should use a fairly large buffer the first time. > > Personally, I might have coded it as a single do { } while(), > with the first attempt in it, but that's just personal stylistic > taste. (You can check for buf != bufs before doing a free() of it.) > And, if you wanted to be clever, the code could use a static "bufsiz_hint", > which is set to the largest size needed sofar and that is used as > the initial malloc size. That way it wouldn't loop as much for a > site with huge passwd entries. (An entire bio in the GECOS field or ???) > Thanks for the review. Another variant. This is a program that can be used for verifying correctness of the function, just change PWBUF_SIZE_* values and put some printfs to see when buffer is reallocated. sizehint is updated only when malloc() succeeded. --------------------------------- #include #include #include #include #include #include #include #include #include #include static int getpwnam_r_func(const char *name, uid_t *uidp) { #define PWBUF_SIZE_INI (2 * MAXLOGNAME + MAXPATHLEN + _PASSWORD_LEN) #define PWBUF_SIZE_INC 128 static size_t sizehint = PWBUF_SIZE_INI; struct passwd pwd; struct passwd *pw; char *buf; size_t size; int error; char lname[MAXLOGNAME]; char bufs[PWBUF_SIZE_INI]; strncpy(lname, name, sizeof(lname)); buf = bufs; size = sizeof(bufs); for (;;) { error = getpwnam_r(lname, &pwd, buf, size, &pw); if (buf != bufs) free(buf); if (pw != NULL) { *uidp = pw->pw_uid; return (GSS_S_COMPLETE); } else if (error != ERANGE || size > SIZE_MAX - PWBUF_SIZE_INC) return (GSS_S_FAILURE); if (size != sizehint) size = sizehint; else size += PWBUF_SIZE_INC; buf = malloc(size); if (buf == NULL) return (GSS_S_FAILURE); sizehint = size; } } int main(void) { const char *str[] = { "man", "root", "q", "bin", NULL }; uid_t uid; u_int i; for (i = 0; str[i] != NULL; ++i) { printf("%-20s\t", str[i]); if (getpwnam_r_func(str[i], &uid) == GSS_S_COMPLETE) printf("%u\n", uid); else printf("not found\n"); } return (0); } --------------------------------- From owner-freebsd-current@FreeBSD.ORG Wed Feb 20 12:31:10 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 7D2D482F for ; Wed, 20 Feb 2013 12:31:10 +0000 (UTC) (envelope-from onwahe@gmail.com) Received: from mail-qa0-f52.google.com (mail-qa0-f52.google.com [209.85.216.52]) by mx1.freebsd.org (Postfix) with ESMTP id 3AD5EE26 for ; Wed, 20 Feb 2013 12:31:09 +0000 (UTC) Received: by mail-qa0-f52.google.com with SMTP id bs12so2357759qab.18 for ; Wed, 20 Feb 2013 04:31:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=W2kel/G4N+35SEqvmEgnguyp4lirXsRVpp7WK72xUeo=; b=RV87rJldrpjZl5SWQF0zn+H9KQ3MflMyariXQSVpbjlxfpZKErSvgENhZ3sLDMo79y LOng/ILnHiHmV82MeZtklWX8nUG06rmQPBx4qeovima0FDkcCLyxpcFgpkTHVqJEGBmL jQNYDNsVRNjPCUuks2BlavCs/pTTyTHgul/9ndsQanF3oDxdD9cHnzjTj6qeRo1TsL5Q qZxpySFtPe4TH5mbwz0A8u3ROa6iup7LwjlPJOc8zY/pe/Qtk2kY6Zu4KLhi+E/b7axD qYgK4FZ3JcuZH7pjBETDeLKDKT9YUeH1TWB4CSBiupr8rJipBZkHqH0q7KCqMor19gz+ wneg== MIME-Version: 1.0 X-Received: by 10.49.118.138 with SMTP id km10mr9309492qeb.18.1361363468921; Wed, 20 Feb 2013 04:31:08 -0800 (PST) Received: by 10.49.121.198 with HTTP; Wed, 20 Feb 2013 04:31:08 -0800 (PST) In-Reply-To: <20130219185129.GC2598@kib.kiev.ua> References: <20130218150809.GG2598@kib.kiev.ua> <20130218170957.GJ2598@kib.kiev.ua> <20130218203630.GO2598@kib.kiev.ua> <20130219185129.GC2598@kib.kiev.ua> Date: Wed, 20 Feb 2013 13:31:08 +0100 Message-ID: Subject: Re: [patch] i386 pmap sysmaps_pcpu[] atomic access From: Svatopluk Kraus To: Konstantin Belousov Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 20 Feb 2013 12:31:10 -0000 On Tue, Feb 19, 2013 at 7:51 PM, Konstantin Belousov wrote: > On Mon, Feb 18, 2013 at 11:18:16PM +0100, Svatopluk Kraus wrote: >> On Mon, Feb 18, 2013 at 9:36 PM, Konstantin Belousov >> wrote: >> Well, I'm taking a part on porting FreeBSD to ARM11mpcore. UP case was >> simple. SMP case is more complex and rather new for me. Recently, I >> was solving a problem with PCPU stuff. For example, PCPU_GET is >> implemented by one instruction on i386 arch. So, a need of atomicity >> with respect to interrupts can be overlooked. On load-store archs, the >> implementation which works in SMP case is not so simple. And what >> works in UP case (single PCPU), not works in SMP case. Believe me, >> mysterious and sporadic 'mutex not owned' assertions and others ones >> caused by curthreads mess, it takes a while ... > Note that PCPU_GET() is not needed to be atomic. The reason is that the code > which uses its result would not be atomic (single-instruction or whatever, see > below). Thus, either the preemption should not matter since the action with > the per-cpu data is advisory, as is in the case of i386 pmap you noted. > or some external measures should be applied in advance to the containing > region (which you proposed, by bracing with sched_pin()). So, it's advisory in the case of i386 pmap... Well, if you can live with that, I can too. > > Also, note that it is not interrupts but preemption which is concern. Yes and no. In theory, yes, a preemption is a concern. In FreeBSD, however, sched_pin() and critical_enter() and their counterparts are implemented with help of curthread. And curthread definition falls to PCPU_GET(curthread) if not defined in other way. So, curthread should be atomic with respect to interrupts and in general, PCPU_GET() should be too. Note that spinlock_enter() definitions often (always) use curthread too. Anyhow, it's defined in MD code and can be defined for each arch separately. >> >> After this, I took a look at how PCPU stuff is used in whole kernel >> and found out mentioned here i386 pmap issue. So, my concern is >> following: >> >> 1. to verify my newly gained ideas how per CPU data should be used, >> 2. to decide how to change my implementation of pmap on ARM11mpcore, >> as it's based on i386 pmap, >> 3. to make FreeBSD code better. >> >> In the meanwhile, it looks that using data dedicated to one CPU on >> another one is OK. However, I can't agree. At least, without comments, >> it is misleading for anyone new in FreeBSD and makes code misty. >> >> > Both threads in your description make useful progress, and computation >> > proceeds correctly. >> >> I thought, there is only one thread in my example. One thread running >> on CPU1, but holding sysmaps dedicated to CPU0 instead of holding >> sysmaps dedicated to CPU1. So, any thread running on CPU0 must wait >> because the thread running on CPU1 is a thief. Futhermore, the idea >> that a thread on CPU1 should hold data for CPU1 is not valid. So, >> either some comment is missing in the code that it's OK or the using >> of PCPU_GET(cpuid) is unneeded and some kind of free sysmaps list can >> be used and it will serve better. > > What is wrong on almost all architectures except x86 is PCPU_ADD(), which > is usually supposed by the MD code to be atomic in regard to _both_ > interrupts and preemption. I said almost all, but in fact I am not aware > of any architecture except x86 where it is right. > > And, RISCs with the load-link and store-conditional (ll/sc) primitives > are well capable of doing the PCPU_ADD() correctly. > > You could look at the projects/counters branch, where single-instruction > increment is used on x86 for dynamic per-cpu counters, and critical_enter() > for other architectures. I might do some work for other arches, but the > counters are correct but slower that it could be, on !x86. Thanks to help me to settle my thoughts. Svata From owner-freebsd-current@FreeBSD.ORG Wed Feb 20 12:39:57 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id D5F36B7A for ; Wed, 20 Feb 2013 12:39:57 +0000 (UTC) (envelope-from vince@unsane.co.uk) Received: from unsane.co.uk (unsane-pt.tunnel.tserv5.lon1.ipv6.he.net [IPv6:2001:470:1f08:110::2]) by mx1.freebsd.org (Postfix) with ESMTP id 46AEBEDE for ; Wed, 20 Feb 2013 12:39:57 +0000 (UTC) Received: from vhoffman.lon.namesco.net (lon.namesco.net [195.7.254.102]) (authenticated bits=0) by unsane.co.uk (8.14.6/8.14.6) with ESMTP id r1KCdnBK099671 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 20 Feb 2013 12:39:51 GMT (envelope-from vince@unsane.co.uk) Message-ID: <5124C414.6040708@unsane.co.uk> Date: Wed, 20 Feb 2013 12:39:48 +0000 From: Vincent Hoffman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: mexas@bristol.ac.uk Subject: Re: daily otput: rejected mail hosts? References: <201302201109.r1KB9E89062500@mech-cluster241.men.bris.ac.uk> In-Reply-To: <201302201109.r1KB9E89062500@mech-cluster241.men.bris.ac.uk> X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 20 Feb 2013 12:39:58 -0000 On 20/02/2013 11:09, Anton Shterenlikht wrote: > From mexas Thu Feb 14 09:51:50 2013 > To: freebsd-questions@freebsd.org > Subject: daily otput: rejected mail hosts? > Reply-To: mexas@bristol.ac.uk > > I see in the daily output: > > Checking for rejected mail hosts: > 172 553 check_mail system.mail exist > 129 553 check_mail tsvpt014.vpt.co.uk exist > 43 553 check_mail unix.dedicated.com.tr exist > 43 553 check_mail ubs.net exist > 43 553 check_mail localhost.localdomain exist > 43 553 check_mail journal-cfp.org exist > 43 553 check_mail italiasito.it exist > > What is that about? > > Is this described somewhere in sendmail manuals? > > I got no reply from questions@, so trying my luck here. questions@ is a better place to ask really as this isnt -CURRENT related, its part of the output of the daily periodic script /etc/periodic/daily/460.status-mail-rejects which is enabled by default. the defaults are in /etc/defaults/periodic.conf feel free to overide them in /etc/periodic.conf Vince > > Thanks > > Anton > _______________________________________________ > 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 Wed Feb 20 14:36:25 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 99C7B100 for ; Wed, 20 Feb 2013 14:36:25 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id 5DCF883B for ; Wed, 20 Feb 2013 14:36:25 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) for freebsd-current@FreeBSD.org with esmtp (envelope-from ) id <1U8AmW-002QtQ-7p>; Wed, 20 Feb 2013 15:36:24 +0100 Received: from e178035155.adsl.alicedsl.de ([85.178.35.155] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.69) for freebsd-current@FreeBSD.org with esmtpsa (envelope-from ) id <1U8AmW-003mtq-4a>; Wed, 20 Feb 2013 15:36:24 +0100 Message-ID: <5124DF62.4010900@zedat.fu-berlin.de> Date: Wed, 20 Feb 2013 15:36:18 +0100 From: "O. Hartmann" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130131 Thunderbird/17.0.2 MIME-Version: 1.0 To: Current FreeBSD Subject: Revision: 247040: kernel crashes with funny blinking characters on console on Ivy-Bridge CPUs X-Enigmail-Version: 1.4.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigD1E1ED4B42B4CF41F1361FF5" X-Originating-IP: 85.178.35.155 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 20 Feb 2013 14:36:25 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigD1E1ED4B42B4CF41F1361FF5 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable Compiling most recent sources of CURRENT with Revision: 247040 results in a kernel crash with funny blinking characters on the screen. This happens on all systems with different amd64 Intel CPU generations at this very moment. Last working sources (reverting and booting kernel.old) is in my case FreeBSD 10.0-CURRENT #0 r246949: Mon Feb 18 22:18:42 CET 2013 Does anyone also experience this? Another remote experimental box, equipted with a Intel Q6600 CPU, is crashed, I have to investigate this when I get to the lab later. It seems not to be related only to Sandy-Bridge-E/Ivy-Bridge CPUs. Regards, Oliver --------------enigD1E1ED4B42B4CF41F1361FF5 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.19 (FreeBSD) iQEcBAEBAgAGBQJRJN9nAAoJEOgBcD7A/5N81ZoH/2lS0r/JUSBufTzK2+WoXB9u 9KUAoHEfhL/RGs3WNS5W6u4DdzvxuvJ4XwWtIBjqdy5XSHLvkUWw7pxHikc9VklJ jW++hhw9OyPxGNdPFJ9j0q3fmzGbvQuX0+Mo0++ms+ckAnPasNZRaDS3F+A37ApN y7/SJd6/1dTkNHfsrokx7QBO8S1ug17PXH95Io/6qP8KLIsX8D2gfcO7ckFVGEHP CY9sC9XcelG6q0qpa06zo1EU5dokYUZc/Vy1dXzhUyh/IDKkNsFBi0mfRMaebRe5 hcrBajx7ErInBLVP9MoM4atEXQM1aDPvQcb9FP23TYhfcym/pOc8jy2CmvQDUP8= =byrJ -----END PGP SIGNATURE----- --------------enigD1E1ED4B42B4CF41F1361FF5-- From owner-freebsd-current@FreeBSD.ORG Wed Feb 20 14:37:31 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 30B3D223; Wed, 20 Feb 2013 14:37:31 +0000 (UTC) (envelope-from freebsd@psconsult.nl) Received: from mx1.psconsult.nl (unknown [IPv6:2001:7b8:30f:e0::5059:ee8a]) by mx1.freebsd.org (Postfix) with ESMTP id C276985D; Wed, 20 Feb 2013 14:37:30 +0000 (UTC) Received: from mx1.psconsult.nl (mx1.hvnu.psconsult.nl [46.44.189.154]) by mx1.psconsult.nl (8.14.5/8.14.4) with ESMTP id r1KEbKCS004758 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 20 Feb 2013 15:37:25 +0100 (CET) (envelope-from freebsd@psconsult.nl) Received: (from paul@localhost) by mx1.psconsult.nl (8.14.5/8.14.4/Submit) id r1KEbKGU004757; Wed, 20 Feb 2013 15:37:20 +0100 (CET) (envelope-from freebsd@psconsult.nl) X-Authentication-Warning: mx1.psconsult.nl: paul set sender to freebsd@psconsult.nl using -f Date: Wed, 20 Feb 2013 15:37:20 +0100 From: Paul Schenkeveld To: "Constantine A. Murenin" Subject: Re: announcing mdoc.su, short manual page URLs Message-ID: <20130220143720.GA4368@psconsult.nl> References: <20130219082700.GA9938@Cns.Cns.SU> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130219082700.GA9938@Cns.Cns.SU> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-doc@freebsd.org, freebsd-current@freebsd.org, freebsd-chat@freebsd.org, Darren Pilgrim X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 20 Feb 2013 14:37:31 -0000 On Tue, Feb 19, 2013 at 12:27:01AM -0800, Constantine A. Murenin wrote: > Dear freebsd-{chat,current,doc}@, > > I would like to announce and introduce , > a deterministic URL shortener for BSD manual pages, > written entirely in nginx.conf. > > It supports several address schemes, for example: > > http://mdoc.su/f/zfs > http://mdoc.su/f/zfs.8 > http://mdoc.su/f/8/zfs > http://mdoc.su/freebsd/zfs > http://mdoc.su/FreeBSD/zfs > > http://mdoc.su/d/hammer.5 > http://mdoc.su/d/hammer.8 > > etc. Very coooool! One question: is the os version accessible comewhere, i.e. can I ask for a manpage from a specific version of FreeBSD? I have to disagree with Darren Pilgrim however, this is not "slight abuse" of rewrite rules but putting rewrite rules to "better use" :-) Kind regards, Paul Schenkeveld From owner-freebsd-current@FreeBSD.ORG Wed Feb 20 15:05:45 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id E96D6AD8 for ; Wed, 20 Feb 2013 15:05:45 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id 9BDB49BF for ; Wed, 20 Feb 2013 15:05:45 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) for freebsd-current@FreeBSD.org with esmtp (envelope-from ) id <1U8BEu-002dOG-KR>; Wed, 20 Feb 2013 16:05:44 +0100 Received: from e178035155.adsl.alicedsl.de ([85.178.35.155] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.69) for freebsd-current@FreeBSD.org with esmtpsa (envelope-from ) id <1U8BEu-003p7e-Gm>; Wed, 20 Feb 2013 16:05:44 +0100 Message-ID: <5124E646.3060304@zedat.fu-berlin.de> Date: Wed, 20 Feb 2013 16:05:42 +0100 From: "O. Hartmann" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130131 Thunderbird/17.0.2 MIME-Version: 1.0 To: Current FreeBSD Subject: No ZFS when loading modules from loeader prompt X-Enigmail-Version: 1.4.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig93FAB683908F0A28C25215C3" X-Originating-IP: 85.178.35.155 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 20 Feb 2013 15:05:46 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig93FAB683908F0A28C25215C3 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable At the moment, the most recent kernel of FreeBSD 10.0-CURRENT crashes on all of the boxes I compiled the most recent kernel sources (build a world ncluding kernel, not only the kernel, so the system is "consistent"= ). At the loader prompt, I need to unload the buggy kernel and load the old working one via load /boot/kernel.old/kernel Then I load also the ZFS related modules load /boot/kernel.old/opensolaris.ko load /boot/kernel.old/zfs.ko Issuing boot at the end of that stage boots the kernel - the old one -successfully - but there is no working ZFS and no ZFS volume gets mounted although the rc.conf is executed correctly. What am I doing wrong at that point? Why isn't ZFS run and mount properly= ? Luckily, just booting the old kernel via load /boot/kernel.old/kernel and booting it having zfs_enable=3D"YES" in /etc/rc.conf set loads the /boot/kernel/opensolaris/zfs stuff - usually those kernel modules are out of sync compared to kernel.old but in this case its just a coincidence that this works. So, what is the proper way to have ZFS mounted in an emergency case when I'm in need of loading a working kernel manually? Regards, Oliver --------------enig93FAB683908F0A28C25215C3 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.19 (FreeBSD) iQEcBAEBAgAGBQJRJOZHAAoJEOgBcD7A/5N85l0H/3OWpgzH+8YR9nHrXBTJnxq+ LNnhXomK0c+cNeBKrfnTAJppMmbk3g9vjPvweB83q4Lm4kcr2qKFZ7fKtqSgrFAi NtoMS8z47GFaK2+SsC7O3Y/GzSnnoFK7NrjbYKzqLpgBGEda/38qboP+SYkS2VWM gjH1DFuE6QicQTE8X+RvstCeb0HqDU94WbgNCSJV6ywZiYzdm1B4EPici8t/Rxsh S9BEYeRSLci9L9M8p9TVXzv1ZvCYx2CESR+Z5HAqB+ooMkY0ek1Z0MjFH9H1QpuI Vd4/r5m/dthCYeunvIqns0EdfEhCHWoOul28lwnS+kUpjfIYxh5XQYB04Mo5w90= =lHzk -----END PGP SIGNATURE----- --------------enig93FAB683908F0A28C25215C3-- From owner-freebsd-current@FreeBSD.ORG Wed Feb 20 15:32:35 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id D10116C3; Wed, 20 Feb 2013 15:32:35 +0000 (UTC) (envelope-from davide.italiano@gmail.com) Received: from mail-vc0-f179.google.com (mail-vc0-f179.google.com [209.85.220.179]) by mx1.freebsd.org (Postfix) with ESMTP id 6EA0FB5F; Wed, 20 Feb 2013 15:32:35 +0000 (UTC) Received: by mail-vc0-f179.google.com with SMTP id gb23so5178461vcb.10 for ; Wed, 20 Feb 2013 07:32:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=woegzMZYJQzSVjt0OQClKq9gQwYINPohBMAN52QPbDk=; b=almf3f/eRolRTndHfdo+I+JxjtuT/kt7xq8cHzKRpU9tIIDoXZVIcz1Z7mZOxmPmAt yIN80Jw7fufiwLCCFg4BZES2sjPwa5CXiM2tOnv/NU9VH9NuvRG3qDFv21qsf1zkzyMv gQcpp/1tQvBoAFyzuOUgies7PnzPbqwlT8sJg/cq6SujNLEZOc/DDXJWqeTjt+HAyZw7 XsWtYa1/mYCdPUq2NbBqIr+BuuOzFu66wk3DRThJRjNJiAoDVQkeegXUJen4DjxgpdVq UnUSc9Yi3v0mhHrISJ/ogVqZoo8pcL4fEnd48FXlS4ig9sC9EO3oNKqEQsIyW0TR+2Y4 hZTQ== MIME-Version: 1.0 X-Received: by 10.220.220.6 with SMTP id hw6mr1408845vcb.59.1361374016168; Wed, 20 Feb 2013 07:26:56 -0800 (PST) Sender: davide.italiano@gmail.com Received: by 10.220.34.203 with HTTP; Wed, 20 Feb 2013 07:26:56 -0800 (PST) In-Reply-To: <86ip5nxqbw.fsf@ds4.des.no> References: <86ip5nxqbw.fsf@ds4.des.no> Date: Wed, 20 Feb 2013 16:26:56 +0100 X-Google-Sender-Auth: k3Ju7hipbI9hhsOHO1TX6HKdq9M Message-ID: Subject: Re: r246916 probably broke amd64 build From: Davide Italiano To: =?ISO-8859-1?Q?Dag=2DErling_Sm=F8rgrav?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "Simon L. B. Nielsen" , freebsd-current , mav@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 20 Feb 2013 15:32:35 -0000 On Wed, Feb 20, 2013 at 10:54 AM, Dag-Erling Sm=F8rgrav wrote: > Davide Italiano writes: >> Unfortunately tinderbox didn't catch this bug because it's triggered >> only when gcc is used to build kernel. > > In this particular case, the broken code is only built on platforms > which default to clang. Otherwise, it would have been caught when > building one of the platforms that default to gcc. > I see. In fact this was a very unlucky case (problem in MD code, for a platform that default to clang). > The tinderbox servers simply donn't have enough CPU power to build all > possible combinations. There isn't even enough for a standard build of > all platforms at a reasonable frequency. I have a stack of new servers, > but nowhere to host them - see the donations wantlist for details. > > DES > -- > Dag-Erling Sm=F8rgrav - des@des.no Sorry I can't help you with that. Thanks, Davide From owner-freebsd-current@FreeBSD.ORG Wed Feb 20 15:43:58 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 65F1ACA2; Wed, 20 Feb 2013 15:43:58 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-bk0-f46.google.com (mail-bk0-f46.google.com [209.85.214.46]) by mx1.freebsd.org (Postfix) with ESMTP id C59B6CF7; Wed, 20 Feb 2013 15:43:57 +0000 (UTC) Received: by mail-bk0-f46.google.com with SMTP id j5so3639114bkw.5 for ; Wed, 20 Feb 2013 07:43:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=KG9DDG7SQOfaMfoJ47hcAvxzicRmQqgC4KgC72aiq/8=; b=FFiynGpNAnZ3KyD38VtQOrgSGVgzwby4HZG6gbtU8SjmD8reElj8sf5k8nZSiL16dB ldnKfep3RM4qyD0IUiRhnrIXNkTsj3E7v8rR91BqP0bP8H2pebdkzFUOPPgRcmX7mher ASUjzFBX2ie5iOVptA/ecp0iYGwmnXdqreyvsD5Gq/JoSHlgBxSDMCTle0CVFRn/5tF2 u6MC13G2X6sOmzmpX71ZO4+tL+xTHGu5M5NGOR6fG9GsBiwDJY36Z0alrGowkkbQ6qSJ IDF8YyjEpKLdf8Ni2ZdBBOZdcL8h7gv9VQ7t6PyPb6vtF8wlktq3dccxWRqLwSnDlWeo VwBQ== X-Received: by 10.205.122.80 with SMTP id gf16mr8835541bkc.130.1361375036615; Wed, 20 Feb 2013 07:43:56 -0800 (PST) Received: from mavbook.mavhome.dp.ua (mavhome.mavhome.dp.ua. [213.227.240.37]) by mx.google.com with ESMTPS id k4sm23510787bkv.18.2013.02.20.07.43.54 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 20 Feb 2013 07:43:55 -0800 (PST) Sender: Alexander Motin Message-ID: <5124EF38.7080302@FreeBSD.org> Date: Wed, 20 Feb 2013 17:43:52 +0200 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130125 Thunderbird/17.0.2 MIME-Version: 1.0 To: Joel Dahl Subject: Re: HEAD memsticks broken? [USB/CAM Problems?] References: <20130209073241.GN21730@jd.benders.se> <20130209230939.GQ21730@jd.benders.se> <20130211222105.GC838@jd.benders.se> <201302120851.18810.hselasky@c2i.net> <20130214193707.GD84888@jd.benders.se> <20130216100719.GB47553@jd.benders.se> In-Reply-To: <20130216100719.GB47553@jd.benders.se> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, Hans Petter Selasky X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 20 Feb 2013 15:43:58 -0000 On 16.02.2013 12:07, Joel Dahl wrote: > On 14-02-2013 20:37, Joel Dahl wrote: >> On 12-02-2013 8:51, Hans Petter Selasky wrote: >>> On Monday 11 February 2013 23:21:05 Joel Dahl wrote: >>>> On 10-02-2013 0:09, Joel Dahl wrote: >>>>> On 09-02-2013 20:28, Alexander Motin wrote: >>>>>> How long ago that HEAD was built? Could you get full dmesg? I don't >>>>>> think that "PREVENT ALLOW MEDIUM REMOVAL" should cause device drop. "No >>>>>> sense data present" also doesn't look right. >>>>> >>>>> As I mentioned earlier, I've tried several HEAD snapshots. >>>> >>>> Just a quick update on this: I've built quite a few releases now and >>>> managed to track down the problem to somewhere between r235789 and >>>> r237855. It'll probably take me another day or two before I know which >>>> commit actually broke it. >>> >>> Hi, >>> >>> I don't see any relevant USB+UMASS patches for your issue in this interval, >>> but many patches in the SCSI/CAM area. >> >> I finally found it. A r237477 memstick boots fine. A r237478 memstick does not. >> >> 237478 is the following commit by mav@: >> >> ------------------------------------------------------------------------ >> r237478 | mav | 2012-06-23 14:32:53 +0200 (Sat, 23 Jun 2012) | 3 lines >> >> Add scsi_extract_sense_ccb() -- wrapper around scsi_extract_sense_len(). >> It allows to remove number of duplicate checks from several places. >> >> ------------------------------------------------------------------------ > > So, mav@ haven't replied yet so I did some more investigation. I collected > all the USB sticks I had in the office (5 in total, all Kingston but different > size and models) and tried a memstick installation with each stick. Turns out > r237478 only breaks memstick installation in combination with certain USB > sticks: > > # Works: > > da0: Removable Direct Access SCSI-2 device > da0: 40.000MB/s transfers > da0: 7664MB (15695872 512 byte sectors: 255H 63S/T 977C) > > da0: Removable Direct Access SCSI-0 device > da0: 40.000MB/s transfers > da0: 1906MB (3903488 512 byte sectors: 255H 63S/T 242C) > > # Does not work: > > da0: Removable Direct Access SCSI-2 device > da0: 40.000MB/s transfers > da0: 15295MB (31324160 512 byte sectors: 255H 63S/T 1949C) > > da0: Removable Direct Access SCSI-0 device > da0: 40.000MB/s transfers > da0: 3690MB (7557704 512 byte sectors: 255H 63S/T 470C) > > da0: Removable Direct Access SCSI-2 device > da0: 40.000MB/s transfers > da0: 1905MB (3903264 512 byte sectors: 255H 63S/T 242C) > > It seems that only USB sticks labeled as "Kingston DataTraveler G3" > are affected by r237478 (in my limited testing, at least). This particular > model is what you get if you buy the cheapest Kingston model on the market > right now. I've reviewed that change once more and I see no flaws in it. My only guess is that it changes something innocent or unrelated in request order that confuses flash firmware, making it stuck and return errors without SCSI sense information. In log provided I see that when device first detected, it normally reports its size. But later, possibly after some command (SYNCHRONIZE CACHE?, PREVENT ALLOW MEDIUM REMOVAL?), it starts to behave wrong. Wrong answer to another READ CAPACITY request causes "got CAM status 0xXX" message and following device loss. Unfortunately I can't reproduce the problem. All USB sticks I have are working fine without any problems with HEAD system. If I could, I would try to log all commands sent to the stick to find one after which problem begins. Commands could be logged either on CAM layer by running `camcontrol debug -IPpc all` before plugging stick in and `camcontrol debug off` after (you may want to do it in single-user mode or without syslog running to avoid logging activity on other CAM disks), or probably somehow on umass layer, or with usbdump on raw USB layer (in last case some more knowledge will be needed to interpret result). -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Wed Feb 20 15:49:23 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id C9540248 for ; Wed, 20 Feb 2013 15:49:23 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id A3125D86 for ; Wed, 20 Feb 2013 15:49:23 +0000 (UTC) Received: from pakbsde14.localnet (unknown [38.105.238.108]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 289AEB95B; Wed, 20 Feb 2013 10:49:23 -0500 (EST) From: John Baldwin To: freebsd-current@freebsd.org Subject: Re: [patch] i386 pmap sysmaps_pcpu[] atomic access Date: Wed, 20 Feb 2013 10:22:29 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p25; KDE/4.5.5; amd64; ; ) References: <20130219185129.GC2598@kib.kiev.ua> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201302201022.29294.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 20 Feb 2013 10:49:23 -0500 (EST) Cc: Konstantin Belousov , Svatopluk Kraus X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 20 Feb 2013 15:49:23 -0000 On Wednesday, February 20, 2013 7:31:08 am Svatopluk Kraus wrote: > On Tue, Feb 19, 2013 at 7:51 PM, Konstantin Belousov > wrote: > > On Mon, Feb 18, 2013 at 11:18:16PM +0100, Svatopluk Kraus wrote: > >> On Mon, Feb 18, 2013 at 9:36 PM, Konstantin Belousov > >> wrote: > >> Well, I'm taking a part on porting FreeBSD to ARM11mpcore. UP case was > >> simple. SMP case is more complex and rather new for me. Recently, I > >> was solving a problem with PCPU stuff. For example, PCPU_GET is > >> implemented by one instruction on i386 arch. So, a need of atomicity > >> with respect to interrupts can be overlooked. On load-store archs, the > >> implementation which works in SMP case is not so simple. And what > >> works in UP case (single PCPU), not works in SMP case. Believe me, > >> mysterious and sporadic 'mutex not owned' assertions and others ones > >> caused by curthreads mess, it takes a while ... > > Note that PCPU_GET() is not needed to be atomic. The reason is that the code > > which uses its result would not be atomic (single-instruction or whatever, see > > below). Thus, either the preemption should not matter since the action with > > the per-cpu data is advisory, as is in the case of i386 pmap you noted. > > or some external measures should be applied in advance to the containing > > region (which you proposed, by bracing with sched_pin()). > > So, it's advisory in the case of i386 pmap... Well, if you can live > with that, I can too. > > > > > Also, note that it is not interrupts but preemption which is concern. > > Yes and no. In theory, yes, a preemption is a concern. In FreeBSD, > however, sched_pin() and critical_enter() and their counterparts are > implemented with help of curthread. And curthread definition falls to > PCPU_GET(curthread) if not defined in other way. So, curthread should > be atomic with respect to interrupts and in general, PCPU_GET() should > be too. Note that spinlock_enter() definitions often (always) use > curthread too. Anyhow, it's defined in MD code and can be defined for > each arch separately. curthread is a bit magic. :) If you perform a context switch during an interrupt (which will change 'curthread') you also change your register state. When you resume, the register state is also restored. This means that while something like 'PCPU_GET(cpuid)' might be stale after you read it, 'curthread' never is. However, it is true that actually reading curthread has to be atomic. If your read of curthread looks like: mov , r0 add , r0 ld r0, r1 Then that will indeed break. Alpha used a fixed register for 'pcpu_reg' (as does ia64 IIRC). OTOH, you might also be able to depend on the fact that pc_curthread is the first thing in 'struct pcpu' (and always will be, you could add a CTASSERT to future-proof). In that case, you can remove the 'add' instruction and instead just do: ld , r1 which is fine. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Wed Feb 20 16:17:47 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 42F17CA6 for ; Wed, 20 Feb 2013 16:17:47 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-qa0-f42.google.com (mail-qa0-f42.google.com [209.85.216.42]) by mx1.freebsd.org (Postfix) with ESMTP id 029D4EFA for ; Wed, 20 Feb 2013 16:17:46 +0000 (UTC) Received: by mail-qa0-f42.google.com with SMTP id cr7so2492962qab.15 for ; Wed, 20 Feb 2013 08:17:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=SBniiXiv0h9ogd9ac10alTP+O3O+P0OBI95XmKRb3dA=; b=kJsnhMSz6kjfgJwzpoAGvsVpv5KCM6CHhzIn+P8w2bt8+179zotiSlvFMCWXvWKc+u j+EdvJIRH5WneqhzSlflmKB/kYpQqdItOFXkLPgjbV0j42z22g8zbNqXmkKSlYseuCom kHf30q0SQamgyXUcLv5MXZXVA4l5qkjofCNR6m0uxthMbr6eUzGm0Anav1PKUSbfNr1s uSYLYBRrbOvDhR2u1T7d/gbRdAce6peMNZBBPcLloXMyslzamfDdQqwb2njX1r0hRvhU g+fvwFySdozu+dghLf0ZU9gy514AMcrwUL8lsShOf6WWFg1EBC8a31H0EqGBCWrGenA1 inhQ== MIME-Version: 1.0 X-Received: by 10.49.108.9 with SMTP id hg9mr9788090qeb.34.1361377066230; Wed, 20 Feb 2013 08:17:46 -0800 (PST) Received: by 10.49.106.233 with HTTP; Wed, 20 Feb 2013 08:17:46 -0800 (PST) In-Reply-To: <5124E646.3060304@zedat.fu-berlin.de> References: <5124E646.3060304@zedat.fu-berlin.de> Date: Wed, 20 Feb 2013 08:17:46 -0800 Message-ID: Subject: Re: No ZFS when loading modules from loeader prompt From: Freddie Cash To: "O. Hartmann" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Current FreeBSD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 20 Feb 2013 16:17:47 -0000 Sounds like a perfect use case for Boot Environments. Create a new BE, install the new kernel into it, set it as the default, reboot. If it fails, you manually set the previous BE as the default, and reboot. That way, your "known-good", working environment is never affected. beadm should be part of 10-CURRENT. If not, there should be a port for it. On Wed, Feb 20, 2013 at 7:05 AM, O. Hartmann wrote: > At the moment, the most recent kernel of FreeBSD 10.0-CURRENT crashes on > all of the boxes I compiled the most recent kernel sources (build a > world ncluding kernel, not only the kernel, so the system is "consistent"). > > At the loader prompt, I need to unload the buggy kernel and load the old > working one via > > load /boot/kernel.old/kernel > > Then I load also the ZFS related modules > > load /boot/kernel.old/opensolaris.ko > load /boot/kernel.old/zfs.ko > > Issuing boot at the end of that stage boots the kernel - the old one > -successfully - but there is no working ZFS and no ZFS volume gets > mounted although the rc.conf is executed correctly. > > What am I doing wrong at that point? Why isn't ZFS run and mount properly? > > Luckily, just booting the old kernel via load /boot/kernel.old/kernel > and booting it having zfs_enable="YES" in /etc/rc.conf set loads the > /boot/kernel/opensolaris/zfs stuff - usually those kernel modules are > out of sync compared to kernel.old but in this case its just a > coincidence that this works. > > So, what is the proper way to have ZFS mounted in an emergency case when > I'm in need of loading a working kernel manually? > > Regards, > Oliver > > -- Freddie Cash fjwcash@gmail.com From owner-freebsd-current@FreeBSD.ORG Wed Feb 20 17:18:00 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 81ACFC6 for ; Wed, 20 Feb 2013 17:18:00 +0000 (UTC) (envelope-from cvs-src@yandex.ru) Received: from forward11.mail.yandex.net (forward11.mail.yandex.net [IPv6:2a02:6b8:0:801::1]) by mx1.freebsd.org (Postfix) with ESMTP id 367642C4 for ; Wed, 20 Feb 2013 17:18:00 +0000 (UTC) Received: from smtp14.mail.yandex.net (smtp14.mail.yandex.net [95.108.131.192]) by forward11.mail.yandex.net (Yandex) with ESMTP id AFB09E816AD; Wed, 20 Feb 2013 21:17:57 +0400 (MSK) Received: from smtp14.mail.yandex.net (localhost [127.0.0.1]) by smtp14.mail.yandex.net (Yandex) with ESMTP id 858271B60769; Wed, 20 Feb 2013 21:17:57 +0400 (MSK) Received: from unknown (unknown [178.76.224.133]) by smtp14.mail.yandex.net (nwsmtp/Yandex) with ESMTP id Hu5qrGiN-Hu5esEFH; Wed, 20 Feb 2013 21:17:57 +0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1361380677; bh=l2hlOJzaqvd2/e+3KE1MQlwoqWzI0YCNzC7+zb1yRHk=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=pWwqsFmMO4PQrpAQRcJ2eAVuE5Fh17yu/ajl2gR6aWOFvJm2t1A5Sp5wk4AYz0u9c xsQoRe0Yxa7uV2SF/5LqoZj5jcrWA7sL1oVcjBZZvlRYpfgRAK4vt/ZqHy9dbzqUgy M0s6yBZBJgOxrwnMJPviz7TMfkgnV9cc4Qx1QCg0= Message-ID: <5125051C.7000909@yandex.ru> Date: Wed, 20 Feb 2013 21:17:16 +0400 From: Ruslan Makhmatkhanov User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130211 Thunderbird/17.0.2 MIME-Version: 1.0 To: "O. Hartmann" Subject: Re: Revision: 247040: kernel crashes with funny blinking characters on console on Ivy-Bridge CPUs References: <5124DF62.4010900@zedat.fu-berlin.de> In-Reply-To: <5124DF62.4010900@zedat.fu-berlin.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Current FreeBSD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 20 Feb 2013 17:18:00 -0000 O. Hartmann wrote on 20.02.2013 18:36: > Compiling most recent sources of CURRENT with Revision: 247040 results > in a kernel crash with funny blinking characters on the screen. This > happens on all systems with different amd64 Intel CPU generations at > this very moment. > > Last working sources (reverting and booting kernel.old) is in my case > > > FreeBSD 10.0-CURRENT #0 r246949: Mon Feb 18 22:18:42 CET 2013 > > > Does anyone also experience this? > > Another remote experimental box, equipted with a Intel Q6600 CPU, is > crashed, I have to investigate this when I get to the lab later. It > seems not to be related only to Sandy-Bridge-E/Ivy-Bridge CPUs. > > > Regards, > Oliver I just updated from r246618 to r247044 (kernel only, built with old world) and everything works as expected. I have: CPU: Intel(R) Core(TM) i5-2430M CPU @ 2.40GHz (2394.62-MHz K8-class CPU) I may build new world and build new kernel with it if it's may help to reproduce. -- Regards, Ruslan Tinderboxing kills... the drives. From owner-freebsd-current@FreeBSD.ORG Wed Feb 20 17:19:24 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 42D58291 for ; Wed, 20 Feb 2013 17:19:24 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-wi0-f181.google.com (mail-wi0-f181.google.com [209.85.212.181]) by mx1.freebsd.org (Postfix) with ESMTP id D75AC2F7 for ; Wed, 20 Feb 2013 17:19:23 +0000 (UTC) Received: by mail-wi0-f181.google.com with SMTP id hm6so6524893wib.8 for ; Wed, 20 Feb 2013 09:19:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=5GztlotZxvRZoEk+EiY8GXyfrv2UL9kjA+Dhxbrmsb8=; b=wO6A4qAwQVKMC2MWOPQdL6BUxTA0VVzT9W7CtYnlHcVLEVVmHTMXclc4xuBrXhWCYj ZhN/JEGgv5E6AOB8sxh7djthPSmYe4AOkFgr4lqYPDOyJtFV7VJ4oVhhoVIsak+akEfr rcsbXgbzzTK6njdfmfRmiDRjt6ZUcHbwPEPGC8nxmu7Xjf+LW52ZRG/YXHi35hGlApkl mJubnpiHgQo54JxqNTyiEJc4Fm8my6xslJfmcZyObiAruWKs4E6yEsIv2uQN9aFhnJMV 8OjGy9e48TRi5/OquYPRpkwBXaeyHV0qm5HZnQOZySoeRl0S46SyU1PPKpBr58nOmRMk YcGA== MIME-Version: 1.0 X-Received: by 10.194.242.69 with SMTP id wo5mr35477115wjc.10.1361380757603; Wed, 20 Feb 2013 09:19:17 -0800 (PST) Received: by 10.194.86.167 with HTTP; Wed, 20 Feb 2013 09:19:17 -0800 (PST) Date: Wed, 20 Feb 2013 20:19:17 +0300 Message-ID: Subject: [patch] remove negative socklen_t checks From: Sergey Kandaurov To: FreeBSD Current Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 20 Feb 2013 17:19:24 -0000 Hi. These checks are useless after the address length argument is converted to socklen_t (up to SUSv2). Any objections? Index: lib/libc/sys/accept.2 =================================================================== --- lib/libc/sys/accept.2 (revision 245745) +++ lib/libc/sys/accept.2 (working copy) @@ -28,7 +28,7 @@ .\" @(#)accept.2 8.2 (Berkeley) 12/11/93 .\" $FreeBSD$ .\" -.Dd December 11, 1993 +.Dd February 20, 2013 .Dt ACCEPT 2 .Os .Sh NAME @@ -154,10 +154,6 @@ The descriptor references a file, not a socket. .It Bq Er EINVAL .Xr listen 2 has not been called on the socket descriptor. -.It Bq Er EINVAL -The -.Fa addrlen -argument is negative. .It Bq Er EFAULT The .Fa addr Index: sys/kern/uipc_syscalls.c =================================================================== --- sys/kern/uipc_syscalls.c (revision 246354) +++ sys/kern/uipc_syscalls.c (working copy) @@ -353,8 +353,6 @@ kern_accept(struct thread *td, int s, struct socka if (name) { *name = NULL; - if (*namelen < 0) - return (EINVAL); } AUDIT_ARG_FD(s); @@ -1327,8 +1325,6 @@ kern_setsockopt(td, s, level, name, val, valseg, v if (val == NULL && valsize != 0) return (EFAULT); - if ((int)valsize < 0) - return (EINVAL); sopt.sopt_dir = SOPT_SET; sopt.sopt_level = level; @@ -1406,8 +1402,6 @@ kern_getsockopt(td, s, level, name, val, valseg, v if (val == NULL) *valsize = 0; - if ((int)*valsize < 0) - return (EINVAL); sopt.sopt_dir = SOPT_GET; sopt.sopt_level = level; @@ -1484,9 +1478,6 @@ kern_getsockname(struct thread *td, int fd, struct socklen_t len; int error; - if (*alen < 0) - return (EINVAL); - AUDIT_ARG_FD(fd); error = getsock_cap(td->td_proc->p_fd, fd, CAP_GETSOCKNAME, &fp, NULL); if (error) @@ -1584,9 +1575,6 @@ kern_getpeername(struct thread *td, int fd, struct socklen_t len; int error; - if (*alen < 0) - return (EINVAL); - AUDIT_ARG_FD(fd); error = getsock_cap(td->td_proc->p_fd, fd, CAP_GETPEERNAME, &fp, NULL); if (error) -- wbr, pluknet From owner-freebsd-current@FreeBSD.ORG Wed Feb 20 18:37:03 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id F1EF77C2 for ; Wed, 20 Feb 2013 18:37:03 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id ADE0EA93 for ; Wed, 20 Feb 2013 18:37:03 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) with esmtp (envelope-from ) id <1U8EXO-003baa-P5>; Wed, 20 Feb 2013 19:37:02 +0100 Received: from telesto.geoinf.fu-berlin.de ([130.133.86.198]) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1U8EXO-0047TA-Mh>; Wed, 20 Feb 2013 19:37:02 +0100 Message-ID: <512517C4.9020206@zedat.fu-berlin.de> Date: Wed, 20 Feb 2013 19:36:52 +0100 From: "O. Hartmann" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130208 Thunderbird/17.0.2 MIME-Version: 1.0 To: Ruslan Makhmatkhanov Subject: Re: Revision: 247040: kernel crashes with funny blinking characters on console on Ivy-Bridge CPUs References: <5124DF62.4010900@zedat.fu-berlin.de> <5125051C.7000909@yandex.ru> In-Reply-To: <5125051C.7000909@yandex.ru> X-Enigmail-Version: 1.4.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig8B15B84AAB5023CFC4321081" X-Originating-IP: 130.133.86.198 Cc: Current FreeBSD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 20 Feb 2013 18:37:04 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig8B15B84AAB5023CFC4321081 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 02/20/13 18:17, Ruslan Makhmatkhanov wrote: > O. Hartmann wrote on 20.02.2013 18:36: >> Compiling most recent sources of CURRENT with Revision: 247040 results= >> in a kernel crash with funny blinking characters on the screen. This >> happens on all systems with different amd64 Intel CPU generations at >> this very moment. >> >> Last working sources (reverting and booting kernel.old) is in my case >> >> >> FreeBSD 10.0-CURRENT #0 r246949: Mon Feb 18 22:18:42 CET 2013 >> >> >> Does anyone also experience this? >> >> Another remote experimental box, equipted with a Intel Q6600 CPU, is >> crashed, I have to investigate this when I get to the lab later. It >> seems not to be related only to Sandy-Bridge-E/Ivy-Bridge CPUs. >> >> >> Regards, >> Oliver >=20 > I just updated from r246618 to r247044 (kernel only, built with old > world) and everything works as expected. I have: > CPU: Intel(R) Core(TM) i5-2430M CPU @ 2.40GHz (2394.62-MHz K8-class CPU= ) >=20 > I may build new world and build new kernel with it if it's may help to > reproduce. >=20 My C2D Q6600 quits with a trap 16 or 18 (I have all withness and debug support deactivated at the moment). The Intel i3-3220 crashes with blinking characters on the screen (I use the built-in GPU for console displaying). A C2D 8400 - same setup, crashes also very early while booting. The whole system/world is built with CLANG, this is the setting of the /etc/src.conf: CPUTYPE?=3D native # CFLAGS+=3D -O3 -pipe -march=3Dnative # for Kernel COPTFLAGS+=3D -O3 -pipe -march=3Dnative # CXXFLAGS+=3D -stdlib=3Dlibc++ CXXFLAGS+=3D -std=3Dc++11 # WITH_CLANG_EXTRAS=3D YES WITH_CLANG_FULL=3D YES WITH_LLVM=3D YES WITH_LLVM_EXTRAS=3D YES # WITH_LIBCPLUSPLUS=3D YES # WITH_BIND_LARGE_FILE=3D YES WITH_BIND_SIGCHASE=3D YES WITH_BIND_LIBS=3D YES # WITH_IDEA=3D YES # #WITH_ICONV=3D YES WITH_BSD_GREP=3D YES WITH_BSDCONFIG=3D YES WITH_BSD_SORT=3D YES WITH_BSD_PATCH=3D YES # #WITH_OFED=3D YES WITH_NAND=3D YES WITH_NMTREE=3D YES #WITH_BMAKE=3D YES #WITH_CTF=3D YES # MALLOC_PRODUCTION=3D YES # PORTS_MODULES=3D emulators/virtualbox-ose-kmod #PORTS_MODULES+=3D x11/nvidia-driver I have a custom kernel, will try also the GENERIC and report in later. Oliver --------------enig8B15B84AAB5023CFC4321081 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.19 (FreeBSD) iQEcBAEBAgAGBQJRJRfOAAoJEOgBcD7A/5N8opoIAKnb2mk6Dwq8Qd3X9JqiCYPy NLHR4fodL9kPhV2X1YoHyxgnEtaOkcuiegUwosibIhoD89gLtid5brHWukmFaOwj 45XDwIZ3LSmRLKqWK2MgOJZH8DxYRNUStsRQRTYTngS8jvcMrPd/gckdysp37AZq ABVVuc4MfeDuXSMebUisyRo1rc8mMPesg+my9lOSPie4Ne2zjXXIXEfnqVWEenQs CbfPhHpkKgUDO9dibMw01hce5aAiJ++/qOS9/ZF1FN1eBAQTXP0kAbzzzPMi/pWI Iuv0Z+mKsxHj9auYmib2wNt6pdXfhHVA4rFdbmQ/aqfRF+XfUv9RxTueq5fk1AQ= =GkBX -----END PGP SIGNATURE----- --------------enig8B15B84AAB5023CFC4321081-- From owner-freebsd-current@FreeBSD.ORG Wed Feb 20 18:42:42 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 49C86B3D for ; Wed, 20 Feb 2013 18:42:42 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from anubis.delphij.net (anubis.delphij.net [IPv6:2001:470:1:117::25]) by mx1.freebsd.org (Postfix) with ESMTP id 29282AED for ; Wed, 20 Feb 2013 18:42:42 +0000 (UTC) Received: from epsilon.delphij.net (drawbridge.ixsystems.com [206.40.55.65]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by anubis.delphij.net (Postfix) with ESMTPSA id 9960B24EFD; Wed, 20 Feb 2013 10:42:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=delphij.net; s=anubis; t=1361385757; bh=iW2jdW+QHj1pO7ttDOiskVYmNdbZcDxncnYg53x4YK4=; h=Date:From:Reply-To:To:CC:Subject:References:In-Reply-To; b=uKprObrGVubI45vjFu564WvY2GBFo1pK8GUp56RYbc6Y6JRjwV8Atd9cpcCGMLw3W Ebuhmi5NhxK+eFiudDGt9+Bj25mEMC0jLlYTzSh2nhptJaqbxDw5BDTW3YDqd0us8+ RSjEF2OShYT9q35fwsL1v29sHSM03k0ujF6OKrBo= Message-ID: <5125191C.6010901@delphij.net> Date: Wed, 20 Feb 2013 10:42:36 -0800 From: Xin Li Organization: The FreeBSD Project MIME-Version: 1.0 To: Sergey Kandaurov Subject: Re: [patch] remove negative socklen_t checks References: In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 20 Feb 2013 18:42:42 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 02/20/13 09:19, Sergey Kandaurov wrote: > Hi. > > These checks are useless after the address length argument is > converted to socklen_t (up to SUSv2). Any objections? No objection in general but there is a minor style issue, see below. [...] > Index: sys/kern/uipc_syscalls.c > =================================================================== > > - --- sys/kern/uipc_syscalls.c (revision 246354) > +++ sys/kern/uipc_syscalls.c (working copy) @@ -353,8 +353,6 @@ > kern_accept(struct thread *td, int s, struct socka > > if (name) { *name = NULL; - if (*namelen < 0) - > return (EINVAL); } The { } for if () is no longer needed now per style(9). By the way I wonder why there is no compiler warning for this -- or do we compile kernel without signedness warnings? Just curious... Cheers, - -- Xin LI https://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJRJRkcAAoJEG80Jeu8UPuzagkIAICE9uJzbLS8MvPPYLEMCop3 mamlq7AOJSpGfEyBzB0CZV2badJC91LEtUGADMN0CANPbvX6EpDsYoPygpXBuxei etNelbp1+9jbqwV6yK+9FVCioRiMMLrPKkyh02+s1ZhWCf6kjz3Xl9MEYKUKYuV1 ay7xLcLnQMxOzf1oS7Sovm6NsIFnDC06WZ0PZDFdBtv7typtGblw3rrgWMsOnshL x35C1UC8NgLnauMEOhX6Vr1zeRz+hqfw+YauCi/P+3chxfUgpe6XR551IN2h9xBU mYTNEjLkRgX8u5sCHYGB16r/OZ3X59w1sJH/21ayrHuF0gNEmQbnMlBnA/krH94= =iiGi -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Wed Feb 20 19:27:48 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 94C8134B; Wed, 20 Feb 2013 19:27:48 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 0894AE50; Wed, 20 Feb 2013 19:27:47 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.6/8.14.6) with ESMTP id r1KJRedq002239; Wed, 20 Feb 2013 21:27:40 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.7.4 kib.kiev.ua r1KJRedq002239 Received: (from kostik@localhost) by tom.home (8.14.6/8.14.6/Submit) id r1KJRell002238; Wed, 20 Feb 2013 21:27:40 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 20 Feb 2013 21:27:39 +0200 From: Konstantin Belousov To: John Baldwin Subject: Re: [patch] i386 pmap sysmaps_pcpu[] atomic access Message-ID: <20130220192739.GM2598@kib.kiev.ua> References: <20130219185129.GC2598@kib.kiev.ua> <201302201022.29294.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="+0mKm/ENadSkQxF+" Content-Disposition: inline In-Reply-To: <201302201022.29294.jhb@freebsd.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: freebsd-current@freebsd.org, Svatopluk Kraus X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 20 Feb 2013 19:27:48 -0000 --+0mKm/ENadSkQxF+ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Feb 20, 2013 at 10:22:29AM -0500, John Baldwin wrote: > On Wednesday, February 20, 2013 7:31:08 am Svatopluk Kraus wrote: > > On Tue, Feb 19, 2013 at 7:51 PM, Konstantin Belousov > > wrote: > > > On Mon, Feb 18, 2013 at 11:18:16PM +0100, Svatopluk Kraus wrote: > > >> On Mon, Feb 18, 2013 at 9:36 PM, Konstantin Belousov > > >> wrote: > > >> Well, I'm taking a part on porting FreeBSD to ARM11mpcore. UP case w= as > > >> simple. SMP case is more complex and rather new for me. Recently, I > > >> was solving a problem with PCPU stuff. For example, PCPU_GET is > > >> implemented by one instruction on i386 arch. So, a need of atomicity > > >> with respect to interrupts can be overlooked. On load-store archs, t= he > > >> implementation which works in SMP case is not so simple. And what > > >> works in UP case (single PCPU), not works in SMP case. Believe me, > > >> mysterious and sporadic 'mutex not owned' assertions and others ones > > >> caused by curthreads mess, it takes a while ... > > > Note that PCPU_GET() is not needed to be atomic. The reason is that t= he code > > > which uses its result would not be atomic (single-instruction or what= ever, see > > > below). Thus, either the preemption should not matter since the actio= n with > > > the per-cpu data is advisory, as is in the case of i386 pmap you note= d. > > > or some external measures should be applied in advance to the contain= ing > > > region (which you proposed, by bracing with sched_pin()). > >=20 > > So, it's advisory in the case of i386 pmap... Well, if you can live > > with that, I can too. > >=20 > > > > > > Also, note that it is not interrupts but preemption which is concern. > >=20 > > Yes and no. In theory, yes, a preemption is a concern. In FreeBSD, > > however, sched_pin() and critical_enter() and their counterparts are > > implemented with help of curthread. And curthread definition falls to > > PCPU_GET(curthread) if not defined in other way. So, curthread should > > be atomic with respect to interrupts and in general, PCPU_GET() should > > be too. Note that spinlock_enter() definitions often (always) use > > curthread too. Anyhow, it's defined in MD code and can be defined for > > each arch separately. >=20 > curthread is a bit magic. :) If you perform a context switch during an > interrupt (which will change 'curthread') you also change your register s= tate. > When you resume, the register state is also restored. This means that wh= ile > something like 'PCPU_GET(cpuid)' might be stale after you read it, 'curth= read' > never is. However, it is true that actually reading curthread has to be > atomic. If your read of curthread looks like: >=20 > mov , r0 > add , r0 > ld r0, r1 >=20 > Then that will indeed break. Alpha used a fixed register for 'pcpu_reg' > (as does ia64 IIRC). OTOH, you might also be able to depend on the fact = that > pc_curthread is the first thing in 'struct pcpu' (and always will be, you= could > add a CTASSERT to future-proof). In that case, you can remove the 'add' > instruction and instead just do: >=20 > ld , r1 >=20 > which is fine. I just looked at the arm pcpu.h, and indeed the curthread falls back to the default implementation from sys/pcpu.h, which is get_pcpu()->pc_curthread. This looks buggy for SMP, does our arm port support any multi-cpu configuration ? --+0mKm/ENadSkQxF+ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJRJSOrAAoJEJDCuSvBvK1BqskP/jtTAH9+tb4wLITbSbQBnrPc Lldv1hIMLti5Upo/bCzmyj0HgNMFPuYEtAFCKglamiwq0IsnWF631UPuXoewhdZL KIk0vzNt2awp9n0KDC+NS15DiDzjgyD2jioxTuT79gSUT7mhyz0P7YVdjRlsED4f 0Dil6sAUvzZsVV7O2ZMT0WPii87gPdY2l+QRT49zbfwuPmi6USVwyxUTE6d3yWPw P/PeL/WVBEb2z+8dp5vrN8SWQR214nJ021hnxRtCN//qYlKCZzV2BvWp++lV5er6 zuv9udCBAGSdVU5CZwFQ8faGpncpJrWcfZD1u31rPvwobR54mpG0ySYdFTCSXQRi Fajtujl45BCCaXW27D+4bDc40nAmwqvI/Ivoj/qbc6t1Tq1khGIiQWv/lObbRruF EipM/VEnn8IlVB6QLm0i010lLFgMevPbjOyzdNZzRXrcThH6pbA7E9Z1RqL5J1jT gCbPvsKUywxpcwKrr/DOsCU4jBS3bt1pL7ADx38yrEDDSNyGGSHP22zwEWcoWXui TGBdXleEubrwGrasbvSLaa59ewBlm7i/rgDwxuLP8U3Qdg3YSHdu7vYlv01reREI OnlNYXaytHQSpK3VM9vsFBP5gRBgdLBSGCnNbyQ8oN8AATg+GmRZJ3+1b2BiRUXz q87LBvl5Tg6yLVxzMPsW =QLoH -----END PGP SIGNATURE----- --+0mKm/ENadSkQxF+-- From owner-freebsd-current@FreeBSD.ORG Wed Feb 20 19:42:37 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 3637CACC for ; Wed, 20 Feb 2013 19:42:37 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-wg0-f46.google.com (mail-wg0-f46.google.com [74.125.82.46]) by mx1.freebsd.org (Postfix) with ESMTP id C9C9CF32 for ; Wed, 20 Feb 2013 19:42:36 +0000 (UTC) Received: by mail-wg0-f46.google.com with SMTP id fg15so6606406wgb.1 for ; Wed, 20 Feb 2013 11:42:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=n+pSHqR1EwQdqS3zbcHMNeTMGgZ9ueee210I/s1zTQk=; b=AMurDkfWL1ZOS2ZVwLG/LHtfEJpMGX+SbBGVX4bL9HinQDloZTy2TYAsfd+mbwGIwl Nv2IPL6U6sma8oHP/F2uAuBs9TE/kSljkEgnPVfPbyZO45QSewkLabheTt8bJIEs2s/H KjqHRS2c6lk4FtYbRuqeOZLVO1/5syO3l1LSLKUTXX3UyEuJp3RizWLdi+X0uBdc6rVA IcQjEQl+uAyjGaPIudSYOXWacPgZrtPv5eUF+kyHK2IglV4C3YE+/7TSDUvzpo32bPBD x67/jGx4rmzVr9E0hz2cXASso8AUAukMH96QQI3XGbKgr/eEPvKUUU7XlpQtnWuccU6j USQg== MIME-Version: 1.0 X-Received: by 10.194.235.6 with SMTP id ui6mr36519559wjc.12.1361389355616; Wed, 20 Feb 2013 11:42:35 -0800 (PST) Received: by 10.194.86.167 with HTTP; Wed, 20 Feb 2013 11:42:35 -0800 (PST) In-Reply-To: <5125191C.6010901@delphij.net> References: <5125191C.6010901@delphij.net> Date: Wed, 20 Feb 2013 22:42:35 +0300 Message-ID: Subject: Re: [patch] remove negative socklen_t checks From: Sergey Kandaurov To: d@delphij.net Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 20 Feb 2013 19:42:37 -0000 On 20 February 2013 22:42, Xin Li wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > On 02/20/13 09:19, Sergey Kandaurov wrote: >> Hi. >> >> These checks are useless after the address length argument is >> converted to socklen_t (up to SUSv2). Any objections? > > No objection in general but there is a minor style issue, see below. > > [...] >> Index: sys/kern/uipc_syscalls.c >> =================================================================== >> >> > - --- sys/kern/uipc_syscalls.c (revision 246354) >> +++ sys/kern/uipc_syscalls.c (working copy) @@ -353,8 +353,6 @@ >> kern_accept(struct thread *td, int s, struct socka >> >> if (name) { *name = NULL; - if (*namelen < 0) - >> return (EINVAL); } > > The { } for if () is no longer needed now per style(9). Indeed, thanks. > > By the way I wonder why there is no compiler warning for this -- or do > we compile kernel without signedness warnings? Just curious... No, they are (at least with clang). That's how I came there. cc -c -O2 -pipe -fno-strict-aliasing -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 -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-aes -mno-avx -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror /usr/src/sys/kern/uipc_syscalls.c /usr/src/sys/kern/uipc_syscalls.c:356:16: warning: comparison of unsigned expression < 0 is always false [-Wtautological-compare] if (*namelen < 0) ~~~~~~~~ ^ ~ /usr/src/sys/kern/uipc_syscalls.c:1487:12: warning: comparison of unsigned expression < 0 is always false [-Wtautological-compare] if (*alen < 0) ~~~~~ ^ ~ /usr/src/sys/kern/uipc_syscalls.c:1587:12: warning: comparison of unsigned expression < 0 is always false [-Wtautological-compare] if (*alen < 0) ~~~~~ ^ ~ Other two warnings are obviously not triggered because of explicit cast to int (eek!). Thanks for review. -- wbr, pluknet From owner-freebsd-current@FreeBSD.ORG Wed Feb 20 19:49:56 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id AAE6DD15 for ; Wed, 20 Feb 2013 19:49:56 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 82825F97 for ; Wed, 20 Feb 2013 19:49:56 +0000 (UTC) Received: from pakbsde14.localnet (unknown [38.105.238.108]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id D4A65B982; Wed, 20 Feb 2013 14:49:55 -0500 (EST) From: John Baldwin To: Konstantin Belousov Subject: Re: [patch] i386 pmap sysmaps_pcpu[] atomic access Date: Wed, 20 Feb 2013 14:32:10 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p25; KDE/4.5.5; amd64; ; ) References: <201302201022.29294.jhb@freebsd.org> <20130220192739.GM2598@kib.kiev.ua> In-Reply-To: <20130220192739.GM2598@kib.kiev.ua> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201302201432.10502.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 20 Feb 2013 14:49:55 -0500 (EST) Cc: freebsd-current@freebsd.org, Svatopluk Kraus X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 20 Feb 2013 19:49:56 -0000 On Wednesday, February 20, 2013 2:27:39 pm Konstantin Belousov wrote: > On Wed, Feb 20, 2013 at 10:22:29AM -0500, John Baldwin wrote: > > On Wednesday, February 20, 2013 7:31:08 am Svatopluk Kraus wrote: > > > On Tue, Feb 19, 2013 at 7:51 PM, Konstantin Belousov > > > wrote: > > > > On Mon, Feb 18, 2013 at 11:18:16PM +0100, Svatopluk Kraus wrote: > > > >> On Mon, Feb 18, 2013 at 9:36 PM, Konstantin Belousov > > > >> wrote: > > > >> Well, I'm taking a part on porting FreeBSD to ARM11mpcore. UP case was > > > >> simple. SMP case is more complex and rather new for me. Recently, I > > > >> was solving a problem with PCPU stuff. For example, PCPU_GET is > > > >> implemented by one instruction on i386 arch. So, a need of atomicity > > > >> with respect to interrupts can be overlooked. On load-store archs, the > > > >> implementation which works in SMP case is not so simple. And what > > > >> works in UP case (single PCPU), not works in SMP case. Believe me, > > > >> mysterious and sporadic 'mutex not owned' assertions and others ones > > > >> caused by curthreads mess, it takes a while ... > > > > Note that PCPU_GET() is not needed to be atomic. The reason is that the code > > > > which uses its result would not be atomic (single-instruction or whatever, see > > > > below). Thus, either the preemption should not matter since the action with > > > > the per-cpu data is advisory, as is in the case of i386 pmap you noted. > > > > or some external measures should be applied in advance to the containing > > > > region (which you proposed, by bracing with sched_pin()). > > > > > > So, it's advisory in the case of i386 pmap... Well, if you can live > > > with that, I can too. > > > > > > > > > > > Also, note that it is not interrupts but preemption which is concern. > > > > > > Yes and no. In theory, yes, a preemption is a concern. In FreeBSD, > > > however, sched_pin() and critical_enter() and their counterparts are > > > implemented with help of curthread. And curthread definition falls to > > > PCPU_GET(curthread) if not defined in other way. So, curthread should > > > be atomic with respect to interrupts and in general, PCPU_GET() should > > > be too. Note that spinlock_enter() definitions often (always) use > > > curthread too. Anyhow, it's defined in MD code and can be defined for > > > each arch separately. > > > > curthread is a bit magic. :) If you perform a context switch during an > > interrupt (which will change 'curthread') you also change your register state. > > When you resume, the register state is also restored. This means that while > > something like 'PCPU_GET(cpuid)' might be stale after you read it, 'curthread' > > never is. However, it is true that actually reading curthread has to be > > atomic. If your read of curthread looks like: > > > > mov , r0 > > add , r0 > > ld r0, r1 > > > > Then that will indeed break. Alpha used a fixed register for 'pcpu_reg' > > (as does ia64 IIRC). OTOH, you might also be able to depend on the fact that > > pc_curthread is the first thing in 'struct pcpu' (and always will be, you could > > add a CTASSERT to future-proof). In that case, you can remove the 'add' > > instruction and instead just do: > > > > ld , r1 > > > > which is fine. > > I just looked at the arm pcpu.h, and indeed the curthread falls > back to the default implementation from sys/pcpu.h, which is > get_pcpu()->pc_curthread. This looks buggy for SMP, does our arm port > support any multi-cpu configuration ? Not in HEAD. There is a projects branch for armv6 I think that does. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Wed Feb 20 20:11:29 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 165D778B for ; Wed, 20 Feb 2013 20:11:29 +0000 (UTC) (envelope-from radiomlodychbandytow@o2.pl) Received: from tur.go2.pl (tur.go2.pl [193.17.41.50]) by mx1.freebsd.org (Postfix) with ESMTP id 815B3179 for ; Wed, 20 Feb 2013 20:11:28 +0000 (UTC) Received: from moh2-ve3.go2.pl (moh2-ve3.go2.pl [193.17.41.208]) by tur.go2.pl (Postfix) with ESMTP id C27C36B0018 for ; Wed, 20 Feb 2013 21:11:20 +0100 (CET) Received: from moh2-ve3.go2.pl (unknown [10.0.0.208]) by moh2-ve3.go2.pl (Postfix) with ESMTP id 9CFE7372B0D for ; Wed, 20 Feb 2013 21:11:14 +0100 (CET) Received: from unknown (unknown [10.0.0.108]) by moh2-ve3.go2.pl (Postfix) with SMTP for ; Wed, 20 Feb 2013 21:11:14 +0100 (CET) Received: from unknown [93.175.66.185] by poczta.o2.pl with ESMTP id YzhAzp; Wed, 20 Feb 2013 21:11:14 +0100 Message-ID: <51252DE2.7040907@o2.pl> Date: Wed, 20 Feb 2013 21:11:14 +0100 From: =?UTF-8?B?UmFkaW8gbcWCb2R5Y2ggYmFuZHl0w7N3?= User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130201 Thunderbird/17.0.2 MIME-Version: 1.0 To: freebsd-current@freebsd.org, "O. Hartmann" Subject: Re: PathScale EKO Path 5 not for FreeBSD anymore? References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-O2-Trust: 1, 32 X-O2-SPF: neutral X-Mailman-Approved-At: Wed, 20 Feb 2013 21:37:55 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 20 Feb 2013 20:11:29 -0000 On 20/02/2013 13:00, freebsd-current-request@freebsd.org wrote: > Gathering informations from many places - as it is with "WHICH > PROFESSIONAL COMPILER WORKS ON FREEBSD WITH PROFESSIONAL HIGH > PERFORMANCE MATH LIBS" is horrible and time consuming. try it on Google > with the tag "Linux" makes you happy within seconds. So true...I found that when the first search for a FreeBSD thing doesn't yield results, I search for Linux and then either check if the results work here or, having some well known name, look for alternatives. -- Twoje radio From owner-freebsd-current@FreeBSD.ORG Wed Feb 20 21:53:13 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 340F5C6B; Wed, 20 Feb 2013 21:53:13 +0000 (UTC) (envelope-from ian@FreeBSD.org) Received: from duck.symmetricom.us (duck.symmetricom.us [206.168.13.214]) by mx1.freebsd.org (Postfix) with ESMTP id 0189A96C; Wed, 20 Feb 2013 21:53:12 +0000 (UTC) Received: from damnhippie.dyndns.org (daffy.symmetricom.us [206.168.13.218]) by duck.symmetricom.us (8.14.6/8.14.6) with ESMTP id r1KLrB9i028301; Wed, 20 Feb 2013 14:53:12 -0700 (MST) (envelope-from ian@FreeBSD.org) Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id r1KLqxcd051828; Wed, 20 Feb 2013 14:52:59 -0700 (MST) (envelope-from ian@FreeBSD.org) Subject: Re: [patch] i386 pmap sysmaps_pcpu[] atomic access From: Ian Lepore To: John Baldwin In-Reply-To: <201302201432.10502.jhb@freebsd.org> References: <201302201022.29294.jhb@freebsd.org> <20130220192739.GM2598@kib.kiev.ua> <201302201432.10502.jhb@freebsd.org> Content-Type: text/plain; charset="us-ascii" Date: Wed, 20 Feb 2013 14:52:59 -0700 Message-ID: <1361397179.1185.13.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: Konstantin Belousov , freebsd-current@FreeBSD.org, Svatopluk Kraus X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 20 Feb 2013 21:53:13 -0000 On Wed, 2013-02-20 at 14:32 -0500, John Baldwin wrote: > On Wednesday, February 20, 2013 2:27:39 pm Konstantin Belousov wrote: > > On Wed, Feb 20, 2013 at 10:22:29AM -0500, John Baldwin wrote: > > > On Wednesday, February 20, 2013 7:31:08 am Svatopluk Kraus wrote: > > > > On Tue, Feb 19, 2013 at 7:51 PM, Konstantin Belousov > > > > wrote: > > > > > On Mon, Feb 18, 2013 at 11:18:16PM +0100, Svatopluk Kraus wrote: > > > > >> On Mon, Feb 18, 2013 at 9:36 PM, Konstantin Belousov > > > > >> wrote: > > > > >> Well, I'm taking a part on porting FreeBSD to ARM11mpcore. UP case was > > > > >> simple. SMP case is more complex and rather new for me. Recently, I > > > > >> was solving a problem with PCPU stuff. For example, PCPU_GET is > > > > >> implemented by one instruction on i386 arch. So, a need of atomicity > > > > >> with respect to interrupts can be overlooked. On load-store archs, the > > > > >> implementation which works in SMP case is not so simple. And what > > > > >> works in UP case (single PCPU), not works in SMP case. Believe me, > > > > >> mysterious and sporadic 'mutex not owned' assertions and others ones > > > > >> caused by curthreads mess, it takes a while ... > > > > > Note that PCPU_GET() is not needed to be atomic. The reason is that the code > > > > > which uses its result would not be atomic (single-instruction or whatever, see > > > > > below). Thus, either the preemption should not matter since the action with > > > > > the per-cpu data is advisory, as is in the case of i386 pmap you noted. > > > > > or some external measures should be applied in advance to the containing > > > > > region (which you proposed, by bracing with sched_pin()). > > > > > > > > So, it's advisory in the case of i386 pmap... Well, if you can live > > > > with that, I can too. > > > > > > > > > > > > > > Also, note that it is not interrupts but preemption which is concern. > > > > > > > > Yes and no. In theory, yes, a preemption is a concern. In FreeBSD, > > > > however, sched_pin() and critical_enter() and their counterparts are > > > > implemented with help of curthread. And curthread definition falls to > > > > PCPU_GET(curthread) if not defined in other way. So, curthread should > > > > be atomic with respect to interrupts and in general, PCPU_GET() should > > > > be too. Note that spinlock_enter() definitions often (always) use > > > > curthread too. Anyhow, it's defined in MD code and can be defined for > > > > each arch separately. > > > > > > curthread is a bit magic. :) If you perform a context switch during an > > > interrupt (which will change 'curthread') you also change your register state. > > > When you resume, the register state is also restored. This means that while > > > something like 'PCPU_GET(cpuid)' might be stale after you read it, 'curthread' > > > never is. However, it is true that actually reading curthread has to be > > > atomic. If your read of curthread looks like: > > > > > > mov , r0 > > > add , r0 > > > ld r0, r1 > > > > > > Then that will indeed break. Alpha used a fixed register for 'pcpu_reg' > > > (as does ia64 IIRC). OTOH, you might also be able to depend on the fact that > > > pc_curthread is the first thing in 'struct pcpu' (and always will be, you could > > > add a CTASSERT to future-proof). In that case, you can remove the 'add' > > > instruction and instead just do: > > > > > > ld , r1 > > > > > > which is fine. > > > > I just looked at the arm pcpu.h, and indeed the curthread falls > > back to the default implementation from sys/pcpu.h, which is > > get_pcpu()->pc_curthread. This looks buggy for SMP, does our arm port > > support any multi-cpu configuration ? > > Not in HEAD. There is a projects branch for armv6 I think that does. > There isn't anything I've heard of that makes it all the way to single user mode yet with multiple cores enabled. -- Ian From owner-freebsd-current@FreeBSD.ORG Wed Feb 20 22:14:39 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 9FC363C2 for ; Wed, 20 Feb 2013 22:14:39 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from anubis.delphij.net (anubis.delphij.net [64.62.153.212]) by mx1.freebsd.org (Postfix) with ESMTP id 8F347ADD for ; Wed, 20 Feb 2013 22:14:39 +0000 (UTC) Received: from epsilon.delphij.net (drawbridge.ixsystems.com [206.40.55.65]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by anubis.delphij.net (Postfix) with ESMTPSA id 0ABBD23E00; Wed, 20 Feb 2013 14:14:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=delphij.net; s=anubis; t=1361398479; bh=dgLSKAr4Ge4gzU2jL46doZz/pS2GSCX8xoHYrKrUj7o=; h=Date:From:Reply-To:To:Subject; b=pWHbHJpSqNBjKrhSSsEo4KC7tpOUTwoeUh/o/I2SktiN0nsKHip1GgRzQSzeErDNK 74/r/KX36H2z6cDIXQDOueovO5PJbLOTR++MXScJxxo+k1Fdz4/Rwt3GaXpAiTbLJ5 zqbViKgeB6nrP5gKZvycU7ULgzrs8okQG7rd3yqI= Message-ID: <51254ACE.2030100@delphij.net> Date: Wed, 20 Feb 2013 14:14:38 -0800 From: Xin Li Organization: The FreeBSD Project MIME-Version: 1.0 To: FreeBSD Current Subject: -CURRENT userland regression X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 20 Feb 2013 22:14:39 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi, It seems that fresh -HEAD would give an unusable kernel that overwrites screen buffer in a way making it impossible to debug. Using an old world source to do 'make buildworld buildkernel' results in a (mostly: I have some strange USB issue right now and still looking for the cause) usable kernel. For now my known good combination is world 246858 with kernel 247057. I'm still trying to find out which revision have broke the stuff. Cheers, - -- Xin LI https://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJRJUrOAAoJEG80Jeu8UPuzJBsIAMi/2gkOd2ApEGWRi7DgHu5c MVRBIgmGW72BfQUWGkNyBCg0nsOO67oKpxMPYx0xzSKMvt2vAohS4+55VuytjOKF mdKjs2wSVeMSYguJ5+OtM3cUxK1OuYRgqla6cvW5DCKdhF4WPFK27+tRgYlGTkzw poGgznOTP2jJlPjICQI+VXkSNrI46xRJqxM3d3/jeYjjujGDOKTthYZJsPNxkTqh mY3ng0hv18vFVxhQMDceRnaXl9QIYQKmzTPc1pnmF21GMDgpHeSfWDdPwvwYDVmO 04Jl8p0jyjfZvgpLddMoBy9GWfMLDY/qwYRE8sGYqWGQqR4y2dFXZTPZZN/YmO8= =0shF -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Wed Feb 20 22:18:56 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id CE5E8577; Wed, 20 Feb 2013 22:18:56 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from onyx.glenbarber.us (onyx.glenbarber.us [IPv6:2607:fc50:1000:c200::face]) by mx1.freebsd.org (Postfix) with ESMTP id A88F7B9D; Wed, 20 Feb 2013 22:18:56 +0000 (UTC) Received: from glenbarber.us (kaos.glenbarber.us [71.224.221.174]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: gjb) by onyx.glenbarber.us (Postfix) with ESMTPSA id B980123F669; Wed, 20 Feb 2013 17:18:55 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.7.4 onyx.glenbarber.us B980123F669 Authentication-Results: onyx.glenbarber.us; dkim=none reason="no signature"; dkim-adsp=none (insecure policy) Date: Wed, 20 Feb 2013 17:18:53 -0500 From: Glen Barber To: d@delphij.net Subject: Re: -CURRENT userland regression Message-ID: <20130220221853.GO1491@glenbarber.us> References: <51254ACE.2030100@delphij.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="pleSNuEbvnUYtMxG" Content-Disposition: inline In-Reply-To: <51254ACE.2030100@delphij.net> X-Operating-System: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 20 Feb 2013 22:18:56 -0000 --pleSNuEbvnUYtMxG Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Feb 20, 2013 at 02:14:38PM -0800, Xin Li wrote: > It seems that fresh -HEAD would give an unusable kernel that > overwrites screen buffer in a way making it impossible to debug. > Using an old world source to do 'make buildworld buildkernel' results > in a (mostly: I have some strange USB issue right now and still > looking for the cause) usable kernel. >=20 > For now my known good combination is world 246858 with kernel 247057. > I'm still trying to find out which revision have broke the stuff. >=20 There was a thread earlier today titled: "Revision: 247040: kernel crashes with funny blinking characters on console on Ivy-Bridge CPUs" if this helps. I am not sure if the report was isolated to that specific revision, or if it was the revision of -CURRENT at the time. Glen --pleSNuEbvnUYtMxG Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQEcBAEBCAAGBQJRJUvNAAoJEFJPDDeguUajCDYH/ROZbU670rbcIymx8jcwmUg7 cb8FdOeoPb3f0Oygpte3RKw5c0bXL5SsMd1NShKxBm9GnUQlD67HZnJnB3oAak9E 2qP0YfW6hzsA1bVG8JWUyocHJiT164zqbz2Y/yZOp9BO/5z4/Z6Md4pC/INabiFI Bh3xNcvgedyv1d2kSzA8gLzIDBoTb9kEjfcYOXVGdSgUf5lrUHSW/FYX5B/MUXW/ 1WTvvkchULylNeBqvv7FShR/Esp35IaKBqenqV8SLvCIQj5nyXU9G8RQm/oap//c OJaW93WzaCSV5HbYJ2s0VNgI852QWALYA9vCgUs+ZIpi4pbo6pMn+r3VxKU6qeY= =jzvd -----END PGP SIGNATURE----- --pleSNuEbvnUYtMxG-- From owner-freebsd-current@FreeBSD.ORG Wed Feb 20 22:21:58 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 7AC76830 for ; Wed, 20 Feb 2013 22:21:58 +0000 (UTC) (envelope-from nparhar@gmail.com) Received: from mail-pb0-f47.google.com (mail-pb0-f47.google.com [209.85.160.47]) by mx1.freebsd.org (Postfix) with ESMTP id 5917DC47 for ; Wed, 20 Feb 2013 22:21:58 +0000 (UTC) Received: by mail-pb0-f47.google.com with SMTP id rp2so3131025pbb.34 for ; Wed, 20 Feb 2013 14:21:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Wqq35iETahAeSU53/oqt3gHJWmpjl52iIN2UwoSE7tU=; b=mkaMmT1JMfTGR4/hYeOcgdoE8M+1D5uIus6ac3zrRR0LVXk+MegOZKNMKxi+ZwdnqZ Y99DB96irP7SqIzAIh/iZSaR/o8Zz7tm+6yooMaO8tjo5tda6DSv9wGUKqP9zn/Sw54B kQ4NceMaRN3RFvzgkLy1AWcXQ6gQudRuhiAQySMgbn1sj4PznY7yLF7+gpfrxx4atwcE C2C3QQSh+XzWlxWpm+f/xvNsIN2a+IVrH+6QQXv6k8qcZkHTO/+mtY1Cx4uPN5iOCfHC AsPSKboGwcJ/EFi7rpjf/vUaMWs49Do2nzSZuuq3aTKI6Z/negG7PhCj9cHQ2a0cWDno LaHQ== X-Received: by 10.68.143.133 with SMTP id se5mr4890545pbb.189.1361398912453; Wed, 20 Feb 2013 14:21:52 -0800 (PST) Received: from [10.192.166.0] (stargate.chelsio.com. [67.207.112.58]) by mx.google.com with ESMTPS id 1sm22915275pbg.18.2013.02.20.14.21.51 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 20 Feb 2013 14:21:51 -0800 (PST) Message-ID: <51254C7E.9050705@gmail.com> Date: Wed, 20 Feb 2013 14:21:50 -0800 From: Navdeep Parhar User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130220 Thunderbird/17.0.3 MIME-Version: 1.0 To: d@delphij.net Subject: Re: -CURRENT userland regression References: <51254ACE.2030100@delphij.net> In-Reply-To: <51254ACE.2030100@delphij.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD Current , Xin Li X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 20 Feb 2013 22:21:58 -0000 On 02/20/13 14:14, Xin Li wrote: > Hi, > > It seems that fresh -HEAD would give an unusable kernel that > overwrites screen buffer in a way making it impossible to debug. > Using an old world source to do 'make buildworld buildkernel' results > in a (mostly: I have some strange USB issue right now and still > looking for the cause) usable kernel. > > For now my known good combination is world 246858 with kernel 247057. > I'm still trying to find out which revision have broke the stuff. I ran into this earlier today. Selecting "safe mode" in the boot loader menu seems to work around the problem on my system. Now I will not reboot until I see a fix for this in head :-) Regards, Navdeep From owner-freebsd-current@FreeBSD.ORG Wed Feb 20 22:25:37 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id B84FF9B2 for ; Wed, 20 Feb 2013 22:25:37 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 31AD6CFD for ; Wed, 20 Feb 2013 22:25:37 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.6/8.14.6) with ESMTP id r1KMPIAP022944; Thu, 21 Feb 2013 00:25:18 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.7.4 kib.kiev.ua r1KMPIAP022944 Received: (from kostik@localhost) by tom.home (8.14.6/8.14.6/Submit) id r1KMPICw022941; Thu, 21 Feb 2013 00:25:18 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 21 Feb 2013 00:25:18 +0200 From: Konstantin Belousov To: Navdeep Parhar Subject: Re: -CURRENT userland regression Message-ID: <20130220222518.GT2598@kib.kiev.ua> References: <51254ACE.2030100@delphij.net> <51254C7E.9050705@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="wAPz785vMyyfnE3+" Content-Disposition: inline In-Reply-To: <51254C7E.9050705@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: Xin Li , FreeBSD Current , d@delphij.net X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 20 Feb 2013 22:25:37 -0000 --wAPz785vMyyfnE3+ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Feb 20, 2013 at 02:21:50PM -0800, Navdeep Parhar wrote: > On 02/20/13 14:14, Xin Li wrote: > > Hi, > >=20 > > It seems that fresh -HEAD would give an unusable kernel that > > overwrites screen buffer in a way making it impossible to debug. > > Using an old world source to do 'make buildworld buildkernel' results > > in a (mostly: I have some strange USB issue right now and still > > looking for the cause) usable kernel. > >=20 > > For now my known good combination is world 246858 with kernel 247057. > > I'm still trying to find out which revision have broke the stuff. >=20 > I ran into this earlier today. Selecting "safe mode" in the boot loader > menu seems to work around the problem on my system. Now I will not > reboot until I see a fix for this in head :-) How much 'the earlier today' is ? I.e., could you specify some revisions ? --wAPz785vMyyfnE3+ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJRJU1NAAoJEJDCuSvBvK1BXv0QAIRD+z3tTuntU7kKk8u7zBJm zLu+gMYDIGMHduC1XbobU+YG6V2rzi4jdr8hMY63MSRrD1EQKxhTcSQjkynrr9Lm S1N/kJ9SHZ/ODU8XqUNjIpVwjuV3R1bFG/iuUpsyws8m3GB52y4n/1Sf/XmdSNNn OKE7c4hq7SF2VzUjpmImllexmIk5CMqS9T7iVFoVLcs6LeHKmHVzmGv0A9MUpvgW GSo0ftOQ0p//TszDQdqXyWBU2DYKEQAUlr1ZHrIsy2qONq/HEO8UolRoyjcQpfjZ 6StUWRw543H9RrleMmR4JSs50MgH0V0pKhUyP3UQqBf3VAzNeAyqhmkhqzQ4gQVR EHhwz4XtqPuXJARCT7Pa28oo8jnUCeLx11rM1JVv8JOjtB7gkOcVzKoeflrQQ2MZ mpnHb0MwnBKwyBM6KGAN4aNNZTWLKoWeaA9+LnSxRUQ+EiUoQ6+CZZU1Iu6GkFI6 91mDcwkdqf8mIWFTu9FD84f3F05PtZ3URrVerGYSCO8XNFqttsFlZGY4g0fGlame bin5D1J3bt+qB3ySFBeOOkEeGosF01Kj5LCkMW1R5dhmj25SU4S6MSvRoyF6H561 2OM5rDgl8kLsfP5JyuJTXN9+wwkR/sv0q2i2A66xY2ob/98l1Q1LJt96/YSSXiLZ dFksO3j+QNHISM2CvoT8 =wBAA -----END PGP SIGNATURE----- --wAPz785vMyyfnE3+-- From owner-freebsd-current@FreeBSD.ORG Wed Feb 20 22:29:38 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id DB1D0C75 for ; Wed, 20 Feb 2013 22:29:38 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from anubis.delphij.net (anubis.delphij.net [IPv6:2001:470:1:117::25]) by mx1.freebsd.org (Postfix) with ESMTP id C185EDAB for ; Wed, 20 Feb 2013 22:29:38 +0000 (UTC) Received: from epsilon.delphij.net (drawbridge.ixsystems.com [206.40.55.65]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by anubis.delphij.net (Postfix) with ESMTPSA id 3AEAB23F60; Wed, 20 Feb 2013 14:29:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=delphij.net; s=anubis; t=1361399378; bh=w926NF1f4IuFfIEM2ic10ctXydnWYir2Sc6FfQCsDpo=; h=Date:From:Reply-To:To:CC:Subject:References:In-Reply-To; b=SHu32RKp8xO8EwQPh2PhoQkQ+LdXINLiiwA/Y7ALOzafWZWyFnLUoFQif+/76NaNo KGx7OOxrArvr/2MZ/B+Oe6vXV43yuszzPgHvMYiZn0S8CE+lDtDdgnt1JuSAZd+YOC +89p19nzDmrkVduGj9HJMtk8t6oaDoznZWVg+yko= Message-ID: <51254E51.1070702@delphij.net> Date: Wed, 20 Feb 2013 14:29:37 -0800 From: Xin Li Organization: The FreeBSD Project MIME-Version: 1.0 To: Konstantin Belousov Subject: Re: -CURRENT userland regression References: <51254ACE.2030100@delphij.net> <51254C7E.9050705@gmail.com> <20130220222518.GT2598@kib.kiev.ua> In-Reply-To: <20130220222518.GT2598@kib.kiev.ua> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD Current , d@delphij.net, Navdeep Parhar X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 20 Feb 2013 22:29:38 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 02/20/13 14:25, Konstantin Belousov wrote: > On Wed, Feb 20, 2013 at 02:21:50PM -0800, Navdeep Parhar wrote: >> On 02/20/13 14:14, Xin Li wrote: >>> Hi, >>> >>> It seems that fresh -HEAD would give an unusable kernel that >>> overwrites screen buffer in a way making it impossible to >>> debug. Using an old world source to do 'make buildworld >>> buildkernel' results in a (mostly: I have some strange USB >>> issue right now and still looking for the cause) usable >>> kernel. >>> >>> For now my known good combination is world 246858 with kernel >>> 247057. I'm still trying to find out which revision have broke >>> the stuff. >> >> I ran into this earlier today. Selecting "safe mode" in the boot >> loader menu seems to work around the problem on my system. Now I >> will not reboot until I see a fix for this in head :-) > > How much 'the earlier today' is ? I.e., could you specify some > revisions ? It would take some time to bi-sect as one needs to do full world/kernel build. The only thing I can say definitely is that something from userland was broken within the (246858,247057] range. I'm compiling 246957 right now. Cheers, - -- Xin LI https://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJRJU5RAAoJEG80Jeu8UPuzvh0H/3gL+Og4fmzZ8TYrkhseuIS4 Pll3sWdIZnCqorfUV2ZFiRzV9Awvt4KRfl3m15lCM6ornl6jdVilQq9o07cfTQFK mvkD6J08nraG/7D/raSzQ9oO4uTUYLVkzoaCDDa3Lz6fdpoIQ6JvuzcvOAsV+DJa DjjKCIB6bOITaA+boyvTAsMwkv437Mz4Ze2eVqUbexwhWktHkzlROhX/H2Cz7CQn fMNxpZFntjhEszi5HRYXQXVkdr/M0t92FpykZQCEXIClyw6tdXWEPJcMZFWVPRip Rg6AR9Iys/BhlMJRttttUl5BzVK0eOB4Jx2PS1pckAduXBKykIrpsEIqY2Ybf1I= =0Hzl -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Wed Feb 20 22:33:26 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 5769AE4 for ; Wed, 20 Feb 2013 22:33:26 +0000 (UTC) (envelope-from nparhar@gmail.com) Received: from mail-pa0-f48.google.com (mail-pa0-f48.google.com [209.85.220.48]) by mx1.freebsd.org (Postfix) with ESMTP id 1EC4BE0E for ; Wed, 20 Feb 2013 22:33:26 +0000 (UTC) Received: by mail-pa0-f48.google.com with SMTP id hz10so4330110pad.7 for ; Wed, 20 Feb 2013 14:33:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=JjlJqDS/wtvvJ7Usm9TztK/4xgeHQCVBFsw2+GMk9Ms=; b=TPRwImrWSSh04Ios2W3mbX1mpOMQjPG3dJd6686Dv6Ies/2gPJfBW5Q9/11WWnSj8S 1s3fF21/uyDnMQZKqP04BvUlTcEiK7K6C5YLCEWWMHMi6SZ7ZabwC8BxCdxVBy1lxjLy KBGJXjF0a68Paa/REoPgSkQf84fmMuViSymPaU51O0aRsSyPv1a24Qpekenq6TI9ZEor Y9/1vxJSw6SmkKSlCvCfPJBMCIxBQSF03LU0SHIWgVGgGs03WkuF4fd2UkFms7cu6vZi jP65elPBw3KXecNUFjgdV4xdTINkmP2qJRZlXiFlYtFyQMJU4T4BXc1WcOEDyhgrTJzs 4gMA== X-Received: by 10.68.241.102 with SMTP id wh6mr11247149pbc.150.1361399605722; Wed, 20 Feb 2013 14:33:25 -0800 (PST) Received: from [10.192.166.0] (stargate.chelsio.com. [67.207.112.58]) by mx.google.com with ESMTPS id t6sm112520669paz.11.2013.02.20.14.33.24 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 20 Feb 2013 14:33:25 -0800 (PST) Message-ID: <51254F33.5060904@gmail.com> Date: Wed, 20 Feb 2013 14:33:23 -0800 From: Navdeep Parhar User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130220 Thunderbird/17.0.3 MIME-Version: 1.0 To: Konstantin Belousov Subject: Re: -CURRENT userland regression References: <51254ACE.2030100@delphij.net> <51254C7E.9050705@gmail.com> <20130220222518.GT2598@kib.kiev.ua> In-Reply-To: <20130220222518.GT2598@kib.kiev.ua> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Xin Li , FreeBSD Current , d@delphij.net X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 20 Feb 2013 22:33:26 -0000 On 02/20/13 14:25, Konstantin Belousov wrote: > On Wed, Feb 20, 2013 at 02:21:50PM -0800, Navdeep Parhar wrote: >> On 02/20/13 14:14, Xin Li wrote: >>> Hi, >>> >>> It seems that fresh -HEAD would give an unusable kernel that >>> overwrites screen buffer in a way making it impossible to debug. >>> Using an old world source to do 'make buildworld buildkernel' results >>> in a (mostly: I have some strange USB issue right now and still >>> looking for the cause) usable kernel. >>> >>> For now my known good combination is world 246858 with kernel 247057. >>> I'm still trying to find out which revision have broke the stuff. >> >> I ran into this earlier today. Selecting "safe mode" in the boot loader >> menu seems to work around the problem on my system. Now I will not >> reboot until I see a fix for this in head :-) > > How much 'the earlier today' is ? > I.e., could you specify some revisions ? > I upgraded from a month old (approx.) head to r247054 and ran into this problem. I haven't tried bisecting as I need a running system right now. Regards, Navdeep From owner-freebsd-current@FreeBSD.ORG Wed Feb 20 22:37:13 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 3E81C399 for ; Wed, 20 Feb 2013 22:37:13 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id D5F7FE64 for ; Wed, 20 Feb 2013 22:37:12 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.6/8.14.6) with ESMTP id r1KMb4AX024248; Thu, 21 Feb 2013 00:37:04 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.7.4 kib.kiev.ua r1KMb4AX024248 Received: (from kostik@localhost) by tom.home (8.14.6/8.14.6/Submit) id r1KMb4AW024247; Thu, 21 Feb 2013 00:37:04 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 21 Feb 2013 00:37:04 +0200 From: Konstantin Belousov To: d@delphij.net Subject: Re: -CURRENT userland regression Message-ID: <20130220223704.GU2598@kib.kiev.ua> References: <51254ACE.2030100@delphij.net> <51254C7E.9050705@gmail.com> <20130220222518.GT2598@kib.kiev.ua> <51254E51.1070702@delphij.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="67BqmJg2unxe7d8V" Content-Disposition: inline In-Reply-To: <51254E51.1070702@delphij.net> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: FreeBSD Current , Navdeep Parhar X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 20 Feb 2013 22:37:13 -0000 --67BqmJg2unxe7d8V Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Feb 20, 2013 at 02:29:37PM -0800, Xin Li wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 >=20 > On 02/20/13 14:25, Konstantin Belousov wrote: > > On Wed, Feb 20, 2013 at 02:21:50PM -0800, Navdeep Parhar wrote: > >> On 02/20/13 14:14, Xin Li wrote: > >>> Hi, > >>>=20 > >>> It seems that fresh -HEAD would give an unusable kernel that=20 > >>> overwrites screen buffer in a way making it impossible to > >>> debug. Using an old world source to do 'make buildworld > >>> buildkernel' results in a (mostly: I have some strange USB > >>> issue right now and still looking for the cause) usable > >>> kernel. > >>>=20 > >>> For now my known good combination is world 246858 with kernel > >>> 247057. I'm still trying to find out which revision have broke > >>> the stuff. > >>=20 > >> I ran into this earlier today. Selecting "safe mode" in the boot > >> loader menu seems to work around the problem on my system. Now I > >> will not reboot until I see a fix for this in head :-) > >=20 > > How much 'the earlier today' is ? I.e., could you specify some > > revisions ? >=20 > It would take some time to bi-sect as one needs to do full > world/kernel build. The only thing I can say definitely is that > something from userland was broken within the (246858,247057] range. > I'm compiling 246957 right now. My first guess would be r247047, but I did booted the kernel+world with this change applied, on amd64. Hm, I booted on the machine with serial console. --67BqmJg2unxe7d8V Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJRJVAQAAoJEJDCuSvBvK1Bz4IP/iRWdTqrvcOCmCnaPxM209RZ XP1VPCkc8meIu7IDrUuIWwo1+ZisuTEvTZA+xkMOnkuFwdDBP/oElajarsBm/EN9 mHPXCxjlSRe0r56Kk5w7RX88hiMPA62e87tELhV8oe4Ge6Nu+zcezNS8+1HzFZqJ lJBzRx8vLPq2COo+UeObVrg1ZmAKZmGLJMKiLaWw/Lz1McrTrhpl+1Xm27wHFgUe yULvAgQ+Z9hk6f1QdfvYlFGfGGdAxaymU78+mt6Cd6MaRfWtxvHKTpEm6EB9KQEx J2RR0MjRbjINYJehl29b+52q9H7tTLofCDR6OVdS5XvodnD0XvyhqWdCFz5x3sXL BdXOg8pS87ezd9HghvQcxdY0CJTj8fiIaIaDzEbfM1CWVe51do4E2n82fE+eCbvL ClfyCm0JkjoJg+dHp7y0PZcaQq1ZF/D2AXD5CRrKLD90Zq8ySFZgUW4cnSR+9OPR O9Jz9Tx/eXMu/LFYfH/zbdSNFNffFatvismJN5Tk0QRTg8i3f47XbsPRddsxhijN yCrcs+d38nqWebPRawE6+/+IzPB+NmQILzsYpN6n64l0jh4qykJf8raZRLbQX0ir 2lzAsK006GfW3S9RUFRB3JFse/kiY+2Kfxq1/w+qaBRGzsDxkpW9ll/UxSND5uQt KfMnmyY0DX2CRg5zJ8mE =wYJW -----END PGP SIGNATURE----- --67BqmJg2unxe7d8V-- From owner-freebsd-current@FreeBSD.ORG Wed Feb 20 22:37:23 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 1F5BD4C5 for ; Wed, 20 Feb 2013 22:37:23 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (m209-73.dsl.rawbw.com [198.144.209.73]) by mx1.freebsd.org (Postfix) with ESMTP id D7F73E70 for ; Wed, 20 Feb 2013 22:37:22 +0000 (UTC) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.14.6/8.14.6) with ESMTP id r1KMbM3o029019 for ; Wed, 20 Feb 2013 14:37:22 -0800 (PST) (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.14.6/8.14.6/Submit) id r1KMbMBi029018 for current@freebsd.org; Wed, 20 Feb 2013 14:37:22 -0800 (PST) (envelope-from david) Date: Wed, 20 Feb 2013 14:37:22 -0800 From: David Wolfskill To: current@freebsd.org Subject: Re: -CURRENT userland regression Message-ID: <20130220223722.GA28913@albert.catwhisker.org> References: <51254ACE.2030100@delphij.net> <51254C7E.9050705@gmail.com> <20130220222518.GT2598@kib.kiev.ua> <51254F33.5060904@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="mYCpIKhGyMATD0i+" Content-Disposition: inline In-Reply-To: <51254F33.5060904@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 20 Feb 2013 22:37:23 -0000 --mYCpIKhGyMATD0i+ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Feb 20, 2013 at 02:33:23PM -0800, Navdeep Parhar wrote: > On 02/20/13 14:25, Konstantin Belousov wrote: > > On Wed, Feb 20, 2013 at 02:21:50PM -0800, Navdeep Parhar wrote: > >> On 02/20/13 14:14, Xin Li wrote: > >>> Hi, > >>> > >>> It seems that fresh -HEAD would give an unusable kernel that > >>> overwrites screen buffer in a way making it impossible to debug. > >>> Using an old world source to do 'make buildworld buildkernel' results > >>> in a (mostly: I have some strange USB issue right now and still > >>> looking for the cause) usable kernel. > >>> > >>> For now my known good combination is world 246858 with kernel 247057. > >>> I'm still trying to find out which revision have broke the stuff. > >> > >> I ran into this earlier today. Selecting "safe mode" in the boot load= er > >> menu seems to work around the problem on my system. Now I will not > >> reboot until I see a fix for this in head :-) > >=20 > > How much 'the earlier today' is ? > > I.e., could you specify some revisions ? > >=20 >=20 > I upgraded from a month old (approx.) head to r247054 and ran into this > problem. I haven't tried bisecting as I need a running system right now. > ... I did not see such a problem after building & booting: FreeBSD g1-227.catwhisker.org 10.0-CURRENT FreeBSD 10.0-CURRENT #817 r2470= 30M/247030: Wed Feb 20 08:13:58 PST 2013 root@g1-227.catwhisker.org:/us= r/obj/usr/src/sys/CANARY i386 built with clang. FWIW. Peace, david --=20 David H. Wolfskill david@catwhisker.org Taliban: Evil men with guns afraid of truth from a 14-year old girl. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --mYCpIKhGyMATD0i+ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlElUCEACgkQmprOCmdXAD2mBACfbcK97x6kCgTuyqoI0re0l/wa HecAniTa8exf8MA8xTsNp/YwzujjqssA =Qufg -----END PGP SIGNATURE----- --mYCpIKhGyMATD0i+-- From owner-freebsd-current@FreeBSD.ORG Wed Feb 20 22:47:50 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 5B5B3874 for ; Wed, 20 Feb 2013 22:47:50 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id D60CFF38 for ; Wed, 20 Feb 2013 22:47:49 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.6/8.14.6) with ESMTP id r1KMlWfE025426; Thu, 21 Feb 2013 00:47:32 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.7.4 kib.kiev.ua r1KMlWfE025426 Received: (from kostik@localhost) by tom.home (8.14.6/8.14.6/Submit) id r1KMlW81025425; Thu, 21 Feb 2013 00:47:32 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 21 Feb 2013 00:47:32 +0200 From: Konstantin Belousov To: Navdeep Parhar Subject: Re: -CURRENT userland regression Message-ID: <20130220224732.GV2598@kib.kiev.ua> References: <51254ACE.2030100@delphij.net> <51254C7E.9050705@gmail.com> <20130220222518.GT2598@kib.kiev.ua> <51254F33.5060904@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Jgs7yVrrV0awjHqX" Content-Disposition: inline In-Reply-To: <51254F33.5060904@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: Xin Li , FreeBSD Current , d@delphij.net X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 20 Feb 2013 22:47:50 -0000 --Jgs7yVrrV0awjHqX Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Feb 20, 2013 at 02:33:23PM -0800, Navdeep Parhar wrote: > On 02/20/13 14:25, Konstantin Belousov wrote: > > On Wed, Feb 20, 2013 at 02:21:50PM -0800, Navdeep Parhar wrote: > >> On 02/20/13 14:14, Xin Li wrote: > >>> Hi, > >>> > >>> It seems that fresh -HEAD would give an unusable kernel that > >>> overwrites screen buffer in a way making it impossible to debug. > >>> Using an old world source to do 'make buildworld buildkernel' results > >>> in a (mostly: I have some strange USB issue right now and still > >>> looking for the cause) usable kernel. > >>> > >>> For now my known good combination is world 246858 with kernel 247057. > >>> I'm still trying to find out which revision have broke the stuff. > >> > >> I ran into this earlier today. Selecting "safe mode" in the boot load= er > >> menu seems to work around the problem on my system. Now I will not > >> reboot until I see a fix for this in head :-) > >=20 > > How much 'the earlier today' is ? > > I.e., could you specify some revisions ? > >=20 >=20 > I upgraded from a month old (approx.) head to r247054 and ran into this > problem. I haven't tried bisecting as I need a running system right now. BTW, does the loader fails, or is it the kernel where the problems start appearing ? --Jgs7yVrrV0awjHqX Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJRJVKEAAoJEJDCuSvBvK1BPy0P/RoRsdYV6ZBuYqoC6kqdKaUD /dErpz06ZakrJPiriCKzNAR944mvh2IzwHfVmdba4+TYqgNFhmZMyC1p0JUYqFYv 4SXGiWY+VesOxRfzQQRs5WECxAa8wRwCxEAGzuYQP9N9i/k9I89nDJ+sHK5HOd/9 B6t9t3NA9g66q8yHF2qr+xgu4iiGYOYrx08BwTDMZo9vIcp+ir28nMNNowHS3MgV ujIxINQYxMUuMo+ct/pbIZV/IZnHQvXKj46ML2na+wCJkmmoWJe6FUs8C54wAlrw Ua8TmO+65fGp7yxm0wpGFJy4XrFO4NEEGSn8H0KL8EhhPus0FFnR2vtbzaoBo+/e xOMl6fVdJ3+VKPgHcaHrs3Q0vi7UriI3r0l/a6Iijz4gebXvwycZ/w2rv+Y2iAom iAeELGN5aMd9hr3TfQSq4XVP+wZHsipTrTiUXt51msPxa78sYxgKCCgUieVRsueW hSP+0SteyfzcNzH+JHbxWaeozHMJMFpgHk/YlA3vkmrdMFcq6AsYKbYsBSG0eL+K GAIkW93zre8vtFUDpnYotrId46so6fA6l4Do1pTH+92wVjwIJkABFScvzDh8djOA 8Ol3UY9Lupt8jHKklEscSmw90r0HnWVVvb5/El916FLDtkA8X3T40tXGXG9ZpZPM Ohq+/0WoHBhwl/2cqfX3 =BulK -----END PGP SIGNATURE----- --Jgs7yVrrV0awjHqX-- From owner-freebsd-current@FreeBSD.ORG Wed Feb 20 22:49:03 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 89000983 for ; Wed, 20 Feb 2013 22:49:03 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) by mx1.freebsd.org (Postfix) with ESMTP id 546A1F4E for ; Wed, 20 Feb 2013 22:49:03 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.6/8.14.6) with ESMTP id r1KMmrGi044512; Wed, 20 Feb 2013 14:48:53 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.6/8.14.6/Submit) id r1KMmrrZ044511; Wed, 20 Feb 2013 14:48:53 -0800 (PST) (envelope-from sgk) Date: Wed, 20 Feb 2013 14:48:53 -0800 From: Steve Kargl To: d@delphij.net Subject: Re: -CURRENT userland regression Message-ID: <20130220224853.GA44319@troutmask.apl.washington.edu> References: <51254ACE.2030100@delphij.net> <51254C7E.9050705@gmail.com> <20130220222518.GT2598@kib.kiev.ua> <51254E51.1070702@delphij.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <51254E51.1070702@delphij.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Konstantin Belousov , FreeBSD Current , Navdeep Parhar X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 20 Feb 2013 22:49:03 -0000 On Wed, Feb 20, 2013 at 02:29:37PM -0800, Xin Li wrote: > > It would take some time to bi-sect as one needs to do full > world/kernel build. The only thing I can say definitely is that > something from userland was broken within the (246858,247057] range. > I'm compiling 246957 right now. > I have laptop:kargl[201] uname -a FreeBSD laptop 10.0-CURRENT FreeBSD 10.0-CURRENT #0 r247049M: Wed Feb 20 11:05:4 running without a problem. It's an older cpu, CPU: Intel(R) Core(TM)2 Duo CPU T7250 @ 2.00GHz (1995.05-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x6fd Family = 0x6 Model = 0xf Stepping = 13 Features=0xbfebfbff Features2=0xe3bd AMD Features=0x20000000 AMD Features2=0x1 TSC: P-state invariant, performance statistics I've rebuilt several ports on this laptop since rebooting with ports/distfile located on a usb mounted UFS2 filesystem. Do note, that everything is compiled with gcc as clang is explicitly disabled with WITHOUT_CLANG in /etc/make.conf. -- Steve From owner-freebsd-current@FreeBSD.ORG Wed Feb 20 22:52:06 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 9A626DA0 for ; Wed, 20 Feb 2013 22:52:06 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 3CF1AF97 for ; Wed, 20 Feb 2013 22:52:06 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.6/8.14.6) with ESMTP id r1KMps7S026003; Thu, 21 Feb 2013 00:51:54 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.7.4 kib.kiev.ua r1KMps7S026003 Received: (from kostik@localhost) by tom.home (8.14.6/8.14.6/Submit) id r1KMpsAm026002; Thu, 21 Feb 2013 00:51:54 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 21 Feb 2013 00:51:54 +0200 From: Konstantin Belousov To: Steve Kargl Subject: Re: -CURRENT userland regression Message-ID: <20130220225154.GW2598@kib.kiev.ua> References: <51254ACE.2030100@delphij.net> <51254C7E.9050705@gmail.com> <20130220222518.GT2598@kib.kiev.ua> <51254E51.1070702@delphij.net> <20130220224853.GA44319@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="GSafuNNN4NHc9BES" Content-Disposition: inline In-Reply-To: <20130220224853.GA44319@troutmask.apl.washington.edu> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: FreeBSD Current , d@delphij.net, Navdeep Parhar X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 20 Feb 2013 22:52:06 -0000 --GSafuNNN4NHc9BES Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Feb 20, 2013 at 02:48:53PM -0800, Steve Kargl wrote: > On Wed, Feb 20, 2013 at 02:29:37PM -0800, Xin Li wrote: > > > > It would take some time to bi-sect as one needs to do full > > world/kernel build. The only thing I can say definitely is that > > something from userland was broken within the (246858,247057] range. > > I'm compiling 246957 right now. > >=20 >=20 > I have=20 >=20 > laptop:kargl[201] uname -a > FreeBSD laptop 10.0-CURRENT FreeBSD 10.0-CURRENT #0 r247049M: Wed Feb 20 = 11:05:4 >=20 What arch is it ? amd64 or i386 ? > running without a problem. It's an older cpu,=20 >=20 > CPU: Intel(R) Core(TM)2 Duo CPU T7250 @ 2.00GHz (1995.05-MHz 686-cla= ss CPU) > Origin =3D "GenuineIntel" Id =3D 0x6fd Family =3D 0x6 Model =3D 0xf = Stepping =3D 13 > Features=3D0xbfebfbff > Features2=3D0xe3bd > AMD Features=3D0x20000000 > AMD Features2=3D0x1 > TSC: P-state invariant, performance statistics >=20 > I've rebuilt several ports on this laptop since rebooting with > ports/distfile located on a usb mounted UFS2 filesystem. >=20 > Do note, that everything is compiled with gcc as clang > is explicitly disabled with WITHOUT_CLANG in /etc/make.conf. >=20 > --=20 > Steve --GSafuNNN4NHc9BES Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJRJVOJAAoJEJDCuSvBvK1BX5oP/0oFHTVXp6L1i6WbXIzPlg/T wD7lqrf1DBtEDNegESIQ8UBp5dQaGUm//yoho0fVWT0mxlDFplVVXdiqdQhmcUbR q+8gttBwT2mrc3qqNZeOoF8sdc9AXlV+xXB+BZsqKQ0UQInDSxUpWHBEmWdCNTrN MP9alrXG7cNd1osX8aSS00twPLbHnpCEIHY39Rc78kpYeMF0FgfV8QBB81HK7nt9 O15DhIYmmHqHE3vIVujtLEdQyn3KJAWgVOXMU75h8DonwqCOt0AJ1yTwqUpagCRx SvznVo32z6rpu35c2a0HDt2JtaQEp0XApdM/au0ASxJQ7HMVBLK27EMHkaJYzabT u1/sknN10mPTFkHKXVnLu5pwk29c0moKDFZu6cxsVN7lSUfFcReiXo1Ks7zErXnI woZdnGv9aNaQbWWXMdV2Uz7uzqikHbJwU6/JYYstLtke6pUvSY6wfaa0HgTgzIAr BnogsZ3hyxcdG93Vw6/dYXxgbFUq4RboJgg0SQ11GtynsSh3E4AoqGYimYqkBLd2 +/SM3j4xsjc9/Fh8uMps/h1Xgl7Fqoq4au3SG75wp9SZ53m8+HYc1l+EIh+3icx0 BlgmIzUsgTYzs6LZZaTeKPGQ/O66e1pBZkbVPFzn/CT2+Pv2rGItUPhQdBMd/zJF PHj546CEOBDkxyu8i9yX =N/PO -----END PGP SIGNATURE----- --GSafuNNN4NHc9BES-- From owner-freebsd-current@FreeBSD.ORG Wed Feb 20 22:56:52 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id C9FB9F94 for ; Wed, 20 Feb 2013 22:56:52 +0000 (UTC) (envelope-from nparhar@gmail.com) Received: from mail-pb0-f53.google.com (mail-pb0-f53.google.com [209.85.160.53]) by mx1.freebsd.org (Postfix) with ESMTP id 97323FDE for ; Wed, 20 Feb 2013 22:56:52 +0000 (UTC) Received: by mail-pb0-f53.google.com with SMTP id un1so3129017pbc.40 for ; Wed, 20 Feb 2013 14:56:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=NS2WMAZ4LmtMgZ7yjKzeX7cHVZeb54YpGIhPVwvBJfQ=; b=rAdizSBw7HZkRDQzLiCbpW9VPXzUFStb8rrBbrb4pf2uY8cj/Sj8JClnCJfQauhl21 VYzCzFR7E4Va6Ysmn1pM/9GqycRUUhPFRJ7btrVTvBzIVcnKoMYjXMbPn6ndcwBWWXJR qT7xTWuDLehgx+2QssbJNj9VeWPovhO6mHXrdqo+H5Mdohmib5uO3hHvdx8UxdJ0yF9+ EO4xG/0+JHRUmIwbxYULm5YfJMoD4oRFvlu3aclNvSRKZa6uVzObdckj5DR2xQ8Sw/V0 CHIdXChJC4C5KxIFwrhGiB3AvgGnKTFCnQcX0uYI5Ak09nqej41DBPEnSmVkJ4Novffj NJuQ== X-Received: by 10.68.17.104 with SMTP id n8mr35249088pbd.18.1361401012093; Wed, 20 Feb 2013 14:56:52 -0800 (PST) Received: from [10.192.166.0] (stargate.chelsio.com. [67.207.112.58]) by mx.google.com with ESMTPS id hs8sm22993096pbc.27.2013.02.20.14.56.50 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 20 Feb 2013 14:56:51 -0800 (PST) Message-ID: <512554B2.3070601@gmail.com> Date: Wed, 20 Feb 2013 14:56:50 -0800 From: Navdeep Parhar User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130220 Thunderbird/17.0.3 MIME-Version: 1.0 To: Konstantin Belousov Subject: Re: -CURRENT userland regression References: <51254ACE.2030100@delphij.net> <51254C7E.9050705@gmail.com> <20130220222518.GT2598@kib.kiev.ua> <51254F33.5060904@gmail.com> <20130220224732.GV2598@kib.kiev.ua> In-Reply-To: <20130220224732.GV2598@kib.kiev.ua> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Xin Li , FreeBSD Current , d@delphij.net X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 20 Feb 2013 22:56:52 -0000 On 02/20/13 14:47, Konstantin Belousov wrote: > On Wed, Feb 20, 2013 at 02:33:23PM -0800, Navdeep Parhar wrote: >> On 02/20/13 14:25, Konstantin Belousov wrote: >>> On Wed, Feb 20, 2013 at 02:21:50PM -0800, Navdeep Parhar wrote: >>>> On 02/20/13 14:14, Xin Li wrote: >>>>> Hi, >>>>> >>>>> It seems that fresh -HEAD would give an unusable kernel that >>>>> overwrites screen buffer in a way making it impossible to debug. >>>>> Using an old world source to do 'make buildworld buildkernel' results >>>>> in a (mostly: I have some strange USB issue right now and still >>>>> looking for the cause) usable kernel. >>>>> >>>>> For now my known good combination is world 246858 with kernel 247057. >>>>> I'm still trying to find out which revision have broke the stuff. >>>> >>>> I ran into this earlier today. Selecting "safe mode" in the boot loader >>>> menu seems to work around the problem on my system. Now I will not >>>> reboot until I see a fix for this in head :-) >>> >>> How much 'the earlier today' is ? >>> I.e., could you specify some revisions ? >>> >> >> I upgraded from a month old (approx.) head to r247054 and ran into this >> problem. I haven't tried bisecting as I need a running system right now. > > BTW, does the loader fails, or is it the kernel where the problems start > appearing ? > The problem occurs well after the kernel is up and running. The last messages that were readable were from ugen/uhub and ada0. The rest was garbled and the system froze solid something after that. I tried pinging it but it wasn't reachable so this wasn't a case where the console was trashed but system was running. This is amd64 built with clang. I have dual consoles - serial and VGA. FreeBSD trantor 10.0-CURRENT FreeBSD 10.0-CURRENT #26: Wed Feb 20 13:18:48 PST 2013 root@trantor:/usr/obj/usr/src/sys/TOEKTR amd64 Regards, Navdeep From owner-freebsd-current@FreeBSD.ORG Wed Feb 20 22:57:41 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id B81961B8 for ; Wed, 20 Feb 2013 22:57:41 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) by mx1.freebsd.org (Postfix) with ESMTP id 9B5BAFF5 for ; Wed, 20 Feb 2013 22:57:41 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.6/8.14.6) with ESMTP id r1KMvdOB045261; Wed, 20 Feb 2013 14:57:39 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.6/8.14.6/Submit) id r1KMvdDI045260; Wed, 20 Feb 2013 14:57:39 -0800 (PST) (envelope-from sgk) Date: Wed, 20 Feb 2013 14:57:38 -0800 From: Steve Kargl To: Konstantin Belousov Subject: Re: -CURRENT userland regression Message-ID: <20130220225738.GC44319@troutmask.apl.washington.edu> References: <51254ACE.2030100@delphij.net> <51254C7E.9050705@gmail.com> <20130220222518.GT2598@kib.kiev.ua> <51254E51.1070702@delphij.net> <20130220224853.GA44319@troutmask.apl.washington.edu> <20130220225154.GW2598@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130220225154.GW2598@kib.kiev.ua> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: FreeBSD Current , d@delphij.net, Navdeep Parhar X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 20 Feb 2013 22:57:41 -0000 On Thu, Feb 21, 2013 at 12:51:54AM +0200, Konstantin Belousov wrote: > On Wed, Feb 20, 2013 at 02:48:53PM -0800, Steve Kargl wrote: > > On Wed, Feb 20, 2013 at 02:29:37PM -0800, Xin Li wrote: > > > > > > It would take some time to bi-sect as one needs to do full > > > world/kernel build. The only thing I can say definitely is that > > > something from userland was broken within the (246858,247057] range. > > > I'm compiling 246957 right now. > > > > > > > I have > > > > laptop:kargl[201] uname -a > > FreeBSD laptop 10.0-CURRENT FreeBSD 10.0-CURRENT #0 r247049M: Wed Feb 20 11:05:4 > > > What arch is it ? amd64 or i386 ? > i386. Also note, I do not use modules, so all devices are compiled into the kernel. -- Steve From owner-freebsd-current@FreeBSD.ORG Wed Feb 20 23:16:47 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 30C58DDB for ; Wed, 20 Feb 2013 23:16:47 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from anubis.delphij.net (anubis.delphij.net [IPv6:2001:470:1:117::25]) by mx1.freebsd.org (Postfix) with ESMTP id 1691C1AC for ; Wed, 20 Feb 2013 23:16:47 +0000 (UTC) Received: from epsilon.delphij.net (drawbridge.ixsystems.com [206.40.55.65]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by anubis.delphij.net (Postfix) with ESMTPSA id B4ADE24389; Wed, 20 Feb 2013 15:16:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=delphij.net; s=anubis; t=1361402206; bh=xHu3hUsVRxOjrSJA9VEYPrd8yy8ROlwSZhr69abAjO0=; h=Date:From:Reply-To:To:CC:Subject:References:In-Reply-To; b=Mveg0YICUNGsS7FdrPen3hf4I4btCH9s3eC1+wUMpa/bWi4L59uLGCs4UgMbDFJXO sIb/lkbeDs6383HK6SU+kpbqlNAOK7cMKxWxHFXzD1Ob0kfpkeE/J5tyn8EjuY5pwn e2/ZxC7yY/LfD+N7GIFXWqn+mH5D0NjShiA7HXV8= Message-ID: <5125595D.5010508@delphij.net> Date: Wed, 20 Feb 2013 15:16:45 -0800 From: Xin Li Organization: The FreeBSD Project MIME-Version: 1.0 To: Konstantin Belousov Subject: Re: -CURRENT userland regression References: <51254ACE.2030100@delphij.net> <51254C7E.9050705@gmail.com> <20130220222518.GT2598@kib.kiev.ua> <51254E51.1070702@delphij.net> <20130220223704.GU2598@kib.kiev.ua> In-Reply-To: <20130220223704.GU2598@kib.kiev.ua> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD Current , d@delphij.net, Navdeep Parhar X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 20 Feb 2013 23:16:47 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 02/20/13 14:37, Konstantin Belousov wrote: > On Wed, Feb 20, 2013 at 02:29:37PM -0800, Xin Li wrote: >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 >> >> On 02/20/13 14:25, Konstantin Belousov wrote: >>> On Wed, Feb 20, 2013 at 02:21:50PM -0800, Navdeep Parhar >>> wrote: >>>> On 02/20/13 14:14, Xin Li wrote: >>>>> Hi, >>>>> >>>>> It seems that fresh -HEAD would give an unusable kernel >>>>> that overwrites screen buffer in a way making it impossible >>>>> to debug. Using an old world source to do 'make buildworld >>>>> buildkernel' results in a (mostly: I have some strange USB >>>>> issue right now and still looking for the cause) usable >>>>> kernel. >>>>> >>>>> For now my known good combination is world 246858 with >>>>> kernel 247057. I'm still trying to find out which revision >>>>> have broke the stuff. >>>> >>>> I ran into this earlier today. Selecting "safe mode" in the >>>> boot loader menu seems to work around the problem on my >>>> system. Now I will not reboot until I see a fix for this in >>>> head :-) >>> >>> How much 'the earlier today' is ? I.e., could you specify some >>> revisions ? >> >> It would take some time to bi-sect as one needs to do full >> world/kernel build. The only thing I can say definitely is that >> something from userland was broken within the (246858,247057] >> range. I'm compiling 246957 right now. > > My first guess would be r247047, but I did booted the kernel+world > with this change applied, on amd64. Hm, I booted on the machine > with serial console. I think it's unlikely -- I have r247057 of sys/ which worked fine... userland 246957 works good by the way. Cheers, - -- Xin LI https://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJRJVldAAoJEG80Jeu8UPuzxBcH/AntMKSKAou10EU8/PbZEAHH q7A4enMQll13UuG9DzcXoQLEdmy+oCTpOcCn1Fe7YcY/ykvKgZhSUgTwwmZseL/N vHRgLH44ctAHEZMGW50oAVLgpR4ac4/dwbqeCThFwMb6C0wwRgo2SJD1w5GW8TMw JI40BeGdSEggJVOuYf+GJh433Wg5IhhxTsVkd5DXNrqjY5QfbtFwWJmUS7DKCb4X Ds153GhyxVJ2YXHBp6HjJ8ccmocBZ+plnda9uNTTVYcvklbQDzYWIFmxHsUO1OBq rXXSh93PJ7yJh/vrSFncDyxxpjfEfqlpCyM60Htd6CaFri1JbAn1kl4OmaDrlt8= =i2Ev -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Wed Feb 20 23:29:08 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id E1FFC3F2 for ; Wed, 20 Feb 2013 23:29:08 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id A9C59235 for ; Wed, 20 Feb 2013 23:29:08 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqEEAHVbJVGDaFvO/2dsb2JhbABFhkm6GoEac4IfAQEBAwEBAQEgBCcgCwUWDgoCAg0ZAikBCSYGCAcEARwEh2sGDK4Akj2BI4wlBQaBBzQHgi2BEwOIZosOgjiBHY8+gyVPfQgXHg X-IronPort-AV: E=Sophos;i="4.84,705,1355115600"; d="scan'208";a="17540792" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-jnhn.mail.uoguelph.ca with ESMTP; 20 Feb 2013 18:29:07 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 23641B3EB3; Wed, 20 Feb 2013 18:29:07 -0500 (EST) Date: Wed, 20 Feb 2013 18:29:07 -0500 (EST) From: Rick Macklem To: Andrey Simonenko Message-ID: <423251068.3167476.1361402947119.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <20130220122826.GA13613@pm513-1.comsys.ntu-kpi.kiev.ua> Subject: Re: Possible bug in NFSv4 with krb5p security? MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.202] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - FF3.0 (Win)/6.0.10_GA_2692) Cc: freebsd-current@freebsd.org, Elias Martenson , Benjamin Kaduk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 20 Feb 2013 23:29:08 -0000 Andrey Simonnenko wrote: > On Tue, Feb 19, 2013 at 08:52:49PM -0500, Rick Macklem wrote: > > > > > > I cannot find how to get information about maximum buffer size for > > > the getpwnam_r() function. This information should be returned by > > > sysconf(_SC_GETPW_R_SIZE_MAX), but since it does not work on > > > FreeBSD > > > it is necessary to guess its size. Original value is 128 and it > > > works > > > for somebody, 1024 works for your environment, but it can fail for > > > another environment. > > > > > > SUSv4 specifies "Storage referenced by the structure is allocated > > > from > > > the memory provided with the buffer parameter", but then tells > > > about > > > groups > > > in EXAMPLE for getpwnam_r() "Note that > > > sysconf(_SC_GETPW_R_SIZE_MAX) > > > may > > > return -1 if there is no hard limit on the size of the buffer > > > needed > > > to > > > store all the groups returned". > > > > > > malloc() can give overhead, but that function can try to call > > > getpwnam_r() > > > with buffer allocated from stack and if getpwnam_r() failed with > > > ERANGE > > > use dynamically allocated buffer. > > > > > > #define PWBUF_SIZE_INI (2 * MAXLOGNAME + 2 * MAXPATHLEN + > > > _PASSWORD_LEN + 1) > > > #define PWBUF_SIZE_INC 128 > > > > > > char bufs[2 * MAXLOGNAME + MAXPATHLEN + PASSWORD_LEN + 1 + 32]; > > > > > > error = getpwnam_r(lname, &pwd, bufs, sizeof(bufs), &pw); > > > if (pw != NULL) { > > > *uidp = pw->pw_uid; > > > return (GSS_S_COMPLETE); > > > } else if (error != ERANGE) > > > return (GSS_S_FAILURE); > > > > > > size = PWBUF_SIZE_INI; > > > for (;;) { > > > size += PWBUF_SIZE_INC; > > > buf = malloc(size); > > > if (buf == NULL) > > > return (GSS_S_FAILURE); > > > error = getpwnam_r(lname, &pwd, buf, size, &pw); > > > free(buf); > > > if (pw != NULL) { > > > *uidp = pw->pw_uid; > > > return (GSS_S_COMPLETE); > > > } else { > > > if (error == ERANGE && > > > size <= SIZE_MAX - PWBUF_SIZE_INC) > > > continue; > > > return (GSS_S_FAILURE); > > > } > > > } > > > > Just my opinion, but I think the above is a good approach. > > (ie. First trying a fairly large buffer on the stack that > > will succeed 99.99% of the time, but check for ERANGE and > > loop trying progressively larger malloc'd buffers until > > it stops reporting ERANGE.) > > > > I suspect the overheads behind getpwnam_r() are larger than > > the difference between using a buffer on the stack vs malloc, > > so I think it should use a fairly large buffer the first time. > > > > Personally, I might have coded it as a single do { } while(), > > with the first attempt in it, but that's just personal stylistic > > taste. (You can check for buf != bufs before doing a free() of it.) > > And, if you wanted to be clever, the code could use a static > > "bufsiz_hint", > > which is set to the largest size needed sofar and that is used as > > the initial malloc size. That way it wouldn't loop as much for a > > site with huge passwd entries. (An entire bio in the GECOS field or > > ???) > > > > Thanks for the review. > > Another variant. This is a program that can be used for verifying > correctness of the function, just change PWBUF_SIZE_* values and put > some printfs to see when buffer is reallocated. sizehint is updated > only when malloc() succeeded. > > --------------------------------- > #include > #include > > #include > > #include > #include > #include > #include > #include > #include > #include > > static int > getpwnam_r_func(const char *name, uid_t *uidp) > { > #define PWBUF_SIZE_INI (2 * MAXLOGNAME + MAXPATHLEN + _PASSWORD_LEN) > #define PWBUF_SIZE_INC 128 > > static size_t sizehint = PWBUF_SIZE_INI; > > struct passwd pwd; > struct passwd *pw; > char *buf; > size_t size; > int error; > char lname[MAXLOGNAME]; > char bufs[PWBUF_SIZE_INI]; > > strncpy(lname, name, sizeof(lname)); > > buf = bufs; > size = sizeof(bufs); > for (;;) { > error = getpwnam_r(lname, &pwd, buf, size, &pw); > if (buf != bufs) > free(buf); > if (pw != NULL) { > *uidp = pw->pw_uid; > return (GSS_S_COMPLETE); > } else if (error != ERANGE || size > SIZE_MAX - PWBUF_SIZE_INC) > return (GSS_S_FAILURE); > if (size != sizehint) > size = sizehint; > else > size += PWBUF_SIZE_INC; > buf = malloc(size); > if (buf == NULL) > return (GSS_S_FAILURE); > sizehint = size; > } > } > All looks fine to me. (Before my mailer messed with the whitespace;-) Thanks, rick ps: I will commit it in April, unless someone else does so sooner. > int > main(void) > { > const char *str[] = { "man", "root", "q", "bin", NULL }; > uid_t uid; > u_int i; > > for (i = 0; str[i] != NULL; ++i) { > printf("%-20s\t", str[i]); > if (getpwnam_r_func(str[i], &uid) == GSS_S_COMPLETE) > printf("%u\n", uid); > else > printf("not found\n"); > } > return (0); > } > --------------------------------- > _______________________________________________ > 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 Feb 21 00:04:50 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 6FE4CD76; Thu, 21 Feb 2013 00:04:50 +0000 (UTC) (envelope-from feld@feld.me) Received: from feld.me (unknown [IPv6:2607:f4e0:100:300::2]) by mx1.freebsd.org (Postfix) with ESMTP id 4EF92692; Thu, 21 Feb 2013 00:04:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=feld.me; s=blargle; h=In-Reply-To:Message-Id:From:Mime-Version:Date:References:Subject:Cc:To:Content-Type; bh=UyDlJ+yO8higm5N82KRkByTiZs7a5Mb8xgikk2/e/q8=; b=nNwCEanwwgcpjHZj/itmhIy+BOt3ErMAFREetiV63uWJbumuqbrNoXPXUvBqUqItn05RCPeQGMjGA/IagjqhNAo7Ytj/F+hveeOcVJJ6NHSPT0d4VEsftUpQDsjhDHi2; Received: from localhost ([127.0.0.1] helo=mwi1.coffeenet.org) by feld.me with esmtp (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1U8JeU-0000qf-Cq; Wed, 20 Feb 2013 18:04:42 -0600 Received: from feld@feld.me by mwi1.coffeenet.org (Archiveopteryx 3.1.4) with esmtpsa id 1361405076-61085-51256/5/3; Thu, 21 Feb 2013 00:04:36 +0000 Content-Type: text/plain; format=flowed; delsp=yes To: mexas@bristol.ac.uk, "O. Hartmann" Subject: Re: PathScale EKO Path 5 not for FreeBSD anymore? References: <201302200909.r1K99lx0029375@mech-cluster241.men.bris.ac.uk> <5124B115.70707@zedat.fu-berlin.de> Date: Wed, 20 Feb 2013 18:04:36 -0600 Mime-Version: 1.0 From: Mark Felder Message-Id: In-Reply-To: <5124B115.70707@zedat.fu-berlin.de> User-Agent: Opera Mail/12.13 (FreeBSD) Cc: freebsd-performance@freebsd.org, freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 21 Feb 2013 00:04:50 -0000 I've been talking to others and it seems that several of us are convinced that BSD is back on the uptake, so I wouldn't be so quick to mark its demise. :-) From owner-freebsd-current@FreeBSD.ORG Wed Feb 20 23:51:14 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id A70A19FB for ; Wed, 20 Feb 2013 23:51:14 +0000 (UTC) (envelope-from dantavious313@gmail.com) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by mx1.freebsd.org (Postfix) with ESMTP id 6F453375 for ; Wed, 20 Feb 2013 23:51:14 +0000 (UTC) Received: by mail-qc0-f172.google.com with SMTP id b25so3358548qca.31 for ; Wed, 20 Feb 2013 15:51:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:subject:date:message-id:user-agent:mime-version :content-transfer-encoding:content-type; bh=JMAHtqzxTNpX/tXU3fs4K0AgfqD6m/4TZwl2WpUi9n4=; b=wuS7gJ5ZSNSXq8vgs0SttWa9qrFfrSnmKmn24DuMQuybVojHKfTgxEjuu8b9xhhucT DnU8s/2ixhk+nXFu7B4yZoO39S0rZxT1KidGOeGyAVzm0gRysqr8qdYMGT8ASE9yevpE ThDrS9zyuRjhad3DtkY30jQmbkD7+FNIa+UOTTttAiifRSR078QccBNFniLtprKsfBa/ /qNvolHeWz0rpfN4H+nieF90mLPwG28mB1aqiToWPo0mdOzG10LVoXh2l1iI3rMQhEIH +UDqma8ShPogRJkqaDoH60+C+aiZFangWvs8ymQ3SsoqZ/n5/mdUTnltIL+MXIZqkugq ucaA== X-Received: by 10.224.41.196 with SMTP id p4mr10709977qae.92.1361403819784; Wed, 20 Feb 2013 15:43:39 -0800 (PST) Received: from zeus.localnet (c-71-226-137-213.hsd1.ga.comcast.net. [71.226.137.213]) by mx.google.com with ESMTPS id z9sm1966364qae.5.2013.02.20.15.43.38 (version=TLSv1.2 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 20 Feb 2013 15:43:38 -0800 (PST) From: Derrick Dantavious Edwards To: freebsd-current@freebsd.org Subject: -CURRENT userland regression Date: Wed, 20 Feb 2013 18:43:34 -0500 Message-ID: <12267334.dmuEncksP6@zeus> User-Agent: KMail/4.9.5 (FreeBSD/10.0-CURRENT; KDE/4.9.5; amd64; ; ) MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Mailman-Approved-At: Thu, 21 Feb 2013 00:12:57 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 20 Feb 2013 23:51:14 -0000 Hi, I have the same issues with FreeBSD 10.0-CURRENT #0 r247035. I completed the buildworld process and was able to install kernel. When I rebooted and attmpted to installworld, I got the same surprise that everyone got. I was able to get in the system using SAFE MODE. FreeBSD 10.0-CURRENT #0 r247035: Wed Feb 20 09:57:43 EST 2013 derrick@zeus:/usr/obj/usr/src/sys/ZEUS amd64 FreeBSD clang version 3.2 (tags/RELEASE_32/final 170710) 20121221 CPU: Intel(R) Core(TM) i5-3210M CPU @ 2.50GHz (2494.39-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x306a9 Family = 0x6 Model = 0x3a Stepping=9 Features=0xbfebfbff Features2=0x7fbae3bf AMD Features=0x28100800 AMD Features2=0x1 Standard Extended Features=0x281 TSC: P-state invariant, performance statistics real memory = 17179869184 (16384 MB) avail memory = 16421789696 (15661 MB) Event timer "LAPIC" quality 600 ACPI APIC Table: pci0: on pcib0 vgapci0: port 0x3000-0x303f mem 0xb8000000-0xb83fffff,0xb0000000-0xb7ffffff irq 16 at device 2.0 on pci0 agp0: on vgapci0 agp0: aperture size is 128M, detected 32764k stolen memory acpi_video0: on vgapci0 V/r Derrick From owner-freebsd-current@FreeBSD.ORG Thu Feb 21 06:05:54 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 70832754; Thu, 21 Feb 2013 06:05:54 +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 47D45114C; Thu, 21 Feb 2013 06:05:54 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r1L65lL3010944; Thu, 21 Feb 2013 01:05:47 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r1L65liD010940; Thu, 21 Feb 2013 06:05:47 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 21 Feb 2013 06:05:47 GMT Message-Id: <201302210605.r1L65liD010940@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 , , Subject: [head tinderbox] failure on arm/arm Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 06:05:54 -0000 TB --- 2013-02-21 04:10:20 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-02-21 04:10:20 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-02-21 04:10:20 - starting HEAD tinderbox run for arm/arm TB --- 2013-02-21 04:10:20 - cleaning the object tree TB --- 2013-02-21 04:10:20 - /usr/local/bin/svn stat /src TB --- 2013-02-21 04:10:24 - At svn revision 247073 TB --- 2013-02-21 04:10:25 - building world TB --- 2013-02-21 04:10:25 - CROSS_BUILD_TESTING=YES TB --- 2013-02-21 04:10:25 - MAKEOBJDIRPREFIX=/obj TB --- 2013-02-21 04:10:25 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-02-21 04:10:25 - SRCCONF=/dev/null TB --- 2013-02-21 04:10:25 - TARGET=arm TB --- 2013-02-21 04:10:25 - TARGET_ARCH=arm TB --- 2013-02-21 04:10:25 - TZ=UTC TB --- 2013-02-21 04:10:25 - __MAKE_CONF=/dev/null TB --- 2013-02-21 04:10:25 - cd /src TB --- 2013-02-21 04:10:25 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Thu Feb 21 04:10:30 UTC 2013 >>> 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 Thu Feb 21 05:59:30 UTC 2013 TB --- 2013-02-21 05:59:30 - generating LINT kernel config TB --- 2013-02-21 05:59:30 - cd /src/sys/arm/conf TB --- 2013-02-21 05:59:30 - /usr/bin/make -B LINT TB --- 2013-02-21 05:59:30 - cd /src/sys/arm/conf TB --- 2013-02-21 05:59:30 - /usr/sbin/config -m LINT TB --- 2013-02-21 05:59:30 - building LINT kernel TB --- 2013-02-21 05:59:30 - CROSS_BUILD_TESTING=YES TB --- 2013-02-21 05:59:30 - MAKEOBJDIRPREFIX=/obj TB --- 2013-02-21 05:59:30 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-02-21 05:59:30 - SRCCONF=/dev/null TB --- 2013-02-21 05:59:30 - TARGET=arm TB --- 2013-02-21 05:59:30 - TARGET_ARCH=arm TB --- 2013-02-21 05:59:30 - TZ=UTC TB --- 2013-02-21 05:59:30 - __MAKE_CONF=/dev/null TB --- 2013-02-21 05:59:30 - cd /src TB --- 2013-02-21 05:59:30 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Feb 21 05:59:30 UTC 2013 >>> 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 -fdiagnostics-show-option -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 -fno-builtin -mno-thumb-interwork -ffreestanding -Werror /src/sys/dev/ppbus/pps.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 -fdiagnostics-show-option -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 -fno-builtin -mno-thumb-interwork -ffreestanding -Werror /src/sys/dev/ppbus/vpo.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 -fdiagnostics-show-option -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 -fno-builtin -mno-thumb-interwork -ffreestanding -Werror /src/sys/dev/ppbus/vpoio.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 -fdiagnostics-show-option -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 -fno-builtin -mno-thumb-interwork -ffreestanding -Werror /src/sys/dev/ppc/ppc.c cc1: warnings being treated as errors /src/sys/dev/ppc/ppc.c: In function 'ppc_smc37c66xgt_detect': /src/sys/dev/ppc/ppc.c:724: warning: implicit declaration of function 'critical_leave' /src/sys/dev/ppc/ppc.c:724: warning: nested extern declaration of 'critical_leave' [-Wnested-externs] *** [ppc.o] Error code 1 Stop in /obj/arm.arm/src/sys/LINT. *** [buildkernel] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-02-21 06:05:47 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-02-21 06:05:47 - ERROR: failed to build LINT kernel TB --- 2013-02-21 06:05:47 - 5597.33 user 985.47 system 6926.93 real http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-arm-arm.full From owner-freebsd-current@FreeBSD.ORG Thu Feb 21 06:43:34 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 3157C391 for ; Thu, 21 Feb 2013 06:43:34 +0000 (UTC) (envelope-from sendtomatt@gmail.com) Received: from mail-ob0-f178.google.com (mail-ob0-f178.google.com [209.85.214.178]) by mx1.freebsd.org (Postfix) with ESMTP id 044B513DC for ; Thu, 21 Feb 2013 06:43:33 +0000 (UTC) Received: by mail-ob0-f178.google.com with SMTP id wd20so8313818obb.23 for ; Wed, 20 Feb 2013 22:43:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=Y0ilIY3Ad3dzYeG7orOkCNtow4spFTlaV080AS3OLuY=; b=B5hOEBPZidKsGVRXD/piMpHybmUcyaEHEa3ZS1tmhvrCnzXa082oAy4Udizgh89/K9 OT/Jrb4sIh4GDJGbHg64bH9UxVQ8MAQbGMaliFtHxIhAJQXijgZCYkR6E+x1yxJkDjXA IPXUipYBm1wiyJyE787D3G3s6NUtwq7sQudoltJ3OyWPr5/9ek/tmQpB1+1diR6KU5Zq e5zKfuZrsZKS/vV5fSVjB85KuLOlB+aiCyhMc1+5eyhvpB7Gr0heXOVzL3v1XuX4BoD+ RDueie3Q+uYjAMefQrOy/pnP5sRODoi3LbMDzJHylwCQNy0dzvtyt9QhEgl7WvtHoh0p 3Pkg== MIME-Version: 1.0 X-Received: by 10.182.86.196 with SMTP id r4mr10152184obz.56.1361429013233; Wed, 20 Feb 2013 22:43:33 -0800 (PST) Received: by 10.76.24.234 with HTTP; Wed, 20 Feb 2013 22:43:33 -0800 (PST) Date: Thu, 21 Feb 2013 06:43:33 +0000 Message-ID: Subject: Kernel hang r247079 mps/vfs/zfs? From: matt To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 21 Feb 2013 06:43:34 -0000 I was testing a patch on r246300 or so, and wanted to see if it would apply cleanly to a newer copy of HEAD. Well it did, except I had a hang at boot, shortly after ZFS version and the last scsi devices appear. This easily could have been related to the patch I was testing, so I wiped /usr/src/ and /usr/obj (after booting kernel.old) and rebuilt world and kernel cleanly. I assumed that would resolve the issue, but it did not. The hang happens right after zfs is announced, and the last da devices (some of which are usb) are reported. It comes before the noisy output of mps. Hang is complete, and single user or verbose don't yield much. I'm having trouble exfiltrating a dmesg from it, but it may be unrelated to the userland issues reported earlier, as single user does not resolve it for me. The svn up was at 11:20 pacific (GMT +8). Anyone else seeing similar issues? Hardware is an LSI mps device, "9210" crossflashed m1015. Pool is a zfs mirror. Works fine booting from r246300 kernel. Motherboard is an AMD Tyan. Pulling USB headers off the board didn't resolve it. Matt From owner-freebsd-current@FreeBSD.ORG Thu Feb 21 07:05:57 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 4B7DAB05; Thu, 21 Feb 2013 07:05:57 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 232F6152F; Thu, 21 Feb 2013 07:05:56 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r1L75uVZ086639; Thu, 21 Feb 2013 02:05:56 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r1L75uG3086634; Thu, 21 Feb 2013 07:05:56 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 21 Feb 2013 07:05:56 GMT Message-Id: <201302210705.r1L75uG3086634@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 , , Subject: [head tinderbox] failure on i386/i386 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 07:05:57 -0000 TB --- 2013-02-21 04:10:20 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-02-21 04:10:20 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-02-21 04:10:20 - starting HEAD tinderbox run for i386/i386 TB --- 2013-02-21 04:10:20 - cleaning the object tree TB --- 2013-02-21 04:10:20 - /usr/local/bin/svn stat /src TB --- 2013-02-21 04:10:24 - At svn revision 247073 TB --- 2013-02-21 04:10:25 - building world TB --- 2013-02-21 04:10:25 - CROSS_BUILD_TESTING=YES TB --- 2013-02-21 04:10:25 - MAKEOBJDIRPREFIX=/obj TB --- 2013-02-21 04:10:25 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-02-21 04:10:25 - SRCCONF=/dev/null TB --- 2013-02-21 04:10:25 - TARGET=i386 TB --- 2013-02-21 04:10:25 - TARGET_ARCH=i386 TB --- 2013-02-21 04:10:25 - TZ=UTC TB --- 2013-02-21 04:10:25 - __MAKE_CONF=/dev/null TB --- 2013-02-21 04:10:25 - cd /src TB --- 2013-02-21 04:10:25 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Thu Feb 21 04:10:30 UTC 2013 >>> 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 Thu Feb 21 06:55:18 UTC 2013 TB --- 2013-02-21 06:55:18 - generating LINT kernel config TB --- 2013-02-21 06:55:18 - cd /src/sys/i386/conf TB --- 2013-02-21 06:55:18 - /usr/bin/make -B LINT TB --- 2013-02-21 06:55:18 - cd /src/sys/i386/conf TB --- 2013-02-21 06:55:18 - /usr/sbin/config -m LINT TB --- 2013-02-21 06:55:18 - building LINT kernel TB --- 2013-02-21 06:55:18 - CROSS_BUILD_TESTING=YES TB --- 2013-02-21 06:55:18 - MAKEOBJDIRPREFIX=/obj TB --- 2013-02-21 06:55:18 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-02-21 06:55:18 - SRCCONF=/dev/null TB --- 2013-02-21 06:55:18 - TARGET=i386 TB --- 2013-02-21 06:55:18 - TARGET_ARCH=i386 TB --- 2013-02-21 06:55:18 - TZ=UTC TB --- 2013-02-21 06:55:18 - __MAKE_CONF=/dev/null TB --- 2013-02-21 06:55:18 - cd /src TB --- 2013-02-21 06:55:18 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Feb 21 06:55:18 UTC 2013 >>> 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 -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -DGPROF -DGPROF4 -DGUPROF -fno-builtin -mno-aes -mno-avx -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -Werror -pg /src/sys/dev/ppc/ppc.c /src/sys/dev/ppc/ppc.c:724:2: error: implicit declaration of function 'critical_leave' is invalid in C99 [-Werror,-Wimplicit-function-declaration] PPC_CONFIG_UNLOCK(ppc); ^ /src/sys/dev/ppc/ppc.c:91:33: note: expanded from macro 'PPC_CONFIG_UNLOCK' #define PPC_CONFIG_UNLOCK(ppc) critical_leave() ^ 1 error generated. *** [ppc.o] Error code 1 Stop in /obj/i386.i386/src/sys/LINT. *** [buildkernel] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-02-21 07:05:56 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-02-21 07:05:56 - ERROR: failed to build LINT kernel TB --- 2013-02-21 07:05:56 - 8486.48 user 1311.22 system 10535.43 real http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Thu Feb 21 07:39:21 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 9099F884; Thu, 21 Feb 2013 07:39: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 6691E188D; Thu, 21 Feb 2013 07:39:21 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r1L7dKoL087076; Thu, 21 Feb 2013 02:39:20 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r1L7dKLN087057; Thu, 21 Feb 2013 07:39:20 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 21 Feb 2013 07:39:20 GMT Message-Id: <201302210739.r1L7dKLN087057@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 , , Subject: [head tinderbox] failure on amd64/amd64 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 07:39:21 -0000 TB --- 2013-02-21 04:10:20 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-02-21 04:10:20 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-02-21 04:10:20 - starting HEAD tinderbox run for amd64/amd64 TB --- 2013-02-21 04:10:20 - cleaning the object tree TB --- 2013-02-21 04:10:20 - /usr/local/bin/svn stat /src TB --- 2013-02-21 04:10:24 - At svn revision 247073 TB --- 2013-02-21 04:10:25 - building world TB --- 2013-02-21 04:10:25 - CROSS_BUILD_TESTING=YES TB --- 2013-02-21 04:10:25 - MAKEOBJDIRPREFIX=/obj TB --- 2013-02-21 04:10:25 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-02-21 04:10:25 - SRCCONF=/dev/null TB --- 2013-02-21 04:10:25 - TARGET=amd64 TB --- 2013-02-21 04:10:25 - TARGET_ARCH=amd64 TB --- 2013-02-21 04:10:25 - TZ=UTC TB --- 2013-02-21 04:10:25 - __MAKE_CONF=/dev/null TB --- 2013-02-21 04:10:25 - cd /src TB --- 2013-02-21 04:10:25 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Thu Feb 21 04:10:30 UTC 2013 >>> 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 Thu Feb 21 07:28:27 UTC 2013 TB --- 2013-02-21 07:28:27 - generating LINT kernel config TB --- 2013-02-21 07:28:27 - cd /src/sys/amd64/conf TB --- 2013-02-21 07:28:27 - /usr/bin/make -B LINT TB --- 2013-02-21 07:28:27 - cd /src/sys/amd64/conf TB --- 2013-02-21 07:28:27 - /usr/sbin/config -m LINT TB --- 2013-02-21 07:28:27 - building LINT kernel TB --- 2013-02-21 07:28:27 - CROSS_BUILD_TESTING=YES TB --- 2013-02-21 07:28:27 - MAKEOBJDIRPREFIX=/obj TB --- 2013-02-21 07:28:27 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-02-21 07:28:27 - SRCCONF=/dev/null TB --- 2013-02-21 07:28:27 - TARGET=amd64 TB --- 2013-02-21 07:28:27 - TARGET_ARCH=amd64 TB --- 2013-02-21 07:28:27 - TZ=UTC TB --- 2013-02-21 07:28:27 - __MAKE_CONF=/dev/null TB --- 2013-02-21 07:28:27 - cd /src TB --- 2013-02-21 07:28:27 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Feb 21 07:28:27 UTC 2013 >>> 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 -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -DGPROF -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mno-aes -mno-avx -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg /src/sys/dev/ppc/ppc.c /src/sys/dev/ppc/ppc.c:724:2: error: implicit declaration of function 'critical_leave' is invalid in C99 [-Werror,-Wimplicit-function-declaration] PPC_CONFIG_UNLOCK(ppc); ^ /src/sys/dev/ppc/ppc.c:91:33: note: expanded from macro 'PPC_CONFIG_UNLOCK' #define PPC_CONFIG_UNLOCK(ppc) critical_leave() ^ 1 error generated. *** [ppc.o] Error code 1 Stop in /obj/amd64.amd64/src/sys/LINT. *** [buildkernel] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-02-21 07:39:20 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-02-21 07:39:20 - ERROR: failed to build LINT kernel TB --- 2013-02-21 07:39:20 - 9819.45 user 1699.91 system 12539.96 real http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-amd64-amd64.full From owner-freebsd-current@FreeBSD.ORG Thu Feb 21 08:35:36 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id DDA7B43F; Thu, 21 Feb 2013 08:35:36 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from anubis.delphij.net (anubis.delphij.net [IPv6:2001:470:1:117::25]) by mx1.freebsd.org (Postfix) with ESMTP id C1DAA1A7C; Thu, 21 Feb 2013 08:35:36 +0000 (UTC) Received: from Xins-MacBook-Pro-2.local (c-67-188-85-47.hsd1.ca.comcast.net [67.188.85.47]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by anubis.delphij.net (Postfix) with ESMTPSA id 2F77D241A8; Thu, 21 Feb 2013 00:35:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=delphij.net; s=anubis; t=1361435736; bh=RIVQev+5aXSEe6iQ3ZWibPYA0N1awQIDiTEis7G0GxY=; h=Date:From:Reply-To:To:CC:Subject:References:In-Reply-To; b=Tix9IsgSla2RpePVJqTGtLZHf7zM6KW0fS77kJEIby9ACgJdbjAVOAUvt1RjnPd5p oKfv0fMgRN4wOKQWqRtl7Fg/MlBxcY9aUAjH/ELPMarQDc7miHwwcMwuISBJH8jlds /nQYph8+k5ZQTN0fwciRf8sX2UY2nWI8hCi3pAVE= Message-ID: <5125DC57.2050909@delphij.net> Date: Thu, 21 Feb 2013 00:35:35 -0800 From: Xin Li Organization: The FreeBSD Project MIME-Version: 1.0 To: Andriy Gapon Subject: Re: -CURRENT userland regression References: <51254ACE.2030100@delphij.net> <51254C7E.9050705@gmail.com> <20130220222518.GT2598@kib.kiev.ua> <51254E51.1070702@delphij.net> <20130220223704.GU2598@kib.kiev.ua> <5125595D.5010508@delphij.net> <5125D8A6.2050409@FreeBSD.org> In-Reply-To: <5125D8A6.2050409@FreeBSD.org> X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Konstantin Belousov , FreeBSD Current , d@delphij.net, Navdeep Parhar X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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: Thu, 21 Feb 2013 08:35:36 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2/21/13 12:19 AM, Andriy Gapon wrote: > on 21/02/2013 01:16 Xin Li said the following: >> I think it's unlikely -- I have r247057 of sys/ which worked >> fine... >> >> userland 246957 works good by the way. > > Just a very wild guess - are you sure that it is the userland that > is to blame? It is rather unfortunate that we install boot blocks, > including loader which gets _really_ installed, as part of > installworld (and they are built as part of buildworld). So there > is a possibility that it is loader that causes the trouble. I > would try to rule that out. Since loader is in /sys/ which I have updated to -HEAD and done a full buildworld/buildkernel cycle, can I rule loader out, or did I missed something? (my experiment was to update src/ to a certain revision, then update src/sys/ to latest, then a full buildworld buildkernel) I do not have console access and had some other tasks yesterday so I didn't continue the tests further but will do it today. Cheers, -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJRJdxXAAoJEG80Jeu8UPuz8TEIALTGsoH7tbTOk7Hh3QJPeuHc PU3VLWo7fb3puoPnQXu1eAlTuAjXGpw2+3ITjgmunGWWpN2ABeFGIauIPk7RAWLV E6/c/EpTfFNDWG0KoSDGJnDoTQ1KO9zp17Gp6KfaVYL3MLYEo/tNXWUBfdfg0ddv 4dNocl34GvPK4LXonIw+oBy2ha5MkzL4BARGP2QgYsv07uMk0MZ8fUSngmQFCiaD LpOVe/mPoBc5GmBI7TZENBN/g9mMVNVu9gZXvQronnw52N3wNxIxy7jmWdv5uLUf PXOjLrx930d88tN3HOjgtxrwbZBRyIJUdckbhXthpezlMsy81vWfn2+x9agG+mk= =9OlU -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Thu Feb 21 12:09:32 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 8936015B7; Thu, 21 Feb 2013 12:09:32 +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 60FEF17A; Thu, 21 Feb 2013 12:09:32 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r1LAUMvj093899; Thu, 21 Feb 2013 05:30:22 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r1LAUMkd093898; Thu, 21 Feb 2013 10:30:22 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 21 Feb 2013 10:30:22 GMT Message-Id: <201302211030.r1LAUMkd093898@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 , , Subject: [head tinderbox] failure on sparc64/sparc64 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 12:09:32 -0000 TB --- 2013-02-21 09:15:47 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-02-21 09:15:47 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-02-21 09:15:47 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2013-02-21 09:15:47 - cleaning the object tree TB --- 2013-02-21 09:15:47 - /usr/local/bin/svn stat /src TB --- 2013-02-21 09:15:50 - At svn revision 247073 TB --- 2013-02-21 09:15:51 - building world TB --- 2013-02-21 09:15:51 - CROSS_BUILD_TESTING=YES TB --- 2013-02-21 09:15:51 - MAKEOBJDIRPREFIX=/obj TB --- 2013-02-21 09:15:51 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-02-21 09:15:51 - SRCCONF=/dev/null TB --- 2013-02-21 09:15:51 - TARGET=sparc64 TB --- 2013-02-21 09:15:51 - TARGET_ARCH=sparc64 TB --- 2013-02-21 09:15:51 - TZ=UTC TB --- 2013-02-21 09:15:51 - __MAKE_CONF=/dev/null TB --- 2013-02-21 09:15:51 - cd /src TB --- 2013-02-21 09:15:51 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Thu Feb 21 09:15:56 UTC 2013 >>> 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 Thu Feb 21 10:17:36 UTC 2013 TB --- 2013-02-21 10:17:36 - generating LINT kernel config TB --- 2013-02-21 10:17:36 - cd /src/sys/sparc64/conf TB --- 2013-02-21 10:17:36 - /usr/bin/make -B LINT TB --- 2013-02-21 10:17:36 - cd /src/sys/sparc64/conf TB --- 2013-02-21 10:17:36 - /usr/sbin/config -m LINT TB --- 2013-02-21 10:17:36 - building LINT kernel TB --- 2013-02-21 10:17:36 - CROSS_BUILD_TESTING=YES TB --- 2013-02-21 10:17:36 - MAKEOBJDIRPREFIX=/obj TB --- 2013-02-21 10:17:36 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-02-21 10:17:36 - SRCCONF=/dev/null TB --- 2013-02-21 10:17:36 - TARGET=sparc64 TB --- 2013-02-21 10:17:36 - TARGET_ARCH=sparc64 TB --- 2013-02-21 10:17:36 - TZ=UTC TB --- 2013-02-21 10:17:36 - __MAKE_CONF=/dev/null TB --- 2013-02-21 10:17:36 - cd /src TB --- 2013-02-21 10:17:36 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Feb 21 10:17:36 UTC 2013 >>> 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 -fdiagnostics-show-option -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/pci/amdsmb.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 -fdiagnostics-show-option -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/pci/if_rl.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 -fdiagnostics-show-option -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/pci/intpm.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 -fdiagnostics-show-option -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/pci/ncr.c /src/sys/pci/ncr.c: In function 'ncr_get_nccb': /src/sys/pci/ncr.c:6428: error: 's' undeclared (first use in this function) /src/sys/pci/ncr.c:6428: error: (Each undeclared identifier is reported only once /src/sys/pci/ncr.c:6428: error: for each function it appears in.) *** [ncr.o] Error code 1 Stop in /obj/sparc64.sparc64/src/sys/LINT. *** [buildkernel] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-02-21 10:30:22 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-02-21 10:30:22 - ERROR: failed to build LINT kernel TB --- 2013-02-21 10:30:22 - 3742.72 user 611.54 system 4475.48 real http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Thu Feb 21 12:09:33 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 0648815B9; Thu, 21 Feb 2013 12:09:33 +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 BA1E717D; Thu, 21 Feb 2013 12:09:32 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r1LAXnYp096736; Thu, 21 Feb 2013 05:33:49 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r1LAXn3d096735; Thu, 21 Feb 2013 10:33:49 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 21 Feb 2013 10:33:49 GMT Message-Id: <201302211033.r1LAXn3d096735@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 , , Subject: [head tinderbox] failure on powerpc/powerpc Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 12:09:33 -0000 TB --- 2013-02-21 08:00:29 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-02-21 08:00:29 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-02-21 08:00:29 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2013-02-21 08:00:29 - cleaning the object tree TB --- 2013-02-21 08:00:29 - /usr/local/bin/svn stat /src TB --- 2013-02-21 08:00:32 - At svn revision 247073 TB --- 2013-02-21 08:00:33 - building world TB --- 2013-02-21 08:00:33 - CROSS_BUILD_TESTING=YES TB --- 2013-02-21 08:00:33 - MAKEOBJDIRPREFIX=/obj TB --- 2013-02-21 08:00:33 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-02-21 08:00:33 - SRCCONF=/dev/null TB --- 2013-02-21 08:00:33 - TARGET=powerpc TB --- 2013-02-21 08:00:33 - TARGET_ARCH=powerpc TB --- 2013-02-21 08:00:33 - TZ=UTC TB --- 2013-02-21 08:00:33 - __MAKE_CONF=/dev/null TB --- 2013-02-21 08:00:33 - cd /src TB --- 2013-02-21 08:00:33 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Thu Feb 21 08:00:38 UTC 2013 >>> 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 Thu Feb 21 10:24:38 UTC 2013 TB --- 2013-02-21 10:24:38 - generating LINT kernel config TB --- 2013-02-21 10:24:38 - cd /src/sys/powerpc/conf TB --- 2013-02-21 10:24:38 - /usr/bin/make -B LINT TB --- 2013-02-21 10:24:38 - cd /src/sys/powerpc/conf TB --- 2013-02-21 10:24:38 - /usr/sbin/config -m LINT TB --- 2013-02-21 10:24:38 - building LINT kernel TB --- 2013-02-21 10:24:38 - CROSS_BUILD_TESTING=YES TB --- 2013-02-21 10:24:38 - MAKEOBJDIRPREFIX=/obj TB --- 2013-02-21 10:24:38 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-02-21 10:24:38 - SRCCONF=/dev/null TB --- 2013-02-21 10:24:38 - TARGET=powerpc TB --- 2013-02-21 10:24:38 - TARGET_ARCH=powerpc TB --- 2013-02-21 10:24:38 - TZ=UTC TB --- 2013-02-21 10:24:38 - __MAKE_CONF=/dev/null TB --- 2013-02-21 10:24:38 - cd /src TB --- 2013-02-21 10:24:38 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Feb 21 10:24:38 UTC 2013 >>> 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 -O -pipe -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 -fdiagnostics-show-option -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 -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/pci/amdsmb.c cc -c -O -pipe -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 -fdiagnostics-show-option -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 -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/pci/if_rl.c cc -c -O -pipe -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 -fdiagnostics-show-option -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 -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/pci/intpm.c cc -c -O -pipe -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 -fdiagnostics-show-option -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 -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/pci/ncr.c /src/sys/pci/ncr.c: In function 'ncr_get_nccb': /src/sys/pci/ncr.c:6428: error: 's' undeclared (first use in this function) /src/sys/pci/ncr.c:6428: error: (Each undeclared identifier is reported only once /src/sys/pci/ncr.c:6428: error: for each function it appears in.) *** [ncr.o] Error code 1 Stop in /obj/powerpc.powerpc/src/sys/LINT. *** [buildkernel] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-02-21 10:33:49 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-02-21 10:33:49 - ERROR: failed to build LINT kernel TB --- 2013-02-21 10:33:49 - 7734.03 user 1011.88 system 9199.66 real http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Thu Feb 21 12:09:33 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 5E9D315BC; Thu, 21 Feb 2013 12:09:33 +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 374BB180; Thu, 21 Feb 2013 12:09:33 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r1L98DOr054271; Thu, 21 Feb 2013 04:08:13 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r1L98DnT054267; Thu, 21 Feb 2013 09:08:13 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 21 Feb 2013 09:08:13 GMT Message-Id: <201302210908.r1L98DnT054267@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 , , Subject: [head tinderbox] failure on i386/pc98 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 12:09:33 -0000 TB --- 2013-02-21 06:05:47 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-02-21 06:05:47 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-02-21 06:05:47 - starting HEAD tinderbox run for i386/pc98 TB --- 2013-02-21 06:05:47 - cleaning the object tree TB --- 2013-02-21 06:05:47 - /usr/local/bin/svn stat /src TB --- 2013-02-21 06:05:53 - At svn revision 247073 TB --- 2013-02-21 06:05:54 - building world TB --- 2013-02-21 06:05:54 - CROSS_BUILD_TESTING=YES TB --- 2013-02-21 06:05:54 - MAKEOBJDIRPREFIX=/obj TB --- 2013-02-21 06:05:54 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-02-21 06:05:54 - SRCCONF=/dev/null TB --- 2013-02-21 06:05:54 - TARGET=pc98 TB --- 2013-02-21 06:05:54 - TARGET_ARCH=i386 TB --- 2013-02-21 06:05:54 - TZ=UTC TB --- 2013-02-21 06:05:54 - __MAKE_CONF=/dev/null TB --- 2013-02-21 06:05:54 - cd /src TB --- 2013-02-21 06:05:54 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Thu Feb 21 06:05:58 UTC 2013 >>> 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 Thu Feb 21 09:00:17 UTC 2013 TB --- 2013-02-21 09:00:17 - generating LINT kernel config TB --- 2013-02-21 09:00:17 - cd /src/sys/pc98/conf TB --- 2013-02-21 09:00:17 - /usr/bin/make -B LINT TB --- 2013-02-21 09:00:17 - cd /src/sys/pc98/conf TB --- 2013-02-21 09:00:17 - /usr/sbin/config -m LINT TB --- 2013-02-21 09:00:17 - building LINT kernel TB --- 2013-02-21 09:00:17 - CROSS_BUILD_TESTING=YES TB --- 2013-02-21 09:00:17 - MAKEOBJDIRPREFIX=/obj TB --- 2013-02-21 09:00:17 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-02-21 09:00:17 - SRCCONF=/dev/null TB --- 2013-02-21 09:00:17 - TARGET=pc98 TB --- 2013-02-21 09:00:17 - TARGET_ARCH=i386 TB --- 2013-02-21 09:00:17 - TZ=UTC TB --- 2013-02-21 09:00:17 - __MAKE_CONF=/dev/null TB --- 2013-02-21 09:00:17 - cd /src TB --- 2013-02-21 09:00:17 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Feb 21 09:00:17 UTC 2013 >>> 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 -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -DGPROF -DGPROF4 -DGUPROF -fno-builtin -mno-aes -mno-avx -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -Werror -pg /src/sys/dev/ppc/ppc.c /src/sys/dev/ppc/ppc.c:724:2: error: implicit declaration of function 'critical_leave' is invalid in C99 [-Werror,-Wimplicit-function-declaration] PPC_CONFIG_UNLOCK(ppc); ^ /src/sys/dev/ppc/ppc.c:91:33: note: expanded from macro 'PPC_CONFIG_UNLOCK' #define PPC_CONFIG_UNLOCK(ppc) critical_leave() ^ 1 error generated. *** [ppc.o] Error code 1 Stop in /obj/pc98.i386/src/sys/LINT. *** [buildkernel] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-02-21 09:08:13 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-02-21 09:08:13 - ERROR: failed to build LINT kernel TB --- 2013-02-21 09:08:13 - 8612.45 user 1321.82 system 10945.53 real http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Thu Feb 21 12:09:33 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id D43B815BF; Thu, 21 Feb 2013 12:09:33 +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 8FEBC181; Thu, 21 Feb 2013 12:09:33 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r1L80TPm008640; Thu, 21 Feb 2013 03:00:29 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r1L80TbR008639; Thu, 21 Feb 2013 08:00:29 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 21 Feb 2013 08:00:29 GMT Message-Id: <201302210800.r1L80TbR008639@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 , , Subject: [head tinderbox] failure on ia64/ia64 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 12:09:33 -0000 TB --- 2013-02-21 06:17:25 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-02-21 06:17:25 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-02-21 06:17:25 - starting HEAD tinderbox run for ia64/ia64 TB --- 2013-02-21 06:17:25 - cleaning the object tree TB --- 2013-02-21 06:17:25 - /usr/local/bin/svn stat /src TB --- 2013-02-21 06:17:28 - At svn revision 247073 TB --- 2013-02-21 06:17:29 - building world TB --- 2013-02-21 06:17:29 - CROSS_BUILD_TESTING=YES TB --- 2013-02-21 06:17:29 - MAKEOBJDIRPREFIX=/obj TB --- 2013-02-21 06:17:29 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-02-21 06:17:29 - SRCCONF=/dev/null TB --- 2013-02-21 06:17:29 - TARGET=ia64 TB --- 2013-02-21 06:17:29 - TARGET_ARCH=ia64 TB --- 2013-02-21 06:17:29 - TZ=UTC TB --- 2013-02-21 06:17:29 - __MAKE_CONF=/dev/null TB --- 2013-02-21 06:17:29 - cd /src TB --- 2013-02-21 06:17:29 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Thu Feb 21 06:17:33 UTC 2013 >>> 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 Thu Feb 21 07:50:56 UTC 2013 TB --- 2013-02-21 07:50:56 - generating LINT kernel config TB --- 2013-02-21 07:50:56 - cd /src/sys/ia64/conf TB --- 2013-02-21 07:50:56 - /usr/bin/make -B LINT TB --- 2013-02-21 07:50:56 - cd /src/sys/ia64/conf TB --- 2013-02-21 07:50:56 - /usr/sbin/config -m LINT TB --- 2013-02-21 07:50:56 - building LINT kernel TB --- 2013-02-21 07:50:56 - CROSS_BUILD_TESTING=YES TB --- 2013-02-21 07:50:56 - MAKEOBJDIRPREFIX=/obj TB --- 2013-02-21 07:50:56 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-02-21 07:50:56 - SRCCONF=/dev/null TB --- 2013-02-21 07:50:56 - TARGET=ia64 TB --- 2013-02-21 07:50:56 - TARGET_ARCH=ia64 TB --- 2013-02-21 07:50:56 - TZ=UTC TB --- 2013-02-21 07:50:56 - __MAKE_CONF=/dev/null TB --- 2013-02-21 07:50:56 - cd /src TB --- 2013-02-21 07:50:56 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Feb 21 07:50:56 UTC 2013 >>> 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 -fdiagnostics-show-option -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/ppbus/pps.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 -fdiagnostics-show-option -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/ppbus/vpo.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 -fdiagnostics-show-option -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/ppbus/vpoio.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 -fdiagnostics-show-option -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/ppc/ppc.c cc1: warnings being treated as errors /src/sys/dev/ppc/ppc.c: In function 'ppc_smc37c66xgt_detect': /src/sys/dev/ppc/ppc.c:724: warning: implicit declaration of function 'critical_leave' /src/sys/dev/ppc/ppc.c:724: warning: nested extern declaration of 'critical_leave' [-Wnested-externs] *** [ppc.o] Error code 1 Stop in /obj/ia64.ia64/src/sys/LINT. *** [buildkernel] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-02-21 08:00:29 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-02-21 08:00:29 - ERROR: failed to build LINT kernel TB --- 2013-02-21 08:00:29 - 4879.34 user 961.57 system 6184.41 real http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Thu Feb 21 12:09:37 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 586071732; Thu, 21 Feb 2013 12:09:37 +0000 (UTC) (envelope-from lars@netapp.com) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) by mx1.freebsd.org (Postfix) with ESMTP id 3C1B4187; Thu, 21 Feb 2013 12:09:37 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.84,706,1355126400"; d="scan'208";a="24810091" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx12-out.netapp.com with ESMTP; 21 Feb 2013 01:12:25 -0800 Received: from vmwexceht01-prd.hq.netapp.com (exchsmtp.hq.netapp.com [10.106.76.239]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id r1L9COGo024310; Thu, 21 Feb 2013 01:12:24 -0800 (PST) Received: from SACEXCMBX01-PRD.hq.netapp.com ([169.254.2.54]) by vmwexceht01-prd.hq.netapp.com ([10.106.76.239]) with mapi id 14.02.0328.009; Thu, 21 Feb 2013 01:12:22 -0800 From: "Eggert, Lars" To: Andriy Gapon Subject: Re: Dtrace: Module is no longer loaded Thread-Topic: Dtrace: Module is no longer loaded Thread-Index: AQHNtcLm1S6KYZ4TpEy+jQm/JkH2r5fQtzwAgAAZWQCAAAQdgIAAChUAgLGLo4CAABStgIACwpkA Date: Thu, 21 Feb 2013 09:12:21 +0000 Message-ID: References: <508E98E1.7010502@FreeBSD.org> <51239437.2020503@FreeBSD.org> In-Reply-To: <51239437.2020503@FreeBSD.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.106.53.51] Content-Type: text/plain; charset="us-ascii" Content-ID: <98C127390179C44E91A002EC6AE91946@tahoe.netapp.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Monthadar Al Jaberi , freebsd-current , Ryan Stone X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 21 Feb 2013 12:09:37 -0000 Hi, On Feb 19, 2013, at 16:03, Andriy Gapon wrote: > Couple of thoughts: > - is your kernel installed in the typical location? yup. > - what does the following produce? > readelf -a -W /boot/kernel/kernel | fgrep shstrtab > readelf -a -W /boot/kernel/kernel | fgrep SUNW_ctf # readelf -a -W /boot/kernel/kernel | fgrep shstrtab [24] .shstrtab STRTAB 0000000000000000 7975ee 000124 00 = 0 0 1 # readelf -a -W /boot/kernel/kernel | fgrep SUNW_ctf [22] .SUNW_ctf PROGBITS 0000000000000000 74ed68 048872 00 = 0 0 4 And then: # dtrace -n 'syscall:::' dtrace: invalid probe specifier syscall:::: "/usr/lib/dtrace/psinfo.d", lin= e 90: failed to resolve type kernel`struct thread * for identifier curthrea= d: Module is no longer loaded Lars= From owner-freebsd-current@FreeBSD.ORG Thu Feb 21 12:10:17 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 543CB1E76 for ; Thu, 21 Feb 2013 12:10: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 981F21E4 for ; Thu, 21 Feb 2013 12:10:16 +0000 (UTC) Received: from porto.starpoint.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 KAA04251; Thu, 21 Feb 2013 10:19:49 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1U8RNd-000FGQ-C7; Thu, 21 Feb 2013 10:19:49 +0200 Message-ID: <5125D8A6.2050409@FreeBSD.org> Date: Thu, 21 Feb 2013 10:19:50 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130220 Thunderbird/17.0.3 MIME-Version: 1.0 To: d@delphij.net Subject: Re: -CURRENT userland regression References: <51254ACE.2030100@delphij.net> <51254C7E.9050705@gmail.com> <20130220222518.GT2598@kib.kiev.ua> <51254E51.1070702@delphij.net> <20130220223704.GU2598@kib.kiev.ua> <5125595D.5010508@delphij.net> In-Reply-To: <5125595D.5010508@delphij.net> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Konstantin Belousov , FreeBSD Current , Xin Li , Navdeep Parhar X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 21 Feb 2013 12:10:17 -0000 on 21/02/2013 01:16 Xin Li said the following: > I think it's unlikely -- I have r247057 of sys/ which worked fine... > > userland 246957 works good by the way. Just a very wild guess - are you sure that it is the userland that is to blame? It is rather unfortunate that we install boot blocks, including loader which gets _really_ installed, as part of installworld (and they are built as part of buildworld). So there is a possibility that it is loader that causes the trouble. I would try to rule that out. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Thu Feb 21 12:32:16 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 7E96233C; Thu, 21 Feb 2013 12:32:16 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-da0-f45.google.com (mail-da0-f45.google.com [209.85.210.45]) by mx1.freebsd.org (Postfix) with ESMTP id BFB25A86; Thu, 21 Feb 2013 12:32:15 +0000 (UTC) Received: by mail-da0-f45.google.com with SMTP id v40so598255dad.4 for ; Thu, 21 Feb 2013 04:32:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:date:to:cc:subject:message-id:reply-to:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=TN7qinlqIdggKmAPkJpBigiMw7NOiibUIFKx/hlJWMI=; b=pBK+h5gnceSMXqfSZewZWARh9gmfUlfCscnPByFi9GYCB50F/zR4SC1szcQ8iOA4Sy EJcoOcUvL4mXljq8noIVw5p71713VTyWemsQbRn7o1OB3GO8EQMJOGIZ1GSK/WS8LTdC 3DF3NWP1iEjZ+J6mtezgLjolzoxmfswjaMbWCF5+9FtWOr8J3U/aDQMox+5XCuI+khdM FoVvREXMqvCGx1MbB/idU7PuzjYda4waPBvXRvzf6TmpIPqoTn4vlRc5W1TT91Y0JCWM Egiz7Ynq/1qXyLEIQ9ERZR6BWSMk2b7thoiWImjdJqd9Ut3Dg2FZhFb5IPSrgTbrc63h b7Gw== X-Received: by 10.68.227.202 with SMTP id sc10mr53788982pbc.109.1361435626165; Thu, 21 Feb 2013 00:33:46 -0800 (PST) Received: from pyunyh@gmail.com (lpe4.p59-icn.cdngp.net. [114.111.62.249]) by mx.google.com with ESMTPS id a4sm114276901paw.21.2013.02.21.00.33.42 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 21 Feb 2013 00:33:44 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Thu, 21 Feb 2013 17:33:35 +0900 From: YongHyeon PYUN Date: Thu, 21 Feb 2013 17:33:35 +0900 To: Alexey Dokuchaev Subject: Re: ale(4) cannot negotiate as GigE Message-ID: <20130221083335.GA3226@michelle.cdnetworks.com> References: <20130219082302.GA86501@FreeBSD.org> <20130220043739.GA1469@michelle.cdnetworks.com> <20130220060853.GA83110@FreeBSD.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="8t9RHnE3ZwKMSgU+" Content-Disposition: inline In-Reply-To: <20130220060853.GA83110@FreeBSD.org> User-Agent: Mutt/1.4.2.3i Cc: current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 12:32:16 -0000 --8t9RHnE3ZwKMSgU+ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Wed, Feb 20, 2013 at 06:08:53AM +0000, Alexey Dokuchaev wrote: > On Wed, Feb 20, 2013 at 01:37:39PM +0900, YongHyeon PYUN wrote: > > On Tue, Feb 19, 2013 at 08:23:02AM +0000, Alexey Dokuchaev wrote: > > > ale0@pci0:2:0:0: class=0x020000 card=0x82261043 chip=0x10261969 > > > rev=0xb0 hdr=0x00 > > > vendor = 'Atheros Communications Inc.' > > > device = 'AR8121/AR8113/AR8114 Gigabit or Fast Ethernet' > > > class = network > > > subclass = ethernet > > > > > > According the the specs, it should be GigE. [...] > > > > There is a fast etherenet version(L2E) so I'm not sure what you > > have. Could you show me dmesg output(ale(4) & atphy(4) only) and > > "devinfo -rv | grep atphy"? > > $ dmesg | egrep ale\|atphy > ale0: port 0xcc00-0xcc7f mem 0xfe9c0000-0xfe9fffff irq 17 at device 0.0 on pci2 > ale0: 960 Tx FIFO, 1024 Rx FIFO > ale0: Using 1 MSI messages. > ale0: 4GB boundary crossed, switching to 32bit DMA addressing mode. > miibus0: on ale0 > atphy0: PHY 0 on miibus0 > atphy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow > > $ devinfo -rv | grep atphy > atphy0 pnpinfo oui=0xc82e model=0x1 rev=0x9 at phyno=0 Hmm, it's still not clear whether the controller is Gigabit or not. Could you try attached patch and let me the output? > > > > I'm not sure why it happens; maybe it's somehow related to a handful of > > > those "ale0: link state changed to DOWN/UP" flip-flops I see in dmesg(8), > > > before it can finally obtain DHCP lease? > > > > That's normal when you initiate auto-negotiation with dhclient. > > Yes, I've already seen your lengthy explanation [1], thanks! > > > > I remember these adapters had problems in the past, like infamous > > > "Corrupted MAC on input" disconnect messages, but I don't recall that I > > > could not use it in GigE mode. [...] > > > > If you still see the "Corrupted MAC on input" message, let me know. > > No, those are long gone now (hopefully; at least I haven't seen them for a > while). > > ./danfe > > [1] http://lists.freebsd.org/pipermail/freebsd-net/2009-January/020662.html --8t9RHnE3ZwKMSgU+ Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="ale.pr.diff" Index: sys/dev/ale/if_ale.c =================================================================== --- sys/dev/ale/if_ale.c (revision 246937) +++ sys/dev/ale/if_ale.c (working copy) @@ -497,6 +497,9 @@ ale_attach(device_t dev) sc->ale_flags |= ALE_FLAG_FASTETHER; } } +#if 1 + printf("ale_flags = 0x%08x\n", sc->ale_flags); +#endif /* * All known controllers seems to require 4 bytes alignment * of Tx buffers to make Tx checksum offload with custom --8t9RHnE3ZwKMSgU+-- From owner-freebsd-current@FreeBSD.ORG Thu Feb 21 12:43:44 2013 Return-Path: Delivered-To: current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1033) id 84E99EA8; Thu, 21 Feb 2013 12:43:44 +0000 (UTC) Date: Thu, 21 Feb 2013 12:43:44 +0000 From: Alexey Dokuchaev To: YongHyeon PYUN Subject: Re: ale(4) cannot negotiate as GigE Message-ID: <20130221124344.GA93056@FreeBSD.org> References: <20130219082302.GA86501@FreeBSD.org> <20130220043739.GA1469@michelle.cdnetworks.com> <20130220060853.GA83110@FreeBSD.org> <20130221083335.GA3226@michelle.cdnetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20130221083335.GA3226@michelle.cdnetworks.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 21 Feb 2013 12:43:44 -0000 On Thu, Feb 21, 2013 at 05:33:35PM +0900, YongHyeon PYUN wrote: > On Wed, Feb 20, 2013 at 06:08:53AM +0000, Alexey Dokuchaev wrote: > > $ dmesg | egrep ale\|atphy > > ale0: port 0xcc00-0xcc7f mem 0xfe9c0000-0xfe9fffff irq 17 at device 0.0 on pci2 > > ale0: 960 Tx FIFO, 1024 Rx FIFO > > ale0: Using 1 MSI messages. > > ale0: 4GB boundary crossed, switching to 32bit DMA addressing mode. > > miibus0: on ale0 > > atphy0: PHY 0 on miibus0 > > atphy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow > > > > $ devinfo -rv | grep atphy > > atphy0 pnpinfo oui=0xc82e model=0x1 rev=0x9 at phyno=0 > > Hmm, it's still not clear whether the controller is Gigabit or not. > Could you try attached patch and let me the output? ale_flags = 0x00000040 ./danfe From owner-freebsd-current@FreeBSD.ORG Thu Feb 21 12:53:59 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 9806867D; Thu, 21 Feb 2013 12:53:59 +0000 (UTC) (envelope-from onwahe@gmail.com) Received: from mail-qa0-f45.google.com (mail-qa0-f45.google.com [209.85.216.45]) by mx1.freebsd.org (Postfix) with ESMTP id 4BDCFEE4; Thu, 21 Feb 2013 12:53:59 +0000 (UTC) Received: by mail-qa0-f45.google.com with SMTP id g10so2990091qah.11 for ; Thu, 21 Feb 2013 04:53:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=8ieSc1/MgBKIH59NOiSo1nDzPVTC87KTUCemI1STF6k=; b=VnsAp+PCfT1jYYA8MVYDIucMtQU4SjsiVIZwdsJ0iCanMlU1gDqA48ICSndS5NuZB2 agBN6gcSl9hIyl6Ced24erS2hNwqvusQk9egM0IvOIKm59U8A1SaKMFxjDDUZAb1lT3/ mCaWPMSJXfyLDcMlAAAzmF/NLdKnQQoKMWHOojkUOgXXkT2TL5NLzeb3NMMVsGqSU2Ua GtHAh1fMbcLtbGNID7cv9B0JFBH14nQqpfNCbDj+Z1Nx16OXZi1f2c6kHGyr9QrbFFGV LA9iTdgJBkC7Dp/8grg6QV46zb/OaZEFNdGonpzQbZ1TOUsv97BK0Q3GVKrBsg8r6/Gv gWCw== MIME-Version: 1.0 X-Received: by 10.49.107.4 with SMTP id gy4mr11955043qeb.63.1361451233138; Thu, 21 Feb 2013 04:53:53 -0800 (PST) Received: by 10.49.121.198 with HTTP; Thu, 21 Feb 2013 04:53:52 -0800 (PST) In-Reply-To: <201302201022.29294.jhb@freebsd.org> References: <20130219185129.GC2598@kib.kiev.ua> <201302201022.29294.jhb@freebsd.org> Date: Thu, 21 Feb 2013 13:53:52 +0100 Message-ID: Subject: Re: [patch] i386 pmap sysmaps_pcpu[] atomic access From: Svatopluk Kraus To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1 Cc: Konstantin Belousov , freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 21 Feb 2013 12:53:59 -0000 On Wed, Feb 20, 2013 at 4:22 PM, John Baldwin wrote: > On Wednesday, February 20, 2013 7:31:08 am Svatopluk Kraus wrote: >> On Tue, Feb 19, 2013 at 7:51 PM, Konstantin Belousov >> wrote: >> > On Mon, Feb 18, 2013 at 11:18:16PM +0100, Svatopluk Kraus wrote: >> >> On Mon, Feb 18, 2013 at 9:36 PM, Konstantin Belousov >> >> wrote: >> >> Well, I'm taking a part on porting FreeBSD to ARM11mpcore. UP case was >> >> simple. SMP case is more complex and rather new for me. Recently, I >> >> was solving a problem with PCPU stuff. For example, PCPU_GET is >> >> implemented by one instruction on i386 arch. So, a need of atomicity >> >> with respect to interrupts can be overlooked. On load-store archs, the >> >> implementation which works in SMP case is not so simple. And what >> >> works in UP case (single PCPU), not works in SMP case. Believe me, >> >> mysterious and sporadic 'mutex not owned' assertions and others ones >> >> caused by curthreads mess, it takes a while ... >> > Note that PCPU_GET() is not needed to be atomic. The reason is that the code >> > which uses its result would not be atomic (single-instruction or whatever, see >> > below). Thus, either the preemption should not matter since the action with >> > the per-cpu data is advisory, as is in the case of i386 pmap you noted. >> > or some external measures should be applied in advance to the containing >> > region (which you proposed, by bracing with sched_pin()). >> >> So, it's advisory in the case of i386 pmap... Well, if you can live >> with that, I can too. >> >> > >> > Also, note that it is not interrupts but preemption which is concern. >> >> Yes and no. In theory, yes, a preemption is a concern. In FreeBSD, >> however, sched_pin() and critical_enter() and their counterparts are >> implemented with help of curthread. And curthread definition falls to >> PCPU_GET(curthread) if not defined in other way. So, curthread should >> be atomic with respect to interrupts and in general, PCPU_GET() should >> be too. Note that spinlock_enter() definitions often (always) use >> curthread too. Anyhow, it's defined in MD code and can be defined for >> each arch separately. > > curthread is a bit magic. :) If you perform a context switch during an > interrupt (which will change 'curthread') you also change your register state. > When you resume, the register state is also restored. This means that while > something like 'PCPU_GET(cpuid)' might be stale after you read it, 'curthread' > never is. However, it is true that actually reading curthread has to be > atomic. If your read of curthread looks like: > > mov , r0 > add , r0 > ld r0, r1 > > Then that will indeed break. Alpha used a fixed register for 'pcpu_reg' > (as does ia64 IIRC). OTOH, you might also be able to depend on the fact that > pc_curthread is the first thing in 'struct pcpu' (and always will be, you could > add a CTASSERT to future-proof). In that case, you can remove the 'add' > instruction and instead just do: > > ld , r1 > > which is fine. Just for the record. There are three extra (coprocessor) registers per a core in arm11mpcore (armv6k). Unfortunately only one is Privileged. The other ones are respectively User Read only and User Read Write. For now, we are using the Privileged one to store pcpu pointer (curthread is correctly set during each context switch). Thus, using a coprocessor register means that reading of curthread is not a single instruction implementation now. After we figured out the curthread issue in SMP case, using a fixed (processor) register for pcpu is an option. Meanwhile, we disable interrupts before reading of curthread and enable them after. The same is done for other PCPU stuff. For now we have not stable system enough for profiling, however, when it will be, it would be interesting to learn how various implementations of curthread reading impact system performance. Svata From owner-freebsd-current@FreeBSD.ORG Thu Feb 21 13:04:15 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 7994AA5A for ; Thu, 21 Feb 2013 13:04:15 +0000 (UTC) (envelope-from m.e.sanliturk@gmail.com) Received: from mail-vb0-f51.google.com (mail-vb0-f51.google.com [209.85.212.51]) by mx1.freebsd.org (Postfix) with ESMTP id 3F2FAFE6 for ; Thu, 21 Feb 2013 13:04:14 +0000 (UTC) Received: by mail-vb0-f51.google.com with SMTP id fq11so5763107vbb.10 for ; Thu, 21 Feb 2013 05:04:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=5kN1pK+dFhfjm0FOJR6mfiEhtT4P0RY7++5Yh+Xz3ro=; b=ii+GqWKOlDY0JxjY1nNw7L6QNnQRzWBIZ7N/RueLX2tb9WfnC+O7wzSLfBkGG94vs9 VXuG7stVnqoqLBbLIOUkVdJJ2TXXKQdow/4+LQLV8c1IRePgXCnk8oNAxb8yh4snCDlv GocmdYWmGGlfcIUvvvCLWT9LDFylNyk7Q9x7IKg5aQiHrmWinBRPsFIsAeSF/Jd1Wrt5 p6TuLdILmfEjmQ9EL23p7eVC1CEFYWxzVzS1Ydd8Pj3wFdd5SXI9Zdvr0f4v5BMUJmW6 hSbc1p+z9XS0GZwkhoDwOC7meqejKL1Xh5EHXTgReKhqHhDzJX0GuTnDLqLb0ebJ3qzc 6FxQ== MIME-Version: 1.0 X-Received: by 10.220.40.9 with SMTP id i9mr31096148vce.23.1361451848961; Thu, 21 Feb 2013 05:04:08 -0800 (PST) Received: by 10.58.170.36 with HTTP; Thu, 21 Feb 2013 05:04:08 -0800 (PST) Date: Thu, 21 Feb 2013 05:04:08 -0800 Message-ID: Subject: FreeBSD Testing Facility From: Mehmet Erol Sanliturk To: freebsd-current Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 21 Feb 2013 13:04:15 -0000 Dear All , During development of FreeBSD , testing is very vital . To my knowledge ( which may not be correct ) , at present , Tinderbox is used to only compilation correctness , means "Syntax" is tested . I have downloaded ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/amd64/amd64/ISO-IMAGES/10.0/FreeBSD-10.0-CURRENT-amd64-20130216-r246877-release.iso and tried to install it on an Intel DG965WH main board . During the first booting , it generated a panic message and entered into debug mode . For me it has crashed , because I do not know what to do in debug mode . On this main board , it is possible to completely install and successfully run Windows 7 , Fedora 15 , 17 , 18 , Mageia OpenSuSE and some others , all of them being 64 bits . The above failure shows that "Semantics" of FreeBSD is NOT tested well . My suggestion is as follows : Establish a mailing list only devoted to FreeBSD testing activities . To the subscribers , present a form to get information which parts of the FreeBSD he/she can test by selecting from supplied parts list . Establish a testing ftp site and introduce into it testing scripts and their parts , or iso files , etc. , directed toward testing a whole or a part . In that site , classify tests in directories such as FATAL ( requires a new , complete install , or can not be applied in a production system ) DANGEROUS ( can not be applied in a production system ) HARMLESS With respect to forms filled by the testing list subscribers , send a mail to inform that a testing step is available with related links . The subscriber , may download the testing parts and apply them . If it is planned and implemented to return a mail showing test results on behalf of user approval , it may be very good . In that way , automated analysis of returned mails will be possible . If this is not easy , the user may send a message about result . Due to irregular message structure , automatic processing of such messages will be difficult . With the above structure , it will be possible to test the FreeBSD as much as possible . The subscribers may maintain a USB hard disk or stick or memory card to be used only for testing purposes . Some subscribers may have free computers to apply tests . Some subscribers may disconnect power of a production hard disk and apply tests on a spare disk , etc. , if they can find time . Any testing step in any way conceived by the subscribers will be useful . There are such community testing programs , for example , using BOINC . There is a port about this already . http://en.wikipedia.org/wiki/BOINC http://en.wikipedia.org/wiki/BOINC_client%E2%80%93server_technology http://en.wikipedia.org/wiki/List_of_distributed_computing_projects https://boinc.berkeley.edu/ http://www.freshports.org/net/boinc-client/ http://www.freshports.org/net/boinc_curses/ http://www.freshports.org/astro/boinc-astropulse/ http://www.freshports.org/astro/boinc-setiathome-enhanced/ http://www.freshports.org/biology/boinc-simap/ Thank you very much . Mehmet Erol Sanliturk From owner-freebsd-current@FreeBSD.ORG Thu Feb 21 13:14:12 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 7A23D194 for ; Thu, 21 Feb 2013 13:14:12 +0000 (UTC) (envelope-from daniel@digsys.bg) Received: from smtp-sofia.digsys.bg (smtp-sofia.digsys.bg [193.68.3.230]) by mx1.freebsd.org (Postfix) with ESMTP id 0461217A for ; Thu, 21 Feb 2013 13:14:11 +0000 (UTC) Received: from dcave.digsys.bg (dcave.digsys.bg [192.92.129.5]) (authenticated bits=0) by smtp-sofia.digsys.bg (8.14.5/8.14.5) with ESMTP id r1LDE65v090128 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Thu, 21 Feb 2013 15:14:06 +0200 (EET) (envelope-from daniel@digsys.bg) Message-ID: <51261D9E.6080507@digsys.bg> Date: Thu, 21 Feb 2013 15:14:06 +0200 From: Daniel Kalchev User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0.12) Gecko/20130125 Thunderbird/10.0.12 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: FreeBSD Testing Facility References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 21 Feb 2013 13:14:12 -0000 On 21.02.13 15:04, Mehmet Erol Sanliturk wrote: > Dear All , > > During development of FreeBSD , testing is very vital . > > To my knowledge ( which may not be correct ) , at present , > Tinderbox is used to only compilation correctness , > means "Syntax" is tested . > > I have downloaded > > ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/amd64/amd64/ISO-IMAGES/10.0/FreeBSD-10.0-CURRENT-amd64-20130216-r246877-release.iso > > > and tried to install it on an Intel DG965WH main board . > > During the first booting , it generated a panic message and entered into > debug mode . > > For me it has crashed , because I do not know what to do in debug mode . > > > > On this main board , it is possible to completely install and successfully > run > > Windows 7 , > Fedora 15 , 17 , 18 , > Mageia > OpenSuSE I stopped right here. None of the software you compare FreeBSD-current to is an development build. On the other hand, you downloaded an cutting-edge development build of FreeBSD (not released software) and expected it to be stable. It is not. This is why it is not released. It might not always break, but it might also damage your data and (possibly) hardware too. Unless you agree to accept these risks, you should not play with development versions of software. Having said that, the DG965WH is quite old hardware and any stable version of FreeBSD should work just fine there. You are unlikely to see any benefit of the unreleased versions that are still in development, such as supporting "very new" hardware etc. Sorry if any of this sounds too hard, but it is reflecting reality. This mailing list, freebsd-current exists to facilitate discussion between those, who know they are running highly unstable, still in development version of FreeBSD that needs lots of work to become more stable. Daniel From owner-freebsd-current@FreeBSD.ORG Thu Feb 21 13:23:35 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 4E2BE3EB for ; Thu, 21 Feb 2013 13:23:35 +0000 (UTC) (envelope-from m.e.sanliturk@gmail.com) Received: from mail-ve0-f173.google.com (mail-ve0-f173.google.com [209.85.128.173]) by mx1.freebsd.org (Postfix) with ESMTP id F3A61212 for ; Thu, 21 Feb 2013 13:23:34 +0000 (UTC) Received: by mail-ve0-f173.google.com with SMTP id oz10so7868759veb.4 for ; Thu, 21 Feb 2013 05:23:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=x00S4l1aXB35wk+9rK282qmE/wzVbuF+dDdAzoszRFQ=; b=Uw1P6FrI2nW6awih/nZK23fDeh3fh+U7ecrmX5BSMzuLI7n76krmtdgG0+kClHtP13 /Vwyxpgbf1Lq8OCI+VSFQpDngOj7XSAW6aZj1Sj4de7om+bDDfyEWBtTmNtFX5FNPi0A 7Iis1ghyU8Dpi3KH9WrF+dPMrYW8l1xRGWciEX/LqoVxRJooha4GO9Px+OoQr+yaX1ud fyOyPL5bLHAwjW8Bt5lwos9Tp0JhsAPaHUWaKSiLD62vVBw/ra+6O3VyWn+5uhJKcLMY eoNle1pT14mjiB1QFdqb2bDtaav2DaCkjzLKQ2nGpHtZoamIXWn0q0y+YFxBaQGccfbK ccdQ== MIME-Version: 1.0 X-Received: by 10.58.252.72 with SMTP id zq8mr32193251vec.20.1361453014119; Thu, 21 Feb 2013 05:23:34 -0800 (PST) Received: by 10.58.170.36 with HTTP; Thu, 21 Feb 2013 05:23:34 -0800 (PST) In-Reply-To: <51261D9E.6080507@digsys.bg> References: <51261D9E.6080507@digsys.bg> Date: Thu, 21 Feb 2013 05:23:34 -0800 Message-ID: Subject: Re: FreeBSD Testing Facility From: Mehmet Erol Sanliturk To: Daniel Kalchev Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 21 Feb 2013 13:23:35 -0000 On Thu, Feb 21, 2013 at 5:14 AM, Daniel Kalchev wrote: > > > On 21.02.13 15:04, Mehmet Erol Sanliturk wrote: > >> Dear All , >> >> During development of FreeBSD , testing is very vital . >> >> To my knowledge ( which may not be correct ) , at present , >> Tinderbox is used to only compilation correctness , >> means "Syntax" is tested . >> >> I have downloaded >> >> ftp://ftp.freebsd.org/pub/**FreeBSD/snapshots/amd64/amd64/** >> ISO-IMAGES/10.0/FreeBSD-10.0-**CURRENT-amd64-20130216-** >> r246877-release.iso >> >> >> and tried to install it on an Intel DG965WH main board . >> >> During the first booting , it generated a panic message and entered into >> debug mode . >> >> For me it has crashed , because I do not know what to do in debug mode . >> >> >> >> On this main board , it is possible to completely install and successfully >> run >> >> Windows 7 , >> Fedora 15 , 17 , 18 , >> Mageia >> OpenSuSE >> > > I stopped right here. None of the software you compare FreeBSD-current to > is an development build. On the other hand, you downloaded an cutting-edge > development build of FreeBSD (not released software) and expected it to be > stable. It is not. This is why it is not released. It might not always > break, but it might also damage your data and (possibly) hardware too. > Unless you agree to accept these risks, you should not play with > development versions of software. > > Having said that, the DG965WH is quite old hardware and any stable version > of FreeBSD should work just fine there. You are unlikely to see any benefit > of the unreleased versions that are still in development, such as > supporting "very new" hardware etc. > > Sorry if any of this sounds too hard, but it is reflecting reality. This > mailing list, freebsd-current exists to facilitate discussion between > those, who know they are running highly unstable, still in development > version of FreeBSD that needs lots of work to become more stable. > > Daniel > I will not support your views . My main idea is to describe how we can help to improve FreeBSD testing . The problem is " A snapshot intended for testing , is NOT able to boot." . If you ask , do I know what I am doing : My answer is I am working in computing since 1970 . Thank you very much . Mehmet Erol Sanliturk From owner-freebsd-current@FreeBSD.ORG Thu Feb 21 14:22:14 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 35E54A99; Thu, 21 Feb 2013 14:22:14 +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 0C0EE81E; Thu, 21 Feb 2013 14:22:13 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r1LEMD55074840; Thu, 21 Feb 2013 09:22:13 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r1LEMDom074839; Thu, 21 Feb 2013 14:22:13 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 21 Feb 2013 14:22:13 GMT Message-Id: <201302211422.r1LEMDom074839@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 , , Subject: [head tinderbox] failure on arm/arm Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 14:22:14 -0000 TB --- 2013-02-21 12:20:17 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-02-21 12:20:17 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-02-21 12:20:17 - starting HEAD tinderbox run for arm/arm TB --- 2013-02-21 12:20:17 - cleaning the object tree TB --- 2013-02-21 12:25:57 - /usr/local/bin/svn stat /src TB --- 2013-02-21 12:26:00 - At svn revision 247093 TB --- 2013-02-21 12:26:01 - building world TB --- 2013-02-21 12:26:01 - CROSS_BUILD_TESTING=YES TB --- 2013-02-21 12:26:01 - MAKEOBJDIRPREFIX=/obj TB --- 2013-02-21 12:26:01 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-02-21 12:26:01 - SRCCONF=/dev/null TB --- 2013-02-21 12:26:01 - TARGET=arm TB --- 2013-02-21 12:26:01 - TARGET_ARCH=arm TB --- 2013-02-21 12:26:01 - TZ=UTC TB --- 2013-02-21 12:26:01 - __MAKE_CONF=/dev/null TB --- 2013-02-21 12:26:01 - cd /src TB --- 2013-02-21 12:26:01 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Thu Feb 21 12:26:06 UTC 2013 >>> 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 Thu Feb 21 14:15:42 UTC 2013 TB --- 2013-02-21 14:15:42 - generating LINT kernel config TB --- 2013-02-21 14:15:42 - cd /src/sys/arm/conf TB --- 2013-02-21 14:15:42 - /usr/bin/make -B LINT TB --- 2013-02-21 14:15:42 - cd /src/sys/arm/conf TB --- 2013-02-21 14:15:42 - /usr/sbin/config -m LINT TB --- 2013-02-21 14:15:42 - building LINT kernel TB --- 2013-02-21 14:15:42 - CROSS_BUILD_TESTING=YES TB --- 2013-02-21 14:15:42 - MAKEOBJDIRPREFIX=/obj TB --- 2013-02-21 14:15:42 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-02-21 14:15:42 - SRCCONF=/dev/null TB --- 2013-02-21 14:15:42 - TARGET=arm TB --- 2013-02-21 14:15:42 - TARGET_ARCH=arm TB --- 2013-02-21 14:15:42 - TZ=UTC TB --- 2013-02-21 14:15:42 - __MAKE_CONF=/dev/null TB --- 2013-02-21 14:15:42 - cd /src TB --- 2013-02-21 14:15:42 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Feb 21 14:15:42 UTC 2013 >>> 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 -fdiagnostics-show-option -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 -fno-builtin -mno-thumb-interwork -ffreestanding -Werror /src/sys/dev/ppbus/pps.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 -fdiagnostics-show-option -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 -fno-builtin -mno-thumb-interwork -ffreestanding -Werror /src/sys/dev/ppbus/vpo.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 -fdiagnostics-show-option -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 -fno-builtin -mno-thumb-interwork -ffreestanding -Werror /src/sys/dev/ppbus/vpoio.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 -fdiagnostics-show-option -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 -fno-builtin -mno-thumb-interwork -ffreestanding -Werror /src/sys/dev/ppc/ppc.c cc1: warnings being treated as errors /src/sys/dev/ppc/ppc.c: In function 'ppc_smc37c66xgt_detect': /src/sys/dev/ppc/ppc.c:724: warning: implicit declaration of function 'critical_leave' /src/sys/dev/ppc/ppc.c:724: warning: nested extern declaration of 'critical_leave' [-Wnested-externs] *** [ppc.o] Error code 1 Stop in /obj/arm.arm/src/sys/LINT. *** [buildkernel] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-02-21 14:22:13 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-02-21 14:22:13 - ERROR: failed to build LINT kernel TB --- 2013-02-21 14:22:13 - 5591.03 user 975.04 system 7315.57 real http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-arm-arm.full From owner-freebsd-current@FreeBSD.ORG Thu Feb 21 14:32:42 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 6A872E7F for ; Thu, 21 Feb 2013 14:32:42 +0000 (UTC) (envelope-from swills@FreeBSD.org) Received: from mouf.net (mouf.net [IPv6:2607:fc50:0:4400:216:3eff:fe69:33b3]) by mx1.freebsd.org (Postfix) with ESMTP id 0999D8DD for ; Thu, 21 Feb 2013 14:32:41 +0000 (UTC) Received: from mouf.net (www@mouf [199.48.129.64]) by mouf.net (8.14.5/8.14.5) with ESMTP id r1LEWTfn044993; Thu, 21 Feb 2013 14:32:34 GMT (envelope-from swills@FreeBSD.org) Received: from 64.128.208.27 (SquirrelMail authenticated user swills) by mouf.net with HTTP; Thu, 21 Feb 2013 09:32:35 -0500 Message-ID: <073043018e9a6318fd5ef17ad4065b10.squirrel@mouf.net> In-Reply-To: References: Date: Thu, 21 Feb 2013 09:32:35 -0500 Subject: Re: Kernel hang r247079 mps/vfs/zfs? From: "Steve Wills" To: "matt" User-Agent: SquirrelMail/1.4.22 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (mouf.net [199.48.129.64]); Thu, 21 Feb 2013 14:32:35 +0000 (UTC) X-Spam-Status: No, score=0.0 required=4.5 tests=none autolearn=unavailable version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on mouf.net X-Virus-Scanned: clamav-milter 0.97.6 at mouf.net X-Virus-Status: Clean Cc: freebsd-current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 21 Feb 2013 14:32:42 -0000 Hi, > I was testing a patch on r246300 or so, and wanted to see if it would > apply > cleanly to a newer copy of HEAD. > > Well it did, except I had a hang at boot, shortly after ZFS version and > the > last scsi devices appear. > This easily could have been related to the patch I was testing, so I wiped > /usr/src/ and /usr/obj (after booting kernel.old) and rebuilt world and > kernel cleanly. > > I assumed that would resolve the issue, but it did not. > > The hang happens right after zfs is announced, and the last da devices > (some of which are usb) are reported. It comes before the noisy output of > mps. > > Hang is complete, and single user or verbose don't yield much. > > I'm having trouble exfiltrating a dmesg from it, but it may be unrelated > to > the userland issues reported earlier, as single user does not resolve it > for me. > The svn up was at 11:20 pacific (GMT +8). > > Anyone else seeing similar issues? > > Hardware is an LSI mps device, "9210" crossflashed m1015. Pool is a zfs > mirror. Works fine booting from r246300 kernel. > Motherboard is an AMD Tyan. > Pulling USB headers off the board didn't resolve it. I am experiencing a similar hang when updating from r246190 to r247017 on my all zfs system. The system has two drives in a zfs mirror and hangs after detecting the hard drives. The last thing seen is the "ada1: Previously was known as ad8" message, then it hangs completely, unable to even ctrl-alt-del or even get the numlock key to toggle the light. System is: CPU: AMD Phenom(tm) II X4 955 Processor (3214.39-MHz K8-class CPU) with ASUS M4A78LT-M board. Let me know if other details will help. Steve From owner-freebsd-current@FreeBSD.ORG Thu Feb 21 15:04:44 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 7F1B7B32 for ; Thu, 21 Feb 2013 15:04:44 +0000 (UTC) (envelope-from mjacob@freebsd.org) Received: from ns1.feral.com (ns1.feral.com [192.67.166.1]) by mx1.freebsd.org (Postfix) with ESMTP id 5C95EB01 for ; Thu, 21 Feb 2013 15:04:44 +0000 (UTC) Received: from [192.168.135.7] (76-14-49-207.sf-cable.astound.net [76.14.49.207]) (authenticated bits=0) by ns1.feral.com (8.14.6/8.14.4) with ESMTP id r1LF4cZv073865 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Thu, 21 Feb 2013 07:04:38 -0800 (PST) (envelope-from mjacob@freebsd.org) Message-ID: <51263782.3020205@freebsd.org> Date: Thu, 21 Feb 2013 07:04:34 -0800 From: Matthew Jacob Organization: FreeBSD User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: FreeBSD Testing Facility References: In-Reply-To: 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.7 (ns1.feral.com [192.67.166.1]); Thu, 21 Feb 2013 07:04:38 -0800 (PST) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: mjacob@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 15:04:44 -0000 On 2/21/2013 5:04 AM, Mehmet Erol Sanliturk wrote: > Dear All , > > During development of FreeBSD , testing is very vital . > ... This in general is a good suggestion. Most companies do such automated testing as a matter of course. Note however that this is a volunteer effort. Were you volunteering to set up such an automated, possibly testzilla driven, facility? It would certainly help the quality, although as others have noted snapshots are often likely to be broken. From owner-freebsd-current@FreeBSD.ORG Thu Feb 21 15:21:23 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 9D288FC2 for ; Thu, 21 Feb 2013 15:21:23 +0000 (UTC) (envelope-from ml@my.gd) Received: from mail-wg0-f48.google.com (mail-wg0-f48.google.com [74.125.82.48]) by mx1.freebsd.org (Postfix) with ESMTP id 3737AC32 for ; Thu, 21 Feb 2013 15:21:22 +0000 (UTC) Received: by mail-wg0-f48.google.com with SMTP id 16so7321342wgi.3 for ; Thu, 21 Feb 2013 07:21:21 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=D5P1lIznPpron0iulEbruVsMz/7Sw2Qy6eabJfrpbaM=; b=E2aLFIN/jhUEuViiEYVLdUOErBrobed11f0K4mB5eGjGXYG+YX0vqXGiIfSbrlbREy g1Ayf6AbXCqjYVJ7Ihe83jXrn383hlM4+v2bY4VAg+pWSielw/AqJwsbuoBQokwNZpnp hIrSFUICy5ctqrKLAzms7ykNhumWoN53HSFiqXQFw6ITxPq2bz28eXfmXy6WcLNNXk7X qESevf/axm86/fkW/yvjtUwiNbScEMV7rvNpGHUawg/VLfcxHN4SqCyZp7Fq20ISYcpr S9w1IoxJMhrhnB5wZBpcElUbkU8UdRavddpkTf1s70DGwxeJxdGzO/bbM6cQS98O8s64 C62A== X-Received: by 10.180.79.6 with SMTP id f6mr42296225wix.26.1361460081458; Thu, 21 Feb 2013 07:21:21 -0800 (PST) Received: from dfleuriot-at-hi-media.com ([83.167.62.196]) by mx.google.com with ESMTPS id j4sm35643669wiz.10.2013.02.21.07.21.19 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 21 Feb 2013 07:21:20 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: FreeBSD Testing Facility From: Fleuriot Damien In-Reply-To: Date: Thu, 21 Feb 2013 16:21:19 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <9A5C98EC-7BDF-482E-A663-F7ED7CB88747@my.gd> References: <51261D9E.6080507@digsys.bg> To: Mehmet Erol Sanliturk X-Mailer: Apple Mail (2.1499) X-Gm-Message-State: ALoCoQkAaTeA3Khwedd5oyMs09MBq1fpETUSJuCYl3bfpQO8qx/338m+SQqCW90ZvygZXvFjBCqc Cc: freebsd-current@freebsd.org, Daniel Kalchev X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 21 Feb 2013 15:21:23 -0000 On Feb 21, 2013, at 2:23 PM, Mehmet Erol Sanliturk = wrote: > On Thu, Feb 21, 2013 at 5:14 AM, Daniel Kalchev = wrote: >=20 >>=20 >>=20 >> On 21.02.13 15:04, Mehmet Erol Sanliturk wrote: >>=20 >>> Dear All , >>>=20 >>> During development of FreeBSD , testing is very vital . >>>=20 >>> To my knowledge ( which may not be correct ) , at present , >>> Tinderbox is used to only compilation correctness , >>> means "Syntax" is tested . >>>=20 >>> I have downloaded >>>=20 >>> ftp://ftp.freebsd.org/pub/**FreeBSD/snapshots/amd64/amd64/** >>> ISO-IMAGES/10.0/FreeBSD-10.0-**CURRENT-amd64-20130216-** >>> = r246877-release.iso= >>>=20 >>>=20 >>> and tried to install it on an Intel DG965WH main board . >>>=20 >>> During the first booting , it generated a panic message and entered = into >>> debug mode . >>>=20 >>> For me it has crashed , because I do not know what to do in debug = mode . >>>=20 >>>=20 >>>=20 >>> On this main board , it is possible to completely install and = successfully >>> run >>>=20 >>> Windows 7 , >>> Fedora 15 , 17 , 18 , >>> Mageia >>> OpenSuSE >>>=20 >>=20 >> I stopped right here. None of the software you compare = FreeBSD-current to >> is an development build. On the other hand, you downloaded an = cutting-edge >> development build of FreeBSD (not released software) and expected it = to be >> stable. It is not. This is why it is not released. It might not = always >> break, but it might also damage your data and (possibly) hardware = too. >> Unless you agree to accept these risks, you should not play with >> development versions of software. >>=20 >> Having said that, the DG965WH is quite old hardware and any stable = version >> of FreeBSD should work just fine there. You are unlikely to see any = benefit >> of the unreleased versions that are still in development, such as >> supporting "very new" hardware etc. >>=20 >> Sorry if any of this sounds too hard, but it is reflecting reality. = This >> mailing list, freebsd-current exists to facilitate discussion between >> those, who know they are running highly unstable, still in = development >> version of FreeBSD that needs lots of work to become more stable. >>=20 >> Daniel >>=20 >=20 >=20 > I will not support your views . My main idea is to describe how we can = help > to improve FreeBSD testing . >=20 > The problem is " A snapshot intended for testing , is NOT able to = boot." . >=20 > If you ask , do I know what I am doing : My answer is I am working in > computing since 1970 . >=20 And in all that time you've never heard of nightly builds being broken ? From owner-freebsd-current@FreeBSD.ORG Thu Feb 21 15:22:31 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 3C96B2DC; Thu, 21 Feb 2013 15:22:31 +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 12BD5CC3; Thu, 21 Feb 2013 15:22:30 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r1LFMUAP049425; Thu, 21 Feb 2013 10:22:30 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r1LFMUWc049419; Thu, 21 Feb 2013 15:22:30 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 21 Feb 2013 15:22:30 GMT Message-Id: <201302211522.r1LFMUWc049419@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 , , Subject: [head tinderbox] failure on i386/i386 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 15:22:31 -0000 TB --- 2013-02-21 12:20:17 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-02-21 12:20:17 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-02-21 12:20:17 - starting HEAD tinderbox run for i386/i386 TB --- 2013-02-21 12:20:17 - cleaning the object tree TB --- 2013-02-21 12:27:03 - /usr/local/bin/svn stat /src TB --- 2013-02-21 12:27:06 - At svn revision 247093 TB --- 2013-02-21 12:27:07 - building world TB --- 2013-02-21 12:27:07 - CROSS_BUILD_TESTING=YES TB --- 2013-02-21 12:27:07 - MAKEOBJDIRPREFIX=/obj TB --- 2013-02-21 12:27:07 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-02-21 12:27:07 - SRCCONF=/dev/null TB --- 2013-02-21 12:27:07 - TARGET=i386 TB --- 2013-02-21 12:27:07 - TARGET_ARCH=i386 TB --- 2013-02-21 12:27:07 - TZ=UTC TB --- 2013-02-21 12:27:07 - __MAKE_CONF=/dev/null TB --- 2013-02-21 12:27:07 - cd /src TB --- 2013-02-21 12:27:07 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Thu Feb 21 12:27:12 UTC 2013 >>> 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 Thu Feb 21 15:12:06 UTC 2013 TB --- 2013-02-21 15:12:06 - generating LINT kernel config TB --- 2013-02-21 15:12:06 - cd /src/sys/i386/conf TB --- 2013-02-21 15:12:06 - /usr/bin/make -B LINT TB --- 2013-02-21 15:12:06 - cd /src/sys/i386/conf TB --- 2013-02-21 15:12:06 - /usr/sbin/config -m LINT TB --- 2013-02-21 15:12:07 - building LINT kernel TB --- 2013-02-21 15:12:07 - CROSS_BUILD_TESTING=YES TB --- 2013-02-21 15:12:07 - MAKEOBJDIRPREFIX=/obj TB --- 2013-02-21 15:12:07 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-02-21 15:12:07 - SRCCONF=/dev/null TB --- 2013-02-21 15:12:07 - TARGET=i386 TB --- 2013-02-21 15:12:07 - TARGET_ARCH=i386 TB --- 2013-02-21 15:12:07 - TZ=UTC TB --- 2013-02-21 15:12:07 - __MAKE_CONF=/dev/null TB --- 2013-02-21 15:12:07 - cd /src TB --- 2013-02-21 15:12:07 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Feb 21 15:12:07 UTC 2013 >>> 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 -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -DGPROF -DGPROF4 -DGUPROF -fno-builtin -mno-aes -mno-avx -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -Werror -pg /src/sys/dev/ppc/ppc.c /src/sys/dev/ppc/ppc.c:724:2: error: implicit declaration of function 'critical_leave' is invalid in C99 [-Werror,-Wimplicit-function-declaration] PPC_CONFIG_UNLOCK(ppc); ^ /src/sys/dev/ppc/ppc.c:91:33: note: expanded from macro 'PPC_CONFIG_UNLOCK' #define PPC_CONFIG_UNLOCK(ppc) critical_leave() ^ 1 error generated. *** [ppc.o] Error code 1 Stop in /obj/i386.i386/src/sys/LINT. *** [buildkernel] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-02-21 15:22:30 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-02-21 15:22:30 - ERROR: failed to build LINT kernel TB --- 2013-02-21 15:22:30 - 8483.52 user 1309.46 system 10932.48 real http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Thu Feb 21 15:26:33 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id DAC798CD; Thu, 21 Feb 2013 15:26:33 +0000 (UTC) (envelope-from m.e.sanliturk@gmail.com) Received: from mail-ve0-f170.google.com (mail-ve0-f170.google.com [209.85.128.170]) by mx1.freebsd.org (Postfix) with ESMTP id 8EF22D14; Thu, 21 Feb 2013 15:26:33 +0000 (UTC) Received: by mail-ve0-f170.google.com with SMTP id 14so8177584vea.29 for ; Thu, 21 Feb 2013 07:26:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=RiHjzrA7hZ4XMUAf1VYJwJ2TcENesR4XJVlGFM6GXaU=; b=WL+JiIvNl1b+na9qMaSx8eX11eTFzebYNtpn7LN5FfLPIzJGoKZx/xnmuRcKbMCKxz 4p+/isFBNoUrx+zkN3vBnIR3dlMzNUFh/jgkjMSZkJDFbpqRpeGZan5HyqkpYdSEgNIh LFIi/NO5Ok0csOQ0zhZI3+MoTTgWsQ81UIZ4e7ziE8FpbQbcuJXUu/A/pQWahoDdOFHP EC2Y71EJhUSKD0IH9DqpoNqo+VKD20wXUm1S333qU9E0qYcdMoEGyXZ0rguZ5UyTCgeR NU2OJm93x11zAeo6AYzuKOdqqlM1qA3/hVP7voOM15jc0vWy8tN1Ys3VXEJ/yRU6JzCy ussA== MIME-Version: 1.0 X-Received: by 10.52.68.116 with SMTP id v20mr8859853vdt.126.1361460386808; Thu, 21 Feb 2013 07:26:26 -0800 (PST) Received: by 10.58.170.36 with HTTP; Thu, 21 Feb 2013 07:26:26 -0800 (PST) In-Reply-To: <51263782.3020205@freebsd.org> References: <51263782.3020205@freebsd.org> Date: Thu, 21 Feb 2013 07:26:26 -0800 Message-ID: Subject: Re: FreeBSD Testing Facility From: Mehmet Erol Sanliturk To: mjacob@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 21 Feb 2013 15:26:33 -0000 On Thu, Feb 21, 2013 at 7:04 AM, Matthew Jacob wrote: > On 2/21/2013 5:04 AM, Mehmet Erol Sanliturk wrote: > >> Dear All , >> >> During development of FreeBSD , testing is very vital . >> ... >> > > This in general is a good suggestion. Most companies do such automated > testing as a matter of course. > > Note however that this is a volunteer effort. Were you volunteering to set > up such an automated, possibly testzilla driven, facility? It would > certainly help the quality, although as others have noted snapshots are > often likely to be broken. > I am not able to design , implement and manage such a facility ( most important problem is health ) , but as an individual I want to participate to testing as much as I can . In the source tree , there are testing software . There are other testing sites . By cosolidating them as a distributed testing facility will help making FreeBSD much more robust and increase development speed . My idea is that a wide testing applicators may resolve many problems at the beginning . All the people which are trying snapshots or are using current developments will likely participate such a testing community and produce results in a structured and cooperative way . For example , assume a component for boot up to login ( included ) is modified . Instead of preparing a many hundred mega bytes complete snapshot , only a small boot only snapshot may be prepared and presented to testers . After verifying that the boot process is correct , the more complete snapshots may be prepared . In that way , time and money will not be wasted by including unnecessary parts . Please , consider each component in that way . At present , many tools are already present in the ports tree . Thank you very much . Mehmet Erol Sanliturk From owner-freebsd-current@FreeBSD.ORG Thu Feb 21 15:28:25 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id B4838A4C for ; Thu, 21 Feb 2013 15:28:25 +0000 (UTC) (envelope-from lattera@gmail.com) Received: from mail-vc0-f174.google.com (mail-vc0-f174.google.com [209.85.220.174]) by mx1.freebsd.org (Postfix) with ESMTP id 7CA7CD41 for ; Thu, 21 Feb 2013 15:28:25 +0000 (UTC) Received: by mail-vc0-f174.google.com with SMTP id n11so5740519vch.19 for ; Thu, 21 Feb 2013 07:28:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=c9+yfipQDVjEQhAJSzNiB37UVNxl7ggQiJOENX7Pe1Q=; b=Joo3n6LzoKNAp9MvLOdliz5tyEZrLU2W57TRw3yOhgljmja30eqG/wYqoAiQKihb5X LHatX3qNNZo2YQO4Fu1/LjIC91TMAo3N4r0Z66yxGb8wNGlYHxuP+9inj8RMdC+HDaHj VMmNqvy/6zRKRyYQCzFAVUa2wb6Xxi9PnNJuCaInbmw6Ip4aGxFE3Wt1JOQ5MNvGYu3J tFTO/vSKeGZ2Udvit5RQIipAINxMwnTFYOCJFeYNaTfDD0y/5LXyUcl3Fk6mMnRAbc/f WcAPRxJt8WVSFgKyMJKaMwpytrxdg4M8Ee4qV3x9tgveGtkinbt+x+vAGEa1DBCEmaZz iZIw== MIME-Version: 1.0 X-Received: by 10.52.28.82 with SMTP id z18mr27001042vdg.33.1361460495120; Thu, 21 Feb 2013 07:28:15 -0800 (PST) Received: by 10.58.37.35 with HTTP; Thu, 21 Feb 2013 07:28:15 -0800 (PST) Date: Thu, 21 Feb 2013 10:28:15 -0500 Message-ID: Subject: r247095 Boot Failure From: Shawn Webb To: FreeBSD-current Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 21 Feb 2013 15:28:25 -0000 I'm on r247095. My box is failing to boot on a Dell Precision T7500. I'm running ZFS as root with a mirrored root pool. Here's a pic of the box failing: https://lh5.googleusercontent.com/-Lq_jlX8of0o/USY4cqZ5BOI/AAAAAAAAGoI/Nd1LGPbFjHc/s1112/IMG_20130221_100723.jpg There isn't much useful information in the pic. No crash dump is generated. Where do I go from here? I can boot into kernel.old and that works as a workaround for now. Thanks, Shawn From owner-freebsd-current@FreeBSD.ORG Thu Feb 21 15:32:19 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 09B00B9E for ; Thu, 21 Feb 2013 15:32:19 +0000 (UTC) (envelope-from sendtomatt@gmail.com) Received: from mail-vc0-f169.google.com (mail-vc0-f169.google.com [209.85.220.169]) by mx1.freebsd.org (Postfix) with ESMTP id 96FC0D81 for ; Thu, 21 Feb 2013 15:32:18 +0000 (UTC) Received: by mail-vc0-f169.google.com with SMTP id n10so5953363vcn.28 for ; Thu, 21 Feb 2013 07:32:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=nrOqku6qIhFGC0LMiuqFb0JU1vd+pZjDSkUfohqnItc=; b=q+6g+AsqrYYL8zB65xYneSld2X1KJn9C/xvhPcqmrl82/9L87JwAyPZRHUdfgfUVke JSNcaSMHkv6RX+Ab8nFqCiWvXKxrisH+xZiaF9CsWqArYIYkg7GFWONCzPfBn1igKPhG SUPL64znfrZrFv01iggcYK0TZ5MrSduTpjs1uBqwstbd/su0ZzSU5uTWzLFJvUOzjYM+ Fa/qouUUP0hNC7NSN0QD0j/tDQT9pAwwCW3ua0qsJVl09PT05b8DqR7H3nuVe60sQeC0 P2sJmeYNPuK3unaROfodLoAJO7fVb6t2hVNzmXnNWHRXEHIDq6H+F/8Kt88koNZSuoXT wY7w== MIME-Version: 1.0 X-Received: by 10.58.161.41 with SMTP id xp9mr32120723veb.56.1361460738104; Thu, 21 Feb 2013 07:32:18 -0800 (PST) Received: by 10.58.77.101 with HTTP; Thu, 21 Feb 2013 07:32:18 -0800 (PST) In-Reply-To: References: <073043018e9a6318fd5ef17ad4065b10.squirrel@mouf.net> Date: Thu, 21 Feb 2013 15:32:18 +0000 Message-ID: Subject: Kernel hang r247079 mps/vfs/zfs? From: matt To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 21 Feb 2013 15:32:19 -0000 --Meant to reply to list as well-- On Thu, Feb 21, 2013 at 2:32 PM, Steve Wills wrote: > > I am experiencing a similar hang when updating from r246190 to r247017 on > my all zfs system. The system has two drives in a zfs mirror and hangs > after detecting the hard drives. The last thing seen is the "ada1: > Previously was known as ad8" message, then it hangs completely, unable to > even ctrl-alt-del or even get the numlock key to toggle the light. System > is: > > CPU: AMD Phenom(tm) II X4 955 Processor (3214.39-MHz K8-class CPU) > > with ASUS M4A78LT-M board. Let me know if other details will help. > > Steve > > > Symptoms are identical to mine as far as I can tell. I did see fatal trap flash in one case, but couldn't read the crash info. It doesn't always just hang, once I got fatal trap and a reboot, other times I got a hard reboot without fatal trap printout. Unfortunately I wasn't able to catch anything other than "fatal trap..." before the machine cycled. Matt From owner-freebsd-current@FreeBSD.ORG Thu Feb 21 15:32:36 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id C00D2CAF; Thu, 21 Feb 2013 15:32:36 +0000 (UTC) (envelope-from yerenkow@gmail.com) Received: from mail-we0-x233.google.com (mail-we0-x233.google.com [IPv6:2a00:1450:400c:c03::233]) by mx1.freebsd.org (Postfix) with ESMTP id 3ABEBD93; Thu, 21 Feb 2013 15:32:36 +0000 (UTC) Received: by mail-we0-f179.google.com with SMTP id p43so5773813wea.38 for ; Thu, 21 Feb 2013 07:32:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=RUDwCvAv137ROAYsnqzVPZgcu8oq5b4RLrnGlffqnGU=; b=cGlA9ErxUV4h8vzA/GjiaDnXVHmSy0iiqP4sUDv8K0lh6SKBUEu/5IzhFlCjruUrfM owa2oYU/DCD3Uf3qmOL5UeBw0d7xUyFNsGNe0R38ey+7lkmtA3kZPSxVaqGvBrGXsn2x +xZTM0iULuZqudv8edkVXvmakJ2YKLDqmnvIhQvY8XPofGCXuBWFEKln9y9ckr+RnIN7 Bdi4IvHZiwxkmcUCXFVt1amGFH4WX6BW4LIWgrKztWf4xXqFAzNM0tx2zbXP6ZYPtnl9 GRqnyGga9O6pCJoW/NVAzeKnSigxTpDpn00xKWadYmPIjPPiQRhPISnFOm4FwGZl20oY LL/w== MIME-Version: 1.0 X-Received: by 10.180.83.227 with SMTP id t3mr40950987wiy.2.1361460755364; Thu, 21 Feb 2013 07:32:35 -0800 (PST) Received: by 10.194.85.116 with HTTP; Thu, 21 Feb 2013 07:32:35 -0800 (PST) In-Reply-To: References: <51263782.3020205@freebsd.org> Date: Thu, 21 Feb 2013 17:32:35 +0200 Message-ID: Subject: Re: FreeBSD Testing Facility From: Alexander Yerenkow To: Mehmet Erol Sanliturk Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-current@freebsd.org, mjacob@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 21 Feb 2013 15:32:36 -0000 Decent testing system is a pretty complex system to be. I spent some time in this area, and gave it up, at least till better times :) But anyway, at least booting/working network stack/firewall could be easily tested with VMs. There just need to be a person dedicated to this, which is lacking now. -- Regards, Alexander Yerenkow From owner-freebsd-current@FreeBSD.ORG Thu Feb 21 15:33:11 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 6E2A6DCC for ; Thu, 21 Feb 2013 15:33:11 +0000 (UTC) (envelope-from m.e.sanliturk@gmail.com) Received: from mail-ve0-f173.google.com (mail-ve0-f173.google.com [209.85.128.173]) by mx1.freebsd.org (Postfix) with ESMTP id 31706DB3 for ; Thu, 21 Feb 2013 15:33:11 +0000 (UTC) Received: by mail-ve0-f173.google.com with SMTP id oz10so8010390veb.4 for ; Thu, 21 Feb 2013 07:33:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=I6w6iev6BvWp0WDh5ll9LiUcASyLQ1gL5P00rPvpnSM=; b=fKndIbPrb1GqheBWiarvhUjydPKgse7zT7PVlXSx5BrjaggDEuTkrkiQaY2gTTS5y0 qGNIJ6Cb1tW4vM2zyY4KnYOOs+H0DdfRAzs+myjC7sLvYRfZJVJFeGLpgHFBJZGN0bVg EHfNNihDuLdtxEmv62oX/w/K/NO/xssNNAM8iX0XQpNPv8ccqgrT1BGIcUwNL3tUEYyR +vBV6DkwY5IonhOOJSERrAPCjTYWh7njVEigp1fut3JpvgXMOmFchyraqIXs0ZKTsGpG 8SOsrGwIQjoBfnGA1qxF/B9TLYwP61mfeAmv6/BgAYr8iUDyuKNlodz50tCZykfLkg4y ZaYQ== MIME-Version: 1.0 X-Received: by 10.52.24.114 with SMTP id t18mr27147413vdf.62.1361460735998; Thu, 21 Feb 2013 07:32:15 -0800 (PST) Received: by 10.58.170.36 with HTTP; Thu, 21 Feb 2013 07:32:15 -0800 (PST) In-Reply-To: <9A5C98EC-7BDF-482E-A663-F7ED7CB88747@my.gd> References: <51261D9E.6080507@digsys.bg> <9A5C98EC-7BDF-482E-A663-F7ED7CB88747@my.gd> Date: Thu, 21 Feb 2013 07:32:15 -0800 Message-ID: Subject: Re: FreeBSD Testing Facility From: Mehmet Erol Sanliturk To: Fleuriot Damien Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-current@freebsd.org, Daniel Kalchev X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 21 Feb 2013 15:33:11 -0000 On Thu, Feb 21, 2013 at 7:21 AM, Fleuriot Damien wrote: > > On Feb 21, 2013, at 2:23 PM, Mehmet Erol Sanliturk < > m.e.sanliturk@gmail.com> wrote: > > > On Thu, Feb 21, 2013 at 5:14 AM, Daniel Kalchev > wrote: > > > >> > >> > >> On 21.02.13 15:04, Mehmet Erol Sanliturk wrote: > >> > >>> Dear All , > >>> > >>> During development of FreeBSD , testing is very vital . > >>> > >>> To my knowledge ( which may not be correct ) , at present , > >>> Tinderbox is used to only compilation correctness , > >>> means "Syntax" is tested . > >>> > >>> I have downloaded > >>> > >>> ftp://ftp.freebsd.org/pub/**FreeBSD/snapshots/amd64/amd64/** > >>> ISO-IMAGES/10.0/FreeBSD-10.0-**CURRENT-amd64-20130216-** > >>> r246877-release.iso< > ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/amd64/amd64/ISO-IMAGES/10.0/FreeBSD-10.0-CURRENT-amd64-20130216-r246877-release.iso > > > >>> > >>> > >>> and tried to install it on an Intel DG965WH main board . > >>> > >>> During the first booting , it generated a panic message and entered > into > >>> debug mode . > >>> > >>> For me it has crashed , because I do not know what to do in debug mode > . > >>> > >>> > >>> > >>> On this main board , it is possible to completely install and > successfully > >>> run > >>> > >>> Windows 7 , > >>> Fedora 15 , 17 , 18 , > >>> Mageia > >>> OpenSuSE > >>> > >> > >> I stopped right here. None of the software you compare FreeBSD-current > to > >> is an development build. On the other hand, you downloaded an > cutting-edge > >> development build of FreeBSD (not released software) and expected it to > be > >> stable. It is not. This is why it is not released. It might not always > >> break, but it might also damage your data and (possibly) hardware too. > >> Unless you agree to accept these risks, you should not play with > >> development versions of software. > >> > >> Having said that, the DG965WH is quite old hardware and any stable > version > >> of FreeBSD should work just fine there. You are unlikely to see any > benefit > >> of the unreleased versions that are still in development, such as > >> supporting "very new" hardware etc. > >> > >> Sorry if any of this sounds too hard, but it is reflecting reality. This > >> mailing list, freebsd-current exists to facilitate discussion between > >> those, who know they are running highly unstable, still in development > >> version of FreeBSD that needs lots of work to become more stable. > >> > >> Daniel > >> > > > > > > I will not support your views . My main idea is to describe how we can > help > > to improve FreeBSD testing . > > > > The problem is " A snapshot intended for testing , is NOT able to boot." > . > > > > If you ask , do I know what I am doing : My answer is I am working in > > computing since 1970 . > > > > > And in all that time you've never heard of nightly builds being broken ? > > Please , please , DO NOT understand my message in a different context . I am NOT saying that a snapshot may not be broken . I am saying that "Let's test components as much as possible to generate more complex components." . After generating working components , we will start to test their union . At present , we are testing a complex system without testing its parts . This wastes much effort , time , money , etc. . To solve this problem , let's establish a distributed testing computing structure . Thank you very much . Mehmet Erol Sanliturk From owner-freebsd-current@FreeBSD.ORG Thu Feb 21 15:34:24 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 48F23F04 for ; Thu, 21 Feb 2013 15:34:24 +0000 (UTC) (envelope-from mjacob@freebsd.org) Received: from ns1.feral.com (ns1.feral.com [192.67.166.1]) by mx1.freebsd.org (Postfix) with ESMTP id 2700FDDA for ; Thu, 21 Feb 2013 15:34:23 +0000 (UTC) Received: from [192.168.135.7] (76-14-49-207.sf-cable.astound.net [76.14.49.207]) (authenticated bits=0) by ns1.feral.com (8.14.6/8.14.4) with ESMTP id r1LFYNvR074029 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Thu, 21 Feb 2013 07:34:23 -0800 (PST) (envelope-from mjacob@freebsd.org) Message-ID: <51263E7B.4040104@freebsd.org> Date: Thu, 21 Feb 2013 07:34:19 -0800 From: Matthew Jacob Organization: FreeBSD User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: FreeBSD Testing Facility References: <51263782.3020205@freebsd.org> In-Reply-To: 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.7 (ns1.feral.com [192.67.166.1]); Thu, 21 Feb 2013 07:34:23 -0800 (PST) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: mjacob@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 15:34:24 -0000 On 2/21/2013 7:32 AM, Alexander Yerenkow wrote: > There just need to be a person dedicated to this, which is lacking now. > > That is correct insofar as it goes. That's why we're not all terribly interested in suggestions about what *could* be done- just what somebody is doing. From owner-freebsd-current@FreeBSD.ORG Thu Feb 21 15:35:06 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 17AA790 for ; Thu, 21 Feb 2013 15:35:06 +0000 (UTC) (envelope-from nparhar@gmail.com) Received: from mail-pb0-f45.google.com (mail-pb0-f45.google.com [209.85.160.45]) by mx1.freebsd.org (Postfix) with ESMTP id E8B82DF2 for ; Thu, 21 Feb 2013 15:35:05 +0000 (UTC) Received: by mail-pb0-f45.google.com with SMTP id ro8so3523511pbb.4 for ; Thu, 21 Feb 2013 07:35:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:date:from:to:cc:subject:message-id:mail-followup-to :references:mime-version:content-type:content-disposition :in-reply-to:user-agent; bh=6uCCFwicVj94j31gz64BKhJC2KPtI0D/arzCnVzbr6o=; b=h2O0/mSTeapj9CpJpS/reggxZy8xzlSYrV5JxSYMEMKoRaiu0TaM/EaQHeYAYcUGwM XsdrRS/sdC1yTEp8uVbu4cVQVwlwKTz47ZroH2d7VzdEBM5pYtT8HHb+c8YWts22fzRj j39oIMc02GX+rmuzzEMxqHKkE/0LqEl3Da8hyDosJneWITJ0QndadGCRnAbrqqkxU9PF j7nD6EMBp/VNsCln3LbI9S0YcahCqk0FaKiYMY2dwJPwIq47O9aGh3Soha8EYzQZnhBs DF2qNXZ5pzOLVD7ZH1uifWAXH9ZQLwSAz7X7UJ7T01p2HpU1Pew3z4oTK2M2HcD+w8yi zDSQ== X-Received: by 10.68.137.161 with SMTP id qj1mr8931795pbb.168.1361460905357; Thu, 21 Feb 2013 07:35:05 -0800 (PST) Received: from itx (c-24-6-45-85.hsd1.ca.comcast.net. [24.6.45.85]) by mx.google.com with ESMTPS id vd4sm25670246pbc.35.2013.02.21.07.35.04 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 21 Feb 2013 07:35:04 -0800 (PST) Date: Thu, 21 Feb 2013 07:34:58 -0800 From: Navdeep Parhar To: Shawn Webb Subject: Re: r247095 Boot Failure Message-ID: <20130221153458.GA6838@itx> Mail-Followup-To: Shawn Webb , FreeBSD-current References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: FreeBSD-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 21 Feb 2013 15:35:06 -0000 On Thu, Feb 21, 2013 at 10:28:15AM -0500, Shawn Webb wrote: > I'm on r247095. My box is failing to boot on a Dell Precision T7500. I'm > running ZFS as root with a mirrored root pool. > > Here's a pic of the box failing: > https://lh5.googleusercontent.com/-Lq_jlX8of0o/USY4cqZ5BOI/AAAAAAAAGoI/Nd1LGPbFjHc/s1112/IMG_20130221_100723.jpg > > There isn't much useful information in the pic. No crash dump is generated. > Where do I go from here? Take a look at the "-CURRENT userland regression" thread. You may be able to boot if you choose "safe mode" in the boot loader menu. Regards, Navdeep > > I can boot into kernel.old and that works as a workaround for now. > > Thanks, > > Shawn > _______________________________________________ > 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 Feb 21 15:38:42 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id A2149424 for ; Thu, 21 Feb 2013 15:38:42 +0000 (UTC) (envelope-from sendtomatt@gmail.com) Received: from mail-ve0-f172.google.com (mail-ve0-f172.google.com [209.85.128.172]) by mx1.freebsd.org (Postfix) with ESMTP id 6830CE2D for ; Thu, 21 Feb 2013 15:38:42 +0000 (UTC) Received: by mail-ve0-f172.google.com with SMTP id cz11so7997513veb.31 for ; Thu, 21 Feb 2013 07:38:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=XkazXmlvA2yZN52BYIXCFkvG/zQdx/LeGHgEvxhZwt0=; b=YJ9aAbb0eV1tKpz/90vWSaRSPKHCHE/vcCKumuXhjJaYi9lUxOZzWyRp9cc2xojYJP Nv2j627tm+WzJvK4FaIFS+T/QaozsxzsHCP/dGXZi6swS2bD1afYpaZwkdCD3BklfOyY 7TdAeB3gEvtCPZBzCm50AtWSLrDMeTzZVWDc8AjFSRWjODSTWg2+WopxA48//MpyXWQb jA6CK4gcMMZdMuZcam2g2YXABaq9Stb2nwZhw9kEIl0Mqk3Xzhf141tvj0mLNxZb0Cyz e/gSMXIXQq+6jYAe88ub5SU2Sgekl/CDEXzGYc8DJ0YHdqJSinC1X1c7fWRdO0wBUuH/ fLDQ== MIME-Version: 1.0 X-Received: by 10.58.117.229 with SMTP id kh5mr32792523veb.27.1361461121489; Thu, 21 Feb 2013 07:38:41 -0800 (PST) Received: by 10.58.77.101 with HTTP; Thu, 21 Feb 2013 07:38:41 -0800 (PST) In-Reply-To: <20130221153458.GA6838@itx> References: <20130221153458.GA6838@itx> Date: Thu, 21 Feb 2013 15:38:41 +0000 Message-ID: Subject: Re: r247095 Boot Failure From: matt To: Shawn Webb , FreeBSD-current , nparhar@gmail.com Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 21 Feb 2013 15:38:42 -0000 On Thu, Feb 21, 2013 at 3:34 PM, Navdeep Parhar wrote: > > Take a look at the "-CURRENT userland regression" thread. You may be > able to boot if you choose "safe mode" in the boot loader menu. > > Regards, > Navdeep > > What is safe mode as far as boot flags? boot -sv doesn't work on my system... Matt From owner-freebsd-current@FreeBSD.ORG Thu Feb 21 15:46:18 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 1F91198D for ; Thu, 21 Feb 2013 15:46:18 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-wg0-f54.google.com (mail-wg0-f54.google.com [74.125.82.54]) by mx1.freebsd.org (Postfix) with ESMTP id 9947AED2 for ; Thu, 21 Feb 2013 15:46:17 +0000 (UTC) Received: by mail-wg0-f54.google.com with SMTP id fm10so7721621wgb.9 for ; Thu, 21 Feb 2013 07:46:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=o0Kr1kjYWDMeSbfxOKvlFcp20zlhsff7hSUoN7+cvc0=; b=LvmQ+LIbeKG+VKki8f+yMpKll6qk4QSnfOpcI+QNBl3Eb8ecuYQbBhb835KRCmapiD GdhQqjWg/TgH5E3JTnNoTgSMmv5fThtYyfFHSZT5Nf7S6ge1lxaKORBUujMPkoClEefA tlZAeVUFrZMim+nfLvwKE5nDdozbkkO4oMd6iFH5PbIZ/vQ7YFzUpvHvJU49T/WOVIPZ kq4jtuo0eWApW4Ppwo7ZJe0REI87ap5w/JDGGpUR6hYILh8sjL9HVSskivQGfre6jmBq l3GTZhO30tccZ/WsOkJ/Dz0hEMev2v80Ee92UOEqM1Ex7MRJFe1XIanf3mCTDUCH/4sI HM9g== MIME-Version: 1.0 X-Received: by 10.194.119.68 with SMTP id ks4mr42396919wjb.3.1361461571634; Thu, 21 Feb 2013 07:46:11 -0800 (PST) Received: by 10.194.86.167 with HTTP; Thu, 21 Feb 2013 07:46:11 -0800 (PST) In-Reply-To: References: <20130221153458.GA6838@itx> Date: Thu, 21 Feb 2013 18:46:11 +0300 Message-ID: Subject: Re: r247095 Boot Failure From: Sergey Kandaurov To: matt Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD-current , nparhar@gmail.com, Shawn Webb X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 21 Feb 2013 15:46:18 -0000 On 21 February 2013 19:38, matt wrote: > On Thu, Feb 21, 2013 at 3:34 PM, Navdeep Parhar wrote: > >> >> Take a look at the "-CURRENT userland regression" thread. You may be >> able to boot if you choose "safe mode" in the boot loader menu. >> >> Regards, >> Navdeep >> >> > What is safe mode as far as boot flags? > Currently that corresponds to: set kern.smp.disabled=1 set hw.ata.ata_dma=0 set hw.ata.atapi_dma=0 set hw.ata.wc=0 set hw.eisa_slots=0 set kern.eventtimer.periodic=1 set kern.geom.part.check_integrity=0 See /boot/menu-commands.4th -- wbr, pluknet From owner-freebsd-current@FreeBSD.ORG Thu Feb 21 15:50:11 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id C3B08FF8 for ; Thu, 21 Feb 2013 15:50:11 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id A2FA7F40 for ; Thu, 21 Feb 2013 15:50:11 +0000 (UTC) Received: from pakbsde14.localnet (unknown [38.105.238.108]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 1F069B911; Thu, 21 Feb 2013 10:50:11 -0500 (EST) From: John Baldwin To: freebsd-current@freebsd.org, Xin Li Subject: Re: -CURRENT userland regression Date: Thu, 21 Feb 2013 10:31:31 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p25; KDE/4.5.5; amd64; ; ) References: <51254ACE.2030100@delphij.net> <51254C7E.9050705@gmail.com> In-Reply-To: <51254C7E.9050705@gmail.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201302211031.31599.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 21 Feb 2013 10:50:11 -0500 (EST) Cc: Navdeep Parhar X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 21 Feb 2013 15:50:11 -0000 On Wednesday, February 20, 2013 5:21:50 pm Navdeep Parhar wrote: > On 02/20/13 14:14, Xin Li wrote: > > Hi, > > > > It seems that fresh -HEAD would give an unusable kernel that > > overwrites screen buffer in a way making it impossible to debug. > > Using an old world source to do 'make buildworld buildkernel' results > > in a (mostly: I have some strange USB issue right now and still > > looking for the cause) usable kernel. > > > > For now my known good combination is world 246858 with kernel 247057. > > I'm still trying to find out which revision have broke the stuff. > > I ran into this earlier today. Selecting "safe mode" in the boot loader > menu seems to work around the problem on my system. Now I will not > reboot until I see a fix for this in head :-) "safe mode" toggles a few different things IIRC, can you narrow it down to a single setting? -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Thu Feb 21 15:50:14 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 0C4F99A; Thu, 21 Feb 2013 15:50:14 +0000 (UTC) (envelope-from m.e.sanliturk@gmail.com) Received: from mail-vb0-f47.google.com (mail-vb0-f47.google.com [209.85.212.47]) by mx1.freebsd.org (Postfix) with ESMTP id B20F1F42; Thu, 21 Feb 2013 15:50:13 +0000 (UTC) Received: by mail-vb0-f47.google.com with SMTP id e21so5742821vbm.20 for ; Thu, 21 Feb 2013 07:50:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=sFnOyetjZMDcF6ceWVjWGELQxOdYLE/4sEoqBq59Jic=; b=CbzVOjxTHnP3XlH8yxclKmBumkZj7J+HZc46TA5KnrPkRMfcvaJ3lgSiULARNeNu0y Rl7cFZ+aWE98NK6gG3Wh1Bpuxy7XDtlbJHDYhDTwGpsQuufVu5CK2T++XUCGOz8/MK7C sNR9UnsURQT1Qj17Bp+CG0h04sZRxjpwJNxN7+yO7Ld4Ub7jf9U8mY2Ng/ILRy/7qiLU KKX/vjNADMu2WG1e0jTbwU9D1NqzeXQ7heO422FGXfyLRcY2ct/rKzIE30g/pqXXh/bM IQGPCKY+OKExKXnrEyJMxrqxG5hCGbqQ0938TrbqVGrM55KEoFl2Kux4IjxncpwypNC8 vu/w== MIME-Version: 1.0 X-Received: by 10.58.154.229 with SMTP id vr5mr7182662veb.11.1361461812876; Thu, 21 Feb 2013 07:50:12 -0800 (PST) Received: by 10.58.170.36 with HTTP; Thu, 21 Feb 2013 07:50:12 -0800 (PST) In-Reply-To: <51263E7B.4040104@freebsd.org> References: <51263782.3020205@freebsd.org> <51263E7B.4040104@freebsd.org> Date: Thu, 21 Feb 2013 07:50:12 -0800 Message-ID: Subject: Re: FreeBSD Testing Facility From: Mehmet Erol Sanliturk To: mjacob@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 21 Feb 2013 15:50:14 -0000 On Thu, Feb 21, 2013 at 7:34 AM, Matthew Jacob wrote: > On 2/21/2013 7:32 AM, Alexander Yerenkow wrote: > >> There just need to be a person dedicated to this, which is lacking now. >> >> >> That is correct insofar as it goes. That's why we're not all terribly > interested in suggestions about what *could* be done- just what somebody is > doing. > Please do not assume that ideas are not important . A question asked about "Why soap film is becoming colored when lighted ?" generated "Quantum mechanics" to supply a reasonable answer . After generating an applicable plan , it may be that there exist people to implement it . I am reading messages that people are asking for project ideas . It may be that some will be interested in some a project if it is defined very well . Without a plan , what can be done and how , and who will handled it ? Thank you very much . Mehmet Erol Sanliturk From owner-freebsd-current@FreeBSD.ORG Thu Feb 21 15:50:21 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 7D57B29A for ; Thu, 21 Feb 2013 15:50:21 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 2B826F51 for ; Thu, 21 Feb 2013 15:50:21 +0000 (UTC) Received: from pakbsde14.localnet (unknown [38.105.238.108]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 80857B990; Thu, 21 Feb 2013 10:50:20 -0500 (EST) From: John Baldwin To: Svatopluk Kraus Subject: Re: [patch] i386 pmap sysmaps_pcpu[] atomic access Date: Thu, 21 Feb 2013 10:43:49 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p25; KDE/4.5.5; amd64; ; ) References: <201302201022.29294.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201302211043.49906.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 21 Feb 2013 10:50:20 -0500 (EST) Cc: Konstantin Belousov , freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 21 Feb 2013 15:50:21 -0000 On Thursday, February 21, 2013 7:53:52 am Svatopluk Kraus wrote: > On Wed, Feb 20, 2013 at 4:22 PM, John Baldwin wrote: > > On Wednesday, February 20, 2013 7:31:08 am Svatopluk Kraus wrote: > >> On Tue, Feb 19, 2013 at 7:51 PM, Konstantin Belousov > >> wrote: > >> > On Mon, Feb 18, 2013 at 11:18:16PM +0100, Svatopluk Kraus wrote: > >> >> On Mon, Feb 18, 2013 at 9:36 PM, Konstantin Belousov > >> >> wrote: > >> >> Well, I'm taking a part on porting FreeBSD to ARM11mpcore. UP case was > >> >> simple. SMP case is more complex and rather new for me. Recently, I > >> >> was solving a problem with PCPU stuff. For example, PCPU_GET is > >> >> implemented by one instruction on i386 arch. So, a need of atomicity > >> >> with respect to interrupts can be overlooked. On load-store archs, the > >> >> implementation which works in SMP case is not so simple. And what > >> >> works in UP case (single PCPU), not works in SMP case. Believe me, > >> >> mysterious and sporadic 'mutex not owned' assertions and others ones > >> >> caused by curthreads mess, it takes a while ... > >> > Note that PCPU_GET() is not needed to be atomic. The reason is that the code > >> > which uses its result would not be atomic (single-instruction or whatever, see > >> > below). Thus, either the preemption should not matter since the action with > >> > the per-cpu data is advisory, as is in the case of i386 pmap you noted. > >> > or some external measures should be applied in advance to the containing > >> > region (which you proposed, by bracing with sched_pin()). > >> > >> So, it's advisory in the case of i386 pmap... Well, if you can live > >> with that, I can too. > >> > >> > > >> > Also, note that it is not interrupts but preemption which is concern. > >> > >> Yes and no. In theory, yes, a preemption is a concern. In FreeBSD, > >> however, sched_pin() and critical_enter() and their counterparts are > >> implemented with help of curthread. And curthread definition falls to > >> PCPU_GET(curthread) if not defined in other way. So, curthread should > >> be atomic with respect to interrupts and in general, PCPU_GET() should > >> be too. Note that spinlock_enter() definitions often (always) use > >> curthread too. Anyhow, it's defined in MD code and can be defined for > >> each arch separately. > > > > curthread is a bit magic. :) If you perform a context switch during an > > interrupt (which will change 'curthread') you also change your register state. > > When you resume, the register state is also restored. This means that while > > something like 'PCPU_GET(cpuid)' might be stale after you read it, 'curthread' > > never is. However, it is true that actually reading curthread has to be > > atomic. If your read of curthread looks like: > > > > mov , r0 > > add , r0 > > ld r0, r1 > > > > Then that will indeed break. Alpha used a fixed register for 'pcpu_reg' > > (as does ia64 IIRC). OTOH, you might also be able to depend on the fact that > > pc_curthread is the first thing in 'struct pcpu' (and always will be, you could > > add a CTASSERT to future-proof). In that case, you can remove the 'add' > > instruction and instead just do: > > > > ld , r1 > > > > which is fine. > > Just for the record. There are three extra (coprocessor) registers per > a core in arm11mpcore (armv6k). Unfortunately only one is Privileged. > The other ones are respectively User Read only and User Read Write. > For now, we are using the Privileged one to store pcpu pointer > (curthread is correctly set during each context switch). Thus, using a > coprocessor register means that reading of curthread is not a single > instruction implementation now. After we figured out the curthread > issue in SMP case, using a fixed (processor) register for pcpu is an > option. Meanwhile, we disable interrupts before reading of curthread > and enable them after. The same is done for other PCPU stuff. For now > we have not stable system enough for profiling, however, when it will > be, it would be interesting to learn how various implementations of > curthread reading impact system performance. curthread is read _a lot_, so I would expect this to hurt. What we did on Alpha was to use a fixed register for pcpu access, but we used the equivalent of a coprocessor register to also store the value so we could set that fixed register on entry to the kernel (userland was free to use the register for its own purposes). -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Thu Feb 21 15:51:59 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id D7C904E0; Thu, 21 Feb 2013 15:51:59 +0000 (UTC) (envelope-from m.e.sanliturk@gmail.com) Received: from mail-vc0-f174.google.com (mail-vc0-f174.google.com [209.85.220.174]) by mx1.freebsd.org (Postfix) with ESMTP id 8790CFB5; Thu, 21 Feb 2013 15:51:59 +0000 (UTC) Received: by mail-vc0-f174.google.com with SMTP id n11so5756888vch.19 for ; Thu, 21 Feb 2013 07:51:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=wjx1qSoXRD0gNRSdhMdqihbQ8ilo2HUySIXcejzYekQ=; b=BGrOb8Oi8o4fLHM67fw5INYDSd46rLwKT8gX6/Ad5U9u22uTbj17435GjFztjbM+ne B0n68ODie03bpPai/ePkEVtTCzN7F8W8WW4cENzFRc8ZQ4FVsEeSo15r25rlDDLTCDUF +v60yhpmKkpH70YsjkPeOjjpR8bws997RfntGdNTaiRxQ/o8JzP33Blb4ue8eEWRXJn5 mVvJEAKqg5+7XA+ifZm64usUBAJLJ5rOa0UCWXvbUNZwBvERrRIq0CbbRYGLcAvpkQcJ Sf+6eXRuNG3gKZu4oKkPMmesQmyHueNN5e1QmLf/53vJ+6mwDbJnEk5rYOCNdsQPlzEE odQQ== MIME-Version: 1.0 X-Received: by 10.52.38.234 with SMTP id j10mr28434020vdk.0.1361461439357; Thu, 21 Feb 2013 07:43:59 -0800 (PST) Received: by 10.58.170.36 with HTTP; Thu, 21 Feb 2013 07:43:59 -0800 (PST) In-Reply-To: References: <51263782.3020205@freebsd.org> Date: Thu, 21 Feb 2013 07:43:59 -0800 Message-ID: Subject: Re: FreeBSD Testing Facility From: Mehmet Erol Sanliturk To: Alexander Yerenkow Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-current@freebsd.org, mjacob@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 21 Feb 2013 15:51:59 -0000 On Thu, Feb 21, 2013 at 7:32 AM, Alexander Yerenkow wrote: > Decent testing system is a pretty complex system to be. > I spent some time in this area, and gave it up, at least till better times > :) > > But anyway, at least booting/working network stack/firewall could be > easily tested with VMs. > There just need to be a person dedicated to this, which is lacking now. > > > -- > Regards, > Alexander Yerenkow With "BOINC" , people are trying to solve very complex problems by contributing as much as what they can do to solve its parts . A similar structure may be established for FreeBSD . As an example , booting in virtual machine may be possible , but in a real machine may not work . Some main boards may work , but others may not work . The FreeBSD project can not establish a very large testing farm . People wanting to participate may contribute very much . Every one will not test every thing . For that reason a database will be constructed at the beginning to contain ( user , parts can be tested ). When a test is required , by querying the database , a message will be send to the prospective users to inform them about the tests . The users will apply tests and return the results . At present , there are "call for testing" messages . In such an organized community , such messages will produce much more structured and effective results . Thank you very much . Mehmet Erol Sanliturk From owner-freebsd-current@FreeBSD.ORG Thu Feb 21 15:56:32 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id EDACA6D8; Thu, 21 Feb 2013 15:56:32 +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 BE59D61; Thu, 21 Feb 2013 15:56:32 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r1LFuWlH047874; Thu, 21 Feb 2013 10:56:32 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r1LFuWun047855; Thu, 21 Feb 2013 15:56:32 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 21 Feb 2013 15:56:32 GMT Message-Id: <201302211556.r1LFuWun047855@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 , , Subject: [head tinderbox] failure on amd64/amd64 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 15:56:33 -0000 TB --- 2013-02-21 12:20:17 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-02-21 12:20:17 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-02-21 12:20:17 - starting HEAD tinderbox run for amd64/amd64 TB --- 2013-02-21 12:20:17 - cleaning the object tree TB --- 2013-02-21 12:27:26 - /usr/local/bin/svn stat /src TB --- 2013-02-21 12:27:30 - At svn revision 247093 TB --- 2013-02-21 12:27:31 - building world TB --- 2013-02-21 12:27:31 - CROSS_BUILD_TESTING=YES TB --- 2013-02-21 12:27:31 - MAKEOBJDIRPREFIX=/obj TB --- 2013-02-21 12:27:31 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-02-21 12:27:31 - SRCCONF=/dev/null TB --- 2013-02-21 12:27:31 - TARGET=amd64 TB --- 2013-02-21 12:27:31 - TARGET_ARCH=amd64 TB --- 2013-02-21 12:27:31 - TZ=UTC TB --- 2013-02-21 12:27:31 - __MAKE_CONF=/dev/null TB --- 2013-02-21 12:27:31 - cd /src TB --- 2013-02-21 12:27:31 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Thu Feb 21 12:27:35 UTC 2013 >>> 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 Thu Feb 21 15:45:25 UTC 2013 TB --- 2013-02-21 15:45:25 - generating LINT kernel config TB --- 2013-02-21 15:45:25 - cd /src/sys/amd64/conf TB --- 2013-02-21 15:45:25 - /usr/bin/make -B LINT TB --- 2013-02-21 15:45:25 - cd /src/sys/amd64/conf TB --- 2013-02-21 15:45:25 - /usr/sbin/config -m LINT TB --- 2013-02-21 15:45:25 - building LINT kernel TB --- 2013-02-21 15:45:25 - CROSS_BUILD_TESTING=YES TB --- 2013-02-21 15:45:25 - MAKEOBJDIRPREFIX=/obj TB --- 2013-02-21 15:45:25 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-02-21 15:45:25 - SRCCONF=/dev/null TB --- 2013-02-21 15:45:25 - TARGET=amd64 TB --- 2013-02-21 15:45:25 - TARGET_ARCH=amd64 TB --- 2013-02-21 15:45:25 - TZ=UTC TB --- 2013-02-21 15:45:25 - __MAKE_CONF=/dev/null TB --- 2013-02-21 15:45:25 - cd /src TB --- 2013-02-21 15:45:25 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Feb 21 15:45:25 UTC 2013 >>> 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 -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -DGPROF -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mno-aes -mno-avx -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg /src/sys/dev/ppc/ppc.c /src/sys/dev/ppc/ppc.c:724:2: error: implicit declaration of function 'critical_leave' is invalid in C99 [-Werror,-Wimplicit-function-declaration] PPC_CONFIG_UNLOCK(ppc); ^ /src/sys/dev/ppc/ppc.c:91:33: note: expanded from macro 'PPC_CONFIG_UNLOCK' #define PPC_CONFIG_UNLOCK(ppc) critical_leave() ^ 1 error generated. *** [ppc.o] Error code 1 Stop in /obj/amd64.amd64/src/sys/LINT. *** [buildkernel] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-02-21 15:56:32 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-02-21 15:56:32 - ERROR: failed to build LINT kernel TB --- 2013-02-21 15:56:32 - 9823.25 user 1700.77 system 12974.48 real http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-amd64-amd64.full From owner-freebsd-current@FreeBSD.ORG Thu Feb 21 15:58:38 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id AA747861 for ; Thu, 21 Feb 2013 15:58:38 +0000 (UTC) (envelope-from nparhar@gmail.com) Received: from mail-da0-f46.google.com (mail-da0-f46.google.com [209.85.210.46]) by mx1.freebsd.org (Postfix) with ESMTP id 86466CA for ; Thu, 21 Feb 2013 15:58:38 +0000 (UTC) Received: by mail-da0-f46.google.com with SMTP id p5so4187817dak.5 for ; Thu, 21 Feb 2013 07:58:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:date:from:to:cc:subject:message-id:mail-followup-to :references:mime-version:content-type:content-disposition :in-reply-to:user-agent; bh=VXWHkj2yAeci/HNX0cWMfZh7F0prk17t7H3lG8+ecw0=; b=t+af5Lk67UoqQemSNpFiUaLO4Fhgk//AKBYrq/xKBT62FnqL4Ky7vkeHgsjDXKLK+5 gYzihd+RHygD0A8cKuFAE6FqlbB9XxZrfJAWe7csVo7athsAjohczybZskrdXd/rdMK0 W7FTLoZwycvufYQAn4xQa8Tdm3OfYFfLT0SHXiy7k+oTb9anpBHuE6mL6pollIQ5DuRI LLeb2ClBQgmw5weJsJrkUtBzi0Awu+CHvbG2OzAwMNK49VIvtQ78JOhdP4mV1SvvWxRi Ki8jM4f2nAU6zpgDercYF1bvroNRmOe6CU+MkLCzEQyXrLAOFyuwkOrt+2ffgN40Eqrl ru2Q== X-Received: by 10.66.222.35 with SMTP id qj3mr60233726pac.69.1361461977482; Thu, 21 Feb 2013 07:52:57 -0800 (PST) Received: from itx (c-24-6-45-85.hsd1.ca.comcast.net. [24.6.45.85]) by mx.google.com with ESMTPS id kl4sm11489857pbc.31.2013.02.21.07.52.56 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 21 Feb 2013 07:52:56 -0800 (PST) Date: Thu, 21 Feb 2013 07:52:53 -0800 From: Navdeep Parhar To: matt Subject: Re: r247095 Boot Failure Message-ID: <20130221155253.GB6838@itx> Mail-Followup-To: matt , Shawn Webb , FreeBSD-current References: <20130221153458.GA6838@itx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: FreeBSD-current , Shawn Webb X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 21 Feb 2013 15:58:38 -0000 On Thu, Feb 21, 2013 at 03:38:41PM +0000, matt wrote: > On Thu, Feb 21, 2013 at 3:34 PM, Navdeep Parhar wrote: > > > > > Take a look at the "-CURRENT userland regression" thread. You may be > > able to boot if you choose "safe mode" in the boot loader menu. > > > > Regards, > > Navdeep > > > > > What is safe mode as far as boot flags? This is the forth code that sets up safe mode: : safemode_enable ( -- ) s" set kern.smp.disabled=1" evaluate s" set hw.ata.ata_dma=0" evaluate s" set hw.ata.atapi_dma=0" evaluate s" set hw.ata.wc=0" evaluate s" set hw.eisa_slots=0" evaluate s" set kern.eventtimer.periodic=1" evaluate s" set kern.geom.part.check_integrity=0" evaluate ; loader.conf should be able to set up those variables too (temporarily, as a workaround). I wonder which one does the trick - smp.disabled or eventtimer_periodic, or ..? Regards, Navdeep > > boot -sv doesn't work on my system... > > Matt From owner-freebsd-current@FreeBSD.ORG Thu Feb 21 16:05:40 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id F03BEAF5 for ; Thu, 21 Feb 2013 16:05:40 +0000 (UTC) (envelope-from sendtomatt@gmail.com) Received: from mail-ve0-f177.google.com (mail-ve0-f177.google.com [209.85.128.177]) by mx1.freebsd.org (Postfix) with ESMTP id 8491D12A for ; Thu, 21 Feb 2013 16:05:40 +0000 (UTC) Received: by mail-ve0-f177.google.com with SMTP id m1so8033730ves.22 for ; Thu, 21 Feb 2013 08:05:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=PPHtF5j739f95/hLJqTHGO66SWJEEK8+05meq+797Eo=; b=MRgKZ5ptLmwKWoXDPltWepXrUZgC/vKJKmC7sn+brsbYF8YmtTyLkkbWF7bwZAMrYG /GyazuvscM3c5ycLQddeld8CsJSDhlK9yO+LycuBOu3cE2JGIjn7q72mpRxJZglVtFkv 9QeJ1CNej+QnIUKmBg2fpXiyTbsOPuma+Yrh1eXebUCSPekAQY8CwUzXlODF0ougETy8 iyUX/KaNVnFiV89eGc8OBWuOQY+5KR96tHC9VVi2boQ2GUyXfeO1T892IbTN6tZd8+g/ pGV3zhdP+NfxyPR8zgspcYWYCjz0KgjjxX8ac2tf30eMvNsWXqogfBuWa0g6VF4zG1/5 Ei8Q== MIME-Version: 1.0 X-Received: by 10.220.154.14 with SMTP id m14mr20325538vcw.21.1361462733996; Thu, 21 Feb 2013 08:05:33 -0800 (PST) Received: by 10.58.77.101 with HTTP; Thu, 21 Feb 2013 08:05:33 -0800 (PST) In-Reply-To: References: <20130221153458.GA6838@itx> Date: Thu, 21 Feb 2013 16:05:33 +0000 Message-ID: Subject: Re: r247095 Boot Failure From: matt To: Sergey Kandaurov Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: FreeBSD-current , nparhar@gmail.com, Shawn Webb X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 21 Feb 2013 16:05:41 -0000 On Thu, Feb 21, 2013 at 3:46 PM, Sergey Kandaurov wrote: > > > Currently that corresponds to: > set kern.smp.disabled=1 > set hw.ata.ata_dma=0 > set hw.ata.atapi_dma=0 > set hw.ata.wc=0 > set hw.eisa_slots=0 > set kern.eventtimer.periodic=1 > set kern.geom.part.check_integrity=0 > > See /boot/menu-commands.4th > > -- > wbr, > pluknet > Enabling beastie, safe mode boots. The userland thread wasn't terribly descriptive about symptoms, and this sure doesn't *look* like a userland problem. Trying to reduce it to a specific option First, no variables or alternate kernels work until I type show (that seems broken) Setting all of the kern variables allow it to boot Setting all of the hw.ata.*dma doesn't change anything Setting hw.ata.wc causes a panic/reboot Matt From owner-freebsd-current@FreeBSD.ORG Thu Feb 21 16:11:14 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 07391D40 for ; Thu, 21 Feb 2013 16:11:14 +0000 (UTC) (envelope-from sendtomatt@gmail.com) Received: from mail-ve0-f181.google.com (mail-ve0-f181.google.com [209.85.128.181]) by mx1.freebsd.org (Postfix) with ESMTP id BE97418F for ; Thu, 21 Feb 2013 16:11:13 +0000 (UTC) Received: by mail-ve0-f181.google.com with SMTP id d10so8038010vea.40 for ; Thu, 21 Feb 2013 08:11:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=0EkwFsF8ttz/a6dB0gjikLOgrJhddGzq2SJsEHPw08s=; b=n6ynS/NAqnVfsWlApUdBPz4TopDhoaUMIZc1veB0EpjzrKyJQjqQkMTKUx7w3WLesx ii5lFOQe8Bau5SLutXTkpEbQ30Wj51egCfNOGrPAAXk4In98k6O7GCdWVSiGzthBFH1n I7nz8YDJbcMgF5VJClUmUcG2Gj8XNgzYJM06uebG9nEDCAnoes2KH4C6WB77Qgy0t45t cY/A8apWDMdjARxGQV2fa894WLwN6O7WlUFLPsm1O7ZWMIuzK/3tn7rQBapqAEYY3c0z BLMKUeoV6QkRbwoQyE1F3Dzi5/6UKLcLyQmbfezmmwNDRq7/Co4E4p3O+BeKvPUtTGeo wfrQ== MIME-Version: 1.0 X-Received: by 10.220.205.195 with SMTP id fr3mr31588691vcb.6.1361463067731; Thu, 21 Feb 2013 08:11:07 -0800 (PST) Received: by 10.58.77.101 with HTTP; Thu, 21 Feb 2013 08:11:07 -0800 (PST) In-Reply-To: References: <20130221153458.GA6838@itx> Date: Thu, 21 Feb 2013 16:11:07 +0000 Message-ID: Subject: Re: r247095 Boot Failure From: matt To: Sergey Kandaurov Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: FreeBSD-current , nparhar@gmail.com, Shawn Webb X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 21 Feb 2013 16:11:14 -0000 > On Thu, Feb 21, 2013 at 3:46 PM, Sergey Kandaurov wrote: > >> >> >> Currently that corresponds to: >> set kern.smp.disabled=1 >> set hw.ata.ata_dma=0 >> set hw.ata.atapi_dma=0 >> set hw.ata.wc=0 >> set hw.eisa_slots=0 >> set kern.eventtimer.periodic=1 >> set kern.geom.part.check_integrity=0 >> >> See /boot/menu-commands.4th >> >> -- >> wbr, >> pluknet >> > > > > It's kern.smp.disabled=1 that allows boot. Matt From owner-freebsd-current@FreeBSD.ORG Thu Feb 21 16:13:45 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id EB39FEAB; Thu, 21 Feb 2013 16:13:45 +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 BB8C81DE; Thu, 21 Feb 2013 16:13:45 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r1LGDjJq052873; Thu, 21 Feb 2013 11:13:45 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r1LGDjbD052857; Thu, 21 Feb 2013 16:13:45 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 21 Feb 2013 16:13:45 GMT Message-Id: <201302211613.r1LGDjbD052857@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 , , Subject: [head tinderbox] failure on ia64/ia64 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 16:13:46 -0000 TB --- 2013-02-21 14:29:42 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-02-21 14:29:42 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-02-21 14:29:42 - starting HEAD tinderbox run for ia64/ia64 TB --- 2013-02-21 14:29:42 - cleaning the object tree TB --- 2013-02-21 14:30:53 - /usr/local/bin/svn stat /src TB --- 2013-02-21 14:30:56 - At svn revision 247093 TB --- 2013-02-21 14:30:57 - building world TB --- 2013-02-21 14:30:57 - CROSS_BUILD_TESTING=YES TB --- 2013-02-21 14:30:57 - MAKEOBJDIRPREFIX=/obj TB --- 2013-02-21 14:30:57 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-02-21 14:30:57 - SRCCONF=/dev/null TB --- 2013-02-21 14:30:57 - TARGET=ia64 TB --- 2013-02-21 14:30:57 - TARGET_ARCH=ia64 TB --- 2013-02-21 14:30:57 - TZ=UTC TB --- 2013-02-21 14:30:57 - __MAKE_CONF=/dev/null TB --- 2013-02-21 14:30:57 - cd /src TB --- 2013-02-21 14:30:57 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Thu Feb 21 14:31:01 UTC 2013 >>> 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 Thu Feb 21 16:04:28 UTC 2013 TB --- 2013-02-21 16:04:28 - generating LINT kernel config TB --- 2013-02-21 16:04:28 - cd /src/sys/ia64/conf TB --- 2013-02-21 16:04:28 - /usr/bin/make -B LINT TB --- 2013-02-21 16:04:28 - cd /src/sys/ia64/conf TB --- 2013-02-21 16:04:28 - /usr/sbin/config -m LINT TB --- 2013-02-21 16:04:28 - building LINT kernel TB --- 2013-02-21 16:04:28 - CROSS_BUILD_TESTING=YES TB --- 2013-02-21 16:04:28 - MAKEOBJDIRPREFIX=/obj TB --- 2013-02-21 16:04:28 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-02-21 16:04:28 - SRCCONF=/dev/null TB --- 2013-02-21 16:04:28 - TARGET=ia64 TB --- 2013-02-21 16:04:28 - TARGET_ARCH=ia64 TB --- 2013-02-21 16:04:28 - TZ=UTC TB --- 2013-02-21 16:04:28 - __MAKE_CONF=/dev/null TB --- 2013-02-21 16:04:28 - cd /src TB --- 2013-02-21 16:04:28 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Feb 21 16:04:28 UTC 2013 >>> 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 -fdiagnostics-show-option -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/ppbus/pps.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 -fdiagnostics-show-option -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/ppbus/vpo.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 -fdiagnostics-show-option -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/ppbus/vpoio.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 -fdiagnostics-show-option -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/ppc/ppc.c cc1: warnings being treated as errors /src/sys/dev/ppc/ppc.c: In function 'ppc_smc37c66xgt_detect': /src/sys/dev/ppc/ppc.c:724: warning: implicit declaration of function 'critical_leave' /src/sys/dev/ppc/ppc.c:724: warning: nested extern declaration of 'critical_leave' [-Wnested-externs] *** [ppc.o] Error code 1 Stop in /obj/ia64.ia64/src/sys/LINT. *** [buildkernel] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-02-21 16:13:45 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-02-21 16:13:45 - ERROR: failed to build LINT kernel TB --- 2013-02-21 16:13:45 - 4875.67 user 967.20 system 6242.40 real http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Thu Feb 21 16:48:38 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 9A388988 for ; Thu, 21 Feb 2013 16:48:38 +0000 (UTC) (envelope-from jmg@h2.funkthat.com) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) by mx1.freebsd.org (Postfix) with ESMTP id 7F4E23F1 for ; Thu, 21 Feb 2013 16:48:38 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id r1LGmWhW079767 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Feb 2013 08:48:32 -0800 (PST) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id r1LGmVW1079766; Thu, 21 Feb 2013 08:48:31 -0800 (PST) (envelope-from jmg) Date: Thu, 21 Feb 2013 08:48:31 -0800 From: John-Mark Gurney To: Shawn Webb Subject: Re: r247095 Boot Failure Message-ID: <20130221164831.GU55866@funkthat.com> Mail-Followup-To: Shawn Webb , FreeBSD-current References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Thu, 21 Feb 2013 08:48:32 -0800 (PST) Cc: FreeBSD-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 21 Feb 2013 16:48:38 -0000 Shawn Webb wrote this message on Thu, Feb 21, 2013 at 10:28 -0500: > I'm on r247095. My box is failing to boot on a Dell Precision T7500. I'm > running ZFS as root with a mirrored root pool. > > Here's a pic of the box failing: > https://lh5.googleusercontent.com/-Lq_jlX8of0o/USY4cqZ5BOI/AAAAAAAAGoI/Nd1LGPbFjHc/s1112/IMG_20130221_100723.jpg > > There isn't much useful information in the pic. No crash dump is generated. > Where do I go from here? > > I can boot into kernel.old and that works as a workaround for now. Some how, my changes to gcc in r247012 is causing this, even when using the default of clang as cc... I was able to reproduce a crash myself, and then I just backed my change and the new kernel booted... I'm about to do a binary diff between the broken kernel and the new kernel (since I only installed the kernel, not userland) and figure out which part of the system.. But clearly, we are still using gcc somehow in our kernel builds... If I don't figure out what it is in a few hours, I'll back out the change... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-current@FreeBSD.ORG Thu Feb 21 16:55:33 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 7B718BF1; Thu, 21 Feb 2013 16:55:33 +0000 (UTC) (envelope-from jmg@h2.funkthat.com) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) by mx1.freebsd.org (Postfix) with ESMTP id 251A2686; Thu, 21 Feb 2013 16:55:32 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id r1LGtRru079877 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Feb 2013 08:55:27 -0800 (PST) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id r1LGtRju079876; Thu, 21 Feb 2013 08:55:27 -0800 (PST) (envelope-from jmg) Date: Thu, 21 Feb 2013 08:55:27 -0800 From: John-Mark Gurney To: Andriy Gapon Subject: Re: -CURRENT userland regression Message-ID: <20130221165527.GV55866@funkthat.com> Mail-Followup-To: Andriy Gapon , d@delphij.net, Konstantin Belousov , FreeBSD Current , Xin Li , Navdeep Parhar References: <51254ACE.2030100@delphij.net> <51254C7E.9050705@gmail.com> <20130220222518.GT2598@kib.kiev.ua> <51254E51.1070702@delphij.net> <20130220223704.GU2598@kib.kiev.ua> <5125595D.5010508@delphij.net> <5125D8A6.2050409@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5125D8A6.2050409@FreeBSD.org> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Thu, 21 Feb 2013 08:55:27 -0800 (PST) Cc: Konstantin Belousov , Xin Li , FreeBSD Current , d@delphij.net, Navdeep Parhar X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 21 Feb 2013 16:55:33 -0000 Andriy Gapon wrote this message on Thu, Feb 21, 2013 at 10:19 +0200: > on 21/02/2013 01:16 Xin Li said the following: > > I think it's unlikely -- I have r247057 of sys/ which worked fine... > > > > userland 246957 works good by the way. > > Just a very wild guess - are you sure that it is the userland that is to blame? > It is rather unfortunate that we install boot blocks, including loader which > gets _really_ installed, as part of installworld (and they are built as part of > buildworld). So there is a possibility that it is loader that causes the > trouble. I would try to rule that out. As I posted in a different thread, apparently my gcc AES changes (r247012) manages to break a clang built kernel... I'm in the process of debugging right now... I did the usual: make buildworld && make buildkernel && make installkernel && shutdown -r now and the kernel hung... I then reverted r247012 and did the above again, and the machine is running again: FreeBSD carbon.funkthat.com 10.0-CURRENT FreeBSD 10.0-CURRENT #4 r247075M: Thu Feb 21 00:49:57 PST 2013 jmg@carbon.funkthat.com:/usr/obj/usr/src/sys/GENERIC amd64 And I haven't installworld yet... so somehow supporting the AES instructions in gcc causes the kernel to miscompile... I'm now going to diff the two kernels to find out what's different... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-current@FreeBSD.ORG Thu Feb 21 17:03:08 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 93CC64E3; Thu, 21 Feb 2013 17:03:08 +0000 (UTC) (envelope-from ringwormezc33@gmail.com) Received: from 86-43-190-227-dynamic.b-ras1.pgs.portlaoise.eircom.net (86-43-190-227-dynamic.b-ras1.pgs.portlaoise.eircom.net [86.43.190.227]) by mx1.freebsd.org (Postfix) with ESMTP id 07C5773B; Thu, 21 Feb 2013 17:03:08 +0000 (UTC) Received: from 86.43.190.227(helo=freebsd.org) by freebsd.org with esmtpa (Exim 4.69) (envelope-from ) id 1MM3CN-5021ff-JJ for ; Thu, 21 Feb 2013 12:02:38 +0000 From: , , , To: , , , Subject: make huge daily income from scratch Date: Thu, 21 Feb 2013 12:02:38 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Mailer: bnkhrs.27 Message-ID: <1020782674.8759E269048000@glfuslzv.ojfby.su> X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 21 Feb 2013 17:03:08 -0000 How does making $70 EVERY 60 Seconds sound to you? To thousnds before you, it's a reality as seen on CNN, NBC, Fox, and USA Today I've reserved a special Access Link For You: http://archemakersmone.com/ But you only have 4.5 hours to access it I'll see you on the other side. From owner-freebsd-current@FreeBSD.ORG Thu Feb 21 17:24:38 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id AC372141; Thu, 21 Feb 2013 17:24:38 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 806BD8D6; Thu, 21 Feb 2013 17:24:38 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r1LHObVV021593; Thu, 21 Feb 2013 12:24:37 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r1LHObA4021586; Thu, 21 Feb 2013 17:24:37 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 21 Feb 2013 17:24:37 GMT Message-Id: <201302211724.r1LHObA4021586@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 , , Subject: [head tinderbox] failure on i386/pc98 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 17:24:38 -0000 TB --- 2013-02-21 14:22:13 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-02-21 14:22:13 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-02-21 14:22:13 - starting HEAD tinderbox run for i386/pc98 TB --- 2013-02-21 14:22:13 - cleaning the object tree TB --- 2013-02-21 14:23:13 - /usr/local/bin/svn stat /src TB --- 2013-02-21 14:23:18 - At svn revision 247093 TB --- 2013-02-21 14:23:19 - building world TB --- 2013-02-21 14:23:19 - CROSS_BUILD_TESTING=YES TB --- 2013-02-21 14:23:19 - MAKEOBJDIRPREFIX=/obj TB --- 2013-02-21 14:23:19 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-02-21 14:23:19 - SRCCONF=/dev/null TB --- 2013-02-21 14:23:19 - TARGET=pc98 TB --- 2013-02-21 14:23:19 - TARGET_ARCH=i386 TB --- 2013-02-21 14:23:19 - TZ=UTC TB --- 2013-02-21 14:23:19 - __MAKE_CONF=/dev/null TB --- 2013-02-21 14:23:19 - cd /src TB --- 2013-02-21 14:23:19 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Thu Feb 21 14:23:24 UTC 2013 >>> 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 Thu Feb 21 17:16:41 UTC 2013 TB --- 2013-02-21 17:16:41 - generating LINT kernel config TB --- 2013-02-21 17:16:41 - cd /src/sys/pc98/conf TB --- 2013-02-21 17:16:41 - /usr/bin/make -B LINT TB --- 2013-02-21 17:16:41 - cd /src/sys/pc98/conf TB --- 2013-02-21 17:16:41 - /usr/sbin/config -m LINT TB --- 2013-02-21 17:16:41 - building LINT kernel TB --- 2013-02-21 17:16:41 - CROSS_BUILD_TESTING=YES TB --- 2013-02-21 17:16:41 - MAKEOBJDIRPREFIX=/obj TB --- 2013-02-21 17:16:41 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-02-21 17:16:41 - SRCCONF=/dev/null TB --- 2013-02-21 17:16:41 - TARGET=pc98 TB --- 2013-02-21 17:16:41 - TARGET_ARCH=i386 TB --- 2013-02-21 17:16:41 - TZ=UTC TB --- 2013-02-21 17:16:41 - __MAKE_CONF=/dev/null TB --- 2013-02-21 17:16:41 - cd /src TB --- 2013-02-21 17:16:41 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Feb 21 17:16:41 UTC 2013 >>> 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 -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -DGPROF -DGPROF4 -DGUPROF -fno-builtin -mno-aes -mno-avx -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -Werror -pg /src/sys/dev/ppc/ppc.c /src/sys/dev/ppc/ppc.c:724:2: error: implicit declaration of function 'critical_leave' is invalid in C99 [-Werror,-Wimplicit-function-declaration] PPC_CONFIG_UNLOCK(ppc); ^ /src/sys/dev/ppc/ppc.c:91:33: note: expanded from macro 'PPC_CONFIG_UNLOCK' #define PPC_CONFIG_UNLOCK(ppc) critical_leave() ^ 1 error generated. *** [ppc.o] Error code 1 Stop in /obj/pc98.i386/src/sys/LINT. *** [buildkernel] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-02-21 17:24:37 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-02-21 17:24:37 - ERROR: failed to build LINT kernel TB --- 2013-02-21 17:24:37 - 8611.15 user 1339.27 system 10943.82 real http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Thu Feb 21 17:33:23 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 2BCF83F9 for ; Thu, 21 Feb 2013 17:33:23 +0000 (UTC) (envelope-from clbuisson@orange.fr) Received: from smtp.smtpout.orange.fr (smtp04.smtpout.orange.fr [80.12.242.126]) by mx1.freebsd.org (Postfix) with ESMTP id 9C32E967 for ; Thu, 21 Feb 2013 17:33:22 +0000 (UTC) Received: from localhost ([109.223.1.180]) by mwinf5d51 with ME id 35ZD1l00y3t1atZ035ZEnW; Thu, 21 Feb 2013 18:33:14 +0100 Message-ID: <51265A58.4010600@orange.fr> Date: Thu, 21 Feb 2013 18:33:12 +0100 From: Claude Buisson User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:10.0.12) Gecko/20130109 Thunderbird/10.0.12 MIME-Version: 1.0 To: FreeBSD Current Subject: DVD/CD lost after r246713 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 21 Feb 2013 17:33:23 -0000 Hi, When trying to update a i386 system from r245422 to r246923, the DVD/CD devices cd0/cd1 could no more be attached. Here is a relevant part of a verbose dmaeg: pass0 at ata0 bus 0 scbus0 target 0 lun 0 pass0: ATA-8 device pass0: Serial Number WD-WCAV2F115406 pass0: 100.000MB/s transfers (UDMA5, PIO 8192bytes) pass1 at ata0 bus 0 scbus0 target 1 lun 0 pass1: ATA-5 device pass1: Serial Number WD-WMA8F2128712 pass1: 100.000MB/s transfers (UDMA5, PIO 8192bytes) pass2 at ata1 bus 0 scbus1 target 0 lun 0 pass2: Removable CD-ROM SCSI-0 device pass2: 33.300MB/s transfers (UDMA2, ATAPI 12bytes, PIO 65534bytes) pass3 at ata1 bus 0 scbus1 target 1 lun 0 pass3: Removable CD-ROM SCSI-0 device pass3: 33.300MB/s transfers (UDMA2, ATAPI 12bytes, PIO 65534bytes) TSC timecounter discards lower 1 bit(s) Timecounter "TSC-low" frequency 1196040076 Hz quality 800 uhub0: 2 ports with 2 removable, self powered uhub1: 2 ports with 2 removable, self powered uhub2: 2 ports with 2 removable, self powered GEOM: new disk cd0 GEOM: new disk cd1 GEOM: new disk ada0 GEOM: new disk ada1 uhub3: 6 ports with 6 removable, self powered ugen0.2: at usbus0 ums0: on usbus0 ums0: 3 buttons and [XYZ] coordinates ID=0 ata1: reset tp1 mask=03 ostat0=d0 ostat1=50 ata1: stat0=0x10 err=0x01 lsb=0x14 msb=0xeb ata1: stat1=0x10 err=0x01 lsb=0x14 msb=0xeb ata1: reset tp2 stat0=10 stat1=10 devices=0x30000 (cd0:ata1:0:0:0): got CAM status 0x50 (cd0:ata1:0:0:0): fatal error, failed to attach to device (cd0:ata1:0:0:0): lost device, 4 refs Opened disk cd0 -> 6 (cd0:ata1:0:0:0): removing device entryata1: reset tp1 mask=03 ostat0=50 ostat1=d0 ata1: stat0=0x10 err=0x01 lsb=0x14 msb=0xeb ata1: stat1=0x10 err=0x01 lsb=0x14 msb=0xeb ata1: reset tp2 stat0=10 stat1=10 devices=0x30000 (cd1:ata1:0:1:0): got CAM status 0x50 (cd1:ata1:0:1:0): fatal error, failed to attach to device (cd1:ata1:0:1:0): lost device, 4 refs Opened disk cd1 -> 6 (cd1:ata1:0:1:0): removing device entry First i tried some snapshots from allbsd.org, to verify that the same problem existed with independently generated systems, then I made a search to find that the "culprit" was: Author: kib Date: Tue Feb 12 16:57:20 2013 New Revision: 246713 URL: http://svnweb.freebsd.org/changeset/base/246713 Log: Reform the busdma API so that new types may be added without modifying every architecture's busdma_machdep.c. It is done by unifying the bus_dmamap_load_buffer() routines so that they may be called from MI code. The MD busdma is then given a chance to do any final processing in the complete() callback. The cam changes unify the bus_dmamap_load* handling in cam drivers. The arm and mips implementations are updated to track virtual addresses for sync(). Previously this was done in a type specific way. Now it is done in a generic way by recording the list of virtuals in the map. Submitted by: jeff (sponsored by EMC/Isilon) Reviewed by: kan (previous version), scottl, mjacob (isp(4), no objections for target mode changes) Discussed with: ian (arm changes) Tested by: marius (sparc64), mips (jmallet), isci(4) on x86 (jharris), amd64 (Fabian Keil ) I even tried to rebuild the system WITHOUT_CLANG, just to eliminate the "compiler factor" (with r247000 applied of course). If necessary I can send complete verbose dmesg at r245422 and r246923. Thanks for your attention CBu P.S. GREAT THANKS to allbsd.org for this its very useful collection of working memstick images ! but with the remark that the documented revision numbers seems to be inexacts: the 246711 snapshot exhibited this same problem (?!) From owner-freebsd-current@FreeBSD.ORG Thu Feb 21 17:49:08 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 3AD12A7C for ; Thu, 21 Feb 2013 17:49:08 +0000 (UTC) (envelope-from decke@bluelife.at) Received: from mail-ob0-f176.google.com (mail-ob0-f176.google.com [209.85.214.176]) by mx1.freebsd.org (Postfix) with ESMTP id 02ABAA8E for ; Thu, 21 Feb 2013 17:49:07 +0000 (UTC) Received: by mail-ob0-f176.google.com with SMTP id v19so9032286obq.21 for ; Thu, 21 Feb 2013 09:49:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bluelife.at; s=google; h=mime-version:x-received:sender:x-originating-ip:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=HWdix2hH2cQ7i8m7e9NukAW14ST6om4cW/OVYMo0c8s=; b=Fvhra+evnfGDi5cFZKdRtdtAPCzF6eBxwbbPWpFfMyEplIIkFPiCX7k6E7axG0K+2V Qa0uSVWG7Nt4zWGiPteN/ktms2gQ38gWlBzBUqARqP49oKBsIhx4pRQu1FV5wtukRfCw wpO/xLc8x3ERk8eei0kqPW821ZKT33u10HBP8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:sender:x-originating-ip:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:x-gm-message-state; bh=HWdix2hH2cQ7i8m7e9NukAW14ST6om4cW/OVYMo0c8s=; b=ZtyfiZ6ThjlZw6qHcaDBw6F4f0ZzJ3DPHpTzZurlo0VZrdoFjkYcW60erdFiqDD/G6 /lL5p4HixXty0xSX/gXZRUEQmjzX3NXoYy+jAE0HeGpvmWNb54pMhBh6Yu3TwLaz6v7P arbdQBB1VG+Q05qb8dcT2E/B0TBrqUW3pQeGxZhIkjzeY3y+WuLWMTcvE5tNjYasXQPU D2DjZqQOI6wbfdgT6jCn2yU4jliY2AOwQdtyplg81IXjr8vFFmCOI+2ETZkjkF5NG4vA PgaqOPx1ZV6Y/SGuoLVCaUveZYt2pwDbsP8nrJimkQhFy6hkCFp9U4IfCkVtRAK6OW68 oAyQ== MIME-Version: 1.0 X-Received: by 10.60.170.20 with SMTP id ai20mr11566684oec.33.1361468947211; Thu, 21 Feb 2013 09:49:07 -0800 (PST) Sender: decke@bluelife.at Received: by 10.76.136.237 with HTTP; Thu, 21 Feb 2013 09:49:06 -0800 (PST) X-Originating-IP: [2001:470:9bf5:200:21c:23ff:fe94:8591] In-Reply-To: References: <51263782.3020205@freebsd.org> Date: Thu, 21 Feb 2013 18:49:07 +0100 X-Google-Sender-Auth: JgDpINHExu02L3StUb3hqB-TdXA Message-ID: Subject: Re: FreeBSD Testing Facility From: =?ISO-8859-1?Q?Bernhard_Fr=F6hlich?= To: Mehmet Erol Sanliturk Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQnGl9E29vyHlRpNCJ7w3G/wkkL+5S9nAGf1zBXziayowlmaobrYGeANEDvpNgTm+AzS2FK0 Cc: Alexander Yerenkow , mjacob@freebsd.org, freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 21 Feb 2013 17:49:08 -0000 On Thu, Feb 21, 2013 at 4:43 PM, Mehmet Erol Sanliturk wrote: > On Thu, Feb 21, 2013 at 7:32 AM, Alexander Yerenkow wrote: > >> Decent testing system is a pretty complex system to be. >> I spent some time in this area, and gave it up, at least till better times >> :) >> >> But anyway, at least booting/working network stack/firewall could be >> easily tested with VMs. >> There just need to be a person dedicated to this, which is lacking now. >> >> >> -- >> Regards, >> Alexander Yerenkow > > > > With "BOINC" , people are trying to solve very complex problems by > contributing as much as what they can do to solve its parts . > > A similar structure may be established for FreeBSD . > > As an example , booting in virtual machine may be possible , but in a real > machine may not work . > Some main boards may work , but others may not work . > > The FreeBSD project can not establish a very large testing farm . > > People wanting to participate may contribute very much . > > Every one will not test every thing . We certainly want to have a system that allows to perform tests in an automated fashion. Both compile and runtime tests but I don't see us running a huge lab of desktop or even worse laptop class hardware to verify that everything works. So the only way to go is limited testing if a new snapshot runs at all and then perform a few runtime tests and probably some benchmarks to find major regressions. Running a BOINC kind of system sounds like out of reach and not worth the work. BOINC works because it's cool to find aliens or prove that Einstein was wrong but testing software is not cool. In your special case it looks like you hit some bug so please file a PR and provide as much details as possible to track down what is causing this. -- Bernhard Froehlich http://www.bluelife.at/ From owner-freebsd-current@FreeBSD.ORG Thu Feb 21 17:51:37 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 0E895E06; Thu, 21 Feb 2013 17:51:37 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from hammer.pct.niksun.com (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 835FBAE6; Thu, 21 Feb 2013 17:51:36 +0000 (UTC) Message-ID: <51265E39.2070109@FreeBSD.org> Date: Thu, 21 Feb 2013 12:49:45 -0500 From: Jung-uk Kim User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130220 Thunderbird/17.0.3 MIME-Version: 1.0 To: John Baldwin Subject: Re: -CURRENT userland regression References: <51254ACE.2030100@delphij.net> <51254C7E.9050705@gmail.com> <201302211031.31599.jhb@freebsd.org> In-Reply-To: <201302211031.31599.jhb@freebsd.org> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, Xin Li , Navdeep Parhar X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 21 Feb 2013 17:51:37 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2013-02-21 10:31:31 -0500, John Baldwin wrote: > On Wednesday, February 20, 2013 5:21:50 pm Navdeep Parhar wrote: >> On 02/20/13 14:14, Xin Li wrote: >>> Hi, >>> >>> It seems that fresh -HEAD would give an unusable kernel that >>> overwrites screen buffer in a way making it impossible to >>> debug. Using an old world source to do 'make buildworld >>> buildkernel' results in a (mostly: I have some strange USB >>> issue right now and still looking for the cause) usable >>> kernel. >>> >>> For now my known good combination is world 246858 with kernel >>> 247057. I'm still trying to find out which revision have broke >>> the stuff. >> >> I ran into this earlier today. Selecting "safe mode" in the boot >> loader menu seems to work around the problem on my system. Now I >> will not reboot until I see a fix for this in head :-) > > "safe mode" toggles a few different things IIRC, can you narrow it > down to a single setting? kern.smp.disabled=1 Jung-uk Kim -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQEcBAEBAgAGBQJRJl45AAoJECXpabHZMqHO/I0IALhqfW2uSY+IoCOvtSN7eQGM IRmzRiFtoz7sXb5OiNlHjwZdRcQR4t6656EUyItDjr3XbXvnGaNL/nk+B9moSgSi NmHpEWQ4yNTJKYUAnvw4NGHKkiOpmNsrAA5i8EEQQesQGuwke0eYaeHMb5R5Wvsu lyWTB0ZH1XV8VehvTir3vo7MWaGjYYp8l09YpaDUYTpn364Fx+jBgsG5qKWdrHMn l/TwMLmWB6Mij2K8+FeS9PIijFKhaTh2s5xa1/xX3vFuR0mhMfNm7OfadXy1KKsL YcTm4Q0QYDkfoxwoS6+AWKVk1LMrF8vah8kHalKp5JCtNv3p1jr5RupalYI9zgo= =1D9R -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Thu Feb 21 18:44:21 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 4B9F1257; Thu, 21 Feb 2013 18:44: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 2199CFF4; Thu, 21 Feb 2013 18:44:20 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r1LIiK6k052870; Thu, 21 Feb 2013 13:44:20 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r1LIiKpg052869; Thu, 21 Feb 2013 18:44:20 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 21 Feb 2013 18:44:20 GMT Message-Id: <201302211844.r1LIiKpg052869@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 , , Subject: [head tinderbox] failure on sparc64/sparc64 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 18:44:21 -0000 TB --- 2013-02-21 17:28:41 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-02-21 17:28:41 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-02-21 17:28:41 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2013-02-21 17:28:41 - cleaning the object tree TB --- 2013-02-21 17:30:05 - /usr/local/bin/svn stat /src TB --- 2013-02-21 17:30:08 - At svn revision 247093 TB --- 2013-02-21 17:30:09 - building world TB --- 2013-02-21 17:30:09 - CROSS_BUILD_TESTING=YES TB --- 2013-02-21 17:30:09 - MAKEOBJDIRPREFIX=/obj TB --- 2013-02-21 17:30:09 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-02-21 17:30:09 - SRCCONF=/dev/null TB --- 2013-02-21 17:30:09 - TARGET=sparc64 TB --- 2013-02-21 17:30:09 - TARGET_ARCH=sparc64 TB --- 2013-02-21 17:30:09 - TZ=UTC TB --- 2013-02-21 17:30:09 - __MAKE_CONF=/dev/null TB --- 2013-02-21 17:30:09 - cd /src TB --- 2013-02-21 17:30:09 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Thu Feb 21 17:30:14 UTC 2013 >>> 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 Thu Feb 21 18:31:42 UTC 2013 TB --- 2013-02-21 18:31:42 - generating LINT kernel config TB --- 2013-02-21 18:31:42 - cd /src/sys/sparc64/conf TB --- 2013-02-21 18:31:42 - /usr/bin/make -B LINT TB --- 2013-02-21 18:31:42 - cd /src/sys/sparc64/conf TB --- 2013-02-21 18:31:42 - /usr/sbin/config -m LINT TB --- 2013-02-21 18:31:42 - building LINT kernel TB --- 2013-02-21 18:31:42 - CROSS_BUILD_TESTING=YES TB --- 2013-02-21 18:31:42 - MAKEOBJDIRPREFIX=/obj TB --- 2013-02-21 18:31:42 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-02-21 18:31:42 - SRCCONF=/dev/null TB --- 2013-02-21 18:31:42 - TARGET=sparc64 TB --- 2013-02-21 18:31:42 - TARGET_ARCH=sparc64 TB --- 2013-02-21 18:31:42 - TZ=UTC TB --- 2013-02-21 18:31:42 - __MAKE_CONF=/dev/null TB --- 2013-02-21 18:31:42 - cd /src TB --- 2013-02-21 18:31:42 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Feb 21 18:31:43 UTC 2013 >>> 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 -fdiagnostics-show-option -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/pci/amdsmb.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 -fdiagnostics-show-option -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/pci/if_rl.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 -fdiagnostics-show-option -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/pci/intpm.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 -fdiagnostics-show-option -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/pci/ncr.c /src/sys/pci/ncr.c: In function 'ncr_get_nccb': /src/sys/pci/ncr.c:6428: error: 's' undeclared (first use in this function) /src/sys/pci/ncr.c:6428: error: (Each undeclared identifier is reported only once /src/sys/pci/ncr.c:6428: error: for each function it appears in.) *** [ncr.o] Error code 1 Stop in /obj/sparc64.sparc64/src/sys/LINT. *** [buildkernel] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-02-21 18:44:20 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-02-21 18:44:20 - ERROR: failed to build LINT kernel TB --- 2013-02-21 18:44:20 - 3746.95 user 613.52 system 4539.06 real http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Thu Feb 21 18:45:29 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 89B724C2; Thu, 21 Feb 2013 18:45:29 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id DA0D68D; Thu, 21 Feb 2013 18:45:28 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.6/8.14.6) with ESMTP id r1LIjFlg060448; Thu, 21 Feb 2013 20:45:15 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.7.4 kib.kiev.ua r1LIjFlg060448 Received: (from kostik@localhost) by tom.home (8.14.6/8.14.6/Submit) id r1LIjFXi060447; Thu, 21 Feb 2013 20:45:15 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 21 Feb 2013 20:45:15 +0200 From: Konstantin Belousov To: Jung-uk Kim Subject: Re: -CURRENT userland regression Message-ID: <20130221184515.GA2598@kib.kiev.ua> References: <51254ACE.2030100@delphij.net> <51254C7E.9050705@gmail.com> <201302211031.31599.jhb@freebsd.org> <51265E39.2070109@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Zif13CGLAmVnkPyw" Content-Disposition: inline In-Reply-To: <51265E39.2070109@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: jmg@freebsd.org, freebsd-current@freebsd.org, Xin Li , Navdeep Parhar X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 21 Feb 2013 18:45:29 -0000 --Zif13CGLAmVnkPyw Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Feb 21, 2013 at 12:49:45PM -0500, Jung-uk Kim wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > On 2013-02-21 10:31:31 -0500, John Baldwin wrote: > > On Wednesday, February 20, 2013 5:21:50 pm Navdeep Parhar wrote: > >> On 02/20/13 14:14, Xin Li wrote: > >>> Hi, > >>>=20 > >>> It seems that fresh -HEAD would give an unusable kernel that=20 > >>> overwrites screen buffer in a way making it impossible to > >>> debug. Using an old world source to do 'make buildworld > >>> buildkernel' results in a (mostly: I have some strange USB > >>> issue right now and still looking for the cause) usable > >>> kernel. > >>>=20 > >>> For now my known good combination is world 246858 with kernel > >>> 247057. I'm still trying to find out which revision have broke > >>> the stuff. > >>=20 > >> I ran into this earlier today. Selecting "safe mode" in the boot > >> loader menu seems to work around the problem on my system. Now I > >> will not reboot until I see a fix for this in head :-) > >=20 > > "safe mode" toggles a few different things IIRC, can you narrow it > > down to a single setting? > > kern.smp.disabled=3D1 As the public service announcement, jmg will commit the following patch. Until that, apply and rebuild both world and kernel. diff --git a/contrib/binutils/opcodes/i386-opc.h b/contrib/binutils/opcodes= /i386-opc.h index 45589d8..27c1dab 100644 --- a/contrib/binutils/opcodes/i386-opc.h +++ b/contrib/binutils/opcodes/i386-opc.h @@ -73,15 +73,16 @@ typedef struct template #define CpuSSE4_2 0x800000 /* SSE4.2 Instructions required */ #define CpuXSAVE 0x1000000 /* XSAVE Instructions required */ #define CpuAES 0x2000000 /* AES Instructions required */ -#define CpuPCLMUL 0x4000000 /* Carry-less Multiplication extensions */ - -/* SSE4.1/4.2 Instructions required */ -#define CpuSSE4 (CpuSSE4_1|CpuSSE4_2) =20 /* These flags are set by gas depending on the flag_code. */ #define Cpu64 0x4000000 /* 64bit support required */ #define CpuNo64 0x8000000 /* Not supported in the 64bit mode */ =20 +#define CpuPCLMUL 0x10000000 /* Carry-less Multiplication extensions */ + +/* SSE4.1/4.2 Instructions required */ +#define CpuSSE4 (CpuSSE4_1|CpuSSE4_2) + /* The default value for unknown CPUs - enable all features to avoid pro= blems. */ #define CpuUnknownFlags (Cpu186|Cpu286|Cpu386|Cpu486|Cpu586|Cpu686 \ |CpuP4|CpuSledgehammer|CpuMMX|CpuMMX2|CpuSSE|CpuSSE2|CpuSSE3|CpuVMX \ --Zif13CGLAmVnkPyw Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJRJms6AAoJEJDCuSvBvK1Bh4wP/2WSxGETb3XGEhM4j8LXiUZT TZ2ju7e4o1eVwvgZ33dabDgEudB6UiphJTs0uVHFDk3WEWKXIwoKxIkUNPa7LtHD PUu4KuB6KD7peBADfFEmcLmY2lb10d8BGEnagVtvfygDCtAGmwYLx8Wpdf6KTgR2 v+gVpkLQM2bfA7lXnqzNFeUAtHUYBWzRIMh+W44hEDIrzAWnO0tDUjlDWMOcmmCV i+kHoKxja0TJreu8BaCwF3asbwvGcHiEzKKRKVcttoX7ErAjKAaoZMQB0vB8xuK/ tW9MlqB0OnMaZMYAV3bYJrDHRGp8xr8hmOJZp+rWl3y9sln/pgdGkIfdJam6khJI NC5cBYhcGK2/PV0YJwjQz8OTWI2eKVScw/yJmhyGytgzsV7S2Lo3ak0+Rjp8A9zF ZrCFEmQzmyRKDT0oHBHRZknqryCoB8Dz0glPtppfNDnWjQvODWdm2p7fjKdc8I4r g0r6/8eaVRyARprOr5sfpIzqOgUgiccWUazjeC8RtnSNmJkpbUFnvuOC+KYZ1/Au d/8Q6vLyn7FUSbk/6q4o+Es79iCQvJWQHn7dUId1YumnDMrf3N++fQNsgIaEkkBD P00k4R31HbP5fG4hN1oNZ8UAFi2Lli0GZX25wTSMgQtySzfpa+P5EApa1701ZN/l LzpyweD9kawucMK/AE5V =W/YG -----END PGP SIGNATURE----- --Zif13CGLAmVnkPyw-- From owner-freebsd-current@FreeBSD.ORG Thu Feb 21 18:46:35 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id DF36F5DF; Thu, 21 Feb 2013 18:46: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 B61C9D4; Thu, 21 Feb 2013 18:46:35 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r1LIkZi4054886; Thu, 21 Feb 2013 13:46:35 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r1LIkZGV054885; Thu, 21 Feb 2013 18:46:35 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 21 Feb 2013 18:46:35 GMT Message-Id: <201302211846.r1LIkZGV054885@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 , , Subject: [head tinderbox] failure on powerpc/powerpc Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 18:46:36 -0000 TB --- 2013-02-21 16:13:45 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-02-21 16:13:45 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-02-21 16:13:45 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2013-02-21 16:13:45 - cleaning the object tree TB --- 2013-02-21 16:14:47 - /usr/local/bin/svn stat /src TB --- 2013-02-21 16:14:51 - At svn revision 247093 TB --- 2013-02-21 16:14:52 - building world TB --- 2013-02-21 16:14:52 - CROSS_BUILD_TESTING=YES TB --- 2013-02-21 16:14:52 - MAKEOBJDIRPREFIX=/obj TB --- 2013-02-21 16:14:52 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-02-21 16:14:52 - SRCCONF=/dev/null TB --- 2013-02-21 16:14:52 - TARGET=powerpc TB --- 2013-02-21 16:14:52 - TARGET_ARCH=powerpc TB --- 2013-02-21 16:14:52 - TZ=UTC TB --- 2013-02-21 16:14:52 - __MAKE_CONF=/dev/null TB --- 2013-02-21 16:14:52 - cd /src TB --- 2013-02-21 16:14:52 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Thu Feb 21 16:14:56 UTC 2013 >>> 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 Thu Feb 21 18:37:32 UTC 2013 TB --- 2013-02-21 18:37:32 - generating LINT kernel config TB --- 2013-02-21 18:37:32 - cd /src/sys/powerpc/conf TB --- 2013-02-21 18:37:32 - /usr/bin/make -B LINT TB --- 2013-02-21 18:37:32 - cd /src/sys/powerpc/conf TB --- 2013-02-21 18:37:32 - /usr/sbin/config -m LINT TB --- 2013-02-21 18:37:33 - building LINT kernel TB --- 2013-02-21 18:37:33 - CROSS_BUILD_TESTING=YES TB --- 2013-02-21 18:37:33 - MAKEOBJDIRPREFIX=/obj TB --- 2013-02-21 18:37:33 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-02-21 18:37:33 - SRCCONF=/dev/null TB --- 2013-02-21 18:37:33 - TARGET=powerpc TB --- 2013-02-21 18:37:33 - TARGET_ARCH=powerpc TB --- 2013-02-21 18:37:33 - TZ=UTC TB --- 2013-02-21 18:37:33 - __MAKE_CONF=/dev/null TB --- 2013-02-21 18:37:33 - cd /src TB --- 2013-02-21 18:37:33 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Feb 21 18:37:33 UTC 2013 >>> 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 -O -pipe -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 -fdiagnostics-show-option -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 -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/pci/amdsmb.c cc -c -O -pipe -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 -fdiagnostics-show-option -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 -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/pci/if_rl.c cc -c -O -pipe -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 -fdiagnostics-show-option -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 -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/pci/intpm.c cc -c -O -pipe -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 -fdiagnostics-show-option -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 -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/pci/ncr.c /src/sys/pci/ncr.c: In function 'ncr_get_nccb': /src/sys/pci/ncr.c:6428: error: 's' undeclared (first use in this function) /src/sys/pci/ncr.c:6428: error: (Each undeclared identifier is reported only once /src/sys/pci/ncr.c:6428: error: for each function it appears in.) *** [ncr.o] Error code 1 Stop in /obj/powerpc.powerpc/src/sys/LINT. *** [buildkernel] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-02-21 18:46:35 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-02-21 18:46:35 - ERROR: failed to build LINT kernel TB --- 2013-02-21 18:46:35 - 7744.05 user 1018.01 system 9169.80 real http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Thu Feb 21 19:45:34 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 1272A444 for ; Thu, 21 Feb 2013 19:45:34 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id CB1DC6AB for ; Thu, 21 Feb 2013 19:45:33 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) with esmtp (envelope-from ) id <1U8c0f-000abT-O7>; Thu, 21 Feb 2013 20:40:49 +0100 Received: from e178033185.adsl.alicedsl.de ([85.178.33.185] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1U8c0f-001Kdd-KV>; Thu, 21 Feb 2013 20:40:49 +0100 Message-ID: <5126783C.7030008@zedat.fu-berlin.de> Date: Thu, 21 Feb 2013 20:40:44 +0100 From: "O. Hartmann" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130220 Thunderbird/17.0.3 MIME-Version: 1.0 To: Shawn Webb Subject: Re: r247095 Boot Failure References: In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="----enig2QJKANCFFIEFOQVWAXHCW" X-Originating-IP: 85.178.33.185 Cc: FreeBSD-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 21 Feb 2013 19:45:34 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2QJKANCFFIEFOQVWAXHCW Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Am 02/21/13 16:28, schrieb Shawn Webb: > I'm on r247095. My box is failing to boot on a Dell Precision T7500. I'= m > running ZFS as root with a mirrored root pool. >=20 > Here's a pic of the box failing: > https://lh5.googleusercontent.com/-Lq_jlX8of0o/USY4cqZ5BOI/AAAAAAAAGoI/= Nd1LGPbFjHc/s1112/IMG_20130221_100723.jpg >=20 > There isn't much useful information in the pic. No crash dump is genera= ted. > Where do I go from here? >=20 > I can boot into kernel.old and that works as a workaround for now. >=20 > Thanks, >=20 > Shawn Well, I guess you faced the same problem I reported in two days ago. I have this crash on ALL(!) of my FreeBSD 10.0-CURRENT boxes, which use CLANG as the default compiler as well as setting CXXFLAGS+=3D -stdlib=3Dlibc++ CXXFLAGS+=3D -std=3Dc++1 The working kernel on those boxes is FreeBSD 10.0-CURRENT #0 r246949: Mon Feb 18 22:20:30 CET 2013/amd64 On our Intel Core2Duo (Q6600/E8400) boxes the crash looks like yours in the picture, but sometimes there is "trap 18" or "trap 16" instead of the cryptic signs. On a more modern Ivy-Bridge i3-3220, I get blinking, funky funny clock characters on the screen - this box uitilizes as a server the Intel iGPU of the CPU. Since I use customized kernels, I tried to start with the official GENERIC kernel and disabling every setting in /boot/loader.conf, but the result is even with such a setting the same - all boxes crashes with the kernel sources > r246949. I also tried to enable the debugging features in the customized kernel (as they are enabled in the GENERIC), but there is no chance to get any backtrace, the kernel simply gets stuck or - on the mentioned box with the ivy Bridge, simply blinking funnily as a home computer in the late 80= s. Sorry for being unable to report more substantial facts on that. Oliver ------enig2QJKANCFFIEFOQVWAXHCW 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.19 (FreeBSD) iQEcBAEBAgAGBQJRJnhBAAoJEOgBcD7A/5N8Rf0H/28vmdH+yVShQQ31j/y8PHyq Pv4clc9LmXhtp0pzLPNQdk/+TmwfAomEMFxieyTXXecUatgAGziJFWw6nc5P2FN2 t8rcK/Em/R4GzYUa1UU26DfPJ9eO8RUSsEGNPzGdVyPtB/3Nx9pAx5+WzG3+WLtT FxP+lbuIWFYC9fe73P8nXqbidQi4C5JAv7rorQ/qxj6va/N+p1UwsAsi5ZnzwVqT WBVpxmx16nBaGyKASHdrr9AoeM7yn6FhpyaAUszcjIgRZ4KtB2+ry4xzjqkRVM09 gq89db7frhGpI2CjvBWCAmW4pci9awDRbBwRP+hWV5HJTWlPyaWfGtFfJrcYYaU= =5zuz -----END PGP SIGNATURE----- ------enig2QJKANCFFIEFOQVWAXHCW-- From owner-freebsd-current@FreeBSD.ORG Thu Feb 21 19:51:18 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id C799B5DF for ; Thu, 21 Feb 2013 19:51:18 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 2E926706 for ; Thu, 21 Feb 2013 19:51:18 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.6/8.14.6) with ESMTP id r1LJpDkr068088; Thu, 21 Feb 2013 21:51:13 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.7.4 kib.kiev.ua r1LJpDkr068088 Received: (from kostik@localhost) by tom.home (8.14.6/8.14.6/Submit) id r1LJpDHd068087; Thu, 21 Feb 2013 21:51:13 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 21 Feb 2013 21:51:13 +0200 From: Konstantin Belousov To: "O. Hartmann" Subject: Re: r247095 Boot Failure Message-ID: <20130221195113.GB2598@kib.kiev.ua> References: <5126783C.7030008@zedat.fu-berlin.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="XeYnZTu7hwE7l7sm" Content-Disposition: inline In-Reply-To: <5126783C.7030008@zedat.fu-berlin.de> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: FreeBSD-current , Shawn Webb X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 21 Feb 2013 19:51:18 -0000 --XeYnZTu7hwE7l7sm Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Feb 21, 2013 at 08:40:44PM +0100, O. Hartmann wrote: > Am 02/21/13 16:28, schrieb Shawn Webb: > > I'm on r247095. My box is failing to boot on a Dell Precision T7500. I'm > > running ZFS as root with a mirrored root pool. > >=20 > > Here's a pic of the box failing: > > https://lh5.googleusercontent.com/-Lq_jlX8of0o/USY4cqZ5BOI/AAAAAAAAGoI/= Nd1LGPbFjHc/s1112/IMG_20130221_100723.jpg > >=20 > > There isn't much useful information in the pic. No crash dump is genera= ted. > > Where do I go from here? > >=20 > > I can boot into kernel.old and that works as a workaround for now. > >=20 > > Thanks, > >=20 > > Shawn >=20 >=20 > Well, I guess you faced the same problem I reported in two days ago. I > have this crash on ALL(!) of my FreeBSD 10.0-CURRENT boxes, which use > CLANG as the default compiler as well as setting CXXFLAGS+=3D > -stdlib=3Dlibc++ > CXXFLAGS+=3D -std=3Dc++1 >=20 > The working kernel on those boxes is >=20 > FreeBSD 10.0-CURRENT #0 r246949: Mon Feb 18 22:20:30 CET 2013/amd64 >=20 > On our Intel Core2Duo (Q6600/E8400) boxes the crash looks like yours in > the picture, but sometimes there is "trap 18" or "trap 16" instead of > the cryptic signs. >=20 > On a more modern Ivy-Bridge i3-3220, I get blinking, funky funny clock > characters on the screen - this box uitilizes as a server the Intel iGPU > of the CPU. >=20 > Since I use customized kernels, I tried to start with the official > GENERIC kernel and disabling every setting in /boot/loader.conf, but the > result is even with such a setting the same - all boxes crashes with the > kernel sources > r246949. >=20 > I also tried to enable the debugging features in the customized kernel > (as they are enabled in the GENERIC), but there is no chance to get any > backtrace, the kernel simply gets stuck or - on the mentioned box with > the ivy Bridge, simply blinking funnily as a home computer in the late 80= s. >=20 > Sorry for being unable to report more substantial facts on that. The supposed fix was committed as r247117. --XeYnZTu7hwE7l7sm Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJRJnqwAAoJEJDCuSvBvK1BjSwP/ip4i25LGOHX8uWlp4kSkn85 ifPJhwraYhJts+Ct899P0bvsCrvdYxjQKgI+dncJxAWoTVtvwa2klLbSgeswRxEw ga9ICmamvLy6Sk33VyytZE7laShu0OCvKEbEKuuJvRzm/O9+zKFbfkp95R/PxFY4 IwJ96JMVvTYReOsAfk+RV/sjrW/uMUX3Q0zt5p76NUZANoQSgNj1bKqrQoIKGQL5 Nee3UGX7vTBVG6IDDIQGILIvvz5l/br5OTbLfl6nlyEYFoJY/dY6UpddFBvZOugm uns7JMmYdpt2dIdMvZFKERVBrkLOhDM/LGd4b5t43VDKxBJgjb+gaEQH+qaqrMt4 LvjeNGd9UErAKNSQsoiq86/n7OmvopoKlisGbY15TIK8IvCOzJAld4EYmLJ6K9uQ lSCHp5W67U4MAr7ZaDhJkFYE4Z/xJ4oIRfvWRiYQ5ga+BfcnzZgiu5ws4l+CgriF g9FVcW/HNHmDg0DAjCVbN61fEEsLiZCi3VNZVVmY7ruOFxSJK31nJLQxXkPsx+3f xKaDhL3edh9bQ9E78LnX4rb8NkTlulbwb+Qf2OyU9sEgx+SW8NrTWllu9adjGmyf PlpSwmdMzfwoEPd/y1fmtYiP6jSsarLgGPWmLa0PdwZJG1v5a+zNxsQUU/r9uBl9 X1vjUxn8eGZ99wy/XYn3 =+v2w -----END PGP SIGNATURE----- --XeYnZTu7hwE7l7sm-- From owner-freebsd-current@FreeBSD.ORG Thu Feb 21 20:14:09 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id B0649F26 for ; Thu, 21 Feb 2013 20:14:09 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id 73767855 for ; Thu, 21 Feb 2013 20:14:09 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) with esmtp (envelope-from ) id <1U8cWu-000vSC-Lv>; Thu, 21 Feb 2013 21:14:08 +0100 Received: from e178018119.adsl.alicedsl.de ([85.178.18.119] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1U8cWu-001MSU-I7>; Thu, 21 Feb 2013 21:14:08 +0100 Message-ID: <5126800F.4090406@zedat.fu-berlin.de> Date: Thu, 21 Feb 2013 21:14:07 +0100 From: "O. Hartmann" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130220 Thunderbird/17.0.3 MIME-Version: 1.0 To: Konstantin Belousov Subject: Re: r247095 Boot Failure References: <5126783C.7030008@zedat.fu-berlin.de> <20130221195113.GB2598@kib.kiev.ua> In-Reply-To: <20130221195113.GB2598@kib.kiev.ua> X-Enigmail-Version: 1.5.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="----enig2IFSQKTTDLEIHHPRUSTXE" X-Originating-IP: 85.178.18.119 Cc: FreeBSD-current , Shawn Webb X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 21 Feb 2013 20:14:09 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2IFSQKTTDLEIHHPRUSTXE Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Am 02/21/13 20:51, schrieb Konstantin Belousov: > On Thu, Feb 21, 2013 at 08:40:44PM +0100, O. Hartmann wrote: >> Am 02/21/13 16:28, schrieb Shawn Webb: >>> I'm on r247095. My box is failing to boot on a Dell Precision T7500. = I'm >>> running ZFS as root with a mirrored root pool. >>> >>> Here's a pic of the box failing: >>> https://lh5.googleusercontent.com/-Lq_jlX8of0o/USY4cqZ5BOI/AAAAAAAAGo= I/Nd1LGPbFjHc/s1112/IMG_20130221_100723.jpg >>> >>> There isn't much useful information in the pic. No crash dump is gene= rated. >>> Where do I go from here? >>> >>> I can boot into kernel.old and that works as a workaround for now. >>> >>> Thanks, >>> >>> Shawn >> >> >> Well, I guess you faced the same problem I reported in two days ago. I= >> have this crash on ALL(!) of my FreeBSD 10.0-CURRENT boxes, which use >> CLANG as the default compiler as well as setting CXXFLAGS+=3D >> -stdlib=3Dlibc++ >> CXXFLAGS+=3D -std=3Dc++1 >> >> The working kernel on those boxes is >> >> FreeBSD 10.0-CURRENT #0 r246949: Mon Feb 18 22:20:30 CET 2013/amd64 >> >> On our Intel Core2Duo (Q6600/E8400) boxes the crash looks like yours i= n >> the picture, but sometimes there is "trap 18" or "trap 16" instead of >> the cryptic signs. >> >> On a more modern Ivy-Bridge i3-3220, I get blinking, funky funny clock= >> characters on the screen - this box uitilizes as a server the Intel iG= PU >> of the CPU. >> >> Since I use customized kernels, I tried to start with the official >> GENERIC kernel and disabling every setting in /boot/loader.conf, but t= he >> result is even with such a setting the same - all boxes crashes with t= he >> kernel sources > r246949. >> >> I also tried to enable the debugging features in the customized kernel= >> (as they are enabled in the GENERIC), but there is no chance to get an= y >> backtrace, the kernel simply gets stuck or - on the mentioned box with= >> the ivy Bridge, simply blinking funnily as a home computer in the late= 80s. >> >> Sorry for being unable to report more substantial facts on that. >=20 > The supposed fix was committed as r247117. >=20 Simply compiling a new kernel doesn't resolve the problem. -------------------------------------------------------------- >>> Updating /usr/src using Subversion -------------------------------------------------------------- /usr/local/bin/svn update -r HEAD Updating '.': At revision 247121. This kernel crashes the same way. As it is supposed to be a gcc-change, I guess I have to recompile the whole world? Doing so by now. If not necessary to build world - then the bug is still persent - at least in my case. Regards, Oliver ------enig2IFSQKTTDLEIHHPRUSTXE 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.19 (FreeBSD) iQEcBAEBAgAGBQJRJoAQAAoJEOgBcD7A/5N8G5IIAIdg/lei8gLcXMXVMhUHlp6s mtKDsSszIBEHKzM2zH3ZpRQxH6Ar4x9Sn1cvkDSic2urvExk4XKqBGIZz4x2h0mW 2Djk99Y/sPfjb2xKoKxuQDvVJoZ3aXXLG97UJSRiuxE7NKfhrG9D3hOdorvUKqyo T9cELBQUW1FfF7qO4Sw0DZWH7lTf4/O4Baiangjl0qPz+XtLu+WBkDE4BJvcYXlQ /3CO8XdH+PMHab0b1a0BHvDS//mfnyPW+1wsMwmhBuCmz0wUWRKUm8tcEk9XUhYk aoQjisctHF0xa7ks2GyLCquKRiuqN365D8h7kCH4Fx4ogI6/1B2hayC5s0mDdd8= =D4ml -----END PGP SIGNATURE----- ------enig2IFSQKTTDLEIHHPRUSTXE-- From owner-freebsd-current@FreeBSD.ORG Thu Feb 21 20:21:10 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 9F3431FB for ; Thu, 21 Feb 2013 20:21:10 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) by mx1.freebsd.org (Postfix) with ESMTP id 7297C8AF for ; Thu, 21 Feb 2013 20:21:10 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.6/8.14.6) with ESMTP id r1LKL9u5023403; Thu, 21 Feb 2013 12:21:09 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.6/8.14.6/Submit) id r1LKL950023402; Thu, 21 Feb 2013 12:21:09 -0800 (PST) (envelope-from sgk) Date: Thu, 21 Feb 2013 12:21:09 -0800 From: Steve Kargl To: "O. Hartmann" Subject: Re: r247095 Boot Failure Message-ID: <20130221202109.GA20010@troutmask.apl.washington.edu> References: <5126783C.7030008@zedat.fu-berlin.de> <20130221195113.GB2598@kib.kiev.ua> <5126800F.4090406@zedat.fu-berlin.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5126800F.4090406@zedat.fu-berlin.de> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Konstantin Belousov , FreeBSD-current , Shawn Webb X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 21 Feb 2013 20:21:10 -0000 On Thu, Feb 21, 2013 at 09:14:07PM +0100, O. Hartmann wrote: > > > > The supposed fix was committed as r247117. > > > > Simply compiling a new kernel doesn't resolve the problem. > See the commit message why your kernel appears to not work. http://svnweb.freebsd.org/base?view=revision&revision=247117 Did you update gas before building the new kernel? -- Steve From owner-freebsd-current@FreeBSD.ORG Thu Feb 21 21:02:01 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 07698535 for ; Thu, 21 Feb 2013 21:02:01 +0000 (UTC) (envelope-from lattera@gmail.com) Received: from mail-qe0-f49.google.com (mail-qe0-f49.google.com [209.85.128.49]) by mx1.freebsd.org (Postfix) with ESMTP id C13E5AAE for ; Thu, 21 Feb 2013 21:02:00 +0000 (UTC) Received: by mail-qe0-f49.google.com with SMTP id q19so990497qeb.22 for ; Thu, 21 Feb 2013 13:01:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=8RsZegTPOek/KHuGnJgkC+x4+5pp5j752jVZJC8CTMo=; b=dtwL2m6LqpGO6gjELufzCvjwhmU8yeMeNgWYaKzhWUOUXAx76W5DPcNuC3PccFBXXx RU8DqSolrQ86t7rLQ0FqfH3QEnbxd059fhmR7VRBpf915s0DWwnmGtLpCMok3/Df5gH5 uwW0y39W88K+OyzEBM1fOaQ+l2YnDZmokRF4/VCgQ7tG9YyN2PJhtFdAY2oOp3+1fHMn 41dkID3nnXJNGgbfBE0b/V0bhV5mejhqLqnYJ7zlGFt/C4bLqKn/LIVyRzXQxNwtPut9 taOEYjFwnbih2qOhO4xgomdim4mlp3EwMogjEybTzKrCOIbXRXd3BcxscTJGZsmiPYdn ScKw== MIME-Version: 1.0 X-Received: by 10.49.74.73 with SMTP id r9mr12766284qev.44.1361480514330; Thu, 21 Feb 2013 13:01:54 -0800 (PST) Received: by 10.49.35.161 with HTTP; Thu, 21 Feb 2013 13:01:54 -0800 (PST) In-Reply-To: <20130221202109.GA20010@troutmask.apl.washington.edu> References: <5126783C.7030008@zedat.fu-berlin.de> <20130221195113.GB2598@kib.kiev.ua> <5126800F.4090406@zedat.fu-berlin.de> <20130221202109.GA20010@troutmask.apl.washington.edu> Date: Thu, 21 Feb 2013 16:01:54 -0500 Message-ID: Subject: Re: r247095 Boot Failure From: Shawn Webb To: Steve Kargl Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Konstantin Belousov , FreeBSD-current , "O. Hartmann" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 21 Feb 2013 21:02:01 -0000 I'm building now. I should know whether or not it works. I'm assuming the updated gas is in base? My userland is r247095, but my kernel is r246990. On Thu, Feb 21, 2013 at 3:21 PM, Steve Kargl < sgk@troutmask.apl.washington.edu> wrote: > On Thu, Feb 21, 2013 at 09:14:07PM +0100, O. Hartmann wrote: > > > > > > The supposed fix was committed as r247117. > > > > > > > Simply compiling a new kernel doesn't resolve the problem. > > > > See the commit message why your kernel appears to not work. > > http://svnweb.freebsd.org/base?view=revision&revision=247117 > > Did you update gas before building the new kernel? > > -- > Steve > From owner-freebsd-current@FreeBSD.ORG Thu Feb 21 21:54:09 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id C4034F9 for ; Thu, 21 Feb 2013 21:54:09 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id 81DDEE9D for ; Thu, 21 Feb 2013 21:54:09 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) with esmtp (envelope-from ) id <1U8e5f-001IJV-Dx>; Thu, 21 Feb 2013 22:54:07 +0100 Received: from e178018119.adsl.alicedsl.de ([85.178.18.119] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1U8e5f-001Rdg-AV>; Thu, 21 Feb 2013 22:54:07 +0100 Message-ID: <5126977A.1090408@zedat.fu-berlin.de> Date: Thu, 21 Feb 2013 22:54:02 +0100 From: "O. Hartmann" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130220 Thunderbird/17.0.3 MIME-Version: 1.0 To: Shawn Webb Subject: Re: r247095 Boot Failure References: <5126783C.7030008@zedat.fu-berlin.de> <20130221195113.GB2598@kib.kiev.ua> <5126800F.4090406@zedat.fu-berlin.de> <20130221202109.GA20010@troutmask.apl.washington.edu> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="----enig2MTRCOLBVXWAWFSHASWTK" X-Originating-IP: 85.178.18.119 Cc: Konstantin Belousov , FreeBSD-current , Steve Kargl X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 21 Feb 2013 21:54:09 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2MTRCOLBVXWAWFSHASWTK Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Am 02/21/13 22:01, schrieb Shawn Webb: > I'm building now. I should know whether or not it works. I'm assuming t= he > updated gas is in base? My userland is r247095, but my kernel is r24699= 0. >=20 >=20 > On Thu, Feb 21, 2013 at 3:21 PM, Steve Kargl < > sgk@troutmask.apl.washington.edu> wrote: >=20 >> On Thu, Feb 21, 2013 at 09:14:07PM +0100, O. Hartmann wrote: >>>> >>>> The supposed fix was committed as r247117. >>>> >>> >>> Simply compiling a new kernel doesn't resolve the problem. >>> >> >> See the commit message why your kernel appears to not work. >> >> http://svnweb.freebsd.org/base?view=3Drevision&revision=3D247117 >> >> Did you update gas before building the new kernel? >> >> -- >> Steve Update now in progress, didn't update gas in the first place. Oliver ------enig2MTRCOLBVXWAWFSHASWTK 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.19 (FreeBSD) iQEcBAEBAgAGBQJRJpd/AAoJEOgBcD7A/5N8DFwH/1jRL5RRk6IDGLULqGitJNPs 2L1Po/IfBP21ZxR5T9MTL0nvczmqQJdwocsJe8yA+N+70Oy4DP7VLmIdGbOaI0D6 Sg+1OgaAAvfKjIsyPoUloBRWpn+zFjoJMaHduiF8oiqjGstQTf1oeFqVUN+tw9Yy ZCH5HoHrWP/v+LtS9HrcjbAZ8h4G2PYnGlND7S8D3dTKbbl0WMUkVM3dxGPDhYar JGkINeaeasnpYPHd7XtO8ujy1u21qjxiSUGZqHCXZtYdzqfbX+GGDmh0lhKOXco7 nSY8FLSgbBh3UFBKLo2GcOR6zx3H4j2EqMCziE3aRHT1DpWJESjcVY09fOWk8Os= =8CZF -----END PGP SIGNATURE----- ------enig2MTRCOLBVXWAWFSHASWTK-- From owner-freebsd-current@FreeBSD.ORG Thu Feb 21 21:55:58 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 8527E4BA for ; Thu, 21 Feb 2013 21:55:58 +0000 (UTC) (envelope-from lattera@gmail.com) Received: from mail-qc0-f170.google.com (mail-qc0-f170.google.com [209.85.216.170]) by mx1.freebsd.org (Postfix) with ESMTP id 1782CECC for ; Thu, 21 Feb 2013 21:55:57 +0000 (UTC) Received: by mail-qc0-f170.google.com with SMTP id d42so4627qca.15 for ; Thu, 21 Feb 2013 13:55:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=gWCXQjkyJ2s5cyzONCCDQqIgTu6kmOZk8O83KWRzLRI=; b=Q0S1M86KuzSyUd8bSVSnIcnQe7gUrHl8DSzYJoxqxir50lXyJZmLIpd75zKoaEG8Vw 764C6AnjouJgr4PpfHYEPGDU3X3reQUIY7+069XxoZgTgbmoP5KEFxHSieI911Xd+JSX +d5mOkvMH1xx0CnPli7rzEyAGJCoDeKLY79jjvIXiBb4QHLrQZjYA9cuIBE7DMALEnb4 r1UpL4z999cfO6Kh06ZeHKhIOcPt3XYmHYEn4yz08E5xNU3YvcTlBew1ZKzUc0+tneU2 evnTvDmHovzdxzWITpRRE5dG+q8AGgTidtPYwPku2shHTm2YFn2sdfjMO0lIknkG93tZ bqag== MIME-Version: 1.0 X-Received: by 10.49.74.198 with SMTP id w6mr12837019qev.57.1361483757562; Thu, 21 Feb 2013 13:55:57 -0800 (PST) Received: by 10.49.35.161 with HTTP; Thu, 21 Feb 2013 13:55:57 -0800 (PST) In-Reply-To: <5126977A.1090408@zedat.fu-berlin.de> References: <5126783C.7030008@zedat.fu-berlin.de> <20130221195113.GB2598@kib.kiev.ua> <5126800F.4090406@zedat.fu-berlin.de> <20130221202109.GA20010@troutmask.apl.washington.edu> <5126977A.1090408@zedat.fu-berlin.de> Date: Thu, 21 Feb 2013 16:55:57 -0500 Message-ID: Subject: Re: r247095 Boot Failure From: Shawn Webb To: "O. Hartmann" Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Konstantin Belousov , FreeBSD-current , Steve Kargl X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 21 Feb 2013 21:55:58 -0000 The results are in: success! Thanks everyone. This is why I love FreeBSD: the community is amazing! On Thu, Feb 21, 2013 at 4:54 PM, O. Hartmann wrote: > Am 02/21/13 22:01, schrieb Shawn Webb: > > I'm building now. I should know whether or not it works. I'm assuming the > > updated gas is in base? My userland is r247095, but my kernel is r246990. > > > > > > On Thu, Feb 21, 2013 at 3:21 PM, Steve Kargl < > > sgk@troutmask.apl.washington.edu> wrote: > > > >> On Thu, Feb 21, 2013 at 09:14:07PM +0100, O. Hartmann wrote: > >>>> > >>>> The supposed fix was committed as r247117. > >>>> > >>> > >>> Simply compiling a new kernel doesn't resolve the problem. > >>> > >> > >> See the commit message why your kernel appears to not work. > >> > >> http://svnweb.freebsd.org/base?view=revision&revision=247117 > >> > >> Did you update gas before building the new kernel? > >> > >> -- > >> Steve > > > > Update now in progress, didn't update gas in the first place. > > Oliver > > From owner-freebsd-current@FreeBSD.ORG Thu Feb 21 22:28:34 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id BEE3F78F; Thu, 21 Feb 2013 22:28:34 +0000 (UTC) (envelope-from onwahe@gmail.com) Received: from mail-qe0-f50.google.com (mail-qe0-f50.google.com [209.85.128.50]) by mx1.freebsd.org (Postfix) with ESMTP id 72A2B157; Thu, 21 Feb 2013 22:28:34 +0000 (UTC) Received: by mail-qe0-f50.google.com with SMTP id w7so20655qeb.23 for ; Thu, 21 Feb 2013 14:28:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=Z2YLI6yHbUQcs6EYr0A1tgdbSbBJMUOqR1Pjl7Z0xdI=; b=eVVBqslaXXBiqo78kf0nqYuI/9JJKjd30pyM41ir9Q44DbUK1YRKJkoVBzcwS9JjMS N7Yuivo/tBdImGImZbNKbr5WToAD2qCZm18r7la/ckaA57dCqR9WdnhyJoseVBKrp1nF k85CGk3bNfpFzLEdQCa4AlHd9TIxYIa8jIPqTHHLToco3CWY4bEZmxsaPQ3qQ896PvpB H3HlTaGLSjEUIvLcM/52n4HxAOBRSt3KExUmv72LtX94SxV6/ApGqtymBJGLnfR8H54q 2qvHlWyHtDCAQXVD8Ag4ykSX8UuxJLGovPg4/RlvnyqLXRoRFpGzLTIyPFwnsbm0SDCd nI3w== MIME-Version: 1.0 X-Received: by 10.49.107.4 with SMTP id gy4mr13180947qeb.63.1361485707986; Thu, 21 Feb 2013 14:28:27 -0800 (PST) Received: by 10.49.121.198 with HTTP; Thu, 21 Feb 2013 14:28:27 -0800 (PST) In-Reply-To: <201302211043.49906.jhb@freebsd.org> References: <201302201022.29294.jhb@freebsd.org> <201302211043.49906.jhb@freebsd.org> Date: Thu, 21 Feb 2013 23:28:27 +0100 Message-ID: Subject: Re: [patch] i386 pmap sysmaps_pcpu[] atomic access From: Svatopluk Kraus To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1 Cc: Konstantin Belousov , freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 21 Feb 2013 22:28:34 -0000 On Thu, Feb 21, 2013 at 4:43 PM, John Baldwin wrote: >> > curthread is a bit magic. :) If you perform a context switch during an >> > interrupt (which will change 'curthread') you also change your register state. >> > When you resume, the register state is also restored. This means that while >> > something like 'PCPU_GET(cpuid)' might be stale after you read it, 'curthread' >> > never is. However, it is true that actually reading curthread has to be >> > atomic. If your read of curthread looks like: >> > >> > mov , r0 >> > add , r0 >> > ld r0, r1 >> > >> > Then that will indeed break. Alpha used a fixed register for 'pcpu_reg' >> > (as does ia64 IIRC). OTOH, you might also be able to depend on the fact that >> > pc_curthread is the first thing in 'struct pcpu' (and always will be, you could >> > add a CTASSERT to future-proof). In that case, you can remove the 'add' >> > instruction and instead just do: >> > >> > ld , r1 >> > >> > which is fine. >> >> Just for the record. There are three extra (coprocessor) registers per >> a core in arm11mpcore (armv6k). Unfortunately only one is Privileged. >> The other ones are respectively User Read only and User Read Write. >> For now, we are using the Privileged one to store pcpu pointer >> (curthread is correctly set during each context switch). Thus, using a >> coprocessor register means that reading of curthread is not a single >> instruction implementation now. After we figured out the curthread >> issue in SMP case, using a fixed (processor) register for pcpu is an >> option. Meanwhile, we disable interrupts before reading of curthread >> and enable them after. The same is done for other PCPU stuff. For now >> we have not stable system enough for profiling, however, when it will >> be, it would be interesting to learn how various implementations of >> curthread reading impact system performance. > > curthread is read _a lot_, so I would expect this to hurt. What we did on > Alpha was to use a fixed register for pcpu access, but we used the equivalent > of a coprocessor register to also store the value so we could set that fixed > register on entry to the kernel (userland was free to use the register for > its own purposes). Interesting solution. Thanks. Svata From owner-freebsd-current@FreeBSD.ORG Thu Feb 21 22:28:58 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 179EC89C for ; Thu, 21 Feb 2013 22:28:58 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id CBA4C16B for ; Thu, 21 Feb 2013 22:28:57 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) with esmtp (envelope-from ) id <1U8edM-001Mx8-23>; Thu, 21 Feb 2013 23:28:56 +0100 Received: from e178015212.adsl.alicedsl.de ([85.178.15.212] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1U8edL-001TTM-Un>; Thu, 21 Feb 2013 23:28:56 +0100 Message-ID: <51269FA7.8060701@zedat.fu-berlin.de> Date: Thu, 21 Feb 2013 23:28:55 +0100 From: "O. Hartmann" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130220 Thunderbird/17.0.3 MIME-Version: 1.0 To: Shawn Webb Subject: Re: r247095 Boot Failure References: <5126783C.7030008@zedat.fu-berlin.de> <20130221195113.GB2598@kib.kiev.ua> <5126800F.4090406@zedat.fu-berlin.de> <20130221202109.GA20010@troutmask.apl.washington.edu> <5126977A.1090408@zedat.fu-berlin.de> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="----enig2ABECWLOIMMDXUNWMMSNC" X-Originating-IP: 85.178.15.212 Cc: Konstantin Belousov , FreeBSD-current , Steve Kargl X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 21 Feb 2013 22:28:58 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2ABECWLOIMMDXUNWMMSNC Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Am 02/21/13 22:55, schrieb Shawn Webb: > The results are in: success! Thanks everyone. This is why I love FreeBS= D: > the community is amazing! >=20 >=20 > On Thu, Feb 21, 2013 at 4:54 PM, O. Hartmann wrote: >=20 >> Am 02/21/13 22:01, schrieb Shawn Webb: >>> I'm building now. I should know whether or not it works. I'm assuming= the >>> updated gas is in base? My userland is r247095, but my kernel is r246= 990. >>> >>> >>> On Thu, Feb 21, 2013 at 3:21 PM, Steve Kargl < >>> sgk@troutmask.apl.washington.edu> wrote: >>> >>>> On Thu, Feb 21, 2013 at 09:14:07PM +0100, O. Hartmann wrote: >>>>>> >>>>>> The supposed fix was committed as r247117. >>>>>> >>>>> >>>>> Simply compiling a new kernel doesn't resolve the problem. >>>>> >>>> >>>> See the commit message why your kernel appears to not work. >>>> >>>> http://svnweb.freebsd.org/base?view=3Drevision&revision=3D247117 >>>> >>>> Did you update gas before building the new kernel? >>>> >>>> -- >>>> Steve >> >> >> >> Update now in progress, didn't update gas in the first place. >> >> Oliver >> >> >=20 Works for me, too. Thanks a lot. oh ------enig2ABECWLOIMMDXUNWMMSNC 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.19 (FreeBSD) iQEcBAEBAgAGBQJRJp+nAAoJEOgBcD7A/5N8Lf8H/jLAlqF5qQ2YskgE8b65MR8N dATjcggbc4aKX94uHGqw57ITvth+VBqPOIbvNqVhhDp/cMS/SRroLJ7ny0j3wn+J ZmQCDZ4kkLkXH8rGpfmnh8QaeI0muR/6gZbeK9WeZJz59VKW0YnWIWH/o+ce0S4Q Bj9vbzKB6OgjE5MzVVTBMaGMGGHFmn/bsa4uVSdmL8syKZtVpGTfPUTbS7Y8QE5R zmftPN9pugN+cx/np74/iJc40mQlaGx6yzzQJ55anfMBz8iaVTLtdES+kksoi7u6 DM7UqRkq8rmqoJzoBhaqfhg79wmw91B31ZITbf96ol0FjX1Ktwl9RefZ4RsBJto= =mwJB -----END PGP SIGNATURE----- ------enig2ABECWLOIMMDXUNWMMSNC-- From owner-freebsd-current@FreeBSD.ORG Fri Feb 22 00:38:36 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id C513A1BD for ; Fri, 22 Feb 2013 00:38:36 +0000 (UTC) (envelope-from peter@rulingia.com) Received: from vps.rulingia.com (host-122-100-2-194.octopus.com.au [122.100.2.194]) by mx1.freebsd.org (Postfix) with ESMTP id 1776A947 for ; Fri, 22 Feb 2013 00:38:35 +0000 (UTC) Received: from server.rulingia.com (c220-239-237-213.belrs5.nsw.optusnet.com.au [220.239.237.213]) by vps.rulingia.com (8.14.5/8.14.5) with ESMTP id r1M0cWoZ082995 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 22 Feb 2013 11:38:32 +1100 (EST) (envelope-from peter@rulingia.com) X-Bogosity: Ham, spamicity=0.000000 Received: from server.rulingia.com (localhost.rulingia.com [127.0.0.1]) by server.rulingia.com (8.14.5/8.14.5) with ESMTP id r1M0cR3x018765 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 22 Feb 2013 11:38:27 +1100 (EST) (envelope-from peter@server.rulingia.com) Received: (from peter@localhost) by server.rulingia.com (8.14.5/8.14.5/Submit) id r1M0cRYe018764 for freebsd-current@freebsd.org; Fri, 22 Feb 2013 11:38:27 +1100 (EST) (envelope-from peter) Date: Fri, 22 Feb 2013 11:38:27 +1100 From: Peter Jeremy To: Current FreeBSD Subject: Re: No ZFS when loading modules from loeader prompt Message-ID: <20130222003827.GA15631@server.rulingia.com> References: <5124E646.3060304@zedat.fu-berlin.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="sm4nu43k4a2Rpi4c" Content-Disposition: inline In-Reply-To: X-PGP-Key: http://www.rulingia.com/keys/peter.pgp User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 00:38:36 -0000 --sm4nu43k4a2Rpi4c Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Feb 20, 2013 at 7:05 AM, O. Hartmann = wrote: > At the loader prompt, I need to unload the buggy kernel and load the old > working one via > > load /boot/kernel.old/kernel > > Then I load also the ZFS related modules > > load /boot/kernel.old/opensolaris.ko > load /boot/kernel.old/zfs.ko > > Issuing boot at the end of that stage boots the kernel - the old one > -successfully - but there is no working ZFS and no ZFS volume gets > mounted although the rc.conf is executed correctly. > > What am I doing wrong at that point? Why isn't ZFS run and mount properly? Last time I ran into this problem, the issue was that "unload" also unloaded the zpool.cache file and the ZFS code relied on that to find the kernel. I don't recall what the workaround was. On 2013-Feb-20 08:17:46 -0800, Freddie Cash wrote: >Sounds like a perfect use case for Boot Environments. Create a new BE, >install the new kernel into it, set it as the default, reboot. If it >fails, you manually set the previous BE as the default, and reboot. That >way, your "known-good", working environment is never affected. How do you change your BE in the loader? Or how do you change your BE when you can't boot? --=20 Peter Jeremy --sm4nu43k4a2Rpi4c Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlEmvgMACgkQ/opHv/APuIf+5gCfW4aeRzU9NZAjduzYq07qqgD3 2oAAoIO16Jgv6cAY/rL/kITdCI7sj2qx =Z2yS -----END PGP SIGNATURE----- --sm4nu43k4a2Rpi4c-- From owner-freebsd-current@FreeBSD.ORG Fri Feb 22 00:46:36 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 78B1539A for ; Fri, 22 Feb 2013 00:46:36 +0000 (UTC) (envelope-from sendtomatt@gmail.com) Received: from mail-vb0-f51.google.com (mail-vb0-f51.google.com [209.85.212.51]) by mx1.freebsd.org (Postfix) with ESMTP id 22B019A3 for ; Fri, 22 Feb 2013 00:46:35 +0000 (UTC) Received: by mail-vb0-f51.google.com with SMTP id fq11so89683vbb.10 for ; Thu, 21 Feb 2013 16:46:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=JPOabNaBagY3w27QldPdGhaq0n+2LM7/i/1cqhTFEaM=; b=U9m8ViWbK35ERnk8mG6JonTIsTSr4G3qPSUF302ul0f39PzAABTzhWe6jqY9rIBMpf XpLWsysqQ3CfoDpibtg0+Qgdqh8BNRf58RZckyF6Y93g0ZsMrlVk/Y42o4heDAZIs5aU RVLB1YYOB7OGSZaV8VKrY08Uoo1tV14fUEeA+YhnDxf+HPD8EmV0yb+iiiytsIaumIn6 rAcmzh1v8aAq/2T6zh44e/MjuEGGNZmPvzJ9ZrTmGJGOXTOBZAjKLXGCixa/+3NUY6Zw undRgTb06j9lkhacemo9VrCVlmZm+w+8RbAAXDKWrtnxwyK96XsNzmZYvwBbCHA5xFUn vvgQ== MIME-Version: 1.0 X-Received: by 10.52.36.11 with SMTP id m11mr9718vdj.117.1361493995403; Thu, 21 Feb 2013 16:46:35 -0800 (PST) Received: by 10.58.77.101 with HTTP; Thu, 21 Feb 2013 16:46:35 -0800 (PST) In-Reply-To: <51269FA7.8060701@zedat.fu-berlin.de> References: <5126783C.7030008@zedat.fu-berlin.de> <20130221195113.GB2598@kib.kiev.ua> <5126800F.4090406@zedat.fu-berlin.de> <20130221202109.GA20010@troutmask.apl.washington.edu> <5126977A.1090408@zedat.fu-berlin.de> <51269FA7.8060701@zedat.fu-berlin.de> Date: Fri, 22 Feb 2013 00:46:35 +0000 Message-ID: Subject: Re: r247095 Boot Failure From: matt To: "O. Hartmann" Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Konstantin Belousov , FreeBSD-current , Steve Kargl , Shawn Webb X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 00:46:36 -0000 OK here as well. Tested sandybridge & opteron. Matt On Thu, Feb 21, 2013 at 10:28 PM, O. Hartmann wrote: > > > Works for me, too. > > Thanks a lot. > > oh > > From owner-freebsd-current@FreeBSD.ORG Fri Feb 22 01:13:24 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id C27B5AB8; Fri, 22 Feb 2013 01:13:24 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-pa0-f46.google.com (mail-pa0-f46.google.com [209.85.220.46]) by mx1.freebsd.org (Postfix) with ESMTP id 7AF55A8E; Fri, 22 Feb 2013 01:13:24 +0000 (UTC) Received: by mail-pa0-f46.google.com with SMTP id kp14so147942pab.5 for ; Thu, 21 Feb 2013 17:13:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:date:to:cc:subject:message-id:reply-to:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=7XLsMRYts+59iBthZK1C0a4Bgmummymz14aoW6HaQXU=; b=AYuhPZAIj8FTeegHUv7GxPuusrcLUQriLWyh/h9F6/YZILiITaPUJ+DiXDpv2yUOzU yRzcmFXMBqBMiaEIXun4O3glVNiieSNcc1jb5n89rQ5/hSeQ4GkqqkrTh2/uehyPSDZW 5MWwjrMBtk5YpzuYbOnRs3BOGjLZLIGhu/MN98JAK53trD01Wi9mAJI9AbjPrVxFO3qs iejjb6/ZhvGdUXP0RypEw5e4jjlcA3K18D9sc5iaG5cYWPVDM/1FTD1rUZ6YDpgFx4lW Pr0OseseQtBVHX10Sr6Y+YNPad5nlta3bjk73VUmVPRxrhsJg0G+1pmkEdb8GE+ws486 VnQA== X-Received: by 10.68.7.106 with SMTP id i10mr266663pba.43.1361495598266; Thu, 21 Feb 2013 17:13:18 -0800 (PST) Received: from pyunyh@gmail.com (lpe4.p59-icn.cdngp.net. [114.111.62.249]) by mx.google.com with ESMTPS id o5sm894358pay.5.2013.02.21.17.13.14 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 21 Feb 2013 17:13:17 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Fri, 22 Feb 2013 10:13:08 +0900 From: YongHyeon PYUN Date: Fri, 22 Feb 2013 10:13:08 +0900 To: Alexey Dokuchaev Subject: Re: ale(4) cannot negotiate as GigE Message-ID: <20130222011308.GA3259@michelle.cdnetworks.com> References: <20130219082302.GA86501@FreeBSD.org> <20130220043739.GA1469@michelle.cdnetworks.com> <20130220060853.GA83110@FreeBSD.org> <20130221083335.GA3226@michelle.cdnetworks.com> <20130221124344.GA93056@FreeBSD.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="UlVJffcvxoiEqYs2" Content-Disposition: inline In-Reply-To: <20130221124344.GA93056@FreeBSD.org> User-Agent: Mutt/1.4.2.3i Cc: current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 01:13:24 -0000 --UlVJffcvxoiEqYs2 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Thu, Feb 21, 2013 at 12:43:44PM +0000, Alexey Dokuchaev wrote: > On Thu, Feb 21, 2013 at 05:33:35PM +0900, YongHyeon PYUN wrote: > > On Wed, Feb 20, 2013 at 06:08:53AM +0000, Alexey Dokuchaev wrote: > > > $ dmesg | egrep ale\|atphy > > > ale0: port 0xcc00-0xcc7f mem 0xfe9c0000-0xfe9fffff irq 17 at device 0.0 on pci2 > > > ale0: 960 Tx FIFO, 1024 Rx FIFO > > > ale0: Using 1 MSI messages. > > > ale0: 4GB boundary crossed, switching to 32bit DMA addressing mode. > > > miibus0: on ale0 > > > atphy0: PHY 0 on miibus0 > > > atphy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow > > > > > > $ devinfo -rv | grep atphy > > > atphy0 pnpinfo oui=0xc82e model=0x1 rev=0x9 at phyno=0 > > > > Hmm, it's still not clear whether the controller is Gigabit or not. > > Could you try attached patch and let me the output? > > ale_flags = 0x00000040 Thanks for the info. Indeed, your controller is AR8121 Gigabit etherent(L1E). I guess the PHY initialization is not complete. Would you try attached patch? > > ./danfe --UlVJffcvxoiEqYs2 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="ale.pr.diff2" Index: sys/dev/ale/if_ale.c =================================================================== --- sys/dev/ale/if_ale.c (revision 246937) +++ sys/dev/ale/if_ale.c (working copy) @@ -406,11 +406,11 @@ CSR_WRITE_2(sc, ALE_GPHY_CTRL, GPHY_CTRL_HIB_EN | GPHY_CTRL_HIB_PULSE | GPHY_CTRL_SEL_ANA_RESET | GPHY_CTRL_PHY_PLL_ON); - DELAY(1000); + DELAY(2000); CSR_WRITE_2(sc, ALE_GPHY_CTRL, GPHY_CTRL_EXT_RESET | GPHY_CTRL_HIB_EN | GPHY_CTRL_HIB_PULSE | GPHY_CTRL_SEL_ANA_RESET | GPHY_CTRL_PHY_PLL_ON); - DELAY(1000); + DELAY(2000); #define ATPHY_DBG_ADDR 0x1D #define ATPHY_DBG_DATA 0x1E --UlVJffcvxoiEqYs2-- From owner-freebsd-current@FreeBSD.ORG Fri Feb 22 01:56:07 2013 Return-Path: Delivered-To: current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1033) id 5C23D4DE; Fri, 22 Feb 2013 01:56:07 +0000 (UTC) Date: Fri, 22 Feb 2013 01:56:07 +0000 From: Alexey Dokuchaev To: YongHyeon PYUN Subject: Re: ale(4) cannot negotiate as GigE Message-ID: <20130222015607.GC66767@FreeBSD.org> References: <20130219082302.GA86501@FreeBSD.org> <20130220043739.GA1469@michelle.cdnetworks.com> <20130220060853.GA83110@FreeBSD.org> <20130221083335.GA3226@michelle.cdnetworks.com> <20130221124344.GA93056@FreeBSD.org> <20130222011308.GA3259@michelle.cdnetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20130222011308.GA3259@michelle.cdnetworks.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 01:56:07 -0000 On Fri, Feb 22, 2013 at 10:13:08AM +0900, YongHyeon PYUN wrote: > On Thu, Feb 21, 2013 at 12:43:44PM +0000, Alexey Dokuchaev wrote: > > ale_flags = 0x00000040 > > Thanks for the info. Indeed, your controller is AR8121 Gigabit > etherent(L1E). I guess the PHY initialization is not complete. > Would you try attached patch? Thanks for the patch. Unfortunately, it's still "100baseTX " after driver reload. Even tried delaying for 3000, no difference. :( ./danfe From owner-freebsd-current@FreeBSD.ORG Fri Feb 22 02:19:04 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 5857D9F3 for ; Fri, 22 Feb 2013 02:19:04 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-qc0-f177.google.com (mail-qc0-f177.google.com [209.85.216.177]) by mx1.freebsd.org (Postfix) with ESMTP id EDDAEDB5 for ; Fri, 22 Feb 2013 02:19:03 +0000 (UTC) Received: by mail-qc0-f177.google.com with SMTP id u28so87070qcs.22 for ; Thu, 21 Feb 2013 18:19:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=544ktjQjdsB8RAl6Lq0LoGMenQuGLSE7fbqylYbebFQ=; b=Qp9fhx4+2hbO0WUlCOlEQS6CpK6mq99ZBPebuHUlfSRpg1hBJqrwDbwi7Y7Hwjofpi zwTZQh+4M4dtoImzgXjJnkoMFn26IBGmUdWwleU6gFaKAYcuPDSfI1yAK4ZPDCOLqgJ4 3KGx/FIK9VO433LYrD3EG0E6QxD7dbyaMPls21MAIao1/zL1pxXogk+wF/HA6jNQIxCU l64U1VPdrLKdGuwcztmA9hRPlTimG/TPaHiCppXwCFH2yje/s3xgo8jJGfBKeYUjp9X3 JzLp3yD7/3hjPnTskPvaTlqz82ejmG5MTi1lC1+JVr1KOx14t2KppwFkItpZicaBgU32 jLLg== MIME-Version: 1.0 X-Received: by 10.229.172.162 with SMTP id l34mr23905qcz.81.1361499543219; Thu, 21 Feb 2013 18:19:03 -0800 (PST) Received: by 10.49.106.233 with HTTP; Thu, 21 Feb 2013 18:19:03 -0800 (PST) Received: by 10.49.106.233 with HTTP; Thu, 21 Feb 2013 18:19:03 -0800 (PST) In-Reply-To: <20130222003827.GA15631@server.rulingia.com> References: <5124E646.3060304@zedat.fu-berlin.de> <20130222003827.GA15631@server.rulingia.com> Date: Thu, 21 Feb 2013 18:19:03 -0800 Message-ID: Subject: Re: No ZFS when loading modules from loeader prompt From: Freddie Cash To: Peter Jeremy Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: FreeBSD-Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 02:19:04 -0000 I haven't used BEs yet, as I have no ZFS-on-root systems. I just know that's how they're supposed to work, and that's the desired use case for them. Vermaden from FreeBSD Forums would be a better one to ask, as he uses them a lot and was one of the people behind BE support in FreeBSD. On 2013-02-21 4:38 PM, "Peter Jeremy" wrote: > On Wed, Feb 20, 2013 at 7:05 AM, O. Hartmann > wrote: > > At the loader prompt, I need to unload the buggy kernel and load the old > > working one via > > > > load /boot/kernel.old/kernel > > > > Then I load also the ZFS related modules > > > > load /boot/kernel.old/opensolaris.ko > > load /boot/kernel.old/zfs.ko > > > > Issuing boot at the end of that stage boots the kernel - the old one > > -successfully - but there is no working ZFS and no ZFS volume gets > > mounted although the rc.conf is executed correctly. > > > > What am I doing wrong at that point? Why isn't ZFS run and mount > properly? > > Last time I ran into this problem, the issue was that "unload" also > unloaded the zpool.cache file and the ZFS code relied on that to find > the kernel. I don't recall what the workaround was. > > On 2013-Feb-20 08:17:46 -0800, Freddie Cash wrote: > >Sounds like a perfect use case for Boot Environments. Create a new BE, > >install the new kernel into it, set it as the default, reboot. If it > >fails, you manually set the previous BE as the default, and reboot. That > >way, your "known-good", working environment is never affected. > > How do you change your BE in the loader? Or how do you change your > BE when you can't boot? > > -- > Peter Jeremy > From owner-freebsd-current@FreeBSD.ORG Fri Feb 22 03:50:33 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id D8ABCDF for ; Fri, 22 Feb 2013 03:50:33 +0000 (UTC) (envelope-from cpet@sdf.org) Received: from sdf.lonestar.org (mx.sdf.org [192.94.73.19]) by mx1.freebsd.org (Postfix) with ESMTP id A9617283 for ; Fri, 22 Feb 2013 03:50:33 +0000 (UTC) Received: from [192.168.1.69] (dsl-187-150-112-90-dyn.prod-infinitum.com.mx [187.150.112.90] (may be forged)) (authenticated (0 bits)) by sdf.lonestar.org (8.14.5/8.14.5) with ESMTP id r1M3oC5L010739 for ; Fri, 22 Feb 2013 03:50:13 GMT Message-ID: <5126EAF3.9010604@sdf.org> Date: Thu, 21 Feb 2013 21:50:11 -0600 From: Chris User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: current@freebsd.org Subject: FreeBSD current rev today about 1-2pm Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 03:50:33 -0000 I updated current today and now the system refuses to boot and my 3ware card constantly has it's LED on and it resets. booting the old kernel boots up fine ? From owner-freebsd-current@FreeBSD.ORG Fri Feb 22 03:53:33 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 3864B30D; Fri, 22 Feb 2013 03:53:33 +0000 (UTC) (envelope-from davide.italiano@gmail.com) Received: from mail-ve0-f175.google.com (mail-ve0-f175.google.com [209.85.128.175]) by mx1.freebsd.org (Postfix) with ESMTP id C94C82CA; Fri, 22 Feb 2013 03:53:32 +0000 (UTC) Received: by mail-ve0-f175.google.com with SMTP id cy12so207493veb.34 for ; Thu, 21 Feb 2013 19:53:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=7qbxgqgSpPJZeN5lalnzY5kOtIbV2R/2bhiI3wcB/W0=; b=qgKPn8bFS4XPo8bu2OzbqJZBuY7EwsEypo+pleBjxgFLeJGSK08sAmgqI3T5D2fsyA kDjttgRZGPDMk3eUtTTLEC+nMAQJ4y0cz17Xhk7OuUPU/MXtWl2TIWZXXy4hfzjFgQiA 7GjKQoOGfAMgzFOstKF1r0sy1pCRz5HLuoykox/yQOVj9JKfOPz+GTqCN+Vic8ePko2Y 0IvQIqJCpnmn9Yymd4SkYo2MINfRwuutSMSVC6PTpOwwOP9CoQ2eNemTCKBiDiFfvu66 JtsD62k63fkA+EGZXfx+21pMqfuUGmvrGqaQd57lI+uySkAOwtxTuoZCke5BE7WpvxPT nAqQ== MIME-Version: 1.0 X-Received: by 10.52.88.237 with SMTP id bj13mr554677vdb.75.1361505211938; Thu, 21 Feb 2013 19:53:31 -0800 (PST) Sender: davide.italiano@gmail.com Received: by 10.220.34.203 with HTTP; Thu, 21 Feb 2013 19:53:31 -0800 (PST) In-Reply-To: <20130217024220.GA81224@onelab2.iet.unipi.it> References: <50D03173.9080904@FreeBSD.org> <20121225232126.GA47692@alchemy.franken.de> <50DB4EFE.2020600@FreeBSD.org> <20130106152313.GD26039@alchemy.franken.de> <50EBF921.2000304@FreeBSD.org> <20130113180940.GM26039@alchemy.franken.de> <50F30CAB.3000001@FreeBSD.org> <20130121095457.GL85306@alchemy.franken.de> <511DEA46.5010509@mu.org> <20130217024220.GA81224@onelab2.iet.unipi.it> Date: Fri, 22 Feb 2013 04:53:31 +0100 X-Google-Sender-Auth: pwpsE-ZSxki7VfIPmsnD_C98mmc Message-ID: Subject: Re: [RFC/RFT] calloutng From: Davide Italiano To: Luigi Rizzo Content-Type: text/plain; charset=ISO-8859-1 Cc: Alexander Motin , Alfred Perlstein , Marius Strobl , Poul-Henning Kamp , FreeBSD Current , freebsd-arch@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 03:53:33 -0000 The patch has been splitted in smaller logical chunks in order to improve readability and facilitate review. The whole code can be found here: http://people.freebsd.org/~davide/calloutng_split/ In particular: http://people.freebsd.org/~davide/calloutng_split/sbintime.diff brings the new type 32.32 fixed point used in lieu of 'int ticks' for the new callout mechanism and relative functions (conversion from to {timeval,bintime,timespec}, sbinuptime(), getsbinuptime()) This change is preliminary to http://people.freebsd.org/~davide/calloutng_split/callout_internals.diff which contains all the callout changes internally (introduction of direct dispatching, conversion to sbintime, new precision mechanism) http://people.freebsd.org/~davide/calloutng_split/cpuidle.diff (see r242905) introduce some optimization in the sleep time calculation and choose of the optimal sleep state, when CPU is idle. http://people.freebsd.org/~mav/calloutng-20130221/libprocstatfix.diff is a workaround in libprocstat in order to allow world to build after changes. About this one, I'm not quite sure is the best solution, so if there are other opinions, I'd be more than happy to hear. Other patches available in the directory converts some kernel consumers of callout(9) to the new interface (nanosleep, poll, select, kqueue, syscons, etc...). My plan is to commit the whole patchset March 4th, unless there are valid reasons to not do so. Any cooment is (as always) appreciated. Thanks, Davide From owner-freebsd-current@FreeBSD.ORG Fri Feb 22 03:55:02 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 4C61D4CE for ; Fri, 22 Feb 2013 03:55:02 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) by mx1.freebsd.org (Postfix) with ESMTP id 1A9BA2FC for ; Fri, 22 Feb 2013 03:55:02 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.6/8.14.6) with ESMTP id r1M3suvK093111; Thu, 21 Feb 2013 19:54:56 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.6/8.14.6/Submit) id r1M3suEO093110; Thu, 21 Feb 2013 19:54:56 -0800 (PST) (envelope-from sgk) Date: Thu, 21 Feb 2013 19:54:56 -0800 From: Steve Kargl To: Chris Subject: Re: FreeBSD current rev today about 1-2pm Message-ID: <20130222035456.GA93091@troutmask.apl.washington.edu> References: <5126EAF3.9010604@sdf.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5126EAF3.9010604@sdf.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 03:55:02 -0000 On Thu, Feb 21, 2013 at 09:50:11PM -0600, Chris wrote: > I updated current today and now the system refuses to boot and my 3ware > card constantly has it's LED on and it resets. booting the old kernel > boots up fine ? Which timezone? 1-2pm is a little ambiguous. Do you have sources with revision 247117 or later? -- Steve From owner-freebsd-current@FreeBSD.ORG Fri Feb 22 03:59:12 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 68118615 for ; Fri, 22 Feb 2013 03:59:12 +0000 (UTC) (envelope-from cpet@sdf.org) Received: from sdf.lonestar.org (mx.sdf.org [192.94.73.19]) by mx1.freebsd.org (Postfix) with ESMTP id 2722D32A for ; Fri, 22 Feb 2013 03:59:11 +0000 (UTC) Received: from [192.168.1.69] (dsl-187-150-112-90-dyn.prod-infinitum.com.mx [187.150.112.90] (may be forged)) (authenticated (0 bits)) by sdf.lonestar.org (8.14.5/8.14.5) with ESMTP id r1M3wvYZ009826; Fri, 22 Feb 2013 03:58:57 GMT Message-ID: <5126ECFF.7010604@sdf.org> Date: Thu, 21 Feb 2013 21:58:55 -0600 From: Chris User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Steve Kargl Subject: Re: FreeBSD current rev today about 1-2pm References: <5126EAF3.9010604@sdf.org> <20130222035456.GA93091@troutmask.apl.washington.edu> In-Reply-To: <20130222035456.GA93091@troutmask.apl.washington.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 03:59:12 -0000 On 2/21/2013 9:54 PM, Steve Kargl wrote: > On Thu, Feb 21, 2013 at 09:50:11PM -0600, Chris wrote: >> I updated current today and now the system refuses to boot and my 3ware >> card constantly has it's LED on and it resets. booting the old kernel >> boots up fine ? > Which timezone? 1-2pm is a little ambiguous. > Do you have sources with revision 247117 or later? > Timezone is CST -6 GMT Working kernel is from 02-11-2012 non working kernel is from today around that time. I am not on the FreeBSD box to check actual rev. From owner-freebsd-current@FreeBSD.ORG Fri Feb 22 04:44:02 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id BB58DD41 for ; Fri, 22 Feb 2013 04:44:02 +0000 (UTC) (envelope-from sendtomatt@gmail.com) Received: from mail-pa0-f50.google.com (mail-pa0-f50.google.com [209.85.220.50]) by mx1.freebsd.org (Postfix) with ESMTP id 9818D6BC for ; Fri, 22 Feb 2013 04:44:02 +0000 (UTC) Received: by mail-pa0-f50.google.com with SMTP id fa11so234537pad.23 for ; Thu, 21 Feb 2013 20:44:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type; bh=EDSktijur4jBEc/LWFRsteBojJs1JuN+dnIjrKhM7BU=; b=ks96kChvjhL/uUS7387te/trhaTZqD7xctBpNyAKV8XKpx5Hg5z7ynjziJpBiHyAMu gOjSncDzAiw93MGIB1LUgkq09TnEzehteQd8cUAM33mExOb6eM65tslTnln96mXA8Wg8 RpPJNm+Ai9tKg4r0ItwM9l1tLylb3HzIIVayCMlzKbNBAGJYXQU94OApG2NzkLH0JT6Z oiYL/kKoNZ0KBhMpvI+5i/9GzdTHKrt9vA14RGhumJqwN+9vvnYdqoYBGHgGFpwSxN9K ExtBDTSVEDnWfaIEr2kXt4bKC9QScBSOwNLaC5+X3KlXOuy4HhrIwLu9VThVnZBZJFFW iqcA== X-Received: by 10.68.203.100 with SMTP id kp4mr882153pbc.186.1361508241825; Thu, 21 Feb 2013 20:44:01 -0800 (PST) Received: from flatline.local (70-36-223-239.dsl.dynamic.sonic.net. [70.36.223.239]) by mx.google.com with ESMTPS id zw3sm1106136pbc.23.2013.02.21.20.43.59 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 21 Feb 2013 20:44:01 -0800 (PST) Message-ID: <5126F753.1000004@gmail.com> Date: Thu, 21 Feb 2013 20:42:59 -0800 From: matt User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130202 Thunderbird/17.0.2 MIME-Version: 1.0 To: Chris Subject: Re: FreeBSD current rev today about 1-2pm References: <5126EAF3.9010604@sdf.org> <20130222035456.GA93091@troutmask.apl.washington.edu> <5126ECFF.7010604@sdf.org> In-Reply-To: <5126ECFF.7010604@sdf.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: current@freebsd.org, Steve Kargl X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 04:44:02 -0000 On 02/21/13 19:58, Chris wrote: > On 2/21/2013 9:54 PM, Steve Kargl wrote: >> On Thu, Feb 21, 2013 at 09:50:11PM -0600, Chris wrote: >>> I updated current today and now the system refuses to boot and my 3ware >>> card constantly has it's LED on and it resets. booting the old kernel >>> boots up fine ? >> Which timezone? 1-2pm is a little ambiguous. >> Do you have sources with revision 247117 or later? >> > Timezone is CST -6 GMT > > Working kernel is from 02-11-2012 non working kernel is from today > around that time. I am not on the FreeBSD box to check actual rev. > _______________________________________________ > 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" > Sounds like the problem from yesterday, my mps0 didn't get to come up before the system hung. It looked like a storage system failure. Get newer sources and try again. Get them from svn, not sure what csup is doing anymore. The patch came around 19:13 GMT. http://freshbsd.org/commit/freebsd/r247117 Matt From owner-freebsd-current@FreeBSD.ORG Fri Feb 22 05:24:12 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 0C596FCB for ; Fri, 22 Feb 2013 05:24:12 +0000 (UTC) (envelope-from cpet@sdf.org) Received: from sdf.lonestar.org (mx.sdf.org [192.94.73.19]) by mx1.freebsd.org (Postfix) with ESMTP id CE34B794 for ; Fri, 22 Feb 2013 05:24:11 +0000 (UTC) Received: from [192.168.1.69] (dsl-187-150-112-90-dyn.prod-infinitum.com.mx [187.150.112.90] (may be forged)) (authenticated (0 bits)) by sdf.lonestar.org (8.14.5/8.14.5) with ESMTP id r1M5NuQ5018907 for ; Fri, 22 Feb 2013 05:23:56 GMT Message-ID: <512700F6.1090003@sdf.org> Date: Thu, 21 Feb 2013 23:24:06 -0600 From: Chris User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: FreeBSD current rev today about 1-2pm References: <5126EAF3.9010604@sdf.org> <20130222035456.GA93091@troutmask.apl.washington.edu> <5126ECFF.7010604@sdf.org> <5126F753.1000004@gmail.com> In-Reply-To: <5126F753.1000004@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 05:24:12 -0000 On 2/21/2013 10:42 PM, matt wrote: > On 02/21/13 19:58, Chris wrote: >> On 2/21/2013 9:54 PM, Steve Kargl wrote: >>> On Thu, Feb 21, 2013 at 09:50:11PM -0600, Chris wrote: >>>> I updated current today and now the system refuses to boot and my 3ware >>>> card constantly has it's LED on and it resets. booting the old kernel >>>> boots up fine ? >>> Which timezone? 1-2pm is a little ambiguous. >>> Do you have sources with revision 247117 or later? >>> >> Timezone is CST -6 GMT >> >> Working kernel is from 02-11-2012 non working kernel is from today >> around that time. I am not on the FreeBSD box to check actual rev. >> _______________________________________________ >> 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" >> > Sounds like the problem from yesterday, my mps0 didn't get to come up > before the system hung. It looked like a storage system failure. > > Get newer sources and try again. Get them from svn, not sure what csup > is doing anymore. > > The patch came around 19:13 GMT. > > http://freshbsd.org/commit/freebsd/r247117 > > Matt > > > _______________________________________________ > 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 will try again tomorrow. Thank you for the heads up :) From owner-freebsd-current@FreeBSD.ORG Fri Feb 22 06:46:10 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 380AAC2B for ; Fri, 22 Feb 2013 06:46:10 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:131:60a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id E07E09D1 for ; Fri, 22 Feb 2013 06:46:09 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:509e:5349:4e7a:bf0a]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPA id 5D86D4AC57 for ; Fri, 22 Feb 2013 10:46:08 +0400 (MSK) Date: Fri, 22 Feb 2013 10:46:03 +0400 From: Lev Serebryakov Organization: FreeBSD X-Priority: 3 (Normal) Message-ID: <108875110.20130222104603@serebryakov.spb.ru> To: freebsd-current Subject: r245741 (clang as cc) can not build binaries for GEODE processor MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: lev@FreeBSD.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 06:46:10 -0000 Hello, freebsd-current. I have -CURRENT i386 installation which runs r245741 now. Default compiler is clang: > cc --version FreeBSD clang version 3.2 (tags/RELEASE_32/final 170710) 20121221 Target: i386-unknown-freebsd10.0 Thread model: posix This system is used to build NanoBSD images (and ports for these images) for my home router, which has AMD Geode CPU: Geode(TM) Integrated Processor by AMD PCS (499.91-MHz 586-class CPU) Build system has only one setting in /etc/src.conf and /etc/make.conf: MALLOC_PRODUCTION=yes NanoBSD image build includes many options, and "CPUTYPE=geode" is among them. Today I've rebuilt all ports (including samba36) and image (from r247117). And new samba port (samba36-3.6.12) failed to start on target system (with Geode CPU). It gets "SIGILL" (!!!). I was able to get core file by running "testparam" in NFS-mounted R/W file system, but after that GDB (on build system, as NanoBSD image doesn't contain one) says, that it could not access memory at failure address to show disassembly: > gdb /usr/local/bin/testparm ~/testparm.core GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd"...(no debugging symbols found)... Core was generated by `testparm'. Program terminated with signal 4, Illegal instruction. #0 0x010351d6 in ?? () (gdb) x/i $pc 0x10351d6: Cannot access memory at address 0x10351d6 (gdb) bt #0 0x010351d6 in ?? () #1 0x00000000 in ?? () (gdb) -- // Black Lion AKA Lev Serebryakov From owner-freebsd-current@FreeBSD.ORG Fri Feb 22 07:54:23 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id AEF09756 for ; Fri, 22 Feb 2013 07:54:23 +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 09356CE5 for ; Fri, 22 Feb 2013 07:54:22 +0000 (UTC) Received: from porto.starpoint.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 JAA15848; Fri, 22 Feb 2013 09:54:13 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1U8nSO-000KIc-5P; Fri, 22 Feb 2013 09:54:13 +0200 Message-ID: <51272422.5090101@FreeBSD.org> Date: Fri, 22 Feb 2013 09:54:10 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130220 Thunderbird/17.0.3 MIME-Version: 1.0 To: Peter Jeremy Subject: Re: No ZFS when loading modules from loeader prompt References: <5124E646.3060304@zedat.fu-berlin.de> <20130222003827.GA15631@server.rulingia.com> In-Reply-To: <20130222003827.GA15631@server.rulingia.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Current FreeBSD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 07:54:23 -0000 on 22/02/2013 02:38 Peter Jeremy said the following: > On Wed, Feb 20, 2013 at 7:05 AM, O. Hartmann wrote: >> At the loader prompt, I need to unload the buggy kernel and load the old >> working one via >> >> load /boot/kernel.old/kernel >> >> Then I load also the ZFS related modules >> >> load /boot/kernel.old/opensolaris.ko >> load /boot/kernel.old/zfs.ko >> >> Issuing boot at the end of that stage boots the kernel - the old one >> -successfully - but there is no working ZFS and no ZFS volume gets >> mounted although the rc.conf is executed correctly. >> >> What am I doing wrong at that point? Why isn't ZFS run and mount properly? > > Last time I ran into this problem, the issue was that "unload" also > unloaded the zpool.cache file and the ZFS code relied on that to find > the kernel. I don't recall what the workaround was. zpool.cache should not be required any longer for the root pool. It is still required to auto-import other pools after boot. > On 2013-Feb-20 08:17:46 -0800, Freddie Cash wrote: >> Sounds like a perfect use case for Boot Environments. Create a new BE, >> install the new kernel into it, set it as the default, reboot. If it >> fails, you manually set the previous BE as the default, and reboot. That >> way, your "known-good", working environment is never affected. > > How do you change your BE in the loader? Or how do you change your > BE when you can't boot? > Short answer: you set currdev in loader prompt. A high-level overview of FreeBSD ZFS boot process is here: http://ru.kyivbsd.org.ua/arhiv/2012/kyivbsd12-gapon-zfs.pdf?attredirects=0&d=1 Section "ZFS Boot Process" -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Fri Feb 22 08:21:54 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id CF1D1E7E for ; Fri, 22 Feb 2013 08:21:54 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 44417E5B for ; Fri, 22 Feb 2013 08:21:54 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.6/8.14.6) with ESMTP id r1M8LjYI060984; Fri, 22 Feb 2013 10:21:45 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.7.4 kib.kiev.ua r1M8LjYI060984 Received: (from kostik@localhost) by tom.home (8.14.6/8.14.6/Submit) id r1M8Ljsm060983; Fri, 22 Feb 2013 10:21:45 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 22 Feb 2013 10:21:45 +0200 From: Konstantin Belousov To: Claude Buisson Subject: Re: DVD/CD lost after r246713 Message-ID: <20130222082145.GJ2598@kib.kiev.ua> References: <51265A58.4010600@orange.fr> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="w8XPRyCD3+ebNMRa" Content-Disposition: inline In-Reply-To: <51265A58.4010600@orange.fr> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 08:21:54 -0000 --w8XPRyCD3+ebNMRa Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Feb 21, 2013 at 06:33:12PM +0100, Claude Buisson wrote: > Hi, >=20 > When trying to update a i386 system from r245422 to r246923, the DVD/CD d= evices > cd0/cd1 could no more be attached. >=20 > Here is a relevant part of a verbose dmaeg: >=20 > pass0 at ata0 bus 0 scbus0 target 0 lun 0 > pass0: ATA-8 device > pass0: Serial Number WD-WCAV2F115406 > pass0: 100.000MB/s transfers (UDMA5, PIO 8192bytes) > pass1 at ata0 bus 0 scbus0 target 1 lun 0 > pass1: ATA-5 device > pass1: Serial Number WD-WMA8F2128712 > pass1: 100.000MB/s transfers (UDMA5, PIO 8192bytes) > pass2 at ata1 bus 0 scbus1 target 0 lun 0 > pass2: Removable CD-ROM SCSI-0 device > pass2: 33.300MB/s transfers (UDMA2, ATAPI 12bytes, PIO 65534bytes) > pass3 at ata1 bus 0 scbus1 target 1 lun 0 > pass3: Removable CD-ROM SCSI-0 device > pass3: 33.300MB/s transfers (UDMA2, ATAPI 12bytes, PIO 65534bytes) > TSC timecounter discards lower 1 bit(s) > Timecounter "TSC-low" frequency 1196040076 Hz quality 800 > uhub0: 2 ports with 2 removable, self powered > uhub1: 2 ports with 2 removable, self powered > uhub2: 2 ports with 2 removable, self powered > GEOM: new disk cd0 > GEOM: new disk cd1 > GEOM: new disk ada0 > GEOM: new disk ada1 > uhub3: 6 ports with 6 removable, self powered > ugen0.2: at usbus0 > ums0: on u= sbus0 > ums0: 3 buttons and [XYZ] coordinates ID=3D0 > ata1: reset tp1 mask=3D03 ostat0=3Dd0 ostat1=3D50 > ata1: stat0=3D0x10 err=3D0x01 lsb=3D0x14 msb=3D0xeb > ata1: stat1=3D0x10 err=3D0x01 lsb=3D0x14 msb=3D0xeb > ata1: reset tp2 stat0=3D10 stat1=3D10 devices=3D0x30000 > (cd0:ata1:0:0:0): got CAM status 0x50 > (cd0:ata1:0:0:0): fatal error, failed to attach to device > (cd0:ata1:0:0:0): lost device, 4 refs > Opened disk cd0 -> 6 > (cd0:ata1:0:0:0): removing device entryata1: reset tp1 mask=3D03 ostat0= =3D50 ostat1=3Dd0 > ata1: stat0=3D0x10 err=3D0x01 lsb=3D0x14 msb=3D0xeb > ata1: stat1=3D0x10 err=3D0x01 lsb=3D0x14 msb=3D0xeb > ata1: reset tp2 stat0=3D10 stat1=3D10 devices=3D0x30000 > (cd1:ata1:0:1:0): got CAM status 0x50 > (cd1:ata1:0:1:0): fatal error, failed to attach to device > (cd1:ata1:0:1:0): lost device, 4 refs > Opened disk cd1 -> 6 > (cd1:ata1:0:1:0): removing device entry >=20 > First i tried some snapshots from allbsd.org, to verify that the same pro= blem > existed with independently generated systems, then I made a search to fin= d that > the "culprit" was: >=20 > Author: kib > Date: Tue Feb 12 16:57:20 2013 > New Revision: 246713 > URL: http://svnweb.freebsd.org/changeset/base/246713 >=20 > Log: > Reform the busdma API so that new types may be added without modifying > every architecture's busdma_machdep.c. It is done by unifying the > bus_dmamap_load_buffer() routines so that they may be called from MI > code. The MD busdma is then given a chance to do any final processing > in the complete() callback. >=20 > The cam changes unify the bus_dmamap_load* handling in cam drivers. >=20 > The arm and mips implementations are updated to track virtual > addresses for sync(). Previously this was done in a type specific > way. Now it is done in a generic way by recording the list of > virtuals in the map. >=20 > Submitted by: jeff (sponsored by EMC/Isilon) > Reviewed by: kan (previous version), scottl, > mjacob (isp(4), no objections for target mode changes) > Discussed with: ian (arm changes) > Tested by: marius (sparc64), mips (jmallet), isci(4) on x86 (jharris), > amd64 (Fabian Keil ) >=20 > I even tried to rebuild the system WITHOUT_CLANG, just to eliminate the > "compiler factor" (with r247000 applied of course). >=20 > If necessary I can send complete verbose dmesg at r245422 and r246923. >=20 > Thanks for your attention >=20 > CBu >=20 > P.S. GREAT THANKS to allbsd.org for this its very useful collection of wo= rking > memstick images ! but with the remark that the documented revision number= s seems > to be inexacts: the 246711 snapshot exhibited this same problem (?!) You need to provide the dmesg from r246713 and r246712 to compare. The note that r246711 snapshot exhibited this same problem makes me sceptical. --w8XPRyCD3+ebNMRa Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJRJyqYAAoJEJDCuSvBvK1B1UcP/jN2AnlT8ByMYLLJSwo239q0 dHKRJoslV0Uoh7D0AVmB1bNQxeKd4/jDr7lUKWR2p8gCSsqJUd2FZFp39jkA6N41 ZO3on3U9bAqEp9HI+OUM8ayBdarQprrkmwEveyFqAxOdrIYrgGvYUkzrqJGJHs07 muR6Ou9Xwah08lp7npMOOnKIpzmeMfE050FMPkfRZBu2BCP14z8zsef0bIv9olDp GDlSnnXs4avmKU1eufeJuB1hena4D1thZ8hmRiAm4wz6vzRdX/VnGhqWgIRf1NHo O5QB+DkEUwQT/+xy2avd7FF3cZVFDzMH3+16uB76g7r1dfzTI8ZXo/Uz4E70B2K/ sU0L7caZd/uMU+pvSAmsy/XOLRLzcUoHCjTHXES7YEUtIwSHa/UBkaENDVeT1RC9 FHAXqTMu/bTl+CRg2iU9PxVpW6kFZDX+HN4VrNDfdmdu0CgO5n1ea7QX7MVBJrAA qfzHx0vnkIeN96F1QndO4NJ/0R62K2lwcj5I2p+VZxnc4ZK0VhqGZsUyBPrz2pIi 6Tn90tCVIKHShiyH4wc9e6Ra/mQYQRtT9Va4vC65qQUql76waH8lEtB5+AOGUH2L w7Mqe6WTe36RcRG2fu1HBj2Q9Gmzr7DXG+RM5lEnCvUCS0yA2aYAcct706KFqlto hfQ78z5RSeX0t1Tr88Ua =vqSv -----END PGP SIGNATURE----- --w8XPRyCD3+ebNMRa-- From owner-freebsd-current@FreeBSD.ORG Fri Feb 22 11:19:48 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 501399BD; Fri, 22 Feb 2013 11:19: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 26FA983D; Fri, 22 Feb 2013 11:19:47 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r1MBJkNt096778; Fri, 22 Feb 2013 06:19:46 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r1MBJkh2096775; Fri, 22 Feb 2013 11:19:46 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 22 Feb 2013 11:19:46 GMT Message-Id: <201302221119.r1MBJkh2096775@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 , , Subject: [head tinderbox] failure on i386/i386 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 11:19:48 -0000 TB --- 2013-02-22 06:40:17 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-02-22 06:40:17 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-02-22 06:40:17 - starting HEAD tinderbox run for i386/i386 TB --- 2013-02-22 06:40:17 - cleaning the object tree TB --- 2013-02-22 06:40:17 - /usr/local/bin/svn stat /src TB --- 2013-02-22 06:40:21 - At svn revision 247144 TB --- 2013-02-22 06:40:22 - building world TB --- 2013-02-22 06:40:22 - CROSS_BUILD_TESTING=YES TB --- 2013-02-22 06:40:22 - MAKEOBJDIRPREFIX=/obj TB --- 2013-02-22 06:40:22 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-02-22 06:40:22 - SRCCONF=/dev/null TB --- 2013-02-22 06:40:22 - TARGET=i386 TB --- 2013-02-22 06:40:22 - TARGET_ARCH=i386 TB --- 2013-02-22 06:40:22 - TZ=UTC TB --- 2013-02-22 06:40:22 - __MAKE_CONF=/dev/null TB --- 2013-02-22 06:40:22 - cd /src TB --- 2013-02-22 06:40:22 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Fri Feb 22 06:40:27 UTC 2013 >>> 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 Fri Feb 22 09:28:30 UTC 2013 TB --- 2013-02-22 09:28:30 - generating LINT kernel config TB --- 2013-02-22 09:28:30 - cd /src/sys/i386/conf TB --- 2013-02-22 09:28:30 - /usr/bin/make -B LINT TB --- 2013-02-22 09:28:30 - cd /src/sys/i386/conf TB --- 2013-02-22 09:28:30 - /usr/sbin/config -m LINT TB --- 2013-02-22 09:28:30 - building LINT kernel TB --- 2013-02-22 09:28:30 - CROSS_BUILD_TESTING=YES TB --- 2013-02-22 09:28:30 - MAKEOBJDIRPREFIX=/obj TB --- 2013-02-22 09:28:30 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-02-22 09:28:30 - SRCCONF=/dev/null TB --- 2013-02-22 09:28:30 - TARGET=i386 TB --- 2013-02-22 09:28:30 - TARGET_ARCH=i386 TB --- 2013-02-22 09:28:30 - TZ=UTC TB --- 2013-02-22 09:28:30 - __MAKE_CONF=/dev/null TB --- 2013-02-22 09:28:30 - cd /src TB --- 2013-02-22 09:28:30 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Fri Feb 22 09:28:30 UTC 2013 >>> 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 LINT completed on Fri Feb 22 09:59:12 UTC 2013 TB --- 2013-02-22 09:59:12 - cd /src/sys/i386/conf TB --- 2013-02-22 09:59:12 - /usr/sbin/config -m LINT-NOINET TB --- 2013-02-22 09:59:12 - building LINT-NOINET kernel TB --- 2013-02-22 09:59:12 - CROSS_BUILD_TESTING=YES TB --- 2013-02-22 09:59:12 - MAKEOBJDIRPREFIX=/obj TB --- 2013-02-22 09:59:12 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-02-22 09:59:12 - SRCCONF=/dev/null TB --- 2013-02-22 09:59:12 - TARGET=i386 TB --- 2013-02-22 09:59:12 - TARGET_ARCH=i386 TB --- 2013-02-22 09:59:12 - TZ=UTC TB --- 2013-02-22 09:59:12 - __MAKE_CONF=/dev/null TB --- 2013-02-22 09:59:12 - cd /src TB --- 2013-02-22 09:59:12 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET >>> Kernel build for LINT-NOINET started on Fri Feb 22 09:59:12 UTC 2013 >>> 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 LINT-NOINET completed on Fri Feb 22 10:28:05 UTC 2013 TB --- 2013-02-22 10:28:05 - cd /src/sys/i386/conf TB --- 2013-02-22 10:28:05 - /usr/sbin/config -m LINT-NOINET6 TB --- 2013-02-22 10:28:05 - building LINT-NOINET6 kernel TB --- 2013-02-22 10:28:05 - CROSS_BUILD_TESTING=YES TB --- 2013-02-22 10:28:05 - MAKEOBJDIRPREFIX=/obj TB --- 2013-02-22 10:28:05 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-02-22 10:28:05 - SRCCONF=/dev/null TB --- 2013-02-22 10:28:05 - TARGET=i386 TB --- 2013-02-22 10:28:05 - TARGET_ARCH=i386 TB --- 2013-02-22 10:28:05 - TZ=UTC TB --- 2013-02-22 10:28:05 - __MAKE_CONF=/dev/null TB --- 2013-02-22 10:28:05 - cd /src TB --- 2013-02-22 10:28:05 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET6 >>> Kernel build for LINT-NOINET6 started on Fri Feb 22 10:28:05 UTC 2013 >>> 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 LINT-NOINET6 completed on Fri Feb 22 10:57:31 UTC 2013 TB --- 2013-02-22 10:57:31 - cd /src/sys/i386/conf TB --- 2013-02-22 10:57:31 - /usr/sbin/config -m LINT-NOIP TB --- 2013-02-22 10:57:31 - building LINT-NOIP kernel TB --- 2013-02-22 10:57:31 - CROSS_BUILD_TESTING=YES TB --- 2013-02-22 10:57:31 - MAKEOBJDIRPREFIX=/obj TB --- 2013-02-22 10:57:31 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-02-22 10:57:31 - SRCCONF=/dev/null TB --- 2013-02-22 10:57:31 - TARGET=i386 TB --- 2013-02-22 10:57:31 - TARGET_ARCH=i386 TB --- 2013-02-22 10:57:31 - TZ=UTC TB --- 2013-02-22 10:57:31 - __MAKE_CONF=/dev/null TB --- 2013-02-22 10:57:31 - cd /src TB --- 2013-02-22 10:57:31 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOIP >>> Kernel build for LINT-NOIP started on Fri Feb 22 10:57:31 UTC 2013 >>> 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 [...] objcopy --strip-debug mw88W8363fw.ko ===> mxge (all) ===> mxge/mxge (all) cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/i386.i386/src/sys/LINT-NOIP/opt_global.h -I. -I@ -I@/contrib/altq -fno-common -I/obj/i386.i386/src/sys/LINT-NOIP -fno-builtin -mno-aes -mno-avx -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -std=iso9899:1999 -Qunused-arguments -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 -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -c /src/sys/modules/mxge/mxge/../../../dev/mxge/if_mxge.c /src/sys/modules/mxge/mxge/../../../dev/mxge/if_mxge.c:2563:6: error: unused variable 'cap' [-Werror,-Wunused-variable] int cap = m->m_pkthdr.rcvif->if_capenable; ^ 1 error generated. *** [if_mxge.o] Error code 1 Stop in /src/sys/modules/mxge/mxge. *** [all] Error code 1 Stop in /src/sys/modules/mxge. *** [all] Error code 1 Stop in /src/sys/modules. *** [modules-all] Error code 1 Stop in /obj/i386.i386/src/sys/LINT-NOIP. *** [buildkernel] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-02-22 11:19:46 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-02-22 11:19:46 - ERROR: failed to build LINT-NOIP kernel TB --- 2013-02-22 11:19:46 - 13056.75 user 2209.21 system 16768.89 real http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Fri Feb 22 11:45:45 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id BC300DFC for ; Fri, 22 Feb 2013 11:45:45 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [46.4.40.135]) by mx1.freebsd.org (Postfix) with ESMTP id 6A213925 for ; Fri, 22 Feb 2013 11:45:45 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:509e:5349:4e7a:bf0a]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPA id 03CA74AC57 for ; Fri, 22 Feb 2013 15:45:37 +0400 (MSK) Date: Fri, 22 Feb 2013 15:45:31 +0400 From: Lev Serebryakov Organization: FreeBSD X-Priority: 3 (Normal) Message-ID: <1392799308.20130222154531@serebryakov.spb.ru> To: freebsd-current Subject: r247144 panics on boot with "memory modified after free" on VBox MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: lev@FreeBSD.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 11:45:45 -0000 Hello, freebsd-current. $subj GENERIC kernel (with WITNESS and other debug stuff), typical VBox virtual machine with AHCI disks and CD. Two "Most recently used by" variants: "cd" and "GEOM". -- // Black Lion AKA Lev Serebryakov From owner-freebsd-current@FreeBSD.ORG Fri Feb 22 11:48:44 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 1CA1CF67; Fri, 22 Feb 2013 11:48:44 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id E1FA6950; Fri, 22 Feb 2013 11:48:43 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r1MBmh7W072378; Fri, 22 Feb 2013 06:48:43 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r1MBmhZg072373; Fri, 22 Feb 2013 11:48:43 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 22 Feb 2013 11:48:43 GMT Message-Id: <201302221148.r1MBmhZg072373@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 , , Subject: [head tinderbox] failure on amd64/amd64 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 11:48:44 -0000 TB --- 2013-02-22 06:40:17 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-02-22 06:40:17 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-02-22 06:40:17 - starting HEAD tinderbox run for amd64/amd64 TB --- 2013-02-22 06:40:17 - cleaning the object tree TB --- 2013-02-22 06:40:17 - /usr/local/bin/svn stat /src TB --- 2013-02-22 06:40:21 - At svn revision 247144 TB --- 2013-02-22 06:40:22 - building world TB --- 2013-02-22 06:40:22 - CROSS_BUILD_TESTING=YES TB --- 2013-02-22 06:40:22 - MAKEOBJDIRPREFIX=/obj TB --- 2013-02-22 06:40:22 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-02-22 06:40:22 - SRCCONF=/dev/null TB --- 2013-02-22 06:40:22 - TARGET=amd64 TB --- 2013-02-22 06:40:22 - TARGET_ARCH=amd64 TB --- 2013-02-22 06:40:22 - TZ=UTC TB --- 2013-02-22 06:40:22 - __MAKE_CONF=/dev/null TB --- 2013-02-22 06:40:22 - cd /src TB --- 2013-02-22 06:40:22 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Fri Feb 22 06:40:27 UTC 2013 >>> 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 Fri Feb 22 10:01:55 UTC 2013 TB --- 2013-02-22 10:01:55 - generating LINT kernel config TB --- 2013-02-22 10:01:55 - cd /src/sys/amd64/conf TB --- 2013-02-22 10:01:55 - /usr/bin/make -B LINT TB --- 2013-02-22 10:01:55 - cd /src/sys/amd64/conf TB --- 2013-02-22 10:01:55 - /usr/sbin/config -m LINT TB --- 2013-02-22 10:01:55 - building LINT kernel TB --- 2013-02-22 10:01:55 - CROSS_BUILD_TESTING=YES TB --- 2013-02-22 10:01:55 - MAKEOBJDIRPREFIX=/obj TB --- 2013-02-22 10:01:55 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-02-22 10:01:55 - SRCCONF=/dev/null TB --- 2013-02-22 10:01:55 - TARGET=amd64 TB --- 2013-02-22 10:01:55 - TARGET_ARCH=amd64 TB --- 2013-02-22 10:01:55 - TZ=UTC TB --- 2013-02-22 10:01:55 - __MAKE_CONF=/dev/null TB --- 2013-02-22 10:01:55 - cd /src TB --- 2013-02-22 10:01:55 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Fri Feb 22 10:01:55 UTC 2013 >>> 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 LINT completed on Fri Feb 22 10:31:33 UTC 2013 TB --- 2013-02-22 10:31:33 - cd /src/sys/amd64/conf TB --- 2013-02-22 10:31:33 - /usr/sbin/config -m LINT-NOINET TB --- 2013-02-22 10:31:33 - building LINT-NOINET kernel TB --- 2013-02-22 10:31:33 - CROSS_BUILD_TESTING=YES TB --- 2013-02-22 10:31:33 - MAKEOBJDIRPREFIX=/obj TB --- 2013-02-22 10:31:33 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-02-22 10:31:33 - SRCCONF=/dev/null TB --- 2013-02-22 10:31:33 - TARGET=amd64 TB --- 2013-02-22 10:31:33 - TARGET_ARCH=amd64 TB --- 2013-02-22 10:31:33 - TZ=UTC TB --- 2013-02-22 10:31:33 - __MAKE_CONF=/dev/null TB --- 2013-02-22 10:31:33 - cd /src TB --- 2013-02-22 10:31:33 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET >>> Kernel build for LINT-NOINET started on Fri Feb 22 10:31:33 UTC 2013 >>> 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 LINT-NOINET completed on Fri Feb 22 10:58:42 UTC 2013 TB --- 2013-02-22 10:58:42 - cd /src/sys/amd64/conf TB --- 2013-02-22 10:58:42 - /usr/sbin/config -m LINT-NOINET6 TB --- 2013-02-22 10:58:42 - building LINT-NOINET6 kernel TB --- 2013-02-22 10:58:42 - CROSS_BUILD_TESTING=YES TB --- 2013-02-22 10:58:42 - MAKEOBJDIRPREFIX=/obj TB --- 2013-02-22 10:58:42 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-02-22 10:58:42 - SRCCONF=/dev/null TB --- 2013-02-22 10:58:42 - TARGET=amd64 TB --- 2013-02-22 10:58:42 - TARGET_ARCH=amd64 TB --- 2013-02-22 10:58:42 - TZ=UTC TB --- 2013-02-22 10:58:42 - __MAKE_CONF=/dev/null TB --- 2013-02-22 10:58:42 - cd /src TB --- 2013-02-22 10:58:42 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET6 >>> Kernel build for LINT-NOINET6 started on Fri Feb 22 10:58:42 UTC 2013 >>> 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 LINT-NOINET6 completed on Fri Feb 22 11:26:55 UTC 2013 TB --- 2013-02-22 11:26:55 - cd /src/sys/amd64/conf TB --- 2013-02-22 11:26:55 - /usr/sbin/config -m LINT-NOIP TB --- 2013-02-22 11:26:55 - building LINT-NOIP kernel TB --- 2013-02-22 11:26:55 - CROSS_BUILD_TESTING=YES TB --- 2013-02-22 11:26:55 - MAKEOBJDIRPREFIX=/obj TB --- 2013-02-22 11:26:55 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-02-22 11:26:55 - SRCCONF=/dev/null TB --- 2013-02-22 11:26:55 - TARGET=amd64 TB --- 2013-02-22 11:26:55 - TARGET_ARCH=amd64 TB --- 2013-02-22 11:26:55 - TZ=UTC TB --- 2013-02-22 11:26:55 - __MAKE_CONF=/dev/null TB --- 2013-02-22 11:26:55 - cd /src TB --- 2013-02-22 11:26:55 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOIP >>> Kernel build for LINT-NOIP started on Fri Feb 22 11:26:55 UTC 2013 >>> 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 [...] objcopy --strip-debug mw88W8363fw.ko ===> mxge (all) ===> mxge/mxge (all) cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/amd64.amd64/src/sys/LINT-NOIP/opt_global.h -I. -I@ -I@/contrib/altq -fno-common -fno-omit-frame-pointer -I/obj/amd64.amd64/src/sys/LINT-NOIP -fno-builtin -mno-aes -mno-avx -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -std=iso9899:1999 -Qunused-arguments -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 -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -c /src/sys/modules/mxge/mxge/../../../dev/mxge/if_mxge.c /src/sys/modules/mxge/mxge/../../../dev/mxge/if_mxge.c:2563:6: error: unused variable 'cap' [-Werror,-Wunused-variable] int cap = m->m_pkthdr.rcvif->if_capenable; ^ 1 error generated. *** [if_mxge.o] Error code 1 Stop in /src/sys/modules/mxge/mxge. *** [all] Error code 1 Stop in /src/sys/modules/mxge. *** [all] Error code 1 Stop in /src/sys/modules. *** [modules-all] Error code 1 Stop in /obj/amd64.amd64/src/sys/LINT-NOIP. *** [buildkernel] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-02-22 11:48:43 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-02-22 11:48:43 - ERROR: failed to build LINT-NOIP kernel TB --- 2013-02-22 11:48:43 - 14271.70 user 2494.02 system 18505.63 real http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-amd64-amd64.full From owner-freebsd-current@FreeBSD.ORG Fri Feb 22 11:50:36 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id DC744160 for ; Fri, 22 Feb 2013 11:50:36 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [46.4.40.135]) by mx1.freebsd.org (Postfix) with ESMTP id 9E9E597D for ; Fri, 22 Feb 2013 11:50:36 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:509e:5349:4e7a:bf0a]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPA id BD2F14AC57 for ; Fri, 22 Feb 2013 15:50:35 +0400 (MSK) Date: Fri, 22 Feb 2013 15:50:30 +0400 From: Lev Serebryakov Organization: FreeBSD X-Priority: 3 (Normal) Message-ID: <1166029593.20130222155030@serebryakov.spb.ru> To: freebsd-current Subject: Re: r247144 panics on boot with "memory modified after free" on VBox In-Reply-To: <1392799308.20130222154531@serebryakov.spb.ru> References: <1392799308.20130222154531@serebryakov.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: lev@FreeBSD.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 11:50:36 -0000 Hello, Lev. You wrote 22 =D1=84=D0=B5=D0=B2=D1=80=D0=B0=D0=BB=D1=8F 2013 =D0=B3., 15:45= :31: LS> $subj LS> GENERIC kernel (with WITNESS and other debug stuff), typical VBox LS> virtual machine with AHCI disks and CD. LS> Two "Most recently used by" variants: "cd" and "GEOM". Removing virtual PATA CD from configuration allows me to boot. --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-current@FreeBSD.ORG Fri Feb 22 12:04:14 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 659BC5BA; Fri, 22 Feb 2013 12:04:14 +0000 (UTC) (envelope-from dnebdal@gmail.com) Received: from mail-la0-x236.google.com (la-in-x0236.1e100.net [IPv6:2a00:1450:4010:c03::236]) by mx1.freebsd.org (Postfix) with ESMTP id 9E3A0A3A; Fri, 22 Feb 2013 12:04:13 +0000 (UTC) Received: by mail-la0-f54.google.com with SMTP id gw10so538901lab.27 for ; Fri, 22 Feb 2013 04:04:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=yhGva/hFqkdtgSdJ6nWgcmjrRiB8pQUBg0CJtM86M6s=; b=gEJWfqkUYJs0T6iT5Xmg5MWzsR4Qas223IRiOpUmeDaZW9iC7Nft5S9ltRW+FdtSOZ 5B51l3oi9OPNQUSlVuImEXGyXRc/cZeqYs6RAD01n8rB1t0yy8s52fEptBsGyfjEG1zt QSE6gh+LqTuJjs5nu9KSxMu+4mhACCI+4Dl9b16fB3Ecj+lIQv9UdSohLRXF+ERGnGfE BSOQKGDM2sUnbuB255rRJkfRKc7Hb9KRdnMyVASMB5vxCfUmKVQwqxtdimWg9Q5kBQw4 vNB8pV0iZftX8f1Ft0cjysysfWBFqh7+yf46pZyGQ03z8afsAHjCf2ooUsDfqfejUw/N R+aQ== MIME-Version: 1.0 X-Received: by 10.152.113.164 with SMTP id iz4mr1509215lab.50.1361534651289; Fri, 22 Feb 2013 04:04:11 -0800 (PST) Received: by 10.112.80.133 with HTTP; Fri, 22 Feb 2013 04:04:11 -0800 (PST) In-Reply-To: <108875110.20130222104603@serebryakov.spb.ru> References: <108875110.20130222104603@serebryakov.spb.ru> Date: Fri, 22 Feb 2013 13:04:11 +0100 Message-ID: Subject: Re: r245741 (clang as cc) can not build binaries for GEODE processor From: Daniel Nebdal To: lev@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 12:04:14 -0000 On Fri, Feb 22, 2013 at 7:46 AM, Lev Serebryakov wrote: > Hello, freebsd-current. > > I have -CURRENT i386 installation which runs r245741 now. > Default compiler is clang: > >> cc --version > FreeBSD clang version 3.2 (tags/RELEASE_32/final 170710) 20121221 > Target: i386-unknown-freebsd10.0 > Thread model: posix > > This system is used to build NanoBSD images (and ports for these > images) for my home router, which has AMD Geode CPU: > > Geode(TM) Integrated Processor by AMD PCS (499.91-MHz 586-class CPU) > > Build system has only one setting in /etc/src.conf and > /etc/make.conf: > > MALLOC_PRODUCTION=yes > > NanoBSD image build includes many options, and "CPUTYPE=geode" is > among them. > > Today I've rebuilt all ports (including samba36) and image (from > r247117). And new samba port (samba36-3.6.12) failed to start on > target system (with Geode CPU). It gets "SIGILL" (!!!). > > I was able to get core file by running "testparam" in NFS-mounted > R/W file system, but after that GDB (on build system, as NanoBSD > image doesn't contain one) says, that it could not access memory at > failure address to show disassembly: > >> gdb /usr/local/bin/testparm ~/testparm.core > GNU gdb 6.1.1 [FreeBSD] > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you are > welcome to change it and/or distribute copies of it under certain conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for details. > This GDB was configured as "i386-marcel-freebsd"...(no debugging symbols found)... > Core was generated by `testparm'. > Program terminated with signal 4, Illegal instruction. > #0 0x010351d6 in ?? () > (gdb) x/i $pc > 0x10351d6: Cannot access memory at address 0x10351d6 > (gdb) bt > #0 0x010351d6 in ?? () > #1 0x00000000 in ?? () > (gdb) > > -- > // Black Lion AKA Lev Serebryakov > > _______________________________________________ > 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 familiar with NanoBSD, but does it do the package builds for you - or do you do those by hand? If it's the latter, I don't quite understand how the compiler is supposed to know the target CPUTYPE? -- Daniel Nebdal From owner-freebsd-current@FreeBSD.ORG Fri Feb 22 12:08:52 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id A83407A3 for ; Fri, 22 Feb 2013 12:08:52 +0000 (UTC) (envelope-from clbuisson@orange.fr) Received: from smtp.smtpout.orange.fr (smtp12.smtpout.orange.fr [80.12.242.134]) by mx1.freebsd.org (Postfix) with ESMTP id 7BC0CA80 for ; Fri, 22 Feb 2013 12:08:50 +0000 (UTC) Received: from localhost ([90.45.150.58]) by mwinf5d47 with ME id 3Q8g1l00G1FqZUy03Q8go5; Fri, 22 Feb 2013 13:08:43 +0100 Message-ID: <51275FC7.9010906@orange.fr> Date: Fri, 22 Feb 2013 13:08:39 +0100 From: Claude Buisson User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:10.0.12) Gecko/20130109 Thunderbird/10.0.12 MIME-Version: 1.0 To: Konstantin Belousov Subject: Re: DVD/CD lost after r246713 References: <51265A58.4010600@orange.fr> <20130222082145.GJ2598@kib.kiev.ua> In-Reply-To: <20130222082145.GJ2598@kib.kiev.ua> Content-Type: multipart/mixed; boundary="------------080201020409000902080309" Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 12:08:52 -0000 This is a multi-part message in MIME format. --------------080201020409000902080309 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 02/22/2013 09:21, Konstantin Belousov wrote: > You need to provide the dmesg from r246713 and r246712 to compare. > The note that r246711 snapshot exhibited this same problem makes > me sceptical. Here are the verbose dmesg from r246712 and r246713; For the sceptical: root@fidel# cd /usr/src root@fidel# grep "\$FreeBSD\:" sys/conf/files # $FreeBSD: head/sys/conf/files 246586 2013-02-09 06:39:28Z delphij $ root@fidel# grep "\$FreeBSD\:" sys/ia64/ia64/dump_machdep.c __FBSDID("$FreeBSD: head/sys/ia64/ia64/dump_machdep.c 246712 2013-02-12 16:51:43Z marcel $"); for r246712 root@fidel# cd /usr/src root@fidel# grep "\$FreeBSD\:" sys/conf/files # $FreeBSD: head/sys/conf/files 246713 2013-02-12 16:57:20Z kib $ root@fidel# grep "\$FreeBSD\:" sys/ia64/include/proc.h * $FreeBSD: head/sys/ia64/include/proc.h 226112 2011-10-07 16:09:44Z kib $ for r246713 The source is from svn0.us-east.freebsd.org And obj/ has been rm'ed before each buildkernel My own conclusion is that the rev number in: FreeBSD-10.0-HEAD-r246711-JPSNAP-i386-i386-memstick.img is bogus, and this can be easily checked by grepping for kern/subr_bus_dma.c in the BUILD.log as this file has been ADDED by r246713 CBu (working on this since Tuesday) --------------080201020409000902080309 Content-Type: text/plain; name="dmesg.246712" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="dmesg.246712" MP Configuration Table version 1.4 found at 0xc00f0000 Table 'FACP' at 0xfd539 Table 'SSDT' at 0xfffd0dfb Table 'APIC' at 0xfd5ad APIC: Found table at 0xfd5ad APIC: Using the MADT enumerator. MADT: Found CPU APIC ID 0 ACPI ID 1: enabled MADT: Found CPU APIC ID 1 ACPI ID 2: disabled MADT: Found CPU APIC ID 1 ACPI ID 3: disabled MADT: Found CPU APIC ID 7 ACPI ID 4: disabled Copyright (c) 1992-2013 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 10.0-CURRENT #0: Fri Feb 22 11:42:36 CET 2013 toor@fidel:/usr/obj/home/src/sys/ADELE10X i386 gcc version 4.2.1 20070831 patched [FreeBSD] Preloaded elf kernel "/boot/kernel/kernel" at 0xc09e8000. Preloaded elf module "/boot/kernel/snd_emu10kx.ko" at 0xc09e8188. Preloaded elf module "/boot/kernel/sound.ko" at 0xc09e8238. Preloaded elf module "/boot/kernel/ums.ko" at 0xc09e82e4. Preloaded elf module "/boot/kernel/umass.ko" at 0xc09e838c. Preloaded elf module "/boot/kernel/mac_stub.ko" at 0xc09e8438. Calibrating TSC clock ... TSC clock: 2392079600 Hz CPU: Intel(R) Pentium(R) 4 CPU 2.40GHz (2392.08-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf27 Family = 0xf Model = 0x2 Stepping = 7 Features=0xbfebfbff Features2=0x4400 Instruction TLB: 4 KB, 2 MB or 4 MB pages, fully associative, 128 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 = 1073741824 (1024 MB) Physical memory chunk(s): 0x0000000000001000 - 0x000000000009ffff, 651264 bytes (159 pages) 0x0000000000100000 - 0x00000000003fffff, 3145728 bytes (768 pages) 0x0000000000c26000 - 0x000000003ed21fff, 1041219584 bytes (254204 pages) avail memory = 1040982016 (992 MB) Event timer "LAPIC" quality 400 ACPI APIC Table: APIC: CPU 0 has ACPI ID 1 bios32: Found BIOS32 Service Directory header at 0xc00ffe80 bios32: Entry = 0xffe90 (c00ffe90) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xf0000+0xbe62 pnpbios: Found PnP BIOS data at 0xc00fe2d0 pnpbios: Entry = f0000:e2f4 Rev = 1.0 Other BIOS signatures found: Security policy loaded: TrustedBSD MAC/Stub (mac_stub) ACPI: RSDP 0xfeb90 00014 (v00 DELL ) ACPI: RSDT 0xfd501 00038 (v01 DELL 4550 00000008 ASL 00000061) ACPI: FACP 0xfd539 00074 (v01 DELL 4550 00000008 ASL 00000061) ACPI: DSDT 0xfffceb2b 022D0 (v01 DELL dt_ex 00001000 MSFT 0100000D) ACPI: FACS 0x3ff75000 00040 ACPI: SSDT 0xfffd0dfb 000A7 (v01 DELL st_ex 00001000 MSFT 0100000D) ACPI: APIC 0xfd5ad 0006C (v01 DELL 4550 00000008 ASL 00000061) ACPI: BOOT 0xfd619 00028 (v01 DELL 4550 00000008 ASL 00000061) ACPI: ASF! 0xfd641 00067 (v16 DELL 4550 00000008 ASL 00000061) MADT: Found IO APIC ID 8, Interrupt 0 at 0xfec00000 ioapic0: Changing APIC ID to 8 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: VESA: INT 0x10 vector 0xc000:0x149a VESA: information block 0000 56 45 53 41 00 03 00 01 00 01 01 00 00 00 22 00 0010 00 01 00 04 17 04 07 01 00 01 1a 01 00 01 28 01 0020 00 01 00 01 01 01 02 01 03 01 04 01 05 01 06 01 0030 07 01 08 01 09 01 0a 01 0b 01 0c 01 0e 01 0f 01 0040 11 01 12 01 14 01 15 01 17 01 18 01 1a 01 30 01 0050 31 01 32 01 33 01 34 01 35 01 36 01 3d 01 3e 01 0060 45 01 46 01 47 01 48 01 ff ff 00 00 00 00 00 00 0070 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0080 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0090 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0100 4e 56 69 64 69 61 00 4e 56 69 64 69 61 20 43 6f 0110 72 70 6f 72 61 74 69 6f 6e 00 4e 56 31 37 20 28 0120 29 20 42 6f 61 72 64 00 43 68 69 70 20 52 65 76 0130 20 41 32 00 00 00 00 00 00 00 00 00 00 00 00 00 0140 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0150 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0160 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0170 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0180 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0190 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 VESA: 35 mode(s) found VESA: v3.0, 65536k memory, flags:0x1, mode table:0xc2d85022 (1000022) VESA: NVidia VESA: NVidia Corporation NV17 () Board Chip Rev A2 io: random: mem: Pentium Pro MTRR support enabled acpi0: on motherboard ACPI: All ACPI Tables successfully acquired ioapic0: routing intpin 9 (ISA IRQ 9) to lapic 0 vector 48 acpi0: Power Button (fixed) acpi0: wakeup code va 0xc2dac000 pa 0x2000 pci_open(1): mode 1 addr port (0x0cf8) is 0x80010064 pci_open(1a): mode1res=0x80000000 (0x80000000) pci_cfgcheck: device 0 [class=060000] [hdr=00] is there (id=25608086) pcibios: BIOS version 2.10 acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, f00000 (3) failed acpi0: reservation of 1000000, 3ef75000 (3) failed cpu0: on acpi0 cpu0: switching to generic Cx mode ACPI: Processor \134_PR_.CPU1 (ACPI ID 2) ignored atrtc0: port 0x70-0x7f 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 49 Event timer "RTC" frequency 32768 Hz quality 0 attimer0: port 0x40-0x5f irq 0 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 ioapic0: routing intpin 2 (ISA IRQ 0) to lapic 0 vector 50 Event timer "i8254" frequency 1193182 Hz quality 100 ACPI timer: 1/1 1/0 1/0 1/1 1/1 1/0 1/0 1/0 1/1 1/1 -> 10 Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 pci_link0: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 3 4 5 6 7 9 10 11 12 15 Validation 0 11 N 0 3 4 5 6 7 9 10 11 12 15 After Disable 0 255 N 0 3 4 5 6 7 9 10 11 12 15 pci_link1: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 3 4 5 6 7 9 10 11 12 15 Validation 0 11 N 0 3 4 5 6 7 9 10 11 12 15 After Disable 0 255 N 0 3 4 5 6 7 9 10 11 12 15 pci_link2: Index IRQ Rtd Ref IRQs Initial Probe 0 9 N 0 3 4 5 6 7 9 10 11 12 15 Validation 0 9 N 0 3 4 5 6 7 9 10 11 12 15 After Disable 0 255 N 0 3 4 5 6 7 9 10 11 12 15 pci_link3: Index IRQ Rtd Ref IRQs Initial Probe 0 10 N 0 3 4 5 6 7 9 10 11 12 15 Validation 0 10 N 0 3 4 5 6 7 9 10 11 12 15 After Disable 0 255 N 0 3 4 5 6 7 9 10 11 12 15 pci_link4: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 3 4 5 6 7 9 10 11 12 15 Validation 0 11 N 0 3 4 5 6 7 9 10 11 12 15 After Disable 0 255 N 0 3 4 5 6 7 9 10 11 12 15 pci_link5: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 4 5 6 7 9 10 11 12 15 Validation 0 255 N 0 3 4 5 6 7 9 10 11 12 15 After Disable 0 255 N 0 3 4 5 6 7 9 10 11 12 15 pci_link6: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 3 4 5 6 7 9 10 11 12 15 Validation 0 11 N 0 3 4 5 6 7 9 10 11 12 15 After Disable 0 255 N 0 3 4 5 6 7 9 10 11 12 15 pci_link7: Index IRQ Rtd Ref IRQs Initial Probe 0 3 N 0 3 4 5 6 7 9 10 11 12 15 Validation 0 3 N 0 3 4 5 6 7 9 10 11 12 15 After Disable 0 255 N 0 3 4 5 6 7 9 10 11 12 15 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pcib0: decoding 4 range 0-0xcf7 pcib0: decoding 4 range 0xd00-0xffff pcib0: decoding 3 range 0xa0000-0xbffff pcib0: decoding 3 range 0xc0000000-0xfebfffff pcib0: decoding 3 range 0xfef00000-0xffafffff pci0: on pcib0 pci0: domain=0, physical bus=0 found-> vendor=0x8086, dev=0x2560, revid=0x01 domain=0, bus=0, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0106, 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 0xe8000000, size 27, enabled pcib0: allocated type 3 (0xe8000000-0xefffffff) for rid 10 of pci0:0:0:0 found-> vendor=0x8086, dev=0x2561, revid=0x01 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=0x0c (3000 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x24c2, 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=11 map[20]: type I/O Port, range 32, base 0xff80, size 5, enabled pcib0: allocated type 4 (0xff80-0xff9f) for rid 20 of pci0:0:29:0 pcib0: matched entry for 0.29.INTA pcib0: slot 29 INTA hardwired to IRQ 16 found-> vendor=0x8086, dev=0x24c4, 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 0xff60, size 5, enabled pcib0: allocated type 4 (0xff60-0xff7f) for rid 20 of pci0:0:29:1 pcib0: matched entry for 0.29.INTB pcib0: slot 29 INTB hardwired to IRQ 19 found-> vendor=0x8086, dev=0x24c7, 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=9 map[20]: type I/O Port, range 32, base 0xff40, size 5, enabled pcib0: allocated type 4 (0xff40-0xff5f) for rid 20 of pci0:0:29:2 pcib0: matched entry for 0.29.INTC pcib0: slot 29 INTC hardwired to IRQ 18 found-> vendor=0x8086, dev=0x24cd, revid=0x01 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=3 powerspec 2 supports D0 D3 current D0 map[10]: type Memory, range 32, base 0xfe300000, size 10, enabled pcib0: allocated type 3 (0xfe300000-0xfe3003ff) for rid 10 of pci0:0:29:7 pcib0: matched entry for 0.29.INTD pcib0: slot 29 INTD hardwired to IRQ 23 found-> vendor=0x8086, dev=0x244e, revid=0x81 domain=0, bus=0, slot=30, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0107, statreg=0x8080, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x06 (1500 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x24c0, revid=0x01 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=0x24cb, revid=0x01 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 pcib0: allocated type 4 (0x1f0-0x1f7) for rid 10 of pci0:0:31:1 pcib0: allocated type 4 (0x3f6-0x3f6) for rid 14 of pci0:0:31:1 pcib0: allocated type 4 (0x170-0x177) for rid 18 of pci0:0:31:1 pcib0: allocated type 4 (0x376-0x376) for rid 1c of pci0:0:31:1 map[20]: type I/O Port, range 32, base 0xffa0, size 4, enabled pcib0: allocated type 4 (0xffa0-0xffaf) for rid 20 of pci0:0:31:1 map[24]: type Memory, range 32, base 0, size 10, memory disabled found-> vendor=0x8086, dev=0x24c3, revid=0x01 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=11 map[20]: type I/O Port, range 32, base 0xdc80, size 5, enabled pcib0: allocated type 4 (0xdc80-0xdc9f) for rid 20 of pci0:0:31:3 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 pcib0: allocated type 3 (0xfc000000-0xfdffffff) for rid 20 of pcib1 pcib0: allocated type 3 (0xf0000000-0xf7ffffff) for rid 24 of pcib1 pcib1: domain 0 pcib1: secondary bus 1 pcib1: subordinate bus 1 pcib1: memory decode 0xfc000000-0xfdffffff pcib1: prefetched decode 0xf0000000-0xf7ffffff pci1: on pcib1 pci1: domain=0, physical bus=1 found-> vendor=0x10de, dev=0x0172, revid=0xa3 domain=0, bus=1, slot=0, func=0 class=03-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0003, statreg=0x02b0, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x05 (1250 ns), maxlat=0x01 (250 ns) intpin=a, irq=11 powerspec 2 supports D0 D3 current D0 map[10]: type Memory, range 32, base 0xfc000000, size 24, enabled pcib1: allocated memory range (0xfc000000-0xfcffffff) for rid 10 of pci0:1:0:0 map[14]: type Prefetchable Memory, range 32, base 0xf4000000, size 26, enabled pcib1: allocated prefetch range (0xf4000000-0xf7ffffff) for rid 14 of pci0:1:0:0 map[18]: type Prefetchable Memory, range 32, base 0xf3f80000, size 19, enabled pcib1: allocated prefetch range (0xf3f80000-0xf3ffffff) 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 vgapci0: mem 0xfc000000-0xfcffffff,0xf4000000-0xf7ffffff,0xf3f80000-0xf3ffffff irq 16 at device 0.0 on pci1 uhci0: port 0xff80-0xff9f irq 16 at device 29.0 on pci0 ioapic0: routing intpin 16 (PCI IRQ 16) to lapic 0 vector 51 usbus0 on uhci0 uhci0: usbpf: Attached uhci1: port 0xff60-0xff7f irq 19 at device 29.1 on pci0 ioapic0: routing intpin 19 (PCI IRQ 19) to lapic 0 vector 52 usbus1 on uhci1 uhci1: usbpf: Attached uhci2: port 0xff40-0xff5f irq 18 at device 29.2 on pci0 ioapic0: routing intpin 18 (PCI IRQ 18) to lapic 0 vector 53 usbus2 on uhci2 uhci2: usbpf: Attached ehci0: mem 0xfe300000-0xfe3003ff irq 23 at device 29.7 on pci0 ioapic0: routing intpin 23 (PCI IRQ 23) to lapic 0 vector 54 usbus3: EHCI version 1.0 usbus3 on ehci0 ehci0: usbpf: Attached pcib2: at device 30.0 on pci0 pcib0: allocated type 4 (0xe000-0xefff) for rid 1c of pcib2 pcib0: allocated type 3 (0xfe100000-0xfe2fffff) for rid 20 of pcib2 pcib2: domain 0 pcib2: secondary bus 2 pcib2: subordinate bus 2 pcib2: I/O decode 0xe000-0xefff pcib2: memory decode 0xfe100000-0xfe2fffff pcib2: no prefetched decode pcib2: Subtractively decoded bridge. pci2: on pcib2 pci2: domain=0, physical bus=2 found-> vendor=0x1102, dev=0x0002, revid=0x0a domain=0, bus=2, slot=1, func=0 class=04-01-00, hdrtype=0x00, mfdev=1 cmdreg=0x0105, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x02 (500 ns), maxlat=0x14 (5000 ns) intpin=a, irq=11 powerspec 1 supports D0 D1 D2 D3 current D0 map[10]: type I/O Port, range 32, base 0xece0, size 5, enabled pcib2: allocated I/O port range (0xece0-0xecff) for rid 10 of pci0:2:1:0 pcib2: matched entry for 2.1.INTA pcib2: slot 1 INTA hardwired to IRQ 22 found-> vendor=0x1102, dev=0x7002, revid=0x0a domain=0, bus=2, slot=1, func=1 class=09-80-00, hdrtype=0x00, mfdev=1 cmdreg=0x0105, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) powerspec 1 supports D0 D1 D2 D3 current D0 map[10]: type I/O Port, range 32, base 0xecd8, size 3, enabled pcib2: allocated I/O port range (0xecd8-0xecdf) for rid 10 of pci0:2:1:1 found-> vendor=0x8086, dev=0x1039, revid=0x81 domain=0, bus=2, slot=8, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0117, statreg=0x0290, cachelnsz=16 (dwords) lattimer=0x40 (1920 ns), mingnt=0x08 (2000 ns), maxlat=0x38 (14000 ns) intpin=a, irq=11 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type Memory, range 32, base 0xfe1ff000, size 12, enabled pcib2: allocated memory range (0xfe1ff000-0xfe1fffff) for rid 10 of pci0:2:8:0 map[14]: type I/O Port, range 32, base 0xec80, size 6, enabled pcib2: allocated I/O port range (0xec80-0xecbf) for rid 14 of pci0:2:8:0 pcib2: matched entry for 2.8.INTA pcib2: slot 8 INTA hardwired to IRQ 20 emu10kx0: port 0xece0-0xecff irq 22 at device 1.0 on pci2 ioapic0: routing intpin 22 (PCI IRQ 22) to lapic 0 vector 55 emu10kx: setmap (3ecd0000, 8000), nseg=1, error=0 emu10kx: setmap (3ece0000, 1000), nseg=1, error=0 emu10kx0: Card Configuration ( 0x00004215 ) emu10kx0: Card Configuration ( & 0xff000000 ) : emu10kx0: Card Configuration ( & 0x00ff0000 ) : emu10kx0: Card Configuration ( & 0x0000ff00 ) : [GPINPUT0] [Joystick] emu10kx0: Card Configuration ( & 0x000000ff ) : [AUTOMUTE] [LOCKTANKCACHE] [AUDIOENABLE] pcm0: on emu10kx0 pcm0: pcm0: Codec features 18 bit DAC, 18 bit ADC, 5 bit master volume, SigmaTel 3D Enhancement pcm0: Primary codec extended features surround DAC 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 "line2": pcm0: Mixer "line3": pcm0: Mixer "dig1": pcm0: Mixer "dig2": pcm0: Mixer "dig3": pcm0: Mixer "phin": pcm0: Mixer "phout": pcm0: Mixer "video": emu10kx: setmap (3ecf0000, 1000), nseg=1, error=0 emu10kx: setmap (1c00000, 1000), nseg=1, error=0 emu10kx: setmap (1c10000, 1000), nseg=1, error=0 emu10kx: setmap (1c20000, 1000), nseg=1, error=0 pcm1: on emu10kx0 pcm1: Mixer "vol": pcm1: Mixer "pcm": emu10kx: setmap (1c40000, 1000), nseg=1, error=0 pci2: at device 1.1 (no driver attached) fxp0: port 0xec80-0xecbf mem 0xfe1ff000-0xfe1fffff irq 20 at device 8.0 on pci2 fxp0: using memory space register mapping fxp0: PCI IDs: 8086 1039 1028 0142 0081 fxp0: Dynamic Standby mode is disabled miibus0: on fxp0 inphy0: PHY 1 on miibus0 inphy0: OUI 0x005500, model 0x0033, rev. 0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto, auto-flow fxp0: bpf attached fxp0: Ethernet address: 00:07:e9:c0:3f:e1 ioapic0: routing intpin 20 (PCI IRQ 20) to lapic 0 vector 56 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: at channel 0 on atapci0 ioapic0: routing intpin 14 (ISA IRQ 14) to lapic 0 vector 57 ata1: at channel 1 on atapci0 ioapic0: routing intpin 15 (ISA IRQ 15) to lapic 0 vector 58 ichsmb0: port 0xdc80-0xdc9f irq 17 at device 31.3 on pci0 ioapic0: routing intpin 17 (PCI IRQ 17) to lapic 0 vector 59 smbus0: on ichsmb0 smb0: on smbus0 fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: ic_type 90 part_id 80 ioapic0: routing intpin 6 (ISA IRQ 6) to lapic 0 vector 60 fd0: <1440-KB 3.5" drive> on fdc0 drive 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: atkbd0, AT 101/102 (2), config:0x0, flags:0x3d0000 ioapic0: routing intpin 1 (ISA IRQ 1) to lapic 0 vector 61 atkbd0: [GIANT-LOCKED] psm0: unable to allocate IRQ uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 ioapic0: routing intpin 4 (ISA IRQ 4) to lapic 0 vector 62 uart0: fast interrupt ppc0: using extended I/O port range ppc0: SPP ECP ECP+EPP ppc0: port 0x378-0x37f,0x778-0x77f irq 7 on acpi0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/8 bytes threshold ioapic0: routing intpin 7 (ISA IRQ 7) to lapic 0 vector 63 ppbus0: on ppc0 ACPI: Enabled 1 GPEs in block 00 to 1F 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 pcib0: allocated type 3 (0xa0000-0xa07ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa0800-0xa0fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa1000-0xa17ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa1800-0xa1fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa2000-0xa27ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa2800-0xa2fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa3000-0xa37ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa3800-0xa3fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa4000-0xa47ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa4800-0xa4fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa5000-0xa57ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa5800-0xa5fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa6000-0xa67ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa6800-0xa6fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa7000-0xa77ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa7800-0xa7fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa8000-0xa87ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa8800-0xa8fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa9000-0xa97ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa9800-0xa9fff) for rid 0 of orm0 pcib0: allocated type 3 (0xaa000-0xaa7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xaa800-0xaafff) for rid 0 of orm0 pcib0: allocated type 3 (0xab000-0xab7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xab800-0xabfff) for rid 0 of orm0 pcib0: allocated type 3 (0xac000-0xac7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xac800-0xacfff) for rid 0 of orm0 pcib0: allocated type 3 (0xad000-0xad7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xad800-0xadfff) for rid 0 of orm0 pcib0: allocated type 3 (0xae000-0xae7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xae800-0xaefff) for rid 0 of orm0 pcib0: allocated type 3 (0xaf000-0xaf7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xaf800-0xaffff) for rid 0 of orm0 pcib0: allocated type 3 (0xb0000-0xb07ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb0800-0xb0fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb1000-0xb17ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb1800-0xb1fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb2000-0xb27ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb2800-0xb2fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb3000-0xb37ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb3800-0xb3fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb4000-0xb47ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb4800-0xb4fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb5000-0xb57ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb5800-0xb5fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb6000-0xb67ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb6800-0xb6fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb7000-0xb77ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb7800-0xb7fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb8000-0xb87ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb8800-0xb8fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb9000-0xb97ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb9800-0xb9fff) for rid 0 of orm0 pcib0: allocated type 3 (0xba000-0xba7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xba800-0xbafff) for rid 0 of orm0 pcib0: allocated type 3 (0xbb000-0xbb7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xbb800-0xbbfff) for rid 0 of orm0 pcib0: allocated type 3 (0xbc000-0xbc7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xbc800-0xbcfff) for rid 0 of orm0 pcib0: allocated type 3 (0xbd000-0xbd7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xbd800-0xbdfff) for rid 0 of orm0 pcib0: allocated type 3 (0xbe000-0xbe7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xbe800-0xbefff) for rid 0 of orm0 pcib0: allocated type 3 (0xbf000-0xbf7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xbf800-0xbffff) for rid 0 of orm0 isa_probe_children: disabling PnP devices pmtimer0 on isa0 atkbdc: atkbdc0 already exists; skipping it atrtc: atrtc0 already exists; skipping it attimer: attimer0 already exists; skipping it fdc: fdc0 already exists; skipping it ppc: ppc0 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 0xc0000-0xcf7ff,0xcf800-0xcffff,0xe0000-0xe17ff,0xe1800-0xe3fff pnpid ORM0000 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <12 virtual consoles, flags=0x300> sc0: fb0, kbd0, terminal emulator: scteken (teken terminal) vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 pcib0: allocated type 4 (0x3c0-0x3df) for rid 0 of vga0 pcib0: allocated type 3 (0xa0000-0xbffff) for rid 0 of vga0 isa_probe_children: probing PnP devices Device configuration finished. lapic: Divisor 2, Frequency 66445545 Hz Timecounters tick every 1.000 msec tcp_init: net.inet.tcp.tcbhashsize auto tuned to 8192 lo0: bpf attached usbus0: 12Mbps Full Speed USB v1.0 usbus1: 12Mbps Full Speed USB v1.0 usbus2: 12Mbps Full Speed USB v1.0 usbus3: 480Mbps High Speed USB v2.0 ata0: reset tp1 mask=03 ostat0=50 ostat1=50 ata0: stat0=0x50 err=0x01 lsb=0x00 msb=0x00 ata0: stat1=0x50 err=0x01 lsb=0x00 msb=0x00 ata0: reset tp2 stat0=50 stat1=50 devices=0x3 ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 ugen2.1: at usbus2 uhub2: on usbus2 ugen3.1: at usbus3 uhub3: on usbus3 ata1: reset tp1 mask=03 ostat0=50 ostat1=00 ata1: stat0=0x10 err=0x01 lsb=0x14 msb=0xeb ata1: stat1=0x00 err=0x01 lsb=0x14 msb=0xeb ata1: reset tp2 stat0=10 stat1=00 devices=0x30000 pass0 at ata0 bus 0 scbus0 target 0 lun 0 pass0: ATA-8 device pass0: Serial Number WD-WCAV2F115406 pass0: 100.000MB/s transfers (UDMA5, PIO 8192bytes) pass1 at ata0 bus 0 scbus0 target 1 lun 0 pass1: ATA-5 device pass1: Serial Number WD-WMA8F2128712 pass1: 100.000MB/s transfers (UDMA5, PIO 8192bytes) pass2 at ata1 bus 0 scbus1 target 0 lun 0 pass2: Removable CD-ROM SCSI-0 device pass2: 33.300MB/s transfers (UDMA2, ATAPI 12bytes, PIO 65534bytes) pass3 at ata1 bus 0 scbus1 target 1 lun 0 pass3: Removable CD-ROM SCSI-0 device pass3: 33.300MB/s transfers (UDMA2, ATAPI 12bytes, PIO 65534bytes) 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 ada0 at ata0 bus 0 scbus0 target 0 lun 0 ada0: ATA-8 device ada0: Serial Number WD-WCAV2F115406 cd1 at ata1 bus 0 scbus1 target 1 lun 0 cd1: Removable CD-ROM SCSI-0 device cd1: 33.300MB/s transfers (UDMA2, ATAPI 12bytes, PIO 65534bytes) cd1: Attempt to query device size failed: NOT READY, Medium not present - tray closed ada0: 100.000MB/s transfers (UDMA5, PIO 8192bytes) ada0: 305245MB (625142448 512 byte sectors: 16H 63S/T 16383C) ada0: Previously was known as ad0 ada1 at ata0 bus 0 scbus0 target 1 lun 0 ada1: ATA-5 device ada1: Serial Number WD-WMA8F2128712 ada1: 100.000MB/s transfers (UDMA5, PIO 8192bytes) ada1: 57220MB (117187500 512 byte sectors: 16H 63S/T 16383C) ada1: Previously was known as ad1 TSC timecounter discards lower 1 bit(s) Timecounter "TSC-low" frequency 1196039800 Hz quality 800 uhub0: 2 ports with 2 removable, self powered uhub1: 2 ports with 2 removable, self powered uhub2: 2 ports with 2 removable, self powered GEOM: new disk cd0 GEOM: new disk cd1 GEOM: new disk ada0 GEOM: new disk ada1 Root mount waiting for: usbus3 Root mount waiting for: usbus3 uhub3: 6 ports with 6 removable, self powered Trying to mount root from ufs:/dev/ada0s3a [rw]... start_init: trying /sbin/init procfs registered ugen0.2: at usbus0 ums0: on usbus0 ums0: 3 buttons and [XYZ] coordinates ID=0 Linux ELF exec handler installed nfslock: pseudo-device --------------080201020409000902080309 Content-Type: text/plain; name="dmesg.246713" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="dmesg.246713" MP Configuration Table version 1.4 found at 0xc00f0000 Table 'FACP' at 0xfd539 Table 'SSDT' at 0xfffd0dfb Table 'APIC' at 0xfd5ad APIC: Found table at 0xfd5ad APIC: Using the MADT enumerator. MADT: Found CPU APIC ID 0 ACPI ID 1: enabled MADT: Found CPU APIC ID 1 ACPI ID 2: disabled MADT: Found CPU APIC ID 1 ACPI ID 3: disabled MADT: Found CPU APIC ID 7 ACPI ID 4: disabled Copyright (c) 1992-2013 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 10.0-CURRENT #0: Fri Feb 22 12:21:59 CET 2013 toor@fidel:/usr/obj/home/src/sys/ADELE10X i386 gcc version 4.2.1 20070831 patched [FreeBSD] Preloaded elf kernel "/boot/kernel/kernel" at 0xc09ea000. Preloaded elf module "/boot/kernel/snd_emu10kx.ko" at 0xc09ea188. Preloaded elf module "/boot/kernel/sound.ko" at 0xc09ea238. Preloaded elf module "/boot/kernel/ums.ko" at 0xc09ea2e4. Preloaded elf module "/boot/kernel/umass.ko" at 0xc09ea38c. Preloaded elf module "/boot/kernel/mac_stub.ko" at 0xc09ea438. Calibrating TSC clock ... TSC clock: 2392078492 Hz CPU: Intel(R) Pentium(R) 4 CPU 2.40GHz (2392.08-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf27 Family = 0xf Model = 0x2 Stepping = 7 Features=0xbfebfbff Features2=0x4400 Instruction TLB: 4 KB, 2 MB or 4 MB pages, fully associative, 128 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 = 1073741824 (1024 MB) Physical memory chunk(s): 0x0000000000001000 - 0x000000000009ffff, 651264 bytes (159 pages) 0x0000000000100000 - 0x00000000003fffff, 3145728 bytes (768 pages) 0x0000000000c26000 - 0x000000003ed21fff, 1041219584 bytes (254204 pages) avail memory = 1040982016 (992 MB) Event timer "LAPIC" quality 400 ACPI APIC Table: APIC: CPU 0 has ACPI ID 1 bios32: Found BIOS32 Service Directory header at 0xc00ffe80 bios32: Entry = 0xffe90 (c00ffe90) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xf0000+0xbe62 pnpbios: Found PnP BIOS data at 0xc00fe2d0 pnpbios: Entry = f0000:e2f4 Rev = 1.0 Other BIOS signatures found: Security policy loaded: TrustedBSD MAC/Stub (mac_stub) ACPI: RSDP 0xfeb90 00014 (v00 DELL ) ACPI: RSDT 0xfd501 00038 (v01 DELL 4550 00000008 ASL 00000061) ACPI: FACP 0xfd539 00074 (v01 DELL 4550 00000008 ASL 00000061) ACPI: DSDT 0xfffceb2b 022D0 (v01 DELL dt_ex 00001000 MSFT 0100000D) ACPI: FACS 0x3ff75000 00040 ACPI: SSDT 0xfffd0dfb 000A7 (v01 DELL st_ex 00001000 MSFT 0100000D) ACPI: APIC 0xfd5ad 0006C (v01 DELL 4550 00000008 ASL 00000061) ACPI: BOOT 0xfd619 00028 (v01 DELL 4550 00000008 ASL 00000061) ACPI: ASF! 0xfd641 00067 (v16 DELL 4550 00000008 ASL 00000061) MADT: Found IO APIC ID 8, Interrupt 0 at 0xfec00000 ioapic0: Changing APIC ID to 8 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: VESA: INT 0x10 vector 0xc000:0x149a VESA: information block 0000 56 45 53 41 00 03 00 01 00 01 01 00 00 00 22 00 0010 00 01 00 04 17 04 07 01 00 01 1a 01 00 01 28 01 0020 00 01 00 01 01 01 02 01 03 01 04 01 05 01 06 01 0030 07 01 08 01 09 01 0a 01 0b 01 0c 01 0e 01 0f 01 0040 11 01 12 01 14 01 15 01 17 01 18 01 1a 01 30 01 0050 31 01 32 01 33 01 34 01 35 01 36 01 3d 01 3e 01 0060 45 01 46 01 47 01 48 01 ff ff 00 00 00 00 00 00 0070 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0080 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0090 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0100 4e 56 69 64 69 61 00 4e 56 69 64 69 61 20 43 6f 0110 72 70 6f 72 61 74 69 6f 6e 00 4e 56 31 37 20 28 0120 29 20 42 6f 61 72 64 00 43 68 69 70 20 52 65 76 0130 20 41 32 00 00 00 00 00 00 00 00 00 00 00 00 00 0140 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0150 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0160 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0170 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0180 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0190 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 VESA: 35 mode(s) found VESA: v3.0, 65536k memory, flags:0x1, mode table:0xc2d85022 (1000022) VESA: NVidia VESA: NVidia Corporation NV17 () Board Chip Rev A2 io: random: mem: Pentium Pro MTRR support enabled acpi0: on motherboard ACPI: All ACPI Tables successfully acquired ioapic0: routing intpin 9 (ISA IRQ 9) to lapic 0 vector 48 acpi0: Power Button (fixed) acpi0: wakeup code va 0xc2dac000 pa 0x2000 pci_open(1): mode 1 addr port (0x0cf8) is 0x80010064 pci_open(1a): mode1res=0x80000000 (0x80000000) pci_cfgcheck: device 0 [class=060000] [hdr=00] is there (id=25608086) pcibios: BIOS version 2.10 acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, f00000 (3) failed acpi0: reservation of 1000000, 3ef75000 (3) failed cpu0: on acpi0 cpu0: switching to generic Cx mode ACPI: Processor \134_PR_.CPU1 (ACPI ID 2) ignored atrtc0: port 0x70-0x7f 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 49 Event timer "RTC" frequency 32768 Hz quality 0 attimer0: port 0x40-0x5f irq 0 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 ioapic0: routing intpin 2 (ISA IRQ 0) to lapic 0 vector 50 Event timer "i8254" frequency 1193182 Hz quality 100 ACPI timer: 1/0 1/1 1/1 1/0 1/1 1/0 1/0 1/1 1/0 1/0 -> 10 Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 pci_link0: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 3 4 5 6 7 9 10 11 12 15 Validation 0 11 N 0 3 4 5 6 7 9 10 11 12 15 After Disable 0 255 N 0 3 4 5 6 7 9 10 11 12 15 pci_link1: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 3 4 5 6 7 9 10 11 12 15 Validation 0 11 N 0 3 4 5 6 7 9 10 11 12 15 After Disable 0 255 N 0 3 4 5 6 7 9 10 11 12 15 pci_link2: Index IRQ Rtd Ref IRQs Initial Probe 0 9 N 0 3 4 5 6 7 9 10 11 12 15 Validation 0 9 N 0 3 4 5 6 7 9 10 11 12 15 After Disable 0 255 N 0 3 4 5 6 7 9 10 11 12 15 pci_link3: Index IRQ Rtd Ref IRQs Initial Probe 0 10 N 0 3 4 5 6 7 9 10 11 12 15 Validation 0 10 N 0 3 4 5 6 7 9 10 11 12 15 After Disable 0 255 N 0 3 4 5 6 7 9 10 11 12 15 pci_link4: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 3 4 5 6 7 9 10 11 12 15 Validation 0 11 N 0 3 4 5 6 7 9 10 11 12 15 After Disable 0 255 N 0 3 4 5 6 7 9 10 11 12 15 pci_link5: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 4 5 6 7 9 10 11 12 15 Validation 0 255 N 0 3 4 5 6 7 9 10 11 12 15 After Disable 0 255 N 0 3 4 5 6 7 9 10 11 12 15 pci_link6: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 3 4 5 6 7 9 10 11 12 15 Validation 0 11 N 0 3 4 5 6 7 9 10 11 12 15 After Disable 0 255 N 0 3 4 5 6 7 9 10 11 12 15 pci_link7: Index IRQ Rtd Ref IRQs Initial Probe 0 3 N 0 3 4 5 6 7 9 10 11 12 15 Validation 0 3 N 0 3 4 5 6 7 9 10 11 12 15 After Disable 0 255 N 0 3 4 5 6 7 9 10 11 12 15 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pcib0: decoding 4 range 0-0xcf7 pcib0: decoding 4 range 0xd00-0xffff pcib0: decoding 3 range 0xa0000-0xbffff pcib0: decoding 3 range 0xc0000000-0xfebfffff pcib0: decoding 3 range 0xfef00000-0xffafffff pci0: on pcib0 pci0: domain=0, physical bus=0 found-> vendor=0x8086, dev=0x2560, revid=0x01 domain=0, bus=0, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0106, 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 0xe8000000, size 27, enabled pcib0: allocated type 3 (0xe8000000-0xefffffff) for rid 10 of pci0:0:0:0 found-> vendor=0x8086, dev=0x2561, revid=0x01 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=0x0c (3000 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x24c2, 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=11 map[20]: type I/O Port, range 32, base 0xff80, size 5, enabled pcib0: allocated type 4 (0xff80-0xff9f) for rid 20 of pci0:0:29:0 pcib0: matched entry for 0.29.INTA pcib0: slot 29 INTA hardwired to IRQ 16 found-> vendor=0x8086, dev=0x24c4, 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 0xff60, size 5, enabled pcib0: allocated type 4 (0xff60-0xff7f) for rid 20 of pci0:0:29:1 pcib0: matched entry for 0.29.INTB pcib0: slot 29 INTB hardwired to IRQ 19 found-> vendor=0x8086, dev=0x24c7, 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=9 map[20]: type I/O Port, range 32, base 0xff40, size 5, enabled pcib0: allocated type 4 (0xff40-0xff5f) for rid 20 of pci0:0:29:2 pcib0: matched entry for 0.29.INTC pcib0: slot 29 INTC hardwired to IRQ 18 found-> vendor=0x8086, dev=0x24cd, revid=0x01 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=3 powerspec 2 supports D0 D3 current D0 map[10]: type Memory, range 32, base 0xfe300000, size 10, enabled pcib0: allocated type 3 (0xfe300000-0xfe3003ff) for rid 10 of pci0:0:29:7 pcib0: matched entry for 0.29.INTD pcib0: slot 29 INTD hardwired to IRQ 23 found-> vendor=0x8086, dev=0x244e, revid=0x81 domain=0, bus=0, slot=30, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0107, statreg=0x8080, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x06 (1500 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x24c0, revid=0x01 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=0x24cb, revid=0x01 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 pcib0: allocated type 4 (0x1f0-0x1f7) for rid 10 of pci0:0:31:1 pcib0: allocated type 4 (0x3f6-0x3f6) for rid 14 of pci0:0:31:1 pcib0: allocated type 4 (0x170-0x177) for rid 18 of pci0:0:31:1 pcib0: allocated type 4 (0x376-0x376) for rid 1c of pci0:0:31:1 map[20]: type I/O Port, range 32, base 0xffa0, size 4, enabled pcib0: allocated type 4 (0xffa0-0xffaf) for rid 20 of pci0:0:31:1 map[24]: type Memory, range 32, base 0, size 10, memory disabled found-> vendor=0x8086, dev=0x24c3, revid=0x01 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=11 map[20]: type I/O Port, range 32, base 0xdc80, size 5, enabled pcib0: allocated type 4 (0xdc80-0xdc9f) for rid 20 of pci0:0:31:3 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 pcib0: allocated type 3 (0xfc000000-0xfdffffff) for rid 20 of pcib1 pcib0: allocated type 3 (0xf0000000-0xf7ffffff) for rid 24 of pcib1 pcib1: domain 0 pcib1: secondary bus 1 pcib1: subordinate bus 1 pcib1: memory decode 0xfc000000-0xfdffffff pcib1: prefetched decode 0xf0000000-0xf7ffffff pci1: on pcib1 pci1: domain=0, physical bus=1 found-> vendor=0x10de, dev=0x0172, revid=0xa3 domain=0, bus=1, slot=0, func=0 class=03-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0003, statreg=0x02b0, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x05 (1250 ns), maxlat=0x01 (250 ns) intpin=a, irq=11 powerspec 2 supports D0 D3 current D0 map[10]: type Memory, range 32, base 0xfc000000, size 24, enabled pcib1: allocated memory range (0xfc000000-0xfcffffff) for rid 10 of pci0:1:0:0 map[14]: type Prefetchable Memory, range 32, base 0xf4000000, size 26, enabled pcib1: allocated prefetch range (0xf4000000-0xf7ffffff) for rid 14 of pci0:1:0:0 map[18]: type Prefetchable Memory, range 32, base 0xf3f80000, size 19, enabled pcib1: allocated prefetch range (0xf3f80000-0xf3ffffff) 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 vgapci0: mem 0xfc000000-0xfcffffff,0xf4000000-0xf7ffffff,0xf3f80000-0xf3ffffff irq 16 at device 0.0 on pci1 uhci0: port 0xff80-0xff9f irq 16 at device 29.0 on pci0 ioapic0: routing intpin 16 (PCI IRQ 16) to lapic 0 vector 51 usbus0 on uhci0 uhci0: usbpf: Attached uhci1: port 0xff60-0xff7f irq 19 at device 29.1 on pci0 ioapic0: routing intpin 19 (PCI IRQ 19) to lapic 0 vector 52 usbus1 on uhci1 uhci1: usbpf: Attached uhci2: port 0xff40-0xff5f irq 18 at device 29.2 on pci0 ioapic0: routing intpin 18 (PCI IRQ 18) to lapic 0 vector 53 usbus2 on uhci2 uhci2: usbpf: Attached ehci0: mem 0xfe300000-0xfe3003ff irq 23 at device 29.7 on pci0 ioapic0: routing intpin 23 (PCI IRQ 23) to lapic 0 vector 54 usbus3: EHCI version 1.0 usbus3 on ehci0 ehci0: usbpf: Attached pcib2: at device 30.0 on pci0 pcib0: allocated type 4 (0xe000-0xefff) for rid 1c of pcib2 pcib0: allocated type 3 (0xfe100000-0xfe2fffff) for rid 20 of pcib2 pcib2: domain 0 pcib2: secondary bus 2 pcib2: subordinate bus 2 pcib2: I/O decode 0xe000-0xefff pcib2: memory decode 0xfe100000-0xfe2fffff pcib2: no prefetched decode pcib2: Subtractively decoded bridge. pci2: on pcib2 pci2: domain=0, physical bus=2 found-> vendor=0x1102, dev=0x0002, revid=0x0a domain=0, bus=2, slot=1, func=0 class=04-01-00, hdrtype=0x00, mfdev=1 cmdreg=0x0105, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x02 (500 ns), maxlat=0x14 (5000 ns) intpin=a, irq=11 powerspec 1 supports D0 D1 D2 D3 current D0 map[10]: type I/O Port, range 32, base 0xece0, size 5, enabled pcib2: allocated I/O port range (0xece0-0xecff) for rid 10 of pci0:2:1:0 pcib2: matched entry for 2.1.INTA pcib2: slot 1 INTA hardwired to IRQ 22 found-> vendor=0x1102, dev=0x7002, revid=0x0a domain=0, bus=2, slot=1, func=1 class=09-80-00, hdrtype=0x00, mfdev=1 cmdreg=0x0105, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) powerspec 1 supports D0 D1 D2 D3 current D0 map[10]: type I/O Port, range 32, base 0xecd8, size 3, enabled pcib2: allocated I/O port range (0xecd8-0xecdf) for rid 10 of pci0:2:1:1 found-> vendor=0x8086, dev=0x1039, revid=0x81 domain=0, bus=2, slot=8, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0117, statreg=0x0290, cachelnsz=16 (dwords) lattimer=0x40 (1920 ns), mingnt=0x08 (2000 ns), maxlat=0x38 (14000 ns) intpin=a, irq=11 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type Memory, range 32, base 0xfe1ff000, size 12, enabled pcib2: allocated memory range (0xfe1ff000-0xfe1fffff) for rid 10 of pci0:2:8:0 map[14]: type I/O Port, range 32, base 0xec80, size 6, enabled pcib2: allocated I/O port range (0xec80-0xecbf) for rid 14 of pci0:2:8:0 pcib2: matched entry for 2.8.INTA pcib2: slot 8 INTA hardwired to IRQ 20 emu10kx0: port 0xece0-0xecff irq 22 at device 1.0 on pci2 ioapic0: routing intpin 22 (PCI IRQ 22) to lapic 0 vector 55 emu10kx: setmap (3ecd0000, 8000), nseg=1, error=0 emu10kx: setmap (3ece0000, 1000), nseg=1, error=0 emu10kx0: Card Configuration ( 0x00004215 ) emu10kx0: Card Configuration ( & 0xff000000 ) : emu10kx0: Card Configuration ( & 0x00ff0000 ) : emu10kx0: Card Configuration ( & 0x0000ff00 ) : [GPINPUT0] [Joystick] emu10kx0: Card Configuration ( & 0x000000ff ) : [AUTOMUTE] [LOCKTANKCACHE] [AUDIOENABLE] pcm0: on emu10kx0 pcm0: pcm0: Codec features 18 bit DAC, 18 bit ADC, 5 bit master volume, SigmaTel 3D Enhancement pcm0: Primary codec extended features surround DAC 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 "line2": pcm0: Mixer "line3": pcm0: Mixer "dig1": pcm0: Mixer "dig2": pcm0: Mixer "dig3": pcm0: Mixer "phin": pcm0: Mixer "phout": pcm0: Mixer "video": emu10kx: setmap (3ecf0000, 1000), nseg=1, error=0 emu10kx: setmap (1c00000, 1000), nseg=1, error=0 emu10kx: setmap (1c10000, 1000), nseg=1, error=0 emu10kx: setmap (1c20000, 1000), nseg=1, error=0 pcm1: on emu10kx0 pcm1: Mixer "vol": pcm1: Mixer "pcm": emu10kx: setmap (1c40000, 1000), nseg=1, error=0 pci2: at device 1.1 (no driver attached) fxp0: port 0xec80-0xecbf mem 0xfe1ff000-0xfe1fffff irq 20 at device 8.0 on pci2 fxp0: using memory space register mapping fxp0: PCI IDs: 8086 1039 1028 0142 0081 fxp0: Dynamic Standby mode is disabled miibus0: on fxp0 inphy0: PHY 1 on miibus0 inphy0: OUI 0x005500, model 0x0033, rev. 0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto, auto-flow fxp0: bpf attached fxp0: Ethernet address: 00:07:e9:c0:3f:e1 ioapic0: routing intpin 20 (PCI IRQ 20) to lapic 0 vector 56 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: at channel 0 on atapci0 ioapic0: routing intpin 14 (ISA IRQ 14) to lapic 0 vector 57 ata1: at channel 1 on atapci0 ioapic0: routing intpin 15 (ISA IRQ 15) to lapic 0 vector 58 ichsmb0: port 0xdc80-0xdc9f irq 17 at device 31.3 on pci0 ioapic0: routing intpin 17 (PCI IRQ 17) to lapic 0 vector 59 smbus0: on ichsmb0 smb0: on smbus0 fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: ic_type 90 part_id 80 ioapic0: routing intpin 6 (ISA IRQ 6) to lapic 0 vector 60 fd0: <1440-KB 3.5" drive> on fdc0 drive 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: atkbd0, AT 101/102 (2), config:0x0, flags:0x3d0000 ioapic0: routing intpin 1 (ISA IRQ 1) to lapic 0 vector 61 atkbd0: [GIANT-LOCKED] psm0: unable to allocate IRQ uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 ioapic0: routing intpin 4 (ISA IRQ 4) to lapic 0 vector 62 uart0: fast interrupt ppc0: using extended I/O port range ppc0: SPP ECP ECP+EPP ppc0: port 0x378-0x37f,0x778-0x77f irq 7 on acpi0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/8 bytes threshold ioapic0: routing intpin 7 (ISA IRQ 7) to lapic 0 vector 63 ppbus0: on ppc0 ACPI: Enabled 1 GPEs in block 00 to 1F 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 pcib0: allocated type 3 (0xa0000-0xa07ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa0800-0xa0fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa1000-0xa17ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa1800-0xa1fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa2000-0xa27ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa2800-0xa2fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa3000-0xa37ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa3800-0xa3fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa4000-0xa47ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa4800-0xa4fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa5000-0xa57ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa5800-0xa5fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa6000-0xa67ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa6800-0xa6fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa7000-0xa77ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa7800-0xa7fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa8000-0xa87ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa8800-0xa8fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa9000-0xa97ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa9800-0xa9fff) for rid 0 of orm0 pcib0: allocated type 3 (0xaa000-0xaa7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xaa800-0xaafff) for rid 0 of orm0 pcib0: allocated type 3 (0xab000-0xab7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xab800-0xabfff) for rid 0 of orm0 pcib0: allocated type 3 (0xac000-0xac7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xac800-0xacfff) for rid 0 of orm0 pcib0: allocated type 3 (0xad000-0xad7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xad800-0xadfff) for rid 0 of orm0 pcib0: allocated type 3 (0xae000-0xae7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xae800-0xaefff) for rid 0 of orm0 pcib0: allocated type 3 (0xaf000-0xaf7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xaf800-0xaffff) for rid 0 of orm0 pcib0: allocated type 3 (0xb0000-0xb07ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb0800-0xb0fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb1000-0xb17ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb1800-0xb1fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb2000-0xb27ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb2800-0xb2fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb3000-0xb37ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb3800-0xb3fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb4000-0xb47ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb4800-0xb4fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb5000-0xb57ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb5800-0xb5fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb6000-0xb67ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb6800-0xb6fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb7000-0xb77ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb7800-0xb7fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb8000-0xb87ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb8800-0xb8fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb9000-0xb97ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb9800-0xb9fff) for rid 0 of orm0 pcib0: allocated type 3 (0xba000-0xba7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xba800-0xbafff) for rid 0 of orm0 pcib0: allocated type 3 (0xbb000-0xbb7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xbb800-0xbbfff) for rid 0 of orm0 pcib0: allocated type 3 (0xbc000-0xbc7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xbc800-0xbcfff) for rid 0 of orm0 pcib0: allocated type 3 (0xbd000-0xbd7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xbd800-0xbdfff) for rid 0 of orm0 pcib0: allocated type 3 (0xbe000-0xbe7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xbe800-0xbefff) for rid 0 of orm0 pcib0: allocated type 3 (0xbf000-0xbf7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xbf800-0xbffff) for rid 0 of orm0 isa_probe_children: disabling PnP devices pmtimer0 on isa0 atkbdc: atkbdc0 already exists; skipping it atrtc: atrtc0 already exists; skipping it attimer: attimer0 already exists; skipping it fdc: fdc0 already exists; skipping it ppc: ppc0 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 0xc0000-0xcf7ff,0xcf800-0xcffff,0xe0000-0xe17ff,0xe1800-0xe3fff pnpid ORM0000 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <12 virtual consoles, flags=0x300> sc0: fb0, kbd0, terminal emulator: scteken (teken terminal) vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 pcib0: allocated type 4 (0x3c0-0x3df) for rid 0 of vga0 pcib0: allocated type 3 (0xa0000-0xbffff) for rid 0 of vga0 isa_probe_children: probing PnP devices Device configuration finished. lapic: Divisor 2, Frequency 66445537 Hz Timecounters tick every 1.000 msec tcp_init: net.inet.tcp.tcbhashsize auto tuned to 8192 lo0: bpf attached usbus0: 12Mbps Full Speed USB v1.0 usbus1: 12Mbps Full Speed USB v1.0 usbus2: 12Mbps Full Speed USB v1.0 usbus3: 480Mbps High Speed USB v2.0 ata0: reset tp1 mask=03 ostat0=50 ostat1=50 ata0: stat0=0x50 err=0x01 lsb=0x00 msb=0x00 ata0: stat1=0x50 err=0x01 lsb=0x00 msb=0x00 ata0: reset tp2 stat0=50 stat1=50 devices=0x3 ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 ugen2.1: at usbus2 uhub2: on usbus2 ugen3.1: at usbus3 uhub3: on usbus3 ata1: reset tp1 mask=03 ostat0=50 ostat1=00 ata1: stat0=0x10 err=0x01 lsb=0x14 msb=0xeb ata1: stat1=0x00 err=0x01 lsb=0x14 msb=0xeb ata1: reset tp2 stat0=10 stat1=00 devices=0x30000 pass0 at ata0 bus 0 scbus0 target 0 lun 0 pass0: ATA-8 device pass0: Serial Number WD-WCAV2F115406 pass0: 100.000MB/s transfers (UDMA5, PIO 8192bytes) pass1 at ata0 bus 0 scbus0 target 1 lun 0 pass1: ATA-5 device pass1: Serial Number WD-WMA8F2128712 pass1: 100.000MB/s transfers (UDMA5, PIO 8192bytes) pass2 at ata1 bus 0 scbus1 target 0 lun 0 pass2: Removable CD-ROM SCSI-0 device pass2: 33.300MB/s transfers (UDMA2, ATAPI 12bytes, PIO 65534bytes) pass3 at ata1 bus 0 scbus1 target 1 lun 0 pass3: Removable CD-ROM SCSI-0 device pass3: 33.300MB/s transfers (UDMA2, ATAPI 12bytes, PIO 65534bytes) ada0 at ata0 bus 0 scbus0 target 0 lun 0 ada0: ATA-8 device ada0: Serial Number WD-WCAV2F115406 ada0: 100.000MB/s transfers (UDMA5, PIO 8192bytes) ada0: 305245MB (625142448 512 byte sectors: 16H 63S/T 16383C) ada0: Previously was known as ad0 ada1 at ata0 bus 0 scbus0 target 1 lun 0 ada1: ATA-5 device ada1: Serial Number WD-WMA8F2128712 ada1: 100.000MB/s transfers (UDMA5, PIO 8192bytes) ada1: 57220MB (117187500 512 byte sectors: 16H 63S/T 16383C) ada1: Previously was known as ad1 TSC timecounter discards lower 1 bit(s) Timecounter "TSC-low" frequency 1196039246 Hz quality 800 uhub0: 2 ports with 2 removable, self powered uhub1: 2 ports with 2 removable, self powered uhub2: 2 ports with 2 removable, self powered GEOM: new disk cd0 GEOM: new disk cd1 GEOM: new disk ada0 GEOM: new disk ada1 uhub3: 6 ports with 6 removable, self powered ugen0.2: at usbus0 ums0: on usbus0 ums0: 3 buttons and [XYZ] coordinates ID=0 ata1: reset tp1 mask=03 ostat0=d0 ostat1=50 ata1: stat0=0x10 err=0x01 lsb=0x14 msb=0xeb ata1: stat1=0x10 err=0x01 lsb=0x14 msb=0xeb ata1: reset tp2 stat0=10 stat1=10 devices=0x30000 (cd0:ata1:0:0:0): got CAM status 0x50 (cd0:ata1:0:0:0): fatal error, failed to attach to device (cd0:ata1:0:0:0): lost device, 4 refs Opened disk cd0 -> 6 (cd0:ata1:0:0:0): removing device entry ata1: reset tp1 mask=03 ostat0=50 ostat1=d0 ata1: stat0=0x10 err=0x01 lsb=0x14 msb=0xeb ata1: stat1=0x10 err=0x01 lsb=0x14 msb=0xeb ata1: reset tp2 stat0=10 stat1=10 devices=0x30000 (cd1:ata1:0:1:0): got CAM status 0x50 (cd1:ata1:0:1:0): fatal error, failed to attach to device (cd1:ata1:0:1:0): lost device, 4 refs Opened disk cd1 -> 6 (cd1:ata1:0:1:0): removing device entry Trying to mount root from ufs:/dev/ada0s3a [rw]... start_init: trying /sbin/init procfs registered Linux ELF exec handler installed nfslock: pseudo-device --------------080201020409000902080309-- From owner-freebsd-current@FreeBSD.ORG Fri Feb 22 09:28:07 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 25B201D9; Fri, 22 Feb 2013 09:28:07 +0000 (UTC) (envelope-from cnst++@freebsd.org) Received: from Cns.Cns.SU (unknown [IPv6:2001:470:7240::]) by mx1.freebsd.org (Postfix) with ESMTP id A382B16E; Fri, 22 Feb 2013 09:28:06 +0000 (UTC) Received: from Cns.Cns.SU (cnst@localhost [127.0.0.1]) by Cns.Cns.SU (8.14.5/8.14.5) with ESMTP id r1M9S5cH012694; Fri, 22 Feb 2013 01:28:05 -0800 (PST) Received: (from cnst@localhost) by Cns.Cns.SU (8.14.5/8.14.5/Submit) id r1M9S5XC002558; Fri, 22 Feb 2013 01:28:05 -0800 (PST) X-Authentication-Warning: Cns.Cns.SU: cnst set sender to cnst++@freebsd.org using -f Date: Fri, 22 Feb 2013 01:28:05 -0800 From: "Constantine A. Murenin" To: Paul Schenkeveld Subject: Re: announcing mdoc.su, short manual page URLs Message-ID: <20130222092805.GA19524@Cns.Cns.SU> References: <20130219082700.GA9938@Cns.Cns.SU> <20130220143720.GA4368@psconsult.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <20130220143720.GA4368@psconsult.nl> User-Agent: Mutt/1.5.21 (2010-09-15) X-Mailman-Approved-At: Fri, 22 Feb 2013 12:27:02 +0000 Cc: freebsd-doc@freebsd.org, freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 09:28:07 -0000 On 2013-W08-3 15:37 +0100, Paul Schenkeveld wrote: > On Tue, Feb 19, 2013 at 12:27:01AM -0800, Constantine A. Murenin wrote: > > Dear freebsd-{chat,current,doc}@, > > > > I would like to announce and introduce , > > a deterministic URL shortener for BSD manual pages, > > written entirely in nginx.conf. > > > > It supports several address schemes, for example: > > > > http://mdoc.su/f/zfs > > http://mdoc.su/f/zfs.8 > > http://mdoc.su/f/8/zfs > > http://mdoc.su/freebsd/zfs > > http://mdoc.su/FreeBSD/zfs > > > > http://mdoc.su/d/hammer.5 > > http://mdoc.su/d/hammer.8 > > > > etc. > > Very coooool! > > One question: is the os version accessible comewhere, i.e. can I ask for > a manpage from a specific version of FreeBSD? I have added OS version support today: http://mdoc.su/f91/aibs.4 http://mdoc.su/FreeBSD-9.1/aibs.4 http://mdoc.su/FreeBSD-8.1/acpi_aiboost.4 :-) OpenBSD and NetBSD versions are also supported (as mentioned, DragonFly doesn't provide versioned man-pages through web-man, so, it's always been supported). Through the long notation, any possible release should be supported, including point releases like 5.2.1, 4.6.2, 4.1.1, 2.2.8 etc (subject to man.cgi support, of course), and long releases like 4.11. Through the short "/f" notation, only versions from 4.0 to a futuristic 19.9 are supported (except for point releases and versions like 4.10 and 4.11). Still written completely in nginx.conf. :-) The FreeBSD portion is now: location ^~ /FreeBSD { rewrite "^/FreeBSD([ -/].*)?$" /freebsd$1 last; return 404; } location ^~ /f { set $fb "http://www.freebsd.org/cgi/man.cgi?query="; set $fs "&sektion="; rewrite ^/f([4-9]|1[0-9])([0-9])(/.*)?$ /freebsd-$1.$2$3; rewrite "^/freebsd[ -/](?[0-9]+(\.[0-9]+)+)(/.*)?$" /.$3; if ($fp) { set $fp "&manpath=FreeBSD+$fp-RELEASE"; } rewrite ^/freebsd(/.*)?$ /.$1; rewrite ^/./([^/.]+)/([^/]+)$ $fb$2$fs$1$fp redirect; rewrite ^/./([^/]+)\.([1-9])$ $fb$1$fs$2$fp redirect; rewrite ^/./([^/]+)$ $fb$1$fs$fp redirect; rewrite ^/./?$ / last; return 410; } Enjoy! Best regards, Constantine. > > I have to disagree with Darren Pilgrim however, this is not "slight abuse" > of rewrite rules but putting rewrite rules to "better use" :-) > > Kind regards, > > Paul Schenkeveld From owner-freebsd-current@FreeBSD.ORG Fri Feb 22 12:46:05 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 62876F0 for ; Fri, 22 Feb 2013 12:46:05 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:131:60a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id 0F674C3D for ; Fri, 22 Feb 2013 12:46:05 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:509e:5349:4e7a:bf0a]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPA id 619E64AC57; Fri, 22 Feb 2013 16:46:03 +0400 (MSK) Date: Fri, 22 Feb 2013 16:45:58 +0400 From: Lev Serebryakov Organization: FreeBSD X-Priority: 3 (Normal) Message-ID: <1812992178.20130222164558@serebryakov.spb.ru> To: Daniel Nebdal Subject: Re: r245741 (clang as cc) can not build binaries for GEODE processor In-Reply-To: References: <108875110.20130222104603@serebryakov.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: lev@FreeBSD.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 12:46:05 -0000 Hello, Daniel. You wrote 22 =D1=84=D0=B5=D0=B2=D1=80=D0=B0=D0=BB=D1=8F 2013 =D0=B3., 16:04= :11: DN> I'm not familiar with NanoBSD, but does it do the package builds for DN> you - or do you do those by hand? DN> If it's the latter, I don't quite understand how the compiler is DN> supposed to know the target CPUTYPE? It is latter, but IMHO, _without_ any CPUTYPE set, system compiler should generate generic enough binaries to run on all supported CPUs of target platform (i386 in this case). --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-current@FreeBSD.ORG Fri Feb 22 13:33:52 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 8C744BDB; Fri, 22 Feb 2013 13:33:52 +0000 (UTC) (envelope-from patfbsd@davenulle.org) Received: from smtp.lamaiziere.net (net.lamaiziere.net [94.23.254.147]) by mx1.freebsd.org (Postfix) with ESMTP id 59BC2F99; Fri, 22 Feb 2013 13:33:51 +0000 (UTC) Received: from mr129166.localdomain (mr129166.cri.univ-rennes1.fr [129.20.129.166]) by smtp.lamaiziere.net (Postfix) with ESMTPA id E2A52AD2B; Fri, 22 Feb 2013 14:26:23 +0100 (CET) Received: from mr129166 (localhost [127.0.0.1]) by mr129166.localdomain (Postfix) with ESMTP id 7FA6060B7; Fri, 22 Feb 2013 14:26:23 +0100 (CET) Date: Fri, 22 Feb 2013 14:26:23 +0100 From: Patrick Lamaiziere To: freebsd-current@freebsd.org Subject: Re: r245741 (clang as cc) can not build binaries for GEODE processor Message-ID: <20130222142623.389445fe@mr129166> In-Reply-To: <1812992178.20130222164558@serebryakov.spb.ru> References: <108875110.20130222104603@serebryakov.spb.ru> <1812992178.20130222164558@serebryakov.spb.ru> X-Mailer: Claws Mail 3.9.0 (GTK+ 2.24.6; amd64-portbld-freebsd9.1) Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Cc: lev@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 13:33:52 -0000 Le Fri, 22 Feb 2013 16:45:58 +0400, Lev Serebryakov a écrit : Hello, > Hello, Daniel. > You wrote 22 Ñ„ÐµÐ²Ñ€Ð°Ð»Ñ 2013 г., 16:04:11: > > DN> I'm not familiar with NanoBSD, but does it do the package builds > DN> for you - or do you do those by hand? > DN> If it's the latter, I don't quite understand how the compiler is > DN> supposed to know the target CPUTYPE? > It is latter, but IMHO, _without_ any CPUTYPE set, system compiler > should generate generic enough binaries to run on all supported CPUs > of target platform (i386 in this case). Clang should work now if march=geode (see: http://llvm.org/bugs/show_bug.cgi?id=11212 ) But I agree that by default on i386, the code should work on i386... Looks like this is not true anymore (>= i686 ?). Regards. From owner-freebsd-current@FreeBSD.ORG Fri Feb 22 14:21:52 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 16113AC6; Fri, 22 Feb 2013 14:21:52 +0000 (UTC) (envelope-from dimitry@andric.com) Received: from tensor.andric.com (tensor.andric.com [IPv6:2001:7b8:3a7:1:2d0:b7ff:fea0:8c26]) by mx1.freebsd.org (Postfix) with ESMTP id D0BC229F; Fri, 22 Feb 2013 14:21:51 +0000 (UTC) Received: from [192.168.0.6] (spaceball.home.andric.com [192.168.0.6]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 871B15C43; Fri, 22 Feb 2013 15:21:47 +0100 (CET) Message-ID: <51277EFE.4000703@andric.com> Date: Fri, 22 Feb 2013 15:21:50 +0100 From: Dimitry Andric User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:19.0) Gecko/20130117 Thunderbird/19.0 MIME-Version: 1.0 To: lev@FreeBSD.org, freebsd-current Subject: Re: r245741 (clang as cc) can not build binaries for GEODE processor References: <108875110.20130222104603@serebryakov.spb.ru> In-Reply-To: <108875110.20130222104603@serebryakov.spb.ru> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 14:21:52 -0000 On 2013-02-22 07:46, Lev Serebryakov wrote: > I have -CURRENT i386 installation which runs r245741 now. > Default compiler is clang: > >> cc --version > FreeBSD clang version 3.2 (tags/RELEASE_32/final 170710) 20121221 > Target: i386-unknown-freebsd10.0 > Thread model: posix > > This system is used to build NanoBSD images (and ports for these > images) for my home router, which has AMD Geode CPU: > > Geode(TM) Integrated Processor by AMD PCS (499.91-MHz 586-class CPU) > > Build system has only one setting in /etc/src.conf and > /etc/make.conf: > > MALLOC_PRODUCTION=yes > > NanoBSD image build includes many options, and "CPUTYPE=geode" is > among them. > > Today I've rebuilt all ports (including samba36) and image (from > r247117). And new samba port (samba36-3.6.12) failed to start on > target system (with Geode CPU). It gets "SIGILL" (!!!). > > I was able to get core file by running "testparam" in NFS-mounted > R/W file system, but after that GDB (on build system, as NanoBSD > image doesn't contain one) says, that it could not access memory at > failure address to show disassembly: > >> gdb /usr/local/bin/testparm ~/testparm.core > GNU gdb 6.1.1 [FreeBSD] > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you are > welcome to change it and/or distribute copies of it under certain conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for details. > This GDB was configured as "i386-marcel-freebsd"...(no debugging symbols found)... > Core was generated by `testparm'. > Program terminated with signal 4, Illegal instruction. > #0 0x010351d6 in ?? () > (gdb) x/i $pc > 0x10351d6: Cannot access memory at address 0x10351d6 > (gdb) bt > #0 0x010351d6 in ?? () > #1 0x00000000 in ?? () > (gdb) As far as I know, Geodes should now work properly, after the long nops were disabled for it. But it could be that there are still some instructions generated that are not understood by the Geode. The default for FreeBSD on 32-bit x86 is i486, so maybe the problems are caused by the -march=geode setting. If you disable that, do the problems disappear? In any case, can you attempt to figure out which exact instructions it dies on? If gdb does not work, like you said above, maybe you can use objdump to disassemble the executable in question, and find the address of the failing instruction. -Dimitry From owner-freebsd-current@FreeBSD.ORG Fri Feb 22 14:23:16 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id F1056CD4; Fri, 22 Feb 2013 14:23:16 +0000 (UTC) (envelope-from dimitry@andric.com) Received: from tensor.andric.com (tensor.andric.com [IPv6:2001:7b8:3a7:1:2d0:b7ff:fea0:8c26]) by mx1.freebsd.org (Postfix) with ESMTP id B5D362C2; Fri, 22 Feb 2013 14:23:16 +0000 (UTC) Received: from [192.168.0.6] (spaceball.home.andric.com [192.168.0.6]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id F13775C43; Fri, 22 Feb 2013 15:23:15 +0100 (CET) Message-ID: <51277F57.5010202@andric.com> Date: Fri, 22 Feb 2013 15:23:19 +0100 From: Dimitry Andric User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:19.0) Gecko/20130117 Thunderbird/19.0 MIME-Version: 1.0 To: Patrick Lamaiziere , freebsd-current@freebsd.org Subject: Re: r245741 (clang as cc) can not build binaries for GEODE processor References: <108875110.20130222104603@serebryakov.spb.ru> <1812992178.20130222164558@serebryakov.spb.ru> <20130222142623.389445fe@mr129166> In-Reply-To: <20130222142623.389445fe@mr129166> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: lev@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 14:23:17 -0000 On 2013-02-22 14:26, Patrick Lamaiziere wrote: ... > Clang should work now if march=geode (see: > http://llvm.org/bugs/show_bug.cgi?id=11212 ) > > But I agree that by default on i386, the code should work on > i386... Looks like this is not true anymore (>= i686 ?). The default is -march=i486, just like with gcc. -Dimitry From owner-freebsd-current@FreeBSD.ORG Fri Feb 22 15:46:19 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id B1A3911F for ; Fri, 22 Feb 2013 15:46:19 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [46.4.40.135]) by mx1.freebsd.org (Postfix) with ESMTP id 5A82587B for ; Fri, 22 Feb 2013 15:46:19 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:509e:5349:4e7a:bf0a]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPA id 8E1894AC57; Fri, 22 Feb 2013 19:46:16 +0400 (MSK) Date: Fri, 22 Feb 2013 19:46:10 +0400 From: Lev Serebryakov Organization: FreeBSD X-Priority: 3 (Normal) Message-ID: <1079015997.20130222194610@serebryakov.spb.ru> To: Patrick Lamaiziere Subject: Re: r245741 (clang as cc) can not build binaries for GEODE processor In-Reply-To: <20130222142623.389445fe@mr129166> References: <108875110.20130222104603@serebryakov.spb.ru> <1812992178.20130222164558@serebryakov.spb.ru> <20130222142623.389445fe@mr129166> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: lev@FreeBSD.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 15:46:19 -0000 Hello, Patrick. You wrote 22 =D1=84=D0=B5=D0=B2=D1=80=D0=B0=D0=BB=D1=8F 2013 =D0=B3., 17:26= :23: >> It is latter, but IMHO, _without_ any CPUTYPE set, system compiler >> should generate generic enough binaries to run on all supported CPUs >> of target platform (i386 in this case). PL> Clang should work now if march=3Dgeode (see: PL> http://llvm.org/bugs/show_bug.cgi?id=3D11212 ) It is why SYSTEM, which is built with this option, works. But ports, built for "generic i386" doesn't :( PL> But I agree that by default on i386, the code should work on PL> i386... Looks like this is not true anymore (>=3D i686 ?). geode is fully i586 compatible, AFAIK, so yes, it looks like >=3D i686 :( --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-current@FreeBSD.ORG Fri Feb 22 15:50:01 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id A26D4252 for ; Fri, 22 Feb 2013 15:50:01 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [46.4.40.135]) by mx1.freebsd.org (Postfix) with ESMTP id 69CBE8A8 for ; Fri, 22 Feb 2013 15:50:01 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:509e:5349:4e7a:bf0a]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPA id D049C4AC59; Fri, 22 Feb 2013 19:49:59 +0400 (MSK) Date: Fri, 22 Feb 2013 19:49:54 +0400 From: Lev Serebryakov Organization: FreeBSD X-Priority: 3 (Normal) Message-ID: <15917508.20130222194954@serebryakov.spb.ru> To: Dimitry Andric Subject: Re: r245741 (clang as cc) can not build binaries for GEODE processor In-Reply-To: <51277EFE.4000703@andric.com> References: <108875110.20130222104603@serebryakov.spb.ru> <51277EFE.4000703@andric.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: lev@FreeBSD.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 15:50:01 -0000 Hello, Dimitry. You wrote 22 =D1=84=D0=B5=D0=B2=D1=80=D0=B0=D0=BB=D1=8F 2013 =D0=B3., 18:21= :50: DA> The default for FreeBSD on 32-bit x86 is i486, so maybe the problems are DA> caused by the -march=3Dgeode setting. If you disable that, do the DA> problems disappear? Problem is, that code compiled with "-march=3Dgeode" works. Code built without any "-march" at all (without CPUTYPE in configs) doesn't. It looks like clang or use "build system" CPU as default "-march" or issue some >=3D i686 commands without it. Or both :) DA> In any case, can you attempt to figure out which exact instructions it DA> dies on? If gdb does not work, like you said above, maybe you can use DA> objdump to disassemble the executable in question, and find the address DA> of the failing instruction. I'm trying to do this with very last sources both as build system and target sources. --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-current@FreeBSD.ORG Fri Feb 22 16:14:49 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 7A5FD731; Fri, 22 Feb 2013 16:14:49 +0000 (UTC) (envelope-from dimitry@andric.com) Received: from tensor.andric.com (tensor.andric.com [IPv6:2001:7b8:3a7:1:2d0:b7ff:fea0:8c26]) by mx1.freebsd.org (Postfix) with ESMTP id 25EB29D6; Fri, 22 Feb 2013 16:14:48 +0000 (UTC) Received: from [192.168.0.6] (spaceball.home.andric.com [192.168.0.6]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id A79CB5C43; Fri, 22 Feb 2013 17:14:47 +0100 (CET) Message-ID: <5127997A.2000901@andric.com> Date: Fri, 22 Feb 2013 17:14:50 +0100 From: Dimitry Andric User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:19.0) Gecko/20130117 Thunderbird/19.0 MIME-Version: 1.0 To: lev@FreeBSD.org Subject: Re: r245741 (clang as cc) can not build binaries for GEODE processor References: <108875110.20130222104603@serebryakov.spb.ru> <51277EFE.4000703@andric.com> <15917508.20130222194954@serebryakov.spb.ru> In-Reply-To: <15917508.20130222194954@serebryakov.spb.ru> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Cc: freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 16:14:49 -0000 On 2013-02-22 16:49, Lev Serebryakov wrote: > You wrote 22 =D1=84=D0=B5=D0=B2=D1=80=D0=B0=D0=BB=D1=8F 2013 =D0=B3., 1= 8:21:50: > > DA> The default for FreeBSD on 32-bit x86 is i486, so maybe the problem= s are > DA> caused by the -march=3Dgeode setting. If you disable that, do the > DA> problems disappear? > Problem is, that code compiled with "-march=3Dgeode" works. Cod= e > built without any "-march" at all (without CPUTYPE in configs) doesn't.= > It looks like clang or use "build system" CPU as default "-march" or= > issue some >=3D i686 commands without it. Or both :) Clang defaults to i486 (that is, on i386-unknown-freebsdXX arch), unless you specify -march=3D or -mcpu=3D on the command line. Maybe samba, or any of its dependencies, attempts to be "smart", and enables some custom CPU optimizations? > DA> In any case, can you attempt to figure out which exact instructions= it > DA> dies on? If gdb does not work, like you said above, maybe you can = use > DA> objdump to disassemble the executable in question, and find the add= ress > DA> of the failing instruction. > I'm trying to do this with very last sources both as build system= > and target sources. As Joerg Sonnenberger mentioned to me, the address 0x10351d6 you show in the gdb session seems to be quite high, possibly pointing to some shared library. Maybe you can try to figure out which library it is? -Dimitry From owner-freebsd-current@FreeBSD.ORG Fri Feb 22 16:35:53 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id EEEADBA9 for ; Fri, 22 Feb 2013 16:35:53 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:131:60a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id B292EA95 for ; Fri, 22 Feb 2013 16:35:53 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:509e:5349:4e7a:bf0a]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPA id 121F04AC58; Fri, 22 Feb 2013 20:35:51 +0400 (MSK) Date: Fri, 22 Feb 2013 20:35:46 +0400 From: Lev Serebryakov Organization: FreeBSD X-Priority: 3 (Normal) Message-ID: <562473731.20130222203546@serebryakov.spb.ru> To: Dimitry Andric Subject: Re: r245741 (clang as cc) can not build binaries for GEODE processor In-Reply-To: <5127997A.2000901@andric.com> References: <108875110.20130222104603@serebryakov.spb.ru> <51277EFE.4000703@andric.com> <15917508.20130222194954@serebryakov.spb.ru> <5127997A.2000901@andric.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: lev@FreeBSD.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 16:35:54 -0000 Hello, Dimitry. You wrote 22 =D1=84=D0=B5=D0=B2=D1=80=D0=B0=D0=BB=D1=8F 2013 =D0=B3., 20:14= :50: DA> Maybe samba, or any of its dependencies, attempts to be "smart", and DA> enables some custom CPU optimizations? Maybe. I'll investigate this one too. >> DA> In any case, can you attempt to figure out which exact instructions = it >> DA> dies on? If gdb does not work, like you said above, maybe you can u= se >> DA> objdump to disassemble the executable in question, and find the addr= ess >> DA> of the failing instruction. >> I'm trying to do this with very last sources both as build system >> and target sources. DA> As Joerg Sonnenberger mentioned to me, the address 0x10351d6 you show in DA> the gdb session seems to be quite high, possibly pointing to some shared DA> library. Maybe you can try to figure out which library it is? I don't like "bt" result with only two lines in high addresses. I'm rebuilding NanoBSD image with enabled gdb now to run "testconf" under gdb itself. --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-current@FreeBSD.ORG Fri Feb 22 17:49:27 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 51CE1E29; Fri, 22 Feb 2013 17:49:27 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-la0-x22b.google.com (la-in-x022b.1e100.net [IPv6:2a00:1450:4010:c03::22b]) by mx1.freebsd.org (Postfix) with ESMTP id A2189E7B; Fri, 22 Feb 2013 17:49:26 +0000 (UTC) Received: by mail-la0-f43.google.com with SMTP id ek20so869706lab.2 for ; Fri, 22 Feb 2013 09:49:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=pzfQte1N6oRTf9UsZht0aDDDx4+AG2z5ghdrA/Gj/6A=; b=tUc7QTp1PUxcbQAZCspxqIuoLcAxjUWQBLUhRNwWjKjnXt6z6owcXLtobE7OmiHlNJ pOo4N0AyjavpP5UyO8gsWCRp1P4+MCA1dziMov27jQfYgJ0xjGs9gOfzNZSQcwoPriRk H1mO4P8JR+NSiSHAkJ5jKX37rNS4ImTviMdpuIIRY5umzY5x50O2uAIeCZE/tAZz8IuP QBygUZyvELU6X44IgAX2e0WPPpl/vqmmCqqaXmuK9JNHIG+4ZOdnA0z43F91uWbnxM6Y GfzlciuCqzAd2XEYrU3+kOttwBl3NTN90oxVa3ZMrEaP2pbhFn+LIysDXj+gzni4+xFE 8Huw== X-Received: by 10.112.46.6 with SMTP id r6mr920832lbm.58.1361555364829; Fri, 22 Feb 2013 09:49:24 -0800 (PST) Received: from mavbook.mavhome.dp.ua (mavhome.mavhome.dp.ua. [213.227.240.37]) by mx.google.com with ESMTPS id e9sm1141837lbz.1.2013.02.22.09.49.22 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 22 Feb 2013 09:49:23 -0800 (PST) Sender: Alexander Motin Message-ID: <5127AFA0.4000008@FreeBSD.org> Date: Fri, 22 Feb 2013 19:49:20 +0200 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130125 Thunderbird/17.0.2 MIME-Version: 1.0 To: Joel Dahl Subject: Re: HEAD memsticks broken? [USB/CAM Problems?] References: <20130209073241.GN21730@jd.benders.se> <20130209230939.GQ21730@jd.benders.se> <20130211222105.GC838@jd.benders.se> <201302120851.18810.hselasky@c2i.net> <20130214193707.GD84888@jd.benders.se> <20130216100719.GB47553@jd.benders.se> <5124EF38.7080302@FreeBSD.org> In-Reply-To: <5124EF38.7080302@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, Hans Petter Selasky X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 17:49:27 -0000 On 20.02.2013 17:43, Alexander Motin wrote: > On 16.02.2013 12:07, Joel Dahl wrote: >> On 14-02-2013 20:37, Joel Dahl wrote: >>> On 12-02-2013 8:51, Hans Petter Selasky wrote: >>>> On Monday 11 February 2013 23:21:05 Joel Dahl wrote: >>>>> On 10-02-2013 0:09, Joel Dahl wrote: >>>>>> On 09-02-2013 20:28, Alexander Motin wrote: >>>>>>> How long ago that HEAD was built? Could you get full dmesg? I don't >>>>>>> think that "PREVENT ALLOW MEDIUM REMOVAL" should cause device drop. "No >>>>>>> sense data present" also doesn't look right. >>>>>> >>>>>> As I mentioned earlier, I've tried several HEAD snapshots. >>>>> >>>>> Just a quick update on this: I've built quite a few releases now and >>>>> managed to track down the problem to somewhere between r235789 and >>>>> r237855. It'll probably take me another day or two before I know which >>>>> commit actually broke it. >>>> >>>> Hi, >>>> >>>> I don't see any relevant USB+UMASS patches for your issue in this interval, >>>> but many patches in the SCSI/CAM area. >>> >>> I finally found it. A r237477 memstick boots fine. A r237478 memstick does not. >>> >>> 237478 is the following commit by mav@: >>> >>> ------------------------------------------------------------------------ >>> r237478 | mav | 2012-06-23 14:32:53 +0200 (Sat, 23 Jun 2012) | 3 lines >>> >>> Add scsi_extract_sense_ccb() -- wrapper around scsi_extract_sense_len(). >>> It allows to remove number of duplicate checks from several places. >>> >>> ------------------------------------------------------------------------ >> >> So, mav@ haven't replied yet so I did some more investigation. I collected >> all the USB sticks I had in the office (5 in total, all Kingston but different >> size and models) and tried a memstick installation with each stick. Turns out >> r237478 only breaks memstick installation in combination with certain USB >> sticks: >> >> # Works: >> >> da0: Removable Direct Access SCSI-2 device >> da0: 40.000MB/s transfers >> da0: 7664MB (15695872 512 byte sectors: 255H 63S/T 977C) >> >> da0: Removable Direct Access SCSI-0 device >> da0: 40.000MB/s transfers >> da0: 1906MB (3903488 512 byte sectors: 255H 63S/T 242C) >> >> # Does not work: >> >> da0: Removable Direct Access SCSI-2 device >> da0: 40.000MB/s transfers >> da0: 15295MB (31324160 512 byte sectors: 255H 63S/T 1949C) >> >> da0: Removable Direct Access SCSI-0 device >> da0: 40.000MB/s transfers >> da0: 3690MB (7557704 512 byte sectors: 255H 63S/T 470C) >> >> da0: Removable Direct Access SCSI-2 device >> da0: 40.000MB/s transfers >> da0: 1905MB (3903264 512 byte sectors: 255H 63S/T 242C) >> >> It seems that only USB sticks labeled as "Kingston DataTraveler G3" >> are affected by r237478 (in my limited testing, at least). This particular >> model is what you get if you buy the cheapest Kingston model on the market >> right now. > > I've reviewed that change once more and I see no flaws in it. My only > guess is that it changes something innocent or unrelated in request > order that confuses flash firmware, making it stuck and return errors > without SCSI sense information. In log provided I see that when device > first detected, it normally reports its size. But later, possibly after > some command (SYNCHRONIZE CACHE?, PREVENT ALLOW MEDIUM REMOVAL?), it > starts to behave wrong. Wrong answer to another READ CAPACITY request > causes "got CAM status 0xXX" message and following device loss. > > Unfortunately I can't reproduce the problem. All USB sticks I have are > working fine without any problems with HEAD system. If I could, I would > try to log all commands sent to the stick to find one after which > problem begins. Commands could be logged either on CAM layer by running > `camcontrol debug -IPpc all` before plugging stick in and `camcontrol > debug off` after (you may want to do it in single-user mode or without > syslog running to avoid logging activity on other CAM disks), or > probably somehow on umass layer, or with usbdump on raw USB layer (in > last case some more knowledge will be needed to interpret result). I've analyzed the stick behavior on your system and got to conclusion that problem is not in mentioned revision r237478 itself. This revision fixes some points of too relaxed checks for sense data. At r237477, when umass reported error on PREVENT ALLOW MEDIUM REMOVAL command, it also falsely reported sense data presence. That command was sent by daprevent(), trying to lock the "tray" of the "removable" device. Because of relaxed check, it handled those fake responses as successful completion, and tried to unlock "tray" on device close. That unlock command somehow restored device consciousness and made it to work further. After r237478 the error is no longer hidden, and unlock command is not sent (because lock command has failed). After that, both SYNCHRONIZE CACHE(10) and READ CAPACITY(10) commands return only errors. While SYNCHRONIZE CACHE(10) errors are not significant, errors on READ CAPACITY(10) cause device destruction. Experiment shown that enabling DA_Q_NO_PREVENT quirk for this stick fixes all the problems. I've committed it to HEAD on r247154. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Fri Feb 22 17:56:50 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id B7C2E164; Fri, 22 Feb 2013 17:56:50 +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 78035ED7; Fri, 22 Feb 2013 17:56:50 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r1MHuiAa078809; Fri, 22 Feb 2013 12:56:44 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r1MHuihw078805; Fri, 22 Feb 2013 17:56:44 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 22 Feb 2013 17:56:44 GMT Message-Id: <201302221756.r1MHuihw078805@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 , , Subject: [head tinderbox] failure on arm/arm Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 17:56:50 -0000 TB --- 2013-02-22 16:00:17 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-02-22 16:00:17 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-02-22 16:00:17 - starting HEAD tinderbox run for arm/arm TB --- 2013-02-22 16:00:17 - cleaning the object tree TB --- 2013-02-22 16:00:17 - /usr/local/bin/svn stat /src TB --- 2013-02-22 16:00:21 - At svn revision 247151 TB --- 2013-02-22 16:00:22 - building world TB --- 2013-02-22 16:00:22 - CROSS_BUILD_TESTING=YES TB --- 2013-02-22 16:00:22 - MAKEOBJDIRPREFIX=/obj TB --- 2013-02-22 16:00:22 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-02-22 16:00:22 - SRCCONF=/dev/null TB --- 2013-02-22 16:00:22 - TARGET=arm TB --- 2013-02-22 16:00:22 - TARGET_ARCH=arm TB --- 2013-02-22 16:00:22 - TZ=UTC TB --- 2013-02-22 16:00:22 - __MAKE_CONF=/dev/null TB --- 2013-02-22 16:00:22 - cd /src TB --- 2013-02-22 16:00:22 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Fri Feb 22 16:00:26 UTC 2013 >>> 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 Fri Feb 22 17:50:52 UTC 2013 TB --- 2013-02-22 17:50:52 - generating LINT kernel config TB --- 2013-02-22 17:50:52 - cd /src/sys/arm/conf TB --- 2013-02-22 17:50:52 - /usr/bin/make -B LINT TB --- 2013-02-22 17:50:52 - cd /src/sys/arm/conf TB --- 2013-02-22 17:50:52 - /usr/sbin/config -m LINT TB --- 2013-02-22 17:50:52 - building LINT kernel TB --- 2013-02-22 17:50:52 - CROSS_BUILD_TESTING=YES TB --- 2013-02-22 17:50:52 - MAKEOBJDIRPREFIX=/obj TB --- 2013-02-22 17:50:52 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-02-22 17:50:52 - SRCCONF=/dev/null TB --- 2013-02-22 17:50:52 - TARGET=arm TB --- 2013-02-22 17:50:52 - TARGET_ARCH=arm TB --- 2013-02-22 17:50:52 - TZ=UTC TB --- 2013-02-22 17:50:52 - __MAKE_CONF=/dev/null TB --- 2013-02-22 17:50:52 - cd /src TB --- 2013-02-22 17:50:52 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Fri Feb 22 17:50:52 UTC 2013 >>> 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 [...] ld -b binary --no-warn-mismatch -d -warn-common -r -o mw88W8363.fwo mw88W8363.fw uudecode -o mwlboot.fw /src/sys/contrib/dev/mwl/mwlboot.fw.uu ld -b binary --no-warn-mismatch -d -warn-common -r -o mwlboot.fwo mwlboot.fw 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 -fdiagnostics-show-option -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 -fno-builtin -mno-thumb-interwork -ffreestanding -Werror /src/sys/dev/mxge/if_mxge.c /src/sys/dev/mxge/if_mxge.c: In function 'mxge_rx_csum': /src/sys/dev/mxge/if_mxge.c:2571: error: 'cap' undeclared (first use in this function) /src/sys/dev/mxge/if_mxge.c:2571: error: (Each undeclared identifier is reported only once /src/sys/dev/mxge/if_mxge.c:2571: error: for each function it appears in.) *** [if_mxge.o] Error code 1 Stop in /obj/arm.arm/src/sys/LINT. *** [buildkernel] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-02-22 17:56:44 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-02-22 17:56:44 - ERROR: failed to build LINT kernel TB --- 2013-02-22 17:56:44 - 5575.86 user 979.06 system 6986.90 real http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-arm-arm.full From owner-freebsd-current@FreeBSD.ORG Fri Feb 22 17:59:20 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id E1EB4409 for ; Fri, 22 Feb 2013 17:59:20 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from adsum.doit.wisc.edu (adsum.doit.wisc.edu [144.92.197.210]) by mx1.freebsd.org (Postfix) with ESMTP id BDA02F10 for ; Fri, 22 Feb 2013 17:59:20 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from avs-daemon.smtpauth1.wiscmail.wisc.edu by smtpauth1.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 7u2-7.05 32bit (built Jul 30 2009)) id <0MIM00B00SG7KQ00@smtpauth1.wiscmail.wisc.edu> for freebsd-current@freebsd.org; Fri, 22 Feb 2013 10:59:13 -0600 (CST) X-Spam-PmxInfo: Server=avs-1, Version=5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.2.22.164815, SenderIP=0.0.0.0 X-Spam-Report: AuthenticatedSender=yes, SenderIP=0.0.0.0 Received: from terminus.icecube.wisc.edu (i3-user-nat.icecube.wisc.edu [128.104.255.12]) by smtpauth1.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 7u2-7.05 32bit (built Jul 30 2009)) with ESMTPSA id <0MIM00FZESIN3K50@smtpauth1.wiscmail.wisc.edu> for freebsd-current@freebsd.org; Fri, 22 Feb 2013 10:59:11 -0600 (CST) X-Wisc-Sender: whitehorn@wisc.edu Message-id: <5127A3DF.3060304@freebsd.org> Date: Fri, 22 Feb 2013 10:59:11 -0600 From: Nathan Whitehorn User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130218 Thunderbird/17.0.2 To: freebsd-current@freebsd.org Subject: Re: DVD/CD lost after r246713 References: <51265A58.4010600@orange.fr> <20130222082145.GJ2598@kib.kiev.ua> <51275FC7.9010906@orange.fr> In-reply-to: <51275FC7.9010906@orange.fr> X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 17:59:20 -0000 On 02/22/13 06:08, Claude Buisson wrote: > On 02/22/2013 09:21, Konstantin Belousov wrote: > > > >> You need to provide the dmesg from r246713 and r246712 to compare. >> The note that r246711 snapshot exhibited this same problem makes >> me sceptical. > > Here are the verbose dmesg from r246712 and r246713; > > For the sceptical: > > root@fidel# cd /usr/src > root@fidel# grep "\$FreeBSD\:" sys/conf/files > # $FreeBSD: head/sys/conf/files 246586 2013-02-09 06:39:28Z delphij $ > root@fidel# grep "\$FreeBSD\:" sys/ia64/ia64/dump_machdep.c > __FBSDID("$FreeBSD: head/sys/ia64/ia64/dump_machdep.c 246712 2013-02-12 > 16:51:43Z marcel $"); > > for r246712 > > root@fidel# cd /usr/src > root@fidel# grep "\$FreeBSD\:" sys/conf/files > # $FreeBSD: head/sys/conf/files 246713 2013-02-12 16:57:20Z kib $ > root@fidel# grep "\$FreeBSD\:" sys/ia64/include/proc.h > * $FreeBSD: head/sys/ia64/include/proc.h 226112 2011-10-07 16:09:44Z > kib $ > > for r246713 > > The source is from svn0.us-east.freebsd.org > > And obj/ has been rm'ed before each buildkernel > > My own conclusion is that the rev number in: > > FreeBSD-10.0-HEAD-r246711-JPSNAP-i386-i386-memstick.img > > is bogus, and this can be easily checked by grepping for > kern/subr_bus_dma.c in > the BUILD.log as this file has been ADDED by r246713 > > CBu (working on this since Tuesday) For whatever it is worth, I have experienced the identical problem on an amd64 system. -Nathan From owner-freebsd-current@FreeBSD.ORG Fri Feb 22 19:03:04 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 460F5C9A; Fri, 22 Feb 2013 19:03:04 +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 1C854306; Fri, 22 Feb 2013 19:03:03 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r1MJ32wf064838; Fri, 22 Feb 2013 14:03:02 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r1MJ32qW064835; Fri, 22 Feb 2013 19:03:02 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 22 Feb 2013 19:03:02 GMT Message-Id: <201302221903.r1MJ32qW064835@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 , , Subject: [head tinderbox] failure on i386/i386 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 19:03:04 -0000 TB --- 2013-02-22 16:00:17 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-02-22 16:00:17 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-02-22 16:00:17 - starting HEAD tinderbox run for i386/i386 TB --- 2013-02-22 16:00:17 - cleaning the object tree TB --- 2013-02-22 16:07:51 - /usr/local/bin/svn stat /src TB --- 2013-02-22 16:07:55 - At svn revision 247151 TB --- 2013-02-22 16:07:56 - building world TB --- 2013-02-22 16:07:56 - CROSS_BUILD_TESTING=YES TB --- 2013-02-22 16:07:56 - MAKEOBJDIRPREFIX=/obj TB --- 2013-02-22 16:07:56 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-02-22 16:07:56 - SRCCONF=/dev/null TB --- 2013-02-22 16:07:56 - TARGET=i386 TB --- 2013-02-22 16:07:56 - TARGET_ARCH=i386 TB --- 2013-02-22 16:07:56 - TZ=UTC TB --- 2013-02-22 16:07:56 - __MAKE_CONF=/dev/null TB --- 2013-02-22 16:07:56 - cd /src TB --- 2013-02-22 16:07:56 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Fri Feb 22 16:08:00 UTC 2013 >>> 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 Fri Feb 22 18:52:34 UTC 2013 TB --- 2013-02-22 18:52:34 - generating LINT kernel config TB --- 2013-02-22 18:52:34 - cd /src/sys/i386/conf TB --- 2013-02-22 18:52:34 - /usr/bin/make -B LINT TB --- 2013-02-22 18:52:34 - cd /src/sys/i386/conf TB --- 2013-02-22 18:52:34 - /usr/sbin/config -m LINT TB --- 2013-02-22 18:52:34 - building LINT kernel TB --- 2013-02-22 18:52:34 - CROSS_BUILD_TESTING=YES TB --- 2013-02-22 18:52:34 - MAKEOBJDIRPREFIX=/obj TB --- 2013-02-22 18:52:34 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-02-22 18:52:34 - SRCCONF=/dev/null TB --- 2013-02-22 18:52:34 - TARGET=i386 TB --- 2013-02-22 18:52:34 - TARGET_ARCH=i386 TB --- 2013-02-22 18:52:34 - TZ=UTC TB --- 2013-02-22 18:52:34 - __MAKE_CONF=/dev/null TB --- 2013-02-22 18:52:34 - cd /src TB --- 2013-02-22 18:52:34 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Fri Feb 22 18:52:34 UTC 2013 >>> 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 -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -DGPROF -DGPROF4 -DGUPROF -fno-builtin -mno-aes -mno-avx -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -Werror -pg /src/sys/dev/mxge/if_mxge.c /src/sys/dev/mxge/if_mxge.c:2571:8: error: use of undeclared identifier 'cap' if ((cap & IFCAP_RXCSUM) == 0) ^ /src/sys/dev/mxge/if_mxge.c:2584:8: error: use of undeclared identifier 'cap' if ((cap & IFCAP_RXCSUM_IPV6) == 0) ^ 2 errors generated. *** [if_mxge.o] Error code 1 Stop in /obj/i386.i386/src/sys/LINT. *** [buildkernel] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-02-22 19:03:02 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-02-22 19:03:02 - ERROR: failed to build LINT kernel TB --- 2013-02-22 19:03:02 - 8466.45 user 1313.45 system 10964.89 real http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Fri Feb 22 19:36:04 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 50E66D54; Fri, 22 Feb 2013 19:36:04 +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 1FFBB771; Fri, 22 Feb 2013 19:36:03 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r1MJa3CT058807; Fri, 22 Feb 2013 14:36:03 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r1MJa3aU058803; Fri, 22 Feb 2013 19:36:03 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 22 Feb 2013 19:36:03 GMT Message-Id: <201302221936.r1MJa3aU058803@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 , , Subject: [head tinderbox] failure on amd64/amd64 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 19:36:04 -0000 TB --- 2013-02-22 16:00:17 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-02-22 16:00:17 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-02-22 16:00:17 - starting HEAD tinderbox run for amd64/amd64 TB --- 2013-02-22 16:00:17 - cleaning the object tree TB --- 2013-02-22 16:08:12 - /usr/local/bin/svn stat /src TB --- 2013-02-22 16:08:15 - At svn revision 247151 TB --- 2013-02-22 16:08:16 - building world TB --- 2013-02-22 16:08:16 - CROSS_BUILD_TESTING=YES TB --- 2013-02-22 16:08:16 - MAKEOBJDIRPREFIX=/obj TB --- 2013-02-22 16:08:16 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-02-22 16:08:16 - SRCCONF=/dev/null TB --- 2013-02-22 16:08:16 - TARGET=amd64 TB --- 2013-02-22 16:08:16 - TARGET_ARCH=amd64 TB --- 2013-02-22 16:08:16 - TZ=UTC TB --- 2013-02-22 16:08:16 - __MAKE_CONF=/dev/null TB --- 2013-02-22 16:08:16 - cd /src TB --- 2013-02-22 16:08:16 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Fri Feb 22 16:08:21 UTC 2013 >>> 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 Fri Feb 22 19:25:55 UTC 2013 TB --- 2013-02-22 19:25:55 - generating LINT kernel config TB --- 2013-02-22 19:25:55 - cd /src/sys/amd64/conf TB --- 2013-02-22 19:25:55 - /usr/bin/make -B LINT TB --- 2013-02-22 19:25:55 - cd /src/sys/amd64/conf TB --- 2013-02-22 19:25:55 - /usr/sbin/config -m LINT TB --- 2013-02-22 19:25:55 - building LINT kernel TB --- 2013-02-22 19:25:55 - CROSS_BUILD_TESTING=YES TB --- 2013-02-22 19:25:55 - MAKEOBJDIRPREFIX=/obj TB --- 2013-02-22 19:25:55 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-02-22 19:25:55 - SRCCONF=/dev/null TB --- 2013-02-22 19:25:55 - TARGET=amd64 TB --- 2013-02-22 19:25:55 - TARGET_ARCH=amd64 TB --- 2013-02-22 19:25:55 - TZ=UTC TB --- 2013-02-22 19:25:55 - __MAKE_CONF=/dev/null TB --- 2013-02-22 19:25:55 - cd /src TB --- 2013-02-22 19:25:55 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Fri Feb 22 19:25:55 UTC 2013 >>> 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 -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -DGPROF -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mno-aes -mno-avx -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg /src/sys/dev/mxge/if_mxge.c /src/sys/dev/mxge/if_mxge.c:2571:8: error: use of undeclared identifier 'cap' if ((cap & IFCAP_RXCSUM) == 0) ^ /src/sys/dev/mxge/if_mxge.c:2584:8: error: use of undeclared identifier 'cap' if ((cap & IFCAP_RXCSUM_IPV6) == 0) ^ 2 errors generated. *** [if_mxge.o] Error code 1 Stop in /obj/amd64.amd64/src/sys/LINT. *** [buildkernel] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-02-22 19:36:03 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-02-22 19:36:03 - ERROR: failed to build LINT kernel TB --- 2013-02-22 19:36:03 - 9804.58 user 1704.75 system 12945.73 real http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-amd64-amd64.full From owner-freebsd-current@FreeBSD.ORG Fri Feb 22 19:51:04 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id DC34E1A4; Fri, 22 Feb 2013 19:51:04 +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 AD8A7813; Fri, 22 Feb 2013 19:51:04 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r1MJp39X052912; Fri, 22 Feb 2013 14:51:03 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r1MJp3c9052906; Fri, 22 Feb 2013 19:51:03 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 22 Feb 2013 19:51:03 GMT Message-Id: <201302221951.r1MJp3c9052906@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 , , Subject: [head tinderbox] failure on ia64/ia64 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 19:51:04 -0000 TB --- 2013-02-22 18:08:51 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-02-22 18:08:51 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-02-22 18:08:51 - starting HEAD tinderbox run for ia64/ia64 TB --- 2013-02-22 18:08:51 - cleaning the object tree TB --- 2013-02-22 18:08:51 - /usr/local/bin/svn stat /src TB --- 2013-02-22 18:08:54 - At svn revision 247151 TB --- 2013-02-22 18:08:55 - building world TB --- 2013-02-22 18:08:55 - CROSS_BUILD_TESTING=YES TB --- 2013-02-22 18:08:55 - MAKEOBJDIRPREFIX=/obj TB --- 2013-02-22 18:08:55 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-02-22 18:08:55 - SRCCONF=/dev/null TB --- 2013-02-22 18:08:55 - TARGET=ia64 TB --- 2013-02-22 18:08:55 - TARGET_ARCH=ia64 TB --- 2013-02-22 18:08:55 - TZ=UTC TB --- 2013-02-22 18:08:55 - __MAKE_CONF=/dev/null TB --- 2013-02-22 18:08:55 - cd /src TB --- 2013-02-22 18:08:55 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Fri Feb 22 18:09:00 UTC 2013 >>> 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 Fri Feb 22 19:42:25 UTC 2013 TB --- 2013-02-22 19:42:25 - generating LINT kernel config TB --- 2013-02-22 19:42:25 - cd /src/sys/ia64/conf TB --- 2013-02-22 19:42:25 - /usr/bin/make -B LINT TB --- 2013-02-22 19:42:25 - cd /src/sys/ia64/conf TB --- 2013-02-22 19:42:25 - /usr/sbin/config -m LINT TB --- 2013-02-22 19:42:25 - building LINT kernel TB --- 2013-02-22 19:42:25 - CROSS_BUILD_TESTING=YES TB --- 2013-02-22 19:42:25 - MAKEOBJDIRPREFIX=/obj TB --- 2013-02-22 19:42:25 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-02-22 19:42:25 - SRCCONF=/dev/null TB --- 2013-02-22 19:42:25 - TARGET=ia64 TB --- 2013-02-22 19:42:25 - TARGET_ARCH=ia64 TB --- 2013-02-22 19:42:25 - TZ=UTC TB --- 2013-02-22 19:42:25 - __MAKE_CONF=/dev/null TB --- 2013-02-22 19:42:25 - cd /src TB --- 2013-02-22 19:42:25 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Fri Feb 22 19:42:25 UTC 2013 >>> 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 [...] ld -b binary --no-warn-mismatch -d -warn-common -r -o mw88W8363.fwo mw88W8363.fw uudecode -o mwlboot.fw /src/sys/contrib/dev/mwl/mwlboot.fw.uu ld -b binary --no-warn-mismatch -d -warn-common -r -o mwlboot.fwo mwlboot.fw 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 -fdiagnostics-show-option -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/mxge/if_mxge.c /src/sys/dev/mxge/if_mxge.c: In function 'mxge_rx_csum': /src/sys/dev/mxge/if_mxge.c:2571: error: 'cap' undeclared (first use in this function) /src/sys/dev/mxge/if_mxge.c:2571: error: (Each undeclared identifier is reported only once /src/sys/dev/mxge/if_mxge.c:2571: error: for each function it appears in.) *** [if_mxge.o] Error code 1 Stop in /obj/ia64.ia64/src/sys/LINT. *** [buildkernel] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-02-22 19:51:03 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-02-22 19:51:03 - ERROR: failed to build LINT kernel TB --- 2013-02-22 19:51:03 - 4842.81 user 954.81 system 6132.13 real http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Fri Feb 22 19:52:09 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 69181343 for ; Fri, 22 Feb 2013 19:52:09 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:131:60a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id 2E2A4839 for ; Fri, 22 Feb 2013 19:52:09 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:509e:5349:4e7a:bf0a]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPA id C2F4E4AC58; Fri, 22 Feb 2013 23:52:06 +0400 (MSK) Date: Fri, 22 Feb 2013 23:52:01 +0400 From: Lev Serebryakov Organization: FreeBSD X-Priority: 3 (Normal) Message-ID: <1084146495.20130222235201@serebryakov.spb.ru> To: Dimitry Andric Subject: Re: r245741 (clang as cc) can not build binaries for GEODE processor In-Reply-To: <5127997A.2000901@andric.com> References: <108875110.20130222104603@serebryakov.spb.ru> <51277EFE.4000703@andric.com> <15917508.20130222194954@serebryakov.spb.ru> <5127997A.2000901@andric.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: lev@FreeBSD.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 19:52:09 -0000 Hello, Dimitry. You wrote 22 =D1=84=D0=B5=D0=B2=D1=80=D0=B0=D0=BB=D1=8F 2013 =D0=B3., 20:14= :50: DA> Maybe samba, or any of its dependencies, attempts to be "smart", and DA> enables some custom CPU optimizations? I've rebuild everything (build system, ports & image) from r247144 (for system sources), and now EVERY port crashes with SIGILL. I have gdb, but it shows nonsense like this on crash: Program received signal SIGILL, Illegal instruction. [Switching to Thread 28c03080 (LWP 100079/mpd5)] 0x0804c899 in ?? () (gdb) bt #0 0x0804c899 in ?? () #1 0xbfbfdbe0 in ?? () #2 0xbfbfdbfc in ?? () #3 0x00000000 in ?? () (gdb) Note addresses like 0xbfbfdbfc, I don't belive, that it is true address. --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-current@FreeBSD.ORG Fri Feb 22 19:57:49 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 71EC279F for ; Fri, 22 Feb 2013 19:57:49 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:131:60a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id 2CEC1889 for ; Fri, 22 Feb 2013 19:57:49 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:509e:5349:4e7a:bf0a]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPA id E92F14AC57; Fri, 22 Feb 2013 23:57:47 +0400 (MSK) Date: Fri, 22 Feb 2013 23:57:42 +0400 From: Lev Serebryakov Organization: FreeBSD X-Priority: 3 (Normal) Message-ID: <781694121.20130222235742@serebryakov.spb.ru> To: Dimitry Andric Subject: Re: r245741 (clang as cc) can not build binaries for GEODE processor In-Reply-To: <5127997A.2000901@andric.com> References: <108875110.20130222104603@serebryakov.spb.ru> <51277EFE.4000703@andric.com> <15917508.20130222194954@serebryakov.spb.ru> <5127997A.2000901@andric.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: lev@FreeBSD.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 19:57:49 -0000 Hello, Dimitry. You wrote 22 =D1=84=D0=B5=D0=B2=D1=80=D0=B0=D0=BB=D1=8F 2013 =D0=B3., 20:14= :50: DA> As Joerg Sonnenberger mentioned to me, the address 0x10351d6 you show in DA> the gdb session seems to be quite high, possibly pointing to some shared DA> library. Maybe you can try to figure out which library it is? Ok, very simple "hello, world!" program crashes too! And I have debug symbols for it ;-) Program terminated with signal 4, Illegal instruction. Reading symbols from /lib/libc.so.7...done. Loaded symbols for /lib/libc.so.7 Reading symbols from /libexec/ld-elf.so.1...done. Loaded symbols for /libexec/ld-elf.so.1 #0 0x080483e9 in _start1 () (gdb) where #0 0x080483e9 in _start1 () #1 0x08048398 in _start () #2 0x00000000 in ?? () (gdb) x/i $pc 0x80483e9 <_start1+73>: nopl 0x0(%eax) (gdb) This program was built with: cc -O99 -g -o test test.c cc --version FreeBSD clang version 3.2 (tags/RELEASE_32/final 170710) 20121221 Target: i386-unknown-freebsd10.0 Thread model: posix test.c could consist of empty main() function. So, by default clang from r247144 still (or again?) has problems with long NOPs. --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-current@FreeBSD.ORG Fri Feb 22 20:14:53 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id A780FA7F for ; Fri, 22 Feb 2013 20:14:53 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [46.4.40.135]) by mx1.freebsd.org (Postfix) with ESMTP id 54F3E91F for ; Fri, 22 Feb 2013 20:14:52 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:509e:5349:4e7a:bf0a]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPA id EBC564AC57; Sat, 23 Feb 2013 00:14:50 +0400 (MSK) Date: Sat, 23 Feb 2013 00:14:45 +0400 From: Lev Serebryakov Organization: FreeBSD X-Priority: 3 (Normal) Message-ID: <386635586.20130223001445@serebryakov.spb.ru> To: Dimitry Andric Subject: Re: r245741 (clang as cc) can not build binaries for GEODE processor In-Reply-To: <5127997A.2000901@andric.com> References: <108875110.20130222104603@serebryakov.spb.ru> <51277EFE.4000703@andric.com> <15917508.20130222194954@serebryakov.spb.ru> <5127997A.2000901@andric.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: lev@FreeBSD.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 20:14:53 -0000 Hello, Dimitry. You wrote 22 =D1=84=D0=B5=D0=B2=D1=80=D0=B0=D0=BB=D1=8F 2013 =D0=B3., 20:14= :50: DA> As Joerg Sonnenberger mentioned to me, the address 0x10351d6 you show in DA> the gdb session seems to be quite high, possibly pointing to some shared DA> library. Maybe you can try to figure out which library it is? Here is two long NOPs in output of clang in -CURRENT without "-march" options: objdump -d test 080483a0 <_start1>: ... 80483e8: 40 inc %eax 80483e9: 0f 1f 80 00 00 00 00 nopl 0x0(%eax) 80483f0: 8a 08 mov (%eax),%cl ... 8048496: 31 ff xor %edi,%edi 8048498: 0f 1f 84 00 00 00 00 nopl 0x0(%eax,%eax,1) 804849f: 00=20 80484a0: 8b 04 bd 68 96 04 08 mov 0x8049668(,%edi,4),%eax --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-current@FreeBSD.ORG Fri Feb 22 20:31:58 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 4AA04EC for ; Fri, 22 Feb 2013 20:31:58 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:131:60a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id 663379CF for ; Fri, 22 Feb 2013 20:31:57 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:509e:5349:4e7a:bf0a]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPA id 93EF34AC57; Sat, 23 Feb 2013 00:31:55 +0400 (MSK) Date: Sat, 23 Feb 2013 00:31:50 +0400 From: Lev Serebryakov Organization: FreeBSD X-Priority: 3 (Normal) Message-ID: <136287724.20130223003150@serebryakov.spb.ru> To: Dimitry Andric , freebsd-current Subject: Re: r245741 (clang as cc) can not build binaries for GEODE processor In-Reply-To: <386635586.20130223001445@serebryakov.spb.ru> References: <108875110.20130222104603@serebryakov.spb.ru> <51277EFE.4000703@andric.com> <15917508.20130222194954@serebryakov.spb.ru> <5127997A.2000901@andric.com> <386635586.20130223001445@serebryakov.spb.ru> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----------02B01613E319E0BA9" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: lev@FreeBSD.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 20:31:58 -0000 ------------02B01613E319E0BA9 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello, Lev. You wrote 23 =D1=84=D0=B5=D0=B2=D1=80=D0=B0=D0=BB=D1=8F 2013 =D0=B3., 0:14:= 45: LS> Hello, Dimitry. LS> You wrote 22 =D1=84=D0=B5=D0=B2=D1=80=D0=B0=D0=BB=D1=8F 2013 =D0=B3., 2= 0:14:50: DA>> As Joerg Sonnenberger mentioned to me, the address 0x10351d6 you show = in DA>> the gdb session seems to be quite high, possibly pointing to some shar= ed DA>> library. Maybe you can try to figure out which library it is? LS> Here is two long NOPs in output of clang in -CURRENT without "-march" LS> options: LS> objdump -d test LS> 080483a0 <_start1>: LS> ... LS> 80483e8: 40 inc %eax LS> 80483e9: 0f 1f 80 00 00 00 00 nopl 0x0(%eax) LS> 80483f0: 8a 08 mov (%eax),%cl LS> ... LS> 8048496: 31 ff xor %edi,%edi LS> 8048498: 0f 1f 84 00 00 00 00 nopl 0x0(%eax,%eax,1) LS> 804849f: 00=20 LS> 80484a0: 8b 04 bd 68 96 04 08 mov 0x8049668(,%edi,4),%eax And sample code is EXACTLY THE SAME with "-march=3Dgeode" and crashes the same! I'm puzzled, why system binaries works in such case!? But disassembly of system binaries (for example, /usr/bin/who) doesn't contains "nopl" at all! I've attached disassembly of "start1" form: (a) unstripped "who" command built in "make buildworld" stage with CPUTYPE=3Dgeode set. (b) unstripped "Hello world" program, built with simple "cc -o test \ test.c" (contains "nopl") (c) unstripped "Hello world" program, built with simple "cc \ -march=3Dgeode -o test.geode test.c" (contains "nopl" too!) Oh, I see... "start1" is linked from startup code like crt0.o, am I right? So, rebuilding only ports with "CPUTYPE=3Dgeode" will not help! But, in any case, it seems to be bug in clang to generate such instructions in "default" case. --=20 // Black Lion AKA Lev Serebryakov ------------02B01613E319E0BA9 Content-Type: text/plain; name="test.geode.s" Content-transfer-encoding: base64 Content-Disposition: attachment; filename="test.geode.s" MDgwNDgzYTAgPF9zdGFydDE+OgogODA0ODNhMDoJNTUgICAgICAgICAgICAgICAgICAgCXB1 c2ggICAlZWJwCiA4MDQ4M2ExOgk4OSBlNSAgICAgICAgICAgICAgICAJbW92ICAgICVlc3As JWVicAogODA0ODNhMzoJNTMgICAgICAgICAgICAgICAgICAgCXB1c2ggICAlZWJ4CiA4MDQ4 M2E0Ogk1NyAgICAgICAgICAgICAgICAgICAJcHVzaCAgICVlZGkKIDgwNDgzYTU6CTU2ICAg ICAgICAgICAgICAgICAgIAlwdXNoICAgJWVzaQogODA0ODNhNjoJODMgZWMgMTAgICAgICAg ICAgICAgCXN1YiAgICAkMHgxMCwlZXNwCiA4MDQ4M2E5Ogk4YiA0NSAwYyAgICAgICAgICAg ICAJbW92ICAgIDB4YyglZWJwKSwlZWF4CiA4MDQ4M2FjOgk4YiA1ZCAxMCAgICAgICAgICAg ICAJbW92ICAgIDB4MTAoJWVicCksJWVieAogODA0ODNhZjoJOGQgNDQgODMgMDQgICAgICAg ICAgCWxlYSAgICAweDQoJWVieCwlZWF4LDQpLCVlYXgKIDgwNDgzYjM6CTgxIDNkIDYwIDk3 IDA0IDA4IDAwIAljbXBsICAgJDB4MCwweDgwNDk3NjAKIDgwNDgzYmE6CTAwIDAwIDAwIAog ODA0ODNiZDoJNzUgMDUgICAgICAgICAgICAgICAgCWpuZSAgICA4MDQ4M2M0IDxfc3RhcnQx KzB4MjQ+CiA4MDQ4M2JmOglhMyA2MCA5NyAwNCAwOCAgICAgICAJbW92ICAgICVlYXgsMHg4 MDQ5NzYwCiA4MDQ4M2M0Ogk4OSA0NSBmMCAgICAgICAgICAgICAJbW92ICAgICVlYXgsLTB4 MTAoJWVicCkKIDgwNDgzYzc6CTgzIDdkIDBjIDAwICAgICAgICAgIAljbXBsICAgJDB4MCww eGMoJWVicCkKIDgwNDgzY2I6CTdlIDJlICAgICAgICAgICAgICAgIAlqbGUgICAgODA0ODNm YiA8X3N0YXJ0MSsweDViPgogODA0ODNjZDoJOGIgMDMgICAgICAgICAgICAgICAgCW1vdiAg ICAoJWVieCksJWVheAogODA0ODNjZjoJODUgYzAgICAgICAgICAgICAgICAgCXRlc3QgICAl ZWF4LCVlYXgKIDgwNDgzZDE6CTc0IDI4ICAgICAgICAgICAgICAgIAlqZSAgICAgODA0ODNm YiA8X3N0YXJ0MSsweDViPgogODA0ODNkMzoJZWIgMGMgICAgICAgICAgICAgICAgCWptcCAg ICA4MDQ4M2UxIDxfc3RhcnQxKzB4NDE+CiA4MDQ4M2Q1Ogk2NiA2NiAyZSAwZiAxZiA4NCAw MCAJbm9wdyAgICVjczoweDAoJWVheCwlZWF4LDEpCiA4MDQ4M2RjOgkwMCAwMCAwMCAwMCAK IDgwNDgzZTA6CTQwICAgICAgICAgICAgICAgICAgIAlpbmMgICAgJWVheAogODA0ODNlMToJ YTMgNTAgOTcgMDQgMDggICAgICAgCW1vdiAgICAlZWF4LDB4ODA0OTc1MAogODA0ODNlNjoJ ZWIgMDggICAgICAgICAgICAgICAgCWptcCAgICA4MDQ4M2YwIDxfc3RhcnQxKzB4NTA+CiA4 MDQ4M2U4Ogk0MCAgICAgICAgICAgICAgICAgICAJaW5jICAgICVlYXgKIDgwNDgzZTk6CTBm IDFmIDgwIDAwIDAwIDAwIDAwIAlub3BsICAgMHgwKCVlYXgpCiA4MDQ4M2YwOgk4YSAwOCAg ICAgICAgICAgICAgICAJbW92ICAgICglZWF4KSwlY2wKIDgwNDgzZjI6CTgwIGY5IDJmICAg ICAgICAgICAgIAljbXAgICAgJDB4MmYsJWNsCiA4MDQ4M2Y1Ogk3NCBlOSAgICAgICAgICAg ICAgICAJamUgICAgIDgwNDgzZTAgPF9zdGFydDErMHg0MD4KIDgwNDgzZjc6CTg0IGM5ICAg ICAgICAgICAgICAgIAl0ZXN0ICAgJWNsLCVjbAogODA0ODNmOToJNzUgZWQgICAgICAgICAg ICAgICAgCWpuZSAgICA4MDQ4M2U4IDxfc3RhcnQxKzB4NDg+CiA4MDQ4M2ZiOgliOCA3YyA5 NiAwNCAwOCAgICAgICAJbW92ICAgICQweDgwNDk2N2MsJWVheAogODA0ODQwMDoJODUgYzAg ICAgICAgICAgICAgICAgCXRlc3QgICAlZWF4LCVlYXgKIDgwNDg0MDI6CTc0IDBkICAgICAg ICAgICAgICAgIAlqZSAgICAgODA0ODQxMSA8X3N0YXJ0MSsweDcxPgogODA0ODQwNDoJOGIg NDUgMDggICAgICAgICAgICAgCW1vdiAgICAweDgoJWVicCksJWVheAogODA0ODQwNzoJODkg MDQgMjQgICAgICAgICAgICAgCW1vdiAgICAlZWF4LCglZXNwKQogODA0ODQwYToJZTggNDEg ZmYgZmYgZmYgICAgICAgCWNhbGwgICA4MDQ4MzUwIDxhdGV4aXRAcGx0PgogODA0ODQwZjoJ ZWIgMDUgICAgICAgICAgICAgICAgCWptcCAgICA4MDQ4NDE2IDxfc3RhcnQxKzB4NzY+CiA4 MDQ4NDExOgllOCA0YSBmZiBmZiBmZiAgICAgICAJY2FsbCAgIDgwNDgzNjAgPF9pbml0X3Rs c0BwbHQ+CiA4MDQ4NDE2OgliOCA3YyA5NiAwNCAwOCAgICAgICAJbW92ICAgICQweDgwNDk2 N2MsJWVheAogODA0ODQxYjoJODUgYzAgICAgICAgICAgICAgICAgCXRlc3QgICAlZWF4LCVl YXgKIDgwNDg0MWQ6CTBmIDg1IGExIDAwIDAwIDAwICAgIAlqbmUgICAgODA0ODRjNCA8X3N0 YXJ0MSsweDEyND4KIDgwNDg0MjM6CWM3IDA0IDI0IGYwIDg0IDA0IDA4IAltb3ZsICAgJDB4 ODA0ODRmMCwoJWVzcCkKIDgwNDg0MmE6CWI5IDY4IDk2IDA0IDA4ICAgICAgIAltb3YgICAg JDB4ODA0OTY2OCwlZWN4CiA4MDQ4NDJmOgliOCA2OCA5NiAwNCAwOCAgICAgICAJbW92ICAg ICQweDgwNDk2NjgsJWVheAogODA0ODQzNDoJMjkgYzggICAgICAgICAgICAgICAgCXN1YiAg ICAlZWN4LCVlYXgKIDgwNDg0MzY6CTg5IGM2ICAgICAgICAgICAgICAgIAltb3YgICAgJWVh eCwlZXNpCiA4MDQ4NDM4OgljMSBmZSAxZiAgICAgICAgICAgICAJc2FyICAgICQweDFmLCVl c2kKIDgwNDg0M2I6CWMxIGVlIDFlICAgICAgICAgICAgIAlzaHIgICAgJDB4MWUsJWVzaQog ODA0ODQzZToJMDEgYzYgICAgICAgICAgICAgICAgCWFkZCAgICAlZWF4LCVlc2kKIDgwNDg0 NDA6CWMxIGZlIDAyICAgICAgICAgICAgIAlzYXIgICAgJDB4MiwlZXNpCiA4MDQ4NDQzOgll OCAwOCBmZiBmZiBmZiAgICAgICAJY2FsbCAgIDgwNDgzNTAgPGF0ZXhpdEBwbHQ+CiA4MDQ4 NDQ4Ogk4NSBmNiAgICAgICAgICAgICAgICAJdGVzdCAgICVlc2ksJWVzaQogODA0ODQ0YToJ NzQgMjggICAgICAgICAgICAgICAgCWplICAgICA4MDQ4NDc0IDxfc3RhcnQxKzB4ZDQ+CiA4 MDQ4NDRjOgkzMSBmZiAgICAgICAgICAgICAgICAJeG9yICAgICVlZGksJWVkaQogODA0ODQ0 ZToJNjYgOTAgICAgICAgICAgICAgICAgCXhjaGcgICAlYXgsJWF4CiA4MDQ4NDUwOgk4YiAw NCBiZCA2OCA5NiAwNCAwOCAJbW92ICAgIDB4ODA0OTY2OCgsJWVkaSw0KSwlZWF4CiA4MDQ4 NDU3Ogk4MyBmOCAwMiAgICAgICAgICAgICAJY21wICAgICQweDIsJWVheAogODA0ODQ1YToJ NzIgMTMgICAgICAgICAgICAgICAgCWpiICAgICA4MDQ4NDZmIDxfc3RhcnQxKzB4Y2Y+CiA4 MDQ4NDVjOgk4YiA0ZCBmMCAgICAgICAgICAgICAJbW92ICAgIC0weDEwKCVlYnApLCVlY3gK IDgwNDg0NWY6CTg5IDRjIDI0IDA4ICAgICAgICAgIAltb3YgICAgJWVjeCwweDgoJWVzcCkK IDgwNDg0NjM6CTg5IDVjIDI0IDA0ICAgICAgICAgIAltb3YgICAgJWVieCwweDQoJWVzcCkK IDgwNDg0Njc6CThiIDRkIDBjICAgICAgICAgICAgIAltb3YgICAgMHhjKCVlYnApLCVlY3gK IDgwNDg0NmE6CTg5IDBjIDI0ICAgICAgICAgICAgIAltb3YgICAgJWVjeCwoJWVzcCkKIDgw NDg0NmQ6CWZmIGQwICAgICAgICAgICAgICAgIAljYWxsICAgKiVlYXgKIDgwNDg0NmY6CTQ3 ICAgICAgICAgICAgICAgICAgIAlpbmMgICAgJWVkaQogODA0ODQ3MDoJMzkgZjcgICAgICAg ICAgICAgICAgCWNtcCAgICAlZXNpLCVlZGkKIDgwNDg0NzI6CTcyIGRjICAgICAgICAgICAg ICAgIAlqYiAgICAgODA0ODQ1MCA8X3N0YXJ0MSsweGIwPgogODA0ODQ3NDoJYjkgNjggOTYg MDQgMDggICAgICAgCW1vdiAgICAkMHg4MDQ5NjY4LCVlY3gKIDgwNDg0Nzk6CWI4IDY4IDk2 IDA0IDA4ICAgICAgIAltb3YgICAgJDB4ODA0OTY2OCwlZWF4CiA4MDQ4NDdlOgkyOSBjOCAg ICAgICAgICAgICAgICAJc3ViICAgICVlY3gsJWVheAogODA0ODQ4MDoJODkgYzYgICAgICAg ICAgICAgICAgCW1vdiAgICAlZWF4LCVlc2kKIDgwNDg0ODI6CWMxIGZlIDFmICAgICAgICAg ICAgIAlzYXIgICAgJDB4MWYsJWVzaQogODA0ODQ4NToJYzEgZWUgMWUgICAgICAgICAgICAg CXNociAgICAkMHgxZSwlZXNpCiA4MDQ4NDg4OgkwMSBjNiAgICAgICAgICAgICAgICAJYWRk ICAgICVlYXgsJWVzaQogODA0ODQ4YToJYzEgZmUgMDIgICAgICAgICAgICAgCXNhciAgICAk MHgyLCVlc2kKIDgwNDg0OGQ6CWU4IDhhIGZlIGZmIGZmICAgICAgIAljYWxsICAgODA0ODMx YyA8X2luaXQ+CiA4MDQ4NDkyOgk4NSBmNiAgICAgICAgICAgICAgICAJdGVzdCAgICVlc2ks JWVzaQogODA0ODQ5NDoJNzQgMmUgICAgICAgICAgICAgICAgCWplICAgICA4MDQ4NGM0IDxf c3RhcnQxKzB4MTI0PgogODA0ODQ5NjoJMzEgZmYgICAgICAgICAgICAgICAgCXhvciAgICAl ZWRpLCVlZGkKIDgwNDg0OTg6CTBmIDFmIDg0IDAwIDAwIDAwIDAwIAlub3BsICAgMHgwKCVl YXgsJWVheCwxKQogODA0ODQ5ZjoJMDAgCiA4MDQ4NGEwOgk4YiAwNCBiZCA2OCA5NiAwNCAw OCAJbW92ICAgIDB4ODA0OTY2OCgsJWVkaSw0KSwlZWF4CiA4MDQ4NGE3Ogk4MyBmOCAwMiAg ICAgICAgICAgICAJY21wICAgICQweDIsJWVheAogODA0ODRhYToJNzIgMTMgICAgICAgICAg ICAgICAgCWpiICAgICA4MDQ4NGJmIDxfc3RhcnQxKzB4MTFmPgogODA0ODRhYzoJOGIgNGQg ZjAgICAgICAgICAgICAgCW1vdiAgICAtMHgxMCglZWJwKSwlZWN4CiA4MDQ4NGFmOgk4OSA0 YyAyNCAwOCAgICAgICAgICAJbW92ICAgICVlY3gsMHg4KCVlc3ApCiA4MDQ4NGIzOgk4OSA1 YyAyNCAwNCAgICAgICAgICAJbW92ICAgICVlYngsMHg0KCVlc3ApCiA4MDQ4NGI3Ogk4YiA0 ZCAwYyAgICAgICAgICAgICAJbW92ICAgIDB4YyglZWJwKSwlZWN4CiA4MDQ4NGJhOgk4OSAw YyAyNCAgICAgICAgICAgICAJbW92ICAgICVlY3gsKCVlc3ApCiA4MDQ4NGJkOglmZiBkMCAg ICAgICAgICAgICAgICAJY2FsbCAgIColZWF4CiA4MDQ4NGJmOgk0NyAgICAgICAgICAgICAg ICAgICAJaW5jICAgICVlZGkKIDgwNDg0YzA6CTM5IGY3ICAgICAgICAgICAgICAgIAljbXAg ICAgJWVzaSwlZWRpCiA4MDQ4NGMyOgk3MiBkYyAgICAgICAgICAgICAgICAJamIgICAgIDgw NDg0YTAgPF9zdGFydDErMHgxMDA+CiA4MDQ4NGM0Ogk4YiA0NSBmMCAgICAgICAgICAgICAJ bW92ICAgIC0weDEwKCVlYnApLCVlYXgKIDgwNDg0Yzc6CTg5IDQ0IDI0IDA4ICAgICAgICAg IAltb3YgICAgJWVheCwweDgoJWVzcCkKIDgwNDg0Y2I6CTg5IDVjIDI0IDA0ICAgICAgICAg IAltb3YgICAgJWVieCwweDQoJWVzcCkKIDgwNDg0Y2Y6CThiIDQ1IDBjICAgICAgICAgICAg IAltb3YgICAgMHhjKCVlYnApLCVlYXgKIDgwNDg0ZDI6CTg5IDA0IDI0ICAgICAgICAgICAg IAltb3YgICAgJWVheCwoJWVzcCkKIDgwNDg0ZDU6CWU4IGI2IDAwIDAwIDAwICAgICAgIAlj YWxsICAgODA0ODU5MCA8bWFpbj4KIDgwNDg0ZGE6CTg5IDA0IDI0ICAgICAgICAgICAgIAlt b3YgICAgJWVheCwoJWVzcCkKIDgwNDg0ZGQ6CWU4IDhlIGZlIGZmIGZmICAgICAgIAljYWxs ICAgODA0ODM3MCA8ZXhpdEBwbHQ+CiA4MDQ4NGUyOgk2NiA2NiA2NiA2NiA2NiAyZSAwZiAJ bm9wdyAgICVjczoweDAoJWVheCwlZWF4LDEpCiA4MDQ4NGU5OgkxZiA4NCAwMCAwMCAwMCAw MCAwMCAK ------------02B01613E319E0BA9 Content-Type: text/plain; name="test.s" Content-transfer-encoding: base64 Content-Disposition: attachment; filename="test.s" MDgwNDgzYTAgPF9zdGFydDE+OgogODA0ODNhMDoJNTUgICAgICAgICAgICAgICAgICAgCXB1 c2ggICAlZWJwCiA4MDQ4M2ExOgk4OSBlNSAgICAgICAgICAgICAgICAJbW92ICAgICVlc3As JWVicAogODA0ODNhMzoJNTMgICAgICAgICAgICAgICAgICAgCXB1c2ggICAlZWJ4CiA4MDQ4 M2E0Ogk1NyAgICAgICAgICAgICAgICAgICAJcHVzaCAgICVlZGkKIDgwNDgzYTU6CTU2ICAg ICAgICAgICAgICAgICAgIAlwdXNoICAgJWVzaQogODA0ODNhNjoJODMgZWMgMTAgICAgICAg ICAgICAgCXN1YiAgICAkMHgxMCwlZXNwCiA4MDQ4M2E5Ogk4YiA0NSAwYyAgICAgICAgICAg ICAJbW92ICAgIDB4YyglZWJwKSwlZWF4CiA4MDQ4M2FjOgk4YiA1ZCAxMCAgICAgICAgICAg ICAJbW92ICAgIDB4MTAoJWVicCksJWVieAogODA0ODNhZjoJOGQgNDQgODMgMDQgICAgICAg ICAgCWxlYSAgICAweDQoJWVieCwlZWF4LDQpLCVlYXgKIDgwNDgzYjM6CTgxIDNkIDYwIDk3 IDA0IDA4IDAwIAljbXBsICAgJDB4MCwweDgwNDk3NjAKIDgwNDgzYmE6CTAwIDAwIDAwIAog ODA0ODNiZDoJNzUgMDUgICAgICAgICAgICAgICAgCWpuZSAgICA4MDQ4M2M0IDxfc3RhcnQx KzB4MjQ+CiA4MDQ4M2JmOglhMyA2MCA5NyAwNCAwOCAgICAgICAJbW92ICAgICVlYXgsMHg4 MDQ5NzYwCiA4MDQ4M2M0Ogk4OSA0NSBmMCAgICAgICAgICAgICAJbW92ICAgICVlYXgsLTB4 MTAoJWVicCkKIDgwNDgzYzc6CTgzIDdkIDBjIDAwICAgICAgICAgIAljbXBsICAgJDB4MCww eGMoJWVicCkKIDgwNDgzY2I6CTdlIDJlICAgICAgICAgICAgICAgIAlqbGUgICAgODA0ODNm YiA8X3N0YXJ0MSsweDViPgogODA0ODNjZDoJOGIgMDMgICAgICAgICAgICAgICAgCW1vdiAg ICAoJWVieCksJWVheAogODA0ODNjZjoJODUgYzAgICAgICAgICAgICAgICAgCXRlc3QgICAl ZWF4LCVlYXgKIDgwNDgzZDE6CTc0IDI4ICAgICAgICAgICAgICAgIAlqZSAgICAgODA0ODNm YiA8X3N0YXJ0MSsweDViPgogODA0ODNkMzoJZWIgMGMgICAgICAgICAgICAgICAgCWptcCAg ICA4MDQ4M2UxIDxfc3RhcnQxKzB4NDE+CiA4MDQ4M2Q1Ogk2NiA2NiAyZSAwZiAxZiA4NCAw MCAJbm9wdyAgICVjczoweDAoJWVheCwlZWF4LDEpCiA4MDQ4M2RjOgkwMCAwMCAwMCAwMCAK IDgwNDgzZTA6CTQwICAgICAgICAgICAgICAgICAgIAlpbmMgICAgJWVheAogODA0ODNlMToJ YTMgNTAgOTcgMDQgMDggICAgICAgCW1vdiAgICAlZWF4LDB4ODA0OTc1MAogODA0ODNlNjoJ ZWIgMDggICAgICAgICAgICAgICAgCWptcCAgICA4MDQ4M2YwIDxfc3RhcnQxKzB4NTA+CiA4 MDQ4M2U4Ogk0MCAgICAgICAgICAgICAgICAgICAJaW5jICAgICVlYXgKIDgwNDgzZTk6CTBm IDFmIDgwIDAwIDAwIDAwIDAwIAlub3BsICAgMHgwKCVlYXgpCiA4MDQ4M2YwOgk4YSAwOCAg ICAgICAgICAgICAgICAJbW92ICAgICglZWF4KSwlY2wKIDgwNDgzZjI6CTgwIGY5IDJmICAg ICAgICAgICAgIAljbXAgICAgJDB4MmYsJWNsCiA4MDQ4M2Y1Ogk3NCBlOSAgICAgICAgICAg ICAgICAJamUgICAgIDgwNDgzZTAgPF9zdGFydDErMHg0MD4KIDgwNDgzZjc6CTg0IGM5ICAg ICAgICAgICAgICAgIAl0ZXN0ICAgJWNsLCVjbAogODA0ODNmOToJNzUgZWQgICAgICAgICAg ICAgICAgCWpuZSAgICA4MDQ4M2U4IDxfc3RhcnQxKzB4NDg+CiA4MDQ4M2ZiOgliOCA3YyA5 NiAwNCAwOCAgICAgICAJbW92ICAgICQweDgwNDk2N2MsJWVheAogODA0ODQwMDoJODUgYzAg ICAgICAgICAgICAgICAgCXRlc3QgICAlZWF4LCVlYXgKIDgwNDg0MDI6CTc0IDBkICAgICAg ICAgICAgICAgIAlqZSAgICAgODA0ODQxMSA8X3N0YXJ0MSsweDcxPgogODA0ODQwNDoJOGIg NDUgMDggICAgICAgICAgICAgCW1vdiAgICAweDgoJWVicCksJWVheAogODA0ODQwNzoJODkg MDQgMjQgICAgICAgICAgICAgCW1vdiAgICAlZWF4LCglZXNwKQogODA0ODQwYToJZTggNDEg ZmYgZmYgZmYgICAgICAgCWNhbGwgICA4MDQ4MzUwIDxhdGV4aXRAcGx0PgogODA0ODQwZjoJ ZWIgMDUgICAgICAgICAgICAgICAgCWptcCAgICA4MDQ4NDE2IDxfc3RhcnQxKzB4NzY+CiA4 MDQ4NDExOgllOCA0YSBmZiBmZiBmZiAgICAgICAJY2FsbCAgIDgwNDgzNjAgPF9pbml0X3Rs c0BwbHQ+CiA4MDQ4NDE2OgliOCA3YyA5NiAwNCAwOCAgICAgICAJbW92ICAgICQweDgwNDk2 N2MsJWVheAogODA0ODQxYjoJODUgYzAgICAgICAgICAgICAgICAgCXRlc3QgICAlZWF4LCVl YXgKIDgwNDg0MWQ6CTBmIDg1IGExIDAwIDAwIDAwICAgIAlqbmUgICAgODA0ODRjNCA8X3N0 YXJ0MSsweDEyND4KIDgwNDg0MjM6CWM3IDA0IDI0IGYwIDg0IDA0IDA4IAltb3ZsICAgJDB4 ODA0ODRmMCwoJWVzcCkKIDgwNDg0MmE6CWI5IDY4IDk2IDA0IDA4ICAgICAgIAltb3YgICAg JDB4ODA0OTY2OCwlZWN4CiA4MDQ4NDJmOgliOCA2OCA5NiAwNCAwOCAgICAgICAJbW92ICAg ICQweDgwNDk2NjgsJWVheAogODA0ODQzNDoJMjkgYzggICAgICAgICAgICAgICAgCXN1YiAg ICAlZWN4LCVlYXgKIDgwNDg0MzY6CTg5IGM2ICAgICAgICAgICAgICAgIAltb3YgICAgJWVh eCwlZXNpCiA4MDQ4NDM4OgljMSBmZSAxZiAgICAgICAgICAgICAJc2FyICAgICQweDFmLCVl c2kKIDgwNDg0M2I6CWMxIGVlIDFlICAgICAgICAgICAgIAlzaHIgICAgJDB4MWUsJWVzaQog ODA0ODQzZToJMDEgYzYgICAgICAgICAgICAgICAgCWFkZCAgICAlZWF4LCVlc2kKIDgwNDg0 NDA6CWMxIGZlIDAyICAgICAgICAgICAgIAlzYXIgICAgJDB4MiwlZXNpCiA4MDQ4NDQzOgll OCAwOCBmZiBmZiBmZiAgICAgICAJY2FsbCAgIDgwNDgzNTAgPGF0ZXhpdEBwbHQ+CiA4MDQ4 NDQ4Ogk4NSBmNiAgICAgICAgICAgICAgICAJdGVzdCAgICVlc2ksJWVzaQogODA0ODQ0YToJ NzQgMjggICAgICAgICAgICAgICAgCWplICAgICA4MDQ4NDc0IDxfc3RhcnQxKzB4ZDQ+CiA4 MDQ4NDRjOgkzMSBmZiAgICAgICAgICAgICAgICAJeG9yICAgICVlZGksJWVkaQogODA0ODQ0 ZToJNjYgOTAgICAgICAgICAgICAgICAgCXhjaGcgICAlYXgsJWF4CiA4MDQ4NDUwOgk4YiAw NCBiZCA2OCA5NiAwNCAwOCAJbW92ICAgIDB4ODA0OTY2OCgsJWVkaSw0KSwlZWF4CiA4MDQ4 NDU3Ogk4MyBmOCAwMiAgICAgICAgICAgICAJY21wICAgICQweDIsJWVheAogODA0ODQ1YToJ NzIgMTMgICAgICAgICAgICAgICAgCWpiICAgICA4MDQ4NDZmIDxfc3RhcnQxKzB4Y2Y+CiA4 MDQ4NDVjOgk4YiA0ZCBmMCAgICAgICAgICAgICAJbW92ICAgIC0weDEwKCVlYnApLCVlY3gK IDgwNDg0NWY6CTg5IDRjIDI0IDA4ICAgICAgICAgIAltb3YgICAgJWVjeCwweDgoJWVzcCkK IDgwNDg0NjM6CTg5IDVjIDI0IDA0ICAgICAgICAgIAltb3YgICAgJWVieCwweDQoJWVzcCkK IDgwNDg0Njc6CThiIDRkIDBjICAgICAgICAgICAgIAltb3YgICAgMHhjKCVlYnApLCVlY3gK IDgwNDg0NmE6CTg5IDBjIDI0ICAgICAgICAgICAgIAltb3YgICAgJWVjeCwoJWVzcCkKIDgw NDg0NmQ6CWZmIGQwICAgICAgICAgICAgICAgIAljYWxsICAgKiVlYXgKIDgwNDg0NmY6CTQ3 ICAgICAgICAgICAgICAgICAgIAlpbmMgICAgJWVkaQogODA0ODQ3MDoJMzkgZjcgICAgICAg ICAgICAgICAgCWNtcCAgICAlZXNpLCVlZGkKIDgwNDg0NzI6CTcyIGRjICAgICAgICAgICAg ICAgIAlqYiAgICAgODA0ODQ1MCA8X3N0YXJ0MSsweGIwPgogODA0ODQ3NDoJYjkgNjggOTYg MDQgMDggICAgICAgCW1vdiAgICAkMHg4MDQ5NjY4LCVlY3gKIDgwNDg0Nzk6CWI4IDY4IDk2 IDA0IDA4ICAgICAgIAltb3YgICAgJDB4ODA0OTY2OCwlZWF4CiA4MDQ4NDdlOgkyOSBjOCAg ICAgICAgICAgICAgICAJc3ViICAgICVlY3gsJWVheAogODA0ODQ4MDoJODkgYzYgICAgICAg ICAgICAgICAgCW1vdiAgICAlZWF4LCVlc2kKIDgwNDg0ODI6CWMxIGZlIDFmICAgICAgICAg ICAgIAlzYXIgICAgJDB4MWYsJWVzaQogODA0ODQ4NToJYzEgZWUgMWUgICAgICAgICAgICAg CXNociAgICAkMHgxZSwlZXNpCiA4MDQ4NDg4OgkwMSBjNiAgICAgICAgICAgICAgICAJYWRk ICAgICVlYXgsJWVzaQogODA0ODQ4YToJYzEgZmUgMDIgICAgICAgICAgICAgCXNhciAgICAk MHgyLCVlc2kKIDgwNDg0OGQ6CWU4IDhhIGZlIGZmIGZmICAgICAgIAljYWxsICAgODA0ODMx YyA8X2luaXQ+CiA4MDQ4NDkyOgk4NSBmNiAgICAgICAgICAgICAgICAJdGVzdCAgICVlc2ks JWVzaQogODA0ODQ5NDoJNzQgMmUgICAgICAgICAgICAgICAgCWplICAgICA4MDQ4NGM0IDxf c3RhcnQxKzB4MTI0PgogODA0ODQ5NjoJMzEgZmYgICAgICAgICAgICAgICAgCXhvciAgICAl ZWRpLCVlZGkKIDgwNDg0OTg6CTBmIDFmIDg0IDAwIDAwIDAwIDAwIAlub3BsICAgMHgwKCVl YXgsJWVheCwxKQogODA0ODQ5ZjoJMDAgCiA4MDQ4NGEwOgk4YiAwNCBiZCA2OCA5NiAwNCAw OCAJbW92ICAgIDB4ODA0OTY2OCgsJWVkaSw0KSwlZWF4CiA4MDQ4NGE3Ogk4MyBmOCAwMiAg ICAgICAgICAgICAJY21wICAgICQweDIsJWVheAogODA0ODRhYToJNzIgMTMgICAgICAgICAg ICAgICAgCWpiICAgICA4MDQ4NGJmIDxfc3RhcnQxKzB4MTFmPgogODA0ODRhYzoJOGIgNGQg ZjAgICAgICAgICAgICAgCW1vdiAgICAtMHgxMCglZWJwKSwlZWN4CiA4MDQ4NGFmOgk4OSA0 YyAyNCAwOCAgICAgICAgICAJbW92ICAgICVlY3gsMHg4KCVlc3ApCiA4MDQ4NGIzOgk4OSA1 YyAyNCAwNCAgICAgICAgICAJbW92ICAgICVlYngsMHg0KCVlc3ApCiA4MDQ4NGI3Ogk4YiA0 ZCAwYyAgICAgICAgICAgICAJbW92ICAgIDB4YyglZWJwKSwlZWN4CiA4MDQ4NGJhOgk4OSAw YyAyNCAgICAgICAgICAgICAJbW92ICAgICVlY3gsKCVlc3ApCiA4MDQ4NGJkOglmZiBkMCAg ICAgICAgICAgICAgICAJY2FsbCAgIColZWF4CiA4MDQ4NGJmOgk0NyAgICAgICAgICAgICAg ICAgICAJaW5jICAgICVlZGkKIDgwNDg0YzA6CTM5IGY3ICAgICAgICAgICAgICAgIAljbXAg ICAgJWVzaSwlZWRpCiA4MDQ4NGMyOgk3MiBkYyAgICAgICAgICAgICAgICAJamIgICAgIDgw NDg0YTAgPF9zdGFydDErMHgxMDA+CiA4MDQ4NGM0Ogk4YiA0NSBmMCAgICAgICAgICAgICAJ bW92ICAgIC0weDEwKCVlYnApLCVlYXgKIDgwNDg0Yzc6CTg5IDQ0IDI0IDA4ICAgICAgICAg IAltb3YgICAgJWVheCwweDgoJWVzcCkKIDgwNDg0Y2I6CTg5IDVjIDI0IDA0ICAgICAgICAg IAltb3YgICAgJWVieCwweDQoJWVzcCkKIDgwNDg0Y2Y6CThiIDQ1IDBjICAgICAgICAgICAg IAltb3YgICAgMHhjKCVlYnApLCVlYXgKIDgwNDg0ZDI6CTg5IDA0IDI0ICAgICAgICAgICAg IAltb3YgICAgJWVheCwoJWVzcCkKIDgwNDg0ZDU6CWU4IGI2IDAwIDAwIDAwICAgICAgIAlj YWxsICAgODA0ODU5MCA8bWFpbj4KIDgwNDg0ZGE6CTg5IDA0IDI0ICAgICAgICAgICAgIAlt b3YgICAgJWVheCwoJWVzcCkKIDgwNDg0ZGQ6CWU4IDhlIGZlIGZmIGZmICAgICAgIAljYWxs ICAgODA0ODM3MCA8ZXhpdEBwbHQ+CiA4MDQ4NGUyOgk2NiA2NiA2NiA2NiA2NiAyZSAwZiAJ bm9wdyAgICVjczoweDAoJWVheCwlZWF4LDEpCiA4MDQ4NGU5OgkxZiA4NCAwMCAwMCAwMCAw MCAwMCAK ------------02B01613E319E0BA9 Content-Type: text/plain; name="who.s" Content-transfer-encoding: base64 Content-Disposition: attachment; filename="who.s" MDgwNDhiMGMgPF9zdGFydDE+OgogODA0OGIwYzoJNTUgICAgICAgICAgICAgICAgICAgCXB1 c2ggICAlZWJwCiA4MDQ4YjBkOgk4OSBlNSAgICAgICAgICAgICAgICAJbW92ICAgICVlc3As JWVicAogODA0OGIwZjoJNTcgICAgICAgICAgICAgICAgICAgCXB1c2ggICAlZWRpCiA4MDQ4 YjEwOgk1NiAgICAgICAgICAgICAgICAgICAJcHVzaCAgICVlc2kKIDgwNDhiMTE6CTUzICAg ICAgICAgICAgICAgICAgIAlwdXNoICAgJWVieAogODA0OGIxMjoJODMgZWMgMWMgICAgICAg ICAgICAgCXN1YiAgICAkMHgxYywlZXNwCiA4MDQ4YjE1OglhMSAwOCBhYSAwNCAwOCAgICAg ICAJbW92ICAgIDB4ODA0YWEwOCwlZWF4CiA4MDQ4YjFhOgk4YiA3NSAwYyAgICAgICAgICAg ICAJbW92ICAgIDB4YyglZWJwKSwlZXNpCiA4MDQ4YjFkOgk4YiA3ZCAxMCAgICAgICAgICAg ICAJbW92ICAgIDB4MTAoJWVicCksJWVkaQogODA0OGIyMDoJODUgYzAgICAgICAgICAgICAg ICAgCXRlc3QgICAlZWF4LCVlYXgKIDgwNDhiMjI6CThkIDVjIGI3IDA0ICAgICAgICAgIAls ZWEgICAgMHg0KCVlZGksJWVzaSw0KSwlZWJ4CiA4MDQ4YjI2OglhMSAwOCBhYSAwNCAwOCAg ICAgICAJbW92ICAgIDB4ODA0YWEwOCwlZWF4CiA4MDQ4YjJiOgkwZiA0NCBjMyAgICAgICAg ICAgICAJY21vdmUgICVlYngsJWVheAogODA0OGIyZToJODUgZjYgICAgICAgICAgICAgICAg CXRlc3QgICAlZXNpLCVlc2kKIDgwNDhiMzA6CWEzIDA4IGFhIDA0IDA4ICAgICAgIAltb3Yg ICAgJWVheCwweDgwNGFhMDgKIDgwNDhiMzU6CTdlIDJiICAgICAgICAgICAgICAgIAlqbGUg ICAgODA0OGI2MiA8X3N0YXJ0MSsweDU2PgogODA0OGIzNzoJOGIgMTcgICAgICAgICAgICAg ICAgCW1vdiAgICAoJWVkaSksJWVkeAogODA0OGIzOToJODUgZDIgICAgICAgICAgICAgICAg CXRlc3QgICAlZWR4LCVlZHgKIDgwNDhiM2I6CTc0IDI1ICAgICAgICAgICAgICAgIAlqZSAg ICAgODA0OGI2MiA8X3N0YXJ0MSsweDU2PgogODA0OGIzZDoJODkgMTUgODQgYTkgMDQgMDgg ICAgCW1vdiAgICAlZWR4LDB4ODA0YTk4NAogODA0OGI0MzoJMGYgYjYgMDIgICAgICAgICAg ICAgCW1vdnpibCAoJWVkeCksJWVheAogODA0OGI0NjoJODQgYzAgICAgICAgICAgICAgICAg CXRlc3QgICAlYWwsJWFsCiA4MDQ4YjQ4Ogk3NCAxOCAgICAgICAgICAgICAgICAJamUgICAg IDgwNDhiNjIgPF9zdGFydDErMHg1Nj4KIDgwNDhiNGE6CTQyICAgICAgICAgICAgICAgICAg IAlpbmMgICAgJWVkeAogODA0OGI0YjoJM2MgMmYgICAgICAgICAgICAgICAgCWNtcCAgICAk MHgyZiwlYWwKIDgwNDhiNGQ6CWExIDg0IGE5IDA0IDA4ICAgICAgIAltb3YgICAgMHg4MDRh OTg0LCVlYXgKIDgwNDhiNTI6CTBmIDQ0IGMyICAgICAgICAgICAgIAljbW92ZSAgJWVkeCwl ZWF4CiA4MDQ4YjU1OglhMyA4NCBhOSAwNCAwOCAgICAgICAJbW92ICAgICVlYXgsMHg4MDRh OTg0CiA4MDQ4YjVhOgkwZiBiNiAwMiAgICAgICAgICAgICAJbW92emJsICglZWR4KSwlZWF4 CiA4MDQ4YjVkOgk0MiAgICAgICAgICAgICAgICAgICAJaW5jICAgICVlZHgKIDgwNDhiNWU6 CTg0IGMwICAgICAgICAgICAgICAgIAl0ZXN0ICAgJWFsLCVhbAogODA0OGI2MDoJNzUgZTkg ICAgICAgICAgICAgICAgCWpuZSAgICA4MDQ4YjRiIDxfc3RhcnQxKzB4M2Y+CiA4MDQ4YjYy OgliOCAyOCBhOCAwNCAwOCAgICAgICAJbW92ICAgICQweDgwNGE4MjgsJWVheAogODA0OGI2 NzoJODUgYzAgICAgICAgICAgICAgICAgCXRlc3QgICAlZWF4LCVlYXgKIDgwNDhiNjk6CTc0 IDFmICAgICAgICAgICAgICAgIAlqZSAgICAgODA0OGI4YSA8X3N0YXJ0MSsweDdlPgogODA0 OGI2YjoJODMgZWMgMGMgICAgICAgICAgICAgCXN1YiAgICAkMHhjLCVlc3AKIDgwNDhiNmU6 CWZmIDc1IDA4ICAgICAgICAgICAgIAlwdXNobCAgMHg4KCVlYnApCiA4MDQ4YjcxOgllOCAw YSBmZSBmZiBmZiAgICAgICAJY2FsbCAgIDgwNDg5ODAgPGF0ZXhpdEBwbHQ+CiA4MDQ4Yjc2 Ogk4MyBjNCAxMCAgICAgICAgICAgICAJYWRkICAgICQweDEwLCVlc3AKIDgwNDhiNzk6CTUw ICAgICAgICAgICAgICAgICAgIAlwdXNoICAgJWVheAogODA0OGI3YToJNTMgICAgICAgICAg ICAgICAgICAgCXB1c2ggICAlZWJ4CiA4MDQ4YjdiOgk1NyAgICAgICAgICAgICAgICAgICAJ cHVzaCAgICVlZGkKIDgwNDhiN2M6CTU2ICAgICAgICAgICAgICAgICAgIAlwdXNoICAgJWVz aQogODA0OGI3ZDoJZTggMmYgMDQgMDAgMDAgICAgICAgCWNhbGwgICA4MDQ4ZmIxIDxtYWlu PgogODA0OGI4MjoJODkgMDQgMjQgICAgICAgICAgICAgCW1vdiAgICAlZWF4LCglZXNwKQog ODA0OGI4NToJZTggNDYgZmYgZmYgZmYgICAgICAgCWNhbGwgICA4MDQ4YWQwIDxleGl0QHBs dD4KIDgwNDhiOGE6CWU4IDQxIGZlIGZmIGZmICAgICAgIAljYWxsICAgODA0ODlkMCA8X2lu aXRfdGxzQHBsdD4KIDgwNDhiOGY6CTgzIGVjIDBjICAgICAgICAgICAgIAlzdWIgICAgJDB4 YywlZXNwCiA4MDQ4YjkyOgk2OCAyOCA4YyAwNCAwOCAgICAgICAJcHVzaCAgICQweDgwNDhj MjgKIDgwNDhiOTc6CWU4IGU0IGZkIGZmIGZmICAgICAgIAljYWxsICAgODA0ODk4MCA8YXRl eGl0QHBsdD4KIDgwNDhiOWM6CWI4IDE0IGE4IDA0IDA4ICAgICAgIAltb3YgICAgJDB4ODA0 YTgxNCwlZWF4CiA4MDQ4YmExOgkyZCAxNCBhOCAwNCAwOCAgICAgICAJc3ViICAgICQweDgw NGE4MTQsJWVheAogODA0OGJhNjoJODMgYzQgMTAgICAgICAgICAgICAgCWFkZCAgICAkMHgx MCwlZXNwCiA4MDQ4YmE5OgljMSBmOCAwMiAgICAgICAgICAgICAJc2FyICAgICQweDIsJWVh eAogODA0OGJhYzoJODkgNDUgZTggICAgICAgICAgICAgCW1vdiAgICAlZWF4LC0weDE4KCVl YnApCiA4MDQ4YmFmOgk3NCAyZSAgICAgICAgICAgICAgICAJamUgICAgIDgwNDhiZGYgPF9z dGFydDErMHhkMz4KIDgwNDhiYjE6CWM3IDQ1IGVjIDI4IGE4IDA0IDA4IAltb3ZsICAgJDB4 ODA0YTgyOCwtMHgxNCglZWJwKQogODA0OGJiODoJZWIgMGIgICAgICAgICAgICAgICAgCWpt cCAgICA4MDQ4YmM1IDxfc3RhcnQxKzB4Yjk+CiA4MDQ4YmJhOglmZiA0NSBlYyAgICAgICAg ICAgICAJaW5jbCAgIC0weDE0KCVlYnApCiA4MDQ4YmJkOgk4YiA0NSBlYyAgICAgICAgICAg ICAJbW92ICAgIC0weDE0KCVlYnApLCVlYXgKIDgwNDhiYzA6CTM5IDQ1IGU4ICAgICAgICAg ICAgIAljbXAgICAgJWVheCwtMHgxOCglZWJwKQogODA0OGJjMzoJNzQgMWEgICAgICAgICAg ICAgICAgCWplICAgICA4MDQ4YmRmIDxfc3RhcnQxKzB4ZDM+CiA4MDQ4YmM1Ogk4YiA1NSBl YyAgICAgICAgICAgICAJbW92ICAgIC0weDE0KCVlYnApLCVlZHgKIDgwNDhiYzg6CThiIDA0 IDk1IDE0IGE4IDA0IDA4IAltb3YgICAgMHg4MDRhODE0KCwlZWR4LDQpLCVlYXgKIDgwNDhi Y2Y6CTgzIGY4IDAxICAgICAgICAgICAgIAljbXAgICAgJDB4MSwlZWF4CiA4MDQ4YmQyOgk3 NiBlNiAgICAgICAgICAgICAgICAJamJlICAgIDgwNDhiYmEgPF9zdGFydDErMHhhZT4KIDgw NDhiZDQ6CTUxICAgICAgICAgICAgICAgICAgIAlwdXNoICAgJWVjeAogODA0OGJkNToJNTMg ICAgICAgICAgICAgICAgICAgCXB1c2ggICAlZWJ4CiA4MDQ4YmQ2Ogk1NyAgICAgICAgICAg ICAgICAgICAJcHVzaCAgICVlZGkKIDgwNDhiZDc6CTU2ICAgICAgICAgICAgICAgICAgIAlw dXNoICAgJWVzaQogODA0OGJkODoJZmYgZDAgICAgICAgICAgICAgICAgCWNhbGwgICAqJWVh eAogODA0OGJkYToJODMgYzQgMTAgICAgICAgICAgICAgCWFkZCAgICAkMHgxMCwlZXNwCiA4 MDQ4YmRkOgllYiBkYiAgICAgICAgICAgICAgICAJam1wICAgIDgwNDhiYmEgPF9zdGFydDEr MHhhZT4KIDgwNDhiZGY6CWU4IGU4IGZjIGZmIGZmICAgICAgIAljYWxsICAgODA0ODhjYyA8 X2luaXQ+CiA4MDQ4YmU0OgliOCAxNCBhOCAwNCAwOCAgICAgICAJbW92ICAgICQweDgwNGE4 MTQsJWVheAogODA0OGJlOToJMmQgMTQgYTggMDQgMDggICAgICAgCXN1YiAgICAkMHg4MDRh ODE0LCVlYXgKIDgwNDhiZWU6CWMxIGY4IDAyICAgICAgICAgICAgIAlzYXIgICAgJDB4Miwl ZWF4CiA4MDQ4YmYxOgk4OSA0NSBlNCAgICAgICAgICAgICAJbW92ICAgICVlYXgsLTB4MWMo JWVicCkKIDgwNDhiZjQ6CTc0IDgzICAgICAgICAgICAgICAgIAlqZSAgICAgODA0OGI3OSA8 X3N0YXJ0MSsweDZkPgogODA0OGJmNjoJYzcgNDUgZjAgMDAgMDAgMDAgMDAgCW1vdmwgICAk MHgwLC0weDEwKCVlYnApCiA4MDQ4YmZkOgllYiAwZiAgICAgICAgICAgICAgICAJam1wICAg IDgwNDhjMGUgPF9zdGFydDErMHgxMDI+CiA4MDQ4YmZmOglmZiA0NSBmMCAgICAgICAgICAg ICAJaW5jbCAgIC0weDEwKCVlYnApCiA4MDQ4YzAyOgk4YiA0NSBmMCAgICAgICAgICAgICAJ bW92ICAgIC0weDEwKCVlYnApLCVlYXgKIDgwNDhjMDU6CTM5IDQ1IGU0ICAgICAgICAgICAg IAljbXAgICAgJWVheCwtMHgxYyglZWJwKQogODA0OGMwODoJMGYgODQgNmIgZmYgZmYgZmYg ICAgCWplICAgICA4MDQ4Yjc5IDxfc3RhcnQxKzB4NmQ+CiA4MDQ4YzBlOgk4YiA1NSBmMCAg ICAgICAgICAgICAJbW92ICAgIC0weDEwKCVlYnApLCVlZHgKIDgwNDhjMTE6CThiIDA0IDk1 IDE0IGE4IDA0IDA4IAltb3YgICAgMHg4MDRhODE0KCwlZWR4LDQpLCVlYXgKIDgwNDhjMTg6 CTgzIGY4IDAxICAgICAgICAgICAgIAljbXAgICAgJDB4MSwlZWF4CiA4MDQ4YzFiOgk3NiBl MiAgICAgICAgICAgICAgICAJamJlICAgIDgwNDhiZmYgPF9zdGFydDErMHhmMz4KIDgwNDhj MWQ6CTUyICAgICAgICAgICAgICAgICAgIAlwdXNoICAgJWVkeAogODA0OGMxZToJNTMgICAg ICAgICAgICAgICAgICAgCXB1c2ggICAlZWJ4CiA4MDQ4YzFmOgk1NyAgICAgICAgICAgICAg ICAgICAJcHVzaCAgICVlZGkKIDgwNDhjMjA6CTU2ICAgICAgICAgICAgICAgICAgIAlwdXNo ICAgJWVzaQogODA0OGMyMToJZmYgZDAgICAgICAgICAgICAgICAgCWNhbGwgICAqJWVheAog ODA0OGMyMzoJODMgYzQgMTAgICAgICAgICAgICAgCWFkZCAgICAkMHgxMCwlZXNwCiA4MDQ4 YzI2OgllYiBkNyAgICAgICAgICAgICAgICAJam1wICAgIDgwNDhiZmYgPF9zdGFydDErMHhm Mz4K ------------02B01613E319E0BA9-- From owner-freebsd-current@FreeBSD.ORG Fri Feb 22 20:34:24 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 1B4F9310; Fri, 22 Feb 2013 20:34:24 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 83FF8A04; Fri, 22 Feb 2013 20:34:23 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.6/8.14.6) with ESMTP id r1MKYFnm043088; Fri, 22 Feb 2013 22:34:15 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.7.4 kib.kiev.ua r1MKYFnm043088 Received: (from kostik@localhost) by tom.home (8.14.6/8.14.6/Submit) id r1MKYFvR043087; Fri, 22 Feb 2013 22:34:15 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 22 Feb 2013 22:34:15 +0200 From: Konstantin Belousov To: Nathan Whitehorn , Claude Buisson Subject: Re: DVD/CD lost after r246713 Message-ID: <20130222203415.GR2598@kib.kiev.ua> References: <51265A58.4010600@orange.fr> <20130222082145.GJ2598@kib.kiev.ua> <51275FC7.9010906@orange.fr> <5127A3DF.3060304@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="7aNskZ0IQd9Ag0jb" Content-Disposition: inline In-Reply-To: <5127A3DF.3060304@freebsd.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 20:34:24 -0000 --7aNskZ0IQd9Ag0jb Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Feb 22, 2013 at 10:59:11AM -0600, Nathan Whitehorn wrote: > On 02/22/13 06:08, Claude Buisson wrote: > > On 02/22/2013 09:21, Konstantin Belousov wrote: > > > > > > > >> You need to provide the dmesg from r246713 and r246712 to compare. > >> The note that r246711 snapshot exhibited this same problem makes > >> me sceptical. > > > > Here are the verbose dmesg from r246712 and r246713; > > > > For the sceptical: > > > > root@fidel# cd /usr/src > > root@fidel# grep "\$FreeBSD\:" sys/conf/files > > # $FreeBSD: head/sys/conf/files 246586 2013-02-09 06:39:28Z delphij $ > > root@fidel# grep "\$FreeBSD\:" sys/ia64/ia64/dump_machdep.c > > __FBSDID("$FreeBSD: head/sys/ia64/ia64/dump_machdep.c 246712 2013-02-12 > > 16:51:43Z marcel $"); > > > > for r246712 > > > > root@fidel# cd /usr/src > > root@fidel# grep "\$FreeBSD\:" sys/conf/files > > # $FreeBSD: head/sys/conf/files 246713 2013-02-12 16:57:20Z kib $ > > root@fidel# grep "\$FreeBSD\:" sys/ia64/include/proc.h > > * $FreeBSD: head/sys/ia64/include/proc.h 226112 2011-10-07 16:09:44Z= =20 > > kib $ > > > > for r246713 > > > > The source is from svn0.us-east.freebsd.org > > > > And obj/ has been rm'ed before each buildkernel > > > > My own conclusion is that the rev number in: > > > > FreeBSD-10.0-HEAD-r246711-JPSNAP-i386-i386-memstick.img > > > > is bogus, and this can be easily checked by grepping for=20 > > kern/subr_bus_dma.c in > > the BUILD.log as this file has been ADDED by r246713 > > > > CBu (working on this since Tuesday) >=20 > For whatever it is worth, I have experienced the identical problem on an= =20 > amd64 system. I see. Could please, one of you try the following, which just a revert of the r246713 for dev/ata ? I believe/hope that this should fix the issue. Apply in the sys/dev/ata directory. Index: ata-dma.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 --- ata-dma.c (revision 246713) +++ ata-dma.c (revision 246712) @@ -304,17 +304,10 @@ ata_dmaload(struct ata_request *request, void *add else dspa.dmatab =3D request->dma->sg; =20 -#ifdef ATA_CAM - if (request->ccb) - error =3D bus_dmamap_load_ccb(request->dma->data_tag, - request->dma->data_map, request->ccb, - ch->dma.setprd, &dspa, BUS_DMA_NOWAIT); - else -#endif - error =3D bus_dmamap_load(request->dma->data_tag, request->dma->da= ta_map, - request->data, request->bytecount, - ch->dma.setprd, &dspa, BUS_DMA_NOWAIT); - if (error || (error =3D dspa.error)) { + if ((error =3D bus_dmamap_load(request->dma->data_tag, request->dma->d= ata_map, + request->data, request->bytecount, + ch->dma.setprd, &dspa, BUS_DMA_NOWAIT)) || + (error =3D dspa.error)) { device_printf(request->parent, "FAILURE - load data\n"); goto error; } Index: atapi-cam.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 --- atapi-cam.c (revision 246713) +++ atapi-cam.c (revision 246712) @@ -514,6 +514,12 @@ atapi_action(struct cam_sim *sim, union ccb *ccb) ("CAM CCB too long for ATAPI")); goto action_invalid; } + if ((ccb_h->flags & CAM_SCATTER_VALID)) { + /* scatter-gather not supported */ + xpt_print_path(ccb_h->path); + printf("ATAPI/CAM does not support scatter-gather yet!\n"); + goto action_invalid; + } =20 switch (ccb_h->flags & CAM_DIR_MASK) { case CAM_DIR_IN: --7aNskZ0IQd9Ag0jb Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJRJ9ZGAAoJEJDCuSvBvK1BBaEQAIJBijjwNMQEtl57/0FaO2ry F2tqW5QbFs4XUGKRPBzp2S8Ixxtu5LTSGcjW8D5SNIgUuxcnZCUByp1L8wODdEzX jNwXQfgTgSDPFGfrBI+ef7wMPrSF2hzJ5oyXG4/NiYwq7DOai7kKNm4G12cwFH+a VT7tVGfZqLWYIaSYJhixzp1Fr0UTFW3vBR59LgDpdUbNFRFYXO+THZlKLqnZJk9n NU09kXf7RlRplzgPNlJbH/dJs65ZCYQcOrnMjwWbk+9EnpW8E7kv+JUlWoQqha6i Fc4k81EyojULpFn+7jEpTKgDtvoRy5jXF5krCe+uylnp9UeFd+NJgCwmJt9fD2oE rtCPHD5egritfZEhwQ6z5BEYn7w7SD4SgRADYc5cCPx0HRXO1tzS6Ce+oxSdTO+S R1jlg1iuNKX2Y8P+v1Kc4jwVay2A+lQwjIM78Dms3zK4e4A+UMZABpwljxk1C/RC Yw38jwEI3R7Sdwfnyjmj4LTsr5gHjc5SKYz/zWzu00BDQmxTYws0Fa541KnMM7LG CZfSaM0SQvKqn4d+q8ElVguDyuDaZmWqAszZ4tcAqm2UOeJBdSxllNJ+MzltZCo6 YSYNu+ic4qmxojjlSlZ6cDkKzOsE4VC8C1tW2TC+OFULlB8ISoJqGLqrK5ChhEhE /c8NoawmxfrvUzwu/XEf =axq1 -----END PGP SIGNATURE----- --7aNskZ0IQd9Ag0jb-- From owner-freebsd-current@FreeBSD.ORG Fri Feb 22 20:46:36 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id BE0B3575 for ; Fri, 22 Feb 2013 20:46:36 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from anubis.delphij.net (anubis.delphij.net [64.62.153.212]) by mx1.freebsd.org (Postfix) with ESMTP id 8B2ADA7B for ; Fri, 22 Feb 2013 20:46:36 +0000 (UTC) Received: from epsilon.delphij.net (drawbridge.ixsystems.com [206.40.55.65]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by anubis.delphij.net (Postfix) with ESMTPSA id E524524C8F; Fri, 22 Feb 2013 12:46:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=delphij.net; s=anubis; t=1361565990; bh=QKWF+fybqtzn53nfFJyx0/JxkxeXc49x1GgF5B1a7t4=; h=Date:From:Reply-To:To:CC:Subject:References:In-Reply-To; b=h2Be/VTQ1oGdjaIqKjsUG5guv5B84wG4yszyNdfXXDXMKk4StEfsjpmO7jVn5Jf4m huubDsvwkiOaqWY6mSaYVYuvAT5WukTXYjNB1E5dJ75vt7OFnFkkLXjO6xO48x6XTg 3uHe/lhgloPuRSOPQDNSGFfZDn5vAZA1efWpVdpY= Message-ID: <5127D925.4030506@delphij.net> Date: Fri, 22 Feb 2013 12:46:29 -0800 From: Xin Li Organization: The FreeBSD Project MIME-Version: 1.0 To: Steve Kargl Subject: Re: compiling libc and libthr with debugging? References: <20130207181441.GA58987@troutmask.apl.washington.edu> In-Reply-To: <20130207181441.GA58987@troutmask.apl.washington.edu> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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: Fri, 22 Feb 2013 20:46:36 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 02/07/13 10:14, Steve Kargl wrote: > What's the preferred method for compiling libc and libthr with > debugging enable? I think that would be to compile and install libaries with DEBUG_FLAGS=-g? Not sure if this is what you wanted though... Cheers, - -- Xin LI https://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJRJ9klAAoJEG80Jeu8UPuz3iEIAKXjl4nvYpf1kp9jAV+wtsWT rNJEzzx6gr366b0NZuYJHTmIRA317Ip3VCCxgIRBhE40caLX7CHfb7NV0eTJh2Lh lcWB9mkr+LsxTHLyJu/2ePAbTxuf+po8GSFuQkfCn9y29v1MIeeGyl6w3YowA2xx fS51NC7IYvuXMcv2lyeM1B7iIKRdOY0/zD3G8RjutCvzMvuX2BzqWJZuLxohAYmN 8o8xChMk45x6VVkEn2VZgVHRfAMxipY/fSaSzJiwfHcO54v2bvqoXBMUk1vf+3FX 7EoFPRZvFYjXML8jF1r+lINaDz8Fd/GKOcRqfW8LQrXo4qi4TBSlTIlcDkp3y6s= =+b4P -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Fri Feb 22 20:49:26 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 26BE469D; Fri, 22 Feb 2013 20:49:26 +0000 (UTC) (envelope-from dimitry@andric.com) Received: from tensor.andric.com (tensor.andric.com [IPv6:2001:7b8:3a7:1:2d0:b7ff:fea0:8c26]) by mx1.freebsd.org (Postfix) with ESMTP id C362DA9B; Fri, 22 Feb 2013 20:49:25 +0000 (UTC) Received: from [192.168.0.6] (spaceball.home.andric.com [192.168.0.6]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 0043E5C43; Fri, 22 Feb 2013 21:49:20 +0100 (CET) Message-ID: <5127D9D2.3000508@andric.com> Date: Fri, 22 Feb 2013 21:49:22 +0100 From: Dimitry Andric User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:19.0) Gecko/20130117 Thunderbird/19.0 MIME-Version: 1.0 To: lev@FreeBSD.org Subject: Re: r245741 (clang as cc) can not build binaries for GEODE processor References: <108875110.20130222104603@serebryakov.spb.ru> <51277EFE.4000703@andric.com> <15917508.20130222194954@serebryakov.spb.ru> <5127997A.2000901@andric.com> <781694121.20130222235742@serebryakov.spb.ru> In-Reply-To: <781694121.20130222235742@serebryakov.spb.ru> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 20:49:26 -0000 On 2013-02-22 20:57, Lev Serebryakov wrote: ... > Program terminated with signal 4, Illegal instruction. > Reading symbols from /lib/libc.so.7...done. > Loaded symbols for /lib/libc.so.7 > Reading symbols from /libexec/ld-elf.so.1...done. > Loaded symbols for /libexec/ld-elf.so.1 > #0 0x080483e9 in _start1 () > (gdb) where > #0 0x080483e9 in _start1 () > #1 0x08048398 in _start () > #2 0x00000000 in ?? () > (gdb) x/i $pc > 0x80483e9 <_start1+73>: nopl 0x0(%eax) Ah yes, I see that is in crt1.o. Some of the lib/csu files are built in a special way: for example, the crt1_c.c file is compiled to crt1_c.s, then the crt1_c.s file file is modified with sed, and lastly the crt1_c.s file is assembled to crt1_c.o: cc -O2 -pipe -I/usr/src/lib/csu/i386-elf/../common -I/usr/src/lib/csu/i386-elf/../../libc/include -std=gnu99 -Qunused-arguments -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 -Wno-empty-body -Wno-string-plus-int -S -o crt1_c.s /usr/src/lib/csu/i386-elf/crt1_c.c sed -i "" -e '/\.note\.tag/s/progbits/note/' crt1_c.s cc -c -o crt1_c.o crt1_c.s For some reason, however, in the last step, the default target CPU (i486) is not passed to the assembler stage: $ cc -v -c -o crt1_c.o crt1_c.s FreeBSD clang version 3.2 (tags/RELEASE_32/final 170710) 20121221 Target: i386-unknown-freebsd10.0 Thread model: posix "/usr/bin/cc" -cc1as -triple i386-unknown-freebsd10.0 -filetype obj -o crt1_c.o crt1_c.s and that seems to be why it still inserts log nops there. It is a problem with -cc1as, and I have reported it to upstream, there should hopefully be a fix soon. As a workaround for now, can you please try to build and install lib/csu with the following added to your environment, make.conf or src.conf: ACFLAGS=-Wa,-target-cpu,geode or alternatively: ACFLAGS=-Wa,-target-cpu,i486 whichever you prefer. Then rebuild your test program, and try running it again. If that seems to work, it is probably safest to rebuild world and kernel with those ACFLAGS settings as the next step, and install them. -Dimitry From owner-freebsd-current@FreeBSD.ORG Fri Feb 22 20:55:42 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 3D15597C; Fri, 22 Feb 2013 20:55:42 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 082A0AE6; Fri, 22 Feb 2013 20:55:41 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r1MKtfwR008476; Fri, 22 Feb 2013 15:55:41 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r1MKtfl7008470; Fri, 22 Feb 2013 20:55:41 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 22 Feb 2013 20:55:41 GMT Message-Id: <201302222055.r1MKtfl7008470@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 , , Subject: [head tinderbox] failure on i386/pc98 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 20:55:42 -0000 TB --- 2013-02-22 17:56:44 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-02-22 17:56:44 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-02-22 17:56:44 - starting HEAD tinderbox run for i386/pc98 TB --- 2013-02-22 17:56:44 - cleaning the object tree TB --- 2013-02-22 17:56:44 - /usr/local/bin/svn stat /src TB --- 2013-02-22 17:56:48 - At svn revision 247151 TB --- 2013-02-22 17:56:49 - building world TB --- 2013-02-22 17:56:49 - CROSS_BUILD_TESTING=YES TB --- 2013-02-22 17:56:49 - MAKEOBJDIRPREFIX=/obj TB --- 2013-02-22 17:56:49 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-02-22 17:56:49 - SRCCONF=/dev/null TB --- 2013-02-22 17:56:49 - TARGET=pc98 TB --- 2013-02-22 17:56:49 - TARGET_ARCH=i386 TB --- 2013-02-22 17:56:49 - TZ=UTC TB --- 2013-02-22 17:56:49 - __MAKE_CONF=/dev/null TB --- 2013-02-22 17:56:49 - cd /src TB --- 2013-02-22 17:56:49 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Fri Feb 22 17:56:53 UTC 2013 >>> 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 Fri Feb 22 20:48:10 UTC 2013 TB --- 2013-02-22 20:48:10 - generating LINT kernel config TB --- 2013-02-22 20:48:10 - cd /src/sys/pc98/conf TB --- 2013-02-22 20:48:10 - /usr/bin/make -B LINT TB --- 2013-02-22 20:48:10 - cd /src/sys/pc98/conf TB --- 2013-02-22 20:48:10 - /usr/sbin/config -m LINT TB --- 2013-02-22 20:48:10 - building LINT kernel TB --- 2013-02-22 20:48:10 - CROSS_BUILD_TESTING=YES TB --- 2013-02-22 20:48:10 - MAKEOBJDIRPREFIX=/obj TB --- 2013-02-22 20:48:10 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-02-22 20:48:10 - SRCCONF=/dev/null TB --- 2013-02-22 20:48:10 - TARGET=pc98 TB --- 2013-02-22 20:48:10 - TARGET_ARCH=i386 TB --- 2013-02-22 20:48:10 - TZ=UTC TB --- 2013-02-22 20:48:10 - __MAKE_CONF=/dev/null TB --- 2013-02-22 20:48:10 - cd /src TB --- 2013-02-22 20:48:10 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Fri Feb 22 20:48:10 UTC 2013 >>> 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 -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -DGPROF -DGPROF4 -DGUPROF -fno-builtin -mno-aes -mno-avx -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -Werror -pg /src/sys/dev/mxge/if_mxge.c /src/sys/dev/mxge/if_mxge.c:2571:8: error: use of undeclared identifier 'cap' if ((cap & IFCAP_RXCSUM) == 0) ^ /src/sys/dev/mxge/if_mxge.c:2584:8: error: use of undeclared identifier 'cap' if ((cap & IFCAP_RXCSUM_IPV6) == 0) ^ 2 errors generated. *** [if_mxge.o] Error code 1 Stop in /obj/pc98.i386/src/sys/LINT. *** [buildkernel] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-02-22 20:55:40 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-02-22 20:55:40 - ERROR: failed to build LINT kernel TB --- 2013-02-22 20:55:40 - 8591.61 user 1313.71 system 10736.08 real http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Fri Feb 22 21:30:50 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 52FB3FF3 for ; Fri, 22 Feb 2013 21:30:50 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.netplex.net (mail.netplex.net [204.213.176.10]) by mx1.freebsd.org (Postfix) with ESMTP id 1E1E3CF7 for ; Fri, 22 Feb 2013 21:30:49 +0000 (UTC) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.14.6/8.14.6/NETPLEX) with ESMTP id r1MLUhwm011708 for ; Fri, 22 Feb 2013 16:30:43 -0500 X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.4.1 (mail.netplex.net [204.213.176.10]); Fri, 22 Feb 2013 16:30:43 -0500 (EST) Date: Fri, 22 Feb 2013 16:30:43 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: freebsd-current@freebsd.org Subject: WITHOUT_CLANG_IS_CC: There and back again Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Daniel Eischen List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 21:30:50 -0000 In trying to debug an unrelated problem, I switched CC from Clang back to GCC. I had a -current kernel and world r247050 built and installed with Clang as the system compiler I have nothing special in /etc/make.conf: BATCH=yes WITH_NEW_XORG=true WITH_KMS=true WITH_PKGNG=yes PERL_VERSION=5.14.2 I added WITHOUT_CLANG_IS_CC=yes to this, then rebuilt kernel and world. I installed the kernel rebooted, everthing worked, so I then installed world. Installword stopped here: ===> libexec/rtld-elf (install) chflags -h noschg /usr/libexec/ld-elf.so.1 install -s -o root -g wheel -m 555 -C -b -fschg -S ld-elf.so.1 /libexec install -o root -g wheel -m 444 rtld.1.gz /usr/share/man/man1 *** [_maninstall] Signal 11 Stop in /opt/FreeBSD/current/src/libexec/rtld-elf. *** [realinstall] Error code 1 At that point my system was completely hosed. Every binary (/bin, /sbin, etc) would sig 11. I had to build a world on another system, then use /rescue to NFS mount the other system and copy over /libexec, /lib, and /usr/lib. This let me recover enough to svn up to r247164. remove WITHOUT_CLANG_IS_CC from /etc/make.conf, and build/install a working world. Is switching from Clang to GCC suppose to work? -- DE From owner-freebsd-current@FreeBSD.ORG Fri Feb 22 21:36:07 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 31799299; Fri, 22 Feb 2013 21:36:07 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) by mx1.freebsd.org (Postfix) with ESMTP id D0394D30; Fri, 22 Feb 2013 21:36:06 +0000 (UTC) Received: from [192.168.0.6] (spaceball.home.andric.com [192.168.0.6]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 097575C43; Fri, 22 Feb 2013 22:35:59 +0100 (CET) Message-ID: <5127E4C0.6060209@FreeBSD.org> Date: Fri, 22 Feb 2013 22:36:00 +0100 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:19.0) Gecko/20130117 Thunderbird/19.0 MIME-Version: 1.0 To: Daniel Eischen , freebsd-current@freebsd.org Subject: Re: WITHOUT_CLANG_IS_CC: There and back again References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 21:36:07 -0000 On 2013-02-22 22:30, Daniel Eischen wrote: > In trying to debug an unrelated problem, I switched CC from Clang > back to GCC. I had a -current kernel and world r247050 built and > installed with Clang as the system compiler I have nothing special > in /etc/make.conf: > > BATCH=yes > WITH_NEW_XORG=true > WITH_KMS=true > WITH_PKGNG=yes > PERL_VERSION=5.14.2 > > I added WITHOUT_CLANG_IS_CC=yes to this, then rebuilt kernel and > world. I installed the kernel rebooted, everthing worked, so I > then installed world. Installword stopped here: > > ===> libexec/rtld-elf (install) > chflags -h noschg /usr/libexec/ld-elf.so.1 > install -s -o root -g wheel -m 555 -C -b -fschg -S ld-elf.so.1 /libexec > install -o root -g wheel -m 444 rtld.1.gz /usr/share/man/man1 > *** [_maninstall] Signal 11 > > Stop in /opt/FreeBSD/current/src/libexec/rtld-elf. > *** [realinstall] Error code 1 > > At that point my system was completely hosed. Every binary (/bin, > /sbin, etc) would sig 11. I had to build a world on another > system, then use /rescue to NFS mount the other system and > copy over /libexec, /lib, and /usr/lib. This let me recover > enough to svn up to r247164. remove WITHOUT_CLANG_IS_CC from > /etc/make.conf, and build/install a working world. > > Is switching from Clang to GCC suppose to work? This might have had nothing to do with either clang or gcc. Between r247012 and r247117, binutils was broken, and this apparently resulted in various nasty problems. Maybe you can try it again, since you are now at r247164? From owner-freebsd-current@FreeBSD.ORG Fri Feb 22 21:40:51 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id F22273EE; Fri, 22 Feb 2013 21:40:50 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) by mx1.freebsd.org (Postfix) with ESMTP id BAFD1D75; Fri, 22 Feb 2013 21:40:50 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.6/8.14.6) with ESMTP id r1MLeoVM097446; Fri, 22 Feb 2013 13:40:50 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.6/8.14.6/Submit) id r1MLeoRJ097445; Fri, 22 Feb 2013 13:40:50 -0800 (PST) (envelope-from sgk) Date: Fri, 22 Feb 2013 13:40:50 -0800 From: Steve Kargl To: Daniel Eischen Subject: Re: WITHOUT_CLANG_IS_CC: There and back again Message-ID: <20130222214050.GB97359@troutmask.apl.washington.edu> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 21:40:51 -0000 On Fri, Feb 22, 2013 at 04:30:43PM -0500, Daniel Eischen wrote: > > At that point my system was completely hosed. Every binary (/bin, > /sbin, etc) would sig 11. I had to build a world on another > system, then use /rescue to NFS mount the other system and > copy over /libexec, /lib, and /usr/lib. This let me recover > enough to svn up to r247164. remove WITHOUT_CLANG_IS_CC from > /etc/make.conf, and build/install a working world. > > Is switching from Clang to GCC suppose to work? > It works if you do thorough switch. Use WITH_GCC WITHOUT_CLANG then after the installworld step, use 'make delete-old' and 'make delete-old-libs' to rid your system of the leftovers. -- Steve From owner-freebsd-current@FreeBSD.ORG Fri Feb 22 21:46:57 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 5A41B6E7; Fri, 22 Feb 2013 21:46:57 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-la0-x22f.google.com (mail-la0-x22f.google.com [IPv6:2a00:1450:4010:c03::22f]) by mx1.freebsd.org (Postfix) with ESMTP id 829EDDC7; Fri, 22 Feb 2013 21:46:56 +0000 (UTC) Received: by mail-la0-f47.google.com with SMTP id fj20so1061687lab.6 for ; Fri, 22 Feb 2013 13:46:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:message-id:date:from:user-agent:mime-version:to :cc:subject:content-type:content-transfer-encoding; bh=4GYzMe3EP446QArYC+zBaoJ/WjqDyH0wS6QTdKOGImg=; b=vJ4RYt75229i/o+JJJjltJm1LI0Pyh7h9hAN8NgOvDoR2s+aAE8qHWHGT4UhT0ZQAL xNMXEATh1Tcw2U5+gj2v5lWQvSbLAF5SiItSWEKDv1vnZS2ALR4XMXeeLUI1uuRsu55g JIJdt+BmY5ABZWh0yaurjbUmpWZjk7xtiQQiIfVh734dWcF/Goz0NFnZQWKmU7nkFz7H Pft6C/n3hoIAuZbyTmAyfKQ3P1PuX2KyniyfrSAb46G3Ifc/DyvypxgRJ8ThAJDMYEQJ YHCMz8nyAux7+l8nUkFChaG5tLbjEGA06y+d5haH6/69TWSlOfSlj+jAnqBFaNQoRvLC 526g== X-Received: by 10.152.109.84 with SMTP id hq20mr2983682lab.48.1361569615375; Fri, 22 Feb 2013 13:46:55 -0800 (PST) Received: from mavbook.mavhome.dp.ua (mavhome.mavhome.dp.ua. [213.227.240.37]) by mx.google.com with ESMTPS id c6sm1328552lbo.3.2013.02.22.13.46.52 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 22 Feb 2013 13:46:53 -0800 (PST) Sender: Alexander Motin Message-ID: <5127E74A.4050205@FreeBSD.org> Date: Fri, 22 Feb 2013 23:46:50 +0200 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130125 Thunderbird/17.0.2 MIME-Version: 1.0 To: athan Whitehorn , Claude Buisson Subject: Re: DVD/CD lost after r246713 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit Cc: Konstantin Belousov , FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 21:46:57 -0000 Hi. ATAPI devices on legacy ATA controllers were lost due to command timeout caused by data underrun, caused by r246713. r247165 should fix the issue. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Fri Feb 22 21:50:47 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id A909B821 for ; Fri, 22 Feb 2013 21:50:47 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from adsum.doit.wisc.edu (adsum.doit.wisc.edu [144.92.197.210]) by mx1.freebsd.org (Postfix) with ESMTP id 83F9BDF9 for ; Fri, 22 Feb 2013 21:50:47 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from avs-daemon.smtpauth1.wiscmail.wisc.edu by smtpauth1.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 7u2-7.05 32bit (built Jul 30 2009)) id <0MIN00E005V70700@smtpauth1.wiscmail.wisc.edu> for freebsd-current@freebsd.org; Fri, 22 Feb 2013 15:50:46 -0600 (CST) X-Spam-PmxInfo: Server=avs-1, Version=5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.2.22.214214, SenderIP=0.0.0.0 X-Spam-Report: AuthenticatedSender=yes, SenderIP=0.0.0.0 Received: from terminus.icecube.wisc.edu (i3-user-nat.icecube.wisc.edu [128.104.255.12]) by smtpauth1.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 7u2-7.05 32bit (built Jul 30 2009)) with ESMTPSA id <0MIN00IRP60L6740@smtpauth1.wiscmail.wisc.edu> for freebsd-current@freebsd.org; Fri, 22 Feb 2013 15:50:45 -0600 (CST) X-Wisc-Sender: whitehorn@wisc.edu Message-id: <5127E835.6000400@freebsd.org> Date: Fri, 22 Feb 2013 15:50:45 -0600 From: Nathan Whitehorn User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130218 Thunderbird/17.0.2 To: freebsd-current@freebsd.org Subject: Re: DVD/CD lost after r246713 References: <5127E74A.4050205@FreeBSD.org> In-reply-to: <5127E74A.4050205@FreeBSD.org> X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 21:50:47 -0000 On 02/22/13 15:46, Alexander Motin wrote: > Hi. > > ATAPI devices on legacy ATA controllers were lost due to command timeout > caused by data underrun, caused by r246713. > > r247165 should fix the issue. > Mine is on AHCI. Should that have been fixed too? -Nathan From owner-freebsd-current@FreeBSD.ORG Fri Feb 22 22:11:00 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 98E06AB7; Fri, 22 Feb 2013 22:11:00 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-la0-x22f.google.com (mail-la0-x22f.google.com [IPv6:2a00:1450:4010:c03::22f]) by mx1.freebsd.org (Postfix) with ESMTP id EF522E9D; Fri, 22 Feb 2013 22:10:59 +0000 (UTC) Received: by mail-la0-f47.google.com with SMTP id fj20so1080824lab.20 for ; Fri, 22 Feb 2013 14:10:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=z7CsUY3HMriHEADvjvwf8sav9Ku4Ze9RY0oZospD6Wk=; b=nbaiAb4WpSDhaZtzxKNj84pIBNCN06P7RLWwKco3QZPqL8wk4V9/KkA18rX9+mQMTw K1P90WUHLVK3rpIzYKfM09AsrzdSMJ1dKh1kp8bL4kbyGUBlxP05tujpanfRmEGqUo69 O/hD73+fj9GifFFL4Y9ixyeMslwOmys4zJIkW8f6/aYAo/pyl9wXS9BfQ25k9BufqWr2 zsjCpqT/ZKk4HQ483b8pn6aXm/NhjXv7bEmIzdkRciMT+m0zxuH4zeVSCMF91UplEIBY Ip5NSrkWTqeUDUhJ3jcXd/9K93Y/DDgVroQc1tWNyuXqmqqJnxaHSuXa7/L8+ISstPBC j5+g== X-Received: by 10.152.148.195 with SMTP id tu3mr3106376lab.27.1361571058878; Fri, 22 Feb 2013 14:10:58 -0800 (PST) Received: from mavbook.mavhome.dp.ua (mavhome.mavhome.dp.ua. [213.227.240.37]) by mx.google.com with ESMTPS id fz16sm2029250lab.5.2013.02.22.14.10.56 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 22 Feb 2013 14:10:57 -0800 (PST) Sender: Alexander Motin Message-ID: <5127ECEF.8080208@FreeBSD.org> Date: Sat, 23 Feb 2013 00:10:55 +0200 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130125 Thunderbird/17.0.2 MIME-Version: 1.0 To: Nathan Whitehorn Subject: Re: DVD/CD lost after r246713 References: <5127E74A.4050205@FreeBSD.org> In-Reply-To: <5127E74A.4050205@FreeBSD.org> Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 22:11:00 -0000 >> On 02/22/13 15:46, Alexander Motin wrote: >>> ATAPI devices on legacy ATA controllers were lost due to command timeout >>> caused by data underrun, caused by r246713. >>> >>> r247165 should fix the issue. > > Mine is on AHCI. Should that have been fixed too? I have no problem with AHCI, and as I can see problem fixed by r247165 should not exist there. You may have something different. Push more info and keep me in CC. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Fri Feb 22 22:15:18 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id E52B9BDF; Fri, 22 Feb 2013 22:15:18 +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 B5901EBE; Fri, 22 Feb 2013 22:15:18 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r1MMFHaO056444; Fri, 22 Feb 2013 17:15:17 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r1MMFHlu056443; Fri, 22 Feb 2013 22:15:17 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 22 Feb 2013 22:15:17 GMT Message-Id: <201302222215.r1MMFHlu056443@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 , , Subject: [head tinderbox] failure on sparc64/sparc64 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 22:15:19 -0000 TB --- 2013-02-22 21:07:30 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-02-22 21:07:30 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-02-22 21:07:30 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2013-02-22 21:07:30 - cleaning the object tree TB --- 2013-02-22 21:07:30 - /usr/local/bin/svn stat /src TB --- 2013-02-22 21:07:33 - At svn revision 247151 TB --- 2013-02-22 21:07:34 - building world TB --- 2013-02-22 21:07:34 - CROSS_BUILD_TESTING=YES TB --- 2013-02-22 21:07:34 - MAKEOBJDIRPREFIX=/obj TB --- 2013-02-22 21:07:34 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-02-22 21:07:34 - SRCCONF=/dev/null TB --- 2013-02-22 21:07:34 - TARGET=sparc64 TB --- 2013-02-22 21:07:34 - TARGET_ARCH=sparc64 TB --- 2013-02-22 21:07:34 - TZ=UTC TB --- 2013-02-22 21:07:34 - __MAKE_CONF=/dev/null TB --- 2013-02-22 21:07:34 - cd /src TB --- 2013-02-22 21:07:34 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Fri Feb 22 21:07:38 UTC 2013 >>> 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 Fri Feb 22 22:09:21 UTC 2013 TB --- 2013-02-22 22:09:21 - generating LINT kernel config TB --- 2013-02-22 22:09:21 - cd /src/sys/sparc64/conf TB --- 2013-02-22 22:09:21 - /usr/bin/make -B LINT TB --- 2013-02-22 22:09:21 - cd /src/sys/sparc64/conf TB --- 2013-02-22 22:09:21 - /usr/sbin/config -m LINT TB --- 2013-02-22 22:09:21 - building LINT kernel TB --- 2013-02-22 22:09:21 - CROSS_BUILD_TESTING=YES TB --- 2013-02-22 22:09:21 - MAKEOBJDIRPREFIX=/obj TB --- 2013-02-22 22:09:21 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-02-22 22:09:21 - SRCCONF=/dev/null TB --- 2013-02-22 22:09:21 - TARGET=sparc64 TB --- 2013-02-22 22:09:21 - TARGET_ARCH=sparc64 TB --- 2013-02-22 22:09:21 - TZ=UTC TB --- 2013-02-22 22:09:21 - __MAKE_CONF=/dev/null TB --- 2013-02-22 22:09:21 - cd /src TB --- 2013-02-22 22:09:21 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Fri Feb 22 22:09:21 UTC 2013 >>> 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 [...] ld -b binary --no-warn-mismatch -d -warn-common -r -o mw88W8363.fwo mw88W8363.fw uudecode -o mwlboot.fw /src/sys/contrib/dev/mwl/mwlboot.fw.uu ld -b binary --no-warn-mismatch -d -warn-common -r -o mwlboot.fwo mwlboot.fw 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 -fdiagnostics-show-option -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/dev/mxge/if_mxge.c /src/sys/dev/mxge/if_mxge.c: In function 'mxge_rx_csum': /src/sys/dev/mxge/if_mxge.c:2571: error: 'cap' undeclared (first use in this function) /src/sys/dev/mxge/if_mxge.c:2571: error: (Each undeclared identifier is reported only once /src/sys/dev/mxge/if_mxge.c:2571: error: for each function it appears in.) *** [if_mxge.o] Error code 1 Stop in /obj/sparc64.sparc64/src/sys/LINT. *** [buildkernel] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-02-22 22:15:17 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-02-22 22:15:17 - ERROR: failed to build LINT kernel TB --- 2013-02-22 22:15:17 - 3380.83 user 579.03 system 4067.12 real http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Fri Feb 22 22:17:26 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id D2066D1B; Fri, 22 Feb 2013 22:17:26 +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 A8BACED9; Fri, 22 Feb 2013 22:17:26 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r1MMHPw9058083; Fri, 22 Feb 2013 17:17:25 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r1MMHPc9058082; Fri, 22 Feb 2013 22:17:25 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 22 Feb 2013 22:17:25 GMT Message-Id: <201302222217.r1MMHPc9058082@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 , , Subject: [head tinderbox] failure on powerpc/powerpc Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 22:17:26 -0000 TB --- 2013-02-22 19:51:04 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-02-22 19:51:04 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-02-22 19:51:04 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2013-02-22 19:51:04 - cleaning the object tree TB --- 2013-02-22 19:51:04 - /usr/local/bin/svn stat /src TB --- 2013-02-22 19:51:07 - At svn revision 247151 TB --- 2013-02-22 19:51:08 - building world TB --- 2013-02-22 19:51:08 - CROSS_BUILD_TESTING=YES TB --- 2013-02-22 19:51:08 - MAKEOBJDIRPREFIX=/obj TB --- 2013-02-22 19:51:08 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-02-22 19:51:08 - SRCCONF=/dev/null TB --- 2013-02-22 19:51:08 - TARGET=powerpc TB --- 2013-02-22 19:51:08 - TARGET_ARCH=powerpc TB --- 2013-02-22 19:51:08 - TZ=UTC TB --- 2013-02-22 19:51:08 - __MAKE_CONF=/dev/null TB --- 2013-02-22 19:51:08 - cd /src TB --- 2013-02-22 19:51:08 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Fri Feb 22 19:51:12 UTC 2013 >>> 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 Fri Feb 22 22:12:38 UTC 2013 TB --- 2013-02-22 22:12:38 - generating LINT kernel config TB --- 2013-02-22 22:12:38 - cd /src/sys/powerpc/conf TB --- 2013-02-22 22:12:38 - /usr/bin/make -B LINT TB --- 2013-02-22 22:12:38 - cd /src/sys/powerpc/conf TB --- 2013-02-22 22:12:38 - /usr/sbin/config -m LINT TB --- 2013-02-22 22:12:38 - building LINT kernel TB --- 2013-02-22 22:12:38 - CROSS_BUILD_TESTING=YES TB --- 2013-02-22 22:12:38 - MAKEOBJDIRPREFIX=/obj TB --- 2013-02-22 22:12:38 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-02-22 22:12:38 - SRCCONF=/dev/null TB --- 2013-02-22 22:12:38 - TARGET=powerpc TB --- 2013-02-22 22:12:38 - TARGET_ARCH=powerpc TB --- 2013-02-22 22:12:38 - TZ=UTC TB --- 2013-02-22 22:12:38 - __MAKE_CONF=/dev/null TB --- 2013-02-22 22:12:38 - cd /src TB --- 2013-02-22 22:12:38 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Fri Feb 22 22:12:39 UTC 2013 >>> 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 [...] ld -b binary --no-warn-mismatch -d -warn-common -r -o mw88W8363.fwo mw88W8363.fw uudecode -o mwlboot.fw /src/sys/contrib/dev/mwl/mwlboot.fw.uu ld -b binary --no-warn-mismatch -d -warn-common -r -o mwlboot.fwo mwlboot.fw cc -c -O -pipe -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 -fdiagnostics-show-option -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 -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/dev/mxge/if_mxge.c /src/sys/dev/mxge/if_mxge.c: In function 'mxge_rx_csum': /src/sys/dev/mxge/if_mxge.c:2571: error: 'cap' undeclared (first use in this function) /src/sys/dev/mxge/if_mxge.c:2571: error: (Each undeclared identifier is reported only once /src/sys/dev/mxge/if_mxge.c:2571: error: for each function it appears in.) *** [if_mxge.o] Error code 1 Stop in /obj/powerpc.powerpc/src/sys/LINT. *** [buildkernel] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-02-22 22:17:25 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-02-22 22:17:25 - ERROR: failed to build LINT kernel TB --- 2013-02-22 22:17:25 - 7494.92 user 997.48 system 8781.84 real http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Fri Feb 22 22:18:03 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 97D53E54; Fri, 22 Feb 2013 22:18:03 +0000 (UTC) (envelope-from jmg@h2.funkthat.com) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) by mx1.freebsd.org (Postfix) with ESMTP id 60C80EF6; Fri, 22 Feb 2013 22:18:03 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id r1MMHoMC010829 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 22 Feb 2013 14:17:50 -0800 (PST) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id r1MMHotV010828; Fri, 22 Feb 2013 14:17:50 -0800 (PST) (envelope-from jmg) Date: Fri, 22 Feb 2013 14:17:50 -0800 From: John-Mark Gurney To: Dimitry Andric Subject: Re: r245741 (clang as cc) can not build binaries for GEODE processor Message-ID: <20130222221750.GB55866@funkthat.com> Mail-Followup-To: Dimitry Andric , lev@freebsd.org, freebsd-current References: <108875110.20130222104603@serebryakov.spb.ru> <51277EFE.4000703@andric.com> <15917508.20130222194954@serebryakov.spb.ru> <5127997A.2000901@andric.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5127997A.2000901@andric.com> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Fri, 22 Feb 2013 14:17:50 -0800 (PST) Cc: lev@freebsd.org, freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 22:18:03 -0000 Dimitry Andric wrote this message on Fri, Feb 22, 2013 at 17:14 +0100: > On 2013-02-22 16:49, Lev Serebryakov wrote: > >You wrote 22 ?????????????? 2013 ??., 18:21:50: > > > >DA> The default for FreeBSD on 32-bit x86 is i486, so maybe the problems > >are > >DA> caused by the -march=geode setting. If you disable that, do the > >DA> problems disappear? > > Problem is, that code compiled with "-march=geode" works. Code > >built without any "-march" at all (without CPUTYPE in configs) doesn't. > > It looks like clang or use "build system" CPU as default "-march" or > >issue some >= i686 commands without it. Or both :) > > Clang defaults to i486 (that is, on i386-unknown-freebsdXX arch), unless > you specify -march= or -mcpu= on the command line. > > Maybe samba, or any of its dependencies, attempts to be "smart", and > enables some custom CPU optimizations? Clang is broken when compiling for pre-PPro machines... it compiles include the cmov instruction. I sent email to -current about this earlier this month in: Subject: -current broken on pre-PPro machines (w/ work around) http://www.freebsd.org/cgi/mid.cgi?20130201170737.GP1410@funkthat.com The work around is to use gcc which will not emit the cmov instructions... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-current@FreeBSD.ORG Fri Feb 22 22:52:41 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 116D652F for ; Fri, 22 Feb 2013 22:52:41 +0000 (UTC) (envelope-from clbuisson@orange.fr) Received: from smtp.smtpout.orange.fr (smtp04.smtpout.orange.fr [80.12.242.126]) by mx1.freebsd.org (Postfix) with ESMTP id 978FA1000 for ; Fri, 22 Feb 2013 22:52:39 +0000 (UTC) Received: from localhost ([92.156.222.176]) by mwinf5d59 with ME id 3asW1l00H3oxrxG03asWeK; Fri, 22 Feb 2013 23:52:32 +0100 Message-ID: <5127F6AD.9020206@orange.fr> Date: Fri, 22 Feb 2013 23:52:29 +0100 From: Claude Buisson User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:10.0.12) Gecko/20130109 Thunderbird/10.0.12 MIME-Version: 1.0 To: Alexander Motin , Konstantin Belousov Subject: Re: DVD/CD lost after r246713 References: <5127E74A.4050205@FreeBSD.org> In-Reply-To: <5127E74A.4050205@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 22:52:41 -0000 On 02/22/2013 22:46, Alexander Motin wrote: > Hi. > > ATAPI devices on legacy ATA controllers were lost due to command timeout > caused by data underrun, caused by r246713. > > r247165 should fix the issue. > r247165 applied Problem solved (at least at the first reboot) Thanks to both of you !! BTW, an old intertwining of lines in dmesg is back: 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 ada0 at ata0 bus 0 scbus0 target 0 lun 0 ada0: ATA-8 device ada0: 100.000MB/s transfers (UDMA5, cd1 at ata1 bus 0 scbus1 target 1 lun 0 ^ cd1: Removable CD-ROM SCSI-0 device cd1: 33.300MB/s transfers (UDMA2, ATAPI 12bytes, PIO 65534bytes) cd1: Attempt to query device size failed: NOT READY, Medium not present - tray closed PIO 8192bytes) ^ ada0: 305245MB (625142448 512 byte sectors: 16H 63S/T 16383C) ada1 at ata0 bus 0 scbus0 target 1 lun 0 ada1: ATA-5 device ada1: 100.000MB/s transfers (UDMA5, PIO 8192bytes) ada1: 57220MB (117187500 512 byte sectors: 16H 63S/T 16383C) Claude Buisson From owner-freebsd-current@FreeBSD.ORG Fri Feb 22 23:00:22 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 224C36D1 for ; Fri, 22 Feb 2013 23:00:22 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-la0-x234.google.com (la-in-x0234.1e100.net [IPv6:2a00:1450:4010:c03::234]) by mx1.freebsd.org (Postfix) with ESMTP id 9BB6AEA for ; Fri, 22 Feb 2013 23:00:21 +0000 (UTC) Received: by mail-la0-f52.google.com with SMTP id fs12so1126662lab.11 for ; Fri, 22 Feb 2013 15:00:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=ogtTTw2L/0S8lqct7sPYTwhcu5+QkjqNMm8c1cHUI9k=; b=WCxTG8A286l7ZMIEC20fu3vVpNRFoeNYgrHMn+b9w1fTvlfHHrT51aZTgu6phr4H7V 2lJ5SPUv05kedDvwXt8LJKqPf1mG38QDCOJIBRH4A3qMZsa9mbixAi9r1/D8l+ntX/Cp m91+LivAwkdZEpOhUIN0olZf2wPz1dgc6lSbP0JgbGdUT4G5MyNsIxsXROyPqckSAime IZxd7Pz8GcEBjs88dUFtldD9OukGU1KwQFZr528xvY1+ChZ7ve+dsc3eVxCES2YGvAOn +FEWhgM2fZHHjqjgsqSMRT0tDOpAxwWveF8WgI7Y4RtoUBGVl6lF5lL6YrCgy8Oto2Ut zHFQ== X-Received: by 10.112.16.137 with SMTP id g9mr1557453lbd.119.1361574019326; Fri, 22 Feb 2013 15:00:19 -0800 (PST) Received: from mavbook.mavhome.dp.ua (mavhome.mavhome.dp.ua. [213.227.240.37]) by mx.google.com with ESMTPS id k15sm1372422lbd.6.2013.02.22.15.00.17 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 22 Feb 2013 15:00:18 -0800 (PST) Sender: Alexander Motin Message-ID: <5127F87F.3030605@FreeBSD.org> Date: Sat, 23 Feb 2013 01:00:15 +0200 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130125 Thunderbird/17.0.2 MIME-Version: 1.0 To: Claude Buisson Subject: Re: DVD/CD lost after r246713 References: <5127E74A.4050205@FreeBSD.org> <5127F6AD.9020206@orange.fr> In-Reply-To: <5127F6AD.9020206@orange.fr> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Konstantin Belousov , FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 23:00:22 -0000 On 23.02.2013 00:52, Claude Buisson wrote: > On 02/22/2013 22:46, Alexander Motin wrote: >> Hi. >> >> ATAPI devices on legacy ATA controllers were lost due to command timeout >> caused by data underrun, caused by r246713. >> >> r247165 should fix the issue. >> > > r247165 applied > > Problem solved (at least at the first reboot) > > Thanks to both of you !! > > BTW, an old intertwining of lines in dmesg is back: > > 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 > ada0 at ata0 bus 0 scbus0 target 0 lun 0 > ada0: ATA-8 device > ada0: 100.000MB/s transfers (UDMA5, cd1 at ata1 bus 0 scbus1 target 1 lun 0 > ^ > cd1: Removable CD-ROM SCSI-0 device > cd1: 33.300MB/s transfers (UDMA2, ATAPI 12bytes, PIO 65534bytes) > cd1: Attempt to query device size failed: NOT READY, Medium not present > - tray > closed > PIO 8192bytes) > ^ > ada0: 305245MB (625142448 512 byte sectors: 16H 63S/T 16383C) > ada1 at ata0 bus 0 scbus0 target 1 lun 0 > ada1: ATA-5 device > ada1: 100.000MB/s transfers (UDMA5, PIO 8192bytes) > ada1: 57220MB (117187500 512 byte sectors: 16H 63S/T 16383C) They never really went away. ada0 and cd1 in this example are living on different buses and so have separate locks, so nothing really prevents them to mix the messages. It rarely happens for disks, but CD tend to report capacity much longer, increasing mix chances. For USB devices chances are even higher, because they are often detected when CAM already gave up waiting and continued booting. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Fri Feb 22 23:55:36 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 4CC7B1A2; Fri, 22 Feb 2013 23:55:36 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.netplex.net (mail.netplex.net [204.213.176.10]) by mx1.freebsd.org (Postfix) with ESMTP id ECA5D286; Fri, 22 Feb 2013 23:55:35 +0000 (UTC) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.14.6/8.14.6/NETPLEX) with ESMTP id r1MNtYHa049444; Fri, 22 Feb 2013 18:55:34 -0500 X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.4.1 (mail.netplex.net [204.213.176.10]); Fri, 22 Feb 2013 18:55:34 -0500 (EST) Date: Fri, 22 Feb 2013 18:55:34 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Dimitry Andric Subject: Re: WITHOUT_CLANG_IS_CC: There and back again In-Reply-To: <5127E4C0.6060209@FreeBSD.org> Message-ID: References: <5127E4C0.6060209@FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Daniel Eischen List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 23:55:36 -0000 On Fri, 22 Feb 2013, Dimitry Andric wrote: > On 2013-02-22 22:30, Daniel Eischen wrote: >> In trying to debug an unrelated problem, I switched CC from Clang >> back to GCC. I had a -current kernel and world r247050 built and >> installed with Clang as the system compiler I have nothing special >> in /etc/make.conf: >> >> BATCH=yes >> WITH_NEW_XORG=true >> WITH_KMS=true >> WITH_PKGNG=yes >> PERL_VERSION=5.14.2 >> >> I added WITHOUT_CLANG_IS_CC=yes to this, then rebuilt kernel and >> world. I installed the kernel rebooted, everthing worked, so I >> then installed world. Installword stopped here: >> >> ===> libexec/rtld-elf (install) >> chflags -h noschg /usr/libexec/ld-elf.so.1 >> install -s -o root -g wheel -m 555 -C -b -fschg -S ld-elf.so.1 >> /libexec >> install -o root -g wheel -m 444 rtld.1.gz /usr/share/man/man1 >> *** [_maninstall] Signal 11 >> >> Stop in /opt/FreeBSD/current/src/libexec/rtld-elf. >> *** [realinstall] Error code 1 >> >> At that point my system was completely hosed. Every binary (/bin, >> /sbin, etc) would sig 11. I had to build a world on another >> system, then use /rescue to NFS mount the other system and >> copy over /libexec, /lib, and /usr/lib. This let me recover >> enough to svn up to r247164. remove WITHOUT_CLANG_IS_CC from >> /etc/make.conf, and build/install a working world. >> >> Is switching from Clang to GCC suppose to work? > > This might have had nothing to do with either clang or gcc. Between > r247012 and r247117, binutils was broken, and this apparently resulted > in various nasty problems. > > Maybe you can try it again, since you are now at r247164? Ahh, okay, thanks to you (& to Steve). I guess my timing was just off. I'll try it again. -- DE From owner-freebsd-current@FreeBSD.ORG Fri Feb 22 23:55:42 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 0543229F; Fri, 22 Feb 2013 23:55:42 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id D15A228A; Fri, 22 Feb 2013 23:55:41 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r1MNte2I001016; Fri, 22 Feb 2013 18:55:40 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r1MNteKa001015; Fri, 22 Feb 2013 23:55:40 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 22 Feb 2013 23:55:40 GMT Message-Id: <201302222355.r1MNteKa001015@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 , , Subject: [head tinderbox] failure on powerpc64/powerpc Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 23:55:42 -0000 TB --- 2013-02-22 20:55:41 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-02-22 20:55:41 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-02-22 20:55:41 - starting HEAD tinderbox run for powerpc64/powerpc TB --- 2013-02-22 20:55:41 - cleaning the object tree TB --- 2013-02-22 20:55:41 - /usr/local/bin/svn stat /src TB --- 2013-02-22 20:55:51 - At svn revision 247151 TB --- 2013-02-22 20:55:52 - building world TB --- 2013-02-22 20:55:52 - CROSS_BUILD_TESTING=YES TB --- 2013-02-22 20:55:52 - MAKEOBJDIRPREFIX=/obj TB --- 2013-02-22 20:55:52 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-02-22 20:55:52 - SRCCONF=/dev/null TB --- 2013-02-22 20:55:52 - TARGET=powerpc TB --- 2013-02-22 20:55:52 - TARGET_ARCH=powerpc64 TB --- 2013-02-22 20:55:52 - TZ=UTC TB --- 2013-02-22 20:55:52 - __MAKE_CONF=/dev/null TB --- 2013-02-22 20:55:52 - cd /src TB --- 2013-02-22 20:55:52 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Fri Feb 22 20:55:56 UTC 2013 >>> 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 Fri Feb 22 23:43:49 UTC 2013 TB --- 2013-02-22 23:43:49 - generating LINT kernel config TB --- 2013-02-22 23:43:49 - cd /src/sys/powerpc/conf TB --- 2013-02-22 23:43:49 - /usr/bin/make -B LINT TB --- 2013-02-22 23:43:49 - cd /src/sys/powerpc/conf TB --- 2013-02-22 23:43:49 - /usr/sbin/config -m LINT TB --- 2013-02-22 23:43:49 - skipping LINT kernel TB --- 2013-02-22 23:43:49 - cd /src/sys/powerpc/conf TB --- 2013-02-22 23:43:49 - /usr/sbin/config -m GENERIC TB --- 2013-02-22 23:43:49 - skipping GENERIC kernel TB --- 2013-02-22 23:43:49 - cd /src/sys/powerpc/conf TB --- 2013-02-22 23:43:49 - /usr/sbin/config -m GENERIC64 TB --- 2013-02-22 23:43:49 - building GENERIC64 kernel TB --- 2013-02-22 23:43:49 - CROSS_BUILD_TESTING=YES TB --- 2013-02-22 23:43:49 - MAKEOBJDIRPREFIX=/obj TB --- 2013-02-22 23:43:49 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-02-22 23:43:49 - SRCCONF=/dev/null TB --- 2013-02-22 23:43:49 - TARGET=powerpc TB --- 2013-02-22 23:43:49 - TARGET_ARCH=powerpc64 TB --- 2013-02-22 23:43:49 - TZ=UTC TB --- 2013-02-22 23:43:49 - __MAKE_CONF=/dev/null TB --- 2013-02-22 23:43:49 - cd /src TB --- 2013-02-22 23:43:49 - /usr/bin/make -B buildkernel KERNCONF=GENERIC64 >>> Kernel build for GENERIC64 started on Fri Feb 22 23:43:50 UTC 2013 >>> 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 [...] objcopy --strip-debug --add-gnu-debuglink=mw88W8363fw.ko.symbols mw88W8363fw.ko.debug mw88W8363fw.ko ===> mxge (all) ===> mxge/mxge (all) cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/powerpc.powerpc64/src/sys/GENERIC64/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -mlongcall -fno-omit-frame-pointer -I/obj/powerpc.powerpc64/src/sys/GENERIC64 -msoft-float -mno-altivec -mcall-aixdesc -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 -fdiagnostics-show-option -c /src/sys/modules/mxge/mxge/../../../dev/mxge/if_mxge.c /src/sys/modules/mxge/mxge/../../../dev/mxge/if_mxge.c: In function 'mxge_rx_csum': /src/sys/modules/mxge/mxge/../../../dev/mxge/if_mxge.c:2571: error: 'cap' undeclared (first use in this function) /src/sys/modules/mxge/mxge/../../../dev/mxge/if_mxge.c:2571: error: (Each undeclared identifier is reported only once /src/sys/modules/mxge/mxge/../../../dev/mxge/if_mxge.c:2571: error: for each function it appears in.) *** [if_mxge.o] Error code 1 Stop in /src/sys/modules/mxge/mxge. *** [all] Error code 1 Stop in /src/sys/modules/mxge. *** [all] Error code 1 Stop in /src/sys/modules. *** [modules-all] Error code 1 Stop in /obj/powerpc.powerpc64/src/sys/GENERIC64. *** [buildkernel] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-02-22 23:55:40 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-02-22 23:55:40 - ERROR: failed to build GENERIC64 kernel TB --- 2013-02-22 23:55:40 - 9509.30 user 1140.48 system 10799.50 real http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-powerpc64-powerpc.full From owner-freebsd-current@FreeBSD.ORG Sat Feb 23 22:55:50 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 6805D1D9 for ; Sat, 23 Feb 2013 22:55:50 +0000 (UTC) (envelope-from dimitry@andric.com) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) by mx1.freebsd.org (Postfix) with ESMTP id 2711591F for ; Sat, 23 Feb 2013 22:55:49 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:204:4bff:fe01:de8a] (spaceball.andric.com [IPv6:2001:7b8:3a7:0:204:4bff:fe01:de8a]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 36CEF5C43 for ; Sat, 23 Feb 2013 23:55:49 +0100 (CET) Message-ID: <512948FA.1020409@andric.com> Date: Sat, 23 Feb 2013 23:55:54 +0100 From: Dimitry Andric User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:19.0) Gecko/20130117 Thunderbird/19.0 MIME-Version: 1.0 To: freebsd-current Subject: Re: r245741 (clang as cc) can not build binaries for GEODE processor References: <108875110.20130222104603@serebryakov.spb.ru> <51277EFE.4000703@andric.com> <15917508.20130222194954@serebryakov.spb.ru> <5127997A.2000901@andric.com> <20130222221750.GB55866@funkthat.com> In-Reply-To: <20130222221750.GB55866@funkthat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 23 Feb 2013 22:55:50 -0000 On 2013-02-22 23:17, John-Mark Gurney wrote: ... > Clang is broken when compiling for pre-PPro machines... it compiles > include the cmov instruction. I sent email to -current about this > earlier this month in: > Subject: -current broken on pre-PPro machines (w/ work around) > > http://www.freebsd.org/cgi/mid.cgi?20130201170737.GP1410@funkthat.com > > The work around is to use gcc which will not emit the cmov instructions... Meanwhile, upstream fixed this, and I have just imported the fix in r247205. I hope all issues with pre-PPro machines are now solved. Can you please try to verify it? I do not have access to such hardware.