Newly developed mailling list search engine needs testing

2006-01-19 Thread Choy Kho Yee
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)

2006-01-19 Thread Scott Long

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?

2006-01-19 Thread M. Warner Losh
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)

2006-01-19 Thread Craig Boston
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?

2006-01-19 Thread Peter Jeremy
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) ???

2006-01-19 Thread Kris Kennaway
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) ???

2006-01-19 Thread Gary Thorpe

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) ???

2006-01-19 Thread Ashok Shrestha
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) ???

2006-01-19 Thread Wesley Shields
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) ???

2006-01-19 Thread Dag-Erling Smørgrav
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

2006-01-19 Thread BSD

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

2006-01-19 Thread Ensel Sharon


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) ???

2006-01-19 Thread Dag-Erling Smørgrav
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]"