2005-03-18 13:46:07

by Jonas Oreland

[permalink] [raw]
Subject: yenta_socket "nobody cared - Disabling IRQ #4"

Hi,

I have a IBM thinkpad G40 and have just upgraded from 2.4.28 to 2.6.11.2
And I fail to get my netgear wg511t wireless pccard to function.
(worked fine with 2.4.28)

I've tried (wo really knowing what i'm doing) using
*) pci=routeirq
*) compiling kernel wo/ acpi
*) modprobe yenta_socket disable_clkrun=1

NOTE: It works sometimes!
When I insert the card (or modprobe yenta_socket), it will either work
and then I can use the wlan card wo/ problem, or it will fail directly.

The failures are unfortunatly is majority :-(

NOTE2: I have also tried wo/ the madwifi driver, and it can still lock up.

Please let me know I you need more/less info

/Jonas

-- output from uname -a
Linux eel 2.6.11.2 #2 Fri Mar 18 14:47:09 CET 2005 i686 Intel(R)
Pentium(R) 4 CPU 3.00GHz GenuineIntel GNU/Linux

-- output from dump_cis
eel ~ # dump_cis
Socket 0:
manfid 0x0271, 0x0012
config_cb base 0x0000 last_index 0x01
cftable_entry_cb 0x01 [default]
[master] [parity] [serr] [fast back]
Vcc Vnom 3300mV Istatic 25mA Iavg 450mA Ipeak 500mA
irq mask 0xffff [level]
mem_base 1
BAR 1 size 64kb [mem]
vers_1 7.1, "Atheros Communications, Inc.", "AR5001-0000-0000",
"Wireless LAN Reference Card", "00"
funcid network_adapter [post]
lan_speed 6 mb/sec
lan_speed 9 mb/sec
lan_speed 12 mb/sec
lan_speed 18 mb/sec
lan_speed 24 mb/sec
lan_speed 36 mb/sec
lan_speed 48 mb/sec
lan_speed 54 mb/sec
lan_speed 72 mb/sec
lan_media 5.4_GHz
lan_node_id 00 09 5b ec 43 cd
lan_connector Closed connector standard

-- output from dmesg
Linux version 2.6.11.2 (root@eel) (gcc version 3.3.5 (Gentoo Linux 3.3.5-r1, ssp-3.3.2-3, pie-8.7.7.1)) #2 Fri Mar 18 14:47:09 CET 2005
BIOS-provided physical RAM map:
BIOS-e820: 0000000000000000 - 000000000009f000 (usable)
BIOS-e820: 000000000009f000 - 00000000000a0000 (reserved)
BIOS-e820: 00000000000ce000 - 00000000000d0000 (reserved)
BIOS-e820: 00000000000dc000 - 0000000000100000 (reserved)
BIOS-e820: 0000000000100000 - 000000000f6f0000 (usable)
BIOS-e820: 000000000f6f0000 - 000000000f700000 (reserved)
BIOS-e820: 000000000f700000 - 000000003f6f0000 (usable)
BIOS-e820: 000000003f6f0000 - 000000003f6f8000 (ACPI data)
BIOS-e820: 000000003f6f8000 - 000000003f6fa000 (ACPI NVS)
BIOS-e820: 000000003f700000 - 0000000040000000 (reserved)
BIOS-e820: 00000000ff800000 - 0000000100000000 (reserved)
Warning only 896MB will be used.
Use a HIGHMEM enabled kernel.
896MB LOWMEM available.
On node 0 totalpages: 229376
DMA zone: 4096 pages, LIFO batch:1
Normal zone: 225280 pages, LIFO batch:16
HighMem zone: 0 pages, LIFO batch:1
DMI present.
ACPI: RSDP (v002 IBM ) @ 0x000f7330
ACPI: XSDT (v001 IBM TP-1T 0x00001081 LTP 0x00000000) @ 0x3f6f2435
ACPI: FADT (v002 IBM TP-1T 0x00001081 IBM 0x00000001) @ 0x3f6f2479
ACPI: SSDT (v001 IBM TP-1T 0x00001081 MSFT 0x0100000d) @ 0x3f6f252d
ACPI: ECDT (v001 IBM TP-1T 0x00001081 IBM 0x00000001) @ 0x3f6f7f87
ACPI: BOOT (v001 IBM TP-1T 0x00001081 LTP 0x00000001) @ 0x3f6f7fd8
ACPI: DSDT (v001 IBM TP-1T 0x00001081 MSFT 0x0100000d) @ 0x00000000
Allocating PCI resources starting at 40000000 (gap: 40000000:bf800000)
Built 1 zonelists
Kernel command line: root=/dev/hda4 resume=/dev/hda3
Initializing CPU#0
PID hash table entries: 4096 (order: 12, 65536 bytes)
Detected 2988.029 MHz processor.
Using tsc for high-res timesource
Console: colour VGA+ 80x25
Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
Memory: 904280k/917504k available (3129k kernel code, 12640k reserved, 1103k data, 160k init, 0k highmem)
Checking if this processor honours the WP bit even in supervisor mode... Ok.
Calibrating delay loop... 5898.24 BogoMIPS (lpj=2949120)
Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
CPU: After generic identify, caps: bfebf9ff 00000000 00000000 00000000 00004400 00000000 00000000
CPU: After vendor identify, caps: bfebf9ff 00000000 00000000 00000000 00004400 00000000 00000000
CPU: Trace cache: 12K uops, L1 D cache: 8K
CPU: L2 cache: 512K
CPU: After all inits, caps: bfebf9ff 00000000 00000000 00000080 00004400 00000000 00000000
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
CPU0: Intel P4/Xeon Extended MCE MSRs (12) available
CPU: Intel(R) Pentium(R) 4 CPU 3.00GHz stepping 09
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Checking 'hlt' instruction... OK.
ACPI: setting ELCR to 0200 (from 0298)
NET: Registered protocol family 16
PCI: PCI BIOS revision 2.10 entry at 0xfd966, last bus=5
PCI: Using configuration type 1
mtrr: v2.0 (20020519)
ACPI: Subsystem revision 20050211
ACPI: Found ECDT
ACPI: Could not use ECDT
ACPI: Interpreter enabled
ACPI: Using PIC for interrupt routing
ACPI: PCI Interrupt Link [LNKA] (IRQs *3 4 5 6 7 9 10 11)
ACPI: PCI Interrupt Link [LNKB] (IRQs 3 *4 5 6 7 9 10 11)
ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 6 *7 9 10 11)
ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 7 *9 10 11)
ACPI: PCI Interrupt Link [LNKE] (IRQs *3 4 5 6 7 9 10 11)
ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 6 7 9 10 11) *0, disabled.
ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 5 6 7 9 10 11) *0, disabled.
ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 5 6 *7 9 10 11)
ACPI: PCI Root Bridge [PCI0] (00:00)
PCI: Probing PCI hardware (bus 00)
PCI: Ignoring BAR0-3 of IDE controller 0000:00:1f.1
PCI: Transparent bridge - 0000:00:1e.0
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
ACPI: Embedded Controller [EC] (gpe 29)
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PCI1._PRT]
Linux Plug and Play Support v0.97 (c) Adam Belay
pnp: PnP ACPI init
pnp: PnP ACPI: found 10 devices
Linux Kernel Card Services
options: [pci] [cardbus] [pm]
usbcore: registered new driver usbfs
usbcore: registered new driver hub
PCI: Using ACPI for IRQ routing
** PCI interrupts are no longer routed automatically. If this
** causes a device to stop working, it is probably because the
** driver failed to call pci_enable_device(). As a temporary
** workaround, the "pci=routeirq" argument restores the old
** behavior. If this argument makes the device work again,
** please email the output of "lspci" to [email protected]
** so I can fix the driver.
Simple Boot Flag at 0x35 set to 0x1
IA-32 Microcode Update Driver: v1.14 <[email protected]>
audit: initializing netlink socket (disabled)
audit(1111156449.775:0): initialized
devfs: 2004-01-31 Richard Gooch ([email protected])
devfs: boot_options: 0x1
Installing knfsd (copyright (C) 1996 [email protected]).
NTFS driver 2.1.22 [Flags: R/O].
Initializing Cryptographic API
pci_hotplug: PCI Hot Plug PCI Core version: 0.5
ACPI: AC Adapter [AC] (on-line)
ACPI: Battery Slot [BAT1] (battery present)
ACPI: Power Button (FF) [PWRF]
ACPI: Lid Switch [LID]
ACPI: Sleep Button (CM) [SLPB]
ACPI: Video Device [VID] (multi-head: yes rom: no post: no)
ACPI: CPU0 (power states: C1[C1] C2[C2])
ACPI: Processor [CPU0] (supports 4 throttling states)
ACPI: Thermal Zone [THRM] (51 C)
ibm_acpi: IBM ThinkPad ACPI Extras v0.8
ibm_acpi: http://ibm-acpi.sf.net/
Linux agpgart interface v0.100 (c) Dave Jones
agpgart: Detected an Intel 855 Chipset.
agpgart: Maximum main memory to use for agp memory: 816M
agpgart: Detected 8060K stolen memory.
agpgart: AGP aperture is 128M @ 0xe0000000
[drm] Initialized drm 1.0.0 20040925
serio: i8042 AUX port at 0x60,0x64 irq 12
serio: i8042 KBD port at 0x60,0x64 irq 1
Serial: 8250/16550 driver $Revision: 1.90 $ 8 ports, IRQ sharing disabled
ACPI: PCI Interrupt Link [LNKB] enabled at IRQ 4
PCI: setting IRQ 4 as level-triggered
ACPI: PCI interrupt 0000:00:1f.6[B] -> GSI 4 (level, low) -> IRQ 4
parport: PnPBIOS parport detected.
parport0: PC-style at 0x3bc, irq 5 [PCSPP(,...)]
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered
Floppy drive(s): fd0 is 1.44M
FDC 0 is a National Semiconductor PC87306
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
ICH4: IDE controller at PCI slot 0000:00:1f.1
PCI: Enabling device 0000:00:1f.1 (0005 -> 0007)
ACPI: PCI Interrupt Link [LNKC] enabled at IRQ 7
PCI: setting IRQ 7 as level-triggered
ACPI: PCI interrupt 0000:00:1f.1[A] -> GSI 7 (level, low) -> IRQ 7
ICH4: chipset revision 1
ICH4: not 100% native mode: will probe irqs later
ide0: BM-DMA at 0x1810-0x1817, BIOS settings: hda:DMA, hdb:pio
ide1: BM-DMA at 0x1818-0x181f, BIOS settings: hdc:DMA, hdd:pio
Probing IDE interface ide0...
hda: IC25N060ATMR04-0, ATA DISK drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
Probing IDE interface ide1...
hdc: DW-224E, ATAPI CD/DVD-ROM drive
ide1 at 0x170-0x177,0x376 on irq 15
Probing IDE interface ide2...
Probing IDE interface ide3...
Probing IDE interface ide4...
Probing IDE interface ide5...
hda: max request size: 128KiB
hda: Host Protected Area detected.
current capacity is 111668597 sectors (57174 MB)
native capacity is 117210240 sectors (60011 MB)
hda: Host Protected Area disabled.
hda: 117210240 sectors (60011 MB) w/7884KiB Cache, CHS=65535/16/63, UDMA(100)
hda: cache flushes supported
/dev/ide/host0/bus0/target0/lun0: p1 p2 p3 p4
hdc: ATAPI 24X DVD-ROM CD-R/RW drive, 1658kB Cache, UDMA(33)
Uniform CD-ROM driver Revision: 3.20
ACPI: PCI Interrupt Link [LNKH] enabled at IRQ 7
ACPI: PCI interrupt 0000:00:1d.7[D] -> GSI 7 (level, low) -> IRQ 7
ehci_hcd 0000:00:1d.7: Intel Corp. 82801DB/DBM (ICH4/ICH4-M) USB 2.0 EHCI Controller
PCI: Setting latency timer of device 0000:00:1d.7 to 64
ehci_hcd 0000:00:1d.7: irq 7, pci mem 0xd0100000
ehci_hcd 0000:00:1d.7: new USB bus registered, assigned bus number 1
PCI: cache line size of 128 is not supported by device 0000:00:1d.7
ehci_hcd 0000:00:1d.7: USB 2.0 initialized, EHCI 1.00, driver 10 Dec 2004
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 6 ports detected
USB Universal Host Controller Interface driver v2.2
ACPI: PCI Interrupt Link [LNKA] enabled at IRQ 3
PCI: setting IRQ 3 as level-triggered
ACPI: PCI interrupt 0000:00:1d.0[A] -> GSI 3 (level, low) -> IRQ 3
uhci_hcd 0000:00:1d.0: Intel Corp. 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #1
PCI: Setting latency timer of device 0000:00:1d.0 to 64
uhci_hcd 0000:00:1d.0: irq 3, io base 0x1820
uhci_hcd 0000:00:1d.0: new USB bus registered, assigned bus number 2
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 2 ports detected
ACPI: PCI Interrupt Link [LNKD] enabled at IRQ 9
PCI: setting IRQ 9 as level-triggered
ACPI: PCI interrupt 0000:00:1d.1[B] -> GSI 9 (level, low) -> IRQ 9
uhci_hcd 0000:00:1d.1: Intel Corp. 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #2
PCI: Setting latency timer of device 0000:00:1d.1 to 64
uhci_hcd 0000:00:1d.1: irq 9, io base 0x1840
uhci_hcd 0000:00:1d.1: new USB bus registered, assigned bus number 3
hub 3-0:1.0: USB hub found
hub 3-0:1.0: 2 ports detected
ACPI: PCI interrupt 0000:00:1d.2[C] -> GSI 7 (level, low) -> IRQ 7
uhci_hcd 0000:00:1d.2: Intel Corp. 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #3
PCI: Setting latency timer of device 0000:00:1d.2 to 64
uhci_hcd 0000:00:1d.2: irq 7, io base 0x1860
uhci_hcd 0000:00:1d.2: new USB bus registered, assigned bus number 4
hub 4-0:1.0: USB hub found
hub 4-0:1.0: 2 ports detected
usb 3-2: new low speed USB device using uhci_hcd and address 2
input: USB HID v1.10 Mouse [Logitech USB Receiver] on usb-0000:00:1d.1-2
usbcore: registered new driver usbhid
drivers/usb/input/hid-core.c: v2.0:USB HID core driver
mice: PS/2 mouse device common for all mice
input: AT Translated Set 2 keyboard on isa0060/serio0
input: PS/2 Generic Mouse on isa0060/serio1
I2O subsystem v$Rev$
i2o: max drivers = 8
I2O Configuration OSM v$Rev$
I2O ProcFS OSM v$Rev$
Advanced Linux Sound Architecture Driver Version 1.0.8 (Thu Jan 13 09:39:32 2005 UTC).
ACPI: PCI interrupt 0000:00:1f.5[B] -> GSI 4 (level, low) -> IRQ 4
PCI: Setting latency timer of device 0000:00:1f.5 to 64
intel8x0_measure_ac97_clock: measured 49335 usecs
intel8x0: clocking to 48000
ACPI: PCI interrupt 0000:00:1f.6[B] -> GSI 4 (level, low) -> IRQ 4
PCI: Setting latency timer of device 0000:00:1f.6 to 64
ALSA device list:
#0: Intel 82801DB-ICH4 with AD1981B at 0xd0100c00, irq 4
#1: Intel 82801DB-ICH4 Modem at 0x2400, irq 4
oprofile: using timer interrupt.
NET: Registered protocol family 2
IP: routing cache hash table of 8192 buckets, 64Kbytes
TCP established hash table entries: 131072 (order: 8, 1048576 bytes)
TCP bind hash table entries: 65536 (order: 6, 262144 bytes)
TCP: Hash tables configured (established 131072 bind 65536)
NET: Registered protocol family 1
NET: Registered protocol family 17
ACPI wakeup devices:
LID SLPB PCI0 BLAN CBS0 USB0 USB1 USB2 AC97
ACPI: (supports S0 S3 S4 S5)
ReiserFS: hda4: found reiserfs format "3.6" with standard journal
ReiserFS: hda4: using ordered data mode
ReiserFS: hda4: journal params: device hda4, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30
ReiserFS: hda4: checking transaction log (hda4)
ReiserFS: hda4: Using r5 hash to sort names
VFS: Mounted root (reiserfs filesystem) readonly.
Mounted devfs on /dev
Freeing unused kernel memory: 160k freed
Adding 1005472k swap on /dev/hda3. Priority:-1 extents:1
tg3.c:v3.23 (February 15, 2005)
ACPI: PCI interrupt 0000:02:00.0[A] -> GSI 3 (level, low) -> IRQ 3
eth0: Tigon3 [partno(BCM95901A50) rev 3001 PHY(5705)] (PCI:33MHz:32-bit) 10/100BaseT Ethernet 00:06:1b:c4:30:dd
eth0: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] Split[0] WireSpeed[1] TSOcap[1]
NTFS volume version 3.1.
tg3: eth0: Link is up at 100 Mbps, full duplex.
tg3: eth0: Flow control is on for TX and on for RX.
tg3: eth0: Link is up at 100 Mbps, full duplex.
tg3: eth0: Flow control is on for TX and on for RX.
ACPI: PCI interrupt 0000:02:01.0[A] -> GSI 4 (level, low) -> IRQ 4
Yenta: CardBus bridge found at 0000:02:01.0 [1014:054e]
Yenta: adjusting diagnostic: 40 -> 60
Yenta: Using CSCINT to route CSC interrupts to PCI
Yenta: Routing CardBus interrupts to PCI
Yenta TI: socket 0000:02:01.0, mfunc 0x011c1112, devctl 0x64
Yenta: ISA IRQ mask 0x0c00, PCI irq 4
Socket status: 30000020
irq 4: nobody cared!
[<c01036ce>] dump_stack+0x1e/0x30
[<c0136d4b>] __report_bad_irq+0x2b/0xa0
[<c0136e56>] note_interrupt+0x66/0xa0
[<c0136817>] __do_IRQ+0x147/0x150
[<c0104c66>] do_IRQ+0x26/0x40
[<c01032ae>] common_interrupt+0x1a/0x20
[<c011c84a>] do_softirq+0x2a/0x30
[<c011c916>] irq_exit+0x36/0x40
[<c0104c6b>] do_IRQ+0x2b/0x40
[<c01032ae>] common_interrupt+0x1a/0x20
[<c0101110>] cpu_idle+0x50/0x60
[<c052681f>] start_kernel+0x14f/0x170
[<c010019f>] 0xc010019f
handlers:
[<c0389eb0>] (snd_intel8x0_interrupt+0x0/0x260)
[<c038d1b0>] (snd_intel8x0_interrupt+0x0/0x260)
[<f8a4a8a0>] (yenta_interrupt+0x0/0x40 [yenta_socket])
Disabling IRQ #4
ath_hal: module license 'Proprietary' taints kernel.
ath_hal: 0.9.14.9 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413)
wlan: 0.8.4.5 (EXPERIMENTAL)
ath_rate_onoe: 1.0
ath_pci: 0.9.4.12 (EXPERIMENTAL)
PCI: Enabling device 0000:03:00.0 (0000 -> 0002)
ACPI: PCI interrupt 0000:03:00.0[A] -> GSI 4 (level, low) -> IRQ 4
ath0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps
ath0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps
ath0: mac 5.9 phy 4.3 radio 4.6
ath0: 802.11 address: 00:09:5b:ec:43:cd
ath0: Use hw queue 0 for WME_AC_BE traffic
ath0: Use hw queue 1 for WME_AC_BK traffic
ath0: Use hw queue 2 for WME_AC_VI traffic
ath0: Use hw queue 3 for WME_AC_VO traffic
ath0: Atheros 5212: mem=0x40800000, irq=4

