Are we going too fast?

Are we going too fast?

[PinkFreud]

Please CC me in any replies, I am not subscribed to this list.

Please forgive me if I seem incoherent.  It's after 3:30 AM here.


I have installed various 2.4.x kernels on 3 seperate systems here.  *ALL*
of them have suffered from one malady or another - from the dual PIII with
the VIA chipset and Matrox G400 card, which locks up nicely when I switch
from X to a text console and back to X (but NOT under a uniprocessor
kernel!), to the system with the NCR 53c810 SCSI board, which suffered
random kernel panics anywhere from 2 hours to 5 days after booting, due to
the ncr53c8xx driver, to YET ANOTHER system which has shown a penchant for
crashing (read: no response on console, can use magic sysrq, but fails to
emergency sync) when attempting to use 'ls' on a mounted QNX filesystem
(ls comes up fine, then system crashes - nothing sent to syslog, no errors
on screen, nothing!) - and this latest is with 2.4.8!

I've used Linux for over 5 years now.  In all the time I've used it, I
have never seen this much instability in a single kernel
series - though I've noticed each successive 'stable' series having
more bugs than the last (2.2.x crashed once a week with SMP 
until 2.2.10!).  Furthermore, I have had a HELL of a time trying
to get responses to the first two problems (this is the first report for
the third).  It used to be that I could ask a question on this list, and
receive responses.  Not anymore.  I can't seem to get the time of day from
anyone on this list now.

This brings me to the subject of this rant: are we going too fast?  New
drivers are still showing up in each successive kernel, and yet no one
seems to be able to fix the old bugs that already exist.  Are we looking
to have the reliability of Windows?  It's starting to seem so - each
successive kernel series just seems to crash more and more often.  When
will we reach the point where Windows, on the average, will have greater
uptime than Linux systems?  Perhaps it's time to slow down, and do some
debugging.

This is supposed to be a 'stable' kernel series?  I see nothing stable
about it.

Should development continue on the latest and supposedly greatest
drivers?  Or should the existing bugs be fixed first?  I've got at least
three up there that need taking care of, and I'm sure others on this list
have found more.  3 seperate crashes on 3 seperate installs on 3 seperate
boxes - that's 100% failure rate.  If I get 100% failure on my installs,
what are others seeing?

To those of you who would tell me to fix them myself: I am an
administrator.  I know Perl.  I am not all that familiar with C, nor with
kernel programming.  They're not my bugs, but I would fix them if I were
able to.  I'd hope the authors of said bugs would be willing to fix them -
but given the track record I've seen for the first two problems, I'm not
holding my breath for the third to be fixed any time soon.

I don't know about the rest of you, but I'm going to give up soon and
switch to NetBSD.  I've already done it on the system with the NCR 53c810
board - and it's proven to be far more stable than 2.4.x kernels have ever
managed to be on it.  What does that say?

sauron@rivendell:~$ uptime
 3:17AM  up 12 days, 15:20, 2 users, load averages: 1.48, 0.66, 0.31
sauron@rivendell:~$ uname -a
NetBSD rivendell 1.5.1 NetBSD 1.5.1 (RIVENDELL) #0: Tue Jul 31 22:58:54
EDT 2001     root@rivendell:/usr/src/sys/arch/i386/compile/RIVENDELL i386
sauron@rivendell:~$ dmesg | grep -i sym
siop0 at pci0 dev 6 function 0: Symbios Logic 53c810 (fast scsi)

(The controller is old - it was made by NCR before it became Symbios Logic
- hence, why I was using the NCR driver for it, rather than the Symbios
driver, in Linux.)

Working on 13 days uptime.  That's well over twice the uptime for Linux on
that box.  That's what happens when the kernel has bugs.

Take this rant for what you will.  Personally, I switched from Windows to
Linux 5 years ago for the stability.  If I need to switch OSs again to
continue to have stability, I will.  Somehow, I suspect, if kernel
development continues down this path, many others will wind up switching
to other OSs as well.

I like Linux.  I'd like to stick with it.  But if it's going to
continually crash, I'm going to jump ship - and I'll start recommending to
others that they do the same.


	Mike Edwards

Brainbench certified Master Linux Administrator
http://www.brainbench.com/transcript.jsp?pid=158188
-----------------------------------
Unsolicited advertisments to this address are not welcome.

Re: Are we going too fast?

[Brian]

4:30am here.  I'm sure it won't seem quite as diplomatic in the morning.

Back on 2.2, up until ~.12 or so, I could hang an Intel NIC in a day and a 
half.  A 3Com or a tulip held out for three.  Considering I run web 
servers and kinda needed network access, that was a problem.  I actually 
had a burn of FreeBSD sitting on my desk when the bugs finally got swashed.

Around that time, I was in IRC with a couple of *BSDers.  One commented 
that Linux's eagarness to support anything and everything is exactly what 
made Windows the Swiss cheese we know today.  I laughed it off at the 
time, but it rang brutally true this evening.

I rolled our 2.4.7-based web server back to 2.2.19 tonight.  As if I 
needed further convincing, 2.4.7 apparently panicked on its way out (I was 
logged in from remote, but the symptoms are all too familiar).  That 
leaves our squid servers as the only 2.4-based servers left; they all run 
test12 since the 'stable' 2.4s didn't do very well at the time (of course, 
they've been up for 67-140 days, so that may not be the case anymore).

