https://bugzilla.novell.com/show_bug.cgi?id=382784 User dkukawka@novell.com added comment https://bugzilla.novell.com/show_bug.cgi?id=382784#c1 Danny Kukawka changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |NEEDINFO Info Provider| |awafaa@opensuse.org --- Comment #1 from Danny Kukawka 2008-04-23 14:41:27 MST --- I can't reproduce problems with the killswitch. What kind of machine do you use? Dell, Lenovo ... ? Please add the full output of lshal to this bug as attachment. Prints the dbus-send command always the same, independed of the killswitch status? What kind of killswitch is it (Keyboard Fn+N combination, extra killswitch ...)? What is the output of "grep . /sys/class/net/wlan*/device/rf_kill" depending of the status of the physical killswitch? -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=382784 User awafaa@opensuse.org added comment https://bugzilla.novell.com/show_bug.cgi?id=382784#c3 --- Comment #3 from Andrew Wafaa 2008-04-24 04:12:23 MST --- Created an attachment (id=210121) --> (https://bugzilla.novell.com/attachment.cgi?id=210121) lshal output -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=382784 Danny Kukawka changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|dkukawka@novell.com |tambet@novell.com Status|NEEDINFO |NEW Info Provider|awafaa@opensuse.org | -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=382784 JP Rosevear changed: What |Removed |Added ---------------------------------------------------------------------------- Status Whiteboard| |gnome-function-does-not-work -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=382784 User tambet@novell.com added comment https://bugzilla.novell.com/show_bug.cgi?id=382784#c6 Tambet Ingo changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|tambet@novell.com |dkukawka@novell.com --- Comment #6 from Tambet Ingo 2008-05-12 01:51:30 MST --- Reassigning. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=382784 User dcbw@redhat.com added comment https://bugzilla.novell.com/show_bug.cgi?id=382784#c8 --- Comment #8 from Dan Williams 2008-05-13 05:15:23 MST --- (In reply to comment #7 from Danny Kukawka)

...

HAL needs to harvest rfkill input events that are simply input layer buttons and create an rfkill switch object in the device list for them

I don't see why HAL should track input events to disable/enable the killswitch. HAL already provide a killswitch object if available in the sysfs.

Because the input events _are_ killswitch events. They are the same thing as the user flipping a switch on the laptop. To the user, it does not matter whether it's an input button Fn+F5, or whether it's a toggle switch somewhere. It's the same thing.

NM (or maybe a desktop application) has to listen to the input events and has to react on them. I don't see a reason why hal should start to listen and handle input events. NM already handle the real killswitch objects (via HAL interfaces), why should hal now start to handle the other input events?

And I don't see why there should be two places to handle the same thing: rfkill. There's still different driver interfaces in the kernel to handle rfkill, because some drivers (ipw2xxx and others) have custom rfkill handling and don't hook into the kernel's rfkill framework yet. HAL is a Hardware Abstraction Layer. rfkill keys are hardware, irregardless of whether they are a toggle switch or a keyboard button. And since there are multiple methods of handling rfkill (kernel rfkill, ipw2x00, input event, vendor-specific module like tpbuttons, fujitsu-laptop, etc) there needs to be a hardware abstraction around them until they all use the same kernel interface.

...

NM would enforce the _policy_ such that if that rfkill object's GetPower() method returned TRUE, NM would kill radios.

Why that? if GetPower() returns TRUE WLAN (or WWAN/Bluetooth) is already disabled. NM should IMO react on the already existing input events, disable the related interface and then call SetPower() if needed.

If you create a machine-wide rfkill switch that just handles input events, then NM would already handle that killswitch automatically just like it handles toggle killswitches. No changes needed to NetworkManager at all. The cases we are talking about are _also_ machines without toggle killswitches, where the _only_ rfkill method is a keyboard key.

...

What I really, really don't want to have is that some rfkill devices go through HAL, but other rfkill devices go through NM.

There are AFAIK _no_ rfkill devices that go through HAL and other that go through NM. HAL provides only an interface to get/set the current state (which is maybe set by the machine itself if you use the rfkill switch). HAL never set the state without someone that called the interface.

