crash with rt61pci when resuming with card ejected

crash with rt61pci when resuming with card ejected

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 502 bytes --]

Hi,

Maybe it was stupid, but with USB it always works, I suspended, ejected
the card (because I had to go and didn't want to resume) while suspended
and resumed when I arrived at uni, to find the laptop crashing.

http://johannes.sipsolutions.net/files/rt61pci-resume-crash.jpg

Sorry it's so unreadable, there wasn't much light and I only had my crap
cell phone.

Here's some of the backtrace:
NIP: rt61pci_mcu_request
LR: rt2x00leds_unregister_led

rt2x00leds_unregister

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: crash with rt61pci when resuming with card ejected

[Ivo van Doorn]

Hi,

> Maybe it was stupid, but with USB it always works, I suspended, ejected
> the card (because I had to go and didn't want to resume) while suspended
> and resumed when I arrived at uni, to find the laptop crashing.
> 
> http://johannes.sipsolutions.net/files/rt61pci-resume-crash.jpg
> 
> Sorry it's so unreadable, there wasn't much light and I only had my crap
> cell phone.
> 
> Here's some of the backtrace:
> NIP: rt61pci_mcu_request
> LR: rt2x00leds_unregister_led
> 
> rt2x00leds_unregister

Heh well these 2 functions are the most important ones in the trace anyway. ;)
The only reason I see that rt61pci_mcu_request might fail like this is if writel()
crashes when a device is unplugged while a driver still has a reference to the
register base pointer which came from ioremap().
But I don't know if that would be a valid assumption. :S

Ivo

Re: crash with rt61pci when resuming with card ejected

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 597 bytes --]

On Thu, 2008-10-30 at 22:47 +0100, Ivo van Doorn wrote:

> Heh well these 2 functions are the most important ones in the trace anyway. ;)
> The only reason I see that rt61pci_mcu_request might fail like this is if writel()
> crashes when a device is unplugged while a driver still has a reference to the
> register base pointer which came from ioremap().
> But I don't know if that would be a valid assumption. :S

I don't think it should, at least not on pcmcia. I can reproduce and
send you a better picture, but I don't know what it'll show in terms of
"why it crashed".

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: crash with rt61pci when resuming with card ejected

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 1001 bytes --]

On Thu, 2008-10-30 at 22:47 +0100, Ivo van Doorn wrote:
> Hi,
> 
> > Maybe it was stupid, but with USB it always works, I suspended, ejected
> > the card (because I had to go and didn't want to resume) while suspended
> > and resumed when I arrived at uni, to find the laptop crashing.
> > 
> > http://johannes.sipsolutions.net/files/rt61pci-resume-crash.jpg

> Heh well these 2 functions are the most important ones in the trace anyway. ;)
> The only reason I see that rt61pci_mcu_request might fail like this is if writel()
> crashes when a device is unplugged while a driver still has a reference to the
> register base pointer which came from ioremap().
> But I don't know if that would be a valid assumption. :S

It looks like a NULL dereference to me. Look at

http://johannes.sipsolutions.net/files/rt61pci-resume-crash2.jpg

(ignore the first backtrace, it's something I always get, but it allows
me to see this oops because it turns on the console early :) )

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: crash with rt61pci when resuming with card ejected

[Ivo van Doorn]

On Friday 31 October 2008, Johannes Berg wrote:
> On Thu, 2008-10-30 at 22:47 +0100, Ivo van Doorn wrote:
> > Hi,
> > 
> > > Maybe it was stupid, but with USB it always works, I suspended, ejected
> > > the card (because I had to go and didn't want to resume) while suspended
> > > and resumed when I arrived at uni, to find the laptop crashing.
> > > 
> > > http://johannes.sipsolutions.net/files/rt61pci-resume-crash.jpg
> 
> > Heh well these 2 functions are the most important ones in the trace anyway. ;)
> > The only reason I see that rt61pci_mcu_request might fail like this is if writel()
> > crashes when a device is unplugged while a driver still has a reference to the
> > register base pointer which came from ioremap().
> > But I don't know if that would be a valid assumption. :S
> 
> It looks like a NULL dereference to me. Look at
> 
> http://johannes.sipsolutions.net/files/rt61pci-resume-crash2.jpg
> 
> (ignore the first backtrace, it's something I always get, but it allows
> me to see this oops because it turns on the console early :) )

