Bug 16133
Summary: | iwlagn stops working after hibernation to disk | ||
---|---|---|---|
Product: | Drivers | Reporter: | Mehmet Giritli (mehmet) |
Component: | Platform | Assignee: | acpi_platform-drivers (acpi_platform-drivers) |
Status: | CLOSED OBSOLETE | ||
Severity: | normal | CC: | alan, linville, reinette.chatre |
Priority: | P1 | ||
Hardware: | x86-64 | ||
OS: | Linux | ||
Kernel Version: | 2.6.33 | Subsystem: | |
Regression: | No | Bisected commit-id: | |
Attachments: |
dmesg with hibernation and resume
Read rfkill status on resume |
Description
Mehmet Giritli
2010-06-05 21:53:36 UTC
Created attachment 26664 [details]
dmesg with hibernation and resume
I'm seeing a number of reports like this, not sure if they are all iwlwifi or not... 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. 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? 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. Created attachment 26828 [details]
Read rfkill status on resume
Before you try the debugging in previous comment ... could you please try attached patch?
(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. (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. BTW, I applied the patch on 2.6.33. Hope it doesn't make a difference. 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? ...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! 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 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... (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? (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... 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. This definitely strikes me as a platform driver issue. (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... |