FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor


 
 
LinkBack Thread Tools
 
Old 09-12-2008, 05:08 AM
"Aaron Griffin"
 
Default udev 128-1

Thanks Eric for being on the ball. I didn't check for a new version today.

Pushed to testing.
Some important changes:
* Stock rules are not in /lib/udev/rules.d/
* /etc/udev/rules.d is still respected and should be used for non-stock rules
* Custom readme moved to /usr/share/udev. slated for removal later
(man pages are superior)
* Improved stock rules, will eventually need to clean up our Arch rules...
* Possibly others.

Please test and let me know how it goes.

Also, a x86_64 build would be nice.

Cheers,
Aaron
 
Old 09-12-2008, 06:54 AM
"Roman Kyrylych"
 
Default udev 128-1

2008/9/12 Aaron Griffin <aaronmgriffin@gmail.com>:
> Thanks Eric for being on the ball. I didn't check for a new version today.
>
> Pushed to testing.
> Some important changes:
> * Stock rules are not in /lib/udev/rules.d/

not -> now

> * /etc/udev/rules.d is still respected and should be used for non-stock rules
> * Custom readme moved to /usr/share/udev. slated for removal later
> (man pages are superior)
> * Improved stock rules, will eventually need to clean up our Arch rules...
> * Possibly others.
>
> Please test and let me know how it goes.
>
> Also, a x86_64 build would be nice.


--
Roman Kyrylych (*оман Кирилич)
 
Old 09-12-2008, 07:29 AM
Thomas Bchler
 
Default udev 128-1

Aaron Griffin schrieb:

Thanks Eric for being on the ball. I didn't check for a new version today.

Pushed to testing.
Some important changes:
* Stock rules are not in /lib/udev/rules.d/
* /etc/udev/rules.d is still respected and should be used for non-stock rules
* Custom readme moved to /usr/share/udev. slated for removal later
(man pages are superior)
* Improved stock rules, will eventually need to clean up our Arch rules...
* Possibly others.

Please test and let me know how it goes.

Also, a x86_64 build would be nice.

Cheers,
Aaron



Damn, I haven't checked in the new load-modules script with the fixed
blacklist yet. I'll do that later today and release a -2 then, if that
is alright.


Also, would you mind looking at klibc-udev? It's only used for a
fraction of a second on every boot, but we should still update it.
 
Old 09-12-2008, 09:38 AM
Allan McRae
 
Default udev 128-1

Aaron Griffin wrote:

Thanks Eric for being on the ball. I didn't check for a new version today.

Pushed to testing.
Some important changes:
* Stock rules are not in /lib/udev/rules.d/
* /etc/udev/rules.d is still respected and should be used for non-stock rules
* Custom readme moved to /usr/share/udev. slated for removal later
(man pages are superior)
* Improved stock rules, will eventually need to clean up our Arch rules...
* Possibly others.

Please test and let me know how it goes.

Also, a x86_64 build would be nice.

Cheers,
Aaron


I still lose (at least) my wireless network connection when I update to
this udev version. I'm using gnome-network-manager with an Intel
PRO/Wireless 3945ABG card and iwlwifi. Trying to figure this out now
because I like the internet...


Allan
 
Old 09-12-2008, 10:01 AM
Thomas Bchler
 
Default udev 128-1

Allan McRae schrieb:
I still lose (at least) my wireless network connection when I update to
this udev version. I'm using gnome-network-manager with an Intel
PRO/Wireless 3945ABG card and iwlwifi. Trying to figure this out now
because I like the internet...


Two possible causes:
1) The module isn't loaded. This is easy to fix, as you just need to
load it manually.

2) The firmware isn't loaded. This is more difficult to fix.

Can you see if iwl3945 is in lsmod and if so, check dmesg.
 
Old 09-12-2008, 10:22 AM
Allan McRae
 
Default udev 128-1

Allan McRae wrote:

Aaron Griffin wrote:
Thanks Eric for being on the ball. I didn't check for a new version
today.


Pushed to testing.
Some important changes:
* Stock rules are not in /lib/udev/rules.d/
* /etc/udev/rules.d is still respected and should be used for
non-stock rules

* Custom readme moved to /usr/share/udev. slated for removal later
(man pages are superior)
* Improved stock rules, will eventually need to clean up our Arch
rules...

* Possibly others.

Please test and let me know how it goes.

Also, a x86_64 build would be nice.

Cheers,
Aaron


