search for: txd

Something about how we're implementing offsets for TXD is wrong, just flip to the generic quadop-based implementation in that case. This is the minimal fix appropriate for backporting. Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> Cc: <mesa-stable at lists.freedesktop.org> --- src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_n...

...in1 ... pin9-pin9) connection on Windows: PIN | PC | UPS __________________________________________________________________________________ Pin1 | DCD | described as DTR (must keep Hi) Pin2 | RxD | AC Power fail (NO, connected to pin4 UPS ground in case of AC failure) Pin3 | TxD | N/A Pin4 | DTR | UPS ground Pin5 | GND | Battery low (NO, connected to pin4 UPS ground in case of LB) Pin6 | DSR | 1. described as UPS RxD and 2. 3 seconds Hi (UPS shutdown) Pin7 | RTS | UPS ground Pin8 | CTS | N/A Pin9 | RI | described as UPS TxD And t...

Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> --- .../drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp | 12 ++++++++++-- 1 file changed, 10 insertions(+), 2 deletions(-) diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp b/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp index f010767..4a9e48f 100644 ---

...y fiddling about, I've come up with the "almost working" configuration below. This works except that it takes about 4 seconds from when the console says the line is answered until it plays my prompt. Watching the card with zttool, all flags start at 0. Then RxA, RxB, TxA, TxB, TxC, TxD change to 1. Then, a split second later, TxA, TxB, TxC, and TxD change to 0. A couple of seconds later, TxA, TxB, TxC, TxD change to 1 and the call progresses. What does this mean? Can you identify the proper configuration from this "handshake?" Verbosity is at least 99 -- Starti...

...| | - - | | | | | | | | CHASSIS 9<--------------//---------------------<5 SG | | | | | | | | TXD 2<--------------//---------------------<2 RXD | | | | | | | | RXD 1<--------------//---------------------<3 TXD | | | | | | | | -...

So I''ve been trying all day to get a small camping app I wrote up on Textdrive to no avail. Right now I''m getting a 500 error when I go to the site, and it spits this out (from lightty after i restart it and make a request to the app): (eval):13:in `initialize'': undefined method `to_hash'' for #<FCGI::Stream:0x83a35d8> (NoMethodError) from

...r_lowering_nvc0.cpp b/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp index 8f26645..0e24db7 100644 --- a/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp +++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp @@ -712,6 +712,7 @@ NVC0LoweringPass::handleManualTXD(TexInstruction *i) Value *zero = bld.loadImm(bld.getSSA(), 0); int l, c; const int dim = i->tex.target.getDim(); + const int array = i->tex.target.isArray(); i->op = OP_TEX; // no need to clone dPdx/dPdy later @@ -722,7 +723,7 @@ NVC0LoweringPass::handleManualTXD(TexI...

...O, connected to pin4 UPS ground in case of AC failure) The genericups driver does not have a setting to use the PC RxD line as a contact-closure input. It seems to be possible if the other software is using it, but genericups can only send a BREAK signal (rather than receiving it). > Pin3 | TxD | N/A > Pin4 | DTR | UPS ground > Pin5 | GND | Battery low (NO, connected to pin4 UPS ground in case of LB) > Pin6 | DSR | 1. described as UPS RxD and 2. 3 seconds Hi (UPS shutdown) > Pin7 | RTS | UPS ground > Pin8 | CTS | N/A > Pin9 | RI...

This is a weird one: My app works fine on our local box with webrick. After uploading to TxD server, the app starts behaving weirdly. I make some edits to one of the controllers and my changes don''t seem to be going through. So I go ahead and change the name of the controller file. The page loads without error. I figure maybe I''m in the wrong directory, so I change t...