...

They either need to _all_ go through HAL or all go through NM, and right now HAL is the place for all rfkill state, not NM.

They have to go through NM. No, right now HAL isn't the place for the state, HAL provide only an interface to get/set the state from sysfs and other places.

No, they WILL NOT go through NetworkManager until there's a standard kernel or HAL interface for ALL rfkill items. It's completely insane to put the hardware abstraction for rfkill stuff in to NetworkManager, when that's exactly what HAL is supposed to be doing right now. There's a standard rfkill interface in HAL: let's use it, not re-implement rfkill in two different places.

Btw. if you want HAL to do this, provide a patch and discuss it upstream. ATM IMO NM should do the handling of the input events and should call HAL to set it to sysfs (or the other tools).

Yes, that's the path forward. Until rfkill methods are standardized with a consistent interface, NetworkManager is not going to talk to them directly. We're NOT going to have 3 different codepaths to handle rfkill in NetworkManager. I see no reason why input event rfkill keys are any different than toggle rfkill keys. How the event gets delivered from the kernel is completely irrelevant; whether it's a sysfs file or an input event does not matter. What matters is having a consistent API for clients of rfkill state (ie, NetworkManager, others). -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=382784 User dcbw@redhat.com added comment https://bugzilla.novell.com/show_bug.cgi?id=382784#c10 --- Comment #10 from Dan Williams 2008-05-13 10:10:00 MST --- (In reply to comment #9 from Danny Kukawka)

(In reply to comment #8 from Dan Williams)

...

Because the input events _are_ killswitch events. They are the same thing as the user flipping a switch on the laptop. To the user, it does not matter whether it's an input button Fn+F5, or whether it's a toggle switch somewhere. It's the same thing.

No, they are not the same (from the technical view). The keyboard input events are not the same as the real kill switch buttons. In the most cases of the real killswitch buttons go through the kernel and the hardware get disabled directly. The input events are different, because they need user interactions

Direct hardware disable only happens in _some_ cases. In some cases it's a GPIO pin that the chip reads directly and notifies the driver. In other cases, the driver reads the value and disables rf. In other cases it's a laptop specific ACPI event. In yet other cases it's a straight input button. I know this.

in many cases (e.g. if the input event isn't only for WLAN but also for bluetooth or WWAN. See for example ThinkPads and Fn+F5 where a tool from Lenovo ask the user what to diable WLAN or/and bluetooth).

That's fine; you could still have a tool to do this if there was a system-wide killswitch in HAL. When the bit flips in HAL, you ask the user what they want to do.

...

And I don't see why there should be two places to handle the same thing: rfkill. There's still different driver interfaces in the kernel to handle rfkill, because some drivers (ipw2xxx and others) have custom rfkill handling and don't hook into the kernel's rfkill framework yet.

There are no different places currently. HAL never set the state of the rfkill. _NEVER_ without an other tool like NM that call hal to do so!

Since the input rfkill button is obviously not tied to a wireless device, there is nothing that SetPower() could or should do. It should simply return an exception when SetPower() is called. It should only report the state of the switch with GetPower(). And yes, there are different places for the rfkill events to come from. There's the kernel's rfkill framework, there's the ipw-specific rfkill stuff in the device's sysfs directory, there's ACPI events, and there's the input-layer buttons. That's 4 different places that rfkill information comes from. NetworkManager is NOT going to abstract these 4 different places. That's HAL's job.

...

HAL is a Hardware Abstraction Layer. rfkill keys are hardware, irregardless of whether they are a toggle switch or a keyboard button. And since there are multiple methods of handling rfkill (kernel rfkill, ipw2x00, input event, vendor-specific module like tpbuttons, fujitsu-laptop, etc) there needs to be a hardware abstraction around them until they all use the same kernel interface.

This is what HAL already do. HAL provides an interface for e.g. NM to set the state back to sysfs/kernel. This is not the job of HAL, also because you need in several cases user interaction (see above).

But it doesn't provide an abstraction for _all_ rfkill buttons. Again, HAL would provide the state of the button, but not the policy. The "user interaction" you talk about is the Policy, and that's fine to handle with NetworkManager. But NetworkManager is not going to provide the abstraction, since that's HAL's job. NM would certainly turn off the radios if the GetPower() call on this virtual killswitch was FALSE. NM would not call SetPower() on the device, because as you state, HAL has no idea how to handle that. Again, the _state_ should be handled in HAL. The _policy_ should be handled in NM. Whether the button is on or off is state, and what to do about that state when it changes is policy.

...

If you create a machine-wide rfkill switch that just handles input events, then NM would already handle that killswitch automatically just like it handles toggle killswitches. No changes needed to NetworkManager at all. The cases we are talking about are _also_ machines without toggle killswitches, where the _only_ rfkill method is a keyboard key.

Looks as if you don't full understand what happens currently. Again:

I completely understand what happens.

1) HAL don't change the state of the rfkill. In some cases it's the kernel, in all other cases NM has to set the state via HAL if there is a event.

I don't expect HAL to turn the power on and off. I simply expect HAL to report the current power state of the rfkill button (either on or off).

2) Why should HAL provide a machine-wide rfkill? There are different types of rfkill 'devices' (WLAN/WWAN/Bluetooth) and this is why HAL has more than one (if supported by the machine) rfkill device/interface. Also because you can have more than one WLAN/WWAN/Bluetooth card. In such cases you have to ask the user which of them (maybe all, maybe only WLAN or only Bluetooth) he would like to disable.

