Hi,
I have a problem with 2.6.9-mm1 on an AMD64 NForce3-based box. Namely, after
some time in X, USB suddenly stops working and sound goes off simultaneously
(it's quite annoying, as I use a USB mouse ;-)). It is 100% reproducible and
it may be related to the sharing of IRQ 5:
rafael@albercik:~> cat /proc/interrupts
CPU0
0: 3499292 XT-PIC timer
1: 7135 XT-PIC i8042
2: 0 XT-PIC cascade
5: 6945 XT-PIC NVidia nForce3, ohci_hcd
8: 0 XT-PIC rtc
9: 1416 XT-PIC acpi, yenta
10: 2 XT-PIC ehci_hcd
11: 37266 XT-PIC SysKonnect SK-98xx, yenta, ohci1394, ohci_hcd
12: 13781 XT-PIC i8042
14: 16 XT-PIC ide0
15: 23601 XT-PIC ide1
NMI: 0
LOC: 3498657
ERR: 1
MIS: 0
(NVidia nForce3 is a sound chip, snd_intel8x0). After it happens I can't
reboot the box cleanly (the ohci-hcd driver cannot be reloaded) and it does
not leave any traces in the log.
Please let me know if you need any more information.
Greets,
RJW
--
- Would you tell me, please, which way I ought to go from here?
- That depends a good deal on where you want to get to.
-- Lewis Carroll "Alice's Adventures in Wonderland"
"Rafael J. Wysocki" <[email protected]> wrote:
>
> Hi,
>
> I have a problem with 2.6.9-mm1 on an AMD64 NForce3-based box. Namely, after
> some time in X, USB suddenly stops working and sound goes off simultaneously
> (it's quite annoying, as I use a USB mouse ;-)). It is 100% reproducible and
> it may be related to the sharing of IRQ 5:
>
> rafael@albercik:~> cat /proc/interrupts
> CPU0
> 0: 3499292 XT-PIC timer
> 1: 7135 XT-PIC i8042
> 2: 0 XT-PIC cascade
> 5: 6945 XT-PIC NVidia nForce3, ohci_hcd
> 8: 0 XT-PIC rtc
> 9: 1416 XT-PIC acpi, yenta
> 10: 2 XT-PIC ehci_hcd
> 11: 37266 XT-PIC SysKonnect SK-98xx, yenta, ohci1394, ohci_hcd
> 12: 13781 XT-PIC i8042
> 14: 16 XT-PIC ide0
> 15: 23601 XT-PIC ide1
> NMI: 0
> LOC: 3498657
> ERR: 1
> MIS: 0
>
> (NVidia nForce3 is a sound chip, snd_intel8x0). After it happens I can't
> reboot the box cleanly (the ohci-hcd driver cannot be reloaded) and it does
> not leave any traces in the log.
>
Beats me. Does the interrupt count stop increasing?
Cc for LKML, (damned NNTP client)
On Sat, 23 Oct 2004, Zwane Mwaikambo wrote:
> On Sat, 23 Oct 2004, Andrew Morton wrote:
>
> > "Rafael J. Wysocki" <[email protected]> wrote:
> > >
> > > Hi,
> > >
> > > I have a problem with 2.6.9-mm1 on an AMD64 NForce3-based box. Namely, after
> > > some time in X, USB suddenly stops working and sound goes off simultaneously
> > > (it's quite annoying, as I use a USB mouse ;-)). It is 100% reproducible and
> > > it may be related to the sharing of IRQ 5:
> > >
> > > rafael@albercik:~> cat /proc/interrupts
> > > CPU0
> > > 0: 3499292 XT-PIC timer
> > > 1: 7135 XT-PIC i8042
> > > 2: 0 XT-PIC cascade
> > > 5: 6945 XT-PIC NVidia nForce3, ohci_hcd
> > > 8: 0 XT-PIC rtc
> > > 9: 1416 XT-PIC acpi, yenta
> > > 10: 2 XT-PIC ehci_hcd
> > > 11: 37266 XT-PIC SysKonnect SK-98xx, yenta, ohci1394, ohci_hcd
> > > 12: 13781 XT-PIC i8042
> > > 14: 16 XT-PIC ide0
> > > 15: 23601 XT-PIC ide1
> > > NMI: 0
> > > LOC: 3498657
> > > ERR: 1
> > > MIS: 0
> > >
> > > (NVidia nForce3 is a sound chip, snd_intel8x0). After it happens I can't
> > > reboot the box cleanly (the ohci-hcd driver cannot be reloaded) and it does
> > > not leave any traces in the log.
> > >
> >
> > Beats me. Does the interrupt count stop increasing?
>
> Could we also get a dmesg and lspci? Boot with the 'debug' kernel
> parameter.
On Sunday 24 of October 2004 00:14, Allan Sandfeld Jensen wrote:
> On Friday 22 October 2004 23:54, you wrote:
> > Hi,
> >
> > I have a problem with 2.6.9-mm1 on an AMD64 NForce3-based box. Namely,
> > after some time in X, USB suddenly stops working and sound goes off
> > simultaneously (it's quite annoying, as I use a USB mouse ;-)). It is
100%
> > reproducible and it may be related to the sharing of IRQ 5:
> >
> Have you tried disabling ioapic?
In principle I could, but I have no such problems with the 2.6.9 kernel,
although the APIC etc., settings are the same. Which means there's a
regression and that's the real issue.
Greets,
RJW
--
- Would you tell me, please, which way I ought to go from here?
- That depends a good deal on where you want to get to.
-- Lewis Carroll "Alice's Adventures in Wonderland"
On Friday 22 October 2004 23:54, you wrote:
> Hi,
>
> I have a problem with 2.6.9-mm1 on an AMD64 NForce3-based box. Namely,
> after some time in X, USB suddenly stops working and sound goes off
> simultaneously (it's quite annoying, as I use a USB mouse ;-)). It is 100%
> reproducible and it may be related to the sharing of IRQ 5:
>
Have you tried disabling ioapic?
I also lost a lot of input-related interrupts when I started using 2.6
kernels on my NForce3 laptop. Disabling ioapic was the only thing that has
made it usable.
Seems like Nvidia even in their third try can't wire a correct APIC.
`Allan
On Saturday 23 of October 2004 01:26, you wrote:
> "Rafael J. Wysocki" <[email protected]> wrote:
> >
> > Hi,
> >
> > I have a problem with 2.6.9-mm1 on an AMD64 NForce3-based box. Namely,
after
> > some time in X, USB suddenly stops working and sound goes off
simultaneously
> > (it's quite annoying, as I use a USB mouse ;-)). It is 100% reproducible
and
> > it may be related to the sharing of IRQ 5:
> >
> > rafael@albercik:~> cat /proc/interrupts
> > CPU0
> > 0: 3499292 XT-PIC timer
> > 1: 7135 XT-PIC i8042
> > 2: 0 XT-PIC cascade
> > 5: 6945 XT-PIC NVidia nForce3, ohci_hcd
> > 8: 0 XT-PIC rtc
> > 9: 1416 XT-PIC acpi, yenta
> > 10: 2 XT-PIC ehci_hcd
> > 11: 37266 XT-PIC SysKonnect SK-98xx, yenta, ohci1394,
ohci_hcd
> > 12: 13781 XT-PIC i8042
> > 14: 16 XT-PIC ide0
> > 15: 23601 XT-PIC ide1
> > NMI: 0
> > LOC: 3498657
> > ERR: 1
> > MIS: 0
> >
> > (NVidia nForce3 is a sound chip, snd_intel8x0). After it happens I can't
> > reboot the box cleanly (the ohci-hcd driver cannot be reloaded) and it
does
> > not leave any traces in the log.
> >
>
> Beats me. Does the interrupt count stop increasing?
Yes, it does.
Moreover, 2.6.10-rc1 has this problem too, but here the network adapter
stopped working along with the USB (as you can see above, it shares an IRQ
with the USB too). Also, this time I was able to reload the ohci-hcd module
(it didn't help) and I got these messages:
Oct 23 18:32:23 albercik kernel: ohci_hcd 0000:00:02.0: remove, state 1
Oct 23 18:32:23 albercik kernel: usb usb2: USB disconnect, address 1
Oct 23 18:32:23 albercik kernel: usb 2-2: USB disconnect, address 2
Oct 23 18:32:24 albercik kernel: ohci_hcd 0000:00:02.0: IRQ INTR_SF lossage
Oct 23 18:32:24 albercik kernel: ohci_hcd 0000:00:02.0: USB bus 2 deregistered
Oct 23 18:32:24 albercik kernel: ohci_hcd 0000:00:02.1: remove, state 1
Oct 23 18:32:24 albercik kernel: usb usb3: USB disconnect, address 1
Oct 23 18:32:24 albercik kernel: ohci_hcd 0000:00:02.1: USB bus 3 deregistered
Oct 23 18:32:41 albercik kernel: ohci_hcd: 2004 Feb 02 USB 1.1 'Open' Host
Controller (OHCI) Driver (PCI)
Oct 23 18:32:41 albercik kernel: ACPI: PCI interrupt 0000:00:02.0[A] -> GSI 11
(level, low) -> IRQ 11
Oct 23 18:32:41 albercik kernel: ohci_hcd 0000:00:02.0: nVidia Corporation
nForce3 USB 1.1
Oct 23 18:32:41 albercik kernel: PCI: Setting latency timer of device
0000:00:02.0 to 64
Oct 23 18:32:41 albercik kernel: ohci_hcd 0000:00:02.0: irq 11, pci mem
0xfebfb000
Oct 23 18:32:41 albercik kernel: ohci_hcd 0000:00:02.0: new USB bus
registered, assigned bus number 2
Oct 23 18:32:41 albercik kernel: hub 2-0:1.0: USB hub found
Oct 23 18:32:41 albercik kernel: hub 2-0:1.0: 3 ports detected
Oct 23 18:32:41 albercik kernel: ACPI: PCI interrupt 0000:00:02.1[B] -> GSI 5
(level, low) -> IRQ 5
Oct 23 18:32:41 albercik kernel: ohci_hcd 0000:00:02.1: nVidia Corporation
nForce3 USB 1.1 (#2)
Oct 23 18:32:41 albercik kernel: PCI: Setting latency timer of device
0000:00:02.1 to 64
Oct 23 18:32:41 albercik kernel: ohci_hcd 0000:00:02.1: irq 5, pci mem
0xfebfc000
Oct 23 18:32:41 albercik kernel: ohci_hcd 0000:00:02.1: new USB bus
registered, assigned bus number 3
ct 23 18:32:41 albercik kernel: hub 3-0:1.0: USB hub found
Oct 23 18:32:41 albercik kernel: hub 3-0:1.0: 3 ports detected
Oct 23 18:32:41 albercik kernel: usb 2-2: new low speed USB device using
address 2
Oct 23 18:32:46 albercik kernel: usb 2-2: control timeout on ep0out
Oct 23 18:32:46 albercik kernel: ohci_hcd 0000:00:02.0: Unlink after no-IRQ?
Different ACPI or APIC settings may help.
Oct 23 18:36:04 albercik kernel: Losing some ticks... checking if CPU
frequency changed.
Oct 23 18:37:28 albercik kernel: eth0: network connection down
Oct 23 18:37:40 albercik kernel: eth0: no IPv6 routers present
Oct 23 18:42:45 albercik kernel: Intel ICH 0000:00:06.0: Device was removed
without properly calling pci_disable_device(). This may need fixing.
The "control timeout on ep0out" and "Unlink after no-IRQ?" messages are
puzzling, but the last one is just ridiculous as the box has _nothing_ to do
with Intel.
The .config for 2.6.10-rc1 is available at:
http://www.sisk.pl/kernel/041023/2.6.10-rc1.config
The .config for 2.6.9-mm1 is available at:
http://www.sisk.pl/kernel/041023/2.6.9-mm1.config
The outputs of dmesg and lspci requested by Zwane will follow in a couple of
minutes.
Greets,
RJW
--
- Would you tell me, please, which way I ought to go from here?
- That depends a good deal on where you want to get to.
-- Lewis Carroll "Alice's Adventures in Wonderland"
On Sat, 23 Oct 2004, Rafael J. Wysocki wrote:
> > Beats me. Does the interrupt count stop increasing?
>
> Yes, it does.
>
> Moreover, 2.6.10-rc1 has this problem too, but here the network adapter
> stopped working along with the USB (as you can see above, it shares an IRQ
> with the USB too). Also, this time I was able to reload the ohci-hcd module
> (it didn't help) and I got these messages:
>
> Oct 23 18:32:23 albercik kernel: ohci_hcd 0000:00:02.0: remove, state 1
> Oct 23 18:32:23 albercik kernel: usb usb2: USB disconnect, address 1
> Oct 23 18:32:23 albercik kernel: usb 2-2: USB disconnect, address 2
> Oct 23 18:32:24 albercik kernel: ohci_hcd 0000:00:02.0: IRQ INTR_SF lossage
> Oct 23 18:32:24 albercik kernel: ohci_hcd 0000:00:02.0: USB bus 2 deregistered
> Oct 23 18:32:24 albercik kernel: ohci_hcd 0000:00:02.1: remove, state 1
> Oct 23 18:32:24 albercik kernel: usb usb3: USB disconnect, address 1
> Oct 23 18:32:24 albercik kernel: ohci_hcd 0000:00:02.1: USB bus 3 deregistered
> Oct 23 18:32:41 albercik kernel: ohci_hcd: 2004 Feb 02 USB 1.1 'Open' Host
> Controller (OHCI) Driver (PCI)
> Oct 23 18:32:41 albercik kernel: ACPI: PCI interrupt 0000:00:02.0[A] -> GSI 11
> (level, low) -> IRQ 11
> Oct 23 18:32:41 albercik kernel: ohci_hcd 0000:00:02.0: nVidia Corporation
> nForce3 USB 1.1
> Oct 23 18:32:41 albercik kernel: PCI: Setting latency timer of device
> 0000:00:02.0 to 64
> Oct 23 18:32:41 albercik kernel: ohci_hcd 0000:00:02.0: irq 11, pci mem
> 0xfebfb000
> Oct 23 18:32:41 albercik kernel: ohci_hcd 0000:00:02.0: new USB bus
> registered, assigned bus number 2
> Oct 23 18:32:41 albercik kernel: hub 2-0:1.0: USB hub found
> Oct 23 18:32:41 albercik kernel: hub 2-0:1.0: 3 ports detected
> Oct 23 18:32:41 albercik kernel: ACPI: PCI interrupt 0000:00:02.1[B] -> GSI 5
> (level, low) -> IRQ 5
> Oct 23 18:32:41 albercik kernel: ohci_hcd 0000:00:02.1: nVidia Corporation
> nForce3 USB 1.1 (#2)
> Oct 23 18:32:41 albercik kernel: PCI: Setting latency timer of device
> 0000:00:02.1 to 64
> Oct 23 18:32:41 albercik kernel: ohci_hcd 0000:00:02.1: irq 5, pci mem
> 0xfebfc000
> Oct 23 18:32:41 albercik kernel: ohci_hcd 0000:00:02.1: new USB bus
> registered, assigned bus number 3
> ct 23 18:32:41 albercik kernel: hub 3-0:1.0: USB hub found
> Oct 23 18:32:41 albercik kernel: hub 3-0:1.0: 3 ports detected
> Oct 23 18:32:41 albercik kernel: usb 2-2: new low speed USB device using
> address 2
> Oct 23 18:32:46 albercik kernel: usb 2-2: control timeout on ep0out
> Oct 23 18:32:46 albercik kernel: ohci_hcd 0000:00:02.0: Unlink after no-IRQ?
> Different ACPI or APIC settings may help.
> Oct 23 18:36:04 albercik kernel: Losing some ticks... checking if CPU
> frequency changed.
> Oct 23 18:37:28 albercik kernel: eth0: network connection down
> Oct 23 18:37:40 albercik kernel: eth0: no IPv6 routers present
> Oct 23 18:42:45 albercik kernel: Intel ICH 0000:00:06.0: Device was removed
> without properly calling pci_disable_device(). This may need fixing.
>
> The "control timeout on ep0out" and "Unlink after no-IRQ?" messages are
> puzzling, but the last one is just ridiculous as the box has _nothing_ to do
> with Intel.
That's probably the nforce3 audio device which is an intel part.
>
> The .config for 2.6.10-rc1 is available at:
> http://www.sisk.pl/kernel/041023/2.6.10-rc1.config
> The .config for 2.6.9-mm1 is available at:
> http://www.sisk.pl/kernel/041023/2.6.9-mm1.config
>
> The outputs of dmesg and lspci requested by Zwane will follow in a couple of
> minutes.
Thanks,
Zwane
On Sat, 23 Oct 2004, Rafael J. Wysocki wrote:
> > Could we also get a dmesg and lspci? Boot with the 'debug' kernel
> > parameter.
>
> Attached, for both 2.6.9-mm1 and 2.6.10-rc1.
Could you boot 2.6.10-rc1 with the 'noapic' kernel parameter and you may
as well remove that pci=routeirq parameter, then send dmesg. Something
appears hosed with respect to IOAPIC setup and i think ACPI is having
trouble doing the fallback to PIC mode.
Thanks,
Zwane
On Sunday 24 of October 2004 18:27, Zwane Mwaikambo wrote:
> On Sat, 23 Oct 2004, Rafael J. Wysocki wrote:
>
> > > Could we also get a dmesg and lspci? Boot with the 'debug' kernel
> > > parameter.
> >
> > Attached, for both 2.6.9-mm1 and 2.6.10-rc1.
>
> Could you boot 2.6.10-rc1 with the 'noapic' kernel parameter and you may
> as well remove that pci=routeirq parameter, then send dmesg. Something
> appears hosed with respect to IOAPIC setup and i think ACPI is having
> trouble doing the fallback to PIC mode.
I booted with noapic and without pci=routeirq, although I think it's still
necessary for suspend. The output of dmesg is attached (well, it's all I can
currently produce - I don't know how to get anything better).
Greets,
RJW
--
- Would you tell me, please, which way I ought to go from here?
- That depends a good deal on where you want to get to.
-- Lewis Carroll "Alice's Adventures in Wonderland"
On Sun, 24 Oct 2004, Rafael J. Wysocki wrote:
> > Could you boot 2.6.10-rc1 with the 'noapic' kernel parameter and you may
> > as well remove that pci=routeirq parameter, then send dmesg. Something
> > appears hosed with respect to IOAPIC setup and i think ACPI is having
> > trouble doing the fallback to PIC mode.
>
> I booted with noapic and without pci=routeirq, although I think it's still
> necessary for suspend.
I think that was an -mm thing only at some point, but it's not in
mainline.
> The output of dmesg is attached (well, it's all I can
> currently produce - I don't know how to get anything better).
So did the system still misbehave? What happened?
Zwane
On Monday 25 of October 2004 16:13, Zwane Mwaikambo wrote:
> On Sun, 24 Oct 2004, Rafael J. Wysocki wrote:
>
> > > Could you boot 2.6.10-rc1 with the 'noapic' kernel parameter and you may
> > > as well remove that pci=routeirq parameter, then send dmesg. Something
> > > appears hosed with respect to IOAPIC setup and i think ACPI is having
> > > trouble doing the fallback to PIC mode.
> >
> > I booted with noapic and without pci=routeirq, although I think it's still
> > necessary for suspend.
>
> I think that was an -mm thing only at some point, but it's not in
> mainline.
Yup. You're right it's not necessary.
>
> > The output of dmesg is attached (well, it's all I can
> > currently produce - I don't know how to get anything better).
>
> So did the system still misbehave? What happened?
So far, so good. The problem has not happened yet, so I think it won't.
Still, I have no such problems with 2.6.9*, although I do not boot them with
noapic ...
Thanks for your help anyway,
RJW
--
- Would you tell me, please, which way I ought to go from here?
- That depends a good deal on where you want to get to.
-- Lewis Carroll "Alice's Adventures in Wonderland"
On Monday 25 of October 2004 16:45, Zwane Mwaikambo wrote:
> On Mon, 25 Oct 2004, Rafael J. Wysocki wrote:
>
> > > So did the system still misbehave? What happened?
> >
> > So far, so good. The problem has not happened yet, so I think it won't.
> > Still, I have no such problems with 2.6.9*, although I do not boot them
with
> > noapic ...
> >
> > Thanks for your help anyway,
>
> Ok, perhaps you shouldn't thank me ;) I actually sortof kinda broke your
> box... The reason why it worked before was because the kernel defaulted to
> disabling the IOAPIC on all nforce3 based systems but we found out that
> most nforce3 systems are actually work with the IOAPIC if we just ignore
> some bogus ACPI BIOS information. Your system happens to be one of the
> more broken ones, i'd actually like to try debug your problem a bit
> further, could you open up a bugzilla entry at bugzilla.kernel.org and
> email me when you're done. In the meantime, just keep booting with
> 'noapic'
OK
The bugzilla entry is at:
http://bugzilla.kernel.org/show_bug.cgi?id=3639
Greets,
RJW
--
- Would you tell me, please, which way I ought to go from here?
- That depends a good deal on where you want to get to.
-- Lewis Carroll "Alice's Adventures in Wonderland"
On Mon, 25 Oct 2004, Rafael J. Wysocki wrote:
> > So did the system still misbehave? What happened?
>
> So far, so good. The problem has not happened yet, so I think it won't.
> Still, I have no such problems with 2.6.9*, although I do not boot them with
> noapic ...
>
> Thanks for your help anyway,
Ok, perhaps you shouldn't thank me ;) I actually sortof kinda broke your
box... The reason why it worked before was because the kernel defaulted to
disabling the IOAPIC on all nforce3 based systems but we found out that
most nforce3 systems are actually work with the IOAPIC if we just ignore
some bogus ACPI BIOS information. Your system happens to be one of the
more broken ones, i'd actually like to try debug your problem a bit
further, could you open up a bugzilla entry at bugzilla.kernel.org and
email me when you're done. In the meantime, just keep booting with
'noapic'
Thanks!
Zwane
On Mon, 25 Oct 2004, Rafael J. Wysocki wrote:
> > Ok, perhaps you shouldn't thank me ;) I actually sortof kinda broke your
> > box... The reason why it worked before was because the kernel defaulted to
> > disabling the IOAPIC on all nforce3 based systems but we found out that
> > most nforce3 systems are actually work with the IOAPIC if we just ignore
> > some bogus ACPI BIOS information. Your system happens to be one of the
> > more broken ones, i'd actually like to try debug your problem a bit
> > further, could you open up a bugzilla entry at bugzilla.kernel.org and
> > email me when you're done. In the meantime, just keep booting with
> > 'noapic'
>
> OK
> The bugzilla entry is at:
> http://bugzilla.kernel.org/show_bug.cgi?id=3639
Thanks Rafael,
We'll work on it from there then.
Zwane