hda - eigenartige Fehlermeldungen

[admappr]

Hallo,
ich habe auf einem älteren Rechner Etch installiert. Beim Booten (sowohl der Installations-CD als auch des finalen Etch) erhalte ich beim Starten des Kernels folgende Fehlermeldungen:

hda: max request size: 128KiB
hda: Host Protected Area detected.
current capacity is 78165360 sectors (40020 MB)
native capacity is 78165361 sectors (40020 MB)
hda: Host Protected Area disabled.
hda: 78165361 sectors (40020 MB) w/512KiB Cache, CHS=65535/16/63, UDMA(33)
hda: cache flushes not supported
hda: hda1 hda2 < hda5 hda6 hda7 hda8 >
hdc: ATAPI 40X CD-ROM drive, 128kB Cache, UDMA(33)
Uniform CD-ROM driver Revision: 3.20
hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
hda: dma_intr: error=0x10 { SectorIdNotFound }, LBAsect=78165360, sector=78165360
ide: failed opcode was: unknown
hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
hda: dma_intr: error=0x10 { SectorIdNotFound }, LBAsect=78165360, sector=78165360
ide: failed opcode was: unknown
hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
hda: dma_intr: error=0x10 { SectorIdNotFound }, LBAsect=78165360, sector=78165360
ide: failed opcode was: unknown
hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
hda: dma_intr: error=0x10 { SectorIdNotFound }, LBAsect=78165360, sector=78165360
...und so weiter

Nach einigen Wiederholungen geht der Startvorgang weiter.

Nachdem das System gestartet ist, sind soweit ich sehe alle Partitionen normal verfügbar.
Ich erkenne den Effekt obiger Fehlermeldungen nicht.

Zur Info:
finger:~# smartctl -i /dev/hda
smartctl version 5.36 [i686-pc-linux-gnu] Copyright (C) 2002-6 Bruce Allen
Home page is http://smartmontools.sourceforge.net/

=== START OF INFORMATION SECTION ===
Model Family: Seagate U Series 5 family
Device Model: ST340823A
Serial Number: 5EF015K5
Firmware Version: 3.54
User Capacity: 40,020,664,320 bytes
Device is: In smartctl database [for details use: -P show]
ATA Version is: 4
ATA Standard is: Exact ATA specification draft version not indicated
Local Time is: Sun May 11 11:17:04 2008 CEST
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

Was wollen sie mir sagen? Habe ich ein echtes Problem? Welches? Wo kann ich weitersuchen? Hinweise?
Auf einem System mit identischer Hardware kommen die gleichen Fehlermeldungen.

Für alle Hinweise dankbar
Dank und noch ein schönes sonniges Pfingswochenende
-admappr

[DynaBlaster]

Der Fehler kann relativ viele Ursachen haben - die Platten können einen physischen Schaden haben oder die IDE-Kabel könnten defekt sein. Da das Problem aber auf 2 Systemen vorkommt, ist das relativ unwahrscheinlich.

Ich hatte dieses Problem auch vor einiger Zeit und bei mir lag es am Zusammenspiel des Debian-Kernel 2.6.18 und dem IDE-Controller auf einem SiS735-Board von Elitegroup. Nachdem ich mir selbst einen aktuelleren Kernel von kernel.org kompiliert hatte, waren die Fehler plötzlich weg.
Ich kann nicht sagen, ob es nun an 2.6.18 lag und der Bug in aktuelleren Kerneln behoben wurde. Könnte auch sein, dass die manuelle Auswahl des richtigen IDE-Treibers das Problem gelöst hat.

[rendegast]

current capacity is 78165360 sectors (40020 MB)
native capacity is 78165361 sectors (40020 MB)
...
hda: 78165361 sectors (40020 MB)
...
... { SectorIdNotFound }, LBAsect=78165360, sector=78165360

der letzte Sektor der Platte?
Scheint ein Problem des LBA zu sein?





EDIT 20080513 -----------------------------
aka gms :
https://lists.linux-foundation.org/pipe ... 16578.html

[admappr]

Hallo,

erst mal: Supervielen Dank, daß Du antwortest/hilfst

current capacity is 78165360 sectors (40020 MB)
native capacity is 78165361 sectors (40020 MB)
...
hda: 78165361 sectors (40020 MB)
...
... { SectorIdNotFound }, LBAsect=78165360, sector=78165360

der letzte Sektor der Platte?
Scheint ein Problem des LBA zu sein?

