[Bug 51081] [ivb] i915 insertion hangs machine

[bugzilla-daemon at bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=51081





--- Comment #6 from alupu at verizon.net  2012-12-14 00:02:08 ---
(In reply to comment #5)
> Sorry I read too fast and didn't see that you can ssh in.  Sounds like
> the system doesn't hang at all then, just your console goes away.

Hi Jesse,

I'm repeating the section from my little OP:
"Note:  the system remains _active_ "behind the scenes":
"magic-sysrq" works, remoting from another host (ssh/scp) works"

99% of the users experiencing this, let's call it "phenomenon" for the time
being, will yell "the dam' thing got hung again" (and they will either hit the
big red button or throw the friggin' thing outa window.)

But let's not allow this become a bone of contention.  You're right that the
system is not technically hung, as I worded it, so I offer apologies for the
word "hangs" in the title;  I propose a replacement instead, "makes the system
unresponsive".  If you come up with a better term or phrase, that's fine with
me.
BTW, as an aside, I didn't know that the screen, keyboard and mouse were called
"console" in Linux kernel parlance.
So from now on I can call the "phenomenon" simply "the console goes dead" :)
The bottom line is that we're actually talking the same language now
(the only positive so far).

> If you leave out the "video=" parameter from your boot line, do things
> behave any differently?
> ...
> [The logs actually don't indicate any serious failures.  The framebuffer
> size doesn't quite match your requested mode however (656x414 vs
> 640x400) which is why I'm curious what happens if you don't specify the
> video= line...]

Yes.  The screen/video goes from 80x25 to something like 240x67 (i.e., barely
visible characters).
However, it does remain "responsive" (after a fashion).

------

Please don't read the following four paragraphs too fast this time :).

This is the reason I've used "video=640x400M at 70m".  On the "old" machine
this works fine, on return from X.org graphics mode (level 5) to level 3
(console mode) where I do most of my work, the resolution returns to a
semblance of 80x25. (this is acceptable by Linux philosophy, I suppose.
[see, if you can stomach, Bug 43167 <bugs.freedesktop.org> --> Bug 43239] )

On the "new" machine, the modprobe (insert) of i915, without the "video"
kernel line, the "console" no longer becomes unresponsive.  As I said above,
I'd have to put up with a terrifyingly small screen, which forces me to reboot,
which is more or less the same thing, in the final analysis
(you'd probably call this "no serious failures";  I'm still alive :).

The "old" machine is built on the "old", perfectly standard intel architecture,
"G35 Express" chipset.
The "new" one is built on the "new", perfectly standard intel architecture,
"H77 Express" chipset.
Evidently, the kernel (and its modules) are not (yet?) up to handling the
latest technology developments.

As a note, this situation completely invalidates, in a legal sense (in addition
to the technical), the "mode specifiers" as documented in
linux-3.6.9/Documentation/fb/modedb.txt

Thanks,
-- Alex

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.