Re: Problem intr11 livelocked
Jonathan Buschmann wrote:
> Bill Hacker a 嶰rit :
>
*SNIP*
>>
> 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:
>
> http://www.actitude.net/~jonthn/dmesg.boot.all_disabled_RAID-enabled
> http://www.actitude.net/~jonthn/vmstat-all_disabled_RAID-enabled
>
> 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
accordingly.
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....
HTH,
Bill
討論串 (同標題文章)
完整討論串 (本文為第 9 之 15 篇)：