Again, I don't expect HAL to handle SetPower() for virtual rfkill buttons. I only expect HAL to report the GetPower() state for the virtual buttons. Obviously something like NetworkManager will handle the policy and user interaction once the user turns the switch off. But NM has to know that the switch got turned off in the _first_ place, and that's the job of the Hardware Abstraction Layer to report. Once NM knows the power state changed, NM can ask the user just what they want to turn off, and do it. HAL would not be involved in actually turning off anything.

...

No, they WILL NOT go through NetworkManager until there's a standard kernel or HAL interface for ALL rfkill items. It's completely insane to put the hardware abstraction for rfkill stuff in to NetworkManager, when that's exactly what HAL is supposed to be doing right now. There's a standard rfkill interface in HAL: let's use it, not re-implement rfkill in two different places.

This all has nothing to do with hardware abstraction in NM. This all is _already_ abstracted in HAL. NM needs only to listen to the events and has to act on them. There is no need to abstract anything.

rfkill is not fully abstracted in HAL, because HAL doesn't handle all the different types of rfkill switches yet. Not all laptop-specific modules (like tpbuttons, fujitsu-laptop, toshiba-laptop, etc) have been converted to use the kernel's rfkill layer. HAL doesn't handle input-layer rfkill buttons. Some drivers like ipw2x00 don't use the in-kernel rfkill layer. Therefore it's not abstracted, since HAL doesn't completely abstract it.

...

Yes, that's the path forward. Until rfkill methods are standardized with a consistent interface, NetworkManager is not going to talk to them directly.

AGAIN: THIS IS WHAT WE ALREADY HAVE! THERE IS ALREADY A standardized INTERFACE. READ THE HAL SPEC.

