Bug 80396

Hello,

the same problems appear on HP nc6120 Laptops.

Greetings,

Mela Eckenfels
-- 
"Was ich an den Konsolen schaetze, ist ihre Kompromisslosigkeit: Du kannst 
einen Phaserbeschuss oder einen Torpedo ueberleben. Aber eine Konsole macht 
keine Gefangenen." - Andreas Luebbecke in <38849FA1.C6A0F8D5@gmx.de>

Comment 2 Eric Anholt 2005-05-06 00:07:09 UTC

Responsible Changed
From-To: freebsd-bugs->anholt

Go ahead and snag this one, as I've taken a few steps towards i915 AGP support. 
Hopefully I'll have a patch soon (lack hardware, though).

http://people.freebsd.org/~anholt/agp-i915.diff

also has the attached patch.  It's a totally untested (beyond compiling)
port of what linux does in its i915 AGP driver, as far as I can tell.
Some of it seems shady to me (not multiplying the offset by 4 again in
bind/unbind page), but I think it also fixes an issue with binding
dcache memory on i810.

I'd love to get feedback and review on this.

-- 
Eric Anholt                                     eta@lclark.edu
http://people.freebsd.org/~anholt/              anholt@FreeBSD.org

Comment 4 Eric Anholt 2005-05-09 23:49:07 UTC

State Changed
From-To: open->feedback

Waiting for feedback from someone with i915.

I've applied your patch against 54-release source on a DELL GX280 
desktop with PCI express.

The i915G now appears as devive agp0:


agp0: <Intel 82915G (915G GMCH) SVGA controller> port 0xe898-0xe89f mem 
0xdfec0000-0xdfefffff,0xc0000000-0xcfffffff,0xdff00000-0xdff7ffff irq 16 
at device 2.0 on pci0
agp0: detected 8060k stolen memory
agp0: aperture size is 256M


agp0@pci0:2:0:  class=0x030000 card=0x01791028 chip=0x25828086 rev=0x04 
hdr=0x00
     vendor   = 'Intel Corporation'
     device   = '82915G Graphics device'
     class    = display
     subclass = VGA



However, the controller still isn't assigned a device.
pci0: <display> at device 2.1 (no driver attached)


none0@pci0:2:1: class=0x038000 card=0x01791028 chip=0x27828086 rev=0x04 
hdr=0x00
     vendor   = 'Intel Corporation'
     device   = '82915G Express Chipset Family Graphics Controller'
     class    = display


I've attached a dmesg and pciconf -lv and Xorg.O.log


Let me know if you need more information.


Donal

On Mon, May 09, 2005 at 10:49:18PM +0000, Eric Anholt wrote:

Hi...