Hmm, it looks like CSR base is NULL, after which the H2M_MAILBOX_CSR
offset is added to it (0x2100)

The strange part is thet CSR is freed and set to NULL _after_ the
rt2x00lib_remove_dev() call...
Oh wait never mind, I get the picture, I missed the "ejected _while_ suspended"
part. I think what is happening is that first the suspend handler is called,
and during resume not the resume handler but the remove handler is running,
and rt2x00 doesn't protect against that.

Could you check if below patch does the trick? If I am not mistaken only the
LED handler actually accesses the hardware to make sure they are off.

Thanks,

Ivo
---

diff --git a/drivers/net/wireless/rt2x00/rt2x00leds.c b/drivers/net/wireless/rt2x00/rt2x00leds.c
index b362a1c..bbac5c1 100644
--- a/drivers/net/wireless/rt2x00/rt2x00leds.c
+++ b/drivers/net/wireless/rt2x00/rt2x00leds.c
@@ -125,6 +125,7 @@ static int rt2x00leds_register_led(struct rt2x00_dev *rt2x00dev,
 	int retval;
 
 	led->led_dev.name = name;
+	led->led_dev.brightness = LED_OFF;
 
 	retval = led_classdev_register(device, &led->led_dev);
 	if (retval) {
@@ -196,10 +197,12 @@ exit_fail:
 	rt2x00leds_unregister(rt2x00dev);
 }
 
-static void rt2x00leds_unregister_led(struct rt2x00_led *led)
+static inline void rt2x00leds_unregister_led(struct rt2x00_led *led)
 {
+	if (!(led->led_dev.flags & LED_SUSPENDED))
+		led->led_dev.brightness_set(&led->led_dev, LED_OFF);
 	led_classdev_unregister(&led->led_dev);
-	led->led_dev.brightness_set(&led->led_dev, LED_OFF);
+
 	led->flags &= ~LED_REGISTERED;
 }
 
@@ -213,22 +216,34 @@ void rt2x00leds_unregister(struct rt2x00_dev *rt2x00dev)
 		rt2x00leds_unregister_led(&rt2x00dev->led_radio);
 }
 
+static inline void rt2x00leds_suspend_led(struct rt2x00_led *led)
+{
+	led->led_dev.brightness_set(&led->led_dev, LED_OFF);
+	led_classdev_suspend(&led->led_dev);
+}
+
 void rt2x00leds_suspend(struct rt2x00_dev *rt2x00dev)
 {
 	if (rt2x00dev->led_qual.flags & LED_REGISTERED)
-		led_classdev_suspend(&rt2x00dev->led_qual.led_dev);
+		rt2x00leds_suspend_led(&rt2x00dev->led_qual);
 	if (rt2x00dev->led_assoc.flags & LED_REGISTERED)
-		led_classdev_suspend(&rt2x00dev->led_assoc.led_dev);
+		rt2x00leds_suspend_led(&rt2x00dev->led_assoc);
 	if (rt2x00dev->led_radio.flags & LED_REGISTERED)
-		led_classdev_suspend(&rt2x00dev->led_radio.led_dev);
+		rt2x00leds_suspend_led(&rt2x00dev->led_radio);
+}
+
+static inline void rt2x00leds_resume_led(struct rt2x00_led *led)
+{
+	led_classdev_resume(&led->led_dev);
+	led->led_dev.brightness_set(&led->led_dev, led->led_dev.brightness);
 }
 
 void rt2x00leds_resume(struct rt2x00_dev *rt2x00dev)
 {
 	if (rt2x00dev->led_radio.flags & LED_REGISTERED)
-		led_classdev_resume(&rt2x00dev->led_radio.led_dev);
+		rt2x00leds_resume_led(&rt2x00dev->led_radio);
 	if (rt2x00dev->led_assoc.flags & LED_REGISTERED)
-		led_classdev_resume(&rt2x00dev->led_assoc.led_dev);
+		rt2x00leds_resume_led(&rt2x00dev->led_assoc);
 	if (rt2x00dev->led_qual.flags & LED_REGISTERED)
-		led_classdev_resume(&rt2x00dev->led_qual.led_dev);
+		rt2x00leds_resume_led(&rt2x00dev->led_qual);
 }

Re: crash with rt61pci when resuming with card ejected

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 831 bytes --]

On Fri, 2008-10-31 at 20:31 +0100, Ivo van Doorn wrote:

