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

[Kostik Belousov]

On Sat, Jun 07, 2008 at 02:41:32PM +0800, Adrian Chadd wrote:
> 2008/6/7 Paul Schmehl <[EMAIL PROTECTED]>:
> 
> > Not only is this wrong, but it completely misses the point.  Why should Jo
> > have to upgrade to find out if his servers will fail under the conditions
> > already articulated in existing, unresolved PRs that affect hardware that he
> > is presently using?  That's a bit like saying, "Buy this new car.  Sure it
> > has bugs that could easily directly affect you, but what's the chance you'll
> > encounter them?  in the off chance that they do, then you can help us
> > resolve them."
> 
> The software is Free. The car was Bought (or suggested to be bought.)
> 
> Re-visit the analogy with a free car that a friend wants to give you.
> (Car analogies suck.)
> 
> 
> > Trust me.  From a server admin's perspective, a bug affects you if it exists
> > in hardware you use.  Whether or not you're actually using the OS is
> > completely irrelevant.  Upgrading to the OS would be foolhardy.  Even
> > testing it on a handful of boxes will not prove that it won't fail under
> > load in production.  Anyone who has done testing knows it can only simulate,
> > not duplicate, the conditions under which production servers run.  I
> > personally have experienced catastrophic failures after extensive testing
> > that revealed no problems.
> 
> You're using free software. This translates to "lots of people have
> put in a lot of effort to provide something to the community which
> they can use, at no cost, if it suits them."
> 
> As said before, the reason FreeBSD isn't supporting older 6.x releases
> anymore is because there's just no manpower to do so.
I want to correct this statement. We do support 6.x releases, but do
this exactly in the form of RELENG_6 and further releases from this
branch, that are in fact snapshots with more quality engineering applied
then usual.

A lot of the work put on the RELENG_6 is the support, i.e. bug fixes and
quite conservative feature merges.

Comparing us with, e.g., Solaris, we would not find a lot of difference
in the support model. Althought they formally provide patches for
Solaris 10 FCS, after patching you find youself running on the same
kernel as the Solaris 10 u5 or later. There could be an argument of
more granularity of the patches then the whole release, but inter-patch
dependencies again make the difference almost non-existent, IMHO.


pgpHYeurSoYjC.pgp
Description: PGP signature

Re: SCSI bus reset with Adaptec 29320ALP and Eonstor RAID

[David Buxton]

On 27 May 2008, at 23:00, David Buxton wrote:


Hello,

I am trying to use a 1.5TB Eonstor raid array with FreeBSD 7.0, but  
I don't understand whether it is the raid or the scsi card or  
something else that is causing the computer problems when accessing  
the raid. My problem is that soon after recognizing the attached  
disk during boot, FreeBSD appears to hang for about 10 seconds and  
then says



To follow up:

Matthew Herzog recommended I ditch the Adaptec 29320 card. I installed  
an LSI 20320-R yesterday and the errors disappeared. The RAID works  
perfectly. The Adaptec card went straight in the bin.


David.

___
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

[Evren Yurtesen]

John Baldwin wrote:

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.




The patch is causing errors in kernel compilation in FreeBSD 7-Stable.

inter-arith -Winline -Wcast-qual  -Wundef -Wno-pointer-sign -fformat-extensions 
-nostdinc  -I. -I/usr/src/sys -I/usr/src/sys/contrib/altq -D_KERNEL 
-DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common 
-finline-limit=8000 --param inline-unit-growth=100 --param 
large-function-growth=1000  -mcmodel=kernel -mno-red-zone  -mfpmath=387 -mno-sse 
-mno-sse2 -mno-mmx -mno-3dnow  -msoft-float -fno-asynchronous-unwind-tables 
-ffreestanding -Werror  /usr/src/sys/kern/imgact_elf32.c
cc -c -O -pipe -march=nocona -std=c99  -Wall -Wredundant-decls -Wnested-externs 
-Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual 
-Wundef -Wno-pointer-sign -fformat-extensions -nostdinc  -I. -I/usr/src/sys 
-I/usr/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include 
opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 
--param large-function-growth=1000  -mcmodel=kernel -mno-red-zone  -mfpmath=387 
-mno-sse -mno-sse2 -mno-mmx -mno-3dnow  -msoft-float 
-fno-asynchronous-unwind-tables -ffreestanding -Werror 
/usr/src/sys/i386/cpufreq/powernow.c
cc -c -O -pipe -march=nocona -std=c99  -Wall -Wredundant-decls -Wnested-externs 
-Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual 
-Wundef -Wno-pointer-sign -fformat-extensions -nostdinc  -I. -I/usr/src/sys 
-I/usr/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include 
opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 
--param large-function-growth=1000  -mcmodel=kernel -mno-red-zone  -mfpmath=387 
-mno-sse -mno-sse2 -mno-mmx -mno-3dnow  -msoft-float 
-fno-asynchronous-unwind-tables -ffreestanding -Werror 
/usr/src/sys/i386/cpufreq/est.c

/usr/src/sys/i386/cpufreq/est.c: In function 'bus_speed_ok':
/usr/src/sys/i386/cpufreq/est.c:1206: error: invalid storage class for function 
'est_msr_info'

cc1: warnings being treated as errors
/usr/src/sys/i386/cpufreq/est.c:1206: warning: no previous prototype for 
'est_msr_info'
/usr/src/sys/i386/cpufreq/est.c:1270: error: invalid storage class for function 
'est_get_id16'
/usr/src/sys/i386/cpufreq/est.c:1270: warning: no previous prototype for 
'est_get_id16'
/usr/src/sys/i386/cpufreq/est.c:1276: error: invalid storage class for function 
'est_set_id16'
/usr/src/sys/i386/cpufreq/est.c:1276: warning: no previous prototype for 
'est_set_id16'
/usr/src/sys/i386/cpufreq/est.c:1303: error: invalid storage class for function 
'est_get_current'
/usr/src/sys/i386/cpufreq/est.c:1303: warning: no previous prototype for 
'est_get_current'
/usr/src/sys/i386/cpufreq/est.c:1326: error: invalid storage class for function 
'est_settings'
/usr/src/sys/i386/cpufreq/est.c:1326: warning: no previous prototype for 
'est_settings'
/usr/src/sys/i386/cpufreq/est.c:1350: error: invalid storage class for function 
'est_set'

/usr/src/sys/i386/cpufreq/est.c:1350: warning: no previous prototype for 
'est_set'
/usr/src/sys/i386/cpufreq/est.c:1371: error: invalid storage class for function 
'est_get'

/usr/src/sys/i386/cpufreq/est.c:1371: warning: no previous prototype for 
'est_get'
/usr/src/sys/i386/cpufreq/est.c:1390: error: invalid storage class for function 
'est_type'

/usr/src/sys/i386/cpufreq/est.c:1390: warning: no previous prototype for 
'est_type'
/usr/src/sys/i386/cpufreq/est.c:1397: error: expected declaration or statement 
at end of input

*** Error code 1

Stop in /usr/obj/usr/src/sys/MAIL.
*** Error code 1

Stop in /usr/src.
*** Error code 1

Stop in /usr/src.
mail:/usr/src#


By the way, there is another thing I am wondering about. If I enable HTT and 
Intel Enhanced SpeedStep in bios on a 3.00GHZ p4 CPU I see:


cpu0:  on acpi0
acpi_perf0:  on cpu0
p4tcc0:  on cpu0
cpu1:  on acpi0
est1:  on cpu1
est: CPU supports Enhanced Speedstep, but is not recognized.
est: cpu_vendor GenuineIntel, msr f270f27
device_attach: est1 attach returned 6
p4tcc1:  on cpu1

dev.

Re: cpufreq broken on core2duo

[Jeremy Chadwick]

On Sat, Jun 07, 2008 at 05:51:38PM +0300, Evren Yurtesen wrote:
> By the way, there is another thing I am wondering about. If I enable HTT 
> and Intel Enhanced SpeedStep in bios on a 3.00GHZ p4 CPU I see:
>
> cpu0:  on acpi0
> acpi_perf0:  on cpu0
> p4tcc0:  on cpu0
> cpu1:  on acpi0
> est1:  on cpu1
> est: CPU supports Enhanced Speedstep, but is not recognized.
> est: cpu_vendor GenuineIntel, msr f270f27
> device_attach: est1 attach returned 6
> p4tcc1:  on cpu1
>
> dev.cpu.0.freq_levels: 1500/27000 1312/23625 1200/13000 1050/11375 900/9750 
> 750/8125 600/6500 450/4875 300/3250 150/1625
> dev.acpi_perf.0.freq_settings: 1500/27000 1200/13000
> dev.cpufreq.0.%driver: cpufreq
> dev.cpufreq.0.%parent: cpu0
> dev.cpufreq.1.%driver: cpufreq
> dev.cpufreq.1.%parent: cpu1
> dev.p4tcc.0.freq_settings: 1/-1 8750/-1 7500/-1 6250/-1 5000/-1 3750/-1 
> 2500/-1 1250/-1
> dev.p4tcc.1.freq_settings: 1/-1 8750/-1 7500/-1 6250/-1 5000/-1 3750/-1 
> 2500/-1 1250/-1
>
> and it does not allow me to set the freq. of the cpu.

How are you setting the frequency?  Are you using powerd?  You do not
have to enable SpeedStep in your BIOS to achieve throttling CPU clock
speed.  In fact, I would highly recommend leaving EIST/SpeedStep in the
BIOS *disabled*, and let powerd adjust the clock frequency via ACPI.

> I see the vcore goes to 2.32 when I set the speed to 150 according to 
> mbmon, and when I set the speed to 1500 vcore goes to 2.51

mbmon is giving you wrong values.  There is no way your Vcore on a P4 is
2.32 or 2.51 volts.  It's very likely that mbmon doesn't support your
hardware monitoring I/C.  What motherboard (exact model) do you have?

> Independent of HTT being active or not, when I enable Intel Enhanced 
> SpeedStep from the bios I start seeing calcru messages:
>
> calcru: runtime went backwards from 6 usec to 3 usec for pid 37 (pagezero)
> calcru: runtime went backwards from 6 usec to 3 usec for pid 36 (vmdaemon)
> calcru: runtime went backwards from 170 usec to 138 usec for pid 35 
> (pagedaemon)
> calcru: runtime went backwards from 553 usec to 291 usec for pid 15 (swi6: 
> task queue)
> calcru: runtime went backwards from 15521 usec to 10366 usec for pid 2 
> (g_event)
> calcru: runtime went backwards from 25 usec to 12 usec for pid 11 (swi1: net)
> calcru: runtime went backwards from 4417 usec to 3960 usec for pid 1 (init)
> calcru: runtime went backwards from 2084385 usec to 1793542 usec for pid 1 
> (init)
> calcru: runtime went backwards from 408 usec to 204 usec for pid 0 (swapper)

I've documented this problem quite clearly on my Commonly Reported
Issues wiki page.  See "Kernel - EIST incompatibilities":

http://wiki.freebsd.org/JeremyChadwick/Commonly_reported_issues

The solution is to keep EIST (SpeedStep) disabled in the BIOS.  You can
still use powerd to adjust CPU clock frequency via ACPI.

> Another weird thing is that if I keep HTT enable but disable Intel Enhanced 
> SpeedStep then I see:
>
> ...
>
> Also the sysctl changes do not return an error however the vcore voltage 
> still remains constant according to mbmon.

