On Tue, Oct 23, 2012 at 11:05:49AM +0100, Alan Cox wrote:
> > So yes, blacklisting it and verifying that your system still operates
> > normally would be something to do. If it does, you could also build a
> > kernel with pata_acpi disabled (that is, provided you build your own
> > kernels).
>
> The crash is still a bug. It needs chasing down.
Yes, ata_timing_find_mode gives NULL, we found that out.
Anton, Phillip, anyone willing to run this hunk below and get us the
output:
---
diff --git a/drivers/ata/pata_acpi.c b/drivers/ata/pata_acpi.c
index 09723b76beac..80d594d6e7c8 100644
--- a/drivers/ata/pata_acpi.c
+++ b/drivers/ata/pata_acpi.c
@@ -144,6 +144,13 @@ static void pacpi_set_dmamode(struct ata_port *ap, struct ata_device *adev)
/* Now stuff the nS values into the structure */
t = ata_timing_find_mode(adev->dma_mode);
+ if (!t) {
+ pr_err("%s: ata_timing_find_mode gives NULL; adev->dma_mode: 0x%x\n",
+ __func__, adev->dma_mode);
+
+ return;
+ }
+
if (adev->dma_mode >= XFER_UDMA_0) {
acpi->gtm.drive[unit].dma = t->udma;
acpi->gtm.flags |= (1 << (2 * unit));
--
Thanks.
--
Regards/Gruss,
Boris.
--
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
