Hey Guys.
First of all it's nice to be here. I had some previous experience with FreeBSD but I decided to give OpenBSD a go and I'm not one bit dissapointed.
I installed 4.4 3 days ago(had not known at the time that the next will be released the second day).
Was surprised to see that cpu scaling worked out of the box.that was not the case with any Linux I ever used, or with FreeBSD.
X configure actually worked and I had a working window manager in 1 minute.

I set apmd_flags to "-C", rebooted and automatic scaling worked. then I decided to upgrade to 4.5 (copied all the sets off the 4.5 cd to /sets, booted the 4.5 bsd.rd, started updating from disc, mounted /sets...it all worked ok...or so it seemed )
Without any other change I booted to 4.5, just to see my cpu was at full capacity when idling in the console (1.800 MHz). `sysctl hw` shows all the scaling stuff, and I can use `sysctl hw.setperf=0` to get it to 800MHz (minimum and cool), but apm does not do it automatically. So for now I have it with "-L" (manual mode) but I'd like apmd to do it automatically.
I should point out that I disabled apm in the kernel and enabled acpi (apm would crash on boot if enabled..this was a problem with everything I used before..it's my laptop's fault). I did this for 4.4 too and it worked.

Second problem is that my Broadcom won't connect to the AP. This is buggy under Linux too, but after a few tries it works.
It can detect AP's, and I see it can get my AP's bssid etc, so traffic works, but it just doesn't get an ip. dhclient says "no link ........ sleeping" and that's all. It runs in the background but no connection can be made. Enabling debug shows the auth beeing sent but after that nothing. The AP is unsecured so it's not a WEP/WPA issue. I decided to buy a rt73 chip based card tomorrow...so this ain't a big problem anymore (even though a fix would be nice)
Thank you all for any type of input

There were changes to ACPI code in the OS between 4.4 and 4.5. I would post a message to the @misc mailing list, briefly describing the problem, and posting a complete dmesg(8) in line with the message. To be extra helpful, you might place the output of acpidump(8) somewhere, and post a link to it (it's a few thousand lines long).

Re: bwi(4):

As to your broadcom issue, a dmesg here might prove helpful. Might not, but without it, all we could do is guess.

It can detect AP's, and I see it can get my AP's bssid etc, so traffic works, but it just doesn't get an ip. dhclient says "no link ........ sleeping" and that's all. It runs in the background but no connection can be made. Enabling debug shows the auth beeing sent but after that nothing.

Along with jggimi's requests,

please post the contents of hostname.bwi0 or whatever ifconfig(8) command is used to initialize the interface.

you should also ensure that the firmware used is up-to-date. bwi(4) provides more details on where to get updates.

Thanks for the responses guys
I have uploaded the outputs of dmesg, acpidump (rather big), ifconfig (before issuing config command) and uname to http://github.com/wraith0x2b/dotfiles/tree/master
The firmware is the one I got from `man bwi`, so I asume it's the latest.
About the hostname file, I stopped using hostname.bwi0 and started manually with `ifconfig bwi0 nwid "my ap name"` then `dhclient bwi0`. I was told this would be enough for a passwordless connection. Tried every other method, like disabling wep, wpa etc..I'm banging my head against the wall for 2 days now. I also have problems on Linux with this but after 5-10 tries (sometimes less) it connects and gets an ip. So I figure there's something with the card and/or the AP beeing too far away. Having a way of increasing the timeout period for dhclient would be a new thing to try I guess (don't know if I can do that or if it's possible though).
I'm buying that new card anyway... I'm sick of Broadcom and their silly closed source drivers

OpenBSD doesn't use a close source driver for Broadcom devices, the bwi firmware is code that is uploaded & executed by the chipsets internal processor.. not by the kernel.

This terminology confusion is quite common, leading many to believe that OpenBSD ships proprietary drivers.. it certainly does not.

Oh I know that. But I was under the impression that open source drivers for such chipsets are crappy (well not too good anyway) because the official drivers are closed source..thus requiring re-writing/reverse engineering and such.
I know this was the case for ATI until recently anyway.

The dmesg shows that this is -release/i386, so patch #003 from the errata might be applicable to this situation.

The dmesg also shows that the chipset is a BCM4318. There was a recent discussion about this on misc@, and while the question was not resolved, one of the respondents was able to circumvent the issue for themselves by disabling WPA on his router.

The dmesg shows that this is -release/i386, so patch #003 from the errata might be applicable to this situation.

The dmesg also shows that the chipset is a BCM4318. There was a recent discussion about this on misc@, and while the question was not resolved, one of the respondents was able to circumvent the issue for themselves by disabling WPA on his router.

I read that when I first noticed the problem.The AP I am using has no encryption, be it WEP or WPA so disabling isn't an option.

If you're talking about the 003 patch on http://www.openbsd.org/errata45.html I will try it tomorrow...but I am getting the new card anyway so might aswell wait until then. The big problem now is the APM one

Well one of the problems is solved I'm happy to say.
I received my new usb wifi card based on rt73 and IT RULES! Not only I can connect instantly and on the first try, but the signal gain is ridiculous compared to the Broadcom (from 30 dBm max went to 100 + some extra gain...). It worked out of the box which is another plus.

I fixed it. I was looking in a totally wrong area.
apmd WAS working, but the cpu got at full because the time it spent on interrupts was at 82.9%!
I disabled acpiprt and acpimadt in the kernel and now it all works ok.
Thanks everyone for the help

Using ACPI with acpiprt(4) disabled doesn't sound like an overly good idea, have you tried disabling ACPI entirely?

You haven't posted a dmesg(1) either, some people appreciate those.. you probably should have done that on your mailing list post as well.

Sending the results of acpidump(8) to a developer is also a good idea, hopefully they can fix ACPI on your laptop.

I did post a link going to dmesg in this thread. Yes I should have done the same with the misc@ email.
I can disable acpi alltogether, but then I don't have scaling anymore (eg cpu at max all the time which is really bad for my laptop)

The userland APM utilities communicate with the kernel via the apm(4) kernel API using 2 character devices, /dev/apm and /dev/apmctl.. historically this was only used only by APM, but now ACPI utilizes the interface as well.

The main purpose of this kernel interface is control the systems power states, like going into suspend/standby.. it doesn't however, control processor speed scaling.

This indicates that you can toggle between 3 different speeds using hw.setperf in sysctl(8), if you're running apmd(8), it will monitor CPU utilization and toggle this value to conserve battery life.. this functionality most definitely should work regardless of the availability of ACPI or APM.

You can monitor this sensor via hw.sensors.kate0 in sysctl(8).. you can also configure sensorsd(8) to monitor and act upon overly high temperatures.

Hopefully this clears some things up for you, as for what happens when neither APM or ACPI are enabled... apmd(8) will still work to scale speeds depending on processor utilization, but apm(8) requests to put the system to sleep will do nothing at all.

That does clear things up for me. Thanks for your time!
I will try this today. I though scaling really doesn't work without acpi.
I could write a sensord.conf to scale down cpu when heat is above 70-75 degrees, but not sure if I can do this on certain load (like apmd does it)
I'll look into this and come back with any results.