Again: it's highly unlikely mbmon is returning correct values.  mbmon
and healthd both were written with very old hardware (circa late 90s,
very early 2001-2002) in mind.  The chips they support are not very
common on consumer motherboards, and are no longer used on server
motherboards.

You might be interested in my bsdhwmon(8) application, but please note
I'm trying to avoid supporting any sort of "consumer" motherboards,
because many of them do not offer SMBus tie-ins, not to mention many
consumer board vendors don't provide any sort of documentation on how to
access said H/W IC functionality:

http://bsdhwmon.parodius.com/

-- 
| 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: challenge: end of life for 6.2 is premature with buggy 6.3

[Ken Smith]

On Fri, 2008-06-06 at 23:37 -0500, Paul Schmehl wrote:
> My point still stands.  I think the behavior of the developers on the 
> lists should be of as high a quality as the work they do on the OS (which, 
> as I have stated, is first rate.)  Descending to the levels that some have 
> (some of which you quote here) reflects poorly on the OS and its 
> developers.

I can empathize somewhat with your sentiment.  But at the same time I
can see where what you are criticizing comes from.

As others have said Free Software Projects function as communities.
Look around your (real) community.  I'm guessing you'll see all sorts of
different personalities.  And those personalities are often times not
shy about speaking their views.

Now, factor that in with the following analogy.  We've all seen scenes
on TV shows or in movies where a customer sends a dish back to the
kitchen via the waiter complaining about something.  The chef proceeds
to pick up a meat cleaver and head towards the door, only to be stopped
by the waiter.  Sometimes on the mailing lists you'll see the reaction
of the chef, there is no waiter to stop him/her.

That's just the nature of the community structure surrounding Open
Source Projects and it's not unique to FreeBSD.  Corporations you can
expect to be held to higher standards, or more specifically held to
standards that you would hold all corporations to.  When on the mailing
lists you can't expect "corporate standards", what you'll get is
"community standards".

-- 
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

[Andrew Reilly]

On Fri, Jun 06, 2008 at 12:08:54PM -0400, Vivek Khera wrote:
> 
> On Jun 4, 2008, at 4:43 PM, Clifton Royston wrote:
> 
> > Speaking just for myself, I'd love to get a general response from
> >people who have run servers on both as to whether 6.3 is on average
> >more stable than 6.2.  I really haven't gotten any clear impression as
> 
> I'll throw in my "+1" for running 6.3.  I have it on many boxes, some  
> of which run gmirror and some of which have bge devices (some with  
> both).  Never any problems.  They operate things varying from Postgres  
> servers to DNS servers to mail servers (postfix) under pretty  
> consistent load pushing lots and lots of data both network and to disk.

I'll second your "+1" for 6.3 and raise you a 7.0.  My main
server is a 1U Dell box with bge network interfaces and it's
as happy as a clam under 7.0 (infrequently updated _STABLE,
actually).

All of my more single-use boxes are happy 7_STABLE campers, too.

Most of 'em are close to 0 load average, but they're important,
continuously used by their smallish user base, and stay up.

Cheers,

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

cpufreq for Opteron quad-core (2354)

[Arno J. Klaassen]

Hello,

apparently powernow on Opteron quad-core is not recognised; when
I kldload cpufreq (leaving it out of kernel) I get :

pci0: driver added
pci1: driver added
pci2: driver added
pci3: driver added
pci4: driver added
pci5: driver added
pci6: driver added
found-> vendor=0x9005, dev=0x0285, revid=0x00
domain=0, bus=6, slot=14, func=0
class=01-04-00, hdrtype=0x00, mfdev=0
cmdreg=0x0196, statreg=0x0230, cachelnsz=16 (dwords)
lattimer=0xf8 (7440 ns), mingnt=0x01 (250 ns), maxlat=0x01 (250 ns)
intpin=a, irq=28
powerspec 2  supports D0 D1 D3  current D0
MSI supports 2 messages, 64 bit
pci0:6:14:0: reprobing on driver added
pci7: driver added
pci8: driver added
pci9: driver added
pci10: driver added


but no dev.cpu.0.freq* showing up.

When I dig up the by me so beloved good old acpi_ppc it says :

cpu0: Px state: P0, 2200MHz, 28000mW, 19us, 19us
cpu0: Px state: P1, 2000MHz, 26250mW, 19us, 19us
cpu0: Px state: P2, 1700MHz, 23750mW, 19us, 19us
cpu0: Px state: P3, 1400MHz, 21250mW, 19us, 19us
cpu0: Px state: P4, 1100MHz, 18750mW, 19us, 19us
cpu0: Px method: Unknown, disabled

This box will probably stay at my office for a while and I'd be glad to
provide more information.

Best, Arno

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

Current status of support for high end SAN hardware

[Andy Kosela]

Hi all,
What is the current status of support for high end SAN hardware in FreeBSD?
I'm especially interested in support for HP EVA/XP disk arrays, Qlogic
HBAs, multipathing.
How FreeBSD compares in this environment to RHEL 5?

-- 
Andy Kosela
ora et labora
___
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

[Mike Edenfield]

Paul Schmehl wrote:

Furthermore, it seems the reaction of developers, that he wasn't being 
specific enough are rendered moot by the urls above, which were easily 
accessed by me, someone with little knowledge at all of two of the 
three issues.  So, rather than berating Jo for not producing PRs, 
wouldn't it have been more professional to list the relevant PRs (just 
as I have done, which took me less time than the multiple angry 
responses to Jo took the involved developers) and ask him which of 
them gave him the greatest concerns?
I'm sure I'm not the only person besides yourself who's actually done 
the searches to see if there are any PRs I may be able to shed light on 
for Jo.  I also briefly read each PR, and even a brief persual would show:
 

That url lists 6 serious problems for bge and 3 non-critical problems, 
some dating to more than two years ago.  Two were patched, one is 
suspended and 6 are still open; four of those critical.
Only 3 (2 critical and one patched) of which are specific to 6.3.  One 
is specific to IPv6 and one only occurring on the second of a dual-card 
configuration; we have no reason to believe that either of these relate 
to Jo's environment without his providing that kind of detail.
 
That url lists 1 serious problem and 3 non-critical problems with 
gmirror, all of which remain open.
Only one of these is specific to 6.3, and it appears very low priority, 
almost cosmetic.
 



That url refers to locking problems that cause kernel panics using the 
twe driver.

This appears to be a bug in aac, not twe.



That url refers to a hang that renders a system unusable when using 
the twa driver.

And it was present in 6.2.

Unfortunately the URLs only serve to make the developer's points for 
them.  None of them gives any indication of what problem Jo may be 
referring to that is preventing him from upgrading to 6.3.  Remember, he 
claims to have multiple servers running 6.2 with no issues, and is only 
concerned with upgrades to 6.3.  He also stated that the PR's he's 
worried about explicitly stated that they could not be reproduced in 
6.2, so any bug that existed in 6.2 clearly doesn't qualify.  That rules 
out all but two bugs, both of which are so specific to a given hardware 
setup that it would be impossible to know if they apply in this case or not.


--Mike

___
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

[Jo Rhett]

On Jun 5, 2008, at 1:39 AM, Peter Jeremy 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.



Sorry, Peter to have annoyed you, but this kind of language is useless  
for accomplishing anything other than pissing me off.  I'm not going  
to go there.


And I never "refused" anything, simply indicated that I didn't have  
time at that moment.


--
Jo Rhett
Net Consonance : consonant endings by net philanthropy, open source  
and other randomness



___
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

[Jo Rhett]

On Jun 5, 2008, at 2:45 AM, Steven Hartland wrote:

You are still fail to take to the time to even tell people what these
bugs are, no ones a mind reader!

People are trying to help you here but all I'm hearing is a child like
"It doesn't work fix it", with no willingness to even explain what it
is or provide resources to test if someone found the time to  
investigate

your issues.
Given this I don't see how you can expect these so called issues to
ever get fixed.


I think you are misunderstanding the point at hand.  I'm not trying to  
address specific issues.  (I'd be happy to in another thread next  
week).  This thread was created to address the overall well-documented  
list of bugs in 6.3, which is the *only* supported stable version of  
the operating system.  (7.0 is even less stable)


The most stable (by numbers of bugs and numbers of reported problems)  
is 6.2.


I see no valid reasoning that can be backed up by numbers as to why  
6.2 should be EoL.  That's the point I'm addressing.  The specific  
bugs that affect us are not necessarily relevant to the overall  
stability.  And anyone can do the same searches on the bug list to  
confirm these numbers for themselves.


--
Jo Rhett
Net Consonance : consonant endings by net philanthropy, open source  
and other randomness



___
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

[Jo Rhett]

On Jun 5, 2008, at 4:34 AM, Adrian Chadd wrote:

If its of major concern for you, then allocate some man hours, grab
the /usr/src/sys diffs between RELENG_6_2_0_RELEASE  and
RELENG_6_3_0_RELEASE.

The others on the list have stated over and over again that they
haven't seen any issues and would like to know precisely what they
are.


While I appreciate their concern for the specifics, I think those  
should be addressed in another thread.  This thread was meant to  
question the overall stability issues that pretty much anyone can view  
for themselves in the freebsd-questions/hardware/scsi mailing lists  
and queries in the open bug reports.



If stability is your main concern then you could throw some resources
at fixing 6.3 or throw some resources at backporting security fixes to
6.2.


I will apparently be backporting the security fixes myself until 6.4  
ships.



I'm sure noone has an agenda to squish the FreeBSD version you're
using for any reason other than there aren't enough people
volunteering / being paid to work on back-porting security fixes.



This is perhaps the real topic that needs to be addressed.  Can we get  
some more details on the issues involved here?


--
Jo Rhett
Net Consonance : consonant endings by net philanthropy, open source  
and other randomness



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

Re: Current status of support for high end SAN hardware

[Daniel Ponticello]

On FreeBSD7, i'm succesfully using Qlogic 4gb fibre channel HBAs (ISP 
driver)
attached to Fibre Brocade Switch and IBM DS4700 (14 disks array) using 4 
way multipath

with gmultipath.

Regards,

Daniel

Andy Kosela ha scritto:

Hi all,
What is the current status of support for high end SAN hardware in FreeBSD?
I'm especially interested in support for HP EVA/XP disk arrays, Qlogic
HBAs, multipathing.
How FreeBSD compares in this environment to RHEL 5?

  


--

WBR,
Cordiali Saluti,

Daniel Ponticello, VP of Engineering

Network Coordination Centre of Skytek

---
- For further information about our services: 
- Please visit our website at http://www.Skytek.it

---

___
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

[Jo Rhett]

