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 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 - 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: 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: 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 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 - 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"
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 <[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
-
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"
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
-
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"
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.h2005-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, >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.h2005-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_IOSPACE0x20
+/* generic hook operations */
+#define HOOK_POWER_PRE 0x01
+#define HOOK_POWER_POST0x02
+
+
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 {
-
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/
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 0x last_index 0x01 cftable_entry_cb 0x01 [default] [master] [parity] [serr] [fast back] Vcc Vnom 3300mV Istatic 25mA Iavg 450mA Ipeak 500mA irq mask 0x [level] mem_base 1 BAR 1 size 64kb [mem] vers_1 7.1, "Atheros Communications, Inc.", "AR5001--", "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 ([EMAIL PROTECTED]) (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: - 0009f000 (usable) BIOS-e820: 0009f000 - 000a (reserved) BIOS-e820: 000ce000 - 000d (reserved) BIOS-e820: 000dc000 - 0010 (reserved) BIOS-e820: 0010 - 0f6f (usable) BIOS-e820: 0f6f - 0f70 (reserved) BIOS-e820: 0f70 - 3f6f (usable) BIOS-e820: 3f6f - 3f6f8000 (ACPI data) BIOS-e820: 3f6f8000 - 3f6fa000 (ACPI NVS) BIOS-e820: 3f70 - 4000 (reserved) BIOS-e820: ff80 - 0001 (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 IBMTP-1T0x1081 LTP 0x) @ 0x3f6f2435 ACPI: FADT (v002 IBMTP-1T0x1081 IBM 0x0001) @ 0x3f6f2479 ACPI: SSDT (v001 IBMTP-1T0x1081 MSFT 0x010d) @ 0x3f6f252d ACPI: ECDT (v001 IBMTP-1T0x1081 IBM 0x0001) @ 0x3f6f7f87 ACPI: BOOT (v001 IBMTP-1T0x1081 LTP 0x0001) @ 0x3f6f7fd8 ACPI: DSDT (v001 IBMTP-1T0x1081 MSFT 0x010d) @ 0x Allocating PCI resources starting at 4000 (gap: 4000:bf80) 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 4400 CPU: After vendor identify, caps: bfebf9ff 4400 CPU: Trace cache: 12K uops, L1 D cache: 8K CPU: L2 cache: 512K CPU: After all inits, caps: bfebf9ff 0080 4400 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
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 0x last_index 0x01 cftable_entry_cb 0x01 [default] [master] [parity] [serr] [fast back] Vcc Vnom 3300mV Istatic 25mA Iavg 450mA Ipeak 500mA irq mask 0x [level] mem_base 1 BAR 1 size 64kb [mem] vers_1 7.1, Atheros Communications, Inc., AR5001--, 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 ([EMAIL PROTECTED]) (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: - 0009f000 (usable) BIOS-e820: 0009f000 - 000a (reserved) BIOS-e820: 000ce000 - 000d (reserved) BIOS-e820: 000dc000 - 0010 (reserved) BIOS-e820: 0010 - 0f6f (usable) BIOS-e820: 0f6f - 0f70 (reserved) BIOS-e820: 0f70 - 3f6f (usable) BIOS-e820: 3f6f - 3f6f8000 (ACPI data) BIOS-e820: 3f6f8000 - 3f6fa000 (ACPI NVS) BIOS-e820: 3f70 - 4000 (reserved) BIOS-e820: ff80 - 0001 (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 IBMTP-1T0x1081 LTP 0x) @ 0x3f6f2435 ACPI: FADT (v002 IBMTP-1T0x1081 IBM 0x0001) @ 0x3f6f2479 ACPI: SSDT (v001 IBMTP-1T0x1081 MSFT 0x010d) @ 0x3f6f252d ACPI: ECDT (v001 IBMTP-1T0x1081 IBM 0x0001) @ 0x3f6f7f87 ACPI: BOOT (v001 IBMTP-1T0x1081 LTP 0x0001) @ 0x3f6f7fd8 ACPI: DSDT (v001 IBMTP-1T0x1081 MSFT 0x010d) @ 0x Allocating PCI resources starting at 4000 (gap: 4000:bf80) 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 4400 CPU: After vendor identify, caps: bfebf9ff 4400 CPU: Trace cache: 12K uops, L1 D cache: 8K CPU: L2 cache: 512K CPU: After all inits, caps: bfebf9ff 0080 4400 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
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.h2005-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.h2005-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_IOSPACE0x20
+/* generic hook operations */
+#define HOOK_POWER_PRE 0x01
+#define HOOK_POWER_POST0x02
+
+
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 {
-
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
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
-
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
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 [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
-
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/
