Opened 4 years ago

Closed 3 years ago

Last modified 3 years ago

#12415 closed bug (fixed)

Removeable media AHCI port reset bug

Reported by: vidrep Owned by: kallisti5
Priority: blocker Milestone: R1/beta1
Component: Drivers/Disk Version: R1/Development
Keywords: cdrom dvd bluray cd-rom Cc:
Blocked By: Blocking: #12470, #12634
Has a Patch: no Platform: All

Description

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

Attachments (1)

syslog (310.6 KB) - added by vidrep 4 years ago.

Download all attachments as: .zip

Change History (31)

Changed 4 years ago by vidrep

Attachment: syslog added

comment:1 Changed 4 years ago by vidrep

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

comment:2 Changed 4 years ago by diver

Component: - GeneralDrivers/Disk

comment:3 Changed 4 years ago by diver

Owner: changed from nobody to kallisti5
Status: newassigned

This one is probably a dupe of #12324.

comment:4 Changed 4 years ago by 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.

comment:5 Changed 4 years ago by kallisti5

Milestone: UnscheduledR1/beta1
Priority: normalblocker

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.

comment:6 Changed 4 years ago by kallisti5

Keywords: cdrom dvd bluray cd-rom added
Summary: AHCI port reset bugRemoveable media AHCI port reset bug

comment:7 Changed 3 years ago by diver

Blocking: 12634 added

comment:8 Changed 3 years ago by Giova84

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

comment:9 Changed 3 years ago by CodeforEvolution

Last edited 3 years ago by CodeforEvolution (previous) (diff)

comment:10 Changed 3 years ago by CodeforEvolution

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

comment:11 Changed 3 years ago by kallisti5

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

comment:13 in reply to:  11 Changed 3 years ago by 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.

comment:14 Changed 3 years ago by kallisti5

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

comment:15 Changed 3 years ago by 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

comment:16 Changed 3 years ago by 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

comment:17 Changed 3 years ago by 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:

  • AHCI Port handles 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 hrev49663? (can be placed into the drive post boot, can be mounted, can be unmounted, and replaced, etc)

Last edited 3 years ago by kallisti5 (previous) (diff)

comment:18 in reply to:  17 Changed 3 years ago by 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 :-)

comment:19 Changed 3 years ago by 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.

comment:20 Changed 3 years ago by 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

comment:21 Changed 3 years ago by 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...

comment:22 Changed 3 years ago by 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.

comment:23 Changed 3 years ago by kallisti5

Resolution: fixed
Status: assignedclosed

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.

Last edited 3 years ago by kallisti5 (previous) (diff)

comment:24 Changed 3 years ago by vidrep

Verified as working on my hardware with hrev50195. Thanks!

comment:25 Changed 3 years ago by 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.

comment:26 Changed 3 years ago by 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.

comment:27 Changed 3 years ago by vidrep

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

comment:28 Changed 3 years ago by jua

Resolution: fixed
Status: closedreopened

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

comment:29 Changed 3 years ago by kallisti5

Resolution: fixed
Status: reopenedclosed

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

comment:30 Changed 3 years ago by diver

Blocking: 12470 added
Note: See TracTickets for help on using tickets.