From mboxrd@z Thu Jan 1 00:00:00 1970 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 04 Jan 2008 01:19:31 +0000 (GMT) Received: from mail.zeugmasystems.com ([192.139.122.66]:51303 "EHLO zeugmasystems.com") by ftp.linux-mips.org with ESMTP id S20022105AbYADBTW (ORCPT ); Fri, 4 Jan 2008 01:19:22 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C84E6F.A6F04519" Subject: BUG: BUS error while returning from read() in /dev/oprofile/buffer Date: Thu, 3 Jan 2008 17:18:01 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: BUG: BUS error while returning from read() in /dev/oprofile/buffer Thread-Index: AchOb6YezCF8sxJbR7Ou5yLm8ezCzg== From: "Anirban Sinha" To: , "Ralf Baechle" Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17909 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ASinha@zeugmasystems.com Precedence: bulk X-list: linux-mips This is a multi-part message in MIME format. ------_=_NextPart_001_01C84E6F.A6F04519 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi: =20 I have been trying to hunt down this bug for several days now. What mainly happens is that when oprofiled wakes up from read() in /dev/oprofile/buffer on receiving a signal USR1 (i.e, when someone does opcontrol -start after doing opcontrol-start-daemon), it somehow gets SIGBUS within glibc read(). We are using a mips machine with Sybyte SB1 processor. On intel, this error does not show up. Interestingly, when I tried running a small test program that simply reads /dev/oprofile/buffer, the error can't be reproduced!=20 =20 Ralf and others, any insights, suggestions or useful comments from experience will be really really appreciated. I am spending a lot of time trying to fix this bug. =20 Cheers, =20 Ani =20 ------_=_NextPart_001_01C84E6F.A6F04519 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi:

I have been trying to hunt down this bug for = several days now. What mainly happens is that when oprofiled wakes up from read() in /dev/oprofile/buffer on receiving a signal USR1 (i.e, when someone does opcontrol –start after doing opcontrol—start-daemon), it = somehow gets SIGBUS within glibc read(). We are using a mips machine with = Sybyte SB1 processor. On intel, this error does not show up. Interestingly, = when I tried running a small test program that simply reads = /dev/oprofile/buffer, the error can’t be reproduced!

Ralf and others, any insights, suggestions or = useful comments from experience will be really really appreciated. I am = spending a lot of time trying to fix this bug.

Cheers,

Ani

------_=_NextPart_001_01C84E6F.A6F04519-- From mboxrd@z Thu Jan 1 00:00:00 1970 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 04 Jan 2008 01:28:10 +0000 (GMT) Received: from smtp1.dnsmadeeasy.com ([205.234.170.144]:47051 "EHLO smtp1.dnsmadeeasy.com") by ftp.linux-mips.org with ESMTP id S20024116AbYADB2A (ORCPT ); Fri, 4 Jan 2008 01:28:00 +0000 Received: from smtp1.dnsmadeeasy.com (localhost [127.0.0.1]) by smtp1.dnsmadeeasy.com (Postfix) with ESMTP id 0799F311B0A; Fri, 4 Jan 2008 01:28:07 +0000 (UTC) X-Authenticated-Name: js.dnsmadeeasy X-Transit-System: In case of SPAM please contact abuse@dnsmadeeasy.com Received: from avtrex.com (unknown [67.116.42.147]) by smtp1.dnsmadeeasy.com (Postfix) with ESMTP; Fri, 4 Jan 2008 01:28:06 +0000 (UTC) Received: from [192.168.7.26] ([192.168.7.26]) by avtrex.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 3 Jan 2008 17:27:44 -0800 Message-ID: <477D8B90.9020701@avtrex.com> Date: Thu, 03 Jan 2008 17:27:44 -0800 From: David Daney User-Agent: Thunderbird 1.5.0.12 (X11/20071019) MIME-Version: 1.0 To: Anirban Sinha Cc: linux-mips@linux-mips.org, Ralf Baechle Subject: Re: BUG: BUS error while returning from read() in /dev/oprofile/buffer References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 04 Jan 2008 01:27:44.0793 (UTC) FILETIME=[01C3A890:01C84E71] Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17910 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ddaney@avtrex.com Precedence: bulk X-list: linux-mips Anirban Sinha wrote: > Hi: > > > > I have been trying to hunt down this bug for several days now. What > mainly happens is that when oprofiled wakes up from read() in > /dev/oprofile/buffer on receiving a signal USR1 (i.e, when someone does > opcontrol –start after doing opcontrol—start-daemon), it somehow gets > SIGBUS within glibc read(). We are using a mips machine with Sybyte SB1 > processor. On intel, this error does not show up. Interestingly, when I > tried running a small test program that simply reads > /dev/oprofile/buffer, the error can’t be reproduced! > > > > Ralf and others, any insights, suggestions or useful comments from > experience will be really really appreciated. I am spending a lot of > time trying to fix this bug. > Likely you did a cross build of bash and your signal numbers are incorrect. On the system where you built bash, SIGUSR1 is 10. On the mips-linux target signal 10 is SIGBUS so when the bash kill builtin thinks it is sending SIGUSR1 it is really sending SIGBUS. David Daney From mboxrd@z Thu Jan 1 00:00:00 1970 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 04 Jan 2008 17:57:00 +0000 (GMT) Received: from mail.zeugmasystems.com ([192.139.122.66]:46020 "EHLO zeugmasystems.com") by ftp.linux-mips.org with ESMTP id S20024116AbYADR4v (ORCPT ); Fri, 4 Jan 2008 17:56:51 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C84EFB.2AD3F165" Subject: RE: BUS error while returning from read() in /dev/oprofile/buffer Date: Fri, 4 Jan 2008 09:56:39 -0800 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: BUS error while returning from read() in /dev/oprofile/buffer Thread-Index: AchOb6YezCF8sxJbR7Ou5yLm8ezCzgAidH0w References: From: "Anirban Sinha" To: Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17913 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ASinha@zeugmasystems.com Precedence: bulk X-list: linux-mips This is a multi-part message in MIME format. ------_=_NextPart_001_01C84EFB.2AD3F165 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable First a correction. My test program does terminate with a bus error on receiving signal USR1. Just in case anyone is interested - It turned out that the BUS error results from the fact that when coreutils was built, it used the signal numbers from the devel machine (x86). These numbers are different from our mips kernel on which we want to use oprofile (mips has slightly different signal numbers from x86). Many thanks to David Daney for drawing my attention to this. =20 Cheers, =20 Ani =20 =20 From: linux-mips-bounce@linux-mips.org [mailto:linux-mips-bounce@linux-mips.org] On Behalf Of Anirban Sinha Sent: Thursday, January 03, 2008 5:18 PM To: linux-mips@linux-mips.org; Ralf Baechle Subject: BUG: BUS error while returning from read() in /dev/oprofile/buffer =20 Hi: =20 I have been trying to hunt down this bug for several days now. What mainly happens is that when oprofiled wakes up from read() in /dev/oprofile/buffer on receiving a signal USR1 (i.e, when someone does opcontrol -start after doing opcontrol-start-daemon), it somehow gets SIGBUS within glibc read(). We are using a mips machine with Sybyte SB1 processor. On intel, this error does not show up. Interestingly, when I tried running a small test program that simply reads /dev/oprofile/buffer, the error can't be reproduced!=20 =20 Ralf and others, any insights, suggestions or useful comments from experience will be really really appreciated. I am spending a lot of time trying to fix this bug. =20 Cheers, =20 Ani =20 ------_=_NextPart_001_01C84EFB.2AD3F165 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