-- output from lspci -vv
0000:00:00.0 Host bridge: Intel Corporation 82852/82855 GM/GME/PM/GMV Processor to I/O Controller (rev 01)
Subsystem: IBM: Unknown device 054a
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort+ >SERR- <PERR-
Latency: 0
Region 0: Memory at <unassigned> (32-bit, prefetchable)
Capabilities: [40] #09 [e105]

0000:00:00.1 System peripheral: Intel Corporation 82852/82855 GM/GME/PM/GMV Processor to I/O Controller (rev 01)
Subsystem: IBM: Unknown device 054b
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 0

0000:00:00.3 System peripheral: Intel Corporation 82852/82855 GM/GME/PM/GMV Processor to I/O Controller (rev 01)
Subsystem: IBM: Unknown device 054c
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 0

0000:00:02.0 VGA compatible controller: Intel Corporation 82852/855GM Integrated Graphics Device (rev 01) (prog-if 00 [VGA])
Subsystem: IBM: Unknown device 0543
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 0
Interrupt: pin A routed to IRQ 3
Region 0: Memory at e0000000 (32-bit, prefetchable)
Region 1: Memory at d0000000 (32-bit, non-prefetchable) [size=512K]
Region 2: I/O ports at 1800 [size=8]
Capabilities: [d0] Power Management version 1
Flags: PMEClk- DSI+ D1+ D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-

