date:20130205

Re: kern/175822: [xen] FreeBSD 9.1 does not work with Xen 4.0

2013-02-05 Thread Egoitz Aurrekoetxea


Why not?? What's the exact problem you are perceiving??



On 04/02/13 21:55, lini...@freebsd.org wrote:

Old Synopsis: FreeBSD 9.1 does not work with Xen 4.0
New Synopsis: [xen] FreeBSD 9.1 does not work with Xen 4.0

Responsible-Changed-From-To: freebsd-bugs->freebsd-xen
Responsible-Changed-By: linimon
Responsible-Changed-When: Mon Feb 4 20:55:05 UTC 2013
Responsible-Changed-Why:
Over to maintainer(s).

http://www.freebsd.org/cgi/query-pr.cgi?pr=175822
___
freebsd-...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-xen
To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"



--
*Egoitz Aurrekoetxea*
Departamento de sistemas
Email: ego...@sarenet.es 
Phone: 94 - 420 94 00
SARENET
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

Re: kern/175759: Correct data types for fields of struct qm_trace{} from

2013-02-05 Thread Bruce Evans


On Tue, 5 Feb 2013, Gleb Smirnoff wrote:


On Tue, Feb 05, 2013 at 03:23:44AM +1100, Bruce Evans wrote:
B> On Mon, 4 Feb 2013, Gleb Smirnoff wrote:
B>
B> >   any additional comments for the attached patch. Is it ok from your
B> > viewpoint?
B>
B> > Index: queue.h
B> > ===
B> > --- queue.h  (revision 245741)
B> > +++ queue.h  (working copy)
B> > @@ -105,13 +105,14 @@
B> >  #ifdef QUEUE_MACRO_DEBUG
B> >  /* Store the last 2 places the queue element or head was altered */
B> >  struct qm_trace {
B> > -char * lastfile;
B> > -int lastline;
B> > -char * prevfile;
B> > -int prevline;
B> > +const char * lastfile;
B> > +unsigned long lastline;
B> > +const char * prevfile;
B> > +unsigned long prevline;
B> >  };
B>
B> Unsigned long is unnecessarily large.  It wastes space on 64-bit
B> arches.  The change doesn't change the wastage, because space was
B> already wasted on 64-bit arches by mispacking the struct (with
B> unnamed padding after the ints).  It changes the API unnecessarily
B> by changing signed variables to unsigned.  Sign variables are
B> easier to use, and changing to unsigned ones risks sign extension
B> bugs.
B>
B> According to your quote of the C standard, int32_t is enough.  (I
B> couldn't find anything directly about either the type or limit of
B> __LINE__ in the n869.txt draft of C99, but #line is limited to 2**31-1.
B> n1124.pdf says much the same, except it says that __LINE__ is an integer
B> constant where n869.txt says that __LINE__ is a decimal constant.  Both
B> of these seem to be wrong -- "decimal constants" include floating point
B> ones, and "integer constants" include octal and hex ones.)

As Andrey pointed out, int may be smaller than 2**31-1, that's why longs
are used.


Using int would only be a style bug, since FreeBSD has thousands if
not millions of other assumptions that ints are precisely 32 bits.  Anyway,
int32_t is large enough to hold 2**31-1.


I know that you prefer signed variables since they are easier to use,
but I prefer to explictily use unsigned in places where value can not
go below zero by its definition.


I used to prefer the latter, but know better now :-).

__LINE__ constant literals probably have type int or long, so it is
inconsistent to store them as unsigned.  But I can't think of any
useful expression where the behaviour would be different due to not
being unsigned -- the expression (p1->lastline - p2->lastline) might
be useful (if unsigned is not used to break it), but there is no
similar expression with 2 __LINE__ constants.

Bruce

Bruce
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

Re: kern/175759: Correct data types for fields of struct qm_trace{} from

2013-02-05 Thread Andrey Simonenko

The following reply was made to PR kern/175759; it has been noted by GNATS.

From: Andrey Simonenko 
To: Bruce Evans 
Cc: Gleb Smirnoff , freebsd-gnats-sub...@freebsd.org
Subject: Re: kern/175759: Correct data types for fields of struct qm_trace{}
 from 
