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 01-12-2012, 07:52 PM
Tom Gundersen
 
Default udev-177

Hi guys,

udev-177 is now in [testing], and a few words of caution are in order.

Firstly, don't be alarmed by the warnings mkinitcpio will spit out
when using udev-177, these are harmless and will go away in the next
mkinitcpio release (which will move to core together with udev-177).

A lot changed in this release, in particular

* the build system was changed around and the standard install
locations were changed. I did my best to change everything back, as we
are not ready to move /bin to /usr/bin yet.

* blkid and modprobe are no longer used, instead their respective
libraries are used in internal tools.

Both of these things might have caused some bugs, so please let me
know if you notice anything.

* as have been mentioned previously devtmpfs is now a hard requirement.

This release depends on kmod, which is currently under heavy
development. udev will therefore stay in testing until Dave decides
that kmod is ready for core.

Cheers,

Tom
 
Old 01-12-2012, 09:17 PM
Dave Reisner
 
Default udev-177

On Jan 12, 2012 3:52 PM, "Tom Gundersen" <teg@jklm.no> wrote:
>
> Hi guys,
>
> udev-177 is now in [testing], and a few words of caution are in order.
>
> Firstly, don't be alarmed by the warnings mkinitcpio will spit out
> when using udev-177, these are harmless and will go away in the next
> mkinitcpio release (which will move to core together with udev-177).
>
> A lot changed in this release, in particular
>
> * the build system was changed around and the standard install
> locations were changed. I did my best to change everything back, as we
> are not ready to move /bin to /usr/bin yet.
>
> * blkid and modprobe are no longer used, instead their respective
> libraries are used in internal tools.
>
> Both of these things might have caused some bugs, so please let me
> know if you notice anything.
>
> * as have been mentioned previously devtmpfs is now a hard requirement.
>
> This release depends on kmod, which is currently under heavy
> development. udev will therefore stay in testing until Dave decides
> that kmod is ready for core.
>
> Cheers,
>
> Tom

Just to clarify, the errors from mkinitcpio are in regard to "missing"
firmware rules and helpers in udev. Udev now handles firmware as a built-in
function and no longer depends on external files.

Other errors can happily be reported.

Dave
 
Old 01-13-2012, 09:52 AM
Andrea Scarpino
 
Default udev-177

On 12 January 2012 21:52, Tom Gundersen <teg@jklm.no> wrote:
> Hi guys,
>
> udev-177 is now in [testing], and a few words of caution are in order.
>
> Firstly, don't be alarmed by the warnings mkinitcpio will spit out
> when using udev-177, these are harmless and will go away in the next
> mkinitcpio release (which will move to core together with udev-177).
>
> A lot changed in this release, in particular
>
> * the build system was changed around and the standard install
> locations were changed. I did my best to change everything back, as we
> are not ready to move /bin to /usr/bin yet.
>
> * blkid and modprobe are no longer used, instead their respective
> libraries are used in internal tools.
>
> Both of these things might have caused some bugs, so please let me
> know if you notice anything.
>
> * as have been mentioned previously devtmpfs is now a hard requirement.
>
> This release depends on kmod, which is currently under heavy
> development. udev will therefore stay in testing until Dave decides
> that kmod is ready for core.

