Re: yenta_socket "nobody cared - Disabling IRQ #4"

Re: yenta_socket "nobody cared - Disabling IRQ #4"

[Daniel Ritz]

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 <daniel.ritz@gmx.ch>



--- 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 {

Re: yenta_socket "nobody cared - Disabling IRQ #4"

[Jonas Oreland]

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 <daniel.ritz@gmx.ch>

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.

Re: yenta_socket "nobody cared - Disabling IRQ #4"

[Francois Romieu]

Jonas Oreland <jonas.oreland@mysql.com> :
[...]
> 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

Re: yenta_socket "nobody cared - Disabling IRQ #4"

[Daniel Ritz]

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 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 <daniel.ritz@gmx.ch>
> 
> 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

Re: yenta_socket "nobody cared - Disabling IRQ #4" - WORKING!!

[Jonas Oreland]

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@gmx.ch>
>>
>>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

Re: yenta_socket "nobody cared - Disabling IRQ #4" - WORKING!!

[Daniel Ritz]

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 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@gmx.ch>
> >>
> >>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