Bug #2280
closed
starting X reboots the machine
100%
Description
I built kernel and world from sources downloaded this morning with Git. I rebooted and, while attempting to start kdm, the box said "F1: DragonFly" and rebooted. I rebooted the previous kernel and X came up fine. I also tried startx on the new kernel without kdm; it still rebooted.
Updated by phma over 12 years ago
- git show
commit 4f45907333eb0ca7cda1d2633ecdf1010f359919
Author: Sepherosa Ziehau <sephe@dragonflybsd.org>
Date: Tue Jan 17 16:52:36 2012 +0800
msix/pci: Enable MSI-X by defaultdiff --git a/sys/bus/pci/pci.c b/sys/bus/pci/pci.c
index d93b6aa..063f169 100644
--- a/sys/bus/pci/pci.c
+++ b/sys/bus/pci/pci.c@ -296,12 +296,10 @ TUNABLE_INT("hw.pci.enable_msi", &pci_do_msi);
SYSCTL_INT(_hw_pci, OID_AUTO, enable_msi, CTLFLAG_RW, &pci_do_msi, 1,
"Enable support for MSI interrupts");
static int pci_do_msix = 0;#if 0
+static int pci_do_msix = 1;
TUNABLE_INT("hw.pci.enable_msix", &pci_do_msix);
SYSCTL_INT(_hw_pci, OID_AUTO, enable_msix, CTLFLAG_RW, &pci_do_msix, 1,
"Enable support for MSI-X interrupts");
-#endif
static int pci_honor_msi_blacklist = 1;
TUNABLE_INT("hw.pci.honor_msi_blacklist", &pci_honor_msi_blacklist);
Updated by phma about 12 years ago
- Priority changed from Normal to High
I am now running v3.1.0.52.g42a0e-DEVELOPMENT. Romick advised me to turn off DRI in xorg.conf if I'm running the Intel driver. I did, and I can log into X, but Kwin says that desktop effects are too slow and turns them off. I turned DRI back on and restarted X. The computer rebooted, then hung when it got to the X server. I booted in single-user mode, couldn't figure out how to edit without the terminal codes working, mounted -a, started sshd, and shelled in from my other box and turned DRI off again.
I am upping the priority because the bug is in both 2.13 and 3.1, so it's probably in 3.0 as well. It appeared between v2.11.0.681.g0eed2f-DEVELOPMENT and v2.13.0.957.g4f459-DEVELOPMENT
Updated by c.turner1 about 12 years ago
On 01/26/12 23:42, Pierre Abbat via Redmine wrote:
I am now running v3.1.0.52.g42a0e-DEVELOPMENT. Romick advised me to turn off DRI in xorg.conf
For refs - am also having the same issue with intel driver on an asus eee901
with day-before-3.0-branch 2.13 - disabling DRI also fixed.
Previously worked OK IIRC but this was a 2.10 install / old pkgsrc
FWIW.
This bug should probably be renamed to 'xorg+intel+dri' crashes the machine
The intel driver directly deals with agp(4) from what I can tell,
haven't gotten further than that (and likely won't any time soon)
Will see if I can generate a dump over the next few days/weeks,
though I think this might not generate one
Updated by masterblaster about 12 years ago
I can reproduce the problem too on a i386 machine (Pentium M).
On a x86_64 (Intel D510), same Xorg driver (i915), same dfly git version, no problem.
From i386 dmesg, v2.13.0.990.g98bec-DEVELOPMENT:
info: [drm] AGP at 0xe8000000 128MB
info: [drm] Initialized i915 1.6.0 20080730
panic: lockmgr: LK_RELEASE: no lock held
Trace beginning at frame 0xcd337ab8
panic(ffffffff,c04d7c40,c0442698,cd337ae8,ff800000) at panic+0x107 0xc01cb7fc
panic(c0442698,0,1,0,e87ec000) at panic+0x107 0xc01cb7fc
lockmgr(cd300e94,6,c1eaae20,cd337b38,c0354078) at lockmgr+0x492 0xc01bddd1
drm_ioctl(cd337b5c,c0477e08,ca6535f0,80186443,cd337c0c) at drm_ioctl+0x356 0xcd34c7ee
dev_dioctl(ca6535f0,80186443,cd337c0c,43,c9acc588) at dev_dioctl+0x40 0xc01af508
devfs_fo_ioctl(c1efb968,80186443,cd337c0c,c9acc588,cd337cf0) at devfs_fo_ioctl+0x119 0xc0302d00
fo_ioctl(c9acc588,cd337cf0,18,1,cd337c54) at fo_ioctl+0x3c 0xc01f5d1d
mapped_ioctl(a,80186443,bfbff594,0,cd337cf0) at mapped_ioctl+0x4c9 0xc01f61ff
sys_ioctl(cd337cf0,cd337d00,c,cd062858,0) at sys_ioctl+0x2e 0xc01f62ae
syscall2(cd337d40) at syscall2+0x232 0xc03e0520
Xint0x80_syscall() at Xint0x80_syscall+0x36 0xc03b2eb6
Debugger("panic")
Get core from https://84.73.12.43/crash/core.0.txz
Updated by dillon about 12 years ago
- Status changed from New to Closed
- % Done changed from 0 to 100
I tracked down the ioctl from the dump and there was an obviously missing DRM_LOCK() in an UNLOCK/LOCK sequence. The bug fix has been committed to master and MFC'd to the release. 7ca5621f78805fd7285a61178d2b25a768715c2f (master) and b60e3fd0b0654b7103d8a27eabb832ba9cec8edc (release).
-Matt