This is about what my situation was when 2.3 branched off.  I can't say I 
care for it, but at least there's precedent that the wrinkles may iron out.
	-- Brian

On Monday 13 August 2001 03:43 am, PinkFreud wrote:
> Please CC me in any replies, I am not subscribed to this list.
>
> Please forgive me if I seem incoherent.  It's after 3:30 AM here.
>
>
> I have installed various 2.4.x kernels on 3 seperate systems here. 
> *ALL* of them have suffered from one malady or another - from the dual
> PIII with the VIA chipset and Matrox G400 card, which locks up nicely
> when I switch from X to a text console and back to X (but NOT under a
> uniprocessor kernel!), to the system with the NCR 53c810 SCSI board,
> which suffered random kernel panics anywhere from 2 hours to 5 days
> after booting, due to the ncr53c8xx driver, to YET ANOTHER system which
> has shown a penchant for crashing (read: no response on console, can use
> magic sysrq, but fails to emergency sync) when attempting to use 'ls' on
> a mounted QNX filesystem (ls comes up fine, then system crashes -
> nothing sent to syslog, no errors on screen, nothing!) - and this latest
> is with 2.4.8!
>
> I've used Linux for over 5 years now.  In all the time I've used it, I
> have never seen this much instability in a single kernel
> series - though I've noticed each successive 'stable' series having
> more bugs than the last (2.2.x crashed once a week with SMP
> until 2.2.10!).  Furthermore, I have had a HELL of a time trying
> to get responses to the first two problems (this is the first report for
> the third).  It used to be that I could ask a question on this list, and
> receive responses.  Not anymore.  I can't seem to get the time of day
> from anyone on this list now.
>
> This brings me to the subject of this rant: are we going too fast?  New
> drivers are still showing up in each successive kernel, and yet no one
> seems to be able to fix the old bugs that already exist.  Are we looking
> to have the reliability of Windows?  It's starting to seem so - each
> successive kernel series just seems to crash more and more often.  When
> will we reach the point where Windows, on the average, will have greater
> uptime than Linux systems?  Perhaps it's time to slow down, and do some
> debugging.
>
> This is supposed to be a 'stable' kernel series?  I see nothing stable
> about it.
>
> Should development continue on the latest and supposedly greatest
> drivers?  Or should the existing bugs be fixed first?  I've got at least
> three up there that need taking care of, and I'm sure others on this
> list have found more.  3 seperate crashes on 3 seperate installs on 3
> seperate boxes - that's 100% failure rate.  If I get 100% failure on my
> installs, what are others seeing?
>
> To those of you who would tell me to fix them myself: I am an
> administrator.  I know Perl.  I am not all that familiar with C, nor
> with kernel programming.  They're not my bugs, but I would fix them if I
> were able to.  I'd hope the authors of said bugs would be willing to fix
> them - but given the track record I've seen for the first two problems,
> I'm not holding my breath for the third to be fixed any time soon.
>
> I don't know about the rest of you, but I'm going to give up soon and
> switch to NetBSD.  I've already done it on the system with the NCR
> 53c810 board - and it's proven to be far more stable than 2.4.x kernels
> have ever managed to be on it.  What does that say?
>
> sauron@rivendell:~$ uptime
>  3:17AM  up 12 days, 15:20, 2 users, load averages: 1.48, 0.66, 0.31
> sauron@rivendell:~$ uname -a
> NetBSD rivendell 1.5.1 NetBSD 1.5.1 (RIVENDELL) #0: Tue Jul 31 22:58:54
> EDT 2001     root@rivendell:/usr/src/sys/arch/i386/compile/RIVENDELL
> i386 sauron@rivendell:~$ dmesg | grep -i sym
> siop0 at pci0 dev 6 function 0: Symbios Logic 53c810 (fast scsi)
>
> (The controller is old - it was made by NCR before it became Symbios
> Logic - hence, why I was using the NCR driver for it, rather than the
> Symbios driver, in Linux.)
>
> Working on 13 days uptime.  That's well over twice the uptime for Linux
> on that box.  That's what happens when the kernel has bugs.
>
> Take this rant for what you will.  Personally, I switched from Windows
> to Linux 5 years ago for the stability.  If I need to switch OSs again
> to continue to have stability, I will.  Somehow, I suspect, if kernel
> development continues down this path, many others will wind up switching
> to other OSs as well.
>
> I like Linux.  I'd like to stick with it.  But if it's going to
> continually crash, I'm going to jump ship - and I'll start recommending
> to others that they do the same.
>
>
> 	Mike Edwards
>
> Brainbench certified Master Linux Administrator
> http://www.brainbench.com/transcript.jsp?pid=158188
> -----------------------------------
> Unsolicited advertisments to this address are not welcome.
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel"
> in the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: Are we going too fast?

[Francois Romieu]

PinkFreud <pf-kernel@mirkwood.net> :
[...]
> kernel!), to the system with the NCR 53c810 SCSI board, which suffered
> random kernel panics anywhere from 2 hours to 5 days after booting, due to
> the ncr53c8xx driver, to YET ANOTHER system which has shown a penchant for

The (ksymoops processed-) oopses may help. You can give a try at the
sym53c8xx driver. It performs well here:
- 53c875 adapter + BX + 2.4.3/2.4.7-ac11/2.4.8 + raid1 (small server)
- 53c810 + VP3 + 2.4.2 (instant reboot at startup with 2.4.8, I guess I
fscked some option).

