Bug#567468: (boot time consequences of) Linux mdadm superblock question.
On Sun, Feb 21, 2010 at 11:06 PM, Goswin von Brederlow goswin-...@web.de wrote: martin f krafft madd...@madduck.net writes: also sprach Daniel Reurich dan...@centurion.net.nz [2010.02.19.0351 +0100]: But if a generated 'system uuid' value (I just suggested the root fs UUID because it would be highly unlikely to be unchanged, and nobody would be likely to fiddle with it) was copied into a file called /etc/system_uuid and copied into the initrd, then we could add put into mdadms hook script in initramfs-tools, to verify and update the homehost variable in the boot time required raid volumes when ever a new initrd is installed. (This generally happens on debian whenever a kernel is installed and mdadm is installed or upgraded. Neil's point is that no such value exists. The root filesystem UUID is not available when the array is created. And updating the homehost in the RAID metadata at boot time would defeat the purpose of homehost in the first place. As an added protection we could include checks in mdadm shutdown script a check that warns when mdadm.conf doesn't exist and the /etc/system_uuid doesn't match the homehost value in the boottime assembled raid volumes. If we did use the root filesystem UUID for this, we could compare that as well. Debian has no policy for this. There is no way to warn a user and interrupt the shutdown process. It would be useful to have a tool similar to /bin/hostname that could be used to create|read|verify|update the system uuid, which would update all the relevant locations which store and check against this system uuid. Yes, it would be useful to have a system UUID that could be generated by the installer and henceforth written to the newly installed system. This is probably something the LSB should push. But you could also bring it up for discussion on debian-devel. How would that work with network boot where the initrd would have to work for multiple hosts? MfG Goswin -- To unsubscribe from this list: send the line unsubscribe linux-raid in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html I don't know how whatever was mentioned previously would work for that, but I do have a solution. Incremental assembly, or examine with all block devices to generate a new mdadm.conf file. Then run only devices which are in a complete state. The next step would be not mount by uuid, but mount by label. Presuming you have a consistently labeled rootfs in your deployment (say mandating that the / filesystem be labeled 'root' or some other value and that no other FS may share that same label) then it should work out just fine. -- 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/4877c76c1002212337i36f208dcyd1be7a93625d...@mail.gmail.com
Bug#570350: linux-image-2.6.26-2-amd64: kernel BUG at kernel/exit.c:822!
Ben Hutchings wrote: On Thu, 2010-02-18 at 09:33 +, Berni Elbourn wrote: Package: linux-2.6 Version: 2.6.26-21lenny3 Severity: normal This may relate to #542115. This system kernel is new (HP ML115) and most definitely not tainted with ndiswrappers or nvidia. I am logging the report just prior to repooting. System seems stable enough. This could be pretty grim for an multiuser Xserver which I was planning to upgrade to Lenny from Etch tomorrow. This is a kernel bug but it appears to be triggered specifically by Chrome. I'm trying to find out just what Chrome does to trigger it. Ben. Huge thanks Ben, This kernel in testing does seem to be immune: Linux version 2.6.32-trunk-amd64 (Debian 2.6.32-5) (b...@decadent.org.uk) (gcc version 4.3.4 (Debian 4.3.4-6) ) #1 SMP Sun Jan 10 22:40:40 UTC 2010 Berni -- 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/4b823e41.4080...@elbournb.fsnet.co.uk
Bug#541317: Built-in microphone doesn't produce any sound with linux-image-2.6.30-1-amd64
Moritz Muehlenhoff wrote: On Thu, Aug 13, 2009 at 05:46:51PM +0800, Jos van Wolput wrote: Package: linux-image-2.6.30-1-amd64_2.6.30-5snapshot.14079_amd64.deb System: Debian/Sid, AMD64 Hardware: Acer Travelmate 4530 AMD Athlon 64 X2 dual-core Severity: normal When using linux-image-2.6.30-1-amd64 the built-in microphone doesn't produce any sound, this seems to be a regression for it works with linux-image-2.6.29-2-amd64. lspci -v: Audio device: ATI Technologies Inc SBx00 Azalia (Intel HDA) Subsystem: Acer Incorporated [ALI] Device 0147 Flags: bus master, slow devsel, latency 64, IRQ 16 Memory at f060 (64-bit, non-prefetchable) [size=16K] Capabilities: [50] Power Management version 2 Kernel driver in use: HDA Intel Hi, The next release of Debian (6.0, code name Squeeze) will be based on 2.6.32. Please test the current 2.6.32 from unstable/testing and tell us whether the problem persists. If so, we should report it upstream to the kernel.org developers. The 2.6.32 kernel is available from packages.debian.org and can be installed in both Debian stable, testing and unstable installations. Thanks, Moritz System: Debian/Sid, linux-image-2.6.32-2-amd64 (2.6.32-8) Hardware: Acer Travelmate 4530 AMD Athlon 64 X2 dual-core I tested both the built-in and the external microphone using audacity. Both mics work. This bug can now be closed. -- 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/4b8243a8.3030...@onsneteindhoven.nl
Bug#567468: (boot time consequences of) Linux mdadm superblock question.
also sprach Goswin von Brederlow goswin-...@web.de [2010.02.22.0806 +0100]: Yes, it would be useful to have a system UUID that could be generated by the installer and henceforth written to the newly installed system. This is probably something the LSB should push. But you could also bring it up for discussion on debian-devel. How would that work with network boot where the initrd would have to work for multiple hosts? Right now, that doesn't work either, except with the traditional method of simply assembling all arrays found. Neil has implemented the homehost feature to prevent that. Arguably that's to protect against a circumstance that is rather rare, and one might not want/need it. However, if used, then it is true: Unless the homehost in the superblock matches the local value, you need mdadm.conf to assemble the devices, because the superblock information won't be trusted if the homehost doesn't match. To be able to determine whether the homehost matches, you need to know the value for the system after the initramfs was unpacked. Therefore, the homehost value must either be stored in the initramfs, which makes it non-portable, or we must use a unique identifier of the system that is available from ROM, e.g. the CPU ID. I don't think that's standardised. If auto-assembly of all RAIDs bears dangers and must be regulated, then we must either have host-specific initramfs's, or be able to determine the homehost value early during boot otherwise. -- .''`. martin f. krafft madd...@d.o Related projects: : :' : proud Debian developer http://debiansystem.info `. `'` http://people.debian.org/~madduckhttp://vcs-pkg.org `- Debian - when you have better things to do than fixing systems digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/)
Bug#567468: (boot time consequences of) Linux mdadm superblock question.
also sprach Michael Evans mjevans1...@gmail.com [2010.02.22.0837 +0100]: I don't know how whatever was mentioned previously would work for that, but I do have a solution. […] Incremental assembly, or examine with all block devices to generate a new mdadm.conf file. Please see the thread for reasons why incremental assembly works only with an mdadm.conf file, or if you can uniquely identify the system before the root filesystem is mounted. Please see the thread for reasons why unconditional auto-assembly of all available arrays may not be desirable. Presuming you have a consistently labeled rootfs in your deployment (say mandating that the / filesystem be labeled 'root' or some other value and that no other FS may share that same label) then it should work out just fine. I fundamentally agree. However, driving this change from mdadm will be impossible. If that is the way to go, then we must first ensure that device names become deprecated, and that everyone uses /dev/disk/by-uuid/*. Only then can we start relying on it. -- .''`. martin f. krafft madd...@d.o Related projects: : :' : proud Debian developer http://debiansystem.info `. `'` http://people.debian.org/~madduckhttp://vcs-pkg.org `- Debian - when you have better things to do than fixing systems digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/)
Bug#567468: md homehost (was: Bug#567468: (boot time consequences of) Linux mdadm superblock) question.
also sprach Piergiorgio Sartor piergiorgio.sar...@nexgo.de [2010.02.21.2113 +0100]: I do not see how the homehost plays a role, here. Neil, Could you please put forth the argument for why the homehost must match, and why unconditional auto-assembly is not desirable? Realistically, what problems are we protecting against? Thanks, -- martin | http://madduck.net/ | http://two.sentenc.es/ fitter, healthier, more productive like a pig, in a cage, on antibiotics -- radiohead spamtraps: madduck.bo...@madduck.net digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/)
Processed: Re: Bug#570417: xserver-xorg: xserver freeze after I close my laptop lid
Processing commands for cont...@bugs.debian.org: reassign 570417 linux-2.6 2.6.32-5 Bug #570417 [xserver-xorg] xserver-xorg: xserver freeze after I close my laptop lid Bug reassigned from package 'xserver-xorg' to 'linux-2.6'. Bug No longer marked as found in versions xorg/1:7.5+3. Bug #570417 [linux-2.6] xserver-xorg: xserver freeze after I close my laptop lid There is no source info for the package 'linux-2.6' at version '2.6.32-5' with architecture '' Unable to make a source version for version '2.6.32-5' Bug Marked as found in versions 2.6.32-5. tags 570417 +fixed-upstream Bug #570417 [linux-2.6] xserver-xorg: xserver freeze after I close my laptop lid Added tag(s) fixed-upstream. thank you Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- 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/handler.s.c.126683235631329.transcr...@bugs.debian.org
Bug#570517: no resume
OK got it now. Installed it and rebooted but still no resume from suspend to ram. -- Mike Sumner -- 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/op.u8iyfstqv46...@vaio-debian
Bug#544709: linux-image-2.6.30-1-686: /proc/acpi/button/lid/*/state always says open
On Fri, 19 Feb 2010, Josue Abarca wrote: On Sat, Feb 13, 2010 at 12:41:17PM +0100, maximilian attems wrote: can you reproduce with 2.6.32 ? Yes, I can. Using linux-image-2.6.32-2-686 2.6.32-8 :( please post output of: cat /proc/acpi/video/*/DOS also please check if you have hotkey-setup installed, if it is installed, please nuke it and reboot. your box seems newer as 8xx where this state can not be trusted at all: http://patchwork.kernel.org/patch/78947/ thanks again for your feedback. -- 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/20100222103401.ga5...@stro.at
Bug#567468: (boot time consequences of) Linux mdadm superblock question.
On Mon, 2010-02-22 at 10:11 +0100, martin f krafft wrote: also sprach Goswin von Brederlow goswin-...@web.de [2010.02.22.0806 +0100]: Yes, it would be useful to have a system UUID that could be generated by the installer and henceforth written to the newly installed system. This is probably something the LSB should push. But you could also bring it up for discussion on debian-devel. How would that work with network boot where the initrd would have to work for multiple hosts? Right now, that doesn't work either, except with the traditional method of simply assembling all arrays found. Neil has implemented the homehost feature to prevent that. Arguably that's to protect against a circumstance that is rather rare, and one might not want/need it. However, if used, then it is true: Unless the homehost in the superblock matches the local value, you need mdadm.conf to assemble the devices, because the superblock information won't be trusted if the homehost doesn't match. To be able to determine whether the homehost matches, you need to know the value for the system after the initramfs was unpacked. Therefore, the homehost value must either be stored in the initramfs, which makes it non-portable, or we must use a unique identifier of the system that is available from ROM, e.g. the CPU ID. I don't think that's standardised. Actually, in this case one could use the dhcp assigned hostname or boot network cards mac address to provide the homehost search string. -- Daniel Reurich. Centurion Computer Technology (2005) Ltd Mobile 021 797 722 -- 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/1266835342.24834.333.ca...@localhost.localdomain
Bug#560389: linux-image-2.6.32-trunk-686: [drm:i915_gem_madvise_ioctl] error and screen flickering
On Sa, Feb 13, 2010 at 15:44:39 +0100, maximilian attems wrote: On Thu, 10 Dec 2009, Dirk Griesbach wrote: Package: linux-2.6 Version: 2.6.32-1 Severity: normal With 2.6.32-1 dmesg throws the following error on a laptop with Intel 945GM integrated graphics and enabled kms every once in a while: | [drm:i915_gem_madvise_ioctl] *ERROR* Attempted i915_gem_madvise_ioctl() on a pinned object Additionally random screen flicker occurs. can you reprodue this with latest version 2.6.32-8 ?? Yes it's still present. The message error on pinned object is displayed every time I shut down xdm. But I can't remember if this was the case in December too. As far as I remember, there the message appeared more often and not only during shut down of the X server. On the other hand, screen flickering and blanking has gone since I disabled power saving of i915. And as far as I know it has been disabled in latest version of 2.6.32 ex factory because of this. Regards, Dirk -- 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/20100222102356.ga2...@freenet.de
Bug#567468: md homehost (was: Bug#567468: (boot time consequences of) Linux mdadm superblock) question.
Could you please put forth the argument for why the homehost must match, and why unconditional auto-assembly is not desirable? Realistically, what problems are we protecting against? I can think of one or two. In the case of network boot, where the kernel and initrd served up via tftp, but the required filesystems are per host raid volumes served up ala ATAoverEthernet, iSCSI etc storage network. This could use the boot network device MAC or dhcp assigned hostname to as the homehost search paramater. This would of course require someway to tell mdadm how to obtain this homehost parameter. This could work well where different groups of hosts using different raid volumes for the root (or other) filesystems, each with a MAC group (first 3 or 4 MAC fields) is used to identify that groups homehost search parameter. Another scenario, is a dual boot system that has separate raid volumes for the respective root filesystems, along with a separate initrd image for each OS. A system uuid stored in the initrd would work in this case for the homehost search parameter. -- Daniel Reurich. Centurion Computer Technology (2005) Ltd Mobile 021 797 722 -- 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/1266837111.24834.365.ca...@localhost.localdomain
Bug#570364: Output LVDS gone on Intel Mobile 915GM
On Sun, 2010-02-21 at 15:15 +0100, Stefan Ott wrote: Hi! On Sat, Feb 20, 2010 at 22:20, Ben Hutchings b...@decadent.org.uk wrote: On Thu, 2010-02-18 at 21:11 +0100, Stefan Ott wrote: Please test the current version, 2.6.32-8, which has many fixes for the i915 video driver. Thanks, I tried but I still get the same result (dmesg attached) Unfortunately the log you sent stops before the i915 driver is active. You will need to let the X server start (or attempt to start) before sending the log. However, I think this bug may be the same as http://bugs.debian.org/569314, which we have a fix for. You can build amd test a kernel with this fix by following the instructions at http://kernel-handbook.alioth.debian.org/ch-common-tasks.html#s-common-official-vcs. Use the distribution codename 'sid'. Okay, I tried that but I still get the same problem, that is, unless I boot with i915.modeset=0 (as mentioned in the other bug report). dmesg outputs are available if you think they're relevant. Please report this upstream at http://bugzilla.freedesktop.org, under product 'DRI', component 'DRM/Intel'. Attach the log 'dmesg.2.6.32-3-686' and the corresponding X server log. Ben. -- Ben Hutchings 73.46% of all statistics are made up. signature.asc Description: This is a digitally signed message part
Bug#497392: e1000e driver does not initialize correctly
I can confirm the same behaviour on 6 Dell's desktop computer, with Intel Corporation 82562V-2 10/100 Network Connection Ethernet card embeded in the motherboard. First we thougth it was because of wires or old-switch, but now everythings fine, we reproduce the sames problems : - dhcp doesn't bring up, with tcpdump silent - modprobe e1000e/ -r e1000e make it works - plug / unplug card/or/switch/or/power of switch $ sudo lspci | grep 8256 00:19.0 Ethernet controller: Intel Corporation 82562V-2 10/100 Network Connection (rev 02) $ sudo lsmod |grep e1 e1000e 84612 0 $ sudo cat /etc/issue Debian GNU/Linux 5.0 \n \l $ uname -a Linux formaxo2 2.6.26-2-686 #1 SMP Sun Jun 21 04:57:38 UTC 2009 i686 GNU/Linux $ sudo modinfo e1000e filename: /lib/modules/2.6.26-2-686/kernel/drivers/net/e1000e/e1000e.ko version:0.3.3.3-k2 license:GPL description:Intel(R) PRO/1000 Network Driver author: Intel Corporation, linux.n...@intel.com srcversion: 91473E7675870049C25134A ... $ sudo aptitude search ~i~n^linux i A linux-headers-2.6-486- Header files for Linux 2.6-486 i A linux-headers-2.6.26-2-486 - Header files for Linux 2.6.26-2-486 i linux-headers-2.6.26-2-686 - Header files for Linux 2.6.26-2-686 i A linux-headers-2.6.26-2-common- Common header files for Linux 2.6.26-2 i linux-image-2.6-686 - image du noyau Linux version 2.6 pour PPro/Celeron/PII/PII i A linux-image-2.6.26-2-486 - Linux 2.6.26 image on x86 i A linux-image-2.6.26-2-686 - Linux 2.6.26 image on PPro/Celeron/PII/PIII/P4 i A linux-kbuild-2.6.26 - Kbuild infrastructure for Linux 2.6.26 i A linux-libc-dev - Linux support headers for userspace development i A linux-sound-base - Paquet de base pour les systèmes de son ALSA et OSS ... $ ls -l /lib/modules/2.6.*/kernel/drivers/net/e1000e/e1000e.ko -rw-r--r-- 1 root root 111371 fév 10 13:25 /lib/modules/2.6.26-2-486/kernel/drivers/net/e1000e/e1000e.ko -rw-r--r-- 1 root root 112627 fév 10 13:26 /lib/modules/2.6.26-2-686/kernel/drivers/net/e1000e/e1000e.ko -- Jérôme Avond j.av...@axolys.fr Axolys, Société de services en logiciels libres -- 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/1266840825.8630.15.ca...@jay1
Bug#550562: [fwd] [Bug 14535] Memory corruption detected in low memory
Ben, any chance you could try the kernel branch Dave points to in the message below? Thanks, Julien - Forwarded message from bugzilla-dae...@bugzilla.kernel.org - From: bugzilla-dae...@bugzilla.kernel.org Date: Sun, 21 Feb 2010 19:55:47 GMT To: dri-de...@lists.sourceforge.net Subject: [Bug 14535] Memory corruption detected in low memory http://bugzilla.kernel.org/show_bug.cgi?id=14535 --- Comment #20 from Dave Airlie airl...@linux.ie 2010-02-21 19:55:41 --- I've tried to reproduce this locally and haven't had any luck using Fedora running in user mode setting. It would help if someone could try with an old kernel and see it still happens. Alternatively can someone test this with git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git drm-radeon-testing We haven't touched the non-kms radeon driver much, the only thing that seems to be happening is mesa is getting better at creating fully used command buffers and the kernel has gotten worse at giving out large kmallocs (64k), there are fixes for this in drm-radeon-testing to avoid the larger mallocs which will hopefully help in some way, I'll see if I can spot a codepath where we send crap to the GPU, but we currently test the offsets userspace gives us and validate them for crap to avoid just this. -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. - End forwarded message - -- 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/20100222133637.gl2...@patate.is-a-geek.org
Bug#528362: linux-image-2.6.32-trunk-686: Bug still on 2.6.32-5
Package: linux-2.6 Version: 2.6.32-5 Followup-For: Bug #528362 It is strange that now it is capable of reconnect on eth0 but connection is alive only for some seconds. Then it looses connection and tries again. I was doing ping while this happened and it was like ping: 0.175 8181 9071 ... 12453 0.187 and again. I'll try to save the trace next time and report it at bugzilla. If it loses its ip address (dhclient asks for a new one) then no answer is obtained and I can not reconnect again. rmmod r8169 mii and modprobe r8169 have no success at all. Maybe the most strange thing is that network monitor (when this happened) showed that there was a lot of incoming packets but no outcoming packets. And the most awful thing is that it only happens while I am reading emails with thunderbird ... maybe I should change to another email client :-( Sorry for bothering u ... Regards, Victor -- Package-specific info: ** Version: Linux version 2.6.32-trunk-686 (Debian 2.6.32-5) (b...@decadent.org.uk) (gcc version 4.3.4 (Debian 4.3.4-6) ) #1 SMP Sun Jan 10 06:32:16 UTC 2010 ** Command line: root=/dev/sda1 ro quiet ** Tainted: W (512) * Taint on warning. ** Kernel log: [7.233100] pcmcia_socket pcmcia_socket0: cs: IO port probe 0x5000-0x5fff: clean. [7.233391] yenta_cardbus :06:04.0: pcmcia: parent PCI bridge Memory window: 0xdc00 - 0xdc0f [7.233394] yenta_cardbus :06:04.0: pcmcia: parent PCI bridge Memory window: 0x4000 - 0x43ff [7.805449] iwl3945 :04:00.0: Tunable channels: 13 802.11bg, 23 802.11a channels [7.805454] iwl3945 :04:00.0: Detected Intel Wireless WiFi Link 3945ABG [7.805601] iwl3945 :04:00.0: irq 28 for MSI/MSI-X [7.812916] ACPI: AC Adapter [ACAD] (on-line) [8.060673] ACPI: Battery Slot [BAT1] (battery present) [8.338410] HDA Intel :00:1b.0: PCI INT A - GSI 22 (level, low) - IRQ 22 [8.338472] HDA Intel :00:1b.0: setting latency timer to 64 [8.825775] hda_codec: ALC861: BIOS auto-probing. [8.826918] input: HDA Digital PCBeep as /devices/pci:00/:00:1b.0/input/input8 [8.901410] pcmcia_socket pcmcia_socket0: cs: IO port probe 0x100-0x3af: clean. [8.903470] pcmcia_socket pcmcia_socket0: cs: IO port probe 0x3e0-0x4ff: excluding 0x4d0-0x4d7 [8.904348] pcmcia_socket pcmcia_socket0: cs: IO port probe 0x820-0x8ff: clean. [8.905068] pcmcia_socket pcmcia_socket0: cs: IO port probe 0xc00-0xcf7: clean. [8.905968] pcmcia_socket pcmcia_socket0: cs: IO port probe 0xa00-0xaff: clean. [8.945844] phy0: Selected rate control algorithm 'iwl-3945-rs' [ 10.391870] Adding 2224992k swap on /dev/sda2. Priority:-1 extents:1 across:2224992k [ 10.897931] EXT3 FS on sda1, internal journal [ 11.440421] loop: module loaded [ 12.188675] kjournald starting. Commit interval 5 seconds [ 12.189061] EXT3 FS on sda4, internal journal [ 12.189071] EXT3-fs: mounted filesystem with ordered data mode. [ 12.280932] FAT: utf8 is not a recommended IO charset for FAT filesystems, filesystem will be case sensitive! [ 33.226812] iwl3945 :04:00.0: firmware: requesting iwlwifi-3945-2.ucode [ 33.536049] iwl3945 :04:00.0: loaded firmware version 15.32.2.9 [ 33.607253] Registered led device: iwl-phy0::radio [ 33.608703] Registered led device: iwl-phy0::assoc [ 33.609665] Registered led device: iwl-phy0::RX [ 33.610197] Registered led device: iwl-phy0::TX [ 33.622206] ADDRCONF(NETDEV_UP): wlan0: link is not ready [ 38.297233] r8169: eth0: link up [ 38.297254] r8169: eth0: link up [ 40.946707] CPUFREQ: Per core ondemand sysfs interface is deprecated - ignore_nice_load [ 41.045591] Registered led device: iwl-phy0::radio [ 41.045613] Registered led device: iwl-phy0::assoc [ 41.045671] Registered led device: iwl-phy0::RX [ 41.045689] Registered led device: iwl-phy0::TX [ 41.057099] ADDRCONF(NETDEV_UP): wlan0: link is not ready [ 41.181114] r8169: eth0: link up [ 42.729125] [drm] Initialized drm 1.1.0 20060810 [ 42.887824] pci :00:02.0: PCI INT A - GSI 16 (level, low) - IRQ 16 [ 42.887830] pci :00:02.0: setting latency timer to 64 [ 42.891603] [drm] Initialized i915 1.6.0 20080730 for :00:02.0 on minor 0 [ 51.672165] eth0: no IPv6 routers present [ 71.612502] CPUFREQ: Per core ondemand sysfs interface is deprecated - up_threshold [ 1213.697130] CE: hpet increasing min_delta_ns to 15000 nsec [ 2417.988062] [ cut here ] [ 2417.988074] WARNING: at /tmp/buildd/linux-2.6-2.6.32/debian/build/source_i386_none/net/sched/sch_generic.c:261 dev_watchdog+0xbd/0x15d() [ 2417.988078] Hardware name: Satellite A110 [ 2417.988080] NETDEV WATCHDOG: eth0 (r8169): transmit queue 0 timed out [ 2417.988083] Modules linked in: i915 drm_kms_helper drm i2c_algo_bit binfmt_misc acpi_cpufreq cpufreq_userspace cpufreq_powersave cpufreq_conservative cpufreq_stats nls_utf8
Processed: bug 570229 is forwarded to http://bugzilla.kernel.org/show_bug.cgi?id=15021
Processing commands for cont...@bugs.debian.org: forwarded 570229 http://bugzilla.kernel.org/show_bug.cgi?id=15021 Bug #570229 [linux-2.6] udev: [drm:drm_fill_in_dev] *ERROR* Cannot initialize the agpgart module Set Bug forwarded-to-address to 'http://bugzilla.kernel.org/show_bug.cgi?id=15021'. thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- 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/handler.s.c.1266855060310.transcr...@bugs.debian.org
Bug#545879:
I can confirm that the recent kernel update in 5.0.4 solved it for us. The version is 2.6.26-21. I have reason to believe from looking at the changelog, the nohz fixes are the reason why the new kernel works without any hangs. Regards, Mike Carvalho
Re: [ubuntu-x] Status of kernel X drivers
On Sun, 21 Feb 2010 23:20:14 +, Ben Hutchings b...@decadent.org.uk wrote: On Thu, 2010-02-18 at 14:40 -0800, Bryce Harrington wrote: [...] From apw's Kernel Summary, about why we are going with 2.6.32: The primary decision for the kernel team at UDS is to choose the base kernel version for the release. For Lucid this will be 2.6.32. This version has just released providing the maximum stabalisation time, it also is expected to be the kernel of choice for long term releases from other distributions.[1] If other distros are pulling the 2.6.33 drm on top of their 2.6.32 for their long term releases as sounds like is the case[2], then this would be a fairly significant divergence on our part for no real gain. [...] 2: http://cvs.fedoraproject.org/viewvc/rpms/kernel/F-12/drm-upgrayedd.patch?view=log Fedora has been backporting drm (and nouveau) for a long time but it's not so clear what means for RHEL. I think this is something we will also consider doing in Debian. A year from now I expect nv to be dead and radeon UMS to be removed upstream, making it impractical to backport new hardware support. Given that, the maintenance burden for 2.6.33 drm should be lower. But this is really outside my area of expertise and certainly not my decision to make. We should probably also consider what this means for drm on the 2.6.32-stable branch. Should the drm developers still send patches there as well, where applicable? If all the distributions using 2.6.32 use the backported drm, should we ask Greg K-H to pull that? Not sure that gregkh would go along with it, but agreed on the other points, and maybe if distro folks ask for a backport pull instead of upstream developers we'll have a better chance of success. The Intel guys should continue sending patches for the current stable branch. I've seen a bunch of non-Intel folks requesting pulls of additional drm/i915 patches to stable branches, so hopefully that can cover 2.6.32 caretaking once our process moves on to the next stable kernel. pgpwTn0p4bJiK.pgp Description: PGP signature
Bug#570990: newer paxtest upstream available
Package: paxtest Version: 0.9.7-pre4-2 Severity: wishlist upstream released 0.9.9 and even has a debian subdir, maybe you could get upstream to have it policy confirmant? new upstream location: http://www.grsecurity.net/~spender/ current latest tarball: http://www.grsecurity.net/~spender/paxtest-0.9.9.tgz -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (900, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-2-amd64 (SMP w/2 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- 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/20100222164124.10814.7610.report...@dual
Processed: [bts-link] source package linux-2.6
Processing commands for cont...@bugs.debian.org: # # bts-link upstream status pull for source package linux-2.6 # see http://lists.debian.org/debian-devel-announce/2006/05/msg1.html # user bts-link-upstr...@lists.alioth.debian.org Setting user to bts-link-upstr...@lists.alioth.debian.org (was bts-link-de...@lists.alioth.debian.org). # remote status report for #569012 (http://bugs.debian.org/569012) # * http://bugzilla.kernel.org/show_bug.cgi?id=15296 # * remote status changed: NEW - NEEDINFO usertags 569012 - status-NEW Bug#569012: linux-image-2.6.32-1-amd64: Freezes and memory corruption Usertags were: status-NEW. Usertags are now: . usertags 569012 + status-NEEDINFO Bug#569012: linux-image-2.6.32-1-amd64: Freezes and memory corruption There were no usertags set. Usertags are now: status-NEEDINFO. # remote status report for #569906 (http://bugs.debian.org/569906) # * http://bugzilla.kernel.org/show_bug.cgi?id=15321 # * remote status changed: (?) - RESOLVED # * remote resolution changed: (?) - INVALID # * closed upstream tags 569906 + fixed-upstream Bug #569906 [linux-2.6] linux-image-2.6.32-trunk-686: Fails to mount a vfat usb device (mp4 player) Added tag(s) fixed-upstream. usertags 569906 + status-RESOLVED resolution-INVALID Bug#569906: linux-image-2.6.32-trunk-686: Fails to mount a vfat usb device (mp4 player) There were no usertags set. Usertags are now: status-RESOLVED resolution-INVALID. # remote status report for #570125 (http://bugs.debian.org/570125) # * https://bugs.freedesktop.org/show_bug.cgi?id=26617 # * remote status changed: (?) - NEW usertags 570125 + status-NEW Bug#570125: [drm/i915] suspend/resume only works once with kms There were no usertags set. Usertags are now: status-NEW. thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- 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/handler.s.c.126685887523506.transcr...@bugs.debian.org
[bts-link] source package linux-2.6
# # bts-link upstream status pull for source package linux-2.6 # see http://lists.debian.org/debian-devel-announce/2006/05/msg1.html # user bts-link-upstr...@lists.alioth.debian.org # remote status report for #569012 (http://bugs.debian.org/569012) # * http://bugzilla.kernel.org/show_bug.cgi?id=15296 # * remote status changed: NEW - NEEDINFO usertags 569012 - status-NEW usertags 569012 + status-NEEDINFO # remote status report for #569906 (http://bugs.debian.org/569906) # * http://bugzilla.kernel.org/show_bug.cgi?id=15321 # * remote status changed: (?) - RESOLVED # * remote resolution changed: (?) - INVALID # * closed upstream tags 569906 + fixed-upstream usertags 569906 + status-RESOLVED resolution-INVALID # remote status report for #570125 (http://bugs.debian.org/570125) # * https://bugs.freedesktop.org/show_bug.cgi?id=26617 # * remote status changed: (?) - NEW usertags 570125 + status-NEW thanks -- 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/20100222171309.27045.17470.btsl...@merkel.debian.org
Bug#569906: marked as done (linux-image-2.6.32-trunk-686: Fails to mount a vfat usb device (mp4 player))
Your message dated Mon, 22 Feb 2010 18:46:07 +0100 with message-id 20100222174607.gd15...@stro.at and subject line Re: linux-image-2.6.32-trunk-686: Fails to mount a vfat usb device (mp4 player) has caused the Debian Bug report #569906, regarding linux-image-2.6.32-trunk-686: Fails to mount a vfat usb device (mp4 player) to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 569906: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=569906 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ---BeginMessage--- Package: linux-2.6 Version: 2.6.32-5 Severity: normal A little longish summary: a MP4 player which can be mounted on Lenny with 2.6.26 cannot be mounted on Sid with 2.6.32. If you look in the attached logs, you may find references to an Actions media player which seems like it is identified by the kernel with no issues. However, the device cannot be mounted. A web search for the name of the device as reported by lsusb finds many disappointed users of different distributions. However, The same device is mounted with no problem on a machine I have that runs Lenny, with # mount -t vfat /dev/sdb /mnt I am attaching the end of dmesg from there -- looks the same as here to me, but maybe I'm missing something... If there's any more info I can supply, I'll be happy to do so. Thanks, Shai. -- Package-specific info: ** Version: Linux version 2.6.32-trunk-686 (Debian 2.6.32-5) (b...@decadent.org.uk) (gcc version 4.3.4 (Debian 4.3.4-6) ) #1 SMP Sun Jan 10 06:32:16 UTC 2010 ** Command line: root=/dev/sda1 ro ** Tainted: PW (513) * Proprietary module has been loaded. * Taint on warning. ** Kernel log: [1592276.142567] scsi 40:0:0:1: Direct-Access GENERIC USB DISK DEVICE 1.00 PQ: 0 ANSI: 0 CCS [1592276.143062] sd 40:0:0:0: Attached scsi generic sg2 type 0 [1592276.143248] sd 40:0:0:1: Attached scsi generic sg3 type 0 [1592276.148193] sd 40:0:0:0: [sdb] 3833344 512-byte logical blocks: (1.96 GB/1.82 GiB) [1592276.149187] sd 40:0:0:1: [sdc] Attached SCSI removable disk [1592276.149808] sd 40:0:0:0: [sdb] Write Protect is off [1592276.149813] sd 40:0:0:0: [sdb] Mode Sense: 00 12 00 00 [1592276.149816] sd 40:0:0:0: [sdb] Assuming drive cache: write through [1592276.153058] sd 40:0:0:0: [sdb] Assuming drive cache: write through [1592276.153064] sdb: [1592276.160563] sd 40:0:0:0: [sdb] Assuming drive cache: write through [1592276.160568] sd 40:0:0:0: [sdb] Attached SCSI removable disk [1592276.327671] devkit-disks-da[4618]: segfault at c ip 080660da sp bffc09b0 error 4 in devkit-disks-daemon[8048000+28000] [1592400.620020] usb 2-1: new full speed USB device using uhci_hcd and address 35 [1592400.796046] usb 2-1: New USB device found, idVendor=0421, idProduct=0016 [1592400.796050] usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [1592400.796054] usb 2-1: Product: Nokia 6267 [1592400.796056] usb 2-1: Manufacturer: Nokia [1592400.796059] usb 2-1: SerialNumber: 355539016515767 [1592400.796175] usb 2-1: configuration #1 chosen from 1 choice [1592400.799192] scsi41 : SCSI emulation for USB Mass Storage devices [1592400.799386] usb-storage: device found at 35 [1592400.799388] usb-storage: waiting for device to settle before scanning [1592405.797092] usb-storage: device scan complete [1592405.800105] scsi 41:0:0:0: Direct-Access NokiaNokia 6267 PQ: 0 ANSI: 4 [1592405.800612] sd 41:0:0:0: Attached scsi generic sg4 type 0 [1592405.806283] sd 41:0:0:0: [sdd] Adjusting the sector count from its reported value: 3970049 [1592405.806293] sd 41:0:0:0: [sdd] 3970048 512-byte logical blocks: (2.03 GB/1.89 GiB) [1592405.809063] sd 41:0:0:0: [sdd] Write Protect is off [1592405.809067] sd 41:0:0:0: [sdd] Mode Sense: 03 00 00 00 [1592405.809070] sd 41:0:0:0: [sdd] Assuming drive cache: write through [1592405.821069] sd 41:0:0:0: [sdd] Adjusting the sector count from its reported value: 3970049 [1592405.824112] sd 41:0:0:0: [sdd] Assuming drive cache: write through [1592405.824118] sdd: sdd1 [1592405.947112] sd 41:0:0:0: [sdd] Adjusting the sector count from its reported value: 3970049 [1592405.952086] sd 41:0:0:0: [sdd] Assuming drive cache: write through [1592405.952093] sd 41:0:0:0: [sdd] Attached SCSI removable disk [1592413.214108] FAT: utf8 is not a recommended IO charset for FAT filesystems, filesystem will be case sensitive! [1592507.120034] usb 2-1: USB disconnect, address 35 [1592507.856020] usb 2-1: new full speed USB device using uhci_hcd and address 36 [1592508.030348] usb 2-1: New USB device found, idVendor=0421, idProduct=0015 [1592508.030352] usb 2-1: New USB device
Bug#541317: marked as done (Built-in microphone doesn't produce any sound with linux-image-2.6.30-1-amd64)
Your message dated Mon, 22 Feb 2010 18:51:29 +0100 with message-id 20100222175129.ga19...@baikonur.stro.at and subject line Re: Bug#541317: Built-in microphone doesn't produce any sound with linux-image-2.6.30-1-amd64 has caused the Debian Bug report #541317, regarding Built-in microphone doesn't produce any sound with linux-image-2.6.30-1-amd64 to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 541317: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=541317 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ---BeginMessage--- Package: linux-image-2.6.30-1-amd64_2.6.30-5snapshot.14079_amd64.deb System: Debian/Sid, AMD64 Hardware: Acer Travelmate 4530 AMD Athlon 64 X2 dual-core Severity: normal When using linux-image-2.6.30-1-amd64 the built-in microphone doesn't produce any sound, this seems to be a regression for it works with linux-image-2.6.29-2-amd64. lspci -v: Audio device: ATI Technologies Inc SBx00 Azalia (Intel HDA) Subsystem: Acer Incorporated [ALI] Device 0147 Flags: bus master, slow devsel, latency 64, IRQ 16 Memory at f060 (64-bit, non-prefetchable) [size=16K] Capabilities: [50] Power Management version 2 Kernel driver in use: HDA Intel ---End Message--- ---BeginMessage--- Version: 2.6.30-8 On Mon, Feb 22, 2010 at 04:43:20PM +0800, Jos van Wolput wrote: Moritz Muehlenhoff wrote: On Thu, Aug 13, 2009 at 05:46:51PM +0800, Jos van Wolput wrote: System: Debian/Sid, linux-image-2.6.32-2-amd64 (2.6.32-8) Hardware: Acer Travelmate 4530 AMD Athlon 64 X2 dual-core I tested both the built-in and the external microphone using audacity. Both mics work. This bug can now be closed. thanks for quick feedback, closing with appropriate version. thanks for your report. ---End Message---
Bug#541317: marked as done (Built-in microphone doesn't produce any sound with linux-image-2.6.30-1-amd64)
Your message dated Mon, 22 Feb 2010 19:07:47 +0100 with message-id 20100222180747.ga17...@inutil.org and subject line Re: Built-in microphone doesn't produce any sound with linux-image-2.6.30-1-amd64 has caused the Debian Bug report #541317, regarding Built-in microphone doesn't produce any sound with linux-image-2.6.30-1-amd64 to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 541317: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=541317 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ---BeginMessage--- Package: linux-image-2.6.30-1-amd64_2.6.30-5snapshot.14079_amd64.deb System: Debian/Sid, AMD64 Hardware: Acer Travelmate 4530 AMD Athlon 64 X2 dual-core Severity: normal When using linux-image-2.6.30-1-amd64 the built-in microphone doesn't produce any sound, this seems to be a regression for it works with linux-image-2.6.29-2-amd64. lspci -v: Audio device: ATI Technologies Inc SBx00 Azalia (Intel HDA) Subsystem: Acer Incorporated [ALI] Device 0147 Flags: bus master, slow devsel, latency 64, IRQ 16 Memory at f060 (64-bit, non-prefetchable) [size=16K] Capabilities: [50] Power Management version 2 Kernel driver in use: HDA Intel ---End Message--- ---BeginMessage--- Version: 2.6.32-1 Jos van Wolput wrote: System: Debian/Sid, linux-image-2.6.32-2-amd64 (2.6.32-8) Hardware: Acer Travelmate 4530 AMD Athlon 64 X2 dual-core I tested both the built-in and the external microphone using audacity. Both mics work. This bug can now be closed. Ok, closing. Cheers, Moritz ---End Message---
Bug#542115: marked as done ([chrome] linux-image-2.6.26-2-686: kernel BUG at kernel/exit.c:822!)
Your message dated Mon, 22 Feb 2010 19:12:31 +0100 with message-id 20100222181231.ga2...@galadriel.inutil.org and subject line Re: Bug#570350: linux-image-2.6.26-2-amd64: kernel BUG at kernel/exit.c:822! has caused the Debian Bug report #570350, regarding [chrome] linux-image-2.6.26-2-686: kernel BUG at kernel/exit.c:822! to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 570350: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=570350 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ---BeginMessage--- Package: linux-image-2.6.26-2-686 Version: 2.6.26-17lenny2 Severity: normal I have this in my /var/log/kern.log: Aug 17 11:54:27 mizar kernel: [8806733.883881] Not cloning cgroup for unused subsystem ns Aug 17 11:55:38 mizar kernel: [8806840.228151] [ cut here ] Aug 17 11:55:38 mizar kernel: [8806840.228160] kernel BUG at kernel/exit.c:822! Aug 17 11:55:38 mizar kernel: [8806840.228164] invalid opcode: [#1] SMP Aug 17 11:55:38 mizar kernel: [8806840.228170] Modules linked in: udf crc_itu_t visor usbserial ext2 xt_mac ipt_MASQUERADE iptable_nat nf_nat nf_conntrack_ipv4 nf_conntrack nls_utf8 nls_cp437 vfat fat usb_storage isofs nls_base zlib_inflate xt_multiport iptable_filter ip_tables x_tables binfmt_misc nvidia(P) agpgart rfcomm l2cap ppdev lp autofs4 tun ipv6 nfsd auth_rpcgss exportfs nfs lockd nfs_acl sunrpc fuse dm_snapshot dm_mirror dm_log dm_mod sbp2 loop snd_intel8x0 snd_ac97_codec ac97_bus snd_pcm_oss snd_mixer_oss snd_pcm snd_seq_dummy snd_seq_oss snd_seq_midi snd_rawmidi snd_seq_midi_event snd_seq snd_timer snd_seq_device parport_pc parport snd button soundcore hci_usb rng_core pcspkr i2c_i801 snd_page_alloc bluetooth iTCO_wdt e752x_edac i2c_core shpchp pci_hotplug edac_core evdev dcdbas ext3 jbd mbcache usbhid hid ff_memless raid1 md_mod ide_cd_mod cdrom sd_mod piix ide_pci_generic ide_core floppy ohci1394 ata_piix ieee1394 ata_generic libata scsi_mod dock ehci_hcd uhci_! hcd usbcore e1000 thermal processor Aug 17 11:55:38 mizar kernel: an thermal_sys Aug 17 11:55:38 mizar kernel: [8806840.228301] Aug 17 11:55:38 mizar kernel: [8806840.228306] Pid: 17496, comm: chrome Tainted: P (2.6.26-2-686 #1) Aug 17 11:55:38 mizar kernel: [8806840.228311] EIP: 0060:[c012527d] EFLAGS: 00210287 CPU: 0 Aug 17 11:55:38 mizar kernel: [8806840.228320] EIP is at do_exit+0x40c/0x5bb Aug 17 11:55:38 mizar kernel: [8806840.228324] EAX: f74c0780 EBX: f74c0658 ECX: f74c0780 EDX: f74c073c Aug 17 11:55:38 mizar kernel: [8806840.228328] ESI: f74c0660 EDI: f74c0658 EBP: f74c0660 ESP: f221bf80 Aug 17 11:55:38 mizar kernel: [8806840.228332] DS: 007b ES: 007b FS: 00d8 GS: SS: 0068 Aug 17 11:55:38 mizar kernel: [8806840.228336] Process chrome (pid: 17496, ti=f221a000 task=f74c0660 task.ti=f221a000) Aug 17 11:55:38 mizar kernel: [8806840.228340] Stack: f221bf88 f221bf88 d047f380 f7492d00 f221a000 Aug 17 11:55:38 mizar kernel: [8806840.228351]c0125490 bf8bf594 bf8bfbfb c01254c6 c0103853 Aug 17 11:55:38 mizar kernel: [8806840.228361] bf8bf594 bf8bfbfb bf8bf9c8 00fc 007b 007b Aug 17 11:55:38 mizar kernel: [8806840.228371] Call Trace: Aug 17 11:55:38 mizar kernel: [8806840.228400] [c0125490] do_group_exit+0x64/0x8d Aug 17 11:55:38 mizar kernel: [8806840.228417] [c01254c6] sys_exit_group+0xd/0x10 Aug 17 11:55:38 mizar kernel: [8806840.228423] [c0103853] sysenter_past_esp+0x78/0xb1 Aug 17 11:55:38 mizar kernel: [8806840.228482] === Aug 17 11:55:38 mizar kernel: [8806840.228484] Code: dc 00 00 00 39 c2 75 ce f0 81 05 00 ea 36 c0 00 00 00 01 fb 0f 1f 84 00 00 00 00 00 90 8d 86 20 01 00 00 39 86 20 01 00 00 74 04 0f 0b eb fe 39 96 dc 00 00 00 74 04 0f 0b eb fe 8b 5c 24 08 81 Aug 17 11:55:38 mizar kernel: [8806840.228541] EIP: [c012527d] do_exit+0x40c/0x5bb SS:ESP 0068:f221bf80 Aug 17 11:55:38 mizar kernel: [8806840.228558] ---[ end trace 4090fef249e8d577 ]--- Aug 17 11:55:38 mizar kernel: [8806840.228562] Fixing recursive fault but reboot is needed! At the moment, the process mentioned is still showing up in the output of ps: # ps -ef|grep 17496 flemingr 17496 1 0 11:54 ?00:00:00 [chrome] But the chrome web browser is no-where to be found on-screen. Not sure what provoked this. -- Package-specific info: ** Version: Linux version 2.6.26-2-686 (Debian 2.6.26-15lenny3) (da...@debian.org) (gcc version 4.1.3 20080704 (prerelease) (Debian 4.1.2-25)) #1 SMP Thu May 28 15:39:35 UTC 2009 ** Command line: root=/dev/md0 ro **
Bug#564731: base: hald crash after plugged in PSP
On Mon, Jan 11, 2010 at 07:53:24PM +0100, Uwe Kleine-König wrote: Hello, When I plugged in my PSP for some file transfer, my system crashed. The screen freezed, and the only option was to hard reset my system. If I boot up with the PSP plugged in, the system crashed after hald started or while hald is starting. If I start up after that, I have to fsck the root partition, and after that my system boots up fine (without the PSP plugged in). The last 6 messages on the screen were: __do__softirq+0x131/0x173 handle_fasteoi_irq+0x7d/0xb5 handle_irq+0x17/0x1d do_IRQ+0x57/0xbf ret_from_intr+0x0/0x11 EOI 4---[ end trace e24949eb6f8b1bf6 ]--- I attached a photo, with all the messages (which fitt on the screen) Can you try to get a more complete dump by using serial or netconsole. If that doesn't work at least boot with vga=6 to get a finer resolution. What kernel version are you using? Can you retry with latest kernel from sid? (It should be installable in a stable system without bigger problems.) Caspar? Cheers, Moritz -- 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/20100222175757.gb14...@inutil.org
Bug#560733: linux-image-2.6.30-2-amd64: ADSL USB ethernet interface(eth0) not showing RX/TX information
Mohan R wrote: Package: linux-image-2.6.30-2-amd64 Version: 2.6.30-8squeeze1 Severity: normal I'm using ADSL USB ethernet as eth0 to connect to internet. System also have 'wl' driver. But eth0 not showing any RX/TX information. Kindly look into the attached log file. Even if I'm streaming from youtube, it shows nothing in RX/TX lines for eth0. xfce4-netload-plugin requires RX/TX data to function properly. Could you please try the current 2.6.32 kernel? Does it work without the proprietary Nvidia kernel module being loaded? Cheers, Moritz -- 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/20100222175747.ga14...@inutil.org
Bug#519984: Cannot boot 2.6.26 kernel on HPPA N4000
Moritz Muehlenhoff wrote: On Sun, Jul 26, 2009 at 08:39:22AM -0600, Grant Grundler wrote: Moritz, thanks for forwarding... On Sat, Jul 25, 2009 at 04:10:04PM +0200, Moritz Muehlenhoff wrote: Attempting to boot a 2.6.26 kernel on an HP N4000 machine (64 bit PA-RISC) yields the following results (beginning at system startup): Beginning of error ... Elroy version TR3.0 (0x4) found at 0xfecf4000 PCI: Address space collision on region 0 of device :d0:00.0 [70e0800:70e08ff] ... sym53c8xx :d0:00.0: enabling device ( - 0003) sym53c8xx :d0:00.0: enabling SERR and PARITY (0003 - 0143) * SYSTEM ALERT ** ... 0x187000FF6292 - type 0 = Data Field Unused 0x5800187000FF6292 6D02 100F120F - type 11 = Timestamp 03/16/2009 The address space collision is likely the cause of this HPMC. (0xff6292 == HPMC) With HPMC's, PIM info is worth collecting. See http://www.parisc-linux.org/faq/kernelbug-howto.html for details on how to collect PIM info. It would also be helpful to collect in io output from the same PDC prompt that allows one to run ser pim and clearpim. Lastly, if an older kernel does boot, lspci -v would be helpful. Is this a known issue, has it been fixed in current kernels from unstable? The parenting of resources in the generic PCI support has been changed. I can't say if it fixes this problem. Is it possible to test a 2.6.30 or 2.6.31-rc kernel? That will be difficult for the bug submitter, since the current versions of the debian installer are not yet based on 2.6.30 AFAICT. However, maybe the PCI card, which causes the collision can be temporarily removed, so that the installation proceeds. After that, the 2.6.30 kernel from unstable could be installed and the PCI card re-plugged in. Marc, would you be able to test this? Marc, would you be able to test this? Cheers, Moritz -- 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/20100222180807.gb17...@inutil.org
Processed: tagging 571019
Processing commands for cont...@bugs.debian.org: # Automatically generated email from bts, devscripts version 2.10.35lenny7 tags 571019 + pending Bug #571019 [linux-2.6] /dev/ttyS1 on openrd-base not working Added tag(s) pending. End of message, stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- 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/handler.s.c.126687322830613.transcr...@bugs.debian.org
Processed: tagging 570678
Processing commands for cont...@bugs.debian.org: tags 570678 pending Bug #570678 [initramfs-tools] initramfs-tools: fix upstream's git commit a2127d33 to avoid firmware copy error Added tag(s) pending. thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- 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/handler.s.c.126687312330286.transcr...@bugs.debian.org
Processed: tagging 543568
Processing commands for cont...@bugs.debian.org: tags 543568 pending Bug #543568 [initramfs-tools] initramfs-tools: usb storage device not recognized at boot after upgrade to kernel 2.6.30 Added tag(s) pending. thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- 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/handler.s.c.12668741822761.transcr...@bugs.debian.org
Bug#570678: initramfs-tools: fix upstream's git commit a2127d33 to avoid firmware copy error
On Sat, 20 Feb 2010, Michael Prokop wrote: Package: initramfs-tools Severity: normal [Disclaimer: I do not report against a specific version because this bugreport is against git tree of initramfs-tools. The according code shouldn't enter a release because it might break several systems, though I'd like to see a new initramfs-tools version soon - that's why I'm reporting here.] The problem is located in this patch: thanks merged and pushed out. -- 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/2010011147.ga12...@stro.at
Processed: tagging 569033
Processing commands for cont...@bugs.debian.org: tags 569033 pending Bug #569033 [initramfs-tools] initramfs-tools: Please make the panic argument available in the rescue shell Added tag(s) pending. thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- 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/handler.s.c.12668747215188.transcr...@bugs.debian.org
Bug#571019: /dev/ttyS1 on openrd-base not working
Package: linux-2.6 Version: 2.6.32-1 - Forwarded message from Luca Niccoli lultimou...@gmail.com - Date: Mon, 22 Feb 2010 02:23:28 +0100 From: Luca Niccoli lultimou...@gmail.com To: debian-...@lists.debian.org Subject: /dev/ttyS1 on openrd Hi, today I tried to use the serial port on my openrd-base (the rs232, not the one with the mini-usb connector). After half an hour trying to understand why my ttl level shifter didn't work, I tried on an other computer, and everything went fine =) This thread [1] has a patch to enable UART1 by disabling the SDIO with a boot parameter; it would be nice if it could be ported to debian and/or upstream. Cheers, Luca [1] http://groups.google.com/group/openrd/browse_thread/thread/7ba48f2d7916a88f -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4e9568871002211723p375422d8vce29e076809e3...@mail.gmail.com - End forwarded message - -- Martin Michlmayr http://www.cyrius.com/ -- 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/2010010237.gq1...@jirafa.cyrius.com
Bug#543568: initramfs-tools: usb storage device not recognized at boot after upgrade to kernel 2.6.30
On Tue, 25 Aug 2009, Avi Rozen wrote: Package: initramfs-tools Version: 0.93.4 Severity: important Tags: patch -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 USB storage device is not recognized at boot after kernel upgrade. It seems that the usb-storage module has been split into several mini modules, which are not copied to the initramfs image. In my case usb-storage.ko is copied but ums-cypress.ko is not copied. I've attached a patch against hook-functions that fixes this, by using copy_modules_dir to copy all the modules in kernel/drivers/usb/storage, instead of just usb-storage. I've set the severity to important because my USB storage device also happens to be the boot device... Cheers, Avi thanks for the patch, finaly applied to current trunk, will be in next revision for squeeze. -- 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/2010013017.gb12...@stro.at
Bug#534324: linux-image-2.6.30-1-686: USB disk fails to show up at initramfs
On Fri, 19 Feb 2010, Martin Michlmayr wrote: Vincent Rubiolo just reported the same issue to me in private mail and found this bug report. The problem is that ums-cypress is not included in the initramfs; however, when the CONFIG_USB_STORAGE_CYPRESS_ATACB is enabled, usb-storage itself will not claim those devices; see https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/419231/comments/13 Ubuntu solved this problem by including all usb-storage modules: https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/419231/comments/19 maks, what's the status of this bug in Debian? thanks for reminder, added relevant patch to latest git. indeed to add all relevant modules. plan to upload soon (sometime in early march at latest) -- 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/2010013139.gc12...@stro.at
Bug#569033: initramfs-tools: Please make the panic argument available in the rescue shell
On Mon, 15 Feb 2010, Ferenc Wagner wrote: wf...@niif.hu writes: maximilian attems m...@stro.at writes: ok full ack to the sent in patch, will merge today/tomorrow, only small preference to call $PANIC as this seems easier to memorize, ok for you? I certainly don't feel strongly about the name of the variable, feel free to rename as you wish, but consider that $panic is already present. ping? applied as is to latest git, thanks! -- 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/2010013809.gd12...@stro.at
Bug#567098: linux-image-2.6.26-2-ixp4xx: adm8511/pegasus usb ethernet device loses mac on nslu2 when cold-plugged
* Devin Carraway de...@debian.org [2010-01-27 02:19]: I've been experimenting with a Pegasus-chipset USB ethernet adapter on an NSLU2 unit. If the adapter is connected prior to system boot, although it will be recognized by the kernel and udev, it starts out with a MAC address of 00:00:00:00:00:00. I finally got around to testing my Pegasus USB Ethernet (a different one to yours) with my NSLU2 and I cannot reproduce this issue (see attached dmesg and udevadm). Can you please report this issue directly to Petko Manolov pet...@users.sourceforge.net, net...@vger.kernel.org (the maintainer of the Pegasus driver and the Linux networking list) and also CC: Krzysztof Halasa k...@pm.waw.pl (the maintainer of the IXP4xx platform) Thanks. -- Martin Michlmayr http://www.cyrius.com/ Booting kernel at 0x8000... Uncompressing Linux... done, booting the kernel. [0.00] Initializing cgroup subsys cpuset [0.00] Initializing cgroup subsys cpu [0.00] Linux version 2.6.32-rc6-ixp4xx (Debian 2.6.32~rc6-1) (b...@decadent.org.uk) (gcc version 4.1.3 20080420 (prerelease) (Debian 4.1.2-22)) #1 Thu Nov 12 18:53:34 UTC 2009 [0.00] CPU: XScale-IXP42x Family [690541f1] revision 1 (ARMv5TE), cr=397f [0.00] CPU: VIVT data cache, VIVT instruction cache [0.00] Machine: Linksys NSLU2 [0.00] Memory policy: ECC disabled, Data cache writeback [0.00] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 8128 [0.00] Kernel command line: console=ttyS0,115200 rtc-x1205.probe=0,0x6f noirqdebug [0.00] Unknown boot option `rtc-x1205.probe=0,0x6f': ignoring [0.00] IRQ lockup detection disabled [0.00] PID hash table entries: 128 (order: -3, 512 bytes) [0.00] Dentry cache hash table entries: 4096 (order: 2, 16384 bytes) [0.00] Inode-cache hash table entries: 2048 (order: 1, 8192 bytes) [0.00] Memory: 32MB = 32MB total [0.00] Memory: 22636KB available (3012K code, 440K data, 108K init, 0K highmem) [0.00] SLUB: Genslabs=11, HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1 [0.00] Hierarchical RCU implementation. [0.00] NR_IRQS:64 [0.00] Console: colour dummy device 80x30 [0.00] Calibrating delay loop... 266.24 BogoMIPS (lpj=1331200) [0.24] Security Framework initialized [0.24] SELinux: Disabled at boot. [0.24] Mount-cache hash table entries: 512 [0.24] Initializing cgroup subsys ns [0.24] Initializing cgroup subsys cpuacct [0.24] Initializing cgroup subsys devices [0.24] Initializing cgroup subsys freezer [0.24] Initializing cgroup subsys net_cls [0.24] CPU: Testing write buffer coherency: ok [0.24] regulator: core version 0.5 [0.24] NET: Registered protocol family 16 [0.25] IXP4xx: Using 16MiB expansion bus window size [0.25] NSLU2: Using MAC address 00:13:10:d6:1e:a7 for port 0 [0.25] PCI: IXP4xx is host [0.25] PCI: IXP4xx Using direct access for memory space [0.25] pci :00:01.0: PME# supported from D0 D1 D2 D3hot [0.25] pci :00:01.0: PME# disabled [0.25] pci :00:01.1: PME# supported from D0 D1 D2 D3hot [0.25] pci :00:01.1: PME# disabled [0.25] pci :00:01.2: PME# supported from D0 D1 D2 D3hot [0.25] pci :00:01.2: PME# disabled [0.25] PCI: bus0: Fast back to back transfers disabled [0.25] pci :00:01.0: dmabounce: registered device [0.25] pci :00:01.1: dmabounce: registered device [0.25] pci :00:01.2: dmabounce: registered device [0.25] bio: create slab bio-0 at 0 [0.25] vgaarb: loaded [0.26] Switching to clocksource OSTS [0.27] NET: Registered protocol family 2 [0.27] IP route cache hash table entries: 1024 (order: 0, 4096 bytes) [0.27] TCP established hash table entries: 1024 (order: 1, 8192 bytes) [0.27] TCP bind hash table entries: 1024 (order: 0, 4096 bytes) [0.27] TCP: Hash tables configured (established 1024 bind 1024) [0.27] TCP reno registered [0.27] NET: Registered protocol family 1 [0.28] Unpacking initramfs... [2.02] Freeing initrd memory: 6140K [2.02] NetWinder Floating Point Emulator V0.97 (double precision) [2.02] audit: initializing netlink socket (disabled) [2.02] type=2000 audit(2.020:1): initialized [2.05] VFS: Disk quotas dquot_6.5.2 [2.05] Dquot-cache hash table entries: 1024 (order 0, 4096 bytes) [2.05] msgmni has been set to 56 [2.05] alg: No test for stdrng (krng) [2.05] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 253) [2.05] io scheduler noop registered [2.05] io scheduler anticipatory registered [2.05] io scheduler deadline registered [2.05] io scheduler cfq registered
Processed: tagging 565416
Processing commands for cont...@bugs.debian.org: tags 565416 pending Bug #565416 [initramfs-tools] update-initramfs: KEYMAP option fails to work due to missing /etc/console/boottime.kmap.gz Added tag(s) pending. thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- 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/handler.s.c.126687774230852.transcr...@bugs.debian.org
Re: Bug#543717: Initramfs firmware loading fail due to udev being started too late
On Sat, 06 Feb 2010, Marco d'Itri wrote: On Jan 26, maximilian attems m...@stro.at wrote: so it it will be run early enough that it is present for /etc/initramfs-tools/modules and no one will need to do mknoding. I cannot do this without coordination with the initramfs-tool package because load_modules and init-premount/blacklist must be moved as well and run before udevadm trigger. Please advise. changed blacklist to load at init-top stage in initramfs-tools git. plan to upload this or next week. -- 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/2010024017.gf12...@stro.at
Processed: tagging 568527
Processing commands for cont...@bugs.debian.org: tags 568527 pending Bug #568527 [initramfs-tools] /lib/udev/vol_id is still used Added tag(s) pending. thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- 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/handler.s.c.126687849012649.transcr...@bugs.debian.org
Bug#565416: update-initramfs: KEYMAP option fails to work due to missing
On Sat, 06 Feb 2010, Maximilian Gass wrote: I have attached a patch that makes the keymap hook consider /etc/console-setup/cached.kmap.gz. I have also added gunzip to the initramfs because otherwise loadkeys complained that it was missing and failed to load the keymap. thanks applied to current git, just with small modification: http://git.debian.org/?p=kernel/initramfs-tools.git;a=summary -- 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/2010023208.ge12...@stro.at
Bug#568527: /lib/udev/vol_id is still used
On Fri, 05 Feb 2010, Christoph Anton Mitterer wrote: Subject: initramfs-tools: sf Package: initramfs-tools Version: 0.93.4 Severity: normal Hi. At least /usr/share/initramfs-tools/scripts/local could still used vol_id which does however not longer exist. it is only used if around and will disappear postetch, latest git uses blkid if around, see http://git.debian.org/?p=kernel/initramfs-tools.git;a=summary -- 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/2010024122.gg12...@stro.at
Bug#523735: /etc/kernel/postinst.d/initramfs-tools: please consider supporting the experimental kernel-package out of the box
Why not simply removing that check: # kernel-package passes an extra arg; hack to not run under kernel-package [ -z $2 ] || exit 0 Or are there any reasons (I don't see) why the scripts won't work with kernel-package. One could add a conflict to a too old kernel-package if necessary. Cheers, Chris. -- 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/1266880718.20774.8.ca...@fermat.scientia.net
Processed: tagging 570554
Processing commands for cont...@bugs.debian.org: # Automatically generated email from bts, devscripts version 2.10.35lenny7 tags 570554 + pending Bug #570554 [linux-2.6] linux: /proc/pid/maps empty Bug #569683 [linux-2.6] linux-image-2.6.26-2-686: /proc/pid/maps is empty for all processes Added tag(s) pending. Added tag(s) pending. End of message, stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- 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/handler.s.c.126688202221128.transcr...@bugs.debian.org
Bug#568527: /lib/udev/vol_id is still used
On Mon, 2010-02-22 at 23:41 +0100, maximilian attems wrote: it is only used if around Yes I've seen that,... and will disappear postetch, latest git uses blkid if around, see http://git.debian.org/?p=kernel/initramfs-tools.git;a=summary ... just wanted to point you there in case it would have been missed ;) Cheers, Chris. -- 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/1266880101.20774.3.ca...@fermat.scientia.net
Bug#533903: initramfs-tools: support different compression tools in mkinitramfs
hello, sorry for the late reaction and thanks a lot for your report. On Wed, 03 Feb 2010, Bert Schulze wrote: Package: initramfs-tools Version: 0.93.4 Severity: normal Tags: patch Dear initramfs-tools Maintainers, since I've recently did some experiments regarding lzma compressed initramfs images I stumbled upon this quite old bugreport. As mentioned before the stock kernel has support for lzma/bzip2 compressed images built in nowadays and it works great. Instead of having to recompress the initramfs image by hand over and over again i did a patch against initramfs-tools-0.93.4 which enables mkinitramfs to build gzip/bzip2/lzma compressed images. cool for the testing! Therefor I've set a new variable in /etc/initramfs-tools/update-initramfs.conf # # compress_initramfs [ gzip | bzip2 | lzma ] # compress_initramfs=gzip hmm there i'm not sure that it is update-initramfs job. I'd prefer to have it in /etc/initramfs-tools/initramfs.conf and have mkinitramfs deal directly with it. then you also don't have to take care about the arg passing. update-initramfs has not many arguments and thus tries to stay user friendly. mkinitramfs is the low level interface. added the new function verify_compression() to the update-initramfs script which - checks the availability of the compression utility in userspace - matches the kernel's config file against the selected compression method - falls back to gzip compression if either or both are missing and prints verbose messages if that has happened. The method gets passed to mkinitramfs via a new optional argument -c COMP and mkinitramfs itself verifies that lzma or bzip2 has been passed as argument, or defaults to gzip. (as well if the -c argument has been omitted) Given the fact that gzip, bzip2 and lzma read input from stdin and pass the compressed output to stdout theres no need to change a lot of code here. would you care to rediff that according to aboves comment, to deal with it in mkinitramfs? also just fall back on current default if the input is undefined or strange of tha config option. unified diff attached best regards Bert Schulze thanks a lot for your input. kind regards. maks -- 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/2010030014.gh12...@stro.at
Processing of linux-2.6_2.6.18.dfsg.1-26etch2_i386.changes
linux-2.6_2.6.18.dfsg.1-26etch2_i386.changes uploaded successfully to localhost along with the files: linux-2.6_2.6.18.dfsg.1-26etch2.dsc linux-2.6_2.6.18.dfsg.1-26etch2.diff.gz linux-doc-2.6.18_2.6.18.dfsg.1-26etch2_all.deb linux-manual-2.6.18_2.6.18.dfsg.1-26etch2_all.deb linux-patch-debian-2.6.18_2.6.18.dfsg.1-26etch2_all.deb linux-source-2.6.18_2.6.18.dfsg.1-26etch2_all.deb linux-support-2.6.18-6_2.6.18.dfsg.1-26etch2_all.deb linux-tree-2.6.18_2.6.18.dfsg.1-26etch2_all.deb linux-headers-2.6.18-6-all_2.6.18.dfsg.1-26etch2_i386.deb linux-headers-2.6.18-6-all-i386_2.6.18.dfsg.1-26etch2_i386.deb linux-headers-2.6.18-6_2.6.18.dfsg.1-26etch2_i386.deb linux-image-2.6.18-6-486_2.6.18.dfsg.1-26etch2_i386.deb linux-headers-2.6.18-6-486_2.6.18.dfsg.1-26etch2_i386.deb linux-image-2.6.18-6-686_2.6.18.dfsg.1-26etch2_i386.deb linux-headers-2.6.18-6-686_2.6.18.dfsg.1-26etch2_i386.deb linux-image-2.6.18-6-k7_2.6.18.dfsg.1-26etch2_i386.deb linux-headers-2.6.18-6-k7_2.6.18.dfsg.1-26etch2_i386.deb linux-image-2.6.18-6-686-bigmem_2.6.18.dfsg.1-26etch2_i386.deb linux-headers-2.6.18-6-686-bigmem_2.6.18.dfsg.1-26etch2_i386.deb linux-image-2.6.18-6-amd64_2.6.18.dfsg.1-26etch2_i386.deb linux-headers-2.6.18-6-amd64_2.6.18.dfsg.1-26etch2_i386.deb linux-headers-2.6.18-6-vserver_2.6.18.dfsg.1-26etch2_i386.deb linux-image-2.6.18-6-vserver-686_2.6.18.dfsg.1-26etch2_i386.deb linux-headers-2.6.18-6-vserver-686_2.6.18.dfsg.1-26etch2_i386.deb linux-image-2.6.18-6-vserver-k7_2.6.18.dfsg.1-26etch2_i386.deb linux-headers-2.6.18-6-vserver-k7_2.6.18.dfsg.1-26etch2_i386.deb linux-headers-2.6.18-6-xen_2.6.18.dfsg.1-26etch2_i386.deb linux-image-2.6.18-6-xen-686_2.6.18.dfsg.1-26etch2_i386.deb linux-modules-2.6.18-6-xen-686_2.6.18.dfsg.1-26etch2_i386.deb linux-headers-2.6.18-6-xen-686_2.6.18.dfsg.1-26etch2_i386.deb xen-linux-system-2.6.18-6-xen-686_2.6.18.dfsg.1-26etch2_i386.deb linux-headers-2.6.18-6-xen-vserver_2.6.18.dfsg.1-26etch2_i386.deb linux-image-2.6.18-6-xen-vserver-686_2.6.18.dfsg.1-26etch2_i386.deb linux-modules-2.6.18-6-xen-vserver-686_2.6.18.dfsg.1-26etch2_i386.deb linux-headers-2.6.18-6-xen-vserver-686_2.6.18.dfsg.1-26etch2_i386.deb xen-linux-system-2.6.18-6-xen-vserver-686_2.6.18.dfsg.1-26etch2_i386.deb Greetings, Your Debian queue daemon (running on host ries.debian.org) -- 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/e1njjcf-000504...@ries.debian.org
Bug#567468: md homehost (was: Bug#567468: (boot time consequences of) Linux mdadm superblock) question.
On Mon, 22 Feb 2010 10:16:32 +0100 martin f krafft madd...@madduck.net wrote: also sprach Piergiorgio Sartor piergiorgio.sar...@nexgo.de [2010.02.21.2113 +0100]: I do not see how the homehost plays a role, here. Neil, Could you please put forth the argument for why the homehost must match, and why unconditional auto-assembly is not desirable? Realistically, what problems are we protecting against? The problem to protect against is any consequence of rearranging devices while the host is off, including attaching devices that previously were attached to a different computer. mdadm will currently assembly any array that it finds, but will not give a predictable name to anything that looks like it might be imported from a different host. So if you have 'md0' on each of two computers, one computer dies and you move the devices from that computer to the other, then as long as the bios boots of the right drive, mdadm will assemble the local array as 'md0' and the other array as 'something else'. There are two ways that mdadm determines than array is 'local'. 1/ is the uuid listed against an array in mdadm.conf 2/ is the 'homehost' encoded in the metadata. If either of those is true, the array is local and gets a predictable name. If neither, the name gets an _%d suffix. This is only an issue if you use device name (.e.g /dev/md0 or /dev/md/root) to mount the root filesystem. If you use mount-by-uuid then it clearly doesn't matter what name mdadm assembles the array under. In that case, the fs UUID (stored on the initramfs or similar) will assure the necessary uniqueness and mdadm need not worry about homehost. But if '/' is mounted by a name in /dev/md/, I want to be sure mdadm puts the correct array at that name no matter what other arrays might be visible. Does that clarify things enough? NeilBrown -- 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/20100223133028.279e0...@notabene.brown
Bug#567468: md homehost (was: Bug#567468: (boot time consequences of) Linux mdadm superblock) question.
also sprach Neil Brown ne...@suse.de [2010.02.23.0330 +0100]: The problem to protect against is any consequence of rearranging devices while the host is off, including attaching devices that previously were attached to a different computer. How often does this happen, and how grave/dangerous are the effects? But if '/' is mounted by a name in /dev/md/, I want to be sure mdadm puts the correct array at that name no matter what other arrays might be visible. Of course it would be nice if this happened, but wouldn't it be acceptable to assume that if someone swaps drives between machines that they ought to know how to deal with the consequences, or at least be ready to tae additional steps to make sure the system still boots as desired? Even if the wrong array appeared as /dev/md0 and was mounted as root device, is there any actual problem, other than inconvenience? Remember that the person who has previously swapped the drives is physically in front of (or behind ;)) the machine. I am unconvinced. I think we should definitely switch to using filesystem-UUIDs over device names, and that is the only real solution to the problem, no? -- martin | http://madduck.net/ | http://two.sentenc.es/ Escape Meta Alt Control Shift spamtraps: madduck.bo...@madduck.net digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/)
Bug#556231: Bug #556231
No issues so far with 2.6.32. xfsdump to tape seems to work better now, i.e. no panics. I think we can close this bug. smime.p7s Description: S/MIME Cryptographic Signature
Bug#567468: md homehost
Daniel Reurich dan...@centurion.net.nz writes: Could you please put forth the argument for why the homehost must match, and why unconditional auto-assembly is not desirable? Realistically, what problems are we protecting against? I can think of one or two. In the case of network boot, where the kernel and initrd served up via tftp, but the required filesystems are per host raid volumes served up ala ATAoverEthernet, iSCSI etc storage network. This could use the boot network device MAC or dhcp assigned hostname to as the homehost search paramater. This would of course require someway to tell mdadm how to obtain this homehost parameter. This could work well where different groups of hosts using different raid volumes for the root (or other) filesystems, each with a MAC group (first 3 or 4 MAC fields) is used to identify that groups homehost search parameter. To get AoE or iSCSI working you need networking. That means dhcp will already have run and the hostname be set. Another scenario, is a dual boot system that has separate raid volumes for the respective root filesystems, along with a separate initrd image for each OS. A system uuid stored in the initrd would work in this case for the homehost search parameter. Or virtualization with raid in the virtual hosts. The host system will see all the raids of the virtual systems but none of them should be started. MfG Goswin -- 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/87aav0pfz7@frosties.localdomain
Bug#567468: md homehost
martin f krafft madd...@madduck.net writes: also sprach Neil Brown ne...@suse.de [2010.02.23.0330 +0100]: The problem to protect against is any consequence of rearranging devices while the host is off, including attaching devices that previously were attached to a different computer. How often does this happen, and how grave/dangerous are the effects? But if '/' is mounted by a name in /dev/md/, I want to be sure mdadm puts the correct array at that name no matter what other arrays might be visible. Of course it would be nice if this happened, but wouldn't it be acceptable to assume that if someone swaps drives between machines that they ought to know how to deal with the consequences, or at least be ready to tae additional steps to make sure the system still boots as desired? Even if the wrong array appeared as /dev/md0 and was mounted as root device, is there any actual problem, other than inconvenience? Remember that the person who has previously swapped the drives is physically in front of (or behind ;)) the machine. I am unconvinced. I think we should definitely switch to using filesystem-UUIDs over device names, and that is the only real solution to the problem, no? Both filesystems and LVM have UUIDs. Does dm-crypt / LUKS have one too? MfG Goswin -- 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/87635opfwb@frosties.localdomain
Bug#556231: Bug #556231
Ooops... just seconds after my mail the server panic'd while xfsdumping to tape: Kernel panic - not syncing: xfs_fs_destroy_inode: cannot reclaim 0x8800642fcd80 Pid: 47, comm: kswapd0 Not tainted 2.6.32-2-amd64 #1 Call trace: [...] ? panic+0x86/0x141 [...] ? __up_write+0x12/0x45 [...] ? xfs_iunlock+0x42/0x7c [xfs] [...] ? xfs_reclaim_inode+x094/0x12e [xfs] [...] ? xfs_fs_destroy_inode+0x4b/0x4d [xfs] [...] ? dispose_list+0xce/0xfe [...] ? shrink_icache_memory+0x1f2/0x228 [...] ? shrink_slab+0xe0/0x153 [...] ? kswapd+0x4d9/0x683 [...] ? isolate_pages_global+0x0/0x20f [...] ? autoremove_wake_function+0x0/0x2e [...] ? kswapd+0x0/0x683 [...] ? kthread+0x79/0x81 [...] ? child_rip+0xa/0x20 [...] ? kthread+0x0/0x81 Looks like my issue is *not* fixed. smime.p7s Description: S/MIME Cryptographic Signature