Date: Tue, 5 Feb 2013 13:35:50 +0200

 Bruce Evans wrote:

 > Unsigned long is unnecessarily large.  It wastes space on 64-bit
 > arches.  The change doesn't change the wastage, because space was
 > already wasted on 64-bit arches by mispacking the struct (with
 > unnamed padding after the ints).  It changes the API unnecessarily
 > by changing signed variables to unsigned.  Sign variables are
 > easier to use, and changing to unsigned ones risks sign extension
 > bugs.

 I did not change order of fields to not change API, that's why
 bigger data type is used without changing size of that structure
 due to padding (at least for current sizes of int and long).

 > According to your quote of the C standard, int32_t is enough.  (I
 > couldn't find anything directly about either the type or limit of
 > __LINE__ in the n869.txt draft of C99, but #line is limited to 2**31-1.
 > n1124.pdf says much the same, except it says that __LINE__ is an integer
 > constant where n869.txt says that __LINE__ is a decimal constant.  Both
 > of these seem to be wrong -- "decimal constants" include floating point
 > ones, and "integer constants" include octal and hex ones.)

 Using [u]int32_t is enough. but it will require to include 
 if QUEUE_MACRO_DEBUG is defined.  By the way including just 
 is not enough because it does not include  for NULL.

 > The change preserves many style bugs:
 > - no prefix in member names
 > - member names not sorted inversely on size.  This gives the space
 >wastage.
 > - member names not indented
 > - space between '*' and member names.

 I'll repeat my idea how to improve QUEUE_MACRO_DEBUG, I did not
 post it in the first message, because it contains more changes:

 1. Allow a user to specify how many places to remember via QMD_TRACE_N.
by default this value is 2 (as now).

 2. Initialize struct qm_trace{} in *_INIT() and *_INITIALIZER(),
all initialized HEADs will have defined values in trace information.

 3. All trace information is saved in the info[QMD_TRACE_N] array, each
element is a structure with file name and line number.  If QMD_TRACE_N
is small, then this array can be split into two arrays to save space;
if QMD_TRACE_N is big, then one array will work faster because of CPU
cache lines.

 4. Lists' elements usually are not initialized (via bzero() for example),
so first entry in the info[] array will have some random index for
lists' elements.

 5. Using info[] array allows to specify arbitrary number of elements and
does not require to move data from one element into another (as now).
Position in array is (idx = (idx + 1) % QMD_TRACE_N) and during
debugging at will be necessary to look at info[idx] to find the most
recent change of HEAD or element.

 So, the main change is (I improved it, because of optimization):

 #defineQMD_TRACE(x) do {   
\
unsigned int __idx; \
__idx = ((x)->trace.idx + 1) % QMD_TRACE_N; \
(x)->trace.idx = __idx; \
(x)->trace.info[__idx].file = __FILE__; \
(x)->trace.info[__idx].line = __LINE__; \
 } while (0)

 It cam seem that this change makes QUEUE_MACRO_DEBUG more complex.
 Actually using info[] array with 2 elements (default value) should work
 faster than current implementation, since it does not require to copy
 data lastline -> prevline and lastfile -> prevfile, and that for(;;) in
 QMD_TRACE_INIT() for 1 element should be unrolled.

 Comparing generated code for QMD_TRACE under FreeBSD/amd64 9.1-STABLE
 by gcc from the base system and by clang-3.2 from Ports for the following
 file with -DQMD_TRACE_N=2^x (for non 2^x values the code will be more
 complex) and "-O2 -DQUEUE_MACRO_DEBUG":

 --
 #include 
 #ifdef QUEUE_DEFAULT
 # include 
 #else
 # include "queue.h"
 #endif

 struct foo {
int x;
int y;
TAILQ_ENTRY(foo) link;
 };

 TAILQ_HEAD(foo_tailq, foo);

 void
 func(struct foo_tailq *foo_tailq, struct foo *foo)
 {
TAILQ_REMOVE(foo_tailq, foo, link);
 }
 --

 1. GCC: 

Now:6 cmds: 4 mov to mem, 2 mov from mem.
New: 9-10 cmds: 3 mov to mem, 1 mov from mem, 5 cmds with regs.

 2. clang:

