Kernel Stacktrace on running lspci on Debian Testing with 3.14
Hi folks, Not yet sure whether it's a bug inside the kernel, an issue with core utils or maybe some hardware fuck up. At my new Thhinkpad T440p I'm getting an kernel stack trace when running lspci. Output of lspci is something like cannot parse file and it stopping at 0:00:0. This is happenning on lates Debian Testing with 3.14 kernel fresh installed. After this network is not working anymore. Not sure if there is anything else effected (on stacktrace e1000 modul is mentioned) Well... my question is: How to go further to investigate this issue best? Sure I can put the output here, but this is more kind of a meta question before I'm doing this;) Cheers, Frank -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/539a9ca0.3090...@frank.uvena.de
Re: Bug#751461: usb ports inaccessible after boot up
Control: reassign -1 src:linux 3.2.0-4-686-pae On Vi, 13 iun 14, 10:03:42, A.Verheul wrote: Package: vmlinuz Version: 3.2.0-4-686-pae Debian Version:Debian wheezy 7.4.0, i386 Bug summary: USB ports inaccessible after boot up Related bugreport: #500552 - involves exactly the same problem (year 2008) - then solved through CPU replacement - issue archived by now Possibly related : #750445 - describes similar problem with different error code Reporter: Arie Verheul Personal status: new to Linux -- Summary of what has been found so far -- a. The system may work properly and hence the hardware seems OK. b. The issue seems not specific for Debian but rather a general kernel issue. c. Puppy Linux seems less sensitive for the issue. d. The Intel BIOS version affects the issue. e. There are indications that the problem might involve a timing issue. -- Dear sir or madam, I do experience a persistent problem with usb port setup on boot up. The system boots up OK but ends up with non-functioning usb-ports. This renders the system useless. The hardware used is new and recent (see specs below). Initially it was attempted to install Scientific Linux, which uses the Anaconda installer. However, Anaconda boots up OK but with non-functioning usb-ports. No solution was found. Installation was done from an usb stick (no optical drive present). Therefore the issue seems to be a kernel issue which is not specific for Debian. Next it was attempted to install Debian. Just like Anaconda the Debian installer boots up with inaccessible usb ports. This could be solved by repeatedly hotplugging the usb mouse. After the usb ports had become accessible Debian could be installed properly. However, once installed Debian normally always boots up with non functioning usb-ports. Error message as below: [ 20.405006] usb 1-1: device not accepting address 2, error -110 [ 20.516591] usb 1-1: new high-speed USB device number 3 using ehci_hcd [ 36.040241] usb 1-1: device not accepting address 3, error -110 [ 36.152034] usb 1-1: new high-speed USB device number 4 using ehci_hcd [ 46.562305] usb 1-1: device not accepting address 4, error -110 [ 46.674088] usb 1-1: new high-speed USB device number 5 using ehci_hcd [ 57.084282] usb 1-1: device not accepting address 5, error -110 [ 57.084425] hub 1-0:1.0: unable to enumerate USB device on port 1 Instead of usb 1-1 the system may complain about usb 3-1 with exactly the same result. To inspect the hard disk Puppy Linux 5.7.1 was installed on a usb stick. Surprisingly Puppy always booted properly, and did not seem to suffer from the usb issue. However, when the system BIOS was updated in an attempt to solve the issue (see below for version), Puppy randomly failed in about half of the cases. Returning to the previous BIOS version solved this. This was reported to Intel. From experiments it was found that Debian could be made to work with properly functioning usb-ports by simply deleting some log files from the /var/log directory (using Puppy). Deleted were kernel.log and the various dmesg files. Although the effect of this remains unclear it gives gives a 70% chance for a working system. Strange enough the reported errors remain exactly the same, even if the system ends up in a properly working state. The system has been used this way for over 2 month now with consistently the same results. The impression is that the solution found for bug #500552 was rather a workaround than a solution. The random behaviour of both Debian and Puppy (the latter with updated BIOS) could indicate a timing issue. In this respect it might be relevant that the system uses an SSD which is faster than most HDD's. The effect of deleting log files could be just a slight delay in OS loading. I therefore took notes of the time of the first reported usb error, both in cases that ended up with functioning usb ports as in cases with non functioning usb ports. -- Boot up ending with non-functioning usb-ports 20.178 20.178 20.178 20.184 20.200 20.405 Boot up ending with properly functioning usb-ports 20.465 20.477 20.508 20.544 -- These data support the timing issue hypothesis. A first error at 20.405 or earlier would result in non-functioning usb-ports, a first error at 20.465 or later would result in
Processed: Re: Bug#751461: usb ports inaccessible after boot up
Processing control commands: reassign -1 src:linux 3.2.0-4-686-pae Bug #751461 [vmlinuz] usb ports inaccessible after boot up Warning: Unknown package 'vmlinuz' Bug reassigned from package 'vmlinuz' to 'src:linux'. No longer marked as found in versions 3.2.0-4-686-pae. Ignoring request to alter fixed versions of bug #751461 to the same values previously set Bug #751461 [src:linux] usb ports inaccessible after boot up The source 'linux' and version '3.2.0-4-686-pae' do not appear to match any binary packages Marked as found in versions linux/3.2.0-4-686-pae. -- 751461: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=751461 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/handler.s.b751461.140265298830211.transcr...@bugs.debian.org
Bug#751488: initramfs-tools: Shell spawned despite panic=0
Package: initramfs-tools
Version: 0.109.1
Severity: critical
Tags: patch
Hi,
I've set panic=0 as a kernel cmdline argument which should trigger a
reboot instead of spawning a shell. However, the reboot seems to be
uneffective and a shell is spawned nevertheless. This is unpleasing
since spawn=0 is marketed as a security feature in
initramfs-tools(8):
panic sets an timeout on panic. panic=sec is a documented
security feature: it disables the debug shell.
Output on screen:
Loading, please wait ...
Spawning shell within the initramfs
Rebooting automatically due to panic= boot argument
BusyBox v1.20.2 (Debian 1:1.20.0-7) built-in shell (ash)
Enter 'help' for a list of built-in commands.
/bin/sh: can't access tty; job control turned off
(initramfs) _
The commands halt, reboot, etc. don't work either.
To fix the security impact of an open shell I propose to at least add a
return after the reboot command so that if the reboot is effectively a
NOP still no shell is spawned.
diff --git a/scripts/functions b/scripts/functions
index 5352f1d..de64494 100644
--- a/scripts/functions
+++ b/scripts/functions
@@ -43,6 +43,7 @@ panic()
echo Rebooting automatically due to panic= boot argument
sleep ${panic}
reboot
+ return
fi
modprobe -v i8042 || true
modprobe -v atkbd || true
Regards,
Lukas
--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
https://lists.debian.org/cacb1aesuy7boyp9q4z1taovla3udqb-h3vhwyruolgrq2w4...@mail.gmail.com
[PATCH V3] ppc64el: installer: new files
This creates the debian/installer/ppc64el dir with the usual contents
(kernel-versions, packages-list, and modules/).
For commonality with the other powerpc-based ports, make the installer's
module lists '#include' those from the ppc64 port (which in turn '#includes'
some from the powerpc port).
The differences are 4 modules from ps3/cell/powermacs systems removed from
nic-modules and scsi-modules.
Changes from V2 [1]:
- Removed symlinks 'debian/installer/ppc64el/modules/{powerpc,ppc64}'.
- Updated #include paths in module lists accordingly (path of ppc64 port).
[2] https://lists.debian.org/debian-kernel/2014/06/msg00064.html
Signed-off-by: Mauricio Faria de Oliveira mauri...@linux.vnet.ibm.com
---
debian/installer/ppc64el/kernel-versions |2 ++
.../installer/ppc64el/modules/ppc64el/ata-modules |1 +
.../ppc64el/modules/ppc64el/btrfs-modules |1 +
.../ppc64el/modules/ppc64el/cdrom-core-modules |1 +
.../installer/ppc64el/modules/ppc64el/core-modules |1 +
.../installer/ppc64el/modules/ppc64el/crc-modules |1 +
.../ppc64el/modules/ppc64el/crypto-dm-modules |1 +
.../ppc64el/modules/ppc64el/crypto-modules |1 +
.../ppc64el/modules/ppc64el/event-modules |1 +
.../installer/ppc64el/modules/ppc64el/ext4-modules |1 +
.../ppc64el/modules/ppc64el/fancontrol-modules |1 +
.../installer/ppc64el/modules/ppc64el/fat-modules |1 +
.../ppc64el/modules/ppc64el/firewire-core-modules |1 +
.../installer/ppc64el/modules/ppc64el/fuse-modules |1 +
.../ppc64el/modules/ppc64el/hypervisor-modules |1 +
.../ppc64el/modules/ppc64el/input-modules |1 +
.../ppc64el/modules/ppc64el/isofs-modules |1 +
.../installer/ppc64el/modules/ppc64el/jfs-modules |1 +
.../installer/ppc64el/modules/ppc64el/kernel-image |1 +
.../installer/ppc64el/modules/ppc64el/loop-modules |1 +
.../installer/ppc64el/modules/ppc64el/md-modules |1 +
.../ppc64el/modules/ppc64el/mouse-modules |1 +
.../ppc64el/modules/ppc64el/multipath-modules |1 +
.../installer/ppc64el/modules/ppc64el/nbd-modules |1 +
.../installer/ppc64el/modules/ppc64el/nic-modules |5 +
.../ppc64el/modules/ppc64el/nic-shared-modules |1 +
.../installer/ppc64el/modules/ppc64el/ppp-modules |1 +
.../installer/ppc64el/modules/ppc64el/sata-modules |1 +
.../ppc64el/modules/ppc64el/scsi-common-modules|1 +
.../ppc64el/modules/ppc64el/scsi-core-modules |1 +
.../ppc64el/modules/ppc64el/scsi-extra-modules |1 +
.../installer/ppc64el/modules/ppc64el/scsi-modules |3 +++
.../ppc64el/modules/ppc64el/serial-modules |1 +
.../ppc64el/modules/ppc64el/squashfs-modules |1 +
.../installer/ppc64el/modules/ppc64el/udf-modules |1 +
.../ppc64el/modules/ppc64el/uinput-modules |1 +
.../installer/ppc64el/modules/ppc64el/usb-modules |1 +
.../ppc64el/modules/ppc64el/usb-serial-modules |1 +
.../ppc64el/modules/ppc64el/usb-storage-modules|1 +
.../ppc64el/modules/ppc64el/virtio-modules |1 +
.../installer/ppc64el/modules/ppc64el/xfs-modules |1 +
debian/installer/ppc64el/package-list |1 +
42 files changed, 49 insertions(+), 0 deletions(-)
create mode 100644 debian/installer/ppc64el/kernel-versions
create mode 100644 debian/installer/ppc64el/modules/ppc64el/ata-modules
create mode 100644 debian/installer/ppc64el/modules/ppc64el/btrfs-modules
create mode 100644 debian/installer/ppc64el/modules/ppc64el/cdrom-core-modules
create mode 100644 debian/installer/ppc64el/modules/ppc64el/core-modules
create mode 100644 debian/installer/ppc64el/modules/ppc64el/crc-modules
create mode 100644 debian/installer/ppc64el/modules/ppc64el/crypto-dm-modules
create mode 100644 debian/installer/ppc64el/modules/ppc64el/crypto-modules
create mode 100644 debian/installer/ppc64el/modules/ppc64el/event-modules
create mode 100644 debian/installer/ppc64el/modules/ppc64el/ext4-modules
create mode 100644 debian/installer/ppc64el/modules/ppc64el/fancontrol-modules
create mode 100644 debian/installer/ppc64el/modules/ppc64el/fat-modules
create mode 100644
debian/installer/ppc64el/modules/ppc64el/firewire-core-modules
create mode 100644 debian/installer/ppc64el/modules/ppc64el/fuse-modules
create mode 100644 debian/installer/ppc64el/modules/ppc64el/hypervisor-modules
create mode 100644 debian/installer/ppc64el/modules/ppc64el/input-modules
create mode 100644 debian/installer/ppc64el/modules/ppc64el/isofs-modules
create mode 100644 debian/installer/ppc64el/modules/ppc64el/jfs-modules
create mode 100644 debian/installer/ppc64el/modules/ppc64el/kernel-image
create mode 100644 debian/installer/ppc64el/modules/ppc64el/loop-modules
create mode 100644 debian/installer/ppc64el/modules/ppc64el/md-modules
create mode 100644 debian/installer/ppc64el/modules/ppc64el/mouse-modules
create mode
Re: [PATCH V2 0/9] Add ppc64el support to src:linux
Ben, This still adds configuration for 'powerpc' and 'ppc64' flavours, which do not exist for ppc64el! Please send a new version of this patch. Sure. I will review and test it on the other ports. I guess I am confusing the symlinks for the #include paths in some form. I just sent a V3 for this one. As for the other patches plus the transactional-memory option you added, I confirm the SVN source pkg is working fine on KVM guests and PowerNV. Thanks, -- Mauricio Faria de Oliveira IBM Linux Technology Center -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/539b1369.9020...@linux.vnet.ibm.com
Bug#749688: linux: add mips64 and mips64el support
New 'add mips64 support': I forgot to add mips64 and mips64el into debian/config/defines On Sat, Jun 7, 2014 at 9:00 AM, Yunqiang Su wzss...@gmail.com wrote: On Fri, Jun 6, 2014 at 10:47 AM, Ben Hutchings b...@decadent.org.uk wrote: On Thu, 2014-06-05 at 17:31 +0800, Yunqiang Su wrote: On Mon, Jun 2, 2014 at 7:57 PM, Ben Hutchings b...@decadent.org.uk wrote: [...] diff -Nru linux-3.15~rc7/debian/config/mips64/defines linux-3.15~rc7/debian/config/mips64/defines --- linux-3.15~rc7/debian/config/mips64/defines 1970-01-01 00:00:00.0 + +++ linux-3.15~rc7/debian/config/mips64/defines 2014-05-29 00:26:03.0 + @@ -0,0 +1,50 @@ +[base] +flavours: + r4k-ip22 + r5k-ip32 + sb1-bcm91250a + 5kc-malta + octeon I don't think we should build such a large number of flavours for a new architecture. Most of those machines are obsolete by now. Which one do you think to be kept? sb1-bcm91250a and octeon ? That seems sensible - those would cover all of Debian's own MIPS hardware that can run big-endian. For mips64(eb), only these 2 flavors are kept. [...] diff -Nru linux-3.15~rc7/debian/config/mipsel/defines linux-3.15~rc7/debian/config/mipsel/defines --- linux-3.15~rc7/debian/config/mipsel/defines 2014-05-06 09:37:03.0 + +++ linux-3.15~rc7/debian/config/mipsel/defines 2014-05-29 00:27:04.0 + This patch does a little more than the subject says! @@ -6,6 +6,7 @@ loongson-2e loongson-2f loongson-3 + octeon Is it useful to run Octeon on little-endian mode? I have not very clear for mipsel while we have mips64el only now. Maybe we should keep octeon in mips64el while not in mipsel OK. [...] diff -Nru linux-3.15~rc7/debian/installer/mips64/modules/mips64/btrfs-modules linux-3.15~rc7/debian/installer/mips64/modules/mips64/btrfs-modules --- linux-3.15~rc7/debian/installer/mips64/modules/mips64/btrfs-modules 1970-01-01 00:00:00.0 + +++ linux-3.15~rc7/debian/installer/mips64/modules/mips64/btrfs-modules 2014-05-29 02:20:50.0 + @@ -0,0 +1 @@ +#include btrfs-modules [...] All the installer modules configuration files should be copied *by reference* from mips or mipsel, either using a relative #include or a directory symlink. OK, I will link them, while diff (debdiff) treats them as normal file. That's true, but if you check out the source using svn or git-svn you can make a diff that shows symlinks. git-svn would be best, as you could then split your changes up into multiple patches: 1. Move common MIPS kernel config files to kernelarch-mips 2. Add kernel config files for mips64/mips64el 3. Add installer config files to mips64/mips64el the dsc file is here: http://mips.wicp.net:9998/mips2/temp/ Looking at the new patch: --- linux-3.15~rc8/debian/config/defines2014-05-14 15:41:05.0 + +++ linux-3.15~rc8/debian/config/defines2014-06-05 06:23:54.0 + @@ -14,6 +14,8 @@ m68k mips mipsel + mips64 + mips64el or1k powerpc powerpcspe @@ -25,7 +27,7 @@ sparc sparc64 x32 -compiler: gcc-4.8 +compiler: gcc-4.9 featuresets: none rt This is the default setting for all architectures; you must not change it but instead override it in debian/config/mips64/defines and debian/config/mips64el/defines. [...] diff -Nru linux-3.15~rc8/debian/config/mips/defines linux-3.15~rc8/debian/config/mips/defines --- linux-3.15~rc8/debian/config/mips/defines 2014-05-06 09:37:03.0 + +++ linux-3.15~rc8/debian/config/mips/defines 2014-06-05 05:43:07.0 + @@ -12,29 +12,47 @@ image-file: vmlinux [image] -initramfs: false +initramfs: true install-stem: vmlinux [r4k-ip22_description] I don't think you can simply change this, as some of the boot loaders used on old MIPS systems don't support an initramfs. If it was that simple, we would have done it already! I changed them back now. [...] --- linux-3.15~rc8/debian/installer/mips64el/package-list 1970-01-01 00:00:00.0 + +++ linux-3.15~rc8/debian/installer/mips64el/package-list 2014-06-05 05:59:58.0 + @@ -0,0 +1,11 @@ +# This file is used to build up the control file. The kernel version and +# -di are appended to the package names. Section can be left out. So can +# architecture, which is derived from the files in the modules directory. +# It overwrites specifications from /usr/share/kernel-wedge/package-list. +# +Package: kernel-image +Provides_sb1-bcm91250a: ata-modules, ext2-modules, ext3-modules, ext4-modules, rtc-modules +Provides_5kc-malta: ata-modules, ext2-modules, ext3-modules, ext4-modules, rtc-modules +Provides_loongson-2e: ata-modules, ext2-modules, ext3-modules, ext4-modules, rtc-modules +Provides_loongson-2f: ata-modules, ext2-modules, ext3-modules, ext4-modules, rtc-modules
Bug#597897: Current status of alsa-firmware?
Is there an update on the packaging status of alsa-firmware, or integration into linux-firmware-nonfree? This RFP was reported more than 3 years ago, yet firmware images for certain audio devices are still missing in Debian. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/539b3f19.6040...@gmail.com