I still lose (at least) my wireless network connection when I update
to this udev version. I'm using gnome-network-manager with an Intel
PRO/Wireless 3945ABG card and iwlwifi. Trying to figure this out now
because I like the internet...


So, the dependency path from gnome-network-manager to udev is:
|--gnome-network-manager
|--networkmanager
|--hal
|--udev

It appears hal needs a rebuild because of the libvolume_id soname bump
in the udev package. Updating udev then restarting hal and
networkmanager make my internet die. I very quickly tried rebuilding
hal but it failed....


checking whether to rebuild gperf header files... checking for DBUS... yes
checking for GLIB... yes
checking if GLib is version 2.14.0 or newer... yes
checking for VOLUME_ID... configure: error: Package requirements
(libvolume_id >= 0.77) were not met:


No package 'libvolume_id' found

Consider adjusting the PKG_CONFIG_PATH environment variable if you
installed software in a non-standard prefix.

Alternatively, you may set the environment variables VOLUME_ID_CFLAGS
and VOLUME_ID_LIBS to avoid the need to call pkg-config.
See the pkg-config man page for more details.
 
Old 09-12-2008, 10:41 AM
Allan McRae
 
Default udev 128-1

Thomas Bchler wrote:

Allan McRae schrieb:
I still lose (at least) my wireless network connection when I update
to this udev version. I'm using gnome-network-manager with an Intel
PRO/Wireless 3945ABG card and iwlwifi. Trying to figure this out now
because I like the internet...


Two possible causes:
1) The module isn't loaded. This is easy to fix, as you just need to
load it manually.

2) The firmware isn't loaded. This is more difficult to fix.

Can you see if iwl3945 is in lsmod and if so, check dmesg.

iwl3945 is in lsmod. Taking a diff with the dmesg output with the old
and new udev package gives this bit of interesting output:


-ACPI: PCI Interrupt 0000:0c:00.0[A] -> GSI 17 (level, low) -> IRQ 17
-PM: Writing back config space on device 0000:0c:00.0 at offset 1 (was
100102, writing 100106)

-firmware: requesting iwlwifi-3945-1.ucode
-Registered led device: iwl-phy0:radio
-Registered led device: iwl-phy0:assoc
-Registered led device: iwl-phy0:RX
-Registered led device: iwl-phy0:TX
[drm] Initialized drm 1.1.0 20060810
ACPI: PCI Interrupt 0000:00:02.0[A] -> GSI 16 (level, low) -> IRQ 16
PCI: Setting latency timer of device 0000:00:02.0 to 64
[drm] Initialized i915 1.6.0 20060119 on minor 0
NET: Registered protocol family 10
lo: Disabled Privacy Extensions
-ADDRCONF(NETDEV_UP): eth0: link is not ready
-ADDRCONF(NETDEV_UP): wlan0: link is not ready
-wlan0: Initial auth_alg=0
-wlan0: authenticate with AP 00:15:e9:cc:1e:be
-wlan0: RX authentication from 00:15:e9:cc:1e:be (alg=0 transaction=2
status=0)

-wlan0: authenticated
-wlan0: associate with AP 00:15:e9:cc:1e:be
-wlan0: RX AssocResp from 00:15:e9:cc:1e:be (capab=0x471 status=0 aid=2)
-wlan0: associated
-wlan0: switched to short barker preamble (BSSID=00:15:e9:cc:1e:be)
-ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
-wlan0: no IPv6 routers present
 
Old 09-12-2008, 11:05 AM
Allan McRae
 
Default udev 128-1

Allan McRae wrote:

Allan McRae wrote:

Aaron Griffin wrote:
Thanks Eric for being on the ball. I didn't check for a new version
today.


Pushed to testing.
Some important changes:
* Stock rules are not in /lib/udev/rules.d/
* /etc/udev/rules.d is still respected and should be used for
non-stock rules

* Custom readme moved to /usr/share/udev. slated for removal later
(man pages are superior)
* Improved stock rules, will eventually need to clean up our Arch
rules...

* Possibly others.

Please test and let me know how it goes.

Also, a x86_64 build would be nice.

Cheers,
Aaron


I still lose (at least) my wireless network connection when I update
to this udev version. I'm using gnome-network-manager with an Intel
PRO/Wireless 3945ABG card and iwlwifi. Trying to figure this out now
because I like the internet...


So, the dependency path from gnome-network-manager to udev is:
|--gnome-network-manager
|--networkmanager
|--hal
|--udev