(Top posted because I didn't want to snip what you said)

Bruce, all of what you said below is well known.  I understand and  
don't have any problem with this.  You seem to be trying to address  
something I wasn't asking about -- certifications, etc and such.  Not  
a concern.


The question I raised is simply: given the number of bugs opened and  
fixed since 6.3-RELEASE shipped, why is 6.3 the only supported  
version?  Why does it make sense for FreeBSD to stop supporting a  
stable version and force people to choose between two different  
unstable versions?  Is this really the right thing to do?


On Jun 5, 2008, at 5:03 AM, Bruce M. Simpson wrote:
  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


--
Jo Rhett
Net Consonance : consonant endings by net philanthropy, open source  
and other randomness



___
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

[Jo Rhett]

On Jun 5, 2008, at 5:51 AM, Jeremy Chadwick wrote:
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.


I will start a new thread with the specific issues that concern my  
environment upon my return.  I'd like to keep the specific issues  
separate from the overall policy question, because they are very  
different in my mind.



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.


Yes, but it often gets played too often too fast.  It's worth having a  
discussion of the policy goals.  I'm not saying that this isn't the  
very best that FreeBSD can do -- maybe it is.  I just couldn't find  
any documentation of why dropping 6.2 makes a lot of sense, so I was  
hoping to get a clear answer for that.


--
Jo Rhett
Net Consonance : consonant endings by net philanthropy, open source  
and other randomness



___
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

[Dick Hoogendijk]

On Sat, 7 Jun 2008 12:53:10 -0700
Jo Rhett <[EMAIL PROTECTED]> wrote:

> Why does it make sense for FreeBSD to stop supporting a  stable
> version and force people to choose between two different unstable
> versions?  Is this really the right thing to do?

NO, it's not.
But you can't change that. The maintainers run the show. It's their time
and their baby. And from one pov that's true. Users have to shut up
if not contributing big time.

I still think your questions are legitimate.
You won't win the battle however.

-- 
Dick Hoogendijk -- PGP/GnuPG key: 01D2433D
++ http://nagual.nl/ + SunOS sxde 01/08 ++
___
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

[Jo Rhett]

On Jun 5, 2008, at 6:09 AM, Dag-Erling Smørgrav wrote:

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.



Must you resort to nonsense and hyperbole?

I'd said nearly a dozen times that the issues I have aren't  
specifics.  I am questioning the overall policy for EoL here. Even if  
it was known to work properly on my hardware the overwhelming amount  
of bugs in 6.3 indicates an unstable release.  The diffs between 6.3  
and 6-STABLE are greater than the diffs between 6.2 and 6.3 last time  
I checked.


I can't understand the logic in having only a single supported version  
of the OS, especially one which so many known/reported/fixed-post- 
release bugs.


And please don't respond if you can't avoid resorting to hyperbole  
like what I quoted above.


--
Jo Rhett
Net Consonance : consonant endings by net philanthropy, open source  
and other randomness



___
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

[Evren Yurtesen]

Jeremy Chadwick wrote:

On Sat, Jun 07, 2008 at 05:51:38PM +0300, Evren Yurtesen wrote:
By the way, there is another thing I am wondering about. If I enable HTT 
and Intel Enhanced SpeedStep in bios on a 3.00GHZ p4 CPU I see:


cpu0:  on acpi0
acpi_perf0:  on cpu0
p4tcc0:  on cpu0
cpu1:  on acpi0
est1:  on cpu1
est: CPU supports Enhanced Speedstep, but is not recognized.
est: cpu_vendor GenuineIntel, msr f270f27
device_attach: est1 attach returned 6
p4tcc1:  on cpu1

dev.cpu.0.freq_levels: 1500/27000 1312/23625 1200/13000 1050/11375 900/9750 
750/8125 600/6500 450/4875 300/3250 150/1625

dev.acpi_perf.0.freq_settings: 1500/27000 1200/13000
dev.cpufreq.0.%driver: cpufreq
dev.cpufreq.0.%parent: cpu0
dev.cpufreq.1.%driver: cpufreq
dev.cpufreq.1.%parent: cpu1
dev.p4tcc.0.freq_settings: 1/-1 8750/-1 7500/-1 6250/-1 5000/-1 3750/-1 
2500/-1 1250/-1
dev.p4tcc.1.freq_settings: 1/-1 8750/-1 7500/-1 6250/-1 5000/-1 3750/-1 
2500/-1 1250/-1


and it does not allow me to set the freq. of the cpu.


How are you setting the frequency?  Are you using powerd?  You do not
have to enable SpeedStep in your BIOS to achieve throttling CPU clock
speed.  In fact, I would highly recommend leaving EIST/SpeedStep in the
BIOS *disabled*, and let powerd adjust the clock frequency via ACPI.


I have tested if it is working or not without using powerd. However you are 
right, SpeedStep in bios seem to be adding some ACPI support which looks like 
kind of broken.


In either case, I get error when I have HTT as powerd (powerd -v) is only able 
to change 1 CPUs speed (obviously). Perhaps this can be fixed in future hopefully.


In the bios, there is also Enhanced C1 support which seems to be reducing the 
vcore voltage at the same clock speed. (is this normal even?)


I see the vcore goes to 2.32 when I set the speed to 150 according to 
mbmon, and when I set the speed to 1500 vcore goes to 2.51


mbmon is giving you wrong values.  There is no way your Vcore on a P4 is
2.32 or 2.51 volts.  It's very likely that mbmon doesn't support your
hardware monitoring I/C.  What motherboard (exact model) do you have?


I thought about that actually but at this moment the importance is that it is 
changing only under certain conditions, there is probably some mistake in mbmon 
which skews the results.


This is the motherboard (information from the datacenter):
http://www.supermicro.com/products/motherboard/PD/E7230/PDSML-LN2.cfm
Although kenv | grep smbios show PDSBM can this be or the datacenter is wrong?

I just went to bios and says 1.264v so I guess it is safe to assume that mbmon 
was showing double.


Independent of HTT being active or not, when I enable Intel Enhanced 
SpeedStep from the bios I start seeing calcru messages:


calcru: runtime went backwards from 6 usec to 3 usec for pid 37 (pagezero)
calcru: runtime went backwards from 6 usec to 3 usec for pid 36 (vmdaemon)
calcru: runtime went backwards from 170 usec to 138 usec for pid 35 (pagedaemon)
calcru: runtime went backwards from 553 usec to 291 usec for pid 15 (swi6: 
task queue)

calcru: runtime went backwards from 15521 usec to 10366 usec for pid 2 (g_event)
calcru: runtime went backwards from 25 usec to 12 usec for pid 11 (swi1: net)
calcru: runtime went backwards from 4417 usec to 3960 usec for pid 1 (init)
calcru: runtime went backwards from 2084385 usec to 1793542 usec for pid 1 
(init)
calcru: runtime went backwards from 408 usec to 204 usec for pid 0 (swapper)


I've documented this problem quite clearly on my Commonly Reported
Issues wiki page.  See "Kernel - EIST incompatibilities":

http://wiki.freebsd.org/JeremyChadwick/Commonly_reported_issues

The solution is to keep EIST (SpeedStep) disabled in the BIOS.  You can
still use powerd to adjust CPU clock frequency via ACPI.


Yes, I have nothing against keeping it closed. :)

Another weird thing is that if I keep HTT enable but disable Intel Enhanced 
SpeedStep then I see:


...

Also the sysctl changes do not return an error however the vcore voltage 
still remains constant according to mbmon.


Again: it's highly unlikely mbmon is returning correct values.  mbmon
and healthd both were written with very old hardware (circa late 90s,
very early 2001-2002) in mind.  The chips they support are not very
common on consumer motherboards, and are no longer used on server
motherboards.

You might be interested in my bsdhwmon(8) application, but please note
I'm trying to avoid supporting any sort of "consumer" motherboards,
because many of them do not offer SMBus tie-ins, not to mention many
consumer board vendors don't provide any sort of documentation on how to
access said H/W IC functionality:


Yes, as a coincidence I found:
http://fixunix.com/freebsd/384760-looking-supermicro-hardware-owners.html

I have 2 other servers with:
http://www.supermicro.com/products/motherboard/Xeon1333/5000V/X7DVL-i.cfm
(eh this one gives "X7DVL" correctly in kenv output also :) )
and I have some Intel products. I can test out bsdhwmo

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

[Jo Rhett]

Hi, John.  Thanks for your update and I'll keep your experience in mind.

As stated in previous messages, I'll open new threads in the  
appropriate lists about any specific driver issues (with details) that  
I am concerned about.  This thread was intended to deal with the  
overall policy issue for dropping 6.2 in just barely more than a year..


On Jun 5, 2008, at 7:23 AM, John Baldwin wrote:

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


--
Jo Rhett
Net Consonance : consonant endings by net philanthropy, open source  
and other randomness



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

please stop being nasty to people.

[Jo Rhett]

On Jun 5, 2008, at 8:01 AM, Kris Kennaway wrote:
Uh yeah, this has been in place for *years*.  Have you actually  
read the

support announcements?  They are public ;)

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



Kris, is this kind of repeated nastiness necessary?

Most everyone who has posted on this thread cares deeply about FreeBSD  
and does what they can to support it.  What do you hope to gain by  
being nasty to them?


--
Jo Rhett
Net Consonance : consonant endings by net philanthropy, open source  
and other randomness



___
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

[sthaug]

> I'd said nearly a dozen times that the issues I have aren't  
> specifics.  I am questioning the overall policy for EoL here. Even if  
> it was known to work properly on my hardware the overwhelming amount  
> of bugs in 6.3 indicates an unstable release.

No. 6.3 is very stable for us, on multiple machines. So is 7.0. And I
have seen lots of other users basically saying the same thing.

*You* are the one claiming that "the overwhelming amount of bugs in 6.3
indicates an unstable release" - yet you are unwilling to test 6.3 and
you are also unwilling to show the PRs you claim exist. My sympathy for
such a view is limited.

Personally, I'm very happy with the work that the developers have put
in and are *continuing* to put in. However, I'm just a user, not a
developer. I have occasionally contributed bug fixes to FreeBSD, which
is *my* best waying of returning the favor of all of the persons who
have spent countless hours, often unpaid, to make FreeBSD a better
system. I hope they continue!

Steinar Haug, Nethelp consulting, [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

[Jo Rhett]

On Jun 5, 2008, at 8:39 AM, Kris Kennaway wrote:
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.


I'm honestly sorry to hear that.  I tried very hard with the very  
limited time I had available to me to phrase it clearly as a policy/ 
support issue and not to put the blame on any developer.  There are  
number of issues in projects I support that are waiting on time from  
me too, so I can hardly point any fingers in that direction.  We *all*  
have less time to work on this stuff than we might want.



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


In rereading my quotes I may have not been clear on something.  The  
vast majority of these bugs have already been fixed. ("not in a state  
that needs help identifying" was what I said trying to cover both that  
and known bugs without a fix yet)


However, the fixes are not available in a -RELEASE version of the  
operating system.  This is why EoLing 6.2 and forcing people to  
upgrade to a release with lots of known issues is a problem.


Obviously you have to choose between developer time/effort to create a  
release candidate and the effort required to backdate security patches  
to 6.2.  I don't know the reasons (which is why I created this thread)  
but my guess was the latter was easier than the former...


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.


Although the insults aren't helpful, I agree with you.  I created this  
thread because I have a "failure of understanding".  I'd appreciate  
some enlightenment of the real costs involved (and how we could help  
if possible).  That's why I created this thread.


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



You seem quite willing to make enemies.  I'm not your enemy, and we'd  
both probably get a lot more work done if you stopped treating me like  
one.


--
Jo Rhett
Net Consonance : consonant endings by net philanthropy, open source  
and other randomness



___
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

[Jo Rhett]

On Jun 5, 2008, at 8:39 AM, 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.
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!"..



Adrian, your other comments are smart and valid.  Why is this kind of  
hyperbole necessary?


I never said anything tragic or emergency or anything like that.  I  
questioned the practicality of having a single supported release with  
significant known bugs in it.


It will take pretty much all the time I spend supporting FreeBSD os  
and applications away to focus entirely on backporting security  
patches back to 6.2.   I know of several other organizations facing  
the same problem.


--
Jo Rhett
Net Consonance : consonant endings by net philanthropy, open source  
and other randomness



___
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

[Jo Rhett]

On Jun 5, 2008, at 8:39 AM, Adrian Chadd wrote:

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.



Splinter groups, in my experience, tend to create duplicate work loads  
and make things harder, not easier.  They seem to be useful only when  
there is a deadlock in the core team, and so far FreeBSD has avoided  
that.


I would rather focus my efforts on something that produces more  
effective results.


This is the reasoning behind my question: why drop 6.2 and 6.1 at the  
same time?  What is the real cost of supporting 6.2 until a new stable  
version ships?


--
Jo Rhett
Net Consonance : consonant endings by net philanthropy, open source  
and other randomness



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

Re: please stop being nasty to people.

[Eric Masson]

Jo Rhett <[EMAIL PROTECTED]> writes:

Hi,

>> Yes, and this is the FreeBSD definition of "long term support".
>> Don't like it?  Do something about it.
>
> Kris, is this kind of repeated nastiness necessary?

This is not nastiness, if you don't like the way the project manages
release lifecycle, you have workarounds :
- Test new release-candidates to verify no regression pop up in your
  standard setup, fill PRs about problems if needed and help project
  developpers to make the release better.
- Pay someone to maintain the One True Release that suits your
  particular needs.
- Use an os/distro that has the kind of long term support you seem to
  need.

You just can't expect to moan on a mailing list about hypothetical bugs
that would impact your setup and be welcomed as the new messiah as you
demand extended support for a previous release just because you haven't
done your homework.

-- 
 > Follow-up fmb.linux, parce que la charte de fca.emacs, redigee par mes
 > soins, interdit les trolls GNU Emacs/XEmacs, sur lesquels je suis le
 > premier a me lancer :-)
 -+- JK in guide du linuxien pervers - bien configurer sa charte -+-
