-------- Пересылаемое сообщение -------- От кого: Мартин Бохниг <[email protected]> Кому: Discussion list for OpenIndiana <[email protected]> Копия: Apostolos Syropoulos <[email protected]>, bentahyr <[email protected]>, a.jung <[email protected]> Дата: Воскресенье, 11 сентября 2016, 16:13 UTC Тема: The compatibility PARADOX of the old versus the new i915 DRM(and now KMS submodule) kernel driver on newer (but not too new) versus older chipsets @@@@@The compatibility PARADOX of the old versus the new i915 DRM(and now KMS submodule) kernel driver on newer (but not too new) versus older chipsets @@@@@ In the old OpenSolaris days the Sun Beijing team ported Intel-DRM to OpenSolaris (in about 2006 with incremental updates until 2010 [and behind the firewall till 2013]), not for all chipsets by all vendors as offered on LinUX, but at least for the most widespread vendor: Intel. For historic Sun announcements see: ###1.######################################################(((((old radeon pciids???))))) ### https://blogs.oracle.com/erwann/entry/ati_support_for_compiz_easy ### https://blogs.oracle.com/erwann/entry/compiz_integrated_in_opensolaris_2008 ### http://pkg.openindiana.org/legacy/manifest/0/[email protected],5.11-0.96%3A20080825T194737Z ### http://web.archive.org/web/20090107043722/http://mail.opensolaris.org/pipermail/xwin-discuss/2007-December/002689.html ### http://web.archive.org/web/20091006235709/http://opensolaris.org/os/project/dri Now, for OpenSolaris this meant that by August 2010 updates stopped streaming in. The so far supported chipsets stayed supported in Illumos based distros (had functioning DRM, but no KMS and hence could run native hw-accelerated Xorg intel_drv.so ddx's until version 2.9 and could run compiz, *BUT* due to the lack of KMS couldn't run any kms-only intel_drv.so Xorg ddx, which meant that 2010's version 2.9 was the newest one could use. This applied to the following chipsets: Intel(R) Integrated Graphics Chipsets: i810, i810-dc100, i810e, i815, i830M, 845G, 854, 852GM/855GM, 865G, 915G, E7221 (i915), 915GM, 945G, 945GM, 945GME, Pineview GM, Pineview G, 965G, G35, 965Q, 946GZ, 965GM, 965GME/GLE, G33, Q35, Q33, GM45, 4 Series, G45/G43, Q45/Q43, G41, B43 ... while all the newer now on-die incorporated Intel-GPU's on Sandy, Ivy, Haswell and some Valleyview-Atoms were completely unsupported until my backport and were left to run vesa_drv.so When I performed the backport my primary testing and debugging focus were obviously those platforms, which didn't have any DRM let alone DRM/KMS support at all: Those modern ones with on-cpu-die integrated GPU's: Sandy, Ivy, Haswell, Atom-Valleyview (newer hardware is not yet supported by Oracle's original driver port). And I had been proud that I got it running there on Sandy, Ivy and Haswell and simply expected the older chipsets to function (didn't have such older testing hardware for i8xx or i9xx etc. Now we saw three users reporting black screens on such older laptops/Netbooks. And Ben was the one who finally posted enough output which proved it that there is indeed a problem on Intel(R) Integrated Graphics Chipsets: i810, i810-dc100, i810e, i815, i830M, 845G, 854, 852GM/855GM, 865G, 915G, E7221 (i915), 915GM, 945G, 945GM, 945GME, Pineview GM, Pineview G, 965G, G35, 965Q, 946GZ, 965GM, 965GME/GLE, G33, Q35, Q33, GM45, 4 Series, G45/G43, Q45/Q43, G41, B43 and which, see my response here: https://openindiana.org/pipermail/openindiana-discuss/2016-September/019436.html Now, to come to the point: I found a hardware freak on ebay who has rooms full of old computers and he permitted me to perform a few test runs, if I would buy one of these old Laptops, which I did. It is indeed true that on the older chipsets the backport resulted in a black screen, each time with the following in syslog: WARNING: [drm:drm_agp_rw_gtt:629] AGPIOC_RW_GTT failed 6 And the good news while getting this fixed via either enhancing the agpgart stack and/or preventing the drm submodule from referencing AGPIOC_RW_GTT is, that now as I finally have such incompatible testing hardware myself, I could test a long set of things which I can't describe here in a minuite. But the interesting finding is, that by copying over Sol11.3's ./ ./kernel/ ./kernel/misc/ ./kernel/misc/amd64/ ./kernel/misc/amd64/agpmaster ./kernel/drv/ ./kernel/drv/amd64/ ./kernel/drv/amd64/amd64_gart ./kernel/drv/amd64/agpgart ./kernel/drv/amd64/agptarget ./kernel/drv/agpgart.conf the same problematic backport bins suddenly do work *fine* on Hipster. BTW, 11.0 and 11.1 agp* bins don't result in a working scenario and 11.2 I so far didn't test. But while this is of course a test I could only perform on my private computer at the same time it shows that not something else in the kernel is breaking functionality. This means, in a few days you get the final repair diff from me. At this time I have 2 strategies: 1st enhancing agpgart* and friends. But what is discouraging me is the fact, that the agpgart* Sol11.1 bins which I expected to be 100% identical to the 11.3 agpgart* bins do *not* solve the problem on my private test laptop, only 11.3 does. So rather I may be requred to test it the other way around: To get rid of AGPIOC_RW_GTT all together in the drm/kms module. Mor on that in a few days. Please do not waste your time with testing the old bins on those older Intel(R) Integrated Graphics Chipsets: i810, i810-dc100, i810e, i815, i830M, 845G, 854, 852GM/855GM, 865G, 915G, E7221 (i915), 915GM, 945G, 945GM, 945GME, Pineview GM, Pineview G, 965G, G35, 965Q, 946GZ, 965GM, 965GME/GLE, G33, Q35, Q33, GM45, 4 Series, G45/G43, Q45/Q43, G41, B43 platforms until I create a modified test iso (with the new yet to be fixed test bins added to alp's Hipster iso). This is today's i915 update. Now finally some time for vbox - more from me in 8 hours. TNX to all who reported for your testing work so far :) best regards, %martin bochnig -- Мартин Бохниг ----------------------------------------------------------------------
_______________________________________________ oi-dev mailing list [email protected] https://openindiana.org/mailman/listinfo/oi-dev
