Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 01 Nov 2004 15:05:03 -0800
From:      "Kevin Oberman" <oberman@es.net>
To:        John Baldwin <jhb@FreeBSD.org>
Cc:        freebsd-acpi@FreeBSD.org
Subject:   Re: ASUS P5A broken by ACPI black-list 
Message-ID:  <20041101230503.6BFCC5D09@ptavv.es.net>
In-Reply-To: Your message of "Mon, 01 Nov 2004 17:48:25 EST." <200411011748.25052.jhb@FreeBSD.org> 

next in thread | previous in thread | raw e-mail | index | archive | help
> From: John Baldwin <jhb@FreeBSD.org>
> Date: Mon, 1 Nov 2004 17:48:25 -0500
> 
> On Wednesday 06 October 2004 01:20 pm, John Baldwin wrote:
> > On Tuesday 05 October 2004 04:32 pm, Kevin Oberman wrote:
> > > > From: John Baldwin <jhb@FreeBSD.org>
> > > > Date: Tue, 5 Oct 2004 12:09:44 -0400
> > > >
> > > > On Tuesday 05 October 2004 11:54 am, Kevin Oberman wrote:
> > > > > > From: John Baldwin <jhb@FreeBSD.org>
> > > > > > Date: Mon, 4 Oct 2004 15:57:30 -0400
> > > > > >
> > > > > > On Monday 04 October 2004 02:33 pm, Nate Lawson wrote:
> > > > > > > Kevin Oberman wrote:
> > > > > > > > It looks like interrupts from the Ethernet are not delivered
> > > > > > > > without ACPI, but that is hardly your problem. I have
> > > > > > > > over-ridden the black-list and things are back to normal.
> > > > > > >
> > > > > > > The reason this system works in Windows without ACPI is that irq
> > > > > > > routing in Windows uses multiple info sources including _PIR and
> > > > > > > $PIR. John Baldwin has patches to do this for us too.
> > > > > >
> > > > > > $PIR routing already works on FreeBSD and has worked for quite a
> > > > > > while. The patches I have are to make the acpi_pci_link code work
> > > > > > more like the $PIR code already does.  It doesn't change the ACPI
> > > > > > code to actually use $PIR or the MPTable though.  I can try to look
> > > > > > at why the ethernet device doesn't get interrupts correctly if you
> > > > > > can provide verbose ACPI and non-ACPI dmesgs to look at.
> > > > >
> > > > > I am attaching the files. I do see some oddities with the
> > > > > interrupts that I had not previously noted, but they seen to be
> > > > > linked to sound, not the Ethernet. And, for whatever it's worth,
> > > > > "vmstat -i" does not show my sound card, at all. dmesg indicates it
> > > > > should be on IRQ 6. interrupt                          total      
> > > > > rate
> > > > > irq0: clk                        4242251         99
> > > > > irq1: atkbd0                           3          0
> > > > > irq7: ppc0                             1          0
> > > > > irq8: rtc                        5430044        127
> > > > > irq10: xl0                         13699          0
> > > > > irq13: npx0                            1          0
> > > > > irq14: ata0                       166980          3
> > > > > irq15: ata1                          136          0
> > > > > Total                            9853115        232
> > > >
> > > > First, do you have a floppy drive?  IRQ 6 should be used for your
> > > > floppy drive if so.  Note that $PIR says that IRQ 6 is not an option
> > > > for your link devices but ACPI does.  In the non-APCI case we use IRQ
> > > > 10 for both xl0 and pcm0. Are you saying that in that case pcm0 works
> > > > but xl0 does not?
> > >
> > > The sound card works fine with ACPI but, without ACPI it fails. The
> > > first tone in the file plays continuously, like there are no interrupts
> > > from the sound card. :-)
> >
> > Ok, well, it seems your BIOS is too busted for non-ACPI to work out of the
> > box, you can try setting a hint to force the link for your sound card to
> > use IRQ 6.  Something like 'set hw.pci.link.0x4.irq=6', or maybe
> > 'hw.pci.link.0x04.irq' if that doesn't work.
> 
> Actually, the $PIR code won't let you use an invalid IRQ currently, but this 
> patch lets it do so.  I'm curious if you could try booting with this patch 
> with ACPI disabled and using an appropriate tunable (such as 
> 'hw.pci.link.0x4.irq=6') to route your links the way ACPI likes them routed.  
> If this does work, I'd like to try another patch as well that would help it 
> to work out-of-the-box for the non-ACPI case.  Thanks.

John,

I just did the patch and the kernel is rebuilding, but I am in
Pittsburgh for SuperComputing conference next week and will not be back
home (where the ASUS is) until Nov. 13.

I will ask my wife to be available to re-boot the old kernel if it
fails, but that won't be until tonight. I should have some feedback on
this by tomorrow, but if I get busy with SCinet (which is what I'm being
paid to do), my response may be delayed.

Thanks for looking at this issue. It's beyond my area of knowledge. In
fact, all of the $PIR stuff is. Hard IRQs are brain dead, but easier for
me to understand.
-- 
R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
E-mail: oberman@es.net			Phone: +1 510 486-8634



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