I have read the HAL spec. I understand it. And HAL doesn't abstract input-layer rfkill buttons that are not tied to a specific hardware device. Remember, just because there's a switch on the laptop _doesn't_ mean that it disables the device in hardware when the switch is flipped. That only happens on some latops. The rfkill devices exposed in HAL are already system-wide rfkill switches, because some laptops don't tie the killswitch to a specific device. Therefore, it's exactly the same sort of thing as an input-layer rfkill switch, which is also system wide. Remember: HAL rfkill button objects are _not_ tied to a specific hardware device; some just happen to be, but that was never the intention becuase it's just not possible. Again, the path forward is to create a virtual, system-wide rfkill switch object in HAL, that responds to GetPower() but returns an exception on SetPower(), and consumes input-layer rfkill events. It should toggle the GetPower() state of the object accordingly when the switch is pressed. Things like NM can then get the events, and act on them as necessary. HAL would not have to care about what specific devices get enabled/disabled. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=382784 User dkukawka@novell.com added comment https://bugzilla.novell.com/show_bug.cgi?id=382784#c12 --- Comment #12 from Danny Kukawka 2008-05-13 11:09:13 MST --- HAL don't need a "system-wide rfkill switch object" since there can be more than one rfkill (for different devices) and they can't and shouldn't go through one object. This make no sense. And since the kernel send e.g. no events if you use a "real" rfkill switch HAL don't get any info if the state change. And for the other events you get information from HAL (as e.g. IBM ACPI events which don't go through the input layer) or the input layer. NM needs only to listen to the input layer and HAL. And since NM already listen to HAL it shouldn't be rocket science to listen also to the input layer to get the other events. If there are rfkill types not supported by GetPower() (which returns the current state) you have to provide the information to add them to the existing HAL structure/script and they get supported. If there are rfkill-buttons which don't have a specific hardware device, how should HAL be able to get (and provide information) about the actual state of the button? Should HAL guess it? AFAIK the keyboard buttons have no state, you can't get information about the state. The keyboard button event doesn't mean neccessary that the rfkill state change. Since a event don't neccessary mean that e.g. the state for WLAN rfkill change if you e.g. disable only WWAN/Bluetooth on the event (because of the user interaction). It make IMO no sense to do this in HAL since only NM can know the correct state in this case. (In reply to comment #11 from Dan Williams)

I should note that NM never has may never call SetPower(), for a few reasons:

If NM don't call SetPower() also GetPower() make no sense, since the state get never set back to the card or the sysfs. HAL can't tell you the correct state then. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=382784 User dkukawka@novell.com added comment https://bugzilla.novell.com/show_bug.cgi?id=382784#c14 --- Comment #14 from Danny Kukawka 2008-05-13 11:59:25 MST --- (In reply to comment #13 from Dan Williams)