First a correction. = My test program does terminate with a bus error on receiving signal USR1. Just = in case anyone is interested - It turned out that the BUS error results from the fact = that when coreutils was built, it used the signal numbers from the devel = machine (x86). These numbers are different from our mips kernel on which we want = to use oprofile (mips has slightly different signal numbers from x86). Many = thanks to David Daney for drawing my attention to this.

Cheers,

Ani

From:= linux-mips-bounce@linux-mips.org = [mailto:linux-mips-bounce@linux-mips.org] On Behalf Of Anirban Sinha
Sent: Thursday, January 03, 2008 5:18 PM
To: linux-mips@linux-mips.org; Ralf Baechle
Subject: BUG: BUS error while returning from read() in /dev/oprofile/buffer

Hi:

I have been trying to hunt down this bug for = several days now. What mainly happens is that when oprofiled wakes up from read() in /dev/oprofile/buffer on receiving a signal USR1 (i.e, when someone does opcontrol –start after doing opcontrol—start-daemon), it = somehow gets SIGBUS within glibc read(). We are using a mips machine with = Sybyte SB1 processor. On intel, this error does not show up. Interestingly, = when I tried running a small test program that simply reads = /dev/oprofile/buffer, the error can’t be reproduced!

Ralf and others, any insights, suggestions or = useful comments from experience will be really really appreciated. I am = spending a lot of time trying to fix this bug.

Cheers,

Ani

------_=_NextPart_001_01C84EFB.2AD3F165-- From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail.zeugmasystems.com ([192.139.122.66]:51303 "EHLO zeugmasystems.com") by ftp.linux-mips.org with ESMTP id S20022105AbYADBTW (ORCPT ); Fri, 4 Jan 2008 01:19:22 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C84E6F.A6F04519" Subject: BUG: BUS error while returning from read() in /dev/oprofile/buffer Date: Thu, 3 Jan 2008 17:18:01 -0800 Message-ID: From: "Anirban Sinha" Return-Path: Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org To: linux-mips@linux-mips.org, Ralf Baechle Message-ID: <20080104011801.Y-csK_0c0dat65fh4e4nC5_lUMYzbq9BpKAXLBeIs1o@z> This is a multi-part message in MIME format. ------_=_NextPart_001_01C84E6F.A6F04519 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi: =20 I have been trying to hunt down this bug for several days now. What mainly happens is that when oprofiled wakes up from read() in /dev/oprofile/buffer on receiving a signal USR1 (i.e, when someone does opcontrol -start after doing opcontrol-start-daemon), it somehow gets SIGBUS within glibc read(). We are using a mips machine with Sybyte SB1 processor. On intel, this error does not show up. Interestingly, when I tried running a small test program that simply reads /dev/oprofile/buffer, the error can't be reproduced!=20 =20 Ralf and others, any insights, suggestions or useful comments from experience will be really really appreciated. I am spending a lot of time trying to fix this bug. =20 Cheers, =20 Ani =20 ------_=_NextPart_001_01C84E6F.A6F04519 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi:

