Bug 186512
| Summary: | kernel prevents proper CD checking (mediacheck/install fails) | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Andre Robatino <robatino> | ||||
| Component: | kernel | Assignee: | Peter Martuccelli <peterm> | ||||
| Status: | CLOSED INSUFFICIENT_DATA | QA Contact: | Brian Brock <bbrock> | ||||
| Severity: | high | Docs Contact: | |||||
| Priority: | medium | ||||||
| Version: | 16 | CC: | bughunt, davehorn1, don.mies, dsnillo, jforbes, kernel-maint, paul, pmiehe, s.clement, triage, wtogami | ||||
| Target Milestone: | --- | Keywords: | Triaged | ||||
| Target Release: | --- | ||||||
| Hardware: | All | ||||||
| OS: | Linux | ||||||
| Whiteboard: | bzcl34nup | ||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2012-11-14 16:36:48 UTC | Type: | --- | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Attachments: |
|
||||||
|
Description
Andre Robatino
2006-03-23 23:37:02 UTC
Some additional information that might be of use: I have a system with a type 3 failure described above. The "ide=nodma" option did not help. The CD drive was old so last weekend I bought a brand new drive and installed it with the same results. I also replaced the old ide cable. I tried the system with only the CD and one disk connected to the same ide channel and I've tried both ide channels with no difference. I've run a CD drive diagnostic from Windows XP on that same system for hours and hours and it found no errors of any sort or even marginal behavior. I ran it on both the CDs and the DVD with no errors on either. I have taken the disks to my work system (an IBM system) and all of the disks passed media check with no problems including the DVD I tried (which also fails on my home system). I've wasted days of time trying to make this work with no results whatever and can't load fedora on my system. So far I have not found a way to load it and I'm on the verge of giving up. I love Linux/Unix but this is frustrating beyond description. The only other system I have on this network is a Windows XP system and so far, no one has been able to tell me how to install from this system. Almost all of the "other" installation methods require a Linux/Unix system to act as the host/server. I forgot to mention above - with my type 2) drive, if I do the mediacheck with "ide=nodma", sometimes instead of PASS, it just hangs, though I can restart the installer with Ctrl-Alt-Del. This is okay - I've found that as long as none of the discs actually FAIL, the install will work properly (not complaining about some package file being corrupted). Here is a fedora-list post from someone who claims that adding padsize=512k to the cdrecord options will allow mediacheck to work. I seem to remember from bug #106685 (which was prematurely closed) that padding was not a reliable workaround, though for anyone who hasn't been able to get mediacheck to work it's worth a shot. http://www.redhat.com/archives/fedora-test-list/2006-March/msg01553.html (In reply to comment #3) > Here is a fedora-list post from someone who claims that adding padsize=512k to > the cdrecord options will allow mediacheck to work. I seem to remember from bug > #106685 (which was prematurely closed) that padding was not a reliable > workaround, though for anyone who hasn't been able to get mediacheck to work > it's worth a shot. > > http://www.redhat.com/archives/fedora-test-list/2006-March/msg01553.html I don't have access to another Linux system to burn the CDs with the above parameter. I used Nero on a Windows XP system to burn my disks. Do you know if there is a way to add this padding using Nero? I'll check the web and see if anyone has done this as well. Thanks I don't know, but it's probably buried in the UI somewhere. I think there's also a version of cdrecord for Windows. Also, some people claim that forcing a slower burn, say at 4x, instead of the default speed, can make a difference. I searched the Nero GUI and documentation and did not find any references to the pad setting so I don't think it's an available option. I'll try the cdrecord program for Windows. I found it on the web but the site only talks about being compatible with 95, 98, and NT... No mention of XP. I guess I'll just have to try it and see if it works. One drawback to this is that the cdrecord program for Windows run under cygwin so I'll need to install that also. I did try using a slower burn speed. My drive is a 16X system but the last set of disks I tried I burned at 2x and they still failed. BTW, the title of this bug may be a bit misleading to developers that are trying to categorize the bugs... It's not just mediacheck that fails here. If this situation occurs, the install will fail as well and that's a lot more serious. On most of the software programs that I've worked on, an installation failure was a high priority bug... There's no better way to lose a customer than for them to be unable to install the software! I renamed this bug "kernel prevents proper CD checking (mediacheck/install fails)", after bug #106685, since it's the same bug, and since that one hasn't been reopened, though it should be, and this one should be marked as a duplicate. I also changed the severity to "high", though it's unlikely that it will be fixed, since it's been ignored/tolerated for years. I realize that it's an upstream bug, but there ought to be some pressure applied on the current maintainer of this code, or if they won't respond, some money to hire someone else to do the work. Two things I've wondered about: 1) Can this bug cause data corruption during normal use? 2) Do other Linux distros have their own mediacheck, and if so, are they vulnerable to the same bug, and if not, can the Fedora version be modified? I have tried the 3 drives on my two computers, and all fail, even with ide=nodma. HP9100 CDRW, LG GCE8525B CDRW, Samsung SC-148 CDROM. I have also a Creative CD5233E CDROM and an LG CR8521B CDROM (it was already in my car going to be recycled). Before I take any more time testing these drives, has anyone compiled a list of drives which work consistently? Do any drives work consistently or does it rely on the hardware detection order on startup? This would be consistent with Andre's report that plugging or unplugging peripherals can change this behaviour. Samsung SCR-2432 and SCR-3232 (in 7-year old Emachines boxes) work properly (category 1), at least in the machines they came in. NEC ND-2510A CD/DVD burner is category 2 in two different machines. MSI MS-8152 is category 3 in two different machines. The only thing that changing peripherals seems to do is to change which particular discs pass mediacheck, or on which package the install fails with a message that it's missing or corrupt (I suppose with luck, one might be able to finish an install by trying a lot of combinations to find one that it doesn't bomb out on). It doesn't change the category of vulnerability. Some additional information: Andre wondered if the mediacheck from other distributions has the same problem so I tested it with the mediacheck from Redhat Enterprise 4.0 Workstation. It fails the same way as the FC4 mediacheck does. I tried it on the 4.0 disk first and it failed there and then I tried it on the FC4 disks and they also failed. The program does behave a bit differently however. The FC4 version stops with an error message as soon as the first error is discovered but the RH 4.0 version appears to scan the entire disk before reporting any errors. I much prefer the FC4 version. Since FC5 is now available I decided to try that over the weekend. I downloaded the i386 DVD image, verified the sha1 checksum, and burned a DVD (using Nero) at 2X speed with verification. The DVD verifies correctly but still fails the mediacheck when I try to use it on the target system. The FC5 mediacheck program behaves like the RH 4.0 program in that it appears to scan the entire disk before reporting an error. I tried installing from this DVD anyway and the failure mode is different also. The FC4 install would report an error of some sort while reading the CD/DVD and abort the install. The FC5 install now runs for a while and then just hangs. When it hangs, it will not respond to anything including <ctrl>-<alt>-del. I had to hard boot the machine to get it back up again. I downloaded FC5 for PowerPC (ppc) CD1. SHA1SUM for Windows confirmed the .iso image was OK. Burnt OK on regularly used CDROM-RW - no problems. On my IBM pSeries p505 the Media Check fails every time. Burnt a fresh CDROM for different vendor. Same result. There's a fair amount known about the cause of this bug - try the search "alan cox" mediacheck on Google. I downloaded FC5 i386 DVD under Linux. sha1sum is correct. Burnt on DVD - correct. However, now I am trying to install on Toshiba Satellite M30 Notebook with DVD/CD-ROM (Pioneer DVD-RW DVR-K12D). MediaCheck stops at 14% with failure Burnt another image - MediaCheck stops at 15% with failure I have read the bug report and tried option ide=nodma - no change. I haven't tried the padsize=512K option yet. However, is it recommendable trying to install even without MediaCheck passing? Don't want to mess up my running system - I was going to install FC5 as second OS but will need the bootmanager... It seems to depend on hardware - some people just ignore the mediacheck failure and are able to install without problems. Other people, including me, almost always have install problems coinciding with the mediacheck problem (though my box responds to ide=nodma, so I can avoid both problems). Without prior experience with your own hardware, there's no way to tell. FYI to all: Be aware that bad memory may show up as media errors. Just today I found after repeated media error reports that memtest86 detected an error in it's test#8. After reseating (& swapping dimms), memtest86 passes, and then the media check and install proceded normally. ..jim Very informative discussion on the fedora-devel list. Read the Follow-Ups: http://www.redhat.com/archives/fedora-devel-list/2006-March/msg01191.html (In reply to comment #15) > FYI to all: > > Be aware that bad memory may show up as media errors. Just today I found after > repeated media error reports that memtest86 detected an error in it's test#8. After > reseating (& swapping dimms), memtest86 passes, and then the media check and install > proceded normally. > > ..jim Jim - Thank you for this comment! I created a memtest86 boot CD and ran it on my problem machine and sure enough, I had an intermittent memory problem. The problem never showed up in the boot rom memory check and I had no serious problems running on this machine but it does have a memory problem. After replacing one of the DIMMs the problem was fixed and now the mediacheck works fine and FC4 and FC5 both install. I'm up and running! This does beg the question of why FC is so sensitive to this memory problem when Windows XP appears to run fine on the same system. I wondered about this and thought that it might just be that the bad memory in my case was up at the high end of the address range and FC might be using that memory more than XP does. To test that theory, I swapped the bad DIMM so that it was located down in the lower area of the address space to see what would happen and the result was the same behavior. XP still appears to work fine but FC fails misreably. Thanks again for solving my problem! FYI, you can run memtest86 from the 1st install CD, or DVD, by booting from it and typing "memtest86" at the boot: prompt (this is listed if you use F2 to show options). For anyone trying to burn usable CDs, see this page: http://www.troubleshooters.com/linux/coasterless.htm Basically, as a workaround to the read-ahead bug, he recommends using -dao, -pad, and padsize=63s as options to cdrecord (though he doesn't explain where 63 comes from). I'd be interested to know whether discs burned this way can pass mediacheck and/or install on machines that normally require ide=nodma even if it isn't used, or on machines where ide=nodma didn't work at all. I burned new copies of the 5 FC5 CDs, using the above options, and letting cdrecord choose the speed automatically. All 5 CDs now pass mediacheck without ide=nodma. In addition, piping the output of the "rawread" script through sha1sum gave the correct result for each of the CDs, giving an alternative to mediacheck. Simply using cat /dev/cdrom | sha1sum did NOT work - it didn't show any errors, but the returned sha1sums were wrong. This is consistent with the web page, which states that it's necessary to read the ISO header first to know how far to read. I'm not going to check whether a clean install without ide=nodma works, since my FC5 box is working fine. That will have to wait until FC6. Created attachment 127640 [details]
The Anaconda dump text
I burned more CD's (I am burning these on a WinXP machine sine I don't have a Linux machine connected to the net right now) and got a set which passes mediacheck on two computers (one P4 one AMD) but the install failed after the first few hardware checks, and yielded the above dump text Did you try installing with the previous CDs, and if so, is this the same error as before? The usual install error associated with the mediacheck bug is that it claims a particular package is missing or corrupt. *** Bug 190303 has been marked as a duplicate of this bug. *** I just bought a Dell Dimension B110 with a Sony CRX310EE CD-RW/DVD-ROM drive. Some of the 5 CDs I burned using the above instructions failed mediacheck. The failures weren't totally consistent, one disk passed once and failed once. Using ide=nodma made no difference. (So this is a "category 3" drive.) However, the actual install worked without incident. Possibly some drives don't do enough error checking during mediacheck, but if anaconda has the drive read an RPM repeatedly during install, it can get it right at least once. This would account for the advice some people give to ignore mediacheck and do the install - their own machines just happen to work like this. Here's an alternative way of checking your media if you have a working Linux system: http://www.city-fan.org/tips/IsoImageFromMedia The "isograb" script does basically the same thing as the "rawread" script. I tested the 5 CDs I burned using rawread on my B110 drive, and one disc failed consistently, with the same wrong sha1sum twice, so it must be failing in only one specific area. I know these discs are readable on another drive, so this drive is probably of low quality. Maybe forcing a lower burn speed would help - I'll try that next time. Also I'm guessing that there's more chance of success reading the discs on the same drive they're burned on. Here is my store, just feel sad that a great product can end up this way, and it seems nobody really cares about the fix. Long time ago, I downloaded FC1. It worked great until the PC gave up. So I have a new one. Install FC1 without problem (use linux allowcddma, a bit problem actually but workable). Then I found out it actually has FC5 now. Surly, I download FC5 and burned 5 CDs. When I installed, it failed. naturely I ran the test CD, turned out 3 were reported bad. I used another brand of CDR, this time one was bad, so reburned one, after threw out 4 CD-Rs, it finally reported all CDs are ready for install. The rest of story, everyone knows. It keeps reporting some rpm corrupted, I tried different burn speed, brand, check the Sha1rsum, differnt burning programs, shame on FC5, none worked. I wasted two full days with nothing. Now I try to download FC3 and will give a try. People may ask why not FC4, based on this thread, it seems FC4 is no better than FC5. If this FC3 does not work, man, I guess I have to use FC1. BTW, anyone can suggest any other Linux than Fedora? It's an upstream bug in the kernel. All distros have it, though the Fedora installer may be more affected than some. Try burning the CDs using the URL in comment #19 to try to work around the bug. A new kernel update has been released (Version: 2.6.18-1.2200.fc5) based upon a new upstream kernel release. Please retest against this new kernel, as a large number of patches go into each upstream release, possibly including changes that may address this problem. This bug has been placed in NEEDINFO state. Due to the large volume of inactive bugs in bugzilla, if this bug is still in this state in two weeks time, it will be closed. Should this bug still be relevant after this period, the reporter can reopen the bug at any time. Any other users on the Cc: list of this bug can request that the bug be reopened by adding a comment to the bug. In the last few updates, some users upgrading from FC4->FC5 have reported that installing a kernel update has left their systems unbootable. If you have been affected by this problem please check you only have one version of device-mapper & lvm2 installed. See bug 207474 for further details. If this bug is a problem preventing you from installing the release this version is filed against, please see bug 169613. If this bug has been fixed, but you are now experiencing a different problem, please file a separate bug for the new problem. Thank you. Still broken (no surprise). The problem still exists in FC6, but the F7 mediacheck appears not to be affected. I'm guessing that the readahead bug still exists, but that mediacheck has been modified to skip the mkisofs-padded end of the ISO, past where the actual files are. This ought to work since mkisofs by default adds enough padding to the ISO to protect the files in it from the readahead bug. Can someone verify this? If so, then this bug should either be closed or renamed since its current summary would no longer be accurate. According to Alan Cox, the libata drivers used by F7 don't have the same problems. Should this bug be closed then? http://www.redhat.com/archives/fedora-list/2007-June/msg01013.html Fedora apologizes that these issues have not been resolved yet. We're sorry it's taken so long for your bug to be properly triaged and acted on. We appreciate the time you took to report this issue and want to make sure no important bugs slip through the cracks. If you're currently running a version of Fedora Core between 1 and 6, please note that Fedora no longer maintains these releases. We strongly encourage you to upgrade to a current Fedora release. In order to refocus our efforts as a project we are flagging all of the open bugs for releases which are no longer maintained and closing them. http://fedoraproject.org/wiki/LifeCycle/EOL If this bug is still open against Fedora Core 1 through 6, thirty days from now, it will be closed 'WONTFIX'. If you can reporduce this bug in the latest Fedora version, please change to the respective version. If you are unable to do this, please add a comment to this bug requesting the change. Thanks for your help, and we apologize again that we haven't handled these issues to this point. The process we are following is outlined here: http://fedoraproject.org/wiki/BugZappers/F9CleanUp We will be following the process here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this doesn't happen again. And if you'd like to join the bug triage team to help make things better, check out http://fedoraproject.org/wiki/BugZappers Still broken as of F8 (contrary to popular opinion). See bug #397141. The easiest way to trigger this bug, assuming one is using a drive vulnerable to the bug, seems to be to burn a CD _without_ using either DAO or padding. Using wodim in the simplest possible way achieves this, for example when burning a CD-RW use wodim dev=/dev/cdrom blank=fast foo.iso then try to read the ISO off the disc using the rawread script. It should fail a few dozen kB from the end. This message is a reminder that Fedora 8 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 8. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '8'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 8's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 8 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping *** Bug 397141 has been marked as a duplicate of this bug. *** This has been seen by someone else in bug #448291. I seem to have hit this bug on Fedora 10. I thought the SCSI/SATA drivers had a
bug until I found this report. Here we go:
With an LG GDRH20N SATA DVD-ROM:
-- Media Check fails 100% (tested DVDs, (live) CDs, several burns...)
-- "Independent Media Check" using another system works (dump the ISO
image, see below, then check the SHA1 sum against the official sum)
-- Installation fails in a totally weird manner
(e.g. at the very end, anaconda says "no kernel images installed" or
arbitrary packages are not found)
-- Starting the same system from a PATA drive found in the attic with
the same media works nicely (installation not yet tried, will try)
-- Media check passes if "ide=nodma" kernel option is given. Yowza!
Additionally:
-- Booting the system to Fedora 10 Live CD using aforementioned PATA
drive, then dumping an ISO image (in this case, F10-x86_64-Live.iso)
off the DVD-ROM if "ide=nodma" has NOT been set results in a:
-- correctly-sized
-- but slightly corrupted image
The dump was done with "dd if=/dev/sr0 of=/tmp/corrupted.iso"
It is probably not of big interest to know the exact differences,
but a little perl program to cut the dump into 10K blocks and hash
these, applied tp both original ISO and dumped ISO reveals 61 10K
blocks with differences, *spread throughout the image* (not only the
end affected).
Now going to have drink or two.
How to hash 10K blocks:
#!/usr/bin/perl
use Digest::MD5 qw(md5 md5_hex md5_base64);
$file = $ARGV[0];
open(FILE,$file) or die "Could not open $file: $!\n";
binmode FILE;
my $buffer;
my $size = 1024*10;
my $read;
my $pos = 0;
while (($read = read(FILE, $buffer, $size)) > 0) {
my $digest = md5_hex($buffer);
my $end = $pos + $size - 1;
print "$digest [$pos,$end] $size\n";
$pos += $size;
}
close(FILE);
The readahead bug should only affect reading the last few dozen KB of the disc image. You also need to be careful not to use dd to attempt to read off more than the actual size of the ISO. The rawread script at http://www.troubleshooters.com/linux/coasterless.htm reads off the correct amount automatically. It's very handy; I make it executable and put it in ~/bin so it's always available in my path. Using "ide=nodma" may or may not work, depending on your hardware (it usually didn't work for me). Doing the burning as recommended in the link above seems to be the only foolproof way to avoid the readahead bug. Thanks Andre, After retesting, any consistent explanation fell apart, and I am now pretty sure that it is just my DVD-ROM drive which does not work or which has some problem with the motherboard. Time burnt on a stupid problem, damn you non-self-checking hardware! Okay, out goes the drive... I'm not sure whether "ide=nodma" still has any effect whatsoever in F10, especially with SATA drives? The last time it was mentioned was in the Fedora Core 4 release notes at http://docs.fedoraproject.org/release-notes/fc4/ This message is a reminder that Fedora 10 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 10. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '10'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 10's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 10 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping Still see this on a clean installed and updated i386 F12 box with a Sony DW-G120A/DRU-120C DVD+RW drive. Trying to read my old FC4 CDs 1,2,3,4 results in read failures 2048, 110592, 110592, and 57344 bytes from the end, resp. Using wget -c to complete the files shows the previously read part is correct. I can confirm what Andre said, I'm using i386 f12 with a HL-DT-ST DVDRAM GSA-H62N and I see read failures near the end of dual layer DVDs, screwing up hashing. Using the rawread script fixes the issue. Stephen: if you are able to read the discs properly with the rawread script, then you're not seeing the same issue. The read errors I'm talking about happen even when the rawread script is used (which I always do) since they happen before the ISO file has been fully read off. Personally, the only time I've heard of this problem on DVDs was when my father bought a Fedora 8 DVD online. The easiest way I know to reproduce it is to burn a CD-RW in the simplest possible way - i.e., wodim -v dev=/dev/cdrom blank=fast file.iso in the default TAO mode (DAO seems to prevent the bug). Growisofs uses DAO by default which may explain why it's so difficult to reproduce on DVDs. Sorry, nevermind, I didn't read all of the comments. Disregard my comment. This message is a reminder that Fedora 12 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 12. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '12'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 12's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 12 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping Same behavior on F14 i386 with 2.6.35.6-48.fc14.i686.PAE. (In reply to comment #45) > Still see this on a clean installed and updated i386 F12 box with a Sony > DW-G120A/DRU-120C DVD+RW drive. Trying to read my old FC4 CDs 1,2,3,4 results > in read failures 2048, 110592, 110592, and 57344 bytes from the end, resp. > Using wget -c to complete the files shows the previously read part is correct. Just clean installed F15 i386 (AKA RC3) in this machine, with the same optical drive, running kernel-2.6.38.6-26.rc1.fc15.i686.PAE. Reading the same 4 CDs, CD 1 has a read failure just 2048 bytes from the end. CDs 2, 3, and 4 can be read all the way to the end. The parts that can be read are correct (using wget -c on the first image, and then verifying the sha1sum of all images). I don't know if this is progress or not. Are there any kernel changes that might have reduced the severity of this bug? Same behavior on F16 (RC5) i386 with kernel-PAE-3.1.0-7.fc16.i686. # Mass update to all open bugs. Kernel 3.6.2-1.fc16 has just been pushed to updates. This update is a significant rebase from the previous version. Please retest with this kernel, and let us know if your problem has been fixed. In the event that you have upgraded to a newer release and the bug you reported is still present, please change the version field to the newest release you have encountered the issue with. Before doing so, please ensure you are testing the latest kernel update in that release and attach any new and relevant information you may have gathered. If you are not the original bug reporter and you still experience this bug, please file a new report, as it is possible that you may be seeing a different problem. (Please don't clone this bug, a fresh bug referencing this bug in the comment is sufficient). With no response, we are closing this bug under the assumption that it is no longer an issue. If you still experience this bug, please feel free to reopen the bug report. |