On Friday 14 July 2006 21:51, Samuel Korpi wrote:
> On 7/14/06, Jeff Dike <[EMAIL PROTECTED]> wrote:
> > On Fri, Jul 14, 2006 at 08:19:16AM +0300, Samuel Korpi wrote:
> > > Attached.
> >
> > Try the patch below. It also fixes a bunch of other arch declarations,
> > one of which faked me into an in
On Fri, Jul 14, 2006 at 08:59:10PM +0200, Blaisorblade wrote:
> Sorry, since when does the udelay interface means "cycles to wait"? It's very
> strange... and the i386 prototype is very likely correct...
The i386 prototype is
extern void __const_udelay(unsigned long usecs);
while the imp
On 7/14/06, Jeff Dike <[EMAIL PROTECTED]> wrote:
> On Fri, Jul 14, 2006 at 08:19:16AM +0300, Samuel Korpi wrote:
> > Attached.
>
> Try the patch below. It also fixes a bunch of other arch declarations, one
> of which faked me into an incorrect implementation of __const_udelay.
>
Thanks. I'll try i
On Friday 14 July 2006 19:58, Jeff Dike wrote:
> On Fri, Jul 14, 2006 at 08:19:16AM +0300, Samuel Korpi wrote:
> > Attached.
>
> Try the patch below. It also fixes a bunch of other arch declarations, one
> of which faked me into an incorrect implementation of __const_udelay.
Sorry, since when does
On Fri, Jul 14, 2006 at 08:19:16AM +0300, Samuel Korpi wrote:
> Attached.
Try the patch below. It also fixes a bunch of other arch declarations, one
of which faked me into an incorrect implementation of __const_udelay.
Jeff
Index: linux-2.6.17/include/asm-i386/de
On 7/13/06, Jeff Dike <[EMAIL PROTECTED]> wrote:
On Mon, Jul 10, 2006 at 02:38:07AM -0400, Samuel Korpi wrote:
> > It's a bug, regardless. Can you attach gdb to it and get a stacktrace?
> >
>
> Stacktrace shows this:
>
> (gdb) bt
> #0 0x60140149 in __const_udelay (usecs=26734100480)
On Mon, Jul 10, 2006 at 02:38:07AM -0400, Samuel Korpi wrote:
> > It's a bug, regardless. Can you attach gdb to it and get a stacktrace?
> >
>
> Stacktrace shows this:
>
> (gdb) bt
> #0 0x60140149 in __const_udelay (usecs=26734100480)
> at arch/um/sys-x86_64/delay.c:37
> #1 0x0
--- On Fri 07/07, Jeff Dike < [EMAIL PROTECTED] > wrote:
>On Fri, Jul 07, 2006 at 04:02:42AM -0400, Samuel Korpi wrote:
>> Now when I get the message when trying to halt the uml, it just freezes with
>> processor running at 100%. I only can get out of this by ending gdb and
>> running 'ki
On Fri, Jul 07, 2006 at 09:39:09AM +0200, Jan Rychter wrote:
> FWIW, I get lots of these when I suspend my laptop with UML guests
> running.
This is essentially the same thing. UML went for more than 10 seconds
without a timer interrupt when your laptop was suspended, and the soft
lockup code got
On Fri, Jul 07, 2006 at 04:02:42AM -0400, Samuel Korpi wrote:
> Now when I get the message when trying to halt the
> uml, it just freezes with processor running at 100%. I only can get
> out of this by ending gdb and running 'killall linux'. This didn't
> happen at first, only after I recompiled th
--- On Thu 07/06, Jeff Dike < [EMAIL PROTECTED] > wrote:
>> [42949518.22] BUG: soft lockup detected on CPU#0!
> This isn't a crash, exactly - it's the timer complaining that ithasn't been
> called in 10 seconds, which will happen if you have itstopped in gdb.
>
Tr
> "Jeff" == Jeff Dike <[EMAIL PROTECTED]> writes:
Jeff> On Thu, Jul 06, 2006 at 08:45:34AM -0400, Samuel Korpi wrote:
[...]
>> [42949518.22] BUG: soft lockup detected on CPU#0!
Jeff> This isn't a crash, exactly - it's the timer complaining that it
Jeff> hasn't been called in 10 secon
On Thu, Jul 06, 2006 at 08:45:34AM -0400, Samuel Korpi wrote:
> Apparently my mistake. I run UML with gdb and it seems 'killall
> linux' was not enough to kill the UML processes while gdb was still
> running.
You can't kill a process out from under gdb. It will die when gdb
detaches or continues
Sorry,
Apparently my mistake. I run UML with gdb and it seems 'killall linux' was not
enough to kill the UML processes while gdb was still running.
But an interesting question is, why does the crash even occur - and just when
the system has been almost halted? Below is part of the output I
14 matches
Mail list logo
