Re: maxproc limit exceeded making no sense
On Fri, May 08, 2009 at 10:51:02AM -0300, Eduardo Meyer wrote: However what I see regarding proc usage is by uid 82 is: # ps -U 82 | wc -l 723 Proccess count for UID 82 is never highter than 913 (monitored the last whole hour, while log messages were still showing, complaining about maxproc limit beeing exceeded). I guess user 82 is exceeding their per-user process limit. This is set (traditionally) using the limit or ulimit shell builtins, but can also be configured in /etc/login.conf or by certain pam modules. I'd start with login.conf. David. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: powerd broken
Robert Noland wrote: On Fri, 2009-04-10 at 16:53 +0200, Dominic Fandrey wrote: Robert Noland wrote: I've been working on the Intel vblank / irq issues. Every time I commit something thinking that I have it resolved, it isn't. So I'm waiting on hardware to arrive that will let me test this all more thoroughly. I do have a patch that I think fixes most of the issues on Intel, but the ddx driver is still doing some silly things that cause issues in some cases. I *think* the only outstanding issue I have with Intel is if something is rendering (synced to vblank or not) when the display goes into dpms sleep, there isn't anything to block that app, so it renders as hard as it can even though it isn't being displayed. In reality, this probably isn't a huge issue, but running gears while the display is asleep keeps the cpu at 100%, which isn't ideal. Normal apps that aren't trying to draw as fast as they can, shouldn't cause an issue. With the latest drm, the IRQ craziness is gone. However, the crappy performance remains. 2 months ago a RELENG_7 with all packages up to date yielded 124fps in a q3 timedemo that now yields 80fps. Things are still not quite right with the Intel driver. But performance regressions are reported across Linux as well. A little of this might be us, but most of it is Intel... I don't know what you did with the last update, but performance is now better than ever (2% above what it used to be), which equels 3-4 more frames in ioQuake3 or 200 more in glxgears. The uptime of the notebook is now 15 hours and the interrupt load insignificant. I get no more than 8000 interrupts per seconds. 4000 of these are CPU timers (2000 for each core) and 1000 more are from my mouse, when I move it very fast. Around 2500 from vgapci, when I run glxgears and the rest is just scraps of whatever else is running (e.g. sound). Thanks a lot. Regards ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: powerd broken
On Sat, 2009-05-09 at 10:26 +0200, Dominic Fandrey wrote: Robert Noland wrote: On Fri, 2009-04-10 at 16:53 +0200, Dominic Fandrey wrote: Robert Noland wrote: I've been working on the Intel vblank / irq issues. Every time I commit something thinking that I have it resolved, it isn't. So I'm waiting on hardware to arrive that will let me test this all more thoroughly. I do have a patch that I think fixes most of the issues on Intel, but the ddx driver is still doing some silly things that cause issues in some cases. I *think* the only outstanding issue I have with Intel is if something is rendering (synced to vblank or not) when the display goes into dpms sleep, there isn't anything to block that app, so it renders as hard as it can even though it isn't being displayed. In reality, this probably isn't a huge issue, but running gears while the display is asleep keeps the cpu at 100%, which isn't ideal. Normal apps that aren't trying to draw as fast as they can, shouldn't cause an issue. With the latest drm, the IRQ craziness is gone. However, the crappy performance remains. 2 months ago a RELENG_7 with all packages up to date yielded 124fps in a q3 timedemo that now yields 80fps. Things are still not quite right with the Intel driver. But performance regressions are reported across Linux as well. A little of this might be us, but most of it is Intel... I don't know what you did with the last update, but performance is now better than ever (2% above what it used to be), which equels 3-4 more frames in ioQuake3 or 200 more in glxgears. The uptime of the notebook is now 15 hours and the interrupt load insignificant. I get no more than 8000 interrupts per seconds. 4000 of these are CPU timers (2000 for each core) and 1000 more are from my mouse, when I move it very fast. Around 2500 from vgapci, when I run glxgears and the rest is just scraps of whatever else is running (e.g. sound). Which update, what? I haven't touched the kernel tree in a while, just trying to sort it all out with patches here and there. Are you saying the the 2.7.0 intel driver helped? Or maybe the Xserver or mesa updates? robert. Thanks a lot. Regards -- Robert Noland rnol...@freebsd.org FreeBSD signature.asc Description: This is a digitally signed message part
Re: powerd broken
Robert Noland wrote: On Sat, 2009-05-09 at 10:26 +0200, Dominic Fandrey wrote: Robert Noland wrote: On Fri, 2009-04-10 at 16:53 +0200, Dominic Fandrey wrote: Robert Noland wrote: I've been working on the Intel vblank / irq issues. Every time I commit something thinking that I have it resolved, it isn't. So I'm waiting on hardware to arrive that will let me test this all more thoroughly. I do have a patch that I think fixes most of the issues on Intel, but the ddx driver is still doing some silly things that cause issues in some cases. I *think* the only outstanding issue I have with Intel is if something is rendering (synced to vblank or not) when the display goes into dpms sleep, there isn't anything to block that app, so it renders as hard as it can even though it isn't being displayed. In reality, this probably isn't a huge issue, but running gears while the display is asleep keeps the cpu at 100%, which isn't ideal. Normal apps that aren't trying to draw as fast as they can, shouldn't cause an issue. With the latest drm, the IRQ craziness is gone. However, the crappy performance remains. 2 months ago a RELENG_7 with all packages up to date yielded 124fps in a q3 timedemo that now yields 80fps. Things are still not quite right with the Intel driver. But performance regressions are reported across Linux as well. A little of this might be us, but most of it is Intel... I don't know what you did with the last update, but performance is now better than ever (2% above what it used to be), which equels 3-4 more frames in ioQuake3 or 200 more in glxgears. The uptime of the notebook is now 15 hours and the interrupt load insignificant. I get no more than 8000 interrupts per seconds. 4000 of these are CPU timers (2000 for each core) and 1000 more are from my mouse, when I move it very fast. Around 2500 from vgapci, when I run glxgears and the rest is just scraps of whatever else is running (e.g. sound). Which update, what? I haven't touched the kernel tree in a while, just trying to sort it all out with patches here and there. Are you saying the the 2.7.0 intel driver helped? Or maybe the Xserver or mesa updates? I update my ports daily, without really looking at what. I think xorg-server was one of them. It must have been something that happened during the last 48 hours. robert. Thanks a lot. Regards ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: powerd broken
On Sat, 2009-05-09 at 15:10 +0200, Dominic Fandrey wrote: Robert Noland wrote: On Sat, 2009-05-09 at 10:26 +0200, Dominic Fandrey wrote: Robert Noland wrote: On Fri, 2009-04-10 at 16:53 +0200, Dominic Fandrey wrote: Robert Noland wrote: I've been working on the Intel vblank / irq issues. Every time I commit something thinking that I have it resolved, it isn't. So I'm waiting on hardware to arrive that will let me test this all more thoroughly. I do have a patch that I think fixes most of the issues on Intel, but the ddx driver is still doing some silly things that cause issues in some cases. I *think* the only outstanding issue I have with Intel is if something is rendering (synced to vblank or not) when the display goes into dpms sleep, there isn't anything to block that app, so it renders as hard as it can even though it isn't being displayed. In reality, this probably isn't a huge issue, but running gears while the display is asleep keeps the cpu at 100%, which isn't ideal. Normal apps that aren't trying to draw as fast as they can, shouldn't cause an issue. With the latest drm, the IRQ craziness is gone. However, the crappy performance remains. 2 months ago a RELENG_7 with all packages up to date yielded 124fps in a q3 timedemo that now yields 80fps. Things are still not quite right with the Intel driver. But performance regressions are reported across Linux as well. A little of this might be us, but most of it is Intel... I don't know what you did with the last update, but performance is now better than ever (2% above what it used to be), which equels 3-4 more frames in ioQuake3 or 200 more in glxgears. The uptime of the notebook is now 15 hours and the interrupt load insignificant. I get no more than 8000 interrupts per seconds. 4000 of these are CPU timers (2000 for each core) and 1000 more are from my mouse, when I move it very fast. Around 2500 from vgapci, when I run glxgears and the rest is just scraps of whatever else is running (e.g. sound). Which update, what? I haven't touched the kernel tree in a while, just trying to sort it all out with patches here and there. Are you saying the the 2.7.0 intel driver helped? Or maybe the Xserver or mesa updates? I update my ports daily, without really looking at what. I think xorg-server was one of them. It must have been something that happened during the last 48 hours. Ok, well server, mesa and intel driver all got updates in my sweep the other day. robert. robert. Thanks a lot. Regards -- Robert Noland rnol...@freebsd.org FreeBSD signature.asc Description: This is a digitally signed message part
FreeBSD Status Reports January - March, 2009
FreeBSD Quarterly Status Report Introduction Since the last Status Reports there has been interesting progress in FreeBSD Development. FreeBSD 7.2 was released just a few days ago. Some of the highlights include: Support for superpages in the FreeBSD Virtual Memory subsystem. The FreeBSD Kernel Virtual Address space has been increased to 6GB on amd64. An updated jail(8) subsystem that supports multi-IPv4/IPv6/noIP and much more. Lots of FreeBSD Developers are in Ottawa, Canada attending the FreeBSD Developer Summit that is before BSDCan. BSDCan officially starts tomorrow and should cover lots of interesting topics, see the BSDCan Website for more information. Thanks to all the reporters for the excellent work! We hope you enjoy reading. __ Projects * Clang replacing GCC in the base system * Device mmap() Extensions * OpenBSM * Release Engineering * Sysinfo - a set of scripts which document your system * TrustedBSD MAC Framework in GENERIC * VFS/NFS DTrace Probes * VirtualBox on FreeBSD FreeBSD Team Reports * FreeBSD BugBusting Team Architectures * FreeBSD/powerpc G5 Support * FreeBSD/sparc64 UltraSPARC III support Documentation * Dutch Documentation Project * German Documentation Project * Hungarian Documentation Project Google Summer of Code * BSD-licensed text-processing tools __ BSD-licensed text-processing tools URL: http://perforce.freebsd.org/depotTreeBrowser.cgi?FSPC=//depot/projects/ soc2008/gabor_textproc Contact: Gábor Kövesdán ga...@freebsd.org Currently, grep is finished and is only waiting for a portbuild test. It is known to be more or less feature complete, while it is much smaller than the GNU version. As for sort, there has been some progress with the complete rewrite and it is lacking few options. Performance is to be measured, as well. Open tasks: 1. Test grep on pointyhat. 2. Complete sort with the missing features. 3. Do performance measurements for sort and look for possible optimization opportunities. 4. Test sort on pointyhat. __ Clang replacing GCC in the base system URL: http://wiki.freebsd.org/BuildingFreeBSDWithClang URL: http://git.hoeg.nl/?p=llvm-bmake URL: http://clang.llvm.org/ Contact: Ed Schouten e...@freebsd.org Contact: Roman Divacky rdiva...@freebsd.org Contact: Brooks Davis bro...@freebsd.org Contact: Pawel Worach pawel.wor...@gmail.com The last 3-4 months we've been working together with the LLVM developers to discuss any bugs and issues we are experiencing with their Clang compiler frontend. The FreeBSD project is looking at the possibility to replace GCC with Clang as a system compiler. It can compile 99% of the FreeBSD world and can compile booting kernel on i386/amd64 but it still contains bugs and its C++ support is still immature. Ed is maintaining a patchset for the FreeBSD sources to replace cc(1) by a Clang binary and bootstrap almost all sources with the Clang compiler. The LLVM developers are very helpful fixing most of the bugs we've reported (over 100). Unfortunately we are currently blocked on some bug reports that prevent us from building libc, libm, libcrypto and various CDDL libraries with Clang but the FreeBSD kernel itself compiles and boots. Open tasks: 1. Testing Clang with compilation of various applications and reporting bugs. 2. Testing the llvm-bmake branch to find more bugs. 3. Arranging an experimental ports build. __ Device mmap() Extensions URL: http://www.FreeBSD.org/~jhb/pat/ Contact: John Baldwin j...@freebsd.org GPU device drivers are increasingly requiring more sophisticated support for mapping objects into both userland and the kernel. For example, memory used for textures often needs to be mapped Write-Combining rather than Write-Back. I have recently created three patches to provide several extensions. The first patch allows device drivers to use a different VM object to back specific mmap() calls instead of always using the device pager. The second patch introduces a new VM object type that can map an arbitrary set of physical address ranges. This can be used to let userland mmap PCI BARs, etc. The third patch allows memory mappings to use different caching modes (e.g. Write-Combining or Uncacheable). Together I believe these patches provide the remaining pieces needed for an Nvidia amd64 driver. They will also be useful for future Xorg DRM support as well. The current set of patches can be safely merged back to 7.x as well.
RE: 7.1-STABLE Sun Mar 29 01:06:46 ADT 2009 Locks up ...
On Tue, 28 Apr 2009, Gavin Atkinson wrote: On Fri, 2009-04-24 at 20:39 +0200, Martin Schmidt wrote: Hi Marc and List, i had similar issues with FreeBSD 7.2-PRERELEASE. Server (zfs,nfs) seems to hang in intervals of about 8 hours. kernel is still there but no connections can be made to nfs/ssh and login on local console doesn't seem to work due to incredible slowness. breaking to the debugger takes a moment but works. (compiling kernel with WITNESS didnt help) the server had been solid before with 7 stable kernel from around 19 October 2008. I now added these lines to /boot/loader.conf hw.pci.enable_msi=0 hw.pci.enable_msix=0 to disable Message Signaled Interrupts. Which are used by the 3ware twa driver and igb network driver on our server. If you are willing to test further on your server, it may be helpful if you could determine which of those two lines in loader.conf fixes the problem for you. It would also be useful to provide a dmesg from the machine when both msi and msix are enabled. FWIW, looking at the vmstat -i output it appears that only the igb driver that are using MSI/MSIX, unless you have a reason to suspect otherwise? How do you tell that, about igb? looking at the server I have the igb device on, it doesn't seem to say anything about that ... # vmstat -i interrupt total rate irq1: atkbd0 162 0 irq30: twa0402647215187 cpu0: timer 4284778818 1999 irq256: igb0 1282945461598 irq257: igb0 215507100100 irq258: igb0 417702261194 irq259: igb0 314601966146 irq260: igb0 568062067265 irq261: igb0 3 0 cpu5: timer 428475 1999 cpu6: timer 4284731466 1999 cpu7: timer 4284724508 1999 cpu1: timer 4284893874 1999 cpu3: timer 4284899807 1999 cpu2: timer 4284892325 1999 cpu4: timer 4284897264 1999 Total37480028742 17493 The server(s) that I am experiencing the hangs on, vmstat -i shows: # vmstat -i interrupt total rate irq1: atkbd0 2 0 irq3: sio1 8 0 irq25: bge0 4614816213 irq72: ciss0 1835763 85 cpu0: timer 43113685 1997 cpu1: timer 43116889 1997 Total 92681163 4293 Are any of these similiarly using MSI/MSIX? Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . scra...@hub.org MSN . scra...@hub.org Yahoo . yscrappy Skype: hub.orgICQ . 7615664 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
RE: 7.1-STABLE Sun Mar 29 01:06:46 ADT 2009 Locks up ...
'k, based on grep'ng the source files, turns out that the if_bge device driver uses msi, while, as you point out, the igb uses msix ... I have disabled msi on the two servers with bge devices, and msix on the one with igb ... all three have given the same sort of problem after varying periods of time ... let's see if I can get to 30 days uptime with this ... On Tue, 28 Apr 2009, Gavin Atkinson wrote: On Fri, 2009-04-24 at 20:39 +0200, Martin Schmidt wrote: Hi Marc and List, i had similar issues with FreeBSD 7.2-PRERELEASE. Server (zfs,nfs) seems to hang in intervals of about 8 hours. kernel is still there but no connections can be made to nfs/ssh and login on local console doesn't seem to work due to incredible slowness. breaking to the debugger takes a moment but works. (compiling kernel with WITNESS didnt help) the server had been solid before with 7 stable kernel from around 19 October 2008. I now added these lines to /boot/loader.conf hw.pci.enable_msi=0 hw.pci.enable_msix=0 to disable Message Signaled Interrupts. Which are used by the 3ware twa driver and igb network driver on our server. If you are willing to test further on your server, it may be helpful if you could determine which of those two lines in loader.conf fixes the problem for you. It would also be useful to provide a dmesg from the machine when both msi and msix are enabled. FWIW, looking at the vmstat -i output it appears that only the igb driver that are using MSI/MSIX, unless you have a reason to suspect otherwise? Gavin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . scra...@hub.org MSN . scra...@hub.org Yahoo . yscrappy Skype: hub.orgICQ . 7615664 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Xorg hangs with drmwtq in 7.2-RELEASE
On Friday 08 May 2009 03:31:04 pm Robert Noland wrote: In order to guess what might be causing this, drm debugging needs to be enabled before the hang, so that we can hopefully figure out what leads up to the hung GPU. Unfortunately that won't work, because turning on hw.dri.0.debug slows down compositing so much that it won't reproduce. -- David Johnson ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Xorg hangs with drmwtq in 7.2-RELEASE
On Friday 08 May 2009 03:31:04 pm Robert Noland wrote: In order to guess what might be causing this, drm debugging needs to be enabled before the hang, so that we can hopefully figure out what leads up to the hung GPU. I'm not able to do that, but I did manage to get debug turned on and dmesg captured early enough to catch some additional information. I've place the full file online at http://www.usermode.org/misc/dmesg.txt, but am including some snippets here. Hopefully this is enough to move forward. -- David Johnson ... [drm:pid1822:drm_ioctl] pid=1822, cmd=0xc0286429, nr=0x29, dev 0xc615fa00, auth=1 [drm:pid1822:radeon_freelist_get] done_age = 102778 [drm:pid1822:drm_ioctl] pid=1822, cmd=0xc010644d, nr=0x4d, dev 0xc615fa00, auth=1 [drm:pid1822:radeon_cp_indirect] idx=27 s=0 e=88 d=1 [drm:pid1822:radeon_cp_dispatch_indirect] buf=27 s=0x0 e=0x58 [drm:pid1822:drm_close] open_count = 2 [drm:pid1822:drm_close] pid = 1822, device = 0xc615fa00, open_count = 2 [drm:pid1822:drm_ioctl] pid=1822, cmd=0x80086442, nr=0x42, dev 0xc615fa00, auth=1 [drm:pid1822:radeon_cp_stop] [drm:pid1822:radeon_do_cp_flush] [drm:pid1822:radeon_do_cp_idle] [drm:pid1822:radeon_do_cp_stop] [drm:pid1822:radeon_do_engine_reset] info: [drm] Num pipes: 1 [drm:pid1822:radeon_do_cp_reset] [drm:pid1822:drm_ioctl] pid=1822, cmd=0x800c6459, nr=0x59, dev 0xc615fa00, auth=1 [drm:pid1822:drm_ioctl] pid=1822, cmd=0x80086414, nr=0x14, dev 0xc615fa00, auth=1 [drm:pid1822:drm_irq_uninstall] irq=16 [drm:pid1822:drm_ioctl] pid=1822, cmd=0x80546440, nr=0x40, dev 0xc615fa00, auth=1 [drm:pid1822:radeon_do_cleanup_cp] [drm:pid1822:drm_ioctl] pid=1822, cmd=0x80086439, nr=0x39, dev 0xc615fa00, auth=1 [drm:pid1822:drm_sg_free] sg free virtual = 0xe8a64000 [drm:pid1822:drm_ioctl] pid=1822, cmd=0x8004667e, nr=0x7e, dev 0xc615fa00, auth=1 [drm:pid1822:drm_ioctl] pid=1822, cmd=0x8004667d, nr=0x7d, dev 0xc615fa00, auth=1 [drm:pid1822:drm_ioctl] pid=1822, cmd=0xc0086421, nr=0x21, dev 0xc615fa00, auth=1 [drm:pid1822:drm_rmctx] 2 [drm:pid1822:drm_ioctl] pid=1822, cmd=0xc0086421, nr=0x21, dev 0xc615fa00, auth=1 [drm:pid1822:drm_rmctx] 1 [drm:pid1822:drm_ioctl] pid=1822, cmd=0xc0086426, nr=0x26, dev 0xc615fa00, auth=1 [drm:pid1822:drm_ioctl] pid=1822, cmd=0xc0086426, nr=0x26, dev 0xc615fa00, auth=1 [drm:pid1822:drm_ioctl] pid=1822, cmd=0x8008642b, nr=0x2b, dev 0xc615fa00, auth=1 [drm:pid1822:drm_unlock] 1 (pid 1822) requests unlock (0x8001), flags = 0x [drm:pid1822:drm_close] open_count = 1 [drm:pid1822:drm_close] pid = 1822, device = 0xc615fa00, open_count = 1 [drm:pid1822:drm_lastclose] [drm:pid1822:radeon_do_cleanup_cp] info: [drm] Setting GART location based on new memory map info: [drm] Loading R500 Microcode info: [drm] Num pipes: 1 info: [drm] writeback test succeeded in 1 usecs drm0: [ITHREAD] info: [drm] Num pipes: 1 info: [drm] Setting GART location based on new memory map info: [drm] Loading R500 Microcode info: [drm] Num pipes: 1 info: [drm] writeback test succeeded in 1 usecs drm0: [ITHREAD] info: [drm] Num pipes: 1 info: [drm] Setting GART location based on new memory map info: [drm] Loading R500 Microcode info: [drm] Num pipes: 1 info: [drm] writeback test succeeded in 1 usecs drm0: [ITHREAD] info: [drm] Num pipes: 1 info: [drm] Setting GART location based on new memory map info: [drm] Loading R500 Microcode info: [drm] Num pipes: 1 info: [drm] writeback test succeeded in 1 usecs drm0: [ITHREAD] info: [drm] Num pipes: 1 info: [drm] Setting GART location based on new memory map info: [drm] Loading R500 Microcode info: [drm] Num pipes: 1 info: [drm] writeback test succeeded in 1 usecs drm0: [ITHREAD] info: [drm] Num pipes: 1 info: [drm] Setting GART location based on new memory map info: [drm] Loading R500 Microcode info: [drm] Num pipes: 1 info: [drm] writeback test succeeded in 1 usecs drm0: [ITHREAD] info: [drm] Num pipes: 1 info: [drm] Setting GART location based on new memory map info: [drm] Loading R500 Microcode info: [drm] Num pipes: 1 info: [drm] writeback test succeeded in 1 usecs drm0: [ITHREAD] [drm:pid6216:drm_ioctl] returning 4 [drm:pid6216:drm_ioctl] pid=6216, cmd=0x80046457, nr=0x57, dev 0xc615fa00, auth=1 [drm:pid6216:drm_ioctl] returning 4 [drm:pid6216:drm_ioctl] pid=6216, cmd=0x80046457, nr=0x57, dev 0xc615fa00, auth=1 [drm:pid6216:drm_ioctl] returning 4 [drm:pid6216:drm_ioctl] pid=6216, cmd=0x80046457, nr=0x57, dev 0xc615fa00, auth=1 [drm:pid6216:drm_ioctl] returning 4 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
