Red Hat Bugzilla – Bug 250019
[libata] HPA mishandling on an error recovery
Last modified: 2013-07-02 22:33:24 EDT
Description of problem: One of my systems can't be used running kernel 2.6.21 or upper, still have to use 2.6.20 Version-Release number of selected component (if applicable): Still until: kernel-2.6.22.1-33.fc7 How reproducible: Always Steps to Reproduce: 1. Boot kernel Actual results: Short after booting, following errors occur: Jul 28 15:18:47 worker kernel: ata2.01: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0 Jul 28 15:18:47 worker kernel: ata2.01: cmd e7/00:00:00:00:00/00:00:00:00:00/b0 tag 0 cdb 0x1e data 0 Jul 28 15:18:47 worker kernel: res 51/04:00:46:ff:7d/00:00:00:00:00/b0 Emask 0x1 (device error) Jul 28 15:18:47 worker kernel: ata2.01: ata_hpa_resize 1: hpa sectors (0) is smaller than sectors (16514064) Jul 28 15:18:47 worker kernel: ata2.00: configured for UDMA/33 Jul 28 15:18:47 worker kernel: ata2.01: ata_hpa_resize 1: hpa sectors (0) is smaller than sectors (16514064) Jul 28 15:18:47 worker kernel: ata2.01: configured for UDMA/33 Jul 28 15:18:47 worker kernel: ata2: EH complete > 1700 "device error" log lines in *1* second. Expected results: Working like on other systems. Additional info: Mainboard is a A7N8X-E Deluxe # lspci 00:00.0 Host bridge: nVidia Corporation nForce2 AGP (different version?) (rev c1) 00:00.1 RAM memory: nVidia Corporation nForce2 Memory Controller 1 (rev c1) 00:00.2 RAM memory: nVidia Corporation nForce2 Memory Controller 4 (rev c1) 00:00.3 RAM memory: nVidia Corporation nForce2 Memory Controller 3 (rev c1) 00:00.4 RAM memory: nVidia Corporation nForce2 Memory Controller 2 (rev c1) 00:00.5 RAM memory: nVidia Corporation nForce2 Memory Controller 5 (rev c1) 00:01.0 ISA bridge: nVidia Corporation nForce2 ISA Bridge (rev a4) 00:01.1 SMBus: nVidia Corporation nForce2 SMBus (MCP) (rev a2) 00:02.0 USB Controller: nVidia Corporation nForce2 USB Controller (rev a4) 00:02.1 USB Controller: nVidia Corporation nForce2 USB Controller (rev a4) 00:02.2 USB Controller: nVidia Corporation nForce2 USB Controller (rev a4) 00:04.0 Ethernet controller: nVidia Corporation nForce2 Ethernet Controller (rev a1) 00:05.0 Multimedia audio controller: nVidia Corporation nForce Audio Processing Unit (rev a2) 00:06.0 Multimedia audio controller: nVidia Corporation nForce2 AC97 Audio Controler (MCP) (rev a1) 00:08.0 PCI bridge: nVidia Corporation nForce2 External PCI Bridge (rev a3) 00:09.0 IDE interface: nVidia Corporation nForce2 IDE (rev a2) 00:0d.0 FireWire (IEEE 1394): nVidia Corporation nForce2 FireWire (IEEE 1394) Controller (rev a3) 00:1e.0 PCI bridge: nVidia Corporation nForce2 AGP (rev c1) 01:04.0 Ethernet controller: Marvell Technology Group Ltd. 88E8001 Gigabit Ethernet Controller (rev 13) 01:0b.0 RAID bus controller: Silicon Image, Inc. SiI 3112 [SATALink/SATARaid] Serial ATA Controller (rev 02) 03:00.0 VGA compatible controller: Matrox Graphics, Inc. MGA G400/G450 (rev 05) # lsmod |grep sata sata_sil 15689 1 sata_nv 22469 0 libata 104661 2 sata_sil,sata_nv
Happpen also on kernel-2.6.22.1-41.fc7 Probably the lsmod-grep was done on 2.6.20, here the 2.6.22 output: # lsmod |grep ata sata_sil 14921 1 ata_generic 11589 0 pata_amd 16581 7 libata 119985 3 sata_sil,ata_generic,pata_amd scsi_mod 140621 7 sr_mod,sg,sym53c8xx,aic7xxx,scsi_transport_spi,libata,sd_mod Probably problem is located in the pata_amd driver, because on this the 8 GB HDD is connected.
What does 'hdparm -i /dev/sdX' say about the disk? (The messages above don't say which sd it is.)
# hdparm -i /dev/sda /dev/sda: Model=IBM-DJNA-351520 , FwRev=J56OA30K, SerialNo= G80GLT3C373 Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs } RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=34 BuffType=DualPortCache, BuffSize=430kB, MaxMultSect=16, MultSect=?16? CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=30033360 IORDY=on/off, tPIO={min:240,w/IORDY:120}, tDMA={min:120,rec:120} PIO modes: pio0 pio1 pio2 pio3 pio4 DMA modes: mdma0 mdma1 mdma2 UDMA modes: udma0 udma1 *udma2 udma3 udma4 udma3 udma4 AdvancedPM=no WriteCache=enabled Drive conforms to: ATA/ATAPI-4 T13 1153D revision 17: ATA/ATAPI-1 ATA/ATAPI-2 ATA/ATAPI-3 ATA/ATAPI-4 * signifies the current active mode
A short test shows that the same problem occurs with 2.6.23-0.61.rc1.git9.fc8 from development.
Same happen on kernel 2.6.22.2-52.fc7 and 2.6.23-0.104.rc3.f8
There is some upstream core libata work going on here to deal with drives that give bogus responses and revalidation bugs. Tejun's latest should have fixed this one I hope
Looks like kernel-2.6.23-1.fc7 from updates-testing fixes this problem.
Forget my last comment, it was a false positive. While system behavior improves since 2.6.22, error messages are still logged all the time also in this 2.6.23 release :-(
I get the same error after changing the mainboard but keeping the drives: IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06)
Should be able to work around it with libata paramater ignore_hpa=1 But you have to get this into the initrd, by editing modprobe.conf and rebuilding the initrd.
Sorry, but hint in https://bugzilla.redhat.com/show_bug.cgi?id=250019#c10 won't work. I've checked "init" from initrd and found insmod /lib/libata.ko ignore_hpa=1 But this won't help. Any other hints?
Based on the date this bug was created, it appears to have been reported during the development of Fedora 8. In order to refocus our efforts as a project we are changing the version of this bug to '8'. If this bug still exists in rawhide, please change the version back to rawhide. (If you're unable to change the bug's version, add a comment to the bug and someone will change it for you.) Thanks for your help and we apologize for the interruption. The process we're following is outlined here: http://fedoraproject.org/wiki/BugZappers/F9CleanUp We will be following the process here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this doesn't happen again.
This message is a reminder that Fedora 8 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 8. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '8'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 8's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 8 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 8 changed to end-of-life (EOL) status on 2009-01-07. Fedora 8 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.