Date: Fri, 24 Oct 2025 11:16:01 +0000 From: "Poul-Henning Kamp" <phk@phk.freebsd.dk> To: Konstantin Belousov <kostikbel@gmail.com> Cc: src-committers@freebsd.org, dev-commits-src-all@freebsd.org, dev-commits-src-main@freebsd.org Subject: Re: git: 2612f1b8649b - main - deadfs: Return ENXIO instead of EIO when the device is gone. Message-ID: <202510241116.59OBG1ii003074@critter.freebsd.dk> In-Reply-To: <aPtWo1UP-UpPdsVf@kib.kiev.ua> References: <202510240741.59O7fBAe041995@gitrepo.freebsd.org> <aPs27Dc_w10t3ENH@kib.kiev.ua> <202510241012.59OACUDA002781@critter.freebsd.dk> <aPtWo1UP-UpPdsVf@kib.kiev.ua>
index | next in thread | previous in thread | raw e-mail
-------- 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. -- 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.home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?202510241116.59OBG1ii003074>