___
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

[Patrick M. Hausen]

Hello,

On Sat, Jun 07, 2008 at 01:28:21PM -0700, Jo Rhett wrote:

> In rereading my quotes I may have not been clear on something.  The vast 
> majority of these bugs have already been fixed. ("not in a state that needs 
> help identifying" was what I said trying to cover both that and known bugs 
> without a fix yet)
> 
> However, the fixes are not available in a -RELEASE version of the operating 
> system.

Yes. So what?

Upgrading your systems to 6.3 takes _precisely_ the same amount
of work as upgrading to "6-STABLE as of today 00:00 GMT".
You may want to pick a different point of time, but it really
doesn't matter, because a release _is_ just a CVS branch created
at a certain time.

> This is why EoLing 6.2 and forcing people to upgrade to a release 
> with lots of known issues is a problem.

People who have issues with RELENG_6_3 should upgrade to RELENG_6
which is perfectly supported.

Kind regards,
Patrick
-- 
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

[Jo Rhett]

On Jun 5, 2008, at 8:53 AM, Patrick M. Hausen wrote:

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


I'm sure somebody would complain ;-)  but yeah, valid.  Unfortunately  
I was on my 3rd day of less than 3 hours sleep and had to leave in  
less than 9 hours from my post, with 12 hours of work to do before  
then.  I really honestly didn't have the time.


I wanted to hold the post until I returned, but last time I did that I  
got dozens of accusations of sitting on it and speaking sooner, etc etc.


I was hoping in my wishes-were-horses brain that someone would provide  
some insight into the issues that made obsoleting 6.2 a good idea, so  
that on my return I could determine how best to focus my efforts.



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].

...

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.


Because focusing on the specifics never helps with policy issues.   
Every time I raise a policy issue and someone asks for specific bugs  
relevant, I answer them and the overall policy issue degrades into the  
merits of the specific problem, and usually into insults from people  
who don't understand why I don't replace X piece of hardware.  The  
overall policy question gets lost.


--
Jo Rhett
Net Consonance : consonant endings by net philanthropy, open source  
and other randomness



___
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

[Jo Rhett]

On Jun 5, 2008, at 8:58 AM, Chris Marlatt wrote:
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.



Thank you.

--
Jo Rhett
Net Consonance : consonant endings by net philanthropy, open source  
and other randomness



___
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

[Jo Rhett]

On Jun 5, 2008, at 9:34 AM, Ken Smith wrote:
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.  :-)


2 years would be perfectly fine in my mind.  I'd love to see 2 years  
of support for 6.2-RELEASE.


6.2 was (and *is* AFAIK) the most stable release of FreeBSD since 4.11  
and it came out the door with less than 12 months of support intended.


--
Jo Rhett
Net Consonance : consonant endings by net philanthropy, open source  
and other randomness



___
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]

Jo Rhett wrote:

I'd said nearly a dozen times that the issues I have aren't specifics.  
I am questioning the overall policy for EoL here.


Your concerns have been noted. You seem unwilling or unable to accept 
the explanation that no matter what you think about the situation, we 
don't have the resources to support 6.2.


Furthermore, according to the vast number of people with way more 
experience and way more hardware running 6.3 than you have (jhb from 
Yahoo! alone qualifies in this category, but he wasn't alone) your 
concerns are in fact, misplaced.


To drive this thread even further into the realm of uselessness, you 
seem to be dead set on replying to every single post, saying basically 
the same thing over and over, and not listening to anything anyone is 
telling you.


So I would like to suggest that you simply stop. Enjoy your trip. When 
you come back if you have specific concerns about your EXPERIENCE 
running 6.3 (or later) on your specific hardware, fire away.


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

[Max Laier]

On Saturday 07 June 2008 21:41:18 Jo Rhett wrote:
> On Jun 5, 2008, at 2:45 AM, Steven Hartland wrote:
> > You are still fail to take to the time to even tell people what these
> > bugs are, no ones a mind reader!
> >
> > People are trying to help you here but all I'm hearing is a child
> > like "It doesn't work fix it", with no willingness to even explain
> > what it is or provide resources to test if someone found the time to
> > investigate
> > your issues.
> > Given this I don't see how you can expect these so called issues to
> > ever get fixed.
>
> I think you are misunderstanding the point at hand.  I'm not trying to
> address specific issues.  (I'd be happy to in another thread next
> week).  This thread was created to address the overall well-documented
> list of bugs in 6.3, which is the *only* supported stable version of
> the operating system.  (7.0 is even less stable)
>
> The most stable (by numbers of bugs and numbers of reported problems)
> is 6.2.
>
> I see no valid reasoning that can be backed up by numbers as to why
> 6.2 should be EoL.  That's the point I'm addressing.  The specific
> bugs that affect us are not necessarily relevant to the overall
> stability.  And anyone can do the same searches on the bug list to
> confirm these numbers for themselves.

Here is a cluebat for you:

Messages in this flamboyant thread of yours: 113 and counting
Messages in support of your claim not sent by yourself: 0

Now please: STFU or invest your time into something more productive.  By 
the way, for somebody who claims to have no time to provide details about 
the bugs that make 6.3 so bad you seem to have a lot of time to send 
bogus emails (26 since Wednesday).  If you had only spend a bit of that 
time into actual bughunting ...

-- 
/"\  Best regards,  | [EMAIL PROTECTED]
\ /  Max Laier  | ICQ #67774661
 X   http://pf4freebsd.love2party.net/  | [EMAIL PROTECTED]
/ \  ASCII Ribbon Campaign  | Against HTML Mail and News
___
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

[Jo Rhett]

On Jun 5, 2008, at 10:27 AM, Doug Barton wrote:

I'm pretty sure the only person that's going to matter to is you.

...

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



Doug, is this really necessary?  Is this kind of response going to help?

Chris, please accept my apology for having created this thread as it  
seems to have become nothing more than an opportunity for people talk  
nastily to others.


--
Jo Rhett
Net Consonance : consonant endings by net philanthropy, open source  
and other randomness



___
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

[Jo Rhett]

On Jun 5, 2008, at 10:27 AM, Doug Barton wrote:

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?


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.



Doug, would you possibly (without attacking me?) give some insight  
into the issues here?  This is what I was asking: what prevents  
supporting 6.2 ?  Where could I best apply some of my time to improve  
the situation?


--
Jo Rhett
Net Consonance : consonant endings by net philanthropy, open source  
and other randomness



___
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

[Jo Rhett]

On Jun 5, 2008, at 10:31 AM, Steven Hartland wrote:
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.



How do you know I haven't?  Point of fact, I have.   This thread was  
not about the specific bug fixes not yet available in a -RELEASE.


This thread was to question the reasoning behind obsoleting 6.2 so  
very quickly.  It's a policy issue, not a single bug report.  It has  
more to do with the "X results" column in a PR search than any single  
one of the entries.


--
Jo Rhett
Net Consonance : consonant endings by net philanthropy, open source  
and other randomness



___
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

[Jo Rhett]

On Jun 5, 2008, at 10:38 AM, Doug Barton wrote:
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.



That's a very separate issue.  I was asking about the policy  
reasoning.  Fixing all of the bugs affecting my environment won't help  
me until they are -RELEASE, which is going to a take a lot of  
resources.  A lot more than supporting 6.2, right?  If not, please  
educate me.


And please stop being nasty.  I'd said much the same thing over the  
last 5 days, but I haven't once uttered a word about you not reading  
what has already been said repeatedly.  Nor does that topic interest  
me.  I am curious about the policy issue involved here.


--
Jo Rhett
Net Consonance : consonant endings by net philanthropy, open source  
and other randomness



___
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]

Jo Rhett wrote:

On Jun 5, 2008, at 10:27 AM, Doug Barton wrote:

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?


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.



Doug, would you possibly (without attacking me?) give some insight into 
the issues here?  This is what I was asking: what prevents supporting 
6.2 ? 


Lack of time on the part of the people that do the support. (As has 
been explained lots of times already.) I realize that you'd rather 
have an answer that gives you something to argue about, but there 
isn't one.



Where could I best apply some of my time to improve the situation?


Backport patches that you find interesting or relevant to 6.2, and 
post on the -stable list to let others know where to find them.



