Actually, upgrading to latest snapshot didn't solve the issue.
But i found a fix!
Basicaly these xseries spare an internal adaptec controller and a pci board with the ServeRAID controller.
That internal controller has no devices attached to it in my server.
Disabling the internal adaptec controller seem to chase that bad timeout..
Boot isn't delayed anymore after finding ipsd0 logical volume.
Well to answer my own question.
I was reading around on the freebsd mailing list and found that the message is the result of a known, but harmless, bug in dc(4). Since its not a show stopper I'll let it slide.
The 4805 should work fine with the iso image, embedded has had a lot of stuff removed lately.
If it's not supported in our kernel build i'm sure we can add the correct "device blah" line to the kernel.
You can find the current kernel config here http://pfsense.com/cgi-bin/cvsweb.cgi/tools/builder_scripts/conf/pfSense.6?rev=1.14;content-type=text%2Fplain
The kernel in the latest builds has been "trimmed" quite a lot lately. I think you will find that the newest builds are much faster due to several improvements (like APC, smaller kernel for faster boot, a few tweaks here and there).
you can use the embedded or regular version of pfsense with the box. All you need to do is to load either image onto the compact flash or hard drive. After loading it on the boot device of your choice the video card doesn't help much other than to post check as there is no keyboard interface. Also, you don't need to have a pci video card as there is onboard video(trident chipset).
I have yet to get the serial port working properly with pfsense nor the leds on the front of the chassis.
When booted up all i normally see is the spinning thing.
So far, I've seen this error only because of an IRQ-Problem with an ACPI System, running pfsense on. It seems to me, that the realtek-driver is not able to share IRQ's under some circumstances with other drivers…
So, you might probably put the card in another pci-slot, and check, if the error occurs further on. Second, it may help to disable unneeded onboard components, as USB or LPT or a soundcard.
The CARP IPs can be handed over from one firewall to the other. What happens in the background is that the failover node grabs the macadress of the CARP IP after the master has died, so nobody in the network will notece that actually another machine took over. same IP, same MAC. The LAN CARP IP that is used as the gateway will act the same.
The price for the nexcom is right. It has some benefits like serial redirection (you even can access the bios at com1) and a rather short 19" 1U case (many switches are even deeper). I configured a 1U mini ITX system with 4 nics and a via C3 1GHz cpu but ended up around the price of the nexcom, at least when using non crappy hardware. And the nexcom comes completely assembled even with serial cable. Add RAM, a cf-card or a hdd and you are ready to roll.
Just a note if you have to hard code your ethernet speeds to check out:
You can hard-code the speeds into the config.xml file but we do not provide a GUI knob for this due to the incredible amount of times this simple thing gets messed up resulting in any os being blamed :)
Retried over and over. Finally ISP's modem failed to respond under any gven OS on my side. They must love me. I never ever use anything "standard" in my ventures and I usualy ask nasty questions noone knows an answer to.
I know I can get it to pull the gateway from config.xml for the inernet connection test. Should I add an entry in config.xml for the external site or just leave it yahoo? I guess a DNS server would also work.
I only have my WRAP for a few days this week before it's shipped off to a client. Having a lot of fun with it though. :)
Any good M$ software to check for CF read/write errors out there?
That's a good question. I've never run across anything such as this.
Simply create a dump file the size of the CF, with a value of hex 0xAA ( 10101010 ), and write it to the flash card. Then verify that there are no errors when comparing against the dump file.
Now write another dump file of hex 0x55 (01010101), and do the same.
This will veryfy that all bits on each byte of memory are set/unset and written/verified correctly.
It does work, however, kernelpolling has a lot of timings that should be tweaked to the appropriate platform/cpu performance. m0n0 aims at slow hardware and has an image for each platform which makes it possible to supply different sets for different hardware. As pfsense has only a general image supplying different optimizations is not that easy (unless we add some kind of pulldown menu with different optimizations or even a tweak page). This is something we already have discussed and even tested different settings with a wrap (see http://wiki.pfsense.com/wikka.php?wakka=Tuning ) and might appear in a version after 1.0.
Sorry about that but I didn't check this thread for a while.
My box specs are in my signature.
I have reflashed my box with 0.97 and all seems fine right now.
Maybe a CF card issue.
Gotta buy a Sandisk instead of this cheap stuff…
Actually I started one of the "other" topics. I never did find out what the problem was. And the problem I was having then is different. As the blink wasn't random flashes it was at a specific interval of about 2 seconds. This can be anywhere from less than a second to flashing very rapidly even when nothing is connected.
I fixed the problem last time by starting fresh with a new version. I guess I could try that again.
I was just posting incase someone else had experienced this. I've gone on holiday for a month and a half so I can't get back to fix/diagnose it anymore unfortunatly. Was worth a try.
Packagesupport might be split in 2 sorts of packages (suitable for all platforms / suitable for embedded builds).
This definitely won't make it in 1.0 though.
No worries, we wouldn't want to postpone 1.0 just because of that ;).