st0: Block limits 1 - 16777215 bytes.

st0: Block limits 1 - 16777215 bytes.

[Glover George]

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?

Thank you.

Glover George
Systems/Networks Admin
Gulf Sales & Supply, Inc.
(228) 762-0268
dime@gulfsales.com
http://www.gulfsales.com
 

Re: st0: Block limits 1 - 16777215 bytes.

[Mr. James W. Laferriere]

	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 .

	Tyan Thunder HE-SL Dual s370 M.B.
 # lspci
00:00.0 Host bridge: Relience Computer CNB20HE (rev 23)
00:00.1 PCI bridge: Relience Computer CNB20HE (rev 01)
00:00.2 Host bridge: Relience Computer: Unknown device 0006 (rev 01)
00:00.3 Host bridge: Relience Computer: Unknown device 0006 (rev 01)
00:01.0 SCSI storage controller: Symbios Logic Inc. (formerly NCR): Unknown device 0021 (rev 01)
00:01.1 SCSI storage controller: Symbios Logic Inc. (formerly NCR): Unknown device 0021 (rev 01)
	BTW these are a Symbios 53c1010 chip on board .
00:02.0 Multimedia audio controller: Ensoniq ES1371 [AudioPCI-97] (rev 09)
00:04.0 PCI bridge: Intel Corporation 80960RP [i960 RP Microprocessor/Bridge] (rev 05)
00:04.1 RAID bus controller: Mylex Corporation DAC960PX (rev 05)
	Is a DAC960PL
00:07.0 Ethernet controller: Intel Corporation 82557 [Ethernet Pro 100] (rev 08)
00:0f.0 ISA bridge: Relience Computer: Unknown device 0200 (rev 51)
00:0f.1 IDE interface: Relience Computer: Unknown device 0211
00:0f.2 USB Controller: Relience Computer: Unknown device 0220 (rev 04)
01:00.0 VGA compatible controller: ATI Technologies Inc Rage 128 PF

 # cat /proc/cpuinfo Below x 2 .

processor       : 0 			( & 1 )
vendor_id       : GenuineIntel
cpu family      : 6
model           : 8
model name      : Pentium III (Coppermine)
stepping        : 10
cpu MHz         : 849.158
cache size      : 256 KB
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 2
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr sse
bogomips        : 1690.82


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?
>
> Thank you.
>
> Glover George
> Systems/Networks Admin
> Gulf Sales & Supply, Inc.
> (228) 762-0268
> dime@gulfsales.com
> http://www.gulfsales.com
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

       +------------------------------------------------------------------+
       | James   W.   Laferriere | System    Techniques | Give me VMS     |
       | Network        Engineer |     P.O. Box 854     |  Give me Linux  |
       | babydr@baby-dragons.com | Coudersport PA 16915 |   only  on  AXP |
       +------------------------------------------------------------------+

RE: st0: Block limits 1 - 16777215 bytes.

[Glover George]

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?
> >

RE: st0: Block limits 1 - 16777215 bytes.

[Richard B. Johnson]

On Wed, 20 Feb 2002, Glover George wrote:

> 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.

You do not tar /proc!  There is kcore there! `tar` thinks it's a real
file. Reading (accessing) some kernel areas will cause a deadlock.

If you don't want to --exclude proc, then `umount` it before your
backups. FYI, it's SOP to backup different mounted file-systems so
you don't end up backing up N disks on a single media. Therefore
your `tar` sequence would be something like:

tar -czlf root.tar.gz /
tar -czlf user.tar.gz /user
       |________ stay on the same file-system.
..etc..

Since /proc is a seperate file-system, you never have problems like
you describe and the mount-point gets backed up as required.


Cheers,
Dick Johnson

Penguin : Linux version 2.4.1 on an i686 machine (797.90 BogoMips).

        111,111,111 * 111,111,111 = 12,345,678,987,654,321