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 Thu, Jun 10, 2010 at 07:30:45PM +0300, Modestas Vainius wrote:
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
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:
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
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 behind COW
retitle 561203 threads and fork on machine with VIPT-WB cache
reassign 561203 linux-2.6
thanks
As I am sure that this bug lives in kernel, I do reassign and retitle.
--
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact
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
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 will be huge performance
impact for fork. But I don't find any good solution other than this
yet.
On Fri, 2010-04-02 at 12:48 +0900, NIIBE Yutaka wrote:
Thanks for your quick reply.
James Bottomley wrote:
In COW breaking, the page table entry is copied, so A and B no longer
have page table entries at the same physical location. If the COW is
intact, A and B have the same physical
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 will be huge performance
impact for fork. But I
Hi there,
I think that I am catching a bug for threads and fork. I found it
when debugging FTBFS of Gauche, a Scheme interpreter. As I think that
the Debian bug #561203 has same cause, I am CC:-ing to the BTS too.
Please send Cc: to me, I am not on linux-parisc list.
Here, I am talking
On Fri, 2010-04-02 at 11:41 +0900, NIIBE Yutaka wrote:
(9) Process B does read-access on memory, which gets *NEW* data in
cache (if process space identifier color is same).
Process B does write-access on memory which causes memory fault,
as it's COW memory.
Note: Process B
Thanks for your quick reply.
James Bottomley wrote:
In COW breaking, the page table entry is copied, so A and B no longer
have page table entries at the same physical location. If the COW is
intact, A and B have the same physical page, but it's also accessed by
the same virtual address,
30 matches
Mail list logo