[...]
> until 2.2.10!).  Furthermore, I have had a HELL of a time trying
> to get responses to the first two problems (this is the first report for
> the third).  It used to be that I could ask a question on this list, and
> receive responses.  Not anymore.  I can't seem to get the time of day from
> anyone on this list now.

Try and send specific bug-reports to the maintainers. 
l-k archives may give you some light on issues with VIA chipsets.

I'm not convinced that gaining stability on a VIA + G400 + X + smp 
combo is an easy task anyway.

-- 
Ueimor

Re: Are we going too fast?

[Gérard Roudier]

On Mon, 13 Aug 2001, PinkFreud wrote:

> Please CC me in any replies, I am not subscribed to this list.
>
> Please forgive me if I seem incoherent.  It's after 3:30 AM here.

So, you will be forgiven, otherwise ... :-)

> I have installed various 2.4.x kernels on 3 seperate systems here.  *ALL*
> of them have suffered from one malady or another - from the dual PIII with
> the VIA chipset and Matrox G400 card, which locks up nicely when I switch
> from X to a text console and back to X (but NOT under a uniprocessor
> kernel!), to the system with the NCR 53c810 SCSI board, which suffered
> random kernel panics anywhere from 2 hours to 5 days after booting, due to
> the ncr53c8xx driver, to YET ANOTHER system which has shown a penchant for
> crashing (read: no response on console, can use magic sysrq, but fails to
> emergency sync) when attempting to use 'ls' on a mounted QNX filesystem
> (ls comes up fine, then system crashes - nothing sent to syslog, no errors
> on screen, nothing!) - and this latest is with 2.4.8!

You may want to elaborate on the ncr53c8xx problems (I maintain this
driver). More generally, you must not ignore the thousands of bugs in the
hardware you are using, but software developpers haven't access to all
errata descriptions since hardware vendors donnot like to make this
information freely available.

About ncr53c8xx problem reports, I cannot reply to all of them. You may
also send them to LSILOGIC support. They also want Linux to work with the
ncr/sym/lsi/53c8xx PCI-SCSI controllers, even with old NCR ones. Some
other vendors seem to just ignore old hardwares. For example NVIDIA that
killed (bought?) 3DFX, does not seem interested in maintaining drivers for
the 3DFX graphic chips.

> I've used Linux for over 5 years now.  In all the time I've used it, I
> have never seen this much instability in a single kernel
> series - though I've noticed each successive 'stable' series having
> more bugs than the last (2.2.x crashed once a week with SMP
> until 2.2.10!).  Furthermore, I have had a HELL of a time trying
> to get responses to the first two problems (this is the first report for
> the third).  It used to be that I could ask a question on this list, and
> receive responses.  Not anymore.  I can't seem to get the time of day from
> anyone on this list now.

I use Linux since some 0.99.x (was yygdrasil distribution). My experience
has been that 1.2.13, 2.0.27 and 2.2.13 worked reliable enough for me.
'Stable' does not means reliable for any workload. It means that we stop
developping (implies changing large portions of code or modifying
interfaces) but only focus on fixing the software with it current design
(implies only changing what is proven to be broken).  This applies to all
softwares, not only to Linux. As a result, early stable releases still
have numerous bugs that may prevent numerous systems from working
reliably. It is up to user to check releases and switch to the one that
fits his expectations.

> This brings me to the subject of this rant: are we going too fast?  New
> drivers are still showing up in each successive kernel, and yet no one
> seems to be able to fix the old bugs that already exist.  Are we looking
> to have the reliability of Windows?  It's starting to seem so - each
> successive kernel series just seems to crash more and more often.  When
> will we reach the point where Windows, on the average, will have greater
> uptime than Linux systems?  Perhaps it's time to slow down, and do some
> debugging.

The reliabity of Windows seems to be just fine for most users since it is
the O/S most of them want to use.:-)
I use Win98/SE, Win/NT 4.0, Linux-2.2.19, FreeBSD-4.2, and sometimes
NetBSD-1.5 on my personnal machine. They all work reliably enough for my
personnal usage. But, indeed, this is a station and not a server, even if
I use to sometimes stress the system under Linux and *BSDs.

> This is supposed to be a 'stable' kernel series?  I see nothing stable
> about it.
>
> Should development continue on the latest and supposedly greatest
> drivers?  Or should the existing bugs be fixed first?  I've got at least
> three up there that need taking care of, and I'm sure others on this list
> have found more.  3 seperate crashes on 3 seperate installs on 3 seperate
> boxes - that's 100% failure rate.  If I get 100% failure on my installs,
> what are others seeing?

Hopefully you aren't a typical computer user or you just have bad luck
with computers. :-)

> To those of you who would tell me to fix them myself: I am an
> administrator.  I know Perl.  I am not all that familiar with C, nor with
> kernel programming.  They're not my bugs, but I would fix them if I were
> able to.  I'd hope the authors of said bugs would be willing to fix them -
> but given the track record I've seen for the first two problems, I'm not
> holding my breath for the third to be fixed any time soon.

All software developpers and maintainers want their software to work and
thus bugs to be fixed. This is just sometimes hard to know what is
actually broken. My experience is that no more than 10% bug reports about
a software are due to a bug in the software that is pointed out by the
report. And for these less than 10% relevant reports, maintainers must
find what is broken... not simple as you can imagine...

