DragonFly BSD
DragonFly bugs List (threaded) for 2005-03
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: Problem intr11 livelocked

From: Bill Hacker <wbh@xxxxxxxxxxxxx>
Date: Thu, 03 Mar 2005 05:03:27 +0800

Jonathan Buschmann wrote:

Bill Hacker a écrit :


At first sorry i was probably unclear ( lack in my english ) but i've currently no Dfly installed on the disk but i'm trying to install it.

That was clear. I presumed you were coming up on the CD only...

I've disabled all i can (USB , NIC , Audio, Serial, Parallel Port, PCI SCSI Card)

Here is the dmesg and the vmstat output:


I've already tried with or without ACPI/RAID Promise and there is still the same problem.

All i can say is that your right it's the ICH5 the problem (the ATA part only ?)

More complex than that (usually).

There can be design flaws / compromises / overly clever shortcuts at the MB trace level,
in silicon, and/or in the BIOS. A given multifunction chipset can work or fail in different MB,
different silicon or BIOS rev levels, and 'only with..' - or 'only NOT with..' - selected OS.

Most commodity MB will ship as soon as they 'don't break' with WinWoes. Fact of life.

It is not uncommon for a multi-function chip to, for example, require that the sound
subsystem be enabled if the otherwise unrelated ethernet NIC is to work, or for on-board
IDE controllers to still be fully-functional even if 'disabled' and reported as such by the BIOS.

Often a designer has had to shared a package pinout, board trace, or logic line that
controls gates or tri-stated I/O. Anything to keep per-unit production and testing costs down.

To the extent an OS 'believes' the BIOS report - or can be told a lie in a driver, this may not matter.

The BSD's, OS/2, or Linux can be more demanding - or less tolerant of sub-optimal
situations. OS/2 the most demanding of all, as it even tests to find which parts of
memory are fastest, and where best to lay down directories and most-used files on
HDD for optimal head seeks, (hpfs, not jfs) and locates things in RAM and on disk

Basically - as you can see from dmesg, 'real' OS's don't trust (or even require) much
from the BIOS. They do their own resource scan and can locate, test, and use
on-board or on-bus devices that the BIOS otherwise claims are disabled.

It might save you some time, and give others finer-grained clues if you could try a FreeBSD
and/or a Linux install ('minimal; for BSD, a small download like Knoppix or Morphix for Linux)
- on that same hardware and report the results, especially as you re-enable various functions.

If it shows the same issues, it may be correctable with an updated BIOS load.
Otherwise, it is effectively a 'WinBoard'.

If one or more of the other OS' (WinWoes need not apply...) works without a whimper,
then your report can help others try to delve into why and where DragonFly does not do so.

For the time being, it smells to me like a 'hardware' issue....



[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]