lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <46B0E975.30404@free.fr>
Date:	Wed, 01 Aug 2007 22:13:41 +0200
From:	Laurent Riffard <laurent.riffard@...e.fr>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
CC:	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org, linux-ide@...r.kernel.org
Subject: Re: 2.6.23-rc1-mm2 (checks-for-80wire-cable-use-in-pata_via)

Le 01.08.2007 08:09, Andrew Morton a écrit :
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc1/2.6.23-rc1-mm2/
...
> +libata-acpi-checks-for-80wire-cable-use-in-pata_via.patch
...
>  sata/pata things

Alan,

this does not work after a suspend-resume cycle, I get a " ACPI get
timing mode failed (AE 0x1001)" error.

$ dmesg | grep ata
...
scsi0 : pata_via
scsi1 : pata_via
ata1: PATA max UDMA/100 cmd 0x000101f0 ctl 0x000103f6 bmdma
0x0001b800 irq 14
ata2: PATA max UDMA/100 cmd 0x00010170 ctl 0x00010376 bmdma
0x0001b808 irq 15
ata1.00: ATA-5: ST340016A, 3.75, max UDMA/100
ata1.00: 78165360 sectors, multi 16: LBA
ata1.01: ATA-7: Maxtor 6Y080L0, YAR41BW0, max UDMA/133
ata1.01: 160086528 sectors, multi 16: LBA
ata1.00: configured for UDMA/100
ata1.01: configured for UDMA/100
ata2.00: ATAPI: HL-DT-ST DVDRAM GSA-4165B, DL03, max UDMA/33
ata2.01: ATAPI: CD-950E/AKU, A4Q, max MWDMA2, CDB intr
ata2.00: configured for UDMA/33
ata2.01: configured for MWDMA2
ata1.00: Unable to set Link PM policy
ata1.01: Unable to set Link PM policy
ata2.00: Unable to set Link PM policy
ata2.01: Unable to set Link PM policy
...
[ suspend-to-disk/resume cycle happens here ]
...
ata1.00: Unable to set Link PM policy
ata1.01: Unable to set Link PM policy
ata2.00: Unable to set Link PM policy
ata2.01: Unable to set Link PM policy
ata1: ACPI get timing mode failed (AE 0x1001)   <==========
ata1.00: limited to UDMA/33 due to 40-wire cable
ata1.01: limited to UDMA/33 due to 40-wire cable
ata1.00: configured for UDMA/33
ata1.01: configured for UDMA/33
ata2: ACPI get timing mode failed (AE 0x1001)
ata2.00: configured for UDMA/33
ata2.01: configured for MWDMA2


Anyway, long before 2.6.23-rc1-mm2, 80-wire cable detection was
already wrong after a suspend-resume cycle. So I cooked the
following patch 2 days ago.

It may be the wrong approach but it works for me.

-- 
pata_via: preserve cable detection bits in via_do_set_mode

via_cable_detect performs cable detection by checking bits in PCI
layer. But via_do_set_mode overwrites these bits. This behaviour
breaks cable detection after suspend/resume cycle.

So let's teach via_do_set_mode to preserve cable detection bits.

Signed-off-by: Laurent Riffard <laurent.riffard@...e.fr>
---

 drivers/ata/pata_via.c |    7 +++++++
 1 file changed, 7 insertions(+)

Index: linux-2.6-mm/drivers/ata/pata_via.c
===================================================================
--- linux-2.6-mm.orig/drivers/ata/pata_via.c
+++ linux-2.6-mm/drivers/ata/pata_via.c
@@ -238,6 +238,7 @@ static void via_do_set_mode(struct ata_p
 	unsigned long T =  1000000000 / via_clock;
 	unsigned long UT = T/tdiv;
 	int ut;
+	u8 cable80_status;
 	int offset = 3 - (2*ap->port_no) - adev->devno;


@@ -287,6 +288,12 @@ static void via_do_set_mode(struct ata_p
 			ut = t.udma ? (0xe0 | (FIT(t.udma, 2, 9) - 2)) : 0x07;
 			break;
 	}
+
+	/* Preserve cable detection bit */
+	pci_read_config_byte(pdev, 0x50 + offset, &cable80_status);
+	cable80_status &= 0x10;
+	ut |= cable80_status;
+
 	/* Set UDMA unless device is not UDMA capable */
 	if (udma_type)
 		pci_write_config_byte(pdev, 0x50 + offset, ut);



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