Re: little-but-scary ahc(4) diff, testers wanted
Date: Thu, 9 Feb 2012 17:14:41 +
From: Miod Vallat m...@online.fr
Could people with ahc(4) SCSI controllers give the following diff a try
and report whether this causes any difference in behaviour? This diff
seems to do wonders on alpha, but I'd like reports from other platforms
(such as i386, amd64 and macppc) before considering putting it in.
I'm not sure this is a good idea. Writes on the PCI bus may be
posted. The ahc_inb() call makes sure that any preceding (posted)
writes have indeed completed. By replacing this with a
bus_space_barrier() you no longer guarantee completion of the writes,
but instead guarantee that the CPU (or the compiler) doesn't reorder
the writes. So it's not the same thing.
I don't know what the ahc(4) driver/hardware requires here. Could be
that posted writes are not an issue at all. But if they are, we
probably need to keep that ahc_inb() call around. So it would be
safer to just add the bus_space_barrier() call before the ahc_inb()
call.
Now it can be argued that bus_space_barrier() should guarantee
completion of posted writes. Unfortunately that's difficult to
achieve since doing a read on the PCI bus is the only way to achieve
this, and doing a read typically has side-effects.
I've never fully understood the issues with posted writes. I think
issues will only show up for devices that are sitting behind a PCI-PCI
bridge. All I know the Linux people tend to make a big fuss about
them and add seemingly redundant reads all over the place to deal with
them.
Index: aic7xxx_openbsd.h
===
RCS file: /cvs/src/sys/dev/ic/aic7xxx_openbsd.h,v
retrieving revision 1.21
diff -u -p -r1.21 aic7xxx_openbsd.h
--- aic7xxx_openbsd.h 17 Jul 2011 22:46:48 - 1.21
+++ aic7xxx_openbsd.h 8 Feb 2012 21:48:48 -
@@ -193,8 +193,8 @@ static __inline void ahc_flush_device_wr
static __inline void
ahc_flush_device_writes(struct ahc_softc *ahc)
{
- /* XXX Is this sufficient for all architectures??? */
- ahc_inb(ahc, INTSTAT);
+ bus_space_barrier(ahc-tag, ahc-bsh, 0, 0x100,
+ BUS_SPACE_BARRIER_READ | BUS_SPACE_BARRIER_WRITE);
}
/ Locking Primitives
**/
Re: rc.d unbound daemon start order
Date: Fri, 10 Feb 2012 09:21:04 -0800 From: Chris Cappuccio ch...@nmedia.net Stuart Henderson [s...@spacehopper.org] wrote: iirc there were some objections to it. I don't see any other way to accommodate ports that require early start in the rc.d system other than to PUT THEM FIRST. Otherwise, rc.d scripts for certain items need to be manually inserted into /etc/rc. How stupid is that ? Perhaps not as stupid as you think. OpenBSD provides a complete base OS. In principle you only need to install packages for add-on software. And there should be no need for such add-on software to be started before the base system is up and running. You only run into problems when you try to replace things from the base system with stuff from ports. I'd argue that in that case you're no longer running OpenBSD, and therefore it is a good thing you need to go through some hoops in order to do this. In the particular case of unbound, there is some consensus that we should replace BIND in base with nsd and unbound. But it seems nobody actually cares enough to do the work to make this happen.
Re: little-but-scary ahc(4) diff, testers wanted
Date: Sun, 12 Feb 2012 10:25:10 +0100 (CET) From: Mark Kettenis mark.kette...@xs4all.nl Date: Thu, 9 Feb 2012 17:14:41 + From: Miod Vallat m...@online.fr Could people with ahc(4) SCSI controllers give the following diff a try and report whether this causes any difference in behaviour? This diff seems to do wonders on alpha, but I'd like reports from other platforms (such as i386, amd64 and macppc) before considering putting it in. I'm not sure this is a good idea. Writes on the PCI bus may be posted. The ahc_inb() call makes sure that any preceding (posted) writes have indeed completed. By replacing this with a bus_space_barrier() you no longer guarantee completion of the writes, but instead guarantee that the CPU (or the compiler) doesn't reorder the writes. So it's not the same thing. I don't know what the ahc(4) driver/hardware requires here. Could be that posted writes are not an issue at all. But if they are, we probably need to keep that ahc_inb() call around. So it would be safer to just add the bus_space_barrier() call before the ahc_inb() call. Ok, aic7xxx_inline.h has the following comment: /* * Ensure that the chip sees that we've cleared * this interrupt before we walk the output fifo. * Otherwise, we may, due to posted bus writes, * clear the interrupt after we finish the scan, * and after the sequencer has added new entries * and asserted the interrupt again. */ ahc_flush_device_writes(ahc); ahc_run_qoutfifo(ahc); so ahc_flush_devoice_writes() is supposed to properly guard against uncompleted posted bus writes. In other words, I think we need to put that ahc_inb(ahc, INTSTAT) call back (after the bus_space_barrier() that miod@ introduced).
Dilo con amor... Dilo con Ferrini. publicidad lo baf
[demime 1.01d removed an attachment of type image/jpeg which had a name of fcaramela.jpg] [demime 1.01d removed an attachment of type image/jpeg which had a name of facuciadora.jpg] [demime 1.01d removed an attachment of type image/jpeg which had a name of tlinternazo.jpg]
select(2) nit
The sample code given in the BUGS section of select(2) contains an
unnecessary cast.
Joachim
Index: select.2
===
RCS file: /usr/cvs/src/src/lib/libc/sys/select.2,v
retrieving revision 1.28
diff -u -p -r1.28 select.2
--- select.231 May 2007 19:19:33 - 1.28
+++ select.212 Feb 2012 18:59:13 -
@@ -204,8 +204,7 @@ userland libraries:
fd_set *fdsr;
int max = fd;
-fdsr = (fd_set *)calloc(howmany(max+1, NFDBITS),
-sizeof(fd_mask));
+fdsr = calloc(howmany(max+1, NFDBITS), sizeof(fd_mask));
if (fdsr == NULL) {
...
return (-1);
Xsearch(3) nit
bsearch(3), tsearch(3) contains some superfluous spaces. Joachim Index: bsearch.3 === RCS file: /usr/cvs/src/src/lib/libc/stdlib/bsearch.3,v retrieving revision 1.7 diff -u -p -r1.7 bsearch.3 --- bsearch.3 31 May 2007 19:19:31 - 1.7 +++ bsearch.3 21 Apr 2011 16:03:10 - @@ -40,7 +40,7 @@ .Sh SYNOPSIS .Fd #include stdlib.h .Ft void * -.Fn bsearch const void *key const void *base size_t nmemb size_t size int (*compar) (const void *, const void *) +.Fn bsearch const void *key const void *base size_t nmemb size_t size int (*compar)(const void *, const void *) .Sh DESCRIPTION The .Fn bsearch Index: tsearch.3 === RCS file: /usr/cvs/src/src/lib/libc/stdlib/tsearch.3,v retrieving revision 1.16 diff -u -p -r1.16 tsearch.3 --- tsearch.3 31 May 2007 19:19:32 - 1.16 +++ tsearch.3 21 Apr 2011 16:03:10 - @@ -26,13 +26,13 @@ .Sh SYNOPSIS .Fd #include search.h .Ft void * -.Fn tdelete const void *key void **rootp int (*compar) (const void *, const void *) +.Fn tdelete const void *key void **rootp int (*compar)(const void *, const void *) .Ft void * -.Fn tfind const void *key void * const *rootp int (*compar) (const void *, const void *) +.Fn tfind const void *key void * const *rootp int (*compar)(const void *, const void *) .Ft void * -.Fn tsearch const void *key void **rootp int (*compar) (const void *, const void *) +.Fn tsearch const void *key void **rootp int (*compar)(const void *, const void *) .Ft void -.Fn twalk const void *root void (*action) (const void *, VISIT, int) +.Fn twalk const void *root void (*action)(const void *, VISIT, int) .Sh DESCRIPTION The .Fn tdelete ,
Re: iwn0 firmware errors
Edd Barrett(vex...@gmail.com) on 2012.02.11 11:57:34 +: Hi, I have just upgraded from a thinkpad x60s to an x61s. The machine came with an iwn wireless card (no suprise really). After installing the firmware with fw_update, you can start using the card but very shortly start to see firmware errors. Once I managed to get an address via DHCP, but that is about as much as I can achieve. Probably not a huge amount we can do if the firmware is buggy, but worth mentioning anyway. In the meantime I am using a usb urtwn. [...] error type = NMI_INTERRUPT_WDG (0x0004) program counter = 0x046C source line = 0x00D0 error data = 0x00020203 branch link = 0x2F3E04C2 interrupt link = 0x06DE2FCE time= 3303793537 driver status: tx ring 0: qid=0 cur=10 queued=0 tx ring 1: qid=1 cur=0 queued=0 tx ring 2: qid=2 cur=0 queued=0 tx ring 3: qid=3 cur=0 queued=0 tx ring 4: qid=4 cur=45 queued=0 tx ring 5: qid=5 cur=0 queued=0 tx ring 6: qid=6 cur=0 queued=0 tx ring 7: qid=7 cur=0 queued=0 tx ring 8: qid=8 cur=0 queued=0 tx ring 9: qid=9 cur=0 queued=0 tx ring 10: qid=10 cur=0 queued=0 tx ring 11: qid=11 cur=0 queued=0 tx ring 12: qid=12 cur=0 queued=0 tx ring 13: qid=13 cur=0 queued=0 tx ring 14: qid=14 cur=0 queued=0 tx ring 15: qid=15 cur=0 queued=0 rx ring: cur=11 802.11 state 4 Hi, i was using a x61s until a month ago. I had these errors too, but only with certain wifi networks (specifically 2 events with 30+ access points and 1000+ wifi users) using cisco ap's. I never saw these errors somewhere else. i can find out which cisco access points were used if someone is interested. /Benno
Re: iwn0 firmware errors
On Sun, Feb 12, 2012 at 09:24:17PM +0100, Sebastian Benoit wrote: i was using a x61s until a month ago. I had these errors too, but only with certain wifi networks (specifically 2 events with 30+ access points and 1000+ wifi users) using cisco ap's. I never saw these errors somewhere else. Hmm. I am seeing the error connecting to a soekris I set up myself. I am the only client on this. It has a ral card in hostap mode. It may be related to power saving? Pure speculation ofcourse -- I know nothing about how these devices work internally. -- Best Regards Edd Barrett http://www.theunixzoo.co.uk
Re: iwn0 firmware errors
On Sun, Feb 12, 2012 at 08:58:31PM +, Edd Barrett wrote: On Sun, Feb 12, 2012 at 09:24:17PM +0100, Sebastian Benoit wrote: i was using a x61s until a month ago. I had these errors too, but only with certain wifi networks (specifically 2 events with 30+ access points and 1000+ wifi users) using cisco ap's. I never saw these errors somewhere else. Hmm. I am seeing the error connecting to a soekris I set up myself. I am the only client on this. It has a ral card in hostap mode. It may be related to power saving? Pure speculation ofcourse -- I know nothing about how these devices work internally. I also have issues with iwn on my SL510, although only when stressing the network (and not reliably). Sample: iwn0 at pci4 dev 0 function 0 Intel WiFi Link 1000 rev 0x00: msi, MIMO 1T2R, BGS, address 00:1e:64:6b:9a:7c iwn0: fatal firmware error firmware error log: error type = NMI_INTERRUPT_WDG (0x0004) program counter = 0x06D0 source line = 0x012E error data = 0x00020363 branch link = 0x059606D4 interrupt link = 0x0892839C time= 2431600062 driver status: tx ring 0: qid=0 cur=0 queued=1 tx ring 1: qid=1 cur=0 queued=0 tx ring 2: qid=2 cur=0 queued=0 tx ring 3: qid=3 cur=0 queued=0 tx ring 4: qid=4 cur=78 queued=0 tx ring 5: qid=5 cur=0 queued=0 tx ring 6: qid=6 cur=0 queued=0 tx ring 7: qid=7 cur=0 queued=0 tx ring 8: qid=8 cur=0 queued=0 tx ring 9: qid=9 cur=0 queued=0 tx ring 10: qid=10 cur=0 queued=0 tx ring 11: qid=11 cur=0 queued=0 tx ring 12: qid=12 cur=0 queued=0 tx ring 13: qid=13 cur=0 queued=0 tx ring 14: qid=14 cur=0 queued=0 tx ring 15: qid=15 cur=0 queued=0 tx ring 16: qid=16 cur=0 queued=0 tx ring 17: qid=17 cur=0 queued=0 tx ring 18: qid=18 cur=0 queued=0 tx ring 19: qid=19 cur=0 queued=0 rx ring: cur=35 802.11 state 4 This occurs with a multitude of APs, so I'm not sure if it's the same issue. I have the latest firmware, iwn-firmware-5.6p0. Joachim
Re: rc.d unbound daemon start order
Mark Kettenis [mark.kette...@xs4all.nl] wrote: Perhaps not as stupid as you think. OpenBSD provides a complete base OS. In principle you only need to install packages for add-on software. And there should be no need for such add-on software to be started before the base system is up and running. You only run into problems when you try to replace things from the base system with stuff from ports. I'd argue that in that case you're no longer running OpenBSD, and therefore it is a good thing you need to go through some hoops in order to do this. In the particular case of unbound, there is some consensus that we should replace BIND in base with nsd and unbound. But it seems nobody actually cares enough to do the work to make this happen. If rc.d provides functionality, it should be usable in cases where you expect it to, or it should at least be documented why it is broken. If an alternative server for syslogd, ldattach, pflogd, named, nsd, ntpd, isakmpd, iked, sasyncd, or ldapd isn't suitable then why is it even in ports ? Some people have specific needs that most people don't? Some of these tools are generally known to be lower quality, yet stay in ports for the same reason. They're useful, but not encouraged. We don't want to make rc.d good enough to help these people because it's another knob. So, the perception here is that rc.d is aimed at the set it and forget it folks who aren't qualified to use ports? Do you use rc.d? I use rc.d. And, probably like you, I used it because it was convenient. And, I am satisfied with it. So while I understand the arguments against fully implementing rc.d, I can't agree that I don't want the pkg_early_scripts convenience there for myself.
Re: rc.d unbound daemon start order
If an alternative server for syslogd, ldattach, pflogd, named, nsd, ntpd, isakmpd, iked, sasyncd, or ldapd isn't suitable then why is it even in ports ? Don't be a jerk. syslogd is obviously different -- it is the daemon which is started very early.
