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
> > > >
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=56
On Fri, Jun 04, 2010 at 12:44:55PM +0200, Thibaut VARENE wrote:
> On Fri, Jun 4, 2010 at 7:21 AM, dann frazier 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
> g
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.
> >
> >
On Fri, Jun 4, 2010 at 7:21 AM, dann frazier 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!
>>>
>>
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 b
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: http://bugs.debian.
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 do
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 ava
# 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
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
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 sa
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.
https:/
> 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
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.
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
> > t
On Tue, 2010-04-06 at 08:37 -0500, James Bottomley wrote:
> > (5) Child process B is waken up and sees old value at in
> ,
> > through different cache line. B sleeps.
>
> This isn't possible. at this point, A and B have the same virtual
> address and mapping for this means they are the sam
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 testi
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
> > > 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.
> 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:
21 matches
Mail list logo
