From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1QaYAn-0006cZ-Sf for garchives@archives.gentoo.org; Sat, 25 Jun 2011 19:05:42 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 7A1B11C1DC for ; Sat, 25 Jun 2011 19:05:41 +0000 (UTC) Received: from mail-wy0-f181.google.com (mail-wy0-f181.google.com [74.125.82.181]) by pigeon.gentoo.org (Postfix) with ESMTP id 4EA7D1C19D for ; Sat, 25 Jun 2011 18:29:15 +0000 (UTC) Received: by wyh22 with SMTP id 22so843767wyh.40 for ; Sat, 25 Jun 2011 11:29:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:from:to:cc:subject:date:message-id:user-agent :in-reply-to:references:mime-version:content-transfer-encoding :content-type; bh=1ZByZ4MAiuZ5XlsO90zObi7/Rz53jz16IDRfmLTmuKE=; b=ujA33aI2ov5muS2ntO0xhBMPmRGA514LsuFZdhzuXxIbA5OKH5lKspAGNrxLOfFTCM aveUb9a8eyR4GDOne2WqjXtoL57nTcKubkyHBQQ+g0g6YIRh0ueDPbgxYwd7Iw/dWoOs JBetE9ej3dskvVjsgChxKC6+aHtgza0Os2HG8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:subject:date:message-id:user-agent:in-reply-to :references:mime-version:content-transfer-encoding:content-type; b=tdMXLadgj3RRc/pKE8sEJN1SdxpQadsWaR/3y0MorSRWjHEvhq00K9h4tQoRIitsdW HdnyNOMyOreculnmdvMKStI9tmE5Qh3ZJ8m64JGi2JY8FoSyHqBo6XdAr0iqv3Hy6mDE ZvlUnzlibB1WnTYXCIZAY0bJeqKAgjiIdbOgc= Received: by 10.227.201.78 with SMTP id ez14mr4063145wbb.43.1309026554273; Sat, 25 Jun 2011 11:29:14 -0700 (PDT) Received: from nazgul.localnet (196-210-183-215.dynamic.isadsl.co.za [196.210.183.215]) by mx.google.com with ESMTPS id fe4sm2065782wbb.28.2011.06.25.11.29.11 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 25 Jun 2011 11:29:13 -0700 (PDT) From: Alan McKinnon To: gentoo-user@lists.gentoo.org Cc: =?ISO-8859-1?Q?Andr=E1s_Cs=E1nyi?= Subject: Re: [gentoo-user] chrome and everything Date: Sat, 25 Jun 2011 20:28:05 +0200 Message-ID: <1843820.dYirHz2lF9@nazgul> User-Agent: KMail/4.6.0 (Linux/2.6.39-ck; KDE/4.6.4; x86_64; ; ) In-Reply-To: References: <201106021121.52021.alan.mckinnon@gmail.com> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Archives-Salt: X-Archives-Hash: 590ad91950d4554268a17f71a1fe3775 On Saturday 25 June 2011 18:38:10 Andr=C3=A1s Cs=C3=A1nyi did opine thu= sly: > On 2 June 2011 11:21, Alan McKinnon wrote: > > Chromium is not the problem, Flash is the problem. > >=20 > > Flash is a piece of shit that has never worked right and Adobe > > are a bunch of fools that cannot code properly or securely. I > > can comfortably say this based on long hard bitter experience > > by the entire Linux community. > >=20 > > If you choose to use Flash, you get to put up with the resulting > > problems. >=20 > I'm not sure the Flash is the problem. Chromium uses Flash through > nspluginwrapper. I removed nspluginwrapper package and I recompiled > few package which depended on nspluginwrapper package. And Chromium > freezin and creating a D process as you can see on this picture. [1] >=20 > http://sayusi.hu/blog/picture_about_htop >=20 > I asked my friends - they are *nix administrators, and they told me > this below could be helpful. However, I don't have any idea what it > means. Flash is still the root cause, nspluginwrapper is only a symptom. Flash is notorious for having to fix the same issues over and over=20 again in different bits of their code. Not only that, but they keep=20 making the same mistakes repeatedly - a very common problem with=20 proprietary code driven by deadline and profit-motivated managers. nspluginwrapper does it's best to cope with this ever-changing=20 landscape, but you can't really blame it when things go wrong - Flash=20= changes something and don't publish what has now changed.=20 nspluginwrapper can't deal with the change, so it breaks. This will never change, because you can't pick up a turd by the clean=20= end. You could submit your stacktrace below to a bug entry at b.g.o. and=20 let the gentoo dev look at it. Most likely he will refer it upstream. >=20 > sa-home sayusi # cat /proc/6725/wchan > call_rwsem_down_read_failed > sa-home sayusi # >=20 > The callstack look like this (the copied just a part of it): > Jun 25 18:33:38 sa-home eep+0x7c/0x80 > Jun 25 18:33:38 sa-home kernel: [] > system_call_fastpath+0x16/0x1b > Jun 25 18:33:38 sa-home kernel: chrome S ffff8800b334b790 > 0 6923 6730 0x00000000 > Jun 25 18:33:38 sa-home kernel: ffff8800a6c47c48 0000000000000086 > ffff8800a6c47b18 ffffffff8109fe4a > Jun 25 18:33:38 sa-home kernel: ffff8800a6c47fd8 ffff8800a6c46010 > 0000000000000001 ffff8800b334b9a0 > Jun 25 18:33:38 sa-home kernel: 0000000000004000 000000000000d580 > ffff8800a6c47fd8 00000001a6c47d48 > Jun 25 18:33:38 sa-home kernel: Call Trace: > Jun 25 18:33:38 sa-home kernel: [] ? > zone_watermark_ok+0x1a/0x20 > Jun 25 18:33:38 sa-home kernel: [] ? > timerqueue_add+0x60/0xb0 > Jun 25 18:33:38 sa-home kernel: [] ? > __hrtimer_start_range_ns+0x1df/0x3d0 > Jun 25 18:33:38 sa-home kernel: [] ? > get_futex_key+0x15a/0x1c0 > Jun 25 18:33:38 sa-home kernel: [] > futex_wait_queue_me+0xc5/0x100 > Jun 25 18:33:38 sa-home kernel: [] > futex_wait+0x1ac/0x290 > Jun 25 18:33:38 sa-home kernel: [] ? > update_rmtp+0x80/0x80 > Jun 25 18:33:38 sa-home kernel: [] > do_futex+0x101/0xac0 > Jun 25 18:33:38 sa-home kernel: [] ? > handle_mm_fault+0x120/0x230 > Jun 25 18:33:38 sa-home kernel: [] ? > do_page_fault+0x1ac/0x430 > Jun 25 18:33:38 sa-home kernel: [] ? > do_mmap_pgoff+0x344/0x390 > Jun 25 18:33:38 sa-home kernel: [] > sys_futex+0x76/0x170 > Jun 25 18:33:38 sa-home kernel: [] ? > sys_mmap_pgoff+0x100/0x190 > Jun 25 18:33:38 sa-home kernel: [] > system_call_fastpath+0x16/0x1b > Jun 25 18:33:38 sa-home kernel: chrome S 0000000000000001 > 0 6927 6730 0x00000000 > Jun 25 18:33:38 sa-home kernel: ffff8800a6d0bda8 0000000000000086 > 0000000000000001 ffff88013f4c1710 > Jun 25 18:33:38 sa-home kernel: ffff8800a6d0bfd8 ffff8800a6d0a010 > 0000000000000001 ffff8800a6c8eec0 > Jun 25 18:33:38 sa-home kernel: 0000000000004000 000000000000d580 > ffff8800a6d0bfd8 000000018171eec8 > Jun 25 18:33:38 sa-home kernel: Call Trace: > Jun 25 18:33:38 sa-home kernel: [] ? > sock_aio_read+0x16d/0x180 > Jun 25 18:33:38 sa-home kernel: [] ? > __mutex_lock_slowpath+0x1c0/0x260 > Jun 25 18:33:38 sa-home kernel: [] ? > sock_poll+0x15/0x20 > Jun 25 18:33:38 sa-home kernel: [] > schedule_hrtimeout_range_clock+0x115/0x130 > Jun 25 18:33:38 sa-home kernel: [] ? > mutex_unlock+0x9/0x10 > Jun 25 18:33:38 sa-home kernel: [] ? > ep_scan_ready_list+0x183/0x190 > Jun 25 18:33:38 sa-home kernel: [] > schedule_hrtimeout_range+0xe/0x10 > Jun 25 18:33:38 sa-home kernel: [] > ep_poll+0x2ec/0x350 > Jun 25 18:33:38 sa-home kernel: [] ? > try_to_wake_up+0x120/0x120 > Jun 25 18:33:38 sa-home kernel: [] > sys_epoll_wait+0xc5/0xe0 > Jun 25 18:33:38 sa-home kernel: [] > system_call_fastpath+0x16/0x1b > Jun 25 18:33:38 sa-home kernel: SignalSender S ffff8800b3f079d0 > 0 6928 6730 0x00000000 > Jun 25 18:33:38 sa-home kernel: ffff8800a6c85c48 0000000000000086 > 0000000000000000 ffffffff81611020 > Jun 25 18:33:38 sa-home kernel: ffff8800a6c85fd8 ffff8800a6c84010 > 0000000000000000 ffff8800b3f07be0 > Jun 25 18:33:38 sa-home kernel: 0000000000004000 000000000000d580 > ffff8800a6c85fd8 0000000000000000 >=20 > My question is that, should I report it on bugs.gentoo.org? By the > way, this bug is not depend on the version. --=20 alan dot mckinnon at gmail dot com