It would be more likely that an overhaul of est(4) would actually remove the hardcoded values. They only seem to be there as work around for a bad bios coding. The way this is supposed to work is the bios passes infomation to the OS via ACPI. The bios should contain the information for all the CPUs it supports.
The other possibility would be to add the values to the module yourself and recompile it. This probably isn't that difficult but would require some time studying the code. I had thought about doing that myself a few times but the performance increase just isn't worth it IMHO.  ;)

Steve

Thanks all!

Curiosity killed the cat. But you know what? Satisfaction brought him back!

The LiveCD worked fine. It's just that there were so many versions, I wanted to be sure I was using the correct one.

Happy New Year all!

thanks for the input….i figured out the problem i think...i was trying to install live-cd 2.0.2 i386 via usb-dvd drive with the iso burnt to a dvd...pfsense would not install even when i chose option 2....i then remembered i had a cd with version 1.2 laying around; this install without any issue with option 2....i dont know if it was the version i was trying to install or the install media that was causing the issue....now i will trying to install version 2.0.2 using a cd tomorrow

Check http://redmine.pfsense.org/issues/2704

You could trying adding the "reject" directive (until a fix is included in base pfSense)

Thanks.  I think I figured as much.  Maybe I'll try and find a spare netbook and get a USB ethernet dongle to play around with some of the other features and still keeping a low energy footprint.

LoboTiger

ya it was some sort of glitch. i did a factory default reset and now it works fine.

thank you all.

@cmb:

That disables MSI in the NIC driver, which I guess either the driver or the hardware has problems with. MSI is:
http://en.wikipedia.org/wiki/Message_Signaled_Interrupts

Thank you both for your time and help. As of this post it's still up and running without issue.

@Darkk:

Will this Linksys / Cisco WUSB600N ever be supported in PfSense 2.0.2 or later?

There are apparently two different chipsets in the WUSB600N. v1 reportedly uses a chipset supported by the run driver. v2 uses a chipset that doesn't appear to be supported.

@Darkk:

If not what is a good wireless-N USB stick I can use that works well?

Have a read through recent entries in the pfSense Wireless forum.

The battery is by my guess at least 7 years old. I tested the battery and it was dead, so I pulled it.
I have a large UPS under my desk, so it isn't much of an issue.

If you can, disable DHCP and NAT from the TP Link box so that you are not doing double NAT.

Unfortunately it doesn't reboot from Linux / BSD directly either.  Have had a search around and found many instances of the same problem (several years ago) but with no apparent solution.

Unless anyone can suggest a way to emulate a windows reboot I think I am out of possibilities.

It is a shame as I have two of these old Compaqs that were sitting on a shelf for years - and pfs seemed the ideal tool to make them useful again. They are very small and almost silent - plus they take full height NICs, unlike most SFF PCs that need higher priced low profile. As I don't have any other spare units lying around I will continue to use them for now - living with the reboot issue.  Hopefully they remain stable so that the reboot problem is effectively irrelevant.

Thanks for the suggestions - will hope that someone comes up with a novel solution!!

….................

Just come across this as a possible solution elsewhere:

I get this problem unless I boot with reboot=pci in my kernel args.

Not sure if this relates to building the kernel - or something that could be loaded?  (Way out of my comfort zone!)  Any thoughts?

Thanks wallabybob!

I now have the following under /dev
[2.1-BETA1][admin@pfsense.localdomain]/root(6): ls /dev/cu*
/dev/cuaU0      /dev/cuaU0.lock /dev/cuaU1.init /dev/cuaU2      /dev/cuaU2.lock
/dev/cuaU0.init /dev/cuaU1      /dev/cuaU1.lock /dev/cuaU2.init

… and have setup PPP interfaces, which actually go as far as to show me dBm and signal % values ... but under status>system logs the following is showing ...

ppp: [opt1_link0] CHAT: +CGDCONT=1,"IP","internet"
ppp: [opt1_link0] CHAT: Detected Hayes compatible modem.
ppp: [opt1_link0] CHAT: The modem responded with "ERROR" to the command "AT&F&C1&D2E0S0=0M1" at ModemCmd: label.
ppp: [opt1_link0] MODEM: chat script failed
ppp: [opt1_link0] Link: DOWN event
ppp: [opt1_link0] LCP: Down event

… also ...