I had to downgrade udev,kmod,mkinitcpio to make my laptop (wifi was
broken and applications didn't start) working again.

This error has gone after the downgrade: http://dpaste.com/687105/

I'm using systemd 38.

--
Andrea
 
Old 01-13-2012, 10:39 AM
Tom Gundersen
 
Default udev-177

Hi Andrea,

On Fri, Jan 13, 2012 at 11:52 AM, Andrea Scarpino <andrea@archlinux.org> wrote:
> I had to downgrade udev,kmod,mkinitcpio

Any change we could narrow this down a bit? If you upgrade again
kmod+mkinitcpio (possibly ignoring the versioned deps), do you still
get the bug? I assume udev is the culprit, so would be nice to get a
confirmation.

> wifi was broken and applications didn't start

When you say that wifi was broken, do you mean at the kerne/modules
level, or at the NM level? I.e. is it possible to get the wifi working
using commandline tools, or even nm-cli as root?

Any more details / logs about the applications not starting? E.g.
which applications are not starting?

> This error has gone after the downgrade: http://dpaste.com/687105/

Hm, so the NM related ones are surely caused by CK failing to start.
No idea why CK is failing though (I have tested CK+sd+[testing] and it
works fine for me). Does 'systemctl status console-kit-daemon.service'
give you any more info?

> I'm using systemd 38.

This should be unrelated, but do you have

'-session optional pam_systemd.so'

at the bottom of /etc/pam.d/kde* ? This is needed to get device ACL's
to work, so would be nice if we could include it in the standard file
(like is done for at least ssh and login).

Cheers,

Tom
 
Old 01-13-2012, 10:52 AM
Ionut Biru
 
Default udev-177

On 01/13/2012 12:52 PM, Andrea Scarpino wrote:
> On 12 January 2012 21:52, Tom Gundersen <teg@jklm.no> wrote:
>> Hi guys,
>>
>> udev-177 is now in [testing], and a few words of caution are in order.
>>
>> Firstly, don't be alarmed by the warnings mkinitcpio will spit out
>> when using udev-177, these are harmless and will go away in the next
>> mkinitcpio release (which will move to core together with udev-177).
>>
>> A lot changed in this release, in particular
>>
>> * the build system was changed around and the standard install
>> locations were changed. I did my best to change everything back, as we
>> are not ready to move /bin to /usr/bin yet.
>>
>> * blkid and modprobe are no longer used, instead their respective
>> libraries are used in internal tools.
>>
>> Both of these things might have caused some bugs, so please let me
>> know if you notice anything.
>>
>> * as have been mentioned previously devtmpfs is now a hard requirement.
>>
>> This release depends on kmod, which is currently under heavy
>> development. udev will therefore stay in testing until Dave decides
>> that kmod is ready for core.
>
> I had to downgrade udev,kmod,mkinitcpio to make my laptop (wifi was
> broken and applications didn't start) working again.
>
> This error has gone after the downgrade: http://dpaste.com/687105/
>

works fine for me.

> I'm using systemd 38.
>

i blame this one.

--
IonuČ›
 
Old 01-13-2012, 11:40 AM
Andrea Scarpino
 
Default udev-177

On 13 January 2012 12:39, Tom Gundersen <teg@jklm.no> wrote:
> Any change we could narrow this down a bit? If you upgrade again
> kmod+mkinitcpio (possibly ignoring the versioned deps), do you still
> get the bug? I assume udev is the culprit, so would be nice to get a
> confirmation.
>
I updated kmod,mkinitcpio,systemd (except udev then) and everything's fine.

> When you say that wifi was broken, do you mean at the kerne/modules
> level, or at the NM level? I.e. is it possible to get the wifi working
> using commandline tools, or even nm-cli as root?
I was broken at kernel level, I just found this (this is the output
using udev 177):

[ 10.732916] Loading firmware rtlwifi/rtl8192sefw.bin
[ 71.520133] rtl8192se:rtl92s_init_sw_vars():<0-0> Failed to request firmware!
[ 71.520141] rtlwifi:rtl_pci_probe():<0-0> Can't init_sw_vars.

> Any more details / logs about the applications not starting? E.g.
> which applications are not starting?
Forgot that.

>> This error has gone after the downgrade: http://dpaste.com/687105/
>
> Hm, so the NM related ones are surely caused by CK failing to start.
> No idea why CK is failing though (I have tested CK+sd+[testing] and it
> works fine for me). Does 'systemctl status console-kit-daemon.service'
> give you any more info?
As I said, everything's ok without udev 177 now. The console-kit-daemon too.

> This should be unrelated, but do you have
>
> '-session * * * *optional * * * *pam_systemd.so'
>
> at the bottom of /etc/pam.d/kde* ? This is needed to get device ACL's
> to work, so would be nice if we could include it in the standard file
> (like is done for at least ssh and login).
Uh. I didn't know. If you say I should add it, I'll.

--
Andrea
 
Old 01-13-2012, 12:15 PM
Tom Gundersen
 
Default udev-177

On Fri, Jan 13, 2012 at 1:40 PM, Andrea Scarpino <andrea@archlinux.org> wrote:
> [ * 10.732916] Loading firmware rtlwifi/rtl8192sefw.bin
> [ * 71.520133] rtl8192se:rtl92s_init_sw_vars():<0-0> Failed to request firmware!
> [ * 71.520141] rtlwifi:rtl_pci_probe():<0-0> Can't init_sw_vars.

Thanks, I'll look into it.

>> '-session * * * *optional * * * *pam_systemd.so'
>
> Uh. I didn't know. If you say I should add it, I'll.

Please do.

-t
 
Old 01-13-2012, 03:35 PM
Gerardo Exequiel Pozzi
 
Default udev-177

On 01/13/2012 09:40 AM, Andrea Scarpino wrote:


I was broken at kernel level, I just found this (this is the output
using udev 177):

[ 10.732916] Loading firmware rtlwifi/rtl8192sefw.bin
[ 71.520133] rtl8192se:rtl92s_init_sw_vars():<0-0> Failed to request firmware!
[ 71.520141] rtlwifi:rtl_pci_probe():<0-0> Can't init_sw_vars.




Same issue for me, using udev-177

Jan 13 13:20:39 localhost udevd[190]: validate module index
Jan 13 13:20:39 localhost udevd[190]: seq 3867 queued, 'add' 'pci'
Jan 13 13:20:39 localhost udevd[190]: passed 317 bytes to netlink
monitor 0x89cc340

Jan 13 13:20:39 localhost udevd[6825]: seq 3867 running
Jan 13 13:20:39 localhost udevd[6825]: device 0x89dbe38 has devpath
'/devices/pci0000:00/0000:00:1c.1/0000:07:00.0'
Jan 13 13:20:39 localhost udevd[6825]: no db file to read
/run/udev/data/+pci:0000:07:00.0: No such file or directory
Jan 13 13:20:39 localhost udevd[6825]: device 0x89dc250 has devpath
'/devices/pci0000:00/0000:00:1c.1'
Jan 13 13:20:39 localhost udevd[6825]: device 0x89cc340 has devpath
'/devices/pci0000:00'
Jan 13 13:20:39 localhost udevd[6825]: no db file to read
/run/udev/data/+pci:0000:00:1c.1: No such file or directory
Jan 13 13:20:39 localhost udevd[6825]: IMPORT builtin 'kmod'
/lib/udev/rules.d/80-drivers.rules:5
Jan 13 13:20:39 localhost udevd[6825]: execute 'load'
'pci:v000010ECd00008172sv000010ECsd00008181bc02sc8 0i00'

Jan 13 13:20:39 localhost udevd[190]: seq 3868 queued, 'add' 'module'
Jan 13 13:20:39 localhost udevd[6826]: seq 3868 running
Jan 13 13:20:39 localhost udevd[6826]: device 0x89cc448 has devpath
'/module/rtlwifi'
Jan 13 13:20:39 localhost udevd[6826]: no db file to read
/run/udev/data/+module:rtlwifi: No such file or directory
Jan 13 13:20:39 localhost udevd[6826]: passed -1 bytes to netlink
monitor 0x89e2e20

Jan 13 13:20:39 localhost udevd[6826]: seq 3868 processed with 0
Jan 13 13:20:39 localhost udevd[190]: passed 143 bytes to netlink
monitor 0x89cc340

Jan 13 13:20:39 localhost udevd[190]: seq 3868 done with 0
Jan 13 13:20:39 localhost udevd[190]: seq 3869 queued, 'add' 'module'
Jan 13 13:20:39 localhost udevd[6826]: seq 3869 running
Jan 13 13:20:39 localhost udevd[6826]: device 0x89cc448 has devpath
'/module/rtl8192se'
Jan 13 13:20:39 localhost udevd[6826]: no db file to read
/run/udev/data/+module:rtl8192se: No such file or directory
Jan 13 13:20:39 localhost udevd[6826]: passed -1 bytes to netlink
monitor 0x89e2e20

Jan 13 13:20:39 localhost udevd[6826]: seq 3869 processed with 0
Jan 13 13:20:39 localhost udevd[190]: passed 145 bytes to netlink
monitor 0x89cc340

Jan 13 13:20:39 localhost udevd[190]: seq 3869 done with 0
Jan 13 13:20:39 localhost kernel: [ 1863.593654] rtl8192se 0000:07:00.0:
PCI INT A -> GSI 17 (level, low) -> IRQ 17
Jan 13 13:20:39 localhost kernel: [ 1863.593679] rtl8192se 0000:07:00.0:
setting latency timer to 64

Jan 13 13:20:39 localhost udevd[190]: seq 3870 queued, 'add' 'firmware'
Jan 13 13:20:39 localhost kernel: [ 1863.606843] rtl8192se: rtl8192ce:
FW Power Save off (module option)
Jan 13 13:20:39 localhost kernel: [ 1863.607022] rtl8192se: Driver for
Realtek RTL8192SE/RTL8191SE
Jan 13 13:20:39 localhost kernel: [ 1863.607025] Loading firmware
rtlwifi/rtl8192sefw.bin

Jan 13 13:21:39 localhost udevd[190]: validate module index
Jan 13 13:21:39 localhost udevd[6825]: inserted 'rtl8192se'
Jan 13 13:21:39 localhost udevd[190]: seq 3871 queued, 'remove' 'firmware'
Jan 13 13:21:39 localhost udevd[190]: seq 3872 queued, 'add' 'drivers'
Jan 13 13:21:39 localhost udevd[6826]: seq 3872 running
Jan 13 13:21:39 localhost udevd[6825]: passed -1 bytes to netlink
monitor 0x89d1fd0
Jan 13 13:21:39 localhost udevd[6826]: device 0x89cc448 has devpath
'/bus/pci/drivers/rtl8192se'

Jan 13 13:21:39 localhost udevd[6825]: seq 3867 processed with 0
Jan 13 13:21:39 localhost udevd[6826]: no db file to read
/run/udev/data/+drivers:rtl8192se: No such file or directory
Jan 13 13:21:39 localhost udevd[6826]: device 0x89db8c8 has devpath
'/bus/pci/drivers'
Jan 13 13:21:39 localhost udevd[6826]: device 0x89dbb88 has devpath
'/bus/pci'
Jan 13 13:21:39 localhost udevd[6826]: no db file to read
/run/udev/data/+subsystem:drivers: No such file or directory
Jan 13 13:21:39 localhost udevd[6826]: passed -1 bytes to netlink
monitor 0x89e2e20

Jan 13 13:21:39 localhost udevd[6826]: seq 3872 processed with 0
Jan 13 13:21:39 localhost udevd[190]: passed 155 bytes to netlink
monitor 0x89cc340

Jan 13 13:21:39 localhost udevd[190]: seq 3867 done with 0
Jan 13 13:21:39 localhost udevd[190]: seq 3872 done with 0
Jan 13 13:21:39 localhost udevd[190]: passed 249 bytes to netlink
monitor 0x89cc340

Jan 13 13:21:39 localhost udevd[6825]: seq 3870 running
Jan 13 13:21:39 localhost udevd[6825]: IMPORT builtin 'firmware'
/lib/udev/rules.d/50-udev-default.rules:107
Jan 13 13:21:39 localhost udevd[6825]: error: can not open
'/sys/devices/pci0000:00/0000:00:1c.1/0000:07:00.0/firmware/0000:07:00.0/loading'
Jan 13 13:21:39 localhost udevd[6825]: device 0x89cc6c8 has devpath
'/devices/pci0000:00/0000:00:1c.1/0000:07:00.0'
Jan 13 13:21:39 localhost udevd[6825]: device 0x89dc250 has devpath
'/devices/pci0000:00/0000:00:1c.1'
Jan 13 13:21:39 localhost udevd[6825]: device 0x89cd858 has devpath
'/devices/pci0000:00'
Jan 13 13:21:39 localhost udevd[6825]: no db file to read
/run/udev/data/+pci:0000:07:00.0: No such file or directory
Jan 13 13:21:39 localhost udevd[6825]: passed -1 bytes to netlink
monitor 0x89d1fd0

Jan 13 13:21:39 localhost udevd[6825]: seq 3870 processed with 0
Jan 13 13:21:39 localhost udevd[190]: seq 3870 done with 0
Jan 13 13:21:39 localhost udevd[190]: passed 252 bytes to netlink
monitor 0x89cc340

Jan 13 13:21:39 localhost udevd[6825]: seq 3871 running
Jan 13 13:21:39 localhost kernel: [ 1924.106791]
rtl8192se:rtl92s_init_sw_vars():<0-0> Failed to request firmware!
Jan 13 13:21:39 localhost kernel: [ 1924.106804]
rtlwifi:rtl_pci_probe():<0-0> Can't init_sw_vars.
Jan 13 13:21:39 localhost kernel: [ 1924.106867] rtl8192se 0000:07:00.0:
PCI INT A disabled
Jan 13 13:21:39 localhost udevd[6825]: no db file to read
/run/udev/data/+firmware:0000:07:00.0: No such file or directory
Jan 13 13:21:39 localhost udevd[6825]: passed -1 bytes to netlink
monitor 0x89d1fd0

Jan 13 13:21:39 localhost udevd[190]: seq 3871 done with 0
Jan 13 13:21:39 localhost udevd[6825]: seq 3871 processed with 0


--
Gerardo Exequiel Pozzi
cos^2alpha + sin^2alpha = 1
 
Old 01-14-2012, 12:20 PM
Tom Gundersen
 
Default udev-177

On Fri, Jan 13, 2012 at 5:35 PM, Gerardo Exequiel Pozzi
<vmlinuz386@yahoo.com.ar> wrote:
> On 01/13/2012 09:40 AM, Andrea Scarpino wrote:
>>
>>
>> I was broken at kernel level, I just found this (this is the output
>> using udev 177):
>>
>> [ * 10.732916] Loading firmware rtlwifi/rtl8192sefw.bin
>> [ * 71.520133] rtl8192se:rtl92s_init_sw_vars():<0-0> *Failed to request
>> firmware!
>> [ * 71.520141] rtlwifi:rtl_pci_probe():<0-0> *Can't init_sw_vars.
>>
>>
>
> Same issue for me, using udev-177
>
> Jan 13 13:20:39 localhost udevd[190]: validate module index
> Jan 13 13:20:39 localhost udevd[190]: seq 3867 queued, 'add' 'pci'
> Jan 13 13:20:39 localhost udevd[190]: passed 317 bytes to netlink monitor
> 0x89cc340

[...]

Thanks for reporting.

Could anyone who can reproduce this please attach their dmesg with
udev's log level set to "debug" to
<https://bugs.archlinux.org/task/27938> (see instructions in the
comments).

Cheers,

Tom
 
Old 01-18-2012, 10:11 AM
Tom Gundersen
 
Default udev-177

udev-177-3 (in testing) should work around the broken drivers for now.
You will probably still see some slowdown as there is a 30 second
timeout, but at least things will boot.

To get things fixed properly we need to file bugs against the kernel.
I know that the network guys are aware of their problems, but if
anyone finds problems in other subsystems it might be worth speaking
up about.

Thanks to Gerdardo for lots and lots of testing!

Cheers,

Tom
 

Thread Tools




All times are GMT. The time now is 03:20 AM.

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