Doug (no, I'm not being flippant)

--

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

[Jo Rhett]

Mark, I'm confused by this message.  You direct your message to me,  
but quote Kris and Chris and then using those comments attack me.  I  
think you may have my own comments confused.


Finally, I haven't asked for anything you are attacking me for here.   
You are apparently restating what you think I said into things and  
attacking me for those ... or something.  I'm entirely confused by  
this message, sorry :-(


On Jun 5, 2008, at 11:18 AM, Mark Linimon wrote:

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:

 relall kern
 ------ 
 6.0210  91
 6.1217  81
 6.2396 102
 6.3167  56
 7.0563 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


--
Jo Rhett
Net Consonance : consonant endings by net philanthropy, open source  
and other randomness



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

console access

[Jo Rhett]

On Jun 5, 2008, at 11:35 AM, Paul Schmehl wrote:
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.


Paul, you should arrange with your colocation provider to get an out  
of band serial connection to the system, and configure the console to  
go to the serial port.  We provide that for free at $EMPLOYER and most  
other places I know of do it for free or nominal charge.


Obviously an operation like ours has lights-out access to everything,  
but we have a dozen or so freebsd developers as customers, and they  
routinely rebuild their machines entirely without ever visiting the  
facility.  GNN in particular lives in Japan these days so a colo visit  
would take him a day or two...


--
Jo Rhett
Net Consonance : consonant endings by net philanthropy, open source  
and other randomness



___
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

[Jo Rhett]

On Jun 5, 2008, at 3:02 PM, Peter Jeremy wrote:

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 didn't refuse, I said it wasn't relevant.  I also offered to provide  
the list and hardware and time resources for testing if any developer  
needed it after June 11 (ie when it was physically possible to do so)  
for anyone who wanted to chase the individual issues.  But the  
individual issues aren't the problem.  No single problem would usually  
warrant that kind of attention.  It's the overall amount of issues  
that concerns me.



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?


Perhaps answer the question which was asked, instead of trying to drag  
the conversation down into specific bug reports?  No single specific  
bug report is relevant to the overall topic.  Fixing a single bug  
won't improve the situation.


Anyway, I've said this a dozen times now so I won't be repeating it.   
You are welcome to continue ignoring it.


--
Jo Rhett
Net Consonance : consonant endings by net philanthropy, open source  
and other randomness



___
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

[Jo Rhett]

On Jun 5, 2008, at 3:32 PM, Scott Long wrote:

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.


Scott, you are missing the point in your apparent desire to be rude.   
When there are bugs where something does not work (and nobody else has  
already reported it) I do open bugs.  And more than 90% of my bug  
reports include patches too.  I know how that works.


The point is that 6.2-RELEASE works well for many people where 6.3- 
RELEASE does not.  Until 6.4-RELEASE ships there will be a lot of  
unsupported systems.



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,


Again, I'm not seeing anything other than you talking down to someone  
that (I think) you know from personal experience knows better than that.



but it seems pretty clear that continuing to argue it in this
forum isn't really solving anything.


You're right.  As usual, people would rather insult and attack than  
address the issue which was raised.  This is why I rarely bother with  
the mailing lists -- flame wars produce no code.



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.



As stated previously, I'll create another thread about the specific  
bugs that concern me upon my return.  Those are not specifically  
relevant to the policy issue here.  (and those threads will be created  
in the appropriate hardware-specific list instead of the general - 
stable mailing list)


--
Jo Rhett
Net Consonance : consonant endings by net philanthropy, open source  
and other randomness



___
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

[Mike Edenfield]

Jo Rhett wrote:
This is why EoLing 6.2 and forcing people to upgrade to a release with 
lots of known issues is a problem.
You keep saying this as if it's somehow unusual that 6.3 has a lot of 
open bugs.  Yet even a cursory look at the PR list (admittedly based 
just on the specific drivers you mentioned early on, but presumably a 
decent random sampling) shows that most of the remaining open issues in 
6.3 are not new, and were present in 6.2 or even as far back as 6.0.  
Certainly there are plenty of issues that were fixed in 6.3 that were 
present in the 6.2 version you're already running.


In other words, you haven't provided any real support to back up your 
claim that 6.3 is significantly "less stable", for whatever that means, 
than 6.2.  Meanwhile, the vast majority of the anecdotal, first-person 
experience in running 6.3 in production indicates quite the opposite -- 
that it's *more* stable than 6.2.  You've already stated that you don't 
want to side track this thread with specifics about your exact bugs.  
The problem is, without specifics to back up your claims of instability, 
they are (in your own words) little more than hyperbole.  It shouldn't 
surprise anyone that you got a negative reaction to that kind of statement.


--Mike

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

kernel panic on em0/taskq

[Daniel Ponticello]

Hello,
i'm experiencing periodic kernel panics on a server with  FreeBSD 
7.0-STABLE #0: Tue May 20 19:09:43 CEST 2008.
My big problem is that the system is not performing memory dumping 
and/or automatic reoboot,

it just stays there.

Here' console output:

em0: watchdog timeout -- resetting
kernel trap 12 with interrupts disabled

Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic_id = 00
fault virtual address   = 0x14
fault code = supervisor read, page not present
intruction pointerr = 0x20:0xc056e2ce
stack pointer = 0x28:0xe537fc08
frame pointer= 0x28:0xe537fc28
code segment= base 0x0, limit 0xf, type 0x1b
   = DPL 0, pres 1, def32 1, gran 1
processor eflags = resume, IOPL = 0
current process  = 29 (em0 taskq)
trap number   = 12
panic: page fault
cpuid = 0


It just stays there, unresponsive (no automatic reboot).



Any  ideas?


Thanks,

Daniel

--

WBR,
Cordiali Saluti,

Daniel Ponticello, VP of Engineering

Network Coordination Centre of Skytek

---
- For further information about our services: 
- Please visit our website at http://www.Skytek.it

---

___
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

[Jo Rhett]

On Jun 5, 2008, at 6:04 PM, Mike Edenfield wrote:
In short, the problem reports that the OP is looking at are not  
immediately obvious to someone who doesn't already know what they  
are, and he's not doing himself any favors by insisting that  
everyone else "already knows" about these problems.  If he's seen  
these bug reports, presumably he knows what their PR #'s are, or at  
the very least the description of the bugs, and it would be many  
many times faster for him to just say so than continue to insist  
that other people read his mind.



Mike, could you do me a favor and provide me with a set of words that  
will make what I am trying to say on this topic clear?  I keep saying  
the same thing over and over again and nobody is hearing me, so could  
you perhaps help me translate this?


These are the raw issues without any friendly wording.

1. Bugs in 6.3 that are patched aren't available in any other -RELEASE.
2. Bugs in 6.3 outstanding that don't affect 6.2
3. Overall amount of bugs.
4. Difference in code base between 6.3 and 6-STABLE is > than 6.2 and  
6.3


These combine to produce a release which will never be "stable" for  
production needs.


Obviously the FreeBSD team(s) involved have to make choices.  Perhaps  
there's nothing we can do to improve it other than work on the  
specific bugs.  But does it hurt to ask why 6.2 was dropped so fast?   
What the real cost of supporting 6.2 until 6.4 ships is?


--
Jo Rhett
Net Consonance : consonant endings by net philanthropy, open source  
and other randomness



___
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

[Jo Rhett]

On Jun 6, 2008, at 6:08 AM, Dag-Erling Smørgrav wrote:

Three people replied to Jo Rhett's initial email.  Here's what they
said, with Jo's own text elided:


Among other things, you time-warped some of my comments into replies  
to things people said to the comments themselves.  But the most  
crucial is that you dropped the entire point I was trying to make and  
focused on someone else's desire to focus on the specific bugs, rather  
than the overall policy issue.  So your entire thread is misguided at  
best.   Specific bugs are always addressed on the PRs themselves or  
the hardware-specific mailing list, not on the general -stable list.


Even worse is your summary:


I won't pretend to know what Jo is thinking or what his motivation is,
but in my experience, when people respond in this manner, it's because
they know they have no solid data or arguments, and are trying to save
face.


What face?  Huh?  Exactly what face do I have to save?  Why on gods  
green earth would I put saving face over system stability?  I think  
you are confusing me with someone who has time to spend all day  
writing on mailing lists/forums and considers their reputation  
important.  You're dealing with exactly the opposite -- I rarely read  
the mailing lists due to lack of time, and generally don't care what  
people think of me as long as it doesn't get in the way of getting  
work done.



I hope this helps you to better understand who's attacking who, and
who's being rude to who.



You should perhaps start at the beginning and look at the questions I  
asked, and then recreate the thread showing the responses to the  
policy questions I have raised.


Or just look at your own responses, which have never been less than  
rude and not once even pretended to focus on the real questions.


--
Jo Rhett
Net Consonance : consonant endings by net philanthropy, open source  
and other randomness



___
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

[Jo Rhett]

On Jun 4, 2008, at 8:22 PM, Jo Rhett wrote:
If you're asking why I don't turn a production environment over to  
being a freebsd-unstable-testbed, I can't really answer that  
question in a way you'd understand (if you were asking that question)


On Jun 6, 2008, at 9:11 AM, Vivek Khera wrote:
If you don't have an identical setup to test new software, then  
you're pretty much not able to ever upgrade anything, IMO, and your  
"production" environment *is* a testbed for new software.



You clipped the part where I said exactly the same thing, and also  
explained why it wasn't really useful for the problems named.


Are you done getting off a random pot-shot?  Interested in focusing on  
the real questions?


--
Jo Rhett
Net Consonance : consonant endings by net philanthropy, open source  
and other randomness



___
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

[Jo Rhett]

On Jun 6, 2008, at 11:41 PM, Adrian Chadd wrote:

As said before, the reason FreeBSD isn't supporting older 6.x releases
anymore is because there's just no manpower to do so.


Which is what I was asking about.  I've asked the questions more  
specifically since they apparently weren't phrased well the first  
time.  It would be great to hear answers to those questions.



I still don't think you get it. FreeBSD is a community. A community
works when enough people contribute positively towards furthering the
goals of the project. Jo is a user. He sounds like he is using it in
some reasonably critical and money-earning roles. Jo can participate
by testing stuff on test hardware, reporting back issues and working
with the community.


Which I do.  If you check out my bug reports they almost always  
include patches.


I've also added freebsd support to many projects, including full  
package management in the latest versions of cfengine.



Bitching about there being no long-term support
for releases isn't constructive. Some developer comments may not be
constructive either, but this is a -community project-. Join the
-community- and help out.


Am I missing an ID card?  Where should I go to acquire one?

When there is a specific issue I can help with, I do.  In this case I  
was asking about the justification for dropping support so quickly.



It doesn't matter if running a long-term support project would be
beneficial for a certain subset of the userbase, its a losing
situation to cater to them unless they somehow contribute back to the
community.



I work on bugs for things I can help with.  I add freebsd support to  
various projects.  I test and report bugs on new releases.  I spend at  
least 10% (and sometimes more) of my paid $EMPLOYER's time working on  
freebsd things, and countless hours of unpaid time.  I don't know that  
I can do any more than this.


--
Jo Rhett
Net Consonance : consonant endings by net philanthropy, open source  
and other randomness

___
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

[Dick Hoogendijk]

On Sat, 7 Jun 2008 14:37:11 -0700
Jo Rhett <[EMAIL PROTECTED]> wrote:

> These are the raw issues without any friendly wording.
> 
> 1. Bugs in 6.3 that are patched aren't available in any other
> -RELEASE. 2. Bugs in 6.3 outstanding that don't affect 6.2
> 3. Overall amount of bugs.
> 4. Difference in code base between 6.3 and 6-STABLE is > than 6.2
> and 6.3
> 
> These combine to produce a release which will never be "stable" for  
> production needs.

You are in fact saying 6.3-RELEASE should not have been released at the
time it was. It should have been posponed 'till some open bugs were
solved. I agree with you that a RELEASE is supposed to be more mature /
stable then a development version. And you state it is -not-

-- 
Dick Hoogendijk -- PGP/GnuPG key: 01D2433D
++ http://nagual.nl/ + SunOS sxde 01/08 ++
___
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

[Garance A Drosehn]

At 2:02 PM -0700 6/7/08, Jo Rhett wrote:


This thread was to question the reasoning behind obsoleting 6.2 so 
very quickly.  It's a policy issue, not a single bug report.  It has 
more to do with the "X results" column in a PR search than any 
single one of the entries.


Some CLARITY:

There is not a single committer that I know of who is convinced
by your argument that we (committers) should sign up for the
additional work of supporting 6.2 for an additional 6 months.

That is the answer to your "policy concern".
Let me say again:
   *That* is the answer to your policy concern.
and:
   That *is* the answer to your policy concern.
and:
   That is the answer to your *policy* concern.

If you have specific issues that you experience with 6.3, then
several committers are still willing to investigate those issues,
because those would (presumably) help other users who have
already upgraded to 6.3.

--
Garance Alistair Drosehn =   [EMAIL PROTECTED]
Senior Systems Programmer   or   [EMAIL PROTECTED]
Rensselaer Polytechnic Institute; Troy, NY;  USA
___
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

[Jo Rhett]

On Jun 7, 2008, at 1:56 AM, Kostik Belousov wrote:
Comparing us with, e.g., Solaris, we would not find a lot of  
difference

in the support model. Althought they formally provide patches for


Huh?  I'm totally not saying that you should be trying to match the  
support model of a large corporation, this statement is outright  
wrong.  I can still get security patches for Solaris 2.8 which shipped  
almost 6 years ago now.


Again, I'm not saying that 6 years is reasonable for FreeBSD - just  
pointing out that the statement is invalid.


--
Jo Rhett
Net Consonance : consonant endings by net philanthropy, open source  
and other randomness



___
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

[Jo Rhett]

On Jun 7, 2008, at 12:59 PM, Dick Hoogendijk wrote:

I still think your questions are legitimate.
You won't win the battle however.



Obviously I got a battle, but that wasn't what I wanted.  I wanted to  
understand the issues involved and from that determine how I might be  
able to help.


--
Jo Rhett
Net Consonance : consonant endings by net philanthropy, open source  
and other randomness



___
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

[Garance A Drosehn]

At 2:37 PM -0700 6/7/08, Jo Rhett wrote:


Mike, could you do me a favor and provide me with a set of words 
that will make what I am trying to say on this topic clear?  I keep 
saying the same thing over and over again and nobody is hearing me, 
so could you perhaps help me translate this?


The fact that we reject your request that we provide further support
for 6.2 does not mean we did not understand the question.  It is you
who are not understanding the reply.

What you are asking for is *SUPPORT* for 6.2.  That implies that we
need to guarantee we will spend time *WORKING* on 6.2.  We see no
benefit in doing that.  We would much rather spend that time to
improve things in 6.3, because 6.3 is one of the branches we are
supporting.

As soon as you can tell us how we "support" 6.2 without *working*
on 6.2, then maybe you'll have a more attentive audience.

--
Garance Alistair Drosehn =   [EMAIL PROTECTED]
Senior Systems Programmer   or   [EMAIL PROTECTED]
Rensselaer Polytechnic Institute; Troy, NY;  USA
___
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

[Oliver Fromme]

Jo Rhett wrote:
 > Ken Smith wrote:
 > > 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.  :-)
 > 
 > 2 years would be perfectly fine in my mind.  I'd love to see 2 years  
 > of support for 6.2-RELEASE.
 > 
 > 6.2 was (and *is* AFAIK) the most stable release of FreeBSD since 4.11  
 > and it came out the door with less than 12 months of support intended.

I'm running various FreeBSD versions on lots of machines
at customers and our own offices.  Among them are about
40 servers with various types of bge(4) chips, and some
machines use gmirror.  AFAIK we don't have machines with
3ware adapters, so I can't comment on that.  But the
bge(4) driver runs better with 6.3, 7.0 and 6/7-stable
than it did with 6.2.  We never had any gmirror problems,
so it's neither worse nor better.  It just works as
expected.

Overall I regard *both* 6.3 and 7.0 more stable than 6.2.

I'm in the process of bringing most machines to 7.0 or
7-stable, and so far it goes very well.  In some cases
the performance has noticably improved, especially on
multicore servers.  I haven't experienced any stability
problems so far.

I'm with FreeBSD since 2.0.5-Release.  I think 7.0 is
the most stable dot-zero release that the project ever
had.

Best regards
   Oliver

-- 
Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M.
Handelsregister: Registergericht Muenchen, HRA 74606,  Geschäftsfuehrung:
secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün-
chen, HRB 125758,  Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart

FreeBSD-Dienstleistungen, -Produkte und mehr:  http://www.secnetix.de/bsd
___
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

[Jo Rhett]

On Jun 7, 2008, at 1:44 PM, Patrick M. Hausen wrote:

Upgrading your systems to 6.3 takes _precisely_ the same amount
of work as upgrading to "6-STABLE as of today 00:00 GMT".


No, it doesn't.  You can get to 6.3 with freebsd-update.  And you can  
stay patched with freebsd-update on a -RELEASE.  For a corporation to  
choose to stick with -RELEASE makes perfect sense, and it specifically  
what the -RELEASE versions were intended for.



You may want to pick a different point of time, but it really
doesn't matter, because a release _is_ just a CVS branch created
at a certain time.



This is why EoLing 6.2 and forcing people to upgrade to a release
with lots of known issues is a problem.


People who have issues with RELENG_6_3 should upgrade to RELENG_6
which is perfectly supported.


I'm sorry, but you clearly don't run RELENG_6 on anything.  I run it  
on two home computers, and grabbing it on any given day and trying to  
run with it in production is insanity.  Lots and lots of things are  
committed, reverted, recommitted, reverted and then finally  
redesigned.  Each of those steps are often committed to the source  
tree.  The -RELEASE versions prevent this kind of insanity.


I'm struggling to find a phrase here that can't be taken to be an  
insult, so forgive me and try to understand when I say that you really  
should try watching the cvs tree for a bit before making a nonsense  
comment like that.


--
Jo Rhett
Net Consonance : consonant endings by net philanthropy, open source  
and other randomness



___
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

[Jo Rhett]

On Jun 7, 2008, at 1:52 PM, Doug Barton wrote:
I'd said nearly a dozen times that the issues I have aren't  
specifics.  I am questioning the overall policy for EoL here.


Your concerns have been noted. You seem unwilling or unable to  
accept the explanation that no matter what you think about the  
situation, we don't have the resources to support 6.2.


I haven't been given an explanation.   I was given that bare  
statement.  An explanation might help me understand where I can help  
improve the situation.


Furthermore, according to the vast number of people with way more  
experience and way more hardware running 6.3 than you have (jhb from  
Yahoo! alone qualifies in this category, but he wasn't alone) your  
concerns are in fact, misplaced.


The people that I know of working around problems in 6.3 all work at  
Yahoo, so ...


To drive this thread even further into the realm of uselessness, you  
seem to be dead set on replying to every single post, saying  
basically the same thing over and over, and not listening to  
anything anyone is telling you.


So far I have been (a) insulted (b) told to "take it or leave it" or  
(c) demanded to provide specific PRs.


Nobody has responded to the question.

So I would like to suggest that you simply stop. Enjoy your trip.  
When you come back if you have specific concerns about your  
EXPERIENCE running 6.3 (or later) on your specific hardware, fire  
away.


I suspect you are right, it's time to stop dealing with FreeBSD.  The  
product is quality, but the abuse one has to sustain to ask a question  
on the mailing list isn't worth it.


--
Jo Rhett
Net Consonance : consonant endings by net philanthropy, open source  
and other randomness



___
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

[Jo Rhett]

On Jun 7, 2008, at 2:46 PM, Garance A Drosehn wrote:

Your concern has been noted and rejected.


My actual questions were never answered.


you are "challenging" others to support 6.2 for you.  For free.


No, I never did that.  I asked why it was a good idea.  And I have  
always offered to help, and have always helped as much as I could with  
anything to do with freebsd.  For free :-)



Several committers have offered to look at any bugs which prevent you
from going to 6.3, and you don't want to hear about that.


No, I said I would provide all those details as soon as I could.


workload is such that you don't really want to even look at any
FreeBSD changes this year, and you assume that our workload is such


Are you just making this stuff up?  My only comments about workload  
was that it was on my schedule for May, then June...  I could totally  
do this upgrade NOW if it was feasible.



Your challenge has been read by many committers, and your challenge
has been found lacking, impractical and uninteresting.  Now, is it
true that every single freebsd committer must reply to this thread
and tell you "Sorry, but No"?  And we must all be nice while we do
it, or we'll also be lectured about our manners?



I find it sad that again you find it more interesting to be insulting  
that to respond in a helpful manner to the questions raised.


--
Jo Rhett
Net Consonance : consonant endings by net philanthropy, open source  
and other randomness



___
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

[Jo Rhett]

On Jun 7, 2008, at 3:00 PM, Garance A Drosehn wrote:

There is not a single committer that I know of who is convinced
by your argument that we (committers) should sign up for the
additional work of supporting 6.2 for an additional 6 months.


I never asked for that.


That is the answer to your "policy concern".
Let me say again:
  *That* is the answer to your policy concern.
and:
  That *is* the answer to your policy concern.
and:
  That is the answer to your *policy* concern.


NICE.  Go with the insults.  Nothing better than pissing off people  
who work for you for free.


--
Jo Rhett
Net Consonance : consonant endings by net philanthropy, open source  
and other randomness



___
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

[Jo Rhett]

On Jun 7, 2008, at 3:00 PM, Dick Hoogendijk wrote:
You are in fact saying 6.3-RELEASE should not have been released at  
the

time it was. It should have been posponed 'till some open bugs were
solved. I agree with you that a RELEASE is supposed to be more  
mature /

stable then a development version. And you state it is -not-



That's direct criticism that I am not willing to make of the  
contributors.  I'm sure everyone did the best they could, and with  
what they knew at the time.


I'm saying that now, in retrospect, it doesn't appear to be a stable  
release.  Forcing everyone to upgrade to a unstable release doesn't  
seem likely to help improve the situation.


--
Jo Rhett
Net Consonance : consonant endings by net philanthropy, open source  
and other randomness



___
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

[Jo Rhett]

On Jun 7, 2008, at 3:05 PM, Garance A Drosehn wrote:

The fact that we reject your request that we provide further support
for 6.2 does not mean we did not understand the question.  It is you
who are not understanding the reply.


At the very least, I phrased my question badly.  Because I asked "why"  
and I heard "no".  And "no" is not an answer to "why".  I still  
haven't heard the why.



What you are asking for is *SUPPORT* for 6.2.  That implies that we


No, I never asked for that.  Depending on the answer to "why" I was  
going to decide what my choices were for helping out and improving the  
situation in some form.  Without the "why" I haven't the foggiest idea  
how to help.  (for already well known bugs which don't need my time/ 
effort/attention)


--
Jo Rhett
Net Consonance : consonant endings by net philanthropy, open source  
and other randomness



___
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

[Garance A Drosehn]

At 1:04 PM -0700 6/7/08, Jo Rhett wrote:

On Jun 5, 2008, at 6:09 AM, Dag-Erling Smørgrav wrote:

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.


Must you resort to nonsense and hyperbole?

I'd said nearly a dozen times that the issues I have aren't specifics.
I am questioning the overall policy for EoL here.


Your concern has been noted and rejected.  Since you obviously are not
the FreeBSD project, there will be nothing gained by repeating your
concern for the thirtieth time.  It is getting mighty annoying that
you are "challenging" others to support 6.2 for you.  For free.

Several committers have offered to look at any bugs which prevent you
from going to 6.3, and you don't want to hear about that.  Your
workload is such that you don't really want to even look at any
FreeBSD changes this year, and you assume that our workload is such
that we could painlessly continue to guarantee support for the specific
release that you want to stick with for another year.  Sorry, but we're
busy too.

We are not changing the rules on you.  When you upgraded to 6.2, we
announced when the EOL would be.  We extended that once already.  You
have not provided a compelling argument why we should extend it again.

In some ways, I can understand your concern.  My own manager has very
similar opinions to yours.  He solved it by choosing linux and buying
into the "Enterprise Edition"s of Redhat.  5 years of support.  I
suggest you look into that option.  It seems better suited to your
needs.  It is a sad truth that the FreeBSD project is not able to be
everything to everybody, but there it is.  As much as we might like
to, but we simply can't.

Perhaps you can find a number of other people who love 6.2 and hate
6.3, and together you can pay someone to support 6.2 for you.  The
way my manager pays Redhat for extended support.

As Kris has noted, there has been nothing of value in this thread.
Initially it looked like there might be, but the more you talk the
less it seems you have a legit complaint.

Your challenge has been read by many committers, and your challenge
has been found lacking, impractical and uninteresting.  Now, is it
true that every single freebsd committer must reply to this thread
and tell you "Sorry, but No"?  And we must all be nice while we do
it, or we'll also be lectured about our manners?

--
Garance Alistair Drosehn =   [EMAIL PROTECTED]
Senior Systems Programmer   or   [EMAIL PROTECTED]
Rensselaer Polytechnic Institute; Troy, NY;  USA
___
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

[Steven Hartland]

Seriously man, is it really necessary to reply to every single post?

How about you spend some of that time and effort testing 6.3 or 7.0
instead of winging about things which may or may not in fact be any
issue at all, as you have not even bothered to test.

- Original Message - 
From: "Jo Rhett" <[EMAIL PROTECTED]>
No, I never asked for that.  Depending on the answer to "why" I was  
going to decide what my choices were for helping out and improving the  
situation in some form.  Without the "why" I haven't the foggiest idea  
how to help.  (for already well known bugs which don't need my time/ 
effort/attention)



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

[Ken Smith]

On Sat, 2008-06-07 at 14:37 -0700, Jo Rhett wrote:

> These are the raw issues without any friendly wording.
> 
> 1. Bugs in 6.3 that are patched aren't available in any other -RELEASE.
> 2. Bugs in 6.3 outstanding that don't affect 6.2
> 3. Overall amount of bugs.
> 4. Difference in code base between 6.3 and 6-STABLE is > than 6.2 and  
> 6.3
> 
> These combine to produce a release which will never be "stable" for  
> production needs.

The issue seems to be that we see no evidence that there is any
significant volume to your item #2, and that's why you are receiving so
much push-back on this.  And that's what you are being asked for
evidence of.  That is the ONLY thing that should be preventing you from
upgrading to 6.3.  Item #1 can't be addressed at all and affects you
while you're running 6.2 just as much as it would affect you running
6.3.  Item #3 is irrelevant in most peoples' eyes because again we see
no evidence that those bugs that would be part of #3 are not in 6.2 as
well as 6.3.  Item #4 is also a non-issue since there is no telling if
any of that code that's changed affects something that you would notice.
For example if a chunk of the code that's changed between 6.3 and
6-STABLE were an amd(8) import that has absolutely no relevance to any
of this discussion, 6.3's overall stability, etc.

As for your overall question of "Why can't 6.2 continue to be
supported?" I answered that but from your reply it seems you may not
have quite understood it.  We typically support the LAST release in a
branch for 2 years, it's typical to not support the earlier releases
that long.  That is based on the theory that we don't have regressions,
and that if we do have regressions we fix them with Errata Notices.  We
did indeed have a major regression with 6.3 - there was a problem with
the threads libraries which has been fixed with an Errata Notice.

As I say the reason for so much push-back seems to be the lack of any
concrete evidence that there are major regressions (by definition a
regression being something that had worked in 6.2 that is broken in
6.3).  From peoples' experiences and their surveys of the PR list we
have not seen any evidence of the regressions you say you are concerned
about - it seems like anything that would affect you in 6.3 should also
be affecting you in 6.2.  Since we all seem to be unable to find what
you are concerned about could you please (when you have time - I have
noticed you said you were time-crunched) let us know what they are?
Given that perhaps we can address the issues and do Errata Notices.

You have also asked about costs.  A large one is the time of the
volunteers on the security team.  We take Security Advisories and Errata
Notices VERY seriously - we try very hard to make sure that what gets
posted is absolutely correct.  That means applying the patches to all
branches concerned and testing them as best we can.  As code ages some
of the more complicated patches can cause concern that they're not quite
right for the older code because of fundamental changes that have been
made (for example locking kernel data structures is hard, at times
extremely complex, and what you need to "watch out for" can change over
time even within a X-STABLE branch).  And there is some cost in
time/energy/resources to maintain FreeBSD-Update support.

Those things don't mean we can't continue support of 6.2, but they do
mean it requires effort.  And again we can't seem to find any evidence
that the effort is needed since we can't seem to find any evidence of
*regressions* in 6.3.  So when you've got the time let us know what
evidence it is we're missing.  And again, pointing at the CVS repository
and saying "lots changed" isn't evidence.  That's completely irrelevant
because of many things including what I mentioned above (e.g. an import
of vendor code shows up as changed code in our CVS repository but for
the purposes of this discussion it's irrelevant).

-- 
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

[Garance A Drosehn]

At 3:29 PM -0700 6/7/08, Jo Rhett wrote:

On Jun 7, 2008, at 3:05 PM, Garance A Drosehn wrote:

The fact that we reject your request that we provide further support
for 6.2 does not mean we did not understand the question.  It is you
who are not understanding the reply.


At the very least, I phrased my question badly.  Because I asked 
"why" and I heard "no".  And "no" is not an answer to "why".  I 
still haven't heard the why.


Apparently the email with this answer from Doug Barton did not
reach you:

Lack of time on the part of the people that do the support.
(As has been explained lots of times already.) I realize
that you'd rather have an answer that gives you something
to argue about, but there isn't one.

Nothing has changed since his email.

--
Garance Alistair Drosehn =   [EMAIL PROTECTED]
Senior Systems Programmer   or   [EMAIL PROTECTED]
Rensselaer Polytechnic Institute; Troy, NY;  USA
___
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]

Jo Rhett wrote:

On Jun 7, 2008, at 1:52 PM, Doug Barton wrote:
I'd said nearly a dozen times that the issues I have aren't 
specifics.  I am questioning the overall policy for EoL here.


Your concerns have been noted. You seem unwilling or unable to accept 
the explanation that no matter what you think about the situation, we 
don't have the resources to support 6.2.


I haven't been given an explanation.   I was given that bare statement.  
An explanation might help me understand where I can help improve the 
situation.


The only message in this thread that you have NOT responded to was the 
one where I answered these questions for you (again) in simple terms. 
The people that do the work of supporting branches do not have the 
time to support 6.2. You're not going to get another answer because 
there isn't one.


It's clear from you rhetorical style that you are uninterested in 
anything in the vicinity of a constructive conversation, so this is my 
last response to you.


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

[Brian]

However, the fixes are not available in a -RELEASE version of the operating 
system.



  

Does freebsd-update not address these?

Brian
___
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]