(In reply to comment #12 from Danny Kukawka)

...

If there are rfkill-buttons which don't have a specific hardware device, how should HAL be able to get (and provide information) about the actual state of the button? Should HAL guess it? AFAIK the keyboard buttons have no state, you can't get information about the state.

HAL tracks the button presses of the item and toggles the power state accordingly. What the default state is when HAL starts, or whether that state gets save across reboots, I'm not sure.

If HAL can't find out the correct state on startup, the state will we ALLWAYS wrong, if the initial state isn't correct. Guessing the current state is a no-go. And that's why the whole discussion make no sense because HAL shouldn't provide any unreliable information. And if you use SIOCSIWTXPOW to control the state of WLAN HAL also can't know the correct state. Btw. You are obviously wrong: The current rfkill interface/method don't tell the state of the button or switch, it tells you the state of the radio (from HAL SPEC: "This interface provides a mechanism for both querying whether a radio is on as well as turning it on and off.") IMO we have NM (and removed network stuff from HAL) because NM is the network abstraction layer. Because of this NM should also listen the input layer (and HAL) and handle all the network related stuff like the network related buttons. Only NM can know the correct state of the radio, HAL can't. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=382784 User dkukawka@novell.com added comment https://bugzilla.novell.com/show_bug.cgi?id=382784#c16 --- Comment #16 from Danny Kukawka 2008-05-13 14:05:37 MST --- (In reply to comment #15 from Dan Williams)

(In reply to comment #14 from Danny Kukawka) [...] No, the state won't always be wrong.

Oh, yes it wouldn't be always wrong ... only in 50% of the cases if you assume two possible states.

You assume a default saved state, which is exactly what NM would be doing anyway.

You can't assume some random default state if the device is diabled or enabled. That would only produce unreliable and possible wrong information.

NM isn't going to store the rfkill state, NM is going to start the radios powered up until the user or some other process tells NM to rfkill them.

I don't want NM to power up any device only to set it to a default state. If I disable WLAN under windows or an other Linux session I want to have it disabled also if I boot my actual Linux. The state should not change and it should be also the same over a reboot or shutdown/boot cycle. One example: I sit in a plane and disabled the WLAN in the airport, then I reboot in the airplane: I don't want NM or HAL to enable the WLAN again only to get a default state. Thats wrong behavior.

The _only_ way you know the state of the radio is if there is a toggle switch on the laptop that the user has switched to "off".

Then the state is possibly wrong until the user toggle the switch. Thats no option.

...

Btw. You are obviously wrong: The current rfkill interface/method don't tell the state of the button or switch, it tells you the state of the radio (from HAL SPEC: "This interface provides a mechanism for both querying whether a radio is on as well as turning it on and off.")

The spec does not reflect reality. Again, not every killswitch is directly related to a hardware radio, so how could the killswitch _possibly_ reflect the state of the radio???? It only reflects radio state for _some_ devices, those where the rfkill state is directly handled by the hardware device and driver.

It does not matter if the spec reflect the reality. It reflects what is described in the spec. And the description is clear. Also because this is for the already existing devices in HAL which all work the same AFAIK. GetPower() returns the state that is set in sysfs or the bios (in the case of the Dell machines) for the currently supported devices. There is nothing wrong in the specification of HAL. The SPEC is not wrong only because you want something different than the current situation.

...

IMO we have NM (and removed network stuff from HAL) because NM is the network abstraction layer. Because of this NM should also listen the input layer (and HAL) and handle all the network related stuff like the network related buttons. Only NM can know the correct state of the radio, HAL can't.

Wrong. The driver knows the correct radio state, whether it's on or off. And the kernel can/should know about hardware button state too. Sometimes that's tied to the radio state, sometimes its not tied to the radio state.

But this don't change the fact that NM is the abstraction layer for network.

If the radio state was tied to a specific device as you keep saying, why wouldn't it be a property on the actual wifi device itself instead of a property on the rfkill button object?

Because there is currently no state property for such devices! There is only a DBus method to get the current state of the radio.

They are rfkill _switch_ objects in the HAL GDL, _not_ radio objects.

Doesn't matter. What matters is actually what is written in the spec.

The way to clean this up is to:

1) Put radio state on the actual radio devices themselves; the WWAN/BT/WIFI/WIMAX device would have a 'rf.radio.state' parameter of 0 (on), 1 (softkill), or 2 (hardkill)

That's not possible for all keyboard buttons, because HAL don't know if the keyboard button has to handle WLAN or/and other radio devices. And adding a device to any radio make also no sense because you can have more than the internal radio devices (and you can detect if a internal UMTS USB card is internal or external) and keyboard button don't need to affect neccessarly the external (USB/PCMCIA/IR) devices (or the user want to differ between internal and external devices). What's if the system has more than one WLAN or bluetooth device? Adding the same keyboard botton to both? What if both devices are in different states? ...

2) Fix the spec to state that the rfkill button objects don't reflect radio state, but instead the button state

That would break the current behavior.

3) Remove the SetPower() method on the rfkill button objects

Why? Maybe an other application than NM wants to set the sysfs attributes also!

4) Add a SetState() call to the network device to set the state to 0 (on) or 1 (softkill); since 2 is a hardkill the radio obviously cannot be taken out of state 2 except by a physical user interaction over which the software has no control

Btw. It make no sense to continue the discussion. The current HAL is maybe not perfect, but what HAL currently do, as in the spec described, is correct. NM could simply listen to the input layer (this is no rocket science!) for now to fix the problem for the current product. If HAL get ever changed it would not be for the current product (openSUSE 11.0). Discuss this in the upstream bugzilla. The discussion ends for me here. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=382784 User dcbw@redhat.com added comment https://bugzilla.novell.com/show_bug.cgi?id=382784#c18 --- Comment #18 from Dan Williams 2008-05-13 14:19:33 MST --- (In reply to comment #17 from Danny Kukawka)

And btw. it's not the job of HAL to do network device specific handling like WEXT or SIOCSIWTXPOW or anything other that's not the sysfs (or e.g. the Dell handling) since we have NM for it. That's why we removed network related stuff from HAL: it's the job of NM. There is no reason to move it back. This all should IMO be done in NM and not HAL.

