various problems (2.2 and 2.3) and a 2.3 fat patch

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.
  Send mail to [e-mail] for more info.

---559023410-851401618-965701504=:8335
Content-Type: TEXT/PLAIN; charset=US-ASCII

I'm having a lot of different linux problems these days...

2.2.14 won't run on my 486 (dx2-66, 16 megs of ram) for any more than a
day or two before it self destructs.  I run an ftp server on it, and
uploading a large file brings it down within minutes.  Nothing in the
logs.  Once it managed to choke out a VM Killing: init message, so I went
back to 2.2.13 (the newest kernel I could find that didn't have the OOM
killer), and I can achieve 30+ day uptimes.

I would've tried 2.3.x or 2.4.xtest on it, but I need the arcnet arc0e
functionality, which doesn't seem to exist anymore.  As well, I can't find
any options (in make menuconfig) to make netfilter support DCC transfers.
(I need the ip_masq_irc kernel module for this under 2.2.13, which I'm
currently forced to use)  Is this functionality somehow provided without
special modules anymore?  I've noticed there still seems to be an ftp
module.

While trying to connect to another linux machine a few days ago, I found
that I could make a single connection, but any more connection attempts
would fail unless I waited a long time before trying again.  Unenlightened
poking about showed that my 486 (running 2.2.13, doing ip masq for a small
network) was using the same source port number for all the outgoing
connections, and the other linux machine was ignoring them until a time
limit was up.  Is this problem with the 486, or the internal machine
initiating the connection?

Also, under 2.2.13, the arc0e driver will give these:

arc1e: transmitter called with busy bit set! (status=60h, inTX=1,
ticksofar=2194)

if the other computers that are hooked up to that NIC are all turned off,
and something is sent to one of them.  When this happens, the computer
will lock up solid until another machine on that network is turned on.
(my current fix is having a second arcnet card in that machine so that
there are always two active cards on the network)

This machine has 2 3com509 network cards in it (in non plug'n'play mode),
and it's quite random what happens when I boot it - but 99% of the time
only one of the cards is detected.  The more interesting boots see both
cards as having the same interrupt.  eth= kernel command lines don't seem
to help/do anything at all.  If I load them as a module after boot time,
they usually both work - is there any way I can get these cards to work
without making the driver a module?

