Opened 3 years ago

Closed 11 months ago

#12714 closed bug (fixed)

intel_extreme driver not recognizing gpu anymore

Reported by: jua Owned by: kallisti5
Priority: normal Milestone: R1/beta2
Component: Drivers/Graphics/intel_extreme Version: R1/Development
Keywords: Cc: luroh
Blocked By: Blocking: #12735
Has a Patch: no Platform: All

Description

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

Attachments (12)

syslog.old (512.0 KB ) - added by Paradoxon 3 years ago.
syslogfile of a failed boot
syslog (63.8 KB ) - added by Paradoxon 3 years ago.
Log of a failed boot
0x0416_syslog.txt (205.1 KB ) - added by humdinger 3 years ago.
non-working Haswell Mobile (used to work originally)
syslog.2 (106.9 KB ) - added by vidrep 3 years ago.
Hardware report (695.5 KB ) - added by vidrep 3 years ago.
syslog_50234_sandybridge.txt (169.7 KB ) - added by luroh 3 years ago.
syslog_50303_sandybridge.txt (169.2 KB ) - added by luroh 3 years ago.
syslog_hrev50303_x86_64 (134.6 KB ) - added by vidrep 3 years ago.
syslog_50330_sandybridge.txt (169.0 KB ) - added by luroh 3 years ago.
syslog_50197_sandybridge.txt​ (164.0 KB ) - added by luroh 3 years ago.
syslog_50505_sandybridge.txt (168.0 KB ) - added by luroh 3 years ago.
syslog_50512_sandybridge.txt (169.2 KB ) - added by luroh 3 years ago.

Change History (53)

comment:1 by jua, 3 years ago

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...

comment:2 by korli, 3 years ago

Owner: changed from axeld to kallisti5
Status: newassigned

comment:3 by kim1963, 3 years ago

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

Last edited 3 years ago by kim1963 (previous) (diff)

by Paradoxon, 3 years ago

Attachment: syslog.old added

syslogfile of a failed boot

by Paradoxon, 3 years ago

Attachment: syslog added

Log of a failed boot

comment:4 by kallisti5, 3 years ago

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

comment:5 by humdinger, 3 years ago

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.

by humdinger, 3 years ago

Attachment: 0x0416_syslog.txt added

non-working Haswell Mobile (used to work originally)

comment:6 by kallisti5, 3 years ago

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 :-\

comment:7 by kallisti5, 3 years ago

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

comment:8 by jua, 3 years ago

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

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

comment:9 by vidrep, 3 years ago

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.

by vidrep, 3 years ago

Attachment: syslog.2 added

by vidrep, 3 years ago

Attachment: Hardware report added

in reply to:  6 ; comment:10 by humdinger, 3 years ago

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 (after uncommenting my chipset in driver.cpp) 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...

Last edited 3 years ago by humdinger (previous) (diff)

in reply to:  10 comment:11 by kallisti5, 3 years ago

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.

comment:12 by luroh, 3 years ago

Cc: luroh added

comment:13 by luroh, 3 years ago

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

by luroh, 3 years ago

comment:14 by jua, 3 years ago

Blocking: 12735 added

(In #12735) Duplicate of #12714

comment:15 by luroh, 3 years ago

No change with hrev50303.

comment:16 by kallisti5, 3 years ago

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.

comment:17 by luroh, 3 years ago

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

by luroh, 3 years ago

comment:18 by vidrep, 3 years ago

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.

by vidrep, 3 years ago

Attachment: syslog_hrev50303_x86_64 added

comment:19 by luroh, 3 years ago

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.

by luroh, 3 years ago

comment:20 by kallisti5, 3 years ago

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.

comment:21 by luroh, 3 years ago

Attaching syslog from hrev50197, native resolution.

by luroh, 3 years ago

comment:22 by kallisti5, 3 years ago

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.

comment:23 by pulkomandy, 3 years ago

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?)

comment:24 by luroh, 3 years ago

Works for me again as of hrev50504.

by luroh, 3 years ago

comment:25 by pulkomandy, 3 years ago

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.

comment:26 by humdinger, 3 years ago

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.

comment:27 by kallisti5, 3 years ago

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.

comment:28 by luroh, 3 years ago

Still working for me with hrev50512.

by luroh, 3 years ago

comment:29 by pulkomandy, 3 years ago

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.

comment:30 by humdinger, 3 years ago

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

comment:31 by luroh, 11 months ago

Resolution: fixed
Status: assignedclosed

hrev52396, 8086:0126 still working fine.

comment:32 by humdinger, 11 months ago

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

comment:33 by tqh, 11 months ago

Resolution: fixed
Status: closedreopened

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

comment:34 by luroh, 11 months ago

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

comment:35 by humdinger, 11 months ago

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

comment:36 by luroh, 11 months ago

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

comment:37 by tqh, 11 months ago

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.

comment:38 by pulkomandy, 11 months ago

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.

comment:39 by pulkomandy, 11 months ago

Milestone: UnscheduledR1/beta2

comment:40 by jua, 11 months ago

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.

comment:41 by pulkomandy, 11 months ago

Resolution: fixed
Status: reopenedclosed

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.

Note: See TracTickets for help on using tickets.