Disabling IRQ #11

[Bill Shannon]

James Wilkinson wrote:
>>From linux/Documentation/kernel-parameters.txt:
>         nousb           [USB] Disable the USB subsystem
>         noacpi          [IA-32] Do not use ACPI for IRQ routing
>                         or for PCI scanning.
> 
>         acpi=           [HW,ACPI] Advanced Configuration and Power Interface
>                         Format: { force | off | ht | strict }
>                         force -- enable ACPI if default was off
>                         off -- disable ACPI if default was on
>                         noirq -- do not use ACPI for IRQ routing
>                         ht -- run only enough ACPI to enable Hyper Threading
>                         strict --  Be less tolerant of platforms that are not
>                                 strictly ACPI specification compliant.
>  
>                         See also Documentation/pm.txt, pci=noacpi

I tried:

kernel /vmlinuz-2.6.8-1.521 ro root=LABEL=/  hdd=ide-scsi acpi=off pci=noacpi noapic

I don't know what ACPI and APIC are, or what the difference is between them,
and I wasn't sure which people were recommending, so I tried both.

It made no difference.

> It might also be worth temporarily disabling both sound and networking:
> try commenting out the appropriate lines in /etc/modprobe.conf or
> setting alias sound off.

I disabled sound in the BIOS.  Made no difference.

I disabled ethernet in the BIOS.  The system hung coming up when it
tried to start sendmail.

Just a reminder, I can reproduce this easily as follows...

I try to login through the GUI login screen to a test account that has
no special dot files.  The login hangs after putting up the "metacity"
icon.  I login from another machine using ssh and kill gnome-session.
That kills the hung login but also immediately displays the "Disabling
IRQ #11" message in my ssh window.  The GUI login screen continues to
function and I can use it to reboot the system.

Disabling acpi and turning off all sorts of things related to IRQ #11
doesn't seem to make any difference.

Is it time to report a bug?

> It might *also* be worth playing with kernel.org kernels.

I'll wait for Fedora Core 3 before wasting time doing that.