> I don't know about the rest of you, but I'm going to give up soon and
> switch to NetBSD.  I've already done it on the system with the NCR 53c810
> board - and it's proven to be far more stable than 2.4.x kernels have ever
> managed to be on it.  What does that say?

You can break any O/S given an appropriate workload. Add to this all the
hidden/unknown hardware bugs that can be randomly triggerred ...

Btw, I use SYM-2 driver under Linux, FreeBSD and NetBSD 1.5. I have no
problem with it. If you plan to use Ultra-160 LSI53C1010 chips, the NetBSD
SIOP driver may be sub-optimal and, btw, it does not seem to know about
C1010 chips erratas.

You donnot seem to have given a try with FreeBSD. Were there some strong
reasons for that ?

> sauron@rivendell:~$ uptime
>  3:17AM  up 12 days, 15:20, 2 users, load averages: 1.48, 0.66, 0.31
> sauron@rivendell:~$ uname -a
> NetBSD rivendell 1.5.1 NetBSD 1.5.1 (RIVENDELL) #0: Tue Jul 31 22:58:54
> EDT 2001     root@rivendell:/usr/src/sys/arch/i386/compile/RIVENDELL i386
> sauron@rivendell:~$ dmesg | grep -i sym
> siop0 at pci0 dev 6 function 0: Symbios Logic 53c810 (fast scsi)
>
> (The controller is old - it was made by NCR before it became Symbios Logic
> - hence, why I was using the NCR driver for it, rather than the Symbios
> driver, in Linux.)
>
> Working on 13 days uptime.  That's well over twice the uptime for Linux on
> that box.  That's what happens when the kernel has bugs.

You seem so sure it is the ncr53c8xx driver that breaks your Linux ...
If it was so broken, may be I would have heared about. :-)

> Take this rant for what you will.  Personally, I switched from Windows to
> Linux 5 years ago for the stability.  If I need to switch OSs again to
> continue to have stability, I will.  Somehow, I suspect, if kernel
> development continues down this path, many others will wind up switching
> to other OSs as well.

If NetBSD fits your need, then let me encourage you to use it.

> I like Linux.  I'd like to stick with it.  But if it's going to
> continually crash, I'm going to jump ship - and I'll start recommending to
> others that they do the same.

That's unclever recommendation, in my opinion.
For example, my children are happy using Windows 98 and I donnot want to
recommend them anything else.

> 	Mike Edwards
>
> Brainbench certified Master Linux Administrator
> http://www.brainbench.com/transcript.jsp?pid=158188
> -----------------------------------
> Unsolicited advertisments to this address are not welcome.

Regards,
  Gérard.

Re: Are we going too fast?

[Chris Wilson]

> > until 2.2.10!).  Furthermore, I have had a HELL of a time trying
> > to get responses to the first two problems (this is the first report
for
> > the third).  It used to be that I could ask a question on this list,
and
> > receive responses.  Not anymore.  I can't seem to get the time of day
from
> > anyone on this list now.
> 
> Try and send specific bug-reports to the maintainers. 
> l-k archives may give you some light on issues with VIA chipsets.
> 
> I'm not convinced that gaining stability on a VIA + G400 + X + smp 
> combo is an easy task anyway.

