intel_extreme driver not recognizing gpu anymore

[jua]

After updating to hrev50209, I'm only getting VESA graphics (with wrong screen resolution) on a SandyBridge-based laptop, which worked fine before.

[jua]

Device is

device Display controller (VGA compatible controller, VGA controller) [3|0|0]
  vendor 8086: Intel Corporation
  device 0126: 2nd Generation Core Processor Family Integrated Graphics Controller

Syslog contains only a single line regarding intel_extreme:

KERN: intel_extreme: CALLED status_t init_hardware()

Right after that it loads the VESA driver.

p.s. seems Trac automatically puts in axeld for this compoent, and I can't "unassign" it...

[kim1963]

hrev50209 device Display controller (VGA compatible controller, VGA controller) [3|0|0]

vendor 8086: Intel Corporation device 0166: 3rd Gen Core processor Graphics Controller

~> sysinfo Kernel name: kernel_x86 built on: Apr 9 2016 23:14:46 version 0x1 4 Intel Core™ i3-3110M, revision 306a9 running at 2394MHz

loads the VESA driver

[Paradoxon]

syslogfile of a failed boot

[Paradoxon]

Log of a failed boot

[kallisti5]

I disabled SandyBridge because it was untested... feel free to uncomment the sandybridge chipsets and do a test :-)

​http://cgit.haiku-os.org/haiku/tree/src/add-ons/kernel/drivers/graphics/intel_extreme/driver.cpp#n85

[humdinger]

I compiled with 0x0416, INTEL_MODEL_HASM, "Haswell Mobile" re-enabled. Doesn't work, unfortunately. Got a black screen some time after the boot screen icons. Attached is the syslog.

[humdinger]

non-working Haswell Mobile (used to work originally)

[kallisti5]

err... strange. your syslog is missing a *lot* of trace data. You should see it probing various port types. (LVDSPort, HDMIPort, etc)

That intel_extreme output almost looks like the old driver.

Also, Haswell desktops have panels connected over DDI connectors... the old driver had 0 code to support those.. I think your Haswell might of worked via a random chance.

Also, you mentioned SandyBridge in the ticket but then submitted a Haswell test result :-\

[kallisti5]

I have a Haswell laptop that didn't work on pre or post rewrite enforcing the "if it worked, it was likely dumb luck :-)"

[jua]

Also, you mentioned SandyBridge in the ticket but then submitted a Haswell test result :-\

You're mixing up reports, the SandyBridge was mine.

[vidrep]

I have attached a syslog from a fresh install of hrev50216 x86_gcc2 as well as a hwchecker_report using mmlr's hardwarechecker script. The symptom is "black screen" after the "rocket" icon.

[humdinger]

Replying to kallisti5:

err... strange. your syslog is missing a *lot* of trace data. You should see it probing various port types. (LVDSPort, HDMIPort, etc)

Do you need a syslog of my current productive system using the old driver?

That intel_extreme output almost looks like the old driver.

Here's what I did after booting a newly updated installation and found it using VESA:
I built intel_extreme of the latest hrev and put it and its link into the respective folders under /system/non-packaged of the test partition.
Booting that test partition I black-listed the intel_extreme driver in the boot options.

Also, Haswell desktops have panels connected over DDI connectors... the old driver had 0 code to support those.. I think your Haswell might of worked via a random chance.

I have a Haswell Mobile (i7-4712MQ).

I have a Haswell laptop that didn't work on pre or post rewrite enforcing the "if it worked, it was likely dumb luck :-)"

Either that, or mmlr's driver did something right...

[kallisti5]

Replying to humdinger:

I have a Haswell laptop that didn't work on pre or post rewrite enforcing the "if it worked, it was likely dumb luck :-)"

Either that, or mmlr's driver did something right...

Nope :-) and the rewrite was largely based on mmlr's previous uncommited work.

I'm working on #12716, but will circle back to this one soon.

[luroh]

Like jua, I have a device 8086:0126 that only displays black screen if I enable SandyBridge, attaching syslog.

[jua]