I have been trying to hunt down this bug for = several days now. What mainly happens is that when oprofiled wakes up from read() in /dev/oprofile/buffer on receiving a signal USR1 (i.e, when someone does opcontrol –start after doing opcontrol—start-daemon), it = somehow gets SIGBUS within glibc read(). We are using a mips machine with = Sybyte SB1 processor. On intel, this error does not show up. Interestingly, = when I tried running a small test program that simply reads = /dev/oprofile/buffer, the error can’t be reproduced!

Ralf and others, any insights, suggestions or = useful comments from experience will be really really appreciated. I am = spending a lot of time trying to fix this bug.

Cheers,

Ani

------_=_NextPart_001_01C84E6F.A6F04519-- From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail.zeugmasystems.com ([192.139.122.66]:46020 "EHLO zeugmasystems.com") by ftp.linux-mips.org with ESMTP id S20024116AbYADR4v (ORCPT ); Fri, 4 Jan 2008 17:56:51 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C84EFB.2AD3F165" Subject: RE: BUS error while returning from read() in /dev/oprofile/buffer Date: Fri, 4 Jan 2008 09:56:39 -0800 Message-ID: In-Reply-To: References: From: "Anirban Sinha" Return-Path: Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org To: linux-mips@linux-mips.org Message-ID: <20080104175639.BT5VSsLyzFoLeNhEx-IdRfLMtJhbsGLypydmkKvk-_k@z> This is a multi-part message in MIME format. ------_=_NextPart_001_01C84EFB.2AD3F165 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable First a correction. My test program does terminate with a bus error on receiving signal USR1. Just in case anyone is interested - It turned out that the BUS error results from the fact that when coreutils was built, it used the signal numbers from the devel machine (x86). These numbers are different from our mips kernel on which we want to use oprofile (mips has slightly different signal numbers from x86). Many thanks to David Daney for drawing my attention to this. =20 Cheers, =20 Ani =20 =20 From: linux-mips-bounce@linux-mips.org [mailto:linux-mips-bounce@linux-mips.org] On Behalf Of Anirban Sinha Sent: Thursday, January 03, 2008 5:18 PM To: linux-mips@linux-mips.org; Ralf Baechle Subject: BUG: BUS error while returning from read() in /dev/oprofile/buffer =20 Hi: =20 I have been trying to hunt down this bug for several days now. What mainly happens is that when oprofiled wakes up from read() in /dev/oprofile/buffer on receiving a signal USR1 (i.e, when someone does opcontrol -start after doing opcontrol-start-daemon), it somehow gets SIGBUS within glibc read(). We are using a mips machine with Sybyte SB1 processor. On intel, this error does not show up. Interestingly, when I tried running a small test program that simply reads /dev/oprofile/buffer, the error can't be reproduced!=20 =20 Ralf and others, any insights, suggestions or useful comments from experience will be really really appreciated. I am spending a lot of time trying to fix this bug. =20 Cheers, =20 Ani =20 ------_=_NextPart_001_01C84EFB.2AD3F165 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

First a correction. = My test program does terminate with a bus error on receiving signal USR1. Just = in case anyone is interested - It turned out that the BUS error results from the fact = that when coreutils was built, it used the signal numbers from the devel = machine (x86). These numbers are different from our mips kernel on which we want = to use oprofile (mips has slightly different signal numbers from x86). Many = thanks to David Daney for drawing my attention to this.

Cheers,

Ani

From:= linux-mips-bounce@linux-mips.org = [mailto:linux-mips-bounce@linux-mips.org] On Behalf Of Anirban Sinha
Sent: Thursday, January 03, 2008 5:18 PM
To: linux-mips@linux-mips.org; Ralf Baechle
Subject: BUG: BUS error while returning from read() in /dev/oprofile/buffer

Hi:

I have been trying to hunt down this bug for = several days now. What mainly happens is that when oprofiled wakes up from read() in /dev/oprofile/buffer on receiving a signal USR1 (i.e, when someone does opcontrol –start after doing opcontrol—start-daemon), it = somehow gets SIGBUS within glibc read(). We are using a mips machine with = Sybyte SB1 processor. On intel, this error does not show up. Interestingly, = when I tried running a small test program that simply reads = /dev/oprofile/buffer, the error can’t be reproduced!

Ralf and others, any insights, suggestions or = useful comments from experience will be really really appreciated. I am = spending a lot of time trying to fix this bug.

Cheers,

Ani

------_=_NextPart_001_01C84EFB.2AD3F165--