RELENG_7: interrupt eating whole cpu core
Carlos A. M. dos Santos
unixmania at gmail.com
Fri Feb 8 13:43:33 UTC 2008
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.
> > 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.
--
Carlos A. M. dos Santos
More information about the freebsd-stable
mailing list