Re: 2.7 amd64 Desktop issues ( mouse, RAM, perfomance etc. )
On Fri, May 14, 2010 at 3:25 PM, Steve O'Hara-Smith st...@sohara.org wrote: The generic kernel does not support SMP - copy the config, uncomment the SMP and APIC_IO options and build a new kernel. Thanks Steve :-) I don't know about the rest, except to wonder if the CD problem is causing an interrupt storm slowing everything else down. Removed the CD still the same problem with mouse and windows switching :-( I edited the xorg config to put the right chipset for the VGA card still the same problem :-( Thanks :-) --Siju
Re: 2.7 amd64 Desktop issues ( mouse, RAM, perfomance etc. )
On Fri, May 14, 2010 at 4:07 PM, YONETANI Tomokazu qhwt+d...@les.ath.cx wrote: On Fri, May 14, 2010 at 03:13:17PM +0530, Siju George wrote: 2) Only 3GB of 4GB RAM is detected. Is there a limit? You may have to change the BIOS setting. BIOS Setting s show Total Memory : 4096 MB with 8 MB Shared Memory : Dual - Channel Memory Mode DDRII1 : 2048 MB/266 MHz (DDRII533) DDRII2 : 2048 MB/266 MHz (DDRII533) There are no setting to limit RAM in BIOS :-( Try booting other 64bit-OSes ArchLinux 64 bit shows only 3 GB :-( to see if they do it better. At least 4G is recognized on my D510MO box $ sysctl hw.physmem hw.usermem hw.physmem: 4262477824 hw.usermem: 3002294272 $ sysctl hw.physmem hw.usermem hw.physmem: 3061977088 hw.usermem: 2638372864 Try capturing dmesg message with boot -v; choose 4-th or so item which reads Boot DragonFly with verbose logging real memory = 3078291456 (2935 MB) Physical memory chunk(s): 0x1000 - 0x0009efff, 647168 bytes (158 pages) 0x0102d000 - 0xb779, 3061264384 bytes (747379 pages) avail memory = 2884808704 (2751 MB) any idea what could be the trouble? I was testing the amd64 port for a new backup server. I guess i will go back to the x86 port since more than 3 GB RAm is not recognized any how :-( thanks --Siju
Re: 2.7 amd64 Desktop issues ( mouse, RAM, perfomance etc. )
Other things I'd do before throwing away the mainboard include: - Read THROUGH the mainboard's manual and make sure if it really supports 4Gbytes of main memory - Also check to see if you need to change the BIOS configuration, such as `Memory Remap feature.' also cf. http://forum.novatech.co.uk/showthread.php?t=15073 - Make sure that the BIOS is up-to-date Cheers.
Re: starting Apache
On Sun, 16 May 2010, Pierre Abbat wrote: PKG_RCD_SCRIPTS=yes But the next line is RCD_SCRIPTS_DIR=/usr/pkg/share/examples/rc.d (That value is for RCD_SCRIPTS_EXAMPLEDIR.) That is broken. The default already is RCD_SCRIPTS_DIR?= /etc/rc.d So if I set that to /etc/rc.d, then they'll go to /etc/rc.d when I install the packages?
which pkgsrc version do I get via git?
Hi! What flavor of pkgsrc do I get, when I use cd /usr make pkgsrc-create/update? There are regular updates, but there seem to be a lot of differences compared to 2010Q1 and cvs/pkgsrc-changes. -- Goetz
Re: starting Apache
But I think I'd prefer /usr/pkg/etc/rc.d, to have a clean separation between base and pkgsrc rc scripts (which might have the same names). I can second this; please make /usr/pkg/etc/rc.d default for pkgsrc; it is just too messy to use /etc/rc.d for non base scripts IMHO. (BIND removal instructions for next release should be updated to reflect this) (also in an ideal world everyone will agree on this and we can GC rc scripts; vs now: http://gitweb.dragonflybsd.org/dragonfly.git/commitdiff/63a7853169a0e37ad03fd8e3e042194273885b34) rc variable namespace still isn't separated, e.g. no reserved name space for base rc scripts, any ideas for this? It might be for this reason that pkgsrc doesn't install rc scripts by default in rc.d; they can break existing setup, if we use variable name for base rc script which some package also uses. -thomas
Re: DragonFly 2.6.2, 2.7.2 tags pushed - fixes for serious HAMMER issue
The corruption can only occur if your HAMMER filesystem became full or nearly full sometime in the last 45 days or so with a kernel built sometime in the last 45 days. To check for the corruption you need an unmounted or completely idle filesystem and then run (using the latest hammer utility): .. hammer -f device show | egrep '^B' | egrep -v '^BM' I was hit, but think my FS has been under 90% full at all times. (checked in single user, w/ r/o mount) Any way to find out which files (history) are affected? If using mirror-read to copyoff remember it must be run on every PFS individually, and bulk mode (-B) is recommended, and make sure any backups are viable before smashing the original filesystem. Why is -B recommended? In hammer.8 -B is 'not recommended'; should this just be removed? Any way to restore root PFS (#0) fully? Root PFS can not be downgraded to slave, for mirror-write, so I see no way to get history restored. Beware of cpdup'ing root PFS; symlinks for already restored PFSs will be overwritten. Also remember to copy PFS config (if you use non default). (I had to restore PFSs twice, as I did 'hammer cleanup' too early) -thomas
Re: DragonFly 2.6.2, 2.7.2 tags pushed - fixes for serious HAMMER issue
: :The corruption can only occur if your HAMMER filesystem became full :or nearly full sometime in the last 45 days or so with a kernel built :sometime in the last 45 days. To check for the corruption you need :an unmounted or completely idle filesystem and then run (using the :latest hammer utility): :.. :hammer -f device show | egrep '^B' | egrep -v '^BM' :I was hit, but think my FS has been under 90% full at all times. :(checked in single user, w/ r/o mount) : :Any way to find out which files (history) are affected? If the filesystem is not idle you can try sync'ing a few times and running the hammer -f device show | egrep... stuff several times to see if the output changes. Only manually by locating the errors in the show output and backtracking the object id (inode number) to the directory entry. In that case you would have to dump the entire show output to a file, which could end up being gigabytes depending on the size of the filesystem. hammer -f device show somefile less somefile /^B (but ^BM has to be ignored since those represent mirror_tid errors which are probably all over the place prior to the fix which went into 2.6). :If using mirror-read to copyoff remember it must be run on every PFS :individually, and bulk mode (-B) is recommended, and make sure any :backups are viable before smashing the original filesystem. : :Why is -B recommended? :In hammer.8 -B is 'not recommended'; should this just be removed? -B works around a bug in the incremental mirroring transaction ids stored in the B-Tree which was fixed for the 2.6 release but existed prior to that. The bug is self-correcting in that modifications made after the bug was fixed will properly deal with the mirror_tid in the B-Tree. :Any way to restore root PFS (#0) fully? :Root PFS can not be downgraded to slave, for mirror-write, :so I see no way to get history restored. No. What we really need to do here is get rid of the notion of a root PFS entirely and just make all the PFSs operate the same way. Someone was talking about making it possible to mount the root HAMMER filesystem with a PFS # other than 0, as well. Also very easy to do I think, it could be a small mini-project for someone. In anycase, ultimately for people who hit this corruption problem the best solution, unfortunately, may be to copy off the data and newfs the thing from scratch. :Beware of cpdup'ing root PFS; symlinks for already restored PFSs :will be overwritten. : :Also remember to copy PFS config (if you use non default). :(I had to restore PFSs twice, as I did 'hammer cleanup' too early) : : -thomas -Matt Matthew Dillon dil...@backplane.com
[HEADS UP] pkg_radd on 2.3 and older systems
If you have a system older than 2.4, pkg_radd uses an old path to find files. Applying the changes here: http://gitweb.dragonflybsd.org/dragonfly.git/commitdiff/3d62c9e33361b5901e858332066162cc93afc27b will make it work with the current layout, and it means I can get rid of the old top level links, which I'll do momentarily. (I figure this only affects a few people running older systems, who may have changed the path already anyway...)
Re: 2.7 amd64 Desktop issues ( mouse, RAM, perfomance etc. )
On Mon, May 17, 2010 at 9:35 PM, YONETANI Tomokazu qhwt+d...@les.ath.cx wrote: On Mon, May 17, 2010 at 07:48:04AM -0700, Siju George wrote: I got this thread about the chip set which says it is the lack of drivers for 64 - bit OS is what makes the RAM unavailable to the OS even though the mother board supports 4GB http://www.tech-forums.net/pc/f9/enable-4gb-ram-windows-7-32-bit-226914/ No, it doesn't say so, but the whole discussion is for Windows 7, why do you care at all? Ya right, I got confused with hte wordings in one post :-( --Siju
