Re: yenta_socket "nobody cared - Disabling IRQ #4" - WORKING!!
From: Jonas Oreland
Date: Sat Mar 19 2005 - 03:07:04 EST
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 <daniel.ritz@xxxxxx>
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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/