Opened 9 years ago
Closed 8 years ago
#12732 closed bug (fixed)
Regression with GMA3150 graphics
Reported by: | vote_gough | Owned by: | pulkomandy |
---|---|---|---|
Priority: | normal | Milestone: | Unscheduled |
Component: | Drivers/Graphics/intel_extreme | Version: | R1/Development |
Keywords: | Cc: | ||
Blocked By: | Blocking: | ||
Platform: | x86 |
Description
My machine is an ASUS eee pc 1015px with an Intel Atom N570 and GMA3150 graphics. Builds prior to and including hrev50194 are working fine with no issues but builds after this fail to boot, halting at the rocket icon on the splash screen. Changing to fail safe graphics and safe mode don't appear to have any effect.
Builds hrev50256 and hrev50252 both however garble the splash screen after all the boot icons are highlighted, and even though the screen is unresponsive and glitched, it seems as though the system has loaded since pressing the power button appears to initiate the shutdown sequence.
Attachments (3)
Change History (27)
comment:1 by , 9 years ago
comment:2 by , 9 years ago
Owner: | changed from | to
---|---|
Status: | new → assigned |
comment:3 by , 9 years ago
Strange, vesa 'fail safe video' should always work as the driver it uses isn't related to Intel_extreme.
Please do the following:
- boot from the latest Haiku image on a USB stick
- after system boots and screen turns garbled, wait 20 seconds.
- hold CTL + ALT + Del. Once system reboots and you see your BIOS, unplug USB stick.
- grab /boot/system/log/syslog from the USB stick and attatch it here.
comment:6 by , 9 years ago
Looks like we can't find EDID data for the LVDS display, thus flag it as disconnected.
Give hrev50262 a swirl. It should make the LVDS detection on older generation intel GPU's more 'aggressive'
I also added in the missing Atom GPU PCI id's you mentioned.
comment:7 by , 9 years ago
Will do, as soon as a new build comes out I'll give it a whirl and let you know how it goes.
comment:8 by , 9 years ago
I tried the 64bit build of hrev50262, it got past the splash screen but it glitched out after that, all white with a bunch of vertical purple lines going all over the place. I've attached the syslog if you want to have a look.
comment:9 by , 9 years ago
Since the gcc2_hybrid builds are still not out, I gave hrev50277 a go, this time x86_gcc4. The good news is that it boots to the desktop and I can interact with it such as open and close programs, type and click things fine.
However, the graphics have become, well, pixelated would probably be the best description. It sort of looks as though it's dithering, with some aspects stretched and others compressed, all looking very blocky and pixelated at native resolution.
Changing the resolution to 800x600 caused the display to go black and unresponsive.
comment:10 by , 9 years ago
Just tried out hrev50281 gcc2_hybrid, however it just boots to a black screen now after the splash screen. As before I'll attach the syslog, syslog2.
comment:11 by , 9 years ago
KERN: intel_extreme: SetDisplayMode: hardware mode will actually be 1024x600 (unscaled)
Does that look like the correct native mode?
comment:12 by , 9 years ago
Yeah... I just confirmed that mode looks right. Bah. I don't have any Intel hardware of this generation. Let me see if I can get something cheap.
comment:13 by , 9 years ago
@kallisti5 yes that's the right native resolution, if you need any other data like the syslog from hrev50194 let me know.
comment:14 by , 9 years ago
I purchased a PineView netbook of this generation, looks like the pll calculation is busted:
KERN: intel_extreme: IsConnected: LVDS C PortRegister: 0x5001180 KERN: intel_extreme: CALLED virtual status_t LVDSPort::SetDisplayMode(display_mode*, uint32) KERN: intel_extreme: SetDisplayMode: LVDS C-3 1024x600 KERN: intel_extreme: SetDisplayMode: hardware mode will actually be 1024x600 (unscaled) KERN: intel_extreme: PLL limits, min: p 7 (p1 1, p2 14), n 1, m 70 (m1 8, m2 3) KERN: intel_extreme: PLL limits, max: p 98 (p1 8, p2 7), n 6, m 120 (m1 18, m2 7) KERN: intel_extreme: compute_pll_divisors: required MHz: 49.8 KERN: intel_extreme: compute_pll_divisors: found: inf MHz, p = 0 (p1 = 0, p2 = 344), n = 0, m = 600 (m1 = 2, m2 = -450708296) KERN: intel_extreme: LVDS: dual channel
I'll take a gander.
follow-up: 21 comment:15 by , 9 years ago
I've found that my PLL calculation rewrite fixes this issue... however there were regressions on other cards. Let me do some testing, best case it fixes more than it breaks and i'll push it up.
comment:16 by , 9 years ago
Priority: | high → normal |
---|
comment:17 by , 9 years ago
Thanks a bunch kallisti5, I updated to hrev50303 and all the issue is gone, good work.
comment:18 by , 9 years ago
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
comment:19 by , 8 years ago
Resolution: | fixed |
---|---|
Status: | closed → reopened |
Regression has appeared again with hrev50525 and hrev50526 (it may have appeared earlier I haven't been able to check), it boots the loading screen fine, but when it loads the desktop it becomes all garbled, although it looks as though the system is still functioning. It boots into a normal desktop if you select fallback VESA drivers.
comment:20 by , 8 years ago
Checked again with hrev50598, both upgrading my existing Haiku install and testing with a live USB.
I can confirm this issue is persisting in both cases, but changing the graphics mode to Fallback in the boot options allows you to interact with the desktop.
comment:21 by , 8 years ago
Replying to kallisti5:
I've found that my PLL calculation rewrite fixes this issue... however there were regressions on other cards. Let me do some testing, best case it fixes more than it breaks and i'll push it up.
I think you might need to run some more tests.
comment:22 by , 8 years ago
Owner: | changed from | to
---|---|
Status: | reopened → in-progress |
I think the PLL is ok now. I had similar problems on my machines, and they are related to wrong assignment of pipes to outputs.
Basically, we set the video mode on pipe B, but leave the display attached to pipe A. I'll try to clean up my fix and push the changes sometime this week.
comment:23 by , 8 years ago
Tested with the latest nightly release, everything looks like it's working fine again.
comment:24 by , 8 years ago
Resolution: | → fixed |
---|---|
Status: | in-progress → closed |
woot! Thanks for testing. Please open another bug if any additional issues are seen.
I am guessing that it must of been hrev50198 ?
The Atom D4xx and Atom N4xx seem to be supported by the driver, but the Atom D5xx and Atom N5xx seem to be missing.
Pineview chipsets: Atom D4xx A001 Atom D5xx A002 Atom N4xx A011 Atom N5xx A012