[206] in linux-scsi channel archive
Re: SCSI ext2 problems
daemon@ATHENA.MIT.EDU (Michael Weller)
Wed May 24 13:36:52 1995
Date: Wed, 24 May 1995 18:21:18 +0200 (MSZ)
From: Michael Weller <eowmob@exp-math.uni-essen.de>
To: Peter K <pko@paradigm.co.za>
Cc: linux-kernel@vger.rutgers.edu, linux-scsi@vger.rutgers.edu
In-Reply-To: <9505241425.AA22974@pollux.exp-math.uni-essen.de>
> From: Peter K <pko@paradigm.co.za>
> To: linux-kernel <linux-kernel@vger.rutgers.edu>
> Subject: SCSI ext2 problems
>
> Hi guys.
>
> Seem this box is out to get me. No hassles until 1.2.8 and then repeated
> crashes reporting (inter alia)
> Kernel panic: EXT2-fs panic (device 8/2): ext2_read_inode:
> unable to read i-node block - inode=6127, block=73743
[...]
I didn't understand exactly what you mean.. Ok you have this problems
with 1.2.8. and had none b4. However, when you now switch back to an older
do you still get problems (did you try) or does it work.
Some of the messages you wrote here refer to absolute low level disk errors
that would indeed hinder ext2 to continue operation (btw, tune2fs allows
to set ext2's error behaviour on the fs.. dunno if this will allow you
not to panic in this situation.. (of course data may be damaged on the fs)..
but if the panic annoys you it could be worth a try.
I don't think that anything this fatal was changed in the scsi driver
recently. Thus I don't really think it is a kernel problem. However 1.2.8
may make more disc accesses or something due to changed swapping
charakteristic s.t. it triggers other hardware problems. badblocks will
probably access the disk sequentially and may not show problems.
Actually there should be no bad blocks on a scsi disk anyway... but maybe
this disk insists on signalling corrected errors or the unability to remap
a newly found badblock to a free area with the Unit Attention... I do not
know how badblocks worx btw. does it only read data or write arbitrary
bit patters and rereads them with verify. If it uses the first approach
hardware problems may not show up with badblocks. (and thus I'd call it
less useful then)
If this disk is a SCSI-2 disk, I'd get scsiinfo and check if the disk has
actually reserved areas for badblocks. I got some disk once and it had not
a single reserved sector for remaps. If such a disk would encounter an
error it may show Unit Attention to say that a sector is bad but it can't
remap it. In that case allow for spare sectors with scsiinfo, save the
config and low level reformat the scsi-disk (thus loosing all data on
it!). Maybe the drive will then be able to remap faulty sectors in the
future.
Also it may be unable to recover the data from a corrupted block. All in all
I would think there is a hardware problem with your disk, scsi adapter or
cabling.
As long as you can't say that kernel x.x.x worx (even then less or different
discactivity may not trigger problems). One may still argue if ext2 should
take any action other than panicing in this situation.
> and, after switching to another screen and hitting <ENTER>
> Kernel panic: EXT2-fs panic (device 8/2): read_inode_bitmap:
> Cannot read inode bitmap - block_group = 1, inode_bitmap = 8197
>
> while the /var/adm/message file recorded
> May 24 10:04:03 kiko kernel: SCSI disk error :
> host 0 id 0 lun 0 return code = 28000002 May 24 10:04:03 kiko
> kernel: extra data not valid Current error sd802: sense key Unit Attention
> May 24 10:04:03
> kiko kernel: scsidisk I/O error: dev 0802, sector 6666
Depending on your syslog config it may well be that messages in
/var/adm/messages do not show up on the screen.
Fatal panics are always send directly to the console (if not in grafix mode)
(as far as I can remember) coz no process will ever have a chance to
record them somewhere.
> As I'm writing this the durned think again <fit proper noise> and (did
> *not* crash this time) recorded
>
> May 24 15:27:57 kiko kernel: SCSI disk error : host 0 id 0 lun 0 return
> code = 28000002
> May 24 15:27:57 kiko kernel: extra data not valid Current error sd803:
> sense key Unit Attention
> May 24 15:27:57 kiko kernel: scsidisk I/O error: dev 0803, sector 93992
> which refers to the second linux partition, this time. [sigh].
Depending on the action that was hit be the operation, ext2 may get
around it w/o panicing. Clearly the inode tables (first panic above) are
that vital that it can't continue w/o them.
Again, do two things:
1: TRY TO MAKE BACKUPS FROM EVERYTHING AS LONG AS YOUR DISK STILL
PARTIALLY WORX!
2: Check if the problem disappears with older kernels, that you could use
flawlessly for some time. It may be that it is kernel bug related..
but I doubt it.
Still if you are lucky someone just screwed the 1542 driver completely.
(eowmob@exp-math.uni-essen.de or eowmob@pollux.exp-math.uni-essen.de
Please do not use my vm or de0hrz1a accounts anymore. In case of real
problems reaching me try mat42b@aixrs1.hrz.uni-essen.de instead.)
