Re: git: 2612f1b8649b - main - deadfs: Return ENXIO instead of EIO when the device is gone.

--------
Konstantin Belousov writes:

> On Fri, Oct 24, 2025 at 07:41:11AM +0000, Poul-Henning Kamp wrote:

> >     Something changed recently, and while testing this fix, I noticed
> Nothing changed WRT code, it is just a race that causes the behavior.

That is why I wrote "something", because I agree that it is not code
in our tree which has changed.

> >     that drm-kmod-66/i915kms may be the condition which trigger
> >     the different code-path.

It worries me if loading drm-kmod-66/i915kms can cause this kind
of change of behaviour.

Even with the fix, I see 2-4 read(2) operations return EIO before
the ENXIO manifests.

The only hypothesis I have, is that something in DRM-world hogs
some kind of HW resource, but I do not have time (nor drm-skillz)
to look into that this morning, and I wanted to get the ENXIO fix
in for RELENG-15 purposes[1].

I'm also seeing two other "hmm, that's odd" things on -current these
days, but they are very specialized so I do not think they should
hold up 15:

A) When using a GreazeWeazle USB device, the USB connection will get stuck.

B) When using a Professional Canon document scanner, the USB
   connection will get stuck even before the first page is been received.

When I next get a chance, I am going to retry both of those scenarios
without loading drm-kmod-66/i915kms, to see if makes any difference.

Poul-Henning

[1]: As I remarked to re@: Measured in years, that is probably the oldest
bug I have ever fixed in FreeBSD:  According to dds' amazing UNIX
history it goes back to 4.4BSD, which means it's probably John Heidemann's
mistake.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.