public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Ingo Rohloff <lundril@gmx.net>
To: linux-kernel@vger.kernel.org
Subject: Problems with NFS in 2.4test10
Date: Thu, 9 Nov 2000 21:50:45 +0000	[thread overview]
Message-ID: <20001109215045.A591@flashline.chipnet> (raw)

Hi,

First a description of my machine:
I use a Dual Celeron System with glibc-2.1.3 and
linux-2.4test10 . 
For information on peripherial devices I give the output of /proc/pci

PCI devices found:
  Bus  0, device   0, function  0:
    Host bridge: Intel Corporation 440BX/ZX - 82443BX/ZX Host bridge (rev 2).
      Master Capable.  Latency=64.  
      Prefetchable 32 bit memory at 0xe0000000 [0xe3ffffff].
  Bus  0, device   1, function  0:
    PCI bridge: Intel Corporation 440BX/ZX - 82443BX/ZX AGP bridge (rev 2).
      Master Capable.  Latency=64.  Min Gnt=128.
  Bus  0, device   7, function  0:
    ISA bridge: Intel Corporation 82371AB PIIX4 ISA (rev 2).
  Bus  0, device   7, function  1:
    IDE interface: Intel Corporation 82371AB PIIX4 IDE (rev 1).
      Master Capable.  Latency=64.  
      I/O at 0xf000 [0xf00f].
  Bus  0, device   7, function  2:
    USB Controller: Intel Corporation 82371AB PIIX4 USB (rev 1).
      IRQ 19.
      Master Capable.  Latency=64.  
      I/O at 0xe000 [0xe01f].
  Bus  0, device   7, function  3:
    Bridge: Intel Corporation 82371AB PIIX4 ACPI (rev 2).
  Bus  0, device   8, function  0:
    Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8029(AS) (rev 0).
      IRQ 16.
      I/O at 0xe400 [0xe41f].
  Bus  0, device  11, function  0:
    VGA compatible controller: S3 Inc. 86c764/765 [Trio32/64/64V+] (rev 0).
      Non-prefetchable 32 bit memory at 0xe5000000 [0xe57fffff].


I have another computer (a K6) which is used as NFS server
(running Universal NFS Server 2.2beta41 under glibc-2.0.7 and
 linux-2.2.16 )

I try to Encode WAV files to MP3s, which are both hosted
on the K6. The files are located on a ReiserFS partition,
which is mounted via NFS from the Dual Celeron.

My Dual Celeron locks up regularily during this operation.
The encoding process simply stops and the whole computer
locks up. (No pinging possible).

I first suspected that it had something to do with 
the Kernel NFS _Server_ which I use on the Dual Celeron,
but since in this case the Dual Celeron acts as client,
this shouldn't be the reason right ?

Any Ideas how to track down this problem (like putting
some printk's in strategically important locations ?)

so long
  Ingo

PS: I might be a hardware problem, since dual Celerons
    should be impossible... But i do a lot of compiling
    on this machine and it never locked up, or threw errors
    during compiling. So I suspect it isn't the hardware.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

             reply	other threads:[~2000-11-09 19:47 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-11-09 21:50 Ingo Rohloff [this message]
     [not found] ` <3A0B2FAB.334D36BC@asiapacificm01.nt.com>
     [not found]   ` <3A0B30F3.FA703FAD@mandrakesoft.com>
2000-11-11 18:35     ` Problems with NFS in 2.4test10 Ingo Rohloff

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20001109215045.A591@flashline.chipnet \
    --to=lundril@gmx.net \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox