lkml.org 
[lkml]   [2000]   [Aug]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patch in this message
/
Date
From
Subjectvarious problems (2.2 and 2.3) and a 2.3 fat patch
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.
ksymoops 2.3.3 on i686 2.4.0-test5. Options used
-V (default)
-k /proc/ksyms (default)
-l /proc/modules (default)
-o /lib/modules/2.4.0-test5/ (default)
-m /usr/src/linux/System.map (default)

Warning: You did not tell me where to find symbol information. I will
assume that the log matches the kernel and modules that are running
right now and I'll use the default options above for symbol resolution.
If the current kernel and/or modules do not match the log, you can get
more accurate output by telling me the kernel version and where to find
map, modules, ksyms etc. ksymoops -h explains the options.

uberdeity:~#Unable to handle kernel NULL pointer dereference at virtual address
00000010
c0152bb7
*pde = 00000000
Oops: 0000
CPU: 1
EIP: 0010:[<c0152bb7>]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010283
eax: 00002101 ebx: d75763a0 ecx: c0282c9c edx: 00000000
esi: 000ebd6a edi: 00000869 ebp: 000ec5d3 esp: d6e93e24
ds: 0018 es: 0018 ss: 0018
Process dd (pid: 699, stackpage=d6e93000)
Stack: 00000869 c1633800 00000000 000ec5d3 c0156b36 d75763a0 00000869 000ec5d3
00000008 00004348 d75763a0 c2f2bce0 00000008 000ec5d2 ffffffff c015483e
d75763a0 00004348 d6e93eb4 00869000 00000200 c01333af d75763a0 00004348
Call Trace: [<c0156b36>] [<c015483e>] [<c01333af>] [<c01328b8>] [<c01338ce>] [<c01547b4>] [<c015615e>]
[<c01547b4>] [<c01291f8>] [<c01548ee>] [<c01548c5>] [<c0130d28>] [<c010b0ec>]
Code: 83 7a 10 00 75 b3 0f b7 43 20 66 89 02 a1 40 2c 28 c0 89 72

>>EIP; c0152bb7 <fat_cache_add+6b/9c> <=====
Trace; c0156b36 <fat_add_cluster+1a6/1d8>
Trace; c015483e <fat_get_block+8a/e4>
Trace; c01333af <__block_prepare_write+d7/1e8>
Trace; c01328b8 <balance_dirty_state+c/4c>
Trace; c01338ce <cont_prepare_write+17e/214>
Trace; c01547b4 <fat_get_block+0/e4>
Trace; c015615e <fat_prepare_write+26/2c>
Trace; c01547b4 <fat_get_block+0/e4>
Trace; c01291f8 <generic_file_write+29c/3c4>
Trace; c01548ee <default_fat_file_write+22/58>
Trace; c01548c5 <fat_file_write+2d/34>
Trace; c0130d28 <sys_write+9c/b0>
Trace; c010b0ec <system_call+34/38>
Code; c0152bb7 <fat_cache_add+6b/9c>
00000000 <_EIP>:
Code; c0152bb7 <fat_cache_add+6b/9c> <=====
0: 83 7a 10 00 cmpl $0x0,0x10(%edx) <=====
Code; c0152bbb <fat_cache_add+6f/9c>
4: 75 b3 jne ffffffb9 <_EIP+0xffffffb9> c0152b70 <fat_cache_add+24/9c>
Code; c0152bbd <fat_cache_add+71/9c>
6: 0f b7 43 20 movzwl 0x20(%ebx),%eax
Code; c0152bc1 <fat_cache_add+75/9c>
a: 66 89 02 mov %ax,(%edx)
Code; c0152bc4 <fat_cache_add+78/9c>
d: a1 40 2c 28 c0 mov 0xc0282c40,%eax
Code; c0152bc9 <fat_cache_add+7d/9c>
12: 89 72 00 mov %esi,0x0(%edx)


1 warning issued. Results may not be reliable.
--- misc.c.orig Mon Aug 7 20:43:02 2000
+++ misc.c Mon Aug 7 21:13:32 2000
@@ -166,7 +166,6 @@
MSDOS_SB(sb)->free_clusters--;
if (MSDOS_SB(sb)->fat_bits == 32)
fat_clusters_flush(sb);
- unlock_fat(sb);
last = 0;
/* We must locate the last cluster of the file to add this
new one (nr) to the end of the link list (the FAT).
@@ -186,6 +185,7 @@
file_cluster++;
if (!(curr = fat_access(sb, last = curr,-1))) {
fat_fs_panic(sb,"File without EOF");
+ unlock_fat(sb);
return res;
}
}
@@ -198,6 +198,7 @@
}
fat_cache_add(inode,file_cluster,nr);
inode->i_blocks += cluster_size;
+ unlock_fat(sb);
return 0;
}
\
 
 \ /
  Last update: 2005-03-22 13:58    [W:0.047 / U:0.204 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site