RE: Interrupt routing problem

RE: Interrupt routing problem

[Yu, Luming]

>The problem is that this box's BIOS points all the interrupt links to
IRQ9
>by default and as far as I remember, neither acpi_irq_pci= nor

Let me see the DSDT..

>acpi_balance_irqs help.
>Is the off-one bug in printing IRQs still present?

I didn't remember bug about printing IRQs.

--Luming


-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id\x1278&alloc_id371&op=click

Re: Interrupt routing problem

[Karol Kozimor]

Thus wrote Yu, Luming:
> >The problem is that this box's BIOS points all the interrupt links to
> IRQ9
> >by default and as far as I remember, neither acpi_irq_pci= nor
> Let me see the DSDT..

See bugzilla #1185 for all the info.

> >acpi_balance_irqs help.
> >Is the off-one bug in printing IRQs still present?
> I didn't remember bug about printing IRQs.

I remember Len writing about one, I'll dig up the old email and point you
to the correct entry (basically, it was about not printing / taking into
account default BIOS links settings under certain conditions).
Best regards,

-- 
Karol 'sziwan' Kozimor
sziwan-DETuoxkZsSqrDJvtcaxF/A@public.gmane.org


-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click

Re: Interrupt routing problem

[Karol Kozimor]

Thus wrote Karol Kozimor:
> I remember Len writing about one, I'll dig up the old email and point you
> to the correct entry (basically, it was about not printing / taking into
> account default BIOS links settings under certain conditions).

Plese refer to:
http://bugme.osdl.org/show_bug.cgi?id=1320#c10
http://bugme.osdl.org/show_bug.cgi?id=430

#430 in particular doesn't seem to be fixed, i.e. both 2.4.23 and
2.6.0-rc1-mm1 don't seem to print IRQ#9 as available.
Best regards,

-- 
Karol 'sziwan' Kozimor
sziwan-DETuoxkZsSqrDJvtcaxF/A@public.gmane.org


-------------------------------------------------------
This SF.net email is sponsored by: Perforce Software.
Perforce is the Fast Software Configuration Management System offering
advanced branching capabilities and atomic changes on 50+ platforms.
Free Eval! http://www.perforce.com/perforce/loadprog.html

RE: Interrupt routing problem

[Yu, Luming]

> Am Di, den 13.01.2004 schrieb Karol Kozimor um 10:00:
> > Thus wrote Yu, Luming:
> > > > (I believe
> > > > there was a patch I tested and found working).
> > > What patch ?
> > I believe it was the one attached below -- my bookmarks 
> went wild some time
> > ago and I can't tell the bugzilla no., but it's certainly there.
> 
> [acpi_hw_enable_ec_gpes() patch]
> I have tested this with 2.4.24 and at least it does no harm ;)
> Since I do not know enough to judge if it is really necessary at least
> from my point of view I would suggest to add it to the general ACPI
> code.

We need to confirm how many hardware has such kind of problems.


-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn

RE: Interrupt routing problem

[Yu, Luming]

> 
> Thus wrote Yu, Luming:
> > > (I believe
> > > there was a patch I tested and found working).
> > 
> > What patch ?
> 
> I believe it was the one attached below -- my bookmarks went 
> wild some time
> ago and I can't tell the bugzilla no., but it's certainly there.

Is it  http://bugme.osdl.org/show_bug.cgi?id=1409#c2 ?


-------------------------------------------------------
This SF.net email is sponsored by: Perforce Software.
Perforce is the Fast Software Configuration Management System offering
advanced branching capabilities and atomic changes on 50+ platforms.
Free Eval! http://www.perforce.com/perforce/loadprog.html

RE: Interrupt routing problem

[Yu, Luming]

> (I believe
> there was a patch I tested and found working).

What patch ?


-------------------------------------------------------
This SF.net email is sponsored by: Perforce Software.
Perforce is the Fast Software Configuration Management System offering
advanced branching capabilities and atomic changes on 50+ platforms.
Free Eval! http://www.perforce.com/perforce/loadprog.html

Re: Interrupt routing problem

[Karol Kozimor]

Thus wrote Yu, Luming:
> > (I believe
> > there was a patch I tested and found working).
> 
> What patch ?

I believe it was the one attached below -- my bookmarks went wild some time
ago and I can't tell the bugzilla no., but it's certainly there.
Best regards,

-- 
Karol 'sziwan' Kozimor
sziwan-DETuoxkZsSqrDJvtcaxF/A@public.gmane.org

diff -Bru linux-2.6.0-test8/drivers/acpi/hardware/hwgpe.c patched/drivers/acpi/hardware/hwgpe.c
--- linux-2.6.0-test8/drivers/acpi/hardware/hwgpe.c     2003-10-18 05:42:53.000000000 +0800
+++ patched/drivers/acpi/hardware/hwgpe.c       2003-10-28 16:30:34.000000000 +0800
@@ -578,3 +578,38 @@

        return (status);
 }
