> > Hi
> >
> > I ripped regexp library from FreeBSD 4 and use it in another program. I
> > get random crashes because the library casts char to int and uses it as
> > array index ... the most obvious case is engine.i:189:
> > register char *dp;
> > dp += charjump[(int)*dp];
> > but there are many m
Hi
I ripped regexp library from FreeBSD 4 and use it in another program. I
get random crashes because the library casts char to int and uses it as
array index ... the most obvious case is engine.i:189:
register char *dp;
dp += charjump[(int)*dp];
but there are many more and I'm unable to spot them
> Hi
>
> I use FreeBSD-4.9-RC1 on a machine with hyperthreading (it seems that
> hyperthreading support was ripped out of final 4.9 release --- why?)
>
> I get random SIGBUSes when compiling (once I got SIGSEGV too). When I
> compile only with make -j 1, I get no errors. Is it known problem with
>
Hi
I use FreeBSD-4.9-RC1 on a machine with hyperthreading (it seems that
hyperthreading support was ripped out of final 4.9 release --- why?)
I get random SIGBUSes when compiling (once I got SIGSEGV too). When I
compile only with make -j 1, I get no errors. Is it known problem with
FreeBSD? Or do
> In message <[EMAIL PROTECTED]>, Kris Kennaway writes:
> >Yes, that's because (as discussed in the archives) the kernel treats
> >it like an extra, completely decoupled physical CPU and schedules
> >processes on it without further consideration. This is presumably the
> >cause of the slowdown, be
Hi
I installed FreeBSD 4.9RC1 on P4 3GHz with hyperthreading and I see
drastic slowdown when kernel with hyperthreading is booted. For example
program compilation took this time:
hyperthreading kernel, make -j 1 --- 1:09
hyperthreading kernel, make -j 2 --- 0:42
singlethreading kernel, make -j
On Tue, 26 Aug 2003, Dan Lukes wrote:
> Mikulas Patocka napsal/wrote, On 08/20/03 01:39:
> > I am reading FreeBSD ATA drivers because I want to use them as base for my
> > ATA driver and I found a total nonsence: in ata-dma.c in FreeBSD 4.8,
> > there is line
> >
On Wed, 20 Aug 2003, Mikulas Patocka wrote:
> Hi
>
> I am reading FreeBSD ATA drivers because I want to use them as base for my
> ATA driver and I found a total nonsence: in ata-dma.c in FreeBSD 4.8,
> there is line
>
> if (!((pci_read_config(parent,0x40,4)>>(ch->
Hi
I am reading FreeBSD ATA drivers because I want to use them as base for my
ATA driver and I found a total nonsence: in ata-dma.c in FreeBSD 4.8,
there is line
if (!((pci_read_config(parent,0x40,4)>>(ch->unit<<8))&0x4000)) {
if ch->unit is 1, config word is shifted by 256 bytes, which gives
un
> : Well, the application date is what counts, and that's mar1992, but I'm
> : pretty sure that Bill Jolitz had them beat to that date already...
>
> I'm pretty sure that VMS 3.x used a similar technique. I have my old
> VMS internals docs from that time frame (maybe they are from 4.x).
> We're
> The key thing with patents is that they are meaningless until the
> patent holder decides to protect them in court by challenging the
> people who are supposedly in violation of the patent. If a patent
> holder decides to go after you, it can be costly even if you win.
They can
> So it looks like we have prior art by around 6 years, which would
> invalidate the patent iff it was the same thing.
Does it mean that the algorithm is free to use by everyone or free to use
only in freebsd? I would like to implemet these page table back pointers
too and I'm scared by the paten
Hi
Go to http://www.uspto.gov/patft/, search for patent number 5873127, and
you will find the description of mapping page table entries into virtual
memory via one page directory entry pointing to the page directory itself
- exactly what FreeBSD does with PTDPTDI and APTDPTDI entries on i386.
(in
> > It skips queue pq[index & PQ_L2_MASK].
> >
>
> That's correct. The inline function vm_page_list_find() in vm_page.h
> has already failed to allocate a page of the desired color, index,
> and so _vm_page_list_find() is called to allocate a page of ANY other
> color it can find.
Oh, yes. I d
Hi.
Isn't the page coloring algoritm in _vm_page_list_find totally bogus?
It skips queue pq[index & PQ_L2_MASK].
If it doesn't find page with desired color, it allocates page with nearest
color - as a result there are two pages with same color mapped at two
adjacent virtual adresses - this is t
15 matches
Mail list logo