Certainly seems to be moving backwards in that respect - from 2.4.6
onwards the bog standard PS/2 keyboard does not work (at all from bootup -
"keyboard: Timeout - AT keyboard not present?(ed)") on my SMP VIA w. G400
(although I've not got as far as loading X on it without the keyboard!) :(

I can't even see what's changed in 2.4.6 that might cause this - soft_irq?
or is that completely unrelated to the keyboard???


Chris

Re: Are we going too fast?

[Justin Guyett]

On Mon, 13 Aug 2001, Gérard Roudier wrote:

> You may want to elaborate on the ncr53c8xx problems (I maintain this
> driver). More generally, you must not ignore the thousands of bugs in the
> hardware you are using, but software developpers haven't access to all
> errata descriptions since hardware vendors donnot like to make this
> information freely available.

I've got a quick unrelated question.

Why not change the name (or at least the description) of sym53c8xx to
include the 53c1010 chips, which this driver seems to work on (and on a
SMP box, no less)?


justin

Re: Are we going too fast?

[szonyi calin]

--- Chris Wilson <jakdaw@lists.jakdaw.org> wrote:

> Certainly seems to be moving backwards in that
> respect - from 2.4.6
> onwards the bog standard PS/2 keyboard does not work
> (at all from bootup -
> "keyboard: Timeout - AT keyboard not present?(ed)")
> on my SMP VIA w. G400
> (although I've not got as far as loading X on it
> without the keyboard!) :(
> 
> I can't even see what's changed in 2.4.6 that might
> cause this - soft_irq?
> or is that completely unrelated to the keyboard???
> 
> 
> Chris
> -

I have too a PS/2 keyboard and no problem at all with
2.4.x kernels. 2.4.0-2.4.8
Cx486 UP 


__________________________________________________
Do You Yahoo!?
Send instant messages & get email alerts with Yahoo! Messenger.
http://im.yahoo.com/

Re: Are we going too fast?

[Andrzej Krzysztofowicz]

"Justin Guyett wrote:"
> Why not change the name (or at least the description) of sym53c8xx to
> include the 53c1010 chips, which this driver seems to work on (and on a
> SMP box, no less)?

For backward compatibility reasons ?
We are in a stable kernels series.

-- 
=======================================================================
  Andrzej M. Krzysztofowicz               ankry@mif.pg.gda.pl
  phone (48)(58) 347 14 61
Faculty of Applied Phys. & Math.,   Technical University of Gdansk

Re: Are we going too fast?

[Alan Cox]

> of them have suffered from one malady or another - from the dual PIII with
> the VIA chipset and Matrox G400 card, which locks up nicely when I switch

Welcome to wacky hardware. To get a G400 stable on x86 you need at least

XFree86 4.1 if you are running hardware 3D (and DRM 4.1)
2.4.8 or higher with the VIA fixes
Preferably a very recent BIOS update for the VIA box

Of those only the XFree hardware 3d stuff is software bug related.

> emergency sync) when attempting to use 'ls' on a mounted QNX filesystem
> (ls comes up fine, then system crashes - nothing sent to syslog, no errors
> on screen, nothing!) - and this latest is with 2.4.8!

The qnxfs code is experimental - so I can believe it might fail in 2.4. I'd
be very interested in info on that one.

> Should development continue on the latest and supposedly greatest
> drivers?  Or should the existing bugs be fixed first?  I've got at least
> three up there that need taking care of, and I'm sure others on this list
> have found more.  3 seperate crashes on 3 seperate installs on 3 seperate
> boxes - that's 100% failure rate.  If I get 100% failure on my installs,
> what are others seeing?

Near enough 0%. But then I try and avoid buying broken chipsets.

> I like Linux.  I'd like to stick with it.  But if it's going to
> continually crash, I'm going to jump ship - and I'll start recommending to

If you want maximum stability you want to be running 2.2 or even 2.0. Newer
less tested code is always less table. 2.4 wont be as stable as 2.2 for a
year yet.

Alan

Re: Are we going too fast?

[hugang]

On Mon, 13 Aug 2001 03:43:05 -0400 (EDT)
PinkFreud <pf-kernel@mirkwood.net> wrote:

> 
> I have installed various 2.4.x kernels on 3 seperate systems here.  *ALL*
> of them have suffered from one malady or another - from the dual PIII with
> the VIA chipset and Matrox G400 card, which locks up nicely when I switch
> from X to a text console and back to X (but NOT under a uniprocessor
> kernel!), to the system with the NCR 53c810 SCSI board, which suffered
> random kernel panics anywhere from 2 hours to 5 days after booting, due to
> the ncr53c8xx driver, to YET ANOTHER system which has shown a penchant for
> crashing (read: no response on console, can use magic sysrq, but fails to
> emergency sync) when attempting to use 'ls' on a mounted QNX filesystem
> (ls comes up fine, then system crashes - nothing sent to syslog, no errors
> on screen, nothing!) - and this latest is with 2.4.8!
> 

> sauron@rivendell:~$ uptime
>  3:17AM  up 12 days, 15:20, 2 users, load averages: 1.48, 0.66, 0.31
> sauron@rivendell:~$ uname -a
> NetBSD rivendell 1.5.1 NetBSD 1.5.1 (RIVENDELL) #0: Tue Jul 31 22:58:54
> EDT 2001     root@rivendell:/usr/src/sys/arch/i386/compile/RIVENDELL i386
> sauron@rivendell:~$ dmesg | grep -i sym
> siop0 at pci0 dev 6 function 0: Symbios Logic 53c810 (fast scsi)
> 
> (The controller is old - it was made by NCR before it became Symbios Logic
> - hence, why I was using the NCR driver for it, rather than the Symbios
> driver, in Linux.)
> 
> Working on 13 days uptime.  That's well over twice the uptime for Linux on
> that box.  That's what happens when the kernel has bugs.
> 
> Take this rant for what you will.  Personally, I switched from Windows to
> Linux 5 years ago for the stability.  If I need to switch OSs again to
> continue to have stability, I will.  Somehow, I suspect, if kernel
> development continues down this path, many others will wind up switching
> to other OSs as well.
> 

	I think this problem can fix if your can report the crash message . (Oops,...)
Beacuse the netbsd can work fine on it , So I true the linux kernel also can  work fine on it.

-- 
Best Regard!
礼！
----------------------------------------------------
hugang : 胡刚 	GNU/Linux User
email  : gang_hu@soul.com.cn linuxbest@soul.com.cn
Tel    : +861068425741/2/3/4
Web    : http://www.soul.com.cn

	Beijing Soul technology Co.Ltd.
	   北京众志和达科技有限公司
----------------------------------------------------

Re: Are we going too fast?

[Anton Altaparmakov]

At 14:11 13/08/01, Alan Cox wrote:
> > Should development continue on the latest and supposedly greatest
> > drivers?  Or should the existing bugs be fixed first?  I've got at least
> > three up there that need taking care of, and I'm sure others on this list
> > have found more.  3 seperate crashes on 3 seperate installs on 3 seperate
> > boxes - that's 100% failure rate.  If I get 100% failure on my installs,
> > what are others seeing?
>
>Near enough 0%. But then I try and avoid buying broken chipsets.

0% here. Admittedly I have only one VIA box and only as of this weekend but 
it works great with all kernels tried. [Epox 8KTA3 mobo, KT133A chipset 
running 266MHz FSB and 1.33GHz Athlon Thunderbird, PC133 CL2 RAM from 
Micron, active PFC power supply, BIOS setup to the fastest settings it 
allows me to set it to while stayin in spec (i.e. no o/c of CPU or 
busses!), IBM Ericson ATA100 41GiB HD attached to the VIA controller].

Tried kernels are 2.4.4-4GB (from SuSE 7.1 binary install Pentium 
optimizations I believe), 2.4.8 and 2.4.8-ac1 (the latter two both compiled 
with Athlon optimizations) and the system is absolutely fine. bonnie 
scores >30MiB/s (in mostly 34-39 MiB/s) on intelligent read/write tests 
with DMA enabled and a working set 2x size of RAM (i.e. 512MiB test size on 
256MiB RAM). Even when using fsync after every operation i/o speed is 
almost unaffected (it drops a bit but only by about 1-2MiB/s).

Copying 15 GiB of data from one partition to the other on the same disk 
worked fine. Compiling kernels works fine (Admittedly it only takes just 
over 3 minutes to compile the kernel with make -j 2 bzImage, so it's not 
too much of a stress test).

Oh and the VIA AC97 audio codec seems to work beautifully, too. As does X 
(both 3.3.x and 4.0.3) is fine, too. (I use an ancient ET6000 PCI gfx card.)

So, basically no problems here. I was quite worried about buying a VIA 
chipset but now it seems like a great buy. (-:

The only thing that's slightly annoying is that during boot three of the 
PCI resources from the VIA chipset are reported as "unknown, treating 
transparently" (or some simillar msg), don't have box handy to say what 
they were exactly... if anyone is intersted in exact messages I can provide 
dmesg + lspci -vvv output once I get home tonight.

> > I like Linux.  I'd like to stick with it.  But if it's going to
> > continually crash, I'm going to jump ship - and I'll start recommending to
>
>If you want maximum stability you want to be running 2.2 or even 2.0. Newer
>less tested code is always less table. 2.4 wont be as stable as 2.2 for a
>year yet.

Or alternatively buy quality components that other people have tested under 
Linux with kernel 2.4...

Anton


-- 
   "Nothing succeeds like success." - Alexandre Dumas
-- 
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Linux NTFS Maintainer / WWW: http://linux-ntfs.sf.net/
ICQ: 8561279 / WWW: http://www-stu.christs.cam.ac.uk/~aia21/

Re: Are we going too fast?

[Gérard Roudier]

On Mon, 13 Aug 2001, Justin Guyett wrote:

> On Mon, 13 Aug 2001, Gérard Roudier wrote:
>
> > You may want to elaborate on the ncr53c8xx problems (I maintain this
> > driver). More generally, you must not ignore the thousands of bugs in the
> > hardware you are using, but software developpers haven't access to all
> > errata descriptions since hardware vendors donnot like to make this
> > information freely available.
>
> I've got a quick unrelated question.
>
> Why not change the name (or at least the description) of sym53c8xx to
> include the 53c1010 chips, which this driver seems to work on (and on a
> SMP box, no less)?

I have an SMP box and a C1010 chip. I like the 'way' this hardware
combination 'seems' to work for me. :-)

About the driver name, I have changed it to just 'sym' for the port to
FreeBSD. Software modules are usually named using a short name under this
O/S. At the time I did the port, LSI had bought SYMBIOS, but they seemed
to want to keep with SYMBIOS name for the 53C8XX PCI-SCSI family.

Then they (LSI) invented the 53C1010, called it LSI53C1010 and designed it
in a way that made possible to use a single driver for the SYM53C8xx
series (NCR+SYMBIOS) and this one.

The current LSI53C10xx family consists in 2 different architectures that
require 2 different software drivers:

- [PCI host interface + SCSI Ultra-160 interface + SCSI scripts
  processor] that are supported by the sym53c8xx driver, the
  derivated 'sym' under FreeBSD and the latest SYM-2 (derived from sym)
  that wants to be portable.

- [PCI/X host interface + SCSI Ultra-320 interface + ARM based IO
  processor] that requires a new driver. I heared that LSILOGIC want to
  provide a driver for Linux. Note that the LSI FC controllers and those
  ones should possibly share the same software drivers.

Then, what better name for the sym53c8xx driver?

- sym has been obsoleted by lsi.
- sym53c8,10xx is confusing, given the 10xx family weirdness (see above).
- lsi is too vague a name, given the numerous chips supplied by LSI.
- siop (SCSI IO PROCESSOR) is already used and looks to me more vague
  than all other names that have ever been used for an HBA driver.:)

