Frebsd 7-STABLE, atapicd, atapicam and Intel errors [SOLVED]

[Jung-uk Kim]

On Wednesday 19 November 2008 03:16 pm, Jan Sebosik wrote:
> Jung-uk Kim napsal(a):
> > On Wednesday 19 November 2008 12:01 pm, Jan Sebosik wrote:
> >> Hi
> >>
> >> so I`ve played with it again, and results are strange.
> >>
> >>    Regardless if HPET is enabled or not.. FreeBSD with atapicd
> >> kldloaded won`t mount /dev/acd1 (mounting /dev/cd0 works). When
> >> I tryied to mount acd0 it still hangs at READ_BIG TIMEOUT.
> >>
> >>    When I left CD in drive, and rebooted (I wanted to switch
> >> HPET), it freezes on cd0 initialization with READ_BIG timeout (I
> >> think it`s causing GEOM_LABEL module trying to read CD label).
> >>
> >> So I think that disabling GEOM_LABEL would help a little.
> >>
> >> I`ll try on friday with another SATA DVD drive if it`s not a bug
> >> inside firmware of LG  :) .
> >>
> >>
> >> Best regards, Jan
> >>
> >> Jeremy Chadwick napsal(a):
> >>> On Wed, Nov 19, 2008 at 03:24:40PM +0100, Jonas Lund wrote:
> >>>> (NOTICE: i'm more of a lowlevel guy close to hardware guy not
> >>>> knowing much of freebsd internals)
> >>>>
> >>>> The fact that FreeBSD is NOT using HPET for timing might be
> >>>> the answer to the "mystery". The HPET hardware might be/get
> >>>> enabled but not handled and firing tons of unexpected
> >>>> interrupts (as you said.. linux produces tons of data into the
> >>>> log, what's the actual content of those logs?).
> >>>>
> >>>> These interrupts in turn might disturb the cd drive in some
> >>>> fashion?
> >>>>
> >>>> Can you bring up some interrupt statistics in freebsd? like a
> >>>> counter of the number of events?
> >>>
> >>> First and foremost, thanks for chiming in, Jonas.  The more
> >>> eyes on this matter the merrier.
> >>>
> >>> vmstat -i can provide interrupt rate and count in FreeBSD,
> >>> e.g.:
> >>>
> >>> interrupt                          total       rate
> >>> irq1: atkbd0                         227          0
> >>> irq6: fdc0                            10          0
> >>> irq17: uhci1++                   4479741         10
> >>> cpu0: timer                    814684046       2000
> >>> irq256: em0                     17219212         42
> >>> cpu1: timer                    814683722       2000
> >>> Total                         1651066958       4053
> >>>
> >>>> 2008/11/19 Jan Sebosik <sebosik at demax.sk>:
> >>>>> [snip]
> >>>>>
> >>>>>> Okay now I understand.  Thank you for taking the time to
> >>>>>> explain!  :-)
> >>>>>>
> >>>>>> And when you disable HPET in the BIOS, what happens?
> >>>>>>
> >>>>>>> Maybe I should try -CURRENT sometimes with your proposed
> >>>>>>> ata patches (or are they merged in right now?).
> >>>>>>
> >>>>>> Sure, you're free to try CURRENT.  The ATA code on CURRENT
> >>>>>> was modularised, and also a very large patch applied; I
> >>>>>> can't promise it fixes your CD/DVD drive issues though.
> >>>>>>
> >>>>>> I had problems getting CURRENT to see my PCI SATA Promise
> >>>>>> controller (it wasn't appearing in pciconf -lv, nor dmesg),
> >>>>>> but I had no problems with CURRENT seeing my ICH7
> >>>>>> controller. I also had other problems with CURRENT which
> >>>>>> caused me to go back to RELENG_7.  CURRENT is undergoing
> >>>>>> lots of changes right now, so I recommend subscribing to
> >>>>>> -current if you plan on running it.
> >>>>>>
> >>>>>> I personally haven't written any ATA patches, except for
> >>>>>> extending atacontrol to support per-disk write cache
> >>>>>> enable/disable.  I think you might be confusing me with
> >>>>>> Andrey V. Elsukov, who *has* written lots of ATA stuff.
> >>>>>
> >>>>> Now happens almost nothing (I don`t understand), except the
> >>>>> cd/acd problems (READ_BIG errors), but I don`t understand why
> >>>>> it is happening.. maybe guys from Intel optimized this board
> >>>>> too much for twista OS :).
> >
> > Can you try the attached patch with HPET enabled from BIOS? 
> > Sorry, it will not solve the cd/acd problems but I have a hunch
> > that it may solve the HPET problem.
> >
> > Thanks,
> >
> > JK
>
> Hi
>
> I`ve tried your patch right now, but didn`t notice any change in
> machine`s behavior.

Okay.  I just went ahead and committed it because that's the right 
thing to do any way. :-)

Thanks for the feedback.

Jung-uk Kim