(In #12735) Duplicate of #12714

[luroh]

No change with hrev50303.

[kallisti5]

luroh: I assume you're still enabling your GPU? Any chance of logs after the most recent changes?

SandyBridge -> Skylake saw some major shuffle of where things are at and what links need to be trained which is why it is such a feat to support. I miss working on our radeon_hd driver a little... AtomBIOS spoiled me.

[luroh]

Yes, I enabled the driver for the GPU. Attaching syslog.

[vidrep]

For what it's worth, I have attached a syslog of a fresh 64 bit install and update to hrev50303. Hopefully it will provide something useful.

[luroh]

hrev50330 with the modifications mentioned in ​http://www.freelists.org/post/haiku-development/intel-extreme-rework-status,3 although it's entirely possible that I messed something up, instructions were not very detailed. Anyhow, same result, black screen. Attaching syslog.

[kallisti5]

any chance of a syslog from the working SandyBridge system before the redesign? I'm curious if there are any major differences in the PLL calculations.

Let's take Haswell out of this bug, that didn't work before the rework either.

Your syslogs show it is finding the correct resolution, finding a sane PLL, and properly programming the LVDS display.

[luroh]

Attaching syslog from hrev50197, native resolution.

[kallisti5]

Definitely looks like the PLL's are getting calculated differently on SnB:

Before:

 PLL limits, min: p 5 (p1 1, p2 10), n 1, m 79 (m1 12, m2 5)
 PLL limits, max: p 80 (p1 8, p2 5), n 5, m 127 (m1 22, m2 9)
 compute_pll_divisors: required MHz: 75.2
 compute_pll_divisors: found: 75.2 MHz, p = 40 (p1 = 4, p2 = 10), n = 3, m = 94 (m1 = 17, m2 = 9)

Now:

 compute_dpll_g4x: required MHz: 75.2
 PLL limits, min: p 28 (p1 2, p2 14), n 1, m 79 (m1 12, m2 5)
 PLL limits, max: p 112 (p1 8, p2 14), n 3, m 118 (m1 22, m2 9)
 compute_dpll_g4x: best MHz: 31.1429 (error: 44.0571)
 compute_pll_divisors: found: p = 112 (p1 = 8, p2 = 14), n = 3, m = 109 (m1 = 18, m2 = 7)

The PLL error is too high there.

[pulkomandy]

does it always result in 31.1429 for any input? Because I got a similar value on my laptop while trying to get 68.9MHz. Looks like maybe the computation is not run at all?

I also see both P and N are at their max value in either case. Could it be that some loop is backwards (n = max_n; n < min_n; n++ or so?)

[luroh]

Works for me again as of hrev50504.

[pulkomandy]

I did not want to commit these changes yet, as I don't understand why they make things work. They revert some things in the driver to the way they were before kallisti5's changes, but are against what's in Intel specs. Leaving the ticket open for now, as we should understand the actual problem and try to fix it the right way. But we'll keep the changes in, if they fix more than just my own hardware.

[humdinger]

For my Haswell Mobile (i7-4712MQ: 0x0416, INTEL_MODEL_HASM) it took a turn to the worse. With hrev50504, I get a black screen after all boot icons lit up. Unfortunately, a syslog isn't available.

[kallisti5]

I need to warn with Pulkomandy's change, he's essentially writing nonsense to the card and breaking some register sets to get SnB working... I strongly disagree with the intel_extreme changes in hrev50504... but don't have time at the moment to look at SnB.

[luroh]

Still working for me with hrev50512.

[pulkomandy]

p.s. seems Trac automatically puts in axeld for this compoent, and I can't "unassign" it...

There is an user named "nobody" to workaround that limitation in Trac. Or you can just assign someone who touched the code recently.

Anyway, please try hrev50512 which restores SandyBridge and later specific behavior, as originally implemented by mmlr.

[humdinger]

Didn't make a difference on my hardware (Haswell Mobile (i7-4712MQ: 0x0416, INTEL_MODEL_HASM)). Still a black screen and no syslog.

[luroh]

hrev52396, 8086:0126 still working fine.

[humdinger]

r1beta1: still black screen on notebook (8086:0416) and desktop (8086:0412). Re-open?

[tqh]

There are a lot of issues with Intel hw combinations. And there needs to be support for EDP, DP and possible HDMI. Probably best reference is Zircon Intel driver which does it quite nicely: ​https://github.com/fuchsia-mirror/zircon/tree/master/system/dev/display/intel-i915

[luroh]

This ticket was about a regression related to device 8086:0126, was it not?

[humdinger]

As the title is so generic, it may make sense to collect all non-working intel drivers here and strike those that get fixed.

[luroh]

I'd rather suggest people refrain from hijacking tickets. I know there's no malicious intent.

[tqh]

Usually we check with reporter and others that wrote in ticket before we close. But yes might be good to divide different chipsets, except there seems to be a lot of them already, so probably better to try and combine them to similar issues.

[pulkomandy]

In the case of driver issues I prefer tokeep a separate one for each affected machine, unless there isstrong evidence the problem is the same (eg kdl with same backtrace). There are so many ways a graphic driver can get to a black screen.

[jua]

The issue with the SandyBridge GPU mentioned in the ticket text is fixed, that one works again. Not as well as it did before the driver rewrite (VGA output is still broken - worked before), but the GPU is recognized.

I think it's ok to repurpose the ticket, as long as it sticks to the original theme: intel_extreme GPUs which worked before the driver rewrite of 3 years ago, but were broken afterwards.

[pulkomandy]

I really prefer one ticket per separate device even in that case. There isn't a single regression to fix and it's a waste of time having to read through the comments, trying to match syslogs with devices, etc, to find where we are with each one.

Large tickets like this become hard to work on and you're never sure all cases are covered. So, if you have a problem just open a new ticket, this one has been fixed already.