2008/6/8 Jo Rhett <[EMAIL PROTECTED]>:

>> If stability is your main concern then you could throw some resources
>> at fixing 6.3 or throw some resources at backporting security fixes to
>> 6.2.
>
> I will apparently be backporting the security fixes myself until 6.4 ships.

And if you do, someone (or me, if noone bothers) will be quite happy
to commit them to the release branch.

>> I'm sure noone has an agenda to squish the FreeBSD version you're
>> using for any reason other than there aren't enough people
>> volunteering / being paid to work on back-porting security fixes.
>
>
> This is perhaps the real topic that needs to be addressed.  Can we get some
> more details on the issues involved here?

.. There isn't much to say. There aren't enough people putting in
their volunteer time to work on this. If you / your company is willing
to begin fixing this problem by contributing back to the community, I
bet the security team will be quite happy to work with you to get the
work done.

And you get that fuzzy, warm feeling from contributing to an open
source project. :)

If everyone who wants 6.2 to be maintained longer wants to put in a
couple hours a week of time to help maintain and backport stuff, I
think we as a project would be stupid to say no. You just have to be
prepared to do the work and be honest enough to say when you're unable
to do it anymore.

Anyway, this thread is making people upset. :)



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]

2008/6/8 Jo Rhett <[EMAIL PROTECTED]>:
> On Jun 5, 2008, at 8:39 AM, 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.
>> 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!"..
>
>
> Adrian, your other comments are smart and valid.  Why is this kind of
> hyperbole necessary?

