date:20080605

--On Friday, June 06, 2008 00:19:05 +0200 Miroslav Lachman <[EMAIL PROTECTED]> 
wrote:



Paul Schmehl wrote:


--On Thursday, June 05, 2008 19:10:19 +0200 Pieter de Goeje
<[EMAIL PROTECTED]> wrote:



There's a really easy way to test this. Build & install a new kernel, but
keep  the old kernel around (by default it's in /boot/kernel.old). If the
problem  is gone, do the upgrade as usual. If it's still there, you know
upgrading  won't fix it and you don't waste time; simply rename
kernel.old to
kernel.  This even works with 7.0 provided that you leave
COMPAT_FREEBSD6 in
the  kernel configuration file.



It's not quite that simple.  To do that, I have to block out time to
drive 45 miles during my supposed "off" hours and do the upgrade there.
Because, if it breaks networking and I'm at home, the server will be
down for at least an hour until I can drive to the hosting company, get
access to the server and restore the old kernel.

Again, I'm not complaining.  Just sayin' that sometimes stuff ain't
quite as easy to do as folks who are surrounded by hardware and test
platforms assume it is.


I fully understand your situation, but I think there is still way to try...
You can use `nextboot` command. If you install new kernel in to
/boot/kernel.new/ directory, just use: nextboot -k kernel.new and then reboot
the server. New kernel will be used for this (and only this) cycle. So if
something goes wrong and you have any possibility to reboot server again (PDU
or by phone call to collocation), you will be back with old good kernel
without need to travel.

I did it a few times and it saved me ;)


Thank you.  I was unaware of the nextboot command.  That's a valuable tidbit 
that I will benefit from.


Thank you very much.

--
Paul Schmehl
As if it wasn't already obvious,
my opinions are my own and not
those of my employer.

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: challenge: end of life for 6.2 is premature with buggy 6.3

--On Friday, June 06, 2008 08:02:44 +1000 Peter Jeremy 
<[EMAIL PROTECTED]> wrote:



On 2008-Jun-05 10:33:18 -0500, Paul Schmehl <[EMAIL PROTECTED]> wrote:

--On Thursday, June 05, 2008 18:39:07 +1000 Peter Jeremy
<[EMAIL PROTECTED]> wrote:


On 2008-Jun-04 22:22:33 -0700, Jo Rhett <[EMAIL PROTECTED]> wrote:

And please stop with the loaded language.  I'm not asking anyone to work
for me.  I am suggesting that it is perhaps too early to EoL 6.2 because
6.3 isn't ready yet.


So you have stated.  When asked to provide evidence to backup that
statement, you have refused.  Since you are the one claiming that
"6.3 isn't ready yet", the onus is on you to put up or shut up.


That is a blatant lie.


I take exception to being called a lier.  Please either explain which of
my above statements is false or apologise.


I apologize.  I reacted in anger because I felt the OP was being savagely 
attacked rather than being responded to with professionalism.  Later in the 
thread some folks got around to asking which PRs he was referring to, but that 
was after attacking him for having the temerity to suggest that perhaps 6.2 
shouldn't be EOL.





 He has stated repeatedly that there are *known*
bugs, complete with bug reports, that are not resolved and that affect the
hardware he uses.  He has also stated that there is no need for him to
provide further evidence of an already documented bug,


I agree that he has made those statements - and those statements may
even be true.  When asked to provide details of the bugs or references
to those problems, he has refused.  Random, unsubstantiated claims are
hardly evidence of anything.



I don't recall him ever refusing.  I think after his initial post he's been 
forced to defend himself from attack from 360 degrees.  It's rather hard to 
focus on the facts when you're being attacked like that.  That's what provoked 
me to respond as I did - to you and to others.




To summarise, so far the OP has made a series of unsubstantianted
claims about vaguely defined problems on vaguely defined hardware.
When asked for more details, he has refused.


I think that's an unfair characterization.  He stated that he had noted 
numerous bugs in 6.3 (submitted PRs) that he perceived affected him personally 
and so he chose not to update to 6.3.  He then asked if 6.2 couldn't be 
extended farther.  That seems like a reasonable question to ask.  A simple, 
professional answer would have settled the matter quickly.


But it was all downhill from there.

I'm not here to defend him.  He can do that himself.  What I took offense to 
was the gang mentality of jumping on him and accusing him of things no one 
could possibly have knowledge of and the childish, immature reaction of some on 
the list.



 Exactly what do you expect the FreeBSD developers to do?



I expect the FreeBSD developers to continue to produce the highest quality OS 
on the market.  I also expect them to treat their customers with respect and 
professionalism and patience.  I don't think that's too much to ask.  Shouldn't 
the developers' behavior match the high quality of their work?


I recently had to deal with two PRs for ports that I maintain.  I initially 
thought both were rather silly.  After testing, I found that one was not, and 
in fact, the user had uncovered a problem I would never have thought to test 
for (and obviously hadn't.)


Had I jumped on them for not giving more details or harangued the committer for 
not pointing out my errors, I would have missed an opportunity to improve both 
a port and my knowledge of porting.  But I withheld my personal views and 
approached both submitters with respect and professionalism.  In the end, I was 
wrong.  But no one but me knew that (until now) because I withheld my personal, 
emotional response.


I'm not bragging.  I don't think that's anything to brag about.  I just think 
we'd all benefit if we could keep the personal opinions personal and deal with 
requests on the list with respect and professionalism, just as we would like to 
be treated.



yet he is willing to
provide equipment with 6.3 RELEASE installed if any developer needs a
platform to test and troubleshoot the bugs.


In the absence of any details about the problems he believes he has,
such an offer is meaningless.


You can't possibly mean that.  Your choice of words is horrible.  How can it 
ever be meaningless to offer assistance to the community, however small?  I've 
noticed this attitude on more than one occasion.  It's as if "we" are the 
little people, not fit to be in the same room with the mighty developers.


Rest assured, each of us has talents that others can't match and each of us has 
weaknesses that others can expose.  We'd all be better off if we focused on the 
former and de-emphasized the latter.



 Reading his actual posting, it reads
more like "who would like to do my QA/validation for me and fix any
bugs they find for free".  In general, the underlying problem is lack
of deve

Re: challenge: end of life for 6.2 is premature with buggy 6.3

2008-06-05 Thread Scott Long


Jo Rhett wrote:

On Jun 4, 2008, at 5:44 PM, Scott Long wrote:
Really, if it's such a big issue that you have time to bitch an moan 
on the mailing lists, I don't understand why you don't have time to also

help a goddamned developer identify the problem.  Are you actually
experiencing problems with 6.3, or not?



None of the bugs were in a state with the developer trying to identify 
the system.  We have several systems dedicated for FreeBSD developers to 
use for test cases already, and we'd be happy to provide another if one 
was necessary.




What is needed prior to talking about loaner systems and test cases is
for you to say, "Hardware XYZ isn't working for me anymore.  It used to
do FOO, and now it does BAR."  That's the first step.  It's a simple
step, but it's an essential step.  Seriously.  And if you aren't
actually experiencing any problems, then all I can say is that your
input on the release and support process has been noted, and we all
look forward to bug reports from you in the future.  And before you
circle back on the "but but but the PR database shows unresolved bugs"
argument, understand that few of us on this mailing lists are idiots;
we know how to read, and we are aware that there are PR entries.  What
pushes a stalled PR along, though, is having an interested party bring
it up and offer insight into the specifics of it.  Just pointing from
afar adds nothing to the process.  You're welcome to disagree on that
point, but it seems pretty clear that continuing to argue it in this
forum isn't really solving anything.

So I'll try one last time you seem to be concerned about possible
bugs in the the 3ware and broadcom drivers.  Can you please provide
specifics on what you are concerned about?  Any personal insight or
experience you have would be highly helpful and appreciated.

Scott

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: challenge: end of life for 6.2 is premature with buggy 6.3

2008-06-05 Thread Miroslav Lachman


Paul Schmehl wrote:

--On Thursday, June 05, 2008 19:10:19 +0200 Pieter de Goeje 
<[EMAIL PROTECTED]> wrote:




There's a really easy way to test this. Build & install a new kernel, but
keep  the old kernel around (by default it's in /boot/kernel.old). If the
problem  is gone, do the upgrade as usual. If it's still there, you know
upgrading  won't fix it and you don't waste time; simply rename 
kernel.old to
kernel.  This even works with 7.0 provided that you leave 
COMPAT_FREEBSD6 in

the  kernel configuration file.



It's not quite that simple.  To do that, I have to block out time to 
drive 45 miles during my supposed "off" hours and do the upgrade there.  
Because, if it breaks networking and I'm at home, the server will be 
down for at least an hour until I can drive to the hosting company, get 
access to the server and restore the old kernel.


Again, I'm not complaining.  Just sayin' that sometimes stuff ain't 
quite as easy to do as folks who are surrounded by hardware and test 
platforms assume it is.


I fully understand your situation, but I think there is still way to try...
You can use `nextboot` command. If you install new kernel in to 
/boot/kernel.new/ directory, just use: nextboot -k kernel.new and then 
reboot the server. New kernel will be used for this (and only this) 
cycle. So if something goes wrong and you have any possibility to reboot 
server again (PDU or by phone call to collocation), you will be back 
with old good kernel without need to travel.


I did it a few times and it saved me ;)

Miroslav Lachman
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: challenge: end of life for 6.2 is premature with buggy 6.3

2008-06-05 Thread Peter Jeremy

On 2008-Jun-05 10:33:18 -0500, Paul Schmehl <[EMAIL PROTECTED]> wrote:
>--On Thursday, June 05, 2008 18:39:07 +1000 Peter Jeremy 
><[EMAIL PROTECTED]> wrote:
>
>> On 2008-Jun-04 22:22:33 -0700, Jo Rhett <[EMAIL PROTECTED]> wrote:
>>> And please stop with the loaded language.  I'm not asking anyone to work
>>> for me.  I am suggesting that it is perhaps too early to EoL 6.2 because
>>> 6.3 isn't ready yet.
>> 
>> So you have stated.  When asked to provide evidence to backup that
>> statement, you have refused.  Since you are the one claiming that
>> "6.3 isn't ready yet", the onus is on you to put up or shut up.
>
>That is a blatant lie.

I take exception to being called a lier.  Please either explain which of
my above statements is false or apologise.

>  He has stated repeatedly that there are *known* 
>bugs, complete with bug reports, that are not resolved and that affect the 
>hardware he uses.  He has also stated that there is no need for him to 
>provide further evidence of an already documented bug,

I agree that he has made those statements - and those statements may
even be true.  When asked to provide details of the bugs or references
to those problems, he has refused.  Random, unsubstantiated claims are
hardly evidence of anything.

I have checked back through this thread and the provided descriptions
of the problems that he believes affect him are (to quote him)
"gmirror failures, 3ware raid driver timeouts, bge0 problems".  Note
that he hasn't done any testing to verify that these problems actually
affect his hardware environment.  When asked to, he refused.
Likewise, he describes his systems as (again, quoting him) "Rackable
systems with 3ware controllers".  (I note that in another post, you
complain about a problem you are having - though you are able to
provide details of both the problem and your hardware/software
environment).

To summarise, so far the OP has made a series of unsubstantianted
claims about vaguely defined problems on vaguely defined hardware.
When asked for more details, he has refused.  Exactly what do you
expect the FreeBSD developers to do?

> yet he is willing to 
>provide equipment with 6.3 RELEASE installed if any developer needs a 
>platform to test and troubleshoot the bugs.

In the absence of any details about the problems he believes he has,
such an offer is meaningless.  Reading his actual posting, it reads
more like "who would like to do my QA/validation for me and fix any
bugs they find for free".  In general, the underlying problem is lack
of developer resources, rather than lack of hardware.

>What is the purpose of the insults and denigration?

I fail to see where I have insulted or denigrated anyone.  OTOH, your
first words to me were an insult.

-- 
Peter Jeremy
Please excuse any delays as the result of my ISP's inability to implement
an MTA that is either RFC2821-compliant or matches their claimed behaviour.

pgpFsusbACJ2d.pgp
Description: PGP signature

Re: gmirror patches

2008-06-05 Thread Miroslav Lachman


Pete French wrote:

Has anybody else had a chance to try the gmirror patches I posted here a
few weeks ago ? I;ve had no feedback so far - not sre if thats good
news or just that nobody tried them. they can be found here if
people are interested:

http://www.freebsd.org/cgi/query-pr.cgi?pr=123630

I;ve been running ths for a month with no ill effecets whatsoever, and would
very much like to get this commited somehow. I am not sure of the best
way to do this though, as it's not an actual bug per-se. Whom would I
approach about getting this added to the tree ?


You can get more attention in [EMAIL PROTECTED] mailinglist and 
gmirror autor - P.J. Dawidek. [EMAIL PROTECTED]


Miroslav Lachman
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: CLARITY re: challenge: end of life for 6.2 is premature with buggy 6.3

2008-06-05 Thread Torfinn Ingolfsen

On Thu, 05 Jun 2008 10:01:40 -0700
Doug Barton <[EMAIL PROTECTED]> wrote:

> Torfinn Ingolfsen wrote:
> > On Thu, 05 Jun 2008 05:51:05 -0700
> > Jeremy Chadwick <[EMAIL PROTECTED]> wrote:
> > 
> >> Offering monetary compensation is not a solution, and I believe
> >> that's because the core problem isn't lack of pay -- it's lack of
> >> time. That's one which is really hard to solve, no matter what the
> >> conditions of an open-source project.
> > 
> > Hmm, perhaps you and others should train people instead?
> > Offer to pay a student to learn FreeBSD, and to train her / him as
> > developer.
> 
> http://www.freebsd.org/projects/summerofcode-2008.html

Yes, I know about Google SoC, and it is a good thing (a _very_ good
thing). I was thinking more along the lines that if offering money for
fixing stuff doesn't work, then maybe getting more interest (in
addition to SoC) would work better.

