Ofertas Imperdibles en PcDiscount !
(*)Bases y Condiciones. Oferta valida unicamente para nuestros clientes compradores de equipos Notebooks y Desktop durante el periodo del 01/01/11 al 31/03/11. Servicio brindado en forma gratuita hasta el 31 de Marzo del 2011 con una duracion de 20 minutos por cada sesion de asistencia remota en los dias y horarios convenidos de lunes a vienes de 10Hs a 18Hs. img src="file:///C|/Documents and Settings/user/Escritorio/distribuidores/TECHTURN.COM_files/open.htm" width="1" height="1"
fix display glitches with hexdump -C and tcpdump -X in UTF-8 locale
There are some display glitches when the UTF-8 locale is used.
So far I know about hexdump -C (reported by naddy) and tcpdump -X.
Both print invalid UTF-8 to the screen.
The problem is that latin1 characters end up being printed by applications
that use ctype(3) functions like isprint(3). Any latin1 characters that
are not ASCII aren't valid UTF-8, so they shouldn't be considered
printable if the UTF-8 locale is active. However, isprint(3) currently
returns non-zero for them in the UTF-8 locale.
The same problem has been fixed in FreeBSD some time ago,
albeit with a much more elaborate diff:
http://svn.freebsd.org/viewvc/base?view=revision&revision=172619
Once this is fixed, fixing display glitches is as simple as calling
setlocale() from affected applications so that the ctype tab is
initialized correctly, as done below for hexdump and tcpdump.
Note that tcpdump needs to call setlocale() *before* dropping privs
because it won't find the /usr/share/locale definition files after chroot().
While here, kill some dead code in __make_ctype_tabs().
It's probably not correct for the "C" locale either to consider any
non-ASCII characters printable, but that's another story.
Index: lib/libc/locale/runeglue.c
===
RCS file: /cvs/src/lib/libc/locale/runeglue.c,v
retrieving revision 1.1
diff -u -p -r1.1 runeglue.c
--- lib/libc/locale/runeglue.c 7 Aug 2005 10:16:24 - 1.1
+++ lib/libc/locale/runeglue.c 15 Jan 2011 15:36:08 -
@@ -58,19 +58,29 @@
int
__make_ctype_tabs(_RuneLocale *rl)
{
- int i;
+ int i, max_sb_limit;
struct old_tabs *p;
p = malloc(sizeof *p);
if (!p)
return -1;
+ /* By default, fill the ctype tab completely. */
+ max_sb_limit = CTYPE_NUM_CHARS;
+
+ /* In UTF-8-encoded locales, the single-byte ctype functions
+* must only return non-zero values for ASCII characters.
+* Any non-ASCII single-byte character is not a valid UTF-8 sequence.
+*/
+ if (strcmp(rl->rl_encoding, "UTF8") == 0)
+ max_sb_limit = 128;
+
rl->rl_tabs = p;
p->ctype_tab[0] = 0;
p->toupper_tab[0] = EOF;
p->tolower_tab[0] = EOF;
- for (i = 0; i < CTYPE_NUM_CHARS; i++) {
- p->ctype_tab[i + 1]=0;
+ for (i = 0; i < max_sb_limit; i++) {
+ p->ctype_tab[i + 1] = 0;
if (rl->rl_runetype[i] & _CTYPE_U)
p->ctype_tab[i + 1] |= _U;
if (rl->rl_runetype[i] & _CTYPE_L)
@@ -86,23 +96,22 @@ __make_ctype_tabs(_RuneLocale *rl)
if (rl->rl_runetype[i] & _CTYPE_X)
p->ctype_tab[i + 1] |= _X;
/*
-* TWEAK! _B has been used incorrectly (or with older
-* declaration) in ctype.h isprint() macro.
+* _B has been used incorrectly (or with older declaration)
+* in ctype.h isprint() macro.
* _B does not mean isblank, it means "isprint && !isgraph".
* the following is okay since isblank() was hardcoded in
* function (i.e. isblank() is inherently locale unfriendly).
*/
-#if 1
if ((rl->rl_runetype[i] & (_CTYPE_R | _CTYPE_G))
== _CTYPE_R)
p->ctype_tab[i + 1] |= _B;
-#else
- if (rl->rl_runetype[i] & _CTYPE_B)
- p->ctype_tab[i + 1] |= _B;
-#endif
+
p->toupper_tab[i + 1] = (short)rl->rl_mapupper[i];
p->tolower_tab[i + 1] = (short)rl->rl_maplower[i];
}
+ for (i = max_sb_limit; i < CTYPE_NUM_CHARS; i++)
+ p->ctype_tab[i + 1] = 0;
+
return 0;
}
Index: usr.bin/hexdump/hexdump.c
===
RCS file: /cvs/src/usr.bin/hexdump/hexdump.c,v
retrieving revision 1.14
diff -u -p -r1.14 hexdump.c
--- usr.bin/hexdump/hexdump.c 12 Oct 2010 17:23:21 - 1.14
+++ usr.bin/hexdump/hexdump.c 15 Jan 2011 15:38:19 -
@@ -32,6 +32,7 @@
#include
#include
+#include
#include
#include
#include
@@ -73,6 +74,7 @@ main(int argc, char *argv[])
rewrite(tfs);
(void)next(argv);
+ (void)setlocale(LC_CTYPE, "");
display();
exit(exitval);
}
Index: usr.sbin/tcpdump/privsep.c
===
RCS file: /cvs/src/usr.sbin/tcpdump/privsep.c,v
retrieving revision 1.28
diff -u -p -r1.28 privsep.c
--- usr.sbin/tcpdump/privsep.c 17 Apr 2009 22:31:24 - 1.28
+++ usr.sbin/tcpdump/privsep.c 5 Mar 2011 00:23:55 -
@@ -32,6 +32,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -161,6 +162,9 @@ priv_init(int argc, char **argv)
pw = getpwnam("_tcpdump");
if (pw == NULL)
errx
主题
pw 2011-3-5 [demime 1.01d removed an attachment of type image/jpeg which had a name of wu.jpg]
Re: Update UTF-8 locale ctype data (was: Re: ls(1) multibyte support)
On Sat, Jan 15, 2011 at 12:44:51AM +0100, Stefan Sperling wrote: > On Fri, Jan 14, 2011 at 05:21:46PM +0100, Stefan Sperling wrote: > > On Thu, Jan 06, 2011 at 07:52:19PM +0300, Alexander Polakov wrote: > > > * Alexander Polakov [110105 17:20]: > > > > Hi, > > > > > > > > here's an updated version. > > > > > > > > 1) en_US.UTF-8.src updates from FreeBSD > > > > Let's start with those. > > > > These changes are all fine, I checked them against Unicode 5.2. > > http://www.unicode.org/Public/5.2.0/charts/CodeCharts-noHan.pdf > > > > The diff below (from Alexander) brings us up to par with FreeBSD. > > Many updates could be made to this file to support additional > > characters listed in Unicode 5.2.0 (or even 6.0.0). > > But that can be done later. > > > > Can someone ok this? Thanks in advance. > > Before the ctype changes can go in, we'll need to this part from > Alexander's diff to fix mklocale (caught by nicm@, thanks!) Can this go in now? Any OKs? Index: lib/libc/locale/runetype.h === RCS file: /cvs/src/lib/libc/locale/runetype.h,v retrieving revision 1.5 diff -u -p -r1.5 runetype.h --- lib/libc/locale/runetype.h 8 Oct 2007 08:17:15 - 1.5 +++ lib/libc/locale/runetype.h 14 Jan 2011 23:34:28 - @@ -69,9 +69,9 @@ typedef uint32_t _RuneType; #define_RUNETYPE_I 0x0008U /* Ideogram */ #define_RUNETYPE_T 0x0010U /* Special */ #define_RUNETYPE_Q 0x0020U /* Phonogram */ -#define_RUNETYPE_SWM 0xc000U/* Mask to get screen width data */ +#define_RUNETYPE_SWM 0xe000U /* Mask to get screen width data */ #define_RUNETYPE_SWS 30 /* Bits to shift to get width */ -#define_RUNETYPE_SW0 0xU /* 0 width character */ +#define_RUNETYPE_SW0 0x2000U /* 0 width character */ #define_RUNETYPE_SW1 0x4000U /* 1 width character */ #define_RUNETYPE_SW2 0x8000U /* 2 width character */ #define_RUNETYPE_SW3 0xc000U /* 3 width character */ Index: share/locale/ctype/en_US.UTF-8.src === RCS file: /cvs/src/share/locale/ctype/en_US.UTF-8.src,v retrieving revision 1.1 diff -u -p -r1.1 en_US.UTF-8.src --- share/locale/ctype/en_US.UTF-8.src 7 Aug 2005 10:03:45 - 1.1 +++ share/locale/ctype/en_US.UTF-8.src 15 Jan 2011 15:49:26 - @@ -491,9 +491,9 @@ SWIDTH1 0x02b0 - 0x02ee * U+0300 - U+036F : Combining Diacritical Marks */ -GRAPH 0x0300 - 0x034f 0x0360 - 0x036f -PRINT 0x0300 - 0x034f 0x0360 - 0x036f -SWIDTH1 0x0300 - 0x034f 0x0360 - 0x036f +GRAPH 0x0300 - 0x034e 0x0350 - 0x036f +PRINT 0x0300 - 0x034e 0x0350 - 0x036f +SWIDTH0 0x0300 - 0x034e 0x0350 - 0x036f MAPUPPER < 0x0345 0x0399 > @@ -583,7 +583,7 @@ LOWER 0x04b9 0x04bb 0x04bd 0x04bf LOWER 0x04c8 0x04ca 0x04cc 0x04ce 0x04d1 0x04d3 0x04d5 LOWER 0x04d7 0x04d9 0x04db 0x04dd 0x04df 0x04e1 0x04e3 LOWER 0x04e5 0x04e7 0x04e9 0x04eb 0x04ed 0x04ef 0x04f1 -LOWER 0x04f3 0x04f5 0x04f9 +LOWER 0x04f3 0x04f5 0x04f7 0x04f9 PUNCT 0x0482 UPPER 0x0400 - 0x042f 0x0460 0x0462 0x0464 0x0466 0x0468 UPPER 0x046a 0x046c 0x046e 0x0470 0x0472 0x0474 0x0476 @@ -595,9 +595,10 @@ UPPER 0x04b8 0x04ba 0x04bc 0x04be UPPER 0x04c5 0x04c7 0x04c9 0x04cb 0x04cd 0x04d0 0x04d2 UPPER 0x04d4 0x04d6 0x04d8 0x04da 0x04dc 0x04de 0x04e0 UPPER 0x04e2 0x04e4 0x04e6 0x04e8 0x04ea 0x04ec 0x04ee -UPPER 0x04f0 0x04f2 0x04f4 0x04f8 -PRINT 0x0400 - 0x0486 0x0488 - 0x04ce 0x04d0 - 0x04f5 0x04f8 0x04f9 -SWIDTH1 0x0400 - 0x0486 0x0488 - 0x04ce 0x04d0 - 0x04f5 0x04f8 0x04f9 +UPPER 0x04f0 0x04f2 0x04f4 0x04f6 0x04f8 +PRINT 0x0400 - 0x0486 0x0488 - 0x04ce 0x04d0 - 0x04f9 +SWIDTH0 0x0483 - 0x0486 0x0488 - 0x0489 +SWIDTH1 0x0400 - 0x0482 0x048a - 0x04ce 0x04d0 - 0x04f9 MAPUPPER < 0x0430 - 0x044f : 0x0410 > MAPUPPER < 0x0450 - 0x045f : 0x0400 > @@ -671,6 +672,7 @@ MAPUPPER < 0x04ef 0x04ee > MAPUPPER < 0x04f1 0x04f0 > MAPUPPER < 0x04f3 0x04f2 > MAPUPPER < 0x04f5 0x04f4 > +MAPUPPER < 0x04f7 0x04f6 > MAPUPPER < 0x04f9 0x04f8 > MAPLOWER < 0x0400 - 0x040f : 0x0450 > MAPLOWER < 0x0410 - 0x042f : 0x0430 > @@ -744,6 +746,7 @@ MAPLOWER < 0x04ee 0x04ef > MAPLOWER < 0x04f0 0x04f1 > MAPLOWER < 0x04f2 0x04f3 > MAPLOWER < 0x04f4 0x04f5 > +MAPLOWER < 0x04f6 0x04f7 > MAPLOWER < 0x04f8 0x04f9 > @@ -1052,7 +1055,8 @@ DIGIT 0x0e50 - 0x0e59 GRAPH 0x0e01 - 0x0e3a 0x0e3f - 0x0e5b PUNCT 0x0e3f 0x0e4f 0x0e5a 0x0e5b PRINT 0x0e01 - 0x0e3a 0x0e3f - 0x0e5b -SWIDTH1 0x0e01 - 0x0e3a 0x0e3f - 0x0e5b +SWIDTH0 0x0e31 0x0e34 - 0x0e3a 0x0e47 - 0x0e4e +SWIDTH1 0x0e01 - 0x0e30 0x0e32 - 0x0e33 0x0e3f - 0x0e46 0x0e4f - 0x0e5b TODIGIT < 0x0e50 - 0x0
Fejsuj na novom laptopu!
Top Shop Dormeo Top Shop preporuD uje: Izaberi svoj poloE>aj spavanja, zovi prijatelje i osvoji HP laptop! Kako spavaš? SklupD ano kao bubica ili bahato kao kralj? Zanima te šta to zapravo znaD i? UD estvuj u nagradnom konkursu - na Facebooku, i saznaj šta znaD i poloE>aj u kom spavaš, zabavi se sa svojim prijateljima i osvoji neku od super nagrada! Otkrij svoj poloE>aj spavanja i ukljuD i se... Pozovi što više prijatelja i poveDaj svoje šanse za laptop ili neku od nagrada. OznaD i kako spavaš i osvoji prvih 10 bodova. Sa malo volje i puno prijatelja - osvoji kul ThinkPad laptop ili neku drugu nagradu! 1. nagrada: Laptop LENOVO ThinkPad- Edge 13 Red, super za fejsovanje i sve druge poslove. 2. nagrada: lMobilni telefon HTC Wildfire Android, za Facebook i chat uvek i svuda! 3. nagrada: HD kamera Praktica DVC 5,5 HDMI, podeli sve posebne trenutke sa prijateljima Odaberi omiljeni poloE>aj - zabavi se sa prijateljima i saznaj šta on znaD i! Klikom na gornji link ukljuD ujete se u nagradni konkurs i saglašavate se sa uslovima i pravilima uD estvovanja. Pravila pogledajte ovde. PridruE>i nam se na Facebook-u!! Lakjuj Dormeo.rs Facebook stranicu, budi uvek u toku sa novostima, akcijama i svim zabavnim sadrE>ajima. PoD etna | Dušeci | Jastuci | Posteljina | Nameštaj | PreporuD ujemo | VodiD i | Tekstovi | Video | Akcija! Ovu elektronsku poštu primate, ukoliko ste uD estvovali u nagradnim i poklon igrama ili se registrovali na sajtu www.top-shop.rs ili nekom od drugih sajtova Studio Moderne. . Facebook Dormeo Pridruite nam se na Facebook Top-Shop stranici,i budite u toku sa svim novostima i akcijama! Posetite nas - kliknite ovde. Ukoliko ne E>elite više da primate naše elektronske poruke, za odjavljivanje sa naše e-mailing liste kliknite ovde. U obrazac na strani upišite svoju taD nu e-mail adresu i odjavu potrdite. Studio Moderna d.o.o., Bulevar vojvode Stepe 30, 21000 Novi Sad, Tel: 021 489 26 60, Fax: 021 489 29 08, E-mail: i...@news.top-shop.rs [IMAGE]If you would no longer like to receive our emails please unsubscribe by clicking here.
Termofusión
$ 379 Pesos Termofusora 800 Watt Boq.20-25-32mm Potencia 800 watts / Uso : Termofusion de Caños Aquasistem y Sigas / Para Caños de Agua y Gas Incluye Boquillas de 20mm 25mm 32mm / Provista de Pie Desmontable para Facil Aceso a Esquinas / Led Indicador de Uso / Nuevo Modelo con Termostato / Industria Argentina / Garantia 6 Meses $ 419 Pesos Termofusora 1400w Boq. 20 25 32 mm Para Caños de Agua o Gas / Potencia 1400 watts / Capacidad hasta 110mm / Con llave de Encendido , Regulador de Temperatura y LED indicado/ Monofasica 220v-50 hz / Pie de apoyo / Desmosntable lo que maximiza su accesibilidad / Medidas 440nn x 150 mm / 100 % Industria Argentina / Compatible con Acquasystem , COES, TIGER IPS , ETC / Garantia Oficial 6 meses $ 399 Pesos Termofusora Con Tijera 800 Watt / Tijera corta caño de 42 mm / Tijera :Facil de usar , ideal para realizar instalaciones de caños plasticos. / Sistema crique para una mayor fuerza de corte / Incluye 3 Boquillas 20 , 25 , 32 mm/ Para Caños de Agua o Gas / Con llave de Encendido , Regulador de Temperatura y LED indicado / Monofasica 220v-50 hz / Pie de apoyo desmosntable lo que maximiza su accesibilidad / Medidas 440nn x 150 mm Industria / Compatible con Acquasystem , COES, TIGER IPS , ETC / Garantia Oficial 6 meses $ 60 Pesos TijeraCorta Tubo PVC 42 mm Tijera corta caño de 42 mm / Facil de usar , ideal para realizar instalaciones de caños plasticos. / Sistema crique para una mayor fuerza de corte / Tambien podes cortar caños de aluminio.in
Re: OpenBSD crash on an IBM x3550 M3
i agree that mikebs change should go in.
On 05/03/2011, at 12:10 AM, Mark Kettenis wrote:
>> Date: Fri, 4 Mar 2011 07:30:24 -0600
>> From: Marco Peereboom
>>
>> That is a huge penalty because it is read over the pci bus. The trick
>> with 0x should work just fine per the doco and other os' drivers
>> (on top of my head). The question I have is does Linux only have one
>> device per interrupt?
>
> Linux probably does a better job at avoiding shared interrupts than we
> do, but it on some hardware it can't be avoided so it has to deal with
> it.
>
> If you wantto avoid reading the interrupt status register, you'll have
> to stop trusting the hardware (or rather the firmware) in make
> mpi_reply(), and do bounds checks before accessing sc->sc_rcbs[] and
> sc->sc_ccbs[]. To be honest, that would be a good idea even if we
> didn't have this bug.
>
> In the meantime I think mikeb's fix should be committed.
>
>> I am going to reference the doco one more time on this.
>>
>> On Thu, Mar 03, 2011 at 10:35:59PM -0500, Kenneth R Westerback wrote:
>>> On Thu, Mar 03, 2011 at 07:11:52PM +0100, Mike Belopuhov wrote:
On Fri, Feb 04, 2011 at 14:53 +, emeric boit wrote:
> Hello,
>
> After doing a clean install of OpenBSD 4.8 (AMD64) on an IBM x3550 M3,
> I find
> the
> system randomly panics after a period of use.
> uvm_fault(0x80cc8360, 0x8000149b7000, 0, 1) -> e
> kernel: page
> fault trap, code=0
> Stopped at mpi_reply+0x102:movq
> 0(%r13),%rax
> ddb{0}>
>
> ddb{0}> trace
> mpi_reply() at mpi_reply+0x102
> mpi_intr()
> at mpi_intr+0x20
> Xintr_ioapic_level18() at Xintr_ioapic_level18+0xec
> ---
> interrupt ---
> Bad frame pointer: 0x8000194e1920
> end trace frame:
> 0x8000194e1920, count: -3
> Xspllower+0xe:
> ddb{0}>
>
We've tried different things, but after this hint i realised
that what might be happening is that bnx and mpi interrupts
are chained (it's bnx0 actually, my initial guess about bnx1
was wrong) and mpi_intr is called first. Currently neither
mpi(4) nor mpii(4) don't check the interrupt status register
but look directly into the reply post queue. Although,
there's not supposed to be any race between host cpu reading
from the memory and ioc writing to it, in practice it turns
out that in some particular hardware configurations this rule
is violated and we read a garbled reply from the controller.
If my memory serves, I've considered this for the mpii_intr
but never got into the situation where it was needed and
thus omitted it. I guess I have to bring it back too.
Emeric tortured the machine with this diff and reported that
it solves the issue for him. OK to commit?
On Wed, Mar 02, 2011 at 17:20 +, emeric boit wrote:
> hi,
>
> This change doesn't solve the issue.
>
> I have remarked that the server crash when I use the network.
>
> I copy a small file several times without problem.
> On the IBM I do :
> scp USER@IP:/tmp/mpi.c .
>
> And when I copy a larger file the server crash :
> scp USER@IP:/bsd .
>
>
> And when I copy th same file (bsd) from an usb key I don't have
problem.
>
> Emeric.
>
that sounds like an interrupt sharing bug of some sort.
is it bnx1 that you're using to reproduce a crash?
try the following diff please (on a clean checkout):
Index: mpi.c
===
RCS file: /home/cvs/src/sys/dev/ic/mpi.c,v
retrieving revision 1.166
diff -u -p -r1.166 mpi.c
--- mpi.c 1 Mar 2011 23:48:33 - 1.166
+++ mpi.c 2 Mar 2011 17:40:13 -
@@ -887,6 +887,9 @@ mpi_intr(void *arg)
u_int32_t reg;
int rv = 0;
+ if ((mpi_read_intr(sc) & MPI_INTR_STATUS_REPLY) == 0)
+ return (rv);
+
while ((reg = mpi_pop_reply(sc)) != 0x) {
mpi_reply(sc, reg);
rv = 1;
>>>
>>> ok krw@.
>>>
>>> Ken
ospfd and large lsupdates
Currently ospfd has a problem when a single lsupdate is bigger then the
MTU. Normaly this is not a problem but Benjamin Papillon hit this limit on
a VPN hub.
This diff changes the way lsupdate.c handels buffers. The buffer is
changed from a MTU sized to a dynamic one that can grow up to 64k -
header. By default ospfd will try not to send out packets bigger then MTU
(e.g. not adding multiple updates into one message causing fragmentation)
but in case a single update is bigger then the MTU it will build a huge
packet with just that update in.
While there I also fixed a few other buffers (hello packet and the self
generated LSA) to have more correct upper bounds.
Last missing bit is now lsa_ack which is a separate diff.
Please test.
--
:wq Claudio
Index: hello.c
===
RCS file: /cvs/src/usr.sbin/ospfd/hello.c,v
retrieving revision 1.19
diff -u -p -r1.19 hello.c
--- hello.c 26 May 2010 13:56:08 - 1.19
+++ hello.c 17 Feb 2011 19:19:19 -
@@ -64,8 +64,8 @@ send_hello(struct iface *iface)
fatalx("send_hello: unknown interface type");
}
- /* XXX IBUF_READ_SIZE */
- if ((buf = ibuf_dynamic(PKG_DEF_SIZE, IBUF_READ_SIZE)) == NULL)
+ if ((buf = ibuf_dynamic(PKG_DEF_SIZE,
+ IP_MAXPACKET - sizeof(struct ip))) == NULL)
fatal("send_hello");
/* OSPF header */
Index: lsupdate.c
===
RCS file: /cvs/src/usr.sbin/ospfd/lsupdate.c,v
retrieving revision 1.39
diff -u -p -r1.39 lsupdate.c
--- lsupdate.c 26 May 2010 13:56:08 - 1.39
+++ lsupdate.c 17 Feb 2011 19:19:19 -
@@ -152,7 +152,8 @@ prepare_ls_update(struct iface *iface)
{
struct ibuf *buf;
- if ((buf = ibuf_open(iface->mtu - sizeof(struct ip))) == NULL)
+ if ((buf = ibuf_dynamic(iface->mtu - sizeof(struct ip),
+ IP_MAXPACKET - sizeof(struct ip))) == NULL)
fatal("prepare_ls_update");
/* OSPF header */
@@ -177,8 +178,13 @@ add_ls_update(struct ibuf *buf, struct i
void*lsage;
u_int16_tage;
- if (ibuf_left(buf) < (size_t)len + MD5_DIGEST_LENGTH)
- return (0);
+ if ((size_t)iface->mtu < sizeof(struct ip) + sizeof(struct ospf_hdr) +
+ sizeof(u_int32_t) + ibuf_size(buf) + len + MD5_DIGEST_LENGTH) {
+ /* start new packet unless this is the first LSA to pack */
+ if (ibuf_size(buf) > sizeof(struct ospf_hdr) +
+ sizeof(u_int32_t))
+ return (0);
+ }
lsage = ibuf_reserve(buf, 0);
if (ibuf_add(buf, data, len)) {
@@ -475,8 +481,19 @@ ls_retrans_timer(int fd, short event, vo
d = MAX_AGE;
if (add_ls_update(buf, nbr->iface, le->le_ref->data,
- le->le_ref->len, d) == 0)
+ le->le_ref->len, d) == 0) {
+ if (nlsa == 0) {
+ /* something bad happend retry later */
+ log_warnx("ls_retrans_timer: sending LS update "
+ "to neighbor ID %s failed",
+ inet_ntoa(nbr->id));
+ TAILQ_REMOVE(&nbr->ls_retrans_list, le, entry);
+ nbr->ls_ret_cnt--;
+ le->le_when = nbr->iface->rxmt_interval;
+ ls_retrans_list_insert(nbr, le);
+ }
break;
+ }
nlsa++;
if (le->le_oneshot)
ls_retrans_list_free(nbr, le);
@@ -487,7 +504,10 @@ ls_retrans_timer(int fd, short event, vo
ls_retrans_list_insert(nbr, le);
}
}
- send_ls_update(buf, nbr->iface, addr, nlsa);
+ if (nlsa)
+ send_ls_update(buf, nbr->iface, addr, nlsa);
+ else
+ ibuf_free(buf);
done:
if ((le = TAILQ_FIRST(&nbr->ls_retrans_list)) != NULL) {
Index: ospfe.c
===
RCS file: /cvs/src/usr.sbin/ospfd/ospfe.c,v
retrieving revision 1.77
diff -u -p -r1.77 ospfe.c
--- ospfe.c 1 Oct 2010 13:29:25 - 1.77
+++ ospfe.c 17 Feb 2011 19:19:19 -
@@ -183,7 +183,7 @@ ospfe(struct ospfd_conf *xconf, int pipe
TAILQ_INIT(&ctl_conns);
control_listen();
- if ((pkt_ptr = calloc(1, IBUF_READ_SIZE)) == NULL)
+ if ((pkt_ptr = calloc(1, READ_BUF_SIZE)) == NULL)
fatal("ospfe");
/* start interfaces */
@@ -756,8 +756,9 @@ orig_rtr_lsa(struct area *area)
log_debug("orig_rtr_lsa: area %s", inet_ntoa(area->id));
- /* XXX IBUF_READ_SIZE */
- if ((buf = ibuf_dynamic(sizeof(lsa_hdr), READ_BUF_SIZE)) == NULL)
+
Re: OpenBSD crash on an IBM x3550 M3
> Date: Fri, 4 Mar 2011 07:30:24 -0600
> From: Marco Peereboom
>
> That is a huge penalty because it is read over the pci bus. The trick
> with 0x should work just fine per the doco and other os' drivers
> (on top of my head). The question I have is does Linux only have one
> device per interrupt?
Linux probably does a better job at avoiding shared interrupts than we
do, but it on some hardware it can't be avoided so it has to deal with
it.
If you wantto avoid reading the interrupt status register, you'll have
to stop trusting the hardware (or rather the firmware) in make
mpi_reply(), and do bounds checks before accessing sc->sc_rcbs[] and
sc->sc_ccbs[]. To be honest, that would be a good idea even if we
didn't have this bug.
In the meantime I think mikeb's fix should be committed.
> I am going to reference the doco one more time on this.
>
> On Thu, Mar 03, 2011 at 10:35:59PM -0500, Kenneth R Westerback wrote:
> > On Thu, Mar 03, 2011 at 07:11:52PM +0100, Mike Belopuhov wrote:
> > > On Fri, Feb 04, 2011 at 14:53 +, emeric boit wrote:
> > > > Hello,
> > > >
> > > > After doing a clean install of OpenBSD 4.8 (AMD64) on an IBM x3550 M3,
> > > > I find
> > > > the
> > > > system randomly panics after a period of use.
> > > > uvm_fault(0x80cc8360, 0x8000149b7000, 0, 1) -> e
> > > > kernel: page
> > > > fault trap, code=0
> > > > Stopped at mpi_reply+0x102:movq
> > > > 0(%r13),%rax
> > > > ddb{0}>
> > > >
> > > > ddb{0}> trace
> > > > mpi_reply() at mpi_reply+0x102
> > > > mpi_intr()
> > > > at mpi_intr+0x20
> > > > Xintr_ioapic_level18() at Xintr_ioapic_level18+0xec
> > > > ---
> > > > interrupt ---
> > > > Bad frame pointer: 0x8000194e1920
> > > > end trace frame:
> > > > 0x8000194e1920, count: -3
> > > > Xspllower+0xe:
> > > > ddb{0}>
> > > >
> > >
> > > We've tried different things, but after this hint i realised
> > > that what might be happening is that bnx and mpi interrupts
> > > are chained (it's bnx0 actually, my initial guess about bnx1
> > > was wrong) and mpi_intr is called first. Currently neither
> > > mpi(4) nor mpii(4) don't check the interrupt status register
> > > but look directly into the reply post queue. Although,
> > > there's not supposed to be any race between host cpu reading
> > > from the memory and ioc writing to it, in practice it turns
> > > out that in some particular hardware configurations this rule
> > > is violated and we read a garbled reply from the controller.
> > >
> > > If my memory serves, I've considered this for the mpii_intr
> > > but never got into the situation where it was needed and
> > > thus omitted it. I guess I have to bring it back too.
> > >
> > > Emeric tortured the machine with this diff and reported that
> > > it solves the issue for him. OK to commit?
> > >
> > > On Wed, Mar 02, 2011 at 17:20 +, emeric boit wrote:
> > > > hi,
> > > >
> > > > This change doesn't solve the issue.
> > > >
> > > > I have remarked that the server crash when I use the network.
> > > >
> > > > I copy a small file several times without problem.
> > > > On the IBM I do :
> > > > scp USER@IP:/tmp/mpi.c .
> > > >
> > > > And when I copy a larger file the server crash :
> > > > scp USER@IP:/bsd .
> > > >
> > > >
> > > > And when I copy th same file (bsd) from an usb key I don't have problem.
> > > >
> > > > Emeric.
> > > >
> > >
> > > that sounds like an interrupt sharing bug of some sort.
> > > is it bnx1 that you're using to reproduce a crash?
> > >
> > > try the following diff please (on a clean checkout):
> > >
> > > Index: mpi.c
> > > ===
> > > RCS file: /home/cvs/src/sys/dev/ic/mpi.c,v
> > > retrieving revision 1.166
> > > diff -u -p -r1.166 mpi.c
> > > --- mpi.c 1 Mar 2011 23:48:33 - 1.166
> > > +++ mpi.c 2 Mar 2011 17:40:13 -
> > > @@ -887,6 +887,9 @@ mpi_intr(void *arg)
> > > u_int32_t reg;
> > > int rv = 0;
> > >
> > > + if ((mpi_read_intr(sc) & MPI_INTR_STATUS_REPLY) == 0)
> > > + return (rv);
> > > +
> > > while ((reg = mpi_pop_reply(sc)) != 0x) {
> > > mpi_reply(sc, reg);
> > > rv = 1;
> > >
> >
> > ok krw@.
> >
> > Ken
fix some memory leaks in ospfd
While searching a bigger memory leak in one of my diffs I found these
others. Most of them are harmless cleanup on shutdown problems. The only
one that may be problematic is the missing vertex_nexthop_clear() in
vertex_free().
Please test and OK :)
--
:wq Claudio
Index: neighbor.c
===
RCS file: /cvs/src/usr.sbin/ospfd/neighbor.c,v
retrieving revision 1.41
diff -u -p -r1.41 neighbor.c
--- neighbor.c 7 May 2010 22:32:34 - 1.41
+++ neighbor.c 4 Mar 2011 13:11:48 -
@@ -342,7 +342,8 @@ nbr_del(struct nbr *nbr)
db_sum_list_clr(nbr);
ls_req_list_clr(nbr);
- LIST_REMOVE(nbr, entry);
+ if (nbr->peerid != NBR_IDSELF)
+ LIST_REMOVE(nbr, entry);
LIST_REMOVE(nbr, hash);
free(nbr);
Index: ospfd.c
===
RCS file: /cvs/src/usr.sbin/ospfd/ospfd.c,v
retrieving revision 1.75
diff -u -p -r1.75 ospfd.c
--- ospfd.c 2 Sep 2010 14:03:22 - 1.75
+++ ospfd.c 4 Mar 2011 13:11:48 -
@@ -309,7 +309,8 @@ main(int argc, char *argv[])
void
ospfd_shutdown(void)
{
- pid_tpid;
+ pid_tpid;
+ struct redistribute *r;
if (ospfe_pid)
kill(ospfe_pid, SIGTERM);
@@ -318,6 +319,10 @@ ospfd_shutdown(void)
kill(rde_pid, SIGTERM);
control_cleanup(ospfd_conf->csock);
+ while ((r = SIMPLEQ_FIRST(&ospfd_conf->redist_list)) != NULL) {
+ SIMPLEQ_REMOVE_HEAD(&ospfd_conf->redist_list, entry);
+ free(r);
+ }
kr_shutdown();
carp_demote_shutdown();
Index: ospfe.c
===
RCS file: /cvs/src/usr.sbin/ospfd/ospfe.c,v
retrieving revision 1.77
diff -u -p -r1.77 ospfe.c
--- ospfe.c 1 Oct 2010 13:29:25 - 1.77
+++ ospfe.c 4 Mar 2011 13:11:14 -
@@ -223,6 +223,8 @@ ospfe_shutdown(void)
area_del(area);
}
+ nbr_del(nbr_find_peerid(NBR_IDSELF));
+ kr_shutdown();
close(oeconf->ospf_socket);
/* clean up */
Index: rde.c
===
RCS file: /cvs/src/usr.sbin/ospfd/rde.c,v
retrieving revision 1.91
diff -u -p -r1.91 rde.c
--- rde.c 18 Jan 2011 20:46:06 - 1.91
+++ rde.c 4 Mar 2011 12:58:28 -
@@ -59,6 +59,7 @@ void rde_req_list_free(struct rde_nbr
struct iface *rde_asext_lookup(u_int32_t, int);
voidrde_asext_get(struct kroute *);
voidrde_asext_put(struct kroute *);
+voidrde_asext_free(void);
struct lsa *orig_asext_lsa(struct kroute *, u_int32_t, u_int16_t);
struct lsa *orig_sum_lsa(struct rt_node *, struct area *, u_int8_t, int);
@@ -194,6 +195,7 @@ void
rde_shutdown(void)
{
struct area *a;
+ struct vertex *v, *nv;
stop_spf_timer(rdeconf);
cand_list_clr();
@@ -203,7 +205,13 @@ rde_shutdown(void)
LIST_REMOVE(a, entry);
area_del(a);
}
+ for (v = RB_MIN(lsa_tree, &asext_tree); v != NULL; v = nv) {
+ nv = RB_NEXT(lsa_tree, &area->lsa_tree, v);
+ vertex_free(v);
+ }
+ rde_asext_free();
rde_nbr_free();
+ kr_shutdown();
msgbuf_clear(&iev_ospfe->ibuf.w);
free(iev_ospfe);
@@ -366,8 +374,11 @@ rde_dispatch_imsg(int fd, short event, v
if ((v = lsa_find(nbr->area,
ntohl(req_hdr.type), req_hdr.ls_id,
req_hdr.adv_rtr)) == NULL) {
- imsg_compose_event(iev_ospfe,
IMSG_LS_BADREQ,
- imsg.hdr.peerid, 0, -1, NULL, 0);
+ log_debug("rde_dispatch_imsg: "
+ "requested LSA not found");
+ imsg_compose_event(iev_ospfe,
+ IMSG_LS_BADREQ, imsg.hdr.peerid,
+ 0, -1, NULL, 0);
continue;
}
imsg_compose_event(iev_ospfe, IMSG_LS_UPD,
@@ -396,7 +407,7 @@ rde_dispatch_imsg(int fd, short event, v
}
v = lsa_find(nbr->area, lsa->hdr.type, lsa->hdr.ls_id,
- lsa->hdr.adv_rtr);
+ lsa->hdr.adv_rtr);
if (v == NULL)
db_hdr = NULL;
else
@@ -1198,6 +1209,18 @@ rde_asext_put(struct kroute *rr)
RB_REMOVE(asext_tree, &ast, an);
free(an);
+}
+
+void
+rde_asext_free(void)
+{
+ struct asext_node *an, *nan;
+
+ f
Re: OpenBSD crash on an IBM x3550 M3
That is a huge penalty because it is read over the pci bus. The trick
with 0x should work just fine per the doco and other os' drivers
(on top of my head). The question I have is does Linux only have one
device per interrupt?
I am going to reference the doco one more time on this.
On Thu, Mar 03, 2011 at 10:35:59PM -0500, Kenneth R Westerback wrote:
> On Thu, Mar 03, 2011 at 07:11:52PM +0100, Mike Belopuhov wrote:
> > On Fri, Feb 04, 2011 at 14:53 +, emeric boit wrote:
> > > Hello,
> > >
> > > After doing a clean install of OpenBSD 4.8 (AMD64) on an IBM x3550 M3,
> > > I find
> > > the
> > > system randomly panics after a period of use.
> > > uvm_fault(0x80cc8360, 0x8000149b7000, 0, 1) -> e
> > > kernel: page
> > > fault trap, code=0
> > > Stopped at mpi_reply+0x102:movq
> > > 0(%r13),%rax
> > > ddb{0}>
> > >
> > > ddb{0}> trace
> > > mpi_reply() at mpi_reply+0x102
> > > mpi_intr()
> > > at mpi_intr+0x20
> > > Xintr_ioapic_level18() at Xintr_ioapic_level18+0xec
> > > ---
> > > interrupt ---
> > > Bad frame pointer: 0x8000194e1920
> > > end trace frame:
> > > 0x8000194e1920, count: -3
> > > Xspllower+0xe:
> > > ddb{0}>
> > >
> >
> > We've tried different things, but after this hint i realised
> > that what might be happening is that bnx and mpi interrupts
> > are chained (it's bnx0 actually, my initial guess about bnx1
> > was wrong) and mpi_intr is called first. Currently neither
> > mpi(4) nor mpii(4) don't check the interrupt status register
> > but look directly into the reply post queue. Although,
> > there's not supposed to be any race between host cpu reading
> > from the memory and ioc writing to it, in practice it turns
> > out that in some particular hardware configurations this rule
> > is violated and we read a garbled reply from the controller.
> >
> > If my memory serves, I've considered this for the mpii_intr
> > but never got into the situation where it was needed and
> > thus omitted it. I guess I have to bring it back too.
> >
> > Emeric tortured the machine with this diff and reported that
> > it solves the issue for him. OK to commit?
> >
> > On Wed, Mar 02, 2011 at 17:20 +, emeric boit wrote:
> > > hi,
> > >
> > > This change doesn't solve the issue.
> > >
> > > I have remarked that the server crash when I use the network.
> > >
> > > I copy a small file several times without problem.
> > > On the IBM I do :
> > > scp USER@IP:/tmp/mpi.c .
> > >
> > > And when I copy a larger file the server crash :
> > > scp USER@IP:/bsd .
> > >
> > >
> > > And when I copy th same file (bsd) from an usb key I don't have problem.
> > >
> > > Emeric.
> > >
> >
> > that sounds like an interrupt sharing bug of some sort.
> > is it bnx1 that you're using to reproduce a crash?
> >
> > try the following diff please (on a clean checkout):
> >
> > Index: mpi.c
> > ===
> > RCS file: /home/cvs/src/sys/dev/ic/mpi.c,v
> > retrieving revision 1.166
> > diff -u -p -r1.166 mpi.c
> > --- mpi.c 1 Mar 2011 23:48:33 - 1.166
> > +++ mpi.c 2 Mar 2011 17:40:13 -
> > @@ -887,6 +887,9 @@ mpi_intr(void *arg)
> > u_int32_t reg;
> > int rv = 0;
> >
> > + if ((mpi_read_intr(sc) & MPI_INTR_STATUS_REPLY) == 0)
> > + return (rv);
> > +
> > while ((reg = mpi_pop_reply(sc)) != 0x) {
> > mpi_reply(sc, reg);
> > rv = 1;
> >
>
> ok krw@.
>
> Ken
Re: tiny imsg_init(3) correction in EXAMPLES
On Fri, Mar 04, 2011 at 01:43:03PM +0500, Anton Maksimenkov wrote:
> Hi.
>
> I found that manpage for imsg-family have a little mistake:
> ...
>if (msgbuf_write(ibuf->w) < 0) {
> ...
>
> It seems it should be:
>if (msgbuf_write(&ibuf->w) < 0) {
Yes that's correct. I think the following diff should fix this.
--
:wq Claudio
Index: imsg_init.3
===
RCS file: /cvs/src/lib/libutil/imsg_init.3,v
retrieving revision 1.3
diff -u -p -r1.3 imsg_init.3
--- imsg_init.3 31 Oct 2010 17:33:33 - 1.3
+++ imsg_init.3 4 Mar 2011 10:09:38 -
@@ -492,7 +492,7 @@ library is used to monitor the socket fi
When the socket is ready for writing, queued messages are transmitted with
.Fn msgbuf_write :
.Bd -literal -offset indent
- if (msgbuf_write(ibuf-\*(Gtw) \*(Lt 0) {
+ if (msgbuf_write(&ibuf-\*(Gtw) \*(Lt 0) {
/* handle write failure */
}
.Ed
tiny imsg_init(3) correction in EXAMPLES
Hi.
I found that manpage for imsg-family have a little mistake:
...
if (msgbuf_write(ibuf->w) < 0) {
...
It seems it should be:
if (msgbuf_write(&ibuf->w) < 0) {
--
antonvm
