Bug 250019 - [libata] HPA mishandling on an error recovery
Summary: [libata] HPA mishandling on an error recovery
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 8
Hardware: All
OS: Linux
low
high
Target Milestone: ---
Assignee: Jeff Garzik
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: bzcl34nup
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2007-07-29 15:56 UTC by Peter Bieringer
Modified: 2013-07-03 02:33 UTC (History)
4 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2009-01-09 04:49:25 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Peter Bieringer 2007-07-29 15:56:46 UTC
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

Comment 1 Peter Bieringer 2007-08-02 18:59:07 UTC
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.

Comment 2 Chuck Ebbert 2007-08-02 19:04:33 UTC
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 19:07:33 UTC
# 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


Comment 4 Peter Bieringer 2007-08-02 19:28:13 UTC
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 07:37:39 UTC
Same happen on kernel 2.6.22.2-52.fc7 and 2.6.23-0.104.rc3.f8

Comment 6 Alan Cox 2007-09-10 15:22:13 UTC
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 11:26:26 UTC
Looks like kernel-2.6.23-1.fc7 from updates-testing fixes this problem.

Comment 8 Peter Bieringer 2007-10-14 09:05:41 UTC
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 19:40:54 UTC
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-30 00:04:43 UTC
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 19:08:40 UTC
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 13:30:00 UTC
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.

Comment 13 Bug Zapper 2008-11-26 07:36:57 UTC
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

Comment 14 Bug Zapper 2009-01-09 04:49:25 UTC
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.