Disk errors reported on boot - kernel 2.6.18
Hello I received a message from Andrey Melnikoff. I tried to answer him but the remote host keeps rejecting the message because he is "backlisted". <[EMAIL PROTECTED]>: 217.13.212.5 does not like recipient. Remote host said: 553 5.3.0 <[EMAIL PROTECTED]>... Too many spam messages. Blacklisted. 2004/03/17 Giving up on 217.13.212.5. I am sending this for his information. Thank you! - 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/2] 2.6.22-rc5: known regressions
Hi all, Here is a list of some known regressions in 2.6.22-rc5. Feel free to add new regressions/remove fixed etc. http://kernelnewbies.org/known_regressions SATA/PATA Subject: libata IT821X driver still fails! Hard-freezes system References : http://lkml.org/lkml/2007/6/14/82 Submitter : Rodney Gordon II <[EMAIL PROTECTED]> Status : unknown Sparc64 Subject: random invalid instruction occourances on sparc32 (sun4c) References : http://lkml.org/lkml/2007/6/17/111 Submitter : Mark Fortescue <[EMAIL PROTECTED]> Status : problem is being debugged Subject: 2.6.22-rc broke X on Ultra5 References : http://lkml.org/lkml/2007/5/22/78 Submitter : Mikael Pettersson <[EMAIL PROTECTED]> Handled-By : David Miller <[EMAIL PROTECTED]> Status : problem is being debugged x86-64 Subject: x86-64 2.6.22-rc2 random segfaults References : http://lkml.org/lkml/2007/5/24/275 Submitter : Ioan Ionita <[EMAIL PROTECTED]> Status : Unknown Regards, Michal -- LOG http://www.stardust.webpages.pl/log/ - 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 1/5] ide: add short cables support
Hello.
Bartlomiej Zolnierkiewicz wrote:
This patch allows users to override both host and device side cable detection
with "ideX=ata66" kernel parameter. Thanks to this it should be now possible
to use UDMA > 2 modes on systems (laptops mainly) which use short 40-pin cable
instead of 80-pin one.
Next patches add automatic detection of some systems using short cables.
Changes:
* Rename hwif->udma_four to hwif->cbl and make it u8.
Not sure if already short word "cable" was worth further shortening. :-)
The name/usage is the same as in libata.
When we add ->cable_detect method it will make grepping easier. 8)
Hm... :-)
Index: b/drivers/ide/pci/alim15x3.c
===
--- a/drivers/ide/pci/alim15x3.c
+++ b/drivers/ide/pci/alim15x3.c
@@ -594,7 +594,7 @@ out:
* FIXME: frobs bits that are not defined on newer ALi devicea
*/
-static unsigned int __devinit ata66_ali15x3 (ide_hwif_t *hwif)
+static u8 __devinit ata66_ali15x3(ide_hwif_t *hwif)
{
struct pci_dev *dev = hwif->pci_dev;
unsigned int ata66 = 0;
@@ -657,7 +657,7 @@ static unsigned int __devinit ata66_ali1
local_irq_restore(flags);
- return(ata66);
+ return ata66 ? ATA_CBL_PATA80 : ATA_CBL_PATA40;
Ahem... I'd think it was about the right time to fix the abomination which
those ata66 and cable_80_pin[2] are, something like this:
static unsigned int __devinit ata66_ali15x3 (ide_hwif_t *hwif)
{
struct pci_dev *dev = hwif->pci_dev;
unsigned int cbl= ATA_CBL_PATA40;
unsigned long flags;
u8 tmpbyte, mask= hwif->channel ? 0x02 : 0x01;
local_irq_save(flags); /* Not sure if it's necessary... */
if (m5229_revision >= 0xC2) {
/*
* Ultra66 cable detection (from Host View)
* m5229, 0x4a, bit0: primary, bit1: secondary
* 0: 80 pin, 1: 40 pin
*/
pci_read_config_byte(dev, 0x4a, &tmpbyte);
/*
* Allow ata66 if cable of current channel has 80 pins
*/
cbl = (tmpbyte & mask) ? ATA_CBL_PATA40 : ATA_CBL_PATA80;
} else {
[Following code frankly speaking has no business being in this function]
patch #3/5 already takes care of cable_80_pin[2] part,
I really should have looked thru all the series but lacked the time. :-<
ata66 part was left as an exercise for the reader ;-)
Hm, now that I've looked at that patch I saw both these things killed.
What, you don't know your own code? ;-)
local_irq_restore(flags); /* Not sure if it's necessary... */
return cbl;
}
/**
Index: b/drivers/ide/pci/serverworks.c
===
--- a/drivers/ide/pci/serverworks.c
+++ b/drivers/ide/pci/serverworks.c
@@ -329,9 +329,9 @@ static unsigned int __devinit init_chips
return dev->irq;
}
-static unsigned int __devinit ata66_svwks_svwks (ide_hwif_t *hwif)
+static u8 __devinit ata66_svwks_svwks(ide_hwif_t *hwif)
{
- return 1;
+ return ATA_CBL_PATA80;
}
Hm, worth folding into ata66_svwks()...
Yes and no...
Alan did a very nice rewrite of cable detection code for pata_serverworks.c
driver. We may be better off just back-porting it (patches are welcomed).
Thanks, no. I still have much to do. :-)
Index: b/drivers/ide/pci/sis5513.c
===
--- a/drivers/ide/pci/sis5513.c
+++ b/drivers/ide/pci/sis5513.c
@@ -796,7 +796,7 @@ static unsigned int __devinit init_chips
return 0;
}
-static unsigned int __devinit ata66_sis5513 (ide_hwif_t *hwif)
+static u8 __devinit ata66_sis5513(ide_hwif_t *hwif)
{
u8 ata66 = 0;
@@ -811,7 +811,8 @@ static unsigned int __devinit ata66_sis5
pci_read_config_byte(hwif->pci_dev, 0x48, ®48h);
ata66 = (reg48h & mask) ? 0 : 1;
}
-return ata66;
+
+ return ata66 ? ATA_CBL_PATA80 : ATA_CBL_PATA40;
}
That doesn't look good as well. I think we should part with 'ata66'
variable here completely...
Could be fixed in the follow-up patch as we should also split ata66_sis5513()
into two separate functions (one for chipset_family >= ATA_133 and one for
chipset_family >= ATA_66).
That's only worth doing if you actually intend to introduce cable_detect()
method...
Thanks,
Bart
MBR, Sergei
-
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 new ICH9M pci id (8086:2850) to ata_piix id list
Hi,
Maurizio Monge pisze:
To make ata_piix recognize my ich9m chip i had to apply the
modification that follows.
Best regards
Maurizio Monge
diff -Nurb old/drivers/ata/ata_piix.c new/drivers/ata/ata_piix.c
--- old/drivers/ata/ata_piix.c 2007-06-17 23:06:12.0 +0200
+++ new/drivers/ata/ata_piix.c 2007-06-17 23:15:57.0 +0200
@@ -243,6 +243,8 @@
{ 0x8086, 0x292d, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich8_sata_ahci },
/* SATA Controller IDE (ICH9M) */
{ 0x8086, 0x292e, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich8_sata_ahci },
+ /* Mobile SATA Controller IDE (ICH9M) */
+ { 0x8086, 0x2850, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich8_sata_ahci },
http://pci-ids.ucw.cz/iii/?i=80862850
Is this really a SATA controller?
((ICH8M/ICH8M-E) IDE Controller)
Regards,
Michal
--
LOG
http://www.stardust.webpages.pl/log/
-
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
sata_promise: preliminary hotplug support
This crude but simple patch enables hotplugging of SATA
disks in the sata_promise driver. Tested successfully on
SATAII150 TX2plus, SATA300 TX2plus, and SATA300 TX4.
The TX4 is significant because of the port_nr-to-ata_nr
remapping that occurs for those chips, which affects
the hotplug status change check for a given port.
While this patch works for me, I consider it preliminary
because it duplicates code and open-codes stuff, so some
cleanups are certainly needed. Also I haven't been able
to test it on first-generation chips yet.
The hotplug checks are high up in the interrupt handling
path, not deep down in error_intr as in ahci/sata_sil24.
That's because the chip doesn't signal hotplug status changes
in the per-port status register: instead a global register
contains hotplug control and status flags for all ports.
I considered following the ahci/sata_sil24 structure, but
that would have required non-trivial changes to the interrupt
handling path, so I chose to keep the hotplug changes simple
and unobtrusive.
/Mikael
(not a formal patch submission, hence no signed-off line)
--- linux-2.6.22-rc5/drivers/ata/sata_promise.c.~1~ 2007-06-17
22:03:46.0 +0200
+++ linux-2.6.22-rc5/drivers/ata/sata_promise.c 2007-06-17 23:43:51.0
+0200
@@ -709,6 +709,9 @@
unsigned int i, tmp;
unsigned int handled = 0;
void __iomem *mmio_base;
+ unsigned int hotplug_offset;
+ u32 hotplug_status;
+ int is_sataii_tx4;
VPRINTK("ENTER\n");
@@ -719,10 +722,22 @@
mmio_base = host->iomap[PDC_MMIO_BAR];
+ /* read and clear hotplug flags for all ports */
+ if (host->ports[0]->flags & PDC_FLAG_GEN_II)
+ hotplug_offset = PDC2_SATA_PLUG_CSR;
+ else
+ hotplug_offset = PDC_SATA_PLUG_CSR;
+ hotplug_status = readl(mmio_base + hotplug_offset);
+ if (hotplug_status & 0xff) {
+ writel(hotplug_status | 0xff, mmio_base + hotplug_offset);
+ printk("%s: hotplug_status %#x\n", __FUNCTION__,
hotplug_status);
+ }
+ hotplug_status &= 0xff; /* clear uninteresting bits */
+
/* reading should also clear interrupts */
mask = readl(mmio_base + PDC_INT_SEQMASK);
- if (mask == 0x) {
+ if (mask == 0x && hotplug_status == 0) {
VPRINTK("QUICK EXIT 2\n");
return IRQ_NONE;
}
@@ -730,16 +745,39 @@
spin_lock(&host->lock);
mask &= 0x; /* only 16 tags possible */
- if (!mask) {
+ if (!mask && hotplug_status == 0) {
VPRINTK("QUICK EXIT 3\n");
goto done_irq;
}
writel(mask, mmio_base + PDC_INT_SEQMASK);
+ /* XXX: ugly ugly ugly */
+ is_sataii_tx4 = 0;
+ if ((host->ports[0]->flags & (PDC_FLAG_GEN_II|PDC_FLAG_4_PORTS)) ==
+ (PDC_FLAG_GEN_II|PDC_FLAG_4_PORTS))
+ is_sataii_tx4 = 1;
+
for (i = 0; i < host->n_ports; i++) {
VPRINTK("port %u\n", i);
ap = host->ports[i];
+ {
+ static const unsigned char sataii_tx4_port_remap[4] = {
3, 1, 0, 2};
+ int ata_nr = i;
+
+ if (is_sataii_tx4)
+ ata_nr = sataii_tx4_port_remap[i];
+
+ if ((hotplug_status & (0x11 << ata_nr)) && ap &&
+ !(ap->flags & ATA_FLAG_DISABLED)) {
+ struct ata_eh_info *ehi = &ap->eh_info;
+ ata_ehi_clear_desc(ehi);
+ ata_ehi_hotplugged(ehi);
+ ata_ehi_push_desc(ehi, "hotplug_status %#x",
hotplug_status);
+ ata_port_freeze(ap);
+ continue;
+ }
+ }
tmp = mask & (1 << (i + 1));
if (tmp && ap &&
!(ap->flags & ATA_FLAG_DISABLED)) {
@@ -897,9 +935,9 @@
tmp = readl(mmio + hotplug_offset);
writel(tmp | 0xff, mmio + hotplug_offset);
- /* mask plug/unplug ints */
+ /* unmask plug/unplug ints */
tmp = readl(mmio + hotplug_offset);
- writel(tmp | 0xff, mmio + hotplug_offset);
+ writel(tmp & ~0xff, mmio + hotplug_offset);
/* don't initialise TBG or SLEW on 2nd generation chips */
if (is_gen2)
-
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
Fwd: [PATCH] [libata] Add irq_flags to struct pata_platform_info
Any comments for this patch?
Thank you.
Sonic Zhang
-- Forwarded message --
From: Sonic Zhang <[EMAIL PROTECTED]>
Date: Jun 15, 2007 5:45 PM
Subject: [PATCH] [libata] Add irq_flags to struct pata_platform_info
To: Linux IDE
Cc: Jeff Garzik <[EMAIL PROTECTED]>
On some embedded platforms, such as blackfin, the gpio interrupt for
IDE interface is designed to be triggered with high voltage. The gpio
port should be configured properly by set_irq_type() when register
the irq. This patch enable the generic pata platform driver to
accept platform irq flags data.
Signed-off-by: Sonic Zhang <[EMAIL PROTECTED]>
---
drivers/ata/pata_platform.c |6 --
include/linux/pata_platform.h |5 +
2 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/ata/pata_platform.c b/drivers/ata/pata_platform.c
index cbb7866..79f841b 100644
--- a/drivers/ata/pata_platform.c
+++ b/drivers/ata/pata_platform.c
@@ -139,6 +139,7 @@ static int __devinit pata_platform_probe(struct
platform_device *pdev)
struct resource *io_res, *ctl_res;
struct ata_host *host;
struct ata_port *ap;
+ struct pata_platform_info *pp_info;
unsigned int mmio;
/*
@@ -208,11 +209,12 @@ static int __devinit pata_platform_probe(struct
platform_device *pdev)
ap->ioaddr.altstatus_addr = ap->ioaddr.ctl_addr;
- pata_platform_setup_port(&ap->ioaddr, pdev->dev.platform_data);
+ pp_info = (struct pata_platform_info *)(pdev->dev.platform_data);
+ pata_platform_setup_port(&ap->ioaddr, pp_info);
/* activate */
return ata_host_activate(host, platform_get_irq(pdev, 0), ata_interrupt,
-0, &pata_platform_sht);
+pp_info->irq_flags, &pata_platform_sht);
}
/**
diff --git a/include/linux/pata_platform.h b/include/linux/pata_platform.h
index 2d5fd64..5799e8d 100644
--- a/include/linux/pata_platform.h
+++ b/include/linux/pata_platform.h
@@ -8,6 +8,11 @@ struct pata_platform_info {
* spacing used by ata_std_ports().
*/
unsigned int ioport_shift;
+ /*
+* Indicate platform specific irq types and initial
+* IRQ flags when call request_irq()
+*/
+ unsigned int irq_flags;
};
#endif /* __LINUX_PATA_PLATFORM_H */
--
1.5.1.3
-
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
-
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: libata interface fatal error
Hello, Florian Effenberger wrote: > What power supply would you recommend for this type of disks? I think we > got a 450W Enermax, IIRC. Most power supplies should be able to do 4 disks without any problem unless it's broken. > What do you mean by "merged speed down fix"? Is your fix for the speed > down logic implemented in the current kernel, so I don't have to patch > anymore (except when I want to force 1.5Gbps right from the beginning)? Yeap, kernel will automatically downgrade to 1.5Gbps after several failures. -- 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: libata interface fatal error
Hello, Florian Effenberger wrote: > we tested out two 600W Fortron PSUs, also tried a BIOS update. Didn't > work out. I see. > We also tried the jumper on the disks labelled SSP (Spread Spectrum > Clocking), didn't work out out as well. > > What seemed to help at least a little bit is to use the 12V connector on > the board, that is normally dedicated for graphic cards. Hm > The best test to reproduce the problem, according to a colleague also > working on the machine, is a cat /dev/zero > zero.bin > > Do you still think it is a PSU or hardware problem? Do you need more > details/logs? The controller being ich8, I'm pretty sure it isn't a driver problem. Do the errors occur on all four drives? Also, if things work after speed is downgraded to 1.5Gbps, it doesn't really matter. There's no noticeable performance difference for single disk anyway. -- 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] Add new ICH9M pci id (8086:2850) to ata_piix id list
Well, you are probably right, it is probably just an ide controller, i
have an acer laptop (tm5720) and to make work the hd the driver ahci
was required, and my patch made work the dvd-rw too.
If so, maybe some other delegate is better for this controller than
"ich8_sata_ahci", but please consider that i am very ignorant about
this driver and i simply posted this patch beacuse it made work my
device.
If there is any test that i can do to sort out this just let me know.
On 6/17/07, Michal Piotrowski <[EMAIL PROTECTED]> wrote:
Hi,
Maurizio Monge pisze:
> To make ata_piix recognize my ich9m chip i had to apply the
> modification that follows.
>
> Best regards
> Maurizio Monge
>
>
> diff -Nurb old/drivers/ata/ata_piix.c new/drivers/ata/ata_piix.c
> --- old/drivers/ata/ata_piix.c 2007-06-17 23:06:12.0 +0200
> +++ new/drivers/ata/ata_piix.c 2007-06-17 23:15:57.0 +0200
> @@ -243,6 +243,8 @@
>{ 0x8086, 0x292d, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich8_sata_ahci },
>/* SATA Controller IDE (ICH9M) */
>{ 0x8086, 0x292e, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich8_sata_ahci },
> + /* Mobile SATA Controller IDE (ICH9M) */
> + { 0x8086, 0x2850, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich8_sata_ahci },
http://pci-ids.ucw.cz/iii/?i=80862850
Is this really a SATA controller?
((ICH8M/ICH8M-E) IDE Controller)
Regards,
Michal
--
LOG
http://www.stardust.webpages.pl/log/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
--
Ciao
Maurizio
http://stregatto.wordpress.com
"Well we all shine on
Like the moon and the stars and the sun" (John Lennon)
-
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
pata_via.c 80w cable detection problem
Hello, I tried libata driver in 2.6.22-rc5 on VIA KT133A mb. It doesn't detect the 80 wire cable (on the first port): (via82cxxx does) scsi0 : pata_via scsi1 : pata_via ata1: PATA max UDMA/100 cmd 0x000101f0 ctl 0x000103f6 bmdma 0x0001d000 irq 14 ata2: PATA max UDMA/100 cmd 0x00010170 ctl 0x00010376 bmdma 0x0001d008 irq 15 ata1.00: ata_hpa_resize 1: sectors = 156355584, hpa_sectors = 156355584 ata1.00: ATA-5: MAXTOR 6L080J4, A93.0500, max UDMA/133 ata1.00: 156355584 sectors, multi 16: LBA ata1.00: limited to UDMA/33 due to 40-wire cable ata1.00: ata_hpa_resize 1: sectors = 156355584, hpa_sectors = 156355584 ata1.00: configured for UDMA/33 ata2.00: ATAPI: HL-DT-ST DVDRAM GSA-H10N, JL10, max UDMA/33 ata2.00: configured for UDMA/33 scsi 0:0:0:0: Direct-Access ATA MAXTOR 6L080J4 A93. PQ: 0 ANSI: 5 sd 0:0:0:0: [sda] 156355584 512-byte hardware sectors (80054 MB) sd 0:0:0:0: [sda] Write Protect is off sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA sd 0:0:0:0: [sda] 156355584 512-byte hardware sectors (80054 MB) sd 0:0:0:0: [sda] Write Protect is off sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA sda: sda1 sda3 sda4 < sda5 sda6 sda7 > sd 0:0:0:0: [sda] Attached SCSI disk scsi 1:0:0:0: CD-ROMHL-DT-ST DVDRAM GSA-H10N JL10 PQ: 0 ANSI: 5 lspci -vnnxxx -s 00:07.1 00:07.1 IDE interface [0101]: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C [1106:0571] PIPC Bus Master IDE (rev 06) (prog-if 8a [Master SecP PriP]) Flags: bus master, medium devsel, latency 32 [virtual] Memory at 01f0 (32-bit, non-prefetchable) [size=8] [virtual] Memory at 03f0 (type 3, non-prefetchable) [size=1] [virtual] Memory at 0170 (32-bit, non-prefetchable) [size=8] [virtual] Memory at 0370 (type 3, non-prefetchable) [size=1] I/O ports at d000 [size=16] Capabilities: [c0] Power Management version 2 00: 06 11 71 05 07 00 90 02 06 8a 01 01 00 20 00 00 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20: 01 d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 30: 00 00 00 00 c0 00 00 00 00 00 00 00 ff 00 00 00 40: 0b 02 09 3a 1c 10 c0 00 a8 20 a8 20 77 00 20 20 50: 03 e4 03 e4 14 00 00 00 a8 a8 a8 a8 00 00 00 00 60: 00 02 00 00 00 00 00 00 00 02 00 00 00 00 00 00 70: 02 01 00 00 00 00 00 00 02 01 00 00 00 00 00 00 80: 00 00 d2 37 00 00 00 00 00 20 d2 37 00 00 00 00 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c0: 01 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00 d0: 06 00 71 05 00 00 00 00 00 00 00 00 00 00 00 00 e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 In via_cable_detect(), l. 178 pci_read_config_dword(pdev, 0x50, &ata66); reads 0xe0030303 When real 40 wire cable is used instead, it reads 0xe4030303. Petr Janecek - 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/RFC 5/9] libata: use freeze()/thaw() for polling
Hello, Albert Lee wrote: > Patch 5/9: > > This patch changes polling codes to use freeze()/thaw() for irq off/on. > ata_qc_set_polling() is also removed since now unused. > > The reason for freeze()/thaw(): some ATAPI devices raises INTRQ even if nIEN > = 1. > Using the host adapter irq mask mechanism, if available, is more reliable > than using the device nIEN bit. > > Considerations: > 1. the semantic of freeze()/thaw() maybe more than irq off/on? It usually is irq off/on. > 2. HSM, the new user of freeze()/thaw(), will call freeze()/thaw() more > frequently than EH. > Can current implemention of freeze()/thaw() handle it? Yeah, I don't see any reason why it can't be used that way but please audit each freeze/thaw implementation. > @@ -5442,7 +5442,7 @@ unsigned int ata_qc_issue_prot(struct at > > case ATA_PROT_PIO: > if (qc->tf.flags & ATA_TFLAG_POLLING) > - ata_qc_set_polling(qc); > + ap->ops->freeze(ap); > > ata_tf_to_host(ap, &qc->tf); Wouldn't ata_tf_load() change the ctl value to qc->tf.ctl when issuing the command? I'm not really sure about this change because most controller which have dedicated IRQ mask bit also have dedicated IRQ pending bit (and probably IRQ clear bit too). With those bits, IRQ during polling is not a big problem (sata_sil for example). So, the change doesn't really help the controllers which actually have problems dealing with devices which raise IRQ regardless of ATA_NIEN. I don't see any easy way out other than manipulating host IRQ on/off as IDE does. If we choose to go that way, we can use them in ata_bmdma_freeze/thaw (they should be named ata_sff_freeze/thaw really) and use this patch on top of it. Maybe it's better to drop ->freeze() and ->thaw() altogether and use ->irq_on() and ->irq_off() instead. Their names are more intuitive IMHO but that's minor. Jeff, Alan, what do you think about adopting IDE's irq off/on mechanism. It's ugly and may cause some problems if the IRQ is shared but then again it has been used for a long time without too much problem and occasional lost IRQ is much better than dead machine due to screaming IRQs followed by nobody cared. 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/RFC 7/9] libata: pdc_freeze() semantic change
Albert Lee wrote: > Patch 7/9: > > After checking the current implementations of freeze()/thaw(), it seems only > pdc_freeze() > do more than simple irq masking. Remove the DMA disable code from > pdc_freeze(). > > The question is the design/semantic of freeze()/thaw(). > Maybe we should limit them to simple irq on/off? Yeap, we can do that but if we do so it would be better to use ->irq_off/->irq_on hooks and kill ->freeze/->thaw. -- 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
[PATCH] libata: more NONCQ devices
More for the NCQ blacklist. One hitachi and one raptor. Other
members of these families of drives are already on the list, so no
surprises.
Signed-off-by: Tejun Heo <[EMAIL PROTECTED]>
---
drivers/ata/libata-core.c |2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index 047eabd..3562812 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -3802,6 +3802,8 @@ static const struct ata_blacklist_entry
ata_device_blacklist [] = {
{ "HTS541010G9SA00","MBZOC60D", ATA_HORKAGE_NONCQ, },
/* Drives which do spurious command completion */
{ "HTS541680J9SA00","SB2IC7EP", ATA_HORKAGE_NONCQ, },
+ { "HTS541612J9SA00","SBDIC7JP", ATA_HORKAGE_NONCQ, },
+ { "WDC WD740ADFD-00NLR1", NULL, ATA_HORKAGE_NONCQ, },
/* Devices with NCQ limits */
-
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: libata interface fatal error
Hi Tejun, I've been trying to find a solution for a long time for quite a similar libata errror messages as shown in this thread. Perhaps you might get have some ideas what the actual originator might be: With the latest 2.6.22-rc4-git4 kernel I still get the following error messages with high I/O load: sd 2:0:0:0: [sdc] 976773168 512-byte hardware sectors (500108 MB) sd 2:0:0:0: [sdc] Write Protect is off sd 2:0:0:0: [sdc] Mode Sense: 00 3a 00 00 sd 2:0:0:0: [sdc] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 ata3.00: (port_status 0x2008) ata3.00: cmd c8/00:08:af:91:49/00:00:00:00:00/e5 tag 0 cdb 0x0 data 4096 in res 50/00:00:b6:91:49/00:00:11:00:00/e5 Emask 0x2 (HSM violation) ata3: soft resetting port ata3: SATA link up 3.0 Gbps (SStatus 123 SControl 300) ata3.00: ata_hpa_resize 1: sectors = 976773168, hpa_sectors = 976773168 ata3.00: ata_hpa_resize 1: sectors = 976773168, hpa_sectors = 976773168 ata3.00: configured for UDMA/133 ata3: EH complete ... and later in the chain ... sd 2:0:0:0: [sdc] 976773168 512-byte hardware sectors (500108 MB) sd 2:0:0:0: [sdc] Write Protect is off sd 2:0:0:0: [sdc] Mode Sense: 00 3a 00 00 sd 2:0:0:0: [sdc] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 ata3.00: (port_status 0x2008) ata3.00: cmd c8/00:08:67:74:65/00:00:00:00:00/ec tag 0 cdb 0x0 data 4096 in res 50/00:00:6e:74:65/00:00:1b:00:00/ec Emask 0x2 (HSM violation) ata3: soft resetting port ata3: SATA link up 1.5 Gbps (SStatus 113 SControl 310) ata3.00: ata_hpa_resize 1: sectors = 976773168, hpa_sectors = 976773168 ata3.00: ata_hpa_resize 1: sectors = 976773168, hpa_sectors = 976773168 ata3.00: configured for UDMA/100 ata3: EH complete --- This goes on until UDMA/33 has been reched The problematic hardware combination is: 00:00.0 Host bridge: VIA Technologies, Inc. KT880 Host Bridge (rev 80) 00:00.1 Host bridge: VIA Technologies, Inc. KT880 Host Bridge 00:00.2 Host bridge: VIA Technologies, Inc. KT880 Host Bridge 00:00.3 Host bridge: VIA Technologies, Inc. KT880 Host Bridge 00:00.4 Host bridge: VIA Technologies, Inc. KT880 Host Bridge 00:00.7 Host bridge: VIA Technologies, Inc. KT880 Host Bridge 00:01.0 PCI bridge: VIA Technologies, Inc. VT8237 PCI Bridge 00:09.0 Ethernet controller: Marvell Technology Group Ltd. 88E8001 Gigabit Ethernet Controller (rev 13) 00:0a.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10) 00:0d.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10) 00:0e.0 Mass storage controller: Promise Technology, Inc. PDC40718 (SATA 300 TX4) (rev 02) 00:0f.0 RAID bus controller: VIA Technologies, Inc. VIA VT6420 SATA RAID Controller (rev 80) 00:0f.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06) 00:10.0 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller (rev 81) 00:10.1 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller (rev 81) 00:10.2 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller (rev 81) 00:10.3 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller (rev 81) 00:10.4 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 86) 00:11.0 ISA bridge: VIA Technologies, Inc. VT8237 ISA bridge [KT600/K8T800/K8T890 South] 00:11.5 Multimedia audio controller: VIA Technologies, Inc. VT8233/A/8235/8237 AC97 Audio Controller (rev 60) 00:11.6 Communication controller: VIA Technologies, Inc. AC'97 Modem Controller (rev 80) 01:00.0 VGA compatible controller: nVidia Corporation NV36.2 [GeForce FX 5700] (rev a1) and the problems relate only to Seagate 7200.10 SATA-disks, never with the older 7200.7 SATA-disks alll connected to Promise Sata 300TX4-controller. Because this problem has been around for as long as I've had the Promise Sata300TX4 controller an additional new problem is that after kernel version 2.6.21-rc3-git10 the libata error handling/interface speed downgrade has been fixed ---> these new seagate disks get downgraded from UDMA/133 to UDMA/33 overnight (can the speed downgrade be disabled as a quick and dirty fix in this case somehow ?). For some reason the above mentioned libata error messages don't really do any noticeable harm but it would be very nice to be able to prevent the interface speed downgrade for now. >> What do you mean by "merged speed down fix"? Is your fix for the speed >> down logic implemented in the current kernel, so I don't have to patch >> anymore (except when I want to force 1.5Gbps right from the beginning)? > > Yeap, kernel will automatically downgrade to 1.5Gbps after several > failures. Yes, this feature seems to work quite nicely as the included logs show. Regards, Tomi Orava PS. These problems are not special to this single machine as a friend at work has the same P
Re: libata interface fatal error
Hello, Yeah, it seems promise has some problem with 3G link. Cc'ing Mikael Pettersson and quoting whole body for him. Mikael, does this look familiar? Tomi Orava wrote: > Hi Tejun, > > I've been trying to find a solution for a long time for quite a similar > libata errror messages as shown in this thread. Perhaps you might get have > some ideas what the actual originator might be: > > With the latest 2.6.22-rc4-git4 kernel I still get the following error > messages > with high I/O load: > > sd 2:0:0:0: [sdc] 976773168 512-byte hardware sectors (500108 MB) > sd 2:0:0:0: [sdc] Write Protect is off > sd 2:0:0:0: [sdc] Mode Sense: 00 3a 00 00 > sd 2:0:0:0: [sdc] Write cache: enabled, read cache: enabled, doesn't > support DPO or FUA > ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 > ata3.00: (port_status 0x2008) > ata3.00: cmd c8/00:08:af:91:49/00:00:00:00:00/e5 tag 0 cdb 0x0 data 4096 in > res 50/00:00:b6:91:49/00:00:11:00:00/e5 Emask 0x2 (HSM violation) > ata3: soft resetting port > ata3: SATA link up 3.0 Gbps (SStatus 123 SControl 300) > ata3.00: ata_hpa_resize 1: sectors = 976773168, hpa_sectors = 976773168 > ata3.00: ata_hpa_resize 1: sectors = 976773168, hpa_sectors = 976773168 > ata3.00: configured for UDMA/133 > ata3: EH complete > > ... and later in the chain ... > > sd 2:0:0:0: [sdc] 976773168 512-byte hardware sectors (500108 MB) > sd 2:0:0:0: [sdc] Write Protect is off > sd 2:0:0:0: [sdc] Mode Sense: 00 3a 00 00 > sd 2:0:0:0: [sdc] Write cache: enabled, read cache: enabled, doesn't > support DPO or FUA > ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 > ata3.00: (port_status 0x2008) > ata3.00: cmd c8/00:08:67:74:65/00:00:00:00:00/ec tag 0 cdb 0x0 data 4096 in > res 50/00:00:6e:74:65/00:00:1b:00:00/ec Emask 0x2 (HSM violation) > ata3: soft resetting port > ata3: SATA link up 1.5 Gbps (SStatus 113 SControl 310) > ata3.00: ata_hpa_resize 1: sectors = 976773168, hpa_sectors = 976773168 > ata3.00: ata_hpa_resize 1: sectors = 976773168, hpa_sectors = 976773168 > ata3.00: configured for UDMA/100 > ata3: EH complete > > --- This goes on until UDMA/33 has been reched > > The problematic hardware combination is: > > 00:00.0 Host bridge: VIA Technologies, Inc. KT880 Host Bridge (rev 80) > 00:00.1 Host bridge: VIA Technologies, Inc. KT880 Host Bridge > 00:00.2 Host bridge: VIA Technologies, Inc. KT880 Host Bridge > 00:00.3 Host bridge: VIA Technologies, Inc. KT880 Host Bridge > 00:00.4 Host bridge: VIA Technologies, Inc. KT880 Host Bridge > 00:00.7 Host bridge: VIA Technologies, Inc. KT880 Host Bridge > 00:01.0 PCI bridge: VIA Technologies, Inc. VT8237 PCI Bridge > 00:09.0 Ethernet controller: Marvell Technology Group Ltd. 88E8001 Gigabit > Ethernet Controller (rev 13) > 00:0a.0 Ethernet controller: Realtek Semiconductor Co., Ltd. > RTL-8139/8139C/8139C+ (rev 10) > 00:0d.0 Ethernet controller: Realtek Semiconductor Co., Ltd. > RTL-8139/8139C/8139C+ (rev 10) > 00:0e.0 Mass storage controller: Promise Technology, Inc. PDC40718 (SATA > 300 TX4) (rev 02) > 00:0f.0 RAID bus controller: VIA Technologies, Inc. VIA VT6420 SATA RAID > Controller (rev 80) > 00:0f.1 IDE interface: VIA Technologies, Inc. > VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06) > 00:10.0 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 > Controller (rev 81) > 00:10.1 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 > Controller (rev 81) > 00:10.2 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 > Controller (rev 81) > 00:10.3 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 > Controller (rev 81) > 00:10.4 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 86) > 00:11.0 ISA bridge: VIA Technologies, Inc. VT8237 ISA bridge > [KT600/K8T800/K8T890 South] > 00:11.5 Multimedia audio controller: VIA Technologies, Inc. > VT8233/A/8235/8237 AC97 Audio Controller (rev 60) > 00:11.6 Communication controller: VIA Technologies, Inc. AC'97 Modem > Controller (rev 80) > 01:00.0 VGA compatible controller: nVidia Corporation NV36.2 [GeForce FX > 5700] (rev a1) > > and the problems relate only to Seagate 7200.10 SATA-disks, never with the > older 7200.7 SATA-disks alll connected to Promise Sata 300TX4-controller. > > Because this problem has been around for as long as I've had the Promise > Sata300TX4 controller an additional new problem is that after kernel > version 2.6.21-rc3-git10 the libata error handling/interface speed > downgrade has been fixed ---> these new seagate disks get downgraded from > UDMA/133 to UDMA/33 overnight (can the speed downgrade be disabled as a > quick and dirty fix in this case somehow ?). For some reason the above > mentioned libata error messages don't really do any noticeable harm but it > would be very nice to be able to prevent the interface speed downgrade for > now. > >>> What do you mean by "merged speed down fix"? Is your fix for the speed >>> down logic implemented in the current kernel, so I d