Therer must be a reason why nobody has formed a commercial compnay to
fix bugs / develop new features fro FreeBSD (either with own employees
or with hired people) already.
To me, that means that the demand isn't big enough to make it a viable
business plan.
-- 
Regards,
Torfinn Ingolfsen,
Norway

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: challenge: end of life for 6.2 is premature with buggy 6.3

--On Thursday, June 05, 2008 14:22:00 -0400 John Baldwin <[EMAIL PROTECTED]> 
wrote:


I find that bce(4) is far more reliable in 6.3 than 6.1 for us.  There have
been several fixes (esp. for higher loads, and mostly in 6.2) to this driver.
There are known panics in earlier 6.x that are fixed in 6.3 for certain with
this driver.



Thanks.  Knowing that gives me a lot more confidence to go ahead and build a 
new kernel for that server.



In general though, you don't know which bugs are fixed and if any regressions
are present w/o testing the code.  If you have production systems then
hopefully you have QA systems for development, etc. and you can either reuse
those when app QA isn't active for OS QA or you can get dedicated boxes for
OS QA.  Even if you used a commercial OS with a support contract you would
need to do the same.


Again, that would be nice, but **just like FreeBSD** this is an all volunteer 
project where both time and money are at a premium.  If I had a dollar for 
every time my wife complained about me using my valuable free time to support 
this site without any compensation, I could probably afford a test bed. :-)


--
Paul Schmehl
As if it wasn't already obvious,
my opinions are my own and not
those of my employer.

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: challenge: end of life for 6.2 is premature with buggy 6.3


Paul Schmehl wrote:
--On Thursday, June 05, 2008 17:53:01 +0100 Tom Evans 
<[EMAIL PROTECTED]> wrote:


I think that, especially with open source products, there is a large
emphasis on testing in your own environments, and choosing the 'correct'
version of a particular software package is important. For example, at
$JOB, we had a lot of servers running 6.1 as it was an extended lifetime
release, so no point jumping to 6.2, instead we waited for 6.3 to pass
our integration testing.



Not everyone has those kinds of resources.  The domain I'm referring to 
is a hobby site, run by a husband and wife.  They started with shared 
hosting and moved to a dedicated box when I volunteered to help with the 
backend work.  For several years we ran one server hosting dns, imaps, 
smtps, mail lists and websites.


Yes, it's not ideal, but when you have zero income you do what you can. 
Testing like you describe is out of the question.


We now have the embarrassment of riches of two servers; one for web and 
the old one for the rest.  The old box is still running 5.4 SECURITY.  
The new box is running 6.1.  I'd *like* to upgrade both boxes, and the 
older box can go offline comfortably for several hours without anyone 
but me noticing.  But if the web box goes down for 30 seconds, queries 
from the users start pouring in.


Come now, even some of the biggest websites on the planet have scheduled 
downtime :)


Kris
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: challenge: end of life for 6.2 is premature with buggy 6.3

2008-06-05 Thread Mark Linimon

On Thu, Jun 05, 2008 at 05:39:36PM +0200, Kris Kennaway wrote:
> You seem awful hostile - do you really think that's the best way to
> represent the project you're involved with?

When confronted with "what you are doing is wrong, but I am not going
to tell you what it is because if you cared you'd already know" (my
summary of your past postings in this thread)? Possibly not 'best' but
'understandable'.

> The option provided seems like a fairly good compromise to both
> interests. Pick 6.3 (or anything the release team wishes) to support
> for a longer period of time.

If you want FreeBSD to be supported the same as a commercial product,
and you be able to dictate the terms, then it's not going to happen
completely via volunteer effort. At some point some money is going to
have to change hands. Either you pay someone at your company to do
support, or you hire someone external.

Then you get to dictate what is supported and for how long. Otherwise,
all you can do is to suggest. A "consensus statement" signed off on
by one person is the former -- not the latter.

Now to add my own frustration to the list ...

I next note that _after_ you said you had no more time to continue
with this thread for now (and thus could not yet give us pointers to
specific failures and any corresponding PR numbers), you are still
replying to email. Since you still seem to have some time, let me
help you do a little research here.

Checking the PRs that you have submitted that are still current, none
of the src-related ones are from anything newer than 6.0R:

http://www.freebsd.org/cgi/query-pr-summary.cgi?originator=Jo+Rhett

