On 09.07.10 at 17:15, 0bo0 <0.bugs.only.0@gmail.com> wrote: On Fri, Jul 9, 2010 at 12:46 AM, Jan Beulich
wrote: The question then is why request_firmware() succeeds. We're not talking about a kernel you built yourself, do we? no, not custom. atm, this is,
uname -a Linux server 2.6.34.1-2-xen #1 SMP 2010-07-06 15:11:07 +0200 x86_64 x86_64 x86_64 GNU/Linux lsb_release -a LSB Version: core-2.0-noarch:core-3.2-noarch:core-4.0-noarch:core-2.0-x86_64:core-3.2-x86_64:core-4. 0-x86_64:desktop-4.0-amd64:desktop-4.0-noarch:graphics-2.0-amd64:graphics-2.0-noarch:g raphics-3.2-amd64:graphics-3.2-noarch:graphics-4.0-amd64:graphics-4.0-noarch Distributor ID: SUSE LINUX Description: openSUSE 11.3 (x86_64) Release: 11.3 Codename: n/a grep base /etc/zypp/repos.d/Kernel_113.repo
baseurl=http://download.opensuse.org/repositories/Kernel:/openSUSE-11.3/open SUSE_11.3
Again, this is a different thing. Can we please finally get to know how a native kernel of the same version behaves?
You may want to set udev_log="info" in /etc/udev/udev.conf and USE_SYSLOG="yes" in /etc/sysconfig/hardware/config to get relevant output from /lib/udev/firmware.sh.
You may want to set udev_log="info" in /etc/udev/udev.conf and USE_SYSLOG="yes" in /etc/sysconfig/hardware/config to get
mkdir -p /etc/sysconfig/hardware
udev_log="info" < -- /etc/udev/udev.conf USE_SYSLOG="yes" <-- /etc/sysconfig/hardware/config to get
reboot uname -a Linux server 2.6.34.1-2-default #1 SMP 2010-07-06 15:11:07 +0200 x86_64 x86_64 x86_64 GNU/Linux
egrep -i "amd|microcode" /var/log/* ...
And for comparison the same with 2.6.34.1-2-xen ? On -default, the messages clearly indicate that request_firmware() is failing on that file (as expected), but the fact that Xen gets presented with a firmware image at all requires that request_firmware() is not failing as expected on -xen. Jan -- To unsubscribe, e-mail: opensuse-virtual+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-virtual+help@opensuse.org