Re: Backout mclgeti for vr(4).
On Mon, Aug 30, 2010 at 11:46:20PM +, Thordur I Bjornsson wrote: Hi Thib! I have two machines with vr(4) interfaces running 4.7, and I can't seem to find any problem running ping -f against them. vr0 at pci0 dev 12 function 0 VIA VT6105 RhineIII rev 0x86: apic 2 int 19 (irq 10), address 00:19:5b:82:a1:e0 vr0 at pci0 dev 16 function 0 VIA Rhine/RhineII rev 0x06: irq 9, address 00:50:ba:bd:89:4d Is it possible that this bug only effects a few models? Possible. I can't remember what model I had (as I no longer have access to the machines) but it was a soekris. It was pretty easy for me to crash the machine, ~8 ping -f's (from two different hosts on a 1G lan). For various reasons, I maintain a 4.5 copy of the vr(4) driver that I've added the mclgeti and other things from current a while ago locally. I just looked wether I get the box to crash or behave in any weird way. | andor2 # ping -f foo.bytemine.net | PING foo.bytemine.net (134.106.XXX.XXX): 56 data bytes | --- foo.bytemine.net ping statistics --- | 1281377 packets transmitted, 1281369 packets received, 0.0% packet loss | round-trip min/avg/max/std-dev = 0.160/0.493/64.885/0.683 ms I will let that run for a while now and see. This is a Soekris 5501-60 with vr(4). If it keeps running stable like that, I will go ahead and diff the vr(4) drivers and see what the differences are. felix
stat.c remove unused variable
Remove unused variable, linkfail. Unused since v1.6.
ok?
mark
Index: stat.c
===
RCS file: /cvs/src/usr.bin/stat/stat.c,v
retrieving revision 1.15
diff -u -p -r1.15 stat.c
--- stat.c 29 Jun 2010 20:51:05 - 1.15
+++ stat.c 31 Aug 2010 07:18:02 -
@@ -141,7 +141,6 @@ int format1(const struct stat *,/* stat
int, int);
char *timefmt;
-int linkfail;
#define addchar(s, c, nl) \
do { \
@@ -164,7 +163,6 @@ main(int argc, char *argv[])
usestat = 0;
nonl = 0;
quiet = 0;
- linkfail = 0;
statfmt = NULL;
timefmt = NULL;
@@ -266,7 +264,6 @@ main(int argc, char *argv[])
if (rc == -1) {
errs = 1;
- linkfail = 1;
if (!quiet)
warn(%s,
argc == 0 ? (stdin) : argv[0]);
@@ -690,16 +687,14 @@ format1(const struct stat *st,
snprintf(path, sizeof(path), - );
l = readlink(file, path + 4, sizeof(path) - 4 - 1);
if (l == -1) {
- linkfail = 1;
l = 0;
path[0] = '\0';
}
path[l + 4] = '\0';
sdata = path + (ofmt == FMTF_STRING ? 0 : 4);
- } else {
- linkfail = 1;
+ } else
sdata = ;
- }
+
formats = FMTF_STRING;
if (ofmt == 0)
ofmt = FMTF_STRING;
Re: carpdev behavior is inconsistent on failover
On Thu, Aug 19, 2010 at 01:49:17PM -0400, Peter Bisroev wrote: Hi All, I have tried searching the mailing lists but did not seem to find the answer to the issue that I am seeing. I apologize for the long email, but more info is better than less :) ... For the tests performed all switches were unmanaged Netgear JFS516 and JGS516. The hosts we wired as follows: -- test00:em2 - 1:sw0a:2 - 1:sw0c test01:em2 - 1:sw0b:2 - 2:sw0c test00:em3 - 1:sw1a:2 - 1:sw1c test01:em3 - 1:sw1b:2 - 2:sw1c test00:bge1 - 1:sw2a:2 - 1:sw2c test01:re1 - 1:sw2b:2 - 2:sw2c -- For example, the last line shows that re1 on test01 was connected to port 1 on switch sw2b and port 2 from sw2b was connected to port 2 on switch sw2c. (I would have loved to draw an ASCII diagram but it got too complex.) The reason for so many switches is to approximate different failure scenarios. For the first test unplug the cable between sw0a:2 and sw0c:1, and as expected the log on test01 shows: -- test01 /bsd: carp0: state transition: BACKUP - MASTER # ifconfig carp carp0: flags=28843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,NOINET6 mtu 1500 lladdr 00:00:5e:00:01:01 priority: 0 carp: MASTER carpdev em2 vhid 1 advbase 1 advskew 100 groups: carp status: master inet 192.168.1.1 netmask 0xff00 broadcast 192.168.1.255 carp1: flags=28843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,NOINET6 mtu 1500 lladdr 00:00:5e:00:01:02 priority: 0 carp: BACKUP carpdev em3 vhid 2 advbase 1 advskew 100 groups: carp status: backup inet 192.168.2.1 netmask 0xff00 broadcast 192.168.2.255 carp2: flags=28843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,NOINET6 mtu 1500 lladdr 00:00:5e:00:01:03 priority: 0 carp: BACKUP carpdev re1 vhid 3 advbase 1 advskew 100 groups: carp status: backup inet 192.168.3.1 netmask 0xff00 broadcast 192.168.3.255 -- Yes, since you disconnected the link between the carp interfaces without dropping their physical connections both will become MASTER. This normaly results in havoc since bad luck will flow all traffic to the wrong box. This is the typical problem with too much redundancy (the result has more error cases and is often less stable). For the second test unplug the cable between test00:em2 and sw0a:1. Now the results are not what I have expected. The log on test00 shows the following: -- test00 /bsd: carp0: state transition: MASTER - INIT test00 /bsd: carp: carp0 demoted group carp to 1 test00 /bsd: carp1: state transition: MASTER - BACKUP test00 /bsd: carp2: state transition: MASTER - BACKUP # ifconfig carp carp0: flags=8803UP,BROADCAST,SIMPLEX,MULTICAST mtu 1500 lladdr 00:00:5e:00:01:01 priority: 0 carp: INIT carpdev em2 vhid 1 advbase 1 advskew 0 groups: carp inet 192.168.1.1 netmask 0xff00 broadcast 192.168.1.255 carp1: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 lladdr 00:00:5e:00:01:02 priority: 0 carp: BACKUP carpdev em3 vhid 2 advbase 1 advskew 0 groups: carp inet 192.168.2.1 netmask 0xff00 broadcast 192.168.2.255 carp2: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 lladdr 00:00:5e:00:01:03 priority: 0 carp: BACKUP carpdev bge1 vhid 3 advbase 1 advskew 0 groups: carp inet 192.168.3.1 netmask 0xff00 broadcast 192.168.3.255 # ifconfig em2 em2: flags=8b43UP,BROADCAST,RUNNING,PROMISC,ALLMULTI,SIMPLEX,MULTICAST mtu 1500 lladdr 00:15:17:b8:db:3e priority: 0 media: Ethernet autoselect (none) status: no carrier -- And the log on test01 shows the following: -- test01 /bsd: carp1: state transition: BACKUP - MASTER test01 /bsd: carp2: state transition: BACKUP - MASTER test01 /bsd: carp0: state transition: BACKUP - MASTER -- Plugging the cable back in brings the system back to the original state as shown in the logs below: -- test00 /bsd: carp0: state transition: INIT - BACKUP test00 /bsd: carp: carp0 demoted group carp to 0 test00 /bsd: carp0: state transition: BACKUP - MASTER test00 /bsd: carp1: state transition: BACKUP - MASTER test00 /bsd: carp2: state transition: BACKUP - MASTER test01 /bsd: carp0: state transition: MASTER - BACKUP test01 /bsd: carp1: state transition: MASTER - BACKUP test01 /bsd: carp2: state transition: MASTER - BACKUP -- The same
Re: Backout mclgeti for vr(4).
On 2010/08/30 20:20, Marco Peereboom wrote: My vr on my firewall hangs for a while until the watchdog kicks it in the pants every time I push a little traffic through it. I'd love to see thibs thing go in. Does thib's diff help this?
Re: Looking for testers for a simple X test
On Tue, Aug 31, 2010 at 10:58:08AM +0300, Oleksii Zhmyrov wrote: Hi, I use OpenBSD -current on my desktop with Xfce4. With Option UseSIGIO false xserver refuses to start at all. Same here, segmentation fault. I am on a radeon card too, x1950 with a ca. 1 week old x11. snipplet from Xorg.0.log: ... [3357823.938] (**) Keyboard0: CustomKeycodes disabled [3357823.938] (II) XINPUT: Adding extended input device Keyboard0 (type: KEYBOARD) [3357823.938] Segmentation fault at address 0x9b641ce [3357823.938] Fatal server error: [3357823.938] Caught signal 11 (Segmentation fault). Server aborting [3357823.938] [3357823.938] ... I can attach the rest if it is needed. Alf OpenBSD 4.8 (GENERIC.MP) #359: Mon Aug 16 09:16:26 MDT 2010 dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC.MP cpu0: Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz (GenuineIntel 686-class) 3.01 GHz cpu0: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1 real mem = 2145873920 (2046MB) avail mem = 2100781056 (2003MB) mainbus0 at root bios0 at mainbus0: AT/286+ BIOS, date 12/11/07, BIOS32 rev. 0 @ 0xfb2e0, SMBIOS rev. 2.4 @ 0xf0100 (38 entries) bios0: vendor Award Software International, Inc. version F1 date 12/11/2007 bios0: Gigabyte Technology Co., Ltd. EP35-DS3P acpi0 at bios0: rev 0 acpi0: sleep states S0 S1 S4 S5 acpi0: tables DSDT FACP HPET MCFG APIC SSDT SSDT acpi0: wakeup devices PEX0(S5) PEX1(S5) PEX2(S5) PEX3(S5) PEX4(S5) PEX5(S5) HUB0(S5) UAR1(S1) USB0(S1) USB1(S1) USB2(S1) USB3(S1) US31(S1) USB4(S1) USB5(S1) USBE(S1) USE2(S1) AZAL(S5) PCI0(S5) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpihpet0 at acpi0: 14318179 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: apic clock running at 333MHz cpu1 at mainbus0: apid 1 (application processor) cpu1: Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz (GenuineIntel 686-class) 3.01 GHz cpu1: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1 ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins ioapic0: misconfigured as apic 0, remapped to apid 2 acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus 2 (PEX0) acpiprt2 at acpi0: bus -1 (PEX1) acpiprt3 at acpi0: bus -1 (PEX2) acpiprt4 at acpi0: bus -1 (PEX3) acpiprt5 at acpi0: bus 3 (PEX4) acpiprt6 at acpi0: bus 4 (PEX5) acpiprt7 at acpi0: bus 5 (HUB0) acpicpu0 at acpi0: FVS, 3000, 2000 MHz acpicpu1 at acpi0: FVS, 3000, 2000 MHz acpibtn0 at acpi0: PWRB bios0: ROM list: 0xc/0xf800 pci0 at mainbus0 bus 0: configuration mode 1 (bios) pchb0 at pci0 dev 0 function 0 Intel 82G33 Host rev 0x02 ppb0 at pci0 dev 1 function 0 Intel 82G33 PCIE rev 0x02: apic 2 int 16 (irq 10) pci1 at ppb0 bus 1 vga1 at pci1 dev 0 function 0 ATI Radeon X1950 Pro rev 0x9a wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) wsdisplay0: screen 1-5 added (80x25, vt100 emulation) radeondrm0 at vga1: apic 2 int 16 (irq 10) drm0 at radeondrm0 ATI Radeon X1950 Pro Sec rev 0x9a at pci1 dev 0 function 1 not configured uhci0 at pci0 dev 26 function 0 Intel 82801I USB rev 0x02: apic 2 int 16 (irq 10) uhci1 at pci0 dev 26 function 1 Intel 82801I USB rev 0x02: apic 2 int 21 (irq 12) uhci2 at pci0 dev 26 function 2 Intel 82801I USB rev 0x02: apic 2 int 18 (irq 10) ehci0 at pci0 dev 26 function 7 Intel 82801I USB rev 0x02: apic 2 int 18 (irq 10) usb0 at ehci0: USB revision 2.0 uhub0 at usb0 Intel EHCI root hub rev 2.00/1.00 addr 1 azalia0 at pci0 dev 27 function 0 Intel 82801I HD Audio rev 0x02: apic 2 int 22 (irq 9) azalia0: codecs: Realtek ALC885 audio0 at azalia0 ppb1 at pci0 dev 28 function 0 Intel 82801I PCIE rev 0x02: apic 2 int 16 (irq 10) pci2 at ppb1 bus 2 ppb2 at pci0 dev 28 function 4 Intel 82801I PCIE rev 0x02: apic 2 int 16 (irq 10) pci3 at ppb2 bus 3 jmb0 at pci3 dev 0 function 0 JMicron JMB363 IDE/SATA rev 0x02 ahci0 at jmb0: apic 2 int 16 (irq 10), AHCI 1.0 scsibus0 at ahci0: 32 targets pciide0 at jmb0: DMA, channel 0 wired to native-PCI, channel 1 wired to native-PCI pciide0: using apic 2 int 16 (irq 10) for native-PCI interrupt atapiscsi0 at pciide0 channel 0 drive 0 scsibus1 at atapiscsi0: 2 targets cd0 at scsibus1 targ 0 lun 0: ASUS, DVD-E616A3, 1.01 ATAPI 5/cdrom removable cd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 5 pciide0: channel 1 disabled (no drives) ppb3 at pci0 dev 28 function 5 Intel 82801I PCIE rev 0x02: apic 2 int 17 (irq 12) pci4 at ppb3 bus 4 re0 at pci4 dev 0 function 0 Realtek 8168 rev 0x01: RTL8168 2 (0x3800), apic 2 int 17 (irq 12), address 00:1a:4d:5f:84:be rgephy0 at re0 phy 7: RTL8169S/8110S PHY, rev. 2 uhci3 at pci0 dev 29 function 0 Intel 82801I USB rev 0x02: apic 2 int 23 (irq 11) uhci4 at pci0 dev 29 function 1 Intel 82801I USB rev 0x02: apic 2 int 19 (irq 11) uhci5 at pci0 dev
Re: ACPI systems without legacy mode
On 08/08/10 12:18, Mark Kettenis wrote: Date: Sun, 8 Aug 2010 17:57:20 +0800 Is there someone who would be willing to test this diff on a physical machine that currently reports ACPI control unavailable in dmesg, e.g. acpi0 at bios0: rev 2, ACPI control unavailable I'm pretty sure such hardware does not exist, at least not in the i386/amd64 world. To me, that doesn't matter. There exist the concept of ACPI systems without SMM in the specs, and at least one VMM implements their ACPI without any SMM. I see no reason to not support running OpenBSD in in it, i.e. Xen. The diff removes the need for UKC workaounds when running HVM OpenBSD guests in Citrix Xenserver. As such it is very useful as is, and it is, in my opinion, correct. I have spent quite a few hours debugging some PCI IRQ routing problems in the Xen guest world which finally boiled down to ioapic enabling, without the ACPI tables available to set it up correctly. acpiprt made it work immedately as soon as acpi was allowed to attach. With this diff, OpenBSD does not need any UKC magic to boot (xenserver still needs some hacks to the qemu-dm-wrapper, in order to emulate em instead of rl, which seems to be a known broken emulation). Furthermore, since USB can be enabled, the much better trick of using a USB tablet for mouse emulation, GUIs become usable as well. Not that I need it, but the side effect to having to disable USB in order to boot OpenBSD, makes mouse emulation really bad. I find it funny that Nathanael only wanted this for halt -p, that would be the least of the good stuff it brings :-) Still, Citrix XenServer breaks SMP, that will be my next thing to fix I guess. I sort of hoped acpimadt would do it :-) So as far as I am concerned Nathanaels diff should be considered seriously. I am already using it in my baseline tree I build all our clients' systems from. Niklas [demime 1.01d removed an attachment of type application/pkcs7-signature which had a name of smime.p7s]
Re: ACPI systems without legacy mode
Now that release is done I am not opposed to this. On Tue, Aug 31, 2010 at 03:58:43PM +0200, Niklas Hallqvist wrote: On 08/08/10 12:18, Mark Kettenis wrote: Date: Sun, 8 Aug 2010 17:57:20 +0800 Is there someone who would be willing to test this diff on a physical machine that currently reports ACPI control unavailable in dmesg, e.g. acpi0 at bios0: rev 2, ACPI control unavailable I'm pretty sure such hardware does not exist, at least not in the i386/amd64 world. To me, that doesn't matter. There exist the concept of ACPI systems without SMM in the specs, and at least one VMM implements their ACPI without any SMM. I see no reason to not support running OpenBSD in in it, i.e. Xen. The diff removes the need for UKC workaounds when running HVM OpenBSD guests in Citrix Xenserver. As such it is very useful as is, and it is, in my opinion, correct. I have spent quite a few hours debugging some PCI IRQ routing problems in the Xen guest world which finally boiled down to ioapic enabling, without the ACPI tables available to set it up correctly. acpiprt made it work immedately as soon as acpi was allowed to attach. With this diff, OpenBSD does not need any UKC magic to boot (xenserver still needs some hacks to the qemu-dm-wrapper, in order to emulate em instead of rl, which seems to be a known broken emulation). Furthermore, since USB can be enabled, the much better trick of using a USB tablet for mouse emulation, GUIs become usable as well. Not that I need it, but the side effect to having to disable USB in order to boot OpenBSD, makes mouse emulation really bad. I find it funny that Nathanael only wanted this for halt -p, that would be the least of the good stuff it brings :-) Still, Citrix XenServer breaks SMP, that will be my next thing to fix I guess. I sort of hoped acpimadt would do it :-) So as far as I am concerned Nathanaels diff should be considered seriously. I am already using it in my baseline tree I build all our clients' systems from. Niklas [demime 1.01d removed an attachment of type application/pkcs7-signature which had a name of smime.p7s]
Re: stat.c remove unused variable
On Tue, Aug 31, 2010 at 07:29:16AM +, Mark Lumsden wrote:
Remove unused variable, linkfail. Unused since v1.6.
ok?
mark
yup, it should have been removed in 1.6, ok gilles@
Index: stat.c
===
RCS file: /cvs/src/usr.bin/stat/stat.c,v
retrieving revision 1.15
diff -u -p -r1.15 stat.c
--- stat.c29 Jun 2010 20:51:05 - 1.15
+++ stat.c31 Aug 2010 07:18:02 -
@@ -141,7 +141,6 @@ int format1(const struct stat *,/* stat
int, int);
char *timefmt;
-int linkfail;
#define addchar(s, c, nl) \
do { \
@@ -164,7 +163,6 @@ main(int argc, char *argv[])
usestat = 0;
nonl = 0;
quiet = 0;
- linkfail = 0;
statfmt = NULL;
timefmt = NULL;
@@ -266,7 +264,6 @@ main(int argc, char *argv[])
if (rc == -1) {
errs = 1;
- linkfail = 1;
if (!quiet)
warn(%s,
argc == 0 ? (stdin) : argv[0]);
@@ -690,16 +687,14 @@ format1(const struct stat *st,
snprintf(path, sizeof(path), - );
l = readlink(file, path + 4, sizeof(path) - 4 - 1);
if (l == -1) {
- linkfail = 1;
l = 0;
path[0] = '\0';
}
path[l + 4] = '\0';
sdata = path + (ofmt == FMTF_STRING ? 0 : 4);
- } else {
- linkfail = 1;
+ } else
sdata = ;
- }
+
formats = FMTF_STRING;
if (ofmt == 0)
ofmt = FMTF_STRING;
--
Gilles Chehade
freelance developer/sysadmin/consultant
http://www.poolp.org
Conseil des Ministres du 26 Août 2010
Visitez le portail officiel du Gouvernement de Ctte d'Ivoire, Cliquez ici (
http://www.gouv.ci/; )
( http://www.gouv.ci/; )
CONSEIL DES MINISTRES
Conseil des Ministres du 26 Ao{t 2010
Le Conseil des Ministres s'est tenu le jeudi 26 ao{t 2010, de 13H15mn `14H30
mn au Palais de la Prisidence de la Ripublique au Plateau, sous la prisidence
de Son Excellence Monsieur Laurent GBAGBO, Prisident de la Ripublique.
A l'ouverture du conseil, le Prisident de la Ripublique a commenti l'actualiti
nationale. Il a rappeli que le rtle essentiel de l'actuel Gouvernement est
l'organisation et la riussite des ilections fixies au 31 octobre 2010.
Lire plus [+] ( http://www.gouv.ci/conseil_ministre.php?recordID=82; )
PROJETS DE LOI ET DICRETS
Au titre du Ministhre d'Etat, Ministhre du Plan et du Diveloppement :
Sur exposi du Ministre d'Etat, Ministre du Plan et du Diveloppement, le
Prisident de la Ripublique a signi un dicret portant criation de la Commission
Nationale de la Prospective.
Cette commission a pour mission de riflichir au futur ` long terme de la Ctte
d'Ivoire avec l'idie d'instaurer de larges concertations permettant de
rialiser un consensus minimal sur les problhmes majeurs du pays.
Lire plus [+] (
http://www.gouv.ci/conseil_ministre.php?recordID=82#PROJETS%20DE%20LOI%20ET%
20DECRETS )
COMMUNICATIONS
Au titre du Ministhre d'Etat, Ministhre du Plan et du Diveloppement :
Le conseil a entendu une communication relative ` l'adoption de la Politique
Nationale de Population.
Cette politique est un ensemble de mesures publiques cohirentes en vue
d'influencer la dynamique dimographique et son impact sur le diveloppement
durable de la Ctte d'Ivoire. Les principes qui sous-tendent cette politique
sont :
- respect des droits fondamentaux de la population ;
- priservation de la paix, de la dimocratie ;
- respect des droits de la famille notamment en matihre de procriation ;
- acchs iquitable de tous ` la santi, ` l'iducation, ` la culture, `
l'information, ` l'emploi ;
- etc.
Lire plus [+] (
http://www.gouv.ci/conseil_ministre.php?recordID=82#COMMUNICATIONS%20:%20%20
POLITIQUE%20NATIONALE%20DE%20LA%20POPULATION )
Le pricident conseil
Le conseil des Ministres s'est tenu le jeudi 22 juillet 2010, de 17H20 mn `
18H15 mn, au Palais de la Prisidence de la Ripublique au Plateau, sous la
prisidence de Son Excellence Monsieur Laurent GBAGBO, Prisident de la
Ripublique.
Lire plus [+] ( http://www.gouv.ci/conseil_ministre.php?recordID=81; )
Le Site Web de la semaine
-
( http://www.plan.gouv.ci/; )
Visitez ce site ( http://www.plan.gouv.ci/; )
Grands dossiers
( http://www.gouv.ci/bonnegouvernance2009_2013.php; )
--
( http://www.gouv.ci/ajustemet_prix_petrol31052010.php; )
LA COMMUNICATION AU COEUR DE L'ACTION GOUVERNEMENTALE
Continuez de nous faire part de vos suggestions (
http://www.gouv.ci/webmaster.php; ).
Merci ` toutes celles et tous ceux qui nous ont dij` icrit !
Si vous ne souhaitez plus recevoir notre lettre d'informations, cliquez ici
pour vous disabonner
[demime 1.01d removed an attachment of type image/jpeg which had a name of
=?iso-8859-1?Q?ajustemet=5Fprix=5Foro2.Jpg?=]
[demime 1.01d removed an attachment of type image/jpeg which had a name of
=?iso-8859-1?Q?bonne_gouvernance.Jpg?=]
[demime 1.01d removed an attachment of type image/jpeg which had a name of
=?iso-8859-1?Q?conseilministre15072010.Jpg?=]
[demime 1.01d removed an attachment of type image/jpeg which had a name of
=?iso-8859-1?Q?gouvletter.jpg?=]
[demime 1.01d removed an attachment of type image/jpeg which had a name of
=?iso-8859-1?Q?logo.jpg?=]
[demime 1.01d removed an attachment of type image/jpeg which had a name of
=?iso-8859-1?Q?Minist=E8re_du_plan_et_du_d=E9veloppement.Jpg?=]
Re: Looking for testers for a simple X test
On Mon, Aug 30, 2010 at 9:12 PM, Theo de Raadt dera...@cvs.openbsd.org wrote: How can you tell whether this option is turned on by default or not? xorg.conf(5) indicates that the default is platform dependent and that this option in general should only be used as a work-around to a bug until fixed. The X documentation is full of lies. I see. Seems a few have had issues with this option. I turned it off last night and have been using it on my ibook G4 (macppc) for a good bunch of hours with no adverse effects. $ grep SIGIO /var/log/Xorg.0.log [3379048.700] (**) Option UseSIGIO false [3379048.700] (**) Disabling SIGIO handlers for input devices This is on a slightly older snapshot: $ sysctl kern.version kern.version=OpenBSD 4.8-beta (GENERIC) #84: Tue Aug 3 10:03:35 MDT 2010 dera...@macppc.openbsd.org:/usr/src/sys/arch/macppc/compile/GENERIC --patrick
Re: Backout mclgeti for vr(4).
On 2010/08/30 23:46, Thordur I Bjornsson wrote: On Mon, Aug 30, 2010 at 06:46:53PM -0400, Brynet wrote: Evening, I have two machines with vr(4) interfaces running 4.7, and I can't seem to find any problem running ping -f against them. vr0 at pci0 dev 12 function 0 VIA VT6105 RhineIII rev 0x86: apic 2 int 19 (irq 10), address 00:19:5b:82:a1:e0 vr0 at pci0 dev 16 function 0 VIA Rhine/RhineII rev 0x06: irq 9, address 00:50:ba:bd:89:4d Is it possible that this bug only effects a few models? Possible. I can't remember what model I had (as I no longer have access to the machines) but it was a soekris. tried some more... 3x ping -f from two fast sources causes my system with VT6105M to crash within seconds. 3x ping -f from a single source causes it to crash in ~30 seconds. on a hunch I tried switching over to copying buffers (i.e. adding the VR_Q_NEEDALIGN quirk that's needed for older ICs) but no difference there. on another hunch, I tried a snapshot kernel from June 30th (pre gcc 4). I haven't been able to crash it yet...
Re: Looking for testers for a simple X test
On Tue, Aug 31, 2010 at 02:54:44PM +0200, Alf Schlichting wrote: On Tue, Aug 31, 2010 at 10:58:08AM +0300, Oleksii Zhmyrov wrote: Hi, I use OpenBSD -current on my desktop with Xfce4. With Option UseSIGIO false xserver refuses to start at all. Same here, segmentation fault. I am on a radeon card too, x1950 with a ca. 1 week old x11. snipplet from Xorg.0.log: ... [3357823.938] (**) Keyboard0: CustomKeycodes disabled [3357823.938] (II) XINPUT: Adding extended input device Keyboard0 (type: KEYBOARD) [3357823.938] Segmentation fault at address 0x9b641ce [3357823.938] Fatal server error: [3357823.938] Caught signal 11 (Segmentation fault). Server aborting [3357823.938] [3357823.938] ... I can attach the rest if it is needed. I just fixed this, please could you try again with current sources and confirm that things are now ok? Ta, -0- -- I do not fear computers. I fear the lack of them. -- Isaac Asimov
Re: Backout mclgeti for vr(4).
running with this seems to help.
Index: if_vr.c
===
RCS file: /cvs/src/sys/dev/pci/if_vr.c,v
retrieving revision 1.105
diff -u -p -r1.105 if_vr.c
--- if_vr.c 19 May 2010 15:27:35 - 1.105
+++ if_vr.c 31 Aug 2010 21:30:22 -
@@ -731,7 +731,7 @@ vr_list_rx_init(struct vr_softc *sc)
{
struct vr_chain_data*cd;
struct vr_list_data *ld;
- struct vr_desc *d;
+ volatile struct vr_desc *d;
int i, nexti;
cd = sc-vr_cdata;
@@ -744,7 +744,7 @@ vr_list_rx_init(struct vr_softc *sc)
return (ENOBUFS);
d = (struct vr_desc *)ld-vr_rx_list[i];
- cd-vr_rx_chain[i].vr_ptr = d;
+ cd-vr_rx_chain[i].vr_ptr = (struct vr_desc *)d;
cd-vr_rx_chain[i].vr_paddr =
sc-sc_listmap-dm_segs[0].ds_addr +
offsetof(struct vr_list_data, vr_rx_list[i]);
@@ -1136,7 +1136,7 @@ vr_intr(void *arg)
int
vr_encap(struct vr_softc *sc, struct vr_chain *c, struct mbuf *m_head)
{
- struct vr_desc *f = NULL;
+ volatile struct vr_desc *f = NULL;
struct mbuf *m_new = NULL;
u_int32_t vr_flags = 0, vr_status = 0;
@@ -1536,8 +1536,8 @@ vr_stop(struct vr_softc *sc)
int
vr_alloc_mbuf(struct vr_softc *sc, struct vr_chain_onefrag *r)
{
- struct vr_desc *d;
- struct mbuf *m;
+ volatile struct vr_desc *d;
+ struct mbuf *m;
if (r == NULL)
return (EINVAL);
Te Regalamos la CCNA
Si no puede ver este Newsletter correctamente, o desea ver la version HTML completa presione en el SIGUIENTE LINK http://www.editorialpoulbert.com.ar/Newsletter/2010/08_agosto/ccna/news_ccna.html - Te regalamos la CCNA Si, creelo!!! Comprando tu carrera CCNP llevate de regalo la Carrera CCNA - CCNP CN - Conceptos en Networking - E-Learning ROUTE - Implementing Cisco IP Routing - 32 hs SWITCH - Implementing Cisco IP Switched Networks - 28 hs TSHOOT - Troubleshooting and Maintaining Cisco IP Networks - 28 hs WC Workshop Certificacisn Internacional CCNP - 16 hs. Duracion Total: 104 hs. Examenes a preparar: 642-902 https://learningnetwork.cisco.com/community/certifications/ccnp/route?tab=overview 642-813 https://learningnetwork.cisco.com/community/certifications/ccnp/switch?tab=overview 642-832 https://learningnetwork.cisco.com/community/certifications/ccnp/tshoot?tab=overview - CCNA (regalo) CN - Conceptos en Networking - E-Learning CCND1 - Interconnecting Cisco Networking Devices Part 1 v1.0 - 28 hs. CCND2 - Interconnecting Cisco Networking Devices Part 2 v1.0 - 28 hs. WC - Workshop Certificacisn Internacional CCNA - 16 hs. Duracion Total: 64 hs. Examenes a preparar: 640-822 http://www.cisco.com/web/learning/le3/current_exams/640-822.html 640-816 http://www.cisco.com/web/learning/le3/current_exams/640-816.html - Encontranos en... http://www.centraltech.tv/ http://www.facebook.com/centraltech http://twitter.com/centraltech_ct Argentina - Bs As.: +54 (11) 5031-2233 Espana - Madrid: +34 (91) 143-6077 Mexico - Dis. Fed.: +52 (55) 1163-8760 USA - Miami: +1 (786) 718-1991 Lavalle 348 - Piso 6 - (C1043AAF) Buenos Aires, Argentina | masi...@centraltech.com.ar http://www.centraltech.com.ar/ Si no desea continuar recibiendo nuestros Newsletters, http://mail.ctnewsletter.com.ar:20080/lists/?p=unsubscribeuid=5d4d37f1358e36e589fb6759c9893e35 Para cambiar sus opciones de envio http://mail.ctnewsletter.com.ar:20080/lists/?p=preferences Visite nuestra politica de PRIVACIDAD http://mail.ctnewsletter.com.ar:20080/lists/privacidad.html -- Powered by CTNewsletter, mail.ctnewsltter.com.ar --
Re: Backout mclgeti for vr(4).
Date: Tue, 31 Aug 2010 22:30:42 +0100 From: Stuart Henderson s...@spacehopper.org running with this seems to help. Can you try this diff instead? Index: if_vr.c === RCS file: /cvs/src/sys/dev/pci/if_vr.c,v retrieving revision 1.105 diff -u -p -r1.105 if_vr.c --- if_vr.c 19 May 2010 15:27:35 - 1.105 +++ if_vr.c 31 Aug 2010 21:57:55 - @@ -1562,6 +1562,10 @@ vr_alloc_mbuf(struct vr_softc *sc, struc d = r-vr_ptr; d-vr_data = htole32(r-vr_map-dm_segs[0].ds_addr); d-vr_ctl = htole32(VR_RXCTL | VR_RXLEN); + + bus_dmamap_sync(sc-sc_dmat, sc-sc_listmap, 0, + sc-sc_listmap-dm_mapsize, BUS_DMASYNC_PREWRITE); + d-vr_status = htole32(VR_RXSTAT); bus_dmamap_sync(sc-sc_dmat, sc-sc_listmap, 0, #define bus_dmamap_sync(t, p, o, l, ops)\ (void)((t)-_dmamap_sync ? \ (*(t)-_dmamap_sync)((t), (p), (o), (l), (ops)) : (void)0) I expect it to still fail in exactly the same way, with gcc re-organizing the writes. Only a global function call will fix it, or, making the pointer volatile so that operations on it are ordered. Volatile pointers are the strong and portable way to imposing ordering.
