Re: cvsup/csup servers stale?
Good luck with employing full discombobulation! I think this is the main requirement for _cloud computing_. -- View this message in context: http://freebsd.1045724.n5.nabble.com/cvsup-csup-servers-stale-tp5761290p5761389.html Sent from the freebsd-current mailing list archive at Nabble.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/csup servers stale?
On 11/15/2012 12:58 PM, Eitan Adler wrote: On 15 November 2012 13:47, Ian FREISLICH wrote: Hi Has the svn->cvs exporter died? Or have the cvsup/csup servers been retired as threatened in a previous thread (I might have missed the headsup)? The FreeBSD cluster is undergoing maintenance. In particular the main machines were recently physically moved, upgraded, and discombobulated. A number of services are down but we are working on fixing this as fast as possible! I want my money back! :) Upgrades are always fun. *throws his hands up and shouts "whee!!" as the rollercoaster goes up and down* No worries. :) -- Chuck Burns ___ 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/csup servers stale?
On 15 November 2012 13:47, Ian FREISLICH wrote: > Hi > > Has the svn->cvs exporter died? Or have the cvsup/csup servers > been retired as threatened in a previous thread (I might have missed > the headsup)? The FreeBSD cluster is undergoing maintenance. In particular the main machines were recently physically moved, upgraded, and discombobulated. A number of services are down but we are working on fixing this as fast as possible! -- Eitan Adler ___ 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"
cvsup/csup servers stale?
Hi Has the svn->cvs exporter died? Or have the cvsup/csup servers been retired as threatened in a previous thread (I might have missed the headsup)? Ian -- Ian Freislich ___ 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: Incorrect tag= in /usr/src/share/examples/cvsup/sta(ble|ndard) in 9.0-PRERELEASE?
On 1 December 2011 13:17, Kostik Belousov wrote: > On Thu, Dec 01, 2011 at 12:12:18PM +0300, Sergey Kandaurov wrote: >> On 1 December 2011 10:20, Milan Obuch wrote: >> > On Tue, 29 Nov 2011 19:22:39 +0300 >> > Sergey Kandaurov wrote: >> > >> >> On 29 November 2011 20:16, Maxim Khitrov wrote: >> >> > On Tue, Nov 29, 2011 at 10:30 AM, Sergey Kandaurov >> >> > wrote: >> >> >> On 26 November 2011 11:44, Milan Obuch >> >> >> wrote: >> >> >>> Hi, >> >> >>> >> >> >>> I am playing a bit with 9.0-PRERELEASE compiling it from source >> >> >>> updated via csup. In both example files there is line specifying >> >> >>> what to csup >> >> >>> >> >> >>> *default release=cvs tag=RELENG_8 >> >> >>> >> >> >>> which is incorrect, I think. It is convenient for me to issue just >> >> >>> >> >> >>> csup -h cvsup.freebsd.sk /usr/share/examples/cvsup/stable-supfile >> >> >>> >> >> >>> to update full sources without need to create any cvsup config >> >> >>> file, however in system installed from 9.0 snapshot (maybe two >> >> >>> weeks old) this file points to version 8 files, so I need to >> >> >>> correct it for 9.0-PRERELEASE to not accidentally download older >> >> >>> version sources. >> >> >>> >> >> >>> The same is also true after upgrade from source - make >> >> >>> installworld install example files pointing to older version... >> >> >>> >> >> >>> Is it something I do not know about or is it an oversight? I >> >> >>> think this line should already be changed to new tag... >> >> >>> >> >> >>> *default release=cvs tag=RELENG_9 >> >> >> >> >> >> Hi. >> >> >> >> >> >> Fixed. Thanks for your report. >> >> >> Now cvs tag points to RELENG_9 in 9.x sources. >> >> > >> >> > Should standard-supfile also be updated to point to RELENG_9_0? I'm >> >> > using csup with "tag=RELENG_9_0" and standard-supfile still points >> >> > to HEAD. >> >> >> >> Yep, sure. >> >> I just sent a request to the Release Engineering Team. >> >> >> > >> > It works for me now as expected, thanks. >> > >> > Anyway, there is a question what the difference between stable-supfile >> > and standard-supfile should be. I looked in my local csupped sources, >> > they are the same in 6-STABLE (OK, some history here), 7-STABLE, >> > 8-STABLE and 9-STABLE. Are they expected to be used differently? >> >> In STABLE branches standard-supfile and stable-supfile are used to have >> the same cvs tag. FYI, compare how it is done in RELEASE branches. >> >> > And, second one - what about CURRENT? In stable-supfile I see >> > tag=RELENG_9 which is not quite clear, but just for some pedantry... I >> > use standard-supfile for CURRENT, so this is not an issue for me either. >> >> To my knowledge, in CURRENT a standard-supfile's cvs tag should be >> read as "the latest (i.e. the most recently created) stable branch". > Could the supfiles be generated from some value in newvers.sh ? I have no idea how it could be done gracefully, sorry. But I like how it is done in www/. Here are several defined entities used elsewhere in doc&www. and so on. -- wbr, pluknet ___ 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: Incorrect tag= in /usr/src/share/examples/cvsup/sta(ble|ndard) in 9.0-PRERELEASE?
On Thu, Dec 01, 2011 at 12:12:18PM +0300, Sergey Kandaurov wrote: > On 1 December 2011 10:20, Milan Obuch wrote: > > On Tue, 29 Nov 2011 19:22:39 +0300 > > Sergey Kandaurov wrote: > > > >> On 29 November 2011 20:16, Maxim Khitrov wrote: > >> > On Tue, Nov 29, 2011 at 10:30 AM, Sergey Kandaurov > >> > wrote: > >> >> On 26 November 2011 11:44, Milan Obuch > >> >> wrote: > >> >>> Hi, > >> >>> > >> >>> I am playing a bit with 9.0-PRERELEASE compiling it from source > >> >>> updated via csup. In both example files there is line specifying > >> >>> what to csup > >> >>> > >> >>> *default release=cvs tag=RELENG_8 > >> >>> > >> >>> which is incorrect, I think. It is convenient for me to issue just > >> >>> > >> >>> csup -h cvsup.freebsd.sk /usr/share/examples/cvsup/stable-supfile > >> >>> > >> >>> to update full sources without need to create any cvsup config > >> >>> file, however in system installed from 9.0 snapshot (maybe two > >> >>> weeks old) this file points to version 8 files, so I need to > >> >>> correct it for 9.0-PRERELEASE to not accidentally download older > >> >>> version sources. > >> >>> > >> >>> The same is also true after upgrade from source - make > >> >>> installworld install example files pointing to older version... > >> >>> > >> >>> Is it something I do not know about or is it an oversight? I > >> >>> think this line should already be changed to new tag... > >> >>> > >> >>> *default release=cvs tag=RELENG_9 > >> >> > >> >> Hi. > >> >> > >> >> Fixed. Thanks for your report. > >> >> Now cvs tag points to RELENG_9 in 9.x sources. > >> > > >> > Should standard-supfile also be updated to point to RELENG_9_0? I'm > >> > using csup with "tag=RELENG_9_0" and standard-supfile still points > >> > to HEAD. > >> > >> Yep, sure. > >> I just sent a request to the Release Engineering Team. > >> > > > > It works for me now as expected, thanks. > > > > Anyway, there is a question what the difference between stable-supfile > > and standard-supfile should be. I looked in my local csupped sources, > > they are the same in 6-STABLE (OK, some history here), 7-STABLE, > > 8-STABLE and 9-STABLE. Are they expected to be used differently? > > In STABLE branches standard-supfile and stable-supfile are used to have > the same cvs tag. FYI, compare how it is done in RELEASE branches. > > > And, second one - what about CURRENT? In stable-supfile I see > > tag=RELENG_9 which is not quite clear, but just for some pedantry... I > > use standard-supfile for CURRENT, so this is not an issue for me either. > > To my knowledge, in CURRENT a standard-supfile's cvs tag should be > read as "the latest (i.e. the most recently created) stable branch". Could the supfiles be generated from some value in newvers.sh ? pgpWdpj5GwCx0.pgp Description: PGP signature
Re: Incorrect tag= in /usr/src/share/examples/cvsup/sta(ble|ndard) in 9.0-PRERELEASE?
On 1 December 2011 10:20, Milan Obuch wrote: > On Tue, 29 Nov 2011 19:22:39 +0300 > Sergey Kandaurov wrote: > >> On 29 November 2011 20:16, Maxim Khitrov wrote: >> > On Tue, Nov 29, 2011 at 10:30 AM, Sergey Kandaurov >> > wrote: >> >> On 26 November 2011 11:44, Milan Obuch >> >> wrote: >> >>> Hi, >> >>> >> >>> I am playing a bit with 9.0-PRERELEASE compiling it from source >> >>> updated via csup. In both example files there is line specifying >> >>> what to csup >> >>> >> >>> *default release=cvs tag=RELENG_8 >> >>> >> >>> which is incorrect, I think. It is convenient for me to issue just >> >>> >> >>> csup -h cvsup.freebsd.sk /usr/share/examples/cvsup/stable-supfile >> >>> >> >>> to update full sources without need to create any cvsup config >> >>> file, however in system installed from 9.0 snapshot (maybe two >> >>> weeks old) this file points to version 8 files, so I need to >> >>> correct it for 9.0-PRERELEASE to not accidentally download older >> >>> version sources. >> >>> >> >>> The same is also true after upgrade from source - make >> >>> installworld install example files pointing to older version... >> >>> >> >>> Is it something I do not know about or is it an oversight? I >> >>> think this line should already be changed to new tag... >> >>> >> >>> *default release=cvs tag=RELENG_9 >> >> >> >> Hi. >> >> >> >> Fixed. Thanks for your report. >> >> Now cvs tag points to RELENG_9 in 9.x sources. >> > >> > Should standard-supfile also be updated to point to RELENG_9_0? I'm >> > using csup with "tag=RELENG_9_0" and standard-supfile still points >> > to HEAD. >> >> Yep, sure. >> I just sent a request to the Release Engineering Team. >> > > It works for me now as expected, thanks. > > Anyway, there is a question what the difference between stable-supfile > and standard-supfile should be. I looked in my local csupped sources, > they are the same in 6-STABLE (OK, some history here), 7-STABLE, > 8-STABLE and 9-STABLE. Are they expected to be used differently? In STABLE branches standard-supfile and stable-supfile are used to have the same cvs tag. FYI, compare how it is done in RELEASE branches. > And, second one - what about CURRENT? In stable-supfile I see > tag=RELENG_9 which is not quite clear, but just for some pedantry... I > use standard-supfile for CURRENT, so this is not an issue for me either. To my knowledge, in CURRENT a standard-supfile's cvs tag should be read as "the latest (i.e. the most recently created) stable branch". -- wbr, pluknet ___ 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: Incorrect tag= in /usr/src/share/examples/cvsup/sta(ble|ndard) in 9.0-PRERELEASE?
On Tue, 29 Nov 2011 19:22:39 +0300 Sergey Kandaurov wrote: > On 29 November 2011 20:16, Maxim Khitrov wrote: > > On Tue, Nov 29, 2011 at 10:30 AM, Sergey Kandaurov > > wrote: > >> On 26 November 2011 11:44, Milan Obuch > >> wrote: > >>> Hi, > >>> > >>> I am playing a bit with 9.0-PRERELEASE compiling it from source > >>> updated via csup. In both example files there is line specifying > >>> what to csup > >>> > >>> *default release=cvs tag=RELENG_8 > >>> > >>> which is incorrect, I think. It is convenient for me to issue just > >>> > >>> csup -h cvsup.freebsd.sk /usr/share/examples/cvsup/stable-supfile > >>> > >>> to update full sources without need to create any cvsup config > >>> file, however in system installed from 9.0 snapshot (maybe two > >>> weeks old) this file points to version 8 files, so I need to > >>> correct it for 9.0-PRERELEASE to not accidentally download older > >>> version sources. > >>> > >>> The same is also true after upgrade from source - make > >>> installworld install example files pointing to older version... > >>> > >>> Is it something I do not know about or is it an oversight? I > >>> think this line should already be changed to new tag... > >>> > >>> *default release=cvs tag=RELENG_9 > >> > >> Hi. > >> > >> Fixed. Thanks for your report. > >> Now cvs tag points to RELENG_9 in 9.x sources. > > > > Should standard-supfile also be updated to point to RELENG_9_0? I'm > > using csup with "tag=RELENG_9_0" and standard-supfile still points > > to HEAD. > > Yep, sure. > I just sent a request to the Release Engineering Team. > It works for me now as expected, thanks. Anyway, there is a question what the difference between stable-supfile and standard-supfile should be. I looked in my local csupped sources, they are the same in 6-STABLE (OK, some history here), 7-STABLE, 8-STABLE and 9-STABLE. Are they expected to be used differently? And, second one - what about CURRENT? In stable-supfile I see tag=RELENG_9 which is not quite clear, but just for some pedantry... I use standard-supfile for CURRENT, so this is not an issue for me either. Regards, Milan ___ 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: Incorrect tag= in /usr/src/share/examples/cvsup/sta(ble|ndard) in 9.0-PRERELEASE?
On Tue, Nov 29, 2011 at 10:30 AM, Sergey Kandaurov wrote: > On 26 November 2011 11:44, Milan Obuch wrote: >> Hi, >> >> I am playing a bit with 9.0-PRERELEASE compiling it from source updated >> via csup. In both example files there is line specifying what to csup >> >> *default release=cvs tag=RELENG_8 >> >> which is incorrect, I think. It is convenient for me to issue just >> >> csup -h cvsup.freebsd.sk /usr/share/examples/cvsup/stable-supfile >> >> to update full sources without need to create any cvsup config file, >> however in system installed from 9.0 snapshot (maybe two weeks old) >> this file points to version 8 files, so I need to correct it for >> 9.0-PRERELEASE to not accidentally download older version sources. >> >> The same is also true after upgrade from source - make installworld >> install example files pointing to older version... >> >> Is it something I do not know about or is it an oversight? I think this >> line should already be changed to new tag... >> >> *default release=cvs tag=RELENG_9 > > Hi. > > Fixed. Thanks for your report. > Now cvs tag points to RELENG_9 in 9.x sources. Should standard-supfile also be updated to point to RELENG_9_0? I'm using csup with "tag=RELENG_9_0" and standard-supfile still points to HEAD. - Max ___ 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: Incorrect tag= in /usr/src/share/examples/cvsup/sta(ble|ndard) in 9.0-PRERELEASE?
On 29 November 2011 20:16, Maxim Khitrov wrote: > On Tue, Nov 29, 2011 at 10:30 AM, Sergey Kandaurov wrote: >> On 26 November 2011 11:44, Milan Obuch wrote: >>> Hi, >>> >>> I am playing a bit with 9.0-PRERELEASE compiling it from source updated >>> via csup. In both example files there is line specifying what to csup >>> >>> *default release=cvs tag=RELENG_8 >>> >>> which is incorrect, I think. It is convenient for me to issue just >>> >>> csup -h cvsup.freebsd.sk /usr/share/examples/cvsup/stable-supfile >>> >>> to update full sources without need to create any cvsup config file, >>> however in system installed from 9.0 snapshot (maybe two weeks old) >>> this file points to version 8 files, so I need to correct it for >>> 9.0-PRERELEASE to not accidentally download older version sources. >>> >>> The same is also true after upgrade from source - make installworld >>> install example files pointing to older version... >>> >>> Is it something I do not know about or is it an oversight? I think this >>> line should already be changed to new tag... >>> >>> *default release=cvs tag=RELENG_9 >> >> Hi. >> >> Fixed. Thanks for your report. >> Now cvs tag points to RELENG_9 in 9.x sources. > > Should standard-supfile also be updated to point to RELENG_9_0? I'm > using csup with "tag=RELENG_9_0" and standard-supfile still points to > HEAD. Yep, sure. I just sent a request to the Release Engineering Team. -- wbr, pluknet ___ 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: Incorrect tag= in /usr/src/share/examples/cvsup/sta(ble|ndard) in 9.0-PRERELEASE?
On 26 November 2011 11:44, Milan Obuch wrote: > Hi, > > I am playing a bit with 9.0-PRERELEASE compiling it from source updated > via csup. In both example files there is line specifying what to csup > > *default release=cvs tag=RELENG_8 > > which is incorrect, I think. It is convenient for me to issue just > > csup -h cvsup.freebsd.sk /usr/share/examples/cvsup/stable-supfile > > to update full sources without need to create any cvsup config file, > however in system installed from 9.0 snapshot (maybe two weeks old) > this file points to version 8 files, so I need to correct it for > 9.0-PRERELEASE to not accidentally download older version sources. > > The same is also true after upgrade from source - make installworld > install example files pointing to older version... > > Is it something I do not know about or is it an oversight? I think this > line should already be changed to new tag... > > *default release=cvs tag=RELENG_9 Hi. Fixed. Thanks for your report. Now cvs tag points to RELENG_9 in 9.x sources. -- wbr, pluknet ___ 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"
Incorrect tag= in /usr/src/share/examples/cvsup/sta(ble|ndard) in 9.0-PRERELEASE?
Hi, I am playing a bit with 9.0-PRERELEASE compiling it from source updated via csup. In both example files there is line specifying what to csup *default release=cvs tag=RELENG_8 which is incorrect, I think. It is convenient for me to issue just csup -h cvsup.freebsd.sk /usr/share/examples/cvsup/stable-supfile to update full sources without need to create any cvsup config file, however in system installed from 9.0 snapshot (maybe two weeks old) this file points to version 8 files, so I need to correct it for 9.0-PRERELEASE to not accidentally download older version sources. The same is also true after upgrade from source - make installworld install example files pointing to older version... Is it something I do not know about or is it an oversight? I think this line should already be changed to new tag... *default release=cvs tag=RELENG_9 Regards, Milan ___ 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: cvsup broken on amd64?
On Wed, Oct 05, 2011 at 03:21:45PM -0700, David O'Brien wrote:
> On Fri, Sep 09, 2011 at 06:00:02PM +0300, Kostik Belousov wrote:
> > --- libs/m3core/src/thread/POSIX/ThreadPosix.m3.orig2011-09-09
> > 17:58:12.867431639 +0300
> > +++ libs/m3core/src/thread/POSIX/ThreadPosix.m3 2011-09-09
> > 17:58:30.380428486 +0300
> > @@ -180,7 +180,7 @@
> >pausedThreads : T;
> >selected_interval:= UTime{0, 100 * 1000};
> >
> > - defaultStackSize := 3000;
> > + defaultStackSize := 1;
>
> This might not be a large enough value (depending on the unit of measure).
>
> I synced tzdata+tzcode at $WORK and we found the amount of stack used by
> tzload() alone is now quite large -- 41k on ARM.
Please see r225677.
pgpjpUkg0NdSp.pgp
Description: PGP signature
Re: cvsup broken on amd64?
> cvsup is a port, so you would need to install that to have cvsup. csup > and cvsup are totally different code bases in different languages. > (csup is C and cvsup is Modula-3.) You probably want to install cvsup > as a package as installing the port also requires building all of the > Modula-3 compiler, not a small install. > -- > R. Kevin Oberman, Network Engineer - Retired > E-mail: kob6...@gmail.com I just checked, again, directory /usr/share/examples/cvsup and was directed to the Handbook section on CVSup, A6. But I checked and found nothing with "modula" in ports; later used the search on modula-3 and found ezm3. I ran "make missing" and "make all-depends-list" in net/cvsup directory and got no dependencies in either case. No Modula-3? 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? I've heard of Modula-2 and 3, but those languages were never widely used as far as I know. Tom ___ 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 Fri, Sep 09, 2011 at 06:00:02PM +0300, Kostik Belousov wrote:
> --- libs/m3core/src/thread/POSIX/ThreadPosix.m3.orig 2011-09-09
> 17:58:12.867431639 +0300
> +++ libs/m3core/src/thread/POSIX/ThreadPosix.m3 2011-09-09
> 17:58:30.380428486 +0300
> @@ -180,7 +180,7 @@
>pausedThreads : T;
>selected_interval:= UTime{0, 100 * 1000};
>
> - defaultStackSize := 3000;
> + defaultStackSize := 1;
This might not be a large enough value (depending on the unit of measure).
I synced tzdata+tzcode at $WORK and we found the amount of stack used by
tzload() alone is now quite large -- 41k on ARM.
--
-- David (obr...@freebsd.org)
___
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 Wed, Oct 5, 2011 at 1:34 AM, Thomas Mueller wrote: >> Hi all, > >> I've committed this to -head. > >> I'd appreciate it if csup users would give this a thorough testing and >> report back to the list with results. >> I won't submit this as a merge candidate this to stable/9 without a >> whole lot of testing. :) > >> Thanks, > > >> Adrian > > I am now in 9.0-BETA2 amd64 and looking to update via source. > > There is /usr/bin/csup but no cvsup. Can I safely use csup on tag RELENG_9 > to update, or is that broken? > > Does this csup come under the cvsup bug in this thread? cvsup is a port, so you would need to install that to have cvsup. csup and cvsup are totally different code bases in different languages. (csup is C and cvsup is Modula-3.) You probably want to install cvsup as a package as installing the port also requires building all of the Modula-3 compiler, not a small install. -- R. Kevin Oberman, Network Engineer - Retired E-mail: kob6...@gmail.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?
> Hi all, > I've committed this to -head. > I'd appreciate it if csup users would give this a thorough testing and > report back to the list with results. > I won't submit this as a merge candidate this to stable/9 without a > whole lot of testing. :) > Thanks, > Adrian I am now in 9.0-BETA2 amd64 and looking to update via source. There is /usr/bin/csup but no cvsup. Can I safely use csup on tag RELENG_9 to update, or is that broken? Does this csup come under the cvsup bug in this thread? Tom ___ 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?
Hi all, I've committed this to -head. I'd appreciate it if csup users would give this a thorough testing and report back to the list with results. I won't submit this as a merge candidate this to stable/9 without a whole lot of testing. :) Thanks, Adrian ___ 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 Tue, Oct 4, 2011 at 2:19 AM, Adrian Chadd wrote: > On 4 October 2011 05:53, Maxime Henrion wrote: > >> Great, that's a relief. I knew the pthread library was free to wake a >> thread up even if it hadn't been signaled, which is why one always has >> to call pthread_cond_wait() inside of a while() loop checking for the >> condition, but wasn't sure about that particular scenario, so I'm glad >> to hear a confirmation. Thanks! > > So shall I commit your change, if someone hasn't already? That would be great (I cannot commit it myself anymore). If you could also fix the misleading comment I've been talking about (s/lister thread/detailer thread/), it would be perfect. Thanks, Maxime ___ 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 4 October 2011 05:53, Maxime Henrion wrote: > Great, that's a relief. I knew the pthread library was free to wake a > thread up even if it hadn't been signaled, which is why one always has > to call pthread_cond_wait() inside of a while() loop checking for the > condition, but wasn't sure about that particular scenario, so I'm glad > to hear a confirmation. Thanks! So shall I commit your change, if someone hasn't already? Adrian ___ 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 Mon, Oct 3, 2011 at 11:30 PM, Jilles Tjoelker wrote:
> On Mon, Oct 03, 2011 at 06:15:41PM +0200, Maxime Henrion wrote:
>> Knowing all that, what's happening seems quite clear. If
>> fixups_close() is called while there was still fixup requests pending,
>> those should be processed by the detailer thread before it returns.
>> Subsequent fixups_get() call should continue returning pending items,
>> until there are no more entries in the queue _and_ the queue is
>> closed.
>
>> So, line 144 in fixups.c (in fixups_get()):
>
>> if (f->closed) {
>
>> should actually be:
>
>> if (f->closed && f->size == 0) {
>
> That looks sensible.
>
>> The fact that this could even happen smells a bit weird to me though;
>> it means the detailer thread didn't get a chance to run between some
>> item was added to the queue (fixups_put() signals the detailer thread
>> via pthread_cond_signal()), and that it only runs now that the updater
>> queue has been closed. I wouldn't go as far as saying this is a bug,
>> but is it even valid for the pthread library to "coalesce" two
>> pthread_cond_signal() calls into one when the thread didn't get to run
>> since the first call was made? If so, then the above fix is perfectly
>> valid. If not, there is a deeper bug in the threading library, or in
>> the CVS mode code which I didn't write (but that seems far-fetched).
>
> The pthread library is free to "coalesce" pthread_cond_signal() calls
> like that. This is because a thread awakened by pthread_cond_signal()
> (or any other event) is not guaranteed to start running immediately and
> pthread_cond_signal() does nothing if there is no thread to wake up.
Great, that's a relief. I knew the pthread library was free to wake a
thread up even if it hadn't been signaled, which is why one always has
to call pthread_cond_wait() inside of a while() loop checking for the
condition, but wasn't sure about that particular scenario, so I'm glad
to hear a confirmation. Thanks!
Cheers,
Maxime
___
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 Mon, Oct 03, 2011 at 06:15:41PM +0200, Maxime Henrion wrote:
> Knowing all that, what's happening seems quite clear. If
> fixups_close() is called while there was still fixup requests pending,
> those should be processed by the detailer thread before it returns.
> Subsequent fixups_get() call should continue returning pending items,
> until there are no more entries in the queue _and_ the queue is
> closed.
> So, line 144 in fixups.c (in fixups_get()):
> if (f->closed) {
> should actually be:
> if (f->closed && f->size == 0) {
That looks sensible.
> The fact that this could even happen smells a bit weird to me though;
> it means the detailer thread didn't get a chance to run between some
> item was added to the queue (fixups_put() signals the detailer thread
> via pthread_cond_signal()), and that it only runs now that the updater
> queue has been closed. I wouldn't go as far as saying this is a bug,
> but is it even valid for the pthread library to "coalesce" two
> pthread_cond_signal() calls into one when the thread didn't get to run
> since the first call was made? If so, then the above fix is perfectly
> valid. If not, there is a deeper bug in the threading library, or in
> the CVS mode code which I didn't write (but that seems far-fetched).
The pthread library is free to "coalesce" pthread_cond_signal() calls
like that. This is because a thread awakened by pthread_cond_signal()
(or any other event) is not guaranteed to start running immediately and
pthread_cond_signal() does nothing if there is no thread to wake up.
If there is no second CPU core available to run the detailer thread, it
is more efficient to have the updater thread do some more work before
incurring a context switch.
--
Jilles Tjoelker
___
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 Mon, Sep 19, 2011 at 8:26 AM, Adrian Chadd wrote:
> 2011/9/19 Alexander Zagrebin :
>
>> I've tried this patch. Now csup "hangs" before handling fixups.
>> So there is no message "Applying fixups..." at all.
>
> Wow. Hm. Where's the author when one needs them..
Well that's quite a strange coincidence. I haven't read current@ in
ages and now I just stumble upon this. :-)
It's been a long time since I've been looking at this code but the
patch from the original PR seems /nearly/ correct, while the one from
adrian@ is definitely incorrect. But to be honest, this part of the
CVSup protocol is a lot more twisted than it would seem, plus a
comment of mine was definitely misleading (it should say that the
detailer thread will hang, not the lister one). Here are some
explanations that should help clarify things.
When the updater thread encountered a problem in updating a file (MD5
checksum doesn't match), it will send a fixup "request" to the
detailer thread. The detailer thread then sends this request to the
CVSup server, which, finally, sends the whole file for the _updater_
thread to receive. So what's happening at this position in the code is
that the updater thread finished processing all the "normal" updates,
and thus knows there won't be any more fixup requests (fixups
themselves can't generate other fixups). This is why it closes the
writing end of the fixups queue, to wake up the detailer thread which
will notice the closed state and the absence of fixups in the queue,
and will thus terminate. So we _have_ to call fixups_close() here, or
the detailer thread will block indefinitely in fixups_get() when an
error happened.
Knowing all that, what's happening seems quite clear. If
fixups_close() is called while there was still fixup requests pending,
those should be processed by the detailer thread before it returns.
Subsequent fixups_get() call should continue returning pending items,
until there are no more entries in the queue _and_ the queue is
closed.
So, line 144 in fixups.c (in fixups_get()):
if (f->closed) {
should actually be:
if (f->closed && f->size == 0) {
The fact that this could even happen smells a bit weird to me though;
it means the detailer thread didn't get a chance to run between some
item was added to the queue (fixups_put() signals the detailer thread
via pthread_cond_signal()), and that it only runs now that the updater
queue has been closed. I wouldn't go as far as saying this is a bug,
but is it even valid for the pthread library to "coalesce" two
pthread_cond_signal() calls into one when the thread didn't get to run
since the first call was made? If so, then the above fix is perfectly
valid. If not, there is a deeper bug in the threading library, or in
the CVS mode code which I didn't write (but that seems far-fetched).
It would be great to fix my misleading comment too by the way :-)
I hope this helps.
Cheers,
Maxime
___
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?
2011/9/19 Alexander Zagrebin : > I've tried this patch. Now csup "hangs" before handling fixups. > So there is no message "Applying fixups..." at all. Wow. Hm. Where's the author when one needs them.. Adrian ___ 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?
Hi!
> So I've taken a look at the csup source.
>
> The problem here is the updater thread setting the "closed" state
> (fixups_closed()) before calling updater_batch() again to handle
> fixups.
>
> Checking for size != 0 at that point may not be valid at the list size
> may actually be 0 for a short period of time.
>
> What about this patch:
>
> Index: updater.c
> ===
> --- updater.c (revision 224905)
> +++ updater.c (working copy)
> @@ -240,9 +240,9 @@
> * Make sure to close the fixups even in case of an error,
> * so that the lister thread doesn't block indefinitely.
> */
> - fixups_close(up->config->fixups);
> if (!error)
> error = updater_batch(up, 1);
> + fixups_close(up->config->fixups);
> switch (error) {
> case UPDATER_ERR_PROTO:
> xasprintf(&args->errmsg, "Updater failed:
> Protocol error");
I've tried this patch. Now csup "hangs" before handling fixups.
So there is no message "Applying fixups..." at all.
--
Alexander Zagrebin
___
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 Sun, Sep 18, 2011 at 02:46:24PM +0200, Oliver Lehmann wrote: > > Kostik Belousov wrote: > > >Did you saw the message with the patch for tzcode I mailed to you ? > > Mmmh... no didn't reached my mailbox - can you resend it please? See the "Segfault in libthr.so on 9.0-BETA2 (with stunnel FWIW)" thread on the current@, where you are explicitely Cc:ed. I posted updated patch a minute ago. pgpbmqafpbDxl.pgp Description: PGP signature
Re: cvsup broken on amd64?
Kostik Belousov wrote: Did you saw the message with the patch for tzcode I mailed to you ? Mmmh... no didn't reached my mailbox - can you resend it please? ___ 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?
Ah, you're the one with the csup problem.
Would you mind trying csup again, and if it doesn't work, try this patch:
Index: updater.c
===
--- updater.c (revision 224905)
+++ updater.c (working copy)
@@ -240,9 +240,9 @@
* Make sure to close the fixups even in case of an error,
* so that the lister thread doesn't block indefinitely.
*/
- fixups_close(up->config->fixups);
if (!error)
error = updater_batch(up, 1);
+ fixups_close(up->config->fixups);
switch (error) {
case UPDATER_ERR_PROTO:
xasprintf(&args->errmsg, "Updater failed: Protocol error");
There's a PR open now (154954) but the patch may be wrong.
thanks,
Adrian
___
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 Sun, Sep 18, 2011 at 12:22:53PM +0200, Oliver Lehmann wrote: > > Adrian Chadd wrote: > > >So I've taken a look at the csup source. > > > >[...] > > > >What about this patch: > > > >[...] > > > >Oliver, would you please try that? > > I have a problem with cvsup, not csup - Alexander mentioned a csup problem. Did you saw the message with the patch for tzcode I mailed to you ? pgpxG7jeO8J6E.pgp Description: PGP signature
Re: cvsup broken on amd64?
Adrian Chadd wrote: So I've taken a look at the csup source. [...] What about this patch: [...] Oliver, would you please try that? I have a problem with cvsup, not csup - Alexander mentioned a csup problem. ___ 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?
Hi,
So I've taken a look at the csup source.
The problem here is the updater thread setting the "closed" state
(fixups_closed()) before calling updater_batch() again to handle
fixups.
Checking for size != 0 at that point may not be valid at the list size
may actually be 0 for a short period of time.
What about this patch:
Index: updater.c
===
--- updater.c (revision 224905)
+++ updater.c (working copy)
@@ -240,9 +240,9 @@
* Make sure to close the fixups even in case of an error,
* so that the lister thread doesn't block indefinitely.
*/
- fixups_close(up->config->fixups);
if (!error)
error = updater_batch(up, 1);
+ fixups_close(up->config->fixups);
switch (error) {
case UPDATER_ERR_PROTO:
xasprintf(&args->errmsg, "Updater failed: Protocol error");
Oliver, would you please try that?
Thanks,
Adrian
___
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 Thu, Sep 15, 2011 at 9:30 AM, Garrett Cooper wrote: > On Thu, Sep 15, 2011 at 8:19 AM, Adrian Chadd wrote: >> On 15 September 2011 18:05, Mark Linimon wrote: >>>> Usually rather quite later than sooner. >>> >>> A perfect opportunity for src committers to dive in and make a >>> difference :-) >> >> I hate you. :) >> >> Ok. Some third person test/verify that this patch (a) does what it's >> supposed to do, and (b) is correct, and I'll commit it. >> >> (blah, what am I signing myself up for..) > > Based on the ticket and the patch, I think this is the right > procedure for verifying the patch. Please verify that the case below > repros the issue seen by the end-user before applying the patch though > :). > Thanks, > -Garrett > > supdir=$(mktemp -d /tmp/sup.XX) > # Supfile follows. Change cvsup host as necessary.. > cat >$supdir/supfile < *default host=cvsup10.FreeBSD.org > *default base=$supdir > *default prefix=$supdir/checkout > *default release=cvs > *default delete use-rel-suffix > *default compress > src-all > EOF > # Get the sources > csup $supdir/supfile > # Empty out the files > for i in $(find $supdir/supfile/sys -name '*.[ch]'); do This should be $supdir/checkout/sys . Thanks, -Garrett ___ 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 Thu, Sep 15, 2011 at 8:19 AM, Adrian Chadd wrote: > On 15 September 2011 18:05, Mark Linimon wrote: >>> Usually rather quite later than sooner. >> >> A perfect opportunity for src committers to dive in and make a >> difference :-) > > I hate you. :) > > Ok. Some third person test/verify that this patch (a) does what it's > supposed to do, and (b) is correct, and I'll commit it. > > (blah, what am I signing myself up for..) Based on the ticket and the patch, I think this is the right procedure for verifying the patch. Please verify that the case below repros the issue seen by the end-user before applying the patch though :). Thanks, -Garrett supdir=$(mktemp -d /tmp/sup.XX) # Supfile follows. Change cvsup host as necessary.. cat >$supdir/supfile < $i done # This should fail, requiring multiple tries. csup $supdir/supfile # Clean up rm -Rf $supdir ___ 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 15 September 2011 18:05, Mark Linimon wrote: >> Usually rather quite later than sooner. > > A perfect opportunity for src committers to dive in and make a > difference :-) I hate you. :) Ok. Some third person test/verify that this patch (a) does what it's supposed to do, and (b) is correct, and I'll commit it. (blah, what am I signing myself up for..) Adrian ___ 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?
> Usually rather quite later than sooner. A perfect opportunity for src committers to dive in and make a difference :-) mcl ___ 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 15/09/2011 12:16 Alexander Zagrebin said the following: >> Pester the maintainer? > > I've thought that if an opened PR exists, then it have to be > reviewed sooner or later... > Usually rather quite later than sooner. There are about 5000 non-ports PRs and there are only a few dozen active developers. -- Andriy Gapon ___ 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?
> Pester the maintainer? I've thought that if an opened PR exists, then it have to be reviewed sooner or later... -- Alexander Zagrebin ___ 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 Wed, Sep 14, 2011 at 11:19 PM, Adrian Chadd wrote: > Pester the maintainer? The maintainer is alumni. -Garrett ___ 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?
Pester the maintainer? Adrian 2011/9/15 Alexander Zagrebin : >> I'm also using cvsup again, due to a problem I had with csup >> back in February >> 2011 >> <http://www.mail-archive.com/freebsd-stable@freebsd.org/msg114 >> 813.html> . >> >> I didn't open a PR; I was under some time pressure and cvsup worked. > > There is a solution of the csup problem: > http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/154954 > I've opened this PR, but nobody has paid to it attentions. :( > > -- > Alexander Zagrebin > > ___ > 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" > ___ 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?
> I'm also using cvsup again, due to a problem I had with csup > back in February > 2011 > <http://www.mail-archive.com/freebsd-stable@freebsd.org/msg114 > 813.html> . > > I didn't open a PR; I was under some time pressure and cvsup worked. There is a solution of the csup problem: http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/154954 I've opened this PR, but nobody has paid to it attentions. :( -- Alexander Zagrebin ___ 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 Fri, 09 Sep 2011 13:47:37 +0200 Oliver Lehmann wrote: > > Kostik Belousov wrote: > > > For start, you should provide the information what exactly is the > > instruction that caused the fault. Show the disassembly from gdb > > for the function that caused the fault. > > Ok, I'm trying. I recompiled cvsup for purpose with -DSTATIC > > How do I continue from the gdb output below to help? > > nudel# gdb > GNU gdb 6.1.1 [FreeBSD] > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you are > welcome to change it and/or distribute copies of it under certain conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for details. > This GDB was configured as "amd64-marcel-freebsd". > (gdb) file ./client/FBSD_AMD64/cvsup > Reading symbols from ./client/FBSD_AMD64/cvsup...done. > (gdb) exec-file ./client/FBSD_AMD64/cvsup > (gdb) set args -g /usr/share/examples/cvsup/9-supfile > (gdb) run > Starting program: > /usr/obj/amd64/usr/ports/net/cvsup-without-gui/work/cvsup-snap-16.1h/client/FBSD_AMD64/cvsup > -g > /usr/share/examples/cvsup/9-supfile > Connected to cvsup.de.FreeBSD.org > Updating collection src-all/cvs > Edit src/crypto/openssl/ssl/s3_lib.c > > Program received signal SIGSEGV, Segmentation fault. > 0x004d24c6 in tzload () > [snip] Ah yes, I've seen this before. I don't know whether it's till the case, but my fix at the time (about 1 year ago) was to delete /usr/share/zoneinfo/UTC. I don't know whether that's even still installed. I know, it's just a work around and not a real fix. -- Gary Jennejohn ___ 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 09/08/11 14:52, b. f. wrote: I have an Atom 330 with 9.0-BETA2/amd64 installed. I did a pkg_add -r cvsup-without-gui at first after installation. Using cvsup, resulted in a core dump (illegal instruction). I then removed all ports, and installed cvsup-without-gui from source. Started cvsup... core dump again. I then got the cvsup binary from a FreeBSD 8 i386 system, installed compat8x and also copied the missing libutil.so.8 from FreeBSD/i386 and cvsuped the source (8.2-STABLE i386 cvsup worked). Then I rebuilt world, kernel (removed all debugging options from GENERIC). Then I removed all ports once more and reinstalled cvsup-without-gui from ports once more. And now again... It may be broken -- I seem to recall some earlier complaints about problems on one of the list. But is there a reason why you are attempting to use it, when /usr/bin/csup is available, and is generally thought to be superior? b. ___ 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" Does cvsup work for anyone? At what point should cvsup just be a symlink to csup? ___ 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?
Kostik Belousov wrote: On Fri, Sep 09, 2011 at 06:20:57PM +0200, Oliver Lehmann wrote: (gdb) run Starting program: /usr/obj/amd64/usr/ports/net/cvsup-without-gui/work/cvsup-snap-16.1h/client/FBSD_AMD64/cvsup -g /usr/share/examples/cvsup/9-supfile Connected to cvsup.de.FreeBSD.org Updating collection src-all/cvs Edit src/crypto/openssl/ssl/s3_lib.c Program received signal SIGSEGV, Segmentation fault. 0x004d24c6 in tzload () (gdb) I need the same information from the gdb for this crash too, with cvsup rebuilt using the patched ezm3. Mh... looks like the same output to me (gdb) info registers $rsp rsp0x916c98 0x916c98 (gdb) info program Using the running image of child process 62191. Program stopped at 0x4d24c6. It stopped with signal SIGSEGV, Segmentation fault. (gdb) nudel# procstat -v 62191 PID STARTEND PRT RES PRES REF SHD FL TP PATH 62191 0x40 0x53f000 r-x 2180 1 0 C- vn /usr/obj/amd64/usr/ports/net/cvsup-without-gui/work/cvsup-snap-16.1h/client/FBSD_AMD64/cvsup 62191 0x73f000 0x7bf000 rw- 930 1 0 C- vn /usr/obj/amd64/usr/ports/net/cvsup-without-gui/work/cvsup-snap-16.1h/client/FBSD_AMD64/cvsup 62191 0x7bf000 0x844000 rw- 1190 15 0 -- df 62191 0x844000 0x845000 r--10 15 0 -- df 62191 0x845000 0x867000 rw- 340 15 0 -- df 62191 0x867000 0x868000 r--10 15 0 -- df 62191 0x868000 0x88a000 rw- 340 15 0 -- df 62191 0x88a000 0x88b000 r--10 15 0 -- df 62191 0x88b000 0x8ad000 rw- 340 15 0 -- df 62191 0x8ad000 0x8ae000 r--10 15 0 -- df 62191 0x8ae000 0x8d rw- 340 15 0 -- df 62191 0x8d 0x8d1000 r--10 15 0 -- df 62191 0x8d1000 0x8f3000 rw- 340 15 0 -- df 62191 0x8f3000 0x8f4000 r--10 15 0 -- df 62191 0x8f4000 0x916000 rw- 340 15 0 -- df 62191 0x916000 0x917000 r--10 15 0 -- df 62191 0x917000 0xa87000 rw- 3440 15 0 -- df 621910x800740x800743000 rw-20 1 0 -- df 621910x8007430000x800751000 r-- 120 1 0 -- vn /mnt/files/FreeBSD/9.0/src/crypto/openssl/ssl/s3_lib.c 62191 0x7ffbf000 0x7ffdf000 rwx10 1 0 -- df 62191 0x7ffdf000 0x7000 rwx 110 1 0 -- df 62191 0x7000 0x8000 r-x10 50 0 CN ph nudel# ___ 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 Fri, Sep 09, 2011 at 06:20:57PM +0200, Oliver Lehmann wrote: > > Kostik Belousov wrote: > > >On Fri, Sep 09, 2011 at 05:55:13PM +0300, Kostik Belousov wrote: > > >>Ok, please do the following: > >>run cvsup under the gdb. When SIGSEGV is raised, from the gdb prompt, do: > >>1. info registers $rsp > >>2. info program > >>This should print you the pid of the process, then do > >>3. shell procstat -v > > (gdb) run > Starting program: > /usr/obj/amd64/usr/ports/net/cvsup-without-gui/work/cvsup-snap-16.1h/client/FBSD_AMD64/cvsup > -g > /usr/share/examples/cvsup/9-supfile > Connected to cvsup.de.FreeBSD.org > Updating collection src-all/cvs > Edit src/crypto/openssl/ssl/s3_lib.c > > Program received signal SIGSEGV, Segmentation fault. > 0x004d24c6 in tzload () > (gdb) info registers $rsp > rsp0x916c98 0x916c98 > (gdb) info program > Using the running image of child process 14704. > Program stopped at 0x4d24c6. > It stopped with signal SIGSEGV, Segmentation fault. > (gdb) > > nudel# procstat -v 14704 > PID STARTEND PRT RES PRES REF SHD FL TP PATH > 14704 0x40 0x53f000 r-x 2190 1 0 C- > vn > /usr/obj/amd64/usr/ports/net/cvsup-without-gui/work/cvsup-snap-16.1h/client/FBSD_AMD64/cvsup > 14704 0x73f000 0x7bf000 rw- 1280 1 0 C- > vn > /usr/obj/amd64/usr/ports/net/cvsup-without-gui/work/cvsup-snap-16.1h/client/FBSD_AMD64/cvsup > 14704 0x7bf000 0x844000 rw- 1190 15 0 -- df > 14704 0x844000 0x845000 r--10 15 0 -- df > 14704 0x845000 0x867000 rw- 340 15 0 -- df > 14704 0x867000 0x868000 r--10 15 0 -- df > 14704 0x868000 0x88a000 rw- 340 15 0 -- df > 14704 0x88a000 0x88b000 r--10 15 0 -- df > 14704 0x88b000 0x8ad000 rw- 340 15 0 -- df > 14704 0x8ad000 0x8ae000 r--10 15 0 -- df > 14704 0x8ae000 0x8d rw- 340 15 0 -- df > 14704 0x8d 0x8d1000 r--10 15 0 -- df > 14704 0x8d1000 0x8f3000 rw- 340 15 0 -- df > 14704 0x8f3000 0x8f4000 r--10 15 0 -- df > 14704 0x8f4000 0x916000 rw- 340 15 0 -- df > 14704 0x916000 0x917000 r--10 15 0 -- df > 14704 0x917000 0xa87000 rw- 3440 15 0 -- df %rsp value is 0x917000, so this is definitely stack overflow. > 147040x800740x800743000 rw-20 1 0 -- df > 147040x8007430000x800751000 r-- 120 1 0 -- > vn /mnt/files/FreeBSD/9.0/src/crypto/openssl/ssl/s3_lib.c > 14704 0x7ffbf000 0x7ffdf000 rwx10 1 0 -- df > 14704 0x7ffdf000 0x7000 rwx 110 1 0 -- df > 14704 0x7000 0x8000 r-x10 47 0 CN ph > nudel# > > > >Also, you might try to test my guesswork, by adding the following > >patch to lang/ezm3 and rebuilding it, then rebuilding cvsup port: > > [made a file below ezm3/files, cleaned the workdir, reinstalled it > cleaned cvsup, rebuilt it] > > no change so far > > (gdb) run > Starting program: > /usr/obj/amd64/usr/ports/net/cvsup-without-gui/work/cvsup-snap-16.1h/client/FBSD_AMD64/cvsup > -g > /usr/share/examples/cvsup/9-supfile > Connected to cvsup.de.FreeBSD.org > Updating collection src-all/cvs > Edit src/crypto/openssl/ssl/s3_lib.c > > Program received signal SIGSEGV, Segmentation fault. > 0x004d24c6 in tzload () > (gdb) I need the same information from the gdb for this crash too, with cvsup rebuilt using the patched ezm3. pgpjB33Vzig07.pgp Description: PGP signature
Re: cvsup broken on amd64?
Kostik Belousov wrote: On Fri, Sep 09, 2011 at 05:55:13PM +0300, Kostik Belousov wrote: Ok, please do the following: run cvsup under the gdb. When SIGSEGV is raised, from the gdb prompt, do: 1. info registers $rsp 2. info program This should print you the pid of the process, then do 3. shell procstat -v (gdb) run Starting program: /usr/obj/amd64/usr/ports/net/cvsup-without-gui/work/cvsup-snap-16.1h/client/FBSD_AMD64/cvsup -g /usr/share/examples/cvsup/9-supfile Connected to cvsup.de.FreeBSD.org Updating collection src-all/cvs Edit src/crypto/openssl/ssl/s3_lib.c Program received signal SIGSEGV, Segmentation fault. 0x004d24c6 in tzload () (gdb) info registers $rsp rsp0x916c98 0x916c98 (gdb) info program Using the running image of child process 14704. Program stopped at 0x4d24c6. It stopped with signal SIGSEGV, Segmentation fault. (gdb) nudel# procstat -v 14704 PID STARTEND PRT RES PRES REF SHD FL TP PATH 14704 0x40 0x53f000 r-x 2190 1 0 C- vn /usr/obj/amd64/usr/ports/net/cvsup-without-gui/work/cvsup-snap-16.1h/client/FBSD_AMD64/cvsup 14704 0x73f000 0x7bf000 rw- 1280 1 0 C- vn /usr/obj/amd64/usr/ports/net/cvsup-without-gui/work/cvsup-snap-16.1h/client/FBSD_AMD64/cvsup 14704 0x7bf000 0x844000 rw- 1190 15 0 -- df 14704 0x844000 0x845000 r--10 15 0 -- df 14704 0x845000 0x867000 rw- 340 15 0 -- df 14704 0x867000 0x868000 r--10 15 0 -- df 14704 0x868000 0x88a000 rw- 340 15 0 -- df 14704 0x88a000 0x88b000 r--10 15 0 -- df 14704 0x88b000 0x8ad000 rw- 340 15 0 -- df 14704 0x8ad000 0x8ae000 r--10 15 0 -- df 14704 0x8ae000 0x8d rw- 340 15 0 -- df 14704 0x8d 0x8d1000 r--10 15 0 -- df 14704 0x8d1000 0x8f3000 rw- 340 15 0 -- df 14704 0x8f3000 0x8f4000 r--10 15 0 -- df 14704 0x8f4000 0x916000 rw- 340 15 0 -- df 14704 0x916000 0x917000 r--10 15 0 -- df 14704 0x917000 0xa87000 rw- 3440 15 0 -- df 147040x800740x800743000 rw-20 1 0 -- df 147040x8007430000x800751000 r-- 120 1 0 -- vn /mnt/files/FreeBSD/9.0/src/crypto/openssl/ssl/s3_lib.c 14704 0x7ffbf000 0x7ffdf000 rwx10 1 0 -- df 14704 0x7ffdf000 0x7000 rwx 110 1 0 -- df 14704 0x7000 0x8000 r-x10 47 0 CN ph nudel# Also, you might try to test my guesswork, by adding the following patch to lang/ezm3 and rebuilding it, then rebuilding cvsup port: [made a file below ezm3/files, cleaned the workdir, reinstalled it cleaned cvsup, rebuilt it] no change so far (gdb) run Starting program: /usr/obj/amd64/usr/ports/net/cvsup-without-gui/work/cvsup-snap-16.1h/client/FBSD_AMD64/cvsup -g /usr/share/examples/cvsup/9-supfile Connected to cvsup.de.FreeBSD.org Updating collection src-all/cvs Edit src/crypto/openssl/ssl/s3_lib.c Program received signal SIGSEGV, Segmentation fault. 0x004d24c6 in tzload () (gdb) ___ 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 Fri, Sep 09, 2011 at 05:55:13PM +0300, Kostik Belousov wrote:
> On Fri, Sep 09, 2011 at 04:34:54PM +0200, Oliver Lehmann wrote:
> >
> > Kostik Belousov wrote:
> >
> > >On Fri, Sep 09, 2011 at 04:19:42PM +0200, Oliver Lehmann wrote:
> >
> > >>(gdb) bt
> > >>#0 0x004d24c6 in tzload ()
> > >
> > >Try to do "disas 0x4d24c6 0x4d24c6+30" from gdb prompt with the loaded
> > >core.
> >
> > (gdb) disas 0x4d24c6 0x4d24c6+30
> > Dump of assembler code from 0x4d24c6 to 0x4d24e4:
> > 0x004d24c6 : callq 0x4db370
> > 0x004d24cb : test %eax,%eax
> > 0x004d24cd : jne0x4d25e0
> > 0x004d24d3 : movzbl (%rbx),%ebp
> > 0x004d24d6 :cmp$0x3a,%bpl
> > 0x004d24da :jne0x4d24e3
> > 0x004d24dc :add$0x1,%rbx
> > 0x004d24e0 :movzbl (%rbx),%ebp
> > 0x004d24e3 :cmp$0x2f,%bpl
> > End of assembler dump.
>
> Ok, please do the following:
> run cvsup under the gdb. When SIGSEGV is raised, from the gdb prompt, do:
> 1. info registers $rsp
> 2. info program
> This should print you the pid of the process, then do
> 3. shell procstat -v
>
> I suspect that modula 3 system uses the kind of green threads, and
> the default thread stack size is simply too small for amd64. This is
> consistent with SIGILL when running standalone, but SIGSEGV under
> debugger.
Also, you might try to test my guesswork, by adding the following
patch to lang/ezm3 and rebuilding it, then rebuilding cvsup port:
--- libs/m3core/src/thread/POSIX/ThreadPosix.m3.orig2011-09-09
17:58:12.867431639 +0300
+++ libs/m3core/src/thread/POSIX/ThreadPosix.m3 2011-09-09 17:58:30.380428486
+0300
@@ -180,7 +180,7 @@
pausedThreads : T;
selected_interval:= UTime{0, 100 * 1000};
- defaultStackSize := 3000;
+ defaultStackSize := 1;
stack_grows_down: BOOLEAN;
pgpf3Qfd6XtRX.pgp
Description: PGP signature
Re: cvsup broken on amd64?
On Fri, Sep 09, 2011 at 04:34:54PM +0200, Oliver Lehmann wrote: > > Kostik Belousov wrote: > > >On Fri, Sep 09, 2011 at 04:19:42PM +0200, Oliver Lehmann wrote: > > >>(gdb) bt > >>#0 0x004d24c6 in tzload () > > > >Try to do "disas 0x4d24c6 0x4d24c6+30" from gdb prompt with the loaded > >core. > > (gdb) disas 0x4d24c6 0x4d24c6+30 > Dump of assembler code from 0x4d24c6 to 0x4d24e4: > 0x004d24c6 : callq 0x4db370 > 0x004d24cb : test %eax,%eax > 0x004d24cd : jne0x4d25e0 > 0x004d24d3 : movzbl (%rbx),%ebp > 0x004d24d6 :cmp$0x3a,%bpl > 0x004d24da :jne0x4d24e3 > 0x004d24dc :add$0x1,%rbx > 0x004d24e0 :movzbl (%rbx),%ebp > 0x0000004d24e3 :cmp$0x2f,%bpl > End of assembler dump. Ok, please do the following: run cvsup under the gdb. When SIGSEGV is raised, from the gdb prompt, do: 1. info registers $rsp 2. info program This should print you the pid of the process, then do 3. shell procstat -v I suspect that modula 3 system uses the kind of green threads, and the default thread stack size is simply too small for amd64. This is consistent with SIGILL when running standalone, but SIGSEGV under debugger. pgpNkNsofaEKD.pgp Description: PGP signature
Re: cvsup broken on amd64?
Kostik Belousov wrote: On Fri, Sep 09, 2011 at 04:19:42PM +0200, Oliver Lehmann wrote: (gdb) bt #0 0x004d24c6 in tzload () Try to do "disas 0x4d24c6 0x4d24c6+30" from gdb prompt with the loaded core. (gdb) disas 0x4d24c6 0x4d24c6+30 Dump of assembler code from 0x4d24c6 to 0x4d24e4: 0x004d24c6 : callq 0x4db370 0x004d24cb : test %eax,%eax 0x004d24cd : jne0x4d25e0 0x004d24d3 : movzbl (%rbx),%ebp 0x004d24d6 :cmp$0x3a,%bpl 0x004d24da :jne0x4d24e3 0x004d24dc :add$0x1,%rbx 0x004d24e0 :movzbl (%rbx),%ebp 0x004d24e3 :cmp$0x2f,%bpl End of assembler dump. ___ 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 Fri, Sep 09, 2011 at 04:19:42PM +0200, Oliver Lehmann wrote: > > Kostik Belousov wrote: > > >I do not know, I was curious about 'illegal instruction' signal, > >which would indicate a problem in the compilation environment. > >Now you get segmentation violation, that is usually caused by a bug in > >the program itself. > > running it outside gdb still results in an 'illegal instruction' error. > Why it gets to "segmentation violation" inside gdb I just don't know. > > nudel# ./client/FBSD_AMD64/cvsup -g /usr/share/examples/cvsup/9-supfile > Connected to cvsup.de.FreeBSD.org > Updating collection src-all/cvs > Edit src/crypto/openssl/ssl/s3_lib.c > Illegal instruction (core dumped) > nudel# gdb ./client/FBSD_AMD64/cvsup cvsup.core > GNU gdb 6.1.1 [FreeBSD] > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you are > welcome to change it and/or distribute copies of it under certain > conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for details. > This GDB was configured as "amd64-marcel-freebsd"... > Core was generated by `cvsup'. > Program terminated with signal 4, Illegal instruction. > #0 0x004d24c6 in tzload () > (gdb) bt > #0 0x004d24c6 in tzload () Try to do "disas 0x4d24c6 0x4d24c6+30" from gdb prompt with the loaded core. pgpz3aHMHVkEn.pgp Description: PGP signature
Re: cvsup broken on amd64?
Kostik Belousov wrote: I do not know, I was curious about 'illegal instruction' signal, which would indicate a problem in the compilation environment. Now you get segmentation violation, that is usually caused by a bug in the program itself. running it outside gdb still results in an 'illegal instruction' error. Why it gets to "segmentation violation" inside gdb I just don't know. nudel# ./client/FBSD_AMD64/cvsup -g /usr/share/examples/cvsup/9-supfile Connected to cvsup.de.FreeBSD.org Updating collection src-all/cvs Edit src/crypto/openssl/ssl/s3_lib.c Illegal instruction (core dumped) nudel# gdb ./client/FBSD_AMD64/cvsup cvsup.core GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"... Core was generated by `cvsup'. Program terminated with signal 4, Illegal instruction. #0 0x004d24c6 in tzload () (gdb) bt #0 0x004d24c6 in tzload () #1 0x004d1f89 in tzparse () #2 0x004d2c27 in tzload () #3 0x004d2e36 in gmtload () #4 0x004eac15 in _once () #5 0x004d1c8b in gmtsub () #6 0x004d33e9 in gmtime () #7 0x004a3d4a in Date__FromTime (M3_CtKayy_t=1314794791, M3_Ab1PrR_z=0x7ed538, M3_D5xROs__result=0x934c08) at DateBsd.m3:31 #8 0x004387d7 in RCSDate__FromTime (M3_CtKayy_t=1314794791) at RCSDate.m3:54 #9 0x004467ba in RCSFile__Import (M3_Bd56fi_p=0x9d9008, M3_Bd56fi_revNum=0x9d87c8, M3_Bd56fi_author=0x763020, M3_Bd56fi_state=0x763040, M3_AcxOUs_logLines=12) at RCSFile.m3:413 #10 0x004077de in CheckoutUpdater__Update (M3_CTVCUv_self=0x9d8980, M3_CzVV2w_sfr=0x7ff2e0, M3_Bd56fi_name=0x9d8788, M3_AicXUJ_toAttic=0 '\0', M3_DsoVVS_proto=0x7f74a8, M3_AeHwgK_trace=0x7f8710, M3_EkTcCb_protoRd=0x9d05b8, M3_BxxOH1_wr=0x9d8e98, M3_AQMw24_status=0x935f48) at CheckoutUpdater.m3:111 #11 0x00416ab4 in Updater__UpdateFile (M3_DBUV6k_self=0x7fee38, M3_CzVV2w_sfr=0x7ff2e0, M3_Bd56fi_name=0x9d8788, M3_AicXUJ_toAttic=0 '\0', M3_DMoNGc_fup=0x9d8980, M3_AicXUJ_isFixup=0 '\0') at Updater.m3:641 #12 0x004155ce in Updater__UpdateCollection (M3_DBUV6k_self=0x7fee38, M3_CzVV2w_sfr=0x7ff2e0, M3_AicXUJ_isFixups=0 '\0') at Updater.m3:458 #13 0x00412baf in Updater__UpdateBatch (M3_DBUV6k_self=0x7fee38, M3_AicXUJ_isFixups=0 '\0') at Updater.m3:151 #14 0x0041268a in Updater__Apply (M3_DBUV6k_self=0x7fee38) at Updater.m3:90 #15 0x0049d290 in ThreadPosix__DetermineContext (M3_AJWxb1_oldSP=0x7edfd0) at ThreadPosix.m3:1127 #16 0x0048d34d in RTCollector__LongAlloc (M3_Cwb5VA_dataSize=4337239, M3_Cwb5VA_dataAlignment=8577024, M3_AOtCKl_currentPtr=0x7f8, M3_AOtCKl_currentBoundary=0x76c8f8, M3_CCsHD8_currentPage=0x0, M3_CCsHD8_stack=0x0, M3_D8qd0n_allocMode=144 '\220', M3_AicXUJ_pure=120 'x') at RTCollector.m3:1530 #17 0x7fffc428 in ?? () #18 0x7fffd990 in ?? () #19 0x7fffda78 in ?? () #20 0x7fffda58 in ?? () #21 0x in ?? () #22 0x in ?? () #23 0x1fa0037f in ?? () #24 0x in ?? () #25 0x007f76c0 in ?? () #26 0x007f76c0 in ?? () #27 0x00492699 in RTMisc__Copy (M3_AJWxb1_src=Cannot access memory at address 0xfffb ) at RTMisc.m3:19 Previous frame inner to this frame (corrupt stack?) (gdb) ___ 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 09/09/11 01:33, Oliver Lehmann wrote: Mike Tancsa wrote: Just curious as to why you need cvsup and not instead use csup that is in the base ? I got used to it in the past 12 years? But this is not realy the question. If it is "BROKEN" it should be marked as BROKEN or there should be a statement that it will not work with FreeBSD 9 on at least amd64 or we will have other users complaining about the same at least when 9.0 RELEASE is out - right? I'm also using cvsup again, due to a problem I had with csup back in February 2011 <http://www.mail-archive.com/freebsd-stable@freebsd.org/msg114813.html> . I didn't open a PR; I was under some time pressure and cvsup worked. - Richard -- Richard Kuhns My Desk: 765-269-8541 Wintek Corporation Internet Support: 765-269-8503 427 N 6th Street STE C Consulting: 765-269-8504 Lafayette, IN 47901-2211 Accounting: 765-269-8502 ___ 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 Fri, Sep 09, 2011 at 01:47:37PM +0200, Oliver Lehmann wrote: > > Kostik Belousov wrote: > > >For start, you should provide the information what exactly is the > >instruction that caused the fault. Show the disassembly from gdb > >for the function that caused the fault. > > Ok, I'm trying. I recompiled cvsup for purpose with -DSTATIC > > How do I continue from the gdb output below to help? I do not know, I was curious about 'illegal instruction' signal, which would indicate a problem in the compilation environment. Now you get segmentation violation, that is usually caused by a bug in the program itself. > > nudel# gdb > GNU gdb 6.1.1 [FreeBSD] > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you are > welcome to change it and/or distribute copies of it under certain > conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for details. > This GDB was configured as "amd64-marcel-freebsd". > (gdb) file ./client/FBSD_AMD64/cvsup > Reading symbols from ./client/FBSD_AMD64/cvsup...done. > (gdb) exec-file ./client/FBSD_AMD64/cvsup > (gdb) set args -g /usr/share/examples/cvsup/9-supfile > (gdb) run > Starting program: > /usr/obj/amd64/usr/ports/net/cvsup-without-gui/work/cvsup-snap-16.1h/client/FBSD_AMD64/cvsup > -g > /usr/share/examples/cvsup/9-supfile > Connected to cvsup.de.FreeBSD.org > Updating collection src-all/cvs > Edit src/crypto/openssl/ssl/s3_lib.c > > Program received signal SIGSEGV, Segmentation fault. > 0x004d24c6 in tzload () > (gdb) bt > #0 0x004d24c6 in tzload () > #1 0x004d1f89 in tzparse () > #2 0x004d2c27 in tzload () > #3 0x004d2e36 in gmtload () > #4 0x004eac15 in _once () > #5 0x004d1c8b in gmtsub () > #6 0x004d33e9 in gmtime () > #7 0x004a3d4a in Date__FromTime (M3_CtKayy_t=1314794791, > M3_Ab1PrR_z=0x7ed538, M3_D5xROs__result=0x934c08) at DateBsd.m3:31 > #8 0x004387d7 in RCSDate__FromTime (M3_CtKayy_t=1314794791) > at RCSDate.m3:54 > #9 0x004467ba in RCSFile__Import (M3_Bd56fi_p=0xa74040, > M3_Bd56fi_revNum=0x9f4828, M3_Bd56fi_author=0x763020, > M3_Bd56fi_state=0x763040, > M3_AcxOUs_logLines=12) at RCSFile.m3:413 > #10 0x004077de in CheckoutUpdater__Update > (M3_CTVCUv_self=0x9f49e0, M3_CzVV2w_sfr=0x7ff2e0, > M3_Bd56fi_name=0x9f47e8, M3_AicXUJ_toAttic=0 '\0', > M3_DsoVVS_proto=0x7f74a8, M3_AeHwgK_trace=0x7f8710, > M3_EkTcCb_protoRd=0x9c98f8, M3_BxxOH1_wr=0x9f4ef8, > M3_AQMw24_status=0x935f48) > at CheckoutUpdater.m3:111 > #11 0x00416ab4 in Updater__UpdateFile > (M3_DBUV6k_self=0x7fee38, M3_CzVV2w_sfr=0x7ff2e0, > M3_Bd56fi_name=0x9f47e8, M3_AicXUJ_toAttic=0 '\0', > M3_DMoNGc_fup=0x9f49e0, M3_AicXUJ_isFixup=0 '\0') at Updater.m3:641 > #12 0x004155ce in Updater__UpdateCollection > (M3_DBUV6k_self=0x7fee38, M3_CzVV2w_sfr=0x7ff2e0, M3_AicXUJ_isFixups=0 > '\0') at Updater.m3:458 > #13 0x00412baf in Updater__UpdateBatch > (M3_DBUV6k_self=0x7fee38, M3_AicXUJ_isFixups=0 '\0') at Updater.m3:151 > #14 0x0041268a in Updater__Apply (M3_DBUV6k_self=0x7fee38) at > Updater.m3:90 > #15 0x0049d290 in ThreadPosix__DetermineContext > (M3_AJWxb1_oldSP=0x7edfd0) at ThreadPosix.m3:1127 > #16 0x0048d34d in RTCollector__LongAlloc > (M3_Cwb5VA_dataSize=4337239, M3_Cwb5VA_dataAlignment=8577024, > M3_AOtCKl_currentPtr=0x7f8, > M3_AOtCKl_currentBoundary=0x76c8f8, M3_CCsHD8_currentPage=0x0, > M3_CCsHD8_stack=0x0, M3_D8qd0n_allocMode=48 '0', M3_AicXUJ_pure=16 > '\020') > at RTCollector.m3:1530 > #17 0x7fffc3c8 in ?? () > #18 0x7fffd930 in ?? () > #19 0x7fffda10 in ?? () > #20 0x7fffd9f0 in ?? () > #21 0x in ?? () > #22 0x in ?? () > #23 0x1fa0037f in ?? () > #24 0x in ?? () > #25 0x007f76c0 in ?? () > #26 0x007f76c0 in ?? () > #27 0x00492699 in RTMisc__Copy (M3_AJWxb1_src=Error accessing > memory address 0xfffb: Bad address. > ) at RTMisc.m3:19 > Previous frame inner to this frame (corrupt stack?) > (gdb) > > > RTMisc.m3:19 is > > PROCEDURE Copy (src, dest: ADDRESS; len: INTEGER) = > BEGIN > EVAL Cstring.memcpy (dest, src, len); > END Copy; pgp2QJtgOP9FU.pgp Description: PGP signature
Re: cvsup broken on amd64?
Kostik Belousov wrote: For start, you should provide the information what exactly is the instruction that caused the fault. Show the disassembly from gdb for the function that caused the fault. Ok, I'm trying. I recompiled cvsup for purpose with -DSTATIC How do I continue from the gdb output below to help? nudel# gdb GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd". (gdb) file ./client/FBSD_AMD64/cvsup Reading symbols from ./client/FBSD_AMD64/cvsup...done. (gdb) exec-file ./client/FBSD_AMD64/cvsup (gdb) set args -g /usr/share/examples/cvsup/9-supfile (gdb) run Starting program: /usr/obj/amd64/usr/ports/net/cvsup-without-gui/work/cvsup-snap-16.1h/client/FBSD_AMD64/cvsup -g /usr/share/examples/cvsup/9-supfile Connected to cvsup.de.FreeBSD.org Updating collection src-all/cvs Edit src/crypto/openssl/ssl/s3_lib.c Program received signal SIGSEGV, Segmentation fault. 0x004d24c6 in tzload () (gdb) bt #0 0x004d24c6 in tzload () #1 0x004d1f89 in tzparse () #2 0x004d2c27 in tzload () #3 0x004d2e36 in gmtload () #4 0x004eac15 in _once () #5 0x004d1c8b in gmtsub () #6 0x004d33e9 in gmtime () #7 0x004a3d4a in Date__FromTime (M3_CtKayy_t=1314794791, M3_Ab1PrR_z=0x7ed538, M3_D5xROs__result=0x934c08) at DateBsd.m3:31 #8 0x004387d7 in RCSDate__FromTime (M3_CtKayy_t=1314794791) at RCSDate.m3:54 #9 0x004467ba in RCSFile__Import (M3_Bd56fi_p=0xa74040, M3_Bd56fi_revNum=0x9f4828, M3_Bd56fi_author=0x763020, M3_Bd56fi_state=0x763040, M3_AcxOUs_logLines=12) at RCSFile.m3:413 #10 0x004077de in CheckoutUpdater__Update (M3_CTVCUv_self=0x9f49e0, M3_CzVV2w_sfr=0x7ff2e0, M3_Bd56fi_name=0x9f47e8, M3_AicXUJ_toAttic=0 '\0', M3_DsoVVS_proto=0x7f74a8, M3_AeHwgK_trace=0x7f8710, M3_EkTcCb_protoRd=0x9c98f8, M3_BxxOH1_wr=0x9f4ef8, M3_AQMw24_status=0x935f48) at CheckoutUpdater.m3:111 #11 0x00416ab4 in Updater__UpdateFile (M3_DBUV6k_self=0x7fee38, M3_CzVV2w_sfr=0x7ff2e0, M3_Bd56fi_name=0x9f47e8, M3_AicXUJ_toAttic=0 '\0', M3_DMoNGc_fup=0x9f49e0, M3_AicXUJ_isFixup=0 '\0') at Updater.m3:641 #12 0x004155ce in Updater__UpdateCollection (M3_DBUV6k_self=0x7fee38, M3_CzVV2w_sfr=0x7ff2e0, M3_AicXUJ_isFixups=0 '\0') at Updater.m3:458 #13 0x00412baf in Updater__UpdateBatch (M3_DBUV6k_self=0x7fee38, M3_AicXUJ_isFixups=0 '\0') at Updater.m3:151 #14 0x0041268a in Updater__Apply (M3_DBUV6k_self=0x7fee38) at Updater.m3:90 #15 0x0049d290 in ThreadPosix__DetermineContext (M3_AJWxb1_oldSP=0x7edfd0) at ThreadPosix.m3:1127 #16 0x0048d34d in RTCollector__LongAlloc (M3_Cwb5VA_dataSize=4337239, M3_Cwb5VA_dataAlignment=8577024, M3_AOtCKl_currentPtr=0x7f8, M3_AOtCKl_currentBoundary=0x76c8f8, M3_CCsHD8_currentPage=0x0, M3_CCsHD8_stack=0x0, M3_D8qd0n_allocMode=48 '0', M3_AicXUJ_pure=16 '\020') at RTCollector.m3:1530 #17 0x7fffc3c8 in ?? () #18 0x7fffd930 in ?? () #19 0x7fffda10 in ?? () #20 0x7fffd9f0 in ?? () #21 0x in ?? () #22 0x in ?? () #23 0x1fa0037f in ?? () #24 0x in ?? () #25 0x007f76c0 in ?? () #26 0x007f76c0 in ?? () #27 0x00492699 in RTMisc__Copy (M3_AJWxb1_src=Error accessing memory address 0xfffb: Bad address. ) at RTMisc.m3:19 Previous frame inner to this frame (corrupt stack?) (gdb) RTMisc.m3:19 is PROCEDURE Copy (src, dest: ADDRESS; len: INTEGER) = BEGIN EVAL Cstring.memcpy (dest, src, len); END Copy; ___ 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 Fri, Sep 09, 2011 at 11:30:46AM +0200, Oliver Lehmann wrote: > > Chris Rees wrote: > > >On 9 September 2011 06:33, Oliver Lehmann wrote: > >>I got used to it in the past 12 years? But this is not realy the question. > >>If it is "BROKEN" it should be marked as BROKEN or there should be a > >>statement that it will not work with FreeBSD 9 on at least amd64 or we > >>will have other users complaining about the same at least when > >>9.0 RELEASE is out - right? > > > >The cvsup port is normally used now only for cvsupd, for which there > >is no csupd analog. As far as I know, and perhaps mux (CC'd) could > >confirm every feature present in cvsup is present in csup-- and it's a > >fair amount faster too. > > Ok, but this again is not the point of my email ;) > This is not about "just me". I know how to help me in that case. I want > to prevent users facing the same problem and writing mails like my initial > mail. > I'm quiet sure that there are numerous users out there still using cvsup > as client so they will start like me with cvsup on ther new instaled system. > It would be better if they just would not be able to install cvsup if it > will not run and we don't want it to run. > I was also curious if it is only me where it fails on amd64 or if it is > because it was compiled on an Atom 330 with some amd64 flags determined by > the system which does not fit the Atom 330 (gcc 4.2 is older than the CPU > design). > With other words: If the support for cvsup on amd64 is dropped, it has > to be marked as BROKEN/IGNORE/whatever. Otherwise it need to get fixed for > 9.0? For start, you should provide the information what exactly is the instruction that caused the fault. Show the disassembly from gdb for the function that caused the fault. pgpNzY8kGtDDW.pgp Description: PGP signature
Re: cvsup broken on amd64?
Chris Rees wrote: On 9 September 2011 06:33, Oliver Lehmann wrote: I got used to it in the past 12 years? But this is not realy the question. If it is "BROKEN" it should be marked as BROKEN or there should be a statement that it will not work with FreeBSD 9 on at least amd64 or we will have other users complaining about the same at least when 9.0 RELEASE is out - right? The cvsup port is normally used now only for cvsupd, for which there is no csupd analog. As far as I know, and perhaps mux (CC'd) could confirm every feature present in cvsup is present in csup-- and it's a fair amount faster too. Ok, but this again is not the point of my email ;) This is not about "just me". I know how to help me in that case. I want to prevent users facing the same problem and writing mails like my initial mail. I'm quiet sure that there are numerous users out there still using cvsup as client so they will start like me with cvsup on ther new instaled system. It would be better if they just would not be able to install cvsup if it will not run and we don't want it to run. I was also curious if it is only me where it fails on amd64 or if it is because it was compiled on an Atom 330 with some amd64 flags determined by the system which does not fit the Atom 330 (gcc 4.2 is older than the CPU design). With other words: If the support for cvsup on amd64 is dropped, it has to be marked as BROKEN/IGNORE/whatever. Otherwise it need to get fixed for 9.0? ___ 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 9 September 2011 06:33, Oliver Lehmann wrote: > > Mike Tancsa wrote: > >> Just curious as to why you need cvsup and not instead use csup that is >> in the base ? > > I got used to it in the past 12 years? But this is not realy the question. > If it is "BROKEN" it should be marked as BROKEN or there should be a > statement that it will not work with FreeBSD 9 on at least amd64 or we > will have other users complaining about the same at least when > 9.0 RELEASE is out - right? The cvsup port is normally used now only for cvsupd, for which there is no csupd analog. As far as I know, and perhaps mux (CC'd) could confirm every feature present in cvsup is present in csup-- and it's a fair amount faster too. Of course, cvsup could probably do with fixing, but for now csup is literally a drop-in replacement; it'll read all your supfiles too. Chris ___ 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?
Mike Tancsa wrote: Just curious as to why you need cvsup and not instead use csup that is in the base ? I got used to it in the past 12 years? But this is not realy the question. If it is "BROKEN" it should be marked as BROKEN or there should be a statement that it will not work with FreeBSD 9 on at least amd64 or we will have other users complaining about the same at least when 9.0 RELEASE is out - right? ___ 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?
> I have an Atom 330 with 9.0-BETA2/amd64 installed. > > I did a pkg_add -r cvsup-without-gui at first after installation. > Using cvsup, resulted in a core dump (illegal instruction). > > I then removed all ports, and installed cvsup-without-gui from source. > Started cvsup... core dump again. > > I then got the cvsup binary from a FreeBSD 8 i386 system, installed > compat8x and also copied the missing libutil.so.8 from FreeBSD/i386 > and cvsuped the source (8.2-STABLE i386 cvsup worked). > > Then I rebuilt world, kernel (removed all debugging options from GENERIC). > > Then I removed all ports once more and reinstalled cvsup-without-gui > from ports once more. > > And now again... It may be broken -- I seem to recall some earlier complaints about problems on one of the list. But is there a reason why you are attempting to use it, when /usr/bin/csup is available, and is generally thought to be superior? b. ___ 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"
cvsup broken on amd64?
Hi,
I have an Atom 330 with 9.0-BETA2/amd64 installed.
I did a pkg_add -r cvsup-without-gui at first after installation.
Using cvsup, resulted in a core dump (illegal instruction).
I then removed all ports, and installed cvsup-without-gui from source.
Started cvsup... core dump again.
I then got the cvsup binary from a FreeBSD 8 i386 system, installed
compat8x and also copied the missing libutil.so.8 from FreeBSD/i386
and cvsuped the source (8.2-STABLE i386 cvsup worked).
Then I rebuilt world, kernel (removed all debugging options from GENERIC).
Then I removed all ports once more and reinstalled cvsup-without-gui
from ports once more.
And now again...
nudel# cvsup -g /usr/share/examples/cvsup/9-supfile
Connected to cvsup.de.FreeBSD.org
Updating collection src-all/cvs
Edit src/crypto/openssl/ssl/s3_lib.c
Illegal instruction (core dumped)
nudel# gdb /usr/local/bin/cvsup cvsup.core
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "amd64-marcel-freebsd"...(no debugging
symbols found)...
Core was generated by `cvsup'.
Program terminated with signal 4, Illegal instruction.
Reading symbols from /lib/libz.so.6...(no debugging symbols found)...done.
Loaded symbols for /lib/libz.so.6
Reading symbols from /lib/libm.so.5...(no debugging symbols found)...done.
Loaded symbols for /lib/libm.so.5
Reading symbols from /lib/libc.so.7...(no debugging symbols found)...done.
Loaded symbols for /lib/libc.so.7
Reading symbols from /libexec/ld-elf.so.1...(no debugging symbols
found)...done.
Loaded symbols for /libexec/ld-elf.so.1
#0 0x000800e12359 in gmtime_r () from /lib/libc.so.7
(gdb) bt
#0 0x000800e12359 in gmtime_r () from /lib/libc.so.7
#1 0x000800e11dde in gmtime_r () from /lib/libc.so.7
#2 0x000800e12ab4 in gmtime_r () from /lib/libc.so.7
#3 0x000800e12cc8 in gmtime_r () from /lib/libc.so.7
#4 0x000800e30928 in sysctl () from /lib/libc.so.7
#5 0x000800e11a9f in timegm () from /lib/libc.so.7
#6 0x000800e13346 in gmtime () from /lib/libc.so.7
#7 0x004a63aa in calloc ()
#8 0x0043ae3b in ?? ()
#9 0x00448e1e in ?? ()
#10 0x00409e42 in ?? ()
#11 0x00419118 in ?? ()
#12 0x00417c32 in ?? ()
#13 0x00415213 in ?? ()
#14 0x00414cee in ?? ()
#15 0x0049f8f0 in calloc ()
#16 0x0048f9ad in fnmatch ()
#17 0x7fffc498 in ?? ()
#18 0x7fffda00 in ?? ()
#19 0x7fffdaf8 in ?? ()
#20 0x7fffdad8 in ?? ()
#21 0x in ?? ()
#22 0x in ?? ()
#23 0x1fa0037f in ?? ()
#24 0x in ?? ()
#25 0x0074c6c0 in ?? ()
#26 0x0074c6c0 in ?? ()
#27 0x00494cf9 in fnmatch ()
Previous frame inner to this frame (corrupt stack?)
(gdb)
cat /etc/make.conf
X_WINDOW_SYSTEM=xorg
WRKDIRPREFIX=/usr/obj/${MACHINE_ARCH}
head -7 /usr/share/examples/cvsup/9-supfile
*default host=cvsup.de.FreeBSD.org
*default base=/mnt/files/FreeBSD/9.0
*default prefix=/mnt/files/FreeBSD/9.0
*default release=cvs tag=.
*default delete use-rel-suffix
*default compress
src-all
___
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: Problems with cvsup on FreeBSD 9, AMD64, osreldate: 900038
On 07/03/2011 03:51 PM, Stephen Montgomery-Smith wrote: On 07/02/2011 10:25 PM, jhell wrote: Use csup(1) in base. This is in 7, 8& 9. cvsup has been deprecated for much longer than it really needed to be and should probably be removed from use as a client entirely and links generated for installation of cvsup -> csup. Only drawback for you may be no X interface but it really was not that pretty in the first place and served no real good purpose over the functionality of the command line client. Another drawback to csup is that csup doesn't seem to recognize the .cvsup/auth file. At least not on FreeBSD 7 of a few months ago. I run CTM generation, and I need access to cvsup-master. My mistake. I found that in FreeBSD-CURRENT that csup does recognize .csup/auth. Any timetable on when this will by MFCed to FreeBSD 7 and 8? Incidentally, csup needs the following diff applied, so that I can continue to use "FreeBSD" in my auth file: 195c195 <if (strcmp(auth->server, server) != 0) --- >if (strcasecmp(auth->server, server) != 0) I'll file a PR. ___ 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: Problems with cvsup on FreeBSD 9, AMD64, osreldate: 900038
On 07/02/2011 10:25 PM, jhell wrote: Use csup(1) in base. This is in 7, 8& 9. cvsup has been deprecated for much longer than it really needed to be and should probably be removed from use as a client entirely and links generated for installation of cvsup -> csup. Only drawback for you may be no X interface but it really was not that pretty in the first place and served no real good purpose over the functionality of the command line client. Another drawback to csup is that csup doesn't seem to recognize the .cvsup/auth file. At least not on FreeBSD 7 of a few months ago. I run CTM generation, and I need access to cvsup-master. ___ 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: Problems with cvsup on FreeBSD 9, AMD64, osreldate: 900038
On 03/07/2011 04:25, jhell wrote: On Sat, Jul 02, 2011 at 04:33:39PM +0100, Vassilis Laganakos wrote: Hello, I am facing the same problems as Holger here: http://lists.freebsd.org/pipermail/freebsd-current/2011-June/025205.html although CVSup dies in gmtime_r in libc.so.7: ... Updating collection src-all/cvs Edit src/UPDATING Program received signal SIGSEGV, Segmentation fault. 0x2ca10fb9 in gmtime_r () from /lib/libc.so.7 ... See full gdb backtrace at: http://www.pastie.org/pastes/2154271 So I'm now stuck in osrel 900038... I guess I need to rebuild libc.so.7 with debugging symbols to find out what is going wrong there. Any quick ideas on how to correct this, or if someone else is seeing this issue? Use csup(1) in base. This is in 7, 8& 9. cvsup has been deprecated for much longer than it really needed to be and should probably be removed from use as a client entirely and links generated for installation of cvsup -> csup. Oh, I wasn't aware of that. csup worked sweet, thanks! So I'll remove the cvsup port and switch to using csup. Only drawback for you may be no X interface but it really was not that pretty in the first place and served no real good purpose over the functionality of the command line client. An alternative if you need and X interface is creating a icon on your desktop that runs ( xterm -e csup /path/to/supfile ) or something similiar. Ok. I haven't been using the X interface, and I agree it hasn't been that great. Thanks for the information! Vassilis L. ___ 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: Problems with cvsup on FreeBSD 9, AMD64, osreldate: 900038
On 02/07/2011 17:54, Kurt Jaeger wrote: Hi! Any quick ideas on how to correct this, or if someone else is seeing this issue? Does csup work ? Yeah! That works! I see that csups is part of the build system. So is this to replace the cvsup port? Thanks, Vassilis L. ___ 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: Problems with cvsup on FreeBSD 9, AMD64, osreldate: 900038
On 02/07/2011 17:07, Garrett Cooper wrote: On Sat, Jul 2, 2011 at 8:33 AM, Vassilis Laganakos wrote: Hello, I am facing the same problems as Holger here: http://lists.freebsd.org/pipermail/freebsd-current/2011-June/025205.html although CVSup dies in gmtime_r in libc.so.7: ... Updating collection src-all/cvs Edit src/UPDATING Program received signal SIGSEGV, Segmentation fault. 0x2ca10fb9 in gmtime_r () from /lib/libc.so.7 ... See full gdb backtrace at: http://www.pastie.org/pastes/2154271 So I'm now stuck in osrel 900038... I guess I need to rebuild libc.so.7 with debugging symbols to find out what is going wrong there. Any quick ideas on how to correct this, or if someone else is seeing this issue? Have you tried recompiling cvsup and all of its dependencies? > Yeah, I rebuilt every port installed with "pormaster -dBfa", hoping that that would correct it, but that gave the same behaviour. Thanks, Vassilis L. ___ 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 servers broken?
Gavin Atkinson wrote: > On Sat, 2 Jul 2011, Ian FREISLICH wrote: > > Matt wrote: > > > On 07/01/11 09:34, Ian FREISLICH wrote: > > > > It looks like the server is just exiting. I've tested cvsup4 and > > > > cvsup5 as well. Is cvsup deprecated these days or has something > > > > else broken it? > > > > > > > Try csup instead of cvsup...I've found it works better. Any possibility > > > of network issues? > > > > csup gets into an infinite loop near the end of the ports tree and > > starts growing in memory consumption. I killed it after it grew > > to about 500M resident. The following is a ktrace snippet after > > it stalls: > > > > 75390 csup RET ioctl -1 errno 25 Inappropriate ioctl for device > > 75390 csup CALL ioctl(0x4,TIOCGETA,0xbf5fac60) > > 75390 csup RET ioctl -1 errno 25 Inappropriate ioctl for device > > 75390 csup CALL ioctl(0x4,TIOCGETA,0xbf5fac60) > > 75390 csup RET ioctl -1 errno 25 Inappropriate ioctl for device > > 75390 csup CALL ioctl(0x4,TIOCGETA,0xbf5fac60) > > 75390 csup RET ioctl -1 errno 25 Inappropriate ioctl for device > > 75390 csup CALL ioctl(0x4,TIOCGETA,0xbf5fac60) > > 75390 csup RET ioctl -1 errno 25 Inappropriate ioctl for device > > 75390 csup CALL ioctl(0x4,TIOCGETA,0xbf5fac60) > > > > The first part of csup's stack trace. It appears to be corrupted > > with several null frames, and is very, very deep. > > > > (gdb) bt > > #0 0x2832c1f3 in ioctl () from /lib/libc.so.7 > > #1 0x2832bdbc in tcgetattr () from /lib/libc.so.7 > > #2 0x2832b7ea in isatty () from /lib/libc.so.7 > > #3 0x08051832 in fnmatch () > > #4 0x08051906 in fnmatch () > > #5 0x08052135 in fnmatch () > > #6 0x08059c19 in fnmatch () > > #7 0x08059a76 in fnmatch () > > #8 0x0804c1ff in ?? () > > #9 0x28c11380 in ?? () > > #10 0x2845f402 in ?? () > > > > [mini] /usr/home/ianf # procstat -f 75390 > > PID COMM FD T V FLAGSREF OFFSET PRO NAME > > 75390 csup text v r r--- - - - /usr/bin/csup > > 75390 csup ctty v c rw-- - - - /dev/pts/1 > > 75390 csup cwd v d r--- - - - /usr/src > > 75390 csup root v d r--- - - - / > > 75390 csup0 v c rw-- 14 10464115 - /dev/pts/1 > > 75390 csup1 v c rw-- 14 10464115 - /dev/pts/1 > > 75390 csup2 v c rw-- 14 10464115 - /dev/pts/1 > > 75390 csup3 s - rw-- 2 0 TCP 10.0.2.67:19238 12 8.205.32.24:5999 > > 75390 csup4 v r r--- 1 0 - /usr/home/ncvs/por ts/x11/wbar/Makefile,v > > 75390 csup5 v r r--- 11023 - /var/db/sup/ports- all/checkouts > > 75390 csup6 v r r--- 1 24492073 - /var/db/sup/ports -all/checkouts > > 75390 csup7 v r -w-- 1 24491389 - /var/db/sup/ports -all/#cvs.csup-75390.0 > > > > filedescriptor 4's directory listing: > > > > [mini] /usr/home/ncvs/ports/x11/wbar # ls -la > > total 24 > > drwxr-xr-x3 root wheel512 Jul 1 07:21 . > > drwxr-xr-x 694 root wheel 14848 Jun 28 16:29 .. > > -r--r--r--1 root wheel 0 Feb 8 22:51 Makefile,v > > -r--r--r-- 1 root wheel 0 Mar 19 14:38 distinfo,v > > drwxr-xr-x2 root wheel512 Jul 1 07:21 files > > -r--r--r--1 root wheel 0 Feb 8 22:51 pkg-descr,v > > -r--r--r--1 root wheel 0 Feb 8 22:51 pkg-plist,v > > > > After removing the zero sized files, csup continued until it hit > > x11-toolkits/Makefile,v and then ports/x11-wm/Makefile,v which was > > also zero sized. Having deleted all the zero files, both cvsup and > > csup complete their run. > > I don't think you'll get much interest in fixing cvsup, but if you can > recreate this at will with csup and haven't had a response in a few days, > could you please submit a PR? This debugging above was with csup. cvsup would cause the remote to exit (hence the RST). csup would just consume all RAM and CPU when it encounters an empty ,v file. Ian -- Ian Freislich ___ 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 servers broken?
On Sat, 2 Jul 2011, Ian FREISLICH wrote: > Matt wrote: > > On 07/01/11 09:34, Ian FREISLICH wrote: > > > It looks like the server is just exiting. I've tested cvsup4 and > > > cvsup5 as well. Is cvsup deprecated these days or has something > > > else broken it? > > > > > Try csup instead of cvsup...I've found it works better. Any possibility > > of network issues? > > csup gets into an infinite loop near the end of the ports tree and > starts growing in memory consumption. I killed it after it grew > to about 500M resident. The following is a ktrace snippet after > it stalls: > > 75390 csup RET ioctl -1 errno 25 Inappropriate ioctl for device > 75390 csup CALL ioctl(0x4,TIOCGETA,0xbf5fac60) > 75390 csup RET ioctl -1 errno 25 Inappropriate ioctl for device > 75390 csup CALL ioctl(0x4,TIOCGETA,0xbf5fac60) > 75390 csup RET ioctl -1 errno 25 Inappropriate ioctl for device > 75390 csup CALL ioctl(0x4,TIOCGETA,0xbf5fac60) > 75390 csup RET ioctl -1 errno 25 Inappropriate ioctl for device > 75390 csup CALL ioctl(0x4,TIOCGETA,0xbf5fac60) > 75390 csup RET ioctl -1 errno 25 Inappropriate ioctl for device > 75390 csup CALL ioctl(0x4,TIOCGETA,0xbf5fac60) > > The first part of csup's stack trace. It appears to be corrupted > with several null frames, and is very, very deep. > > (gdb) bt > #0 0x2832c1f3 in ioctl () from /lib/libc.so.7 > #1 0x2832bdbc in tcgetattr () from /lib/libc.so.7 > #2 0x2832b7ea in isatty () from /lib/libc.so.7 > #3 0x08051832 in fnmatch () > #4 0x08051906 in fnmatch () > #5 0x08052135 in fnmatch () > #6 0x08059c19 in fnmatch () > #7 0x08059a76 in fnmatch () > #8 0x0804c1ff in ?? () > #9 0x28c11380 in ?? () > #10 0x2845f402 in ?? () > > [mini] /usr/home/ianf # procstat -f 75390 > PID COMM FD T V FLAGSREF OFFSET PRO NAME > 75390 csup text v r r--- - - - /usr/bin/csup > 75390 csup ctty v c rw-- - - - /dev/pts/1 > 75390 csup cwd v d r--- - - - /usr/src > 75390 csup root v d r--- - - - / > 75390 csup0 v c rw-- 14 10464115 - /dev/pts/1 > 75390 csup1 v c rw-- 14 10464115 - /dev/pts/1 > 75390 csup2 v c rw-- 14 10464115 - /dev/pts/1 > 75390 csup3 s - rw-- 2 0 TCP 10.0.2.67:19238 > 128.205.32.24:5999 > 75390 csup4 v r r--- 1 0 - > /usr/home/ncvs/ports/x11/wbar/Makefile,v > 75390 csup5 v r r--- 11023 - > /var/db/sup/ports-all/checkouts > 75390 csup6 v r r--- 1 24492073 - > /var/db/sup/ports-all/checkouts > 75390 csup7 v r -w-- 1 24491389 - > /var/db/sup/ports-all/#cvs.csup-75390.0 > > filedescriptor 4's directory listing: > > [mini] /usr/home/ncvs/ports/x11/wbar # ls -la > total 24 > drwxr-xr-x3 root wheel512 Jul 1 07:21 . > drwxr-xr-x 694 root wheel 14848 Jun 28 16:29 .. > -r--r--r--1 root wheel 0 Feb 8 22:51 Makefile,v > -r--r--r--1 root wheel 0 Mar 19 14:38 distinfo,v > drwxr-xr-x2 root wheel512 Jul 1 07:21 files > -r--r--r--1 root wheel 0 Feb 8 22:51 pkg-descr,v > -r--r--r--1 root wheel 0 Feb 8 22:51 pkg-plist,v > > After removing the zero sized files, csup continued until it hit > x11-toolkits/Makefile,v and then ports/x11-wm/Makefile,v which was > also zero sized. Having deleted all the zero files, both cvsup and > csup complete their run. I don't think you'll get much interest in fixing cvsup, but if you can recreate this at will with csup and haven't had a response in a few days, could you please submit a PR? Thanks, Gavin ___ 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"
Problems with cvsup on FreeBSD 9, AMD64, osreldate: 900038
Hello, I am facing the same problems as Holger here: http://lists.freebsd.org/pipermail/freebsd-current/2011-June/025205.html although CVSup dies in gmtime_r in libc.so.7: ... Updating collection src-all/cvs Edit src/UPDATING Program received signal SIGSEGV, Segmentation fault. 0x2ca10fb9 in gmtime_r () from /lib/libc.so.7 ... See full gdb backtrace at: http://www.pastie.org/pastes/2154271 So I'm now stuck in osrel 900038... I guess I need to rebuild libc.so.7 with debugging symbols to find out what is going wrong there. Any quick ideas on how to correct this, or if someone else is seeing this issue? Thanks, Vassilis L. ___ 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 servers broken?
Matt wrote: > On 07/01/11 09:34, Ian FREISLICH wrote: > > It looks like the server is just exiting. I've tested cvsup4 and > > cvsup5 as well. Is cvsup deprecated these days or has something > > else broken it? > > > Try csup instead of cvsup...I've found it works better. Any possibility > of network issues? csup gets into an infinite loop near the end of the ports tree and starts growing in memory consumption. I killed it after it grew to about 500M resident. The following is a ktrace snippet after it stalls: 75390 csup RET ioctl -1 errno 25 Inappropriate ioctl for device 75390 csup CALL ioctl(0x4,TIOCGETA,0xbf5fac60) 75390 csup RET ioctl -1 errno 25 Inappropriate ioctl for device 75390 csup CALL ioctl(0x4,TIOCGETA,0xbf5fac60) 75390 csup RET ioctl -1 errno 25 Inappropriate ioctl for device 75390 csup CALL ioctl(0x4,TIOCGETA,0xbf5fac60) 75390 csup RET ioctl -1 errno 25 Inappropriate ioctl for device 75390 csup CALL ioctl(0x4,TIOCGETA,0xbf5fac60) 75390 csup RET ioctl -1 errno 25 Inappropriate ioctl for device 75390 csup CALL ioctl(0x4,TIOCGETA,0xbf5fac60) The first part of csup's stack trace. It appears to be corrupted with several null frames, and is very, very deep. (gdb) bt #0 0x2832c1f3 in ioctl () from /lib/libc.so.7 #1 0x2832bdbc in tcgetattr () from /lib/libc.so.7 #2 0x2832b7ea in isatty () from /lib/libc.so.7 #3 0x08051832 in fnmatch () #4 0x08051906 in fnmatch () #5 0x08052135 in fnmatch () #6 0x08059c19 in fnmatch () #7 0x08059a76 in fnmatch () #8 0x0804c1ff in ?? () #9 0x28c11380 in ?? () #10 0x2845f402 in ?? () [mini] /usr/home/ianf # procstat -f 75390 PID COMM FD T V FLAGSREF OFFSET PRO NAME 75390 csup text v r r--- - - - /usr/bin/csup 75390 csup ctty v c rw-- - - - /dev/pts/1 75390 csup cwd v d r--- - - - /usr/src 75390 csup root v d r--- - - - / 75390 csup0 v c rw-- 14 10464115 - /dev/pts/1 75390 csup1 v c rw-- 14 10464115 - /dev/pts/1 75390 csup2 v c rw-- 14 10464115 - /dev/pts/1 75390 csup3 s - rw-- 2 0 TCP 10.0.2.67:19238 128.205.32.24:5999 75390 csup4 v r r--- 1 0 - /usr/home/ncvs/ports/x11/wbar/Makefile,v 75390 csup5 v r r--- 11023 - /var/db/sup/ports-all/checkouts 75390 csup6 v r r--- 1 24492073 - /var/db/sup/ports-all/checkouts 75390 csup7 v r -w-- 1 24491389 - /var/db/sup/ports-all/#cvs.csup-75390.0 filedescriptor 4's directory listing: [mini] /usr/home/ncvs/ports/x11/wbar # ls -la total 24 drwxr-xr-x3 root wheel512 Jul 1 07:21 . drwxr-xr-x 694 root wheel 14848 Jun 28 16:29 .. -r--r--r--1 root wheel 0 Feb 8 22:51 Makefile,v -r--r--r--1 root wheel 0 Mar 19 14:38 distinfo,v drwxr-xr-x2 root wheel512 Jul 1 07:21 files -r--r--r--1 root wheel 0 Feb 8 22:51 pkg-descr,v -r--r--r--1 root wheel 0 Feb 8 22:51 pkg-plist,v After removing the zero sized files, csup continued until it hit x11-toolkits/Makefile,v and then ports/x11-wm/Makefile,v which was also zero sized. Having deleted all the zero files, both cvsup and csup complete their run. So, why does it fail so absurdly on this condition? Ian -- Ian Freislich ___ 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 servers broken?
On 07/01/11 09:34, Ian FREISLICH wrote: Hi I've been seeing this all day: # cvsup -L2 /root/supfile-cvs Parsing supfile "/root/supfile-cvs" Connecting to cvsup6.freebsd.org Connected to cvsup6.freebsd.org Server software version: SNAP_16_1h Negotiating file attribute support Exchanging collection information Establishing multiplexed-mode data connection Running Updating collection cvsroot-common/cvs Updating collection src-all/cvs Updating collection ports-all/cvs Detailer failed: Premature EOF from server Will retry at 18:32:04 Which coincides with: (Timestamps UTC+0200) 18:27:12.004603 IP 41.154.88.19.52564> 128.205.32.24.5999: Flags [.], ack 102802, win 8225, options [nop,nop,TS val 3651903 ecr 3047757560], length 1400 18:27:12.006713 IP 128.205.32.24.5999> 41.154.88.19.52564: Flags [.], ack 14659685, win 8225, options [nop,nop,TS val 3047757730 ecr 3651472], length 0 18:27:12.145079 IP 128.205.32.24.5999> 41.154.88.19.52564: Flags [.], ack 14662485, win 8050, options [nop,nop,TS val 3047757867 ecr 3651688], length 10 18:27:12.157567 IP 128.205.32.24.5999> 41.154.88.19.52564: Flags [.], ack 14663885, win 8225, options [nop,nop,TS val 3047757880 ecr 3651688], length 0 18:27:12.245335 IP 41.154.88.19.52564> 128.205.32.24.5999: Flags [P.], ack 102812, win 8225, options [nop,nop,TS val 3652146 ecr 3047757867], length 342 18:27:12.578479 IP 128.205.32.24.5999> 41.154.88.19.52564: Flags [R], seq 1059787102, win 0, length 0 It looks like the server is just exiting. I've tested cvsup4 and cvsup5 as well. Is cvsup deprecated these days or has something else broken it? Ian Try csup instead of cvsup...I've found it works better. Any possibility of network issues? Matt ___ 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"
cvsup servers broken?
Hi I've been seeing this all day: # cvsup -L2 /root/supfile-cvs Parsing supfile "/root/supfile-cvs" Connecting to cvsup6.freebsd.org Connected to cvsup6.freebsd.org Server software version: SNAP_16_1h Negotiating file attribute support Exchanging collection information Establishing multiplexed-mode data connection Running Updating collection cvsroot-common/cvs Updating collection src-all/cvs Updating collection ports-all/cvs Detailer failed: Premature EOF from server Will retry at 18:32:04 Which coincides with: (Timestamps UTC+0200) 18:27:12.004603 IP 41.154.88.19.52564 > 128.205.32.24.5999: Flags [.], ack 102802, win 8225, options [nop,nop,TS val 3651903 ecr 3047757560], length 1400 18:27:12.006713 IP 128.205.32.24.5999 > 41.154.88.19.52564: Flags [.], ack 14659685, win 8225, options [nop,nop,TS val 3047757730 ecr 3651472], length 0 18:27:12.145079 IP 128.205.32.24.5999 > 41.154.88.19.52564: Flags [.], ack 14662485, win 8050, options [nop,nop,TS val 3047757867 ecr 3651688], length 10 18:27:12.157567 IP 128.205.32.24.5999 > 41.154.88.19.52564: Flags [.], ack 14663885, win 8225, options [nop,nop,TS val 3047757880 ecr 3651688], length 0 18:27:12.245335 IP 41.154.88.19.52564 > 128.205.32.24.5999: Flags [P.], ack 102812, win 8225, options [nop,nop,TS val 3652146 ecr 3047757867], length 342 18:27:12.578479 IP 128.205.32.24.5999 > 41.154.88.19.52564: Flags [R], seq 1059787102, win 0, length 0 It looks like the server is just exiting. I've tested cvsup4 and cvsup5 as well. Is cvsup deprecated these days or has something else broken it? Ian -- Ian Freislich ___ 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: problems with cvsup on FreeBSD 9 snapshot 201101
On 6/15/11 10:58 AM, Kostik Belousov wrote: On Wed, Jun 15, 2011 at 10:24:46AM -0400, Eric McCorkle wrote: On 6/15/11 8:23 AM, Holger Kipp wrote: Dear all, I had installed FreeBSD 9 amd64 from snapshot (ISO-image) located here: ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/201101/FreeBSD-9.0-CURRENT-201101-amd64-dvd1.iso Today I wanted to cvsup to a later date to upgrade to ZFS v28 and compiled port /usr/ports/net/cvsup-without-gui without problems. Starting freshly compiled cvsup then gives me "Illegal Instruction" This error seems to be identical to http://lists.freebsd.org/pipermail/freebsd-current/2010-September/020083.html I've gotten the same problem, and managed to diagnose it. The problem actually isn't an illegal instruction, but a stack misalignment. If you load it in gdb, it will die with SIGSEGV somewhere in libc.so.7, on a callq instruction. This is because callq needs the stack to be 16-byte aligned, and it's not for some reason. Stack alignment requirement is an ABI convention, and it is not enforced by CPU, except several special cases. In particular, either EFLAGS.AC bit should be set, that usually is not, or SSE instruction explicitely disallowing non-aligned access executed. Anyway, you will not get Illegal instruction fault for unaligned access. I took a closer look this afternoon, and you're right. callq with an unaligned stack pointer does *not* cause a fault. If anyone does a movaps, however, you will get a fault (SIGBUS, I believe), and if the ABI says stacks are 16-byte aligned, then libraries may assume it's safe to load from the stack with movaps, and you'll get a fault. This is what happened to mlton on Mac OS, so I thought it might be something similar going on here. Anyways, I'll look into it more. ___ 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: problems with cvsup on FreeBSD 9 snapshot 201101
Ah, ok. Do we have a compiler switch to force stack alignment to 16-Byte-boundaries? Otherwise I am really concerned that we might have similar wrong pieces of code lurking unnoticed in other binaries as well :-/ My cvsup binary is: # file /usr/local/bin/cvsup /usr/local/bin/cvsup: ELF 64-bit LSB executable, x86-64, version 1 (FreeBSD), dynamically linked (uses shared libs), for FreeBSD 9.0 (900029), stripped Best regards, Holger From: owner-freebsd-curr...@freebsd.org [owner-freebsd-curr...@freebsd.org] on behalf of Eric McCorkle [e...@shadowsun.net] Sent: 15 June 2011 16:24 To: freebsd-current@freebsd.org Subject: Re: problems with cvsup on FreeBSD 9 snapshot 201101 On 6/15/11 8:23 AM, Holger Kipp wrote: > Dear all, > > I had installed FreeBSD 9 amd64 from snapshot (ISO-image) located here: > ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/201101/FreeBSD-9.0-CURRENT-201101-amd64-dvd1.iso > > > Today I wanted to cvsup to a later date to upgrade to ZFS v28 > and compiled port /usr/ports/net/cvsup-without-gui without problems. > > Starting freshly compiled cvsup then gives me > > "Illegal Instruction" > > This error seems to be identical to > http://lists.freebsd.org/pipermail/freebsd-current/2010-September/020083.html > I've gotten the same problem, and managed to diagnose it. The problem actually isn't an illegal instruction, but a stack misalignment. If you load it in gdb, it will die with SIGSEGV somewhere in libc.so.7, on a callq instruction. This is because callq needs the stack to be 16-byte aligned, and it's not for some reason. As for why it's not aligned, I don't know. -- Eric McCorkle Computer Science Ph.D Student, University of Massachusetts Research Intern, IBM Research ___ 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" -- Holger Kipp Diplom-Mathematiker Senior Consultant Tel. : +49 30 436 58 114 Fax. : +49 30 436 58 214 Mobil: +49 178 36 58 114 Email: holger.k...@alogis.com alogis AG Alt-Moabit 90b D-10559 Berlin web : http://www.alogis.com -- alogis AG Sitz/Registergericht: Berlin/AG Charlottenburg, HRB 71484 Vorstand: Arne Friedrichs, Joern Samuelson Aufsichtsratsvorsitzender: Reinhard Mielke ___ 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: problems with cvsup on FreeBSD 9 snapshot 201101
On 6/15/11 10:46 AM, Holger Kipp wrote: Ah, ok. Do we have a compiler switch to force stack alignment to 16-Byte-boundaries? Otherwise I am really concerned that we might have similar wrong pieces of code lurking unnoticed in other binaries as well :-/ My cvsup binary is: # file /usr/local/bin/cvsup /usr/local/bin/cvsup: ELF 64-bit LSB executable, x86-64, version 1 (FreeBSD), dynamically linked (uses shared libs), for FreeBSD 9.0 (900029), stripped Best regards, Holger (Accidentally replied directly to you, cc'ing list) It's certainly possible, though GCC aligns the stack correctly, or else nothing would work. CVSup is written in Modula 3. I checked the stack alignment option for FBSD_AMD64, and it is sure enough set to 16. My guess is somewhere in the native call interface, something's not being done right. I ran into a similar problem when porting the mlton compiler to Mac OS a couple of years back. -- Eric McCorkle Computer Science Ph.D student, University of Massachusetts Research Intern, IBM Research ___ 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: problems with cvsup on FreeBSD 9 snapshot 201101
On Wed, Jun 15, 2011 at 10:24:46AM -0400, Eric McCorkle wrote: > On 6/15/11 8:23 AM, Holger Kipp wrote: > >Dear all, > > > >I had installed FreeBSD 9 amd64 from snapshot (ISO-image) located here: > >ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/201101/FreeBSD-9.0-CURRENT-201101-amd64-dvd1.iso > > > > > > > >Today I wanted to cvsup to a later date to upgrade to ZFS v28 > >and compiled port /usr/ports/net/cvsup-without-gui without problems. > > > >Starting freshly compiled cvsup then gives me > > > >"Illegal Instruction" > > > >This error seems to be identical to > >http://lists.freebsd.org/pipermail/freebsd-current/2010-September/020083.html > > > > > > I've gotten the same problem, and managed to diagnose it. The problem > actually isn't an illegal instruction, but a stack misalignment. If you > load it in gdb, it will die with SIGSEGV somewhere in libc.so.7, on a > callq instruction. This is because callq needs the stack to be 16-byte > aligned, and it's not for some reason. Stack alignment requirement is an ABI convention, and it is not enforced by CPU, except several special cases. In particular, either EFLAGS.AC bit should be set, that usually is not, or SSE instruction explicitely disallowing non-aligned access executed. Anyway, you will not get Illegal instruction fault for unaligned access. > > As for why it's not aligned, I don't know. > > -- > Eric McCorkle > Computer Science Ph.D Student, > University of Massachusetts > Research Intern, IBM Research > ___ > 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" pgpbOT6ivEoap.pgp Description: PGP signature
Re: problems with cvsup on FreeBSD 9 snapshot 201101
On 6/15/11 8:23 AM, Holger Kipp wrote: Dear all, I had installed FreeBSD 9 amd64 from snapshot (ISO-image) located here: ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/201101/FreeBSD-9.0-CURRENT-201101-amd64-dvd1.iso Today I wanted to cvsup to a later date to upgrade to ZFS v28 and compiled port /usr/ports/net/cvsup-without-gui without problems. Starting freshly compiled cvsup then gives me "Illegal Instruction" This error seems to be identical to http://lists.freebsd.org/pipermail/freebsd-current/2010-September/020083.html I've gotten the same problem, and managed to diagnose it. The problem actually isn't an illegal instruction, but a stack misalignment. If you load it in gdb, it will die with SIGSEGV somewhere in libc.so.7, on a callq instruction. This is because callq needs the stack to be 16-byte aligned, and it's not for some reason. As for why it's not aligned, I don't know. -- Eric McCorkle Computer Science Ph.D Student, University of Massachusetts Research Intern, IBM Research ___ 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: problems with cvsup on FreeBSD 9 snapshot 201101
W dniu 2011-06-15 14:23, Holger Kipp pisze: Have now used csup instead of cvsup (which seems to have worked fine), and started cvsup once again (seems cvsup only gives "Illegal Instruction" when a file needs to be changed...). Any ideas? Whoops, I read your message too fast, apologize. Please ignore my previous email :) -- Bartosz Stec ___ 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: problems with cvsup on FreeBSD 9 snapshot 201101
W dniu 2011-06-15 14:23, Holger Kipp pisze: Dear all, I had installed FreeBSD 9 amd64 from snapshot (ISO-image) located here: ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/201101/FreeBSD-9.0-CURRENT-201101-amd64-dvd1.iso Today I wanted to cvsup to a later date to upgrade to ZFS v28 and compiled port /usr/ports/net/cvsup-without-gui without problems. Starting freshly compiled cvsup then gives me "Illegal Instruction" This error seems to be identical to http://lists.freebsd.org/pipermail/freebsd-current/2010-September/020083.html As this was created on a vanilla 9 snapshot using the default make.conf with only cvsup settings adapted I thought this might be of interest. Have now used csup instead of cvsup (which seems to have worked fine), and started cvsup once again (seems cvsup only gives "Illegal Instruction" when a file needs to be changed...). Any ideas? Best regards, Holger Although it's not a "fix" to your problem, doesn't cvsup became obsolete, from the moment when csup was integrated into the world (a couple of years ago I believe)? If you just want to update the ports tree, use csup. -- Bartosz Stec ___ 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"
problems with cvsup on FreeBSD 9 snapshot 201101
Dear all, I had installed FreeBSD 9 amd64 from snapshot (ISO-image) located here: ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/201101/FreeBSD-9.0-CURRENT-201101-amd64-dvd1.iso Today I wanted to cvsup to a later date to upgrade to ZFS v28 and compiled port /usr/ports/net/cvsup-without-gui without problems. Starting freshly compiled cvsup then gives me "Illegal Instruction" This error seems to be identical to http://lists.freebsd.org/pipermail/freebsd-current/2010-September/020083.html As this was created on a vanilla 9 snapshot using the default make.conf with only cvsup settings adapted I thought this might be of interest. Have now used csup instead of cvsup (which seems to have worked fine), and started cvsup once again (seems cvsup only gives "Illegal Instruction" when a file needs to be changed...). Any ideas? Best regards, Holger -- Holger Kipp Diplom-Mathematiker Senior Consultant Tel. : +49 30 436 58 114 Fax. : +49 30 436 58 214 Mobil: +49 178 36 58 114 Email: holger.k...@alogis.com alogis AG Alt-Moabit 90b D-10559 Berlin web : http://www.alogis.com -- alogis AG Sitz/Registergericht: Berlin/AG Charlottenburg, HRB 71484 Vorstand: Arne Friedrichs, Joern Samuelson Aufsichtsratsvorsitzender: Reinhard Mielke ___ 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: 10/23 cvsup buildworld failure
Il Ven, 2003-10-24 alle 17:47, Michael L. Squires ha scritto: > Tinderbox > > /vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/lib/libfetch/common.c:60: > error: initializer element is not constant > > Under 5.1-CURRENT or i386 cvsuped on 10/23 I get the same failure, with > the additional error message > > /usr/src/lib/libfetch/common.c:58: error: 'EAINONAME' undeclared here (not in a > function) > > Other error messages are similar or the same. > > I have re-cvsup'd and am trying again. You cvsup'd on at a bad moment, because ume@ correct this error at 2003/10/23 20:49:38 PDT with revision 1.29 of netdb.h Regards -- Rionda aka Matteo Riondato G.U.F.I Staff Member (http://www.gufi.org) BSD-FAQ-it Main Developer (http://www.gufi.org/~rionda) GPG key at: http://www.riondabsd.net/riondagpg.asc Sent from: kaiser.sig11.org running FreeBSD-5.1-CURRENT signature.asc Description: Questa parte del messaggio =?ISO-8859-1?Q?=E8?= firmata
Re: 10/23 cvsup buildworld failure
On Fri, Oct 24, 2003 at 10:47:22AM -0500, Michael L. Squires wrote: > Tinderbox > > /vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/lib/libfetch/common.c:60: > error: initializer element is not constant > > Under 5.1-CURRENT or i386 cvsuped on 10/23 I get the same failure, with > the additional error message > > /usr/src/lib/libfetch/common.c:58: error: 'EAINONAME' undeclared here (not in a > function) > > Other error messages are similar or the same. > > I have re-cvsup'd and am trying again. This was fixed yesterday, hours before your message was sent :-) Kris pgp0.pgp Description: PGP signature
10/23 cvsup buildworld failure
Tinderbox > /vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/lib/libfetch/common.c:60: > error: initializer element is not constant Under 5.1-CURRENT or i386 cvsuped on 10/23 I get the same failure, with the additional error message /usr/src/lib/libfetch/common.c:58: error: 'EAINONAME' undeclared here (not in a function) Other error messages are similar or the same. I have re-cvsup'd and am trying again. Mike Squires ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Unable to boot cvsup 20031011
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tuesday 14 October 2003 07:28 pm, Brian J. Creasy wrote: > On Sun, 12 Oct 2003, Anish Mistry wrote: > > > I finally recvsupped today as some problems with my ata stuff was > > fixed. Went through the normal buildworld/kernel progress and on > > reboot of loading the new kernel, it loads the kernel and modules and > > then as it starts booting it just causes my machine to restart. It > > doesn't have a serial port so I can't get any debug info that way. I > > can still boot in with an old kernel, so i can get debug info that > > way if needed. Old dmesg and pciconf attached. > > - -- > > Anish Mistry > The problem was in a commit to /src/sys/i386/i386/machdep.c which what just fixed last night it should work now if you CVSup. - -- Anish Mistry -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQE/jWHLxqA5ziudZT0RAvm8AJ9Gd9q2Aa0Lnvui12PMF73ZlPuTiACdHhB2 a1gWE3I0/6J8uZIbPLJQZ64= =MqOi -END PGP SIGNATURE- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Unable to boot cvsup 20031011
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 15 Oct 2003, Terry Lambert wrote: > Dimitry Andric wrote: > > On 2003-10-15 at 03:30:54 Brian J. Creasy wrote: > > > unfortunately, we are not getting any errors. the system just restarts > > > after it starts booting the kernel. > > > > I've got the same version here of pmap.c, but in my case the kernel > > hangs just after the boot loader's 'spinner' goes away, before the > > initial copyright message even. This happens on my old pentium router > > box, however on another box (well, not a real one, it's VMware ;) this > > does NOT occur, with precisely the same cvsup... > > I'm going to bet that both your machines have an odd amount of > memory in about the same ballpark. my fujitsu lifebook p2120 has 384mb of ram with 8mb shared video. i'm going to start checking past days' kernels and see exactly what day it stopped working. > > In my experience, the auto-tuning code still needs some tuning... > > -- Terry - --- Brian J. Creasy -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (FreeBSD) iD8DBQE/jVoGWMKWjLymTUYRArYtAJ9v9kNfW5HUXcav2xQOSJL4VNgXxwCgt017 w7hBXU4+Y/T+4BEKHPAnz/A= =rjZl -END PGP SIGNATURE- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Unable to boot cvsup 20031011
Dimitry Andric wrote: > On 2003-10-15 at 03:30:54 Brian J. Creasy wrote: > > unfortunately, we are not getting any errors. the system just restarts > > after it starts booting the kernel. > > I've got the same version here of pmap.c, but in my case the kernel > hangs just after the boot loader's 'spinner' goes away, before the > initial copyright message even. This happens on my old pentium router > box, however on another box (well, not a real one, it's VMware ;) this > does NOT occur, with precisely the same cvsup... I'm going to bet that both your machines have an odd amount of memory in about the same ballpark. In my experience, the auto-tuning code still needs some tuning... -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Unable to boot cvsup 20031011
On 2003-10-15 at 03:30:54 Brian J. Creasy wrote:
>> What version of sys/i386/i386/pmap.c do you have? If you are getting
>> the "pmap_zero_page: CMAP3 busy", it should be fixed by version 1.446,
>> which phk checked in 2003/10/12 10:55:45.
> __FBSDID("$FreeBSD: src/sys/i386/i386/pmap.c,v 1.447 2003/10/13 03:28:31
> alc Exp $");
> unfortunately, we are not getting any errors. the system just restarts
> after it starts booting the kernel.
I've got the same version here of pmap.c, but in my case the kernel
hangs just after the boot loader's 'spinner' goes away, before the
initial copyright message even. This happens on my old pentium router
box, however on another box (well, not a real one, it's VMware ;) this
does NOT occur, with precisely the same cvsup...
pgp0.pgp
Description: PGP signature
Re: Unable to boot cvsup 20031011
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tue, 14 Oct 2003, Don Lewis wrote:
> On 12 Oct, Anish Mistry wrote:
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA1
> >
> > I finally recvsupped today as some problems with my ata stuff was
> > fixed. Went through the normal buildworld/kernel progress and on
> > reboot of loading the new kernel, it loads the kernel and modules and
> > then as it starts booting it just causes my machine to restart. It
> > doesn't have a serial port so I can't get any debug info that way. I
> > can still boot in with an old kernel, so i can get debug info that
> > way if needed. Old dmesg and pciconf attached.
>
> What version of sys/i386/i386/pmap.c do you have? If you are getting
> the "pmap_zero_page: CMAP3 busy", it should be fixed by version 1.446,
> which phk checked in 2003/10/12 10:55:45.
__FBSDID("$FreeBSD: src/sys/i386/i386/pmap.c,v 1.447 2003/10/13 03:28:31
alc Exp $");
unfortunately, we are not getting any errors. the system just restarts
after it starts booting the kernel.
- ---
Brian J. Creasy
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.1 (FreeBSD)
iD8DBQE/jKNUWMKWjLymTUYRAq21AJ0TCECQQNrc7L1LZu6PJ/Xeq0ydxgCeIcoz
2TPzvP2MV/3/K6GmAJIFeHc=
=4jHZ
-END PGP SIGNATURE-
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Unable to boot cvsup 20031011
On Tue, Oct 14, 2003 at 09:19:10PM -0400, Brian J. Creasy wrote: > the last good cvsup i did was quite a while ago. july 13th. i got a > little hung up with the semester starting back up. there isn't a way to > tell cvsup a specific date to roll back to, is there? There is... please to be RTFMing... it's in the manual page. BMS pgp0.pgp Description: PGP signature
Re: Unable to boot cvsup 20031011
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, 14 Oct 2003, Anish Mistry wrote: > > hi. i'm having the same problem and my pciconf output is the same as > > yours. you have a fujitsu lifebook p2120, right? > > > > P2110. I'm at least glad to hear that I'm not alone. as am i. > > > i tried the same source (world and kernel) on one of my desktop > > machines and it is able to boot just fine. looks like this is a tm > > crusoe issue. > > maybe something with the acpi or longrun stuff. > > > > i'm not too proficient with freebsd kernel hacking, so hopefully > > someone else will be able to tackle this. > > > > When was the last good cvsup that you did? I think we will have to > track down ourselves which commit broke since no one else is having > this problem. I don't remember when I did mine since I let a friend > borrow it for a couple of weeks. I hope that someone with more > knowledge can point where to start looking. It isn't ACPI since it > still doesn't work when unloaded from the boot loader. > > > --- > > Brian J. Creasy > > > > > -- > Anish Mistry the last good cvsup i did was quite a while ago. july 13th. i got a little hung up with the semester starting back up. there isn't a way to tell cvsup a specific date to roll back to, is there? - --- Brian J. Creasy -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (FreeBSD) iD8DBQE/jKCkWMKWjLymTUYRAg5tAJwNE3LxAxd+UNC+5hxKuYzLEZ5YTQCbBB7y rQ7JmenMscCERiZmAL3djCY= =UoI8 -END PGP SIGNATURE- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Unable to boot cvsup 20031011
On 12 Oct, Anish Mistry wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > I finally recvsupped today as some problems with my ata stuff was > fixed. Went through the normal buildworld/kernel progress and on > reboot of loading the new kernel, it loads the kernel and modules and > then as it starts booting it just causes my machine to restart. It > doesn't have a serial port so I can't get any debug info that way. I > can still boot in with an old kernel, so i can get debug info that > way if needed. Old dmesg and pciconf attached. What version of sys/i386/i386/pmap.c do you have? If you are getting the "pmap_zero_page: CMAP3 busy", it should be fixed by version 1.446, which phk checked in 2003/10/12 10:55:45. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Unable to boot cvsup 20031011
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 > hi. i'm having the same problem and my pciconf output is the same as > yours. you have a fujitsu lifebook p2120, right? > P2110. I'm at least glad to hear that I'm not alone. > i tried the same source (world and kernel) on one of my desktop machines > and it is able to boot just fine. looks like this is a tm crusoe issue. > maybe something with the acpi or longrun stuff. > > i'm not too proficient with freebsd kernel hacking, so hopefully someone > else will be able to tackle this. > When was the last good cvsup that you did? I think we will have to track down ourselves which commit broke since no one else is having this problem. I don't remember when I did mine since I let a friend borrow it for a couple of weeks. I hope that someone with more knowledge can point where to start looking. It isn't ACPI since it still doesn't work when unloaded from the boot loader. > --- > Brian J. Creasy > - -- Anish Mistry -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQE/jJdBxqA5ziudZT0RAhjdAJwJyo4t0aPF14fW5zH7i6SU+N3T+gCg3dJD 8CZc2ypG6VYchDSuPVWKEt8= =AQay -END PGP SIGNATURE- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Unable to boot cvsup 20031011
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sun, 12 Oct 2003, Anish Mistry wrote: > I finally recvsupped today as some problems with my ata stuff was > fixed. Went through the normal buildworld/kernel progress and on > reboot of loading the new kernel, it loads the kernel and modules and > then as it starts booting it just causes my machine to restart. It > doesn't have a serial port so I can't get any debug info that way. I > can still boot in with an old kernel, so i can get debug info that > way if needed. Old dmesg and pciconf attached. > - -- > Anish Mistry hi. i'm having the same problem and my pciconf output is the same as yours. you have a fujitsu lifebook p2120, right? i tried the same source (world and kernel) on one of my desktop machines and it is able to boot just fine. looks like this is a tm crusoe issue. maybe something with the acpi or longrun stuff. i'm not too proficient with freebsd kernel hacking, so hopefully someone else will be able to tackle this. - --- Brian J. Creasy -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (FreeBSD) iD8DBQE/jIaZWMKWjLymTUYRArVrAJ454d0I3V3GvA+9FkNqpz6EL3y1KQCgt9Vk ArLxKFm9nNsfgiSe2ZpYPWs= =zLwX -END PGP SIGNATURE- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Unable to boot cvsup 20031011
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I finally recvsupped today as some problems with my ata stuff was fixed. Went through the normal buildworld/kernel progress and on reboot of loading the new kernel, it loads the kernel and modules and then as it starts booting it just causes my machine to restart. It doesn't have a serial port so I can't get any debug info that way. I can still boot in with an old kernel, so i can get debug info that way if needed. Old dmesg and pciconf attached. - -- Anish Mistry -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQE/ibQzxqA5ziudZT0RAglLAJ9cxoP9hQ65NQ/k5fsrWJs7QJ1V2wCfU7G2 mbG9XSjhoxEX+q6Ntl6/VBI= =ZulV -END PGP SIGNATURE- [EMAIL PROTECTED]:0:0: class=0x06 card=0x110e10cf chip=0x03951279 rev=0x02 hdr=0x00 vendor = 'Transmeta Corp.' device = 'LongRun Northbridge' class= bridge subclass = HOST-PCI [EMAIL PROTECTED]:0:1: class=0x05 card=0x110e10cf chip=0x03961279 rev=0x00 hdr=0x00 vendor = 'Transmeta Corp.' device = 'SDRAM Controller' class= memory subclass = RAM [EMAIL PROTECTED]:0:2: class=0x05 card=0x110e10cf chip=0x03971279 rev=0x00 hdr=0x00 vendor = 'Transmeta Corp.' device = 'BIOS scratchpad' class= memory subclass = RAM [EMAIL PROTECTED]:2:0: class=0x0c0310 card=0x10a210cf chip=0x523710b9 rev=0x03 hdr=0x00 vendor = 'Acer Labs Incorporated (ALi)' device = 'ALI M5237 USB Host Controller' class= serial bus subclass = USB [EMAIL PROTECTED]:4:0: class=0x040100 card=0x112f10cf chip=0x545110b9 rev=0x01 hdr=0x00 vendor = 'Acer Labs Incorporated (ALi)' device = 'ALI M5451 PCI AC-Link Controller Audio Device' class= multimedia subclass = audio [EMAIL PROTECTED]:6:0: class=0x068000 card=0x10a310cf chip=0x710110b9 rev=0x00 hdr=0x00 vendor = 'Acer Labs Incorporated (ALi)' device = 'ALI M7101 Power Management Controller' class= bridge subclass = PCI-unknown [EMAIL PROTECTED]:7:0: class=0x060100 card=0x153310b9 chip=0x153310b9 rev=0x00 hdr=0x00 vendor = 'Acer Labs Incorporated (ALi)' device = 'ALI M1533 Aladdin IV ISA Bridge' class= bridge subclass = PCI-ISA [EMAIL PROTECTED]:12:0: class=0x060700 card=0x10c610cf chip=0xac50104c rev=0x01 hdr=0x02 vendor = 'Texas Instruments (TI)' device = 'PCI1410 PC card cardBus Controller' class= bridge subclass = PCI-CardBus [EMAIL PROTECTED]:15:0: class=0x0101fa card=0x10a410cf chip=0x522910b9 rev=0xc3 hdr=0x00 vendor = 'Acer Labs Incorporated (ALi)' device = 'M1543 Southbridge EIDE Controller' class= mass storage subclass = ATA [EMAIL PROTECTED]:16:0: class=0x02 card=0x111c10cf chip=0x813910ec rev=0x10 hdr=0x00 vendor = 'Realtek Semiconductor' device = 'RT8139 (A/B/C/8130) Fast Ethernet Adapter' class= network subclass = ethernet [EMAIL PROTECTED]:19:0: class=0x0c0010 card=0x116210cf chip=0x8026104c rev=0x00 hdr=0x00 vendor = 'Texas Instruments (TI)' device = 'TSB43AB21 1394a-2000 OHCI PHY/link-layer Controller' class= serial bus subclass = FireWire [EMAIL PROTECTED]:20:0: class=0x03 card=0x114f10cf chip=0x4c521002 rev=0x64 hdr=0x00 vendor = 'ATI Technologies' device = 'Rage P/M Mobility PCI' class= display subclass = VGA ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: cvsup sites are all at capacity?
I spoke too soon. Suddenly it all works. >It never got above 10 clients before today. How about a few >people switch to my server for regular updates? Thanks. :) > >Regards, >-- >wca Oh, alright! Andrew Lankford ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: cvsup sites are all at capacity?
On Tue, Sep 16, 2003 at 04:01:39PM -0600, Andrew Lankford wrote: > I've tried various cvsup sites (normally cvsup2 or cvsup16 ) > and each site returns this message: > > Rejected by server: Access limit exceeded; try again later > > I've gotten that before but never with all of the hosts out there. Is everyone and > their brother doing a make world today, > are the sites down for maintenance, or is something sinister > going on? Mine (cvsup12) is still below capacity (28 max clients): http://paloalto.csociety.org/mrtg-sanmateo/ (mrtg) It never got above 10 clients before today. How about a few people switch to my server for regular updates? Thanks. :) Regards, -- wca ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: cvsup sites are all at capacity?
On Tue, Sep 16, 2003 at 05:11:02PM -0500, Dan Nelson wrote:
> In the last episode (Sep 16), Andrew Lankford said:
> > I've tried various cvsup sites (normally cvsup2 or cvsup16 ) and
> > each site returns this message:
> >
> > Rejected by server: Access limit exceeded; try again later
> >
> > I've gotten that before but never with all of the hosts out there.
> > Is everyone and their brother doing a make world today, are the sites
> > down for maintenance, or is something sinister going on?
>
> cvsup4, 5, 9, 10, 11, 12, 13, 14, and 16 all work for me.
There's a port ('fastest_cvsup') that might be useful for folks.
-T
--
The envious man thinks that if his neighbor breaks a leg, he will be able
to walk better himself.
- Helmut Schoeck, _Envy: A Theory Of Social Behavior_
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: cvsup sites are all at capacity?
In the last episode (Sep 16), Andrew Lankford said: > I've tried various cvsup sites (normally cvsup2 or cvsup16 ) and > each site returns this message: > > Rejected by server: Access limit exceeded; try again later > > I've gotten that before but never with all of the hosts out there. > Is everyone and their brother doing a make world today, are the sites > down for maintenance, or is something sinister going on? cvsup4, 5, 9, 10, 11, 12, 13, 14, and 16 all work for me. -- Dan Nelson [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: cvsup sites are all at capacity?
On Tue, Sep 16, 2003 at 04:01:39PM -0600, Andrew Lankford wrote: > I've tried various cvsup sites (normally cvsup2 or cvsup16 ) > and each site returns this message: > > Rejected by server: Access limit exceeded; try again later > > I've gotten that before but never with all of the hosts out there. > Is everyone and their brother doing a make world today, Probably. There was a security advisory for OpenSSH released earlier today, so I would guess just about everybody is trying to update their systems. > are the sites down for maintenance, or is something sinister > going on? > > Just wonderin' > > Andrew Lankford > -- Erik Trulsson [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
cvsup sites are all at capacity?
I've tried various cvsup sites (normally cvsup2 or cvsup16 ) and each site returns this message: Rejected by server: Access limit exceeded; try again later I've gotten that before but never with all of the hosts out there. Is everyone and their brother doing a make world today, are the sites down for maintenance, or is something sinister going on? Just wonderin' Andrew Lankford ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ATA problems(unlean fs) on recent cvsup
I've seen that too, although my problem was with my Alcatel Speedtouch 330 which routinely panics the system. I'djust retrieved usr from a backup to get round it, and put it down to the perils of -current, but if there is really a problem, I can investigate further here. Mark Simon Brown wrote: Hi... Sorry to do a me too, but I have a similar problem after a cvsup midday on the 13th September. The previous kernel was pre-ATAng. The machine panic'd after inserting a friends wireless PCMCIA card (but that's probably another unrelated issue), rebooted and left me in single user after failing to automatically run fsck. Prior to that it had booted fine when the disks were clean. Unfortunately, I wasn't able to copy down the exact error messages it printed in the failed fsck_ufs. But they were definitely of the form CANNOT WRITE BLK: and the fsck then died with a SIGABRT. A manual fsck of the disks has got me back up and running and the machine now boots multiuser without fsck terminating abnormally, but still seems unable to resolve the inconsistencies on-disk. http://www.silent.co.uk/freebsd/ ... contains a dmesg and messages log of the failing background fsck if they are of any help. I will try to investigate further but please get in touch if there is more information I can provide. Cheers, Si On Sun, Sep 14, 2003 at 03:52:33PM +1000, Alastair G. Hogge wrote: Hello list, I've recently cvsup'd current (14th of Sep). After a build and install world/kernel I rebooted to find some new and interesting kernel messages about ata? MPSAFE. Well as the booting continued I notcied the machine was going through more disk activity then usal. It was also taking alot longer to actully start. Eventully the kernel dropped into single user mode. It appears my filesystem is playing up for some reason. I haven't had any power failures for random hangs/reboots. After the recent cvsup my /usr fs appears to be coruppt or something. In single user mode I'm unable fix the problem with fsck. At first when I had softupdates /usr fsck would give me messages like "UNEXPECTED SOFT UPDATE INCONSISTENCY" I turned of softupate to see if it would help...it didn't. I still can't fix the fs. I get output like "CANNOT WRITE BLK: xxx" and I'm always unable to salvage blks and what not. Anyway my dmesg is as follows: Copyright (c) 1992-2003 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.1-CURRENT #0: Sun Sep 14 12:59:35 EST 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC Preloaded elf kernel "/boot/kernel.GENERIC/kernel" at 0xc076. Preloaded elf module "/boot/modules/acpi.ko" at 0xc076024c. Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Pentium(R) 4 CPU 2.53GHz (2533.05-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf27 Stepping = 7 Features=0xbfebfbff real memory = 536854528 (511 MB) avail memory = 513466368 (489 MB) Pentium Pro MTRR support enabled npx0: [FAST] npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard pcibios: BIOS version 2.10 Using $PIR table, 11 entries at 0xc00f1720 acpi0: power button is handled as a fixed feature programming model. Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0xe408-0xe40b on acpi0 acpi_cpu0: on acpi0 acpi_cpu1: on acpi0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib0: slot 2 INTA is routed to irq 11 pcib0: slot 3 INTA is routed to irq 9 pcib0: slot 3 INTB is routed to irq 9 pcib0: slot 3 INTC is routed to irq 9 pcib0: slot 14 INTA is routed to irq 11 agp0: mem 0xe000-0xe7ff at device 0.0 on pci0 pcib1: at device 1.0 on pci0 pci1: on pcib1 pcib1: slot 0 INTA is routed to irq 11 pci1: at device 0.0 (no driver attached) isab0: at device 2.0 on pci0 isa0: on isab0 fwohci0: vendor=1039, dev=7007 fwohci0: <1394 Open Host Controller Interface> mem 0xde80-0xde800fff at device 2.3 on pci0 pcib0: slot 2 INTB is routed to irq 5 fwohci0: [MPSAFE] fwohci0: OHCI version 1.0 (ROM=1) fwohci0: No. of Isochronous channel is 4. fwohci0: EUI64 00:e0:18:00:00:0a:83:4c fwohci0: Phy 1394a available S400, 2 ports. fwohci0: Link S400, max_rec 2048 bytes. firewire0: on fwohci0 if_fwe0: on firewire0 if_fwe0: Fake Ethernet address: 02:e0:18:0a:83:4c sbp0: on firewire0 fwohci0: Initiate bus reset atapci0: port 0xb400-0xb40f,0xb800-0xb803,0xd000-0xd007,0xd400-0xd403,0xd800-0xd807 irq 11 at device 2.5 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata0: [MPSAFE] ata1: at 0x170 irq 15 on atapci0 ata1: [MPSAFE] pci0: at device 2.7 (no driver attached) ohci0: mem 0xde00-0xde000fff irq 9 at device 3.0 on pci0 usb0: OHCI version 1.0, legacy support usb0: SMM does not respond, resetting usb0: on o
