Bug 16133 - iwlagn stops working after hibernation to disk
Summary: iwlagn stops working after hibernation to disk
Status: CLOSED OBSOLETE
Alias: None
Product: Drivers
Classification: Unclassified
Component: Platform (show other bugs)
Hardware: x86-64 Linux
: P1 normal
Assignee: acpi_platform-drivers@kernel-bugs.osdl.org
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-06-05 21:53 UTC by Mehmet Giritli
Modified: 2012-06-14 17:23 UTC (History)
3 users (show)

See Also:
Kernel Version: 2.6.33
Subsystem:
Regression: No
Bisected commit-id:


Attachments
dmesg with hibernation and resume (46.28 KB, text/plain)
2010-06-05 21:54 UTC, Mehmet Giritli
Details
Read rfkill status on resume (891 bytes, patch)
2010-06-17 17:09 UTC, Reinette Chatre
Details | Diff

Description Mehmet Giritli 2010-06-05 21:53:36 UTC
After hibernation to disk, my wireless is not usable anymore. Suspend to ram is ok. This only happens with hibernation. I have to shutdown and restart the computer to have wireless working again.

After resume:

iwconfig

lo        no wireless extensions.

wlan0     IEEE 802.11abgn  Mode:Managed  Access Point: Not-Associated   
          Tx-Power=off   
          Retry  long limit:7   RTS thr:off   Fragment thr:off
          Encryption key:off
          Power Management:off

When I try to bring up the interface with: ifconfig wlan0 up, I get: SIOCSIFFLAGS: Unknown error 132

I have a feeling this has to do with rfkill?

Attaching dmesg.
Comment 1 Mehmet Giritli 2010-06-05 21:54:35 UTC
Created attachment 26664 [details]
dmesg with hibernation and resume
Comment 2 John W. Linville 2010-06-07 13:47:54 UTC
I'm seeing a number of reports like this, not sure if they are all iwlwifi or not...
Comment 3 Reinette Chatre 2010-06-16 22:45:23 UTC
This seems to be, as you say, an rfkill issue. When the system comes back up the driver detects that RFKILL is enabled. Note the message "RF_KILL bit toggled to disable radio" in your logs. What platform is this? Which platform driver are you using?

Does it help at all if you enable/disable the RFKILL switch on your laptop when this happens? It may help to install the rfkill utility to take a look at rfkill state after hibernation and then also take a look at how the state changes when you enable/disable the switch a few times at that point.
Comment 4 Mehmet Giritli 2010-06-17 12:31:32 UTC
Hi,

This is on a amd64, gentoo linux.

I installed and run rfkill utility and this is what I got after hibernation:

0: phy0: Wireless LAN
	Soft blocked: no
	Hard blocked: yes
2: hci0: Bluetooth
	Soft blocked: no
	Hard blocked: no

Before hibernating, phy0 was not blocked as above obviously. I tried to turn on and off the switch but it did not help at all. What else can I do now?
Comment 5 Reinette Chatre 2010-06-17 16:27:41 UTC
Could you please be more specific about your platform? What brand of laptop is this? What I would like to know is which platform module (sony, dell, hp, etc.) is being used.

Please try two things:
- After hibernation, run "rfkill event" while running this turn on and off the rfkill switch and record what switch changes you made and how it is reflected in the "rfkill event" output.

- Do the same test, but unload your platform module right after hibernation.
Comment 6 Reinette Chatre 2010-06-17 17:09:53 UTC
Created attachment 26828 [details]
Read rfkill status on resume