It appears hal needs a rebuild because of the libvolume_id soname bump
in the udev package. Updating udev then restarting hal and
networkmanager make my internet die. I very quickly tried rebuilding
hal but it failed....


checking whether to rebuild gperf header files... checking for DBUS...
yes

checking for GLIB... yes
checking if GLib is version 2.14.0 or newer... yes
checking for VOLUME_ID... configure: error: Package requirements
(libvolume_id >= 0.77) were not met:


No package 'libvolume_id' found

Consider adjusting the PKG_CONFIG_PATH environment variable if you
installed software in a non-standard prefix.

Alternatively, you may set the environment variables VOLUME_ID_CFLAGS
and VOLUME_ID_LIBS to avoid the need to call pkg-config.
See the pkg-config man page for more details.


That error is because /usr/lib/pkgconfig/libvolume_id.pc moved to
/lib/pkgconfig. Anyway, rebuilding hal doe snot fix my problem.
 
Old 09-12-2008, 11:07 AM
Thomas Bchler
 
Default udev 128-1

Allan McRae schrieb:

So, the dependency path from gnome-network-manager to udev is:
|--gnome-network-manager
|--networkmanager
|--hal
|--udev

It appears hal needs a rebuild because of the libvolume_id soname bump
in the udev package. Updating udev then restarting hal and
networkmanager make my internet die. I very quickly tried rebuilding
hal but it failed....


checking whether to rebuild gperf header files... checking for DBUS... yes
checking for GLIB... yes
checking if GLib is version 2.14.0 or newer... yes
checking for VOLUME_ID... configure: error: Package requirements
(libvolume_id >= 0.77) were not met:


No package 'libvolume_id' found

Consider adjusting the PKG_CONFIG_PATH environment variable if you
installed software in a non-standard prefix.

Alternatively, you may set the environment variables VOLUME_ID_CFLAGS
and VOLUME_ID_LIBS to avoid the need to call pkg-config.
See the pkg-config man page for more details.


This is definitely a blocker. I am confused though, as volume_id is only
required for hald-probe-storage and hald-probe-volume, which should not
block hal from starting.


Does hal start up at all and if yes, what processes are running (ps
ax|grep -i hal)?


As your problem seems related to networkmanager, is the interface
present? Do the missing dmesg lines (about firmware and LED) show up
when you simply run ifconfig wlan0 up?
 
Old 09-12-2008, 12:22 PM
Allan McRae
 
Default udev 128-1

Thomas Bchler wrote:

Allan McRae schrieb:

So, the dependency path from gnome-network-manager to udev is:
|--gnome-network-manager
|--networkmanager
|--hal
|--udev

It appears hal needs a rebuild because of the libvolume_id soname
bump in the udev package. Updating udev then restarting hal and
networkmanager make my internet die. I very quickly tried rebuilding
hal but it failed....


checking whether to rebuild gperf header files... checking for
DBUS... yes

checking for GLIB... yes
checking if GLib is version 2.14.0 or newer... yes
checking for VOLUME_ID... configure: error: Package requirements
(libvolume_id >= 0.77) were not met:


No package 'libvolume_id' found

Consider adjusting the PKG_CONFIG_PATH environment variable if you
installed software in a non-standard prefix.

Alternatively, you may set the environment variables VOLUME_ID_CFLAGS
and VOLUME_ID_LIBS to avoid the need to call pkg-config.
See the pkg-config man page for more details.


This is definitely a blocker. I am confused though, as volume_id is
only required for hald-probe-storage and hald-probe-volume, which
should not block hal from starting.


Does hal start up at all and if yes, what processes are running (ps
ax|grep -i hal)?




Hal starts up fine. With the new udev I get the following processes:

/usr/sbin/hald
hald-runner
/usr/lib/hal/hald-addon-cpufreq
hald-addon-acpi: listening on acpi kernel interface /proc/acpi/event

With the old udev I also get:

/usr/lib/hal/hald-addon-dell-backlight
hald-addon-input: Listening on /dev/input/event1 /dev/input/event2
/dev/input/event3 /dev/input/event4 /dev/input/event5 /dev/input/event6

hald-addon-storage: polling /dev/sr0 (every 2 sec)

The storage one will be a libvolume_id issue but not sure about the
other two.


As your problem seems related to networkmanager, is the interface
present? Do the missing dmesg lines (about firmware and LED) show up
when you simply run ifconfig wlan0 up?




Running "ifconfig wlan0 up" adds these lines to the dmesg output.
 

Thread Tools




All times are GMT. The time now is 09:58 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org