A brief overview of what I am experiencing:
I have an old 486 running RH 7.1 on a 60 gig hdd. There is a / partition and a /home partition. I have compiled a custom rh 7.1 kernel 2.4.2-2 and am using it. The box is basically used to serve mp3's and vidoeos using samba.
I have noticed that there are large amounts of collisions when I attempt to copy anything from the Win98 box to the Linux box by using windows to do the copy. I tried using smbclient on the linux box to do a file copy from the win box to the linux box and got a lot of collisions this way.
While I do these copies on large files (>10Mb) I often get an error in windows after it has copied an amount of the file claiming that the network resource is not available. When I tried the copy in smbclient, it would seg fault.
I changed this line in the smb.conf:
socket options = TCP_NODELAY SO_RCVBUF=8192 SOSNDBUF=8192
to:
socket options = TCP_NODELAY SO_RCVBUF=18192 SOSNDBUF=8192

I figured perhaps the 486 was being overloaded with data so I increased the buffer.
This didn't fix the collisions when copying things from Win->Linux using Windows, but it did significantly lower the number of collisions when doing the same copy using smbclient in linux.

I still get the error copying large files under windows. Also, before and after I changed this line, and with both my kernel and the stock RH kernel, the kernel occasionally panics when one of these copy errors is recieved in windows. This does not happen all the time, but often enough that I worry about it. Usually it is an: unable to dereference NULL kernel pointer

I would like any info on how to trouble shoot, what log files to check, how to set up log files to be detailed enough to be useful, and any info on what may be causing this.

My three theories: The machine has crashed many times and had errors on the file system from other things I have done with it, could this have damaged important files?
The machine has networking problems (being overloaded with data, not talking to Win correctly, just too old and slow).
or
Maybe this is a kernel bug? Might it help to upgrade to a new kernel? I have read that 2.4 kernels before 2.4.17 or so have several different bugs?

At this point I'm ready to start from scratch and do an LFS system. This will be my choice if no one can help me debug this machine.


***EDIT***

I origianally thought this was samba, now I believe it is a network card issue, see below.

I found this info:




At this point I'm ready to start from scratch and do an LFS system. This will be my choice if no one can help me debug this machine.


On Sun, 1 Oct 2000, Niccolo Rigacci wrote:


> I have a Debian GNU/Linux 2.2 (kernel 2.2.17) installed on a
> Cyrix 6x86, sometimes it panics. As far I can detect the panics
> occur when there is much disk activity (updatedb and
> checksecurity are in progress). I was able to get the log of the
> panic via the serial console.


Do you have smbfs mounted when find/updatedb is running? 2.2.18pre fixes
an old bug where smbfs didn't check the length of the path it was building
vs the buffer used to store the path. Depending on what you have mounted
this can cause all sorts of fun things to happen.


If you had not used smbfs since booting then that is not it, and then I
know nothing about it.


/Urban

This is outrageous!!!!

I figured perhaps there is a coding bug, so I went to update some pkgs at:

ftp://updates.redhat.com/7.1/en/os/i386

I updated samba, samba client, and samba common.
I also got a new kernel source and header.

I installed a new kernel with the new samba rpms and I'm still getting this: Unable to handle kernel paging request at virtual memory address...

I found the above info and I checked samba.org to see what the latest version is.. I don't trust redhat's update page now!!

The version they had for an UPGRADE was 2.0.10!!!
2.2 is out on samba.org in an rpm rolled for RH 7.1!! RH really sucks, they are extremely old in their versions! I had to go to the rawhide site
ftp://ftp.redhat.com/pub/redhat/linu...6/RedHat/RPMS/ for the 2.2 version of samba! The kernel I got was also old. It has on the update site 2.4.9, but at the rawhide site, it has 2.4.17!!

Can anyone explain why Rehat is keeping users pushed back? If I get something from the update site, I expect it to be the latest stable version!!

I'm upgrading samba once again, this time to 2.2.8
I'm still having the collisions and crashes, but maybe this will fix it.
I'm also going to try taking out that "TCP_NODELAY" if that doesn't work.

I might also dl that 2.4.17 kernel.

All these crashes are doing heavy damage to my file system.. Once I figure out how to fix this, I may just do a clean install and patch it.

Well, I upgraded to samba 2.2.8 and I still got a hung system with use..

On a hunch, I set up my windows box to run many instances of ping using 65500 size pings. I ran about 10-15 instances of this, pinging linux to put stress on its networking. After 3 minutes, I got a hung box.

I don't think this is a samba issue now, I believe this may be a NIC card driver issue. I have a 3com 900B boomerang. I'm going to change from the driver provided with the kernel source to the driver available from 3com and retest.

This problem was definitly a driver problem. The driver provided in the kernel was an old version of what can be found at www.scyld.com. Instead of updating this driver, I used 3com's driver. It is GPL. After making a new kernel without stock support for my NIC card and compiling 3com's driver, I stressed the box by ping flooding it and later copying 6 cd's to it using samba. It is now rock solid. Now if only I could get that source in the kernel instead of having it run as a module...

what is the diference in performance if i hace a driver kernel provided or an added module??

the question is because all my nics are module added and they work all right.

thanx, and congratulations you got it alone!!!

To the best of my knowledge, having them as modules has no better or worse performance. The only problem that I see is that getting the modules to load correctly on boot can be a pain in the butt. This is how my drivers are also since I cannot figure out how to compile 3 com's drivers directly into the kernel.