Slow boot due to USB errors
by drago01
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
9 years, 11 months
[PATCH 0/4] Input: Add INPUT_PROP_TOPBUTTONPAD device property to Fedora kernels
by Hans de Goede
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
9 years, 11 months
Stable kernel testing
by poma
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-20...
9 years, 11 months
[PATCH] kernel.spec: xz compress modules on i686 and x86_64
by Kyle McMartin
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}
###
9 years, 11 months
2 input + 2 backlight bug-fix patches which I would like to add to the Fedora kernels
by Hans de Goede
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
9 years, 11 months
with_dbgonly
by poma
$ 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
9 years, 11 months
New package naming scheme
by poma
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
9 years, 11 months
kernel-core pulls linux-firmware
by Reindl Harald
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
9 years, 12 months
RFE: enable uas in 3.15 kernels
by Hans de Goede
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
9 years, 12 months
Re: [kernel] Add use_native_backlight quirk for 4 laptops (rhbz 983342 1093120)
by Josh Boyer
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
9 years, 12 months