Created attachment 87611 [details] modprobe drm debug=6; modprobe i915 -> HANG In console/text mode (runlevel 3) the command modprobe i915 hangs the system: 1. screen goes blank 2. keyboard and mouse are no longer recognized (active) Note: the system remains active "behind the scenes": "magic-sysrq" works remoting from another host (ssh/scp) works (thus the attached dmesg log)
Are you sure about keyboard and mouse since there's nothing in the logs indicating a real hang? You /should/ be able to still long in (albeit blindly). Also the dmesg is cut off at the top, so: What's your kernel version? And is this a regression? Also, please test the latest drm-intel-next-queued git branch from http://cgit.freedesktop.org/~danvet/drm-intel
(In reply to comment #1) > Are you sure about keyboard and mouse since there's nothing in the logs > indicating a real hang? You /should/ be able to still long in (albeit > blindly). Like I said, the keyboard and mouse become dead. There no point to [log] in because the hang happens, like I said, after I do 'modprobe i915' as obviously, logged in. > Also the dmesg is cut off at the top, so: What's your kernel version? Like I said at the beginning of this document, 3.6.8 > And is this a regression? Not really. It is a new machine. On the old machine (_identical_ system) this does NOT happen (at all). Old machine: "ASUS P5E-VM HDMI" with intel G35/ICH9R. intel E8400 New (hang) machine: "ASUS P8H77-I" with (not surprisingly, intel H77) and intel i7-3770 (Ivy Bridge) > Also, please test the latest drm-intel-next-queued git branch from > http://cgit.freedesktop.org/~danvet/drm-intel In the meantime, while I test this branch, please try to get a handle on what's going on and to fix the problem. -- Alex
Any update Alex? This will be tough to debug unless we can get more information. One way we debug hangs or graphics corruption is by using netconsole to direct kernel messages at another machine. https://wiki.ubuntu.com/Kernel/Netconsole has some info on that. If you can modprobe i915 after setting drm.debug=0xf and capture the output from netconsole, we might be able to figure out where it hangs and what's causing it.
(In reply to comment #3) > Any update Alex? Hi Jesse, Same situation on 3.6.9 (no, I haven't looked at 3.6.10. And I will look at 3.6.11 as well, as soon as it comes out). I don't expect (good) surprizes because Murphy's law is as 100% valid and powerful now as when it was first stated: "Left by themselves, things go from bad to worse." And this bug has surely been left by itself. > This will be tough to debug unless we can get more information > information. One way we debug hangs or graphics corruption is by using > netconsole to direct kernel messages at another machine. > https://wiki.ubuntu.com/Kernel/Netconsole has some info on that. > > If you can modprobe i915 after setting drm.debug=0xf and capture the output > from netconsole, we might be able to figure out where it hangs and what's > causing it. I'm presenting here a summary from the original Bug submission: << In console/text mode (runlevel 3) [at] the command modprobe i915 ... the keyboard and mouse become dead. Note: the system remains active "behind the scenes": "magic-sysrq" works [and] remoting from another host (ssh/scp) works (thus the attached dmesg log) Created an attachment [with the dmesg] for modprobe drm debug=6; modprobe i915 >> QUESTIONS for you: 1.1. Wasn't my dmesg attachment an example of the use of how "to direct kernel messages at another machine"? 1.2. Like I said, "remoting from another host (ssh/scp) works", so why do I have to read instructions from a distribution I don't use (nor do I intend to). For the record, I've always used "BLFS" (Beyond Linux From Scratch). 2. From your review of the "kernel messages" in my attachment, what was missing so you haven't been able to proceed with the analysis, debug and fix? 3. Was my 'drm debug=6' not informative enough, so that you want now drm debug=0xf (or 15, as they say)? 4. What was it on 'drm debug=6' that was missing (in plain English so I can get an idea)? Thanks, -- Alex
On Thu, 13 Dec 2012 16:15:29 +0000 (UTC) bugzilla-daemon@bugzilla.kernel.org wrote: > 1.1. > Wasn't my dmesg attachment an example of the use of how "to direct kernel > messages at another machine"? > > 1.2. Like I said, "remoting from another host (ssh/scp) works", so > why do I have to read instructions from a distribution I don't use (nor do I > intend to). > For the record, I've always used "BLFS" (Beyond Linux From Scratch). 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. > 2. From your review of the "kernel messages" in my attachment, what was > missing so you haven't been able to proceed with the analysis, debug and fix? If you leave out the "video=" parameter from your boot line, do things behave any differently? > 3. Was my 'drm debug=6' not informative enough, so that you want now > drm debug=0xf (or 15, as they say)? > > 4. What was it on 'drm debug=6' that was missing (in plain English so I > can get an idea)? 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...
(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@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
Two things: - What happens when you boot with video=640x480? - Does this 640x400 mode correctly when you select it in X with e.g. xrandr?
Created attachment 89151 [details] Test results as requested, then some.
Hi Daniel, Hope I got your instructions correctly. Thanks, -- Alex
Ok, so stuff seems to work as expected, safe that your monitor just doesn't like that 680x400 resolution you want. But since you force it, kernel complies and you get a black screen. Fyi you can also force modes with xrandr by adding new ones with xrandr --addmode. With the right mode bad wraparound (which I still think is simply a bug in fbconsole) is also gone. So I'll close this as not a bug, it looks like what you've originally wanted to it simply something you're hw doesn't like too much. If you _really_ want to get that 640x400 mode going I guess you need to change the timings (with xrandr --addmode) until you have something that works on your hw, and then use that on the cmdline.
(In reply to comment #10) > Ok, so stuff seems to work as expected, safe that your monitor just doesn't > like that 680x400 resolution you want. Work as expected by whom, and WHY? OK? I've been using the _same_ monitor since day one. It's a standard, solid, Samsung 2494. I now switch it between the two machines, the "old" and the "new" since I started working on the new one. > But since you force it, kernel complies and you get a black screen. 1. Why not on the "old" one? Same kernel. Same basic hardware and HUI. 2. Where have you heard about this strange (to put it delicately) "rule"? (about when the kernel "complies" with an [unpleasant] "force" you get a blank screen (and a dead keyboard and mouse too, I might add)). If this so obvious and expected about kernel behavior (that only you know about, BTW) then it should apply in all similar situations. > Fyi you can also force modes with xrandr by adding > new ones with xrandr --addmode. With the right mode bad wraparound (which I > still think is simply a bug in fbconsole) is also gone. If that were so, why is the original "wraparound" Bug 43167 --> 43239 still buried deep (for more than a year) and UNRESOLVED. Not even a half-hearted proposal for a successful workaround offered. As everybody who's paid any attention to this original Bug handling, everything stems from a bad kernel change I _proved_ and documented (at great effort and against all odds) with a kernel bisection and all. To this day kernel 3.0.20 (the last one standing) still works without all these complications explained away by you (which BTW, do nothing other than manage to insult a reader's intelligence.) > So I'll close this as not a bug, it looks like what you've originally wanted > to it simply something you're hw doesn't like too much. My comments above demonstrate with facts, not invented "thoughts" for the occasion by people who don't even bother to (or can) read a simple sentence carefully, why this submission has to be reopened. > If you _really_ want to get that 640x400 mode going I guess you need to > change the timings (with xrandr --addmode) until you have something that > works on your hw, and then use that on the cmdline. No, I DO NOT "_really_ want to get that 640x400 mode". NO NO NO. I couldn't _really_ care less about what has to be on the command line. ALL I ALWAYS WANTED has been SIMPLY, when I exit the graphics mode to 1. get the 80x25 (back) 2. with CORRECT, as expected, wraparound !! 80x25, BTW, has been and will be the universal standard for text mode. Proof of it, even now, on boot, the kernel starts the machine in 80x25 resolution. It's amazing that this has to even come up as debatable. And YES YES YES. The current "nouveau" software (tested with an NVidia board on the same hw) meets all these BASIC "requirements" in stride: 80x25 and correct wraparound.
The dmesg lists the modes the display supports, and the mode specified in the video= kernel parameter is not one of them. Please use a mode that *is* supported by your display. Even if the mode unsupported by your display works by coincidence on your old machine, there is no reason it should work on your new machine. For example, there may be subtle differences in the clocks and timings generated by two different generations of hardware. I am closing this bug again. If you're experiencing problems related to the topic of the bug with supported modes, please reopen.
(In reply to comment #12) > The dmesg lists the modes the display supports, and the mode specified in the > video= kernel parameter is not one of them. Please use a mode that *is* > supported by your display. > > Even if the mode unsupported by your display works by coincidence on your old > machine, there is no reason it should work on your new machine. For example, > there may be subtle differences in the clocks and timings generated by two > different generations of hardware. Hi Jani, Thank you for your comments. For some reason, people got hung up on that "video=" parameter. In my narrative below, I'll stay within the modes supported (per xrandr) so we can eliminate an unnecessary side show. >> LEGEND hangs = input (keyboard & mouse) unresponsive; screen blanks out >> REFERENCE (for completeness) Monitor: Samsung 2494 (same one as in Bug 43167 (freedektop) and 43239 (kernel.org)) []% xrandr Screen 0: minimum 320 x 200, current 1366 x 768, maximum 8192 x 8192 VGA1 disconnected (normal left inverted right x axis y axis) HDMI1 disconnected (normal left inverted right x axis y axis) HDMI2 connected 1366x768+0+0 (normal left inverted right x axis y axis) 531mm x 298mm 1366x768 60.0*+ 1920x1080 60.0 + 50.0 1600x1200 60.0 1680x1050 59.9 1680x945 60.0 1400x1050 59.9 1600x900 60.0 1280x1024 60.0 1440x900 59.9 1280x960 60.0 1360x768 60.0 1280x800 59.9 1280x768 60.0 1280x720 50.0 60.0 1024x768 60.0 1024x576 60.0 800x600 60.3 56.2 720x576 50.0 848x480 60.0 720x480 59.9 640x480 60.0 DP1 disconnected (normal left inverted right x axis y axis) DP2 disconnected (normal left inverted right x axis y axis) At submission (Nov 28, 2012) kernel-3.6.6 glibc-2.15 libXrandr-1.4.0 xf86-video-modesetting-0.5.0 xorg-server-1.13.0 xf86-input-evdev-2.7.3 xf86-video-intel-2.20.13 fluxbox-1.3.2 (can also be KDE-3.5.10/Konsole for the purposes of this submission) Changes (Installations) made since submission: kernel-3.7.1 Installation ("the sanitize") of Linux API Headers glibc-2.16.0 xorg-server-1.13.1 xf86-video-intel-2.20.17 >> CURRENT Situation 1. kernel /boot/LFSkernel root=/dev/sda3 # NO "video=" parameter Boot up to runlevel 3 (25x80 console text). I'll then go to Xorg. On exiting Xorg (runlevel 5): Computer HANGS with Magic-SysRq and remote access working 2. kernel /boot/LFSkernel root=/dev/sda3 video=HDMI-A-2:640x480 Same situation as 1. above ! 3. kernel /boot/LFSkernel root=/dev/sda3 video=HDMI-A-2:800x600 Same situation as 1. above ! >> COMMENTS KEYED TO THE ABOVE "CURRENT Situation" TESTS 1. modprobe i915 (before going to Xorg-runlevel 5) []$ stty -a speed 38400 baud; rows 67; columns 240; line = 0; ... 2. modprobe i915 (before going to Xorg-runlevel 5) []$ stty -a speed 38400 baud; rows 30; columns 80; line = 0; ... 3. modprobe i915 (before going to Xorg-runlevel 5) []$ stty -a speed 38400 baud; rows 37; columns 100; line = 0; ... >> OVERALL COMMENT _All_ I want from Santa is: On exit from runlevel 5 to runlevel 3 ... 1. No hang 2. Regain my 25x80 text screen with 3. Correct (= normal) wraparound > I am closing this bug again. If you're experiencing problems related to the > topic of the bug with supported modes, please reopen. Based on "CURRENT Situation" above, I'm reopening the submission. Thank you, -- Alex PS I'm working feverishly to respond to your comment/question on Bugs 43167 and 43239 (which in my uneducated guess are related to this one)
(In reply to comment #13) > For some reason, people got hung up on that "video=" parameter. That is because the dmesg you attached has the parameter. > hangs = input (keyboard & mouse) unresponsive; screen blanks out If the screen goes black, how do you expect keyboard and mouse to respond exactly? Would it be accurate if I restated your problem as "the screen goes black on returning to runlevel 3"? > >> CURRENT Situation > 1. kernel /boot/LFSkernel root=/dev/sda3 # NO "video=" parameter > > Boot up to runlevel 3 (25x80 console text). I'll then go to Xorg. > On exiting Xorg (runlevel 5): > Computer HANGS with Magic-SysRq and remote access working IOW, the screen of your computer goes black. Please do the above, with drm.debug=0xe module parameter, and provide the output of dmesg, all the way from boot to the end, including the timestamps. When your screen is black, what happens if you go back to runlevel 5? > _All_ I want from Santa is: > On exit from runlevel 5 to runlevel 3 ... > 1. No hang > 2. Regain my 25x80 text screen with > 3. Correct (= normal) wraparound ... > PS I'm working feverishly to respond to your comment/question on Bugs 43167 > and 43239 (which in my uneducated guess are related to this one) Let's focus on the screen going black part on this bug.
(In reply to comment #14) > (In reply to comment #13) > > For some reason, people got hung up on that "video=" parameter. > > That is because the dmesg you attached has the parameter. True, but as I made a point in my Comment #13, the problem happens even without this parameter. I also showed that it happens even if you stay within what xrandr sees as "acceptable" resolutions. I fully agree with you (in retrospect) that on the old machine a "non-standard" video=resolution that appears to work (somehow) has been just a lucky guess. > > hangs = input (keyboard & mouse) unresponsive; screen blanks out > > If the screen goes black, how do you expect keyboard and mouse to respond > exactly? Would it be accurate if I restated your problem as "the screen goes > black on returning to runlevel 3"? Here I just would like to (informally) add to this description (your restatement) that the monitor has two "buttons" one can play with in this context: An "auto sync" and The on/off Neither takes the monitor from this ~black (~unresponsive) state. Somebody here even suggested I use the keyboard/mouse blindly and see what happens. Maybe with skill and care I can avoid the dreaded SysRq but SysRq is way faster and more reliable. So this is why I cannot say with full confidence that the keyboard and mouse do not respond. Actually a quick analysis points to at least some reponsiveness as long as the three-key SysRq salute works. > > >> CURRENT Situation > > 1. kernel /boot/LFSkernel root=/dev/sda3 # NO "video=" parameter > > > > Boot up to runlevel 3 (25x80 console text). I'll then go to Xorg. > > On exiting Xorg (runlevel 5): > > Computer HANGS with Magic-SysRq and remote access working > > IOW, the screen of your computer goes black. Here, again for completeness (and maybe a clue to specialists), the screen actually goes to a very dark gray (close to black to the untrained eye) suggesting some scanning still going on. Only at the point where SysRq does its magic the screen goes pitch dark (thus announcing the impending reboot sequence). > Please do the above, with drm.debug=0xe module parameter, and provide the > output of dmesg, all the way from boot to the end, including the timestamps. I'll do that, no problem (this is just a quick reply to prove I'm still alive what with the Holidays and all). For the timestamps I'll have to recompile the kernel. Questions: As I described in Comment #13, the original modprobe drm debug=6; modprobe i915 sequence no longer appears to lead directly to the hang state. (at least 'modprobe i915' alone doesn't hang; I haven't tried it with the preceding 'modprobe drm' lately) The hang, as I said, always happens after I exit the graphics state (runlevel 5) under any circumstance, video= or not. Do you want a "no video=" dmesg or with "video=" and which resolution do you prefer in this case? Thanks, -- Alex
Alex, in light of [1], is this still an issue? [1] https://bugs.freedesktop.org/show_bug.cgi?id=43167#c43
(In reply to comment #16) > Alex, in light of [1], is this still an issue? > > [1] https://bugs.freedesktop.org/show_bug.cgi?id=43167#c43 This remains vary much a serious issue: the computer consistently hangs (or as you'd put it, goes to a "black screen") each and every time it comes from runlevel 5 to 3, under any circumstance, whether - No "video=" or - "video=any of the monitor "approved" xrandr resolution or and any other resolution I can think of". It you are still interested and would like to help, please read 1. My comment #13 and 2. My "Questions" in my Comment #15 carefully. To summarize the situations of Bug 43167/43239 vs. 51081: Only THREE things in common: 1. The same good, solid, tried and true monitor (Samsung 2494) 2. Same-level Linux software 3. Myself (as owner and bug submitter) OTOH, many different things, most notably, DIFFERENT (physical) computers P5E-VM HDMI board with intel E8400 processor and intel G35 Express chipset, 4G (43167/43239) vs P8H77-I board with i7-3770 processor and intel H77 chipset, 16G (51081)
Created attachment 90061 [details] xorg.conf
Created attachment 90071 [details] Xorg.0.log
Created attachment 90081 [details] Xorg.0.log
Since the "hang" happens on exit from Xorg (runlevel 5) consistently, I provided some material which might address some potential questions: For reference: []$ xrandr Screen 0: minimum 320 x 200, current 1360 x 768, maximum 8192 x 8192 VGA1 disconnected (normal left inverted right x axis y axis) HDMI1 disconnected (normal left inverted right x axis y axis) HDMI2 connected 1360x768+0+0 (normal left inverted right x axis y axis) 531mm x 298mm 1360x768 60.0*+ 1920x1080 60.0 + 50.0 1600x1200 60.0 1680x1050 59.9 1680x945 60.0 1400x1050 59.9 1600x900 60.0 1280x1024 60.0 1440x900 59.9 1280x960 60.0 1366x768 60.0 1280x800 59.9 1280x768 60.0 1280x720 50.0 60.0 1024x768 60.0 1024x576 60.0 800x600 60.3 56.2 720x576 50.0 848x480 60.0 720x480 59.9 640x480 60.0 DP1 disconnected (normal left inverted right x axis y axis) DP2 disconnected (normal left inverted right x axis y axis) Please note that in both instances covered, No "video=" and video=800x600 the two remote (ssh) tests, 1. 25x80 is perfect: []$ stty -a | grep speed speed 38400 baud; rows 25; columns 80; line = 0; 2. The wrap-around is perfect. A Happy New Year, -- Alex
1) Please reproduce the screen going black on return to runlevel 3, with drm.debug=0xe module parameter, and provide the output of dmesg (that is the kernel console log), all the way from boot to the end, including the timestamps. Do not use a video= kernel parameter. 2) With the screen black, what happens if you go back to runlevel 5?
(In reply to comment #22) > 2) With the screen black, what happens if you go back to runlevel 5? I'll answer your second question first so you'll have something to work on (hopefully) in the interim. For the first I'll have to recompile the kernel to provide time stamps, so it may take a while for me to "recover" there. ANSWER Consistently (reproducible), each time I remotely direct the problem computer to go from the new level 3 ("black") to level 5 again: It goes back to the 1360x768 Xorg screen and looks/acts normal (as if nothing ever happened). ------ For the record: on the remote (controlling) monitor: ... Failed to read: session.screen0.tooltipDelay Setting default value Failed to read: session.screen0.clientMenu.usePixmap Setting default value Failed to read: session.screen0.slit.acceptKdeDockapps Setting default value xinit: connection to X server lost waiting for X server to shut down X: dispatch.c:3944: DetachOutputGPU: Assertion `slave->isGPU' failed. ----------------------------------------------------- NOTES: FWIW, the remote (controlling) console never loses the connection to the subject computer. I'm reiterating, the "black" (hung) screen is not black black; it is _almost_ black, suggesting (to my untrained eye) some scanning still going on. It becomes really black (i.e., like when the the monitor is turned off) only when the computer starts rebooting (locally at magic-SysRq, remotely after typing 'reboot').
Created attachment 90151 [details] time-stamped dmesg The dmesg as requested by Jani in Comment #22: 1) Please reproduce the screen going black on return to run level 3, with drm.debug=0xe module parameter, and provide the output of dmesg (that is the kernel console log), all the way from boot to the end, including the timestamps. Do not use a video= kernel parameter.
We never found the root cause here, and also failed to report that we were unable to solve the bug. And we've neglected the bug since. Apologies. I'm afraid we still don't have a clue, but trying a recent kernel might be worth it. We do fix plenty of bugs all the time - it just might be we've fixed the issue behind this one without connecting the dots to this bug. Please try a recent kernel, thanks.
(In reply to Jani Nikula from comment #25) > We never found the root cause here, and also failed to report that we were > unable to solve the bug. And we've neglected the bug since. Apologies. I'm > afraid we still don't have a clue, but trying a recent kernel might be worth > it. We do fix plenty of bugs all the time - it just might be we've fixed the > issue behind this one without connecting the dots to this bug. Please try a > recent kernel, thanks. Hi Jani, Long time no see. My, how time flies! HARDWARE reminder Motherboard: "ASUS P8H77-I" (with intel H77) and intel i7-3770, 16 GB. Monitor: ASUS VE258Q, connected via HDMI to motherboard. SOFTWARE reminder 32-bit, i686 GNU/Linux. BLFS <www.linuxfromscratch.org> UPDATE Kernel: 3.16.3 (latest as of this writing, Sep. 27, 2014 11:30 EST). There is NO longer hang-up ("black screen") on 'modprobe i915' BUT (see TEST RESULTS below). TEST METHODOLOGY 1. Reboot machine _directly_ to Level 3 ("console/text mode"). Note: NEVER go to Level 5 (Xorg 7.7) during the procedure below. Just stay on the original Level 3. 2. Based on a trick devised sometime ago while grappling with a similar(?) problem of changed-screen-resolution (from default 25 rows to 30) on returning from Level 5 (graphics mode) to Level 3. The trick: change to an appropriate font type (lat4a-19) to restore the 25 rows on a _full_ screen. The resulting text is not as sharp as the original kernel console type but hey, let's not be too demanding, we're still only 2014! 3. Legend for the following (hopefully) self-explanatory console text, "$" = console root prompt. TEST RESULTS After reboot: $ $ stty -a | grep speed speed 38400 baud; rows 25; columns 80; ... $ lsmod | grep 915 $ modprobe i915 # No black screen but see next 'stty' results $ lsmod | grep 915 i915 553907 1 cfbfillrect 2426 1 i915 cfbimgblt 1687 1 i915 i2c_algo_bit 3687 1 i915 cfbcopyarea 2318 1 i915 drm_kms_helper 24092 1 i915 drm 161309 3 i915,drm_kms_helper i2c_core 13418 4 drm,i915,drm_kms_helper,i2c_algo_bit intel_gtt 8490 1 i915 video 10362 1 i915 backlight 3705 2 i915,video button 3206 1 i915 $ stty -a | grep speed speed 38400 baud; rows 30; columns 80; line = 0; $ INITTY=/dev/tty[1-6] ; \ for TTY in $INITTY ; do setfont lat4a-19 -C $TTY ; done $ stty -a | grep speed speed 38400 baud; rows 25; columns 80; line = 0; CONCLUSION The situation is much better but still not what I expect: There should be no change to screen resolution on loading i915. Thanks, -- Alex
In anticipation of possible questions regarding the purpose of the "video=HDMI-A-2:640x480M" parameter I use in in the grub 'menu.lst' kernel line (kernel ... video=HDMI-A-2:640x480M): TESTS without "video=HDMI-A-2:640x480M" 1. Reboot, login (as root) $ $ stty -a | grep speed speed 38400 baud; rows 25; columns 80; ... Start X (Level 5) Exit X (return to Level 3 $ stty -a | grep speed speed 38400 baud; rows 56; columns 240; ... ------------------------------------------------- 2. Reboot, login (as root) $ $ stty -a | grep speed speed 38400 baud; rows 25; columns 80; ... $ modprobe i915 $ stty -a | grep speed speed 38400 baud; rows 67; columns 240; ... ------------------------------------------------- ANSWER With the parameter "video=HDMI-A-2:640x480M" in, I can at least "recover" my 80x25 console by using the trick detailed in Comment #26.2 above. -- Alex
I think it's fair to say we are not working on this. Sorry. Please file any new bug reports at the freedesktop.org bugzilla [1]. Thank you. [1] https://bugs.freedesktop.org/enter_bug.cgi?product=DRI&component=DRM/Intel