Hi Scott,
Thanks for the heads up. Here is what I did below to get around that
problem.
I went into the BIOS and disabled the Floppy controller but the simplest way
was to tell the BIOS that no floppy was attached. This worked for me and
booted straight up normally.
I did notice however that during the boot process, that even when told that
no floppy is attached, it is still allocated in the IRQ to the controller.
So to physically disable the floppy controller would be to take it from it
IRQ.
I also tried it again with another known working floppy drive and again the
delay. I was using a new cable on the floppy drive and when I attached it I
thought that something looked odd. I again rebooted and the floppy activity
light was constantly on. So I checked the cable and saw that the power side
of the cable was on the wrong side.
This can easily be over looked as the locating tab on the cable was on the
wrong side and just to plug it into where it matches was the fault. Remove
the locating tab, reattach cable to correct locating position (power side of
cable to power plug) and hey presto it now boots and is working as it should
with the floppy drive enabled. During the boot procedure it gets to ad0 then
acd0, it then sends a signal to the floppy drive and waits for the reply
signal from the floppy drive unless it is disabled it waits patiently until
it gets to timeout and leaves.
It appears that some cable manufacturers are making floppy drive cables
incorrectly. This can be a trap for new players and those who don’t follow
their gut instincts and use what they know works. Also some older floppy
drives have its cable connector inverted to that of new drives, for which
the new cables are made.
Kindest Regards,
Craig Roy
Horizon IT Consultants
[EMAIL PROTECTED]
AUSTRALIAN RESELLER
FOR
-----Original Message-----
From: Scott Ullrich [mailto:[EMAIL PROTECTED]
Sent: Thursday, 15 September 2005 1:30 AM
To: [email protected]
Subject: Re: [pfSense-discussion] Massive Boot delay during load
Disable the floppy controller. Its been reported on the FreeBSD lists.
Also, I'm working on a small bug where php is launching quite
frequently which is driving up the CPU load.
Scott
On 9/14/05, Gary Buckmaster <[EMAIL PROTECTED]> wrote:
>
> I have also seen this behavior on several different machines with no rhyme
> or reason to it. I have seen this issue in 0.82.4 as well as 0.84 (I
don't
> remember off-hand if I saw it happening in a version previous to 0.82.4 or
> if so, what version it was).
>
> This issue does not appear to be specific to a particular hard drive
> make/type/model nor to a particular brand of motherboard, but I would
> suspect that this hang, whatever it is, is probably a FreeBSD issue and
not
> specific to pfSense.
>
> -Gary
>
>
> -----Original Message-----
> From: Craig Roy [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, September 14, 2005 6:17 AM
> To: [email protected]
> Subject: [pfSense-discussion] Massive Boot delay during load
>
>
>
>
> Hi All,
>
>
>
> Thanks for your work and efforts in making pfSense a great product.
>
>
>
> After the release of the Update .84 I downloaded the complete update file
> and proceeded to upload to my test machine, (which will be going through
its
> paces until November when I finally get DSL).
>
>
>
> Here is what I have experienced after the update. After uploading the
update
> file, I rebooted the system and observed the boot process. I was initially
> met by the normal bootup process until it got to:
>
>
>
> ad0: 38165MB <Seagate ST340016A 3.10> at ata0-master UDMA100
>
> acd0: CDRW <CD-W54E/7.1F7H> at ata1-master PIO4
>
> 10minute boot delay then displayed the following (copied from the system
log
> but same message).
>
> Trying to mount root from ufs:/dev/ad0s1a
>
>
>
> I thought that it had stalled during bootup and I rebooted.
>
>
>
> Again the delay halt, during this delay, no HDD or CDRW activity is
observed
> for nearly 10 minutes (to the second). I thought that I had managed to
> corrupt the setup. I simply reinstalled the previous ISO .82.4 and normal
> boot time experienced. I then again updated the firmware to .84 and
> rebooted, the same delay noticed and timed at 10minutes before continuing
to
> the pf menu. I wondered if the update had a problem, so I downloaded the
ISO
> .84 and reinstalled the complete setup from the new ISO.
>
>
>
> From booting the CD to get to the install procedure was again 10 minutes.
I
> have gone through the boot loader files, but I am unable to see anything
out
> of the ordinary that would cause this delay.
>
> I changed the IDE Channels from CDRW to HDD and so on that I would
normally
> do during a troubleshooting procedure, right down to having No NIC's
> installed and HDD only, same result.
>
>
>
> Will the old loader files be compatible with this version to test?
>
> I am not sure if it is looking for a device that is not actually installed
> in my machine that may have been on the DEV machine, and thought that it
may
> actually look for Flash Cards during this time and is consistently waiting
> for a response until it times out before continuing.
>
> Have you got any ideas that I may try?
>
>
>
> WebGUI CPU Meter Usage is better but still @ 60% - 67% idle.
>
>
>
> I hope that you don't mind me giving you some feedback. I am not greatly
> concerned at this point in time as this is basically my own machine. I am
> used to installing systems and testing is one of the jobs that I do day to
> day.
>
>
>
> SYSTEM SPECS
>
> 2GHZ Intel P4
>
> 40GB HDD
>
> 512MB DDR
>
> 4xNETGEAR RLTK8169
>
>
>
> Kindest Regards,
>
>
>
> Craig Roy
>
> Horizon IT Consultants
>
> [EMAIL PROTECTED]
>
>
>
> AUSTRALIAN RESELLER
>
> FOR
>
>
>
>
>
>
> --
> No virus found in this outgoing message.
> Checked by AVG Anti-Virus.
> Version: 7.0.344 / Virus Database: 267.10.24/101 - Release Date:
13/09/2005
>
>
>
--
No virus found in this incoming message.
Checked by AVG Anti-Virus.
Version: 7.0.344 / Virus Database: 267.10.25/102 - Release Date: 14/09/2005
--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.344 / Virus Database: 267.10.25/102 - Release Date: 14/09/2005
