Patchwork Suppressing ATA errors on boot

login
register
mail settings
Submitter Tejun Heo
Date June 30, 2011, 4:39 p.m.
Message ID <20110630163940.GT3386@htj.dyndns.org>
Download mbox | patch
Permalink /patch/102783/
State Not Applicable
Delegated to: David Miller
Headers show

Comments

Tejun Heo - June 30, 2011, 4:39 p.m.
Hello,

On Thu, Jun 30, 2011 at 11:22:47AM -0400, David Shaw wrote:
> On Jun 30, 2011, at 5:49 AM, Tejun Heo wrote:
> 
> > Hello,
> > 
> > On Wed, Jun 29, 2011 at 11:07:11AM -0400, David Shaw wrote:
> >> Is there some way to tell libata that those ports shouldn't even be
> >> probed?  Alternately, is there a way to selectively prevent those
> >> messages from being logged (without affecting the logging for the
> >> rest of the boot)?  Or perhaps a third solution?
> > 
> > Can you attach the output of "lspci -nn" and full boot log?
> 
> Sure.
> 
> ata_piix 0000:00:1f.2: PCI INT C -> GSI 23 (level, low) -> IRQ 23
> ata_piix 0000:00:1f.2: MAP [ P0 P2 P1 P3 ]
> scsi0 : ata_piix
> scsi1 : ata_piix
> ata1: SATA max UDMA/133 cmd 0xe8e0 ctl 0xe8d0 bmdma 0xec00 irq 23
> ata2: SATA max UDMA/133 cmd 0xe8e8 ctl 0xe8d4 bmdma 0xec08 irq 23
> ata_piix 0000:00:1f.5: PCI INT D -> GSI 22 (level, low) -> IRQ 22
> ata_piix 0000:00:1f.5: MAP [ P0 -- P1 -- ]
> scsi2 : ata_piix
> scsi3 : ata_piix
> ata3: SATA max UDMA/133 cmd 0xe8f0 ctl 0xe8d8 bmdma 0xec20 irq 22
> ata4: SATA max UDMA/133 cmd 0xe8f8 ctl 0xe8dc bmdma 0xec28 irq 22
...
> ata2.00: failed to resume link (SControl 0)
> ata4: failed to resume link (SControl 0)
> ata4: SATA link down (SStatus 4 SControl 0)
> ata1.01: failed to resume link (SControl 0)
> ata1.01: SATA link down (SStatus 0 SControl 0)
> ata2.01: failed to resume link (SControl 0)
> ata2.00: SATA link down (SStatus 0 SControl 0)
> ata2.01: SATA link down (SStatus 0 SControl 0)

Hmmm.... I don't think there's any easy way to suppress the above
messages; however, the reason why they get printed through is because
they're marked KERN_ERR, but it isn't necessarily an error condition
and we should be fine with KERN_WARNING.

Does the following make the issue go away?

Thanks.


--
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
David Shaw - June 30, 2011, 10:01 p.m.
On Jun 30, 2011, at 12:39 PM, Tejun Heo wrote:

> Hmmm.... I don't think there's any easy way to suppress the above
> messages; however, the reason why they get printed through is because
> they're marked KERN_ERR, but it isn't necessarily an error condition
> and we should be fine with KERN_WARNING.
> 
> Does the following make the issue go away?

It does, thanks very much!

David

--
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Patch

diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index 736bee5..0044370 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -3552,7 +3552,7 @@  int sata_link_resume(struct ata_link *link, const unsigned long *params,
 	} while ((scontrol & 0xf0f) != 0x300 && --tries);
 
 	if ((scontrol & 0xf0f) != 0x300) {
-		ata_link_printk(link, KERN_ERR,
+		ata_link_printk(link, KERN_WARNING,
 				"failed to resume link (SControl %X)\n",
 				scontrol);
 		return 0;