Re: freebsd-update install failed
d...@gmx.com wrote on 10/24/2014 04:09: # freebsd-update install Installing updates...install: ///usr/src/contrib/tzdata/zone1970.tab: No such file or directory done. # OK, maybe the install didn't fail, and the quirk is ignorable. However, in any case, freebsd-update shouldn't try to update anything in /usr/src. ___ 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: freebsd-update install failed
Allan Jude wrote on 10/24/2014 18:29: Do you have a src tree installed? Obviously not. This error is usually Usually? You've gotta be kidding me. caused by it trying to install the update to an empty src tree, so the contrib/tzdata parent directory does not exist. It is a minor problem with freebsd-update where it gets confused the odd time a new file has to be added in a security update. It is a problem with the update package, actually. To update /usr/src, one should use Subversion. Not? If it is the job of freebsd-update to update /usr/src (when it exists), then freebsd-update should also try to apply source code security patches as well, which apparently is not the 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
freebsd-update install failed
Do what (is it safe to retry the install?)? log: # freebsd-update fetch Looking up update.FreeBSD.org mirrors... 5 mirrors found. Fetching public key from update5.freebsd.org... done. Fetching metadata signature for 10.0-RELEASE from update5.freebsd.org... done. Fetching metadata index... done. Fetching 2 metadata files... done. Inspecting system... done. Preparing to download files... done. Fetching 88 patches.1020304050607080 done. Applying patches... done. Fetching 4 files... done. The following files will be removed as part of updating to 10.0-RELEASE-p11: /usr/share/zoneinfo/Asia/Chongqing /usr/share/zoneinfo/Asia/Harbin /usr/share/zoneinfo/Asia/Kashgar The following files will be added as part of updating to 10.0-RELEASE-p11: /usr/share/zoneinfo/Antarctica/Troll /usr/share/zoneinfo/Asia/Chita /usr/share/zoneinfo/Asia/Srednekolymsk /usr/src/contrib/tzdata/zone1970.tab The following files will be updated as part of updating to 10.0-RELEASE-p11: /bin/freebsd-version /boot/kernel/kernel /boot/kernel/kernel.symbols /rescue/[ [...] /usr/share/zoneinfo/Pacific/Pago_Pago /usr/share/zoneinfo/zone.tab # freebsd-update install Installing updates...install: ///usr/src/contrib/tzdata/zone1970.tab: No such file or directory done. # ___ 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: Xorg causes panics with multiple drivers (Was: panic: resource_list_alloc: resource entry is busy)
John Baldwin wrote on 09/12/2014 23:06: X loaded i915kms automatically and i915 and i915kms do not get along. i915 had already allocated the IRQ when i915kms tried to alloc the same IRQ causing the issue. Who is to blame? The user who tried to manually load an unsupported combination of modules, or the system, which should have handled things gracefully (whether by automatically unloading the first driver, or producing a soft-error upon loading the 2nd driver)? On a side-note, I also had a resource_list_alloc: resource entry is busy panic right after switching from the 10.0-supported Xorg to the new Xorg; I exited Xorg, enabled FreeBSD_new_Xorg, ran pkg upgrade, then ran startx, and got the panic. Surely this wasn't my fault! ___ 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: [ANNOUNCEMENT] pkg 1.3.0 out!
Baptiste Daroussin wrote, On 07/23/2014 16:42: So much has happened that it is hard to summarize so I'll try to highlight the major points: - New solver, now pkg has a real SAT solver able to automatically handle conflicts and dynamically discover them. (yes pkg set -o is deprecated now) Does pkg/Pkg/PKG/pkgng/PkgNg/PKGNG/whatever now downgrade/revert packages when removing an alternative repository, such as FreeBSD_new_xorg? (Previously, it didn't: I was required to manually remove and (re)install all X11-related packages.) ___ 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
panic: page fault (on 10.0-RELEASE-p7)
Info at http://slexy.org/raw/s21qACK3qQ. On the 1st boot after the panic, the crash dump failed due to insufficient amount of space on /. Then I removed some files, restarted the system, and the dump was redone. Is it correct to assume that the dump was not damaged? ___ 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: freebsd and utf-8 directory names
Kevin Lo wrote, On 07/03/2014 05:33: On Wed, Jul 02, 2014 at 12:27:07AM +0200, d...@gmx.com wrote: But now, eat this: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=191540 Well, I'm going to close that PR. :-) First, [...] Let me know if that works for you, thanks. Yes, that did work. When I'll have more time and resources, I'll try to find out why/what didn't work at the time of the IRC conversation. It is possible that Windows was using something like UTF-16, but I tested only UTF-8 -- though the apparent unavailability of any UTF-16 locale on my system indicates that base FreeBSD installations are not able to properly mount commonly-used FAT32 partitions (think about flash drives). Another next step is to find out whether a regular user can set a locale environment variable and then create a file that system utilities -- which have one pre-set locale -- (think about disk space usage quota enforcers) won't handle well. ___ 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: freebsd and utf-8 directory names
MS - Krasznai András wrote, On 06/30/2014 08:30: There is a partition formatted for FAT32 where I store documents which I would like to view (and edit) both in windows and freebsd. The problem is that if the path name contains certain Hungarian characters (e.g o with double accent), then libreoffice in FreeBSD refuses to open them complaining about illegal characters. The directory was created in windows, the document also, and I can handle them perfectly from windows (what is more, libreoffice under a linux can also open those documents). Some accented characters are shown as a question mark in FreeBSD, and some others are as a black rectangle; these latter are causing problems. If a file-nam contains such characters then the file is shown as 0- length in Midnight Commander. This is not limited to Hungarian characters. There are bugs in FreeBSD's FAT handling code. According to an IRC discussion with mux, FreeBSD has plenty of VOP_LOOKUP bugs, and this case hits such a bug. To allow FreeBSD to read files with fancy UTF-8 characters in their names, mount the FAT32 partition with ``-o shortnames''. Then, you won't be able to use proper file naming (so this is not even a workaround), but at least you'll be able to read the said files. Poke the FreeBSD developers to start fixing bugs, maybe (but not very likely) that will help. Also, you're at least the 3rd user (I'm at least the 2nd) that runs into this case; ie., here's a report: http://forums.freebsd.org/showthread.php?t=14612 (of course, this does not contain a solution). ___ 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: freebsd and utf-8 directory names
MS - Krasznai András wrote, On 07/01/2014 17:07: I installed xfe (x11-fm/xfe) file manager in the same freebsd configuration. This application displays and handles those diretories and files perfectly, but as soon as I want to open such a file with double click on it (I set xfe to invoke libreoffice in this case) libreoffice still refuses to open the file. [...] What does xfe do differently? What do you mean by handling and displaying properly? Listing (directory contents) is one thing, being able to stat or open the file is different. ___ 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: freebsd and utf-8 directory names
Steve Kargl wrote, On 07/01/2014 17:30: Or become a FreeBSD developer, fix the problem, submit a patch, and make everyone happy. I would be very interested in 1-on-1 coaching from you. I will pay for your work with awesome patches. ___ 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: freebsd and utf-8 directory names
Steve Kargl wrote, On 07/01/2014 18:34: As far as coaching, I'll give you the secret to how I started fixing libm: step 1. Obtain src/ step 2. Read relevent files in src/ step 3. Find problem. step 4. Search literature. step 5. Fix problem. step 6. Submit patch 6a. Receive review of patch. 6b. Fix patch based on review. 6c. Resubmit patch. [[step 7. commit patch] step 8. goto step 2. In other words, You, the general user, should learn the art of operating system development (on your own) for the sole purpose of being able to fix the bug yourself. ___ 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: freebsd and utf-8 directory names
David Chisnall wrote, On 07/01/2014 19:06: Please note that forums.freebsd.org is not a bug tracker. I tried searching the bug tracker for bugs with FAT and filename or FAT and utf-8/utf8/character in their names and could not find any reference to this issue. If you actually want to see bugs fixed, rather than just complain about them, please file them here: https://bugs.freebsd.org/bugzilla/enter_bug.cgi Make sure that you provide all of the steps required to reproduce them. I neglected to submit a bug report because: (1) there were already at least 3 bug reports related to (FAT32 and) character sets or encodings, some of them even had patches; (2) the reports were very old, indicating that the FreeBSD developers don't care about FAT32; (3) at least one report was seemingly related, and I didn't want to create a(nother) possible duplicate. But now, eat this: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=191540 ___ 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: GHCi vs iconv_open
lokada...@gmx.de wrote, On 12/31/2013 22:37: On 12/22/13 19:35, d...@gmx.com wrote: After a recent installworld, GHCi (``ghc -i'' from lang/ghc) fails like so: % ghci GHCi, version 7.6.3: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... ghc: /usr/local/lib/ghc-7.6.3/base-4.6.0.1/HSbase-4.6.0.1.o: unknown symbol `iconv_open' ghc: unable to load package `base' Running portupgrade to rebuild all (most) ports didn't help. Where's the issue / Do what? Which version of FreeBSD you are running? FreeBSD 10.0 Beta4 shouldn't have the problem. I stumble over it while i update from Beta 2 to RC3. The error is hit even with FreeBSD r260061 (built a couple of days ago). ___ 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: new Xorg (KMS, etc.) for Radeon 9600
Adrian Chadd wrote, On 12/30/2013 22:17: On 17 December 2013 22:41, d...@gmx.com wrote: It fixes non-deterministic lockups when the (old, drm1) r300 drivers are used. According to John Baldwin [1]: The drm code is doing a copyin() while holding a mutex (which is not allowed). The latest version of the patch (also the one I used for years) is at [2], linked from [3]. Hm. Well, can we add some lock assertions to the dri code to panic whenever this is done? Oops, I meant panics, not lockups. The kernel panics exactly because -- as I gather -- the assertions are already there. There are lockup issues even with the patch applied (for the most part, only when using, in Xorg.conf: Option AccelMethod EXA). ___ 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: new Xorg (KMS, etc.) for Radeon 9600
John Baldwin wrote, On 12/23/2013 17:50: It needs fixing, but the fix needs to be correct. Though a fix should not be delayed by decades... ___ 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: PACKAGESITE spam
Frank Seltzer wrote, On 12/22/2013 15:00: Greg Rivers said: Do you really feel that strongly about it? Having a record of changes to the system has always seemed like a feature to me... Baptiste Daroussin said: this has been done and activated for reason, first for lot of companies, it is important (PCI DSS requirement for example), secondly I receive tons of request to actiavte on by default while you are the first to request it off by default Adrian Chadd said: The point is that some people like an audit trail. The audit trail for some people involves remote logging of syslog messages to a log host. This would include when packages are installed. My thought: Then why can't the messages about installed ports have it's own log file rather than /var/log/messages? As for this message: pkg: PACKAGESITE in pkg.conf is deprecated. Please create a repository configuration file Glen Barber replied: echo 'SYSLOG: no' /usr/local/etc/pkg.conf And Shane Ambler: now we can turn it off which I don't think we could before. All of this is mostly off-topic. I haven't had any opposition to logging. Instead, I originally thought that the PACKAGESITE spam was a result of a bug, because -- the spam appeared with a recent installworld; -- there were like 50 consecutive messages every now and then; -- I don't recall ever setting up any PACKAGESITE-related variables (the timestamp on the file is 2013-04-05, so I could be WRONG); -- I looked for pkg.conf (only) in /etc, and didn't find it there; -- neither of the UPDATING files contain instructions regarding pkg.conf; -- I haven't payed too much attention to HEADSUP mails in the last few weeks (what relevant things did I miss?). Why is pkg.conf in /usr/local/etc instead of /etc? By contrast, why does the sample configuration file (/usr/local/etc/pkg.conf.sample) contain a line that links to a file in /etc, namely #PUBKEY : /etc/ssl/pkg.conf? The pkg.conf of a -RELEASE won't be as empty as mine is currently (causing PACKAGESITE spam), will it? If not (obviously), then what will it look like? ___ 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
GHCi vs iconv_open
After a recent installworld, GHCi (``ghc -i'' from lang/ghc) fails like so: % ghci GHCi, version 7.6.3: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... ghc: /usr/local/lib/ghc-7.6.3/base-4.6.0.1/HSbase-4.6.0.1.o: unknown symbol `iconv_open' ghc: unable to load package `base' Running portupgrade to rebuild all (most) ports didn't help. Where's the issue / Do what? ___ 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
PACKAGESITE spam
I've just installed a very recent -CURRENT, and now I'm performing a big portupgrade procedure. I get the following message spammed a lot: pkg: PACKAGESITE in pkg.conf is deprecated. Please create a repository configuration file ___ 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: buildworld error (tcpdump and Capsicum)
ping ! ___ 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: buildworld error (tcpdump and Capsicum)
Index: addrtoname.c === --- addrtoname.c (revision 259658) +++ addrtoname.c (working copy) @@ -33,9 +33,11 @@ #endif #ifdef __FreeBSD__ +#ifdef HAVE_LIBCAPSICUM #include libcapsicum.h #include libcapsicum_dns.h #endif +#endif #include tcpdump-stdinc.h #ifdef USE_ETHER_NTOHOST ___ 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: new Xorg (KMS, etc.) for Radeon 9600
Jean-Sébastien Pédron wrote, On 12/17/2013 22:20: On 16.12.2013 08:36, d...@gmx.com wrote: Still nobody wants to apply Robert Noland's DRM patch? What problem(s) does this patch fix? It fixes non-deterministic lockups when the (old, drm1) r300 drivers are used. According to John Baldwin [1]: The drm code is doing a copyin() while holding a mutex (which is not allowed). The latest version of the patch (also the one I used for years) is at [2], linked from [3]. [1] http://lists.freebsd.org/pipermail/freebsd-current/2009-April/005988.html [2] http://people.freebsd.org/~rnoland/drm_radeon-copyin-fix-try2.patch [3] http://lists.freebsd.org/pipermail/freebsd-current/2009-April/006080.html ___ 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
buildworld error (tcpdump and Capsicum)
/usr/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/addrtoname.c:36:10: fatal error: 'libcapsicum.h' file not found #include libcapsicum.h I have, notably, WITHOUT_CAPSICUM=1 in /etc/src.conf. ___ 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: new Xorg (KMS, etc.) for Radeon 9600
Still nobody wants to apply Robert Noland's DRM patch?
Index: sys/dev/drm/r300_cmdbuf.c
===
--- sys/dev/drm/r300_cmdbuf.c (revision 259413)
+++ sys/dev/drm/r300_cmdbuf.c (working copy)
@@ -1043,6 +1043,8 @@
int emit_dispatch_age = 0;
int ret = 0;
+ DRM_UNLOCK();
+
DRM_DEBUG(\n);
/* pacify */
@@ -1205,5 +1207,7 @@
COMMIT_RING();
+ DRM_LOCK();
+
return ret;
}
Index: sys/dev/drm/radeon_irq.c
===
--- sys/dev/drm/radeon_irq.c (revision 259413)
+++ sys/dev/drm/radeon_irq.c (working copy)
@@ -338,10 +338,13 @@
result = radeon_emit_irq(dev);
+ DRM_UNLOCK();
if (DRM_COPY_TO_USER(emit-irq_seq, result, sizeof(int))) {
DRM_ERROR(copy_to_user\n);
+ DRM_LOCK();
return -EFAULT;
}
+ DRM_LOCK();
return 0;
}
Index: sys/dev/drm/radeon_mem.c
===
--- sys/dev/drm/radeon_mem.c (revision 259413)
+++ sys/dev/drm/radeon_mem.c (working copy)
@@ -246,11 +246,14 @@
if (!block)
return -ENOMEM;
+ DRM_UNLOCK();
if (DRM_COPY_TO_USER(alloc-region_offset, block-start,
sizeof(int))) {
DRM_ERROR(copy_to_user\n);
+ DRM_LOCK();
return -EFAULT;
}
+ DRM_LOCK();
return 0;
}
Index: sys/dev/drm/radeon_state.c
===
--- sys/dev/drm/radeon_state.c (revision 259413)
+++ sys/dev/drm/radeon_state.c (working copy)
@@ -1773,8 +1773,13 @@
}
if (!buf) {
DRM_DEBUG(EAGAIN\n);
- if (DRM_COPY_TO_USER(tex-image, image, sizeof(*image)))
+ DRM_UNLOCK();
+ if (DRM_COPY_TO_USER(tex-image, image,
+ sizeof(*image))) {
+DRM_LOCK();
return -EFAULT;
+ }
+ DRM_LOCK();
return -EAGAIN;
}
@@ -1786,10 +1791,13 @@
#define RADEON_COPY_MT(_buf, _data, _width) \
do { \
- if (DRM_COPY_FROM_USER(_buf, _data, (_width))) {\
+ DRM_UNLOCK(); \
+ if (DRM_COPY_FROM_USER(_buf, _data, (_width))) { \
DRM_ERROR(EFAULT on pad, %d bytes\n, (_width)); \
+ DRM_LOCK(); \
return -EFAULT; \
} \
+ DRM_LOCK(); \
} while(0)
if (microtile) {
@@ -2130,9 +2138,13 @@
if (sarea_priv-nbox RADEON_NR_SAREA_CLIPRECTS)
sarea_priv-nbox = RADEON_NR_SAREA_CLIPRECTS;
+ DRM_UNLOCK();
if (DRM_COPY_FROM_USER(depth_boxes, clear-depth_boxes,
- sarea_priv-nbox * sizeof(depth_boxes[0])))
+ sarea_priv-nbox * sizeof(depth_boxes[0]))) {
+ DRM_LOCK();
return -EFAULT;
+ }
+ DRM_LOCK();
radeon_cp_dispatch_clear(dev, clear, depth_boxes);
@@ -2394,10 +2406,13 @@
return -EINVAL;
}
- if (DRM_COPY_FROM_USER(image,
- (drm_radeon_tex_image_t __user *) tex-image,
- sizeof(image)))
- return -EFAULT;
+ DRM_UNLOCK();
+ ret = -DRM_COPY_FROM_USER(image,
+ (drm_radeon_tex_image_t __user *) tex-image,
+ sizeof(image));
+ DRM_LOCK();
+ if (ret)
+ return ret;
RING_SPACE_TEST_WITH_RETURN(dev_priv);
VB_AGE_TEST_WITH_RETURN(dev_priv);
@@ -2418,8 +2433,12 @@
LOCK_TEST_WITH_RETURN(dev, file_priv);
- if (DRM_COPY_FROM_USER(mask, stipple-mask, 32 * sizeof(u32)))
+ DRM_UNLOCK();
+ if (DRM_COPY_FROM_USER(mask, stipple-mask, 32 * sizeof(u32))) {
+ DRM_LOCK();
return -EFAULT;
+ }
+ DRM_LOCK();
RING_SPACE_TEST_WITH_RETURN(dev_priv);
@@ -2546,16 +2565,24 @@
drm_radeon_prim_t prim;
drm_radeon_tcl_prim_t tclprim;
- if (DRM_COPY_FROM_USER(prim, vertex-prim[i], sizeof(prim)))
+ DRM_UNLOCK();
+ if (DRM_COPY_FROM_USER(prim, vertex-prim[i], sizeof(prim))) {
+ DRM_LOCK();
return -EFAULT;
+ }
+ DRM_LOCK();
if (prim.stateidx != laststate) {
drm_radeon_state_t state;
+ DRM_UNLOCK();
if (DRM_COPY_FROM_USER(state,
vertex-state[prim.stateidx],
- sizeof(state)))
+ sizeof(state))) {
+DRM_LOCK();
return -EFAULT;
+ }
+ DRM_LOCK();
if (radeon_emit_state2(dev_priv, file_priv, state)) {
DRM_ERROR(radeon_emit_state2 failed\n);
@@ -2772,8 +2799,12 @@
do {
if (i cmdbuf-nbox) {
- if (DRM_COPY_FROM_USER(box, boxes[i], sizeof(box)))
+ DRM_UNLOCK();
+ if (DRM_COPY_FROM_USER(box, boxes[i], sizeof(box))) {
+DRM_LOCK();
return -EFAULT;
+ }
+ DRM_LOCK();
/* FIXME The second and subsequent times round
* this loop, send a WAIT_UNTIL_3D_IDLE before
* calling emit_clip_rect(). This fixes a
@@ -2866,11 +2897,14 @@
kbuf = drm_alloc(cmdbuf-bufsz, DRM_MEM_DRIVER);
if (kbuf == NULL)
return -ENOMEM;
+ DRM_UNLOCK();
if (DRM_COPY_FROM_USER(kbuf, (void __user *)cmdbuf-buf,
cmdbuf-bufsz)) {
+ DRM_LOCK();
drm_free(kbuf, orig_bufsz, DRM_MEM_DRIVER);
return -EFAULT;
}
+ DRM_LOCK();
cmdbuf-buf = kbuf;
}
@@ -3089,10 +3123,13 @@
return -EINVAL;
}
+ DRM_UNLOCK();
if (DRM_COPY_TO_USER(param-value, value, sizeof(int))) {
DRM_ERROR(copy_to_user\n);
+ DRM_LOCK();
return -EFAULT;
}
+ DRM_LOCK();
return 0;
}
Re: RFC: (Unconditionally) enable -fno-strict-overflow for kernel builds
Konstantin Belousov wrote, On 11/30/2013 13:56: The compiler authors take the undefined part there as a blanket to perform optimizations which are assuming that signed overflow cannot happen. Personally, when I first heard about such assumptions, it was inspiring to write code in a way that automatically gives the compiler certain ``overflow cannot happer'' (for example, because the input values given are always small) hints, such as turning some uses of ``unsigned int'' (where a negative value logically doesn't make sense, such as in a size/length value) into ``signed int''. However, I quickly found that this way of thinking leads to counter-production: coding becomes slower, the resulting code becomes less readable, while the performance gain remains questionable. It would be much better if hints could be given to the compiler using assert() (which would have effect even in non-debug mode). How do others feel? Konstantin Belousov wrote, On 12/01/2013 08:59: It is written in C, but no useful program can be written in the pure standard C. We must rely on the assumptions about underlying architecture, and compiler must provide sane access to the features of the underlying architecture to be useful. But what behavior do you want for signed arithmetic? Modular, saturating, or some other? And how do you signal that? Or maybe you just want to check for (signed/unsigned) integer overflow (which can't be done cleanly and efficiently in C), in which case someone should write a check_add_overflow() function... ___ 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: RFC: (Unconditionally) enable -fno-strict-overflow for kernel builds
Adrian Chadd wrote, On 12/01/2013 01:33: Are you able to have clang/llvm/gcc tell us where/when code is relying on undefined behaviour? So we can, like, fix them? Well, there's -ftrapv. ___ 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: [RFC] how to get the size of a malloc(9) block ?
John-Mark Gurney wrote, On 12/01/2013 03:20: Either it happens rarely, and always doing a realloc won't hurt performance, or it happens often, and then you should be using a larger buffer in the first place.. What if a size-elastic implementation of a dynamic data structure would be able to adjust to the malloc implementation, such as agreeing to allocate regions of size (2^k - 8)? Much like the use of getpagesize() (yes, I know it's not part of a technical standard). ___ 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: [RFC] how to get the size of a malloc(9) block ?
What is the supposed definition of malloc_usable_size(p) in a hypothetical, upcoming C standard? With the rest of the C standard remaining the same, one could try: Definition: The value of malloc_usable_size(p) is the amount of space allocated for object p, plus the amount of space after object p that can currently be written without messing up other objects or memory-management areas. This definition is practically useless, because data written to the slack space after the object could be claimed by calls to alloc()ish function -- perhaps by other threads. Another attempt at the defining something useful: Definition: The value of malloc_usable_size(p) is the amount of space allocated for object p, plus the amount of space after object p that can be written without messing up other objects or memory-management areas, while alloc()ish functions are not called on p. With this, one asks the question: How much is usually overallocated? In some implementations, usually just a few bytes (say, when the minimal allocation unit is 8 bytes); where not, it can be said that the memory manager is quite space-leaky. It appears that it's not possible to make a proper API with malloc_usable_size() included, at least when multi-threading is involved (ie., in the modern world). However, it is still useful to create an API that supports the following cases: - A program knows how to adapt to memory fragmentation without moving an ever-growing, but chainable array of data. - A program would become faster, if it knew when moving is required; then, the program could update various pointer-based (as opposed to arrayindex-based) references to the object being moved. (Just like when memory is defragmentated in a garbage-collected programming language.) - A program requires more memory in real-time, which means to either receive more memory immediately and do something, or to signal a real-time failure. So new flags could be [1]: - realloc_flags(p, s, REALLOCF_NO_MOVE): Resize object p, without moving it, to size s. With this restriction, when requesting more memory, and the specified amount isn't available, don't do anything (when requesting less memory, always succeed). - realloc_flags(p, s, REALLOCF_NO_MOVE | REALLOCF_ELASTIC): Resize object p, without moving it, to size s. With this restriction, when requesting more memory, and the specified amount isn't available, reserve as much as possible (when requesting less memory, always succeed). On the other hand, be advised of a hypothetical scenario, in which realloc() would like to jump at the opportunity to move the object to a different space, say, for the purpose of condensing slack space, when statistics show that allocated areas have plenty of holes. This means that the design of the new API can have more goals: - The allocator implementation should be able to shape the workings of a program at quick-realloc points, for example, by coaxing it to call realloc() when memory is very scattered. - The program should always be able to take advantage of a quick-realloc functionality, for example, to support certain real-time requirements of applications, to the extent reasonably possible within the implementation. For this, there could be a REALLOCF_FORCE flag, to be used in real-time scenarios. Without the flag, the call can be expected to be rejected on the basis of some implementation-specific preference, such as anti-fragmentation. Is there any insufficiency in this API, in anyone's mind? [1] When such a distinction makes sense and is supported (not stubbed) in the current architecture, environment, implementation, etc. ___ 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: new Xorg (KMS, etc.) for Radeon 9600
Jean-Sébastien Pédron wrote, On 11/13/2013 21:29: As I don't really now how AGP works and have no AGP hardware to reproduce the problem, can you post the output of the following commands as a start? pciconf -lvbce hostb0@pci0:0:0:0: class=0x06 card=0x25701849 chip=0x25708086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82865G/PE/P DRAM Controller/Host-Hub Interface' class = bridge subclass = HOST-PCI bar [10] = type Prefetchable Memory, range 32, base 0xf000, size 134217728, enabled cap 09[e4] = vendor (length 6) Intel cap 0 version 1 cap 02[a0] = AGP v3 8x 4x SBA disabled PCI errors = Received Master-Abort pcib1@pci0:0:1:0: class=0x060400 card=0x chip=0x25718086 rev=0x02 hdr=0x01 vendor = 'Intel Corporation' device = '82865G/PE/P AGP Bridge' class = bridge subclass = PCI-PCI uhci0@pci0:0:29:0: class=0x0c0300 card=0x24d01849 chip=0x24d28086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82801EB/ER (ICH5/ICH5R) USB UHCI Controller' class = serial bus subclass = USB bar [20] = type I/O Port, range 32, base 0xe000, size 32, enabled uhci1@pci0:0:29:1: class=0x0c0300 card=0x24d01849 chip=0x24d48086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82801EB/ER (ICH5/ICH5R) USB UHCI Controller' class = serial bus subclass = USB bar [20] = type I/O Port, range 32, base 0xe400, size 32, enabled uhci2@pci0:0:29:2: class=0x0c0300 card=0x24d01849 chip=0x24d78086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82801EB/ER (ICH5/ICH5R) USB UHCI Controller' class = serial bus subclass = USB bar [20] = type I/O Port, range 32, base 0xe800, size 32, enabled uhci3@pci0:0:29:3: class=0x0c0300 card=0x24d01849 chip=0x24de8086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82801EB/ER (ICH5/ICH5R) USB UHCI Controller' class = serial bus subclass = USB bar [20] = type I/O Port, range 32, base 0xec00, size 32, enabled ehci0@pci0:0:29:7: class=0x0c0320 card=0x24d01849 chip=0x24dd8086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82801EB/ER (ICH5/ICH5R) USB2 EHCI Controller' class = serial bus subclass = USB bar [10] = type Memory, range 32, base 0xff2ffc00, size 1024, enabled cap 01[50] = powerspec 2 supports D0 D3 current D0 cap 0a[58] = EHCI Debug Port at offset 0xa0 in map 0x14 pcib2@pci0:0:30:0: class=0x060400 card=0x chip=0x244e8086 rev=0xc2 hdr=0x01 vendor = 'Intel Corporation' device = '82801 PCI Bridge' class = bridge subclass = PCI-PCI isab0@pci0:0:31:0: class=0x060100 card=0x chip=0x24d08086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82801EB/ER (ICH5/ICH5R) LPC Interface Bridge' class = bridge subclass = PCI-ISA atapci0@pci0:0:31:1:class=0x01018a card=0x24d01849 chip=0x24db8086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82801EB/ER (ICH5/ICH5R) IDE Controller' class = mass storage subclass = ATA bar [20] = type I/O Port, range 32, base 0xfc00, size 16, enabled bar [24] = type Memory, range 32, base 0, size 1024, enabled none0@pci0:0:31:3: class=0x0c0500 card=0x24d01849 chip=0x24d38086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82801EB/ER (ICH5/ICH5R) SMBus Controller' class = serial bus subclass = SMBus bar [20] = type I/O Port, range 32, base 0x400, size 32, enabled pcm0@pci0:0:31:5: class=0x040100 card=0x97611849 chip=0x24d58086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82801EB/ER (ICH5/ICH5R) AC'97 Audio Controller' class = multimedia subclass = audio bar [10] = type I/O Port, range 32, base 0xd800, size 256, enabled bar [14] = type I/O Port, range 32, base 0xdc00, size 64, enabled bar [18] = type Memory, range 32, base 0xff2ff800, size 512, enabled bar [1c] = type Memory, range 32, base 0xff2ff400, size 256, enabled cap 01[50] = powerspec 2 supports D0 D3 current D0 vgapci0@pci0:1:0:0: class=0x03 card=0x200217ee chip=0x41501002 rev=0x00 hdr=0x00 vendor = 'Advanced Micro Devices [AMD] nee ATI' device = 'RV350 AP [Radeon 9600]' class = display subclass = VGA bar [10] = type Prefetchable Memory, range 32, base 0xd000, size 268435456, enabled bar [14] = type I/O Port, range 32, base 0xa800, size 256, enabled bar [18] = type Memory, range 32, base 0xff0f, size 65536, enabled cap 02[58] = AGP v3 8x 4x SBA disabled cap 01[50] = powerspec 2 supports D0 D1 D2 D3 current D0 vgapci1@pci0:1:0:1: class=0x038000 card=0x200317ee chip=0x41701002 rev=0x00
Re: cron(8) improvement
Adrian Chadd wrote, On 11/10/2013 01:18: I'm kinda fed up installing packages that don't enable themselves. There should be no package that needs activation, that is if you want a desktop computer, not a server. 'pkg install xorg' is not enough to get a working xorg. You have to enable hal and dbus and then restart (so things come up in the right order; manually starting them doesn't work) in order to get X working. I use: hald_enable=NO dbus_enable=NO Please install the cron scripts by default. Please then write up a simple rc.conf style setup where the cron scripts can check a config file to see if they should run. Provided that there will be - an option for every instance of a port wanting to install a cron.d script -- ie., port options plus a settable NO_CROND_SCRIPTS -- and - a fail-safe mechanism to disable all cron.d entries, ie. crond_enable=NO, I feel that installed scripts could be an option. ___ 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: new Xorg (KMS, etc.) for Radeon 9600
Tijl Coosemans wrote, On 11/14/2013 11:38: On Wed, 13 Nov 2013 21:29:23 +0100 Jean-Sébastien Pédron wrote: Le 10/11/2013 18:20, d...@gmx.com a écrit : drmn0: info: GTT: 0M 0xF000 - 0xEFFF Tijl Coosemans is right, the problem is this line. The attached patch should fix it, but I haven't been able to test it yet. The ai_aperture_size field is in bytes. Doesn't help in practice (the program still should run faster), although now I get: drmn0: info: GTT: 128M 0xF000 - 0xF7FF ___ 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: new Xorg (KMS, etc.) for Radeon 9600
Tijl Coosemans wrote, On 11/11/2013 10:07: On Sun, 10 Nov 2013 18:20:29 +0100 d...@gmx.com wrote: error: [drm:pid667:r100_cp_init_microcode] *ERROR* radeon_cp: Failed to load firmware radeonkmsfw_R300_cp Make sure you have /boot/kernel/radeonkmsfw_R300_cp.ko. Oops, my bad. I had WITHOUT_SOURCELESS=1 in /etc/src.conf. Now the said 3D application works, though the performance is crappier than with the old Xorg... ___ 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
new Xorg (KMS, etc.) for Radeon 9600
I've built the ports with the following lines in my /etc/make.conf: WITH_NEW_XORG=1 WITH_KMS=1 WITH_GALLIUM=1 And I've attempted to run ``startx''. The compiler was a very recent version of Clang. When building the kernel (not the ports): == /etc/make.conf snippet begins == CPUTYPE?=native CXXFLAGS+= -stdlib=libc++ KERNCONF=MYKERNCONF MODULES_OVERRIDE=drm2 == /etc/make.conf snippet ends == == /sys/i386/conf/MYKERNCONF begins == cpu I686_CPU ident MYKERNCONF options SCHED_ULE # ULE scheduler options PREEMPTION # Enable kernel thread preemption options INET# InterNETworking options FFS # Berkeley Fast Filesystem options SOFTUPDATES # Enable FFS soft updates support options UFS_DIRHASH # Improve performance on big directories options MD_ROOT # MD is a potential root device options MSDOSFS # MSDOS Filesystem options GEOM_PART_GPT # GUID Partition Tables. options GEOM_LABEL # Provides labelization options COMPAT_FREEBSD4 # Compatible with FreeBSD4 options COMPAT_FREEBSD5 # Compatible with FreeBSD5 options COMPAT_FREEBSD6 # Compatible with FreeBSD6 options COMPAT_FREEBSD7 # Compatible with FreeBSD7 options SCSI_DELAY=1000 # Delay (in ms) before probing SCSI options SYSVSHM # SYSV-style shared memory options SYSVMSG # SYSV-style message queues options SYSVSEM # SYSV-style semaphores options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time extensions options PRINTF_BUFR_SIZE=128# Prevent printf output being interspersed. # To make an SMP kernel, the next two lines are needed options SMP # Symmetric MultiProcessor Kernel device apic# I/O APIC # Bus support. device acpi device pci # ATA controllers device ata # Legacy ATA/SATA controllers # ATA/SCSI peripherals device scbus # SCSI bus (required for ATA/SCSI) device da # Direct Access (disks) # atkbdc0 controls both the keyboard and the PS/2 mouse device atkbdc # AT keyboard controller device atkbd # AT keyboard device vga # VGA video card driver # syscons is the default console driver, resembling an SCO console device sc device agp # support several AGP chipsets # PCI Ethernet NICs that use the common MII bus controller code. # NOTE: Be sure to keep the 'device miibus' line in order to use these NICs! device miibus # MII bus support device rl # RealTek 8129/8139 # Pseudo devices. device loop# Network loopback device random # Entropy device device ether # Ethernet support device md # Memory disks device firmware# firmware assist module # USB support device uhci# UHCI PCI-USB interface device ohci# OHCI PCI-USB interface device ehci# EHCI PCI-USB interface (USB 2.0) device usb # USB Bus (required) device umass # Disks/Mass storage - Requires scbus and da device ums # Mouse # Sound support device sound # Generic sound driver (required) device snd_ich # Intel, NVidia and other ICH AC'97 Audio device drm device radeondrm device iicbus device iic device iicbb == /sys/i386/conf/MYKERNCONF ends == == /etc/X11/xorg.conf begins == Section ServerFlags Option DontZoom on Option VTSysReq on # #Option BlankTime 1 # #Option StandbyTime 2 # #Option SuspendTime 3 # #Option OffTime 4 # Option HandleSpecialKeys Always Option AIGLX off Option GlxVisuals minimal Option AllowEmptyInput off Option AutoAddDevices off Option AutoEnableDevices off EndSection Section InputDevice Identifier mouse1 Driver mouse Option Device /dev/ums0 EndSection Section InputDevice Identifier keyboard1 Driver kbd Option XkbLayout us,hu Option AutoRepeat 320 29 EndSection Section Device Identifier card1 Driver radeon VideoRam 131072 #Option ScalerWidth 1920 Option AGPMode 8 #Option AGPFastWrite on # sux Option BusType AGP Option DisplayPriority HIGH Option
Re: new Xorg (KMS, etc.) for Radeon 9600
Daniel Eischen wrote, On 11/10/2013 17:40: My -current is still from ~July 3, and I also got panics when trying new Xorg. Take the drm devices out of your kernel configuration and let X load the necessary drm2 devices when it starts. This allowed it to work for me. Hmm, works for me to avoid panics and hard reboots. Problems: 1. Switching to the virtual terminals or shutting down X causes the display to go black and unrevivable -- a (soft) reboot is necessary. 2. A 3D application crashes with SIGBUS, and the stack gets toasted. == dmesg begins == 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 11.0-CURRENT #6 r257831M: Sun Nov 10 17:55:45 CET 2013 root@:/usr/obj/usr/src/sys/CUSTOM i386 clang version 3.4 (trunk 194164) CPU: Intel(R) Pentium(R) 4 CPU 3.00GHz (2999.72-MHz 686-class CPU) Origin = GenuineIntel Id = 0xf41 Family = 0xf Model = 0x4 Stepping = 1 Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE Features2=0x441dSSE3,DTES64,MON,DS_CPL,CNXT-ID,xTPR TSC: P-state invariant real memory = 536870912 (512 MB) avail memory = 515149824 (491 MB) Event timer LAPIC quality 400 ACPI APIC Table: A M I OEMAPIC FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 1 core(s) x 2 HTT threads cpu0 (BSP): APIC ID: 0 cpu1 (AP/HT): APIC ID: 1 ioapic0: Changing APIC ID to 2 ioapic0 Version 2.0 irqs 0-23 on motherboard random: Software, Yarrow initialized acpi0: A M I OEMRSDT on motherboard acpi0: Power Button (fixed) acpi0: reservation of 0, a (3) failed acpi0: reservation of 10, 1ff0 (3) failed cpu0: ACPI CPU on acpi0 cpu1: ACPI CPU on acpi0 attimer0: AT timer port 0x40-0x43 irq 0 on acpi0 Timecounter i8254 frequency 1193182 Hz quality 0 Event timer i8254 frequency 1193182 Hz quality 100 atrtc0: AT realtime clock port 0x70-0x71 irq 8 on acpi0 Event timer RTC frequency 32768 Hz quality 0 Timecounter ACPI-fast frequency 3579545 Hz quality 900 acpi_timer0: 24-bit timer at 3.579545MHz port 0x808-0x80b on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 agp0: Intel 82865 host to AGP bridge on hostb0 pcib1: ACPI PCI-PCI bridge at device 1.0 on pci0 pci1: ACPI PCI bus on pcib1 vgapci0: VGA-compatible display port 0xa800-0xa8ff mem 0xd000-0xdfff,0xff0f-0xff0f irq 16 at device 0.0 on pci1 vgapci1: VGA-compatible display mem 0xc000-0xcfff,0xff0e-0xff0e at device 0.1 on pci1 uhci0: Intel 82801EB (ICH5) USB controller USB-A port 0xe000-0xe01f irq 16 at device 29.0 on pci0 usbus0 on uhci0 uhci1: Intel 82801EB (ICH5) USB controller USB-B port 0xe400-0xe41f irq 19 at device 29.1 on pci0 usbus1 on uhci1 uhci2: Intel 82801EB (ICH5) USB controller USB-C port 0xe800-0xe81f irq 18 at device 29.2 on pci0 usbus2 on uhci2 uhci3: Intel 82801EB (ICH5) USB controller USB-D port 0xec00-0xec1f irq 16 at device 29.3 on pci0 usbus3 on uhci3 ehci0: Intel 82801EB/R (ICH5) USB 2.0 controller mem 0xff2ffc00-0xff2f irq 23 at device 29.7 on pci0 usbus4: EHCI version 1.0 usbus4 on ehci0 pcib2: ACPI PCI-PCI bridge at device 30.0 on pci0 pci2: ACPI PCI bus on pcib2 rl0: RealTek 8139 10/100BaseTX port 0xb800-0xb8ff mem 0xff1ffc00-0xff1ffcff irq 22 at device 5.0 on pci2 miibus0: MII bus on rl0 rlphy0: RealTek internal media interface PHY 0 on miibus0 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto rl0: Ethernet address: 00:25:22:10:7c:de isab0: PCI-ISA bridge at device 31.0 on pci0 isa0: ISA bus on isab0 atapci0: Intel ICH5 UDMA100 controller port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xfc00-0xfc0f at device 31.1 on pci0 ata0: ATA channel at channel 0 on atapci0 ata1: ATA channel at channel 1 on atapci0 pci0: serial bus, SMBus at device 31.3 (no driver attached) pcm0: Intel ICH5 (82801EB) port 0xd800-0xd8ff,0xdc00-0xdc3f mem 0xff2ff800-0xff2ff9ff,0xff2ff400-0xff2ff4ff irq 17 at device 31.5 on pci0 pcm0: C-Media Electronics CMI9761 AC97 Codec acpi_button0: Power Button on acpi0 atkbdc0: Keyboard controller (i8042) port 0x60,0x64 irq 1 on acpi0 atkbd0: AT Keyboard irq 1 on atkbdc0 atkbd0: [GIANT-LOCKED] orm0: ISA Option ROM at iomem 0xc-0xccfff pnpid ORM on isa0 sc0: System console at flags 0x100 on isa0 sc0: VGA 16 virtual consoles, flags=0x300 vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0 acpi_throttle0: ACPI CPU Throttling on cpu0 Timecounters tick every 1.000 msec random: unblocking device. usbus0: 12Mbps Full Speed USB v1.0 usbus1: 12Mbps Full Speed USB v1.0 usbus2: 12Mbps Full Speed USB v1.0 usbus3: 12Mbps Full Speed USB v1.0 usbus4: 480Mbps High Speed USB v2.0 ugen1.1: Intel at usbus1 uhub0: Intel UHCI root HUB, class 9/0, rev 1.00/1.00,
Re : newcons comming
On Sat, 26 Oct 2013 10:45:32 +0200 dt71 at gmx.com wrote: Suppose that Newcons gets in quickly. I use a Radeon 9600 card. Will I see something useful on my screen (with KMS and the new Xorg and things like that), or will my screen be black? Yup, you will get normal virtual terminal, but a bit bigger than 640x480. It is main reason why x11 team ask me to merge newcons ASAP. Newcons can use framebuffer provided by DRM. Try it yourself. You have successfully volunteered to diagnose why a graphical display fails to start when ports are built using WITH_NEW_XORG=1 WITH_KMS=1 WITH_GALLIUM=1 I still have a very custom kernel containing device drm device radeondrm and no loadable modules, so I'll be back with a situation report after building and installing a more GENERIC kernel. ___ 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: Automated submission of kernel panic reports: sysutils/panicmail
Colin Percival wrote, On 11/04/2013 11:41: After considerable review on freebsd-hackers (thanks dt71 and jilles!) I have now added sysutils/panicmail to the FreeBSD ports tree. The pkesh script is probably still in need of a big review (S00N(TM)...). ___ 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: libreadline rl_message() and building the same object file 6 times?
Sean Bruno wrote, On 10/30/2013 23:14: On Wed, 2013-10-30 at 22:24 +0200, Konstantin Belousov wrote: Thank you for the explanation. Is there a trivial way to abort building all the objects or fail if one fails? Or is this done in parallel? This is done automatically, no ? Bmake seems to be more advanced in this regard, e.g. my parallel kernel builds with compilation error in some module abort whole build immediately, comparing with fmake builds which run to the end. Yes, the build exits immediately if I understand what's going on correctly. My question was about building all six objects, shouldn't one error/warning be enough? Or is there no way for what I propose to happen? What if one path takes very long, for example, if it's an independent call to make(1)? ___ 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: buildworld failure: pfvar.h:44 #include netpfil/pf/pf.h not found
Gleb Smirnoff wrote, On 10/29/2013 05:19: +1 patch. So far, so good: === usr.sbin/tcpdump/tcpdump (depend) rm -f version.c ; sed 's/.*/char version[] = ;/' /usr/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/VERSION version.c rm -f .depend CC='/i/a/clang --sysroot=/usr/obj/usr/src/tmp -B/usr/obj/usr/src/tmp/usr/bin' mkdep -f .depend -a-I/usr/src/usr.sbin/tcpdump/tcpdump -I/usr/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump -DHAVE_CONFIG_H -D_U_=__attribute__((unused)) -I/usr/obj/usr/src/tmp/usr/include/openssl -DHAVE_LIBCRYPTO -DHAVE_OPENSSL_EVP_H -DNDEBUG -std=gnu99 /usr/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/addrtoname.c /usr/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/af.c /usr/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/checksum.c /usr/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/cpack.c /usr/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/gmpls.c /usr/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/gmt2local.c /usr/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/in_cksum.c /usr/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/ipproto.c /usr/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/l2vpn.c /usr/src/usr.sbin/tcpdum p/tcpdum p /../../../contrib/tcpdump/machdep.c /usr/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/nlpid.c /usr/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/oui.c /usr/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/parsenfsfh.c /usr/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-802_11.c /usr/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-802_15_4.c /usr/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-ah.c /usr/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-aodv.c /usr/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-ap1394.c /usr/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-arcnet.c /usr/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-arp.c /usr/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-ascii.c /usr/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-atalk.c /usr/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-atm.c /usr/src/usr.sbin/tcpd ump/tcpd u mp/../../../contrib/tcpdump/print-beep.c /usr/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-bfd.c /usr/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-bgp.c /usr/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-bootp.c /usr/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-bt.c /usr/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-carp.c /usr/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-cdp.c /usr/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-cfm.c /usr/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-chdlc.c /usr/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-cip.c /usr/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-cnfp.c /usr/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-dccp.c /usr/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-decnet.c /usr/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-domain.c /usr/src/usr.s bin/tcpd u mp/tcpdump/../../../contrib/tcpdump/print-dtp.c /usr/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-dvmrp.c /usr/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-eap.c /usr/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-egp.c /usr/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-eigrp.c /usr/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-enc.c /usr/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-esp.c /usr/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-ether.c /usr/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-fddi.c /usr/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-forces.c /usr/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-fr.c /usr/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-gre.c /usr/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-hsrp.c /usr/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-icmp.c /usr/src /usr.sbi n /tcpdump/tcpdump/../../../contrib/tcpdump/print-igmp.c /usr/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-igrp.c /usr/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-ip.c /usr/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-ipcomp.c /usr/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-ipfc.c /usr/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-ipnet.c /usr/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-ipx.c /usr/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-isakmp.c /usr/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-isoclns.c
Re: buildworld failure: pfvar.h:44 #include netpfil/pf/pf.h not found
Gleb Smirnoff wrote, On 10/29/2013 14:43: d === usr.sbin/tcpdump/tcpdump (depend) +1 patch Success! ___ 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
buildworld failure: pfvar.h:44 #include netpfil/pf/pf.h not found
=== sbin/ifconfig (depend) rm -f .depend CC='/path/to/clang --sysroot=/usr/obj/usr/src/tmp -B/usr/obj/usr/src/tmp/usr/bin' mkdep -f .depend -a-DINET -DNDEBUG -std=gnu99 /usr/src/sbin/ifconfig/ifconfig.c /usr/src/sbin/ifconfig/af_link.c /usr/src/sbin/ifconfig/af_inet.c /usr/src/sbin/ifconfig/af_atalk.c /usr/src/sbin/ifconfig/ifclone.c /usr/src/sbin/ifconfig/ifmac.c /usr/src/sbin/ifconfig/ifmedia.c /usr/src/sbin/ifconfig/iffib.c /usr/src/sbin/ifconfig/ifvlan.c /usr/src/sbin/ifconfig/ifgre.c /usr/src/sbin/ifconfig/ifgif.c /usr/src/sbin/ifconfig/ifieee80211.c /usr/src/sbin/ifconfig/regdomain.c /usr/src/sbin/ifconfig/carp.c /usr/src/sbin/ifconfig/ifgroup.c /usr/src/sbin/ifconfig/ifpfsync.c /usr/src/sbin/ifconfig/ifbridge.c /usr/src/sbin/ifconfig/iflagg.c In file included from /usr/src/sbin/ifconfig/ifpfsync.c:35: /usr/obj/usr/src/tmp/usr/include/net/pfvar.h:44:10: fatal error: 'netpfil/pf/pf.h' file not found #include netpfil/pf/pf.h ^ /usr/obj was clean. The environment contains, notably: CC=/path/to/clang CXX=/path/to/clang++ CPP=/path/to/clang-cpp WITHOUT_SSP=1 /etc/make.conf is: CPUTYPE?=native CXXFLAGS+= -stdlib=libc++ KERNCONF=CUSTOM NO_CLEAN=1 NO_KERNELCLEAN=1 NO_MODULES=1 MALLOC_PRODUCTION=1 WITHOUT_SSP=1 /etc/src.conf is: WITHOUT_ACCT=1 WITHOUT_ACPI=1 WITHOUT_AMD=1 WITHOUT_APM=1 WITHOUT_ASSERT_DEBUG=1 WITHOUT_AT=1 WITHOUT_ATF=1 WITHOUT_ATM=1 WITHOUT_AUDIT=1 WITHOUT_AUTHPF=1 WITHOUT_BLUETOOTH=1 WITHOUT_BSNMP=1 WITHOUT_CALENDAR=1 WITHOUT_CAPSICUM=1 WITHOUT_CDDL=1 WITHOUT_CLANG=1 WITHOUT_CPP=1 WITHOUT_CROSS_COMPILER=1 WITHOUT_CTM=1 WITHOUT_DICT=1 WITHOUT_ED_CRYPTO=1 WITHOUT_EXAMPLES=1 WITHOUT_FDT=1 WITHOUT_FLOPPY=1 WITHOUT_FORMAT_EXTENSIONS=1 WITHOUT_FREEBSD_UPDATE=1 WITHOUT_GAMES=1 WITHOUT_GCC=1 WITHOUT_GCOV=1 WITHOUT_GDB=1 WITHOUT_GNUCXX=1 WITHOUT_GPIB=1 WITHOUT_GPIO=1 WITHOUT_HESIOD=1 WITHOUT_HTML=1 WITHOUT_INET6=1 WITHOUT_IPFILTER=1 WITHOUT_IPFW=1 WITHOUT_IPX=1 WITHOUT_JAIL=1 WITHOUT_KDUMP=1 WITHOUT_KERNEL_SYMBOLS=1 WITHOUT_KVM=1 WITHOUT_LDNS=1 WITHOUT_LEGACY_CONSOLE=1 WITHOUT_LOCALES=1 WITHOUT_LOCATE=1 WITHOUT_LPR=1 WITHOUT_MAIL=1 WITHOUT_NDIS=1 WITHOUT_NETGRAPH=1 WITHOUT_NLS=1 WITHOUT_NLS_CATALOGS=1 WITHOUT_NTP=1 WITHOUT_PC_SYSINSTALL=1 WITHOUT_PF=1 WITHOUT_PMC=1 WITHOUT_PORTSNAP=1 WITHOUT_PPP=1 WITHOUT_PROFILE=1 WITHOUT_QUOTAS=1 WITHOUT_RCMDS=1 WITHOUT_RCS=1 WITHOUT_RESCUE=1 WITHOUT_SENDMAIL=1 WITHOUT_SHAREDOCS=1 WITHOUT_SOURCELESS=1 WITHOUT_SSP=1 WITHOUT_SYSINSTALL=1 WITHOUT_TELNET=1 WITHOUT_UNBOUND=1 WITHOUT_WIRELESS=1 WITHOUT_WPA_SUPPLICANT_EAPOL=1 WITHOUT_ZFS=1 WITH_BSD_GREP=1 WITH_SVN=1 ___ 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: buildworld failure: pfvar.h:44 #include netpfil/pf/pf.h not found
Gleb Smirnoff wrote, On 10/28/2013 23:33: Can you please test attached patch? Progress: === usr.bin/netstat (depend) rm -f .depend CC='/i/a/clang --sysroot=/usr/obj/usr/src/tmp -B/usr/obj/usr/src/tmp/usr/bin' mkdep -f .depend -a-DIPSEC -DSCTP -DINET -DNDEBUG -std=gnu99 /usr/src/usr.bin/netstat/if.c /usr/src/usr.bin/netstat/inet.c /usr/src/usr.bin/netstat/main.c /usr/src/usr.bin/netstat/mbuf.c /usr/src/usr.bin/netstat/mroute.c /usr/src/usr.bin/netstat/netisr.c /usr/src/usr.bin/netstat/route.c /usr/src/usr.bin/netstat/unix.c /usr/src/usr.bin/netstat/atalk.c /usr/src/usr.bin/netstat/mroute6.c /usr/src/usr.bin/netstat/ipsec.c /usr/src/usr.bin/netstat/bpf.c /usr/src/usr.bin/netstat/pfkey.c /usr/src/usr.bin/netstat/sctp.c In file included from /usr/src/usr.bin/netstat/if.c:51: /usr/obj/usr/src/tmp/usr/include/net/pfvar.h:44:10: fatal error: 'netpfil/pf/pf.h' file not found #include netpfil/pf/pf.h ^ ___ 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: newcons comming
Suppose that Newcons gets in quickly. I use a Radeon 9600 card. Will I see something useful on my screen (with KMS and the new Xorg and things like that), or will my screen be black? ___ 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: [PATCH] contrib/groff Queisce -Wdangling else
Sean Bruno wrote, On 10/26/2013 17:04:
Index: contrib/groff/src/roff/troff/node.cpp
===
--- contrib/groff/src/roff/troff/node.cpp (revision 257159)
+++ contrib/groff/src/roff/troff/node.cpp (working copy)
@@ -4600,17 +4600,18 @@
}
else {
hunits rem = x - w*i;
-if (rem H0)
+if (rem H0) {
if (n-overlaps_horizontally()) {
if (out-is_on())
n-tprint(out);
out-right(rem - w);
+ } else {
+ out-right(rem);
}
- else
- out-right(rem);
while (--i = 0)
if (out-is_on())
n-tprint(out);
+}
}
}
There is no(intended) functional change.
RED ALERT ! SEAN BRUNO IS A GOVERNMENT SPY 1
___
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: panic: softdep_deallocate_dependencies: unrecovered I/O error
Alexey Dokuchaev wrote, On 10/23/2013 06:26: panic: softdep_deallocate_dependencies: unrecovered I/O error I've seen similar panics relatively often in the last few months, but I deemed them to be the cause of worn IDE cables and old (10 year old) hard drives. In fact, I have a core dump (which I apparently forgot to remove -- it's probably useless anyway) with the following panic string: softdep_deallocate_dependencies: dangling deps ___ 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: make buildworld
George Mitchell wrote, On 10/23/2013 03:22: On 10/22/13 20:55, Mateusz Guzik wrote: On Tue, Oct 22, 2013 at 07:49:21PM -0500, Saul A. Peebsen wrote: error: 'MALLOC_PRODUCTION' macro redefined [-Werror] #define MALLOC_PRODUCTION ^ command line:6:9: note: previous definition is here #define MALLOC_PRODUCTION 1 ^ 1 error generated. *** Error code 1 Presumably you have MALLOC_PRODUCTION set in src.conf or make.conf, remove it. Ran into this myself. More specifically, you have MALLOC_PRODUCTION set to something other than the null string. jemalloc_FreeBSD.h, however, says #define MALLOC_PRODUCTION. This is okay if you have MALLOC_PRODUCTION= in src.conf/make.conf, and this is okay if you don't have MALLOC_PRODUCTION in those files, but if you have it set to foo, or y, or even no, you will get this compile error. -- George That shouldn't be the case, either the jemalloc-part of the build system (which apparently -- for no apparently good reason -- translates the said make variable directly to a C preprocessor #define) or the jemalloc header file should be fixed. Or? ___ 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: Robert Noland's DRM patch
Ping! ___ 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: svn error during 'make buildkernel'?
On 08/03/2013 23:43, Glen Barber wrote: BTW, you should upgrade devel/subversion anyway, since there are security vulnerabilities. BTW, you should remove GA, since it is a security vulnerability itself. ___ 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: another -Wunsequenced topic
Well, this turned out to be a semi-false alarm. A week ago, for a short time, there was a bug in Clang. There is no undefined behavior in ptr = func(++ptr);, partially because a function call introduces a sequence point in C, but Clang did not respect this at that time. However, x = func1(++ptr) + func2(++ptr); is compiler-dependent. Additionally, if func() turns out to be a macro, rather than a native function, then undefined behavior (due to unsequencedness) occurs. According to the manpage for ntohl(): On machines which have a byte order which is the same as the network order, routines are defined as null macros.. This can bite libstand on big-endian systems So in the end, Clang has accidentally pointed me to an irrelated bug, and induced some unnecessary code changes. lolz ___ 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: another -Wunsequenced topic
There are more.
Take the first hunk with caution.
Index: contrib/gdb/gdb/dwarf2-frame.c
===
--- contrib/gdb/gdb/dwarf2-frame.c (revision 252384)
+++ contrib/gdb/gdb/dwarf2-frame.c (working copy)
@@ -1361,7 +1361,7 @@
else if (*augmentation == 'P')
{
/* Skip. */
- buf += size_of_encoded_value (*buf++);
+ buf += size_of_encoded_value (*buf) + 1;
augmentation++;
}
Index: usr.sbin/moused/moused.c
===
--- usr.sbin/moused/moused.c(revision 252384)
+++ usr.sbin/moused/moused.c(working copy)
@@ -2455,7 +2455,7 @@
return (FALSE);
lbutton = atoi(s);
- arg = skipspace(++arg);
+ arg = skipspace(arg + 1);
s = arg;
while (isdigit(*arg))
++arg;
Index: lib/libstand/nfs.c
===
--- lib/libstand/nfs.c (revision 252384)
+++ lib/libstand/nfs.c (working copy)
@@ -1465,8 +1465,9 @@
d-d_name[d-d_namlen] = '\0';
pos = roundup(d-d_namlen, sizeof(uint32_t)) / sizeof(uint32_t);
- fp-off = cookie = ((uint64_t)ntohl(rent-nameplus[pos++]) 32) |
- ntohl(rent-nameplus[pos++]);
+ fp-off = cookie = ((uint64_t)ntohl(rent-nameplus[pos]) 32) |
+ ntohl(rent-nameplus[pos + 1]);
+ pos += 2;
buf = (u_char *)rent-nameplus[pos];
return (0);
}
Index: contrib/sendmail/src/recipient.c
===
--- contrib/sendmail/src/recipient.c(revision 252384)
+++ contrib/sendmail/src/recipient.c(working copy)
@@ -1834,7 +1834,7 @@
/* sp#@# introduces a comment anywhere */
/* for Japanese character sets */
- for (p = buf; (p = strchr(++p, '#')) != NULL; )
+ for (p = buf; (p = strchr(p + 1, '#')) != NULL; )
{
if (p[1] == '@' p[2] == '#'
isascii(p[-1]) isspace(p[-1])
Index: usr.sbin/pkg_install/create/perform.c
===
--- usr.sbin/pkg_install/create/perform.c (revision 252384)
+++ usr.sbin/pkg_install/create/perform.c (working copy)
@@ -149,7 +149,7 @@
/* Count number of dependencies */
for (cp = Pkgdeps; cp != NULL *cp != '\0';
- cp = strpbrk(++cp, \t\n)) {
+ cp = strpbrk(cp + 1, \t\n)) {
ndeps++;
}
___
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
another -Wunsequenced topic
Here's a patch to fix several compilation errors coming from -Wunsequenced
warnings:
Index: bin/ed/re.c
===
--- bin/ed/re.c (revision 252372)
+++ bin/ed/re.c (working copy)
@@ -89,7 +89,7 @@
default:
break;
case '[':
- if ((nd = parse_char_class(++nd)) == NULL) {
+ if ((nd = parse_char_class(nd + 1)) == NULL) {
errmsg = unbalanced brackets ([]);
return NULL;
}
Index: contrib/bmake/meta.c
===
--- contrib/bmake/meta.c(revision 252372)
+++ contrib/bmake/meta.c(working copy)
@@ -1249,7 +1249,7 @@
warnx(%s: %d: line truncated at %u, fname,
lineno, x);
break;
}
- cp = strchr(++cp, '\n');
+ cp = strchr(cp + 1, '\n');
} while (cp);
if (buf[x - 1] == '\n')
buf[x - 1] = '\0';
Index: lib/libfetch/fetch.c
===
--- lib/libfetch/fetch.c(revision 252372)
+++ lib/libfetch/fetch.c(working copy)
@@ -376,7 +376,7 @@
/* password */
if (*q == ':')
- q = fetch_pctdecode(u-pwd, ++q, URL_PWDLEN);
+ q = fetch_pctdecode(u-pwd, q + 1, URL_PWDLEN);
p++;
} else {
Index: lib/libutil/login_times.c
===
--- lib/libutil/login_times.c (revision 252372)
+++ lib/libutil/login_times.c (working copy)
@@ -96,7 +96,7 @@
else
m.lt_start = 0;
if (*p == '-')
- p = parse_time(++p, m.lt_end);
+ p = parse_time(p + 1, m.lt_end);
else
m.lt_end = 1440;
Index: usr.sbin/newsyslog/newsyslog.c
===
--- usr.sbin/newsyslog/newsyslog.c (revision 252372)
+++ usr.sbin/newsyslog/newsyslog.c (working copy)
@@ -1083,7 +1083,7 @@
* at any time, etc).
*/
if (strcasecmp(DEBUG_MARKER, q) == 0) {
- q = parse = missing_field(sob(++parse), errline);
+ q = parse = missing_field(sob(parse + 1), errline);
parse = son(parse);
if (!*parse)
warnx(debug line specifies no option:\n%s,
@@ -1096,7 +1096,7 @@
} else if (strcasecmp(INCLUDE_MARKER, q) == 0) {
if (verbose)
printf(Found: %s, errline);
- q = parse = missing_field(sob(++parse), errline);
+ q = parse = missing_field(sob(parse + 1), errline);
parse = son(parse);
if (!*parse) {
warnx(include line missing argument:\n%s,
@@ -1138,7 +1138,7 @@
defconf_p = working;
}
- q = parse = missing_field(sob(++parse), errline);
+ q = parse = missing_field(sob(parse + 1), errline);
parse = son(parse);
if (!*parse)
errx(1, malformed line (missing fields):\n%s,
@@ -1172,7 +1172,7 @@
} else
working-gid = (gid_t)-1;
- q = parse = missing_field(sob(++parse), errline);
+ q = parse = missing_field(sob(parse + 1), errline);
parse = son(parse);
if (!*parse)
errx(1, malformed line (missing fields):\n%s,
@@ -1187,7 +1187,7 @@
errx(1, error in config file; bad permissions:\n%s,
errline);
- q = parse = missing_field(sob(++parse), errline);
+ q = parse = missing_field(sob(parse + 1), errline);
parse = son(parse);
if (!*parse)
errx(1, malformed line (missing fields):\n%s,
@@ -1197,7 +1197,7 @@
errx(1, error in config file; bad value for count of logs
to save:\n%s,
errline);
- q = parse = missing_field(sob(++parse), errline);
+ q = parse = missing_field(sob(parse + 1), errline);
parse = son(parse);
if (!*parse)
errx(1, malformed line (missing fields):\n%s,
@@ -1215,7 +1215,7 @@
working-flags = 0;
working-compress = COMPRESS_NONE;
- q = parse = missing_field(sob(++parse), errline);
+ q = parse =
compilation error regarding __cxa_call_terminate()
Using Clang head: /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/eh_call.cc:44:1: error: conflicting types for '__cxa_call_terminate' __cxa_call_terminate(_Unwind_Exception* ue_header_) ^ /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/unwind-cxx.h:136:17: note: previous declaration is here extern C void __cxa_call_terminate (void*) __attribute__((noreturn)); ^ ___ 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
Robert Noland's DRM patch
I'm tired of having a local patch to fix video card software. The patch was written by Robert Noland, and is supposed to fix cases where DRM is doing a copyin() while holding a mutex, which is not allowed. Could someone commit the patch? If not, why? ___ 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: Robert Noland's DRM patch
Index: sys/dev/drm/r300_cmdbuf.c
===
--- sys/dev/drm/r300_cmdbuf.c (revision 252372)
+++ sys/dev/drm/r300_cmdbuf.c (working copy)
@@ -1043,6 +1043,8 @@
int emit_dispatch_age = 0;
int ret = 0;
+ DRM_UNLOCK();
+
DRM_DEBUG(\n);
/* pacify */
@@ -1205,5 +1207,7 @@
COMMIT_RING();
+ DRM_LOCK();
+
return ret;
}
Index: sys/dev/drm/radeon_irq.c
===
--- sys/dev/drm/radeon_irq.c (revision 252372)
+++ sys/dev/drm/radeon_irq.c (working copy)
@@ -338,10 +338,13 @@
result = radeon_emit_irq(dev);
+ DRM_UNLOCK();
if (DRM_COPY_TO_USER(emit-irq_seq, result, sizeof(int))) {
DRM_ERROR(copy_to_user\n);
+ DRM_LOCK();
return -EFAULT;
}
+ DRM_LOCK();
return 0;
}
Index: sys/dev/drm/radeon_mem.c
===
--- sys/dev/drm/radeon_mem.c (revision 252372)
+++ sys/dev/drm/radeon_mem.c (working copy)
@@ -246,11 +246,14 @@
if (!block)
return -ENOMEM;
+ DRM_UNLOCK();
if (DRM_COPY_TO_USER(alloc-region_offset, block-start,
sizeof(int))) {
DRM_ERROR(copy_to_user\n);
+ DRM_LOCK();
return -EFAULT;
}
+ DRM_LOCK();
return 0;
}
Index: sys/dev/drm/radeon_state.c
===
--- sys/dev/drm/radeon_state.c (revision 252372)
+++ sys/dev/drm/radeon_state.c (working copy)
@@ -1773,8 +1773,13 @@
}
if (!buf) {
DRM_DEBUG(EAGAIN\n);
- if (DRM_COPY_TO_USER(tex-image, image, sizeof(*image)))
+ DRM_UNLOCK();
+ if (DRM_COPY_TO_USER(tex-image, image,
+ sizeof(*image))) {
+DRM_LOCK();
return -EFAULT;
+ }
+ DRM_LOCK();
return -EAGAIN;
}
@@ -1786,10 +1791,13 @@
#define RADEON_COPY_MT(_buf, _data, _width) \
do { \
- if (DRM_COPY_FROM_USER(_buf, _data, (_width))) {\
+ DRM_UNLOCK(); \
+ if (DRM_COPY_FROM_USER(_buf, _data, (_width))) { \
DRM_ERROR(EFAULT on pad, %d bytes\n, (_width)); \
+ DRM_LOCK(); \
return -EFAULT; \
} \
+ DRM_LOCK(); \
} while(0)
if (microtile) {
@@ -2130,9 +2138,13 @@
if (sarea_priv-nbox RADEON_NR_SAREA_CLIPRECTS)
sarea_priv-nbox = RADEON_NR_SAREA_CLIPRECTS;
+ DRM_UNLOCK();
if (DRM_COPY_FROM_USER(depth_boxes, clear-depth_boxes,
- sarea_priv-nbox * sizeof(depth_boxes[0])))
+ sarea_priv-nbox * sizeof(depth_boxes[0]))) {
+ DRM_LOCK();
return -EFAULT;
+ }
+ DRM_LOCK();
radeon_cp_dispatch_clear(dev, clear, depth_boxes);
@@ -2394,10 +2406,13 @@
return -EINVAL;
}
- if (DRM_COPY_FROM_USER(image,
- (drm_radeon_tex_image_t __user *) tex-image,
- sizeof(image)))
- return -EFAULT;
+ DRM_UNLOCK();
+ ret = -DRM_COPY_FROM_USER(image,
+ (drm_radeon_tex_image_t __user *) tex-image,
+ sizeof(image));
+ DRM_LOCK();
+ if (ret)
+ return ret;
RING_SPACE_TEST_WITH_RETURN(dev_priv);
VB_AGE_TEST_WITH_RETURN(dev_priv);
@@ -2418,8 +2433,12 @@
LOCK_TEST_WITH_RETURN(dev, file_priv);
- if (DRM_COPY_FROM_USER(mask, stipple-mask, 32 * sizeof(u32)))
+ DRM_UNLOCK();
+ if (DRM_COPY_FROM_USER(mask, stipple-mask, 32 * sizeof(u32))) {
+ DRM_LOCK();
return -EFAULT;
+ }
+ DRM_LOCK();
RING_SPACE_TEST_WITH_RETURN(dev_priv);
@@ -2546,16 +2565,24 @@
drm_radeon_prim_t prim;
drm_radeon_tcl_prim_t tclprim;
- if (DRM_COPY_FROM_USER(prim, vertex-prim[i], sizeof(prim)))
+ DRM_UNLOCK();
+ if (DRM_COPY_FROM_USER(prim, vertex-prim[i], sizeof(prim))) {
+ DRM_LOCK();
return -EFAULT;
+ }
+ DRM_LOCK();
if (prim.stateidx != laststate) {
drm_radeon_state_t state;
+ DRM_UNLOCK();
if (DRM_COPY_FROM_USER(state,
vertex-state[prim.stateidx],
- sizeof(state)))
+ sizeof(state))) {
+DRM_LOCK();
return -EFAULT;
+ }
+ DRM_LOCK();
if (radeon_emit_state2(dev_priv, file_priv, state)) {
DRM_ERROR(radeon_emit_state2 failed\n);
@@ -2772,8 +2799,12 @@
do {
if (i cmdbuf-nbox) {
- if (DRM_COPY_FROM_USER(box, boxes[i], sizeof(box)))
+ DRM_UNLOCK();
+ if (DRM_COPY_FROM_USER(box, boxes[i], sizeof(box))) {
+DRM_LOCK();
return -EFAULT;
+ }
+ DRM_LOCK();
/* FIXME The second and subsequent times round
* this loop, send a WAIT_UNTIL_3D_IDLE before
* calling emit_clip_rect(). This fixes a
@@ -2866,11 +2897,14 @@
kbuf = drm_alloc(cmdbuf-bufsz, DRM_MEM_DRIVER);
if (kbuf == NULL)
return -ENOMEM;
+ DRM_UNLOCK();
if (DRM_COPY_FROM_USER(kbuf, (void __user *)cmdbuf-buf,
cmdbuf-bufsz)) {
+ DRM_LOCK();
drm_free(kbuf, orig_bufsz, DRM_MEM_DRIVER);
return -EFAULT;
}
+ DRM_LOCK();
cmdbuf-buf = kbuf;
}
@@ -3089,10 +3123,13 @@
return -EINVAL;
}
+ DRM_UNLOCK();
if (DRM_COPY_TO_USER(param-value, value, sizeof(int))) {
DRM_ERROR(copy_to_user\n);
+ DRM_LOCK();
return -EFAULT;
}
+ DRM_LOCK();
return 0;
}
___
-Wheader-guard
/usr/src/contrib/wpa/src/utils/base64.h:15:9: warning: 'BASE64_H' is used as a header guard here, followed by #define of a different macro [-Wheader-guard] #ifndef BASE64_H ^~~~ /usr/src/contrib/wpa/src/utils/base64.h:16:9: note: 'BASE64_h' is defined here; did you mean 'BASE64_H'? #define BASE64_h ^~~~ BASE64_H and so on. Patch: Index: contrib/wpa/src/utils/base64.h === --- contrib/wpa/src/utils/base64.h (revision 251823) +++ contrib/wpa/src/utils/base64.h (working copy) @@ -13,7 +13,7 @@ */ #ifndef BASE64_H -#define BASE64_h +#define BASE64_H unsigned char * base64_encode(const unsigned char *src, size_t len, size_t *out_len); Index: sys/dev/puc/puc_bfe.h === --- sys/dev/puc/puc_bfe.h (revision 251823) +++ sys/dev/puc/puc_bfe.h (working copy) @@ -27,7 +27,7 @@ */ #ifndef _DEV_PUC_BFE_H_ -#define_DEV_PUC_BFE_H +#define_DEV_PUC_BFE_H_ #define PUC_PCI_BARS 6 Index: sys/dev/puc/puc_cfg.h === --- sys/dev/puc/puc_cfg.h (revision 251823) +++ sys/dev/puc/puc_cfg.h (working copy) @@ -27,7 +27,7 @@ */ #ifndef _DEV_PUC_CFG_H_ -#define_DEV_PUC_CFG_H +#define_DEV_PUC_CFG_H_ #define DEFAULT_RCLK 1843200 Index: sys/dev/vxge/vxge.h === --- sys/dev/vxge/vxge.h (revision 251823) +++ sys/dev/vxge/vxge.h (working copy) @@ -31,7 +31,7 @@ /*$FreeBSD$*/ #ifndef _VXGE_H_ -#define__VXGE_H_ +#define_VXGE_H_ #include dev/vxge/vxgehal/vxgehal.h #include dev/vxge/vxge-osdep.h Index: usr.bin/csup/updater.h === --- usr.bin/csup/updater.h (revision 251823) +++ usr.bin/csup/updater.h (working copy) @@ -26,7 +26,7 @@ * $FreeBSD$ */ #ifndef _UPDATER_H_ -#define _UPDATER_H +#define _UPDATER_H_ void *updater(void *); Index: usr.bin/sort/vsort.h === --- usr.bin/sort/vsort.h(revision 251823) +++ usr.bin/sort/vsort.h(working copy) @@ -28,7 +28,7 @@ */ #if !defined(__VSORT_H__) -#define _VSORT_H__ +#define __VSORT_H__ #include bwstring.h ___ 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
another external compiler topic
For the diagnosis of an error related to external compilers, I'll post full
setup information.
Compiler version string: clang version 3.4 (trunk 182723).
Installed system revision: 251046.
Checked out source tree revision: 251352.
The following 2 configuration files were used to build the installed system, as well as
the new system. (However, see the compiler note later on.)
=== make.conf begins ===
CPUTYPE=native
KERNCONF=MYCONF
COMPILER_TYPE=clang
CROSS_COMPILER_PREFIX=
WITHOUT_FORMAT_EXTENSIONS=1
CC=/path/to/clang
CPP=/path/to/clang-cpp
CXX=/path/to/clang++
NO_CLEAN=1
NO_KERNELCLEAN=1
NO_MODULES=1
MALLOC_PRODUCTION=1
=== make.conf ends ===
=== src.conf begins ===
WITHOUT_ACCT=1
WITHOUT_ACPI=1
WITHOUT_AMD=1
WITHOUT_APM=1
WITHOUT_AT=1
WITHOUT_ATF=1
WITHOUT_ATM=1
WITHOUT_AUDIT=1
WITHOUT_AUTHPF=1
WITHOUT_BIND=1
WITHOUT_BLUETOOTH=1
WITHOUT_BSNMP=1
WITHOUT_CALENDAR=1
WITHOUT_CDDL=1
WITHOUT_CLANG=1
WITHOUT_CLANG_IS_CC=1
WITHOUT_CTM=1
WITHOUT_CVS=1
WITHOUT_DICT=1
WITHOUT_ED_CRYPTO=1
WITHOUT_FDT=1
WITHOUT_FLOPPY=1
WITHOUT_FREEBSD_UPDATE=1
WITHOUT_GAMES=1
WITHOUT_GCC=1
WITHOUT_GCOV=1
WITHOUT_GDB=1
WITHOUT_GPIB=1
WITHOUT_GPIO=1
WITHOUT_HESIOD=1
WITHOUT_HTML=1
WITHOUT_INET6=1
WITHOUT_INFO=1 # [1]
WITHOUT_IPFILTER=1
WITHOUT_IPFW=1
WITHOUT_IPX=1
WITHOUT_JAIL=1
WITHOUT_KDUMP=1
WITHOUT_KVM=1
WITHOUT_LDNS=1
WITHOUT_LEGACY_CONSOLE=1
WITHOUT_LOCATE=1
WITHOUT_LPR=1
WITHOUT_MAIL=1
WITHOUT_NDIS=1
WITHOUT_NETGRAPH=1
WITHOUT_NLS=1
WITHOUT_NLS_CATALOGS=1
WITHOUT_NTP=1
WITHOUT_PC_SYSINSTALL=1
WITHOUT_PF=1
WITHOUT_PKGTOOLS=1
WITHOUT_PMC=1
WITHOUT_PORTSNAP=1
WITHOUT_PPP=1
WITHOUT_PROFILE=1
WITHOUT_QUOTAS=1
WITHOUT_RCMDS=1
WITHOUT_RCS=1
WITHOUT_RESCUE=1
WITHOUT_SENDMAIL=1
WITHOUT_SHAREDOCS=1
WITHOUT_SYSINSTALL=1
WITHOUT_TELNET=1
WITHOUT_WIRELESS=1
WITHOUT_WPA_SUPPLICANT_EAPOL=1
WITH_BSD_GREP=1
WITH_BSD_PATCH=1
=== src.conf ends ===
For the interested reader, regarding # [1]:
=== /usr/bin/makeinfo begins ===
B=
for i in $@ ; do
if test -n $B ; then
echo fuck this shit $i
exit 0
fi
if test $i = -o ; then
B=1
fi
done
=== /usr/bin/makeinfo ends ===
The following are output log snippets. (Snippet 2 contains an error that
follows snippet 1; key term: parallel builds (most likely).)
=== `make buildworld` snippet 1 begins ===
building shared library libkadm5srv.so.11
=== kerberos5/lib/libkafs5 (all)
/i/a/clang -O2 -pipe -march=native
-I/usr/src/kerberos5/lib/libkafs5/../../../crypto/heimdal/lib/kafs
-I/usr/src/kerberos5/li
b/libkafs5/../../../crypto/heimdal/lib/krb5
-I/usr/obj/usr/src/kerberos5/lib/libkafs5/../libkrb5/
-I/usr/src/kerberos5/lib/li
bkafs5/../../../crypto/heimdal/lib/roken -DHAVE_CONFIG_H
-I/usr/src/kerberos5/lib/libkafs5/../../include -std=gnu99 -Qunused-ar
guments -fstack-protector -c
/usr/src/kerberos5/lib/libkafs5/../../../crypto/heimdal/lib/kafs/afssys.c -o
afssys.o
In file included from
/usr/src/kerberos5/lib/libkafs5/../../../crypto/heimdal/lib/kafs/afssys.c:34:
In file included from
/usr/src/kerberos5/lib/libkafs5/../../../crypto/heimdal/lib/kafs/kafs_locl.h:99:
/usr/src/kerberos5/lib/libkafs5/../../../crypto/heimdal/lib/krb5/krb5-v4compat.h:39:10:
fatal error: 'krb_err.h' file not found
=== `make buildworld` snippet 1 ends ===
=== `make buildworld` snippet 2 begins ===
=== kerberos5/lib/libkafs5 (install)
sh /usr/src/tools/install.sh -C -o root -g wheel -m 444 libkafs5.a
/usr/obj/usr/src/tmp/usr/lib
install: libkafs5.a: No such file or directory
=== `make buildworld` snippet 2 ends ===
When building the system that is currently installed, the following compiler
was used:
=== /path/to/clang begins ===
#!/bin/sh
/path/to/real/clang $@ || /path/to/real/clang --sysroot=/usr/obj/usr/src/tmp
$@
=== /path/to/clang ends ===
Also, the following patch was applied to the source tree:
=== diff begins ===
Index: Makefile.inc1
===
--- Makefile.inc1 (revision 251352)
+++ Makefile.inc1 (working copy)
@@ -722,7 +722,7 @@
ITOOLS=[ awk cap_mkdb cat chflags chmod chown \
date echo egrep find grep id install ${_install-info} \
ln lockf make mkdir mtree ${_nmtree_itools} mv pwd_mkdb \
- rm sed sh sysctl test true uname wc ${_zoneinfo}
+ rm sed sh sysctl test true uname wc ${_zoneinfo} btxld ls mv cp dd
#
# distributeworld
Index: usr.bin/xlint/llib/Makefile
===
--- usr.bin/xlint/llib/Makefile (revision 251352)
+++ usr.bin/xlint/llib/Makefile (working copy)
@@ -9,9 +9,9 @@
CLEANFILES+= ${LIBS}
llib-lposix.ln: llib-lposix
- ${LINT} ${LINTFLAGS} -Cposix ${.ALLSRC}
+ CC=${CC:Q} ${LINT} ${LINTFLAGS} -Cposix ${.ALLSRC}
llib-lstdc.ln: llib-lstdc
- ${LINT} ${LINTFLAGS} -Cstdc ${.ALLSRC}
+ CC=${CC:Q} ${LINT} ${LINTFLAGS} -Cstdc ${.ALLSRC}
.include bsd.prog.mk
=== diff
Re: another external compiler topic
On 06/05/2013 21:31, Brooks Davis wrote:
My first reaction is that your configuration is so far beyond anything
that is actually documented as working you're going to be mostly on your
own.
Why?
First off I assume that since you posted to freebsd-current@ that you
are running the latest head.
Yes:
On Wed, Jun 05, 2013 at 08:53:14PM +0200, d...@gmx.com wrote:
Installed system revision: 251046.
Checked out source tree revision: 251352.
Setting CC, CPP, and CXX except in the environment isn't supported and
can't work for cross build cases. It looks like your avoiding those
cases (but more on your wrapper script later), but this does put you in
uncharted land.
Now compiling with CC, CPP and CXX only in the environment (and XCC, XCPP and
XCXX in make.conf).
I see that WITHOUT_KERBEROS is not set here. Was it ever? Migration
from a WITHOUT_KERBEROS system to a WITH_KERBEROS system is known to be
broken which might explain your breakage in the libkrb5 build.
Yes, WITHOUT_KERBEROS was set once in the past, but that was only so multiple
re-buildworld and re-installworld iterations ago.
When building the system that is currently installed, the following compiler
was used:
=== /path/to/clang begins ===
#!/bin/sh
/path/to/real/clang $@ || /path/to/real/clang --sysroot=/usr/obj/usr/src/tmp
$@
=== /path/to/clang ends ===
This has got to corrupt your build. I can't imagine anything staying
working for long given that many translation units will compile with
the system headers and then get linked to something compiled with the
headers from the source tree.
I forgot to mention that after re-buildworld-ing and re-installworld-ing with
the script, I redid the whole process again without the script (at which point
the sysroot argument was not required anymore, until the next header update).
Also, the following patch was applied to the source tree:
=== diff begins ===
Index: Makefile.inc1
===
--- Makefile.inc1 (revision 251352)
+++ Makefile.inc1 (working copy)
@@ -722,7 +722,7 @@
ITOOLS= [ awk cap_mkdb cat chflags chmod chown \
date echo egrep find grep id install ${_install-info} \
ln lockf make mkdir mtree ${_nmtree_itools} mv pwd_mkdb \
- rm sed sh sysctl test true uname wc ${_zoneinfo}
+ rm sed sh sysctl test true uname wc ${_zoneinfo} btxld ls mv cp dd
#
# distributeworld
Index: usr.bin/xlint/llib/Makefile
===
--- usr.bin/xlint/llib/Makefile (revision 251352)
+++ usr.bin/xlint/llib/Makefile (working copy)
@@ -9,9 +9,9 @@
CLEANFILES+= ${LIBS}
llib-lposix.ln: llib-lposix
- ${LINT} ${LINTFLAGS} -Cposix ${.ALLSRC}
+ CC=${CC:Q} ${LINT} ${LINTFLAGS} -Cposix ${.ALLSRC}
llib-lstdc.ln: llib-lstdc
- ${LINT} ${LINTFLAGS} -Cstdc ${.ALLSRC}
+ CC=${CC:Q} ${LINT} ${LINTFLAGS} -Cstdc ${.ALLSRC}
.include bsd.prog.mk
=== diff ends ===
What do these patches work around?
The 1st hunk works around an installkernel issue: in some cases (unknown, but seemingly related to
header updates), installkernel seems to involve some compiling, cping,
btxlding, etc..
Without the 2nd hunk, the lint program would call cc, which does not exist
(ie., there is no /usr/bin/cc, but there is a ${CC}).
___
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: another external compiler topic
On 06/05/2013 23:20, Brooks Davis wrote:
On Wed, Jun 05, 2013 at 10:46:01PM +0200, d...@gmx.com wrote:
Now compiling with CC, CPP and CXX only in the environment (and XCC, XCPP and
XCXX in make.conf).
Success!
If you XCC, XCPP, and XCXX you may not need CC, CPP, and CXX at all,
though your environment is weird enough I won't assert that.
There is no cc (/usr/bin/cc), so some form of CC is required.
Also, the following patch was applied to the source tree:
=== diff begins ===
Index: Makefile.inc1
===
--- Makefile.inc1 (revision 251352)
+++ Makefile.inc1 (working copy)
@@ -722,7 +722,7 @@
ITOOLS= [ awk cap_mkdb cat chflags chmod chown \
date echo egrep find grep id install ${_install-info} \
ln lockf make mkdir mtree ${_nmtree_itools} mv pwd_mkdb \
- rm sed sh sysctl test true uname wc ${_zoneinfo}
+ rm sed sh sysctl test true uname wc ${_zoneinfo} btxld ls mv cp dd
#
# distributeworld
Index: usr.bin/xlint/llib/Makefile
===
--- usr.bin/xlint/llib/Makefile (revision 251352)
+++ usr.bin/xlint/llib/Makefile (working copy)
@@ -9,9 +9,9 @@
CLEANFILES+= ${LIBS}
llib-lposix.ln: llib-lposix
- ${LINT} ${LINTFLAGS} -Cposix ${.ALLSRC}
+ CC=${CC:Q} ${LINT} ${LINTFLAGS} -Cposix ${.ALLSRC}
llib-lstdc.ln: llib-lstdc
- ${LINT} ${LINTFLAGS} -Cstdc ${.ALLSRC}
+ CC=${CC:Q} ${LINT} ${LINTFLAGS} -Cstdc ${.ALLSRC}
.include bsd.prog.mk
=== diff ends ===
What do these patches work around?
The 1st hunk works around an installkernel issue: in some cases (unknown, but seemingly related to
header updates), installkernel seems to involve some compiling, cping,
btxlding, etc..
Hmm, that seems weird. I've never seen that.
Actually, installworld, not installkernel.
Without the 2nd hunk, the lint program would call cc, which does not exist
(ie., there is no /usr/bin/cc, but there is a ${CC}).
This sounds like a bug.
Well, now, with a CC environment variable, the hunk is no longer required for me. But
then again, the lint program calls cc if there is no CC environment variable,
such as when CC is set only in make.conf.
According to https://wiki.freebsd.org/ExternalToolchain:
To use XCC, you must not set any of the variables that can be overridden by X*
variables in /etc/make.conf or /etc/src.conf as Makefile.inc1 will be unable to
change them.
Why? In my case, CC should always be /path/to/clang (however, CFLAGS should contain
--sysroot=/usr/obj/..., when appropriate).
___
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
bsd.qt.mk (cc --version [...])
There is no cc executable in the path (eg., there is no /usr/bin/cc) and the CC
make-variable is set to an absolute path to the C compiler (Clang) in
/etc/make.conf. Then, for example,
cd /usr/ports/www/seamonkey make config
results in the following output:
make: /usr/ports/Mk/bsd.qt.mk line 313: warning: Couldn't read shell's output for (cc --version 2
/dev/null | /usr/bin/awk 'NR == 1 { gsub(/[()]/, , $2); print $2 }') || echo gcc
TODO: fix.
___
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: Building of libc in /usr/src/lib/libc results in error
On 05/27/2013 02:28, Super Bisquit wrote: building shared library libc.so.7 /usr/bin/ld: warning: creating a DT_TEXTREL in a shared object. I have run into this issue multiple times in the past -- its occurrence seems to be correlated with header updates. As an instant workaround, you can add ALLOW_SHARED_TEXTREL=1 to /etc/make.conf for one buildworldinstallworld run, and then do another run, for which ALLOW_SHARED_TEXTREL=1 will empirically not be required. ___ 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
absolute paths in port patch files
In the ports system, some patch files use absolute paths. Run ls -d /usr/ports/*/*/files | xargs -IX grep -rnE '^([+][+][+]|---) /' X to see what I mean. For example, there is: /usr/ports/textproc/texi2html/files/patch-texi2html.pl:2:+++ /usr/local/bin/texi2html 2012-07-09 10:53:16.0 +0200 Some patch files refer to target files in the /tmp directory. Theoretically, this means that malicious regular users are able to fiddle with the patching process: by creating the target files in the /tmp directory, they are able to silently cause patches to apply to bogus files in the /tmp directory instead of the intended files in the port's work directory. In the extreme case, a malicious user could cause ports to be built without certain security patches. The user could also try a symlink attack. Some patch files refer to target files that will be installed, such as /usr/local/bin/texi2html. A patch in the textproc/texi2html port was the basis for me finding out about this issue: the port was already installed, and was being built to be reinstalled, and the patching process tried to modify the installed /usr/local/bin/texi2html file, but failed (the following files were created: /usr/local/bin/texi2html.orig and /usr/local/bin/texi2html.rej). However, theoretically, if the patching process succeeds on the already-installed files, then later, unpatched files will be reinstalled. Some patch files refer directly to target files in the /usr/ports directory, others to the /home directory. These are practically harmless. In all cases, absolute paths should be replaced with relative paths. At the time of this writing, the malicious user thing is just theory, while the texi2html is just an annoying build bug. It seems that this path issue doesn't warrant much noise. ___ 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: Bug in BSD patch
On 05/23/2013 13:02, Stefan Esser wrote: Quoting from the patch(1) man page: [...] patch will examine either the “old” and “new” file names or, for a non-context diff, the “index” file name, and choose the file name with the fewest path components, the short- est basename, and the shortest total file name length (in that order). I did read that, got confused, and decided to put off further attempts to understand the program--manpage connection. Your patch file example has the following file information: --- texi2html.pl2012-07-09 10:54:41.0 +0200 +++ /usr/local/bin/texi2html2012-07-09 10:53:16.0 +0200 Patch will modify texi2html.pl in the work directory. The other file name (/usr/local/bin/texi2html) is ignored. So, there is no problem with this patch, if patch works as advertised. In that case, I see no security issues (assuming I didn't miss anything): all patch files (containing at least 1 absolute path, excluding /dev/null) would point the patch program to the work directory, provided that a manpage-conforming program is used. Some patch files refer to target files in the /tmp directory. Theoretically, this means that malicious regular users are able to fiddle with the patching process: by creating the target files in the /tmp directory, they are able to silently cause patches to apply to bogus files in the /tmp directory instead of the intended files in the port's work directory. In the extreme case, a malicious user could cause ports to be built without certain security patches. The user could also try a symlink attack. But it is highly unlikely, that the chunk will apply cleanly, and thus patch will abort without changing the bogus target file, in most cases. In which case a reject file will be written to /tmp/insert_target_file_here.rej, which will be -- perhaps only at the right time, as a race condition -- a symlink to /etc/insert_important_file_here. Unfortunately, my brief attempt at making this work failed. ___ 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
