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

[Sune Mølgaard]

Hi Koba,

That link seems to be to the patch series that you pointed me to (thank 
you), when I thought the UBSAN thing was causing the excessive udevd 
queue wait.

I agree that the patch series eliminates the UBSAN complaints, but as I 
tried to say, the udevd queue wait problem persisted, and my email that 
you replied to here was to inform that the cause of the udevd queue 
queue wait problem seems completely unrelated, and that I have found a 
workaround for me, the nature of which points to a problematic change in 
the scsi_generic code between 6.4.0 and 6.5-rc1 that I have not yet had 
the time to do a proper git bisect to pinpoint.

That I mentioned you was merely to confirm the suspicions that the two 
ere unrelated, that I have aired on 
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2028830, which you 
were so kind as to open.

In essence, there was, apparently, a problem in scsi_generic that made 
the boot process stall long enough to make me notice the complaints from 
UBSAN, and it turns out that my interpretation of those complaints as 
being the cause of the boot stall was erroneous.

Thank you very much for your time in this, but unless you also happen to 
be in a position to reach out the person responsible for scsi_generic 
problem with faulty media in an optical drive leading to ~1½ hour ATA 
speed negotiation retries that hold up the udevd queue, feel free to 
just interpret my Cc:'ing you as a correction on my part for a faulty 
assumption of causality.

My very best regards,

Sune Mølgaard

-- 
Programming today is a race between software engineers striving to
build bigger and better idiot-proof programs, and the Universe trying
to produce bigger and better idiots. So far, the Universe is winning.
- Rich Cook

On 20/09/2023 07.22, Koba Ko wrote:
> Hi Sune,
> the maintainer has some comments on this series[0],
> it's still not merged.
>
> Ref. [0], https://lore.kernel.org/lkml/20230806170604.16143-11-james@equiv.tech/T/
>
> Thanks
> Koba Ko
>
> On Wed, Sep 20, 2023 at 4:36 AM Sune Mølgaard <sune at molgaard.org> wrote:
>> 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:
>>
>> System has an optical media drive
>>
>> May even be specific to DVDRW  GUD0N
>>
>> The drive is loaded with a defective medium
>>
>> 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.