0000:00:02.1 Display controller: Intel Corporation 82852/855GM Integrated Graphics Device (rev 01)
Subsystem: IBM: Unknown device 0543
Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Region 0: Memory at e8000000 (32-bit, prefetchable)
Region 1: Memory at d0080000 (32-bit, non-prefetchable) [size=512K]
Capabilities: [d0] Power Management version 1
Flags: PMEClk- DSI+ D1+ D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-

0000:00:1d.0 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #1 (rev 01) (prog-if 00 [UHCI])
Subsystem: IBM: Unknown device 0547
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 0
Interrupt: pin A routed to IRQ 3
Region 4: I/O ports at 1820 [size=32]

0000:00:1d.1 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #2 (rev 01) (prog-if 00 [UHCI])
Subsystem: IBM: Unknown device 0547
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 0
Interrupt: pin B routed to IRQ 9
Region 4: I/O ports at 1840 [size=32]

0000:00:1d.2 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #3 (rev 01) (prog-if 00 [UHCI])
Subsystem: IBM: Unknown device 0547
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 0
Interrupt: pin C routed to IRQ 7
Region 4: I/O ports at 1860 [size=32]

0000:00:1d.7 USB Controller: Intel Corporation 82801DB/DBM (ICH4/ICH4-M) USB2 EHCI Controller (rev 01) (prog-if 20 [EHCI])
Subsystem: IBM: Unknown device 0548
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 0
Interrupt: pin D routed to IRQ 7
Region 0: Memory at d0100000 (32-bit, non-prefetchable)
Capabilities: [50] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [58] #0a [2080]

