lost interrupts with 2.4.1-rc6 and i875p chipset

lost interrupts with 2.4.1-rc6 and i875p chipset

[Greg Norris]

I recently installed Debian on a new i875P chipset machine, and I'm
seeing frequent "hdX: lost interrupt" messages at the console under
2.4.21-rc6.  The IDE system appears to stall for 5 seconds or so
whenever this occurs (I assume that a reset/resync is occurring), but
then seems to recover.  It's pretty easy to reproduce... any
significant disk activity will trigger the problem.  In particular,
running fsck or copying files off a cdrom will expose the problem
within seconds.

This issue does not occur under 2.4.20.  Both kernels were compiled
using gcc 2.95.4, and no non-kernel modules are in use in either case
(no nvidia module, for instance).  I'd be happy to provide additional
information, if someone can point out what would be helpful.


root@glitch[~]# lspci -i ~adric/pci.ids 
00:00.0 Host bridge: Intel Corp. 82875P Memory Controller Hub (rev 02)
00:01.0 PCI bridge: Intel Corp. 82875P Processor to AGP Controller (rev 02)
00:1d.0 USB Controller: Intel Corp. 82801EB USB (rev 02)
00:1d.1 USB Controller: Intel Corp. 82801EB USB (rev 02)
00:1d.2 USB Controller: Intel Corp. 82801EB USB (rev 02)
00:1d.3 USB Controller: Intel Corp. 82801EB USB (rev 02)
00:1d.7 USB Controller: Intel Corp. 82801EB USB2 (rev 02)
00:1e.0 PCI bridge: Intel Corp. 82801BA/CA/DB/EB PCI Bridge (rev c2)
00:1f.0 ISA bridge: Intel Corp. 82801EB LPC Interface Controller (rev 02)
00:1f.1 IDE interface: Intel Corp. 82801EB Ultra ATA Storage Controller (rev 02)
00:1f.2 IDE interface: Intel Corp. 82801EB Ultra ATA Storage Controller (rev 02)
00:1f.3 SMBus: Intel Corp. 82801EB SMBus Controller (rev 02)
01:00.0 VGA compatible controller: nVidia Corporation NV18 [GeForce4 MX 440 AGP 8x] (rev a2)
02:02.0 Multimedia audio controller: Creative Labs [SB Live! Value] EMU10k1X
02:02.1 Input device controller: Creative Labs [SB Live! Value] Input device controller
02:08.0 Ethernet controller: Intel Corp.: Unknown device 1050 (rev 02)

Re: lost interrupts with 2.4.1-rc6 and i875p chipset

[Alan Cox]

On Maw, 2003-06-03 at 12:15, Greg Norris wrote:
> I recently installed Debian on a new i875P chipset machine, and I'm
> seeing frequent "hdX: lost interrupt" messages at the console under
> 2.4.21-rc6.  The IDE system appears to stall for 5 seconds or so
> whenever this occurs (I assume that a reset/resync is occurring), but
> then seems to recover.  It's pretty easy to reproduce... any
> significant disk activity will trigger the problem.  In particular,
> running fsck or copying files off a cdrom will expose the problem
> within seconds.

Does this occur if you build the kernel without ACPI and without APIC
support ?

Re: lost interrupts with 2.4.1-rc6 and i875p chipset

[dmeyer]

In article <20030603111519.GA23228@glitch.localdomain> you write:
> I recently installed Debian on a new i875P chipset machine, and I'm
> seeing frequent "hdX: lost interrupt" messages at the console under
> 2.4.21-rc6.  The IDE system appears to stall for 5 seconds or so
> whenever this occurs (I assume that a reset/resync is occurring), but
> then seems to recover.  It's pretty easy to reproduce... any
> significant disk activity will trigger the problem.  In particular,
> running fsck or copying files off a cdrom will expose the problem
> within seconds.

I see the same thing with my machine:

