Robert Hancock wrote:
> However, how about putting in a printk in nv_adma_interrupt handler here:
>
> /* freeze if hotplugged or controller error */
> if (unlikely(status & (NV_ADMA_STAT_HOTPLUG |
>NV_ADMA_STAT_HOTUNPLUG |
>NV_ADMA_STAT_TIMEOUT |
>NV
Tejun Heo wrote:
How about putting a bunch of printks inside the interrupt handler? That
would tell us if it's even reaching the interrupt handler..
If you give me a patch, I'll apply it and cause lock up and report the
result. Just shoot the patches my way. But maybe reproducing the lock
up
Robert Hancock wrote:
> Tejun Heo wrote:
>> Tejun Heo wrote:
>>> Robert Hancock wrote:
Tejun Heo wrote:
> Tejun Heo wrote:
>>> [ 34.466899] testing NMI watchdog ... <4>WARNING: CPU#0: NMI
>>> appears
>>> to be stuck (0->0)!
>>> [ 34.555056] WARNING: CPU#1: NMI appears t
Tejun Heo wrote:
Tejun Heo wrote:
Robert Hancock wrote:
Tejun Heo wrote:
Tejun Heo wrote:
[ 34.466899] testing NMI watchdog ... <4>WARNING: CPU#0: NMI appears
to be stuck (0->0)!
[ 34.555056] WARNING: CPU#1: NMI appears to be stuck (0->0)!
Oops, missed that. I'll see whether there's IRQ
Tejun Heo wrote:
> Robert Hancock wrote:
>> Tejun Heo wrote:
>>> Tejun Heo wrote:
> [ 34.466899] testing NMI watchdog ... <4>WARNING: CPU#0: NMI appears
> to be stuck (0->0)!
> [ 34.555056] WARNING: CPU#1: NMI appears to be stuck (0->0)!
Oops, missed that. I'll see whether the
Robert Hancock wrote:
> Tejun Heo wrote:
>> Tejun Heo wrote:
[ 34.466899] testing NMI watchdog ... <4>WARNING: CPU#0: NMI appears
to be stuck (0->0)!
[ 34.555056] WARNING: CPU#1: NMI appears to be stuck (0->0)!
>>> Oops, missed that. I'll see whether there's IRQ storm going on.
Tejun Heo wrote:
Tejun Heo wrote:
[ 34.466899] testing NMI watchdog ... <4>WARNING: CPU#0: NMI appears
to be stuck (0->0)!
[ 34.555056] WARNING: CPU#1: NMI appears to be stuck (0->0)!
Oops, missed that. I'll see whether there's IRQ storm going on.
I made the nv irq handler to print messa
Tejun Heo wrote:
>> [ 34.466899] testing NMI watchdog ... <4>WARNING: CPU#0: NMI appears
>> to be stuck (0->0)!
>> [ 34.555056] WARNING: CPU#1: NMI appears to be stuck (0->0)!
>
> Oops, missed that. I'll see whether there's IRQ storm going on.
I made the nv irq handler to print message every
Robert Hancock wrote:
> Tejun Heo wrote:
>> Tejun Heo wrote:
>>> Robert Hancock wrote:
> Okay, just succeeded on the current #upstream-fixes, attaching the
> log.
> The machine is a brick after the crash.
I assume the cable got reconnected at 325 seconds? It looks like that
w
Tejun Heo wrote:
Tejun Heo wrote:
Robert Hancock wrote:
Okay, just succeeded on the current #upstream-fixes, attaching the log.
The machine is a brick after the crash.
I assume the cable got reconnected at 325 seconds? It looks like that
was during error handling for the previous unplug?
I d
Tejun Heo wrote:
> Robert Hancock wrote:
>>> Okay, just succeeded on the current #upstream-fixes, attaching the log.
>>> The machine is a brick after the crash.
>> I assume the cable got reconnected at 325 seconds? It looks like that
>> was during error handling for the previous unplug?
>
> I don
Robert Hancock wrote:
>> Okay, just succeeded on the current #upstream-fixes, attaching the log.
>> The machine is a brick after the crash.
>
> I assume the cable got reconnected at 325 seconds? It looks like that
> was during error handling for the previous unplug?
I don't remember too well (th
Tejun Heo wrote:
Tejun Heo wrote:
Robert Hancock wrote:
This has only been reported on one person's MSI board. Apparently
another revision of the same board is reported to work, and I can't
duplicate the problem on my Asus board, so it could just be some
hardware problem on that motherboard.
I
Tejun Heo wrote:
> Robert Hancock wrote:
This has only been reported on one person's MSI board. Apparently
another revision of the same board is reported to work, and I can't
duplicate the problem on my Asus board, so it could just be some
hardware problem on that motherboard.
>
Robert Hancock wrote:
>>> This has only been reported on one person's MSI board. Apparently
>>> another revision of the same board is reported to work, and I can't
>>> duplicate the problem on my Asus board, so it could just be some
>>> hardware problem on that motherboard.
>>
>> IIRC, I have two f
Tejun Heo wrote:
Robert Hancock wrote:
Mark Lord wrote:
Tejun Heo wrote:
Hello, guys.
We still have three problems with ADMA.
* hard lockup during resume * occasional hard lockup after
hotplug or other erros (probably related to the above?)
This has only been reported on one person's MSI boa
Robert Hancock wrote:
> Mark Lord wrote:
>> Tejun Heo wrote:
>>> Hello, guys.
>>>
>>> We still have three problems with ADMA.
>>>
>>> * hard lockup during resume * occasional hard lockup after
>>> hotplug or other erros (probably related to the above?)
>
> This has only been reported on one pers
Mark Lord wrote:
Tejun Heo wrote:
Hello, guys.
We still have three problems with ADMA.
* hard lockup during resume
* occasional hard lockup after hotplug or other erros (probably related
to the above?)
This has only been reported on one person's MSI board. Apparently
another revision of the
Tejun Heo wrote:
Hello, guys.
We still have three problems with ADMA.
* hard lockup during resume
* occasional hard lockup after hotplug or other erros (probably related
to the above?)
* occasional timeout of FLUSH after NCQ writes
I think we should disable ADMA for 2.6.24 and -stable for now.
Hello, guys.
We still have three problems with ADMA.
* hard lockup during resume
* occasional hard lockup after hotplug or other erros (probably related
to the above?)
* occasional timeout of FLUSH after NCQ writes
I think we should disable ADMA for 2.6.24 and -stable for now. What do
you guys
20 matches
Mail list logo
