From: Lyndon Nerenberg <lyndon@orthanc.ca>
To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
Subject: [9fans] Too many checkpages() diagnostics ...
Date: Mon, 26 May 2014 16:14:36 -0700 [thread overview]
Message-ID: <05B9A9E7-83BA-4EBE-AC4F-22F414ABB5A5@orthanc.ca> (raw)
[-- Attachment #1: Type: text/plain, Size: 2673 bytes --]
For the last couple of days I have been plagued by many many diagnostics from checkpages(), in conjunction with things like:
rc: note: sys: trap: fault read addr=0x0 pc=0x000101c4
rc 50675: suicide: sys: trap: fault read addr=0x0 pc=0x000101c4
The kernel print buffer holds corresponding entries like:
coral# 10618 dns: checked 136 page table entries
dns 10618: suicide: sys: trap: fault write addr=0x0 pc=0x00015cea
26591 rfcmirror: checked 270 page table entries
37326 rc: checked 51 page table entries
47773 rc: checked 57 page table entries
47773 rc: checked 57 page table entries
47773 rc: checked 57 page table entries
47773 rc: checked 57 page table entries
47773 rc: checked 57 page table entries
47773 rc: checked 57 page table entries
47773 rc: checked 57 page table entries
47773 rc: checked 57 page table entries
47773 rc: checked 57 page table entries
47773 rc: checked 57 page table entries
47773 rc: checked 57 page table entries
50675 rc: checked 53 page table entries
coral# rm '#s/dns'
coral# ndb/dns -r
coral# 55270 rfcmirror: checked 146 page table entries
55270 rfcmirror: checked 146 page table entries
66218 rfcmirror: checked 146 page table entries
70615 rfcmirror: checked 62 page table entries
70615 rfcmirror: checked 62 page table entries
70644 tcp567: checked 39 page table entries
70644 tcp567: checked 39 page table entries
71354 rfcmirror: checked 46 page table entries
71354 rfcmirror: checked 46 page table entries
Yes, these were two different events. These just happened to be what I captured for later reference. Three events, really; the 'rc' complaints are from me running 'mk' in various source trees.
I have always seen these 'checked nnn page table entries' messages, but for the last couple of days they are everywhere. And processes are failing hand-over-fist. Forking processes in rc seems to be a sure-fire way to provoke this. I cannot get through a 'mk' of any significant piece of software, and /n/sources/contrib/lyndon/rfcmirror is very good at borking things, too.
Is anyone else seeing this? I'm running bleeding edge labs code, compiled from a pull from this afternoon. (And I have been running very up-to-date labs pulls all the way along.)
This is all running in a Parallels VM on a Mac, the same VM I have been using as a terminal for several years. What changed was switching over to a CPU kernel. The VM has 1GB of RAM now, but was quite happy running 9pcf (vs 9pccpuf now) in 256 MB, and that terminal kernel ran the same suite of commands just fine. (This is objtype=386.)
--lyndon
[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 817 bytes --]
next reply other threads:[~2014-05-26 23:14 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-26 23:14 Lyndon Nerenberg [this message]
2014-05-26 23:41 ` Steve Simon
2014-05-26 23:44 ` Lyndon Nerenberg
2014-05-26 23:47 ` Steve Simon
2014-05-27 0:27 ` Lyndon Nerenberg
2014-05-27 13:08 ` Anthony Sorace
2014-05-27 22:56 ` Lyndon Nerenberg
2014-05-27 10:43 ` Charles Forsyth
2014-05-27 6:46 ` lucio
2014-05-27 6:57 ` lucio
2014-05-27 20:52 ` Lyndon Nerenberg
2014-05-27 13:36 ` erik quanstrom
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=05B9A9E7-83BA-4EBE-AC4F-22F414ABB5A5@orthanc.ca \
--to=lyndon@orthanc.ca \
--cc=9fans@9fans.net \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).