Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 13 Jul 2007 11:37:11 -0400
From:      John Baldwin <jhb@freebsd.org>
To:        freebsd-acpi@freebsd.org, =?windows-1251?b?zOj14OjrIMrz9+jt?= <admin@mixey.spb.ru>
Subject:   Re: Asus P5W DH Deluxe APIC/SMP IRQ problem
Message-ID:  <200707131137.11871.jhb@freebsd.org>
In-Reply-To: <1737185464.20070713180756@mixey.spb.ru>
References:  <1737185464.20070713180756@mixey.spb.ru>

next in thread | previous in thread | raw e-mail | index | archive | help
On Friday 13 July 2007 10:07:56 am =CC=E8=F5=E0=E8=EB =CA=F3=F7=E8=ED wrote:
> Hi!
>=20
> I am still searching help with Asus P5W DH Deluxe IRQ's
>=20
> > > > atapci0: <JMicron JMB363 SATA300 controller> port
> > > > 0xac00-0xac07,0xa880-0xa883,0xa800-0xa807,0xa480-0xa483,0xa400-0xa4=
0f=20
mem
> > > > 0xfe8fe000-0xfe8fffff irq 17 at device 0.0 on pci2
> > > > atapci0: AHCI Version 01.00 controller with 2 ports detected
> > > > ata2: <ATA channel 0> on atapci0
> > > > ata3: <ATA channel 1> on atapci0
> > > > ata4: <ATA channel 2> on atapci0
> > >
> > > So my guess is that one or more of these ATA issues is the cause.
>=20
> > Probably not.  His issue is that some device that _isn't_ on IRQ 23 in =
the
> > _PRT tables, actually _is_ on IRQ 23.  The key is to find out what devi=
ce
> > (not atapci2) is generating those interrupts.  Turning each device off
> > individually to test can figure this out.
>=20
> Thank You for ideas. Today I've tried to use some other VGA cards,
> lots of old different PCI and some new PCI experss card - no effect.
> Not to load myk0 intertface - also unsuccessful.
>=20
> How can I turn off other devices like bus or conroller? I have
> succeeded in turning off only myk0 and changing VGA. What cat I do
> next while searching this "bad" device?
>=20
> By the way, I've got verbose boot log and mptable output:
>    http://mixey.spb.ru/boot-verbose.txt
>    http://mixey.spb.ru/mptable.txt
>   =20
> Can it help me?

=46or now you would just have to hack drivers to not attach, etc.  Your mpt=
able=20
agrees with the ACPI tables.  It could also be a bug in the ata(4) driver i=
f=20
it's not acknowledging some interrupt condition.  You could test for that b=
y=20
trying to print out the interrupt status register in the ata interrupt=20
handler for the device on irq 23 and seeing if there are conditions that ar=
e=20
set on each interrupt and not getting cleared.

=2D-=20
John Baldwin



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200707131137.11871.jhb>