Does anyone regularly build HEAD with clang?
I've noticed that it's been broken for about a week as a result of: --- /usr/src/lib/libc/../../include/rpc/rpcb_clnt.h.orig2012-02-12 22:42:29.0 -0800 +++ /usr/src/lib/libc/../../include/rpc/rpcb_clnt.h 2012-02-12 22:41:27.0 -0800 @@ -66,7 +66,7 @@ const struct netconfig *, const struct netbuf *); extern bool_t rpcb_unset(const rpcprog_t, const rpcvers_t, const struct netconfig *); -extern rpcblist*rpcb_getmaps(const struct netconfig *, const char *); +extern struct rpcblist *rpcb_getmaps(const struct netconfig *, const char *); extern enum clnt_stat rpcb_rmtcall(const struct netconfig *, const char *, const rpcprog_t, const rpcvers_t, const rpcproc_t, Easy fix (I don't have a commit bit anymore or I'd just check it in), but it makes me wonder if anyone is building with clang on a regular basis or they'd have caught this one quickly. Thanks, - Jordan ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Mesa 8.0 Info
http://cgit.freedesktop.org/mesa/mesa/commit/?id=d01de08c4c84f0406a23ce38e1c9c163ed2b91bc ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
print/ghostscript9: ./base/sjpx_openjpeg.c:169: error: too many arguments to function
This arise today when updating ghostscript9-9.04 to ghostscript9-9.05: cc -DHAVE_MKSTEMP -DHAVE_FONTCONFIG -DHAVE_LIBIDN -DHAVE_SETLOCALE -DHAVE_SSE2 -DHAVE_DBUS -O2 -pipe -O2 -fno-strict-aliasing -pipe -march=native -fPIC -DUPD_SIGNAL=0 -I. -I/usr/ports/print/ghostscript9/work/ghostscript-9.05/lcms/include -I/usr/local/include/libpng -I/usr/local/include -I/usr/local/include/freetype2 -Wall -Wstrict-prototypes -Wundef -Wmissing-declarations -Wmissing-prototypes -Wwrite-strings -Wno-strict-aliasing -Wdeclaration-after-statement -fno-builtin -fno-common -DHAVE_STDINT_H=1 -DHAVE_SYS_TIME_H=1 -DGX_COLOR_INDEX_TYPE=unsigned long int -O2 -pipe -O2 -fno-strict-aliasing -pipe -march=native -DUSE_LIBICONV_GNU -DUSE_LIBPAPER -I/usr/local/include -DGS_DEVS_SHARED -DGS_DEVS_SHARED_DIR=\/usr/local/lib/ghostscript/9.05\ -Iopenjpeg/libopenjpeg/.. -Iopenjpeg/libopenjpeg -I./soobj -I./base -DUSE_OPENJPEG_JP2 -ffast-math -DOPJ_STATIC -std=c99 -o ./soobj/sjpx_openjpeg.o \ -c -DOPJ_STATIC ./base/sjpx_openjpeg.c ./base/sjpx_openjpeg.c: In function 'decode_image': ./base/sjpx_openjpeg.c:169: error: too many arguments to function 'opj_decode' ./base/sjpx_openjpeg.c:205: error: 'opj_image_comp_t' has no member named 'typ' ./base/sjpx_openjpeg.c:205: error: 'CTYPE_COLOR' undeclared (first use in this function) ./base/sjpx_openjpeg.c:205: error: (Each undeclared identifier is reported only once ./base/sjpx_openjpeg.c:205: error: for each function it appears in.) ./base/sjpx_openjpeg.c:207: error: 'opj_image_comp_t' has no member named 'typ' ./base/sjpx_openjpeg.c:207: error: 'CTYPE_OPACITY' undeclared (first use in this function) ./base/sjpx_openjpeg.c:217: error: 'CLRSPC_CMYK' undeclared (first use in this function) ./base/sjpx_openjpeg.c:250: error: 'opj_image_t' has no member named 'has_palette' ./base/sjpx_openjpeg.c:257: error: 'CLRSPC_EYCC' undeclared (first use in this function) gmake[2]: *** [soobj/sjpx_openjpeg.o] Error 1 gmake[2]: Leaving directory `/usr/ports/print/ghostscript9/work/ghostscript-9.05' gmake[1]: *** [so-subtarget] Error 2 gmake[1]: Leaving directory `/usr/ports/print/ghostscript9/work/ghostscript-9.05' gmake: *** [so] Error 2 *** Error code 1 Stop in /usr/ports/print/ghostscript9. *** Error code 1 Stop in /usr/ports/print/ghostscript9. === make failed for print/ghostscript9 === Aborting update Terminated === You can restart from the point of failure with this command line: portmaster flags print/ghostscript9 signature.asc Description: OpenPGP digital signature
Re: Does anyone regularly build HEAD with clang?
Yes, we do have a buildbots, ie.: http://llvm-amd64.freebsd.your.org:8010/builders/freebsd-clang-amd64/ On Sun, Feb 12, 2012 at 09:42:47PM -0800, Jordan K. Hubbard wrote: I've noticed that it's been broken for about a week as a result of: --- /usr/src/lib/libc/../../include/rpc/rpcb_clnt.h.orig 2012-02-12 22:42:29.0 -0800 +++ /usr/src/lib/libc/../../include/rpc/rpcb_clnt.h 2012-02-12 22:41:27.0 -0800 @@ -66,7 +66,7 @@ const struct netconfig *, const struct netbuf *); extern bool_t rpcb_unset(const rpcprog_t, const rpcvers_t, const struct netconfig *); -extern rpcblist *rpcb_getmaps(const struct netconfig *, const char *); +extern struct rpcblist *rpcb_getmaps(const struct netconfig *, const char *); extern enum clnt_stat rpcb_rmtcall(const struct netconfig *, const char *, const rpcprog_t, const rpcvers_t, const rpcproc_t, Easy fix (I don't have a commit bit anymore or I'd just check it in), but it makes me wonder if anyone is building with clang on a regular basis or they'd have caught this one quickly. Thanks, - Jordan ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
loader is aborted with 'out of memory'
I got the following error of the current loader if I put the xxx_after line into loader.conf to wait a key after load the xxx module. --- Error: out of memory Module xxx Error executing read -p Press Enter Aborted! --- The loader.conf is: xxx_load=YES xxx_after=read -p \Press Enter\ Does anyone know what is wrong? --- TAKAHASHI Yoshihiro n...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Enhancing the user experience with tcsh
Alex Keda wrote: On 10.02.2012 21:07, Chuck Burns wrote: set prompt = [%n@%m]%c04%# it's not needed need some as alias ll ls -lAhG alias ls ls -G set autolist = TAB bindkey \e[3~ delete-char . and other _really_ necessary settings This can be as simple as defining CLICOLOR. However colors of ls -G wouldn't match with default color set in LSCOLORS so correct LS_COLORS string would be needed too. -- Sphinx of black quartz judge my vow. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Enhancing the user experience with tcsh
Chris Rees wrote: set prompt = [%n@%m]%c04%# it's not needed need some as alias ll ls -lAhG alias ls ls -G Lscolors are an abomination. -F or nothing at all is better; remember some people will use white xterms etc. Yeah, a +1 for me. Plain xterm with colorized output makes you feel like using fork to pry your eyes out... That's surely not a good default. -- Sphinx of black quartz judge my vow. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [CFT] Xorg Upgrade 7.5.2
Adam K Kirchhoff wrote: I've run it for a while now and am actually having a pretty serious issue: http://thorn.visualtech.com/screenshot.jpg As you can see, that big window on the right monitor (though certainly doesn't limit itself to just that screen) is almost entirely corrupt. It's an xfce4 Terminal, though this can happen with nearly any window, and happens both with compositing enabled or disabled. Getting the window to redraw somehow (either by highlighting all the text or resizing it) will fix tha areas that are redrawn. The problem is most often triggered by moving the window around, or moving other windows around on top of it. Unfortunately, it makes X barely usable. I'm not involved with testing new version but I can second this issue with current version in ports. When I managed to add my TV as a second screen XFCE draws garbage instead of desktop on the second screen. E17 however worked like a charm. I mean... you sure this is not an XFCE issue? -- Sphinx of black quartz judge my vow. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Mesa 8.0 Info
В Mon, 13 Feb 2012 00:34:36 -0800 vehemens vehem...@verizon.net пишет: http://cgit.freedesktop.org/mesa/mesa/commit/?id=d01de08c4c84f0406a23ce38e1c9c163ed2b91bc Well, of course! Haiku is much more meaningful project than FreeBSD! ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [CFT] Xorg Upgrade 7.5.2
On Mon, 13 Feb 2012 15:39:21 +0200 Volodymyr Kostyrko c.kw...@gmail.com wrote: Adam K Kirchhoff wrote: I've run it for a while now and am actually having a pretty serious issue: http://thorn.visualtech.com/screenshot.jpg As you can see, that big window on the right monitor (though certainly doesn't limit itself to just that screen) is almost entirely corrupt. It's an xfce4 Terminal, though this can happen with nearly any window, and happens both with compositing enabled or disabled. Getting the window to redraw somehow (either by highlighting all the text or resizing it) will fix tha areas that are redrawn. The problem is most often triggered by moving the window around, or moving other windows around on top of it. Unfortunately, it makes X barely usable. I'm not involved with testing new version but I can second this issue with current version in ports. When I managed to add my TV as a second screen XFCE draws garbage instead of desktop on the second screen. E17 however worked like a charm. I mean... you sure this is not an XFCE issue? Yes, I'm quite sure. This happens with xfce4, kde4 and just plain openbox. I've seen similar distortion (though not quite the same as what's in my screenshot) from the radeon driver even before testing this new version. I will, however, confirm these various corruptions with the radeon driver happen less with E17. I've also seen the same thing on OpenBSD. The distortion I've seen with the driver/Xorg from ports I've also seen on Slackware when disabling KMS, so I'm quite convinced this is a UMS-specific bug. Adam ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Does anyone regularly build HEAD with clang?
On 2012-02-13 06:42, Jordan K. Hubbard wrote: I've noticed that it's been broken for about a week as a result of: --- /usr/src/lib/libc/../../include/rpc/rpcb_clnt.h.orig 2012-02-12 22:42:29.0 -0800 +++ /usr/src/lib/libc/../../include/rpc/rpcb_clnt.h 2012-02-12 22:41:27.0 -0800 @@ -66,7 +66,7 @@ const struct netconfig *, const struct netbuf *); extern bool_t rpcb_unset(const rpcprog_t, const rpcvers_t, const struct netconfig *); -extern rpcblist *rpcb_getmaps(const struct netconfig *, const char *); +extern struct rpcblist *rpcb_getmaps(const struct netconfig *, const char *); extern enum clnt_stat rpcb_rmtcall(const struct netconfig *, const char *, const rpcprog_t, const rpcvers_t, const rpcproc_t, Easy fix (I don't have a commit bit anymore or I'd just check it in), but it makes me wonder if anyone is building with clang on a regular basis or they'd have caught this one quickly. I build it very regularly, and there are several buildbots that also build it continously (though they currently don't spam the mailing lists). For me, and the buildbots, head builds just fine with clang, though. What was the exact error you got during buildworld? In any case, it is likely your problem is caused by my recent fixes to rpcgen, which make it use the C preprocessor built during buildworld, instead of always using /usr/bin/cpp. What are your CC, CXX and CPP settings in make.conf? And can you please post the file: /usr/obj/usr/src/tmp/usr/include/rpc/rpcb_prot.h which should have been generated by rpcgen during build. It is probably missing the line: typedef struct rp__list rpcblist; ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [CFT] Xorg Upgrade 7.5.2
Adam K Kirchhoff wrote: I've run it for a while now and am actually having a pretty serious issue: http://thorn.visualtech.com/screenshot.jpg As you can see, that big window on the right monitor (though certainly doesn't limit itself to just that screen) is almost entirely corrupt. It's an xfce4 Terminal, though this can happen with nearly any window, and happens both with compositing enabled or disabled. Getting the window to redraw somehow (either by highlighting all the text or resizing it) will fix tha areas that are redrawn. The problem is most often triggered by moving the window around, or moving other windows around on top of it. Unfortunately, it makes X barely usable. I'm not involved with testing new version but I can second this issue with current version in ports. When I managed to add my TV as a second screen XFCE draws garbage instead of desktop on the second screen. E17 however worked like a charm. I mean... you sure this is not an XFCE issue? Yes, I'm quite sure. This happens with xfce4, kde4 and just plain openbox. I've seen similar distortion (though not quite the same as what's in my screenshot) from the radeon driver even before testing this new version. I will, however, confirm these various corruptions with the radeon driver happen less with E17. Yep, radeon here too. -- Sphinx of black quartz judge my vow. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [ptrace] please review follow fork/exec changes
I looked at the orphan.patch. Am I right that the orphans are the real childs of the process which are temporarily reparented to the debugger ? Whatever they are, a comment should be added to proc.h describing what does it mean. Please provide me with a test case that demonstrates the issue solved by the change. The new LIST_FOREACH(q-p_orphans) body is copy/pasted, together with the comments, from the LIST_FOREACH(q-p_children). Can the common code be moved into some function ? Shouldn't there be some assertion in proc_reparent() for the case when we remove child from the orphans list, that the child is no longer debugged ? Why in proc_reparent(), in the case of P_TRACED child, you do PROC_UNLOC/PROC_LOCK ? It seems that now wait4(2) can be called from the real (non-debugger) parent first and result in the call to proc_reap(), isn't it ? We would then just reparent the child back to the caller, still leaving the zombie and confusing debugger. pgpZfjlKmTwOb.pgp Description: PGP signature
Re: loader is aborted with 'out of memory'
On 2/13/2012 7:06 AM, TAKAHASHI Yoshihiro wrote: I got the following error of the current loader if I put the xxx_after line into loader.conf to wait a key after load the xxx module. --- Error: out of memory Module xxx Error executing read -p Press Enter Aborted! --- The loader.conf is: xxx_load=YES xxx_after=read -p \Press Enter\ Does anyone know what is wrong? --- TAKAHASHI Yoshihiron...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org Uhm, yea.. it's having trouble executing the command 'read -p Press Enter' My guess is, it can't run that command read. Perhaps it needs a full path, or something? grasping at straws on the fix you want, but the error message is pretty clear.. and without the _after line I'm betting it would boot fine. -- Chuck Burns The Southern Libertarian (owner/editor) http://www.thesouthernlibertarian.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Does anyone regularly build HEAD with clang?
On Feb 13, 2012, at 5:59 AM, Dimitry Andric wrote: I build it very regularly, and there are several buildbots that also build it continously (though they currently don't spam the mailing lists). For me, and the buildbots, head builds just fine with clang, though. What was the exact error you got during buildworld? For that one, the error was: clang -O2 -pipe -I/usr/src/lib/libc/include -I/usr/src/lib/libc/../../include -I/usr/src/lib/libc/i386 -DNLS -D__DBINTERFACE_PRIVATE -I/usr/src/lib/libc/../../contrib/gdtoa -DINET6 -I/usr/obj/usr/src/lib/libc -I/usr/src/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE -I/usr/src/lib/libc/../../contrib/tzcode/stdtime -I/usr/src/lib/libc/stdtime -I/usr/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/usr/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99 -fstack-protector -Wsystem-headers -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-conversion -Wno-switch-enum -Wno-empty-body -c /usr/src/lib/libc/rpc/clnt_bcast.c -o clnt_bcast.o In file included from /usr/src/lib/libc/rpc/clnt_bcast.c:61: In file included from /usr/src/lib/libc/../../include/rpc/rpc.h:76: /usr/src/lib/libc/../../include/rpc/rpcb_clnt.h:69:8: error: unknown type name 'rpcblist' extern rpcblist *rpcb_getmaps(const struct netconfig *, const char *); ^ Though having made my small patch, I've now moved on to: ./contrib/gdtoa -DINET6 -I/usr/obj/usr/src/lib/libc -I/usr/src/lib/libc/resolv - D_ACL_PRIVATE -DPOSIX_MISTAKE -I/usr/src/lib/libc/../../contrib/tzcode/stdtime - I/usr/src/lib/libc/stdtime -I/usr/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DD ES_BUILTIN -I/usr/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gn u99 -fstack-protector -Wsystem-headers -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-e quality -Wno-unused-function -Wno-conversion -Wno-switch-enum -Wno-empty-body -c /usr/src/lib/libc/rpc/clnt_bcast.c -o clnt_bcast.o /usr/src/lib/libc/rpc/clnt_bcast.c:273:28: error: variable has incomplete type ' struct r_rpcb_rmtcallargs' struct r_rpcb_rmtcallargs barg; /* Remote arguments */ ^ During stage 4.2: building libraries. What are your CC, CXX and CPP settings in make.conf? And can you please post the file: My make.conf is pretty bleeding edge, tailored to seeing how far along FreeBSD is to making the full transition away from gcc and other GPL'd bits. I'll attach it. /usr/obj/usr/src/tmp/usr/include/rpc/rpcb_prot.h Also attached. Thanks for the prompt reply! - Jordan ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Does anyone regularly build HEAD with clang?
On 2012-02-13 17:56, Jordan K. Hubbard wrote: On Feb 13, 2012, at 5:59 AM, Dimitry Andric wrote: I build it very regularly, and there are several buildbots that also build it continously (though they currently don't spam the mailing lists). For me, and the buildbots, head builds just fine with clang, though. What was the exact error you got during buildworld? For that one, the error was: clang -O2 -pipe -I/usr/src/lib/libc/include -I/usr/src/lib/libc/../../include -I/usr/src/lib/libc/i386 -DNLS -D__DBINTERFACE_PRIVATE -I/usr/src/lib/libc/../../contrib/gdtoa -DINET6 -I/usr/obj/usr/src/lib/libc -I/usr/src/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE -I/usr/src/lib/libc/../../contrib/tzcode/stdtime -I/usr/src/lib/libc/stdtime -I/usr/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/usr/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99 -fstack-protector -Wsystem-headers -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-conversion -Wno-switch-enum -Wno-empty-body -c /usr/src/lib/libc/rpc/clnt_bcast.c -o clnt_bcast.o In file included from /usr/src/lib/libc/rpc/clnt_bcast.c:61: In file included from /usr/src/lib/libc/../../include/rpc/rpc.h:76: /usr/src/lib/libc/../../include/rpc/rpcb_clnt.h:69:8: error: unknown type name 'rpcblist' extern rpcblist *rpcb_getmaps(const struct netconfig *, const char *); ^ Though having made my small patch, I've now moved on to: ./contrib/gdtoa -DINET6 -I/usr/obj/usr/src/lib/libc -I/usr/src/lib/libc/resolv - D_ACL_PRIVATE -DPOSIX_MISTAKE -I/usr/src/lib/libc/../../contrib/tzcode/stdtime - I/usr/src/lib/libc/stdtime -I/usr/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DD ES_BUILTIN -I/usr/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gn u99 -fstack-protector -Wsystem-headers -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-e quality -Wno-unused-function -Wno-conversion -Wno-switch-enum -Wno-empty-body -c /usr/src/lib/libc/rpc/clnt_bcast.c -o clnt_bcast.o /usr/src/lib/libc/rpc/clnt_bcast.c:273:28: error: variable has incomplete type ' struct r_rpcb_rmtcallargs' struct r_rpcb_rmtcallargs barg; /* Remote arguments */ ^ During stage 4.2: building libraries. What are your CC, CXX and CPP settings in make.conf? And can you please post the file: My make.conf is pretty bleeding edge, tailored to seeing how far along FreeBSD is to making the full transition away from gcc and other GPL'd bits. I'll attach it. /usr/obj/usr/src/tmp/usr/include/rpc/rpcb_prot.h Also attached. Thanks for the prompt reply! - Jordan The ML ate the attachments. Either attach them as text/plain or post them online somewhere. Regards! -- Niclas ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Mesa 8.0 Info
On 02/13/12 09:34, vehemens wrote: http://cgit.freedesktop.org/mesa/mesa/commit/?id=d01de08c4c84f0406a23ce38e1c9c163ed2b91bc Interesting to read that FreeBSD has now explicitely been extracted from the description file :-( signature.asc Description: OpenPGP digital signature
Re: Mesa 8.0 Info
В Mon, 13 Feb 2012 19:02:30 +0100 O. Hartmann ohart...@zedat.fu-berlin.de пишет: On 02/13/12 09:34, vehemens wrote: http://cgit.freedesktop.org/mesa/mesa/commit/?id=d01de08c4c84f0406a23ce38e1c9c163ed2b91bc Interesting to read that FreeBSD has now explicitely been extracted from the description file :-( The impression that someone really wants to destroy FreeBSD... ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Mesa 8.0 Info
On Mon, Feb 13, 2012 at 10:02 AM, O. Hartmann ohart...@zedat.fu-berlin.de wrote: On 02/13/12 09:34, vehemens wrote: http://cgit.freedesktop.org/mesa/mesa/commit/?id=d01de08c4c84f0406a23ce38e1c9c163ed2b91bc Interesting to read that FreeBSD has now explicitly been extracted from the description file :-( Well, the section listing FreeBSD was totally removed, so all OSes were explicitly removed and replaced with text describing APIs. Since those are mostly orthogonal, I'd say that they simply removed references to any specific OS with DRI support. -- R. Kevin Oberman, Network Engineer E-mail: kob6...@gmail.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: MCA UNCOR error
On Sunday, February 12, 2012 4:55:49 am TAKAHASHI Yoshihiro wrote: I get the following error and kernel panic on my pc98 at the boot time. MCA: Bank 2, Status 0xb614 MCA: Global Cap 0x0005, Status 0x0004 MCA: Vendor GenuineIntel, ID 0x616, APIC ID 0 MCA: CPU 0 UNCOR PCC no error MCA: Address 0x3446ff003446ff When I disable MCA with hw.mca.enabled=0 on loader prompt, the machine works fine. Does it mean my pc98 is broken? Or other isssue? It's spec is: FreeBSD 10.0-CURRENT #5: Thu Feb 9 13:18:22 UTC 2012 CPU: Pentium Pro (198.95-MHz 686-class CPU) Origin = GenuineIntel Id = 0x616 Family = 6 Model = 1 Stepping = 6 Features=0xf9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV real memory = 134217728 (128 MB) avail memory = 120471552 (114 MB) Interesting, that is odd to get an error with no error code. Can you tell from the stack trace if your CPU actually raised a machine check exception (trap 28)? -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Mesa 8.0 Info
On 2012-02-13 19:32, Kevin Oberman wrote: On Mon, Feb 13, 2012 at 10:02 AM, O. Hartmann ohart...@zedat.fu-berlin.de wrote: On 02/13/12 09:34, vehemens wrote: http://cgit.freedesktop.org/mesa/mesa/commit/?id=d01de08c4c84f0406a23ce38e1c9c163ed2b91bc Interesting to read that FreeBSD has now explicitly been extracted from the description file :-( Well, the section listing FreeBSD was totally removed, so all OSes were explicitly removed and replaced with text describing APIs. Since those are mostly orthogonal, I'd say that they simply removed references to any specific OS with DRI support. For those of you interested in trying out MESA 8.0 it is in the experimental xorg repository: http://trillian.chruetertee.ch/ports/browser It is however not part of the CFT miwi sent a week or so ago, since i was released after that. Feel free to try it out though, and report success/failiure. Regards! -- Niclas ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Mesa 8.0 Info
В Mon, 13 Feb 2012 19:57:42 +0100 Niclas Zeising zeis...@daemonic.se пишет: On 2012-02-13 19:32, Kevin Oberman wrote: On Mon, Feb 13, 2012 at 10:02 AM, O. Hartmann ohart...@zedat.fu-berlin.de wrote: On 02/13/12 09:34, vehemens wrote: http://cgit.freedesktop.org/mesa/mesa/commit/?id=d01de08c4c84f0406a23ce38e1c9c163ed2b91bc Interesting to read that FreeBSD has now explicitly been extracted from the description file :-( Well, the section listing FreeBSD was totally removed, so all OSes were explicitly removed and replaced with text describing APIs. Since those are mostly orthogonal, I'd say that they simply removed references to any specific OS with DRI support. For those of you interested in trying out MESA 8.0 it is in the experimental xorg repository: http://trillian.chruetertee.ch/ports/browser It is however not part of the CFT miwi sent a week or so ago, since i was released after that. Feel free to try it out though, and report success/failiure. Regards! Where did you see there is Mesa 8.0? Can you give my a direct link? ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Mesa 8.0 Info
В Mon, 13 Feb 2012 19:57:42 +0100 Niclas Zeising zeis...@daemonic.se пишет: On 2012-02-13 19:32, Kevin Oberman wrote: On Mon, Feb 13, 2012 at 10:02 AM, O. Hartmann ohart...@zedat.fu-berlin.de wrote: On 02/13/12 09:34, vehemens wrote: http://cgit.freedesktop.org/mesa/mesa/commit/?id=d01de08c4c84f0406a23ce38e1c9c163ed2b91bc Interesting to read that FreeBSD has now explicitly been extracted from the description file :-( Well, the section listing FreeBSD was totally removed, so all OSes were explicitly removed and replaced with text describing APIs. Since those are mostly orthogonal, I'd say that they simply removed references to any specific OS with DRI support. For those of you interested in trying out MESA 8.0 it is in the experimental xorg repository: http://trillian.chruetertee.ch/ports/browser It is however not part of the CFT miwi sent a week or so ago, since i was released after that. Feel free to try it out though, and report success/failiure. Regards! Sorry - had already seen, it is in the trunk :( ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Does anyone regularly build HEAD with clang?
I was having the exact same issue. The fix? 'CPP=clang-cpp' instead of 'CPP=clang -E' in your make.conf. -Brandon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Mesa 8.0 Info
В Mon, 13 Feb 2012 20:43:54 +0100 Niclas Zeising zeis...@daemonic.se пишет: On 2012-02-13 20:29, Ivan Klymenko wrote: В Mon, 13 Feb 2012 19:57:42 +0100 Niclas Zeising zeis...@daemonic.se пишет: On 2012-02-13 19:32, Kevin Oberman wrote: On Mon, Feb 13, 2012 at 10:02 AM, O. Hartmann ohart...@zedat.fu-berlin.de wrote: On 02/13/12 09:34, vehemens wrote: http://cgit.freedesktop.org/mesa/mesa/commit/?id=d01de08c4c84f0406a23ce38e1c9c163ed2b91bc Interesting to read that FreeBSD has now explicitly been extracted from the description file :-( Well, the section listing FreeBSD was totally removed, so all OSes were explicitly removed and replaced with text describing APIs. Since those are mostly orthogonal, I'd say that they simply removed references to any specific OS with DRI support. For those of you interested in trying out MESA 8.0 it is in the experimental xorg repository: http://trillian.chruetertee.ch/ports/browser It is however not part of the CFT miwi sent a week or so ago, since i was released after that. Feel free to try it out though, and report success/failiure. Regards! Where did you see there is Mesa 8.0? Can you give my a direct link? Here for instance: https://trillian.chruetertee.ch/ports/browser/trunk/graphics/libGL The whole repo is found here: https://trillian.chruetertee.ch/ports/browser/trunk?order=name Have a look at the wiki here http://wiki.freebsd.org/Xorg before playing with it though. To get the new MESA you need the KMS patch, instructions here http://wiki.freebsd.org/Intel_GPU as well as a resonably recent intel graphics card (Radeon might work, but that is unlikely.) Regards! Thank you - I know, just a few days ago, there was no Mesa 8.0 in the repository ... ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Mesa 8.0 Info
On 2012-02-13 20:29, Ivan Klymenko wrote: В Mon, 13 Feb 2012 19:57:42 +0100 Niclas Zeising zeis...@daemonic.se пишет: On 2012-02-13 19:32, Kevin Oberman wrote: On Mon, Feb 13, 2012 at 10:02 AM, O. Hartmann ohart...@zedat.fu-berlin.de wrote: On 02/13/12 09:34, vehemens wrote: http://cgit.freedesktop.org/mesa/mesa/commit/?id=d01de08c4c84f0406a23ce38e1c9c163ed2b91bc Interesting to read that FreeBSD has now explicitly been extracted from the description file :-( Well, the section listing FreeBSD was totally removed, so all OSes were explicitly removed and replaced with text describing APIs. Since those are mostly orthogonal, I'd say that they simply removed references to any specific OS with DRI support. For those of you interested in trying out MESA 8.0 it is in the experimental xorg repository: http://trillian.chruetertee.ch/ports/browser It is however not part of the CFT miwi sent a week or so ago, since i was released after that. Feel free to try it out though, and report success/failiure. Regards! Where did you see there is Mesa 8.0? Can you give my a direct link? Here for instance: https://trillian.chruetertee.ch/ports/browser/trunk/graphics/libGL The whole repo is found here: https://trillian.chruetertee.ch/ports/browser/trunk?order=name Have a look at the wiki here http://wiki.freebsd.org/Xorg before playing with it though. To get the new MESA you need the KMS patch, instructions here http://wiki.freebsd.org/Intel_GPU as well as a resonably recent intel graphics card (Radeon might work, but that is unlikely.) Regards! -- Niclas P.S. For more questions regarding the experimental xorg repo, feel free to ask on x...@freebsd.org. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Does anyone regularly build HEAD with clang?
On 2012-02-13 20:10, Brandon Falk wrote: I was having the exact same issue. The fix? 'CPP=clang-cpp' instead of 'CPP=clang -E' in your make.conf. Yes, you should indeed use clang-cpp instead of clang -E. Similarly, never use CPP=gcc -E. This is because in cpp mode, both gcc and clang behave a little differently than with -E: unknown file extensions (such as the .x extension used for RPC) will be treated as C. But when you use -E, any unknown file extension will be considered an object file, and passed to the linker. Normally, this should lead to errors during building of the rpc include files though... I wonder why this does not happen in your case. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [ptrace] please review follow fork/exec changes
On 02/13/2012 07:28 AM, Konstantin Belousov wrote:
I looked at the orphan.patch.
Am I right that the orphans are the real childs of the process which
are temporarily reparented to the debugger ? Whatever they are, a comment
should be added to proc.h describing what does it mean.
Done.
Please provide me with a test case that demonstrates the issue
solved by the change.
ftp://ftp.springdaemons.com/soft/I attached 2 source files that compile into
separate binaries. scescx should be able
The problem I'm trying to solve is to allow a parent to collect it's child exit
status while we're following its child. Gdb detaches from the parent upon
successful switch-over from parent to child. At this point due to re-parenting
the parent loses the child to gdb and if it's in a wait() it'll get a return
status that it has no children to wait for.
The new LIST_FOREACH(q-p_orphans) body is copy/pasted, together
with the comments, from the LIST_FOREACH(q-p_children). Can the
common code be moved into some function ?
Moved the common code into a function. Didn't have time to test though.
Shouldn't there be some assertion in proc_reparent() for the case when
we remove child from the orphans list, that the child is no longer
debugged ?
Hmm... Not sure I understand...
Why in proc_reparent(), in the case of P_TRACED child, you do
PROC_UNLOC/PROC_LOCK ?
No idea how it ended up like that... I'll clean it up.
It seems that now wait4(2) can be called from the real (non-debugger)
parent first and result in the call to proc_reap(), isn't it ? We would
then just reparent the child back to the caller, still leaving the
zombie and confusing debugger.
When either gdb or the real parent gets to proc_reap() the process wouldn't get
destroyed, it'll get caught by the following clause:
if (p-p_oppid (t = pfind(p-p_oppid)) != NULL) {
and the real parent with get the child back into the children's list while gdb
will get it into the orphan list. The second time around when proc_reap() is
entered, p-p_oppid will be 0 and the process will get really reaped. Does it
make sense? And proc_reparent() attempts to keep the orphan list clean and not
have the same entries and the list of siblings.
The idea is to keep the real parent alive ling enough to collect the statuc of
the child running under gdb.
Index: sys/proc.h
===
--- sys/proc.h (revision 231328)
+++ sys/proc.h (working copy)
@@ -507,8 +507,6 @@ struct proc {
/* The following fields are all zeroed upon creation in fork. */
#define p_startzero p_oppid
pid_t p_oppid; /* (c + e) Save ppid in ptrace. XXX */
- int p_dbg_child; /* (c + e) # of debugged children in
- ptrace. */
struct vmspace *p_vmspace; /* (b) Address space. */
u_int p_swtick; /* (c) Tick when swapped in or out. */
struct itimerval p_realtimer; /* (c) Alarm timer. */
@@ -576,6 +574,11 @@ struct proc {
after fork. */
uint64_t p_prev_runtime; /* (c) Resource usage accounting. */
struct racct *p_racct; /* (b) Resource accounting. */
+ /* An orphan is process that has beed re-parented to the debugger
+ as a result of attaching to it. Need to keep track of tham to
+ be able to collect the exit status of what used to be children. */
+ LIST_ENTRY(proc) p_orphan; /* (e) List of orphan processes. */
+ LIST_HEAD(, proc) p_orphans; /* (e) Pointer to list of orphans. */
};
#define p_session p_pgrp-pg_session
@@ -867,7 +870,7 @@ void procinit(void);
void proc_linkup0(struct proc *p, struct thread *td);
void proc_linkup(struct proc *p, struct thread *td);
void proc_reap(struct thread *td, struct proc *p, int *status, int options,
- struct rusage *rusage);
+ struct rusage *rusage, int child);
void proc_reparent(struct proc *child, struct proc *newparent);
struct pstats *pstats_alloc(void);
void pstats_fork(struct pstats *src, struct pstats *dst);
Index: kern/kern_exit.c
===
--- kern/kern_exit.c (revision 231328)
+++ kern/kern_exit.c (working copy)
@@ -680,7 +680,7 @@ sys_wait4(struct thread *td, struct wait_args *uap
*/
void
proc_reap(struct thread *td, struct proc *p, int *status, int options,
-struct rusage *rusage)
+struct rusage *rusage, int child)
{
struct proc *q, *t;
@@ -720,7 +720,6 @@ proc_reap(struct thread *td, struct proc *p, int *
if (p-p_oppid (t = pfind(p-p_oppid)) != NULL) {
PROC_LOCK(p);
proc_reparent(p, t);
- p-p_pptr-p_dbg_child--;
p-p_oppid = 0;
PROC_UNLOCK(p);
pksignal(t, SIGCHLD, p-p_ksi);
@@ -738,7 +737,10 @@ proc_reap(struct thread *td, struct proc *p, int *
sx_xlock(allproc_lock);
LIST_REMOVE(p, p_list); /* off zombproc */
sx_xunlock(allproc_lock);
- LIST_REMOVE(p, p_sibling);
+ if (child)
+ LIST_REMOVE(p, p_sibling);
+ else
+ LIST_REMOVE(p, p_orphan);
leavepgrp(p);
#ifdef PROCDESC
if (p-p_procdesc != NULL)
@@ -803,12 +805,54 @@
Re: [ptrace] please review follow fork/exec changes
On Mon, Feb 13, 2012 at 02:04:24PM -0800, Dmitry Mikulin wrote:
On 02/13/2012 07:28 AM, Konstantin Belousov wrote:
I looked at the orphan.patch.
Am I right that the orphans are the real childs of the process which
are temporarily reparented to the debugger ? Whatever they are, a comment
should be added to proc.h describing what does it mean.
Done.
Please provide me with a test case that demonstrates the issue
solved by the change.
ftp://ftp.springdaemons.com/soft/I attached 2 source files that compile
into separate binaries. scescx should be able
The problem I'm trying to solve is to allow a parent to collect it's child
exit status while we're following its child. Gdb detaches from the parent
upon successful switch-over from parent to child. At this point due to
re-parenting the parent loses the child to gdb and if it's in a wait()
it'll get a return status that it has no children to wait for.
This text should be put somewhere in the comment. It took me some time
to re-create the reason for the patch during the read.
I will take a look at the example tomorrow, thanks.
The new LIST_FOREACH(q-p_orphans) body is copy/pasted, together
with the comments, from the LIST_FOREACH(q-p_children). Can the
common code be moved into some function ?
Moved the common code into a function. Didn't have time to test though.
Ok. Do not put the space between function name and '('.
Both calls to proc_to_reap() has the space.
Shouldn't there be some assertion in proc_reparent() for the case when
we remove child from the orphans list, that the child is no longer
debugged ?
Hmm... Not sure I understand...
proc_reparent() can move the child both to and from the orphan list.
If child is traced, you instert it into the orhpan list.
When removing the child from the orphan list, it means that
debugger finished with the process. My suggestion is to assert this
in proc_reparent (but I am not completely sure that this can be done
easily).
Why in proc_reparent(), in the case of P_TRACED child, you do
PROC_UNLOC/PROC_LOCK ?
No idea how it ended up like that... I'll clean it up.
It seems that now wait4(2) can be called from the real (non-debugger)
parent first and result in the call to proc_reap(), isn't it ? We would
then just reparent the child back to the caller, still leaving the
zombie and confusing debugger.
When either gdb or the real parent gets to proc_reap() the process wouldn't
get destroyed, it'll get caught by the following clause:
if (p-p_oppid (t = pfind(p-p_oppid)) != NULL) {
and the real parent with get the child back into the children's list while
gdb will get it into the orphan list. The second time around when
proc_reap() is entered, p-p_oppid will be 0 and the process will get
really reaped. Does it make sense? And proc_reparent() attempts to keep the
orphan list clean and not have the same entries and the list of siblings.
Right, this is what I figured. But I asked about some further implication
of this change:
if real parent spuriosly calls wait4(2) on the child pid after the child
exited, but before the debugger called the wait4(), then exactly the
code you noted above will be run. This results in the child being fully
returned to the original parent.
Next, the wait4() call from debugger gets an error, and zombie will be
kept around until parent calls wait4() for this pid once more.
Am I missed something ?
The idea is to keep the real parent alive ling enough to collect the
statuc of the child running under gdb.
pgpimDQrx4uk7.pgp
Description: PGP signature
Re: Mesa 8.0 Info
On 02/13/12 19:31, Ivan Klymenko wrote: В Mon, 13 Feb 2012 19:02:30 +0100 O. Hartmann ohart...@zedat.fu-berlin.de пишет: On 02/13/12 09:34, vehemens wrote: http://cgit.freedesktop.org/mesa/mesa/commit/?id=d01de08c4c84f0406a23ce38e1c9c163ed2b91bc Interesting to read that FreeBSD has now explicitely been extracted from the description file :-( The impression that someone really wants to destroy FreeBSD... More the impression that the world is filled up with Linux-PR-nailed heads. RedHat, Suse, they all make a lot of money with their distributions, namely the server distributions, services et cetera. As I learned in my carreer at university, it has been a hard and long way to make the heterogeneous landscape of several UNIX flavors compatible by designing standards. Today, nearly every pupil, scholar or even teacher associates with the terminus UNIX Linux! signature.asc Description: OpenPGP digital signature
Re: [ptrace] please review follow fork/exec changes
The problem I'm trying to solve is to allow a parent to collect it's child
exit status while we're following its child. Gdb detaches from the parent
upon successful switch-over from parent to child. At this point due to
re-parenting the parent loses the child to gdb and if it's in a wait()
it'll get a return status that it has no children to wait for.
This text should be put somewhere in the comment. It took me some time
to re-create the reason for the patch during the read.
I'll find a place in the code to add this comment.
I will take a look at the example tomorrow, thanks.
The new LIST_FOREACH(q-p_orphans) body is copy/pasted, together
with the comments, from the LIST_FOREACH(q-p_children). Can the
common code be moved into some function ?
Moved the common code into a function. Didn't have time to test though.
Ok. Do not put the space between function name and '('.
Both calls to proc_to_reap() has the space.
Habit of a different coding convention... fixed
Shouldn't there be some assertion in proc_reparent() for the case when
we remove child from the orphans list, that the child is no longer
debugged ?
Hmm... Not sure I understand...
proc_reparent() can move the child both to and from the orphan list.
If child is traced, you instert it into the orhpan list.
When removing the child from the orphan list, it means that
debugger finished with the process. My suggestion is to assert this
in proc_reparent (but I am not completely sure that this can be done
easily).
Need to think about this one.
Why in proc_reparent(), in the case of P_TRACED child, you do
PROC_UNLOC/PROC_LOCK ?
No idea how it ended up like that... I'll clean it up.
It seems that now wait4(2) can be called from the real (non-debugger)
parent first and result in the call to proc_reap(), isn't it ? We would
then just reparent the child back to the caller, still leaving the
zombie and confusing debugger.
When either gdb or the real parent gets to proc_reap() the process wouldn't
get destroyed, it'll get caught by the following clause:
if (p-p_oppid (t = pfind(p-p_oppid)) != NULL) {
and the real parent with get the child back into the children's list while
gdb will get it into the orphan list. The second time around when
proc_reap() is entered, p-p_oppid will be 0 and the process will get
really reaped. Does it make sense? And proc_reparent() attempts to keep the
orphan list clean and not have the same entries and the list of siblings.
Right, this is what I figured. But I asked about some further implication
of this change:
if real parent spuriosly calls wait4(2) on the child pid after the child
exited, but before the debugger called the wait4(), then exactly the
code you noted above will be run. This results in the child being fully
returned to the original parent.
Next, the wait4() call from debugger gets an error, and zombie will be
kept around until parent calls wait4() for this pid once more.
Am I missed something ?
In this case the process will move from gdb's child list to gdb's orphan list
when the real parent does a wait4(). Next time around the wait loop in gdb
it'll be caught by the orphan's proc_reap().
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Mesa 8.0 Info
On 2012-Feb-13, 00:34, vehemens wrote: http://cgit.freedesktop.org/mesa/mesa/commit/?id=d01de08c4c84f0406a23ce38e1c9c163ed2b91bc FWIW, I'm going to update graphics/libosmesa within the next few days. -- Pietro Cerutti The FreeBSD Project g...@freebsd.org PGP Public Key: http://gahr.ch/pgp pgpvsEiKHFpor.pgp Description: PGP signature
Re: Intermittent re0 phy failure
On Mon, Jan 30, 2012 at 05:32:06PM -0500, Michael Butler wrote: On 01/18/12 20:52, YongHyeon PYUN wrote: On Wed, Jan 18, 2012 at 08:01:42PM -0500, Michael Butler wrote: On 01/18/12 19:54, YongHyeon PYUN wrote: On Wed, Jan 18, 2012 at 05:48:47PM -0500, Michael Butler wrote: At random intervals, when re0 is without any significant load; idle for lengthy periods, I see .. kernel: re0: PHY read failed last message repeated 4 times kernel: re0: link state changed to DOWN Unplugging the cable and re-inserting is sufficient to restore functionality. [ .. snip .. ] Thanks a lot. Would you try attached patch? Since applying this (for 8168D) and the patch at SVN r230336 (which affected another system of mine), neither system has gone deaf, Thanks for testing. Committed to HEAD(r231622). Thanks! imb ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
