On Fri, 16 Jun 2000, David Brownell wrote:
> > > Actually, since Miles provided separate information about the
> > > controller's real address (0xc5882000) which isn't the one
> > > provided through the URB (0xc5880000), it's clear that some
> > > pointer in the "urb->bus->dev->hcpriv" sequence used to get
> > > that pointer (hcpriv) became bogus ...
> >
> > Didn't Miles say in his last mail that both Addresses are equal?
> > (0xc5882000)
>
> I may have missed some e-mail, pacbell has been darn poor lately.
>
> Actually he said to me that they weren't (in one letter) but
> in the full log he sent, I see they are ... I'm thinking that
> his controller address is changing between runs, just to cause
> maximal confusion!!
Yes. It seems that is what's happening.
> Jun 16 08:57:14 agate kernel: usb-ohci.c: USB OHCI at membase 0xc5872000,
> IRQ 11
> Jun 16 08:57:14 agate kernel: usb-ohci.c: PCI device 1045:c861
> ...
> Jun 16 08:58:28 agate kernel: usb-storage.c: *** thread sleeping.
> Jun 16 08:58:50 agate kernel: usb-ohci.c: USB suspend: c5872000
> Jun 16 08:58:50 agate kernel: usb-ohci.c: rh_send_irq given bogus
> controller address c5872000
> Jun 16 08:59:04 agate last message repeated 5 times
> Jun 16 08:59:05 agate kernel: usb-ohci.c: USB resume: c5872000
> Jun 16 08:59:05 agate kernel: usb-ohci.c: rh_send_irq given bogus
> controller address c5872000
> Jun 16 08:59:06 agate last message repeated 2 times
> ...
> Jun 16 08:59:07 agate kernel: PCI: Enabling device 03:00.0 (0000 -> 0002)
> Jun 16 08:59:07 agate kernel: PCI: Found IRQ 11 for device 03:00.0
> Jun 16 08:59:07 agate kernel: PCI: The same IRQ used for device 00:04.0
> Jun 16 09:01:33 agate kernel: spurious 8259A interrupt: IRQ7.
>
>
> OK, so this new information suggests something else is happening.
>
> Could the timer be getting fired while PCI address mappings
> need to be re-established? (I can't see any other reason why
> a timer call would cause any trouble in this sequence, since
> evidently both memory and the OHCI controller retained power,
> so there's no state that'd have been lost.)
>
> I'm not sure the significance of the messages about IRQ 11,
> which is used by the USB controller, except that it suggests
> experiments where that IRQ isn't shared.
I have these two options enabled in my kernel build:
CONFIG_IDEPCI_SHARE_IRQ=y
CONFIG_SERIAL_SHARE_IRQ=y
Also, these messages seem to indicate that the cardbus controller
is sharing IRQ 11 for both cardbus slots:
Jun 16 08:26:13 agate kernel: Linux PCMCIA Card Services 3.1.11
Jun 16 08:26:13 agate kernel: options: [pci] [cardbus] [pm]
Jun 16 08:26:13 agate kernel: Adding cardbus controller 0: Texas
Instruments PCI1131
Jun 16 08:26:13 agate kernel: PCI: Enabling device 00:04.0 (0000 -> 0002)
Jun 16 08:26:13 agate kernel: PCI: Assigned IRQ 11 for device 00:04.0
Jun 16 08:26:14 agate kernel: Yenta IRQ list 0698, PCI irq11
Jun 16 08:26:14 agate kernel: Socket status: 30000010
Jun 16 08:26:14 agate kernel: Adding cardbus controller 1: Texas
Instruments PCI1131 (#2)
Jun 16 08:26:14 agate kernel: PCI: Enabling device 00:04.1 (0000 -> 0002)
Jun 16 08:26:15 agate kernel: PCI: Assigned IRQ 11 for device 00:04.1
Jun 16 08:26:15 agate kernel: Yenta IRQ list 0698, PCI irq11
Jun 16 08:26:15 agate kernel: Socket status: 30000020
Jun 16 08:26:16 agate kernel: cs: cb_alloc(bus 3): vendor 0x1045, device
0xc861
Jun 16 08:26:16 agate kernel: PCI: Enabling device 03:00.0 (0000 -> 0002)
Jun 16 08:26:16 agate kernel: PCI: Found IRQ 11 for device 03:00.0
Jun 16 08:26:16 agate kernel: PCI: The same IRQ used for device 00:04.0
Jun 16 08:57:14 agate kernel: PCI: Setting latency timer of device 03:00.0
to 64
> Miles, what does your /proc/interrupts say about irq11? In
> fact, all of the irqs ... can you do something to avoid such
> sharing? I boot with "pci=biosirq", maybe turning that on or
> off would shuffle those assignments enough to try this.
Here's /proc/interrupts:
0: 2723485 XT-PIC timer
1: 12026 XT-PIC keyboard
2: 0 XT-PIC cascade
3: 42967 XT-PIC serial
5: 528 XT-PIC CS4232
11: 426 XT-PIC Texas Instruments PCI1131, Texas
Instruments PCI1131 (#2), usb-ohci
12: 11260 XT-PIC PS/2 Mouse
13: 1 XT-PIC fpu
14: 19196 XT-PIC ide0
15: 3 XT-PIC ide1
NMI: 0
ERR: 1
Just for good measure, here's "lspci -v":
les@agate /proc]$ lspci -v
00:00.0 Host bridge: Intel Corporation 440BX/ZX - 82443BX/ZX Host bridge
(AGP disabled) (rev 02)
Flags: bus master, medium devsel, latency 64
Memory at <unassigned> (32-bit, prefetchable) [size=64M]
00:02.0 VGA compatible controller: Neomagic Corporation NM2160 [MagicGraph
128XD] (rev 01) (prog-if 00 [VGA])
Subsystem: Dell Computer Corporation: Unknown device 007e
Flags: bus master, medium devsel, latency 128
Memory at fd000000 (32-bit, prefetchable) [size=16M]
Memory at fea00000 (32-bit, non-prefetchable) [size=2M]
Memory at fed00000 (32-bit, non-prefetchable) [size=1M]
00:04.0 CardBus bridge: Texas Instruments PCI1131 (rev 01)
Subsystem: Dell Computer Corporation: Unknown device 007e
Flags: bus master, medium devsel, latency 168, IRQ 11
Memory at 10000000 (32-bit, non-prefetchable) [size=4K]
Bus: primary=00, secondary=01, subordinate=01, sec-latency=176
Memory window 0: 10400000-107ff000 (prefetchable)
Memory window 1: 10800000-10bff000
I/O window 0: 00001000-000010ff
I/O window 1: 00000000-00000003
16-bit legacy interface ports at 0001
00:04.1 CardBus bridge: Texas Instruments PCI1131 (rev 01)
Subsystem: Dell Computer Corporation: Unknown device 007e
Flags: bus master, medium devsel, latency 168, IRQ 11
Memory at 10001000 (32-bit, non-prefetchable) [size=4K]
Bus: primary=00, secondary=03, subordinate=03, sec-latency=176
Memory window 0: 10c00000-10fff000 (prefetchable)
Memory window 1: 11000000-113ff000
I/O window 0: 00001400-000014ff
I/O window 1: 00000000-00000003
16-bit legacy interface ports at 0001
00:07.0 Bridge: Intel Corporation 82371AB PIIX4 ISA (rev 02)
Flags: bus master, medium devsel, latency 0
00:07.1 IDE interface: Intel Corporation 82371AB PIIX4 IDE (rev
01) (prog-if 80 [Master])
Flags: bus master, medium devsel, latency 64
I/O ports at fcf0 [size=16]
00:07.2 USB Controller: Intel Corporation 82371AB PIIX4 USB (rev
01) (prog-if 00 [UHCI])
Flags: medium devsel
I/O ports at fcc0 [disabled] [size=32]
00:07.3 Bridge: Intel Corporation 82371AB PIIX4 ACPI (rev 02)
Flags: medium devsel
03:00.0 USB Controller: OPTi Inc. 82C861 (rev 10) (prog-if 10 [OHCI])
Subsystem: OPTi Inc.: Unknown device c861
Flags: medium devsel, IRQ 11
Memory at 11000000 (32-bit, non-prefetchable) [size=4K]
> Hmm ... OK, more info. Is this using APM, or ACPI? Is it
> possible to switch to the other, and still reproduce this?
> ACPI has given me no happiness whatsoever, though ymmv.
I am currently using APM. Here are my Power Management options:
CONFIG_PM=y
CONFIG_APM=y
CONFIG_APM_DO_ENABLE=y
CONFIG_APM_CPU_IDLE=y
CONFIG_APM_ALLOW_INTS=y
CONFIG_APM_REAL_MODE_POWER_OFF=y
Possible bugaboos might be something to do with the CONFIG_APM_ALLOW_INTS
or the CONFIG_APM_CPU_IDLE options being enabled.
I'm not sure what we'd learn from my attempting to use ACPI.
ACPI seems to still be in the pre-alpha or alpha stage.
Hope this helps,
Miles
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
