Bug#676360: nouveau: PFIFO_CACHE_ERROR - Ch 0/7
* Jonathan Nieder [2012-06-06 11:30:00 -0500]: Please test 3.4.1 from experimental (it should finish building and show up at incoming.debian.org soon[1]). Hope that helps, Sorry to disappoint you. That 3.4.1-1~experimental.1 build (3.4-trunk-686-pae #1 SMP Wed Jun 6 15:11:31 UTC 2012 i686 GNU/Linux) is even less well-behaved under Xen: I'm getting a kernel OOPS at EIP: [c1168e54] atomic64_read_cx8+0x4/0xc SS:ESP e021:ca853c6c The top of the trace message unfortunately scrolled off the console before I could see it, and the message doesn't have time to make it to syslog (either local or remote). An interesting twist: the trace is timestamped 0.776065 but there is exactly one more message on the console at 1.344071 before the system hangs: Refined TSC clocksource calibration: 3191.999 MHz. (This is indeed a 3.2 GHz CPU.) Non-Xen boots proceed normally. Feel free to split this bug report since this new OOPS is clearly unrelated to the nouveau issue (it happens even when the nouveau module is blacklisted); I only mention it here because it's preventing me from checking whether the problem with nouveau is still present. -- 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/20120607064017.ga2...@hanuman.astro.su.se
Processed: tagging 669028
Processing commands for cont...@bugs.debian.org: tags 669028 + pending Bug #669028 [src:linux-2.6] please backport new procfs hidepid option into 3.2 Added tag(s) pending. thanks Stopping processing here. Please contact me if you need assistance. -- 669028: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=669028 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.133905236229581.transcr...@bugs.debian.org
Bug#676360: xen: oops at atomic64_read_cx8+0x4
Sergio Gelato wrote[1]: That 3.4.1-1~experimental.1 build (3.4-trunk-686-pae #1 SMP Wed Jun 6 15:11:31 UTC 2012 i686 GNU/Linux) is even less well-behaved under Xen: I'm getting a kernel OOPS at EIP: [c1168e54] atomic64_read_cx8+0x4/0xc SS:ESP e021:ca853c6c The top of the trace message unfortunately scrolled off the console before I could see it, and the message doesn't have time to make it to syslog (either local or remote). [...] Non-Xen boots proceed normally. Yeah, apparently[2] that's caused by commit 26c191788f18 Author: Andrea Arcangeli aarca...@redhat.com Date: Tue May 29 15:06:49 2012 -0700 mm: pmd_read_atomic: fix 32bit PAE pmd walk vs pmd_populate SMP race condition which was also included in Debian kernel 3.2.19-1. [1] http://bugs.debian.org/676360 [2] https://bugzilla.redhat.com/show_bug.cgi?id=829016#c4 -- 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/2012060707.GF3210@burratino
Processed: tagging 674059
Processing commands for cont...@bugs.debian.org: tags 674059 - pending Bug #674059 [initramfs-tools] initramfs generation fails at fs/udf/udf.ko Removed tag(s) pending. thanks Stopping processing here. Please contact me if you need assistance. -- 674059: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=674059 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.133905636518822.transcr...@bugs.debian.org
Processed: tagging 676439
Processing commands for cont...@bugs.debian.org: tags 676439 + pending Bug #676439 [initramfs-tools] buggy manual_add_modules hook function Added tag(s) pending. thanks Stopping processing here. Please contact me if you need assistance. -- 676439: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=676439 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.133905639319250.transcr...@bugs.debian.org
Bug#664068: USB MIDI keyboard fails to initialize
Hi Jonathan, I tested your patches on a 3.3.6 kernel and they work fine. Weird --- those patches don't do anything for 0763:019b. Could you attach lsusb -v and alsa-info.sh --no-upload output[1]? Indeed this is weird. I first tested it with a 3.4.0 kernel that without the patch and it was not working. Then I rebooted on a patched 3.3.6 kernel and the midi keyboard was working. Of course, in both case, I took care to revert /etc/laptop-mode/conf.d/usb-autosuspend.conf But I agree with you that this is very surprising when we look at patch as it does not match my vendor/device ID. Maybe it was just luck, as the issue described initially by David seems to occur for 90% of tests. Or perhaps I was too fast and I hit a key before the keyboard switched in powersave mode ? Unfortunately I won't be able to do the test again before weeks as the keyboard is currently not at my home (that's also why I took time to answer and I was not able to test it more deeply). As soon as I can do the test again, I will post requested info (lsusb and alsa-info). Regards, Olivier -- 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/4fd06563.7050...@droids-corp.org
Bug#676486: mkinitramfs: Error: missing parameters. See -h.
Package: initramfs-tools Version: 0.105 If I run update-initramfs, it prints an error message about missing parameters: # update-initramfs -u -k 3.3.0-trunk-amd64 update-initramfs: Generating /boot/initrd.img-3.3.0-trunk-amd64 Error: missing parameters. See -h. To debug this, I added set -x to mkinitramfs: + hidden_dep_add_modules + local modules= + set -- lib/libcrc32c crc32c + [ -f /var/tmp/mkinitramfs_Qadg11/lib/modules/3.3.0-trunk-amd64/kernel/lib/libcrc32c.ko ] + set -- fs/ubifs/ubifs deflate zlib lzo + [ -f /var/tmp/mkinitramfs_Qadg11/lib/modules/3.3.0-trunk-amd64/kernel/fs/ubifs/ubifs.ko ] + manual_add_modules + local prefix kmod options firmware + modprobe --all --set-version=3.3.0-trunk-amd64 --ignore-install --quiet --show-depends + read prefix kmod options Error: missing parameters. See -h. [ Of course the error comes from modprobe, not read. ] -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (990, 'unstable'), (500, 'experimental') Architecture: i386 (x86_64) Foreign Architectures: amd64 Kernel: Linux 3.3.0-trunk-amd64 (SMP w/2 CPU cores) Locale: LANG=C, LC_CTYPE=pl_PL.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages initramfs-tools depends on: ii cpio 2.11-7 ii klibc-utils2.0-2 ii kmod 8-2 ii module-init-tools 8-2 ii udev 175-3.1 Versions of packages initramfs-tools recommends: ii busybox-static 1:1.19.3-7 -- Jakub Wilk -- 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/20120607094146.ga1...@jwilk.net
Bug#676360: xen: oops at atomic64_read_cx8+0x4
On Thu, Jun 07, 2012 at 02:33:33AM -0500, Jonathan Nieder wrote: Sergio Gelato wrote[1]: That 3.4.1-1~experimental.1 build (3.4-trunk-686-pae #1 SMP Wed Jun 6 15:11:31 UTC 2012 i686 GNU/Linux) is even less well-behaved under Xen: I'm getting a kernel OOPS at EIP: [c1168e54] atomic64_read_cx8+0x4/0xc SS:ESP e021:ca853c6c The top of the trace message unfortunately scrolled off the console before I could see it, and the message doesn't have time to make it to syslog (either local or remote). [...] Non-Xen boots proceed normally. Yeah, apparently[2] that's caused by commit 26c191788f18 Author: Andrea Arcangeli aarca...@redhat.com Date: Tue May 29 15:06:49 2012 -0700 mm: pmd_read_atomic: fix 32bit PAE pmd walk vs pmd_populate SMP race condition which was also included in Debian kernel 3.2.19-1. [1] http://bugs.debian.org/676360 [2] https://bugzilla.redhat.com/show_bug.cgi?id=829016#c4 Oops, sorry I didn't imagine atomic64_read on a pmd would trip. Unfortunately to support pagetable walking with mmap_sem hold for reading, we need an atomic read on 32bit PAE if CONFIG_TRANSPARENT_HUGEPAGE=y. The only case requiring this is 32bit PAE with CONFIG_TRANSPARENT_HUGEPAGE=y at build time. If you set CONFIG_TRANSPARENT_HUGEPAGE=n temporarily you should be able to work around this as I optimized the code in a way to avoid an expensive cmpxchg8b. I guess if Xen can't be updated to handle an atomic64_read on a pmd in the guest, we can add a pmd_read paravirt op? Or if we don't want to break the paravirt interface a loop like gup_fast with irq disabled should also work but looping + local_irq_disable()/enable() sounded worse and more complex than a atomic64_read (gup fast already disables irqs because it doesn't hold the mmap_sem so it's a different cost looping there). AFIK Xen disables THP during boot, so a check on THP being enabled and falling back in the THP=n version of pmd_read_atomic, would also be safe, but it's not so nice to do it with a runtime check. Thanks, Andrea -- 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/20120607103355.ga21...@redhat.com
Bug#676486: mkinitramfs: Error: missing parameters. See -h.
tags 676486 + pending merge 676439 676486 thanks * Jakub Wilk [Thu Jun 07, 2012 at 11:41:46AM +0200]: If I run update-initramfs, it prints an error message about missing parameters: # update-initramfs -u -k 3.3.0-trunk-amd64 update-initramfs: Generating /boot/initrd.img-3.3.0-trunk-amd64 Error: missing parameters. See -h. [...] This seems to be #676439, upload will follow soon. regards, -mika- signature.asc Description: Digital signature
Processed: Re: Bug#676486: mkinitramfs: Error: missing parameters. See -h.
Processing commands for cont...@bugs.debian.org: tags 676486 + pending Bug #676486 [initramfs-tools] mkinitramfs: Error: missing parameters. See -h. Added tag(s) pending. merge 676439 676486 Bug #676439 [initramfs-tools] buggy manual_add_modules hook function Bug #676486 [initramfs-tools] mkinitramfs: Error: missing parameters. See -h. Marked as found in versions initramfs-tools/0.104. Added tag(s) confirmed and patch. Bug #676439 [initramfs-tools] buggy manual_add_modules hook function Marked as found in versions initramfs-tools/0.105. Merged 676439 676486 thanks Stopping processing here. Please contact me if you need assistance. -- 676439: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=676439 676486: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=676486 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.13390657243604.transcr...@bugs.debian.org
Bug#676360: xen: oops at atomic64_read_cx8+0x4
* Andrea Arcangeli [2012-06-07 12:33:55 +0200]: I guess if Xen can't be updated to handle an atomic64_read on a pmd in the guest, I'm not sure if it makes a difference, but just in case: I observed the problem in a dom0. we can add a pmd_read paravirt op? Or if we don't want to break the paravirt interface a loop like gup_fast with irq disabled should also work but looping + local_irq_disable()/enable() sounded worse and more complex than a atomic64_read (gup fast already disables irqs because it doesn't hold the mmap_sem so it's a different cost looping there). AFIK Xen disables THP during boot, so a check on THP being enabled and falling back in the THP=n version of pmd_read_atomic, would also be safe, but it's not so nice to do it with a runtime check. Thanks, Andrea -- 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/20120607123031.gb2...@hanuman.astro.su.se
Bug#676439: marked as done (buggy manual_add_modules hook function)
Your message dated Thu, 07 Jun 2012 13:03:06 +
with message-id e1sccmk-0007je...@franck.debian.org
and subject line Bug#676439: fixed in initramfs-tools 0.106
has caused the Debian Bug report #676439,
regarding buggy manual_add_modules hook function
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.)
--
676439: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=676439
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
---BeginMessage---
Package: initramfs-tools
Version: 0.104
The change to manual_add_modules() to always call modprobe --all
--set-version=${version} --ignore-install --quiet --show-depends $@
ends up not working too well when $@ is empty (Error: missing parameters.
See -h.)
In my case it happens because my kernels don't have any of the modules
from the hidden_dep_add_modules() function. I'll leave it up to you
to decide if its better to never call manual_add_modules without
arguments, or make manual_add_modules a nop if it is.
--
Jamie Heilman http://audible.transient.net/~jamie/
---End Message---
---BeginMessage---
Source: initramfs-tools
Source-Version: 0.106
We believe that the bug you reported is fixed in the latest version of
initramfs-tools, which is due to be installed in the Debian FTP archive:
initramfs-tools_0.106.dsc
to main/i/initramfs-tools/initramfs-tools_0.106.dsc
initramfs-tools_0.106.tar.gz
to main/i/initramfs-tools/initramfs-tools_0.106.tar.gz
initramfs-tools_0.106_all.deb
to main/i/initramfs-tools/initramfs-tools_0.106_all.deb
A summary of the changes between this version and the previous one is
attached.
Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to 676...@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.
Debian distribution maintenance software
pp.
Michael Prokop m...@debian.org (supplier of updated initramfs-tools package)
(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmas...@debian.org)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.8
Date: Thu, 07 Jun 2012 14:40:24 +0200
Source: initramfs-tools
Binary: initramfs-tools
Architecture: source all
Version: 0.106
Distribution: unstable
Urgency: high
Maintainer: Debian kernel team debian-kernel@lists.debian.org
Changed-By: Michael Prokop m...@debian.org
Description:
initramfs-tools - generic modular initramfs generator
Closes: 676439
Changes:
initramfs-tools (0.106) unstable; urgency=high
.
[ Josh Triplett ]
* [67d4cec] initramfs-tools: Make manual_add_modules a no-op with no
arguments (Closes: 676439)
Checksums-Sha1:
c87e0d03f717d9fccbbdaafa153223f77649c333 1052 initramfs-tools_0.106.dsc
d45364f0f10fc9ee722ed005058f3d8f970731fa 84681 initramfs-tools_0.106.tar.gz
d8b4b2d1150126284752155c7073ed10e1809693 90614 initramfs-tools_0.106_all.deb
Checksums-Sha256:
0c9965ab4ae031fa181526610b157aa9e641e9a9c702f82df7f41da70bc16d0f 1052
initramfs-tools_0.106.dsc
455d93c863deca4cc519f6ce57150a7b77fbe0c5744d6e6ff4a5a070413492d7 84681
initramfs-tools_0.106.tar.gz
da112108f1d604f98ad70f59b6e9ae349ccd1078a74cea4abcc03f7f365db3a4 90614
initramfs-tools_0.106_all.deb
Files:
bca5aeef81cfb94147c23e98de9eb687 1052 utils optional initramfs-tools_0.106.dsc
feff8d9b2458f0ba5cfe92d852316574 84681 utils optional
initramfs-tools_0.106.tar.gz
6e07783570f7dffcb06e95f0a75355e3 90614 utils optional
initramfs-tools_0.106_all.deb
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
iEYEARECAAYFAk/Qoj4ACgkQ2N9T+zficuif4wCffubBJlgSzt9+9MNJam223yfH
hDAAniaM4ZLGniaAfxj9uE0rfVCy1/Zl
=NiDX
-END PGP SIGNATURE-
---End Message---
Bug#676486: marked as done (mkinitramfs: Error: missing parameters. See -h.)
Your message dated Thu, 07 Jun 2012 13:03:06 + with message-id e1sccmk-0007je...@franck.debian.org and subject line Bug#676439: fixed in initramfs-tools 0.106 has caused the Debian Bug report #676439, regarding mkinitramfs: Error: missing parameters. See -h. 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.) -- 676439: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=676439 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ---BeginMessage--- Package: initramfs-tools Version: 0.105 If I run update-initramfs, it prints an error message about missing parameters: # update-initramfs -u -k 3.3.0-trunk-amd64 update-initramfs: Generating /boot/initrd.img-3.3.0-trunk-amd64 Error: missing parameters. See -h. To debug this, I added set -x to mkinitramfs: + hidden_dep_add_modules + local modules= + set -- lib/libcrc32c crc32c + [ -f /var/tmp/mkinitramfs_Qadg11/lib/modules/3.3.0-trunk-amd64/kernel/lib/libcrc32c.ko ] + set -- fs/ubifs/ubifs deflate zlib lzo + [ -f /var/tmp/mkinitramfs_Qadg11/lib/modules/3.3.0-trunk-amd64/kernel/fs/ubifs/ubifs.ko ] + manual_add_modules + local prefix kmod options firmware + modprobe --all --set-version=3.3.0-trunk-amd64 --ignore-install --quiet --show-depends + read prefix kmod options Error: missing parameters. See -h. [ Of course the error comes from modprobe, not read. ] -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (990, 'unstable'), (500, 'experimental') Architecture: i386 (x86_64) Foreign Architectures: amd64 Kernel: Linux 3.3.0-trunk-amd64 (SMP w/2 CPU cores) Locale: LANG=C, LC_CTYPE=pl_PL.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages initramfs-tools depends on: ii cpio 2.11-7 ii klibc-utils2.0-2 ii kmod 8-2 ii module-init-tools 8-2 ii udev 175-3.1 Versions of packages initramfs-tools recommends: ii busybox-static 1:1.19.3-7 -- Jakub Wilk ---End Message--- ---BeginMessage--- Source: initramfs-tools Source-Version: 0.106 We believe that the bug you reported is fixed in the latest version of initramfs-tools, which is due to be installed in the Debian FTP archive: initramfs-tools_0.106.dsc to main/i/initramfs-tools/initramfs-tools_0.106.dsc initramfs-tools_0.106.tar.gz to main/i/initramfs-tools/initramfs-tools_0.106.tar.gz initramfs-tools_0.106_all.deb to main/i/initramfs-tools/initramfs-tools_0.106_all.deb A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to 676...@bugs.debian.org, and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Michael Prokop m...@debian.org (supplier of updated initramfs-tools package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing ftpmas...@debian.org) -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Thu, 07 Jun 2012 14:40:24 +0200 Source: initramfs-tools Binary: initramfs-tools Architecture: source all Version: 0.106 Distribution: unstable Urgency: high Maintainer: Debian kernel team debian-kernel@lists.debian.org Changed-By: Michael Prokop m...@debian.org Description: initramfs-tools - generic modular initramfs generator Closes: 676439 Changes: initramfs-tools (0.106) unstable; urgency=high . [ Josh Triplett ] * [67d4cec] initramfs-tools: Make manual_add_modules a no-op with no arguments (Closes: 676439) Checksums-Sha1: c87e0d03f717d9fccbbdaafa153223f77649c333 1052 initramfs-tools_0.106.dsc d45364f0f10fc9ee722ed005058f3d8f970731fa 84681 initramfs-tools_0.106.tar.gz d8b4b2d1150126284752155c7073ed10e1809693 90614 initramfs-tools_0.106_all.deb Checksums-Sha256: 0c9965ab4ae031fa181526610b157aa9e641e9a9c702f82df7f41da70bc16d0f 1052 initramfs-tools_0.106.dsc 455d93c863deca4cc519f6ce57150a7b77fbe0c5744d6e6ff4a5a070413492d7 84681 initramfs-tools_0.106.tar.gz da112108f1d604f98ad70f59b6e9ae349ccd1078a74cea4abcc03f7f365db3a4 90614 initramfs-tools_0.106_all.deb Files: bca5aeef81cfb94147c23e98de9eb687 1052 utils optional initramfs-tools_0.106.dsc feff8d9b2458f0ba5cfe92d852316574 84681 utils optional initramfs-tools_0.106.tar.gz 6e07783570f7dffcb06e95f0a75355e3 90614 utils optional initramfs-tools_0.106_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAk/Qoj4ACgkQ2N9T+zficuif4wCffubBJlgSzt9+9MNJam223yfH
Processing of initramfs-tools_0.106_amd64.changes
initramfs-tools_0.106_amd64.changes uploaded successfully to localhost along with the files: initramfs-tools_0.106.dsc initramfs-tools_0.106.tar.gz initramfs-tools_0.106_all.deb Greetings, Your Debian queue daemon (running on host franck.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/e1scc8q-0006kf...@franck.debian.org
initramfs-tools_0.106_amd64.changes ACCEPTED into unstable
Accepted: initramfs-tools_0.106.dsc to main/i/initramfs-tools/initramfs-tools_0.106.dsc initramfs-tools_0.106.tar.gz to main/i/initramfs-tools/initramfs-tools_0.106.tar.gz initramfs-tools_0.106_all.deb to main/i/initramfs-tools/initramfs-tools_0.106_all.deb Changes: initramfs-tools (0.106) unstable; urgency=high . [ Josh Triplett ] * [67d4cec] initramfs-tools: Make manual_add_modules a no-op with no arguments (Closes: 676439) Override entries for your package: initramfs-tools_0.106.dsc - source utils initramfs-tools_0.106_all.deb - optional utils Announcing to debian-devel-chan...@lists.debian.org Closing bugs: 676439 Thank you for your contribution to Debian. -- 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/e1sccmk-0007jy...@franck.debian.org
Bug#676515: linux-2.6: AppArmor totally broken
Package: linux-2.6 Severity: normal Version: 3.2.19-1 Tags: patch X-Debbugs-CC: john.johan...@canonical.com, k...@debian.org, mi...@riseup.net Hi, the AppArmor compatibility patch applied to fix #661151 totally breaks AppArmor support; this is a regression. Details: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=661151#83 Applying the AppArmor: compatibility patch for v5 network controll on top of the already applied one fixes the problem for me. I did test with the patch that can be found there: http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-precise.git;a=commit;h=d253e5fb4a6b552e7cd2a3c80934ab4f92faec97 Please consider applying this network compatibility patch, not only to fix this regression, but also to get us working network mediation. -- 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/85fwa7z1lt@boum.org
Processed: tagging 657078
Processing commands for cont...@bugs.debian.org: tags 657078 + pending Bug #657078 [linux-2.6] nfs: page allocation failure in nfs_idmap_new Added tag(s) pending. thanks Stopping processing here. Please contact me if you need assistance. -- 657078: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=657078 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.133907748214488.transcr...@bugs.debian.org
Bug#676515: linux-2.6: AppArmor totally broken
On Thu, 2012-06-07 at 15:35 +0200, intrig...@debian.org wrote:
Package: linux-2.6
Severity: normal
Version: 3.2.19-1
Tags: patch
X-Debbugs-CC: john.johan...@canonical.com, k...@debian.org, mi...@riseup.net
Hi,
the AppArmor compatibility patch applied to fix #661151
totally breaks AppArmor support; this is a regression.
Details: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=661151#83
Applying the AppArmor: compatibility patch for v5 network controll
on top of the already applied one fixes the problem for me.
I did test with the patch that can be found there:
http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-precise.git;a=commit;h=d253e5fb4a6b552e7cd2a3c80934ab4f92faec97
Please consider applying this network compatibility patch,
not only to fix this regression,
but also to get us working network mediation.
So these independent patches really aren't... or else userland gets
confused if we apply just the one.
Looking at the network controller patch:
--- a/security/apparmor/lsm.c
+++ b/security/apparmor/lsm.c
[...]
@@ -621,6 +622,104 @@ static int apparmor_task_setrlimit(struct task_struct
*task,
return error;
}
+static int apparmor_socket_create(int family, int type, int protocol, int
kern)
+{
+ struct aa_profile *profile;
+ int error = 0;
+
+ if (kern)
+ return 0;
If we don't want to restrict sockets used by the kernel, don't we need
to store the kern flag for later use by aa_revalidate_sk()?
+ profile = __aa_current_profile();
+ if (!unconfined(profile))
+ error = aa_net_perm(OP_CREATE, profile, family, type, protocol,
+ NULL);
+ return error;
+}
[...]
--- /dev/null
+++ b/security/apparmor/net.c
[...]
+static int audit_net(struct aa_profile *profile, int op, u16 family, int
type,
+ int protocol, struct sock *sk, int error)
+{
[...]
+ } else {
+ u16 quiet_mask = profile-net.quiet[sa.u.net.family];
+ u16 kill_mask = 0;
+ u16 denied = (1 sa.aad.net.type) ~quiet_mask;
+
+ if (denied kill_mask)
+ audit_type = AUDIT_APPARMOR_KILL;
+
+ if ((denied quiet_mask)
Since denied has already been masked with ~quiet_mask, this condition
can never be true.
+ AUDIT_MODE(profile) != AUDIT_NOQUIET
+ AUDIT_MODE(profile) != AUDIT_ALL)
+ return COMPLAIN_MODE(profile) ? 0 : sa.aad.error;
+ }
+
+ return aa_audit(audit_type, profile, GFP_KERNEL, sa, audit_cb);
+}
[...]
+/**
+ * aa_revalidate_sk - Revalidate access to a sock
+ * @op: operation being checked
+ * @sk: sock being revalidated (NOT NULL)
+ *
+ * Returns: %0 else error if permission denied
+ */
+int aa_revalidate_sk(int op, struct sock *sk)
+{
+ struct aa_profile *profile;
+ int error = 0;
+
+ /* aa_revalidate_sk should not be called from interrupt context
+ * don't mediate these calls as they are not task related
+ */
+ if (in_interrupt())
+ return 0;
I wonder why this is being checked at all.
+ profile = __aa_current_profile();
+ if (!unconfined(profile))
+ error = aa_net_perm(op, profile, sk-sk_family, sk-sk_type,
+ sk-sk_protocol, sk);
+
+ return error;
+}
[...]
Ben.
--
Ben Hutchings
I haven't lost my mind; it's backed up on tape somewhere.
signature.asc
Description: This is a digitally signed message part
Bug#676515: linux-2.6: AppArmor totally broken
On Thu, 2012-06-07 at 15:34 +0100, Ben Hutchings wrote:
On Thu, 2012-06-07 at 15:35 +0200, intrig...@debian.org wrote:
[...]
Looking at the network controller patch:
--- a/security/apparmor/lsm.c
+++ b/security/apparmor/lsm.c
[...]
@@ -621,6 +622,104 @@ static int apparmor_task_setrlimit(struct task_struct
*task,
return error;
}
+static int apparmor_socket_create(int family, int type, int protocol, int
kern)
+{
+ struct aa_profile *profile;
+ int error = 0;
+
+ if (kern)
+ return 0;
If we don't want to restrict sockets used by the kernel, don't we need
to store the kern flag for later use by aa_revalidate_sk()?
[...]
Certainly that's what SELinux does (in the socket_post_create hook).
Ben.
--
Ben Hutchings
I haven't lost my mind; it's backed up on tape somewhere.
signature.asc
Description: This is a digitally signed message part
Bug#676360: [Xen-devel] xen: oops at atomic64_read_cx8+0x4
On Thu, Jun 07, 2012 at 12:33:55PM +0200, Andrea Arcangeli wrote: On Thu, Jun 07, 2012 at 02:33:33AM -0500, Jonathan Nieder wrote: Sergio Gelato wrote[1]: That 3.4.1-1~experimental.1 build (3.4-trunk-686-pae #1 SMP Wed Jun 6 15:11:31 UTC 2012 i686 GNU/Linux) is even less well-behaved under Xen: I'm getting a kernel OOPS at EIP: [c1168e54] atomic64_read_cx8+0x4/0xc SS:ESP e021:ca853c6c The top of the trace message unfortunately scrolled off the console before I could see it, and the message doesn't have time to make it to syslog (either local or remote). [...] Non-Xen boots proceed normally. Yeah, apparently[2] that's caused by commit 26c191788f18 Author: Andrea Arcangeli aarca...@redhat.com Date: Tue May 29 15:06:49 2012 -0700 mm: pmd_read_atomic: fix 32bit PAE pmd walk vs pmd_populate SMP race condition which was also included in Debian kernel 3.2.19-1. [1] http://bugs.debian.org/676360 [2] https://bugzilla.redhat.com/show_bug.cgi?id=829016#c4 Oops, sorry I didn't imagine atomic64_read on a pmd would trip. Hmm, so it looks like it used to do this: pmd = pmd_offset(pud, addr); .. pmd_t pmdval = *pmd; but now you do: pmd_t ret = (pmd_val)((u32)*tmp); ret |= (*tmp+1) 32; which would read the low first and then the high one next (or is the other way around?). The 'pmd_offset' beforehand manufactures the pmd using the PFN to MFN lookup tree (so that there aren't any hypercall or traps). Hm, with your change, you are still looking at the 'pmd' and its contents, except that you are reading the low and then the high part. Why that would trip the hypervisor is not clear to me. Perhaps in the past it only read the low bits? If there was Xen hypervisor log that might give some ideas. Is there any chance that the Linode folks could send that over? Unfortunately to support pagetable walking with mmap_sem hold for reading, we need an atomic read on 32bit PAE if CONFIG_TRANSPARENT_HUGEPAGE=y. The only case requiring this is 32bit PAE with CONFIG_TRANSPARENT_HUGEPAGE=y at build time. If you set CONFIG_TRANSPARENT_HUGEPAGE=n temporarily you should be able to work around this as I optimized the code in a way to avoid an expensive cmpxchg8b. Ah, by just skipping the thing if the low bits are zero. I guess if Xen can't be updated to handle an atomic64_read on a pmd in the guest, we can add a pmd_read paravirt op? Or if we don't want to break the paravirt interface a loop like gup_fast with irq disabled should also work but looping + local_irq_disable()/enable() sounded worse and more complex than a atomic64_read (gup fast already disables irqs because it doesn't hold the mmap_sem so it's a different cost I am not really sure what is at foot. It sounds like the hypervisor didn't like somebody reading the high and low bit, but isn't the pmdval_t still 64-bit ? So I would have thought this would have been triggered? Or is that the code on pmd_val never actually read the high bits (before your addition to the atomic_read?)? looping there). AFIK Xen disables THP during boot, so a check on THP being enabled and falling back in the THP=n version of pmd_read_atomic, would also be safe, but it's not so nice to do it with a runtime check. The thing is that I did install a 32-bit PAE guest (a Fedora) on a Fedora 17 dom0. So it looks like this is reading high part is fixed on the newer hypervisors, but now with the older ones. And the older one is Amazon EC2 so some .. hack to workaround older hypervisors could be added. -- 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/20120607155647.go9...@phenom.dumpdata.com
Bug#676360: [Xen-devel] xen: oops at atomic64_read_cx8+0x4
Hi, On Thu, Jun 07, 2012 at 11:56:47AM -0400, Konrad Rzeszutek Wilk wrote: then the high part. Why that would trip the hypervisor is not clear to me. Perhaps in the past it only read the That is the CONFIG_TRANSPARENT_HUGEPAGE=n case and in fact it doesn't trip the hypervisor. That was tested too, it should work fine. The problem is with the atomic64_read version, that one uses cmpxchg8b to read the contents of the pmdp. Ah, by just skipping the thing if the low bits are zero. Yep. didn't like somebody reading the high and low bit, but isn't the pmdval_t still 64-bit ? So I would have thought this would The pmd format is unchanged, that's hardware. The thing is that I did install a 32-bit PAE guest (a Fedora) on a Fedora 17 dom0. So it looks like this is reading high part is fixed on the newer hypervisors, but now with the older ones. And the older one is Amazon EC2 so some .. hack to workaround older hypervisors could be added. The insn oopsing is cmpxchg8b and it's not reading the low/high part in two separate insn but reading it in a single insn, which means the kernel oopsing was built with CONFIG_TRANSPARENT_HUGEPAGE=y. -- 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/20120607161704.ge21...@redhat.com
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 #518467 (http://bugs.debian.org/518467) # Bug title: linux-image-2.6.28-1-amd64: bluetooth mouse stutters since kernel upgrade # * http://bugzilla.kernel.org/show_bug.cgi?id=13314 # * remote status changed: NEW - CLOSED # * remote resolution changed: (?) - OBSOLETE # * closed upstream tags 518467 + fixed-upstream Bug #518467 [linux-2.6] linux-image-2.6.28-1-amd64: bluetooth mouse stutters since kernel upgrade Added tag(s) fixed-upstream. usertags 518467 - status-NEW Bug#518467: linux-image-2.6.28-1-amd64: bluetooth mouse stutters since kernel upgrade Usertags were: status-NEW. Usertags are now: . usertags 518467 + status-CLOSED resolution-OBSOLETE Bug#518467: linux-image-2.6.28-1-amd64: bluetooth mouse stutters since kernel upgrade There were no usertags set. Usertags are now: resolution-OBSOLETE status-CLOSED. thanks Stopping processing here. Please contact me if you need assistance. -- 518467: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=518467 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.133908716731253.transcr...@bugs.debian.org
Bug#676515: linux-2.6: AppArmor totally broken
On 06/07/2012 07:34 AM, Ben Hutchings wrote:
On Thu, 2012-06-07 at 15:35 +0200, intrig...@debian.org wrote:
Package: linux-2.6
Severity: normal
Version: 3.2.19-1
Tags: patch
X-Debbugs-CC: john.johan...@canonical.com, k...@debian.org, mi...@riseup.net
Hi,
the AppArmor compatibility patch applied to fix #661151
totally breaks AppArmor support; this is a regression.
Details: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=661151#83
Applying the AppArmor: compatibility patch for v5 network controll
on top of the already applied one fixes the problem for me.
I did test with the patch that can be found there:
http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-precise.git;a=commit;h=d253e5fb4a6b552e7cd2a3c80934ab4f92faec97
Please consider applying this network compatibility patch,
not only to fix this regression,
but also to get us working network mediation.
So these independent patches really aren't... or else userland gets
confused if we apply just the one.
Hrmmm, no they should be. That is a bug in userland that needs to be
fixed. I do know that they used to work when applied separately. It
certainly not a configuration that gets a lot of testing, but it
should have worked. I will look into it and figure out what is causing
it to break.
Looking at the network controller patch:
--- a/security/apparmor/lsm.c
+++ b/security/apparmor/lsm.c
[...]
@@ -621,6 +622,104 @@ static int apparmor_task_setrlimit(struct task_struct
*task,
return error;
}
+static int apparmor_socket_create(int family, int type, int protocol, int
kern)
+{
+struct aa_profile *profile;
+int error = 0;
+
+if (kern)
+return 0;
If we don't want to restrict sockets used by the kernel, don't we need
to store the kern flag for later use by aa_revalidate_sk()?
For how apparmor is generally deployed it can get away with this, the
kernel bits generally bail out earlier on the check for unconfined.
That is not to say it isn't a good idea, or that it shouldn't be done.
The fact is this patch is going to be replaced with completely rewritten
controls, that do store info on the socket, it just hasn't happened yet
due to resources and priorities (not my priorities).
+profile = __aa_current_profile();
+if (!unconfined(profile))
+error = aa_net_perm(OP_CREATE, profile, family, type, protocol,
+NULL);
+return error;
+}
[...]
--- /dev/null
+++ b/security/apparmor/net.c
[...]
+static int audit_net(struct aa_profile *profile, int op, u16 family, int
type,
+ int protocol, struct sock *sk, int error)
+{
[...]
+} else {
+u16 quiet_mask = profile-net.quiet[sa.u.net.family];
+u16 kill_mask = 0;
+u16 denied = (1 sa.aad.net.type) ~quiet_mask;
+
+if (denied kill_mask)
+audit_type = AUDIT_APPARMOR_KILL;
+
+if ((denied quiet_mask)
Since denied has already been masked with ~quiet_mask, this condition
can never be true.
indeed
+AUDIT_MODE(profile) != AUDIT_NOQUIET
+AUDIT_MODE(profile) != AUDIT_ALL)
+return COMPLAIN_MODE(profile) ? 0 : sa.aad.error;
+}
+
+return aa_audit(audit_type, profile, GFP_KERNEL, sa, audit_cb);
+}
[...]
+/**
+ * aa_revalidate_sk - Revalidate access to a sock
+ * @op: operation being checked
+ * @sk: sock being revalidated (NOT NULL)
+ *
+ * Returns: %0 else error if permission denied
+ */
+int aa_revalidate_sk(int op, struct sock *sk)
+{
+struct aa_profile *profile;
+int error = 0;
+
+/* aa_revalidate_sk should not be called from interrupt context
+ * don't mediate these calls as they are not task related
+ */
+if (in_interrupt())
+return 0;
I wonder why this is being checked at all.
Good question, I will have to dig into it.
+profile = __aa_current_profile();
+if (!unconfined(profile))
+error = aa_net_perm(op, profile, sk-sk_family, sk-sk_type,
+sk-sk_protocol, sk);
+
+return error;
+}
[...]
Ben.
--
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/4fd0dab0.5070...@canonical.com
[bts-link] source package src:linux-2.6
# # bts-link upstream status pull for source package src: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 #508866 (http://bugs.debian.org/508866) # Bug title: linux-image-2.6.26-1-amd64: NFS going stale for stat() for renamed files like .Xauthority # * http://bugzilla.kernel.org/show_bug.cgi?id=12557 # * remote status changed: NEW - REOPENED usertags 508866 - status-NEW usertags 508866 + status-REOPENED 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/20120607163925.19971.79111.btsl...@busoni.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 #518467 (http://bugs.debian.org/518467) # Bug title: linux-image-2.6.28-1-amd64: bluetooth mouse stutters since kernel upgrade # * http://bugzilla.kernel.org/show_bug.cgi?id=13314 # * remote status changed: NEW - CLOSED # * remote resolution changed: (?) - OBSOLETE # * closed upstream tags 518467 + fixed-upstream usertags 518467 - status-NEW usertags 518467 + status-CLOSED resolution-OBSOLETE 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/20120607163927.19971.19631.btsl...@busoni.debian.org
Bug#676545: linux-image-3.2.0-0.bpo.2-686-pae: ASIX usb net driver broken with 8021Q frames
Package: linux-2.6 Version: 3.2.18-1~bpo60+1 Severity: normal Tags: upstream I am having problems using asix on 3.2.18 with vlan tags, the logs fills up with this; asix 1-4:1.0: eth7: asix_rx_fixup() Bad RX Length 1518 and after some time no RX packets get trough (until the module is unloaded and loaded again). Found this on LKML; https://lkml.org/lkml/2012/6/7/48 Could this fix be included in 3.2.X as well please? Note: I am running on the 3.2.18 kernel backported to squeeze, but the problem should apply to wheezy/sid as well. Note2: irqfixup is due to ASUS PCI irq problems (probably ASM1083), and not related this this. -- Package-specific info: ** Version: Linux version 3.2.0-0.bpo.2-686-pae (Debian 3.2.18-1~bpo60+1) (debian-kernel@lists.debian.org) (gcc version 4.4.5 (Debian 4.4.5-8) ) #1 SMP Sun Jun 3 22:21:19 UTC 2012 ** Command line: BOOT_IMAGE=/vmlinuz-3.2.0-0.bpo.2-686-pae root=/dev/mapper/vg_noraid-lv_root ro quiet irqfixup ** Not tainted ** Kernel log: asix 1-4:1.0: eth7: asix_rx_fixup() Bad RX Length 1518 ** Model information not available ** Loaded modules: snip... asix usbnet mii usbcore snip... ** USB devices: Bus 009 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 008 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 004 Device 002: ID 0557:2008 ATEN International Co., Ltd UC-232A Serial Port [pl2303] Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 006 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 005 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 001 Device 003: ID 2001:3c05 D-Link Corp. DUB-E100 Fast Ethernet [asix] Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub -- System Information: Debian Release: 6.0.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 3.2.0-0.bpo.2-686-pae (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages linux-image-3.2.0-0.bpo.2-686-pae depends on: ii debconf [debconf-2.0] 1.5.36.1 Debian configuration management sy ii initramfs-tools [linux-init 0.99~bpo60+1 tools for generating an initramfs ii linux-base 3.4~bpo60+1 Linux image base package ii module-init-tools 3.12-2+b1tools for managing Linux kernel mo Versions of packages linux-image-3.2.0-0.bpo.2-686-pae recommends: ii firmware-linux-free 2.6.32-45 Binary firmware for various driver ii libc6-i6862.11.3-3 Embedded GNU C Library: Shared lib Versions of packages linux-image-3.2.0-0.bpo.2-686-pae suggests: ii grub-pc1.98+20100804-14+squeeze1 GRand Unified Bootloader, version pn linux-doc-3.2 none(no description available) Versions of packages linux-image-3.2.0-0.bpo.2-686-pae is related to: pn firmware-atheros none (no description available) pn firmware-bnx2 none (no description available) pn firmware-bnx2xnone (no description available) pn firmware-brcm80211none (no description available) pn firmware-intelwimax none (no description available) pn firmware-ipw2x00 none (no description available) pn firmware-ivtv none (no description available) pn firmware-iwlwifi none (no description available) pn firmware-libertas none (no description available) pn firmware-linuxnone (no description available) pn firmware-linux-nonfreenone (no description available) pn firmware-myricom none (no description available) pn firmware-netxen none (no description available) pn firmware-qlogic none (no description available) pn firmware-ralink none (no description available) ii firmware-realtek 0.35 Binary firmware for Realtek wired pn xen-hypervisornone (no description available) -- debconf information excluded -- 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/20120607180252.7081.23123.report...@pluto.rio.se
Bug#666021: Workaround
I've found that sysctl vm.min_free_kbytes = 65536 fixes the issue. Now testing with 16384. It seems that this is specific to PPC kernel as didn't notice this on any other machine (i386/amd64) Regards Petr -- 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/55eb2e79-82ed-462b-b7a6-34a4b5543...@spaceboy.cz
Bug#676360: [Xen-devel] xen: oops at atomic64_read_cx8+0x4
Andrea Arcangeli aarca...@redhat.com 06/07/12 12:35 PM Oops, sorry I didn't imagine atomic64_read on a pmd would trip. The problem really is that the cmpxchg8b is a write, and hence won't go through without faulting on a write protected page (which all page table pages necessarily are). I guess if Xen can't be updated to handle an atomic64_read on a pmd in the guest, we can add a pmd_read paravirt op? Xen could certainly be updated to treat cmpxchg8b on a PMD entry as a simple 8-byte read when compared-to and to-be-stored values are identical, but the problem would be that hypervisors in the field wouldn't necessarily get updated. Or if we don't want to break the paravirt interface a loop like gup_fast with irq disabled should also work but looping + local_irq_disable()/enable() sounded worse and more complex than a atomic64_read (gup fast already disables irqs because it doesn't hold the mmap_sem so it's a different cost looping there). AFIK Xen disables THP during boot, so a check on THP being enabled and falling back in the THP=n version of pmd_read_atomic, would also be safe, but it's not so nice to do it with a runtime check. That would probably nevertheless be the most viable option. If performance critical(?), maybe this could be hidden with something like the alternative instruction or paravirt patching mechanisms? Jan -- 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/4fd11408027800085...@nat28.tlf.novell.com
Bug#518467: marked as done (linux-image-2.6.28-1-amd64: bluetooth mouse stutters since kernel upgrade)
Your message dated Thu, 7 Jun 2012 21:11:07 +0100 with message-id 20120607201102.ga2...@decadent.org.uk and subject line Re: Bug#518467: linux-image-2.6.28-1-amd64: bluetooth mouse stutters since kernel upgrade has caused the Debian Bug report #518467, regarding linux-image-2.6.28-1-amd64: bluetooth mouse stutters since kernel upgrade 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.) -- 518467: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=518467 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ---BeginMessage--- Package: linux-image-2.6.28-1-amd64 Version: 2.6.28-1 Severity: normal A Logitech MX900 Bluetooth mouse connected to its Bluetooth WirelessHub in HCI mode 'stutters'/'lags' as if input events are lumped together only a few times per second. This happens since the recent kernel upgrade from 2.6.26-1. $ grep HID /etc/default/bluetooth HID2HCI_ENABLED=1 HIDD_ENABLED=1 HIDD_OPTIONS=--master --server The same mouse works smoothly in HCI mode with the kernel from linux-image-2.6.26-1-amd64 2.6.26-13. It also works in both 2.6.26 and 2.6.28 kernels if the bluetooth dongle is in HID mode. I also tested a Nintendo wiimote with wminput 0.6.00-4. It works smoothly in both kernels. -- Package-specific info: ** Version: Linux version 2.6.28-1-amd64 (Debian 2.6.28-1) (m...@debian.org) (gcc version 4.3.3 (Debian 4.3.3-4) ) #1 SMP Wed Feb 18 17:16:12 UTC 2009 ** Command line: root=/dev/sda1 ro vdso32=0 single ** Tainted: P M (17) ** Kernel log: [2.804621] usbcore: registered new interface driver usbhid [2.804662] usbhid: v2.6:USB HID core driver [2.982526] ata5: SATA link down (SStatus 0 SControl 300) [3.310528] ata6: SATA link down (SStatus 0 SControl 300) [3.316311] Uniform Multi-Platform E-IDE driver [3.326928] Driver 'sd' needs updating - please use bus_type methods [3.327033] sd 0:0:0:0: [sda] 390721968 512-byte hardware sectors: (200 GB/186 GiB) [3.327075] sd 0:0:0:0: [sda] Write Protect is off [3.327105] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00 [3.327122] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [3.327202] sd 0:0:0:0: [sda] 390721968 512-byte hardware sectors: (200 GB/186 GiB) [3.327242] sd 0:0:0:0: [sda] Write Protect is off [3.327270] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00 [3.327287] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [3.327321] sda: sda1 sda2 sda5 sda6 [3.361000] sd 0:0:0:0: [sda] Attached SCSI disk [3.879546] EXT3-fs: INFO: recovery required on readonly filesystem. [3.879578] EXT3-fs: write access will be enabled during recovery. [4.474861] kjournald starting. Commit interval 5 seconds [4.477027] EXT3-fs: sda1: orphan cleanup on readonly fs [4.477058] ext3_orphan_cleanup: truncating inode 318672 to 0 bytes [4.477084] EXT3-fs: sda1: 1 truncate cleaned up [4.477111] EXT3-fs: recovery complete. [4.484883] EXT3-fs: mounted filesystem with ordered data mode. [5.667970] udevd version 125 started [5.936693] input: Power Button (FF) as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input3 [5.989530] ACPI: Power Button (FF) [PWRF] [5.989627] input: Power Button (CM) as /devices/LNXSYSTM:00/device:00/PNP0C0C:00/input/input4 [6.005516] ACPI: Power Button (CM) [PWRB] [6.377836] iTCO_wdt: Intel TCO WatchDog Timer Driver v1.04 [6.377948] iTCO_wdt: Found a ICH10R TCO device (Version=2, TCOBASE=0x0860) [6.378009] iTCO_wdt: initialized. heartbeat=30 sec (nowayout=0) [6.453658] i801_smbus :00:1f.3: PCI INT C - GSI 18 (level, low) - IRQ 18 [6.453698] ACPI: I/O resource :00:1f.3 [0x400-0x41f] conflicts with ACPI region SMRG [0x400-0x40f] [6.453736] ACPI: Device needs an ACPI driver [6.510006] HDA Intel :00:1b.0: PCI INT A - GSI 22 (level, low) - IRQ 22 [6.510094] HDA Intel :00:1b.0: setting latency timer to 64 [6.918110] HDA Intel :01:00.1: PCI INT B - GSI 17 (level, low) - IRQ 17 [6.918198] HDA Intel :01:00.1: setting latency timer to 64 [7.741795] Unable to find swap-space signature [7.970193] EXT3 FS on sda1, internal journal [8.793958] loop: module loaded [8.867784] coretemp coretemp.0: Using relative temperature scale! [8.867847] coretemp coretemp.1: Using relative temperature scale! [8.867897] coretemp coretemp.2: Using relative temperature scale! [8.867950] coretemp coretemp.3: Using relative temperature scale! [8.898671] w83627ehf: Found W83627EHG chip at 0x290 [9.338787] kjournald starting.
Bug#675615: linux-2.6: Please backport seccomp-filter to wheezy
On Saturday 02 June 2012, Ben Hutchings wrote: On Sat, 2012-06-02 at 16:23 +0200, Stefan Fritsch wrote: Package: linux-2.6 Severity: wishlist The seccomp filter code has this Linus' tree a while back and will be in 3.5. It's a very usefult security feature that would be very nice to have in wheezy. Is it possible to backport it or do you consider it to be too intrusive? I'm aware of this but haven't yet looked at how easy it would be to backport. We would at least need no_new_privs as well. FWIW, I done a backport of (hopefully) all the relevant commits. I have picked the debian/3.2.17 tag from git://anonscm.debian.org/kernel/linux-2.6.git as target because I was too lazy to get the current debian source from svn. Hopefully the differences are not too big. The result is at http://people.debian.org/~sf/seccomp-filter-backport/ . It compiles and the included seccomp-filter sample programs work. Of course, all the patches need review. And it's quite possible that I have overlooked some important pieces, too. Noteworthy conflicts: 3.5 seems to have some seccomp audit infrastructure that is not in 3.2. I have left this out and left the basic logging in, instead. The latter was removed from 3.5 in 3dc1c1b2d2ed7507ce8a379814ad75745ff97ebe. fb0fadf9b213f55ca9368f3edafe51101d5d2deb defines PTRACE_EVENT_SECCOMP to 7, which is used by PTRACE_EVENT_STOP in 3.2. I have used 8 instead. Does this look reasonable to include in wheezy even this close to the freeze? Cheers, Stefan -- 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/201206072257.42207...@sfritsch.de
Bug#676360: [ 08/82] mm: pmd_read_atomic: fix 32bit PAE pmd walk vs pmd_populate SMP race condition
Hi,
this should avoid the cmpxchg8b (to make Xen happy) but without
reintroducing the race condition. It's actually going to be faster
too, but it's conceptually more complicated as the pmd high/low may be
inconsistent at times, but at those times we're going to declare the
pmd unstable and ignore it anyway so it's ok.
NOTE: in theory I could also drop the high part when THP=y thanks to
the barrier() in the caller (and the barrier is needed for the generic
version anyway):
static inline pmd_t pmd_read_atomic(pmd_t *pmdp)
{
pmdval_t ret;
u32 *tmp = (u32 *)pmdp;
ret = (pmdval_t) (*tmp);
+#ifndef CONFIG_TRANSPARENT_HUGEPAGE
if (ret) {
/*
* If the low part is null, we must not read the high part
* or we can end up with a partial pmd.
*/
smp_rmb();
ret |= ((pmdval_t)*(tmp + 1)) 32;
}
+#endif
return (pmd_t) { ret };
}
But it's not worth the extra complexity. It looks cleaner if we deal
with good pmds if they're later found pointing to a pte (even if we
discard them and force pte_offset to re-read the *pmd).
Andrea Arcangeli (1):
thp: avoid atomic64_read in pmd_read_atomic for 32bit PAE
arch/x86/include/asm/pgtable-3level.h | 30 +-
include/asm-generic/pgtable.h | 10 ++
2 files changed, 27 insertions(+), 13 deletions(-)
--
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/1339102833-12358-1-git-send-email-aarca...@redhat.com
Bug#676360: [PATCH] thp: avoid atomic64_read in pmd_read_atomic for 32bit PAE
In the x86 32bit PAE CONFIG_TRANSPARENT_HUGEPAGE=y case while holding
the mmap_sem for reading, cmpxchg8b cannot be used to read pmd
contents under Xen.
So instead of dealing only with consistent pmdvals in
pmd_none_or_trans_huge_or_clear_bad() (which would be conceptually
simpler) we let pmd_none_or_trans_huge_or_clear_bad() deal with pmdvals
where the low 32bit and high 32bit could be inconsistent (to avoid
having to use cmpxchg8b).
The only guarantee we get from pmd_read_atomic is that if the low part
of the pmd was found null, the high part will be null too (so the pmd
will be considered unstable). And if the low part of the pmd is found
stable later, then it means the whole pmd was read atomically
(because after a pmd is stable, neither MADV_DONTNEED nor page faults
can alter it anymore, and we read the high part after the low part).
In the 32bit PAE x86 case, it is enough to read the low part of the
pmdval atomically to declare the pmd as stable and that's true for
THP and no THP, furthermore in the THP case we also have a barrier()
that will prevent any inconsistent pmdvals to be cached by a later
re-read of the *pmd.
Signed-off-by: Andrea Arcangeli aarca...@redhat.com
---
arch/x86/include/asm/pgtable-3level.h | 30 +-
include/asm-generic/pgtable.h | 10 ++
2 files changed, 27 insertions(+), 13 deletions(-)
diff --git a/arch/x86/include/asm/pgtable-3level.h
b/arch/x86/include/asm/pgtable-3level.h
index 43876f1..cb00ccc 100644
--- a/arch/x86/include/asm/pgtable-3level.h
+++ b/arch/x86/include/asm/pgtable-3level.h
@@ -47,16 +47,26 @@ static inline void native_set_pte(pte_t *ptep, pte_t pte)
* they can run pmd_offset_map_lock or pmd_trans_huge or other pmd
* operations.
*
- * Without THP if the mmap_sem is hold for reading, the
- * pmd can only transition from null to not null while pmd_read_atomic runs.
- * So there's no need of literally reading it atomically.
+ * Without THP if the mmap_sem is hold for reading, the pmd can only
+ * transition from null to not null while pmd_read_atomic runs. So
+ * we can always return atomic pmd values with this function.
*
* With THP if the mmap_sem is hold for reading, the pmd can become
- * THP or null or point to a pte (and in turn become stable) at any
- * time under pmd_read_atomic, so it's mandatory to read it atomically
- * with cmpxchg8b.
+ * trans_huge or none or point to a pte (and in turn become stable)
+ * at any time under pmd_read_atomic. We could read it really
+ * atomically here with a atomic64_read for the THP enabled case (and
+ * it would be a whole lot simpler), but to avoid using cmpxchg8b we
+ * only return an atomic pmdval if the low part of the pmdval is later
+ * found stable (i.e. pointing to a pte). And we're returning a none
+ * pmdval if the low part of the pmd is none. In some cases the high
+ * and low part of the pmdval returned may not be consistent if THP is
+ * enabled (the low part may point to previously mapped hugepage,
+ * while the high part may point to a more recently mapped hugepage),
+ * but pmd_none_or_trans_huge_or_clear_bad() only needs the low part
+ * of the pmd to be read atomically to decide if the pmd is unstable
+ * or not, with the only exception of when the low part of the pmd is
+ * zero in which case we return a none pmd.
*/
-#ifndef CONFIG_TRANSPARENT_HUGEPAGE
static inline pmd_t pmd_read_atomic(pmd_t *pmdp)
{
pmdval_t ret;
@@ -74,12 +84,6 @@ static inline pmd_t pmd_read_atomic(pmd_t *pmdp)
return (pmd_t) { ret };
}
-#else /* CONFIG_TRANSPARENT_HUGEPAGE */
-static inline pmd_t pmd_read_atomic(pmd_t *pmdp)
-{
- return (pmd_t) { atomic64_read((atomic64_t *)pmdp) };
-}
-#endif /* CONFIG_TRANSPARENT_HUGEPAGE */
static inline void native_set_pte_atomic(pte_t *ptep, pte_t pte)
{
diff --git a/include/asm-generic/pgtable.h b/include/asm-generic/pgtable.h
index ae39c4b..0ff87ec 100644
--- a/include/asm-generic/pgtable.h
+++ b/include/asm-generic/pgtable.h
@@ -484,6 +484,16 @@ static inline int
pmd_none_or_trans_huge_or_clear_bad(pmd_t *pmd)
/*
* The barrier will stabilize the pmdval in a register or on
* the stack so that it will stop changing under the code.
+*
+* When CONFIG_TRANSPARENT_HUGEPAGE=y on x86 32bit PAE,
+* pmd_read_atomic is allowed to return a not atomic pmdval
+* (for example pointing to an hugepage that has never been
+* mapped in the pmd). The below checks will only care about
+* the low part of the pmd with 32bit PAE x86 anyway, with the
+* exception of pmd_none(). So the important thing is that if
+* the low part of the pmd is found null, the high part will
+* be also null or the pmd_none() check below would be
+* confused.
*/
#ifdef CONFIG_TRANSPARENT_HUGEPAGE
barrier();
--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe.
Bug#660288: Please enable CONFIG_KALLSYMS_ALL
On Mon, Jun 04, 2012 at 05:26:28PM -0400, Tim Abbott wrote: Hi Ben, Your comment about source code is rather off-topic for this bug report, but since there seems to be a misunderstanding on this point, I'd like to clarify: Every Ksplice update tarball ships with a README file containing instructions on how to request the source code for that update from the appropriate people in Oracle Legal. Anyone who follows those instructions can get a copy of the relevant source code. I understand that Matthew Garrett tried to take up this offer a while ago, and is still waiting for complete source code. It doesn't seem to be a good faith attempt to fulfil GPL obligations. To briefly clarify my original email, it is true that enabling CONFIG_KALLSYMS_ALL would make life slightly easier for Ksplice and similar tools that look at kernel data structures (e.g. debugging tools). No doubt true, but it is also strictly redundant with debuginfo. That said, Ksplice doesn't require CONFIG_KALLSYMS_ALL -- the Ksplice Uptrack service has been providing updates for systems running Debian Linux since 2009. While your enabling CONFIG_KALLSYMS_ALL might allow us to delete like 50 lines of code 2 years from now when Squeeze reaches end of life, I submitted this bug report primarily because I'd like it to be the case that other folks developing similar innovative new technologies don't have to do the extra work of supporting !CONFIG_KALLSYMS_ALL in order to support all the major Linux distributions. I hope you'll consider my suggestion on its technical merits. I'm going to have see a request from an actual other person before I care to spend time on this. (In case anyone else in the kernel team wants to proceed with this, that's not a NAK. The issue is that memory and/or flash partition constraints make this unsuitable for some configurations, and you'll need to work out which ones to enable it for.) Ben -- Ben Hutchings We get into the habit of living before acquiring the habit of thinking. - Albert Camus -- 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/20120607213444.gd2...@decadent.org.uk
Bug#675615: linux-2.6: Please backport seccomp-filter to wheezy
On Thu, Jun 07, 2012 at 10:57:41PM +0200, Stefan Fritsch wrote: On Saturday 02 June 2012, Ben Hutchings wrote: On Sat, 2012-06-02 at 16:23 +0200, Stefan Fritsch wrote: Package: linux-2.6 Severity: wishlist The seccomp filter code has this Linus' tree a while back and will be in 3.5. It's a very usefult security feature that would be very nice to have in wheezy. Is it possible to backport it or do you consider it to be too intrusive? I'm aware of this but haven't yet looked at how easy it would be to backport. We would at least need no_new_privs as well. FWIW, I done a backport of (hopefully) all the relevant commits. I have picked the debian/3.2.17 tag from git://anonscm.debian.org/kernel/linux-2.6.git as target because I was too lazy to get the current debian source from svn. Hopefully the differences are not too big. The result is at http://people.debian.org/~sf/seccomp-filter-backport/ . It compiles and the included seccomp-filter sample programs work. That git tag actually represents 3.2.17 with bits removed for DFSG compliance, but without any bugfix or feature patches added. But I doubt we have anything that conflicts with these changes, though. Of course, all the patches need review. And it's quite possible that I have overlooked some important pieces, too. Noteworthy conflicts: 3.5 seems to have some seccomp audit infrastructure that is not in 3.2. I have left this out and left the basic logging in, instead. The latter was removed from 3.5 in 3dc1c1b2d2ed7507ce8a379814ad75745ff97ebe. fb0fadf9b213f55ca9368f3edafe51101d5d2deb defines PTRACE_EVENT_SECCOMP to 7, which is used by PTRACE_EVENT_STOP in 3.2. I have used 8 instead. Does this look reasonable to include in wheezy even this close to the freeze? I'll have a proper look at it later. Thanks for this. Ben. -- Ben Hutchings We get into the habit of living before acquiring the habit of thinking. - Albert Camus -- 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/20120607213820.ge2...@decadent.org.uk
Bug#675621: system freeze after safely unmounting usb drive
On Tue, Jun 05, 2012 at 09:05:42AM +0200, Rik Theys wrote: reassign 675621 linux-2.6 thanks Hi, I have seen similar crashes with the 6.0.x kernel on some of our systems. Unfortunately the systems are in a remote location and I was unable to capture any crash screens. [...] This sounds somewhat the bug fixed by: commit 8354a9e00afb022f6b508bd7d6bd74daebb8b751 Author: James Bottomley james.bottom...@hansenpartnership.com Date: Wed May 25 15:52:14 2011 -0500 Fix oops caused by queue refcounting failure commit e73e079bf128d68284efedeba1fbbc18d78610f9 upstream. or possibly: commit 5e4c1dbf52bc1ff33782266332a62151d5b5f0be Author: James Bottomley james.bottom...@suse.de Date: Wed May 18 16:20:10 2011 +0200 block: add proper state guards to __elv_next_request commit 0a58e077eb600d1efd7e54ad9926a75a39d7f8ae upstream. But we've had those since linux-2.6 version 2.6.32-36 (Debian release 6.0.3). So unless Sebastien has somehow failed to upgrade then this must be something different. We're really going to need a kernel log in order to make any progress on this. Ben. -- Ben Hutchings We get into the habit of living before acquiring the habit of thinking. - Albert Camus -- 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/20120607212211.gc2...@decadent.org.uk
Processed: tagging 675621
Processing commands for cont...@bugs.debian.org: tags 675621 + moreinfo Bug #675621 [src:linux-2.6] base: system freeze after safely unmounting usb drive Added tag(s) moreinfo. thanks Stopping processing here. Please contact me if you need assistance. -- 675621: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=675621 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.133910510925893.transcr...@bugs.debian.org
Bug#611107: ath5k phy0: noise floor calibration timeout
# 98a01747ba448e42b37bf6caaa596662c386a4d...@exmbc02.tcc.fl.edu found 611107 linux-2.6/2.6.32-45 # 2.6.32.59 tags 611107 + upstream REX ABERT wrote: Working through option 4 below. I am now running 2.6.32.59 kernel, and Noise Floor Calibration Timeout still occurs. Marking accordingly. [...] I have not yet applied the patches as described. I won't have the opportunity to do so until Monday. Ok, sounds good. Thanks for the updates. Looking forward to it, Jonathan -- 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/20120607231200.GB3236@burratino
Processed (with 5 errors): Re: ath5k phy0: noise floor calibration timeout
Processing commands for cont...@bugs.debian.org: # 98a01747ba448e42b37bf6caaa596662c386a4d...@exmbc02.tcc.fl.edu found 611107 linux-2.6/2.6.32-45 Bug #611107 [linux-2.6] ath5k: noise floor calibration timeout Marked as found in versions linux-2.6/2.6.32-45. # 2.6.32.59 tags 611107 + upstream Bug #611107 [linux-2.6] ath5k: noise floor calibration timeout Added tag(s) upstream. REX ABERT wrote: Unknown command or malformed arguments to command. Working through option 4 below. I am now running 2.6.32.59 kernel, Unknown command or malformed arguments to command. and Noise Floor Calibration Timeout still occurs. Unknown command or malformed arguments to command. Marking accordingly. Unknown command or malformed arguments to command. [...] Unknown command or malformed arguments to command. Too many unknown commands, stopping here. Please contact me if you need assistance. -- 611107: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=611107 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.133911073222758.transcr...@bugs.debian.org
Bug#662902: Please include the sbs-battery driver (CONFIG_BATTERY_SBS=m)
On Tue, 2012-03-06 at 21:49 -0800, Josh Triplett wrote: Package: linux-image-3.3.0-rc6-amd64 Severity: wishlist Please consider including the sbs-battery driver, CONFIG_BATTERY_SBS=m. This driver supports i2c-attached Smart Battery System batteries. I have an Atom board with such a battery. (Such batteries can exist on both 32-bit and 64-bit x86.) The same driver exists in 3.2, but under a different name (bq20z75). Do you think it would be useful to build it for wheezy too? Ben. -- Ben Hutchings I haven't lost my mind; it's backed up on tape somewhere. signature.asc Description: This is a digitally signed message part
Processed: tagging 662902
Processing commands for cont...@bugs.debian.org: tags 662902 + pending Bug #662902 [linux-2.6] Please include the sbs-battery driver (CONFIG_BATTERY_SBS=m) Added tag(s) pending. thanks Stopping processing here. Please contact me if you need assistance. -- 662902: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=662902 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.13391293399827.transcr...@bugs.debian.org
Processed: severity of 675621 is serious
Processing commands for cont...@bugs.debian.org: severity 675621 serious Bug #675621 [src:linux-2.6] base: system freeze after safely unmounting usb drive Severity set to 'serious' from 'critical' thanks Stopping processing here. Please contact me if you need assistance. -- 675621: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=675621 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.133912957810639.transcr...@bugs.debian.org
Bug#662902: Please include the sbs-battery driver (CONFIG_BATTERY_SBS=m)
On Fri, Jun 08, 2012 at 05:23:49AM +0100, Ben Hutchings wrote: On Tue, 2012-03-06 at 21:49 -0800, Josh Triplett wrote: Package: linux-image-3.3.0-rc6-amd64 Severity: wishlist Please consider including the sbs-battery driver, CONFIG_BATTERY_SBS=m. This driver supports i2c-attached Smart Battery System batteries. I have an Atom board with such a battery. (Such batteries can exist on both 32-bit and 64-bit x86.) The same driver exists in 3.2, but under a different name (bq20z75). Do you think it would be useful to build it for wheezy too? Less so, but yes. As far as I know, sbs-battery drives a superset of hardware, but bq20z75 does drive a useful subset (though one that doesn't include the hardware I actually have). Having bq20z75 in the wheezy 3.2 kernel wouldn't serve the particular purpose I had in mind for it, but it seems potentially useful. - Josh Triplett -- 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/20120608043612.GA30524@leaf
Bug#675934: st - slow tape read/write rate
06.06.2012 20:32, Jonathan Nieder wrote: How long does it typically take to reproduce the problem? I'll try that next week. I can't before, because this server is in production and restart it is some problem. I will give all information as soon as it will done. WBR, Yury O. Tabolin -- 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/4fd18f11.1060...@ies.udm.ru
