Removeable media AHCI port reset bug

[vidrep]

hrev49674 x86_gcc2 Cannot eject CD tray Tray opens then closes immediately; impossible to insert or remove a disc It is working properly with hrev49662 Attached syslog

[vidrep]

After a reboot I noticed that the syslog keeps growing as the AHCI port is continuously being reset.

[diver]

This one is probably a dupe of #12324.

[kallisti5]

Nah. this is a different issue. So our AHCI stack freaks out if there isn't any media in an AHCI device. We see a continuous stream of port resets. I think we need to do something special if TEST_UNIT_READY fails... but haven't dug into the exacts yet.

[kallisti5]

I'm making this one a blocker since CDROM functionality is pretty core.

While you can insert a cd at boot and it works... changing media is difficult and the AHCI device state gets invalidated when no media is present.

I attempted to solve this one during my AHCI work, but never figured out what AHCI callbacks were needed for empty media.

[Giova84]

Same bug on my system. I comment here also to receive notifications about this ticket.

[CodeforEvolution]

I have found the source of this critical bug in hrev49665 and ironically was supposed to improve ahci on haiku.

[kallisti5]

Did you see this issue before hrev49665? I was seeing it prior which is the original reason I did hrev49665.

[kallisti5]

Here is an image just before hrev49665 to test with:

​http://download.haiku-os.org/nightly-images/x86_hybrid/haiku_unsupported-nightly-hrev49663-x86_hybrid-anyboot.zip

[Giova84]

Replying to kallisti5:

Did you see this issue before hrev49665? I was seeing it prior which is the original reason I did hrev49665.

On hrev49662 everything is fine: for me, on this old revision, this issue is not present.

[kallisti5]

ok, let me test reverting locally and see if it goes away

[kallisti5]

Pulkomandy also mentioned just reverting in the Beta 1 branch if the change is solid but buggy.

For reference, here are reversions to undo my recent changes.

git revert b8dd04e42808ada06d91000e06bdc9eecdc05893 c6475ba15c3a804dd8de51b2d781431935922f7f 2f6a9c685a0b6490796c08ef8120cff1ea743dc5 a1ed294ff9fd94e10fe6b7fada5e20891b693ec2

[kallisti5]

I'm going to move these patches into a local branch to rework and revert them in master. I haven't found the time to fix them and nobody has stepped up to help out.

Doing a test build now and have extracted the changes into a series of patch files i'll apply to a github.com/kallisti5/haiku "ahci rework" branch

[kallisti5]

LOL... reverting my changes does make the problem worse (just less noticeably)

With my changes / rework:

• Port enters AHCI reset loop when no media is present on boot
• CDROM immediately loads when ejected
• CDROM's placed in drive have around a 50/50% chance of loading properly when placed in system post-boot.
• CDROM's placed in drive pre-boot work normally.

Without my changes / rework:

• Port ejects normally.
• CD's placed into drive while OS running don't work.
• CD's placed into drive pre-boot don't work.

It was one of the previous commits to the stack that caused the original regression (which is likely why I couldn't find the root cause in my changes). I made it slightly better that they work when inserted before boot but the port falls into a reset loop when the OS is running without media.

Could the previous testers validate that the CD's actually work reliably on hrev49662? (can be placed into the drive post boot, can be mounted, can be unmounted, and replaced, etc)

[Giova84]

Replying to kallisti5:

Could the previous testers validate that the CD's actually work reliably on hrev49663? (can be placed into the drive post boot, can be mounted, can be unmounted, and replaced, etc)

Hi, I can confirm you that for me, on my system with hrev49662 everything that you mentioned, works fine without any (at least noticeable) issues. To give you a better confirmation, would be nice also get a response from Vidrep :-)

[vidrep]

As discussed on IRC yesterday, I did a fresh install of hrev49664 and confirmed that it is the last working revision for which the AHCI port reset bug is not evident on my system.

[kallisti5]

For my reference... here is the loop with a few comments

KERN: ahci: check_sense: No sense ("SCSI thought there was an error.. but there wasn't")
KERN: ahci: AHCIPort::PortReset
KERN: ahci: Disable
KERN: ahci: PhyReady Change
KERN: ahci: Enable
KERN: ahci: Port Connect Change
KERN: ahci: Port Connect Change
KERN: ahci: PhyReady Change
KERN: ahci: Probe: link speed 1.5Gb/s
KERN: ahci: Probe: port is atapi

[kallisti5]

AH: 1d4c4d3a5bb167a4df0202a1c1d9e44abd4c156d

mmlr mentions the exact issue we're seeing here as being solved... however I don't see him solving it in ahci_port... he just seems to be logging the event there and getting the test unit...

[kallisti5]

mmlr was just "hiding the errors" when no cd media is present lol. I simply unhid the errors.

So the port reset storm is a red herring... the real issue is:

• cdrom sucking back in when ejected
• removable media not loading on insertion post-boot.

[kallisti5]

Ok. 1d4c4d3 gave me some valuable notes on what the intent was. While I was testing, reverting all of my changes still showed the constant port resets. That paired with strange VirtualBox AHCI behavior made it look like reverting my changes didn't fix it.

However the notes on 1d4c4d3 show that mmlr was simply "hiding" the AHCI resets when no media is present. The resets happen continuously while no media is present. (He should of thrown some comments in :-))

Since the suspect was the resets, I took a step back and looked at the reset code... it appears I inadvertently made the resets "stronger" all of the time. Since we now know the CDROM constantly "resets while no media is present" the stronger AHCI resets result in funky removable media behavior.

Resolved in hrev50195. I think there are a few bus state issues after inserting a cdrom, however those can be cleaned up via a new ticket as the AHCI stack recovers. I'll need to go back and hide error messages when no media is present once this stuff is tested beyond my hardware.

[vidrep]

Verified as working on my hardware with hrev50195. Thanks!

[Giova84]

I am on hrev50198, but I still experience the bug described in ticket:12634 Otherwise, at least, I am again able to insert or remove disks in my cd - dvd player.

[Giova84]

Hi Kallisti, I've seen that you have reopened the ticket:12634. Can you also assign the proper component? (currently is set as "General"); however do you plan to assign such ticket to yourself?

Kind regards.

[vidrep]

I'm seeing this as well. Let me know if I can provide any useful info.

[jua]

hrev50209 here, CD drive in Thinkpad still puts endless port reset messages into the syslog.

[kallisti5]

Please do not reopen this ticket. The issue mentioned in it is resolved. The port resets in the log are in ticket:12634.