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.
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
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.
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.
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 <[email protected]>:
[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;
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
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
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 <[email protected]>:
>
> [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.
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 <[email protected]>:
> >
> > [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