Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 02 Jun 2006 21:08:21 -0400
From:      Jim Pingle <lists@pingle.org>
To:        Antony Mawer <fbsd-stable@mawer.org>
Cc:        freebsd-stable@freebsd.org, Jack Vogel <jfvogel@gmail.com>
Subject:   Re: long timeout on boot
Message-ID:  <4480E105.1040106@pingle.org>
In-Reply-To: <4480DC6B.10306@mawer.org>
References:  <2a41acea0606011530wf7bca5du23711fbfbfbc81@mail.gmail.com>	<1149241101.60897.58.camel@buffy.york.ac.uk>	<2a41acea0606020943j1843d949kf8d25e3164255e43@mail.gmail.com> <4480DC6B.10306@mawer.org>

next in thread | previous in thread | raw e-mail | index | archive | help
Antony Mawer wrote:
> On 3/06/2006 2:43 AM, Jack Vogel wrote:
>> On 6/2/06, Gavin Atkinson <gavin.atkinson@ury.york.ac.uk> wrote:
>>> On Thu, 2006-06-01 at 15:30 -0700, Jack Vogel wrote:
>>> > Both on my own machine, and on systems in our test group's lab, we
>>> > notice these long (like 2min maybe?) delays near the end of boot. It
>>> > seems to be ATA/SATA related. It has just announced the one disk
>>> > it discovered, then shows the CPUs launched, and then it just sits
>>> > printing nothing for, like I said, maybe a minute or two. Finally
>>> it will
>>> > complete boot and all seems to be fine.
>>>
>>> Can you put a verbose dmesg up with debug.fdc.debugflags=255 set from
>>> the loader?
>>>
>>> I suspect you'll find it's floppy-related.  Try setting
>>> hint.fdc.0.disabled="1" from the loader and seeing if it goes away.
>>
>> YUP, I hadnt looked before, but during the whole timeout the floppy
>> access light is on. There were some messages during boot from the
>> controller as well.
> 
> I've seen this on a number of 6.0 production systems with exactly the
> same symptoms. Disabling the floppy controller removes the long delay.
> 
> I've skimmed the change log for the fdc driver:
> 
>     http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/fdc/
> 
> ... but there have been a huge number of commits over the recent few
> years. Any number of those sounds like potential candidates for
> introducing the problem, but it will need someone with a large degree of
> patience to try and identify where the problem started occurring.
> 
> I might add that it seems very hardware dependent: unfortunately none of
> my test machines on-hand exhibit the problem or I might be able to do
> some testing myself...
> 
> -Antony

I posted about this problem previously, when I had (very incorrectly)
thought it had something to do with the RAID controller.

I have a large number of servers that exhibit this behavior and have done so
since 6.0-RELEASE. I have 5.4 on one of them but I don't recall if it did
the same thing or not.

The servers I have which do this tend to be Intel chipset systems, most of
them are VA Linux boxes: Dual pIII-800s on L440GX+ Boards, if memory serves.

fdc0: <floppy drive controller> port 0x3f2-0x3f5 irq 6 drq 2 on acpi0
fdc0: [FAST]
fd0: <1440-KB 3.5" drive> on fdc0 drive 0

I have one or two of these setup I could do some testing with, but I'm not
sure what dates to start with, seeing as the problem has existed since
6.0-RELEASE on these (and with most of them that's the first release I've
used on them.)

I can check some more on Monday to see at least if the 5.x box is doing
this. It's a testing server that's not currently in use. I'd check right now
but it'd be almost impossible to diagnose remotely (no serial console.)




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4480E105.1040106>