kernel May 2014

kernel@lists.fedoraproject.org

22 participants
21 discussions

Slow boot due to USB errors
by drago01 12 May '14

12 May '14

Hi, Startup finished in 8.394s (firmware) + 590ms (loader) + 918ms (kernel) + 19.389s (initrd) + 1.940s (userspace) = 31.234s ~19.4 seconds during initrd seems like a bit much ... looking at the log output I have noticed this: [ 3.306309] usb 1-4: new full-speed USB device number 3 using xhci_hcd [ 5.502178] usb 1-4: unable to read config index 0 descriptor/start: -71 [ 5.502190] usb 1-4: can't read configurations, error -71 [ 5.655591] usb 1-4: new full-speed USB device number 4 using xhci_hcd [ 7.699049] usb 1-4: unable to read config index 0 descriptor/start: -71 [ 7.699060] usb 1-4: can't read configurations, error -71 [ 7.851791] usb 1-4: new full-speed USB device number 5 using xhci_hcd [ 9.895842] usb 1-4: unable to read config index 0 descriptor/start: -71 [ 9.895854] usb 1-4: can't read configurations, error -71 [ 9.895997] hub 1-0:1.0: unable to enumerate USB device on port 4 [ 10.048994] usb 1-5: new high-speed USB device number 6 using xhci_hcd [ 10.363192] usb 1-5: New USB device found, idVendor=0bda, idProduct=58b1 [ 10.363202] usb 1-5: New USB device strings: Mfr=3, Product=1, SerialNumber=2 [ 10.363208] usb 1-5: Product: FJ Camera [ 10.363212] usb 1-5: Manufacturer: Generic [ 10.363215] usb 1-5: SerialNumber: 200901010001 [ 10.519824] usb 1-7: new full-speed USB device number 7 using xhci_hcd [ 10.684975] usb 1-7: New USB device found, idVendor=8087, idProduct=07dc [ 10.684986] usb 1-7: New USB device strings: Mfr=0, Product=0, SerialNumber=0 [ 10.942675] usb 1-4: new full-speed USB device number 8 using xhci_hcd [ 13.139694] usb 1-4: unable to read config index 0 descriptor/start: -71 [ 13.139731] usb 1-4: can't read configurations, error -71 [ 13.292830] usb 1-4: new full-speed USB device number 9 using xhci_hcd [ 15.489755] usb 1-4: unable to read config index 0 descriptor/start: -71 [ 15.489766] usb 1-4: can't read configurations, error -71 [ 15.642970] usb 1-4: new full-speed USB device number 10 using xhci_hcd [ 17.687316] usb 1-4: unable to read config index 0 descriptor/start: -71 [ 17.687328] usb 1-4: can't read configurations, error -71 [ 17.840189] usb 1-4: new full-speed USB device number 11 using xhci_hcd [ 19.884509] usb 1-4: unable to read config index 0 descriptor/start: -71 [ 19.884522] usb 1-4: can't read configurations, error -71 [ 19.884617] hub 1-0:1.0: unable to enumerate USB device on port 4 [ 19.919050] PM: Starting manual resume from disk [ 19.940256] EXT4-fs (sda4): mounted filesystem with ordered data mode. Opts: (null) [ 20.172347] usb 1-4: new full-speed USB device number 12 using xhci_hcd So the questions are 1) what do those message actually mean? Seems like everything works anyway 2) why do those block the boot process ... its not like the root fs is on a usb driver or something. Kernel is 3.14.3-200.fc20.x86_64 (but does this not seem to matter it happens for pretty much every kernel for almost every but not all boot ups). Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 001 Device 007: ID 8087:07dc Intel Corp. Bus 001 Device 006: ID 0bda:58b1 Realtek Semiconductor Corp. Bus 001 Device 012: ID 04f3:009b Elan Microelectronics Corp. Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Any ideas where to investigate? Those error messages are really cryptic and do not tell me anything. Thanks

5 15

[PATCH 0/4] Input: Add INPUT_PROP_TOPBUTTONPAD device property to Fedora kernels
by Hans de Goede 10 May '14

10 May '14