0000:00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev 81) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR+
Latency: 0
Bus: primary=00, secondary=02, subordinate=05, sec-latency=64
I/O behind bridge: 00003000-00006fff
Memory behind bridge: d0200000-dfffffff
Prefetchable memory behind bridge: f0000000-f7ffffff
BridgeCtl: Parity- SERR- NoISA+ VGA- MAbort- >Reset- FastB2B-

0000:00:1f.0 ISA bridge: Intel Corporation 82801DBM (ICH4-M) LPC Interface Bridge (rev 01)
Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 0

0000:00:1f.1 IDE interface: Intel Corporation 82801DBM (ICH4-M) IDE Controller (rev 01) (prog-if 8a [Master SecP PriP])
Subsystem: IBM: Unknown device 0547
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 0
Interrupt: pin A routed to IRQ 7
Region 0: I/O ports at <unassigned>
Region 1: I/O ports at <unassigned>
Region 2: I/O ports at <unassigned>
Region 3: I/O ports at <unassigned>
Region 4: I/O ports at 1810 [size=16]
Region 5: Memory at 40000000 (32-bit, non-prefetchable) [size=1K]

0000:00:1f.3 SMBus: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) SMBus Controller (rev 01)
Subsystem: IBM: Unknown device 0547
Control: I/O+ Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Interrupt: pin B routed to IRQ 4
Region 4: I/O ports at 1880 [size=32]