There are some resources to help you find already-submitted PRs to
reference if it will help. (The latter 2 are new, and are attempts
by the bugbusting team to flag 'well-known problem' and 'PR indicates
regression'):

http://wiki.freebsd.org/JeremyChadwick/Commonly_reported_issues
http://people.freebsd.org/~linimon/studies/prs/well_known_prs.html
http://people.freebsd.org/~linimon/studies/prs/prs_for_tag_regression.html

Now I'll admit the following is a less-obvious query of the database, but
it's my attempt to show regressions that we have already flagged in 6.3:

http://www.freebsd.org/cgi/query-pr-summary.cgi?release=%5EFreeBSD+6.3&category=kern&text=regression

So these 4 links should give you some quick ways to generate some PR
numbers for us.

Finally, here are some statistics about PR count:

rel all kern
--- ---
6.0 210 91
6.1 217 81
6.2 396 102
6.3 167 56
7.0 563 140

To me, this doesn't look like an overwhelming case for 6.3 being worse
off than 6.2. Yes, I'm sure there are regressions: there are in any
release.

mcl
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: challenge: end of life for 6.2 is premature with buggy 6.3

--On Thursday, June 05, 2008 19:10:19 +0200 Pieter de Goeje <[EMAIL PROTECTED]> 
wrote:


There's a really easy way to test this. Build & install a new kernel, but
keep  the old kernel around (by default it's in /boot/kernel.old). If the
problem  is gone, do the upgrade as usual. If it's still there, you know
upgrading  won't fix it and you don't waste time; simply rename kernel.old to
kernel.  This even works with 7.0 provided that you leave COMPAT_FREEBSD6 in
the  kernel configuration file.


It's not quite that simple.  To do that, I have to block out time to drive 45 
miles during my supposed "off" hours and do the upgrade there.  Because, if it 
breaks networking and I'm at home, the server will be down for at least an hour 
until I can drive to the hosting company, get access to the server and restore 
the old kernel.


Again, I'm not complaining.  Just sayin' that sometimes stuff ain't quite as 
easy to do as folks who are surrounded by hardware and test platforms assume it 
is.


--
Paul Schmehl
As if it wasn't already obvious,
my opinions are my own and not
those of my employer.

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: challenge: end of life for 6.2 is premature with buggy 6.3

--On Thursday, June 05, 2008 17:53:01 +0100 Tom Evans 
<[EMAIL PROTECTED]> wrote:


I think that, especially with open source products, there is a large
emphasis on testing in your own environments, and choosing the 'correct'
version of a particular software package is important. For example, at
$JOB, we had a lot of servers running 6.1 as it was an extended lifetime
release, so no point jumping to 6.2, instead we waited for 6.3 to pass
our integration testing.



Not everyone has those kinds of resources.  The domain I'm referring to is a 
hobby site, run by a husband and wife.  They started with shared hosting and 
moved to a dedicated box when I volunteered to help with the backend work.  For 
several years we ran one server hosting dns, imaps, smtps, mail lists and 
websites.


Yes, it's not ideal, but when you have zero income you do what you can. 
Testing like you describe is out of the question.


We now have the embarrassment of riches of two servers; one for web and the old 
one for the rest.  The old box is still running 5.4 SECURITY.  The new box is 
running 6.1.  I'd *like* to upgrade both boxes, and the older box can go 
offline comfortably for several hours without anyone but me noticing.  But if 
the web box goes down for 30 seconds, queries from the users start pouring in.



We buy usually the same chassis for all our servers, and test
extensively before deploying to a new chassis/OS/anything. This is the
definition of change management, which is expensive, takes lots of time
and planning, and doesn't guarantee zaroo bugs - just a high likelihood
of not hitting them. It also isn't smooth, when we tested 6.1, we found
a multitude of bugs in bce(4), which we worked with net@ and David
Christensen of Broadcom to get fixed (they work lovely now :).



Wouldn't that be nice!  Unfortunately, it's not reality for some of us.  And 
I'm not going to run anything but FreeBSD, because it's the best open source 
solution there is, bar none.  When I run into problems I usually don't say much 
on the lists.  I use Google and read diffs and try to do my best to figure it 
out on my own.  But testing?  Not a chance?  Contributing?  I do what I can.  I 
maintain a bunch of ports.  I'm not a developer, and I can't "read" code and 
figure out what's going on except for the simplest of tasks.


--
Paul Schmehl
As if it wasn't already obvious,
my opinions are my own and not
those of my employer.

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: challenge: end of life for 6.2 is premature with buggy 6.3

2008-06-05 Thread Mark Linimon

kris points out that I botched my reply by confusing contributions
from 2 different posters.  My apologies (I have not closely tracked
the entire thread).

Nevertheless, the URLs and the summary information should still be of
interest.

mcl
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: challenge: end of life for 6.2 is premature with buggy 6.3

On Thursday 05 June 2008 12:14:20 pm Paul Schmehl wrote:
> --On Thursday, June 05, 2008 10:23:55 -0400 John Baldwin <[EMAIL PROTECTED]> 
> wrote:
> >
> > FWIW, at Y! 6.3 is more stable than 6.2 (I had a list of about 10 patches 
> > for
> > known deadlocks and kernel panics that were errata candidates for 6.2 that
> > never made it into RELENG_6_2 but all of them are in 6.3).  We also have 
> > many
> > machines with bge(4) and from our perspective 6.3 has less issues with bge0
> > devices than 6.2.
> >
> 
> I'm glad to hear that.  I have a server that uses bce, and it was completely 
> non-functional until I hunted down some beta code that made it usable.  I'd 
> like to upgrade, but this is a critical server with no redundancy (and it's a 
> hobby site with no money to pay for expensive support), and I'm not about to 
> upgrade unless I know for certain the problems won't reoccur, because I have 
> to 
> upgrade remotely and pay money if the system goes down.

I find that bce(4) is far more reliable in 6.3 than 6.1 for us.  There have
been several fixes (esp. for higher loads, and mostly in 6.2) to this driver.
There are known panics in earlier 6.x that are fixed in 6.3 for certain with
this driver.

In general though, you don't know which bugs are fixed and if any regressions
are present w/o testing the code.  If you have production systems then
hopefully you have QA systems for development, etc. and you can either reuse
those when app QA isn't active for OS QA or you can get dedicated boxes for
OS QA.  Even if you used a commercial OS with a support contract you would
need to do the same.

-- 
John Baldwin
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: challenge: end of life for 6.2 is premature with buggy 6.3

2008-06-05 Thread Dag-Erling Smørgrav

Chris Marlatt <[EMAIL PROTECTED]> writes:
> This may or may not be the case. Like I said if it's a horrible idea
> sorry for wasting your time. But it seems fairly logical to me as a
> good solution to the problem and should net the team more time for
> things that really count.

How does *increasing our workload* free up "more time for things that
really count"?

DES
-- 
Dag-Erling Smørgrav - [EMAIL PROTECTED]
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: challenge: end of life for 6.2 is premature with buggy 6.3

Doug Barton wrote:

Chris Marlatt wrote:

Adrian Chadd wrote:

The project is doing what it can with what people are contributing. If

What if it can accomplish the same or more by simply reorganizing what
it's already doing?

I think that the problem here is that you have no idea how absurd you
sound to the people who are actually doing the work.

Forgive me for not knowing how people I've never met or conversed with
before would accept my proposal. I'll do better next time.

Taking what you said at face value for a minute, a polite response
would be something along the lines of, "At this point in the project's
history we've already given lengthy and careful consideration to the
resources we have available, and how best to allocate them. FreeBSD is
a volunteer project, and with few exceptions those who put work into
it are doing it 'for fun,' and choose where they want to apply their
efforts. Suggestions are often made about where effort can be best
applied, some private, some public. But in the end it's the individual
developer who chooses what to work on, and the project leadership
tries to keep things moving smoothly with the resources available."

Now let me approach this from another angle, which is how what you
said above can easily sound to us. "Hey you volunteers! It's great
that you're working on FreeBSD and giving it to me for free and all,
but what I really want you to do is this, so get to it will you?" I'm
sure you can imagine the response to that.

And frankly, it doesn't even matter which way you _meant_ it. And
sure, you have the right to voice your opinion, all FreeBSD users do.
You also need to be prepared to take "no" for an answer.

So take a line from yourself. This isn't grade school. If you or members
of your team can't take constructive criticism then you need to grow up.
FreeBSD isn't a toy. Thousands of people rely on it for a variety of
reasons. Which strangely enough is likely one of the primary reasons the
team enjoys volunteering the time that they do. It means so much to so
many people. However those same people are the ones who's concerns are
being replied with "do it yourself or go away".

I'm completely prepared to hear no - assuming it's a no with some sense
behind it. As I've said more than once if it's a horrible idea fine. But
it's one I haven't seen proposed before.

you'd like a distribution supported for longer then offer to help
maintain it. You may be surprised how helpful people get when you
offer to help. :0

Again IMHO the only message coming across here is either do it
yourself or keep your mouth shut.

That's not _exactly_ what we're saying, but it's pretty close. This is
open source after all. "If you can't find what you're looking for,
build it, or look elsewhere" would be a better way to say it.

The other side of the coin here is - what's to say the FreeBSD project
requires what I can offer?

Without trying to sound rude, I'm pretty sure the only person that's
going to matter to is you.

I respectfully disagree.

Granted it's been sometime since I've browsed the entire FreeBSD.org
site but last I checked there wasn't an area devoted to

the needs of the project.

http://www.freebsd.org/cgi/query-pr-summary.cgi?category=&severity=&priority=&class=&state=&sort=none&text=&responsible=&multitext=&originator=&release=

If the only thing the FreeBSD project is in need of is time to work on
PR fixes than what I can offer isn't of much help. Which is why the
^original^ comment was made.

Furthermore, just because someone isn't providing assistance doesn't
mean that their concerns should go unheard.

This isn't the '80's, and we aren't in grade school. See above on
taking "no" for an answer.

What does this have to do with the 80's and again no is a perfectly
acceptable answer if it doesn't come along with a STFU.

It's quite possible what was proposed is an awful idea and if it is
so be it. But it would appear as though it wasn't even considered.

On the contrary. This, and lots of other ideas have been given very
careful consideration and have been rejected due to lack of resources.
There, feel better?

Yes because "Uh yeah, this has been in place for *years*. Have you
actually read the support announcements? They are public ;) " sounds
exactly like careful consideration.

Seriously folks, it's not as if we don't _want_ to be able to provide
better, longer, faster, $whatever support. We're just trying to be
realistic about what we can reasonably do with what we have available.

If you really want to then slow down the release schedule. I've seen a
lot less "I _must_ have this feature" than "Whoa! why are we going to
safe" threads. The project is creating a circumstance where offering
extended support is not an option.

hth,

Doug

Regards,

Chris
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freeb

Re: challenge: end of life for 6.2 is premature with buggy 6.3

2008-06-05 Thread Chris Rees

On Thursday, June 05, 2008 10:23:55 -0400 John Baldwin <[EMAIL PROTECTED]>
> wrote:

> I'm glad to hear that.  I have a server that uses bce, and it was completely
> non-functional until I hunted down some beta code that made it usable.  I'd
> like to upgrade, but this is a critical server with no redundancy (and it's a
> hobby site with no money to pay for expensive support), and I'm not about to
> upgrade unless I know for certain the problems won't reoccur, because I have 
> to
> upgrade remotely and pay money if the system goes down.
>
> The problems with that driver were bad enough when the server was being
> configured in my study.  (The system would lock up, and only a hard reboot
> would restore networking.)  It would be hell trying to troubleshoot problems 
> if
> I had to drive the 45 miles to the hosting site and spend a night there trying
> to get the server back up, then go to work the next day.
>
> # uname -a
> FreeBSD www.stovebolt.com 6.1-RELEASE-p10 FreeBSD 6.1-RELEASE-p10 #2: Mon Oct
> 16 15:38:02 CDT 2006 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC
> i386
>
> # grep bce /var/run/dmesg.boot
> bce0:  mem
> 0xf400-0xf5ff irq 16 at device 0.0 on pci9
> bce0: ASIC ID 0x57081010; Revision (B1); PCI-X 64-bit 133MHz
> miibus0:  on bce0
> bce0: Ethernet address: 00:13:72:fb:2a:ad
> bce1:  mem
> 0xf800-0xf9ff irq 16 at device 0.0 on pci5
> bce1: ASIC ID 0x57081010; Revision (B1); PCI-X 64-bit 133MHz
> miibus1:  on bce1
> bce1: Ethernet address: 00:13:72:fb:2a:ab
>
> # grep bce0 /var/log/messages
> May  2 09:10:31 www kernel: bce0: link state changed to DOWN
> May  2 09:10:39 www kernel: bce0: link state changed to UP
> May 25 07:49:49 www kernel: bce0: link state changed to DOWN
> May 25 07:50:31 www kernel: bce0: link state changed to UP
> May 26 21:28:36 www kernel: bce0: link state changed to DOWN
> May 26 21:28:40 www kernel: bce0: link state changed to UP
> May 27 13:13:21 www kernel: bce0: link state changed to DOWN
> May 27 13:13:31 www kernel: bce0: link state changed to UP
>
> It's been like that since the server was installed.
>
> So, if I upgrade to 6.3 or 7.0, am I still going to experience these problems?
> Is the server going to stop working entirely?  How can I know that for sure
> before starting an upgrade?

Damn, that's fascinating. I get that with nfe, on my xbox;


amnesiac# uname -a
FreeBSD amnesiac.bayofrum.net 7.0-RELEASE-p1 FreeBSD 7.0-RELEASE-p1
#9: Wed May 28 23:14:21 BST 2008
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/AMNESIAC  i386


amnesiac# uptime
 6:27PM  up 7 days, 18:53, 1 user, load averages: 0.00, 0.05, 0.06


amnesiac# tail /var/log/messages
Jun  3 17:39:31 amnesiac kernel: pid 37682 (python), uid 80 inumber
871485 on /usr/spare: filesystem full
Jun  4 17:07:24 amnesiac kernel: nfe0: link state changed to DOWN
Jun  4 17:07:34 amnesiac kernel: nfe0: link state changed to UP
Jun  4 17:07:40 amnesiac kernel: nfe0: link state changed to DOWN
Jun  4 17:07:54 amnesiac kernel: nfe0: link state changed to UP
Jun  4 18:39:50 amnesiac kernel: nfe0: link state changed to DOWN
Jun  4 18:40:01 amnesiac kernel: nfe0: link state changed to UP
Jun  4 18:40:07 amnesiac kernel: nfe0: link state changed to DOWN
Jun  4 18:40:21 amnesiac kernel: nfe0: link state changed to UP
Jun  5 18:26:58 amnesiac sudo:chris : TTY=ttyp0 ;
PWD=/usr/home/chris ; USER=root ; COMMAND=/usr/bin/su


Hm, I swear that's getting more regular. Anyway, it hasn't lost
permanantly yet, but I was just ignoring them (my Linux background
:$). Should I be worried??

I'll provide any other details if anyone's interested.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

[solved] Re: 7-STABLE: bridge and em

2008-06-05 Thread Boris Samorodov

Hi List!


Well, it took me a while to discover the case...

Provider attached my ethernet line to a switch and set up port
security to restrict to three MAC addresses which were already
used by two computers and a network printer.

As soon as provider deletted those restrictions all went well.

Thanks for all who helped me.


On Wed, 28 May 2008 02:15:18 +0400 Boris Samorodov wrote:

> When em0 has an inet address while bridge0 doesn't, it seems to be OK:
> -
> bs1% uname -a
> FreeBSD bs1.sp34.ru 7.0-STABLE FreeBSD 7.0-STABLE #0: Sun May 25 20:15:26 MSD 
> 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/BSM  i386
> bs1% ifconfig em0; ifconfig tap0; ifconfig bridge0
> em0: flags=8943 metric 0 mtu 
> 1500
>   options=98
>   ether 00:0c:f1:6c:37:4c
>   inet 192.168.16.30 netmask 0xff00 broadcast 192.168.16.255
>   media: Ethernet autoselect (100baseTX )
>   status: active
> tap0: flags=8943 metric 0 mtu 
> 1500
>   ether 00:bd:3e:24:00:00
> bridge0: flags=8843 metric 0 mtu 1500
>   ether ea:8b:1f:65:2a:5c
>   id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15
>   maxage 20 holdcnt 6 proto rstp maxaddr 100 timeout 1200
>   root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0
>   member: tap0 flags=143
>   ifmaxaddr 0 port 7 priority 128 path cost 200
>   member: em0 flags=143
>   ifmaxaddr 0 port 1 priority 128 path cost 200
> bs1% netstat -rn 
> Routing tables

> Internet:
> DestinationGatewayFlagsRefs  Use  Netif Expire
> default192.168.16.254 UGS 0  357em0
> 127.0.0.1  127.0.0.1  UH  0 3934lo0
> 192.168.16.0/24link#1 UC  00em0
> 192.168.16.1   00:07:e9:80:33:bc  UHLW1   16em0951
> 192.168.16.254 00:07:e9:80:33:bc  UHLW20em0   1002

> Internet6:
> Destination   Gateway   Flags  
> Netif Expire
> ::1   ::1   UHL 
> lo0
> fe80::%lo0/64 fe80::1%lo0   U   
> lo0
> fe80::1%lo0   link#5UHL 
> lo0
> ff01:5::/32   fe80::1%lo0   UC  
> lo0
> ff02::%lo0/32 fe80::1%lo0   UC  
> lo0
> bs1% ping -c 3 192.168.16.254 
> PING 192.168.16.254 (192.168.16.254): 56 data bytes
> 64 bytes from 192.168.16.254: icmp_seq=0 ttl=64 time=0.316 ms
> 64 bytes from 192.168.16.254: icmp_seq=1 ttl=64 time=0.263 ms
> 64 bytes from 192.168.16.254: icmp_seq=2 ttl=64 time=0.266 ms

> --- 192.168.16.254 ping statistics ---
> 3 packets transmitted, 3 packets received, 0.0% packet loss
> round-trip min/avg/max/stddev = 0.263/0.282/0.316/0.024 ms
> -

> But if I move ip address from em0 to bridge0:
> -
> bs1% sudo ifconfig em0 inet 192.168.16.30 netmask 0xff00 delete
> bs1% sudo ifconfig bridge0 inet 192.168.16.30 netmask 0xff00   
> bs1% sudo route add default 192.168.16.254 
> add net default: gateway 192.168.16.254
> bs1% ifconfig em0; ifconfig tap0; ifconfig bridge0 
> em0: flags=8943 metric 0 mtu 
> 1500
>   options=98
>   ether 00:0c:f1:6c:37:4c
>   media: Ethernet autoselect (100baseTX )
>   status: active
> tap0: flags=8943 metric 0 mtu 
> 1500
>   ether 00:bd:3e:24:00:00
> bridge0: flags=8843 metric 0 mtu 1500
>   ether ea:8b:1f:65:2a:5c
>   inet 192.168.16.30 netmask 0xff00 broadcast 192.168.16.255
>   id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15
>   maxage 20 holdcnt 6 proto rstp maxaddr 100 timeout 1200
>   root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0
>   member: tap0 flags=143
>   ifmaxaddr 0 port 7 priority 128 path cost 200
>   member: em0 flags=143
>   ifmaxaddr 0 port 1 priority 128 path cost 200
> bs1% netstat -rn   
> Routing tables

> Internet:
> DestinationGatewayFlagsRefs  Use  Netif Expire
> default192.168.16.254 UGS 00 bridge
> 127.0.0.1  127.0.0.1  UH  0 3934lo0
> 192.168.16.0/24link#6 UC  00 bridge
> 192.168.16.254 link#6 UHLW20 bridge

> Internet6:
> Destination   Gateway   Flags  
> Netif Expire
> ::1   ::1   UHL 
> lo0
> fe80::%lo0/64 fe80::1%lo0   U   
> lo0
> fe80::1%lo0   link#5UHL 
> lo0
> ff01:5::/32   fe80::1%lo0   UC  
> lo0
> ff02::%lo0/32

Re: Interrupt storm with shared interrupt on digi(4)

2008-06-05 Thread Alfred Perlstein

* John Baldwin <[EMAIL PROTECTED]> [080605 07:58] wrote:
> On Thursday 05 June 2008 02:19:31 am Alfred Perlstein wrote:
> > * John Baldwin <[EMAIL PROTECTED]> [080604 11:12] wrote:
> > > On Tuesday 03 June 2008 03:04:18 pm Peter Jeremy wrote:
> > > > BTW, your MUA's list-reply configuration don't recognize that
> > > > freebsd-stable@ and stable@ are aliases.
> > > 
> > > Yes, kmail is broken and the authors refuse to fix it.  It happens on 
> > > reply to 
> > > a foo@ e-mail (it changes the 'To' to 'freebsd-foo@' because of the 
> > > List-Id 
> > > header and leaves foo@ in the 'CC' field).  Note that there isn't 
> > > anything in 
> > > the List headers that says that foo@ is an alias for [EMAIL PROTECTED]  I 
> > > just 
> > > wish I could turn off the List-Id crap and use plain old reply-to-all, 
> > > but 
> > > that is where the kmail developers disagree.
> > 
> > wtf.why not just have a checkbox to toggle the behavior?
> 
> That was my request (and I found at least 2 other open bugs for the same issue
> when I looked again yesterday).  The developers reply was "an option is not an
> option".

Did you try sending him email with forged headers a few times with
List-Id set to something embarassing?

What's his email?  I'll do it.

-Alfred
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: challenge: end of life for 6.2 is premature with buggy 6.3

2008-06-05 Thread Doug Barton


Jo Rhett wrote:


On Jun 4, 2008, at 5:17 PM, Steven Hartland wrote:

I wouldn't be surprised if these are not new bugs, just something
that others have noticed later than 6.2 and I'd suggest you actually
try 6.3 to see if they are in fact an issue for you.


I don't have the resources to load up the systems enough to find these 
problems sitting on my desk.  And I can't risk production resources for 
problems known and reported on the *EXACT* same hardware.


Ok, then don't. Just stop whining about it. The 6.2 EOL has been 
announced from day 1 (and extended once already). If you haven't made 
adequate preparations, that's not our fault.


Furthermore, if your production environment is as overwhelmingly 
important as you make it out to be, you ought to have provisions for 
redundancy and failover already. If you don't have that, and don't 
have a testbed, that's not our fault either.


Bruce put it in much more polite terms than I have patience for atm. 
Open source software isn't "free," and if you're not interested in 
holding up your end of the bargain, explore other alternatives.


"oh but it won't happen to me" isn't a useful methodology in a 
production environment.


I mean, seriously, I know the majority of you are happy rebooting your 
systems 5x daily to run the latest.  I'll do that with my home system, 
no problem.  But I can't do this in a production environment.


Ok, then don't. But you probably ought not to insult the 
professionalism of the people that you're going to be asking for help 
again at some point.


When you do come back, your first message should contain a list of PRs 
that you're concerned about, and confirmation (per jhb's message) that 
you have the _exact_ hardware that is referred to in them. If you 
can't provide that, don't bother.


Doug

--

This .signature sanitized for your protection

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: challenge: end of life for 6.2 is premature with buggy 6.3

2008-06-05 Thread Steven Hartland

- Original Message - 
From: "Paul Schmehl" <[EMAIL PROTECTED]>


That is a blatant lie.  He has stated repeatedly that there are *known* bugs, 
complete with bug reports, that are not resolved and that affect the hardware 
he uses.  He has also stated that there is no need for him to provide further 
evidence of an already documented bug, yet he is willing to provide equipment 
with 6.3 RELEASE installed if any developer needs a platform to test and 
troubleshoot the bugs.


