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
Guennadi Liakhovetski <[email protected]> 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 - [email protected]
http://web.telia.com/~u89404340
On Sun, 25 Sep 2005, Peter Osterlund wrote:
> Guennadi Liakhovetski <[email protected]> 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
Guennadi Liakhovetski <[email protected]> writes:
> On Sun, 25 Sep 2005, Peter Osterlund wrote:
>
> > Guennadi Liakhovetski <[email protected]> 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 - [email protected]
http://web.telia.com/~u89404340
On Mon, 26 Sep 2005, Peter Osterlund wrote:
> Guennadi Liakhovetski <[email protected]> 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 ([email protected]) (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 ([email protected]) (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
Guennadi Liakhovetski <[email protected]> writes:
> On Mon, 26 Sep 2005, Peter Osterlund wrote:
>
> > Guennadi Liakhovetski <[email protected]> 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 ([email protected]) (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 ([email protected]) (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 - [email protected]
http://web.telia.com/~u89404340
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
Guennadi Liakhovetski <[email protected]> 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 - [email protected]
http://web.telia.com/~u89404340
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
Guennadi Liakhovetski <[email protected]> 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 - [email protected]
http://web.telia.com/~u89404340
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
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
Guennadi Liakhovetski <[email protected]> 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 - [email protected]
http://web.telia.com/~u89404340
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
On Sun, 9 Oct 2005, Peter Osterlund wrote:
> Guennadi Liakhovetski <[email protected]> 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 - [email protected]
> http://web.telia.com/~u89404340
>
---
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
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:
<[email protected]>:
81.228.8.84_does_not_like_recipient./Remote_host_said:_553_RCPT_TO:<[email protected]>_refused/G
iving_up_on_81.228.8.84./
Thanks
Guennadi
---
Guennadi Liakhovetski
Guennadi Liakhovetski <[email protected]> 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:
>
> <[email protected]>:
> 81.228.8.84_does_not_like_recipient./Remote_host_said:_553_RCPT_TO:<[email protected]>_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 - [email protected]
http://web.telia.com/~u89404340
Peter Osterlund <[email protected]> writes:
> Guennadi Liakhovetski <[email protected]> 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 - [email protected]
http://web.telia.com/~u89404340
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