Oh don't mind me, I occasionally get pissed off too. :) I have this
exact problem with the other project I work on (Squid), and it just
gets mto me sometimes.



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: CLARITY re: challenge: end of life for 6.2 is premature with buggy 6.3

[Clifton Royston]

On Sat, Jun 07, 2008 at 12:53:10PM -0700, Jo Rhett wrote:
...
> The question I raised is simply: given the number of bugs opened and  
> fixed since 6.3-RELEASE shipped, why is 6.3 the only supported  
> version?  Why does it make sense for FreeBSD to stop supporting a  
> stable version and force people to choose between two different  
> unstable versions?  Is this really the right thing to do?

  In what sense do you consider 6.2 stable?  Stable as compared to
what?

  I think a part of the problem here - not the only part - is that you
are using idiosyncratic definitions of terms.

  -- Clifton

-- 
Clifton Royston  --  [EMAIL PROTECTED] / [EMAIL PROTECTED]
   President  - I and I Computing * http://www.iandicomputing.com/
 Custom programming, network design, systems and network consulting services
___
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

[Dag-Erling Smørgrav]

Jo Rhett <[EMAIL PROTECTED]> writes:
> 2 years would be perfectly fine in my mind.  I'd love to see 2 years
> of support for 6.2-RELEASE.

Well, you're getting two years for 6.3.

> 6.2 was (and *is* AFAIK) the most stable release of FreeBSD since 4.11
> and it came out the door with less than 12 months of support intended.

6.2 was released on 2007-01-15.  The original EoL date was 2008-01-31,
and was later pushed back to 2008-05-31.  How is that "less than 12
months of support intended"?

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

[Dag-Erling Smørgrav]

Jo Rhett <[EMAIL PROTECTED]> writes:
> Dag-Erling Smørgrav <[EMAIL PROTECTED]> writes:
> > 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.
> Must you resort to nonsense and hyperbole?

I'll stop the minute you start backing your claims with data - by which
I mean PR numbers at the very least, and preferably information about
the outcome of your own tests.

> I'd said nearly a dozen times that the issues I have aren't specifics.

You mean apart from this:

 > gmirror failures, 3ware raid driver timeouts, bge0 problems.  All
 > three in production use on dozens of systems.

or this:

 > The bugs in question were very well documented.

Sounds to me like you have something pretty specific in mind - yet you
consistently refuse to share any of it with us.  Every time someone asks
you for more information, you dodge the issue with nonsense like the
following:

> I am questioning the overall policy for EoL here. Even if it was known
> to work properly on my hardware the overwhelming amount of bugs in 6.3
> indicates an unstable release.

Which overwhelming amount of bugs?  Mark Linimon gave you the numbers:

 > Finally, here are some statistics about PR count:
 > 
 >   relall kern
 >   ------ 
 >   6.0210  91
 >   6.1217  81
 >   6.2396 102
 >   6.3167  56
 >   7.0563 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.

Looks like there are significantly fewer open PRs against 6.3 than
against 6.2.

> The diffs between 6.3 and 6-STABLE are greater than the diffs between
> 6.2 and 6.3 last time I checked.

Yet another claim that is simply not supported by evidence:

