On May 27, 2014, at 6:08 AM, Anthony Sorace wrote:
> I believe 'mk all' in /sys/src/9/ will still do this.
So there is. (And 'installall'.) Sorry for not seeing this :-P
signature.asc
Description: Message signed with OpenPGP using GPGMail
On May 26, 2014, at 11:57 PM, lu...@proxima.alt.za wrote:
> I was more frequent when there was a duplicate entry in
> /lib/ndb/kestell (happens to be the description of my local network),
> it's improved since I fixed that. There may still be some trouble in
> the database, but I could not spot
> I recall there used to me a mk target that would rebuild all the kernel
> configs. I.e. everything in CONFLIST. It would be nice if that came back.
I believe 'mk all' in /sys/src/9/ will still do this.
signature.asc
Description: Message signed with OpenPGP using GPGMail
On Mon May 26 19:16:22 EDT 2014, lyn...@orthanc.ca wrote:
> For the last couple of days I have been plagued by many many diagnostics from
> checkpages(), in conjunction with things like:
>
> rc: note: sys: trap: fault read addr=0x0 pc=0x000101c4
> rc 50675: suicide: sys: trap: fault read add
On 27 May 2014 00:41, Steve Simon wrote:
> its not the lack of he new
> nsec() systemcall biteing you is it?
>
that wouldn't lead to checkpages faults, which appear when processes trap
on bad addresses.
i'd suspect an inconsistency between the source (eg, paging or lock data
structures) and exis
> The dns failures occur this side too, once, sometimes a few times a
> day.
I was more frequent when there was a duplicate entry in
/lib/ndb/kestell (happens to be the description of my local network),
it's improved since I fixed that. There may still be some trouble in
the database, but I could
> Is anyone else seeing this? I'm running bleeding edge labs code,
> compiled from a pull from this afternoon. (And I have been running
> very up-to-date labs pulls all the way along.)
The dns failures occur this side too, once, sometimes a few times a
day. The responsible party is the auth/cpu
On May 26, 2014, at 4:47 PM, Steve Simon wrote:
> Just thought I would ask, 9pccpuf is not built by the labs
> so you would need to rebuild it by hand.
It's not rebuilt, which is a shame, since I'm pretty sure this must be the
kernel they run on their file servers.
If not, I would really like
Ok,
Just thought I would ask, 9pccpuf is not built by the labs
so you would need to rebuild it by hand.
worth a try.
-Steve
On May 26, 2014, at 4:41 PM, Steve Simon wrote:
> I have to ask, when you rebuilt everything, you did rebuild
> 9pccpuf as well didn't you? i.e. its not the lack of he new
> nsec() systemcall biteing you is it?
No, I carefully did the Macarena around that mess ;-)
--lyndon
signature.asc
Des
I have to ask, when you rebuilt everything, you did rebuild
9pccpuf as well didn't you? i.e. its not the lack of he new
nsec() systemcall biteing you is it?
-Steve
For the last couple of days I have been plagued by many many diagnostics from
checkpages(), in conjunction with things like:
rc: note: sys: trap: fault read addr=0x0 pc=0x000101c4
rc 50675: suicide: sys: trap: fault read addr=0x0 pc=0x000101c4
The kernel print buffer holds corresponding entr
12 matches
Mail list logo
