[prev in list] [next in list] [prev in thread] [next in thread]
List: squeak-vm-dev
Subject: Re: [Vm-dev] Heartbeat & Linux
From: Casey Ransberger <casey.obrien.r () gmail ! com>
Date: 2013-04-24 20:07:43
Message-ID: CACemAZe1Pjxx7+9Z4Y9iLZBskZS7dtMq26PqUweKSvDtKWWRBw () mail ! gmail ! com
[Download RAW message or body]
[Attachment #3 (multipart/alternative)]
Bert, I didn't say I thought the Stack VM would be too slow without messing
with pthreads, or I didn't mean to. The idea is to see how far I can push
the little gadget:)
On Mon, Apr 22, 2013 at 10:52 AM, Eliot Miranda <eliot.miranda@gmail.com>wrote:
>
>
>
> On Mon, Apr 22, 2013 at 10:31 AM, Bert Freudenberg <bert@freudenbergs.de>wrote:
>
>>
>>
>> On 2013-04-22, at 19:16, Eliot Miranda <eliot.miranda@gmail.com> wrote:
>>
>>
>>
>> On Mon, Apr 22, 2013 at 5:33 AM, Bert Freudenberg <bert@freudenbergs.de>wrote:
>>
>>>
>>> Still, you make it sound like this inefficiency is actually preventing
>>> the Stack VM from running on the Raspberry Pi? That is hard to believe.
>>>
>>
>> No, we just use the interval timer. But as I say in a
>> server/multi-user/ffi context the interval timer is problematic.
>>
>>
>> Okay. So for the typical local single pi user it should be fine :)
>>
>> Btw, what kind of deadlocks have you seen with SA_RESTART? Normally that
>> should avoid the EINTR problems.
>>
>
> Just weird bugs that look like linux internal issues.
>
> The most recent one is with PAM, the authentication library, using
> pam_start and pam_authenticate with a callback to fetch the password (the
> pam_conv structure). On linux if one successfully authenticates then fine.
> But if one answers an invalid password to fail the authentication the
> ITIMER_REAL interval timer's reload value gets set to zero, disabling the
> heartbeat. If one puts a breakpoint on the setitimer entry-point for the
> setitimer system call then it is never called (I didn't put a breakpoint on
> the indirect system call).
>
> The previous one with RHES 4 is that if there are two threads in the VM
> then very occasionally in the delivery of the SIGALRM signal the kernel
> confuses the thread control blocks of the two threads and one ends up with
> both the VM and the second thread running the second thread's code,
> freezing the VM.
>
> <rant>Essentially I think linux has serious quality control issues and the
> itimer tickles them. These things are a right royal pain in the ass to
> debug and a pain to work-around. I don't see much difference between
> Windows and linux in terms of quality. They're both abysmal. In my
> experiemce Mac OS X, Solaris and HP-UX are of signaificantly higher
> quality</rant>.
>
>>
>> - Bert -
>>
>>
>>> - Bert -
>>>
>>> On 2013-04-19, at 05:24, Casey Ransberger <casey.obrien.r@gmail.com>
>>> wrote:
>>>
>>> I had a feeling the actual problem was probably political. The name is
>>> also a bit... well. As many children will prefer to avoid the use of
>>> profanity while raising their parents, I wonder if I shouldn't start by
>>> forking it and calling it the Big Furry Scheduler or something...
>>>
>>> Anyhow this sheds lots of light on things. Thank, Eliot!
>>>
>>>
>>> On Thu, Apr 18, 2013 at 1:29 PM, Eliot Miranda <eliot.miranda@gmail.com>wrote:
>>>
>>>>
>>>> Hi Casey,
>>>>
>>>> On Thu, Apr 18, 2013 at 5:37 AM, Casey Ransberger <
>>>> casey.obrien.r@gmail.com> wrote:
>>>>
>>>>>
>>>>> Totally. I know it isn't going to be a small thing. I'm curious if any
>>>>> of the BSD implementations solve the problem adequately for Cog; I might
>>>>> have something working to study, build tests around, etc. A control group.
>>>>>
>>>>
>>>> The technical problem was solved for Linux in 2009 by Con Kolivas with
>>>> his (excuse the language)
>>>> http://en.wikipedia.org/wiki/Brain_Fuck_Scheduler. The political
>>>> problem of getting it adopted throughout the linux community so it can be
>>>> relied upon is an entirely different thing.
>>>>
>>>> Note that once BFS is more widely available I could write a VM that
>>>> will test thread priorities on startup and use threads if multiple
>>>> priorities are supported, falling back on the ITIMER if not.
>>>>
>>>>
>>>>>
>>>>> Either way though, it would be a largish win for the community, given
>>>>> the widespread popularity of Linux. I might be able to find some friends
>>>>> who might like to attack it with me. Etcetera.
>>>>>
>>>>> I wonder about why the Linux folks haven't dealt with it already.
>>>>> Maybe it hasn't come up. Hopefully it isn't a security thing, that'd be
>>>>> hard to make a case about.
>>>>>
>>>>> Either way, I haven't figured out where to start looking yet.
>>>>>
>>>>>
>>>>> On Thu, Apr 18, 2013 at 5:23 AM, David T. Lewis <lewis@mail.msen.com>wrote:
>>>>>
>>>>>>
>>>>>> I think that Eliot has described the issue in some detail either on
>>>>>> this list, or on his blog http://www.mirandabanda.org/cogblog/. Sorry
>>>>>> I don't have any links handy, but reading through the blog is time
>>>>>> well spent in any case :)
>>>>>>
>>>>>> I think you are dealing with a fundamental issue in the pthreads
>>>>>> implementation(s) on Linux, so don't be surprised if it's not just
>>>>>> a simple matter of fixing a bug. The pthreads implementation is more
>>>>>> or less grafted onto the original Unix process model, and operating
>>>>>> systems tend to vary as to whether they support pthreads fully, or
>>>>>> for that matter whether they support a thread model at all.
>>>>>>
>>>>>> Dave
>>>>>>
>>>>>> On Thu, Apr 18, 2013 at 05:07:42AM -0700, Casey Ransberger wrote:
>>>>>> >
>>>>>> > Well I guess maybe I left a part of the message out. Oops. I'm
>>>>>> talking
>>>>>> > about Cog's heart. It needs user-level thread prioritization and
>>>>>> apparently
>>>>>> > (GNU/?)Linux lacks this.
>>>>>> >
>>>>>> > My guess is it's a kernel issue. But that's an uneducated guess.
>>>>>> >
>>>>>> > It became interesting to me because I'm not super happy with the UI
>>>>>> > responsiveness of Squeak trunk under the interpreter and Raspbian
>>>>>> on a
>>>>>> > 700MHz Pi (out of box experience isn't overclocked, so I'm
>>>>>> targeting that.)
>>>>>> > My thought was to get the stack VM going, but we still have this
>>>>>> issue with
>>>>>> > the heartbeat for the stack VM to be able to perform optimally. If
>>>>>> I can
>>>>>> > fix the heartbeat (read: pthreads) issue, I can benefit GNU/Linux
>>>>>> users of
>>>>>> > the system across the board, both in terms of the (Intel) JIT, and
>>>>>> in terms
>>>>>> > of the stack oriented virtual machine which has the awesome
>>>>>> Ungar-style
>>>>>> > garbage collection, right? I want the efficient GC eventually
>>>>>> anyway. The
>>>>>> > advantages of stack orientation are somewhat beyond my current
>>>>>> > understanding of virtual machines, but I gather that's desirable as
>>>>>> well?
>>>>>> > </noob>
>>>>>> >
>>>>>> > I need to do some tests with Cuis, Spoon, Pharo, and Etoys before
>>>>>> I'm going
>>>>>> > to blame any part of the VM about the UI perf I'm seeing, but a
>>>>>> faster VM
>>>>>> > is a faster VM anyway. I'd like to make all of the images faster on
>>>>>> this
>>>>>> > little gadget, because it's cool, it's popular, and it gives us an
>>>>>> approach
>>>>>> > on more than just the third world (not that the third world isn't
>>>>>> > incredibly important, just that if we don't start making better
>>>>>> adults
>>>>>> > where people with first world problems are too, I'll end up feeling
>>>>>> like
>>>>>> > Rick Moranis in Spaceballs or I'm going to have to relocate to
>>>>>> someplace
>>>>>> > where we previously made better adults.)
>>>>>> >
>>>>>> > http://www.youtube.com/watch?v=sen8Tn8CBA4
>>>>>> >
>>>>>> > I know this isn't really the place to ask, but I thought maybe
>>>>>> someone
>>>>>> > might be able to point me at what I'd need to dig into to
>>>>>> understand the
>>>>>> > problem we have with the popular Linux implementation of pthreads,
>>>>>> because
>>>>>> > when I GOOG that, I get #1 a tutorial on using pthreads, #2 a
>>>>>> Wikipedia
>>>>>> > article which speaks abstractly about pthreads, and #3 another
>>>>>> tutorial on
>>>>>> > using pthreads. I think I'm trying to figure out what to google for
>>>>>> so that
>>>>>> > I can figure out where the problem lives and then look at it to see
>>>>>> whether
>>>>>> > or not I can steal its lunch money.
>>>>>> >
>>>>>> > Even if I google "linux pthreads" I still get a tutorial on using
>>>>>> them as
>>>>>> > the top hit.
>>>>>> >
>>>>>> > This is the most directly informative thing I can find:
>>>>>> >
>>>>>> > http://man7.org/linux/man-pages/man7/pthreads.7.html
>>>>>> >
>>>>>> > Hopefully this explains anything I might have left out of my first
>>>>>> message
>>>>>> > on the subject!
>>>>>> >
>>>>>> > Casey
>>>>>> >
>>>>>> >
>>>>>> > On Wed, Apr 17, 2013 at 5:33 AM, David T. Lewis <
>>>>>> lewis@mail.msen.com> wrote:
>>>>>> >
>>>>>> > >
>>>>>> > > On Wed, Apr 17, 2013 at 01:15:45AM -0700, Casey Ransberger wrote:
>>>>>> > > >
>>>>>> > > > I'm assuming the problem is in the kernel, but making
>>>>>> assumptions is
>>>>>> > > usually a bad plan, so I'm asking.
>>>>>> > > >
>>>>>> > > > When I look, I find a rather confusing jumble: pthreads exists
>>>>>> in
>>>>>> > > different implementations under different operating systems.
>>>>>> > > >
>>>>>> > > > I'd kind of like the heartbeat to work right under Raspbian,
>>>>>> because
>>>>>> > > kids are going to use it, and the goal of producing better adults
>>>>>> is pretty
>>>>>> > > close to my heart. See also making Squeak faster. (Stack VM.)
>>>>>> > > >
>>>>>> > > > I want to arm myself with as much knowledge about this as
>>>>>> possible,
>>>>>> > > because I'm considering just bloody fixing it. If the (GNU/Linux)
>>>>>> community
>>>>>> > > has objections, and I'm able to pull off the fix, I can make a
>>>>>> patch
>>>>>> > > available to people who want it.
>>>>>> > > >
>>>>>> > > > I'm not confident that I can fix the bug with the knowledge I
>>>>>> have now,
>>>>>> > > but I'm confident that I can fix it eventually, if someone else
>>>>>> doesn't
>>>>>> > > beat me to the punch.
>>>>>> > > >
>>>>>> > > > Outside of the wiki page, are there any
>>>>>> documents/people/mailing lists I
>>>>>> > > should look at to be able to get a good handle on where in the
>>>>>> kernel (or
>>>>>> > > elsewhere) I should be looking for the code which isn't meeting
>>>>>> our
>>>>>> > > Cog-nitive requirements?
>>>>>> > > >
>>>>>> > >
>>>>>> > > I do not understand what problem or bug you are asking about. Is
>>>>>> there
>>>>>> > > some issue with Raspbian Linux that is causing a problem?
>>>>>> > >
>>>>>> > > Dave
>>>>>> > >
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Casey Ransberger
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> best,
>>>> Eliot
>>>>
>>>>
>>>
>>>
>>> --
>>> Casey Ransberger
>>>
>>>
>>>
>>>
>>
>>
>> --
>> best,
>> Eliot
>>
>>
>> - Bert -
>>
>>
>>
>>
>
>
> --
> best,
> Eliot
>
>
--
Casey Ransberger
[Attachment #6 (text/html)]
<div dir="ltr">Bert, I didn't say I thought the Stack VM would be too slow \
without messing with pthreads, or I didn't mean to. The idea is to see how far I \
can push the little gadget:)</div><div class="gmail_extra"> <br><br><div \
class="gmail_quote">On Mon, Apr 22, 2013 at 10:52 AM, Eliot Miranda <span \
dir="ltr"><<a href="mailto:eliot.miranda@gmail.com" \
target="_blank">eliot.miranda@gmail.com</a>></span> wrote:<br><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"> <br><br><br><div class="gmail_quote">On Mon, Apr 22, 2013 \
at 10:31 AM, Bert Freudenberg <span dir="ltr"><<a \
href="mailto:bert@freudenbergs.de" \
target="_blank">bert@freudenbergs.de</a>></span> wrote:<br><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex">
<br><div style="word-wrap:break-word"><br><div><div>On 2013-04-22, at 19:16, Eliot \
Miranda <<a href="mailto:eliot.miranda@gmail.com" \
target="_blank">eliot.miranda@gmail.com</a>> wrote:</div><br><blockquote \
type="cite">
<br><br><div class="gmail_quote">On Mon, Apr 22, 2013 at 5:33 AM, Bert Freudenberg \
<span dir="ltr"><<a href="mailto:bert@freudenbergs.de" \
target="_blank">bert@freudenbergs.de</a>></span> wrote:<br><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex">
<br><div style="word-wrap:break-word">Still, you make it sound like this \
inefficiency is actually preventing the Stack VM from running on the Raspberry Pi? \
That is hard to believe.</div></blockquote><div><br></div> <div>No, we just use the \
interval timer. But as I say in a server/multi-user/ffi context the interval timer \
is problematic.</div></div></blockquote><div><br></div><div>Okay. So for the typical \
local single pi user it should be fine :) </div>
<div><br></div><div>Btw, what kind of deadlocks have you seen with SA_RESTART? \
Normally that should avoid the EINTR \
problems.</div></div></div></blockquote><div><br></div><div>Just weird bugs that look \
like linux internal issues.</div>
<div><br></div><div>The most recent one is with PAM, the authentication library, \
using pam_start and pam_authenticate with a callback to fetch the password (the \
pam_conv structure). On linux if one successfully authenticates then fine. But if \
one answers an invalid password to fail the authentication the ITIMER_REAL interval \
timer's reload value gets set to zero, disabling the heartbeat. If one puts a \
breakpoint on the setitimer entry-point for the setitimer system call then it is \
never called (I didn't put a breakpoint on the indirect system call).</div>
<div><br></div><div>The previous one with RHES 4 is that if there are two threads in \
the VM then very occasionally in the delivery of the SIGALRM signal the kernel \
confuses the thread control blocks of the two threads and one ends up with both the \
VM and the second thread running the second thread's code, freezing the VM.</div>
<div><br></div><div><rant>Essentially I think linux has serious quality control \
issues and the itimer tickles them. These things are a right royal pain in the ass \
to debug and a pain to work-around. I don't see much difference between Windows \
and linux in terms of quality. They're both abysmal. In my experiemce Mac OS X, \
Solaris and HP-UX are of signaificantly higher quality</rant>.</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div><br></div><div>- \
Bert -</div><br><blockquote type="cite"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div style="word-wrap:break-word"><div><br></div><div><span \
style="border-collapse:separate;border-spacing:0px;font-size:12px"><div \
style="font-family:Helvetica">- Bert -</div><br></span></div><div><div>On 2013-04-19, \
at 05:24, Casey Ransberger <<a href="mailto:casey.obrien.r@gmail.com" \
target="_blank">casey.obrien.r@gmail.com</a>> wrote:</div>
<br><blockquote type="cite"><div dir="ltr">I had a feeling the actual problem was \
probably political. The name is also a bit... well. As many children will prefer to \
avoid the use of profanity while raising their parents, I wonder if I shouldn't \
start by forking it and calling it the Big Furry Scheduler or something...<div>
<br></div><div>Anyhow this sheds lots of light on things. Thank, \
Eliot!</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, \
Apr 18, 2013 at 1:29 PM, Eliot Miranda <span dir="ltr"><<a \
href="mailto:eliot.miranda@gmail.com" \
target="_blank">eliot.miranda@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"> <br>Hi Casey,<br><br><div class="gmail_quote">On Thu, Apr \
18, 2013 at 5:37 AM, Casey Ransberger <span dir="ltr"><<a \
href="mailto:casey.obrien.r@gmail.com" \
target="_blank">casey.obrien.r@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"> <br><div dir="ltr">Totally. I know it isn't going to be \
a small thing. I'm curious if any of the BSD implementations solve the problem \
adequately for Cog; I might have something working to study, build tests around, etc. \
A control group.</div>
</blockquote><div><br></div><div>The technical problem was solved for Linux in 2009 \
by Con Kolivas with his (excuse the language) <a \
href="http://en.wikipedia.org/wiki/Brain_Fuck_Scheduler" \
target="_blank">http://en.wikipedia.org/wiki/Brain_Fuck_Scheduler</a>. The political \
problem of getting it adopted throughout the linux community so it can be relied upon \
is an entirely different thing.</div>
<div><br></div><div>Note that once BFS is more widely available I could write a VM \
that will test thread priorities on startup and use threads if multiple priorities \
are supported, falling back on the ITIMER if not.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px \
#ccc solid;padding-left:1ex"><div dir="ltr"><div> <br></div><div>Either way though, \
it would be a largish win for the community, given the widespread popularity of \
Linux. I might be able to find some friends who might like to attack it with me. \
Etcetera.</div><div> <br></div><div>I wonder about why the Linux folks haven't \
dealt with it already. Maybe it hasn't come up. Hopefully it isn't a security \
thing, that'd be hard to make a case about.</div><div><br> </div><div>Either way, \
I haven't figured out where to start looking yet.</div></div><div \
class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Apr 18, 2013 at 5:23 AM, \
David T. Lewis <span dir="ltr"><<a href="mailto:lewis@mail.msen.com" \
target="_blank">lewis@mail.msen.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"><br> I think that Eliot has described the issue in some \
detail either on<br> this list, or on his blog <a \
href="http://www.mirandabanda.org/cogblog/" \
target="_blank">http://www.mirandabanda.org/cogblog/</a>. Sorry<br> I don't have \
any links handy, but reading through the blog is time<br> well spent in any case \
:)<br> <br>
I think you are dealing with a fundamental issue in the pthreads<br>
implementation(s) on Linux, so don't be surprised if it's not just<br>
a simple matter of fixing a bug. The pthreads implementation is more<br>
or less grafted onto the original Unix process model, and operating<br>
systems tend to vary as to whether they support pthreads fully, or<br>
for that matter whether they support a thread model at all.<br>
<br>
Dave<br>
<div><br>
On Thu, Apr 18, 2013 at 05:07:42AM -0700, Casey Ransberger wrote:<br>
><br>
> Well I guess maybe I left a part of the message out. Oops. I'm talking<br>
> about Cog's heart. It needs user-level thread prioritization and \
apparently<br> > (GNU/?)Linux lacks this.<br>
><br>
> My guess is it's a kernel issue. But that's an uneducated guess.<br>
><br>
> It became interesting to me because I'm not super happy with the UI<br>
> responsiveness of Squeak trunk under the interpreter and Raspbian on a<br>
> 700MHz Pi (out of box experience isn't overclocked, so I'm targeting \
that.)<br> > My thought was to get the stack VM going, but we still have this \
issue with<br> > the heartbeat for the stack VM to be able to perform optimally. \
If I can<br> > fix the heartbeat (read: pthreads) issue, I can benefit GNU/Linux \
users of<br> > the system across the board, both in terms of the (Intel) JIT, and \
in terms<br> > of the stack oriented virtual machine which has the awesome \
Ungar-style<br> > garbage collection, right? I want the efficient GC eventually \
anyway. The<br> > advantages of stack orientation are somewhat beyond my \
current<br> > understanding of virtual machines, but I gather that's desirable \
as well?<br> > </noob><br>
><br>
> I need to do some tests with Cuis, Spoon, Pharo, and Etoys before I'm \
going<br> > to blame any part of the VM about the UI perf I'm seeing, but a \
faster VM<br> > is a faster VM anyway. I'd like to make all of the images \
faster on this<br> > little gadget, because it's cool, it's popular, and \
it gives us an approach<br> > on more than just the third world (not that the \
third world isn't<br> > incredibly important, just that if we don't start \
making better adults<br> > where people with first world problems are too, \
I'll end up feeling like<br> > Rick Moranis in Spaceballs or I'm going to \
have to relocate to someplace<br> > where we previously made better adults.)<br>
><br>
> <a href="http://www.youtube.com/watch?v=sen8Tn8CBA4" \
target="_blank">http://www.youtube.com/watch?v=sen8Tn8CBA4</a><br> ><br>
> I know this isn't really the place to ask, but I thought maybe someone<br>
> might be able to point me at what I'd need to dig into to understand the<br>
> problem we have with the popular Linux implementation of pthreads, because<br>
> when I GOOG that, I get #1 a tutorial on using pthreads, #2 a Wikipedia<br>
> article which speaks abstractly about pthreads, and #3 another tutorial on<br>
> using pthreads. I think I'm trying to figure out what to google for so \
that<br> > I can figure out where the problem lives and then look at it to see \
whether<br> > or not I can steal its lunch money.<br>
><br>
> Even if I google "linux pthreads" I still get a tutorial on using them \
as<br> > the top hit.<br>
><br>
> This is the most directly informative thing I can find:<br>
><br>
> <a href="http://man7.org/linux/man-pages/man7/pthreads.7.html" \
target="_blank">http://man7.org/linux/man-pages/man7/pthreads.7.html</a><br> ><br>
> Hopefully this explains anything I might have left out of my first message<br>
> on the subject!<br>
><br>
> Casey<br>
><br>
><br>
> On Wed, Apr 17, 2013 at 5:33 AM, David T. Lewis <<a \
href="mailto:lewis@mail.msen.com" target="_blank">lewis@mail.msen.com</a>> \
wrote:<br> ><br>
> ><br>
> > On Wed, Apr 17, 2013 at 01:15:45AM -0700, Casey Ransberger wrote:<br>
> > ><br>
> > > I'm assuming the problem is in the kernel, but making assumptions \
is<br> > > usually a bad plan, so I'm asking.<br>
> > ><br>
> > > When I look, I find a rather confusing jumble: pthreads exists in<br>
> > different implementations under different operating systems.<br>
> > ><br>
> > > I'd kind of like the heartbeat to work right under Raspbian, \
because<br> > > kids are going to use it, and the goal of producing better \
adults is pretty<br> > > close to my heart. See also making Squeak faster. \
(Stack VM.)<br> > > ><br>
> > > I want to arm myself with as much knowledge about this as \
possible,<br> > > because I'm considering just bloody fixing it. If the \
(GNU/Linux) community<br> > > has objections, and I'm able to pull off the \
fix, I can make a patch<br> > > available to people who want it.<br>
> > ><br>
> > > I'm not confident that I can fix the bug with the knowledge I have \
now,<br> > > but I'm confident that I can fix it eventually, if someone \
else doesn't<br> > > beat me to the punch.<br>
> > ><br>
> > > Outside of the wiki page, are there any documents/people/mailing lists \
I<br> > > should look at to be able to get a good handle on where in the kernel \
(or<br> > > elsewhere) I should be looking for the code which isn't meeting \
our<br> > > Cog-nitive requirements?<br>
> > ><br>
> ><br>
> > I do not understand what problem or bug you are asking about. Is there<br>
> > some issue with Raspbian Linux that is causing a problem?<br>
> ><br>
> > Dave<br>
> ><br>
<br>
</div></blockquote></div><br><br clear="all"><div><br></div>-- <br>Casey Ransberger
</div>
<br></blockquote></div><br><br clear="all"><div><br></div>-- \
<br>best,<div>Eliot</div> <br></blockquote></div><br><br \
clear="all"><div><br></div>-- <br>Casey Ransberger </div>
</blockquote></div><br></div><br></blockquote></div><br><br \
clear="all"><div><br></div>-- <br>best,<div>Eliot</div> </blockquote></div><br><div>
<span style="border-collapse:separate;border-spacing:0px;font-size:12px"><div \
style="font-family:Helvetica"><span style="font-family:Helvetica">- Bert \
-</span></div><br></span>
</div>
<br></div><br></blockquote></div><br><br clear="all"><div><br></div>-- \
<br>best,<div>Eliot</div> <br></blockquote></div><br><br \
clear="all"><div><br></div>-- <br>Casey Ransberger </div>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic