QLogic device FCP RESPONSE: 0x2
*HI *I have* **qlogic* FC HBA card which is not detecting the LUN I think the problem is with targeting...I have diabled acpicpu at boot time and using OpenBSD 5.1 amd64 Any advice or help. * isp0* at pci4 dev 0 function 0 QLogic ISP2432 rev 0x03: apic 9 int 6 *isp0*: board type 2422 rev 0x3, resident firmware rev 4.0.26 scsibus0 at *isp0*: 512 targets, WWPN 2124ff364ae8, WWNN 2024ff364ae8 *isp0*: 0.0.0 FCP RESPONSE: 0x2 *isp0*: 0.0.0 FCP RESPONSE: 0x2 *isp0*: 0.1.0 FCP RESPONSE: 0x2 *isp0*: 0.1.0 FCP RESPONSE: 0x2 isp1 at pci4 dev 0 function 1 QLogic ISP2432 rev 0x03: apic 9 int 13 isp1: board type 2422 rev 0x3, resident firmware rev 4.0.26 scsibus1 at isp1: 512 targets, WWPN 2124ff364ae9, WWNN 2024ff364ae9 isp1: 0.0.0 FCP RESPONSE: 0x2 isp1: 0.0.0 FCP RESPONSE: 0x2 isp1: 0.1.0 FCP RESPONSE: 0x2 isp1: 0.1.0 FCP RESPONSE: 0x2 - Complete dmesg can be shown http://old.nabble.com/Mount-San-Disk-from-IBM-DS3400-tc34491545.html#
[PATCH] ospf6d problem when a route already exists with a different nexthop
Here is a patch adapted from ospfd patch of Tue Sep 25 11:25:41 2007
UTC (the one of version 1.52 of kroute.c):
Last missing piece in the equal cost multipath support for ospfd.
Send all possible nexthops to the parent process and correctly sync
the RIB, FIB and kernel routing table. Based on initial work by pyr@.
OK pyr@ norby@
PS: don't forget that you need to enable multipath support via a sysctl
It seems to solve my problem but not perfectly.
When starting ospf6d with the best link between 2 hosts down, fib contains
2 other routes comme from 2 other hosts (these 2 routes have equal cost).
When the link came UP, these 2 routes are removed and replaced by the best
route; that's alright.
Next when the link goes down, the 2 alternative routes are well added in fib
but the precedent best route is still in the fib (I see it with route -n -v
show |grep TargetIP). May be an important point: TargetIP is an IPv6 on lo1.
I can't find why; if you have any idea... I have a test network so I can make
test easily...
Manuel
= The Patch =
diff -u ospf6d.uptodate/kroute.c ospf6d.patch1/kroute.c
--- ospf6d.uptodate/kroute.cThu Sep 20 15:25:33 2012
+++ ospf6d.patch1/kroute.c Thu Sep 27 18:01:37 2012
@@ -59,6 +59,8 @@
intkr_redist_eval(struct kroute *, struct rroute *);
void kr_redistribute(struct kroute_node *);
intkroute_compare(struct kroute_node *, struct kroute_node *);
+intkr_change_fib(struct kroute_node *, struct kroute *, int, int);
+intkr_delete_fib(struct kroute_node *);
struct kroute_node *kroute_find(const struct in6_addr *, u_int8_t);
struct kroute_node *kroute_matchgw(struct kroute_node *,
@@ -140,18 +142,102 @@
}
int
-kr_change(struct kroute *kroute)
+kr_change_fib(struct kroute_node *kr, struct kroute *kroute, int krcount,
+int action)
{
+ int i;
+ struct kroute_node *kn, *nkn;
+
+ if (action == RTM_ADD) {
+ /*
+* First remove all stale multipath routes.
+* This step must be skipped when the action is RTM_CHANGE
+* because it is already a single path route that will be
+* changed.
+*/
+ for (kn = kr; kn != NULL; kn = nkn) {
+ for (i = 0; i krcount; i++) {
+ if
(IN6_ARE_ADDR_EQUAL(kn-r.nexthop,kroute[i].nexthop))
+ break;
+ }
+ nkn = kn-next;
+ if (i == krcount)
+ /* stale route */
+ if (kr_delete_fib(kn) == -1)
+ log_warnx(kr_delete_fib failed);
+ log_debug(kr_update_fib: before: %s%s,
+ log_in6addr(kn-r.nexthop),
+ i == krcount ? (deleted) : );
+ }
+ }
+
+ /*
+* now add or change the route
+*/
+ for (i = 0; i krcount; i++) {
+ /* nexthop within 127/8 - ignore silently */
+ if (kr IN6_IS_ADDR_LOOPBACK(kr-r.nexthop))
+ continue;
+
+ if (action == RTM_ADD kr) {
+ for (kn = kr; kn != NULL; kn = kn-next) {
+ if
(IN6_ARE_ADDR_EQUAL(kn-r.nexthop,kroute[i].nexthop))
+ break;
+ }
+
+ log_debug(kr_update_fib: after : %s%s,
+log_in6addr(kroute[i].nexthop),
+kn == NULL ? (added) : );
+
+ if (kn != NULL)
+ /* nexthop already present, skip it */
+ continue;
+ } else
+ /* modify first entry */
+ kn = kr;
+
+ /* send update */
+ if (send_rtmsg(kr_state.fd, action, kroute[i]) == -1)
+ return (-1);
+
+ /* create new entry unless we are changing the first entry */
+ if (action == RTM_ADD)
+ if ((kn = calloc(1, sizeof(*kn))) == NULL)
+ fatal(NULL);
+
+ kn-r.prefix = kroute[i].prefix;
+ kn-r.prefixlen = kroute[i].prefixlen;
+ kn-r.nexthop = kroute[i].nexthop;
+ kn-r.scope = kroute[i].scope;
+ kn-r.flags = kroute[i].flags | F_OSPFD_INSERTED;
+ kn-r.ext_tag = kroute[i].ext_tag;
+ rtlabel_unref(kn-r.rtlabel); /* for RTM_CHANGE */
+ kn-r.rtlabel = kroute[i].rtlabel;
+ if (action == RTM_ADD) {
+ if (kroute_insert(kn) == -1) {
+ log_debug(kr_update_fib: cannot insert %s,
+ log_in6addr(kn-r.nexthop));
+
Re: [PATCH] ospf6d problem when a route already exists with a different nexthop
On Thu, Oct 04, 2012 at 11:54:00AM +0200, Manuel Guesdon wrote: Here is a patch adapted from ospfd patch of Tue Sep 25 11:25:41 2007 UTC (the one of version 1.52 of kroute.c): Last missing piece in the equal cost multipath support for ospfd. Send all possible nexthops to the parent process and correctly sync the RIB, FIB and kernel routing table. Based on initial work by pyr@. OK pyr@ norby@ PS: don't forget that you need to enable multipath support via a sysctl It seems to solve my problem but not perfectly. When starting ospf6d with the best link between 2 hosts down, fib contains 2 other routes comme from 2 other hosts (these 2 routes have equal cost). When the link came UP, these 2 routes are removed and replaced by the best route; that's alright. Next when the link goes down, the 2 alternative routes are well added in fib but the precedent best route is still in the fib (I see it with route -n -v show |grep TargetIP). May be an important point: TargetIP is an IPv6 on lo1. I can't find why; if you have any idea... I have a test network so I can make test easily... I started a large sync of the ospf6d kroute code with the one in ospfd. In other words adding proper support for priorities. With that in the tracking gets much simpler. I need a few more days and some testing before sending the diff out. -- :wq Claudio
add support for elantech touchpads to pms(4)
This diff adds support for Elantech touchpads to pms(4), so that
synpatics(4) will attach and allow configuration of edge-scrolling,
2-finger scrolling, toggle tap-to-click on/off, etc.
Currently, such pads only work in compat mode, which means they are
recognized as regular PS/2 mice and cannot be properly configured.
This patch adds support for hardware version 1, 2, and 3.
Linux also supports version 4 but this driver does not yet.
I have hardware version 3 which seems to work well, but code for
the other versions is entirely untested. If you have a machine with
a touchpad please try this diff. If it's an Elantech 1, 2, or 3,
it should be detected as such automatically. (If you're looking
for an easy way to configure the pad I'd suggest installing Xfce
and going to the Mouse/Touchpad settings window.)
If I don't get test reports for versions 1 and 2, my plan is to
commit the support code for versions 1 and 2 but only attach to
version 3. Bugs in touchpad support code can be rather irritating
so I'd prefer to keep versions 1 and 2 in PS/2 compat mode until
somebody can confirm that the code actually works. Thanks!
Index: pms.c
===
RCS file: /cvs/src/sys/dev/pckbc/pms.c,v
retrieving revision 1.31
diff -u -p -r1.31 pms.c
--- pms.c 22 Jul 2012 18:28:36 - 1.31
+++ pms.c 4 Oct 2012 12:56:24 -
@@ -57,6 +57,8 @@ struct pms_protocol {
#define PMS_INTELLI1
#define PMS_SYNAPTICS 2
#define PMS_ALPS 3
+#define PMS_ELANTECH_V14
+#define PMS_ELANTECH 5
u_int packetsize;
int (*enable)(struct pms_softc *);
int (*ioctl)(struct pms_softc *, u_long, caddr_t, int, struct proc *);
@@ -108,6 +110,27 @@ struct alps_softc {
#define ALPS_PRESSURE 40
};
+struct elantech_softc {
+ int hw_version;
+ int flags;
+#define ELANTECH_F_REPORTS_PRESSURE0x01
+#define ELANTECH_F_HAS_ROCKER 0x02
+#define ELANTECH_F_PARITY_REVERSED 0x03
+#define ELANTECH_F_2FINGER_PACKET 0x04
+#define ELANTECH_F_HW_V1_OLD 0x08
+
+ int min_x, min_y;
+ int max_x, max_y;
+
+ u_char parity[256];
+ u_char p1, p2, p3;
+
+ /* Compat mode */
+ int wsmode;
+ int old_x, old_y;
+ u_int old_buttons;
+};
+
struct pms_softc { /* driver status information */
struct device sc_dev;
@@ -129,6 +152,7 @@ struct pms_softc { /* driver status inf
const struct pms_protocol *protocol;
struct synaptics_softc *synaptics;
struct alps_softc *alps;
+ struct elantech_softc *elantech;
u_char packet[8];
@@ -227,6 +251,17 @@ intpms_ioctl_alps(struct pms_softc *, u
intpms_sync_alps(struct pms_softc *, int);
void pms_proc_alps(struct pms_softc *);
+intpms_enable_elantech(struct pms_softc *);
+intpms_ioctl_elantech(struct pms_softc *, u_long, caddr_t, int,
+struct proc *);
+intpms_sync_elantech_v1(struct pms_softc *, int);
+intpms_sync_elantech_v2(struct pms_softc *, int);
+intpms_sync_elantech(struct pms_softc *, int);
+void pms_proc_elantech_v1(struct pms_softc *);
+void pms_proc_elantech_v2(struct pms_softc *);
+void pms_proc_elantech_v3(struct pms_softc *);
+void pms_proc_elantech(struct pms_softc *);
+
intsynaptics_set_mode(struct pms_softc *, int);
intsynaptics_query(struct pms_softc *, int, int *);
intsynaptics_get_hwinfo(struct pms_softc *);
@@ -235,6 +270,15 @@ void synaptics_sec_proc(struct pms_softc
intalps_sec_proc(struct pms_softc *);
intalps_get_hwinfo(struct pms_softc *);
+void elantech_send_input(struct pms_softc *, u_int, int, int, int, int);
+intelantech_id_query(struct pms_softc *, int, u_char *);
+intelantech_get_hwinfo(struct pms_softc *);
+intelantech_ps2_cmd(struct pms_softc *, u_char);
+intelantech_read_reg(struct pms_softc *, u_char, u_char *);
+intelantech_write_reg(struct pms_softc *, u_char, u_char);
+intelantech_set_absolute_mode(struct pms_softc *);
+
+
struct cfattach pms_ca = {
sizeof(struct pms_softc), pmsprobe, pmsattach, NULL,
pmsactivate
@@ -293,6 +337,24 @@ const struct pms_protocol pms_protocols[
pms_proc_alps,
NULL
},
+ /* Elantech touchpad (hardware version 1) */
+ {
+ PMS_ELANTECH_V1, 4,
+ pms_enable_elantech,
+ pms_ioctl_elantech,
+ pms_sync_elantech_v1,
+ pms_proc_elantech_v1,
+ NULL
+ },
+ /* Elantech touchpad */
+ {
+ PMS_ELANTECH, 6,
+ pms_enable_elantech,
+ pms_ioctl_elantech,
+ pms_sync_elantech,
+ pms_proc_elantech,
+ NULL
+ },
};
int
@@ -1358,5 +1420,643 @@ pms_proc_alps(struct pms_softc *sc)
alps-old_x = x;
Re: QLogic device FCP RESPONSE: 0x2
On Thu, Oct 4, 2012 at 11:52 AM, mohit sah mohits...@gmail.com wrote: *HI *I have* **qlogic* FC HBA card which is not detecting the LUN I think the problem is with targeting...I have diabled acpicpu at boot time and using OpenBSD 5.1 amd64 Any advice or help. I don't know if this is the right advice, but I suspect you need to recompile your kernel with the following option: ISP_FIRMWARE_2400 Ciao, David * isp0* at pci4 dev 0 function 0 QLogic ISP2432 rev 0x03: apic 9 int 6 *isp0*: board type 2422 rev 0x3, resident firmware rev 4.0.26 scsibus0 at *isp0*: 512 targets, WWPN 2124ff364ae8, WWNN 2024ff364ae8 *isp0*: 0.0.0 FCP RESPONSE: 0x2 *isp0*: 0.0.0 FCP RESPONSE: 0x2 *isp0*: 0.1.0 FCP RESPONSE: 0x2 *isp0*: 0.1.0 FCP RESPONSE: 0x2 isp1 at pci4 dev 0 function 1 QLogic ISP2432 rev 0x03: apic 9 int 13 isp1: board type 2422 rev 0x3, resident firmware rev 4.0.26 scsibus1 at isp1: 512 targets, WWPN 2124ff364ae9, WWNN 2024ff364ae9 isp1: 0.0.0 FCP RESPONSE: 0x2 isp1: 0.0.0 FCP RESPONSE: 0x2 isp1: 0.1.0 FCP RESPONSE: 0x2 isp1: 0.1.0 FCP RESPONSE: 0x2 - Complete dmesg can be shown http://old.nabble.com/Mount-San-Disk-from-IBM-DS3400-tc34491545.html#
Re: [PATCH] ospf6d problem when a route already exists with a different nexthop
On Thu, 4 Oct 2012 14:25:35 +0200 Claudio Jeker cje...@diehard.n-r-g.com wrote: | I started a large sync of the ospf6d kroute code with the one in ospfd. In | other words adding proper support for priorities. With that in the | tracking gets much simpler. I need a few more days and some testing before | sending the diff out. OK. I'll be happy to test it ! Manuel
Re: ral rt2661 tx interrupt race fix
On Sun, Sep 30, 2012 at 10:32:23PM +0100, Tom Murphy wrote: Stefan, Your patch works well on my system: ral0 at pci0 dev 14 function 0 Ralink RT2661 rev 0x00: irq 10, address 00:14:85:d5:39:bb ral0: MAC/BBP RT2661D, RF RT2529 (MIMO XR) Only problem is downloading from the net is extremely slow. Benchmarks have it at 512 KB/sec as opposed to 10 megabits/s. This is (internet) - OpenBSD - ral0 - wifi client But it doesn't crash or bring up OACTIVE flag anymore which is fantastic.. however, it's a little to slow to use with any regularity. Uploads are fine (wifi - ral(4) - OpenBSD - out to the net). I've already replied to Tom in private requesting some additional testing but I would still be interested in other reports about transmission speed issues with ral. I've also noticed that my ral-based AP can be ridiculously slow. I believe this is a separate bug which is independent of the OACTIVE lock-up problem. Is anyone else out there seeing this, too? IIRC dragonfly have some ral performance fixes in their git history which haven't been ported back to OpenBSD yet.
tx dma segments for if_vr
Darren Tucker's vlan tagging for vr motivated me. Here is a diff that
implements transmit DMA segments, instead of copying fragmented mbufs every
time. This should be a win for userland traffic, and NFS. It also implements a
FreeBSD feature to only ask for TX completion interrupts every 8 packets,
instead of every packet, which is another win for weak CPUs. FreeBSD has been
doing DMA tx segments and 1/8 completion interrupts for 4 years across the same
chips. Annoyingly, on first glance, the rhine chip still seems to send the same
number completion interrupts. But it's clear that bus_dmamap_load_mbuf no
longer fails at the top of vr_encap on packets with 8 or less mbuf fragments,
avoiding the whole new mbuf and m_copydata dance for the majority of situations
now. The next win would be to copy reyk's method from if_myx to create a new
DMA segment for padding packets VR_MINFRAMELEN instead of create a whole new
mbuf and copying. Micro-optimizations for micro-platforms.
This is heavily influenced by yongari@FreeBSD's work 4 years ago. (In fact,
maybe too much so. As far as I can tell, allowing for DMA transfers of MCLBYTES
* VR_MAXFRAGS is overkill since a packet over the size of MCLBYTES isn't even
possible with this chip. Also returns from vr_encap are now ENOFBUFS but the
error gets ignored upstream at this point.)
Index: if_vr.c
===
RCS file: /cvs/src/sys/dev/pci/if_vr.c,v
retrieving revision 1.115
diff -u -r1.115 if_vr.c
--- if_vr.c 18 Sep 2012 14:49:44 - 1.115
+++ if_vr.c 4 Oct 2012 17:12:08 -
@@ -113,7 +113,7 @@
NULL, vr, DV_IFNET
};
-int vr_encap(struct vr_softc *, struct vr_chain *, struct mbuf *);
+int vr_encap(struct vr_softc *, struct vr_chain **, struct mbuf *);
void vr_rxeof(struct vr_softc *);
void vr_rxeoc(struct vr_softc *);
void vr_txeof(struct vr_softc *);
@@ -720,13 +720,17 @@
cd = sc-vr_cdata;
ld = sc-vr_ldata;
+
+ cd-vr_tx_pkts = 0;
+ cd-vr_tx_cnt = 0;
+
for (i = 0; i VR_TX_LIST_CNT; i++) {
cd-vr_tx_chain[i].vr_ptr = ld-vr_tx_list[i];
cd-vr_tx_chain[i].vr_paddr =
sc-sc_listmap-dm_segs[0].ds_addr +
offsetof(struct vr_list_data, vr_tx_list[i]);
- if (bus_dmamap_create(sc-sc_dmat, MCLBYTES, 1,
+ if (bus_dmamap_create(sc-sc_dmat, MCLBYTES * VR_MAXFRAGS,
VR_MAXFRAGS,
MCLBYTES, 0, BUS_DMA_NOWAIT, cd-vr_tx_chain[i].vr_map))
return (ENOBUFS);
@@ -984,11 +988,13 @@
* frames that have been transmitted.
*/
cur_tx = sc-vr_cdata.vr_tx_cons;
- while(cur_tx-vr_mbuf != NULL) {
- u_int32_t txstat;
+ while (cur_tx != sc-vr_cdata.vr_tx_prod) {
+
+ u_int32_t txstat, txctl;
int i;
txstat = letoh32(cur_tx-vr_ptr-vr_status);
+ txctl = letoh32(cur_tx-vr_ptr-vr_ctl);
if ((txstat VR_TXSTAT_ABRT) ||
(txstat VR_TXSTAT_UDF)) {
@@ -1002,7 +1008,7 @@
sc-vr_flags |= VR_F_RESTART;
break;
}
- VR_TXOWN(cur_tx) = htole32(VR_TXSTAT_OWN);
+ cur_tx-vr_ptr-vr_status = htole32(VR_TXSTAT_OWN);
CSR_WRITE_4(sc, VR_TXADDR, cur_tx-vr_paddr);
break;
}
@@ -1010,6 +1016,11 @@
if (txstat VR_TXSTAT_OWN)
break;
+ sc-vr_cdata.vr_tx_cnt--;
+ /* Only the first descriptor in the chain is valid. */
+ if ((txctl VR_TXCTL_FIRSTFRAG) == 0)
+ goto next;
+
if (txstat VR_TXSTAT_ERRSUM) {
ifp-if_oerrors++;
if (txstat VR_TXSTAT_DEFER)
@@ -1028,11 +1039,12 @@
cur_tx-vr_mbuf = NULL;
ifp-if_flags = ~IFF_OACTIVE;
+next:
cur_tx = cur_tx-vr_nextdesc;
}
sc-vr_cdata.vr_tx_cons = cur_tx;
- if (cur_tx-vr_mbuf == NULL)
+ if (sc-vr_cdata.vr_tx_cnt == 0)
ifp-if_timer = 0;
}
@@ -1164,19 +1176,22 @@
* pointers to the fragment pointers.
*/
int
-vr_encap(struct vr_softc *sc, struct vr_chain *c, struct mbuf *m_head)
+vr_encap(struct vr_softc *sc, struct vr_chain **cp, struct mbuf *m_head)
{
+ struct vr_chain *c = *cp;
struct vr_desc *f = NULL;
struct mbuf *m_new = NULL;
- u_int32_t vr_flags = 0, vr_status = 0;
+ u_int32_t vr_ctl = 0, vr_status = 0;
+ bus_dmamap_ttxmap;
+ int i;
if (sc-vr_quirks VR_Q_CSUM) {
if
Venda como un Guerrillero - Logre un Record de Ventas
Venda como un Guerrillero - Armas y Tácticas No Convencionales para Lograr un Récord de Ventas Panama 11 de Octubre / Sheraton Panama Hotel Convention Center Para sobrevivir en el medio actual de las ventas, ya sea de productos o servicios, usted debe poner en práctica el coraje de un mercenario veterano ¡Debe convertirse en un guerrillero!... Cierre más ventas y gane más cuentas con las estrategias probadas de las ventas de guerrilla. Hoy, hay una selva ahí afuera: Los presupuestos están limitados, la competencia es feroz y la decisión de compra a menudo se basa en el precio, pero usted tiene garantizado el cumplimiento de sus metas porque este seminario le ayudará a dominar las técnicas, los acercamientos y las habilidades que diferencian al Top 5 de los Vendedores de todos los demás y obtendrá lo que necesita para llevar sus ventas a un nivel más alto y poder disfrutar de las ventajas que siempre ha esperado de su carrera en ventas. Este seminario le ofrece los beneficios de una nueva forma revolucionaria de vender, incluyendo: 1. Las 10 características clave que destacan a los mejores vendedores de los demás Descubra los secretos del éxito de los vendedores guerreros. 2. Cómo implementar tácticas que convierten a los prospecto en clientes. 3. Piense como el cliente y adapte su acercamiento a la venta. 4. Domine la venta con valor agregado: La llave para mantener sus clientes a largo plazo. 5. Acorte su ciclo de venta y obtenga el sí más rápido. 6. Vuélvase indispensable y derrote a sus competidores. ¡Obtenga la Información Completa! Respondiendo los siguientes datos: -Empresa: -Nombre: -Puesto: -Tel: ( ) o Llame al (507) 2791083-279-0887 ESTE CORREO NO PUEDE SER CONSIDERADO INTRUSIVO YA QUE CUMPLE CON LAS POLÍTICAS ANTISPAM INTERNACIONALES Y LOCALES: Responda este correo con el Asunto unsus y automáticamente quedará fuera de nuestras listas. Este correo ha sido enviado a: tech@openbsd.org - 111254
Tecnicas Super Efectivas de Cobranza
[IMAGE] Técnicas Súper Efectivas de Cobranza Seminario ONLINE en VIVO este 08 de Octubre ¡Descubra el modo rápido, fácil y legal de recuperar su dinero de cuentas atrasadas! usted conocerá docenas de secretos que las empresas más efectivas usan para que los deudores paguen rápido, convierta el teléfono en su instrumento más poderoso de recuperación de cartera, cómo manejar cada excusa, cómo tratar con gente enojada y abusiva y aprenda a escribir cartas que le faciliten el trabajo. Recibirá herramientas y técnicas que necesita para ser más productivo, más eficaz y más contundente, sin mencionar que estará menos estresado en el trabajo. ¡No deje pasar esta única oportunidad! Entre los puntos a tratar se incluyen: * Cómo manejar excusas, mentiras y quejas de los deudores * Calme a clientes furiosos e irracionales con técnicas que trabajan como un encanto * Mantenga su organización fuera de problemas, sabiendo exactamente cuáles son sus derechos y límites legales * Haga que ingrese más dinero con sus cartas de cobranza * Mantenga el control de la conversación telefónica cuando los deudores tratan de conducirlo por otro lado * Sepa exactamente cuándo y cómo usted debería considerar la demanda judicial en cuentas atrasadas. Adquiera la información completa y sin compromiso solo responda este correo con asunto -Deseo Folleto Cobranza o Comuníquese al (507) 279-1083 / 279-0258 / 279-0887 - y a la brevedad lo recibira. ESTE CORREO NO PUEDE SER CONSIDERADO INTRUSIVO YA QUE CUMPLE CON LAS POLÍTICAS ANTISPAM INTERNACIONALES Y LOCALES: Responda este correo con el Asunto borrar y automáticamente quedará fuera de nuestras listas. [demime 1.01d removed an attachment of type image/jpeg which had a name of co-panama.jpg]
Re: Scheduler improvements
On Thu, Oct 04, 2012 at 23:42, Gregor Best wrote: As before, I'm looking forward to anything you have to comment, especially cool benchmark ideas or the like. A short one is building a kernel. Try before and after with make, make -j 2, and make -j 4. (or ncpu and ncpu * 2).
Re: [PATCH] Enable NTFS support on loongson
On Wed, Oct 03, 2012 at 22:26, Donovan Watteau wrote: Hello, The following diff enables NTFS support on loongson. I've been using it with external drives on my Yeeloong without any problem. Honestly, I think we should just enable it everywhere. You're unlikely to stick an ntfs disk in your vax, but vnd disk images are theoretically possible.
Re: ral rt2661 tx interrupt race fix
On Thu, Oct 04, 2012 at 07:21:50PM +0200, Stefan Sperling wrote: On Sun, Sep 30, 2012 at 10:32:23PM +0100, Tom Murphy wrote: Stefan, Your patch works well on my system: ral0 at pci0 dev 14 function 0 Ralink RT2661 rev 0x00: irq 10, address 00:14:85:d5:39:bb ral0: MAC/BBP RT2661D, RF RT2529 (MIMO XR) Only problem is downloading from the net is extremely slow. Benchmarks have it at 512 KB/sec as opposed to 10 megabits/s. This is (internet) - OpenBSD - ral0 - wifi client But it doesn't crash or bring up OACTIVE flag anymore which is fantastic.. however, it's a little to slow to use with any regularity. Uploads are fine (wifi - ral(4) - OpenBSD - out to the net). I've already replied to Tom in private requesting some additional testing but I would still be interested in other reports about transmission speed issues with ral. I've also noticed that my ral-based AP can be ridiculously slow. I believe this is a separate bug which is independent of the OACTIVE lock-up problem. Is anyone else out there seeing this, too? IIRC dragonfly have some ral performance fixes in their git history which haven't been ported back to OpenBSD yet. I gave up on my ral ap a couple of years ago due to ridiculous slowness, but the athn replacement was just as slow. Got a new motherboard going into the firewall shortly and may be motivated to recheck the wireless performance of -current then. Ken
Re: Scheduler improvements
On Thu, Oct 04, 2012 at 06:28:11PM -0400, Ted Unangst wrote: On Thu, Oct 04, 2012 at 23:42, Gregor Best wrote: As before, I'm looking forward to anything you have to comment, especially cool benchmark ideas or the like. A short one is building a kernel. Try before and after with make, make -j 2, and make -j 4. (or ncpu and ncpu * 2). A more realistic and useful one is rebuilding the full package tree with dpb, which is rather simple to try these days (just requires about 30GB of disk space) kernel will take a few minutes, dpb some hours to a few days...
Re: [PATCH] Enable NTFS support on loongson
On Thu, Oct 04, 2012 at 06:29:21PM -0400, Ted Unangst wrote: On Wed, Oct 03, 2012 at 22:26, Donovan Watteau wrote: Hello, The following diff enables NTFS support on loongson. I've been using it with external drives on my Yeeloong without any problem. Honestly, I think we should just enable it everywhere. You're unlikely to stick an ntfs disk in your vax, but vnd disk images are theoretically possible. The NTFS file system support would need to work on big endian systems before that would make sense. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
