Re: SMP users needed to test patch
2009/11/4 Saifi Khan : > On Wed, 4 Nov 2009, Stathis Kamperis wrote: > >> >> Did you by any chance try without my patch and SMP/APIC set in your >> kernel configuration file ? >> >> > > Commented out the following option and 'recompiled' the kernel. > > ### options APIC_IO > > Did not see any of the 'livelock' notifications. Alright, thanks. I suppose that those livelock events are irrelevant to my work then. > > So, i ventured out and cloned in the 'pcca-test'. > > On running 'make' in the mqueue.h/ > >> make > gcc -Wall -W -Wformat-nonliteral -Wcast-align -Wpointer-arith > -Wbad-function-cast -Wmissing-prototypes -Wstrict-prototypes > -Wmissing-declarations -Winline -Wundef -Wnested-externs -Wcast-qual > -Wshadow -Wwrite-strings -Wno-unused-parameter -Wfloat-equal -Wswitch > -Wbad-function-cast -g -lrt t_mq_ambig.c -o t_mq_ambig > /usr/libexec/binutils217/elf/ld: cannot find -lrt > *** Error code 1 > > Stop in /home/saifi/dragonflybsd/pcca-tests/mqueue.h. >> Oh, you must be running 2.4.x, right? The librt has been born in 2.5.x :) So there isn't much you can do. > thanks > Saifi. No, I thank you. Best regards, Stathis Kamperis
Re: SMP users needed to test patch
On Wed, 4 Nov 2009, Stathis Kamperis wrote: > > Did you by any chance try without my patch and SMP/APIC set in your > kernel configuration file ? > > Commented out the following option and 'recompiled' the kernel. ### options APIC_IO Did not see any of the 'livelock' notifications. So, i ventured out and cloned in the 'pcca-test'. On running 'make' in the mqueue.h/ > make gcc -Wall -W -Wformat-nonliteral -Wcast-align -Wpointer-arith -Wbad-function-cast -Wmissing-prototypes -Wstrict-prototypes -Wmissing-declarations -Winline -Wundef -Wnested-externs -Wcast-qual -Wshadow -Wwrite-strings -Wno-unused-parameter -Wfloat-equal -Wswitch -Wbad-function-cast -g -lrt t_mq_ambig.c -o t_mq_ambig /usr/libexec/binutils217/elf/ld: cannot find -lrt *** Error code 1 Stop in /home/saifi/dragonflybsd/pcca-tests/mqueue.h. > Does this imply that i need to buildworld as well ? i suppose 'librt' is POSIX real time extensions. Here is the 'dmesg', (it it helps). ... Copyright (c) 2003-2009 The DragonFly Project. Copyright (c) 1992-2003 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. DragonFly d15a49f-DEVELOPMENT #1: Thu Nov 5 13:21:29 IST 2009 r...@amd64x2.datasynergy.org:/usr/obj/usr/src/sys/AMD64-P-MQ Calibrating clock(s) ... TSC clock: 2310389259 Hz, i8254 clock: 1193136 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency CLK_USE_TSC_CALIBRATION not specified - using old calibration method CPU: AMD Athlon(tm) 64 X2 Dual Core Processor 4400+ (2310.50-MHz K8-class CPU) Origin = "AuthenticAMD" Id = 0x60fb1 Stepping = 1 Features=0x178bfbff Features2=0x2001 AMD Features=0xea500800 AMD Features2=0x11f Cores per package: 2 L1 2MB data TLB: 8 entries, fully associative L1 2MB instruction TLB: 8 entries, fully associative L1 4KB data TLB: 32 entries, fully associative L1 4KB instruction TLB: 32 entries, fully associative L1 data cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way associative L1 instruction cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way associative L2 2MB unified TLB: 0 entries, disabled/not present L2 4KB data TLB: 512 entries, 4-way associative L2 4KB instruction TLB: 512 entries, 4-way associative L2 unified cache: 512 kbytes, 64 bytes/line, 1 lines/tag, 16-way associative real memory = 2013003776 (1965824K bytes) Physical memory chunk(s): 0x1000 - 0x0009bfff, 634880 bytes (155 pages) 0x01007000 - 0x77fa, 1996132352 bytes (487337 pages) avail memory = 1879461888 (1835412K bytes) lapic: divisor index 0, frequency 100455852 Hz SMP: CPU0 apic_initialize(): lint0: 0x0700 lint1: 0x00010400 TPR: 0x008f SVR: 0x01ff DragonFly/MP: Multiprocessor motherboard cpu0 (BSP): apic id: 0, version: 0x80050010, at 0xfee0 cpu1 (AP): apic id: 1, version: 0x80050010, at 0xfee0 Warning: APIC I/O disabled<<32 Preloaded elf kernel "/kernel" at 0x80fde000. Preloaded elf obj module "/modules/acpi.ko" at 0x80fde290. start scheduler helpers on cpus: 0 1 start dummy scheduler helpers on cpus: 0 1 wlan: <802.11 Link Layer> kbd: new array size 4 kbd1 at kbdmux0 crypto: sched_ithd: stray interrupt 7 on cpu 1 md0: Malloc disk ACPI: RSDP 0xfb840 00014 (v0 ACPIAM) ACPI: RSDT 0x77fc 00040 (v1 _ASUS_ Notebook 04000730 MSFT 0097) ACPI: FACP 0x77fc0200 00084 (v2 A_M_I_ OEMFACP 04000730 MSFT 0097) ACPI: DSDT 0x77fc05c0 04D44 (v1 A0557 A0557000 INTL 20051117) ACPI: FACS 0x77fce000 00040 ACPI: APIC 0x77fc0390 00070 (v1 A_M_I_ OEMAPIC 04000730 MSFT 0097) ACPI: MCFG 0x77fc0400 0003C (v1 A_M_I_ OEMMCFG 04000730 MSFT 0097) ACPI: SLIC 0x77fc0440 00176 (v1 _ASUS_ Notebook 04000730 MSFT 0097) ACPI: OEMB 0x77fce040 00060 (v1 A_M_I_ AMI_OEM 04000730 MSFT 0097) ACPI: HPET 0x77fc5310 00038 (v1 A_M_I_ OEMHPET0 04000730 MSFT 0097) ACPI: SSDT 0x77fc5350 00248 (v1 A_M_I_ POWERNOW 0001 AMD 0001) acpi0.nexus0.root0 acpi0: <_ASUS_ Notebook> [tentative] on motherboard acpi0: Power Button (fixed) Warning: ACPI is disabling APM's device. You can't run both pci_open(1):mode 1 addr port (0x0cf8) is 0x8000c060 pci_open(1a): mode1res=0x8000 (0x8000) pci_cfgcheck: device 0 [class=05] [hdr=00] is there (id=03ea10de) AcpiOsDerivePciId: bus 0 dev 1 func 0 ACPI timer looks BAD min = 5, max = 12, width = 7 ACPI timer looks BAD min = 5, max = 793, width = 788 ACPI timer looks GOOD min = 5, max = 6, width = 1 ACPI timer looks BAD min = 5, max = 12, width = 7 ACPI timer looks GOOD min = 5, max = 6, width = 1 ACPI timer looks BAD min = 5, max = 12, width = 7 ACPI timer looks BAD min = 5, max = 12, w
Re: SMP users needed to test patch
On Wed, 4 Nov 2009, Stathis Kamperis wrote: > 2009/11/4 Saifi Khan : > > On Wed, 4 Nov 2009, Stathis Kamperis wrote: > > > >> Hello everyone! > >> > >> I'd like to mark mq*() syscall as MPSAFE, but before that I need > >> someone to test them in an SMP capable machine running SMP kernel. I > >> only have UP machines around. > >> > >> So, if anyone is able and kind enough, here are some directions on how > >> to do it. I assume s\he is running HEAD. > >> > >> cd /usr/src > >> fetch http://leaf.dragonflybsd.org/~beket/mq-mpsafe.diff > >> git apply mq-mpsafe.diff > >> make buildkernel > >> make installkernel > >> reboot > > > > Reached this far and currently face the issue which has > > effectively disabled networking. > > > > intr 2 at 40001/4 hz, livelock limit engaged > > > > Details posted in a separate thread. > > > > > > thanks > > Saifi. > > > > > > Thank you Saifi! I very much appreciate the time you've put into this. > > Did you by any chance try without my patch and SMP/APIC set in your > kernel configuration file ? > Unfortunately no ! Let me try and revert the patch i applied and rebuild the kernel. Will post an update on this. thanks Saifi.
Re: SMP users needed to test patch
2009/11/4 Saifi Khan : > On Wed, 4 Nov 2009, Stathis Kamperis wrote: > >> Hello everyone! >> >> I'd like to mark mq*() syscall as MPSAFE, but before that I need >> someone to test them in an SMP capable machine running SMP kernel. I >> only have UP machines around. >> >> So, if anyone is able and kind enough, here are some directions on how >> to do it. I assume s\he is running HEAD. >> >> cd /usr/src >> fetch http://leaf.dragonflybsd.org/~beket/mq-mpsafe.diff >> git apply mq-mpsafe.diff >> make buildkernel >> make installkernel >> reboot > > Reached this far and currently face the issue which has > effectively disabled networking. > > intr 2 at 40001/4 hz, livelock limit engaged > > Details posted in a separate thread. > > > thanks > Saifi. > > Thank you Saifi! I very much appreciate the time you've put into this. Did you by any chance try without my patch and SMP/APIC set in your kernel configuration file ? Best regards, Stathis Kamperis
Re: SMP users needed to test patch
On Wed, 4 Nov 2009, Stathis Kamperis wrote: > Hello everyone! > > I'd like to mark mq*() syscall as MPSAFE, but before that I need > someone to test them in an SMP capable machine running SMP kernel. I > only have UP machines around. > > So, if anyone is able and kind enough, here are some directions on how > to do it. I assume s\he is running HEAD. > > cd /usr/src > fetch http://leaf.dragonflybsd.org/~beket/mq-mpsafe.diff > git apply mq-mpsafe.diff > make buildkernel > make installkernel > reboot Reached this far and currently face the issue which has effectively disabled networking. intr 2 at 40001/4 hz, livelock limit engaged Details posted in a separate thread. thanks Saifi.
intr 2 at 40001/40000 hz, livelock limit engaged
Hi: Compiled a custom kernel on AMD64 X2 with the following modifications to the AMD64_GENERIC config. options SMP options APIC and application of the patch http://leaf.dragonflybsd.org/~beket/mq-mpsafe.diff The following lines are seen, with network traffic degraded to 95% packet loss. In short, i can't ssh to the box. ... intr 2 at 40001/4 hz, livelock limit engaged ! nfe0: watchdog timeout - lost interrupt recovered nfe0: watchdog timeout - lost interrupt recovered intr 2 at 14288/2 hz, livelock removed intr 2 at 40001/4 hz, livelock limit engaged ! intr 2 at 14616/2 hz, livelock removed intr 2 at 40001/4 hz, livelock limit engaged ! intr 2 at 13510/2 hz, livelock removed intr 2 at 40001/4 hz, livelock limit engaged ! ... Is there a work around/fix to this issue ? thanks Saifi.
Re: remote branches
Saifi Khan wrote: Subsequent to a fresh DragonFly BSD 2.4.1 installation on AMD64 X2 box, i did the following steps to pull in the source code as i did not want to use the Makefile. # cd /usr # mkdir src # cd src # git init # git remote add origin git://git.dragonflybsd.org/dragonfly.git # git pull origin HEAD Is this the recommended approach ? No. Just use git clone git://... src Additionally, when i try to view the 'remote' branches # git branch -r there are none seen. Yes, because you only pulled master. Is this something to be worried about ? run a "git remote update" to get all. On another laptop, i pulled in the code (couple of months ago) using # git clone -o chlamydia git://chlamydia.fs.ei.tum.de/dragonfly.git followed by periodic # git pull When, i try to view the remote branches, Git shows it as, # git branch -r origin/DragonFly_RELEASE_1_10 [..] What could i be missing here ? where? -- <3 the future +++ RENT this banner advert +++ ASCII Ribbon /"\ rock the past +++ space for low CHF NOW!1 +++ Campaign \ / Party Enjoy Relax | http://dragonflybsd.org Against HTML \ Dude 2c 2 the max ! http://golden-apple.biz Mail + News / \
remote branches
Hi: Subsequent to a fresh DragonFly BSD 2.4.1 installation on AMD64 X2 box, i did the following steps to pull in the source code as i did not want to use the Makefile. # cd /usr # mkdir src # cd src # git init # git remote add origin git://git.dragonflybsd.org/dragonfly.git # git pull origin HEAD Is this the recommended approach ? Additionally, when i try to view the 'remote' branches # git branch -r there are none seen. Is this something to be worried about ? On another laptop, i pulled in the code (couple of months ago) using # git clone -o chlamydia git://chlamydia.fs.ei.tum.de/dragonfly.git followed by periodic # git pull When, i try to view the remote branches, Git shows it as, # git branch -r origin/DragonFly_RELEASE_1_10 origin/DragonFly_RELEASE_1_12 origin/DragonFly_RELEASE_1_2 origin/DragonFly_RELEASE_1_4 origin/DragonFly_RELEASE_1_6 origin/DragonFly_RELEASE_1_8 origin/DragonFly_RELEASE_2_0 origin/DragonFly_RELEASE_2_2 origin/DragonFly_RELEASE_2_4 origin/HEAD -> origin/master origin/doc origin/master origin/netmp origin/repo/hooks origin/site origin/vendor/ACPICA-UNIX origin/vendor/ATHEROS origin/vendor/AWK origin/vendor/BIND origin/vendor/BINUTILS origin/vendor/BINUTILS220 origin/vendor/BSDINSTALLER origin/vendor/BSDTAR origin/vendor/BZIP origin/vendor/CVS origin/vendor/DHCP origin/vendor/DIFFUTILS origin/vendor/FILE origin/vendor/GCC origin/vendor/GCC44 origin/vendor/GDB origin/vendor/GDTOA origin/vendor/GMP origin/vendor/GPERF origin/vendor/GROFF origin/vendor/HEIMDAL origin/vendor/HOSTAPD origin/vendor/INTEL_ACPICA origin/vendor/LESS origin/vendor/LIBARCHIVE origin/vendor/LIBEVENT origin/vendor/LIBPCAP origin/vendor/LIBSTDC++ origin/vendor/LUKEMFTP origin/vendor/MPFR origin/vendor/NCURSES origin/vendor/NETGRAPH origin/vendor/NTPD origin/vendor/OPENPAM origin/vendor/OPENSSH origin/vendor/OPENSSL origin/vendor/PAM_PASSWDQC origin/vendor/READLINE origin/vendor/SENDMAIL origin/vendor/TCPDUMP origin/vendor/TCSH origin/vendor/TEXINFO origin/vendor/TNFTP origin/vendor/WPA_SUPPLICANT origin/vendor/ZLIB What could i be missing here ? thanks Saifi.
Re: Xorg configuration
On Wed, 4 Nov 2009, Pierre Abbat wrote: > I used "Xorg -configure". I've seen another way of configuring X, which > starts > the server, displays a dialog box asking if it's visible, and then exits the > server if I don't push a button. Is that program available? > Perhaps you are referring to SAX2 utility in openSUSE. You can use 'xvinfo' to print out X-Video adapter information and then tailor the xorg.conf file. thanks Saifi.
Re: Xorg configuration
> I used "Xorg -configure". I've seen another way of configuring X, which > starts > the server, displays a dialog box asking if it's visible, and then exits > the > server if I don't push a button. Is that program available? There's the old XF86Config and xf86cfg programs, though neither of those are much better. I'm not sure what xorg may include by default these days.
Re: GHC on DragonFly?
I'm going to have a go at this when GHC 6.12.1 is released (32-bit DragonFly). It looks very intimidating, as I don't know x86 assembler, nor DragonFly internals, but I dare say I can shrug off 15 years of not doing anything so low-level, and get to grips with it. 2009/5/23 G.Isenmann : > On Sat, 16 May 2009 19:09:06 +0100 > Colin Adams wrote: > >> I think someone was making an attempt to port ghc (Glasgow Haskell >> Compiler) to DragonFly. Has this been succesfull? > > Neither lang/ghc (6.8.3) nor wip/ghc (6.10.1) build without changes. > > I started with wip/ghc and made the build process believe that the > build was on and for freebsd4. That gave me something good enought as a > bootstrap compiler. Wasn't able to build a ghc package, and while > building some packages with cabal I got error messages like "not > possible with a stage 1 compiler". > > Next I used this compiler (without pkgsrc and netbsd bootstrap > compiler) to build the next version. This time I checked the sources > for anything freebsd specific and modified those places to do the > same for dragonfly. > > There is at least one open problem with rts/Linker.c > http://leaf.dragonflybsd.org/mailarchive/users/2009-04/msg00030.html > This prevents the use of ghci and the build of e.g. yi. > > Not much done since. At the moment I am happy with a working darcs and > xmonad. I have looked a few times into the binutils and ghc sources, > but still do not understand much about this (tls) stuff. > -- > Goetz > -- Colin Adams Preston, Lancashire, ENGLAND
Re: Xorg configuration
I used "Xorg -configure". I've seen another way of configuring X, which starts the server, displays a dialog box asking if it's visible, and then exits the server if I don't push a button. Is that program available? Pierre -- li ze te'a ci vu'u ci bi'e te'a mu du li ci su'i ze te'a mu bi'e vu'u ci
SMP users needed to test patch
Hello everyone! I'd like to mark mq*() syscall as MPSAFE, but before that I need someone to test them in an SMP capable machine running SMP kernel. I only have UP machines around. So, if anyone is able and kind enough, here are some directions on how to do it. I assume s\he is running HEAD. cd /usr/src fetch http://leaf.dragonflybsd.org/~beket/mq-mpsafe.diff git apply mq-mpsafe.diff make buildkernel make installkernel reboot git clone git://gitweb.dragonflybsd.org/~beket/pcca-tests.git cd pcca-tests/mqueue.h make && make -k run cd etc make sysctl -w kern.mqueue.mq_prio_max=200 ./t_mq_parallel_threads ./t_mq_parallel_fork If you encounter problems you can mail me off-list to sort them out. I know that it's messy, so no hard feelings if no one volunteers :) Thank you for considering. Best regards, Stathis Kamperis
Re: DragonFlyBSD make
[repost; reformat, fixing line breaks] >>The tutorial isn't installed anymore, so link should go; but it is still in >>our repo: >>http://gitweb.dragonflybsd.org/dragonfly.git/blob/HEAD:/usr.bin/make/PSD.doc/tutorial.ms >>(online documented versoin can be found at e.g. >>http://www.freebsd.org/doc/en/books/pmake/) s/documented versoin/formatted version/ (my typo) >Thomas, maybe the link in make(1) should only be commented out for now. OK; I just think we shouldn't refer to a file path which isn't used anymore; a full reference should be fine. >Installation of these documents was disabled a long time ago by Hiten or Joerg >(IIRC) when groff was removed from the build-tools. Although you can still go >to the directory in src/ and format oneself. Joerg did it; a little fast IMO. >The situation might improve, however, now that we have mandoc(1), but I >haven't tested it on these documents. These documents are using ME or MS roff macro packages, mandoc(1) only support man & mdoc. >It's true that much of the stuff in src/share/doc is outdated, misleading >etc., but there are several documents which actually contain useful >information (such as the PMake one). Well, I don't see much outdated material, most is documenting 4.4 BSD, which is either still useful, or has historical interest (for some of us at least). >We have several options I think: > >* Leave things lying around until we utilize mandoc(1) better in favor of >groff and then think about whether installation of the still useful documents >should be done again (with mandoc(1) as a build-tool). mandoc(1) won't be of much use, see above. If plan is to drop groff from our base, people can still install it (or some other troff(1)) and format documents themselves. We might commit formatted versions, maybe latin1 text & PDF (or PS, and html and ..) versions. >* Remove src/share/doc completely (user can dig this information himself on >the web). > >* Commit formatted versions of the still useful documents and remove the rest. > >* ... > >I'm favoring the first option but I could live with any of the other ones. Me too. -thomas