---------- Forwarded Message ----------
Subject: Re: [uml-devel] SIGSEGV and SA_NODEFER Date: Tuesday 25 January 2005 09:45 From: Gerd Knorr <[EMAIL PROTECTED]> To: Blaisorblade <[EMAIL PROTECTED]> > > 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