In my taste, sym53c8xx is still quite good name for the following reasons:

1) It is the SYMBIOS company that made the greatest development for the
   53C8XX family, in my opinion.
2) The 53C10xx chips that can be driven by the sym* drivers use a 53C1010
   core, even if then may be named 53C1000, etc..., for marketing reasons.
3) All future 53C10xx HBAs will probably be based on PCI/X + U320 + ARM
   and so will not be supported by sym* (same for SIOP, btw).

Now, we could change everything that wants to describe this driver.
Here is my current one (from sym-2 that also supports NCR53C8xx chips):

 * Device driver for the SYMBIOS/LSILOGIC 53C8XX and 53C1010 family
 * of PCI-SCSI IO processors.

Just my 0.02 euro. :)

  Gérard.

Re: Are we going too fast?

[Stephen Satchell]

At 02:11 PM 8/13/01 +0100, Alan Cox wrote:
> > Should development continue on the latest and supposedly greatest
> > drivers?  Or should the existing bugs be fixed first?  I've got at least
> > three up there that need taking care of, and I'm sure others on this list
> > have found more.  3 seperate crashes on 3 seperate installs on 3 seperate
> > boxes - that's 100% failure rate.  If I get 100% failure on my installs,
> > what are others seeing?
>
>Near enough 0%. But then I try and avoid buying broken chipsets.