+
+acpi_status
+acpi_hw_enable_ec_gpes(
+       void)
+{
+
+       struct acpi_gpe_block_info      *gpe_block;
+       struct acpi_gpe_event_info      *gpe_event_info;
+       acpi_status                     status = AE_OK;
+       acpi_native_uint                i,j;
+
+       ACPI_FUNCTION_ENTRY ();
+
+       status = acpi_ut_acquire_mutex(ACPI_MTX_EVENTS);
+
+       if(ACPI_FAILURE(status)){
+               return (status);
+       }
+
+       for (i = 0; i < ACPI_MAX_GPE_BLOCKS; i++) {
+               gpe_block = acpi_gbl_gpe_fadt_blocks[i];
+               if (gpe_block) {
+                       for ( j = 0; j < gpe_block->register_count*8; j++){
+                               gpe_event_info= &gpe_block->event_info[j];
+                               if (gpe_event_info->handler &&
+                                               gpe_event_info->context)
+                                       acpi_hw_enable_gpe(gpe_event_info);
+                       }
+               }
+       }
+
+       (void) acpi_ut_release_mutex(ACPI_MTX_EVENTS);
+
+       return (status);
+}
diff -Bru linux-2.6.0-test8/drivers/acpi/hardware/hwsleep.c patched/drivers/acpi/hardware/hwsleep.c
--- linux-2.6.0-test8/drivers/acpi/hardware/hwsleep.c   2003-10-18 05:42:54.000000000 +0800
+++ patched/drivers/acpi/hardware/hwsleep.c     2003-10-24 18:53:10.000000000 +0800
@@ -429,6 +429,9 @@
        if (ACPI_FAILURE (status)) {
                return_ACPI_STATUS (status);
        }
+
+
+       acpi_hw_enable_ec_gpes();

        /* Disable BM arbitration */
        status = acpi_set_register (ACPI_BITREG_ARB_DISABLE, 0, ACPI_MTX_LOCK);
diff -Bru linux-2.6.0-test8/include/acpi/achware.h patched/include/acpi/achware.h
--- linux-2.6.0-test8/include/acpi/achware.h    2003-10-18 05:43:18.000000000 +0800
+++ patched/include/acpi/achware.h      2003-10-24 19:01:17.000000000 +0800
@@ -156,6 +156,9 @@
 acpi_hw_enable_non_wakeup_gpes (
        void);

+acpi_status
+acpi_hw_enable_ec_gpes(
+       void);

 /* ACPI Timer prototypes */




-------------------------------------------------------
This SF.net email is sponsored by: Perforce Software.
Perforce is the Fast Software Configuration Management System offering
advanced branching capabilities and atomic changes on 50+ platforms.
Free Eval! http://www.perforce.com/perforce/loadprog.html

Re: Interrupt routing problem

[Nils Faerber]

Am Di, den 13.01.2004 schrieb Karol Kozimor um 10:00:
> Thus wrote Yu, Luming:
> > > (I believe
> > > there was a patch I tested and found working).
> > What patch ?
> I believe it was the one attached below -- my bookmarks went wild some time
> ago and I can't tell the bugzilla no., but it's certainly there.

[acpi_hw_enable_ec_gpes() patch]
I have tested this with 2.4.24 and at least it does no harm ;)
Since I do not know enough to judge if it is really necessary at least
from my point of view I would suggest to add it to the general ACPI
code.

> Best regards,
CU
  nils faerber

-- 
kernel concepts          Tel: +49-271-771091-12
Dreisbachstr. 24         Fax: +49-271-771091-19
D-57250 Netphen          D1 : +49-170-2729106
--



-------------------------------------------------------
This SF.net email is sponsored by: Perforce Software.
Perforce is the Fast Software Configuration Management System offering
advanced branching capabilities and atomic changes on 50+ platforms.
Free Eval! http://www.perforce.com/perforce/loadprog.html

RE: Interrupt routing problem

[Yu, Luming]

>http://bugme.osdl.org/show_bug.cgi?id=1320#c10
I have a patch http://bugme.osdl.org/show_bug.cgi?id=1661 for this kind
of issue.


-------------------------------------------------------
This SF.net email is sponsored by: Perforce Software.
Perforce is the Fast Software Configuration Management System offering
advanced branching capabilities and atomic changes on 50+ platforms.
Free Eval! http://www.perforce.com/perforce/loadprog.html

Re: Interrupt routing problem

[Karol Kozimor]

Thus wrote Yu, Luming:
> >http://bugme.osdl.org/show_bug.cgi?id=1320#c10
> I have a patch http://bugme.osdl.org/show_bug.cgi?id=1661 for this kind
> of issue.

Well, I remember now. This patch doesn't actually make any difference
(especially that the problem occurs before, not after the suspend).
It doesn't even help for lost ACPI interrupts after S3 resume (I believe
there was a patch I tested and found working).
Best regards,

-- 
Karol 'sziwan' Kozimor
sziwan-DETuoxkZsSqrDJvtcaxF/A@public.gmane.org


-------------------------------------------------------
This SF.net email is sponsored by: Perforce Software.
Perforce is the Fast Software Configuration Management System offering
advanced branching capabilities and atomic changes on 50+ platforms.
Free Eval! http://www.perforce.com/perforce/loadprog.html