Hi All, Now that INPUT_PROP_TOPBUTTONPAD has landed in Linus' tree, upstream xorg-x11-drv-synaptics is relying on it as the one and only way to identify clickpads with top buttons (as found on all new lenovo laptops). Currently in Fedora we have a set of udev rules, which need to be expanded for each new model, instead of using INPUT_PROP_TOPBUTTONPAD. Now that yet another Lenovo model has surfaced with this type of touchpad: https://bugzilla.redhat.com/show_bug.cgi?id=1096436 I would like to move Fedora to the solution upstream is using. The first step for this would be to add these 4 patches to the Fedora kernels. I've also send them to stable, and Dmitry Torokhov and Greg KH are both ok with them going into stable. But Greg has a bit of a backlog atm. For now I'll just extend the udev rules in xorg-x11-drv-synaptics for this one more model, since otherwise things will break for people not using the very latest Fedora kernel. Once these changes have been in Fedora kernels for a while I plan to rebase xorg-x11-drv-synaptics to the latest upstream, making it rely on INPUT_PROP_TOPBUTTONPAD and avoiding the need to update it for each new laptop model with such a touchpad. Regards, Hans

2 7

Stable kernel testing
by poma 09 May '14

09 May '14

bodhi, autoqa, hreindl, drago01, roshi, bradw, aleph, bojan, Anonymous Tester, freddyw, dandim, amluto, csouth3, mstevens, abderrahman, amessina, bitlord, xosevp, quickbooks, gkulyk, rdieter, jforbes and arcfi. Guys, which of you uses the debug version of the kernel for testing it? poma Ref. https://admin.fedoraproject.org/updates/FEDORA-2014-5808/kernel-3.14.2-200.…

5 6

[PATCH] kernel.spec: xz compress modules on i686 and x86_64
by Kyle McMartin 07 May '14

07 May '14

Pretty grody, but it seems to be working... it has to happen after module signing (obviously) and after find-debuginfo.sh runs as well, so tacking it onto the end seems sensible, and then just fixing up the file lists as we go. Provides a nice tidy savings to the disk footprint: kyle@dreadnought:~% for i in kernel-core-3.15.0-0.rc3.git4.1.fc21.x86_64.rpm \ kernel-core-3.15.0-0.rc3.git4.1.fc21.x86_64.rpm.1; do \ rpm -qip $i | grep '^Size'; done Size : 43011603 Size : 81106737 kmod has handed .xz and .gz modules for a long time now, and can cope. I was thinking we might also %ghost the .ko, and have a %post install script that un-xz the modules in /proc/modules, but none of them are big enough for that to be worthwhile I think (maybe XFS, but I doubt it.) --Kyle --- a/kernel.spec +++ b/kernel.spec @@ -12,8 +12,14 @@ Summary: The Linux kernel # architectures are added. %ifarch %{ix86} x86_64 %global signmodules 1 +%global zipmodules 1 %else %global signmodules 0 +%global zipmodules 0 +%endif + +%if %{zipmodules} +%global zipsed -e 's/\.ko$/\.ko.xz/' %endif # % define buildid .local @@ -1713,9 +1719,9 @@ BuildKernel() { # Make sure the files lists start with absolute paths or rpmbuild fails. # Also add in the dir entries - sed -e 's/^lib*/\/lib/' $RPM_BUILD_ROOT/k-d.list > ../kernel${Flavour:+-${Flavour}}-modules.list - sed -e 's/^lib*/%dir \/lib/' $RPM_BUILD_ROOT/module-dirs.list > ../kernel${Flavour:+-${Flavour}}-core.list - sed -e 's/^lib*/\/lib/' $RPM_BUILD_ROOT/modules.list >> ../kernel${Flavour:+-${Flavour}}-core.list + sed -e 's/^lib*/\/lib/' %{?zipsed} $RPM_BUILD_ROOT/k-d.list > ../kernel${Flavour:+-${Flavour}}-modules.list + sed -e 's/^lib*/%dir \/lib/' %{?zipsed} $RPM_BUILD_ROOT/module-dirs.list > ../kernel${Flavour:+-${Flavour}}-core.list + sed -e 's/^lib*/\/lib/' %{?zipsed} $RPM_BUILD_ROOT/modules.list >> ../kernel${Flavour:+-${Flavour}}-core.list # Cleanup rm -f $RPM_BUILD_ROOT/k-d.list @@ -1836,6 +1842,9 @@ popd %{modsign_cmd} signing_key.priv.sign signing_key.x509.sign $RPM_BUILD_ROOT/lib/modules/%{KVERREL}/ \ fi \ fi \ + if [ "%{zipmodules}" -eq "1" ]; then \ + find $RPM_BUILD_ROOT/lib/modules/ -type f -name '*.ko' | xargs xz; \ + fi \ %{nil} ###