$ /sbin/lspci
00:00.0 Host bridge: Intel Corp. 82845G/GL [Brookdale-G] Chipset Host Bridge (rev 03)
00:02.0 VGA compatible controller: Intel Corp. 82845G/GL [Brookdale-G] Chipset Integrated Graphics Device (rev 03)
00:1d.0 USB Controller: Intel Corp. 82801DB USB (Hub #1) (rev 02)
00:1d.1 USB Controller: Intel Corp. 82801DB USB (Hub #2) (rev 02)
00:1d.2 USB Controller: Intel Corp. 82801DB USB (Hub #3) (rev 02)
00:1d.7 USB Controller: Intel Corp. 82801DB USB EHCI Controller (rev 02)
00:1e.0 PCI bridge: Intel Corp. 82801BA/CA/DB PCI Bridge (rev 82)
00:1f.0 ISA bridge: Intel Corp. 82801DB ISA Bridge (LPC) (rev 02)
00:1f.1 IDE interface: Intel Corp. 82801DB ICH4 IDE (rev 02)
00:1f.3 SMBus: Intel Corp. 82801DB SMBus (rev 02)
00:1f.5 Multimedia audio controller: Intel Corp. 82801DB AC'97 Audio (rev 02)
01:04.0 SCSI storage controller: Adaptec AHA-2940U/UW/D / AIC-7881U
01:09.0 Ethernet controller: Broadcom Corporation: Unknown device 4401 (rev 01)

though for me it's more likely to be hitting inn really hard than the
cdrom drive.  Booting with "noapic" fixes it, though obviously at the
cost of losing whatever advantages the APIC provides.

-- 
Dave Meyer
dmeyer@dmeyer.net

Re: lost interrupts with 2.4.1-rc6 and i875p chipset

[dmeyer]

In article <20030603151809.GA23419@jhereg.dmeyer.net> you write:
> I see the same thing with my machine:
> 
> $ /sbin/lspci
> 00:00.0 Host bridge: Intel Corp. 82845G/GL [Brookdale-G] Chipset Host
> Bridge (rev 03)
> 00:02.0 VGA compatible controller: Intel Corp. 82845G/GL [Brookdale-G]
> Chipset Integrated Graphics Device (rev 03)
> 00:1d.0 USB Controller: Intel Corp. 82801DB USB (Hub #1) (rev 02)
> 00:1d.1 USB Controller: Intel Corp. 82801DB USB (Hub #2) (rev 02)
> 00:1d.2 USB Controller: Intel Corp. 82801DB USB (Hub #3) (rev 02)
> 00:1d.7 USB Controller: Intel Corp. 82801DB USB EHCI Controller (rev 02)
> 00:1e.0 PCI bridge: Intel Corp. 82801BA/CA/DB PCI Bridge (rev 82)
> 00:1f.0 ISA bridge: Intel Corp. 82801DB ISA Bridge (LPC) (rev 02)
> 00:1f.1 IDE interface: Intel Corp. 82801DB ICH4 IDE (rev 02)
> 00:1f.3 SMBus: Intel Corp. 82801DB SMBus (rev 02)
> 00:1f.5 Multimedia audio controller: Intel Corp. 82801DB AC'97 Audio (rev 02)
> 01:04.0 SCSI storage controller: Adaptec AHA-2940U/UW/D / AIC-7881U
> 01:09.0 Ethernet controller: Broadcom Corporation: Unknown device 4401 (rev 01)
> 
> though for me it's more likely to be hitting inn really hard than the
> cdrom drive.  Booting with "noapic" fixes it, though obviously at the
> cost of losing whatever advantages the APIC provides.

Followup to this:  with 2.4.21-rc7-ac1, I get very different
behavior.  If I boot with noapic, my machine goes into an endless loop
of

   APIC error on CPU0: 40(40)

errors.  If I boot regularly (APIC enabled), everything is fine.  My
machine has been up for almost a full day without a single lost
interrupt message.  This, BTW, is with ACPI enabled in both cases.

-- 
Dave Meyer
dmeyer@dmeyer.net

Re: lost interrupts with 2.4.1-rc6 and i875p chipset

[Greg Norris]

On Sat, Jun 07, 2003 at 03:20:08PM -0400, dmeyer@dmeyer.net wrote:
> Followup to this:  with 2.4.21-rc7-ac1, I get very different
> behavior.  If I boot with noapic, my machine goes into an endless loop
> of
> 
>    APIC error on CPU0: 40(40)
> 
> errors.  If I boot regularly (APIC enabled), everything is fine.  My
> machine has been up for almost a full day without a single lost
> interrupt message.  This, BTW, is with ACPI enabled in both cases.

It looks like -ac1 works for me with apic enabled as well.  I haven't
tried rebooting with noapic yet,,,

Re: lost interrupts with 2.4.21-rc6 and i875p chipset

[Greg Norris]

> Does this occur if you build the kernel without ACPI and without APIC
> support ?

After a bit of experimenting with pre7, I found that I only need to
disable IOAPIC (ACPI was already disabled).  Thanx for the pointer!


   $ grep APIC config_glitch.apic.2
   CONFIG_X86_GOOD_APIC=y
   CONFIG_X86_UP_APIC=y
   # CONFIG_X86_UP_IOAPIC is not set
   CONFIG_X86_LOCAL_APIC=y

Re: lost interrupts with 2.4.21 and i875p chipset -- resolved (maybe)

[Greg Norris]

On Tue, Jun 03, 2003 at 06:43:59PM -0500, Greg Norris wrote:
> > Does this occur if you build the kernel without ACPI and without APIC
> > support ?
>
> I just finished testing rc7, and sure enough the problem disappears
> after disabling APIC.  Thanx!

I built a SMP kernel earlier today (in order to enable hyperthreading),
and discovered that the lost interrupt problem appears to have gone
away.  In addition, dmesg no longer shows any "unexpected IO-APIC"
messages.  The only configuration changes from the previous kernel are:

   CONFIG_SMP=y
   CONFIG_ACPI=y
   CONFIG_ACPI_BUSMGR=y
   CONFIG_ACPI_CPU=y

I guess that the next step is to disable hyperthreading in the BIOS,
and see if the UP kernel still has problems.