[2.6.13] pktcdvd: IO-errors

[2.6.13] pktcdvd: IO-errors

[Guennadi Liakhovetski]

Hi all

Just tried pktcdvd on 2.6.13.1. The setup went fine:

20:33:13: pktcdvd: writer pktcdvd0 mapped to hdc
20:33:21: pktcdvd: inserted media is CD-RW
20:33:21: pktcdvd: Fixed packets, 32 blocks, Mode-2 disc
20:33:21: pktcdvd: Max. media speed: 10
20:33:21: pktcdvd: write speed 10x
20:33:21: pktcdvd: 590528kB available on disc
20:33:23: UDF-fs INFO UDF 0.9.8.1 (2004/29/09) Mounting volume 'LinuxUDF', timestamp 2005/09/24 20:18 (1078)

But, as I tried to copy some files to the CD-RW, it first went ok, but 
then produced the following:

20:41:01: ide-cd: cmd 0x2a timed out
		      ^^^^	---------> write10
20:41:01: hdc: DMA timeout retry
20:41:01: hdc: timeout waiting for DMA
20:41:01: hdc: status timeout: status=0xd0 { Busy }
20:41:01: ide: failed opcode was: unknown
20:41:01: hdc: drive not ready for command
20:41:31: hdc: ATAPI reset timed-out, status=0x80
20:42:06: ide1: reset timed-out, status=0x80
20:42:06: hdc: status timeout: status=0x80 { Busy }
20:42:06: ide: failed opcode was: unknown
20:42:06: hdc: drive not ready for command
20:42:36: hdc: ATAPI reset timed-out, status=0x80
20:43:07: : I/O error, dev hdc, sector 136672
20:43:07: end_request: I/O error, dev hdc, sector 136680
20:43:07: end_request: I/O error, dev hdc, sector 136688
20:43:07: end_request: I/O error, dev hdc, sector 136696
20:43:07: end_request: I/O error, dev hdc, sector 137216
20:43:07: end_request: I/O error, dev hdc, sector 137224
20:43:07: end_request: I/O error, dev hdc, sector 137232
20:43:07: end_request: I/O error, dev hdc, sector 137240
... <thousands of the above>
20:43:11: end_request: I/O error, dev hdc, sector 344440
20:43:11: end_request: I/O error, dev hdc, sector 344444
20:43:11: pktcdvd: bb 00 06 ea 06 ea 00 00 00 00 00 00 - sense 00.e0.0e (No sense)
20:43:11: end_request: I/O error, dev hdc, sector 363008
20:43:11: end_request: I/O error, dev hdc, sector 363016
... <more of them>
20:43:11: printk: 79693 messages suppressed.
20:43:11: Buffer I/O error on device pktcdvd0, logical block 90752
20:43:11: lost page write due to I/O error on pktcdvd0
20:43:11: end_request: I/O error, dev hdc, sector 362880
20:43:11: end_request: I/O error, dev hdc, sector 362884
...

the "cp" finished earlier, I did a sync, and it also finished. The good 
parts - no Oops, no process stuck in "D", tha bad parts - it didn't 
work:-), the IDE LED stays on and I cannot eject the CD. The CD-R is a 
BenQ 52x32x52 Seamless Link alone on ide1, the disk does indeed say 
4x-10x. The cd-writer works mostly... if I am gentle to it - I usually 
burn at 32x even if the media says 52x... Is it just a hw-failure or a 
driver bug?

Thanks
Guennadi
---
Guennadi Liakhovetski

Re: [2.6.13] pktcdvd: IO-errors

[Peter Osterlund]

Guennadi Liakhovetski <g.liakhovetski@gmx.de> writes:

> Just tried pktcdvd on 2.6.13.1. The setup went fine:
> 
> 20:33:13: pktcdvd: writer pktcdvd0 mapped to hdc
> 20:33:21: pktcdvd: inserted media is CD-RW
> 20:33:21: pktcdvd: Fixed packets, 32 blocks, Mode-2 disc
> 20:33:21: pktcdvd: Max. media speed: 10
> 20:33:21: pktcdvd: write speed 10x
> 20:33:21: pktcdvd: 590528kB available on disc
> 20:33:23: UDF-fs INFO UDF 0.9.8.1 (2004/29/09) Mounting volume 'LinuxUDF', timestamp 2005/09/24 20:18 (1078)
> 
> But, as I tried to copy some files to the CD-RW, it first went ok, but 
> then produced the following:
> 
> 20:41:01: ide-cd: cmd 0x2a timed out
> 		      ^^^^	---------> write10
> 20:41:01: hdc: DMA timeout retry
> 20:41:01: hdc: timeout waiting for DMA
> 20:41:01: hdc: status timeout: status=0xd0 { Busy }
> 20:41:01: ide: failed opcode was: unknown
> 20:41:01: hdc: drive not ready for command
> 20:41:31: hdc: ATAPI reset timed-out, status=0x80
> 20:42:06: ide1: reset timed-out, status=0x80
> 20:42:06: hdc: status timeout: status=0x80 { Busy }
> 20:42:06: ide: failed opcode was: unknown
> 20:42:06: hdc: drive not ready for command
> 20:42:36: hdc: ATAPI reset timed-out, status=0x80
> 20:43:07: : I/O error, dev hdc, sector 136672
> 20:43:07: end_request: I/O error, dev hdc, sector 136680
> 20:43:07: end_request: I/O error, dev hdc, sector 136688
> 20:43:07: end_request: I/O error, dev hdc, sector 136696
> 20:43:07: end_request: I/O error, dev hdc, sector 137216
> 20:43:07: end_request: I/O error, dev hdc, sector 137224
> 20:43:07: end_request: I/O error, dev hdc, sector 137232
> 20:43:07: end_request: I/O error, dev hdc, sector 137240
> ... <thousands of the above>
> 20:43:11: end_request: I/O error, dev hdc, sector 344440
> 20:43:11: end_request: I/O error, dev hdc, sector 344444
> 20:43:11: pktcdvd: bb 00 06 ea 06 ea 00 00 00 00 00 00 - sense 00.e0.0e (No sense)
> 20:43:11: end_request: I/O error, dev hdc, sector 363008
> 20:43:11: end_request: I/O error, dev hdc, sector 363016
> ... <more of them>
> 20:43:11: printk: 79693 messages suppressed.
> 20:43:11: Buffer I/O error on device pktcdvd0, logical block 90752
> 20:43:11: lost page write due to I/O error on pktcdvd0
> 20:43:11: end_request: I/O error, dev hdc, sector 362880
> 20:43:11: end_request: I/O error, dev hdc, sector 362884
> ...
> 
> the "cp" finished earlier, I did a sync, and it also finished. The good 
> parts - no Oops, no process stuck in "D", tha bad parts - it didn't 
> work:-), the IDE LED stays on and I cannot eject the CD. The CD-R is a 
> BenQ 52x32x52 Seamless Link alone on ide1, the disk does indeed say 
> 4x-10x. The cd-writer works mostly... if I am gentle to it - I usually 
> burn at 32x even if the media says 52x... Is it just a hw-failure or a 
> driver bug?