...hm. das mit dem letzten Sektor ist mir auch aufgefallen.
Aber, was kann ich tun?
Augenscheinlich funktioniert alles...
unentschlossene Grüße
-admappr

[gms]

um was es bei der "Host Protected Area" geht, wird hier ganz gut erklärt: http://de.wikipedia.org/wiki/Host_Protected_Area

Das Problem liegt aber daran, daß sich diese Disk anders als üblich verhält:

/*
* Some disks report total number of sectors instead of
* maximum sector address. We list them here.
*/
static const struct drive_list_entry hpa_list[] = {
{ "ST340823A", NULL },
{ "ST320413A", NULL },
{ "ST310211A", NULL },
{ NULL, NULL }
};

In neueren Kernel wurde dieses eigenartige Verhalten schon berücksichtigt ( die obige Liste ist aus den Kernel-Sourcen von 2.6.25.1 ), im 2.6.19er und daher auch im Debian-Kernel aus Etch wird dieses Verhalten anscheinend noch nicht berücksichtigt und es kommt daher zu dem Problem mit den letztem Sektor.

Die Lösung wäre also auf einen neuern Kernel upzugraden. Ich werde noch überprüfen, ob der neueste unter Debian verfügbare Kernel schon diesen Fehler behoben hat.

edit:
Im 2.6.24er sind die beiden Disks "ST340823A" und "ST320413A" schon enthalten, du könntest dir also den Kernel aus Debian-Testing installieren

Gruß
gms

[DynaBlaster]

Sieh mal einer an. Leider habe ich den Rechner, mit dem ich die Probleme auch hatte, nicht mehr. Und ich kann mich auch nicht wirklich erinnern, ob da eine Samsung-Platte drin war - tippen würde ich eigentlich auf 'ne Maxtor. Egal, dank gms wieder was dazu gelernt

[karmon]

Hallo,

