On Wed, Jul 20, 2016 at 2:57 PM, H.J. Lu <hjl.to...@gmail.com> wrote: > On Wed, Jul 20, 2016 at 2:20 PM, Jeff Law <l...@redhat.com> wrote: >> On 07/20/2016 03:09 PM, Andrew Pinski wrote: >>> >>> On Wed, Jul 20, 2016 at 2:02 PM, Andrew Pinski <pins...@gmail.com> wrote: >>>> >>>> On Wed, Jul 20, 2016 at 1:32 PM, Jeff Law <l...@redhat.com> wrote: >>>>> >>>>> On 07/20/2016 02:21 PM, Segher Boessenkool wrote: >>>>>> >>>>>> >>>>>> On Wed, Jul 20, 2016 at 12:48:09PM +0530, Senthil Kumar Selvaraj wrote: >>>>>>>> >>>>>>>> >>>>>>>> I see this for some of the larger C frontend tests with lots of >>>>>>>> expected >>>>>>>> errors/warnings as well. >>>>>> >>>>>> >>>>>> >>>>>> I also see this for tests with small output, but it happens more >>>>>> often for tests with big output. >>>>>> >>>>>>> Are you guys getting this everytime or is it sporadic? >>>>>> >>>>>> >>>>>> >>>>>> Not always, but usually. It seems related to how busy the system is, >>>>>> but that could be my imagination. >>>>>> >>>>>> It usually happens for a bunch of tests at the same time. >>>>>> >>>>>> Not always is the output just cut short: some random characters >>>>>> are inserted sometimes (in the individual log files, the consolidated >>>>>> log file does not have those; it looks like pointers). >>>>> >>>>> >>>>> Hmm, there was a kernel bug a while back which had similar behavior. >>>>> What >>>>> kernel version are you running? >>>> >>>> >>>> I am running with 4.2. Let me find the old email and see I should >>>> include it in our tree (I thought we did). >>> >>> >>> Found it. It looks like it was not put in yet: >>> https://bugzilla.kernel.org/show_bug.cgi?id=96311 >>> >>> I know Jakub asked about a year ago saying it was not 4.1-rc1 yet. >>> Can someone look to see if it even made it into newer kernels? >> >> I know "a" fix is in modern Fedora kernels and I thought it came from >> upstream. >> >> Jeff >> > > commit 1a48632ffed61352a7810ce089dc5a8bcd505a60 > Author: Peter Hurley <pe...@hurleysoftware.com> > Date: Mon Apr 13 13:24:34 2015 -0400 > > pty: Fix input race when closing > > A read() from a pty master may mistakenly indicate EOF (errno == -EIO) > after the pty slave has closed, even though input data remains to be read. > For example, >
I definitely have this patch in my kernel which I am using and still seeing failures. I wonder if the memory barriers are still wrong. Since I see this on aarch64 where the memory ordering is weak with respect to stores. Thanks, Andrew > > -- > H.J.