Unforunately to now he has totally avoided telling anyone what said BUG's,
PR's etc are, even when asked on several occasions. Instead he continues
down the line of "I dont have time or resources to test your fixes so just
make it work ffs!" just not in so many words.

I'm just a user here, but if something is a show stopper for us I work
with anyone who is able to help us resolve the issue. This has proved
very successful, in particular one case springs to mind where we worked
with HighPoint support to fix a serious corruption issue with 1820a
under FreeBSD.

I have no sympathy for anyone who's going to moan about a previous release
being desupported that isn't willing to put the effort in to make the
issues they are seeing get fixed.

   Regards
   Steve


This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. 


In the event of misdirection, illegible or incomplete transmission please 
telephone +44 845 868 1337
or return the E.mail to [EMAIL PROTECTED]

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: challenge: end of life for 6.2 is premature with buggy 6.3

2008-06-05 Thread Doug Barton

Chris Marlatt wrote:

Adrian Chadd wrote:
The project is doing what it can with what people are
contributing. If

What if it can accomplish the same or more by simply reorganizing
what it's already doing?

I think that the problem here is that you have no idea how absurd you
sound to the people who are actually doing the work.

And frankly, it doesn't even matter which way you _meant_ it. And
sure, you have the right to voice your opinion, all FreeBSD users do.
You also need to be prepared to take "no" for an answer.

you'd like a distribution supported for longer then offer to help
maintain it. You may be surprised how helpful people get when
you offer to help. :0

Again IMHO the only message coming across here is either do it
yourself or keep your mouth shut.

That's not _exactly_ what we're saying, but it's pretty close. This is
open source after all. "If you can't find what you're looking for,
build it, or look elsewhere" would be a better way to say it.

The other side of the coin here is - what's to say the FreeBSD
project requires what I can offer?

Without trying to sound rude, I'm pretty sure the only person that's
going to matter to is you.

Granted it's been sometime since I've browsed the entire
FreeBSD.org site but last I checked there wasn't an area devoted to

the needs of the project.

http://www.freebsd.org/cgi/query-pr-summary.cgi?category=&severity=&priority=&class=&state=&sort=none&text=&responsible=&multitext=&originator=&release=

Furthermore, just because someone isn't providing assistance
doesn't mean that their concerns should go unheard.

This isn't the '80's, and we aren't in grade school. See above on
taking "no" for an answer.

It's quite possible what was proposed is an awful idea and if it is
so be it. But it would appear as though it wasn't even considered.

On the contrary. This, and lots of other ideas have been given very
careful consideration and have been rejected due to lack of resources.
There, feel better?

hth,

Doug

This .signature sanitized for your protection

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: challenge: end of life for 6.2 is premature with buggy 6.3

2008-06-05 Thread Pieter de Goeje

On Thursday 05 June 2008, Paul Schmehl wrote:
> --On Thursday, June 05, 2008 10:23:55 -0400 John Baldwin <[EMAIL PROTECTED]>
>
> wrote:
> > FWIW, at Y! 6.3 is more stable than 6.2 (I had a list of about 10 patches
> > for known deadlocks and kernel panics that were errata candidates for 6.2
> > that never made it into RELENG_6_2 but all of them are in 6.3).  We also
> > have many machines with bge(4) and from our perspective 6.3 has less
> > issues with bge0 devices than 6.2.
>
> I'm glad to hear that.  I have a server that uses bce, and it was
> completely non-functional until I hunted down some beta code that made it
> usable.  I'd like to upgrade, but this is a critical server with no
> redundancy (and it's a hobby site with no money to pay for expensive
> support), and I'm not about to upgrade unless I know for certain the
> problems won't reoccur, because I have to upgrade remotely and pay money if
> the system goes down.
>
> The problems with that driver were bad enough when the server was being
> configured in my study.  (The system would lock up, and only a hard reboot
> would restore networking.)  It would be hell trying to troubleshoot
> problems if I had to drive the 45 miles to the hosting site and spend a
> night there trying to get the server back up, then go to work the next day.
>
> # uname -a
> FreeBSD www.stovebolt.com 6.1-RELEASE-p10 FreeBSD 6.1-RELEASE-p10 #2: Mon
> Oct 16 15:38:02 CDT 2006
> [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC i386
>
> # grep bce /var/run/dmesg.boot
> bce0:  mem
> 0xf400-0xf5ff irq 16 at device 0.0 on pci9
> bce0: ASIC ID 0x57081010; Revision (B1); PCI-X 64-bit 133MHz
> miibus0:  on bce0
> bce0: Ethernet address: 00:13:72:fb:2a:ad
> bce1:  mem
> 0xf800-0xf9ff irq 16 at device 0.0 on pci5
> bce1: ASIC ID 0x57081010; Revision (B1); PCI-X 64-bit 133MHz
> miibus1:  on bce1
> bce1: Ethernet address: 00:13:72:fb:2a:ab
>
> # grep bce0 /var/log/messages
> May  2 09:10:31 www kernel: bce0: link state changed to DOWN
> May  2 09:10:39 www kernel: bce0: link state changed to UP
> May 25 07:49:49 www kernel: bce0: link state changed to DOWN
> May 25 07:50:31 www kernel: bce0: link state changed to UP
> May 26 21:28:36 www kernel: bce0: link state changed to DOWN
> May 26 21:28:40 www kernel: bce0: link state changed to UP
> May 27 13:13:21 www kernel: bce0: link state changed to DOWN
> May 27 13:13:31 www kernel: bce0: link state changed to UP
>
> It's been like that since the server was installed.
>
> So, if I upgrade to 6.3 or 7.0, am I still going to experience these
> problems? Is the server going to stop working entirely?  How can I know
> that for sure before starting an upgrade?
> [...]

There's a really easy way to test this. Build & install a new kernel, but keep 
the old kernel around (by default it's in /boot/kernel.old). If the problem 
is gone, do the upgrade as usual. If it's still there, you know upgrading 
won't fix it and you don't waste time; simply rename kernel.old to kernel. 
This even works with 7.0 provided that you leave COMPAT_FREEBSD6 in the 
kernel configuration file.

-- 
Pieter de Goeje

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: CLARITY re: challenge: end of life for 6.2 is premature with buggy 6.3

2008-06-05 Thread Doug Barton


Torfinn Ingolfsen wrote:

On Thu, 05 Jun 2008 05:51:05 -0700
Jeremy Chadwick <[EMAIL PROTECTED]> wrote:


Offering monetary compensation is not a solution, and I believe that's
because the core problem isn't lack of pay -- it's lack of time.
That's one which is really hard to solve, no matter what the
conditions of an open-source project.


Hmm, perhaps you and others should train people instead?
Offer to pay a student to learn FreeBSD, and to train her / him as
developer.


http://www.freebsd.org/projects/summerofcode-2008.html

--

This .signature sanitized for your protection

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: challenge: end of life for 6.2 is premature with buggy 6.3

2008-06-05 Thread Tom Evans


On Thu, 2008-06-05 at 11:14 -0500, Paul Schmehl wrote:
> --On Thursday, June 05, 2008 10:23:55 -0400 John Baldwin <[EMAIL PROTECTED]> 
> wrote:
> >
> > FWIW, at Y! 6.3 is more stable than 6.2 (I had a list of about 10 patches 
> > for
> > known deadlocks and kernel panics that were errata candidates for 6.2 that
> > never made it into RELENG_6_2 but all of them are in 6.3).  We also have 
> > many
> > machines with bge(4) and from our perspective 6.3 has less issues with bge0
> > devices than 6.2.
> >
> 
> I'm glad to hear that.  I have a server that uses bce, and it was completely 
> non-functional until I hunted down some beta code that made it usable.  I'd 
> like to upgrade, but this is a critical server with no redundancy (and it's a 
> hobby site with no money to pay for expensive support), and I'm not about to 
> upgrade unless I know for certain the problems won't reoccur, because I have 
> to 
> upgrade remotely and pay money if the system goes down.
> 
> The problems with that driver were bad enough when the server was being 
> configured in my study.  (The system would lock up, and only a hard reboot 
> would restore networking.)  It would be hell trying to troubleshoot problems 
> if 
> I had to drive the 45 miles to the hosting site and spend a night there 
> trying 
> to get the server back up, then go to work the next day.
> 
> # uname -a
> FreeBSD www.stovebolt.com 6.1-RELEASE-p10 FreeBSD 6.1-RELEASE-p10 #2: Mon Oct 
> 16 15:38:02 CDT 2006 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC 
> i386
> 
> # grep bce /var/run/dmesg.boot
> bce0:  mem 
> 0xf400-0xf5ff irq 16 at device 0.0 on pci9
> bce0: ASIC ID 0x57081010; Revision (B1); PCI-X 64-bit 133MHz
> miibus0:  on bce0
> bce0: Ethernet address: 00:13:72:fb:2a:ad
> bce1:  mem 
> 0xf800-0xf9ff irq 16 at device 0.0 on pci5
> bce1: ASIC ID 0x57081010; Revision (B1); PCI-X 64-bit 133MHz
> miibus1:  on bce1
> bce1: Ethernet address: 00:13:72:fb:2a:ab
> 
> # grep bce0 /var/log/messages
> May  2 09:10:31 www kernel: bce0: link state changed to DOWN
> May  2 09:10:39 www kernel: bce0: link state changed to UP
> May 25 07:49:49 www kernel: bce0: link state changed to DOWN
> May 25 07:50:31 www kernel: bce0: link state changed to UP
> May 26 21:28:36 www kernel: bce0: link state changed to DOWN
> May 26 21:28:40 www kernel: bce0: link state changed to UP
> May 27 13:13:21 www kernel: bce0: link state changed to DOWN
> May 27 13:13:31 www kernel: bce0: link state changed to UP
> 
> It's been like that since the server was installed.
> 
> So, if I upgrade to 6.3 or 7.0, am I still going to experience these 
> problems? 
> Is the server going to stop working entirely?  How can I know that for sure 
> before starting an upgrade?
> 
> Because, I have a 7.0 STABLE workstation (I'm sending this email from it) 
> with 
> a serious problem with umass, and no fix seems to be forthcoming.  On a 
> workstation, I can work around problems.  On a critical server, not so much.
> 
> Look, I know this is open source, all volunteer (hell, I'm a port maintainer 
> myself) and guys' time is extremely valuable (whose isn't?), but it seems to 
> me 
> there needs to be better communication between the folks who know the code 
> and 
> those who only run boxes.  You might be able to read diffs and say, "Aha, 
> they've fixed the problem", but I can't.  I don't know, if I upgrade to 6.3, 
> if 
> the server will stop passing packets or not.  And I can't take the chance 
> that 
> it will.
> 
> Saying put up or shut up isn't going to win many friends.  I can't use the 
> server for testing.  It's a website with 5 to 7 million hits per month.
> 
> MInd you, I haven't complained about this and I'm not complaining now.  I'm 
> simply saying it would be more productive if folks *listened* to what people 
> say about a particular problem and gave it some thought before firing salvos 
> at 
> the "complainers" and demanding that they contribute to solving the problem 
> somehow.
> 
> -- 
> Paul Schmehl

I think that, especially with open source products, there is a large
emphasis on testing in your own environments, and choosing the 'correct'
version of a particular software package is important. For example, at
$JOB, we had a lot of servers running 6.1 as it was an extended lifetime
release, so no point jumping to 6.2, instead we waited for 6.3 to pass
our integration testing.

We buy usually the same chassis for all our servers, and test
extensively before deploying to a new chassis/OS/anything. This is the
definition of change management, which is expensive, takes lots of time
and planning, and doesn't guarantee zaroo bugs - just a high likelihood
of not hitting them. It also isn't smooth, when we tested 6.1, we found
a multitude of bugs in bce(4), which we worked with net@ and David
Christensen of Broadcom to get fixed (they work lovely now :).

If you don't want to do this sort of work, then yes, things may fail
unexpectedly (sort of unexpectedly, I would c

Re: challenge: end of life for 6.2 is premature with buggy 6.3


Ivan Voras wrote:

Chris Marlatt wrote:


The option provided seems like a fairly good compromise to both
interests. Pick 6.3 (or anything the release team wishes) to support for
a longer period of time. Keep all other releases to 12 month support and
continue doing what I believe is some fairly incredible work. I really
don't see the downside to it. If anything it should reduce the work load
for the team and let them focus on making considerable progress.
Especially considering Ken Smith's recent post regarding future release
schedules.


This is already being done: 6.1 was a "long term support" release.

The topic comes about pretty often. I think it's because people are
still impressed / spoiled by 4.x and wish they had a stable operating
system that's supported for 6+ years (like 4.x had been). I even heard


Spoiled is probably a good word for it. But you have to admit it's 
extremely useful to the user base to have such support. This was quite 
evident by the apposition to discontinue the 4.x branch.



commercial / embedded companies saying they would use FreeBSD if only
they had a 5+ years run off a branch (which is comparable to what Debian
has, if you allow 3.0 and 3.1 to be "similar enough").

But all is not so bad: consider for example 7.x: 7.0 was released
2008/02, and from Ken's schedule the last release, 7.4 will be released
2009/12, with probable support for maybe 1-2 more years which makes the
whole 7.x generation of the OS officialy supported for 3, maybe 4 years,
which is a lot in fast technology-changing world.


I think you're missing the point. Whereas it is indeed helpful to have 
the major release supported for that duration of time. The concern was 
over the minor release support. For instance if 7.0 is only supported 
for 12 months it doesn't really matter if 7.x is support for 48. You 
still need to upgrade and deal with any potential problems 7.1 or 7.2 
induces if you wish to continue having "vendor supplied" security fixes. 
However using the 7.x tree as an example is problem not the best. 7.x, 
at least from what I've perceived, is a fairly active development 
branch. The 6.2 to 6.3 change is somewhat a better example but still not 
perfect.




I know long term support is not doable with the resources the project
currently has, but I've been toying with the idea that maybe there's an
opportunity for commercial development here - a company that would
backport security fixes and important driver fixes for ($$$ *
(N-YEAR_OF_LAST_RELEASE)) more years or something.




Regards,

Chris
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: challenge: end of life for 6.2 is premature with buggy 6.3

2008-06-05 Thread Ken Smith

On Thu, 2008-06-05 at 17:01 +0200, Kris Kennaway wrote:
> Chris Marlatt wrote:
> > Kris Kennaway wrote:
> >> Chris Marlatt wrote:
> >>> In an effort to potentially find a compromise between those who
> >>> believe FreeBSD is EoL'ing previous releases too quickly and those who
> >>> don't. Have those in a position to set FreeBSD release schedules
> >>> debated the option of setting a long term support release, a specific
> >>> release picked by the team to be support for,.. 4 or 5 years? Other
> >>> projects have done this will relative success and considering the
> >>> "only" work required for this release would be security patches the
> >>> work load should be minimized. Hopefully something like this could
> >>> free up more time for the FreeBSD developers to continue their work on
> >>> the newer release(s) while still answering the requests of what seems
> >>> like quite a few of the legacy FreeBSD users. Thoughts?
> >>>
> >>> If this has already been discussed on-list I apologize for beating a
> >>> dead horse but I can't recall it bring brought up before.
> >> Uh yeah, this has been in place for *years*.  Have you actually read the
> >> support announcements?  They are public ;)
> >>
> >> Kris
> > 
> > I do actually - and when was the last release that was support for such
> > a duration of time,.. 4.11? As of recent the longest I've seen has been
> > 24 months with others being only 12.
> 
> Yes, and this is the FreeBSD definition of "long term support".  Don't 
> like it?  Do something about it.
> 

The 4.11 support was an anomoly, to a large degree because you needed to
be either "Really Brave" or "Clinically Insane" to use 5.x.  :-)

It's unfortunate that people seem to be experiencing regressions with
6.3, we do try quite hard to avoid that.  And our support model is
geared up around that, it's typically the last release for a given
development branch that receives the extended support under the
assumption there are no issues with upgrading in-branch.

As for re-defining extended support to mean 4 or 5 years instead of just
two it's not clear us doing that (except for anomolies like 4.11) is
really in your best interests.  :-)  Even if the base system's support
were to be extended to that sort of timeframe it's the *applications*
you folks rely on the most.  The ports folks do their best to keep their
stuff usable for the Project-defined life cycle of the releases which
gets harder the older a given "target" gets as well as needing to cater
to "too many" different branches simultaneously.  Keeping the ports
builds going for longer than two years after the last release of a given
branch just isn't feasible/reasonable.  And if the stuff you layer on
top of the operating system isn't upgradable giving you the warm fuzzy
feeling you're OK because the base OS still receives patches isn't
necessarily a good thing.  Of course there will be people who feel
differently but we need to focus efforts on the average folks.

