Hi list,

I'm a having few issues with the new intel(4) driver in X on -CURRENT
using the snapshot from two days ago. 

The system is an IBM Netvista 8310-XXS and uses an integrated Intel
82845G. The dmesg is below. The hardware itself is fine, and it
previously ran 4.4-stable perfectly, albeit on -stable it used the now
removed/renamed i810(4) driver.

Yes, I've got the aperture sysctl set for running X.
	$ sysctl machdep.allowaperture
	machdep.allowaperture=2

The BIOS settings for the integrated video are:
	Primary Video: Integrated
	Video RAM: 8192KB
	AGP Aperture: 32MB

Most of the time, when starting up X with plain vanilla `startx` and no
xorg.conf file, X fails to start. On two rare occasions, X somewhat
started but died shortly afterwards with a long list of errors like:

	(EE) intel(0): underun on pipe A!

The bulk of the time, X never starts, and the errors are different.
I've included three Xorg.0.log files below, each done with different
AGP Aperture settings. The last Xorg.0.log is the partial startup (with
the above error), and but the first two seem to be a bit more telling.
I *think* the problem is somehow related to AGP Aperture, so I've tried
all of the available values in the BIOS (32MB, 60MB, 128MB, 256MB) in
hope of seeing different behavior. There are some differences in the
logs below.

This system used to work fine with X auto-configuration on 4.4.-stable
using the old i810(4) driver and without an xorg.conf. Tonight I'll run
some more tests with the new intel(4) driver an a simple xorg.conf to
shut off features.

Though the problem exists in the 2009.02.18 i386 snapshot, last night I
built -CURRENT from source, and the problem still exists.

I don't know much about X driver internals, but on the majority of
failures to start, it seems the new intel(4) driver is failing to map
memory properly.

If you've got any ideas, or if there is something specific that you
want to see tested, please let me know.

Unfortunately, when the dmesg and ...
[ message continues ]

On i8xx chipsets that are experiencing this kind of problems,
switching back to the XAA acceleration methode generally works.

Add

  Option "AccelMethod" "XAA"

to the Device section of your xorg.conf file
-- 
Matthieu Herrb

[ message continues ]

On Sun, 22 Feb 2009 09:11:28 +0100 Matthieu Herrb <mherrb@gmail.com>


Thanks Mathieu!

This option does help somewhat with the 82845G chipset I have, but it's
not a correct answer. 

With this option enabled, X will start after a cold boot and run fairly
well, but then the trouble becomes ending the X session. When you exit
X, the display is often left in a weird state with blurred, distorted
or displaced text as if the display never quite made it back in to text
mode properly.

On occasion, X will exit properly, but more often than not it leaves
the display in some weird state.

With the "AccelMethod" option you mentioned, a cold boot does allow me
to get X running on the first try, but exiting X, or restarting X just
doesn't work properly.

Shutting off the acceleration entirely with the "Accel" option has
basically the same effect as designating  the "AccelMethod"

	Option "Accel" "false"

Again, shutting off acceleration completely allows you to get X running
after a cold boot, but exiting X and/or restarting X typically results
in either a screwed up text mode, or a failed/incomplete start of X.

Is there anything else I could do to help fix this instability bug?

-- 
J.C. Roberts

[ message continues ]

Fill a bug to bugs.freedesktop.org (product Xorg) with as many details
as posslbe, and pray that the intel guys eventually take support for
their older chips seriously.

And for now switch to the vesa driver if you need a working X in this machine.

-- 
Matthieu Herrb

[ message continues ]

On Mon, 23 Feb 2009 08:35:58 +0100 Matthieu Herrb <mherrb@gmail.com>

As long as I don't stop and restart X, or switch virtual terminals, your
suggestion of adding:

	Option "AccelMethod" "XAA"

to the DEVICE section works fairly well. None the less, this really
needs to get fixed.

I searched the bug database on freedesktop.org and got countless hits.
To *me* it seems this is actually one big bug with a lot of possible
manifestations (descriptions). I'm working on getting a well written
and more importantly, complete, bug report done.

On release we can expect a lot of i810(4)->intel(4) messages on misc,
as well as similar bug reports on intel(4).

-- 
J.C. Roberts

[ message continues ]

You are not the one paying the fixers unfortunately.  The only influence
you have is what Matthieu suggested.


[ message continues ]