Did it ever work with this hardware, for example using 2.6.12? Does
the drive have the latest firmware? If not, a firmware upgrade might
help. Does it work if you use ide-scsi instead of ide-cd?

What errors do you get if you try to burn at 52x without using the
packet writing driver?

-- 
Peter Osterlund - petero2@telia.com
http://web.telia.com/~u89404340

Re: [2.6.13] pktcdvd: IO-errors

[Guennadi Liakhovetski]

On Sun, 25 Sep 2005, Peter Osterlund wrote:

> Guennadi Liakhovetski <g.liakhovetski@gmx.de> writes:
> 
> > Just tried pktcdvd on 2.6.13.1. The setup went fine:
> > 
> > 20:33:13: pktcdvd: writer pktcdvd0 mapped to hdc
> > 20:33:21: pktcdvd: inserted media is CD-RW
> > 20:33:21: pktcdvd: Fixed packets, 32 blocks, Mode-2 disc
> > 20:33:21: pktcdvd: Max. media speed: 10
> > 20:33:21: pktcdvd: write speed 10x
> > 20:33:21: pktcdvd: 590528kB available on disc
> > 20:33:23: UDF-fs INFO UDF 0.9.8.1 (2004/29/09) Mounting volume 'LinuxUDF', timestamp 2005/09/24 20:18 (1078)
> > 
> > But, as I tried to copy some files to the CD-RW, it first went ok, but 
> > then produced the following:
> > 
> > 20:41:01: ide-cd: cmd 0x2a timed out
> > 		      ^^^^	---------> write10
> > 20:41:01: hdc: DMA timeout retry
> > 20:41:01: hdc: timeout waiting for DMA
> > 20:41:01: hdc: status timeout: status=0xd0 { Busy }
> > 20:41:01: ide: failed opcode was: unknown
> > 20:41:01: hdc: drive not ready for command
> > 20:41:31: hdc: ATAPI reset timed-out, status=0x80
> > 20:42:06: ide1: reset timed-out, status=0x80
> > 20:42:06: hdc: status timeout: status=0x80 { Busy }
> > 20:42:06: ide: failed opcode was: unknown
> > 20:42:06: hdc: drive not ready for command
> > 20:42:36: hdc: ATAPI reset timed-out, status=0x80
> > 20:43:07: : I/O error, dev hdc, sector 136672
> > 20:43:07: end_request: I/O error, dev hdc, sector 136680
> > 20:43:07: end_request: I/O error, dev hdc, sector 136688
> > 20:43:07: end_request: I/O error, dev hdc, sector 136696
> > 20:43:07: end_request: I/O error, dev hdc, sector 137216
> > 20:43:07: end_request: I/O error, dev hdc, sector 137224
> > 20:43:07: end_request: I/O error, dev hdc, sector 137232
> > 20:43:07: end_request: I/O error, dev hdc, sector 137240
> > ... <thousands of the above>
> > 20:43:11: end_request: I/O error, dev hdc, sector 344440
> > 20:43:11: end_request: I/O error, dev hdc, sector 344444
> > 20:43:11: pktcdvd: bb 00 06 ea 06 ea 00 00 00 00 00 00 - sense 00.e0.0e (No sense)
> > 20:43:11: end_request: I/O error, dev hdc, sector 363008
> > 20:43:11: end_request: I/O error, dev hdc, sector 363016
> > ... <more of them>
> > 20:43:11: printk: 79693 messages suppressed.
> > 20:43:11: Buffer I/O error on device pktcdvd0, logical block 90752
> > 20:43:11: lost page write due to I/O error on pktcdvd0
> > 20:43:11: end_request: I/O error, dev hdc, sector 362880
> > 20:43:11: end_request: I/O error, dev hdc, sector 362884
> > ...
> > 
> > the "cp" finished earlier, I did a sync, and it also finished. The good 
> > parts - no Oops, no process stuck in "D", tha bad parts - it didn't 
> > work:-), the IDE LED stays on and I cannot eject the CD. The CD-R is a 
> > BenQ 52x32x52 Seamless Link alone on ide1, the disk does indeed say 
> > 4x-10x. The cd-writer works mostly... if I am gentle to it - I usually 
> > burn at 32x even if the media says 52x... Is it just a hw-failure or a 
> > driver bug?
> 
> Did it ever work with this hardware, for example using 2.6.12?

