On Thu, 2007-02-01 at 17:10 -0700, Eric D. Mudama wrote:
> In the log you posted, the drive posted 51/04 to your out-of-bounds
> request, but these are 59/04, do they span the end of the device or
> something?
As you can see in the error-log including in the Ubuntu bug report, the
51/04 errors
On 2/1/07, TJ <[EMAIL PROTECTED]> wrote:
short extract ---
DC202XX: Primary channel reset.
ide2: reset: success
hde: task_in_intr: status=0x59 { DriveReady SeekComplete DataRequest
Error }
hde: task_in_intr: error=0x04 { DriveStatusError }
ide: failed opcode was: unknown
end_request: I/O
On Thu, 2007-02-01 at 14:26 -0800, Andrew Morton wrote:
> The recursion is a concern. Is there any way in which a cunningly-crafted
> device can cause sufficiently deep recursion to crash the kernel?
I did wonder about this, but couldn't think of an *elegant* way of
mirroring the
On 2/1/07, Andrew Morton <[EMAIL PROTECTED]> wrote:
Also, from reading the replies I think we'd like to see some more
explanation of why this is necessary: are you really really sure that those
disks were incorrectly handling illegal sector numbers? Knowing the IBM
and Maxtor model numbers
On Wed, 31 Jan 2007 23:50:39 +
TJ <[EMAIL PROTECTED]> wrote:
> + if (!insane && is_extended_partition(p)) { /* check the
> extended partition */
> + data = read_dev_sector(bdev, START_SECT(p)*sector_size,
> ); /* fetch sector from cache */
> +
On Thu, 01 Feb 2007 14:12:42 -0500
Phillip Susi <[EMAIL PROTECTED]> wrote:
> I think you may be barking up the wrong tree because IIRC, these
> requests for data beyond the end of the disk never make it to the drive;
> the kernel fails them in the block layer. There was a patch a while
> back
I think you may be barking up the wrong tree because IIRC, these
requests for data beyond the end of the disk never make it to the drive;
the kernel fails them in the block layer. There was a patch a while
back to fix the partition detection code to NOT request sectors beyond
the end of the
On Wed, 2007-01-31 at 22:20 -0600, Robert Hancock wrote:
> It seems pretty unlikely that telling a hard drive to seek past its
> capacity would cause it to damage itself, that would be some pretty
> moronic firmware. Though, you never know - if it's true, let me know
> what kind of drives
On Wed, 2007-01-31 at 22:20 -0600, Robert Hancock wrote:
It seems pretty unlikely that telling a hard drive to seek past its
capacity would cause it to damage itself, that would be some pretty
moronic firmware. Though, you never know - if it's true, let me know
what kind of drives these
I think you may be barking up the wrong tree because IIRC, these
requests for data beyond the end of the disk never make it to the drive;
the kernel fails them in the block layer. There was a patch a while
back to fix the partition detection code to NOT request sectors beyond
the end of the
On Thu, 01 Feb 2007 14:12:42 -0500
Phillip Susi [EMAIL PROTECTED] wrote:
I think you may be barking up the wrong tree because IIRC, these
requests for data beyond the end of the disk never make it to the drive;
the kernel fails them in the block layer. There was a patch a while
back to
On Wed, 31 Jan 2007 23:50:39 +
TJ [EMAIL PROTECTED] wrote:
+ if (!insane is_extended_partition(p)) { /* check the
extended partition */
+ data = read_dev_sector(bdev, START_SECT(p)*sector_size,
sect); /* fetch sector from cache */
+
On 2/1/07, Andrew Morton [EMAIL PROTECTED] wrote:
Also, from reading the replies I think we'd like to see some more
explanation of why this is necessary: are you really really sure that those
disks were incorrectly handling illegal sector numbers? Knowing the IBM
and Maxtor model numbers might
On Thu, 2007-02-01 at 14:26 -0800, Andrew Morton wrote:
The recursion is a concern. Is there any way in which a cunningly-crafted
device can cause sufficiently deep recursion to crash the kernel?
I did wonder about this, but couldn't think of an *elegant* way of
mirroring the
On 2/1/07, TJ [EMAIL PROTECTED] wrote:
short extract ---
DC202XX: Primary channel reset.
ide2: reset: success
hde: task_in_intr: status=0x59 { DriveReady SeekComplete DataRequest
Error }
hde: task_in_intr: error=0x04 { DriveStatusError }
ide: failed opcode was: unknown
end_request: I/O
On Thu, 2007-02-01 at 17:10 -0700, Eric D. Mudama wrote:
In the log you posted, the drive posted 51/04 to your out-of-bounds
request, but these are 59/04, do they span the end of the device or
something?
As you can see in the error-log including in the Ubuntu bug report, the
51/04 errors are
TJ wrote:
From: TJ <[EMAIL PROTECTED]>
Applies to: up-to and including 2.6.20-rc7
This rare but critical bug has the potential to cause a hardware failure on
disk drives by
allowing the system to repeatedly attempt to seek to sectors beyond the end of
the physical
disk, causing sustained
From: TJ <[EMAIL PROTECTED]>
Applies to: up-to and including 2.6.20-rc7
Update to previous patch.
Fixed logical error in if() statements for conditional printk(). Replaced
bit-wise OR with AND.
Signed-off-by: TJ <[EMAIL PROTECTED]>
--- fs/partitions/msdos.tj.c2007-02-01
From: TJ <[EMAIL PROTECTED]>
Applies to: up-to and including 2.6.20-rc7
This rare but critical bug has the potential to cause a hardware failure on
disk drives by
allowing the system to repeatedly attempt to seek to sectors beyond the end of
the physical
disk, causing sustained 'head
From: TJ [EMAIL PROTECTED]
Applies to: up-to and including 2.6.20-rc7
This rare but critical bug has the potential to cause a hardware failure on
disk drives by
allowing the system to repeatedly attempt to seek to sectors beyond the end of
the physical
disk, causing sustained 'head banging'.
From: TJ [EMAIL PROTECTED]
Applies to: up-to and including 2.6.20-rc7
Update to previous patch.
Fixed logical error in if() statements for conditional printk(). Replaced
bit-wise OR with AND.
Signed-off-by: TJ [EMAIL PROTECTED]
--- fs/partitions/msdos.tj.c2007-02-01 00:41:57.0
TJ wrote:
From: TJ [EMAIL PROTECTED]
Applies to: up-to and including 2.6.20-rc7
This rare but critical bug has the potential to cause a hardware failure on
disk drives by
allowing the system to repeatedly attempt to seek to sectors beyond the end of
the physical
disk, causing sustained
22 matches
Mail list logo
