Re: Kernel Bug in ATA or SMART area

[Axel Uhl]

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