It was the first time I ever tried it. Now as you asked I also tried 
2.6.12-rc5. Surprise, surprise - it worked... But very strange. First, I 
did

# time cp -a source /cdrom/ ; time sync

It took a few minutes to copy 190MB, but it finished successfully. Now to 
the strange things: even after it finished the LED on the writer continued 
flashing red... Only after I performed a read access to /cdrom/ it 
stopped. Actually, just wrote a small file to it, did a sync, sync 
returned, LED is flashing red. Now I cannot stop it by reading. Only 
unmounting it helped.

> Does the drive have the latest firmware? If not, a firmware upgrade 
> might help.

Yeah, seems to be. But, likely, unusable for me - I don't have Windows at 
home. Don't know how relevant that BIOS upgrade would be. Here's comment 
from the BenQ site:

<quote>

Firmware Update

Changes:

1. Fix misjudgement for 8cm CD-R disc.
2. Solution for CD Extra reading issue.
3. Enable quality test function on CD-DVD Speed v3.x.

YQS.zip  	 143 KB  	Version: Y.QS 	 01-10-2004 	

Changes:

Added solution for disc auto-play function in Windows XP SP2.

YRS.zip  	 143 KB  	Version: Y.RS 	 11-11-2004

</quote>

Besides, it works under 2.6.12-rc5...

> Does it work if you use ide-scsi instead of ide-cd?

No. I get

# mount ./pktcdvd0 /cdrom -t udf -o rw,noatime
pktcdvd: inserted media is CD-RW
pktcdvd: Fixed packets, 32 blocks, Mode-2 disc
pktcdvd: Max. media speed: 10
pktcdvd: write speed 10x
pktcdvd: 590528kB available on disc
UDF-fs: No partition found (1)
mount: wrong fs type, bad option, bad superblock on ./pktcdvd0,
       missing codepage or other error
       In some cases useful info is found in syslog - try
       dmesg | tail  or so

> What errors do you get if you try to burn at 52x without using the
> packet writing driver?

Well, to compare packet / "normal" I just tried the same CD-RW with 
cdrecord as /dev/hdc at the same speed 10 (max for this CD) - it worked.

Thanks
Guennadi
---
Guennadi Liakhovetski

Re: [2.6.13] pktcdvd: IO-errors

[Peter Osterlund]

Guennadi Liakhovetski <g.liakhovetski@gmx.de> writes:

> On Sun, 25 Sep 2005, Peter Osterlund wrote:
> 
> > Guennadi Liakhovetski <g.liakhovetski@gmx.de> writes:
> > 
> > > Just tried pktcdvd on 2.6.13.1. The setup went fine:
...
> > > But, as I tried to copy some files to the CD-RW, it first went ok, but 
> > > then produced the following:
> > > 
> > > 20:41:01: ide-cd: cmd 0x2a timed out
> > > 		      ^^^^	---------> write10
> > > 20:41:01: hdc: DMA timeout retry
> > > 20:41:01: hdc: timeout waiting for DMA
...
> > > the "cp" finished earlier, I did a sync, and it also finished. The good 
> > > parts - no Oops, no process stuck in "D", tha bad parts - it didn't 
> > > work:-), the IDE LED stays on and I cannot eject the CD. The CD-R is a 
> > > BenQ 52x32x52 Seamless Link alone on ide1, the disk does indeed say 
> > > 4x-10x. The cd-writer works mostly... if I am gentle to it - I usually 
> > > burn at 32x even if the media says 52x... Is it just a hw-failure or a 
> > > driver bug?
> > 
> > Did it ever work with this hardware, for example using 2.6.12?
> 
> It was the first time I ever tried it. Now as you asked I also tried 
> 2.6.12-rc5. Surprise, surprise - it worked... But very strange. First, I 
> did
> 
> # time cp -a source /cdrom/ ; time sync
> 
> It took a few minutes to copy 190MB, but it finished successfully. Now to 
> the strange things: even after it finished the LED on the writer continued 
> flashing red... Only after I performed a read access to /cdrom/ it 
> stopped. Actually, just wrote a small file to it, did a sync, sync 
> returned, LED is flashing red. Now I cannot stop it by reading. Only 
> unmounting it helped.
...
> Besides, it works under 2.6.12-rc5...

What gcc versions were used when compiling the kernels? (Boot both
kernels, run "cat /proc/version" to find out.)

I just discovered that the driver doesn't work correctly on my laptop
if I use "gcc version 4.0.1 20050727 (Red Hat 4.0.1-5)" from Fedora
Core 4. "pktsetup 0 /dev/hdc ; cat /proc/driver/pktcdvd/pktcdvd0"
OOPSes. If I use gcc32 it does seem to work though.

-- 
Peter Osterlund - petero2@telia.com
http://web.telia.com/~u89404340

Re: [2.6.13] pktcdvd: IO-errors

[Guennadi Liakhovetski]

On Mon, 26 Sep 2005, Peter Osterlund wrote:

> Guennadi Liakhovetski <g.liakhovetski@gmx.de> writes:
> 
> > Besides, it works under 2.6.12-rc5...
> 
> What gcc versions were used when compiling the kernels? (Boot both
> kernels, run "cat /proc/version" to find out.)

