Re: Read-triggered corruption of swap backed MD devices
On Fri, May 24, 2013 at 12:19:44PM +1000, Lawrence Stewart wrote:
> 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.
Confirmed, and the following patch fixed the issue for me.
diff --git a/sys/dev/md/md.c b/sys/dev/md/md.c
index e871d8f..57c5b57 100644
--- a/sys/dev/md/md.c
+++ b/sys/dev/md/md.c
@@ -829,7 +829,9 @@ mdstart_swap(struct md_s *sc, struct bio *bp)
m = vm_page_grab(sc->object, i, VM_ALLOC_NORMAL |
VM_ALLOC_RETRY);
if (bp->bio_cmd == BIO_READ) {
- if (m->valid != VM_PAGE_BITS_ALL)
+ if (m->valid == VM_PAGE_BITS_ALL)
+ rv = VM_PAGER_OK;
+ else
rv = vm_pager_get_pages(sc->object, &m, 1, 0);
if (rv == VM_PAGER_ERROR) {
vm_page_wakeup(m);
@@ -854,6 +856,8 @@ mdstart_swap(struct md_s *sc, struct bio *bp)
} else if (bp->bio_cmd == BIO_WRITE) {
if (len != PAGE_SIZE && m->valid != VM_PAGE_BITS_ALL)
rv = vm_pager_get_pages(sc->object, &m, 1, 0);
+ else
+ rv = VM_PAGER_OK;
if (rv == VM_PAGER_ERROR) {
vm_page_wakeup(m);
break;
@@ -868,6 +872,8 @@ mdstart_swap(struct md_s *sc, struct bio *bp)
} else if (bp->bio_cmd == BIO_DELETE) {
if (len != PAGE_SIZE && m->valid != VM_PAGE_BITS_ALL)
rv = vm_pager_get_pages(sc->object, &m, 1, 0);
+ else
+ rv = VM_PAGER_OK;
if (rv == VM_PAGER_ERROR) {
vm_page_wakeup(m);
break;
pgpHpCj2tJyba.pgp
Description: PGP signature
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@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: r250633: make -j buildkernel: ports module: illegal option -- J
Le 24/05/2013 11:12, Anton Shterenlikht a écrit : > > 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 See here: http://lists.freebsd.org/pipermail/freebsd-current/2013-May/041976.html > Thanks > > Anton > > ___ > 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" > -- Florent Peterschmitt | /"\ ASCII Ribbon Campaign flor...@peterschmitt.fr| \ / - No HTML/RTF in E-mail +33 (0)6 64 33 97 92 | X - No proprietary attachments http://florent.peterschmitt.fr | / \ - Respect for open standards signature.asc Description: OpenPGP digital signature
Re: [PATCH] NAND Framework ONFI chip detection
Hi, current! I received a positive feedback from Grzegorz Bernacki (semihalf). He said that my patch is ok. Can anyone commit a proposed patch? 2013/5/21 Alexander Fedorov : > Hi all! > > I'm writing NAND Flash controller driver for my Hackberry board. > And I found that NAND Framework does not properly detecting ONFI > compiliant chips. > > First, ONFI specification says (p. 40 > http://www.onfi.org/~/media/ONFI/specs/ONFI_1_0_Gold.pdf): > >>The ONFI signature is the ASCII encoding of 'ONFI' where 'O' = 4Fh, 'N' = >>4Eh, 'F' = 46h, 'I' = 49h. > > But, current code check it for 'o', 'n', 'f', 'I'. > > Second, function "onfi_read_parameter" (nand_generic.c) read > parameters page using this construction: >>NANDBUS_READ_BUFFER(nandbus, params, sizeof(struct onfi_params)); > > So, structure onfi_params must be declared as packed. > > Proposed patch solves the problem for me. > Is this patch ok? nand_framework_onfi_probing.patch Description: Binary data ___ 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-server running on 10-current under VMware?
On May 23, 2013, at 23:20, Guy Helmer wrote: > 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 ... > Any hints? Maybe you can do what it suggests: 'Please also check the log file at "/var/log/Xorg.0.log" for additional information.' ? :-) -Dimitry ___ 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-server running on 10-current
Hi, Running 10-current_r250582, X fails to start with similar error message : Fatal server error: AddScreen/ScreenInit failed for driver 0 - Driver used is nvidia-driver-310-14 compiled from port. - Same behaviour using vesa-driver Previously 10-current_r247167 using the same driver ran X just fine In both cases, xorg.conf generated from nvidia-xconfig. here the log file : X.Org X Server 1.7.7 Release Date: 2010-05-04 X Protocol Version 11, Revision 0 Build Operating System: FreeBSD 10.0-CURRENT amd64 Current Operating System: FreeBSD P5E-WS 10.0-CURRENT FreeBSD 10.0-CURRENT #0: M on May 13 00:54:58 UTC 2013 r...@snap.freebsd.org:/usr/obj/usr/src/sys/GENER IC amd64 Build Date: 21 May 2013 12:33:14PM Current version of pixman: 0.24.2 Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: "/var/log/Xorg.0.log", Time: Thu May 23 08:50:24 2013 (==) Using config file: "/etc/X11/xorg.conf" (==) ServerLayout "Layout0" (**) |-->Screen "Screen0" (0) (**) | |-->Monitor "Monitor0" (**) | |-->Device "Device0" (**) |-->Input Device "Keyboard0" (**) |-->Input Device "Mouse0" (==) Automatically adding devices (==) Automatically enabling devices (**) FontPath set to: /usr/local/lib/X11/fonts/misc/:unscaled, /usr/local/lib/X11/fonts/100dpi/:unscaled, /usr/local/lib/X11/fonts/75dpi/:unscaled, /usr/local/lib/X11/fonts/misc/, /usr/local/lib/X11/fonts/Type1/, /usr/local/lib/X11/fonts/100dpi/, /usr/local/lib/X11/fonts/75dpi/, /usr/local/lib/X11/fonts/cyrillic/, /usr/local/lib/X11/fonts/TTF/ /usr/local/lib/X11/fonts/misc/, /usr/local/lib/X11/fonts/TTF/, /usr/local/lib/X11/fonts/OTF, /usr/local/lib/X11/fonts/Type1/, /usr/local/lib/X11/fonts/100dpi/, /usr/local/lib/X11/fonts/75dpi/ (==) ModulePath set to "/usr/local/lib/xorg/modules" (WW) AllowEmptyInput is on, devices using drivers 'kbd', 'mouse' or 'vmmouse' wi ll be disabled. (WW) Disabling Keyboard0 (WW) Disabling Mouse0 (II) Loader magic: 0x7b64e0 (II) Module ABI versions: X.Org ANSI C Emulation: 0.4 X.Org Video Driver: 6.0 X.Org XInput driver : 7.0 X.Org Server Extension : 2.0 (--) Using syscons driver with X support (version 2.0) (--) using VT number 9 (--) PCI:*(0:1:0:0) 10de:10c3:196e:080b NVIDIA Corporation GT218 [GeForce 8400 G S Rev. 3] rev 162, Mem @ 0xfd00/16777216, 0xd000/268435456, 0xce00/3 3554432, I/O @ 0xac00/128, BIOS @ 0x/65536 (II) LoadModule: "extmod" (II) Loading /usr/local/lib/xorg/modules/extensions/libextmod.so (II) Module extmod: vendor="X.Org Foundation" compiled for 1.7.7, module version = 1.0.0 Module class: X.Org Server Extension ABI class: X.Org Server Extension, version 2.0 (II) Loading extension MIT-SCREEN-SAVER (II) Loading extension XFree86-VidModeExtension (II) Loading extension XFree86-DGA (II) Loading extension DPMS (II) Loading extension XVideo (II) Loading extension XVideo-MotionCompensation (II) Loading extension X-Resource (II) LoadModule: "dbe" (II) Loading /usr/local/lib/xorg/modules/extensions/libdbe.so (II) Module dbe: vendor="X.Org Foundation" compiled for 1.7.7, module version = 1.0.0 Module class: X.Org Server Extension ABI class: X.Org Server Extension, version 2.0 (II) Loading extension DOUBLE-BUFFER (II) LoadModule: "glx" (II) Loading /usr/local/lib/xorg/modules/extensions/libglx.so (II) Module glx: vendor="NVIDIA Corporation" compiled for 4.0.2, module version = 1.0.0 Module class: X.Org Server Extension (II) NVIDIA GLX Module 310.44 Wed Mar 27 15:00:45 PDT 2013 (II) Loading extension GLX (II) LoadModule: "record" (II) Loading /usr/local/lib/xorg/modules/extensions/librecord.so (II) Module record: vendor="X.Org Foundation" compiled for 1.7.7, module version = 1.13.0 Module class: X.Org Server Extension ABI class: X.Org Server Extension, version 2.0 (II) Loading extension RECORD (II) LoadModule: "dri" (II) Loading /usr/local/lib/xorg/modules/extensions/libdri.so (II) Module dri: vendor="X.Org Foundation" compiled for 1.7.7, module version = 1.0.0 ABI class: X.Org Server Extension, version 2.0 (II) Loading extension XFree86-DRI (II) LoadModule: "dri2" (II) Loading /usr/local/lib/xorg/modules/extensions/libdri2.so (II) Module dri2: vendor="X.Org Foundation" compiled for 1.7.7, module version = 1.1.0 ABI class: X.Org Server Extension, version 2.0 (II) Loading extension DRI2 (II) LoadModule: "nvidia" (II) Loading /usr/local/lib/xorg/modules/drivers/nvidia_drv.so (II) Module nvidia: vendor="NVIDIA Corporation" compiled for 4.0.2, module version = 1.0.0 Module class: X.Org Video Driver (II) NVIDIA dlloader X Driver 310.44 Wed Mar 27 14:44:32 PDT 2013 (II) NVIDIA Unified Driver for all Supported NVIDIA GPUs (II) Primary Device is: PCI 01@00:00:0 (II) Loading sub module "wfb" (II) LoadModule: "wf
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@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 signature.asc Description: This is a digitally signed message part
Re: xorg-server running on 10-current under VMware?
On Thu, 23 May 2013 16:20:35 -0500, Guy Helmer wrote: > 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: > > > [...] > > 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. > > > > Segmentation fault at address 0x290 > > > > FatalError re-entered, aborting > > Caught signal 11 (Segmentation fault). Server aborting > > Any hints? I'm observing the same behaviour with 10-current running as guest in VirtualBox. Program received signal SIGSEGV, Segmentation fault. 0x00454bec in dixLookupPrivate (privates=0x290, key=0x804e2be38) at privates.c:79 79 return *key && *privates && Current language: auto; currently minimal (gdb) bt #0 0x00454bec in dixLookupPrivate (privates=0x290, key=0x804e2be38) at privates.c:79 #1 0x000804c27310 in ShadowLeaveVT () from /usr/local/lib/xorg/modules/libshadowfb.so #2 0x0047a076 in AbortDDX () at xf86Init.c:1249 #3 0x004739fd in AbortServer () at log.c:404 #4 0x004732b6 in FatalError (f=) at log.c:529 #5 0x004799a9 in InitOutput (pScreenInfo=0x7c5560, argc=3, argv=0x7fffdc38) at xf86Init.c:1057 #6 0x00431f6e in main (argc=3, argv=0x7fffdc38, envp=) at main.c:204 The segmentation fault in dixLookupPrivate() seems like a subsequent fault of xf86Init.c:1043 scr_index = AddScreen(xf86Screens[i]->ScreenInit, argc, argv); indicating failure to add the screen. Building xorg-server with gcc make USE_GCC=any or with clang and -O0 mage CFLAGS=-O0 gives me an X server that appears to work (displays root weave, xterm, and twm). -- Thomas Mueller ___ 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-server running on 10-current under VMware?
On May 24, 2013, at 6:14 AM, Dimitry Andric wrote: > On May 23, 2013, at 23:20, Guy Helmer wrote: >> 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 > ... >> Any hints? > > Maybe you can do what it suggests: 'Please also check the log file at > "/var/log/Xorg.0.log" for additional information.' ? :-) Thanks, but I copied+pasted this from the Xorg.0.log. I haven't found anything in Xorg.0.log that seems to indicate why AddScreen/ScreenInit failed. Guy ___ 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: Read-triggered corruption of swap backed MD devices
Fast work, Konstantin! This looks like it may be the solution to an
intermittent and inexplicable bug we've been seeing that we feared may
be data corruption in ZFS.
On Fri, May 24, 2013 at 2:53 AM, Konstantin Belousov
wrote:
> On Fri, May 24, 2013 at 12:19:44PM +1000, Lawrence Stewart wrote:
>> 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.
>
> Confirmed, and the following patch fixed the issue for me.
>
> diff --git a/sys/dev/md/md.c b/sys/dev/md/md.c
> index e871d8f..57c5b57 100644
> --- a/sys/dev/md/md.c
> +++ b/sys/dev/md/md.c
> @@ -829,7 +829,9 @@ mdstart_swap(struct md_s *sc, struct bio *bp)
> m = vm_page_grab(sc->object, i, VM_ALLOC_NORMAL |
> VM_ALLOC_RETRY);
> if (bp->bio_cmd == BIO_READ) {
> - if (m->valid != VM_PAGE_BITS_ALL)
> + if (m->valid == VM_PAGE_BITS_ALL)
> + rv = VM_PAGER_OK;
> + else
> rv = vm_pager_get_pages(sc->object, &m, 1, 0);
> if (rv == VM_PAGER_ERROR) {
> vm_page_wakeup(m);
> @@ -854,6 +856,8 @@ mdstart_swap(struct md_s *sc, struct bio *bp)
> } else if (bp->bio_cmd == BIO_WRITE) {
> if (len != PAGE_SIZE && m->valid != VM_PAGE_BITS_ALL)
> rv = vm_pager_get_pages(sc->object, &m, 1, 0);
> + else
> + rv = VM_PAGER_OK;
> if (rv == VM_PAGER_ERROR) {
> vm_page_wakeup(m);
> break;
> @@ -868,6 +872,8 @@ mdstart_swap(struct md_s *sc, struct bio *bp)
> } else if (bp->bio_cmd == BIO_DELETE) {
> if (len != PAGE_SIZE && m->valid != VM_PAGE_BITS_ALL)
> rv = vm_pager_get_pages(sc->object, &m, 1, 0);
> + else
> + rv = VM_PAGER_OK;
> if (rv == VM_PAGER_ERROR) {
> vm_page_wakeup(m);
> break;
___
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-server running on 10-current under VMware?
On May 24, 2013, at 8:08 AM, Thomas Mueller wrote: > On Thu, 23 May 2013 16:20:35 -0500, Guy Helmer wrote: >> 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: >> >>> [...] >>> 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. >>> >>> Segmentation fault at address 0x290 >>> >>> FatalError re-entered, aborting >>> Caught signal 11 (Segmentation fault). Server aborting >> >> Any hints? > > I'm observing the same behaviour with 10-current running as guest in > VirtualBox. > > Program received signal SIGSEGV, Segmentation fault. > 0x00454bec in dixLookupPrivate (privates=0x290, key=0x804e2be38) at > privates.c:79 > 79 return *key && *privates && > Current language: auto; currently minimal > (gdb) bt > #0 0x00454bec in dixLookupPrivate (privates=0x290, key=0x804e2be38) > at privates.c:79 > #1 0x000804c27310 in ShadowLeaveVT () from > /usr/local/lib/xorg/modules/libshadowfb.so > #2 0x0047a076 in AbortDDX () at xf86Init.c:1249 > #3 0x004739fd in AbortServer () at log.c:404 > #4 0x004732b6 in FatalError (f=) at log.c:529 > #5 0x004799a9 in InitOutput (pScreenInfo=0x7c5560, argc=3, > argv=0x7fffdc38) at xf86Init.c:1057 > #6 0x00431f6e in main (argc=3, argv=0x7fffdc38, envp= optimized out>) at main.c:204 > > The segmentation fault in dixLookupPrivate() seems like a subsequent fault of > xf86Init.c:1043 scr_index = AddScreen(xf86Screens[i]->ScreenInit, argc, > argv); > indicating failure to add the screen. > > Building xorg-server with gcc > make USE_GCC=any > or with clang and -O0 > mage CFLAGS=-O0 > gives me an X server that appears to work (displays root weave, xterm, > and twm). Thank you! Rebuilding as you suggested resolved the problem for me. Guy ___ 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"
[head tinderbox] failure on ia64/ia64
TB --- 2013-05-24 16:31:25 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-05-24 16:31:25 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-05-24 16:31:25 - starting HEAD tinderbox run for ia64/ia64 TB --- 2013-05-24 16:31:25 - cleaning the object tree TB --- 2013-05-24 16:31:25 - /usr/local/bin/svn stat /src TB --- 2013-05-24 16:31:29 - At svn revision 250967 TB --- 2013-05-24 16:31:30 - building world TB --- 2013-05-24 16:31:30 - CROSS_BUILD_TESTING=YES TB --- 2013-05-24 16:31:30 - MAKEOBJDIRPREFIX=/obj TB --- 2013-05-24 16:31:30 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-05-24 16:31:30 - SRCCONF=/dev/null TB --- 2013-05-24 16:31:30 - TARGET=ia64 TB --- 2013-05-24 16:31:30 - TARGET_ARCH=ia64 TB --- 2013-05-24 16:31:30 - TZ=UTC TB --- 2013-05-24 16:31:30 - __MAKE_CONF=/dev/null TB --- 2013-05-24 16:31:30 - cd /src TB --- 2013-05-24 16:31:30 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Fri May 24 16:31:37 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Fri May 24 18:02:41 UTC 2013 TB --- 2013-05-24 18:02:41 - generating LINT kernel config TB --- 2013-05-24 18:02:41 - cd /src/sys/ia64/conf TB --- 2013-05-24 18:02:41 - /usr/bin/make -B LINT TB --- 2013-05-24 18:02:41 - cd /src/sys/ia64/conf TB --- 2013-05-24 18:02:41 - /usr/sbin/config -m LINT TB --- 2013-05-24 18:02:41 - building LINT kernel TB --- 2013-05-24 18:02:41 - CROSS_BUILD_TESTING=YES TB --- 2013-05-24 18:02:41 - MAKEOBJDIRPREFIX=/obj TB --- 2013-05-24 18:02:41 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-05-24 18:02:41 - SRCCONF=/dev/null TB --- 2013-05-24 18:02:41 - TARGET=ia64 TB --- 2013-05-24 18:02:41 - TARGET_ARCH=ia64 TB --- 2013-05-24 18:02:41 - TZ=UTC TB --- 2013-05-24 18:02:41 - __MAKE_CONF=/dev/null TB --- 2013-05-24 18:02:41 - cd /src TB --- 2013-05-24 18:02:41 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Fri May 24 18:02:41 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] *** Error code 1 Stop. make: stopped in /obj/ia64.ia64/src/sys/LINT *** Error code 1 Stop. make: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-05-24 18:22:53 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-05-24 18:22:53 - ERROR: failed to build LINT kernel TB --- 2013-05-24 18:22:53 - 5432.63 user 888.20 system 6687.74 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-ia64-ia64.full ___ 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: 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,
we...@uni-mainz.de |55099 Mainz, Tel: +49(6131)39-26361, FAX: +49(6131)39-26407
___
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: Intel D2500CC motherboard and strange RS232/UART behavior
Hello, Jürgen.
You wrote 24 мая 2013 г., 23:15:17:
WJ> According to the ACPI of the board, uart0 and uart 2
WJ> use IRQ 3 and
WJ> IRQ (Edge, ActiveLow, Shared, )
WJ>{3}
WJ> uart1 and uart3 use IRQ 4
WJ> IRQ (Edge, ActiveLow, Shared, )
WJ>{4}
WJ> ioapic_config_intr is called with trig == INTR_TRIGGER_EDGE and
WJ> pol == INTR_POLARITY_LOW.
WJ> The combinatation of Edge and ActiveLow seems kind of broken.
WJ> Forcing the polarity in ioapic_config_intr to INTR_POLARITY_HIGH
WJ> and disabling uart 2 and uart 3 results in two working serial
WJ> interfaces.
WJ> So what is the correct fix to this?
I've tried to disable ACPI access to these UARTs at all, then only
two of them are detected, but they don't work either. And I cannot
disable 2 and 3, as screen I have attached to this box (old IBM-made
LCD from register/cashier machine, which works perfectly with FreeBSD
default text console on this MoBo) cannot show text (!) BIOS setup
screen to me -- it shows only blue noise and looks like compeltely
out-of-sync. I need to bring this box to some other dispaly and try
to disable these two UARTs AND disable ACPI for them with loader
tunable.
--
// Black Lion AKA Lev Serebryakov
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: CURRENT: system crashing while shuting down -> files system corruption
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 05/24/13 06:50, O. Hartmann wrote: > 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@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 Have you tried 'svn upgrade' by chance? Cheers, - -- Xin LI https://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -BEGIN PGP SIGNATURE- iQEcBAEBCgAGBQJRn+oaAAoJEG80Jeu8UPuzukkIAKadxoGeM+9QiJim5QIV6uWx GgY2Doz04R3+Ow89IRCQdrrlgsG/lJkR7hV7XD9H4dfbD8Fkh1X79vnRcJ/CSSPg OZu3FgVHE4CVVJZLMFv+4wM9VIPeGMVBV8wnbP2CcleqJlJWDoI4OUddHhEeOHoU 8qqjylxUUcvijWj6c4P3MZloiopE8L9mHZmyuhh85LYszr/2lRCPeFjXQh/b+9C0 RsC0fZoJtCr/X+8ekvj4SIGwOTIvyJyXCfeNaHEhlGFj86bjuEA3OIwG1UOMebMv y9hTeNrso0eB32BDNOPqwpL6pxnTS7rKS2Wxp/16zb9Lh/Hiui8UILRhwwbPcy4= =HGvA -END PGP SIGNATURE- ___ 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: CURRENT: system crashing while shuting down -> files system corruption
On Fri, May 24, 2013 at 3:50 AM, O. Hartmann wrote: > 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@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 > Coincidentally, I get that exact same error message today when I exported an SVN /usr/src tree to a raspberry-pi host from an amd64 system. I tried the script and it complains about I/O errors... dave c ___ 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: Unexpected behavior change [FreeBSD]make -> bmake
Using bmake in ports instead of building it into base system. On Fri, May 24, 2013 at 1:03 AM, David O'Brien wrote: > 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 (obr...@freebsd.org) > ___ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > -- (c) http://glx.me/ ___ 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"
[head tinderbox] failure on ia64/ia64
TB --- 2013-05-25 03:41:54 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-05-25 03:41:54 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-05-25 03:41:54 - starting HEAD tinderbox run for ia64/ia64 TB --- 2013-05-25 03:41:54 - cleaning the object tree TB --- 2013-05-25 03:43:10 - /usr/local/bin/svn stat /src TB --- 2013-05-25 03:43:14 - At svn revision 250973 TB --- 2013-05-25 03:43:15 - building world TB --- 2013-05-25 03:43:15 - CROSS_BUILD_TESTING=YES TB --- 2013-05-25 03:43:15 - MAKEOBJDIRPREFIX=/obj TB --- 2013-05-25 03:43:15 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-05-25 03:43:15 - SRCCONF=/dev/null TB --- 2013-05-25 03:43:15 - TARGET=ia64 TB --- 2013-05-25 03:43:15 - TARGET_ARCH=ia64 TB --- 2013-05-25 03:43:15 - TZ=UTC TB --- 2013-05-25 03:43:15 - __MAKE_CONF=/dev/null TB --- 2013-05-25 03:43:15 - cd /src TB --- 2013-05-25 03:43:15 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sat May 25 03:43:23 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] *** Error code 1 Stop. make: stopped in /src *** Error code 1 Stop. make: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-05-25 05:03:16 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-05-25 05:03:16 - ERROR: failed to build world TB --- 2013-05-25 05:03:16 - 3824.56 user 690.24 system 4882.36 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-ia64-ia64.full ___ 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"
[head tinderbox] failure on mips/mips
TB --- 2013-05-25 05:03:17 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-05-25 05:03:17 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-05-25 05:03:17 - starting HEAD tinderbox run for mips/mips TB --- 2013-05-25 05:03:17 - cleaning the object tree TB --- 2013-05-25 05:03:17 - /usr/local/bin/svn stat /src TB --- 2013-05-25 05:03:30 - At svn revision 250973 TB --- 2013-05-25 05:03:31 - building world TB --- 2013-05-25 05:03:31 - CROSS_BUILD_TESTING=YES TB --- 2013-05-25 05:03:31 - MAKEOBJDIRPREFIX=/obj TB --- 2013-05-25 05:03:31 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-05-25 05:03:31 - SRCCONF=/dev/null TB --- 2013-05-25 05:03:31 - TARGET=mips TB --- 2013-05-25 05:03:31 - TARGET_ARCH=mips TB --- 2013-05-25 05:03:31 - TZ=UTC TB --- 2013-05-25 05:03:31 - __MAKE_CONF=/dev/null TB --- 2013-05-25 05:03:31 - cd /src TB --- 2013-05-25 05:03:31 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sat May 25 05:03:41 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] *** Error code 1 Stop. make: stopped in /src *** Error code 1 Stop. make: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-05-25 05:58:25 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-05-25 05:58:25 - ERROR: failed to build world TB --- 2013-05-25 05:58:25 - 2400.95 user 572.86 system 3308.20 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-mips-mips.full ___ 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"
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 .obj/release-shared/qsize.o tools/qsize.cpp In file included from tools/qsimd.cpp:42: In file included from tools/qsimd_p.h:203: In file included from /usr/include/clang/3.3/mm3dnow.h:27: /usr/include/clang/3.3/mmintrin.h:28:2: error: "MMX instruction set not enabled" #error "MMX instruction set not enabled" ^ In file included from tools/qsimd.cpp:42: In file included from tools/qsimd_p.h:203: /usr/include/clang/3.3/mm3dnow.h:37:19: error: unknown type name '__m64' static __inline__ __m64 __attribute__((__always_inline__, __nodebug__)) ^ /usr/include/clang/3.3/mm3dnow.h:37:25: error: expected unqualified-id static __inline__ __m64 __attribute__((__always_inline__, __nodebug__)) ^ /usr/include/clang/3.3/mm3dnow.h:42:19: error: unknown type name '__m64' static __inline__ __m64 __attribute__((__always_inline__, __nodebug__)) ^ /usr/include/clang/3.3/mm3dnow.h:42:25: error: expected unqualified-id static __inline__ __m64 __attribute__((__always_inline__, __nodebug__)) ^ /usr/include/clang/3.3/mm3dnow.h:47:19: error: unknown type name '__m64' static __inline__ __m64 __attribute__((__always_inline__, __nodebug__)) ^ /usr/include/clang/3.3/mm3dnow.h:47:25: error: expected unqualified-id static __inline__ __m64 __attribute__((__always_inline__, __nodebug__)) ^ /usr/include/clang/3.3/mm3dnow.h:52:19: error: unknown type name '__m64' static __inline__ __m64 __attribute__((__always_inline__, __nodebug__)) ^ /usr/include/clang/3.3/mm3dnow.h:52:25: error: expected unqualified-id static __inline__ __m64 __attribute__((__always_inline__, __nodebug__)) ^ /usr/include/clang/3.3/mm3dnow.h:57:19: error: unknown type name '__m64' static __inline__ __m64 __attribute__((__always_inline__, __nodebug__)) ^ /usr/include/clang/3.3/mm3dnow.h:57:25: error: expected unqualified-id static __inline__ __m64 __attribute__((__always_inline__, __nodebug__)) ^ /usr/include/clang/3.3/mm3dnow.h:62:19: error: unknown type name '__m64' static __inline__ __m64 __attribute__((__always_inline__, __nodebug__)) ^ /usr/include/clang/3.3/mm3dnow.h:62:25: error: expected unqualified-id static __inline__ __m64 __attribute__((__always_inline__, __nodebug__)) ^ /usr/include/clang/3.3/mm3dnow.h:67:19: error: unknown type name '__m64' static __inline__ __m64 __attribute__((__always_inline__, __nodebug__)) ^ /usr/include/clang/3.3/mm3dnow.h:67:25: error: expected unqualified-id static __inline__ __m64 __attribute__((__always_inline__, __nodebug__)) ^ /usr/include/clang/3.3/mm3dnow.h:72:19: error: unknown type name '__m64' static __inline__ __m64 __attribute__((__always_inline__, __nodebug__)) ^ /usr/include/clang/3.3/mm3dnow.h:72:25: error: expected unqualified-id static __inline__ __m64 __attribute__((__always_inline__, __nodebug__))
[head tinderbox] failure on mips64/mips
TB --- 2013-05-25 05:48:19 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-05-25 05:48:19 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-05-25 05:48:19 - starting HEAD tinderbox run for mips64/mips TB --- 2013-05-25 05:48:19 - cleaning the object tree TB --- 2013-05-25 05:48:19 - /usr/local/bin/svn stat /src TB --- 2013-05-25 05:48:23 - At svn revision 250973 TB --- 2013-05-25 05:48:24 - building world TB --- 2013-05-25 05:48:24 - CROSS_BUILD_TESTING=YES TB --- 2013-05-25 05:48:24 - MAKEOBJDIRPREFIX=/obj TB --- 2013-05-25 05:48:24 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-05-25 05:48:24 - SRCCONF=/dev/null TB --- 2013-05-25 05:48:24 - TARGET=mips TB --- 2013-05-25 05:48:24 - TARGET_ARCH=mips64 TB --- 2013-05-25 05:48:24 - TZ=UTC TB --- 2013-05-25 05:48:24 - __MAKE_CONF=/dev/null TB --- 2013-05-25 05:48:24 - cd /src TB --- 2013-05-25 05:48:24 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sat May 25 05:48:31 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] *** Error code 1 Stop. make: stopped in /src *** Error code 1 Stop. make: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-05-25 06:41:59 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-05-25 06:41:59 - ERROR: failed to build world TB --- 2013-05-25 06:41:59 - 2415.38 user 530.23 system 3219.50 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-mips64-mips.full ___ 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: compiling qt4-corelib fails on 10-CURRENT r250588
El día Saturday, May 25, 2013 a las 08:22:51AM +0200, Matthias Apitz escribió: > > 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 ... I just found with Don Google that this was fixed in KDE4 two weeks ago; I should have searched before; sorry for the noise; matthias -- Matthias Apitz | /"\ ASCII Ribbon Campaign: www.asciiribbon.org E-mail: g...@unixarea.de | \ / - No HTML/RTF in E-mail WWW: http://www.unixarea.de/ | X - No proprietary attachments phone: +49-170-4527211 | / \ - Respect for open standards ___ 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"
