Re: ksh: tab completion fix (again)
On cs, szept 27, 2012 at 01:42:25 +0400, Alexander Polakov wrote: I sent this diff in 2011 (?) with a bunch of other diffs. It fixes tab completion for filenames containing special characters like [], () and so. This code affects interactive mode only, and I don't know a way to do automated testing of this. Suggestions welcome. [...] I've been using this (and the other ones) since then. No problems neither on OpenBSD or Linux. Daniel -- LÉVAI Dániel PGP key ID = 0x83B63A8F Key fingerprint = DBEC C66B A47A DFA2 792D 650C C69B BE4C 83B6 3A8F
Re: Threads related SIGSEGV in random.c (diff, v2)
On Thursday, September 27, 2012, Philip Guenther wrote: On Thu, 27 Sep 2012, Alexey Suslikov wrote: Removing only local variables part reverts us to previous behavior (i.e. crashes). My guess is your program is calling srandom(), srandomdev(), initstate() or setstate() as well. Your diff doesn't protect the alteration of state, end_ptr, fptr, and rptr on those paths, so a call to initstate() while another thread is in random() can walk fptr and/or rptr out of the state array. Add the necessary locking in them and run your tests again. If not, well, crank up your debugging skills. What was the line of code that actually triggered the crash? Where did the bogus pointer come from? Crash: Program received signal SIGSEGV, Segmentation fault. [Switching to thread 1006387] 0x0cb33345cf6e in random () at /usr/src/lib/libc/stdlib/random.c:387 387 *fptr += *rptr; Back trace: Thread 10 (thread 1003160): #0 0x0cb33344135a in _thread_sys___thrsleep () at stdin:2 #1 0x0cb3315fac2a in pthread_cond_wait (condp=0xcb32a79c4b0, mutexp=Variable mutexp is not available. ) at /usr/src/lib/librthread/rthread_sync.c:500 #2 0x0cb129f836ba in gwlist_consume () from /usr/local/sbin/bearerbox #3 0x0cb129f121f1 in boxc_sender () from /usr/local/sbin/bearerbox #4 0x0cb129f828dd in new_thread () from /usr/local/sbin/bearerbox #5 0x0cb3315f911e in _rthread_start (v=Variable v is not available. ) at /usr/src/lib/librthread/rthread.c:122 #6 0x0cb333434f9b in __tfork_thread () at /usr/src/lib/libc/arch/amd64/sys/tfork_thread.S:75 Cannot access memory at address 0xcb32b27c000 0x0cb33345cf6e 387 *fptr += *rptr; I'm starting to believe that static globals are not good. They are incredibly good at what they do. If you're trying to say that they fundamentally can't be thread-safe, you'll need some extraordinary evidence for such a claim. What good they do? Cheers, Alexey
Threads related SIGSEGV in random.c (diff, v2)
On Thursday, September 27, 2012, Alexey Suslikov wrote: On Thursday, September 27, 2012, Philip Guenther wrote: On Thu, 27 Sep 2012, Alexey Suslikov wrote: Removing only local variables part reverts us to previous behavior (i.e. crashes). My guess is your program is calling srandom(), srandomdev(), initstate() or setstate() as well. Your diff doesn't protect the alteration of state, end_ptr, fptr, and rptr on those paths, so a call to initstate() while another thread is in random() can walk fptr and/or rptr out of the state array. Add the necessary locking in them and run your tests again. If not, well, crank up your debugging skills. What was the line of code that actually triggered the crash? Where did the bogus pointer come from? Crash: Program received signal SIGSEGV, Segmentation fault. [Switching to thread 1006387] 0x0cb33345cf6e in random () at /usr/src/lib/libc/stdlib/random.c:387 387 *fptr += *rptr; Back trace: Thread 10 (thread 1003160): #0 0x0cb33344135a in _thread_sys___thrsleep () at stdin:2 #1 0x0cb3315fac2a in pthread_cond_wait (condp=0xcb32a79c4b0, mutexp=Variable mutexp is not available. ) at /usr/src/lib/librthread/rthread_sync.c:500 #2 0x0cb129f836ba in gwlist_consume () from /usr/local/sbin/bearerbox #3 0x0cb129f121f1 in boxc_sender () from /usr/local/sbin/bearerbox #4 0x0cb129f828dd in new_thread () from /usr/local/sbin/bearerbox #5 0x0cb3315f911e in _rthread_start (v=Variable v is not available. ) at /usr/src/lib/librthread/rthread.c:122 #6 0x0cb333434f9b in __tfork_thread () at /usr/src/lib/libc/arch/amd64/sys/tfork_thread.S:75 Cannot access memory at address 0xcb32b27c000 0x0cb33345cf6e 387 *fptr += *rptr; I'm starting to believe that static globals are not good. They are incredibly good at what they do. If you're trying to say that they fundamentally can't be thread-safe, you'll need some extraordinary evidence for such a claim. What good they do? Philip, can you help us to write threaded test case (spawning a number of threads each calling random)?
¡Los mejores precios para tu proximo viaje!
[IMAGE][IMAGE][IMAGE] [IMAGE]Buzios Enero- FebreroU$S 1270.- [IMAGE]Imbassai Temporada bajaU$S 1740.- [IMAGE]Natalen Baja!U$S 1505.- [IMAGE]Porto Seguro en EneroU$S 1429.- [IMAGE] [IMAGE]Cancúnen Baja!U$S 2310.- [IMAGE]CubaHabana- VaraderoU$S 1655.- [IMAGE]Puerto PlataEneroU$S 2835.- [IMAGE]Isla Margarita Enero a MarzoU$S 1590.- [IMAGE] [IMAGE]Perú e Isla de Pascuaen NoviembreU$S 2305.- [IMAGE]Perú MágicoGrupal en OctubreU$S 1950.- [IMAGE]Punta del Este feriado de Octubre$ 1630.- [IMAGE]SALINAS-Ecuadorplaya U$S 1680.- [IMAGE] [IMAGE]Dubai, Vietnam, Camboya ThailandiaU$S 7080.- [IMAGE]India y Nepal Grupal en MarzoU$S 5385.- [IMAGE]Marruecos- Grupalen Octubre U$S 3765.- [IMAGE]Tailandia playasen FebreroU$S 4799.- [IMAGE]Si no desea seguir recibiendo novedades de Nau Turismo haga click aquÃ.
smtpd alias expansion updated, please test
Hi, I have just commited a rather deep change to the alias expansion logic in smtpd. It fixes a bug reported by halex@ in virtual maps, where an alias expanding to two different virtual users would end up being sent only to the first one. Alias expansion is tricky. We want to make sure that the change doesn't introduce a regression. So please test and report problems you notice to gil...@openbsd.org and e...@openbsd.org. Thank you. Eric.
Re: Intel azalia(4) and MSI
Date: Mon, 24 Sep 2012 03:49:41 -0400
From: Brad Smith b...@comstyle.com
I've always wondered why this workaround was not removed once MSI
support was added. This was added before we had MSI support to
workaround some Intel azalia(4) being setup by the BIOS as far
as I know to use MSI and thus interrupts on system that were
affected by this did not work at all for azalia(4).
Because there still are conditions under which we would not be able to
use MSI.
Perhaps we should change the generic PCI code to explicitly disable
MSIs if they are turned on. But until we do that, this workaround
needs to stay in place.
Index: azalia.c
===
RCS file: /home/cvs/src/sys/dev/pci/azalia.c,v
retrieving revision 1.200
diff -u -p -r1.200 azalia.c
--- azalia.c 10 May 2012 22:46:48 - 1.200
+++ azalia.c 2 Aug 2012 10:41:02 -
@@ -488,7 +488,6 @@ azalia_pci_attach(struct device *parent,
azalia_t *sc;
struct pci_attach_args *pa;
pcireg_t v;
- uint8_t reg;
pci_intr_handle_t ih;
const char *interrupt_str;
@@ -511,13 +510,6 @@ azalia_pci_attach(struct device *parent,
sc-subid = pci_conf_read(pa-pa_pc, pa-pa_tag, PCI_SUBSYS_ID_REG);
azalia_configure_pci(sc);
-
- /* disable MSI, use INTx instead */
- if (PCI_VENDOR(sc-pciid) == PCI_VENDOR_INTEL) {
- reg = azalia_pci_read(sc-pc, sc-tag, ICH_PCI_MMC);
- reg = ~(ICH_PCI_MMC_ME);
- azalia_pci_write(sc-pc, sc-tag, ICH_PCI_MMC, reg);
- }
/* interrupt */
if (pci_intr_map_msi(pa, ih) pci_intr_map(pa, ih)) {
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
For a man who's in search.
Hello cutie! )) I'm sure we will be good friends. I'm Angelina and no guess I like u I looked through ur photographs and I found you are really pretty. Can't wait to see +1 in my inbox (;
Re: ahd(4): Support Adaptec 39320LPE adapter
Date: Mon, 24 Sep 2012 04:09:16 -0400
From: Brad Smith b...@comstyle.com
Add support for the Adaptec 39320LPE adapter.
From FreeBSD
Don't see a downside, so ok kettenis@
Index: ahd_pci.c
===
RCS file: /home/cvs/src/sys/dev/pci/ahd_pci.c,v
retrieving revision 1.18
diff -u -p -r1.18 ahd_pci.c
--- ahd_pci.c 31 May 2009 04:47:59 - 1.18
+++ ahd_pci.c 24 Sep 2012 08:00:01 -
@@ -119,6 +119,7 @@ ahd_compose_id(u_int device, u_int vendo
#define ID_AHA_39320D_B 0x801C900500419005ull
#define ID_AHA_39320D_HP 0x8011900500AC0E11ull
#define ID_AHA_39320D_B_HP 0x801C900500AC0E11ull
+#define ID_AHA_39320LPE 0x8017900500459005ull
#define ID_AIC7902_PCI_REV_A40x3
#define ID_AIC7902_PCI_REV_B00x10
#define SUBID_HP 0x0E11
@@ -218,6 +219,11 @@ struct ahd_pci_identity ahd_pci_ident_ta
},
{
ID_AHA_39320D_B_HP,
+ ID_ALL_MASK,
+ ahd_aic7902_setup
+ },
+ {
+ ID_AHA_39320LPE,
ID_ALL_MASK,
ahd_aic7902_setup
},
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Re: acpiec madness (HP laptop people pay attention to this one) - tested on HP Compaq 6510b, 8510p, 8510w, 8710p, 8710w platforms
Date: Mon, 24 Sep 2012 22:06:24 +0400
From: Denis Lapshin deniza...@gmail.com
Two years ago Marco issued a patch
http://marc.info/?l=openbsd-techm=128612230314484w=4 in order to
prevent incorrect reading acpitz on HP Compaq (or any HP laptops with
acpiec madness) by adding some delays to have data prepared to
read/write.
It has been tested and works perfectly fine on some HP laptops: 6510b,
8510p/w, 8710p/w.
Please add this patch into the source tree to have it by default.
This is just papering over the problem. Marco didn't really
understand what he was doing. Seriously, making a local variable
volatile?
Index: acpiec.c
===
RCS file: /cvs/src/sys/dev/acpi/acpiec.c,v
retrieving revision 1.43
diff -u -p -r1.43 acpiec.c
--- acpiec.c 8 Aug 2010 17:25:41 - 1.43
+++ acpiec.c 29 Sep 2010 04:24:13 -
@@ -92,7 +92,7 @@ void
acpiec_wait(struct acpiec_softc *sc, u_int8_t mask, u_int8_t val)
{
static int acpiecnowait;
- u_int8_tstat;
+ volatile u_int8_t stat;
dnprintf(40, %s: EC wait_ns for: %b == %02x\n,
DEVNAME(sc), (int)mask,
@@ -104,8 +104,14 @@ acpiec_wait(struct acpiec_softc *sc, u_i
if (cold || (stat EC_STAT_BURST))
delay(1);
else
- tsleep(acpiecnowait, PWAIT, acpiec, 1);
+ tsleep(acpiecnowait, PWAIT, ecstat, 1);
}
+
+ /* delay to make sure the data is actually ready */
+ if (cold)
+ delay(10);
+ else
+ tsleep(acpiecnowait, PWAIT, ecout, 1);
dnprintf(40, %s: EC wait_ns, stat: %b\n, DEVNAME(sc), (int)stat,
\20\x8IGN\x7SMI\x6SCI\05BURST\04CMD\03IGN\02IBF\01OBF);
Re: Intel azalia(4) and MSI
On Fri, Sep 28, 2012 at 04:06:32AM +0200, Mark Kettenis wrote:
Date: Mon, 24 Sep 2012 03:49:41 -0400
From: Brad Smith b...@comstyle.com
I've always wondered why this workaround was not removed once MSI
support was added. This was added before we had MSI support to
workaround some Intel azalia(4) being setup by the BIOS as far
as I know to use MSI and thus interrupts on system that were
affected by this did not work at all for azalia(4).
Because there still are conditions under which we would not be able to
use MSI.
I had 6 people reply off list indicating their Intel azalia controllers
didn't seem to have any regressions with the previous diff applied.
Can you expand upon this and explain what you mean. What are these
conditions? It would be nice to mention what those conditions are
within the comment.
Perhaps we should change the generic PCI code to explicitly disable
MSIs if they are turned on. But until we do that, this workaround
needs to stay in place.
Since MSI is being disabled for the Intel azalia controller and the
datasheet does confirm that is what this code is doing shouldn't
we be telling the PCI layer MSI is disabled too like so? It doesn't
make sense to have MSI disabled for the controller and then the
PCI layer still thinking MSI should be used.
Index: azalia.c
===
RCS file: /home/cvs/src/sys/dev/pci/azalia.c,v
retrieving revision 1.201
diff -u -p -r1.201 azalia.c
--- azalia.c12 Aug 2012 19:32:22 - 1.201
+++ azalia.c28 Sep 2012 02:17:31 -
@@ -515,6 +515,7 @@ azalia_pci_attach(struct device *parent,
/* disable MSI, use INTx instead */
if (PCI_VENDOR(sc-pciid) == PCI_VENDOR_INTEL) {
+ pa-pa_flags = ~PCI_FLAGS_MSI_ENABLED;
reg = azalia_pci_read(sc-pc, sc-tag, ICH_PCI_MMC);
reg = ~(ICH_PCI_MMC_ME);
azalia_pci_write(sc-pc, sc-tag, ICH_PCI_MMC, reg);
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Re: gem(4): simplify gem_attach_pci() variant detection code a bit
Date: Wed, 26 Sep 2012 15:32:37 -0400 From: Brad Smith b...@comstyle.com Simplify the gem(4) variant detection code a bit. I don't see the benefit and prefer to keep the code as it is now. Index: if_gem_pci.c === RCS file: /home/cvs/src/sys/dev/pci/if_gem_pci.c,v retrieving revision 1.31 diff -u -p -r1.31 if_gem_pci.c --- if_gem_pci.c 15 Oct 2009 17:54:56 - 1.31 +++ if_gem_pci.c 6 Mar 2011 06:50:12 - @@ -231,18 +231,10 @@ gem_attach_pci(struct device *parent, st sc-sc_variant = GEM_SUN_GEM; else if (PCI_PRODUCT(pa-pa_id) == PCI_PRODUCT_SUN_ERINETWORK) sc-sc_variant = GEM_SUN_ERI; - else if (PCI_PRODUCT(pa-pa_id) == PCI_PRODUCT_APPLE_INTREPID2_GMAC) - sc-sc_variant = GEM_APPLE_GMAC; - else if (PCI_PRODUCT(pa-pa_id) == PCI_PRODUCT_APPLE_PANGEA_GMAC) - sc-sc_variant = GEM_APPLE_GMAC; - else if (PCI_PRODUCT(pa-pa_id) == PCI_PRODUCT_APPLE_SHASTA_GMAC) - sc-sc_variant = GEM_APPLE_GMAC; - else if (PCI_PRODUCT(pa-pa_id) == PCI_PRODUCT_APPLE_UNINORTHGMAC) - sc-sc_variant = GEM_APPLE_GMAC; - else if (PCI_PRODUCT(pa-pa_id) == PCI_PRODUCT_APPLE_UNINORTH2GMAC) - sc-sc_variant = GEM_APPLE_GMAC; else if (PCI_PRODUCT(pa-pa_id) == PCI_PRODUCT_APPLE_K2_GMAC) sc-sc_variant = GEM_APPLE_K2_GMAC; + else + sc-sc_variant = GEM_APPLE_GMAC; #define PCI_GEM_BASEADDR 0x10 if (pci_mapreg_map(pa, PCI_GEM_BASEADDR, type, 0, -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
Re: hardware VLAN tagging for vr(4)
Date: Thu, 27 Sep 2012 09:54:35 +1000
From: Darren Tucker dtuc...@zip.com.au
Hi all.
This diff adds hardware 802.1q VLAN tagging support to vr(4) (just
tag/untag, it doesn't do anything with the VLAN CAM filters).
As far as I know, the capability is only in the VT6105M Rhine III chip
which is used, amongst other places, in the pcengines ALIX machines.
If anyone has a vr(4) (any revision), especially if you use VLANs,
I'd be interested to hear if this works for you.
I'm not a kernel guy, so it's quite possible I made some basic mistake
in there somewhere, but it works for me on an ALIX:
vr0 at pci0 dev 9 function 0 VIA VT6105M RhineIII rev 0x96: irq 10, address
00:0d:b9:7e:21:5c
ukphy0 at vr0 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI
0x004063, model 0x0034
$ ifconfig vr0 hwfeatures | grep hwfeatures
hwfeatures=8037CSUM_IPv4,CSUM_TCPv4,CSUM_UDPv4,VLAN_MTU,VLAN_HWTAGGING,WOL
As an aside, I found what I believe is a latent bug in the existing
driver. When it's done with the TX descriptor, it sets the owner
bit to tell the chip that it's good to go:
#define VR_TXSTAT_OWN 0x8000
#define VR_TXOWN(x) x-vr_ptr-vr_status
VR_TXOWN(cur_tx) = htole32(VR_TXSTAT_OWN);
which expands to:
cur_tx-vr_ptr-vr_status = htole32(0x8000);
which zeroes the 31 least significant bits in the first word of the
TX descriptor. Sadly, this includes the VLAN ID, which caused me some
head-scratching trying to figure out why my tagged frames were all in
VLAN 0.
On the plus side, nothing else currently uses those bits, so right
now it doesn't matter. My questions is: why hide that behind a macro?
or at least, if you're going to, why not go the whole hog and put the
entire thing in there?
#define VR_TXOWN(x) ((x)-vr_ptr-vr_status |= htole32(VR_TXSTAT_OWN))
Yes. I consider using macros in the LHS of an assignment bad style.
But I'd just drop the macro entirely. I think having the code show
explicitly that vr_status is getting changed is better, and would
probably have prevented the latent bug you mention above.
Diff looks good to me, but I don't have the hardware to test this.
ok kettenis@
Index: sys/dev/pci/if_vr.c
===
RCS file: /cvs/src/sys/dev/pci/if_vr.c,v
retrieving revision 1.114
diff -u -p -r1.114 if_vr.c
--- sys/dev/pci/if_vr.c 30 Jan 2012 09:11:30 - 1.114
+++ sys/dev/pci/if_vr.c 26 Sep 2012 23:13:45 -
@@ -62,6 +62,7 @@
*/
#include bpfilter.h
+#include vlan.h
#include sys/param.h
#include sys/systm.h
@@ -83,6 +84,11 @@
#include net/if_dl.h
#include net/if_media.h
+#if NVLAN 0
+#include net/if_types.h
+#include net/if_vlan_var.h
+#endif
+
#if NBPFILTER 0
#include net/bpf.h
#endif
@@ -633,6 +639,12 @@ vr_attach(struct device *parent, struct
if (sc-vr_quirks VR_Q_CSUM)
ifp-if_capabilities |= IFCAP_CSUM_IPv4|IFCAP_CSUM_TCPv4|
IFCAP_CSUM_UDPv4;
+
+#if NVLAN 0
+ /* if the hardware can do VLAN tagging, say so. */
+ if (sc-vr_quirks VR_Q_HWTAG)
+ ifp-if_capabilities |= IFCAP_VLAN_HWTAGGING;
+#endif
#ifndef SMALL_KERNEL
if (sc-vr_revid = REV_ID_VT3065_A) {
ifp-if_capabilities |= IFCAP_WOL;
@@ -880,6 +892,23 @@ vr_rxeof(struct vr_softc *sc)
cur_rx-vr_map-dm_mapsize, BUS_DMASYNC_POSTREAD);
bus_dmamap_unload(sc-sc_dmat, cur_rx-vr_map);
+#if NVLAN 0
+ /*
+ * If there's a tagged packet, the 802.1q header will be at the
+ * 4-byte boundary following the CRC. There will be 2 bytes
+ * TPID (0x8100) and 2 bytes TCI (including VLAN ID).
+ * This isn't in the data sheet.
+ */
+ if (rxctl VR_RXCTL_TAG) {
+ u_int16_t vtag;
+ int offset = ((total_len + 3) ~3) + 2;
+
+ bcopy(m-m_data + offset, vtag, sizeof(vtag));
+ m-m_pkthdr.ether_vtag = ntohs(vtag);
+ m-m_flags |= M_VLANTAG;
+ }
+#endif
+
/*
* The VIA Rhine chip includes the CRC with every
* received frame, and there's no way to turn this
@@ -1002,7 +1031,7 @@ vr_txeof(struct vr_softc *sc)
sc-vr_flags |= VR_F_RESTART;
break;
}
- VR_TXOWN(cur_tx) = htole32(VR_TXSTAT_OWN);
+ VR_TXOWN(cur_tx) |= htole32(VR_TXSTAT_OWN);
CSR_WRITE_4(sc, VR_TXADDR, cur_tx-vr_paddr);
break;
}
@@ -1170,6 +1199,16 @@ vr_encap(struct vr_softc *sc, struct vr_
struct mbuf *m_new = NULL;
u_int32_t vr_flags = 0, vr_status = 0;
+#if NVLAN 0
Re: gem(4): simplify gem_attach_pci() variant detection code a bit
On Wed, Sep 26, 2012 at 15:32, Brad Smith wrote: Simplify the gem(4) variant detection code a bit. OK? Wouldn't a switch be a nicer simplification? Index: if_gem_pci.c === RCS file: /home/cvs/src/sys/dev/pci/if_gem_pci.c,v retrieving revision 1.31 diff -u -p -r1.31 if_gem_pci.c --- if_gem_pci.c 15 Oct 2009 17:54:56 - 1.31 +++ if_gem_pci.c 6 Mar 2011 06:50:12 - @@ -231,18 +231,10 @@ gem_attach_pci(struct device *parent, st sc-sc_variant = GEM_SUN_GEM; else if (PCI_PRODUCT(pa-pa_id) == PCI_PRODUCT_SUN_ERINETWORK) sc-sc_variant = GEM_SUN_ERI; - else if (PCI_PRODUCT(pa-pa_id) == PCI_PRODUCT_APPLE_INTREPID2_GMAC) - sc-sc_variant = GEM_APPLE_GMAC; - else if (PCI_PRODUCT(pa-pa_id) == PCI_PRODUCT_APPLE_PANGEA_GMAC) - sc-sc_variant = GEM_APPLE_GMAC; - else if (PCI_PRODUCT(pa-pa_id) == PCI_PRODUCT_APPLE_SHASTA_GMAC) - sc-sc_variant = GEM_APPLE_GMAC; - else if (PCI_PRODUCT(pa-pa_id) == PCI_PRODUCT_APPLE_UNINORTHGMAC) - sc-sc_variant = GEM_APPLE_GMAC; - else if (PCI_PRODUCT(pa-pa_id) == PCI_PRODUCT_APPLE_UNINORTH2GMAC) - sc-sc_variant = GEM_APPLE_GMAC; else if (PCI_PRODUCT(pa-pa_id) == PCI_PRODUCT_APPLE_K2_GMAC) sc-sc_variant = GEM_APPLE_K2_GMAC; + else + sc-sc_variant = GEM_APPLE_GMAC; #define PCI_GEM_BASEADDR 0x10 if (pci_mapreg_map(pa, PCI_GEM_BASEADDR, type, 0,
