on 18/04/2011 03:54 Alexander Kabaev said the following:
>
> I would blame it, and expressly at that. -pthread is a shortcut for
> {-lpthread -lc} instead of just {-lc} in the place where implied libc
> is provided by the compiler driver and has no magic properties you want
> it it to have. If chr
On Sun, 17 Apr 2011 15:11:03 +0300
Daniel Braniss wrote:
> when something gets too complicated, it's usualy helpful to look for other
> ways
> out:
> the /(root) + /usr + kernel-debuging + src is less than 1GB, so what I
> do (when diskless is not an option), I have a 2 partitions, both bootable,
On Sun, 17 Apr 2011 18:56:52 +0300
Andriy Gapon wrote:
> on 17/04/2011 18:21 Daniel Eischen said the following:
> > On Sun, 17 Apr 2011, Andriy Gapon wrote:
> >
> >> on 16/04/2011 14:46 Andriy Gapon said the following:
> >>> The second puzzle is the EPERM return value itself, on stable/8.
> >>>
On Sun, 17 Apr 2011 17:39:43 +0300
Andriy Gapon wrote:
> on 16/04/2011 14:46 Andriy Gapon said the following:
> > The second puzzle is the EPERM return value itself, on stable/8.
> > From what I seem chromium does a bunch of forks before it gets to
> > the place of interest. My debugging shows t
> On Sun, Apr 17, 2011 at 03:49:48PM -0400, Rick Macklem wrote:
> > Hi,
> >
> > I should know the answer to this, but... When reading a global
> > kernel
> > variable, where its modifications are protected by a mutex, is it
> > necessary to get the mutex lock to just read its value?
> >
> > For exa
On Sun, Apr 17, 2011 at 03:49:48PM -0400, Rick Macklem wrote:
> Hi,
>
> I should know the answer to this, but... When reading a global kernel
> variable, where its modifications are protected by a mutex, is it
> necessary to get the mutex lock to just read its value?
>
> For example:
> Aif ((
2011/4/17 Rick Macklem :
> Hi,
>
> I should know the answer to this, but... When reading a global kernel
> variable, where its modifications are protected by a mutex, is it
> necessary to get the mutex lock to just read its value?
>
> For example:
> A if ((mp->mnt_kern_flag & MNTK_UNMOUNTF) != 0
Hi,
I should know the answer to this, but... When reading a global kernel
variable, where its modifications are protected by a mutex, is it
necessary to get the mutex lock to just read its value?
For example:
Aif ((mp->mnt_kern_flag & MNTK_UNMOUNTF) != 0)
return (EPERM);
versus
B
On Sun, 17 Apr 2011, Andriy Gapon wrote:
on 17/04/2011 18:21 Daniel Eischen said the following:
On Sun, 17 Apr 2011, Andriy Gapon wrote:
on 16/04/2011 14:46 Andriy Gapon said the following:
The second puzzle is the EPERM return value itself, on stable/8.
From what I seem chromium does a bunc
on 17/04/2011 18:21 Daniel Eischen said the following:
> On Sun, 17 Apr 2011, Andriy Gapon wrote:
>
>> on 16/04/2011 14:46 Andriy Gapon said the following:
>>> The second puzzle is the EPERM return value itself, on stable/8.
>>> From what I seem chromium does a bunch of forks before it gets to the
On Sun, 17 Apr 2011, Andriy Gapon wrote:
on 16/04/2011 14:46 Andriy Gapon said the following:
The second puzzle is the EPERM return value itself, on stable/8.
From what I seem chromium does a bunch of forks before it gets to the place of
interest. My debugging shows that those forks are "singl
on 16/04/2011 14:46 Andriy Gapon said the following:
> The second puzzle is the EPERM return value itself, on stable/8.
> From what I seem chromium does a bunch of forks before it gets to the place of
> interest. My debugging shows that those forks are "single-threaded" (i.e.
> code
> in thr_fork
on 16/04/2011 14:46 Andriy Gapon said the following:
>
> Guys,
>
> I am trying to debug this chromium issue:
> http://trillian.chruetertee.ch/chromium/ticket/13
> Not sure SOCK_SEQPACKET mentioned in the ticket is an actual culprit, the
> problem that interests me is that pthread_cond_wait() retu
>
> --Kj7319i9nmIyA2yE
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
> Content-Transfer-Encoding: quoted-printable
>
> On Sat, Apr 16, 2011 at 04:46:53PM -0600, Warren Block wrote:
> >On Sat, 16 Apr 2011, dieter...@engineer.com wrote:
> >
> >>Suggestion 2: The kernel
14 matches
Mail list logo
