Re: sys/conf/newvers.sh vs. subversion-1.7
On 10/27/2011 12:05, Craig Rodrigues wrote: > On Tue, Oct 25, 2011 at 1:07 PM, Doug Barton wrote: >> The attached implements that, and is almost certainly the right way to >> go. It would be nice if someone could test it, and better if someone >> else could commit it. I swore after the last time that I'd stay away >> from that file precisely because of all the bikeshed stupidity that this >> issue creates. > > Hi, > > I tested your patch and it works. I am attaching vers.c files which I > generated in trees which were under svn control, and not under svn control. Thanks for testing the non-svn case. I just committed the patch. -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: sys/conf/newvers.sh vs. subversion-1.7
On 10/25/2011 14:45, Craig Rodrigues wrote: > On Tue, Oct 25, 2011 at 1:54 PM, Doug Barton >> Actually hex would still work since 0x would match. :) > > Yes, but if in the future, a revision number format is ever chosen > that doesn't include > 0x at the beginning, and is something like: > a23728ea7d592acc69b36875a482cdf3fd5c8d > > then this check would fail. However, none of this > exists yet in SVN, so it is not worth worry about > right now. Yes, that was what the smiley at the end of my sentence above was intending to convey. Sorry I wasn't more clear. :) Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: sys/conf/newvers.sh vs. subversion-1.7
On 10/25/2011 13:23, Craig Rodrigues wrote:
> On Tue, Oct 25, 2011 at 1:07 PM, Doug Barton wrote:
>>
>> I didn't "disagree" with you. I pointed out that there is absolutely no
>> reason to run 2 separate commands. To put it more bluntly, I pointed out
>> why your suggestion is a bad idea.
>
> Hmmm, sounds like a disagreement to me.
"Disagreement" implies that you and I both have equally valid ideas, and
that we cannot agree on which one to use.
> I have read your concerns, but I don't fully
> understand why invoking "svn info ${SRCDIR}/sys",
> ignoring the output of "svn info", and then just
> checking its return status is a bad idea.
As I tried to explain previously, running one command, testing the
outcome, and then running another command if the first succeeded is a
bad idea if you can simply run the command you need to run in the first
place and parse *its* output. Obviously running 'svn info' first isn't
overwhelmingly expensive, so this isn't the most horrible idea ever
suggested for FreeBSD. However as a general principle we should be
trying to do the best we can, not only for its own sake, but as an
example to those who read and copy the code.
BTW, the rest of my analysis in my previous post is relevant here too.
If a bare 'svnversion' took a long time to return in a non-svn directory
then obviously we'd have to give your solution a better look. However,
given that it returns nearly instantaneously, there's no point.
> Using "svnversion" further down in the script
> if "svn info" succeeds is all that I was recommending.
Yes, I understood what you were suggesting. :)
> Anyways, I am fine with the patch which you propose.
Awesome!
> The only possible issue could be in future,
> if svn switches from using decimal revision numbers
> to numbers which are in hexadecimal, base64, etc.
>
> However, that is not currently the case, and if
> it does happen in future, we can change the script
> accordingly.
Actually hex would still work since 0x would match. :)
In any case I just tested the svn case, and it worked. If someone else
could test the non-svn case then we can get this fixed and move on.
Doug
--
Nothin' ever doesn't change, but nothin' changes much.
-- OK Go
Breadth of IT experience, and depth of knowledge in the DNS.
Yours for the right price. :) http://SupersetSolutions.com/
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: sys/conf/newvers.sh vs. subversion-1.7
On 10/25/2011 12:43, Craig Rodrigues wrote:
> I know that Doug disagreed with me on this,
I didn't "disagree" with you. I pointed out that there is absolutely no
reason to run 2 separate commands. To put it more bluntly, I pointed out
why your suggestion is a bad idea.
I'm sorry to be so blunt but I'm getting really tired of people who
can't let go of bad ideas even when it's demonstrated conclusively why
they are bad. :)
> The alternative would be to run ${dir}/svnversion, and check the output
> of that command, making sure that the output starts with a number.
The attached implements that, and is almost certainly the right way to
go. It would be nice if someone could test it, and better if someone
else could commit it. I swore after the last time that I'd stay away
from that file precisely because of all the bikeshed stupidity that this
issue creates.
Doug
--
Nothin' ever doesn't change, but nothin' changes much.
-- OK Go
Breadth of IT experience, and depth of knowledge in the DNS.
Yours for the right price. :) http://SupersetSolutions.com/
Index: newvers.sh
===
--- newvers.sh (revision 226474)
+++ newvers.sh (working copy)
@@ -88,7 +88,7 @@
i=`${MAKE:-make} -V KERN_IDENT`
for dir in /bin /usr/bin /usr/local/bin; do
- if [ -d "${SYSDIR}/.svn" -a -x "${dir}/svnversion" ] ; then
+ if [ -x "${dir}/svnversion" ] ; then
svnversion=${dir}/svnversion
break
fi
@@ -99,8 +99,12 @@
done
if [ -n "$svnversion" ] ; then
-echo "$svnversion"
- svn=" r`cd ${SYSDIR} && $svnversion`"
+ echo "$svnversion"
+ svn=`cd ${SYSDIR} && $svnversion`
+ case "$svn" in
+ [0-9]*) svn=" r${svn}" ;;
+ *) unset svn ;;
+ esac
fi
if [ -n "$git_cmd" ] ; then
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: sys/conf/newvers.sh vs. subversion-1.7
On 10/24/2011 10:14, Craig Rodrigues wrote: > On Fri, Oct 21, 2011 at 10:47 PM, Doug Barton wrote: >> On 10/21/2011 22:42, Craig Rodrigues wrote: >>> Hi, >>> >>> I tried following: >>> >>> (1) Run svnversion in non-svn directory: >>> >>>return status == 0 >> >> Return status isn't everything. :) >> >>>prints out "exported" >> >> In my case (1.7) it says "Unversioned directory" >> >> But my point (which perhaps I should have made more explicit) is that >> given the fact that svnversion handles non-svn directories gracefully >> it's faster (simpler, etc.) to just run foo=`svnversion` and then make >> sure that $foo is rational than it is to run 2 commands. >> >> Doug > > > Hi, > > What logic can we use to make sure svnversion returns a rational value? Make sure that the response starts with a number. > It looks like the output of svnversion for non-svn directories is > inconsistent between versions of Subversion. The non-svn responses vary, the svn responses don't. :) -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: sys/conf/newvers.sh vs. subversion-1.7
On 10/22/2011 12:07, Boris Samorodov wrote:
> 22.10.2011 22:12, Doug Barton пишет:
>> On 10/22/2011 08:29, Garrett Cooper wrote:
>>> $(svn info | awk '/^Revision:/ {print $2}')
>>
>> 2 subshells and a pipe for this, vs. only 1 subshell for just running
>> svnversion.
>>
>> Anyone else want to propose a more complex solution when a simple and
>> more effective one already exists? :)
>
> I'm not an exert here, so I'm not sure which one and why did you call
> "simple and more effective":
Please read the rest of this thread, where the fact that svnversion does
more than what 'svn info' does, and that people find the more that it
does to be useful.
So "simpler" is "one command, not 2 or more," and "more effective" is
"provides more information, and people find that extra information
useful." :)
hth,
Doug
--
Nothin' ever doesn't change, but nothin' changes much.
-- OK Go
Breadth of IT experience, and depth of knowledge in the DNS.
Yours for the right price. :) http://SupersetSolutions.com/
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: sys/conf/newvers.sh vs. subversion-1.7
On 10/22/2011 08:29, Garrett Cooper wrote:
> $(svn info | awk '/^Revision:/ {print $2}')
2 subshells and a pipe for this, vs. only 1 subshell for just running
svnversion.
Anyone else want to propose a more complex solution when a simple and
more effective one already exists? :)
--
Nothin' ever doesn't change, but nothin' changes much.
-- OK Go
Breadth of IT experience, and depth of knowledge in the DNS.
Yours for the right price. :) http://SupersetSolutions.com/
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: sys/conf/newvers.sh vs. subversion-1.7
On 10/21/2011 22:42, Craig Rodrigues wrote: > Hi, > > I tried following: > > (1) Run svnversion in non-svn directory: > >return status == 0 Return status isn't everything. :) >prints out "exported" In my case (1.7) it says "Unversioned directory" But my point (which perhaps I should have made more explicit) is that given the fact that svnversion handles non-svn directories gracefully it's faster (simpler, etc.) to just run foo=`svnversion` and then make sure that $foo is rational than it is to run 2 commands. Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: IPv6 accept_rtadv + bfe0
On 10/19/2011 00:29, Hiroki Sato wrote: > Mattia Rossi wrote > in <4e9dfe11.2070...@swin.edu.au>: > > mr> So the _ipv6 bit doesn't take care of passing "inet6" to ifconfig > mr> automatically? > > No. You always need to add the inet6 keyword wherever needed. That seems redundant, and contrary to how the IPv4 equivalents work. And obviously it's confusing to users. From what I can see looking at some 7.x and 8.x systems it also seems to be a POLA violation. Perhaps this is something that you should reconsider? Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: sys/conf/newvers.sh vs. subversion-1.7
On 10/21/2011 17:51, Craig Rodrigues wrote: > Can you come up with a patch which invoke "svn info ." (if the svn > binary exists)? > This is slightly faster than svnversion. > > If "svn info ." doesn't error out, you can assume that the directory > is under SVN control. Doesn't svnversion error out pretty quickly in the same circumstance? My brief testing seems to indicate that it does. -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: 9.0-beta3 preferring ipv4 over ipv6 with ipv6_activate_all_interfaces="YES"
On 10/14/2011 10:38, Hajimu UMEMOTO wrote: > AFAIK, recent Firefox implements Happy Eyeballs. So, I suspect it > doesn't obey RFC 3484, anymore. My understanding is that they added it, then turned it off because it didn't work as expected. -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Fixed: ichwd failure to attach
On 10/14/2011 12:03, Xin LI wrote: >> Hmm, is your isab device behind a PCI-PCI bridge? Me either: isab0: at device 31.0 on pci0 isa0: on isab0 -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Fixed: ichwd failure to attach
On 10/14/2011 10:35, Xin LI wrote: > On 10/14/11 04:35, John Baldwin wrote: >> On Thursday, October 13, 2011 6:26:26 pm Doug Barton wrote: >>> On 10/12/2011 08:20, Michael Butler wrote: >>>> SVN r226302 solves the ichwd failure to attach issue .. >>> >>> Still failing for me: >>> >>> ichwd0: on isa0 >>> ichwd0: unable to reserve GCS registers >>> device_attach: ichwd0 attach returned 6 > >> Yes, it can only fix it if the BIOS decides to list it as a system resource >> in >> ACPI. However, using 'debug.acpi.disabled=hostres' should still be working >> as >> a workaround for lying BIOSes yes? As I reported previously, that didn't work for me. I'll try it again next time I reboot JIC. FYI, I also have a Dell system, Optiplex 960. > I do have debug.acpi.disabled=hostres but it doesn't seem help in my > case (Dell Latitude D630): > > ichwd0: on isa0 > ichwd0: unable to reserve GCS registers > device_attach: ichwd0 attach returned 6 > ichwd0: at port 0x1030-0x1037,0x1060-0x107f > on isa0 > ichwd0: unable to reserve GCS registers > device_attach: ichwd0 attach returned 6 > > Is there something I should look at or additional information needed? > > Cheers, > -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Fixed: ichwd failure to attach
On 10/12/2011 08:20, Michael Butler wrote: > SVN r226302 solves the ichwd failure to attach issue .. Still failing for me: ichwd0: on isa0 ichwd0: unable to reserve GCS registers device_attach: ichwd0 attach returned 6 r226340, smp, amd64 -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: FreeBSD 9.0-BETA3 Available...
On 10/12/2011 06:47, Ken Smith wrote: > On Wed, 2011-10-12 at 14:39 +0100, Bruce Cran wrote: >> On 29/09/2011 02:42, Ken Smith wrote: >>> MD5 (FreeBSD-9.0-BETA3-amd64-bootonly.iso) = >>> 2ce7b93d28fd7ff37965893f1af3f7fc >>> MD5 (FreeBSD-9.0-BETA3-amd64-dvd1.iso) = 4affc701f2052edc548274f090e49235 >>> MD5 (FreeBSD-9.0-BETA3-amd64-memstick.img) = >>> e260f2f2122326cb9a93ac83eb006c1c >> >> The -dvd1.iso files seem to be less than a CD, at 610MB. Are they >> expected to contain more data over time, or could 'dvd' be removed? >> > > I was planning on them having package sets. The new installer doesn't > support installing packages like sysinstall had but if I provide Gnome, > KDE, and perhaps a small set of other stuff it would be useful to people > with crummy network connectivity. They could install the packages from > the DVD instead of needing to have everything downloaded. Is there still going to be a CD-sized installer? I find this really useful both at home, and also for virtualized installs. -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: cvs commit: ports/security/cyrus-sasl2 Makefile ports/security/cyrus-sasl2/files patch-plugins::gssapi.c
On 10/09/2011 09:29, Hajimu UMEMOTO wrote: > Hi, > >>>>>> On Fri, 07 Oct 2011 16:48:52 -0700 >>>>>> Doug Barton said: > > dougb> In case anyone wants to take this on, this port fails to install on > 10.0 > dougb> because it uses its own version of libtool. I took a quick look but > dougb> there wasn't a solution obvious enough for me. :) > > I didn't have 10-current box, yet. So, I've just upgraded my > 9-current box to today's current, and tried to rebuild cyrus-sasl2 > port on it. However, I couldn't reproduce the problem. It built just > fine, here. Any thought? So I was able to confirm that the patch which had previously been in /usr/share/mk/bsd.port.mk was what caused it to fail. Hopefully that information will be helpful to those working on improving the generic fix. Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Patch for ports on 10-current
On 10/10/2011 15:00, Nali Toja wrote:
> Doug Barton writes:
>
>> Until the pointy-haireds come up with a better solution, here is a patch
>> that incorporates work that others have done into a manageable form so
>> that those interested in working with ports on 10-current have some
>> tools to work with:
>>
>> http://dougbarton.us/bam.patch
> [...]
>> +.if ${OSVERSION} >= 100 && !defined(NO_LIBTOOL_FIXED)
>
> The issue does not lie in OSVERSION but in OSREL. So, why not be smarter
> and detect if a user has UNAME_r workaround in environment
Because by doing it the way I did it the user can apply both fixes, or
either fix individually by using the right combination of knobs.
--
Nothin' ever doesn't change, but nothin' changes much.
-- OK Go
Breadth of IT experience, and depth of knowledge in the DNS.
Yours for the right price. :) http://SupersetSolutions.com/
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Patch for ports on 10-current
Until the pointy-haireds come up with a better solution, here is a patch that incorporates work that others have done into a manageable form so that those interested in working with ports on 10-current have some tools to work with: http://dougbarton.us/bam.patch You need to do the equivalent of 'portmaster -o devel/libtool-fixed libtool' to get the fixed version. In addition to the OSVERSION check I added knobs to selectively disable the 2 parts of the fix to aid in development and testing. Also, make sure that you have the latest /usr/share/mk/bsd.port.mk with the similar fix backed out. Hopefully there will be a better fix soon, but until there is, I hope that this helps. Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: flash for 9-beta3
On 10/08/2011 14:53, Warren Block wrote: > nspluginwrapper needs to be run as the end user. The pkg-message tells them to do that. -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: cvs commit: ports/security/cyrus-sasl2 Makefile ports/security/cyrus-sasl2/files patch-plugins::gssapi.c
In case anyone wants to take this on, this port fails to install on 10.0 because it uses its own version of libtool. I took a quick look but there wasn't a solution obvious enough for me. :) Doug On 10/07/2011 09:15, Hajimu UMEMOTO wrote: > ume 2011-10-07 16:15:47 UTC > > FreeBSD ports repository > > Modified files: > security/cyrus-sasl2 Makefile > Added files: > security/cyrus-sasl2/files patch-plugins::gssapi.c > Log: > Fix GSSAPI client crash, NULL ptr dereference. > > Submitted by: Phil Pennock > Obtained from: > http://lists.andrew.cmu.edu/pipermail/cyrus-sasl/2011-October/002358.html > > Revision ChangesPath > 1.148 +1 -1 ports/security/cyrus-sasl2/Makefile > 1.5 +22 -0 > ports/security/cyrus-sasl2/files/patch-plugins::gssapi.c (new) > > http://www.FreeBSD.org/cgi/cvsweb.cgi/ports/security/cyrus-sasl2/Makefile.diff?&r1=1.147&r2=1.148&f=h > http://www.FreeBSD.org/cgi/cvsweb.cgi/ports/security/cyrus-sasl2/files/patch-plugins::gssapi.c > -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: subversion-freebsd dependencies
On 10/06/2011 12:58, Lev Serebryakov wrote: > Hello, Doug. > You wrote 6 октября 2011 г., 23:37:26: > >>> On a newly installed development machine I installed subversion-freebsd >>> from ports and ended up with a huge dependency chain. >> If you're just using it for FreeBSD you can un-check all the OPTIONS. If >> you might want to use the http:// protocol to check something out the >> neon option works well and is fairly painless. > > It doesn't help to remove tcl build dependency, as sqlite3 is > unconditional dependency :( 'portmaster --packages-build' does help with that stuff though, possibly with --delete-build-only if you're tight on space. Doug PS, I just noticed that this is on the wrong list ... freebsd-ports@ would be more appropriate. -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: subversion-freebsd dependencies
On 10/06/2011 03:34, Andre Oppermann wrote: > > On a newly installed development machine I installed subversion-freebsd > from ports and ended up with a huge dependency chain. If you're just using it for FreeBSD you can un-check all the OPTIONS. If you might want to use the http:// protocol to check something out the neon option works well and is fairly painless. hth, Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: cvsup broken on amd64?
On 10/06/2011 01:41, Thomas Mueller wrote: > Anyway, from what I read, csup is better, and I think I can use the same > supfile and same server that I would use for cvsup? Yes. -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: portsnap5 problem, portsnap error handling
On 10/04/2011 03:32, Andriy Gapon wrote: > Not sure which list would be best for this Given that it's a ports issue, freebsd-ports@ comes to mind ... -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HEADS UP: ports/ and 10.0-CURRENT
On 09/28/2011 13:45, Beech Rintoul wrote: > On Wednesday 28 September 2011 12:18:47 Doug Barton wrote: >> On 09/28/2011 12:39, Hartmann, O. wrote: >>> The mess started to happen when I tried to "repair" a non CLANG >>> compiling port math/gotoblas with portmaster -vf amth/gotoblas. >>> Since this build binutils and even gettext and libiconv, I guess they >>> got broken. Last I saw was a successful installation report from >>> portmaster. But the libiconv.so.3 wasn't there anymore when I checked! >>> >>> This is a catastrophy ... >>> >>> I'm on FreeBSD 10.0-CURRENT r225844 >> >> It's been widely reported on the ports list that you can't do fresh >> ports compiles on 10-current, and won't be able to until well after >> 9.0-RELEASE. The primary reason is that auto* stuff doesn't understand >> the 2-digit release version. >> >> Solutions are to set UNAME_r=9.0-CURRENT in your environment, and/or >> twiddle the version in newvers.sh and rebuild/reinstall your kernel. >> >> >> hth, >> >> Doug > > So if I change /usr/src/sys/conf/newvers.sh to something like vers 9.9 I'm > not > going to shoot myself in the foot if I try and update? I would really like to > avoid downgrading this box.I've altready been bitten once today and had to > build packages on my tindy and force install. That should be the case, yes. I haven't tested it yet myself. If you do, and it works, let us know and I'll write the UPDATING entry if no one else does. -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HEADS UP: ports/ and 10.0-CURRENT
On 09/28/2011 12:39, Hartmann, O. wrote: > The mess started to happen when I tried to "repair" a non CLANG > compiling port math/gotoblas with portmaster -vf amth/gotoblas. > Since this build binutils and even gettext and libiconv, I guess they > got broken. Last I saw was a successful installation report from > portmaster. But the libiconv.so.3 wasn't there anymore when I checked! > > This is a catastrophy ... > > I'm on FreeBSD 10.0-CURRENT r225844 It's been widely reported on the ports list that you can't do fresh ports compiles on 10-current, and won't be able to until well after 9.0-RELEASE. The primary reason is that auto* stuff doesn't understand the 2-digit release version. Solutions are to set UNAME_r=9.0-CURRENT in your environment, and/or twiddle the version in newvers.sh and rebuild/reinstall your kernel. hth, Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Experiences with FreeBSD 9.0-BETA2
On 09/27/2011 14:24, Peter Jeremy wrote: > On 2011-Sep-26 21:29:18 -0700, Kevin Oberman wrote: >> MBR allows 4 slices (which Windows and most of the world call >> partitions). Windows also >> allows the creation of "Extended Partitions, but FreeBSD does not >> support these. They result >> in device named with an 's' for slice. E.g. "da0s1". > > To be pedantic, the FreeBSD bootcode does not support _booting_ off > extended partitions. Once it is booted, FreeBSD has no problems > accessing them. Correct. > (I don't know if alternative bootcode such as grub > can boot FreeBSD within an extended partition). Well the installer won't even look there, so you'd have to do a fair bit of gymnastics to even get it there in the first place. And given the difficulty that grub sometimes has with booting it from primary partitions I wouldn't be hopeful, even if the FreeBSD late-stage boot loader could do it, which I highly doubt. -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: bin/160979: 9.0 burncd error caused by change to cd0 from acd0
On 09/26/2011 18:43, Craig Rodrigues wrote: > On Mon, Sep 26, 2011 at 6:28 PM, Doug Barton wrote: >>> burncd has been part of the system utilities included in the basic >>> release since release 4.0 and cdrecord is a port. The professional >>> solution is to remove burncd from the 9.0 system release and add the >>> cdrecord command to the basic release as the replacement for burncd. >>> Then add release notes entry of the change. >> >> I think you misunderstand the situation. So here are a few hopefully >> helpful facts: >> >> 1. The fact that something is in the base, or in the ports, has >> absolutely no bearing on whether one piece of software is fundamentally >> more useful or valuable than another. > > > Hi, > > I have used burncd on many releases of FreeBSD, on many machines > without problem. I can see the fact that burncd suddenly failing to > work on ATAPI hardware could annoy and confused end-users. It doesn't fail to work on ATAPI hardware. It fails to work on cd0 which is a SCSI device. The fact that it's emulated doesn't matter. > Can we modify burncd to somehow detect if ATAPI-CAM is enabled, and print out > a more useful error message? Sure, as soon as someone volunteers to create that patch. No one is *trying* to annoy users, but things change around here because people are interested in changing them. hth, Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: bin/160979: 9.0 burncd error caused by change to cd0 from acd0
On 09/26/2011 17:59, Fbsd8 wrote: > Your solution is very un-professional. Good thing we're all volunteers. :) > What your solution purposes to do > is do nothing. I think your judgment is flawed and a larger group of > your peers need to review your judgment in this case. Ok, done. Eitan is right. > burncd has been part of the system utilities included in the basic > release since release 4.0 and cdrecord is a port. The professional > solution is to remove burncd from the 9.0 system release and add the > cdrecord command to the basic release as the replacement for burncd. > Then add release notes entry of the change. I think you misunderstand the situation. So here are a few hopefully helpful facts: 1. The fact that something is in the base, or in the ports, has absolutely no bearing on whether one piece of software is fundamentally more useful or valuable than another. 2. burncd has only ever worked with a subset of the legacy ATA hardware. 3. ATA-CAM is on by default in FreeBSD 9 (which means that rather than acd0 as an ATA device you'll have cd0 as a SCSI device). 4. However, ATA-CAM is not mandatory, which means that leaving burncd in the base for those that want to continue using the legacy ATA interface is a perfectly reasonable course of action. 5. For those that wish to use the default ATA-CAM interface the cdrecord port provides a mature, full-featured solution. Even if it were possible to import it into the base, doing so would be a step in the wrong direction. > You do not knowingly leave a non-working utility in the system, period, That makes sense, however see above. > or not provide a included replacement for a popular utility as this one. The alternative already exists. The fact that it's not in the base has no relevance. I hope this clears up your confusion. If you have any further questions please direct them to freebsd-questi...@freebsd.org only. Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: FreeBSD 9-Beta3 on X300 problems.
On 09/26/2011 16:02, crsnet.pl wrote: > >> 2. Kadu/Gnu Gadu. >> I dont know why, but when i run kadu / gnu gadu and try to connect to >> Gadu-Gadu network software segments ;/ >> Kadu with signal 6, GnuGadu with signal 11. >> I try to use old gadulib, or recompie it. But this doesn't help ;/ > > I run portmaster -y --no-confirm --packages-if-newer -m 'BATCH=yes' -d -a The -y option is meaningless in that context, FYI. > And... its works;) I'm glad to hear that at least. :) -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Experiences with FreeBSD 9.0-BETA2
On 09/26/2011 15:38, Benjamin Kaduk wrote: > This perception that ZFS is most of the future probably contributed to > the lack of strong opinions regarding the default UFS partition scheme. Can we please stop saying that there were no contrary opinions stated? I personally expressed a preference (call it strong if that helps) for split partition scheme, as did several other people, all with worked examples. Nathan chose to go "one big partition" in spite of that input. Given that he was the one doing the work on the installer I personally decided to take a step back and see how it played out. But let's not pretend that this wasn't Nathan's decision. Meanwhile, if based on feedback from early adopters we need to tweak the layout, that's not life threatening. There is still time. Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Screwy behavior in ports framework
First, this should be on freebsd-po...@freebsd.org. If you still have problems later please start a new thread there. On 09/13/2011 02:45, Thomas Mueller wrote: > I quote my /etc/make.conf from BETA2: > WRKDIR=workb2 That's guaranteed to break things. What you want is to remove that and set: WRKDIRPREFIX= /full/path/to/valid/location Make sure you set the *full* path. hth, Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Unusually high LA without any load at FreeBSD9-BETA2
On 09/06/2011 10:05, Garrett Cooper wrote: > On Tue, Sep 6, 2011 at 9:30 AM, Alex Kozlov wrote: >> Hi, current >> >> I see an unusually high LA for more than 10 hours without slightest load. >> Any ideas? > > What is "LA"? Load Average. -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: LOR 9.0 beta1
On 8/23/2011 7:48 AM, Garrett Cooper wrote: > On Tue, Aug 23, 2011 at 4:29 AM, Holger Kipp wrote: >> Maybe already seen... >> This is within Parallels 6.0 VM on a Mac with OS 10.6.8 > > ... > > This is a well known LOR. There are a lot of well-known LORs in HEAD. This is a bug. They make witness basically useless, and cause users to waste a bunch of time reporting things that are already "well known." -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ichwd attach failure
John was working on this, haven't seen an update recently though. Doug On 08/26/2011 14:24, Mike Tancsa wrote: > Got a newish Intel board in and decided to give it a spin. Trying to > load the watchdog, I get this error below on CURRENT. Anyone able to > get ichwd working on such a motherboard ? full dmesg and devinfo at > > http://www.tancsa.com/intel.txt > and > http://www.tancsa.com/intel-asl.txt > > > > isab0: found ICH10 or equivalent chipset: Intel Cougar Point watchdog timer > ichwd0: on isa0 > isab0: found ICH10 or equivalent chipset: Intel Cougar Point watchdog timer > pcib0: allocated type 4 (0x430-0x437) for rid 0 of ichwd0 > pcib0: allocated type 4 (0x460-0x47f) for rid 1 of ichwd0 > ichwd0: unable to reserve GCS registers > device_attach: ichwd0 attach returned 6 > pcib0: allocated type 4 (0x3f0-0x3f5) for rid 0 of fdc0 > pcib0: allocated type 4 (0x3f7-0x3f7) for rid 1 of fdc0 > ppc0: cannot reserve I/O port range > pcib0: allocated type 4 (0x2f8-0x2ff) for rid 0 of uart1 > > -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: periodic weekly catman - perl problem
On 08/22/2011 09:41, Andrej Zverev wrote: > > > On Mon, Aug 22, 2011 at 11:59 AM, Doug Barton <mailto:do...@freebsd.org>> wrote: > > I have the catman option enabled for periodic/weekly and get the > following errors: > > Reformatting manual pages: > catman: /usr/local/lib/perl5/5.12.4/man/cat3: mkdir: Permission denied > catman: /usr/local/lib/perl5/5.12.4/perl/man/cat3: mkdir: Permission > denied > > > It seems that the cat3 directories are not created because the man > directories are owned by root, and the cat* directories are owned by > man, which is what the 330.catman script operates as. > > Creating those directories with the proper permissions allows the catman > periodic script to do its thing. So my question is, is this something > that the catman periodic script should be doing, or should the perl port > be doing it? > > Hello, Doug. I couldn't find which way is correct in this situation but > I can propose the following patch: > http://sunner.semmy.ru/~az/perl-man.txt if this solve issue when you can > knock-knock at skv's (perl maintainer) door. Thanks for looking at this, but you're solving the wrong problem. :) It's the cat* directories that need to be owned by man. Having thought about this more, I think it's the 330.catman script that needs to ensure that these directories exist, likely with 'install -d'. I'll try to get to it, but if someone else is quicker ... Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Well, there goes Windows!
On Mon, 22 Aug 2011 12:23:43 +0800 Adrian Chadd wrote: > However, an installer is user-facing (here), as well as system-facing. > As much as I understand the logic behind it, it is still going to > surprise people to find that their partition tables are modified at > any point before that final "commit". +1 -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
periodic weekly catman - perl problem
I have the catman option enabled for periodic/weekly and get the following errors: Reformatting manual pages: catman: /usr/local/lib/perl5/5.12.4/man/cat3: mkdir: Permission denied catman: /usr/local/lib/perl5/5.12.4/perl/man/cat3: mkdir: Permission denied It seems that the cat3 directories are not created because the man directories are owned by root, and the cat* directories are owned by man, which is what the 330.catman script operates as. Creating those directories with the proper permissions allows the catman periodic script to do its thing. So my question is, is this something that the catman periodic script should be doing, or should the perl port be doing it? Doug ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: nroff -mandoc | more no longer works
The proper way to do this atm is 'man ./foo.1'. I had the same set of commands under the fingers as well, but doing it the new way has many benefits. Not the least of which is that you will see the page the same way man will render it when it's installed. Doug (change is hard) On 8/14/2011 12:08 PM, Julian Elischer wrote: > I also use this line for testing man page edits. It will be a very sad > thing if it's been broken in 9.0. > > > On 8/14/11 8:29 AM, Robert Watson wrote: >> >> I'm guessing this relates to nroff/groff tweaks, but I was a bit >> unhappy to learn that the command I've used for the last decade to >> render man pages while editing them (nroff -mandoc foo.1 | more) no >> longer works (output below). >> >> It seems likely this has to do with teaching groff to use ANSI escape >> codes that more, by default, rejects. I'm aware there are lots of >> other command lines I could use, but it seems unfortunate that this is >> broken -- possibly more should accept more escape codes in its default >> configuration, or nroff should generate fewer of them? >> >> (I'd love to see this fixed for 9.0) >> >> Robert N M Watson >> Computer Laboratory >> University of Cambridge -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ghost files
On 08/06/2011 23:08, deeptec...@gmail.com wrote: > i'd note that the hard drive is kind of old (>7 years), and i recently > had the power cut during port build operations twice, although the > (UFS) filesystem is fsck-clean. Have you actually booted single user and run 'fsck -y'? That should probably be your next step. -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: New installation script
On 08/06/2011 07:52, Nathan Whitehorn wrote: > This is, to some extent, a deliberate design decision. The idea is that > if you are installing onto an existing partition with the right type, > then you really do just want to use it without newfs. Actually, if I am reinstalling I really do want to newfs the system partitions because that's how I can guarantee that no old cruft is left over. I generally do not want to newfs things like /home. I think my use case here is fairly typical. There should at minimum be an option to newfs the partitions one is installing the OS to. Ideally that option should default to whatever sysinstall does now (which IIRC is 'on'). Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: svn commit: r224659 - head/etc
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 08/05/2011 23:07, Ed Schouten wrote: > Hi Doug, > > * Doug Barton , 20110806 02:07: >> However, I would much rather see us actually change the default >> file. Users who are going to enable nis will already know that this >> file needs to be tweaked, and by using more sensible defaults we'll >> be more relevant to the majority of our userbase. So I propose the >> attached (along with reverting your change obviously). > > I'm fine either way. Feel free to commit it (after re approval). :-) Done, thanks. :) - -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (FreeBSD) iQEcBAEBCAAGBQJOPQrhAAoJEFzGhvEaGryESC0H/i90aqFTDOUduBD7zSterzC2 rUtgvj/7Pcw52jeROhn6lIutjhG4iZU1rtdSYn01y6mDppQ+Liwr7BBJQYki0u5d sPcTGZS8FfSOBTnbUq1YSTpmjQVONAA42dSYZ6pAZzlcwr0rQRbImDI7SgOkjwxR eRIY7ESMo42jq5nMnHTpgUOpp6V9nVtbJyZkQWHlOJopZLAiRmSGPYnl5qn7VUrG pKntJwK20H1mRwbf60yQNKzuoufZo4xMwhjZKLE109zkD/A8GsanM1Jyo6IZI7ZQ 8hWBjprUco3RnFIcPscK6ckAhH9zIuo86zEoqRmkqtelIhLHj/I9BGkCTTq22f8= =1nQA -END PGP SIGNATURE- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: svn commit: r224659 - head/etc
Ed,
First off, thanks for taking a look at this. I've always been
uncomfortable with our default nsswitch.conf file because most users do
not use nis, and although everything works with our (previous) default
it produces errors in the logs that are very non-obvious.
That said, I think the approach you have here needs some tweaking. You
only posted it to -current yesterday, and I hadn't even gotten past
thinking "Ok, that's a good direction to start looking" before it was
committed already. :) I know deadlines are tight prior to the release,
but I don't think they are _that_ tight.
I have 2 suggestions. The first is that if we go this way that we tweak
the sed statements to comment out the _compat entries rather than
deleting them. This will accomplish the same thing but be slightly less
confusing for users who eventually want to implement nis. This can be
accomplished like this:
-e 's/.*_compat:/# &/' -e 's/compat$/files/'
The other issue is that due to the way that mergemaster works by default
users who have existing /etc/nsswitch.conf files (which should be pretty
close to 100%) won't see this change because it doesn't affect the
$FreeBSD$ tag. If we decide to keep things this way then I would suggest
adding a comment to that file so that it will get picked up.
However, I would much rather see us actually change the default file.
Users who are going to enable nis will already know that this file needs
to be tweaked, and by using more sensible defaults we'll be more
relevant to the majority of our userbase. So I propose the attached
(along with reverting your change obviously).
hth,
Doug
On 08/05/2011 10:33, Ed Schouten wrote:
> Author: ed
> Date: Fri Aug 5 17:33:12 2011
> New Revision: 224659
> URL: http://svn.freebsd.org/changeset/base/224659
>
> Log:
> Remove NIS entries from /etc/nsswitch.conf for WITHOUT_NIS.
>
> We already modify various configuration files in /etc based on build
> configuration. This is not done for nsswitch.conf right now when setting
> WITHOUT_NIS. This breaks various utilities, including crond, that depend
> on working databases.
>
> Approved by:re (kib)
> MFC after: 1 month
>
> Modified:
> head/etc/Makefile
>
> Modified: head/etc/Makefile
> ==
> --- head/etc/Makefile Fri Aug 5 17:15:46 2011(r224658)
> +++ head/etc/Makefile Fri Aug 5 17:33:12 2011(r224659)
> @@ -256,6 +256,10 @@ distribution:
> ${DESTDIR}/boot/device.hints
> .endif
> .endif
> +.if ${MK_NIS} == "no"
> + sed -i "" -e '/_compat:/d' -e 's/compat/files/' \
> + ${DESTDIR}/etc/nsswitch.conf
> +.endif
>
> distrib-dirs:
> mtree -eU ${MTREE_FOLLOWS_SYMLINKS} -f ${.CURDIR}/mtree/BSD.root.dist
> -p ${DESTDIR}/
>
--
Nothin' ever doesn't change, but nothin' changes much.
-- OK Go
Breadth of IT experience, and depth of knowledge in the DNS.
Yours for the right price. :) http://SupersetSolutions.com/
#
# $FreeBSD: head/etc/nsswitch.conf 158266 2006-05-03 15:14:47Z ume $
#
# To enable NIS the commented entries should replace their uncommented
# equivalents. See nsswitch.conf(5) for more information.
#
group: files
#group_compat: nis
#group: compat
passwd: files
#passwd_compat: nis
#passwd: compat
services: files
#services_compat: nis
#services: compat
hosts: files dns
networks: files
shells: files
protocols: files
rpc: files
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: resolvconf script overwrites entries in resolv.conf - RDNSS/DNSSL related
On 08/04/2011 22:59, Mattia Rossi wrote: > Hi all, > > I've finally patched my 8.2 IPv6 gateway with the RDNSS/DNSSL patches > and I'm distributing DNS servers that way now. Works fine, my box > running CURRENT picks up the DNS servers and search domains and writes > them into /etc/resolv.conf using the resolvconf script. > > The script anyhow overwrites my previous manual entries in > /etc/resolv.conf which I need for my manual IPv4 setup... > > I think it's an easily fixable bug - haven't looked into it that close > atm., but given that the resolvconf script is going to be > rewritten/enhanced anyways, that's something to keep in mind. > I think that manual entries should always be preferred. Check 'man resolvconf.conf' for information on name_servers_append. It would probably be nice if there was a _prepend equivalent. -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ichwd0: unable to reserve GCS registers
On 08/02/2011 15:06, John Baldwin wrote:
> On Saturday, July 30, 2011 2:49:52 am Andriy Gapon wrote:
>> on 19/07/2011 18:16 John Baldwin said the following:
>>> Hmm, can you get devinfo -r output from a working kernel with ichwd loaded?
>>>
>>> You might be able to just build the kernel with 'nooptions NEW_PCIB'.
>>
>> I believe that I've got a similar problem with amdsbwd(4).
>> It needs some resources (I/O ports) that belong to ACPI.
>> The problem is that the driver attaches to isa bus which is under
>> isab->pci->pcib and those particular resources are not assigned to the
>> Host-PCI
>> bridge.
>>
>> I think that you already made a suggestion that perhaps isa bus should
>> directly
>> attach to acpi bus when acpi is available. Not sure if there are any
>> alternative approaches.
>
> Can you try this:
Not so much. :) the first and last patches I can apply to HEAD by hand,
but /sys/dev/acpica/acpi_pcib_acpi.c is only 387 lines long, so I'm not
even sure where to start.
Any chance you could diff against HEAD?
Doug
> --- //depot/projects/pci/sys/dev/acpica/acpi.c2011-06-25
> 12:05:19.0
> +++ //depot/projects/pci/sys/dev/acpica/acpi.c2011-08-02
> 20:21:42.0
> @@ -1238,7 +1238,6 @@
> struct resource_list_entry *rle;
> struct resource_list *rl;
> struct resource *res;
> -struct rman *rm;
> int isdefault = (start == 0UL && end == ~0UL);
>
> /*
> @@ -1291,15 +1290,29 @@
> } else
> res = BUS_ALLOC_RESOURCE(device_get_parent(bus), child, type, rid,
> start, end, count, flags);
> -if (res != NULL || start + count - 1 != end)
> - return (res);
>
> /*
> * If the first attempt failed and this is an allocation of a
> * specific range, try to satisfy the request via a suballocation
> - * from our system resource regions. Note that we only handle
> - * memory and I/O port system resources.
> + * from our system resource regions.
> */
> +if (res == NULL && start + count - 1 == end)
> + res = acpi_alloc_sysres(child, type, rid, start, end, count, flags);
> +return (res);
> +}
> +
> +/*
> + * Attempt to allocate a specific resource range from the system
> + * resource ranges. Note that we only handle memory and I/O port
> + * system resources.
> + */
> +struct resource *
> +acpi_alloc_sysres(device_t child, int type, int *rid, u_long start, u_long
> end,
> +u_long count, u_int flags)
> +{
> +struct rman *rm;
> +struct resource *res;
> +
> switch (type) {
> case SYS_RES_IOPORT:
> rm = &acpi_rman_io;
> @@ -1311,6 +1324,7 @@
> return (NULL);
> }
>
> +KASSERT(start + count - 1 == end, ("wildcard resource range"));
> res = rman_reserve_resource(rm, start, end, count, flags & ~RF_ACTIVE,
> child);
> if (res == NULL)
> --- //depot/projects/pci/sys/dev/acpica/acpi_pcib_acpi.c 2011-07-22
> 18:19:55.0
> +++ //depot/projects/pci/sys/dev/acpica/acpi_pcib_acpi.c 2011-08-02
> 20:21:42.0
> @@ -541,6 +541,7 @@
> {
> #ifdef NEW_PCIB
> struct acpi_hpcib_softc *sc;
> +struct resource *res;
> #endif
>
> #if defined(__i386__) || defined(__amd64__)
> @@ -549,8 +550,11 @@
>
> #ifdef NEW_PCIB
> sc = device_get_softc(dev);
> -return (pcib_host_res_alloc(&sc->ap_host_res, child, type, rid, start,
> end,
> - count, flags));
> +res = pcib_host_res_alloc(&sc->ap_host_res, child, type, rid, start, end,
> + count, flags);
> +if (res == NULL && start + count - 1 == end)
> + res = acpi_alloc_sysres(child, type, rid, start, end, count, flags);
> +return (res);
> #else
> return (bus_generic_alloc_resource(dev, child, type, rid, start, end,
> count, flags));
> --- //depot/projects/pci/sys/dev/acpica/acpivar.h 2011-06-22
> 16:25:39.0
> +++ //depot/projects/pci/sys/dev/acpica/acpivar.h 2011-08-02
> 20:21:42.0
> @@ -382,6 +382,8 @@
> struct resource *res, ACPI_RESOURCE *acpi_res);
> ACPI_STATUS acpi_parse_resources(device_t dev, ACPI_HANDLE handle,
> struct acpi_parse_resource_set *set, void *arg);
> +struct resource *acpi_alloc_sysres(device_t child, int type, int *rid,
> + u_long start, u_long end, u_long count, u_int flags);
>
> /* ACPI event handling */
> UINT32 acpi_event_power_button_sleep(void *context);
>
--
Nothin' ever doesn't change, but nothin' changes much.
-- OK Go
Breadth of IT experience, and depth of knowledge in the DNS.
Yours for the right price. :) http://SupersetSolutions.com/
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ichwd0: unable to reserve GCS registers
On 07/30/2011 19:35, John Baldwin wrote: > On 7/30/11 7:55 PM, Doug Barton wrote: >> On 07/30/2011 05:34, John Baldwin wrote: >>> On Saturday, July 30, 2011 02:49:52 AM Andriy Gapon wrote: >>>> on 19/07/2011 18:16 John Baldwin said the following: >>>>> Hmm, can you get devinfo -r output from a working kernel with ichwd >>>>> loaded? You might be able to just build the kernel with 'nooptions >>>>> NEW_PCIB'. >> >> So is this still relevant? I'm sorry I haven't had a chance to get this >> done, but I may be able to this weekend if you still think it's useful. > > No, I was able to get that info from someone else with the same issue. Awesome. Let me know if there is anything else I can not do to help. :) -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ichwd0: unable to reserve GCS registers
On 07/30/2011 05:34, John Baldwin wrote: > On Saturday, July 30, 2011 02:49:52 AM Andriy Gapon wrote: >> on 19/07/2011 18:16 John Baldwin said the following: >>> Hmm, can you get devinfo -r output from a working kernel with ichwd >>> loaded? You might be able to just build the kernel with 'nooptions >>> NEW_PCIB'. So is this still relevant? I'm sorry I haven't had a chance to get this done, but I may be able to this weekend if you still think it's useful. Doug >> I believe that I've got a similar problem with amdsbwd(4). >> It needs some resources (I/O ports) that belong to ACPI. >> The problem is that the driver attaches to isa bus which is under >> isab->pci->pcib and those particular resources are not assigned to the >> Host-PCI bridge. >> >> I think that you already made a suggestion that perhaps isa bus should >> directly attach to acpi bus when acpi is available. Not sure if there are >> any alternative approaches. > > Actually, my suggestion was the other way around (we should move certain ACPI > devices down behind isab so they are behind the Host-PCI bridge as they are > in > hardware). In this case the BIOS clearly does not list the reosurces for the > GCS as valid resources for the Host-PCI bridge. This is part of the reason > that I added the 'debug.acpi.disable="hostres"'. One thing we may be able to > do is allow non-wildcard requests that are outside the range to still pass if > they are in ACPI's system resource range perhaps. > -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ichwd0: unable to reserve GCS registers
On 07/18/2011 10:08, John Baldwin wrote: > On Monday, July 18, 2011 4:26:49 am Doug Barton wrote: >> I'm getting this with recent HEAD: >> >> isab0: found ICH7 or equivalent chipset: Intel ICH7M watchdog timer >> ichwd0: at port 0x1030-0x1037,0x1060-0x107f >> on isa0 >> isab0: found ICH7 or equivalent chipset: Intel ICH7M watchdog timer >> pcib0: allocated type 4 (0x1030-0x1037) for rid 0 of ichwd0 >> pcib0: allocated type 4 (0x1060-0x107f) for rid 1 of ichwd0 >> ichwd0: unable to reserve GCS registers >> device_attach: ichwd0 attach returned 6 >> pcib0: allocated type 4 (0x2f8-0x2ff) for rid 0 of uart1 > > Can you get devinfo -r output while booting with > 'debug.acpi.disabled=hostres'? I escaped to the loader prompt and type 'set debug..' and then booted. The devinfo output is attached. Doing the kldload with debug.bootverbose I now get this: isab0: found ICH7 or equivalent chipset: Intel ICH7M watchdog timer ichwd0: detached ichwd0 failed to probe at port 0x1030-0x1037,0x1060-0x107f on isa0 isab0: found ICH7 or equivalent chipset: Intel ICH7M watchdog timer ichwd0: at port 0x1030-0x1037,0x1060-0x107f on isa0 isab0: found ICH7 or equivalent chipset: Intel ICH7M watchdog timer ichwd0: Intel ICH7M watchdog timer (ICH7 or equivalent) ichwd0: timer disabled ichwd0: timer enabled ichwd0: timeout set to 28 ticks ichwd0: timer reloaded (repeats infinitely) Thanks, Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ nexus0 apic0 ram0 I/O memory addresses: 0x0-0x9efff 0x10-0x7fe813ff acpi0 Interrupt request lines: 9 I/O ports: 0x20-0x21 0x2e-0x2f 0x4e-0x4f 0x86 0x92 0xa0-0xa1 0xb2 0xb3 0x4d0-0x4d1 0x809 0x910-0x91f 0x920-0x92f 0x930-0x97f 0xc80-0xcaf 0xcbc-0xcbf 0xcc0-0xcff 0x1000-0x1005 0x1006-0x1007 0x1008-0x1059 0x1060-0x107f 0x1080-0x10bf 0x10c0-0x10df 0xf400-0xf4fe I/O memory addresses: 0x9fc00-0x9 0xc-0xc 0xe-0xf 0x7fe81400-0x7fef 0x7ff0-0x7fff 0xf000-0xf3ff 0xf400-0xf4003fff 0xf4004000-0xf4004fff 0xf4005000-0xf4005fff 0xf4006000-0xf4006fff 0xf4008000-0xf400bfff 0xfec0-0xfec0 0xfed2-0xfed3 0xfed45000-0xfed9 0xfee0-0xfee0 0xffa8-0xffa83fff 0xffb0-0x cpu0 ACPI I/O ports: 0x1014 0x1016 acpi_perf0 est0 cpufreq0 coretemp0 cpu1 ACPI I/O ports: 0x1014 0x1016 acpi_perf1 est1 cpufreq1 coretemp1 acpi_acad0 battery0 battery1 acpi_lid0 acpi_button0 acpi_button1 acpi_sysresource0 pcib0 pci0 hostb0 pcib1 I/O memory addresses: 0xd000-0xdfff 0xed00-0xefef pci1 vgapci0 Interrupt request lines: 16 pcib1 memory window: 0xed00-0xedff 0xee00-0xeeff pcib1 prefetch window: 0xd000-0xdfff vgapm0 nvidia0 hdac0 Interrupt request lines: 256 I/O memory addresses: 0xefffc000-0xefff pcm0 pcib2 pci11 pcib3 I/O memory addresses: 0xecf0-0xecff pci12 wpi0 Interrupt request lines: 17 pcib3 memory window: 0xecfff000-0xecff pcib4 I/O memory addresses: 0xece0-0xecef pci9 uhci0 Interrupt request lines: 20 I/O ports: 0xbf80-0xbf9f usbus0 uhub0 uhci1 Interrupt request lines: 21 I/O ports: 0xbf60-0xbf7f usbus1 uhub1 uhci2 Interrupt request lines: 22 I/O ports: 0xbf40-0xbf5f usbus2 uhub2 ums0 uhci3 Interrupt request lines: 23 I/O ports:
Re: sys/boot/i386/boot2 build failure with clang
On 07/18/2011 13:11, Dimitry Andric wrote: > On 2011-07-18 09:42, Doug Barton wrote: > .. >> A clean /usr/obj got me all the way through buildworld to the point >> where it was building the 32-bit compat libs, and got this: > ... >> /tmp/.root/cc-ysEysz.s:31589: Error: unknown pseudo-op: `.cfi_sections' >> clang: error: assembler command failed with exit code 1 (use -v to see > > This should now really be fixed with r224201. Can you please confirm? :) Confirmed! Thanks. :) -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
ichwd0: unable to reserve GCS registers
I'm getting this with recent HEAD: isab0: found ICH7 or equivalent chipset: Intel ICH7M watchdog timer ichwd0: at port 0x1030-0x1037,0x1060-0x107f on isa0 isab0: found ICH7 or equivalent chipset: Intel ICH7M watchdog timer pcib0: allocated type 4 (0x1030-0x1037) for rid 0 of ichwd0 pcib0: allocated type 4 (0x1060-0x107f) for rid 1 of ichwd0 ichwd0: unable to reserve GCS registers device_attach: ichwd0 attach returned 6 pcib0: allocated type 4 (0x2f8-0x2ff) for rid 0 of uart1 -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: sys/boot/i386/boot2 build failure with clang
On 07/17/2011 07:03, Dimitry Andric wrote: > In any case, I have committed a fix in r224131, let me know how that > works out for you. A clean /usr/obj got me all the way through buildworld to the point where it was building the 32-bit compat libs, and got this: clang -m32 -march=i686 -mmmx -msse -msse2 -mfancy-math-387 -DCOMPAT_32BIT -isystem /usr/obj/home/svn/head/lib32/usr/include/ -L/usr/obj/home/svn/head/lib32/usr/lib32 -B/usr/obj/home/svn/head/lib32/usr/lib32 -O2 -pipe -g -I/home/svn/head/lib/libc/include -I/home/svn/head/lib/libc/../../include -I/home/svn/head/lib/libc/i386 -DNLS -D__DBINTERFACE_PRIVATE -I/home/svn/head/lib/libc/../../contrib/gdtoa -DINET6 -I/usr/local/obj/lib32/home/svn/head/lib/libc -I/home/svn/head/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE -no-integrated-as -I/home/svn/head/lib/libc/../../contrib/tzcode/stdtime -I/home/svn/head/lib/libc/stdtime -I/home/svn/head/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/home/svn/head/lib/libc/rpc -DNS_CACHING -DSYMBOL_VERSIONING -g -std=gnu99 -fstack-protector -Wsystem-headers -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /home/svn/head/lib/libc/stdlib/malloc.c clang: warning: argument unused during compilation: '-mfancy-math-387' clang: warning: argument unused during compilation: '-L/usr/obj/home/svn/head/lib32/usr/lib32' /tmp/.root/cc-ysEysz.s: Assembler messages: /tmp/.root/cc-ysEysz.s:31589: Error: unknown pseudo-op: `.cfi_sections' clang: error: assembler command failed with exit code 1 (use -v to see invocation) *** Error code 1 Thanks, Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: sys/boot/i386/boot2 build failure with clang
I have DEBUG_FLAGS+= -g in my /etc/make.conf. Commenting that out allows this to work. Doug On 07/17/2011 03:11, Doug Barton wrote: > Howdy, > > Trying to build r224125 with clang, and got this (using no -j): > > ===> boot2 (all) > objcopy -S -O binary boot1.out boot1 > dd if=/dev/zero of=boot2.ldr bs=512 count=1 > 1+0 records in > 1+0 records out > 512 bytes transferred in 0.40 secs (12782641 bytes/sec) > clang -Os -fno-guess-branch-probability -fomit-frame-pointer > -fno-unit-at-a-time -mno-align-long-strings -mrtd -mregparm=3 > -DUSE_XREAD -DUFS1_AND_UFS2 -DFLAGS=0x80 -DSIOPRT=0x3f8 -DSIOFMT=0x3 > -DSIOSPD=9600 -I/home/svn/head/sys/boot/i386/boot2/../../common > -I/home/svn/head/sys/boot/i386/boot2/../btx/lib -I. -Wall > -Waggregate-return -Wbad-function-cast -Wcast-align > -Wmissing-declarations -Wmissing-prototypes -Wnested-externs > -Wpointer-arith -Wshadow -Wstrict-prototypes -Wwrite-strings -Winline > --param max-inline-insns-single=100 -mllvm -stack-alignment=8 -mllvm > -inline-threshold=3 -mllvm -enable-load-pre=false -ffreestanding > -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 > -mno-sse3 -msoft-float -m32 -march=i386 -g -std=gnu99 -S -o > boot2.s.tmp /home/svn/head/sys/boot/i386/boot2/boot2.c > clang: warning: the clang compiler does not support '-fno-unit-at-a-time' > clang: warning: argument unused during compilation: > '-fno-guess-branch-probability' > clang: warning: argument unused during compilation: > '-mno-align-long-strings' > clang: warning: argument unused during compilation: '--param > max-inline-insns-single=100' > clang: warning: argument unused during compilation: > '-mpreferred-stack-boundary=2' > In file included from /home/svn/head/sys/boot/i386/boot2/boot2.c:172: > /home/svn/head/sys/boot/i386/boot2/../../common/ufsread.c:232:17: > warning: cast > from 'char *' to 'struct ufs1_dinode *' increases required > alignment from > 1 to 4 [-Wcast-align] > memcpy(&dp1, (struct ufs1_dinode *)blkbuf + n, > ^~~~ > /home/svn/head/sys/boot/i386/boot2/../../common/ufsread.c:235:17: > warning: cast > from 'char *' to 'struct ufs2_dinode *' increases required > alignment from > 1 to 4 [-Wcast-align] > memcpy(&dp2, (struct ufs2_dinode *)blkbuf + n, > ^~~~ > /home/svn/head/sys/boot/i386/boot2/boot2.c:224:1: warning: no previous > prototype > for function 'main' [-Wmissing-prototypes] > main(void) > ^ > /home/svn/head/sys/boot/i386/boot2/boot2.c:352:4: warning: cast from > 'caddr_t' > (aka 'char *') to 'Elf32_Word *' (aka 'unsigned int *') increases > required > alignment from 1 to 4 [-Wcast-align] > *(Elf32_Word *)p = es[i].sh_size; > ^~~ > /home/svn/head/sys/boot/i386/boot2/boot2.c:611:8: warning: cast from > 'caddr_t' > (aka 'char *') to 'uint32_t *' (aka 'unsigned int *') increases > required > alignment from 1 to 4 [-Wcast-align] > t1 = *(uint32_t *)PTOV(0x46c); > ^~~ > 5 warnings generated. > sed -e '/align/d' -e '/nop/d' < boot2.s.tmp > boot2.s > rm -f boot2.s.tmp > as --32 -o boot2.o boot2.s > boot2.s: Assembler messages: > boot2.s:4073: Error: unknown pseudo-op: `.cfi_sections' > *** Error code 1 > > > > -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
sys/boot/i386/boot2 build failure with clang
Howdy, Trying to build r224125 with clang, and got this (using no -j): ===> boot2 (all) objcopy -S -O binary boot1.out boot1 dd if=/dev/zero of=boot2.ldr bs=512 count=1 1+0 records in 1+0 records out 512 bytes transferred in 0.40 secs (12782641 bytes/sec) clang -Os -fno-guess-branch-probability -fomit-frame-pointer -fno-unit-at-a-time -mno-align-long-strings -mrtd -mregparm=3 -DUSE_XREAD -DUFS1_AND_UFS2 -DFLAGS=0x80 -DSIOPRT=0x3f8 -DSIOFMT=0x3 -DSIOSPD=9600 -I/home/svn/head/sys/boot/i386/boot2/../../common -I/home/svn/head/sys/boot/i386/boot2/../btx/lib -I. -Wall -Waggregate-return -Wbad-function-cast -Wcast-align -Wmissing-declarations -Wmissing-prototypes -Wnested-externs -Wpointer-arith -Wshadow -Wstrict-prototypes -Wwrite-strings -Winline --param max-inline-insns-single=100 -mllvm -stack-alignment=8 -mllvm -inline-threshold=3 -mllvm -enable-load-pre=false -ffreestanding -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -msoft-float -m32 -march=i386 -g -std=gnu99 -S -o boot2.s.tmp /home/svn/head/sys/boot/i386/boot2/boot2.c clang: warning: the clang compiler does not support '-fno-unit-at-a-time' clang: warning: argument unused during compilation: '-fno-guess-branch-probability' clang: warning: argument unused during compilation: '-mno-align-long-strings' clang: warning: argument unused during compilation: '--param max-inline-insns-single=100' clang: warning: argument unused during compilation: '-mpreferred-stack-boundary=2' In file included from /home/svn/head/sys/boot/i386/boot2/boot2.c:172: /home/svn/head/sys/boot/i386/boot2/../../common/ufsread.c:232:17: warning: cast from 'char *' to 'struct ufs1_dinode *' increases required alignment from 1 to 4 [-Wcast-align] memcpy(&dp1, (struct ufs1_dinode *)blkbuf + n, ^~~~ /home/svn/head/sys/boot/i386/boot2/../../common/ufsread.c:235:17: warning: cast from 'char *' to 'struct ufs2_dinode *' increases required alignment from 1 to 4 [-Wcast-align] memcpy(&dp2, (struct ufs2_dinode *)blkbuf + n, ^~~~ /home/svn/head/sys/boot/i386/boot2/boot2.c:224:1: warning: no previous prototype for function 'main' [-Wmissing-prototypes] main(void) ^ /home/svn/head/sys/boot/i386/boot2/boot2.c:352:4: warning: cast from 'caddr_t' (aka 'char *') to 'Elf32_Word *' (aka 'unsigned int *') increases required alignment from 1 to 4 [-Wcast-align] *(Elf32_Word *)p = es[i].sh_size; ^~~ /home/svn/head/sys/boot/i386/boot2/boot2.c:611:8: warning: cast from 'caddr_t' (aka 'char *') to 'uint32_t *' (aka 'unsigned int *') increases required alignment from 1 to 4 [-Wcast-align] t1 = *(uint32_t *)PTOV(0x46c); ^~~ 5 warnings generated. sed -e '/align/d' -e '/nop/d' < boot2.s.tmp > boot2.s rm -f boot2.s.tmp as --32 -o boot2.o boot2.s boot2.s: Assembler messages: boot2.s:4073: Error: unknown pseudo-op: `.cfi_sections' *** Error code 1 -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: named crashes on assertion in rbtdb.c on sparc64/SMP
On 07/15/2011 01:40, Marius Strobl wrote: > The generated config.h and platform.h for sparc64 are these: > http://people.freebsd.org/~marius/bind96_config.h > http://people.freebsd.org/~marius/bind96_platform.h Marius, Thanks again for all your help on this. During the work to upgrade to BIND 9.8 in HEAD I first tried your patch but I got some odd errors on some of the non-mainstream archs, so I ultimately went with something similar to what you sent but much more conservative. Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
HEADS UP: BIND 9.8 imported to HEAD
Howdy, I wanted to let everyone know that BIND 9.8.0-P4 has just been imported to 9-current, and will be part of the 9.0-RELEASE. The 9.8 branch has many nice new features vs. 9.6.x, especially in the area of DNSSEC. You can read more about the new features in the README file included in /usr/share/doc/bind9. I also encourage you to browse through the ARM, either in HTML or PDF format as there are other interesting features for both authoritative and resolving name servers. The good news is that zone files and server configurations that work with BIND 9.6.x should work without modification in 9.8.x so migration should be painless. If you have any problems or questions feel free to follow up here on -current. Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: named crashes on assertion in rbtdb.c on sparc64/SMP
On 07/14/2011 16:21, Marius Strobl wrote: > On Thu, Jul 14, 2011 at 09:53:42AM +0400, KOT MATPOCKuH wrote: >> 2011/7/11 KOT MATPOCKuH : Oops, sorry, I forgot to revert the previous patch when test-compiling. Please re-fetch sparc64_isc_atomic.h.diff2 and try again. >>> I started named from ports (dns/bind96) at Sat Jul ?9 10:08:41 MSD, >>> and it worked properly till Sun Jul 10 22:25:41 MSD. >>> At 22:25:41 I restarted bind from base system with your >>> sparc64_isc_atomic.h.diff2. >>> From this moment till today, 15:57:05 he crashed 3 times: >>> Jul 10 23:19:19 sunrise kernel: pid 45352 (named), uid 53: exited on signal >>> 6 >>> Jul 11 14:52:20 sunrise kernel: pid 52032 (named), uid 53: exited on signal >>> 6 >>> Jul 11 15:14:15 sunrise kernel: pid 71300 (named), uid 53: exited on signal >>> 6 >>> >>> To make to ensure proper operation of bind from ports, I ran it again >>> at 15:57:05, and, I think, we need to wait several days. >> And from that time till now bind from ports never died and works properly... >> > > Okay. > Doug, could you please disable the use of atomic operations for sparc64 > in the in-tree BIND via the following patch in order to match what the > vendor source does? > http://people.freebsd.org/~marius/sparc64_isc_disable_atomic.diff If you use the port and do 'make configure' are the values in config.h the same as the ones in your patch? If so, that's likely to be the right answer, and I'll go ahead and apply your patch. Thanks, Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: cardbus panic: end address is not aligned
On 07/14/2011 12:55, Doug Barton wrote: > On 07/14/2011 11:39, John Baldwin wrote: >> On Thursday, July 14, 2011 6:27:20 am Adrian Chadd wrote: >>>> Don't forget if_ath_pci. >> Which I think is a bug for this very reason if it turns out to be the cause. > > I have > > MODULES_OVERRIDE=ath ... > > in src.conf and I have an if_ath module, but no if_ath_pci module. There > is no directory in /sys/modules for either, and no Makefile in > /sys/dev/ath. Looking in GENERIC it seems I'm going to need ath_hal as > well? Do _pci and _hal need to be compiled into the kernel > unconditionally in order to use if_ath? Or am I missing something? Adrian set me straight on /sys/modules/ath[_pci] being the proper places to build the modules, and with if_ath_pci kldload'ed the cards are recognized. There is a minor issue with one of the cards but I have some other things to poke before I am sure it's FreeBSD at fault this time. So it's likely this issue is closed. Thanks again John and Adrian for your help. Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: cardbus panic: end address is not aligned
On 07/14/2011 11:39, John Baldwin wrote: > On Thursday, July 14, 2011 6:27:20 am Adrian Chadd wrote: >> > Don't forget if_ath_pci. > Which I think is a bug for this very reason if it turns out to be the cause. I have MODULES_OVERRIDE=ath ... in src.conf and I have an if_ath module, but no if_ath_pci module. There is no directory in /sys/modules for either, and no Makefile in /sys/dev/ath. Looking in GENERIC it seems I'm going to need ath_hal as well? Do _pci and _hal need to be compiled into the kernel unconditionally in order to use if_ath? Or am I missing something? Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: cardbus panic: end address is not aligned
On 07/12/2011 07:22, John Baldwin wrote: > On Monday, July 11, 2011 9:29:19 pm Doug Barton wrote: >> On 07/08/2011 06:19, John Baldwin wrote: >> >>> Hmm, well that's odd. It didn't grow it enough it seems. >>> >>>>> Also, can you boot your machine, then do 'sysctl debug.bootverbose=1', >>>>> insert >>>>> the card and record the messages in dmesg when it does? (You can likely >>>>> get >>>>> those out of kgdb.) >> >> I tried your patch, and got some odd results. The good news is, no >> crash. However it did not actually enable the cards, with or without >> if_ath being loaded before inserting them. Here is the dmesg output with >> debug.bootverbose=1. This is with inserting and removing first one card, >> then the other. > > Hmm, can you try without NEW_PCIB just as a test? (You'll need to add > 'nooption NEW_PCIB' to your kernel config file.) No change. Still no panic, but the cards were not recognized with or without if_ath loaded in advance. -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: cardbus panic: end address is not aligned
On 07/12/2011 07:22, John Baldwin wrote: > On Monday, July 11, 2011 9:29:19 pm Doug Barton wrote: >> On 07/08/2011 06:19, John Baldwin wrote: >> >>> Hmm, well that's odd. It didn't grow it enough it seems. >>> >>>>> Also, can you boot your machine, then do 'sysctl debug.bootverbose=1', >>>>> insert >>>>> the card and record the messages in dmesg when it does? (You can likely >>>>> get >>>>> those out of kgdb.) >> >> I tried your patch, and got some odd results. The good news is, no >> crash. However it did not actually enable the cards, with or without >> if_ath being loaded before inserting them. Here is the dmesg output with >> debug.bootverbose=1. This is with inserting and removing first one card, >> then the other. > > Hmm, can you try without NEW_PCIB just as a test? (You'll need to add > 'nooption NEW_PCIB' to your kernel config file.) Yes, but not any sooner than this evening. I see you committed the patch you sent me, so I'll update my srcs to the latest HEAD, add the option you suggested, and rebuild ASAP. Thanks again, Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: cardbus panic: end address is not aligned
On 07/08/2011 06:19, John Baldwin wrote: > Hmm, well that's odd. It didn't grow it enough it seems. > >>> Also, can you boot your machine, then do 'sysctl debug.bootverbose=1', >>> insert >>> the card and record the messages in dmesg when it does? (You can likely >>> get >>> those out of kgdb.) I tried your patch, and got some odd results. The good news is, no crash. However it did not actually enable the cards, with or without if_ath being loaded before inserting them. Here is the dmesg output with debug.bootverbose=1. This is with inserting and removing first one card, then the other. pcib5: attempting to grow memory window for (0x8800-0x,0x1) back candidate range: 0x8800-0x8800 pcib5: grew memory window to 0x8000-0x880f pcib5: allocated memory range (0x8800-0x8800) for rid 10 of pci0:4:0:0 found-> vendor=0x168c, dev=0x0023, revid=0x01 domain=0, bus=4, slot=0, func=0 class=02-80-00, hdrtype=0x00, mfdev=0 cmdreg=0x, statreg=0x02b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=18 cardbus0: at device 0.0 (no driver attached) map[10]: type Memory, range 32, base 0, size 16, memory disabled pcib5: allocated memory range (0x8800-0x8800) for rid 10 of pci0:4:0:0 found-> vendor=0x168c, dev=0x0023, revid=0x01 domain=0, bus=4, slot=0, func=0 class=02-80-00, hdrtype=0x00, mfdev=0 cmdreg=0x, statreg=0x02b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=18 cardbus0: at device 0.0 (no driver attached) pcib5: allocated memory range (0x8800-0x8800) for rid 10 of pci0:4:0:0 unknown: Lazy allocation of 0x1 bytes rid 0x10 type 3 at 0x8800 cbb0: Opening memory: cbb0: Normal: 0x8800-0x8800 cbb0: Opening memory: cbb0: Opening memory: cbb0: Normal: 0x8800-0x8800 cbb0: Opening memory: found-> vendor=0x168c, dev=0x0013, revid=0x01 domain=0, bus=4, slot=0, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0002, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x0a (2500 ns), maxlat=0x1c (7000 ns) intpin=a, irq=18 powerspec 2 supports D0 D3 current D0 cardbus0: at device 0.0 (no driver attached) pci0:4:0:0: Transition from D0 to D3 > The real messages I will want to see are in the dmesg. Also, getting the > output of 'devinfo -r' before you insert the card would also be helpful so > I can see what it is growing from. Attached. Thanks for looking into this, Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ nexus0 apic0 ram0 I/O memory addresses: 0x0-0x9efff 0x10-0x7fe813ff acpi0 Interrupt request lines: 9 I/O ports: 0x20-0x21 0x2e-0x2f 0x4e-0x4f 0x86 0x92 0xa0-0xa1 0xb2 0xb3 0x4d0-0x4d1 0x809 0x910-0x91f 0x920-0x92f 0x930-0x97f 0xc80-0xcaf 0xcbc-0xcbf 0xcc0-0xcff 0x1000-0x1005 0x1006-0x1007 0x1008-0x1059 0x1060-0x107f 0x1080-0x10bf 0x10c0-0x10df 0xf400-0xf4fe I/O memory addresses: 0x9fc00-0x9 0xc-0xc 0xe-0xf 0x7fe81400-0x7fef 0x7ff0-0x7fff 0xf000-0xf3ff 0xf400-0xf4003fff 0xf4004000-0xf4004fff 0xf4005000-0xf4005fff 0xf4006000-0xf4006fff 0xf4008000-0xf400bfff 0xfec0-0xfec0 0xfed2-0xfed3 0xfed45000-0xfed9 0xfee0-0xfee0 0xffa8-0xffa83fff 0xffb0-0x cpu0 ACPI I/O ports: 0x1014 0x1016 est0 acpi_perf0 cpufreq0 coretemp0 cpu1 ACPI I/O ports: 0x1014 0x1016 est1 acpi_perf1 cpufreq1 coretemp1 acpi_acad0 battery0 battery1 acpi_lid0 acpi_button0 acpi_button1 acpi_sysresource0 pcib0 pci0 hostb0 pcib1 I/O memory addresses: 0xd000-0xdfff 0xed00-0xefef pci1 vgapci0 Interrupt request lines: 16 pcib1 memory window: 0xed00-0xedff 0xee00-0xeeff pcib1 prefetch window: 0xd000-0xdfff vgapm0 nvidia0 hdac0
Re: cardbus panic: end address is not aligned
On 07/07/2011 14:20, John Baldwin wrote:
> On Sunday, July 03, 2011 1:39:18 am Doug Barton wrote:
>> I have 2 ath-based pc-card adapters. If I put either one of them in the
>> slot while the system is up, or if I try booting with them in the slot,
>> I get an instant panic. The cards previously worked in -current, and
>> continue to work in 8-stable and windows xp. I don't have any other
>> pc-cards to compare with. Full core.txt.0 file is in my home directory
>> on freefall.
>>
>> This problem persists on r223732 but happened to me for the first time a
>> week or 2 ago (haven't had time to report it previously, apologies). It
>> likely originated a while before though, I don't use these cards very
>> often.
>>
>> panic: end address is not aligned
>>
>> #1 0x80426a8a in kern_reboot (howto=260)
>> at /home/svn/head/sys/kern/kern_shutdown.c:430
>> #2 0x80426521 in panic (fmt=Variable "fmt" is not available.
>> )
>> at /home/svn/head/sys/kern/kern_shutdown.c:604
>> #3 0x8032c648 in pcib_grow_window (sc=0xfe0002603400,
>> w=0xfe0002603498, type=3, start=0, end=4294967295, count=65536,
>> flags=Variable "flags" is not available.
>
> The line is here:
>
> KASSERT((w->limit & ((1ul << w->step) - 1)) == (1ul << w->step) - 1,
> ("end address is not aligned"));
>
> Can you run kgdb and do 'frame 3' and 'p/x *w'?
(kgdb) frame 3
#3 0x8032c648 in pcib_grow_window (sc=0xfe0002603400,
w=0xfe0002603498, type=3, start=0, end=4294967295, count=65536,
flags=Variable "flags" is not available.
)
at /home/svn/head/sys/dev/pci/pci_pci.c:1018
1018KASSERT((w->limit & ((1ul << w->step) - 1)) == (1ul << w->step)
- 1,
(kgdb) p/x *w
$1 = {base = 0x8000, limit = 0x8800, rman = {rm_list = {
tqh_first = 0xfe0002702a00, tqh_last = 0xfe0002702a98},
rm_mtx = 0xfe00024e20e0, rm_link = {tqe_next = 0xfe0002603520,
tqe_prev = 0xfe0002603448}, rm_start = 0x0, rm_end = 0x,
rm_type = 0x2, rm_descr = 0xfe0002608060}, res =
0xfe0002702b00,
reg = 0x20, valid = 0x1, mask = 0x2, step = 0x14, name =
0x8071b77c}
> Also, can you boot your machine, then do 'sysctl debug.bootverbose=1', insert
> the card and record the messages in dmesg when it does? (You can likely get
> those out of kgdb.)
The system panics instantly when I insert the cards. Would a verbose
dmesg entry from 8.2-stable work? I can do that on the same hardware.
If not I can try it on -current and see if anything gets logged.
Thanks for taking a look!
Doug
--
Nothin' ever doesn't change, but nothin' changes much.
-- OK Go
Breadth of IT experience, and depth of knowledge in the DNS.
Yours for the right price. :) http://SupersetSolutions.com/
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: named crashes on assertion in rbtdb.c o? sparc64/SMP
On 06/28/2011 08:58, Marius Strobl wrote: Uhm, we once fixed a problem in the MD atomic implementation which still seems to present in the ISC copy. Could you please test whether the following patch makes a difference? http://people.freebsd.org/~marius/sparc64_isc_atomic.h.diff I haven't seen any verification from the OP that this patch solved the problem, however it did pass 'make universe' on both 9-current and RELENG_8, so I've committed it to those 2 branches along with the recent update. I'll also submit it upstream. Thanks, Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: My problems with stability on -current
On 05/11/2011 04:33, Alexander Motin wrote:
On 11.05.2011 08:17, Doug Barton wrote:
I had an interesting result doing nothing but switching from HPET to
LAPIC ... no crash. Still on the same version of -current (r221566) the
only thing I've done is to add kern.eventtimer.timer="LAPIC" to
/boot/loader.conf, and so far I haven't been able to get it to crash no
matter how much I compile, or how much other stuff I do in the
background. I _can_ get the system heavily loaded enough so that the
mouse can drag across the screen, windows take visible time to repaint,
etc. That happens with a load average of 4+ on this core 2 duo. But
other than that (which is not altogether unreasonable) the system has
been very stable for a couple of days now.
Does that suggest a next step in terms of what to test?
The fact that LAPIC is working fine can mean that problem is either HPET
specific or non-per-CPU timers specific. To check that you could try to
use i8254 timer in one-shot mode:
hint.attimer.0.timecounter=0
kern.eventtimer.timer="i8254"
, or use HPET in per-CPU mode:
hint.atrtc.0.clock=0
hint.attimer.0.clock=0
hint.hpet.X.legacy_route=1
But the most informative would be to see what's going on with HPET
interrupts during the freezes. With HPET hardware it is very easy to
loose interrupt. And the lost interrupt means problem for many things.
There are some workarounds made for that, but I can't be sure. For that
case you could experiment with this patch:
--- acpi_hpet.c.prev 2010-12-25 11:28:45.0 +0200
+++ acpi_hpet.c 2011-05-11 14:30:59.0 +0300
@@ -190,7 +190,7 @@ restart:
bus_write_4(sc->mem_res, HPET_TIMER_COMPARATOR(t->num),
t->next);
}
- if (fdiv < 5000) {
+ if (1 || fdiv < 5000) {
bus_read_4(sc->mem_res, HPET_TIMER_COMPARATOR(t->num));
now = bus_read_4(sc->mem_res, HPET_MAIN_COUNTER);
FYI, I have been running this patch since you sent it, and haven't
crashed under high load since.
--
Nothin' ever doesn't change, but nothin' changes much.
-- OK Go
Breadth of IT experience, and depth of knowledge in the DNS.
Yours for the right price. :) http://SupersetSolutions.com/
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: cardbus panic: end address is not aligned
On 07/03/2011 03:05, Adrian Chadd wrote: The obvious question - can you bisect kernel versions to find out when it broke? Sorry, I thought the answer to that was obvious from my message. I have no idea how far back the breakage goes since I don't use the cards often. Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
cardbus panic: end address is not aligned
I have 2 ath-based pc-card adapters. If I put either one of them in the slot while the system is up, or if I try booting with them in the slot, I get an instant panic. The cards previously worked in -current, and continue to work in 8-stable and windows xp. I don't have any other pc-cards to compare with. Full core.txt.0 file is in my home directory on freefall. This problem persists on r223732 but happened to me for the first time a week or 2 ago (haven't had time to report it previously, apologies). It likely originated a while before though, I don't use these cards very often. panic: end address is not aligned #1 0x80426a8a in kern_reboot (howto=260) at /home/svn/head/sys/kern/kern_shutdown.c:430 #2 0x80426521 in panic (fmt=Variable "fmt" is not available. ) at /home/svn/head/sys/kern/kern_shutdown.c:604 #3 0x8032c648 in pcib_grow_window (sc=0xfe0002603400, w=0xfe0002603498, type=3, start=0, end=4294967295, count=65536, flags=Variable "flags" is not available. ) at /home/svn/head/sys/dev/pci/pci_pci.c:1018 #4 0x8032c8f7 in pcib_alloc_resource (dev=0xfe00026f2600, child=0xfe0002eaf800, type=Variable "type" is not available. ) at /home/svn/head/sys/dev/pci/pci_pci.c:1090 #5 0x80325bdd in pci_alloc_resource (dev=0xfe000279bd00, child=0xfe0002eaf800, type=3, rid=0xff8000309688, start=2281701376, end=18446744073709551615, count=65536, flags=16384) at bus_if.h:263 #6 0x8031bd25 in cbb_alloc_resource (brdev=Variable "brdev" is not available. ) at bus_if.h:263 #7 0x80325d8e in pci_alloc_resource (dev=0xfe000279ed00, child=0xfe0002eaf800, type=3, rid=0xff8000309688, start=0, end=18446744073709551615, count=1, flags=16384) at bus_if.h:263 #8 0x80456f39 in bus_alloc_resource (dev=0xfe0002eaf800, type=3, rid=0xff8000309688, start=0, end=18446744073709551615, count=1, flags=12290) at bus_if.h:263 #9 0x802faa60 in cardbus_parse_cis (cbdev=0xfe000279ed00, child=0xfe0002eaf800, callbacks=0xff8000309af0, argp=0xfe0002e2d140) at bus.h:415 #10 0x802fb0c1 in cardbus_device_create (sc=0xfe00025d8030, devi=0xfe0002e2d000, parent=Variable "parent" is not available. ) at /home/svn/head/sys/dev/cardbus/cardbus_device.c:105 #11 0x802f9c4e in cardbus_attach_card (cbdev=0xfe000279ed00) at /home/svn/head/sys/dev/cardbus/cardbus.c:191 #12 0x8031ba44 in cbb_event_thread (arg=Variable "arg" is not available. ) at card_if.h:83 #13 0x803fb355 in fork_exit ( callout=0x8031b660 , arg=0xfe0002599800, frame=0xff8000309c50) at /home/svn/head/sys/kern/kern_fork.c:920 #14 0x80666c4e in fork_trampoline () at /home/svn/head/sys/amd64/amd64/exception.S:603 -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: named crashes on assertion in rbtdb.c on sparc64/SMP
On 06/29/2011 06:41, Marius Strobl wrote: On Wed, Jun 29, 2011 at 02:33:06PM +0400, KOT MATPOCKuH wrote: 2011/6/29 KOT MATPOCKuH: I'm got a problem with named on FreeBSD-CURRENT/sparc64. Up to 5 times a day it crashes with these messages: 27-Jun-2011 03:42:14.384 general: /usr/src/lib/bind/dns/../../../contrib/bind9/lib/dns/rbtdb.c:1614: REQUIRE(prev> 0) failed 27-Jun-2011 03:42:14.385 general: exiting (due to assertion failure) I found a some similar problems on alpha and IA64, which was related to problems with isc_atomic_xadd() function in include/isc/atomic.h. But I don't understand that there may be incorrect for sparc64 and this function was not changed for a minimum 4 years... Uhm, we once fixed a problem in the MD atomic implementation which still seems to present in the ISC copy. Could you please test whether the following patch makes a difference? http://people.freebsd.org/~marius/sparc64_isc_atomic.h.diff I ran named with your patch and and watching him. Omg. Or I incorrectly rebuilt named, or the problem is not solved. I got a crash after about 2 hours after named restarted: 29-Jun-2011 13:51:28.855 general: /usr/src/lib/bind/dns/../../../contrib/bind9/lib/dns/rbtdb.c:1614: REQUIRE(prev> 0) failed 29-Jun-2011 13:51:28.856 general: exiting (due to assertion failure) The remainder of the isc atomic.h looks fine though, so this likely is a general bug in BIND, especially if it didn't happen before BIND 9.6.-ESV-R4-P1. Doug should be able to help you. Doug, could you please nevertheless take care of getting the above patch into BIND? It's a merge of r148453. Hmm, I thought I had already pushed that rock up the appropriate hill, but maybe not. I've been following this thread, but it's incredibly unlikely that I'll be able to do anything useful with it until Friday. hth, Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: sys/boot/i386/boot2 (install) fail
On 06/24/2011 13:39, Doug Barton wrote: On r223514M, kernel installed Ok, then after reboot and attempt to installworld I first get a failure that "btxld" is not found. So I add that to ITOOLS and then I get this. Any ideas? Building again with a clean /usr/obj "solved" this problem, FYI. -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
sys/boot/i386/boot2 (install) fail
On r223514M, kernel installed Ok, then after reboot and attempt to installworld I first get a failure that "btxld" is not found. So I add that to ITOOLS and then I get this. Any ideas? Thanks, Doug ===> sys/boot/i386/boot2 (install) as --32 -o boot2.o boot2.s ld -static -N --gc-sections -nostdlib -m elf_i386_fbsd -Ttext 0x2000 -o boot2.out /usr/local/obj/home/svn/head/sys/boot/i386/boot2/../btx/lib/crt0.o boot2.o sio.o objcopy -S -O binary boot2.out boot2.bin btxld -v -E 0x2000 -f bin -b /usr/local/obj/home/svn/head/sys/boot/i386/boot2/../btx/btx/btx -l boot2.ldr -o boot2.ld -P 1 boot2.bin kernel: ver=1.02 size=690 load=9000 entry=9010 map=16M pgctl=1:1 client: fmt=bin size=13c1 text=0 data=0 bss=0 entry=0 output: fmt=bin size=1c51 text=200 data=1a51 org=0 entry=0 ls: not found arithmetic expression: expecting primary: "7680-" *** Error code 2 Stop in /home/svn/head/sys/boot/i386/boot2. *** Error code 1 -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
mariadb-server-5.2.6 failed on amd64 9
Unfortunately this problem didn't magically fix itself in the 5.2.7 version of mariadb, so I'm still open to suggestions ... Doug Original Message Subject: mariadb-server-5.2.6 failed on amd64 9 Date: Sat, 11 Jun 2011 22:16:22 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ To: freebsd-current@FreeBSD.org No luck on -ports, anyone here have a suggestion? I'm confused by this error, since it works just fine with default settings on 7 and 8 with both amd64 and i386. Can someone give me a suggestion on the right direction to look? Original Message Excerpt from the build log at http://pointyhat.FreeBSD.org/errorlogs/amd64-errorlogs/a.9.20110609110911/mariadb-server-5.2.6.log building mariadb-server-5.2.6 on gohan61.freebsd.org if c++ -DMYSQL_SERVER -DDEFAULT_MYSQL_HOME='"/usr/local"' -DMYSQL_DATADIR='"/usr/local/var"' -DSHAREDIR='"/usr/local/share/mysql"' -DPLUGINDIR='"/usr/local/lib/mysql/plugin"' -DHAVE_EVENT_SCHEDULER -DHAVE_CONFIG_H -I. -I. -I../include -I../include -I../include -I../regex -I. -I/usr/local/include -I/usr/local/include -O2 -pipe -fno-strict-aliasing -fno-implicit-templates -fno-exceptions -fno-rtti -DMYSQLD_NET_RETRY_COUNT=100 -MT sql_builtin.o -MD -MP -MF ".deps/sql_builtin.Tpo" -c -o sql_builtin.o sql_builtin.cc; then mv -f ".deps/sql_builtin.Tpo" ".deps/sql_builtin.Po"; else rm -f ".deps/sql_builtin.Tpo"; exit 1; fi In file included from ../include/my_global.h:454, from sql_builtin.cc:16: /usr/include/sys/timeb.h:42:2: warning: #warning "this file includes which is deprecated" libtool: link: cc -shared .libs/udf_example.o -lcrypt -lm -lpthread -lrt -Wl,-soname -Wl,udf_example.so.0 -o .libs/udf_example.so.0 libtool: link: c++ -O2 -pipe -fno-strict-aliasing -fno-implicit-templates -fno-exceptions -fno-rtti -DMYSQLD_NET_RETRY_COUNT=100 -o mysql_tzinfo_to_sql mysql_tzinfo_to_sql-tztime.o ../vio/libvio.a ../mysys/libmysys.a ../dbug/libdbug.a ../regex/.libs/libregex.a ../strings/libmystrings.a -lz -lcrypt -lm -lpthread -lrt libtool: link: (cd ".libs" && rm -f "udf_example.so" && ln -s "udf_example.so.0" "udf_example.so") libtool: link: (cd ".libs" && rm -f "udf_example.so" && ln -s "udf_example.so.0" "udf_example.so") libtool: link: ar cru .libs/libndb.a .libs/libndb_la-ha_ndbcluster.o .libs/libndb_la-ha_ndbcluster_binlog.o .libs/libndb_la-ha_ndbcluster_cond.o libtool: link: ranlib .libs/libndb.a libtool: link: ( cd ".libs" && rm -f "libndb.la" && ln -s "../libndb.la" "libndb.la" ) libtool: link: ar cru .libs/udf_example.a udf_example.o libtool: link: ranlib .libs/udf_example.a libtool: link: ( cd ".libs" && rm -f "udf_example.la" && ln -s "../udf_example.la" "udf_example.la" ) /bin/sh ../libtool --tag=CXX --mode=link c++ -O2 -pipe -fno-strict-aliasing -fno-implicit-templates -fno-exceptions -fno-rtti -DMYSQLD_NET_RETRY_COUNT=100 -o mysqld sql_lex.o sql_handler.o sql_partition.o item.o item_sum.o item_buff.o item_func.o item_cmpfunc.o item_strfunc.o item_timefunc.o thr_malloc.o item_create.o item_subselect.o item_row.o item_geofunc.o item_xmlfunc.o field.o strfunc.o key.o sql_class.o sql_list.o net_serv.o protocol.o sql_state.o lock.o my_lock.o sql_string.o sql_manager.o sql_map.o mysqld.o password.o hash_filo.o hostname.o sql_connect.o scheduler.o sql_parse.o set_var.o sql_yacc.o sql_base.o table.o sql_select.o sql_insert.o sql_profile.o sql_prepare.o sql_error.o sql_locale.o sql_update.o sql_delete.o uniques.o sql_do.o procedure.o sql_test.o log.o init.o derror.o sql_acl.o unireg.o des_key_file.o log_event.o rpl_record.o log_event_old.o rpl_record_old.o discover.o time.o opt_range.o opt_sum.o records.o filesor t .o handler.o ha_partition.o debug_sync.o sql_db.o sql_table.o sql_rename.o sql_crypt.o sql_load.o mf_iocache.o field_conv.o sql_show.o sql_udf.o sql_analyse.o sql_cache.o slave.o sql_repl.o rpl_filter.o rpl_tblmap.o rpl_utility.o rpl_injector.o rpl_rli.o rpl_mi.o rpl_reporting.o sql_union.o sql_derived.o sql_client.o repl_failsafe.o sql_olap.o sql_view.o gstream.o spatial.o sql_help.o sql_cursor.o tztime.o my_decimal.o sp_head.o sp_pcontext.o sp_rcontext.o sp.o sp_cache.o parse_file.o sql_trigger.o event_scheduler.o event_data_objects.o event_queue.o event_db_repository.o events.o sql_plugin.o sql_binlog.o sql_builtin.o sql_tablespace.o partition_info.o sql_servers.o event_parse_data.o opt_table_elimination.o create_options.o mini_client_errors.o pack.o client.o my_time.o my_user.o client_plugi
Re: rc.d script to load kernel modules
On 6/12/2011 1:43 PM, Jason Hellenthal wrote: Doug, On Sun, Jun 12, 2011 at 12:46:58PM -0700, Doug Barton wrote: On 6/12/2011 12:42 PM, Jason Hellenthal wrote: Yes I agree. I was just stating that simply for the previous post implying where ZFS was slower than UFS. No, it wasn't. You completely fail to understand the problem. Stop writing, and start reading. As in, read the threads on both -arch and the svn list, and this entire thread again, then wait an hour or two before posting anything else. (Yes, I'm serious) Yes, it, was. This was not to your post. This was to another fellows which don't recall his name ATM but would please be as kind as to discard the unuseful comments. I was agree'ing with Gary that its not a problem with ZFS/UFS or any mix or match of the two. Perhaps a pause in both of our replies would be duly needed. Gustau's post said in part: For example, in my case, I'm booting from a zfs-only installation. Kldloading a ten or twelve modules in loader.conf takes a long time compared to a UFS-only installation. Moving them to a rc.d script would allow me to save a lot of time during the boot process. http://lists.freebsd.org/pipermail/freebsd-current/2011-June/025132.html zfs vs. ufs is entirely irrelevant to the matter at hand, which is entirely related to the fact that loading modules from the boot loader is always going to be many many times slower than loading them from the disk after the system is booted. Kevin was kind enough to elaborate, hopefully his explanation is better than mine, and will help you understand the problem better. Meanwhile, to address Gustau's original point, the modules related to getting zfs up and running would still have to be loaded in loader.conf. My solution is only effective for those modules which are not related to getting the local disks on line (which fortunately is the vast majority of them). Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: rc.d script to load kernel modules
On 6/12/2011 12:42 PM, Jason Hellenthal wrote: Yes I agree. I was just stating that simply for the previous post implying where ZFS was slower than UFS. No, it wasn't. You completely fail to understand the problem. Stop writing, and start reading. As in, read the threads on both -arch and the svn list, and this entire thread again, then wait an hour or two before posting anything else. (Yes, I'm serious) -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: rc.d script to load kernel modules
On 6/12/2011 12:34 PM, Garrett Cooper wrote: On Sun, Jun 12, 2011 at 12:24 PM, Gary Palmer wrote: On Sun, Jun 12, 2011 at 02:56:31PM -0400, Jason Hellenthal wrote: So technically here a ZFS only install is lacking the speed in which modules are loaded. I would prefer to find out why and fix that before we go about adding new functionality to rcNG. As I believe Doug has already said, its not just loading modules from ZFS. In my experience, loading modules via loader.conf from UFS on i386 is significantly slower than once the kernel has booted on both of my systems here. I think I've tried it and its not a disk thing as its slow loading from flash media also. Dumb questions: 0. Does anyone actually read what I write? 1. Has anyone benchmarked the two methods in parallel? If so what's the delta? As I've said several times now ... Loading modules in the boot loader takes an average of 2 seconds per module. Loading 6 of them from disk happens so fast I can't read the probe messages in real time. (I.e., less than 1 second total for all 6.) 2. Has anyone tried to determine why it is that way? Repeating myself again ... read the threads on -arch and the svn list. There you will find the answers from people a lot smarter than I. Short version, it's a known issue that cannot be changed. -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: rc.d script to load kernel modules
On 6/12/2011 12:16 PM, Jason Hellenthal wrote:
Doug,
On Sun, Jun 12, 2011 at 12:00:56PM -0700, Doug Barton wrote:
Absolutely not. That would not fit into the way we do things at all, and
would essentially require /etc/rc to do the processing, which is a huge
step in the wrong direction.
Ok can you explain this ? I am not seeing how /etc/rc would all of a
sudden have to jump in to do the proccessing anymore than it would with
the original patch ?
Ok, what do you propose the mechanism should be to process all of the
*_load variables? And why do you think it's preferable to do it that way
rather than simply listing the modules to load? (Other than, "that's the
way it's done in loader.conf" which I don't think is important.) Oh, and
btw, one benefit of the list (albeit a minor one) is being able to load
them in order. An additional problem with *_load in rc.conf is that it
prevents any other rc.d script from using ${name}_load as an option
(which should be a hint as to another reason why this is a very bad idea).
"That would not fit into the way we do things at all" funny because
thats exactly how we have been doing things in loader.conf for some odd
umpteen years plus. Unless I misunderstood how you meant this ?.
What do loader.conf and rc.conf have to do with one another? I'll save
you the time, absolutely nothing (except ".conf" of course). They are
completely different mechanisms processed by completely different back
ends.
I'm actually not trying to be rude here, this is just such a terrible
idea that I'm surprised someone as smart as you are suggested it. If
this explanation isn't sufficient, feel free to submit a diff that
implements your suggestion. Maybe working through it will make it more
clear.
--
Nothin' ever doesn't change, but nothin' changes much.
-- OK Go
Breadth of IT experience, and depth of knowledge in the DNS.
Yours for the right price. :) http://SupersetSolutions.com/
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: rc.d script to load kernel modules
On 6/12/2011 12:05 PM, Jason Hellenthal wrote: Any opposition for keeping the syntax of loader.conf ? nullfs_load="YES" Yes, see my other message on this point. -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: rc.d script to load kernel modules
On 6/12/2011 11:56 AM, Jason Hellenthal wrote: So technically here a ZFS only install is lacking the speed in which modules are loaded. It has nothing to do with zfs. It has to do with how the kernel and modules are loaded at boot time, vs. after the disks are up. Please read the threads on -arch and the svn list before proceeding. I would prefer to find out why and fix that before we go about adding new functionality to rcNG. It's rc.d. It isn't "next generation" anymore. Personally after giving this some more thought I would not mind seeing the same syntax as in loader.conf brought to rc.conf. Absolutely not. That would not fit into the way we do things at all, and would essentially require /etc/rc to do the processing, which is a huge step in the wrong direction. -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: rc.d script to load kernel modules
On 6/12/2011 1:56 AM, Jason Hellenthal wrote: Cutting modules out of the kernel in general does help speed up booting but loading those same modules later in the boot process will just lead you back to the same boot time. Loading modules via loader.conf is many times slower than doing it from disk after the system is partially booted. (As in, 2-3 seconds per module vs. nearly instantaneous for all 6.) I didn't offer my list as an example of what to do, I offered it as a syntax example. I would of course expect people to use appropriate discretion to load things in loader.conf that are necessary for boot. (Of course, the fact that people can easily get this wrong is a strike against the technique.) There is no point in having an _enable for this script because if the kld_list is empty, nothing happens. -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
mariadb-server-5.2.6 failed on amd64 9
No luck on -ports, anyone here have a suggestion? I'm confused by this error, since it works just fine with default settings on 7 and 8 with both amd64 and i386. Can someone give me a suggestion on the right direction to look? Original Message Excerpt from the build log at http://pointyhat.FreeBSD.org/errorlogs/amd64-errorlogs/a.9.20110609110911/mariadb-server-5.2.6.log building mariadb-server-5.2.6 on gohan61.freebsd.org if c++ -DMYSQL_SERVER -DDEFAULT_MYSQL_HOME='"/usr/local"' -DMYSQL_DATADIR='"/usr/local/var"' -DSHAREDIR='"/usr/local/share/mysql"' -DPLUGINDIR='"/usr/local/lib/mysql/plugin"' -DHAVE_EVENT_SCHEDULER -DHAVE_CONFIG_H -I. -I. -I../include -I../include -I../include -I../regex -I. -I/usr/local/include -I/usr/local/include -O2 -pipe -fno-strict-aliasing -fno-implicit-templates -fno-exceptions -fno-rtti -DMYSQLD_NET_RETRY_COUNT=100 -MT sql_builtin.o -MD -MP -MF ".deps/sql_builtin.Tpo" -c -o sql_builtin.o sql_builtin.cc; then mv -f ".deps/sql_builtin.Tpo" ".deps/sql_builtin.Po"; else rm -f ".deps/sql_builtin.Tpo"; exit 1; fi In file included from ../include/my_global.h:454, from sql_builtin.cc:16: /usr/include/sys/timeb.h:42:2: warning: #warning "this file includes which is deprecated" libtool: link: cc -shared .libs/udf_example.o -lcrypt -lm -lpthread -lrt -Wl,-soname -Wl,udf_example.so.0 -o .libs/udf_example.so.0 libtool: link: c++ -O2 -pipe -fno-strict-aliasing -fno-implicit-templates -fno-exceptions -fno-rtti -DMYSQLD_NET_RETRY_COUNT=100 -o mysql_tzinfo_to_sql mysql_tzinfo_to_sql-tztime.o ../vio/libvio.a ../mysys/libmysys.a ../dbug/libdbug.a ../regex/.libs/libregex.a ../strings/libmystrings.a -lz -lcrypt -lm -lpthread -lrt libtool: link: (cd ".libs" && rm -f "udf_example.so" && ln -s "udf_example.so.0" "udf_example.so") libtool: link: (cd ".libs" && rm -f "udf_example.so" && ln -s "udf_example.so.0" "udf_example.so") libtool: link: ar cru .libs/libndb.a .libs/libndb_la-ha_ndbcluster.o .libs/libndb_la-ha_ndbcluster_binlog.o .libs/libndb_la-ha_ndbcluster_cond.o libtool: link: ranlib .libs/libndb.a libtool: link: ( cd ".libs" && rm -f "libndb.la" && ln -s "../libndb.la" "libndb.la" ) libtool: link: ar cru .libs/udf_example.a udf_example.o libtool: link: ranlib .libs/udf_example.a libtool: link: ( cd ".libs" && rm -f "udf_example.la" && ln -s "../udf_example.la" "udf_example.la" ) /bin/sh ../libtool --tag=CXX --mode=link c++ -O2 -pipe -fno-strict-aliasing -fno-implicit-templates -fno-exceptions -fno-rtti -DMYSQLD_NET_RETRY_COUNT=100 -o mysqld sql_lex.o sql_handler.o sql_partition.o item.o item_sum.o item_buff.o item_func.o item_cmpfunc.o item_strfunc.o item_timefunc.o thr_malloc.o item_create.o item_subselect.o item_row.o item_geofunc.o item_xmlfunc.o field.o strfunc.o key.o sql_class.o sql_list.o net_serv.o protocol.o sql_state.o lock.o my_lock.o sql_string.o sql_manager.o sql_map.o mysqld.o password.o hash_filo.o hostname.o sql_connect.o scheduler.o sql_parse.o set_var.o sql_yacc.o sql_base.o table.o sql_select.o sql_insert.o sql_profile.o sql_prepare.o sql_error.o sql_locale.o sql_update.o sql_delete.o uniques.o sql_do.o procedure.o sql_test.o log.o init.o derror.o sql_acl.o unireg.o des_key_file.o log_event.o rpl_record.o log_event_old.o rpl_record_old.o discover.o time.o opt_range.o opt_sum.o records.o filesort .o handler.o ha_partition.o debug_sync.o sql_db.o sql_table.o sql_rename.o sql_crypt.o sql_load.o mf_iocache.o field_conv.o sql_show.o sql_udf.o sql_analyse.o sql_cache.o slave.o sql_repl.o rpl_filter.o rpl_tblmap.o rpl_utility.o rpl_injector.o rpl_rli.o rpl_mi.o rpl_reporting.o sql_union.o sql_derived.o sql_client.o repl_failsafe.o sql_olap.o sql_view.o gstream.o spatial.o sql_help.o sql_cursor.o tztime.o my_decimal.o sp_head.o sp_pcontext.o sp_rcontext.o sp.o sp_cache.o parse_file.o sql_trigger.o event_scheduler.o event_data_objects.o event_queue.o event_db_repository.o events.o sql_plugin.o sql_binlog.o sql_builtin.o sql_tablespace.o partition_info.o sql_servers.o event_parse_data.o opt_table_elimination.o create_options.o mini_client_errors.o pack.o client.o my_time.o my_user.o client_plugin.o libndb.la -static -all-static -L/usr/local/lib -levent ../storage/myisam/libmyisam_s.la ../storage/archive/libarchive.la ../storage/blackhole/libblackhol e. la ../storage/csv/libcsv.la ../storage/federatedx/libfederat! edx.la ../storage/heap/libheap_s.la ../storage/maria/libaria_s.la ../storage/myisammrg/libmyisammrg_s.la ../storage/sphinx/libsphinx.la ../storage/xtradb/libxtradb.la ../vio/libvio.a ../mysys/libmysys.a ../dbug/libdbug.a ../regex/libregex.la ../strings/libmystrings.a -lz ../extra/yassl/src/libyassl.la ../extra/yassl/taocrypt/src/libtaocrypt.la -lcrypt -lm -lpthread -lrt libtool: link: c++ -O2 -pipe -fno-strict-aliasing -fno-implicit-templates -fno-exceptions
kldstat -q -m seems broken
Howdy, I'm running 9.0-CURRENT r222889M amd64 and in the kld script I just sent to the list I had to use the slower 'load_kld -e' form because 'kldstat -q -m foo' is not working for me. For example: kldstat -qm linux ; echo $? 1 However the module is definitely loaded: 52 0x81828000 1f113linux.ko The same is true for several of my other modules, so it seems to be a fairly general problem. Anyone interested in taking a look? Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
rc.d script to load kernel modules
Howdy,
Per discussion on -arch and the svn list about improving boot time and
stripping down the kernel to just that-which-cannot-be-modularized I
created the attached script to kldload modules that don't need to be in
loader.conf. It cut quite a bit of time off my boot, so hopefully it
will be useful to others as well.
To use it just put everything that is being _load'ed in loader.conf into
kld_list in rc.conf[.local]. For example, mine has:
kld_list='umass coretemp ichwd linux nvidia if_wpi'
If there is agreement that this is a good direction to go I'll be happy
to commit this along with the relevant /etc/defaults/rc.conf and
rc.conf.5 changes.
hth,
Doug
--
Nothin' ever doesn't change, but nothin' changes much.
-- OK Go
Breadth of IT experience, and depth of knowledge in the DNS.
Yours for the right price. :) http://SupersetSolutions.com/
#!/bin/sh
# $FreeBSD$
#
# PROVIDE: kld
# REQUIRE: FILESYSTEMS
# KEYWORD: nojail
# BEFORE: var
. /etc/rc.subr
name="kld"
start_cmd="${name}_start"
stop_cmd=':'
kld_start()
{
[ -n "$kld_list" ] || return
local _kld
echo 'Loading kernel modules:'
for _kld in $kld_list ; do
load_kld -e ${_kld}.ko $_kld
done
}
load_rc_config $name
run_rc_command "$1"
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: llimport(8): Import lastlog into utmpx
On 06/03/2011 14:07, Ed Schouten wrote: the reason why I picked the current approach, is because I don't want to cause people to get confused when they upgrade to 9.0, to discover that their lastlog database is `missing'. Understood, but in my mind that's a release notes issue. -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: llimport(8): Import lastlog into utmpx
On 06/03/2011 13:47, Garrett Cooper wrote: On Fri, Jun 3, 2011 at 1:43 PM, Ed Schouten wrote: Hi all, I think not long after I replaced utmp with utmpx, I got requests to add utilities to convert the old utmp databases to the new formats. I added wtmpcvt(1) for /var/log/wtmp*, but I didn't add any tools for the other databases. Even though it's a bit overdue (more than one year later?), I think it wouldn't be a bad idea to add a utility to import lastlog for people who are going to upgrade from 7.x/8.x to 9.0. I've written a utility called llimport(8), which imports entries from lastlog into utx.lastlogin for users which do not already have an entry in the latter. I've also added an rc-script, which executes llimport when /var/log/lastlog is present and renames the old database to /var/log/lastlog.old. Any objections if I commit the following patch to HEAD one of these days? I will remove it from HEAD not long after we release 9.0, since an upgrade from 8.x to 10.x should go through 9.x anyway. http://80386.nl/pub/llimport.txt It would be nice if someone could look at the rc script. I think it should be okay, but it's not a part of the tree I'm familiar with. Is this a one time change? If so, wouldn't it make more sense to put this into mergemaster(8) instead of rc(5)? FWIW I'm not enthusiastic about either option. I definitely don't think an rc.d script is desirable, since it would be run at every boot for what (if I understand it correctly) is a one-time thing. More or less the same argument applies to adding this to mergemaster. In my mind the best way to handle this would be to add it to tools/ and let users who need it access it that way. But perhaps I'm missing something? Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: CURRENT && /usr/ports
On 05/26/2011 01:37, Matthias Apitz wrote: Hello, I'm running -CURRENT on my laptop (r220692 from ~mid of April) and /usr/ports from CVS from the same day; I want from time to time (let's says once a week) SVN update my kernel and userland; I know that these two should be in sync, but what about the ports? I have installed around 1200 ports I'm used to use. Is there any special note in /usr/src/UPDATING when the ABI changes and would break the compiled ports? I've been using -current on my laptop for years and have run into this problem less than a handful of times. As a general principle you don't need to be concerned about it. OTOH, if you are using ports that are tied into the source tree (like nvidia modules, fuse, virtualbox, etc.) then of course you should rebuild those ports after you update your system. hth, Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [PATCH] Fix CFLAGS overwrite by Makefile
On 05/24/2011 13:41, Dimitry Andric wrote: So that is why these Makefiles purposefully overwrite CFLAGS, it is not by accident. In those cases adding comments to the Makefile is probably appropriate, if they are not present already. Something to the effect of, "Purposely overwriting CFLAGS because ..." Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: My problems with stability on -current
On 05/11/2011 04:33, Alexander Motin wrote:
On 11.05.2011 08:17, Doug Barton wrote:
I had an interesting result doing nothing but switching from HPET to
LAPIC ... no crash. Still on the same version of -current (r221566) the
only thing I've done is to add kern.eventtimer.timer="LAPIC" to
/boot/loader.conf, and so far I haven't been able to get it to crash no
matter how much I compile, or how much other stuff I do in the
background. I _can_ get the system heavily loaded enough so that the
mouse can drag across the screen, windows take visible time to repaint,
etc. That happens with a load average of 4+ on this core 2 duo. But
other than that (which is not altogether unreasonable) the system has
been very stable for a couple of days now.
Does that suggest a next step in terms of what to test?
The fact that LAPIC is working fine can mean that problem is either HPET
specific or non-per-CPU timers specific. To check that you could try to
use i8254 timer in one-shot mode:
hint.attimer.0.timecounter=0
kern.eventtimer.timer="i8254"
, or use HPET in per-CPU mode:
hint.atrtc.0.clock=0
hint.attimer.0.clock=0
hint.hpet.X.legacy_route=1
But the most informative would be to see what's going on with HPET
interrupts during the freezes. With HPET hardware it is very easy to
loose interrupt. And the lost interrupt means problem for many things.
There are some workarounds made for that, but I can't be sure. For that
case you could experiment with this patch:
--- acpi_hpet.c.prev 2010-12-25 11:28:45.0 +0200
+++ acpi_hpet.c 2011-05-11 14:30:59.0 +0300
@@ -190,7 +190,7 @@ restart:
bus_write_4(sc->mem_res, HPET_TIMER_COMPARATOR(t->num),
t->next);
}
- if (fdiv < 5000) {
+ if (1 || fdiv < 5000) {
bus_read_4(sc->mem_res, HPET_TIMER_COMPARATOR(t->num));
now = bus_read_4(sc->mem_res, HPET_MAIN_COUNTER);
Ok, I'll try the patch sometime soon, lots going on right now. FYI, I
had something odd happen tonight, the laptop had been up for about 36
hours, and it was idle for a while when I was afk for about an hour.
When I came back, the system was off. Nothing in the logs, no core dump,
but it definitely crashed because when I turned it back on the file
systems were all dirty. This is still r221566 running LAPIC.
Interestingly I had pidgin running while it was idle, and a friend sent
me an e-mail saying that he tried to IM me and as soon as he sent the
message my status went from "away" to "off line." The time he sent the
e-mail corresponds roughly to the last entry in the log before I
rebooted it. I realize that this is not a lot to go on, but I thought
I'd mention it.
Doug
--
Nothin' ever doesn't change, but nothin' changes much.
-- OK Go
Breadth of IT experience, and depth of knowledge in the DNS.
Yours for the right price. :) http://SupersetSolutions.com/
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: My problems with stability on -current
I had an interesting result doing nothing but switching from HPET to LAPIC ... no crash. Still on the same version of -current (r221566) the only thing I've done is to add kern.eventtimer.timer="LAPIC" to /boot/loader.conf, and so far I haven't been able to get it to crash no matter how much I compile, or how much other stuff I do in the background. I _can_ get the system heavily loaded enough so that the mouse can drag across the screen, windows take visible time to repaint, etc. That happens with a load average of 4+ on this core 2 duo. But other than that (which is not altogether unreasonable) the system has been very stable for a couple of days now. Does that suggest a next step in terms of what to test? -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: My problems with stability on -current
New symptom, today (still running r221566) I compiled a small port, that worked without any freezes or interactivity problems. Then I tried compiling a larger port (java/openjdk6 if anyone cares) and still no interactivity problems, but I got the "system wedge requiring power cycle" problem I was seeing previously that I tracked to the one-shot timer update. More below. On 05/07/2011 02:43, Alexander Motin wrote: Doug Barton wrote: On 05/05/2011 13:55, Alexander Motin wrote: I see several possibly unrelated problems there: - crashes are always crashes. They should be debugged. - calcru going backwards could have the same roots as lost wall clock time. I think you're right about that. What usually happens when the load maxes out is that the system visibly freezes for a minute or 2, and when it comes back to life the log is flooded with calcru messages. If it stays up long enough after that the wall clock drift becomes noticeable. This is in spite of running ntpd. These system freezes are very suspicious. Most time counters need only few seconds to overflow, some even less. So freeze for few minutes will easily overflow most of them. So the freezes are probably the cause of time problems, but the question now is what the cause of freezes. You should try to investigate what is going on during freezes. Does the system do anything, are there any interrupts working (`vmstat -i` just before and after), are there any interrupt storms, etc? Here is the output on a mostly-idle system, shortly after reboot: vmstat -i interrupt total rate irq1: atkbd01784 0 irq9: acpi01 0 irq14: ata0 213355 89 irq15: ata1 58 0 irq17: wpi074331 31 irq20: hpet0 uhci0+ 787767331 irq22: uhci2 21453 9 irq256: hdac0 11 0 Total1098760462 At a more opportune time I'll try crashing it again and get another result. If there are some problems with timer interrupts, timecounters could wrap unnoticed that will cause random time jumps. - interactivity problems. I can't prove it is unrelated, but have no real ideas now. I would start from most obvious problems. I need to know more about crashes. As usual: how to trigger, stack backtraces, etc. Triggering is easy, I can start a buildworld with -j2, and a build of ports/www/firefox with FORCE_MAKE_JOBS, and within 30 minutes the system will reboot. I posted a panic message relative to r220282, (-current archives, 4/4) but kib said it didn't make any sense. Usually I don't get a panic at all. Could you hint me the thread? Go to http://www.FreeBSD.org/ Click 'mailing lists' Click 'listed in the FreeBSD Handbook.' Click freebsd-current Click freebsd-current Archives Click April 2011 search for r220282 Voila! :) What's about time problems, I would try to collect more data: - show `sysctl kern.eventtimer`, `sysctl kern.timecounter` and verbose dmesg outputs; http://people.freebsd.org/~dougb/dougb-current-r221566.txt - what eventtimer is used now and does it helps to switch to another one with kern.eventtimer.timer sysctl? When I was trying to track down the problems last summer I vaguely remember trying RTC, but eventually we realized that the real problem was throttling, so I stopped specifying RTC and let it go back to the default. What do you suggest I try? As I see, now you are using HPET (chosen automatically). I would try switch to the LAPIC. Just make sure to disable C-states if you are enabled them to be sure that LAPIC timer won't stop. Ok, so kern.eventtimer.timer="LAPIC" in /boot/loader.conf should do that, right? I don't use C-states (in part as a result of previous investigation) but I do use powerd as such: powerd_flags="-a adaptive -b adaptive -n adaptive" - does the timer runs in periodic or one-shot mode and does it helps to switch to another one? How could I tell, and how would I switch? `sysctl kern.eventtimer.periodic`. kern.eventtimer.periodic: 0 And read eventtimers(4) please. I did that, but I don't see anything in there as to which choice is one-shot, and how to change to periodic. I assume 0 is the default, which I also assume is one-shot. Does setting that to 1 change to periodic? Also, can I safely do this while the system is running, or should it be in /boot/loader.conf as well? - if full CPU load makes time to stop, try to track what is going on with timer interrupts using `vmstat -i` and `systat -vm 1`. Under full CPU load in one-shot mode you should have stable timer interrupt rate about hz+stathz. Ok, I'll do that tomorrow, tired now. - if timer interrupts are not w
Re: My problems with stability on -current
On 05/05/2011 13:55, Alexander Motin wrote: Doug Barton wrote: Alexander suggested some knobs to twist for the timers, and I'll be glad to do that once he gets back to me with more concrete suggestions now that he knows more about my specific problems. OK, I am all here. While this post is indeed larger then previous, it is not much more informative. Sorry. :( I understand. I see several possibly unrelated problems there: - crashes are always crashes. They should be debugged. - calcru going backwards could have the same roots as lost wall clock time. I think you're right about that. What usually happens when the load maxes out is that the system visibly freezes for a minute or 2, and when it comes back to life the log is flooded with calcru messages. If it stays up long enough after that the wall clock drift becomes noticeable. This is in spite of running ntpd. If there are some problems with timer interrupts, timecounters could wrap unnoticed that will cause random time jumps. - interactivity problems. I can't prove it is unrelated, but have no real ideas now. I would start from most obvious problems. I need to know more about crashes. As usual: how to trigger, stack backtraces, etc. Triggering is easy, I can start a buildworld with -j2, and a build of ports/www/firefox with FORCE_MAKE_JOBS, and within 30 minutes the system will reboot. I posted a panic message relative to r220282, (-current archives, 4/4) but kib said it didn't make any sense. Usually I don't get a panic at all. What's about time problems, I would try to collect more data: - show `sysctl kern.eventtimer`, `sysctl kern.timecounter` and verbose dmesg outputs; http://people.freebsd.org/~dougb/dougb-current-r221566.txt - what eventtimer is used now and does it helps to switch to another one with kern.eventtimer.timer sysctl? When I was trying to track down the problems last summer I vaguely remember trying RTC, but eventually we realized that the real problem was throttling, so I stopped specifying RTC and let it go back to the default. What do you suggest I try? - does the timer runs in periodic or one-shot mode and does it helps to switch to another one? How could I tell, and how would I switch? - if full CPU load makes time to stop, try to track what is going on with timer interrupts using `vmstat -i` and `systat -vm 1`. Under full CPU load in one-shot mode you should have stable timer interrupt rate about hz+stathz. Ok, I'll do that tomorrow, tired now. - if timer interrupts are not working well, you can build kernel with optionsKTR optionsALQ optionsKTR_ALQ optionsKTR_COMPILE=(KTR_SPARE2) optionsKTR_ENTRIES=131072 optionsKTR_MASK=(KTR_SPARE2) to track event timers operation and use ktrdump to save the trace when problem exist (preferably when it begins). And let's experiment with fresh CURRENT. Done and done. I'm up to r221566, and I added those options to my kernel config. I ran ktrdump -cH -o ktrdumpfile and posted the results here: http://people.freebsd.org/~dougb/ktrdumpfile.txt This was shortly after boot, with no load. Not sure if it helps, but there you go. Thanks again for your help, Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
My problems with stability on -current
This is long, sorry. I wish I could condense things down to just the answer, or even just the question, but here goes. I've used HEAD on my main workstation(s) for many years. It's common for there to be ups and downs, and that's fine. Lately however the problems have been debilitating. First a timeline. Since sometime before January 2008 I've been using a Dell Latitude D620 laptop as my primary system. It has a core 2 duo running at 2.33 G, and 2 G RAM. I 4xboot it with windows xp, freebsd current (amd64), another freebsd (usually 8.N-RELEASE i386) and Ubuntu. On the first and last I don't do a lot of compiling obviously, but even under heavy load on 8.2-RELEASE I'm not seeing problems, so the problems I _am_ seeing are not hardware related. I keep my system very close to stock. My kernel config is GENERIC minus devices I don't have, and plus the following: options EXT2FS options IEEE80211_DEBUG # enable debug msgs options VESA device atapicam device sound device snd_hda device snp I was building with clang for a while, but when the problems started I went back to gcc. I still have INVARIANTS on but I disabled WITNESS because with all the known+unfixed LORs it's kind of pointless. Nothing interesting in make/src.conf either, the latter is just a list of stuff not to build, KERNCONF, and MODULES_OVERRIDE. Starting around December 2009 I started having problems under load with -current. Often I reported them, sometimes problems were found, sometimes not. In the course of trying to debug those problems I disabled throttling, which helped. Switching to SCHED_4BSD also helped quite a bit with interactivity under load, although it was still worse than on 8.x. In October of 2010 I was lucky enough to receive a donation of a Dell Optiplex desktop that I started using as my primary workstation. Around that same time there was some work being done in the scheduler(s) and various related systems, and my desktop (which had a slightly faster core 2 duo and 4 G RAM) was running great. I assumed that the problems were solved. Then 2 months ago I packed up the desktop system and pulled out the laptop again. I updated to the latest -current on the laptop, and all heck broke loose. I couldn't do anything on my laptop that created even a mediocre load without it crashing. Trying to do something like a buildworld (even without -j) would cause the system to absolutely crawl. I'd get tons of the dreaded "calcru" messages about time going backwards, and the system clock would lose literally minutes of wall clock time. At one point when I could keep it up long enough to build the world without crashing it had lost 40 minutes of wall clock time when it finished. I think that specific problem happened sometime between March 15 and r220282. In trying to find that problem, I uncovered another, deeper problem with the "one-shot timers" from r212541. In order to make my binary search easier for the problem described above I was using a -current snapshot CD from August 2010 that I had laying around. I could easily build world with -j2, run X, do normal desktop stuff (firefox, thunderbird, pidgin, etc.) all at the same time. When I got closer to the more recent -current, it would crash as soon as I put a load on it. I eventually bifurcated down to that exact commit. I've been running on 212540 for over a week now without any problems, including lots of port builds with FORCE_MAKE_JOBS, etc. Alexander suggested some knobs to twist for the timers, and I'll be glad to do that once he gets back to me with more concrete suggestions now that he knows more about my specific problems. Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: responsiveness during IO tasks
On 04/26/2011 03:37, Alexander Best wrote: On Mon Apr 25 11, Steve Wills wrote: Hi, I've noticed lately that when doing heavy IO, my 9-CURRENT system (Fri Apr 15 23:33:46 EDT 2011) is quite unresponsive. I have two ZFS mirrors setup and run KDE4. The system has 12GB of RAM. When I, for example, copy an ISO image from one mirror to the other, the whole desktop becomes really slow during the copy. It takes a good 15 seconds to open a new tab in Konsole, switching windows takes a while, etc. Once the copy is finished, things are fine. It wasn't like this back before I upgraded from 8.2-RC1 to 9-CURRENT. Has anyone else noticed something similar, or is it just me? Is there any other info I can provide or something I should look for? i've noticed this too. for me the situation is sometimes even worse. during heavy i/o the mouse cursor won't even respond. i think this is a scheduler isse. maybe running a non-preemptive kernel or switching to the old 4bsd scheduler fixes it? Try backing up your src tree to r212540, clean /usr/obj, buildworld/kernel and see if that helps. I just tracked down a big part of my current problem (pun intended) to r212541, the one-shot timer commit. I'm working on a larger post to describe my problems, but short version is, up through r212540 I can load the system down as heavily as I want, and while there may be some unresponsiveness it's at least stable. If I update to one-shot timers the system wedges as soon as I put load on it. No panic, not even a reboot, it just wedges solid requiring it to be powered off. You should also test SCHED_4BSD to see if that improves your situation. There have been a lot of reports about problems with SCHED_ULE with heavy disk i/o. Moving to 4bsd helps me in terms of interactivity, but I needed to find the crashing problem first. hth, Doug (sorry mav) -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Why is /usr/obj/lib32 where it is?
On 04/25/2011 13:07, Steve Kargl wrote: On Mon, Apr 25, 2011 at 12:53:44PM -0700, Doug Barton wrote: Howdy, In my /usr/obj (on amd64) I have 2 directories; lib32, and the root of the fs where the sources are. It seems odd to me that lib32 is not under the same root as everything else, so I'm asking why. :) troutmask:kargl[214] find /usr/obj/usr/src/lib32 -type f | wc -l 2412 It seems that a portion of lib32 is found were you appear to want it to be. I don't understand your answer. Let me add a few more details. My /usr/src is a symlink to /home/svn/head. For that matter, my /usr/obj is actually a symlink to /usr/local/obj. Meanwhile, I have the following in /usr/obj: ls /usr/obj/ home/ lib32/ hth, Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Why is /usr/obj/lib32 where it is?
Howdy, In my /usr/obj (on amd64) I have 2 directories; lib32, and the root of the fs where the sources are. It seems odd to me that lib32 is not under the same root as everything else, so I'm asking why. :) Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Switch from legacy ata(4) to CAM-based ATA
On 04/20/2011 16:01, Warren Block wrote: Not sure I understand the question. I have a little article called FreeBSD Labeled Filesystems: http://www.wonkity.com/~wblock/docs/html/labels.html That's a good article, but it highlights what seem to be some deficiencies in the various implementations. For the most part they seem ufs-centric, although glabel shows some promise for supporting ext2fs and msdosfs (both of which are workhorse file systems for me). In your article you point out another thing that seems sub-optimal to me, different locations for different types of things which are all referred to as labels. My primary concern however is, quite frankly, that it isn't being done the way linux does it, on 2 fronts. First, I like the fact that on linux the labels are created with uuidgen at install time, and all the configuration is transparent to the user. Here is a good article that gives an overview: http://www.linux.com/archive/feature/146951, although searching for "linux uuid disk label" yielded a lot of good results. (Testing with our uuidgen(1) I noticed that we would probably need to do some work to support more methods to make it a little less predictable, but that shouldn't be difficult). The other concern I have is that having installed linux (ubuntu specifically) it's already created labels for things. If I run glabel is it potentially going to overwrite them? Why can't 'glabel list' (or some other tool) "see" those labels? And if this kind of label already exists, why can't we just use it? Finally, is glabel (which seems to be the only option for multi-fs labeling) be used safely for at least msdosfs and ext2fs? And if glabel is safe to use for all of our supported file systems, can they safely be mounted that way? Thanks, Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Switch from legacy ata(4) to CAM-based ATA
On 04/20/2011 15:18, Scott Long wrote: I agree with what Alexander is saying, but I'd like to take it a step further. We should all be using [...] mount-by-label +1 When I first saw this on linux my gut reaction was "e, different." But now that I've worked with it a bit, I really like it. Doing this by default in 9.0 would be a really useful step forward, and would allow greater innovation down the road. Is there a handy tutorial somewhere for making this change in FreeBSD? Or is it even possible to do in a rational way? Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: `hw.acpi.thermal.tz0.temperature' disappeared
On 4/19/2011 9:44 AM, m...@freebsd.org wrote: As an aside, what kind of h/w do I need for hw.acpi.thermal to show up? I don't see it on my Dell desktop... The hardware is likely to be there for any reasonably modern Dell desktop. Do you have coretemp loaded? Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
crash on r220282
Someone suggested I might get better results including the actual panic: panic: Freeing unused sector 4918950 6 c41f Meanwhile the core.txt.1 file is in my home directory on freefall. Doug #0 sched_switch (td=dwarf2_read_address: Corrupted DWARF expression. ) at /home/svn/head/sys/kern/sched_ule.c:1854 #1 0x8042b16d in mi_switch (flags=dwarf2_read_address: Corrupted DWARF expression. ) at /home/svn/head/sys/kern/kern_synch.c:450 #2 0x8045ce3a in sleepq_switch (wchan=dwarf2_read_address: Corrupted DWARF expression. ) at /home/svn/head/sys/kern/subr_sleepqueue.c:538 #3 0x8045d303 in sleepq_timedwait (wchan=dwarf2_read_address: Corrupted DWARF expression. ) at /home/svn/head/sys/kern/subr_sleepqueue.c:652 #4 0x8042abe8 in _sleep (ident=Variable "ident" is not available. ) at /home/svn/head/sys/kern/kern_synch.c:230 #5 0x8065cfa0 in scheduler (dummy=0x0) at /home/svn/head/sys/vm/vm_glue.c:771 #6 0x803dc2b3 in mi_startup () at /home/svn/head/sys/kern/init_main.c:258 #7 0x8027164f in btext () #8 0x80acba60 in bootverbose () #9 0x80a81a80 in tdq_cpu () #10 0x80acba60 in bootverbose () #11 0x80a83800 in sleepq_chains () #12 0x80caab80 in ?? () #13 0x80caab28 in ?? () #14 0xfe00015d4000 in ?? () #15 0x80442cd7 in sched_switch (td=dwarf2_read_address: Corrupted DWARF expression. ) at /home/svn/head/sys/kern/sched_ule.c:1848 Previous frame inner to this frame (corrupt stack?) -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
crash on r220282
#0 sched_switch (td=dwarf2_read_address: Corrupted DWARF expression. ) at /home/svn/head/sys/kern/sched_ule.c:1854 #1 0x8042b16d in mi_switch (flags=dwarf2_read_address: Corrupted DWARF expression. ) at /home/svn/head/sys/kern/kern_synch.c:450 #2 0x8045ce3a in sleepq_switch (wchan=dwarf2_read_address: Corrupted DWARF expression. ) at /home/svn/head/sys/kern/subr_sleepqueue.c:538 #3 0x8045d303 in sleepq_timedwait (wchan=dwarf2_read_address: Corrupted DWARF expression. ) at /home/svn/head/sys/kern/subr_sleepqueue.c:652 #4 0x8042abe8 in _sleep (ident=Variable "ident" is not available. ) at /home/svn/head/sys/kern/kern_synch.c:230 #5 0x8065cfa0 in scheduler (dummy=0x0) at /home/svn/head/sys/vm/vm_glue.c:771 #6 0x803dc2b3 in mi_startup () at /home/svn/head/sys/kern/init_main.c:258 #7 0x8027164f in btext () #8 0x80acba60 in bootverbose () #9 0x80a81a80 in tdq_cpu () #10 0x80acba60 in bootverbose () #11 0x80a83800 in sleepq_chains () #12 0x80caab80 in ?? () #13 0x80caab28 in ?? () #14 0xfe00015d4000 in ?? () #15 0x80442cd7 in sched_switch (td=dwarf2_read_address: Corrupted DWARF expression. ) at /home/svn/head/sys/kern/sched_ule.c:1848 Previous frame inner to this frame (corrupt stack?) -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
How can I clone a mac address on wlan0?
For a variety of boring reasons I need to clone a mac address on wlan0. The documented way to do this: ifconfig wlan0 create wlandev wpi0 wlanaddr 00:11:22:33:44:55:66 works in the sense that it sets up the interface with that mac, but then the wlan0 interface never associates. Doing everything the same but omitting the wlanaddr argument (which causes wlan0 to use the mac of the wpi0 device) works. This also doesn't work in 8.2-RELEASE, so either we've got a long-standing bug, or I'm doing something very wrong. The wpi0 card is an intel 3945abg, I also have a couple of ath cards I can try (although so far they haven't worked either). Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: tzsetup disregards setting TZ to UTC
On 03/28/2011 16:24, David Cornejo wrote: To me it seems that the fault is that I can find no way in tzsetup to specify UTC. Though it seems the system defaults to UTC if you don't run tzsetup anyway, so maybe it would suffice to just say not to do that. (tzsetup is a no-op anyway if you're using UTC since in either case the system RTC would be set to UTC) While I don't follow the lists religiously, this is the first time in many years that I've seen someone make this complaint and I'd rather not change it. I made the same complaint recently in a semi-private forum, so you're not alone. :) I just haven't taken the time to figure out how best to "fix" it. Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: r219385 build error.
On 03/07/2011 14:56, Alexander Best wrote:
"native" doesn't get handled by bsd.cpu.mk at all! it gets passed to gcc
directly and gcc choses -m{tune,arch} on it's own.
don't add -march=* directly to CFLAGS. this is bound to go wrong at some
point. use CPUTYPE to set the cpu and CFLAGS for -O*, -pipe, etc.
also please keep in mind that the optimisations that can be achieved by
finetuning make.conf are rather minor. some people think that with
cflags and cpu juju they can boost the OS. i don't believe that's true. the
chances are much greater that you're adding a problematic switch and end up
with binaries during installworld that segfault. so it's not really worth
getting into this kinda trouble just for the sake of optimisation.
a simple
CPUTYPE ?= native
COPTFLAGS = -O0 -pipe
CFLAGS = -O2 -pipe
should be close to perfekt.;)
Does any of this pertain to clang?
Doug
--
Nothin' ever doesn't change, but nothin' changes much.
-- OK Go
Breadth of IT experience, and depth of knowledge in the DNS.
Yours for the right price. :) http://SupersetSolutions.com/
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
