Intel Extreme driver showing blank with N10 (GMA 3150)

[6foot3]

Using a HP Mini Note 1032cl (for detailed specs see: ​http://bizsupport1.austin.hp.com/bizsupport/TechSupport/Document.jsp?objectID=c01965897&lang=en&cc=us&taskId=101&prodSeriesId=4075896&prodTypeId=321957 ) after the splash screen disappears, the screen remains blank (black). This is regression, since it used to work until quite recently. I first noticed after trying to install hrev41552 on this netbook, the previous installs being to other computers that had issues (ticket #7522 and #3/5). Reverted to hrev41539 and still had the problem. Will try an earlier build hrev41490 after I've filed this ticket.

[sotrud_nik]

This is similiar to tickets https://dev.haiku-os.org/ticket/7487 and https://dev.haiku-os.org/ticket/7441 , latter was filled by me. The only way I got it working - recompile the intel_extreme.accelerant with hardcoded pixel clock value. Yeah, that's an ugly hack. Don't know how to fix it in proper way. As you can see, trying different revisions would not help you.

[6foot3]

Tried hrev41490, hrev41207 hrev40649 before getting my screen back with hrev40033 (skipped hrev40200 and hrev40188). So much for quite recently, since 40649 was dated Feb 24 and 40033, Dec 29! Time flies when you're having fun.

[6foot3]

Just tried hrev40188 and had no issues so, that narrows it down to something that changed between Jan 10 and hrev40649 on Feb 24. If it would help, I could download a couple of the releases between hrev40188 and hrev40649 to try and narrow it down some more. Let me know since I really want to help to find this bug.

[anevilyak]

hrev40319 is a possible candidate there.

[6foot3]

Yup, that's the one. See ​http://www.freelists.org/post/haiku-commits/r40319-in-haikutrunk-headersprivategraphicsintel-extreme-srcaddonsaccelerantsintel-extreme-srcaddonskernelbussesagp-gart-srcaddonskerneldriversgraphicsintel-extreme

" Author: brecht

Date: 2011-01-29 22:20:00 +0100 (Sat, 29 Jan 2011)

New Revision: 40319

Changeset: ​http://dev.haiku-os.org/changeset/40319[[BR]]

Ticket: ​http://dev.haiku-os.org/ticket/6202

Modified:

haiku/trunk/headers/private/graphics/intel_extreme/intel_extreme.h haiku/trunk/src/add-ons/accelerants/intel_extreme/mode.cpp haiku/trunk/src/add-ons/kernel/busses/agp_gart/intel_gart.cpp haiku/trunk/src/add-ons/kernel/drivers/graphics/intel_extreme/driver.cpp

Log:

• added support for the Atom IGD, based on the X driver sources (fixes #6202)
• fixes G4x PLL limits"

[anevilyak]

No need to quote the changeset, the Trac hyperlink already does so. Assigning to Brecht.

[brecht]

hrev40319 introduced support for the N10, so it must have been running the VESA driver before. Still, it should be working with intel_extreme. Can you provide syslog output? Does your monitor complain about the screenmode?

[6foot3]

This presents a dilemma. The only way I can boot and see the screen is to use fail-safe video mode (VESA) in which case I suspect the syslog will not contain the messages that contain what goes on when not booting in fail safe mode. When not in fail safe mode I cannot view a screen so how do I then access or otherwise preserve the syslog that is generated? The computer does not have a serial port as can be seen from going to the linked specifications in the original description of the ticket.

[anevilyak]

If you reset (without powering off) immediately after the boot without video and go into the boot loader by holding shift, then go into "Select debug options", you should have an option to save the syslog from the previous boot to a USB stick.

[6foot3]

This netbook does not have a hard reset switch/button so I tried to reboot two ways.

1) After the system has completed the boot process, press Ctrl-Alt-Del which should bring up the team monitor. Then press Ctrl-Alt-Del again and hold for four seconds which invokes a reboot.

2) Drop into KDL by pressing Alt-PrtScr-d and issuing the "reboot" command.

In either case the only debug options I see are:

Enable serial debug output Enable on screen debug output Enable debug syslog (enabled)

Is there something else I should be doing?

[bonefish]

Replying to 6foot3:

This netbook does not have a hard reset switch/button so I tried to reboot two ways.

Either way is fine.

Is there something else I should be doing?

No, the feature was broken. Please retry with hrev42123 or later.

[diver]

But isn't hrev42123 committed to signals branch?
haiku/branches/developer/bonefish/signals/src/system/boot/platform/bios_ia32/mmu.cpp

[bonefish]

Replying to diver:

