Bug#1017977: Fails to load intel/ibt-20-1-3.sfi
Hi, I just upgraded linux-image-amd64 and that pulled in 6.1.0-9 and now intel/ibt-20-1-3.sfi loads without issues and my Bluetooth keyboard works, even when cold booting! Cold booting 6.1.0-7 it fails and my keyboard is unresponsive. For reference, # grep -E '(version 6\.1\.0-|ibt-20-1-3\.sfi)' /var/log/kern.log | sed 's/.* kernel: //' [0.00] Linux version 6.1.0-7-amd64 (debian-kernel@lists.debian.org) (gcc-12 (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #1 SMP PREEMPT_DYNAMIC Debian 6.1.20-2 (2023-04-08) [1.590712] bluetooth hci0: firmware: failed to load intel/ibt-20-1-3.sfi (-2) [1.590724] bluetooth hci0: firmware: failed to load intel/ibt-20-1-3.sfi (-2) [1.590726] Bluetooth: hci0: Failed to load Intel firmware file intel/ibt-20-1-3.sfi (-2) [0.00] Linux version 6.1.0-9-amd64 (debian-kernel@lists.debian.org) (gcc-12 (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #1 SMP PREEMPT_DYNAMIC Debian 6.1.27-1 (2023-05-08) [3.635292] bluetooth hci0: firmware: direct-loading firmware intel/ibt-20-1-3.sfi [3.635294] Bluetooth: hci0: Found device firmware: intel/ibt-20-1-3.sfi I don't know if it is related but when I boot 6.1.0-7, I also see a call trace that starts with [1.554110] alg: self-tests for ecdh-nist-p256 using ecdh-nist-p256-generic failed (rc=-14) [1.554111] [ cut here ] This happens before 6.1.0-7 tries to load intel/ibt-20-1-3.sfi. With 6.1.0-9, that call trace is gone too and loading the firmware file appears to have been moved to a later phase based upon the time stamps. I don't know what fixed it but I'm happy to report this fixed. At least in 6.1.0-9, but I'm slightly worried a later version might reintroduce it as that has happened before. Oh, FYI, I have the following firmware packages installed at the moment # apt list --installed 2>/dev/null | grep firmware firmware-amd-graphics/testing,now 20230210-5 all [installed] firmware-iwlwifi/testing,now 20230210-5 all [installed] firmware-linux-free/unstable,unstable,testing,now 20200122-1 all [installed,automatic] firmware-realtek/testing,now 20230210-5 all [installed] Hope this helps, -- Olaf Meeuwissen
Bug#1017977: Fails to load intel/ibt-20-1-3.sfi
Hi,
Again, unfortunately :-(
Diederik de Haas writes:
> On Sunday, 12 February 2023 03:29:14 CET Olaf Meeuwissen wrote:
>> Olaf Meeuwissen writes:
>> > Just checked again with 6.1.7-1 and still no joy :-(
>>
>> Glad to report joy cold-booting linux-image-6.1.0-3-amd64.
>> Currrently have the following installed
>
> That's great!
Cold booting with 6.1.0-5, I was left without a working keyboard again.
Warm booting back to 6.1.0-3 did NOT give me a working keyboard either.
Repeated cold booting 6.1.0-3 did NOT give me my keyboard back. I don't
know what happened when I was able to report success.
Plugged in my PS/2 keyboard via USB dongle, added
deb [check-valid-until=no]
https://snapshot.debian.org/archive/debian/20221112T151812Z/ sid main
to my APT sources and reinstalled 6.0.0-4. Cold booting that got my
Bluetooth-only keyboard back. Subsequent warm booting 6.1.0-5 left
that keyboard functional.
FTR, this is all using firmware-iwlwifi 20221214-3.
Earlier, in message #34, I reported that upgrading that package fixed
the issue for 6.0.0-4. Checking on packages.debian.org, I see that a
newer version is available for bookworm but that the section has been
renamed. Added that and upgraded which also bumped my other firmware
packages and pulled in the 6.1.0-6 kernel.
The 6.1.0-6 kernel also fails to load the firmware file, leaves me
without a working Bluetooth-only keyboard but warm booting to it (from a
6.0.0-4 cold boot) I can use said keyboard.
>> I checked the changelog but did not find anything obviously related, but
>> maybe one of these upstream stable updates
>>
>> - wifi: iwlwifi: fw: skip PPAG for JF
>> - Bluetooth: hci_sync: Fix use HCI_OP_LE_READ_BUFFER_SIZE_V2
>>
>> fixed it?
>
> I looked into them, but didn't find a direct link. But hopefully the issue is
> fixed now.
>
> If the issue does come back, then I'd suggest doing a `git bisect` between
> v5.18.14 and v5.18.16 as that's where the initial problem surfaced and it also
> has the benefit of being a reasonably small range.
Please note that 6.0.0-4 (package version 6.0.8-1) fixed it but 6.0.0-5
(package v6.0.10-1) broke it again. FTR,
diff -u /boot/config-6.0.0-{4,5}-amd64
--- /boot/config-6.0.0-4-amd642022-11-11 17:36:29.0 +0900
+++ /boot/config-6.0.0-5-amd642022-11-27 00:06:48.0 +0900
@@ -1,6 +1,6 @@
#
# Automatically generated file; DO NOT EDIT.
-# Linux/x86 6.0.8 Kernel Configuration
+# Linux/x86 6.0.10 Kernel Configuration
#
CONFIG_CC_VERSION_TEXT="gcc-12 (Debian 12.2.0-9) 12.2.0"
CONFIG_CC_IS_GCC=y
so we can rule out a configuration change causing the breakage.
> https://wiki.debian.org/DebianKernel/GitBisect has instructions for it.
Thanks for the pointer but that is a bit more work than I currently care
to chew into.
--
Olaf Meeuwissen
Bug#1017977: Fails to load intel/ibt-20-1-3.sfi
Olaf Meeuwissen writes: > Just checked again with 6.1.7-1 and still no joy :-( Glad to report joy cold-booting linux-image-6.1.0-3-amd64. Currrently have the following installed $ dpkg-query -W | grep -E '(linux-image|firmware-iwlwifi)' firmware-iwlwifi 20221214-3 linux-image-6.1.0-2-amd64 6.1.7-1 linux-image-6.1.0-3-amd64 6.1.8-1 linux-image-amd64 6.1.8-1 Cold-booting with linux-image-6.1.0-2-amd64 didn't give me a working keyboard. I checked the changelog but did not find anything obviously related, but maybe one of these upstream stable updates - wifi: iwlwifi: fw: skip PPAG for JF - Bluetooth: hci_sync: Fix use HCI_OP_LE_READ_BUFFER_SIZE_V2 fixed it? Hope this helps, -- Olaf Meeuwissen
Bug#1017977: Fails to load intel/ibt-20-1-3.sfi
Olaf Meeuwissen writes: > I am currently on > > firmware-iwlwifi/testing,now 20221214-3 all [installed] > linux-image-6.0.0-4-amd64/now 6.0.8-1 amd64 [installed,local] > linux-image-6.0.0-6-amd64/now 6.0.12-1 amd64 [installed,local] > linux-image-6.1.0-1-amd64/testing,now 6.1.4-1 amd64 [installed,automatic] > linux-image-amd64/testing,now 6.1.4-1 amd64 [installed,automatic] > > and still experience this issue when "cold" booting (i.e. after > `poweroff`) linux-image-6.1.0.1. Just checked again with 6.1.7-1 and still no joy :-( -- Olaf Meeuwissen
Bug#1017977: Fails to load intel/ibt-20-1-3.sfi
Olaf Meeuwissen writes: > FYI, the situation is unchanged after upgrading > > - firmware-iwlwifi from 20221109-2 to 20221109-4 > - linux-image-6.0.0-5-amd64 from 6.0.10-1 to 6.0.10-2 > - linux-image-amd64 from 6.0.10-1 to 6.0.10-2 I am currently on firmware-iwlwifi/testing,now 20221214-3 all [installed] linux-image-6.0.0-4-amd64/now 6.0.8-1 amd64 [installed,local] linux-image-6.0.0-6-amd64/now 6.0.12-1 amd64 [installed,local] linux-image-6.1.0-1-amd64/testing,now 6.1.4-1 amd64 [installed,automatic] linux-image-amd64/testing,now 6.1.4-1 amd64 [installed,automatic] and still experience this issue when "cold" booting (i.e. after `poweroff`) linux-image-6.1.0.1. In order to use my Bluetooth-only keyboard, I cold boot with 6.0.0-4 so that loading the intel/ibt-20-1-3.sfi firmware file succeeds and then "warm" boot (i.e. `reboot`) into 6.1.0-1 to use the latest kernel. That way I can use that Bluetooth-only keyboard. BTW, in order to select a kernel in the GRUB menu I use an old PS/2 keyboard connected via a PS/2 to USB adapter. P.S.: I have no info on cold booting with 6.0.0-6. Hope this helps, -- Olaf Meeuwissen
Bug#1017977: Fails to load intel/ibt-20-1-3.sfi
Olaf Meeuwissen writes: > Upgrading the firmware-iwlwifi package last week (2022-11-27) from > 20221012-1 to 20221109-2 fixed the issue for linux-image-6.0.0-4-amd64 > 6.0.8-1. The changelog for 20221109-1 mentioned > > * iwlwifi: update firmware files for Intel Bluetooth AX2* > * iwlwifi: Add Intel Wireless AX211 Bluethooth firmware and > configuration (Closes: #1023245) > > which may be related to fixing it for my > > Intel Corporation Wi-Fi 6 AX200 (rev 1a) > > However, upgrading today (2022-12-04) to linux-image-6.0.0-5-amd64 > 6.0.10-1 reintroduced it. > > Cold booting into 6.0.0-4 I have a working Bluetooth-only keyboard. > Rebooting from that into 6.0.0-5 my keyboard remains functional. > Cold booting into 6.0.0-5 my Bluetooth-only keyboard is unresponsive. > > For both 6.0.0-5 boot scenarios, dmesg --level=err includes > > bluetooth hci0: firmware: failed to load intel/ibt-20-1-3.sfi (-2) > > Twice, actually, about 10 microseconds apart. > > For 6.0.0-4 there is no such error message. FYI, the situation is unchanged after upgrading - firmware-iwlwifi from 20221109-2 to 20221109-4 - linux-image-6.0.0-5-amd64 from 6.0.10-1 to 6.0.10-2 - linux-image-amd64 from 6.0.10-1 to 6.0.10-2 Hope this helps, -- Olaf Meeuwissen
Bug#1017977: Fails to load intel/ibt-20-1-3.sfi
Upgrading the firmware-iwlwifi package last week (2022-11-27) from 20221012-1 to 20221109-2 fixed the issue for linux-image-6.0.0-4-amd64 6.0.8-1. The changelog for 20221109-1 mentioned * iwlwifi: update firmware files for Intel Bluetooth AX2* * iwlwifi: Add Intel Wireless AX211 Bluethooth firmware and configuration (Closes: #1023245) which may be related to fixing it for my Intel Corporation Wi-Fi 6 AX200 (rev 1a) However, upgrading today (2022-12-04) to linux-image-6.0.0-5-amd64 6.0.10-1 reintroduced it. Cold booting into 6.0.0-4 I have a working Bluetooth-only keyboard. Rebooting from that into 6.0.0-5 my keyboard remains functional. Cold booting into 6.0.0-5 my Bluetooth-only keyboard is unresponsive. For both 6.0.0-5 boot scenarios, dmesg --level=err includes bluetooth hci0: firmware: failed to load intel/ibt-20-1-3.sfi (-2) Twice, actually, about 10 microseconds apart. For 6.0.0-4 there is no such error message. Hope this helps, -- Olaf Meeuwissen
Bug#1017977: Fails to load intel/ibt-20-1-3.sfi
I just want to add that there has been no improvement in the situation with 6.0.0-3 as well as 6.0.0-4. After a poweroff, I boot 5.18.0-3 (after I connect my PS2 keyboard via a USB dongle so I can navigate the GRUB menu) and then *reboot* to the latest kernel. This way, the firmware file is loaded by 5.18.0-3 and stays in the hardware's memory during the reboot so I get to use that latest kernel with my Bluetooth-only keyboard. Cumbersome, at best. Hope this helps, -- Olaf Meeuwissen
Bug#1017977: Fails to load intel/ibt-20-1-3.sfi
Hi again, Olaf Meeuwissen writes: >> Package: linux-image-5.18.0-4-amd64 >> Severity: important >> >> The intel/ibt-20-1-3.sfi file loads fine on linux-image-5.18.0-3-amd64. >> Used that to report this bug as the failure to load leaves me without a >> working keyboard. It's a bluetooth-only keyboard and it not working at >> all is why I've marked this important. > > I just want to add that this is still an issue with 6.0.0-2. Exact same > symptoms. Keyboard is useless when booting after a poweroff. Booting > into 5.18.0-3 restores keyboard usability. A subsequent *reboot* to the > latest linux-image version, as opposed to a poweroff+boot, leaves the > keyboard in a usable state. Just upgraded 6.0.0-2 from 6.0.3-1 to 6.0.5-1 and firmware-iwlwifi, which provides the intel/ibt-20-1-3.sfi file, from 20210818-1 to 20221012-1. Still no working keyboard after booting following a poweroff. I'm back to booting 5.18.0-3 which loads the file just fine and gives me back my keyboard. -- Olaf Meeuwissen
Bug#1017977: Fails to load intel/ibt-20-1-3.sfi
> Package: linux-image-5.18.0-4-amd64 > Severity: important > > The intel/ibt-20-1-3.sfi file loads fine on linux-image-5.18.0-3-amd64. > Used that to report this bug as the failure to load leaves me without a > working keyboard. It's a bluetooth-only keyboard and it not working at > all is why I've marked this important. I just want to add that this is still an issue with 6.0.0-2. Exact same symptoms. Keyboard is useless when booting after a poweroff. Booting into 5.18.0-3 restores keyboard usability. A subsequent *reboot* to the latest linux-image version, as opposed to a poweroff+boot, leaves the keyboard in a usable state. Hope this helps, -- Olaf Meeuwissen
Bug#847154: linux-image-amd64: Disabling vsyscall interface may break docker run
Ian Campbell writes: > On Tue, 2016-12-06 at 14:17 +, Ben Hutchings wrote: >> >> But perhas we should more explicit in this message, e.g.: >> >> "This breaks (e)glibc 2.13 and earlier, which may still be installed in >> a chroot or container environment based on Debian 7, RHEL/CentOS 6 or >> earlier versions." > > That's a good idea! And is what I actually wanted to achieve because the message as is did not make this "obvious" for me. Sorry for not being clear. @Ian Thanks for the pointers, will have a look. -- Olaf Meeuwissen, LPIC-2 FLOSS Engineer -- EPSON AVASYS CORPORATION Free Software Foundation Associate Member since 2004-01-27 Support Free Software https://my.fsf.org/donate Join the Free Software Foundationhttps://my.fsf.org/join
Bug#847154: linux-image-amd64: Disabling vsyscall interface may break docker run
Package: linux-image-amd64 Version: 4.8+76 Severity: wishlist Dear Maintainer, You may want to add to the NEWS blurb that disabling the old 'virtual syscall' interface can lead to crashes when trying to run a Docker container. With upstream's docker-engine-1.12.3-0~stretch, I see docker run -it --rm centos:6.8 /bin/bash exit with a 139 status (and may leave a core file). Adding a vsyscall=emulate to the kernel parameters fixed this for me. When using the centos:7 image, this problem does not occur. On 4.7.0-1-amd64, both centos:6.8 and centos:7 Docker images work without any problems. Seeing that the centos:7 image works fine, I am inclined to think that this problem may be limited to older Docker images. I have not done any research to back this up, nor do I plan to. -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (990, 'testing'), (500, 'stable-updates'), (500, 'unstable'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.8.0-1-amd64 (SMP w/8 CPU cores) Locale: LANG=en_GB.utf8, LC_CTYPE=ja_JP.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages linux-image-amd64 depends on: ii linux-image-4.8.0-1-amd64 4.8.7-1 linux-image-amd64 recommends no packages. linux-image-amd64 suggests no packages. -- no debconf information Hope this helps, -- Olaf Meeuwissen, LPIC-2 FLOSS Engineer -- EPSON AVASYS CORPORATION Free Software Foundation Associate Member since 2004-01-27 Support Free Software https://my.fsf.org/donate Join the Free Software Foundationhttps://my.fsf.org/join
Bug#815451: initramfs-tools: Fails to install without busybox (Depends vs. Recommends)
Hi Ben, Ben Hutchings writes: > On Fri, 2016-03-04 at 09:03 +0900, Olaf Meeuwissen wrote: > [...] >> The initramfs.conf file says: >> >> > >> > # BUSYBOX: [ y | n ] >> > # >> > # Use busybox if available >> > # >> > >> > BUSYBOX=y >> Something does not make sense unless there is a typo, s/not/now/, in >> Ben's initial comment. >> >> I use the default initramfs.conf since my initial install.I upgrade to >> initramfs-tools 0.123 and stuff breaks.You definitely have a non-clean >> upgrade path here. > > On the contrary, the default initramfs.conf has changed BUSYBOX=y to > BUSYBOX=auto. You chose not to accept that. I don't recall doing so but that might have happened. I don't have any *.dpkg-new lying around anymore. >> I'll fix my initramfs.conf manually but default setups that suddenly can >> no longer create initramfs images is scary at best. >> >> Please make the postinst modify initramfs.conf to disable busybox unless >> available.While at it, also update the comment. > [...] > > I did that too. I grabbed a copy of the latest source and now use the initramfs.conf that is shipped without any trouble. Sorry for the noise, -- Olaf Meeuwissen, LPIC-2 FLOSS Engineer -- EPSON AVASYS CORPORATION Free Software Foundation Associate Member since 2004-01-27 Support Free Software https://my.fsf.org/donate Join the Free Software Foundationhttps://my.fsf.org/join
Bug#815451: initramfs-tools: Fails to install without busybox (Depends vs. Recommends)
Just got bit by this this morning. Ben Hutchings said: > busybox is not required by the default configuration. See the NEWS > file. OK, I check the NEWS file. That says (for 0.121~rc1): > If initramfs-tools is configured to use busybox but it is not > installed, mkinitramfs will now fail. Next I check my /etc/initramfs-tools/initramfs.conf. I have kept my /etc/ in git with etckeeper since the system's initial install. The file has never been changed since the initial install (2014-03-27, network-less standard base install from Debian 7.4.0 netinst CD ISO, initramfs-tools-0.109.1; switched to testing later). The initramfs.conf file says: > # BUSYBOX: [ y | n ] > # > # Use busybox if available > # > > BUSYBOX=y Something does not make sense unless there is a typo, s/not/now/, in Ben's initial comment. I use the default initramfs.conf since my initial install. I upgrade to initramfs-tools 0.123 and stuff breaks. You definitely have a non-clean upgrade path here. I'll fix my initramfs.conf manually but default setups that suddenly can no longer create initramfs images is scary at best. Please make the postinst modify initramfs.conf to disable busybox unless available. While at it, also update the comment. Another option is to really do what that comment says, i.e. fix initramfs-tools to test for busybox at run-time if BUSYBOX=y and act as if BUSYBOX=n when not found. Hope this helps, -- Olaf Meeuwissen, LPIC-2 FLOSS Engineer -- EPSON AVASYS CORPORATION Free Software Foundation Associate Member since 2004-01-27 Support Free Software https://my.fsf.org/donate Join the Free Software Foundationhttps://my.fsf.org/join
Bug#804629: linux-image-amd64: Cannot mount LVM RAID1 file system at boot
Just FYI, this bug is still present with - linux-image-4.2.0-1-amd64 4.2.6-1 - linux-image-4.3.0-1-amd64 4.3.3-5 I've read through the thread and will take my system off LVM RAID1. I have submitted #811033 against lvm2, requesting this to be documented. Hope this helps, -- Olaf Meeuwissen, LPIC-2 FLOSS Engineer -- EPSON AVASYS CORPORATION Free Software Foundation Associate Member since 2004-01-27 Support Free Software https://my.fsf.org/donate Support the Free Software Foundation https://my.fsf.org/join
Bug#804629: linux-image-amd64: Cannot mount LVM RAID1 file system at boot
Package: linux-image-amd64 Version: 4.2+68 Severity: important Dear maintainer(s), I recently put one of my file systems on LVM RAID1. All is fine when I lvconvert or lvcreate the RAID1 mirror on a running kernel. The problem happens when I reboot the system. This happens with: - linux-image-4.2.0-1-amd64 4.2.5-1 - linux-image-4.1.0-2-amd64 4.1.6-1 - linux-image-4.1.0-1-amd64 4.1.3-1 Rebooting with a linux-image-4.0.0-2-amd64 (4.0.8-2) kernel works fine. The LVM RAID1 file system mounts automatically and is fully usable. During the failing boots I see: Setting up LVM Volume Groups... lvmetad is not active yet, using direct activation during sysin it device-mapper: reload ioctl on (253:8) failed: Invalid argument and a little later: fsck.ext4: No such file or directory while trying to open /dev/mapper/helix-srv Possibly non-existent device? Trying to activate the LV after the boot does not work either. # lvchange -ay helix/srv device-mapper: reload iocth on (253:8) failed: Invalid argument In my syslog I see: mdX: invalid bitmap file superblock: bad magic mdX: bitmap file superblock magic: 0401 and mdX: failed to create bitmap (-22) device-mapper: table: 253:8 raid: Fail to run raid araay I have found https://bugzilla.kernel.org/show_bug.cgi?id=100491[1][1] which mentions some of the messages I observe. I do not get the OOPS but it might be related. For the time being I'll stick to 4.0. -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (990, 'testing'), (500, 'testing-updates'), (500, 'stable-updates'), (500, 'unstable'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.0.0-2-amd64 (SMP w/8 CPU cores) Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages linux-image-amd64 depends on: ii linux-image-4.2.0-1-amd64 4.2.5-1 linux-image-amd64 recommends no packages. linux-image-amd64 suggests no packages. -- no debconf information Hope this helps, -- Olaf Meeuwissen, LPIC-2 EPSON FLOSS Engineer -- AVASYS CORPORATION FSF Associate Member #1962 Help support software freedom http://www.fsf.org/jf?referrer=1962
Bug#799226: linux-image-4.1.0-2-amd64: Not able to mount LVM RAID1 file system at boot
) (prog-if 30 [XHCI]) Subsystem: Device [1b5b:8040] Physical Slot: 1 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- Kernel driver in use: xhci_hcd 0f:00.0 VGA compatible controller [0300]: NVIDIA Corporation GT218 [NVS 300] [10de:10d8] (rev a2) (prog-if 00 [VGA controller]) Subsystem: Hewlett-Packard Company Device [103c:0862] Physical Slot: 2 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- Kernel driver in use: nouveau 0f:00.1 Audio device [0403]: NVIDIA Corporation High Definition Audio Controller [10de:0be3] (rev a1) Subsystem: Hewlett-Packard Company Device [103c:0862] Physical Slot: 2 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- Kernel driver in use: snd_hda_intel 1c:00.0 Ethernet controller [0200]: Broadcom Corporation NetXtreme BCM5761 Gigabit Ethernet PCIe [14e4:1681] (rev 10) Subsystem: Broadcom Corporation NetXtreme BCM5761 Gigabit Ethernet PCIe [14e4:1681] Physical Slot: 3 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- Kernel driver in use: tg3 37:05.0 FireWire (IEEE 1394) [0c00]: LSI Corporation FW322/323 [TrueFire] 1394a Controller [11c1:5811] (rev 70) (prog-if 10 [OHCI]) Subsystem: Hewlett-Packard Company Device [103c:130a] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- Kernel driver in use: firewire_ohci 3e:00.0 Host bridge [0600]: Intel Corporation Xeon 5600 Series QuickPath Architecture Generic Non-core Registers [8086:2c70] (rev 02) Subsystem: Hewlett-Packard Company Device [103c:130a] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- pn irqbalance Versions of packages linux-image-4.1.0-2-amd64 suggests: pn debian-kernel-handbook ii grub-pc 2.02~beta2-28 pn linux-doc-4.1 Versions of packages linux-image-4.1.0-2-amd64 is related to: pn firmware-atheros pn firmware-bnx2 pn firmware-bnx2x pn firmware-brcm80211 pn firmware-intelwimax pn firmware-ipw2x00 pn firmware-ivtv pn firmware-iwlwifi pn firmware-libertas pn firmware-linux pn firmware-linux-nonfree pn firmware-myricom pn firmware-netxen pn firmware-qlogic pn firmware-ralink pn firmware-realtek pn xen-hypervisor -- debconf information: linux-image-4.1.0-2-amd64/postinst/depmod-error-initrd-4.1.0-2-amd64: false linux-image-4.1.0-2-amd64/postinst/mips-initrd-4.1.0-2-amd64: linux-image-4.1.0-2-amd64/prerm/removing-running-kernel-4.1.0-2-amd64: true Hope this helps, -- Olaf Meeuwissen, LPIC-2 EPSON FLOSS Engineer -- AVASYS CORPORATION FSF Associate Member #1962 Help support software freedom http://www.fsf.org/jf?referrer=1962[2]
Bug#789913: linux-image-3.16.0-4-amd64: Oopses in nouveau_gpuobj_create
Package: src:linux Version: 3.16.7-ckt11-1 Severity: normal Dear Maintainer, -- Package-specific info: ** Version: Linux version 3.16.0-4-amd64 (debian-kernel@lists.debian.org) (gcc version 4.8.4 (Debian 4.8.4-1) ) #1 SMP Debian 3.16.7-ckt11-1 (2015-05-24) ** Command line: BOOT_IMAGE=/vmlinuz-3.16.0-4-amd64 root=/dev/mapper/helix-root ro quiet cgroup_enable=memory ** Tainted: CI (3072) * Module from drivers/staging has been loaded. * Working around severe firmware bug. ** Kernel log: [5.552781] sound hdaudioC0D0:mono: mono_out=0x0 [5.552782] sound hdaudioC0D0:inputs: [5.552784] sound hdaudioC0D0: Front Mic=0x19 [5.552786] sound hdaudioC0D0: Rear Mic=0x18 [5.552788] sound hdaudioC0D0: Line=0x1a [5.561583] input: HDA Digital PCBeep as /devices/pci:00/:00:1b.0/sound/card0/hdaudioC0D0/input5 [5.562315] input: HDA Intel Front Mic as /devices/pci:00/:00:1b.0/sound/card0/input6 [5.562352] input: HDA Intel Rear Mic as /devices/pci:00/:00:1b.0/sound/card0/input7 [5.562384] input: HDA Intel Line as /devices/pci:00/:00:1b.0/sound/card0/input8 [5.562418] input: HDA Intel Line Out as /devices/pci:00/:00:1b.0/sound/card0/input9 [5.562450] input: HDA Intel Front Headphone as /devices/pci:00/:00:1b.0/sound/card0/input10 [5.703551] [drm] Initialized drm 1.1.0 20060810 [5.803819] ppdev: user-space parallel port driver [5.822169] systemd-udevd[433]: renamed network interface eth1 to rename3 [5.857870] nouveau [ DEVICE][:0f:00.0] BOOT0 : 0x0a8c00b1 [5.857874] nouveau [ DEVICE][:0f:00.0] Chipset: GT218 (NVA8) [5.857876] nouveau [ DEVICE][:0f:00.0] Family : NV50 [5.857923] nouveau [ VBIOS][:0f:00.0] checking PRAMIN for image... [5.927265] nouveau [ VBIOS][:0f:00.0] ... appears to be valid [5.927267] nouveau [ VBIOS][:0f:00.0] using image from PRAMIN [5.927436] nouveau [ VBIOS][:0f:00.0] BIT signature found [5.927439] nouveau [ VBIOS][:0f:00.0] version 70.18.89.00.02 [5.927849] nouveau :0f:00.0: irq 76 for MSI/MSI-X [5.927859] nouveau [ PMC][:0f:00.0] MSI interrupts enabled [5.927890] nouveau [ PFB][:0f:00.0] RAM type: DDR3 [5.927892] nouveau [ PFB][:0f:00.0] RAM size: 512 MiB [5.927893] nouveau [ PFB][:0f:00.0]ZCOMP: 960 tags [5.931440] nouveau [VOLT][:0f:00.0] GPU voltage: 90uv [5.958909] nouveau [ PTHERM][:0f:00.0] FAN control: none / external [5.958916] nouveau [ PTHERM][:0f:00.0] fan management: automatic [5.958919] nouveau [ PTHERM][:0f:00.0] internal sensor: yes [5.958941] nouveau [ CLK][:0f:00.0] 03: core 135 MHz shader 270 MHz memory 135 MHz [5.958945] nouveau [ CLK][:0f:00.0] 07: core 405 MHz shader 810 MHz memory 405 MHz [5.958948] nouveau [ CLK][:0f:00.0] 0f: core 520 MHz shader 1230 MHz memory 790 MHz [5.958967] nouveau [ CLK][:0f:00.0] --: core 405 MHz shader 810 MHz memory 405 MHz [5.959235] [TTM] Zone kernel: Available graphics memory: 12360808 kiB [5.959237] [TTM] Zone dma32: Available graphics memory: 2097152 kiB [5.959238] [TTM] Initializing pool allocator [5.959244] [TTM] Initializing DMA pool allocator [5.959254] nouveau [ DRM] VRAM: 512 MiB [5.959256] nouveau [ DRM] GART: 1048576 MiB [5.959258] nouveau [ DRM] TMDS table version 2.0 [5.959260] nouveau [ DRM] DCB version 4.0 [5.959262] nouveau [ DRM] DCB outp 00: 02000360 [5.959263] nouveau [ DRM] DCB outp 01: 02000362 00020010 [5.959265] nouveau [ DRM] DCB outp 02: 028003a6 0f220010 [5.959267] nouveau [ DRM] DCB outp 03: 01011380 [5.959268] nouveau [ DRM] DCB outp 04: 08011382 00020010 [5.959270] nouveau [ DRM] DCB outp 05: 088113c6 0f220010 [5.959271] nouveau [ DRM] DCB conn 00: 00101064 [5.959273] nouveau [ DRM] DCB conn 01: 00202165 [5.985148] SSE version of gcm_enc/dec engaged. [5.989371] alg: No test for __gcm-aes-aesni (__driver-gcm-aes-aesni) [6.007495] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). [6.007497] [drm] Driver supports precise vblank timestamp query. [6.059339] nouveau [ DRM] MM: using COPY for buffer copies [6.059716] systemd-udevd[427]: renamed network interface eth0 to eth1 [6.063648] iTCO_vendor_support: vendor-support=0 [6.089288] systemd-udevd[433]: renamed network interface eth1 to eth0 [6.140078] iTCO_wdt: Intel TCO WatchDog Timer Driver v1.11 [6.140105] iTCO_wdt: unable to reset NO_REBOOT flag, device disabled by hardware/BIOS [6.161172] nouveau [ DRM] allocated 1600x900 fb: 0x7, bo 880302534c00 [6.161460] fbcon: nouveaufb (fb0) is primary device [6.248913] Console: switching to colour frame buffer device 200x56 [
Bug#586554: initramfs-tools fails to upgrade from 0.96.1 to 0.97
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2010年06月29日 18:33, maximilian attems wrote: FTR, I've attached the hook scripts template. The @...@ stuff is substituted at package build time. hmm I don'T see at a quick look why it failed. but I don't get it'S purpose? why do you want mkinitramfs to clean some file in your statedir? this seems the wrong location to do such The script attempts to prevent unneeded udev rules from getting into the initramfs. At one point iscan shipped a botched udev rules file that could prevent your machine from booting up when included. Ever since we got a bit more careful. The rules files takes care of configuring supported scanner devices. We don't see any reason you would need access to your scanner at the boot stage where an initramfs is used. FWIW, the file in our statedir lists files we don't want to end up in the DESTDIR. also why does it need udev (just a minor nit..)? There is nothing to be done if udev is not installed. Hope this helps, - -- Olaf Meeuwissen, LPIC-2 FLOSS Engineer -- AVASYS CORPORATION FSF Associate Member #1962 Help support software freedom http://www.fsf.org/jf?referrer=1962 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkwqfUMACgkQt5qrxaZLMnIaogCgqo3xL6XMFnJPnSD693pC2AOf jQgAoJu8OhnabDXBdGkwbkDKEGdoitI2 =9e2n -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c2a7d43.7020...@avasys.jp
Bug#586554: initramfs-tools fails to upgrade from 0.96.1 to 0.97
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Image Scan! for Linux upstream maintainer here. Care to point out why iscan is the culprit? I went through the logs but nothing ran a bell. If possible we'd like to get a fix out before squeeze goes stable ;-) - -- Olaf Meeuwissen, LPIC-2 FLOSS Engineer -- AVASYS CORPORATION FSF Associate Member #1962 Help support software freedom http://www.fsf.org/jf?referrer=1962 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkwoWmgACgkQt5qrxaZLMnLnxwCfQKqkpkkMgudcxtjK/LojCVFh BIsAn0L503g77eSxFqQ6Swvy4Jg/Baz1 =xJlH -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c285a68.7030...@avasys.jp
Bug#586554: initramfs-tools fails to upgrade from 0.96.1 to 0.97
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2010年06月28日 17:31, maximilian attems wrote: On Mon, Jun 28, 2010 at 05:16:40PM +0900, Olaf Meeuwissen wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Image Scan! for Linux upstream maintainer here. Care to point out why iscan is the culprit? I went through the logs but nothing ran a bell. you are sending the message to the wrong recipient. we do not maintain that iscan software, nor their initramfs-tools hooks please nag them. # I'd have to nag myself then. I maintain iscan. Let me put the question differently then. What exactly led to the conclusion that iscan's initramfs hooks are the culprit. There is nothing in the log that gives me any clues about why iscan is the culprit. The hook provided by iscan is so trivial (and has worked fine upto at leat 0.94.4) that I don't see what is wrong. - -- Olaf Meeuwissen, LPIC-2 FLOSS Engineer -- AVASYS CORPORATION FSF Associate Member #1962 Help support software freedom http://www.fsf.org/jf?referrer=1962 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkwpKesACgkQt5qrxaZLMnJP3wCgiSBSapcyBZO8E2GVg5qlhdfD dSQAniUBAj9VPxBENNs6T5drJ/gbb9xF =ZEYY -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c2929eb.8020...@avasys.jp
Bug#586554: initramfs-tools fails to upgrade from 0.96.1 to 0.97
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2010?06?29? 07:55, maximilian attems wrote:
On Tue, Jun 29, 2010 at 08:02:03AM +0900, Olaf Meeuwissen wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2010???06???28??? 17:31, maximilian attems wrote:
On Mon, Jun 28, 2010 at 05:16:40PM +0900, Olaf Meeuwissen wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Image Scan! for Linux upstream maintainer here.
Care to point out why iscan is the culprit? I went through the logs but
nothing ran a bell.
you are sending the message to the wrong recipient.
we do not maintain that iscan software, nor their initramfs-tools hooks
please nag them.
# I'd have to nag myself then. I maintain iscan.
Let me put the question differently then. What exactly led to the
conclusion that iscan's initramfs hooks are the culprit.
There is nothing in the log that gives me any clues about why iscan is
the culprit. The hook provided by iscan is so trivial (and has worked
fine upto at leat 0.94.4) that I don't see what is wrong.
I haven't looked at the iscan hook script yet. The difference in
initramfs-tools is that now the hooks are run under errexit and
thus may abort. afair it has been determined that your hook script
fails (mkinitramfs needs to be more explicit about what goes on).
Thanks for the info. I've checked the dash and bash manual pages but
running under errexit seems to be the same as using `set -e`. The hook
provided by iscan has done a `set -e` from the beginning so that can't
be the reason (unless I misunderstood the errexit stuff).
FTR, I've attached the hook scripts template. The @...@ stuff is
substituted at package build time.
Hope this helps,
- --
Olaf Meeuwissen, LPIC-2 FLOSS Engineer -- AVASYS CORPORATION
FSF Associate Member #1962 Help support software freedom
http://www.fsf.org/jf?referrer=1962
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkwpOOIACgkQt5qrxaZLMnKNRgCghiCZgHJZZ1jKzlL8Zmkg+T36
iiMAoI2eRFWZGjdRTCWETdtQU2audlB6
=VZ4p
-END PGP SIGNATURE-
#! /bin/sh
# Copyright (C) 2009 SEIKO EPSON CORPORATION
#
# License: GPLv2+
state_d...@deb_configure_localstatedir@/lib/@DEB_SOURCE_PACKAGE@
set -e
PREREQS=udev
prereqs()
{
echo $PREREQS
}
case $1 in
prereqs)
prereqs
exit 0
;;
esac
. /usr/share/initramfs-tools/hook-functions
test -r $STATE_DIR/clean-files || exit 0
awk '{print $2}' $STATE_DIR/clean-files \
| while read file; do
test -e ${DESTDIR}$file rm -f ${DESTDIR}$file
done