Nowhere in this discussion have I ever said that HAL should touch the wireless devices themselves with WEXT. That is, and has always been, the job of NetworkManager. I simply want HAL to consistently report the state of rfkill buttons so that _NM_ can do the WEXT poking. HAL should abstract the vendor/device specific rfkill button states, not the device stuff. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=382784 User awafaa@opensuse.org added comment https://bugzilla.novell.com/show_bug.cgi?id=382784#c20 --- Comment #20 from Andrew Wafaa 2008-05-20 07:34:35 MST --- Updated to latest Factory as of 20May 1300UTC The laptop is normally docked in a docking station, but when rebooting to activate the new kernel I removed the laptop from the docking station. When I logged in I was able to connect to wireless and it could see *all* wirless AP without issue. Problem returns when I connect the laptop to the docking station. Once done it is as if wireless was never there. This function worked correctly in 10.3 without any problems. As such I don't believe this is an enhancement bug - it doesn't work, not it works but could be better. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=382784 User awafaa@opensuse.org added comment https://bugzilla.novell.com/show_bug.cgi?id=382784#c22 --- Comment #22 from Andrew Wafaa 2008-06-23 16:12:55 MDT --- David, are you using a docking station? I only have this issue when I dock my HP NC6320. If I boot up off of the docker then everything works as expected, as soon as I dock then NM decides that I no longer have wireless. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=382784 User jnelson-suse@jamponi.net added comment https://bugzilla.novell.com/show_bug.cgi?id=382784#c24 Jon Nelson changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jnelson-suse@jamponi.net --- Comment #24 from Jon Nelson 2008-07-29 19:44:09 MDT --- My Laptop (Lenovo T61p) with iwl4965 goes crazy if I use the kill switch. *Nothing* happens if I don't load the rfkill module manually. Once I do, NetworkManager itself goes crazy, generating *millions* of these two lines over and over and over again: Jul 29 20:33:12 worklaptop NetworkManager: nm_supplicant_interface_request_scan: assertion `NM_IS_SUPPLICANT_INTERFACE (self)' failed Jul 29 20:33:12 worklaptop NetworkManager: nm_supplicant_interface_get_connection_state: assertion `NM_IS_SUPPLICANT_INTERFACE (self)' failed zypper says I have anything with 'supplicant' installed. Additionally, Something is also calling: /usr/lib64/hal/scripts/linux/hal-system-killswitch-get-power-linux many times a second. If I add a 'set -x' to that script, i see: + '[' '' = bluetooth ']' + '[' '' = wlan ']' + '[' '' = wwan ']' + echo org.freedesktop.Hal.Device.KillSwitch.NotSupported org.freedesktop.Hal.Device.KillSwitch.NotSupported + echo 'Killswitch type not supported' Killswitch type not supported + exit 1 (note the missing iwl). If I rmmod iwl4965, rmmod rfkill, and then modprobe iwl4965: then I'll get: + '[' wlan = bluetooth ']' + '[' wlan = wlan ']' + '[' ipw = dell ']' + '[' ipw = ipw ']' + hal-ipw-killswitch-linux getrfkill + value=1 + '[' 1 = 0 ']' + '[' 1 = 1 ']' + exit 0 every 6 seconds, but using the kill switch itself makes no difference. Bluetooth comes up and down dutifully, but not iwl4965, with or without rfkill. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=382784 User trenn@novell.com added comment https://bugzilla.novell.com/show_bug.cgi?id=382784#c26 --- Comment #26 from Thomas Renninger 2008-07-30 05:04:35 MDT --- For the thinkpad: Henrique has posted several patches for proper use of rfkill on ThinkPads. IIRC this could also affect other machines. It would be great if you could give the next 11.1 Alpha/Beta release a test. It should be 2.6.27 kernel based as there the changes are included. I do not know now whether the next 11.1 will be based on that kernel, please ask again if you are unsure and the next one got released. This bug will probably be a Won't fix for 11.0, Henriques changes were rather large. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=382784 User jnelson-suse@jamponi.net added comment https://bugzilla.novell.com/show_bug.cgi?id=382784#c28 --- Comment #28 from Jon Nelson 2008-07-30 06:03:21 MDT --- You must realize, of course, that the NM bug being fixed in SVN doesn't do me any good while it stays there. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.