Re: HEADS UP! KSE needs more attention
On Sunday 06 June 2004 16:49, Scott Long wrote: > Garance A Drosihn wrote: > > At 3:46 PM -0600 6/6/04, Scott Long wrote: > >> At this point, I'm going to advocate that Alpha be dropped from > >> Tier-1 status for 5.3 and 5-STABLE and no longer be a blocking > >> item for releases. ... As I said back then, demotion is not a > >> terminal condition, and I would be thrilled if someone comes > >> forward in the future and brings the platform back up to date. > > > > I think you have to officially demote it, with emphasis on the > > point that "demotion is not a terminal condition". Then, if some > > developer(s) show up and implement all the missing pieces, we > > can happily announce it back in tier 1. > > > > But for now, say that it *IS* demoted. Not that you're advocating > > that we think about maybe demoting it in the future unless someone > > offers to start looking into the missing pieces. > > > > At the moment, it probably also makes sense to demote sparc64, > > even though I own one of those. Not that we have anything against > > it, but as a practical matter we haven't hit "critical mass" on it > > just yet. Since I am interested in sparc64, I can take that as a > > goal to help make it a tier-1 platform by 5.4-release... > > Ok, thanks for all of the input. I'm going to wait a few more days for > anyone else to chime in and then discuss it with re@ and [EMAIL PROTECTED] We'll > likely have a formal announcement in a week. > > Back to the topic at hand, who is looking that the other KSE issues? The "tierness" of a particular platform wasn't all that important as long as FreeBSD 5 remained a development branch, but with 5-STABLE rapidly approaching, it will become much more important. When we first documented the tier approach, we selected sparc64 as the reference 64-bit platform, because it was at that time the most viable and the most actively developed platform. This was shortly before the Athlon64 release, which has turned into an avalanche. None of the current tiers are set in stone, in fact, they're not really very firm at all. The stability and completeness of each will have to be evaluated as the 5.3 release becomes real and adjustments made. It wouldn't surprise me to see a new 64-bit reference platform chosen; the momentum in that arena has definitely shifted. As an aside, I would sadden me greatly to see sparc64 or alpha abandoned. Even sadder (to me) is how little I've been able to contribute to either. I don't have time to bring my sparc skills up to working on FreeBSD internals and I'm not likely to suddenly grow more time soon. I do have an Ultra 5 workstation that is free to any developer in North America who will use it to further FreeBSD development. I'll contact dlo@ with details. sparc64 and alpha need a few champions. Without them, these ports will quickly be relegated to the bit-bucket. At any rate, FreeBSD will continue to move, in a direction we've decided to call "forward." -- Where am I, and what am I doing in this handbasket? Wes Peters [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADS UP! KSE needs more attention
In message: <[EMAIL PROTECTED]> Marcel Moolenaar <[EMAIL PROTECTED]> writes: : On Sun, Jun 06, 2004 at 05:27:56PM -0400, Daniel Eischen wrote: : > : > > As for alpha, we don't even seem to be able to degrade it to tier 2 : > > without losing face. kris@ has already stopped package builds for it : > > for his own sake. : > : > We shouldn't keep an arch at tier 1 just to save face. Better to just : > lower it to tier 2 and be done with it. My $.02, FWIW. : : You misunderstand my statement. Lowering alpha to tier 2 is what I : suggested multiple times before. The point is that we haven't yet : and alpha is degenerating more and more while we fail to adjust : the tierness. That's where we fail to save face. I tend to agree. Tierness is a combination of politics and technical reality. The rality of the situation with alpha is that it has had no clothes long enough that it no longer reflects the Tier-1 ideas that we strive to attain. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADS UP! KSE needs more attention
On Mon, Jun 07, 2004 at 02:32:11AM +0200, Matthias Andree wrote:
> Marcel Moolenaar <[EMAIL PROTECTED]> writes:
>
> > As for alpha, we don't even seem to be able to degrade it to tier 2
> > without losing face. kris@ has already stopped package builds for it
> > for his own sake.
>
> Alpha is special, with what seems to me like a GDB bug. Try this:
>
> echo '#include
> int main() {abort();}' >abortme.c
> gcc -O2 -o abortme abortme.c
> ./abortme
> gdb ./abortme ./core.abortme
> (inside gdb:) backtrace
> (inside gdb:) backtrace full
> (inside gdb:) quit
>
> This stuff is run as part of the ports/mail/bogofilter test suite (which
> is part of the build) determine if core dumps from the build logs are
> usable.
>
> A couple of days ago, the backtrace of the trivial program ended up in
> an unterminated loop on the build cluster, GDB kept repeating stack
> frame #0. Whoops. The other architectures appeared fine though.
This is fixed in gdb 6.x:
GNU gdb 6.1.0.90_20040413 [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 "alpha-intree-freebsd"...
Core was generated by `abortme'.
Program terminated with signal 6, Aborted.
Reading symbols from /lib/libc.so.5...done.
Loaded symbols for /lib/libc.so.5
Reading symbols from /libexec/ld-elf.so.1...done.
Loaded symbols for /libexec/ld-elf.so.1
#0 0x0001601b29bc in kill () from /lib/libc.so.5
(gdb) l
1 #include
2 int main()
3 {
4 abort();
5 }
(gdb) bt
#0 0x0001601b29bc in kill () from /lib/libc.so.5
#1 0x0001601a5298 in raise () from /lib/libc.so.5
#2 0x000160233f88 in abort () from /lib/libc.so.5
#3 0x000128a0 in main () at abortme.c:4
(gdb)
An import of gdb 6.1 or gdb 6.1.1 will resolve this.
--
Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADS UP! KSE needs more attention
Garance A Drosihn wrote: At 3:46 PM -0600 6/6/04, Scott Long wrote: At this point, I'm going to advocate that Alpha be dropped from Tier-1 status for 5.3 and 5-STABLE and no longer be a blocking item for releases. ... As I said back then, demotion is not a terminal condition, and I would be thrilled if someone comes forward in the future and brings the platform back up to date. I think you have to officially demote it, with emphasis on the point that "demotion is not a terminal condition". Then, if some developer(s) show up and implement all the missing pieces, we can happily announce it back in tier 1. But for now, say that it *IS* demoted. Not that you're advocating that we think about maybe demoting it in the future unless someone offers to start looking into the missing pieces. At the moment, it probably also makes sense to demote sparc64, even though I own one of those. Not that we have anything against it, but as a practical matter we haven't hit "critical mass" on it just yet. Since I am interested in sparc64, I can take that as a goal to help make it a tier-1 platform by 5.4-release... Ok, thanks for all of the input. I'm going to wait a few more days for anyone else to chime in and then discuss it with re@ and [EMAIL PROTECTED] We'll likely have a formal announcement in a week. Back to the topic at hand, who is looking that the other KSE issues? Scott ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADS UP! KSE needs more attention
At 3:46 PM -0600 6/6/04, Scott Long wrote: At this point, I'm going to advocate that Alpha be dropped from Tier-1 status for 5.3 and 5-STABLE and no longer be a blocking item for releases. ... As I said back then, demotion is not a terminal condition, and I would be thrilled if someone comes forward in the future and brings the platform back up to date. I think you have to officially demote it, with emphasis on the point that "demotion is not a terminal condition". Then, if some developer(s) show up and implement all the missing pieces, we can happily announce it back in tier 1. But for now, say that it *IS* demoted. Not that you're advocating that we think about maybe demoting it in the future unless someone offers to start looking into the missing pieces. At the moment, it probably also makes sense to demote sparc64, even though I own one of those. Not that we have anything against it, but as a practical matter we haven't hit "critical mass" on it just yet. Since I am interested in sparc64, I can take that as a goal to help make it a tier-1 platform by 5.4-release... -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADS UP! KSE needs more attention
Marcel Moolenaar wrote: On Sun, Jun 06, 2004 at 03:46:44PM -0600, Scott Long wrote: As for alpha, we don't even seem to be able to degrade it to tier 2 without losing face. kris@ has already stopped package builds for it for his own sake. It's not that there is face to loose on alpha, it's that every time I announce that alpha is going to be killed unless issues X, Y, and Z are fixed, someone comes along and fixes X, part of Y, and promises to fix Z. I don't read anything I haven't read before. People have made promises before and good intentions notwithstanding, you cannot keep a project hostage this way. Degrade alpha and only promote it after people have actually demonstrated that alpha is tier 1 material after all. At this point, I'm going to advocate that Alpha be dropped from Tier-1 status for 5.3 and 5-STABLE and no longer be a blocking item for releases. Just *do* it. You've been advocating for way too long. There are always people with good intentions, and they often want to find some way to help. I appreciate this very much and I don't want to turn them away. We also can't make a snap decision in an afternoon and risk missing people who have better things to do on their weekends/holidays than track FreeBSD mail =-) But yes, Alpha has been languishing for too long. I'll say it in a loud voice now: This is the last call for Alpha. It cannot maintain minimum tier-1 requirements and it will be demoted for 5.3. Unless you currently have access to a representative selection of hardware, the knowledge to track down platform-specific issues, the willingness to handle the current outstanding issues, and the time to do it for the next 18 months, please accept my regrets on it. Again, while I appreciate people who can pick away at some of the lesser issues or want to learn the bigger things, we need a 100% maintenance and development solution. Scott ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADS UP! KSE needs more attention
On Sun, Jun 06, 2004 at 03:46:44PM -0600, Scott Long wrote: > > > >As for alpha, we don't even seem to be able to degrade it to tier 2 > >without losing face. kris@ has already stopped package builds for it > >for his own sake. > > It's not that there is face to loose on alpha, it's that every time > I announce that alpha is going to be killed unless issues X, Y, and Z > are fixed, someone comes along and fixes X, part of Y, and promises > to fix Z. I don't read anything I haven't read before. People have made promises before and good intentions notwithstanding, you cannot keep a project hostage this way. Degrade alpha and only promote it after people have actually demonstrated that alpha is tier 1 material after all. > At this point, I'm going to advocate that Alpha be dropped from Tier-1 > status for 5.3 and 5-STABLE and no longer be a blocking item for > releases. Just *do* it. You've been advocating for way too long. -- Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADS UP! KSE needs more attention
On Sun, Jun 06, 2004 at 05:27:56PM -0400, Daniel Eischen wrote: > > > As for alpha, we don't even seem to be able to degrade it to tier 2 > > without losing face. kris@ has already stopped package builds for it > > for his own sake. > > We shouldn't keep an arch at tier 1 just to save face. Better to just > lower it to tier 2 and be done with it. My $.02, FWIW. You misunderstand my statement. Lowering alpha to tier 2 is what I suggested multiple times before. The point is that we haven't yet and alpha is degenerating more and more while we fail to adjust the tierness. That's where we fail to save face. -- Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADS UP! KSE needs more attention
On Sun, Jun 06, 2004 at 03:49:13PM -0600, Scott Long wrote: > amd64 is approaching critical mass for tier-1. There are a number of > developers that own amd64 hardware now, and a number of users who are > asking about it on the mailing lists. Peter is finishing up the last > blocking item for it (kld's) not including the observed KSE problems. > It's very close and I _will_ hold up the release for it to get done. > amd64 is the future of commodity computing and we aren't going to > ignore it for 5-STABLE. amd64 has a bug with swapping - when something begins to access swap, the entire system becomes almost entirely unresponsive (e.g. no mouse response for up to 10 seconds) until it stops. Peter has some ideas about it, but it's a serious enough bug that it forced me to stop using amd64 as my desktop machine (hello, kde!). Kris pgpOd3IUDPnRF.pgp Description: PGP signature
Re: HEADS UP! KSE needs more attention
On 6 Jun, Daniel Eischen wrote: > On Sun, 6 Jun 2004, Marcel Moolenaar wrote: > >> On Sun, Jun 06, 2004 at 02:31:56PM -0600, Scott Long wrote: >> >> > As with Alpha, >> > the fate of a platform rests on the people who are willing to work on >> > it, not on whether it is in a particular list. >> >> Agreed, but it's the projects responsibility to take the tierness and >> the intend to support multiple platforms serious and not to chicken out >> at the first signs of complications or hurdles. We labeled sparc64 as >> a tier 1 platform and we better deal with the consequences. > > Not to take away from the tremendous effort that jake had done for > sparc64, but it should really take more than one or two supporting > developers to obtain tier 1 support. People come and go, and > tierness should take that into account. I've got some sparc64 hardware that recently became available for FreeBSD develpment. Unfortunately my time available to FreeBSD is likely to be the limiting factor. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADS UP! KSE needs more attention
Wilko Bulte wrote: On Sun, Jun 06, 2004 at 02:12:49PM -0700, Marcel Moolenaar wrote: On Sun, Jun 06, 2004 at 02:31:56PM -0600, Scott Long wrote: As with Alpha, the fate of a platform rests on the people who are willing to work on it, not on whether it is in a particular list. Agreed, but it's the projects responsibility to take the tierness and the intend to support multiple platforms serious and not to chicken out at the first signs of complications or hurdles. We labeled sparc64 as a tier 1 platform and we better deal with the consequences. As for alpha, we don't even seem to be able to degrade it to tier 2 without losing face. kris@ has already stopped package builds for it for his own sake. Wake up, people. This is quickly becoming a joke... Right... Basically only i386 is a Tier 1. The rest is a joke if it is called Tier 1. If only because there are insufficient numbers of committers actively working on the arch. (maybe pc98 should be called Tier 1, I just don't know enough about that one). amd64 is approaching critical mass for tier-1. There are a number of developers that own amd64 hardware now, and a number of users who are asking about it on the mailing lists. Peter is finishing up the last blocking item for it (kld's) not including the observed KSE problems. It's very close and I _will_ hold up the release for it to get done. amd64 is the future of commodity computing and we aren't going to ignore it for 5-STABLE. Scott ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADS UP! KSE needs more attention
Marcel Moolenaar wrote: On Sun, Jun 06, 2004 at 02:31:56PM -0600, Scott Long wrote: As with Alpha, the fate of a platform rests on the people who are willing to work on it, not on whether it is in a particular list. Agreed, but it's the projects responsibility to take the tierness and the intend to support multiple platforms serious and not to chicken out at the first signs of complications or hurdles. We labeled sparc64 as a tier 1 platform and we better deal with the consequences. As for alpha, we don't even seem to be able to degrade it to tier 2 without losing face. kris@ has already stopped package builds for it for his own sake. Wake up, people. This is quickly becoming a joke... It's not that there is face to loose on alpha, it's that every time I announce that alpha is going to be killed unless issues X, Y, and Z are fixed, someone comes along and fixes X, part of Y, and promises to fix Z. There is nothing wrong with this, and I definitely appreciate it when people step up to fix things. However, it does prolong the process and doesn't leave us with 100% of what we need. At this point, I'm going to advocate that Alpha be dropped from Tier-1 status for 5.3 and 5-STABLE and no longer be a blocking item for releases. I made it very clear last winter that alpha needed a full time maintainer in order to stay viable, and that really never happened. As I said back then, demotion is not a terminal condition, and I would be thrilled if someone comes forward in the future and brings the platform back up to date. If anyone wants to claim it now and keep it alive for 5.3, they need to both finish KSE, make KSE work reliably, and be very responsive to Kris Kenneway about ports issues. This needs to happen in no more than 4 weeks. After that, I will turn away even the best of intentions. Anyways, moving on, KSE needs attention. Please figure out what can be done for sparc64 and amd64 and do it. Scott ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADS UP! KSE needs more attention
Hey all, Daniel Eischen wrote: On Sun, 6 Jun 2004, Marcel Moolenaar wrote: On Sun, Jun 06, 2004 at 02:31:56PM -0600, Scott Long wrote: Not to take away from the tremendous effort that jake had done for sparc64, but it should really take more than one or two supporting developers to obtain tier 1 support. People come and go, and tierness should take that into account. We shouldn't keep an arch at tier 1 just to save face. Better to just lower it to tier 2 and be done with it. My $.02, FWIW. I agree with Daniel, although i am not developping for freebsd (lack of knowledge). I think that what Daniel says is true, you cannot say that you support a product in a tier 1 status, while you have way to less people to resolve things. In my opinion it's also better to lower it then, and perhaps upgrade it again when more supporters are available to resolve issues. It takes more time to recover from "failed support" then by honestly saying that you don't have the manpower to support it in a tier 1 branch. Besides that i can understand that this will hit certain people, depending on the sparc64 tier 1 status, but perhaps they can support as well.. We need to resolve this with all of us, and if we cannot find enough people to help , then it should -sadly enough- be degraded in tier status. my $0.02 :) -- Kind regards, Remko Lodder Elvandar.org/DSINet.org www.mostly-harmless.nl Dutch community for helping newcomers on the hackerscene ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADS UP! KSE needs more attention
On Sun, 6 Jun 2004, Marcel Moolenaar wrote: > On Sun, Jun 06, 2004 at 02:31:56PM -0600, Scott Long wrote: > > > As with Alpha, > > the fate of a platform rests on the people who are willing to work on > > it, not on whether it is in a particular list. > > Agreed, but it's the projects responsibility to take the tierness and > the intend to support multiple platforms serious and not to chicken out > at the first signs of complications or hurdles. We labeled sparc64 as > a tier 1 platform and we better deal with the consequences. Not to take away from the tremendous effort that jake had done for sparc64, but it should really take more than one or two supporting developers to obtain tier 1 support. People come and go, and tierness should take that into account. > As for alpha, we don't even seem to be able to degrade it to tier 2 > without losing face. kris@ has already stopped package builds for it > for his own sake. We shouldn't keep an arch at tier 1 just to save face. Better to just lower it to tier 2 and be done with it. My $.02, FWIW. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADS UP! KSE needs more attention
On Sun, Jun 06, 2004 at 02:31:56PM -0600, Scott Long wrote: > As with Alpha, > the fate of a platform rests on the people who are willing to work on > it, not on whether it is in a particular list. Agreed, but it's the projects responsibility to take the tierness and the intend to support multiple platforms serious and not to chicken out at the first signs of complications or hurdles. We labeled sparc64 as a tier 1 platform and we better deal with the consequences. As for alpha, we don't even seem to be able to degrade it to tier 2 without losing face. kris@ has already stopped package builds for it for his own sake. Wake up, people. This is quickly becoming a joke... -- Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADS UP! KSE needs more attention
On Sun, Jun 06, 2004 at 02:27:08PM -0600, Scott Long wrote: > > > >Doug Rabson also has basic TLS support working in perforce. > > What platforms? My understanding was that new binutils and gcc was > needed for sparc64 at a minimum. Yes. It's i386 only and not even close to being complete. In fact, there has been discussions that the thread pointer on i386 needs to change. Whether that's the case or not, it's likely that TLS will complicate matters way too much to for it to ever work in 5.3. > >It'd be nice to get TLS and debugging in before 5.3-release. > > > > Yes. Be aware that there is a serious effort to get GDB 6.x into the > tree for 5.3. I just asked cvs@ and core@ to advice about importing gdb 6.1 into src/contrib/gdb6. We need to break this vicious circle of people waiting on each other. > That presents us with a bit of a dilemma since David's > work is against GDB 5.x. And not even complete. There are still issues that haven't found a solution or even compromise and it too is only for i386. -- Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADS UP! KSE needs more attention
Marcel Moolenaar wrote: On Sun, Jun 06, 2004 at 01:14:57PM -0600, Scott Long wrote: All, We are about 4-6 weeks away from starting the 5.3 release cycle. As it stands, KSE still only works reliably on i386. I don't have any problems on ia64. Good to hear =-) ... I'm willing to drop the alpha requirement and maybe even the sparc64 requirement, but there absolutely will not be a 5.3 until amd64 is solid. I think sparc64 should have KSE too. If we already accept that sparc64 is feature incomplete, we set/acknowledge a really bad precedence. I do too, but there is the difficult fact in that there are few people out there that are willing to work on sparc64. One person offered to try to learn it and tackle it, but that's a lot to ask. As with Alpha, the fate of a platform rests on the people who are willing to work on it, not on whether it is in a particular list. Scott ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADS UP! KSE needs more attention
Daniel Eischen wrote: On Sun, 6 Jun 2004, Scott Long wrote: All, We are about 4-6 weeks away from starting the 5.3 release cycle. As it stands, KSE still only works reliably on i386. There are reports of significant instability on amd64, and it doesn't work at all on alpha and sparc64. I'm willing to drop the alpha requirement and maybe even the sparc64 requirement, but there absolutely will not be a 5.3 until amd64 is solid. Please contact myself, Dan Eischen, and David Xu if you are interested in helping out. amd64 looks to be a problem in readline which doesn't seem to redispatch signal handlers with SA_SIGINFO arguments. David also has patches for debugging support at: http://people.freebsd.org/~davidxu/kse/dbg/ Doug Rabson also has basic TLS support working in perforce. What platforms? My understanding was that new binutils and gcc was needed for sparc64 at a minimum. It'd be nice to get TLS and debugging in before 5.3-release. Yes. Be aware that there is a serious effort to get GDB 6.x into the tree for 5.3. That presents us with a bit of a dilemma since David's work is against GDB 5.x. It's hard to back off on the GDB 6 requirement since it is needed for amd64 and sparc64. We need to get David, Marcel, David O'brien, and Alexander Kabaev together to work out the combined picture. Scott ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADS UP! KSE needs more attention
On Sun, 6 Jun 2004, Scott Long wrote: > All, > > We are about 4-6 weeks away from starting the 5.3 release cycle. As it > stands, KSE still only works reliably on i386. There are reports of > significant instability on amd64, and it doesn't work at all on alpha > and sparc64. I'm willing to drop the alpha requirement and maybe even > the sparc64 requirement, but there absolutely will not be a 5.3 until > amd64 is solid. Please contact myself, Dan Eischen, and David Xu if > you are interested in helping out. amd64 looks to be a problem in readline which doesn't seem to redispatch signal handlers with SA_SIGINFO arguments. David also has patches for debugging support at: http://people.freebsd.org/~davidxu/kse/dbg/ Doug Rabson also has basic TLS support working in perforce. It'd be nice to get TLS and debugging in before 5.3-release. -- Dan Eischen ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADS UP! KSE needs more attention
On Sun, Jun 06, 2004 at 01:14:57PM -0600, Scott Long wrote: > All, > > We are about 4-6 weeks away from starting the 5.3 release cycle. As it > stands, KSE still only works reliably on i386. I don't have any problems on ia64. > ... I'm willing to drop the alpha requirement and maybe even > the sparc64 requirement, but there absolutely will not be a 5.3 until > amd64 is solid. I think sparc64 should have KSE too. If we already accept that sparc64 is feature incomplete, we set/acknowledge a really bad precedence. -- Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
HEADS UP! KSE needs more attention
All, We are about 4-6 weeks away from starting the 5.3 release cycle. As it stands, KSE still only works reliably on i386. There are reports of significant instability on amd64, and it doesn't work at all on alpha and sparc64. I'm willing to drop the alpha requirement and maybe even the sparc64 requirement, but there absolutely will not be a 5.3 until amd64 is solid. Please contact myself, Dan Eischen, and David Xu if you are interested in helping out. Thanks, Scott ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Odd requestion: EISA Configuration disk
Hi, At 16:16 06/06/2004, M. Warner Losh wrote: I have managed to really mess up my NEC Express/II P90LT EISA system that I've been trying to get up for some eisa rework I'm doing. Can anybody send me the base motherboard configuration program as well as the aic7770 config files (the ones I've found on the net, along with the configuration program has made a big paperweight out of my box). Thanks for any help you might be able to provide in this matter. Warner Try http://support.necsam.com/downloads/search/default.htm -- Bob Bishop +44 (0)118 977 4017 [EMAIL PROTECTED] fax +44 (0)118 989 4254 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Odd requestion: EISA Configuration disk
I have managed to really mess up my NEC Express/II P90LT EISA system that I've been trying to get up for some eisa rework I'm doing. Can anybody send me the base motherboard configuration program as well as the aic7770 config files (the ones I've found on the net, along with the configuration program has made a big paperweight out of my box). Thanks for any help you might be able to provide in this matter. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Semantics of "seteuid(uid)" vs. "setreuid(-1,uid)"
Any reason, that there is a difference in semantics between: seteuid(id) vs. setreuid(-1, id)??? The tests performed on the arguments are different (assuming a fixed arg of -1 for ruid) in that seteuid does not support the case of (euid == cr_uid): seteuid(euid): euid != oldcred->cr_ruid && euid != oldcred->cr_svuid setreuid(-1, euid): euid != oldcred->cr_uid && euid != oldcred->cr_ruid && euid != oldcred->cr_svuid So seteuid() may fail in cases where setreuid() with a first argument of -1 succeeds. The test obviously corresponds to POSIX appendix B.4.2.2 as mentioned in the comment in setuid(). Is the difference between seteuid() and setreuid() deliberate ? I'm asking because I have received a bug report for a port, and it appears that seteuid() on other systems is indeed equivalent to our setreuid(-1,). Regards, STefan ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
machine is unusable with panic: vrele: negative ref cnt
On boot I see the following on an IBM T30 laptop: Mounting root from ufs:/dev/ad0s1a WARNING: / was not properly dismounted ad0: FAILURE - READ_MUL status=59 error=40 LBA=376639 ad0: FAILURE - READ_MUL status=59 error=40 LBA=376639 ad0: FAILURE - READ_MUL status=59 error=40 LBA=376639 ad0: FAILURE - READ_MUL status=59 error=40 LBA=376639 ad0: FAILURE - READ_MUL status=59 error=40 LBA=376639 ad0: FAILURE - READ_MUL status=59 error=40 LBA=376639 ad0: FAILURE - READ_MUL status=59 error=40 LBA=376639 panic: vrele: negative ref cnt syncing disks, buffers remaining... 9 9 9 9 9 9 9 9 9 9 \giving up on 9 buffers. And the same occurs on every reboot and the machine isn't usable anymore. I'd like to salvage the data that's in the hard disk. Any ideas on how ro recover data from the hard disk? The disk is only 4 months old. Thanks, Alan Evans ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD 5.2.1: Mutex/Spinlock starvation?
Hi Robert, As promised my findings regarding the changes; just came home after a night of trying and praying :) > Actually, by default, most mutexes in the system are sleep mutexes, so > they sleep on contention rather than spinning. In some cases, this > actually hurts more than spinning, because if the mutex is released > quickly by the holder, then you pay the context switches which cost > more than spinning for the short period of time. > > You might want to try adding "options ADAPTIVE_MUTEXES" to your kernel > configuration, which will cause mutexes to spin briefly on SMP systems > before sleeping, and has been observed to improve performance quite a > bit. > I tried this; this helps performance a lot, here are the findings: - under all conditions turning on HTT helps a *lot* (which is logical i think) - under non killing load (killing load = load where server would have crashed without this option) it performs much much better - under killing load it performs a lot better, up until a certain level: - a new killing level: from this point onward basically the same thing happens as before.. What i'm guessing is that probably this new killing level occurs when load is so high that the spins 'adapt' into blocks. From your description above I understand that there's a certain timeout when 'spinning' mutexes turn into 'blocking'/'sleeping' mutexes. Is there a way to set this timeout ? I would very much like to try out what would happen if one would set this timeout to a quite high value. Appart from this i also tried options ZERO_COPY_SOCKET, but that didnt seem to help much, if at all. Furthermore I tried out SCHED_ULE which was dramatic! I'm not sure if i'm the only one, but the performance was really terrible. i switched it off again as soon as i could. Also what I was wondering: do processes that go into sleep-mutex mode go into the same waiting queue as normal processes, or do they go into a special queue? Could this problem basically boil down to a scheduler being to slow (or the context switching) for these amounts of processes waiting/blocking ? If so could it be an idea to put blocking processes into a special queue in which the scheduler adepts simple scheduling algorithm (such as first come first serve, or random, or whatever) to dramatically reduce rescheduling time ? Best Regards, Ali Niknam ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
A subtle libstand bug?
Hi there, I'm sorry to report the problem I observed in so little detail, but OTOH I feel I must notify the community about it. I'm afraid there's too little detail for a PR. Yesterday I did binary upgrade of my home system, from 4.9-R to 4.10-R. Then I merged my old /etc into the new one. Of course, I just did "mv /etc.old/fstab /etc". After that, the kernel started to ask for the root device. Having played with loader(8) in the past, I concluded that something was wrong with my /etc/fstab, because I knew loader(8) would consult it for the root device name to pass to the kernel. I added some debugging printfs to getrootmount(), in sys/boot/common/boot.c, and saw that /etc/fstab was opened OK, but nothing could be read from it as though it was empty. At the same time, fsck reported no errors in the file system. And then I did a mistake: I issued, "cp /etc/fstab /etc/fstab2 && mv /etc/fstab2 /etc/fstab". The problem vanished, and I could reproduce it no more. >From this experience I suppose that there is a subtle bug in libstand that must be related to reading FFS directories or inodes. A libstand wizard might have insight into it. -- Yar ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
