lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:	Tue, 29 Aug 2006 20:15:38 +0100
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	Martin Dorey <mdorey@...earc.com>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: 0x7f in SectorIdNotFound errors

Ar Llu, 2006-08-28 am 12:56 -0700, ysgrifennodd Martin Dorey:
> Aug 14 01:10:33 ithaki kernel: hdb: drive_cmd: status=0x7f { DriveReady
> DeviceFault SeekComplete DataRequest CorrectedError Index Error }
> 
> In hex, that LBAsect is 0x17f7f7f7f7f.  The disk is:

That may well have been f7f7f7f7f7... because several bits will have
been masked (its not 32bit addressed at controller<>device level)

> FS is ext3.  smartctl didn't report any errors but, then, it wouldn't
> necessarily if the problem was garbage fs metadata.  I found a few other
> LKML postings with 0x7f patterns in part of the LBAsect.

If you force an fsck do you see any errors ? I guess not but if you have
a chance to check please do.

I'm not sure where F7 came from as it is not a poison value we typically
use. The fact the value is odd is also significant. Most of the kernel
deals in 1K block sizes so any error/corruption occurred fairly low down
once we got into sectors. That seems to rule out, for example, ext3
metadata corruption because it would be very strange drive geometry to
start a partition on an odd sector boundary, and the ext3 meta data
doesn't go down to sector granularity.

Alan

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