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.
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: 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: [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: 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: Scheduler improvements
Hi people,
after a (very) long time of silence on this, here's another go at it. This time,
I basically started from scratch and used a bit of code by Christiano Haesberth
which had been posted to tech@ a while ago to detect CPU topology on amd64 and
take that into account when moving processes between CPUs.
This version has one single queue per CPU, getting rid of a) the one single
system
wide runqueue and b) the queue for expired processes. This simplifies things a
bit
and performs just as well as my previous versions (the only difference is the
order
in which expired procs get selected for running on a CPU). One advantage is that
process selection is in O(log n) of the number of processes on the CPU and
depends
neither on the total number of processes nor the number of expired processes in
the runqueue.
The factors for the cost of moving a process between hardware threads, cpu dies
and cpu packages are guesses now, I think those will have to be tuned further.
Sadly, I haven't had access to a multiprocessor machine with a more diverse
architecture than "a bunch of cores on the same die".
I tested this on some more machines than before; a Core i5, an i7 and my Core 2
Duo and on all machines (perceived) interactivity was improved. The simplest
benchmark I used was playing back a 1080p version of Big Buck Bunny with
mplayer.
All machines I tested on had Intel graphics cards, one GM965 (on the Core2Duo)
and
the others were Sandy Bridge devices. On all of them, playback was smoother with
the i7 being most visible. With the default scheduler, watching the movie was a
big pain due to heavy frame-dropping, with my patch, the movie was watchable
(with
frame dropping only (barely) noticable in scenes with much movement).
As before, I'm looking forward to anything you have to comment, especially cool
benchmark ideas or the like.
--
Gregor Best
Index: arch/amd64/amd64/identcpu.c
===
RCS file: /cvs/src/sys/arch/amd64/amd64/identcpu.c,v
retrieving revision 1.39
diff -u -r1.39 identcpu.c
--- arch/amd64/amd64/identcpu.c 19 Sep 2012 20:19:31 - 1.39
+++ arch/amd64/amd64/identcpu.c 4 Oct 2012 21:27:55 -
@@ -202,6 +202,8 @@
void via_nano_setup(struct cpu_info *ci);
+void cpu_topology(struct cpu_info *ci);
+
void
via_nano_setup(struct cpu_info *ci)
{
@@ -470,4 +472,123 @@
sensordev_install(&ci->ci_sensordev);
#endif
}
+
+ cpu_topology(ci);
+}
+
+/*
+ * Base 2 logarithm of an int. returns 0 for 0 (yeye, I know).
+ */
+static int
+log2(unsigned int i)
+{
+ int ret = 0;
+
+ while (i >>= 1)
+ ret++;
+
+ return (ret);
+}
+
+static int
+mask_width(u_int x)
+{
+ int bit;
+ int mask;
+ int powerof2;
+
+ powerof2 = ((x - 1) & x) == 0;
+ mask = (x << (1 - powerof2)) - 1;
+
+ /* fls */
+ if (mask == 0)
+ return (0);
+ for (bit = 1; mask != 1; bit++)
+ mask = (unsigned int)mask >> 1;
+
+ return (bit);
+}
+
+/*
+ * Build up cpu topology for given cpu, must run on the core itself.
+ */
+void
+cpu_topology(struct cpu_info *ci)
+{
+ u_int32_t eax, ebx, ecx, edx;
+ u_int32_t apicid, max_apicid, max_coreid;
+ u_int32_t smt_bits, core_bits, pkg_bits;
+ u_int32_t smt_mask, core_mask, pkg_mask;
+
+ /* We need at least apicid at CPUID 1 */
+ CPUID(0, eax, ebx, ecx, edx);
+ if (eax < 1)
+ goto no_topology;
+
+ /* Initial apicid */
+ CPUID(1, eax, ebx, ecx, edx);
+ apicid = (ebx >> 24) & 0xff;
+
+ if (strcmp(cpu_vendor, "AuthenticAMD") == 0) {
+ /* We need at least apicid at CPUID 0x8008 */
+ CPUID(0x8000, eax, ebx, ecx, edx);
+ if (eax < 0x8008)
+ goto no_topology;
+
+ CPUID(0x8008, eax, ebx, ecx, edx);
+ core_bits = (ecx >> 12) & 0xf;
+ if (core_bits == 0)
+ goto no_topology;
+ /* So coreidsize 2 gives 3, 3 gives 7... */
+ core_mask = (1 << core_bits) - 1;
+ /* Core id is the least significant considering mask */
+ ci->ci_core_id = apicid & core_mask;
+ /* Pkg id is the upper remaining bits */
+ ci->ci_pkg_id = apicid & ~core_mask;
+ ci->ci_pkg_id >>= core_bits;
+ } else if (strcmp(cpu_vendor, "GenuineIntel") == 0) {
+ /* We only support leaf 1/4 detection */
+ CPUID(0, eax, ebx, ecx, edx);
+ if (eax < 4)
+ goto no_topology;
+ /* Get max_apicid */
+ CPUID(1, eax, ebx, ecx, edx);
+ max_apicid = (ebx >> 16) & 0xff;
+ /* Get max_coreid */
+ CPUID2(4, 0, eax, ebx, ecx, edx);
+ max_coreid = ((eax >> 26) & 0x3f) + 1;
+ /* SMT */
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]
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
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
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.
Re: [PATCH] ospf6d problem when a route already exists with a different nexthop
On Thu, 4 Oct 2012 14:25:35 +0200 Claudio Jeker 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: QLogic device FCP RESPONSE: 0x2
On Thu, Oct 4, 2012 at 11:52 AM, mohit sah 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#
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: [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
[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",
+
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#
