Bug 60512
| Summary: | launching X freezes CURRENT | ||
|---|---|---|---|
| Product: | Base System | Reporter: | evenson <evenson> |
| Component: | misc | Assignee: | Eric Anholt <anholt> |
| Status: | Closed FIXED | ||
| Severity: | Affects Only Me | ||
| Priority: | Normal | ||
| Version: | Unspecified | ||
| Hardware: | Any | ||
| OS: | Any | ||
|
Description
evenson
2003-12-22 17:50:17 UTC
I have the same problem on a thinkpad A22m. Almost exact same symptoms. John I might have the same problem here with 5.2-RELEASE on an Thinkpad A20p
(2629-62G; ATI Rage Mobility 128, r128.ko) -- seemingly random but not
infrequent freezes when starting X with startx or shutting down the X
server, sometimes still in graphical mode, sometimes already in console.
Cheers,
Dan
--
Daniel Roethlisberger <daniel@roe.ch>
OpenPGP key id 0x804A06B1 (1024/4096 DSA/ElGamal)
144D 6A5E 0C88 E5D7 0775 FCFD 3974 0E98 804A 06B1
!->
Starting X always hangs 5.2-RELEASE Thinkpad X20 here too. The video card is ATI Rage Mobility P/M. Teemu -- tkoponen@iki.fi # PGP public key: http://www.iki.fi/tkoponen/pgp.asc XFree86 freezes here too if I enable dri, but works fine without dri... Preloaded elf module "/boot/kernel/agp.ko" at 0xc082321c. agp0: <NVIDIA nForce2 AGP Controller> mem 0xe8000000-0xebffffff at device 0.0 on pci0 drm0: <ATI Radeon QY RV100 7000/VE> port 0xa000-0xa0ff mem 0xed000000-0xed00ffff,0xe0000000-0xe7ffffff irq 11 at device 0.0 on pci2 info: [drm] AGP at 0xe8000000 64MB info: [drm] Initialized radeon 1.10.0 20020828 on minor 0 System is an NF7-M motherboard with NForce2 chipset. It loops while doing an ioctl to /dev/dri/card0 Here is a small part of ktrace of XFree86: 49609 XFree86 CALL ioctl(0x7,0x20006444 ,0) 49609 XFree86 RET ioctl -1 errno 16 Device busy 49609 XFree86 CALL ioctl(0x7,0x20006444 ,0) 49609 XFree86 RET ioctl -1 errno 16 Device busy 49609 XFree86 CALL ioctl(0x7,0x20006444 ,0) 49609 XFree86 RET ioctl -1 errno 16 Device busy 49609 XFree86 CALL ioctl(0x7,0x20006444 ,0) 49609 XFree86 RET ioctl -1 errno 16 Device busy *continues for ever* sys runs at nearly 100% after starting XFree86 (with dri), the console dies and does never come up again. The kernel is up and userland works, so I could ssh in and do ktrace, etc, and shutdown it 'cleanly'.. Sorry, I don't have a null-modem cable yet.. Jan-Espen Pettersen Same on my box. Its an old P3 with an old erazor graphics card. FreeBSd 4.8 + latest XFree4 (till december) worked flawless. After deleting it completely, I installed FreeBSD 5.2.1 with XFree86-4 from the ports cvs (beginning of february). xf86cfg freezes the machine on exit. With the configuration file from an old 4.8 backup, the command XFree86 freezes immediately. Freezes means no reaction anymore. Even pings were not responded. What helped was to remove the lines Load "glx" Load "dri" Load "record" Note, that each of them will cause the problem. Without this three even kde is running. Heiner Heiner <h.eichmann@gmx.de> writes: > Same on my box. Its an old P3 with an old erazor graphics card. FreeBSd 4.8 + > latest XFree4 (till december) worked flawless. After deleting it completely, > I installed FreeBSD 5.2.1 with XFree86-4 from the ports cvs (beginning of > february). xf86cfg freezes the machine on exit. With the configuration file > from an old 4.8 backup, the command XFree86 freezes immediately. Freezes > means no reaction anymore. Even pings were not responded. > > What helped was to remove the lines > > Load "glx" > Load "dri" > Load "record" > > Note, that each of them will cause the problem. Without this three even kde is > running. Thanks for the advice, but my situation seems to be even worse: removing the XFree86 module loading doesn't seem to affect my box. It will still freeze on startup most times, only sometimes it somehow "makes it through" the initialization phase, kicking itself all the way to actually working. Do you have any idea how to get some additional information out of the frozen box? I wish I could see a backtrace or something to have an avenue for investigation, but no such luck. -- Mark Evenson <evenson@panix.com> "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now." After installing some new components (mainly kde stuff) the situation is worse here as well. startx starts KDE but the only way to terminate it is to go to the controlling terminal and press ctrl-C. The normal kde exits freezes BSD completely. Even disabeling all drivers and upgrading to the latest Xfree-Server port version does not help. As "freeze" also kills the disk cache, all log file entries (if there are any) will not make it to the disk. Disabeling the soft updates might help here. I will try if I find some time. Heiner On my FreeBSD (5.2.x) there is a boot promt at the beginning. If I choose 2 (no acpi), all X-windows problems are gone! I can now start and finish KDE without a single freeze (tested 6 times with 2 reboots in between). Heiner Hello, seems as I have the same problem. If I'm trying to start X, the system freezes. Even pings are not responded. Not always but every fourth time or so. I tried to remove those modules from XF86Config, which are named in a former posting(glx, dri, record), but it didn't help. So I disabled ACPI and it worked. No freezes anymore. Only wanted to mention this... with best regards, --- benny Not compiling SMP support into the kernel works around the problem for me without having to disable ACPI. -Dan Responsible Changed From-To: freebsd-bugs->anholt Over to dri Maintainer. State Changed From-To: open->closed This PR is uselessly filled with different reports. Original reporter's issue can't be with the DRI, because his card doesn't support the DRI (as of the software in ports at the time). Someone reports what could be a DRM issue, but information only shows that the card has hung and is being reset. Another reports that any of 3 unrelated XFree86 modules causes the machine to hard-lock. Later he reports a hang (probably a panic) on exiting KDE unless ACPI is disabled, and another says disabling SMP does the same. Any of these as separate reports might have been interesting, but it's too hard to follow now, and little of it seems to relate to the DRM, anyway. Close it. Those that are still having problems should file separate reports for separate issues. |
