Re: Phenom II 975 BE shows 0 celsius
on 02/08/2011 00:06 Jung-uk Kim said the following: > On Monday 01 August 2011 04:10 pm, Andriy Gapon wrote: >> on 01/08/2011 22:48 Jung-uk Kim said the following: >>> I have mixed feeling about this because I own a system with such >>> CPU/motherboard combo, too. I also believe it works well but >>> errata is errata. If vendor says we shouldn't use it, then we >>> shouldn't. In fact, I am just following Linux as an example here >>> but I have no problem with turning this into a warning message, >>> either. >> >> Let's cut a deal :-) >> If we start using amdtemp for fan control, emergency system >> shutdown or similar, then we follow the strict path. Until then, >> while we use amdtemp to amuse users with numbers, let's just print >> a warning :-) > > Okay, here is the new patch (not tested on the affected system yet): > > http://people.freebsd.org/~jkim/amdtemp2.diff Tested the patch - looks good! One comment though: it seems that sensor_offset defaults to zero now. Would it be a good idea to default it to what it previously used to be? On my system the hardware reports the offset correctly (as verified by using independent hardware monitoring logic in Super I/O), so defaulting it to zero is kind of a regression. -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Concurrent execution of rc-scripts with rcorder(8)
Hello, the idea to start services concurrently during boot isn't new and the question why FreeBSD doesn't do it has popped up on the forum and mailing list occasionally. So, why not give it a shot? rcorder(8) is normally used during boot to bring the rc-scripts into a particular order, so when they are executed linearly by /etc/rc, all constraints will be satisfied. I modified rcorder(8) to enable it to run rc-scripts concurrently, while keeping track of the constraints as rc-scripts start and finish. You can find the code at https://github.com/kil/rcorder. As it works now, it will fall back to the current mode of execution if anything goes wrong. So, if worst comes to worst, booting takes a bit longer. If you feel brave, give it a try (Actually, not too much bravery is needed: on all boots of my machine it worked perfectly every time.) I haven't done any measurements yet on how large the speedup is, but booting feels a bit faster with it. Also, there probably is room for improvement. Any ideas and feedback are very welcome! -kilian ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Concurrent execution of rc-scripts with rcorder(8)
> I haven't done any measurements yet on how large the speedup is, but booting > feels a bit faster with it. FWIW, my laptop's boot time (from pressing "power" to seeing login prompt) is reduced from 44s to 37s (out of which, first 20-25s are kernel booting). ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Concurrent execution of rc-scripts with rcorder(8)
Here is another approach: https://github.com/buganini/rcexecr -- Buganini ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Concurrent execution of rc-scripts with rcorder(8)
*** Sorry, emailed from wrong address and it bounced from hackers ***: I might suggest moving this to rc@. I'll try it later, looks interesting. Chris ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Concurrent execution of rc-scripts with rcorder(8)
2011/8/21 kilian : > Hello, > > the idea to start services concurrently during boot isn't new and the > question why FreeBSD doesn't do it has popped up on the forum and > mailing list occasionally. So, why not give it a shot? > > rcorder(8) is normally used during boot to bring the rc-scripts into a > particular order, so when they are executed linearly by /etc/rc, all > constraints will be satisfied. I modified rcorder(8) to enable it to > run rc-scripts concurrently, while keeping track of the constraints as > rc-scripts start and finish. You can find the code at > https://github.com/kil/rcorder. As it works now, it will fall back to the > current mode of execution if anything goes wrong. So, if worst comes to > worst, booting takes a bit longer. > > If you feel brave, give it a try (Actually, not too much bravery is needed: > on all boots of my machine it worked perfectly every time.) > > I haven't done any measurements yet on how large the speedup is, but booting > feels a bit faster with it. Also, there probably is room for improvement. > Any ideas and feedback are very welcome! There is another implementation which had been posted here (maybe) some times ago. Maybe a good thing to compare. https://github.com/buganini/rcexecr Joris > > -kilian > ___ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org" > ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Concurrent execution of rc-scripts with rcorder(8)
On Sun, Aug 21, 2011 at 04:18:10PM +0200, joris dedieu wrote: > 2011/8/21 kilian : > > Hello, > > > > the idea to start services concurrently during boot isn't new and the > > question why FreeBSD doesn't do it has popped up on the forum and > > mailing list occasionally. So, why not give it a shot? > > > > rcorder(8) is normally used during boot to bring the rc-scripts into a > > particular order, so when they are executed linearly by /etc/rc, all > > constraints will be satisfied. I modified rcorder(8) to enable it to > > run rc-scripts concurrently, while keeping track of the constraints as > > rc-scripts start and finish. You can find the code at > > https://github.com/kil/rcorder. As it works now, it will fall back to the > > current mode of execution if anything goes wrong. So, if worst comes to > > worst, booting takes a bit longer. > > > > If you feel brave, give it a try (Actually, not too much bravery is needed: > > on all boots of my machine it worked perfectly every time.) > > > > I haven't done any measurements yet on how large the speedup is, but booting > > feels a bit faster with it. Also, there probably is room for improvement. > > Any ideas and feedback are very welcome! > > There is another implementation which had been posted here (maybe) > some times ago. Maybe a good thing to compare. > > https://github.com/buganini/rcexecr Didn't know someone else already implemented this. I had a (quick) look at the source code and tried it out, too. Seems to do its job quite well. I'm (obviously) biased in my opinion but what might be considered a drawback of the rcexecr implementation is that it requires modifications to some files in /etc/rc.d. The modifications to /etc/rc are also more invasive. rcexecr is a whole new program, based on rcorder. My implementation requires changes only to /etc/rc and adds features to rcorder (preserving compatibility, I might add). - kilian > > Joris > > > > -kilian > > ___ > > freebsd-hackers@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > > To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org" > > > ___ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org" > ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: [nvi-iconv]Call for test
A new patch is uploaded. https://github.com/downloads/lichray/nvi2/nvi2-freebsd-2011-08-21.diff.gz There is no functional change in this patch. I just wrote a cmake script and regenerated config.h and pathnames.h; I also removed usr.bin/vi/port.h, so please make sure you applied the patch with patch -p0 -E < /path/to/nvi2-freebsd-2011-08-21.diff If usr.bin/vi/port.h still exists, just rm it; and if you see a usr.bin/vi/config.h.rej, you can get a clean copy with wget --no-check-certificate 'https://socsvn.freebsd.org/socsvn/soc2011/zy/nvi-iconv/head/usr.bin/vi/config.h' And replace usr.bin/vi/config.h with the one you downloaded. After the src tree is patched, please issue a make WITH_ICONV=1 depend first under usr.bin/vi/ if you just want to test nvi instead of to rebuild the world. For the new config.h, the FreeBSD-only SYSV_CURSES macro is removed, since we only have ncurses in -stable and -current. And the SYS5_TTY is enabled, since we support it in -stable and -current. On Thu, Aug 18, 2011 at 10:15 PM, Zhihao Yuan wrote: > On Thu, Aug 18, 2011 at 9:26 PM, Test Rat wrote: >> timp writes: >> >>> Hi! >>> I just tried you patch on latest current with clang. >>> >>> [root@current64 /usr/src]# uname -a >>> FreeBSD current64 9.0-BETA1 FreeBSD 9.0-BETA1 #0: Thu Aug 18 03:56:45 MSK >>> 2011 mox@current64:/usr/obj/usr/src/sys/GENERIC amd64 >>> >>> [root@current64 /usr/src]# patch < ~/nvi2-freebsd-2011-08-17.diff >> [...] >>> ===> usr.bin/vi (depend) >>> make: don't know how to make cl_bsd.c. Stop >>> *** Error code 2 >> >> Use `-p0' otherwise new directories won't be created. This is documented >> in patch(1). And cl_bsd.c ended up in current directory (/usr/src) >> >> $ diffstat ~/nvi2-freebsd-2011-08-17.diff.gz | fgrep cl_bsd.c >> contrib/nvi2/cl/cl_bsd.c | 346 +++ > > zzz... I always use -p0 but I did not know what it does... > >> >> Zhihao Yuan writes: >>> The patch will create contrib/nvi2, and it will not remove the unused >>> contrib/nvi (patch(1) can not really remove files anyway). >> >> patch(1) can remove *empty* files with `-E', e.g. >> >> $ svn rm UPDATING >> $ svn di UPDATING | patch -E -d /usr/src > > Got it. But removing contrib/nvi with patch will just double the patch > size anyway. A svn rm will do it if some day the patch got committed. > >> ___ >> freebsd-hackers@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers >> To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org" >> > > > > -- > Zhihao Yuan, nickname lichray > The best way to predict the future is to invent it. > ___ > 4BSD -- http://4bsd.biz/ > -- Zhihao Yuan, nickname lichray The best way to predict the future is to invent it. ___ 4BSD -- http://4bsd.biz/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Concurrent execution of rc-scripts with rcorder(8)
On Sun, Aug 21, 2011 at 04:14:02PM +0300, Vitaly Magerya wrote: > > I haven't done any measurements yet on how large the speedup is, but booting > > feels a bit faster with it. > > FWIW, my laptop's boot time (from pressing "power" to seeing login > prompt) is reduced from 44s to 37s (out of which, first 20-25s are > kernel booting). Thats about the same speedup I'm seeing. Also, today I found a bug in the /etc/rc patch that caused too many scripts to be run. I doubt it has a large impact but it maybe worth a try. > ___ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org" > ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
