Hello,
On sekmadienis 06 Birželis 2010 04:01:23 Modestas Vainius wrote:
On penktadienis 04 Birželis 2010 08:21:06 dann frazier wrote:
My case and my analysis talked about UP kernel, and John David Anglin
made a patch:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=561203#144
On Fri, Jun 04, 2010 at 12:44:55PM +0200, Thibaut VARENE wrote:
On Fri, Jun 4, 2010 at 7:21 AM, dann frazier da...@debian.org wrote:
On Fri, Jun 04, 2010 at 10:03:07AM +0900, NIIBE Yutaka wrote:
Modestas Vainius wrote:
Note that Debian's buildds run a UP kernel, so as soon as those fixes
Hello,
On penktadienis 04 Birželis 2010 08:21:06 dann frazier wrote:
My case and my analysis talked about UP kernel, and John David Anglin
made a patch:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=561203#144
After that, the discussion went to SMP cases.
It would be
Processing commands for cont...@bugs.debian.org:
severity 561203 serious
Bug #561203 [linux-2.6] threads and fork on machine with VIPT-WB cache
Severity set to 'serious' from 'critical'
thanks
Stopping processing here.
Please contact me if you need assistance.
--
561203:
severity 561203 serious
thanks
On Thu, Jun 03, 2010 at 11:50:05AM +0300, Modestas Vainius wrote:
# Breaks unrelated applications
Sorry, no. Almost all applications are related to the kernel.
Well, as long as this is unfixed or at least common, I don't see how hppa
can be considered to be a
On Fri, Jun 4, 2010 at 7:21 AM, dann frazier da...@debian.org wrote:
On Fri, Jun 04, 2010 at 10:03:07AM +0900, NIIBE Yutaka wrote:
Modestas Vainius wrote:
Note that Debian's buildds run a UP kernel, so as soon as those fixes
go upstream we can pull them in. Thanks for all your work here!
# Breaks unrelated applications
tags 561203 critical
thanks
Hello,
On trečiadienis 02 Birželis 2010 20:56:17 dann frazier wrote:
On Wed, Jun 02, 2010 at 01:16:01PM -0400, John David Anglin wrote:
On Wed, 02 Jun 2010, Modestas Vainius wrote:
Hello,
this bug [1] is back to the very
Modestas Vainius wrote:
Note that Debian's buildds run a UP kernel, so as soon as those fixes
go upstream we can pull them in. Thanks for all your work here!
Well, as long as this is unfixed or at least common, I don't see how hppa
can be considered to be a release arch. Is that UP patch
On Fri, Jun 04, 2010 at 10:03:07AM +0900, NIIBE Yutaka wrote:
Modestas Vainius wrote:
Note that Debian's buildds run a UP kernel, so as soon as those fixes
go upstream we can pull them in. Thanks for all your work here!
Well, as long as this is unfixed or at least common, I don't see how
Hello,
this bug [1] is back to the very common department with eglibc 2.11 (libc6-
dev_2.11.1-1) builds. Majority of KDE applications are failing to build on
hppa again. Is there really nothing what could be done to fix it?
1. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=561203
2.
On Wed, 02 Jun 2010, Modestas Vainius wrote:
Hello,
this bug [1] is back to the very common department with eglibc 2.11 (libc6-
dev_2.11.1-1) builds. Majority of KDE applications are failing to build on
hppa again. Is there really nothing what could be done to fix it?
I will just say it
On Wed, Jun 02, 2010 at 01:16:01PM -0400, John David Anglin wrote:
On Wed, 02 Jun 2010, Modestas Vainius wrote:
Hello,
this bug [1] is back to the very common department with eglibc 2.11
(libc6-
dev_2.11.1-1) builds. Majority of KDE applications are failing to build on
hppa
On 04/02/2010 09:35 PM, John David Anglin wrote:
On Fri, 02 Apr 2010, NIIBE Yutaka wrote:
NIIBE Yutaka wrote:
To have same semantics as other archs, I think that VIPT-WB cache
machine should have cache flush at ptep_set_wrprotect, so that memory
of the page has up-to-date data. Yes, it
On Thu, 08 Apr 2010, Helge Deller wrote:
I tested your patch today on one of my machines with plain kernel 2.6.33
(32bit, SMP, B2000 I think).
Sadly I still did see the minifail bug.
Are you sure, that the patch fixed this bug for you?
Seemed to, but I have a bunch of other
On Tue, 2010-04-06 at 08:37 -0500, James Bottomley wrote:
(5) Child process B is waken up and sees old value at x in
oldpage,
through different cache line. B sleeps.
This isn't possible. at this point, A and B have the same virtual
address and mapping for oldpage this means they are
On Tue, 2010-04-06 at 13:57 +0900, NIIBE Yutaka wrote:
John David Anglin wrote:
It is interesting that in the case of the Debian bug that
a thread of the parent process causes the COW break and thereby corrupts
its own memory. As far as I can tell, the fork'd child never writes
to the
On Sun, 2010-04-04 at 22:51 -0400, John David Anglin wrote:
Thanks a lot for the discussion.
James Bottomley wrote:
So your theory is that the data the kernel sees doing the page copy can
be stale because of dirty cache lines in userspace (which is certainly
possible in the
John David Anglin wrote:
It is interesting that in the case of the Debian bug that
a thread of the parent process causes the COW break and thereby corrupts
its own memory. As far as I can tell, the fork'd child never writes
to the memory that causes the fault.
Thanks for writing and testing
Thanks a lot for the discussion.
James Bottomley wrote:
So your theory is that the data the kernel sees doing the page copy can
be stale because of dirty cache lines in userspace (which is certainly
possible in the ordinary way)?
Yes.
By design that shouldn't happen: the idea
By design that shouldn't happen: the idea behind COW breaking is
that before it breaks, the page is read only ... this means that
processes can have clean cache copies of it, but never dirty cache
copies (because writes are forbidden).
That must be design, I agree.
To keep
20 matches
Mail list logo