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

On Fri, Oct 24, 2025, 7:49 AM Konstantin Belousov <kostikbel@gmail.com>
wrote:

> On Fri, Oct 24, 2025 at 11:16:01AM +0000, Poul-Henning Kamp wrote:
> > --------
> > Konstantin Belousov writes:
> >
> > > On Fri, Oct 24, 2025 at 10:12:30AM +0000, Poul-Henning Kamp wrote:
> >
> > > I do not think that DRM really affects the code path for io.
> >
> > 100% agreement.
> >
> > But it can change the order of thread/interrupt/event-handling
> > scheduling.
> >
> > When I tested the ENXIO patch, I started booting an unmodified
> > kernel in single-user and immediately got ENXIO when I pulled
> > the USB stick - quite to my surprise.
> >
> > Then I kldloaded i915kms, still in single-user, and now I got
> > the observed bad EIO behaviour.
> >
> > With a fixed kernel and i915kms loaded, I saw four or five reads
> > return EIO before one got ENXIO and terminated recoverdisk.
> >
> > Getting a handful of EIO's before the ENXIO finally appears
> > strongly suggests that some of the eventhandling related to
> > the disappearing USB stick is being held up by something.
> >
> > As soon as I can, I'll try to gather more data.
>
> It might make sense to annotate CAM EIOs with EXTERROR().
> But then, we probably need to add something to copy that
> extended data between threads and possibly extend struct buf/bio
> witg the place for exterror data besides b_error.
>

Given the contexts cam runs in, managing the storage for that can be hard.

Warner

>