Re: Kernel Bug in ATA or SMART area

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [Linux Filesystems]     [Linux SCSI]     [Linux RAID]     [Git]     [Kernel Newbies]     [Linux Newbie]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Samba]     [Device Mapper]

  Powered by Linux