3 5

2 input + 2 backlight bug-fix patches which I would like to add to the Fedora kernels
by Hans de Goede 06 May '14

06 May '14

Hi All, FYI I've just added a patch with another set of acpi-video backlight quirks to the fedora kernel pkgs. This should be non controversial since upstream has agreed to maintain the quirk table for now, until it is certain that switch to using video.use_native_backlight=1 as default can be safely done. There are 4 more patches which I would like to add to the kernel to fix various bigs, I've attached them here. Here is the changelog from my (local) spec file modifications: - Add a patch to fix the Synaptics Touch Pad V 103S found on some keyboard docks for win8 tablets - Add a patch to fix the elantech touchpad on Gigabyte U2442 laptops - Add a patch to fix backlight control on the Samsung NC210/NC110 (rhbz#861573) - Add a patch to fix backlight & wifi on the Asus EEE PC 1015PX (rhbz#1067181) The first patch has been reviewed upstream (but not yet applied). The second and third patch should be uncontroversial and get accepted upstream. The fourth patch may turn out to be a bit controversial when someone upstream actually gets around to review it. But there seems to be no other way, and the user has been applying the same fix from the kernel cmdline for months now. All of them have a Cc: stable Regards, Hans

3 3

with_dbgonly
by poma 05 May '14

05 May '14

$ diff kernel-3.15.0-0.rc4.git0.3.fc21.src/kernel.spec \ > kernel-3.15.0-0.rc4.git0.1.fc21.src/kernel.spec 37c37 < %global baserelease 3 --- > %global baserelease 1 644,645d643 < Patch30000: cachelines-revert.patch < 1367,1368d1364 < ApplyPatch cachelines-revert.patch < 2231a2228,2231 > * Mon May 05 2014 Josh Boyer <jwboyer(a)fedoraproject.org> - 3.15.0-0.rc4.git0.1 > - Linux v3.15-rc4 > - Disable debugging options. > $ rpmbuild -ba --with dbgonly --without debuginfo --target=`uname -m` kernel.spec $ ls -1 kernel-3.15.0-0.rc4.git0.3.fc21.i686.rpm <- kernel-3.15.0-0.rc4.git0.3.fc21.src.rpm kernel-debug-3.15.0-0.rc4.git0.3.fc21.i686.rpm kernel-debug-core-3.15.0-0.rc4.git0.3.fc21.i686.rpm kernel-debug-devel-3.15.0-0.rc4.git0.3.fc21.i686.rpm kernel-debug-modules-3.15.0-0.rc4.git0.3.fc21.i686.rpm kernel-debug-modules-extra-3.15.0-0.rc4.git0.3.fc21.i686.rpm kernel-headers-3.15.0-0.rc4.git0.3.fc21.i686.rpm Is the "kernel-3.15.0-0.rc4.git0.3.fc21.i686.rpm" superfluous, given that it should belong to the 'baseonly'? poma

1 0

New package naming scheme
by poma 04 May '14

04 May '14

There is a discrepancy in the terminology of these two packages: - kernel-drivers[1] - kernel-modules-extra Are these[1] modules passed the driving test? Should I read the "Banana Split" thread, again? Perhaps the "kernel-modules" for the "kernel-drivers" is the proper name. poma

8 12

kernel-core pulls linux-firmware
by Reindl Harald 01 May '14

01 May '14

Hi where is this dependency from? after confirm you can happily "yum remove linux-firmware" without any problems and the next kernel update pulls it again which is not how a normal dependency works because it would not allow to uninstall the dependency without remove the pulling package hence why i have on our virtualized infrastructure for years a empty meta-package with provides/obsoletes but given now that we have "kernel-core" and "kernel-drivers" this dependecy should be only pulled only by "kernel-drivers" _____________________________________________________ ---> Package kernel-core.x86_64 0:3.15.0-0.rc3.git3.1.fc21 will be installed --> Processing Dependency: linux-firmware >= 20130724-29.git31f6b30 for package: kernel-core-3.15.0-0.rc3.git3.1.fc21.x86_64 ---> Package libcap-ng.x86_64 0:0.7.4-1.fc21 will be updated ---> Package libcap-ng.x86_64 0:0.7.4-2.fc21 will be an update ---> Package lyx-fonts.noarch 0:2.1.0-0.fc21 will be updated ---> Package lyx-fonts.noarch 0:2.1.0-2.fc21 will be an update ---> Package vim-minimal.x86_64 2:7.4.258-1.fc21 will be updated ---> Package vim-minimal.x86_64 2:7.4.258-2.fc21 will be an update --> Running transaction check ---> Package linux-firmware.noarch 0:20140317-37.gitdec41bce.fc21 will be installed --> Finished Dependency Resolution --> Finding unneeded leftover dependencies Found and removing 0 unneeded dependencies _____________________________________________________ Name : linux-firmware Arch : noarch Version : 20140317 Release : 37.gitdec41bce.fc21 Size : 50 M Repo : installed _____________________________________________________ [root@rawhide ~]# rpm -qa | grep kernel kernel-core-3.15.0-0.rc3.git3.1.fc21.x86_64 kernel-core-3.15.0-0.rc3.git1.10.fc21.x86_64 _____________________________________________________ Is this ok [y/N]: y Downloading packages: Running transaction check Running transaction test Transaction test succeeded Running transaction Erasing : linux-firmware-20140317-37.gitdec41bce.fc21.noarch 1/1 Verifying : linux-firmware-20140317-37.gitdec41bce.fc21.noarch 1/1 Removed: linux-firmware.noarch 0:20140317-37.gitdec41bce.fc21 _____________________________________________________ [root@rawhide ~]# rpm -qa | grep kernel kernel-core-3.15.0-0.rc3.git3.1.fc21.x86_64 kernel-core-3.15.0-0.rc3.git1.10.fc21.x86_64

2 2

RFE: enable uas in 3.15 kernels
by Hans de Goede 01 May '14

01 May '14

Hi All, I would like to suggest to enable uas in the 3.15 kernel: CONFIG_USB_UAS=m For all platforms. Usb Attached Scsi is a standard, much improved usb storage protocol allowing the use of NCQ over usb, and slowly more devices are hitting the market supporting it. Besides being a whole lot faster, I also put 1.5 months of full-time work in getting it into shape and getting it of the CONFIG_BROKEN list upstream, which has now all finally landed. So I also have a small personal bias towards enabling it :) Regards, Hans

