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

Bug#425355: marked as done (dpt_i2o - disk IO causes very high load)

Your message dated Tue, 30 Dec 2008 11:33:18 +0100
with message-id <20081230103317.GA3582@galadriel.inutil.org>
and subject line Re: Bug#425355: Acknowledgement (dpt_i2o - disk IO causes very high load)
has caused the Debian Bug report #425355,
regarding dpt_i2o - disk IO causes very high load
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
425355: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=425355
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
Package: linux-image-2.6.18-4-k7
Version: 2.6.18.dfsg.1-12etch2

Doing any disk IO (> 10MB/s) causes the load on the system to rise into
extreme areas. This is bugging me, especially since the disks (4) are
on a separate RAID controller (Adaptec 2400A, module dpt_i2o).

For example: If I copy a big file via NFS onto the machine, the load
rises easily up to 8 (8 threads configured for nfsd). Copying the same
file via scp, the load gets still up to 5, so it doesn't look like it
is related to NFS. When I check with top what is causing this high
load, I can see that the system is spending all the time in iowaits.

I had this problem also with older kernels. I guess it was just not
that worse, because I just recently upgraded the NIC from 100MBit to
1GBit, causing extra stress for the disks.

Trying to debug things I found a something strange (at least for me).

PCI: Failed to allocate mem resource #6:10000@f8000000 for 0000:01:05.0
PCI: Bridge: 0000:00:01.0
  IO window: disabled.
  MEM window: e8000000-e8ffffff
  PREFETCH window: f0000000-f7ffffff
PCI: Bridge: 0000:02:05.1
  IO window: disabled.
  MEM window: disabled.
  PREFETCH window: disabled.
PCI: Bridge: 0000:00:10.0
  IO window: 2000-2fff
  MEM window: e9000000-e90fffff
  PREFETCH window: ea000000-ebffffff

0000:01:05.0 -> graphics card (AGP, nVidia nv15)
0000:02:05.1 -> PCI bridge of the RAID controller
                Why is the IO/MEM/PREFETCH window disabled?

Attached is also the full output of dmesg, lspci, /proc/interrupts,
/proc/iomem and /proc/ioports.

Could that be the reason for the high load?

cheers,
    Peter

-- 
Peter Hirdina <Peter.Hirdina@gmx.net>

Attachment: output.iomem
Description: Binary data

Attachment: output.ioports
Description: Binary data

Attachment: output.lspci
Description: Binary data

Attachment: output.dmesg
Description: Binary data

Attachment: output.interrupts
Description: Binary data


--- End Message ---
--- Begin Message --- 
On Tue, Dec 30, 2008 at 01:36:45AM +0100, Peter Hirdina wrote:
> Sorry, totally forgot about this bug.
> 
> > Does this error still occur with more recent kernel versions?
> 
> I haven't tested it, but it will. After plugging a PCI 1GBit ethernet
> card (Intel) into the system which also showed massive performance
> problems, I did some extensive research. Well, there is a bug, but it
> is not within Linux but the 760MPX chipset. AMD messed up the 32bit PCI
> bus completely. You will hardly get 20MB/s over it. Which explains the
> problems I had with the RAID controller and the ethernet card.
> 
> So, feel free to close this bug, since it was a hardware problem.
> Actually, I replaced the machine anyway a few ago anyway.

Thanks, closing the bug then.

Cheers,
        Moritz

--- End Message ---
Reply to: