Hi, i have problem with ati mobility radeon 9600 graphic card. With vesa driver works OK, but with ati or radeon driver, 3d acceletarion does not work (with Xorg 6.9 worked). I am now using Xorg xorg-server-1.4_3,1. xvinfo: X-Video Extension version 2.2 screen #0 Adaptor #0: "ATI Radeon Video Overlay" number of ports: 1 port base: 73 operations supported: PutImage supported visuals: depth 24, visualID 0x23 depth 24, visualID 0x24 depth 24, visualID 0x2...

Hi, There were talks in 'sbrk(2) broken' thread about memory hogs which can easily eat all available VM despite of resources. That'smust be fixed or it will make a bad reputation for FreeBSD as a server platform. But there are related "bug", in that of malloc overcommit, which can be demonstrated by this short program (if no resource limits are present, you'll see): #include <unistd.h> /* http://alter.tomsk.ru/bugs/head/ */ /* (C) Vladimir */ /* alter at alter tom ru */ int main...

So why we are losing users due to this "feature", as other OSes provide tunables? Can I find somewhere summary of that discussions in archives? -- WBR, Vadim Goncharov _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"

That's not a solution for end-user. Why just not have space reserving, as other operating systems can guarantee to their applications that stable availability of memory? -- WBR, Vadim Goncharov _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"

Hi, As far as I know about the details of implementation and what would it take to fix the problems, is it safe to assume ZFS will never become stable during 7.x lifetime?

My yardstick is currently "when a month goes by without anyone This number is not so large. It seems to be easily crashed by rsync, for example (speaking from my own experience, and also some of my I listened to some of Pawel's talks and devsummit brainstormings and I get the feeling *none* of the problems can be fixed in 7.x, especially on i386. I'm just asking for more official confirmation. This is not a trivial question, since it involves deploying systems to be maintained some years into...

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Recently I have encountered a strange kernel trap 12, which always end up at vm_page_splay() like this, the fault va and IP vary from time to time: Fatal trap 12: page fault while in kernel mode cpuid = 3; apic id = 03 fault virtual address = 0xfff9a4b5 fault code = supervisor read, page not present instruction pointer = 0x20:0xc073eec7 stack pointer = 0x28:0xe66fa94c frame pointer = 0x28:0xe66fa9a4 code segment = base 0x0...

There are better lists on which to discuss DragonflyBSD vaporware. Scott _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"

Malloc() itself knows about memory amount _really_ in use by a program and could check it don't go beyond the limits, but for this it needs run-time check via getrlimit() call for each malloc() call (a program can use setrlimit() by itself). Traking direct mmap()s and sbrk()s outside of malloc() is also needed. -- http://ache.pp.ru/ _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscr...

Then, we need sysctl to fetch that "memory actually in use" from the kernel and compare that with getrlimit() which allows malloc() to return 0 when needed. -- http://ache.pp.ru/ _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"

In that case the process is subject to be killed by system, if exceeds its limits. But... this is not malloc() problem at all, malloc() designed to detect overflow situation, not prevent it. The malloc() problem is not returning 0. -- http://ache.pp.ru/ _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"

The issue here was that there were a number of reports that out-of-control= =20 applications were toasting systems that weren't getting toasted under 6.x. = I=20 experienced this on my web server, but the ports build cluster has been=20 running into it for months. The symptom is that a single application exhau= sts=20 swap, causing all sorts of things to break (tm), killing of other large=20 processes, etc. To be clear, in the new world order, instead of getting NU= LL=20 back from malloc(3...

FreeBSD allows memory overcommit, both overcommit of physical memory resulting in paging, and overcommit of swap space. For the last few years, resource limits on the data segment size, previously observed by malloc(), have prevented processes from mallocing enough memory individually to exhaust swap on 32-bit systems. This is arguably a bug, because you actually want a single process to be able to allocate enough memory to fill its address space, but because the data segment size is used to...

Broadcasting SIGDANGER would be a much better option; followed by SIGTERM to the memory hogger (to allow for graceful termination) and only then SIGKILL. I can imagine a few (legitimate) scenarios when a That would be really cool and even better if it allocated it in a contiguous chunk. Igor :-) _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current...

In message <86myrlahee.fsf@ds4.des.no>, =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= wr SIGDANGER is not what we need. What we need is an intelligent mechanism to tell applications what the overall situation is, so that jemalloc and aware applications can tune their usage pattern to the availability of physical and virtual memory. Instead of the binary "SIGDANGER" indication we need a more gradual state, at the very least three stats: "plenty", "getting a bit tight" and "crunchtime". Having ...

You don't seem to understand what Poul-Henning was trying to point out, which is that broadcasting SIGDANGER can make a bad situation much, much worse by waking up and paging in every single process in the system, including processes that are blocked and wouldn't otherwise run for several minutes, hours or even days (getty, inetd, sshd, mountd, even nfsd / nfsiod in some cases can sleep for days at a time waiting for I/O) DES -- Dag-Erling Smørgrav - des@des.no ______________________________...

Another aspect of the problem is that applications have come to depend in= =20 malloc(3) returning NULL when memory is getting tight, and while we have ne= ver=20 done exactly that, we have historically had malloc(3) return NULL when we g= et=20 close to the process data segment size. Robert N M Watson Computer Laboratory University of Cambridge

That will create a sparse file without file system blocks to back it, and is effectively also over-commit. When the file system runs out of room, you will get SIGSEGV when the vnode pager discovers it can't write a page to disk. If you zero-fill it, the blocks are pre-allocated. In a more ideal world, we might support an ioctl or system call to pre-allocate but not hook up the blocks until they were written to, in order to avoid writing lots of zeros to disk, but we don't live in that ideal...

Sparse files are a feature. It just becomes inconvenient at that point because you discover the lack of space asynchronously from a useful user process event. When memory pressure gets high, the vnode pager decides it's time to push a dirty page to disk, and then discovers that there are no free blocks on the file system to write to. As I mentioned in my e-mail, it would be nice if our file system supported a way to reserve blocks for files without hooking them up to the file's visiible add...

Not a good solution on its own. You need a per-process limit as well, otherwise a malloc() bomb will still cause other processes to fail Thank you :) DES -- Dag-Erling Smørgrav - des@des.no _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"

Robert Watson wrote: > On Fri, 4 Jan 2008, Dag-Erling Sm

> > > On Fri, 4 Jan 2008, Dag-Erling Sm

> > > > > On Fri, 4 Jan 2008, Dag-Erling Sm

This will presumably only work for console logins, as sshd (etc) will depen= d=20 on unprivileged users, but perhaps that is fine. I'm less concerned with t= he=20 details of the implementation or policy than that we simply be able to supp= ort=20 even a basic policy and have it configured by default to prevent=20 foot-shooting. Robert N M Watson Computer Laboratory University of Cambridge

[Empty message]