Bug 397141

  Forgot to include the important info that both I and my father are using
identical Sony DW-G120A DVD RW drives (firmware version MYR5, no firmware update
available) purchased less than a year ago.

  Additionally, we were using these same drives 6 months ago, when F7 came out.
 So in my case, I was checking those old unpadded discs with the same drive, so
the fact that they all passed back then, with this drive, but not now, indicates
that there really is an OS regression, not just a failure to take this
particular drive into account.

  I took my unpadded but otherwise good FC4 disc 1, and did a mediacheck on it
after booting from each of several recent install DVDs.

Fedora 7 DVD:                                passes
Fedura Unity 20070912 7 DVD:  passes
Fedora 7.92 (F8t3) DVD:              fails
Fedora 8 DVD:                                fails

So it appears the problem came back sometime in September.  I don't happen to
have a F8 test 1 or 2 DVD, but could download and test it if really necessary.

  One more data point:

Fedora Unity 20071030 7 DVD:     fails

FU7 20070912 shipped with kernel-2.6.22.5-76.fc7, and FU7 20071030 shipped with
kernel-2.6.23.1-10.fc7.  Looking through fedora-package-announce for September
and October, the only F7 kernel updates between these two were

Sep. 25: kernel-2.6.22.7-85.fc7
Sep. 28: kernel-2.6.22.9-91.fc7

so the first F7 kernel to bring back the readahead bug was one of
kernel-2.6.22.7-85.fc7, kernel-2.6.22.9-91.fc7, or kernel-2.6.23.1-10.fc7.

  I downloaded and installed the kernels for F7.90 and F7.91 (F8 test 1 and 2,
resp.).  The former has almost been wiped from the face of the earth, but I was
able to find a copy at ftp.cse.yzu.edu.tw.  That shouldn't happen - all the old
versions should be available.  Anyway, after booting from the F7.90
kernel-2.6.23-0.164.rc5.fc8, and then checking my unpadded disc with
checkisomd5, the mediacheck fails.  I couldn't check F7.91 since the kernel
panicked while booting.  But it seems that the readahead bug had already
returned with F8t1, which was released on August 7.

  Sorry, I should have said "latter", not "former".  The
download.fedora.redhat.com server, and almost all of the mirrors, only have 7.90
and 7.92.

  I had my father, who is running a fully updated F7, install the
anaconda-runtime package, and then use checkisomd5 to check his unpadded
purchased F8 DVD, which he could not read near the end due to the readahead bug
affecting the kernel he's currently running.  Oddly, the mediacheck passed.  I
have no explanation for this.

  Still broken in kernel-2.6.23.8-63.fc8.

  Still broken in kernel-2.6.23.9-85.fc8.  This time, though, when trying to use
rawread to read my unpadded FC4 disc 1, it was able to read 665419776 out of
665434112 bytes, whereas the two previous F8 kernels both failed at 665305088
bytes.  Has the relevant kernel code changed?

  Still broken in kernel-2.6.23.14-107.fc8.  The number of bytes it can read
from the unpadded FC4 disc 1 has gone back to 665305088.

Could the priority on this be raised?  There appears to be no interest currently
in fixing this.  Considering that it WAS fixed when F7 came out, it shouldn't be
too hard for someone familiar with the relevant code to discover what went
wrong, assuming it was around 2.6.23.  And mediacheck failures won't be taken
seriously until well after this is fixed, since the bug has existed for almost
the entire time mediacheck has, and people have been trained to ignore failures
and install anyway.  

I have no other reports, no way to duplicate it and no plausible code changes to
explain it so at the moment the priority for this bug is very low.

  Following the advice in the following post

http://www.mail-archive.com/cdwrite@other.debian.org/msg11444.html

I ran the command

[root@localhost ~]# blockdev --setra 0 /dev/dvd

to change the default readahead from 256 to 0, and then ran the rawread command
again on the same disc.  This time, it read 665432064 bytes instead of 665305088
(the read is also much slower), but still failed near the end.  Unfortunately,
most of the discussion on that thread is over my head, so I don't know if this
is helpful or not.  I know the bug is reproducible with a Sony DRU-120C DVD
drive and an unpadded Fedora CD burned in TAO mode, so I would be willing to buy
one of these drives and have it shipped to someone qualified to diagnose the
bug, if a listing turns up on Ebay (I bought mine in 12/2006 and I don't think
they are sold anymore).

I downloaded Fedora-9-Alpha-i386-DVD.iso and burned this ISO, unpadded, to both
a DVD+R and a DVD+RW using the command

growisofs -dvd-compat -speed=1 -Z /dev/dvd=Fedora-9-Alpha-i386-DVD.iso

and then checked each using the command

rawread /dev/dvd | sha1sum

while running F8.  To my surprise, both discs checked properly.  Then I
downloaded Fedora-9-Alpha-i386-rescuecd.iso and burned this ISO, unpadded, to a
CD-RW using the command

wodim -v dev=/dev/cdrom blank=fast driveropts=burnfree
Fedora-9-Alpha-i386-rescuecd.iso

and to a CD-R using the command

wodim -v dev=/dev/cdrom driveropts=burnfree Fedora-9-Alpha-i386-rescuecd.iso

and checked each using the command

rawread /dev/cdrom | sha1sum

