Re: TCQ problems in 2.6.0-test1: the summary

[Jens Axboe <axboe@suse.de>]

On Sat, Jul 19 2003, Ivan Gyurdiev wrote:
> 2.6.0-test1-current.
> The TCQ bugs/problems that I have found in the kernel have not been
> addressed yet. Some of the things posted below are new, but most have
> been posted before, and there have been no replies. If those bug reports
> are invalid, please say so, and I will stop sending them.
> 
> ================================================================================
> 
> I own an IC35L080AVVA07-0 80 GB drive
> (IBM Desktar 120 GXP, which is supposed to support TCQ).
> TCQ will not be activated on boot unless TCQ is enabled by default.
> 
> The problems:
> 
> ======================================================================================
> 1) This patch by Jens Axboe makes my machine bootable with tcq enabled.
> It hasn't been included in the kernel yet.
> 
> http://www.ussg.iu.edu/hypermail/linux/kernel/0307.1/1006.html

I'll send that in.

> 2) The default for queue depth is commented as 32, but is in fact 8.

I'll fix that up, too.

> 3) This is described as a way to set tcq depth in the docs:
>  echo "using_tcq:32" > /proc/ide/hdX/settings
> 
> but it results in:  proc_ide_write_settings(): parse error
> (hdparm -Q works instead)

Huhm weird, someone has broking the proc parsing. I'll look into that.
-Q does the same thing, as you know.

> 4) Using a tcq-enabled kernel with queue depth of 8 results in
> massive filesystem corruption for me, verified under reiserfs, and xfs.
> Elevator choice does not appear to matter, while queue depth is
> important - I do not appear to get filesystem corruption with queue
> depth of 32. Reiser refuses to mount with such a kernel, and runs
> --fix-fixable at boot time. This is reproducible every time.

This is really strange. The only difference between using 8 or 32 tags
is when ide-disk stops attempting to queue. Are you getting any errors
in dmesg when this happens? Reading the start io path for this, it looks
correct to me. I'll have to try and reproduce when I get back.

> 5) Using a tcq-enabled kernel causes i/o lockups (disk read/write
> freezes, while I am still able to move the mouse, type dmesg, etc..). To
> trigger the partial i/o lockups I set the disk standby to 5 seconds.
> After waking up the disk, I get numerous errors, and I have also gotten
> an oops. Attempts to reproduce this with tcq off have failed so far. The
> errors and oops are posted here:
> 
> http://www.ussg.iu.edu/hypermail/linux/kernel/0307.1/1682.html

Noted, that is something I haven't tested.

> I am still keeping an old damaged reiser root filesystem, for the
> purposes of testing. If there is interest in testing filesystem
> corruption bugs, I am willing to do that. Please reply, though, because
> I will eventually destroy that partition if there is no interest.

If it's an ide tcq bug, it isn't very interesting. You can safely fry
that partition.

-- 
Jens Axboe