RE: Interrupt routing problem

[Yu, Luming]

>strange phenomenons concerning USB with this setup, i.e. devices
>suddenly getting disconnected and reconnected again, HUBs beeing
>disabled altogether, ports being disabled and so on; and yes, using
uhci
>instead of usb-uhci does not help any.

How did you know this is caused by sharing IRQ 9? 

What is the exact failure that causes?


>So my question is if I can "help" my kernel somehow to distribute the
>IRQs in a more clever way.

You can try boot with acpi_irq_balance option.

--Luming


-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id\x1278&alloc_id371&op=click

RE: Interrupt routing problem

[Len Brown]

Nils,

First try acpi=off to completely remove ACPI from the picture.
If the USB issues are still with you, then you know it has nothing to do
with ACPI.

If the USB issues did go away, then there is surely at least an ACPI
related issue, probably an ACPI bug.  If so, try booting with pci=noacpi
to disable ACPI interrupt routing.  without your dmesg I can't tell if
this would have any effect or not, but it may. You'll be able to tell
from a different /proc/interrupts.  But with a PIC-mode box chances are
good that everything will remain piled onto a single IRQ and this will
make no difference.

Depending on your hardware, acpi_irq_balance, perhaps with
acpi_irq_pci=... could distribute some devices off IRQ9.  However, IRQ9
is only the 5th most active entry, so this may not help.

if you were receiving ACPI events with an interrupt-level performance
issue, that could be a cause.  Check /var/log/acpid to see if ACPI
itself is getting any events.

thanks,
-Len

On Sun, 2004-01-04 at 21:17, Yu, Luming wrote:
> >strange phenomenons concerning USB with this setup, i.e. devices
> >suddenly getting disconnected and reconnected again, HUBs beeing
> >disabled altogether, ports being disabled and so on; and yes, using
> uhci
> >instead of usb-uhci does not help any.
> 
> How did you know this is caused by sharing IRQ 9? 
> 
> What is the exact failure that causes?
> 
> 
> >So my question is if I can "help" my kernel somehow to distribute the
> >IRQs in a more clever way.
> 
> You can try boot with acpi_irq_balance option.
> 
> --Luming
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: IBM Linux Tutorials.
> Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
> Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
> Click now! http://ads.osdn.com/?ad_id\x1278&alloc_id371&op=click
> _______________________________________________
> Acpi-devel mailing list
> Acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> https://lists.sourceforge.net/lists/listinfo/acpi-devel



-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click

Re: Interrupt routing problem

[Karol Kozimor]

Thus wrote Len Brown:
> Depending on your hardware, acpi_irq_balance, perhaps with
> acpi_irq_pci=... could distribute some devices off IRQ9.  However, IRQ9
> is only the 5th most active entry, so this may not help.

The problem is that this box's BIOS points all the interrupt links to IRQ9
by default and as far as I remember, neither acpi_irq_pci= nor
acpi_balance_irqs help.
Is the off-one bug in printing IRQs still present?
Best regards,

-- 
Karol 'sziwan' Kozimor
sziwan-DETuoxkZsSqrDJvtcaxF/A@public.gmane.org


-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click

Interrupt routing problem

[Nils Faerber]

Hi!
I think my current ACPI enabled 2.4.23 kernel is doing something IMHO
not so clever concerning interrupt routing:

           CPU0       
  0:      57158          XT-PIC  timer
  1:       2339          XT-PIC  keyboard
  2:          0          XT-PIC  cascade
  5:       2707          XT-PIC  usb-uhci, Ricoh Co Ltd RL5c476 II
  7:          3          XT-PIC  parport0
  8:     194573          XT-PIC  rtc
  9:      12214          XT-PIC  acpi, ohci1394, usb-uhci, eth0, Texas
Instruments PCI1410 PC card Cardbus Controller, orinoco_cs
 11:      61791          XT-PIC  Ricoh Co Ltd RL5c476 II (#2), Intel
ICH3
 12:        134          XT-PIC  PS/2 Mouse
 14:      38295          XT-PIC  ide0
 15:       6607          XT-PIC  ide1

As you can see most devices are routed through IRQ9. I even think that
this is not only ugly but even causes problems. For example I see
strange phenomenons concerning USB with this setup, i.e. devices
suddenly getting disconnected and reconnected again, HUBs beeing
disabled altogether, ports being disabled and so on; and yes, using uhci
instead of usb-uhci does not help any.

So my question is if I can "help" my kernel somehow to distribute the
IRQs in a more clever way.
I can remember that there were some kernel commandline options about
ACPI and PCI interrupt routing (like pci=noacpi or acpi=nopci). Are
those still valid? Would they help?

Oh, BTW, setup summary
	Linux kernel 2.4.23 + swsusp
running on
	Asus notebook L3800C, latest BIOS V1.21

Thanks in advance!
CU
  nils faerber

-- 
kernel concepts          Tel: +49-271-771091-12
Dreisbachstr. 24         Fax: +49-271-771091-19
D-57250 Netphen          D1 : +49-170-2729106
--



-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click