Closed Bug 601222 Opened 10 years ago Closed 10 years ago
Blacklist tracejit and methodjit on samsung i9000 devices
+++ This bug was initially created as a clone of Bug #600488 +++ Spun off from bug 600596 and bug 600488, which now need to block betaN instead of beta1 (I don't have those powers).
On my vibrant, this makes -j testComparisons.js crash go away. With os.environ['JS_IGNORE_JIT_BROKENNESS'] = '1' args = [ JS, 'basic/testComparisons.js', '--show-cmd', '--show-output', '--avoid-stdio', '--jitflags', 'j', ] it comes back. This is a gross hack, but the precedent is && JSC::MacroAssemblerX86Common::getSSEState() >= JSC::MacroAssemblerX86Common::HasSSE2 To my knowledge, we don't have a cleaner way of checking the host CPU.
Assignee: general → jones.chris.g
Attachment #480221 - Flags: review?(dvander)
10 years ago
Attachment #480221 - Flags: review?(dvander) → review+
http://hg.mozilla.org/mozilla-central/rev/4791cfde3ca0 (relbranch) http://hg.mozilla.org/mozilla-central/rev/9c2484dac245 Sigh.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
It struck me while I was walking to dinner that it might have been a good idea to write something to logcat when we disable JIT. Ah well, maybe can get that in if we respin.
It's really too bad that this went in with an env var instead of a pref :( The jit issue seems fixed with Android 2.2, but it's very difficult to enable the jit now.
Maybe we could change the blacklist to also depend on the OS version, or the kernel version. The leaked Android 2.2 image for Captivate (I assume this is the one that Vlad is testing) uses kernel 184.108.40.206 according to this page (compared to 2.6.29 in the shipping Android 2.1 images): http://forum.xda-developers.com/showthread.php?t=797282&page=8
(In reply to comment #4) > The > jit issue seems fixed with Android 2.2, but it's very difficult to enable the > jit now. How did you test the JIT? (It's easy to enable for test with the script here https://wiki.mozilla.org/Mobile/Fennec/Android#JS_trace-tests.) If it's indeed fixed, yes, we should pass 2.2 through.
Well, I tested by running sunspider and kraken, and browsing for about 20-30 minutes with no hangs. I've never been able to browse that long before without issues. I'll give the tests a try when I get a chance.
The blacklist in the patch doesn't include the string "GT-I9000" which is what my (UK/European, non-carrier-model) Galaxy S has for 'Hardware' according to /proc/cpuinfo. Should it?
If there's a significant number of these running 2.1 (eclair), then yes.
Samsung have not yet officially released Froyo firmware for the device; besides those using leaked or community builds, every Galaxy S runs 2.1-update1. Also, note that updates are via Samsung's "Kies" software rather than OTA, so uptake of 2.2 (rumoured to arrive later this month) will be slow. The device is on the majority of UK carriers and is reasonably popular.
10 years ago
Samsung has officially realeased froyo for Galaxy S phones, most carriers in the US have not decided to release it yet. Although fully legit leaked versions of froyo for galaxy s phones are available.
You need to log in before you can comment on or make changes to this bug.