Re: Promise SATA TX4 300 port timeout with sata_promise in 2.6.22, kernel panic in 2.6.23
Hello, I Stratford wrote: > The purpose of the mail is to document and share my experience in the > hope that someone might find it useful, either for debugging their own > TX4 300-centric system issues or figuring out what is up with > sata_promise and the TX4 300 in 3Gbps mode. I also wish to offer my > somewhat unique promise-based system as a test environment for either > the timeout or kernel panic issues. I obviously have some basic need > for data integrity of the RAID5, but this system is not in production > and is therefore more available for testing purposes than the average > machine with 22 Promise SATA ports.. :) [cc'ing Mikael Pettersson] It seems those 3Gbps promise controllers have hard time getting out of transmission errors. Is it because hardreset doesn't work? Can we fix it? Also, if 3Gbps can't be made reliable on those controllers, how about limiting it to 1.5Gbps by default with appropriate warning messages? Without PMP, it's not like we're gonna earn anything by driving the thing at 3Gbps. Thanks. -- tejun - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: SATA eating my disk, port reset, destroying unrelated data
Robert Hancock wrote: > Norbert Preining wrote: >> ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x40 action 0x2 > > Serror 0x40 means a handshake error. Usually Serror indications are > due to a hardware problem (bad SATA cable, power or drive problem). > >> ata1.00: (BMDMA stat 0x25) >> ata1.00: cmd 35/00:00:2a:6f:c0/00:04:0c:00:00/e0 tag 0 cdb 0x0 data >> 524288 out >> res 51/84:10:1a:72:c0/84:01:0c:00:00/e0 Emask 0x10 (ATA bus >> error) And error register value 0x84 - ICRC (CRC error on ATA bus) and ABRT (command abort) - agrees with what SError indicates. You're experiencing transmission errors. >> ata1: soft resetting port >> ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300) >> ata1.00: configured for UDMA/133 >> ata1: EH complete >> >> Even worse, sometimes the reset does not work ... >> >> ata1: device not ready (errno=-16), forcing hardreset >> ata1: hard resetting port >> ata1 SRST failed (errno=-19) >> ata1: reset failed (errno=-19), retrying in 10 secs >> .. >> >> (typed from a digital photo, nothing remains in the logs) >> >> After this I need to do a cold boot otherwise the drive is really in a >> bad state and not even the bios gets it right. > > If even the BIOS cannot reset properly then that also really points to a > hardware problem.. Also, firmware on some harddrives die solidly when transmission errors occur. Maybe yours is one. There's nothing much the driver can do about both the transmission error and the drive locking up afterward. If the transmission errors occur frequently, the chance is that either your drive or power supply is dying. As for the drive lock up, maybe firmware update will help. * "smartctl -a /dev/sda" might report something interesting. * Connect the drive to different SATA and power connector and see if the problem persists. * Connect the drive to a separate power supply and see if the problem persists. -- tejun - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.24-rc1: pata_amd fails to detect 80-pin wire
Hello, Cable detection has always been broken for pata_amd. Recent changes seem to have broken some other subset tho. The following patchset to get it fixed once and for all is pending. http://thread.gmane.org/gmane.linux.ide/24524 Thanks. -- tejun - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: AHCI + ST3160023AS + NCQ problems
Matheus Izvekov wrote: >> Indeed removing the jumper of sdb made it be recognised as SATA2. But >> sdc, what the problem is really about, is neither SATA2, not has any >> jumper whatsoever. but both the manufacturer and libata claim it >> supports NCQ. >> > > Anything i could do to help debug this? or perhaps it makes more sense > to just blacklist NCQ for this particular drive? Timeouts on modern SATA disks usually indicate hardware problem. * unstable power supply (this is quite common) * faulty cable or poorly seated connectors * faulty drive or controller (seems rare) Please apply common hardware debugging method - isolate problem by changing configuration piece-by-piece and finding out to which component the error actually belongs to. -- tejun - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: only one drive in a port multiplier system is being recognized
Greg Hennessy wrote: > I have a LYCeSATA-4x pci card that is port multiplier compatible (it > works fine > under win xp) that is only showing one of 5 attached drives when > attached to > a Redhat 5 computer, with both 2.6.18-8.1.15.el5 and 2.6.23.1. > The SATA link shows as up for the one recognized drive, the other four > drives show the link down. > Any sugguestions as to what may be the problem? Stock 2.6.23.1 doesn't have PMP support. 2.6.24 will. You need patches from the following page. http://home-tj.org/wiki/index.php/Libata-tj-stable -- tejun - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: linux-ata.org contributions
Jeff Garzik wrote: >> So, my preference is a wiki. I don't care which wiki it is as long as I >> can edit and view it directly. > > So noted, it sounds like a wiki it greatly preferred by all involved. > I'll look around for one I like. > > Expect no action until Nov 16 at the earliest, of course... Enjoy your vacation. :-) -- tejun - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: linux-ata.org contributions
Tejun Heo wrote: Jeff Garzik wrote: I wouldn't push it out unless it looked OK in my browser. But overall I tend to dislike wikis. They enable collaboration, but tend to be uniformly ugly, cumbersome, and CPU intensive. Besides collaboration, one thing I like about wikis is that updating the page is an one-step process. You can just go there and edit things directly and pages are updated and history is recorded immediately. Compared to normal web pages where you have to go through one or a few iterations of edit -> view -> check in if you wanna -> upload / send pages, it's just more efficient. Well, I also dislike editing html pages directly and pages generated by openoffice is ugly. So, my preference is a wiki. I don't care which wiki it is as long as I can edit and view it directly. So noted, it sounds like a wiki it greatly preferred by all involved. I'll look around for one I like. Expect no action until Nov 16 at the earliest, of course... Jeff - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: linux-ata.org contributions
Jeff Garzik wrote: > I wouldn't push it out unless it looked OK in my browser. > > But overall I tend to dislike wikis. They enable collaboration, but > tend to be uniformly ugly, cumbersome, and CPU intensive. Besides collaboration, one thing I like about wikis is that updating the page is an one-step process. You can just go there and edit things directly and pages are updated and history is recorded immediately. Compared to normal web pages where you have to go through one or a few iterations of edit -> view -> check in if you wanna -> upload / send pages, it's just more efficient. Well, I also dislike editing html pages directly and pages generated by openoffice is ugly. So, my preference is a wiki. I don't care which wiki it is as long as I can edit and view it directly. Thanks. -- tejun - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] cmd64x: don't clear the other channels interrupt
On Friday 09 November 2007, Sergei Shtylyov wrote: > Make sure to not clear the other IDE channel's interrupt when clearing an IDE > interrupt via the MRDMODE register. > > Thanks to Bart for finding a coding mistake. Could you resend with "Signed-off-by:" and "Tested-by:" tags? [ A reference to the problematic commit and crediting Martin for patiently bisecting the issue would score an extra points. :) ] > --- > The patch is against the Linus tree. > > drivers/ide/pci/cmd64x.c |5 +++-- > 1 files changed, 3 insertions(+), 2 deletions(-) > > Index: linux-2.6/drivers/ide/pci/cmd64x.c > === > --- linux-2.6.orig/drivers/ide/pci/cmd64x.c > +++ linux-2.6/drivers/ide/pci/cmd64x.c > @@ -1,5 +1,5 @@ > /* > - * linux/drivers/ide/pci/cmd64x.cVersion 1.50May 10, 2007 > + * linux/drivers/ide/pci/cmd64x.cVersion 1.51Nov 8, 2007 > * > * cmd64x.c: Enable interrupts at initialization time on Ultra/PCI machines. > * Due to massive hardware bugs, UltraDMA is only supported > @@ -339,7 +339,8 @@ static int cmd648_ide_dma_end (ide_drive > u8 mrdmode = inb(hwif->dma_master + 0x01); > > /* clear the interrupt bit */ > - outb(mrdmode | irq_mask, hwif->dma_master + 0x01); > + outb((mrdmode & ~(MRDMODE_INTR_CH0 | MRDMODE_INTR_CH1)) | irq_mask, > + hwif->dma_master + 0x01); > > return err; > } > > - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.24-rc1: pata_acpi fails to activate DMA for DVD-ROM on ALi M5229 secondary channel
> BTW in rc2 it does not even boot - it babbles something about > Unable to determine IRQ for 00:04.0 (which is IDE controller) and that is > the end of story. No IDE device is found. Thats not an IDE breakage I suspect. Various people are reporting IRQ related breakage with -rc2 so you should probably report that to the main linux-kernel list Doesn't explain the ALi DMA problem but I think its unrelated Alan - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.24-rc1: pata_acpi fails to activate DMA for DVD-ROM on ALi M5229 secondary channel
On Friday 26 October 2007, Alan Cox wrote: > On Fri, 26 Oct 2007 21:30:02 +0400 > Andrey Borzenkov <[EMAIL PROTECTED]> wrote: > > > Running legacy IDE drivers apparently works in DMA mode for both: > > Thanks - can you send me an lspci -vvxxx off list > BTW in rc2 it does not even boot - it babbles something about Unable to determine IRQ for 00:04.0 (which is IDE controller) and that is the end of story. No IDE device is found. signature.asc Description: This is a digitally signed message part.
Re: [PATCH] Add quirk to set AHCI mode on ICH boards
On 11.11.2007 15:05, Thorsten Leemhuis wrote: > On 10.11.2007 00:32, Matthias Schniedermeyer wrote: > > [...] > > My computer/mainboard @work has such a "broken" BIOS. Of the 5 > > SATA-Ports this MB has only 1 (and 1 "missing" that is reported by > > linux but i can't find on the MB) is configured as AHCI [...] > > There is nothing "broken" here. You have a ICH8 (without R) that drives > four SATA ports, which are handled by ata_piix. > > Then you have a Jmicron JMB363 -- it handles the PATA-Channel and two > SATA-Ports -- one internal (near the battery)/next to the PCI-Slot and a > external eSATA port. Seems you configured it in AHCI-Mode in the > BIOS-Setup. Linux will work just fine if you connect the hard disc to > that port. But if you want to install Windows XP you need a driver from > Jmicron. > > There were BIOSes for the P5B where you could enabled AHCI for the ICH8 > as well. It seems Asus removed it in the later BIOS-versions again as > Intel doesn't provide a Windows-AHCI driver for the basic ICH8. I don't have an P5B @work, but i guess MSI cooks with water too. :-) But i have a (1 year old) P5B @home and it is exactly like you said. My main point is still the same, if Linux could force AHCI mode, i wouldn't have to switch between those modes when booting Wintendo to play some games. (And i could use AHCI @work where i can't switch it in BIOS) On a side note, with the mainboard i had before the P5B (ASUS, 925X Chipset, ICH 6 or 7) Linux worked in AHCI-mode and Wintendo worked also without problems. (IOW: I did not need to switch modes in BIOS!) Bis denn -- Real Programmers consider "what you see is what you get" to be just as bad a concept in Text Editors as it is in women. No, the Real Programmer wants a "you asked for it, you got it" text editor -- complicated, cryptic, powerful, unforgiving, dangerous. - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Hang during boot in piix_init_pcs (ata_piix.c) with macbook pro
Hello,
I am using kernel 2.6.23 with the driver drivers/ata/ata_piix.c on my macbook
pro.
About every fourth boot hangs. I tried to narrow down the problem by putting in
dome printk
statements and found (at least on 2 hangs so far) that the msleep(150) in
piix_init_pcs
does not return:
static void __devinit piix_init_pcs(struct pci_dev *pdev,
struct ata_port_info *pinfo,
const struct piix_map_db *map_db)
{
u16 pcs, new_pcs;
printk("piix_init_pcs 1");
pci_read_config_word(pdev, ICH5_PCS, &pcs);
printk("piix_init_pcs 2");
new_pcs = pcs | map_db->port_enable;
if (new_pcs != pcs) {
printk("updating PCS from 0x%x to 0x%x\n", pcs, new_pcs);
DPRINTK("updating PCS from 0x%x to 0x%x\n", pcs, new_pcs);
pci_write_config_word(pdev, ICH5_PCS, new_pcs);
printk("updating PCS done");
msleep(150);
printk("updating PCS done wait");
}
}
The "updating PCS done" is printed but the "updateing PCS done wait" is not
printed.
The following is part of the dmesg output of a working boot. The hang always
happens with
the SATA controller (i.e. :00:1f.2):
ata_piix :00:1f.1: version 2.12
ata_pci_init_one d
ata_pci_init_one e
ata_pci_init_one f
piix_init_one before ret
ata_pci_init_one a
ACPI: PCI Interrupt :00:1f.1[A] -> GSI 21 (level, low) -> IRQ 18
ata_pci_init_one b
ata_pci_init_one c
PCI: Setting latency timer of device :00:1f.1 to 64
ata_pci_init_one d
ata_pci_init_one e
scsi0 : ata_piix
scsi1 : ata_piix
ata1: PATA max UDMA/100 cmd 0x000101f0 ctl 0x000103f6 bmdma 0x000160e0 irq 14
ata2: PATA max UDMA/100 cmd 0x00010170 ctl 0x00010376 bmdma 0x000160e8 irq 15
ata1.00: ATAPI: HL-DT-ST DVDRW GSA-S10N, AP09, max UDMA/33
ata1.00: configured for UDMA/33
Clocksource tsc unstable (delta = -497173580 ns)
scsi 0:0:0:0: CD-ROMHL-DT-ST DVDRW GSA-S10N AP09 PQ: 0 ANSI: 5
ata_pci_init_one done
piix_init_one a
ata_piix :00:1f.2: MAP [ P0 P2 P1 P3 ]
piix_init_one b
piix_init_pcs 1piix_init_pcs 2updating PCS from 0x8101 to 0x8103
updating PCS doneupdating PCS done waitpiix_init_one c
ata_pci_init_one d
ata_pci_init_one e
ata_pci_init_one f
piix_init_one before ret
ata_pci_init_one a
ACPI: PCI Interrupt :00:1f.2[B] -> GSI 18 (level, low) -> IRQ 19
ata_pci_init_one b
ata_pci_init_one c
PCI: Setting latency timer of device :00:1f.2 to 64
ata_pci_init_one d
ata_pci_init_one e
scsi2 : ata_piix
scsi3 : ata_piix
ata3: SATA max UDMA/133 cmd 0x000160f8 ctl 0x00016116 bmdma 0x00016020 irq 19
ata4: SATA max UDMA/133 cmd 0x000160f0 ctl 0x00016112 bmdma 0x00016028 irq 19
ata3.00: ATA-8: FUJITSU MHW2120BH, 00810013, max UDMA/100
ata3.00: 234441648 sectors, multi 16: LBA48 NCQ (depth 0/32)
ata3.00: configured for UDMA/100
scsi 2:0:0:0: Direct-Access ATA FUJITSU MHW2120B 0081 PQ: 0 ANSI: 5
sd 2:0:0:0: [sda] 234441648 512-byte hardware sectors (120034 MB)
sd 2:0:0:0: [sda] Write Protect is off
sd 2:0:0:0: [sda] Mode Sense: 00 3a 00 00
sd 2:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support
DPO or FUA
sd 2:0:0:0: [sda] 234441648 512-byte hardware sectors (120034 MB)
sd 2:0:0:0: [sda] Write Protect is off
sd 2:0:0:0: [sda] Mode Sense: 00 3a 00 00
sd 2:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support
DPO or FUA
lspci -n for the devices is:
00:1f.1 0101: 8086:2850 (rev 03)
00:1f.2 0101: 8086:2828 (rev 03)
My next try would be to put in a custom version ich8_map_db with port_enable=1
(and possibly {P0, P2, NA, NA} in the first line of .map) and use this map
for pci id 8086:2828, because I think the notebook has only one sata port
anyway.
Is this the correct way to approach the matter?
Please carbon copy me when answering, as I am not subscribed to the list.
Sincerely,
Thomas Rohwer
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: linux-ata.org contributions
On Sat, 2007-11-10 at 18:06 -0500, Jeff Garzik wrote: > Alan Cox wrote: > > On Sat, 10 Nov 2007 17:11:39 -0500 > > Jeff Garzik <[EMAIL PROTECTED]> wrote: > > > >> Jeff Garzik wrote: > >>> Whenever you want to update or add a page, just send a 'git pull' > >>> request to me... > >> > >> Or patches, if you wish to avoid git. > > > > Bad idea IMHO > > > > You ask Jeff to pull some updates, they go wrong, the website looks a > > mess, Jeff goes to the pub. > > > > There's an immediacy about the display of web content that often benefits > > from an immediacy of updates/fixing. The web just isn't batch processed. > > I wouldn't push it out unless it looked OK in my browser. > > But overall I tend to dislike wikis. They enable collaboration, but > tend to be uniformly ugly, cumbersome, and CPU intensive. What about ikiwiki? It's a wiki backed by an RCS, which can be git. http://ikiwiki.info/ and http://ikiwiki.info/rcs/git/ James Andrewartha - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Add quirk to set AHCI mode on ICH boards
On 10.11.2007 00:32, Matthias Schniedermeyer wrote: > [...] > My computer/mainboard @work has such a "broken" BIOS. Of the 5 > SATA-Ports this MB has only 1 (and 1 "missing" that is reported by > linux but i can't find on the MB) is configured as AHCI [...] There is nothing "broken" here. You have a ICH8 (without R) that drives four SATA ports, which are handled by ata_piix. Then you have a Jmicron JMB363 -- it handles the PATA-Channel and two SATA-Ports -- one internal (near the battery)/next to the PCI-Slot and a external eSATA port. Seems you configured it in AHCI-Mode in the BIOS-Setup. Linux will work just fine if you connect the hard disc to that port. But if you want to install Windows XP you need a driver from Jmicron. There were BIOSes for the P5B where you could enabled AHCI for the ICH8 as well. It seems Asus removed it in the later BIOS-versions again as Intel doesn't provide a Windows-AHCI driver for the basic ICH8. HTH and clarifies some of your problems. Cu knurd -- Thorsten Leemhuis c't- Magazin für Computertechnik webhttp://www.heise.de/ct/ Heise Zeitschriften Verlag GmbH&Co.KG phone +49 (0)511 5352 666 Helstorfer Str. 7 icq140593172 D-30625 Hannover, Germany jabber [EMAIL PROTECTED] /* Heise Zeitschriften Verlag GmbH & Co. KG, Registergericht: Amtsgericht Hannover HRA 26709; Persönlich haftende Gesellschafterin: Heise Zeitschriften Verlag Geschäftsführung GmbH, Registergericht: Amtsgericht Hannover, HRB 60405 Geschäftsführer: Ansgar Heise, Steven P. Steinkraus, Dr. Alfons Schräder */ - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Tejun collecting libata patches this week
I'm about to disappear (virtually) through Friday for vacation. Tejun Heo has agreed to collect libata bug fix patches in my absence. Thanks! Jeff - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[2.6 patch] libata: remove unused functions
This patch removes the following obsolete functions:
- libata-core.c: __sata_phy_reset()
- libata-core.c: sata_phy_reset()
- libata-eh.c: ata_qc_timeout()
- libata-eh.c: ata_eng_timeout()
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
drivers/ata/libata-core.c | 78 ---
drivers/ata/libata-eh.c | 95 --
include/linux/libata.h|4 -
3 files changed, 177 deletions(-)
7e9868b7e921f3235d044c78f28da8797cc63e5a
diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index 8189803..1584164 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -2581,81 +2581,6 @@ void sata_print_link_status(struct ata_link *link)
}
/**
- * __sata_phy_reset - Wake/reset a low-level SATA PHY
- * @ap: SATA port associated with target SATA PHY.
- *
- * This function issues commands to standard SATA Sxxx
- * PHY registers, to wake up the phy (and device), and
- * clear any reset condition.
- *
- * LOCKING:
- * PCI/etc. bus probe sem.
- *
- */
-void __sata_phy_reset(struct ata_port *ap)
-{
- struct ata_link *link = &ap->link;
- unsigned long timeout = jiffies + (HZ * 5);
- u32 sstatus;
-
- if (ap->flags & ATA_FLAG_SATA_RESET) {
- /* issue phy wake/reset */
- sata_scr_write_flush(link, SCR_CONTROL, 0x301);
- /* Couldn't find anything in SATA I/II specs, but
-* AHCI-1.1 10.4.2 says at least 1 ms. */
- mdelay(1);
- }
- /* phy wake/clear reset */
- sata_scr_write_flush(link, SCR_CONTROL, 0x300);
-
- /* wait for phy to become ready, if necessary */
- do {
- msleep(200);
- sata_scr_read(link, SCR_STATUS, &sstatus);
- if ((sstatus & 0xf) != 1)
- break;
- } while (time_before(jiffies, timeout));
-
- /* print link status */
- sata_print_link_status(link);
-
- /* TODO: phy layer with polling, timeouts, etc. */
- if (!ata_link_offline(link))
- ata_port_probe(ap);
- else
- ata_port_disable(ap);
-
- if (ap->flags & ATA_FLAG_DISABLED)
- return;
-
- if (ata_busy_sleep(ap, ATA_TMOUT_BOOT_QUICK, ATA_TMOUT_BOOT)) {
- ata_port_disable(ap);
- return;
- }
-
- ap->cbl = ATA_CBL_SATA;
-}
-
-/**
- * sata_phy_reset - Reset SATA bus.
- * @ap: SATA port associated with target SATA PHY.
- *
- * This function resets the SATA bus, and then probes
- * the bus for devices.
- *
- * LOCKING:
- * PCI/etc. bus probe sem.
- *
- */
-void sata_phy_reset(struct ata_port *ap)
-{
- __sata_phy_reset(ap);
- if (ap->flags & ATA_FLAG_DISABLED)
- return;
- ata_bus_reset(ap);
-}
-
-/**
* ata_dev_pair- return other device on cable
* @adev: device
*
@@ -7653,8 +7578,6 @@ EXPORT_SYMBOL_GPL(ata_dev_disable);
EXPORT_SYMBOL_GPL(sata_set_spd);
EXPORT_SYMBOL_GPL(sata_link_debounce);
EXPORT_SYMBOL_GPL(sata_link_resume);
-EXPORT_SYMBOL_GPL(sata_phy_reset);
-EXPORT_SYMBOL_GPL(__sata_phy_reset);
EXPORT_SYMBOL_GPL(ata_bus_reset);
EXPORT_SYMBOL_GPL(ata_std_prereset);
EXPORT_SYMBOL_GPL(ata_std_softreset);
@@ -7725,7 +7648,6 @@ EXPORT_SYMBOL_GPL(ata_port_desc);
#ifdef CONFIG_PCI
EXPORT_SYMBOL_GPL(ata_port_pbar_desc);
#endif /* CONFIG_PCI */
-EXPORT_SYMBOL_GPL(ata_eng_timeout);
EXPORT_SYMBOL_GPL(ata_port_schedule_eh);
EXPORT_SYMBOL_GPL(ata_link_abort);
EXPORT_SYMBOL_GPL(ata_port_abort);
diff --git a/drivers/ata/libata-eh.c b/drivers/ata/libata-eh.c
index ed8813b..0dac69d 100644
--- a/drivers/ata/libata-eh.c
+++ b/drivers/ata/libata-eh.c
@@ -559,101 +559,6 @@ void ata_port_wait_eh(struct ata_port *ap)
}
}
-/**
- * ata_qc_timeout - Handle timeout of queued command
- * @qc: Command that timed out
- *
- * Some part of the kernel (currently, only the SCSI layer)
- * has noticed that the active command on port @ap has not
- * completed after a specified length of time. Handle this
- * condition by disabling DMA (if necessary) and completing
- * transactions, with error if necessary.
- *
- * This also handles the case of the "lost interrupt", where
- * for some reason (possibly hardware bug, possibly driver bug)
- * an interrupt was not delivered to the driver, even though the
- * transaction completed successfully.
- *
- * TODO: kill this function once old EH is gone.
- *
- * LOCKING:
- * Inherited from SCSI layer (none, can sleep)
- */
-static void ata_qc_timeout(struct ata_queued_cmd *qc)
-{
- struct ata_port *ap = qc->ap;
- u8 host_stat = 0, drv_stat;
- unsigned long flags;
-
- DPRINTK("ENTER\n");
-
- ap->hsm_task_state = HSM_ST_IDLE;
-
- spin_lock_irqsave(ap->lock, flags);
-
- switch (qc->tf.protocol) {
-
- case ATA_PROT_DMA:
-
