Re: git: 2612f1b8649b - main - deadfs: Return ENXIO instead of EIO when the device is gone.
- Reply: Warner Losh : "Re: git: 2612f1b8649b - main - deadfs: Return ENXIO instead of EIO when the device is gone."
- In reply to: Poul-Henning Kamp: "Re: git: 2612f1b8649b - main - deadfs: Return ENXIO instead of EIO when the device is gone."
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Fri, 24 Oct 2025 11:49:11 UTC
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.