headers
Mike Belopuhov | 1 Nov 2005 14:38
Picon

LKM fix for amd64

Hi, this patch makes LKM code correctly map memory on amd64 and
actually allows LKM work on that platform.

Also this fixes building LKM objects with gcc3.

Patch doesn't make any changes related to other platforms.

Fix by Oleg Safiullin <form <at> pdp-11.org.ru>.

Tested by him and me.

Index: share/mk/bsd.lkm.mk
===================================================================
RCS file: /cvs/src/share/mk/bsd.lkm.mk,v
retrieving revision 1.20
diff -d -u -r1.20 bsd.lkm.mk
--- share/mk/bsd.lkm.mk	2005/09/15 07:12:18	1.20
+++ share/mk/bsd.lkm.mk	2005/11/01 13:08:32
 <at>  <at>  -20,6 +20,10  <at>  <at> 
 CFLAGS+=	${CDIAGFLAGS}
 .endif

+.if ${MACHINE_ARCH} == "amd64"
+CFLAGS+=	-mcmodel=kernel
+.endif
+
 LDFLAGS+= -r
 .if defined(LKM)
 SRCS?=	${LKM}.c
Index: sys/arch/amd64/amd64/machdep.c
(Continue reading)

Permalink | Reply | 0 comments |
headers
Timothy Brown | 1 Nov 2005 21:10

IXP2400 support

Are there any drivers (or any drivers being worked on) for the Intel  
network processors (IXPxxxx)?

Tim
Permalink | Reply | 1 comment |
headers
Theo de Raadt | 1 Nov 2005 21:18
Picon
Favicon

Re: IXP2400 support

Perhaps if lots of us had hardware containing them.  But we don't.
Permalink | Reply | 0 comments |
headers
Craig, Dave | 1 Nov 2005 20:19

Hard real-time support for OpenBSD

Hi, I'm looking into using OpenBSD as a platform to host an application
with real-time scheduling needs.  Is there any active work on this?
What approach are you using?  Is there a branch that I might try to test
how well it works?

I reviewed the mailing list but did not see much mentioned this year
about real-time support.

Thank you for your help,

     Dave Craig
Permalink | Reply | 1 comment |
headers
Pailloncy Jean-Gerard | 1 Nov 2005 22:31

Re: Hard real-time support for OpenBSD

Google: OpenBSD + Real-Time

http://archives.neohapsis.com/archives/openbsd/2001-12/1420.html
http://www.rtmx.com/

http://www.openbsd.org/products.html
"RTMX sells a version of OpenBSD which has a full complement of POSIX  
real-time features added to it. They have graciously donated the  
source code for these extensions, and these changes will be  
integrated into OpenBSD soon."
"soon" means "soon since OBSD 2.2" at least ;-)

Cordialement,
Jean-Girard Pailloncy
Permalink | Reply | 0 comments |
headers
Alexandre Ratchov | 2 Nov 2005 16:14

midiplay(1) and gm1-on message

hello,

i've a small suggestion about midiplay(1):

currently midiplay(1) sends a "General Midi 1 System On" (GM1-on)
message before starting playback. This puts most midi devices in
"General Midi 1" compatibility mode. However there are other
modes than GM1 (GM2, GS, GX, ...) and i see no reason to force the
user to use one particular mode.

- Old midi devices have only one mode so we don't need to send
  them a "GM1-on" message.

- Recent midi devices have more advanced modes than GM1, the user
  may want to use them.

more generally, if a midi file is specific to GM1, imho the
correct approach is to put the "GM1-on" message in the midi file;
midiplay(1) will play it and the device will switch to GM1 mode

The attached patch removes the code that sends the GM1-on
message from midiplay(1).

Comments? other suggestions?

(if you think that it is important to keep this feature, i can provide
midi files containing GM1-on, GM2-on, GM-off messages to populate
for instance /usr/share/something)

regards,
(Continue reading)

Permalink | Reply | 0 comments |
headers
Marc Espie | 3 Nov 2005 01:06
Favicon

fix <cmath> C++include to work with _XOPEN_SOURCE

The gnu configure stuff does set up lots of defines statically, and it
fails miserably wrt defines like _XOPEN_SOURCE... namely, if
you try to c++ -D_XOPEN_SOURCE anything that #include <cmath>, then it
errors out.

Fixing bits/c++config.h is hard, but fortunately, all those defines are
only needed for cmath, so we can fix them after the fact...

This specific issue was noticed by wilfried while building gtk2mm...

I don't think it's worth it to bump libstdc++ shared lib version, since we are
fix a situation that didn't work at all before...

okay ?

