* 2.6.15-$SHA1: VT <-> X sometimes odd @ 2006-01-10 16:23 Alexey Dobriyan 2006-01-11 11:50 ` Antonino A. Daplas 0 siblings, 1 reply; 9+ messages in thread From: Alexey Dobriyan @ 2006-01-10 16:23 UTC (permalink / raw) To: linux-kernel 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. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: 2.6.15-$SHA1: VT <-> X sometimes odd 2006-01-10 16:23 2.6.15-$SHA1: VT <-> X sometimes odd Alexey Dobriyan @ 2006-01-11 11:50 ` Antonino A. Daplas 2006-01-11 15:38 ` Alexey Dobriyan 0 siblings, 1 reply; 9+ messages in thread From: Antonino A. Daplas @ 2006-01-11 11:50 UTC (permalink / raw) To: Alexey Dobriyan; +Cc: linux-kernel 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: 2.6.15-$SHA1: VT <-> X sometimes odd 2006-01-11 11:50 ` Antonino A. Daplas @ 2006-01-11 15:38 ` Alexey Dobriyan 2006-01-12 19:28 ` Alexey Dobriyan 0 siblings, 1 reply; 9+ messages in thread From: Alexey Dobriyan @ 2006-01-11 15:38 UTC (permalink / raw) To: Antonino A. Daplas; +Cc: linux-kernel 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. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: 2.6.15-$SHA1: VT <-> X sometimes odd 2006-01-11 15:38 ` Alexey Dobriyan @ 2006-01-12 19:28 ` Alexey Dobriyan 2006-01-12 19:23 ` Linus Torvalds 0 siblings, 1 reply; 9+ messages in thread From: Alexey Dobriyan @ 2006-01-12 19:28 UTC (permalink / raw) To: Antonino A. Daplas; +Cc: linux-kernel, Andrew Morton, Linus Torvalds 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. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: 2.6.15-$SHA1: VT <-> X sometimes odd 2006-01-12 19:28 ` Alexey Dobriyan @ 2006-01-12 19:23 ` Linus Torvalds 2006-01-12 20:04 ` Linus Torvalds 2006-01-12 20:23 ` Lockups while unpacking huge tarballs (was Re: 2.6.15-$SHA1: VT <-> X sometimes odd) Alexey Dobriyan 0 siblings, 2 replies; 9+ messages in thread From: Linus Torvalds @ 2006-01-12 19:23 UTC (permalink / raw) To: Alexey Dobriyan Cc: Antonino A. Daplas, Linux Kernel Mailing List, Andrew Morton, Jens Axboe 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; ^ permalink raw reply related [flat|nested] 9+ messages in thread
* Re: 2.6.15-$SHA1: VT <-> X sometimes odd 2006-01-12 19:23 ` Linus Torvalds @ 2006-01-12 20:04 ` Linus Torvalds 2006-01-12 20:08 ` Jens Axboe 2006-01-12 20:23 ` Lockups while unpacking huge tarballs (was Re: 2.6.15-$SHA1: VT <-> X sometimes odd) Alexey Dobriyan 1 sibling, 1 reply; 9+ messages in thread From: Linus Torvalds @ 2006-01-12 20:04 UTC (permalink / raw) To: Alexey Dobriyan Cc: Antonino A. Daplas, Linux Kernel Mailing List, Andrew Morton, Jens Axboe 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: 2.6.15-$SHA1: VT <-> X sometimes odd 2006-01-12 20:04 ` Linus Torvalds @ 2006-01-12 20:08 ` Jens Axboe 0 siblings, 0 replies; 9+ messages in thread From: Jens Axboe @ 2006-01-12 20:08 UTC (permalink / raw) To: Linus Torvalds Cc: Alexey Dobriyan, Antonino A. Daplas, Linux Kernel Mailing List, Andrew Morton 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Lockups while unpacking huge tarballs (was Re: 2.6.15-$SHA1: VT <-> X sometimes odd) 2006-01-12 19:23 ` Linus Torvalds 2006-01-12 20:04 ` Linus Torvalds @ 2006-01-12 20:23 ` Alexey Dobriyan 2006-01-12 20:14 ` Jens Axboe 1 sibling, 1 reply; 9+ messages in thread From: Alexey Dobriyan @ 2006-01-12 20:23 UTC (permalink / raw) To: Linus Torvalds Cc: Antonino A. Daplas, Linux Kernel Mailing List, Andrew Morton, 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 <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. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Lockups while unpacking huge tarballs (was Re: 2.6.15-$SHA1: VT <-> X sometimes odd) 2006-01-12 20:23 ` Lockups while unpacking huge tarballs (was Re: 2.6.15-$SHA1: VT <-> X sometimes odd) Alexey Dobriyan @ 2006-01-12 20:14 ` Jens Axboe 0 siblings, 0 replies; 9+ messages in thread From: Jens Axboe @ 2006-01-12 20:14 UTC (permalink / raw) To: Alexey Dobriyan Cc: Linus Torvalds, Antonino A. Daplas, Linux Kernel Mailing List, Andrew Morton 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2006-01-12 20:12 UTC | newest] Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2006-01-10 16:23 2.6.15-$SHA1: VT <-> X sometimes odd Alexey Dobriyan 2006-01-11 11:50 ` Antonino A. Daplas 2006-01-11 15:38 ` Alexey Dobriyan 2006-01-12 19:28 ` Alexey Dobriyan 2006-01-12 19:23 ` Linus Torvalds 2006-01-12 20:04 ` Linus Torvalds 2006-01-12 20:08 ` Jens Axboe 2006-01-12 20:23 ` Lockups while unpacking huge tarballs (was Re: 2.6.15-$SHA1: VT <-> X sometimes odd) Alexey Dobriyan 2006-01-12 20:14 ` Jens Axboe
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).