Created attachment 14165 [details] xorg.conf X fails to start with any version (through Jan 25ths git) of the intel driver. It starts fine with version 1.7.4 of the intel driver. 00:02.0 VGA compatible controller: Intel Corporation E7221 Integrated Graphics Controller (rev 04) (prog-if 00 [VGA controller]) Subsystem: Dell Unknown device 0180 Flags: bus master, fast devsel, latency 0, IRQ 11 Memory at dff80000 (32-bit, non-prefetchable) [size=512K] I/O ports at ecd8 [size=8] Memory at f0000000 (32-bit, prefetchable) [size=128M] Memory at dff40000 (32-bit, non-prefetchable) [size=256K] Capabilities: [d0] Power Management version 2
Created attachment 14166 [details] Xorg.0.log-1.7.4
Created attachment 14167 [details] Xorg.0.log-2.2.1_pre20080125
You need the agpgart kernel module. The driver complains in the log that it can't find /dev/agpgart.
The agpgart issue is irrelevant. Both attempts are with the same kernel and loaded modules. In fact, I don't even think there is AGP available on this system. The graphics card is built-in and on the PCI bus.
intel video driver depends on kernel agp module to be exist, otherwise X can't work as it can't allocate any memory. Could you check with dmesg to see if intel_agp loaded? any E7221 message?
I actually did load intel_agp (along with all the other agp modoles just to be sure it wasn't another chipset). There seems to be no AGP on this system: ~ # lsmod | grep intel intel_agp 15844 0 agpgart 18574 11 drm,via_agp,sworks_agp,sis_agp,nvidia_agp,efficeon_agp,ati_agp,amd_k7_agp,amd64_agp,ali_agp,intel_agp ~ # lsmod | grep intel_agp intel_agp 15844 0 agpgart 18574 11 drm,via_agp,sworks_agp,sis_agp,nvidia_agp,efficeon_agp,ati_agp,amd_k7_agp,amd64_agp,ali_agp,intel_agp ~ # ls /dev/agp* ls: cannot access /dev/agp*: No such file or directory ~ # dmesg | grep agp Linux agpgart interface v0.102 ~ # dmesg | grep E7 <nothing> And to prove such messages didn't get pushed out of the buffer... ~ # dmesg | head Linux version 2.6.23-hardened-r6 (root@upe) (gcc version 3.4.6 (Gentoo Hardened 3.4.6-r2, ssp-3.4.6-1.0, pie-8.7.10)) #1 SMP Tue Feb 5 19:21:08 PST 2008 BIOS-provided physical RAM map:
I believe the system is a Dell 420SC, but I'm not 100% sure of that since I am remote. Here are the specs on the 420SC http://support.dell.com/support/edocs/systems/pe420sc/ http://www.dell.com/downloads/global/products/pedge/en/sc420_specs.pdf
Please provide your dmesg log. thanks.
You'd better try 2.6.24 kernel which has recently added agp and drm support for E7221, that should fix your problem.
this should an easy one. ping confirm from bug reporter...
Can't yet confirm it... remote access from the machine. I should be able to confirm this some time next week.
as there is no patch needed from this bug, Jeremy, I'll mark this as fixed. please reopen when it bothers you...
Thanks, I'm sure this will fix the issue... just haven't had a chance to verify.
Oh, FTR... 2.6.24 works great with the 2.3.0 driver on this box.
Well... not quite. Any thing that attempts to use GL crashes the server. The following message is spit out: Unrecognized deviceID 258a Backtrace: 0: X(xf86SigHandler+0x9a) [0x12dcefb1] Fatal server error: Caught signal 11. Server aborting --- This occurs with both the 2.2.1 and 2.3.0 drivers http://www.calel.org/pci-devices/xorg-device-list.html shows that 258A is the correct deviceID for the E7221, so I'm not sure what's going wrong. Xorg.log attached. This is using a 1.4 server.
Created attachment 16316 [details] Xorg.0.log 1.4.0.90 + intel 2.2.1
lspci -nv shows: 00:00.0 0600: 8086:2588 (rev 04) Subsystem: 1028:0180 Flags: bus master, fast devsel, latency 0 Capabilities: [e0] Vendor Specific Information <?> Kernel driver in use: agpgart-intel Kernel modules: intel-agp 00:02.0 0300: 8086:258a (rev 04) (prog-if 00 [VGA controller]) Subsystem: 1028:0180 Flags: bus master, fast devsel, latency 0, IRQ 16 Memory at dff80000 (32-bit, non-prefetchable) [size=512K] I/O ports at ecd8 [size=8] Memory at f0000000 (32-bit, prefetchable) [size=128M] Memory at dff40000 (32-bit, non-prefetchable) [size=256K] Capabilities: [d0] Power Management version 2
What's your mesa version? I think it might be just missing E7221 pci ids in mesa dri driver.
mesa is 7.0.3 Still, even if that is the case, the server should not be able to handle that gracefully and not crash ;)
The mesa issue is fixed in master.
I still contend that this is a bug that needs to be resolved: 1) I don't see the change in mesa_7_0_branch 2) The X server should not die just because the dri driver does not recognize the card
Possible to get gdb back trace of Xorg crash? Haihao, pls check and pick fix into mesa 7.0 branch.
fixed in commit 44f6a6f9c4195727e8819007ac4e3aeac898838a
Reopening to address the X server crash issue that still remains if the id is unknown. I'll get a backtrace when I have access to the box again (probably in a few days)
It turns out that the X server "crash" was actually grsecurity killing the server because of: grsec: signal 11 sent to /usr/bin/Xorg[X:13023] uid/euid:0/0 gid/egid:0/0, parent /usr/bin/xinit[xinit:13022] uid/euid:0/0 gid/egid:0/0 grsec: denied resource overstep by requesting 4096 for RLIMIT_CORE against limit 0 for /usr/bin/Xorg[X:13023] uid/euid:0/0 gid/egid:0/0, parent /usr/bin/xinit[xinit:13022] uid/euid:0/0 gid/egid:0/0 gdb is being annoying and not letting me attach to the process in order to get a usable backtrace to see where that's coming from, and I'm not sure why... really frustrating. --- As for the DRI situation... building mesa with that change, I still can't get DRI working on the E7221 using Mesa-7.0.3 + the PCI_CHIP_E7221_G patch. I'm seeing: II) intel(0): Kernel reported 238592 total, 20481 used (II) intel(0): I830CheckAvailableMemory: 872444 kB available drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 10, (OK) drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 10, (OK) drmOpenByBusid: Searching for BusID pci:0000:00:02.0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 10, (OK) drmOpenByBusid: drmOpenMinor returns 10 drmOpenByBusid: drmGetBusid reports pci:0000:00:02.0 (II) [drm] DRM interface version 1.0 (EE) [drm] Could not set DRM device bus ID. (EE) intel(0): [dri] DRIScreenInit failed. Disabling DRI. I will attach the full log file.
Created attachment 16436 [details] Xorg.0.log 1.4.0.90 + intel 2.3.0 + mesa-7.0.3 + E7221 patch
What is your DRM version? Could you try with DRM master?
I'm using what is in the 2.6.24 kernel. I'll pull in master and give it a try next time I have access (tomorrow probably)
I haven't verified DRI locally, but remotely I see succeess in the server log after updating libdrm to master: drmOpenByBusid: drmOpenMinor returns 10 drmOpenByBusid: drmGetBusid reports pci:0000:00:02.0 (II) [drm] DRM interface version 1.3 (II) [drm] DRM open master succeeded. I'll verify it locally later today and reopen if there are any further issues. The server being killed by grsec is a separate issue, and I'll open a new bug if I find the source of the problem
Jeremy, does 3D work on your E7221 now? We have a new bug #16837 on E7221, I'd like to ask if it works for you, as we don't have e7221 hardware.
After going up to kernel 2.6.24 and dri head, E7221 was working fine. I'll take a look at that bug when I get access to this hardware again.
*** Bug 16837 has been marked as a duplicate of this bug. ***
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.