[EMAIL PROTECTED] ~/projects/freebsd/releng_6/src% ncvs diff -Nu 
-rRELENG_6_2_BP -rRELENG_6_3_BP >/tmp/releng62-releng63.diff
[EMAIL PROTECTED] ~/projects/freebsd/releng_6/src% ncvs diff -Nu 
-rRELENG_6_3_BP -rRELENG_6 >/tmp/releng63-releng6.diff
[EMAIL PROTECTED] ~/projects/freebsd/releng_6/src% wc /tmp/releng6*
 1177219 4227294 48994670 /tmp/releng62-releng63.diff
  481059 2094131 16180209 /tmp/releng63-releng6.diff
 1658278 6321425 65174879 total

> I can't understand the logic in having only a single supported version
> of the OS, especially one which so many known/reported/fixed-post- 
> release bugs.

As you have been repeatedly told: we do what we can with the resources
we have.

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]"

6.2; 6.3; EOL; combustible discussions

[Adrian Chadd]

Ok everyone, I think thats enough about this for now.

I think the developers and users have made their points clear, and
they're no going to agree any more (but they may agree less) over
time.

For now, I think we should wait for the following:

* Some users standing up, stating "yes, 6.2 lifetime means a lot to
us, we'll happily contribute back security fixes and/or bug fixes for
our hardware so we can continue using it!", and then doing so.
* Some users (Jo, in particular) providing hardware which 6.2 runs on
but 6.3 may or may not, and allowing interested developers to jump on
and test/debug, so this whole discussion can be ejected out the
nearest airlock.
* Users figuring out they can contribute back to the community. It
isn't hard, honest. How do you think some of us learnt how stuff
works? :)

Anything else, really, is just going to continue upsetting people.
Yes, users want stability in their specific environments. Yes,
developers are mere mortals, and users should be happy that there's
even a project here they can get access to without some kind of
warez-like upload/download ratio. further discussion is just going to
upset people even further. :)



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: 6.2; 6.3; EOL; combustible discussions

[Josh Carroll]

> I think the developers and users have made their points clear, and
> they're no going to agree any more (but they may agree less) over
> time.

You make it sound as if all users are of the same opinion as Jo. The
majority of the responses from users running 6.3 in the thread(s) have
been positive feedback of its operating properly. I know what you
meant, though. Just don't want anyone to think there is somehow a line
being drawn in the sand between users and developers. :)

> * Some users standing up, stating "yes, 6.2 lifetime means a lot to
> us, we'll happily contribute back security fixes and/or bug fixes for
> our hardware so we can continue using it!", and then doing so.

While it would be interesting to see the response here, it still
doesn't necessarily provide a solution. It will still involved
developers' time to QA the user-submitted patches, so it won't
entirely eliminate the additional workload for maintainers. There is
also zero (enforceable) accountability. If X people commit to this,
what happens when only a fraction of them actually do end up helping?

> * Some users (Jo, in particular) providing hardware which 6.2 runs on
> but 6.3 may or may not, and allowing interested developers to jump on
> and test/debug, so this whole discussion can be ejected out the
> nearest airlock.

That would, of course, require that Jo actually try to run 6.3 on his
particular hardware, something he said he does not have the time
(currently) to do. As others have pointed out, hardware often has
numerous revisions and it's quite possible 6.3 will work fine for him.

> Anything else, really, is just going to continue upsetting people.
> Yes, users want stability in their specific environments. Yes,
> developers are mere mortals, and users should be happy that there's
> even a project here they can get access to without some kind of
> warez-like upload/download ratio. further discussion is just going to
> upset people even further. :)

I agree, the horse has been beaten to death numerous times.

I guess the one thing that I've taken away from this entire discussion
is that perhaps it would be useful to the end users to have a
managed/tracked list of regressions between releases. I know there are
known bugs published, but is there a list of items that are strictly
regressions? Even if it doesn't solve the problem of users with
particular hardware configurations being able to run the new release,
at least it's something people can use in deciding when/if to upgrade
or whether they want to go the route of self-supporting
security/errata fixes until they find a release they feel comfortable
migrating to?

Just my two cents, and hopefully I'm not throwing wood on the fire here.

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

Re: gmirror patches

[Dag-Erling Smørgrav]

Pete French <[EMAIL PROTECTED]> writes:
> Ah, yes, sorry about that - thought it would be obvious. I always
> submit changes that way as I find that whitespace has a habit
> of breaking otherwise.
> [...]
> How would I set about doing that without the whitespace being messed up
> by email transit ? I have always found in the past that tabs end up as
> spaces and then patch gets upset hwne you try to apply it.

"email transit" does not mess up whitespace, though perhaps your web
browser does (when you copy-paste the patch from the web interface).

If the patches were submitted as PR attachments (using 'send-pr -a'),
you can download them separately from the web interface, and avoid the
entire copy-paste issue:

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

Finally, if you do end up with a patch with messed-up whitespace, you
can still apply it using 'patch -l'.

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: console access

[Paul Schmehl]

--On June 7, 2008 2:16:26 PM -0700 Jo Rhett <[EMAIL PROTECTED]> 
wrote:



On Jun 5, 2008, at 11:35 AM, Paul Schmehl wrote:

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.


Paul, you should arrange with your colocation provider to get an out of
band serial connection to the system, and configure the console to go to
the serial port.  We provide that for free at $EMPLOYER and most other
places I know of do it for free or nominal charge.



I was not aware of that.  Thanks for the suggestion.

Paul Schmehl
If it isn't already obvious,
my opinions are my own and not
those of my employer.

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

[Paul Schmehl]

--On June 7, 2008 2:41:32 PM +0800 Adrian Chadd <[EMAIL PROTECTED]> wrote:


2008/6/7 Paul Schmehl <[EMAIL PROTECTED]>:


Not only is this wrong, but it completely misses the point.  Why should
Jo have to upgrade to find out if his servers will fail under the
conditions already articulated in existing, unresolved PRs that affect
hardware that he is presently using?  That's a bit like saying, "Buy
this new car.  Sure it has bugs that could easily directly affect you,
but what's the chance you'll encounter them?  in the off chance that
they do, then you can help us resolve them."


The software is Free. The car was Bought (or suggested to be bought.)

Re-visit the analogy with a free car that a friend wants to give you.
(Car analogies suck.)



Yes, they do.  It was the best I could come up with on the spur of the 
moment.





Trust me.  From a server admin's perspective, a bug affects you if it
exists in hardware you use.  Whether or not you're actually using the
OS is completely irrelevant.  Upgrading to the OS would be foolhardy.
Even testing it on a handful of boxes will not prove that it won't fail
under load in production.  Anyone who has done testing knows it can
only simulate, not duplicate, the conditions under which production
servers run.  I personally have experienced catastrophic failures after
extensive testing that revealed no problems.


You're using free software. This translates to "lots of people have
put in a lot of effort to provide something to the community which
they can use, at no cost, if it suits them."



Of course.  What it *shouldn't* translate to is STFU and eat our dog food 
or go somewhere else.




I've lectured enough.  If anyone doesn't get the point by now further
explanation isn't going to help.


I still don't think you get it. FreeBSD is a community. A community
works when enough people contribute positively towards furthering the
goals of the project. Jo is a user. He sounds like he is using it in
some reasonably critical and money-earning roles. Jo can participate
by testing stuff on test hardware, reporting back issues and working
with the community. Bitching about there being no long-term support
for releases isn't constructive. Some developer comments may not be
constructive either, but this is a -community project-. Join the
-community- and help out.



Here's a hint for you.  Jo already contributes.  So do I.  Furthermore, 
both of us deeply appreciate the work that the developers do to produce 
FreeBSD and have stated so repeatedly.



It doesn't matter if running a long-term support project would be
beneficial for a certain subset of the userbase, its a losing
situation to cater to them unless they somehow contribute back to the
community.



This is precisely the attitude that I am objecting to.  Translated for the 
average user it states, "If you're using and not contributing, then shut 
up.  You haven't earned the right to complain."


Open source projects are not free.  They cost the developers in time and 
effort.  They also cost the users in dealing with untested bugs, dealing 
with making many disparate pieces of software work together rather than 
using a fully integrated commercial package.


Open source projects also have benefits.  Developers get the benefit of a 
huge plus on their resumes.  This translates directly into increased 
income for some of them and could for all of them.  They also benefit from 
intangibles such as the pride of a job well done, the respect of their 
peers and the admiration of their users.  Users get benefits as well. 
They get to use a system that works better than many commercial products 
and has a great deal more flexibility.


But don't think for one minute that open source is free for users and only 
costs developers.


Neither "side" deserves to be insulted and talked down to.

Maybe some developers need to quit.  If the work is so difficult and 
stressful that they can't behave in a professional manner, perhaps it's an 
indication that they've overextended themselves and need to take a step 
back.  There are few that have displayed an attitude that clearly states 
that they think they are doing all the contributing and users are doing 
nothing.  Nothing could be further from the truth.


Paul Schmehl
If it isn't already obvious,
my opinions are my own and not
those of my employer.

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

[Zoran Kolic]

This thread solves nothing. Two positions are clear.
Also, I recall harder words on openbsd list, with a
lot shorter thread. The whole thing is finished and
should stay in that state. All next posts could be
written, but no need to be sent.
Best regards

Zoran

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

Re: kernel panic on em0/taskq

[Jack Vogel]

On Sat, Jun 7, 2008 at 2:34 PM, Daniel Ponticello <[EMAIL PROTECTED]> wrote:
> Hello,
> i'm experiencing periodic kernel panics on a server with  FreeBSD 7.0-STABLE
> #0: Tue May 20 19:09:43 CEST 2008.
> My big problem is that the system is not performing memory dumping and/or
> automatic reoboot,
> it just stays there.
>
> Here' console output:
>
> em0: watchdog timeout -- resetting
> kernel trap 12 with interrupts disabled
>
> Fatal trap 12: page fault while in kernel mode
> cpuid = 0; apic_id = 00
> fault virtual address   = 0x14
> fault code = supervisor read, page not present
> intruction pointerr = 0x20:0xc056e2ce
> stack pointer = 0x28:0xe537fc08
> frame pointer= 0x28:0xe537fc28
> code segment= base 0x0, limit 0xf, type 0x1b
>   = DPL 0, pres 1, def32 1, gran 1
> processor eflags = resume, IOPL = 0
> current process  = 29 (em0 taskq)
> trap number   = 12
> panic: page fault
> cpuid = 0
>
>
> It just stays there, unresponsive (no automatic reboot).
>
>
>
> Any  ideas?

There was a problem in the watchdog path, I don't recall if
it was checked in to STABLE, I will check after the weekend.

But, there is also the question of why you are in the watchdog
path in the first place.

Jack
___
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

[Freddie Cash]

On 6/7/08, Jo Rhett <[EMAIL PROTECTED]> wrote:
> The question I raised is simply: given the number of bugs opened and
> fixed since 6.3-RELEASE shipped, why is 6.3 the only supported
> version?  Why does it make sense for FreeBSD to stop supporting a
> stable version and force people to choose between two different
> unstable versions?  Is this really the right thing to do?

Define the terms "stable" and "unstable", how you measure said
"stability" and "instability", and what you are comparing them
against.

Only then can people understand what you are talking about, and can
any kind of meaningful dialog occur.

Right now, you are saying one thing, people are hearing another, and
responding with something else.

Oh, and be sure to back things up with actual data, otherwise there's
no point in going any further with this.

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