http://blog.gmane.org/gmane.os.freebsd.stable hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.os.freebsd.stable/80619 <pre> On Fri, May 25, 2012 at 07:44:39AM +0200, Trond Endrest?l wrote: Same here but on 8.3-STABLE i386 no errors found throughout any of the tests. </pre> Jason Hellenthal 2012-05-25T15:45:30 http://permalink.gmane.org/gmane.os.freebsd.stable/80618 <pre>Hello, a user at BSDForen.de had the same problem and I helped him to track it down. While I was unable to find a solution I found the cause of the problems. The problem is (all files and line numbers relative to FreeBSD 9.0-RELEASE): 1. When a new p-state is requested (by powerd or by changing the sysctl) in kern/kern_cpu.c the function cf_set_method() is invoked. 2. In line 335 the driver depended function is called. For newer AMD CPU it's hwpstate_set() in x86/cpufreq/hwpstate.c 3. In x86/cpufreq/hwpstate.c line 227 hwpstate_goto_pstate() is called which does the actual magic. 4. In line 199 "if (msr != id)" triggers, returns ENXIO. The error is send back to cf_set_method(), which prints the "hwpstate0: set freq failed". powerd translates the error to "Device not configured" After some further investigation and looking at the linux driver [0] I changed the loop at x86/cpufreq/hwpstate.c 188ff from 100 iterations to 250. It lessend the problem but didn't solve it. The next step was to rewrite the logic between line 183 and 203 and adding a lot of debug printf. The patch (non style(9) compliant) is attached. With the new logic every 100 usec the new p-state is set again, until it's accepted. After 100 tries ENXIO is returned. This lessend the problem even more and showed that - On an old Phenom II X4 940 (K10 / Deneb) the new p-state is always accepted at the first try. At a test run for about 3 hours there was not a single failure. - On the Bulldozer CPU in about 9 in 10 times the new p-state is accepted at the first try. At most other times the new p-state is accepted after 1 to 10 tries. And there is a ~0,25% chance that the new p-state is never accepted, leading to "hwpstate0: set freq failed". At the next call to cf_set_method() (about 500ms to 1s later) the new p-state it's most likely set successfull. This can be seen at the log (full log attached): # First call, failed after 102 iterations hwpstate0: MSR: 0 ID: 1 hwpstate0: Setting failed! hwpstate0: Iterations: 102 # Second call, successfull hwpstate0: setting P1-state on cpu1 hwpstate0: MSR: 1 ID: 1 hwpstate0: Iterations: 1 So the big question is: Why is the new p-state sometimes not accepted? And why does this only happen on Bulldozer CPUs and not at the old K10 (Barcelona, Deneb), etc? Reading the "BIOS and kernel developer guide" for Bulldozer didn't show anything, but I may have overlooked it. One solution may be to change hwpstate not to set p-states but "Frequency IDs" (FID) and "Voltage ID" (VID) like the linux driver does. 0: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=blob;f=drivers/cpufreq/powernow-k8.c;h=c0e816468e300f242735f4825d09b9d291a9b522;hb=HEAD 1: http://support.amd.com/us/Processor_TechDocs/42301_15h_Mod_00h-0Fh_BKDG.pdf </pre> Yamagi Burmeister 2012-05-25T14:36:53 http://permalink.gmane.org/gmane.os.freebsd.stable/80617 <pre>Hi! I don't know if this is the right list for this question, but I cannot find anything related about "cifs" or "samba". By the way I would apologize about my bad english... My system is a FreeBSD 9-RELEASE i386. The windows server at office have a large path to the shares (sub-path), e.g. //teide/recursos/usuarios/myuser where "recursos" is a share, and inside it, "myuser" is another share from "usuarios" (users). This runs fine in any linux. In FreeBSD this is my fstab entry: //mtrujillo&lt; at &gt;teide/recursos/usuarios/myuser /media/personal smbfsnoauto,rw,-u=myuser,-g=myuser,-N 0 0 I have also an /etc/nsmb.conf configured. All runs fine... except because I only can mount up to "recursos" (from the line teide/recursos/usuarios/myuser), and NOT the share "myuser" (the last part of the PATH). Anybody could help me please? Thank you very much! </pre> Manuel Trujillo (TooManySecrets 2012-05-25T10:38:14 http://permalink.gmane.org/gmane.os.freebsd.stable/80616 <pre> Interesting. I have this setting "Off" - but my machines were perfectly reliable until AIO was added to the mix. Are yours directly on top of a zvol as the underlying disc, or using files on ZFS ? Will try enabling that setting - thoigh as it is stable anyway it wont make a lot of diffeernce I hope! cheers, -pete. _______________________________________________ freebsd-stable&lt; at &gt;freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscribe&lt; at &gt;freebsd.org" </pre> Pete French 2012-05-25T10:00:56 http://permalink.gmane.org/gmane.os.freebsd.stable/80615 <pre>Hi, No, I didn't have vesa loaded. I'll load that now and try tomorrow after a reboot. Yes, I tried switching VTYs, each VTY had the same issue. I guess the driver isn't doing a VGA mode change when I switch VTYs unless the screens are in different modes? FWIW, Xorg suspend/resume via the "switch to VTY before suspending" hack works on this Thinkpad T60. It's not optimal but hey, it _does_ work. :) Adrian _______________________________________________ freebsd-stable&lt; at &gt;freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscribe&lt; at &gt;freebsd.org" </pre> Adrian Chadd 2012-05-25T07:51:38 http://permalink.gmane.org/gmane.os.freebsd.stable/80614 <pre>-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thu, 24 May 2012 13:07-0700, Sean Bruno wrote: I'm unable to reproduce this behaviour on one of my systems: trond&lt; at &gt;enterprise:~&gt;bash --version GNU bash, version 4.2.28(0)-release (amd64-portbld-freebsd9.0) Copyright (C) 2011 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later &lt;http://gnu.org/licenses/gpl.html&gt; This is free software; you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. trond&lt; at &gt;enterprise:~&gt;my_var="$(uname)" trond&lt; at &gt;enterprise:~&gt;echo $my_var FreeBSD trond&lt; at &gt;enterprise:~&gt; I'm not sure what's going on in your case. - -- +-------------------------------+------------------------------------+ | Vennlig hilsen, | Best regards, | | Trond Endrestøl, | Trond Endrestøl, | | IT-ansvarlig, | System administrator, | | Fagskolen Innlandet, | Gjøvik Technical College, Norway, | | tlf. dir. 61 14 54 39, | Office.....: +47 61 14 54 39, | | tlf. mob. 952 62 567, | Cellular...: +47 952 62 567, | | sentralbord 61 14 54 00. | Switchboard: +47 61 14 54 00. | +-------------------------------+------------------------------------+ -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk+/HEwACgkQbYWZalUoElvZYwCeLq5IHGp2dLyf+pcbzC1jk3RK us4An1AX5SelbwMEEVmooiopPmF9SAlI =9bTW -----END PGP SIGNATURE-----_______________________________________________ freebsd-stable&lt; at &gt;freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscribe&lt; at &gt;freebsd.org"</pre> Trond Endrestøl 2012-05-25T05:44:39 http://permalink.gmane.org/gmane.os.freebsd.stable/80613 <pre>Hi, On 23/05/2012, at 11:11 PM, Pete French wrote: I have seen similar behaviour, but I did not disable AIO to solve it. Instead, in the VirtualBox VM, I made sure that the storage controller was created with the "--hostiocache on" option. Without that, the virtual machines were unreliable on ZFS with the same behaviour you saw. Do you have the hostiocache enabled or disabled in your VM? Does it make a difference? Regards, Jan. _______________________________________________ freebsd-stable&lt; at &gt;freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscribe&lt; at &gt;freebsd.org" </pre> Jan Mikkelsen 2012-05-25T05:25:09 http://permalink.gmane.org/gmane.os.freebsd.stable/80612 <pre>Hi, thanks for reporting! Do you have vesa(4) in your kernel? It seems dev/fv/vesa.c:vesa_bios_post() restore the mode when resuming, but it's maybe incomplete in some cases... I think great work was done in this area, and we can improve this more. How about switching vty to other different mode vty and switching back in order to force changing video mode? I think it's better than re-run vidcontrol. This is my pleasure :) Thanks! _______________________________________________ freebsd-stable&lt; at &gt;freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscribe&lt; at &gt;freebsd.org" </pre> Mitsuru IWASAKI 2012-05-25T04:49:03 http://permalink.gmane.org/gmane.os.freebsd.stable/80611 <pre> Note that enough of those patches have been committed (at least as of r235891) that I was able to perform suspend/resume properly on my laptop (a Dell Precision M4400; video is "NVIDIA GPU Quadro FX 770M (G96GL)", and I use the nVidia driver (ports/x11/nvidia-driver)) without adding more patches. I do not see that behavior, and: g1-227(8.3-S)[7] sysctl hw.acpi.reset_video hw.acpi.reset_video: 0 (Yes, I'm running stable/8 on the present slice. I have stable/9 on another slice. And the experiment I did was with a slice where I had built stable/9 (i386) using clang.) That is another issue that I have not observed (in my case). I believe that my experience is evidence that if such a shortciming exists, it is not a general one. For me, suspend/resume in stable/9 Just Works (thanks to the hard work of others (such as iwasaki&lt; at &gt;), of course). Cool! :-) (Adrian, next BAFUG, perhaps we could compare notes/behaviors in person, if that might be of use?) Peace, david </pre> David Wolfskill 2012-05-25T04:07:00 http://permalink.gmane.org/gmane.os.freebsd.stable/80610 <pre>Hi, I'm toying with the SMP/i386 ACPI suspend/resume patches in -9. Thanks so much for this! I've noticed though that the video backlight stays off after resume. A common problem on -9, so I set hw.acpi.reset_video=1. That restores the backlight. However, the video mode isn't restored. I have my console set to VGA_80x60 and the resume seems to set it up "wrong". I get half or so of each line displayed. A vidcontrol VGA_80x60 restores things to proper working order. Is there a shortcoming somewhere in syscons/ACPI video restore on -9 that doesn't properly restore the configured mode? Thanks again for all your hard work! Now that you've done that, I'll go off and work on fixing up ath(4) suspend/resume for PCI devices. :) Adrian _______________________________________________ freebsd-stable&lt; at &gt;freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscribe&lt; at &gt;freebsd.org" </pre> Adrian Chadd 2012-05-25T03:46:03 http://permalink.gmane.org/gmane.os.freebsd.stable/80609 <pre> I think I should restore the old behavior for CURRENT as well. The -i option really only exists for /etc/rc.d/jail, and should behave the way it expects it to. And if anything else uses it, all the more reason not to change it. - Jamie _______________________________________________ freebsd-stable&lt; at &gt;freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscribe&lt; at &gt;freebsd.org" </pre> Jamie Gritton 2012-05-25T02:39:07 http://permalink.gmane.org/gmane.os.freebsd.stable/80608 <pre> Note that my proposal with persistent jail creation as first step doesn't conflict with new behavior of jail(8) regarding jid printing. Also, I think that head -&gt; tail change for rc.d script that I proposed is broken. I think that as a short-term solution you should restore old behavior (jid printed before everything else) for -STABLE. The reason is that currently you have to take the jid from the last line, but you cannot be sure that jailed processes didn't mess with the output, so you actually cannot trust the last line, so you don't know the actual jid. That is: rc.d/jail reads the last line jail(8) just writes jid to very same file that contains output of jailed /etc/rc. So if the last line written by jailed processes doesn't end with newline character, jail(8) will just append jid to the line, so the actual content of /var/run/jail_foo.id will consist of characters written by possibly malicious script and jid. This could be used to store jid of another jail (assuming jid 2, /etc/rc consisting of echo -n 1 would result in stored jid 12 etc.) or random content that in some conditions could lead to code execution. </pre> Mateusz Guzik 2012-05-25T01:23:27 http://permalink.gmane.org/gmane.os.freebsd.stable/80607 <pre> There definitely is a difference between old and new jail behavior, not just in the order of things: glorfindel# jail -i -c name=foo command="foo" 5 jail: execvp: foo: No such file or directory vs glorfindel# /usr/obj`pwd`/jail -i -c name=foo command="foo" jail: exec foo: No such file or directory jail: foo: failed -1 The jail id given back used to correspond to a jail that was created but no longer exists by the time it's printed (or shortly thereafter). Now it's a -1 indicating that no jail exists. I think the -1 is more correct, but perhaps better for CURRENT but not STABLE? And the extra "foo: failed" is printed by jail, as a generic message when a command doesn't work out (for the case where the command itself doesn't print a message). Hmm ... I'll be pondering this one while I get a bite to eat :-). - Jamie _______________________________________________ freebsd-stable&lt; at &gt;freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscribe&lt; at &gt;freebsd.org" </pre> Jamie Gritton 2012-05-25T00:47:30 http://permalink.gmane.org/gmane.os.freebsd.stable/80606 <pre> No idea, but devel/diffuse might be alternative. _______________________________________________ freebsd-stable&lt; at &gt;freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscribe&lt; at &gt;freebsd.org" </pre> Warren Block 2012-05-24T23:14:17 http://permalink.gmane.org/gmane.os.freebsd.stable/80605 <pre> Yeah, was not sure whether I should change the order or the script. :) Would not it be better to just create empty persistent jail as first step? Since in this case only one line will be generated (jid), rc.d script will be able to just take the output - this seems much less fragile than the current method. Then of course it would proceed with jexec running /etc/rc and in the end drop persist flag. It looks like rc.d script still uses old syntax so this actually may be less trivial than it sounds. That being said, if this is idea sounds okay, I can try to come up with a patch this weekend. </pre> Mateusz Guzik 2012-05-24T22:59:31 http://permalink.gmane.org/gmane.os.freebsd.stable/80604 <pre> I'll get the patch to jail(8) in - thanks for catching that. But I wonder about the patch to /etc/rc.d/jail. It looks correct, but I'm going to see if it's /etc/rc.d/jail that needs changing, or if my recent changes to jail(8) have changed the order in which things are written. - Jamie _______________________________________________ freebsd-stable&lt; at &gt;freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscribe&lt; at &gt;freebsd.org" </pre> Jamie Gritton 2012-05-24T22:46:52 http://permalink.gmane.org/gmane.os.freebsd.stable/80603 <pre> Patch contains two fixes, for both usr/sbin/jail and etc/rc.d/jail. Assuming that the patch is still applied to your source tree, just do: cp /usr/src/etc/rc.d/jail /etc/rc.d/jail This fixes the jail script to actually store jail id instead of messages from /etc/rc. That is, you should be able to stop jails started by new etc/rc.d/jail script. </pre> Mateusz Guzik 2012-05-24T22:30:05 http://permalink.gmane.org/gmane.os.freebsd.stable/80602 <pre> Sigh, sorry, it's been a long day. I didnt look at the patch :P It works perfectly now, thanks again, hope someone can commit this soon. _______________________________________________ freebsd-stable&lt; at &gt;freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscribe&lt; at &gt;freebsd.org" </pre> Mike Jakubik 2012-05-24T22:25:05 http://permalink.gmane.org/gmane.os.freebsd.stable/80601 <pre> Right, i just realized this. I set the hostname in the jailed rc.conf, now the file contains this: root&lt; at &gt;jail.local:~# cat /var/run/jail_app.id Setting hostname: app.local. I do not see a link to your jail rc.d script, just the patch. _______________________________________________ freebsd-stable&lt; at &gt;freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscribe&lt; at &gt;freebsd.org" </pre> Mike Jakubik 2012-05-24T22:20:15 http://permalink.gmane.org/gmane.os.freebsd.stable/80600 <pre> This message is about rc.conf from your jail. This should be fixed by my change to etc/rc.d/jail, are you sure that you are running patched version? </pre> Mateusz Guzik 2012-05-24T22:13:53 http://permalink.gmane.org/gmane.os.freebsd.stable/80599 <pre>Sorry, I was going too fast. &gt; uname -a FreeBSD P9X79.tddhome 9.0-STABLE FreeBSD 9.0-STABLE #2: Fri May 11 20:41:54 PDT 2012 tomdean&lt; at &gt;P9X79.tddhome:/usr/src/sys/GENERIC amd64 Tom Dean _______________________________________________ freebsd-stable&lt; at &gt;freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscribe&lt; at &gt;freebsd.org" </pre> Thomas D. Dean 2012-05-24T22:13:31 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.os.freebsd.stable