Menu
▾
▴
vacm-general
You can subscribe to this list here.
| 2000 |
Jan
(2) |
Feb
|
Mar
|
Apr
(3) |
May
|
Jun
|
Jul
(1) |
Aug
(26) |
Sep
(4) |
Oct
(7) |
Nov
(5) |
Dec
(19) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2001 |
Jan
(7) |
Feb
(16) |
Mar
|
Apr
(12) |
May
(9) |
Jun
|
Jul
(23) |
Aug
(4) |
Sep
(8) |
Oct
(1) |
Nov
|
Dec
|
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2003 |
Jan
(2) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Dean J. <dt...@ub...> - 2003-01-02 23:49:13
|
On Thu, 2003-01-02 at 17:17, jeff wrote: > I have a couple of VA boxes, a 1220 and 1221. I am renting out the 1220 > to someone for their site. They want to run windows (I know, believe me > I tried) so I have installed w2k for them. > > I suspect that I might have to power cycle this box for them so I was > wondering if I could use these strange ports on the back of the box to > do this. Beats having to go down to the data center. > > I have read over the VACM docs and I think I can set this up, but I am > confused about how the wiring works. Do I use straight through ethernet > cables? Can I connect the VASNET port of the 1220 to the ICMB port of > the 1221? If that doesn't work is there some other way that I could > achieve my purpose? I am not sure about the other methods, but the way I always did it was through the EMP port, which is a serial connection. It wouldn't really require VACM, as VACM was meant more as a manager for many boxes. I can't recall which type of serial cable it used, but you could just hook the serial cable from another one of your boxes to it and get to the EMP via minicom. -- Dean Johnson <dt...@ub...> |
|
From: jeff <je...@eu...> - 2003-01-02 23:10:36
|
I have a couple of VA boxes, a 1220 and 1221. I am renting out the 1220 to someone for their site. They want to run windows (I know, believe me I tried) so I have installed w2k for them. I suspect that I might have to power cycle this box for them so I was wondering if I could use these strange ports on the back of the box to do this. Beats having to go down to the data center. I have read over the VACM docs and I think I can set this up, but I am confused about how the wiring works. Do I use straight through ethernet cables? Can I connect the VASNET port of the 1220 to the ICMB port of the 1221? If that doesn't work is there some other way that I could achieve my purpose? |
|
From: Alexandre B. <ale...@bu...> - 2002-05-14 09:20:25
|
Hello,
I having problems configuring EMP.
I work with VACM 2.0.5a.
I have two IPMI 1.5 enabled servers, they are Bull Express 5800/120lf.
To configure EMP, I have to boot on the ESM Pro 5.06 CD
because the 120lf's bios doesn't contain an EMP category.
The server category only allows to redirect or not Console Display.
Once the BMC is configured to work with the serial Line
(19.2 kbps, CRTSCTS flow control), and the LAN (ip address to set)
with a numerical password set too,
I verified that everything is working well by taking control
of one servers from a third computer, Windows 2000 based.
On that Windows based machine,
it's Nec MWA I used to take control of one of the 120lf servers.
All of that told me that the servers are well configured,
especially the serial cross-cable is working.
So I tried to configure VACM on one of the 120lf server
to take control of the other, by serial and/or by LAN.
It's a RedHat 7.2 installed on that controller computer.
I managed to compile and installed it without problems
By serial, I connected ttyS0 on the controller machine
and ttyS1 and the controlled machine.
I started "nexxus -l" on the controller machine.
Under vash, I renamed the default user blum into another.
I added the controlled machine in a nodes-group I defined.
I tried to set EMP by typing:
vash$ ipc localhost emp:configuration:server1:/dev/ttyS0:1234
I get everytime.
EMP:72:JOB_STARTED
EMP:72:STATUS:ENGAGING <with a little wait state of 5
seconds approximatively here>
EMP:72:STATUS:PROTOCOL_UNAVAILABLE
EMP:72:JOB_COMPLETED
vash$
nexxus said :
EMP] Thread server1 protocol unavailable (Connection timed out)
By LAN I typed :
vash$ ipc localhost emp:configuration:server1:10.0.0.1-623:1234
and get every time:
EMP:73:JOB_STARTED
EMP:73:STATUS:ENGAGING
EMP:73:STATUS:ENGAGE_FAILED
EMP:73:JOB_ERROR:Connection refused
vash$
nexxus said :
[17:04:15][EMP] Thread server1 engage failed (Connection refused)
and a lot of the following message
[17:04:16][EMP] Driver for node server1 reports unexpected serial
traffic (bad cabling or hw error?)
[17:04:16][EMP] Driver for node server1 reports unexpected serial
traffic (bad cabling or hw error?)
[17:04:16][EMP] Driver for node server1 reports unexpected serial
traffic (bad cabling or hw error?)
[17:04:16][EMP] Driver for node server1 reports unexpected serial
traffic (bad cabling or hw error?)
[17:04:16][EMP] Driver for node server1 reports unexpected serial
traffic (bad cabling or hw error?)
[17:04:16][EMP] Driver for node server1 reports unexpected serial
traffic (bad cabling or hw error?)
[17:04:16][EMP] Driver for node server1 reports unexpected serial
traffic (bad cabling or hw error?)
[17:04:16][EMP] Driver for node server1 reports unexpected serial
traffic (bad cabling or hw error?)
[17:04:16][EMP] Driver for node server1 reports unexpected serial
traffic (bad cabling or hw error?)
[17:04:16][EMP] Driver for node server1 reports unexpected serial
traffic (bad cabling or hw error?)
[17:04:16][EMP] Driver for node server1 reports unexpected serial
traffic (bad cabling or hw error?)
[17:04:16][EMP] Driver for node server1 reports unexpected serial
traffic (bad cabling or hw error?)
[17:04:16][EMP] Driver for node server1 reports unexpected serial
traffic (bad cabling or hw error?)
...
which make my /var/log/vacm.log growing too much I have to delete it.
I'm almost sure it is the 623 port to access
because, when I "tcpdumped" on the controlled server
when I take control of it from the Windows 2000's MWA software,
I see communication o this port, between the two machines.
Could someone tell me what I missed to have VACM EMP module working ?
Thanks to all.
Alexandre BERDAH
|
|
From: Dirk W. <di...@re...> - 2001-10-01 20:27:03
|
hi, maybe somebody is still listening and can give me a piece of advice. ;) i have a cyclades terminal server which i want to use under vacm. i assume the sercon module is the right thing for that. the problem i have cuurently is configuring the cyclades correctly so that it provides access to my machines. in my understanding it should be like all other terminalservers, so that if i do "telnet my_terminalserver port" (where port is a number dependended on the brand of tserver and the serial port) i get to the serial console of the device which is hooked up. so far so good, but i can't get it to work. as a first try i just don't use vacm, i see that the cyclades i listening on the ports i configured. but if i telnet to a port like mentioned above, i get: Entering character Mode Escape character is ^] Connection closed by foreign host. the cables/connectors are the same as for the rocketport ports. pslave.conf has "all.authtype none", "all.protocol socket_server". i don't use radius authentication. i know the problem is a little bit off topic, but i'd appreciate any help. maybe somebody has done this before and can tell me what the pslave.conf file should be like. afair VALinux was about to sell this a turnkey solution, so somebody might still know how this is going to fly ;-) thx, ~dirkw |
|
From: <ra...@ra...> - 2001-09-13 07:27:32
|
On Thu, 13 Sep 2001 09:15:35 +0200 XiScO <fn...@ga...> babbled profusely: > Hi! > when I create a node inside a nexxus with flim,it is supposed that flim > will do all the necessary things, rith(creating a variable for the node > and assigning the ip and password)?.The problem is that it do for me all > except setting the password for the node in nexxus, so I must do it > using vash. Is this on this way or perhaps I'm doing something wrong. i never wrote the code in flim to support that feature. by the time vacm settlied in the direction it was going... flim's design wasn't geared towards what vacm at the back-end was doing... the choice was to rewrite flim - ro wait for vacm 3.0 - i was waiting for 3.0. right now 3.0 will likely never happen and i don't see any good reaosn to rewrite flim - as well... i'm unemployed - unless someone wants to hire me to continue work on it and fix all the issues i've been meaning to but have been on hold due to other issues. :) > Tanks > -- > Salu2, > > ******** > Francisco Javier > > _______________________________________________ > Vacm-general mailing list > Vac...@li... > https://lists.sourceforge.net/lists/listinfo/vacm-general -- --------------- Codito, ergo sum - "I code, therefore I am" -------------------- The Rasterman (Carsten Haitzler) ra...@ra... Unemployed ra...@de... Mobile Phone: +61 (0)408 363 984 Work Phone: I don't anymore. |
|
From: XiScO <fn...@ga...> - 2001-09-13 07:12:44
|
Hi! when I create a node inside a nexxus with flim,it is supposed that flim will do all the necessary things, rith(creating a variable for the node and assigning the ip and password)?.The problem is that it do for me all except setting the password for the node in nexxus, so I must do it using vash. Is this on this way or perhaps I'm doing something wrong. Tanks -- Salu2, ******** Francisco Javier |
|
From: XiScO <fn...@ga...> - 2001-09-10 12:36:01
|
Hi! I've simple PCs without any additional hardware. Is there any moudle except from SYSSTAT which I can use? Thanks -- Salu2, ******** Francisco Javier |
|
From: XiScO <fn...@ga...> - 2001-09-10 10:16:05
|
Hi! I've run the daemon for sysstat on a node and it asked me for a password, then I went to flim and added a node with the IP of it and the password I've set. When I try to get the system status for this node I get at the node console the following message: Authentication Failed. Then I've gone to nexxus using vash and input the next ipc localhost sysstat:configuration:machine01:password and then it worked. But is it not the same to do this than do it in flim when I add a node??? What have I done wrong? Thanks -- Salu2, ******** Francisco Javier |
|
From: <ra...@ra...> - 2001-09-07 18:14:43
|
On Fri, 7 Sep 2001 10:04:56 -0400 Rob Latham <rl...@pl...> babbled profusely: > On Fri, Sep 07, 2001 at 03:31:32PM +0200, XiScO wrote: > > I've found this error when trying to run flim, but the library exists, > > what's the problem?? > > Tanks. > > [root@marjal02 vacm-2.0.5]# flim > > flim: error while loading shared libraries: libvacmclient-2.0.5.so: > > cannot load shared object file: No such file or directory > > what happens when you do "ldd flim" ? What libraries are reported as > ot found ? > > > [root@marjal02 vacm-2.0.5]# whereis libvacmclient-2.0.5.so > > libvacmclient-2.0.5: /usr/local/lib/libvacmclient-2.0.5.so > > sounds like you need to add /usr/local/lib to your LD_LIBRARY_PATH, or > add it to /etc/ld.so.conf and re-run ldconfig yeah. that. :) > > ==rob > > -- > [ Rob Latham <rl...@pl...> Developer, Admin, Alchemist ] > [ Paralogic Inc. - www.plogic.com ] > [ ] > [ EAE8 DE90 85BB 526F 3181 1FCF 51C4 B6CB 08CC 0897 ] > > _______________________________________________ > Vacm-general mailing list > Vac...@li... > https://lists.sourceforge.net/lists/listinfo/vacm-general -- --------------- Codito, ergo sum - "I code, therefore I am" -------------------- The Rasterman (Carsten Haitzler) ra...@ra... ra...@va... VA Linux Systems ra...@de... Mobile Phone: +61 (0)408 363 984 Work Phone: +61 (02) 9386 9362 |
|
From: Rob L. <rl...@pl...> - 2001-09-07 14:04:59
|
On Fri, Sep 07, 2001 at 03:31:32PM +0200, XiScO wrote: > I've found this error when trying to run flim, but the library exists, > what's the problem?? > Tanks. > [root@marjal02 vacm-2.0.5]# flim > flim: error while loading shared libraries: libvacmclient-2.0.5.so: > cannot load shared object file: No such file or directory what happens when you do "ldd flim" ? What libraries are reported as ot found ? > [root@marjal02 vacm-2.0.5]# whereis libvacmclient-2.0.5.so > libvacmclient-2.0.5: /usr/local/lib/libvacmclient-2.0.5.so sounds like you need to add /usr/local/lib to your LD_LIBRARY_PATH, or add it to /etc/ld.so.conf and re-run ldconfig ==rob -- [ Rob Latham <rl...@pl...> Developer, Admin, Alchemist ] [ Paralogic Inc. - www.plogic.com ] [ ] [ EAE8 DE90 85BB 526F 3181 1FCF 51C4 B6CB 08CC 0897 ] |
|
From: XiScO <fn...@ga...> - 2001-09-07 13:36:01
|
I've found this error when trying to run flim, but the library exists, what's the problem?? Tanks. [root@marjal02 vacm-2.0.5]# flim flim: error while loading shared libraries: libvacmclient-2.0.5.so: cannot load shared object file: No such file or directory [root@marjal02 vacm-2.0.5]# whereis libvacmclient-2.0.5.so libvacmclient-2.0.5: /usr/local/lib/libvacmclient-2.0.5.so [root@marjal02 vacm-2.0.5]# -- Salu2, ******** Francisco Javier |
|
From: XiScO <fn...@ga...> - 2001-09-06 15:52:50
|
Hi! I'm new to VACM and have some questions. First of all I want to ensure that VACM is what I need. We want a management software for a cluster, so we can know the state of each node at a time from only one PC. This is possible with VACM, right?(sorry but it is difficult for me to understand VACM). Other question is: Does the tar src file has all the software in all the rpms? -Should I install nexxus in all pc's?, well really which components should I install in the pc which I want to motoring? Thanks -- Salu2, ******** Francisco Javier |
|
From: Rob L. <rl...@pl...> - 2001-08-23 18:45:23
|
On Thu, Aug 23, 2001 at 12:32:19PM -0600, Nelson, Ben wrote: > I've got sercon set up on all of my machines and when I am watching them > boot from sercon_terminal, the boot messages always stop at "Freeing used > kernel memory" and then I get a Login: prompt. The machine I'm using has > console redirection set up in the BIOS on serial port 2, 0258 IRQ 3 , I have > the following lines in my /etc/lilo.conf > > serial=0,19200n8 > append="console=ttyS1,19200n8 console=tty0" > > I can see the entire post and get into the BIOS and everything from sercon, > but if the machines ever need to have a manual fsck done on them during the > boot process, I'll never see the message or be able to do anything about it. if you can live w/o ever seeing the messages on the video console, swap the order of console: append="console=tty0 console=ttyS1,19200n8" It'd be very nice if i knew how to get init scripts to talk on vga /and/ serial consoles ==rob -- [ Rob Latham <rl...@pl...> Developer, Admin, Alchemist ] [ Paralogic Inc. - www.plogic.com ] [ ] [ EAE8 DE90 85BB 526F 3181 1FCF 51C4 B6CB 08CC 0897 ] |
|
From: Nelson, B. <bn...@ri...> - 2001-08-23 18:38:31
|
I've got sercon set up on all of my machines and when I am watching them boot from sercon_terminal, the boot messages always stop at "Freeing used kernel memory" and then I get a Login: prompt. The machine I'm using has console redirection set up in the BIOS on serial port 2, 0258 IRQ 3 , I have the following lines in my /etc/lilo.conf serial=0,19200n8 append="console=ttyS1,19200n8 console=tty0" I also added the proper line to /etc/inittab to start up a getty listening on ttyS1 I can see the entire post and get into the BIOS and everything from sercon, but if the machines ever need to have a manual fsck done on them during the boot process, I'll never see the message or be able to do anything about it. Thanks, --Ben |
|
From: Dirk W. <di...@re...> - 2001-08-15 19:06:42
|
Hi, i wasn't quite clear with my objective. what i wanted is: configure a baytech powerstrip so that with hoover i can select my client and press reset, as i am used to do with EMP capable clients. 3 questions: a is that possible? b what baytech strip do i need for that c (if answer(a)=yes): what do i need to do to set it up? thx! ~dirkw On Tue, 14 Aug 2001, Dirk Wetter wrote: > > Hi all, > > what kind of Baytech powerstrip do i need for controlling it with > vacm? Is the one with the serial one just fine (e.g. RPC-28) > or do i need a ethernet connection as well? can somebody please > enlighten me ;-). > the thing which confuses me a little bit though is that the docu > doesn't say for the serial Baytech what (BayTech)port the machine is > hooked up to: > > ---- > FORMAT: > BAYTECH:CONFIGURATION:<NODE_ID>:<DEVICE_ADDRESS> > RESPONSES: > JOB_STARTED > JOB_ERROR:(errno string) > JOB_COMPLETED > FIELDS: > <DEVICE_ADDRESS> - Either a serial port or the address of a port on > a terminal server in the form of hostname-port > --- > > but the for reboot it says: > > --- > FORMAT: > BAYTECH:PORT_REBOOT:<NODE_ID>:<PORT_ID> > --- > > or does it mean that i only can use vash and not hoover powercycling the > machine? > > thx, > ~dirkw > > > _______________________________________________ > Vacm-general mailing list > Vac...@li... > http://lists.sourceforge.net/lists/listinfo/vacm-general > |
|
From: Dirk W. <di...@re...> - 2001-08-14 18:09:27
|
Hi all, what kind of Baytech powerstrip do i need for controlling it with vacm? Is the one with the serial one just fine (e.g. RPC-28) or do i need a ethernet connection as well? can somebody please enlighten me ;-). the thing which confuses me a little bit though is that the docu doesn't say for the serial Baytech what (BayTech)port the machine is hooked up to: ---- FORMAT: BAYTECH:CONFIGURATION:<NODE_ID>:<DEVICE_ADDRESS> RESPONSES: JOB_STARTED JOB_ERROR:(errno string) JOB_COMPLETED FIELDS: <DEVICE_ADDRESS> - Either a serial port or the address of a port on a terminal server in the form of hostname-port --- but the for reboot it says: --- FORMAT: BAYTECH:PORT_REBOOT:<NODE_ID>:<PORT_ID> --- or does it mean that i only can use vash and not hoover powercycling the machine? thx, ~dirkw |
|
From: San M. <net...@va...> - 2001-07-27 17:34:16
|
Ahhh excellent.. however I had found that with more nodes things start to break down with EMP protocol.. simply pinging around on the network a bit could cause problems.. (not good) TGIF -san -----Original Message----- From: Dean Johnson [mailto:dt...@ub...] Sent: Thursday, July 26, 2001 9:41 PM To: San Mehat Cc: 'Ard van Breemen'; vac...@li... Subject: Re: [Vacm-general] Slow EMP handling San Mehat wrote: > Ard, > > This has been a common problem with network T/S's... when receiving data > from the serial port, they wait for either a minimum number of bytes to > arrive, or for a maximum timeout before sending the data over the > network... these devices are normally optimized for streaming protocols > (as they should be), and obviously it doesn't work with us... > That's one of the reasons I like cisco's.. their RAW port *really* is > raw... one byte of data from the serial port ends up sending a frame... > which is why they work.... I also tried other network terminal servers > like the Digi EtherLites, various Livingston beasties, etc... > -san > Bill Sparks (js...@sg...) was able to get the SGI version of the EtherLite working reasonably well with the EMP. It was the latest hardware with the latest firmware, and probably some prevailing tailwind involved, but it worked well. I don't know how it would fare under a load, but it successfully handled bringing an SGI 1200 up and down for many hours without a failure. -Dean |
|
From: Dean J. <dt...@ub...> - 2001-07-27 04:41:53
|
San Mehat wrote: > Ard, > > This has been a common problem with network T/S's... when receiving data > from the serial port, they wait for either a minimum number of bytes to > arrive, or for a maximum timeout before sending the data over the > network... these devices are normally optimized for streaming protocols > (as they should be), and obviously it doesn't work with us... > That's one of the reasons I like cisco's.. their RAW port *really* is > raw... one byte of data from the serial port ends up sending a frame... > which is why they work.... I also tried other network terminal servers > like the Digi EtherLites, various Livingston beasties, etc... > -san > Bill Sparks (js...@sg...) was able to get the SGI version of the EtherLite working reasonably well with the EMP. It was the latest hardware with the latest firmware, and probably some prevailing tailwind involved, but it worked well. I don't know how it would fare under a load, but it successfully handled bringing an SGI 1200 up and down for many hours without a failure. -Dean |
|
From: Dean J. <dt...@ub...> - 2001-07-27 04:32:43
|
San Mehat wrote: > Hey Ard, > > As I suspected, it looks like you're having a serial protocol issue.. > The reason that only the cisco boxes are qualified as a *network* based > connectivity method for EMP are that they have below 1 ms round trip > latency on single byte transactions on their raw ports... The EMP > protocol requires a MAXIMUM latency of 2ms per byte.. otherwise it will > timeout the byte (and sometimes the fame). It is VERY difficult to > recover a frame when this occurs, so we end up having to do nasty > re-synchronizing which doesn't always work... > > I would advise going to a rocketport connectivity solution since its > much cheaper than the cisco method... The Comtrol Interchange VS1000 seems to also work. -Dean |
|
From: San M. <net...@va...> - 2001-07-25 17:06:12
|
Hey Ard, IPMI 1.5 is the latest and greatest IPMI management goop but it works completely over LAN via UDP... kind of cool.. no timing requirements.. fairly strong authentication... etc... Bike computer? -----Original Message----- From: 'Ard van Breemen' [mailto:ar...@te...] Sent: Wednesday, July 25, 2001 8:52 AM To: San Mehat Cc: sa...@va...; vac...@li... Subject: Re: [Vacm-general] Slow EMP handling On Wed, Jul 25, 2001 at 08:24:15AM -0700, San Mehat wrote: > The first thing I did when I got my cyclades was open it up :) Ted Tso, Of course :) > the author of the Linux TTY/serial driver layer also had a look.. It > appears they use a *ton* of semi-standard UARTS which are connected to > an ISA bus on the system... fine for normal bursted serial flow.. but ugh... > really awfull for lots of single byte I/O which is what the EMP state > machine calls for rather heavily.... Hmmm.... Actually it should be workable... A kernel "thread" should poll all emp ports (I guess half of them will be emp, the other half will be serial console) in a single poll stroke. That is about 1920 poll's per second no matter the number of ports. Any active port will result in the emp-daemon being scheduled at most 1920 times per second, no matter the number of ports. In a single stroke the emp-daemon should be able to respond to all traffic, and queue any incoming data from the emp ports. That is 500 microseconds for kernel-interrupt, task switch, and handling of data. Of course, the task switch only happens when it was not already running. After that, a more normal threaded and buffered approach can be used. > This has been a common problem with serial concentrator vendors.... in > any event, playing in the kernel may be difficult as I understand their > serial driver itself is not open source.... other than that I agree that Grrrr. Although, the CDK is a .i386.rpm, but it looks like it contains source. > it may be just a matter of software, however I just don't have the > bandwidth to work on yet another piece of serial hardware (I'm currently > working on preliminary IPMI 1.5 over LAN support) Eh, that is ipmi with default lan support? > If you do decide to take this on, let me know.. I'd be happy to provide > whatever EMP related assistance I can... Well, I first have to search for a cyclades first... I will probably not be able to obtain one :( , so I will try to think out my bike computer some more. (bike sample http://www.alleweder.nl ) (Ever seen a bike computer that show median speed instead of that stupid average?) -- <ar...@te...> Telegraaf Elektronische Media http://wwwijzer.nl http://leerquoten.monster.org/ http://www.faqs.org/rfcs/rfc1855.html Let your government know you value your freedom. Sign the petition: http://petition.eurolinux.org/ |
|
From: 'Ard v. Breemen' <ar...@te...> - 2001-07-25 15:52:35
|
On Wed, Jul 25, 2001 at 08:24:15AM -0700, San Mehat wrote: > The first thing I did when I got my cyclades was open it up :) Ted Tso, Of course :) > the author of the Linux TTY/serial driver layer also had a look.. It > appears they use a *ton* of semi-standard UARTS which are connected to > an ISA bus on the system... fine for normal bursted serial flow.. but ugh... > really awfull for lots of single byte I/O which is what the EMP state > machine calls for rather heavily.... Hmmm.... Actually it should be workable... A kernel "thread" should poll all emp ports (I guess half of them will be emp, the other half will be serial console) in a single poll stroke. That is about 1920 poll's per second no matter the number of ports. Any active port will result in the emp-daemon being scheduled at most 1920 times per second, no matter the number of ports. In a single stroke the emp-daemon should be able to respond to all traffic, and queue any incoming data from the emp ports. That is 500 microseconds for kernel-interrupt, task switch, and handling of data. Of course, the task switch only happens when it was not already running. After that, a more normal threaded and buffered approach can be used. > This has been a common problem with serial concentrator vendors.... in > any event, playing in the kernel may be difficult as I understand their > serial driver itself is not open source.... other than that I agree that Grrrr. Although, the CDK is a .i386.rpm, but it looks like it contains source. > it may be just a matter of software, however I just don't have the > bandwidth to work on yet another piece of serial hardware (I'm currently > working on preliminary IPMI 1.5 over LAN support) Eh, that is ipmi with default lan support? > If you do decide to take this on, let me know.. I'd be happy to provide > whatever EMP related assistance I can... Well, I first have to search for a cyclades first... I will probably not be able to obtain one :( , so I will try to think out my bike computer some more. (bike sample http://www.alleweder.nl ) (Ever seen a bike computer that show median speed instead of that stupid average?) -- <ar...@te...> Telegraaf Elektronische Media http://wwwijzer.nl http://leerquoten.monster.org/ http://www.faqs.org/rfcs/rfc1855.html Let your government know you value your freedom. Sign the petition: http://petition.eurolinux.org/ |
|
From: San M. <net...@va...> - 2001-07-25 15:33:40
|
The download log code erases the log as it downloads it.. the log in the hardware is meant to be a mailbox and not general storage.. so everytime an entry is downloaded it is deleted, so once the log download is complete, the log should be empty until something puts an entry in it :) -san -----Original Message----- From: vac...@li... [mailto:vac...@li...] On Behalf Of 'Ard van Breemen' Sent: Wednesday, July 25, 2001 8:09 AM To: vac...@li... Subject: Re: [Vacm-general] Slow EMP handling On Wed, Jul 25, 2001 at 04:28:45PM +0200, 'Ard van Breemen' wrote: > On Wed, Jul 25, 2001 at 03:21:29PM +0200, 'Ard van Breemen' wrote: > > On Tue, Jul 24, 2001 at 11:26:11AM -0700, San Mehat wrote: > > > As I suspected, it looks like you're having a serial protocol issue.. > > > The reason that only the cisco boxes are qualified as a *network* based > > > connectivity method for EMP are that they have below 1 ms round trip > > > latency on single byte transactions on their raw ports... The EMP > > > protocol requires a MAXIMUM latency of 2ms per byte.. otherwise it will > > > timeout the byte (and sometimes the fame). It is VERY difficult to > > But how is the byte acked? What happens with modems? If I hook up a > > modem, the round trip will probably exceed that 2 ms due to compression > > and other stuff. We are after all talking about almost 4 byte-times. > Allright... > Debugging using tcpdump and ethereal. > My system send a byte to the portmaster. > 1.37 ms later the portmaster acks. > 53 ms later the portmasters sends a packet containing data. > Usually 1 byte as a reaction from my system. But sometimes up to 29 bytes. > But always 53 ms... > As if something was nagging... Or at least some timer seems to be involved... It get's worse: Enabled all emp debugging (like DEBUG_TRANS), the download still takes long, but other actions are currently fast. Refresh of the node will fail the first time. As if it tries to reconnect with a connection still open. The second time it works (maybe the connection is closed due to the failure of opening it :) ). Anyway: ard@c24574:/net/home/ard$ time vash -c localhost -u blum -p frub -x 'ipc localhost emp:chassis_status:rs0' EMP:124:JOB_STARTED EMP:124:CSTATUS:YES:NO:NO:NO:NO:YES:NO:NO:NO:NO:NO:YES:NO:NO:NO EMP:124:JOB_COMPLETED real 0m0.818s user 0m0.000s sys 0m0.000s ard@c24574:/net/home/ard$ time vash -c localhost -u blum -p frub -x 'ipc localhost emp:chassis_status:rs0' EMP:127:JOB_STARTED EMP:127:CSTATUS:YES:NO:NO:NO:NO:YES:NO:NO:NO:NO:NO:YES:NO:NO:NO EMP:127:JOB_COMPLETED real 0m0.528s user 0m0.000s sys 0m0.000s The .5 s is median. It either takes .5 s or .8 s. The download_log takes about the same time, but that is probably cached? -- <ar...@te...> Telegraaf Elektronische Media http://wwwijzer.nl http://leerquoten.monster.org/ http://www.faqs.org/rfcs/rfc1855.html Let your government know you value your freedom. Sign the petition: http://petition.eurolinux.org/ _______________________________________________ Vacm-general mailing list Vac...@li... http://lists.sourceforge.net/lists/listinfo/vacm-general |
|
From: San M. <net...@va...> - 2001-07-25 15:32:18
|
Ard, This has been a common problem with network T/S's... when receiving data from the serial port, they wait for either a minimum number of bytes to arrive, or for a maximum timeout before sending the data over the network... these devices are normally optimized for streaming protocols (as they should be), and obviously it doesn't work with us... That's one of the reasons I like cisco's.. their RAW port *really* is raw... one byte of data from the serial port ends up sending a frame... which is why they work.... I also tried other network terminal servers like the Digi EtherLites, various Livingston beasties, etc... -san -----Original Message----- From: 'Ard van Breemen' [mailto:ar...@te...] Sent: Wednesday, July 25, 2001 7:29 AM To: San Mehat Cc: vac...@li... Subject: Re: [Vacm-general] Slow EMP handling On Wed, Jul 25, 2001 at 03:21:29PM +0200, 'Ard van Breemen' wrote: > On Tue, Jul 24, 2001 at 11:26:11AM -0700, San Mehat wrote: > > As I suspected, it looks like you're having a serial protocol issue.. > > The reason that only the cisco boxes are qualified as a *network* based > > connectivity method for EMP are that they have below 1 ms round trip > > latency on single byte transactions on their raw ports... The EMP > > protocol requires a MAXIMUM latency of 2ms per byte.. otherwise it will > > timeout the byte (and sometimes the fame). It is VERY difficult to > But how is the byte acked? What happens with modems? If I hook up a > modem, the round trip will probably exceed that 2 ms due to compression > and other stuff. We are after all talking about almost 4 byte-times. Allright... Debugging using tcpdump and ethereal. My system send a byte to the portmaster. 1.37 ms later the portmaster acks. 53 ms later the portmasters sends a packet containing data. Usually 1 byte as a reaction from my system. But sometimes up to 29 bytes. But always 53 ms... As if something was nagging... Or at least some timer seems to be involved... -- <ar...@te...> Telegraaf Elektronische Media http://wwwijzer.nl http://leerquoten.monster.org/ http://www.faqs.org/rfcs/rfc1855.html Let your government know you value your freedom. Sign the petition: http://petition.eurolinux.org/ |
|
From: San M. <net...@va...> - 2001-07-25 15:29:45
|
Ard, Basically an EMP request frame looks like this: 0xa0 <-- frame start 0x20 <-- EMP slave address 0xxx <-- LUN and NetFn 0xxx <-- checksum 0x64 <-- EMP application slave address 0xxx <-- sequence number (goes up by 4) 0xxx <-- Command 0xx1 <-- Command arg byte 1 0xx2 <-- Command arg byte 2 0xxn <-- Command arg byte n 0xxx <-- checksum 0xa5 <-- Frame end Now after sending each byte you have to wait for an ack (0xa8) from the hardware.. When the hardware ack's a byte, the *next* byte MUST arrive Within 2ms, otherwise the hardware thinks there has been a communications error and *SILENTLY* discards the entire frame. This is one of the large problems with resynchronization... if we send a few bytes of the command within the proper 2ms window, then for one reason or another we send one byte *after* the window, then the remote firmware will silently toss the frame. We of course don't know this has happened so as per the EMP spec, when the byte we last sent does not receive an ack, we resend it and it is acked.. this continues until we send the frame end character at which point the remote hardware sends us an error saying the command we sent is invalid because the frame it received was truncated due to the fact that it tossed the first few bytes due to a timeout. Now... take that behavior, and add the fact that every 2 seconds of realtime, no matter what is going on the port, the hardware will send a PING frame (EMP_ACTIVE), and things get even more messy... You can have a look at emp_driver.c to see just how messy things can get... Basically, H/W S/W flow control would of made this whole thing a lot nicer.. but what can you do... sigh.. As for the resynchronizing stuff, if you have the right debugging compiled in you may see a msg like this: Driver %s calling detect_protocol because resync required or something... ;) For more information on this in terms of debugging, make sure that TRANS_DEBUG is defined in emp_driver.c (transport debug), and run it... you might want to log it or something as this will generate a lot of data when running on multiple nodes -san -----Original Message----- From: 'Ard van Breemen' [mailto:ar...@te...] Sent: Wednesday, July 25, 2001 6:21 AM To: San Mehat Cc: vac...@li... Subject: Re: [Vacm-general] Slow EMP handling On Tue, Jul 24, 2001 at 11:26:11AM -0700, San Mehat wrote: > As I suspected, it looks like you're having a serial protocol issue.. > The reason that only the cisco boxes are qualified as a *network* based > connectivity method for EMP are that they have below 1 ms round trip > latency on single byte transactions on their raw ports... The EMP > protocol requires a MAXIMUM latency of 2ms per byte.. otherwise it will > timeout the byte (and sometimes the fame). It is VERY difficult to But how is the byte acked? What happens with modems? If I hook up a modem, the round trip will probably exceed that 2 ms due to compression and other stuff. We are after all talking about almost 4 byte-times. > recover a frame when this occurs, so we end up having to do nasty > re-synchronizing which doesn't always work... But if it needs to re-synchronize, it would tell me, right? It does not say anything about sync... (Hmmm, see the debugging commented out, recompiling...) > I would advise going to a rocketport connectivity solution since its > much cheaper than the cisco method... Well, another good solution would be a real power-boot :). -- <ar...@te...> Telegraaf Elektronische Media http://wwwijzer.nl http://leerquoten.monster.org/ http://www.faqs.org/rfcs/rfc1855.html Let your government know you value your freedom. Sign the petition: http://petition.eurolinux.org/ |
|
From: San M. <net...@va...> - 2001-07-25 15:14:09
|
Hey Ard, The first thing I did when I got my cyclades was open it up :) Ted Tso, the author of the Linux TTY/serial driver layer also had a look.. It appears they use a *ton* of semi-standard UARTS which are connected to an ISA bus on the system... fine for normal bursted serial flow.. but really awfull for lots of single byte I/O which is what the EMP state machine calls for rather heavily.... This has been a common problem with serial concentrator vendors.... in any event, playing in the kernel may be difficult as I understand their serial driver itself is not open source.... other than that I agree that it may be just a matter of software, however I just don't have the bandwidth to work on yet another piece of serial hardware (I'm currently working on preliminary IPMI 1.5 over LAN support) If you do decide to take this on, let me know.. I'd be happy to provide whatever EMP related assistance I can... -san -----Original Message----- From: 'Ard van Breemen' [mailto:ar...@te...] Sent: Wednesday, July 25, 2001 5:13 AM To: San Mehat Cc: sa...@va...; vac...@li... Subject: Re: [Vacm-general] Slow EMP handling On Tue, Jul 24, 2001 at 11:29:06AM -0700, San Mehat wrote: > We had done some initial investigating into the cyclades product to see > if this exact thing could be done... basically it appears that the box > is too underpowered to drive all the ports with the EMP state machine.. Hmmm, that is weird: I guess that with a 50MHz ppc, it is very easy to control 32 serial ports. > We noticed that the machine was so underpowered that it was taking a few > seconds for a connection to be acknowledged as closed by the box.. so > the port that was being listened() on was showing a connection *well* > after shutdown() was called on the socket.... not good... Well, time to look at the source code then.... Hmmm, hands start itching.. It sounds like somebody has programmed the box to generate interrupts for every port. This results on 19.2k (the emp speed) in 1920 interrupts per port per second, that is about 61440 interrupts... Even a pentium will not be able to handle that. > The cyclades box looks to be a good solution for serial console > redirection.. but it just doesn't look like it has the horsepower for > managing the EMP state machine.... Just a question of software.... Like in the old days. Then they did the same, just with less hardware :). > -san > Nope, all of the software that runs on the Cyclades TS1000 (16 port) and > TS2000 (32 port) term servers is open source. The main piece of software > that manages the ports is portslave or pslave. If you are curious the > flash image of exactly what is on them is available for download from > the Cyclades ftp site. Yes! Cool! Now I need the Cyclades itself, and unfortunately we already have serial console systems, so I cannot request one for my work :(... -- <ar...@te...> Telegraaf Elektronische Media http://wwwijzer.nl http://leerquoten.monster.org/ http://www.faqs.org/rfcs/rfc1855.html Let your government know you value your freedom. Sign the petition: http://petition.eurolinux.org/ |