[Bug 302539] New: NetworkManager: permanently send NameOwnerChanged and poll HAL
https://bugzilla.novell.com/show_bug.cgi?id=302539 Summary: NetworkManager: permanently send NameOwnerChanged and poll HAL Product: openSUSE 10.3 Version: Beta 1 Platform: Other OS/Version: Other Status: NEW Severity: Critical Priority: P5 - None Component: Network AssignedTo: tambet@novell.com ReportedBy: dkukawka@novell.com QAContact: qa@suse.de CC: hschaa@novell.com Found By: --- I have problems with NetworkManager on Beta1 on a Acer TravelMate 3000. I have seen something like that also on some other machines, but can't say which one atm. 1) I get permanently (every 2 seconds I guess) NameOwnerChanged events on the D-Bus system bus which are caused (directly or indirect) by NetworkManager. They stop if I shutdown Networkmanager. Unfortunately there is no destination set (dest=(null destination) in dbus-monitor), so I can't find the direct source. 2) It looks as if Networkmanager permanently call GetPower() of /org/freedesktop/Hal/devices/ipw_wlan_switch on HAL. This happen also every 2 seconds which is really bad, because with every call a fork on HAL happen because this method is implemented as a script. It looks as if 1 and 2 are connected to each other. If I remove the ipw_wlan_switch device from HAL everything stop. IMO the problem is that Networkmanager poll GetPower(). This should get stopped. There should be an other solution for this (e.g. call GetPower() only if really needed or after a WLAN key event via input or HAL). -- 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=302539#c1
--- Comment #1 from Tambet Ingo
https://bugzilla.novell.com/show_bug.cgi?id=302539
JP Rosevear
https://bugzilla.novell.com/show_bug.cgi?id=302539#c3
--- Comment #3 from JP Rosevear
There is no such feature in the upstream SVN trunk as far as I can see. And as it currently workit's really better to drop the feature.
Its in the 0.6.x branch only currently, it has not been forward ported because of all the changes going on in trunk.
HAL can't send a signal since HAL don't get an info if this change. At least also because this all differ from machine to machine. There is no common sysfs interface for killshwitch.
NetworkManager could do on ThinkPads the following: 1) check initial the status of WLAN/Killswitch 2) listen to HAL for ButtonPressed=killswitch event 3) call GetPower()
Something like that also for Dell (and other) machines (if it doesn work: report it): 1) check initial the status of WLAN/Killswitch 2) listen on the input device for the keyboard for KEY_WLAN (keycode: 238) 3) call GetPower()
Isn't this the type of abstraction hal should deal with? -- 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=302539
JP Rosevear
https://bugzilla.novell.com/show_bug.cgi?id=302539#c4
Danny Kukawka
Isn't this the type of abstraction hal should deal with?
No, since HAL never handle button/switch events. This is the job of the userspace tools behind HAL as it is e.g. the job of KPowersave/g-p-m/powersaved to handle suspend button events. Last but not least HAL don't abstract such network stuff, this is the job of NM. -- 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=302539#c5
--- Comment #5 from JP Rosevear
(In reply to comment #3 from JP Rosevear)
Isn't this the type of abstraction hal should deal with?
No, since HAL never handle button/switch events. This is the job of the userspace tools behind HAL as it is e.g. the job of KPowersave/g-p-m/powersaved to handle suspend button events. Last but not least HAL don't abstract such network stuff, this is the job of NM.
Afaik though there are not a variety of suspend/resume buttons and things like pm-utils take care of hardware specific issues underneath. The button is already abstracted in hal as you mention with /org/freedesktop/Hal/devices/ipw_wlan_switch so why would a user space daemon either poll it or wait for a signal change? In the end this is a change one of the upstream maintainers let in, it seems odd we would go about disabling upstream features. -- 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=302539#c6
JP Rosevear
https://bugzilla.novell.com/show_bug.cgi?id=302539#c7
--- Comment #7 from Danny Kukawka
Afaik though there are not a variety of suspend/resume buttons and things like pm-utils take care of hardware specific issues underneath.
No, that's not correct. There are also 2 different types of suspend buttons atm. There are the buttons which produce events via ACPI and also buttons which go trough the input layer. Both need be handled by the userspace. And it's also not handled by pm-utils but by g-p-m/powersave/kpowersave. It's the same as for brightness button events. In this case it's also the job of e.g. g-p-m to react on the button events to change the brightness. It's not the job of HAL (for g-p-m it mean also: call GetBrightness() if needed, but don't poll it).
The button is already abstracted in hal as you mention with /org/freedesktop/Hal/devices/ipw_wlan_switch so why would a user space daemon either poll it or wait for a signal change?
This interface is not the abstraction of the button itself. It's a abstraction of the rfkill status. This is something different. While e.g. the button/switch can disable the hardware (and there is no way to enable it again trough sysfs/software if this is a real switch) the rfkill can be also set by software via sysfs to enable/disable the wireless. It's not the job of HAL to monitor and react on such events. NM is the perfect place to handle these events. -- 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=302539#c8
JP Rosevear
https://bugzilla.novell.com/show_bug.cgi?id=302539
Tambet Ingo
participants (1)
-
bugzilla_noreply＠novell.com