Very Computer

Dual boot system, kernels 2.2.19 and 2.4.6.  Originally Slackware 7.1.

My 2.2.19 kernel has ne2000 support built-in.  I've been using the same card
at 0x360,10 since kernel 1.3.18.  Recently I added an identical card at
0x320,12 and am using the box as a router/firewall for RoadRunner.

Works great on 2.2.19.  Used to work great on 2.0.35.  Never had any
problems.  I know I should leave well enough alone, but I figure since
"they" changed ip forwading and masqing **YET AGAIN** it must be good since
the third time is ALWAYS the charm.

Right?

It turns out 2.4.6 only supports ONE card when the driver is compiled into
the kernel (found this out the hard way - BY READING THE DOCS).  Damn shame.
I never had any luck back when modules were shiny and new, so I always
compiled ne2000 support into the kernel.  Now I have no choice (like those
poor bastard Windoze userz).

The 2.4.6 kernel will only detect the card at 0x320,12.

There is no parallel port in the system at all, so no conflict with io=0x360
(I learned that one back in 1995!).

Went through many, many newsgroup messages looking at the issue.  I have
tried many, many combinations of insmod, modprobe, /etc/modules.conf, etc.
to no avail.  It can only detect one NE2000.

Oddly enough this line:

#insmod ne io=0x320,0x360 irq=12,10

will discover eth0 at 0x320,12, while this line:

#insmod ne io=0x360,0x320 irq=10,12

will discover nothing at all.  Even if I cut the 0x320,12 card out of the
equation, this line

#insmod ne io=0x360 irq=10

fails to find the card!  It just "doesn't like" that io address.  I'd jumper
the card back to 0x300 or 0x340, but the box is buried and it's a pain to
crack the case open.  Besides, it "should" work and does... on kernel
2.2.19!

And yes, I have the "latest" (last time I checked) modutils (2.4.6).

Mr. Becker be hanged, this *is BROKE!  If anyone has a clue as to how to
hack ne.c to autprobe more than one address #ifndef MODULE, I would
appreciate a hint.

Hardware is an ancient 486DX/100.  The ISA NICs are from an obscure company
called RPT Intergoups.  They still have the "YES! It runs with NetWare!"
stickers on them.

I might be just grasping at straws....  but I think your problem is in the
ISAPNP code...

example    I had a Pbell-133  with 2 PNP soundcards (wanted both to work one
for playback of mp3 files and the second for phone messages) one and only
one for some reason was detected by the module via kernel ISAPNP the other
had to be manually configured via isapnp-tools (pnpdump/isapnp.conf) and
have its info passed manually to the sound module...

all sounds the same possibly the same fix will work for you...

            --Robert
p.s. that was long before the 2.4.6 kernel was a 2.4.2 if I remember
correctly

Quote:> Dual boot system, kernels 2.2.19 and 2.4.6.  Originally Slackware 7.1.

> My 2.2.19 kernel has ne2000 support built-in.  I've been using the same
card
> at 0x360,10 since kernel 1.3.18.  Recently I added an identical card at
> 0x320,12 and am using the box as a router/firewall for RoadRunner.

> Works great on 2.2.19.  Used to work great on 2.0.35.  Never had any
> problems.  I know I should leave well enough alone, but I figure since
> "they" changed ip forwading and masqing **YET AGAIN** it must be good
since
> the third time is ALWAYS the charm.

> Right?

> It turns out 2.4.6 only supports ONE card when the driver is compiled into
> the kernel (found this out the hard way - BY READING THE DOCS).  Damn
shame.
> I never had any luck back when modules were shiny and new, so I always
> compiled ne2000 support into the kernel.  Now I have no choice (like those
> poor bastard Windoze userz).

> The 2.4.6 kernel will only detect the card at 0x320,12.

> There is no parallel port in the system at all, so no conflict with
io=0x360
> (I learned that one back in 1995!).

> Went through many, many newsgroup messages looking at the issue.  I have
> tried many, many combinations of insmod, modprobe, /etc/modules.conf, etc.
> to no avail.  It can only detect one NE2000.

> Oddly enough this line:

> #insmod ne io=0x320,0x360 irq=12,10

> will discover eth0 at 0x320,12, while this line:

> #insmod ne io=0x360,0x320 irq=10,12

> will discover nothing at all.  Even if I cut the 0x320,12 card out of the
> equation, this line

> #insmod ne io=0x360 irq=10

> fails to find the card!  It just "doesn't like" that io address.  I'd
jumper
> the card back to 0x300 or 0x340, but the box is buried and it's a pain to
> crack the case open.  Besides, it "should" work and does... on kernel
> 2.2.19!

> And yes, I have the "latest" (last time I checked) modutils (2.4.6).

> Mr. Becker be hanged, this *is BROKE!  If anyone has a clue as to how
to
> hack ne.c to autprobe more than one address #ifndef MODULE, I would
> appreciate a hint.