ich habe genau das selbe Problem mit einer 8 Jahre alten Maxtor-Platte (bei mir hdc), ebenfalls auf einem älteren Rechner (600'er Athlon, 8 Jahre alt).
Mein Debian Etch lief diesbezüglich immer problemlos, bis vor mehreren Wochen (mittlerweile ein paar Monate) auf einmal die im ersten posting beschriebenen Meldungen beim Hochfahren erschienen.
Da diese Platte schon seit 8 Jahren ihren Dienst tut, dachte ich, dass sie jetzt wohl verbraucht ist und erste Fehler zeigt.
Dummerweise lag die /- Partition meines Arbeits-systems auf eben dieser alten Maxtor-platte und vor ca. 2 Wochen blieb es leider nicht mehr bei diesen Meldungen, sondern das System nach diesen Meldungen stehen.
Ein anderes Debian Etch, das auf dem gleichen Rechner (aber auf einer anderen Festplatte (hda) ) installiert ist und das ursprünglich ein Klon meines Arbeits-systems auf hdc war, zeigt zwar die gleichen Fehler, ist aber nicht an die hdc-Platte gebunden, da es auf der hda-Platte installiert ist.
Seither arbeite ich notgedrungen mit dem Klon-system von der anderen Platte aus.
Auf der angeblich beschädigten Partition befinden sich noch weitere Partitionen mit Daten, auf die ich problemlosen und fehlerlosen Zugriff habe. Dennoch habe ich alles vorsorglich gespiegelt und gesichert.

Durch diesen Thread hier bin ich nun stutzig geworden, ob es tatsächlich an der Platte liegt, oder vielleicht nicht doch einen Betriebssystem-seitigen Grund hat.
Wenn es von Belang ist, dann kann ich die betreffenden logs posten, in denen die upgrades der letzten Wochen drin sind.

[cirrussc]

Hi,

Durch diesen Thread hier bin ich nun stutzig geworden, ob es tatsächlich an der Platte liegt, oder vielleicht nicht doch einen Betriebssystem-seitigen Grund hat.

Das hört sich eher nach einem Hardwarefehler an.
Auch Southbridges sind nicht von Defekten Ausgeschlossen.

[gms]

Wenn es von Belang ist, dann kann ich die betreffenden logs posten, in denen die upgrades der letzten Wochen drin sind.

ja bitte, diese Seek-Fehler können sicherlich viele verschiedene Ursachen haben.
Bei dem von "admappr" geposteten Problem, bekommt das Betriebsystem eine falsche Angabe über die Plattengröße und glaubt daher, daß hier eine "Host Protected Area" aktiviert ist und versucht diese vermeintliche HPA zu deaktivieren.
Aus den Logs ist dieser Fehler ziemlich eindeutig daran zu erkennen, daß einerseits eine "Host Protected Area" erkannt wird und andererseits der Seek Fehler in einem Bereich zwischen der gemeldeten "current capacity" und der "native capacity" weniger 1 ( der erste Sektor hat die Adresse 0), auftritt:

Code: Alles auswählen

hda: Host Protected Area detected.
current capacity is 78165360 sectors (40020 MB)
native capacity is 78165361 sectors (40020 MB)
hda: Host Protected Area disabled.
...
hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
hda: dma_intr: error=0x10 { SectorIdNotFound }, LBAsect=78165360, sector=78165360

Wenn das bei dir nicht der Fall ist, dann wäre auch die Ausgabe von "smartctl -a /dev/hdc" helfen. ( Ein eigener Thread wäre dann allerdings auch sinnvoll )

Gruß
gms

[cirrussc]

Hm mit dem Unterschied, das es bei karmon plötzlich aufgetreten ist und vorher funktionierte.
Das lässt stark auf eine defekte Festplatte schließen (so als Schnellschuss).

[admappr]

Guten Morgen,
nur nochmal, ob ich es richtig verstanden habe:

Der Kommentar:
* Some disks report total number of sectors instead of
* maximum sector address. We list them here.

Die Platte, die bei mir verbaut ist gibt also eine fehlerhafte Zahl von Sektoren an.
Der Kernel versucht offensichtlich aus irgendwelchen Gründen den letzten Sektor zu lesen. Da dieser (weil eins zu hoch) nicht gelesen werden kann, produziert er Fehler.

Was bedeutet das jetzt?
Ich konnte ganz normal (=ohne Fehlermeldungen) Partitionen anlegen. Ich kann diese ganz normal (=ohne Fehlermeldungen oder Probleme bei der Nutzung - wenigstens bisher) Partitionen mounten und nutzen.

Augenscheinlich haben diese Fehler beim Booten später keinen Effekt.
Ich würde vermutlich dann einen Effekt bemerken, wenn meine letzte Partition bis zu diesem letzten Sektor reicht und dieser -- weil z.B. Filesystem vollständig gefüllt -- geschrieben werden würde. Stimmt das so?

fragende Grüße
-admappr

[gms]

Augenscheinlich haben diese Fehler beim Booten später keinen Effekt.
Ich würde vermutlich dann einen Effekt bemerken, wenn meine letzte Partition bis zu diesem letzten Sektor reicht und dieser -- weil z.B. Filesystem vollständig gefüllt -- geschrieben werden würde. Stimmt das so?

ja, den Fehler bemerkst du nur, wenn dieser nicht vorhandene Sektor angesprochen wird, also z.B auch dann, wenn du ein Image der hda Platte, mit "dd if=/dev/hda of=hda.img" , erstellen möchtest.
Falls dieser Sektor innerhalb einer Partition iiegt, wäre es am besten wenn du diese verkleinern würdest ( poste bitte einmal die Ausgabe von "cfdisk -P s /dev/hda", "sfdisk -dump /dev/hda" oder von einem ähnlichen Kommando ).
Wenn du mit den Fehlermeldungen beim Booten leben kannst, würde so gesehen auch keine Notwendigkeit bestehen, auf einen neueren Kernel upzugraden, allerdings bin ich mir nicht sicher, ob sich diese falschen Zugriffe auf die Dauer nicht negativ auf die Festplatte auswirken können. Vermutlich nicht, aber sicher weiß ich es halt auch nicht.
Gruß
gms

[karmon]

So, das hier bekomme ich mit dem Klonsystem (auf hda), von dem aus ich zur Zeit arbeite:

Code: Alles auswählen

hdc: dma_intr: status=0x51 { DriveReady SeekComplete Error }
hdc: dma_intr: error=0x84 { DriveStatusError BadCRC }
ide: failed opcode was: unknown
hdc: dma_intr: status=0x51 { DriveReady SeekComplete Error }
hdc: dma_intr: error=0x84 { DriveStatusError BadCRC }
ide: failed opcode was: unknown
hdc: dma_intr: status=0x51 { DriveReady SeekComplete Error }
hdc: dma_intr: error=0x84 { DriveStatusError BadCRC }
ide: failed opcode was: unknown
hdc: dma_intr: status=0x51 { DriveReady SeekComplete Error }
hdc: dma_intr: error=0x84 { DriveStatusError BadCRC }
ide: failed opcode was: unknown
hdd: DMA disabled
ide1: reset: success
Attempting manual resume
kjournald starting.  Commit interval 5 seconds

Und das hier habe ich dem syslog meines alten Systems (auf hdc2) entnommen:

Code: Alles auswählen

Apr 30 18:34:23 joe kernel: hdc: dma_intr: status=0x51 { DriveReady SeekComplete Error }
Apr 30 18:34:23 joe kernel: hdc: dma_intr: error=0x40 { UncorrectableError }, LBAsect=267277, sector=267274
Apr 30 18:34:23 joe kernel: ide: failed opcode was: unknown
Apr 30 18:34:23 joe kernel: end_request: I/O error, dev hdc, sector 267274
Apr 30 18:34:23 joe kernel: Buffer I/O error on device hdc2, logical block 95837
Apr 30 18:34:23 joe kernel: hdc: dma_intr: status=0x51 { DriveReady SeekComplete Error }
Apr 30 18:34:23 joe kernel: hdc: dma_intr: error=0x40 { UncorrectableError }, LBAsect=267277, sector=267276
Apr 30 18:34:23 joe kernel: ide: failed opcode was: unknown
Apr 30 18:34:23 joe kernel: end_request: I/O error, dev hdc, sector 267276
Apr 30 18:34:23 joe kernel: Buffer I/O error on device hdc2, logical block 95838
Apr 30 18:34:23 joe kernel: hdc: dma_intr: status=0x51 { DriveReady SeekComplete Error }
Apr 30 18:34:23 joe kernel: hdc: dma_intr: error=0x40 { UncorrectableError }, LBAsect=267277, sector=267274
Apr 30 18:34:23 joe kernel: ide: failed opcode was: unknown
Apr 30 18:34:23 joe kernel: end_request: I/O error, dev hdc, sector 267274
Apr 30 18:34:23 joe kernel: Buffer I/O error on device hdc2, logical block 95837
Apr 30 18:34:23 joe kernel: hdc: dma_intr: status=0x51 { DriveReady SeekComplete Error }
Apr 30 18:34:23 joe kernel: hdc: dma_intr: error=0x40 { UncorrectableError }, LBAsect=267277, sector=267276
Apr 30 18:34:23 joe kernel: ide: failed opcode was: unknown
Apr 30 18:34:23 joe kernel: end_request: I/O error, dev hdc, sector 267276
Apr 30 18:34:23 joe kernel: Buffer I/O error on device hdc2, logical block 95838
Apr 30 18:34:23 joe kernel: hdc: dma_intr: status=0x51 { DriveReady SeekComplete Error }
Apr 30 18:34:23 joe kernel: hdc: dma_intr: error=0x40 { UncorrectableError }, LBAsect=267277, sector=267274
Apr 30 18:34:23 joe kernel: ide: failed opcode was: unknown
Apr 30 18:34:23 joe kernel: end_request: I/O error, dev hdc, sector 267274
Apr 30 18:34:23 joe kernel: Buffer I/O error on device hdc2, logical block 95837
Apr 30 18:34:23 joe kernel: hdc: dma_intr: status=0x51 { DriveReady SeekComplete Error }
Apr 30 18:34:23 joe kernel: hdc: dma_intr: error=0x40 { UncorrectableError }, LBAsect=267277, sector=267276
Apr 30 18:34:23 joe kernel: ide: failed opcode was: unknown
Apr 30 18:34:23 joe kernel: end_request: I/O error, dev hdc, sector 267276
Apr 30 18:34:23 joe kernel: Buffer I/O error on device hdc2, logical block 95838

Gegen ein Versagen der Southbridge spricht meiner Ansicht nach die Tatsache, dass ja die andere Festplatte (hda) problemlos funktioniert, und selbst die anderen Partitionen auf hdc laufen (bis jetzt) ohne Probleme.

"smartctl -a /dev/hdc" werde ich als nächstes ausführen.

[rendegast]

"Letzter Sektor, HBA"-Workaround ?

http://www.mjmwired.net/kernel/Document ... meters.txt
http://www.mjmwired.net/kernel/Document ... de/ide.txt

/proc/ide/hdx/geometry
Kann den nicht mit "hdx=cyl,head,sect" die automatische Erkennung umgangen werden?

[gms]

Gegen ein Versagen der Southbridge spricht meiner Ansicht nach die Tatsache, dass ja die andere Festplatte (hda) problemlos funktioniert, und selbst die anderen Partitionen auf hdc laufen (bis jetzt) ohne Probleme.

wenn die Fehler nur auf einer Partition auftreten, hast du dort wahrscheinlich kaputte Sektoren.
Du kannst auch einmal das Programm "badblocks" über die Partition drüber laufen lassen

Kann den nicht mit "hdx=cyl,head,sect" die automatische Erkennung umgangen werden?

ein Versuch wäre es sicherlich wert, ich glaube aber, daß die Geometrie schon korrekt vom Bios oder durch das Auto-Probing ermittelt wird und daß sich daher auch diese Angaben 1:1 damit decken würden.

Gruß
gms

[admappr]

Hallo,

wow...da hab' ich ja offenbar eine Diskussion angestoßen...cool
So wie ich es sehe, bearbeiten wir gerade zwei ähnlich gelagerte Probleme.

Falls dieser Sektor innerhalb einer Partition iiegt, wäre es am besten wenn du diese verkleinern würdest ( poste bitte einmal die Ausgabe von "cfdisk -P s /dev/hda", "sfdisk -dump /dev/hda" oder von einem ähnlichen Kommando ).

Hier also die Ausgaben:

Code: Alles auswählen

finger:~# cfdisk -P s /dev/hda
Partition Table for /dev/hda

               First       Last
 # Type       Sector      Sector   Offset    Length   Filesystem Type (ID) Flag
-- ------- ----------- ----------- ------ ----------- -------------------- ----
 1 Primary           0    20980889     63    20980890 HPFS/NTFS (07)       Boot
 2 Primary    20980890    78156224      0    57175335 Extended (05)        None
 5 Logical    20980890    21559229     63      578340 Linux swap / So (82) None
 6 Logical    21559230    33270614     63    11711385 Linux (83)           None
 7 Logical    33270615    37174409     63     3903795 Linux (83)           None
 8 Logical    37174410    78156224     63    40981815 Linux (83)           None
finger:~# sfdisk -dump /dev/hda

unrecognized format - using sectors
Warning: extended partition does not start at a cylinder boundary.
DOS and Linux will interpret the contents differently.
# partition table of /dev/hda
unit: sectors

/dev/hda1 : start=       63, size= 20980827, Id= 7, bootable
/dev/hda2 : start= 20980890, size= 57175335, Id= 5
/dev/hda3 : start=        0, size=        0, Id= 0
/dev/hda4 : start=        0, size=        0, Id= 0
/dev/hda5 : start= 20980953, size=   578277, Id=82
/dev/hda6 : start= 21559293, size= 11711322, Id=83
/dev/hda7 : start= 33270678, size=  3903732, Id=83
/dev/hda8 : start= 37174473, size= 40981752, Id=83

finger:~# fdisk -l /dev/hda

Disk /dev/hda: 40.0 GB, 40020664832 bytes
255 heads, 63 sectors/track, 4865 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

   Device Boot      Start         End      Blocks   Id  System
/dev/hda1   *           1        1306    10490413+   7  HPFS/NTFS
/dev/hda2            1307        4865    28587667+   5  Extended
/dev/hda5            1307        1342      289138+  82  Linux swap / Solaris
/dev/hda6            1343        2071     5855661   83  Linux
/dev/hda7            2072        2314     1951866   83  Linux
/dev/hda8            2315        4865    20490876   83  Linux

...Äh. Wie rechnet man jetzt die Angabe von Blocks um in welchem Sektor dieser Block liegt?

Kann sich jemand einen vernünftigen Grund ausdenken, weshalb ein Plattenhersteller das Verhalten seiner Platten 'einfach so' ändern würde???

vielen vielen Dank für eure Unterstützung
-admappr

[cirrussc]

Kann sich jemand einen vernünftigen Grund ausdenken, weshalb ein Plattenhersteller das Verhalten seiner Platten 'einfach so' ändern würde???

BUG?
Gerade Festplatten (sehr komplex) werden sicherlich nicht verschont davon.

[gms]

ja, anscheinend hat hier einer die ATA-Spezifikation nicht genau gelesen
die drei bekannten Problemfälle stammen aus dieser Serie http://www.seagate.com/support/disc/igu ... sheeta.pdf
würde mich wundern, wenn die restlichen 2 nicht auch diesen Bug hätten

Dieses Fehler macht sich aber auch nur bemerkbar, weil Linux versucht, die HPA zu deaktivieren ( ein Windows schert sich wenig darum, wahrscheinlich sogar überhaupt nicht ). Zu diesem Zweck wird die internel maximale Adresse mittels eines speziellen ATA-Kommando abgefragt, welches sonst nirgends verwendet wird.

Ich wollte auch einmal herausfinden, ab welchem Kernel diese Fehler auftreten, laut diesem Bugreport, wird schon beim 2.6.8er eine falsche "native capacity" ermittelt, ab dem 2.6.13er wird dieser letzte Sektor dann auch noch ausprobiert:

Kernels after 2.6.13-1 probe
the last sector when propably looking for partitions and the drive
fails silently and loudly after 2.6.16-2. Kernel thinks the drive shouldn't
fail...

Gruß
gms

[admappr]

Hi gms,

...Du fragtest weiter oben nach dem Output der beiden Kommandos. Kannst Du mal einen Blick drauf werfen, bitte? Glaubst Du, daß ich mit der letzten Partition in ein Problem laufen werde -- wegen des "nicht lesbaren" letzten Sektors???

Danke für Deine Unterstützung.

beste Grüße
-admappr

[gms]

aja, das hatte ich vergessen. Laut cfdisk ist der letzte von einer Partition belegte Sektor, der Sektor mit der Adresse "78156224". Der problematische Sektor "78165360" wird also von der Partitiontable nicht adressiert.
Nach einem kurzen Blick, wie das bei mir ausschaut, dürfte es auch üblich sein, daß da hinten so viel "freier Platz" übrigbleibt. Vielleicht liegen dort die ominösen Sektoren für das Remapping von kaputten Sektoren, aber das ist jetzt nur eine Vermutung.

Gruß
gms

[habakug]

Hallo!

Ein wenig anders ist das schon noch mit der HPA. Zunächst stellen wir fest ob eine HPA vorhanden ist:

Code: Alles auswählen

root@dnsmasq:~$ hdparm -N /dev/hda

/dev/hda:
 max sectors   = 312561701/312581808, HPA is enabled

hdparm hat dieses Feature seit Version 8.1, die Größe kann dann z.B. so eingestellt werden (Vorsicht Datenverlust):

Code: Alles auswählen

root@dnsmasq:~$ hdparm -N312581808 /dev/hda

Entscheidend ist jedoch der "Security Mode", unter dem die Festplatte läuft. Mit "hdparm -I /dev/hda" kann man ihn auslesen. Die Ausgabe bedeutet folgendens:

Code: Alles auswählen

SM0 = Inactive, das Feature ist ausgeschaltet, die Maximaladresse kann geändert werden
SM1 = Unlocked, ein Kennwort wurde gesetzt, die Maximaladresse kann geändert werden
SM2 = Locked, Maximaladresse eingefroren und nicht änderbar, Zustand kann nur durch Kennwort geändert werden
SM3 = Frozen, wie SM2, kann auch nicht durch Kennwort geändert werden

Neuere Kernel ( >2.6.24) versuchen die HPA abzuschalten. Ist die Platte jedoch im Modus SM3 (Frozen), kommt es zu diesen Fehlermeldungen:

Code: Alles auswählen

hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
hda: dma_intr: error=0x10 { SectorIdNotFound }, LBAsect=78165360, sector=78165360
ide: failed opcode was: unknown

Der letzte Sektor einer HPA-fähigen Festplatte enthält übrigens das BEER (Boot Engineering Extension Record), eine Art MBR für die HPA.

Gruß, habakug

http://www.t10.org/t13/project/d1321r3-ATA-ATAPI-5.pdf

[gms]

Der letzte Sektor einer HPA-fähigen Festplatte enthält übrigens das BEER (Boot Engineering Extension Record), eine Art MBR für die HPA.

danke, das erklärt warum der Kernel überhaupt versucht den letzten Sektor zu adressieren

Neuere Kernel ( >2.6.24) versuchen die HPA abzuschalten.

wenn man dem Bugreport http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=401035 glauben schenkt, wurde die HPA aber schon viel früher ( 2.6.8 ) deaktiviert und ab dem 2.6.13er wird auch dieser letzte Sektor gelesen

Gruß
gms