Date: Fri, 1 Jan 2010 20:38:14 +0100 From: Jilles Tjoelker <jilles@stack.nl> To: Fernando =?iso-8859-1?Q?Apestegu=EDa?= <fernando.apesteguia@gmail.com> Cc: FreeBSD Hackers <freebsd-hackers@freebsd.org> Subject: Re: linprocfs Input/output error Message-ID: <20100101193814.GA60021@stack.nl> In-Reply-To: <1bd550a01001010945i1a043ff9t70eb814cafe4b30a@mail.gmail.com> References: <1bd550a01001010945i1a043ff9t70eb814cafe4b30a@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Jan 01, 2010 at 06:45:33PM +0100, Fernando Apesteguía wrote: > Hi all, I post here cause I didn't get any answers in freebsd-emulation. > In 8.0-RELEASE-p1 if I try to execute this: > cat /compat/linux/proc/cpuinfo > ~/cpuinfo.txt > I get > cat: /compat/linux/proc/cpuinfo: Input/output error > truss shows the read system call returns ERR#5. It is the same with > other files from linprocfs. > cat /compat/linux/proc/[any_file] works fine > What am I missing? You are not missing anything, this is a bug. A while ago, cat(1) was changed to use larger buffers when writing to regular files on machines with sufficient RAM, usually a multiple of MAXPHYS. On the other hand, pseudofs (the general framework for filesystems such as procfs, linprocfs and linsysfs) in src/sys/fs/pseudofs/pseudofs_vnops.c pfs_read() fails any read over MAXPHYS + 1 with EIO. This limit probably has to do with the allocation of a buffer of that size using sbuf_new(9) (and so, malloc(9)). Some sort of limit seems appropriate, but MAXPHYS seems unrelated, and if the request is too long it should perhaps just truncate it. -- Jilles Tjoelker
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100101193814.GA60021>