On Monday 20 December 2010 05:31:55 Joerg Sonnenberger wrote:
> Hi all,
> unless there are objections, I am going to commit the attached patch
> soon. It replaces the use of stabs for WARN_REFERENCES in assembler code
> with the modernish .gnu.warning sections. Platforms that already used
> this no
On Mon, Dec 20, 2010 at 08:48:45AM +, Nick Hudson wrote:
> On Monday 20 December 2010 05:31:55 Joerg Sonnenberger wrote:
> > Hi all,
> > unless there are objections, I am going to commit the attached patch
> > soon. It replaces the use of stabs for WARN_REFERENCES in assembler code
> > with the
On Monday 20 December 2010 10:31:01 Joerg Sonnenberger wrote:
> On Mon, Dec 20, 2010 at 08:48:45AM +, Nick Hudson wrote:
> > On Monday 20 December 2010 05:31:55 Joerg Sonnenberger wrote:
> > > Hi all,
> > > unless there are objections, I am going to commit the attached patch
> > > soon. It repl
On Mon, Dec 20, 2010 at 06:31:55AM +0100, Joerg Sonnenberger wrote:
> unless there are objections, I am going to commit the attached patch
> soon. It replaces the use of stabs for WARN_REFERENCES in assembler code
> with the modernish .gnu.warning sections. Platforms that already used
> this now co
On Mon, Dec 20, 2010 at 11:01:27AM +, Nick Hudson wrote:
> On Monday 20 December 2010 10:31:01 Joerg Sonnenberger wrote:
> > On Mon, Dec 20, 2010 at 08:48:45AM +, Nick Hudson wrote:
> > > On Monday 20 December 2010 05:31:55 Joerg Sonnenberger wrote:
> > > > Hi all,
> > > > unless there are
On Mon, Dec 20, 2010 at 07:43:38AM -0500, Allen Briggs wrote:
> On Mon, Dec 20, 2010 at 06:31:55AM +0100, Joerg Sonnenberger wrote:
> > unless there are objections, I am going to commit the attached patch
> > soon. It replaces the use of stabs for WARN_REFERENCES in assembler code
> > with the mode
On Sun, 19 Dec 2010 23:41:11 + (UTC),
Eduardo Horvath wrote:
> Looks reasonable. You should definitely add a comment somewhere
> indicating the uino is protected by the lfs_lock. Locking protocols must
> be documented or they are guaranteed to be broken. Have you tested it
> under load?
On Tue, 21 Dec 2010, NAKAJIMA Yoshihiro wrote:
> On Sun, 19 Dec 2010 23:41:11 + (UTC),
> Eduardo Horvath wrote:
>
> > Looks reasonable. You should definitely add a comment somewhere
> > indicating the uino is protected by the lfs_lock. Locking protocols must
> > be documented or they are
On Mon, Dec 20, 2010 at 07:43:38AM -0500, Allen Briggs wrote:
>
> Should these be conditional on tools that understand .gnu.warning, or
> are we assuming that if we use alternative tools, they should understand
> .gnu.warning? Or does it not matter?
At a guess the unknown section will be treated
On Sun, Dec 19, 2010 at 04:50:39PM -0500, Greg Troxel wrote:
>
> Manuel Bouyer writes:
>
> > Well, in the current state, modules are a not enabled in the Xen kernels
> > (modules should be built specifically for Xen, but the build tools do not
> > allow this right now). So you have to compile al
There's a deadly embrace between watchdogs and cngetc. While cngetc is looping
at splserial, callouts are blocked, let alone letting user processes run.
So if you are stuck at the ddb prompt, eventually the watchdog will fire
because you didn't type fast enough.
I've added a new class of hook
On Dec,Monday 20 2010, at 8:46 PM, Manuel Bouyer wrote:
> On Sun, Dec 19, 2010 at 04:50:39PM -0500, Greg Troxel wrote:
>>
>> Manuel Bouyer writes:
>>
>>> Well, in the current state, modules are a not enabled in the Xen kernels
>>> (modules should be built specifically for Xen, but the build to
On 20.12.2010 22:58, Adam Hamsik wrote:
>
> On Dec,Monday 20 2010, at 8:46 PM, Manuel Bouyer wrote:
>
>> On Sun, Dec 19, 2010 at 04:50:39PM -0500, Greg Troxel wrote:
>>>
>>> Manuel Bouyer writes:
>>>
Well, in the current state, modules are a not enabled in the Xen kernels
(modules shou
On Mon, 20 Dec 2010, Matt Thomas wrote:
> There's a deadly embrace between watchdogs and cngetc. While cngetc is
> looping at splserial, callouts are blocked, let alone letting user processes
> run.
>
> So if you are stuck at the ddb prompt, eventually the watchdog will fire
> because you did
On Dec 20, 2010, at 4:34 PM, Eduardo Horvath wrote:
> On Mon, 20 Dec 2010, Matt Thomas wrote:
>
>> There's a deadly embrace between watchdogs and cngetc. While cngetc is
>> looping at splserial, callouts are blocked, let alone letting user processes
>> run.
>>
>> So if you are stuck at the d
Guys,
There are two ports, sh3 and mips, which define PROC_PC() macro in
cpu.h. They look both wrong and un-compileable indeed. It's apparent
they are a sort of leftovers never used so far. Is it ok to remove the
#define from cpu.h and the usage in kern/kern_clock.c?
Toru Nishimura / ALKYL Te
16 matches
Mail list logo