Back in the old 2.0 days there was a couple of HOWTOs that discussed what 
hardware worked and didn't work under Linux.  I remember using the 
Ethernet-HOWTO as a "shopping list" when going to ham fests, "Wierd Stuff", 
and similar consignment/surplus/boneyard houses.  Have these HOWTOs been 
maintained?

(I've noticed that a number of very, very useful HOWTOs have fallen into 
the "unmaintained" category.)

I happen to think that "stories around the campfire" are fine, but with an 
OS like Linux we should have the "Campfire FAQ"...  :)

Satch

A warning (was: Re: Are we going too fast?)

[Nico Schottelius]

One last word to this email:

- Linux is kind of stable for _normal_ use
- PinkFreud did actually warn us. It is important to
include latest hardware support into the kernel, but we
should always aim to have a stable Linux.

So all guys herein do the best work they can do and I am
impressed everyday, what a great OS Linux was, is and will be.

Have a nice day,

Nico

Re: Are we going too fast?

[Pete Toscano]

I'm running a SMP (2xPIII 600) on a Tyan Tiger mobo (Via Apollo Pro 133a
chipset) with a G400 and it runs fine, when I do the following:

	- disable APIC ("noapic" as a boot parameter).  Then again, the
	  system won't boot without APIC disabled.
	- use the ALSA drivers for my SoundBlaster Live.  (I haven't
	  tried the kernel-based drivers for a few version now, so this
	  situation might have changes, but up until I switched to ALSA,
	  I had crashes all the time during medium to high I/O.
	- use the uhci USB driver when I'm using a USB printer.  If I
	  use the usb-uhci driver with my USB printer, the whole system
	  locks.  This has been reported a few times on LKML,
	  linux-usb-users, and linux-usb-developers and nobody helped,
	  but a few people wrote back with "me too"s.  It was broken in
	  the trasnition from 2.4.3 to 2.4.4 and only seems to affect
	  SMP systems.  I just gave up on USB printing and went back to
	  my parallel port.

Finally, I'm using RedHat 7.1.  This system has no stability problems
now (after a long series of all kinds of stability problems).  Maybe
it's a load thing, I don't know, but it now runs stable.  

pete

On Mon, 13 Aug 2001, Francois Romieu wrote:

> I'm not convinced that gaining stability on a VIA + G400 + X + smp 
> combo is an easy task anyway.

Re: Are we going too fast?

[Alan Cox]

> 	- use the uhci USB driver when I'm using a USB printer.  If I
> 	  use the usb-uhci driver with my USB printer, the whole system
> 	  locks.  This has been reported a few times on LKML,
> 	  linux-usb-users, and linux-usb-developers and nobody helped,
> 	  but a few people wrote back with "me too"s.  It was broken in
> 	  the trasnition from 2.4.3 to 2.4.4 and only seems to affect
> 	  SMP systems.  I just gave up on USB printing and went back to
> 	  my parallel port.

usb-uhci seems to not be SMP safe. Ultimately we don't need both uhci
drivers so that hasnt been one that worried me.  Probably we should drop
the other uhci driver over time (2.5 maybe)

Alan

usb-uhci + SMP -> bad

[Andre Pang]

On Tue, Aug 14, 2001 at 01:48:06PM +0100, Alan Cox wrote:

> > 	- use the uhci USB driver when I'm using a USB printer.  If I
> > 	  use the usb-uhci driver with my USB printer, the whole system
> > 	  locks.  This has been reported a few times on LKML,
> > 	  linux-usb-users, and linux-usb-developers and nobody helped,
> > 	  but a few people wrote back with "me too"s.  It was broken in
> > 	  the trasnition from 2.4.3 to 2.4.4 and only seems to affect
> > 	  SMP systems.  I just gave up on USB printing and went back to
> > 	  my parallel port.
> 
> usb-uhci seems to not be SMP safe. Ultimately we don't need both uhci
> drivers so that hasnt been one that worried me.  Probably we should drop
> the other uhci driver over time (2.5 maybe)

i'd just thought i'd verify that usb-uchi seems to be causing
some havoc on SMP boxes.

i've had complete crashes (Alt-SysRq-s doesn't respond) when i
try to print stuff to a USB printer using the usb-uchi and
printer modules.  this is on an SMP box.

however -- 2.4.2 works perfectly for that.  it broke from 2.4.4
onward (tried 2.4.[5-7], i'm presuming .8 hasn't fixed the
problem.)

if anybody wants me to help them diagnose the problem, i'd be
more than happy to, but i'm not sure where to start at the
moment.


-- 
#ozone/algorithm <ozone@algorithm.com.au>          - trust.in.love.to.save

Re: usb-uhci + SMP -> bad

[Russell Cattelan]

Andre Pang wrote:

