On May 09 20:39:34, Owain Ainsworth wrote:
> On Sun, May 09, 2010 at 09:21:05PM +0200, Jan Stary wrote:
> > On May 09 19:24:46, Owain Ainsworth wrote:
> > > On Sun, May 09, 2010 at 08:07:13PM +0200, Jan Stary wrote:
> > > > On May 09 15:14:01, Owain Ainsworth wrote:
> > > > > On Sun, May 09, 2010 at 02:54:55PM +0100, Owain Ainsworth wrote:
> > > > > > > 
> > > > > > > What can I do do test / debug the intagp support (so that I have 
> > > > > > > agp,
> > > > > > > so that Xorg has /dev/agp0, so that it can use the intel driver)
> > > > > > > on my hardware?
> > > > > > 
> > > > > > intagp does not currently support the pineview chipset.
> > > > > > 
> > > > > > I will look at it in a few days. Busy right now.
> > > > > 
> > > > > Scratch that, i found time.
> > > > >
> > > > > Now this very much depends on how good the modesetting support in the
> > > > > intel driver is for pineview, i sincerely recommend you test with GEM
> > > > > and the new driver + this diff. Unfortunately newer intel drivers
> > > > > are kernel modesetting only, and thus no bugfixes will be forthcoming
> > > > > from upstream if the modesetting isn't right. I won't be able to fix
> > > > > any problems in that light without hardware.
> > > > > 
> > > > > However, this is idle speculation for now, please test this diff:
> > > > 
> > > > With the diff below and a kernel configuration of
> > > > 
> > > >         include "arch/i386/conf/GENERIC.MP"
> > > >         option INTELDRM_GEM
> > > > 
> > > > the booting kernel hangs with
> > > > 
> > > >         intagp0 at vga1: unknown initialization
> > > >         inteldrm0 at vga1: apic 8 int 16 (irq 11)
> > > >         drm0 at inteldrm0: couldn't find agp
> > > >         uvm_fault(0xd092b940, 0x0, 0, 3) -> e
> > > >         kernel: page fault trap, code = 0
> > > > 
> > > > Compiling the same patched kernel with the standard GENEREC.MP
> > > > config boots fine (see full dmesg below) with
> > > > 
> > > > vga1 at pci0 dev 2 function 0 "Intel Pineview Integrated Graphics 
> > > > Controller" rev 0x02
> > > > wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
> > > > wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
> > > > intagp0 at vga1: unknown initialisation
> > > > inteldrm0 at vga1: apic 8 int 16 (irq 11)
> > > > drm0 at inteldrm0: couldn't find agp
> > > > 
> > > > and continues without hanging.
> > > > 
> > > > However, without agp, the original problem (X not running
> > > > with the autodetected intel driver) is still there, obviously.
> > > > 
> > > > Thanks anyway. Is there anythyng else I should test?
> > > > The kernel trap continues all the way up (down) to ddb,
> > > > but I don't have a serial port on that machine. Is there another
> > > > way to capture the panic, trace, etc?
> > > 
> > > *sigh*, of course I forgot a bloody chunk.
> > > try this one:
> > 
> > This works: with an INTELDRM_GEM kernel, as patched below,
> > the agp and drm are detected (see full dmesg below) as
> > 
> > vga1 at pci0 dev 2 function 0 "Intel Pineview Integrated Graphics 
> > Controller" rev 0x02
> > wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
> > wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
> > intagp0 at vga1
> > agp0 at intagp0: aperture at 0xe0000000, size 0x10000000
> > inteldrm0 at vga1: apic 8 int 16 (irq 11)
> > drm0 at inteldrm0
> 
> Excellent, i will commit that diff. Thank you for testing.
> 

One more detail: when I return from X to the concole,
I notice the following message appeared in dmesg:

error: [drm:pid30347:i915_write_fence_reg] *ERROR* object 0xab0000 not 1M or 
size (0x100000) aligned

When I run X again and later exit it and return to the console again,
the message does _not_ repeat (so I don't know who pid 30347 was).

> > and I can run Xorg without a config file (see Xorg.0.log below).
> > However, I can't switch resolutions using ctrl-alt-{+|-}
> > - is this expected?
> 
> That has not worked for a rather long time on anything that supports
> RandR 1.2.

Do you mean "anything that supports RandR 1.2 ONLY"
(as opposed to supporting the newer 1.3 version),
or "anything that supports RandR 1.2"
(as opposed to only supporting the older 1.1 version)?
Does that mean "supporting 1.2" breaks something?

Reply via email to