Description of problem: I installed an Intel solid-state disk (ATA INTEL SSDSA2MH080G1GC with firmware version 045C8802) on my laptop (http://www.smolts.org/client/show/pub_09d2739c-80d4-4d97-87c5-fadf6e1d7815) At every boot, I receive the following messages while loading the initial ramdisk: ata1: COMRESET failed (errno=-16) while loading initial ramdisk This repeats 3-4 times until 60s has elapsed, after which the system boots normally. Version-Release number of selected component (if applicable): kernel-3.2.9-2.fc16.x86_64 How reproducible: Every time Steps to Reproduce: 1. Install Fedora 16 on the Intel SSD specified above 2. Attempt to boot. Actual results: Annoying error message and completely unnecessary 60 seconds of lag while starting up. Expected results: System should start booting immediately. Additional info: I am available to run any set of diagnostics needed to track this down. I'm setting the severity to low because the system works after the lag, but it's very annoying.
[mass update] kernel-3.3.0-4.fc16 has been pushed to the Fedora 16 stable repository. Please retest with this update.
Absolutely no change with kernel-3.3.0-4.fc16
Hi Stephen, just registered to answer you :-) I have a Thinkpad SL300 and I had the same Error: Loading initial ramdisk ... [ 11.312075]ata2: COMRESET failed (errno=-16) beside the fact that it only is one time after about 11 seconds. A temporary fix is to set AHCPI in your BIOS to compatibility mode. think it is not a bug in fedora. see also: https://bugs.launchpad.net/ubuntu/+source/linux-meta/+bug/150259/comments/27
I don't know if I agree that this is not a bug in Fedora. Setting the BIOS to compatibility mode is a workaround, not a fix (and one that comes with a not-insignificant performance penalty). I'd much rather have my solid-state disk performing at its full potential, not running in IDE-compatibility mode.
Hi Stephen, did you try to update your BIOS as suggested there: https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.22/+bug/162536 Too bad, I am already at the newest bios version available.
Yes, I am running the latest available BIOS
If you boot with libahci.skip_host_reset=1 on the cmd line does it help at all?
(In reply to comment #9) > If you boot with libahci.skip_host_reset=1 on the cmd line does it help at > all? No, I still received three of the above error message, taking 60s between loading message about loading the initrd and actually starting the normal boot process.
# 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).
This problem is still occurring on Fedora 18 running kernel-3.6.2-2.fc18.x86_64 This problem is exacerbated by https://bugzilla.redhat.com/show_bug.cgi?id=868421 because the tendency to wander off and do something else while waiting for the COMRESET issue to time out often means that I won't get back in time to enter the LUKS password before that drops the system to a debug console (which must be rebooted to continue, forcing another COMRESET wait period).
Is this still happening with 3.8.2 and the latest bios?
I don't know, I gave up and swapped the drive out for a new model that doesn't experience this issue. I still have the old drive around and could probably boot it up, but at this point unless anyone else is reporting the problem I'd probably just recommend closing this bug as no longer interesting.
Yeah, still seeing it on 3.8.2-206.fc18.x86_64.
Still there on 3.8.3-201.fc18.i686.PAE using a kingston ssd
Fixed in Kernel 3.8.4-202.fc18.i686
(In reply to comment #15) > I don't know, I gave up and swapped the drive out for a new model that > doesn't experience this issue. > > I still have the old drive around and could probably boot it up, but at this > point unless anyone else is reporting the problem I'd probably just > recommend closing this bug as no longer interesting. no, no... I'm watching it as I still have SSDSA2M080G2GN which annoys me with COMRESET for a while already. :)
I've just updated SSD firmware and it resolved the issue. Thus I support closing this.
Still receiving the COMRESET failed (errno=-16) on kernel 3.8.6-203.fc18.i686.PAE
*********** MASS BUG UPDATE ************** We apologize for the inconvenience. There is a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 18 kernel bugs. Fedora 18 has now been rebased to 3.11.4-101.fc18. Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel. If you have moved on to Fedora 19, and are still experiencing this issue, please change the version to Fedora 19. If you experience different issues, please open a new bug report for those.
Hi Justin, I updated the kernel but the error is still present. kernel: 3.11.4-101.fc18.i686.PAE
George, have you tried to update the ssd firmware to the latest available already?
Hi Anton, Yes I am on the latest firmware (the ssd is a very old model). This week I will be getting a new ssd, will check if re-produces the same issue and update you accordingly.
This message is a reminder that Fedora 18 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 18. 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 '18'. 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 18's end of life. Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 18 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, you are encouraged change the 'version' to a later Fedora version prior to Fedora 18's end of life. 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.
Fedora 18 changed to end-of-life (EOL) status on 2014-01-14. Fedora 18 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.
Adding libata.force=ataN:1.5G works around the problem for me.
(Obviously it's not perfect, but in this case I'd rather continue to use this at 1.5G/s than deal with the delays to booting.)
The status was changed to WONTFIX for Fedora 18. However, I have this problem on the currently supported Fedora 20! I guess, this ticket has to be opened again. SSD: Intel SA2MH080G1GN Error while installing from USB: ata1: COMRESET failed (errno=-16) @Kyle McMartin, how can I fix the problem like you did? I do not mind the 1.5G/s (for the moment)
Add libata.force=1:1.5G to your kernel command line where the first "1" corresponds to whichever ata device is being complained about. (Looks like 1 in your case above as well.)