Re: Kernel Bug in ATA or SMART area

Axel Uhl <axel.uhl@xxxxxx> · Sat, 20 Feb 2010 09:46:03 +0100

Hi Mikael,

BTW, how do you know that all my PATA controllers are driven by libata? 
From the current /var/log/dmesg:

Uniform Multi-Platform E-IDE driver
via82cxxx 0000:00:0f.1: VIA vt8237a (rev 00) IDE UDMA133
via82cxxx 0000:00:0f.1: IDE controller (0x1106:0x0571 rev 0x07)
via82cxxx 0000:00:0f.1: not 100% native mode: will probe irqs later
    ide0: BM-DMA at 0xfc00-0xfc07
    ide1: BM-DMA at 0xfc08-0xfc0f
Probing IDE interface ide0...
hda: Maxtor 6L300R0, ATA DISK drive
hdb: Maxtor 6L300R0, ATA DISK drive
hda: host max PIO5 wanted PIO255(auto-tune) selected PIO4
hda: UDMA/133 mode selected
hdb: host max PIO5 wanted PIO255(auto-tune) selected PIO4
hdb: UDMA/133 mode selected
Probing IDE interface ide1...
hdc: SAMSUNG SP1614N, ATA DISK drive
hdd: Maxtor 6L300R0, ATA DISK drive
hdc: host max PIO5 wanted PIO255(auto-tune) selected PIO4
hdc: UDMA/100 mode selected
hdd: host max PIO5 wanted PIO255(auto-tune) selected PIO4
hdd: UDMA/133 mode selected
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
ide1 at 0x170-0x177,0x376 on irq 15
ide_generic: please use "probe_mask=0x3f" module parameter for probing 
all legacy ISA IDE ports
ide-gd driver 1.18
hda: max request size: 512KiB
hda: 586114704 sectors (300090 MB) w/16384KiB Cache, CHS=36483/255/63
hda: cache flushes supported
 hda: hda1
hdb: max request size: 512KiB
hdb: 586114704 sectors (300090 MB) w/16384KiB Cache, CHS=36483/255/63
hdb: cache flushes supported
 hdb: hdb1 hdb2
hdc: max request size: 512KiB
hdc: 312581808 sectors (160041 MB) w/8192KiB Cache, CHS=19457/255/63
hdc: cache flushes supported
 hdc: hdc1
hdd: max request size: 512KiB
hdd: 586114704 sectors (300090 MB) w/16384KiB Cache, CHS=36483/255/63
hdd: cache flushes supported
 hdd: hdd1
SCSI Media Changer driver v0.25
sata_promise 0000:00:0a.0: version 2.12
sata_promise 0000:00:0a.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18
scsi0 : sata_promise
scsi1 : sata_promise
scsi2 : sata_promise
scsi3 : sata_promise
ata1: SATA max UDMA/133 mmio m4096@0xfebfe000 ata 0xfebfe380 irq 18
ata2: SATA max UDMA/133 mmio m4096@0xfebfe000 ata 0xfebfe280 irq 18
ata3: SATA max UDMA/133 mmio m4096@0xfebfe000 ata 0xfebfe200 irq 18
ata4: SATA max UDMA/133 mmio m4096@0xfebfe000 ata 0xfebfe300 irq 18
sata_via 0000:00:0f.0: version 2.4
sata_via 0000:00:0f.0: PCI INT B -> GSI 21 (level, low) -> IRQ 21
sata_via 0000:00:0f.0: routed to hard irq line 10
scsi4 : sata_via
scsi5 : sata_via
ata5: SATA max UDMA/133 cmd 0xe000 ctl 0xdc00 bmdma 0xd480 irq 21
ata6: SATA max UDMA/133 cmd 0xd880 ctl 0xd800 bmdma 0xd488 irq 21

This to me looks at least as if the VIA IDE driver still recognizes the 
IDE disks.

Best,
-- Axel

Mikael Pettersson wrote:
Axel Uhl writes:
 > I now enabled IO/APIC in my kernel. See attached .config. I also enabled 
 >   pata_via but was unsure which IDE driver to disable.

That would be VIA82CXXX. But all your PATA/SATA controllers are now driven
by libata, so you can disable IDE, i.e. set CONFIG_IDE=n.

 > 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.
 > 
 > Would you consider the exception above a serious problem that should be 
 > taken care of somehow?

Apparently this disk likes to complain when issued a SMART command while spun
down, but as libata EH recovers nicely there's no real reason to worry.

--
Find Security Certificate at http://www.axel-uhl.de/cgi-bin/cacert.cgi
Attachment:
smime.p7s

Description: S/MIME Cryptographic Signature