Problem intr11 livelocked

[Bill Hacker]

Jonathan Buschmann wrote:

Bill Hacker a écrit :

*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