Attachments (1)
Change History (31)
by , 9 years ago
comment:1 by , 9 years ago
comment:2 by , 9 years ago
Component: | - General → Drivers/Disk |
---|
comment:3 by , 9 years ago
Owner: | changed from | to
---|---|
Status: | new → assigned |
This one is probably a dupe of #12324.
comment:4 by , 9 years ago
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 by , 9 years ago
Milestone: | Unscheduled → R1/beta1 |
---|---|
Priority: | normal → blocker |
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 by , 9 years ago
Keywords: | cdrom dvd bluray cd-rom added |
---|---|
Summary: | AHCI port reset bug → Removeable media AHCI port reset bug |
comment:7 by , 9 years ago
Blocking: | 12634 added |
---|
comment:8 by , 9 years ago
Same bug on my system. I comment here also to receive notifications about this ticket.
comment:10 by , 9 years ago
I have found the source of this critical bug in hrev49665 and ironically was supposed to improve ahci on haiku.
follow-up: 13 comment:11 by , 9 years ago
comment:13 by , 9 years ago
comment:15 by , 9 years ago
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 by , 9 years ago
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
follow-up: 18 comment:17 by , 9 years ago
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)
comment:18 by , 9 years ago
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 by , 9 years ago
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 by , 9 years ago
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 by , 9 years ago
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 by , 9 years ago
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 by , 9 years ago
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
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.
comment:25 by , 9 years ago
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 by , 9 years ago
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:28 by , 9 years ago
Resolution: | fixed |
---|---|
Status: | closed → reopened |
hrev50209 here, CD drive in Thinkpad still puts endless port reset messages into the syslog.
comment:29 by , 9 years ago
Resolution: | → fixed |
---|---|
Status: | reopened → closed |
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 by , 9 years ago
Blocking: | 12470 added |
---|
After a reboot I noticed that the syslog keeps growing as the AHCI port is continuously being reset.