headers
Centro Diete | 4 May 2011 10:52

Dimagrire senza fatica

E' arrivata la bella stagione!

Con il nuovo metodo dimagrante,ti GARANTIAMO fino a 8 kg in meno al mese (soddisfatti o rimborsati).

Cicca qui http://dimagrimento.click-page.net

*I dati sopra riportati sono i risultati della sperimentazione scientifica e degli studi sperimentali
sul prodotto eseguiti dall'Istituto Superiore di Igiene Alimentare.
Permalink | Reply | 0 comments |
headers
Rui-Xiang Guo | 5 May 2011 19:13

_lwp_park issue?

Hi, all.
When testing chromium 11, I get such error on both NetBSD-5.1 amd64/i386.
It looks like the pthread issue. Here is the gdb output -
[...]
Program received signal SIGTRAP, Trace/breakpoint trap.
0x00007f7ff6934d4a in _lwp_park () from /usr/lib/libc.so.12
(gdb) bt
#0  0x00007f7ff6934d4a in _lwp_park () from /usr/lib/libc.so.12
#1  0x00007f7ff6c0840a in pthread_mutex_trylock ()
   from /usr/lib/libpthread.so.0
#2  0x0000000000d31aed in base::internal::LockImpl::Lock ()
#3  0x0000000001664b72 in BrowserThread::PostTaskHelper ()
#4  0x0000000001664d71 in BrowserThread::PostTask ()
#5  0x0000000000595a04 in SafeBrowsingService::GetDatabase ()
#6  0x0000000000d0737e in MessageLoop::RunTask ()
#7  0x0000000000d075d8 in MessageLoop::DeferOrRunPendingTask ()
#8  0x0000000000d0781d in MessageLoop::DoWork ()
#9  0x0000000000d0b85b in base::MessagePumpDefault::Run ()
#10 0x0000000000d07bc2 in MessageLoop::RunInternal ()
#11 0x0000000000d07d54 in MessageLoop::Run ()
#12 0x0000000000d3822e in base::Thread::ThreadMain ()
#13 0x0000000000d35902 in base::(anonymous namespace)::ThreadFunc ()
#14 0x00007f7ff6c0bd92 in pthread_setcancelstate ()
   from /usr/lib/libpthread.so.0
#15 0x00007f7ff69545b0 in swapcontext () from /usr/lib/libc.so.12
#16 0x00007f7ff3200000 in ?? ()
#17 0x0000000111110001 in ?? ()
#18 0x0000000033330003 in ?? ()
#19 0x0000000000000000 in ?? ()
(Continue reading)

Permalink | Reply | 2 comments |
headers
Masao Uebayashi | 12 May 2011 05:46
Picon
Gravatar

Re: reduce size of pv_pte

In the very long run, we will be able to cache a reference to a
vm_physseg on the fault handler stack, then pass (paddr_t, vm_page) to
pmap.  I agree that PHYS_TO_VM_PAGE is a bad idea in general.

Masao

On Thu, May 12, 2011 at 6:25 AM, Lars Heidieker <lars <at> heidieker.de> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 04/26/11 00:40, YAMAMOTO Takashi wrote:
>> hi,
>>
>> the following patch reduces the size of pv_pte, thus pv_entry and vm_page.
>> comments?
>>
>> YAMAMOTO Takashi
>>
>
> Hi, that's interesting. It is cutting a pv_entry from 40 bytes down to
> 32 bytes for 64 bit.
> I've a concern about the runtime requirements because of the
> PHYS_TO_VM_PAGE lookup which might be significant.
> Do all amd64 machines have only a few physical memory segments?
>
> Lars
>
>> Index: include/pmap_pv.h
>> ===================================================================
>> RCS file: /cvsroot/src/sys/arch/x86/include/pmap_pv.h,v
(Continue reading)

Permalink | Reply | 1 comment |
headers
Joerg Sonnenberger | 12 May 2011 23:54
Picon

clang, arch/i386/stand and the calling convention

Hi all,
the last unresolved issues with clang integration are the CMSG* hack and
the size of the boot loader. The former is outside the scope of this
mail, leaving the size of the boot loader. I have some size optimised
versions of the common string routines and with that all of the normal
bootxx images except msdos and ustar fit. The netboot images don't so
far.

The major reason is that LLVM currently doesn't support a push[bwl]
based argument handling like GCC uses for size-optimised code. That
means instead of e.g. using
	pushl $3
	pushl $2
	pushl $1
	call foo
it is always using the larger
	movl $3, 8(%esp)
	movl $2, 4(%esp)
	movl $1, (%esp)
	call foo
sequence for foo(1,2,3). The second form is normally preferable as it
allows better scheduling.

There are two basic approaches for dealing with this:
(1) Implement the other argument handling style for size optimised code.
This is relatively much work for something not necessarily used often.

(2) Use the more efficient register-based fastcall convention for stand.
This requires changes to the assembler code (but quite a bit is begging
for size optimisation anyway, e.g. libkern), but doesn't involve changes
(Continue reading)

Permalink | Reply | 0 comments |
headers
YAMAMOTO Takashi | 13 May 2011 04:12
Picon

Re: reduce size of pv_pte

hi,

