Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1598022 - ata1: COMRESET failed (errno=-16) while loading initial ramdisk [NEEDINFO]
Summary: ata1: COMRESET failed (errno=-16) while loading initial ramdisk
Keywords:
Status: CLOSED INSUFFICIENT_DATA
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 27
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On: 802365
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-07-04 07:39 UTC by xhe@redhat.com
Modified: 2018-08-29 14:56 UTC (History)
27 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of: 802365
Environment:
Last Closed: 2018-08-29 14:56:15 UTC
jforbes: needinfo?


Attachments (Terms of Use)
HDD is lost in BIOS -> Boot Queue (deleted)
2018-07-04 07:39 UTC, xhe@redhat.com
no flags Details
BIOS INFO (deleted)
2018-07-04 08:06 UTC, xhe@redhat.com
no flags Details

Description xhe@redhat.com 2018-07-04 07:39:19 UTC
Created attachment 1456387 [details]
HDD is lost in BIOS -> Boot Queue

+++ This bug was initially created as a clone of Bug #802365 +++

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.

--- Additional comment from Dave Jones on 2012-03-22 12:56:14 EDT ---

[mass update]
kernel-3.3.0-4.fc16 has been pushed to the Fedora 16 stable repository.
Please retest with this update.

--- Additional comment from Dave Jones on 2012-03-22 13:00:05 EDT ---

[mass update]
kernel-3.3.0-4.fc16 has been pushed to the Fedora 16 stable repository.
Please retest with this update.

--- Additional comment from Dave Jones on 2012-03-22 13:11:21 EDT ---

[mass update]
kernel-3.3.0-4.fc16 has been pushed to the Fedora 16 stable repository.
Please retest with this update.

--- Additional comment from Stephen Gallagher on 2012-03-23 07:25:51 EDT ---

Absolutely no change with kernel-3.3.0-4.fc16

--- Additional comment from Thomas Waldecker on 2012-03-30 08:32:57 EDT ---

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

--- Additional comment from Stephen Gallagher on 2012-03-30 08:47:27 EDT ---

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.

--- Additional comment from Thomas Waldecker on 2012-03-30 09:01:49 EDT ---

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.

--- Additional comment from Stephen Gallagher on 2012-03-30 09:07:43 EDT ---

Yes, I am running the latest available BIOS

--- Additional comment from Kyle McMartin on 2012-10-15 14:17:33 EDT ---

If you boot with libahci.skip_host_reset=1 on the cmd line does it help at all?

--- Additional comment from Stephen Gallagher on 2012-10-15 14:29:37 EDT ---

(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.

--- Additional comment from Dave Jones on 2012-10-23 11:41:37 EDT ---

# 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).

--- Additional comment from Stephen Gallagher on 2012-10-23 12:25:48 EDT ---

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).

--- Additional comment from Justin M. Forbes on 2013-03-14 16:29:16 EDT ---

Is this still happening with 3.8.2 and the latest bios?

--- Additional comment from Justin M. Forbes on 2013-03-14 16:29:53 EDT ---

Is this still happening with 3.8.2 and the latest bios?

--- Additional comment from Stephen Gallagher on 2013-03-14 16:39:36 EDT ---

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.

--- Additional comment from Kyle McMartin on 2013-03-14 16:40:25 EDT ---

Yeah, still seeing it on 3.8.2-206.fc18.x86_64.

--- Additional comment from George Constantinou on 2013-03-20 17:44:58 EDT ---

Still there on 3.8.3-201.fc18.i686.PAE using a kingston ssd

--- Additional comment from Thomas Waldecker on 2013-03-28 09:40:01 EDT ---

Fixed in Kernel 3.8.4-202.fc18.i686

--- Additional comment from Anton Arapov on 2013-04-10 11:19:54 EDT ---

(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. :)

--- Additional comment from Anton Arapov on 2013-04-10 13:05:29 EDT ---

I've just updated SSD firmware and it resolved the issue. Thus I support closing this.

--- Additional comment from George Constantinou on 2013-04-13 20:32:28 EDT ---

Still receiving the COMRESET failed (errno=-16) on kernel 3.8.6-203.fc18.i686.PAE

--- Additional comment from Justin M. Forbes on 2013-10-18 17:22:30 EDT ---

*********** 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.

--- Additional comment from George Constantinou on 2013-10-20 05:16:36 EDT ---

Hi Justin,

I updated the kernel but the error is still present.

kernel: 3.11.4-101.fc18.i686.PAE

--- Additional comment from Anton Arapov on 2013-10-21 02:40:19 EDT ---

George, have you tried to update the ssd firmware to the latest available already?

--- Additional comment from George Constantinou on 2013-11-02 06:47:14 EDT ---

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.

--- Additional comment from Fedora End Of Life on 2013-12-21 03:34:00 EST ---

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.

--- Additional comment from Fedora End Of Life on 2014-02-05 06:55:02 EST ---

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.

--- Additional comment from Kyle McMartin on 2014-02-17 17:29:28 EST ---

Adding libata.force=ataN:1.5G works around the problem for me.

--- Additional comment from Kyle McMartin on 2014-02-17 17:31:19 EST ---

(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.)

--- Additional comment from Shailen Sobhee on 2015-02-01 09:15:18 EST ---

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)

--- Additional comment from Kyle McMartin on 2015-02-04 11:13:09 EST ---

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.)

Comment 1 xhe@redhat.com 2018-07-04 08:02:04 UTC
I hit this issue on my new system Fedora 27 installed in this morning. Hard disk can not be detected in BIOS -> Boot Order, I can not copy out my work data from it. 

Here is reproducer: 
step 1) added two lines to /etc/fstab :  
+ /dev/mapper/fedora-..-home /home ext4 default 1 1  
+ /dev/mapper/fedora-..-var  /var  ext4 default 1 1 
Note: the two existing partitions are from the old system of Fedora 25, when I installed Fedora 27 I didn't remove the old system. So that I can mount Fedora 25 partitions to current /home /var.
Step 2) rebooted system and everything worked.
Step 3) I tried to add old system boot kernel into /etc/grub2.cfg, but system suddenly did reboot by itself, so that I didn't finished inputting in the grub2.cfg
Step 4) I was told "No disk found" in system booting, then I checked the BIOS boot queue, found that HDD doesn't exists in the boot order of BIOS.

Comment 2 xhe@redhat.com 2018-07-04 08:06:39 UTC
Created attachment 1456418 [details]
BIOS INFO

Comment 3 Justin M. Forbes 2018-07-23 14:56:43 UTC
*********** MASS BUG UPDATE **************

We apologize for the inconvenience.  There are 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 27 kernel bugs.

Fedora 27 has now been rebased to 4.17.7-100.fc27.  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 28, and are still experiencing this issue, please change the version to Fedora 28.

If you experience different issues, please open a new bug report for those.

Comment 4 Justin M. Forbes 2018-08-29 14:56:15 UTC
*********** MASS BUG UPDATE **************
This bug is being closed with INSUFFICIENT_DATA as there has not been a response in 5 weeks. If you are still experiencing this issue, please reopen and attach the relevant data from the latest kernel you are running and any data that might have been requested previously.


Note You need to log in before you can comment on or make changes to this bug.