On 11/5/2014 6:41 AM, Andriy Gapon wrote:
> If something hangs (appears to hang) and it's ZFS related, then
> https://wiki.freebsd.org/AvgZfsDeadlockDebug
>
I don't think the"zpool history" hang is in ZFS or storage layer code:
it seems be stalled in kernel malloc(). See PID 12105 (zpool
histo
On 11/4/2014 5:47 AM, Dmitriy Makarov wrote:
> Funny thing is that when we manually allocate and release memory, using
> simple python script:
...
>
> Current workaround is to periodically invoke this python script by cron.
>
I wonder if this is related to PR
https://bugs.freebsd.org/bugzilla/sh
ee memory before zfs unblocked.
On 10/16/2014 6:25 AM, James R. Van Artsdalen wrote:
> The zfs recv / kmem arena hang happens with -CURRENT as well as
> 10-STABLE, on two different systems, with 16GB or 32GB of RAM, from
> memstick or normal multi-user environments,
>
> Hangs usually see
On 10/21/2014 5:03 PM, Alan Cox wrote:
> How up to date is your source tree? r2720221 is relevant. Without that
> change, there are circumstances in which the code that is supposed to
> free space from the kmem arena doesn't get called.
I've tried HEAD/CURRENT at r272749
On 10-STABLE through r273
ic's "zpool history". After a reboot it did not hang
Saturday night.
On 10/16/2014 11:37 PM, James R. Van Artsdalen wrote:
> On 10/16/2014 11:10 PM, Xin Li wrote:
>> On 10/16/14 8:43 PM, James R. Van Artsdalen wrote:
>>> On 10/16/2014 11:12 AM, Xin Li wrote:
>>&
The zfs recv / kmem arena hang happens with -CURRENT as well as
10-STABLE, on two different systems, with 16GB or 32GB of RAM, from
memstick or normal multi-user environments,
Hangs usually seem to hapeen 1TB to 3TB in, but last night one run hung
after only 4.35MB.
On 9/26/2014 1:42 AM, James R
On 11/16/2013 8:52 AM, Allan Jude wrote:
> I see this was in the release notes for 9.0 and 8.3, but other than
> that, I don't see how anyone was supposed to find out about this.
> Maybe it would make sense to print 'Starting memory test, set
> hw.memtest.test=0 to disable' before that starts, so
Asus Z9PA-U8 motherboard, 256GB of RAM, 2.4 GHz Xeon E5-2695 v2, FreeBSD
11.0-CURRENT r258092
There is a two minute pause when booting, after the loader's SMAP
display and the initial kernel output,
Does anyone know what's going on here? Even that much RAM shouldn't
take that much time to clear.
BLACKIE:/root# uname -a
FreeBSD BLACKIE.housenet.jrv 10.0-BETA1 FreeBSD 10.0-BETA1 #0 r256428M:
Sun Oct 13 23:46:54 CDT 2013
r...@clank.housenet.jrv:/usr/obj/usr/src/sys/GENERIC amd64
This pool is on da{0,1,2,3,4,5,6,7} - I think, only da4 is sure
NAME
GOHORNS:/usr/src/sys# uname -a
FreeBSD GOHORNS.housenet.jrv 10.0-CURRENT FreeBSD 10.0-CURRENT #0
r240529: Sat Sep 15 03:10:21 CDT 2012
r...@gohorns.housenet.jrv:/usr/obj/usr/src/sys/GENERIC amd64
I am getting an error when attaching some disks from Mac OSX. This is
an enclose of 5 SATA disks use
On 2/22/2011 2:57 PM, Peter Jeremy wrote:
> When that does come, it will probably be driven by BIOS and hardware
> vendors dropping support for MBR.
MBR is not a BIOS concept. MBR is an OS thing. The BIOS does not care
or know what kind of partitioning you use, or if you partition at all.
A GPT
On 1/20/2011 3:37 PM, David Demelier wrote:
> Why does the installer use GPT partition by default? Do you know that
> GPT is not supported on every (even modern) computer ?
GPT is fully compatible with the universe of PC/AT BIOS-compatible
computers, which is essentially all "PCs" going back to th
FreeBSD gohorns.x 9.0-CURRENT FreeBSD 9.0-CURRENT #1 r216088: Thu Dec 2
23:20:14 CST 2010 r...@gohorns.x:/usr/obj/usr/src/sys/GENERIC amd64
I have been getting a lot of ts_to_ct for months: are we supposed to
look for something or report anything about these?
I just noticed an NTP error in
Ivan Voras wrote:
> Unfortunately, the kernel hangs on boot. The loader finishes, the twirly
> starts spinning but then hangs. Enabling verbose booting results in
> nothing new - no kernel messages at all.
I don't think "loader finishes" is correct. Can you break to the loader
command line at the
FreeBSD 9.0-CURRENT #1 r209275: Fri Jun 18 08:15:15 CDT 2010
r...@clank.housenet.jrv:/usr/obj/usr/src/sys/GENERIC amd64
June 17 -CURRENT
This panic was seen under VirtualBox on a Windows host. The VM has 2
cores (the host is a Core i7).
I this infrequently under a VM. I have yet to see it o
Bernd Walter wrote:
> But calling my_abolsutely_not_inlineable_memset should work IMHO.
Try gcc -fno-builtin-memset
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "f
On 6/1/2010 3:38 AM, Kostik Belousov wrote:
> This is unsufficient. What could work is if clang provided some common
> symbol into all .o files generated by it, e.g. __clang_compiled. And
> then kernel considered tainted with corresponding banner printed when
> weak reference to that symbol is reso
Scott Long wrote:
> Sounds like you're inviting the discussion right now. I'll start =-)
>
> 1. I hate gcc with the burning heat of a million suns. It's not a tool, it's
> a political weapon wielded by the FSF and their acolytes. It's also a crummy
> piece of software that has been "good enough
On 5/22/2010 8:25 PM, Rob Farmer wrote:
> make release is still broken on amd64 as of svn 208373 (2010-05-21
>> 04:52:49 -0500)
>>
>> That patch seems unrelated?
>>
> What needs done is
> /src/release/$ARCH/boot_crunch.conf files need the relevant libraries
> added to the libs section. I haven't te
On 5/18/2010 2:34 AM, jhell wrote:
> On Mon, May 17, 2010 at 10:35 PM, Rob Farmer
> wrote:
>>> make release is broken on current. Seems to be related to the lzma
>>> import. This is on i386:
>>>
>>> cc -static -o boot_crunch boot_crunch.o hostname.lo pwd.lo rm.lo sh.lo
>>> test.lo camcontrol.lo dh
Scott Long wrote:
>
> I'm sorry, but I find it absolutely absurd that any filesystem has to wire
> down 2GB of RAM, and that the solution to panics is buy more
The only thing buying more RAM is likely to do is make the memory leak
behind this harder to reproduce. Likewise increasing kernel tunab
Андрей Смагин wrote:
> > panic: kmem_malloc(131072): kmem_map too small: 3832475648 total allocated
> >
> I open PR amd64/145654 with problem like it. Have you increasing Wired memory
> at buildworld ?
>
No. This
# while true
> do
> sysctl -A | grep wired
> make -j8 buildworld
> done
is g
FreeBSD bigback.housenet.jrv 9.0-CURRENT FreeBSD 9.0-CURRENT #1 r206111:
Mon Apr 26 01:13:00 CDT 2010
r...@bigback.housenet.jrv:/usr/obj/usr/src/sys/GENERIC amd64
svn 206111 is April 2
system is a Core i7 975 (3.33 GHz x 4 cores 3x threads per core) with 12
GB of RAM, a 2x2TB ZFS boot pool a
I have a Dell Zino HD (Mac mini clone, with eSATA ports) that uses the
BCM4353 chip (called a Dell 1520 card)
no...@pci0:2:0:0:class=0x028000 card=0x000e1028 chip=0x435314e4
rev=0x01 hdr=0x00
vendor = 'Broadcom Corporation'
class = network
Should I expect this to work with to
Roman Divacky wrote:
> Recently, we've achieved the state when clang can compile all of FreeBSD world
> on i386/amd64 platforms (including all the C++ apps we have and itself)
> and a bootable kernel.
bigback:/usr/clangbsd# make buildworld
.
.
.
clang++ -O2 -pipe
-I/usr/clangbsd/usr.bin/clang/lib/
Norikatsu Shigemura wrote:
> According to http://en.wikipedia.org/wiki/AES-NI , we can get
> specification document: http://software.intel.com/file/20457 .
>
> I saw it, and consider that we can release under BSDL. Because
> of 'from specification'.
That document is short on det
26 matches
Mail list logo