> Hardware is an ancient 486DX/100.  The ISA NICs are from an obscure
company
> called RPT Intergoups.  They still have the "YES! It runs with NetWare!"
> stickers on them.

Please don't blame me for this problem.

Problems such as this one are occurring because the people changing the
code don't test before releasing the changes into the main kernel tree.
The development methodology was a "significant issue" about two years
ago, and the result was that I lost.  I now have no influence to prevent
broken changes to the netdriver API or infrastructure code.  My updates
and new drivers tend to be merged into the 2.4 kernel, but never
directly by me.

A bit of a personal flame here: Apparently I was useful when I wrote,
and more importantly supported and maintained, every significant network
driver from the beginning through 2.2 kernels.  But with the 2.3/2.4
kernel development the increased interest lead people to the conclusion
that, with enough people playing with the code, consistency, support and
an understanding were no longer critical issues.  New kernel
capabilities are nice, but we need this thing to _work_.

Bottom line: My code worked, and it would still work if I had influence,
please place the blame correctly.

--

Scyld Computing Corporation             http://www.veryComputer.com/
410 Severn Ave. Suite 210               Beowulf Clusters / Linux Installations
Annapolis MD 21403

As an ordinary Linux user, I've become increasingly worried by the 2.4
kernel. Lots and lots of things seem to be broken. I'm particularly
upset by the broken support for Promise PCI IDE controllers (probably
the biggest selling PCI controller chipset), the lack of a functioning
iBCS and the general flakiness and strange behaviour.

These changes are doing serious damage to the reputation of Linux as a
mature, stable OS. Most commercial/professional users I know are
staying with kernels around 2.2.15 and living without all the
supposedly wonderful new stuff in 2.4 (the later 2.2 kernels have lots
of broken stuff backported from 2.4).

Mr. Becker: I've used your network drivers for years. They always
worked very, very well. I'm particularly impressed by the autoprobing
of non-PnP ISA cards like (real) NE2000s.

Best regards, Paul
Paul Sherwin Consulting     22 Monmouth Road, Oxford OX1 4TD, UK
Phone  +44 (0)1865 721438   http://www.veryComputer.com/

Donald's right, the networking API was changed massively from one point
release of 2.4 to another.

Quote:> Problems such as this one are occurring because the people changing the
> code don't test before releasing the changes into the main kernel tree.
> The development methodology was a "significant issue" about two years
> ago, and the result was that I lost.

This is one reason why I advocate using distro source kernels, rather than
'standard' ones.  Any honest perusal of the change logs, of 2.4 shows a
lack of proper integration testing before release, they're not catching
show stoppers.  The download of a Linus standard from kernel.org, seems
somewhat akin to a religious showing of faith, they expect it to work, and
countless ppl are finding the same problems.  If you want to live out on
the bleeding edge like that, you really should follow the kernel list
fairly closely.

The introduction of Reiser FS into standard code, is one example.  
Unfortunately many of those who try new features are then burned by
problems, and tend to blame the newly integrated system, rather than
teething problems of the merge, and the lack of systematic testing.  This
leads to a lot of anti-Reiser comments over the net, which are really
damaging, there's enough FUD about without us generating it ourselves.

Quote:> As an ordinary Linux user, I've become increasingly worried by the 2.4
> kernel. Lots and lots of things seem to be broken. I'm particularly
> upset by the broken support for Promise PCI IDE controllers (probably
> the biggest selling PCI controller chipset), the lack of a functioning
> iBCS and the general flakiness and strange behaviour.

There are workrounds for 2.2.19 and 2.4 to have the cards recognised, based
on techniques used when ATA66/100 controllers first came out.  Promise have
drivers for Fastrak, but they would appear to have some issues, making it
impossible to include them in main kernel.  Andre Hedrik and a Promise
employee, started working to resolve issues see kt.zork.net for some of the
dicussion if you're interested.

iBCS was a Linus political decision, noone was very interested in
maintaining it and support for SCO UNIX binaries, seemed not very
important, with linux's increased market share.

Quote:> These changes are doing serious damage to the reputation of Linux as a
> mature, stable OS. Most commercial/professional users I know are
> staying with kernels around 2.2.15 and living without all the
> supposedly wonderful new stuff in 2.4 (the later 2.2 kernels have lots
> of broken stuff backported from 2.4).

Generally I think your sentiment is right, and it's something that's
bothered me.  The complexity of the kernel has increased, and I worry that
they're reaching the limits of the 'hacker' way of working, and need to be
more systematic. GCC has an extensive test suite for example.

But 2.2.19 is important for security reasons, previous kernels have a local
root exploit, and other versions 2.2.16 and on have other security issue
fixes, so using 2.2.15 is rather risky for most ppl.

Hopefully 2.4.6 will fix the VM problems, 2.5 will start, and then 2.4 will
become properly stable.  There is a huge market pressure on distributions
to ship with the latest and greatest kernels, though technically the early
2.4 kernels haven't really been the best for most users.

