Newly developed mailling list search engine needs testing
Hi, everybody. Firstly, let me introduce myself. I am Choy Kho Yee, an comp. sci. undergraduate student in Osaka University. For my final year thesis, I have developed a mailing list archive management system called "MLwiki". The name MLwiki is made up from the words "Mailing List" and "Wiki". It was developed to overcome some weaknesses of the existing mailing list archiving and searching system and to combine the power of wiki and the huge amount of information in the mailing list archive. With MLwiki, it is hoped that users can get the information they want faster and easier. More information about MLwiki is available on the main page of this system, which is located at MLwiki http://noanoa.ics.es.osaka-u.ac.jp/~k-choy/mlwiki-test/mlwiki.php The questionnaire http://noanoa.ics.es.osaka-u.ac.jp/~k-choy/mlwiki-test/mlwiki_questionaire.html Please read the introduction on the main page before testing the system as it provides some vital information to fully utilize MLwiki. After testing out the system, I would be glad if you can help me out by filling in the questionnaire about this system, which can be accessed through the above address or from MLwiki's main page. Please understand that MLwiki is in its early stage of development and therefore there might be many bugs hidden in it. Bugs reports are welcome. And please remember that this system is still in an experimental stage, all changes you submit might be lost in the future release. But do feel free to test around. This website will be available until 10 February 2006. Accessibility after that will be re-considered depends on the response and the condition of the system. Thanks a lot. --- Choy Kho Yee E-mail: k-choy at ics dot es dot osaka-u dot ac dot jp ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Weird PCI interrupt delivery problem (resolution, sort of)
Craig Boston wrote:
After trying everything I could think of to do to the I/O APIC code and
coming up empty, tonight I went back to the local APIC. I had
previously ruled it out since the lapic timer interrupt continued to
work fine even when the others stopped. However, adding some DELAY(1)
calls at key points caused it to work, much like adding WITNESS does.
I managed to get it down to a single change that makes APIC mode work on
this laptop:
--- local_apic.c.orig Thu Jan 19 18:32:37 2006
+++ local_apic.cThu Jan 19 18:32:28 2006
@@ -599,4 +599,5 @@
lapic_eoi(void)
{
lapic->eoi = 0;
+ lapic->eoi = 0;
}
...and welcome to bizarro world. There's absolutely no reason I can
think of why that would change anything, other than buggy hardware.
I looked at what Linux was doing, and they're also using a single write
to EOI interrupts, so long as the X86_GOOD_APIC config option is enabled
(and it is for P5/MMX or newer). Otherwise it does an extra read before
writing to any APIC register. I don't know if linux works on this
hardware or not -- the live CD I tried wasn't compiled for APIC support.
At this point, since AFAIK nobody else has reported the same problem,
I'm content with a local workaround. It's just... wierd.
Craig
This points to a bus coherency problem. I wonder if your BIOS is
incorrectly setting the memory region of the apics as cachable. You'll
want to bug Baldwin about this.
Scott
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Ricoh PCI to SD device?
In message: <[EMAIL PROTECTED]> Peter Jeremy <[EMAIL PROTECTED]> writes: : http://focus.ti.com/docs/apps/catalog/resources/appnoteabstract.jhtml?abstractName=scpu022 : contains some information as does the data manual for the PCI17x21. : : I'm not sure if there is sufficient information to write a driver. No. There isn't. Warner ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Weird PCI interrupt delivery problem (resolution, sort of)
After trying everything I could think of to do to the I/O APIC code and
coming up empty, tonight I went back to the local APIC. I had
previously ruled it out since the lapic timer interrupt continued to
work fine even when the others stopped. However, adding some DELAY(1)
calls at key points caused it to work, much like adding WITNESS does.
I managed to get it down to a single change that makes APIC mode work on
this laptop:
--- local_apic.c.orig Thu Jan 19 18:32:37 2006
+++ local_apic.cThu Jan 19 18:32:28 2006
@@ -599,4 +599,5 @@
lapic_eoi(void)
{
lapic->eoi = 0;
+ lapic->eoi = 0;
}
...and welcome to bizarro world. There's absolutely no reason I can
think of why that would change anything, other than buggy hardware.
I looked at what Linux was doing, and they're also using a single write
to EOI interrupts, so long as the X86_GOOD_APIC config option is enabled
(and it is for P5/MMX or newer). Otherwise it does an extra read before
writing to any APIC register. I don't know if linux works on this
hardware or not -- the live CD I tried wasn't compiled for APIC support.
At this point, since AFAIK nobody else has reported the same problem,
I'm content with a local workaround. It's just... wierd.
Craig
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Ricoh PCI to SD device?
On Wed, 2006-Jan-11 10:40:11 +, Andrew Gordon wrote: >Have you seen this datasheet from TI? > >http://focus.ti.com/docs/apps/catalog/resources/appnoteabstract.jhtml?abstractName=sprue30 I get "The information that you have requested is not available" but http://focus.ti.com/docs/apps/catalog/resources/appnoteabstract.jhtml?abstractName=scpu022 contains some information as does the data manual for the PCI17x21. I'm not sure if there is sufficient information to write a driver. -- Peter Jeremy ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: speed up port compiling using RAM (tmpfs) ???
On Thu, Jan 19, 2006 at 05:32:58PM -0500, Gary Thorpe wrote: > Ashok Shrestha wrote: > >I mounted part of RAM as such: > > > >mdmfs -s 500m md /mnt > > > >Then put WRKDIRPREFIX=/path/to/md in /etc/make.conf. > > > >It substantially reduces compile time by about 5-10 times. > > > > > >Thanx to all ur replies. > > > >-Ashok Shrestha > > An alternative is to try using the "-pipe" flag with GCC: this > eliminates the need to use some temporary files by using a unix pipe for > IPC. Setting another flag "-j 2" will allow 2 jobs to be done at the > same time and should eliminate (by hiding) the I/O delays (this slows > down the CPU slightly because of more task switches, but even with one > job there are still lots of generated tasks). -j is not safe to use with port builds since many ported software contain race conditions in the build. Kris pgpviV0QJrOwr.pgp Description: PGP signature
Re: speed up port compiling using RAM (tmpfs) ???
Ashok Shrestha wrote: I mounted part of RAM as such: mdmfs -s 500m md /mnt Then put WRKDIRPREFIX=/path/to/md in /etc/make.conf. It substantially reduces compile time by about 5-10 times. Thanx to all ur replies. -Ashok Shrestha An alternative is to try using the "-pipe" flag with GCC: this eliminates the need to use some temporary files by using a unix pipe for IPC. Setting another flag "-j 2" will allow 2 jobs to be done at the same time and should eliminate (by hiding) the I/O delays (this slows down the CPU slightly because of more task switches, but even with one job there are still lots of generated tasks). If you combine these, you should see your compilations becoming CPU-bound. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: speed up port compiling using RAM (tmpfs) ???
I mounted part of RAM as such: mdmfs -s 500m md /mnt Then put WRKDIRPREFIX=/path/to/md in /etc/make.conf. It substantially reduces compile time by about 5-10 times. Thanx to all ur replies. -Ashok Shrestha On 1/19/06, Wesley Shields <[EMAIL PROTECTED]> wrote: > On Thu, Jan 19, 2006 at 05:54:02PM +0100, Dag-Erling Sm?rgrav wrote: > > Mike Meyer <[EMAIL PROTECTED]> writes: > > > Will using a swap-backed disk change anything? > > > > Not really. > > > > > How about the best way to configure things to use two disks for the > > > compile? > > > > I'm not sure what you are trying to achieve. Unlike the base system, > > the ports tree does not use separate source and object directories. > > I think he is trying to get at a scenario where WRKDIR is on a seperate > disk from the one /usr/ports is on. > > To answer his question, assuming this is what he is going, for why not > just add a new physical disk to the system per the handbook, and set > WRKDIR to be where ever that disk is mounted. > > -- WXS > -- Ashok Shrestha ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: speed up port compiling using RAM (tmpfs) ???
On Thu, Jan 19, 2006 at 05:54:02PM +0100, Dag-Erling Sm?rgrav wrote: > Mike Meyer <[EMAIL PROTECTED]> writes: > > Will using a swap-backed disk change anything? > > Not really. > > > How about the best way to configure things to use two disks for the > > compile? > > I'm not sure what you are trying to achieve. Unlike the base system, > the ports tree does not use separate source and object directories. I think he is trying to get at a scenario where WRKDIR is on a seperate disk from the one /usr/ports is on. To answer his question, assuming this is what he is going, for why not just add a new physical disk to the system per the handbook, and set WRKDIR to be where ever that disk is mounted. -- WXS ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: speed up port compiling using RAM (tmpfs) ???
Mike Meyer <[EMAIL PROTECTED]> writes: > Will using a swap-backed disk change anything? Not really. > How about the best way to configure things to use two disks for the > compile? I'm not sure what you are trying to achieve. Unlike the base system, the ports tree does not use separate source and object directories. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Apache & PV_ENTRY
Hello list, I am configuring a very heavily used apache webserver, that required some special needs. This particular configuration needs to have at least 1024 httpds always running. Reaching this number is not a problem, but whenever I stop apache via apachectl stop, I notice all the httpds take a long time (1 min) to vanish - and meanwhile, top shows most of them locked. The states I see in top are: *vm ob RUN while the header shows: 1038 processes:332 running, 12 sleeping, 694 lock The numbers vary a lot. Eventually, they get killed, but it takes too much time. After some searching, I found out the cause for this was running out of PVs. I've added the following relevant options to the kernel: options KVA_PAGES=768 options PMAP_SHPGPERPROC=5120 sysctl vm.zone | grep PV shows: (note: httpd stopped here) (limit) (used) (free) (requests) PV ENTRY: 24, 84410445, 5522, 1632543, 5381679 So, if my assumptions are correct, and running out of PVs was the cause (I did get that message about increasing PMAP_SHPGPERPROC before I placed that in the kernel), there is a problem now. If you look at the vm.zone output, there are 84,410,445 PVs that could exist, but the system shows only 1,632,543 free. This leads me to believe there is another thing to tune. I already have a high PVs limit, but according to this output, it's not going further than 1,6 millions. My question is, what can I do to make the system use the full 84 millions, as I have not found any way to do this. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: tuning to run large (1000+) numbers of null_mounts
On Wed, 18 Jan 2006, Kris Kennaway wrote: > > hmmm...the cut and paste of that loud warning was from a 6.0-RELEASE man > > page ... if I need to be CURRENT to get the updated man page, do I also > > need to be CURRENT to get the safe null_mount code itself ? > > > > Or is 6.0-RELEASE safe ? (re: null_mount) > > > > Thanks a lot. > > 6.0-RELEASE is also safe. I only just removed the warning the other > day, but I'll also be merging it to 6.0-STABLE. Ok, that is good to know. However, I continue to see instability on this system with the 2000+ null_mounts. Are there any system tunables / sysctls / kernel configurations that I should be studying or experimenting with that are relevant to this ? Perhaps looking more broadly, are there any tunables related to large numbers of mounted filesystems _period_, not just null mounts ? For what it is worth, the system also has several mdconfig'd and mounted snapshots (more than 5, less than 10). Further, all of the null mounts mount space from within a mounted snapshot into normal filesystem space. With all the snapshots mounted and all the null mounts mounted, I find that commencing an rsync from the filesystem that all these exist on locks up the machine. I can still ping it, but it refuses all connections. It requires a power cycle. Comments ? ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: speed up port compiling using RAM (tmpfs) ???
Ashok Shrestha <[EMAIL PROTECTED]> writes: > I am curious to know if there is a way to compile a port such as X11 > or KDE faster. > > I know in Gentoo, you can mount a part of RAM and compile in that. > This substantially decreases the compile time. Reference: > http://gentoo-wiki.com/TIP_Speeding_up_portage_with_tmpfs > > Does anyone know how to do this in Freebsd? I doubt it would help. You get faster disk accesses, but significantly reduce the amount of memory available for the buffer cache. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
