Re: MFC of Large set of CAM improvements breaks I/O to Adaptec 29160 SCSI controller
Scott Long wrote: On Apr 29, 2010, at 2:50 AM, Pete French wrote: Thanks. First step successful - I can steadily reproduce problem on CURRENT. raidtest with 200 I/O streams over gmirror of two disks on same channel triggers issue in seconds. Any I/O on channel dying after both disks report Queue full error same time. The rest of system works fine. If I preliminarily manually adjust queue depth of one disk - everything works fine. I'll investigate it tomorrow. Glad you have managed to dupliate it - the queue depth thing is inetersting, what changes did you make ? I can try them here and see if they improve the situation on either of my two machines. For the record, queue-full is a common, expected condition in CAM. It's not something that should be avoided =-) Should we maybe have a counter in sysctl rather than flooding the console with these messages then? robert. Scott ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: freebsd7 (and 8), radeon, xorg-server - deadlock or so
On Mon, 2010-02-15 at 14:23 +0100, Martin Kristensen wrote: On Sat, 13 Feb 2010 15:27:04 -0600 Robert Noland rnol...@freebsd.org wrote: On Sat, 2010-02-13 at 11:37 -0800, Norbert Papke wrote: On February 13, 2010, Robert Noland wrote: Ok, I've put up a patch at: http://people.freebsd.org/~rnoland/drm-radeon-test.patch http://people.freebsd.org/~rnoland/drm-radeon-8-test.patch This one should work on 8... robert. This is sort of a mega patch and includes: Re-worked drm mapping code, that ensures that we don't end up incorrectly mapping certain maps with overlapping offsets. This generally shows up as the ring buffer not being cleared (contents != 0 in xorg.log) which leads to corruption and other bad behavior. Re-written scatter gather allocation code. This interacts directly with the VM system, rather than using bus_dma to allow us to grab non-contiguous pages for the scatter gather backing of the GART. It also makes it easier to handle the caching mode of the backing pages. Disable cache snooping on radeon cards, since we have write combining set properly now. I have at least done a test build on -CURRENT with this patch, but I haven't had time to do much else without the rest of the code in my tree. I've been running most all of this code for a month or two now at least, so it is mostly just a question of whether or not I got all of the conflicts sorted out properly when I made this patch. The re-mapping code has the most widespread impact and has been tested on radeon r600 amd64, intel g45 i386 and mga amd64. robert. The patch applied cleanly. I have applied the patch to a clean 8-STABLE environment with WITNESS, INVARIANTS and KDB_UNATTENDED in the kernel. I still see the crashes when starting X with DRI on. This is what I see in messages: Feb 14 19:13:44 alpha kernel: [drm:pid30467:drm_mmap] called with offset 070001c7b000 Feb 14 19:13:44 alpha kernel: [drm:pid30467:drm_mmap] called with offset 070001c7c000 Feb 14 19:13:44 alpha kernel: Feb 14 19:13:44 alpha kernel: [drm:pid30467:drm_mmap] called with offset 070001c7d000 Feb 14 19:13:44 alpha kernel: Feb 14 19:13:44 alpha kernel: [drm:pid30467:drm_mmap] called with offset 070001c7e000 Feb 14 19:13:44 alpha kernel: [drm:pid30467:drm_mmap] called with offset 070001c7f000 Feb 14 19:13:44 alpha kernel: Feb 14 19:13:44 alpha kernel: [drm:pid30467:drm_ioctl] pid=30467, cmd=0xc0286415, nr=0x15, dev 0xff0001a79400, auth=1 Feb 14 19:13:44 alpha kernel: Feb 14 19:13:44 alpha kernel: [drm:pid30467:drm_addmap] offset = 0xfe8e, size = 0x0001, type = 1 Feb 14 19:13:44 alpha kernel: [drm:pid30467:drm_addmap] Found kernel map 1 Feb 14 19:13:44 alpha kernel: [drm:pid30467:drm_addmap] Added map 1 0xfe8e/0x1 Feb 14 19:13:44 alpha kernel: [drm:pid30467:drm_ioctl] pid=30467, cmd=0x80106459, nr=0x59, dev 0xff0001a79400, auth=1 There has been one odd development. If I startx with DRI off or NoAccel set it starts as usual. If I then quit and to cli and restart, I see the same crash as if I had DRI on. I'm really starting to think that this is a bug in the Xserver somewhere... If DRI is off, the kernel drm is not involved at all. The radeon driver does grope around on the pci bus (via libpciaccess) which could potentially cause issues, but... miwi and a few other folks have picked up the ball to get us up to xorg 7.5, since I just don't have time to do it all now. That might be a good thing to try, I expect that they will have a patch ready soon, like within a few days. robert. Martin -- Robert Noland rnol...@freebsd.org FreeBSD ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: booting off a ZFS pool consisting of multiple striped mirror vdevs
On Mon, 2010-02-15 at 10:07 -0800, Matt Reimer wrote: On Sat, Feb 13, 2010 at 12:04 PM, Dan Naumov dan.nau...@gmail.com wrote: Hello I have succesfully tested and used a full ZFS install of FreeBSD 8.0 on both single disk and mirror disk configurations using both MBR and GPT partitioning. AFAIK, with the more recent -CURRENT and -STABLE it is also possible to boot off a root filesystem located on raidz/raidz2 pools. But what about booting off pools consisting of multiple striped mirror or raidz vdevs? Like this: Assume each disk looks like a half of a traditional ZFS mirror root configuration using GPT 1: freebsd-boot 2: freebsd-swap 3: freebsd-zfs |disk1+disk2| + |disk3+disk4| + |disk5+disk6| My logic tells me that while booting off any of the 6 disks, boot0 and boot1 stage should obviously work fine, but what about the boot2 stage? Can it properly handle booting off a root filesystem thats striped across 3 mirror vdevs or is booting off a single mirror vdev the best that one can do right now? I don't know, but I plan to test that scenario in a few days. It *should* work... I made changes a while back that allow for multiple vdevs to attach to the root. In this case you should have 3 mirror vdevs attached to the root, so as long as the BIOS can enumerate all of the drives, we should find all of the vdevs and build the tree correctly. It should be simple enough to test in qemu, except that the BIOS in qemu is a little broken and might not id all of the drives. robert. Matt ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org -- Robert Noland rnol...@freebsd.org FreeBSD ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: freebsd7 (and 8), radeon, xorg-server - deadlock or so
On Thu, 2010-02-11 at 08:49 +0100, Ulrich Spörlein wrote: On Wed, 10.02.2010 at 12:08:12 -0600, Robert Noland wrote: On Wed, 2010-02-10 at 19:00 +0100, Ulrich Spörlein wrote: On Wed, 10.02.2010 at 09:11:10 -0600, Robert Noland wrote: I have a strong suspicion that the issue is with bus_dma. If this is a pci based card, then it is trying to allocate 32MB of contiguous physical ram when the drm device is opened. This usually succeeds the first time that the driver opens the device, but later, after memory has become fragmented, this can become an issue. As I have mentioned, I have code that reworks this whole process and I'll try and make a patch available soon, but my I don't have a lot of time now, so it might be the weekend before I can rebase the code and get a clean patch. No deadlocks for me, but I've been hit by the 32MB issue. On 8-STABLE without the recent Xorg update (haven't done that yet) I usually startx right after boot, and this usually works fine. One time I had massive ZFS/git jobs running headless first and wanted to startx afterwards. X11 took quite some time to come up and although window switching was snappy, *moving* windows around was slow as hell, window contents were re-drawing at ~1FPS. This also seems to always happen if I stop X11 and startx it again. So I made a diff from a regular Xorg startup against the slow one: --- Xorg.0.log 2010-02-09 20:59:16.0 +0100 +++ Xorg.slow.log 2010-01-31 11:04:08.0 +0100 ... @@ -599,49 +599,22 @@ (II) RADEON(0): [drm] added 1 reserved context for kernel (II) RADEON(0): X context handle = 0x1 (II) RADEON(0): [drm] installed DRM signal handler -(II) RADEON(0): [pci] 32768 kB allocated with handle 0xed1a5000 -(II) RADEON(0): [pci] ring handle = 0xed1a5000 -(II) RADEON(0): [pci] Ring mapped at 0x802aa -(II) RADEON(0): [pci] Ring contents 0x -(II) RADEON(0): [pci] ring read ptr handle = 0xed2a6000 -(II) RADEON(0): [pci] Ring read ptr mapped at 0x8006d6000 -(II) RADEON(0): [pci] Ring read ptr contents 0x -(II) RADEON(0): [pci] vertex/indirect buffers handle = 0xed2a7000 -(II) RADEON(0): [pci] Vertex/indirect buffers mapped at 0x812c0 -(II) RADEON(0): [pci] Vertex/indirect buffers contents 0x -(II) RADEON(0): [pci] GART texture map handle = 0xed4a7000 -(II) RADEON(0): [pci] GART Texture map mapped at 0x812ea7000 -(II) RADEON(0): [drm] register handle = 0xfe8e -(II) RADEON(0): [dri] Visual configs initialized +(EE) RADEON(0): [pci] Out of memory (-12) Yes, drm failed to allocate the 32MB to back the GART, so drm was disabled. Hopefully, the new allocation strategy will resolve this since it will just require 32MB of physical ram below 4GB without needing it to be contiguous. Hmm, given that today, 32MB isn't really that much, wouldn't it make more sense to have radeon(4) reserve those 32MB on load and never let go? I have radeon_load=YES set in loader.conf so it has a fair chance to always get it's 32MB contig. memory during startup. Given ZFS' memory hunger, there may not be enough free physical RAM below 4GB ... Ok, I've put up a patch at: http://people.freebsd.org/~rnoland/drm-radeon-test.patch This is sort of a mega patch and includes: Re-worked drm mapping code, that ensures that we don't end up incorrectly mapping certain maps with overlapping offsets. This generally shows up as the ring buffer not being cleared (contents != 0 in xorg.log) which leads to corruption and other bad behavior. Re-written scatter gather allocation code. This interacts directly with the VM system, rather than using bus_dma to allow us to grab non-contiguous pages for the scatter gather backing of the GART. It also makes it easier to handle the caching mode of the backing pages. Disable cache snooping on radeon cards, since we have write combining set properly now. I have at least done a test build on -CURRENT with this patch, but I haven't had time to do much else without the rest of the code in my tree. I've been running most all of this code for a month or two now at least, so it is mostly just a question of whether or not I got all of the conflicts sorted out properly when I made this patch. The re-mapping code has the most widespread impact and has been tested on radeon r600 amd64, intel g45 i386 and mga amd64. robert. But it's your call, you obviously know more about this than me anyway :) Bye, Uli -- Robert Noland rnol...@freebsd.org FreeBSD ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: freebsd7 (and 8), radeon, xorg-server - deadlock or so
On Sat, 2010-02-13 at 11:37 -0800, Norbert Papke wrote: On February 13, 2010, Robert Noland wrote: Ok, I've put up a patch at: http://people.freebsd.org/~rnoland/drm-radeon-test.patch This is sort of a mega patch and includes: Re-worked drm mapping code, that ensures that we don't end up incorrectly mapping certain maps with overlapping offsets. This generally shows up as the ring buffer not being cleared (contents != 0 in xorg.log) which leads to corruption and other bad behavior. Re-written scatter gather allocation code. This interacts directly with the VM system, rather than using bus_dma to allow us to grab non-contiguous pages for the scatter gather backing of the GART. It also makes it easier to handle the caching mode of the backing pages. Disable cache snooping on radeon cards, since we have write combining set properly now. I have at least done a test build on -CURRENT with this patch, but I haven't had time to do much else without the rest of the code in my tree. I've been running most all of this code for a month or two now at least, so it is mostly just a question of whether or not I got all of the conflicts sorted out properly when I made this patch. The re-mapping code has the most widespread impact and has been tested on radeon r600 amd64, intel g45 i386 and mga amd64. robert. I tweaked the patch and applied it to 8-STABLE. It has improved things. I no longer hang when starting X but DRI still does not work. I also intermittently experience the interrupt problem where the screen does not update unless I wiggle the mouse. It is entirely possible that I messed up adapting the patch for 8-STABLE. I did the following: * applied SVN 203287 and 203287 for VIA support * applied your patch * reverted drm_vm.c because it is dependent on r201223 (Update d_mmap() to accept vm_ooffset_t and vm_memattr_t.) Ah, on 8 it just needs to use d_mmap2. That is only a couple of line change. IIRC, just change d_mmap to d_mmap2 in drm_drv.c and change the declaration of drm_mmap to the correct type. d_mmap2 in 8 is the same as d_mmap in HEAD. * re-enabled snooping in ati_pcigart.c and r600_cp.c I have appended my xorg.0.log file. Perhaps something in there stands out as red flag? (II) [drm] Mapping SAREA for DRM lock failed. (EE) RADEON(0): [dri] DRIScreenInit failed. Disabling DRI. Hrm... That shouldn't happen... but I'm not sure if I missed something in the patch or if it hasn't applied correctly to 8 robert. Thank you for all the time you put into this. Cheers, -- Norbert Papke. npa...@acm.org X.Org X Server 1.6.5 Release Date: 2009-10-11 X Protocol Version 11, Revision 0 Build Operating System: FreeBSD 8.0-STABLE amd64 Current Operating System: FreeBSD proven.lan.provenpath.ca 8.0-STABLE FreeBSD 8.0-STABLE #36 r203841M: Sat Feb 13 10:50:20 PST 2010 npa...@proven.lan.provenpath.ca:/usr/obj/red/usr/public/freebsd/sources/stable8/sys/PROVEN amd64 Build Date: 10 February 2010 06:25:15PM 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 Feb 13 10:55:30 2010 (==) Using config file: /etc/X11/xorg.conf (==) ServerLayout X.org Configured (**) |--Screen Screen0 (0) (**) | |--Monitor LG (**) | |--Device Card0 (**) Option DontZap off (**) Option BlankTime 15 (**) Option StandbyTime 120 (**) Option SuspendTime 150 (**) Option OffTime 180 (**) Option AIGLX on (**) Option AllowEmptyInput false (==) Automatically adding devices (==) Automatically enabling devices (WW) `fonts.dir' not found (or not valid) in /usr/local/share/fonts/. Entry deleted from font path. (Run 'mkfontdir' on /usr/local/share/fonts/). (WW) `fonts.dir' not found (or not valid) in /usr/local/share/fonts/cmpsfont. Entry deleted from font path. (Run 'mkfontdir' on /usr/local/share/fonts/cmpsfont). (WW) `fonts.dir' not found (or not valid) in /usr/local/share/fonts/amspsfont. Entry deleted from font path. (Run 'mkfontdir' on /usr/local/share/fonts/amspsfont). (**) FontPath set to: /usr/local/lib/X11/fonts/bitstream-vera/, /usr/local/lib/X11/fonts/dejavu/, /usr/local/lib/X11/fonts/misc/, /usr/local/lib/X11/fonts/TrueType/, /usr/local/lib/X11/fonts/TTF/, /usr/local/lib/X11/fonts/OTF, /usr/local/lib/X11/fonts/Type1/, /usr/local/lib/X11/fonts/100dpi/, /usr/local/lib/X11/fonts/75dpi/, /usr/local/lib/X11/fonts/webfonts/, /usr/local/lib/X11/fonts/misc/, /usr/local/lib/X11/fonts/TTF/, /usr/local/lib/X11/fonts/OTF, /usr/local/lib/X11/fonts
Re: freebsd7 (and 8), radeon, xorg-server - deadlock or so
On Sat, 2010-02-13 at 11:37 -0800, Norbert Papke wrote: On February 13, 2010, Robert Noland wrote: Ok, I've put up a patch at: http://people.freebsd.org/~rnoland/drm-radeon-test.patch http://people.freebsd.org/~rnoland/drm-radeon-8-test.patch This one should work on 8... robert. This is sort of a mega patch and includes: Re-worked drm mapping code, that ensures that we don't end up incorrectly mapping certain maps with overlapping offsets. This generally shows up as the ring buffer not being cleared (contents != 0 in xorg.log) which leads to corruption and other bad behavior. Re-written scatter gather allocation code. This interacts directly with the VM system, rather than using bus_dma to allow us to grab non-contiguous pages for the scatter gather backing of the GART. It also makes it easier to handle the caching mode of the backing pages. Disable cache snooping on radeon cards, since we have write combining set properly now. I have at least done a test build on -CURRENT with this patch, but I haven't had time to do much else without the rest of the code in my tree. I've been running most all of this code for a month or two now at least, so it is mostly just a question of whether or not I got all of the conflicts sorted out properly when I made this patch. The re-mapping code has the most widespread impact and has been tested on radeon r600 amd64, intel g45 i386 and mga amd64. robert. I tweaked the patch and applied it to 8-STABLE. It has improved things. I no longer hang when starting X but DRI still does not work. I also intermittently experience the interrupt problem where the screen does not update unless I wiggle the mouse. It is entirely possible that I messed up adapting the patch for 8-STABLE. I did the following: * applied SVN 203287 and 203287 for VIA support * applied your patch * reverted drm_vm.c because it is dependent on r201223 (Update d_mmap() to accept vm_ooffset_t and vm_memattr_t.) * re-enabled snooping in ati_pcigart.c and r600_cp.c I have appended my xorg.0.log file. Perhaps something in there stands out as red flag? Thank you for all the time you put into this. Cheers, -- Norbert Papke. npa...@acm.org X.Org X Server 1.6.5 Release Date: 2009-10-11 X Protocol Version 11, Revision 0 Build Operating System: FreeBSD 8.0-STABLE amd64 Current Operating System: FreeBSD proven.lan.provenpath.ca 8.0-STABLE FreeBSD 8.0-STABLE #36 r203841M: Sat Feb 13 10:50:20 PST 2010 npa...@proven.lan.provenpath.ca:/usr/obj/red/usr/public/freebsd/sources/stable8/sys/PROVEN amd64 Build Date: 10 February 2010 06:25:15PM 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 Feb 13 10:55:30 2010 (==) Using config file: /etc/X11/xorg.conf (==) ServerLayout X.org Configured (**) |--Screen Screen0 (0) (**) | |--Monitor LG (**) | |--Device Card0 (**) Option DontZap off (**) Option BlankTime 15 (**) Option StandbyTime 120 (**) Option SuspendTime 150 (**) Option OffTime 180 (**) Option AIGLX on (**) Option AllowEmptyInput false (==) Automatically adding devices (==) Automatically enabling devices (WW) `fonts.dir' not found (or not valid) in /usr/local/share/fonts/. Entry deleted from font path. (Run 'mkfontdir' on /usr/local/share/fonts/). (WW) `fonts.dir' not found (or not valid) in /usr/local/share/fonts/cmpsfont. Entry deleted from font path. (Run 'mkfontdir' on /usr/local/share/fonts/cmpsfont). (WW) `fonts.dir' not found (or not valid) in /usr/local/share/fonts/amspsfont. Entry deleted from font path. (Run 'mkfontdir' on /usr/local/share/fonts/amspsfont). (**) FontPath set to: /usr/local/lib/X11/fonts/bitstream-vera/, /usr/local/lib/X11/fonts/dejavu/, /usr/local/lib/X11/fonts/misc/, /usr/local/lib/X11/fonts/TrueType/, /usr/local/lib/X11/fonts/TTF/, /usr/local/lib/X11/fonts/OTF, /usr/local/lib/X11/fonts/Type1/, /usr/local/lib/X11/fonts/100dpi/, /usr/local/lib/X11/fonts/75dpi/, /usr/local/lib/X11/fonts/webfonts/, /usr/local/lib/X11/fonts/misc/, /usr/local/lib/X11/fonts/TTF/, /usr/local/lib/X11/fonts/OTF, /usr/local/lib/X11/fonts/Type1/, /usr/local/lib/X11/fonts/100dpi/, /usr/local/lib/X11/fonts/75dpi/ (**) ModulePath set to /usr/local/lib/xorg/modules (**) Extension Composite is enabled (==) |--Input Device default pointer (==) |--Input Device default keyboard (==) The core pointer device wasn't specified explicitly in the layout. Using the default mouse configuration
Re: freebsd7 (and 8), radeon, xorg-server - deadlock or so
On Thu, 2010-02-11 at 08:49 +0100, Ulrich Spörlein wrote: On Wed, 10.02.2010 at 12:08:12 -0600, Robert Noland wrote: On Wed, 2010-02-10 at 19:00 +0100, Ulrich Spörlein wrote: On Wed, 10.02.2010 at 09:11:10 -0600, Robert Noland wrote: I have a strong suspicion that the issue is with bus_dma. If this is a pci based card, then it is trying to allocate 32MB of contiguous physical ram when the drm device is opened. This usually succeeds the first time that the driver opens the device, but later, after memory has become fragmented, this can become an issue. As I have mentioned, I have code that reworks this whole process and I'll try and make a patch available soon, but my I don't have a lot of time now, so it might be the weekend before I can rebase the code and get a clean patch. No deadlocks for me, but I've been hit by the 32MB issue. On 8-STABLE without the recent Xorg update (haven't done that yet) I usually startx right after boot, and this usually works fine. One time I had massive ZFS/git jobs running headless first and wanted to startx afterwards. X11 took quite some time to come up and although window switching was snappy, *moving* windows around was slow as hell, window contents were re-drawing at ~1FPS. This also seems to always happen if I stop X11 and startx it again. So I made a diff from a regular Xorg startup against the slow one: --- Xorg.0.log 2010-02-09 20:59:16.0 +0100 +++ Xorg.slow.log 2010-01-31 11:04:08.0 +0100 ... @@ -599,49 +599,22 @@ (II) RADEON(0): [drm] added 1 reserved context for kernel (II) RADEON(0): X context handle = 0x1 (II) RADEON(0): [drm] installed DRM signal handler -(II) RADEON(0): [pci] 32768 kB allocated with handle 0xed1a5000 -(II) RADEON(0): [pci] ring handle = 0xed1a5000 -(II) RADEON(0): [pci] Ring mapped at 0x802aa -(II) RADEON(0): [pci] Ring contents 0x -(II) RADEON(0): [pci] ring read ptr handle = 0xed2a6000 -(II) RADEON(0): [pci] Ring read ptr mapped at 0x8006d6000 -(II) RADEON(0): [pci] Ring read ptr contents 0x -(II) RADEON(0): [pci] vertex/indirect buffers handle = 0xed2a7000 -(II) RADEON(0): [pci] Vertex/indirect buffers mapped at 0x812c0 -(II) RADEON(0): [pci] Vertex/indirect buffers contents 0x -(II) RADEON(0): [pci] GART texture map handle = 0xed4a7000 -(II) RADEON(0): [pci] GART Texture map mapped at 0x812ea7000 -(II) RADEON(0): [drm] register handle = 0xfe8e -(II) RADEON(0): [dri] Visual configs initialized +(EE) RADEON(0): [pci] Out of memory (-12) Yes, drm failed to allocate the 32MB to back the GART, so drm was disabled. Hopefully, the new allocation strategy will resolve this since it will just require 32MB of physical ram below 4GB without needing it to be contiguous. Hmm, given that today, 32MB isn't really that much, wouldn't it make more sense to have radeon(4) reserve those 32MB on load and never let go? I have radeon_load=YES set in loader.conf so it has a fair chance to always get it's 32MB contig. memory during startup. Given ZFS' memory hunger, there may not be enough free physical RAM below 4GB ... While that would make sense... And it might work more like that once I implement TTM/KMS (actually the whole memory requirements will change as pages will then get mapped in and out of the gart), but currently, the allocation of scatter gather memory to populate the gart is driven by userland. The only memory that is pre-allocated by the driver is the sarea, and the register maps are pre-allocated, but that is just address mapping. For everything else, userland tells us when and how much memory to allocate. On radeon (and Intel for that matter) most if not all cards can reference anything that the cpu can, (up to at least 36 bits, iirc, or maybe 40) so I might drop the 4GB limit. However, since all of this is done in the generic drm code, I don't actually know what card I'm allocating memory for when I do it, so I won't change that part until I need to. I'll try and get a cleaned up patch of the scatter gather rework out this weekend. I've abandoned the use of bus_dma entirely for allocating SG pages and interact with the VM directly, thus avoiding the contiguous requirements of bus_dma. robert. But it's your call, you obviously know more about this than me anyway :) Bye, Uli -- Robert Noland rnol...@freebsd.org FreeBSD ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: freebsd7 (and 8), radeon, xorg-server - deadlock or so
On Thu, 2010-02-11 at 11:49 +0100, Martin Kristensen wrote: On Wed, 10 Feb 2010 20:17:43 -0600 Robert Noland rnol...@freebsd.org wrote: On Wed, 2010-02-10 at 23:43 +0100, Martin Kristensen wrote: On Wed, 10 Feb 2010 16:01:58 -0600 Robert Noland rnol...@freebsd.org wrote: On Wed, 2010-02-10 at 22:05 +0100, Martin Kristensen wrote: On Wed, 10 Feb 2010 20:33:46 +0200 Andriy Gapon a...@icyb.net.ua wrote: on 10/02/2010 20:29 Vitaly Magerya said the following: Robert Noland wrote: It is not, and yes I use WITHOUT_HAL. Currently disabling DRI helps; should I try rebuilding xorg-server with HAL? Yes, you can still disable hal at runtime by setting AutoAddDevices Off in xorg.conf. Seems to work with HAL. I've long thought that xorg server should be linked with libthr regardless of HAL option. Unfortunately, I never came up with patch, nor have anyone else. Xorg server really uses pthreads when doing DRM and HAL brings in libthr dependency only as an accident. This is my first post to this list, so hello all. I have been running with NoAccel for a long time, since disabling DRI alone would cause a complete deadlock (screen to standby, no ssh, no response to keyboard, etc.). However, I rebuilt xorg-server with HAL support, and now simply disabling DRI allows me to start X. The card is RV790 based. Just checked... This card should work with Accel and DRI... At least on -CURRENT with updated ports. Check UPDATING, and set WITHOUT_NOUVEAU to get correct version of libdrm. robert. I am on -STABLE built on Jan. 19. I updated mesa today (to libdrm-2.4.17), and rebuilt xorg-server and drivers. I have WITHOUT_NOUVEAU=YES in /etc/make.conf. pkg_info reports libGL-7.6.1. Is that 8-STABLE or 7? 8 should work, and I think 7 should as well, but just checking. 6 won't work. I am on 8-STABLE. I have tried loading radeon.ko manually before startx. What are the results? If things are not working, I'll want to see your xorg.conf, xorg.log, pciconf -lvb and a sysctl hw.dri with X started if you can get it. robert. I have attached the output from pciconf -lvb, sysctl -a |grep ^hw.dri reports: hw.dri.0.name: radeon 0x96 hw.dri.0.vm: hw.dri.0.clients: hw.dri.0.vblank: hw.dri.0.debug: 0 I loaded radeon.ko from within my X session, which was started with DRI OFF. Ok, if X doesn't try to open drm, then nothing will show up as being mapped. If you do a sysctl hw.dri it will show the mappings, but the above grep is cutting out most of the useful info. If I run startx with DRI True or without an xorg.conf, the screen goes into standby as if the pc is turned off, the mouse and keyboard stops responding to keypresses (ie. numlock-led will not respond to me pressing the key.) and I cannot ssh into the machine. As far as I can tell it has crashed. There is nothing in /var/log/messages, which gives any indication that something went wrong (If I boot the machine - startx and force a reboot I get 2 x dmesg plus fsck messages). Xorg.0.log contains only messages from the last successful start of xorg, and is a far as I can tell useless in tracking this down. This sounds suspiciously like a WITNESS issue... I wonder if I have accidentally MFC'd something that isn't safe. You don't get a core dump eventually do you? robert. If it will help, I can switch to -CURRENT to see if that changes anything. Martin PS. Robert, in researching this I got some idea of the effort you put into this, thanks! Martin -- Robert Noland rnol...@freebsd.org FreeBSD ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: freebsd7 (and 8), radeon, xorg-server - deadlock or so
On Thu, 2010-02-11 at 17:41 +0100, Martin Kristensen wrote: On Thu, 11 Feb 2010 14:50:44 +0100 Martin Kristensen m...@pc.dk wrote: On Thu, 11 Feb 2010 06:16:12 -0600 Robert Noland rnol...@freebsd.org wrote: On Thu, 2010-02-11 at 11:49 +0100, Martin Kristensen wrote: On Wed, 10 Feb 2010 20:17:43 -0600 Robert Noland rnol...@freebsd.org wrote: On Wed, 2010-02-10 at 23:43 +0100, Martin Kristensen wrote: On Wed, 10 Feb 2010 16:01:58 -0600 Robert Noland rnol...@freebsd.org wrote: On Wed, 2010-02-10 at 22:05 +0100, Martin Kristensen wrote: On Wed, 10 Feb 2010 20:33:46 +0200 Andriy Gapon a...@icyb.net.ua wrote: on 10/02/2010 20:29 Vitaly Magerya said the following: Robert Noland wrote: It is not, and yes I use WITHOUT_HAL. Currently disabling DRI helps; should I try rebuilding xorg-server with HAL? Yes, you can still disable hal at runtime by setting AutoAddDevices Off in xorg.conf. Seems to work with HAL. I've long thought that xorg server should be linked with libthr regardless of HAL option. Unfortunately, I never came up with patch, nor have anyone else. Xorg server really uses pthreads when doing DRM and HAL brings in libthr dependency only as an accident. This is my first post to this list, so hello all. I have been running with NoAccel for a long time, since disabling DRI alone would cause a complete deadlock (screen to standby, no ssh, no response to keyboard, etc.). However, I rebuilt xorg-server with HAL support, and now simply disabling DRI allows me to start X. The card is RV790 based. Just checked... This card should work with Accel and DRI... At least on -CURRENT with updated ports. Check UPDATING, and set WITHOUT_NOUVEAU to get correct version of libdrm. robert. I am on -STABLE built on Jan. 19. I updated mesa today (to libdrm-2.4.17), and rebuilt xorg-server and drivers. I have WITHOUT_NOUVEAU=YES in /etc/make.conf. pkg_info reports libGL-7.6.1. Is that 8-STABLE or 7? 8 should work, and I think 7 should as well, but just checking. 6 won't work. I am on 8-STABLE. I have tried loading radeon.ko manually before startx. What are the results? If things are not working, I'll want to see your xorg.conf, xorg.log, pciconf -lvb and a sysctl hw.dri with X started if you can get it. robert. I have attached the output from pciconf -lvb, sysctl -a |grep ^hw.dri reports: hw.dri.0.name: radeon 0x96 hw.dri.0.vm: hw.dri.0.clients: hw.dri.0.vblank: hw.dri.0.debug: 0 I loaded radeon.ko from within my X session, which was started with DRI OFF. Ok, if X doesn't try to open drm, then nothing will show up as being mapped. If you do a sysctl hw.dri it will show the mappings, but the above grep is cutting out most of the useful info. Sorry, I did not understand what you wanted, here is sysctl hw.dri: hw.dri.0.name: radeon 0x96 hw.dri.0.vm: slot offset size type flags address mtrr 0 0xfe8e 0x0001 REG 0x82 0xff00fe8e no hw.dri.0.clients: a devpid uid magic ioctls hw.dri.0.vblank: crtc ref countlast enabled inmodeset 00 00 00 00 01 00 00 00 hw.dri.0.debug: 0 If I run startx with DRI True or without an xorg.conf, the screen goes into standby as if the pc is turned off, the mouse and keyboard stops responding to keypresses (ie. numlock-led will not respond to me pressing the key.) and I cannot ssh into the machine. As far as I can tell it has crashed. There is nothing in /var/log/messages, which gives any indication that something went wrong (If I boot the machine - startx and force a reboot I get 2 x dmesg plus fsck messages). Xorg.0.log contains only messages from the last successful start of xorg, and is a far as I can tell useless in tracking this down. This sounds suspiciously like a WITNESS issue... I wonder if I have accidentally MFC'd something that isn't safe. You don't get a core dump eventually do you? robert. I have left it for at least the time it takes to boot my laptop and try to ssh into the machine (5 min.). I have dumpdev defined. I will crash it and leave it for 15 min. to see if something happens. Alas, I have crashed it a couple of times and left it for ~30 min. There was no change, and I got no core dump. Hrm, ok... I'll try to dig into it this weekend... robert. If it will help, I can switch
Re: freebsd7, radeon, xorg-server - deadlock or so
On Tue, 2010-02-09 at 20:41 -0700, Warren Block wrote: On Wed, 10 Feb 2010, Christof Schulze wrote: The situation is heavily unsatisfying, since one need an expensive AMD/ATi Radeon card to gain non-3D poor functionality, where a cheaper one should be do the same - but the cheaper ones don't work. Even if one uses AMD64, the situattion is worse and I have no reason using Linux-driver on a FreeBSD box. Hope the situation gets cleared in the nearest future. It's a kind of deadlock. As I said, either spenig a lot of money for a working RV770 based AMD graphics card with poor functionality or nothing so far, since most smaller RV730 chips aren't supported properly by the most recent drivers. To be fair - my ATI X300 has always worked. It is a cheap card with low-end performance but it is perfectly fine for regular desktop-use. The older chipsets are better supported because the newer ones are, well, newer. If you haven't bought a video card yet, look at the radeon(4x) man page first. radeon IS the best choice. They (amd) are reasonably supportive of our efforts, provide docs and code. Intel also does, but they are far less interested in supporting anything except linux with their latest and greatest code. As for older cards, as things change, the older cards get less and less testing and can sometimes have issues. I only have one AGP based radeon handy (8500DV), but for PCI-E, I have representations from every chip family, from x600 up to HD4650. Basically, r300, r500, r600. I do not have one of the IGP models, which are slightly different (rv480, rs690) but AFAIK, we resolved the issues with those chips and drm like a year ago. Warren and Adam Kirchof have also always been really good about providing testing on their fleet of radeons. A lockup without drm is almost certainly a GPU crash as there isn't any real kernel interaction. If you can ssh into the box and collect some info it might help to identify the issue. GPU crashes can be tricky to isolate though, since you really don't know where the instruction that is causing the issue is coming from. Dropping back to a really simple environment and slowly working forward to find out what triggers the issue is usually the best way. robert. Unfortunately, that doesn't help if you already have a newer card, or a notebook. The other choices are Intel, where they don't have standalone video cards, or nVidia, which has a full-featured blob and a really bare-bones open driver. -Warren Block * Rapid City, South Dakota USA ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org -- Robert Noland rnol...@freebsd.org FreeBSD ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: freebsd7 (and 8), radeon, xorg-server - deadlock or so
On Wed, 2010-02-10 at 12:29 +0200, Vitaly Magerya wrote: Oliver Pinter wrote: After updated the xorg* and dri* and dependency, the system going to deadlock at second start of xserver. I think it is not an uniqe issue, as others wrote them at freebsd-x11: http://lists.freebsd.org/pipermail/freebsd-x11/2010-February/009370.html I have a similar problem with ATI Mobility Radeon 9000 (r250) and FreeBSD 8.0-RELEASE-p2 i386 (dmesg is at [1]). The system hangs when I run Xorg with xorg.conf obtained by `Xorg -configure' and do either of these: * pkill Xorg * close xorg via ^C and start it again * close xorg via ^C and kldunload radeon I did not try using 'option DRI OFF' though, I will this evening. Unfortunately I can't currently say if it works under different conditions, since after a number of hangs I switched to VESA. But if anyone is interested, I'll investigate further and will provide any additional information -- just name it. I have a strong suspicion that the issue is with bus_dma. If this is a pci based card, then it is trying to allocate 32MB of contiguous physical ram when the drm device is opened. This usually succeeds the first time that the driver opens the device, but later, after memory has become fragmented, this can become an issue. As I have mentioned, I have code that reworks this whole process and I'll try and make a patch available soon, but my I don't have a lot of time now, so it might be the weekend before I can rebase the code and get a clean patch. robert. [1] http://tx97.net/~magv/dmesg-t40.80-p2.txt ___ freebsd-...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-x11 To unsubscribe, send any mail to freebsd-x11-unsubscr...@freebsd.org -- Robert Noland rnol...@freebsd.org FreeBSD ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: freebsd7, radeon, xorg-server - deadlock or so
On Wed, 2010-02-10 at 10:47 +, O. Hartmann wrote: On 02/10/10 03:41, Warren Block wrote: On Wed, 10 Feb 2010, Christof Schulze wrote: The situation is heavily unsatisfying, since one need an expensive AMD/ATi Radeon card to gain non-3D poor functionality, where a cheaper one should be do the same - but the cheaper ones don't work. Even if one uses AMD64, the situattion is worse and I have no reason using Linux-driver on a FreeBSD box. Hope the situation gets cleared in the nearest future. It's a kind of deadlock. As I said, either spenig a lot of money for a working RV770 based AMD graphics card with poor functionality or nothing so far, since most smaller RV730 chips aren't supported properly by the most recent drivers. To be fair - my ATI X300 has always worked. It is a cheap card with low-end performance but it is perfectly fine for regular desktop-use. The older chipsets are better supported because the newer ones are, well, newer. If you haven't bought a video card yet, look at the radeon(4x) man page first. Unfortunately, that doesn't help if you already have a newer card, or a notebook. The other choices are Intel, where they don't have standalone video cards, or nVidia, which has a full-featured blob and a really bare-bones open driver. -Warren Block * Rapid City, South Dakota USA You said it. Alternatives? Barely. Having Intel-X58 based mainboards for our workstations, there is no onboard-Intel solution. Speaking of nVidia - 64Bit FreeBSD-support isn't mature and, as far as I know, not yet arrived, but underway, but this is in the future and isn't subject of any consideration if I need to make my choices now. Our department orders, in most cases, a bunch of systems completely equipted also with graphics boards. In many cases, there is no reason, economically, buying outdated graphics boards which are 5 years old and older, despite the fact that many shops do not offer them. On Linux, most of those modern ATi/AMD video cards not working with X11 on FreeBSD/amd64 work on Linux due to the fact most Linux derivates have a more modern OpenSource Xorg environment, including 'cutting' edge DRI and drivers. The alternative is to play with the well supported 32- and 64-Bit blob even AMD/ATi offers for Linux. We use more or less, the same code that linux does. We don't have KMS/TTM yet, but generally, I think you will probably find more issues using those than you will with the slightly older driver. If you are having issues with the radeon driver, then you need to report that to me and be willing to provide details. The guys at AMD are pretty willing to offer support where needed, but I can't look into issues that I don't know about. The very newest radeons still aren't supported in any code, but all HD4xxx and below should be. I don't have the time that I have in the past, but I'll try and sort out issues as I can. robert. Regards, Oliver ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org -- Robert Noland rnol...@freebsd.org FreeBSD ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: freebsd7 (and 8), radeon, xorg-server - deadlock or so
On Wed, 2010-02-10 at 18:01 +0200, Vitaly Magerya wrote: Andriy Gapon wrote: Please check if your X binary is linked with libthr (using ldd). I saw similar problems when it was not. That was because it was compiled without HAL support. It is not, and yes I use WITHOUT_HAL. Currently disabling DRI helps; should I try rebuilding xorg-server with HAL? Yes, you can still disable hal at runtime by setting AutoAddDevices Off in xorg.conf. robert. -- Robert Noland rnol...@freebsd.org FreeBSD ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: freebsd7 (and 8), radeon, xorg-server - deadlock or so
On Wed, 2010-02-10 at 19:00 +0100, Ulrich Spörlein wrote: On Wed, 10.02.2010 at 09:11:10 -0600, Robert Noland wrote: I have a strong suspicion that the issue is with bus_dma. If this is a pci based card, then it is trying to allocate 32MB of contiguous physical ram when the drm device is opened. This usually succeeds the first time that the driver opens the device, but later, after memory has become fragmented, this can become an issue. As I have mentioned, I have code that reworks this whole process and I'll try and make a patch available soon, but my I don't have a lot of time now, so it might be the weekend before I can rebase the code and get a clean patch. No deadlocks for me, but I've been hit by the 32MB issue. On 8-STABLE without the recent Xorg update (haven't done that yet) I usually startx right after boot, and this usually works fine. One time I had massive ZFS/git jobs running headless first and wanted to startx afterwards. X11 took quite some time to come up and although window switching was snappy, *moving* windows around was slow as hell, window contents were re-drawing at ~1FPS. This also seems to always happen if I stop X11 and startx it again. So I made a diff from a regular Xorg startup against the slow one: --- Xorg.0.log 2010-02-09 20:59:16.0 +0100 +++ Xorg.slow.log 2010-01-31 11:04:08.0 +0100 ... @@ -599,49 +599,22 @@ (II) RADEON(0): [drm] added 1 reserved context for kernel (II) RADEON(0): X context handle = 0x1 (II) RADEON(0): [drm] installed DRM signal handler -(II) RADEON(0): [pci] 32768 kB allocated with handle 0xed1a5000 -(II) RADEON(0): [pci] ring handle = 0xed1a5000 -(II) RADEON(0): [pci] Ring mapped at 0x802aa -(II) RADEON(0): [pci] Ring contents 0x -(II) RADEON(0): [pci] ring read ptr handle = 0xed2a6000 -(II) RADEON(0): [pci] Ring read ptr mapped at 0x8006d6000 -(II) RADEON(0): [pci] Ring read ptr contents 0x -(II) RADEON(0): [pci] vertex/indirect buffers handle = 0xed2a7000 -(II) RADEON(0): [pci] Vertex/indirect buffers mapped at 0x812c0 -(II) RADEON(0): [pci] Vertex/indirect buffers contents 0x -(II) RADEON(0): [pci] GART texture map handle = 0xed4a7000 -(II) RADEON(0): [pci] GART Texture map mapped at 0x812ea7000 -(II) RADEON(0): [drm] register handle = 0xfe8e -(II) RADEON(0): [dri] Visual configs initialized +(EE) RADEON(0): [pci] Out of memory (-12) Yes, drm failed to allocate the 32MB to back the GART, so drm was disabled. Hopefully, the new allocation strategy will resolve this since it will just require 32MB of physical ram below 4GB without needing it to be contiguous. robert. +(EE) RADEON(0): [pci] PCI failed to initialize. Disabling the DRI. +(II) RADEON(0): [drm] removed 1 reserved context for kernel +(II) RADEON(0): [drm] unmapping 8192 bytes of SAREA 0xff8014a6d000 at 0x8006d4000 +(II) RADEON(0): [drm] Closed DRM master. (II) RADEON(0): RADEONRestoreMemMapRegisters() : (II) RADEON(0): MC_FB_LOCATION : 0x00ef00d0 0x001f (II) RADEON(0): MC_AGP_LOCATION : 0x003f (==) RADEON(0): Backing store disabled -(II) RADEON(0): [DRI] installation complete -(II) RADEON(0): [drm] Added 32 65536 byte vertex/indirect buffers -(II) RADEON(0): [drm] Mapped 32 vertex/indirect buffers -(II) RADEON(0): [drm] dma control initialized, using IRQ 256 -(II) RADEON(0): [drm] Initialized kernel GART heap manager, 29884416 -(WW) RADEON(0): DRI init changed memory map, adjusting ... -(WW) RADEON(0): MC_FB_LOCATION was: 0x00ef00d0 is: 0x00ef00d0 -(WW) RADEON(0): MC_AGP_LOCATION was: 0x003f is: 0x0003 -(II) RADEON(0): RADEONRestoreMemMapRegisters() : -(II) RADEON(0): MC_FB_LOCATION : 0x00ef00d0 0x00ef00d0 -(II) RADEON(0): MC_AGP_LOCATION : 0x0003 -(II) RADEON(0): Direct rendering enabled -(II) RADEON(0): Setting EXA maxPitchBytes -(II) EXA(0): Offscreen pixmap area of 111050752 bytes -(II) EXA(0): Driver registered support for the following operations: -(II) Solid -(II) Copy -(II) Composite (RENDER acceleration) -(II) UploadToScreen -(II) DownloadFromScreen -(II) RADEON(0): Acceleration enabled +(WW) RADEON(0): Direct rendering disabled +(EE) RADEON(0): Acceleration initialization failed +(II) RADEON(0): Acceleration disabled (**) Option dpms (**) RADEON(0): DPMS enabled (==) RADEON(0): Silken mouse enabled -(II) RADEON(0): Set up textured video +(II) RADEON(0): Textured video requires CP on R5xx/R6xx/R7xx/IGP Output CRT2 disable success (II) RADEON(0): UNIPHY1 transmitter: Coherent Mode enabled Output UNIPHY1 transmitter setup success @@ -661,7 +634,7 @@ Mode 1920x1200 - 2080 1235 9 (II) RADEON(0): RADEONRestoreMemMapRegisters() : (II) RADEON(0): MC_FB_LOCATION : 0x00ef00d0 0x00ef00d0 -(II) RADEON(0): MC_AGP_LOCATION : 0x0003 +(II) RADEON(0): MC_AGP_LOCATION : 0x003f freq: 15400 best_freq: 15390
Re: freebsd7 (and 8), radeon, xorg-server - deadlock or so
On Thu, 2010-02-11 at 06:58 +1100, Peter Jeremy wrote: On 2010-Feb-10 20:33:46 +0200, Andriy Gapon a...@icyb.net.ua wrote: I've long thought that xorg server should be linked with libthr regardless of HAL option. Unfortunately, I never came up with patch, nor have anyone else. Xorg server really uses pthreads when doing DRM and HAL brings in libthr dependency only as an accident. Try Ports/139011 - this adds an option to enable GLX TLS - which appears to be the underlying problem. GLX TLS, just plain does not work on FreeBSD. It has to be enabled in both the server and mesa and just makes bad things happen. I can make it all build, but having it actually work is a whole other matter. robert. http://www.freebsd.org/cgi/query-pr.cgi?pr=139011 -- Robert Noland rnol...@freebsd.org FreeBSD ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: freebsd7 (and 8), radeon, xorg-server - deadlock or so
On Wed, 2010-02-10 at 22:05 +0100, Martin Kristensen wrote: On Wed, 10 Feb 2010 20:33:46 +0200 Andriy Gapon a...@icyb.net.ua wrote: on 10/02/2010 20:29 Vitaly Magerya said the following: Robert Noland wrote: It is not, and yes I use WITHOUT_HAL. Currently disabling DRI helps; should I try rebuilding xorg-server with HAL? Yes, you can still disable hal at runtime by setting AutoAddDevices Off in xorg.conf. Seems to work with HAL. I've long thought that xorg server should be linked with libthr regardless of HAL option. Unfortunately, I never came up with patch, nor have anyone else. Xorg server really uses pthreads when doing DRM and HAL brings in libthr dependency only as an accident. This is my first post to this list, so hello all. I have been running with NoAccel for a long time, since disabling DRI alone would cause a complete deadlock (screen to standby, no ssh, no response to keyboard, etc.). However, I rebuilt xorg-server with HAL support, and now simply disabling DRI allows me to start X. The card is RV790 based. Is that an HD5xxx? robert. -- Robert Noland rnol...@freebsd.org FreeBSD ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: freebsd7 (and 8), radeon, xorg-server - deadlock or so
On Wed, 2010-02-10 at 22:05 +0100, Martin Kristensen wrote: On Wed, 10 Feb 2010 20:33:46 +0200 Andriy Gapon a...@icyb.net.ua wrote: on 10/02/2010 20:29 Vitaly Magerya said the following: Robert Noland wrote: It is not, and yes I use WITHOUT_HAL. Currently disabling DRI helps; should I try rebuilding xorg-server with HAL? Yes, you can still disable hal at runtime by setting AutoAddDevices Off in xorg.conf. Seems to work with HAL. I've long thought that xorg server should be linked with libthr regardless of HAL option. Unfortunately, I never came up with patch, nor have anyone else. Xorg server really uses pthreads when doing DRM and HAL brings in libthr dependency only as an accident. This is my first post to this list, so hello all. I have been running with NoAccel for a long time, since disabling DRI alone would cause a complete deadlock (screen to standby, no ssh, no response to keyboard, etc.). However, I rebuilt xorg-server with HAL support, and now simply disabling DRI allows me to start X. The card is RV790 based. Just checked... This card should work with Accel and DRI... At least on -CURRENT with updated ports. Check UPDATING, and set WITHOUT_NOUVEAU to get correct version of libdrm. robert. -- Robert Noland rnol...@freebsd.org FreeBSD ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: freebsd7 (and 8), radeon, xorg-server - deadlock or so
On Wed, 2010-02-10 at 23:43 +0100, Martin Kristensen wrote: On Wed, 10 Feb 2010 16:01:58 -0600 Robert Noland rnol...@freebsd.org wrote: On Wed, 2010-02-10 at 22:05 +0100, Martin Kristensen wrote: On Wed, 10 Feb 2010 20:33:46 +0200 Andriy Gapon a...@icyb.net.ua wrote: on 10/02/2010 20:29 Vitaly Magerya said the following: Robert Noland wrote: It is not, and yes I use WITHOUT_HAL. Currently disabling DRI helps; should I try rebuilding xorg-server with HAL? Yes, you can still disable hal at runtime by setting AutoAddDevices Off in xorg.conf. Seems to work with HAL. I've long thought that xorg server should be linked with libthr regardless of HAL option. Unfortunately, I never came up with patch, nor have anyone else. Xorg server really uses pthreads when doing DRM and HAL brings in libthr dependency only as an accident. This is my first post to this list, so hello all. I have been running with NoAccel for a long time, since disabling DRI alone would cause a complete deadlock (screen to standby, no ssh, no response to keyboard, etc.). However, I rebuilt xorg-server with HAL support, and now simply disabling DRI allows me to start X. The card is RV790 based. Just checked... This card should work with Accel and DRI... At least on -CURRENT with updated ports. Check UPDATING, and set WITHOUT_NOUVEAU to get correct version of libdrm. robert. I am on -STABLE built on Jan. 19. I updated mesa today (to libdrm-2.4.17), and rebuilt xorg-server and drivers. I have WITHOUT_NOUVEAU=YES in /etc/make.conf. pkg_info reports libGL-7.6.1. Is that 8-STABLE or 7? 8 should work, and I think 7 should as well, but just checking. 6 won't work. I have tried loading radeon.ko manually before startx. What are the results? If things are not working, I'll want to see your xorg.conf, xorg.log, pciconf -lvb and a sysctl hw.dri with X started if you can get it. robert. If it will help, I can switch to -CURRENT to see if that changes anything. Martin PS. Robert, in researching this I got some idea of the effort you put into this, thanks! -- Robert Noland rnol...@freebsd.org FreeBSD ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: freebsd7, radeon, xorg-server - deadlock or so
On Wed, 2010-02-10 at 01:36 +0100, O. Hartmann wrote: On 02/10/10 00:24, Oliver Pinter wrote: Hi all! After updated the xorg* and dri* and dependency, the system going to deadlock at second start of xserver. I think it is not an uniqe issue, as others wrote them at freebsd-x11: http://lists.freebsd.org/pipermail/freebsd-x11/2010-February/009370.html The symptoms: * independent from enabled or disabled DRI or GLX, first I think, this is the error, but not * the system going to deadlock state * no coredumps of xorgs * no panic, but the system is unusuable * independent from the driver: probed the radeon and radeonhd driver * independent from the WITHOUT_NOUVEAU or WITH_NOUVEAU compile options (make.conf) * the system is: FreeBSD peonia.teteny.bme.hu 7.3-PRERELEASE FreeBSD 7.3-PRERELEASE #29 r203612+fa83fdf: Mon Feb 8 02:11:08 CET 2010 r...@peonia.teteny.bme.hu:/usr/obj/usr/src/sys/stable amd64 ___ freebsd-stable@freebsd.org mailing list, http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org I had a similar freezing on several FreeBSD 8.0 boxes with either 'radeon' or 'radeonhd/radeonhd-devel' with recent ports. With more expensive graphics cards, like HD4830, HD4850 we never had the issue, but with smaller cards, like HD4670. HD4670 never worked. HD4770 cards work with explicit set option DRI OFF As far as I know, WITHOUT_NOUVEAU does have no effect on the current ports, since it is reported in ports/UPDATING, it prevents building nouveau driver which is broken when using newer libdrm/dri and libGLUT, but those new ports do not seem to be merged into the tree. The situation is heavily unsatisfying, since one need an expensive AMD/ATi Radeon card to gain non-3D poor functionality, where a cheaper one should be do the same - but the cheaper ones don't work. Even if one uses AMD64, the situattion is worse and I have no reason using Linux-driver on a FreeBSD box. Hope the situation gets cleared in the nearest future. It's a kind of deadlock. As I said, either spenig a lot of money for a working RV770 based AMD graphics card with poor functionality or nothing so far, since most smaller RV730 chips aren't supported properly by the most recent drivers. I'm only aware of one issue which leads to corruption. I have patches that resolve that issue which are not yet committed. If your are experiencing lockups with DRI disabled, then something very strange is going on and you will need to provide more details. I don't remember exactly what drm code I have committed to 7 right now, but it should be fairly current as I don't think I have much in the way of outstanding MFCs. The current drm and radeon drivers work on every card that I have, which in the r600 class are HD 3650,3850,4650. robert. Regards, Oliver ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org -- Robert Noland rnol...@freebsd.org FreeBSD ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: booting off GPT partitions
On Wed, 2010-01-27 at 20:23 -0600, Brooks Davis wrote: On Thu, Jan 28, 2010 at 12:27:54AM +0100, Dimitry Andric wrote: On 2010-01-27 22:27, John Baldwin wrote: GPT was defined along with EFI, so many folks assume that you have to use EFI to boot a GPT-labelled disk. However, FreeBSD has its own BIOS-based bootstrap that can handle GPT-labelled disks. I doubt the SuperMicro tech is familiar with that case. I thought I heard that some folks had added GPT support to grub as well. However, this won't boot disks larger than 2TiB, right? At least not without BIOS support... You won't be able to boot from a partition more than 2TiB in, but you should still be able to boot as long as you boot from the front part of the disk. John or Marcel can correct me, but I don't think that this is an issue. The bootstrap is located in the pmbr in sector 0 and the GPT headers and tables are in sectors 1 - 34. The bootstrap code knows how to read the GPT tables and can deal with 2 tb lba's. So, as long as you can successfully load the bootstrap code from sector 0, all *should* be good. robert. -- Brook -- Robert Noland rnol...@freebsd.org FreeBSD ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Loader, MBR and the boot process
On Mon, 2010-01-25 at 09:45 +, Matthew Seaman wrote: Andriy Gapon wrote: on 25/01/2010 04:41 Robert Noland said the following: On Mon, 2010-01-25 at 07:57 +1100, Mark Andrews wrote: offset The offset of the start of the partition from the beginning of the drive in sectors, or * to have bsdlabel calculate the correct offset to use (the end of the previous partition plus one, ignor- ing partition `c'. For partition `c', * will be interpreted as an offset of 0. The first partition should start at offset 16, because the first 16 sectors are reserved for metadata. Ok, now this has my attention... My gut feeling right now is that this is a bug in geom_part_bsd. I don't understand why the label isn't protected. (Adding -b 16 when adding the swap partition fixes this) Another project to goes on my list... If anyone knows why this is done like this... please share. I presume that this is for purely historic reasons. I believe this has been known about since 5.x days: http://www.freebsd.org/cgi/query-pr.cgi?pr=72812 As far as I recall, sometime around 6.1-RELEASE this should have been fixed. It certainly seems to be the case that it is harmless to have a plain swap partition start at offset 0, but anything else, like encrypted swap or putting a filesystem there needs the 16 sector offset. When the first partition (whatever it is), starts at offset 0, if you dd into that partition you wipe out the label entirely, which just doesn't make sense to me. Trying to manage this in the file system code and the swap pager or whatever other consumer might make use of the partition seems like madness to me. robert. Cheers, Matthew -- Robert Noland rnol...@freebsd.org FreeBSD ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Loader, MBR and the boot process
___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org -- Robert Noland rnol...@freebsd.org FreeBSD ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 8.0-RELEASE / gpart / GPT / marking a partition as active
On Tue, 2010-01-19 at 19:11 +0200, Dan Naumov wrote: It seems that quite a few BIOSes have serious issues booting off disks using GPT partitioning when no partition present is marked as active. See http://www.freebsd.org/cgi/query-pr.cgi?pr=115406cat=bin for a prime example. In 8.0-RELEASE, using gpart, setting a slice as active in MBR partitioning mode is trivial, ie: gpart set -a active -i 1 DISKNAME However, trying to do the same thing with GPT partitioning yields no results: gpart set -a active -i 1 DISKNAME gpart: attrib 'active': Device not configured As a result of this issue, I can configure and make a succesfull install using GPT in 8.0, but I cannot boot off it using my Intel D945GCLF2 board. I have the same board... I have found this discussion from about a month ago: http://www.mail-archive.com/freebsd-stable@freebsd.org/msg106918.html where Robert mentions that gpart set -a active -i 1 is no longer needed in 8-STABLE, because the pmbr will be marked as active during the installation of the bootcode. Is there anything I can do to archieve the same result in 8.0-RELEASE or is installing from a snapshop of 8-STABLE my only option? Prior to fixing gpart to take care of this, I used fdisk to set the active partition. gpart knows the disk is GPT and GPT doesn't have an active parameter, so the above command doesn't (perhaps never) worked. Basically, an fdisk -a /dev/devX is what you want... robert. Thanks. - Sincerely, Dan Naumov -- Robert Noland rnol...@freebsd.org FreeBSD ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: install FreeBSD 8 on disk where windows7 made a gpt
On Tue, 2009-12-29 at 20:05 -0200, Nenhum_de_Nos wrote: hail, I have Windows7 alone in a disk, and now I'd like to install FreeBSD 8 on it. when I boot from USB disk, the partitioner says there is no partitions on it. then I read about: http://wiki.freebsd.org/RootOnZFS/GPTZFSBoot and got to the fixit part. then gpt show ad10 says also there is no gpt in there. is there any way to deal with this ? There are some fixes in 8-STABLE that I don't think I got into 8.0. Those fixed reading of GPT headers written by opensolaris. I haven't seen the GPT headers written by Win7. If you want to dd if=/dev/ad10 of=header-dump.bin bs=512 count=34 and send that to me, I can take a look at what is written. robert. thanks, matheus -- Robert Noland rnol...@freebsd.org FreeBSD ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: freebsd / gpt boot
On Tue, 2009-12-15 at 17:11 -0500, Adam Jacob Muller wrote: On Dec 14, 2009, at 10:46 AM, Robert Noland wrote: On Sun, 2009-12-13 at 23:21 +0100, Rolf G Nielsen wrote: Adam Jacob Muller wrote: Hi, I'm trying to setup a system with a very large RAID array (total ~10TB), I would ideally like to have the system boot directly off that 10TB array, so i'm trying to get the system setup with GPT but running into an issue. The initial pre-loader (boot0 I think? -- i'm not sure what this is called) is unable to find loader at /boot/loader nor can it load /boot/kernel/kernel Is the partitioning done correctly (have you created a small boot partition, 15 sectors is enough for booting from ufs, but the tutorials I've found deal mainly with booting from zfs and they recommend 128 sectors to make future bootcode changes easier)? You will need to be doing all of this from a current 8-STABLE. One bug in dealing with larger zfs raidz volumes was fixed and made it into 8.0. Another, which deals with GPT/ZFS and large volumes did not make it and only exists in 8-STABLE, iirc. Also, with the gptzfsboot code from -STABLE, it will request to load /boot/zfsloader by default (and LOADER_ZFS_SUPPORT is no longer required). gpart add -b 34 -s 128 -t freebsd-boot -i 1 da0 Have you embedded the correct boot code? gpart bootcode -b /boot/pmbr -p /boot/gptboot -i 1 da0 (for booting from ufs). or gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 da0 (for booting from zfs). You may also need to set it active by gpart set -a active -i 1 da0 The above step is no longer needed on -STABLE, the pmbr will be marked active when you install bootcode. Robert, Do either of these bugs affect GPT/UFS, which is what I am using here. I thought that one of them was relevant, but looking back at the patch, I believe that it only impacted gpt + zfs. robert. These bugs are affecting the actual older versions of the tools (IE using the gpart from an 8.0-pre or earlier could cause issues like this)? Also, perhaps not coincidentally, booting the FreeBSD memstick image produces the same error (boot0 can't find loader). -Adam robert. And of course, substitute your arrays device node for da0 in my examples. Copying /boot/loader to /loader allows me to enter /loader at the boot: prompt and the loader will load, however, its unable to load the kernel. If I do an ls at the loader prompt I can see boot listed as a directory (with a d before it) Trying to do ls boot inexplicably it says boot: not a directory re-applying my /boot/loader.conf settings (for some reason vfs.root.mountfrom=ufs:/dev/label/root is required, or else I get a mountroot) and then: load /kernel boot does work, and lets the system boot normally and everything is as expected (/boot is a directory etc). Anyone have any ideas about either of these things (the vfs.root.mountfrom is minor i guess but i'm curious if they are related?) Thanks in advance, -Adam ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org -- Robert Noland rnol...@freebsd.org FreeBSD ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org -- Robert Noland rnol...@freebsd.org FreeBSD ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Dell D830, nVidia and FreeBSD-8/amd64
On Tue, 2009-12-15 at 15:51 -0500, John Baldwin wrote: On Tuesday 15 December 2009 2:47:03 pm Jonathan Chen wrote: On Tue, Dec 15, 2009 at 10:18:36AM -0500, John Baldwin wrote: On Monday 14 December 2009 9:37:51 pm Jonathan Chen wrote: On Mon, Dec 14, 2009 at 10:46:27AM -0500, John Baldwin wrote: On Sunday 13 December 2009 2:19:05 pm Jonathan Chen wrote: Hi, This is a general rehash of a problem that I've been having with my Dell Latitude D830 with an nVidia Quadro NVS 140M internal graphics card. I've been using the XOrg's vesa driver ever since something in the code rendered the nvidia driver inoperable in 7-STABLE sometime mid last year. With nVidia's new 195.22 (BETA) drivers, I had hoped that I could bypass the problem. Unfortunately, I seem to be experiencing the same problem as described in the following thread: http://www.nvnews.net/vbulletin/showthread.php?t=142391 which appears to be implying that something in the kernel is interfering with memory allocation. Would it be possible for someone with deeper kernel-fu be able to take a look at this issue? Do you have a verbose dmesg available? I've attached a dmesg with a verbose boot. I hope this is what you're looking for. Ok, can you grab the output of 'devinfo -r' and 'devinfo -ur'? I suspect that when the bridge allocates the prefetch resource range from the parent it is failing somehow. For a quick hack try something like this: [...] I've attatched the requested output. Unfortunately, the patch didn't result in anything different. I/O memory addresses: 0xdff0-0xe06f (acpi0) 0xe070-0xe0700fff (cbb0) 0xe0701000-0xf3ff (root0) The root0 range is ok (it really means free), but the cbb0 and acpi0 ranges here conflict with the prefetch BAR for the video adapter. The cbb0 one I think is because that range is free when cbb0 needs to allocate a fresh range of resources. The real bug is why your BIOS thinks that a system resource is using 0xe000-0xe06f which conflicts with the nvidia card. You can try disabling ACPI's system-resource handling (set debug.acpi.disabled=sysres from the loader). I'm not sure what is the root issue, but we have seen system resource conflicts like this reasonably often with Nvidia graphics. I've never some across this issue with any other display adapter. But I've had at least a handful of reports of noveau not working due to this issue. robert. -- Robert Noland rnol...@freebsd.org FreeBSD ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: freebsd / gpt boot
On Sun, 2009-12-13 at 23:21 +0100, Rolf G Nielsen wrote: Adam Jacob Muller wrote: Hi, I'm trying to setup a system with a very large RAID array (total ~10TB), I would ideally like to have the system boot directly off that 10TB array, so i'm trying to get the system setup with GPT but running into an issue. The initial pre-loader (boot0 I think? -- i'm not sure what this is called) is unable to find loader at /boot/loader nor can it load /boot/kernel/kernel Is the partitioning done correctly (have you created a small boot partition, 15 sectors is enough for booting from ufs, but the tutorials I've found deal mainly with booting from zfs and they recommend 128 sectors to make future bootcode changes easier)? You will need to be doing all of this from a current 8-STABLE. One bug in dealing with larger zfs raidz volumes was fixed and made it into 8.0. Another, which deals with GPT/ZFS and large volumes did not make it and only exists in 8-STABLE, iirc. Also, with the gptzfsboot code from -STABLE, it will request to load /boot/zfsloader by default (and LOADER_ZFS_SUPPORT is no longer required). gpart add -b 34 -s 128 -t freebsd-boot -i 1 da0 Have you embedded the correct boot code? gpart bootcode -b /boot/pmbr -p /boot/gptboot -i 1 da0 (for booting from ufs). or gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 da0 (for booting from zfs). You may also need to set it active by gpart set -a active -i 1 da0 The above step is no longer needed on -STABLE, the pmbr will be marked active when you install bootcode. robert. And of course, substitute your arrays device node for da0 in my examples. Copying /boot/loader to /loader allows me to enter /loader at the boot: prompt and the loader will load, however, its unable to load the kernel. If I do an ls at the loader prompt I can see boot listed as a directory (with a d before it) Trying to do ls boot inexplicably it says boot: not a directory re-applying my /boot/loader.conf settings (for some reason vfs.root.mountfrom=ufs:/dev/label/root is required, or else I get a mountroot) and then: load /kernel boot does work, and lets the system boot normally and everything is as expected (/boot is a directory etc). Anyone have any ideas about either of these things (the vfs.root.mountfrom is minor i guess but i'm curious if they are related?) Thanks in advance, -Adam ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org -- Robert Noland rnol...@freebsd.org FreeBSD ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: MTRR failure revisited (nVidia) 8-STABLE/RELEASE
On Sat, 2009-12-12 at 20:08 -0800, Chris H wrote: On Sat, December 12, 2009 6:36 am, Robert Noland wrote: On Sat, 2009-12-12 at 03:47 -0800, Chris H wrote: Greetings, I brought this same error to the list back in May 2009. Under: failed to set mtrr: invalid argument. Well, I'm back using the same card: GeForce4 MX 440-SE - VideoRam 65536 - BusID PCI:1:3:0. The driver is different, I'm using: nvidia-driver-96.43.13 out of ports on a custom 8-STABLE kernel. Xorg starts up, and produces a desktop. But it's dog slow UPDATE: Disabling HAL /greatly/ increased performance eg; hal_enable=YES -- hal_enable=NO in /etc/rc.conf More specifically, response times are now closer to what one would anticipate/ expect now that HAL has been dis-abled in rc.conf. , and the nvidia driver emits the following error: NVIDIA: failed to set MTRR 0xf000, 0M (write-combining) several times. I understand John Baldwin provided some invaluable help some time ago: http://lists.freebsd.org/pipermail/freebsd-hackers/2006-June/016995.html and I was wondering if anyone has gained any further insight with these cards, and how to better interface them in BSD. Last I spoke on the topic, I was informed that the memory was basically untouchable - or perhaps in other words; can't be manipulated. Has this changed? Surely someone else has had to deal with this besides me. It seems crazy to spend a boat load of $$ on these high performers, and not be able to use them on a high performing OS - no? :) Sure, the one I'm working with now is legacy. But I have 3 near new, top of their line cards, and thus far it appears that if I ever hope to use them, I'll be forced to... hack, choke.. spin up a WIN CD. :( Thank you for all your time, consideration, and insight. Greetings Robert, and thank you for taking the time to respond. The mtrr issue has to do with the system / bios, not the graphics card. While I've not used the blob driver, the issue in Nouveau and other drm drivers is that on many systems if you run memcontrol list, you will see a line something like this: 0x0/0x1 BIOS write-back set-by-firmware active I see the following (condensed for brevity): 0x0/0x1 BIOS write-back fixed-base fixed-length set-by-firmware active 0x1/0x1-0x7/0x1 BIOS write-back fixed-base fixed-length set-by-firmware active 0x8/0x4000 BIOS-0x9c000/0x4000 write-back fixed-base fixed-length set-by-firmware active 0xa/0x4000-0xbc000/0x4000 BIOS uncacheable fixed-base fixed-length set-by-firmware active 0xc/0x1xc7000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xc8000/0x1000-0xff000/0x1000 BIOS uncacheable fixed-base fixed-length set-by-firmware active 0x0/0x4000 BIOS write-back set-by-firmware active The above entry is the one that causes setting write-combine MTRR to fail. 0xe000/0x2000 BIOS uncacheable set-by-firmware active While I could pull the BIOS out of it's socket after POST. I don't suppose I could read it's contents to file, and then allow manipulation of the regions currently off limits? This is more easily achieved in our MTRR code I expect, certainly than BIOS hacking all of the effected machines. Frankly, all of my more modern machines have this issue. This says that all of memory defaults to write-back. We aren't allowed to overlap write-combined on top of write-back, so the setting of mtrr fails. Isn't it /best/ to choose write-back, so as to mark the memory dirty? I /could/ choose write-ahead, or write-through. I've looked at ways to try to fix this in the past, but generally found it more practical to use PAT than try to override/fix bios behavior. Marius Nünnerich also mentioned this in a response to this thread. Would you be willing to share any additional information, based on your experiences using PAT? PAT and MTRR both allow for the setting of cache attributes for a range of memory. For MTRR, there are a certain number of variable range registers in a given CPU which allow the setting of global cache attributes for a given memory range. There are a number of rules about what memory types may overlap though, so having that entry that covers all of memory means that setting MTRR to anything other than uncached will always fail. PAT is less restrictive in this regard and a table exists in the intel documentation showing the effective cache method for various combinations of MTRR/PAT. The difficulty with PAT is that it is an attribute of the individual page mapping and so all mappings of the same physical region of memory need to have the same PAT type set. jhb@, alc@ and I (my contribution has mostly consisted of whining and testing) have recently (over the last year at least) been adding the ability to handle allowing userspace mappings of memory regions to be mapped with consistent PAT attributes. This was also
Re: MTRR failure revisited (nVidia) 8-STABLE/RELEASE
On Sun, 2009-12-13 at 06:53 -0800, Chris H wrote: On Sun, December 13, 2009 6:04 am, Robert Noland wrote: On Sat, 2009-12-12 at 20:08 -0800, Chris H wrote: On Sat, December 12, 2009 6:36 am, Robert Noland wrote: On Sat, 2009-12-12 at 03:47 -0800, Chris H wrote: Greetings, I brought this same error to the list back in May 2009. Under: failed to set mtrr: invalid argument. Well, I'm back using the same card: GeForce4 MX 440-SE - VideoRam 65536 - BusID PCI:1:3:0. The driver is different, I'm using: nvidia-driver-96.43.13 out of ports on a custom 8-STABLE kernel. Xorg starts up, and produces a desktop. But it's dog slow UPDATE: Disabling HAL /greatly/ increased performance eg; hal_enable=YES -- hal_enable=NO in /etc/rc.conf More specifically, response times are now closer to what one would anticipate/ expect now that HAL has been dis-abled in rc.conf. , and the nvidia driver emits the following error: NVIDIA: failed to set MTRR 0xf000, 0M (write-combining) several times. I understand John Baldwin provided some invaluable help some time ago: http://lists.freebsd.org/pipermail/freebsd-hackers/2006-June/016995.html and I was wondering if anyone has gained any further insight with these cards, and how to better interface them in BSD. Last I spoke on the topic, I was informed that the memory was basically untouchable - or perhaps in other words; can't be manipulated. Has this changed? Surely someone else has had to deal with this besides me. It seems crazy to spend a boat load of $$ on these high performers, and not be able to use them on a high performing OS - no? :) Sure, the one I'm working with now is legacy. But I have 3 near new, top of their line cards, and thus far it appears that if I ever hope to use them, I'll be forced to... hack, choke.. spin up a WIN CD. :( Thank you for all your time, consideration, and insight. Greetings Robert, and thank you for taking the time to respond. The mtrr issue has to do with the system / bios, not the graphics card. While I've not used the blob driver, the issue in Nouveau and other drm drivers is that on many systems if you run memcontrol list, you will see a line something like this: 0x0/0x1 BIOS write-back set-by-firmware active I see the following (condensed for brevity): 0x0/0x1 BIOS write-back fixed-base fixed-length set-by-firmware active 0x1/0x1-0x7/0x1 BIOS write-back fixed-base fixed-length set-by-firmware active 0x8/0x4000 BIOS-0x9c000/0x4000 write-back fixed-base fixed-length set-by-firmware active 0xa/0x4000-0xbc000/0x4000 BIOS uncacheable fixed-base fixed-length set-by-firmware active 0xc/0x1xc7000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xc8000/0x1000-0xff000/0x1000 BIOS uncacheable fixed-base fixed-length set-by-firmware active 0x0/0x4000 BIOS write-back set-by-firmware active Hello Robert, and thank you for your thoughtful response. The above entry is the one that causes setting write-combine MTRR to fail. 0xe000/0x2000 BIOS uncacheable set-by-firmware active While I could pull the BIOS out of it's socket after POST. I don't suppose I could read it's contents to file, and then allow manipulation of the regions currently off limits? This is more easily achieved in our MTRR code I expect, certainly than BIOS hacking all of the effected machines. Frankly, all of my more modern machines have this issue. Ahhh, OK. This says that all of memory defaults to write-back. We aren't allowed to overlap write-combined on top of write-back, so the setting of mtrr fails. Isn't it /best/ to choose write-back, so as to mark the memory dirty? I /could/ choose write-ahead, or write-through. I've looked at ways to try to fix this in the past, but generally found it more practical to use PAT than try to override/fix bios behavior. Marius Nünnerich also mentioned this in a response to this thread. Would you be willing to share any additional information, based on your experiences using PAT? PAT and MTRR both allow for the setting of cache attributes for a range of memory. For MTRR, there are a certain number of variable range registers in a given CPU which allow the setting of global cache attributes for a given memory range. There are a number of rules about what memory types may overlap though, so having that entry that covers all of memory means that setting MTRR to anything other than uncached will always fail. PAT is less restrictive in this regard and a table exists in the intel documentation showing the effective cache method for various combinations of MTRR/PAT. The difficulty with PAT is that it is an attribute of the individual page mapping and so all mappings of the same physical region of memory need to have the same PAT type set
Re: MTRR failure revisited (nVidia) 8-STABLE/RELEASE
On Sat, 2009-12-12 at 03:47 -0800, Chris H wrote: Greetings, I brought this same error to the list back in May 2009. Under: failed to set mtrr: invalid argument. Well, I'm back using the same card: GeForce4 MX 440-SE - VideoRam 65536 - BusID PCI:1:3:0. The driver is different, I'm using: nvidia-driver-96.43.13 out of ports on a custom 8-STABLE kernel. Xorg starts up, and produces a desktop. But it's dog slow, and the nvidia driver emits the following error: NVIDIA: failed to set MTRR 0xf000, 0M (write-combining) several times. I understand John Baldwin provided some invaluable help some time ago: http://lists.freebsd.org/pipermail/freebsd-hackers/2006-June/016995.html and I was wondering if anyone has gained any further insight with these cards, and how to better interface them in BSD. Last I spoke on the topic, I was informed that the memory was basically untouchable - or perhaps in other words; can't be manipulated. Has this changed? Surely someone else has had to deal with this besides me. It seems crazy to spend a boat load of $$ on these high performers, and not be able to use them on a high performing OS - no? :) Sure, the one I'm working with now is legacy. But I have 3 near new, top of their line cards, and thus far it appears that if I ever hope to use them, I'll be forced to... hack, choke.. spin up a WIN CD. :( Thank you for all your time, consideration, and insight. The mtrr issue has to do with the system / bios, not the graphics card. While I've not used the blob driver, the issue in Nouveau and other drm drivers is that on many systems if you run memcontrol list, you will see a line something like this: 0x0/0x1 BIOS write-back set-by-firmware active This says that all of memory defaults to write-back. We aren't allowed to overlap write-combined on top of write-back, so the setting of mtrr fails. I've looked at ways to try to fix this in the past, but generally found it more practical to use PAT than try to override/fix bios behavior. I've been told that linux does apply some BIOS fixups to address this issue, which I might look into again, but I make no promises. There are also a very limited number of variable mtrr registers (7 on most hardware, iirc) for managing caching. robert. --Chris H ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org -- Robert Noland rnol...@freebsd.org FreeBSD ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: whats best pracfive for ZFS on a whole disc these days ?
On Mon, 2009-10-26 at 11:19 +, Pete French wrote: just about to build a new ZFS based system and I was wondering what the recommended way to dedicate a whole disc to ZFS is these days. Should I just give it 'da1', 'da2' etc as I have done in the past, or is it better to use GPT to create a partition over the whole disc, which is marked as being for freebsd-zfs ? Not that I have had any problems with simply using bare drives, but the phrase 'dangerously dedicated' does keep nagging at me, hence considering the GPT route :-) Others may have different opinions, but if your drives are dedicated to zfs and you don't intend to try and boot from them, I see no reason not to continue giving the whole disk to zfs. robert. cheers, -pete. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org -- Robert Noland rnol...@freebsd.org FreeBSD ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: i am desperate over some GPT tables
On Sun, 2009-10-25 at 16:44 +, Kris Weston wrote: hi Robert appreciate you having a look at this, if you need any funny noises ever, give us a shout :) i really dont know what to do as i dont have a spare box to try out solaris on and solaris wont boot fully here... i did manage to export the drives from solaris first so all *should* be well... there are three disks in the set ad4,ad6,ad8 terrabyte each - they are supposed to be two mirrors but one disk went down should still work though - well was working in solaris... as i said before it at least could read the pools from freebsd before but something has happened now where it wont... i think 4+6 are a mirror... let me know if you can shed any light... out of interest - how do you look at these dumps ? and what are you looking for ? Ok, we have a couple of options What I have done so far is to hex edit your GPT headers, though technically they are valid. Sector 2 is the GPT header and normally the header length is recorded as 92 bytes. Yours claim that the header it 512 bytes or the entire sector. The crc32 value is calculated based on byte 0 - header size. Our GPT code is performing the crc comparison based on the 92 valid bytes in the header along with 512 - 92 bytes of random memory, so the header crc fails and GEOM refuses the header. We need to fix the GPT code to handle this correctly, so you can give me a little time to fix it correctly, or we can just fix your existing GPT headers to work with our code... Before: GEOM: md6: corrupt or invalid GPT detected. GEOM: md6: GPT rejected -- may not be recoverable. After: GEOM: md6: the secondary GPT table is corrupt or invalid. GEOM: md6: using the primary only -- recovery suggested. =34 1953525101 md6 GPT (466T) 34 222 - free - (111K) 256 19535084951 !6a898cc3-1dd2-11b2-99a6-080020736631 (932G) 1953508751 163849 !6a945a3b-1dd2-11b2-99a6-080020736631 (8.0M) Hopefully I don't need to tell you proceed with caution here, but if you want to rewrite the headers, I've attached 6 files which contain the modified primary and secondary headers. The seek values below for the secondary header are calculated for your drive. Make sure that you use the correct header for the correct drive and pri/sec. dd if=headeradX-pri.dmp of=/dev/adX bs=512 seek=1 dd if=headeradX-sec.dmp of=/dev/adX bs=512 seek=1953525167 robert. thanks Kris -- )) (( c[_] 2009/10/23 Robert Noland rnol...@freebsd.org On Wed, 2009-10-21 at 13:11 +0100, Kris Weston wrote: been looking for months now, trawled google no help, i just dont understand. do you need a GPT table with zfs ? i have a pentium D 3ghz (running 64bit stable 7.2) and i cant seem to import my zpool into it exported fine on solaris , its definitely the same version (v13) but when i import into zfs it says GPT tables corrupt ? why ? and what does this mean ? please help me. please. Send me the fist 34 sectors of the disk and I will try to take a look. dd if=raw disk device of=header.dmp bs=512 count=34 robert. -- )) (( c[_] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org -- Robert Noland rnol...@freebsd.org FreeBSD ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org -- Robert Noland rnol...@freebsd.org FreeBSD headerad4-pri.dmp Description: Binary data headerad4-sec.dmp Description: Binary data headerad6-pri.dmp Description: Binary data headerad6-sec.dmp Description: Binary data headerad8-pri.dmp Description: Binary data headerad8-sec.dmp Description: Binary data ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: i am desperate over some GPT tables
On Wed, 2009-10-21 at 13:11 +0100, Kris Weston wrote: been looking for months now, trawled google no help, i just dont understand. do you need a GPT table with zfs ? i have a pentium D 3ghz (running 64bit stable 7.2) and i cant seem to import my zpool into it exported fine on solaris , its definitely the same version (v13) but when i import into zfs it says GPT tables corrupt ? why ? and what does this mean ? please help me. please. Send me the fist 34 sectors of the disk and I will try to take a look. dd if=raw disk device of=header.dmp bs=512 count=34 robert. -- )) (( c[_] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org -- Robert Noland rnol...@freebsd.org FreeBSD ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: SATA is to slow comparing with linux
On Wed, 2009-09-30 at 09:53 +0200, Oliver Lehmann wrote: Daniel O'Connor writes: In the end I got a PCI Silicon Image 3114 based controller and it worked fine. I thought about getting a controller with a SiL-Chil too because they are kinda cheap and another system I intend to use with SATA harddisks has no SATA on-board. But then I searched through the web and read many posts telling me stay away from Silicon Image controllers so I did as advised I got a Promise SATA300 TX2plus instead. I'll rune some tests with later (when I'm back home ;)) I would also be curious how that ahci driver from -CURRENT is performing relative to other implementations. robert. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org -- Robert Noland rnol...@freebsd.org FreeBSD ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: SATA is to slow comparing with linux
On Wed, 2009-09-30 at 13:17 +0200, Oliver Lehmann wrote: Robert Noland writes: On Wed, 2009-09-30 at 09:53 +0200, Oliver Lehmann wrote: I got a Promise SATA300 TX2plus instead. I'll rune some tests with later (when I'm back home ;)) I would also be curious how that ahci driver from -CURRENT is performing relative to other implementations. So there is a new driver - never heard about ahci ;) Is it sufficient to boot 8.0-RC1 livefs? It looks like ahci is not included in GENERIC so I have to load the module in the 2nd bootloader I guess. Something else like disabling the old ata driver? Or will the new driver be used automatically. I was not sure about the man page what this one means (the ataahci or the ahaci?): AHCI hardware is also supported by ataahci driver from ata(4) subsystem. If both drivers are loaded at the same time, this one will be given precedence as the more functional of the two. If the ahci driver is loaded via loader.conf it will override that ata driver. The ahci driver is being actively worked on, so I'm not certain how much of the new code is in RC1, but that is a start. robert. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org -- Robert Noland rnol...@freebsd.org FreeBSD ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Excessivly cheap USB device issue
On Tue, 2009-09-29 at 14:35 +0930, Daniel O'Connor wrote: On Mon, 28 Sep 2009, Mike Tancsa wrote: I also have a similar device, which I've been messing with a bit the last couple of days. In your case, it isn't seeing the media, just the drive. I've had to try various combinations of unplugging the adapter from usb, inserting the media then plugging it back in. It does seem to work fairly reliably if you boot with the media already inserted, but it doesn't seem to detect media change at all. I get around it (on my cheap reader) by always doing a cat /dev/null /dev/da1 whever I change or insert new media into the reader That seems to work with the gear I have 99% of the time. Hmm OK, I sort of expected fdisk da1 to fail straightaway though (it takes ~30 seconds to fail for me). I have unplugged it for now, it interacts annoyingly with SANE because that scans the SCSI bus(es) looking for scanner and each umass takes 30+ seconds to fail. FWIW, on yesterdays kernel, mine seems to be working properly and detecting media change. I'm not sure what change helped. Note that I am running -CURRENT. robert. -- Robert Noland rnol...@freebsd.org FreeBSD ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Excessivly cheap USB device issue
On Tue, 2009-09-29 at 23:16 +1300, Andrew Thompson wrote: On Tue, Sep 29, 2009 at 05:11:24AM -0500, Robert Noland wrote: On Tue, 2009-09-29 at 14:35 +0930, Daniel O'Connor wrote: On Mon, 28 Sep 2009, Mike Tancsa wrote: I also have a similar device, which I've been messing with a bit the last couple of days. In your case, it isn't seeing the media, just the drive. I've had to try various combinations of unplugging the adapter from usb, inserting the media then plugging it back in. It does seem to work fairly reliably if you boot with the media already inserted, but it doesn't seem to detect media change at all. I get around it (on my cheap reader) by always doing a cat /dev/null /dev/da1 whever I change or insert new media into the reader That seems to work with the gear I have 99% of the time. Hmm OK, I sort of expected fdisk da1 to fail straightaway though (it takes ~30 seconds to fail for me). I have unplugged it for now, it interacts annoyingly with SANE because that scans the SCSI bus(es) looking for scanner and each umass takes 30+ seconds to fail. FWIW, on yesterdays kernel, mine seems to be working properly and detecting media change. I'm not sure what change helped. Note that I am running -CURRENT. Was that after the sync to Hans's repo? There were around 20 commits so if anyone can narrow it down to a single rev then it may be able to be merged. Looks like I'm at r197575, now. robert. Andrew ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org -- Robert Noland rnol...@freebsd.org FreeBSD ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Excessivly cheap USB device issue
On Mon, 2009-09-28 at 00:09 +0930, Daniel O'Connor wrote: I have a very cheap USB CF/SD/SM/MS connected to an 8.0-RC1 system and it is detected, ie.. Sep 27 14:29:18 midget kernel: da0 at umass-sim0 bus 0 target 0 lun 0 Sep 27 14:29:18 midget kernel: da0: Generic USB SD Reader 1.00 Removable Direct Access SCSI-0 device Sep 27 14:29:18 midget kernel: da0: 40.000MB/s transfers Sep 27 14:29:18 midget kernel: da0: Attempt to query device size failed: NOT READY, Medium not present Sep 27 14:29:18 midget kernel: (probe7:umass-sim0:0:0:1): TEST UNIT READY. CDB: 0 20 0 0 0 0 Sep 27 14:29:18 midget kernel: (probe7:umass-sim0:0:0:1): CAM Status: SCSI Status Error Sep 27 14:29:18 midget kernel: (probe7:umass-sim0:0:0:1): SCSI Status: Check Condition Sep 27 14:29:18 midget kernel: (probe7:umass-sim0:0:0:1): NOT READY csi:0,aa,55,40 asc:3a,0 Sep 27 14:29:18 midget kernel: (probe7:umass-sim0:0:0:1): Medium not present Sep 27 14:29:18 midget kernel: (probe7:umass-sim0:0:0:1): Unretryable error Sep 27 14:29:18 midget kernel: da1 at umass-sim0 bus 0 target 0 lun 1 Sep 27 14:29:18 midget kernel: da1: Generic USB CF Reader 1.01 Removable Direct Access SCSI-0 device Sep 27 14:29:18 midget kernel: da1: 40.000MB/s transfers Sep 27 14:29:18 midget kernel: da1: Attempt to query device size failed: NOT READY, Medium not present If I connect a CF card to da1 and run 'fdisk da1' I get.. [midget 0:06] ~ fdisk da1 load: 0.29 cmd: fdisk 69630 [cgticb] 1.50r 0.00u 0.00s 0% 1160k load: 0.19 cmd: fdisk 69630 [cbwait] 24.42r 0.00u 0.00s 0% 1160k load: 0.19 cmd: fdisk 69630 [cbwait] 27.01r 0.00u 0.00s 0% 1160k fdisk: unable to get correct path for da1: Input/output error [midget 0:05] ~ sudo usbconfig -u 5 -a 2 dump_device_desc ugen5.2: Mass Storage Device Generic at usbus5, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON bLength = 0x0012 bDescriptorType = 0x0001 bcdUSB = 0x0200 bDeviceClass = 0x bDeviceSubClass = 0x bDeviceProtocol = 0x bMaxPacketSize0 = 0x0040 idVendor = 0x058f idProduct = 0x6362 bcdDevice = 0x0129 load: 0.21 cmd: usbconfig 69643 [WCTRL] 1.73r 0.00u 0.00s 0% 1080k iManufacturer = 0x0001 retrieving string failed load: 0.19 cmd: usbconfig 69643 [WCTRL] 8.56r 0.00u 0.00s 0% 1104k iProduct = 0x0002 retrieving string failed iSerialNumber = 0x0003 retrieving string failed bNumConfigurations = 0x0001 Perhaps some quirk would help but I'm not sure which one :) I also have a similar device, which I've been messing with a bit the last couple of days. In your case, it isn't seeing the media, just the drive. I've had to try various combinations of unplugging the adapter from usb, inserting the media then plugging it back in. It does seem to work fairly reliably if you boot with the media already inserted, but it doesn't seem to detect media change at all. robert. -- Robert Noland rnol...@freebsd.org FreeBSD ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Signing Request
On Wed, 2009-09-23 at 11:40 -0400, J. Hellenthal wrote: If you do not need to pgp/gpg sign email message to the lists please don't. I know I probably don't have your pgp public key and a lot more users probably do not either. Please use your best judgment. http://www.freebsd.org/doc/pgpkeyring.txt Frankly, I always sign messages, except that evolution / gpg support is currently a bit broken... robert. Thank you and best regards. -- Robert Noland rnol...@freebsd.org FreeBSD ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 8.0-BETA-4: no mouse or keyboard in X.
On Sun, 2009-09-13 at 15:29 +1000, Dave Hardman wrote: I upgraded from 7.2 to 8.0-BETA4. Now X will not receive input from either the mouse or keyboard. When this has happened in 7.1 or 7.2 it was fixed by running hal. The keyboard, mouse and hal are all working. I did not configure X, the xorg.conf file was auto generated when X was first started. I have tried a few things; new xorg.conf with Xorg -configure, putting config files, which I found in a mailing list, in /usr/local/etc/hal/fdi/policy. Using a different window manager. Nothing worked. Theres nothing in the log files that I recognise. Xorg.log reported config/hal Adding input device AT Keyboard. Any suggestions I also noticed the fuse.ko will not load, reporting Exec format error. This suggests that you have not rebuilt your ports. At a minumum you need to rebuild fuse and hal, though I strongly suggest that you rebuild everything. robert. d...@loc:/usr/home/dave $ uname -a FreeBSD loc.alh.ost 8.0-BETA4 FreeBSD 8.0-BETA4 #0: Sun Sep 6 04:44:31 UTC 2009 r...@mason.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 Thanks Dave ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org -- Robert Noland rnol...@freebsd.org FreeBSD ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Detecting CPU throttling on over temperature
On Wed, 2009-09-09 at 17:47 +0930, Daniel O'Connor wrote: On Wed, 9 Sep 2009, Alexander Motin wrote: Daniel O'Connor wrote: On Wed, 9 Sep 2009, Alexander Motin wrote: Daniel O'Connor wrote: I recently discovered a system where the floppy drive cable was intermittently fouling the CPU fan - I believe this caused the CPU to overheat and then get throttled by the BIOS. Does anyone know if it is possible to determine if this is the case? ie is there a way to be informed if throttling has occurred? Theoretically it is possible. I know off-topic tool reporting this. Also you can just monitor CPU temperature, depending on CPU type. Monitoring CPU temperature is a bit difficult, there are a lack of tools (although I have some code it's not complete). There indeed problems with MB monitoring, as it is non-standard. But modern CPUs also include on-chip thermal sensors. For Core2Duo family coretemp module works fine and precisely. Ahh coretemp, I had forgotten about that. I did a test on the bench (on a 7.2 system) here and realised that I can't actually detect throttling. coretemp reported 72 78C but the frequency was still 2933MHz. I am pretty sure it would be throttling but I think that works by maintaining the frequency but stalling the CPU some percentage of the time. I have p4tcc loaded (in GENERIC) but it doesn't show up, I only get.. Is this a core2duo? IIRC, they generally don't go into TCC until around 100C. I did pull the c2d cpu docs at one point trying to look at cpufreq. If you are bored, you can grab the docs from intel and double check. robert. dev.cpu.0.%desc: ACPI CPU dev.cpu.0.%driver: cpu dev.cpu.0.%location: handle=\_PR_.CPU0 dev.cpu.0.%pnpinfo: _HID=none _UID=0 dev.cpu.0.%parent: acpi0 dev.cpu.0.freq: 2933 dev.cpu.0.freq_levels: 2933/35000 2566/30625 2199/26250 1833/21875 1466/17500 1099/13125 733/8750 366/4375 dev.cpu.0.cx_supported: C1/0 C2/85 dev.cpu.0.cx_lowest: C1 dev.cpu.0.cx_usage: 100.00% 0.00% dev.cpu.0.temperature: 44 dev.cpu.1.%desc: ACPI CPU dev.cpu.1.%driver: cpu dev.cpu.1.%location: handle=\_PR_.CPU1 dev.cpu.1.%pnpinfo: _HID=none _UID=0 dev.cpu.1.%parent: acpi0 dev.cpu.1.cx_supported: C1/0 C2/85 dev.cpu.1.cx_lowest: C1 dev.cpu.1.cx_usage: 100.00% 0.00% dev.cpu.1.temperature: 36 I see some odd results if I disable the fan while running 'dd if=/dev/zero bs=128k count=5000 | md5' in a loop. The throughput seems to remain the same (odd) but the CPU idle time goes up when it gets hot. The problem is that the CPU temperature is only a proxy measurement, I would much prefer to be told directly the BIOS is throttling rather than guess :) While ACPI could implement thermal throttling, AFAIK TM1/TM2 technologies of P4 and above families are working just in CPU hardware. BIOS only initializes them. OK. -- Robert Noland rnol...@freebsd.org FreeBSD ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Detecting CPU throttling on over temperature
On Wed, 2009-09-09 at 16:16 +0300, Alexander Motin wrote: Robert Noland wrote: On Wed, 2009-09-09 at 17:47 +0930, Daniel O'Connor wrote: On Wed, 9 Sep 2009, Alexander Motin wrote: Daniel O'Connor wrote: On Wed, 9 Sep 2009, Alexander Motin wrote: Daniel O'Connor wrote: I recently discovered a system where the floppy drive cable was intermittently fouling the CPU fan - I believe this caused the CPU to overheat and then get throttled by the BIOS. Does anyone know if it is possible to determine if this is the case? ie is there a way to be informed if throttling has occurred? Theoretically it is possible. I know off-topic tool reporting this. Also you can just monitor CPU temperature, depending on CPU type. Monitoring CPU temperature is a bit difficult, there are a lack of tools (although I have some code it's not complete). There indeed problems with MB monitoring, as it is non-standard. But modern CPUs also include on-chip thermal sensors. For Core2Duo family coretemp module works fine and precisely. Ahh coretemp, I had forgotten about that. I did a test on the bench (on a 7.2 system) here and realised that I can't actually detect throttling. coretemp reported 72 78C but the frequency was still 2933MHz. I am pretty sure it would be throttling but I think that works by maintaining the frequency but stalling the CPU some percentage of the time. I have p4tcc loaded (in GENERIC) but it doesn't show up, I only get.. Is this a core2duo? IIRC, they generally don't go into TCC until around 100C. I did pull the c2d cpu docs at one point trying to look at cpufreq. If you are bored, you can grab the docs from intel and double check. AFAIR C2D supports three protection technologies. When CPU is hot, it starts reducing frequency (multiplier) and voltage, alike to IEST. If it is insufficient, it starts to skip core cycles, alike to TCC. If it is still insufficient and temperature rises above about 100C, emergency shutdown happens. Your recollection is probably more accurate than mine. My brain is full, so every new doc that I read pushes something else out. robert. -- Robert Noland rnol...@freebsd.org FreeBSD ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Detecting CPU throttling on over temperature
On Wed, 2009-09-09 at 10:20 +0930, Daniel O'Connor wrote: On Wed, 9 Sep 2009, Ian Smith wrote: Does anyone know if it is possible to determine if this is the case? ie is there a way to be informed if throttling has occurred? Might be easier to hack powerd.c as an existing pretty lightweight way of monitoring CPU freq (to log or signal on detected freq lowered by throttling, say?) even if you don't need/want it to actually vary freq according to load, eg setting idle/busy shift factors to 'never/always'? Hmm, that could work. It seems odd to me that there is no direct way the BIOS can notify the OS it's throttling the CPU though. Some BIOS can and do send an ACPI event when the proc gets hot. In my experience, this was not a good thing though. The BIOS that I remember dealing with this on would continuously send the alarms, so while TCC would kick in and throttle the CPU, the event processing kept it at 100% utilization until it was powered off to cool. I have also been able to determine that TCC had kicked in by looking at the cpu frequency via sysctl and comparing that to the max frequency reported for the proc. If the BIOS sent the alarm, but throttled the rate it wouldn't have been so bad. Not that I had any active fan control on that box to do anything about it really, but TCC might have actually worked if it wasn't flooding the acpi event processor. robert. -- Robert Noland rnol...@freebsd.org FreeBSD ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: mergemaster merge left/right
On Fri, 2009-07-03 at 10:51 +0200, Dominic Fandrey wrote: I'd really like mergemaster to tell me whether the left or the right side is the new file. # $FreeBSD: src/etc/devd.conf,v 1.38. | # $FreeBSD: src/etc/devd.conf,v 1.38. Like this I have no idea which one to pick. The right hand side is always the new file. robert. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org -- Robert Noland rnol...@freebsd.org FreeBSD signature.asc Description: This is a digitally signed message part
Re: trap 12
On Fri, 2009-07-03 at 10:06 +0100, Ian J Hart wrote: Is this likely to be hardware? Details will follow if not. [copied from a screen dump] Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 01 fault virtual address = 0x0 fault code = supervisor write data, page not present instruction pointer = 0x8:0x807c6c12 stack pointer = 0x10:0x510e7890 frame pointer = 0x10:0xff00054a6c90 code segment = base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1 def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 75372 (printf) trap number = 12 panic: page fault cpuid = 1 uptime: 8m2s Cannot dump. No dump device defined. I would doubt it. Are you using drm, with the radeon driver? There are a few corner cases where this can happen. http://people.freebsd.org/~rnoland/drm_radeon-copyin-fix-try2.patch should help if this is the case. robert. -- Robert Noland rnol...@freebsd.org FreeBSD signature.asc Description: This is a digitally signed message part
Re: good old intel troubles
On Fri, 2009-07-03 at 12:14 +0200, Dominic Fandrey wrote: Now that the intel driver is stable and performs well, again, it's time to start complainig about all the things that still do not work. This is basically going to the console and back. Well, it actually works but X will entirely lock up unless the mouse is in motion. It's not hard to imagine that this is really bad. With violent mouse movement I can get glxgears to render 0.3 frames per second. That's it. 1 frame every 3 seconds. Back on the console everything is fine, so it's really just X misbehaving. No scheduling issue or the like. Oh, btw, when I switch to the Konsole I get the following message on my dmesg. error: [drm:pid1318:i915_get_vblank_counter] *ERROR* trying to get vblank count for disabled pipe 0 This is still harmless, though I hope that I have caught most of the cases where it occurs. Userland (mesa) may still call this ioctl with the wrong or both crtc's though. It is converted back to a debug message in HEAD. My system is a core2duo (amd64) running RELENG_7 (sources are from ~2 hours ago). This is all fixed in HEAD. It is waiting jhb@ to MFC r194644 to get -STABLE fixed up. I have additional MFC's to cleanup vblank support issues, but the primary issue is that msi interrupts don't work after a vt switch without the above MFC. robert. Maybe this snippet from my Xorg.0.log is also of interest: (--) Using syscons driver with X support (version 2.0) (--) using VT number 9 (--) PCI:*(0...@0:2:0) Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller rev 12, Mem @ 0xe460/1048576, 0xd000/268435456, I/O @ 0x4000/8, BIOS @ 0x/65536 (--) PCI: (0...@0:2:1) Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller rev 12, Mem @ 0xe470/1048576 I'm running X without HAL. (**) Option AllowEmptyInput off (**) Option AutoAddDevices off ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org -- Robert Noland rnol...@freebsd.org FreeBSD signature.asc Description: This is a digitally signed message part
Re: 7.2-RELEASE amd64 panic when starting Xorg
On Wed, 2009-07-01 at 10:25 +, david.kel...@litchis.fr wrote: Hi, Using an ATI Radeon X850, the system restarts when starting Xorg. The coredump says that it's a page related error. This bug seems related to this one: http://lists.freebsd.org/pipermail/freebsd-stable/2009-April/049618.html which provides some informations. Do you need more ? What can I do to help ? I don't see that we resolved that one... It looks like drm_open is returning no such file or directory. Check the permissions on the drm device. That said, it still shouldn't panic, I'm suspicious that it may be related to copyin/copyout with locks held. See if the following patch still applies cleanly. http://people.freebsd.org/~rnoland/drm_radeon-copyin-fix-try2.patch robert. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org -- Robert Noland rnol...@freebsd.org FreeBSD signature.asc Description: This is a digitally signed message part
Re: Cannot buildkernel i386/p3 (i915_suspend.c)
On Fri, 2009-06-26 at 06:09 -0700, Jakub Lach wrote: Hello. I'm trying to update P3 STABLE box from 7.2-PRERELEASE to latest stable source. 8 cut 8 /usr/src/sys/modules/drm/i915/../../../dev/drm/i915_suspend.c: In function 'i915_save_state': /usr/src/sys/modules/drm/i915/../../../dev/drm/i915_suspend.c:244: error: 'struct drm_i915_private' has no member named 'saveRENDERSTANDBY' /usr/src/sys/modules/drm/i915/../../../dev/drm/i915_suspend.c:247: error: 'struct drm_i915_private' has no member named 'saveHWS' /usr/src/sys/modules/drm/i915/../../../dev/drm/i915_suspend.c: In function 'i915_restore_state': /usr/src/sys/modules/drm/i915/../../../dev/drm/i915_suspend.c:380: error: 'struct drm_i915_private' has no member named 'saveRENDERSTANDBY' /usr/src/sys/modules/drm/i915/../../../dev/drm/i915_suspend.c:383: error: 'struct drm_i915_private' has no member named 'saveHWS' *** Error code 1 1 error I even deleted whole source and recsuped. My local i915_suspend.c is the same as in STABLE and CURRENT. There are no such problems on my CURRENT amd64 box. These come from i915_drv.h. I just did a test build on stable/7 i386 and didn't have any issue. Kernel build for GENERIC completed on Fri Jun 26 15:59:24 UTC 2009 robert. How do I update: make cleandir make cleandir rm -rf /usr/obj make -j3 buildworld make -j3 buildkernel KERNCONF=I686STRIPPED make installkernel KERNCONF=I686STRIPPED make installworld make -DBATCH_DELETE_OLD_FILES delete-old-libs make -DBATCH_DELETE_OLD_FILES delete-old make cleandir make cleandir rm -rf /usr/obj mergemaster Am I missing something obvious? -best regards, Jakub Lach -- Robert Noland rnol...@freebsd.org FreeBSD signature.asc Description: This is a digitally signed message part
Re: Cannot buildkernel i386/p3 (i915_suspend.c)
On Fri, 2009-06-26 at 09:32 -0700, Jakub Lach wrote: Robert Noland wrote: My local i915_suspend.c is the same as in STABLE and CURRENT. There are no such problems on my CURRENT amd64 box. These come from i915_drv.h. I just did a test build on stable/7 i386 and didn't have any issue. Kernel build for GENERIC completed on Fri Jun 26 15:59:24 UTC 2009 robert. -- Robert Noland rnol...@freebsd.org FreeBSD Thank for reply. It's reproducible so it shouldn't be hardware problem. At the moment I'm suspecting (if I remember .supfile correctly) cvsup.pl.FreeBSD.org mirror. Now I'm in middle of last attempt to fresh build world/kernel (single user, no -j n) before checking/changing csup mirror. This is possible. I build from svn. robert. -best regards, Jakub Lach -- Robert Noland rnol...@freebsd.org FreeBSD signature.asc Description: This is a digitally signed message part
Re: Bug between DRM, MSI, or somewhere, re7-stable amd64
On Mon, 2009-06-08 at 21:52 -0400, Pete Carah wrote: I updated my recently acquired core-2 duo laptop to 7-stable amd64 (I had been running 7-stable i386 with few problems) and have acquired an apparent irq problem. Fortunately in debugging a linux shared-interrupt problem about a month ago I learned that the X server will happily accept mouse motion as if it was a display interrupt, so at least with some inconvenience I can read the screen... (the keyboard isn't so obliging) Ours does this too... /usr/src was picked up via svn on last Saturday morning EDT, ports via csup about the same time. I have no idea if this bug is in the intel driver, drm, or the core msi code... There are 2 peripherals that dmesg says uses msi - re0 (which doesn't get a kernel thread indicated in ps for either the stated irq (257) or re0) and drm0/vgapci0 (which indicates irq256 in systat and ps). As I said, this worked properly with earlier source (about a week) in i386 mode. I've used both G45 and re controllers in (f10) linux msi mode with no problems in both 32 and 64-bit. Fortunately this laptop now has enough disk to triple-boot so at least something works... Yes, Intel still has issues. I do have a patch that reworks the interrupt handling and gets Intel chips working. It isn't safe to commit yet though. It works correctly on my G45, but I have had reports that GM45 is still broken somehow. As a workaround you can disable MSI for just drm using loader tuneable hw.drm.msi=0. robert. I am using svn instead of csup because I am trying (haven't gotten time yet either :-) to port Sam's ath 92xx code to -stable and handling code porting is much easier that way. -- Pete ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org -- Robert Noland rnol...@freebsd.org FreeBSD signature.asc Description: This is a digitally signed message part
Re: Xorg hangs with drmwtq in 7.2-RELEASE
On Sun, 2009-05-31 at 00:12 -0700, David Johnson wrote: I haven't heard anything on this in three weeks. I filed a bug report, but no acceptance yet. Does this imply that there is no intention to fix this problem? What is happening with this? Am I even posting to the right list? I'm completely in the dark here. Yes, your in the right place... I just can't reproduce it still and so it's problematic to track down. I reviewed the commit that you pointed out, but that is the r6/7xx import commit and involves a lot of code. robert. -- Robert Noland rnol...@freebsd.org FreeBSD signature.asc Description: This is a digitally signed message part
Re: failed to set mtrr: invalid argument
On Tue, 2009-05-19 at 16:10 -0700, Chris H wrote: So, zapping is off by default now in 1.6.x. If you want it, add Option DontZap off. The cross hatch is also gone, that is what the -retro option is supposed to do. The session leader in a failsafe twm session is the left hand xterm. Typing exit in that window should exit the session. DOH! Sorry. My bad. I have since determined that turning off hald dbus improve performance. I built the X server with the hald option picked. But, when I bounced the box, and started an X session (with a WM), performance was improved. BUT. Performance pretty much sucks. I have 4 of these boards running with the onbord (mach64) video, and the mere 2Mb built in RAM. They run with better performance than does this one with (200Mhz less CPU) comparable RAM this one has 64Mb onboard a faster Gpu. But they also run 6.4-STABLE xorg-6.9. So, I'm going to experiment by rebuilding the X server w/o the HAL driver - make option untick HAL. Then portupgrade -fi xorg-server. I'll report back should there be any improvement. So, the use of hal or not shouldn't produce any performance difference. It is only used to detect input devices kbd/mouse. One thing that I have discovered and I'm hoping for someone to send me a patch, is that if you build xorg-server without hal support it doesn't get linked to pthread libraries. This causes issues with libdrm on Intel at least. Not sure what else may be impacted. There is also my nouveau patch that you could try. That should get you EXA and Xv acceleration with the nouveau driver. Overall the reports that I've been getting have been good. robert. Thank you very much Robert, for all your time and efforts. -- Robert Noland rnol...@freebsd.org FreeBSD signature.asc Description: This is a digitally signed message part
Re: nv driver on Dell Latitude 830
, GeForce 6800 LE, GeForce 6800 GT, GeForce 6800 XT, GeForce 6200, GeForce 6200 A-LE, GeForce 7800 GTX, GeForce 7800 GTX, GeForce 7800 GT, GeForce 7800 GS, GeForce 7800 SLI, GeForce Go 7800, GeForce Go 7800 GTX, Quadro FX 4500, GeForce 7300 LE, GeForce 7300 SE, GeForce Go 7200, GeForce Go 7300, GeForce Go 7400, GeForce Go 7400 GS, Quadro NVS 110M, Quadro NVS 120M, Quadro FX 350M, GeForce 7500 LE, Quadro FX 350, GeForce 7300 GS, GeForce 7600 GT, GeForce 7600 GS, GeForce 7300 GT, GeForce 7600 LE, GeForce 7300 GT, GeForce Go 7700, GeForce Go 7600, GeForce Go 7600 GT, Quadro NVS 300M, GeForce Go 7900 SE, Quadro FX 550M, Quadro FX 560, GeForce 7900 GTX, GeForce 7900 GT, GeForce 7900 GS, GeForce Go 7900 GS, GeForce Go 7900 GTX, Quadro FX 2500M, Quadro FX 1500M, Quadro FX 5500, Quadro FX 3500, Quadro FX 1500, Quadro FX 4500 X2, GeForce 6150, GeForce 6150 LE, GeForce 6100, GeForce Go 6150, GeForce Go 6100, GeForce 8800 GTX, GeForce 8800 GTS, GeForce 8800 Ultra, Quadro FX 5600, Quadro FX 4600, GeForce 8600 GTS, GeForce 8600 GT, GeForce 8600 GT, GeForce 8600 GS, GeForce 8400 GS, GeForce 9500M GS, GeForce 8600M GT, GeForce 9650M GS, GeForce 8700M GT, Quadro FX 370, Quadro NVS 320M, Quadro FX 570M, Quadro FX 1600M, Quadro FX 570, Quadro FX 1700, GeForce 8400 SE, GeForce 8500 GT, GeForce 8400 GS, GeForce 8300 GS, GeForce 8400 GS, GeForce 8600M GS, GeForce 8400M GT, GeForce 8400M GS, GeForce 8400M G, Quadro NVS 140M, Quadro NVS 130M, Quadro NVS 135M, GeForce 9400 GT, Quadro FX 360M, GeForce 9300M G, Quadro NVS 290, GeForce GTX 280, GeForce GTX 260, GeForce 8800 GTS 512, GeForce 8800 GT, GeForce 9800 GX2, GeForce 8800 GS, GeForce 8800M GTS, GeForce 8800M GTX, GeForce 8800 GS, GeForce 9600 GSO, GeForce 8800 GT, GeForce 9800 GTX, GeForce 9800 GTK+, GeForce 9800 GT, Quadro FX 3700, Quadro FX 3600M, GeForce 9600 GT, GeForce 9600 GS, GeForce 9800M GTS, GeForce 9700M GTS, GeForce 9800M GTS, GeForce 9500 GT, GeForce 9600M GT, GeForce 9600M GS, GeForce 9600M GT, GeForce 9500M G, GeForce 9300 GS, GeForce 8400 GS, GeForce 9300M GS, GeForce 9200M GS, GeForce 9300M GS, Quadro NVS 150M, Quadro NVS 160M (II) Primary Device is: PCI 0...@00:00:0 (--) NV: Found NVIDIA Quadro NVS 140M at 0...@00:00:0 (II) resource ranges after probing: [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) Loading sub module int10 (II) LoadModule: int10 (II) Loading /usr/local/lib/xorg/modules//libint10.so (II) Module int10: vendor=X.Org Foundation compiled for 1.6.1, module version = 1.0.0 ABI class: X.Org Video Driver, version 5.0 (II) NV(0): Initializing int10 (==) NV(0): Write-combining range (0xa,0x2) was already clear (==) NV(0): Write-combining range (0xc,0x4) was already clear (II) NV(0): Primary V_BIOS segment is: 0xc000 (==) NV(0): Write-combining range (0x0,0x1000) was already clear (--) NV(0): Console is VGA mode 0x3 (**) NV(0): Depth 24, (--) framebuffer bpp 32 (==) NV(0): RGB weight 888 (==) NV(0): Default visual is TrueColor (==) NV(0): Using hardware cursor (==) NV(0): Using gamma correction (1.0, 1.0, 1.0) (II) NV(0): MMIO registers mapped at 0x80280 (EE) NV(0): Failed to determine the amount of available video memory (==) NV(0): Write-combining range (0x0,0x1000) was already clear (II) UnloadModule: nv (II) UnloadModule: int10 (II) Unloading /usr/local/lib/xorg/modules//libint10.so (EE) Screen(s) found, but none have a usable configuration. Fatal server error: no screens found I've not really looked at the nv driver in detail... You could try my nouveau patch. I think it will apply to 7.2 kernel. That should get you EXA and Xv acceleration. http://people.freebsd.org/~rnoland/drm-nouveau-043009.patch robert. Please consult the The X.Org Foundation support at http://wiki.x.org for help. Please also check the log file at /var/log/Xorg.0.log for additional information. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org -- Robert Noland rnol...@freebsd.org FreeBSD signature.asc Description: This is a digitally signed message part
Re: failed to set mtrr: invalid argument
On Wed, 2009-05-20 at 16:16 +0200, Paul B. Mahol wrote: On 5/20/09, Robert Noland rnol...@freebsd.org wrote: On Tue, 2009-05-19 at 16:10 -0700, Chris H wrote: So, zapping is off by default now in 1.6.x. If you want it, add Option DontZap off. The cross hatch is also gone, that is what the -retro option is supposed to do. The session leader in a failsafe twm session is the left hand xterm. Typing exit in that window should exit the session. DOH! Sorry. My bad. I have since determined that turning off hald dbus improve performance. I built the X server with the hald option picked. But, when I bounced the box, and started an X session (with a WM), performance was improved. BUT. Performance pretty much sucks. I have 4 of these boards running with the onbord (mach64) video, and the mere 2Mb built in RAM. They run with better performance than does this one with (200Mhz less CPU) comparable RAM this one has 64Mb onboard a faster Gpu. But they also run 6.4-STABLE xorg-6.9. So, I'm going to experiment by rebuilding the X server w/o the HAL driver - make option untick HAL. Then portupgrade -fi xorg-server. I'll report back should there be any improvement. So, the use of hal or not shouldn't produce any performance difference. It is only used to detect input devices kbd/mouse. One thing that I have discovered and I'm hoping for someone to send me a patch, is that if you build xorg-server without hal support it doesn't get linked to pthread libraries. This causes issues with libdrm on Intel at least. Not sure what else may be impacted. I ignored this info first time, but I will ask now. Does this implies that libthr is listed in Xorg ldd(1) output? I use server build without hal support on 945GM(irq not MSI) and I do not experience problems with drm/dri/OpenGL/xv or whatever other protocol you name it. Yes, if xserver is built with HAL support, I see it linked with libthr. If HAL is disabled, it doesn't appear to be. I'm trying to remember exactly what the reported issue was, but I think it was X crashing on exit. robert. There is also my nouveau patch that you could try. That should get you EXA and Xv acceleration with the nouveau driver. Overall the reports that I've been getting have been good. robert. Thank you very much Robert, for all your time and efforts. -- Robert Noland rnol...@freebsd.org FreeBSD -- Robert Noland rnol...@freebsd.org FreeBSD signature.asc Description: This is a digitally signed message part
Re: failed to set mtrr: invalid argument
On Wed, 2009-05-20 at 17:26 +0200, Paul B. Mahol wrote: On 5/20/09, Robert Noland rnol...@freebsd.org wrote: On Wed, 2009-05-20 at 16:16 +0200, Paul B. Mahol wrote: On 5/20/09, Robert Noland rnol...@freebsd.org wrote: On Tue, 2009-05-19 at 16:10 -0700, Chris H wrote: So, zapping is off by default now in 1.6.x. If you want it, add Option DontZap off. The cross hatch is also gone, that is what the -retro option is supposed to do. The session leader in a failsafe twm session is the left hand xterm. Typing exit in that window should exit the session. DOH! Sorry. My bad. I have since determined that turning off hald dbus improve performance. I built the X server with the hald option picked. But, when I bounced the box, and started an X session (with a WM), performance was improved. BUT. Performance pretty much sucks. I have 4 of these boards running with the onbord (mach64) video, and the mere 2Mb built in RAM. They run with better performance than does this one with (200Mhz less CPU) comparable RAM this one has 64Mb onboard a faster Gpu. But they also run 6.4-STABLE xorg-6.9. So, I'm going to experiment by rebuilding the X server w/o the HAL driver - make option untick HAL. Then portupgrade -fi xorg-server. I'll report back should there be any improvement. So, the use of hal or not shouldn't produce any performance difference. It is only used to detect input devices kbd/mouse. One thing that I have discovered and I'm hoping for someone to send me a patch, is that if you build xorg-server without hal support it doesn't get linked to pthread libraries. This causes issues with libdrm on Intel at least. Not sure what else may be impacted. I ignored this info first time, but I will ask now. Does this implies that libthr is listed in Xorg ldd(1) output? I use server build without hal support on 945GM(irq not MSI) and I do not experience problems with drm/dri/OpenGL/xv or whatever other protocol you name it. Yes, if xserver is built with HAL support, I see it linked with libthr. If HAL is disabled, it doesn't appear to be. I'm trying to remember exactly what the reported issue was, but I think it was X crashing on exit. Looking at xorg-server source I did not see anything that points it must link to libthr, perhaps HAL support makes libthr linking mandatory. The issue crops up with libdrm-intel. libdrm is linked with pthread. I know I talked about this with kib@ a while back and we determined that the existing behavior was correct, but I think at that time we were looking at xserver linked with libthr. X doesnt crash on exit for me, well it did before (maybe because drm outputs ressurected *pipe disabled* message on console all the time). Should this finnaly be replaced with DRM_DEBUG ? I changed it to a DEBUG before, it crept back in... I think I have it changed again in my current intel code. robert. -- Robert Noland rnol...@freebsd.org FreeBSD signature.asc Description: This is a digitally signed message part
Re: failed to set mtrr: invalid argument
On Tue, 2009-05-19 at 09:57 -0700, Chris H wrote: Quoting Dimitry Andric dimi...@andric.com: On 2009-05-19 08:40, Chris H wrote: I see. Well I'm specifically using the nv driver. Here's another attempt to provide the relevant info: I could not find the error message from $subject in these logs. Where is it? :) If I had found it, I would have better known what direction to travel to overcome it. :) Aparently Xorg wants to keep it a secret - I saw no argument. This isn't actually Xorg per se... It is when we attempt to set an MTRR range via ioctl on /dev/mem. The ultimate return value is EINVAL which just gets displayed as invalid argument. The closest possible answer I can come up with, involves write combining and provinding some information in /proc/mtrr But I only have /proc and nothing in it. Thought about echo(1)ing the information to mtrr. But don't understand the whole thing well enough to /dare/ do it. I only know it involves something in this area: 0xfd00/16777216, 0xf000/134217728, 0xfa58/524288 out of the Xorg log. I'm also not sure if GENERIC knows how to handle mtrr (Memory Type Range Registers) ideally. I hadn't built world/kernel yet because there are also some issues on the ATA ports that need to be resolved. I started a theread on this earlier. Thank you for taking the time to respond. You can do a memcontrol list which will display the memory regions and their caching method. Likely what you will find is a global MTRR which is set to write-back. We don't have the ability to split regions and we aren't allowed to overlap write-combine on top of write-back, so any attempt to set MTRR will fail. The specific failure is most likely when X tries to set write-combine on the framebuffer, which in your case looks like 0xf000/134217728. Again, this shouldn't prevent X from working... It is just a performance issue. robert. --Chris H ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org -- Robert Noland rnol...@freebsd.org FreeBSD signature.asc Description: This is a digitally signed message part
Re: failed to set mtrr: invalid argument
On Tue, 2009-05-19 at 13:14 -0700, Chris H wrote: Hello Robert, and thank you for taking the time to respond. Quoting Robert Noland rnol...@freebsd.org: On Tue, 2009-05-19 at 09:57 -0700, Chris H wrote: Quoting Dimitry Andric dimi...@andric.com: On 2009-05-19 08:40, Chris H wrote: I see. Well I'm specifically using the nv driver. Here's another attempt to provide the relevant info: I could not find the error message from $subject in these logs. Where is it? :) If I had found it, I would have better known what direction to travel to overcome it. :) Aparently Xorg wants to keep it a secret - I saw no argument. This isn't actually Xorg per se... It is when we attempt to set an MTRR range via ioctl on /dev/mem. The ultimate return value is EINVAL which just gets displayed as invalid argument. The closest possible answer I can come up with, involves write combining and provinding some information in /proc/mtrr But I only have /proc and nothing in it. Thought about echo(1)ing the information to mtrr. But don't understand the whole thing well enough to /dare/ do it. I only know it involves something in this area: 0xfd00/16777216, 0xf000/134217728, 0xfa58/524288 out of the Xorg log. I'm also not sure if GENERIC knows how to handle mtrr (Memory Type Range Registers) ideally. I hadn't built world/kernel yet because there are also some issues on the ATA ports that need to be resolved. I started a theread on this earlier. Thank you for taking the time to respond. You can do a memcontrol list which will display the memory regions and their caching method. Likely what you will find is a global MTRR which is set to write-back. I always set write-back in the BIOS, as it then gets marked dirty, and the CPU cache will get processed accordingly. We don't have the ability to split regions and we aren't allowed to overlap write-combine on top of write-back, so any attempt to set MTRR will fail. The specific failure is most likely when X tries to set write-combine on the framebuffer, which in your case looks like 0xf000/134217728. Again, this shouldn't prevent X from working... It is just a performance issue. My investigations on this have led me to believe that Linux can address (allow) write-combining via their version of sysctl (so to speak). The article I found this reference was here: http://www.mplayerhq.hu/DOCS/HTML/en/mtrr.html Do we (does FreeBSD) have this ability? Or will we? I also found some good information on write combining here: http://www.meduna.org/txt_mtrr_en.html This box can be used as a guinea pig if you would like. Thanks again Robert, for all your time and efforts. Linux may have the ability to split regions, I'm really not sure. We can manipulate memory ranges using memcontrol, but if you have a global set to write-back like both of my newer bios's do, then you would have to remove that and then manually split the regions to allow a non-overlapping write-combined region. I generally lock up the machine when I have tried that though. robert. --Chris H robert. --Chris H ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org -- Robert Noland rnol...@freebsd.org FreeBSD ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org -- Robert Noland rnol...@freebsd.org FreeBSD signature.asc Description: This is a digitally signed message part
Re: failed to set mtrr: invalid argument
On Tue, 2009-05-19 at 13:52 -0700, Chris H wrote: Quoting Robert Noland rnol...@freebsd.org: On Tue, 2009-05-19 at 11:47 -0700, Chris H wrote: Quoting Chris H chr...@1command.com: Quoting Laurent Grangeau thorz...@gmail.com: I think I can handle this answer. This is the default behavior of Xorg 7.4. If you want to see the old screen, launch Xorg with the -retro option. The command should be like this : X -config xorg.conf.new -retro If your mouse or your keyboard doesn't seem to work, look if you have enable dbus and hald. In your /etc/rc.conf, you should have dbus_enable=YES and hald_enable=YES (I'm not sure about this). All this is explain in the handbook : Configuring X11. Hello Laurent, and thank you for your reply. For the record, this is the way I /first/ attempted to do it - echo 'enable_hald=YES' /etc/rc.conf echo 'enable_dbus=YES' /etc/rc.conf Bounce the box attempt to test Xorg: Xorg -config /root/xorg.conf.new no joy. So I tweaked the file (removing the card I wasn't going to use). Save the remaining as /etc/X11/xorg.conf.nvidia Xorg -config /etc/X11/xorg.conf.nvidia But again, no joy. I'll try it again, and report back with my findings. Thanks again for your response. --Chris H OK here's the results: echo 'hald_enable=YES' /etc/rc.conf echo 'enable_dbus=YES' /etc/rc.conf bounce the box Xorg -config /etc/X11/xorg.conf.nvidia returns the following: X.Org X Server 1.6.0 Release Date: 2009-2-25 X Protocol Version 11, Revision 0 Build Operating System: FreeBSD 7.1-RELEASE i386 Current Operating ---8--[BIG SNIP]--8--- (**) Option DataBits 8 (**) Option Parity None (**) Option Vmin 1 (**) Option Vtime 0 (**) Option FlowControl None An attempt to bail out of X on tty8 (ctl-alt-backspace) returns: Failed to switch consoles (Invalid argument) on tty0 Attempting again returns: Failed to switch consoles (Invalid argument) on tty0 move to tty0 (ctl-alt-f1) ctl-C OK let's try the -retro switch on the Xorg created conf... --- Xorg -config xorg.conf.new -retro provides: X.Org X Server 1.6.0 Release Date: 2009-2-25 X Protocol Version 11, Revision 0 Build Operating System: FreeBSD 7.1-RELEASE i386 Current Operating System: FreeBSD udns.ultimatedns.NET 7.1-RELEASE FreeBSD 7.1-RELEASE #0: Thu Jan 1 14:37:25 UTC 2009 r...@logan.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386 Build Date: 16 May 2009 07:15:01AM 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: Tue May 19 11:33:40 2009 (++) Using config file: /etc/X11/xorg.conf.new (==) ServerLayout X.org Configured (**) |--Screen Screen0 (0) (**) | |--Monitor Monitor0 (**) | |--Device Card0 (**) |--Screen Screen1 (1) (**) | |--Monitor Monitor1 (**) | |--Device Card1 (**) |--Input Device Mouse0 (**) |--Input Device Keyboard0 (==) Automatically adding devices ---8--[BIG SNIP]--8--- (II) Module int10: vendor=X.Org Foundation compiled for 1.6.0, module version = 1.0.0 ABI class: X.Org Video Driver, version 5.0 (==) MACH64(0): Write-combining range (0xa,0x2) was already clear (==) MACH64(0): Write-combining range (0xc,0x4) was already clear Which only leaves me with a blinking block cursor in the upper LEFT-hand corner while hooked up to the NV card. There is no output to the MACH64. I don't think this is the answer. Hrm, ok... It might still be getting confused by the ati card... The issue comes down to which card (hopefully not both) is handling legacy vga calls to 0xc. I did just notice someone else post an issue with the openchrome driver and int10 though, so you might try disabling int10. robert. Hello Robert, and thank you for your reply. I apologize, but am not exactly sure how to do this. The following: SubSection int10 Optionomit int10 # don't initialise openchrome extension EndSubSection didn't do it. :( man xorg.conf Option NoInt10 boolean Disables the Int10 module, a module that uses the int10 call to the BIOS of the graphics card to initialize it. Default: false. robert. --Chris H. --Chris H Le 19 mai 09 à 19:15, Chris H chr...@1command.com a écrit : Quoting Robert Noland rnol...@freebsd.org: On Mon, 2009-05-18 at 23:40 -0700, Chris H wrote: Quoting Paul B. Mahol one...@gmail.com: On 5/19/09, Chris H chr...@1command.com wrote: Quoting Chris H chr...@1command.com: Quoting Chris H chr...@1command.com
Re: Xorg hangs with drmwtq in 7.2-RELEASE
On Sun, 2009-05-17 at 13:54 -0700, David Johnson wrote: After much rebuilding and testing, I have narrowed down the introduction of this bug to commit #189855. Most of this commit is related to r600/700 chips, but there are other changes. I don't understand the code and can't see anything obvious. But it is a place to start. Does this help any? Or should I keep banging my head against the wall? I'll review that commit... Hopefully before brain damage sets in for either of us... robert. -- Robert Noland rnol...@freebsd.org FreeBSD signature.asc Description: This is a digitally signed message part
Re: Xorg hangs with drmwtq in 7.2-RELEASE
On Sat, 2009-05-09 at 18:41 -0700, David Johnson wrote: On Friday 08 May 2009 03:31:04 pm Robert Noland wrote: In order to guess what might be causing this, drm debugging needs to be enabled before the hang, so that we can hopefully figure out what leads up to the hung GPU. I'm not able to do that, but I did manage to get debug turned on and dmesg captured early enough to catch some additional information. I've place the full file online at http://www.usermode.org/misc/dmesg.txt, but am including some snippets here. Hopefully this is enough to move forward. -- David Johnson This trace still looks odd... ... [drm:pid1822:drm_ioctl] pid=1822, cmd=0xc0286429, nr=0x29, dev 0xc615fa00, auth=1 [drm:pid1822:radeon_freelist_get] done_age = 102778 Things appear to be working at this point. [drm:pid1822:drm_ioctl] pid=1822, cmd=0xc010644d, nr=0x4d, dev 0xc615fa00, auth=1 [drm:pid1822:radeon_cp_indirect] idx=27 s=0 e=88 d=1 [drm:pid1822:radeon_cp_dispatch_indirect] buf=27 s=0x0 e=0x58 Now, open count is 2 and something is calling close. [drm:pid1822:drm_close] open_count = 2 [drm:pid1822:drm_close] pid = 1822, device = 0xc615fa00, open_count = 2 [drm:pid1822:drm_ioctl] pid=1822, cmd=0x80086442, nr=0x42, dev 0xc615fa00, auth=1 [drm:pid1822:radeon_cp_stop] [drm:pid1822:radeon_do_cp_flush] [drm:pid1822:radeon_do_cp_idle] [drm:pid1822:radeon_do_cp_stop] [drm:pid1822:radeon_do_engine_reset] info: [drm] Num pipes: 1 [drm:pid1822:radeon_do_cp_reset] [drm:pid1822:drm_ioctl] pid=1822, cmd=0x800c6459, nr=0x59, dev 0xc615fa00, auth=1 [drm:pid1822:drm_ioctl] pid=1822, cmd=0x80086414, nr=0x14, dev 0xc615fa00, auth=1 [drm:pid1822:drm_irq_uninstall] irq=16 [drm:pid1822:drm_ioctl] pid=1822, cmd=0x80546440, nr=0x40, dev 0xc615fa00, auth=1 [drm:pid1822:radeon_do_cleanup_cp] [drm:pid1822:drm_ioctl] pid=1822, cmd=0x80086439, nr=0x39, dev 0xc615fa00, auth=1 [drm:pid1822:drm_sg_free] sg free virtual = 0xe8a64000 [drm:pid1822:drm_ioctl] pid=1822, cmd=0x8004667e, nr=0x7e, dev 0xc615fa00, auth=1 [drm:pid1822:drm_ioctl] pid=1822, cmd=0x8004667d, nr=0x7d, dev 0xc615fa00, auth=1 [drm:pid1822:drm_ioctl] pid=1822, cmd=0xc0086421, nr=0x21, dev 0xc615fa00, auth=1 [drm:pid1822:drm_rmctx] 2 [drm:pid1822:drm_ioctl] pid=1822, cmd=0xc0086421, nr=0x21, dev 0xc615fa00, auth=1 [drm:pid1822:drm_rmctx] 1 [drm:pid1822:drm_ioctl] pid=1822, cmd=0xc0086426, nr=0x26, dev 0xc615fa00, auth=1 [drm:pid1822:drm_ioctl] pid=1822, cmd=0xc0086426, nr=0x26, dev 0xc615fa00, auth=1 [drm:pid1822:drm_ioctl] pid=1822, cmd=0x8008642b, nr=0x2b, dev 0xc615fa00, auth=1 [drm:pid1822:drm_unlock] 1 (pid 1822) requests unlock (0x8001), flags = 0x Another close, followed by lastclose, so drm is fully shutdown. [drm:pid1822:drm_close] open_count = 1 [drm:pid1822:drm_close] pid = 1822, device = 0xc615fa00, open_count = 1 [drm:pid1822:drm_lastclose] [drm:pid1822:radeon_do_cleanup_cp] Now, this looks like several vt switches... We don't see the open sequence here, so I assume that debugging was disabled at this point. info: [drm] Setting GART location based on new memory map info: [drm] Loading R500 Microcode info: [drm] Num pipes: 1 info: [drm] writeback test succeeded in 1 usecs drm0: [ITHREAD] info: [drm] Num pipes: 1 info: [drm] Setting GART location based on new memory map info: [drm] Loading R500 Microcode info: [drm] Num pipes: 1 info: [drm] writeback test succeeded in 1 usecs drm0: [ITHREAD] info: [drm] Num pipes: 1 info: [drm] Setting GART location based on new memory map info: [drm] Loading R500 Microcode info: [drm] Num pipes: 1 info: [drm] writeback test succeeded in 1 usecs drm0: [ITHREAD] info: [drm] Num pipes: 1 info: [drm] Setting GART location based on new memory map info: [drm] Loading R500 Microcode info: [drm] Num pipes: 1 info: [drm] writeback test succeeded in 1 usecs drm0: [ITHREAD] info: [drm] Num pipes: 1 info: [drm] Setting GART location based on new memory map info: [drm] Loading R500 Microcode info: [drm] Num pipes: 1 info: [drm] writeback test succeeded in 1 usecs drm0: [ITHREAD] info: [drm] Num pipes: 1 info: [drm] Setting GART location based on new memory map info: [drm] Loading R500 Microcode info: [drm] Num pipes: 1 info: [drm] writeback test succeeded in 1 usecs drm0: [ITHREAD] info: [drm] Num pipes: 1 info: [drm] Setting GART location based on new memory map info: [drm] Loading R500 Microcode info: [drm] Num pipes: 1 info: [drm] writeback test succeeded in 1 usecs drm0: [ITHREAD] and here debugging was re-enabled after the problem has occurred. [drm:pid6216:drm_ioctl] returning 4 [drm:pid6216:drm_ioctl] pid=6216, cmd=0x80046457, nr=0x57, dev 0xc615fa00, auth=1 [drm:pid6216:drm_ioctl] returning 4 [drm:pid6216:drm_ioctl] pid=6216, cmd=0x80046457, nr=0x57, dev 0xc615fa00, auth=1 [drm:pid6216:drm_ioctl] returning 4 [drm:pid6216:drm_ioctl] pid=6216, cmd=0x80046457, nr=0x57, dev
Re: powerd broken
On Sat, 2009-05-09 at 10:26 +0200, Dominic Fandrey wrote: Robert Noland wrote: On Fri, 2009-04-10 at 16:53 +0200, Dominic Fandrey wrote: Robert Noland wrote: I've been working on the Intel vblank / irq issues. Every time I commit something thinking that I have it resolved, it isn't. So I'm waiting on hardware to arrive that will let me test this all more thoroughly. I do have a patch that I think fixes most of the issues on Intel, but the ddx driver is still doing some silly things that cause issues in some cases. I *think* the only outstanding issue I have with Intel is if something is rendering (synced to vblank or not) when the display goes into dpms sleep, there isn't anything to block that app, so it renders as hard as it can even though it isn't being displayed. In reality, this probably isn't a huge issue, but running gears while the display is asleep keeps the cpu at 100%, which isn't ideal. Normal apps that aren't trying to draw as fast as they can, shouldn't cause an issue. With the latest drm, the IRQ craziness is gone. However, the crappy performance remains. 2 months ago a RELENG_7 with all packages up to date yielded 124fps in a q3 timedemo that now yields 80fps. Things are still not quite right with the Intel driver. But performance regressions are reported across Linux as well. A little of this might be us, but most of it is Intel... I don't know what you did with the last update, but performance is now better than ever (2% above what it used to be), which equels 3-4 more frames in ioQuake3 or 200 more in glxgears. The uptime of the notebook is now 15 hours and the interrupt load insignificant. I get no more than 8000 interrupts per seconds. 4000 of these are CPU timers (2000 for each core) and 1000 more are from my mouse, when I move it very fast. Around 2500 from vgapci, when I run glxgears and the rest is just scraps of whatever else is running (e.g. sound). Which update, what? I haven't touched the kernel tree in a while, just trying to sort it all out with patches here and there. Are you saying the the 2.7.0 intel driver helped? Or maybe the Xserver or mesa updates? robert. Thanks a lot. Regards -- Robert Noland rnol...@freebsd.org FreeBSD signature.asc Description: This is a digitally signed message part
Re: powerd broken
On Sat, 2009-05-09 at 15:10 +0200, Dominic Fandrey wrote: Robert Noland wrote: On Sat, 2009-05-09 at 10:26 +0200, Dominic Fandrey wrote: Robert Noland wrote: On Fri, 2009-04-10 at 16:53 +0200, Dominic Fandrey wrote: Robert Noland wrote: I've been working on the Intel vblank / irq issues. Every time I commit something thinking that I have it resolved, it isn't. So I'm waiting on hardware to arrive that will let me test this all more thoroughly. I do have a patch that I think fixes most of the issues on Intel, but the ddx driver is still doing some silly things that cause issues in some cases. I *think* the only outstanding issue I have with Intel is if something is rendering (synced to vblank or not) when the display goes into dpms sleep, there isn't anything to block that app, so it renders as hard as it can even though it isn't being displayed. In reality, this probably isn't a huge issue, but running gears while the display is asleep keeps the cpu at 100%, which isn't ideal. Normal apps that aren't trying to draw as fast as they can, shouldn't cause an issue. With the latest drm, the IRQ craziness is gone. However, the crappy performance remains. 2 months ago a RELENG_7 with all packages up to date yielded 124fps in a q3 timedemo that now yields 80fps. Things are still not quite right with the Intel driver. But performance regressions are reported across Linux as well. A little of this might be us, but most of it is Intel... I don't know what you did with the last update, but performance is now better than ever (2% above what it used to be), which equels 3-4 more frames in ioQuake3 or 200 more in glxgears. The uptime of the notebook is now 15 hours and the interrupt load insignificant. I get no more than 8000 interrupts per seconds. 4000 of these are CPU timers (2000 for each core) and 1000 more are from my mouse, when I move it very fast. Around 2500 from vgapci, when I run glxgears and the rest is just scraps of whatever else is running (e.g. sound). Which update, what? I haven't touched the kernel tree in a while, just trying to sort it all out with patches here and there. Are you saying the the 2.7.0 intel driver helped? Or maybe the Xserver or mesa updates? I update my ports daily, without really looking at what. I think xorg-server was one of them. It must have been something that happened during the last 48 hours. Ok, well server, mesa and intel driver all got updates in my sweep the other day. robert. robert. Thanks a lot. Regards -- Robert Noland rnol...@freebsd.org FreeBSD signature.asc Description: This is a digitally signed message part
Re: Xorg hangs with drmwtq in 7.2-RELEASE
On Thu, 2009-05-07 at 22:29 -0700, David Johnson wrote: On Tuesday 05 May 2009 08:41:48 pm David Johnson wrote: On Monday 04 May 2009 11:20:17 pm Robert Noland wrote: This generally suggests that the GPU is locked up... Given that you say sometimes it locks up hard (usually a panic, that you can't see since X is running) and other times only X is stalled it might be related to this patch, if you haven't tried this on already. http://people.freebsd.org/~rnoland/drm_radeon-copyin-fix-try2.patch Nope, that didn't help. Still froze when I tried opening multiple windows at once. I'm backing out the patch to get back to a clean state. I also edited my xorg.conf to be closer to yours. No difference. What information do you need to go forward, and how do I collect it? p.s. I didn't have a problem with sources from RELENG_7 date=2009.03.13, if that helps any. I just upgraded graphics/libdrm. It didn't help any. I'm just shooting blanks in the dark. Any help would be greatly appreciated. Please let me know what information is needed and how I collect it. I still can't reproduce this... I updated the Xserver, libGL and dri ports yesterday, all of which could be related to locking up the GPU and worth a shot. Failing that, I need you to enabled drm debugging. Start the system without X, kldload radeon.ko, set sysctl hw.dri.0.debug=1 then startx. robert. Thank you, -- Robert Noland rnol...@freebsd.org FreeBSD signature.asc Description: This is a digitally signed message part
Re: Xorg hangs with drmwtq in 7.2-RELEASE
On Fri, 2009-05-08 at 14:58 -0700, David Johnson wrote:
On Friday 08 May 2009 07:35:45 am Robert Noland wrote:
I still can't reproduce this... I updated the Xserver, libGL and dri
ports yesterday, all of which could be related to locking up the GPU and
worth a shot. Failing that, I need you to enabled drm debugging. Start
the system without X, kldload radeon.ko, set sysctl hw.dri.0.debug=1
then startx.
I've got all the updated ports as of last night, so that wasn't it.
I turned AIGLX back on, and it promptly locked up again. This time, however,
the screen went black instead of freezing, but otherwise the same as always.
I then turned on hw.dri.0.debug, and messages quickly filled up with the
following repeated message:
[drm:pid1195:drm_ioctl] returning 4
[drm:pid1195:drm_ioctl] pid=1195, cmd=0x80046457, nr=0x57, dev 0xc615fa00,
auth=1
This is too late to really see anything... This still just suggests that
the GPU is locked up. What is happening below is that we have emitted
an irq to the card and we are waiting on it to parse that. The return
value 4 is EINTR which says that we were interrupted while we were
waiting. When we return EINTR, libdrm just performs the ioctl over
again. We first read the register from the card to see if it has parsed
at least up to what we are looking for, if so we just return success and
don't sleep. If the register says that we haven't parsed the command,
then we sleep for a max of 3 seconds waiting on the card to catch up.
In your case, the card is never catching up, which suggests that the
card is hung and not processing the command stream anymore.
static int radeon_wait_irq(struct drm_device * dev, int swi_nr)
{
drm_radeon_private_t *dev_priv =
(drm_radeon_private_t *) dev-dev_private;
int ret = 0;
if (RADEON_READ(RADEON_LAST_SWI_REG) = swi_nr)
return 0;
dev_priv-stats.boxes |= RADEON_BOX_WAIT_IDLE;
DRM_WAIT_ON(ret, dev_priv-swi_queue, 3 * DRM_HZ,
RADEON_READ(RADEON_LAST_SWI_REG) = swi_nr);
if (ret == -ERESTART)
DRM_DEBUG(restarting syscall);
return ret;
}
In order to guess what might be causing this, drm debugging needs to be
enabled before the hang, so that we can hopefully figure out what leads
up to the hung GPU.
robert.
--
Robert Noland rnol...@freebsd.org
FreeBSD
signature.asc
Description: This is a digitally signed message part
Re: Xorg hangs with drmwtq in 7.2-RELEASE
On Mon, 2009-05-04 at 20:15 -0700, David Johnson wrote: This topic has been recently discussed twice before in the past month and a half, but without resolution. It now reappears on my system as I upgrade to 7.2-RELEASE. It does not happen with a build from RELENG_7 date=2009.03.13. I am desperately hoping for a resolution. To reiterate the problem: Xorg will occassionally hang. This only happens when compositing it enabled. I am using KDE 4.2.2, radeon driver, all ports updated to this morning. About a third of the time the kernel locks up, and I cannot ssh into the system. The other half of the time I can ssh into the system. There I notice that Xorg has the state of drmwtq, with perhaps some other GUI processes in the same state. The video card is a Radeon X1550. I have tried with and without AGPMode set, and both XAA and EXA render modes. No change. You can look at my xorg.conf and Xorg log at: http://www.usermode.org/misc/xorg.conf http://www.usermode.org/misc/Xorg.0.log.old p.s. Posting to freebsd-stable, as this problem has been previously discussed here. If this is no longer the appropriate list, please let me know. Unfortunately, hanging in drmwtq isn't really that informative... What this says is that we have submitted commands to the GPU and are waiting on it to process them. When userland tells us to wait for the event, we check to see if the card has already processed the command. If it has, then we just return immediately. If it hasn't, then we sleep waiting on an interrupt from the card once it has processed the command. We will sleep for at most 3 seconds, but userland (via libdrm) will just keep asking us over and over. This generally suggests that the GPU is locked up... Given that you say sometimes it locks up hard (usually a panic, that you can't see since X is running) and other times only X is stalled it might be related to this patch, if you haven't tried this on already. http://people.freebsd.org/~rnoland/drm_radeon-copyin-fix-try2.patch I would usually suggest that you try AGPMode 1, but since you have already tried PCI mode, that should rule that out. You should be using EXA on this card, but having tried XAA is also good for a sanity check. I rarely get to run a card for very long anymore... I end up swapping cards out a few times a day lately, but I have recently been running an x600 pcie (r300) with compiz for at least several hours without issue. If you can figure out a way to reproduce it, or manage to get a core file from one of the panics that would help. Preferably without involving KDE, since I don't run it... I have also run an x1650 PCI-E somewhat recently, which is the closest I have to your card, though I don't remember exactly how long ago it was that I ran it for more than an hour. Probably 2 or 3 weeks ago. robert. Thank you, -- Robert Noland rnol...@freebsd.org FreeBSD signature.asc Description: This is a digitally signed message part
Re: [PANIC] recent 7.2-STABLE when probing drm
On Tue, 2009-05-05 at 13:35 +0100, Gavin Atkinson wrote: On Tue, 2009-05-05 at 15:12 +0300, Kostik Belousov wrote: On Tue, May 05, 2009 at 12:12:31PM +0100, Gavin Atkinson wrote: On Tue, 2009-05-05 at 13:06 +0200, Guido Falsi wrote: Hi! I'm using FreeBSD/i386 stable on a HP DC7800 PC. It has an Intel Q35 graphic chip. After upgrading to a recent stable I experienced a pani on boot, just after probing drm. I investigated a little and found out that reverting the file src/sys/dev/pci/pci.c to rev. 1.355.2.9 (SVN Rev 190092) solves the crash. I could not investigatte urther right away, but some regression was introduced with this rev. Is any more information needed? When it panics, can you please type bt (assuming you have the debugger compiled in) and show the output? I have this too. I have dump too. drm0: Intel i945GM on vgapci0 panic: resource_list_alloc: resource entry is busy KDB: stack backtrace: db_trace_self_wrapper(c07214ff,c2b46764,c04c928f,c071f823,c078b080,...) at 0xc044df46 = db_trace_self_wrapper+0x26 kdb_backtrace(c071f823,c078b080,c07211b1,c2b46770,c2b46770,...) at 0xc04f41f9 = kdb_backtrace+0x29 panic(c07211b1,3,10,c04e9484,c2e37000,...) at 0xc04c928f = panic+0xaf resource_list_alloc(c2cffb04,c2d00a80,c2d00c80,3,c2d2a1fc,...) at 0xc04f0c06 = resource_list_alloc+0xd6 pci_alloc_resource(c2d00a80,c2d00c80,3,c2d2a1fc,0,,1,4) at 0xc045a2d1 = pci_alloc_resource+0x581 bus_alloc_resource(c2d00c80,3,c2d2a1fc,0,,...) at 0xc04f0a8c = bus_alloc_resource+0x7c vga_pci_alloc_resource(c2d00c80,c2cfa080,3,c2d2a1fc,0,,1,4) at 0xc04600ab = vga_pci_alloc_resource+0x3b [...] I wonder if r189373 also needs merging? Yes, that looks right, resources are owned by both agp and drm on Intel. robert. Gavin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org -- Robert Noland rnol...@freebsd.org FreeBSD signature.asc Description: This is a digitally signed message part
Re: Radeon 9250 DRM in 7.2-RELEASE
On Mon, 2009-05-04 at 13:41 -0400, Steve Polyack wrote: I upgraded my workstation (via source) to 7.2-RELEASE from 7.1-RELEASE about a day ago. After the upgrade procedure, I'm having no luck with using DRM in X11. It worked fine before and gave reasonable performance. Now when I start up X with DRI enabled, both of my screens display garbage. The mouse pointer is also not visible. I'm using a PCI Radeon 9250. I can get more details if necessary. I can also try to revert the kernel DRM module code to 7.1. From dmesg: drm2: ATI Radeon RV280 9250 on vgapci2 Why is this drm2? Is this a multicard setup? Multicard doesn't work right now. If you aren't using more than one card, can you disable whatever else drm is attaching to? robert. vgapci2: child drm2 requested pci_enable_busmaster info: [drm] Initialized radeon 1.29.0 20080528 info: [drm] Setting GART location based on new memory map info: [drm] Loading R200 Microcode info: [drm] writeback test succeeded in 2 usecs drm2: [ITHREAD] Any ideas or suggestions would be appreciated. Thanks. ___ freebsd-...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-x11 To unsubscribe, send any mail to freebsd-x11-unsubscr...@freebsd.org -- Robert Noland rnol...@freebsd.org FreeBSD signature.asc Description: This is a digitally signed message part
Re: Radeon 9250 DRM in 7.2-RELEASE
On Mon, 2009-05-04 at 14:48 -0400, Steve Polyack wrote: Robert Noland wrote: Why is this drm2? Is this a multicard setup? Multicard doesn't work right now. If you aren't using more than one card, can you disable whatever else drm is attaching to? robert. This is something funny I had to deal with initially. There is *no* drm0 or drm1 being probed. Consequently, there is only one entry in /dev/dri/, card2. As a result, Xorg doesn't even recognize card2 as a source for DRM (probably due to what you said). In the past, I have symlinked /dev/dri/card2 to /dev/dri/card0 and Xorg would work correctly, utilizing DRM. I have an onboard Intel VGA device, but as far as I know it is disabled. I can double check, but as I've noted things have worked fine with the above tweak until upgrading to 7.2-RELEASE. Can you send me a pciconf -lvb robert. Thanks, ___ freebsd-...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-x11 To unsubscribe, send any mail to freebsd-x11-unsubscr...@freebsd.org -- Robert Noland rnol...@freebsd.org FreeBSD signature.asc Description: This is a digitally signed message part
Re: Radeon 9250 DRM in 7.2-RELEASE
On Mon, 2009-05-04 at 15:56 -0400, Steve Polyack wrote: vgap...@pci0:0:2:0:class=0x038000 card=0x01ad1028 chip=0x27728086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82945G Integrated Graphics Controller' class = display bar [10] = type Memory, range 32, base 0xfeb0, size 524288, enabled bar [14] = type I/O Port, range 32, base 0xe898, size 8, enabled bar [18] = type Prefetchable Memory, range 32, base 0xd000, size 268435456, enabled bar [1c] = type Memory, range 32, base 0xfeac, size 262144, enabled vgap...@pci0:0:2:1:class=0x038000 card=0x01ad1028 chip=0x27768086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82945G Integrated Graphics Controller' class = display bar [10] = type Memory, range 32, base 0xfeb8, size 524288, enabled Ok, they are at least partially disabled... I wonder if a BIOS update would help. Anyway, the garbled screen issue is usually associated with the caching method used on the PCI GART. On IGP chips we force the GART to be uncacheable. On PCI chips they are supposed to be able to snoop the bus and DTRT. All of the fixes for memory caching should be in 7. Please try the attached patch and see if that makes a difference. robert. -- Robert Noland rnol...@freebsd.org FreeBSD Index: radeon_cp.c === --- radeon_cp.c (revision 191793) +++ radeon_cp.c (working copy) @@ -1429,7 +1429,7 @@ dev_priv-gart_info.mapping.size = dev_priv-gart_info.table_size; - drm_core_ioremap_wc(dev_priv-gart_info.mapping, dev); + drm_core_ioremap(dev_priv-gart_info.mapping, dev); dev_priv-gart_info.addr = dev_priv-gart_info.mapping.handle; signature.asc Description: This is a digitally signed message part
Re: Radeon 9250 DRM in 7.2-RELEASE
On Mon, 2009-05-04 at 16:36 -0400, Steve Polyack wrote: Robert Noland wrote: Ok, they are at least partially disabled... I wonder if a BIOS update would help. Anyway, the garbled screen issue is usually associated with the caching method used on the PCI GART. On IGP chips we force the GART to be uncacheable. On PCI chips they are supposed to be able to snoop the bus and DTRT. All of the fixes for memory caching should be in 7. Please try the attached patch and see if that makes a difference. robert. Unfortunately, this didn't help. I should also clarify what I'm seeing, as it's not complete garbage as I thought. I have a dual monitor setup, side-by-side using xrandr. When I start X (xfce4) with drm available, the left monitor (primary) is a sold light shade of blue, except for a black corner which is maybe 10pix square. The right monitor displays my typical background image with another black box over part of it. If it shift back to the console and then back into X, I can see the outlines of my startup windows, but they contain garbage and the outlines are fuzzed with green and magenta garbage. ok, how about this one... If this doesn't do it, then we need to start digging... robert. -- Robert Noland rnol...@freebsd.org FreeBSD Index: ati_pcigart.c === --- ati_pcigart.c (revision 191793) +++ ati_pcigart.c (working copy) @@ -83,7 +83,7 @@ } flags = BUS_DMA_WAITOK | BUS_DMA_ZERO; - if (gart_info-gart_reg_if == DRM_ATI_GART_IGP) +// if (gart_info-gart_reg_if == DRM_ATI_GART_IGP) flags |= BUS_DMA_NOCACHE; ret = bus_dmamem_alloc(dmah-tag, dmah-vaddr, flags, dmah-map); signature.asc Description: This is a digitally signed message part
Re: Radeon 9250 DRM in 7.2-RELEASE
On Mon, 2009-05-04 at 17:41 -0400, Steve Polyack wrote: Robert Noland wrote: ok, how about this one... If this doesn't do it, then we need to start digging... robert. No change when using this patch either. I've also updated to the latest BIOS and have ensured that the onboard Intel adapter is as disabled as it can get. I can provide you some photos of the screen behavior if you think it may help. Thanks again so far! Ok, so to start with, we need an xorg log and conf. If you kldload radeon.ko before starting X then you can set hw.dri.0.debug=1 which will dump a bunch of drm debugging into /var/log/messages. That would be useful. Also having a look at memcontrol list might be a good idea. robert. ___ freebsd-...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-x11 To unsubscribe, send any mail to freebsd-x11-unsubscr...@freebsd.org -- Robert Noland rnol...@freebsd.org FreeBSD signature.asc Description: This is a digitally signed message part
Re: dri + ATI: dramatic performance slowdown
On Fri, 2009-05-01 at 07:52 +0200, Oliver Lehmann wrote: Hi Robert Oliver Lehmann wrote: Robert Noland wrote: It still might be useful... Option BusType PCI any new here? No, sorry... I got distracted by over heating and trashing the disk in my test machine... Note to self... Saphire cards shouldn't exhaust into drive cage... robert. -- Robert Noland rnol...@freebsd.org FreeBSD signature.asc Description: This is a digitally signed message part
Re: dri + ATI: dramatic performance slowdown
On Sun, 2009-04-26 at 10:21 +0200, Oliver Lehmann wrote: Robert Noland wrote: It also just occurred to me... I'm running radeonhd right now... I will switch off to radeon in a bit and see if things change. Ok So I don't need to force it to PCI mode now? ;) If I should nevertheless - how do I do this? It still might be useful... Option BusType PCI robert. -- Robert Noland rnol...@freebsd.org FreeBSD signature.asc Description: This is a digitally signed message part
Re: dri + ATI: dramatic performance slowdown
On Sat, 2009-04-25 at 10:19 +0200, Oliver Lehmann wrote: Oliver Lehmann wrote: Robert Noland wrote: Hrm, that is an HD 3850... Same as I am running now... Do you have to remain on console for a period of time, or does just switching back and forth crash the gpu? just switching back is enough. I'm not sure if this is important or if this is standard. When switching back to the console I get a [drm] Resetting GPU (or something like this) line. This is normal for the ati driver. And - it is the AGP version as stated in the initial posting of this thread. Right, I forgot that this was AGP... robert. -- Robert Noland rnol...@freebsd.org FreeBSD signature.asc Description: This is a digitally signed message part
Re: dri + ATI: dramatic performance slowdown
On Sat, 2009-04-25 at 10:19 +0200, Oliver Lehmann wrote: Oliver Lehmann wrote: Robert Noland wrote: Hrm, that is an HD 3850... Same as I am running now... Do you have to remain on console for a period of time, or does just switching back and forth crash the gpu? just switching back is enough. I'm not sure if this is important or if this is standard. When switching back to the console I get a [drm] Resetting GPU (or something like this) line. And - it is the AGP version as stated in the initial posting of this thread. What happens if you force it into pci mode? robert. -- Robert Noland rnol...@freebsd.org FreeBSD signature.asc Description: This is a digitally signed message part
Re: dri + ATI: dramatic performance slowdown
On Sat, 2009-04-25 at 10:19 +0200, Oliver Lehmann wrote: Oliver Lehmann wrote: Robert Noland wrote: Hrm, that is an HD 3850... Same as I am running now... Do you have to remain on console for a period of time, or does just switching back and forth crash the gpu? just switching back is enough. I'm not sure if this is important or if this is standard. When switching back to the console I get a [drm] Resetting GPU (or something like this) line. And - it is the AGP version as stated in the initial posting of this thread. It also just occurred to me... I'm running radeonhd right now... I will switch off to radeon in a bit and see if things change. robert. -- Robert Noland rnol...@freebsd.org FreeBSD signature.asc Description: This is a digitally signed message part
Re: 7.2-PRERELEASE X-server hang in drmwtq
On Sat, 2009-04-25 at 16:24 +0400, Artem Kim wrote: I checked 7.2 RC2 problem still here. I found a way to reproduce the problem easily. I used KDE 4.2.2 composite manager is enabled. The problem occurs when two applications run in a way that their window to appear at the same time. Ok, luckily I don't think that KDE is important... compositing might be. Can you give a more complete example of how to trigger the hang? I don't have any r300 based cards handy right now. AMD is sending them though, so it shouldn't be long... I can reproduce the problem on the cards Radeon 9800 XT (AMD64 UP) and Radeon X550 (AMD64 SMP). Are these AGP or PCI(e)? robert. ___ freebsd-...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-x11 To unsubscribe, send any mail to freebsd-x11-unsubscr...@freebsd.org -- Robert Noland rnol...@freebsd.org FreeBSD signature.asc Description: This is a digitally signed message part
Re: 7.2-PRERELEASE X-server hang in drmwtq
On Sat, 2009-04-25 at 20:37 +0400, Artem Kim wrote: On Saturday 25 April 2009 19:18:43 Robert Noland wrote: On Sat, 2009-04-25 at 16:24 +0400, Artem Kim wrote: I checked 7.2 RC2 problem still here. I found a way to reproduce the problem easily. I used KDE 4.2.2 composite manager is enabled. The problem occurs when two applications run in a way that their window to appear at the same time. Ok, luckily I don't think that KDE is important... compositing might be. Can you give a more complete example of how to trigger the hang? I don't have any r300 based cards handy right now. AMD is sending them though, so it shouldn't be long... I can reproduce the problem on the cards Radeon 9800 XT (AMD64 UP) and Radeon X550 (AMD64 SMP). Are these AGP or PCI(e)? robert. I'm using KDE 4.2.2 as a test. The problem occurs only if the composite manager is enabled. The problem occurs spontaneously when the new window is created. A reliable way to reproduce the problem - run concurrently several applications that create new windows. Typically, a window appears on the screen with some delay after starting the application. Time delays occur (drawing) of a new window depending on the application. The problem occurs if one or more applications have opened new windows (the window starts to draw on the screen) at about the same time. You can run fast (this is important) one after another Konqueror, System Settings, File Manager, it is enough to reproduce the problem. The problem looks like this: X-server in drmwtq state. The screen freezes or just turns off. The keyboard sometimes works, sometimes not. I used a 9800 AGP at the UP and X550 PCI-E to the SMP AMD64 system. Ok, so my test is under gnome with metacity in composite mode. Using zsh (I think bash can do this also) balrog% for ((i=0 ; i 5 ; i++ )) do firefox ;done So, I've launched 5 firefox and 10 xterms... Neither produce the hang. Sitting in drmwtq means that you are waiting on the rendering engine to catch up and send you an interrupt. Probably the best debugging that we are going to get is by: booting the system without starting X, kldload radeon and then set sysctl hw.dri.0.debug=1 and start X/KDE... trigger the lockup and send me the output of the debugging from /var/log/messages. robert. -- Robert Noland rnol...@freebsd.org FreeBSD signature.asc Description: This is a digitally signed message part
Re: 7.2-PRERELEASE X-server hang in drmwtq
On Sat, 2009-04-25 at 20:37 +0400, Artem Kim wrote: On Saturday 25 April 2009 19:18:43 Robert Noland wrote: On Sat, 2009-04-25 at 16:24 +0400, Artem Kim wrote: I checked 7.2 RC2 problem still here. I found a way to reproduce the problem easily. I used KDE 4.2.2 composite manager is enabled. The problem occurs when two applications run in a way that their window to appear at the same time. Ok, luckily I don't think that KDE is important... compositing might be. Can you give a more complete example of how to trigger the hang? I don't have any r300 based cards handy right now. AMD is sending them though, so it shouldn't be long... I can reproduce the problem on the cards Radeon 9800 XT (AMD64 UP) and Radeon X550 (AMD64 SMP). Are these AGP or PCI(e)? robert. I'm using KDE 4.2.2 as a test. The problem occurs only if the composite manager is enabled. The problem occurs spontaneously when the new window is created. A reliable way to reproduce the problem - run concurrently several applications that create new windows. Typically, a window appears on the screen with some delay after starting the application. Time delays occur (drawing) of a new window depending on the application. The problem occurs if one or more applications have opened new windows (the window starts to draw on the screen) at about the same time. You can run fast (this is important) one after another Konqueror, System Settings, File Manager, it is enough to reproduce the problem. The problem looks like this: X-server in drmwtq state. The screen freezes or just turns off. The keyboard sometimes works, sometimes not. I used a 9800 AGP at the UP and X550 PCI-E to the SMP AMD64 system. Actually, I do have a patch that might be relevant... Try, http://people.freebsd.org/~rnoland/drm_radeon-copyin-fix-try2.patch robert. -- Robert Noland rnol...@freebsd.org FreeBSD signature.asc Description: This is a digitally signed message part
Re: 7.2-PRERELEASE X-server hang in drmwtq
On Sun, 2009-04-26 at 00:18 +0400, Artem Kim wrote:
On Saturday 25 April 2009 21:15:16 you wrote:
Ok, so my test is under gnome with metacity in composite mode. Using
zsh (I think bash can do this also)
balrog% for ((i=0 ; i 5 ; i++ )) do firefox ;done
So, I've launched 5 firefox and 10 xterms... Neither produce the hang.
Sitting in drmwtq means that you are waiting on the rendering engine to
catch up and send you an interrupt. Probably the best debugging that we
are going to get is by:
booting the system without starting X, kldload radeon and then set
sysctl hw.dri.0.debug=1 and start X/KDE... trigger the lockup and send
me the output of the debugging from /var/log/messages.
robert.
I used the following script:
#!/bin/sh
TRY = 5
while [$ (TRY)-gt 0]; do
# Konqueror
okteta
kcalc
kwrite
TRY = `expr $ (TRY) - 1`
done
sleep 30
killall konqueror
killall okteta
killall kcalc
killall kwrite
If I set hw.dri.0.debug = 1 the problem is not reproducing, even at very
big
values of ${TRY}.
However if hw.dri.0.debug = 0 one pass reproduces the problem.
If I set hw.dri.0.debug=1 _after_ the server hang, I see the message:
Apr 25 23:44:04 test kernel: [drm: pid782: drm_ioctl] pid = 782, cmd =
0x80046457, nr = 0x57, dev 0xff0001556d00, auth = 1
Apr 25 23:44:04 test kernel: [drm: pid782: drm_ioctl] returning 4
Ok, so what this is saying is that pid 782 is waiting on the rendering
engine to catch up. The returning 4 part says that we were
interrupted while we were waiting. libdrm retries the wait, which
should return immediately if the engine has caught up now. It never
appears to catch up, so either the counter is getting corrupted or we
failed to get the commands submitted to the card like we thought, or we
have locked up the GPU.
What does it take to recover from this? Do you have to reboot, or is
killing the process that initiated the wait sufficient?
robert.
Apr 25 23:44:04 test kernel: [drm: pid782: drm_ioctl] pid = 782, cmd =
0x80046457, nr = 0x57, dev 0xff0001556d00, auth = 1
Apr 25 23:44:04 test kernel: [drm: pid782: drm_ioctl] returning 4
Apr 25 23:44:04 test kernel: [drm: pid782: drm_ioctl] pid = 782, cmd =
0x80046457, nr = 0x57, dev 0xff0001556d00, auth = 1
Apr 25 23:44:04 test kernel: [drm: pid782: drm_ioctl] returning 4
Apr 25 23:44:04 test kernel: [drm: pid782: drm_ioctl] pid = 782, cmd =
0x80046457, nr = 0x57, dev 0xff0001556d00, auth = 1
Apr 25 23:44:04 test kernel: [drm: pid782: drm_ioctl] returning 4
Apr 25 23:44:04 test kernel: [drm: pid782: drm_ioctl] pid = 782, cmd =
0x80046457, nr = 0x57, dev 0xff0001556d00, auth = 1
Apr 25 23:44:04 test kernel: [drm: pid782: drm_ioctl] returning 4
I try to apply this patch:
http://people.freebsd.org/ ~ rnoland/drm_radeon-copyin-fix-try2.patch
In my case the problem remains.
--
Robert Noland rnol...@freebsd.org
FreeBSD
signature.asc
Description: This is a digitally signed message part
Re: dri + ATI: dramatic performance slowdown
On Fri, 2009-04-24 at 15:11 +0200, Oliver Lehmann wrote: Hi Robert, there is one problem left here. When changing from inside X11 to the console (Ctrl+F1), and then changing back to X11 (Alt+F9), the the monitor keeps being black. From a remote login I can see, that Xorg is now unkillable and eats all my CPU. dmesg shows: info: [drm] wait idle failed status : 0xA0003030 0x0003 over and over (looks like the buffer can only keep 1090 lines ;)) All I'm left with is rebooting the system :( Which chip is this with? Vt switching seems fine for me on x1650 and HD 3850. I don't think that I have anything substantial in my tree that isn't in -STABLE for ATI. robert. -- Robert Noland rnol...@freebsd.org FreeBSD signature.asc Description: This is a digitally signed message part
Re: dri + ATI: dramatic performance slowdown
On Fri, 2009-04-24 at 19:52 +0200, Oliver Lehmann wrote: Hi Robert, Robert Noland wrote: On Fri, 2009-04-24 at 15:11 +0200, Oliver Lehmann wrote: info: [drm] wait idle failed status : 0xA0003030 0x0003 Which chip is this with? vgap...@pci0:1:0:0: class=0x03 card=0x00281787 chip=0x95151002 rev=0x00 hdr=0x00 vendor = 'ATI Technologies Inc' class = display subclass = VGA Hrm, that is an HD 3850... Same as I am running now... Do you have to remain on console for a period of time, or does just switching back and forth crash the gpu? robert. -- Robert Noland rnol...@freebsd.org FreeBSD signature.asc Description: This is a digitally signed message part
Re: dri + ATI: dramatic performance slowdown
On Wed, 2009-04-22 at 17:39 -0700, Norbert Papke wrote: 0x0/0x1 BIOS write-back set-by-firmware active 0x1/0x4000 BIOS write-back set-by-firmware active 0xc000/0x4000 BIOS uncacheable set-by-firmware active MTRR is failing in many cases... It seems that your BIOS is doing what both of my newer machines are doing and setting a global range to write-back. I'm also guessing that 0xc000 is your framebuffer. We aren't allowed to overlap either of these ranges with a write combined region according to the specs. We would have to handle splitting/merging regions which we don't currently do. I looked at this just the other day, but it is reasonably complex to make that work right and accommodate all of the merging/splitting of regions. We are allowed to use PAT on either of these types of regions to enable write-combining. The drm code already does this for some allocations that are not mapped to user space. The problem with PAT is that all mappings of a given region need to have the same type and we don't currently have any way to specify that for user space mappings. This is fwiw, the last of Nvidia's feature requests as well. I've started looking at it, but I have a lot of learning to do on the vm system still. robert. -- Robert Noland rnol...@freebsd.org FreeBSD signature.asc Description: This is a digitally signed message part
Re: dri + ATI: dramatic performance slowdown
On Wed, 2009-04-22 at 19:38 -0700, Norbert Papke wrote: On April 22, 2009, Robert Noland wrote: On Wed, 2009-04-22 at 17:39 -0700, Norbert Papke wrote: 0x0/0x1 BIOS write-back set-by-firmware active 0x1/0x4000 BIOS write-back set-by-firmware active 0xc000/0x4000 BIOS uncacheable set-by-firmware active MTRR is failing in many cases... It seems that your BIOS is doing what both of my newer machines are doing and setting a global range to write-back. I'm also guessing that 0xc000 is your framebuffer. Correct. The framebuffer starts at 0xd000, still covered by that last range. We aren't allowed to overlap either of these ranges with a write combined region according to the specs. We would have to handle splitting/merging regions which we don't currently do. I looked at this just the other day, but it is reasonably complex to make that work right and accommodate all of the merging/splitting of regions. We are allowed to use PAT on either of these types of regions to enable write-combining. The drm code already does this for some allocations that are not mapped to user space. The problem with PAT is that all mappings of a given region need to have the same type and we don't currently have any way to specify that for user space mappings. This is fwiw, the last of Nvidia's feature requests as well. I've started looking at it, but I have a lot of learning to do on the vm system still. Thanks for taking the time to explain. Your posts are always very informative. I am learning quite a lot about the complexities involved. There is yet another thing I don't understand. With other graphics cards, including my G45 internal graphics adaptor, the /dev/agpgart device is created. I don't see this device with the Radeon card. Is this expected because it is not needed for PCIe? That is correct. If you have an agp based chipset, then the agp wriver will attach to your chipset and give you an agpgart device. All Intel graphics chips emulate AGP, so you will always have an agpgart device. With PCI-E based cards such as ATI or Nvidia, they don't use AGP. In those situations, we use a PCI GART (ati_pcigart.c) and map scatter gather memory into the GART. Nouveau is very similar in that respect. robert. Cheers, -- Norbert Papke. npa...@acm.org -- Robert Noland rnol...@freebsd.org FreeBSD signature.asc Description: This is a digitally signed message part
Re: dri + ATI: dramatic performance slowdown
On Tue, 2009-04-21 at 10:26 +0200, Ronald Klop wrote: On Mon, 20 Apr 2009 15:26:20 +0200, Oliver Lehmann lehm...@ans-netz.de wrote: Hi, as I found out in the meantime - the following described problem can be only worked around when 'Load dri' is removed from the server section, and 'Option DRI true' is removed from the Device section. Otherwise: I've synced my pre-drm-changes 7-STABLE to the latest 7-STABLE. Now the grafic performance in xorg decreased dramatically. Moving a window or resizing a window makes me feel sent back 15 years ago ;). I can see the window resizing. The popup of an window is fast, but moving it around or scrolling... jesus that is what I call slow. Firefox is nearly not usable for example :( I wonder what is causing this. I'm using a ATI Radeon HD3850 in it's AGP version (probably kinda uncommon). olivl...@kartoffel olivleh1 dmesg | grep drm drm0: ATI Radeon HD3850 on vgapci0 vgapci0: child drm0 requested pci_enable_busmaster info: [drm] AGP at 0xd800 128MB info: [drm] Initialized radeon 1.29.0 20080528 info: [drm] Setting GART location based on new memory map info: [drm] Loading RV670 CP Microcode info: [drm] Loading RV670 PFP Microcode info: [drm] Resetting GPU info: [drm] writeback test succeeded in 1 usecs drm0: [ITHREAD] olivl...@kartoffel olivleh1 pkg_info | grep radeon xf86-video-radeonhd-1.2.5 X.Org ati RadeonHD display driver olivl...@kartoffel olivleh1 From my xorg.conf: Section Module Loaddbe Loadfreetype Loadglx Loaddri EndSection Section Device Identifier ATI1 BoardName ATI Radeon Driver radeonhd BusID PCI:1:0:0 Option Monitor-DVI-I_1/digital Syncmaster DVI1 Option Monitor-DVI-I_2/digital Syncmaster DVI2 Option DRI true EndSection the whole xorg.conf can be found here: http://cvs.olli.homeip.net/index.html/configs/xorg.conf?rev=1.9 Is this expected to happen with DRI enabled? Hi, X.org is quite good in autodetecting your hardware and running without a config. It works for me out-of-the-box with my Radeon HD 2400 XT and Radeon HD 2600 XT. (But I'm not using agp.) You can also try the xf86-video-ati driver. It works very well with 2d accell. (I'm using it also.) If you don't have a config, you won't get drm as it defaults to off on r6/7xx hardware right now. robert. Ronald. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org -- Robert Noland rnol...@freebsd.org FreeBSD signature.asc Description: This is a digitally signed message part
Re: dri + ATI: dramatic performance slowdown
On Tue, 2009-04-21 at 16:26 +0200, Oliver Lehmann wrote: Ronald Klop wrote: X.org is quite good in autodetecting your hardware and running without a config. It works for me out-of-the-box with my Radeon HD 2400 XT and Radeon HD 2600 XT. (But I'm not using agp.) You can also try the xf86-video-ati driver. It works very well with 2d accell. (I'm using it also.) When I tried xf86-video-ati in the past, it didn't deteced my ChipID so I was forced to use the radeonhd driver (I even have to manually patch the official generic AMD/ATI Windows XP driver to get support for my card ;)). I now retested the driver and my Xorg was left unresponsible after my loginmanager slim tried to fire up my windowmanager. I only could kill it from an other system, switching back to the console and back to X11 left my Xorg in an unkillable state while eating up all my CPU time. So for my xf86-video-ati is not an option :( I'm also not sure how the RV610 or RV630 chipsets are different to my RV670. (--) PCI:*(0...@1:0:0) ATI Technologies Inc RV670PRO [Radeon HD 3850] rev 0, Mem @ 0xd000/268435456, 0xfe8e/65536, I/O @ 0xb000/256, BIOS @ 0x/65536 I am running this right now... Though, it is PCI-E, not AGP... Works with both radeon and radeonhd drivers (current from ports). I expect the issue is with AGP, but you need to be setting Option AccelMethod EXA on your hardware as well. robert. -- Robert Noland rnol...@freebsd.org FreeBSD signature.asc Description: This is a digitally signed message part
Re: dri + ATI: dramatic performance slowdown
On Tue, 2009-04-21 at 16:04 +0200, Oliver Lehmann wrote: 0xd800/0x800 drm write-combine active Ok, looks like MTRR is working for you, so that isn't it... robert. -- Robert Noland rnol...@freebsd.org FreeBSD signature.asc Description: This is a digitally signed message part
Re: dri + ATI: dramatic performance slowdown
On Tue, 2009-04-21 at 19:27 +0200, Oliver Lehmann wrote: Robert Noland wrote: but you need to be setting Option AccelMethod EXA on your hardware as well. (**) RADEONHD(0): Option DRI true (**) RADEONHD(0): Selected EXA 2D acceleration. (II) RADEONHD(0): Unknown card detected: 0x9515:0x1787:0x0028. Great - this did the trick. Now the system works like it was before and I can enjoy DRI - resizing videos and so on works now like a charm - like some years ago with my old ATI2950 ;) Resizing windows, scrolling content is now fast. Is there a FAQ list where I could have found it by searching on my own? The r6/7xx drm support is new. Best place is freebsd-x11@ for late breaking details on currently supported graphics cards from all vendors. I am now working with new 3d bits that AMD has released for these cards. It isn't quite ready yet, but we are getting closer... robert. -- Robert Noland rnol...@freebsd.org FreeBSD signature.asc Description: This is a digitally signed message part
Re: dri + ATI: dramatic performance slowdown
On Mon, 2009-04-20 at 15:26 +0200, Oliver Lehmann wrote: Hi, as I found out in the meantime - the following described problem can be only worked around when 'Load dri' is removed from the server section, and 'Option DRI true' is removed from the Device section. Otherwise: I've synced my pre-drm-changes 7-STABLE to the latest 7-STABLE. Now the grafic performance in xorg decreased dramatically. Moving a window or resizing a window makes me feel sent back 15 years ago ;). I can see the window resizing. The popup of an window is fast, but moving it around or scrolling... jesus that is what I call slow. Firefox is nearly not usable for example :( I wonder what is causing this. I'm using a ATI Radeon HD3850 in it's AGP version (probably kinda uncommon). olivl...@kartoffel olivleh1 dmesg | grep drm drm0: ATI Radeon HD3850 on vgapci0 vgapci0: child drm0 requested pci_enable_busmaster info: [drm] AGP at 0xd800 128MB Can you show me the output of memcontrol list, with drm enabled. robert. info: [drm] Initialized radeon 1.29.0 20080528 info: [drm] Setting GART location based on new memory map info: [drm] Loading RV670 CP Microcode info: [drm] Loading RV670 PFP Microcode info: [drm] Resetting GPU info: [drm] writeback test succeeded in 1 usecs drm0: [ITHREAD] olivl...@kartoffel olivleh1 pkg_info | grep radeon xf86-video-radeonhd-1.2.5 X.Org ati RadeonHD display driver olivl...@kartoffel olivleh1 From my xorg.conf: Section Module Loaddbe Loadfreetype Loadglx Loaddri EndSection Section Device IdentifierATI1 BoardName ATI Radeon Driver radeonhd BusID PCI:1:0:0 Option Monitor-DVI-I_1/digital Syncmaster DVI1 Option Monitor-DVI-I_2/digital Syncmaster DVI2 OptionDRI true EndSection the whole xorg.conf can be found here: http://cvs.olli.homeip.net/index.html/configs/xorg.conf?rev=1.9 Is this expected to happen with DRI enabled? -- Robert Noland rnol...@freebsd.org FreeBSD signature.asc Description: This is a digitally signed message part
Re: page fault in sis.ko / drm.ko
On Sat, 2009-04-18 at 19:13 +0200, cpghost wrote:
Could a drm guru please have a look at kern/133554?
Thanks,
-cpghost.
Give this patch a try, it looks like the sis driver doesn't have irq's.
robert.
--
Robert Noland rnol...@freebsd.org
FreeBSD
Index: dev/drm/drm_drv.c
===
--- dev/drm/drm_drv.c (revision 190987)
+++ dev/drm/drm_drv.c (working copy)
@@ -134,7 +134,7 @@
.d_flags = D_TRACKCLOSE
};
-int drm_msi = 1; /* Enable by default. */
+static int drm_msi = 1; /* Enable by default. */
TUNABLE_INT(hw.drm.msi, drm_msi);
static struct drm_msi_blacklist_entry drm_msi_blacklist[] = {
@@ -228,28 +228,31 @@
dev-pci_vendor = pci_get_vendor(dev-device);
dev-pci_device = pci_get_device(dev-device);
- if (drm_msi
- !drm_msi_is_blacklisted(dev-pci_vendor, dev-pci_device)) {
- msicount = pci_msi_count(dev-device);
- DRM_DEBUG(MSI count = %d\n, msicount);
- if (msicount 1)
- msicount = 1;
+ if (drm_core_check_feature(dev, DRIVER_HAVE_IRQ)) {
+ if (drm_msi
+ !drm_msi_is_blacklisted(dev-pci_vendor, dev-pci_device)) {
+ msicount = pci_msi_count(dev-device);
+ DRM_DEBUG(MSI count = %d\n, msicount);
+ if (msicount 1)
+msicount = 1;
- if (pci_alloc_msi(dev-device, msicount) == 0) {
- DRM_INFO(MSI enabled %d message(s)\n, msicount);
- dev-msi_enabled = 1;
- dev-irqrid = 1;
+ if (pci_alloc_msi(dev-device, msicount) == 0) {
+DRM_INFO(MSI enabled %d message(s)\n,
+msicount);
+dev-msi_enabled = 1;
+dev-irqrid = 1;
+ }
}
- }
- dev-irqr = bus_alloc_resource_any(dev-device, SYS_RES_IRQ,
- dev-irqrid, RF_SHAREABLE);
- if (!dev-irqr) {
- return ENOENT;
+ dev-irqr = bus_alloc_resource_any(dev-device, SYS_RES_IRQ,
+ dev-irqrid, RF_SHAREABLE);
+ if (!dev-irqr) {
+ return ENOENT;
+ }
+
+ dev-irq = (int) rman_get_start(dev-irqr);
}
- dev-irq = (int) rman_get_start(dev-irqr);
-
mtx_init(dev-dev_lock, drmdev, NULL, MTX_DEF);
mtx_init(dev-irq_lock, drmirq, NULL, MTX_DEF);
mtx_init(dev-vbl_lock, drmvbl, NULL, MTX_DEF);
signature.asc
Description: This is a digitally signed message part
Re: powerd broken
On Fri, 2009-04-10 at 16:53 +0200, Dominic Fandrey wrote: Robert Noland wrote: I've been working on the Intel vblank / irq issues. Every time I commit something thinking that I have it resolved, it isn't. So I'm waiting on hardware to arrive that will let me test this all more thoroughly. I do have a patch that I think fixes most of the issues on Intel, but the ddx driver is still doing some silly things that cause issues in some cases. I *think* the only outstanding issue I have with Intel is if something is rendering (synced to vblank or not) when the display goes into dpms sleep, there isn't anything to block that app, so it renders as hard as it can even though it isn't being displayed. In reality, this probably isn't a huge issue, but running gears while the display is asleep keeps the cpu at 100%, which isn't ideal. Normal apps that aren't trying to draw as fast as they can, shouldn't cause an issue. With the latest drm, the IRQ craziness is gone. However, the crappy performance remains. 2 months ago a RELENG_7 with all packages up to date yielded 124fps in a q3 timedemo that now yields 80fps. Things are still not quite right with the Intel driver. But performance regressions are reported across Linux as well. A little of this might be us, but most of it is Intel... robert. Regards -- Robert Noland rnol...@freebsd.org FreeBSD signature.asc Description: This is a digitally signed message part
Re: no USB mice detected on GA-MA74GM-S2
PnP devices Device configuration finished. Reducing kern.maxvnodes 130270 - 10 procfs registered lapic: Divisor 2, Frequency 100213866 hz Timecounter TSC frequency 2505346537 Hz quality -100 Timecounters tick every 1.000 msec lo0: bpf attached ata0-slave: pio=PIO4 wdma=WDMA2 udma=UDMA40 cable=40 wire acd0: setting PIO4 on IXP700 chip acd0: DMA limited to UDMA33, device found non-ATA66 cable acd0: setting UDMA33 on IXP700 chip acd0: LITE-ON COMBO SOHC-5232K/NK06 CDRW drive at ata0 as slave acd0: read 4134KB/s (8958KB/s) write 8958KB/s (8958KB/s), 2048KB buffer, UDMA33 acd0: Reads: CDR, CDRW, CDDA stream, DVDROM, DVDR, packet acd0: Writes: CDR, CDRW, test write, burnproof acd0: Audio: play, 255 volume levels acd0: Mechanism: ejectable tray, unlocked acd0: Medium: CD-ROM 120mm data disc ata2-master: pio=PIO4 wdma=WDMA2 udma=UDMA133 cable=40 wire ad4: 305244MB WDC WD3200AVJS-63WDA0 12.01B02 at ata2-master SATA300 ad4: 625140335 sectors [620178C/16H/63S] 16 sectors/interrupt 1 depth queue GEOM: new disk ad4 acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00 (probe0:ata0:0:1:0): error 22 (probe0:ata0:0:1:0): Unretryable Error (probe0:ata0:0:1:0): Down reving Protocol Version from 2 to 0? acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00 (probe0:ata0:0:1:0): error 22 (probe0:ata0:0:1:0): Unretryable Error pass0 at ata0 bus 0 target 1 lun 0 pass0: LITE-ON COMBO SOHC-5232K NK06 Removable CD-ROM SCSI-0 device pass0: 33.000MB/s transfers GEOM: new disk cd0 cd0 at ata0 bus 0 target 1 lun 0 cd0: LITE-ON COMBO SOHC-5232K NK06 Removable CD-ROM SCSI-0 device cd0: 33.000MB/s transfers cd0: cd present [294606 x 2048 byte records] SMP: AP CPU #1 Launched! cpu1 AP: ID: 0x0100 VER: 0x80050010 LDR: 0x DFR: 0x lint0: 0x00010700 lint1: 0x0400 TPR: 0x SVR: 0x01ff timer: 0x000200ef therm: 0x0001 err: 0x0001 pcm: 0x0001 ioapic0: Assigning ISA IRQ 1 to local APIC 0 ioapic0: Assigning ISA IRQ 7 to local APIC 1 ioapic0: Assigning ISA IRQ 9 to local APIC 0 ioapic0: Assigning ISA IRQ 14 to local APIC 1 ioapic0: Assigning PCI IRQ 16 to local APIC 0 ioapic0: Assigning PCI IRQ 17 to local APIC 1 ioapic0: Assigning PCI IRQ 18 to local APIC 0 ioapic0: Assigning PCI IRQ 19 to local APIC 1 ioapic0: Assigning PCI IRQ 20 to local APIC 0 ioapic0: Assigning PCI IRQ 22 to local APIC 1 scsi_cd.c::ioctl cmd=4400648b error=25 Trying to mount root from ufs:/dev/ad4s2a start_init: trying /sbin/init Linux ELF exec handler installed fuse4bsd: version 0.3.9-pre1, FUSE ABI 7.8 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org -- Robert Noland rnol...@freebsd.org FreeBSD signature.asc Description: This is a digitally signed message part
Re: powerd broken
On Sat, 2009-04-04 at 12:31 +0200, Dominic Fandrey wrote: Robert Noland wrote: On Fri, 2009-04-03 at 11:43 +0200, Dominic Fandrey wrote: Alexander Motin wrote: Dominic Fandrey wrote: I can rule out drm0 as the cause, because uhci0 is the only common presence in all occurrences of this problem. You have other examples? If you mean irq16: hdac0 uhci+ string, then + there means and some other devices, which in this case is probably drm0. There were some drm related commits last time and there are also some IRQ related problems were reported/patched in CURRENT recently. So I would not ignore this possibility without additional testing. Is there anything I can do, apart from turning off drm? This is really annoying (well, it eats a whole core while I'm compiling and it keeps the fans going, when the machine should be idle). Is there somehow I can generate useful information? Someone to send a kernel dump to? Use a radeon? ;( Nay, I use an Intel GM965. I've been working on the Intel vblank / irq issues. Every time I commit something thinking that I have it resolved, it isn't. So I'm waiting on hardware to arrive that will let me test this all more thoroughly. I do have a patch that I think fixes most of the issues on Intel, but the ddx driver is still doing some silly things that cause issues in some cases. I *think* the only outstanding issue I have with Intel is if something is rendering (synced to vblank or not) when the display goes into dpms sleep, there isn't anything to block that app, so it renders as hard as it can even though it isn't being displayed. In reality, this probably isn't a huge issue, but running gears while the display is asleep keeps the cpu at 100%, which isn't ideal. Normal apps that aren't trying to draw as fast as they can, shouldn't cause an issue. The other issue with my current patches is that I had to change around a fair amount of infrastructure code to try and fix Intel's brain damage, so I have to finish fixing the rest of the drivers so they don't break. I have Intel and radeon fixed, I just have to hit the more obscure drivers. robert. So it appears all I've got to do is wait. Correct me if I'm wrong. You can set the tuneable hw.drm.msi=0 for now and see if that helps. I haven't followed this whole thread, but the primary issue that people were having is that interrupts would not work after a vt switch with msi. So, it that isn't your issue, you may need to look elsewhere. robert. Regards -- Robert Noland rnol...@freebsd.org FreeBSD signature.asc Description: This is a digitally signed message part
Re: powerd broken
On Sat, 2009-04-04 at 10:01 -0700, Norbert Papke wrote: Hi Robert, On April 3, 2009, Robert Noland wrote: Use a radeon? ;( Is there any particular model of Radeon PCIe that you would recommend? Most all of them should work ok... You won't have 3d on r600+ just yet, but... I'm running on an x1650 right now. robert. Cheers, -- Norbert Papke. npa...@acm.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org -- Robert Noland rnol...@freebsd.org FreeBSD signature.asc Description: This is a digitally signed message part
Re: powerd broken
On Sat, 2009-04-04 at 12:24 -0700, Norbert Papke wrote: On April 4, 2009, Robert Noland wrote: On Sat, 2009-04-04 at 10:01 -0700, Norbert Papke wrote: Hi Robert, On April 3, 2009, Robert Noland wrote: Use a radeon? ;( Is there any particular model of Radeon PCIe that you would recommend? Most all of them should work ok... You won't have 3d on r600+ just yet, but... I'm running on an x1650 right now. After a quick check, everything available retail (locally) is r600 or newer. I'll keep an eye open for an older second hand card. It is rumored that 3d support for the r6/7xx chips will be available soon(tm). For now, you get EXA and Xv acceleration. robert. Thanks for information and all your hard work. -- Norbert Papke. npa...@acm.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org -- Robert Noland rnol...@freebsd.org FreeBSD signature.asc Description: This is a digitally signed message part
Re: powerd broken
On Fri, 2009-04-03 at 11:43 +0200, Dominic Fandrey wrote: Alexander Motin wrote: Dominic Fandrey wrote: I can rule out drm0 as the cause, because uhci0 is the only common presence in all occurrences of this problem. You have other examples? If you mean irq16: hdac0 uhci+ string, then + there means and some other devices, which in this case is probably drm0. There were some drm related commits last time and there are also some IRQ related problems were reported/patched in CURRENT recently. So I would not ignore this possibility without additional testing. Is there anything I can do, apart from turning off drm? This is really annoying (well, it eats a whole core while I'm compiling and it keeps the fans going, when the machine should be idle). Is there somehow I can generate useful information? Someone to send a kernel dump to? Use a radeon? ;( I've been working on the Intel vblank / irq issues. Every time I commit something thinking that I have it resolved, it isn't. So I'm waiting on hardware to arrive that will let me test this all more thoroughly. I do have a patch that I think fixes most of the issues on Intel, but the ddx driver is still doing some silly things that cause issues in some cases. I *think* the only outstanding issue I have with Intel is if something is rendering (synced to vblank or not) when the display goes into dpms sleep, there isn't anything to block that app, so it renders as hard as it can even though it isn't being displayed. In reality, this probably isn't a huge issue, but running gears while the display is asleep keeps the cpu at 100%, which isn't ideal. Normal apps that aren't trying to draw as fast as they can, shouldn't cause an issue. The other issue with my current patches is that I had to change around a fair amount of infrastructure code to try and fix Intel's brain damage, so I have to finish fixing the rest of the drivers so they don't break. I have Intel and radeon fixed, I just have to hit the more obscure drivers. robert. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org -- Robert Noland rnol...@freebsd.org FreeBSD signature.asc Description: This is a digitally signed message part
Re: 7.2-PRERELEASE X-server hang in drmwtq
On Fri, 2009-04-03 at 02:23 +0400, Artem Kim wrote: Hi. In last time, I have a problem with stability on my system: 7.2-PRERELEASE Thu Apr 2 20:20:31 MSD 2009 amd64 (UP); ati 9800-XT From time to time the x-server go in drmwtq state if the AIGLX is enabled. This usually happens when creating a new window. If I setup hw.dri.0.debug to 1, I get a lot of messages: [drm: pid1469: drm_ioctl] pid = 1469, cmd = 0x80046457, nr = 0x57, dev 0xff0001306800, auth = 1 [drm: pid1469: drm_ioctl] returning -1 I can see a recurring message in in ktrace: 1469 Xorg PSIG SIGALRM caught handler = 0x4dca90 mask = 0x0 code = 0x0 1469 Xorg CALL sigreturn (0x7fffe5b0) 1469 Xorg RET sigreturn JUSTRETURN 1469 Xorg CALL ioctl (0xa, 0x80046457, 0x8156e807c) 1469 Xorg RET ioctl RESTART The problems started after vblank rework in the STABLE. The first time I got a panic when i try to restart or shutdown x-server, but the problem with panic was solved (for me ;)) quickly. I am ready to provide any additional information. Many thanks for your work. Ok, I haven't really seen a problem on ati. Intel is a nightmare... I think that I have it all sorted out now, but in order to deal with some of this, I am having to rework all of the drivers. robert. ___ freebsd-...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-x11 To unsubscribe, send any mail to freebsd-x11-unsubscr...@freebsd.org -- Robert Noland rnol...@freebsd.org FreeBSD signature.asc Description: This is a digitally signed message part
Re: Xorg unbuildable - where to get: x11-xcb?
On Sat, 2009-03-28 at 21:04 -0700, Chris H wrote: Greetings, A fresh install of 7 followed by a cvsup to 7.2-PRE on the 26th results in an inability to build Xorg on the system. A cvsup only an hour ago provides no solution. An attempt at the following: cd /usr/ports/x11/xorg-minimal make produces the following error: ... checking pkg-config files for X11 are available... yes checking for LIBDRM... yes checking for DRI2PROTO... yes checking for DRIGL... gnome-config: not found configure: error: Package requirements (x11 xext xxf86vm xdamage xfixes x11-xcb xcb-glx) were not met: No package 'x11-xcb' found I'm guessing that you installed Xorg from the 7.0 packages. You need to rebuild everything that depends on libxcb. See UPDATING. robert. Consider adjusting the PKG_CONFIG_PATH environment variable if you installed software in a non-standard prefix. ... I was able to install /usr/ports/x11/xcb with no issue. But have no idea where to find x11-xcb. Where can I get it? thank you for all your time and consideration in this matter. --Chris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org -- Robert Noland rnol...@freebsd.org FreeBSD signature.asc Description: This is a digitally signed message part
Re: X.org hanging under 7.2-PRERELEASE
On Fri, 2009-03-27 at 19:44 -0700, David Johnson wrote: I update -STABLE about once a week. On Wednesday I update, and subsequently started getting hangs and lockups. This happens only when DRI is enabled. When DRI is disabled there is no problem. The seriousness can vary. Sometimes I can ssh in from another machine to reboot, other times I can't. The last time it hung, top showed X.org at 100.0% CPU. The previous time it was stuck with in a drmwtq state. The hang always occurs within twenty minutes of starting X. Actually, the commits that I might have expected to cause this, haven't been MFC'd yet. You probably did pick up the r6/7xx code in this update. I also made an error in the GART mapping code, but that should only effect pci(e) based radeons. It could also be related to the 6.12.1 ati driver. AGP mode 4x is always suspect as well, you might try reducing that to 2 or 1 and see if the problems go away. As for checking out an earlier release, with csup you just have to specify a date that you want to checkout. See man csup and reference the section titled CHECKOUT MODE. robert. Particulars: FreeBSD 7.2-PRERELEASE #2: Thu Mar 26 19:21:26 xf86-video-ati-6.12.1 (with Radeon X1550) kdelibs-4.2.1_1 Relevant portions of my xorg.conf: Section Module Load extmod Load dbe Load dri Load glx Load xtrap Load freetype EndSection Section Device Identifier Card0 Driver radeon ... Option AGPMode 4 Option RenderAccel on Option AccelMethod EXA EndSection I have had no prior problems with -STABLE. I have an Intel Q45 chipset, so I need to run -STABLE, and don't have the option of going back to -RELEASE. Is there any easy way to go back to an earlier -STABLE? -- Robert Noland rnol...@freebsd.org FreeBSD signature.asc Description: This is a digitally signed message part
Re: X.org hanging under 7.2-PRERELEASE
On Sat, 2009-03-28 at 01:34 -0500, Robert Noland wrote: On Fri, 2009-03-27 at 19:44 -0700, David Johnson wrote: I update -STABLE about once a week. On Wednesday I update, and subsequently started getting hangs and lockups. This happens only when DRI is enabled. When DRI is disabled there is no problem. The seriousness can vary. Sometimes I can ssh in from another machine to reboot, other times I can't. The last time it hung, top showed X.org at 100.0% CPU. The previous time it was stuck with in a drmwtq state. The hang always occurs within twenty minutes of starting X. Actually, the commits that I might have expected to cause this, haven't been MFC'd yet. You probably did pick up the r6/7xx code in this update. I also made an error in the GART mapping code, but that should only effect pci(e) based radeons. It could also be related to the 6.12.1 ati driver. AGP mode 4x is always suspect as well, you might try reducing that to 2 or 1 and see if the problems go away. As for checking out an earlier release, with csup you just have to specify a date that you want to checkout. See man csup and reference the section titled CHECKOUT MODE. Actually, hanging in drmwtq is usually an indication of the card going belly up, or of interrupts being trashed. Make sure that you aren't getting an interrupt storm on a shared irq with drm/vgapci. Can you send me a full dmesg after drm is loaded and an xorg.log. Without drm, you really don't use interrupts, so... robert. robert. Particulars: FreeBSD 7.2-PRERELEASE #2: Thu Mar 26 19:21:26 xf86-video-ati-6.12.1 (with Radeon X1550) kdelibs-4.2.1_1 Relevant portions of my xorg.conf: Section Module Load extmod Load dbe Load dri Load glx Load xtrap Load freetype EndSection Section Device Identifier Card0 Driver radeon ... Option AGPMode 4 Option RenderAccel on Option AccelMethod EXA EndSection I have had no prior problems with -STABLE. I have an Intel Q45 chipset, so I need to run -STABLE, and don't have the option of going back to -RELEASE. Is there any easy way to go back to an earlier -STABLE? -- Robert Noland rnol...@freebsd.org FreeBSD signature.asc Description: This is a digitally signed message part