> Hmm, it looks like CSR base is NULL, after which the H2M_MAILBOX_CSR
> offset is added to it (0x2100)
> 
> The strange part is thet CSR is freed and set to NULL _after_ the
> rt2x00lib_remove_dev() call...
> Oh wait never mind, I get the picture, I missed the "ejected _while_ suspended"
> part. I think what is happening is that first the suspend handler is called,
> and during resume not the resume handler but the remove handler is running,
> and rt2x00 doesn't protect against that.
> 
> Could you check if below patch does the trick? If I am not mistaken only the
> LED handler actually accesses the hardware to make sure they are off.

Now it crashes in config_pairwise_key or something like that, I can send
you the image if you want.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: crash with rt61pci when resuming with card ejected

[Ivo van Doorn]

On Friday 31 October 2008, Johannes Berg wrote:
> On Fri, 2008-10-31 at 20:31 +0100, Ivo van Doorn wrote:
> 
> > Hmm, it looks like CSR base is NULL, after which the H2M_MAILBOX_CSR
> > offset is added to it (0x2100)
> > 
> > The strange part is thet CSR is freed and set to NULL _after_ the
> > rt2x00lib_remove_dev() call...
> > Oh wait never mind, I get the picture, I missed the "ejected _while_ suspended"
> > part. I think what is happening is that first the suspend handler is called,
> > and during resume not the resume handler but the remove handler is running,
> > and rt2x00 doesn't protect against that.
> > 
> > Could you check if below patch does the trick? If I am not mistaken only the
> > LED handler actually accesses the hardware to make sure they are off.
> 
> Now it crashes in config_pairwise_key or something like that, I can send
> you the image if you want.

No need. :)
I assume mac80211 calls set_key() to disable all hardware keys when
ieee80211_unregister_hw() is being called. I'll cook up a patch to catch
that as well.

Ivo

Re: crash with rt61pci when resuming with card ejected

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 616 bytes --]

On Fri, 2008-10-31 at 23:01 +0100, Ivo van Doorn wrote:

> > Now it crashes in config_pairwise_key or something like that, I can send
> > you the image if you want.
> 
> No need. :)
> I assume mac80211 calls set_key() to disable all hardware keys when
> ieee80211_unregister_hw() is being called. I'll cook up a patch to catch
> that as well.

Yep, that's it, it does it by way of turning off all interfaces,
removing all stations etc. Of course, if it would implement
suspend/resume properly then it would have removed the keys already
before suspend and be putting them back at resume...

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: crash with rt61pci when resuming with card ejected

[Ivo van Doorn]

On Friday 31 October 2008, Johannes Berg wrote:
> On Fri, 2008-10-31 at 23:01 +0100, Ivo van Doorn wrote:
> 
> > > Now it crashes in config_pairwise_key or something like that, I can send
> > > you the image if you want.
> > 
> > No need. :)
> > I assume mac80211 calls set_key() to disable all hardware keys when
> > ieee80211_unregister_hw() is being called. I'll cook up a patch to catch
> > that as well.
> 
> Yep, that's it, it does it by way of turning off all interfaces,
> removing all stations etc. Of course, if it would implement
> suspend/resume properly then it would have removed the keys already
> before suspend and be putting them back at resume...

Could you try this patch? It doesn't matter if it is on top or as a replacement
of my previous patch.

This patch should also fix suspend/resume handling in general, I suddenly realized
there was quite a big bug in there regarding EEPROM/CSR handling. 

Thanks,

Ivo

---
diff --git a/drivers/net/wireless/rt2x00/rt2x00pci.c b/drivers/net/wireless/rt2x00/rt2x00pci.c
index adf2876..d2c6bc9 100644
--- a/drivers/net/wireless/rt2x00/rt2x00pci.c
+++ b/drivers/net/wireless/rt2x00/rt2x00pci.c
@@ -350,8 +350,6 @@ int rt2x00pci_suspend(struct pci_dev *pci_dev, pm_message_t state)
 	if (retval)
 		return retval;
 
-	rt2x00pci_free_reg(rt2x00dev);
-
 	pci_save_state(pci_dev);
 	pci_disable_device(pci_dev);
 	return pci_set_power_state(pci_dev, pci_choose_state(pci_dev, state));
@@ -371,10 +369,6 @@ int rt2x00pci_resume(struct pci_dev *pci_dev)
 		return -EIO;
 	}
 
