Re: [CFT] Ralink RT2860, RT2870, RT3060, RT3090 support
Hi, FWIW, device timeout may just be watchdog related race conditions, rather than an actual hardware device timeout. I have the same issues in ath(4). I need to fix a whole lot of locking constructs before I can fix 'that'. Adrian ___ 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: Binary packages for LibreOffice 3.5 or 3.4
on 07/05/2012 01:58 Baptiste Daroussin said the following: Well for libreoffice on freebsd clang is the official compiler, because 4.2.1 is just too old for libreoffice, and I never managed to make it built (the 3.5) with gcc from ports. What problem are you running into? I am able to build the latest libreoffice with gcc46. -- Andriy Gapon ___ 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: Binary packages for LibreOffice 3.5 or 3.4
On Mon, May 07, 2012 at 09:20:06AM +0300, Andriy Gapon wrote: on 07/05/2012 01:58 Baptiste Daroussin said the following: Well for libreoffice on freebsd clang is the official compiler, because 4.2.1 is just too old for libreoffice, and I never managed to make it built (the 3.5) with gcc from ports. What problem are you running into? I am able to build the latest libreoffice with gcc46. Really with no modification on the ports? Are you sure you are not building it with clang which is forced by default? regards, Bapt pgpblqAHkv5xJ.pgp Description: PGP signature
Re: Binary packages for LibreOffice 3.5 or 3.4
On 05/07/12 11:35, Baptiste Daroussin wrote: On Mon, May 07, 2012 at 09:20:06AM +0300, Andriy Gapon wrote: on 07/05/2012 01:58 Baptiste Daroussin said the following: Well for libreoffice on freebsd clang is the official compiler, because 4.2.1 is just too old for libreoffice, and I never managed to make it built (the 3.5) with gcc from ports. What problem are you running into? I am able to build the latest libreoffice with gcc46. Really with no modification on the ports? Are you sure you are not building it with clang which is forced by default? regards, Bapt I realized very late that LibreOffice is unwilling to compile with gcc4.6. The error I faced was introduced by the port net/libcmis, which in my case was built via gcc 4.6 (and doesn't build with CLANG). After building libcmis with legacy gcc 4.2.1, I was able to build editors/libreoffice without problems (as far as the selected options concern). Regards, Oliver ___ 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: Binary packages for LibreOffice 3.5 or 3.4
On Mon, May 07, 2012 at 12:22:21PM +0200, Hartmann, O. wrote: On 05/07/12 11:35, Baptiste Daroussin wrote: On Mon, May 07, 2012 at 09:20:06AM +0300, Andriy Gapon wrote: on 07/05/2012 01:58 Baptiste Daroussin said the following: Well for libreoffice on freebsd clang is the official compiler, because 4.2.1 is just too old for libreoffice, and I never managed to make it built (the 3.5) with gcc from ports. What problem are you running into? I am able to build the latest libreoffice with gcc46. Really with no modification on the ports? Are you sure you are not building it with clang which is forced by default? regards, Bapt I realized very late that LibreOffice is unwilling to compile with gcc4.6. The error I faced was introduced by the port net/libcmis, which in my case was built via gcc 4.6 (and doesn't build with CLANG). After building libcmis with legacy gcc 4.2.1, I was able to build editors/libreoffice without problems (as far as the selected options concern). Nice to hear. FYI if avg managed to build libreoffice with 4.6 should be because his whole system should be built (at least the C++ libraries) using gcc 4.6. regards, Bapt pgpUgc4Tk6Nm5.pgp Description: PGP signature
Re: Binary packages for LibreOffice 3.5 or 3.4
2012/5/7 Baptiste Daroussin b...@freebsd.org On Mon, May 07, 2012 at 12:22:21PM +0200, Hartmann, O. wrote: On 05/07/12 11:35, Baptiste Daroussin wrote: On Mon, May 07, 2012 at 09:20:06AM +0300, Andriy Gapon wrote: on 07/05/2012 01:58 Baptiste Daroussin said the following: Well for libreoffice on freebsd clang is the official compiler, because 4.2.1 is just too old for libreoffice, and I never managed to make it built (the 3.5) with gcc from ports. What problem are you running into? I am able to build the latest libreoffice with gcc46. Really with no modification on the ports? Are you sure you are not building it with clang which is forced by default? regards, Bapt I realized very late that LibreOffice is unwilling to compile with gcc4.6. The error I faced was introduced by the port net/libcmis, which in my case was built via gcc 4.6 (and doesn't build with CLANG). After building libcmis with legacy gcc 4.2.1, I was able to build editors/libreoffice without problems (as far as the selected options concern). Nice to hear. FYI if avg managed to build libreoffice with 4.6 should be because his whole system should be built (at least the C++ libraries) using gcc 4.6. regards, Bapt With FreeBSD 9.0-STABLE #140 r229960M I built libreoffice-3.5.2_2 with no problems. Port worked fine. ed ___ 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
Add GEOM_RAID to GENERIC?
I installed 9.0 on a new desktop that used Intel's on-board RAID yesterday and it worked great. One nit though is I had to remember to kldload geom_raid manually from the shell before starting the install, and to load it from the loader on the first boot after install. The old ataraid(4) was present in GENERIC, so I think it would be fine for GEOM_RAID to be present in GENERIC now (certainly on x86). What do you think? -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ctfmerge core dump
On 2012/5/6 5:08, b. f. wrote: On 5/5/12, Steve Willsswi...@freebsd.org wrote: Thanks for the info. I took a look at the dump and see this: % sudo gdb /usr/bin/ctfmerge ctfmerge.core [GDB will not be able to debug user-mode threads: Undefined symbol td_thr_getxmmregs] Hmm, is the thread debugging broken on amd64 now ? td_thr_getxmmregs resides in libthread_db and /usr/src/gnu/usr.bin/gdb/libgdb is complaining about the missing symbol. Maybe or maybe I have done something wrong on my system. FWIW, I do all my builds with debugging enabled. BTW, just to confirm, I was able to work around the original issue once I updated past r235068. I had to disable DTrace build and build and install a new libthr, then was able to re-enable DTrace and everything was fine. Thanks, Steve ___ 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: Add GEOM_RAID to GENERIC?
The only argument that stopped me is that GEOM_RAID is more active in probing for metadata then ataraid. Now it tastes all 6 formats on every provider in system. ataraid tasted only first level and subset of formats depending on controller vendor. While it is possible to do the same, I am not sure it should be done. But may be that all is not really a problem. Most users won't notice few extra requests unless something happen like disk failure, that can make boot to take much longer. 07.05.2012 16:24 пользователь John Baldwin j...@freebsd.org написал: I installed 9.0 on a new desktop that used Intel's on-board RAID yesterday and it worked great. One nit though is I had to remember to kldload geom_raid manually from the shell before starting the install, and to load it from the loader on the first boot after install. The old ataraid(4) was present in GENERIC, so I think it would be fine for GEOM_RAID to be present in GENERIC now (certainly on x86). What do you think? -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
does anyone care about periodic scripts?
Hi all. It seems that patches to periodic scripts have hard time coming into the tree. I personally filed http://www.freebsd.org/cgi/query-pr.cgi?pr=conf/165817 and still there's no move despite change is purely cosmetical and just fixes right way of things. And this is not just one and only case, pr's are numerous and get minimal to no attention at all: http://www.freebsd.org/cgi/query-pr.cgi?pr=conf/165956 http://www.freebsd.org/cgi/query-pr.cgi?pr=conf/30938 How can I assist with this pr's? Whom should I bug to get some answer about them? -- Sphinx of black quartz judge my vow. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: updating from r231158 to 234465: mounting from ufs:/dev/ad4s1a failed with error 19
On Friday, May 04, 2012 4:07:24 pm Anton Shterenlikht wrote:
On Fri, May 04, 2012 at 11:07:59AM -0400, John Baldwin wrote:
On Friday, May 04, 2012 7:51:33 am Anton Shterenlikht wrote:
On Thu, May 03, 2012 at 02:46:18PM -0400, John Baldwin wrote:
On Thursday, May 03, 2012 11:35:19 am Anton Shterenlikht wrote:
On Tue, May 01, 2012 at 12:35:26PM +0100, Anton Shterenlikht wrote:
On Mon, Apr 30, 2012 at 08:43:14AM -0400, John Baldwin wrote:
I also see:
ata0: stat0=0x00 err=0x01 lsb=0x14 msb=0exb
ata0: stat1=0x00 err=0x00 lsb=0x00 msb=0x00
ata0: reset tp2 stat0=00 stat1=00 devices=0x1
Hmmm, I don't know how to grok these lines, but does your disk
work
at
all now
with any kernel? It may be that your disk has died (or a cable,
etc.)
and it
just happened to coincide with your upgrade?
I reverted back to r231158, built world and generic
kernel (minus all modules, i.e. option MODULES_OVERRIDE=).
This works, see the verbose boot dmesg at the end.
I think I'll just do a binary search.
I traced it to r233677.
The only change from 233676 to 233677 is
in /sys/dev/pci/pci.c
My kernel is GENERIC with no modules
and with various bits removed, e.g. all raid devices
and PCI network devices, which I definitely
haven't got on this laptop.
Below is the verbose boot with r233676.
Apparently at the beginning there's also
the previous unsuccessful boot with r233677.
Is this a new feature? I didn't know the
previous dmesg is preserved after a reboot.
Anyway, you can see clearly the error with r233677.
I guess this is something to do with
ata - ada change?
I don't think so.
Please try just this change:
Index: pci.c
===
--- pci.c (revision 234928)
+++ pci.c (working copy)
@@ -2822,10 +2822,14 @@ pci_add_map(device_t bus, device_t dev, int
reg, s
* from the parent.
*/
resource_list_delete(rl, type, reg);
- } else {
+ start = 0;
+ device_printf(bus,
+ pci%d:%d:%d:%d bar %#x failed to allocate,
+ pci_get_domain(dev), pci_get_bus(dev),
pci_get_slot(dev),
+ pci_get_function(dev), reg);
+ } else
start = rman_get_start(res);
- pci_write_bar(dev, pm, start);
- }
+ pci_write_bar(dev, pm, start);
return (barlen);
}
That helped, thank you.
Bizarre, can you get a regular dmesg with that change applied?
Hmm, I missed a newline at the end. :) Looks like this happened twice.
I've added the relevant verbose boot messages from your earlier kernel
below each one:
pci0: ACPI PCI bus on pcib0
pci0: pci0:0:20:2 bar 0x10 failed to allocate
pcib1: ACPI PCI-PCI bridge at device 1.0 on pci0
found- vendor=0x1002, dev=0x4383, revid=0x00
domain=0, bus=0, slot=20, func=2
class=04-03-00, hdrtype=0x00, mfdev=0
cmdreg=0x0006, statreg=0x0410, cachelnsz=16 (dwords)
lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns)
intpin=a, irq=10
powerspec 2 supports D0 D3 current D0
map[10]: type Memory, range 64, base 0xcc408000, size 14, enabled
pcib0: matched entry for 0.20.INTA
pcib0: slot 20 INTA hardwired to IRQ 16
pcib4: ACPI PCI-PCI bridge at device 20.4 on pci0
pcib4: failed to allocate initial memory window: 0xcc10-0xcc1f
pci2: ACPI PCI bus on pcib4
pci2: pci0:2:4:0 bar 0x10 failed to allocate
cbb0: RF5C476 PCI-CardBus Bridge irq 20 at device 4.0 on pci2
found- vendor=0x1180, dev=0x0476, revid=0xb6
domain=0, bus=2, slot=4, func=0
class=06-07-00, hdrtype=0x02, mfdev=1
cmdreg=0x0007, statreg=0x0210, cachelnsz=0 (dwords)
lattimer=0x40 (1920 ns), mingnt=0x80 (32000 ns), maxlat=0x07 (1750 ns)
intpin=a, irq=10
powerspec 2 supports D0 D1 D2 D3 current D0
map[10]: type Memory, range 32, base 0xcc10, size 12, enabled
pcib4: failed to allocate initial memory window (0xcc10-0xcc1f,0x10)
pcib4: matched entry for 2.4.INTA
pcib4: slot 4 INTA hardwired to IRQ 20
cbb0: RF5C476 PCI-CardBus Bridge irq 20 at device 4.0 on pci2
pcib0: allocated type 3 (0xcc50-0xcc5f) for rid 20 of pcib4
pcib4: allocated initial memory window of 0xcc50-0xcc5f
pcib4: allocated memory range (0xcc50-0xcc500fff) for rid 10 of cbb0
cbb0: Lazy allocation of 0x1000 bytes rid 0x10 type 3 at 0xcc50
So the second case actually recovers and allocates a different range.
Can you try booting with 'debug.acpi.disabled=sysres' set in the loader?
Also, can you get the
Re: Binary packages for LibreOffice 3.5 or 3.4
On 2012-05-07 12:22, Hartmann, O. wrote:
...
The error I faced was introduced by the port net/libcmis, which in my
case was built via gcc 4.6 (and doesn't build with CLANG). After
building libcmis with legacy gcc 4.2.1, I was able to build
editors/libreoffice without problems (as far as the selected options
concern).
Here's a diff for the net/libcmis port, to make it compile with clang.
Can someone from ports please apply this?
The software has some very basic C++ problems, such as non-virtual
destructors, and tends to compile everything with -Werror -Wall
-pedantic, so some errors are expected. :)
Another approach, which takes less modifications, is to just run its
configure script with --disable-error.
Index: net/libcmis/files/patch-configure
===
RCS file: net/libcmis/files/patch-configure
diff -N net/libcmis/files/patch-configure
--- /dev/null 1 Jan 1970 00:00:00 -
+++ net/libcmis/files/patch-configure 7 May 2012 18:11:21 -
@@ -0,0 +1,42 @@
+--- configure.orig 2011-10-04 10:45:11.0 +0200
configure 2012-05-07 20:03:00.0 +0200
+@@ -3178,19 +3178,6 @@ else
+
+ fi
+
+-if test x$enable_werror != xno; then :
+-
+- CFLAGS=$CFLAGS -Werror
+- CXXFLAGS=$CXXFLAGS -Werror
+-
+-fi
+-if test x$GCC = xyes; then :
+-
+- # Be tough with warnings and produce less careless code
+- CFLAGS=$CFLAGS -Wall -pedantic
+- CXXFLAGS=$CXXFLAGS -Wall -pedantic
+-
+-fi
+
+ LIBCMIS_API_VERSION=0.2
+
+@@ -15971,6 +15958,19 @@ fi
+
+ ac_config_files=$ac_config_files Makefile libcmis.pc src/Makefile src/libcmis/Makefile
+
++if test x$enable_werror != xno; then :
++
++ CFLAGS=$CFLAGS -Werror
++ CXXFLAGS=$CXXFLAGS -Werror
++
++fi
++if test x$GCC = xyes; then :
++
++ # Be tough with warnings and produce less careless code
++ CFLAGS=$CFLAGS -Wall -pedantic
++ CXXFLAGS=$CXXFLAGS -Wall -pedantic
++
++fi
+ cat confcache \_ACEOF
+ # This file is a shell script that caches the results of configure
+ # tests run on this system so they can be shared between configure
Index: net/libcmis/files/patch-src__libcmis__atom-document.hxx
===
RCS file: net/libcmis/files/patch-src__libcmis__atom-document.hxx
diff -N net/libcmis/files/patch-src__libcmis__atom-document.hxx
--- /dev/null 1 Jan 1970 00:00:00 -
+++ net/libcmis/files/patch-src__libcmis__atom-document.hxx 7 May 2012 18:11:21 -
@@ -0,0 +1,11 @@
+--- src/libcmis/atom-document.hxx.orig 2011-10-01 14:26:15.0 +0200
src/libcmis/atom-document.hxx 2012-05-07 20:06:51.0 +0200
+@@ -44,7 +44,7 @@ class AtomDocument : public libcmis::Doc
+ public:
+ AtomDocument( AtomPubSession* session, std::string url );
+ AtomDocument( AtomPubSession* session, xmlNodePtr entryNd );
+-~AtomDocument( );
++virtual ~AtomDocument( );
+
+ // Override content methods
+ virtual FILE* getContent( const char* path = NULL );
Index: net/libcmis/files/patch-src__libcmis__atom-folder.hxx
===
RCS file: net/libcmis/files/patch-src__libcmis__atom-folder.hxx
diff -N net/libcmis/files/patch-src__libcmis__atom-folder.hxx
--- /dev/null 1 Jan 1970 00:00:00 -
+++ net/libcmis/files/patch-src__libcmis__atom-folder.hxx 7 May 2012 18:11:21 -
@@ -0,0 +1,11 @@
+--- src/libcmis/atom-folder.hxx.orig 2011-09-30 20:52:01.0 +0200
src/libcmis/atom-folder.hxx 2012-05-07 20:06:29.0 +0200
+@@ -42,7 +42,7 @@ class AtomFolder : public libcmis::Folde
+ public:
+ AtomFolder( AtomPubSession* session, std::string url );
+ AtomFolder( AtomPubSession* session, xmlNodePtr entryNd );
+-~AtomFolder( );
++virtual ~AtomFolder( );
+
+ // virtual pure methods from Folder
+ virtual std::vector libcmis::CmisObjectPtr getChildren( );
Index: net/libcmis/files/patch-src__libcmis__session.hxx
===
RCS file: net/libcmis/files/patch-src__libcmis__session.hxx
diff -N net/libcmis/files/patch-src__libcmis__session.hxx
--- /dev/null 1 Jan 1970 00:00:00 -
+++ net/libcmis/files/patch-src__libcmis__session.hxx 7 May 2012 18:11:21 -
@@ -0,0 +1,10 @@
+--- src/libcmis/session.hxx.orig 2011-09-30 20:38:39.0 +0200
src/libcmis/session.hxx 2012-05-07 19:23:43.0 +0200
+@@ -36,6 +36,7 @@ namespace libcmis
+ class Session
+ {
+ public:
++virtual ~Session( ) { }
+
+ /** Get the Root folder of the repository
+ */
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: jemalloc: jemalloc_arena.c:182: Failed assertion: p[i] == 0
On Apr 21, 2012, at 11:54 AM, David Wolfskill wrote:
After applying Dimitry Andric's patches to contrib/jemalloc and
replacing
/usr/bin/as with one built last Sunday, I was finally(!) able to rebuild
head as of 234536:
FreeBSD freebeast.catwhisker.org 10.0-CURRENT FreeBSD 10.0-CURRENT #797
234536M: Sat Apr 21 10:23:33 PDT 2012
r...@freebeast.catwhisker.org:/usr/obj/usr/src/sys/GENERIC i386
However, as I was copying a /usr/obj hierarchy via tar -- e.g.:
root@freebeast:/common/home/david # (cd /var/tmp rm -fr obj mkdir
obj) (cd /usr tar cpf - obj) | (cd /var/tmp tar xpf -)
it ran for a while, then:
jemalloc: jemalloc_arena.c:182: Failed assertion: p[i] == 0
Abort (core dumped)
root@freebeast:/common/home/david # echo $?
134
root@freebeast:/common/home/david # ls -lTio *.core
ls: No match.
root@freebeast:/common/home/david #
So ... no core file, apparently.
freebeast(10.0-C)[2] find /usr/src/contrib/jemalloc -type f -name
jemalloc_arena.c
freebeast(10.0-C)[3]
No file named jemalloc_arena.c, either.
But contrib/jemalloc/src/arena.c contains a function,
arena_chunk_validate_zeroed():
175 static inline void
176 arena_chunk_validate_zeroed(arena_chunk_t *chunk, size_t run_ind)
177 {
178 size_t i;
179 UNUSED size_t *p = (size_t *)((uintptr_t)chunk + (run_ind
LG_PAGE));
180
181 for (i = 0; i PAGE / sizeof(size_t); i++)
182 assert(p[i] == 0);
183 }
Thoughts?
I received a similar report yesterday in the context of filezilla, but
didn't get as far as reproducing it. I think the problem is in
chunk_alloc_dss(), which dangerously claims that newly allocated memory is
zeroed. It looks like I formalized this bad assumption in early 2010,
though the bug existed before that. It's a bigger deal now because sbrk()
is preferred over mmap(), so the bug has languished for a couple of years.
I'll get a fix committed today (and revert the order of preference
between sbrk() and mmap()).
By the way, I wonder why not everyone hits this (I don't).
I just now hit the same issue while using ports tinderbox. It was calling
tar during the makeJail tinderbox subcommand and gave the same error as
in the subject. Funny thing is I had run the same command (on a different
jail) right before this and didn't get the error. What's the status of
this? Should I set MALLOC_PRODUCTION=yes in /etc/make.conf, rebuild world
and forget about it?
Steve
___
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, seems related to r234386
On 05/06/2012 15:19, Sergey Kandaurov wrote:
On 7 May 2012 01:54, Doug Barton do...@freebsd.org wrote:
I got this with today's current, previous (working) kernel is r232719.
panic: _mtx_lock_sleep: recursed on non-recursive mutex struct mount mtx
@ /frontier/svn/head/sys/kern/vfs_subr.c:4595
...
Please try this patch.
Index: fs/ext2fs/ext2_vfsops.c
===
--- fs/ext2fs/ext2_vfsops.c (revision 235108)
+++ fs/ext2fs/ext2_vfsops.c (working copy)
@@ -830,7 +830,6 @@
/*
* Write back each (modified) inode.
*/
- MNT_ILOCK(mp);
loop:
MNT_VNODE_FOREACH_ALL(vp, mp, mvp) {
if (vp-v_type == VNON) {
Didn't help, sorry. I put 234385 through some pretty heavy load
yesterday, and everything was fine. As soon as I move up to 234386, the
panic triggered again. So I cleaned everything up, applied your patch,
built a kernel from scratch, and rebooted. It was Ok for a few seconds
after boot, then panic'ed again, I think in a different place, but I'm
not sure because subsequent attempts to fsck the file systems caused new
panics which overwrote the old ones before they could be saved.
I'd like to see this changed backed out until the proponents can
thoroughly regression test all of the file systems that it affects.
FWIW, the thing that seems to be triggering the panic is that I have the
following setup:
/dev/ad0s2a on / (ufs, local)
/dev/ad3s2 on /home (ext2fs, local)
/etc/namedb is a symlink to /home/named/etc/namedb. When I booted 234386
named failed to start because the symlink was corrupted. When I
recreated the symlink and then started named, it panic'ed.
hth,
Doug
--
This .signature sanitized for your protection
___
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: Binary packages for LibreOffice 3.5 or 3.4
On Mon, May 07, 2012 at 08:22:16PM +0200, Dimitry Andric wrote: On 2012-05-07 12:22, Hartmann, O. wrote: ... The error I faced was introduced by the port net/libcmis, which in my case was built via gcc 4.6 (and doesn't build with CLANG). After building libcmis with legacy gcc 4.2.1, I was able to build editors/libreoffice without problems (as far as the selected options concern). Here's a diff for the net/libcmis port, to make it compile with clang. Can someone from ports please apply this? The software has some very basic C++ problems, such as non-virtual destructors, and tends to compile everything with -Werror -Wall -pedantic, so some errors are expected. :) Another approach, which takes less modifications, is to just run its configure script with --disable-error. Thanks for the patch, your patch break the build with gcc 4.2.1, I'll try to fix it otherwise I'll run it disabling --disable-error. regards, Bapt pgp4TZqhdx5AR.pgp Description: PGP signature
Re: Binary packages for LibreOffice 3.5 or 3.4
On Mon, May 07, 2012 at 08:22:16PM +0200, Dimitry Andric wrote: On 2012-05-07 12:22, Hartmann, O. wrote: ... The error I faced was introduced by the port net/libcmis, which in my case was built via gcc 4.6 (and doesn't build with CLANG). After building libcmis with legacy gcc 4.2.1, I was able to build editors/libreoffice without problems (as far as the selected options concern). Here's a diff for the net/libcmis port, to make it compile with clang. Can someone from ports please apply this? The software has some very basic C++ problems, such as non-virtual destructors, and tends to compile everything with -Werror -Wall -pedantic, so some errors are expected. :) Another approach, which takes less modifications, is to just run its configure script with --disable-error. Committed thank you, regards, Bapt pgp7zDQg1hcXW.pgp Description: PGP signature
Re: panic, seems related to r234386
On Mon, May 07, 2012 at 12:28:41PM -0700, Doug Barton wrote:
On 05/06/2012 15:19, Sergey Kandaurov wrote:
On 7 May 2012 01:54, Doug Barton do...@freebsd.org wrote:
I got this with today's current, previous (working) kernel is r232719.
panic: _mtx_lock_sleep: recursed on non-recursive mutex struct mount mtx
@ /frontier/svn/head/sys/kern/vfs_subr.c:4595
...
Please try this patch.
Index: fs/ext2fs/ext2_vfsops.c
===
--- fs/ext2fs/ext2_vfsops.c (revision 235108)
+++ fs/ext2fs/ext2_vfsops.c (working copy)
@@ -830,7 +830,6 @@
/*
* Write back each (modified) inode.
*/
- MNT_ILOCK(mp);
loop:
MNT_VNODE_FOREACH_ALL(vp, mp, mvp) {
if (vp-v_type == VNON) {
Didn't help, sorry. I put 234385 through some pretty heavy load
yesterday, and everything was fine. As soon as I move up to 234386, the
panic triggered again. So I cleaned everything up, applied your patch,
built a kernel from scratch, and rebooted. It was Ok for a few seconds
after boot, then panic'ed again, I think in a different place, but I'm
not sure because subsequent attempts to fsck the file systems caused new
panics which overwrote the old ones before they could be saved.
Another MNT_ILOCK was hiding few lines below, try this patch:
http://student.agh.edu.pl/~mjguzik/patches/ext2fs-ilock.patch
I've tested this a bit and I believe this fixes your problem.
--
Mateusz Guzik mjguzik gmail.com
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: updating from r231158 to 234465: mounting from ufs:/dev/ad4s1a failed with error 19
On Mon, May 07, 2012 at 10:39:51AM -0400, John Baldwin wrote:
On Friday, May 04, 2012 4:07:24 pm Anton Shterenlikht wrote:
On Fri, May 04, 2012 at 11:07:59AM -0400, John Baldwin wrote:
On Friday, May 04, 2012 7:51:33 am Anton Shterenlikht wrote:
On Thu, May 03, 2012 at 02:46:18PM -0400, John Baldwin wrote:
On Thursday, May 03, 2012 11:35:19 am Anton Shterenlikht wrote:
On Tue, May 01, 2012 at 12:35:26PM +0100, Anton Shterenlikht wrote:
On Mon, Apr 30, 2012 at 08:43:14AM -0400, John Baldwin wrote:
I also see:
ata0: stat0=0x00 err=0x01 lsb=0x14 msb=0exb
ata0: stat1=0x00 err=0x00 lsb=0x00 msb=0x00
ata0: reset tp2 stat0=00 stat1=00 devices=0x1
Hmmm, I don't know how to grok these lines, but does your disk
work
at
all now
with any kernel? It may be that your disk has died (or a
cable,
etc.)
and it
just happened to coincide with your upgrade?
I reverted back to r231158, built world and generic
kernel (minus all modules, i.e. option MODULES_OVERRIDE=).
This works, see the verbose boot dmesg at the end.
I think I'll just do a binary search.
I traced it to r233677.
The only change from 233676 to 233677 is
in /sys/dev/pci/pci.c
My kernel is GENERIC with no modules
and with various bits removed, e.g. all raid devices
and PCI network devices, which I definitely
haven't got on this laptop.
Below is the verbose boot with r233676.
Apparently at the beginning there's also
the previous unsuccessful boot with r233677.
Is this a new feature? I didn't know the
previous dmesg is preserved after a reboot.
Anyway, you can see clearly the error with r233677.
I guess this is something to do with
ata - ada change?
I don't think so.
Please try just this change:
Index: pci.c
===
--- pci.c (revision 234928)
+++ pci.c (working copy)
@@ -2822,10 +2822,14 @@ pci_add_map(device_t bus, device_t dev, int
reg, s
* from the parent.
*/
resource_list_delete(rl, type, reg);
- } else {
+ start = 0;
+ device_printf(bus,
+ pci%d:%d:%d:%d bar %#x failed to allocate,
+ pci_get_domain(dev), pci_get_bus(dev),
pci_get_slot(dev),
+ pci_get_function(dev), reg);
+ } else
start = rman_get_start(res);
- pci_write_bar(dev, pm, start);
- }
+ pci_write_bar(dev, pm, start);
return (barlen);
}
That helped, thank you.
Bizarre, can you get a regular dmesg with that change applied?
Hmm, I missed a newline at the end. :) Looks like this happened twice.
I've added the relevant verbose boot messages from your earlier kernel
below each one:
pci0: ACPI PCI bus on pcib0
pci0: pci0:0:20:2 bar 0x10 failed to allocate
pcib1: ACPI PCI-PCI bridge at device 1.0 on pci0
found- vendor=0x1002, dev=0x4383, revid=0x00
domain=0, bus=0, slot=20, func=2
class=04-03-00, hdrtype=0x00, mfdev=0
cmdreg=0x0006, statreg=0x0410, cachelnsz=16 (dwords)
lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns)
intpin=a, irq=10
powerspec 2 supports D0 D3 current D0
map[10]: type Memory, range 64, base 0xcc408000, size 14, enabled
pcib0: matched entry for 0.20.INTA
pcib0: slot 20 INTA hardwired to IRQ 16
pcib4: ACPI PCI-PCI bridge at device 20.4 on pci0
pcib4: failed to allocate initial memory window: 0xcc10-0xcc1f
pci2: ACPI PCI bus on pcib4
pci2: pci0:2:4:0 bar 0x10 failed to allocate
cbb0: RF5C476 PCI-CardBus Bridge irq 20 at device 4.0 on pci2
found- vendor=0x1180, dev=0x0476, revid=0xb6
domain=0, bus=2, slot=4, func=0
class=06-07-00, hdrtype=0x02, mfdev=1
cmdreg=0x0007, statreg=0x0210, cachelnsz=0 (dwords)
lattimer=0x40 (1920 ns), mingnt=0x80 (32000 ns), maxlat=0x07 (1750 ns)
intpin=a, irq=10
powerspec 2 supports D0 D1 D2 D3 current D0
map[10]: type Memory, range 32, base 0xcc10, size 12, enabled
pcib4: failed to allocate initial memory window
(0xcc10-0xcc1f,0x10)
pcib4: matched entry for 2.4.INTA
pcib4: slot 4 INTA hardwired to IRQ 20
cbb0: RF5C476 PCI-CardBus Bridge irq 20 at device 4.0 on pci2
pcib0: allocated type 3 (0xcc50-0xcc5f) for rid 20 of pcib4
pcib4: allocated initial memory window of 0xcc50-0xcc5f
pcib4: allocated memory range (0xcc50-0xcc500fff) for rid 10 of cbb0
cbb0: Lazy allocation of 0x1000 bytes rid 0x10 type 3 at 0xcc50
So the
Re: panic, seems related to r234386
On 05/07/2012 13:11, Mateusz Guzik wrote: On Mon, May 07, 2012 at 12:28:41PM -0700, Doug Barton wrote: On 05/06/2012 15:19, Sergey Kandaurov wrote: On 7 May 2012 01:54, Doug Barton do...@freebsd.org wrote: I got this with today's current, previous (working) kernel is r232719. panic: _mtx_lock_sleep: recursed on non-recursive mutex struct mount mtx @ /frontier/svn/head/sys/kern/vfs_subr.c:4595 ... Please try this patch. Ok, so far so good. Again, thanks for the quick response. I'm stress-testing my ext2fs partitions a bit atm, and everything seems Ok. I'll let you know if I run into any problems. So my next question is, does removing those locks present any risks? Should they be replaced by different locks, or were they just safety belts to start with? Finally, should my next step be to advance to the latest current + your patch and see how I go from there? Doug -- This .signature sanitized for your protection ___ 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: jemalloc: jemalloc_arena.c:182: Failed assertion: p[i] == 0
On May 7, 2012, at 12:19 PM, Steve Wills wrote:
On Apr 21, 2012, at 11:54 AM, David Wolfskill wrote:
After applying Dimitry Andric's patches to contrib/jemalloc and
replacing
/usr/bin/as with one built last Sunday, I was finally(!) able to rebuild
head as of 234536:
FreeBSD freebeast.catwhisker.org 10.0-CURRENT FreeBSD 10.0-CURRENT #797
234536M: Sat Apr 21 10:23:33 PDT 2012
r...@freebeast.catwhisker.org:/usr/obj/usr/src/sys/GENERIC i386
However, as I was copying a /usr/obj hierarchy via tar -- e.g.:
root@freebeast:/common/home/david # (cd /var/tmp rm -fr obj mkdir
obj) (cd /usr tar cpf - obj) | (cd /var/tmp tar xpf -)
it ran for a while, then:
jemalloc: jemalloc_arena.c:182: Failed assertion: p[i] == 0
Abort (core dumped)
root@freebeast:/common/home/david # echo $?
134
root@freebeast:/common/home/david # ls -lTio *.core
ls: No match.
root@freebeast:/common/home/david #
So ... no core file, apparently.
freebeast(10.0-C)[2] find /usr/src/contrib/jemalloc -type f -name
jemalloc_arena.c
freebeast(10.0-C)[3]
No file named jemalloc_arena.c, either.
But contrib/jemalloc/src/arena.c contains a function,
arena_chunk_validate_zeroed():
175 static inline void
176 arena_chunk_validate_zeroed(arena_chunk_t *chunk, size_t run_ind)
177 {
178 size_t i;
179 UNUSED size_t *p = (size_t *)((uintptr_t)chunk + (run_ind
LG_PAGE));
180
181 for (i = 0; i PAGE / sizeof(size_t); i++)
182 assert(p[i] == 0);
183 }
Thoughts?
I received a similar report yesterday in the context of filezilla, but
didn't get as far as reproducing it. I think the problem is in
chunk_alloc_dss(), which dangerously claims that newly allocated memory is
zeroed. It looks like I formalized this bad assumption in early 2010,
though the bug existed before that. It's a bigger deal now because sbrk()
is preferred over mmap(), so the bug has languished for a couple of years.
I'll get a fix committed today (and revert the order of preference
between sbrk() and mmap()).
By the way, I wonder why not everyone hits this (I don't).
I just now hit the same issue while using ports tinderbox. It was calling
tar during the makeJail tinderbox subcommand and gave the same error as
in the subject. Funny thing is I had run the same command (on a different
jail) right before this and didn't get the error. What's the status of
this? Should I set MALLOC_PRODUCTION=yes in /etc/make.conf, rebuild world
and forget about it?
How recent is your system? This problem should have been fixed by r234569, so
if you're still seeing problems after that revision, there's another problem we
need to figure out. (By the way, it's possible for an application to trigger
this assertion, but unlikely.)
Thanks,
Jason___
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: Binary packages for LibreOffice 3.5 or 3.4
on 07/05/2012 12:35 Baptiste Daroussin said the following: On Mon, May 07, 2012 at 09:20:06AM +0300, Andriy Gapon wrote: on 07/05/2012 01:58 Baptiste Daroussin said the following: Well for libreoffice on freebsd clang is the official compiler, because 4.2.1 is just too old for libreoffice, and I never managed to make it built (the 3.5) with gcc from ports. What problem are you running into? I am able to build the latest libreoffice with gcc46. Really with no modification on the ports? Yes. (OK, I lied, see below) Are you sure you are not building it with clang which is forced by default? Yes. I set WITH_GCC in make.conf. Some notes: - I have boost 1.48 via the patches from the boost port maintainer (long overdue to be committed) - on one system I build (almost) all ports with gcc46 (base system is built in a standard fashion) - on another system I build (almost) all ports with base gcc (except, obviously, those ports that have USE_GCC=4.6[+]) And, oh, almost forgot, I had to manually apply the attached patch in cppunit/ subdirectory on FreeBSD 10. It seems that the source code in question is extracted during build, so it is not possible to apply the patch during normal patch target. The patch is for the well-known FreeBSD1 vs FreeBSD10 confusion in autotools. -- Andriy Gapon ___ 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: Binary packages for LibreOffice 3.5 or 3.4
On Tue, May 08, 2012 at 08:10:25AM +0300, Andriy Gapon wrote: on 07/05/2012 12:35 Baptiste Daroussin said the following: On Mon, May 07, 2012 at 09:20:06AM +0300, Andriy Gapon wrote: on 07/05/2012 01:58 Baptiste Daroussin said the following: Well for libreoffice on freebsd clang is the official compiler, because 4.2.1 is just too old for libreoffice, and I never managed to make it built (the 3.5) with gcc from ports. What problem are you running into? I am able to build the latest libreoffice with gcc46. Really with no modification on the ports? Yes. (OK, I lied, see below) Are you sure you are not building it with clang which is forced by default? Yes. I set WITH_GCC in make.conf. Some notes: - I have boost 1.48 via the patches from the boost port maintainer (long overdue to be committed) - on one system I build (almost) all ports with gcc46 (base system is built in a standard fashion) - on another system I build (almost) all ports with base gcc (except, obviously, those ports that have USE_GCC=4.6[+]) And, oh, almost forgot, I had to manually apply the attached patch in cppunit/ subdirectory on FreeBSD 10. It seems that the source code in question is extracted during build, so it is not possible to apply the patch during normal patch target. The patch is for the well-known FreeBSD1 vs FreeBSD10 confusion in autotools. Yes but only with gcc46 because cppunit needs the same libstdc++ as libreoffice so with gcc 4.6 is needs to be built with bundled, while it is unbundled with clang. regards, Bapt pgpavsUkyb9vy.pgp Description: PGP signature