Before you try the debugging in previous  comment ... could you please try attached patch?
Comment 7 Mehmet Giritli 2010-06-17 21:12:34 UTC
(In reply to comment #5)
> Could you please be more specific about your platform? What brand of laptop
> is
> this? What I would like to know is which platform module (sony, dell, hp,
> etc.)
> is being used.

This is on a Toshiba A350 22Z laptop. I am using omnibook driver for some features but there is no difference at all when I leave the module out.

> 
> Please try two things:
> - After hibernation, run "rfkill event" while running this turn on and off
> the
> rfkill switch and record what switch changes you made and how it is reflected
> in the "rfkill event" output.

I see no response from "rfkill event" when I flip the switch. It is ok before hibernation.

> 
> - Do the same test, but unload your platform module right after hibernation.

Makes no difference.
Comment 8 Mehmet Giritli 2010-06-17 21:14:58 UTC
(In reply to comment #6)
> Created an attachment (id=26828) [details]
> Read rfkill status on resume
> 
> Before you try the debugging in previous  comment ... could you please try
> attached patch?

Sorry, makes no difference to the above results.
Comment 9 Mehmet Giritli 2010-06-17 21:20:12 UTC
BTW, I applied the patch on 2.6.33. Hope it doesn't make a difference.
Comment 10 Reinette Chatre 2010-06-18 17:34:56 UTC
Isn't the omnibook driver for old HP laptops? This driver is not even in the kernel and seems not to have been updated on its sf page in a long time. Where did you get the driver? Is there not an in-kernel platform driver that supports this platform? I see there are some toshiba options in the Kconfig, do they work?
Comment 11 Mehmet Giritli 2010-06-18 18:17:04 UTC
...And also for Toshiba satellite laptops. Yes, it is not maintained but are we sure that this is the problem?

I don't use this omnibook driver for anything except using bluetooth. Wireless works perfectly without (without loading the module) it as well. rfkill switch also works ok without it, _only_ except after a hibernation...

I get the module from gentoo portage tree. This is the only way of activating bluetooth feature for satellite laptops afaik, so a snapshot is kept by distros...

However, I did check it with the omnibook driver as well and I noticed that omnibook detects rfkill events after hibernation (by checking the contents of the file /proc/omnibook/wifi), unlike the rfkill utility and the kernel!
Comment 12 Mehmet Giritli 2010-06-19 12:31:42 UTC
And also, wireless can be turned on with the omnibook driver with a command like:

echo 1 > /proc/omnibook/wifi

But again, I think this is not the issue here?
Comment 13 Mehmet Giritli 2010-06-19 12:34:22 UTC
I also noticed that there is a rfkill bluetooth option in Kconfig for toshiba laptops and it works for my bluetooth as well (this must be something new, I didn't notice it before). But there is nothing similar for wireless rfkill...
Comment 14 Reinette Chatre 2010-06-21 20:45:37 UTC
(In reply to comment #12)
> And also, wireless can be turned on with the omnibook driver with a command
> like:
> 
> echo 1 > /proc/omnibook/wifi
> 
> But again, I think this is not the issue here?

I asked around and it is likely that BIOS disables rfkill during hibernation. In this case it is the platform driver's responsibility to re-enable things as you show is possible here.

One way that was proposed to check on this is if you try to hibernate without telling BIOS  ("echo shutdown > /sys/power/disk").

Perhaps it is also possible to check rfkill value in BIOS before you resume from hibernate?
Comment 15 Mehmet Giritli 2010-06-22 06:45:21 UTC
(In reply to comment #14)
> (In reply to comment #12)
> > And also, wireless can be turned on with the omnibook driver with a command
> > like:
> > 
> > echo 1 > /proc/omnibook/wifi
> > 
> > But again, I think this is not the issue here?
> 
> I asked around and it is likely that BIOS disables rfkill during hibernation.
> In this case it is the platform driver's responsibility to re-enable things
> as
> you show is possible here.
> 
> One way that was proposed to check on this is if you try to hibernate without
> telling BIOS  ("echo shutdown > /sys/power/disk").

This command had no effect on my laptop, it doesn't do anything.

> 
> Perhaps it is also possible to check rfkill value in BIOS before you resume
> from hibernate?

If you are asking for information from the BIOS menu, no I don't have any info related to rfkill status there.

It appears to me that a wifi-equivalent of the option I mentioned in comment 13 is necessary. I checked the code (drivers/platform/x86/toshiba_bluetooth.c) and it doesn't seem all that complicated. May be it could be adapted for wifi devices as well? I wish I could contribute instead of just commenting...
Comment 16 Reinette Chatre 2010-06-22 22:04:10 UTC
We need some input from the platform folks here and since the driver you are using it not in the kernel it will be very hard to obtain. Does your distro support this platform driver or just carry it? Perhaps you can ask the platform group of your distro to take a look at this. I do not see anything the driver can do here.
Comment 17 John W. Linville 2010-06-23 17:52:24 UTC
This definitely strikes me as a platform driver issue.
Comment 18 Mehmet Giritli 2010-06-23 19:25:12 UTC
(In reply to comment #16)
> We need some input from the platform folks here and since the driver you are
> using it not in the kernel it will be very hard to obtain. Does your distro
> support this platform driver or just carry it? Perhaps you can ask the
> platform
> group of your distro to take a look at this. I do not see anything the driver
> can do here.

They just carry it and the driver is not maintained. Actually, with the toshiba bluetooth rfkill feature in the kernel I mentioned above, this driver is now completely useless with the exception of wifi rfkill feature to use after hibernation...

Note You need to log in before you can comment on or make changes to this bug.