-	retval = rt2x00pci_alloc_reg(rt2x00dev);
-	if (retval)
-		return retval;
-
 	retval = rt2x00lib_resume(rt2x00dev);
 	if (retval)
 		goto exit_free_reg;
diff --git a/drivers/net/wireless/rt2x00/rt2x00usb.c b/drivers/net/wireless/rt2x00/rt2x00usb.c
index b73a7e0..6198cf3 100644
--- a/drivers/net/wireless/rt2x00/rt2x00usb.c
+++ b/drivers/net/wireless/rt2x00/rt2x00usb.c
@@ -597,8 +597,6 @@ int rt2x00usb_suspend(struct usb_interface *usb_intf, pm_message_t state)
 	if (retval)
 		return retval;
 
-	rt2x00usb_free_reg(rt2x00dev);
-
 	/*
 	 * Decrease usbdev refcount.
 	 */
@@ -616,10 +614,6 @@ int rt2x00usb_resume(struct usb_interface *usb_intf)
 
 	usb_get_dev(interface_to_usbdev(usb_intf));
 
-	retval = rt2x00usb_alloc_reg(rt2x00dev);
-	if (retval)
-		return retval;
-
 	retval = rt2x00lib_resume(rt2x00dev);
 	if (retval)
 		goto exit_free_reg;

Re: crash with rt61pci when resuming with card ejected

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 445 bytes --]

On Sat, 2008-11-01 at 09:58 +0100, Ivo van Doorn wrote:

> Could you try this patch? It doesn't matter if it is on top or as a replacement
> of my previous patch.
> 
> This patch should also fix suspend/resume handling in general, I suddenly realized
> there was quite a big bug in there regarding EEPROM/CSR handling. 

Now it just hangs at resume, rather than crashing. At suspend it already
logs some MCU errors though.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: crash with rt61pci when resuming with card ejected

[Ivo van Doorn]

On Saturday 01 November 2008, Johannes Berg wrote:
> On Sat, 2008-11-01 at 09:58 +0100, Ivo van Doorn wrote:
> 
> > Could you try this patch? It doesn't matter if it is on top or as a replacement
> > of my previous patch.
> > 
> > This patch should also fix suspend/resume handling in general, I suddenly realized
> > there was quite a big bug in there regarding EEPROM/CSR handling. 
> 
> Now it just hangs at resume, rather than crashing. At suspend it already
> logs some MCU errors though.

Hmm that is strange, those MCU errors could only come from right before the code I
just changed. :S

In any case, could you revert the previous patches and try this. This is the same LED patch
as before, but I have added the check for set_key() to return immediately when this is called
while the module is busy unloading.

Ivo
---
diff --git a/drivers/net/wireless/rt2x00/rt2x00leds.c b/drivers/net/wireless/rt2x00/rt2x00leds.c
index b362a1c..bbac5c1 100644
--- a/drivers/net/wireless/rt2x00/rt2x00leds.c
+++ b/drivers/net/wireless/rt2x00/rt2x00leds.c
@@ -125,6 +125,7 @@ static int rt2x00leds_register_led(struct rt2x00_dev *rt2x00dev,
 	int retval;
 
 	led->led_dev.name = name;
+	led->led_dev.brightness = LED_OFF;
 
 	retval = led_classdev_register(device, &led->led_dev);
 	if (retval) {
@@ -196,10 +197,12 @@ exit_fail:
 	rt2x00leds_unregister(rt2x00dev);
 }
 
-static void rt2x00leds_unregister_led(struct rt2x00_led *led)
+static inline void rt2x00leds_unregister_led(struct rt2x00_led *led)
 {
+	if (!(led->led_dev.flags & LED_SUSPENDED))
+		led->led_dev.brightness_set(&led->led_dev, LED_OFF);
 	led_classdev_unregister(&led->led_dev);
-	led->led_dev.brightness_set(&led->led_dev, LED_OFF);
+
 	led->flags &= ~LED_REGISTERED;
 }
 
@@ -213,22 +216,34 @@ void rt2x00leds_unregister(struct rt2x00_dev *rt2x00dev)
 		rt2x00leds_unregister_led(&rt2x00dev->led_radio);
 }
 
