https://bugzilla.kernel.org/show_bug.cgi?id=215880 --- Comment #54 from Damien Le Moal (damien.lemoal@xxxxxxx) --- (In reply to Paul Ausbeck from comment #53) > I sense that we are in disagreement. In my way of thinking disagreement is > overcome through logical argument. So here goes. > > I argue that you can't call a bug fixed if the fix introduces a serious, > entirely separate, regression. I further argue that at resume the mouse > pointer should be interactive at the same time that the display becomes > active. I further argue that if the mouse pointer is not interactive at any > time that the display is active, that is a serious UX bug. I further argue > that before the recent kernel ATA changes this particular bug did not exist > and therefore it is a regression. I further argue that though the regression > is UX related it cannot be patched over outside of the kernel. I further > argue that this regression likely affects any personal machine that contains > a spinning disk and that this class of machines is substantial in size. I > further argue that your reported deadlock between ata resume and scsi resume > likely affects a far smaller class of machines. I further argue that though > for a single machine deadlock is a more important problem than temporary > lack of mouse pointer interactivity, for the kernel as a whole, problem > importance is proportional to the multiplication of the individual > seriousness and the size of the set of affected machines. I further argue > that your assertion that the non-interactive mouse pointer is not related to > the libata resume changes is incorrect. I further argue that the two dmesg > fragments that I have posted to this thread explain the situation quite > clearly. > > My argument contains 10 assertions. If you disagree with any of them, please > give details. In particular I don't have a clear idea of the size of the set > of machines that might experience the "fixed" ata/scsi resume deadlock. Repeating the same things again and again without new technical information we (developers) can act on is not very productive. So let's dig into this issue to verify *if* this is really an issue introduced by libata, which as I said, I doubt it is. But let's make sure. So could you please try the following: 1) Build the latest 6.5-rc1 kernel from git and try with that kernel to see if the issue is still there. 2) If the issue is not resolved, with that same kernel, please try to revert commit 6aa0365a3c85. 3) Regardless of the result for (2) please do a bisect to see if the commit responsible for the issue is indeed 6aa0365a3c85. You can find information on how to do that in the Linux documentation at Documentation/admin-guide/bug-bisect.rst. You may also want to read Documentation/admin-guide/quickly-build-trimmed-linux.rst 4) Please provide the output of lspci and a full dmesg for your system. dmesg output after boot and after resume would be helpful. With the above information, we will likely have a better idea of what is going on with your machine. Also please know that the number of machines affected by an issue only determines the priority/urgency of a fix. Even if a single user is affected, issues will still be addressed as long as enough information is provided and the person affected helps with testing (as I cannot recreate that issue with the hardware I have). Note that I am on vacation this week, so I am only checking emails and replying as a courtesy. I will not do anything until Tuesday next week. -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
