HDIO_SET_DMA failed: Operation not permitted

[Jan 'RedBully' Seiffert]

Thomas Laubrock wrote:
[snip]
>>   
>>> [snip]
>>>  HDIO_GETGEO failed: Inappropriate ioctl for device
>>> kieken:~#
>>>
>>>     
>> [snip SeekComplete Error]
>> Anscheinend nicht ;)
>>   
> Tja hier tippe ich auf ein Problem mit dem Kernel Module allgemein.
> Kann mir jemand sagen, welches MOdule für den Intel Chipsatz ICH7 / 
> 82801G nötig ist.

auf dem alten IDE-Stack heist es einfach "piix.ko". Ungefaehr in
Benutzung seit den ersten Intel 440 BX Chipsaetzen. Ich wuerde das mal
als stable bezeichnen.

Auf dem neuen libata-Stack heist es "ata_piix.ko" und macht gleichzeitig
SATA und PATA, der hat noch die eine oder andere Macke, in 2.6.19 wurde
z.B. gefixed das er lange haengt wenn an einem Port kein Geraet
angeschlossen ist.

*les les*

Hmmmm, das ist ja das reinste Chaos...

Anscheined kennt der Chipsatz verschiedene Modi, die dann teilweise kein
DMA erlauben, dafuer abwaertskompatibel sind...

Lies dir mal
<https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=163418>
durch, besonders zum ende hin, das sind spaetere Kernelversionen.

*ratlos*

Muss man wohl etwas durchprobieren, aber im Grunde den ganzen IDE-Kram
rausschmeissen (und da saugt eben eine Distro-Initrd, ueberzeug die mal
dazu), und alles auf ata_piix umbiegen, mit noch einem Sack voll flags.
Denoch macht das eine oder andere ATAPI-Geraet trozdem zicken...

> [...]
>> ICH7: port 0x01f0 already claimed by ide0
>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> ICH7: neither IDE port enabled (BIOS)
>>
>>   
> Oh sorry falsches dmesg hochgelanden.
> http://www.schmu.net/dmesg-20070711.log

Hmmm, sieht schon besser aus, scheint aber an Grenzen des Chipsatz zu
liegen.
Hast du im Bios so einstellungmoeglichkeiten wie "IDE-Mode combined"
oder sowas? AHCI-Mode?

> Die Symptome sind natürlich noch gleich
>> Irgendein anderer (generischer?) Treiber stuerzt sich auf das Interface
>> und hat es sich dann schon unter den Nagel gerisssen.
>> Das schlimmste ist, ausser ICH7 sehe ich da grad nix. Da is doch der
>> Wurm drin.
>> Scheiss Initrd...
>>   
> Den Zusammenhang zwischen initrd und dem ganzen verstehe ich zwar noch 
> nicht ganz.
> Findest Du vielleicht distri-Kernel unbrauchbar?
Der Mechanismus der Initrd wird zwar vom Kernel zur verfuegung gestellt,
aber der Inhalt sind nicht nur ein paar .ko, sondern auch ein paar
Scripte, die das alles laden und handeln. DIE sind Distri-spezifisch
(genauso wie die Erstellung und dann eben Einstellmoeglichkeiten und
Autofaehigkeiten).
So mounten alle RedHat/Fedora das root-device nach UID aus der initrd,
tolle Sache, es kann sich umbennen wie es will (hda, sdb), es wird gefunden.
Davon hat der geneigte $IRGENDWAS Benutzer nur nichts.

Wenn man nun etwas einstellen moechte, oder muss, muss man auf jeder
Ditro wissen, wie man es macht.

Dazu das Problem, das eben die Initrd erfunden wurde, damit Distris ALLE
Treiber dazu legen koennen (damit es ueberall laeuft), wird dann ekelig,
wenn zwei oder mehrere Treiber sich um ein Device pruegeln (generischer,
alter, neuer). Man kann zwar aus einer Initrd eigentlich besser
kontrolieren, was in welcher Reihenfolge geladen wird, einfacher wird es
aber meistens dadurch, genau eins einzukompilieren oder nicht, denn die
Scripte beruecksichtigen diese Moeglichkeit nicht, so das man dran
rumschrauben muesste, und dann kolidiert es mit dem Packetsystem.

Und das selbst erzeugen eines Kernels ist dann auch meist ein
Spiessrutenlauf wenn man es "The-Distri-Way" machen moechte.

Distro-Kernel sind schon toll wenn sie laufen und man nichts anpassen
will/muss. Einspielen, gluecklichsein. Updates kriegen, gut is.

IMHO & AFAIE

>>> Den gleichen Fehler bekomme ich, wenn ich libata versuche ATAPI 
>>> beizubringen:
>>>
>>> **"echo options libata atapi_enabled=1>/etc/modprobe.d/atapienable"**
>>>
>>>     
>> So einfach geht das nicht, erstmal muss der Chipsatztreiber unter libata
>> geladen werden, dann kann sich libata auch um entsprechend
>> angeschlossene ATAPI-Geraete kuemmern.
>>   
> Hmm, hast Du da eine gute Quelle für eine Dokumentation?
Nein, leider nicht. Vielleicht wer anders?
Nur "Wie arbeitet das zusammen"-Bits&Pieces in meinem Kopf.
Freiheitsgrade wie an deinem Chipsatz (combined mode etc.) sind da
natuerlich dann unpraktisch.
Einfach im Internet suchen, es gibt einige Wikis und Forenberichte genau
zu ICH7 und ATAPI Laufwerken, man muss nur immer genau aufs Datum und
die Kernelversion achten, ob das noch so gueltig ist, abzueglich
widerspruechliche aussagen + ob der Hase fuer deine Distri so laeuft.

>>   
>> Kernel bauen
>> Kernel bauen
>> Kernel bauen
>>
>>   
> Das macht nur sinn, wenn ich weiss, welches Module meinen IDE Treiber 
> glücklich macht.
> 
Ich dachte auch eher, zum experimentieren macht es das erstmal einfacher
um genau diesen oder jenen Treiber auszuprobieren.

Im Prinzip muesste seit 2.6.18-19 ata_piix der einzig gluecklich
machende sein. Eigentlich. Was er noch an "combined_mode=libata" oder
"libata.atapi_enabled=1" braucht, ka. Wenn du erstmal bei dem
Ditro-kernel bleibst (was im Prinzip auch gehen sollte), brauchst du
wohl noch "hda=noprobe", aber ob das noch mit 2.6.18 gueltig ist
(widerspruechliche Infos)...

Schau halt in den RedHat-Bugreport, ich bin auch ueber ein Thinkpad-Wiki
gestossen, die das ansprechen, aber mit widerspruechlichen infos.


> Gruß
>  Thomas
> 
Gruss
	Jan

-- 
> Was bedeutet die Abkürzung UMTS?
"Unverhoffte Mehreinnahme zur Tilgung von Staatsschulden" ...
			-- Oliver Brosch in de.comm.technik.mobil