+static inline void rt2x00leds_suspend_led(struct rt2x00_led *led)
+{
+	led->led_dev.brightness_set(&led->led_dev, LED_OFF);
+	led_classdev_suspend(&led->led_dev);
+}
+
 void rt2x00leds_suspend(struct rt2x00_dev *rt2x00dev)
 {
 	if (rt2x00dev->led_qual.flags & LED_REGISTERED)
-		led_classdev_suspend(&rt2x00dev->led_qual.led_dev);
+		rt2x00leds_suspend_led(&rt2x00dev->led_qual);
 	if (rt2x00dev->led_assoc.flags & LED_REGISTERED)
-		led_classdev_suspend(&rt2x00dev->led_assoc.led_dev);
+		rt2x00leds_suspend_led(&rt2x00dev->led_assoc);
 	if (rt2x00dev->led_radio.flags & LED_REGISTERED)
-		led_classdev_suspend(&rt2x00dev->led_radio.led_dev);
+		rt2x00leds_suspend_led(&rt2x00dev->led_radio);
+}
+
+static inline void rt2x00leds_resume_led(struct rt2x00_led *led)
+{
+	led_classdev_resume(&led->led_dev);
+	led->led_dev.brightness_set(&led->led_dev, led->led_dev.brightness);
 }
 
 void rt2x00leds_resume(struct rt2x00_dev *rt2x00dev)
 {
 	if (rt2x00dev->led_radio.flags & LED_REGISTERED)
-		led_classdev_resume(&rt2x00dev->led_radio.led_dev);
+		rt2x00leds_resume_led(&rt2x00dev->led_radio);
 	if (rt2x00dev->led_assoc.flags & LED_REGISTERED)
-		led_classdev_resume(&rt2x00dev->led_assoc.led_dev);
+		rt2x00leds_resume_led(&rt2x00dev->led_assoc);
 	if (rt2x00dev->led_qual.flags & LED_REGISTERED)
-		led_classdev_resume(&rt2x00dev->led_qual.led_dev);
+		rt2x00leds_resume_led(&rt2x00dev->led_qual);
 }
diff --git a/drivers/net/wireless/rt2x00/rt2x00mac.c b/drivers/net/wireless/rt2x00/rt2x00mac.c
index 8fc2315..188f891 100644
--- a/drivers/net/wireless/rt2x00/rt2x00mac.c
+++ b/drivers/net/wireless/rt2x00/rt2x00mac.c
@@ -486,7 +486,9 @@ int rt2x00mac_set_key(struct ieee80211_hw *hw, enum set_key_cmd cmd,
 			struct ieee80211_key_conf *key);
 	struct rt2x00lib_crypto crypto;
 
-	if (!test_bit(CONFIG_SUPPORT_HW_CRYPTO, &rt2x00dev->flags))
+	if (!test_bit(DEVICE_STATE_PRESENT, &rt2x00dev->flags))
+		return 0;
+	else if (!test_bit(CONFIG_SUPPORT_HW_CRYPTO, &rt2x00dev->flags))
 		return -EOPNOTSUPP;
 	else if (key->keylen > 32)
 		return -ENOSPC;

Re: crash with rt61pci when resuming with card ejected

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 1046 bytes --]

On Sat, 2008-11-01 at 11:29 +0100, Ivo van Doorn wrote:
> On Saturday 01 November 2008, Johannes Berg wrote:
> > On Sat, 2008-11-01 at 09:58 +0100, Ivo van Doorn wrote:
> > 
> > > Could you try this patch? It doesn't matter if it is on top or as a replacement
> > > of my previous patch.
> > > 
> > > This patch should also fix suspend/resume handling in general, I suddenly realized
> > > there was quite a big bug in there regarding EEPROM/CSR handling. 
> > 
> > Now it just hangs at resume, rather than crashing. At suspend it already
> > logs some MCU errors though.
> 
> Hmm that is strange, those MCU errors could only come from right before the code I
> just changed. :S
> 
> In any case, could you revert the previous patches and try this. This is the same LED patch
> as before, but I have added the check for set_key() to return immediately when this is called
> while the module is busy unloading.

Now I've upgraded wireless-testing and am running into the BUG_ON you
added for antenna diversity...

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: crash with rt61pci when resuming with card ejected

[Ivo van Doorn]

