Re: FreeBSD/ZFS on 9.3-RELEASE chews up memory with wide directories when calling readdir, etc; causes trap 12 panics
On Apr 8, 2015, at 9:15, Alan Somers asom...@freebsd.org wrote: On Tue, Apr 7, 2015 at 12:37 AM, Garrett Cooper yaneurab...@gmail.com wrote: Hi, Long story short, I had a lot of mail spooled up in /var/spool. When I did ls /var/spool, ZFS chewed up almost all 12GB of my memory in 10 mins (because there were enough files there) and the system eventually panicked because [I assume that a memory allocation failed and] a trap 12 panic was caught. I don’t have the exact details, but it should be relatively easy to repro (YMMV if you have a boatload of RAM): repro_end=100 for i in $(seq 1 $repro_end); do mktemp tmp.; done ls This might be ameliorated via r281026, but this change is only available in CURRENT (so far), and I haven’t tested it. Are there any comments about this scalability issue with FreeBSD/ZFS? Thanks, I spent the last ~ 24 hours creating 58,567,635 empty files in one directory. I can ls it without crashing on a machine with 32 GB RAM. # /usr/bin/time -l ls /tmp/tmp | wc 1061.21 real 225.54 user36.61 sys 9720268 maximum resident set size 28 average shared memory size 8 average unshared data size 128 average unshared stack size 2425013 page reclaims 0 page faults 0 swaps 108036 block input operations 0 block output operations 0 messages sent 0 messages received 0 signals received 108004 voluntary context switches 2428 involuntary context switches 58567635 58567635 644243985 Strange. I wish I could gather more details about how many files were located there. Distance and time that they were created might manner; in my case there were _many_ spooled up emails that hadn’t been sent because I didn’t take the time to fix my SMTP settings via comcast/gmail. RAM amount might matter too. 12GB vs 32GB is a bit of a difference. Thanks! signature.asc Description: Message signed with OpenPGP using GPGMail
Re: FreeBSD/ZFS on 9.3-RELEASE chews up memory with wide directories when calling readdir, etc; causes trap 12 panics
On Tue, Apr 7, 2015 at 12:37 AM, Garrett Cooper yaneurab...@gmail.com wrote: Hi, Long story short, I had a lot of mail spooled up in /var/spool. When I did ls /var/spool, ZFS chewed up almost all 12GB of my memory in 10 mins (because there were enough files there) and the system eventually panicked because [I assume that a memory allocation failed and] a trap 12 panic was caught. I don’t have the exact details, but it should be relatively easy to repro (YMMV if you have a boatload of RAM): repro_end=100 for i in $(seq 1 $repro_end); do mktemp tmp.; done ls This might be ameliorated via r281026, but this change is only available in CURRENT (so far), and I haven’t tested it. Are there any comments about this scalability issue with FreeBSD/ZFS? Thanks, I spent the last ~ 24 hours creating 58,567,635 empty files in one directory. I can ls it without crashing on a machine with 32 GB RAM. # /usr/bin/time -l ls /tmp/tmp | wc 1061.21 real 225.54 user36.61 sys 9720268 maximum resident set size 28 average shared memory size 8 average unshared data size 128 average unshared stack size 2425013 page reclaims 0 page faults 0 swaps 108036 block input operations 0 block output operations 0 messages sent 0 messages received 0 signals received 108004 voluntary context switches 2428 involuntary context switches 58567635 58567635 644243985 -Alan ___ 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
ports/base ntpd rc.d script with WITHOUT_NTP=yes
Hi, I just upgraded my server to 10.1-STABLE r281264 and when I ran mergemaster it told me that /etc/rc.d/ntpd was stale and would I like to delete it. It's never done this before. I've figured out it's because I have WITHOUT_NTP=yes in /etc/src.conf. I did this because I use the ports version of ntpd and thus wanted to remove the base installed version so that when I run commands like ntpq it's using my possibly newer port installed version and not the older one. However, the port version doesn't have its own rc script. It usually uses the base version with ntpd_program and ntpd_config set. With this latest change it means I have to have the base version installed again. Is it possible to get the port version to have its own rc script? -- Matt ___ 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: ports/base ntpd rc.d script with WITHOUT_NTP=yes
On 04/08/2015 12:48, Matt Smith wrote: Hi, I just upgraded my server to 10.1-STABLE r281264 and when I ran mergemaster it told me that /etc/rc.d/ntpd was stale and would I like to delete it. It's never done this before. I've figured out it's because I have WITHOUT_NTP=yes in /etc/src.conf. I did this because I use the ports version of ntpd and thus wanted to remove the base installed version so that when I run commands like ntpq it's using my possibly newer port installed version and not the older one. However, the port version doesn't have its own rc script. It usually uses the base version with ntpd_program and ntpd_config set. With this latest change it means I have to have the base version installed again. Is it possible to get the port version to have its own rc script? net/openntpd has an rc script if you don't mind switching. It is very very simple to configure. Ideally the original problem should be solved too but I ran into the same problem with Kerberos. I didn't get anywhere in the bug report where I argued the system scripts still worked fine except for recent changes in them causing a regression and failure with the port. Both situations could probably use a contributed patch to make an rc script. ___ 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: ports/base ntpd rc.d script with WITHOUT_NTP=yes
On Apr 08 12:56, Adam McDougall wrote: On 04/08/2015 12:48, Matt Smith wrote: Hi, I just upgraded my server to 10.1-STABLE r281264 and when I ran mergemaster it told me that /etc/rc.d/ntpd was stale and would I like to delete it. It's never done this before. I've figured out it's because I have WITHOUT_NTP=yes in /etc/src.conf. I did this because I use the ports version of ntpd and thus wanted to remove the base installed version so that when I run commands like ntpq it's using my possibly newer port installed version and not the older one. However, the port version doesn't have its own rc script. It usually uses the base version with ntpd_program and ntpd_config set. With this latest change it means I have to have the base version installed again. Is it possible to get the port version to have its own rc script? net/openntpd has an rc script if you don't mind switching. It is very very simple to configure. Ideally the original problem should be solved too but I ran into the same problem with Kerberos. I didn't get anywhere in the bug report where I argued the system scripts still worked fine except for recent changes in them causing a regression and failure with the port. Both situations could probably use a contributed patch to make an rc script. I guess it wouldn't be too hard to just take the base system script, make some minor changes, and add it to the port. Would probably need to call it something different to ntpd though so it doesn't conflict. The openssh port does this I think with ssh in the base and openssh in the port. I might look into it and submit a PR. -- Matt ___ 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
i915kms, Xorg, and Power management discrepency error
Ever since rebuilding world from commit r208369 (merging the newer i915kms from HEAD) I've continually received this error in my stdout/logs: kernel: error: [drm:pid1228:gen6_sanitize_pm] *ERROR* Power management discrepancy: GEN6_RP_INTERRUPT_LIMITS expected 1a0d, was 1a00 The only thing that ever changes is the PID of the process, which always points to Xorg. Under most typical production use this doesn't seem to have any effect, but anytime I watch any sort of video on my production laptop the CPU/GPU temp in my laptop very quickly climbs above 80 degrees celsius. On my multi-purpose server/HTPC, starting an XBMC/Kodi session has the same effect, even if the system is idling (just sitting at the main menu with nothing playing at all). This doesn't stop until I cease video playback on my laptop or kill the Kodi session on the server. Note that the hardware in both machines is identical (yes, the server is a laptop), and they're base systems and kernels are synchronized, so whatever is affectng one should be what's affecting the other. I came across an older mailing list thread from February[1] on this same basic subject that didn't seem to go anywhere, but it had the implication that the i915kms module was the cause. That precisely this same error message is present on various Linux forums bolsters the notion that the video driver might be to blame. If anyone has any insight into how to begin debugging this, I'd be grateful. Thanks in advance. - Bigby [1]: http://freebsd.1045724.n5.nabble.com/Weird-ACPI-DRM-messages-on-current-td5986712.html -- A common mistake that people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools. - Douglas Adams ___ 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: 10-STABLE live locks, looks like VM-related
Hello Lev, Monday, April 6, 2015, 11:55:09 AM, you wrote: I got several live locks of my server in a row (3 in one week). It is amd64 10-STABLE r277307. And again, rebuilded to r281159 http://lev.serebryakov.spb.ru/freebsd/ll/ I've tested memory with memtest86 for 12 hours without errors. Added as core.txt.6 -- Best regards, Levmailto:l...@serebryakov.spb.ru pgpfTu1t_ILmE.pgp Description: PGP signature