Now:6 cmds: 4 mov to mem, 2 mov from mem.
New:7 cmds: 3 mov to mem, 1 mov from mem, 3 cmds with regs.

 The diff can be found here:

 http://lists.freebsd.org/pipermail/freebsd-bugs/2013-February/051665.html

 It contains many lines, because I renamed some debugging related macro
 names to improve style, added debugging to TAILQ_SWAP(),

Re: kern/175822: [xen] FreeBSD 9.1 does not work with Xen 4.0

2013-02-05 Thread Jeroen van der Ham

Hi,

As I wrote before:
> This boots, and then goes into a loop printing "pudna: fpcurthread == 
> curthread xx times" when it tries to mount the filesystem.
> I have tried the exact same setup with the similar 9.0 DVD, and this boots 
> just fine.

The system is then not respsonsive, with just the message scrolling by with the 
number increasing.

Jeroen.


On 5 Feb 2013, at 10:59, Egoitz Aurrekoetxea  wrote:

> Why not?? What's the exact problem you are perceiving??
> 
> 
> 
> On 04/02/13 21:55, lini...@freebsd.org wrote:
>> Old Synopsis: FreeBSD 9.1 does not work with Xen 4.0
>> New Synopsis: [xen] FreeBSD 9.1 does not work with Xen 4.0
>> 
>> Responsible-Changed-From-To: freebsd-bugs->freebsd-xen
>> Responsible-Changed-By: linimon
>> Responsible-Changed-When: Mon Feb 4 20:55:05 UTC 2013
>> Responsible-Changed-Why:
>> Over to maintainer(s).
>> 
>> http://www.freebsd.org/cgi/query-pr.cgi?pr=175822
>> ___
>> freebsd-...@freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-xen
>> To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
> 
> 
> -- 
> *Egoitz Aurrekoetxea*
> Departamento de sistemas
> Email: ego...@sarenet.es 
> Phone: 94 - 420 94 00
> SARENET
> ___
> freebsd-...@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-xen
> To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"

___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

misc/175859: [patch] Update: lang/fsharp to 3.0.25

2013-02-05 Thread Youhei Kondou


>Number: 175859
>Category:   misc
>Synopsis:   [patch] Update: lang/fsharp to 3.0.25
>Confidential:   no
>Severity:   non-critical
>Priority:   low
>Responsible:freebsd-bugs
>State:  open
>Quarter:
>Keywords:   
>Date-Required:
>Class:  sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Tue Feb 05 11:50:00 UTC 2013
>Closed-Date:
>Last-Modified:
>Originator: Youhei Kondou
>Release:FreeBSD 9.1 amd64
>Organization:
>Environment:
>Description:
Update FSharp to 3.0.25
And change its license to Apache License 2

Since this update, this ports omit F# PowerPack
While F# 3.0 supports SGen on other OSs, F# 3.0 on FreeBSD only supports Boehm 
GC.
>How-To-Repeat:

>Fix:


Patch attached with submission follows:

