headers
Matthias Apitz | 25 May 2013 08:22
Picon

compiling qt4-corelib fails on 10-CURRENT r250588


Hello,

The compilation of ports/devel/qt4-corelib fails on r250588; please
advice what's todo; thanks

===>  Building for qt4-corelib-4.8.4_1
clang++ -c -O2 -pipe -fno-strict-aliasing -pthread -I/usr/local/include/glib-2.0
-I/usr/local/include -O2 -fvisibility=hidden -fvisibility-inlines-hidden -Wall -W -pthread
-D_THREAD_SAFE -fPIC -DQT_SHARED -DQT_BUILD_CORE_LIB -DQT_NO_USING_NAMESPACE
-DQT_NO_CAST_TO_ASCII -DQT_ASCII_CAST_WARNINGS -DQT3_SUPPORT -DQT_MOC_COMPAT
-DQT_USE_QSTRINGBUILDER -DQT_USE_ICU -DHB_EXPORT=Q_CORE_EXPORT -DGNU_LIBICONV -DQT_NO_DEBUG
-DQT_HAVE_MMX -DQT_HAVE_3DNOW -DQT_HAVE_SSE -DQT_HAVE_MMXEXT -DQT_HAVE_SSE2 -DQT_HAVE_SSE3
-DQT_HAVE_SSSE3 -DQT_HAVE_SSE4_1 -DQT_HAVE_SSE4_2 -DQT_HAVE_AVX -D_LARGEFILE64_SOURCE
-D_LARGEFILE_SOURCE -I/usr/local/share/qt4/mkspecs/freebsd-clang -I. -I../../include
-I../../include/QtCore -I.rcc/release-shared -Iglobal -I../3rdparty/harfbuzz/src
-I../3rdparty/md5 -I../3rdparty/md4 -I.
 moc/release-shared -I/usr/local/include/qt4 -I/usr/local/include -o
.obj/release-shared/qsimd.o tools/qsimd.cpp
clang++ -c -O2 -pipe -fno-strict-aliasing -pthread -I/usr/local/include/glib-2.0
-I/usr/local/include -O2 -fvisibility=hidden -fvisibility-inlines-hidden -Wall -W -pthread
-D_THREAD_SAFE -fPIC -DQT_SHARED -DQT_BUILD_CORE_LIB -DQT_NO_USING_NAMESPACE
-DQT_NO_CAST_TO_ASCII -DQT_ASCII_CAST_WARNINGS -DQT3_SUPPORT -DQT_MOC_COMPAT
-DQT_USE_QSTRINGBUILDER -DQT_USE_ICU -DHB_EXPORT=Q_CORE_EXPORT -DGNU_LIBICONV -DQT_NO_DEBUG
-DQT_HAVE_MMX -DQT_HAVE_3DNOW -DQT_HAVE_SSE -DQT_HAVE_MMXEXT -DQT_HAVE_SSE2 -DQT_HAVE_SSE3
-DQT_HAVE_SSSE3 -DQT_HAVE_SSE4_1 -DQT_HAVE_SSE4_2 -DQT_HAVE_AVX -D_LARGEFILE64_SOURCE
-D_LARGEFILE_SOURCE -I/usr/local/share/qt4/mkspecs/freebsd-clang -I. -I../../include
-I../../include/QtCore -I.rcc/release-shared -Iglobal -I../3rdparty/harfbuzz/src
-I../3rdparty/md5 -I../3rdparty/md4 -I.
 moc/release-shared -I/usr/local/include/qt4 -I/usr/local/include -o
(Continue reading)

Permalink | Reply | 1 comment |
headers
Weiß, Jürgen | 24 May 2013 21:15
Picon
Picon
Favicon

Re: Intel D2500CC motherboard and strange RS232/UART behavior

According to the ACPI of the board, uart0 and uart 2
use IRQ 3 and
     IRQ (Edge, ActiveLow, Shared, )
       {3}
uart1 and uart3 use IRQ 4
     IRQ (Edge, ActiveLow, Shared, )
       {4}

ioapic_config_intr is called with trig == INTR_TRIGGER_EDGE and
 pol == INTR_POLARITY_LOW.

The combinatation of Edge and ActiveLow seems kind of broken.

Forcing the polarity in ioapic_config_intr to INTR_POLARITY_HIGH
and disabling uart 2 and uart 3 results in two working serial
interfaces.

So what is the correct fix to this?

Regards 

Juergen Weiss

Juergen Weiss      |Universitaet Mainz, Zentrum fuer Datenverarbeitung,
weiss <at> uni-mainz.de |55099 Mainz, Tel: +49(6131)39-26361, FAX: +49(6131)39-26407

_______________________________________________
freebsd-current <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe <at> freebsd.org"
(Continue reading)

Permalink | Reply | 1 comment |
headers
O. Hartmann | 24 May 2013 15:50
Picon
Picon
Favicon

CURRENT: system crashing while shuting down -> files system corruption

Since r250670 (last known stable) I face a lot of problems.

On systems with SSD, after a couple of seconds the box is crashing and
rebooting, showing up a lot of CAM/SCSI stuff on the console.

