Totally screwed up system

Totally screwed up system

Post by mathew yeat » Wed, 01 Feb 1995 17:07:34



Here are the clues ...... (please don't guess that it was Miss Marple
with a knife in the ballroom)

My system has been fine since I installed it in July. (Slackware,
kernel = 1.0.9). But in the last 2 weeks ......

dd if=/dev/zero of=newfile bs=1024 count=8192
works fine
but
dd if=foo of=newfile bs=1024 count=8192
hangs my system when foo is large (over a meg)

similarly, I cannot copy a large file. However, I can move it.
cat foo > newfile also crashes me.

When I ran strace while trying to uncompress a large (1.3 meg) file,
I get a series of reads from 0 and writes to 1 and then the system
hangs with read(0,

Why am I unable to read large amounts? It doesn't seem like it could be
memory. The program "uncompress" was reading in 1024 blocks and only
crashed after a certain number had been read.

Whats happening here!

"free" says
        Total     used   free  shared buffers

Mem:    6708      6140   568  4732     1924
Swap:   8564      1840   6724

Last clue: gcc frequently gives me the internal error message. I understand
that this can be fixed by raisng the waits in cmos (whatever that means)
But is this related to my problem reading?

Mathew

 
 
 

Totally screwed up system

Post by David A Blankenshi » Thu, 02 Feb 1995 05:26:50


Excerpts from netnews.comp.os.linux.admin: 31-Jan-95 Totally screwed up

Quote:

> My system has been fine since I installed it in July. (Slackware,
> kernel = 1.0.9). But in the last 2 weeks ......

> dd if=/dev/zero of=newfile bs=1024 count=8192
> works fine
> but
> dd if=foo of=newfile bs=1024 count=8192
> hangs my system when foo is large (over a meg)

> similarly, I cannot copy a large file. However, I can move it.
> cat foo > newfile also crashes me.

> When I ran strace while trying to uncompress a large (1.3 meg) file,
> I get a series of reads from 0 and writes to 1 and then the system
> hangs with read(0,

> Why am I unable to read large amounts? It doesn't seem like it could be
> memory. The program "uncompress" was reading in 1024 blocks and only
> crashed after a certain number had been read.

> Whats happening here!

    Hmmm, you didn't run out of disk space did you?

=============================================================================
            "Women's Lib: Too many plots and plans, and not enough
                      pots and pans!"



 
 
 

Totally screwed up system

Post by Stephen Knila » Mon, 13 Feb 1995 02:16:07



>Here are the clues ...... (please don't guess that it was Miss Marple
>with a knife in the ballroom)

>My system has been fine since I installed it in July. (Slackware,
>kernel = 1.0.9). But in the last 2 weeks ......

>dd if=/dev/zero of=newfile bs=1024 count=8192
>works fine
>but
>dd if=foo of=newfile bs=1024 count=8192
>hangs my system when foo is large (over a meg)

>similarly, I cannot copy a large file. However, I can move it.
>cat foo > newfile also crashes me.

the MV command has NOTHING to do with the data, and merely moves the directory
entry so it is really only moving a few bytes, and not the entire file.

- Show quoted text -

Quote:

>Why am I unable to read large amounts? It doesn't seem like it could be
>memory. The program "uncompress" was reading in 1024 blocks and only
>crashed after a certain number had been read.

>Whats happening here!

>"free" says
>        Total     used   free  shared buffers

>Mem:    6708      6140   568  4732     1924
>Swap:   8564      1840   6724

>Last clue: gcc frequently gives me the internal error message. I understand
>that this can be fixed by raisng the waits in cmos (whatever that means)
>But is this related to my problem reading?

If you have a "GCC" error that can be corrected by "raising the waits in CMOS",
then WATCH IT!  The CMOS is a group of CMOS(complementary Symettry Metal Oxide
Semiconductor) chips(or I guesss they originally were), that store info about
how the computer should work.  The only "waits" that they control are on the
bus, various chips on board, and RAM.  If ANY of these don't have enough wait
states, your computer will become unpredictable.  If the RAM wait states are
set too low, for example, it could run for MONTHS without a problem until some
circuit on some chip, or the ram is accessed and then you could get a parity
error, incorrect data, or the computer could simply crash.  

Is it possible that the file has a problem and/or the kernel has a problem
that is causing it to simply hang?  After dismounting the disk, try fsck.
It is concievable that you could have some damaged inodes that are making
it go through more than 1MB, or they could be going through the same info
over and over again.  

Try typing "cat file.ext >/dev/null", and seeing if it is readable.  Check
free space on the drive to make sure there is enough.  Hopefully, it will give
people enough info to be a REAL help.  BTW, what kernel version are you running?

Steve

 
 
 

1. Help system totally screwed up !

--
Michael C. Vergallen A.k.A. Mad Mike,
Sportstraat 28                  http://www.double-barrel.be/mvergall/
B 9000 Gent                     ftp://ftp.double-barrel.be/pub/linux/
Belgium                         tel : 32-9-2227764 Fax : 32-9-2224976

2. need help with pppd problems (please)

3. HELP HELP HELP -Totally screwed ?

4. NFS v4 and cachefs

5. Totally screwed: How to Avoid in the Future

6. snooping in solaris

7. Totally screwed up

8. Bochs emulator

9. Totally new, totally lost in RedHat

10. Shape Ups,Men's Shape Ups,Men's Skechers Shape Ups - new styles!

11. Window Maker Freezez system totally

12. Getting out from the X windows system totally to terminal mode - newbie

13. SCSI problems freeze system totally