Re: Current qc_defer implementation may lead to infinite recursion

2008-02-18 Thread Elias Oltmanns
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 for

Re: Current qc_defer implementation may lead to infinite recursion

2008-02-12 Thread Elias Oltmanns
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

Re: Current qc_defer implementation may lead to infinite recursion

2008-02-12 Thread Tejun Heo
Elias Oltmanns wrote: 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

Re: Current qc_defer implementation may lead to infinite recursion

2008-02-12 Thread Elias Oltmanns
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 that the

Re: Current qc_defer implementation may lead to infinite recursion

2008-02-12 Thread Tejun Heo
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 for one port hasn't changed in the meantime. This

Re: Current qc_defer implementation may lead to infinite recursion

2008-02-11 Thread Elias Oltmanns
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

Re: Current qc_defer implementation may lead to infinite recursion

2008-02-11 Thread Tejun Heo
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? + static int count = 0; +#define PIIX_QC_DEFER_THRESHOLD 5000 + + if (!ap) + ap =

Re: Current qc_defer implementation may lead to infinite recursion

2008-02-11 Thread Tejun Heo
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 yet but you're saying that blocked

Re: Current qc_defer implementation may lead to infinite recursion

2008-02-10 Thread Elias Oltmanns
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

Re: Current qc_defer implementation may lead to infinite recursion

2008-02-10 Thread Tejun Heo
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 recursion as I have explained to