On Mon, 23 Feb 2009 08:27:08 -0600 Marco Peereboom <slash@peereboom.us>

Thanks Marco. If I'm reading Mathieu and you correctly, I have to take
this upstream to get it fixed, and of course, this means writing a
*VERY* long and detailed bug report to make things as easy as possible
for those who could/might fix it.

I've tried searching for and reading existing bug reports on the 
intel(4) driver, and specifically the 845G chipset, but there are
*TONS* of them. A lot of the existing reports are poorly written
but since the buggy behavior is inconsistent, many of the existing bug
reports are probably duplicates, well, at least in some sense.

I just singed up for freedesktop.org this morning, and I'm collecting
the needed Xorg.0.log's with full debug info, descriptions and whatnot.
It's going to take quite a while experiment with it and write up all the
buggy behavior variations. If I do an absolutely stellar job on the bug
report, they might take the time to look at it.

After watching the old i810(4) driver work fine for me, and seeing
all the bug reports on the new intel(4) driver, I've got this bad
feeling that nobody cared to test it on the older chipsets... i.e. they
are not getting paid to care about "legacy" support.

Would this be a correct assessment?

-- 
J.C. Roberts

[ message continues ]

Yes.

A man cannot have two masters.

In this case, some people are collecting pay cheques from Intel, so no
wonder there is a problem.

A substantial problem.

[ message continues ]

Please add me (zerooa@googlemail.com) to the CC. I try and keep an eye

From discussing with the intel guys, their actually split. Probably more
towards "fuck legacy" though.

-0-
-- 
Cigarette, n.:
	A fire at one end, a fool at the other, and a bit of tobacco in
	between.

[ message continues ]

On Tue, 24 Feb 2009 23:38:43 +0000 Owain Ainsworth

Will do. 

I'm still working with your intel(4) 2.6.1 "patch" from tech@, while
trying to learn about remote debugging X. It will take me a while to
test everything, document the bugs, and get familiar with the code.

-- 
J.C. Roberts

[ message continues ]

I just encountered what looks like the same issue. Worked with OpenBSD v4.4, has
been working since OpenBSD v3.2. I will try some of the suggestions.

I also noticed that the /dev/drm0 is being removed, and then complaining it's
not there any longer. Running MAKEDEV recreates /dev/drm0.

Attached is a dmesg and Xorg.0.log, any news or progress please let me know.

Regards

Nigel Taylor


dmesg and Xorg.0.log attached.


OpenBSD 4.5 (GENERIC) #1749: Sat Feb 28 14:51:18 MST 2009
    deraadt@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
cpu0: Intel(R) Pentium(R) 4 CPU 1.80GHz ("GenuineIntel" 686-class) 1.80 GHz
cpu0:
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM
real mem  = 259551232 (247MB)
avail mem = 242667520 (231MB)
mainbus0 at root
bios0 at mainbus0: AT/286+ BIOS, date 05/28/02, BIOS32 rev. 0 @ 0xeba30, SMBIOS
rev. 2.3 @ 0xfd486 (46 entries)
bios0: vendor Compaq version "686O2 v1.08" date 05/28/2002
bios0: Compaq Evo D510 SFF
acpi0 at bios0: rev 0
acpi0: tables DSDT FACP SSDT SSDT SSDT SSDT SSDT SSDT SSDT APIC SSDT SSDT SSDT
SSDT SSDT SSDT SSDT
acpi0: wakeup devices PCI0(S4) HUB_(S4) COM1(S4) COM2(S4) USB1(S1) USB2(S1)
USB3(S1) EUSB(S1) PBTN(S4)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee00000: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: apic clock running at 99MHz
ioapic0 at mainbus0: apid 8 pa 0xfec00000, version 20, 24 pins
ioapic0: misconfigured as apic 0, remapped to apid 8
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 5 (HUB_)
acpicpu0 at acpi0
acpibtn0 at acpi0: PBTN
bios0: ROM list: 0xc0000/0xac00! 0xcac00/0x1800 0xcc400/0x1800 0xe1c00/0x9000!
pci0 at mainbus0 bus 0: configuration mode 1 (bios)
pchb0 at pci0 dev 0 function 0 "Intel 82845G Host" rev 0x01
vga1 at pci0 dev 2 function 0 "Intel 82845G Video" rev 0x01
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 ...
[ message continues ]