Bug#573144: Re: Bug#573144: linux-image-2.6-686: kernel freezes related to i915 handle error
So 2.6.32-3-686 freezes too. I don't know how to debug it, because kernel seems to be completely dead :( Zbynek Hello, I am experiencing the same problem in 2.6.32-5-686 and 2.6.34-1-686 on my Acer laptop with i855 chipset. System freezes randomly as described by Eric. I guess that 2.6.32-3-686 was fine, but I am not sure (have not this kernel anymore). Thanks, Zbynek -- 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/4734.521.833-18615-1273802685-1277802...@seznam.cz
Bug#578131: [linux-2.6] Copying big files to pendrive is deadly slow
Some facts: - Still present in linux-image-2.6.32-5-amd64. - Not present in linux-image-2.6.30-2-amd64. The transfer rate also drops after completing one third of the upload to the external device, but just to a reasonable 3.5 MB/s. - It seems to be filesystem-independent (I formatted my pendrive with vfat, ntfs and ext4) and device-independent (tested other external storage devices). - My buddy reports (on a different and more powerful Debian Squeeze amd64 box running 2.6.32-5) he is not experiencing anything unusual with transfer rates even using my own pendrive. So I guess there must be some combination of kernel and hardware issues. Regards, Antonio -- 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/201006291021.24484.a...@ipna.csic.es
Bug#586554: initramfs-tools fails to upgrade from 0.96.1 to 0.97
On Tue, Jun 29, 2010 at 09:05:55AM +0900, Olaf Meeuwissen wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Thanks for the info. I've checked the dash and bash manual pages but
running under errexit seems to be the same as using `set -e`. The hook
provided by iscan has done a `set -e` from the beginning so that can't
be the reason (unless I misunderstood the errexit stuff).
FTR, I've attached the hook scripts template. The @...@ stuff is
substituted at package build time.
hmm I don'T see at a quick look why it failed.
Hope this helps,
but I don't get it'S purpose?
why do you want mkinitramfs to clean some file in your statedir?
this seems the wrong location to do such
also why does it need udev (just a minor nit..)?
#! /bin/sh
# Copyright (C) 2009 SEIKO EPSON CORPORATION
#
# License: GPLv2+
state_d...@deb_configure_localstatedir@/lib/@DEB_SOURCE_PACKAGE@
set -e
PREREQS=udev
prereqs()
{
echo $PREREQS
}
case $1 in
prereqs)
prereqs
exit 0
;;
esac
. /usr/share/initramfs-tools/hook-functions
test -r $STATE_DIR/clean-files || exit 0
awk '{print $2}' $STATE_DIR/clean-files \
| while read file; do
test -e ${DESTDIR}$file rm -f ${DESTDIR}$file
done
--
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/20100629093312.ge9...@baikonur.stro.at
Bug#573144: Re: Bug#573144: linux-image-2.6-686: kernel freezes related to i915 handle error
On Tue, Jun 29, 2010 at 11:02:55AM +0200, Zbynek Michl wrote: So 2.6.32-3-686 freezes too. I don't know how to debug it, because kernel seems to be completely dead :( Zbynek did you check with latest experimental intel driver? also we will shortly make 2.6.35-rcX available. the old intel driver support is since some time messy, sorry for that. -- 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/20100629112911.gf9...@baikonur.stro.at
Re: [DRAFT] Policy for Linux kernel, initramfs, boot loader update process
On Mon, 28 Jun 2010 19:07:16 -0400 (EDT), Ben Hutchings wrote: Please reply to debian-kernel only. As you wish. I had reason to believe that some key players were probably not subscribed to debian-kernel. But they are now at least aware of the thread and can follow it further if they so desire. I have now subscribed to debian-kernel myself; so there is no need to CC me. On Mon, 2010-06-28 at 11:16 -0400, Stephen Powell wrote: On Sun, 27 Jun 2010 22:02:35 -0400 (EDT), Ben Hutchings wrote: [...] The environment variable DEB_MAINT_PARAMS will contain the arguments given to the kernel maintainer script, single-quoted. Is this environment variable provided by the maintainer scripts that come with kernel image packages created by make deb-pkg? (I honestly don't know. I've never used make deb-pkg.) It has done since 2.6.31, though without single-quotes. I'll note that they may or may not be quoted, and recommend how to use this variable. OK. [...] 5. Kernel and initramfs builder packages must not invoke boot loaders except via hooks. If /etc/kernel-img.conf contains an explicit 'do_bootloader = yes', kernel package maintainer scripts should warn that this is now ignored. At the risk of flogging a dead horse, I would prefer to see do_bootloader = yes supported until Squeeze+1, both by the kernel maintainer scripts and by update-initramfs -u, particularly since we are so close to a freeze. The release team has stated we are not close to a freeze. So we have a little time to sort this out. That's good. But if you're going to drop support for it in Squeeze, then yes, a warning message is necessary. Both the kernel maintainer scripts *and* update-initramfs -u *must* issue a warning message if they find do_bootloader = yes specified in /etc/kernel-img.conf. In fact, since the default value is yes, they should issue the warning message unless do_bootloader is *explicitly* set to no. I can put a one-time warning into linux-base. But the default for squeeze must be 'no'. It should not be necessary to create /etc/kernel-img.conf at all in squeeze. That's a good idea. I'm just concerned about migrations from a previous release where users may be relying on the implicit default to get their boot loader run. 6. The installer must not define do_bootloader, postinst_hook or postrm_hook in /etc/kernel-img.conf. Doesn't this conflict with point 4 (a)? Not at all. This means postinst_hook and postrm_hook are now strictly for use by the user. OK. -- .''`. Stephen Powell : :' : `. `'` `- -- 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/1129698791.34865.1277816465356.javamail.r...@md01.wow.synacor.com
Bug#570350: linux-image-2.6.26-2-amd64: kernel BUG at kernel/exit.c:822! PATCHES
The bug is still present in Google Chrome Stable version: 5.0.375.86 Ben Hutchings wrote: snip I think we should actually apply a second patch. So, please try the two attached patches snip Please test this fix by following the instructions at http://kernel-handbook.alioth.debian.org/ch-common-tasks.html#s-common-official I have enclosed those patches for the bug report. They were built on source containing linux-2.6_2.6.26-24.dsc and tested on two Amd SMPs: AMD Turion(tm) 64 X2 Mobile Technology TL-60 Quad-Core AMD Opteron(tm) Processor 1352 Prior to the patch I could sometimes force the kernel problem by opening Chrome say 4 times, open some sites, leave a while then closing all the chrome windows quickly. After two-ish days of pretty intense usage so far no repeat of the kernel BUG message. And for me these patches don't regress other things. BUT (and its a big BUT). Chrome 5 continues to use root setuid. So I doubt that this is the end of the kernel bug story. I have updated the Chrome fault log accordingly: http://code.google.com/p/chromium/issues/detail?id=35440 I really would be happier if there were no root setuid involved in a browser. Also I am not sure there is enough demand here to warrant a change to the production Debian kernels. Much as it hurts: The answer for me, at least until we understand a little more about the sandbox, is to simply avoid using Google Chrome. Wait and see? Berni From: Oleg Nesterov o...@tv-sign.ru Date: Tue, 2 Sep 2008 14:35:48 -0700 Subject: [PATCH 1/2] pid_ns: zap_pid_ns_processes: fix the -child_reaper changing commit add0d4dfd660e9e4fd0af3eac3cad23583c9558f upstream. zap_pid_ns_processes() sets pid_ns-child_reaper = NULL, this is wrong. Yes, we have already killed all tasks in this namespace, and sys_wait4() doesn't see any child. But this doesn't mean -children list is empty, we may have EXIT_DEAD tasks which are not visible to do_wait(). In that case the subsequent forget_original_parent() will crash the kernel because it will try to re-parent these tasks to the NULL reaper. Even if there are no childs, it is not good that forget_original_parent() uses reaper == NULL. Change the code to set -child_reaper = init_pid_ns.child_reaper instead. We could use pid_ns-parent-child_reaper as well, I think this does not really matter. These EXIT_DEAD tasks are not visible to the new -parent after re-parenting, they will silently do release_task() eventually. Note that we must change -child_reaper, otherwise forget_original_parent() will use reaper == father, and in that case we will hit the (correct) BUG_ON(!list_empty(father-children)). Signed-off-by: Oleg Nesterov o...@tv-sign.ru Acked-by: Serge Hallyn se...@us.ibm.com Acked-by: Sukadev Bhattiprolu suka...@linux.vnet.ibm.com Acked-by: Pavel Emelyanov xe...@openvz.org Signed-off-by: Andrew Morton a...@linux-foundation.org Signed-off-by: Linus Torvalds torva...@linux-foundation.org [bwh: Adjust context for 2.6.26] --- kernel/pid_namespace.c |9 ++--- 1 files changed, 6 insertions(+), 3 deletions(-) diff --git a/kernel/pid_namespace.c b/kernel/pid_namespace.c index ea567b7..598f1ee 100644 --- a/kernel/pid_namespace.c +++ b/kernel/pid_namespace.c @@ -182,9 +182,12 @@ void zap_pid_ns_processes(struct pid_namespace *pid_ns) rc = sys_wait4(-1, NULL, __WALL, NULL); } while (rc != -ECHILD); - - /* Child reaper for the pid namespace is going away */ - pid_ns-child_reaper = NULL; + /* + * We can not clear -child_reaper or leave it alone. + * There may by stealth EXIT_DEAD tasks on -children, + * forget_original_parent() must move them somewhere. + */ + pid_ns-child_reaper = init_pid_ns.child_reaper; return; } From: Oleg Nesterov o...@tv-sign.ru Date: Tue, 2 Sep 2008 14:35:49 -0700 Subject: [PATCH 2/2] pid_ns: (BUG 11391) change -child_reaper when init-group_leader exits commit 950bbabb5a804690a0201190de5c22837f72f83f upstream. We don't change pid_ns-child_reaper when the main thread of the subnamespace init exits. As Robert Rex robert@exasol.com pointed out this is wrong. Yes, the re-parenting itself works correctly, but if the reparented task exits it needs -parent-nsproxy-pid_ns in do_notify_parent(), and if the main thread is zombie its -nsproxy was already cleared by exit_task_namespaces(). Introduce the new function, find_new_reaper(), which finds the new -parent for the re-parenting and changes -child_reaper if needed. Kill the now unneeded exit_child_reaper(). Also move the changing of -child_reaper from zap_pid_ns_processes() to find_new_reaper(), this consolidates the games with -child_reaper and makes it stable under tasklist_lock. Addresses http://bugzilla.kernel.org/show_bug.cgi?id=11391 Reported-by: Robert Rex robert@exasol.com Signed-off-by: Oleg Nesterov o...@tv-sign.ru Acked-by: Serge Hallyn se...@us.ibm.com Acked-by: Pavel Emelyanov xe...@openvz.org Acked-by: Sukadev Bhattiprolu suka...@linux.vnet.ibm.com Signed-off-by: Andrew Morton
Bug#570350: linux-image-2.6.26-2-amd64: kernel BUG at kernel/exit.c:822!
Just a snippet on the Google Sandbox. From here: http://blog.chromium.org/2008/10/new-approach-to-browser-security-google.html The entire HTML rendering and JavaScript execution is isolated to its own class of processes; the renderers. These are the ones that live in the sandbox. ...perhaps this should be discussed elsewhere. 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/4c2a12f6.40...@elbournb.fsnet.co.uk
Bug#570350: pid_ns child_reaper fixes for 2.6.26
On 06/29, Ben Hutchings wrote: I've attempted to cherry-pick and adjust these for 2.6.26; patches below. Do these look reasonable or are additional changes required? Confused. please see below. Subject: [PATCH 1/2] pid_ns: zap_pid_ns_processes: fix the -child_reaper changing commit add0d4dfd660e9e4fd0af3eac3cad23583c9558f upstream. ... @@ -182,9 +182,12 @@ void zap_pid_ns_processes(struct pid_namespace *pid_ns) rc = sys_wait4(-1, NULL, __WALL, NULL); } while (rc != -ECHILD); - - /* Child reaper for the pid namespace is going away */ - pid_ns-child_reaper = NULL; + /* + * We can not clear -child_reaper or leave it alone. + * There may by stealth EXIT_DEAD tasks on -children, + * forget_original_parent() must move them somewhere. + */ + pid_ns-child_reaper = init_pid_ns.child_reaper; This is correct, but the second patch @@ -182,12 +182,6 @@ void zap_pid_ns_processes(struct pid_namespace *pid_ns) rc = sys_wait4(-1, NULL, __WALL, NULL); } while (rc != -ECHILD); - /* - * We can not clear -child_reaper or leave it alone. - * There may by stealth EXIT_DEAD tasks on -children, - * forget_original_parent() must move them somewhere. - */ - pid_ns-child_reaper = init_pid_ns.child_reaper; Removes this code? This doesn't look right, or I missed something. I think you are right, you need these 2 commits 950bbabb5a804690a0201190de5c22837f72f83f add0d4dfd660e9e4fd0af3eac3cad23583c9558f (in that order). I'd suggest you to adjust these commits and make a single patch. In that case I can try to see if it is correct against the 2.6.26. Oleg. -- 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/20100629152336.ga13...@redhat.com
Bug#573144: Re: Bug#573144: Re: Bug#573144: linux-image-2.6-686: kernel freezes related to i915 handle error
On Tue, Jun 29, 2010 at 11:02:55AM +0200, Zbynek Michl wrote: So 2.6.32-3-686 freezes too. I don't know how to debug it, because kernel seems to be completely dead :( Zbynek did you check with latest experimental intel driver? I have tried the latest 2.6.34-1-686_2.6.34-1~experimental.2_i386 with no luck. also we will shortly make 2.6.35-rcX available. the old intel driver support is since some time messy, sorry for that. Do you think intel driver in the kernel? Couldn't be there any connection with x.org driver (xserver-xorg-video-radeon in my case)? Thanks, Zbynek -- 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/4746.521.833-24801-1944936096-1277825...@seznam.cz
Bug#570350: linux-image-2.6.26-2-amd64: kernel BUG at kernel/exit.c:822! PATCHES
On 29 Jun 2010, be...@elbournb.fsnet.co.uk wrote: [ SNIP ] I really would be happier if there were no root setuid involved in a browser. Also I am not sure there is enough demand here to warrant a change to the production Debian kernels. Much as it hurts: The answer for me, at least until we understand a little more about the sandbox, is to simply avoid using Google Chrome. I totally have to agree with both statements above! /Georg -- 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/87mxudg3ie@big.home.gb
Problem with applying debian kernel patches
Hi, when I try to apply kernel patches I got the following error message: # ../kernel-patches/all/2.6.26/apply/debian -a amd64 -f vserver 21 -- Try to unapply 24. ... (+) OK bugfix/all/signal-fix-information-leak-with-print-fatal-signals.patch (+) OK bugfix/all/mac80211-fix-spurious-delBA-handling.patch -- 21lenny1 fully unapplied. -- Try to apply 1-extra. -- 1-extra fully applied. -- Try to apply 3-extra. 1 out of 5 hunks FAILED -- saving rejects to file mm/mremap.c.rej (+) FAIL features/all/vserver/vs2.3.0.35.patch Error: Patch failed I tried this on an fully update debian lenny. ii linux-image-2.6.26-2-vserver-amd64 2.6.26-24 Linux 2.6.26 image on AMD64, Linux-VServer s ii linux-libc-dev 2.6.26-24 Linux support headers for userspace developm ii linux-patch-debian-2.6.26 2.6.26-24 Debian patches to version 2.6.26 of the Linu ii linux-source-2.6.26 2.6.26-24 Linux kernel source for version 2.6.26 with ii linux-support-2.6.26-2 2.6.26-24 Support files for Linux 2.6.26 As far as I remember that worked in previous versions. Regards, Matthias -- 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/16c8cf336ee16d12ad6e40b240dcc...@127.0.0.1
Re: [DRAFT] Policy for Linux kernel, initramfs, boot loader update process
On Mon, 28 Jun 2010 19:07:16 -0400 (EDT), Ben Hutchings wrote: ... I can put a one-time warning into linux-base. But the default for squeeze must be 'no'. It should not be necessary to create /etc/kernel-img.conf at all in squeeze. Sorry I didn't think of this the first time, but there are up to four steps to preparing a kernel for booting: (1) Installation of the kernel itself (2) Creation of an initial RAM file system (3) Updating symbolic links (4) Running the boot loader installer Not all steps are required in all cases, depending on the circumstances. Neither grub version 1 nor grub version 2 generally use symbolic links; so that hasn't been on the forefront of most people's minds. Strictly speaking, the historic boot loaders such as lilo and zipl don't *have* to use symbolic links, but as they have historically been used in Debian systems, they generally do. Obviously, item 1 takes care of itself. For stock kernels, item 2 also takes care of itself. And it appears that the latest version of initramfs-tools provides hook scripts of the same name in /etc/kernel/postinst.d and /etc/kernel/postrm.d which take care of item 2 for kernel image packages created by make-kpkg and make deb-pkg as well. (Actually, that item does need some work, but I'll come back to that later. For now, let's assume that item 2 is taken care of.) Item 4 is what we've been talking about. Each boot loader that needs some kind of update will have to provide a hook script starting with zz-. Now the question is, what should we do about item 3, maintaining the symlinks? For stock kernels, that has historically been handled by variables in /etc/kernel-img.conf: do_symlinks, relative_links, and link_in_boot, mainly, though there are other seldom-used variations. But you just said that the goal was to be able to eliminate /etc/kernel-img.conf. So what do we do about symlinks? Fortunately, the update-initramfs -u issue doesn't affect the symlinks. The symlinks only need to be maintained, if at all, when a kernel is installed, updated, or removed. The symlinks are not, strictly speaking, associated with a package. Should the boot loader script take care of it? Or should this be a separate script? What do you think? I said I would come back to initramfs-tools; so now I'm back. There are two issues with the script as written today. (1) it does not redirect standard output to standard error when invoking update-initramfs. Thus, the user sees no output (since debconf swallows it) and, depending on the output, it may cause problems for debconf. (2) it unconditionally creates an initial RAM file system for kernel image packages created by make-kpkg, even if the user doesn't want one. There is a way to check to see if one is needed. I can submit a revised version of the script if you like. Would you like me to do so? -- .''`. Stephen Powell : :' : `. `'` `- -- 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/1783519414.48436.1277843088409.javamail.r...@md01.wow.synacor.com
Re: [DRAFT] Policy for Linux kernel, initramfs, boot loader update process
On Tue, Jun 29, 2010 at 04:24:48PM -0400, Stephen Powell wrote: On Mon, 28 Jun 2010 19:07:16 -0400 (EDT), Ben Hutchings wrote: ... I can put a one-time warning into linux-base. But the default for squeeze must be 'no'. It should not be necessary to create /etc/kernel-img.conf at all in squeeze. Sorry I didn't think of this the first time, but there are up to four steps to preparing a kernel for booting: (1) Installation of the kernel itself (2) Creation of an initial RAM file system (3) Updating symbolic links they are deprecated and shouldn't be necessary. there are even more evil incarnations like reverse symlinks or whatever. which we no longer support since longer.. it be better to just get rid of them. (4) Running the boot loader installer Not all steps are required in all cases, depending on the circumstances. Neither grub version 1 nor grub version 2 generally use symbolic links; so that hasn't been on the forefront of most people's minds. Strictly speaking, the historic boot loaders such as lilo and zipl don't *have* to use symbolic links, but as they have historically been used in Debian systems, they generally do. Obviously, item 1 takes care of itself. For stock kernels, item 2 also takes care of itself. And it appears that the latest version of initramfs-tools provides hook scripts of the same name in /etc/kernel/postinst.d and /etc/kernel/postrm.d which take care of item 2 for kernel image packages created by make-kpkg and make deb-pkg as well. (Actually, that item does need some work, but I'll come back to that later. For now, let's assume that item 2 is taken care of.) Item 4 is what we've been talking about. Each boot loader that needs some kind of update will have to provide a hook script starting with zz-. Now the question is, what should we do about item 3, maintaining the symlinks? For stock kernels, that has historically been handled by variables in /etc/kernel-img.conf: do_symlinks, relative_links, and link_in_boot, mainly, though there are other seldom-used variations. But you just said that the goal was to be able to eliminate /etc/kernel-img.conf. So what do we do about symlinks? Fortunately, the update-initramfs -u issue doesn't affect the symlinks. The symlinks only need to be maintained, if at all, when a kernel is installed, updated, or removed. The symlinks are not, strictly speaking, associated with a package. Should the boot loader script take care of it? Or should this be a separate script? What do you think? get rid of them. they are ugly and useless. I said I would come back to initramfs-tools; so now I'm back. There are two issues with the script as written today. (1) it does not redirect standard output to standard error when invoking update-initramfs. Thus, the user sees no output (since debconf swallows it) and, depending on the output, it may cause problems for debconf. (2) it unconditionally creates an initial RAM file system for kernel image packages created by make-kpkg, even if the user doesn't want one. There is a way to check to see if one is needed. I can submit a revised version of the script if you like. Would you like me to do so? hate those indirections due to debconf magic, but why would the hook scripts need one. thanks for hints, been staying away from debconf for long.. the unconditional is expected and there is a wishlist bug open for that it has not high priority as many things do not work if you don'T use an initramfs. thanks ps if you want the no cc thing set up your mua appropriately. here in d-kernel we do cc. -- 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/20100629203540.gh9...@baikonur.stro.at
Bug#582177: grub-pc: system with RAID CRYPTO; system with problem to be deactivated August 2010
Sirs and Dames: The system that has the problem discussed under bug #'s 582177 and 582342 will be deactivated the second week of August 2010. It will not be reactivated until October 2010; it might be cannibalized. Should you want me to do anymore major smoke-tests on this bug, I will gladly do two-to-three more until the computer is deactivated. Please get any tests or instructions to me soon. Regards, C. Cropper -- 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/201006291645.33819.crop...@acm.org
Bug#582177: grub-pc: system with RAID CRYPTO; system with problem to be deactivated August 2010
On Tue, Jun 29, 2010 at 04:45:33PM -0400, crop...@acm.org wrote: Sirs and Dames: The system that has the problem discussed under bug #'s 582177 and 582342 will be deactivated the second week of August 2010. It will not be reactivated until October 2010; it might be cannibalized. Should you want me to do anymore major smoke-tests on this bug, I will gladly do two-to-three more until the computer is deactivated. Please get any tests or instructions to me soon. afaik this is a grub2 bug, please update to latest available grub2 in sid and do grub-install /dev/sda grub-install /dev/sdb .. (dont' remember how many discs you have) update-grub and then try to reboot, 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/20100629204438.gi9...@baikonur.stro.at
Bug#581596: linux-2.6: pxe-booting a qemu-kvm or kvm guest with virtio network (fai-client) produces kernel panic
Hallo, it's not a kernel problem. When installing the newer initramfs-tools from official lenny fai repo (http://www.informatik.uni-koeln.de/fai/download/lenny/, initramfs-tools_0.93.4-grml02_all.deb) pxe boots fine with virtio-net guests (both with plain lenny 2.6.26... and backported 2.6.32 from squeeze). Possibly you want to assign this bug initramfs-tools. Cheers Holger Fischer -- 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/4c2a67dc.4060...@web.de
Bug#581596: linux-2.6: pxe-booting a qemu-kvm or kvm guest with virtio network (fai-client) produces kernel panic
On Tue, Jun 29, 2010 at 11:38:36PM +0200, Holger Fischer wrote: Hallo, it's not a kernel problem. When installing the newer initramfs-tools from official lenny fai repo (http://www.informatik.uni-koeln.de/fai/download/lenny/, initramfs-tools_0.93.4-grml02_all.deb) pxe boots fine with virtio-net guests (both with plain lenny 2.6.26... and backported 2.6.32 from squeeze). Possibly you want to assign this bug initramfs-tools. newer initramfs-tools has several network boot fixes indeed. can you please test that it works with latest 0.97 in squeeze. that one should install just fine in lenny. 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/20100629215737.gj9...@baikonur.stro.at
Bug#488566: some info
On Tue, 2010-06-29 at 18:52 +, Fito . wrote: From: b...@decadent.org.uk To: binaura...@hotmail.com CC: 488...@bugs.debian.org Date: Tue, 29 Jun 2010 00:42:23 +0100 Subject: RE: Bug#488566: some info Please reply to all. On Mon, 2010-06-28 at 19:03 +, Fito . wrote: hello ben. sorry, but i fail to build the kernel package base on the guide you sent me. but it was probably just because my incompetence in the subject and the complete lack of experience on linux (and no programming knowledge whatsoever for that matter). i tried under my debian testing system (i used the squeeze patch), the kernel was compile but upon install there was a dependency that failed to comply. What was the error message? i don't remember exactly but i think that when dpkg -i linux-image... it asked for linux-base-2.6.32-15test or somethimg like that... Oh, I see. I should change the source package so that it doesn't get that dependency. before that when i tried to compile acording the steps on the page you sent me, i had to install gcc 4.3, although gcc 4.4 was already install. just commenting in case this means anything to you... I think that should have been installed by 'apt-get build-dep linux-2.6'. However, if you also have experimental sources then that may not do what we want. [...] then compile with make-kpkg, then i installed the linux image, everything went smoothly. rebooted, loaded new kernel, tested burning cd process, it worked. =) if any more info or testing is needed i'll gladly comply. Did you verify that the contents of the CD were correct? When you burned CDs previously with this computer, were they always corrupted? Ben. -- Ben Hutchings Once a job is fouled up, anything done to improve it makes it worse. signature.asc Description: This is a digitally signed message part
Bug#584744: linux-2.6: radeonfb builtin on sparc and powerpc
On Sun, Jun 6, 2010 at 14:36:12 +0200, Bastian Blank wrote: On Sun, Jun 06, 2010 at 11:07:51AM +0200, Julien Cristau wrote: the sid kernel has radeonfb builtin on some archs: debian/config/powerpc/config:CONFIG_FB_RADEON=y debian/config/sparc/config:CONFIG_FB_RADEON=y This is likely to conflict with the fb provided by the radeon drm driver with kms. Maybe they can be made =m instead? That is a problem. Both powerpc and sparc have no text console. So do you have another suggestion to avoid the conflict? Cheers, Julien signature.asc Description: Digital signature
Bug#570350: pid_ns child_reaper fixes for 2.6.26
On Tue, 2010-06-29 at 17:23 +0200, Oleg Nesterov wrote:
On 06/29, Ben Hutchings wrote:
I've attempted to cherry-pick and adjust these for 2.6.26; patches
below. Do these look reasonable or are additional changes required?
Confused. please see below.
Subject: [PATCH 1/2] pid_ns: zap_pid_ns_processes: fix the -child_reaper
changing
commit add0d4dfd660e9e4fd0af3eac3cad23583c9558f upstream.
...
@@ -182,9 +182,12 @@ void zap_pid_ns_processes(struct pid_namespace *pid_ns)
rc = sys_wait4(-1, NULL, __WALL, NULL);
} while (rc != -ECHILD);
-
- /* Child reaper for the pid namespace is going away */
- pid_ns-child_reaper = NULL;
+ /*
+* We can not clear -child_reaper or leave it alone.
+* There may by stealth EXIT_DEAD tasks on -children,
+* forget_original_parent() must move them somewhere.
+*/
+ pid_ns-child_reaper = init_pid_ns.child_reaper;
This is correct, but the second patch
@@ -182,12 +182,6 @@ void zap_pid_ns_processes(struct pid_namespace *pid_ns)
rc = sys_wait4(-1, NULL, __WALL, NULL);
} while (rc != -ECHILD);
- /*
-* We can not clear -child_reaper or leave it alone.
-* There may by stealth EXIT_DEAD tasks on -children,
-* forget_original_parent() must move them somewhere.
-*/
- pid_ns-child_reaper = init_pid_ns.child_reaper;
Removes this code?
That's what your commit 950bbabb5a804690a0201190de5c22837f72f83f did.
This doesn't look right, or I missed something.
I think you are right, you need these 2 commits
950bbabb5a804690a0201190de5c22837f72f83f
add0d4dfd660e9e4fd0af3eac3cad23583c9558f
(in that order).
That is the opposite of the order in which they were originally applied!
I'd suggest you to adjust these commits and make
a single patch. In that case I can try to see if it is correct
against the 2.6.26.
The combined diff is:
--- a/kernel/exit.c
+++ b/kernel/exit.c
@@ -758,23 +758,48 @@ static void reparent_thread(struct task_struct *p, struct
task_struct *father)
* the child reaper process (ie init) in our pid
* space.
*/
+static struct task_struct *find_new_reaper(struct task_struct *father)
+{
+ struct pid_namespace *pid_ns = task_active_pid_ns(father);
+ struct task_struct *thread;
+
+ thread = father;
+ while_each_thread(father, thread) {
+ if (thread-flags PF_EXITING)
+ continue;
+ if (unlikely(pid_ns-child_reaper == father))
+ pid_ns-child_reaper = thread;
+ return thread;
+ }
+
+ if (unlikely(pid_ns-child_reaper == father)) {
+ write_unlock_irq(tasklist_lock);
+ if (unlikely(pid_ns == init_pid_ns))
+ panic(Attempted to kill init!);
+
+ zap_pid_ns_processes(pid_ns);
+ write_lock_irq(tasklist_lock);
+ /*
+* We can not clear -child_reaper or leave it alone.
+* There may by stealth EXIT_DEAD tasks on -children,
+* forget_original_parent() must move them somewhere.
+*/
+ pid_ns-child_reaper = init_pid_ns.child_reaper;
+ }
+
+ return pid_ns-child_reaper;
+}
+
static void forget_original_parent(struct task_struct *father)
{
- struct task_struct *p, *n, *reaper = father;
+ struct task_struct *p, *n, *reaper;
struct list_head ptrace_dead;
INIT_LIST_HEAD(ptrace_dead);
write_lock_irq(tasklist_lock);
+ reaper = find_new_reaper(father);
- do {
- reaper = next_thread(reaper);
- if (reaper == father) {
- reaper = task_child_reaper(father);
- break;
- }
- } while (reaper-flags PF_EXITING);
-
/*
* There are only two places where our children can be:
*
@@ -929,39 +954,6 @@ static void check_stack_usage(void)
static inline void check_stack_usage(void) {}
#endif
-static inline void exit_child_reaper(struct task_struct *tsk)
-{
- if (likely(tsk-group_leader != task_child_reaper(tsk)))
- return;
-
- if (tsk-nsproxy-pid_ns == init_pid_ns)
- panic(Attempted to kill init!);
-
- /*
-* @tsk is the last thread in the 'cgroup-init' and is exiting.
-* Terminate all remaining processes in the namespace and reap them
-* before exiting @tsk.
-*
-* Note that @tsk (last thread of cgroup-init) may not necessarily
-* be the child-reaper (i.e main thread of cgroup-init) of the
-* namespace i.e the child_reaper may have already exited.
-*
-* Even after a child_reaper exits, we let it inherit orphaned children,
-* because, pid_ns-child_reaper remains valid as long as there is
-* at least one living sub-thread in the cgroup init.
-
-
Processed: tagging 581596
Processing commands for cont...@bugs.debian.org: tags 581596 moreinfo Bug #581596 [linux-2.6] linux-2.6: pxe-booting a qemu-kvm or kvm guest with virtio network (fai-client) produces kernel panic Added tag(s) moreinfo. thanks Stopping processing here. Please contact me if you need assistance. -- 581596: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=581596 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/handler.s.c.127785155218082.transcr...@bugs.debian.org
Processed: reassign 581596 to initramfs-tools
Processing commands for cont...@bugs.debian.org: reassign 581596 initramfs-tools Bug #581596 [linux-2.6] linux-2.6: pxe-booting a qemu-kvm or kvm guest with virtio network (fai-client) produces kernel panic Bug reassigned from package 'linux-2.6' to 'initramfs-tools'. Bug No longer marked as found in versions 2.6.32-12. thanks Stopping processing here. Please contact me if you need assistance. -- 581596: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=581596 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/handler.s.c.127785155918141.transcr...@bugs.debian.org
Re: Problem with applying debian kernel patches
On Tue, 2010-06-29 at 22:22 +0200, Matthias Rieber wrote: Hi, when I try to apply kernel patches I got the following error message: # ../kernel-patches/all/2.6.26/apply/debian -a amd64 -f vserver 21 -- Try to unapply 24. ... (+) OK bugfix/all/signal-fix-information-leak-with-print-fatal-signals.patch (+) OK bugfix/all/mac80211-fix-spurious-delBA-handling.patch -- 21lenny1 fully unapplied. -- Try to apply 1-extra. -- 1-extra fully applied. -- Try to apply 3-extra. 1 out of 5 hunks FAILED -- saving rejects to file mm/mremap.c.rej (+) FAIL features/all/vserver/vs2.3.0.35.patch Error: Patch failed I tried this on an fully update debian lenny. [...] This feature (reconstruction of previous versions) exists in order to fulfil the requirement that we provide sources for the binary kernel packages used in the installer, which may lag behind the kernel packages that are actually installed. This requirement does not apply to 'featureset' binary packages, since they are not used in the installer. It is sometimes necessary to adjust the featureset patches to avoid conflicts with other patches that are used for all kernel packages. This then means that it is no longer possible to reconstruct older versions of the featureset. You can get the old versions from snapshot.debian.org or from our svn repository. Ben. -- Ben Hutchings Once a job is fouled up, anything done to improve it makes it worse. signature.asc Description: This is a digitally signed message part
Bug#587580: linux-source-2.6.32: bonding (ifenslave) does not work with asix based usb-network-adapter (ax88178)
Package: linux-source-2.6.32
Severity: normal
Tags: patch
Hallo,
This patch from git.kernel.org fixes setting of mac address of asix usb-net
adapters,
MAC address setting is needed by ifenslave (mode active/backup).
Without this patch bonding seems to work with my ax88178 based,
but when making this device the active no packets are transmitted.
Switching back to the primary active device (e1000) works - no errors, oops,
panic.
When applying this patch to the current squeeze kernel sources (2.6.32-15),
compiling and installing it, the ax88178 based adapter works as expected in
bonding mode active/backup.
This works also on a lenny system with the backported squeeze kernel.
It would be nice if this patch could be included in squeeze.
P.S. Possibly this is related to bug 444043.
Thanks
Holger Fischer
diff --git a/drivers/net/usb/asix.c b/drivers/net/usb/asix.c
index 20e3460..9e05639 100644
--- a/drivers/net/usb/asix.c
+++ b/drivers/net/usb/asix.c
@@ -54,6 +54,7 @@ static const char driver_name [] = asix;
#define AX_CMD_WRITE_IPG0 0x12
#define AX_CMD_WRITE_IPG1 0x13
#define AX_CMD_READ_NODE_ID0x13
+#define AX_CMD_WRITE_NODE_ID 0x14
#define AX_CMD_WRITE_IPG2 0x14
#define AX_CMD_WRITE_MULTI_FILTER 0x16
#define AX88172_CMD_READ_NODE_ID 0x17
@@ -165,6 +166,7 @@ static const char driver_name [] = asix;
/* This structure cannot exceed sizeof(unsigned long [5]) AKA 20 bytes */
struct asix_data {
u8 multi_filter[AX_MCAST_FILTER_SIZE];
+ u8 mac_addr[ETH_ALEN];
u8 phymode;
u8 ledmode;
u8 eeprom_len;
@@ -732,6 +734,30 @@ static int asix_ioctl (struct net_device *net, struct
ifreq *rq, int cmd)
return generic_mii_ioctl(dev-mii, if_mii(rq), cmd, NULL);
}
+static int asix_set_mac_address(struct net_device *net, void *p)
+{
+ struct usbnet *dev = netdev_priv(net);
+ struct asix_data *data = (struct asix_data *)dev-data;
+ struct sockaddr *addr = p;
+
+ if (netif_running(net))
+ return -EBUSY;
+ if (!is_valid_ether_addr(addr-sa_data))
+ return -EADDRNOTAVAIL;
+
+ memcpy(net-dev_addr, addr-sa_data, ETH_ALEN);
+
+ /* We use the 20 byte dev-data
+* for our 6 byte mac buffer
+* to avoid allocating memory that
+* is tricky to free later */
+ memcpy(data-mac_addr, addr-sa_data, ETH_ALEN);
+ asix_write_cmd_async(dev, AX_CMD_WRITE_NODE_ID, 0, 0, ETH_ALEN,
+ data-mac_addr);
+
+ return 0;
+}
+
/* We need to override some ethtool_ops so we require our
own structure so we don't interfere with other usbnet
devices that may be connected at the same time. */
@@ -919,7 +945,7 @@ static const struct net_device_ops ax88772_netdev_ops = {
.ndo_start_xmit = usbnet_start_xmit,
.ndo_tx_timeout = usbnet_tx_timeout,
.ndo_change_mtu = usbnet_change_mtu,
- .ndo_set_mac_address= eth_mac_addr,
+ .ndo_set_mac_address= asix_set_mac_address,
.ndo_validate_addr = eth_validate_addr,
.ndo_do_ioctl = asix_ioctl,
.ndo_set_multicast_list = asix_set_multicast,
@@ -1213,7 +1239,7 @@ static const struct net_device_ops ax88178_netdev_ops = {
.ndo_stop = usbnet_stop,
.ndo_start_xmit = usbnet_start_xmit,
.ndo_tx_timeout = usbnet_tx_timeout,
- .ndo_set_mac_address= eth_mac_addr,
+ .ndo_set_mac_address= asix_set_mac_address,
.ndo_validate_addr = eth_validate_addr,
.ndo_set_multicast_list = asix_set_multicast,
.ndo_do_ioctl = asix_ioctl,
-- System Information:
Debian Release: squeeze/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.32-5-amd64 (SMP w/1 CPU core)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
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/20100630003302.3736.66637.report...@hoogrzulisv001.intern.hoonet.org
Bug#581596: linux-2.6: pxe-booting a qemu-kvm or kvm guest with virtio network (fai-client) produces kernel panic
* maximilian attems m...@stro.at [Die Jun 29, 2010 at 11:57:38 +0200]: On Tue, Jun 29, 2010 at 11:38:36PM +0200, Holger Fischer wrote: it's not a kernel problem. When installing the newer initramfs-tools from official lenny fai repo (http://www.informatik.uni-koeln.de/fai/download/lenny/, initramfs-tools_0.93.4-grml02_all.deb) pxe boots fine with virtio-net guests (both with plain lenny 2.6.26... and backported 2.6.32 from squeeze). Possibly you want to assign this bug initramfs-tools. newer initramfs-tools has several network boot fixes indeed. can you please test that it works with latest 0.97 in squeeze. that one should install just fine in lenny. JFTR: initramfs-tools 0.93.4-grml02 was just a Q/A build of initramfs-tools's git tree (and the incorporated Q/A stuff is merged upstream nowadays), so I expect that initramfs-tools 0.97 works just as expected. I'll make sure that the FAI repository provides initramfs-tools version =0.97 as well. regards, -mika- - with both his grml and initramfs-tools hat on signature.asc Description: Digital signature
Re: Call for Testing: initramfs-tools 0.97
* Joachim Wiedorn ad_deb...@joonet.de [Sun Jun 27, 2010 at 05:03:02PM +0200]: Michael Prokop m...@debian.org wrote on 2010-06-18 23:48: we - the initramfs-tools maintainers in Debian - want to provide a solid initramfs-tools version for squeeze. The new release 0.97 is expected to fix many longstanding problems. It would be great if we could receive feedback from testers. The new release is available from Debian/unstable and is expected to install without problems in at least lenny, squeeze and sid: http://cdn.debian.net/debian/pool/main/i/initramfs-tools/initramfs-tools_0.97_all.deb SHA256:56eb56d472d0dd24c8f2fd030222586e258ec882b716f02d114865cef9c19639 No matter how your partition layout looks like (rootfs on lvm, crypto, sw-raid,...), if you're booting on physical hardware or a virtualized system (Xen, openvz, kvm,...) - please give it a shot and report any possible problems. I have checked the scripts and I was very happy to see that lilo is furthermore supported by initramfs-tools (script update-initramfs). Can I be sure that this support stay in your package? Because of changes in some other packages this would be nearly an existential question. Sorry for the delay in answering, we discussed that in the team. Conclusion: no, we - as in initramfs-tools maintainers - won't support that. The mechanism will change with run-parts execution of /etc/initramfs hooks - the bootloader will add initramfs hooks. As explanation for the no see thread with subject [DRAFT] Policy for Linux kernel, initramfs, boot loader update process (Message-ID: 1277690555.26161.532.ca...@localhost) on debian-devel. (I'm aware that you - Joachim - already mailed in that thread and are aware of it therefore, I'm mentioning it here JFTR.) regards, -mika- signature.asc Description: Digital signature
Bug#586554: initramfs-tools fails to upgrade from 0.96.1 to 0.97
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2010年06月29日 18:33, maximilian attems wrote: FTR, I've attached the hook scripts template. The @...@ stuff is substituted at package build time. hmm I don'T see at a quick look why it failed. but I don't get it'S purpose? why do you want mkinitramfs to clean some file in your statedir? this seems the wrong location to do such The script attempts to prevent unneeded udev rules from getting into the initramfs. At one point iscan shipped a botched udev rules file that could prevent your machine from booting up when included. Ever since we got a bit more careful. The rules files takes care of configuring supported scanner devices. We don't see any reason you would need access to your scanner at the boot stage where an initramfs is used. FWIW, the file in our statedir lists files we don't want to end up in the DESTDIR. also why does it need udev (just a minor nit..)? There is nothing to be done if udev is not installed. Hope this helps, - -- Olaf Meeuwissen, LPIC-2 FLOSS Engineer -- AVASYS CORPORATION FSF Associate Member #1962 Help support software freedom http://www.fsf.org/jf?referrer=1962 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkwqfUMACgkQt5qrxaZLMnIaogCgqo3xL6XMFnJPnSD693pC2AOf jQgAoJu8OhnabDXBdGkwbkDKEGdoitI2 =9e2n -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c2a7d43.7020...@avasys.jp
Processed: tagging 587580
Processing commands for cont...@bugs.debian.org: # Automatically generated email from bts, devscripts version 2.10.35lenny7 tags 587580 + pending Bug #587580 [linux-source-2.6.32] linux-source-2.6.32: bonding (ifenslave) does not work with asix based usb-network-adapter (ax88178) Added tag(s) pending. End of message, stopping processing here. Please contact me if you need assistance. -- 587580: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=587580 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/handler.s.c.12778597401289.transcr...@bugs.debian.org
Bug#587580: linux-source-2.6.32: bonding (ifenslave) does not work with asix based usb-network-adapter (ax88178)
On Wed, 2010-06-30 at 02:33 +0200, Holger Fischer wrote: Package: linux-source-2.6.32 Severity: normal Tags: patch Hallo, This patch from git.kernel.org fixes setting of mac address of asix usb-net adapters, MAC address setting is needed by ifenslave (mode active/backup). Without this patch bonding seems to work with my ax88178 based, but when making this device the active no packets are transmitted. I think you'll find the problem is with receiving, not transmitting. MACs will transmit frames with any source address, but normally discard received frames where the destination address doesn't match. Switching back to the primary active device (e1000) works - no errors, oops, panic. When applying this patch to the current squeeze kernel sources (2.6.32-15), compiling and installing it, the ax88178 based adapter works as expected in bonding mode active/backup. This works also on a lenny system with the backported squeeze kernel. It would be nice if this patch could be included in squeeze. It will be. In future, please specify the git commit id if you know it, as this makes it easier to find all the details of the change. P.S. Possibly this is related to bug 444043. No, that was a different problem. Ben. -- Ben Hutchings Once a job is fouled up, anything done to improve it makes it worse. signature.asc Description: This is a digitally signed message part
Processed: reassign 585655 to src:libsdl1.2 ...
Processing commands for cont...@bugs.debian.org: reassign 585655 src:libsdl1.2 Bug #585655 [linux-2.6] linux-image-2.6-686: 2xwireless 360 gamepads arent working. Please can hardware works under LINUX for once ? Bug #585656 [linux-2.6] xpad: xpad does not work with joysticks : it makes 4 input joysticks instead of ONE ! Bug reassigned from package 'linux-2.6' to 'src:libsdl1.2'. Bug reassigned from package 'linux-2.6' to 'src:libsdl1.2'. Bug No longer marked as found in versions 2.6.32-9. Bug No longer marked as found in versions 2.6.32-9. retitle 585655 libsdl can fail to enumerate XBox 360 wireless controllers Bug #585655 [src:libsdl1.2] linux-image-2.6-686: 2xwireless 360 gamepads arent working. Please can hardware works under LINUX for once ? Bug #585656 [src:libsdl1.2] xpad: xpad does not work with joysticks : it makes 4 input joysticks instead of ONE ! Changed Bug title to 'libsdl can fail to enumerate XBox 360 wireless controllers' from 'linux-image-2.6-686: 2xwireless 360 gamepads arent working. Please can hardware works under LINUX for once ?' Changed Bug title to 'libsdl can fail to enumerate XBox 360 wireless controllers' from 'xpad: xpad does not work with joysticks : it makes 4 input joysticks instead of ONE !' thanks Stopping processing here. Please contact me if you need assistance. -- 585655: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=585655 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/handler.s.c.127786220016144.transcr...@bugs.debian.org
Bug#488566: some info
Forwarded Message From: Fito . binaura...@hotmail.com To: b...@decadent.org.uk Subject: RE: Bug#488566: some info Date: Wed, 30 Jun 2010 01:54:56 + Sorry, I can't reply in the BTS, I don't work with emails so I just use the web mail service. I think that should have been installed by 'apt-get build-dep linux-2.6'. However, if you also have experimental sources then that may not do what we want. Mmm, I don't know anything about experimental sources, but I don't know if there's any installed. Did you verify that the contents of the CD were correct? Yes, they worked, files (images, music), iso images... the only thing that isn't working is the eject after the burning, but that could just be brasero. When you burned CDs previously with this computer, were they always corrupted? I don't know if data was corrupted (but because i might not know how to identify data corruption unless that means that I can't open a file or something like that). What happened previously, when burning CDs, was, in the beginning, that the process would hang before any data could be written, and made the CD unreadable (like it couldn't be mount). Luckily I used a rewritable CD and could erase it and make it usable again under Windoze. I think that was fix in the last kernel upgrade. After that, during burning process it seemed that data was in fact being written, but then it couldn't fixate, and the same problem would appear, the CD wouldn't mount. Sorry if this isn't very clear (my english is a bit rusty). Hotmail has tools for the New Busy. Search, chat and e-mail from your inbox. Learn more. -- 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/1277866713.28819.50.ca...@localhost
[Fwd: [PATCH 1/1] [Maverick] UBUNTU: [Config] disable CONFIG_VMI]
Does this seem like a reasonable change to make in squeeze? Ben. Forwarded Message From: Andy Whitcroft a...@canonical.com To: kernel-t...@lists.ubuntu.com Subject: [PATCH 1/1] [Maverick] UBUNTU: [Config] disable CONFIG_VMI Date: Sat, 19 Jun 2010 11:18:16 +0100 As indicated in the option descripion (below) Hypervisor support for VMI is now deprecated and supporting its use is a negative for portability of your kernel image. Turn it off. As of September 2009, VMware has started a phased retirement of this feature from VMware's products. Please see feature-removal-schedule.txt for details. If you are planning to enable this option, please note that you cannot live migrate a VMI enabled VM to a future VMware product, which doesn't support VMI. So if you expect your kernel to seamlessly migrate to newer VMware products, keep this disabled. BugLink: http://bugs.launchpad.net/bugs/537601 Signed-off-by: Andy Whitcroft a...@canonical.com --- debian.master/config/config.common.ubuntu |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/debian.master/config/config.common.ubuntu b/debian.master/config/config.common.ubuntu index 59dd011..36abdf0 100644 --- a/debian.master/config/config.common.ubuntu +++ b/debian.master/config/config.common.ubuntu @@ -4857,7 +4857,7 @@ CONFIG_VLSI_FIR=m CONFIG_VM86=y CONFIG_VME_BUS=m CONFIG_VME_USER=m -CONFIG_VMI=y +# CONFIG_VMI is not set CONFIG_VMIVME_7805=m # CONFIG_VMSPLIT_1G is not set # CONFIG_VMSPLIT_2G is not set -- 1.7.0.4 -- kernel-team mailing list kernel-t...@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/kernel-team -- Ben Hutchings Once a job is fouled up, anything done to improve it makes it worse. signature.asc Description: This is a digitally signed message part
Bug#587215: [linux-image-2.6.32-5-686]
On Tue, 2010-06-29 at 07:35 +0200, ing. Barry B.F. de Graaff (debian) wrote: [...] On Sun, Jun 27, 2010 at 7:40 PM, Ben Hutchings b...@decadent.org.uk wrote: OK, and for comparison, can you repeat that while using the original driver? (Temporarily remove the driver you got from the manufacturer.) [...] [ 428.084108] eth2: register 'asix' at usb-:00:1d.7-7, ASIX AX88178 USB 2.0 Ethernet, 00:0e:c6:88:09:28 [ 428.084137] usbcore: registered new interface driver asix [ 493.600293] b44: eth0: powering down PHY [ 493.704834] eth2: link down [ 493.707183] ADDRCONF(NETDEV_UP): eth2: link is not ready [ 503.123908] ADDRCONF(NETDEV_CHANGE): eth2: link becomes ready [ 503.126016] eth2: link up, 1000Mbps, full-duplex, lpa 0xCDE1 [ 513.272023] eth2: no IPv6 routers present [ 560.087747] eth2: link up, 1000Mbps, full-duplex, lpa 0xCDE1 [ 563.511322] ADDRCONF(NETDEV_UP): eth0: link is not ready [ 570.622539] b44: eth0: powering down PHY [ 570.704834] eth2: link up, 1000Mbps, full-duplex, lpa 0xCDE1 [ 581.576024] eth2: no IPv6 routers present So, it reported link up... [...] *** Device statistics: Inter-| Receive| Transmit face |bytespackets errs drop fifo frame compressed multicast|bytes packets errs drop fifo colls carrier compressed lo: 0 0000 0 0 00 0000 0 0 0 eth1: 0 0000 0 0 00 0000 0 0 0 eth0: 502382 809000 0 064 128514 786000 0 0 0 eth2: 736 16000 0 0 0 9860 43000 0 0 0 [...] and apparently it was able to send and receive packets without errors. So what is your basis for saying it can't transfer data? How are you testing it? Ben. -- Ben Hutchings Once a job is fouled up, anything done to improve it makes it worse. signature.asc Description: This is a digitally signed message part
Problem installing debian lenny on notebook dell
Hello, can someone help me with this problem?. I m trying to install debian on my notebook dell(i3, gb ram), but when it boots the system doesnt boot and get the following message: waitinf for /dev to be fully populated. Sorry for my english. Im from argentina. -- 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/1193563928-1277869707-cardhu_decombobulator_blackberry.rim.net-5115636...@bda487.bisx.prod.on.blackberry
Bug#587592: initramfs-tools: update-initramfs -u generates default image for incorrect kernel version
Package: initramfs-tools Version: 0.97 Severity: normal If a portion an existing (but older) initrd image is non-numeric like 'trunk' in the example below exists in the /boot directory, the default image will be built for that kernel and not the actual most recent one. (-5 in the examle). It wouldn't be much of a problem except most of the install scripts depend on -u reliably identifying the correct version to update without using the -k option. ls -lh /boot/initrd.* : -rw-r--r-- 1 root root 6.4M Apr 19 2009 /boot/initrd.img-2.6.26-1-amd64 -rw-r--r-- 1 root root 11M Dec 23 2009 /boot/initrd.img-2.6.26-2-amd64 -rw-r--r-- 1 root root 6.9M Apr 19 2009 /boot/initrd.img-2.6.26-2-amd64.bak -rw-r--r-- 1 root root 11M Jun 29 22:38 /boot/initrd.img-2.6.32-5-amd64 -rw-r--r-- 1 root root 11M Jun 29 22:56 /boot/initrd.img-2.6.32-trunk-amd64 -rw-r--r-- 1 root root 8.8M Dec 23 2009 /boot/initrd.img-2.6.32-trunk- amd64.bak The -5 image shows a current date because I corrected the problem using the -k option before starting this report. (apparently -trunk was a left over kernel from sid I was trying out a few months ago - it's not a name I would personally have chosen) Thanks -- Package-specific info: -- initramfs sizes -rw-r--r-- 1 root root 6.4M Apr 19 2009 /boot/initrd.img-2.6.26-1-amd64 -rw-r--r-- 1 root root 11M Dec 23 2009 /boot/initrd.img-2.6.26-2-amd64 -rw-r--r-- 1 root root 6.9M Apr 19 2009 /boot/initrd.img-2.6.26-2-amd64.bak -rw-r--r-- 1 root root 11M Jun 29 22:38 /boot/initrd.img-2.6.32-5-amd64 -rw-r--r-- 1 root root 11M Jun 29 22:56 /boot/initrd.img-2.6.32-trunk-amd64 -rw-r--r-- 1 root root 8.8M Dec 23 2009 /boot/initrd.img-2.6.32-trunk- amd64.bak -- /proc/cmdline BOOT_IMAGE=/boot/vmlinuz-2.6.32-5-amd64 root=UUID=d74173e9-b5b2-4866- bebf-754b772164eb ro quiet -- resume RESUME=/dev/vda5 -- /proc/filesystems ext3 fuseblk -- lsmod Module Size Used by nfs 240826 2 lockd 57603 1 nfs fscache29834 1 nfs nfs_acl 2031 1 nfs auth_rpcgss33460 1 nfs sunrpc161317 15 nfs,lockd,nfs_acl,auth_rpcgss fuse 50190 1 loop 11783 0 snd_ens137018435 4 gameport7416 1 snd_ens1370 snd_pcm_oss32591 0 snd_mixer_oss 12606 1 snd_pcm_oss snd_pcm60471 3 snd_ens1370,snd_pcm_oss snd_seq_midi4400 0 snd_rawmidi15515 2 snd_ens1370,snd_seq_midi snd_seq_midi_event 4628 1 snd_seq_midi snd_seq42881 2 snd_seq_midi,snd_seq_midi_event snd_timer 15582 3 snd_pcm,snd_seq snd_seq_device 4493 3 snd_seq_midi,snd_rawmidi,snd_seq joydev 8411 0 snd46446 14 snd_ens1370,snd_pcm_oss,snd_mixer_oss,snd_pcm,snd_rawmidi,snd_seq,snd_timer,snd_seq_device i2c_piix4 8328 0 soundcore 4598 1 snd snd_page_alloc 6249 2 snd_ens1370,snd_pcm i2c_core 15712 1 i2c_piix4 virtio_balloon 2961 0 tpm_tis 7336 0 tpm 9917 1 tpm_tis tpm_bios4521 1 tpm psmouse49777 0 pcspkr 1699 0 evdev 7352 9 serio_raw 3752 0 processor 30231 0 button 4650 0 ext3 106518 1 jbd37085 1 ext3 mbcache 5050
