Re: Fwd: Re: [uml-devel] SIGSEGV and SA_NODEFER

Re: Fwd: Re: [uml-devel] SIGSEGV and SA_NODEFER

[Rob Landley]

On Tuesday 25 January 2005 05:15 am, Blaisorblade wrote:

> > > I'm using stdin/stdout as the console.  (And even though you put it
> > > into raw mode, I still can't ctrl-c out of the processs I'm running,
> > > either.)
>
> Hmm, ^C works perfectly fine for me.  Usually I work with a virtual
> serial line as console ("console=ttyS0 ssl0=fd:0,fd:1 con=pts"), works
> better than the uml console as applications don't expect the linux vt
> ioctls work on these devices ;)

Actually, if I thump on this one anytime soon I'll just make it _not_ go into 
raw mode, and let ctrl-c kill the UML vm.  Since I'm running running my 
script as init anyway, both have about the same effect.

(I should probably suppress the "panic: tried to kill init" if there's a clean 
way to do that, too...)

> I'm still at 2.6.10 + patches though, not yet at 2.6.11-rc2.
>
> > However, I'm not sure that patch is at fault... there is a locking
> > problem which *could* maybe be responsible of this...; I actually wonder
> > about why this locking problem has never shown up in reports or in
> > testing (it exists, only it's a race condition)... there is a situation
> > where it shows up with a side effect, indeed, so the problem exists...
>
> Heavy swapping (see other mail) and thus some stuff running _very_ slow
> might open such race windows wide enougth that one actually hits them.

Heh heh heh... :)

It's not actually a major slowdown that does it, though.  It's just the fairly 
standard half-second hiccup (well, standard for me) and then it blasts out 
all those repeats at once...

> The uml-terminal-cleanup patch doesn't touch how the uml terminal lines
> output (xterm, pty, ...) works, it's more the input side which has been
> reworked a bit, especially the console handling (console meaning the
> device the kernel sends the printk messages to, not the linux vt
> subsystem).

Dunno.  It's possible it happened under 2.6.9-bb4 and I just never saw it.  I 
have a to-do item to go back and check, but I also have work in four hours...

By the way, these aren't printk that's stuttering.  This is the output of my 
script, presumably going to /dev/console.

Rob


-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Fwd: Re: [uml-devel] SIGSEGV and SA_NODEFER

[Blaisorblade]

----------  Forwarded Message  ----------

Subject: Re: [uml-devel] SIGSEGV and SA_NODEFER
Date: Tuesday 25 January 2005 09:45
From: Gerd Knorr <kraxel@bytesex.org>
To: Blaisorblade <blaisorblade@yahoo.it>

> > binutils-2.14/ld/testsuite/ld-sparc/tlssunbin64.dd
> > binutils-2.14/ld/testsuite/ld-sparc/tlssunbin64.rd
> > binutils-2.14/ld/testsuite/lde/ld-/ld-sld-spd-spa-sparsparcparc/arc/trc/t
> >lc /tls/tlsstlssulssunssunbsunbiunbinnbin6bin64in64.n64.s64.s4.s.ss
> > binubinutinutinutilutilstils-ils-2ls-2.s-2.1-2.142.14/.14/l14/ld4/ld//ld/
> >tl
> > d/ted/tes/testtestsestsustsuitsuitsuiteuite/ite/lte/lde/ld-/ld-sld-spd-sp
> >a-s
> > parsparcparc/arc/trc/tlc/tls/tlsstlssulssunssunbsunbiunbinnbin6bin64in64.
> >n64 .s64.sd4.sd.sdsd binutils-2.14/ld/testsuite/ld-sparc/tlssunbin64.td
> > binutils-2.14/ld/testsuite/ld-sparc/tlssunbinpic32.s
> > binutils-2.14/ld/testsuite/ld-sparc/tlssunbinpic64.s
> > binutils-2.14/ld/testsuite/ld-sparc/tlssunnopic32.dd
> >
> > I had all that output piped to tee, which output it to out.txt, and the
> > corresponding line of out.txt isn't glitched, so it seems to just be a
> > cosmetic bug in the display code.  But I thought I'd report it anyway.
>
> Good thing, thanks...

I remember having seen a comment (and patch?) on one of the lists for
the tty line buffering, because of data loss in case the buffers are
full.  Don't remember the details but this could be related.

> > I'm using stdin/stdout as the console.  (And even though you put it
> > into raw mode, I still can't ctrl-c out of the processs I'm running,
> > either.)

Hmm, ^C works perfectly fine for me.  Usually I work with a virtual
serial line as console ("console=ttyS0 ssl0=fd:0,fd:1 con=pts"), works
better than the uml console as applications don't expect the linux vt
ioctls work on these devices ;)

I'm still at 2.6.10 + patches though, not yet at 2.6.11-rc2.

> However, I'm not sure that patch is at fault... there is a locking problem
> which *could* maybe be responsible of this...; I actually wonder about why
> this locking problem has never shown up in reports or in testing (it
> exists, only it's a race condition)... there is a situation where it shows
> up with a side effect, indeed, so the problem exists...

Heavy swapping (see other mail) and thus some stuff running _very_ slow
might open such race windows wide enougth that one actually hits them.

The uml-terminal-cleanup patch doesn't touch how the uml terminal lines
output (xterm, pty, ...) works, it's more the input side which has been
reworked a bit, especially the console handling (console meaning the
device the kernel sends the printk messages to, not the linux vt
subsystem).

  Gerd

--
#define printk(args...) fprintf(stderr, ## args)

-------------------------------------------------------

-- 
Paolo Giarrusso, aka Blaisorblade
Linux registered user n. 292729
http://www.user-mode-linux.org/~blaisorblade


-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel