RELENG_7: interrupt eating whole cpu core

[Dominic Fandrey]

Carlos A. M. dos Santos wrote:
> On Feb 8, 2008 4:27 AM, Dominic Fandrey <kamikaze at bsdforen.de> wrote:
>> Carlos A. M. dos Santos wrote:
>>> On Feb 6, 2008 5:45 PM, Dominic Fandrey <kamikaze at bsdforen.de> wrote:
>>>> Chuck Swiger wrote:
>>>>> Hi, Dominic--
>>>>>
>>>>> On Feb 6, 2008, at 11:12 AM, Dominic Fandrey wrote:
>>>>>>> behaviour has changed. This is an HP 6510b GR695EA#ABD, if anyone
>>>>>>> thinks it might be helpful, I can supply you with a dmesg and the
>>>>>>> output of pciconf -lv.
>>>>>> The problem remains with fresh sources:
>>>>>>
>>>>>>  PID USERNAME   THR PRI NICE   SIZE    RES STATE  C   TIME    CPU COMMAND
>>>>>>   12 root         1 171 ki31     0K    16K RUN    0  22:04 97.85%
>>>>>> idle: cpu0
>>>>>>   37 root         1 -64    -     0K    16K CPU1   1   2:35 96.00%
>>>>>> irq14: ata0
>>>>>>   11 root         1 171 ki31     0K    16K RUN    1  19:32  6.40%
>>>>>> idle: cpu1
>>>>>>
>>>>>> The rip is done by k3b, so the drive is accessed through the cam
>>>>>> interface.
>>>>> What are the values being reported by "sysctl hw.ata"?  If you're going
>>>>> to be burning CD/DVDs, you really want to make sure hw.ata.atapi_dma is on.
>>>> I cannot believe it was so trivial. The sysctl looks all right.
>>>>
>>>> # sysctl hw.ata                                      0 /root
>>>> hw.ata.wc: 1
>>>> hw.ata.atapi_dma: 1
>>>> hw.ata.ata_dma: 1
>>>>
>>>> But further research revealed:
>>>> # atacontrol mode acd0                               0 /root
>>>> current mode = PIO4
>>>>
>>>> # atacontrol mode acd0 udma33                        0 /root
>>>>
>>>> changed the load dramatically:
>>>>   PID USERNAME    THR PRI NICE   SIZE    RES STATE  C   TIME   WCPU COMMAND
>>>>    12 root          1 171 ki31     0K    16K RUN    0  52:54 100.00% idle: cpu0
>>>>    11 root          1 171 ki31     0K    16K CPU1   1  23:36 94.29% idle: cpu1
>>>> 1087 kamikaze      3  -8    0   133M 36168K physrd 1   1:09  3.17% k3b
>>>>    37 root          1 -64    -     0K    16K WAIT   1  30:10  0.00% irq14: ata0
>>>>
>>>>
>>>> Thank you very much! I used to think that UDMA33 was the default for
>>>> CD-/DVD-Rom drives. I suppose I should review the BIOS settings or change
>>>> something in the hints file.
>>> Wow, now I'm *really* surprised. I used to think that putting
>>>
>>>      hw.ata.ata_dma="1"
>>>      hw.ata.atapi_dma="1"
>>>
>>> in /boot/loader.conf would be enough to enable DMA mode. In fact I'm
>>> pretty sure it used to be in previous versions of FreeBSD. I created a
>>> /etc/rc.local containing
>>>
>>>      #!/bin/sh -
>>>      atacontrol mode acd0 udma33
>>>
>> Did you check weather you are affected, before you applied your solution?
>> Only one machine is affected.
> 
> Yes, it happens in my notebook (HP NX6320).
> 
>> I put the following into my rc.conf:
>> # Set mode for CD/DVD drive.
>> /sbin/atacontrol mode acd0 2>&1 | /usr/bin/grep PIO > /dev/null 2>&1 \
>>         && /sbin/atacontrol mode acd0 UDMA33
> 
> Do not put this in rc.conf. It will be executed again each time a
> script in /etc/rc.d source rc.conf to obtain the configuration
> variables.

Hence the check, weather the drive is in PIO mode or not. The way I understand 
the rc(8) manual page, the same is true for rc.local.

> 
>>> Two questions, now:
>>>
>>> 1. Is this related to using atapicam?
>> Not for me.
>>
>>> 2. Should this be considered a bug?
>> Yes, but not in FreeBSD. It's a bug in the BIOS of my Notebook. This is a
>> guess, not certainty.
> 
> I believe that the kernel must handle this transparently when
> hw.ata.atapi_dma is set to 1, but I will need to look at the code this
> to see what is happening.

I think it's the job of the BIOS to set this properly. Many BIOS allow you to 
choose the mode and FreeBSD obeys the settings made in the BIOS. To me that 
makes sense. It's a problem of HP that they do not allow to change the setting 
and have chosen such an ill fit default.

Also you cannot just send everything into DMA mode, because all devices can 
have different capabilities.

My preferred solution would be to have device hints for every device to 
override the BIOS settings.