NFS/UDP and vfs.nfs.nfs_ip_paranoia=0 does not help
Hi, While trying to find out why our NSF/ZFS servers now hangs about once a week, I got hold of a similiar box, and got a bit more ambitious, I connected it via 2 NICs, to complicate things a bit, the server boots via pxeboot (ie, is datatless). After fiddling with the default gateway, adding -h to rpcbind and mountd, things seem ok, but UDP is 'problematic', I could do with TCP except that am-utils does a fsinfo via UDP when doing a /net/host and will hang the client. even with vfs.nfs.nfs_ip_paranoia=0, when the response from the server arrives with the 'wrong' ip, an ICMP destination unreachable (port unreachable) is replied. in short, on the client: this works: mount_nfs -o mntudp server-ip-vlanA:/mnt /mnt this fails: mount_nfs -o mntudp server-ip-vlanB:/mnt /mnt since the response is coming from server-ip-vlanA. Q: why does this work for TCP and fails for UDP Q: is there a workaround? danny ___ 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: NFS write corruption on 8.0-RELEASE
On Fri, Feb 12, 2010 at 04:08:55PM -0800, alan bryan wrote: --- On Fri, 2/12/10, Rick Macklem rmack...@uoguelph.ca wrote: From: Rick Macklem rmack...@uoguelph.ca Subject: Re: NFS write corruption on 8.0-RELEASE To: Dmitry Marakasov amd...@amdmi3.ru Cc: freebsd-hack...@freebsd.org, freebsd-stable@freebsd.org, John Baldwin j...@freebsd.org Date: Friday, February 12, 2010, 11:12 AM On Fri, 12 Feb 2010, Dmitry Marakasov wrote: I'm planning a massive testing for this weekend, including removing soft mount option and trying linux client/server. Btw, I forgot to mention that I'm experiencing other NFS problems from time to time, including death of a mount (that is, all processes that try to access it freeze; this cures itself in some time with a message server is alive again). Also I've seen another strange thing - not only the mount dies but the network is flooded with NFS traffic. Last time I've seen it quite a while ago, so I don't remember the circumstances and direction of the traffic. There are some patches at: http://people.freebsd.org/~rmacklem that may be relevant if you are using vanilla FreeBSD-8.0. (They're all now in stable/8, but are post-release of 8.0.) rick ___ 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 This is interesting: I've seen another strange thing - not only the mount dies but the network is flooded with NFS traffic. You might be able to see NFS flooding with: Write file on client. rm the file during the write on the server. The client now gets IO-errors, but keeps trying forever. Maybe it depends on the mechanism the client application uses to write the file. I never reported because my client is an old 7.0-stable system. I originally noticed it when downloading files with seamonkey on my client and mv it on the server to another partition before it was completely downloaded. -- B.Walter be...@bwct.de http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. ___ 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
Message rejected due to out of space
Your mail has been administratively rejected. Reciptent will not receive this mail due to quota limit . ___ 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: kern/140661: [zfs] /boot/loader fails to work on a GPT/ZFS-only system on both 8.0-RC2 and RC3
On Nov 18, 2009, at 21:57 , Scot Hetzel wrote: Make sure you have LOADER_ZFS_SUPPORT in your /etc/src.conf: dv8t01# cat /etc/src.conf LOADER_ZFS_SUPPORT=YES Ah! I also have LOADER_TFTP_SUPPORT=YES. Removing that, and everything works. I don't know why I didn't think of that in the first place, but maybe this is either a bug, or something that should be warned about when building loader(8)? /Kenneth I had the same problem which went away after removing TFTP support and reinstalling the bootcode. For now I suggest to add the following patch: --- sys/boot/i386/loader/conf.c.orig2010-02-13 14:08:31.154391969 + +++ sys/boot/i386/loader/conf.c 2010-02-13 14:11:11.119255786 + @@ -46,6 +46,10 @@ #error Cannot have both tftp and nfs support yet. #endif +#if defined(LOADER_ZFS_SUPPORT) defined(LOADER_TFTP_SUPPORT) +#error Cannot have both tftp and zfs support yet. +#endif + #if defined(LOADER_FIREWIRE_SUPPORT) extern struct devsw fwohci; #endif I think having both options corrupt each other's environment system: FreeBSD freebsd-master 8.0-STABLE FreeBSD 8.0-STABLE #2: Mon Jan 18 16:14:24 UTC 2010 r...@freebsd-master:/usr/obj/usr/cvsup/8-stable/src/sys/VMWARE amd64 Regards, Ruben ___ 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: panic - sleeping thread on FreeBSD 8.0-stable / amd64
On Sun, 07 Feb 2010 16:36:31 +0100 Torfinn Ingolfsen torfinn.ingolf...@broadpark.no wrote: Well, it was stable for many days, but today it rebooted on its ownb again. After the fact, I see this in /var/log/messages: Feb 7 11:50:16 kg-f2 ntpd[906]: time reset +2.376096 s Feb 7 12:02:21 kg-f2 kernel: ata6: port is not ready (timeout 1ms) tfd = 007f Feb 7 12:02:21 kg-f2 kernel: ata6: hardware reset timeout Feb 7 12:05:43 kg-f2 syslogd: kernel boot file is /boot/kernel/kernel So there is probably some problem with a cable or disk. Or just plain broken hardware. The machine rebooted last night. In /var/log/messages I see: Feb 13 03:50:20 kg-f2 kernel: ata5: port is not ready (timeout 1ms) tfd = 007f Feb 13 03:50:20 kg-f2 kernel: ata5: hardware reset timeout Last time it was ata6 and now it is ata5? Hmm... -- Torfinn ___ 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: ntpd struggling to keep up - how to fix?
On Fri, 12 Feb 2010 11:46:04 -0800 Jeremy Chadwick free...@jdc.parodius.com wrote: override this though! :-) ), which -- assuming it works -- should solve your problem. We'll see. The box rebooted again last night (see another thread on this mailing list), so now I have added kern.timecounter.hardware=ACPI-safe to /etc/sysctl.conf, just in case it reboots again. Technical footnote: I wish I understood 1) the difference between ACPI-safe and ACPI-fast, and 2) how the system or OS ranks the I'm still wondering why this machine doesn't have ACPI-fast: o...@kg-f2# sysctl kern.timecounter.choice kern.timecounter.choice: TSC(-100) HPET(900) ACPI-safe(850) i8254(0) dummy(-100) While my workstation do: ti...@kg-v2$ sysctl kern.timecounter.choice kern.timecounter.choice: TSC(-100) HPET(900) ACPI-fast(1000) i8254(0) dummy(-100) and anaother machine: r...@kg-quiet# sysctl kern.timecounter.choice kern.timecounter.choice: TSC(800) ACPI-fast(1000) i8254(0) dummy(-100) and another: r...@kg-vm# sysctl kern.timecounter.choice kern.timecounter.choice: TSC(-100) ACPI-fast(1000) i8254(0) dummy(-100) Probably a BIOS / acpi problem. -- Torfinn ___ 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 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.) * 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. (==) The core keyboard device wasn't specified explicitly in the layout. Using the default keyboard configuration. (II) Loader magic: 0x3f60 (II) Module ABI versions: X.Org ANSI C Emulation: 0.4 X.Org Video
Re: ZFS ARC being limited below what is defined in /boot/loader.conf
On Fri, Feb 12, 2010 at 01:10:51PM -0800, Artem Belevich wrote: vm.kmem_size_max/vm.kmem_size_min define the range vm.kmem_size can be set to. vm_kmem_size specifies the actual kmem size. ARC size in turn limited by vm.kmem_size. If you want to bump ARC size, you do need to bump vm.kmem_size. --Artem On Fri, Feb 12, 2010 at 11:36 AM, Steve Polyack kor...@comcast.net wrote: On 02/12/10 13:47, Artem Belevich wrote: On Fri, Feb 12, 2010 at 10:31 AM, Steve Polyackkor...@comcast.net wrote: Has anyone had an issue with the ZFS ARC max being limited below what has been defined in /boot/loader.conf? I just upgraded the RAM in a ZFS-equipped system and attempted to devote 4GB to the ARC cache by placing the following in loader.conf: vfs.zfs.arc_max=4096M However, after rebooting, querying the sysctl gives me this: $ sysctl vfs.zfs.arc_max vfs.zfs.arc_max: 1726489600 or about 1.7GB, an odd number that I can't find any references to. For reference, I'm running 8-STABLE (as of Jan 19th) on an amd64 system with 8GB of RAM. The system was previously very stable with 4GB of RAM and a 512MB arc_max. I have not modified vm.kmem_size_max (defaults to ~330GB on amd64) or any other ZFS tunables. I'd also like to avoid syncing up to the current 8-STABLE if at all possible. Thanks, Steve Polyack ___ 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 Check your vm.kmem_size. Default setting is way too low. Set it to at least double of desired arc size. --Artem I mentioned it briefly, but vm.kmem_size_max was left at the default for amd64. At 330GB it is way above and beyond what will ever be allocated to ARC: $ sysctl vm.kmem_size_max vm.kmem_size_max: 329853485875 I'm concerned about adjusting vm.kmem_size, since vm.kmem_size_max is supposed to be auto-adjusting as of this point in time. How does adjusting vm.kmem_size affect things like kern.maxdsiz, kern.dfldsiz, and kern.maxssiz? These tunings are required for things like userland apps which require a large amount of memory (read: mysqld). The amount of VM-related tunables requiring is getting out of hand. We need documentation of some sort, outlining how all these things fit together as to avoid potential kernel panics or memory exhaustion issues; for example, people with 8GB of RAM installed who utilise both ZFS on the server in addition to a memory-hungry mysqld. -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ 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
booting off a ZFS pool consisting of multiple striped mirror vdevs
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? - Sincerely, Dan Naumov ___ 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,
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. (==) The
Re: freebsd7 (and 8), radeon, xorg-server - deadlock or so
On February 13, 2010, Robert Noland 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... Thanks, the patch applies and builds cleanly. Unfortunately, it does not fix things for me. I am back to completely hanging the system. I getting the sense that there is some randomness or a timing issue. Changes that improved the behavior in one trial do not necessarily help in another trial. One thing I did is enable DRM_DEBUG. I wanted to get sense of how far we got before the hang. Unfortunately, there is no guarantee that log messages will be persisted before the system hangs. In a few attempts, the latest messages I observed were the following: Feb 13 13:37:58 proven kernel: [drm:pid41750:r600_do_init_cp] dev-agp_buffer_map-virtual 0xff807a51b000 Feb 13 13:37:58 proven kernel: info: [drm] Setting GART location based on new memory map Feb 13 13:37:58 proven kernel: [drm:pid41750:r600_do_init_cp] fb 0xd000 size 536870912 Feb 13 13:37:58 proven kernel: [drm:pid41750:r600_do_init_cp] dev_priv-gart_size 33554432 Feb 13 13:37:58 proven kernel: [drm:pid41750:r600_do_init_cp] dev_priv-gart_vm_start 0xf000 Feb 13 13:37:58 proven kernel: [drm:pid41750:r600_do_init_cp] dev_priv-gart_buffers_offset 0xf0102000 Feb 13 13:37:58 proven kernel: [drm:pid41750:r600_do_init_cp] Using gart offset 0x0fff Feb 13 13:37:58 proven kernel: [drm:pid41750:r600_do_init_cp] Setting phys_pci_gart to 0xff00dfff 0FFF Feb 13 13:37:58 proven kernel: [drm:pid41750:r600_page_table_init] page entry 0: 0xb956c063 Feb 13 13:37:58 proven kernel: [drm:pid41750:r600_page_table_init] page entry 128: 0x82128063 Feb 13 13:37:58 proven kernel: [drm:pid41750:r600_page_table_init] page entry 256: 0x98b8a063 [...] Feb 13 13:37:58 proven kernel: [drm:pid41750:r600_page_table_init] page entry 7936: 0x499df063 Feb 13 13:37:58 proven kernel: [drm:pid41750:r600_page_table_init] page entry 8064: 0x49a21063 Feb 13 13:37:58 proven kernel: info: [drm] Loading RV635 Microcode Feb 13 13:37:58 proven kernel: [drm:pid41750:r600_do_cp_stop] I will repeat the experiment a few more times. 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
Re: freebsd7 (and 8), radeon, xorg-server - deadlock or so
The interest thing is, with the previous version of xorg-server never locked the system up... On 2/13/10, Norbert Papke npa...@acm.org wrote: On February 13, 2010, Robert Noland 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... Thanks, the patch applies and builds cleanly. Unfortunately, it does not fix things for me. I am back to completely hanging the system. I getting the sense that there is some randomness or a timing issue. Changes that improved the behavior in one trial do not necessarily help in another trial. One thing I did is enable DRM_DEBUG. I wanted to get sense of how far we got before the hang. Unfortunately, there is no guarantee that log messages will be persisted before the system hangs. In a few attempts, the latest messages I observed were the following: Feb 13 13:37:58 proven kernel: [drm:pid41750:r600_do_init_cp] dev-agp_buffer_map-virtual 0xff807a51b000 Feb 13 13:37:58 proven kernel: info: [drm] Setting GART location based on new memory map Feb 13 13:37:58 proven kernel: [drm:pid41750:r600_do_init_cp] fb 0xd000 size 536870912 Feb 13 13:37:58 proven kernel: [drm:pid41750:r600_do_init_cp] dev_priv-gart_size 33554432 Feb 13 13:37:58 proven kernel: [drm:pid41750:r600_do_init_cp] dev_priv-gart_vm_start 0xf000 Feb 13 13:37:58 proven kernel: [drm:pid41750:r600_do_init_cp] dev_priv-gart_buffers_offset 0xf0102000 Feb 13 13:37:58 proven kernel: [drm:pid41750:r600_do_init_cp] Using gart offset 0x0fff Feb 13 13:37:58 proven kernel: [drm:pid41750:r600_do_init_cp] Setting phys_pci_gart to 0xff00dfff 0FFF Feb 13 13:37:58 proven kernel: [drm:pid41750:r600_page_table_init] page entry 0: 0xb956c063 Feb 13 13:37:58 proven kernel: [drm:pid41750:r600_page_table_init] page entry 128: 0x82128063 Feb 13 13:37:58 proven kernel: [drm:pid41750:r600_page_table_init] page entry 256: 0x98b8a063 [...] Feb 13 13:37:58 proven kernel: [drm:pid41750:r600_page_table_init] page entry 7936: 0x499df063 Feb 13 13:37:58 proven kernel: [drm:pid41750:r600_page_table_init] page entry 8064: 0x49a21063 Feb 13 13:37:58 proven kernel: info: [drm] Loading RV635 Microcode Feb 13 13:37:58 proven kernel: [drm:pid41750:r600_do_cp_stop] I will repeat the experiment a few more times. 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 ___ 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 February 13, 2010, Norbert Papke wrote: I will repeat the experiment a few more times. After quite a number of trials, I never managed to get any further with the radeon driver. I also tried the radeonhd driver. It seems to behave a little differently. I usually get to an X screen with some incompletely rendered windows before the system hangs. Feb 13 15:51:51 proven kernel: [drm:pid1833:drm_ioctl] pid=1833, cmd=0xc0106403, nr=0x03, dev 0xff00026fb400, auth=1 Feb 13 15:51:51 proven kernel: [drm:pid1833:drm_irq_by_busid] 1:0:0 = IRQ 260 Feb 13 15:51:51 proven kernel: [drm:pid1833:drm_ioctl] pid=1833, cmd=0x80086414, nr=0x14, dev 0xff00026fb400, auth=1 Feb 13 15:51:51 proven kernel: [drm:pid1833:drm_irq_install] irq=260 Feb 13 15:51:51 proven kernel: drm0: [ITHREAD] Feb 13 15:51:51 proven kernel: [drm:pid1833:drm_ioctl] pid=1833, cmd=0x800c6455, nr=0x55, dev 0xff00026fb400, auth=1 Feb 13 15:51:51 proven kernel: [drm:pid1833:drm_ioctl] pid=1833, cmd=0x80106459, nr=0x59, dev 0xff00026fb400, auth=1 Feb 13 15:51:51 proven kernel: [drm:pid1833:drm_ioctl] pid=1833, cmd=0xc0106451, nr=0x51, dev 0xff00026fb400, auth=1 Feb 13 15:51:51 proven kernel: [drm:pid1833:radeon_cp_getparam] pid=1833 Feb 13 15:51:51 proven kernel: [drm:pid1833:drm_ioctl] pid=1833, cmd=0x20006441, nr=0x41, dev 0xff00026fb400, auth=1 Feb 13 15:51:51 proven kernel: [drm:pid1833:radeon_cp_start] Feb 13 15:51:51 proven kernel: [drm:pid1833:r600_do_cp_start] Feb 13 15:51:51 proven kernel: [drm:pid1833:drm_ioctl] pid=1833, cmd=0xc0406429, nr=0x29, dev 0xff00026fb400, auth=1 Feb 13 15:51:51 proven kernel: [drm:pid1833:radeon_freelist_get] done_age = -559038737 Feb 13 15:51:52 proven kernel: [drm:pid1833:drm_ioctl] pid=1833, cmd=0xc0406429, nr=0x29, dev 0xff00026fb400, auth=1 Feb 13 15:51:52 proven kernel: [drm:pid1833:radeon_freelist_get] done_age = -559038737 Feb 13 15:51:52 proven kernel: [drm:pid1833:drm_mmap] called with offset 0602 Feb 13 15:51:52 proven kernel: [drm:pid1833:drm_mmap] called with offset 06021000 Feb 13 15:51:52 proven kernel: [drm:pid1833:drm_mmap] called with offset 06022000 Feb 13 15:51:52 proven kernel: [drm:pid1833:drm_mmap] called with offset 06023000 Feb 13 15:51:52 proven kernel: [drm:pid1833:drm_mmap] called with offset 06028000 Feb 13 15:51:52 proven kernel: [drm:pid1833:drm_ioctl] pid=1833, cmd=0xc010644d, nr=0x4d, dev 0xff00026fb400, auth=1 Feb 13 15:51:52 proven kernel: [drm:pid1833:radeon_cp_indirect] idx=2 s=0 e=14400 d=1 Feb 13 15:51:52 proven kernel: [drm:pid1833:r600_cp_dispatch_indirect] dwords:3600 Feb 13 15:51:52 proven kernel: [drm:pid1833:r600_cp_dispatch_indirect] offset 0xf0222000 I am not sure what to make of this. Cheers, -- Norbert. ___ 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
managing ZFS automatic mounts - FreeBSD deviates from Solaris?
Hello From the SUN ZFS Administration Guide: http://docs.sun.com/app/docs/doc/819-5461/gaztn?a=view If ZFS is currently managing the file system but it is currently unmounted, and the mountpoint property is changed, the file system remains unmounted. This does not seem to be the case in FreeBSD (8.0-RELEASE): = zfs get mounted tank/home NAMEPROPERTYVALUE SOURCE tank/home mounted no - zfs set mountpoint=/mnt/home tank/home zfs get mounted tank/home NAMEPROPERTYVALUE SOURCE tank/home mounted no - = This might not look like a serious issue at first, until you try doing an installation of FreeBSD from FIXIT, trying to setup multiple filesystems and their mountpoints at the very end of the installation process. For example if you set the mountpoint of your poolname/rootfs/usr to /usr as one of the finishing touches to the system installation, it will immideately mount the filesystem, instantly breaking your FIXIT environment and you cannot proceed any further. Is this a known issue and/or should I submit a PR? - Sincerely, Dan Naumov ___ 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: managing ZFS automatic mounts - FreeBSD deviates from Solaris?
On Sun, Feb 14, 2010 at 2:24 AM, Dan Naumov dan.nau...@gmail.com wrote: Hello From the SUN ZFS Administration Guide: http://docs.sun.com/app/docs/doc/819-5461/gaztn?a=view If ZFS is currently managing the file system but it is currently unmounted, and the mountpoint property is changed, the file system remains unmounted. This does not seem to be the case in FreeBSD (8.0-RELEASE): = zfs get mounted tank/home NAME PROPERTY VALUE SOURCE tank/home mounted no - zfs set mountpoint=/mnt/home tank/home zfs get mounted tank/home NAME PROPERTY VALUE SOURCE tank/home mounted no - = This might not look like a serious issue at first, until you try doing an installation of FreeBSD from FIXIT, trying to setup multiple filesystems and their mountpoints at the very end of the installation process. For example if you set the mountpoint of your poolname/rootfs/usr to /usr as one of the finishing touches to the system installation, it will immideately mount the filesystem, instantly breaking your FIXIT environment and you cannot proceed any further. Is this a known issue and/or should I submit a PR? Oops, I managed to screw up my previous email. My point was to show that mounted changes to YES after changing the mountpoint property :) - Dan ___ 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: hardware for home use large storage
Dan Langille wrote: Hi, I'm looking at creating a large home use storage machine. Budget is a concern, but size and reliability are also a priority. Noise is also a concern, since this will be at home, in the basement. That, and cost, pretty much rules out a commercial case, such as a 3U case. It would be nice, but it greatly inflates the budget. This pretty much restricts me to a tower case. The primary use of this machine will be a backup server[1]. It will do other secondary use will include minor tasks such as samba, CIFS, cvsup, etc. I'm thinking of 8x1TB (or larger) SATA drives. I've found a case[2] with hot-swap bays[3], that seems interesting. I haven't looked at power supplies, but given that number of drives, I expect something beefy with a decent reputation is called for. Whether I use hardware or software RAID is undecided. I I think I am leaning towards software RAID, probably ZFS under FreeBSD 8.x but I'm open to hardware RAID but I think the cost won't justify it given ZFS. Given that, what motherboard and RAM configuration would you recommend to work with FreeBSD [and probably ZFS]. The lists seems to indicate that more RAM is better with ZFS. Thanks. [1] - FYI running Bacula, but that's out of scope for this question [2] - http://www.newegg.com/Product/Product.aspx?Item=N82E16811192058 [3] - nice to have, especially for a failure. After creating three different system configurations (Athena, Supermicro, and HP), my configuration of choice is this Supermicro setup: 1. Samsung SATA CD/DVD Burner $20 (+ $8 shipping) 2. SuperMicro 5046A $750 (+$43 shipping) 3. LSI SAS 3081E-R $235 4. SATA cables $60 5. Crucial 3×2G ECC DDR3-1333 $191 (+ $6 shipping) 6. Xeon W3520 $310 Total price with shipping $1560 Details and links at http://dan.langille.org/2010/02/14/supermicro/ I'll probably start with 5 HDD in the ZFS array, 2x gmirror'd drives for the boot, and 1 optical drive (so 8 SATA ports). ___ 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: hardware for home use large storage
On Sun, 14 Feb 2010, Dan Langille wrote: After creating three different system configurations (Athena, Supermicro, and HP), my configuration of choice is this Supermicro setup: 1. Samsung SATA CD/DVD Burner $20 (+ $8 shipping) 2. SuperMicro 5046A $750 (+$43 shipping) 3. LSI SAS 3081E-R $235 4. SATA cables $60 5. Crucial 3×2G ECC DDR3-1333 $191 (+ $6 shipping) 6. Xeon W3520 $310 Total price with shipping $1560 Details and links at http://dan.langille.org/2010/02/14/supermicro/ I'll probably start with 5 HDD in the ZFS array, 2x gmirror'd drives for the boot, and 1 optical drive (so 8 SATA ports). That is f**king expensive for a home setup :) I priced a decent ZFS PC for a small business and it was AUD$2500 including the disks (5x750Gb), case, PSU etc.. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C signature.asc Description: This is a digitally signed message part.
Re: hardware for home use large storage
On Sun, 14 Feb 2010, Daniel O'Connor wrote: On Sun, 14 Feb 2010, Dan Langille wrote: After creating three different system configurations (Athena, Supermicro, and HP), my configuration of choice is this Supermicro setup: 1. Samsung SATA CD/DVD Burner $20 (+ $8 shipping) 2. SuperMicro 5046A $750 (+$43 shipping) 3. LSI SAS 3081E-R $235 4. SATA cables $60 5. Crucial 3×2G ECC DDR3-1333 $191 (+ $6 shipping) 6. Xeon W3520 $310 Total price with shipping $1560 Details and links at http://dan.langille.org/2010/02/14/supermicro/ I'll probably start with 5 HDD in the ZFS array, 2x gmirror'd drives for the boot, and 1 optical drive (so 8 SATA ports). That is f**king expensive for a home setup :) I priced a decent ZFS PC for a small business and it was AUD$2500 including the disks (5x750Gb), case, PSU etc.. Also, that one booted off a 4Gb CF card (non RAID/mirror though). -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C signature.asc Description: This is a digitally signed message part.
