similar to: tty (serial) patch update

> From: Abhijit Dasgupta <adasgupta@araastat.com> > Date: October 31, 2010 1:30:02 AM EDT > To: Matt Shotwell <shotwelm@musc.edu> > Subject: Re: [R] ForestPlot or similar > > I just did something very similar using ggplot's pointrange geom. In the following, I'm plotting hazard ratios, for which the nominal value is 1 and not 0. x has 5 columns: drug, hr,

Hello, I would like to compress a long string (character vector), store the compressed string in the text field of a SQLite database (using RSQLite), and then load the text back into memory and decompress it back into the the original string. My character vector can be compressed considerably using standard gzip/bzip2 compression. In theory it should be much faster for me to compress/decompress

Hi, my physical machine (Dell PE2650) has two serial ports, the /proc/tty/driver/serial output looks like this under a non-XEN Linux kernel: serinfo:1.0 driver revision: 0: uart:16550A port:000003F8 irq:4 tx:2761 rx:2766 CTS|CD|RI 1: uart:NS16550A port:000002F8 irq:3 tx:58353 rx:2986 RTS|CTS|DTR|DSR|CD|RI 2: uart:16550A port:0000EC80 irq:177 tx:0 rx:0 CTS|DSR|CD 3: uart:unknown port:000002E8

We are in the process of migrating one of our embedded apps to use uart by default instead of sio in RELENG_7 in prep for the day when sio eventually disappears. Unfortunately, the application doesnt want to work with uart with puc backed devices, but still works with sio. Stranger still, the app works with the uart driver when uart attaches to the built in com port on the isa bus. However,

R community, As you may know, R's iconv doesn't work well converting to and from encodings that allow embedded nulls. For example > iconv("foo", to="UTF-16") Error in iconv("foo", to = "UTF-16") : embedded nul in string: '\xff\xfef\0o\0o\0' However, I don't believe embedded nulls are at issue here, but rather that R's iconv

This command fails with an incorrect error message: $ nbdkit ssh host=localhost /nosuchfile password=- --run 'qemu-img info $nbd' </dev/null password: nbdkit: error: could not read password from stdin: Inappropriate ioctl for device The error (ENOTTY Inappropriate ioctl for device) is actually a leftover errno from the previous isatty call. This happens because getline(3) can

CentOS-6.2 We have a dedicated CentOS-5.7 host used for fax reception and transmission that we wish to move to a CentOS-6.2 virtual guest instance. The CentOS-6.2 virtual host has a 4-port serial card installed. lspci -v tshows this this: 03:00.0 Serial controller: Oxford Semiconductor Ltd OX16PCI954 (Quad 16950 UART) function 0 (Uart) (prog-if 06 [16950]) Subsystem: Oxford

I have gotten scattered reports of strange problems caused by the fact that virtio_console doesn't behave like a normal tty (support termios and so on.) This seems to be an odd restriction -- is there any fundamental reason for this design choice? -hpa

I have gotten scattered reports of strange problems caused by the fact that virtio_console doesn't behave like a normal tty (support termios and so on.) This seems to be an odd restriction -- is there any fundamental reason for this design choice? -hpa

The vm host shows this: # setserial -g /dev/ttyS* /dev/ttyS0, UART: 16550A, Port: 0x03f8, IRQ: 4 /dev/ttyS1, UART: 16950/954, Port: 0xd040, IRQ: 17 /dev/ttyS2, UART: 16950/954, Port: 0xd048, IRQ: 17 /dev/ttyS3, UART: 16950/954, Port: 0xd050, IRQ: 17 # # ll /dev/ttyS* crw-rw----. 1 root dialout 4, 64 Nov 10 12:18 /dev/ttyS0 crw-rw----. 1 root dialout 4, 65 Nov 10 12:18 /dev/ttyS1 crw-rw----. 1

On Mon, Jan 29, 2018 at 07:00:02AM -0500, Pete Geenhuizen wrote: > > > On 01/28/18 20:15, Fred Smith wrote: > >On Sun, Jan 28, 2018 at 12:10:29PM -0500, Pete Geenhuizen wrote: > >>I'm upgrading from CentOS6 to CentOS 7. > >> > >>I run 2 weather stations on C6 and have one of them attached to > >>ttyS0 which is on the motherboard, and the

I have installed two 4-port serial cards (http://www.startech.com/ Product/ItemDetail.aspx?productid=PCI4S550&c=US) on a CentOS 4.4 system. The hardware appears to be recognized correctly, as kudzu added 2 entries to /etc/sysconfig/hwconf and lscpi shows both cards (output of lspci -vv for both cards included at the end of this email): # lspci 00:00.0 Host bridge: Intel Corporation

We have upgraded a box from 6.2 to 6.3-RELEASE. Afterwards the box does not recognize its ST Lab I-160 serial card with Netmos 9845 Chipset. It worked flawlessly on 6.2 with puc(4) driver. >From dmesg: pci1: <simple comms, UART> at device 8.0 (no driver attached) ~# pciconf -l -v | grep -B 4 UART none2@pci1:8:0: class=0x070002 card=0x00041000 chip=0x98459710 rev=0x01 hdr=0x00

On 01/28/18 20:15, Fred Smith wrote: > On Sun, Jan 28, 2018 at 12:10:29PM -0500, Pete Geenhuizen wrote: >> I'm upgrading from CentOS6 to CentOS 7. >> >> I run 2 weather stations on C6 and have one of them attached to >> ttyS0 which is on the motherboard, and the other to ttyS2 which in >> on an add-on PCI serial card. >> >> I'm migrating the

guys, A bit off topic here, but since this issue already has a history here: serial connection to the SCD, the never ending story ... - the intel D945GSEJT mainboard (ICH7) has two serial ports with onboard connectors which require a ribon cable to the external DB9 connectors in the case. I tested 5 cables, but none works. whereas I'm not sure if it is a cable problem. this is what dmesg

Folks, First, let me thank everyone involved for making QEMU available on the Solaris platform. It''s turning out to be really handy.... Here at work we''re required to use GroupWise calendaring (at least for the time being), and I''m trying to get a bit more organized, so thought I''d start (again) using a Palm handheld to take my calendar, etc. with me. The new

> From: "James Bean" <james@hdcs.com.au> > Has anyone every setup an external open/close relay, off say a serial > interface, and have an extension trigger the relay? The following will do the trick. Just add a 5vdc solid state relay ('cause you can't sink too much current out of the RS232C port). Substitute "2", "4" or "6" in the

Hello, openssh-3.0.1p1 appears to transmit and parse tty modes correctly, but later in the code it uses vhangup() to close all tty references and reset the tty to default modes. I don't think that vhangup() should be needed on Unix98 ptys, possibly not even on BSD ptys, and I am probably wrong, so please tell me where. Of course vhangup() clears all tty modes, so you need to save them

I am new to this mailing list. I apologize if any needed information is missing. I know this is a bit much to ask of wine's current serial port implementation, I am hoping someone has maybe figured this out already? Or can help me further the debugging process, I'd rather be part of the solution then simply another complaint about wine's serial port. ***** problem description

"H. Peter Anvin" <hpa at zytor.com> writes: > I have gotten scattered reports of strange problems caused by the fact > that virtio_console doesn't behave like a normal tty (support termios > and so on.) This seems to be an odd restriction -- is there any > fundamental reason for this design choice? Not that I know. I tacked it into hvc_console which provided the