In both cases, the read failed shortly before the end.  With the CD-RW, it read
117452800 out of 117508096 bytes.  With the CD-R, it read 117424128 bytes.  In
both cases, writing the partial reads to a file, using wget -c to complete them,
and sha1sum to check them, shows that the partial reads are correct up to the
cutoff point.

So to reproduce this bug, one should burn an unpadded ISO to a CD using one of
the above commands, then check it using rawread with a >= 2.6.23 kernel and a CD
or DVD drive known to have been vulnerable to the readahead bug before F7.  The
bug doesn't seem to affect DVDs.

Correction - I know it affects DVDs, or at least did until recently, since both
unpadded F8 DVDs my father bought online failed mediacheck, but it seems to be
much harder to reproduce, plus a rescue CD image is much smaller so makes it
much easier to burn the disc and reproduce the bug.

  I tried reproducing my father's experience by burning the unpadded F8 DVD ISO
to a DVD+RW, booting from it, and running mediacheck.  It passes for me - which
means that there must be something different about the mass-pressed discs which
is what he probably got.  I tried to do the same with Fedora 9 Alpha, but
unfortunately due to bug #431138, it's impossible to see whether mediacheck
passed or failed.  So currently I can only reproduce the problem with CDs, and
most people never install using these anymore, which may account for the lack of
reports.

Still broken with kernel-2.6.23.14-115.fc8.  With the unpadded FC4 disc, can
read 665419776 out of 665434112 bytes again.  With the Fedora 9 Alpha rescuecd
CD-RW, can read 117489664 out of 117508096 bytes, and with the CD-R, 117424128
bytes, same as the previous kernel.

The fact mass produced disks work is consistent with the bug report. Mass
produced disks have a defined end, CD-R's don't.

I think you misunderstood - the online-purchased F8 DVD my father bought is the
one that failed mediacheck, and also had the failed read near the end.  The
unpadded DVD+R and DVD+RW discs I burned for myself work properly.  I don't
doubt that if I obtained an identical F8 DVD from the same vendor, it would fail
for me as well, since I'm using exactly the same DVD drive as my father.

  I just had my father read the F8 DVD he purchased while running the latest F8
kernel, and the problem still exists for him.  The rawread command fails after
reading 3424710656 out of 3424749568 bytes which is 38912 bytes short of the
end.  If anyone else can reproduce the problem with CDs, then either they could
purchase the same DVD from the same vendor, or since my father has 2 copies of
the same DVD (the vendor sent a second one which failed in the same way), I
could have him send one of the copies to the person's address.

Still broken in kernel-2.6.23.15-137.fc8.

FC4 i386 Disc 1 CD-R: 665419776/665434112 bytes
Fedora 9 Alpha i386 rescuecd CD-RW: 117424128/117508096 bytes (changed)
Fedora 9 Alpha i386 rescuecd CD-R: 117452800/117508096 bytes (changed)

Still broken in kernel-2.6.24.3-12.fc8.

FC4 i386 Disc 1 CD-R: 665305088/665434112 bytes
Fedora 9 Alpha i386 rescuecd CD-RW: 117424128/117508096 bytes
Fedora 9 Alpha i386 rescuecd CD-R: 117424128/117508096 bytes

I noticed that Fedora 9 Alpha was released with CD as well as DVD ISOs.  Will
this also be true for F9 final?  Since this bug manifests more easily with CDs,
it would result in a lot more reports of mediacheck failures, making it more
likely that this would get fixed.  (I never understood why providing CD images
was so difficult, and yes I know about Fedora Unity and jigdo, but those don't
help people who don't already have a working Fedora box.)

Still broken in kernel-2.6.24.3-34.fc8.

FC4 i386 Disc 1 CD-R: 665427968/665434112 bytes
Fedora 9 Alpha i386 rescuecd CD-RW: 117424128/117508096 bytes
Fedora 9 Alpha i386 rescuecd CD-R: 117424128/117508096 bytes

Burned the 6 F9-Beta CD images to CD-RWs in default TAO mode without padding,
using wodim.  Testing them using the original F7 mediacheck, the discs all
failed.  Previously I had only tested F7 using CD-Rs.  So apparently this bug
was not fixed even in F7.  I then tried reburning one disc using DAO mode
without padding, and another using TAO mode with padding.  Both passed.  So
apparently either DAO mode or padding is enough to allow the discs to be read
properly.  I then used rawread to read each of these two discs while running F8,
and both discs could be read properly.

Perhaps bug 444344 is another instance of this

Using the rawread script mentioned above would be the way to tell - if it is,
the read would fail about 100K or less from the end.  (BTW, this method can be
used instead of mediacheck to check burned Fedora discs, without having to
reboot.  Just pipe through sha1sum and compare to the expected value.)

For comparison, bug 440343 is not due to I/O errors.
dmesg is free of such errors. "readcd" can read the burnt
image just fine.

I also find that I cannot use readcd to properly read off the ISO file from a
DVD, even a properly padded one which rawread has no trouble with.  What I get
contains extra data after the end of the actual ISO.  See comments 12 and 13 of
bug #440343.  Could this be related to the readahead bug?

Still broken in F9 with kernel-2.6.25.4-30.fc9.i686.  Changing version to 9.

Still broken in F10 with kernel-2.6.27.5-117.fc10.i686.  Changing Version to 10.  (Should this be made a duplicate of bug #186512?)

I think you are right

*** This bug has been marked as a duplicate of bug 186512 ***