[scsi_generic] Bad media in DVD drive leads to enormous boot time since 6.5rc

[Sune Mølgaard]

25/07/2023 04:08+0200, I reported that 6.5-rc wouldn't boot, possibly 
due to UBSAN complaining about mpt3sas.

Patches were since provided for mpt3sas that got rid of the UBSAN error 
messages, but non-boot (later discovered to "just" being that boot 
wouldn't complete until after ~1½ hours) remained.

Just now, I discovered that the ~1½ hour boot time is unrelated to 
mpt3sas and is, instead, related to a quite specific set of circumstances:

 1. System has an optical media drive
     1. May even be specific to DVDRW  GUD0N
 2. The drive is loaded with a defective medium
     1. Disk is scratched, and for the longest time, I have been meaning
        to attempt a ddrescue but haven't gotten around to it

Pre-6.5-rc, a seek error would be reported, and that was that.

Since 6.5-rc, what happens instead, is that ATA speed negotiation will 
cycle between the various possible speeds, precluding the udevd queue 
from emptying, hence tying up systemd-udevd, for approximately 1½ hours, 
before boot eventually completes.

Pre-6.5-rc kernels still boot in reasonable time, as does 6.6-rc2 (and 
probably any in-between) if the drive tray is open during boot, 
precluding the bad medium from being attempted to be read.

Now, with optical drives going out of fashion and, presumably, with 
having defective media in such a drive during boot being even rarer, the 
likelihood of widespread impact is low, but given the extreme impact 
(boot time goes from <1m to ~1½h), and given the obvious wrongness of 
the behaviour in this scenario, I do think a fix would be in order.

I should obviously do a git bisect at some point, but until I have time 
for that, if someone happens to have an idea as to what commit might 
have effected the new behaviour, I shall be happy to test patches in the 
mean time.

/sune

NB: Koba Ko is Cc: since he responded to the 25/07 email. Koba, the 
UBSAN patches seem just perfect, and the boot problem turned out to be 
completely unrelated.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/kernel-team/attachments/20230919/43a72f5e/attachment-0001.html>