0000:00:1f.5 Multimedia audio controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) AC'97 Audio Controller (rev 01)
Subsystem: IBM: Unknown device 0542
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 0
Interrupt: pin B routed to IRQ 4
Region 0: I/O ports at 1c00
Region 1: I/O ports at 18c0 [size=64]
Region 2: Memory at d0100c00 (32-bit, non-prefetchable) [size=512]
Region 3: Memory at d0100800 (32-bit, non-prefetchable) [size=256]
Capabilities: [50] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-

0000:00:1f.6 Modem: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) AC'97 Modem Controller (rev 01) (prog-if 00 [Generic])
Subsystem: IBM: Unknown device 0544
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 0
Interrupt: pin B routed to IRQ 4
Region 0: I/O ports at 2400
Region 1: I/O ports at 2000 [size=128]
Capabilities: [50] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-

0000:02:00.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5901 100Base-TX (rev 01)
Subsystem: IBM ThinkPad R40e (2684-HVG) builtin ethernet controller
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B-
Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 64 (16000ns min), cache line size 08
Interrupt: pin A routed to IRQ 3
Region 0: Memory at d0200000 (64-bit, non-prefetchable)
Capabilities: [48] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot+,D3cold+)
Status: D0 PME-Enable- DSel=0 DScale=1 PME-
Capabilities: [50] Vital Product Data
Capabilities: [58] Message Signalled Interrupts: 64bit+ Queue=0/3 Enable-
Address: ffbafffffffefffc Data: dfff

0000:02:01.0 CardBus bridge: Texas Instruments PCI1410 PC card Cardbus Controller (rev 02)
Subsystem: IBM: Unknown device 054e
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 168, cache line size 20
Interrupt: pin A routed to IRQ 4
Region 0: Memory at 40001000 (32-bit, non-prefetchable)
Bus: primary=02, secondary=03, subordinate=06, sec-latency=176
Memory window 0: 40400000-407ff000 (prefetchable)
Memory window 1: 40800000-40bff000
I/O window 0: 00004000-000040ff
I/O window 1: 00004400-000044ff
BridgeCtl: Parity- SERR- ISA- VGA- MAbort- >Reset- 16bInt- PostWrite+
16-bit legacy interface ports at 0001

0000:03:00.0 Ethernet controller: Atheros Communications, Inc. AR5212 802.11abg NIC (rev 01)
Subsystem: Netgear: Unknown device 4b00
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 168 (2500ns min, 7000ns max), cache line size 20
Interrupt: pin A routed to IRQ 4
Region 0: Memory at 40800000 (32-bit, non-prefetchable)
Capabilities: [44] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=2 PME-

--
Jonas Oreland, Software Engineer
MySQL AB, http://www.mysql.com


2005-03-18 21:44:27

by Daniel Ritz

[permalink] [raw]
Subject: Re: yenta_socket "nobody cared - Disabling IRQ #4"

hi

it's the second time now i see this problem with an atheros chipset in
combination with a TI bridge. last time it was the 1225...
attached a patch that could help...

rgds
-daniel

--------------

for TI bridges: turn off interrupts during card power-on. this seems
to be neccessary for some combination of TI bridges with at least CB cards
with atheros chipset...problem is that they produce an interrupt storm
during power-on so the kernel happens to disable the IRQ which is a bad
thing (tm).
adds a generic hook function so that a socket driver can hook into
almost anywhere (by adding more hook points of course). this is the
cleanest way i can think of. and it allows adding more workarounds
for more problems...
for the TI specific interrupt on-off stuff just save the MFUNC register
and set it to 0 to disable all interrupts, restore it afterwards.

Signed-off-by: Daniel Ritz <[email protected]>



--- 1.22/drivers/pcmcia/ti113x.h 2005-03-11 21:32:12 +01:00
+++ edited/drivers/pcmcia/ti113x.h 2005-03-18 22:06:12 +01:00
@@ -591,6 +591,35 @@
}
}

+
+/*
+ * TI specifiy parts for generic hook. generic hook really is specifiy to the
+ * chipset so there's no point having it in yenta_socket.c (for now)
+ *
+ * some TI's with some CB's produces interrupt storm on power on. it has been
+ * seen with atheros wlan cards on TI1225 and TI1410. solution is simply to
+ * disable any CB interrupts during this time.
+ */
+static int ti12xx_hook(struct pcmcia_socket *sock, int operation)
+{
+ struct yenta_socket *socket = container_of(sock, struct yenta_socket, socket);
+
+ switch (operation) {
+ case HOOK_POWER_PRE:
+ socket->saved_state[0] = config_readl(socket, TI122X_MFUNC);
+ config_writel(socket, TI122X_MFUNC, 0);
+ break;
+
+ case HOOK_POWER_POST:
+ config_writel(socket, TI122X_MFUNC, socket->saved_state[0]);
+ break;
+ default:
+ break;
+ }
+
+ return 0;
+}
+
static int ti12xx_override(struct yenta_socket *socket)
{
u32 val, val_orig;
@@ -633,6 +662,9 @@
ti12xx_irqroute_func0(socket);
else
ti12xx_irqroute_func1(socket);
+
+ /* install generic hook */
+ socket->socket.ops->generic_hook = ti12xx_hook;

return ti_override(socket);
}
--- 1.125/drivers/pcmcia/cs.c 2005-03-11 21:32:13 +01:00
+++ edited/drivers/pcmcia/cs.c 2005-03-12 21:22:38 +01:00
@@ -508,6 +508,10 @@
cs_err(skt, "unsupported voltage key.\n");
return CS_BAD_TYPE;
}
+
+ if (skt->ops->generic_hook)
+ skt->ops->generic_hook(skt, HOOK_POWER_PRE);
+
skt->socket.flags = 0;
skt->ops->set_socket(skt, &skt->socket);

@@ -522,7 +526,12 @@
return CS_BAD_TYPE;
}

- return socket_reset(skt);
+ status = socket_reset(skt);
+
+ if (skt->ops->generic_hook)
+ skt->ops->generic_hook(skt, HOOK_POWER_POST);
+
+ return status;
}