[2.1-BETA1][admin@pfsense.localdomain]/root(8): usbconfig -d 1.2 dump_device_desc show_ifdrv
ugen1.2: <huawei mobile="" huawei="">at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON
ugen1.2.0: umodem0: <huawei 0="" 2="" huawei="" mobile,="" class="" 0,="" rev="" 2.00="" 1.02,="" addr="">ugen1.2.1: umodem1: <huawei 0="" 2="" huawei="" mobile,="" class="" 0,="" rev="" 2.00="" 1.02,="" addr="">ugen1.2.2: umodem2: <huawei 0="" 2="" huawei="" mobile,="" class="" 0,="" rev="" 2.00="" 1.02,="" addr="">ugen1.2.3: umass0: <huawei 0="" 2="" huawei="" mobile,="" class="" 0,="" rev="" 2.00="" 1.02,="" addr="">ugen1.2.4: umass1: <huawei 0="" 2="" huawei="" mobile,="" class="" 0,="" rev="" 2.00="" 1.02,="" addr="">bLength = 0x0012
  bDescriptorType = 0x0001
  bcdUSB = 0x0200
  bDeviceClass = 0x0000
  bDeviceSubClass = 0x0000
  bDeviceProtocol = 0x0000
  bMaxPacketSize0 = 0x0040
  idVendor = 0x12d1
  idProduct = 0x1c05
  bcdDevice = 0x0102
  iManufacturer = 0x0002  <huawei>iProduct = 0x0001  <huawei mobile="">iSerialNumber = 0x0000  <no string="">bNumConfigurations = 0x0001

… should umodem* not be u3g* in the above?

Thanks again for the help, it at least feels like I'm getting somewhere.</no></huawei></huawei></huawei></huawei></huawei></huawei></huawei></huawei>

Yes, I have tested on 2.1. It's working well.

Just saw this thread. My recommendation would had been an i3 no matter what.. Steve knows that :-) Atom processor just doesn't cut it for me. Plus you have a good hardware that you can switch to a full blown PC if required at a later time. $$ difference between Atom and i3 is not that much. For a very low end straight simple firewall system Atom is fine but it's has long lost the speed battle with i3 as you need the power once you start putting in resource intensive packages like Snort. And I highly recommend you add Snort to the firewall. Squid and others are just matter of personal preference and needs but Snort is something the firewall really needs to shield you from attackers.

@ptt:

Check the second post of this thread (stephenw10 post)

http://forum.pfsense.org/index.php/topic,57045.msg304449.html#msg304449

Thanks.  I'll modify the /boot/loader.conf.local file as it recommends.  I was hoping it'd be something so simple.  ;)

Nice!
Yes the PWM employed by the SuperIO chip to control the fan speed completely screws the speed readout once you go below a certain level. Hex value BB I seem to recall. That's why you can't use a value below BB in the bios for the initial fan speed. The completely fictitious huge values crash the bios setup code.

Steve

There is no public information on rebranding that's up to date, complete, and accurate. If you're building a custom-branded product, you can afford to purchase the reseller subscription and get the pros to help with your product. We'd be glad to help.

Yes thanks for sharing this.  Intend to look into the video blanking stuff after first of the year.  Though on my DELL Inspiron 5100 closing the lid seems to do nothing other than turning off the display and pfSense continues to run just fine.  Would like to turn off display (including backlight) without closing the lid/display.

Turned on PowerD with Adaptive setting and that seems to work fine.  However when set to Hiadaptive the current/max display in dashboard comes and goes.  One update cycle it with be there then the next gone, then back again and so on.

UPDATE:
Just noticed it comes and goes in Adaptive mode also.  Just less so than in Hiadaptive mode.

$60 is probably the cheapest you can get any worthwhile UPS. I'd expect to spend more. I've bought cheap no name UPSes before and will almost certainly never do so again. They don't last, and their QA is horrid. I got a RMA replacement on one that the second I plugged it in, shot sparks like crazy and started billowing smoke. Power protection isn't worth screwing around with, damage to equipment and potentially yourself isn't worth saving a few bucks (if they're shipping something that blows up like that, I'm probably lucky I wasn't electrocuted).

I have a Asus C60MI-I (fanless & no coil whine) + spare 8GB corsair vengeance ddr3 with a "free (€150)" dual Intel NIC PCI-E x4 controller.
It runs 120Mbit ISP connection no sweat..