From: Helge Deller <deller@gmx.de>
To: dann frazier <dannf@dannf.org>, Helge Deller <deller@gmx.de>,
Matt Taggart <taggart@debian.org>,
Christoph Martin <martin@uni-mainz.de>,
debian-hppa@lists.debian.org, debian-release@l
Cc: linux-parisc <linux-parisc@vger.kernel.org>
Subject: Re: HPPA and lenny (ruby1.9 build problems)
Date: Tue, 06 Jan 2009 00:46:34 +0100 [thread overview]
Message-ID: <49629BDA.4030904@gmx.de> (raw)
In-Reply-To: <20090105190209.GI932@anguilla.noreply.org>
CC: linux-paric mailing list
Peter Palfrader wrote:
> On Mon, 05 Jan 2009, dann frazier wrote:
>
>> On Tue, Dec 23, 2008 at 11:43:22AM +0100, Helge Deller wrote:
>>> Peter Palfrader wrote:
>>>> Helge Deller schrieb am Dienstag, dem 23. Dezember 2008:
>>>>
>>>>> Patch in parisc git tree:
>>>>> http://git.kernel.org/?p=linux/kernel/git/kyle/parisc-2.6.git;a=commitdiff;h=378fe7c4cc619b561409206605c723c05358edac;hp=6c4dfa8f8bcf032137aacb3640d7dd9d75b2b607
>>>> So just using an SMP kernel should also work?
>>> Probably yes, since some other developers tried initially to reproduce
>>> the problem, but they couldn't (as it seems they were running on newer
>>> SMP machines). But I don't have a SMP server which is why I can't test
>>> myself...
>> Unfortunately, it looks like we're still having problems on the
>> buildds w/ 2.6.26 SMP kernels:
>> http://buildd.debian.org/build.php?&pkg=ruby1.9&ver=1.9.0.2-9&arch=hppa&file=log
>>
>> The build doesn't take the system down, but does still hang
>> indefinitely while running miniruby - though the hang location varies.
>>
>> I'll prepare a UP kernel for one of the buildds w/ the
>> up-optimization-removal patch just to see if it improves things. I
>> don't see why it would, other than it seemed to solve the problem on
>> my test box when I first tested the patch.
It seemed to fix the problem for me as well.
In principle looking at the logs it looks more like a userspace bugs
due to threading functions.
Anyway, I'll try to reproduce it here as well.
FWIW, I had some additional irq locking code in load_context(), maybe
this helps...?
> Yeah, penalosa got stuck again today, this was on the console:
Does panalosa has the patched kernel (same one as the one on peri) ?
The protection ID traps shouldn't happen any longer, and from the buildd
logs on peri it does seem like that the ProtID traps don't happen there.
Helge
> ...
> [18255061.952000]
> [18255240.024000] install (pid 15737): Protection id trap (code 27) at
> 000000004038d203
> [18255240.116000] Backtrace:
> [18255240.148000]
> [18255258.720000] dpkg-deb (pid 15897): Protection id trap (code 27) at 00000000
> 4035defb
> [18255258.812000] Backtrace:
> [18255258.844000]
> [18260696.284000] dpkg-deb (pid 13540): Protection id trap (code 27) at 00000000
> 00026f1b
> [18260696.376000] Backtrace:
> [18260696.408000]
> [18289955.716000] ------------[ cut here ]------------
> [18289955.776000] kernel BUG at fs/inode.c:262!
I think this bug is unrelated to the ruby1.9 issue.
> [18289955.824000]
> [18289955.848000] YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
> [18289955.908000] PSW: 00001000000001001111111100001111 Tainted: G D
> [18289955.988000] r00-03 000000ff0804ff0f 00000000401e7888 00000000401e78a4 00000000a7d1d750
> [18289956.084000] r04-07 00000000405c9660 00000000a7d1d750 00000000404a5d40 000000012db86400
> [18289956.184000] r08-11 fffffffffffff000 0000000000017800 00000000000dc2f7 000000012f871828
> [18289956.284000] r12-15 000000007f9d7000 00000000000e7d58 00000000000081a4 0000000000000001
> [18289956.384000] r16-19 00000000000ad800 00000000000ad800 00000000000f4648 0000000040501e4c
> [18289956.480000] r20-23 000000000800000f 000000000800000f 000000012e623b40 0000000000000000
> [18289956.580000] r24-27 000000012f93a2c8 0000000000000000 00000000a7d1d750 00000000405c9660
> [18289956.680000] r28-31 0000000000000002 000000007d800690 000000007d8006c0 00000000002ac810
> [18289956.780000] sr00-03 0000000003ab8800 0000000000000000 0000000000000000 0000000003da5800
> [18289956.880000] sr04-07 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> [18289956.980000]
> [18289957.000000] IASQ: 0000000000000000 0000000000000000 IAOQ: 00000000401e78b0 00000000401e78b4
> [18289957.104000] IIR: 03ffe01f ISR: 0000000010340000 IOR: 000000f6000006c8
> [18289957.188000] CPU: 0 CR30: 000000007d800000 CR31: 0000000011111111
> [18289957.272000] ORIG_R28: 0000000000001000
> [18289957.324000] IAOQ[0]: clear_inode+0x28/0x178
> [18289957.376000] IAOQ[1]: clear_inode+0x2c/0x178
> [18289957.432000] RP(r2): clear_inode+0x1c/0x178
> [18289957.484000] Backtrace:
> [18289957.516000] [<00000000002b8844>] ext3_free_inode+0x19c/0x540 [ext3]
> [18289957.596000] [<00000000002bd0e0>] ext3_delete_inode+0x138/0x178 [ext3]
> [18289957.676000] [<00000000401e7bb8>] generic_delete_inode+0x120/0x1e0
> [18289957.756000] [<00000000401e7ca4>] generic_drop_inode+0x2c/0x200
> [18289957.828000] [<00000000401e6f50>] iput+0x80/0x90
> [18289957.888000] [<00000000401da980>] do_unlinkat+0x1b0/0x278
> [18289957.956000] [<00000000401daa60>] sys_unlink+0x18/0x28
> [18289958.020000] [<0000000040104ef8>] syscall_exit+0x0/0x14
> [18289958.084000]
> [18289958.108000] Backtrace:
> [18289958.136000] [<000000004011b154>] show_stack+0x14/0x20
> [18289958.204000] [<000000004011b178>] dump_stack+0x18/0x28
> [18289958.268000] [<000000004011b90c>] die_if_kernel+0x17c/0x230
> [18289958.336000] [<000000004011bc58>] handle_interruption+0x298/0x7f0
> [18289958.412000] [<00000000401e78b0>] clear_inode+0x28/0x178
> [18289958.480000] [<00000000002b8844>] ext3_free_inode+0x19c/0x540 [ext3]
> [18289958.560000] [<00000000002bd0e0>] ext3_delete_inode+0x138/0x178 [ext3]
> [18289958.640000] [<00000000401e7bb8>] generic_delete_inode+0x120/0x1e0
> [18289958.716000] [<00000000401e7ca4>] generic_drop_inode+0x2c/0x200
> [18289958.792000] [<00000000401e6f50>] iput+0x80/0x90
> [18289958.852000] [<00000000401da980>] do_unlinkat+0x1b0/0x278
> [18289958.916000] [<00000000401daa60>] sys_unlink+0x18/0x28
> [18289958.984000] [<0000000040104ef8>] syscall_exit+0x0/0x14
> [18289959.048000]
next prev parent reply other threads:[~2009-01-05 23:46 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20081213230739.GI20002@anguilla.noreply.org>
[not found] ` <4944C414.5090709@uni-mainz.de>
[not found] ` <20081215084913.766FCD75DF@taggart.lackof.org>
2008-12-15 11:27 ` HPPA and lenny Thibaut VARENE
[not found] ` <494666FB.9030907@gmx.de>
[not found] ` <20081215193025.GP20002@anguilla.noreply.org>
[not found] ` <20081215200749.GA30169@colo.lackof.org>
[not found] ` <4949787B.9070003@gmx.de>
[not found] ` <20081217222540.GB13477@colo.lackof.org>
[not found] ` <4950B3AD.1020200@gmx.de>
[not found] ` <20081223102356.GF19873@anguilla.noreply.org>
[not found] ` <4950C0CA.1040804@gmx.de>
[not found] ` <20090105180823.GC877@colo.lackof.org>
[not found] ` <20090105190209.GI932@anguilla.noreply.org>
2009-01-05 23:46 ` Helge Deller [this message]
2009-01-06 4:13 ` HPPA and lenny (ruby1.9 build problems) dann frazier
2009-01-06 16:21 ` Helge Deller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=49629BDA.4030904@gmx.de \
--to=deller@gmx.de \
--cc=dannf@dannf.org \
--cc=debian-hppa@lists.debian.org \
--cc=debian-release@l \
--cc=linux-parisc@vger.kernel.org \
--cc=martin@uni-mainz.de \
--cc=taggart@debian.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.