Re: diagnosing freezes (DRI?)
On Thu, 16 Apr 2009 22:18:36 +0300 Kostik Belousov kostik...@gmail.com wrote: On Thu, Apr 16, 2009 at 10:47:55AM -0700, Tim Kientzle wrote: Gary Jennejohn wrote: deeptec...@gmail.com wrote: This kernel output really looks bad: Wai tSiynngc i(nmga xd is6k0s ,s evcnoonddess) rfeomra isnyisntge.m. .pr0o cess `syncer' to stop...0 done I can't speak to the rest, but this is probably because you have SMP and don't have `options PRINTF_BUFR_SIZE=128' in your kernel config. Is there any reason this shouldn't be the default? This is becoming an increasingly common FAQ. The only reason I am aware of is that the buffer is allocated on the stack. 128 bytes is not so small for our kernel stacks. True, but it still seems like this could be put into GENERIC, commented out, with a good comment about stack size, so that users have a reasonable chance of finding out about it. --- Gary Jennejohn ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: diagnosing freezes (DRI?)
I can reliably (~40%) reproduce a freeze, which I think is related. Using the GENERIC debug kernel built from SVN HEAD: # cd /usr/obj/usr/src/sys/GENERIC/ # kgdb kernel.debug /var/crash/vmcore.0 GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i386-marcel-freebsd... Unread portion of the kernel message buffer: 118Apr 16 04:22:24 syslogd: exiting on signal 15 Waiting (max 60 seconds) for system process `vnlru' to stop...done Waiting (max 60 seconds) for system process `bufdaemon' to stop...done Wai tSiynngc i(nmga xd is6k0s ,s evcnoonddess) rfeomra isnyisntge.m. .pr0o cess `syncer' to stop...0 done All buffers synced. Copyright (c) 1992-2009 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 8.0-CURRENT #0 r191101: Wed Apr 15 17:29:58 UTC 2009 devhc@:/usr/obj/usr/src/sys/GENERIC WARNING: WITNESS option enabled, expect reduced performance. Timecounter i8254 frequency 1193182 Hz quality 0 CPU: Intel(R) Pentium(R) 4 CPU 2.80GHz (2798.67-MHz 686-class CPU) Origin = GenuineIntel Id = 0xf29 Stepping = 9 Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE Features2=0x4400CNXT-ID,xTPR Logical CPUs per core: 2 real memory = 536870912 (512 MB) avail memory = 506023936 (482 MB) ACPI APIC Table: A M I OEMAPIC FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP/HT): APIC ID: 1 ioapic0 Version 2.0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: A M I OEMXSDT on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of 0, a (3) failed acpi0: reservation of 10, 1fef (3) failed Timecounter ACPI-fast frequency 3579545 Hz quality 1000 acpi_timer0: 24-bit timer at 3.579545MHz port 0x808-0x80b on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 agp0: Intel 82865 host to AGP bridge on hostb0 pcib1: ACPI PCI-PCI bridge at device 1.0 on pci0 pci1: ACPI PCI bus on pcib1 vgapci0: VGA-compatible display port 0xd000-0xd0ff mem 0xd000-0xdfff,0xfbee-0xfbee irq 16 at device 0.0 on pci1 vgapci1: VGA-compatible display mem 0xe000-0xefff,0xfbef-0xfbef at device 0.1 on pci1 uhci0: Intel 82801EB (ICH5) USB controller USB-A port 0xc880-0xc89f irq 16 at device 29.0 on pci0 uhci0: [ITHREAD] uhci0: LegSup = 0x2030 usbus0: Intel 82801EB (ICH5) USB controller USB-A on uhci0 uhci1: Intel 82801EB (ICH5) USB controller USB-B port 0xcc00-0xcc1f irq 19 at device 29.1 on pci0 uhci1: [ITHREAD] uhci1: LegSup = 0x2030 usbus1: Intel 82801EB (ICH5) USB controller USB-B on uhci1 ehci0: Intel 82801EB/R (ICH5) USB 2.0 controller mem 0xfbdffc00-0xfbdf irq 23 at device 29.7 on pci0 ehci0: [ITHREAD] usbus2: EHCI version 1.0 usbus2: Intel 82801EB/R (ICH5) USB 2.0 controller on ehci0 pcib2: ACPI PCI-PCI bridge at device 30.0 on pci0 pci2: ACPI PCI bus on pcib2 skc0: 3Com 3C940 Gigabit Ethernet port 0xe800-0xe8ff mem 0xfbffc000-0xfbff irq 22 at device 5.0 on pci2 skc0: 3Com Gigabit LOM (3C940) rev. (0x1) sk0: Marvell Semiconductor, Inc. Yukon on skc0 sk0: Ethernet address: 00:0e:a6:35:15:91 miibus0: MII bus on sk0 e1000phy0: Marvell 88E1011 Gigabit PHY PHY 0 on miibus0 e1000phy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX-FDX, auto skc0: [ITHREAD] pcm0: Creative CT5880-E port 0xec00-0xec3f irq 20 at device 12.0 on pci2 pcm0: eMicro EM28028 AC97 Codec pcm0: [ITHREAD] pcm0: Playback: DAC1,DAC2 / Record: ADC isab0: PCI-ISA bridge at device 31.0 on pci0 isa0: ISA bus on isab0 atapci0: Intel ICH5 UDMA100 controller port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xfc00-0xfc0f at device 31.1 on pci0 ata0: ATA channel 0 on atapci0 ata0: [ITHREAD] ata1: ATA channel 1 on atapci0 ata1: [ITHREAD] pci0: serial bus, SMBus at device 31.3 (no driver attached) acpi_button0: Power Button on acpi0 atrtc0: AT realtime clock port 0x70-0x71 irq 8 on acpi0 atkbdc0: Keyboard controller (i8042) port 0x60,0x64 irq 1 on acpi0 atkbd0: AT Keyboard irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] uart0: 16550 or compatible port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 uart0: [FILTER] uart1: 16550 or compatible port 0x2f8-0x2ff irq 3 on acpi0 uart1: [FILTER] ppc0: Parallel port port 0x378-0x37f,0x778-0x77b irq 7 drq 3 on acpi0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/9 bytes threshold ppc0: [ITHREAD] ppbus0: Parallel port bus on ppc0 plip0: PLIP network
Re: diagnosing freezes (DRI?)
On Thu, 16 Apr 2009 17:04:55 +0200 deeptec...@gmail.com wrote: [snip a whole bunch of stuff] This kernel output really looks bad: Wai tSiynngc i(nmga xd is6k0s ,s evcnoonddess) rfeomra isnyisntge.m. .pr0o cess `syncer' to stop...0 done I can't speak to the rest, but this is probably because you have SMP and don't have `options PRINTF_BUFR_SIZE=128' in your kernel config. --- Gary Jennejohn ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: diagnosing freezes (DRI?)
Gary Jennejohn wrote: deeptec...@gmail.com wrote: This kernel output really looks bad: Wai tSiynngc i(nmga xd is6k0s ,s evcnoonddess) rfeomra isnyisntge.m. .pr0o cess `syncer' to stop...0 done I can't speak to the rest, but this is probably because you have SMP and don't have `options PRINTF_BUFR_SIZE=128' in your kernel config. Is there any reason this shouldn't be the default? This is becoming an increasingly common FAQ. Tim ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: diagnosing freezes (DRI?)
On Thu, Apr 16, 2009 at 10:47:55AM -0700, Tim Kientzle wrote: Gary Jennejohn wrote: deeptec...@gmail.com wrote: This kernel output really looks bad: Wai tSiynngc i(nmga xd is6k0s ,s evcnoonddess) rfeomra isnyisntge.m. .pr0o cess `syncer' to stop...0 done I can't speak to the rest, but this is probably because you have SMP and don't have `options PRINTF_BUFR_SIZE=128' in your kernel config. Is there any reason this shouldn't be the default? This is becoming an increasingly common FAQ. The only reason I am aware of is that the buffer is allocated on the stack. 128 bytes is not so small for our kernel stacks. pgpcX6fGA5N90.pgp Description: PGP signature
Re: diagnosing freezes (DRI?)
Kostik Belousov wrote: On Thu, Apr 16, 2009 at 10:47:55AM -0700, Tim Kientzle wrote: Gary Jennejohn wrote: deeptec...@gmail.com wrote: This kernel output really looks bad: Wai tSiynngc i(nmga xd is6k0s ,s evcnoonddess) rfeomra isnyisntge.m. .pr0o cess `syncer' to stop...0 done I can't speak to the rest, but this is probably because you have SMP and don't have `options PRINTF_BUFR_SIZE=128' in your kernel config. Is there any reason this shouldn't be the default? The only reason I am aware of is that the buffer is allocated on the stack. 128 bytes is not so small for our kernel stacks. How about 32? Anything larger than 1 would make it much easier to read these messages. Tim ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: diagnosing freezes (DRI?)
Hello. Just to let everyone know, I'm now coming to the conclusion that I may be suffering from hardware/thermal problems and that the DRI driver wasn't actually at fault (but highlighted the problem by pushing the hardware... harder). Thanks for the assistance, though. xw ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: diagnosing freezes (DRI?)
On Friday 10 April 2009 20:31:33 Robert Noland wrote:
On Fri, 2009-04-10 at 18:59 +0100, xorquew...@googlemail.com wrote:
The system doesn't seem to have frozen since DRI/DRM was disabled.
I did have one crash/reboot whilst building a large number of
packages with tinderbox. I've currently got both tinderbox and a
make -j 16 buildworld going on a loop in the hope that I can trigger
it again.
Being the idiot I am, I had encrypted swap enabled and so savecore
didn't save anything. Won't make that mistake twice.
I'm currently using a world compiled WITH_DEBUG but is there
anything else I can do?
If it is locking the whole system, then a core is really our best
shot. If you can extract anything useful from xorg.log or setting
hw.dri.0.debug that also might be of use.
I'm running on 2 cores, but it is possible that some locking issue
exists. All of the driver specific ioctls are run under a lock
though.
I have the same problem with a Radeon Mobility 9700 (r300) on 7-STABLE.
The entire system freezes, but it happens very rarely. I took a quick
look at the drm code for locking issues and found one thing that seems
suspicious. Patch attached. I'm not familiar with the code, so I don't
know if it's correct or even related this problem.
--- sys/dev/drm/drm_bufs.c.orig 2009-04-11 15:10:56.0 +0200
+++ sys/dev/drm/drm_bufs.c 2009-04-11 15:11:33.0 +0200
@@ -173,7 +173,6 @@
/* Prevent a 2nd X Server from creating a 2nd lock */
DRM_LOCK();
if (dev-lock.hw_lock != NULL) {
- DRM_UNLOCK();
free(map-handle, DRM_MEM_MAPS);
free(map, DRM_MEM_MAPS);
return EBUSY;
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: diagnosing freezes (DRI?)
On 2009-04-11 02:30:40, Paul B. Mahol wrote: If it locks under X11 then use debug.debugger_on_panic=0 sysctl. Not doing this will increase drasticaly chances of locking whole system and not providing any debug data. I don't seem to have that sysctl. You sure that's the correct name? xw ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: diagnosing freezes (DRI?)
The machine ran for hours, apparently. I ended up going to bed and leaving it running. Woke up to find it on display sleep, frozen. It didn't panic, apparently. I've included Xorg.0.log and the last few lines of /var/log/messages but I don't believe they show anything very interesting. I should point out that this card is the dual-DVI version. I'm not sure if that's relevant (I think it's just less common). I'm only using one screen, currently. /var/log/Xorg.0.log: X.Org X Server 1.6.0 Release Date: 2009-2-25 X Protocol Version 11, Revision 0 Build Operating System: FreeBSD 7.2-PRERELEASE amd64 Current Operating System: FreeBSD viper.internal.network 7.2-PRERELEASE FreeBSD 7.2-PRERELEASE #0: Fri Apr 10 00:09:48 BST 2009 r...@viper.internal.network:/usr/obj/usr/src/sys/GENERIC amd64 Build Date: 11 April 2009 04:34:30AM Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: /var/log/Xorg.0.log, Time: Sat Apr 11 06:16:46 2009 (==) Using config file: /etc/X11/xorg.conf (==) ServerLayout X.org Configured (**) |--Screen Screen0 (0) (**) | |--Monitor Monitor0 (**) | |--Device Card0 (**) |--Input Device Mouse0 (**) |--Input Device Keyboard0 (==) Not automatically adding devices (==) Not automatically enabling devices (WW) The directory /usr/local/lib/X11/fonts/TTF/ does not exist. Entry deleted from font path. (WW) The directory /usr/local/lib/X11/fonts/OTF does not exist. Entry deleted from font path. (WW) The directory /usr/local/lib/X11/fonts/Type1/ does not exist. Entry deleted from font path. (WW) The directory /usr/local/lib/X11/fonts/TTF/ does not exist. Entry deleted from font path. (WW) The directory /usr/local/lib/X11/fonts/OTF does not exist. Entry deleted from font path. (WW) The directory /usr/local/lib/X11/fonts/Type1/ does not exist. Entry deleted from font path. (**) FontPath set to: /usr/local/lib/X11/fonts/misc/, /usr/local/lib/X11/fonts/100dpi/, /usr/local/lib/X11/fonts/75dpi/, /usr/local/lib/X11/fonts/misc/, /usr/local/lib/X11/fonts/100dpi/, /usr/local/lib/X11/fonts/75dpi/, built-ins (**) ModulePath set to /usr/local/lib/xorg/modules (II) Loader magic: 0xd20 (II) Module ABI versions: X.Org ANSI C Emulation: 0.4 X.Org Video Driver: 5.0 X.Org XInput driver : 4.0 X.Org Server Extension : 2.0 (II) Loader running on freebsd (--) Using syscons driver with X support (version 134217730.0) (--) using VT number 9 (--) PCI:*(0...@6:0:0) ATI Technologies Inc RV570 [Radeon X1950 Pro] rev 154, Mem @ 0xd000/268435456, 0xfbee/65536, I/O @ 0xe000/256, BIOS @ 0x/65536 (--) PCI: (0...@6:0:1) ATI Technologies Inc RV570 [Radeon X1950 Pro] (secondary) rev 154, Mem @ 0xfbef/65536 (II) System resource ranges: [0] -1 0 0x000f - 0x000f (0x1) MX[B] [1] -1 0 0x000c - 0x000e (0x3) MX[B] [2] -1 0 0x - 0x0009 (0xa) MX[B] [3] -1 0 0x - 0x (0x1) IX[B] [4] -1 0 0x - 0x00ff (0x100) IX[B] (II) extmod will be loaded. This was enabled by default and also specified in the config file. (II) dbe will be loaded. This was enabled by default and also specified in the config file. (II) glx will be loaded. This was enabled by default and also specified in the config file. (II) record will be loaded. This was enabled by default and also specified in the config file. (II) dri will be loaded. This was enabled by default and also specified in the config file. (II) dri2 will be loaded. This was enabled by default and also specified in the config file. (II) LoadModule: extmod (II) Loading /usr/local/lib/xorg/modules/extensions//libextmod.so (II) Module extmod: vendor=X.Org Foundation compiled for 1.6.0, module version = 1.0.0 Module class: X.Org Server Extension ABI class: X.Org Server Extension, version 2.0 (II) Loading extension MIT-SCREEN-SAVER (II) Loading extension XFree86-VidModeExtension (II) Loading extension XFree86-DGA (II) Loading extension DPMS (II) Loading extension XVideo (II) Loading extension XVideo-MotionCompensation (II) Loading extension X-Resource (II) LoadModule: record (II) Loading /usr/local/lib/xorg/modules/extensions//librecord.so (II) Module record: vendor=X.Org Foundation compiled for 1.6.0, module version = 1.13.0 Module class: X.Org Server Extension ABI class: X.Org Server Extension, version 2.0 (II) Loading extension RECORD (II) LoadModule: dbe (II) Loading /usr/local/lib/xorg/modules/extensions//libdbe.so (II) Module dbe: vendor=X.Org Foundation compiled for
Re: diagnosing freezes (DRI?)
On Sat, 11 Apr 2009 11:15:59 +0100 xorquew...@googlemail.com wrote: On 2009-04-11 02:30:40, Paul B. Mahol wrote: If it locks under X11 then use debug.debugger_on_panic=0 sysctl. Not doing this will increase drasticaly chances of locking whole system and not providing any debug data. I don't seem to have that sysctl. You sure that's the correct name? It's definitely in 8-current. Seems to be set to 0 as default. --- Gary Jennejohn ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: diagnosing freezes (DRI?)
On Sat, 11 Apr 2009 11:15:59 +0100 xorquew...@googlemail.com wrote: x On 2009-04-11 02:30:40, Paul B. Mahol wrote: If it locks under X11 then use debug.debugger_on_panic=0 sysctl. Not doing this will increase drasticaly chances of locking whole system and not providing any debug data. x I don't seem to have that sysctl. You will see this sysctl only if you build your kernel with ddb(4) support. If you are interested in providing useful information about your freezes, please read the following: http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug.html You need to build your kernel with options described in http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug-online-ddb.html and http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug-deadlocks.html As you run X, you need to have debug.debugger_on_panic=0 set (as Paul has suggested). Otherwise ddb would enter on panic but you wouldn't be able to access it due to X. After panic you will be able to get useful information from generated core dump using kgdb. Another option is to set debug.debugger_on_panic=1 but also set some ddb script that will run when the kernel debugger is entered as a result of a panic. This script will enable output capture, dump some useful debugging info to capture buffer, and then force a kernel dump to be written out followed by a reboot. E.g. running something like this will do the trick: ddb script 'kdb.enter.panic=capture on; show pcpu; show allpcpu; bt; ps; show locks; show alllocks; show lockedvnods; alltrace; call doadump; reset' After reboot you can extract captured information from the capture buffer information using the command: ddb capture -M /var/crash/vmcore.X print ddb.out You need to increase the value of debug.ddb.capture.bufsize sysctl variable to make sure all ddb output will be captured. You can read more about this in ddb(4), ddb(8), textdump(4). -- Mikolaj Golub ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: diagnosing freezes (DRI?)
On Sat, 2009-04-11 at 11:23 +0100, xorquew...@googlemail.com wrote: The machine ran for hours, apparently. I ended up going to bed and leaving it running. Woke up to find it on display sleep, frozen. Are you running the 7.2-PRE or -STABLE? There are a few relevant fixes in -STABLE that didn't make it into the pre-release. robert. It didn't panic, apparently. I've included Xorg.0.log and the last few lines of /var/log/messages but I don't believe they show anything very interesting. I should point out that this card is the dual-DVI version. I'm not sure if that's relevant (I think it's just less common). I'm only using one screen, currently. /var/log/Xorg.0.log: X.Org X Server 1.6.0 Release Date: 2009-2-25 X Protocol Version 11, Revision 0 Build Operating System: FreeBSD 7.2-PRERELEASE amd64 Current Operating System: FreeBSD viper.internal.network 7.2-PRERELEASE FreeBSD 7.2-PRERELEASE #0: Fri Apr 10 00:09:48 BST 2009 r...@viper.internal.network:/usr/obj/usr/src/sys/GENERIC amd64 Build Date: 11 April 2009 04:34:30AM Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: /var/log/Xorg.0.log, Time: Sat Apr 11 06:16:46 2009 (==) Using config file: /etc/X11/xorg.conf (==) ServerLayout X.org Configured (**) |--Screen Screen0 (0) (**) | |--Monitor Monitor0 (**) | |--Device Card0 (**) |--Input Device Mouse0 (**) |--Input Device Keyboard0 (==) Not automatically adding devices (==) Not automatically enabling devices (WW) The directory /usr/local/lib/X11/fonts/TTF/ does not exist. Entry deleted from font path. (WW) The directory /usr/local/lib/X11/fonts/OTF does not exist. Entry deleted from font path. (WW) The directory /usr/local/lib/X11/fonts/Type1/ does not exist. Entry deleted from font path. (WW) The directory /usr/local/lib/X11/fonts/TTF/ does not exist. Entry deleted from font path. (WW) The directory /usr/local/lib/X11/fonts/OTF does not exist. Entry deleted from font path. (WW) The directory /usr/local/lib/X11/fonts/Type1/ does not exist. Entry deleted from font path. (**) FontPath set to: /usr/local/lib/X11/fonts/misc/, /usr/local/lib/X11/fonts/100dpi/, /usr/local/lib/X11/fonts/75dpi/, /usr/local/lib/X11/fonts/misc/, /usr/local/lib/X11/fonts/100dpi/, /usr/local/lib/X11/fonts/75dpi/, built-ins (**) ModulePath set to /usr/local/lib/xorg/modules (II) Loader magic: 0xd20 (II) Module ABI versions: X.Org ANSI C Emulation: 0.4 X.Org Video Driver: 5.0 X.Org XInput driver : 4.0 X.Org Server Extension : 2.0 (II) Loader running on freebsd (--) Using syscons driver with X support (version 134217730.0) (--) using VT number 9 (--) PCI:*(0...@6:0:0) ATI Technologies Inc RV570 [Radeon X1950 Pro] rev 154, Mem @ 0xd000/268435456, 0xfbee/65536, I/O @ 0xe000/256, BIOS @ 0x/65536 (--) PCI: (0...@6:0:1) ATI Technologies Inc RV570 [Radeon X1950 Pro] (secondary) rev 154, Mem @ 0xfbef/65536 (II) System resource ranges: [0] -1 0 0x000f - 0x000f (0x1) MX[B] [1] -1 0 0x000c - 0x000e (0x3) MX[B] [2] -1 0 0x - 0x0009 (0xa) MX[B] [3] -1 0 0x - 0x (0x1) IX[B] [4] -1 0 0x - 0x00ff (0x100) IX[B] (II) extmod will be loaded. This was enabled by default and also specified in the config file. (II) dbe will be loaded. This was enabled by default and also specified in the config file. (II) glx will be loaded. This was enabled by default and also specified in the config file. (II) record will be loaded. This was enabled by default and also specified in the config file. (II) dri will be loaded. This was enabled by default and also specified in the config file. (II) dri2 will be loaded. This was enabled by default and also specified in the config file. (II) LoadModule: extmod (II) Loading /usr/local/lib/xorg/modules/extensions//libextmod.so (II) Module extmod: vendor=X.Org Foundation compiled for 1.6.0, module version = 1.0.0 Module class: X.Org Server Extension ABI class: X.Org Server Extension, version 2.0 (II) Loading extension MIT-SCREEN-SAVER (II) Loading extension XFree86-VidModeExtension (II) Loading extension XFree86-DGA (II) Loading extension DPMS (II) Loading extension XVideo (II) Loading extension XVideo-MotionCompensation (II) Loading extension X-Resource (II) LoadModule: record (II) Loading /usr/local/lib/xorg/modules/extensions//librecord.so (II) Module record: vendor=X.Org Foundation compiled for 1.6.0, module version = 1.13.0 Module class: X.Org
Re: diagnosing freezes (DRI?)
On 2009-04-11 16:12:45, Mikolaj Golub wrote: If you are interested in providing useful information about your freezes, please read the following: Thanks very much. Will be doing all of the above. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: diagnosing freezes (DRI?)
On 2009-04-11 14:11:15, Robert Noland wrote: Are you running the 7.2-PRE or -STABLE? There are a few relevant fixes in -STABLE that didn't make it into the pre-release. Sorry, should've made that clear. It was meant to be -STABLE but it seems to be calling itself -PRE. Just to clarify, my uname says 7.2-PRERELEASE but I used the 'stable-supfile'. This is expected, yes? I'm about to update the machine's BIOS and then enable all the possible debugging options from the kernel dev handbook. xw ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: diagnosing freezes (DRI?)
On Sat, 2009-04-11 at 20:30 +0100, xorquew...@googlemail.com wrote: On 2009-04-11 14:11:15, Robert Noland wrote: Are you running the 7.2-PRE or -STABLE? There are a few relevant fixes in -STABLE that didn't make it into the pre-release. Sorry, should've made that clear. It was meant to be -STABLE but it seems to be calling itself -PRE. Just to clarify, my uname says 7.2-PRERELEASE but I used the 'stable-supfile'. This is expected, yes? I'm about to update the machine's BIOS and then enable all the possible debugging options from the kernel dev handbook. Yes, just make sure that your -STABLE is at least: r190653 | rnoland | 2009-04-02 13:21:41 -0500 (Thu, 02 Apr 2009) | 7 lines robert. xw -- Robert Noland rnol...@freebsd.org FreeBSD signature.asc Description: This is a digitally signed message part
Re: diagnosing freezes (DRI?)
On Sat, 2009-04-11 at 14:06 +0200, Gary Jennejohn wrote: On Sat, 11 Apr 2009 11:15:59 +0100 xorquew...@googlemail.com wrote: On 2009-04-11 02:30:40, Paul B. Mahol wrote: If it locks under X11 then use debug.debugger_on_panic=0 sysctl. Not doing this will increase drasticaly chances of locking whole system and not providing any debug data. I don't seem to have that sysctl. You sure that's the correct name? It's definitely in 8-current. Seems to be set to 0 as default. This may only exist if you have DDB enabled... robert. --- Gary Jennejohn ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org -- Robert Noland rnol...@freebsd.org FreeBSD signature.asc Description: This is a digitally signed message part
Re: diagnosing freezes (DRI?)
On 4/11/09, xorquew...@googlemail.com xorquew...@googlemail.com wrote: On 2009-04-11 02:30:40, Paul B. Mahol wrote: If it locks under X11 then use debug.debugger_on_panic=0 sysctl. Not doing this will increase drasticaly chances of locking whole system and not providing any debug data. I don't seem to have that sysctl. You sure that's the correct name? Well if you dont have it, capturing cores should generaly still work. But in this case some kind of serial console is only remaining option. -- Paul ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: diagnosing freezes (DRI?)
Hello. Recently bought a new system and am experiencing problems with system freezes. I think the most likely culprit is DRI. The freezes occur apparently at random. I've disabled drm.ko and radeon.ko and the system doesn't appear to have frozen yet. I'm running 7.2-PRERELEASE (STABLE as of yesterday). Machine's dmesg: Copyright (c) 1992-2009 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 7.2-PRERELEASE #0: Fri Apr 10 00:09:48 BST 2009 r...@viper.internal.network:/usr/obj/usr/src/sys/GENERIC Timecounter i8254 frequency 1193182 Hz quality 0 CPU: Intel(R) Core(TM) i7 CPU 920 @ 2.67GHz (2665.04-MHz K8-class CPU) Origin = GenuineIntel Id = 0x106a4 Stepping = 4 Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE Features2=0x98e3bdSSE3,RSVD2,MON,DS_CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,b19,b20,b23 AMD Features=0x28100800SYSCALL,NX,RDTSCP,LM AMD Features2=0x1LAHF Cores per package: 8 Logical CPUs per core: 2 usable memory = 12862480384 (12266 MB) avail memory = 12424323072 (11848 MB) ACPI APIC Table: 121008 APIC1726 FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 cpu4 (AP): APIC ID: 4 cpu5 (AP): APIC ID: 5 cpu6 (AP): APIC ID: 6 cpu7 (AP): APIC ID: 7 ioapic0: Changing APIC ID to 8 ioapic0 Version 2.0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: 121008 RSDT1726 on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of 0, a (3) failed acpi0: reservation of 10, bff0 (3) failed Timecounter ACPI-fast frequency 3579545 Hz quality 1000 acpi_timer0: 24-bit timer at 3.579545MHz port 0x808-0x80b on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 pcib1: ACPI PCI-PCI bridge at device 1.0 on pci0 pci7: ACPI PCI bus on pcib1 pcib2: ACPI PCI-PCI bridge at device 3.0 on pci0 pci6: ACPI PCI bus on pcib2 vgapci0: VGA-compatible display port 0xe000-0xe0ff mem 0xd000-0xdfff,0xfbee-0xfbee irq 16 at device 0.0 on pci6 drm0: ATI Radeon X1950 on vgapci0 vgapci0: child drm0 requested pci_enable_busmaster info: [drm] Initialized radeon 1.29.0 20080528 vgapci1: VGA-compatible display mem 0xfbef-0xfbef at device 0.1 on pci6 pcib3: ACPI PCI-PCI bridge at device 7.0 on pci0 pci5: ACPI PCI bus on pcib3 pci0: base peripheral, interrupt controller at device 16.0 (no driver attached) pci0: base peripheral, interrupt controller at device 16.1 (no driver attached) pci0: base peripheral, interrupt controller at device 20.0 (no driver attached) pci0: base peripheral, interrupt controller at device 20.1 (no driver attached) pci0: base peripheral, interrupt controller at device 20.2 (no driver attached) pci0: base peripheral, interrupt controller at device 20.3 (no driver attached) uhci0: UHCI (generic) USB controller port 0x9080-0x909f irq 16 at device 26.0 on pci0 uhci0: [GIANT-LOCKED] uhci0: [ITHREAD] usb0: UHCI (generic) USB controller on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 on usb0 uhub0: 2 ports with 2 removable, self powered uhci1: UHCI (generic) USB controller port 0x9400-0x941f irq 21 at device 26.1 on pci0 uhci1: [GIANT-LOCKED] uhci1: [ITHREAD] usb1: UHCI (generic) USB controller on uhci1 usb1: USB revision 1.0 uhub1: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 on usb1 uhub1: 2 ports with 2 removable, self powered uhci2: UHCI (generic) USB controller port 0x9480-0x949f irq 19 at device 26.2 on pci0 uhci2: [GIANT-LOCKED] uhci2: [ITHREAD] usb2: UHCI (generic) USB controller on uhci2 usb2: USB revision 1.0 uhub2: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 on usb2 uhub2: 2 ports with 2 removable, self powered ehci0: EHCI (generic) USB 2.0 controller mem 0xfb9f6000-0xfb9f63ff irq 18 at device 26.7 on pci0 ehci0: [GIANT-LOCKED] ehci0: [ITHREAD] usb3: EHCI version 1.0 usb3: companion controllers, 2 ports each: usb0 usb1 usb2 usb3: EHCI (generic) USB 2.0 controller on ehci0 usb3: USB revision 2.0 uhub3: Intel EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 on usb3 uhub3: 6 ports with 6 removable, self powered uhub4: NEC Corporation USB2.0 Hub Controller, class 9/0, rev 2.00/1.00, addr 2 on uhub3 uhub4: single transaction translator uhub4: 4 ports with 4 removable, self powered ukbd0: Griffin Technology, Inc. iMate, USB To ADB Adaptor, class 0/0, rev 1.00/3.70, addr 3 on uhub4 kbd2 at ukbd0 ums0: Griffin Technology, Inc. iMate, USB To ADB Adaptor, class 0/0, rev 1.00/3.70, addr 3 on uhub4 ums0: 3 buttons. ums1: Microsoft Basic Optical Mouse, class 0/0, rev 1.10/0.00, addr 4 on uhub4 ums1: 3 buttons and Z dir. uhub5: Mitsumi Electric Hub in Apple
Re: diagnosing freezes (DRI?)
On Fri, 2009-04-10 at 16:42 +0100, xorquew...@googlemail.com wrote: Hello. Recently bought a new system and am experiencing problems with system freezes. I think the most likely culprit is DRI. The freezes occur apparently at random. I've disabled drm.ko and radeon.ko and the system doesn't appear to have frozen yet. I'm running 7.2-PRERELEASE (STABLE as of yesterday). Machine's dmesg: Copyright (c) 1992-2009 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 7.2-PRERELEASE #0: Fri Apr 10 00:09:48 BST 2009 r...@viper.internal.network:/usr/obj/usr/src/sys/GENERIC Timecounter i8254 frequency 1193182 Hz quality 0 CPU: Intel(R) Core(TM) i7 CPU 920 @ 2.67GHz (2665.04-MHz K8-class CPU) Origin = GenuineIntel Id = 0x106a4 Stepping = 4 Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE Features2=0x98e3bdSSE3,RSVD2,MON,DS_CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,b19,b20,b23 AMD Features=0x28100800SYSCALL,NX,RDTSCP,LM AMD Features2=0x1LAHF Cores per package: 8 Logical CPUs per core: 2 usable memory = 12862480384 (12266 MB) avail memory = 12424323072 (11848 MB) ACPI APIC Table: 121008 APIC1726 FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 cpu4 (AP): APIC ID: 4 cpu5 (AP): APIC ID: 5 cpu6 (AP): APIC ID: 6 cpu7 (AP): APIC ID: 7 ioapic0: Changing APIC ID to 8 ioapic0 Version 2.0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: 121008 RSDT1726 on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of 0, a (3) failed acpi0: reservation of 10, bff0 (3) failed Timecounter ACPI-fast frequency 3579545 Hz quality 1000 acpi_timer0: 24-bit timer at 3.579545MHz port 0x808-0x80b on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 pcib1: ACPI PCI-PCI bridge at device 1.0 on pci0 pci7: ACPI PCI bus on pcib1 pcib2: ACPI PCI-PCI bridge at device 3.0 on pci0 pci6: ACPI PCI bus on pcib2 vgapci0: VGA-compatible display port 0xe000-0xe0ff mem 0xd000-0xdfff,0xfbee-0xfbee irq 16 at device 0.0 on pci6 drm0: ATI Radeon X1950 on vgapci0 vgapci0: child drm0 requested pci_enable_busmaster info: [drm] Initialized radeon 1.29.0 20080528 vgapci1: VGA-compatible display mem 0xfbef-0xfbef at device 0.1 on pci6 pcib3: ACPI PCI-PCI bridge at device 7.0 on pci0 pci5: ACPI PCI bus on pcib3 pci0: base peripheral, interrupt controller at device 16.0 (no driver attached) pci0: base peripheral, interrupt controller at device 16.1 (no driver attached) pci0: base peripheral, interrupt controller at device 20.0 (no driver attached) pci0: base peripheral, interrupt controller at device 20.1 (no driver attached) pci0: base peripheral, interrupt controller at device 20.2 (no driver attached) pci0: base peripheral, interrupt controller at device 20.3 (no driver attached) uhci0: UHCI (generic) USB controller port 0x9080-0x909f irq 16 at device 26.0 on pci0 uhci0: [GIANT-LOCKED] uhci0: [ITHREAD] usb0: UHCI (generic) USB controller on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 on usb0 uhub0: 2 ports with 2 removable, self powered uhci1: UHCI (generic) USB controller port 0x9400-0x941f irq 21 at device 26.1 on pci0 uhci1: [GIANT-LOCKED] uhci1: [ITHREAD] usb1: UHCI (generic) USB controller on uhci1 usb1: USB revision 1.0 uhub1: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 on usb1 uhub1: 2 ports with 2 removable, self powered uhci2: UHCI (generic) USB controller port 0x9480-0x949f irq 19 at device 26.2 on pci0 uhci2: [GIANT-LOCKED] uhci2: [ITHREAD] usb2: UHCI (generic) USB controller on uhci2 usb2: USB revision 1.0 uhub2: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 on usb2 uhub2: 2 ports with 2 removable, self powered ehci0: EHCI (generic) USB 2.0 controller mem 0xfb9f6000-0xfb9f63ff irq 18 at device 26.7 on pci0 ehci0: [GIANT-LOCKED] ehci0: [ITHREAD] usb3: EHCI version 1.0 usb3: companion controllers, 2 ports each: usb0 usb1 usb2 usb3: EHCI (generic) USB 2.0 controller on ehci0 usb3: USB revision 2.0 uhub3: Intel EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 on usb3 uhub3: 6 ports with 6 removable, self powered uhub4: NEC Corporation USB2.0 Hub Controller, class 9/0, rev 2.00/1.00, addr 2 on uhub3 uhub4: single transaction translator uhub4: 4 ports with 4 removable, self powered ukbd0: Griffin Technology, Inc. iMate, USB To ADB Adaptor, class 0/0, rev 1.00/3.70, addr 3 on uhub4 kbd2 at ukbd0 ums0: Griffin Technology, Inc. iMate, USB To ADB Adaptor, class 0/0, rev
Re: diagnosing freezes (DRI?)
Hello. On 2009-04-10 12:42:48, Robert Noland wrote: Are you running powerd by chance? I was seeing an issue that seemed to be related to powerd. Since I've disabled it on that box, it hasn't hung up any more. I'm not running powerd, no. As far as drm is concerned, I've been running on an x1650 for probably a week now while working mostly on port stuff and I haven't seen any issues. This is with full 3d and compiz running, etc... So, if it is drm related... we are going to have to dig up some debugging info somehow... robert. The system doesn't seem to have frozen since DRI/DRM was disabled. I did have one crash/reboot whilst building a large number of packages with tinderbox. I've currently got both tinderbox and a make -j 16 buildworld going on a loop in the hope that I can trigger it again. Being the idiot I am, I had encrypted swap enabled and so savecore didn't save anything. Won't make that mistake twice. I'm currently using a world compiled WITH_DEBUG but is there anything else I can do? thanks, xw ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: diagnosing freezes (DRI?)
On Fri, 2009-04-10 at 18:59 +0100, xorquew...@googlemail.com wrote: Hello. On 2009-04-10 12:42:48, Robert Noland wrote: Are you running powerd by chance? I was seeing an issue that seemed to be related to powerd. Since I've disabled it on that box, it hasn't hung up any more. I'm not running powerd, no. As far as drm is concerned, I've been running on an x1650 for probably a week now while working mostly on port stuff and I haven't seen any issues. This is with full 3d and compiz running, etc... So, if it is drm related... we are going to have to dig up some debugging info somehow... robert. The system doesn't seem to have frozen since DRI/DRM was disabled. I did have one crash/reboot whilst building a large number of packages with tinderbox. I've currently got both tinderbox and a make -j 16 buildworld going on a loop in the hope that I can trigger it again. Being the idiot I am, I had encrypted swap enabled and so savecore didn't save anything. Won't make that mistake twice. I'm currently using a world compiled WITH_DEBUG but is there anything else I can do? If it is locking the whole system, then a core is really our best shot. If you can extract anything useful from xorg.log or setting hw.dri.0.debug that also might be of use. I'm running on 2 cores, but it is possible that some locking issue exists. All of the driver specific ioctls are run under a lock though. robert. thanks, xw ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org -- Robert Noland rnol...@freebsd.org FreeBSD signature.asc Description: This is a digitally signed message part
Re: diagnosing freezes (DRI?)
On 2009-04-10 13:31:33, Robert Noland wrote: If it is locking the whole system, then a core is really our best shot. If you can extract anything useful from xorg.log or setting hw.dri.0.debug that also might be of use. I'm running on 2 cores, but it is possible that some locking issue exists. All of the driver specific ioctls are run under a lock though. robert. Ok. I've re-enabled drm.ko and radeon.ko and am running X. I'll leave the system under load and let you know when it inevitably locks up... cheers, xw ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: diagnosing freezes (DRI?)
On 4/10/09, xorquew...@googlemail.com xorquew...@googlemail.com wrote: On 2009-04-10 13:31:33, Robert Noland wrote: If it is locking the whole system, then a core is really our best shot. If you can extract anything useful from xorg.log or setting hw.dri.0.debug that also might be of use. I'm running on 2 cores, but it is possible that some locking issue exists. All of the driver specific ioctls are run under a lock though. robert. Ok. I've re-enabled drm.ko and radeon.ko and am running X. I'll leave the system under load and let you know when it inevitably locks up... cheers, If it locks under X11 then use debug.debugger_on_panic=0 sysctl. Not doing this will increase drasticaly chances of locking whole system and not providing any debug data. -- Paul ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