# This is a shell archive.  Save it in a file, remove anything before
# this line, and then unpack it by entering "sh file".  Note, it may
# create directories; files and directories will be owned by you and
# have default permissions.
#
# This archive contains:
#
#   fsharp_Makefile.diff
#   fsharp_distinfo.diff
#   fsharp_pkg-descr.diff
#   fsharp_pkg-plist.diff
#   files/patch-configure.ac
#
echo x - fsharp_Makefile.diff
sed 's/^X//' >fsharp_Makefile.diff << '875aec91dfab26875ce847ecd792c79d'
X--- /usr/ports/lang/fsharp/Makefile2012-11-17 14:58:49.0 +0900
X+++ ./Makefile 2013-02-03 21:34:13.0 +0900
X@@ -1,70 +1,32 @@
X-# New ports collection makefile for:fsharp
X-# Date created:   2006 10 10
X-# Whom:   Phillip Neumann 
X-#
X+# Created by: Youhei Kondou 
X # $FreeBSD: ports/lang/fsharp/Makefile,v 1.7 2012/11/17 05:58:49 svnexp Exp $
X-#
X 
X PORTNAME= fsharp
X-PORTVERSION=  1.9.6.16
X-PORTREVISION= 4
X+PORTVERSION=  3.0.25
X+PORTREVISION= 0
X CATEGORIES=   lang
X-MASTER_SITES= 
http://download.microsoft.com/download/F/7/4/F74A3170-261C-4E8F-B1A8-2E352C61A89B/
X-DISTNAME= fsharp
X+MASTER_SITES= https://nodeload.github.com/fsharp/fsharp/tar.gz/
X+DISTNAME= ${PORTNAME}-${PORTVERSION}
X+DISTFILES=${PORTVERSION}
X+DIST_SUBDIR=  fsharp
X+ONLY_FOR_ARCHS= i386 amd64 powerpc
X 
X MAINTAINER=   p...@freebsd.org
X COMMENT=  Functional and object-oriented language for the .NET platform
X 
X-BUILD_DEPENDS=mono>=2:${PORTSDIR}/lang/mono\
X+BUILD_DEPENDS=mono>=3:${PORTSDIR}/lang/mono\
X   
${LOCALBASE}/lib/libgdiplus.a:${PORTSDIR}/x11-toolkits/libgdiplus
X-RUN_DEPENDS=  mono>=2:${PORTSDIR}/lang/mono\
X+RUN_DEPENDS=  mono>=3:${PORTSDIR}/lang/mono\
X   
${LOCALBASE}/lib/libgdiplus.a:${PORTSDIR}/x11-toolkits/libgdiplus
X 
X-PORTDIR=  lib/${PORTNAME}-${PORTVERSION}
X-PORTDOCS= LICENSE-fsharp.txt README-fsharp.html doc manual
X-PORTDATA= lib source
X-
X-PLIST_SUB=SUBDIR=${PORTDIR}
X-.if !defined(NOPORTDOCS)
X-PLIST_SUB+=   RMLIC="@comment "
X-.else
X-PLIST_SUB+=   RMLIC=""
X-.endif
X-
X-WRKSRC=   ${WRKDIR}/FSharp-${PORTVERSION}
X-USE_ZIP=  yes
X-RESTRICTED=   Microsoft Research Shared Source License Agreement
X-
X-AOT=  Core Compiler PowerPack
X-WRAPPERS= fsc fsi fslex fsyacc
X-
X-post-extract:
X-.for wrapper in ${WRAPPERS}
X-  @(${ECHO} '#!${SH}' > ${WRKDIR}/${wrapper})
X-  @(${ECHO} '${LOCALBASE}/bin/mono 
${PREFIX}/${PORTDIR}/bin/${wrapper}.exe $$*' >> ${WRKDIR}/${wrapper})
X-.endfor
X-
X-do-build:
X-
X-do-install:
X-.for asm in ${AOT}
X-  @ ${GACUTIL_INSTALL} ${WRKSRC}/bin/FSharp.${asm}.dll
X-.endfor
X-  @ ${MKDIR} ${PREFIX}/${PORTDIR} ${PREFIX}/${PORTDIR}/bin ${DOCSDIR}
X-  @ (cd ${WRKSRC} && ${COPYTREE_SHARE} "bin" ${PREFIX}/${PORTDIR}/)
X-  @ ${INSTALL_DATA} ${WRKSRC}/LICENSE-fsharp.txt ${DOCSDIR}/
X-.if !defined(NOPORTDOCS)
X-  @ ${MKDIR} ${DOCSDIR}/doc ${DOCSDIR}/manual
X-  @ (cd ${WRKSRC} && ${COPYTREE_SHARE} "doc manual" ${DOCSDIR}/)
X-  @ ${INSTALL_DATA} ${WRKSRC}/README-fsharp.html ${DOCSDIR}/
X-.endif
X-.if !defined(NOPORTDATA)
X-  @ ${MKDIR} ${DATADIR} ${DATADIR}/lib ${DATADIR}/source
X-  @ (cd ${WRKSRC} && ${COPYTREE_SHARE} "lib source" ${DATADIR}/)
X-.endif
X-.for wrapper in ${WRAPPERS}
X-  @ ${INSTALL_SCRIPT} ${WRKDIR}/${wrapper} ${PREFIX}/bin/
X-.endfor
X+USE_GMAKE=yes
X+USE_AUTOCONF= yes
X+LICENSE=  AL2
X+
X+pre-build:
X+  @(cd ${BUILD_WRKSRC}; ./autogen.sh)
X+post-install:
X+  @(chmod a+w ${LOCALBASE}/etc/mono/registry/last-btime)
X 
X-.include "${.CURDIR}/../../lang/mono/bsd.mono.mk"
X+.include "../mono/bsd.mono.mk"
X .include 
875aec91dfab26875ce847ecd792c79d
echo x - fsharp_distinfo.diff
sed 's/^X//' >fsharp_distinfo.diff << 'd0a6538122b61970ac924f4fb545c226'
X--- /usr/ports/lang/fsharp/distinfo2011-07-03 22:45:11.0 +0900
X+++ ./distinfo 2013-02-02 20:51:16.0 +0900
X@@ -1,2 +1,2 @@
X-SHA256 (fsharp.zip) = 
29c0691879a79ac84059d8a615508da4c7da27908e6bdbf5e3d85b53635b20a4
X-SIZE (fsharp.zip) = 21226155
X+SHA256 (fsharp/3.0.25) = 
1252ada65996f80d31e1bcc5c6718015ec5172c40288429d7dd2d2

Re: ports/175859: [patch] Update: lang/fsharp to 3.0.25

2013-02-05 Thread pgj

Synopsis: [patch] Update: lang/fsharp to 3.0.25

Responsible-Changed-From-To: freebsd-bugs->freebsd-ports-bugs
Responsible-Changed-By: pgj
Responsible-Changed-When: Tue Feb 5 12:00:45 UTC 2013
Responsible-Changed-Why: 
Fix category and (initial) responsible.

http://www.freebsd.org/cgi/query-pr.cgi?pr=175859
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

Re: kern/175759: Correct data types for fields of struct qm_trace{} from

2013-02-05 Thread Gleb Smirnoff

The following reply was made to PR kern/175759; it has been noted by GNATS.

From: Gleb Smirnoff 
To: Andrey Simonenko 
Cc: Bruce Evans , freebsd-gnats-sub...@freebsd.org
Subject: Re: kern/175759: Correct data types for fields of struct qm_trace{}
 from 
Date: Tue, 5 Feb 2013 16:02:18 +0400

 On Tue, Feb 05, 2013 at 01:35:50PM +0200, Andrey Simonenko wrote:
 A> > Unsigned long is unnecessarily large.  It wastes space on 64-bit
 A> > arches.  The change doesn't change the wastage, because space was
 A> > already wasted on 64-bit arches by mispacking the struct (with
 A> > unnamed padding after the ints).  It changes the API unnecessarily
 A> > by changing signed variables to unsigned.  Sign variables are
 A> > easier to use, and changing to unsigned ones risks sign extension
 A> > bugs.
 A> 
 A> I did not change order of fields to not change API, that's why
 A> bigger data type is used without changing size of that structure
 A> due to padding (at least for current sizes of int and long).

 We don't claim to be ABI stable for binaries that contain additional
 debugging information. They don't go into releases, and they alredy
 are incompatible with non-debugging binaries.

 So this isn't a problem.

 -- 
 Totus tuus, Glebius.
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

Re: kern/175822: [xen] FreeBSD 9.1 does not work with Xen 4.0

2013-02-05 Thread Mark Felder

On Tue, 05 Feb 2013 05:49:01 -0600, Jeroen van der Ham   
wrote:


The system is then not respsonsive, with just the message scrolling by  
with the number increasing.


If memory serves me this is a well known Xen regression that's solved by  
upgrading to Xen 4.1 or 4.2. I don't believe this is something that  
FreeBSD can fix.

___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

Re: kern/175822: [xen] FreeBSD 9.1 does not work with Xen 4.0

2013-02-05 Thread Jeroen van der Ham

Hi,

On 5 Feb 2013, at 14:46, Mark Felder  wrote:

> On Tue, 05 Feb 2013 05:49:01 -0600, Jeroen van der Ham  wrote:
> 
>> The system is then not respsonsive, with just the message scrolling by with 
>> the number increasing.
> 
> If memory serves me this is a well known Xen regression that's solved by 
> upgrading to Xen 4.1 or 4.2. I don't believe this is something that FreeBSD 
> can fix.

Do you have any references for that or something I could search for? I tried 
searching for "pudna: fpcurthread == curthread xx times", but that did not turn 
up much.

Jeroen.

___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

Re: conf/175751: FreeBSD 10.0-CURRENT: build failure with "device runfw"

2013-02-05 Thread Giorgos Keramidas

The following reply was made to PR conf/175751; it has been noted by GNATS.

From: Giorgos Keramidas 
To: Issei 
Cc: bug-follo...@freebsd.org, Andrew Thompson 
Subject: Re: conf/175751: FreeBSD 10.0-CURRENT: build failure with "device
 runfw"
Date: Tue, 5 Feb 2013 19:38:17 +0100

 On 2013-02-01 07:23, Issei  wrote:
 > >Number: 175751
 > >Category:   conf
 > >Synopsis:   FreeBSD 10.0-CURRENT: build failure with "device runfw"
 
 > On FreeBSD 10.0-CURRENT/amd64 or /arm, moist recent sources, adding
 > "device runfw" to kernel configuration file results in build error.
 
 > cc -O -pipe  -std=c99 -g -Wall -Wredundant-decls -Wnested-externs 
 > -Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline 
 > -Wcast-qual  -Wundef -Wno-pointer-sign -fformat-extensions  
 > -Wmissing-include-dirs -fdiagnostics-show-option   -nostdinc  -I. 
 > -I/usr/src/sys -I/usr/src/sys/contrib/altq -I/usr/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  -mno-thumb-interw ork -ffreestanding -c runfw.c
 > uudecode -o runfw /usr/src/sys/contrib/dev/run/rt2870.fw.uu
 > ld -b binary --no-warn-mismatch -d -warn-common -r  -o runfw.fwo
 > ld: no input files
 > *** [runfw.fwo] Error code 1
 
 Andrew (thompsa) may want to chime in and check this change for runfw
 too, so I've Cc:ed him in this thread too.
 
 This error is present for amd64 too.  I just tried rebuilding a kernel
 with this configuration file, and I can reproduce this error myself too:
 
 kobe:~$ cat -nv /usr/src/sys/amd64/conf/RUNFW
  1 #
  2 # RUNFW -- test kernel for device runfw
  3 #
  4 include GENERIC
  5 ident   RUNFW
  6
  7 device  firmware
  8 device  runfw
 kobe:~$
 
 And this is indeed the fix, because it breaks the circular dependency of
 'runfw -> runfw' in sys/conf/files.  Thanks!
 
 > Index: sys/conf/files
 > ===
 > --- sys/conf/files  (revision 246145)
 > +++ sys/conf/files  (working copy)
 > @@ -2208,19 +2208,19 @@
 >  dev/usb/wlan/if_rum.c  optional rum
 >  dev/usb/wlan/if_run.c  optional run
 >  runfw.coptional runfw   
 >   \
 > -   compile-with"${AWK} -f $S/tools/fw_stub.awk runfw:runfw -mrunfw 
 > -c${.TARGET}"   \
 > +   compile-with"${AWK} -f $S/tools/fw_stub.awk runfw.fw:runfw 
 > -mrunfw -c${.TARGET}"\
 > no-implicit-rule before-depend local 
 >   \
 > clean   "runfw.c"
 >  runfw.fwo  optional runfw   
 >   \
 > -   dependency  "runfw"  
 >   \
 > +   dependency  "runfw.fw"   
 >   \
 > compile-with"${NORMAL_FWO}"  
 >   \
 > no-implicit-rule 
 >   \
 > clean   "runfw.fwo"
 > -runfw  optional runfw   
 >   \
 > +runfw.fw   optional runfw   
 >   \
 > dependency  "$S/contrib/dev/run/rt2870.fw.uu"
 >   \
 > compile-with"${NORMAL_FW}"   
 >   \
 > no-obj no-implicit-rule  
 >   \
 > -   clean   "runfw"
 > +   clean   "runfw.fw"
 >  dev/usb/wlan/if_uath.c optional uath
 >  dev/usb/wlan/if_upgt.c optional upgt
 >  dev/usb/wlan/if_ural.c optional ural
 > Index: sys/modules/runfw/Makefile
 > ===
 > --- sys/modules/runfw/Makefile  (revision 246145)
 > +++ sys/modules/runfw/Makefile  (working copy)
 > @@ -1,11 +1,11 @@
 >  # $FreeBSD$
 >
 >  KMOD=  runfw
 > -FIRMWS=runfw:runfw:1
 > +FIRMWS=runfw.fw:runfw:1
 >
 > -CLEANFILES=runfw
 > +CLEANFILES=runfw.fw
 >
 > -runfw: ${.CURDIR}/../../contrib/dev/run/rt2870.fw.uu
 > +runfw.fw: ${.CURDIR}/../../contrib/dev/run/rt2870.fw.uu
 > uudecode -p ${.CURDIR}/../../contrib/dev/run/rt2870.fw.uu > 
 > ${.TARGET}
 >
 >  .include 
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

Re: kern/175864: [re] Intel MB D510MO, onboard ethernet not working after update to 9.1 [regression]

2013-02-05 Thread linimon

Old Synopsis: Intel MB D510MO, onboard ethernet not working after update to 9.1
New Synopsis: [re] Intel MB D510MO, onboard ethernet not working after update 
to 9.1 [regression]

Responsible-Changed-From-To: freebsd-amd64->freebsd-bugS
Responsible-Changed-By: linimon
Responsible-Changed-When: Wed Feb 6 01:55:58 UTC 2013
Responsible-Changed-Why: 
reclassify.

http://www.freebsd.org/cgi/query-pr.cgi?pr=175864
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

Re: kern/175864: [re] Intel MB D510MO, onboard ethernet not working after update to 9.1 [regression]

2013-02-05 Thread linimon

Synopsis: [re] Intel MB D510MO, onboard ethernet not working after update to 
9.1 [regression]

Responsible-Changed-From-To: freebsd-bugS->freebsd-net
Responsible-Changed-By: linimon
Responsible-Changed-When: Wed Feb 6 01:57:30 UTC 2013
Responsible-Changed-Why: 
er, forgot to reassign.

http://www.freebsd.org/cgi/query-pr.cgi?pr=175864
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

Re: kern/175759: [headers] [patch] Correct data types for fields of struct qm_trace{} from

2013-02-05 Thread glebius

Synopsis: [headers] [patch] Correct data types for fields of struct qm_trace{} 
from 

State-Changed-From-To: open->patched
State-Changed-By: glebius
State-Changed-When: Wed Feb 6 07:27:36 UTC 2013
State-Changed-Why: 
Committed, thanks.


Responsible-Changed-From-To: freebsd-bugs->glebius
Responsible-Changed-By: glebius
Responsible-Changed-When: Wed Feb 6 07:27:36 UTC 2013
Responsible-Changed-Why: 
Committed, thanks.

http://www.freebsd.org/cgi/query-pr.cgi?pr=175759
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

Re: kern/175822: [xen] FreeBSD 9.1 does not work with Xen 4.0

Re: kern/175759: Correct data types for fields of struct qm_trace{} from

Re: kern/175759: Correct data types for fields of struct qm_trace{} from

Re: kern/175822: [xen] FreeBSD 9.1 does not work with Xen 4.0

misc/175859: [patch] Update: lang/fsharp to 3.0.25

Re: ports/175859: [patch] Update: lang/fsharp to 3.0.25

Re: kern/175759: Correct data types for fields of struct qm_trace{} from

Re: kern/175822: [xen] FreeBSD 9.1 does not work with Xen 4.0

Re: kern/175822: [xen] FreeBSD 9.1 does not work with Xen 4.0

Re: conf/175751: FreeBSD 10.0-CURRENT: build failure with "device runfw"

Re: kern/175864: [re] Intel MB D510MO, onboard ethernet not working after update to 9.1 [regression]

Re: kern/175864: [re] Intel MB D510MO, onboard ethernet not working after update to 9.1 [regression]

Re: kern/175759: [headers] [patch] Correct data types for fields of struct qm_trace{} from

13 matches

Site Navigation

Mail list logo

Footer information