In another machine, a dual celeron abit-bp6, recent 2.3.x kernels seem to
dislike my realtek 8029 NIC.  (I know, it's garbage plugged in to
garbage...)  The network card will die randomly, usually when I'm sending
large amounts of data.  When it dies, there are no kernel messages, and
the interrupt count in /proc/interrupts for the card stop changing.  Minor
(painful) experimentation has shown that if the card is sharing the
interrupt with anything else (say, ide2), it takes that with it.  This
only happens in "newer" kernels, it's fine in 2.2.16, and in some earlier
2.3.x kernels.  It goes away if I boot with the noapic=1 kernel parameter,
and seems to be replaced with harmless "spurious 8259A interrupt: IRQ7."
messages.  (I haven't configured any hardware at all to be on IRQ7 -
though I'm lead to believe IRQ7 has some sort of special purpose)

Also, if I try to dd if=/dev/zero of=/vfatfs/blah on to two different
hard drives (they were both vfat fs), I get an OOPS.  Attached are the
oops (run through ksymoops), and a patch that corrects it for me, and is
probably broken and foolish.

This machine also has problems with Xfree 4.0 - it segfaults randomly
under 2.4.xtest and 2.3.x, but I've yet to see it crash under 2.2.x.  I'm
using the nvidia closed drivers, making this a fairly useless report - but
would reproducing this with the "stock" xfree nvidia drivers prove
anything, or testing with an S3 card I have lying around?

Are there any compelling reasons not to use 2.2.13? (the machine has no
untrusted users)  I've had people tell me I shouldn't use 2.2.13, but they
don't remember why.

Will arc0e be supported by 2.4.x, or am I "stuck" with 2.2.x?

Is there a serious performance hit to using noapic=1 on my dual celeron
system?

Thanks,
	Derek

Please CC any replies to me, as I am not on the list.

---559023410-851401618-965701504=:8335
Content-Type: TEXT/PLAIN; charset=US-ASCII; name=OOPS
Content-Transfer-Encoding: BASE64
Content-ID: <[e-mail]>
Content-Description: 
Content-Disposition: attachment; filename=OOPS

a3N5bW9vcHMgMi4zLjMgb24gaTY4NiAyLjQuMC10ZXN0NS4gIE9wdGlvbnMg
dXNlZA0KICAgICAtViAoZGVmYXVsdCkNCiAgICAgLWsgL3Byb2Mva3N5bXMg
KGRlZmF1bHQpDQogICAgIC1sIC9wcm9jL21vZHVsZXMgKGRlZmF1bHQpDQog
ICAgIC1vIC9saWIvbW9kdWxlcy8yLjQuMC10ZXN0NS8gKGRlZmF1bHQpDQog
ICAgIC1tIC91c3Ivc3JjL2xpbnV4L1N5c3RlbS5tYXAgKGRlZmF1bHQpDQoN
Cldhcm5pbmc6IFlvdSBkaWQgbm90IHRlbGwgbWUgd2hlcmUgdG8gZmluZCBz
eW1ib2wgaW5mb3JtYXRpb24uICBJIHdpbGwNCmFzc3VtZSB0aGF0IHRoZSBs
b2cgbWF0Y2hlcyB0aGUga2VybmVsIGFuZCBtb2R1bGVzIHRoYXQgYXJlIHJ1
bm5pbmcNCnJpZ2h0IG5vdyBhbmQgSSdsbCB1c2UgdGhlIGRlZmF1bHQgb3B0
aW9ucyBhYm92ZSBmb3Igc3ltYm9sIHJlc29sdXRpb24uDQpJZiB0aGUgY3Vy
cmVudCBrZXJuZWwgYW5kL29yIG1vZHVsZXMgZG8gbm90IG1hdGNoIHRoZSBs
b2csIHlvdSBjYW4gZ2V0DQptb3JlIGFjY3VyYXRlIG91dHB1dCBieSB0ZWxs
aW5nIG1lIHRoZSBrZXJuZWwgdmVyc2lvbiBhbmQgd2hlcmUgdG8gZmluZA0K
bWFwLCBtb2R1bGVzLCBrc3ltcyBldGMuICBrc3ltb29wcyAtaCBleHBsYWlu
cyB0aGUgb3B0aW9ucy4NCg0KdWJlcmRlaXR5On4jVW5hYmxlIHRvIGhhbmRs
ZSBrZXJuZWwgTlVMTCBwb2ludGVyIGRlcmVmZXJlbmNlIGF0IHZpcnR1YWwg
YWRkcmVzcw0KMDAwMDAwMTANCmMwMTUyYmI3DQoqcGRlID0gMDAwMDAwMDAN
Ck9vcHM6IDAwMDANCkNQVTogICAgMQ0KRUlQOiAgICAwMDEwOls8YzAxNTJi
Yjc+XQ0KVXNpbmcgZGVmYXVsdHMgZnJvbSBrc3ltb29wcyAtdCBlbGYzMi1p
Mzg2IC1hIGkzODYNCkVGTEFHUzogMDAwMTAyODMNCmVheDogMDAwMDIxMDEg
ICBlYng6IGQ3NTc2M2EwICAgZWN4OiBjMDI4MmM5YyAgIGVkeDogMDAwMDAw
MDANCmVzaTogMDAwZWJkNmEgICBlZGk6IDAwMDAwODY5ICAgZWJwOiAwMDBl
YzVkMyAgIGVzcDogZDZlOTNlMjQNCmRzOiAwMDE4ICAgZXM6IDAwMTggICBz
czogMDAxOA0KUHJvY2VzcyBkZCAocGlkOiA2OTksIHN0YWNrcGFnZT1kNmU5
MzAwMCkNClN0YWNrOiAwMDAwMDg2OSBjMTYzMzgwMCAwMDAwMDAwMCAwMDBl
YzVkMyBjMDE1NmIzNiBkNzU3NjNhMCAwMDAwMDg2OSAwMDBlYzVkMw0KICAg
ICAgIDAwMDAwMDA4IDAwMDA0MzQ4IGQ3NTc2M2EwIGMyZjJiY2UwIDAwMDAw
MDA4IDAwMGVjNWQyIGZmZmZmZmZmIGMwMTU0ODNlDQogICAgICAgZDc1NzYz
YTAgMDAwMDQzNDggZDZlOTNlYjQgMDA4NjkwMDAgMDAwMDAyMDAgYzAxMzMz
YWYgZDc1NzYzYTAgMDAwMDQzNDgNCkNhbGwgVHJhY2U6IFs8YzAxNTZiMzY+
XSBbPGMwMTU0ODNlPl0gWzxjMDEzMzNhZj5dIFs8YzAxMzI4Yjg+XSBbPGMw
MTMzOGNlPl0gWzxjMDE1NDdiND5dIFs8YzAxNTYxNWU+XQ0KICAgICAgIFs8
YzAxNTQ3YjQ+XSBbPGMwMTI5MWY4Pl0gWzxjMDE1NDhlZT5dIFs8YzAxNTQ4
YzU+XSBbPGMwMTMwZDI4Pl0gWzxjMDEwYjBlYz5dDQpDb2RlOiA4MyA3YSAx
MCAwMCA3NSBiMyAwZiBiNyA0MyAyMCA2NiA4OSAwMiBhMSA0MCAyYyAyOCBj
MCA4OSA3Mg0KDQo+PkVJUDsgYzAxNTJiYjcgPGZhdF9jYWNoZV9hZGQrNmIv
OWM+ICAgPD09PT09DQpUcmFjZTsgYzAxNTZiMzYgPGZhdF9hZGRfY2x1c3Rl
cisxYTYvMWQ4Pg0KVHJhY2U7IGMwMTU0ODNlIDxmYXRfZ2V0X2Jsb2NrKzhh
L2U0Pg0KVHJhY2U7IGMwMTMzM2FmIDxfX2Jsb2NrX3ByZXBhcmVfd3JpdGUr
ZDcvMWU4Pg0KVHJhY2U7IGMwMTMyOGI4IDxiYWxhbmNlX2RpcnR5X3N0YXRl
K2MvNGM+DQpUcmFjZTsgYzAxMzM4Y2UgPGNvbnRfcHJlcGFyZV93cml0ZSsx
N2UvMjE0Pg0KVHJhY2U7IGMwMTU0N2I0IDxmYXRfZ2V0X2Jsb2NrKzAvZTQ+
DQpUcmFjZTsgYzAxNTYxNWUgPGZhdF9wcmVwYXJlX3dyaXRlKzI2LzJjPg0K
VHJhY2U7IGMwMTU0N2I0IDxmYXRfZ2V0X2Jsb2NrKzAvZTQ+DQpUcmFjZTsg
YzAxMjkxZjggPGdlbmVyaWNfZmlsZV93cml0ZSsyOWMvM2M0Pg0KVHJhY2U7
IGMwMTU0OGVlIDxkZWZhdWx0X2ZhdF9maWxlX3dyaXRlKzIyLzU4Pg0KVHJh
Y2U7IGMwMTU0OGM1IDxmYXRfZmlsZV93cml0ZSsyZC8zND4NClRyYWNlOyBj
MDEzMGQyOCA8c3lzX3dyaXRlKzljL2IwPg0KVHJhY2U7IGMwMTBiMGVjIDxz
eXN0ZW1fY2FsbCszNC8zOD4NCkNvZGU7ICBjMDE1MmJiNyA8ZmF0X2NhY2hl
X2FkZCs2Yi85Yz4NCjAwMDAwMDAwIDxfRUlQPjoNCkNvZGU7ICBjMDE1MmJi
NyA8ZmF0X2NhY2hlX2FkZCs2Yi85Yz4gICA8PT09PT0NCiAgIDA6ICAgODMg
N2EgMTAgMDAgICAgICAgICAgICAgICBjbXBsICAgJDB4MCwweDEwKCVlZHgp
ICAgPD09PT09DQpDb2RlOyAgYzAxNTJiYmIgPGZhdF9jYWNoZV9hZGQrNmYv
OWM+DQogICA0OiAgIDc1IGIzICAgICAgICAgICAgICAgICAgICAgam5lICAg
IGZmZmZmZmI5IDxfRUlQKzB4ZmZmZmZmYjk+IGMwMTUyYjcwIDxmYXRfY2Fj
aGVfYWRkKzI0LzljPg0KQ29kZTsgIGMwMTUyYmJkIDxmYXRfY2FjaGVfYWRk
KzcxLzljPg0KICAgNjogICAwZiBiNyA0MyAyMCAgICAgICAgICAgICAgIG1v
dnp3bCAweDIwKCVlYngpLCVlYXgNCkNvZGU7ICBjMDE1MmJjMSA8ZmF0X2Nh
Y2hlX2FkZCs3NS85Yz4NCiAgIGE6ICAgNjYgODkgMDIgICAgICAgICAgICAg
ICAgICBtb3YgICAgJWF4LCglZWR4KQ0KQ29kZTsgIGMwMTUyYmM0IDxmYXRf
Y2FjaGVfYWRkKzc4LzljPg0KICAgZDogICBhMSA0MCAyYyAyOCBjMCAgICAg
ICAgICAgIG1vdiAgICAweGMwMjgyYzQwLCVlYXgNCkNvZGU7ICBjMDE1MmJj
OSA8ZmF0X2NhY2hlX2FkZCs3ZC85Yz4NCiAgMTI6ICAgODkgNzIgMDAgICAg
ICAgICAgICAgICAgICBtb3YgICAgJWVzaSwweDAoJWVkeCkNCg0KDQoxIHdh
cm5pbmcgaXNzdWVkLiAgUmVzdWx0cyBtYXkgbm90IGJlIHJlbGlhYmxlLg0K

---559023410-851401618-965701504=:8335
Content-Type: TEXT/PLAIN; charset=US-ASCII; name=fatpatch
Content-Transfer-Encoding: BASE64
Content-ID: <[e-mail]>
Content-Description: 
Content-Disposition: attachment; filename=fatpatch

LS0tIG1pc2MuYy5vcmlnCU1vbiBBdWcgIDcgMjA6NDM6MDIgMjAwMA0KKysr
IG1pc2MuYwlNb24gQXVnICA3IDIxOjEzOjMyIDIwMDANCkBAIC0xNjYsNyAr
MTY2LDYgQEANCiAJCU1TRE9TX1NCKHNiKS0+ZnJlZV9jbHVzdGVycy0tOw0K
IAlpZiAoTVNET1NfU0Ioc2IpLT5mYXRfYml0cyA9PSAzMikNCiAJCWZhdF9j
bHVzdGVyc19mbHVzaChzYik7DQotCXVubG9ja19mYXQoc2IpOw0KIAlsYXN0
ID0gMDsNCiAJLyogV2UgbXVzdCBsb2NhdGUgdGhlIGxhc3QgY2x1c3RlciBv
ZiB0aGUgZmlsZSB0byBhZGQgdGhpcw0KIAkgICBuZXcgb25lIChucikgdG8g
dGhlIGVuZCBvZiB0aGUgbGluayBsaXN0ICh0aGUgRkFUKS4NCkBAIC0xODYs
NiArMTg1LDcgQEANCiAJCQlmaWxlX2NsdXN0ZXIrKzsNCiAJCQlpZiAoIShj
dXJyID0gZmF0X2FjY2VzcyhzYiwgbGFzdCA9IGN1cnIsLTEpKSkgew0KIAkJ
CQlmYXRfZnNfcGFuaWMoc2IsIkZpbGUgd2l0aG91dCBFT0YiKTsNCisJCQkJ
dW5sb2NrX2ZhdChzYik7DQogCQkJCXJldHVybiByZXM7DQogCQkJfQ0KIAkJ
fQ0KQEAgLTE5OCw2ICsxOTgsNyBAQA0KIAl9DQogCWZhdF9jYWNoZV9hZGQo
aW5vZGUsZmlsZV9jbHVzdGVyLG5yKTsNCiAJaW5vZGUtPmlfYmxvY2tzICs9
IGNsdXN0ZXJfc2l6ZTsNCisJdW5sb2NrX2ZhdChzYik7DQogCXJldHVybiAw
Ow0KIH0NCiANCg==
---559023410-851401618-965701504=:8335--