-- 
Ken Smith
- From there to here, from here to  |   [EMAIL PROTECTED]
  there, funny things are everywhere.   |
  - Theodore Geisel |

signature.asc
Description: This is a digitally signed message part

Re: challenge: end of life for 6.2 is premature with buggy 6.3

2008-06-05 Thread Ivan Voras

Chris Marlatt wrote:

> The option provided seems like a fairly good compromise to both
> interests. Pick 6.3 (or anything the release team wishes) to support for
> a longer period of time. Keep all other releases to 12 month support and
> continue doing what I believe is some fairly incredible work. I really
> don't see the downside to it. If anything it should reduce the work load
> for the team and let them focus on making considerable progress.
> Especially considering Ken Smith's recent post regarding future release
> schedules.

This is already being done: 6.1 was a "long term support" release.

The topic comes about pretty often. I think it's because people are
still impressed / spoiled by 4.x and wish they had a stable operating
system that's supported for 6+ years (like 4.x had been). I even heard
commercial / embedded companies saying they would use FreeBSD if only
they had a 5+ years run off a branch (which is comparable to what Debian
has, if you allow 3.0 and 3.1 to be "similar enough").

But all is not so bad: consider for example 7.x: 7.0 was released
2008/02, and from Ken's schedule the last release, 7.4 will be released
2009/12, with probable support for maybe 1-2 more years which makes the
whole 7.x generation of the OS officialy supported for 3, maybe 4 years,
which is a lot in fast technology-changing world.

I know long term support is not doable with the resources the project
currently has, but I've been toying with the idea that maybe there's an
opportunity for commercial development here - a company that would
backport security fixes and important driver fixes for ($$$ *
(N-YEAR_OF_LAST_RELEASE)) more years or something.

signature.asc
Description: OpenPGP digital signature

Re: challenge: end of life for 6.2 is premature with buggy 6.3

--On Thursday, June 05, 2008 10:23:55 -0400 John Baldwin <[EMAIL PROTECTED]> 
wrote:


FWIW, at Y! 6.3 is more stable than 6.2 (I had a list of about 10 patches for
known deadlocks and kernel panics that were errata candidates for 6.2 that
never made it into RELENG_6_2 but all of them are in 6.3).  We also have many
machines with bge(4) and from our perspective 6.3 has less issues with bge0
devices than 6.2.



I'm glad to hear that.  I have a server that uses bce, and it was completely 
non-functional until I hunted down some beta code that made it usable.  I'd 
like to upgrade, but this is a critical server with no redundancy (and it's a 
hobby site with no money to pay for expensive support), and I'm not about to 
upgrade unless I know for certain the problems won't reoccur, because I have to 
upgrade remotely and pay money if the system goes down.


The problems with that driver were bad enough when the server was being 
configured in my study.  (The system would lock up, and only a hard reboot 
would restore networking.)  It would be hell trying to troubleshoot problems if 
I had to drive the 45 miles to the hosting site and spend a night there trying 
to get the server back up, then go to work the next day.


# uname -a
FreeBSD www.stovebolt.com 6.1-RELEASE-p10 FreeBSD 6.1-RELEASE-p10 #2: Mon Oct 
16 15:38:02 CDT 2006 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC 
i386


# grep bce /var/run/dmesg.boot
bce0:  mem 
0xf400-0xf5ff irq 16 at device 0.0 on pci9

bce0: ASIC ID 0x57081010; Revision (B1); PCI-X 64-bit 133MHz
miibus0:  on bce0
bce0: Ethernet address: 00:13:72:fb:2a:ad
bce1:  mem 
0xf800-0xf9ff irq 16 at device 0.0 on pci5

bce1: ASIC ID 0x57081010; Revision (B1); PCI-X 64-bit 133MHz
miibus1:  on bce1
bce1: Ethernet address: 00:13:72:fb:2a:ab

# grep bce0 /var/log/messages
May  2 09:10:31 www kernel: bce0: link state changed to DOWN
May  2 09:10:39 www kernel: bce0: link state changed to UP
May 25 07:49:49 www kernel: bce0: link state changed to DOWN
May 25 07:50:31 www kernel: bce0: link state changed to UP
May 26 21:28:36 www kernel: bce0: link state changed to DOWN
May 26 21:28:40 www kernel: bce0: link state changed to UP
May 27 13:13:21 www kernel: bce0: link state changed to DOWN
May 27 13:13:31 www kernel: bce0: link state changed to UP

It's been like that since the server was installed.

So, if I upgrade to 6.3 or 7.0, am I still going to experience these problems? 
Is the server going to stop working entirely?  How can I know that for sure 
before starting an upgrade?


Because, I have a 7.0 STABLE workstation (I'm sending this email from it) with 
a serious problem with umass, and no fix seems to be forthcoming.  On a 
workstation, I can work around problems.  On a critical server, not so much.


Look, I know this is open source, all volunteer (hell, I'm a port maintainer 
myself) and guys' time is extremely valuable (whose isn't?), but it seems to me 
there needs to be better communication between the folks who know the code and 
those who only run boxes.  You might be able to read diffs and say, "Aha, 
they've fixed the problem", but I can't.  I don't know, if I upgrade to 6.3, if 
the server will stop passing packets or not.  And I can't take the chance that 
it will.


Saying put up or shut up isn't going to win many friends.  I can't use the 
server for testing.  It's a website with 5 to 7 million hits per month.


MInd you, I haven't complained about this and I'm not complaining now.  I'm 
simply saying it would be more productive if folks *listened* to what people 
say about a particular problem and gave it some thought before firing salvos at 
the "complainers" and demanding that they contribute to solving the problem 
somehow.


--
Paul Schmehl
As if it wasn't already obvious,
my opinions are my own and not
those of my employer.

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: challenge: end of life for 6.2 is premature with buggy 6.3


Kris Kennaway wrote:

Chris Marlatt wrote:

Kris Kennaway wrote:

Chris Marlatt wrote:

Kris Kennaway wrote:

Chris Marlatt wrote:

Kris Kennaway wrote:

Jo Rhett wrote:

On Jun 4, 2008, at 11:39 AM, Kris Kennaway wrote:

Also, it's not like anyone should have been caught by surprise by
the 6.2 EoL; the expiry date has been advertised since the 6.2
release itself.


It has changed multiple times.  I keep reviewing and finding 6.3
bugs outstanding, and then observe the EoL get pushed.

I'm surprised that it failed to get pushed this time.


I'm sorry that the FreeBSD project failed to conform to your
expectations.  However, I invite you to actually try 6.3 for 
yourself

instead of assuming that it will fail.

Kris

In an effort to potentially find a compromise between those who
believe FreeBSD is EoL'ing previous releases too quickly and those 
who

don't. Have those in a position to set FreeBSD release schedules
debated the option of setting a long term support release, a specific
release picked by the team to be support for,.. 4 or 5 years? Other
projects have done this will relative success and considering the
"only" work required for this release would be security patches the
work load should be minimized. Hopefully something like this could
free up more time for the FreeBSD developers to continue their 
work on

the newer release(s) while still answering the requests of what seems
like quite a few of the legacy FreeBSD users. Thoughts?

If this has already been discussed on-list I apologize for beating a
dead horse but I can't recall it bring brought up before.
Uh yeah, this has been in place for *years*.  Have you actually 
read the

support announcements?  They are public ;)

Kris


I do actually - and when was the last release that was support for such
a duration of time,.. 4.11? As of recent the longest I've seen has been
24 months with others being only 12.


Yes, and this is the FreeBSD definition of "long term support".  
Don't like it?  Do something about it.


Kris


You seem awful hostile - do you really think that's the best way to 
represent the project you're involved with? Initially belittle someone 
for offering their opinion and then when they reply telling them to do 
it themselves or shut up? Try and have an open mind about these things.


The option provided seems like a fairly good compromise to both 
interests. Pick 6.3 (or anything the release team wishes) to support 
for a longer period of time. Keep all other releases to 12 month 
support and continue doing what I believe is some fairly incredible 
work. I really don't see the downside to it. If anything it should 
reduce the work load for the team and let them focus on making 
considerable progress. Especially considering Ken Smith's recent post 
regarding future release schedules.


IMHO, the attitude and opinion you have right now accomplishes nothing 
other than alienating your supporters.


There has been nothing of value offered in this thread, and it's only 
served to piss off a number of developers who already put huge amounts 
of volunteer time into supporting FreeBSD, and who take pride in the 
quality of their work.  Asking the volunteers to




I don't think anyone has really said their quality is in question. At 
least not myself. The OP stated there are unclosed bugs that be believes 
are preventing him from using 6.3 and called into question the decision 
of EoL'ing 6.2. Granted he should have tested it anyways vs. waiting 
until hell freezes over but at this time thats somewhat beside the 
point. Just because someone questions a decision or notes there are 
unclosed bugs doesn't mean they appreciate the work the team as a whole 
is doing any less.


a) fix unspecified problems that the submitter will not name in detail 
but which are OMG SHOWSTOPPER YOU MUST FIX




Again I completely agree that the OP should have provided the PRs. If 
for nothing else to ensure that you're talking about exactly the same 
issue and not anything similar. How about just saving you from having to 
look them up?


b) donate even more unpaid time to supporting branches because it seems 
like a good "compromise" (!)


This may or may not be the case. Like I said if it's a horrible idea 
sorry for wasting your time. But it seems fairly logical to me as a good 
solution to the problem and should net the team more time for things 
that really count.




shows a complete failure of understanding and frankly beggars belief.

Such people are not acting as supporters of the project, however 
well-intentioned they may believe themselves to be.




I respectfully disagree.


Kris


Regards,

Chris
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: CLARITY re: challenge: end of life for 6.2 is premature with buggy 6.3

2008-06-05 Thread Torfinn Ingolfsen

On Thu, 05 Jun 2008 05:51:05 -0700
Jeremy Chadwick <[EMAIL PROTECTED]> wrote:

> Offering monetary compensation is not a solution, and I believe that's
> because the core problem isn't lack of pay -- it's lack of time.
> That's one which is really hard to solve, no matter what the
> conditions of an open-source project.

Hmm, perhaps you and others should train people instead?
Offer to pay a student to learn FreeBSD, and to train her / him as
developer.
I don't know if it is at all possible to fund something like that
within the econimcs of a company such as yours, but if it worked, it
would bring more developers on board.

Just an idea.
-- 
Regards,
Torfinn Ingolfsen,
Norway

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: challenge: end of life for 6.2 is premature with buggy 6.3

--On Thursday, June 05, 2008 08:03:44 +0200 Torfinn Ingolfsen 
<[EMAIL PROTECTED]> wrote:



On Wed, 04 Jun 2008 22:19:03 -0700
Jo Rhett <[EMAIL PROTECTED]> wrote:


Edwin, I've been building testbed environments for over 20 years in
my professional career.  I know a lot more than this basic concept.

The costs in our environment for a proper testbed is $20k in
hardware and 3000 man hours.  That's for a small test of comparable
small changes to the existing environment.

Why would we take on this cost only to re-document well known and
already acknowledged bugs?  I mean, really?


I'm surprised that a test environment (for upgrade testing, load
testing, release testing) isn't already in place.
Some people (customers and operators alike) might think it is
unprofessional and unsafe to run a production system without a test
system available.

If you have a test system available, why don't you use it?