But isn't hrev42123 committed to signals branch?

Yuck! That was utterly unintended. That's also why I could have sworn I already fixed the same bug, although it was still there. Because I actually did that in the trunk in hrev41446. So never mind, the feature should work. If it doesn't I don't know why.

[mmlr]

Replying to bonefish:

So never mind, the feature should work. If it doesn't I don't know why.

I'm pretty sure it's because the debug option isn't actually activated when the menu isn't entered. The safemode settings are only appended when the menu options are parsed and since the menu entries are only built when the menu is actually entered, they aren't there when just booting without entering the menu. At least that's why the default option of "Disable IO-APIC" we had didn't work at all, it would only get applied when you manually entered the menu on boot.

6foot3 could you try entering the menu on the first boot and check the debug options (it should already have the debug syslog feature ticked). Then just leave the menu again and continue booting.

[6foot3]

Sorry guys, spent the day out yesterday. Will download hrev42126 and try it today.

[6foot3]

Spent some time trying to figure out how the logging works in order to try and make sure that the syslog i attach contains the relevant entries. Here's my take on how it works:

All entries are appended to the current syslog untill it reaches a size of 512kb. At that point the syslog is renamed to syslog.old and a new syslog is generated. I had been thinking that everytime the system was booted, a new syslog was created but, my observations are that this is not the case. The syslog entries after a reboot just continue to be added to the existing syslog.

In safe mode the log grows a lot more slowly as there is a lot less activity going on. Where there are no open networks within range and not in safe mode, the system appears to be continuously trying to identify a suitable network to connect to. As a result, if the system is just left doing nothing, after a while most of the entries in syslog and syslog.old will consist of these network messages.

Based on my observations and new understandung of how the syslog works, here is how captured what I believe is a relevant syslog.

I booted up in safe graphics mode and watched the syslog grow from the constant network activity until it was almost 512kb in size then, I initiated a restart. I allowed the system to boot normally until I got the blank screen following the start up sequence. I used ctrl-alt-del to reboot the system and selected safe graphis mode and safe mode from the bootloader safe mode options. Having completed booting I copied the syslog to another location and renamed it "syslog_r42159_screen blank,txt".

I suppose that most kernel and driver developers would be able to identify a shutdown/start-up sequence in the syslog. I believe that the syslog I'm attaching contains a shutdown/boot-up sequnce into normal mode, followed by another shutdown/boot-up sequence, this time into safe mode.

If I am mistaken in any of my conclusions, I welcome any explanation of how things actually work.

[6foot3]

Incedentally, I still have not seen the option under the debug options of the bootloader menu that would allow me to save the syslog. If the observations in my previous comment are correct, I can think up a couple ways we could capture the syslog produced by a particular boot process.

One way would be an option in the debug options of the bootloader menu to start a fresh syslog, with the option to save the existing syslog with a name chosen by the user.

In the case in point, I could take that option and save the existing syslog with any name eg. syslog.old.partial. When I have booted up to the blank screen and rebooted, I would take the same action again and name the existing syslog to something like syslog.no_screen since, all the entries in that syslog will be those that were created since the previous reboot.

Does anybody else think that such functionality wwould be usefull?

[diver]

6foot3, did you try to follow mmlr's suggestion from comment:14?

[6foot3]

diver, I did just before I posted that last comment. Maybe i'm doing something wrong?

[melete]

Can confirm this on EeePC 1005PE using alpha 3. Though i get some parts of the screen displayed on the integrated panel when connecting an external screen via vga connector. But even then the lower ~ quarter of the screen is still black on the built-in panel.

[6foot3]

I recently installed hrev43690 over my previous install and the issue seems to have been resolved. If melete or anyone else who was experiencing this can confirm, I suggest this ticket be closed.

[sotrud_nik]

Well, latest hrev43697 does not work on Acer Aspire One 532h, which has the same Atom N450 CPU with built-in GMA3150.

6foot3, hrev43690 does not work either

[6foot3]

It seems to me that events have caught up with this ticket. A new ticket, #9157 gives a much more accurate and concise description of what is happening. I may have ignored the 1 to 3 pixel line at the top of the screen, if it was in fact there, when I filed the ticket originally. At any rate, the behaviour I'm seeing now is exactly as described in ticket #9157. Maybe we should close this as a duplicate of #9157 or vice versa.

[axeld]

Should be fixed by now, at the latest with hrev45381 - if not, please reopen.

[6foot3]

I checked this a few days ago after seeing the updates to the intel extreme driver and it does in fact work. Great job! Now all I need to switch to haiku full time is Flash/HTML5 support!