/*
--- 1.48/include/pcmcia/ss.h 2005-03-11 21:32:13 +01:00
+++ edited/include/pcmcia/ss.h 2005-03-12 21:22:39 +01:00
@@ -77,6 +77,11 @@
/* Use this just for bridge windows */
#define MAP_IOSPACE 0x20

+/* generic hook operations */
+#define HOOK_POWER_PRE 0x01
+#define HOOK_POWER_POST 0x02
+
+
typedef struct pccard_io_map {
u_char map;
u_char flags;
@@ -113,6 +118,7 @@
int (*set_socket)(struct pcmcia_socket *sock, socket_state_t *state);
nt (*set_io_map)(struct pcmcia_socket *sock, struct pccard_io_map *io);
int (*set_mem_map)(struct pcmcia_socket *sock, struct pccard_mem_map *mem);
+ int (*generic_hook)(struct pcmcia_socket *sock, int operation);
};

struct pccard_resource_ops {

2005-03-18 23:00:38

by Jonas Oreland

[permalink] [raw]
Subject: Re: yenta_socket "nobody cared - Disabling IRQ #4"

Daniel Ritz wrote:
> hi

Hi

Thanks for your effort!

>
> it's the second time now i see this problem with an atheros chipset in
> combination with a TI bridge. last time it was the 1225...
> attached a patch that could help...
>

Report:
1) It works somewhat better. irq doesn't get disabled.
2) however wlan card get disfunctional. I haven't been able to contact my wap
even if i'm standing on it...
3) unplug has resulted in kernel panic (twice)
(btw: how do I do to capture and report those)
4) when unlug don't produce kernel panic, then there is no way of power-oning that card again.
5) booting with the card inserted makes it not power on when yenta_socket is loaded (module)

comment: the card being disfunction could have something to with the driver.
but before it worked sometimes...

> --------------
>
> for TI bridges: turn off interrupts during card power-on. this seems
> to be neccessary for some combination of TI bridges with at least CB cards
> with atheros chipset...problem is that they produce an interrupt storm
> during power-on so the kernel happens to disable the IRQ which is a bad
> thing (tm).
> adds a generic hook function so that a socket driver can hook into
> almost anywhere (by adding more hook points of course). this is the
> cleanest way i can think of. and it allows adding more workarounds
> for more problems...
> for the TI specific interrupt on-off stuff just save the MFUNC register
> and set it to 0 to disable all interrupts, restore it afterwards.
>
> Signed-off-by: Daniel Ritz <[email protected]>

Some thoughts: (not I'm neither pcmcia nor linux expert).

The "irq storm", shouldn't that be "acked" in someway.
I.e. the card produced a lot of irq's (that get ignored)
isn't the "real" solution to capture them, and "do something clever"?

Instead of just "shutting the card down".

hmmm...wonder if that made sence

Question: Why do you think that it worked sometimes before?

/Jonas

ps.
but the hook was/is nice :-)
ds.

2005-03-18 23:38:18

by Francois Romieu

[permalink] [raw]
Subject: Re: yenta_socket "nobody cared - Disabling IRQ #4"

Jonas Oreland <[email protected]> :
[...]
> Report:
> 1) It works somewhat better. irq doesn't get disabled.
> 2) however wlan card get disfunctional. I haven't been able to contact my
> wap
> even if i'm standing on it...
> 3) unplug has resulted in kernel panic (twice)
> (btw: how do I do to capture and report those)
> 4) when unlug don't produce kernel panic, then there is no way of
> power-oning that card again.
> 5) booting with the card inserted makes it not power on when yenta_socket
> is loaded (module)
>
> comment: the card being disfunction could have something to with the driver.
> but before it worked sometimes...

static int
ath_pci_probe(struct pci_dev *pdev, const struct pci_device_id *id)
[...]
if (request_irq(dev->irq, ath_intr, SA_SHIRQ, dev->name, dev)) {
printk(KERN_WARNING "%s: request_irq failed\n", dev->name);
goto bad3;
}
[...]
athname = ath_hal_probe(id->vendor, id->device);
printk(KERN_INFO "%s: %s: mem=0x%lx, irq=%d\n",
dev->name, athname ? athname : "Atheros ???", phymem, dev->irq);

/* ready to process interrupts */
sc->aps_sc.sc_invalid = 0;

No sources for ath_hal_probe, too bad.

However, even without any sources, a driver which includes an "I am not ready
to process interrupts" flag and issue request_irq() without having disabled
the device first makes me a bit nervous.

--
Ueimor

2005-03-18 23:52:45

by Daniel Ritz

[permalink] [raw]
Subject: Re: yenta_socket "nobody cared - Disabling IRQ #4"

On Saturday 19 March 2005 00:00, Jonas Oreland wrote:
> Daniel Ritz wrote:
> > hi
>
> Hi
>
> Thanks for your effort!
>
> >
> > it's the second time now i see this problem with an atheros chipset in
> > combination with a TI bridge. last time it was the 1225...
> > attached a patch that could help...
> >
>
> Report:
> 1) It works somewhat better. irq doesn't get disabled.
> 2) however wlan card get disfunctional. I haven't been able to contact my wap
> even if i'm standing on it...

i was afraid that it could have some side effects. it's probably because just
writing a 0 to the MFUNC register is stupid...can you try to replace ti12xx_hook()
in ti113x.h with this one?

static int ti12xx_hook(struct pcmcia_socket *sock, int operation)
{
struct yenta_socket *socket = container_of(sock, struct yenta_socket, socket);
u32 tmp;

switch (operation) {
case HOOK_POWER_PRE:
tmp = config_readl(socket, TI122X_MFUNC);
socket->saved_state[0] = tmp;
config_writel(socket, TI122X_MFUNC, tmp & ~(TI122X_MFUNC0_MASK | TI122X_MFUNC3_MASK));
break;

case HOOK_POWER_POST:
config_writel(socket, TI122X_MFUNC, socket->saved_state[0]);
break;
default:
break;
}

return 0;
}