> Waiting for feedback from someone with i915.
I just compiled a new kernel out of RELENG_5_4 with your patch.
but my agp is still not visible :(

attached, the details



cheers
	Martin

To the 1st reply:

I think that 2nd display device is a placeholder used by windows for the
2nd head you have (you've got a dualhead option, right?), so that's
expected.  However, the "xf86AllocateGARTMemory: allocation of 4 pages
failed" and other GART errors aren't expected, and indicates that the
driver isn't working right.

To the 2nd reply: You would have to add your even newer chipset (2592)
to the list of pci ids supported and the related switch statements.  I
haven't checked if it's expected to work the same.

-- 
Eric Anholt                                     eta@lclark.edu
http://people.freebsd.org/~anholt/              anholt@FreeBSD.org

Comment 8 Eric Anholt 2005-06-13 10:37:20 UTC

State Changed
From-To: feedback->suspended

Stash this in suspended state until someone can finish off the patch.

Here is another report, with (partial) success.
X server sometimes failed to be started on my machine.


My machine is NEC's liquid-cooled desktop featuring i915G.
I had installed FreeBSD 5.4-RELEASE,
and successfully configured X.org 6.8.2 using "vesa" driver,
under the control of GDM 2.6.0.8 (installed from packages).

Then I've also tried the patch.
I've extracted clean 5.4-RELEASE kernel source tree and simply applied it.
After reboot, agp0 appears.

agp0: <Intel 82915G (915G GMCH) SVGA controller> port 0xb800-0xb807 mem 0xb0000000-0xb003ffff,0xc0000000-0xcfffffff,0xb0080000-0xb00fffff irq 16 at device 2.0 on pci0
agp0: detected 8060k stolen memory
agp0: aperture size is 256M

But at first time, as previously reported,
X server was killed with the 'xf86BindGARTMemory' warnings,
GDM gave up starting X server after 3 times trials.
There were 3 duplications of
"agp0: trying to bind into stolen memory" in syslog.

Then I added << Option "DRI" "False" >> to /etc/X11/xorg.conf,
send HUP signal to GDM to start X server again.
This time, GDM successfully showed login prompt,
but the cursor turned into a white rectangle.
After I added << Option "SWcursor" "True" >> to xorg.conf and restart X,
wow, it seemed perfect.

However, things are more complicated.
When I reboot my machine, GDM reports once failing to start X,
and the login prompt appears after that.
I suppose something is still wrong.

I'm attaching the Xorg.0.log logs as well as something else.
One is for failed case, and the other is for succeeded case.

Thanks.

-- 
Motomichi Matsuzaki, PhD <mzaki@biol.s.u-tokyo.ac.jp>
Dept. of Biological Sciences, Grad. School of Science, Univ. of Tokyo, Japan

Hi,

I'm attaching new patch.
Please try it; apply the patch after applying Eric's.

Changes are:
* Add 915GM device ID
* 915G uses new PCI register to disable/enable integrated graphics
    DEVEN (Dev2:Func0 0x54) bit 3
* 915G uses new PCI register to change aperture size
    MSAC (Dev2:Func0 0x62) bit 1
* 915G initializes 256k GATT on boot
    I'm not sure what it is. This is based on a NetBSD patch.
    (http://mail-index.netbsd.org/port-i386/2004/12/23/0006.html)

This patch makes X successfully started.
However, as referred in the NetBSD patch,
the hardware cursor and the acceleration doesn't work correctly.

Thanks.

-- 
Motomichi Matsuzaki, PhD <mzaki@biol.s.u-tokyo.ac.jp>
Dept. of Biological Sciences, Grad. School of Science, Univ. of Tokyo, Japan

On Thu, Jun 16, 2005 at 09:56:07PM +0900, Motomichi Matsuzaki wrote:
> I'm attaching new patch.
> Please try it; apply the patch after applying Eric's.

Thanks for your work. Unfortunatly here on my HP Compaq nc6120 there
isn't much effect.

I've attached the dmesg and startx-output.

Greetings,

Mela
-- 
Real-Life Quotes [3]: Bernd ueber Melas Fahrstil:
"Ich wuenschte ja du haettest mal vor richtigen Gefahren Angst und nicht
nur vor solch abstrakten wie "Familienfeiern".

Hi, 

At Fri, 17 Jun 2005 05:31:38 +0200,
Mela Eckenfels wrote:
> Thanks for your work. Unfortunatly here on my HP Compaq nc6120 there
> isn't much effect.
   :
   :
> (--) PCI:*(0:2:0) Intel Corp. unknown chipset (0x2592) rev 3, Mem @ 0xd0400000/19, 0xc0000000/28, 0xd0480000/18, I/O @ 0x7000/3
> (--) PCI: (0:2:1) Intel Corp. unknown chipset (0x2792) rev 3, Mem @ 0xd0500000/19
   :
   :
> (II) I810: Driver for Intel Integrated Graphics Chipsets: i810, i810-dc100,
> 	i810e, i815, i830M, 845G, 852GM/855GM, 865G, 915G
> (II) Primary Device is: PCI 00:02:0
> (WW) I810: No matching Device section for instance (BusID PCI:0:2:1) found
> (EE) No devices detected.

It seems none of FreeBSD problems, but X.org 6.8.2 doesn't know about 915GM.

I found XFree86 4.5.0 supports 915GM in addition to 915G,
so how about trying XFree86 4.5.0.
Otherwise, use latest snapshot of X.org.
(http://xorg.freedesktop.org/snapshots/)

-- 
Motomichi Matsuzaki, PhD <mzaki@biol.s.u-tokyo.ac.jp>
Dept. of Biological Sciences, Grad. School of Science, Univ. of Tokyo, Japan

Comment 13 Hajimu UMEMOTO 2005-06-19 06:18:45 UTC

Hi,

>>>>> On Thu, 16 Jun 2005 21:56:07 +0900
>>>>> Motomichi Matsuzaki <mzaki@biol.s.u-tokyo.ac.jp> said:

mzaki>  I'm attaching new patch.
mzaki>  Please try it; apply the patch after applying Eric's.

mzaki>  Changes are:
mzaki>  * Add 915GM device ID
mzaki>  * 915G uses new PCI register to disable/enable integrated graphics
mzaki>      DEVEN (Dev2:Func0 0x54) bit 3
mzaki>  * 915G uses new PCI register to change aperture size
mzaki>      MSAC (Dev2:Func0 0x62) bit 1
mzaki>  * 915G initializes 256k GATT on boot
mzaki>      I'm not sure what it is. This is based on a NetBSD patch.
mzaki>      (http://mail-index.netbsd.org/port-i386/2004/12/23/0006.html)

Thank you.  With your patch, Intel 915GMS Express is now recognized on
my Panasonic Let'snote LITE CF-R4
(http://panasonic.jp/pc/products/r4g/index.html):

agp0: <Intel 82915GM (915GM GMCH) SVGA controller> port 0x1800-0x1807 mem 0xb0080000-0xb00fffff,0xc0000000-0xcfffffff,0xb0000000-0xb003ffff irq 16 at device 2.0 on pci0
agp0: detected 7932k stolen memory
agp0: aperture size is 256M

The output of pciconf -lv is:

agp0@pci0:2:0:  class=0x030000 card=0x833810f7 chip=0x25928086 rev=0x03 hdr=0x00    vendor   = 'Intel Corporation'
    device   = '82915GM/GMS, 82910GML Integrated Graphics Device'
    class    = display
    subclass = VGA

mzaki>  This patch makes X successfully started.
mzaki>  However, as referred in the NetBSD patch,
mzaki>  the hardware cursor and the acceleration doesn't work correctly.

I've tried ports/x11-servers/xorg-server-snap which supports 915.  It
seems working but I need to specify NoAccel and SWCursor.

Sincerely,

--
Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan
ume@mahoroba.org  ume@{,jp.}FreeBSD.org
http://www.imasy.org/~ume/

Hi,

I have a notebook with the i915GM chip.

I'm running the latest FreeBSD 6.0 (BETA5) plus both
patches from PR/80396, i.e. the one from Eric Anholt plus
the one from Motomichi Matsuzaki.  I'm using the latest
Xorg snapshot from the ports collection (6.8.99.12).

The result is the same as others have reported:  Now
the agp0 device is detected, and the X server basically
works, but I have to enable SWCursor (the hardware cursor
only gives a white square) and NoAccel (otherwise I get
some garbage, like broken lines when scrolling in xterm).
But with NoAccel, scrolling in xterm is sluggish, so this
is not really desirable.

However -- WITHOUT the agp patches, Xorg 6.8.99.12 works
fine _with_ 2D acceleration, and scrolling in xterm works
correctly and is smooth.  Since agp0 is not detected when
the patches are not applied, the hardware cursor is
disabled automatically, and also the XVideo extension is
disabled.

It sounds strange, but currently I prefer that my agp0
is not detected, for the above reasons.  :-)   This will
change, of course, when the acceleration problem is fixed.

Another point to note:  There is a much newer Xorg snapshot
available, which is the first release-candidate for 6.9:

http://xorg.freedesktop.org/X11R6.9-RC0/

Maybe it supports the i915/i915GM better and fixes the
cursor and acceleration problems?  I tried to update the
xorg-server-snapshot to 6.9-RC0 for myself, but I wasn't
successful in compiling it.  :-(

Best regards
   Oliver

-- 
Oliver Fromme,  secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing
Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd
Any opinions expressed in this message may be personal to the author
and may not necessarily reflect the opinions of secnetix in any way.

"Being really good at C++ is like being really good
at using rocks to sharpen sticks."
        -- Thant Tessman

New patch is up at http://people.freebsd.org/~anholt/agp-i915-2.diff

Untested, as usual, but now with Motomichi Matsuzaki's changes
integrated, plus fixing writing of the gatt entries (missed a * 4 in
offset calculation).

Sometimes I'm amazed at how well hardware will hold up in the presence
of gross misprogramming.  I can't believe people survived with the
previous diff even with acceleration/cursor disabled.

-- 
Eric Anholt                                     eta@lclark.edu
http://people.freebsd.org/~anholt/              anholt@FreeBSD.org

Comment 16 Eric Anholt 2005-11-23 04:32:34 UTC

State Changed
From-To: suspended->feedback

New diff, new pass through "feedback" state.

Hi Eric,

Eric Anholt wrote:
 > 
 > New patch is up at http://people.freebsd.org/~anholt/agp-i915-2.diff
 > 
 > Untested, as usual, but now with Motomichi Matsuzaki's changes
 > integrated, plus fixing writing of the gatt entries (missed a * 4 in
 > offset calculation).

I'll try at the weekend (I hope I'll have enough time then).
Thank you very much for your efforts!

By the way, is there a chance that the xorg-devel port will
be updated to the latest X.org snapshot?  That would be
6.8.99.902 from November 10th (2 weeks ago).  The current
version of the port is 4 months old (6.8.99.16 from July).

According to the change logs, several fixes have gone into
X.org's i810/915 driver.  Therefore I think it is possible
that some problems will go away with the latest snapshot.

Best regards
   Oliver

-- 
Oliver Fromme,  secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing
Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd
Any opinions expressed in this message may be personal to the author
and may not necessarily reflect the opinions of secnetix in any way.

'Instead of asking why a piece of software is using "1970s technology,"
start asking why software is ignoring 30 years of accumulated wisdom.'

Yet another new patch, this time fixing a copy'n'paste-o.  Now we try to
write the GTT entries into the desired framebuffer area, rather than all
over the register space.  Oops.

http://people.freebsd.org/~anholt/agp-i915-3.diff

-- 
Eric Anholt                                     eta@lclark.edu
http://people.freebsd.org/~anholt/              anholt@FreeBSD.org

Comment 19 Eric Anholt 2005-12-02 23:51:46 UTC

State Changed
From-To: feedback->closed

More bugs were fixed, and the result was committed to -current.

Eric Anholt wrote:
 > Yet another new patch, this time fixing a copy'n'paste-o.  Now we try to
 > write the GTT entries into the desired framebuffer area, rather than all
 > over the register space.  Oops.
 > 
 > http://people.freebsd.org/~anholt/agp-i915-3.diff

With the latest RELENG_6 (checked out a few minuts ago),
the patch applies cleanly, but I get the below errors
during compiling.  The missing names are nowhere in my
kernel sources.  What am I missing?  Does it require
-current?

Best regards
   Oliver

cc -c -O -pipe -march=pentium4m -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  -fformat-extensions -std=c99 -g -nostdinc -I-  -I. -I../../.. -I../../../contrib/altq -I../../../contrib/ipfilter -I../../../contrib/pf -I../../../contrib/dev/ath -I../../../contrib/dev/ath/freebsd -I../../../contrib/ngatm -I../../../dev/twa -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-gro wth=100 --param large-function-growth=1000  -mno-align-long-strings -mpreferred-stack-boundary=2  -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -ffreestanding -Werror  ../../../pci/agp_i810.c
../../../pci/agp_i810.c: In function `agp_i810_probe':
../../../pci/agp_i810.c:251: error: `AGP_I915_DEVEN' undeclared (first use in this function)
../../../pci/agp_i810.c:251: error: (Each undeclared identifier is reported only once
../../../pci/agp_i810.c:251: error: for each function it appears in.)
../../../pci/agp_i810.c:252: error: `AGP_I915_DEVEN_D2F0' undeclared (first use in this function)
../../../pci/agp_i810.c:253: error: `AGP_I915_DEVEN_D2F0_DISABLED' undeclared (first use in this function)
../../../pci/agp_i810.c: In function `agp_i810_attach':
../../../pci/agp_i810.c:310: error: `AGP_I915_MMADR' undeclared (first use in this function)
../../../pci/agp_i810.c:324: error: `AGP_I915_GTTADR' undeclared (first use in this function)
../../../pci/agp_i810.c:431: error: `AGP_I915_GCC1_GMS_STOLEN_48M' undeclared (first use in this function)
../../../pci/agp_i810.c:434: error: `AGP_I915_GCC1_GMS_STOLEN_64M' undeclared (first use in this function)
../../../pci/agp_i810.c: In function `agp_i810_detach':
../../../pci/agp_i810.c:493: error: `AGP_I915_GTTADR' undeclared (first use in this function)
../../../pci/agp_i810.c:494: error: `AGP_I915_MMADR' undeclared (first use in this function)
../../../pci/agp_i810.c: In function `agp_i810_get_aperture':
../../../pci/agp_i810.c:531: error: `AGP_I915_MSAC' undeclared (first use in this function)
../../../pci/agp_i810.c:532: error: `AGP_I915_MSAC_GMASIZE' undeclared (first use in this function)
../../../pci/agp_i810.c:533: error: `AGP_I915_MSAC_GMASIZE_128' undeclared (first use in this function)
../../../pci/agp_i810.c: In function `agp_i810_set_aperture':
../../../pci/agp_i810.c:591: error: `AGP_I915_MSAC' undeclared (first use in this function)
../../../pci/agp_i810.c:592: error: `AGP_I915_MSAC_GMASIZE' undeclared (first use in this function)
../../../pci/agp_i810.c:596: error: `AGP_I915_MSAC_GMASIZE_128' undeclared (first use in this function)
../../../pci/agp_i810.c:599: error: `AGP_I915_MSAC_GMASIZE_256' undeclared (first use in this function)
*** Error code 1

-- 
Oliver Fromme,  secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing
Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd
Any opinions expressed in this message may be personal to the author
and may not necessarily reflect the opinions of secnetix in any way.

"C is quirky, flawed, and an enormous success."
        -- Dennis M. Ritchie.

On Sun, 2005-12-04 at 20:59 +0100, Oliver Fromme wrote:
> Eric Anholt wrote:
>  > Yet another new patch, this time fixing a copy'n'paste-o.  Now we try to
>  > write the GTT entries into the desired framebuffer area, rather than all
>  > over the register space.  Oops.
>  > 
>  > http://people.freebsd.org/~anholt/agp-i915-3.diff
> 
> With the latest RELENG_6 (checked out a few minuts ago),
> the patch applies cleanly, but I get the below errors
> during compiling.  The missing names are nowhere in my
> kernel sources.  What am I missing?  Does it require
> -current?


You also need the agpreg.h bits.  That patch is old and broken, anyway
-- use -current's stuff.

-- 
Eric Anholt                                     eta@lclark.edu
http://people.freebsd.org/~anholt/              anholt@FreeBSD.org

Eric Anholt wrote:
 > On Sun, 2005-12-04 at 20:59 +0100, Oliver Fromme wrote:
 > > Eric Anholt wrote:
 > > > Yet another new patch, this time fixing a copy'n'paste-o.  Now we try to
 > > > write the GTT entries into the desired framebuffer area, rather than all > ll
 > > > over the register space.  Oops.
 > > > 
 > > > http://people.freebsd.org/~anholt/agp-i915-3.diff
 > > 
 > > With the latest RELENG_6 (checked out a few minuts ago),
 > > the patch applies cleanly, but I get the below errors
 > > during compiling.  The missing names are nowhere in my
 > > kernel sources.  What am I missing?  Does it require
 > > -current?
 > 
 > You also need the agpreg.h bits.  That patch is old and broken, anyway
 > -- use -current's stuff.

You mean that the patch which you announced on Friday is
obsolete?  I didn't know that.

Anyway, I checked out the agp* files from -current just
a few minutes ago, copied them into my RELENG_6 tree,
then compiled and rebooted while holding my breath ...

Finally, good news.  :)

The AGP device is detected, Xorg starts up without any
problems, hardware cursor works, acceleration (2D) works,
and the XVideo extension works, so I can watch videos
full-screen without CPU overhead.  (By the way, I'm using
the latest Xorg snapshot 6.8.99.902.  The previous one
did have a few issues, so I had to update.)

Thankyou very, very much, Eric!  :)

As far as I am concerned, I think the agp source bits can
be MFCed to RELENG_6 and the PR be closed.  (Note that I'm
not the originator of the PR, though.)

I haven't tried DRI/DRM yet, because I don't need 3D
acceleration (what do you need that for anyway?), but
I'll give it a try when I have some time (maybe at the
weekend).

I have placed copies of my Xorg.log file at the following
URL.  (With plain RELENG_6 sources, with your agp patches
from -current, and a diff between them.)

http://www.secnetix.de/~olli/dmesg/centaur/

Best regards
   Oliver

PS:  There's a small glitch with the HW cursor memory
allocation:

(II) I810(0): Allocated 4 kB for HW cursor at 0xffff000 (0x2e7c8000)
(WW) I810(0): xf86AllocateGARTMemory: allocation of 4 pages failed
       (Cannot allocate memory)
(EE) I810(0): Failed to allocate HW (ARGB) cursor space.
(II) I810(0): Allocated 4 kB for Overlay registers at 0xfffe000 (0x2e8c9000).
[...]
(II) I810(0): Initializing HW Cursor

The hardware cursor seems to work fine anyhow, so I assume
the above (WW) and (EE) don't really indicate a fatal
problem.

PPS:  For your information, this is from dmesg:

agp0: <Intel 82915GM (915GM GMCH) SVGA controller> port 0x1800-0x1807 mem 0xb0080000-0xb00fffff,0xc0000000-0xcfffffff,0xb0000000-0xb003ffff irq 16 at device 2.0 on pci0
agp0: detected 7932k stolen memory
agp0: aperture size is 256M

I assume the "aperture size" is something different than
the shared video RAM size, right?  I'm asking because I've
set the latter to 128 in the BIOS setup, not 256.

-- 
Oliver Fromme,  secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing
Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd
Any opinions expressed in this message may be personal to the author
and may not necessarily reflect the opinions of secnetix in any way.

"The scanf() function is a large and complex beast that often does
something almost but not quite entirely unlike what you desired."
        -- Chris Torek

hi everybody?

is this pr still active?

i am running RELENG_6 from last week and still have the known problems:
 from dmesg:
----
vga0: <Generic ISA VGA> at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0
----

also note that setting hw.pci.allow_unsupported_io_range=1 adds this to dmesg:
----
pci0: <display, VGA> at device 2.0 (no driver attached)
pci0: <display> at device 2.1 (no driver attached)
----

pciconf shows:
----
none0@pci0:2:0: class=0x030000 card=0x01d81028 chip=0x27a28086 rev=0x03 hdr=0x00
    vendor   = 'Intel Corporation'
    class    = display
    subclass = VGA
none1@pci0:2:1: class=0x038000 card=0x01d81028 chip=0x27a68086 rev=0x03 hdr=0x00
    vendor   = 'Intel Corporation'
    class    = display
----

x.org wont start with known error message, i.e.
----
(EE) No devices detected.

Fatal server error:
no screens found
----

i can boot with vesa drivers but then widescreen resolutions added
with 915resolution dont work.

is this problem solved in current yet?

or does updating parts of the tree and applying patches solve the problem?

DRI is not very important right now (although it would be nice in
future ;) ), but i really need a proper resolution and the possibility
to watch movies :D

thanks for your help