The man page for hdparm is a bit dated on the -u flag allowing ints during
i/o, warning about the dangers of using kernels older than 2.0.13. No
problem there, but what are the more current implications?
I would think that this would be safe when using DMA, and likely to be
safe for PIO and more recent chipsets, but I wouldn't want to actually
tell anyone that.
Therefore:
1 - the man page would benefit from an update regarding recent kernels
from this millenium, if only to reassure readers.
2 - any better way to tell if allowing ints will cause problems than just
to try it? Not desirable on large machines, but it was off and I am
seeing serial problems on the OOB access modem.
--
bill davidsen <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
>[...]
> I would think that this would be safe when using DMA, and likely to be
> safe for PIO and more recent chipsets, but I wouldn't want to actually
> tell anyone that.
A little story from OLS. I have a 486/75 laptop, which can only
do PIO. It always was losing characters evern on 9600 baud on its
serial port, and I thought it was simply broken for five years.
A guy who did a security talk showed me that doing hdparm -u
fixes the problem. Apparently, the lappy has a non-buffering UART.
So, it seems that hdparm -u is a very useful thing for obsotele
boxes. If you do DMA, you probably do not care.
-- Pete
On Wed, 24 Jul 2002, Pete Zaitcev wrote:
> >[...]
> > I would think that this would be safe when using DMA, and likely to be
> > safe for PIO and more recent chipsets, but I wouldn't want to actually
> > tell anyone that.
>
> A little story from OLS. I have a 486/75 laptop, which can only
> do PIO. It always was losing characters evern on 9600 baud on its
> serial port, and I thought it was simply broken for five years.
:-)
> A guy who did a security talk showed me that doing hdparm -u
> fixes the problem. Apparently, the lappy has a non-buffering UART.
>
> So, it seems that hdparm -u is a very useful thing for obsotele
> boxes. If you do DMA, you probably do not care.
Yup, for PIO unmask (if possible) is a must.
--bzolnier
> -- Pete
Bartlomiej Zolnierkiewicz wrote:
> On Wed, 24 Jul 2002, Pete Zaitcev wrote:
>
>
>>>[...]
>>>I would think that this would be safe when using DMA, and likely to be
>>>safe for PIO and more recent chipsets, but I wouldn't want to actually
>>>tell anyone that.
>>
>>A little story from OLS. I have a 486/75 laptop, which can only
>>do PIO. It always was losing characters evern on 9600 baud on its
>>serial port, and I thought it was simply broken for five years.
>
>
> :-)
>
>
>>A guy who did a security talk showed me that doing hdparm -u
>>fixes the problem. Apparently, the lappy has a non-buffering UART.
>>
>>So, it seems that hdparm -u is a very useful thing for obsotele
>>boxes. If you do DMA, you probably do not care.
>
>
> Yup, for PIO unmask (if possible) is a must.
It's even for DMA a good thing, since the IRQ handler in question can
reenter the RQ handler. The invention of the not unmasking
behaviour in Linux is the result of some not entierly ATA-2 compliant
devices long long time ago gone. Basically XT disks on PC. They did have
the habbit of splewing IRQs too early for command ACK.
On Thu, 2002-07-25 at 08:54, Marcin Dalecki wrote:
> > Yup, for PIO unmask (if possible) is a must.
>
> It's even for DMA a good thing, since the IRQ handler in question can
> reenter the RQ handler. The invention of the not unmasking
> behaviour in Linux is the result of some not entierly ATA-2 compliant
> devices long long time ago gone. Basically XT disks on PC. They did have
> the habbit of splewing IRQs too early for command ACK.
There are also some older systems where if the block transfer of the IDE
data didn't keep up with the controller instead of handshaking properly
it kind of dribbled random numbers onto the disk.
Unless anyone knows of PCI era devices with this problem I would be
inclined to agree that we should default to IRQ unmasking in the 2.5 IDE
code if the IDE controller is PCI.
For old ISA/VLB controllers its safer left as is, and nobody running a
machine like that can realistically expect good performance without hand
tuning stuff anyway
Alan Cox wrote:
> On Thu, 2002-07-25 at 08:54, Marcin Dalecki wrote:
>
>>>Yup, for PIO unmask (if possible) is a must.
>>
>>It's even for DMA a good thing, since the IRQ handler in question can
>>reenter the RQ handler. The invention of the not unmasking
>>behaviour in Linux is the result of some not entierly ATA-2 compliant
>>devices long long time ago gone. Basically XT disks on PC. They did have
>>the habbit of splewing IRQs too early for command ACK.
>
>
> There are also some older systems where if the block transfer of the IDE
> data didn't keep up with the controller instead of handshaking properly
> it kind of dribbled random numbers onto the disk.
>
> Unless anyone knows of PCI era devices with this problem I would be
> inclined to agree that we should default to IRQ unmasking in the 2.5 IDE
> code if the IDE controller is PCI.
Tough not 100% but I'm about 99% sure that having this kind of problem
no PCI bus would prevent any kind of proper level triggered IRQ handling
on behalf of the host controller... At least it seems very very
unlikely. (Data transfer problems are a different story of course.)
And I personally never ever expirenced *any* problems with -u1 on any
Linux systems I ever got in to my hands (startting 386sx 16MHz...).
Not even at the time I run the really buggy CMD640 mask revision for 3
years.
> For old ISA/VLB controllers its safer left as is, and nobody running a
> machine like that can realistically expect good performance without hand
> tuning stuff anyway
Sounds fairly well and is easy to implement...just adding
if (ch->pci_dev != NULL && ch->umask)
at the corresponding plase in ata_irq_request will do the trick.
On Thursday 25 July 2002 11.34, Marcin Dalecki wrote:
> Alan Cox wrote:
> > For old ISA/VLB controllers its safer left as is, and nobody running a
> > machine like that can realistically expect good performance without hand
> > tuning stuff anyway
>
> Sounds fairly well and is easy to implement...just adding
>
> if (ch->pci_dev != NULL && ch->umask)
>
> at the corresponding plase in ata_irq_request will do the trick.
>
Yea, but I lake to be able to see that it is enabled with hdparm
(and to be able to disable it as well...)
/RogerL
--
Roger Larsson
Skellefte?
Sweden
On 25 Jul 2002, Alan Cox wrote:
> There are also some older systems where if the block transfer of the IDE
> data didn't keep up with the controller instead of handshaking properly
> it kind of dribbled random numbers onto the disk.
>
> Unless anyone knows of PCI era devices with this problem I would be
> inclined to agree that we should default to IRQ unmasking in the 2.5 IDE
> code if the IDE controller is PCI.
Certainly if the controller is running in DMA mode. If running in PIO mode
I would think you could still have a problem if the transfer was stopped
mid-block. Perhaps I'm paranoid, is that a "can't happen" now?
> For old ISA/VLB controllers its safer left as is, and nobody running a
> machine like that can realistically expect good performance without hand
> tuning stuff anyway
I would think the guts of PIO block transfer would have to be protected
anyway, but that's a very small part of the code.
--
bill davidsen <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
Bill Davidsen wrote:
> On 25 Jul 2002, Alan Cox wrote:
>
>
>>There are also some older systems where if the block transfer of the IDE
>>data didn't keep up with the controller instead of handshaking properly
>>it kind of dribbled random numbers onto the disk.
>>
>>Unless anyone knows of PCI era devices with this problem I would be
>>inclined to agree that we should default to IRQ unmasking in the 2.5 IDE
>>code if the IDE controller is PCI.
>
>
> Certainly if the controller is running in DMA mode. If running in PIO mode
> I would think you could still have a problem if the transfer was stopped
> mid-block. Perhaps I'm paranoid, is that a "can't happen" now?
Please note that with the advent of on target device caching this is
neraly impossible unless you chook the cabling - which is of course
something we can't prevent.
>>For old ISA/VLB controllers its safer left as is, and nobody running a
>>machine like that can realistically expect good performance without hand
>>tuning stuff anyway
>
>
> I would think the guts of PIO block transfer would have to be protected
> anyway, but that's a very small part of the code.