[head tinderbox] failure on amd64/amd64
TB --- 2011-10-24 06:20:00 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-10-24 06:20:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2011-10-24 06:20:00 - cleaning the object tree TB --- 2011-10-24 06:20:06 - cvsupping the source tree TB --- 2011-10-24 06:20:06 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/amd64/amd64/supfile TB --- 2011-10-24 06:20:59 - building world TB --- 2011-10-24 06:20:59 - CROSS_BUILD_TESTING=YES TB --- 2011-10-24 06:20:59 - MAKEOBJDIRPREFIX=/obj TB --- 2011-10-24 06:20:59 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-10-24 06:20:59 - SRCCONF=/dev/null TB --- 2011-10-24 06:20:59 - TARGET=amd64 TB --- 2011-10-24 06:20:59 - TARGET_ARCH=amd64 TB --- 2011-10-24 06:20:59 - TZ=UTC TB --- 2011-10-24 06:20:59 - __MAKE_CONF=/dev/null TB --- 2011-10-24 06:20:59 - cd /src TB --- 2011-10-24 06:20:59 - /usr/bin/make -B buildworld World build started on Mon Oct 24 06:21:00 UTC 2011 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 [...] cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/amd64/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -fstack-protector! -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_objset.c cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/amd64/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -fstack-protector! -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_traverse.c cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/amd64/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -fstack-protector! -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_tx.c cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common
Current problem reports assigned to freebsd-amd64@FreeBSD.org
Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description o amd64/161949 amd64 [kern] 64-bit structures are used even with 32-bit cod o kern/160833 amd64 Keyboard USB doesn't work o amd64/160561 amd64 no C-states on atom D525 o amd64/157386 amd64 [powerd] Enabling powerd(8) with default settings on I o amd64/156106 amd64 [boot] boot0 fails to start o amd64/155135 amd64 [boot] Does Not Boot On a Very Standard Hardware o amd64/154957 amd64 [boot] Install boot CD won't boot up - keeps rebooting o amd64/154629 amd64 [panic] Fatal trap 9: general protection fault while i o amd64/153935 amd64 [hang] system hangs while trying to do 'shutdown -h no o amd64/153831 amd64 [boot] CD bootloader won't on Tyan s2912G2nr o amd64/153496 amd64 [hyper-v] [install] Install on Hyper-V leaves corrupt o amd64/153372 amd64 [panic] kernel panic o amd64/153175 amd64 [amd64] Kernel Panic on only FreeBSD 8 amd64 o amd64/152874 amd64 [install] 8.1 install fails where 7.3 works due to lac o amd64/152430 amd64 [boot] HP ProLiant Microserver n36l cannot boot into i o amd64/151385 amd64 [boot] Installation hangs on MacBook o amd64/150170 amd64 [patch] [amd64] [headers] SIG_ATOMIC_MIN/SIG_ATOMIC_MA o amd64/145991 amd64 [NOTES] [patch] Add a requires line to /sys/amd64/conf o amd64/144405 amd64 [build] [patch] include /usr/obj/lib32 in cleanworld t s amd64/143173 amd64 [ata] Promise FastTrack TX4 + SATA DVD, installer can' f amd64/141413 amd64 [hang] Tyan 2881 m3289 SMDC freeze f amd64/141060 amd64 [install] Can't install 8.0-RELEASE on the server wher o amd64/140715 amd64 [boot] Dell M600 Blade fails to boot 7.2+ 64 bit o amd64/139998 amd64 [panic][net] 7.2 amd64 panic in rtrequest1_fib o amd64/139924 amd64 [boot] cd or dvd not load o amd64/137942 amd64 [pci] 8.0-BETA2 having problems with Asus M2N-SLI-delu o amd64/135265 amd64 [mpt] Boot from install cd hangs on HP DL160 G5 with L o amd64/135040 amd64 [ata] FreeBSD/amd64 does not (always) detect disk on S o amd64/133977 amd64 [panic] [ffs] panic: ffs_blkfree: freeing free block o amd64/133701 amd64 Recompiling the kernel with k8temp or smbios break GEO o amd64/132574 amd64 [boot] [hang] Freeze on bootstrap loader (CD) using AT o amd64/131456 amd64 [acpi] [ata] ACPI ATA problems s amd64/131209 amd64 [panic] [bce] 7.1-STABLE amd64 crash - m0 NULL o amd64/130368 amd64 [hang] Switching from xorg to console locks up compute o amd64/129889 amd64 [boot] [hang] The booting process stops at the line mo o amd64/129426 amd64 [panic] FreeBSD 7.0 crash after subdiskXX: detached o amd64/129315 amd64 [em] amd64 motherboard: Intel DG965WH motherboard comp f amd64/128765 amd64 [install] Install CD loads to Install choices but stop o amd64/127640 amd64 [amd64] gcc(1) will not build shared libraries with -f o amd64/125002 amd64 [install] amd64, SATA hard disks not detected o amd64/124432 amd64 [panic] 7.0-STABLE panic: invalbuf: dirty bufs o amd64/122549 amd64 7.0-RELEASE-amd64-bootonly.iso doesn't work w/ serial o amd64/120202 amd64 [amd64] [patch] [panic] kernel panic at start_all_aps, f amd64/117296 amd64 [ata] I don`t see second SATA IDE on VIA VT8237A f amd64/116620 amd64 [hang] ifconfig spins when creating carp(4) device on s amd64/115815 amd64 [ata] [request] Gigabyte GA-M61P-S3 Motherboard unsupp o amd64/115194 amd64 LCD screen remains blank after Dell XPS M1210 lid is c o amd64/91405 amd64 [asr] [panic] Kernel panic caused by asr on 6.0-amd64 48 problems total. ___ freebsd-amd64@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 To unsubscribe, send any mail to freebsd-amd64-unsubscr...@freebsd.org
Re: 32-bit binaries (e.g. wine) and 64-bit kernel structures
On Sunday, October 23, 2011 7:04:51 pm Li-Lun Leland Wang wrote: Hi, Although I only encounter this kind of problem when running wine (because it is one of the few ports that need to compile into 32-bit), it is a problem of i386 binaries on x64 FreeBSD in general. The problem that I'm running into recently is http://bugs.winehq.org/show_bug.cgi?id=28857 . In short, wine recently implemented GetUdpTable() for Mac OS and BSD. It uses sysctlbyname() to get net.inet.udp.pcblist, and parses it into xinpgen structures. However, the size of xinpgen is different on i386 and x64. As a result, when I run applications that call GetUdpTable(), the kernel supplies wine with 64-bit structures, while wine expects 32-bit structures, and crashes. They decided that this is a FreeBSD bug rather than a wine bug, and that the kernel or LD should know a 32-bit binary is being run and return proper structures, as is done in Mac OS. xinpgen is not the only structure of wrong sizes for 32-bit binaries on x64. A while ago I was trying to make my usb gamepad work on wine using the ugen device. libusbhid uses ioctl to get the usb_gen_descriptor structure, which is also of different sizes on i386 and x64. I had to manually pad the pointers to 64-bit and build a custom libusbhid for it to work. As it stands, they will probably not fix GetUdpTable() on wine side, and any windows applications that uses GetUdpTable() will not run properly in wine on FreeBSD x64. Do we have plans to fix this kind of problems in general? Although wine port on FreeBSD is only supported for ARCH=i386, could there be workarounds? Fixing this problem generically is very hard. Instead, we have patched individual sysctls and ioctls on a case-by-case basis. I do think newer interfaces often opt to use fixed-size types so that the structure is the same for both 32-bit and 64-bit, but that will not work for existing interfaces. -- John Baldwin ___ freebsd-amd64@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 To unsubscribe, send any mail to freebsd-amd64-unsubscr...@freebsd.org
Re: 32-bit binaries (e.g. wine) and 64-bit kernel structures
On Mon, Oct 24, 2011 at 7:01 AM, per...@pluto.rain.com wrote: Li-Lun \Leland\ Wang llw...@infor.org wrote: ... the kernel or LD should know a 32-bit binary is being run and return proper structures, as is done in Mac OS. ... Do we have plans to fix this kind of problems in general? Although wine port on FreeBSD is only supported for ARCH=i386, could there be workarounds? Does it work if you run the 32-bit app in a 32-bit jail? If so, it might be a workaround (or, arguably, a solution). I can't test the same app directly in the 32-bit jail because a lot of things (e.g. certain devices in the devfs) are not available in the jail. However, I do believe the 64-bit kernel returns 64-bit structures even in 32-bit jails. -- llwang ___ freebsd-amd64@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 To unsubscribe, send any mail to freebsd-amd64-unsubscr...@freebsd.org
amd64/161968: renaming snapshot with -r including a zvol snapshot causes total ZFS freeze/lockup
Number: 161968 Category: amd64 Synopsis: renaming snapshot with -r including a zvol snapshot causes total ZFS freeze/lockup Confidential: no Severity: critical Priority: high Responsible:freebsd-amd64 State: open Quarter: Keywords: Date-Required: Class: sw-bug Submitter-Id: current-users Arrival-Date: Mon Oct 24 15:20:00 UTC 2011 Closed-Date: Last-Modified: Originator: Peter Maloney Release:8.2-STABLE FreeBSD 8.2-STABLE #0: Tue Sep 27 16:27:57 CEST 2011 r...@bcnastest2.bc.local:/usr/obj/usr/src/sys/GENERIC amd64 Organization: Brockmann Consult Environment: FreeBSD bcnas1.bc.local 8.2-STABLE FreeBSD 8.2-STABLE #0: Thu Sep 29 15:06:03 CEST 2011 r...@bcnas1.bc.local:/usr/obj/usr/src/sys/GENERIC amd64 Description: renaming snapshot with -r including a zvol snapshot causes total ZFS freeze/lockup/deadlock. After it is locked up, any command using zfs zpool sysctl -a, or NFS exports will freeze. And shutdown -r will not restart the system, only shut it down until it says the disks are all synced. CTRL+T done after zfs or zpool shows state spa_namespace_lock. Done after sysctl -a shows state g_waitfor_event. Most of the time, a simple zfs rename does not cause a lockup, however with a specific snapshot on one system, renaming it always causes a lockup, and on every other 8-STABLE system I have, my script always causes a lockup after a few loops. My FreeBSD 8-STABLE was installed as 8.2 release plus the mps driver, and then cvsup using this cvsupfile (removed comments): *default host=cvsup.de.FreeBSD.org *default base=/var/db *default prefix=/usr *default release=cvs tag=RELENG_8 *default delete use-rel-suffix *default date=2011.09.27.00.00.00 *default compress src-all (and the same freeze result occurs with date changed to today, Oct. 24th) # zpool get all big NAME PROPERTY VALUE SOURCE big size 39.8G - big capacity 24% - big altroot- default big health ONLINE - big guid 14576708073682355899 default big version28 default big bootfs - default big delegation on default big autoreplaceon local big cachefile - default big failmode continuelocal big listsnapshots on local big autoexpand off default big dedupditto 0 default big dedupratio 1.00x - big free 30.1G - big allocated 9.64G - big readonly off - # zfs get all big NAME PROPERTY VALUE SOURCE big type filesystem - big creation Thu Jul 21 11:48 2011 - big used 4.80G - big available 14.7G - big referenced4.80G - big compressratio 1.00x - big mounted yes- big quota none default big reservation none default big recordsize128K default big mountpoint/big default big sharenfs offdefault big checksum on default big compression offdefault big atime on default big devices on default big exec on default big setuidon default big readonly offdefault big jailedoffdefault big snapdir visiblelocal big aclmode discarddefault big aclinheritrestricted default big canmount on default big xattr offtemporary big copies1 default big version 4 - big utf8only off- big normalization none - big casesensitivity sensitive - big vscan offdefault big nbmandoffdefault big sharesmb offdefault big refquota none default big refreservationnone default big primarycache alldefault big secondarycachealldefault big usedbysnapshots 0 - big usedbydataset 4.80G - big usedbychildren6.70M - big
Re: 32-bit binaries (e.g. wine) and 64-bit kernel structures
Li-Lun \Leland\ Wang llw...@infor.org wrote: a lot of things (e.g. certain devices in the devfs) are not available in the jail. I have gotten the impression that there's a way to fix that -- it involves something along the lines of a nullfs mount IIRC -- but I'm by no means an expert on jails. ... I do believe the 64-bit kernel returns 64-bit structures even in 32-bit jails. That is arguably a bug in the jail support :( ___ freebsd-amd64@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 To unsubscribe, send any mail to freebsd-amd64-unsubscr...@freebsd.org
