<!DOCTYPE html> <html> <head> <meta http-equiv="content-type" content="text/html; charset=UTF-8"> </head> <body> 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: <ol> <li>System has an optical media drive</li> <ol> <li>May even be specific to DVDRW GUD0N</li> </ol> <li>The drive is loaded with a defective medium</li> <ol> <li>Disk is scratched, and for the longest time, I have been meaning to attempt a ddrescue but haven't gotten around to it</li> </ol> </ol> 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. </body> </html>