Jesper Juhl [EMAIL PROTECTED] wrote:
These two lines :
- args-handler = task_no_data_intr;
+ args-handler = task_no_data_intr;
do the same thing.
Thanks for explaining, obviously I got a bit confused.
Sorry for the noise.
Elias
-
To unsubscribe from this list: send
Hi Tejun,
due to your commit 31cc23b34913bc173680bdc87af79e551bf8cc0d libata now
sets max_host_blocked and max_device_blocked to 1 for all devices it
manages. Under certain conditions this may lead to system lockups due to
infinite recursion as I have explained to James on the scsi list (kept
you
Tejun Heo [EMAIL PROTECTED] wrote:
Hello,
Elias Oltmanns wrote:
Hmmm... The reason why max_host_blocked and max_device_blocked are set
to 1 is to let libata re-consider status after each command completion
as blocked status can be rather complex w/ PMP. I haven't really
followed the code
Tejun Heo [EMAIL PROTECTED] wrote:
Elias Oltmanns wrote:
Hi Tejun,
due to your commit 31cc23b34913bc173680bdc87af79e551bf8cc0d libata now
sets max_host_blocked and max_device_blocked to 1 for all devices it
manages. Under certain conditions this may lead to system lockups due to
infinite
Tejun Heo [EMAIL PROTECTED] wrote:
Elias Oltmanns wrote:
+static int piix_qc_defer(struct ata_queued_cmd *qc)
+{
+static struct ata_port *ap = NULL;
+struct ata_queued_cmd qcmd[ATA_MAX_QUEUE];
missing static?
Oh well, I must have been too tired already yesterday. There are a few
Tejun Heo [EMAIL PROTECTED] wrote:
Elias Oltmanns wrote:
This proves that piix_qc_defer() has declined the same command 100
times in succession. However, this will only happen if the status of
all the commands enqueued for one port hasn't changed in the
meantime. This suggests to me
Hi Tejun,
Tejun Heo [EMAIL PROTECTED] wrote:
Elias Oltmanns wrote:
Tejun Heo [EMAIL PROTECTED] wrote:
Elias Oltmanns wrote:
This proves that piix_qc_defer() has declined the same command 100
times in succession. However, this will only happen if the status of
all the commands enqueued
Hi all,
at the moment I'm having another go at trying to make the disk shock
protection patch fit for upstream submission. However, there are still
some fundamental issues I'd like to discuss in order to make sure that
I'm heading in the right direction.
The general idea: A daemon running in
Jeff Garzik [EMAIL PROTECTED] wrote:
Elias Oltmanns wrote:
The general idea: A daemon running in user space monitors input data
from an accelerometer. When the daemon detects a critical condition,
i.e., a sudden acceleration (for instance, laptop slides off the desk),
it signals the kernel so
