Mikael Pettersson | 1 Sep 03:34 2009
Picon
Picon

Re: [Bug #14015] pty regressed again, breaking expect and gcc's testsuite

Mikael Pettersson writes:
 > Rafael J. Wysocki writes:
 >  > On Saturday 29 August 2009, Mikael Pettersson wrote:
 >  > > Mikael Pettersson writes:
 >  > >  > Rafael J. Wysocki writes:
 >  > >  >  > On Thursday 27 August 2009, Mikael Pettersson wrote:
 >  > >  >  > > On Tue, 25 Aug 2009 22:34:53 +0200 (CEST), Rafael J. Wysocki wrote:
 >  > >  >  > > > The following bug entry is on the current list of known regressions
 >  > >  >  > > > from 2.6.30.  Please verify if it still should be listed and let me know
 >  > >  >  > > > (either way).
 >  > >  >  > > > 
 >  > >  >  > > > 
 >  > >  >  > > > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=3D14015
 >  > >  >  > > > Subject		: pty regressed again, breaking expect and gcc's testsuite
 >  > >  >  > > > Submitter	: Mikael Pettersson <mikpe@...>
 >  > >  >  > > > Date		: 2009-08-14 23:41 (12 days old)
 >  > >  >  > > > References	: http://marc.info/?l=3Dlinux-kernel&m=3D125029329805643&w=3D4
 >  > >  >  > > 
 >  > >  >  > > Not fixed. With 2.6.31-rc7 I'm still seeing repeatable testsuite
 >  > >  >  > > failures on powerpc64. Reverting to 2.6.30 makes the failures go away.
 >  > >  >  > 
 >  > >  >  > Thanks for the update.
 >  > >  >  > 
 >  > >  >  > I guess 2.6.31-rc8 doesn't make any difference, does it?
 >  > >  > 
 >  > >  > I've scheduled a number of gcc bootstraps and testsuite runs
 >  > >  > with -rc8 on x86, powerpc64, and arm. I'll post an update in
 >  > >  > a day or so.
 >  > > 
 >  > > 2.6.31-rc8 results in bogus testsuite failures on all three platforms.
(Continue reading)

Rafael J. Wysocki | 1 Sep 20:42 2009
Picon

Re: [Bug #14015] pty regressed again, breaking expect and gcc's testsuite

On Tuesday 01 September 2009, Mikael Pettersson wrote:
> Mikael Pettersson writes:
>  > Rafael J. Wysocki writes:
>  >  > On Saturday 29 August 2009, Mikael Pettersson wrote:
>  >  > > Mikael Pettersson writes:
>  >  > >  > Rafael J. Wysocki writes:
>  >  > >  >  > On Thursday 27 August 2009, Mikael Pettersson wrote:
>  >  > >  >  > > On Tue, 25 Aug 2009 22:34:53 +0200 (CEST), Rafael J. Wysocki wrote:
>  >  > >  >  > > > The following bug entry is on the current list of known regressions
>  >  > >  >  > > > from 2.6.30.  Please verify if it still should be listed and let me know
>  >  > >  >  > > > (either way).
>  >  > >  >  > > > 
>  >  > >  >  > > > 
>  >  > >  >  > > > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=3D14015
>  >  > >  >  > > > Subject		: pty regressed again, breaking expect and gcc's testsuite
>  >  > >  >  > > > Submitter	: Mikael Pettersson <mikpe@...>
>  >  > >  >  > > > Date		: 2009-08-14 23:41 (12 days old)
>  >  > >  >  > > > References	: http://marc.info/?l=3Dlinux-kernel&m=3D125029329805643&w=3D4
>  >  > >  >  > > 
>  >  > >  >  > > Not fixed. With 2.6.31-rc7 I'm still seeing repeatable testsuite
>  >  > >  >  > > failures on powerpc64. Reverting to 2.6.30 makes the failures go away.
>  >  > >  >  > 
>  >  > >  >  > Thanks for the update.
>  >  > >  >  > 
>  >  > >  >  > I guess 2.6.31-rc8 doesn't make any difference, does it?
>  >  > >  > 
>  >  > >  > I've scheduled a number of gcc bootstraps and testsuite runs
>  >  > >  > with -rc8 on x86, powerpc64, and arm. I'll post an update in
>  >  > >  > a day or so.
>  >  > > 
(Continue reading)

Jeremy Fitzhardinge | 1 Sep 21:47 2009

Re: [Bug #14062] Failure to boot as xen guest

On 08/25/09 13:34, Rafael J. Wysocki wrote:
> This message has been generated automatically as a part of a report
> of recent regressions.
>
> The following bug entry is on the current list of known regressions
> from 2.6.30.  Please verify if it still should be listed and let me know
> (either way).
>   

I think this is fixed by d560bc61.

    J

>
> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=14062
> Subject		: Failure to boot as xen guest
> Submitter	: Arnd Hannemann <hannemann@...>
> Date		: 2009-08-25 15:48 (1 days old)
> First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=83b519e8b9572c319c8e0c615ee5dd7272856090
> References	: http://marc.info/?l=linux-kernel&m=125121534229538&w=4
> Handled-By	: Jeremy Fitzhardinge <jeremy@...>
> Patch		: http://patchwork.kernel.org/patch/43799/
>
>
>   

Bartlomiej Zolnierkiewicz | 2 Sep 19:48 2009
Picon

Re: ipw2200: firmware DMA loading rework

On Sunday 30 August 2009 14:37:42 Bartlomiej Zolnierkiewicz wrote:
> On Friday 28 August 2009 05:42:31 Zhu Yi wrote:
> > Bartlomiej Zolnierkiewicz reported an atomic order-6 allocation failure
> > for ipw2200 firmware loading in kernel 2.6.30. High order allocation is
> 
> s/2.6.30/2.6.31-rc6/
> 
> The issue has always been there but it was some recent change that
> explicitly triggered the allocation failures (after 2.6.31-rc1).

ipw2200 fix works fine but yesterday I got the following error while mounting
ext4 filesystem (mb_history is optional so the mount succeeded):

EXT4-fs (dm-2): barriers enabled
kjournald2 starting: pid 3137, dev dm-2:8, commit interval 5 seconds
EXT4-fs (dm-2): internal journal on dm-2:8
EXT4-fs (dm-2): delayed allocation enabled
EXT4-fs: file extents enabled
mount: page allocation failure. order:5, mode:0xc0d0
Pid: 3136, comm: mount Not tainted 2.6.31-rc8-00015-gadda766-dirty #78
Call Trace:
 [<c0394de3>] ? printk+0xf/0x14
 [<c016a693>] __alloc_pages_nodemask+0x400/0x442
 [<c016a71b>] __get_free_pages+0xf/0x32
 [<c01865cf>] __kmalloc+0x28/0xfa
 [<c023d96f>] ? __spin_lock_init+0x28/0x4d
 [<c01f529d>] ext4_mb_init+0x392/0x460
 [<c01e99d2>] ext4_fill_super+0x1b96/0x2012
 [<c0239bc8>] ? snprintf+0x15/0x17
 [<c01c0b26>] ? disk_name+0x24/0x69
(Continue reading)

Luis R. Rodriguez | 2 Sep 20:02 2009
Picon

Re: ipw2200: firmware DMA loading rework

On Wed, Sep 2, 2009 at 10:48 AM, Bartlomiej
Zolnierkiewicz<bzolnier <at> gmail.com> wrote:
> On Sunday 30 August 2009 14:37:42 Bartlomiej Zolnierkiewicz wrote:
>> On Friday 28 August 2009 05:42:31 Zhu Yi wrote:
>> > Bartlomiej Zolnierkiewicz reported an atomic order-6 allocation failure
>> > for ipw2200 firmware loading in kernel 2.6.30. High order allocation is
>>
>> s/2.6.30/2.6.31-rc6/
>>
>> The issue has always been there but it was some recent change that
>> explicitly triggered the allocation failures (after 2.6.31-rc1).
>
> ipw2200 fix works fine but yesterday I got the following error while mounting
> ext4 filesystem (mb_history is optional so the mount succeeded):

OK so the mount succeeded.

> EXT4-fs (dm-2): barriers enabled
> kjournald2 starting: pid 3137, dev dm-2:8, commit interval 5 seconds
> EXT4-fs (dm-2): internal journal on dm-2:8
> EXT4-fs (dm-2): delayed allocation enabled
> EXT4-fs: file extents enabled
> mount: page allocation failure. order:5, mode:0xc0d0
> Pid: 3136, comm: mount Not tainted 2.6.31-rc8-00015-gadda766-dirty #78
> Call Trace:
>  [<c0394de3>] ? printk+0xf/0x14
>  [<c016a693>] __alloc_pages_nodemask+0x400/0x442
>  [<c016a71b>] __get_free_pages+0xf/0x32
>  [<c01865cf>] __kmalloc+0x28/0xfa
>  [<c023d96f>] ? __spin_lock_init+0x28/0x4d
(Continue reading)

Bartlomiej Zolnierkiewicz | 2 Sep 20:26 2009
Picon

Re: ipw2200: firmware DMA loading rework

On Wednesday 02 September 2009 20:02:14 Luis R. Rodriguez wrote:
> On Wed, Sep 2, 2009 at 10:48 AM, Bartlomiej
> Zolnierkiewicz<bzolnier@...> wrote:
> > On Sunday 30 August 2009 14:37:42 Bartlomiej Zolnierkiewicz wrote:
> >> On Friday 28 August 2009 05:42:31 Zhu Yi wrote:
> >> > Bartlomiej Zolnierkiewicz reported an atomic order-6 allocation failure
> >> > for ipw2200 firmware loading in kernel 2.6.30. High order allocation is
> >>
> >> s/2.6.30/2.6.31-rc6/
> >>
> >> The issue has always been there but it was some recent change that
> >> explicitly triggered the allocation failures (after 2.6.31-rc1).
> >
> > ipw2200 fix works fine but yesterday I got the following error while mounting
> > ext4 filesystem (mb_history is optional so the mount succeeded):
> 
> OK so the mount succeeded.
> 
> > EXT4-fs (dm-2): barriers enabled
> > kjournald2 starting: pid 3137, dev dm-2:8, commit interval 5 seconds
> > EXT4-fs (dm-2): internal journal on dm-2:8
> > EXT4-fs (dm-2): delayed allocation enabled
> > EXT4-fs: file extents enabled
> > mount: page allocation failure. order:5, mode:0xc0d0
> > Pid: 3136, comm: mount Not tainted 2.6.31-rc8-00015-gadda766-dirty #78
> > Call Trace:
> >  [<c0394de3>] ? printk+0xf/0x14
> >  [<c016a693>] __alloc_pages_nodemask+0x400/0x442
> >  [<c016a71b>] __get_free_pages+0xf/0x32
> >  [<c01865cf>] __kmalloc+0x28/0xfa
(Continue reading)

Linus Torvalds | 3 Sep 03:23 2009

Re: [Bug #14015] pty regressed again, breaking expect and gcc's testsuite


On Tue, 1 Sep 2009, Rafael J. Wysocki wrote:
> On Tuesday 01 September 2009, Mikael Pettersson wrote:
> > 
> > Starting with 2.6.31-rc8 and reverting
> > 
> > 85dfd81dc57e8183a277ddd7a56aa65c96f3f487 pty: fix data loss when stopped (^S/^Q)
> > d945cb9cce20ac7143c2de8d88b187f62db99bdc pty: Rework the pty layer to use the normal buffering logic
> > 
> > in that order gives me a kernel that works on both x86 and powerpc64.
> > 
> > So the bug is definitely limited to the pty buffering logic change.
> 
> Thanks a lot for this information, adding somme CCs to the list.

Mikael, is there any way to get the gcc testsuite to show the "expected" 
vs "result" cases when the failures occur, so that we can see what the 
pattern is ("it drops one character every 8kB" or something like that).

However, I get the feeling that it's really the same bug that 
OGAWA-san already fixed - and that his fix just doesn't always do a 100% 
of the job. 

So what Ogawa did was to make sure that we flush any pending data whenever 
we;re checking "do we have any data left". He did that by calling out to 
tty_flush_to_ldisc(), which should flush the data through to the ldisc. 

The keyword here being "should". In flush_to_ldisc(), we have at least one 
case where we say "we'll delay it a bit more":

(Continue reading)

OGAWA Hirofumi | 3 Sep 13:29 2009
Picon

Re: [Bug #14015] pty regressed again, breaking expect and gcc's testsuite

Linus Torvalds <torvalds <at> linux-foundation.org> writes:

> On Tue, 1 Sep 2009, Rafael J. Wysocki wrote:
>> On Tuesday 01 September 2009, Mikael Pettersson wrote:
>> > 
>> > Starting with 2.6.31-rc8 and reverting
>> > 
>> > 85dfd81dc57e8183a277ddd7a56aa65c96f3f487 pty: fix data loss when stopped (^S/^Q)
>> > d945cb9cce20ac7143c2de8d88b187f62db99bdc pty: Rework the pty layer to use the normal buffering logic
>> > 
>> > in that order gives me a kernel that works on both x86 and powerpc64.
>> > 
>> > So the bug is definitely limited to the pty buffering logic change.
>> 
>> Thanks a lot for this information, adding somme CCs to the list.
>
> Mikael, is there any way to get the gcc testsuite to show the "expected" 
> vs "result" cases when the failures occur, so that we can see what the 
> pattern is ("it drops one character every 8kB" or something like that).
>
> However, I get the feeling that it's really the same bug that 
> OGAWA-san already fixed - and that his fix just doesn't always do a 100% 
> of the job. 
>
> So what Ogawa did was to make sure that we flush any pending data whenever 
> we;re checking "do we have any data left". He did that by calling out to 
> tty_flush_to_ldisc(), which should flush the data through to the ldisc. 
>
> The keyword here being "should". In flush_to_ldisc(), we have at least one 
> case where we say "we'll delay it a bit more":
(Continue reading)

Mel Gorman | 3 Sep 14:49 2009
Picon

Re: ipw2200: firmware DMA loading rework

On Wed, Sep 02, 2009 at 11:02:14AM -0700, Luis R. Rodriguez wrote:
> On Wed, Sep 2, 2009 at 10:48 AM, Bartlomiej
> Zolnierkiewicz<bzolnier <at> gmail.com> wrote:
> > On Sunday 30 August 2009 14:37:42 Bartlomiej Zolnierkiewicz wrote:
> >> On Friday 28 August 2009 05:42:31 Zhu Yi wrote:
> >> > Bartlomiej Zolnierkiewicz reported an atomic order-6 allocation failure
> >> > for ipw2200 firmware loading in kernel 2.6.30. High order allocation is
> >>
> >> s/2.6.30/2.6.31-rc6/
> >>
> >> The issue has always been there but it was some recent change that
> >> explicitly triggered the allocation failures (after 2.6.31-rc1).
> >
> > ipw2200 fix works fine but yesterday I got the following error while mounting
> > ext4 filesystem (mb_history is optional so the mount succeeded):
> 
> OK so the mount succeeded.
> 
> > EXT4-fs (dm-2): barriers enabled
> > kjournald2 starting: pid 3137, dev dm-2:8, commit interval 5 seconds
> > EXT4-fs (dm-2): internal journal on dm-2:8
> > EXT4-fs (dm-2): delayed allocation enabled
> > EXT4-fs: file extents enabled
> > mount: page allocation failure. order:5, mode:0xc0d0
> > Pid: 3136, comm: mount Not tainted 2.6.31-rc8-00015-gadda766-dirty #78
> > Call Trace:
> >  [<c0394de3>] ? printk+0xf/0x14
> >  [<c016a693>] __alloc_pages_nodemask+0x400/0x442
> >  [<c016a71b>] __get_free_pages+0xf/0x32
> >  [<c01865cf>] __kmalloc+0x28/0xfa
(Continue reading)

Mikael Pettersson | 3 Sep 22:27 2009
Picon
Picon

Re: [Bug #14015] pty regressed again, breaking expect and gcc's testsuite

Linus Torvalds writes:
 > 
 > 
 > On Tue, 1 Sep 2009, Rafael J. Wysocki wrote:
 > > On Tuesday 01 September 2009, Mikael Pettersson wrote:
 > > > 
 > > > Starting with 2.6.31-rc8 and reverting
 > > > 
 > > > 85dfd81dc57e8183a277ddd7a56aa65c96f3f487 pty: fix data loss when stopped (^S/^Q)
 > > > d945cb9cce20ac7143c2de8d88b187f62db99bdc pty: Rework the pty layer to use the normal buffering logic
 > > > 
 > > > in that order gives me a kernel that works on both x86 and powerpc64.
 > > > 
 > > > So the bug is definitely limited to the pty buffering logic change.
 > > 
 > > Thanks a lot for this information, adding somme CCs to the list.
 > 
 > Mikael, is there any way to get the gcc testsuite to show the "expected" 
 > vs "result" cases when the failures occur, so that we can see what the 
 > pattern is ("it drops one character every 8kB" or something like that).

I don't know. It dumps a summary on stdout and saves logs in various
subdirs. Those logs do show the gcc commands executed and the output
from those commands, but they don't show why some test is considered
failed, or the exact boundaries of each fragment of text returned by
read(2) [which I guess may be significant].

What I can say for certain is that the test cases I've seen fail most
frequently deliberately generate lots of diagnostic output from the
compiler, like 100s or 1000s of lines of warning/error messages.
(Continue reading)


Gmane