> In the very long run, we will be able to cache a reference to a
> vm_physseg on the fault handler stack, then pass (paddr_t, vm_page) to
> pmap.  I agree that PHYS_TO_VM_PAGE is a bad idea in general.

i don't think it's relevant to this patch.
pvkey_decode is only used for P->V operations.

YAMAMOTO Takashi

> 
> Masao
Permalink | Reply | 0 comments |
headers
Phil Nelson | 13 May 2011 20:15
Picon

New Dell Optiplex 990 Network card problem

Hello,

  I just got a new Dell Optiplex 990 and it contains an Integrated Intel
82579LM Ethernet LAN 10/100/1000 device.  It appears as pci vendor 0x8086,
product 0x1502.   I'm hoping that this is similar enough to a current device
so it just needs to have the vendor/product added.    Does anyone know if
this is the case?

--Phil

--

-- 
Phil Nelson (phil at cs.wwu.edu) http://www.cs.wwu.edu/nelson
NetBSD: http://www.NetBSD.org  Coda: http://www.coda.cs.cmu.edu
Life:  http://www.goallpower.com
Permalink | Reply | 11 comments |
headers
Paul Goyette | 13 May 2011 20:43

Re: New Dell Optiplex 990 Network card problem

Maybe it's close to the wm driver's i82573 ?

Maybe check the datasheets?

On Fri, 13 May 2011, Phil Nelson wrote:

> Hello,
>
>  I just got a new Dell Optiplex 990 and it contains an Integrated Intel
> 82579LM Ethernet LAN 10/100/1000 device.  It appears as pci vendor 0x8086,
> product 0x1502.   I'm hoping that this is similar enough to a current device
> so it just needs to have the vendor/product added.    Does anyone know if
> this is the case?
>
> --Phil
>
> -- 
> Phil Nelson (phil at cs.wwu.edu) http://www.cs.wwu.edu/nelson
> NetBSD: http://www.NetBSD.org  Coda: http://www.coda.cs.cmu.edu
> Life:  http://www.goallpower.com
>
> !DSPAM:4dcd754d2401573588653!
>
>
>

-------------------------------------------------------------------------
| Paul Goyette     | PGP Key fingerprint:     | E-mail addresses:       |
| Customer Service | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com    |
| Network Engineer | 0786 F758 55DE 53BA 7731 | pgoyette at juniper.net |
(Continue reading)

Permalink | Reply | 0 comments |
headers
SAITOH Masanobu | 13 May 2011 21:24

Re: New Dell Optiplex 990 Network card problem

 I'm now writing the patch.

 Attached patch may work for you. 82579 support is not completed yet
because I have a little time to write it now. Only 1 hour work...

BTW: I'm now in Ottawa.

(2011/05/13 14:15), Phil Nelson wrote:
> Hello,
> 
>   I just got a new Dell Optiplex 990 and it contains an Integrated Intel
> 82579LM Ethernet LAN 10/100/1000 device.  It appears as pci vendor 0x8086,
> product 0x1502.   I'm hoping that this is similar enough to a current device
> so it just needs to have the vendor/product added.    Does anyone know if
> this is the case?
> 
> --Phil
> 

--

-- 
-----------------------------------------------
                SAITOH Masanobu (msaitoh <at> execsw.org
                                 msaitoh <at> netbsd.org)
Attachment (wm.dif): video/x-dv, 9 KiB
Permalink | Reply | 9 comments |
headers
Greg Oster | 13 May 2011 21:41
Picon
Picon
Favicon

Re: New Dell Optiplex 990 Network card problem

On Fri, 13 May 2011 15:24:23 -0400
SAITOH Masanobu <msaitoh <at> execsw.org> wrote:

>  I'm now writing the patch.

Cool!!  I have a Gateway DX4850-45CU that has the 82579V chip.  I'm 
certainly happy to help with testing on this.  (The 82579V shows up as 
vendor 0x8086, product 0x1503, and I see you already have it listed in
your patch :) )

Later...

Greg Oster

>  Attached patch may work for you. 82579 support is not completed yet
> because I have a little time to write it now. Only 1 hour work...
> 
> BTW: I'm now in Ottawa.
> 
> (2011/05/13 14:15), Phil Nelson wrote:
> > Hello,
> > 
> >   I just got a new Dell Optiplex 990 and it contains an Integrated
> > Intel 82579LM Ethernet LAN 10/100/1000 device.  It appears as pci
> > vendor 0x8086, product 0x1502.   I'm hoping that this is similar
> > enough to a current device so it just needs to have the
> > vendor/product added.    Does anyone know if this is the case?
> > 
> > --Phil
> >
(Continue reading)

Permalink | Reply | 0 comments |
headers
Phil Nelson | 13 May 2011 22:17
Picon

Re: New Dell Optiplex 990 Network card problem

On Friday 13 May 2011 12:24:23 pm SAITOH Masanobu wrote:
>  I'm now writing the patch.
> 

Thanks much.  I'll check it out.

--Phil

--

-- 
Phil Nelson (phil at cs.wwu.edu) http://www.cs.wwu.edu/nelson
NetBSD: http://www.NetBSD.org  Coda: http://www.coda.cs.cmu.edu
Life:  http://www.goallpower.com
Permalink | Reply | 7 comments |

Gmane