Well, they are somewhat different:

Linux version 2.6.12-rc5 (lyakh@poirot.grange) (gcc version 3.3.4 (Debian 
1:3.3.4-13)) #1 Sun May 29 22:53:31 CEST 2005

Linux version 2.6.13.1 (lyakh@poirot.grange) (gcc version 3.3.5 (Debian 
1:3.3.5-13)) #1 Sat Sep 17 11:57:51 CEST 2005

... No gcc-4.0, but still - 3.3.4 and 3.3.5... I could try recompiling 
2.6.12 with 3.3.5... Do you REALLY believe it could be the reason?

> I just discovered that the driver doesn't work correctly on my laptop
> if I use "gcc version 4.0.1 20050727 (Red Hat 4.0.1-5)" from Fedora
> Core 4. "pktsetup 0 /dev/hdc ; cat /proc/driver/pktcdvd/pktcdvd0"
> OOPSes. If I use gcc32 it does seem to work though.

Doesn't Oops for me under 2.6.13.1 compiled with 3.3.5, that's where I get 
errors.

Thanks
Guennadi
---
Guennadi Liakhovetski

Re: [2.6.13] pktcdvd: IO-errors

[Peter Osterlund]

Guennadi Liakhovetski <g.liakhovetski@gmx.de> writes:

> On Mon, 26 Sep 2005, Peter Osterlund wrote:
> 
> > Guennadi Liakhovetski <g.liakhovetski@gmx.de> writes:
> > 
> > > Besides, it works under 2.6.12-rc5...
> > 
> > What gcc versions were used when compiling the kernels? (Boot both
> > kernels, run "cat /proc/version" to find out.)
> 
> Well, they are somewhat different:
> 
> Linux version 2.6.12-rc5 (lyakh@poirot.grange) (gcc version 3.3.4 (Debian 
> 1:3.3.4-13)) #1 Sun May 29 22:53:31 CEST 2005
> 
> Linux version 2.6.13.1 (lyakh@poirot.grange) (gcc version 3.3.5 (Debian 
> 1:3.3.5-13)) #1 Sat Sep 17 11:57:51 CEST 2005
> 
> ... No gcc-4.0, but still - 3.3.4 and 3.3.5... I could try recompiling 
> 2.6.12 with 3.3.5... Do you REALLY believe it could be the reason?

No, not 3.3.4 vs 3.3.5.

> > I just discovered that the driver doesn't work correctly on my laptop
> > if I use "gcc version 4.0.1 20050727 (Red Hat 4.0.1-5)" from Fedora
> > Core 4. "pktsetup 0 /dev/hdc ; cat /proc/driver/pktcdvd/pktcdvd0"
> > OOPSes. If I use gcc32 it does seem to work though.
> 
> Doesn't Oops for me under 2.6.13.1 compiled with 3.3.5, that's where I get 
> errors.

OK. Another option since you have one good and one bad kernel, is to
try to find the point in time where it broke. If you are a git user,
you can use the "git bisect" method. If not, you can use -rc releases
from ftp.kernel.org.

-- 
Peter Osterlund - petero2@telia.com
http://web.telia.com/~u89404340

Re: [2.6.13] pktcdvd: IO-errors

[Guennadi Liakhovetski]

On Mon, 26 Sep 2005, Peter Osterlund wrote:

> OK. Another option since you have one good and one bad kernel, is to
> try to find the point in time where it broke. If you are a git user,

No, I am not.

> you can use the "git bisect" method. If not, you can use -rc releases
> from ftp.kernel.org.

I think, I have an easier test - I just replaced the pktcdvd.[hc] in 
2.6.13.1 with respective files from 2.6.12, and it worked. The diff is 
pretty small, so, it should be possible to actually find the culprit 
there. E.g., here's the comment, that came in with 2.6.13:

- * - Optimize for throughput at the expense of latency. This means that streaming
- *   writes will never be interrupted by a read, but if the drive has to seek
- *   before the next write, switch to reading instead if there are any pending
- *   read requests.

In the worst case, one could just reverse the patch for 2.6.14 and until a 
solution to the problem is found.

Thanks
Guennadi
---
Guennadi Liakhovetski

Re: [2.6.13] pktcdvd: IO-errors

[Peter Osterlund]

Guennadi Liakhovetski <g.liakhovetski@gmx.de> writes:

> On Mon, 26 Sep 2005, Peter Osterlund wrote:
> 
> > OK. Another option since you have one good and one bad kernel, is to
> > try to find the point in time where it broke. If you are a git user,
> 
> No, I am not.
> 
> > you can use the "git bisect" method. If not, you can use -rc releases
> > from ftp.kernel.org.
> 
> I think, I have an easier test - I just replaced the pktcdvd.[hc] in 
> 2.6.13.1 with respective files from 2.6.12, and it worked. The diff is 
> pretty small, so, it should be possible to actually find the culprit 
> there. E.g., here's the comment, that came in with 2.6.13:
> 
> - * - Optimize for throughput at the expense of latency. This means that streaming
> - *   writes will never be interrupted by a read, but if the drive has to seek
> - *   before the next write, switch to reading instead if there are any pending
> - *   read requests.

That's quite disturbing unfortunately.

The driver works by sending reads, writes, and synchronize cache
commands to the real CD/DVD driver, which then forwards them to the
drive firmware. Except during startup, the driver will send one or
more read requests, followed by one or more write requests, followed
by exactly one synchronize cache request, and then start over with
read requests.

