headers
David Krause | 1 Aug 2007 05:52

please test, netstart diff

This diff fixes the problem of daemons that fail to start at boot time
due to being unable to bind to all interfaces.  If you have to start
isakmpd with -4 to have it run at bootup this should fix it.  The
problem is that certain interfaces, vlan and gif, have tentative IPv6
addresses also, but are started after the delay for IPv6 DAD.  So this
diff moves the DAD delay to the end of the file to make sure all
interfaces are ready before continuing.

Please test this with whatever weird setups you have, especially with
lots of interfaces and in IPv6 setups.

David

Index: etc/netstart
===================================================================
RCS file: /cvs/src/etc/netstart,v
retrieving revision 1.115
diff -u -p -r1.115 netstart
--- etc/netstart	15 Nov 2006 06:28:33 -0000	1.115
+++ etc/netstart	1 Jul 2007 16:28:05 -0000
 <at>  <at>  -301,10 +301,6  <at>  <at>  if [ "$ip6kernel" = "YES" -a "x$rtsolif"
 		echo "WARNING: inconsistent config - check /etc/sysctl.conf for IPv6 autoconf"
 	fi
 fi
-if [ "$ip6kernel" = "YES" ]; then
-	# this is to make sure DAD is completed before going further.
-	sleep `sysctl -n net.inet6.ip6.dad_count`
-fi

 # The trunk interfaces need to come up first in this list.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Reyk Floeter | 1 Aug 2007 10:57
Picon
Favicon

Re: i965GM agp and xorg diff

On Mon, Jul 30, 2007 at 08:50:22PM +0200, Mark Kettenis wrote:
> If I leave X and start it again, things appear to be normal again,
> although I get a new warning in /var/log/Xorg.0.log
> 
> (WW) xf86AcquireGART: AGPIOC_ACQUIRE failed (Device busy)
> 

ok, i've seen this. something is wrong here and i will try to make an
updated diff. by some reason it is not releasing some agp memory.

> Here is a diff between the logfile created during the first time I
> started X and the second.  I also attached the logfile for the X
> session that showed the problem.
> 
> I'm fairly sure I didn't see any problems with only the kernel diff
> applied.  Let me know if you need more information.
> 
> Mark
> 

to understand it right - you don't have any problems when running the
patched kernel but when you run the patched i810 xenocara driver?
what happens when you run an unpatched kernel with the patched
xenocara driver? does the AGPIOC_ACQUIRE error msg appear?

> 
> --- /var/log/Xorg.0.log.old	Mon Jul 30 20:26:22 2007
> +++ /var/log/Xorg.0.log	Mon Jul 30 20:32:14 2007
>  <at>  <at>  -1,5 +1,6  <at>  <at> 
>  (--) checkDevMem: using aperture driver /dev/xf86
(Continue reading)

Permalink | Reply | 1 comment |
headers
Mark Kettenis | 1 Aug 2007 11:30
Picon
Picon
Favicon

Re: i965GM agp and xorg diff

> Date: Wed, 1 Aug 2007 10:57:55 +0200
> From: Reyk Floeter <reyk <at> openbsd.org>
> 
> On Mon, Jul 30, 2007 at 08:50:22PM +0200, Mark Kettenis wrote:
> > If I leave X and start it again, things appear to be normal again,
> > although I get a new warning in /var/log/Xorg.0.log
> > 
> > (WW) xf86AcquireGART: AGPIOC_ACQUIRE failed (Device busy)
> > 
> 
> ok, i've seen this. something is wrong here and i will try to make an
> updated diff. by some reason it is not releasing some agp memory.

As discussed on icb, the old code suffers from the same problem.  So
there is a problem here, but it is not with Reyk's diff.
Permalink | Reply | 0 comments |
headers
Lutz Hamann | 1 Aug 2007 15:19

Re: patch if_trunk.h for ath and em

On Wed, Aug 01, 2007 at 02:46:36AM +1000, Joel Sing wrote:
> I think we're probably dealing with three classes of interfaces/drivers:
> 
> 1. Those that cannot report link state (mainly old hardware?)
> 2. Those that report link state
> 3. Wireless interfaces
> 
> For (2) there are no issues. For (3) I think it is a case of either having 
> them report as UP either once associated, or once the radio is active and the 
> device is configured to be able to associate (as per my previous email). For 
> (1) there is no easy solution other than to change trunk to once again use != 
> LINK_STATE_DOWN, or trunk is simply not supported with these devices (makes 
> more sense to me, at least for failover mode).

For (3) the following seems to do the trick. I've tested with the only
two wireless adapters that I have here. Inbuild ath(4) and cardbus rtw(4).
They both report as UP once associated and running, DOWN when not on the
ap any longer. The flapping is also not too bad, since they both don't
immediatly fall down to scan mode when the signal is lost for a few
seconds. (rtw acutally takes quite a long time to realize the link
is lost, ath is faster)

ieee80211_proto.c already has a nice list of all state changes possible.
I used UP and DOWN as in this table:

	TO
	INIT	SCAN	AUTH	ASSOC	RUN
FROM
INIT	-	-	I	I	I
(Continue reading)

Permalink | Reply | 0 comments |
headers
Hugo van Niekerk | 2 Aug 2007 04:18
Picon

Problem with VLANs

Hey Everybody

Im running OpenBSD 3.9. At startup during vlan initialization I get  
an error that the vlan initiated with a nonstandard mtu of 1946  
(parent pcn1). Of course I understand that a vlan header has to be  
sent and that provision has to be made for this. Ive done a lot of  
searching on the web around this and everything is pointing to the  
fact that the network driver does not support / has not been set for  
a larger mtu. This is where I get stuck. There is a component  
SIOCIFMTU that reports that the mtu value I use is incorrect for a  
specific interface when I try to increase the mtu from the command  
line using ifconfig. This component, according to my research sets  
the mtu value automatically at startup based on the information that  
is fed to it by the network card driver. Anything above what is set  
at startup would be invalid. Can anybody please give me some advise  
as to where I can more resources that I can research to resolve this  
problem or point me in the right direction. I would really  
appreciated this! Also, I've been looking for a guide or good book /  
resource around configuring vlans on OpenBSD, I thought maybe I made  
a mistake in the hostname.if and pf.conf files. Again any assistance  
here will be greatly appreciated.

regards

Hugo

--

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Hugo van Niekerk | 2 Aug 2007 04:31
Picon

Problem with VLANs

Sorry, my bad. The mtu is 1496, not 1946. Finger problems.

--

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Permalink | Reply | 1 comment |
headers
Henrik Johansen | 2 Aug 2007 10:14
Picon

Problem with STP enabled brigdes.

I am currently playing around with bridge failover using OpenBSD 4.1 and I
have discovered a problem - the STP ID portion of every bridge always seems
to be equal to the MAC adress of the first phsycial network interface
present on machineX.

That works fine as long as you are trying to failover a complete machine but
I am trying to individually failover bridges between machine1 and machine2
and that seems not to be possible since every bridge on machineX shares the
same STP bridge ID.

##########
MACHINE1:
##########
# uname -a
OpenBSD machine1.xxxxxx.xxx 4.1 GENERIC.MP#1225 i386

# ifconfig em0 | grep lladdr
         lladdr 00:15:17:15:8e:52

# brconfig bridge0
bridge0: flags=41<UP,RUNNING>
         priority 24576 hellotime 2 fwddelay 15 maxage 20 holdcnt 6 proto rstp
         designated: id 00:15:17:15:8e:52 priority 24576
         em3 flags=eb<LEARNING,DISCOVER,STP,AUTOEDGE,PTP,AUTOPTP>
                 port 4 ifpriority 128 ifcost 20000 forwarding role designated
         em2 flags=eb<LEARNING,DISCOVER,STP,AUTOEDGE,PTP,AUTOPTP>
                 port 3 ifpriority 128 ifcost 20000 forwarding role designated
         Addresses (max cache: 100, timeout: 240):
                 00:19:b9:aa:83:68 em2 1 flags=0<>
                 00:19:b9:aa:99:72 em3 1 flags=0<>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Igor Moiseev | 2 Aug 2007 11:35
Picon
Favicon

mpi driver

Hello,
We have in production some servers (DELL PowerEdge 840 with LSI scsi card)
with installed Openbsd 4.1.

The problem is that disk system speed is very low when the RAID-1 is
configured.
I mean that it works stably but slow. I expected at least the speed of one
disk or a bit slower.

The main question: Does anybody khow how it is possible to fix this
problem?

I found one old post related this topic (It seems the prob. still exist).
http://archive.openbsd.nu/?ml=openbsd-tech&a=2004-04&t=189139

Here below the output of speed test and dmesg. The difference in
"Sequential Output" with the standard (non RAID) openbsd machine is about
10 times!

Best regards.
Igor Moiseev.

Bonnie-----------------------------------------------------------------------
--
File './Bonnie.1678', size: 104857600
Writing with putc()...done
Rewriting...done
Writing intelligently...done
Reading with getc()...done
Reading intelligently...done
(Continue reading)

Permalink | Reply | 1 comment |
headers
Johan M:son Lindman | 2 Aug 2007 12:02
Picon

diff - add nvram(4) to amd64

This diff adds nvram(4) to amd64.
This way I can use ports like sysutils/tpb on amd64 .
This works nicely on my Thinkpad X60 w/ em64t Core Duo 7200
running amd64.

Regards
Johan M:son Lindman

Index: etc/etc.amd64/MAKEDEV.md
===================================================================
RCS file: /cvs/src/etc/etc.amd64/MAKEDEV.md,v
retrieving revision 1.18
diff -u -p -r1.18 MAKEDEV.md
--- etc/etc.amd64/MAKEDEV.md	25 Jul 2007 18:48:35 -0000	1.18
+++ etc/etc.amd64/MAKEDEV.md	1 Aug 2007 16:35:35 -0000
 <at>  <at>  -18,6 +18,8  <at>  <at>  dnl OR IN CONNECTION WITH THE USE OR PER
 dnl
 dnl
 __devitem(acpi, acpi, Advanced Configuration and Power Interface)dnl
+__devitem(nvram, nvram, NVRAM access)dnl
+_mkdev(nvram, nvram, {-M nvram c major_nvram_c 0 440 kmem-})dnl
 _TITLE(make)
 _DEV(all)
 _DEV(ramdisk)
 <at>  <at>  -78,6 +80,7  <at>  <at>  _DEV(iop, 75)
 _DEV(joy, 26)
 _DEV(lkm, 28)
 _DEV(music, 53)
+_DEV(nvram, 85)
 _DEV(pci, 72)
(Continue reading)

Permalink | Reply | 1 comment |
headers
Johan M:son Lindman | 2 Aug 2007 14:39
Picon

Re: diff - add nvram(4) to amd64

On Thursday 02 August 2007 12:02:45 you wrote:
> This diff adds nvram(4) to amd64.
> This way I can use ports like sysutils/tpb on amd64 .
> This works nicely on my Thinkpad X60 w/ em64t Core Duo 7200
> running amd64.
>
>
> Regards
> Johan M:son Lindman

It looks like my MUA b0tched the last diff, please try this diff instead, 
sorry for the inconvenience.

http://coh02.btradianz.se/~jl/nvram_amd64.diff

Regards
Johan M:son Lindman
Permalink | Reply | 0 comments |

Gmane