Matthew Fredrickson wrote:
On Feb 20, 2007, at 9:43 PM, Robert Hancock wrote:
Matthew Fredrickson wrote:
I have noticed something that might be related as well. I am working
on a device driver that would have periodic data errors due to
exceptionally long interrupt handling latency. I have
On 2/21/07, Matthew Fredrickson <[EMAIL PROTECTED]> wrote:
It's a 2.6.18 kernel. What we're seeing (by means of the interrupt pin
on another card) is extremely large interrupt latency (measured from
the time the interrupt pin goes low to the first couple lines of code
in the IRQ handler to clear
On Feb 20, 2007, at 9:43 PM, Robert Hancock wrote:
Matthew Fredrickson wrote:
I have noticed something that might be related as well. I am working
on a device driver that would have periodic data errors due to
exceptionally long interrupt handling latency. I have come to the
point that I s
Matthew Fredrickson wrote:
I have noticed something that might be related as well. I am working on
a device driver that would have periodic data errors due to
exceptionally long interrupt handling latency. I have come to the point
that I suspect that it's the sata_nv driver, and now that we c
On Feb 12, 2007, at 12:49 AM, Tejun Heo wrote:
ris wrote:
procs ---memory-- ---swap-- -io -system--
cpu
r b swpd free buff cache si sobibo in cs us
sy id wa
0 0 0 303444 53224 36013200 276 157 627 814 5
2 89 4
Matthew Fredrickson wrote:
I have noticed something that might be related as well. I am working on
a device driver that would have periodic data errors due to
exceptionally long interrupt handling latency. I have come to the point
that I suspect that it's the sata_nv driver, and now that we c
ris wrote:
Tejun Heo gmail.com> writes:
iowait != cpu busy. Your cpu idleness stays above 80%.
Ok .. but one of my CPU core are at 99% usage
htop report this
So how to solve this problem ?
The red part of cpu usage bar represents 'iowait' not cpu usage. Fire
up both top
ris wrote:
procs ---memory-- ---swap-- -io -system-- cpu
r b swpd free buff cache si sobibo in cs us sy id wa
0 0 0 303444 53224 36013200 276 157 627 814 5 2 89 4
0 0 0 302956 53228 36033200 196
Tejun Heo gmail.com> writes:
>
> Hello,
>
> ris wrote:
> > and dmesg
>
> Please report...
>
> 1. 'vmstat 1' result during file copy (w/ cpu 100%)
> 2. 'dmesg' result after file copy
>
Sorry for late.
Dmesg get no errors /informations
vmstat 1
procs ---memory-- ---swap
Hello,
ris wrote:
and dmesg
Please report...
1. 'vmstat 1' result during file copy (w/ cpu 100%)
2. 'dmesg' result after file copy
--
tejun
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http
On Mon, 15 Jan 2007 18:26:42 +, Frederik Deweerdt wrote
> On Mon, Jan 15, 2007 at 06:54:50PM +0200, ris wrote:
> > I have motherboard with nforce 590 SLI (MCP55) chipset.
> > On other systems all its ok.
> >
> > But i tried a lot o kernels, configurations and always get cpu at 100% when
> > co
On Mon, Jan 15, 2007 at 06:54:50PM +0200, ris wrote:
> I have motherboard with nforce 590 SLI (MCP55) chipset.
> On other systems all its ok.
>
> But i tried a lot o kernels, configurations and always get cpu at 100% when
> copying files.
> I use SATA II samsung hard drive.
>
Any dmesg complain?
I have motherboard with nforce 590 SLI (MCP55) chipset.
On other systems all its ok.
But i tried a lot o kernels, configurations and always get cpu at 100% when
copying files.
I use SATA II samsung hard drive.
There is my lspci
00:0c.0 IDE interface: nVidia Corporation MCP55 IDE (rev a1) (prog-i
13 matches
Mail list logo