On Saturday 01 November 2008, Johannes Berg wrote:
> On Sat, 2008-11-01 at 11:29 +0100, Ivo van Doorn wrote:
> > On Saturday 01 November 2008, Johannes Berg wrote:
> > > On Sat, 2008-11-01 at 09:58 +0100, Ivo van Doorn wrote:
> > > 
> > > > Could you try this patch? It doesn't matter if it is on top or as a replacement
> > > > of my previous patch.
> > > > 
> > > > This patch should also fix suspend/resume handling in general, I suddenly realized
> > > > there was quite a big bug in there regarding EEPROM/CSR handling. 
> > > 
> > > Now it just hangs at resume, rather than crashing. At suspend it already
> > > logs some MCU errors though.
> > 
> > Hmm that is strange, those MCU errors could only come from right before the code I
> > just changed. :S
> > 
> > In any case, could you revert the previous patches and try this. This is the same LED patch
> > as before, but I have added the check for set_key() to return immediately when this is called
> > while the module is busy unloading.
> 
> Now I've upgraded wireless-testing and am running into the BUG_ON you
> added for antenna diversity...

Hmm, that's odd.. I'll look into it. Patches could take some time :(

Ivo

Re: crash with rt61pci when resuming with card ejected

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 1606 bytes --]

On Sat, 2008-11-01 at 16:25 +0100, Ivo van Doorn wrote:
> On Saturday 01 November 2008, Johannes Berg wrote:
> > On Sat, 2008-11-01 at 11:29 +0100, Ivo van Doorn wrote:
> > > On Saturday 01 November 2008, Johannes Berg wrote:
> > > > On Sat, 2008-11-01 at 09:58 +0100, Ivo van Doorn wrote:
> > > > 
> > > > > Could you try this patch? It doesn't matter if it is on top or as a replacement
> > > > > of my previous patch.
> > > > > 
> > > > > This patch should also fix suspend/resume handling in general, I suddenly realized
> > > > > there was quite a big bug in there regarding EEPROM/CSR handling. 
> > > > 
> > > > Now it just hangs at resume, rather than crashing. At suspend it already
> > > > logs some MCU errors though.
> > > 
> > > Hmm that is strange, those MCU errors could only come from right before the code I
> > > just changed. :S
> > > 
> > > In any case, could you revert the previous patches and try this. This is the same LED patch
> > > as before, but I have added the check for set_key() to return immediately when this is called
> > > while the module is busy unloading.
> > 
> > Now I've upgraded wireless-testing and am running into the BUG_ON you
> > added for antenna diversity...
> 
> Hmm, that's odd.. I'll look into it. Patches could take some time :(

That was with that patch applied, but I don't think it caused it. No
worries, I don't usually actually use the rt61 card, but had used it for
monitoring the night before I wrote my bug report, suspended, and
ejected it while suspended the next morning because I had to run... :)

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: crash with rt61pci when resuming with card ejected

[Ivo van Doorn]

On Saturday 01 November 2008, Johannes Berg wrote:
> On Sat, 2008-11-01 at 16:25 +0100, Ivo van Doorn wrote:
> > On Saturday 01 November 2008, Johannes Berg wrote:
> > > On Sat, 2008-11-01 at 11:29 +0100, Ivo van Doorn wrote:
> > > > On Saturday 01 November 2008, Johannes Berg wrote:
> > > > > On Sat, 2008-11-01 at 09:58 +0100, Ivo van Doorn wrote:
> > > > > 
> > > > > > Could you try this patch? It doesn't matter if it is on top or as a replacement
> > > > > > of my previous patch.
> > > > > > 
> > > > > > This patch should also fix suspend/resume handling in general, I suddenly realized
> > > > > > there was quite a big bug in there regarding EEPROM/CSR handling. 
> > > > > 
> > > > > Now it just hangs at resume, rather than crashing. At suspend it already
> > > > > logs some MCU errors though.
> > > > 
> > > > Hmm that is strange, those MCU errors could only come from right before the code I
> > > > just changed. :S
> > > > 
> > > > In any case, could you revert the previous patches and try this. This is the same LED patch
> > > > as before, but I have added the check for set_key() to return immediately when this is called
> > > > while the module is busy unloading.
> > > 
> > > Now I've upgraded wireless-testing and am running into the BUG_ON you
> > > added for antenna diversity...
> > 
> > Hmm, that's odd.. I'll look into it. Patches could take some time :(
> 
> That was with that patch applied, but I don't think it caused it. No
> worries, I don't usually actually use the rt61 card, but had used it for
> monitoring the night before I wrote my bug report, suspended, and
> ejected it while suspended the next morning because I had to run... :)

I think I found something, I'm sending a patch series for John in a few minutes,
it will contain a fix for this BUG_ON().

Ivo