Hello!
I am working on an embedded ppc (mpc8540) using a pretty common Promise IDE
PCI controller w/ a PDC20275 on it (it's called Ultra TX2).
I have an otherwise good Maxtor 6B120P0 (160GB) connected to it.
But sometimes (expecially with more than zero disk-i/o-load), when I
turn on DMA by
$hdparm -X69 -d1 /dev/hda
I get
hda: task_out_intr: status=0x58 { DriveReady SeekComplete DataRequest }
ide: failed opcode was: unknown
hda: CHECK for good STATUS
And when I turn off DMA with
$hdparm -d0 /dev/hda
I get sometimes a
hda: DMA disabled
which is fine but sometimes I also get:
hda: status error: status=0x58 { DriveReady SeekComplete DataRequest }
ide: failed opcode was: unknown
hda: drive not ready for command
hda: CHECK for good STATUS
which is not so nice.
Can you tell me if this is dangerous?
$ uname -a
Linux ecam.anagramm.de 2.6.13-rc7 #5 Thu Aug 25 15:33:38 CEST 2005 ppc ppc ppc GNU/Linux
I am about to update to the latest 2.6.15-rc5.
Thanks,
--
Clemens Koller
_______________________________
R&D Imaging Devices
Anagramm GmbH
Rupert-Mayer-Str. 45/1
81379 Muenchen
Germany
http://www.anagramm.de
Phone: +49-89-741518-50
Fax: +49-89-741518-19
On 12/16/05, Clemens Koller <[email protected]> wrote:
> Hello!
Hi,
> I am working on an embedded ppc (mpc8540) using a pretty common Promise IDE
> PCI controller w/ a PDC20275 on it (it's called Ultra TX2).
> I have an otherwise good Maxtor 6B120P0 (160GB) connected to it.
>
> But sometimes (expecially with more than zero disk-i/o-load), when I
> turn on DMA by
>
> $hdparm -X69 -d1 /dev/hda
> I get
>
> hda: task_out_intr: status=0x58 { DriveReady SeekComplete DataRequest }
> ide: failed opcode was: unknown
> hda: CHECK for good STATUS
>
> And when I turn off DMA with
> $hdparm -d0 /dev/hda
> I get sometimes a
>
> hda: DMA disabled
>
> which is fine but sometimes I also get:
>
> hda: status error: status=0x58 { DriveReady SeekComplete DataRequest }
> ide: failed opcode was: unknown
> hda: drive not ready for command
> hda: CHECK for good STATUS
>
> which is not so nice.
> Can you tell me if this is dangerous?
Is there any particular reason why you are using hdparm with '-d' and '-X'?
Your IDE host driver (pdc202xx_new in this case) should configure
best xfer mode and enable DMA so you shouldn't need to use hdparm.
Given that IDE driver code for changing xfer mode and DMA setting
is racy and actually quite hard to fix, it will probably be removed in
the future (after auditing IDE host drivers).
BTW please use [email protected] for IDE problems
Thanks,
Bartlomiej
Hello, Bartolmiej!
>>I am working on an embedded ppc (mpc8540) using a pretty common Promise IDE
>>PCI controller w/ a PDC20275 on it (it's called Ultra TX2).
>>I have an otherwise good Maxtor 6B120P0 (160GB) connected to it.
>>
>>But sometimes (expecially with more than zero disk-i/o-load), when I
>>turn on DMA by
>>
>>$hdparm -X69 -d1 /dev/hda
>>I get
>>
>>hda: task_out_intr: status=0x58 { DriveReady SeekComplete DataRequest }
>>ide: failed opcode was: unknown
>>hda: CHECK for good STATUS
>>
>>And when I turn off DMA with
>>$hdparm -d0 /dev/hda
>>I get sometimes a
>>
>>hda: DMA disabled
>>
>>which is fine but sometimes I also get:
>>
>>hda: status error: status=0x58 { DriveReady SeekComplete DataRequest }
>>ide: failed opcode was: unknown
>>hda: drive not ready for command
>>hda: CHECK for good STATUS
>>
>>which is not so nice.
>>Can you tell me if this is dangerous?
>
>
> Is there any particular reason why you are using hdparm with '-d' and '-X'?
I want to test it with DMA before fixing it into the kernel.
> Your IDE host driver (pdc202xx_new in this case) should configure
> best xfer mode and enable DMA so you shouldn't need to use hdparm.
I didn't enable automatic turning on of DMA it in the kernel by default
in the past because I had problems with this hdd controller and
interrupts (some PCI IRQ mapping issues). The interrupt issues are
solved now, so I've tried to enable DMA. DMA works pretty fine,
I was just worried about the severity of the message. It doesn't
really tell anything useful for non-ide-hackers. (whether it's
dangerous or not.)
> Given that IDE driver code for changing xfer mode and DMA setting
> is racy and actually quite hard to fix, it will probably be removed in
> the future (after auditing IDE host drivers).
So, I guess the answer is: DMA itself seems to work and it
isn't really dangerous - it's working as it's supposed to.
But if you do it the way you do, you can run into problems due
to races. Right? So, if I enable DMA as usual in the kernel,
I don't usually risk my data?!
> BTW please use [email protected] for IDE problems
Okay, in next thread.
Thanks,
--
Clemens Koller
_______________________________
R&D Imaging Devices
Anagramm GmbH
Rupert-Mayer-Str. 45/1
81379 Muenchen
Germany
http://www.anagramm.de
Phone: +49-89-741518-50
Fax: +49-89-741518-19
On 12/19/05, Clemens Koller <[email protected]> wrote:
> Hello, Bartolmiej!
>
> >>I am working on an embedded ppc (mpc8540) using a pretty common Promise IDE
> >>PCI controller w/ a PDC20275 on it (it's called Ultra TX2).
> >>I have an otherwise good Maxtor 6B120P0 (160GB) connected to it.
> >>
> >>But sometimes (expecially with more than zero disk-i/o-load), when I
> >>turn on DMA by
> >>
> >>$hdparm -X69 -d1 /dev/hda
> >>I get
> >>
> >>hda: task_out_intr: status=0x58 { DriveReady SeekComplete DataRequest }
> >>ide: failed opcode was: unknown
> >>hda: CHECK for good STATUS
> >>
> >>And when I turn off DMA with
> >>$hdparm -d0 /dev/hda
> >>I get sometimes a
> >>
> >>hda: DMA disabled
> >>
> >>which is fine but sometimes I also get:
> >>
> >>hda: status error: status=0x58 { DriveReady SeekComplete DataRequest }
> >>ide: failed opcode was: unknown
> >>hda: drive not ready for command
> >>hda: CHECK for good STATUS
> >>
> >>which is not so nice.
> >>Can you tell me if this is dangerous?
> >
> >
> > Is there any particular reason why you are using hdparm with '-d' and '-X'?
>
> I want to test it with DMA before fixing it into the kernel.
>
> > Your IDE host driver (pdc202xx_new in this case) should configure
> > best xfer mode and enable DMA so you shouldn't need to use hdparm.
>
> I didn't enable automatic turning on of DMA it in the kernel by default
> in the past because I had problems with this hdd controller and
> interrupts (some PCI IRQ mapping issues). The interrupt issues are
> solved now, so I've tried to enable DMA. DMA works pretty fine,
> I was just worried about the severity of the message. It doesn't
> really tell anything useful for non-ide-hackers. (whether it's
> dangerous or not.)
>
> > Given that IDE driver code for changing xfer mode and DMA setting
> > is racy and actually quite hard to fix, it will probably be removed in
> > the future (after auditing IDE host drivers).
>
> So, I guess the answer is: DMA itself seems to work and it
> isn't really dangerous - it's working as it's supposed to.
Yes.
> But if you do it the way you do, you can run into problems due
> to races. Right? So, if I enable DMA as usual in the kernel,
> I don't usually risk my data?!
Yes, just use default settings.
Thanks,
Bartlomiej