On Mon, Dec 06, 1999 at 01:43:33PM -0800, Matthew Dillon wrote:
If we enforce a stabilizing period between .0 and .1 and branch at .1
rather then at .0, this combined with the 12 month schedule should result
in pretty damn good releases.
If we just do the 12 month schedule,
We are having a similar problem at the job I just started. A box meeting
the exact specifications that Mike said caused the problem is essentially
having the crap beat out of it as far as disk access and network activity
(it might help to also say that this company is rather large in the scheme
Andrew Reilly wrote:
On Sun, Dec 05, 1999 at 07:42:21PM -0700, Wes Peters wrote:
Software
is created by humans, and humans are fallible, therefore the software
is also fallible.
No, that doesn't logically follow. Just because it's possible
for humans to make mistakes doesn't mean
Ed Hall wrote:
: you wrote:
: : I wrote:
: :4) Using a different SCSI driver (Peter managed to get a driver from 4.0
: : hooked up under 3.3, and it survived two days of torture that would
: : have toasted things within an hour using the stock driver; you'll have
: : to ask him for
Peter Wemm writes:
In all cases the panics were extremely "strange". The original fxp+ncr
combination changed it's crash pattern when we put extra debugging in it to
sanity check and check conditions. The results varied from registers getting
clobbered (as though an interrupt
Gerard Roudier wrote:
On Tue, 7 Dec 1999, Peter Wemm wrote:
I might add that others have found that using sym + fxp on the N440BX
motherboards didn't solve their problems, or moved the problem elsewhere,
eg: to the sbdrop() etc routines. One other interesting variable.. an ahc
+
On Mon, 6 Dec 1999, Jordan K. Hubbard wrote:
Many arguments about how we were holding up progress and that
volunteers were going to start wandering off to other *BSD projects
were raised, along with more dire predictions, and finally enough was
enough and we set a date by which all the late
:
:
:[snip]
: I am a good programmer and can fix things :-). But I've had to deal with
: a number of nightmare situations by commercial entities deploying FreeBSD
: and at least three (including one very recently) where commercial entities
: have refused to upgrade past 2.2.x due to
:You write:
:: we can not identify the specific problem from this message.
:: without sufficient information to indentify and hopefully reproduce
:: the problem, we can not address it. please provide this information
:: if it is available to you. if it is not, please provide us contact
::
At 11:05 AM 12/6/99 -0800, you wrote:
:
:
:[snip]
: I am a good programmer and can fix things :-). But I've had to deal
with
: a number of nightmare situations by commercial entities deploying
FreeBSD
: and at least three (including one very recently) where commercial
entities
: have
::the problem, we can not address it. please provide this information
::if it is available to you. if it is not, please provide us contact
::information for the commercial entities experiencing the problem.
::
::jmb
:
:First, the statement was anecdotal -- all of the problems have been
:
I've confirmed that neither problem exists in 4.0. There are ample
work-arounds, both hardware and software, including just not using 3.3.
No fixes, though, just work-arounds... Workarounds for the NCR/FXP
issue included:
1) Using 2.2.8 (4.0 isn't a production option).
2) Using a different NIC
On Mon, 6 Dec 1999, Dennis wrote:
Of course moving to -current to fix the problems in 3.x introduce a whole
new set of problems, in which case you have an OS that is never going to be
stable. When 4.0 is released we'll be told that the problems of 4.0 are
fixed in -current. When does it end?
I think the solution here is to change the release mechanism slightly.
I believe we made a huge mistake splitting of the 4.x tree from 3.x
so early.
I was going to make a point about this, but thank you for making it
for me. :-)
My point was going to be that it was clearly not
:I've confirmed that neither problem exists in 4.0. There are ample
:work-arounds, both hardware and software, including just not using 3.3.
:No fixes, though, just work-arounds... Workarounds for the NCR/FXP
:issue included:
:
:1) Using 2.2.8 (4.0 isn't a production option).
:2) Using a
I've been with BSD a long time--from back when my email address was
decvax!randvax!edhall. I want it to succeed, for reasons that are more
emotional than rational; my nightmare was having to say that my project
(1) worked on Solaris, (2) worked on Linux, but (3) broke FreeBSD.
And I hope
On Mon, Dec 06, 1999 at 12:19:20PM -0800, Matthew Dillon wrote:
::the problem, we can not address it. please provide this information
::if it is available to you. if it is not, please provide us contact
::information for the commercial entities experiencing the problem.
::
::jmb
:
:
I have some remarks about the issue. I donnot claim it is not a software
problem, but ...
1) Given the actual differences between the ncr and sym drivers nowadays,
I would be surprised if the problem was due to a driver software bug.
A difference could be that recent drivers may use PCI
:I tell you, it's just not possible to win, especially when those doing
:the most yelling are always conspicuously absent when crunch time
:comes. Matt wasn't really fully on board at the time and I'm not
:pointing my finger at him specifically, but it seems like everyone's
:hindsight is 20-20
In otherwords, we should branch with the 4.1 release rather then the
4.0 release.
Sounds a lot like 3.x to me. We didn't branch at 3.0 either, we
branched one release afterwards and only after people threatened to
mutiny if we didn't since the usual pattern up to that point had been
:Well, I used to run -CURRENT in a commercial environment :-)
:
:And I got bashed here and elsewhere for doing it too.
:
:But, with the exception of some really egregious fuck-ups (on both my part
:and those of people who committed shit that didn't work AT ALL) it was, by
:far, the better option
: you wrote:
: : I wrote:
: :4) Using a different SCSI driver (Peter managed to get a driver from 4.0
: : hooked up under 3.3, and it survived two days of torture that would
: : have toasted things within an hour using the stock driver; you'll have
: : to ask him for details).
:
: Ed,
I have some remarks about the issue. I donnot claim it is not a software
problem, but ...
1) Given the actual differences between the ncr and sym drivers nowadays,
I would be surprised if the problem was due to a driver software bug.
A difference could be that recent drivers may use PCI
: In otherwords, we should branch with the 4.1 release rather then the
: 4.0 release.
:
:Sounds a lot like 3.x to me. We didn't branch at 3.0 either, we
:branched one release afterwards and only after people threatened to
:mutiny if we didn't since the usual pattern up to that point had
Regarding the PCI DMA problems and corruption, it reminds of me of a
similar PCI and DMA-related problem we had when porting OpenBSD to a
now-defunct NKK MIPS chipset. It may not be related, but here it is.
The port was up and running but under heavy load, say a compile, apps
(specifically one
On Mon, 6 Dec 1999, Parag Patel wrote:
[ ... ]
In the proecss, we discovered a very interesting thing about the
NCR/Symbios chips, at least the 810 and 825 series. Turns out that when
they are executing their scripts, and the scripts access an on-board PCI
register, that access actually
On Sun, Dec 05, 1999 at 07:42:21PM -0700, Wes Peters wrote:
Software
is created by humans, and humans are fallible, therefore the software
is also fallible.
No, that doesn't logically follow. Just because it's possible
for humans to make mistakes doesn't mean that it's impossible to
do or
[snip]
I am a good programmer and can fix things :-). But I've had to deal with
a number of nightmare situations by commercial entities deploying FreeBSD
and at least three (including one very recently) where commercial entities
have refused to upgrade past 2.2.x due to perceived
The "issue" that i first cited is that the core people in FreeBSD seemed
disinterested in 3.x soon after its release. Development on 4.0 shouldnt
even have begun until 3.x was stabilized. 3.0 wasnt ready for prime time
when it was released and the work needed to get it there hasnt been done
due
On Mon, 6 Dec 1999, Dennis wrote:
The "issue" that i first cited is that the core people in FreeBSD seemed
disinterested in 3.x soon after its release. Development on 4.0 shouldnt
even have begun until 3.x was stabilized. 3.0 wasnt ready for prime time
when it was released and the work
You write:
: we can not identify the specific problem from this message.
: without sufficient information to indentify and hopefully reproduce
: the problem, we can not address it. please provide this information
: if it is available to you. if it is not, please provide us contact
:
In message [EMAIL PROTECTED],
Matthew Dillon [EMAIL PROTECTED] wrote:
So, I think it *IS* possible to make FreeBSD sufficiently bug-free that
people become 'surprised' when they are able to crash a box running it.
FYI - Part of the reason that _I_ jumped onto the FreeBSD bandwagon
Matthew Dillon wrote:
:
:All running software has serious problems, that's why it is never considered
:done. Taking the time to enumerate specific problems that are currently
:plaguing an installation is the only way anyone can possibly hope to help.
:Problems reports of "It don't work" are
Mike,
So I'm to blame that my project schedule didn't happen to coincide
with the FreeBSD release schedule? Give me a break. The project hasn't
even gone into production yet. And I think you'll find that your apparent
assumption that no one was told about the problems is equally rash. I
At 07:49 PM 11/21/99 -0500, you wrote:
On Mon, 22 Nov 1999, Dennis wrote:
The nightmare of instability of 3.x continues whilst the braintrust flogs
away at 4.x. Its really a damn shame. And why is 3.x so much slower than
2.2.8? Will 4.0 be slower yet?
Your vagueness and lack of evidence
Dennis wrote:
At 07:49 PM 11/21/99 -0500, you wrote:
On Mon, 22 Nov 1999, Dennis wrote:
The nightmare of instability of 3.x continues whilst the braintrust flogs
away at 4.x. Its really a damn shame. And why is 3.x so much slower than
2.2.8? Will 4.0 be slower yet?
Your
On Sat, 4 Dec 1999, Dennis wrote:
At 10:28 AM 12/4/99 -0700, Wes Peters wrote:
Unless they're running your drivers. I'm perfectly willing to accept YOUR
DRIVERS might be less unstable on Linux than FreeBSD.
"less unstable". Is that a technical term?
With a large number of the systems
There was a time that when someone reported a problem there was interest in
finding out what it might be.
Bah, this is a shameless attempt to inflame emotions as a substitute
for having an actual logical point and you know it. Save it for the
presidential debates!
There is ALWAYS interest in
:
: There was a time that when someone reported a problem there was interest in
: finding out what it might be.
:
:Bah, this is a shameless attempt to inflame emotions as a substitute
:for having an actual logical point and you know it. Save it for the
:presidential debates!
:
:There is ALWAYS
:Actually, you may recall that when you first brought this up this time
:around, I (and others) _did_ try to find out what you were actually
:unhappy about.
:
:Spectators will note that you haven't actually given us anything useful
:to work with; no PR numbers, no code fragments, in fact
:Actually, you may recall that when you first brought this up this time
:around, I (and others) _did_ try to find out what you were actually
:unhappy about.
:
:Spectators will note that you haven't actually given us anything useful
:to work with; no PR numbers, no code fragments, in fact
: :There is ALWAYS interest in finding out what a problem is when it's
: :reported in such a way that the effort is worth the potential reward.
: :Having someone walk up and say, in effect, "Dudes, your system is
: :broken. Fix it!" is a content-free statement and does not qualify as
:
:
: - Dennis is a principal in a company which manufactures communications
: peripherals and writes driver software for them. It's not
: unreasonable to expect him to have some sort of idea, or access to an
: in-house idea, about how to go about diagnosing a problem like this.
: It's
Matthew Dillon wrote:
:Matt, this thread is a LOT older than Nov 20th, it runs for YEARS. Dennis
:said the same things about 2.2 vs. 2.1.5 at the very least. A few years
:later when he finally got his driver sorted out for 2.2, it became the
:best thing since sliced bread and now 3.x is
:Oh hell, how did I manage to fall into alt.philosophy.est? Wait a minute,
:this *is* freebsd-hackers. It's *you* who is off topic, and off base.
:
:As penance, you get to go read everything ever posted to a freebsd mailing
:list by JMJr.
:
:People do change, and I continually await
:
: He didn't say this until after the situation had started to degrade.
:
: Besides, he's right. 3.x has serious problems.
:
:All running software has serious problems, that's why it is never considered
:done. Taking the time to enumerate specific problems that are currently
On Sun, 21 Nov 1999, Jordan K. Hubbard wrote:
Bringing something into question without detail is useless. If I
seriously questioned your sexual orientation, for example, you'd have
every right to ask me just what the hell I was basing such a question
on and why I was uncertain about it in
In message [EMAIL PROTECTED] Ben Rosengart
writes:
: In my tests, I've found that FreeBSD is getting faster with successive
: releases -- I think because the increased weight of the extra disks helps
: overcome wind resistance.
That's just due to the beefier system requirements. of course the
At 09:15 PM 11/20/99 -0800, Mike Smith wrote:
I'll test this in 3.3 shortly...has anything been done in this area? It
seems to happen on passive backplace systems (although its more likely the
chipsets used on SBCs)...my acer MB doesnt lock up with the same test. This
problem has been
At 12:21 PM 11/21/99 -0800, you wrote:
At 09:15 PM 11/20/99 -0800, Mike Smith wrote:
I'll test this in 3.3 shortly...has anything been done in this area? It
seems to happen on passive backplace systems (although its more
likely the
chipsets used on SBCs)...my acer MB doesnt lock up with
On Mon, 22 Nov 1999, Dennis wrote:
!Its a late 3.2-STABLE. so its not that old. Surely someone knows if
!something in this area was fixed or not?
!
!Since its a DMA lockup, how would you suggest that the informatoin about
!what instruction was executing be obtained?
!
!The nightmare of
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Bosko Milekic
Sent: Sunday, November 21, 1999 5:51 PM
To: Dennis
Cc: [EMAIL PROTECTED]
Subject: Re: PCI DMA lockups in 3.2 (3.3 maybe?)
On Mon, 22 Nov 1999, Dennis wrote:
!Its a late 3.2-STABLE
Dennis has a good point.
for slower? I've ran FreeBSD for years and now I run a combo of -STABLE
and -CURRENT and you know what? It's all good! My hardware is the bottle
neck and its just as fast as 2.x was.
Do you have some numbers to back this up? (unfortunately "It's all good!"
doesn't
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Christopher Stein
Sent: Sunday, November 21, 1999 6:26 PM
To: FreeBSD
Cc: [EMAIL PROTECTED]
Subject: RE: PCI DMA lockups in 3.2 (3.3 maybe?)
Dennis has a good point.
for slower? I've ran
On Sun, 21 Nov 1999, Christopher Stein wrote:
Dennis has a good point.
Dennis has no point unless he provides some numbers to quantify his
claim.
Witness:
FreeBSD 3.X is the fastest thing I have ever seen: it's so much faster
than 2.X, I can only guess what 4.X is going to be like!
There,
On Sun, 21 Nov 1999, Kris Kennaway wrote:
On Sun, 21 Nov 1999, Christopher Stein wrote:
Dennis has a good point.
Dennis has no point unless he provides some numbers to quantify his
claim.
His point was not a claim about performance, rather he was bringing into
question whether
On Sun, 21 Nov 1999, Christopher Stein wrote:
Dennis has a good point.
Dennis has no point unless he provides some numbers to quantify his
claim.
His point was not a claim about performance, rather he was bringing into
question whether performance was improving with successive
His point was not a claim about performance, rather he was bringing into
question whether performance was improving with successive releases.
Bringing something into question without detail is useless. If I
seriously questioned your sexual orientation, for example, you'd have
every right to
His point was not a claim about performance, rather he was bringing into
question whether performance was improving with successive releases.
Sounded very much to me like he was just vaguely griping about how slow
and unstable newer versions of FreeBSD are compared to the good old days.
I've run into a situation where, with heavy PCI bus traffic, freebsd 3.2
systems lock up. I havent tried it on 3.3 yet. The same scenarios do not
cause the problem on the exact machine in both FreeBSD 2.2.8 and LINUX so
it doesnt seem to be a hardware problem.
The problem can be duplicated
I'll test this in 3.3 shortly...has anything been done in this area? It
seems to happen on passive backplace systems (although its more likely the
chipsets used on SBCs)...my acer MB doesnt lock up with the same test. This
problem has been duplicated on more than 1 system with completely
61 matches
Mail list logo
