Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 15 Nov 2001 23:56:13 EET
From:      Maxim Sobolev <sobomax@FreeBSD.org>
To:        marcus@marcuscom.com
Cc:        freebsd-ports@FreeBSD.org, hackers@FreeBSD.org
Subject:   Using bit 21 of EFLAGS in user-mode [was: Re: sigreturn: eflags creash (fixed!)]
Message-ID:  <200111152156.XAA79972@ipcard.iptcom.net>
In-Reply-To: <20011115145029.G47613-200000@shumai.marcuscom.com>

next in thread | previous in thread | raw e-mail | index | archive | help
This is a multi-part message in MIME format.

--192.168.1.100.0.992.1005861375.631.10189
Content-Type: text/plain

On Thu, 15 Nov 2001 14:56:31 -0500 (EST), Joe Clarke wrote:
> 
> I learned about this by reading through some of the -hackers archives.
> One person complained of similar errors trying to get xine to work on
> FreeBSD.  Removing the MMX detection code fixed it.  I remembered libpng
> also used MMX, so I removed the pnggccrd.c source, and voila!
> 
> Based on core dumps, strace output, and a lot of code surfing, this makes
> sense to me.  Basically, any png-dependent app's thread that runs longer
> than what ITIMER_PROF is set to gets hit with a SIGPROF.  When that
> happens, things context switch.  eflags must have been corrupted by the
> MMX code, thus sigreturn() bombs out, and causes uthread_kern to die as
> well.  Here's what strace looks like when balsa tries to read a 33 MB
> mailbox:
> 
> 74202 sigreturn(0x81f2c64
> 
> When this happens, strace politely dies with a bus error.
> 
> Thanks for testing this, Maxim.  Hopefully someone can find the problem
> and fix it for good.

That explains... After a quick glance at png code I found that
the only place where EFLAGS is altered is CPUID code, where
the library flips bit 21 of EFLAGS in order to ensure that the
CPUID instruction is supported (otherwise it will get SIGILL
on older processors). Unfortunately, for some reason FreeBSB
kernel considers bit 21 of EFLAGS as one that should not be
altered in the user mode, thus making it illegal to use standard
user-mode processor-detection routines based around that bit.
AFAIK, it is a bug in FreeBSD, because there is actually nothing
wrong with altering bit 21 in the user mode - it doesn't have
any side effects and pretty much any of the currently available
on the i386 OSes allows it.

Therefore, I would like to ask you to test attached patch and
if it works and there are no other objections I would like to
commit it shortly. To test the patch, you need to recompile
kernel with patch applied, reboot, recompile/reinstall png with
MXX support turned on and try to run Nautilus. Please let me know
if it helped or not.

Thanks!

-Maxim
--192.168.1.100.0.992.1005861375.631.10189
Content-Type: application/octet-stream;
    name="psl.h.diff"
Content-Transfer-Encoding: base64

SW5kZXg6IHN5cy9pMzg2L2luY2x1ZGUvcHNsLmgKPT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQpSQ1MgZmlsZTogL2hvbWUv
bmN2cy9zcmMvc3lzL2kzODYvaW5jbHVkZS9wc2wuaCx2CnJldHJpZXZpbmcgcmV2aXNpb24gMS4x
MApkaWZmIC1kIC11IC1yMS4xMCBwc2wuaAotLS0gc3lzL2kzODYvaW5jbHVkZS9wc2wuaAkyOCBB
dWcgMTk5OSAwMDo0NDoyMiAtMDAwMAkxLjEwCisrKyBzeXMvaTM4Ni9pbmNsdWRlL3BzbC5oCTE1
IE5vdiAyMDAxIDIxOjI1OjAyIC0wMDAwCkBAIC04Myw2ICs4Myw2IEBACiAgKiAzODYncy4KICAq
LwogI2RlZmluZQlQU0xfVVNFUkNIQU5HRSAoUFNMX0MgfCBQU0xfUEYgfCBQU0xfQUYgfCBQU0xf
WiB8IFBTTF9OIHwgUFNMX1QgXAotCQkJfCBQU0xfRCB8IFBTTF9WIHwgUFNMX05UIHwgUFNMX0FD
KQorCQkJfCBQU0xfRCB8IFBTTF9WIHwgUFNMX05UIHwgUFNMX0FDIHwgUFNMX0lEKQogCiAjZW5k
aWYgLyogIV9NQUNISU5FX1BTTF9IXyAqLwo=

--192.168.1.100.0.992.1005861375.631.10189--

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-ports" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200111152156.XAA79972>