2.6.15-$SHA1: VT <-> X sometimes odd

2.6.15-$SHA1: VT <-> X sometimes odd

[Alexey Dobriyan]

Approximate sequence of event:

1. script which builds allmodconfig on 11 targets is left on otherwise
   idle machine. Logged in on VT1. Logged of X.
2. After 5 hours I return, ensure script behaves OK, switch to X and see
   black screen.
3. Now, trying to switch between VTs and X gives nothing but black
   screen.
4. Alt+SysRq+K. After several seconds black screen switches to black
   screen with text cursor in the upper-left corner.
5. Futher attempts to switch and SysRq+Ki'ing gave nothing.
6. In a minute or so X login prompt reappeared. Mouse os OK. Keyboard is
   not. In particular, typing username doesn't work.
7. By some miracle, typing became OK (probably after I hit Ctrl, not
   sure). I login to X successfully and fire up mutt to mail bugreport.
8. Devil turned me to switch to VT again...
9. goto #5.
10. Cold reboot.

The overall feeling is that X left without human interaction starts to
reacts slooowly (probably after blanking kicks in?).

This is semi-reproducable, as in, I can't reproduce it at will but the
very same thing occured yesterday.

Now version numbers. All the above happened with
2.6.15-977127174a7dff52d17faeeb4c4949a54221881f

Yesterday it was 2.6.15-5367f2d67c7d0bf1faae90e6e7b4e2ac3c9b5e0f or
2.6.15-0aec63e67c69545ca757a73a66f5dcf05fa484bf, I don't remember. These
are just top entries in grub.conf.

Re: 2.6.15-$SHA1: VT <-> X sometimes odd

[Antonino A. Daplas]

Alexey Dobriyan wrote:
> Approximate sequence of event:
> 
> 1. script which builds allmodconfig on 11 targets is left on otherwise
>    idle machine. Logged in on VT1. Logged of X.
> 2. After 5 hours I return, ensure script behaves OK, switch to X and see
>    black screen.
> 3. Now, trying to switch between VTs and X gives nothing but black
>    screen.
> 4. Alt+SysRq+K. After several seconds black screen switches to black
>    screen with text cursor in the upper-left corner.
> 5. Futher attempts to switch and SysRq+Ki'ing gave nothing.
> 6. In a minute or so X login prompt reappeared. Mouse os OK. Keyboard is
>    not. In particular, typing username doesn't work.
> 7. By some miracle, typing became OK (probably after I hit Ctrl, not
>    sure). I login to X successfully and fire up mutt to mail bugreport.
> 8. Devil turned me to switch to VT again...
> 9. goto #5.
> 10. Cold reboot.

Can you reproduce this with another X driver, for example, vesa or
fbdev, and/or with another console driver? Maybe you can also try with
DRI enabled and disabled?
 
> 
> The overall feeling is that X left without human interaction starts to
> reacts slooowly (probably after blanking kicks in?).

That's also what I'm thinking, console blanking, X blanking, or power
management. You might want to shorten the console blanking interval with:

setterm -blank 1.

Tony

Re: 2.6.15-$SHA1: VT <-> X sometimes odd

[Alexey Dobriyan]

On Wed, Jan 11, 2006 at 07:50:44PM +0800, Antonino A. Daplas wrote:
> Alexey Dobriyan wrote:
> > Approximate sequence of event:
> >
> > 1. script which builds allmodconfig on 11 targets is left on otherwise
> >    idle machine. Logged in on VT1. Logged of X.
> > 2. After 5 hours I return, ensure script behaves OK, switch to X and see
> >    black screen.
> > 3. Now, trying to switch between VTs and X gives nothing but black
> >    screen.
> > 4. Alt+SysRq+K. After several seconds black screen switches to black
> >    screen with text cursor in the upper-left corner.
> > 5. Futher attempts to switch and SysRq+Ki'ing gave nothing.
> > 6. In a minute or so X login prompt reappeared. Mouse os OK. Keyboard is
> >    not. In particular, typing username doesn't work.
> > 7. By some miracle, typing became OK (probably after I hit Ctrl, not
> >    sure). I login to X successfully and fire up mutt to mail bugreport.
> > 8. Devil turned me to switch to VT again...
> > 9. goto #5.
> > 10. Cold reboot.
>
> Can you reproduce this with another X driver, for example, vesa or
> fbdev, and/or with another console driver? Maybe you can also try with
> DRI enabled and disabled?

OK, I'll try.

> > The overall feeling is that X left without human interaction starts to
> > reacts slooowly (probably after blanking kicks in?).
>
> That's also what I'm thinking, console blanking, X blanking, or power
> management. You might want to shorten the console blanking interval with:
>
> setterm -blank 1.

Strange freezing continues, probably blanking should be left alone:

