Bug#663696: ALSA: Internal speakers don't shut up when I plug in a headset on ATI SBx00 Azalia (Intel HDA).
Package: linux-2.6 Version: 3.2.7-1 Severity: normal Dear Maintainer, I recently discovered that my internal speakers don't shut up when I plug in a headset on my laptop (eMachines G640) on ATI SBx00 Azalia (Intel HDA) [1002:4383]. This feature functions well on the same computer under Windows Seven, and DID FUNCTION in the past under Debian/GNU/Linux. I am unfortunate that I think I cannot contribute much to the debugging of this trouble because of two things: - When I first witnessed this problem, I believed it was due to a hardware damage (jack plug) caused my me pulling the cable the wrong way. - Then, when using Windows I realized that the hardware is just fine, it was probably ages since the Linux/ALSA bug first appeared, spannig multiple Linux versions for sure. Feel free to ask me for any test and feedback, however. In hope my report will prove useful. Kind Regards, Valentin QUEQUET -- Package-specific info: ** Version: Linux version 3.2.0-1-amd64 (Debian 3.2.7-1) (debian-kernel@lists.debian.org) (gcc version 4.6.2 (Debian 4.6.2-16) ) #1 SMP Tue Feb 28 15:35:32 UTC 2012 ** Command line: BOOT_IMAGE=/boot/vmlinuz-3.2.0-1-amd64 root=UUID=33f066d5-b48c-457a-ad2b-0df0e19f6c0a ** Not tainted ** Kernel log: [34112.544599] pcieport :00:05.0: restoring config space at offset 0x7 (was 0x1f1, writing 0x21f1) [34112.544604] pcieport :00:05.0: restoring config space at offset 0x3 (was 0x1, writing 0x10008) [34112.544648] ahci :00:11.0: restoring config space at offset 0x1 (was 0x237, writing 0x2300407) [34112.544697] ohci_hcd :00:12.0: wake-up capability disabled by ACPI [34112.560119] ehci_hcd :00:12.2: BAR 0: set to [mem 0xd0506000-0xd05060ff] (PCI address [0xd0506000-0xd05060ff]) [34112.560148] ehci_hcd :00:12.2: restoring config space at offset 0x1 (was 0x2b0, writing 0x2b00013) [34112.560171] ehci_hcd :00:12.2: wake-up capability disabled by ACPI [34112.560175] ehci_hcd :00:12.2: PME# disabled [34112.560202] ohci_hcd :00:13.0: wake-up capability disabled by ACPI [34112.576118] ehci_hcd :00:13.2: BAR 0: set to [mem 0xd0506400-0xd05064ff] (PCI address [0xd0506400-0xd05064ff]) [34112.576147] ehci_hcd :00:13.2: restoring config space at offset 0x1 (was 0x2b0, writing 0x2b00013) [34112.576169] ehci_hcd :00:13.2: wake-up capability disabled by ACPI [34112.576174] ehci_hcd :00:13.2: PME# disabled [34112.576195] pci :00:14.0: restoring config space at offset 0x1 (was 0x2200403, writing 0x223) [34112.576204] pata_atiixp :00:14.1: restoring config space at offset 0xf (was 0x200, writing 0x20a) [34112.576215] pata_atiixp :00:14.1: restoring config space at offset 0x8 (was 0x1, writing 0x8451) [34112.576224] pata_atiixp :00:14.1: restoring config space at offset 0x3 (was 0x0, writing 0x4000) [34112.576230] pata_atiixp :00:14.1: restoring config space at offset 0x1 (was 0x220, writing 0x227) [34112.576258] snd_hda_intel :00:14.2: restoring config space at offset 0x1 (was 0x416, writing 0x412) [34112.576346] radeon :02:00.0: restoring config space at offset 0xf (was 0x1ff, writing 0x105) [34112.576360] radeon :02:00.0: restoring config space at offset 0x3 (was 0x80, writing 0x88) [34112.576398] snd_hda_intel :02:00.1: restoring config space at offset 0xf (was 0x2ff, writing 0x20b) [34112.576412] snd_hda_intel :02:00.1: restoring config space at offset 0x4 (was 0x4, writing 0xd0020004) [34112.576416] snd_hda_intel :02:00.1: restoring config space at offset 0x3 (was 0x80, writing 0x88) [34112.576421] snd_hda_intel :02:00.1: restoring config space at offset 0x1 (was 0x10, writing 0x13) [34112.576500] tg3 :03:00.0: restoring config space at offset 0x3 (was 0x0, writing 0x8) [34112.576506] tg3 :03:00.0: restoring config space at offset 0x1 (was 0x10, writing 0x16) [34112.576550] ath9k :06:00.0: restoring config space at offset 0xf (was 0x1ff, writing 0x10a) [34112.576565] ath9k :06:00.0: restoring config space at offset 0x4 (was 0x4, writing 0xd024) [34112.576570] ath9k :06:00.0: restoring config space at offset 0x3 (was 0x0, writing 0x8) [34112.576576] ath9k :06:00.0: restoring config space at offset 0x1 (was 0x10, writing 0x17) [34112.576701] PM: early resume of devices complete after 32.233 msecs [34112.576890] ohci_hcd :00:12.0: PCI INT A - GSI 18 (level, low) - IRQ 18 [34112.576914] ehci_hcd :00:12.2: PCI INT B - GSI 17 (level, low) - IRQ 17 [34112.576960] ohci_hcd :00:13.0: PCI INT A - GSI 18 (level, low) - IRQ 18 [34112.576972] ehci_hcd :00:13.2: PCI INT B - GSI 17 (level, low) - IRQ 17 [34112.576989] pata_atiixp :00:14.1: PCI INT B - GSI 17 (level, low) - IRQ 17 [34112.577006] snd_hda_intel :00:14.2: PCI INT A - GSI 16 (level, low) - IRQ 16 [34112.577057] radeon :02:00.0: setting latency timer to 64 [34112.577298] snd_hda_intel
Bug#663707: ALSA: Internal speakers don't shut up when I plug in a headset on ATI SBx00 Azalia (Intel HDA).
Package: linux-2.6 Version: 3.2.7-1 Severity: normal Tags: upstream Dear Maintainer, I recently discovered that my internal speakers don't shut up when I plug in a headset on my laptop (eMachines G640) on ATI SBx00 Azalia (Intel HDA) [1002:4383]. This feature functions well on the same computer under Windows Seven, and DID FUNCTION in the past under Debian/GNU/Linux. I am unfortunate that I believe I cannot contribute much to debugging this trouble because of two things: - When I first witnessed this problem, I believed it was due to a hardware damage (jack plug) caused my me pulling the cable the wrong way. - Then, when I realized using Windows that the hardware is just fine, it was probably ages since the Linux bug first appeared, spannig multiple Linux versions for sure. Feel free to ask me for any tests and feedback, however. In hope my report will prove useful. Kind Regards, Valentin QUEQUET -- Package-specific info: ** Version: Linux version 3.2.0-1-amd64 (Debian 3.2.7-1) (debian-kernel@lists.debian.org) (gcc version 4.6.2 (Debian 4.6.2-16) ) #1 SMP Tue Feb 28 15:35:32 UTC 2012 ** Command line: BOOT_IMAGE=/boot/vmlinuz-3.2.0-1-amd64 root=UUID=33f066d5-b48c-457a-ad2b-0df0e19f6c0a ** Not tainted ** Kernel log: [34112.544599] pcieport :00:05.0: restoring config space at offset 0x7 (was 0x1f1, writing 0x21f1) [34112.544604] pcieport :00:05.0: restoring config space at offset 0x3 (was 0x1, writing 0x10008) [34112.544648] ahci :00:11.0: restoring config space at offset 0x1 (was 0x237, writing 0x2300407) [34112.544697] ohci_hcd :00:12.0: wake-up capability disabled by ACPI [34112.560119] ehci_hcd :00:12.2: BAR 0: set to [mem 0xd0506000-0xd05060ff] (PCI address [0xd0506000-0xd05060ff]) [34112.560148] ehci_hcd :00:12.2: restoring config space at offset 0x1 (was 0x2b0, writing 0x2b00013) [34112.560171] ehci_hcd :00:12.2: wake-up capability disabled by ACPI [34112.560175] ehci_hcd :00:12.2: PME# disabled [34112.560202] ohci_hcd :00:13.0: wake-up capability disabled by ACPI [34112.576118] ehci_hcd :00:13.2: BAR 0: set to [mem 0xd0506400-0xd05064ff] (PCI address [0xd0506400-0xd05064ff]) [34112.576147] ehci_hcd :00:13.2: restoring config space at offset 0x1 (was 0x2b0, writing 0x2b00013) [34112.576169] ehci_hcd :00:13.2: wake-up capability disabled by ACPI [34112.576174] ehci_hcd :00:13.2: PME# disabled [34112.576195] pci :00:14.0: restoring config space at offset 0x1 (was 0x2200403, writing 0x223) [34112.576204] pata_atiixp :00:14.1: restoring config space at offset 0xf (was 0x200, writing 0x20a) [34112.576215] pata_atiixp :00:14.1: restoring config space at offset 0x8 (was 0x1, writing 0x8451) [34112.576224] pata_atiixp :00:14.1: restoring config space at offset 0x3 (was 0x0, writing 0x4000) [34112.576230] pata_atiixp :00:14.1: restoring config space at offset 0x1 (was 0x220, writing 0x227) [34112.576258] snd_hda_intel :00:14.2: restoring config space at offset 0x1 (was 0x416, writing 0x412) [34112.576346] radeon :02:00.0: restoring config space at offset 0xf (was 0x1ff, writing 0x105) [34112.576360] radeon :02:00.0: restoring config space at offset 0x3 (was 0x80, writing 0x88) [34112.576398] snd_hda_intel :02:00.1: restoring config space at offset 0xf (was 0x2ff, writing 0x20b) [34112.576412] snd_hda_intel :02:00.1: restoring config space at offset 0x4 (was 0x4, writing 0xd0020004) [34112.576416] snd_hda_intel :02:00.1: restoring config space at offset 0x3 (was 0x80, writing 0x88) [34112.576421] snd_hda_intel :02:00.1: restoring config space at offset 0x1 (was 0x10, writing 0x13) [34112.576500] tg3 :03:00.0: restoring config space at offset 0x3 (was 0x0, writing 0x8) [34112.576506] tg3 :03:00.0: restoring config space at offset 0x1 (was 0x10, writing 0x16) [34112.576550] ath9k :06:00.0: restoring config space at offset 0xf (was 0x1ff, writing 0x10a) [34112.576565] ath9k :06:00.0: restoring config space at offset 0x4 (was 0x4, writing 0xd024) [34112.576570] ath9k :06:00.0: restoring config space at offset 0x3 (was 0x0, writing 0x8) [34112.576576] ath9k :06:00.0: restoring config space at offset 0x1 (was 0x10, writing 0x17) [34112.576701] PM: early resume of devices complete after 32.233 msecs [34112.576890] ohci_hcd :00:12.0: PCI INT A - GSI 18 (level, low) - IRQ 18 [34112.576914] ehci_hcd :00:12.2: PCI INT B - GSI 17 (level, low) - IRQ 17 [34112.576960] ohci_hcd :00:13.0: PCI INT A - GSI 18 (level, low) - IRQ 18 [34112.576972] ehci_hcd :00:13.2: PCI INT B - GSI 17 (level, low) - IRQ 17 [34112.576989] pata_atiixp :00:14.1: PCI INT B - GSI 17 (level, low) - IRQ 17 [34112.577006] snd_hda_intel :00:14.2: PCI INT A - GSI 16 (level, low) - IRQ 16 [34112.577057] radeon :02:00.0: setting latency timer to 64 [34112.577298
Bug#663707: ALSA [SOLVED]: Internal speakers don't shut up when I plug in a headset.
Package: linux-2.6 Followup-For: Bug #663707 Dear Maintainer, First, I would like to thank you for your promptness and your eagerness to help someone else. Using 'alsamixer' the way you showed me, I realized that it was the 'auto-mute' toggle button which was at a fault. Once toggeled, everything functions very fine. I'm not so sorry for the noise, cause this mis-feature is much of a trap, indeed; hope you agree with me. Thanks again, Jonathan. Kind Regards, Valentin QUEQUET -- System Information: Debian Release: wheezy/sid APT prefers experimental APT policy: (2000, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.iso885915, LC_CTYPE=en_US.iso885915 (charmap=ISO-8859-15) Shell: /bin/sh linked to /bin/dash -- 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/20120313152214.32627.8549.reportbug@localhost.localdomain
Bug#663707: ALSA: Internal speakers don't shut up when I plug in a headset [SOLVED].
Package: linux-2.6 Followup-For: Bug #663707 Dear Maintainer, Yeah, besides the fact I failed to follow your commands, I noticed the following: After having set the 'auto-mute' option using alsa-mixer and took fun wih it, I rebooted the machine, and all was just fine : auto-mute still enabled. Do you still need that I remove the '/var/lib/alsa/asound.state' configuration file in between two full boots? I will do, one day, regardless of your answer, but I make no promise for when I will share my progress. Still in contact ... co-Debianer, or not? Deep Thoughts, Valentin QUEQUET -- System Information: Debian Release: wheezy/sid APT prefers experimental APT policy: (2000, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.iso885915, LC_CTYPE=en_US.iso885915 (charmap=ISO-8859-15) Shell: /bin/sh linked to /bin/dash -- 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/20120313205953.13615.52265.reportbug@localhost.localdomain
Bug#586554: Twice the same bug
Package: initramfs-tools Version: 0.97 Severity: normal Hello, I think that bugs #587608 and #586554 are indeed the same ; shouldn't we merge them? Furtermore, only purging initramfs-tools and reinstalling the package solved the problem on my box. Is it really a bug of initramfs-tools or a bug of the install system? By the time someone has initramfs-tools 0.94.4 , he/she should have a COMPRESS=gzip stanza in the configuration file. I appologize for not having seen the bug report #586554 before. Sincerely, Valentin QUEQUET -- Package-specific info: -- initramfs sizes lrwxrwxrwx 1 root root 51 Feb 16 12:09 /boot/initrd.img-2.6.29.4-reiser4-um-custom-0001 - /usr/bin/initrd.img-2.6.29.4-reiser4-um-custom-0001 lrwxrwxrwx 1 root root 79 Feb 16 12:09 /boot/initrd.img-2.6.29.4-reiser4-um-custom-0001.udev_and_cryptsetup_updated - /usr/bin/initrd.img-2.6.29.4-reiser4-um-custom-0001.udev_and_cryptsetup_updated -rw-r--r-- 1 root root 13M Jun 8 18:07 /boot/initrd.img-2.6.32-5-686 -rw-r--r-- 1 root root 13M Jun 8 18:08 /boot/initrd.img-2.6.32-5-686-bigmem -rw-r--r-- 1 root root 14M May 21 02:22 /boot/initrd.img-2.6.33-2-686 -rw-r--r-- 1 root root 14M May 21 02:23 /boot/initrd.img-2.6.33-2-686-bigmem -rw-r--r-- 1 root root 14M May 6 01:43 /boot/initrd.img-2.6.33-3.dmz.2-liquorix-686 -rw-r--r-- 1 root root 14M Feb 19 16:10 /boot/initrd.img-2.6.33-rc8-git1-custom-0001 lrwxrwxrwx 1 root root 45 Feb 16 12:04 /boot/initrd.img-2.6.33-rc8-um-custom-0001 - /usr/bin/initrd.img-2.6.33-rc8-um-custom-0001 -rw-r--r-- 1 root root 15M May 30 10:36 /boot/initrd.img-2.6.34-0.dmz.5-liquorix-686 -rw--- 1 root root 14M Jul 2 10:17 /boot/initrd.img-2.6.34-1-686 -rw-r--r-- 1 root root 46K Jun 30 14:01 /boot/initrd.img-2.6.34-1-686-bigmem.list -rw-r--r-- 1 root root 14M Jun 8 17:46 /boot/initrd.img-2.6.34-1-686-bigmem.previous -rw-r--r-- 1 root root 14M Jun 8 17:46 /boot/initrd.img-2.6.34-1-686-bigmem.previous2 -rw-r--r-- 1 root root 14M Jun 30 14:11 /boot/initrd.img-2.6.34-1-686-bigmem.safe -rw-r--r-- 1 root root 31M Jun 30 13:59 /boot/initrd.img-2.6.34-1-686-bigmem_plain -rw--- 1 root root 14M Jul 1 00:07 /boot/initrd.img-2.6.34-1-686.functional -rw-r--r-- 1 root root 42K Jun 30 14:00 /boot/initrd.img-2.6.34-1-686.list -rw-r--r-- 1 root root 14M Jun 8 17:45 /boot/initrd.img-2.6.34-1-686.previous -rw-r--r-- 1 root root 14M Jun 8 17:45 /boot/initrd.img-2.6.34-1-686.previous2 -rw-r--r-- 1 root root 14M Jun 30 14:10 /boot/initrd.img-2.6.34-1-686.safe -rw-r--r-- 1 root root 31M Jun 30 13:56 /boot/initrd.img-2.6.34-1-686_plain -- /proc/cmdline ro root=/dev/sda7 bootkbd=fr -- resume RESUME=/dev/dm-0 -- /proc/filesystems btrfs reiserfs ext2 fuseblk -- lsmod Module Size Used by radeon538129 2 ttm32433 1 radeon drm_kms_helper 18331 1 radeon drm 112550 5 radeon,ttm,drm_kms_helper i2c_algo_bit3537 1 radeon ipt_ULOG4605 1 x_tables8637 1 ipt_ULOG powernow_k7 3462 0 cpufreq_powersave606 0 cpufreq_stats 1934 0 cpufreq_userspace 1492 0 cpufreq_conservative 6246 0 ppdev 4475 0 lp 5798 0 cn 3677 1 binfmt_misc 4958 1 uinput 4854 1 deflate 1291 0 ctr 2671 0 twofish 5353 0 twofish_common 12668 1 twofish camellia 17361 0 serpent17103 0 blowfish7148 0 cast5 15109 0 des_generic15127 0 xcbc1809 0 rmd160 6208 0 sha512_generic 7245 0 sha1_generic1363 0 hmac2001 0 crypto_null 1864 0 af_key 21731 0 fuse 43631 3 loop 10008 6 ext2 45679 1 mbcache 3840 1 ext2 sha256_generic 9069 4 aes_i5866820 4 aes_generic25758 1 aes_i586 cbc 1967 2 dm_crypt8987 2 snd_ali545111566 0 snd_ac97_codec 76621 1 snd_ali5451 ac97_bus 714 1 snd_ac97_codec snd_pcm_oss27474 0 snd_mixer_oss 10335 1 snd_pcm_oss snd_pcm46860 3 snd_ali5451,snd_ac97_codec,snd_pcm_oss tpm_tis 5469 0 parport_pc 15685 1 parport21194 3 ppdev,lp,parport_pc snd_seq_midi3602 0 tpm 8071 1 tpm_tis ndiswrapper 132238 0 snd_rawmidi12621 1 snd_seq_midi snd_seq_midi_event 3742 1 snd_seq_midi joydev 6840 0 snd_seq34704 2 snd_seq_midi,snd_seq_midi_event snd_timer 12489 2 snd_pcm,snd_seq ac 1636 0
Bug#587608: Sorted out this bug
Package: initramfs-tools Version: 0.97 Severity: normal Hello, Dear Maks, It's a long time since we last talked together. I've sorted out the bug, thought I can't explain why my system was broken in such a way to explose this bug. Please, read on. The only thing I did was to upgrade initramfs-tools from version 0.94.4 to version 0.97 , as the following dpkg.log line shows: 2010-06-30 12:51:11 upgrade initramfs-tools 0.94.4 0.97 All went good, and triggers went right. I made this update the usual way, through aptitude. I've investigated and reached the following conclusion: For some reason, there was no COMPRESS=... stanza in my /etc/initramfs-tools/initramfs.conf configuration file. It is very strange, because I've never ever tried to modify this. Creating an initrd with initramfs-tools 0.94.4 succeeded because this version is resilient to the missing COMPRESS=... stanza. In the contrary, creating an initrd with initramfs-tools 0.97 failed because this version relies on the stanza COMPRESS=... which was missing on my system. That explains why the bug triggered on upgrade from version 0.94.4 to version 0.97 of the initramfs-tools package. Here folows my interpretation of why my system was missing the COMPRESS=... stanza in the initramfs.conf configuration file: Ages ago, I was in need of modifying this coniguration file, just the MODULES=... stanza in fact. I often swapped from MODULES=most to MODULES=dep, and vice versa, because either I had trouble to make lilo boot with large initrds, or I didn't get the good set of modules in to boot. (both happened alternatively) I believe, thought, it is quite some time now, that my initramfs.conf configuration file has returned to a sane state WRT this MODULES=... stanza, because it was monthes ago that I last needed such trickery. It appears very likely that some older version of initramfs-tools didn't have a COMPRESS=... stanza in its configuration file. And for some reason, APT/DPKG messed things up on successive upgrades of initramfs-tools, and did not replace the initramfs.conf configuration file with its updated version. I believe that APT/DPKG didn't warn me that I had a modified local version of the initramfs.conf configuration file. I remember clearly, however, that APT/DPKG warned me that I had a modified update-initramfs.conf configuration file, and I directed it to keep my local version which only differed from the official version by the modified update_initramfs=no stanza, instead of update_initramfs=yes. So, I still can't explain why my initramfs.conf configuration file was still missing the COMPRESS=... stanza. Even more strange is that reportbug warned me that I had a modified update-initramfs.conf file, but didn't talk about my then modified initramfs.conf file either. This missing stanza has survived at least two upgrades of initramfs-tools : from pre- 0.94.4 to 0.94.4 , and from 0.94.4 to 0.97 ; without me being warned, and the bug only triggered when using the 0.97 version because this particular version depends on the COMPRESS variable to be set properly, as I said above. I can't figure out why APT/DPKG didn't warn me that I had a modified local version of initramfs.conf . All that I know is that NOW, APT/DPKG warns me if I modify /etc/initramfs-tools/initramfs.conf before upgrading initramfs-tools from version 0.94.4 to version 0.97 . Note that it is strange that initramfs-tools 0.97 depends on the COMPRESS variable to be set properly in /etc/initramfs-tools/initramfs.conf, while the 0.94.4 version does not, especially that both versions embed a COMPRESS=gzip stanza. That's all. In hope my report will prove useful. Sincerely, Valentin QUEQUET -- Package-specific info: -- initramfs sizes lrwxrwxrwx 1 root root 51 Feb 16 12:09 /boot/initrd.img-2.6.29.4-reiser4-um-custom-0001 - /usr/bin/initrd.img-2.6.29.4-reiser4-um-custom-0001 lrwxrwxrwx 1 root root 79 Feb 16 12:09 /boot/initrd.img-2.6.29.4-reiser4-um-custom-0001.udev_and_cryptsetup_updated - /usr/bin/initrd.img-2.6.29.4-reiser4-um-custom-0001.udev_and_cryptsetup_updated -rw-r--r-- 1 root root 13M Jun 8 18:07 /boot/initrd.img-2.6.32-5-686 -rw-r--r-- 1 root root 13M Jun 8 18:08 /boot/initrd.img-2.6.32-5-686-bigmem -rw-r--r-- 1 root root 14M May 21 02:22 /boot/initrd.img-2.6.33-2-686 -rw-r--r-- 1 root root 14M May 21 02:23 /boot/initrd.img-2.6.33-2-686-bigmem -rw-r--r-- 1 root root 14M May 6 01:43 /boot/initrd.img-2.6.33-3.dmz.2-liquorix-686 -rw-r--r-- 1 root root 14M Feb 19 16:10 /boot/initrd.img-2.6.33-rc8-git1-custom-0001 lrwxrwxrwx 1 root root 45 Feb 16 12:04 /boot/initrd.img-2.6.33-rc8-um-custom-0001 - /usr/bin/initrd.img-2.6.33-rc8-um-custom-0001 -rw-r--r-- 1 root root 15M May 30 10:36 /boot/initrd.img-2.6.34-0.dmz.5-liquorix-686 -rw--- 1 root root 14M Jul 2 10:17 /boot/initrd.img-2.6.34-1-686 -rw-r--r-- 1 root root 46K Jun 30 14:01 /boot/initrd.img-2.6.34-1-686-bigmem.list -rw-r--r-- 1 root root 14M Jun 8 17:46 /boot/initrd.img-2.6.34-1-686
Bug#519040: linux-headers-2.6.28-1-686: depends on linux-kbuild but not available
Hello, the hurd, davide wrote : [...] svn co svn://svn.debian.org/kernel/dists/trunk/linux-kbuild-2.6 Then, fetch the vanilla kernel tarball (important: the 2.6.x version, no 2.6.x.y version): wget http://ftp.de.kernel.org/pub/linux/kernel/v2.6/linux-2.6.27.tar.bz2 Now, you can prepare the package: cd linux-kbuild-2.6 ./debian/bin/genorig.py ../linux-2.6.27.tar.bz2 cd .. tar xzf orig/linux-kbuild-2.6_2.6.27.orig.tar.gz cd linux-kbuild-2.6-2.6.27/ cp -a ../linux-kbuild-2.6/* ./ ./debian/bin/gencontrol.py dch -i Now adjust the version, and add a comment like New upstream version or something, and build the package itself, after you installed eventually missing build-dependencies: SORRY, but what do you mean by : Now adjust the version, and add a comment ... Imagine today I want to generate and build package linux-kbuild-2.6.28 ; then, what shall I do to reach this goal, since the source I've downloaded from svn are linux-kbuild-2.6.29~rc5 - related ? make -f debian/rules clean dpkg-checkbuilddeps dpkg-buildpackage -us -uc and you are done. End of quote. If you try it, can you please drop a line to this bug? I would need the same stuff and haven't tryed yet (not enough time) Regards, me. Regards, another me. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#513835: linux-image-2.6.26-1-xen-686: xen kernel fails at recognizing keyboard and at ACPI handling
Package: linux-image-2.6.26-1-xen-686 Version: 2.6.26-13 Severity: normal Hello the hurd, Preambule: I stick with Xen Dom0 for now. The only kernel I don't run on the bare hardware is linux-image-2.6.26-1-xen-686 which is then paravirtualized with Xen. That is I don't attempt to run any kernel through Xen HVM. My problem: With linux-image-2.6.26-1-xen-686 I experience a similar bug as with linux-image-2.6.26-1-openvz-686 ; see my previous bug report: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=513095 That is, not only my keyboard seems dead (with not even SysReq keys functionning), but, likewise, my touchpad seems dead too. It behaves like both (keyboard and touchpad) were not power supplied. Note that I don't have those problems with linux-image-2.6.26-1-686 or linux-image-2.6.26-1-vserver-686 ; don't you think it's strange ? This might be a 'false bug' since Xen is known not to support ACPI. However it is embarrassing if keyboard and touchpad functions depend effectively on proper OS-Side ACPI initialisation while the keyboard can be used seamlessly to tell the boot loader what to boot. In hope my report will prove useful. Sincerely, Valentin QUEQUET -- System Information: Debian Release: 5.0 APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.26-1-686 (SMP w/1 CPU core) Locale: lang=fr...@euro, lc_ctype=fr...@euro (charmap=ISO-8859-15) Shell: /bin/sh linked to /bin/bash Versions of packages linux-image-2.6.26-1-xen-686 depends on: hi initramfs-tools 0.92o tools for generating an initramfs ii linux-modules-2.6.26-1-xen-68 2.6.26-13 Linux 2.6.26 modules on i686 Versions of packages linux-image-2.6.26-1-xen-686 recommends: ii libc6-xen 2.7-18 GNU C Library: Shared libraries [X Versions of packages linux-image-2.6.26-1-xen-686 suggests: hi grub 0.97-47lenny2 GRand Unified Bootloader (Legacy v hi linux-doc-2.6.26 2.6.26-13 Linux kernel specific documentatio -- no debconf information -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#495533: initramfs-tools: vdjxngdgh
maximilian attems wrote: On Mon, Aug 18, 2008 at 01:13:21PM +0200, Valentin QUEQUET wrote: Package: initramfs-tools Version: 0.92e Severity: normal Hello all, I witnessed this trouble with initramfs-tools 0.92f : Boot process freezes on 'Activating swap:' message. Instead, all is fine with previous initramfs-tools version = 0.92e . Under 0.92e, I can see the message : 'Activating swap: swapon on /dev/sda3' In hope my report will prove useful. please reinstall 0.92f and try to reproduce. tried to boot the newest linux image? also please nuke any splash package that might interfer. Hello all, I'm very sorry indeed cause I realize that I might have made some mistakes. Now I have re-upgraded initramfs-tools from version 0.92e to version 0.92f, I see all function normally; the bug I had, and which I thought was caused by upgrade from 0.92e to 0.92f, disappeared! I couldn't stress that enough: I'm very sorry for the disappointment and for the fear of a bug in initramfs-tools I may have spread. Nota: The duplicate bug report (under #495534) was just there to correct the weird title and replace vdjxngdgh with Boot process freezes on 'Activating swap:' message. in hope the corrected version would have been favored for further processing. With plenty of excuses, Valentin QUEQUET -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#495533: initramfs-tools: vdjxngdgh
Package: initramfs-tools Version: 0.92e Severity: normal Subject: initramfs-tools: Boot process freezes on 'Activating swap:' message. Package: initramfs-tools Version: 0.92f Severity: normal Hello all, I witnessed this trouble with initramfs-tools 0.92f : Boot process freezes on 'Activating swap:' message. Instead, all is fine with previous initramfs-tools version = 0.92e . Under 0.92e, I can see the message : 'Activating swap: swapon on /dev/sda3' In hope my report will prove useful. Sincerely, Valentin QUEQUET -- Package-specific info: -- /proc/cmdline BOOT_IMAGE=241EnHk6 root=1642 -- /proc/filesystems reiserfs fuseblk vfat -- lsmod Module Size Used by binfmt_misc11336 1 nvidia 7100100 24 agpgart31912 1 nvidia rfcomm 36912 2 l2cap 22976 9 rfcomm bluetooth 53956 4 rfcomm,l2cap nfsd 204432 13 lockd 60968 2 nfsd nfs_acl 3584 1 nfsd auth_rpcgss39904 1 nfsd sunrpc171484 9 nfsd,lockd,nfs_acl,auth_rpcgss exportfs4832 1 nfsd kvm_amd16524 0 kvm79572 1 kvm_amd ppdev 8900 0 parport_pc 26340 0 lp 11204 0 parport34472 3 ppdev,parport_pc,lp video 18832 0 output 3840 1 video ac 6212 0 battery13700 0 powernow_k814400 1 cpufreq_powersave 1920 0 cpufreq_stats 5248 0 cpufreq_userspace 4388 0 cpufreq_ondemand8620 1 cpufreq_conservative 7688 0 freq_table 4544 3 powernow_k8,cpufreq_stats,cpufreq_ondemand ipv6 242212 28 nls_iso8859_1 4224 1 nls_cp437 5888 1 vfat 12384 1 fat48924 1 vfat dm_crypt 13348 0 pppoatm 5760 0 ppp_generic26388 1 pppoatm slhc6144 1 ppp_generic speedtch 16132 0 firmware_class 9472 1 speedtch usbatm 18592 1 speedtch fuse 45332 3 cryptoloop 3264 0 sha512 9152 0 loop 16996 3 cryptoloop snd_hda_intel 274848 3 snd_pcm_oss38368 0 snd_mixer_oss 15424 3 snd_pcm_oss snd_pcm72036 2 snd_hda_intel,snd_pcm_oss snd_timer 21348 1 snd_pcm snd48772 7 snd_hda_intel,snd_pcm_oss,snd_mixer_oss,snd_pcm,snd_timer rtc_cmos8384 0 rtc_core 18152 1 rtc_cmos i2c_nforce2 6528 0 soundcore 7680 3 snd button 8528 0 rtc_lib 3104 1 rtc_core i2c_core 22656 2 nvidia,i2c_nforce2 snd_page_alloc 10184 2 snd_hda_intel,snd_pcm evdev 11200 3 k8temp 5632 0 pcspkr 3264 0 reiserfs 210848 2 dm_mirror 21792 0 dm_snapshot17060 0 dm_mod 56004 3 dm_crypt,dm_mirror,dm_snapshot raid10 22368 0 raid456 122128 0 async_xor 2816 1 raid456 async_memcpy2080 1 raid456 async_tx2656 1 raid456 xor14472 2 raid456,async_xor raid1 22336 0 raid0 7936 0 multipath 8384 0 linear 5856 0 md_mod 73652 6 raid10,raid456,raid1,raid0,multipath,linear ide_disk 15776 2 ide_cd 36352 0 cdrom 32672 1 ide_cd sd_mod 27296 4 usbhid 28032 0 hid34400 1 usbhid usb_storage77632 0 generic 4484 0 [permanent] amd74xx 8816 0 [permanent] ide_core 108740 4 ide_disk,ide_cd,generic,amd74xx floppy 54724 0 forcedeth 47052 0 sata_nv25224 3 ata_generic 7556 0 ohci1394 30192 0 ieee1394 85112 1 ohci1394 ehci_hcd 32556 0 libata144560 2 sata_nv,ata_generic scsi_mod 141516 3 sd_mod,usb_storage,libata ohci_hcd 22212 0 usbcore 127724 7 speedtch,usbatm,usbhid,usb_storage,ehci_hcd,ohci_hcd thermal16092 0 processor 36840 2 powernow_k8,thermal fan 4868 0 -- /etc/kernel-img.conf # Kernel Image management overrides # See kernel-img.conf(5) for details do_symlinks = No -- /etc/initramfs-tools/initramfs.conf MODULES=dep BUSYBOX=y KEYMAP=n BOOT=local DEVICE=eth0 NFSROOT=auto -- /etc/crypttab # target device source device key file options
Bug#495534: Boot process freezes on 'Activating swap:' message.
Subject: initramfs-tools: Boot process freezes on 'Activating swap:' message. Package: initramfs-tools Version: 0.92f Severity: normal *** Please type your report below this line *** Hello all, I witnessed this trouble with initramfs-tools 0.92f : Boot process freezes on 'Activating swap:' message. Instead, all is fine with previous initramfs-tools version = 0.92e . Under 0.92e, I can see the message : 'Activating swap: swapon on /dev/sda3' In hope my report will prove useful. Sincerely, Valentin QUEQUET -- Package-specific info: -- /proc/cmdline BOOT_IMAGE=241EnHk6 root=1642 -- /proc/filesystems reiserfs fuseblk vfat -- lsmod Module Size Used by binfmt_misc11336 1 nvidia 7100100 24 agpgart31912 1 nvidia rfcomm 36912 2 l2cap 22976 9 rfcomm bluetooth 53956 4 rfcomm,l2cap nfsd 204432 13 lockd 60968 2 nfsd nfs_acl 3584 1 nfsd auth_rpcgss39904 1 nfsd sunrpc171484 9 nfsd,lockd,nfs_acl,auth_rpcgss exportfs4832 1 nfsd kvm_amd16524 0 kvm79572 1 kvm_amd ppdev 8900 0 parport_pc 26340 0 lp 11204 0 parport34472 3 ppdev,parport_pc,lp video 18832 0 output 3840 1 video ac 6212 0 battery13700 0 powernow_k814400 1 cpufreq_powersave 1920 0 cpufreq_stats 5248 0 cpufreq_userspace 4388 0 cpufreq_ondemand8620 1 cpufreq_conservative 7688 0 freq_table 4544 3 powernow_k8,cpufreq_stats,cpufreq_ondemand ipv6 242212 28 nls_iso8859_1 4224 1 nls_cp437 5888 1 vfat 12384 1 fat48924 1 vfat dm_crypt 13348 0 pppoatm 5760 0 ppp_generic26388 1 pppoatm slhc6144 1 ppp_generic speedtch 16132 0 firmware_class 9472 1 speedtch usbatm 18592 1 speedtch fuse 45332 3 cryptoloop 3264 0 sha512 9152 0 loop 16996 3 cryptoloop snd_hda_intel 274848 3 snd_pcm_oss38368 0 snd_mixer_oss 15424 3 snd_pcm_oss snd_pcm72036 2 snd_hda_intel,snd_pcm_oss snd_timer 21348 1 snd_pcm snd48772 7 snd_hda_intel,snd_pcm_oss,snd_mixer_oss,snd_pcm,snd_timer rtc_cmos8384 0 rtc_core 18152 1 rtc_cmos i2c_nforce2 6528 0 soundcore 7680 3 snd button 8528 0 rtc_lib 3104 1 rtc_core i2c_core 22656 2 nvidia,i2c_nforce2 snd_page_alloc 10184 2 snd_hda_intel,snd_pcm evdev 11200 3 k8temp 5632 0 pcspkr 3264 0 reiserfs 210848 2 dm_mirror 21792 0 dm_snapshot17060 0 dm_mod 56004 3 dm_crypt,dm_mirror,dm_snapshot raid10 22368 0 raid456 122128 0 async_xor 2816 1 raid456 async_memcpy2080 1 raid456 async_tx2656 1 raid456 xor14472 2 raid456,async_xor raid1 22336 0 raid0 7936 0 multipath 8384 0 linear 5856 0 md_mod 73652 6 raid10,raid456,raid1,raid0,multipath,linear ide_disk 15776 2 ide_cd 36352 0 cdrom 32672 1 ide_cd sd_mod 27296 4 usbhid 28032 0 hid34400 1 usbhid usb_storage77632 0 generic 4484 0 [permanent] amd74xx 8816 0 [permanent] ide_core 108740 4 ide_disk,ide_cd,generic,amd74xx floppy 54724 0 forcedeth 47052 0 sata_nv25224 3 ata_generic 7556 0 ohci1394 30192 0 ieee1394 85112 1 ohci1394 ehci_hcd 32556 0 libata144560 2 sata_nv,ata_generic scsi_mod 141516 3 sd_mod,usb_storage,libata ohci_hcd 22212 0 usbcore 127724 7 speedtch,usbatm,usbhid,usb_storage,ehci_hcd,ohci_hcd thermal16092 0 processor 36840 2 powernow_k8,thermal fan 4868 0 -- /etc/kernel-img.conf # Kernel Image management overrides # See kernel-img.conf(5) for details do_symlinks = No -- /etc/initramfs-tools/initramfs.conf MODULES=dep BUSYBOX=y KEYMAP=n BOOT=local DEVICE=eth0 NFSROOT=auto -- /etc/crypttab # target device source device key file options -- /sys/block
Bug#487725: linux-image-2.6.25-2-amd64: Got much trouble and message 'ehci_hcd: HC died' when scanning image from 'Canon PIXMA MP150'.
ok so time to notify upstream, please file the corresponding info in bugzilla.kernel.org saying that it is not a regression but with the oops output. lspci might help too. My report against this bug (#487725) remains unchanged. (Kernel NOT Tainted) I'm so sorry. please tell us the upstream bug number so we can mark it appropriately then. Hello, Maks and other Linux' enthusiasts. I tested with Pristine Linux 2.6.26-rc8 with debugging/logging facilities ; got the same as with Debian-packaged -rc8 I reported the bug upstream as Bug #10997 which can be shown at: http://bugzilla.kernel.org/show_bug.cgi?id=10997 I also updated things on my WEB site (more log files, .config, ...): http://pagesperso-orange.fr/mandolosse/ Have a nice W.E. regards Valentin QUEQUET -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#487725: linux-image-2.6.25-2-amd64: Got much trouble and message 'ehci_hcd: HC died' when scanning image from 'Canon PIXMA MP150'.
urrgs indeed. but please can you test out latest upstream linux images 2.6.26-rcX they install just fine in testing/unstable. see trunk apt lines - http://wiki.debian.org/DebianKernel kind regards Hi, Maks and other Linux' enthusiasts. I would like to thank you for the suggestion to use the latest Release Candidate of (Debian-Packaged-)Linux 2.6.26 (2.6.26~rc7-1~experimental.1~snapshot.11693 by the time of my writing) ; but I'm afraid I still have bad news for you :-( My report against this bug (#487725) remains unchanged. (Kernel NOT Tainted) I'm so sorry. Least but not last: I still experience bug #427421 (The FAMOUS Linux/LILO/initRD case) with kernel 2.6.26~rc7-1~experimental.1~snapshot.11693 :-( Help this report will prove useful. Yours, sincerely. Valentin QUEQUET -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#487725: linux-image-2.6.25-2-amd64: Got much trouble and message 'ehci_hcd: HC died' when scanning image from 'Canon PIXMA MP150'.
Package: linux-image-2.6.25-2-amd64 Version: 2.6.25-5 Severity: normal Hello, all. While scanning (with SANE) a document from my 'Canon PIXMA MP150' scanner/printer combo, I stumbled upon a grave problem. I discovered that my configuration - out-of-the-box up-to-date lenny - was using module 'ehci_hcd' (possibly amongst others) to dialog with my scanner. And I discovered that there was some activity on IRQ_7, which was 'listened-to' by module 'ehci_hcd', when I queried scanner list typing: scanimage -L and when I put my scanner ON or OFF. I was able to query this list 3 times without a problem ; this step did no hurt. But a grave problem suddenly arose when I typed: scanimage -T which is a scanner/communication test which consist in scanning a full line - equivalent to effectively scanning a small part of the document. Not only the test failed, but 3 more very bad things happened: - I got alarming messages on console (and in 'dmesg' below) : ehci_hdc: ... HC died, and kernel said it would forget about IRQ_7 (which 'ehci_hcd' was 'listening-to' earlier). - I became unable to query the list of scanners anymore : the scanner ceased to respond. - The kernel no longer notified (eg on console) when I put my scanner OFF, ON, and OFF again. Fortunately, I discovered that in this situation, I had just to unload module 'ehci_hcd' to get my scanner+SANE functional (including scanner power ON/OFF notifications). But a few points draw my attention: I retried this scenario, implying scanner OFF, PC reboot, delay, scanner ON. A few times the scenario showed to be exactly like I described above. While the other times, symptoms of the bug (alarming messages + unability to communicate with the scanner) happened merely whenever I chose to put my scanner OFF (alarm) and ON (no comm.) instead of doing the scanner test (via scanimage -T). Again, unloading module 'ehci_hcd' got my scanner+SANE functional. I found very strange that IRQ_7 would just be used for some handchecking and not for the transfer phase. But it's obvious: 'ehci_hcd', which was the sole user of IRQ_7, succeeded at handchecking and broke on scanning/transfer attempts. So, when I unloaded 'ehci_hcd', the transfer phase likely falled back to some non-IRQ (polling) method. I was sorry that my new Debian pre-packaged linux-image-2.6.25-2-amd64 (ver 2.6.25-5) made my scanning experience so tricky. And I asked myself what it would have been if module 'echi_hcd' didn't broke. Would 'ehci_hcd' be usefull after all ? Would IRQ_7 be used ? With many interruptions in scanning/transfer phase ? And would transfers get faster ? So, I decided to repeat the whole thing with Debian pre-packaged linux-image-2.6.24-1-amd64 (ver 2.6.24-7). You can't believe it ! Scanning (scanner+SANE) functioned right out of the box, without having root to unload module 'ehci_hcd' (it was effectively loaded). And I was witnessing an intensive use of IRQ_7 by module 'ehci_hcd' ; transfers were similar than with 2.6.25 : certainly no far from perfect. And whenever I put my scanner ON or OFF, I got the matching notifications on console and in dmesg. And whenever I wanted to scan some paper, all was good and perfect. To help you understand what happened, and in the case the piece of dmesg below would not be enough, I give you a pointer to my full dmesg log: http://pagesperso-orange.fr/mandolosse/logs/2008-06-23__dmesg__ehci_hcd__died.txt I also captured 'scanimage', 'lsmod' output and snapshots of '/proc/interrupts' at different times. I plan to scrutinize all this data, to comment the relevant parts and to post them later. In hope my report will prove useful. Sincerely, Valentin QUEQUET -- Package-specific info: ** Version: Linux version 2.6.25-2-amd64 (Debian 2.6.25-5) ([EMAIL PROTECTED]) (gcc version 4.1.3 20080420 (prerelease) (Debian 4.1.2-22)) #1 SMP Thu Jun 12 15:38:32 UTC 2008 ** Command line: BOOT_IMAGE=252k8c ro root=1641 acpi=off bootkbd=fr ** Not tainted ** Kernel log: [ 26.186050] sd 4:0:0:0: [sdb] Attached SCSI removable disk [ 26.226053] sd 4:0:0:1: [sdc] Attached SCSI removable disk [ 26.235133] sd 4:0:0:2: [sdd] Attached SCSI removable disk [ 26.257114] sd 4:0:0:3: [sde] Attached SCSI removable disk [ 28.474762] loop: AES key scrubbing enabled [ 28.474762] loop: loaded (max 8 devices) [ 84.509321] fuse init (API version 7.9) [ 84.649334] ReiserFS: hdd2: found reiserfs format 3.6 with standard journal [ 84.649334] ReiserFS: hdd2: using ordered data mode [ 84.649334] ReiserFS: hdd2: journal params: device hdd2, size 8125, journal first block 66, max trans len 256, max batch 225, max commit age 30, max trans age 30 [ 84.650872] ReiserFS: hdd2: checking transaction log (hdd2) [ 84.709413] ReiserFS: hdd2: Using r5 hash to sort names [ 84.927097] NTFS driver 2.1.29 [Flags: R/W MODULE]. [ 84.996773] NTFS volume version 3.1. [ 84.996819] NTFS-fs warning (device sda1): load_system_files
Bug#487421: Early boot-time kernel panic with linux-image-2.6.25-2-amd64 (2.6.25-5).
Hello, Maks and others. before jumping to strange conlcusions. this looks very much like a dup. did you set MODULES=dep *and* regenerated the initramfs with update-initramfs -u -k kernelversion *and* tried to boot that. You're right, Maks, i_DID a mistake ! I'm not even able to describe what I did, but when I looked-at my 'MODULES=dep' - see 3) below - initrd I realized how ugly it was ; it really contained evil things ! Strangely enough, my 'customized-dep' - see 4) below - initrd version was completely fine !!! If I didn't have made this mistake, I would have saved a few hours guessing which few modules I had to add to this base. Now - a few dozens minutes ago - I've rebuilt my 4 different versions of initrd for linux-image-2.6.25-2-amd64 (ver 2.6.25-5) : 1) The default one (= Simply with MODULES=most) 2) A custom gently stripped-down version of the previous one 3) The 'dep' one (= Simply with MODULES=dep) 4) A (now useless) custom slighlty enhanced version of the previous one And LILO knows them all very well ;-) I've tried them all in order: 1) and 2) lead to an early kernel panic 3) and 4) are all fine wrt all one can expect from an initrd. Now, that matter boils down to tree cases: 1) Linux has a problem with large initrd files. 2) LILO has a problem with large initrd files. 3) BOTH have a problem with large initrd files. I know a snake who bites its tail ... And now let's see my initrd sizes: 1) 7275892 bytes 2) 5738810 bytes 3) 3485038 bytes 4) 3686321 bytes Note: vmlinuz is 1727488 bytes But I can boot linux-image-2.6.24-1-amd64 (ver 2.6.24-7) without any problem and using an initrd of 7090895 bytes, and vmlinuz is 1668248 bytes. So, why had I an early kernel panic with version 2) (see above) of my initrd for linux-image-2.6.25-2-amd64 (ver 2.6.25-5) which is smaller ? In hope my report will prove useful. I'm looking forward to hearing from you. Sincerely, Valentin QUEQUET -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#487421: Early boot-time kernel panic with linux-image-2.6.25-2-amd64 (2.6.25-5).
Hello, Maks and others. Package: linux-image-2.6.25-2-amd64 Version: 2.6.25-5 Severity: grave Justification: renders package unusable learn to set severities, not working on *one* box is not grave Really, I apologize, if not too late ;-) But I've been influenced in this choice by some other thread. It would have been *nice* if you gave me a pointer to learn more about that. Furthermore, I don't think this problem is sporadic or even endemic to Compaq Presario SR1917FR boxes. Instead, I think either the kernel or LILO (or both) is unpredictable (= buggy) over a wide range of combinations of hardware and filesystems ( /boot ; I use reiserfs3 withOUT 'notail' option, which I may change later, but I'm fine with my boot (and root) partition in all other cases. ). read http://wiki.debian.org/InitramfsDebug and provide info based on that. I must agree that I didn't say that I had already read the page at http://wiki.debian.org/InitramfsDebug but I DID SO indeed. And parameter rootdelay=9 (i.e. an arbitrary delay of 9 seconds) did NOT HELP ; this option really is for LVM and networked filesystems. Furthermore, I can hardly provide useful info based on http://wiki.debian.org/InitramfsDebug because : either - I boot with a complete initial RAM disk image and the kernel hangs, loading no file (init, shell, ...) from within the RAM disk. or - I boot with a manually pruned initial RAM disk image and the kernel does well, though I MUST break startup process at some point (i.e. break=premount) to get a console, because my custom initRD is missing some modules (I'm working on adding just the modules I need). Thus, one cannot think it's just that the kernel might not detect the good filesystem type of the initial RAM disk image. It's clear that the problem is more complex, and I bet it is a Kernel+LILO problem (like in the mythology of the Babel Tower). I'm looking forward to hearing from you. Sincerely, Valentin QUEQUET -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#487421: Early boot-time kernel panic with linux-image-2.6.25-2-amd64 (2.6.25-5).
... and finally I'm hearing from myself ! Hello, Maks and others. Because of some experiments with kernel 2.6.24-1 (always functional) I got a rough idea of the modules I would really have to put in the initrd (with respect to my hardware BIOS) for kernel 2.6.25-2 (ver 2.6.25-5) which I was not able to boot my system with. (c.f. my previous post.) Hoollaoup*! I'm writing this e-mail under my now-functional kernel 2.6.25-2 (ver 2.6.25-5) -running system. * I don't know the english world - if it exist - to convey such an intense joy ;-) Now, though, I very much fear this kernel (2.6.25-2 ver 2.6.25-5) be broken and would endanger my - not so valuable - data (filesystems). I say that because having read the following thread: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=485464 One can read that Arno Griffioen reported such corruptions with kernel in linux-image-2.6.25-2-amd64 (which version?). Then you, Maks, answered him to try out latest 2.6.26-rc5 (there is some 2.6.26-rc6~... snapshot now). You now see why I fear what I fear. So, I decide to always run 2.6.25-2 (ver 2.6.25-5) ; that will serve as a testcase (though not exhaustive wrt hardware usage patterns). If you can't hear from me in the following 1-2 year(s) that would mean that kernel 2.6.25-2 (ver 2.6.25-5) crunched my whole system, all my partitions ( Including M$ Windaube eXPrès ;-) ). Said that, I still find the imputability of guilt, in the Linux_Kernel/LILO/Initial_RAM_Disk case, be a moot point. To your opinion, who's guilty ? I don't necessarily want to make the case against Linux_Kernel overflated ;-) I'm looking forward to hearing from you. Sincerely, Valentin QUEQUET -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#487421: Early boot-time kernel panic with linux-image-2.6.25-2-amd64 (2.6.25-5).
Package: linux-image-2.6.25-2-amd64
Version: 2.6.25-5
Severity: grave
Justification: renders package unusable
Hello all,
I experience early boot-time kernel panic with linux-image-2.6.25-2-amd64
(2.6.25-5)
on my amd64 box.
After having read tons of posts on forums, and particularly:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=482773
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=479101
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=479607
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=479607#96
I know that the bug I discovered is closely related to already reported bug
#479607
which apparently concerns lilo because:
The bug - kernel panic - happens just before any piece of userspace code being
loaded from initial RAM disk :
===
RAMDISK: Couldn't find valid RAM disk image starting at 0.
List of all partitions :
010065536ram0 (driver?)
..
..
..
010f65536ram15 (driver?)
No filesystem could mount root, tried:
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(22,65)
===
But I have to add food for thought:
Here follow key files on my Debian_amd64 system:
ls -l /boot gave: ( cropped the list to meaningful parts )
-rw-r--r-- 1 root root 6621847 jun 21 11:19 initrd.img-2.6.18-6-amd64
-rw--- 1 root root 7090895 jun 21 09:40 initrd.img-2.6.24-1-amd64
-rw-r--r-- 1 root root 7276007 jun 21 11:41 initrd.img-2.6.25-2-amd64
-rw-r--r-- 1 root root 21132800 jun 21 18:03 initrd.img-2.6.25-2-amd64.cpio
-rw-r--r-- 1 root root 5598429 jun 21 18:06 initrd.img-2.6.25-2-amd64_light
-rw-r--r-- 1 root root 16109056 jun 21 18:12
initrd.img-2.6.25-2-amd64_light.cpio
-rw-r--r-- 1 root root 1512362 jun 6 09:20 vmlinuz-2.6.18-6-amd64
-rw-r--r-- 1 root root 1668248 mai 10 11:32 vmlinuz-2.6.24-1-amd64
-rw-r--r-- 1 root root 1727488 jun 12 18:35 vmlinuz-2.6.25-2-amd64
ls -l /boot/initrd.img-2.6.*amd64{,_light}{,.cpio} gave: ( cropped the list to
meaningful parts )
/boot/initrd.img-2.6.18-6-amd64:gzip compressed data, from Unix,
last modified: Sat Jun 21 11:19:01 2008
/boot/initrd.img-2.6.24-1-amd64:gzip compressed data, from Unix,
last modified: Sat Jun 21 09:40:50 2008
/boot/initrd.img-2.6.25-2-amd64:gzip compressed data, from Unix,
last modified: Sat Jun 21 11:41:17 2008
/boot/initrd.img-2.6.25-2-amd64.cpio: ASCII cpio archive (SVR4 with no
CRC)
/boot/initrd.img-2.6.25-2-amd64_light: gzip compressed data, from Unix,
last modified: Sat Jun 21 18:06:31 2008, max compression
/boot/initrd.img-2.6.25-2-amd64_light.cpio: ASCII cpio archive (SVR4 with no
CRC)
WHERE initrd.img-2.6.25-2-amd64_light is a manually lightened customization of
the
original initrd.
Finally, since I only experience trouble - very early kernel panic - with
2.6.25-2-amd64
regardless wether my initrd is heavy or not, how do you explain this strange
behavior ?
In hope my report will prove useful.
Sincerely,
Valentin QUEQUET
-- Package-specific info:
-- System Information:
Debian Release: lenny/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.24-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages linux-image-2.6.25-2-amd64 depends on:
ii debconf [debconf-2.0] 1.5.22 Debian configuration management sy
ii initramfs-tools [linux-initra 0.92b tools for generating an initramfs
ii module-init-tools 3.4-1 tools for managing Linux kernel mo
linux-image-2.6.25-2-amd64 recommends no packages.
-- debconf information:
linux-image-2.6.25-2-amd64/preinst/abort-overwrite-2.6.25-2-amd64:
linux-image-2.6.25-2-amd64/postinst/create-kimage-link-2.6.25-2-amd64: true
linux-image-2.6.25-2-amd64/preinst/failed-to-move-modules-2.6.25-2-amd64:
linux-image-2.6.25-2-amd64/postinst/depmod-error-2.6.25-2-amd64: false
linux-image-2.6.25-2-amd64/postinst/bootloader-test-error-2.6.25-2-amd64:
linux-image-2.6.25-2-amd64/prerm/would-invalidate-boot-loader-2.6.25-2-amd64:
true
linux-image-2.6.25-2-amd64/postinst/old-dir-initrd-link-2.6.25-2-amd64: true
linux-image-2.6.25-2-amd64/preinst/lilo-has-ramdisk:
linux-image-2.6.25-2-amd64/preinst/bootloader-initrd-2.6.25-2-amd64: true
shared/kernel-image/really-run-bootloader: true
linux-image-2.6.25-2-amd64/prerm/removing-running-kernel-2.6.25-2-amd64: true
linux-image-2.6.25-2-amd64/postinst/old-initrd-link-2.6.25-2-amd64: true
linux-image-2.6.25-2-amd64/preinst/abort-install-2.6.25-2-amd64:
linux-image-2.6.25-2-amd64/postinst/kimage-is-a-directory:
linux-image-2.6.25-2-amd64/postinst/old-system-map-link-2.6.25-2-amd64: true
linux-image-2.6.25-2-amd64/preinst/overwriting-modules-2.6.25-2-amd64: true
linux-image-2.6.25-2-amd64/postinst/depmod-error-initrd-2.6.25-2-amd64: false
linux-image-2.6.25-2-amd64/preinst/elilo
Lack of overall understanding.
Hi all. I'm very disappointed, indded. For so long I'm browsing web sites such as http://www.debian.org/, http://www.kernel.org/ + LKML, and http://wiki.debian.org/ in order to grasp the process by which Debian Kernel maintainers customize pristine Linux kernels. So far, I haven't yet found any set of coherent documentation pieces. Is there a policy out there that decribes the goals of Linux kernel customization bu Debian kernel maintainers? Is there a comprehensive documentation which deals with technical mecha nisms they use to achieve their goals? I would be VERY grateful if someone would afford to give me hints (pointers) about existing documentation [if any], or otherwise would get involved - WITH ME ( [EMAIL PROTECTED] ) - to collect the necessary information bits to compile them together to help anybody else (including newbies) to grasp HOW DO Debian CUSTOMIZE [pristine] Linux KERNEL. I just throw a bottle into the sea. In hope someone catch it... Sincerely, Valentin QUEQUET -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#468839: linux-source-2.6.24: A make-kpkg build of Linux 2.6.24 generates an unusable headers package (i.e. : not suitable for m-a).
Package: linux-source-2.6.24 Version: 2.6.24-4 Severity: important Hello, the hurd. Here again! But this time I do have precise facts and I have PARTLY troubleshooted the problem myself. I've noticed that a make-kpkg build of Linux 2.6.24 generates an unusable headers package (i.e. : not suitable for module-assistant). This surprising behavior did not happen with Linux 2.6.22 , using the same procedure to generate the kernel image, headers and external modules. With more details, here are the 2 facts relevant to any further external module build with module-assistant (only for 2.6.24): 1) Really, installing the generated headers package is not enough. 2) It shows necessary to keep the kernel build directory in-place too. I cannot stress less: This surprising behavior did not happen with Linux 2.6.22 ... Hope this report will prove useful. I'm looking forward to hearing from you. Sincerely, Valentin QUEQUET -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.24-tuned-toi (SMP w/2 CPU cores; PREEMPT) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/bash Versions of packages linux-source-2.6.24 depends on: ii binutils2.18.1~cvs20080103-1 The GNU assembler, linker and bina ii bzip2 1.0.4-3 high-quality block-sorting file co Versions of packages linux-source-2.6.24 recommends: ii gcc 4:4.2.2-2 The GNU C compiler ii libc6-dev [libc-dev] 2.7-6 GNU C Library: Development Librari ii make 3.81-3 The GNU version of the make util -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#468492: linux-source-2.6.24: Building linux 2.6.24 with make-kpkg breaks further external modules compilation with module-assistant.
Package: linux-source-2.6.24 Version: 2.6.24-4 Severity: normal Hello, the hurd. The facts I'm trying to depict here might be conveyed somehow inprecisely and, as such, might render this bug report not as useful or not as clear, straightforward, than expected. The reason why I still want to inform you about the troubles I stuck upon is that I recall different use cases where not all was so dark, and I really think the following depiction, which I'll try to keep consice, will prove useful. In the following, the external modules I'm interested in ( 'my' external modules ) refer to: lzma squashfs aufs loop-aes nvidia-kernel[proprietary] (+ other less useful to me) And I always tried to build them with further invokation of module-assistant, instead of the --added-modules option of make-kpkg . Here are the facts: - My 1st intent was to build a 2.6.24 kernel with the TuxOnIce patch applied. - I did so. - I was unable to compile 'my' external modules. - It run well but: - I had a very disturbed and unREADable console. (mixed-up with initial framebuffer mode and [usplash?] splash screen). - Xorg X server didn't start because I had it configured to use nvidia-kernel module which failed to compile. - Then, I built several 'customizations' of kernel: - 2.6.22 , 2.6.24 unpatched , 2.6.24 patched with TuxOnIce - Several times with more or less hardware support and more or less 'software concepts' support (network QoS, ...). What I got is: - I had no problem with kernel 2.6.22 : - As far as I remember, 'my' external modules always compiled. - These modules always ended in /usr/src . - I'm sure it is not a requirement to keep the 2.6.22 kernel build directory (and contents) to manage to build 'my' external modules. Just need to install the make-kpkg -generated kernel headers package. - I OFTEN got problems with kernel 2.6.24 : - I believe I at least 1 time managed to compile 'my' external modules for 2.6.24 kernel. - I am sure that at least 1 time the resulting external modules packages generated by module-assistant went into the same directory where make-kpkg put my kernel image and kernel headers packages, instead of /usr/src like as usual, and I'm almost certain it was with 2.6.24 kernel. - Most often (always?), I was unable to build 'my' external modules for kernel 2.6.24. - I've just made the assumption that it would have been a requirement to keep the 2.6.24 kernel build directory (and contents) to manage to build 'my' external modules but, because I was so eager to recover disk space, I didn't do it or I did it the 1 time this compilation succeed. How about you? - How did you manage do provide pre-packaged external modules? (aufs, squashfs, ...) - Did you use the --added-modules option of make-kpkg to 'ship' these modules, instead of further module-assistant invokation (I always used m-a)? Help this report will prove useful. Sincerely, Valentin QUEQUET -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.24-1-686 (SMP w/2 CPU cores) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/bash Versions of packages linux-source-2.6.24 depends on: hi binutils2.18.1~cvs20080103-1 The GNU assembler, linker and bina hi bzip2 1.0.4-3 high-quality block-sorting file co Versions of packages linux-source-2.6.24 recommends: hi gcc 4:4.2.2-2 The GNU C compiler hi libc6-dev [libc-dev] 2.7-6 GNU C Library: Development Librari hi make 3.81-3 The GNU version of the make util -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
