> pacija wrote:
>
> - Original Message -
> > Dear list readers,
> >
> > I am having a problem with pxe loader on FreeBSD 9.0 i386 release. No
> > matter what value I put for DHCP option 017 (Root Path) in Microsoft
> > DHCP server, pxe always sets root path:
> > pxe_open: server path: /
>
> > pacija wrote:
> >
> > - Original Message -
> > > Dear list readers,
> > >
> > > I am having a problem with pxe loader on FreeBSD 9.0 i386 release. No
> > > matter what value I put for DHCP option 017 (Root Path) in Microsoft
> > > DHCP server, pxe always sets root path:
> > > pxe_open
>
> --=-etjkwQYOTmf8U9KY0eW8
> Content-Type: text/plain; charset="us-ascii"
> Content-Transfer-Encoding: 7bit
>
> > > pacija wrote:
> > >
> > > - Original Message -
> > > > Dear list readers,
> > > >
> > > > I am having a problem with pxe loader on FreeBSD 9.0 i386 release. No
> > > > m
On 28-5-2012 23:22, Jeremie Le Hen wrote:
> Hi Mel,
>
> On Sun, May 27, 2012 at 08:15:02PM +0200, Mel Flynn wrote:
>> Hi,
>>
>> for a port, I'm seeing:
>> #ifdef _FORTIFY_SOURCE
>> ...
>> #endif
>>
>> I did a bit of reading (http://wiki.debian.org/Hardening) for example,
>> searching through /usr/
Hi,
In case of a Multicore cpu system running a multithreaded process.
For protocol control blocks there is no protection provided in the FreeBSD
9. For example, udp_close() and udp_send() access the inp before taking the
lock. Couldn't this cause the inp inconsistency on a multithreaded process
Hi Alexander and others,
I've been tinkering with ath(4) IO scheduling and taskqueues. In order
to get proper "in order" TX IO occuring, I've placed ath_start() into
a taskqueue so now whenever ath_start() is called, it just schedules a
taskqueue entry to run.
However, performance is worse. :-)
.. also, if you take a look at the ktr output, the CPU timers between
CPU 0 and CPU 1 are slightly different. schedgraph complains quite
loudly. :-)
Is that acceptable/possible?
Adrian
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.
2012/5/29 Adrian Chadd :
> Hi Alexander and others,
>
> I've been tinkering with ath(4) IO scheduling and taskqueues. In order
> to get proper "in order" TX IO occuring, I've placed ath_start() into
> a taskqueue so now whenever ath_start() is called, it just schedules a
> taskqueue entry to run.
>
Can somebody please reply to this email.
basically, can udp_detach() and udp_send() execute simultaneously for a
process with multiple threads? if yes, then inp reference in udp_send()
will be stale if udp_detach() free's the inp?
Thanks,
Vasanth
On Tue, May 29, 2012 at 10:53 AM, vasanth rao n
On Tue, 29 May 2012, vasanth rao naik sabavat wrote:
In case of a Multicore cpu system running a multithreaded process.
For protocol control blocks there is no protection provided in the FreeBSD
9. For example, udp_close() and udp_send() access the inp before taking the
lock. Couldn't this c
On Tue, 29 May 2012, vasanth rao naik sabavat wrote:
Can somebody please reply to this email.
basically, can udp_detach() and udp_send() execute simultaneously for a
process with multiple threads? if yes, then inp reference in udp_send() will
be stale if udp_detach() free's the inp?
You ar
Hello Robert,
My main concern is about the protocol control block "inp", a reference in
the socket structure. the udp_detach() free'es the inp but there is a
potential for other thread running udp_* functions to get hold of the
reference? Also, sofree() calls SOCK_UNLOCK() which potentially may al
On 29 May 2012, at 18:06, vasanth rao naik sabavat
wrote:
> My main concern is about the protocol control block "inp", a reference in the
> socket structure. the udp_detach() free'es the inp but there is a potential
> for other thread running udp_* functions to get hold of the reference? Also,
Hi Robert,
I am trying to understand the socket <--> protocol layer as part of our
project. I was trying to understand why the sotoinpcb() is called before
taking any locks. Also, I am trying to understand scenario of a
multi-threaded process trying to do socket operations simultaneously on a
mult
On 5/27/2012 10:06 PM, Bryan Drewery wrote:
> Hi,
>
> As reported in bin/146189, script(1) was returning the wrong exit status
> sometimes.
>
> The PR says that script(1) was broken by r205008/r205635, neither of
> which are in 7-stable or releng/7.4. Yet it is broken on 7.4.
>
> This is easil
On 29 May 2012, at 21:09, vasanth rao naik sabavat wrote:
> I am trying to understand the socket <--> protocol layer as part of our
> project. I was trying to understand why the sotoinpcb() is called before
> taking any locks. Also, I am trying to understand scenario of a
> multi-threaded proc
16 matches
Mail list logo