Index: libstdc++/include/c_std/std_cmath.h
===================================================================
RCS file: /cvs/src/gnu/lib/libstdc++/libstdc++/include/c_std/std_cmath.h,v
retrieving revision 1.2
diff -u -p -r1.2 std_cmath.h
--- libstdc++/include/c_std/std_cmath.h	31 Jan 2004 20:50:28 -0000	1.2
+++ libstdc++/include/c_std/std_cmath.h	3 Nov 2005 00:03:01 -0000
 <at>  <at>  -48,6 +48,29  <at>  <at> 

 #include <bits/c++config.h>

+// XXX OpenBSD specific hack
+#if defined(_XOPEN_SOURCE) || defined(_ANSI_SOURCE) || defined(_POSIX_SOURCE)
+#undef _GLIBCPP_HAVE_ACOSF
+#undef _GLIBCPP_HAVE_ASINF
(Continue reading)

Permalink | Reply | 4 comments |
headers
Ryan McBride | 3 Nov 2005 04:06
Picon
Favicon

Re: OpenBSD 3.8 (and prior) arpbalance bug + patch

Moved from bugs <at>  to tech <at> 

arpbalance users: Please test the attached diff, and verify that
connections from different hosts are actually going to different
systems.

On Thu, Nov 03, 2005 at 09:09:37AM +1000, Matt Bradford wrote:
> Just a question - and I should have raised this in the e-mail - Yes, i
> saw your comment regarding using a hash like pf_hash() or whatever it
> was, but what's the motivation for doing this?
>
> Granted, I can see how in situations unlike mine, it's possible that people
> aren't filling subnets consecutively, and thus wouldn't balance out roughly
> 50/50.

Basically you shouldn't have to think about what IP address you're
assigning to a host in order for traffic to balance evenly.

> This is actually the first time i've dabbled with network structures
> in C - but wouldnt a packet coming from across the internet still have
> the same source IP address as the host that sent it? In that case,
> it'd be better to hash based on source IP because that way you're
> operating on the original IP source, not the MAC address of a router
> for example, that would always select one host.

It's not the data packet with the source IP that gets balanced, it's the
ARP request that gets balanced... for traffic coming across a router,
this ARP request comes from the router's IP address, so it doesn't
really matter whether you use the IP or the MAC address, the mapping is
constant. (The MAC address hashes a bit more nicely, though.)
(Continue reading)

Permalink | Reply | 1254 comments |
headers
Matt Bradford | 3 Nov 2005 04:15
Picon
Picon
Favicon

Re: OpenBSD 3.8 (and prior) arpbalance bug + patch

Oh, of course... I didn't even put two and two together. That makes a lot more
sense - i'll be applying the patch this afternoon. Thanks for the clarity.

Cheers,
Matt

-- 
-=--==-=-==----=-===-=---===-=---=----=--===--=-
Matt Bradford
BInfoTech(DataCommunications/SoftwareEng)

Computer Systems Support Officer
Information Security Institute
Queensland University of Technology
Brisbane, Australia
(Cricos Institution Code: No. 00213J)

Email: m.bradford <at> isrc.qut.edu.au
Phone: +61 (07) 3864 9512 (QUT Extension 9512)

-==----=-==--=---==--==--==-====-===--=--==--=--

Quoting Ryan McBride <mcbride <at> openbsd.org>:

> Moved from bugs <at>  to tech <at> 
>
> arpbalance users: Please test the attached diff, and verify that
> connections from different hosts are actually going to different
> systems.
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Matt Bradford | 3 Nov 2005 05:06
Picon
Picon
Favicon

Re: OpenBSD 3.8 (and prior) arpbalance bug + patch

Ryan,

Patch applied to ip_carp.c from the current web repository, which was then
grafted to my local tree of 3.8 sys. 1 hunk (#2) failed - applied manually.
Kernel compiled without glitch.

_IT WOULD APPEAR_ that the hosts weren't offering ARP replies - some hosts would
still work, but that was due to the arp cache. No investigation has been done
into this as of yet. Please let me know if people have a similar problem.

Cheers,
Matt

--

-- 
-=--==-=-==----=-===-=---===-=---=----=--===--=-
Matt Bradford
BInfoTech(DataCommunications/SoftwareEng)

Computer Systems Support Officer
Information Security Institute
Queensland University of Technology
Brisbane, Australia
(Cricos Institution Code: No. 00213J)

Email: m.bradford <at> isrc.qut.edu.au
Phone: +61 (07) 3864 9512 (QUT Extension 9512)

-==----=-==--=---==--==--==-====-===--=--==--=--

Quoting Ryan McBride <mcbride <at> openbsd.org>:
(Continue reading)

Permalink | Reply | 0 comments |

Gmane