1. while reading random patches with gitk with nothing more running. gitk
   already read all patch headers from the whole Linux git archive.

   gitk stops reacting on mouse clicks
   "Ctrl+Alt+1" (switching to virtual desktop #1 in evilwm) -- OK
   "Ctrl+Alt+2" (back) -- gitk shows its window but without actual
   content as if something can't get a timeslice for redraw.

2. Two allmodconfig builds in parallel. mutt downloading email, /me
   lazily browsing with Firefox.

Re: 2.6.15-$SHA1: VT <-> X sometimes odd

[Linus Torvalds]

On Thu, 12 Jan 2006, Alexey Dobriyan wrote:
> 
> Now it's vim saving 5k proggie while X tarball was unpacking on reiserfs.
> :wq and vim freezes. Switching to another virtual "desktops" works and
> everything in general works except vim. But switching to VT and back
> sends system to hell.

This may be fixed by the current -git tree:

	commit 1bc691d3, Tejun Heo <htejun@gmail.com>:

	[PATCH] fix queue stalling while barrier sequencing

or if that isn't it, and you have an IDE drive, can you try if the 
appended trivial patch makes a difference?

			Linus

---
diff --git a/drivers/ide/ide-io.c b/drivers/ide/ide-io.c
index bcbaeb5..d726167 100644
--- a/drivers/ide/ide-io.c
+++ b/drivers/ide/ide-io.c
@@ -101,7 +101,7 @@ int __ide_end_request(ide_drive_t *drive
 	 * for those
 	 */
 	nbytes = nr_sectors << 9;
-	if (!rq->errors && rq_all_done(rq, nbytes)) {
+	if (0 && !rq->errors && rq_all_done(rq, nbytes)) {
 		rq->data_len = nbytes;
 		blkdev_dequeue_request(rq);
 		HWGROUP(drive)->rq = NULL;

Re: 2.6.15-$SHA1: VT <-> X sometimes odd

[Alexey Dobriyan]

On Wed, Jan 11, 2006 at 06:38:22PM +0300, Alexey Dobriyan wrote:
> On Wed, Jan 11, 2006 at 07:50:44PM +0800, Antonino A. Daplas wrote:
> > Alexey Dobriyan wrote:
> > > Approximate sequence of event:
> > >
> > > 1. script which builds allmodconfig on 11 targets is left on otherwise
> > >    idle machine. Logged in on VT1. Logged of X.
> > > 2. After 5 hours I return, ensure script behaves OK, switch to X and see
> > >    black screen.
> > > 3. Now, trying to switch between VTs and X gives nothing but black
> > >    screen.
> > > 4. Alt+SysRq+K. After several seconds black screen switches to black
> > >    screen with text cursor in the upper-left corner.
> > > 5. Futher attempts to switch and SysRq+Ki'ing gave nothing.
> > > 6. In a minute or so X login prompt reappeared. Mouse os OK. Keyboard is
> > >    not. In particular, typing username doesn't work.
> > > 7. By some miracle, typing became OK (probably after I hit Ctrl, not
> > >    sure). I login to X successfully and fire up mutt to mail bugreport.
> > > 8. Devil turned me to switch to VT again...
> > > 9. goto #5.
> > > 10. Cold reboot.
> >
> > Can you reproduce this with another X driver, for example, vesa or
> > fbdev, and/or with another console driver? Maybe you can also try with
> > DRI enabled and disabled?
>
> OK, I'll try.
>
> > > The overall feeling is that X left without human interaction starts to
> > > reacts slooowly (probably after blanking kicks in?).
> >
> > That's also what I'm thinking, console blanking, X blanking, or power
> > management. You might want to shorten the console blanking interval with:
> >
> > setterm -blank 1.
>
> Strange freezing continues, probably blanking should be left alone:
>
> 1. while reading random patches with gitk with nothing more running. gitk
>    already read all patch headers from the whole Linux git archive.
>
>    gitk stops reacting on mouse clicks
>    "Ctrl+Alt+1" (switching to virtual desktop #1 in evilwm) -- OK
>    "Ctrl+Alt+2" (back) -- gitk shows its window but without actual
>    content as if something can't get a timeslice for redraw.
>
> 2. Two allmodconfig builds in parallel. mutt downloading email, /me
>    lazily browsing with Firefox.

I disabled DRI in xorg.conf but it happened again.

Now it's vim saving 5k proggie while X tarball was unpacking on reiserfs.
:wq and vim freezes. Switching to another virtual "desktops" works and
everything in general works except vim. But switching to VT and back
sends system to hell.

Re: 2.6.15-$SHA1: VT <-> X sometimes odd

[Linus Torvalds]

On Thu, 12 Jan 2006, Linus Torvalds wrote:
>
> or if that isn't it, and you have an IDE drive, can you try if the 
> appended trivial patch makes a difference?

I just pushed out a commit that reverts the IDE softirq request 
completion, so if you pull a recent enough git tree, and you see that 
revert (by Jens), the patch in the previous email won't apply, but it 
won't be needed either.

		Linus

Re: 2.6.15-$SHA1: VT <-> X sometimes odd

[Jens Axboe]

On Thu, Jan 12 2006, Linus Torvalds wrote:
> 
> 
> On Thu, 12 Jan 2006, Linus Torvalds wrote:
> >
> > or if that isn't it, and you have an IDE drive, can you try if the 
> > appended trivial patch makes a difference?
> 
> I just pushed out a commit that reverts the IDE softirq request 
> completion, so if you pull a recent enough git tree, and you see that 
> revert (by Jens), the patch in the previous email won't apply, but it 
> won't be needed either.

Yes thanks for applying it Linus, felt like the best move right now. I'd
rather work on this later and get a stabler -rc1 out the door sooner.

-- 
Jens Axboe

Re: Lockups while unpacking huge tarballs (was Re: 2.6.15-$SHA1: VT <-> X sometimes odd)

[Jens Axboe]

On Thu, Jan 12 2006, Alexey Dobriyan wrote:
> On Thu, Jan 12, 2006 at 11:23:54AM -0800, Linus Torvalds wrote:
> > On Thu, 12 Jan 2006, Alexey Dobriyan wrote:
> > > Now it's vim saving 5k proggie while X tarball was unpacking on reiserfs.
> > > :wq and vim freezes. Switching to another virtual "desktops" works and
> > > everything in general works except vim. But switching to VT and back
> > > sends system to hell.
> >
> > This may be fixed by the current -git tree:
> >
> > 	commit 1bc691d3, Tejun Heo <htejun@gmail.com>:
> >
> > 	[PATCH] fix queue stalling while barrier sequencing
> 
> It isn't. My HEAD is 9f5974c8734d83d4ab7096ed98136a82f41210d6 and I see
> this patch in git log output.
> 
> > or if that isn't it, and you have an IDE drive, can you try if the
> > appended trivial patch makes a difference?
> 
> > --- a/drivers/ide/ide-io.c
> > +++ b/drivers/ide/ide-io.c
> > @@ -101,7 +101,7 @@ int __ide_end_request(ide_drive_t *drive
> >  	 * for those
> >  	 */
> >  	nbytes = nr_sectors << 9;
> > -	if (!rq->errors && rq_all_done(rq, nbytes)) {
> > +	if (0 && !rq->errors && rq_all_done(rq, nbytes)) {
> >  		rq->data_len = nbytes;
> >  		blkdev_dequeue_request(rq);
> >  		HWGROUP(drive)->rq = NULL;
> 
> With this one-liner two X tarballs and one Firefox tarballs were
> successfully unpacked while I was hitting :w.
> 
> Without it just one X tarball doesn't pass. It's even reproducable.

Alright thanks for retesting, current git should work for you (once it
mirrors out from master).

-- 
Jens Axboe

Lockups while unpacking huge tarballs (was Re: 2.6.15-$SHA1: VT <-> X sometimes odd)

[Alexey Dobriyan]

On Thu, Jan 12, 2006 at 11:23:54AM -0800, Linus Torvalds wrote:
> On Thu, 12 Jan 2006, Alexey Dobriyan wrote:
> > Now it's vim saving 5k proggie while X tarball was unpacking on reiserfs.
> > :wq and vim freezes. Switching to another virtual "desktops" works and
> > everything in general works except vim. But switching to VT and back
> > sends system to hell.
>
> This may be fixed by the current -git tree:
>
> 	commit 1bc691d3, Tejun Heo <htejun@gmail.com>:
>
> 	[PATCH] fix queue stalling while barrier sequencing

It isn't. My HEAD is 9f5974c8734d83d4ab7096ed98136a82f41210d6 and I see
this patch in git log output.

> or if that isn't it, and you have an IDE drive, can you try if the
> appended trivial patch makes a difference?

> --- a/drivers/ide/ide-io.c
> +++ b/drivers/ide/ide-io.c
> @@ -101,7 +101,7 @@ int __ide_end_request(ide_drive_t *drive
>  	 * for those
>  	 */
>  	nbytes = nr_sectors << 9;
> -	if (!rq->errors && rq_all_done(rq, nbytes)) {
> +	if (0 && !rq->errors && rq_all_done(rq, nbytes)) {
>  		rq->data_len = nbytes;
>  		blkdev_dequeue_request(rq);
>  		HWGROUP(drive)->rq = NULL;

With this one-liner two X tarballs and one Firefox tarballs were
successfully unpacked while I was hitting :w.

Without it just one X tarball doesn't pass. It's even reproducable.