...SPLIT, MERGE, CONSTRAINT @@ -44,7 +44,7 @@ const uint8_t Target::operationSrcNr[OP_LAST + 1] = 1, 1, 2, 1, 2, // VFETCH, PFETCH, EXPORT, LINTERP, PINTERP 1, 1, // EMIT, RESTART 1, 1, 1, // TEX, TXB, TXL, - 1, 1, 1, 1, 1, 2, // TXF, TXQ, TXD, TXG, TEXCSAA, TEXPREP + 1, 1, 1, 1, 1, 1, 2, // TXF, TXQ, TXD, TXG, TXLQ, TEXCSAA, TEXPREP 1, 1, 2, 2, 2, 2, 2, // SULDB, SULDP, SUSTB, SUSTP, SUREDB, SUREDP, SULEA 3, 3, 3, 3, // SUBFM, SUCLAMP, SUEAU, MADSP 0, // TEXBAR @@ -57,7 +57,7 @@ const...

To much of my dissapointment, the uptime on my TxD account does not improve. What alternatives do we have for hosting Rails projects on shared accounts? I would love to keep lighttpd and the level of control I have on TxD but wouldn''t like to spend much more (I am currently on the 25$/month plan). I won''t need much suppo...

>> On Nov 21, 2015, at 2:43 AM, R?bert SZAKSZ <robert at szaksz.eu> wrote: >> >> I mesured it and on DC and it shows 0 V (zero V). >> May be the information (pls. see attachment) that UPS PIN1 should bee keept HI is mandatory. Should I connect it to PC PIN4 DTR? > >Certainly possible. blazer_ser and nutdrv_qx should set DTR high and RTS low by default, but

...UPS ground in case of AC failure) > >The genericups driver does not have a setting to use the PC RxD line as a contact-closure input. It seems to be possible if the other software is using it, but genericups can only send a BREAK signal (rather >than receiving it). > >> Pin3 | TxD | N/A >> Pin4 | DTR | UPS ground >> Pin5 | GND | Battery low (NO, connected to pin4 UPS ground in case of LB) >> Pin6 | DSR | 1. described as UPS RxD and 2. 3 seconds Hi (UPS shutdown) >> Pin7 | RTS | UPS ground >> Pin8 | CTS | N/A &...

...H +#define _UPT1_DEFS_H + +struct UPT1_TxStats { + u64 TSOPktsTxOK; /* TSO pkts post-segmentation */ + u64 TSOBytesTxOK; + u64 ucastPktsTxOK; + u64 ucastBytesTxOK; + u64 mcastPktsTxOK; + u64 mcastBytesTxOK; + u64 bcastPktsTxOK; + u64 bcastBytesTxOK; + u64 pktsTxError; + u64 pktsTxDiscard; +}; + +struct UPT1_RxStats { + u64 LROPktsRxOK; /* LRO pkts */ + u64 LROBytesRxOK; /* bytes from LRO pkts */ + /* the following counters are for pkts from the wire, i.e., pre-LRO */ + u64 ucastPktsRxOK; + u64 ucastBytesRxOK; + u64 mcastPktsRxOK; + u64 mcastBytesRxOK; + u64...

...H +#define _UPT1_DEFS_H + +struct UPT1_TxStats { + u64 TSOPktsTxOK; /* TSO pkts post-segmentation */ + u64 TSOBytesTxOK; + u64 ucastPktsTxOK; + u64 ucastBytesTxOK; + u64 mcastPktsTxOK; + u64 mcastBytesTxOK; + u64 bcastPktsTxOK; + u64 bcastBytesTxOK; + u64 pktsTxError; + u64 pktsTxDiscard; +}; + +struct UPT1_RxStats { + u64 LROPktsRxOK; /* LRO pkts */ + u64 LROBytesRxOK; /* bytes from LRO pkts */ + /* the following counters are for pkts from the wire, i.e., pre-LRO */ + u64 ucastPktsRxOK; + u64 ucastBytesRxOK; + u64 mcastPktsRxOK; + u64 mcastBytesRxOK; + u64...

