All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Glover George" <dime@gulfsales.com>
To: "'Mr. James W. Laferriere'" <babydr@baby-dragons.com>
Cc: <linux-kernel@vger.kernel.org>
Subject: RE: st0: Block limits 1 - 16777215 bytes.
Date: Wed, 20 Feb 2002 08:56:41 -0600	[thread overview]
Message-ID: <003601c1ba1e$ce631630$0300a8c0@yellow> (raw)
In-Reply-To: <Pine.LNX.4.44.0202192005050.32040-100000@filesrv1.baby-dragons.com>

Ok, after playing with it a little more I found out that the message I'm
getting about the block sizes isn't related to the lockups.  I can lock
the system up by tar'ing up the /proc directory (why are you tar'ing the
/proc directory!!! I know!!! But that's not the point).  I had no
problem with RH 7.2's supplied 7.2 kernel (2.4.7-10).  However, this is
2.4.17 (with the linux-abi patch). 

I have been able to make succesful backups as long as I ignore the /proc
directory but something must be wrong.  Doing an "ls -la *" doesn't lock
the machine though.  Only when tar'ing it (I suppose because of a read).
It doesn't lock up consistently in the same place when reading from the
proc directory however, but always in the proc.  I made about 15 test
runs and they all died in proc and --exclude proc doesn't cause it to
lock somewhere else.

I guess the question is (and I've had it for a while) is how do I get
the system to log more info for me?  I'm a little new a debugging the
kernel, but I did compile most of the debugging into a test kernel.
However, the system hard locks with no oops or anything in the logs.
The system must be shutdown by holding the power button in for 4
seconds. I know this must not be a huge problem because no ones
mentioned it, so I'd like to do some more investigating on my part.
Thanks for your help.

> 	Hello Glover ,  I get the same messages & do not get system
> 	lock ups .  Might try sending a little bit more info about
> 	what is going on around any of the lock ups .  If you can
> 	reliably lock up the system by accessing the tape drive .
> 	Then send some info to the list about the system & the tape
> 	drive and how it is attached to the system .  Hth ,  JimL
> ps:	All disk & tape drives are scsi .
> 
> 
> On Tue, 19 Feb 2002, Glover George wrote:
> 
> > I've been experiencing mysterious lockups since upgrading to kernel 
> > 2.4.17.  Looking in the /var/log/messages I hadn't seen anything 
> > suspicious until now.  I guess the machine hasn't had time to write 
> > this to disk except every now and then.  The message
> >
> > Feb 19 11:29:55 butler kernel: st0: Block limits 1 - 16777215 bytes.
> >
> > I notice this after rebooting after the crash.  So I tried manually 
> > doing a tar to the tape drive and was able to successfully lock the 
> > machine up.  Can someone help me understand this and if it 
> is simply a 
> > limit problem, why would the machine lock up?
> >


  reply	other threads:[~2002-02-20 14:56 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-02-19 17:57 st0: Block limits 1 - 16777215 bytes Glover George
2002-02-20  1:15 ` Mr. James W. Laferriere
2002-02-20 14:56   ` Glover George [this message]
2002-02-20 15:21     ` Richard B. Johnson

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='003601c1ba1e$ce631630$0300a8c0@yellow' \
    --to=dime@gulfsales.com \
    --cc=babydr@baby-dragons.com \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.