A system with "traditional" disks I get while shutdown in progress (via
ACPI power button or shutdown -p now command) corrupt filesystems (UFS
disk).

Below an error message after such a crahs, /usr/ports is a partition and
while the shutdown was in effect, there were no activities on that
partition, but is has been "repaired" while the box then powered up
again. Now it seems to be corrupted in the way that I can not svn update
the ports tree anymore.

What happened?

root <at> thor:/usr/ports # make update
--------------------------------------------------------------
>>> Updating /usr/ports using Subversion
--------------------------------------------------------------
cd /usr/ports; /usr/local/bin/svn update
svn: E155036: Please see the 'svn upgrade' command
svn: E155036: Working copy '/usr/ports' is an old development version
(format 12); to upgrade it, use a format 18 client, then use
'tools/dev/wc-ng/bump-to-19.py', then use the current client
*** Error code 1

Stop.
make: stopped in /usr/ports
(Continue reading)

Permalink | Reply | 2 comments |
headers
Anton Shterenlikht | 24 May 2013 11:12
Picon
Picon
Favicon

r250633: make -j buildkernel: ports module: illegal option -- J


amd64 r250633 buildworld fine,
but on "make -j4 buildkernel" got this error:

===> Ports module net/bwn-firmware-kmod (all)

*skip*

Extracting v4/b0g0initvals5.fw
/usr/bin/touch /usr/obj/usr/src/sys/BUZI/usr/ports/net/bwn-firmware-kmod/work/bg
/v4/ucode.fw
make: illegal option -- J
usage: make [-BPSXeiknpqrstv] [-C directory] [-D variable]
        [-d flags] [-E variable] [-f makefile] [-I directory]
        [-j max_jobs] [-m directory] [-V variable]
        [variable=value] [target ...]
*** Error code 2

Stop.
make: stopped in /usr/ports/net/bwn-firmware-kmod

#  cat /etc/src.conf
PORTS_MODULES=net/bwn-firmware-kmod

Thanks

Anton

_______________________________________________
freebsd-current <at> freebsd.org mailing list
(Continue reading)

Permalink | Reply | 1 comment |
headers
Lawrence Stewart | 24 May 2013 04:19
Picon
Favicon

Read-triggered corruption of swap backed MD devices

Hi all,

I tracked the cause of a colleague's nanobsd image creation problem to
what appears to be some nasty behaviour with swap-backed MD devices.
I've verified the behaviour exists on three separate systems running
10-CURRENT r250260, 9-STABLE r250824 and 9-STABLE r250925.

The following minimal reproduction recipe (run as root)
deterministically triggers the behaviour for me on the 3 systems I've
tested:

env MD_DEV=`mdconfig -an -t swap -s 1m -x 63 -y 16` sh -c '(fdisk -I
md${MD_DEV} ; bsdlabel -w -B md${MD_DEV}s1 ; bsdlabel md${MD_DEV}s1 ; dd
if=/dev/md${MD_DEV} of=/dev/null bs=64k ; bsdlabel md${MD_DEV}s1 ;
mdconfig -d -u ${MD_DEV})'

By changing the mdconfig "-t swap" argument to "-t malloc", the bsdlabel
remains intact after the dd command completes.

I've included command line recipe runs from my 10-CURRENT r250260 laptop
with both "-t swap" and "-t malloc" at the end of this email for reference.

Smells like a VM related problem to me, but ENOCLUE so I would
appreciate some help.

Cheers,
Lawrence

root <at> lstewart-laptop:~ # uname -a
FreeBSD lstewart-laptop 10.0-CURRENT FreeBSD 10.0-CURRENT #0 r250260:
(Continue reading)

Permalink | Reply | 2 comments |
headers
David O'Brien | 24 May 2013 03:03
Picon
Favicon

Unexpected behavior change [FreeBSD]make -> bmake

For some reason bmake is now using share/mk/ from within a source tree
instead of the installation in /usr/share/mk/:

   /w/10/usr.bin/xinstall$ bmake
   bmake: "/b/deo/10/share/mk/bsd.own.mk" line 444: MK_BMAKE can't be set by a user.

I believe this is against POLA as there is no guarantee that a share/mk/
within the source tree is parseable by the invoked /usr/bin/bmake.  It is
/usr/share/mk/ that is guaranteed to be consistent with /usr/bin/make.

I see this as synonymous with using headers from lib/libc/ within the
source tree vs. /usr/include (which match the /lib/libc.so) when
building in this same way.  I think we can all agree that is wrong
(the headers that match the libc that is being linked against needs
to be used).

Can we go back to the pre-16-May-2013 behavior?

--

-- 
-- David  (obrien <at> FreeBSD.org)
_______________________________________________
freebsd-current <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe <at> freebsd.org"
Permalink | Reply | 1 comment |
headers
current | 24 May 2013 02:12
Picon
Favicon

