| Summary: | libhal request result does not match lshal output | ||
|---|---|---|---|
| Product: | hal | Reporter: | Alex HeadHunter Pyattaev <alex.pyattaev> |
| Component: | libhal | Assignee: | David Zeuthen (not reading bugmail) <zeuthen> |
| Status: | RESOLVED INVALID | QA Contact: | |
| Severity: | normal | ||
| Priority: | highest | CC: | danny.kukawka |
| Version: | unspecified | Keywords: | have-backtrace |
| Hardware: | x86-64 (AMD64) | ||
| OS: | Linux (All) | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Attachments: | Full lshal output | ||
There are a lot of people at some other bugtrackers waiting for solution. It appears, that the problem is somewhat related to AMD64 platform with ssb bus drivers, actually affected HW is: Dell D630 tx2100, ZV6000 HP laptops. I can't reproduce this. If the key is in lshal then it should be also available via libhal_device_get_property_string() since lshal use the same data via libhal. You don't show any output out of the code from NetworkManager. What exactly is failing? Was the correct udi used? OK, I'm idiot=) When somebody uses ssb-based drivers (ssb is a subsystem in kernel), a fictional interface is created, wmaster0. It does nothing, it just hangs around. And it appears that NM decides that it is the only wireless device, and uses its UDI. It works for some reason, but wmaster interface is not supposed to have any associated driver, thus driver request fails. So, the problem is not with libhal. It was just incorrect request. Sorry/ |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.
Created attachment 28312 [details] Full lshal output Hi! I use gentoo linux distribution, and for quite a long time HAL was just working. But I have recently updated HAL to version 0.5.13 (can't remember previous version), and the things went a bit crazy. To be exact, Network-manager produced error message for my Broadcom wifi NIC "Assertion Driver!=NULL failed." upon registering the device. I started by checking lshal output. Here it is: udi = '/org/freedesktop/Hal/devices/pci_14e4_4312' info.linux.driver = 'b43-pci-bridge' (string) info.parent = '/org/freedesktop/Hal/devices/pci_10de_2fd' (string) info.product = 'BCM4312 802.11a/b/g' (string) info.subsystem = 'pci' (string) info.udi = '/org/freedesktop/Hal/devices/pci_14e4_4312' (string) info.vendor = 'Broadcom Corporation' (string) linux.hotplug_type = 2 (0x2) (int) linux.subsystem = 'pci' (string) linux.sysfs_path = '/sys/devices/pci0000:00/0000:00:03.0/0000:03:00.0' (string) pci.device_class = 2 (0x2) (int) pci.device_protocol = 0 (0x0) (int) pci.device_subclass = 128 (0x80) (int) pci.linux.sysfs_path = '/sys/devices/ pci0000:00/0000:00:03.0/0000:03:00.0' (string) pci.product = 'BCM4312 802.11a/b/g' (string) pci.product_id = 17170 (0x4312) (int) pci.subsys_product = 'Broadcom 802.11a/b/g WLAN' (string) pci.subsys_product_id = 4977 (0x1371) (int) pci.subsys_vendor = 'Hewlett-Packard Company' (string) pci.subsys_vendor_id = 4156 (0x103c) (int) pci.vendor = 'Broadcom Corporation' (string) pci.vendor_id = 5348 (0x14e4) (int) So, it looks like a normal WIFI device. Note the driver string, it exists and is valid. I have decided that NM does some nasty magic on the string, so I have checked the NM source code (src/nm-hal-manager.c:252) and found out that the driver_name string is the return value of this function: ======= static char * nm_get_device_driver_name (LibHalContext *ctx, const char *origdev_udi) { char *driver_name = NULL; nm_debug("entered nm_get_device_driver_name"); if (origdev_udi && libhal_device_property_exists (ctx, origdev_udi, "info.linux.driver", NULL)) { char *drv; nm_debug("found property"); drv = libhal_device_get_property_string (ctx, origdev_udi, "info.linux.driver", NULL); if (drv) { nm_debug("copied device name %s",drv); driver_name = g_strdup (drv); libhal_free_string (drv); } } return driver_name; } ======== As you can see I have added some nice debug, so I saw a nice result - for the Ethernet controller the driver_name was acquired correctly, and for WIFI libhal decides that there is no such string (I didn't see "found property" in log for WIFI). Full lshal output is attached, you can find Ethernet device there by "forcedeth" keyword. So, I have decided that the problem lies somewhere inside libhal, but I have failed to locate it. For now I have a workaround (I have disabled the assertion and NM works fine), but the issue needs a FIX, not a workaround. Software versions are: hal-0.5.13-r2, hal-0.5.13-r2, udev-141-r1, policykit-0.9-r1, consolekit-0.3.0-r1; linux kernel 2.6.30-r4, 2.6.29-r3. Feel free to ask for info and good luck=)