[arch-general] [kernel/update] Found hardware: "HDA-Intel: "Conexant CX20561 (Hermosa)"
Hi, Every day, I run pacman -Syyu on my Arch x86-64 installed on ThinkPad T400. I did it today too and, without a single change in my configuration, I've noticed a new message on boot: Found hardware: "HDA-Intel: "Conexant CX20561 (Hermosa)" ... Hardware is initialized using a generic method It doesn't really bother me, but I wonder where the sudden change from? $ uname -a Linux dog 3.4.2-2-ARCH #1 SMP PREEMPT Mon Jun 11 22:27:17 CEST 2012 x86_64 GNU/Linux Best regards, -- Mateusz Loskot, http://mateusz.loskot.net
Hi, Am 15.06.2012 20:35, schrieb Mateusz Loskot:
It doesn't really bother me, but I wonder where the sudden change from?
Noticed this also. In my case two pieces of hardware get found and the status on the right column says "failed". Haven't looked into it yet, but probably something else is expected as a return value. But everything works just as usual, even the state of the mixer is being restored, so this is not a major issue for me. Best regards, Karol Babioch
On 15 June 2012 19:49, Karol Babioch <karol@babioch.de> wrote:
Am 15.06.2012 20:35, schrieb Mateusz Loskot:
It doesn't really bother me, but I wonder where the sudden change from?
Noticed this also. In my case two pieces of hardware get found and the status on the right column says "failed". Haven't looked into it yet, but probably something else is expected as a return value.
In my case, nothing "fails". Here is screenshot: http://www.flickr.com/photos/mloskot/7375548454/
But everything works just as usual, even the state of the mixer is being restored, so this is not a major issue for me.
Indeed, same here. I'm just curious. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net
Hi, Am 15.06.2012 21:12, schrieb Mateusz Loskot:
In my case, nothing "fails". You've backgrounded alsa. Could you try to start it in the foreground, and see if it still doesn't fail? I would be surprised, to be honest.
Best regards, Karol Babioch
On 15 June 2012 20:16, Karol Babioch <karol@babioch.de> wrote:
Am 15.06.2012 21:12, schrieb Mateusz Loskot:
In my case, nothing "fails". You've backgrounded alsa. Could you try to start it in the foreground, and see if it still doesn't fail? I would be surprised, to be honest.
No difference, doesn't fail: http://www.flickr.com/photos/mloskot/7375588834/ Best regards, -- Mateusz Loskot, http://mateusz.loskot.net
On Fri, Jun 15, 2012 at 3:12 PM, Mateusz Loskot <mateusz@loskot.net> wrote:
On 15 June 2012 19:49, Karol Babioch <karol@babioch.de> wrote:
Am 15.06.2012 20:35, schrieb Mateusz Loskot:
It doesn't really bother me, but I wonder where the sudden change from?
Noticed this also. In my case two pieces of hardware get found and the status on the right column says "failed". Haven't looked into it yet, but probably something else is expected as a return value.
In my case, nothing "fails". Here is screenshot: http://www.flickr.com/photos/mloskot/7375548454/
But everything works just as usual, even the state of the mixer is being restored, so this is not a major issue for me.
Indeed, same here. I'm just curious.
If the driver of your sound hardware changes, then the stored state doesn't apply cleanly, and you will get such a message. I generally see it every time we move to a new kernel series (i.e., 3.3 -> 3.4). What I do is to check the mixer settings and fix them if needed, and then run "alsactl store" by hand so as to update the saved state immediately rather than waiting for it to happen at shutdown time. At that point it matches the new driver and you won't see this message again.
On 15 June 2012 20:19, Ray Kohler <ataraxia937@gmail.com> wrote:
On Fri, Jun 15, 2012 at 3:12 PM, Mateusz Loskot <mateusz@loskot.net> wrote:
On 15 June 2012 19:49, Karol Babioch <karol@babioch.de> wrote:
Am 15.06.2012 20:35, schrieb Mateusz Loskot:
It doesn't really bother me, but I wonder where the sudden change from?
Noticed this also. In my case two pieces of hardware get found and the status on the right column says "failed". Haven't looked into it yet, but probably something else is expected as a return value.
In my case, nothing "fails". Here is screenshot: http://www.flickr.com/photos/mloskot/7375548454/
But everything works just as usual, even the state of the mixer is being restored, so this is not a major issue for me.
Indeed, same here. I'm just curious.
If the driver of your sound hardware changes, then the stored state doesn't apply cleanly, and you will get such a message. I generally see it every time we move to a new kernel series (i.e., 3.3 -> 3.4).
I see.
What I do is to check the mixer settings and fix them if needed, and then run "alsactl store" by hand so as to update the saved state immediately rather than waiting for it to happen at shutdown time. At that point it matches the new driver and you won't see this message again.
Bingo! It does the trick, thanks Ray! Best regards, -- Mateusz Loskot, http://mateusz.loskot.net
With the next reboot after today's System Update (which included updates for pkg's linux and nvidia) the kernel was not able the partitions anymore and froze. Having the system restored with a liveCD and chroot I found in pacman.log dozens of lines like this [2012-06-15 17:39] -> Running build hook: [fsck] [2012-06-15 17:39] cp: cannot stat '/lib/modules/3.4.2-2-ARCH/kernel/drivers/at$ [2012-06-15 17:39] cp: cannot stat '/lib/modules/3.4.2-2-ARCH/kernel/drivers/hi$ [2012-06-15 17:39] cp: cannot stat '/lib/modules/3.4.2-2-ARCH/kernel/drivers/hi$ [2012-06-15 17:39] cp: cannot stat '/lib/modules/3.4.2-2-ARCH/kernel/drivers/hi$ [2012-06-15 17:39] cp: cannot stat '/lib/modules/3.4.2-2-ARCH/kernel/drivers/hi$ [2012-06-15 17:39] cp: cannot stat '/lib/modules/3.4.2-2-ARCH/kernel/drivers/hi$ [2012-06-15 17:39] cp: cannot stat '/lib/modules/3.4.2-2-ARCH/kernel/drivers/hi$ [2012-06-15 17:39] cp: cannot stat '/lib/modules/3.4.2-2-ARCH/kernel/drivers/hi$ Because no one else reported this here it seems to be specific to my installation. Did the modules move to another directory with 3.4.2-2 oder did I miss a package in the past ? Best regards, Nelson. P.S.: In pacman.conf I have the packages 'linux' and 'nvidia' to the 'IgnorePkgs' line but this shouldn't be the last clue I guess.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 06/15/12 13:13, Nelson Marambio wrote:
With the next reboot after today's System Update (which included updates for pkg's linux and nvidia) the kernel was not able the partitions anymore and froze. Having the system restored with a liveCD and chroot I found in pacman.log dozens of lines like this
[2012-06-15 17:39] -> Running build hook: [fsck] [2012-06-15 17:39] cp: cannot stat '/lib/modules/3.4.2-2-ARCH/kernel/drivers/at$ [2012-06-15 17:39] cp: cannot stat '/lib/modules/3.4.2-2-ARCH/kernel/drivers/hi$ [2012-06-15 17:39] cp: cannot stat '/lib/modules/3.4.2-2-ARCH/kernel/drivers/hi$ [2012-06-15 17:39] cp: cannot stat '/lib/modules/3.4.2-2-ARCH/kernel/drivers/hi$ [2012-06-15 17:39] cp: cannot stat '/lib/modules/3.4.2-2-ARCH/kernel/drivers/hi$ [2012-06-15 17:39] cp: cannot stat '/lib/modules/3.4.2-2-ARCH/kernel/drivers/hi$ [2012-06-15 17:39] cp: cannot stat '/lib/modules/3.4.2-2-ARCH/kernel/drivers/hi$ [2012-06-15 17:39] cp: cannot stat '/lib/modules/3.4.2-2-ARCH/kernel/drivers/hi$
Because no one else reported this here it seems to be specific to my installation. Did the modules move to another directory with 3.4.2-2 oder did I miss a package in the past ?
I also saw this. It seems to have sorted itself out, but I had previously relinked depmod, which had previously effectively been linked to /sbin/usr/bin/kmod, as follows: graton% ls -al $(which depmod) lrwxrwxrwx 1 root root 13 Jun 8 21:53 /sbin/depmod -> /usr/bin/kmod Notice that the link is absolute rather than relative. As a precaution, I ran: graton# pacman -S linux warning: linux-3.4.2-2 is up to date -- reinstalling And it was fine. - -- David Benfell benfell@parts-unknown.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJP25j3AAoJELT202JKF+xpCfkP/1kC0PD4TZg3yhQnp2UOLsSa s17J/CIQUOPFNiP9huR/FnOO9mWjXXx+y8RD1pC41Jf6v+P9n5cCWs6rHul4JhOS IPS8WHkgoXdmIpzWGJY23TPLKTsT70iRwid0aH3Kj2dUuoCrnU6qYvqM6jCuD/SO ude0sMZUcXCOFK3AJytIZGSr3w5hVPcXl/xONwbCVtozsA9JCgiuXD/MorkySv1h 98zWpAf3tTYa9pZ9ENhaDl35/qW77w2attidlA24VhZUlo4X8Am0e0tWcWzkTumD mWyENFR1aycZObaIgVzsh7jNKscoxqd81Ip4F0CJNHPUQvI+pj8vXYSiBPi9Nb6P uxN2shozqP7ONJycgFS4YtRXkopATJOUTlwy3hLGwglBHdkpUeKSMwnO7xZ6kDng laX4pzHVs/Gy5WZUQxszcTHqJZQxCYPKnaYHUSWLArMHak3DcbltTN5YlilWELhl dI74DjWPmOsBpJaLpKR9QGOS8guYmmXLDpP28sVRFMCtDHgUC3JspcMivD6Odghe h5aMNwpPzwJhsgBz/KwoHPDvdk03vzc6FLkwq8Vbho2hxdfW9U014pVFLNpX+CTT l9+whC8oFk50GVEgJ+viffX+7ZNunSzmOgFpcSaYS4Cos3ai4ze58fWPTIO2OXE8 gfM+iFZ/zVmQ6rg8UMio =yqx/ -----END PGP SIGNATURE-----
Am 15.06.2012 22:20, schrieb David Benfell:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 06/15/12 13:13, Nelson Marambio wrote:
With the next reboot after today's System Update (which included updates for pkg's linux and nvidia) the kernel was not able the partitions anymore and froze. Having the system restored with a liveCD and chroot I found in pacman.log dozens of lines like this
[2012-06-15 17:39] -> Running build hook: [fsck] [2012-06-15 17:39] cp: cannot stat '/lib/modules/3.4.2-2-ARCH/kernel/drivers/at$ [2012-06-15 17:39] cp: cannot stat '/lib/modules/3.4.2-2-ARCH/kernel/drivers/hi$ [2012-06-15 17:39] cp: cannot stat '/lib/modules/3.4.2-2-ARCH/kernel/drivers/hi$ [2012-06-15 17:39] cp: cannot stat '/lib/modules/3.4.2-2-ARCH/kernel/drivers/hi$ [2012-06-15 17:39] cp: cannot stat '/lib/modules/3.4.2-2-ARCH/kernel/drivers/hi$ [2012-06-15 17:39] cp: cannot stat '/lib/modules/3.4.2-2-ARCH/kernel/drivers/hi$ [2012-06-15 17:39] cp: cannot stat '/lib/modules/3.4.2-2-ARCH/kernel/drivers/hi$ [2012-06-15 17:39] cp: cannot stat '/lib/modules/3.4.2-2-ARCH/kernel/drivers/hi$
Because no one else reported this here it seems to be specific to my installation. Did the modules move to another directory with 3.4.2-2 oder did I miss a package in the past ?
I also saw this. It seems to have sorted itself out, but I had previously relinked depmod, which had previously effectively been linked to /sbin/usr/bin/kmod, as follows:
graton% ls -al $(which depmod) lrwxrwxrwx 1 root root 13 Jun 8 21:53 /sbin/depmod -> /usr/bin/kmod
So you got the same errors, relinked depmod and ran pacman -S again, right (otherwise you should have gotten the same bugy kernel image like me) ? How did you "relink" depmod in details ? Or: where has the symlink has to be placed ? Sounds like it could be the one-command-solution for me already. :)
Notice that the link is absolute rather than relative. As a precaution, I ran:
graton# pacman -S linux warning: linux-3.4.2-2 is up to date -- reinstalling
And it was fine.
- -- David Benfell benfell@parts-unknown.org
-----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQIcBAEBAgAGBQJP25j3AAoJELT202JKF+xpCfkP/1kC0PD4TZg3yhQnp2UOLsSa s17J/CIQUOPFNiP9huR/FnOO9mWjXXx+y8RD1pC41Jf6v+P9n5cCWs6rHul4JhOS IPS8WHkgoXdmIpzWGJY23TPLKTsT70iRwid0aH3Kj2dUuoCrnU6qYvqM6jCuD/SO ude0sMZUcXCOFK3AJytIZGSr3w5hVPcXl/xONwbCVtozsA9JCgiuXD/MorkySv1h 98zWpAf3tTYa9pZ9ENhaDl35/qW77w2attidlA24VhZUlo4X8Am0e0tWcWzkTumD mWyENFR1aycZObaIgVzsh7jNKscoxqd81Ip4F0CJNHPUQvI+pj8vXYSiBPi9Nb6P uxN2shozqP7ONJycgFS4YtRXkopATJOUTlwy3hLGwglBHdkpUeKSMwnO7xZ6kDng laX4pzHVs/Gy5WZUQxszcTHqJZQxCYPKnaYHUSWLArMHak3DcbltTN5YlilWELhl dI74DjWPmOsBpJaLpKR9QGOS8guYmmXLDpP28sVRFMCtDHgUC3JspcMivD6Odghe h5aMNwpPzwJhsgBz/KwoHPDvdk03vzc6FLkwq8Vbho2hxdfW9U014pVFLNpX+CTT l9+whC8oFk50GVEgJ+viffX+7ZNunSzmOgFpcSaYS4Cos3ai4ze58fWPTIO2OXE8 gfM+iFZ/zVmQ6rg8UMio =yqx/ -----END PGP SIGNATURE-----
OK, this may be the solution: Because typing 'depmod' returned a 'command not found' I recognized that my current $PATH was different from /etc/profile . So with 'source /etc/profile' the missing directories were added again, this seems to be even permanent up to now. Afterwards I could upgrade the kernel without any problems. Am 16.06.2012 08:51, schrieb Nelson Marambio:
Am 15.06.2012 22:20, schrieb David Benfell:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 06/15/12 13:13, Nelson Marambio wrote:
With the next reboot after today's System Update (which included updates for pkg's linux and nvidia) the kernel was not able the partitions anymore and froze. Having the system restored with a liveCD and chroot I found in pacman.log dozens of lines like this
[2012-06-15 17:39] -> Running build hook: [fsck] [2012-06-15 17:39] cp: cannot stat '/lib/modules/3.4.2-2-ARCH/kernel/drivers/at$ [2012-06-15 17:39] cp: cannot stat '/lib/modules/3.4.2-2-ARCH/kernel/drivers/hi$ [2012-06-15 17:39] cp: cannot stat '/lib/modules/3.4.2-2-ARCH/kernel/drivers/hi$ [2012-06-15 17:39] cp: cannot stat '/lib/modules/3.4.2-2-ARCH/kernel/drivers/hi$ [2012-06-15 17:39] cp: cannot stat '/lib/modules/3.4.2-2-ARCH/kernel/drivers/hi$ [2012-06-15 17:39] cp: cannot stat '/lib/modules/3.4.2-2-ARCH/kernel/drivers/hi$ [2012-06-15 17:39] cp: cannot stat '/lib/modules/3.4.2-2-ARCH/kernel/drivers/hi$ [2012-06-15 17:39] cp: cannot stat '/lib/modules/3.4.2-2-ARCH/kernel/drivers/hi$
Because no one else reported this here it seems to be specific to my installation. Did the modules move to another directory with 3.4.2-2 oder did I miss a package in the past ?
I also saw this. It seems to have sorted itself out, but I had previously relinked depmod, which had previously effectively been linked to /sbin/usr/bin/kmod, as follows:
graton% ls -al $(which depmod) lrwxrwxrwx 1 root root 13 Jun 8 21:53 /sbin/depmod -> /usr/bin/kmod
So you got the same errors, relinked depmod and ran pacman -S again, right (otherwise you should have gotten the same bugy kernel image like me) ?
How did you "relink" depmod in details ? Or: where has the symlink has to be placed ? Sounds like it could be the one-command-solution for me already. :)
Notice that the link is absolute rather than relative. As a precaution, I ran:
graton# pacman -S linux warning: linux-3.4.2-2 is up to date -- reinstalling
And it was fine.
- -- David Benfell benfell@parts-unknown.org
-----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQIcBAEBAgAGBQJP25j3AAoJELT202JKF+xpCfkP/1kC0PD4TZg3yhQnp2UOLsSa s17J/CIQUOPFNiP9huR/FnOO9mWjXXx+y8RD1pC41Jf6v+P9n5cCWs6rHul4JhOS IPS8WHkgoXdmIpzWGJY23TPLKTsT70iRwid0aH3Kj2dUuoCrnU6qYvqM6jCuD/SO ude0sMZUcXCOFK3AJytIZGSr3w5hVPcXl/xONwbCVtozsA9JCgiuXD/MorkySv1h 98zWpAf3tTYa9pZ9ENhaDl35/qW77w2attidlA24VhZUlo4X8Am0e0tWcWzkTumD mWyENFR1aycZObaIgVzsh7jNKscoxqd81Ip4F0CJNHPUQvI+pj8vXYSiBPi9Nb6P uxN2shozqP7ONJycgFS4YtRXkopATJOUTlwy3hLGwglBHdkpUeKSMwnO7xZ6kDng laX4pzHVs/Gy5WZUQxszcTHqJZQxCYPKnaYHUSWLArMHak3DcbltTN5YlilWELhl dI74DjWPmOsBpJaLpKR9QGOS8guYmmXLDpP28sVRFMCtDHgUC3JspcMivD6Odghe h5aMNwpPzwJhsgBz/KwoHPDvdk03vzc6FLkwq8Vbho2hxdfW9U014pVFLNpX+CTT l9+whC8oFk50GVEgJ+viffX+7ZNunSzmOgFpcSaYS4Cos3ai4ze58fWPTIO2OXE8 gfM+iFZ/zVmQ6rg8UMio =yqx/ -----END PGP SIGNATURE-----
On Sat, Jun 16, 2012 at 01:00:02PM +0200, Nelson Marambio wrote:
OK, this may be the solution:
Because typing 'depmod' returned a 'command not found' I recognized that my current $PATH was different from /etc/profile .
So with 'source /etc/profile' the missing directories were added again, this seems to be even permanent up to now.
Afterwards I could upgrade the kernel without any problems.
Sorry for hijacking on $PATH, but... If you want to play around with $PATH in .bashrc or the like sourced script, use this function or something equally careful: # adds one path to $PATH and checks if it isn't already in there addpath() { [[ "$PATH" == *$1* ]] || export PATH="$PATH:$1" } unless, of course, you fancy ending up with a crazy long $PATH (in the .bashrc case) or it's going to break in other ways... cheers! mar77i
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 06/15/12 23:51, Nelson Marambio wrote:
I also saw this. It seems to have sorted itself out, but I had previously relinked depmod, which had previously effectively been linked to /sbin/usr/bin/kmod, as follows:
graton% ls -al $(which depmod) lrwxrwxrwx 1 root root 13 Jun 8 21:53 /sbin/depmod -> /usr/bin/kmod
So you got the same errors, relinked depmod and ran pacman -S again, right (otherwise you should have gotten the same bugy kernel image like me) ?
I actually don't quite understand what happened here. Because I had seen these errors before and re-linked depmod at that time. So all I did yesterday was confirm that depmod was still linked the way it was yesterday and then do the pacman -S. I haven't been so bold as to try rebooting, but judging from some as yet unexplained (I'm still catching up) errors that have cropped up, I might well do that today.
How did you "relink" depmod in details ? Or: where has the symlink has to be placed ? Sounds like it could be the one-command-solution for me already. :)
I think it could be a one-line solution, something like ln -sf /usr/bin/kmod /sbin/depmod ; pacman -S linux But I probably actually removed the old link first. - -- David Benfell benfell@parts-unknown.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJP3NyxAAoJELT202JKF+xpxckP/37YQaOJ5IJuEGp//TwklEQK 72+htXVYDwKUEU3pHFddwEvhyn9euJijlxgj4kB+Ld4ZCQ7JTs9kMguxn0H/jeuH 5VV/uuiTAs/MJBfxNpfV8gJgeFdZR7OMXmExaGbiKroSqCTpEpJIVht6Ebt3T1R/ 5oJAVr4XvI/vRPvRv0GxCzSAcLJIOWqHljb5SWLzRTa94OXZaPJYJO6Xnb/FDW93 VMwbT1kgQ8qrHTv7aydjzQ9OafDYhI2VZ0QJDGOPZ5BfmAxSg+u/OB9k+BuwbgJ/ DtFs2jSFd4NEzBspDTtH1mdzt8yi/hdKTlrfpoloHS/S9th1LfGBga6E4h+WaRaA Qo7hybSlFwzgpyUfjzNqcyHyGrqU6ViTMc/5PLYLoR4d7ph3vHkd8+B5XZweug0H BNg0CkX8QKYN+XF4yGyTllLayDyzu3Goh66JiAaWLStkgGrLozKzEFIzfnm+z0od fgkLZLpQCFGDd0Osbnx0ztW2h1CfBseYM+2OTBojEtk2H9jAkLBskBf4kAYnH7MQ 7RyF1hC39XuQmGeIzbdTi9BCMmJoNdHqtk4BKqhGoVAOcY9gQblehfaQ0PIf98dR EhH2CkjiB+DY/liMPm2uN9rAcF3KiFfNeQGPwet5wxwkz4W1RNY5cta8tugSvq9O bFd9RjfguPiV4t1eSq0p =7H9j -----END PGP SIGNATURE-----
participants (6)
-
David Benfell
-
Karol Babioch
-
Martti Kühne
-
Mateusz Loskot
-
Nelson Marambio
-
Ray Kohler