also try in a second step to replace the following lines in cs.c:
(~line 529)
status = socket_reset(skt);

if (skt->ops->generic_hook)
skt->ops->generic_hook(skt, HOOK_POWER_POST);


with

if (skt->ops->generic_hook)
skt->ops->generic_hook(skt, HOOK_POWER_POST);

status = socket_reset(skt);


> 3) unplug has resulted in kernel panic (twice)
> (btw: how do I do to capture and report those)

at a first guess i would blame the atheros driver which taints the kernel.
so try _not_ loading the atheros driver and see if it still happens. if
so the messages please. to capture them you can use a serial console
(null modem cable to second pc). check out the "remote serial console"
howto on http://www.tldp.org

> 4) when unlug don't produce kernel panic, then there is no way of power-oning that card again.
> 5) booting with the card inserted makes it not power on when yenta_socket is loaded (module)

anything in dmesg then?

>
> comment: the card being disfunction could have something to with the driver.
> but before it worked sometimes...
>
> > --------------
> >
> > for TI bridges: turn off interrupts during card power-on. this seems
> > to be neccessary for some combination of TI bridges with at least CB cards
> > with atheros chipset...problem is that they produce an interrupt storm
> > during power-on so the kernel happens to disable the IRQ which is a bad
> > thing (tm).
> > adds a generic hook function so that a socket driver can hook into
> > almost anywhere (by adding more hook points of course). this is the
> > cleanest way i can think of. and it allows adding more workarounds
> > for more problems...
> > for the TI specific interrupt on-off stuff just save the MFUNC register
> > and set it to 0 to disable all interrupts, restore it afterwards.
> >
> > Signed-off-by: Daniel Ritz <[email protected]>
>
> Some thoughts: (not I'm neither pcmcia nor linux expert).
>
> The "irq storm", shouldn't that be "acked" in someway.
> I.e. the card produced a lot of irq's (that get ignored)
> isn't the "real" solution to capture them, and "do something clever"?
>
> Instead of just "shutting the card down".
>
> hmmm...wonder if that made sence

it's the CB device that is making the interrupt storm and the TI
bridge is stupid enough to let the interrupts thru during power
on. thing is you can't ack them at this time because the cardbus
resources are not set up at this time and ack'ing an IRQ is
device specifc.

>
> Question: Why do you think that it worked sometimes before?

pure luck?

>
> /Jonas
>
> ps.
> but the hook was/is nice :-)
> ds.
>

can you also give me a dump of /proc/iomem?

rgds
-daniel

2005-03-19 08:05:50

by Jonas Oreland

[permalink] [raw]
Subject: Re: yenta_socket "nobody cared - Disabling IRQ #4" - WORKING!!

Hi again and thx again,

SUMMARY: It's working with new hook (wo/ trying second part)
I'll post again if error comes up again.

Daniel Ritz wrote:
> On Saturday 19 March 2005 00:00, Jonas Oreland wrote:
>>
>>>it's the second time now i see this problem with an atheros chipset in
>>>combination with a TI bridge. last time it was the 1225...
>>>attached a patch that could help...
>>>
>>
>>Report:
>>1) It works somewhat better. irq doesn't get disabled.
>>2) however wlan card get disfunctional. I haven't been able to contact my wap
>> even if i'm standing on it...
>
>
> i was afraid that it could have some side effects. it's probably because just
> writing a 0 to the MFUNC register is stupid...can you try to replace ti12xx_hook()
> in ti113x.h with this one?
>

yes, now it works!!! (limited testing)
I tried rebooting plugging/unplugging/swsuspending maybe 6 times.
All of them working, that a new record :-)

Should I try "second step" anyway?

>>3) unplug has resulted in kernel panic (twice)
>> (btw: how do I do to capture and report those)
>
>
> at a first guess i would blame the atheros driver which taints the kernel.
> so try _not_ loading the atheros driver and see if it still happens. if
> so the messages please. to capture them you can use a serial console
> (null modem cable to second pc). check out the "remote serial console"
> howto on http://www.tldp.org

might be...the driver...haven't tried wo/ it.

note: I never got this after new hook,

>
>
>>4) when unlug don't produce kernel panic, then there is no way of power-oning that card again.
>>5) booting with the card inserted makes it not power on when yenta_socket is loaded (module)
>
>
> anything in dmesg then?

zero