>On Tue, Aug 14, 2001 at 01:48:06PM +0100, Alan Cox wrote:
>
>>>	- use the uhci USB driver when I'm using a USB printer.  If I
>>>	  use the usb-uhci driver with my USB printer, the whole system
>>>	  locks.  This has been reported a few times on LKML,
>>>	  linux-usb-users, and linux-usb-developers and nobody helped,
>>>	  but a few people wrote back with "me too"s.  It was broken in
>>>	  the trasnition from 2.4.3 to 2.4.4 and only seems to affect
>>>	  SMP systems.  I just gave up on USB printing and went back to
>>>	  my parallel port.
>>>
>>usb-uhci seems to not be SMP safe. Ultimately we don't need both uhci
>>drivers so that hasnt been one that worried me.  Probably we should drop
>>the other uhci driver over time (2.5 maybe)
>>
>
>i'd just thought i'd verify that usb-uchi seems to be causing
>some havoc on SMP boxes.
>
>i've had complete crashes (Alt-SysRq-s doesn't respond) when i
>try to print stuff to a USB printer using the usb-uchi and
>printer modules.  this is on an SMP box.
>
>however -- 2.4.2 works perfectly for that.  it broke from 2.4.4
>onward (tried 2.4.[5-7], i'm presuming .8 hasn't fixed the
>problem.)
>
>if anybody wants me to help them diagnose the problem, i'd be
>more than happy to, but i'm not sure where to start at the
>moment.
>

Note the usb sound driver does that same thing even on a UP box (with 
SMP kernel and UP kernel)

I've tried to debug the problem but setting nmi_watchdog=1 at boot time 
does seem
to catch the problem so I don't have much to go on.

If you haven't set nmi_watchdog yet you may want to try it and see if 
you have
better luck.

And yes comfirmed 2.4.3 works 2.4.[45678] does not.


-Russell Cattelan

Re: Are we going too fast?

[Anders Larsen]

On 2001-08-13 15:11 Alan Cox wrote:
> > emergency sync) when attempting to use 'ls' on a mounted QNX filesystem
> > (ls comes up fine, then system crashes - nothing sent to syslog, no errors
> > on screen, nothing!) - and this latest is with 2.4.8!
> 
> The qnxfs code is experimental - so I can believe it might fail in 2.4. I'd
> be very interested in info on that one.

The qnxfs code is really quite stable - that's the first time in more than a
year that I hear of any problem reading a qnx file-system; actually, I've been
considering removing the 'experimental' tag, but now I'll reconsider...

Incidentally, I use the qnxfs in a production environment here (tried'em all
up to 2.4.7 - guess I'll better switch to 2.4.8 right now to check, although
the qnxfs code has not changed from 2.4.7)

I'll be very interested in hearing what you find out.

cheers
  Anders (maintainer, qnx4fs)
-- 
"In theory there is no difference between theory and practice.
 In practice there is." - Yogi Berra

Re: Are we going too fast?

[Anders Larsen]

Anders Larsen wrote:
> 
> On 2001-08-13 15:11 Alan Cox wrote:
> > > emergency sync) when attempting to use 'ls' on a mounted QNX filesystem
> > > (ls comes up fine, then system crashes - nothing sent to syslog, no errors
> > > on screen, nothing!) - and this latest is with 2.4.8!
> >
> > The qnxfs code is experimental - so I can believe it might fail in 2.4. I'd
> > be very interested in info on that one.
> 
> The qnxfs code is really quite stable - that's the first time in more than a
> year that I hear of any problem reading a qnx file-system; actually, I've been
> considering removing the 'experimental' tag, but now I'll reconsider...

Come to think of it...
Mike didn't mention any details of the hardware where he's experiencing this
bug, but is it possibly a multiprocessor machine?
Since I only have UP's to test on, the qnxfs might have SMP issues.

Could someone please glance through the code in fs/qnx4 to check if there
are any obvious problems?

cheers
  Anders (maintainer, qnx4fs)
-- 
"In theory there is no difference between theory and practice.
 In practice there is." - Yogi Berra

Re: Are we going too fast?

[Paul G. Allen]

Alan Cox wrote:
> 
> >       - use the uhci USB driver when I'm using a USB printer.  If I
> >         use the usb-uhci driver with my USB printer, the whole system
> >         locks.  This has been reported a few times on LKML,
> >         linux-usb-users, and linux-usb-developers and nobody helped,
> >         but a few people wrote back with "me too"s.  It was broken in
> >         the trasnition from 2.4.3 to 2.4.4 and only seems to affect
> >         SMP systems.  I just gave up on USB printing and went back to
> >         my parallel port.
> 
> usb-uhci seems to not be SMP safe. Ultimately we don't need both uhci
> drivers so that hasnt been one that worried me.  Probably we should drop
> the other uhci driver over time (2.5 maybe)
> 

When I first installed RH 7.1 on my Tyan K7, the system would lock upon boot when the USB module was loaded. I disabled the USB controller in the BIOS and all
was fine. After compiling 2.4.7-ac10 and running it for some time reliably, I re-enabled USB and re-compiled making sure the USB modules were included. They now
load just fine.

Note that I do not (yet) have any USB devices.

PGA
-- 
Paul G. Allen
UNIX Admin II/Programmer
Akamai Technologies, Inc.
www.akamai.com
Work: (858)909-3630
Cell: (858)395-5043