IDE from current bk tree, UDMA and two channels...

I finally managed to compile older kernels, and I found that 2.5.27 (and 2.4.19-rc1 and 2.5.26) works fine (modulo endless loop in ide_do_request... but it takes at least 5 minutes to trigger it), while 2.5.28 dies in one second with UDMA status 0x25 (irq requested, transfer in progress) and IDE status 0x58 (drq asserted).

Because of only change in IDE system between 2.5.27 and 2.5.28 is renaming __save_flags => local_save_flags, fixing get_request for ioctl commands (so 2.5.28 should be correct while 2.5.27 is not), and moving some ioctls around, it looks like that problem is triggered by something else.

I currently suspect IRQ handling changes, but maybe someone has better idea? Also, I cannot reproduce problem with Seagate UDMA66 drive switched to UDMA33 mode, so it looks like that problem is timming/firmware (Toshiba MK6409MAV) dependent.

And I did all these tests with UP kernel, just to eliminate cli/sti changes.
Petr Vandrovec [email protected]

I'd like to apologize to Ingo, his changes were completely innocent. Problem was triggered by Al's 'block device size cleanups' (currently cset 1.403.160.5 on bkbits).

Before this change, my system was using 4KB block size when reading from /dev/hdc1, because of blk_size[][] (which is in 1kB units) of this partition was multiple of 2, and so i_size % 4096 was 0. But after Al's change partition size is read from gendisk, and not from blk_size, and gendisk partition size is in 512 bytes units: and, as you can probably guess, now my partition had i_size % 4096 == 512, and so only 512 byte block size was choosen. And with 512 bytes block size my harddisk refuses to cooperate.

I was trying to find reason in code, why 512 byte block size should not work, but I was not able to reveal any. Maybe I/O gurus here will know?

For now, I'm using patch below. It fixes problems for me, block size = 1024 is sufficient in my configuration. If you have any insights what can be a problem, please tell me. Problem apparently is not in i_size not being multiple of 1024: without changing bsize problem still occurs, even if I shrink i_size down to be multiple of 4K.

After some more testing I found that my other drive (120GB WD) handles bsize=512 quite happily, so it looks like that just my Toshiba disk does not like 512B back to back transfers?! Are there any plans to read from block devices in 4KB blocks for all reads/writes except for the last partial page?
Thanks,
Petr Vandrovec [email protected]

@@ -608,6 +608,11 @@
 				break;
 			bsize <<= 1;
 		}
+		if (bsize == 512) {
+			printk(KERN_ERR "Found 512b device! Using larger block size...\n");
+			bdev->bd_inode->i_size -= 512;
+			bsize = 1024;
+		}
 		bdev->bd_block_size = bsize;
 		bdev->bd_inode->i_blkbits = blksize_bits(bsize);
 		if (p->queue)

Uz.ytkownik Petr Vandrovec napisa?:

Petr. First - I wish to express my respect (for whatever it's worth). Once again you are fscking sharp and up the point in problem analysis.

For what few things I know about the situation is that the SATA people are having great problems with the mediocre physical sector size and they are pushing hard toward bigger sector
sizes. This may explain a bit why there is a propability why one should be awake in this area.

Would you mind sending me hdparm -i /dev/hdx and hdparm -I /dev/hdx for documentation purposes? The host controller chip could be the one to blame as well.

I fear the need for jet another black list.

Uh-oh...

Let me see if I got it straight:

a) your disk doesn't work with half-Kb requests
b) you have a partition with odd number of sectors
c) hardsect_size is set to half-Kb
d) old code worked since it rounded size to multiple of kilobyte.

Correct?