yenta_socket "nobody cared - Disabling IRQ #4"
hable) [size=1K] :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- SERR- :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- SERR- :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- SERR- :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- SERR- :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- SERR- Reset- 16bInt- PostWrite+ 16-bit legacy interface ports at 0001 :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- SERR- -- Jonas Oreland, Software Engineer MySQL AB, www.mysql.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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 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? -0009efff : System RAM 0009f000-0009 : reserved 000a-000b : Video RAM area 000c-000c7fff : Video ROM 000cd000-000ce7ff : Adapter ROM 000e-000e : Extension ROM 000f-000f : System ROM 0010-0f6e : System RAM 0010-00409648 : Kernel code 00409649-005183ff : Kernel data 0f6f-0f6f : reserved 0f70-3f6e : System RAM 3f6f-3f6f7fff : ACPI Tables 3f6f8000-3f6f9fff : ACPI Non-volatile Storage 3f70-3fff : reserved 4000-43ff : :00:1f.1 40001000-40001fff : :02:01.0 40001000-40001fff : yenta_socket 4040-407f : PCI CardBus #03 4080-40bf : PCI CardBus #03 4080-4080 : :03:00.0 4080-4080 : ath d000-d007 : :00:02.0 d008-d00f : :00:02.1 d010-d01003ff : :00:1d.7 d010-d01003ff : ehci_hcd d0100800-d01008ff : :00:1f.5 d0100800-d01008ff : Intel 82801DB-ICH4 d0100c00-d0100dff : :00:1f.5 d0100c00-d0100dff : Intel 82801DB-ICH4 d020-d020 : :02:00.0 d020-d020 : tg3 e000-e7ff : :00:02.0 e800-efff : :00:02.1 ff80- : reserved - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Major problem with PCMCIA/Yenta system
Hi, I recently had a similar problem, but with a netgear-wg511t However, a kind gentleman called [EMAIL PROTECTED] supplied with me a patch that solved the problem. Not sure if it will work with your card, but you can always try. You should find it on this list, thread topic is "yenta_socket "nobody cared - Disabling IRQ #4"" /Jonas Ron Gage wrote: Greetings: I have been trying to get a recently acquired Cardbus based USB 2.0 card working under 2.6 for the past weekend. It's not going well. Everytime I plug the card into the computer, the entire PCMCIA system just dies, taking my network connectivity with it. I have to do a power off reset to recover. The cardbus card is based on the ALI USB chipset. This shows up as both an EHCI and an OHCI device under 2.6.11.5. My laptop, an older HP Pavilion N5150 has a UHCI based chipset: 00:00.0 Host bridge: Intel Corp. 440BX/ZX/DX - 82443BX/ZX/DX Host bridge (rev 03) 00:01.0 PCI bridge: Intel Corp. 440BX/ZX/DX - 82443BX/ZX/DX AGP bridge (rev 03) 00:04.0 CardBus bridge: Texas Instruments PCI1420 00:04.1 CardBus bridge: Texas Instruments PCI1420 00:07.0 ISA bridge: Intel Corp. 82371AB/EB/MB PIIX4 ISA (rev 02) 00:07.1 IDE interface: Intel Corp. 82371AB/EB/MB PIIX4 IDE (rev 01) 00:07.2 USB Controller: Intel Corp. 82371AB/EB/MB PIIX4 USB (rev 01) 00:07.3 Bridge: Intel Corp. 82371AB/EB/MB PIIX4 ACPI (rev 03) 00:08.0 Multimedia audio controller: ESS Technology ES1988 Allegro-1 (rev 12) 01:01.0 VGA compatible controller: S3 Inc. 86C270-294 Savage/IX-MV (rev 11) 02:00.0 Ethernet controller: Digital Equipment Corporation DECchip 21142/43 (rev 41) My ethernet card is a generic cardbus device. When I insert the new USB 2.0 card, the kernel reports that it's killing off IRQ 11. Here is the actual dump from dmesg: Mar 20 18:38:13 port2 kernel: irq 11: nobody cared! Mar 20 18:38:13 port2 kernel: [] __report_bad_irq+0x2a/0xa0 Mar 20 18:38:13 port2 kernel: [] handle_IRQ_event+0x30/0x70 Mar 20 18:38:13 port2 kernel: [] note_interrupt+0x70/0xb0 Mar 20 18:38:13 port2 kernel: [] __do_IRQ+0xe1/0xf0 Mar 20 18:38:13 port2 kernel: [] do_IRQ+0x19/0x30 Mar 20 18:38:13 port2 kernel: [] common_interrupt+0x1a/0x20 Mar 20 18:38:13 port2 kernel: [] __do_softirq+0x2e/0xa0 Mar 20 18:38:13 port2 kernel: [] do_softirq+0x26/0x30 Mar 20 18:38:13 port2 kernel: [] do_IRQ+0x1e/0x30 Mar 20 18:38:13 port2 kernel: [] common_interrupt+0x1a/0x20 Mar 20 18:38:13 port2 kernel: [] acpi_processor_idle+0x238/0x288 Mar 20 18:38:13 port2 kernel: [] default_idle+0x0/0x30 Mar 20 18:38:13 port2 kernel: [] cpu_idle+0x4c/0x60 Mar 20 18:38:13 port2 kernel: [] start_kernel+0x13c/0x160 Mar 20 18:38:13 port2 kernel: [] unknown_bootoption+0x0/0x200 Mar 20 18:38:13 port2 kernel: handlers: Mar 20 18:38:13 port2 kernel: [] (yenta_interrupt+0x0/0x40 [yenta_socket]) Mar 20 18:38:13 port2 kernel: [] (yenta_interrupt+0x0/0x40 [yenta_socket]) Mar 20 18:38:13 port2 kernel: [] (tulip_interrupt+0x0/0x9c0) Mar 20 18:38:13 port2 kernel: Disabling IRQ #11 Mar 20 18:38:14 port2 kernel: PCI: Enabling device :06:00.0 ( -> 0002) Mar 20 18:38:14 port2 kernel: PCI: Enabling device :06:00.3 ( -> 0002) Mar 20 18:38:16 port2 kernel: ohci_hcd :06:00.0: Unlink after no-IRQ? Controller is probably using the wrong IRQ. Again, when the USB card in inserted, the entire PCMCIA system shuts down and remains unusuable until powered off. Kernel is stock 2.6.11.5. I also tried with 2.6.11, 2.6.10, 2.6.9 and 2.6.7 - same result. Distribution is Slackware 9.1 - gcc is 3.2.3 HELP!!! -- Jonas Oreland, Software Engineer MySQL AB, www.mysql.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