That patch changes the logic that decides when the driver should
change between reading and writing. However, the read/write/sync
sequence that makes your drive fail in 2.6.13 could theoretically
happen in 2.6.12 as well if you are unlucky.

I think some trial and error will be required to figure out what
causes your drive to fail. If you apply this patch to 2.6.12, does it
still work?

--- a/drivers/block/pktcdvd.c
+++ b/drivers/block/pktcdvd.c
@@ -2131,7 +2131,7 @@ static int pkt_make_request(request_queu
 		cloned_bio->bi_private = psd;
 		cloned_bio->bi_end_io = pkt_end_io_read_cloned;
 		pd->stats.secs_r += bio->bi_size >> 9;
-		pkt_queue_bio(pd, cloned_bio, 1);
+		pkt_queue_bio(pd, cloned_bio, 0);
 		return 0;
 	}
 

-- 
Peter Osterlund - petero2@telia.com
http://web.telia.com/~u89404340

Re: [2.6.13] pktcdvd: IO-errors

[Guennadi Liakhovetski]

On Wed, 28 Sep 2005, Peter Osterlund wrote:

> That patch changes the logic that decides when the driver should
> change between reading and writing. However, the read/write/sync
> sequence that makes your drive fail in 2.6.13 could theoretically
> happen in 2.6.12 as well if you are unlucky.

Well, I didn't test it extensively - it was the first time I tried it 
under 2.6.13.

> I think some trial and error will be required to figure out what
> causes your drive to fail. If you apply this patch to 2.6.12, does it
> still work?

Yes, it does...

Thanks
Guennadi
---
Guennadi Liakhovetski

Re: [2.6.13] pktcdvd: IO-errors

[Peter Osterlund]

Guennadi Liakhovetski <g.liakhovetski@gmx.de> writes:

> On Wed, 28 Sep 2005, Peter Osterlund wrote:
> 
> > That patch changes the logic that decides when the driver should
> > change between reading and writing. However, the read/write/sync
> > sequence that makes your drive fail in 2.6.13 could theoretically
> > happen in 2.6.12 as well if you are unlucky.
> 
> Well, I didn't test it extensively - it was the first time I tried it 
> under 2.6.13.
> 
> > I think some trial and error will be required to figure out what
> > causes your drive to fail. If you apply this patch to 2.6.12, does it
> > still work?
> 
> Yes, it does...

OK, in that case this patch for 2.6.12 should work as well, because
all it does compared to the previous patch is to remove the now unused
high_prio_read variables. Can you confirm that it works?

(Continue reading, more after this patch.)

