lkml.org 
[lkml]   [2006]   [Apr]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: about ll_rw_blk.c of void generic_make_request(struct bio *bio)
From
On Thu, 6 Apr 2006, erich wrote:
> I am so sorry that I reply this mail today.
> At 2006/4/3 my mother unexpectedly got paralysis and dead.
> I can not do any more "request testing" with this bug for some days.
> I do dump_stack as your request and attach it.
> And I do "fsck" before test this volume every time.
> It appears fine when do fsck with each testing volume.
> You can easily reproduce this bug from copy a 900MB file from ARECA volume
> (mkfs.ext2, mount -t ext2) to none ARECA volume.

Erich, my sincere condolences to you and your family.

With respect to this problem, is it possible with your driver that if a
transfer read request is above a certain size, data corruption occurs?

It may be that fsck passes because it is doing smaller transfers while a
file copy under ext2 (or in your example, ext3) fails because it is during
those operations that the higher max_sectors makes a difference.

Curiously, the hex values of the "want=" field in your report are as
follows:

sdb1: rw=0, want=12126966488, limit=312496317
2D2D2D2D8
sdb1: rw=0, want=12126967088, limit=312496317
2D2D2D530
sdb1: rw=0, want=22232771288, limit=312496317
52D2D2AD8
sdb1: rw=0, want=22232771888, limit=312496317
52D2D2D30

I wonder if 0x2D or 0xD2 corresponds to something on the disk such as in
the file being copied or is otherwise familiar.

Chris
-
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/

\
 
 \ /
  Last update: 2006-04-06 13:47    [W:0.650 / U:0.048 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site