I am offended by the tone of many of the responses to Jo Rhett's *legitimate* 
arguments that *perhaps* the EOL of 6.2 is a bit premature.  I think some folks 
need to take a break, push away from the keyboard and reduce the insulting 
rhetoric they are casting his way.


He has been more than clear that he routinely donates time and equipment to the 
community.  If all you can do is insult him, perhaps you should consider 
shutting up.


Please note: this is *not* directed only at the person to whom I responded but 
to all those who have chosen to take the low road rather than engage Jo in 
professional discussion.


--
Paul Schmehl
As if it wasn't already obvious,
my opinions are my own and not
those of my employer.

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: challenge: end of life for 6.2 is premature with buggy 6.3


Adrian Chadd wrote:


The OP stated "argh argh sky is falling with 6.3!" but hasn't yet
listed PRs which indicate this to be happening.


I'm glad we can agree on something. Providing the PRs is not a lot to 
ask. Especially if it provides some forward movement and gets the 
support he needs.


I can certainly relate to a potentially standoff'ish approach that's 
been seen recently. It's easy to take people's criticism as completely 
negative regardless what is said. To be honest though - people are using 
FreeBSD because it's a good project to say the least. A few negative 
comments doesn't mean they think the whole project is trash. Excluding 
the fact that we're all human and have emotions / ego, you have to agree 
that such a hostile approach isn't really the best thing.


Regards,

Chris
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: challenge: end of life for 6.2 is premature with buggy 6.3

2008-06-05 Thread Patrick M. Hausen

Hello,

On Thu, Jun 05, 2008 at 10:33:18AM -0500, Paul Schmehl wrote:
> --On Thursday, June 05, 2008 18:39:07 +1000 Peter Jeremy 
> <[EMAIL PROTECTED]> wrote:
> 
>> On 2008-Jun-04 22:22:33 -0700, Jo Rhett <[EMAIL PROTECTED]> wrote:
>>> And please stop with the loaded language.  I'm not asking anyone to work
>>> for me.  I am suggesting that it is perhaps too early to EoL 6.2 because
>>> 6.3 isn't ready yet.
>> 
>> So you have stated.  When asked to provide evidence to backup that
>> statement, you have refused.  Since you are the one claiming that
>> "6.3 isn't ready yet", the onus is on you to put up or shut up.
> 
> That is a blatant lie.  He has stated repeatedly that there are *known* 
> bugs, complete with bug reports, that are not resolved and that affect the 
> hardware he uses.

So he should at least be able to name the relevant PRs.
Or name at least one. Then nobody would complain.

But stating "it's all well documented" without providing evidence
doesn't help. I for one was not able to find any open PRs that
deal specifically with 3ware hardware and 6.3, but not 6.[0-2].

> He has also stated that there is no need for him to 
> provide further evidence of an already documented bug

Agreed, but he should name the PRs he's referring to.
You know, my crystal ball is at the shop for a check, and
it seems like everybody else's is, too.

Kind regards,
Patrick M. Hausen
Leiter Netzwerke und Sicherheit
-- 
punkt.de GmbH * Kaiserallee 13a * 76133 Karlsruhe
Tel. 0721 9109 0 * Fax 0721 9109 100
[EMAIL PROTECTED]   http://www.punkt.de
Gf: Jürgen Egeling  AG Mannheim 108285
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: challenge: end of life for 6.2 is premature with buggy 6.3

--On Thursday, June 05, 2008 18:39:07 +1000 Peter Jeremy 
<[EMAIL PROTECTED]> wrote:



On 2008-Jun-04 22:22:33 -0700, Jo Rhett <[EMAIL PROTECTED]> wrote:

And please stop with the loaded language.  I'm not asking anyone to work
for me.  I am suggesting that it is perhaps too early to EoL 6.2 because
6.3 isn't ready yet.


So you have stated.  When asked to provide evidence to backup that
statement, you have refused.  Since you are the one claiming that
"6.3 isn't ready yet", the onus is on you to put up or shut up.


That is a blatant lie.  He has stated repeatedly that there are *known* bugs, 
complete with bug reports, that are not resolved and that affect the hardware 
he uses.  He has also stated that there is no need for him to provide further 
evidence of an already documented bug, yet he is willing to provide equipment 
with 6.3 RELEASE installed if any developer needs a platform to test and 
troubleshoot the bugs.


What is the purpose of the insults and denigration?  Do you really hope to 
accomplish something positive?


--
Paul Schmehl
As if it wasn't already obvious,
my opinions are my own and not
those of my employer.

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: challenge: end of life for 6.2 is premature with buggy 6.3


Chris Marlatt wrote:

Kris Kennaway wrote:

Chris Marlatt wrote:

Kris Kennaway wrote:

Chris Marlatt wrote:

Kris Kennaway wrote:

Jo Rhett wrote:

On Jun 4, 2008, at 11:39 AM, Kris Kennaway wrote:

Also, it's not like anyone should have been caught by surprise by
the 6.2 EoL; the expiry date has been advertised since the 6.2
release itself.


It has changed multiple times.  I keep reviewing and finding 6.3
bugs outstanding, and then observe the EoL get pushed.

I'm surprised that it failed to get pushed this time.


I'm sorry that the FreeBSD project failed to conform to your
expectations.  However, I invite you to actually try 6.3 for yourself
instead of assuming that it will fail.

Kris

In an effort to potentially find a compromise between those who
believe FreeBSD is EoL'ing previous releases too quickly and those who
don't. Have those in a position to set FreeBSD release schedules
debated the option of setting a long term support release, a specific
release picked by the team to be support for,.. 4 or 5 years? Other
projects have done this will relative success and considering the
"only" work required for this release would be security patches the
work load should be minimized. Hopefully something like this could
free up more time for the FreeBSD developers to continue their work on
the newer release(s) while still answering the requests of what seems
like quite a few of the legacy FreeBSD users. Thoughts?

If this has already been discussed on-list I apologize for beating a
dead horse but I can't recall it bring brought up before.
Uh yeah, this has been in place for *years*.  Have you actually read 
the

support announcements?  They are public ;)

Kris


I do actually - and when was the last release that was support for such
a duration of time,.. 4.11? As of recent the longest I've seen has been
24 months with others being only 12.


Yes, and this is the FreeBSD definition of "long term support".  Don't 
like it?  Do something about it.


Kris


You seem awful hostile - do you really think that's the best way to 
represent the project you're involved with? Initially belittle someone 
for offering their opinion and then when they reply telling them to do 
it themselves or shut up? Try and have an open mind about these things.


The option provided seems like a fairly good compromise to both 
interests. Pick 6.3 (or anything the release team wishes) to support for 
a longer period of time. Keep all other releases to 12 month support and 
continue doing what I believe is some fairly incredible work. I really 
don't see the downside to it. If anything it should reduce the work load 
for the team and let them focus on making considerable progress. 
Especially considering Ken Smith's recent post regarding future release 
schedules.


IMHO, the attitude and opinion you have right now accomplishes nothing 
other than alienating your supporters.


There has been nothing of value offered in this thread, and it's only 
served to piss off a number of developers who already put huge amounts 
of volunteer time into supporting FreeBSD, and who take pride in the 
quality of their work.  Asking the volunteers to


a) fix unspecified problems that the submitter will not name in detail 
but which are OMG SHOWSTOPPER YOU MUST FIX


b) donate even more unpaid time to supporting branches because it seems 
like a good "compromise" (!)


shows a complete failure of understanding and frankly beggars belief.

Such people are not acting as supporters of the project, however 
well-intentioned they may believe themselves to be.


Kris
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: challenge: end of life for 6.2 is premature with buggy 6.3

(I know I should really be studying, but this thread really irks me,
as I have exactly this issue in the project _I_ am involved in..)

2008/6/5 Chris Marlatt <[EMAIL PROTECTED]>:

> Again IMHO the only message coming across here is either do it yourself or
> keep your mouth shut. The other side of the coin here is - what's to say the

Well, its "do it yourself or be helpful to people who are willing to do it".

The OP stated "argh argh sky is falling with 6.3!" but hasn't yet
listed PRs which indicate this to be happening.
He's offered hardware in a week or two - which is great! - but what
irks the developers is the large amount of noise and absolutely no
useful information. Anyone can say "its broken!"..

> FreeBSD project requires what I can offer? Granted it's been sometime since
> I've browsed the entire FreeBSD.org site but last I checked there wasn't an
> area devoted to the needs of the project.

Whatever you want..?

> Furthermore, just because someone isn't providing assistance doesn't mean
> that their concerns should go unheard. It's quite possible what was proposed
> is an awful idea and if it is so be it. But it would appear as though it
> wasn't even considered.

Thats true in say, your case. And, say another case like yours. But
after hundreds of people who aren't providing assistance and are
simply providing their 2c, it gets a bit tiresome. Its not that ALL of
the comments aren't any good, its that wading through the crap to find
the gems is more effort than fun, and people have real work to do!

So yes, the way to contribute is to get involved. If you think there's
a real desire to take FreeBSD-6.2 (as an example) and continue
supporting security patches and critical bugfixes, versus the
larger-scale changes which seem to have gone on in /usr/src/sys then
just get together a group, generate some patches and submit them.

At some point the poor sod who is committing your work will say "screw
this, he's getting a commit bit"..



Adrian



-- 
Adrian Chadd - [EMAIL PROTECTED]
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: challenge: end of life for 6.2 is premature with buggy 6.3

2008/6/5 Chris Marlatt <[EMAIL PROTECTED]>:

> The option provided seems like a fairly good compromise to both interests.
> Pick 6.3 (or anything the release team wishes) to support for a longer
> period of time. Keep all other releases to 12 month support and continue
> doing what I believe is some fairly incredible work. I really don't see the
> downside to it. If anything it should reduce the work load for the team and
> let them focus on making considerable progress. Especially considering Ken
> Smith's recent post regarding future release schedules.

Please remember that:

* the people generally pushing changes back down into RELENG_6 are
doing so to (hopefully) fix bugs that they see in their production
environments;
* So the project is (in theory) being driven by people who have real
needs and don't mind sharing; so
* If you'd like to see this happen then please take charge and offer
to trial it. :)



Adrian



-- 
Adrian Chadd - [EMAIL PROTECTED]
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: challenge: end of life for 6.2 is premature with buggy 6.3


Adrian Chadd wrote:

The project is doing what it can with what people are contributing. If


What if it can accomplish the same or more by simply reorganizing what 
it's already doing? I completely understand the apparent situation - if 
you look at it from all angles it appears to be no different than that 
of the people apposed to the recent scheduling changes FreeBSD has made. 
There's a limited amount of people and time to do everything.



you'd like a distribution supported for longer then offer to help
maintain it. You may be surprised how helpful people get when you
offer to help. :0


Again IMHO the only message coming across here is either do it yourself 
or keep your mouth shut. The other side of the coin here is - what's to 
say the FreeBSD project requires what I can offer? Granted it's been 
sometime since I've browsed the entire FreeBSD.org site but last I 
checked there wasn't an area devoted to the needs of the project.


Furthermore, just because someone isn't providing assistance doesn't 
mean that their concerns should go unheard. It's quite possible what was 
proposed is an awful idea and if it is so be it. But it would appear as 
though it wasn't even considered.


Regards,

Chris
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: challenge: end of life for 6.2 is premature with buggy 6.3


Kris Kennaway wrote:

Chris Marlatt wrote:

Kris Kennaway wrote:

Chris Marlatt wrote:

Kris Kennaway wrote:

Jo Rhett wrote:

On Jun 4, 2008, at 11:39 AM, Kris Kennaway wrote:

Also, it's not like anyone should have been caught by surprise by
the 6.2 EoL; the expiry date has been advertised since the 6.2
release itself.


It has changed multiple times.  I keep reviewing and finding 6.3
bugs outstanding, and then observe the EoL get pushed.

I'm surprised that it failed to get pushed this time.


I'm sorry that the FreeBSD project failed to conform to your
expectations.  However, I invite you to actually try 6.3 for yourself
instead of assuming that it will fail.

Kris

In an effort to potentially find a compromise between those who
believe FreeBSD is EoL'ing previous releases too quickly and those who
don't. Have those in a position to set FreeBSD release schedules
debated the option of setting a long term support release, a specific
release picked by the team to be support for,.. 4 or 5 years? Other
projects have done this will relative success and considering the
"only" work required for this release would be security patches the
work load should be minimized. Hopefully something like this could
free up more time for the FreeBSD developers to continue their work on
the newer release(s) while still answering the requests of what seems
like quite a few of the legacy FreeBSD users. Thoughts?

If this has already been discussed on-list I apologize for beating a
dead horse but I can't recall it bring brought up before.

Uh yeah, this has been in place for *years*.  Have you actually read the
support announcements?  They are public ;)

Kris


I do actually - and when was the last release that was support for such
a duration of time,.. 4.11? As of recent the longest I've seen has been
24 months with others being only 12.


Yes, and this is the FreeBSD definition of "long term support".  Don't 
like it?  Do something about it.


Kris


You seem awful hostile - do you really think that's the best way to 
represent the project you're involved with? Initially belittle someone 
for offering their opinion and then when they reply telling them to do 
it themselves or shut up? Try and have an open mind about these things.


The option provided seems like a fairly good compromise to both 
interests. Pick 6.3 (or anything the release team wishes) to support for 
a longer period of time. Keep all other releases to 12 month support and 
continue doing what I believe is some fairly incredible work. I really 
don't see the downside to it. If anything it should reduce the work load 
for the team and let them focus on making considerable progress. 
Especially considering Ken Smith's recent post regarding future release 
schedules.


IMHO, the attitude and opinion you have right now accomplishes nothing 
other than alienating your supporters.


Regards,

Chris
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

gmirror patches

2008-06-05 Thread Pete French

Has anybody else had a chance to try the gmirror patches I posted here a
few weeks ago ? I;ve had no feedback so far - not sre if thats good
news or just that nobody tried them. they can be found here if
people are interested:

http://www.freebsd.org/cgi/query-pr.cgi?pr=123630

