All of lore.kernel.org
 help / color / mirror / Atom feed
From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: John David Anglin <dave@hiauly1.hia.nrc.ca>
Cc: Kyle McMartin <kyle@mcmartin.ca>,
	carlos@systemhalted.org, randolph@tausq.org, deller@gmx.de,
	kurt@roeckx.be, pkern@debian.org, debian-hppa@lists.debian.org,
	linux-parisc@vger.kernel.org, debian-release@lists.debian.org
Subject: Re: HPPA and Squeeze
Date: Tue, 07 Jul 2009 09:11:17 -0500	[thread overview]
Message-ID: <1246975877.4522.9.camel@mulgrave.site> (raw)
In-Reply-To: <20090707014710.EF3975022@hiauly1.hia.nrc.ca>

On Mon, 2009-07-06 at 21:47 -0400, John David Anglin wrote:
> > If I remember correctly, there's still some issues with the L2 cache on
> > pa8800 that we haven't quite bothered to work out yet, since it's "good
> > enough" for now. James probably knows more. It would be interesting to
> > see if you could reproduce it with a UP 64-bit kernel on your C3750 to
> > discount the L2 problems.
> 
> Googling, I see Grant had trouble with RCU_TORTURE_TEST=y.  Probably,
> I should test current kernel to see if the problem is still present.
> 
> I guess you are referring to this change:
> http://fossplanet.com/linux.debian.devel.kernel.cvs/thread-4378354-r7141-patches/
> 
> I'm thinking we must be missing a flush...  Maybe in clear_user_page
> as for copy_user_page?

Clear user page is very clever and doesn't need a flush.  What it does
is clear the page through the users cache rather than the kernel's ...
what it actually does is place zeros in the cache above the physical
page, so the user can only access the zeros ... they eventually get
cleaned back to the page as the cache empties.

> Do the problematic debian buildd machines have pa8800/pa8900 processors?

No boxes outside of the cupertino test ring and a few giveaways (you,
kyle and t-bone, I think) have pa88/8900 cpus.

> My sense is that some change (probably to the core memory management
> code) made the coherence issue worse post 2.6.22.x.

So if I characterise the problem you think you're seeing: on mmap of a
file at a memory location to be determined by the kernel, a sequential
set of reads of the mapped location eventually turns up a zero where
there should be data?  Yes, it does sound like a caching issue.

James



  parent reply	other threads:[~2009-07-07 14:11 UTC|newest]

Thread overview: 87+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-06-19  6:05 HPPA and Squeeze Luk Claes
2009-06-19 15:15 ` Kurt Roeckx
2009-06-19 15:43   ` Philipp Kern
2009-06-20 22:44     ` John David Anglin
2009-07-03 18:57     ` Kurt Roeckx
2009-07-03 19:28       ` Philipp Kern
2009-07-03 22:15         ` Kurt Roeckx
2009-07-04 23:34           ` John David Anglin
2009-07-05  9:06             ` Helge Deller
2009-07-05 13:44               ` Jurij Smakov
2009-07-05 14:01                 ` Philipp Kern
2009-07-05 17:19               ` John David Anglin
2009-07-05 18:01                 ` John David Anglin
2009-07-05 23:07                 ` John David Anglin
2009-07-06  0:03                   ` Carlos O'Donell
2009-07-06  0:17                     ` John David Anglin
2009-07-06  1:06                       ` James Bottomley
2009-07-06  1:43                         ` John David Anglin
2009-07-06  5:38                           ` Randolph Chung
2009-07-06 13:28                             ` John David Anglin
2009-07-06 16:36                               ` Carlos O'Donell
2009-07-06 18:45                                 ` John David Anglin
2009-07-06 21:43                                   ` Kyle McMartin
2009-07-07  1:47                                     ` John David Anglin
2009-07-07  2:43                                       ` dann frazier
2009-07-07 13:57                                         ` Carlos O'Donell
2009-07-07 14:11                                       ` James Bottomley [this message]
2009-07-07 16:21                                         ` John David Anglin
2009-07-07 20:42                                           ` Carlos O'Donell
2009-07-07 22:07                                             ` John David Anglin
2009-07-07 22:17                                               ` Carlos O'Donell
2009-07-07 22:39                                                 ` John David Anglin
2009-07-07 14:22                                     ` James Bottomley
2009-07-05 23:59                 ` Carlos O'Donell
2009-07-06  2:25                   ` John David Anglin
2009-07-04 19:52       ` John David Anglin
2009-07-04 21:03         ` Kurt Roeckx
2009-07-04 23:30           ` Kurt Roeckx
2009-06-20 14:33   ` Kurt Roeckx
2009-06-20 16:02     ` John David Anglin
2009-06-20 17:48       ` Kurt Roeckx
2009-06-20 21:57         ` Grant Grundler
2009-06-20 22:25           ` John David Anglin
2009-06-20 23:07             ` Grant Grundler
2009-06-20 23:25               ` John David Anglin
2009-06-20 14:39   ` Kurt Roeckx
2009-06-20 14:51     ` Thibaut VARENE
     [not found] <20090602140734.GC26721@mx0.halon.org.uk>
