Re: csh Cannot open /etc/termcap after starting "screen"
On Sat, Jun 18, 2011 at 11:37:07PM +0300, Kostik Belousov wrote: > On Sat, Jun 18, 2011 at 10:14:32PM +0200, Stefan `Sec` Zehl wrote: > > Hi, > > > > On Thu, Jun 16, 2011 at 13:15 -0700, Jeremy Chadwick wrote: > > > Example: run mutt from within GNU screen while connected to > > > the system with PuTTY, then copy some of the terminal content and paste > > > it somewhere. Wow, look at all those extraneous spaces at the end of > > > lines, which you now gloriously have to manually remove. > > > > While I don't want to stand in the way of your rant, this is actually a > > bug/problem of mutt. -- mutt is really printing spaces there, so it is > > (IMHO) correct that copy&paste copies spaces. > > It is the case of the default termcap entry for the screen. > Try "TERM=screen-bce mutt". Which is in no way acceptable given these kinds of visual results: http://www.malkavian.com/~jdc/mutt-screen-bce.png Though what comes across stdout is a lot more reasonable (no padding): 35745 mutt GIO fd 1 wrote 340 bytes 0x 0d1b 5b33 376d 1b5b 4a1b 5b48 1b5b 3337 6d1b 5b34 346d 1b5b 316d 2d2d 2d4d 7574 |..[37m.[J.[H.[37m.[44m.[1m---Mut| 0x0020 743a 203d 7370 616d 205b 4d73 6773 3a31 204e 6577 3a31 2032 2e38 4b5d 2d2d 2d28 |t: =spam [Msgs:1 New:1 2.8K]---(| 0x0040 7468 7265 6164 732f 6461 7465 292d 2d2d 2d2d 2d2d 2d2d 2d2d 2d2d 2d2d 2d2d 2d2d |threads/date)---| 0x0060 2d2d 2d2d 2d2d 2d2d 2d2d 2d2d 2d2d 2d2d 2d2d 2d2d 2d2d 2d2d 2d2d 2d2d 2d2d 2d2d || 0x0080 2d2d 2d2d 2d2d 2d2d 2d2d 2d2d 2d2d 2d2d 2d2d 2d2d 2d2d 2861 6c6c 292d 2d2d 1b5b |--(all)---.[| 0x00a0 323b 3148 1b5b 3337 6d1b 5b34 366d 2020 2031 204e 202b 2030 362f 3138 2031 363a |2;1H.[37m.[46m 1 N + 06/18 16:| 0x00c0 3436 2020 4f72 6465 7220 4e6f 7469 6669 6572 2020 2020 2020 2830 2e34 4b29 205b |46 Order Notifier (0.4K) [| 0x00e0 7370 616d 5d20 4865 6c6c 6f1b 5b4b 0d1b 5b34 3042 1b5b 3337 6d1b 5b34 346d 713a |spam] Hello.[K..[40B.[37m.[44mq:| 0x0100 5175 6974 2020 643a 4465 6c20 2075 3a55 6e64 656c 2020 733a 5361 7665 2020 6d3a |Quit d:Del u:Undel s:Save m:| 0x0120 4d61 696c 2020 723a 5265 706c 7920 2067 3a47 726f 7570 2020 3f3a 4865 6c70 1b5b |Mail r:Reply g:Group ?:Help.[| 0x0140 4b1b 5b32 3b31 3332 481b 5b33 393b 3439 6d1b 5b6d |K.[2;132H.[39;49m.[m| So what happens if one puts "defbce on" in .screenrc and uses TERM=screen-bce? Padded spaces: 35849 mutt GIO fd 1 wrote 495 bytes 0x 1b5b 481b 5b33 376d 1b5b 3434 6d1b 5b31 6d2d 2d2d 4d75 7474 3a20 3d73 7061 6d20 |.[H.[37m.[44m.[1m---Mutt: =spam | 0x0020 5b4d 7367 733a 3120 4e65 773a 3120 496e 633a 3120 322e 384b 5d2d 2d2d 2874 6872 |[Msgs:1 New:1 Inc:1 2.8K]---(thr| 0x0040 6561 6473 2f64 6174 6529 2d2d 2d2d 2d2d 2d2d 2d2d 2d2d 2d2d 2d2d 2d2d 2d2d 2d2d |eads/date)--| 0x0060 2d2d 2d2d 2d2d 2d2d 2d2d 2d2d 2d2d 2d2d 2d2d 2d2d 2d2d 2d2d 2d2d 2d2d 2d2d 2d2d || 0x0080 2d2d 2d2d 2d2d 2d2d 2d2d 2d2d 2d28 616c 6c29 2d2d 2d1b 5b32 3b31 481b 5b33 376d |-(all)---.[2;1H.[37m| 0x00a0 1b5b 3436 6d20 2020 3120 4e20 2b20 3036 2f31 3820 3136 3a34 3620 204f 7264 6572 |.[46m 1 N + 06/18 16:46 Order| 0x00c0 204e 6f74 6966 6965 7220 2020 2020 2028 302e 344b 2920 5b73 7061 6d5d 2048 656c | Notifier (0.4K) [spam] Hel| 0x00e0 6c6f 2020 2020 2020 2020 2020 2020 2020 2020 2020 2020 2020 2020 2020 2020 2020 |lo | 0x0100 2020 2020 2020 2020 2020 2020 2020 2020 2020 2020 2020 2020 2020 2020 2020 2020 || 0x0120 2020 2020 2020 2020 201b 5b34 323b 3148 1b5b 3337 6d1b 5b34 346d 713a 5175 6974 | .[42;1H.[37m.[44mq:Quit| 0x0140 2020 643a 4465 6c20 2075 3a55 6e64 656c 2020 733a 5361 7665 2020 6d3a 4d61 696c | d:Del u:Undel s:Save m:Mail| 0x0160 2020 723a 5265 706c 7920 2067 3a47 726f 7570 2020 3f3a 4865 6c70 2020 2020 2020 | r:Reply g:Group ?:Help | 0x0180 2020 2020 2020 2020 2020 2020 2020 2020 2020 2020 2020 2020 2020 2020 2020 2020 || 0x01a0 2020 2020 2020 2020 2020 2020 2020 2020 2020 2020 2020 2020 2020 2020 2020 1b5b | .[| 0x01c0 3433 3b31 481b 5b6d 1b5b 3337 6d20 2020 2020 2020 2020 2020 2020 2020 2020 201b |43;1H.[m.[37m .| 0x01e0 5b32 3b31 3332 481b 5b33 396d 1b5b 6d |[2;132H.[39m.[m| -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | _
Re: csh Cannot open /etc/termcap after starting "screen"
On Sat, Jun 18, 2011 at 10:14:32PM +0200, Stefan `Sec` Zehl wrote: > Hi, > > On Thu, Jun 16, 2011 at 13:15 -0700, Jeremy Chadwick wrote: > > Example: run mutt from within GNU screen while connected to > > the system with PuTTY, then copy some of the terminal content and paste > > it somewhere. Wow, look at all those extraneous spaces at the end of > > lines, which you now gloriously have to manually remove. > > While I don't want to stand in the way of your rant, this is actually a > bug/problem of mutt. -- mutt is really printing spaces there, so it is > (IMHO) correct that copy&paste copies spaces. mutt is not printing spaces. GNU screen is doing it, and I'm going to show you hard evidence of it. I've done this analysis many times over the years, so doing it once again won't hurt. It never ceases to amaze me how GNU screen advocates "insist it's a problem with " when that simply isn't the case. Let's take a look at *exactly* what mutt is sending to stdout (fd 1) in a terminal that's 132x43 in size, using TERM=xterm, thus without GNU screen. PuTTY is my terminal emulator. We're looking at the I/O that comes across fd 1 (stdout) from mutt. mutt on this system is build with ncurses (base system version, not ports) The test procedure: ktrace -ti /usr/local/bin/mutt -f =spam kdump | less Firstly, a screen shot of what shows up in PuTTY, just so you have some visual context: http://www.malkavian.com/~jdc/mutt.png And across stdout, here's what we see: 29053 mutt GIO fd 1 wrote 340 bytes 0x 0d1b 5b33 376d 1b5b 4a1b 5b48 1b5b 3337 6d1b 5b34 346d 1b5b 316d 2d2d 2d4d 7574 |..[37m.[J.[H.[37m.[44m.[1m---Mut| 0x0020 743a 203d 7370 616d 205b 4d73 6773 3a31 204e 6577 3a31 2049 6e63 3a33 2032 2e38 |t: =spam [Msgs:1 New:1 Inc:3 2.8| 0x0040 4b5d 2d2d 2d28 7468 7265 6164 732f 6461 7465 292d 2d2d 2d2d 2d2d 2d2d 2d2d 2d2d |K]---(threads/date)-| 0x0060 2d2d 2d2d 2d2d 2d2d 2d2d 2d2d 2d2d 2d2d 2d2d 2d2d 2d2d 2d2d 2d2d 2d2d 2d2d 2d2d || 0x0080 2d2d 2d2d 2d2d 2d2d 2d2d 2d2d 2d2d 2d2d 2d2d 2d2d 2d2d 2861 6c6c 292d 2d2d 1b5b |--(all)---.[| 0x00a0 323b 3148 1b5b 3337 6d1b 5b34 366d 2020 2031 204e 202b 2030 362f 3138 2031 363a |2;1H.[37m.[46m 1 N + 06/18 16:| 0x00c0 3436 2020 4f72 6465 7220 4e6f 7469 6669 6572 2020 2020 2020 2830 2e34 4b29 205b |46 Order Notifier (0.4K) [| 0x00e0 7370 616d 5d20 4865 6c6c 6f1b 5b4b 0d1b 5b34 3042 1b5b 3337 6d1b 5b34 346d 713a |spam] Hello.[K..[40B.[37m.[44mq:| 0x0100 5175 6974 2020 643a 4465 6c20 2075 3a55 6e64 656c 2020 733a 5361 7665 2020 6d3a |Quit d:Del u:Undel s:Save m:| 0x0120 4d61 696c 2020 723a 5265 706c 7920 2067 3a47 726f 7570 2020 3f3a 4865 6c70 1b5b |Mail r:Reply g:Group ?:Help.[| 0x0140 4b1b 5b32 3b31 3332 481b 5b33 393b 3439 6d1b 5b6d |K.[2;132H.[39;49m.[m| Here's the xterm escape sequence decoding chart -- we'll be caring about [ a lot, which is referred to as "CSI" in the docs. http://invisible-island.net/xterm/ctlseqs/ctlseqs.html Let's decode the above output and turn it into something human-readable: [37m = set foreground text colour to white [J = clear from cursor to end of terminal [H = move cursor to top left corner of terminal [37m = set foreground text colour to white [44m = set background colour to blue [1m = turn on bold/bright ---Mutt: =spam [Msgs:1 New:1 Inc:3 2.8K]---(threads/date)---(all)--- [2;1H= move cursor to row 2 column 1 [37m = set foreground text colour to white [46m = set background colour to cyan 1 N + 06/18 16:46 Order Notifier (0.4K) [spam] Hello [K = erase from cursor position to end of line [40B = move cursor 40 lines downward [37m = set foreground text colour to white [44m = set background colour to blue q:Quit d:Del u:Undel s:Save m:Mail r:Reply g:Group ?:Help [K = erase from cursor position to end of line [2;132H = move cursor to row 2, column 132 [39;49m = set foreground text colour and background to default [m = turn off bold/bright Given this analysis, we can see where GNU screen is making some stupid assumptions. Let's focus on the part that's causing the nonsense: 1 N + 06/18 16:46 Order Notifier (0.4K) [spam] Hello ^ cursor is now here ^ This is followed by [K, which is used to erase all content from the cursor position to the end of the line. "Erase all content" does not mean "print spaces" -- you can see quite clearly in the I/O to stdout that no "padding spaces" are printed. It's a terminal escape sequence which is interpreted by xterm (PuTTY in my case) to do what it's told. It's important to note that the foreground colo
Re: csh Cannot open /etc/termcap after starting "screen"
On Sat, Jun 18, 2011 at 10:14:32PM +0200, Stefan `Sec` Zehl wrote: > Hi, > > On Thu, Jun 16, 2011 at 13:15 -0700, Jeremy Chadwick wrote: > > Example: run mutt from within GNU screen while connected to > > the system with PuTTY, then copy some of the terminal content and paste > > it somewhere. Wow, look at all those extraneous spaces at the end of > > lines, which you now gloriously have to manually remove. > > While I don't want to stand in the way of your rant, this is actually a > bug/problem of mutt. -- mutt is really printing spaces there, so it is > (IMHO) correct that copy&paste copies spaces. It is the case of the default termcap entry for the screen. Try "TERM=screen-bce mutt". pgpVDFesl77jN.pgp Description: PGP signature
Re: csh Cannot open /etc/termcap after starting "screen"
Hi, On Thu, Jun 16, 2011 at 13:15 -0700, Jeremy Chadwick wrote: > Example: run mutt from within GNU screen while connected to > the system with PuTTY, then copy some of the terminal content and paste > it somewhere. Wow, look at all those extraneous spaces at the end of > lines, which you now gloriously have to manually remove. While I don't want to stand in the way of your rant, this is actually a bug/problem of mutt. -- mutt is really printing spaces there, so it is (IMHO) correct that copy&paste copies spaces. CU, Sec (using screen since 1994) -- | Kevin Dalley on Melissa being Open Source: While the Melissa license is a bit unclear, Melissa aggressively encourages free distribution of its source code. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Crashes with Promise controller
On Sat, Jun 18, 2011 at 06:49:41PM +0200, Stefan Bethke wrote:
> Am 13.06.2011 um 16:22 schrieb Christian Baer:
>
> > I have to slightly explain the word "crash" here: I don't actually have
> > to hard reset the system myself. My box just does a reboot by itself. No
> > filesystem is unmounted cleanly and because the machine isn't really new
> > and powerful fsck takes pretty long.
>
> I can't help you with your controllers, but anyone in a position to
> help will likely want to know if the box simply resets, or if the
> kernel panics. And if there are going to be any patches, you most
> certainly will want to get familiar with the debugger to help try
> stuff out. The handbook has information on how to enable crash dumps
> and getting the kernel debugger going. If you haven't done so
> already, try and get a serial console going, it helps tremendously to
> be able to cut&paste debugger info instead of trying to hand
> transcribe it.
It may be that the kernel is panic'ing and auto-rebooting before he can
see the message in question. I would advocate he put the following
directives in his kernel configuration and rebuild/reinstall kernel and
wait for it to happen again.
# Debugging options
options KDB # Enable kernel debugger support
options KDB_TRACE # Print stack trace automatically on
panic
options DDB # Support DDB
options GDB # Support remote GDB
If after doing this the machine literally reboots rather than panics,
then that would indicate a mainboard having issues, or power-related
stuff (keep reading).
As for the behaviour he describes -- this sort of problem can sometimes
turn out to be PSU-load-related (too many drives on a PSU that can't
handle it on a single rail), bad/improper voltages (difficult to track
down given the state of hardware monitoring on mainboards and on
FreeBSD), or "dirty power" / excessive ripple. Power-related problems
on computers almost always appear as random/abrupt situations that can
usually be exacerbated by heavy system utilisation. I have no proof
this is Christian's problem, but it's worth considering anyway.
One might be able to detect ("log") potential power loss by looking at
SMART attribute 12 on mechanical HDDs in the system; if the RAW_VALUE
increases after it happens, then power is being lost to the drives. If
not, then it may be a soft reset. I use the word "may" because
sometimes a very quick brown-out won't cause the drives to actually
"power down" fully (e.g. the attribute never gets incremented) but the
loss of power can be just enough to cause them to start freaking out.
Computers + power issues = expect random chaos.
--
| Jeremy Chadwickjdc at parodius.com |
| Parodius Networking http://www.parodius.com/ |
| UNIX Systems Administrator Mountain View, CA, US |
| Making life hard for others since 1977. PGP 4BD6C0CB |
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Crashes with Promise controller
Am 13.06.2011 um 16:22 schrieb Christian Baer: > I have to slightly explain the word "crash" here: I don't actually have > to hard reset the system myself. My box just does a reboot by itself. No > filesystem is unmounted cleanly and because the machine isn't really new > and powerful fsck takes pretty long. I can't help you with your controllers, but anyone in a position to help will likely want to know if the box simply resets, or if the kernel panics. And if there are going to be any patches, you most certainly will want to get familiar with the debugger to help try stuff out. The handbook has information on how to enable crash dumps and getting the kernel debugger going. If you haven't done so already, try and get a serial console going, it helps tremendously to be able to cut&paste debugger info instead of trying to hand transcribe it. HTH, Stefan -- Stefan BethkeFon +49 151 14070811 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: BTX loader problem on specific hardware
On 06/17/11 18:01, John Baldwin wrote: I'm not sure, but maybe rdmsr or wrmsr are generating exceptions which are not managed by BTX? I could be wrong, I really dont' know that much about the internals of CPUs. Well, the old BTX didn't allow full access to CR registers. Running in real mode, there should be no problems with any MSR accesses though in the new BTX. I thought that, but I could not identify any other big diffs from the other BIOS I had a look at. I obviously have the disassembled code available, but not posting it here because I'm not sure what policies there are about disassembled code on the lists. You can post a URL perhaps (or just send it to me directly if you wish). http://www.madpilot.net/HP6005Pro/ I put there a disassembled.txt with the relevant parts disassembled and put in some kind of order(you'll anyway need to jump a round a little, could not make it any better). There's a small comment identifying the critical area. I put there a dump of the full BIOS and the IDT, just in case. Thank you again! -- Guido Falsi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