Your PayPal account has been limited PP-503-472-100


                 Your PayPal Account Has Been Limited today.

                                   PayPal

                        Your Paypal Account Has Been
                        Limited FROM PayPal Support

   Hello

   security measure, we regularly screen activity in the system.
   You received this message due to an issue on your account.
   Due to unusual number of invalid login attempts on your account, we
   have reason to believe there might be security breach on your account.
   Your account requires extra verification process to ensure your
   identity under Your Account.
   [1]Log in to view now
   [2]ADD A MOBILE NUMBER

   [3]Accept Payments [4]Security [5]PayPal App [6]Fees [7]Help [8]PayPal
                                                                Anywhere

   Please do not reply to this email. We are unable to respond to
   inquiries sent to this address. For immediate answers to your
   questions, visit our Help Center by clicking "Help" located on any
   PayPal page or email.
   Copyright © 2013 PayPal Inc. All rights reserved. PayPal is located at
   2211 N. First St., San Jose, CA 95131.

   [index.php] [index.php]
(Continue reading)

Permalink | Reply | 0 comments |
headers
Guy Helmer | 23 May 2013 23:20
Picon

xorg-server running on 10-current under VMware?

I've tried using drivers xf86-video-vmware (vmware) and xf86-video-vesa (vesa) for 10-current under
VMware Fusion. Regardless, the X server fails with the error:

> […]
> (==) VESA(0): Backing store disabled
> 
> Fatal server error:
> AddScreen/ScreenInit failed for driver 0
> 
> 
> Please consult the The X.Org Foundation support 
> 	 at http://wiki.x.org
>  for help. 
> Please also check the log file at "/var/log/Xorg.0.log" for additional information.
> 
> (==) VESA(0): Write-combining range (0x0,0x1000) was already clear
> (==) VESA(0): Write-combining range (0x0,0x1000) was already clear

or

> […]
> (==) vmware(0): Backing store disabled
> (==) vmware(0): Silken mouse enabled
> 
> Fatal server error:
> AddScreen/ScreenInit failed for driver 0
> 
> 
> Please consult the The X.Org Foundation support 
> 	 at http://wiki.x.org
(Continue reading)

Permalink | Reply | 5 comments |
headers
dt71 | 23 May 2013 08:50
Picon
Favicon

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.000000000 +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.
_______________________________________________
(Continue reading)

Permalink | Reply | 5 comments |
headers
Erich Dollansky | 23 May 2013 05:25

Fatal trap 3: breakpoint instruction fault

Hi,

I updated my system over night. It suddenly reboots and I find some 20
entries like this in /var/log/message:

May 23 10:05:28 X220 kernel: Fatal trap 3: breakpoint instruction fault
while in kernel mode 
May 23 10:05:28 X220 kernel: cpuid = 0; apic id = 00 
May 23 10:05:28 X220 kernel: instruction pointer	=
0x20:0xffffffff80809f7e 
May 23 10:05:28 X220 kernel: stack pointer	        =
0x28:0xffffff82336de7c0 
May 23 10:05:28 X220 kernel: frame pointer	        =
0x28:0xffffff82336de7e0 
May 23 10:05:28 X220 kernel: code segment		= base 0x0,
limit 0xfffff, type 0x1b 
May 23 10:05:28 X220 kernel: = DPL 0, pres 1, long 1, def32 0, gran 1 
May 23 10:05:28 X220 kernel: processor eflags = IOPL = 0 
May 23 10:05:28 X220 kernel: current process = 2043 (chrome) 
May 23 10:05:28 X220 kernel: trap number = 3 
May 23 10:05:28 X220 kernel:
panic: breakpoint instruction fault 
May 23 10:05:28 X220 kernel: cpuid = 0 
May 23 10:05:28 X220 kernel: KDB: enter: panic 
May 23 10:05:28 X220 kernel: 
May 23 10:05:28 X220 kernel: 

All messages have chrome as the current process but different values
for IP and SP.
(Continue reading)

Permalink | Reply | 4 comments |
headers
Mateusz Guzik | 23 May 2013 03:06
Picon

acct: shared rlimit object for exiting processes

When a process is exiting accounting code always allocates new rlimit,
copies old limits over and sets RLIMIT_FSIZE to RLIM_INFINITY.

Since I don't see any good for keeping old limits with exception of
RLIMIT_FSIZE, allocation each time looks unnecessary. Thus I propose the
following:
=========================

acct: create a special plimit object and set it for exiting processes
instead of allocating new one each time

We set all limits to RLIM_INFINITY which sould be ok (even though we
care only about RLIMT_FSIZE).

diff --git a/sys/kern/kern_acct.c b/sys/kern/kern_acct.c
index 3362112..af167d9 100644
--- a/sys/kern/kern_acct.c
+++ b/sys/kern/kern_acct.c
 <at>  <at>  -133,6 +133,7  <at>  <at>  static int		 acct_configured;
 static int		 acct_suspended;
 static struct vnode	*acct_vp;
 static struct ucred	*acct_cred;
+static struct plimit	*acct_limit;
 static int		 acct_flags;
 static struct sx	 acct_sx;

 <at>  <at>  -196,7 +197,7  <at>  <at>  int
 sys_acct(struct thread *td, struct acct_args *uap)
 {
 	struct nameidata nd;
(Continue reading)

Permalink | Reply | 0 comments |

Gmane