linux-kernel - Re: Kernel Bug in ATA or SMART area

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: <4B7F5C12.5080201@kernel.org>
Date:	Sat, 20 Feb 2010 12:50:42 +0900
From:	Tejun Heo <tj@...nel.org>
To:	Axel Uhl <axel.uhl@....de>
CC:	Mikael Pettersson <mikpe@...uu.se>, linux-ide@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: Kernel Bug in ATA or SMART area

Hello,

On 02/20/2010 03:53 AM, Axel Uhl wrote:
> I now enabled IO/APIC in my kernel. See attached .config. I also enabled
> pata_via but was unsure which IDE driver to disable. The kernel
> rebooted fine. The following appeared in my syslog when the smartctl
> command spinned up the disk:
> 
> Feb 19 18:57:09 homemp3 kernel: ata5.00: exception Emask 0x0 SAct 0x0
> SErr 0x0 action 0x6 frozen
> Feb 19 18:57:09 homemp3 kernel: ata5.00: failed command: SMART
> Feb 19 18:57:09 homemp3 kernel: ata5.00: cmd
> b0/da:00:00:4f:c2/00:00:00:00:00/00 tag 0
> Feb 19 18:57:09 homemp3 kernel:          res
> 40/00:01:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
> Feb 19 18:57:09 homemp3 kernel: ata5.00: status: { DRDY }
> Feb 19 18:57:09 homemp3 kernel: ata5: soft resetting link
> Feb 19 18:57:09 homemp3 kernel: ata5.00: configured for UDMA/133
> Feb 19 18:57:09 homemp3 kernel: ata5: EH complete
> 
> At least it seems that the kernel recovered better from this exception
> than before. In particular, IRQ10 didn't get disabled and so I/O
> continued to work fine. Thanks for the hint.

The SMART error isn't likely to be related to the nobody cared.
Neither is the switch to libata driver.  One possibility is that the
IRQ line is shared with yet another device which the corresponding
driver didn't take care of (there was an i2c controller raising
interrupt behind the driver's back).

> Would you consider the exception above a serious problem that should be
> taken care of somehow?

In itself, it's not dangerous at all although repeated occurrences
could be annoying.

Thanks.

-- 
tejun
--
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/