>>comment: the card being disfunction could have something to with the driver.
>>but before it worked sometimes...
>>
>>
>>>--------------
>>>
>>>for TI bridges: turn off interrupts during card power-on. this seems
>>>to be neccessary for some combination of TI bridges with at least CB cards
>>>with atheros chipset...problem is that they produce an interrupt storm
>>>during power-on so the kernel happens to disable the IRQ which is a bad
>>>thing (tm).
>>>adds a generic hook function so that a socket driver can hook into
>>>almost anywhere (by adding more hook points of course). this is the
>>>cleanest way i can think of. and it allows adding more workarounds
>>>for more problems...
>>>for the TI specific interrupt on-off stuff just save the MFUNC register
>>>and set it to 0 to disable all interrupts, restore it afterwards.
>>>
>>>Signed-off-by: Daniel Ritz <[email protected]>
>>
>>Some thoughts: (not I'm neither pcmcia nor linux expert).
>>
>>The "irq storm", shouldn't that be "acked" in someway.
>>I.e. the card produced a lot of irq's (that get ignored)
>>isn't the "real" solution to capture them, and "do something clever"?
>>
>>Instead of just "shutting the card down".
>>
>>hmmm...wonder if that made sence
>
>
> it's the CB device that is making the interrupt storm and the TI
> bridge is stupid enough to let the interrupts thru during power
> on. thing is you can't ack them at this time because the cardbus
> resources are not set up at this time and ack'ing an IRQ is
> device specifc.

ok

>>Question: Why do you think that it worked sometimes before?
>
>
> pure luck?

How about 2.4? can you compare cs code with 2.6?
It always worked in 2.4...

/Jonas

> can you also give me a dump of /proc/iomem?

00000000-0009efff : System RAM
0009f000-0009ffff : reserved
000a0000-000bffff : Video RAM area
000c0000-000c7fff : Video ROM
000cd000-000ce7ff : Adapter ROM
000e0000-000effff : Extension ROM
000f0000-000fffff : System ROM
00100000-0f6effff : System RAM
00100000-00409648 : Kernel code
00409649-005183ff : Kernel data
0f6f0000-0f6fffff : reserved
0f700000-3f6effff : System RAM
3f6f0000-3f6f7fff : ACPI Tables
3f6f8000-3f6f9fff : ACPI Non-volatile Storage
3f700000-3fffffff : reserved
40000000-400003ff : 0000:00:1f.1
40001000-40001fff : 0000:02:01.0
40001000-40001fff : yenta_socket
40400000-407fffff : PCI CardBus #03
40800000-40bfffff : PCI CardBus #03
40800000-4080ffff : 0000:03:00.0
40800000-4080ffff : ath
d0000000-d007ffff : 0000:00:02.0
d0080000-d00fffff : 0000:00:02.1
d0100000-d01003ff : 0000:00:1d.7
d0100000-d01003ff : ehci_hcd
d0100800-d01008ff : 0000:00:1f.5
d0100800-d01008ff : Intel 82801DB-ICH4
d0100c00-d0100dff : 0000:00:1f.5
d0100c00-d0100dff : Intel 82801DB-ICH4
d0200000-d020ffff : 0000:02:00.0
d0200000-d020ffff : tg3
e0000000-e7ffffff : 0000:00:02.0
e8000000-efffffff : 0000:00:02.1
ff800000-ffffffff : reserved

2005-03-19 21:15:31

by Daniel Ritz

[permalink] [raw]
Subject: Re: yenta_socket "nobody cared - Disabling IRQ #4" - WORKING!!

On Saturday 19 March 2005 09:05, Jonas Oreland wrote:
> Hi again and thx again,
>
> SUMMARY: It's working with new hook (wo/ trying second part)
> I'll post again if error comes up again.

that's good news!

>
> Daniel Ritz wrote:
> > On Saturday 19 March 2005 00:00, Jonas Oreland wrote:
> >>
> >>>it's the second time now i see this problem with an atheros chipset in
> >>>combination with a TI bridge. last time it was the 1225...
> >>>attached a patch that could help...
> >>>
> >>
> >>Report:
> >>1) It works somewhat better. irq doesn't get disabled.
> >>2) however wlan card get disfunctional. I haven't been able to contact my wap
> >> even if i'm standing on it...
> >
> >
> > i was afraid that it could have some side effects. it's probably because just
> > writing a 0 to the MFUNC register is stupid...can you try to replace ti12xx_hook()
> > in ti113x.h with this one?
> >
>
> yes, now it works!!! (limited testing)
> I tried rebooting plugging/unplugging/swsuspending maybe 6 times.
> All of them working, that a new record :-)
>
> Should I try "second step" anyway?

not neccessarily..

>
> >>3) unplug has resulted in kernel panic (twice)
> >> (btw: how do I do to capture and report those)
> >
> >
> > at a first guess i would blame the atheros driver which taints the kernel.
> > so try _not_ loading the atheros driver and see if it still happens. if
> > so the messages please. to capture them you can use a serial console
> > (null modem cable to second pc). check out the "remote serial console"
> > howto on http://www.tldp.org
>
> might be...the driver...haven't tried wo/ it.
>
> note: I never got this after new hook,
>
> >
> >
> >>4) when unlug don't produce kernel panic, then there is no way of power-oning that card again.
> >>5) booting with the card inserted makes it not power on when yenta_socket is loaded (module)
> >
> >
> > anything in dmesg then?
>
> zero
>
> >>comment: the card being disfunction could have something to with the driver.
> >>but before it worked sometimes...
> >>
> >>
> >>>--------------
> >>>
> >>>for TI bridges: turn off interrupts during card power-on. this seems
> >>>to be neccessary for some combination of TI bridges with at least CB cards
> >>>with atheros chipset...problem is that they produce an interrupt storm
> >>>during power-on so the kernel happens to disable the IRQ which is a bad
> >>>thing (tm).
> >>>adds a generic hook function so that a socket driver can hook into
> >>>almost anywhere (by adding more hook points of course). this is the
> >>>cleanest way i can think of. and it allows adding more workarounds
> >>>for more problems...
> >>>for the TI specific interrupt on-off stuff just save the MFUNC register
> >>>and set it to 0 to disable all interrupts, restore it afterwards.
> >>>
> >>>Signed-off-by: Daniel Ritz <[email protected]>
> >>
> >>Some thoughts: (not I'm neither pcmcia nor linux expert).
> >>
> >>The "irq storm", shouldn't that be "acked" in someway.
> >>I.e. the card produced a lot of irq's (that get ignored)
> >>isn't the "real" solution to capture them, and "do something clever"?
> >>
> >>Instead of just "shutting the card down".
> >>
> >>hmmm...wonder if that made sence
> >
> >
> > it's the CB device that is making the interrupt storm and the TI
> > bridge is stupid enough to let the interrupts thru during power
> > on. thing is you can't ack them at this time because the cardbus
> > resources are not set up at this time and ack'ing an IRQ is
> > device specifc.
>
> ok
>
> >>Question: Why do you think that it worked sometimes before?
> >
> >
> > pure luck?
>
> How about 2.4? can you compare cs code with 2.6?
> It always worked in 2.4...

the problem is there also, it just doesn't show up. 2.6 checks for
every interrupt if one of the handlers took care of it. if not the
dump is printed and a counter is increased. if this counter reaches
a limit the interrupt line is disabled. 2.4 doesn't do it so the interrupt
storm is there too, it just recovers...you can try with 2.4...after you
have the card up do a "cat /proc/interrupts" and you'll see a high
number for yenta's interrupt line...

>
> /Jonas
>
> > can you also give me a dump of /proc/iomem?
>
[snip /proc/iomem]

it was just to be sure nothing is mapped over existing physical RAM
which is not the case...

i'll cook up a more flexible patch which handles other TI bridges
as well (the current one will fail on some older controllers and
on 2-slot controllers)

rgds
-daniel