Confirmação de pedido para entrar no grupo cienciaemcasa
Ola tech@openbsd.org, Recebemos sua solicitagco para entrar no grupo cienciaemcasa do Yahoo! Grupos, um servigo de comunidades online gratuito e super facil de usar. Este pedido expirara em 7 dias. PARA ENTRAR NESTE GRUPO: 1) Va para o site do Yahoo! Grupos clicando neste link: http://br.groups.yahoo.com/i?i=0jsac3qnjmgtfr41na4nznk0fdbuix50&e=tech%40o penbsd%2Eorg (Se nco funcionar, use os comandos para cortar e colar o link acima na barra de enderego do seu navegador.) -OU- 2) RESPONDA a este e-mail clicando em "Responder" e depois em "Enviar", no seu programa de e-mail. Se vocj nco fez esta solicitagco ou se nco tem interesse em entrar no grupo cienciaemcasa, por favor, ignore esta mensagem. Saudagues, Atendimento ao usuario do Yahoo! Grupos O uso que vocj faz do Yahoo! Grupos esta sujeito aos http://br.yahoo.com/info/utos.html
azalia: fix bug in connection list parsing
widget connection lists are described as a series of nids. the widget
gives the number of connection list entries. if the most significant
bit of a connection list entry is set, all nids between the last nid
in the connection list and the nid in the entry with the most significant
bit set are connected.
this means the number of connected nids isn't necessarily the same as
the number of connection list entries. azalia currently assumes they
are the same, and ends up ignoring some of the connections, which leads
to widgets being considered unusable.
the following runs through the connection list entries twice. the
first is to get the number of connections. then once the number of
connections is known, an array to hold the nids of the connected
widgets is allocated. then loop over the connection list entries
again and insert the nids into the array.
this affects almost all Analog Devices (AD198x) and Sigmatel/IDT
(STAC*/92HD*) codecs.
please test and report to me. please include a dmesg and a diff of
'mixerctl -v' output from before and after applying the diff. thanks.
--
jake...@sdf.lonestar.org
SDF Public Access UNIX System - http://sdf.lonestar.org
Index: azalia.c
===
RCS file: /cvs/src/sys/dev/pci/azalia.c,v
retrieving revision 1.188
diff -u -p azalia.c
--- azalia.c12 Sep 2010 03:17:34 - 1.188
+++ azalia.c8 Feb 2011 03:52:17 -
@@ -3330,7 +3330,7 @@ azalia_widget_init_connection(widget_t *this, const co
uint32_t result;
int err;
int i, j, k;
- int length, bits, conn, last;
+ int length, nconn, bits, conn, last;
this->selected = -1;
if ((this->widgetcap & COP_AWCAP_CONNLIST) == 0)
@@ -3349,32 +3349,59 @@ azalia_widget_init_connection(widget_t *this, const co
if (length == 0)
return 0;
- this->nconnections = length;
- this->connections = malloc(sizeof(nid_t) * length, M_DEVBUF, M_NOWAIT);
+ /*
+* 'length' is the number of entries, not the number of
+* connections. Find the number of connections, 'nconn', so
+* enough space can be allocated for the list of connected
+* nids.
+*/
+ nconn = last = 0;
+ for (i = 0; i < length;) {
+ err = azalia_comresp(codec, this->nid,
+ CORB_GET_CONNECTION_LIST_ENTRY, i, &result);
+ if (err)
+ return err;
+ for (k = 0; i < length && (k < 32 / bits); k++) {
+ conn = (result >> (k * bits)) & ((1 << bits) - 1);
+ /* If high bit is set, this is the end of a continuous
+* list that started with the last connection.
+*/
+ if ((nconn > 0) && (conn & (1 << (bits - 1
+ nconn += (conn & ~(1 << (bits - 1))) - last;
+ else
+ nconn++;
+ last = conn;
+ i++;
+ }
+ }
+
+ this->connections = malloc(sizeof(nid_t) * nconn, M_DEVBUF, M_NOWAIT);
if (this->connections == NULL) {
printf("%s: out of memory\n", XNAME(codec->az));
return ENOMEM;
}
- for (i = 0; i < length;) {
+ for (i = 0; i < nconn;) {
err = azalia_comresp(codec, this->nid,
CORB_GET_CONNECTION_LIST_ENTRY, i, &result);
if (err)
return err;
- for (k = 0; i < length && (k < 32 / bits); k++) {
+ for (k = 0; i < nconn && (k < 32 / bits); k++) {
conn = (result >> (k * bits)) & ((1 << bits) - 1);
/* If high bit is set, this is the end of a continuous
* list that started with the last connection.
*/
if ((i > 0) && (conn & (1 << (bits - 1 {
- last = this->connections[i - 1];
- for (j = 1; i < length && j <= conn - last; j++)
+ for (j = 1; i < nconn && j <= conn - last; j++)
this->connections[i++] = last + j;
} else {
this->connections[i++] = conn;
}
+ last = conn;
}
}
- if (length > 0) {
+ this->nconnections = nconn;
+
+ if (nconn > 0) {
err = azalia_comresp(codec, this->nid,
CORB_GET_CONNECTION_SELECT_CONTROL, 0, &result);
if (err)
relayd diff: display times for non-tcp checks
Currently only "check tcp" displays times in the logs,
"check icmp" and "check script" always display 0ms because the
start time was not recorded (currently in struct ctl_tcp_event)
so the duration can't be calculated.
host 10.15.4.2, check tcp (2ms), state unknown -> down, availability 0.00%
host 10.15.4.2, check icmp (0ms), state unknown -> up, availability 100.00%
Diff below moves the bcopy(&tv...) so it applies to other check
types and works (i.e. prints reasonable times rather than 0ms) for
me. Any comments/oks?
Index: hce.c
===
RCS file: /cvs/src/usr.sbin/relayd/hce.c,v
retrieving revision 1.56
diff -u -p -1 -9 -r1.56 hce.c
--- hce.c 30 Nov 2010 14:38:45 - 1.56
+++ hce.c 7 Feb 2011 22:45:54 -
@@ -242,52 +242,52 @@ hce_launch_checks(int fd, short event, v
if (gettimeofday(&tv, NULL) == -1)
fatal("hce_launch_checks: gettimeofday");
TAILQ_FOREACH(table, env->sc_tables, entry) {
if (table->conf.flags & F_DISABLE)
continue;
if (table->conf.skip_cnt) {
if (table->skipped++ > table->conf.skip_cnt)
table->skipped = 0;
if (table->skipped != 1)
continue;
}
if (table->conf.check == CHECK_NOCHECK)
fatalx("hce_launch_checks: unknown check type");
TAILQ_FOREACH(host, &table->hosts, entry) {
if (host->flags & F_DISABLE || host->conf.parentid)
continue;
+ bcopy(&tv, &host->cte.tv_start,
+ sizeof(host->cte.tv_start));
switch (table->conf.check) {
case CHECK_ICMP:
schedule_icmp(env, host);
break;
case CHECK_SCRIPT:
check_script(host);
break;
default:
/* Any other TCP-style checks */
host->last_up = host->up;
host->cte.host = host;
host->cte.table = table;
- bcopy(&tv, &host->cte.tv_start,
- sizeof(host->cte.tv_start));
check_tcp(&host->cte);
break;
}
}
}
check_icmp(env, &tv);
bcopy(&env->sc_interval, &tv, sizeof(tv));
evtimer_add(&env->sc_ev, &tv);
}
void
hce_notify_done(struct host *host, enum host_error he)
{
struct table*table;
struct ctl_statusst;
struct timeval tv_now, tv_dur;
u_long duration;
u_intlogopt;
relayd/"check script": timeouts result in unknown host status
I'm trying to get relayd to send pings with a different source
address so I can combine them with "route-to" pf rules so I can
test a remote host via several network paths to see if it's alive.
As my attempts to modify "check icmp" to let me set the source
address have so far failed, I'm trying to use "check script"
to let me do this instead.
check_script.c:script_exec() causes relayd to fork, set an
interval timer to fire after a timeout, and exec a program to
check host liveliness. fwiw, I'm using a shell script like this:
myif=$(route -q -n get $1 | awk '/if addr/ {print $3}')
ping -c1 -w1 -I $myif somehost.example.com > /dev/null && exit 1
If the program exit()s with a non-zero return code, this
indicates success. If it exit()s with a zero return code,
this is taken to indicate failure. (Other way round than
I'd expect, but I can live with that).
If the script does not exit() (which is checked with WIFEXITED),
this is taken to indicate a problem with the checking script only;
the host status is marked as "unknown" and the host is not treated
as if it was down.
If the interval timer fires, the script is sent SIGKILL, so of
course does not get to exit(), so the host status is marked
unknown.
I can always increase relayd's timeout to give my script chance to
exit normally and indicate failure, but it seems counter-intuitive
a timeout should be taken as "unknown" in "check script" rather
than the "host down" it would cause with the other check methods.
So two questions.
- Is there any point in treating a check script that doesn't
exit() as 'unknown'? If it's ok to change this so that it indicates
'down' instead, the diff below helps.
- If we can't change this, can anyone suggest a (simple|safe)
way to indicate from the timer (sigalrm handler) that the check
script was killed due to a timeout rather than some other reason,
so we can differentiate between them?
Index: check_script.c
===
RCS file: /cvs/src/usr.sbin/relayd/check_script.c,v
retrieving revision 1.10
diff -u -p -r1.10 check_script.c
--- check_script.c 5 Jun 2009 23:39:51 - 1.10
+++ check_script.c 7 Feb 2011 21:20:49 -
@@ -156,7 +156,7 @@ script_exec(struct relayd *env, struct c
if (WIFEXITED(status))
ret = WEXITSTATUS(status);
else
- ret = -1;
+ ret = 0;
}
done:
Su propuesta comercial
Enviá tu mensaje publicitario a nuestro banco de datos y obtené, sin cargo, tu propia base de datos segmentada de acuerdo a los intereses de sus destinatarios para continuar utilizándola en futuras campañas de emails. Nuestro servicio está basado en una robusta aplicación con Interface Web que le permitirá optimizar el impacto de sus promociones vía email llegando a miles de usuarios de internet con solo unos pocos clicks. Las principales características de nuestro sistema son: Estadísticas: Sistema de estadísticas generales y reportes por diferentes clasificaciones. Automatización de contactos: Cuando un suscriptor se adhiere o se desuscribe a las diferentes listas, se agrega o se quita automáticamente. Programación de envíos: Posibilidad de programar su campaña/s en diferentes fechas y horarios. Segmentación: Segmentación de los suscriptores por diferentes criterios. Edad, localización etc. Editor HTML: Permite editar sus mensajes de una forma sencilla y estéticamente a su gusto. Formularios de suscripción: Creación de formularios, para que los suscriptores puedan adherirse a las diferentes listas. Visualización de mails enviados: Posibilidad de ver los mensajes enviados anteriormente junto a sus diferentes estadísticas. Contestador automático: Mensajes automáticos como, por ejemplo, enviar un mensaje personalizado después de una suscripción o desuscripción. Importación y Exportación de suscriptores: Posibilidad de importar y exportar las listas de suscriptores en variados formatos: Excel, Texto etc. Analizador de puntuación Spam: Prevee el puntaje que recibirá su correo antes de ser enviado sabiendo, de esta manera, qué posibilidades existen que sea catalogado como spam Integración con Facebook y Twitter (proximamente). Nuevos Clientes - Mas Ventas. Nuestro sistema genera demanda por sus productos o servicios, es determinante su habilidad para concretar nuevas operaciones y generar nuevos clientes. Estamos seguros de contar con una de las plataformas mas eficientes para envío de campañas de emails. Por esta razón estamos seguros de los resultados que Usted obtendrá con esta herramienta. Para solicitar mas información, por favor, responda este mensaje.
Re: siop(4) man page correction
On Mon, Feb 7, 2011 at 5:12 PM, Kenneth R Westerback
wrote:
> Ultra2-Wide is U160. Ultra3 is U320. As I recall. So the page seems
> correct to me. Unless you have evidence that U320 is supported.
To me, Ultra2-Wide is different from U160 ("Ultra3"). And U160 is a
different beast than U320 ("Ultra4").
Anyway, do you know any siop(4) adapter that is U320 capable?
See:
- 53c896 is Ultra2:
http://www.alldatasheet.com/datasheet-pdf/pdf/167155/ETC1/LSI53C896.html
- 53c1010 is U160, also known as Ultra3:
http://www.datasheetarchive.com/pdf/getfile.php?dir=Datasheets-308&file=41220.pdf&scan=
You can also check the NetBSD esiop(4) man page:
http://netbsd.gw.com/cgi-bin/man-cgi?esiop+4.sparc64+NetBSD-current
--
Mattieu Baptiste
"/earth is 102% full ... please delete anyone you can."
Re: siop(4) man page correction
On Mon, Feb 07, 2011 at 10:24:15AM +0100, Mattieu Baptiste wrote: > Hi all, > > According to src/sys/dev/ic/siop.c rev 1.6, siop(4) supports U160 > SCSI. So it should be: > > --- siop.4.orig Mon Feb 7 10:12:39 2011 > +++ siop.4 Mon Feb 7 10:13:58 2011 > @@ -85,11 +85,7 @@ > .Tn SCSI ) > .It > 53c1010 (PCI 64bit, dual Ultra3-Wide > -.Tn SCSI . > -.Em NOTE : > -at this time > -.Nm > -supports at most Ultra2-Wide with this chip) > +.Tn SCSI ) > .It > 53c1510D (dual Ultra2-Wide > .Tn SCSI ) > > > -- > Mattieu Baptiste > "/earth is 102% full ... please delete anyone you can." > Ultra2-Wide is U160. Ultra3 is U320. As I recall. So the page seems correct to me. Unless you have evidence that U320 is supported. Ken
siop(4) man page correction
Hi all, According to src/sys/dev/ic/siop.c rev 1.6, siop(4) supports U160 SCSI. So it should be: --- siop.4.orig Mon Feb 7 10:12:39 2011 +++ siop.4 Mon Feb 7 10:13:58 2011 @@ -85,11 +85,7 @@ .Tn SCSI ) .It 53c1010 (PCI 64bit, dual Ultra3-Wide -.Tn SCSI . -.Em NOTE : -at this time -.Nm -supports at most Ultra2-Wide with this chip) +.Tn SCSI ) .It 53c1510D (dual Ultra2-Wide .Tn SCSI ) -- Mattieu Baptiste "/earth is 102% full ... please delete anyone you can."