SGI have a project for systematic testing of the kernel, building a suite
to allow regression tests.  This effort is to be applauded, hopefully it
will become more widely used and improve quality.

Breakage and loss of data is however nothing new, I lost a lot of
filesystems, around 2.2.12 through to 2.2.14 due to I/O errors leading to
massive corruption, rather than graceful recovery.  I note even recently
that additional fixes have gone in to deal with these problems.

It's important to keep a perspective, there are many quite happily using
the newer kernels, and for many they work fine.  It is an issue however, as
many new users install Linux, then hit the problems and conclude that the
quality claims of Linux are pure hype.

Rob

Does anyone have a link to a summary of this discussion or a pointer into
key threads in a mail archive?  I'd be very interested to see the arguments
of both sides in this discussion.

Rob

Quote:

>Breakage and loss of data is however nothing new, I lost a lot of
>filesystems, around 2.2.12 through to 2.2.14 due to I/O errors leading to
>massive corruption, rather than graceful recovery.  I note even recently
>that additional fixes have gone in to deal with these problems.

>It's important to keep a perspective, there are many quite happily using
>the newer kernels, and for many they work fine.  It is an issue however, as
>many new users install Linux, then hit the problems and conclude that the
>quality claims of Linux are pure hype.

Other broken features have in the recent past included such time-
honoured favourites as umsdos and plip - these are both features have
probably lost their sex-appeal for workers at the bleeding edge, but
retain their usefulness for people eg doing low-end machine installs,
probably for the first time.

A systematic test-suite would be a good way forward for preserving the
usability of features like these.

Bob

PS - why does this thread keep reverting back to alt.os.slakware only  -
probably the sleepiest linux thread I monitor?! (and not to be confused
with alt.os.linux.slackware).

--
robert w hall

In my case it's because I failed to notice, the Newsreader auto setting a
follow-up.

Often folk get told off for cross-posts without it, even when it's a small
number of relevant groups, I don't quite understand why, as I _hate_ having
duplicate posts, as often I then read & answer the same questions in
different places.

Off to see if I've been flamed in alt.linux.slakware ;)

Rob

Quote:> As an ordinary Linux user, I've become increasingly worried by the 2.4
> kernel. Lots and lots of things seem to be broken. I'm particularly
> upset by the broken support for Promise PCI IDE controllers (probably
> the biggest selling PCI controller chipset), the lack of a functioning
> iBCS and the general flakiness and strange behaviour.

I dunno - I never trust kernels until they get out to .10 or .11.  Look
at all of the filesystem corruption bugs in the early 2.2's.  There's
alot of chaos in the L-K scene, and some really strange attitudes.

Example: ages ago, I had whipped up fragments of Rik van Riel's
out-of-memory patches to be properly functional under 2.2.x, and instead
of your memory starved linux machine locked up or worse, killing vital
system daemons (updated, kswapd, etc) at random, it would use a
heuristic to select and kill processes which would avoid killing root
processes if at all possible.  Days of stress-testing with a variety of
loads demonstrated it always killed a piggy user process or the one that
spent the longest in sleep, or in most cases, one of the spare httpd
processes (which auto-revive anyway when the # of servers gets below
MinSpares).

In short, it might not have been "elegant" (to use a Linusism), but it
kept the box from corrupting data or locking up.

Odd priorities those kernel folks have.  Since then, I've basically lost
all faith in the "Linux Kernel Development Process" and do my own tests,
validations, and patches.  

I advise all of those who require their Linux systems be reliable and
data-safe do the same.  There are some serious cowboy jockeys (Linus
included).

I used to run 2.0.36 for 200-300+ days.  I don't seem to see those kind
of uptimes anymore.  My 2.2.19 boxen seem to reboot themselves every
50-70 days or so, dunno why really.  No lockups yet...

Quote:> These changes are doing serious damage to the reputation of Linux as a
> mature, stable OS. Most commercial/professional users I know are
> staying with kernels around 2.2.15 and living without all the
> supposedly wonderful new stuff in 2.4 (the later 2.2 kernels have lots
> of broken stuff backported from 2.4).

At the very least, you should be at 2.2.16.  2.2's before then have a
fairly * CAPABILITIES bug.

As Robert Davies points out:

Quote:> SGI have a project for systematic testing of the kernel, building a suite
> to allow regression tests.  This effort is to be applauded, hopefully it
> will become more widely used and improve quality.

This is very much overdue, and will mean good things for the quality of
the kernel overall.  I still have a few jitters about 2.2 (compared to
2.0's rock-solid stability), but there's no way I'd run 2.4 now - as
much as I'd love 64 bit file sizes, better SMP locking granularity, etc.

=Rob=

--
The reply-to-address is *REAL* and will expire on 0:01 1-August-2001.
 >>  HTML emails will be bounced UNREAD.  You've been warned.  <<
 >>  Some ISPs are blacklisted due to rampant network abuse.   <<
Please review http://www.veryComputer.com/