Could it be http://www.freebsd.org/cgi/query-pr.cgi?pr=164445 ?
It looks like that fix from reply 3 is not in kernel 9.0-10+deb70 which
is what I'm running (but I have Wheezy userspace, so I haven't
reproduced a problem either)
Jeff
--
To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.o
Hi Jeff!
On 21/01/14 02:38, Jeff Epler wrote:
> Could it be http://www.freebsd.org/cgi/query-pr.cgi?pr=164445 ?
I think you might be right:
> From: Andriy Gapon
> On FreeBSD the ioctl(2) system call does copyin/copyout of the data argument
> and
> thus those extra copyin/copuout calls
This is about 100x times harder to reproduce running under ktrace but I
got lucky. The problematic syscall is right here:
> egrepRET read 32768/0x8000
> egrepCALL lseek(0,0,SEEK_CUR)
> egrepRET lseek 32768/0x8000
> egrepCALL lseek(0,0x8000,SEEK_HOLE)
> -egrepRET ls
found 736202 2.16-1
found 736202 2.14-3
# regression since this version
fixed 736202 2.12-2
thanks
I see the same thing in a sid chroot on a wheezy system (kfreebsd-amd64
9.0). Seems to affects grep 2.16-1 and 2.14-3, but not grep 2.12-2 from
wheezy running in the same chroot.
I found that in t
Package: ktrace
Version: 10.0-1
Severity: normal
Control: block -1 by 736198
A consequence of this is that kdump builds are no longer deterministic.
Sometimes
kdump will build with more "knowledge" (e.g. mount flags, ioctl names, etc) than
other times.
On 20/01/2014 23:12, Robert Millan wrote:
>
5 matches
Mail list logo