2 3

Re: [kernel] Add use_native_backlight quirk for 4 laptops (rhbz 983342 1093120)
by Josh Boyer 01 May '14

01 May '14

On Thu, May 1, 2014 at 8:51 AM, Hans de Goede <jwrdegoede(a)fedoraproject.org> wrote: > commit f22ebd0b2b7a7d5d07367c5c50f81185b9fa672b > Author: Hans de Goede <hdegoede(a)redhat.com> > Date: Thu May 1 14:51:32 2014 +0200 > > Add use_native_backlight quirk for 4 laptops (rhbz 983342 1093120) > > ...Add-4-new-models-to-the-use_native_backli.patch | 89 ++++++++++++++++++++ > kernel.spec | 9 ++ > 2 files changed, 98 insertions(+), 0 deletions(-) Hi Hans, In the future, could you please refrain from committing patches like this directly without any heads up or discussion? A quick post to this list with a link to the upstream submission is ideal. I really appreciate the effort your putting in on the backlight stuff here, but this patch was committed before it was even reviewed upstream. The previous incarnation of it was rejected because a supposed fix is coming in 3.16. It's certainly reasonable for Fedora to carry this until 3.16 lands, but I'd like it if we can get some agreement from upstream one way or another. There's no major rush at this point, particularly for rawhide. Thanks. josh

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

kernel May 2014