* 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 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: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: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
* 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
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).