From owner-freebsd-arm@freebsd.org Wed Sep 2 14:47:39 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8BEB49C831F for ; Wed, 2 Sep 2015 14:47:39 +0000 (UTC) (envelope-from onwahe@gmail.com) Received: from mail-ig0-x22f.google.com (mail-ig0-x22f.google.com [IPv6:2607:f8b0:4001:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 511BDA81; Wed, 2 Sep 2015 14:47:39 +0000 (UTC) (envelope-from onwahe@gmail.com) Received: by igcpb10 with SMTP id pb10so27123972igc.1; Wed, 02 Sep 2015 07:47:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ewR214g+abQzzLKihrolUBe77iTXTJyP9s/xSK6cHIQ=; b=rJpcqy92V86cu7hsXY5oO7LmqX/nwgX8RtC6wcTmy9FvrvqmlBeYBvxui7RcjKhaLw d95GNlmowGY//I/o6vx4bNGfFhteBpcGAGmLKOworMs82fbD1OQ/oNU/R9dxJNUPZUP1 Ue6FPWdz8O9lhSwyw9w5/n/8KEKwVKhex7iLhXRjqmhEwheXEseCnK5/IkkXDN9LKc5v 4AEcTCs4MYlH75vjCwTxDopfjmrxTGzMGcXDuzjWowiWPeLX2HY2N4zX3XJiTcFd/a2O tA8HccabDXPKByqieoODqLOCoKrPdOlOYDznHM8pMtpEzC3Fxn1EYlhTx90i0gy3DJI8 GL9w== MIME-Version: 1.0 X-Received: by 10.50.26.66 with SMTP id j2mr3412528igg.42.1441205258541; Wed, 02 Sep 2015 07:47:38 -0700 (PDT) Received: by 10.64.239.196 with HTTP; Wed, 2 Sep 2015 07:47:38 -0700 (PDT) In-Reply-To: <20150901130117.GK1245@hades.panopticon> References: <20150819120753.GH79354@hades.panopticon> <20150819134708.GJ79354@hades.panopticon> <20150819232836.GA1245@hades.panopticon> <20150820185417.GB1245@hades.panopticon> <20150820201020.GC1245@hades.panopticon> <20150901130117.GK1245@hades.panopticon> Date: Wed, 2 Sep 2015 16:47:38 +0200 Message-ID: Subject: Re: Instability likely related to new pmap on Cubieboard A10 From: Svatopluk Kraus To: Dmitry Marakasov Cc: Adrian Chadd , "freebsd-arm@FreeBSD.org" , Ian Lepore Content-Type: multipart/mixed; boundary=047d7bd75bb27c36d0051ec4bf6f X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2015 14:47:39 -0000 --047d7bd75bb27c36d0051ec4bf6f Content-Type: text/plain; charset=UTF-8 On Tue, Sep 1, 2015 at 3:01 PM, Dmitry Marakasov wrote: > * Svatopluk Kraus (onwahe@gmail.com) wrote: > >> >> Thanks. Meantime, I tried most recent HEAD on pandaboard and >> >> beaglebone black and no problem there. Do you have enabled INVARIANTS >> >> and INVARIANT_SUPPORT in your config? >> > >> > I've enabled them at some point - at least last two runs had these >> > enabled. Any other way I could help? Maybe I should check if it was >> > new pmap commit which caused this, and if not, bisect it? >> > >> >> Can you try attached semi-debug patch, please? I want to be sure that >> problem is not on patched place. > > Sorry for delay, I was short on time last week, and then I was busy with > setting up tftp/nfs netboot for my cubieboard. Now it finally works > and I'd say it's pretty cool when I can test another build without > plugging sd card around. Unfortunately, with this setup panic doesn't > reproduce: there are just around 10 sh(1) segfaults during init, and > then it boots into somehow usable state. Only once I've had panic with > your latest patch applied: > > https://people.freebsd.org/~amdmi3/pmap4.log > > With my new netboot, I plan to try to bisect it; for panic debugging I > guess I'll have to get back to plugging SD around. If you want me to do > more panic tests, could we please revisit which patches should be > applied cause I'm kinda lost in them. > Okay then, here is my summary: I thought that segmentation faults and panic(s) are caused by two different things. Now, it looks that they are not. The logs of old configuration with sd card, you provided, shows that something is corrupting kernel memory. Three logs and three quite different corruptions. So now, I would like to focus to segmentation faults which points to some corruption too. As you are only one who reports this kind of problem, it's probably related to your hardware or the way how your system is booted. Thus, if you would be so kind: (A1) Use only one hardware configuration now. I like to investigate the segmentation faults, so you may use netboot. (A2) Start with clean, up to date kernel without any patches to learn how the system behaves. (A3) You can try to use old pmap, however, the result has no relevance. Note that with old pmap, the system memory layout is different, the system timing is different (for example, when a process is forking), and pointless cache and TLB operation are done in addition. (A4) Apply attached patch, enable KTR, set KTR_MASK to KTR_TRAP, and when system breaks to debugger, send me output from the following commands: "show ktr" ... at least 10 lines but more is better ;) "show pmap /u" (A5) If you type "continue", you can repeat step A4 and send me info from more segmentation faults at once. (A6) If you got panic, send me kernel file together with panic backtrace. (B) Another thing you could try is to omit in you configuration as many devices as possible. Mainly the ones which use DMA. For example, boot from sd card without network driver compiled in and vice versa. (C) If you think that there was kernel revision including new pmap which worked without problems, confirm that please and tell me which one it was. Svata --047d7bd75bb27c36d0051ec4bf6f Content-Type: text/plain; charset=US-ASCII; name="pmap_debug3.diff" Content-Disposition: attachment; filename="pmap_debug3.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_ie2w51dx0 SW5kZXg6IHN5cy9hcm0vYXJtL3RyYXAtdjYuYwo9PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBzeXMvYXJtL2FybS90 cmFwLXY2LmMJKHJldmlzaW9uIDI4NzM5NCkKKysrIHN5cy9hcm0vYXJtL3RyYXAtdjYuYwkod29y a2luZyBjb3B5KQpAQCAtMTY3LDcgKzE2NywyNyBAQAogCXthYm9ydF9mYXRhbCwJIlVuZGVmaW5l ZCBDb2RlICgweDQwRikifQogfTsKIAorc3RhdGljIHZvaWQKK2NwdV90cmFjZXNpZ2V4aXQoc3Ry dWN0IHRocmVhZCAqdGQpCit7CisJc3RydWN0IHRyYXBmcmFtZSAqdGY7CiAKKwl0ZiA9IHRkLT50 ZF9mcmFtZTsKKwlpZiAodGYgPT0gTlVMTCkKKwkJcmV0dXJuOworCisJQ1RSMyhLVFJfVFJBUCwg InBjIDB4JTA4eCB1c3JfbHIgMHglMDh4IHVzcl9zcCAweCUwOHgiLAorCSAgICB0Zi0+dGZfcGMs IHRmLT50Zl91c3JfbHIsIHRmLT50Zl91c3Jfc3ApOworCUNUUjMoS1RSX1RSQVAsICJzcHNyIDB4 JTA4eCBzdmNfbHIgMHglMDh4IHN2Y19zcCAweCUwOHgiLAorCSAgICB0Zi0+dGZfc3BzciwgdGYt PnRmX3N2Y19sciwgdGYtPnRmX3N2Y19zcCk7CisJQ1RSNShLVFJfVFJBUCwgInIwIDB4JTA4eCBy MSAweCUwOHggcjIgMHglMDh4IHIzIDB4JTA4eCByNCAweCUwOHgiLAorCSAgICB0Zi0+dGZfcjAs IHRmLT50Zl9yMSwgdGYtPnRmX3IyLCB0Zi0+dGZfcjMsIHRmLT50Zl9yNCk7CisJQ1RSNShLVFJf VFJBUCwgInI1IDB4JTA4eCByNiAweCUwOHggcjcgMHglMDh4IHI4IDB4JTA4eCByOSAweCUwOHgi LAorCSAgICB0Zi0+dGZfcjUsIHRmLT50Zl9yNiwgdGYtPnRmX3I3LCB0Zi0+dGZfcjgsIHRmLT50 Zl9yOSk7CisJQ1RSMyhLVFJfVFJBUCwgInIxMCAweCUwOHggcjExIDB4JTA4eCByMTIgMHglMDh4 IiwKKwkgICAgdGYtPnRmX3IxMCwgdGYtPnRmX3IxMSwgdGYtPnRmX3IxMik7Cit9CisKIHN0YXRp YyBfX2lubGluZSB2b2lkCiBjYWxsX3RyYXBzaWduYWwoc3RydWN0IHRocmVhZCAqdGQsIGludCBz aWcsIGludCBjb2RlLCB2bV9vZmZzZXRfdCBhZGRyKQogewpAQCAtMTc2LDYgKzE5Niw5IEBACiAJ Q1RSNChLVFJfVFJBUCwgIiVzOiBhZGRyOiAlI3gsIHNpZzogJWQsIGNvZGU6ICVkIiwKIAkgICBf X2Z1bmNfXywgYWRkciwgc2lnLCBjb2RlKTsKIAorCWNwdV90cmFjZXNpZ2V4aXQodGQpOworCWJy ZWFrcG9pbnQoKTsKKwogCS8qCiAJICogVE9ETzogc29tZSBpbmZvIHdvdWxkIGJlIG5pY2UgdG8g a25vdwogCSAqIGlmIHdlIGFyZSBzZXJ2aW5nIGRhdGEgb3IgcHJlZmV0Y2ggYWJvcnQuCg== --047d7bd75bb27c36d0051ec4bf6f--