* Re: [gentoo-user] framebuffer hangs in 2.6.26
2008-10-08 22:21 [gentoo-user] framebuffer hangs in 2.6.26 Andrey Vul
@ 2008-11-04 14:11 ` Jorge Peixoto de Morais Neto
0 siblings, 0 replies; 2+ messages in thread
From: Jorge Peixoto de Morais Neto @ 2008-11-04 14:11 UTC (permalink / raw
To: gentoo-user
> The current kernel that I am running is 2.6.26.5-rt9-gentoo2.
> Sporadically this freezes, usually happening during the end of
> emerging an ebuild or when stopping gpm. Usually, the fb only freezes
> for a few seconds, but sometimes I have to <Alt><SysRq>O the machine
> (it's unresponsive to <Alt><SysRq>{R,S,E,I,K,U}).
> I have the feeling that this is a regression because the framebuffer
> never froze on 2.6.25.4-rt5-gentoo nor on the kernel on the 2008.0
> install/minimal CD.
>
> Any suggestions?
>
> Note: I emailed about this on lkml, yet got no replies.
>
I think something similar happened to me; I am using vanilla-sources.
As for version, see
$ uname -a
Linux jorge 2.6.26.6 #1 Fri Oct 10 00:52:35 BRT 2008 i686 AMD
Athlon(tm) XP 2600
+ AuthenticAMD GNU/Linux
(although, at the time of the problem, it might have been 2.6.26.5)
The computer froze during an emerge of multiple ebuilds (I couldn't
know if the emerge had finished or not, but I intensely hope it had -
I hate system inconsistencies and filesystem corruptions).
The system were completely unresponsive to <ctrl><alt>fn and the magic
sysrq keys, except <Alt><SysRq>o. In fact, even the keyboard leds were
unresponsive AFAIR (as far as I recall).
Note: Despite the system *seeming* unresponsive to the other
<alt><sysrq> keys, *maybe* they were indeed effective, and I did the
whole "<Alt><SysRq>r, <Alt><SysRq>e, wait 5 seconds, <Alt><SysRq>i,
<Alt><SysRq>s, wait 5 seconds, <Alt><SysRq>u, wait 5 seconds,
<Alt><SysRq>o" hoping that this would cleanly shutdown my computer.
AFAIR, the next boot did indicate that the filesystem had been cleanly
umounted)
On 2008-10-18 it happened again. Using vanilla sources 2.6.26.6. Again, it was
after an emerge (but it wasn't immediately after, it was some minutes
later). For the record, I am using a tmpfs on PORTAGE_TMPDIR (and it
is 1536 MB, far more than enough for emerging the programs I was
emerging - gimp-help, yasm, libpcre, subversion, giflib - and I have 1
GB RAM and 972 MB of swap - and I was not running any memory-intensive
apps (just enlightenment, gkrellm, pidgin, and firefox viewing a
single page on Ubuntu wiki) The emerge went fine with absolutely no
errors. Some minutes later, when I was preparing to shutdown the
system, the system became unresponsive just after I tried to close
pidgin.
It seems that the system becomes completely unresponsive to keyboard
(except the magic sysrq keys); <ctrl><alt>fn , <ctrl><alt>backspace ,
<ctrl><alt><del>, nothing responds. The screen is completely frozen
(so I don't know if the computer responds to the mouse). The system
itself isn't frozen though - I have cron jobs that beep every 15
minutes (to keep me informed of the time), and I heard the expected
beep when the time reached 7:00 (I woke up early, at 5:45). I then
performed <alt><sysrq>r, but the system seemed still unresponsive to
keyboard. I left the system idle for more than 30 minutes, to see if
it would recover. It didn't.
I then rebooted with the EISUB sysrq keys combination. The system
indeed responded to theses keys - it rebooted and, on the next boot,
the filesystem was reportedly clean.
I was using e17. Since i changed to Xfce, I haven't had this problem.
It is very possible, though, that this was just a coincidence, and the
bug is not e17's fault
--
Software is like sex: it is better when it is free - Linus Torvalds
^ permalink raw reply [flat|nested] 2+ messages in thread