Regression with ATI Mobility Radeon HD 3400
This was also sent to bugs@ but I am also sending it here per recommendation from #openbsd on Freenode. Version: Current, 5.2 (what will get released), 5.1 Platform: amd64 Graphic adapter: ATI Mobility Radeon HD 3400 Problem: At some point a half year to one year ago, some changes were made to current that made it impossible to watch movies on my computer. The graphics is lagging so terrible that it is not possible to watch. A less important problem is absolutely terrible 3d performance. Even software rendering is faster. I get with glxgears about 0.6-0.8 FPS. I have even tried the experimental BFS from Marc to see if it would help, but it does not. I have attached Xorg.0.log and dmesg. I am willing to test any experimental patches / fixes. And if there is anything else I can do to help tell me (I am not on the mailing list) Regards, Lasse [23.679] (--) checkDevMem: using aperture driver /dev/xf86 [23.692] (--) Using wscons driver on /dev/ttyC4 in pcvt compatibility mode (version 3.32) [23.739] X.Org X Server 1.12.3 Release Date: 2012-07-09 [23.739] X Protocol Version 11, Revision 0 [23.739] Build Operating System: OpenBSD 5.2 amd64 [23.739] Current Operating System: OpenBSD bach.home.gateway 5.2 GENERIC.MP#0 amd64 [23.740] Build Date: 09 October 2012 09:54:26AM [23.740] [23.740] Current version of pixman: 0.26.2 [23.740]Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. [23.740] Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. [23.740] (==) Log file: /var/log/Xorg.0.log, Time: Thu Oct 18 19:30:39 2012 [23.768] (==) Using system config directory /usr/X11R6/share/X11/xorg.conf.d [23.778] (==) No Layout section. Using the first Screen section. [23.779] (==) No screen section available. Using defaults. [23.779] (**) |--Screen Default Screen Section (0) [23.779] (**) | |--Monitor default monitor [23.780] (==) No monitor specified for screen Default Screen Section. Using a default monitor configuration. [23.780] (==) Disabling SIGIO handlers for input devices [23.780] (==) Automatically adding devices [23.780] (==) Automatically enabling devices [23.927] (==) FontPath set to: /usr/X11R6/lib/X11/fonts/misc/, /usr/X11R6/lib/X11/fonts/TTF/, /usr/X11R6/lib/X11/fonts/OTF/, /usr/X11R6/lib/X11/fonts/Type1/, /usr/X11R6/lib/X11/fonts/100dpi/, /usr/X11R6/lib/X11/fonts/75dpi/ [23.927] (==) ModulePath set to /usr/X11R6/lib/modules [23.927] (II) The server relies on wscons to provide the list of input devices. If no devices become available, reconfigure wscons or disable AutoAddDevices. [23.941] (II) Loader magic: 0x17ca3a4b53e0 [23.941] (II) Module ABI versions: [23.941]X.Org ANSI C Emulation: 0.4 [23.941]X.Org Video Driver: 12.0 [23.941]X.Org XInput driver : 16.0 [23.941]X.Org Server Extension : 6.0 [23.945] (--) PCI:*(0:1:0:0) 1002:95c4:103c:30fc rev 0, Mem @ 0xc000/268435456, 0xd240/65536, I/O @ 0x7000/256, BIOS @ 0x/131072 [23.945] (II) LoadModule: extmod [23.971] (II) Loading /usr/X11R6/lib/modules/extensions/libextmod.so [23.987] (II) Module extmod: vendor=X.Org Foundation [23.987]compiled for 1.12.3, module version = 1.0.0 [23.987]Module class: X.Org Server Extension [23.987]ABI class: X.Org Server Extension, version 6.0 [23.987] (II) Loading extension MIT-SCREEN-SAVER [23.987] (II) Loading extension XFree86-VidModeExtension [23.987] (II) Loading extension XFree86-DGA [23.987] (II) Loading extension DPMS [23.987] (II) Loading extension XVideo [23.987] (II) Loading extension XVideo-MotionCompensation [23.987] (II) Loading extension X-Resource [23.987] (II) LoadModule: dbe [23.989] (II) Loading /usr/X11R6/lib/modules/extensions/libdbe.so [23.993] (II) Module dbe: vendor=X.Org Foundation [23.993]compiled for 1.12.3, module version = 1.0.0 [23.993]Module class: X.Org Server Extension [23.993]ABI class: X.Org Server Extension, version 6.0 [23.994] (II) Loading extension DOUBLE-BUFFER [23.994] (II) LoadModule: glx [23.995] (II) Loading /usr/X11R6/lib/modules/extensions/libglx.so [24.007] (II) Module glx: vendor=X.Org Foundation [24.007]compiled for 1.12.3, module version = 1.0.0 [24.007]ABI class: X.Org Server Extension, version 6.0 [24.008] (==) AIGLX enabled [24.008] (II) Loading extension GLX [24.008] (II) LoadModule: record [24.010] (II) Loading /usr/X11R6/lib/modules/extensions/librecord.so [24.011] (II) Module record: vendor=X.Org
iked vs. isakmpd + carp
Two part question: 1. Anyone had any success getting iked and carp working on OpenBSD 5.1 (amd64)? We can get it working with isakmpd. The issue seems to be that iked wants to send out packets as the physical interface IP instead of the carp IP. iked documentation eludes to the fact that it should work. 2. I can't get isakmpd to use groups above modp1024 when using aes-256 or aes in main. Is there a catch I'm not aware of? Works: gwA = 1.1.1.1 gwB = 2.2.2.2 ike active esp from 192.168.1.1 to 172.16.1.1 \ local $gwA peer $gwB \ main auth hmac-sha1 enc aes-256 group modp1024 \ quick auth hmac-sha1 enc aes-256 \ psk foobar Does not work: gwA = 1.1.1.1 gwB = 2.2.2.2 ike active esp from 192.168.1.1 to 172.16.1.1 \ local $gwA peer $gwB \ main auth hmac-sha1 enc aes-256 group modp2048 \ quick auth hmac-sha1 enc aes-256 \ psk foobar The error message isakmpd spits out on one side is says MALFORMED_PAYLOAD and the other NO_PROPOSAL_CHOSEN. I can provide more details if needed. Just odd it works with only a change to the group field. thanks Jim
Re: Xwindows unusable after Zapping
On 19 October 2012 00:29, patrick keshishian pkesh...@gmail.com wrote: Hi Ville, I do believe after a few Xwindows restarts the machine seems to hang, but I'll retest to verify this and check the Xorg.log more closely. cheers, --patrick Now when you said that, I remember how to reproduce it: system freezes after many suspend/resume loops and therefore symptoms are equal. -- Ville
Re: Regression with ATI Mobility Radeon HD 3400
On Fri, Oct 19, 2012 at 09:06:24AM +0300, Lars Engblom wrote: At some point a half year to one year ago, some changes were made to current that made it impossible to watch movies on my computer. The graphics is lagging so terrible that it is not possible to watch. [26.263] (II) AIGLX: Loaded and initialized r600 ^ My guess is that you need this in ~/.drirc or /etc/drirc: driconf device screen=0 driver=r600 application name=all option name=fthrottle_mode value=0/ option name=vblank_mode value=0/ /application /device /driconf See http://marc.info/?l=openbsd-cvsm=130679235018645w=2 I have an r600 as well and it works very well with the above dri config.
Re: Regression with ATI Mobility Radeon HD 3400
Thanks, I will try it as soon as I get home to my computer. I would suggest to add this information to the radeon manual page. I have read that page several times playing with options found there without luck for this card. It is there people will first look. Regards, Lasse On 10/19/12 11:59, Stefan Sperling wrote: On Fri, Oct 19, 2012 at 09:06:24AM +0300, Lars Engblom wrote: At some point a half year to one year ago, some changes were made to current that made it impossible to watch movies on my computer. The graphics is lagging so terrible that it is not possible to watch. [26.263] (II) AIGLX: Loaded and initialized r600 ^ My guess is that you need this in ~/.drirc or /etc/drirc: driconf device screen=0 driver=r600 application name=all option name=fthrottle_mode value=0/ option name=vblank_mode value=0/ /application /device /driconf See http://marc.info/?l=openbsd-cvsm=130679235018645w=2 I have an r600 as well and it works very well with the above dri config.
Re: Regression with ATI Mobility Radeon HD 3400
On Fri, Oct 19, 2012 at 12:10:31PM +0300, Lars Engblom wrote: Thanks, I will try it as soon as I get home to my computer. I would suggest to add this information to the radeon manual page. I have read that page several times playing with options found there without luck for this card. It is there people will first look. I guess this config file hack was supposed to be a temporary measure. But nobody is working on enhancing r600 support currently so for the time being it is required. Instead of changing the man page we could add this /etc/drirc to the xetc set to make it work out of the box. And remove it from the set once r600 support has been fixed to work without this config hack. On 10/19/12 11:59, Stefan Sperling wrote: On Fri, Oct 19, 2012 at 09:06:24AM +0300, Lars Engblom wrote: At some point a half year to one year ago, some changes were made to current that made it impossible to watch movies on my computer. The graphics is lagging so terrible that it is not possible to watch. [26.263] (II) AIGLX: Loaded and initialized r600 ^ My guess is that you need this in ~/.drirc or /etc/drirc: driconf device screen=0 driver=r600 application name=all option name=fthrottle_mode value=0/ option name=vblank_mode value=0/ /application /device /driconf See http://marc.info/?l=openbsd-cvsm=130679235018645w=2 I have an r600 as well and it works very well with the above dri config.
Re: openbsd 5.1 and ospfd
On 10/18/2012 04:48 PM, Claudio Jeker wrote: On Thu, Oct 18, 2012 at 03:50:45PM -0400, Mathieu Gignac wrote: Hi, I'm testing ospf on openBSD 5.1 on a lab before sending firewalls in production and I'm actually having a problem with ospfd that I do not understand. I already work with ospfd on openBSD 4.7 and 4.9 and I'm wondering if you could help me with my problem. I have 2 firewalls connected to each other. FW1 vr0 - FW2 vr0 Both routers are communicating together via ospf and exchanging informations. The only problem is that routing tables on each routers are not updated or ospf does not seam to exchange routes with each others. Here is the information of each firewall. - FW1 : - vr0 : 10.10.10.1/24 vr2 : 192.168.0.1/24 snip ospfctl show nei ID Pri StateDeadTime Address Iface Uptime 192.168.1.1 1 FULL/DR 00:00:35 10.10.10.2 vr0 00:00:10 ospfctl show rib Destination Nexthop Path TypeType CostUptime 10.10.10.0/2410.10.10.1Intra-Area Network 10 00:00:16 ospfctl show fib flags: * = valid, O = OSPF, C = Connected, S = Static Flags Prio Destination Nexthop *C4 10.10.10.0/24link#1 *O 32 10.10.10.0/2410.10.10.1 *C0 127.0.0.0/8 link#0 *S8 127.0.0.0/8 127.0.0.1 * 4 127.0.0.1/32 127.0.0.1 C4 192.168.0.0/24 link#3 *S8 224.0.0.0/4 127.0.0.1 I also tried redistribute 192.168.0.0/24 and redistribute connected and it is not working. In the show fib output you can see that 192.168.0.0/24 is not a valid route. In other words the link is most probably not up on the interface and therefor the information is not distributed. Make sure that vr2 has link and is up and then the route should be valid in ospfd and redistributed to the other side. Thanks for your quick answers. I forgot about link-state in OSPF, so it is why it was not working and not distributing routes.
Re: iked vs. isakmpd + carp
On 10/19/2012 1:16 AM, Jim Miller wrote: Two part question: 1. Anyone had any success getting iked and carp working on OpenBSD 5.1 (amd64)? We can get it working with isakmpd. The issue seems to be that iked wants to send out packets as the physical interface IP instead of the carp IP. iked documentation eludes to the fact that it should work. In my experience under 5.1 isakmpd wants to use the IP from the real physical interface instead of the virtual carp interface too, so I have to use the local x.x.x.x command in ipsec.conf, where x.x.x.x = my carp IP -- this forces it onto the carp IP and all is well. iked.conf(5) has a similar local command. Does it not work? and keep in mind the caveat: iked is not yet finished and is missing some important security features. It should not yet be used in production networks. -- iked(8)
Novedoso curso de Meta-Habilidades Directivas y Gerenciales”
Si no puede visualizar correctamente este correo, le pedimos que lo arrastre a su Bandeja de Entrada Apreciable Ejecutivo: TIEM de México Empresa Líder en Capacitación y Actualización de Capital Humano Trae para usted su novedoso curso denominado: Meta-Habilidades Directivas y Gerenciales Ciudad de México, el día 30 de Octubre de 2012 Inscríbase 5 días antes de la fecha del Curso y obtenga un descuento del 15% con Inversión Inmediata O bien, por cada dos participantes inscritos en tarifa de Inversión normal, el tercero es completamente gratis La dirección de la empresa, se enfrenta en el día a día, en la necesidad de liderar personas para alcanzar un mismo fin, motivarlas y administrar con eficacia el tiempo, tomar decisiones importantes, resolver conflictos, ser altamente competitiva, aun bajo presión, por lo tanto contar con las técnicas y habilidades de gestión directiva y gerencial es una necesaria prioritaria para la alta dirección. Actualizar las técnicas de desempeño en la gestión directiva y gerencial, permiten eficientar y dar eficacia a los resultados que, en coordinación con todas las áreas de la empresa, permitan la alta competitividad y el logro de los resultados. Por esta razón, contar con META HABILIDADES, les proporcionará las herramientas de gestión directiva y gerencial necesarias, que facilitarán la organización y conducción de la empresa, ante un entorno lleno de cambios y altamente dinámico para hacer a la organización mas fuerte y competitiva en el mercado. Objetivo del Curso: Al concluir el evento, los participantes conocerán y podrán aplicar modernas técnicas, comprobadas así como altamente estratégicas y especializadas, que les permitirán llevar a cabo la gestión directiva de una manera mas eficaz incrementando su potencial personal para influir y motivar a todo el personal que conducen en la consecución de los objetivos de la empresa. Método Didáctico: Técnica Expositiva Auto-evaluaciones para identificar áreas de mejora personal Dinámica de grupos: Ejercicios y dinámicas en equipo Proyección y discusión de videos en temas específicos Análisis de Casos, entre otras y role playing Dirigido a: Ejecutivos de Alto nivel, (Directores, Gerentes, Jefes de Departamento, Supervisores) y en General todos los Ejecutivos, que por la naturaleza de sus funciones Intervengan en el desarrollo estratégico de la empresa. Duración: 10 horas Para mayor información, favor de responder este correo con los siguientes datos: Empresa: Nombre: Ciudad: Teléfono: O si lo prefiere comuníquese a los teléfonos: Del DF al 5611-0969 con 10 líneas Interior del País Lada sin Costo 01 800 900 TIEM (8436) Aceptamos todas las TDC y Débito. **Promoción: 3 meses sin Intereses pagando con American Express **Aplica solo con Inversión Normal ®Todos los Derechos Reservados ©2011 TIEM Talento e Innovación Empresarial de México Este Mensaje le ha sido enviado como usuario de TIEM de México o bien un usuario le refirió para recibir este boletín. Como usuario de TIEM de México, en este acto autoriza de manera expresa que TIEM de México le puede contactar vía correo electrónico u otros medios. Si usted ha recibido este mensaje por error, haga caso omiso de él y reporte su cuenta respondiendo este correo con el subject BAJABD Tenga en cuenta que la gestión de nuestras bases de datos es de suma importancia y no es intención de la empresa la inconformidad del receptor.
Re: iked vs. isakmpd + carp
Hi, On Fri, Oct 19, 2012 at 8:10 PM, Tyler Morgan tyl...@tradetech.net wrote: On 10/19/2012 1:16 AM, Jim Miller wrote: Two part question: 1. Anyone had any success getting iked and carp working on OpenBSD 5.1 (amd64)? We can get it working with isakmpd. The issue seems to be that iked wants to send out packets as the physical interface IP instead of the carp IP. iked documentation eludes to the fact that it should work. thanks for reporting, I can reproduce the problem. In my experience under 5.1 isakmpd wants to use the IP from the real physical interface instead of the virtual carp interface too, so I have to use the local x.x.x.x command in ipsec.conf, where x.x.x.x = my carp IP -- this forces it onto the carp IP and all is well. iked.conf(5) has a similar local command. Does it not work? It does not work. You can see that iked is setting the carp address correctly but the address on the wire is the primary one. Fail. The code doesn't bind() to the IP used in the local command and the kernel uses the primary address for the related route. btw. you can also specify local carp0 instead of the IP address and it will pick the interface's first address. and keep in mind the caveat: iked is not yet finished and is missing some important security features. It should not yet be used in production networks. -- iked(8) Yeah, but we're working on it. I actually added this comment before mikeb@ added support for SA expiration, lifetimes and retransmits. So iked is still not ready, but the situation is much better now ;-) reyk
Re: iked vs. isakmpd + carp
I think this can be fixed by: shell# cat /etc/isakmpd/isakmpd.conf [General] Listen-on= 1.2.3.4 I runs this setup in prod. It works. In my case 1.2.3.4 is a CARP:ed IP. //mxb On 19 okt 2012, at 20:10, Tyler Morgan tyl...@tradetech.net wrote: isakmpd wants to use the IP from the real physical interface
Re: iked vs. isakmpd + carp
Thanks Reky. I'll stick with isakmp for now but would like to swtich to iked when its ready. BTW. Any known issues with isakmp and groups larger than modp1024? I still can't get isakmpd to use anything larger than that? -Jim On 10/19/12 3:35 PM, Reyk Floeter wrote: Hi, On Fri, Oct 19, 2012 at 8:10 PM, Tyler Morgan tyl...@tradetech.net wrote: On 10/19/2012 1:16 AM, Jim Miller wrote: Two part question: 1. Anyone had any success getting iked and carp working on OpenBSD 5.1 (amd64)? We can get it working with isakmpd. The issue seems to be that iked wants to send out packets as the physical interface IP instead of the carp IP. iked documentation eludes to the fact that it should work. thanks for reporting, I can reproduce the problem. In my experience under 5.1 isakmpd wants to use the IP from the real physical interface instead of the virtual carp interface too, so I have to use the local x.x.x.x command in ipsec.conf, where x.x.x.x = my carp IP -- this forces it onto the carp IP and all is well. iked.conf(5) has a similar local command. Does it not work? It does not work. You can see that iked is setting the carp address correctly but the address on the wire is the primary one. Fail. The code doesn't bind() to the IP used in the local command and the kernel uses the primary address for the related route. btw. you can also specify local carp0 instead of the IP address and it will pick the interface's first address. and keep in mind the caveat: iked is not yet finished and is missing some important security features. It should not yet be used in production networks. -- iked(8) Yeah, but we're working on it. I actually added this comment before mikeb@ added support for SA expiration, lifetimes and retransmits. So iked is still not ready, but the situation is much better now ;-) reyk
客户资料之家
æç¼åééç¸çªæ¤ éæ¹æ¦´ç¦ç«æ»éª¨å·æªä¼é¢¤è´¢æ éµ è¾½è¿·é ±æ¢°æ¶æ±å£èçæªç«é 婶宴å½å亨ççæ¯ç ¨åæ®åæ¹åæ
OpenBSD upgrade guide 5.2?
Does anyone know when the upgrade guides are usually posted? I know we're a couple of weeks away from the release, but I also thought I read that 5.2 cds had already been shipped to some locations, which would imply that it's pretty much ready for release? I figured I'd take some time to look over it ahead of time.