diff --git a/drivers/block/pktcdvd.c b/drivers/block/pktcdvd.c
--- a/drivers/block/pktcdvd.c
+++ b/drivers/block/pktcdvd.c
@@ -467,14 +467,12 @@ static int pkt_set_speed(struct pktcdvd_
  * Queue a bio for processing by the low-level CD device. Must be called
  * from process context.
  */
-static void pkt_queue_bio(struct pktcdvd_device *pd, struct bio *bio, int high_prio_read)
+static void pkt_queue_bio(struct pktcdvd_device *pd, struct bio *bio)
 {
 	spin_lock(&pd->iosched.lock);
 	if (bio_data_dir(bio) == READ) {
 		pkt_add_list_last(bio, &pd->iosched.read_queue,
 				  &pd->iosched.read_queue_tail);
-		if (high_prio_read)
-			pd->iosched.high_prio_read = 1;
 	} else {
 		pkt_add_list_last(bio, &pd->iosched.write_queue,
 				  &pd->iosched.write_queue_tail);
@@ -490,15 +488,16 @@ static void pkt_queue_bio(struct pktcdvd
  * requirements for CDRW drives:
  * - A cache flush command must be inserted before a read request if the
  *   previous request was a write.
- * - Switching between reading and writing is slow, so don't it more often
+ * - Switching between reading and writing is slow, so don't do it more often
  *   than necessary.
+ * - Optimize for throughput at the expense of latency. This means that streaming
+ *   writes will never be interrupted by a read, but if the drive has to seek
+ *   before the next write, switch to reading instead if there are any pending
+ *   read requests.
  * - Set the read speed according to current usage pattern. When only reading
  *   from the device, it's best to use the highest possible read speed, but
  *   when switching often between reading and writing, it's better to have the
  *   same read and write speeds.
- * - Reads originating from user space should have higher priority than reads
- *   originating from pkt_gather_data, because some process is usually waiting
- *   on reads of the first kind.
  */
 static void pkt_iosched_process_queue(struct pktcdvd_device *pd)
 {
@@ -512,21 +511,18 @@ static void pkt_iosched_process_queue(st
 
 	for (;;) {
 		struct bio *bio;
-		int reads_queued, writes_queued, high_prio_read;
+		int reads_queued, writes_queued;
 
 		spin_lock(&pd->iosched.lock);
 		reads_queued = (pd->iosched.read_queue != NULL);
 		writes_queued = (pd->iosched.write_queue != NULL);
-		if (!reads_queued)
-			pd->iosched.high_prio_read = 0;
-		high_prio_read = pd->iosched.high_prio_read;
 		spin_unlock(&pd->iosched.lock);
 
 		if (!reads_queued && !writes_queued)
 			break;
 
 		if (pd->iosched.writing) {
-			if (high_prio_read || (!writes_queued && reads_queued)) {
+			if (!writes_queued && reads_queued) {
 				if (atomic_read(&pd->cdrw.pending_bios) > 0) {
 					VPRINTK("pktcdvd: write, waiting\n");
 					break;
@@ -559,8 +555,9 @@ static void pkt_iosched_process_queue(st
 
 		if (bio_data_dir(bio) == READ)
 			pd->iosched.successive_reads += bio->bi_size >> 10;
-		else
+		else {
 			pd->iosched.successive_reads = 0;
+		}
 		if (pd->iosched.successive_reads >= HI_SPEED_SWITCH) {
 			if (pd->read_speed == pd->write_speed) {
 				pd->read_speed = MAX_SPEED;
@@ -765,7 +762,7 @@ static void pkt_gather_data(struct pktcd
 
 		atomic_inc(&pkt->io_wait);
 		bio->bi_rw = READ;
-		pkt_queue_bio(pd, bio, 0);
+		pkt_queue_bio(pd, bio);
 		frames_read++;
 	}
 
@@ -1062,7 +1059,7 @@ static void pkt_start_write(struct pktcd
 
 	atomic_set(&pkt->io_wait, 1);
 	pkt->w_bio->bi_rw = WRITE;
-	pkt_queue_bio(pd, pkt->w_bio, 0);
+	pkt_queue_bio(pd, pkt->w_bio);
 }
 
 static void pkt_finish_packet(struct packet_data *pkt, int uptodate)
@@ -2120,7 +2117,7 @@ static int pkt_make_request(request_queu
 		cloned_bio->bi_private = psd;
 		cloned_bio->bi_end_io = pkt_end_io_read_cloned;
 		pd->stats.secs_r += bio->bi_size >> 9;
-		pkt_queue_bio(pd, cloned_bio, 1);
+		pkt_queue_bio(pd, cloned_bio);
 		return 0;
 	}
 
diff --git a/include/linux/pktcdvd.h b/include/linux/pktcdvd.h
--- a/include/linux/pktcdvd.h
+++ b/include/linux/pktcdvd.h
@@ -159,7 +159,6 @@ struct packet_iosched
 	struct bio		*read_queue_tail;
 	struct bio		*write_queue;
 	struct bio		*write_queue_tail;
-	int			high_prio_read;	/* An important read request has been queued */
 	int			successive_reads;
 };
 

With that patch for 2.6.12, the diff compared to 2.6.13 now looks like
below. Can you confirm that reverse applying this patch for 2.6.13
also works?

--- linux-2612/drivers/block/pktcdvd.c	2005-10-02 13:52:22.000000000 +0200
+++ /home/petero/ftp/kernel/2.6/linux/drivers/block/pktcdvd.c	2005-10-01 13:31:50.000000000 +0200
@@ -522,7 +522,13 @@
 			break;
 
 		if (pd->iosched.writing) {
-			if (!writes_queued && reads_queued) {
+			int need_write_seek = 1;
+			spin_lock(&pd->iosched.lock);
+			bio = pd->iosched.write_queue;
+			spin_unlock(&pd->iosched.lock);
+			if (bio && (bio->bi_sector == pd->iosched.last_write))
+				need_write_seek = 0;
+			if (need_write_seek && reads_queued) {
 				if (atomic_read(&pd->cdrw.pending_bios) > 0) {
 					VPRINTK("pktcdvd: write, waiting\n");
 					break;
@@ -557,6 +563,7 @@
 			pd->iosched.successive_reads += bio->bi_size >> 10;
 		else {
 			pd->iosched.successive_reads = 0;
+			pd->iosched.last_write = bio->bi_sector + bio_sectors(bio);
 		}
 		if (pd->iosched.successive_reads >= HI_SPEED_SWITCH) {
 			if (pd->read_speed == pd->write_speed) {
@@ -1244,8 +1251,7 @@
 			VPRINTK("kcdrwd: wake up\n");
 
 			/* make swsusp happy with our thread */
-			if (current->flags & PF_FREEZE)
-				refrigerator(PF_FREEZE);
+			try_to_freeze();
 
 			list_for_each_entry(pkt, &pd->cdrw.pkt_active_list, list) {
 				if (!pkt->sleep_time)
--- linux-2612/include/linux/pktcdvd.h	2005-10-02 13:47:21.000000000 +0200
+++ /home/petero/ftp/kernel/2.6/linux/include/linux/pktcdvd.h	2005-10-01 13:32:08.000000000 +0200
@@ -159,6 +159,7 @@
 	struct bio		*read_queue_tail;
 	struct bio		*write_queue;
 	struct bio		*write_queue_tail;
+	sector_t		last_write;	/* The sector where the last write ended */
 	int			successive_reads;
 };
 

-- 
Peter Osterlund - petero2@telia.com
http://web.telia.com/~u89404340

Re: [2.6.13] pktcdvd: IO-errors

[Guennadi Liakhovetski]

On Sun, 2 Oct 2005, Peter Osterlund wrote:

> OK, in that case this patch for 2.6.12 should work as well, because
> all it does compared to the previous patch is to remove the now unused
> high_prio_read variables. Can you confirm that it works?

Sorry, Peter, was away for a week. Just came back late today, will re-test 
asap and report back.

Regards
Guennadi
---
Guennadi Liakhovetski

Re: [2.6.13] pktcdvd: IO-errors

[Guennadi Liakhovetski]

On Sun, 2 Oct 2005, Peter Osterlund wrote:

> OK, in that case this patch for 2.6.12 should work as well, because
> all it does compared to the previous patch is to remove the now unused
> high_prio_read variables. Can you confirm that it works?

Yes, it does.

> With that patch for 2.6.12, the diff compared to 2.6.13 now looks like
> below. Can you confirm that reverse applying this patch for 2.6.13
> also works?

Well, I am testing always with 2.6.13 kernel, just replacing the pktcdvd 
driver sources. So, I just checked that 2.6.13 - your 2nd patch from the 
last email == 2.6.12 + 1st patch from the same email ( + trivial 
refrigerator() call compile-fix), so, we may save us this test.

Thanks
Guennadi
---
Guennadi Liakhovetski

Re: [2.6.13] pktcdvd: IO-errors

[Peter Osterlund]

Guennadi Liakhovetski <g.liakhovetski@gmx.de> writes:

> On Sun, 2 Oct 2005, Peter Osterlund wrote:
> 
> > OK, in that case this patch for 2.6.12 should work as well, because
> > all it does compared to the previous patch is to remove the now unused
> > high_prio_read variables. Can you confirm that it works?
> 
> Yes, it does.

In that case, this patch should also work. Does it?

diff --git a/drivers/block/pktcdvd.c b/drivers/block/pktcdvd.c
index d4b9c17..cb6bda9 100644
--- a/drivers/block/pktcdvd.c
+++ b/drivers/block/pktcdvd.c
@@ -538,7 +538,7 @@ static void pkt_iosched_process_queue(st
 			spin_unlock(&pd->iosched.lock);
 			if (bio && (bio->bi_sector == pd->iosched.last_write))
 				need_write_seek = 0;
-			if (need_write_seek && reads_queued) {
+			if (!writes_queued && reads_queued) {
 				if (atomic_read(&pd->cdrw.pending_bios) > 0) {
 					VPRINTK("pktcdvd: write, waiting\n");
 					break;

-- 
Peter Osterlund - petero2@telia.com
http://web.telia.com/~u89404340

Re: [2.6.13] pktcdvd: IO-errors

[Guennadi Liakhovetski]

On Sun, 9 Oct 2005, Peter Osterlund wrote:

> In that case, this patch should also work. Does it?

This is to 2.6.13, right?

Thanks
Guennadi

> diff --git a/drivers/block/pktcdvd.c b/drivers/block/pktcdvd.c
> index d4b9c17..cb6bda9 100644
> --- a/drivers/block/pktcdvd.c
> +++ b/drivers/block/pktcdvd.c
> @@ -538,7 +538,7 @@ static void pkt_iosched_process_queue(st
>  			spin_unlock(&pd->iosched.lock);
>  			if (bio && (bio->bi_sector == pd->iosched.last_write))
>  				need_write_seek = 0;
> -			if (need_write_seek && reads_queued) {
> +			if (!writes_queued && reads_queued) {
>  				if (atomic_read(&pd->cdrw.pending_bios) > 0) {
>  					VPRINTK("pktcdvd: write, waiting\n");
>  					break;
> 
---
Guennadi Liakhovetski

Re: [2.6.13] pktcdvd: IO-errors

[Guennadi Liakhovetski]

On Sun, 9 Oct 2005, Peter Osterlund wrote:

> Guennadi Liakhovetski <g.liakhovetski@gmx.de> writes:
> 
> > On Sun, 2 Oct 2005, Peter Osterlund wrote:
> > 
> > > OK, in that case this patch for 2.6.12 should work as well, because
> > > all it does compared to the previous patch is to remove the now unused
> > > high_prio_read variables. Can you confirm that it works?
> > 
> > Yes, it does.
> 
> In that case, this patch should also work. Does it?

Yes. 2.6.13 + this patch work for me.

Thanks
Guennadi

> 
> diff --git a/drivers/block/pktcdvd.c b/drivers/block/pktcdvd.c
> index d4b9c17..cb6bda9 100644
> --- a/drivers/block/pktcdvd.c
> +++ b/drivers/block/pktcdvd.c
> @@ -538,7 +538,7 @@ static void pkt_iosched_process_queue(st
>  			spin_unlock(&pd->iosched.lock);
>  			if (bio && (bio->bi_sector == pd->iosched.last_write))
>  				need_write_seek = 0;
> -			if (need_write_seek && reads_queued) {
> +			if (!writes_queued && reads_queued) {
>  				if (atomic_read(&pd->cdrw.pending_bios) > 0) {
>  					VPRINTK("pktcdvd: write, waiting\n");
>  					break;
> 
> -- 
> Peter Osterlund - petero2@telia.com
> http://web.telia.com/~u89404340
> 

---
Guennadi Liakhovetski

Re: [2.6.13] pktcdvd: IO-errors

[Guennadi Liakhovetski]

On Mon, 10 Oct 2005, Guennadi Liakhovetski wrote:

> On Sun, 9 Oct 2005, Peter Osterlund wrote:
> 
> > In that case, this patch should also work. Does it?
> 
> Yes. 2.6.13 + this patch work for me.

Oops... Things are getting out of control here... A more extensive test of 
your patch produced the same error again... I'll redo tests with your 
previous patches more thoroughly... This will take some time though.

Thanks
Guennadi
---
Guennadi Liakhovetski

Re: [2.6.13] pktcdvd: IO-errors

[Guennadi Liakhovetski]

On Sun, 9 Oct 2005, Peter Osterlund wrote:

> In that case, this patch should also work. Does it?
> 
> diff --git a/drivers/block/pktcdvd.c b/drivers/block/pktcdvd.c
> index d4b9c17..cb6bda9 100644
> --- a/drivers/block/pktcdvd.c
> +++ b/drivers/block/pktcdvd.c
> @@ -538,7 +538,7 @@ static void pkt_iosched_process_queue(st
>  			spin_unlock(&pd->iosched.lock);
>  			if (bio && (bio->bi_sector == pd->iosched.last_write))
>  				need_write_seek = 0;
> -			if (need_write_seek && reads_queued) {
> +			if (!writes_queued && reads_queued) {
>  				if (atomic_read(&pd->cdrw.pending_bios) > 0) {
>  					VPRINTK("pktcdvd: write, waiting\n");
>  					break;
> 

Well, I've had this patch (to 2.6.13) failing once, whereas I still 
haven't been able to reproduce the error with your previous patch. What 
now? A bit worrying is that test results are not 100% deterministic now... 
Which means, until recently my standard test (copy about 150M co the 
CD-RW && sync) produced always consistent results, now I've seen a couple 
of times the same driver version either failing or succeeding...

BTW, Peter, I still get errors from mails to you:

<petero2@telia.com>:
81.228.8.84_does_not_like_recipient./Remote_host_said:_553_RCPT_TO:<petero2@telia.com>_refused/G
iving_up_on_81.228.8.84./


Thanks
Guennadi
---
Guennadi Liakhovetski

Re: [2.6.13] pktcdvd: IO-errors

[Peter Osterlund]

Guennadi Liakhovetski <g.liakhovetski@gmx.de> writes:

> On Sun, 9 Oct 2005, Peter Osterlund wrote:
> 
> > In that case, this patch should also work. Does it?
> > 
> > diff --git a/drivers/block/pktcdvd.c b/drivers/block/pktcdvd.c
> > index d4b9c17..cb6bda9 100644
> > --- a/drivers/block/pktcdvd.c
> > +++ b/drivers/block/pktcdvd.c
> > @@ -538,7 +538,7 @@ static void pkt_iosched_process_queue(st
> >  			spin_unlock(&pd->iosched.lock);
> >  			if (bio && (bio->bi_sector == pd->iosched.last_write))
> >  				need_write_seek = 0;
> > -			if (need_write_seek && reads_queued) {
> > +			if (!writes_queued && reads_queued) {
> >  				if (atomic_read(&pd->cdrw.pending_bios) > 0) {
> >  					VPRINTK("pktcdvd: write, waiting\n");
> >  					break;
> 
> Well, I've had this patch (to 2.6.13) failing once, whereas I still 
> haven't been able to reproduce the error with your previous patch. What 
> now? A bit worrying is that test results are not 100% deterministic now... 
> Which means, until recently my standard test (copy about 150M co the 
> CD-RW && sync) produced always consistent results, now I've seen a couple 
> of times the same driver version either failing or succeeding...

My current theory is that there is something wrong with the firmware
or hardware in your drive, and different I/O patterns have different
probabilities of triggering this problem.

Maybe you could use Jens' IO tracing patch to identify the sequence of
commands that make the drive fail. See subject "[PATCH] Block device
io tracing" posted by Jens earlier today.

If the problem is always caused by some well defined sequence of
commands, it might be possible to implement a workaround in the
pktcdvd driver.

> BTW, Peter, I still get errors from mails to you:
> 
> <petero2@telia.com>:
> 81.228.8.84_does_not_like_recipient./Remote_host_said:_553_RCPT_TO:<petero2@telia.com>_refused/G
> iving_up_on_81.228.8.84./

It seems like my ISPs mail server doesn't want to talk to your mail
server. I have no idea why. I did get mails from you earlier.

-- 
Peter Osterlund - petero2@telia.com
http://web.telia.com/~u89404340

Re: [2.6.13] pktcdvd: IO-errors

[Peter Osterlund]

Peter Osterlund <petero2@telia.com> writes:

> Guennadi Liakhovetski <g.liakhovetski@gmx.de> writes:
> 
> > Well, I've had this patch (to 2.6.13) failing once, whereas I still 
> > haven't been able to reproduce the error with your previous patch. What 
> > now? A bit worrying is that test results are not 100% deterministic now... 
> > Which means, until recently my standard test (copy about 150M co the 
> > CD-RW && sync) produced always consistent results, now I've seen a couple 
> > of times the same driver version either failing or succeeding...
> 
> My current theory is that there is something wrong with the firmware
> or hardware in your drive, and different I/O patterns have different
> probabilities of triggering this problem.
> 
> Maybe you could use Jens' IO tracing patch to identify the sequence of
> commands that make the drive fail. See subject "[PATCH] Block device
> io tracing" posted by Jens earlier today.
> 
> If the problem is always caused by some well defined sequence of
> commands, it might be possible to implement a workaround in the
> pktcdvd driver.

I have found a problem on one of my drives. On my FC4 system, hald and
kded are constantly doing something with the drive, and this makes it
fail when I try to do packet writing. Killing those processes make
that drive work correctly. Maybe this helps in your case too. Try
packet writing from single user mode to see if it helps.

I don't know yet how to make hald and kded stay away from the drive
while packet writing is in progress.

-- 
Peter Osterlund - petero2@telia.com
http://web.telia.com/~u89404340

Re: [2.6.13] pktcdvd: IO-errors

[Guennadi Liakhovetski]

On Sat, 15 Oct 2005, Peter Osterlund wrote:

> I have found a problem on one of my drives. On my FC4 system, hald and
> kded are constantly doing something with the drive, and this makes it
> fail when I try to do packet writing. Killing those processes make
> that drive work correctly. Maybe this helps in your case too. Try
> packet writing from single user mode to see if it helps.

Sell, it's Sarge here, so, I doubt there's something similar running, but 
I'll verify it anyway. Also, booting into S has another side effect on the 
system - lower background load, fewer context switches...

Thanks
Guennadi
---
Guennadi Liakhovetski