I;ve been running ths for a month with no ill effecets whatsoever, and would
very much like to get this commited somehow. I am not sure of the best
way to do this though, as it's not an actual bug per-se. Whom would I
approach about getting this added to the tree ?

cheers,

-pete.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: challenge: end of life for 6.2 is premature with buggy 6.3

2008/6/5 Chris Marlatt <[EMAIL PROTECTED]>:

>> Uh yeah, this has been in place for *years*.  Have you actually read the
>> support announcements?  They are public ;)
>>
>> Kris
>
> I do actually - and when was the last release that was support for such
> a duration of time,.. 4.11? As of recent the longest I've seen has been
> 24 months with others being only 12.

Noone is stopping -anyone- from doing the Debian/ubuntu thing and
breaking off snapshots of FreeBSD to roll in a slightly different way.
This is happening with PCBSD, for example.

The project is doing what it can with what people are contributing. If
you'd like a distribution supported for longer then offer to help
maintain it. You may be surprised how helpful people get when you
offer to help. :0



Adrian

-- 
Adrian Chadd - [EMAIL PROTECTED]
(Still inactive...)
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Crashes in devfs. Possibly on interface creation/destruction.

2008-06-05 Thread Kostik Belousov

On Thu, Jun 05, 2008 at 12:25:39AM +0300, Alexander Motin wrote:
> Hi.
> 
> After recent upgrading from 6.3-RC1/mpd-5.0rc1 to 6.3-STABLE/mpd-5.1 
> some of my PPPoE servers started to crash with about weekly period. 
> Usually they just just hang without rebooting and core dumping. Consoles 
> are inaccessible. All I have got from them was:
> 
> kernel: Fatal trap 12: page fau
> kernel: lt while in k
> kernel: ernel
> kernel: mode
> kernel:
> kernel: cpuid = 1; apic id = 01
> kernel: faut virtual address = 0x58
> kernel:
> kernel: fault code   = supervisor read, page not present
> kernel:
> kernel: instruction pointer  = 0x20:0xc04800be
> kernel:
> kernel: stack pointer= 0x28:0xd690883c
> kernel: frame pointer= 0x28:0
> kernel: xd6908854
> kernel: code segment =
> kernel: base 0x0, limit 0xf, type 0x1b
> kernel:
> kernel: = DPL 0, pres 1, def32 1, gra
> kernel: n 1
> kernel: processor eflags = interrupt
> kernel: enab
> kernel: led, r
> kernel: esume
> kernel: , IOPL
> kernel: = 0
> kernel:
> kernel: current process  = 1835 (mpd5)
> kernel:
> kernel: trap number  = 12
> 
> "fault virtual address" and "instruction pointer" are always the same.
> 
> Address 0xc04800be looks like part of devfs code:
> > addr2line -f -e kernel.debug 0xc04800be
> devfs_populate_loop
> /usr/src/sys/fs/devfs/devfs_devs.c:443
> 
> devfs_devs.c:
> de = devfs_newdirent(s, q - s);
> if (cdp->cdp_c.si_flags & SI_ALIAS) {
> de->de_uid = 0;
> de->de_gid = 0;
> de->de_mode = 0755;
> de->de_dirent->d_type = DT_LNK;
> pdev = cdp->cdp_c.si_parent;
> ->> line 443 ->>j = strlen(pdev->si_name) + 1;
> de->de_symlink = malloc(j, M_DEVFS, M_WAITOK);
> bcopy(pdev->si_name, de->de_symlink, j);
> 
> 0x58 - is precisely the offset of si_name field inside of struct cdev. 
> So looks like pdev = cdp->cdp_c.si_parent is NULL here for some reason.
> 
> As soon as network interfaces have respective devfs entries and looking 
> higher interface creation/destruction rate that newest mpd5.1 is able to 
> reach due to optimizations, I think it may be some kind or race 
> somewhere interface creation.
> 
> Can somebody give me any hint where to look to?

Try the following patch. It is against current, there might be further
races at the device destruction, but may be not. Also, please note that
devfs in RELENG_6 and RELENG_7/CURRENT are diverged enough to make MFC
of most bugfixes to RELENG_6 nearly impossible.

diff --git a/sys/kern/kern_conf.c b/sys/kern/kern_conf.c
index e9d0f7b..af9a47d 100644
--- a/sys/kern/kern_conf.c
+++ b/sys/kern/kern_conf.c
@@ -825,9 +825,9 @@ make_dev_alias(struct cdev *pdev, const char *fmt, ...)
va_end(ap);
 
devfs_create(dev);
+   dev_dependsl(pdev, dev);
clean_unrhdrl(devfs_inos);
dev_unlock();
-   dev_depends(pdev, dev);
 
notify_create(dev);
 


pgpQXnySO4gWK.pgp
Description: PGP signature

Re: challenge: end of life for 6.2 is premature with buggy 6.3


Chris Marlatt wrote:

Kris Kennaway wrote:

Chris Marlatt wrote:

Kris Kennaway wrote:

Jo Rhett wrote:

On Jun 4, 2008, at 11:39 AM, Kris Kennaway wrote:

Also, it's not like anyone should have been caught by surprise by
the 6.2 EoL; the expiry date has been advertised since the 6.2
release itself.


It has changed multiple times.  I keep reviewing and finding 6.3
bugs outstanding, and then observe the EoL get pushed.

I'm surprised that it failed to get pushed this time.


I'm sorry that the FreeBSD project failed to conform to your
expectations.  However, I invite you to actually try 6.3 for yourself
instead of assuming that it will fail.

Kris

In an effort to potentially find a compromise between those who
believe FreeBSD is EoL'ing previous releases too quickly and those who
don't. Have those in a position to set FreeBSD release schedules
debated the option of setting a long term support release, a specific
release picked by the team to be support for,.. 4 or 5 years? Other
projects have done this will relative success and considering the
"only" work required for this release would be security patches the
work load should be minimized. Hopefully something like this could
free up more time for the FreeBSD developers to continue their work on
the newer release(s) while still answering the requests of what seems
like quite a few of the legacy FreeBSD users. Thoughts?

If this has already been discussed on-list I apologize for beating a
dead horse but I can't recall it bring brought up before.

Uh yeah, this has been in place for *years*.  Have you actually read the
support announcements?  They are public ;)

Kris


I do actually - and when was the last release that was support for such
a duration of time,.. 4.11? As of recent the longest I've seen has been
24 months with others being only 12.


Yes, and this is the FreeBSD definition of "long term support".  Don't 
like it?  Do something about it.


Kris
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: cpufreq broken on core2duo

On Wednesday 04 June 2008 07:09:35 pm Evren Yurtesen wrote:
> Roland Smith wrote:
> > On Thu, Jun 05, 2008 at 08:33:24AM +1000, Andrew Snow wrote:
> >> Here's another one:
> >> CPU: Intel(R) Xeon(R) CPU  E5410  @ 2.33GHz
> >> cpu0:  on acpi0
> >> est0:  on cpu0
> >> est: CPU supports Enhanced Speedstep, but is not recognized.
> >> est: cpu_vendor GenuineIntel, msr 720072006000720
> >> device_attach: est0 attach returned 6
> >> p4tcc0:  on cpu0
> >  
> > I had this on a new core2 quad. Updating to a recent 7-STABLE fixed the
> > issue for me.
> 
> Did any of you tried chkfreq which comes with acpi_ppc 
> http://www.spa.is.uec.ac.jp/~nfukuda/software/ to check if the cpu frequency 
is 
> actually changing?

chkfreq checks the frequency by reading the TSC and comparing it across a 
sleep.  However, newer CPUs actually fix the TSC to increment at a constant 
rate (so at lower CPU speeds 1 CPU tick may actuall be N TSC ticks) to make 
it easier to use the TSC for timekeeping.  Thus, chkfreq will think that 
newer CPUs are running at the maximum speed when they aren't.  This is 
actually a feature of newer CPUs.

Try turning off powerd and using 'openssl speed rsa' at different frequencies 
to check for real frequency changes.

-- 
John Baldwin
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Interrupt storm with shared interrupt on digi(4)

On Thursday 05 June 2008 02:19:31 am Alfred Perlstein wrote:
> * John Baldwin <[EMAIL PROTECTED]> [080604 11:12] wrote:
> > On Tuesday 03 June 2008 03:04:18 pm Peter Jeremy wrote:
> > > BTW, your MUA's list-reply configuration don't recognize that
> > > freebsd-stable@ and stable@ are aliases.
> > 
> > Yes, kmail is broken and the authors refuse to fix it.  It happens on reply 
> > to 
> > a foo@ e-mail (it changes the 'To' to 'freebsd-foo@' because of the List-Id 
> > header and leaves foo@ in the 'CC' field).  Note that there isn't anything 
> > in 
> > the List headers that says that foo@ is an alias for [EMAIL PROTECTED]  I 
> > just 
> > wish I could turn off the List-Id crap and use plain old reply-to-all, but 
> > that is where the kmail developers disagree.
> 
> wtf.why not just have a checkbox to toggle the behavior?

That was my request (and I found at least 2 other open bugs for the same issue
when I looked again yesterday).  The developers reply was "an option is not an
option".

-- 
John Baldwin
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: challenge: end of life for 6.2 is premature with buggy 6.3

On Wednesday 04 June 2008 01:20:56 pm Jo Rhett wrote:
> Okay, I totally understand that FreeBSD wants people to upgrade from  
> 6.2 to 6.3.  But given that 6.3 is still experiencing bugs with things  
> that are working fine and stable in 6.2, this is a pretty hard case to  
> make.
> 
> This is also a fairly significant investment in terms of time and  
> money for any business to handle this ugprade.  It totally understand  
> obsoleting 5.x now that 7.x is out.  But 6.2 is barely a year old...

FWIW, at Y! 6.3 is more stable than 6.2 (I had a list of about 10 patches for 
known deadlocks and kernel panics that were errata candidates for 6.2 that 
never made it into RELENG_6_2 but all of them are in 6.3).  We also have many 
machines with bge(4) and from our perspective 6.3 has less issues with bge0 
devices than 6.2.

Given the real world experience I have, your claims of instability w/o even 
testing 6.3 border on silly.  Also, when it comes to bge(4), you need to be 
_very_ specific about what chipsets you are using and comparing those with 
the chipsets in the bug reports you read.  The bge(4) driver in particular 
covers a vast range of different hardware variations and is a bit of a 
hodge-podge itself.  If there is a problem with a 5705 card then it may be 
specific to just 5705 parts and not affect 575x, etc. parts.

Again, with 3ware, there are two different drivers (twe(4) vs twa(4)) and 
again, you need to be more specific with which driver you are using and which 
model controllers you have.

-- 
John Baldwin
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: cpufreq broken on core2duo (was: powerd is doing nothing?)

On Wednesday 04 June 2008 06:33:24 pm Andrew Snow wrote:
> Evren Yurtesen wrote:
> 
> > When you say that it doesnt work, does it give an error or? In my case 
> > it doesnt give any errors just says it set it but I see that nothing is 
> > set.
> 
> Here's one box:
> 
> CPU: Intel(R) Core(TM)2 Duo CPU  E8500  @ 3.16GHz
> cpu0:  on acpi0
> est0:  on cpu0
> est: CPU supports Enhanced Speedstep, but is not recognized.
> est: cpu_vendor GenuineIntel, msr 61a49200600091a
> device_attach: est0 attach returned 6
> p4tcc0:  on cpu0
> 
> 
> Here's another one:
> CPU: Intel(R) Xeon(R) CPU  E5410  @ 2.33GHz
> cpu0:  on acpi0
> est0:  on cpu0
> est: CPU supports Enhanced Speedstep, but is not recognized.
> est: cpu_vendor GenuineIntel, msr 720072006000720
> device_attach: est0 attach returned 6
> p4tcc0:  on cpu0

You can try http://www.FreeBSD.org/~jhb/patches/est_msr.patch.  It won't give 
you the full range of speeds for you CPU, but it should give you the high and 
low values that we can guess from the upper 32-bits of the MSR.

-- 
John Baldwin
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: challenge: end of life for 6.2 is premature with buggy 6.3

Kris Kennaway wrote:
> Chris Marlatt wrote:
>> Kris Kennaway wrote:
>>> Jo Rhett wrote:
 On Jun 4, 2008, at 11:39 AM, Kris Kennaway wrote:
> Also, it's not like anyone should have been caught by surprise by
> the 6.2 EoL; the expiry date has been advertised since the 6.2
> release itself.


 It has changed multiple times.  I keep reviewing and finding 6.3
 bugs outstanding, and then observe the EoL get pushed.

 I'm surprised that it failed to get pushed this time.

>>>
>>> I'm sorry that the FreeBSD project failed to conform to your
>>> expectations.  However, I invite you to actually try 6.3 for yourself
>>> instead of assuming that it will fail.
>>>
>>> Kris
>>
>> In an effort to potentially find a compromise between those who
>> believe FreeBSD is EoL'ing previous releases too quickly and those who
>> don't. Have those in a position to set FreeBSD release schedules
>> debated the option of setting a long term support release, a specific
>> release picked by the team to be support for,.. 4 or 5 years? Other
>> projects have done this will relative success and considering the
>> "only" work required for this release would be security patches the
>> work load should be minimized. Hopefully something like this could
>> free up more time for the FreeBSD developers to continue their work on
>> the newer release(s) while still answering the requests of what seems
>> like quite a few of the legacy FreeBSD users. Thoughts?
>>
>> If this has already been discussed on-list I apologize for beating a
>> dead horse but I can't recall it bring brought up before.
> 
> Uh yeah, this has been in place for *years*.  Have you actually read the
> support announcements?  They are public ;)
> 
> Kris

I do actually - and when was the last release that was support for such
a duration of time,.. 4.11? As of recent the longest I've seen has been
24 months with others being only 12.

Regards,

Chris
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Crashes in devfs. Possibly on interface creation/destruction.

2008-06-05 Thread Oleksandr Tymoshenko


Alexander Motin wrote:

Hi.

