Bug 250019 - [libata] HPA mishandling on an error recovery
[libata] HPA mishandling on an error recovery
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
All Linux
low Severity high
: ---
: ---
Assigned To: Jeff Garzik
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2007-07-29 11:56 EDT by Peter Bieringer
Modified: 2013-07-02 22:33 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-01-08 23:49:25 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Peter Bieringer 2007-07-29 11:56:46 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:

How reproducible:

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
Comment 1 Peter Bieringer 2007-08-02 14:59:07 EDT
Happpen also on kernel-

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

Probably problem is located in the pata_amd driver, because on this the 8 GB HDD
is connected.
Comment 2 Chuck Ebbert 2007-08-02 15:04:33 EDT
What does 'hdparm -i /dev/sdX' say about the disk?
(The messages above don't say which sd it is.)
Comment 3 Peter Bieringer 2007-08-02 15:07:33 EDT
# hdparm -i /dev/sda


 Model=IBM-DJNA-351520                         , FwRev=J56OA30K, SerialNo=     
 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

 * signifies the current active mode
Comment 4 Peter Bieringer 2007-08-02 15:28:13 EDT
A short test shows that the same problem occurs with 2.6.23-0.61.rc1.git9.fc8
from development.
Comment 5 Peter Bieringer 2007-08-15 03:37:39 EDT
Same happen on kernel and 2.6.23-0.104.rc3.f8
Comment 6 Alan Cox 2007-09-10 11:22:13 EDT
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
Comment 7 Peter Bieringer 2007-10-13 07:26:26 EDT
Looks like kernel-2.6.23-1.fc7 from updates-testing fixes this problem.
Comment 8 Peter Bieringer 2007-10-14 05:05:41 EDT
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 :-(
Comment 9 Peter Bieringer 2007-10-28 15:40:54 EDT
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)
Comment 10 Chuck Ebbert 2007-10-29 20:04:43 EDT
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.
Comment 11 Peter Bieringer 2007-10-30 15:08:40 EDT
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?
Comment 12 Bug Zapper 2008-04-04 09:30:00 EDT
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
(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:

We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.
Comment 13 Bug Zapper 2008-11-26 02:36:57 EST
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: 
Comment 14 Bug Zapper 2009-01-08 23:49:25 EST
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.

Note You need to log in before you can comment on or make changes to this bug.