...H +#define _UPT1_DEFS_H + +struct UPT1_TxStats { + u64 TSOPktsTxOK; /* TSO pkts post-segmentation */ + u64 TSOBytesTxOK; + u64 ucastPktsTxOK; + u64 ucastBytesTxOK; + u64 mcastPktsTxOK; + u64 mcastBytesTxOK; + u64 bcastPktsTxOK; + u64 bcastBytesTxOK; + u64 pktsTxError; + u64 pktsTxDiscard; +}; + +struct UPT1_RxStats { + u64 LROPktsRxOK; /* LRO pkts */ + u64 LROBytesRxOK; /* bytes from LRO pkts */ + /* the following counters are for pkts from the wire, i.e., pre-LRO */ + u64 ucastPktsRxOK; + u64 ucastBytesRxOK; + u64 mcastPktsRxOK; + u64 mcastBytesRxOK; + u64...

...H +#define _UPT1_DEFS_H + +struct UPT1_TxStats { + u64 TSOPktsTxOK; /* TSO pkts post-segmentation */ + u64 TSOBytesTxOK; + u64 ucastPktsTxOK; + u64 ucastBytesTxOK; + u64 mcastPktsTxOK; + u64 mcastBytesTxOK; + u64 bcastPktsTxOK; + u64 bcastBytesTxOK; + u64 pktsTxError; + u64 pktsTxDiscard; +}; + +struct UPT1_RxStats { + u64 LROPktsRxOK; /* LRO pkts */ + u64 LROBytesRxOK; /* bytes from LRO pkts */ + /* the following counters are for pkts from the wire, i.e., pre-LRO */ + u64 ucastPktsRxOK; + u64 ucastBytesRxOK; + u64 mcastPktsRxOK; + u64 mcastBytesRxOK; + u64...

...H +#define _UPT1_DEFS_H + +struct UPT1_TxStats { + u64 TSOPktsTxOK; /* TSO pkts post-segmentation */ + u64 TSOBytesTxOK; + u64 ucastPktsTxOK; + u64 ucastBytesTxOK; + u64 mcastPktsTxOK; + u64 mcastBytesTxOK; + u64 bcastPktsTxOK; + u64 bcastBytesTxOK; + u64 pktsTxError; + u64 pktsTxDiscard; +}; + +struct UPT1_RxStats { + u64 LROPktsRxOK; /* LRO pkts */ + u64 LROBytesRxOK; /* bytes from LRO pkts */ + /* the following counters are for pkts from the wire, i.e., pre-LRO */ + u64 ucastPktsRxOK; + u64 ucastBytesRxOK; + u64 mcastPktsRxOK; + u64 mcastBytesRxOK; + u64...

...H +#define _UPT1_DEFS_H + +struct UPT1_TxStats { + u64 TSOPktsTxOK; /* TSO pkts post-segmentation */ + u64 TSOBytesTxOK; + u64 ucastPktsTxOK; + u64 ucastBytesTxOK; + u64 mcastPktsTxOK; + u64 mcastBytesTxOK; + u64 bcastPktsTxOK; + u64 bcastBytesTxOK; + u64 pktsTxError; + u64 pktsTxDiscard; +}; + +struct UPT1_RxStats { + u64 LROPktsRxOK; /* LRO pkts */ + u64 LROBytesRxOK; /* bytes from LRO pkts */ + /* the following counters are for pkts from the wire, i.e., pre-LRO */ + u64 ucastPktsRxOK; + u64 ucastBytesRxOK; + u64 mcastPktsRxOK; + u64 mcastBytesRxOK; + u64...

...w that helps me. USB would be cool but I don't really need that, it just has to work. I have also found a document that shows the pinout of the com port (page 8) there: http://www.watfordcontrol.co.th/products/UPS/series_ae1/Catalog_A-19_A_E_engl(1999).pdf My question is, do I have to swap the TXD and RXD pins to get it working? I have tried to add the USB device address into the ups.conf and run the driver config tool thing. After a while it says: tcgetattr(/proc/bus/usb/004/002): Inappropriate ioctl for device After that I have tried the serial port, with a 1:1 cable, which didn't wor...