2009-06-06 18:36 ` Grant Grundler
2009-06-08 21:26   ` Neil McGovern
2009-06-08 23:44     ` Thibaut VARENE
2009-06-09  9:29       ` Neil McGovern
2009-06-09 10:38         ` Thomas Bogendoerfer
2009-06-09 16:47         ` Aioanei Rares
2009-06-09 17:06           ` John David Anglin
     [not found]       ` <slrnh2scj5.720.nospam@sshway.ssh.pusling.com>
2009-06-09 19:11         ` Helge Deller
2009-06-17  2:37           ` John David Anglin
2009-06-15 16:26     ` Grant Grundler
2009-06-15 17:32       ` Helge Deller
2009-06-12  6:49   ` Luk Claes
2009-06-12  7:53     ` Bart Schelstraete
2009-06-12  7:55       ` Bart Schelstraete
2009-06-12 14:16         ` James Bottomley
2009-06-12 15:35           ` dann frazier
2009-06-13 12:19             ` Brian Szymanski
2009-06-14 18:29             ` Thibaut VARENE
2009-06-14 18:39               ` dann frazier
2009-06-15 17:31     ` Grant Grundler
2009-06-16  6:25       ` Lucas Nussbaum
2009-06-16 19:08         ` Helge Deller
2009-06-16 19:13           ` Aurelien Jarno
2009-06-17 11:14             ` Carlos O'Donell
2009-06-21 22:55             ` Carlos O'Donell
2009-07-12 12:30               ` Aurelien Jarno
2009-07-12 14:52                 ` Carlos O'Donell
2009-07-13 13:30                   ` Carlos O'Donell
2009-06-16 20:50         ` Grant Grundler
2009-06-16 21:35           ` dann frazier
2009-06-17 23:54       ` Matthias Klose
2009-06-18  1:35         ` John David Anglin
2009-06-18  6:33           ` Luk Claes
2009-06-18  9:40             ` Randolph Chung
2009-06-18 18:19               ` Luk Claes
2009-06-18 10:16             ` Thibaut VARENE
2009-06-18 18:16               ` Luk Claes
2009-06-18 15:03             ` John David Anglin
2009-06-18  6:29         ` Luk Claes
2009-06-24 23:32           ` Matthias Klose

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=1246975877.4522.9.camel@mulgrave.site \
    --to=james.bottomley@hansenpartnership.com \
    --cc=carlos@systemhalted.org \
    --cc=dave@hiauly1.hia.nrc.ca \
    --cc=debian-hppa@lists.debian.org \
    --cc=debian-release@lists.debian.org \
    --cc=deller@gmx.de \
    --cc=kurt@roeckx.be \
    --cc=kyle@mcmartin.ca \
    --cc=linux-parisc@vger.kernel.org \
    --cc=pkern@debian.org \
    --cc=randolph@tausq.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.