* yenta_socket rapid fires interrupts @ 2005-01-10 17:33 DHollenbeck 2005-01-10 19:24 ` Alan Cox 2005-01-11 3:17 ` Linus Torvalds 0 siblings, 2 replies; 16+ messages in thread From: DHollenbeck @ 2005-01-10 17:33 UTC (permalink / raw) To: linux-kernel Please help me troubleshoot a problem with 2.6.10-ac5 i386 on embedded pentium 266MHz problem. The same problem exists with a 2.6.7 and 2.6.9 kernel. I am currently testing against 2.6.10-ac5. The problem I think is in the yenta_socket driver, which in my case is configured as a module. I have two CARDBUS slots. If the slots are empty when loading yenta_socket, then no problem loading the module. However, when I have a "CARDBUS to USB 2.0 Hi-Speed Adapter" installed at the time of modprobe yenta_socket, I get a problem, shown below. The same problem occurs if the Adapter is inserted after the yenta module is loaded. That is, load the yenta_socket module: no problem, then physically insert the Adapter: same problem. This same Adapter card works fine in a different pentium shoebox computer using the same kernel and root file system as the "problem embedded pentium" system, but with a different CARDBUS chipset. So I do not suspect the card. Wild guess: perhaps the Adapter card is powering up in a mode to rapid fire interrupts because this CARDBUS chipset is not initialized correctly? Sequence of states and actions: root@EMBEDDED[~]# uname -a Linux EMBEDDED 2.6.10-ac5 #12 Fri Jan 7 15:41:15 CST 2005 i586 unknown root@EMBEDDED[~]# lsmod Module Size Used by md5 2944 1 ipv6 184704 6 natsemi 17760 0 root@EMBEDDED[~]# cat /proc/interrupts CPU0 0: 84342 XT-PIC timer 2: 0 XT-PIC cascade 4: 162 XT-PIC serial 8: 0 XT-PIC rtc 9: 329 XT-PIC eth0 14: 8245 XT-PIC ide0 NMI: 0 LOC: 0 ERR: 0 MIS: 0 root@EMBEDDED[~]# modprobe yenta_socket root@EMBEDDED[~]# dmesg Linux version 2.6.10-ac5 (dick@DicksAMD) (gcc version 3.4.1) #12 Fri Jan 7 15:41:15 CST 2005 BIOS-provided physical RAM map: BIOS-e820: 0000000000000000 - 000000000009fc00 (usable) BIOS-e820: 0000000000100000 - 0000000002000000 (usable) user-defined physical RAM map: user: 0000000000000000 - 000000000009fc00 (usable) user: 0000000000100000 - 0000000002000000 (usable) 32MB LOWMEM available. On node 0 totalpages: 8192 DMA zone: 4096 pages, LIFO batch:1 Normal zone: 4096 pages, LIFO batch:1 HighMem zone: 0 pages, LIFO batch:1 DMI not present. Built 1 zonelists Kernel command line: ro irqpoll root=/dev/hda1 console=ttyS0,38400 TERM=vt100 platform=routerboard mem=32768K Misrouted IRQ fixup and polling support enabled. This may significantly impact system performance. No local APIC present or hardware disabled mapped APIC to ffffd000 (01041000) Initializing CPU#0 PID hash table entries: 256 (order: 8, 4096 bytes) Detected 266.771 MHz processor. Using tsc for high-res timesource Console: colour dummy device 80x25 Dentry cache hash table entries: 8192 (order: 3, 32768 bytes) Inode-cache hash table entries: 4096 (order: 2, 16384 bytes) Memory: 29376k/32768k available (1635k kernel code, 2956k reserved, 603k data, 140k init, 0k highmem) Checking if this processor honours the WP bit even in supervisor mode... Ok. Calibrating delay loop... 491.52 BogoMIPS (lpj=245760) Mount-cache hash table entries: 512 (order: 0, 4096 bytes) CPU: After generic identify, caps: 00808131 01818131 00000000 00000000 CPU: After vendor identify, caps: 00808131 01818131 00000000 00000000 CPU: After all inits, caps: 00808131 00818131 00000000 00000001 CPU: NSC Unknown stepping 01 Checking 'hlt' instruction... OK. NET: Registered protocol family 16 PCI: PCI BIOS revision 2.10 entry at 0xf7870, last bus=1 PCI: Using configuration type 1 PCI: Probing PCI hardware PCI: Probing PCI hardware (bus 00) PCI: Using IRQ router NatSemi [100b/0510] at 0000:00:12.0 Initializing Cryptographic API Real Time Clock Driver v1.12 i8042.c: Can't read CTR while initializing i8042. Serial: 8250/16550 driver $Revision: 1.90 $ 76 ports, IRQ sharing enabled ttyS0 at I/O 0x3f8 (irq = 4) is a NS16550A io scheduler noop registered elevator: using noop as default io scheduler floppy0: no floppy controllers found loop: loaded (max 8 devices) Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2 ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx Probing IDE interface ide0... hda: SAMSUNG CF/ATA, CFA DISK drive Probing IDE interface ide1... ide1: Wait for ready failed before probe ! ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 hda: max request size: 128KiB hda: 126976 sectors (65 MB) w/1KiB Cache, CHS=496/8/32 hda: cache flushes not supported hda: hda1 NFTL driver: nftlcore.c $Revision: 1.97 $, nftlmount.c $Revision: 1.39 $ No valid DiskOnChip devices found mice: PS/2 mouse device common for all mice NET: Registered protocol family 2 IP: routing cache hash table of 512 buckets, 4Kbytes TCP: Hash tables configured (established 2048 bind 4096) ip_tables: (C) 2000-2002 Netfilter core team NET: Registered protocol family 1 NET: Registered protocol family 17 hda: hda1 EXT3-fs: INFO: recovery required on readonly filesystem. EXT3-fs: write access will be enabled during recovery. kjournald starting. Commit interval 5 seconds EXT3-fs: recovery complete. EXT3-fs: mounted filesystem with ordered data mode. VFS: Mounted root (ext3 filesystem) readonly. Freeing unused kernel memory: 140k freed EXT3 FS on hda1, internal journal natsemi dp8381x driver, version 1.07+LK1.0.17, Sep 27, 2002 originally by Donald Becker <becker@scyld.com> http://www.scyld.com/network/natsemi.html 2.4.x kernel port by Jeff Garzik, Tjeerd Mulder PCI: Found IRQ 9 for device 0000:00:0b.0 natsemi eth0: NatSemi DP8381[56] at 0xfebf7000 (0000:00:0b.0), 00:0c:42:03:1b:59, IRQ 9, port TP. PCI: Found IRQ 10 for device 0000:00:0c.0 natsemi eth1: NatSemi DP8381[56] at 0xfebf8000 (0000:00:0c.0), 00:0c:42:03:1b:5a, IRQ 10, port TP. eth0: DSPCFG accepted after 0 usec. eth0: link up. eth0: Setting full-duplex based on negotiated link capability. NET: Registered protocol family 10 Disabled Privacy Extensions on device c031bd60(lo) IPv6 over IPv4 tunneling driver eth0: no IPv6 routers present Linux Kernel Card Services options: [pci] [cardbus] PCI: Found IRQ 11 for device 0000:00:0d.0 PCI: Sharing IRQ 11 with 0000:00:0d.1 Yenta: CardBus bridge found at 0000:00:0d.0 [0000:0000] Yenta: Enabling burst memory read transactions Yenta: Using CSCINT to route CSC interrupts to PCI Yenta: Routing CardBus interrupts to PCI Yenta TI: socket 0000:00:0d.0, mfunc 0x00001022, devctl 0x64 Yenta: ISA IRQ mask 0x00a8, PCI irq 11 Socket status: 30000020 PCI: Found IRQ 11 for device 0000:00:0d.1 PCI: Sharing IRQ 11 with 0000:00:0d.0 Yenta: CardBus bridge found at 0000:00:0d.1 [0000:0000] Yenta: Using CSCINT to route CSC interrupts to PCI Yenta: Routing CardBus interrupts to PCI Yenta TI: socket 0000:00:0d.1, mfunc 0x00001022, devctl 0x64 Yenta: ISA IRQ mask 0x00a8, PCI irq 11 Socket status: 30000006 irq 11: nobody cared (try booting with the "irqpoll" option. [<c0127362>] [<c0127468>] [<c0126e89>] [<c010481a>] [<c01031ea>] [<c012007b>] [<c0126d59>] [<c0126e55>] [<c010481a>] [<c01031ea>] [<c012007b>] [<c0115d70>] [<c0120060>] [<c0115e15>] [<c010481f>] [<c01031ea>] [<c01005f0>] [<c0100613>] [<c010068c>] [<c0332737>] handlers: [<c2837930>] [<c2837930>] Disabling IRQ #11 <------------------------------------------------------- !!@@ OUCH @@!! root@EMBEDDED[~]# lspci -vnn 00:00.0 Class 0600: 1078:0001 Flags: bus master, medium devsel, latency 0 00:0b.0 Class 0200: 100b:0020 Subsystem: 100b:0020 Flags: bus master, medium devsel, latency 64, IRQ 9 I/O ports at 1000 [size=256] Memory at febf7000 (32-bit, non-prefetchable) [size=4K] Expansion ROM at <unassigned> [disabled] [size=64K] Capabilities: [40] Power Management version 2 00:0c.0 Class 0200: 100b:0020 Subsystem: 100b:0020 Flags: bus master, medium devsel, latency 64, IRQ 10 I/O ports at 1400 [size=256] Memory at febf8000 (32-bit, non-prefetchable) [size=4K] Expansion ROM at <unassigned> [disabled] [size=64K] Capabilities: [40] Power Management version 2 00:0d.0 Class 0607: 104c:ac55 (rev 01) Flags: bus master, medium devsel, latency 168, IRQ 11 Memory at febf9000 (32-bit, non-prefetchable) [size=4K] Bus: primary=00, secondary=01, subordinate=04, sec-latency=176 Memory window 0: 10000000-103ff000 (prefetchable) Memory window 1: 10400000-107ff000 I/O window 0: 00004000-000040ff I/O window 1: 00004400-000044ff 16-bit legacy interface ports at 0001 00:0d.1 Class 0607: 104c:ac55 (rev 01) Flags: bus master, medium devsel, latency 168, IRQ 11 Memory at febfa000 (32-bit, non-prefetchable) [size=4K] Bus: primary=00, secondary=05, subordinate=08, sec-latency=176 Memory window 0: 10800000-10bff000 (prefetchable) Memory window 1: 10c00000-10fff000 I/O window 0: 00004800-000048ff I/O window 1: 00004c00-00004cff 16-bit legacy interface ports at 0001 00:12.0 Class 0601: 100b:0510 Subsystem: 100b:0500 Flags: bus master, medium devsel, latency 4 I/O ports at 1c00 [size=64] I/O ports at 1c40 [size=64] 00:12.1 Class 0680: 100b:0511 Subsystem: 100b:0501 Flags: medium devsel I/O ports at 1800 [size=256] 00:12.2 Class 0101: 100b:0502 (rev 01) (prog-if 80 [Master]) Subsystem: 100b:0502 Flags: bus master, medium devsel, latency 0 I/O ports at 1cc0 [size=16] 00:12.3 Class 0401: 100b:0503 Subsystem: 100b:0503 Flags: bus master, medium devsel, latency 0 Memory at febfb000 (32-bit, non-prefetchable) [size=4K] 00:12.4 Class 0300: 100b:0514 (rev 01) Subsystem: 100b:0504 Flags: medium devsel Memory at febfc000 (32-bit, non-prefetchable) [size=4K] Memory at febfd000 (32-bit, non-prefetchable) [size=4K] Memory at febfe000 (32-bit, non-prefetchable) [size=4K] Expansion ROM at <unassigned> [disabled] 00:12.5 Class 0680: 100b:0515 Subsystem: 100b:0505 Flags: medium devsel I/O ports at 1c80 [size=64] 00:13.0 Class 0c03: 0e11:a0f8 (rev 08) (prog-if 10) Subsystem: 0e11:a0f8 Flags: medium devsel, IRQ 12 Memory at febff000 (32-bit, non-prefetchable) [size=4K] 01:00.0 Class 0c03: 10b9:5237 (rev 03) (prog-if 10) Subsystem: 10b9:5237 Flags: 66Mhz, medium devsel, IRQ 11 Memory at 10400000 (32-bit, non-prefetchable) [disabled] [size=4K] Capabilities: [60] Power Management version 2 01:00.3 Class 0c03: 10b9:5239 (rev 01) (prog-if 20) Subsystem: 10b9:5272 Flags: 66Mhz, medium devsel, IRQ 11 Memory at 10401000 (32-bit, non-prefetchable) [disabled] [size=256] Capabilities: [50] Power Management version 2 Capabilities: [58] #0a [2090] root@EMBEDDED[~]# cat /proc/interrupts CPU0 0: 541666 XT-PIC timer 2: 0 XT-PIC cascade 4: 162 XT-PIC serial 8: 0 XT-PIC rtc 9: 1133 XT-PIC eth0 11: 98681 XT-PIC yenta, yenta 14: 8443 XT-PIC ide0 NMI: 0 LOC: 0 ERR: 0 MIS: 0 root@EMBEDDED[~]# --------------- kernel paramters irqpoll and apic options had no effect. Bitte, was ist? Dick Hollenbeck -- Please help fix the U.S. software industry before it is too late. Contact your U.S. representatives with this information: http://lpf.ai.mit.edu/Patents/industry-at-risk.html http://www.groklaw.net/article.php?story=20041003041632172 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: yenta_socket rapid fires interrupts 2005-01-10 17:33 yenta_socket rapid fires interrupts DHollenbeck @ 2005-01-10 19:24 ` Alan Cox 2005-01-11 3:17 ` Linus Torvalds 1 sibling, 0 replies; 16+ messages in thread From: Alan Cox @ 2005-01-10 19:24 UTC (permalink / raw) To: DHollenbeck; +Cc: Linux Kernel Mailing List On Llu, 2005-01-10 at 17:33, DHollenbeck wrote: > However, when I have a "CARDBUS to USB 2.0 Hi-Speed Adapter" installed > at the time of modprobe yenta_socket, I get a problem, shown below. The > same problem occurs if the Adapter is inserted after the yenta module is > loaded. That is, load the yenta_socket module: no problem, then > physically insert the Adapter: same problem. Do other cardbus cards work on this machine ? I'd expect to see 1000 interrupts/second or so off a running USB controller with devices (or thinking ithas devices) but no more. > Bitte, was ist? Sa i'n sŵr ;) Alan ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: yenta_socket rapid fires interrupts 2005-01-10 17:33 yenta_socket rapid fires interrupts DHollenbeck 2005-01-10 19:24 ` Alan Cox @ 2005-01-11 3:17 ` Linus Torvalds 2005-01-11 19:18 ` DHollenbeck 1 sibling, 1 reply; 16+ messages in thread From: Linus Torvalds @ 2005-01-11 3:17 UTC (permalink / raw) To: DHollenbeck; +Cc: linux-kernel On Mon, 10 Jan 2005, DHollenbeck wrote: > > However, when I have a "CARDBUS to USB 2.0 Hi-Speed Adapter" installed > at the time of modprobe yenta_socket, I get a problem, shown below. Can you compile the kernel with kallsyms info? That would make the output a whole lot more readable. > The same problem occurs if the Adapter is inserted after the yenta > module is loaded. That is, load the yenta_socket module: no problem, > then physically insert the Adapter: same problem. Can you test with another type of card, just to see if it is specific to that particular driver, or it happens with any card insertion event? > This same Adapter card works fine in a different pentium shoebox > computer using the same kernel and root file system as the "problem > embedded pentium" system, but with a different CARDBUS chipset. It's entirely possible that they have different behaviours for screaming interrupts and/or just different setup. > irq 11: nobody cared (try booting with the "irqpoll" option. > [<c0127362>] > .... > handlers: > [<c2837930>] > [<c2837930>] I can't tell what your handlers are, but there are two of them, and they are the same, which makes me strongly suspect that it's just the two "yenta_socket" handlers for the two slots (sharing the same interrupt). Which implies that when the card was inserted and powered on, it started enabling the interrupt early, before the low-level driver had had a chance to register _its_ interrupt handler. > 01:00.0 Class 0c03: 10b9:5237 (rev 03) (prog-if 10) > Subsystem: 10b9:5237 > Flags: 66Mhz, medium devsel, IRQ 11 > Memory at 10400000 (32-bit, non-prefetchable) [disabled] [size=4K] > Capabilities: [60] Power Management version 2 > > 01:00.3 Class 0c03: 10b9:5239 (rev 01) (prog-if 20) > Subsystem: 10b9:5272 > Flags: 66Mhz, medium devsel, IRQ 11 > Memory at 10401000 (32-bit, non-prefetchable) [disabled] [size=256] > Capabilities: [50] Power Management version 2 > Capabilities: [58] #0a [2090] Hmm. That would be "PCI_CLASS_SERIAL_USB", but clearly: > root@EMBEDDED[~]# cat /proc/interrupts > CPU0 > 11: 98681 XT-PIC yenta, yenta No USB driver there, so the driver never even loaded. The problem probably happened immediately on card insertion, and is likely card-indepdendent. But it would be nice to have that confirmed by testing. It seems to be a TI 1520 chipset: 00:0d.0 Class 0607: 104c:ac55 (rev 01) Yenta: CardBus bridge found at 0000:00:0d.0 [0000:0000] Yenta: Enabling burst memory read transactions Yenta: Using CSCINT to route CSC interrupts to PCI Yenta: Routing CardBus interrupts to PCI Yenta TI: socket 0000:00:0d.0, mfunc 0x00001022, devctl 0x64 Yenta: ISA IRQ mask 0x00a8, PCI irq 11 Socket status: 30000020 and everything looks good in that the interrupt probing seems to have been happy at this stage - so at least the CSC interrupt is working right. There used to be somebody who knew the TI chips on the list - I've only worked with the older ones. But everything _looks_ fine. Linus ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: yenta_socket rapid fires interrupts 2005-01-11 3:17 ` Linus Torvalds @ 2005-01-11 19:18 ` DHollenbeck 2005-01-11 19:46 ` Grzegorz Kulewski 2005-01-11 19:54 ` Linus Torvalds 0 siblings, 2 replies; 16+ messages in thread From: DHollenbeck @ 2005-01-11 19:18 UTC (permalink / raw) To: Linus Torvalds, linux-kernel, Alan Cox, magnus.damm Linus Torvalds wrote: >On Mon, 10 Jan 2005, DHollenbeck wrote: > > >>However, when I have a "CARDBUS to USB 2.0 Hi-Speed Adapter" installed >>at the time of modprobe yenta_socket, I get a problem, shown below. >> >> > >Can you compile the kernel with kallsyms info? That would make the output >a whole lot more readable. > > > first, load the following two modules modprobe ehci_hcd, then modprobe yenta_socket then a dmesg extract, now with kallsyms: usbcore: registered new driver usbfs usbcore: registered new driver hub Linux Kernel Card Services options: [pci] [cardbus] PCI: Found IRQ 11 for device 0000:00:0d.0 PCI: Sharing IRQ 11 with 0000:00:0d.1 Yenta: CardBus bridge found at 0000:00:0d.0 [0000:0000] Yenta: Enabling burst memory read transactions Yenta: Using CSCINT to route CSC interrupts to PCI Yenta: Routing CardBus interrupts to PCI Yenta TI: socket 0000:00:0d.0, mfunc 0x00001022, devctl 0x64 Yenta: ISA IRQ mask 0x00a8, PCI irq 11 Socket status: 30000006 PCI: Found IRQ 11 for device 0000:00:0d.1 PCI: Sharing IRQ 11 with 0000:00:0d.0 Yenta: CardBus bridge found at 0000:00:0d.1 [0000:0000] Yenta: Using CSCINT to route CSC interrupts to PCI Yenta: Routing CardBus interrupts to PCI Yenta TI: socket 0000:00:0d.1, mfunc 0x00001022, devctl 0x64 Yenta: ISA IRQ mask 0x00a8, PCI irq 11 Socket status: 30000020 irq 11: nobody cared (try booting with the "irqpoll" option. [<c012b752>] __report_bad_irq+0x22/0x90 [<c012b868>] note_interrupt+0x78/0xc0 [<c012b11d>] __do_IRQ+0x13d/0x160 [<c0104aba>] do_IRQ+0x1a/0x30 [<c010337a>] common_interrupt+0x1a/0x20 [<c012007b>] sys_getresgid+0xb/0xa0 [<c0117750>] __do_softirq+0x30/0xa0 [<c0120060>] sys_setresgid+0x120/0x130 [<c01177f5>] do_softirq+0x35/0x40 [<c012af65>] irq_exit+0x35/0x40 [<c0104abf>] do_IRQ+0x1f/0x30 [<c010337a>] common_interrupt+0x1a/0x20 [<c01005b0>] default_idle+0x0/0x40 [<c038007b>] ic_setup_if+0xcb/0xd0 [<c01005d3>] default_idle+0x23/0x40 [<c010064c>] cpu_idle+0x1c/0x50 [<c036873c>] start_kernel+0x13c/0x160 handlers: [<c2842930>] (yenta_interrupt+0x0/0x40 [yenta_socket]) [<c2842930>] (yenta_interrupt+0x0/0x40 [yenta_socket]) Disabling IRQ #11 PCI: Enabling device 0000:05:00.3 (0000 -> 0002) ehci_hcd 0000:05:00.3: ALi Corporation USB 2.0 Controller ehci_hcd 0000:05:00.3: irq 11, pci mem 0x10c01000 ehci_hcd 0000:05:00.3: new USB bus registered, assigned bus number 1 ehci_hcd 0000:05:00.3: USB 2.0 initialized, EHCI 1.00, driver 26 Oct 2004 hub 1-0:1.0: USB hub found hub 1-0:1.0: 2 ports detected root@EMBEDDED[~]# cat /proc/interrupts CPU0 0: 263041 XT-PIC timer 2: 0 XT-PIC cascade 4: 163 XT-PIC serial 8: 0 XT-PIC rtc 9: 584 XT-PIC eth0 11: 100000 XT-PIC yenta, yenta, ehci_hcd 14: 8631 XT-PIC ide0 NMI: 0 LOC: 0 ERR: 0 MIS: 0 root@EMBEDDED[~]# >>The same problem occurs if the Adapter is inserted after the yenta >>module is loaded. That is, load the yenta_socket module: no problem, >>then physically insert the Adapter: same problem. >> >> > >Can you test with another type of card, just to see if it is specific to >that particular driver, or it happens with any card insertion event? > > > Yes, a PRISM54 PCMCIA (WL54G) card seems to work in the slot. With it : root@SHOEBOX[~]# cat /proc/interrupts CPU0 0: 2890965 XT-PIC timer 2: 0 XT-PIC cascade 4: 925 XT-PIC serial 8: 0 XT-PIC rtc 9: 3715 XT-PIC eth0 10: 5 XT-PIC eth1 11: 92 XT-PIC yenta, yenta, eth2 12: 0 XT-PIC ohci_hcd 14: 11812 XT-PIC ide0 NMI: 0 ERR: 0 IRQ 11 is showing 92 interrupts, vs. 100000 when the USB 2.0 Adapter card is in the slot instead of the Prism54 card. Here is the USB Adapter card: http://link-depot.com/pcb-u22.html >>This same Adapter card works fine in a different pentium shoebox >>computer using the same kernel and root file system as the "problem >>embedded pentium" system, but with a different CARDBUS chipset. >> >> > >It's entirely possible that they have different behaviours for screaming >interrupts and/or just different setup. > > > >>irq 11: nobody cared (try booting with the "irqpoll" option. >> [<c0127362>] >>.... >>handlers: >>[<c2837930>] >>[<c2837930>] >> >> > >I can't tell what your handlers are, but there are two of them, and they >are the same, which makes me strongly suspect that it's just the two >"yenta_socket" handlers for the two slots (sharing the same interrupt). > >Which implies that when the card was inserted and powered on, it started >enabling the interrupt early, before the low-level driver had had a chance >to register _its_ interrupt handler. > > > >>01:00.0 Class 0c03: 10b9:5237 (rev 03) (prog-if 10) >> Subsystem: 10b9:5237 >> Flags: 66Mhz, medium devsel, IRQ 11 >> Memory at 10400000 (32-bit, non-prefetchable) [disabled] [size=4K] >> Capabilities: [60] Power Management version 2 >> >>01:00.3 Class 0c03: 10b9:5239 (rev 01) (prog-if 20) >> Subsystem: 10b9:5272 >> Flags: 66Mhz, medium devsel, IRQ 11 >> Memory at 10401000 (32-bit, non-prefetchable) [disabled] [size=256] >> Capabilities: [50] Power Management version 2 >> Capabilities: [58] #0a [2090] >> >> > >Hmm. That would be "PCI_CLASS_SERIAL_USB", but clearly: > > Yes, in addition to the CARDBUS slots, into which I want to insert this card: http://link-depot.com/pcb-u22.html there is also an onboard USB support, but not 2.0 USB. > > >>root@EMBEDDED[~]# cat /proc/interrupts >> CPU0 >> 11: 98681 XT-PIC yenta, yenta >> >> > >No USB driver there, so the driver never even loaded. The problem probably >happened immediately on card insertion, and is likely card-indepdendent. >But it would be nice to have that confirmed by testing. > > The console dumps from my original posting were done without first loading ehci_hcd. Today you can see above ehci_hcd was loaded first, but this does not fix the problem. Thank you! ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: yenta_socket rapid fires interrupts 2005-01-11 19:18 ` DHollenbeck @ 2005-01-11 19:46 ` Grzegorz Kulewski 2005-01-11 19:54 ` Linus Torvalds 1 sibling, 0 replies; 16+ messages in thread From: Grzegorz Kulewski @ 2005-01-11 19:46 UTC (permalink / raw) To: DHollenbeck; +Cc: Linus Torvalds, linux-kernel, Alan Cox, magnus.damm On Tue, 11 Jan 2005, DHollenbeck wrote: > Linus Torvalds wrote: > >> On Mon, 10 Jan 2005, DHollenbeck wrote: >> >> >>> However, when I have a "CARDBUS to USB 2.0 Hi-Speed Adapter" installed at >>> the time of modprobe yenta_socket, I get a problem, shown below. >>> >>> >> >> Can you compile the kernel with kallsyms info? That would make the output a >> whole lot more readable. >> >> >> > first, load the following two modules > > modprobe ehci_hcd, then > modprobe yenta_socket > > then a dmesg extract, now with kallsyms: > > usbcore: registered new driver usbfs > usbcore: registered new driver hub > Linux Kernel Card Services > options: [pci] [cardbus] > PCI: Found IRQ 11 for device 0000:00:0d.0 > PCI: Sharing IRQ 11 with 0000:00:0d.1 > Yenta: CardBus bridge found at 0000:00:0d.0 [0000:0000] > Yenta: Enabling burst memory read transactions > Yenta: Using CSCINT to route CSC interrupts to PCI > Yenta: Routing CardBus interrupts to PCI > Yenta TI: socket 0000:00:0d.0, mfunc 0x00001022, devctl 0x64 > Yenta: ISA IRQ mask 0x00a8, PCI irq 11 > Socket status: 30000006 > PCI: Found IRQ 11 for device 0000:00:0d.1 > PCI: Sharing IRQ 11 with 0000:00:0d.0 > Yenta: CardBus bridge found at 0000:00:0d.1 [0000:0000] > Yenta: Using CSCINT to route CSC interrupts to PCI > Yenta: Routing CardBus interrupts to PCI > Yenta TI: socket 0000:00:0d.1, mfunc 0x00001022, devctl 0x64 > Yenta: ISA IRQ mask 0x00a8, PCI irq 11 > Socket status: 30000020 > irq 11: nobody cared (try booting with the "irqpoll" option. > [<c012b752>] __report_bad_irq+0x22/0x90 > [<c012b868>] note_interrupt+0x78/0xc0 > [<c012b11d>] __do_IRQ+0x13d/0x160 > [<c0104aba>] do_IRQ+0x1a/0x30 > [<c010337a>] common_interrupt+0x1a/0x20 > [<c012007b>] sys_getresgid+0xb/0xa0 > [<c0117750>] __do_softirq+0x30/0xa0 > [<c0120060>] sys_setresgid+0x120/0x130 > [<c01177f5>] do_softirq+0x35/0x40 > [<c012af65>] irq_exit+0x35/0x40 > [<c0104abf>] do_IRQ+0x1f/0x30 > [<c010337a>] common_interrupt+0x1a/0x20 > [<c01005b0>] default_idle+0x0/0x40 > [<c038007b>] ic_setup_if+0xcb/0xd0 > [<c01005d3>] default_idle+0x23/0x40 > [<c010064c>] cpu_idle+0x1c/0x50 > [<c036873c>] start_kernel+0x13c/0x160 > handlers: > [<c2842930>] (yenta_interrupt+0x0/0x40 [yenta_socket]) > [<c2842930>] (yenta_interrupt+0x0/0x40 [yenta_socket]) > Disabling IRQ #11 > PCI: Enabling device 0000:05:00.3 (0000 -> 0002) > ehci_hcd 0000:05:00.3: ALi Corporation USB 2.0 Controller > ehci_hcd 0000:05:00.3: irq 11, pci mem 0x10c01000 > ehci_hcd 0000:05:00.3: new USB bus registered, assigned bus number 1 > ehci_hcd 0000:05:00.3: USB 2.0 initialized, EHCI 1.00, driver 26 Oct 2004 > hub 1-0:1.0: USB hub found > hub 1-0:1.0: 2 ports detected > > > root@EMBEDDED[~]# cat /proc/interrupts > CPU0 > 0: 263041 XT-PIC timer > 2: 0 XT-PIC cascade > 4: 163 XT-PIC serial > 8: 0 XT-PIC rtc > 9: 584 XT-PIC eth0 > 11: 100000 XT-PIC yenta, yenta, ehci_hcd > 14: 8631 XT-PIC ide0 > NMI: 0 > LOC: 0 > ERR: 0 > MIS: 0 > root@EMBEDDED[~]# I think that this is not this card problem. I have laptop (x86_64 - Acer Aspire 1524 WLMI) with yenta and usb 2.0 (onboard not cardbus). It has yenta and USB on the same IRQ (11 too). When I try to load USB module (even with yenta removed from /lib/modules) I get similar problem. I hacked it somehow - probably disabling ACPI and maybe APIC, and passing tons of strange options to the kernel (and maybe even compiling only usb 1.1 support in? - I do not remember - I was in hurry to get my mouse working before Xmas...) But I will bet that ACPI has something to this. I believe I described this problem (offlist) in mail to Greg KH, but I got no response (maybe it didn't get there?). I can post this mail to the list if you think you need it. There were some details like my logs, my configurations etc. BTW. Does anybody knows why APIC on this laptop sends my (onboard) Realtek 1000 Mbps network card to IRQ 169 or something like that (of course making it unusable until reboot with noapic)??? Thanks, Grzegorz Kulewski ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: yenta_socket rapid fires interrupts 2005-01-11 19:18 ` DHollenbeck 2005-01-11 19:46 ` Grzegorz Kulewski @ 2005-01-11 19:54 ` Linus Torvalds 2005-01-11 21:16 ` DHollenbeck 2005-01-11 21:38 ` DHollenbeck 1 sibling, 2 replies; 16+ messages in thread From: Linus Torvalds @ 2005-01-11 19:54 UTC (permalink / raw) To: DHollenbeck; +Cc: linux-kernel, Alan Cox, magnus.damm On Tue, 11 Jan 2005, DHollenbeck wrote: > > then a dmesg extract, now with kallsyms: Ok, that wasn't very interesting ;) If anything, it does show that the interrupt doesn't happen at any "enable device" point, which in turn would tend to indicate that it's not some Linux device initialization that brings on the interrupts storm: it really looks like it is the act of inserting this particular card that makes the hardware start to act up. Which means that I agree with you: it's something specific to the initialization of the TI CardBus bridge. Exactly what, I have no friggin clue. Some incorrect state initialization for interrupts for that particular board. > handlers: > [<c2842930>] (yenta_interrupt+0x0/0x40 [yenta_socket]) > [<c2842930>] (yenta_interrupt+0x0/0x40 [yenta_socket]) > Disabling IRQ #11 > PCI: Enabling device 0000:05:00.3 (0000 -> 0002) > ehci_hcd 0000:05:00.3: ALi Corporation USB 2.0 Controller > ehci_hcd 0000:05:00.3: irq 11, pci mem 0x10c01000 > ehci_hcd 0000:05:00.3: new USB bus registered, assigned bus number 1 > ehci_hcd 0000:05:00.3: USB 2.0 initialized, EHCI 1.00, driver 26 Oct 2004 > hub 1-0:1.0: USB hub found > hub 1-0:1.0: 2 ports detected .. but clearly the card is _seen_. I assume that this is the USB controller card that you just inserted. Everything looks good, except for the fact that the damn interrupt storm started. > >Can you test with another type of card, just to see if it is specific to > >that particular driver, or it happens with any card insertion event? > > Yes, a PRISM54 PCMCIA (WL54G) card seems to work in the slot. With it : Uhhuh. Both look like proper CardBus cards, so this isn't even some "16-bit card works fine, 32-bit does not". > The console dumps from my original posting were done without first > loading ehci_hcd. Today you can see above ehci_hcd was loaded first, > but this does not fix the problem. No, but it shows that the card is recognized, and the yenta subsystem works fine _except_ for the fact that it for some reason results in tons of interrupts. Can you add a "printk()" to "yenta_events()" that shows the value of both "csc" and "cb_event", and additionally shows CB_STATUS. Something like the appended (and totally untested) patch.. It's going to be very noisy when the problem happens (you'll see 10000 lines scroll by very quickly), but it would be good to see what the last lines were. Just to see if some event/state seems stuck.. Linus ===== drivers/pcmcia/yenta_socket.c 1.65 vs edited ===== --- 1.65/drivers/pcmcia/yenta_socket.c 2004-12-01 00:14:04 -08:00 +++ edited/drivers/pcmcia/yenta_socket.c 2005-01-11 11:52:10 -08:00 @@ -401,7 +401,7 @@ static unsigned int yenta_events(struct yenta_socket *socket) { u8 csc; - u32 cb_event; + u32 cb_event, cb_state; unsigned int events; /* Clear interrupt status for the event */ @@ -409,6 +409,9 @@ cb_writel(socket, CB_SOCKET_EVENT, cb_event); csc = exca_readb(socket, I365_CSC); + + cb_state = cb_readl(socket, CB_SOCKET_STATE); + printk("yenta: event %08x state %08x csc %02x\n", cb_event, cb_state, csc); events = (cb_event & (CB_CD1EVENT | CB_CD2EVENT)) ? SS_DETECT : 0 ; events |= (csc & I365_CSC_DETECT) ? SS_DETECT : 0; ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: yenta_socket rapid fires interrupts 2005-01-11 19:54 ` Linus Torvalds @ 2005-01-11 21:16 ` DHollenbeck 2005-01-11 21:40 ` Linus Torvalds 2005-01-11 21:38 ` DHollenbeck 1 sibling, 1 reply; 16+ messages in thread From: DHollenbeck @ 2005-01-11 21:16 UTC (permalink / raw) To: Linus Torvalds; +Cc: linux-kernel, Alan Cox, magnus.damm Linus Torvalds wrote: >Can you add a "printk()" to "yenta_events()" that shows the value of both >"csc" and "cb_event", and additionally shows CB_STATUS. Something like >the appended (and totally untested) patch.. > >It's going to be very noisy when the problem happens (you'll see 10000 >lines scroll by very quickly), but it would be good to see what the last >lines were. Just to see if some event/state seems stuck.. > > Linus > >===== drivers/pcmcia/yenta_socket.c 1.65 vs edited ===== >--- 1.65/drivers/pcmcia/yenta_socket.c 2004-12-01 00:14:04 -08:00 >+++ edited/drivers/pcmcia/yenta_socket.c 2005-01-11 11:52:10 -08:00 >@@ -401,7 +401,7 @@ > static unsigned int yenta_events(struct yenta_socket *socket) > { > u8 csc; >- u32 cb_event; >+ u32 cb_event, cb_state; > unsigned int events; > > /* Clear interrupt status for the event */ >@@ -409,6 +409,9 @@ > cb_writel(socket, CB_SOCKET_EVENT, cb_event); > > csc = exca_readb(socket, I365_CSC); >+ >+ cb_state = cb_readl(socket, CB_SOCKET_STATE); >+ printk("yenta: event %08x state %08x csc %02x\n", cb_event, cb_state, csc); > > events = (cb_event & (CB_CD1EVENT | CB_CD2EVENT)) ? SS_DETECT : 0 ; > events |= (csc & I365_CSC_DETECT) ? SS_DETECT : 0; > > > TI 1520 data sheet URL: http://www-s.ti.com/sc/ds/pci1520.pdf output from printk: only the last several lines were caught. There is toggling between two states, the very first state was not captured. : : yenta: event 00000000 state 30000006 csc 00 yenta: event 00000000 state 30000829 csc 00 yenta: event 00000000 state 30000006 csc 00 yenta: event 00000000 state 30000829 csc 00 yenta: event 00000000 state 30000006 csc 00 yenta: event 00000000 state 30000829 csc 00 yenta: event 00000000 state 30000006 csc 00 yenta: event 00000000 state 30000829 csc 00 : : : yenta: event 00000000 state 30000006 csc 00 yenta: event 00000000 state 30000829 csc 00 yenta: event 00000000 state 30000006 csc 00 yenta: event 00000000 state 30000829 csc 00 yenta: event 00000000 state 30000006 csc 00 yenta: event 00000000 state 30000829 csc 00 yenta: event 00000000 state 30000006 csc 00 yenta: event 00000000 state 30000829 csc 00 yenta: event 00000000 state 30000006 csc 00 yenta: event 00000000 state 30000829 csc 00 yenta: event 00000000 state 30000006 csc 00 yenta: event 00000000 state 30000829 csc 00 yenta: event 00000000 state 30000006 csc 00 yenta: event 00000000 state 30000829 csc 00 yenta: event 00000000 state 30000006 csc 00 yenta: event 00000000 state 30000829 csc 00 yenta: event 00000000 state 30000006 csc 00 yenta: event 00000000 state 30000829 csc 00 irq 11: nobody cared (try booting with the "irqpoll" option. [<c012b752>] __report_bad_irq+0x22/0x90 [<c012b868>] note_interrupt+0x78/0xc0 [<c012b11d>] __do_IRQ+0x13d/0x160 [<c0104aba>] do_IRQ+0x1a/0x30 [<c010337a>] common_interrupt+0x1a/0x20 [<c012af99>] handle_IRQ_event+0x29/0x70 [<c012b0b1>] __do_IRQ+0xd1/0x160 [<c0104aba>] do_IRQ+0x1a/0x30 [<c010337a>] common_interrupt+0x1a/0x20 [<c012007b>] sys_getresgid+0xb/0xa0 [<c0117750>] __do_softirq+0x30/0xa0 [<c0120060>] sys_setresgid+0x120/0x130 [<c01177f5>] do_softirq+0x35/0x40 [<c012af65>] irq_exit+0x35/0x40 [<c0104abf>] do_IRQ+0x1f/0x30 [<c010337a>] common_interrupt+0x1a/0x20 [<c01005b0>] default_idle+0x0/0x40 [<c038007b>] ic_setup_if+0xcb/0xd0 [<c01005d3>] default_idle+0x23/0x40 [<c010064c>] cpu_idle+0x1c/0x50 [<c036873c>] start_kernel+0x13c/0x160 handlers: [<c2838950>] (yenta_interrupt+0x0/0x40 [yenta_socket]) [<c2838950>] (yenta_interrupt+0x0/0x40 [yenta_socket]) Disabling IRQ #11 I can read bits in a datasheet, but their meaning in the context of this driver is better interpreted by somebody with more PCMCIA experience than me. Thanks for your help! ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: yenta_socket rapid fires interrupts 2005-01-11 21:16 ` DHollenbeck @ 2005-01-11 21:40 ` Linus Torvalds 2005-01-13 14:13 ` Stefan Seyfried 0 siblings, 1 reply; 16+ messages in thread From: Linus Torvalds @ 2005-01-11 21:40 UTC (permalink / raw) To: DHollenbeck; +Cc: linux-kernel, Alan Cox, magnus.damm On Tue, 11 Jan 2005, DHollenbeck wrote: > > only the last several lines were caught. There is toggling between two > states, the very first state was not captured. That's fine. This is interesting: > yenta: event 00000000 state 30000006 csc 00 30000006 means (apart from the socket voltage information) "CB_CDETECT1 | CB_CDETECT2", which just means that a socket detect is pending. > yenta: event 00000000 state 30000829 csc 00 And this means "CB_CARDSTS | CB_PWRCYCLE | CB_CBCARD | CB_3VCARD", ie that it's become ready, powered, 32-bit card at 3.3V. Goodie. Everything looks fine, as far as I can tell. But then something makes it back to detect pending again: > yenta: event 00000000 state 30000006 csc 00 and it bounces between those two states forever. That certainly would seem to explain why you get a lot of interrupts, except the actual "event" flags are never set, so afaik it wasn't actually this yenta controller that sent those events in the first place. In fact, at no point would "yenta_events()" have returned non-zero, which is why the Yenta driver says "this interrupt was not for me". What I don't see is why the port changes state, then. Since the yenta driver doesn't care for the interrupt anyway, it shouldn't be touching the hardware, and if it doesn't touch the hardware, then the pcmcia thing should eventually just calm down, even if it were to de-bounce a few times. The above is what you'd likely see if somebody was forcing a reset on the card or a card voltage re-interrogation all the time, which I don't see why it would happen. Can you change the "#if 0" at top of yenta_socket.c (around the debug thing), into a "#if 1"? That will make it _really_ noisy and totally unusable, but since it's unusable already.. I'd like to see what the accesses are in a full "cycle" of those bounces. And don't worry about capturing the whole log - the only thing that I'm interested in is one full cycle (from likely 5000 of them - since every other interrupt is in the reset state, and every other is PWRCYCLE). Linus ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: yenta_socket rapid fires interrupts 2005-01-11 21:40 ` Linus Torvalds @ 2005-01-13 14:13 ` Stefan Seyfried 2005-01-13 15:42 ` DHollenbeck 2005-01-13 15:59 ` DHollenbeck 0 siblings, 2 replies; 16+ messages in thread From: Stefan Seyfried @ 2005-01-13 14:13 UTC (permalink / raw) To: Linus Torvalds; +Cc: linux-kernel, Alan Cox, magnus.damm, DHollenbeck Linus Torvalds wrote: > What I don't see is why the port changes state, then. Since the yenta > driver doesn't care for the interrupt anyway, it shouldn't be touching the > hardware, and if it doesn't touch the hardware, then the pcmcia thing > should eventually just calm down, even if it were to de-bounce a few > times. > > The above is what you'd likely see if somebody was forcing a reset on the > card or a card voltage re-interrogation all the time, which I don't see > why it would happen. i have a "feeling" that a weak power supply or a little bit too high current draw from the card may cause something like this. But this is just what i wrote: a feeling from my stomach ;-) Stefan ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: yenta_socket rapid fires interrupts 2005-01-13 14:13 ` Stefan Seyfried @ 2005-01-13 15:42 ` DHollenbeck 2005-01-13 15:59 ` DHollenbeck 1 sibling, 0 replies; 16+ messages in thread From: DHollenbeck @ 2005-01-13 15:42 UTC (permalink / raw) To: Stefan Seyfried; +Cc: Linus Torvalds, linux-kernel, Alan Cox, magnus.damm Stefan Seyfried wrote: > Linus Torvalds wrote: > >> What I don't see is why the port changes state, then. Since the yenta >> driver doesn't care for the interrupt anyway, it shouldn't be >> touching the hardware, and if it doesn't touch the hardware, then the >> pcmcia thing should eventually just calm down, even if it were to >> de-bounce a few times. >> >> The above is what you'd likely see if somebody was forcing a reset on >> the >> card or a card voltage re-interrogation all the time, which I don't see >> why it would happen. > > > i have a "feeling" that a weak power supply or a little bit too high > current draw from the card may cause something like this. But this is > just what i wrote: a feeling from my stomach ;-) > > Stefan > I tested the card in a different, more beefy box, namely a shoebox PC, whereas the problem box is one with an external power supply coming in via cable. In the shoebox PC the card works fine. In the shoebox, this problem CARDBUS card (CARDBUS to USB 2.0 adapter) is running on a PCI card, which is a separate "PCI to CARDBUS" PCI card. The PCI card has a PCI_DEVICE_ID_RICOH_RL5C475 part, which is under control of the yenta_socket driver just fine. So the "problem USB 2.0 adapter card" works OK with yenta_socket.c from 2.6.10 on the RICOH cardbus chip. The problem is with the TI1520 chip in the embedded machine on the embedded motherboard. What we do not know is if the problem is with: 1) TI1520 chip/yenta combo, or 2) embedded PC/power supply Any last gasping ideas? Thank you all again, Dick ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: yenta_socket rapid fires interrupts 2005-01-13 14:13 ` Stefan Seyfried 2005-01-13 15:42 ` DHollenbeck @ 2005-01-13 15:59 ` DHollenbeck 1 sibling, 0 replies; 16+ messages in thread From: DHollenbeck @ 2005-01-13 15:59 UTC (permalink / raw) To: Stefan Seyfried; +Cc: Linus Torvalds, linux-kernel, Alan Cox, magnus.damm More info comes. The embedded system has a single PCI slot. So I tried the PCI card with the RICOH CARDBUS support on it in the embedded system, and plugged in the problem CARDBUS card into the RICOH board before powering up. This is analogous to the case before, when the motherboard resident TI1520 chip was in play. Now the system can load yenta_socket fine. So it is definitely not a power supply _capacity_ issue, although I suppose it could be power availability timing issue. This experiment tends to put more doubt into the TI1520 chip and the yenta support for it. Dick ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: yenta_socket rapid fires interrupts 2005-01-11 19:54 ` Linus Torvalds 2005-01-11 21:16 ` DHollenbeck @ 2005-01-11 21:38 ` DHollenbeck 2005-01-11 21:43 ` Linus Torvalds 1 sibling, 1 reply; 16+ messages in thread From: DHollenbeck @ 2005-01-11 21:38 UTC (permalink / raw) To: Linus Torvalds; +Cc: linux-kernel, Alan Cox, magnus.damm Add to my last post, the information that IRQ 11 is only being used by the two yenta sockets. So the "toggling" is not really toggling, but the printing of the two card sockets which are both on the same IRQ? root@EMBEDDED[~]# cat /proc/interrupts CPU0 0: 4039920 XT-PIC timer 2: 0 XT-PIC cascade 4: 167 XT-PIC serial 8: 0 XT-PIC rtc 9: 1633 XT-PIC eth0 11: 100000 XT-PIC yenta, yenta 14: 11209 XT-PIC ide0 NMI: 0 LOC: 0 ERR: 0 MIS: 0 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: yenta_socket rapid fires interrupts 2005-01-11 21:38 ` DHollenbeck @ 2005-01-11 21:43 ` Linus Torvalds 2005-01-11 22:32 ` DHollenbeck 0 siblings, 1 reply; 16+ messages in thread From: Linus Torvalds @ 2005-01-11 21:43 UTC (permalink / raw) To: DHollenbeck; +Cc: linux-kernel, Alan Cox, magnus.damm On Tue, 11 Jan 2005, DHollenbeck wrote: > > Add to my last post, the information that IRQ 11 is only being used by > the two yenta sockets. So the "toggling" is not really toggling, but the > printing of the two card sockets which are both on the same IRQ? Ahh. Good catch, silly me. No toggling, so you can ignore my last post. There's no cycle going on, and the ports are stable, and the interrupt is coming from somewhere else entirely. You could still enable debugging, but at that point I'd actually be interested in the _first_ part of the debug output, not the long tail of dead interrupts. You'd need a serial console or netconsole to catch it, I'm afraid. Linus ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: yenta_socket rapid fires interrupts 2005-01-11 21:43 ` Linus Torvalds @ 2005-01-11 22:32 ` DHollenbeck 2005-01-12 0:03 ` Linus Torvalds 0 siblings, 1 reply; 16+ messages in thread From: DHollenbeck @ 2005-01-11 22:32 UTC (permalink / raw) To: Linus Torvalds; +Cc: linux-kernel, Alan Cox, magnus.damm Linus Torvalds wrote: >On Tue, 11 Jan 2005, DHollenbeck wrote: > > >>Add to my last post, the information that IRQ 11 is only being used by >>the two yenta sockets. So the "toggling" is not really toggling, but the >>printing of the two card sockets which are both on the same IRQ? >> >> > >Ahh. Good catch, silly me. No toggling, so you can ignore my last post. >There's no cycle going on, and the ports are stable, and the interrupt is >coming from somewhere else entirely. > >You could still enable debugging, but at that point I'd actually be >interested in the _first_ part of the debug output, not the long tail of >dead interrupts. You'd need a serial console or netconsole to catch it, >I'm afraid. > > Linus > > > My modfied, throw away, debug patch: --- linux/drivers/pcmcia/yenta_socket..orig 2004-12-24 15:35:00.000000000 -0600 +++ linux/drivers/pcmcia/yenta_socket.c 2005-01-11 16:16:47.000000000 -0600 @@ -401,7 +401,7 @@ static unsigned int yenta_events(struct yenta_socket *socket) { u8 csc; - u32 cb_event; + u32 cb_event, intctl; unsigned int events; /* Clear interrupt status for the event */ @@ -412,13 +412,31 @@ events = (cb_event & (CB_CD1EVENT | CB_CD2EVENT)) ? SS_DETECT : 0 ; events |= (csc & I365_CSC_DETECT) ? SS_DETECT : 0; - if (exca_readb(socket, I365_INTCTL) & I365_PC_IOCARD) { + if ( (intctl=exca_readb(socket, I365_INTCTL)) & I365_PC_IOCARD) { events |= (csc & I365_CSC_STSCHG) ? SS_STSCHG : 0; } else { events |= (csc & I365_CSC_BVD1) ? SS_BATDEAD : 0; events |= (csc & I365_CSC_BVD2) ? SS_BATWARN : 0; events |= (csc & I365_CSC_READY) ? SS_READY : 0; } + +/* RHH: per Linus */ +#if 1 + { + u32 cb_state; + + static int intCount = 20; + + if( intCount > 0 ) + { + --intCount; + cb_state = cb_readl(socket, CB_SOCKET_STATE); + printk("yenta: event %08x state %08x csc %02x intctl %02x events=%08x\n", + cb_event, cb_state, csc, intctl, events ); + } + } +#endif + return events; } And the dmesg output. Please look at intctl. Is this our unsatisfied noise maker? Linux Kernel Card Services options: [pci] [cardbus] PCI: Found IRQ 11 for device 0000:00:0d.0 PCI: Sharing IRQ 11 with 0000:00:0d.1 Yenta: CardBus bridge found at 0000:00:0d.0 [0000:0000] Yenta: Enabling burst memory read transactions Yenta: Using CSCINT to route CSC interrupts to PCI Yenta: Routing CardBus interrupts to PCI Yenta TI: socket 0000:00:0d.0, mfunc 0x00001022, devctl 0x64 Yenta: ISA IRQ mask 0x00a8, PCI irq 11 Socket status: 30000006 PCI: Found IRQ 11 for device 0000:00:0d.1 PCI: Sharing IRQ 11 with 0000:00:0d.0 Yenta: CardBus bridge found at 0000:00:0d.1 [0000:0000] Yenta: Using CSCINT to route CSC interrupts to PCI Yenta: Routing CardBus interrupts to PCI Yenta TI: socket 0000:00:0d.1, mfunc 0x00001022, devctl 0x64 yenta: event 00000000 state 30000006 csc 00 intctl 50 events=00000000 Yenta: ISA IRQ mask 0x00a8, PCI irq 11 Socket status: 30000020 yenta: event 00000000 state 30000006 csc 00 intctl 50 events=00000000 yenta: event 00000000 state 30000829 csc 00 intctl 10 events=00000000 yenta: event 00000000 state 30000006 csc 00 intctl 50 events=00000000 yenta: event 00000008 state 30000829 csc 00 intctl 10 events=00000000 yenta: event 00000000 state 30000006 csc 00 intctl 50 events=00000000 yenta: event 00000000 state 30000829 csc 00 intctl 10 events=00000000 yenta: event 00000000 state 30000006 csc 00 intctl 50 events=00000000 yenta: event 00000000 state 30000829 csc 00 intctl 10 events=00000000 yenta: event 00000000 state 30000006 csc 00 intctl 50 events=00000000 yenta: event 00000000 state 30000829 csc 00 intctl 10 events=00000000 yenta: event 00000000 state 30000006 csc 00 intctl 50 events=00000000 yenta: event 00000000 state 30000829 csc 00 intctl 10 events=00000000 yenta: event 00000000 state 30000006 csc 00 intctl 50 events=00000000 yenta: event 00000000 state 30000829 csc 00 intctl 10 events=00000000 yenta: event 00000000 state 30000006 csc 00 intctl 50 events=00000000 yenta: event 00000000 state 30000829 csc 00 intctl 10 events=00000000 yenta: event 00000000 state 30000006 csc 00 intctl 50 events=00000000 yenta: event 00000000 state 30000829 csc 00 intctl 10 events=00000000 yenta: event 00000000 state 30000006 csc 00 intctl 50 events=00000000 irq 11: nobody cared (try booting with the "irqpoll" option. [<c012b752>] __report_bad_irq+0x22/0x90 [<c012b868>] note_interrupt+0x78/0xc0 [<c012b11d>] __do_IRQ+0x13d/0x160 [<c0104aba>] do_IRQ+0x1a/0x30 [<c010337a>] common_interrupt+0x1a/0x20 [<c012007b>] sys_getresgid+0xb/0xa0 [<c0117750>] __do_softirq+0x30/0xa0 [<c0120060>] sys_setresgid+0x120/0x130 [<c01177f5>] do_softirq+0x35/0x40 [<c012af65>] irq_exit+0x35/0x40 [<c0104abf>] do_IRQ+0x1f/0x30 [<c010337a>] common_interrupt+0x1a/0x20 [<c01005b0>] default_idle+0x0/0x40 [<c038007b>] ic_setup_if+0xcb/0xd0 [<c01005d3>] default_idle+0x23/0x40 [<c010064c>] cpu_idle+0x1c/0x50 [<c036873c>] start_kernel+0x13c/0x160 handlers: [<c2838980>] (yenta_interrupt+0x0/0x40 [yenta_socket]) [<c2838980>] (yenta_interrupt+0x0/0x40 [yenta_socket]) Disabling IRQ #11 root@EMBEDDED[~]# ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: yenta_socket rapid fires interrupts 2005-01-11 22:32 ` DHollenbeck @ 2005-01-12 0:03 ` Linus Torvalds 2005-01-12 23:14 ` DHollenbeck 0 siblings, 1 reply; 16+ messages in thread From: Linus Torvalds @ 2005-01-12 0:03 UTC (permalink / raw) To: DHollenbeck; +Cc: linux-kernel, Alan Cox, magnus.damm On Tue, 11 Jan 2005, DHollenbeck wrote: > > And the dmesg output. Please look at intctl. Is this our unsatisfied > noise maker? Hmm. It has I365_PC_RESET set, which does indeed not look right. Could you try just forcing it to zero in the initialization path? In fact, that's there in the 16-bit card case, but not in the CBCARD case. Something like this: --- 1.65/drivers/pcmcia/yenta_socket.c 2004-12-01 00:14:04 -08:00 +++ edited/drivers/pcmcia/yenta_socket.c 2005-01-11 16:02:45 -08:00 @@ -260,7 +260,7 @@ /* ISA interrupt control? */ intr = exca_readb(socket, I365_INTCTL); - intr = (intr & ~0xf); + intr &= I365_RING_ENA | I365_INTR_ENA; if (!socket->cb_irq) { intr |= state->io_irq; bridge |= CB_BRIDGE_INTR; should hopefully take care of it. Linus ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: yenta_socket rapid fires interrupts 2005-01-12 0:03 ` Linus Torvalds @ 2005-01-12 23:14 ` DHollenbeck 0 siblings, 0 replies; 16+ messages in thread From: DHollenbeck @ 2005-01-12 23:14 UTC (permalink / raw) To: Linus Torvalds; +Cc: linux-kernel, Alan Cox, magnus.damm > > >>And the dmesg output. Please look at intctl. Is this our unsatisfied >>noise maker? >> >> > >Hmm. It has I365_PC_RESET set, which does indeed not look right. Could you >try just forcing it to zero in the initialization path? In fact, that's >there in the 16-bit card case, but not in the CBCARD case. Something like >this: > >--- 1.65/drivers/pcmcia/yenta_socket.c 2004-12-01 00:14:04 -08:00 >+++ edited/drivers/pcmcia/yenta_socket.c 2005-01-11 16:02:45 -08:00 >@@ -260,7 +260,7 @@ > > /* ISA interrupt control? */ > intr = exca_readb(socket, I365_INTCTL); >- intr = (intr & ~0xf); >+ intr &= I365_RING_ENA | I365_INTR_ENA; > if (!socket->cb_irq) { > intr |= state->io_irq; > bridge |= CB_BRIDGE_INTR; > >should hopefully take care of it. > > Linus > > > Linus, unfortunately that did not fix it. And I no longer think the "cause" of the interrupt is this I365_PC_RESET bit being on. At first after adding your patch, the same symptoms existed, and since both interrupts handlers were called in immediate sequence (because of the shared IRQ 11 for the two sockets), the events printk mis-led me into believing that the I386_PC_RESET bit was still the cause. (The interrupt stream begins towards the end of probing for the first socket, before the second socket is programmed. and in the events printk I could still see the I386_PC_RESET bit for the 2nd socket.) Eventually I put code into the interrupt handler to turn off that bit whenever I saw it on, regardless of which socket's interrupt handler was executing. Still the interrupt stream persists. I thank you for your help. I have done about all I can do here, and I think there could be a bug in the yenta driver's initialization scenario. Before bailing on this card, I can go this bit further. While the list ponders this post, I am going to once again try this card in a different machine to see if it is still good. It was at last check. Please review the attached dmesg output, which I got by patching the debug printk's. The format is: <calling function> [ <source file line number> ] <io func> <io func data args> see below for more hints on how to interpret... Linux Kernel Card Services options: [pci] [cardbus] PCI: Found IRQ 11 for device 0000:00:0d.0 PCI: Sharing IRQ 11 with 0000:00:0d.1 Yenta: CardBus bridge found at 0000:00:0d.0 [0000:0000] yenta_config_init[ 921]config_writel_ c187a400 0044 00000000 yenta_config_init[ 922]config_writel_ c187a400 0010 fe002000 yenta_config_init[ 927]config_writew_ c187a400 0004 0087 yenta_config_init[ 930]config_writeb_ c187a400 000c 20 yenta_config_init[ 931]config_writeb_ c187a400 000d a8 yenta_config_init[ 936]config_writel_ c187a400 0018 b0040100 yenta_config_init[ 944] config_readw_ c187a400 003e 0340 yenta_config_init[ 947]config_writew_ c187a400 003e 0580 yenta_probe[1013] cb_writel_ c187a400 0004 00000000 yenta_allocate_res[ 602] config_readl_ c187a400 001c 00000000 yenta_allocate_res[ 603] config_readl_ c187a400 0020 00000000 yenta_allocate_res[ 642]config_writel_ c187a400 001c 10000000 yenta_allocate_res[ 643]config_writel_ c187a400 0020 103fffff yenta_allocate_res[ 602] config_readl_ c187a400 0024 00000000 yenta_allocate_res[ 603] config_readl_ c187a400 0028 00000000 yenta_allocate_res[ 642]config_writel_ c187a400 0024 10400000 yenta_allocate_res[ 643]config_writel_ c187a400 0028 107fffff yenta_allocate_res[ 602] config_readl_ c187a400 002c 00000000 yenta_allocate_res[ 603] config_readl_ c187a400 0030 00000000 yenta_allocate_res[ 642]config_writel_ c187a400 002c 00004000 yenta_allocate_res[ 643]config_writel_ c187a400 0030 000040ff yenta_allocate_res[ 602] config_readl_ c187a400 0034 00000000 yenta_allocate_res[ 603] config_readl_ c187a400 0038 00000000 yenta_allocate_res[ 642]config_writel_ c187a400 0034 00004400 yenta_allocate_res[ 643]config_writel_ c187a400 0038 000044ff ti12xx_override[ 598] config_readl_ c187a400 0080 28449060 Yenta: Enabling burst memory read transactions ti12xx_override[ 602]config_writel_ c187a400 0080 2844d060 ti12xx_override[ 619] config_readb_ c187a400 0093 60 Yenta: Using CSCINT to route CSC interrupts to PCI Yenta: Routing CardBus interrupts to PCI ti12xx_irqroute_func0[ 335] config_readl_ c187a400 008c 00001022 ti12xx_irqroute_func0[ 336] config_readb_ c187a400 0092 64 Yenta TI: socket 0000:00:0d.0, mfunc 0x00001022, devctl 0x64 ti_init[ 291] exca_readb_ c187a400 0003 00 ti_init[ 297] exca_writeb_ c187a400 0003 10 yenta_probe_cb_irq[ 866] config_readw_ c187a400 003e 05c0 yenta_probe_cb_irq[ 868]config_writew_ c187a400 003e 0540 yenta_probe_cb_irq[ 876] exca_writeb_ c187a400 0005 01 yenta_probe_cb_irq[ 877] cb_writel_ c187a400 0000 ffffffff yenta_probe_cb_irq[ 878] cb_writel_ c187a400 0004 00000001 yenta_probe_cb_irq[ 879] cb_writel_ c187a400 000c 00000001 yenta_probe_handler[ 843] cb_readl_ c187a400 0000 00000001 yenta_probe_handler[ 844] cb_writel_ c187a400 0000 ffffffff yenta_probe_handler[ 845] exca_readb_ c187a400 0004 00 yenta_probe_cb_irq[ 884] cb_writel_ c187a400 0004 00000000 yenta_probe_cb_irq[ 885] exca_writeb_ c187a400 0005 00 yenta_probe_cb_irq[ 886] cb_writel_ c187a400 0000 ffffffff yenta_probe_cb_irq[ 887] exca_readb_ c187a400 0004 00 Yenta: ti12xx_override(): socket->dev->device=ac55 Yenta: resetting I365_INTCTL's I365_RESET ti12xx_override[ 639] exca_readb_ c187a400 0003 10 ti12xx_override[ 641] exca_writeb_ c187a400 0003 10 ti_override[ 303] exca_readb_ c187a400 0003 10 ti_override[ 307] exca_writeb_ c187a400 0003 00 yenta_probe_irq[ 801] config_readw_ c187a400 003e 0540 yenta_probe_irq[ 804]config_writew_ c187a400 003e 05c0 yenta_probe_irq[ 811] cb_writel_ c187a400 0000 ffffffff yenta_probe_irq[ 812] cb_writel_ c187a400 0004 00000001 yenta_probe_irq[ 813] exca_writeb_ c187a400 0005 00 yenta_probe_irq[ 818] exca_writeb_ c187a400 0005 31 yenta_probe_irq[ 819] cb_writel_ c187a400 000c 00000001 yenta_probe_irq[ 821] cb_writel_ c187a400 0000 ffffffff yenta_probe_irq[ 818] exca_writeb_ c187a400 0005 51 yenta_probe_irq[ 819] cb_writel_ c187a400 000c 00000001 yenta_probe_irq[ 821] cb_writel_ c187a400 0000 ffffffff yenta_probe_irq[ 818] exca_writeb_ c187a400 0005 61 yenta_probe_irq[ 819] cb_writel_ c187a400 000c 00000001 yenta_probe_irq[ 821] cb_writel_ c187a400 0000 ffffffff yenta_probe_irq[ 818] exca_writeb_ c187a400 0005 71 yenta_probe_irq[ 819] cb_writel_ c187a400 000c 00000001 yenta_probe_irq[ 821] cb_writel_ c187a400 0000 ffffffff yenta_probe_irq[ 818] exca_writeb_ c187a400 0005 a1 yenta_probe_irq[ 819] cb_writel_ c187a400 000c 00000001 yenta_probe_irq[ 821] cb_writel_ c187a400 0000 ffffffff yenta_probe_irq[ 823] cb_writel_ c187a400 0004 00000000 yenta_probe_irq[ 824] exca_writeb_ c187a400 0005 00 yenta_probe_irq[ 829]config_writew_ c187a400 003e 0540 Yenta: ISA IRQ mask 0x00a8, PCI irq 11 yenta_probe[1044] cb_readl_ c187a400 0008 30000006 Socket status: 30000006 yenta_sock_init[ 523] config_readw_ c187a400 003e 0540 yenta_sock_init[ 526]config_writew_ c187a400 003e 0540 yenta_sock_init[ 528] exca_writeb_ c187a400 001e 00 yenta_sock_init[ 529] exca_writeb_ c187a400 0016 00 yenta_sock_init[ 532] cb_readl_ c187a400 0008 30000006 yenta_set_power[ 264] cb_readl_ c187a400 0010 00000400 yenta_set_power[ 265] cb_writel_ c187a400 0010 00000000 yenta_set_socket[ 275] config_readw_ c187a400 003e 0540 yenta_set_socket[ 276] cb_readl_ c187a400 0008 30000006 yenta_set_socket[ 294] exca_readb_ c187a400 0003 00 yenta_set_socket[ 301] exca_writeb_ c187a400 0003 40 yenta_set_socket[ 303] exca_readb_ c187a400 0002 00 yenta_set_socket[ 307] exca_readb_ c187a400 0002 00 yenta_set_socket[ 308] exca_writeb_ c187a400 0002 40 yenta_set_socket[ 319] exca_writeb_ c187a400 0005 08 yenta_set_socket[ 320] exca_readb_ c187a400 0004 00 yenta_set_socket[ 324]config_writew_ c187a400 003e 0580 yenta_set_socket[ 326] cb_writel_ c187a400 0000 ffffffff yenta_set_socket[ 327] cb_writel_ c187a400 0004 00000006 yenta_set_io_map[ 343] exca_readb_ c187a400 0006 00 yenta_set_io_map[ 351] exca_writew_ c187a400 0008 0000 yenta_set_io_map[ 352] exca_writew_ c187a400 000a 0001 yenta_set_io_map[ 354] exca_readb_ c187a400 0007 00 yenta_set_io_map[ 358] exca_writeb_ c187a400 0007 00 yenta_set_io_map[ 343] exca_readb_ c187a400 0006 00 yenta_set_io_map[ 351] exca_writew_ c187a400 000c 0000 yenta_set_io_map[ 352] exca_writew_ c187a400 000e 0001 yenta_set_io_map[ 354] exca_readb_ c187a400 0007 00 yenta_set_io_map[ 358] exca_writeb_ c187a400 0007 00 yenta_set_mem_map[ 386] exca_readb_ c187a400 0006 00 yenta_set_mem_map[ 392] exca_writeb_ c187a400 0040 00 yenta_set_mem_map[ 399] exca_writew_ c187a400 0010 0000 yenta_set_mem_map[ 408] exca_writew_ c187a400 0012 0000 yenta_set_mem_map[ 415] exca_writew_ c187a400 0014 0000 yenta_set_mem_map[ 386] exca_readb_ c187a400 0006 00 yenta_set_mem_map[ 392] exca_writeb_ c187a400 0041 00 yenta_set_mem_map[ 399] exca_writew_ c187a400 0018 0000 yenta_set_mem_map[ 408] exca_writew_ c187a400 001a 0000 yenta_set_mem_map[ 415] exca_writew_ c187a400 001c 0000 yenta_set_mem_map[ 386] exca_readb_ c187a400 0006 00 yenta_set_mem_map[ 392] exca_writeb_ c187a400 0042 00 yenta_set_mem_map[ 399] exca_writew_ c187a400 0020 0000 yenta_set_mem_map[ 408] exca_writew_ c187a400 0022 0000 yenta_set_mem_map[ 415] exca_writew_ c187a400 0024 0000 yenta_set_mem_map[ 386] exca_readb_ c187a400 0006 00 yenta_set_mem_map[ 392] exca_writeb_ c187a400 0043 00 yenta_set_mem_map[ 399] exca_writew_ c187a400 0028 0000 yenta_set_mem_map[ 408] exca_writew_ c187a400 002a 0000 yenta_set_mem_map[ 415] exca_writew_ c187a400 002c 0000 yenta_set_mem_map[ 386] exca_readb_ c187a400 0006 00 yenta_set_mem_map[ 392] exca_writeb_ c187a400 0044 00 yenta_set_mem_map[ 399] exca_writew_ c187a400 0030 0000 yenta_set_mem_map[ 408] exca_writew_ c187a400 0032 0000 yenta_set_mem_map[ 415] exca_writew_ c187a400 0034 0000 ti_init[ 291] exca_readb_ c187a400 0003 40 ti_init[ 297] exca_writeb_ c187a400 0003 10 yenta_sock_init[ 543] cb_writel_ c187a400 0004 00000006 yenta_set_power[ 264] cb_readl_ c187a400 0010 00000400 yenta_set_power[ 265] cb_writel_ c187a400 0010 00000000 yenta_set_socket[ 275] config_readw_ c187a400 003e 05c0 yenta_set_socket[ 276] cb_readl_ c187a400 0008 30000006 yenta_set_socket[ 294] exca_readb_ c187a400 0003 10 yenta_set_socket[ 301] exca_writeb_ c187a400 0003 50 yenta_set_socket[ 303] exca_readb_ c187a400 0002 00 yenta_set_socket[ 307] exca_readb_ c187a400 0002 00 yenta_set_socket[ 308] exca_writeb_ c187a400 0002 40 yenta_set_socket[ 319] exca_writeb_ c187a400 0005 08 yenta_set_socket[ 320] exca_readb_ c187a400 0004 00 yenta_set_socket[ 324]config_writew_ c187a400 003e 0580 yenta_set_socket[ 326] cb_writel_ c187a400 0000 ffffffff yenta_set_socket[ 327] cb_writel_ c187a400 0004 00000006 PCI: Found IRQ 11 for device 0000:00:0d.1 PCI: Sharing IRQ 11 with 0000:00:0d.0 Yenta: CardBus bridge found at 0000:00:0d.1 [0000:0000] yenta_config_init[ 921]config_writel_ c187a000 0044 00000000 yenta_config_init[ 922]config_writel_ c187a000 0010 fe003000 yenta_config_init[ 927]config_writew_ c187a000 0004 0087 yenta_config_init[ 930]config_writeb_ c187a000 000c 20 yenta_config_init[ 931]config_writeb_ c187a000 000d a8 yenta_config_init[ 936]config_writel_ c187a000 0018 b0080500 yenta_config_init[ 944] config_readw_ c187a000 003e 0340 yenta_config_init[ 947]config_writew_ c187a000 003e 0580 yenta_probe[1013] cb_writel_ c187a000 0004 00000000 yenta_allocate_res[ 602] config_readl_ c187a000 001c 00000000 yenta_allocate_res[ 603] config_readl_ c187a000 0020 00000000 yenta_allocate_res[ 642]config_writel_ c187a000 001c 10800000 yenta_allocate_res[ 643]config_writel_ c187a000 0020 10bfffff yenta_allocate_res[ 602] config_readl_ c187a000 0024 00000000 yenta_allocate_res[ 603] config_readl_ c187a000 0028 00000000 yenta_allocate_res[ 642]config_writel_ c187a000 0024 10c00000 yenta_allocate_res[ 643]config_writel_ c187a000 0028 10ffffff yenta_allocate_res[ 602] config_readl_ c187a000 002c 00000000 yenta_allocate_res[ 603] config_readl_ c187a000 0030 00000000 yenta_allocate_res[ 642]config_writel_ c187a000 002c 00004800 yenta_allocate_res[ 643]config_writel_ c187a000 0030 000048ff yenta_allocate_res[ 602] config_readl_ c187a000 0034 00000000 yenta_allocate_res[ 603] config_readl_ c187a000 0038 00000000 yenta_allocate_res[ 642]config_writel_ c187a000 0034 00004c00 yenta_allocate_res[ 643]config_writel_ c187a000 0038 00004cff ti12xx_override[ 598] config_readl_ c187a000 0080 2844d060 ti12xx_override[ 619] config_readb_ c187a000 0093 60 Yenta: Using CSCINT to route CSC interrupts to PCI Yenta: Routing CardBus interrupts to PCI ti12xx_irqroute_func1[ 494] config_readl_ c187a000 008c 00001022 ti12xx_irqroute_func1[ 495] config_readb_ c187a000 0092 64 Yenta TI: socket 0000:00:0d.1, mfunc 0x00001022, devctl 0x64 ti_init[ 291] exca_readb_ c187a000 0003 00 ti_init[ 297] exca_writeb_ c187a000 0003 10 yenta_probe_cb_irq[ 866] config_readw_ c187a000 003e 05c0 yenta_probe_cb_irq[ 868]config_writew_ c187a000 003e 0540 yenta_probe_cb_irq[ 876] exca_writeb_ c187a000 0005 01 yenta_probe_cb_irq[ 877] cb_writel_ c187a000 0000 ffffffff yenta_probe_cb_irq[ 878] cb_writel_ c187a000 0004 00000001 yenta_probe_cb_irq[ 879] cb_writel_ c187a000 000c 00000001 yenta_events[ 430] cb_readl_ c187a400 0000 00000000 yenta_events[ 431] cb_writel_ c187a400 0000 00000000 yenta_events[ 433] exca_readb_ c187a400 0004 00 yenta_events[ 437] exca_readb_ c187a400 0003 50 yenta_events[ 441] exca_writeb_ c187a400 0003 10 yenta_events[ 463] cb_readl_ c187a400 0008 30000006 yenta: c187a400 cb_event 00000000 state 30000006 csc 00 intctl 50 events 00000040 yenta_probe_handler[ 843] cb_readl_ c187a000 0000 00000001 yenta_probe_handler[ 844] cb_writel_ c187a000 0000 ffffffff yenta_probe_handler[ 845] exca_readb_ c187a000 0004 00 yenta_get_status[ 161] cb_readl_ c187a400 0008 30000006 yenta_get_status[ 174] exca_readb_ c187a400 0001 00 yenta_get_status[ 176] exca_readb_ c187a400 0003 10 yenta_probe_cb_irq[ 884] cb_writel_ c187a000 0004 00000000 yenta_probe_cb_irq[ 885] exca_writeb_ c187a000 0005 00 yenta_probe_cb_irq[ 886] cb_writel_ c187a000 0000 ffffffff yenta_probe_cb_irq[ 887] exca_readb_ c187a000 0004 00 Yenta: ti12xx_override(): socket->dev->device=ac55 Yenta: resetting I365_INTCTL's I365_RESET ti12xx_override[ 639] exca_readb_ c187a000 0003 10 ti12xx_override[ 641] exca_writeb_ c187a000 0003 10 ti_override[ 303] exca_readb_ c187a000 0003 10 ti_override[ 307] exca_writeb_ c187a000 0003 00 yenta_probe_irq[ 801] config_readw_ c187a000 003e 0540 yenta_probe_irq[ 804]config_writew_ c187a000 003e 05c0 yenta_probe_irq[ 811] cb_writel_ c187a000 0000 ffffffff yenta_probe_irq[ 812] cb_writel_ c187a000 0004 00000001 yenta_probe_irq[ 813] exca_writeb_ c187a000 0005 00 yenta_probe_irq[ 818] exca_writeb_ c187a000 0005 31 yenta_probe_irq[ 819] cb_writel_ c187a000 000c 00000001 yenta_probe_irq[ 821] cb_writel_ c187a000 0000 ffffffff yenta_probe_irq[ 818] exca_writeb_ c187a000 0005 51 yenta_probe_irq[ 819] cb_writel_ c187a000 000c 00000001 yenta_probe_irq[ 821] cb_writel_ c187a000 0000 ffffffff yenta_probe_irq[ 818] exca_writeb_ c187a000 0005 61 yenta_probe_irq[ 819] cb_writel_ c187a000 000c 00000001 yenta_probe_irq[ 821] cb_writel_ c187a000 0000 ffffffff yenta_probe_irq[ 818] exca_writeb_ c187a000 0005 71 yenta_probe_irq[ 819] cb_writel_ c187a000 000c 00000001 yenta_probe_irq[ 821] cb_writel_ c187a000 0000 ffffffff yenta_probe_irq[ 818] exca_writeb_ c187a000 0005 a1 yenta_probe_irq[ 819] cb_writel_ c187a000 000c 00000001 yenta_probe_irq[ 821] cb_writel_ c187a000 0000 ffffffff yenta_probe_irq[ 823] cb_writel_ c187a000 0004 00000000 yenta_probe_irq[ 824] exca_writeb_ c187a000 0005 00 yenta_probe_irq[ 829]config_writew_ c187a000 003e 0540 Yenta: ISA IRQ mask 0x00a8, PCI irq 11 yenta_probe[1044] cb_readl_ c187a000 0008 30000020 Socket status: 30000020 yenta_sock_init[ 523] config_readw_ c187a000 003e 0540 yenta_sock_init[ 526]config_writew_ c187a000 003e 0540 yenta_sock_init[ 528] exca_writeb_ c187a000 001e 00 yenta_sock_init[ 529] exca_writeb_ c187a000 0016 00 yenta_sock_init[ 532] cb_readl_ c187a000 0008 30000020 yenta_sock_init[ 535] cb_writel_ c187a000 000c 00004000 yenta_set_power[ 264] cb_readl_ c187a000 0010 00000400 yenta_set_power[ 265] cb_writel_ c187a000 0010 00000000 yenta_set_socket[ 275] config_readw_ c187a000 003e 0540 yenta_set_socket[ 276] cb_readl_ c187a000 0008 30000820 yenta_set_socket[ 281] exca_readb_ c187a000 0003 00 yenta: CBCARD: I365_INTCTL=00 state->io_irq=00 yenta_set_socket[ 290] exca_writeb_ c187a000 0003 00 yenta_set_socket[ 324]config_writew_ c187a000 003e 0500 yenta_set_socket[ 326] cb_writel_ c187a000 0000 ffffffff yenta_set_socket[ 327] cb_writel_ c187a000 0004 00000006 yenta_set_io_map[ 343] exca_readb_ c187a000 0006 00 yenta_set_io_map[ 351] exca_writew_ c187a000 0008 0000 yenta_set_io_map[ 352] exca_writew_ c187a000 000a 0001 yenta_set_io_map[ 354] exca_readb_ c187a000 0007 00 yenta_set_io_map[ 358] exca_writeb_ c187a000 0007 00 yenta_set_io_map[ 343] exca_readb_ c187a000 0006 00 yenta_set_io_map[ 351] exca_writew_ c187a000 000c 0000 yenta_set_io_map[ 352] exca_writew_ c187a000 000e 0001 yenta_set_io_map[ 354] exca_readb_ c187a000 0007 00 yenta_set_io_map[ 358] exca_writeb_ c187a000 0007 00 yenta_set_mem_map[ 386] exca_readb_ c187a000 0006 00 yenta_set_mem_map[ 392] exca_writeb_ c187a000 0040 00 yenta_set_mem_map[ 399] exca_writew_ c187a000 0010 0000 yenta_set_mem_map[ 408] exca_writew_ c187a000 0012 0000 yenta_set_mem_map[ 415] exca_writew_ c187a000 0014 0000 yenta_set_mem_map[ 386] exca_readb_ c187a000 0006 00 yenta_set_mem_map[ 392] exca_writeb_ c187a000 0041 00 yenta_set_mem_map[ 399] exca_writew_ c187a000 0018 0000 yenta_set_mem_map[ 408] exca_writew_ c187a000 001a 0000 yenta_set_mem_map[ 415] exca_writew_ c187a000 001c 0000 yenta_set_mem_map[ 386] exca_readb_ c187a000 0006 00 yenta_set_mem_map[ 392] exca_writeb_ c187a000 0042 00 yenta_set_mem_map[ 399] exca_writew_ c187a000 0020 0000 yenta_set_mem_map[ 408] exca_writew_ c187a000 0022 0000 yenta_set_mem_map[ 415] exca_writew_ c187a000 0024 0000 yenta_set_mem_map[ 386] exca_readb_ c187a000 0006 00 yenta_set_mem_map[ 392] exca_writeb_ c187a000 0043 00 yenta_set_mem_map[ 399] exca_writew_ c187a000 0028 0000 yenta_set_mem_map[ 408] exca_writew_ c187a000 002a 0000 yenta_set_mem_map[ 415] exca_writew_ c187a000 002c 0000 yenta_set_mem_map[ 386] exca_readb_ c187a000 0006 00 yenta_set_mem_map[ 392] exca_writeb_ c187a000 0044 00 yenta_set_mem_map[ 399] exca_writew_ c187a000 0030 0000 yenta_set_mem_map[ 408] exca_writew_ c187a000 0032 0000 yenta_set_mem_map[ 415] exca_writew_ c187a000 0034 0000 ti_init[ 291] exca_readb_ c187a000 0003 00 ti_init[ 297] exca_writeb_ c187a000 0003 10 yenta_sock_init[ 543] cb_writel_ c187a000 0004 00000006 yenta_set_power[ 264] cb_readl_ c187a000 0010 00000400 yenta_set_power[ 265] cb_writel_ c187a000 0010 00000000 yenta_set_socket[ 275] config_readw_ c187a000 003e 0540 yenta_set_socket[ 276] cb_readl_ c187a000 0008 30000820 yenta_set_socket[ 281] exca_readb_ c187a000 0003 10 yenta: CBCARD: I365_INTCTL=10 state->io_irq=00 yenta_set_socket[ 290] exca_writeb_ c187a000 0003 10 yenta_set_socket[ 324]config_writew_ c187a000 003e 0500 yenta_set_socket[ 326] cb_writel_ c187a000 0000 ffffffff yenta_set_socket[ 327] cb_writel_ c187a000 0004 00000006 yenta_get_status[ 161] cb_readl_ c187a000 0008 30000820 yenta_get_status[ 161] cb_readl_ c187a000 0008 30000820 yenta_get_status[ 161] cb_readl_ c187a000 0008 30000820 yenta_set_power[ 264] cb_readl_ c187a000 0010 00000400 yenta_set_power[ 265] cb_writel_ c187a000 0010 00000033 yenta_set_socket[ 275] config_readw_ c187a000 003e 0540 yenta_set_socket[ 276] cb_readl_ c187a000 0008 30000820 yenta_set_socket[ 281] exca_readb_ c187a000 0003 10 yenta: CBCARD: I365_INTCTL=10 state->io_irq=00 yenta_set_socket[ 290] exca_writeb_ c187a000 0003 10 yenta_set_socket[ 324]config_writew_ c187a000 003e 0500 yenta_set_socket[ 326] cb_writel_ c187a000 0000 ffffffff yenta_set_socket[ 327] cb_writel_ c187a000 0004 00000006 yenta_events[ 430] cb_readl_ c187a400 0000 00000000 yenta_events[ 431] cb_writel_ c187a400 0000 00000000 yenta_events[ 433] exca_readb_ c187a400 0004 00 yenta_events[ 437] exca_readb_ c187a400 0003 10 yenta_events[ 463] cb_readl_ c187a400 0008 30000006 yenta: c187a400 cb_event 00000000 state 30000006 csc 00 intctl 10 events 00000000 yenta_events[ 430] cb_readl_ c187a000 0000 00000008 yenta_events[ 431] cb_writel_ c187a000 0000 00000008 yenta_events[ 433] exca_readb_ c187a000 0004 00 yenta_events[ 437] exca_readb_ c187a000 0003 10 yenta_events[ 463] cb_readl_ c187a000 0008 30000829 yenta: c187a000 cb_event 00000008 state 30000829 csc 00 intctl 10 events 00000000 yenta_events[ 430] cb_readl_ c187a400 0000 00000000 yenta_events[ 431] cb_writel_ c187a400 0000 00000000 yenta_events[ 433] exca_readb_ c187a400 0004 00 yenta_events[ 437] exca_readb_ c187a400 0003 10 yenta_events[ 463] cb_readl_ c187a400 0008 30000006 yenta: c187a400 cb_event 00000000 state 30000006 csc 00 intctl 10 events 00000000 yenta_events[ 430] cb_readl_ c187a000 0000 00000000 yenta_events[ 431] cb_writel_ c187a000 0000 00000000 yenta_events[ 433] exca_readb_ c187a000 0004 00 yenta_events[ 437] exca_readb_ c187a000 0003 10 irq 11: nobody cared (try booting with the "irqpoll" option. [<c012b752>] __report_bad_irq+0x22/0x90 [<c012b868>] note_interrupt+0x78/0xc0 [<c012b11d>] __do_IRQ+0x13d/0x160 [<c0104aba>] do_IRQ+0x1a/0x30 [<c010337a>] common_interrupt+0x1a/0x20 [<c012007b>] sys_getresgid+0xb/0xa0 [<c0117750>] __do_softirq+0x30/0xa0 [<c0120060>] sys_setresgid+0x120/0x130 [<c01177f5>] do_softirq+0x35/0x40 [<c012af65>] irq_exit+0x35/0x40 [<c0104abf>] do_IRQ+0x1f/0x30 [<c010337a>] common_interrupt+0x1a/0x20 [<c01005b0>] default_idle+0x0/0x40 [<c038007b>] ic_setup_if+0xcb/0xd0 [<c01005d3>] default_idle+0x23/0x40 [<c010064c>] cpu_idle+0x1c/0x50 [<c036873c>] start_kernel+0x13c/0x160 handlers: [<c284f5c0>] (yenta_interrupt+0x0/0x40 [yenta_socket]) [<c284f5c0>] (yenta_interrupt+0x0/0x40 [yenta_socket]) Disabling IRQ #11 yenta: CBCARD: I365_INTCTL=10 state->io_irq=00 yenta: CBCARD: I365_INTCTL=10 state->io_irq=00 root@EMBEDDED[~]# root@EMBEDDED[~]# To make sense of the line numbers, you could take a copy of yenta_socket.c 2.6.10 out of tree to a tmp dir, and apply the following patch. Some of the line numbers are header file relative, but most all are based in yenta_socket.c. --- yenta_socket..orig 2004-12-24 15:35:00.000000000 -0600 +++ yenta_socket.c 2005-01-12 14:58:24.000000000 -0600 @@ -29,12 +29,6 @@ #include "i82365.h" -#if 0 -#define debug(x,args...) printk(KERN_DEBUG "%s: " x, __func__ , ##args) -#else -#define debug(x,args...) -#endif - /* Don't ask.. */ #define to_cycles(ns) ((ns)/120) #define to_ns(cycles) ((cycles)*120) @@ -42,95 +36,120 @@ static int yenta_probe_cb_irq(struct yenta_socket *socket); +#if 1 +static int debugOn=1; +#define debug(f,l,x,args...) do { if(debugOn) printk(KERN_DEBUG "%20s[%4d]%14s " x,f, l,__func__,##args); } while(0) +#else +#define debug(f,l,x,args...) +#endif + +/* pass "line" numbers to inline static functions for debugging output */ +#define cb_readl(s, r) cb_readl_(__func__,__LINE__,s,r) +#define cb_writel(s,r,v) cb_writel_(__func__,__LINE__,s,r,v) + +#define config_readb(s,o) config_readb_(__func__,__LINE__,s,o) +#define config_writeb(s,o,v) config_writeb_(__func__,__LINE__,s,o,v) +#define config_readw(s,o) config_readw_(__func__,__LINE__,s,o) +#define config_writew(s,o,v) config_writew_(__func__,__LINE__,s,o,v) +#define config_readl(s,o) config_readl_(__func__,__LINE__,s,o) +#define config_writel(s,o,v) config_writel_(__func__,__LINE__,s,o,v) + +#define exca_readb(s,r) exca_readb_(__func__,__LINE__,s,r) +#define exca_readw(s,r) exca_readw_(__func__,__LINE__,s,r) +#define exca_writeb(s,r,v) exca_writeb_(__func__,__LINE__,s,r,v) +#define exca_writew(s,r,v) exca_writew_(__func__,__LINE__,s,r,v) + + /* * Generate easy-to-use ways of reading a cardbus sockets * regular memory space ("cb_xxx"), configuration space * ("config_xxx") and compatibility space ("exca_xxxx") */ -static inline u32 cb_readl(struct yenta_socket *socket, unsigned reg) +static inline u32 cb_readl_(const char* f, int line, struct yenta_socket *socket, unsigned reg) { u32 val = readl(socket->base + reg); - debug("%p %04x %08x\n", socket, reg, val); + debug(f,line, "%p %04x %08x\n", socket, reg, val); return val; } -static inline void cb_writel(struct yenta_socket *socket, unsigned reg, u32 val) +static inline void cb_writel_(const char* f, int line, struct yenta_socket *socket, unsigned reg, u32 val) { - debug("%p %04x %08x\n", socket, reg, val); + debug(f,line, "%p %04x %08x\n", socket, reg, val); writel(val, socket->base + reg); } -static inline u8 config_readb(struct yenta_socket *socket, unsigned offset) +static inline u8 config_readb_(const char* f, int line, struct yenta_socket *socket, unsigned offset) { u8 val; pci_read_config_byte(socket->dev, offset, &val); - debug("%p %04x %02x\n", socket, offset, val); + debug(f,line, "%p %04x %02x\n", socket, offset, val); return val; } -static inline u16 config_readw(struct yenta_socket *socket, unsigned offset) +static inline u16 config_readw_(const char* f, int line, struct yenta_socket *socket, unsigned offset) { u16 val; pci_read_config_word(socket->dev, offset, &val); - debug("%p %04x %04x\n", socket, offset, val); + debug(f,line, "%p %04x %04x\n", socket, offset, val); return val; } -static inline u32 config_readl(struct yenta_socket *socket, unsigned offset) +static inline u32 config_readl_(const char* f, int line, struct yenta_socket *socket, unsigned offset) { u32 val; pci_read_config_dword(socket->dev, offset, &val); - debug("%p %04x %08x\n", socket, offset, val); + debug(f,line, "%p %04x %08x\n", socket, offset, val); return val; } -static inline void config_writeb(struct yenta_socket *socket, unsigned offset, u8 val) +static inline void config_writeb_(const char* f, int line, struct yenta_socket *socket, unsigned offset, u8 val) { - debug("%p %04x %02x\n", socket, offset, val); + debug(f,line, "%p %04x %02x\n", socket, offset, val); pci_write_config_byte(socket->dev, offset, val); } -static inline void config_writew(struct yenta_socket *socket, unsigned offset, u16 val) +static inline void config_writew_(const char* f, int line, struct yenta_socket *socket, unsigned offset, u16 val) { - debug("%p %04x %04x\n", socket, offset, val); + debug(f,line, "%p %04x %04x\n", socket, offset, val); pci_write_config_word(socket->dev, offset, val); } -static inline void config_writel(struct yenta_socket *socket, unsigned offset, u32 val) +static inline void config_writel_(const char* f, int line, struct yenta_socket *socket, unsigned offset, u32 val) { - debug("%p %04x %08x\n", socket, offset, val); + debug(f,line, "%p %04x %08x\n", socket, offset, val); pci_write_config_dword(socket->dev, offset, val); } -static inline u8 exca_readb(struct yenta_socket *socket, unsigned reg) +static inline u8 exca_readb_(const char* f, int line, struct yenta_socket *socket, unsigned reg) { u8 val = readb(socket->base + 0x800 + reg); - debug("%p %04x %02x\n", socket, reg, val); + debug(f,line, "%p %04x %02x\n", socket, reg, val); return val; } -static inline u8 exca_readw(struct yenta_socket *socket, unsigned reg) +static inline u8 exca_readw_(const char* f, int line, struct yenta_socket *socket, unsigned reg) { u16 val; val = readb(socket->base + 0x800 + reg); val |= readb(socket->base + 0x800 + reg + 1) << 8; - debug("%p %04x %04x\n", socket, reg, val); + debug(f,line, "%p %04x %04x\n", socket, reg, val); return val; } -static inline void exca_writeb(struct yenta_socket *socket, unsigned reg, u8 val) +static inline void exca_writeb_(const char* f, int line, struct yenta_socket *socket, unsigned reg, u8 val) { - debug("%p %04x %02x\n", socket, reg, val); + debug(f,line, "%p %04x %02x\n", socket, reg, val); writeb(val, socket->base + 0x800 + reg); } -static void exca_writew(struct yenta_socket *socket, unsigned reg, u16 val) +static void exca_writew_(const char* f, int line, struct yenta_socket *socket, unsigned reg, u16 val) { - debug("%p %04x %04x\n", socket, reg, val); + debug(f,line, "%p %04x %04x\n", socket, reg, val); writeb(val, socket->base + 0x800 + reg); writeb(val >> 8, socket->base + 0x800 + reg + 1); } + /* * Ugh, mixed-mode cardbus and 16-bit pccard state: things depend * on what kind of card is inserted.. @@ -260,11 +279,14 @@ /* ISA interrupt control? */ intr = exca_readb(socket, I365_INTCTL); - intr = (intr & ~0xf); +// intr = (intr & ~0xf); + intr &= I365_RING_ENA | I365_INTR_ENA; if (!socket->cb_irq) { intr |= state->io_irq; bridge |= CB_BRIDGE_INTR; } + printk("yenta: CBCARD: I365_INTCTL=%02x state->io_irq=%02x\n", + intr, state->io_irq ); exca_writeb(socket, I365_INTCTL, intr); } else { u8 reg; @@ -401,7 +423,7 @@ static unsigned int yenta_events(struct yenta_socket *socket) { u8 csc; - u32 cb_event; + u32 cb_event, intctl; unsigned int events; /* Clear interrupt status for the event */ @@ -412,13 +434,41 @@ events = (cb_event & (CB_CD1EVENT | CB_CD2EVENT)) ? SS_DETECT : 0 ; events |= (csc & I365_CSC_DETECT) ? SS_DETECT : 0; - if (exca_readb(socket, I365_INTCTL) & I365_PC_IOCARD) { + intctl = exca_readb(socket, I365_INTCTL); + + if (intctl & I365_PC_RESET ) { + events |= SS_READY; /* ensure a non-zero return */ + exca_writeb(socket, I365_INTCTL, intctl & ~I365_PC_RESET); + } + + if (intctl & I365_PC_IOCARD) { events |= (csc & I365_CSC_STSCHG) ? SS_STSCHG : 0; + } else { events |= (csc & I365_CSC_BVD1) ? SS_BATDEAD : 0; events |= (csc & I365_CSC_BVD2) ? SS_BATWARN : 0; events |= (csc & I365_CSC_READY) ? SS_READY : 0; } + +/* RHH: per Linus */ +#if 1 + { + u32 cb_state; + + static int intCount = 4; + + if( intCount > 0 ) + { + --intCount; + cb_state = cb_readl(socket, CB_SOCKET_STATE); + printk("yenta: %p cb_event %08x state %08x csc %02x intctl %02x events %08x\n", + socket, cb_event, cb_state, csc, intctl, events ); + } + else + debugOn = 0; + } +#endif + return events; } ^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2005-01-13 16:15 UTC | newest] Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2005-01-10 17:33 yenta_socket rapid fires interrupts DHollenbeck 2005-01-10 19:24 ` Alan Cox 2005-01-11 3:17 ` Linus Torvalds 2005-01-11 19:18 ` DHollenbeck 2005-01-11 19:46 ` Grzegorz Kulewski 2005-01-11 19:54 ` Linus Torvalds 2005-01-11 21:16 ` DHollenbeck 2005-01-11 21:40 ` Linus Torvalds 2005-01-13 14:13 ` Stefan Seyfried 2005-01-13 15:42 ` DHollenbeck 2005-01-13 15:59 ` DHollenbeck 2005-01-11 21:38 ` DHollenbeck 2005-01-11 21:43 ` Linus Torvalds 2005-01-11 22:32 ` DHollenbeck 2005-01-12 0:03 ` Linus Torvalds 2005-01-12 23:14 ` DHollenbeck
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).