After recent upgrading from 6.3-RC1/mpd-5.0rc1 to 6.3-STABLE/mpd-5.1 
some of my PPPoE servers started to crash with about weekly period. 
Usually they just just hang without rebooting and core dumping. Consoles 
are inaccessible. All I have got from them was:


kernel: Fatal trap 12: page fau
kernel: lt while in k
kernel: ernel
kernel: mode
kernel:
kernel: cpuid = 1; apic id = 01
kernel: faut virtual address = 0x58
kernel:
kernel: fault code   = supervisor read, page not present
kernel:
kernel: instruction pointer  = 0x20:0xc04800be
kernel:
kernel: stack pointer= 0x28:0xd690883c
kernel: frame pointer= 0x28:0
kernel: xd6908854
kernel: code segment =
kernel: base 0x0, limit 0xf, type 0x1b
kernel:
kernel: = DPL 0, pres 1, def32 1, gra
kernel: n 1
kernel: processor eflags = interrupt
kernel: enab
kernel: led, r
kernel: esume
kernel: , IOPL
kernel: = 0
kernel:
kernel: current process  = 1835 (mpd5)
kernel:
kernel: trap number  = 12

"fault virtual address" and "instruction pointer" are always the same.

Address 0xc04800be looks like part of devfs code:
 > addr2line -f -e kernel.debug 0xc04800be
devfs_populate_loop
/usr/src/sys/fs/devfs/devfs_devs.c:443

devfs_devs.c:
de = devfs_newdirent(s, q - s);
if (cdp->cdp_c.si_flags & SI_ALIAS) {
de->de_uid = 0;
de->de_gid = 0;
de->de_mode = 0755;
de->de_dirent->d_type = DT_LNK;
pdev = cdp->cdp_c.si_parent;
->> line 443 ->>j = strlen(pdev->si_name) + 1;
de->de_symlink = malloc(j, M_DEVFS, M_WAITOK);
bcopy(pdev->si_name, de->de_symlink, j);

0x58 - is precisely the offset of si_name field inside of struct cdev. 
So looks like pdev = cdp->cdp_c.si_parent is NULL here for some reason.


As soon as network interfaces have respective devfs entries and looking 
higher interface creation/destruction rate that newest mpd5.1 is able to 
reach due to optimizations, I think it may be some kind or race 
somewhere interface creation.


Can somebody give me any hint where to look to?

On a quick glance the most likely place is make_dev_alias call in net/if.c
line 457. And the most likely suspect is race for if_index variable. There are
even a couple of "XXX: should be locked" notes there :)


--
gonzo
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: challenge: end of life for 6.2 is premature with buggy 6.3


Chris Marlatt wrote:

Kris Kennaway wrote:

Jo Rhett wrote:

On Jun 4, 2008, at 11:39 AM, Kris Kennaway wrote:
Also, it's not like anyone should have been caught by surprise by 
the 6.2 EoL; the expiry date has been advertised since the 6.2 
release itself.



It has changed multiple times.  I keep reviewing and finding 6.3 bugs 
outstanding, and then observe the EoL get pushed.


I'm surprised that it failed to get pushed this time.



I'm sorry that the FreeBSD project failed to conform to your 
expectations.  However, I invite you to actually try 6.3 for yourself 
instead of assuming that it will fail.


Kris


In an effort to potentially find a compromise between those who believe 
FreeBSD is EoL'ing previous releases too quickly and those who don't. 
Have those in a position to set FreeBSD release schedules debated the 
option of setting a long term support release, a specific release picked 
by the team to be support for,.. 4 or 5 years? Other projects have done 
this will relative success and considering the "only" work required for 
this release would be security patches the work load should be 
minimized. Hopefully something like this could free up more time for the 
FreeBSD developers to continue their work on the newer release(s) while 
still answering the requests of what seems like quite a few of the 
legacy FreeBSD users. Thoughts?


If this has already been discussed on-list I apologize for beating a 
dead horse but I can't recall it bring brought up before.


Uh yeah, this has been in place for *years*.  Have you actually read the 
support announcements?  They are public ;)


Kris
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: challenge: end of life for 6.2 is premature with buggy 6.3


Kris Kennaway wrote:

Jo Rhett wrote:

On Jun 4, 2008, at 11:39 AM, Kris Kennaway wrote:
Also, it's not like anyone should have been caught by surprise by the 
6.2 EoL; the expiry date has been advertised since the 6.2 release 
itself.



It has changed multiple times.  I keep reviewing and finding 6.3 bugs 
outstanding, and then observe the EoL get pushed.


I'm surprised that it failed to get pushed this time.



I'm sorry that the FreeBSD project failed to conform to your 
expectations.  However, I invite you to actually try 6.3 for yourself 
instead of assuming that it will fail.


Kris


In an effort to potentially find a compromise between those who believe 
FreeBSD is EoL'ing previous releases too quickly and those who don't. 
Have those in a position to set FreeBSD release schedules debated the 
option of setting a long term support release, a specific release picked 
by the team to be support for,.. 4 or 5 years? Other projects have done 
this will relative success and considering the "only" work required for 
this release would be security patches the work load should be 
minimized. Hopefully something like this could free up more time for the 
FreeBSD developers to continue their work on the newer release(s) while 
still answering the requests of what seems like quite a few of the 
legacy FreeBSD users. Thoughts?


If this has already been discussed on-list I apologize for beating a 
dead horse but I can't recall it bring brought up before.


Regards,

Chris
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: challenge: end of life for 6.2 is premature with buggy 6.3

2008-06-05 Thread Dag-Erling Smørgrav

Jo Rhett <[EMAIL PROTECTED]> writes:
> It has changed multiple times.  I keep reviewing and finding 6.3 bugs
> outstanding, and then observe the EoL get pushed.

The EoL date for 6.2 was pushed back *once* and once only, and that was
not in response to any specific bug report.  See for yourself:

http://www.freebsd.org/cgi/cvsweb.cgi/www/en/security/security.sgml

DES
-- 
Dag-Erling Smørgrav - [EMAIL PROTECTED]
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: CLARITY re: challenge: end of life for 6.2 is premature with buggy 6.3

2008-06-05 Thread Patrick M. Hausen

Hi, all,

On Thu, Jun 05, 2008 at 05:51:05AM -0700, Jeremy Chadwick wrote:
> On Thu, Jun 05, 2008 at 01:03:04PM +0100, Bruce M. Simpson wrote:
> > Jo Rhett wrote:
> >>
> >> I am suggesting that given that the current bug list for 6.3-RELEASE is 
> >> both (a) too large and (b) breaks things that work fine in 6.2 ... that I 
> >> think pushing 6.2 (the real stable release) into EoL is a bit rushed.  I 
> >> sympathize with the development costs of maintaining old versions.  Again, 
> >> I will help in any way I can.
> >
> > I'm sorry to hear about the problems you've been having.
> 
> If the exact regression between 6.2 and 6.3 can be tracked down, great.
> If it's in a specific driver, CVS commit logs or cvsweb will come in
> handy.  Otherwise, if it's some larger piece of code ("ohai i revamped
> the intrupt handlar!"), chances of finding it are slimmer.  I'm a bit
> disappointed that Jo hasn't explicitly mentioned what's broken in 6.3
> that's affecting him, because that might help everyone.  Heck, I'll even
> add it to my Commonly reported issue wiki page.  PRs would be good, but
> I'll gladly take past mailing list discussions.

Since we, too, use quite a few machines in production, most of
them 6.3 BTW, i spent some time searching the PRs with the
keyword "3ware" and varying combinations of release, severity, etc.

I was not able to find anything with respect to that hardware
that wasn't recorded as early as 6.1. em0 lockups were fixed
around 6.1 for us with Jack Vogels kind assistance (and hardware
provided by us ;-)

Kind regards,

Patrick M. Hausen
Leiter Netzwerke und Sicherheit
-- 
punkt.de GmbH * Kaiserallee 13a * 76133 Karlsruhe
Tel. 0721 9109 0 * Fax 0721 9109 100
[EMAIL PROTECTED]   http://www.punkt.de
Gf: Jürgen Egeling  AG Mannheim 108285
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: challenge: end of life for 6.2 is premature with buggy 6.3

2008-06-05 Thread Dag-Erling Smørgrav

Jo Rhett <[EMAIL PROTECTED]> writes:
> Absolutely not saying that.   In fact, we had 6.3 upgrade on the books
> for April but when I looked in April there were still open bugs.  I
> looked in late May and saw the same.  So we punted to late June
> (because the original end of life was June 30th) and then suddenly
> we're getting messages every night saying that we're unsupported.

The EoL for 6.2 was never June 30th.  It was originally set to January
31st when 6.2 was released, then extended by four months to May 31st.

If you have issues with 6.3, your time would be better spent reporting
them (by which I mean describe them in detail) than waving your hands in
the air and yelling at people.

DES
-- 
Dag-Erling Smørgrav - [EMAIL PROTECTED]
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: CLARITY re: challenge: end of life for 6.2 is premature with buggy 6.3

2008-06-05 Thread Jeremy Chadwick

On Thu, Jun 05, 2008 at 01:03:04PM +0100, Bruce M. Simpson wrote:
> Jo Rhett wrote:
>>
>> I am suggesting that given that the current bug list for 6.3-RELEASE is 
>> both (a) too large and (b) breaks things that work fine in 6.2 ... that I 
>> think pushing 6.2 (the real stable release) into EoL is a bit rushed.  I 
>> sympathize with the development costs of maintaining old versions.  Again, 
>> I will help in any way I can.
>
> I'm sorry to hear about the problems you've been having.

If the exact regression between 6.2 and 6.3 can be tracked down, great.
If it's in a specific driver, CVS commit logs or cvsweb will come in
handy.  Otherwise, if it's some larger piece of code ("ohai i revamped
the intrupt handlar!"), chances of finding it are slimmer.  I'm a bit
disappointed that Jo hasn't explicitly mentioned what's broken in 6.3
that's affecting him, because that might help everyone.  Heck, I'll even
add it to my Commonly reported issue wiki page.  PRs would be good, but
I'll gladly take past mailing list discussions.

Jo's opinion is reasonable, but the bottom line is that the FreeBSD
Project folks will always win the argument once the "it's best-effort"
trump card is played; the convo has to end once it's on the table.

I consider myself an advocate of open-source, but simultaneously, was
raised as a child to take responsibility for things I bring unto others.
I do not publicly release code/binaries for things I do not wish to
provide support for.  Likewise, bugs in my software are my fault, thus
thus my responsibility to fix.

The FreeBSD Project does things differently than how I do.  I have a
hard time understanding the opposing view, but every time it comes up, I
try a little harder to be open-minded about it.

Jo, as we share somewhat of the same viewpoint, I'll mention that it
would be within our best interest to try and understand the other
viewpoint, and hope that the results of (positive) karma are seen down
the road someday.

> If you want someone to take responsibility, make 'em an offer.

In my case, with some FreeBSD bugs in the past, I have offered monetary
compensation (hourly wages, reasonable by Bay Area standards) to
developers to fix issues -- only to receive absolutely no response.

Offering monetary compensation is not a solution, and I believe that's
because the core problem isn't lack of pay -- it's lack of time.  That's
one which is really hard to solve, no matter what the conditions of an
open-source project.

On the other hand, there was the "donation thing" phk@ did when he was
out of work, which I felt was great.  I still feel good about donating
to that.

-- 
| Jeremy Chadwickjdc at parodius.com |
| Parodius Networking   http://www.parodius.com/ |
| UNIX Systems Administrator  Mountain View, CA, USA |
| Making life hard for others since 1977.  PGP: 4BD6C0CB |

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: CLARITY re: challenge: end of life for 6.2 is premature with buggy 6.3

2008-06-05 Thread Bruce M. Simpson


Jo Rhett wrote:


I am suggesting that given that the current bug list for 6.3-RELEASE 
is both (a) too large and (b) breaks things that work fine in 6.2 ... 
that I think pushing 6.2 (the real stable release) into EoL is a bit 
rushed.  I sympathize with the development costs of maintaining old 
versions.  Again, I will help in any way I can.


I'm sorry to hear about the problems you've been having.

   It is worth remembering that FreeBSD is an open source project, and 
it's maintained on a best-effort basis -- it is offered for free and 
without any warranty. Like any other open source project, risk 
management and change management becomes a two-way street, because 
that's the trade-off struck with the open source model.


   The risks, as well as the benefits, have to be factored in carefully 
to your company's technology strategy, as I'm sure you're aware.


   I'm very surprised that the 6.3 train has been a big issue for you, 
although speaking from the development side of the fence, there are a 
lot of moving targets, and vendor support of the OS does play a part.
   It is difficult to offer any more specific advice without knowing in 
more detail exactly what's causing such problems for you, although I see 
you've offered general pointers, the folk directly involved need to be 
pointed at direct information.
   The FreeBSD Project just doesn't have the resources to do 
compatibility testing on the scale of e.g. Windows Hardware Quality 
Labs, as I'm sure you are also aware.


   I take on board what you say about your organisation holding back on 
an upgrade because there are PRs filed for the hardware you use, and 
having worked in an investment banking environment, I understand this 
level of conservatism is warranted.


   However, I point out again: it's the open source model, and where 
hardware compatibility is concerned, it really is a case of "suck it and 
see".
   Always has been, no different anywhere else. Open source requires 
user participation. Microsoft run the WHQL because their status as a 
going concern depends on it.


   I'm pleased to hear about your offer of hardware resources for 
developers. However, this is only part of the problem.
   To my mind, you need to find the right people, with the right 
skills, to deal with the issues, and quite often, those guys are already 
in demand, and thus their time can attract a high value. Open source 
succeeds because money is not the only motivation.

   The alternative is DIY, and that is "the point".

   If you need firm guarantees about support, consider contracting with 
someone to do that. Many companies using FreeBSD already outsource this 
kind of support requirement to 3rd parties. There are also FreeBSD 
hardware vendors who support FreeBSD as a platform.


If you want someone to take responsibility, make 'em an offer.

thanks,
BMS
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: challenge: end of life for 6.2 is premature with buggy 6.3