Bug#691576: GDB still broken with 3.11.10-1
Hi, And happy new year! 2013/12/20 Ben Hutchings b...@decadent.org.uk: I actually tried building the kernel like that, so you could try the packages in: http://people.debian.org/~benh/packages/wheezy-ia64-kernel-O1/ Was your O1-compiled kernel working fine? I have no idea as no-one has reported their results yet. It seems that optimization settings have impact on this problem. Ben, I couldn't install your 3.2 kernel version (too old for my current Debian install). However, I've recompiled with -O1 a -O2 non-working kernel configuration on my Gentoo install. No problem with -O1 :-) Keep in mind that this is just an observation on a single kernel version/flavour at the moment. Future will tell us if this problem really comes up with optimization settings. Émeric -- 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/CAA9xbM7_coD6iLof3utm4dNiQTRycRfJDYFPffqZjzFSO=g...@mail.gmail.com
Bug#723180: [PATCH] Revert x86: Disable IST stacks for debug/int 3/stack fault for PREEMPT_RT
* Andi Kleen | 2014-01-04 19:18:07 [+0100]: On Fri, Jan 03, 2014 at 02:55:48PM +0100, Sebastian Andrzej Siewior wrote: where do I start. Let me explain what is going on here. The code sequence Yes the IST stacks are needed for correctness, even in more cases than the example below. You cannot just disable them, just because you don't like them. Andi, you were the Author of that patch. I plan to migrate from the IST stack to the kernel stack so I can enable preemption. This is he case on 32bit. You mention more cases than this. Could you please give me some examples so I can consider them? -Andi Sebastian -- 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/20140106113230.ga25...@linutronix.de
Re: updating debian-kernel-handbook
On Mon, Jan 6, 2014 at 6:03 AM, Ben Hutchings b...@decadent.org.uk wrote: On Sat, 2014-01-04 at 15:32 +0100, Geert Stappers wrote: Op 2014-01-04 om 14:18 schreef Ian Campbell: On Sat, 2014-01-04 at 13:37 +0100, Geert Stappers wrote: Op 2013-12-14 om 16:01 schreef Ben Hutchings: That looks good; applied. Where is it applied? [ ] Where should I look for updates of the Debian kernel handbook? I suspect Ben just forgot to git push. Or Ben had another good reason for not yet git-pushing it. Such as Alioth not being avialable. The date could match. Thanks for the response. I'll send another reminder if needed. Yes, I think that must be it. I have pushed now. How about the http://kernel-handbook.alioth.debian.org web update? Ben. -- Ben Hutchings Everything should be made as simple as possible, but not simpler. - Albert Einstein Sh. Niew
Re: updating debian-kernel-handbook
On Mon, 2014-01-06 at 17:28 +0800, Niew, Sh. wrote: On Mon, Jan 6, 2014 at 6:03 AM, Ben Hutchings b...@decadent.org.uk wrote: On Sat, 2014-01-04 at 15:32 +0100, Geert Stappers wrote: Op 2014-01-04 om 14:18 schreef Ian Campbell: On Sat, 2014-01-04 at 13:37 +0100, Geert Stappers wrote: Op 2013-12-14 om 16:01 schreef Ben Hutchings: That looks good; applied. Where is it applied? [ ] Where should I look for updates of the Debian kernel handbook? I suspect Ben just forgot to git push. Or Ben had another good reason for not yet git-pushing it. Such as Alioth not being avialable. The date could match. Thanks for the response. I'll send another reminder if needed. Yes, I think that must be it. I have pushed now. How about the http://kernel-handbook.alioth.debian.org web update? That should be done now as well. Ben. -- Ben Hutchings Any smoothly functioning technology is indistinguishable from a rigged demo. signature.asc Description: This is a digitally signed message part
Processed: clone 734234 to linux-image-3.12-1-rt-amd64 (3.12.6-2)
Processing commands for cont...@bugs.debian.org: clone 734237 -1 Bug #734237 [btrfs-tools] btrfs-tools lockup with 3.12 RT kernel Bug 734237 cloned as bug 734370 reassign -1 linux-image-3.12-1-rt-amd64 Bug #734370 [btrfs-tools] btrfs-tools lockup with 3.12 RT kernel Bug reassigned from package 'btrfs-tools' to 'linux-image-3.12-1-rt-amd64'. No longer marked as found in versions btrfs-tools/3.12-1. Ignoring request to alter fixed versions of bug #734370 to the same values previously set retitle -1 btrfs lockup with 3.12 RT kernel Bug #734370 [linux-image-3.12-1-rt-amd64] btrfs-tools lockup with 3.12 RT kernel Changed Bug title to 'btrfs lockup with 3.12 RT kernel' from 'btrfs-tools lockup with 3.12 RT kernel' found-1 3.12.6-2 Bug #734370 [linux-image-3.12-1-rt-amd64] btrfs lockup with 3.12 RT kernel Marked as found in versions linux/3.12.6-2. thanks Stopping processing here. Please contact me if you need assistance. -- 734237: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=734237 734370: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=734370 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.138901731226989.transcr...@bugs.debian.org
Bug#734376: linux: Please enable accelerated variants of crypto modules
Source: linux Version: 3.12.6-2 Severity: normal Dear Maintainer, Please consider enabling more of the accelerated variants of the crypto modules available in the kernel. For example, the current kernel config contains: CONFIG_CRYPTO_CRCT10DIF=m # CONFIG_CRYPTO_CRCT10DIF_PCLMUL is not set CONFIG_CRYPTO_SHA1=y CONFIG_CRYPTO_SHA1_SSSE3=m # CONFIG_CRYPTO_SHA256_SSSE3 is not set # CONFIG_CRYPTO_SHA512_SSSE3 is not set CONFIG_CRYPTO_SHA256=m CONFIG_CRYPTO_SHA512=m CONFIG_CRYPTO_CAMELLIA=m CONFIG_CRYPTO_CAMELLIA_X86_64=m # CONFIG_CRYPTO_CAMELLIA_AESNI_AVX_X86_64 is not set # CONFIG_CRYPTO_CAMELLIA_AESNI_AVX2_X86_64 is not set CONFIG_CRYPTO_CAST5=m # CONFIG_CRYPTO_CAST5_AVX_X86_64 is not set CONFIG_CRYPTO_CAST6=m # CONFIG_CRYPTO_CAST6_AVX_X86_64 is not set CONFIG_CRYPTO_SERPENT=m CONFIG_CRYPTO_SERPENT_SSE2_X86_64=m CONFIG_CRYPTO_SERPENT_AVX_X86_64=m # CONFIG_CRYPTO_SERPENT_AVX2_X86_64 is not set For x86_64/amd64 at least, it would be nice to enable all of the options marked as 'not set' above. Thanks, Chris -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (990, 'testing'), (500, 'testing-updates'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.12-1-amd64 (SMP w/8 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- Chris Boot deb...@bootc.net GPG: 1DE8 6AB0 1897 A330 D973 D77C 50DD 5A29 FB09 -- 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/52cac80f.1070...@bootc.net
Re: updating debian-kernel-handbook
On Mon, Jan 6, 2014 at 10:07 PM, Ben Hutchings b...@decadent.org.uk wrote: On Mon, 2014-01-06 at 17:28 +0800, Niew, Sh. wrote: On Mon, Jan 6, 2014 at 6:03 AM, Ben Hutchings b...@decadent.org.uk wrote: On Sat, 2014-01-04 at 15:32 +0100, Geert Stappers wrote: Op 2014-01-04 om 14:18 schreef Ian Campbell: On Sat, 2014-01-04 at 13:37 +0100, Geert Stappers wrote: Op 2013-12-14 om 16:01 schreef Ben Hutchings: That looks good; applied. Where is it applied? [ ] Where should I look for updates of the Debian kernel handbook? I suspect Ben just forgot to git push. Or Ben had another good reason for not yet git-pushing it. Such as Alioth not being avialable. The date could match. Thanks for the response. I'll send another reminder if needed. Yes, I think that must be it. I have pushed now. How about the http://kernel-handbook.alioth.debian.org web update? That should be done now as well. Thanks. Ben. -- Ben Hutchings Any smoothly functioning technology is indistinguishable from a rigged demo. Sh. Niew
Bug#734381: linux-image-3.12-1-amd64: freezes after suspend
Package: src:linux Version: 3.12.6-2 Severity: important Dear Maintainer, my system freezes after returning from suspension. It doesn't happen with linux-image-3.11-2-amd (which I still have installed). I consider this as _important_ severity because on netbooks one suspends pretty often. I can't get anything on syslog. I see the messages when it's suspending and only some weird characters after I hard reboot the machine. Let me know if you need any debug info or you want me to try anything else. Regards, -- Package-specific info: ** Version: Linux version 3.12-1-amd64 (debian-kernel@lists.debian.org) (gcc version 4.8.2 (Debian 4.8.2-10) ) #1 SMP Debian 3.12.6-2 (2013-12-29) ** Command line: BOOT_IMAGE=/boot/vmlinuz-3.12-1-amd64 root=/dev/mapper/omoloko-root ro quiet rootflags=data=writeback initcall_debug printk.time=y init=/bin/systemd ** Not tainted ** Kernel log: [4.518155] initcall ppdev_init+0x0/0x1000 [ppdev] returned 0 after 642 usecs [4.521172] systemd-logind[1068]: Watching system buttons on /dev/input/event3 (Lid Switch) [4.521231] systemd-logind[1068]: Watching system buttons on /dev/input/event2 (Sleep Button) [4.522711] calling parport_pc_init+0x0/0xf4f [parport_pc] @ 1169 [4.522898] initcall parport_pc_init+0x0/0xf4f [parport_pc] returned 0 after 177 usecs [4.524176] calling bnep_init+0x0/0x9a [bnep] @ 1175 [4.524178] Bluetooth: BNEP (Ethernet Emulation) ver 1.3 [4.524179] Bluetooth: BNEP filters: protocol multicast [4.524185] Bluetooth: BNEP socket layer initialized [4.524187] initcall bnep_init+0x0/0x9a [bnep] returned 0 after 8 usecs [4.528739] calling rfcomm_init+0x0/0xdc [rfcomm] @ 1207 [4.528838] Bluetooth: RFCOMM TTY layer initialized [4.528848] Bluetooth: RFCOMM socket layer initialized [4.528849] Bluetooth: RFCOMM ver 1.11 [4.528853] initcall rfcomm_init+0x0/0xdc [rfcomm] returned 0 after 106 usecs [4.529360] psmouse serio2: synaptics: Touchpad model: 1, fw: 7.2, id: 0x1c0b1, caps: 0xd04733/0xa4/0xa, board id: 3655, fw id: 582762 [4.554415] calling cpufreq_gov_userspace_init+0x0/0x1000 [cpufreq_userspace] @ 1249 [4.554420] initcall cpufreq_gov_userspace_init+0x0/0x1000 [cpufreq_userspace] returned 0 after 0 usecs [4.563700] calling cpufreq_gov_dbs_init+0x0/0x1000 [cpufreq_conservative] @ 1267 [4.563705] initcall cpufreq_gov_dbs_init+0x0/0x1000 [cpufreq_conservative] returned 0 after 0 usecs [4.570393] input: SynPS/2 Synaptics TouchPad as /devices/platform/i8042/serio2/input/input12 [4.594504] calling cpufreq_gov_powersave_init+0x0/0x1000 [cpufreq_powersave] @ 1275 [4.594508] initcall cpufreq_gov_powersave_init+0x0/0x1000 [cpufreq_powersave] returned 0 after 0 usecs [4.594672] calling joydev_init+0x0/0x1000 [joydev] @ 1277 [4.594678] initcall joydev_init+0x0/0x1000 [joydev] returned 0 after 2 usecs [4.634329] calling cpufreq_stats_init+0x0/0x1000 [cpufreq_stats] @ 1288 [4.634334] initcall cpufreq_stats_init+0x0/0x1000 [cpufreq_stats] returned 0 after 1 usecs [4.642765] calling acpi_cpufreq_init+0x0/0x1000 [acpi_cpufreq] @ 1318 [4.642768] initcall acpi_cpufreq_init+0x0/0x1000 [acpi_cpufreq] returned -17 after 0 usecs [4.786137] [drm] Enabling RC6 states: RC6 on, RC6p on, RC6pp off [4.958802] r8169 :03:00.2: firmware: direct-loading firmware rtl_nic/rtl8411-1.fw [5.028572] r8169 :03:00.2 eth0: link down [5.028596] r8169 :03:00.2 eth0: link down [5.028639] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready [5.511574] input: ACPI Virtual Keyboard Device as /devices/virtual/input/input20 [5.575718] calling xt_init+0x0/0x1000 [x_tables] @ 1567 [5.575724] initcall xt_init+0x0/0x1000 [x_tables] returned 0 after 0 usecs [5.576479] calling ebtables_init+0x0/0x1000 [ebtables] @ 1567 [5.576481] Ebtables v2.0 registered [5.576484] initcall ebtables_init+0x0/0x1000 [ebtables] returned 0 after 1 usecs [5.577277] calling ebtable_nat_init+0x0/0x1000 [ebtable_nat] @ 1569 [5.577283] initcall ebtable_nat_init+0x0/0x1000 [ebtable_nat] returned 0 after 3 usecs [5.580919] calling ip_tables_init+0x0/0x1000 [ip_tables] @ 1572 [5.580927] ip_tables: (C) 2000-2006 Netfilter Core Team [5.580930] initcall ip_tables_init+0x0/0x1000 [ip_tables] returned 0 after 7 usecs [5.581918] calling iptable_filter_init+0x0/0x1000 [iptable_filter] @ 1574 [5.582011] initcall iptable_filter_init+0x0/0x1000 [iptable_filter] returned 0 after 86 usecs [5.584963] calling ip6_tables_init+0x0/0x1000 [ip6_tables] @ 1577 [5.584970] ip6_tables: (C) 2000-2006 Netfilter Core Team [5.584972] initcall ip6_tables_init+0x0/0x1000 [ip6_tables] returned 0 after 5 usecs [5.585931] calling ip6table_filter_init+0x0/0x1000 [ip6table_filter] @ 1579 [5.586014] initcall ip6table_filter_init+0x0/0x1000 [ip6table_filter] returned 0 after 77 usecs [6.917841] r8169 :03:00.2
Bug#734172: didn't work
disabling send_page didn't work. something a simple as a tar from one gfs2 to another made it crash again. :-(
Bug#733826: crazy loop xhci_hcd Too many fragments
On Mon, Jan 06, 2014 at 03:52:24PM +, David Laight wrote: From: Alan Stern Subject: Re: Bug#733826: crazy loop xhci_hcd Too many fragments On Mon, 6 Jan 2014, Ben Hutchings wrote: On Sat, 2014-01-04 at 05:44 +0800, jida...@jidanni.org wrote: ... # cat /var/log/syslog Jan 1 06:57:38 jidanni5 ntpd[2822]: Listen normally on 5 lo ::1 UDP 123 Jan 1 06:57:38 jidanni5 ntpd[2822]: Listen normally on 6 eth0 fe80::2289:84ff:fe28:ad9 UDP 123 Jan 1 06:57:38 jidanni5 ntpd[2822]: peers refreshed Jan 1 06:57:38 jidanni5 ntpd[2822]: Listening on routing socket on fd #23 for interface updates Jan 1 07:04:49 jidanni5 kernel: [ 559.624680] xhci_hcd :00:14.0: Too many fragments 79, max 63 Jan 1 07:04:49 jidanni5 kernel: [ 559.624695] xhci_hcd :00:14.0: Too many fragments 79, max 63 Jan 1 07:04:49 jidanni5 kernel: [ 559.624704] xhci_hcd :00:14.0: Too many fragments 79, max 63 10 lines later... oops I mean an actual MILLION lines later Assuming my fix for the repetition is correct, the remaining problem is why usb-storage is generating such large/fragmented urbs. usb-storage doesn't generate large or fragmented anything. It merely passes on the scatter-gather information it gets from the block layer. Although not a real fix to the underlying problem, it seems that the default ring size is far too small. Did you mean ring segment size? Any amount of network traffic also activates the ring expansion code. IIRC each ring entry is 16 bytes, so increasing the ring size to 256 still keeps the rings to a single 4k page. Whether anything regularly exceeds 255 fragments is a another matter. If so, yes, changing the segment size makes sense. TRBS_PER_SEGMENT could be increased to 256. I'm not sure if we should switch to using dma_alloc_coherent instead of a DMA pool. Some systems could be using bigger than 4K pages, so we should probably still stick with DMA pools. Ben, can you change your patch to increase TRBS_PER_SEGMENT to 256? Sarah Sharp -- 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/20140106174059.GA5290@xanatos
Bug#734172: similar to
Looks somewhat similar to https://bugzilla.redhat.com/show_bug.cgi?id=1023431
Bug#733826: crazy loop xhci_hcd Too many fragments
On Mon, Jan 06, 2014 at 10:06:33AM -0500, Alan Stern wrote:
On Mon, 6 Jan 2014, Ben Hutchings wrote:
On Sat, 2014-01-04 at 05:44 +0800, jida...@jidanni.org wrote:
BH == Ben Hutchings b...@decadent.org.uk writes:
BH And what were those error messages?
BH Which USB devices are you using (this is probably disk or network
BH related)?
I had done an aptitude update on writing onto
# fdisk -l
Disk /dev/sdg: 3867 MB, 3867148288 bytes
OK, the important thing is it's usb-storage.
181 heads, 32 sectors/track, 1304 cylinders, total 7553024 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0xc3072e18
# mount
Device Boot Start End Blocks Id System
/dev/sdg1 32 868799 434384 83 Linux
/dev/sdg2 868800 7553023 3342112 83 Linux
/dev/sdg2 on /var/cache/apt/archives type ext3
(rw,noatime,errors=remount-ro,data=ordered)
/dev/sdg1 on /var/lib/apt/lists type ext3
(rw,noatime,errors=remount-ro,data=ordered)
# cat /var/log/syslog
Jan 1 06:57:38 jidanni5 ntpd[2822]: Listen normally on 5 lo ::1 UDP 123
Jan 1 06:57:38 jidanni5 ntpd[2822]: Listen normally on 6 eth0
fe80::2289:84ff:fe28:ad9 UDP 123
Jan 1 06:57:38 jidanni5 ntpd[2822]: peers refreshed
Jan 1 06:57:38 jidanni5 ntpd[2822]: Listening on routing socket on fd
#23 for interface updates
Jan 1 07:04:49 jidanni5 kernel: [ 559.624680] xhci_hcd :00:14.0:
Too many fragments 79, max 63
Jan 1 07:04:49 jidanni5 kernel: [ 559.624695] xhci_hcd :00:14.0:
Too many fragments 79, max 63
Jan 1 07:04:49 jidanni5 kernel: [ 559.624704] xhci_hcd :00:14.0:
Too many fragments 79, max 63
10 lines later... oops I mean an actual MILLION lines later
Assuming my fix for the repetition is correct, the remaining problem is
why usb-storage is generating such large/fragmented urbs.
usb-storage doesn't generate large or fragmented anything. It merely
passes on the scatter-gather information it gets from the block layer.
And the block layer depends on drivers to tell it what their
scatter-gather capabilities are.
The answer appears to be that xhci is lying:
int xhci_gen_setup(struct usb_hcd *hcd, xhci_get_quirks_t get_quirks)
{
[...]
/* Accept arbitrarily long scatter-gather lists */
hcd-self.sg_tablesize = ~0;
and this value gets copied up the stack to the block layer.
Ben.
--
Ben Hutchings
The two most common things in the universe are hydrogen and stupidity.
--
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/20140106194415.gg5...@decadent.org.uk
Bug#733826: [PATCH] xhci: Set scatter-gather limit to avoid failed block writes.
Dan, can you test this patch, on top of the other patch that Ben sent?
There's directions for building a custom kernel here, if you need it:
http://kernelnewbies.org/KernelBuild
I suggest either getting the Debian kernel source and patching that, or
patching 3.12.6 or later.
Sarah Sharp
8--8
Commit 35773dac5f862cb1c82ea151eba3e2f6de51ec3e usb: xhci: Link TRB
must not occur within a USB payload burst attempted to fix an issue
found with USB ethernet adapters, and inadvertently broke USB storage
devices. The patch attempts to ensure that transfers never span a
segment, and rejects transfers that have more than 63 entries (or
possibly less, if some entries cross 64KB boundaries).
usb-storage limits the maximum transfer size to 120K, and we had assumed
the block layer would pass a scatter-gather list of 4K entries,
resulting in no more than 31 sglist entries:
http://marc.info/?l=linux-usbm=138498190419312w=2
That assumption was wrong, since we've seen the driver reject a write
that was 218 sectors long (of probably 512 bytes each):
Jan 1 07:04:49 jidanni5 kernel: [ 559.624704] xhci_hcd :00:14.0: Too many
fragments 79, max 63
...
Jan 1 07:04:58 jidanni5 kernel: [ 568.622583] Write(10): 2a 00 00 06 85 0e 00
00 da 00
Limit the number of scatter-gather entries to half a ring segment. That
should be margin enough in case some entries cross 64KB boundaries.
Increase the number of TRBs per segment from 64 to 256, which should
result in ring segments fitting on a 4K page.
Signed-off-by: Sarah Sharp sarah.a.sh...@linux.intel.com
---
drivers/usb/host/xhci.c | 4 ++--
drivers/usb/host/xhci.h | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 4265b48856f6..d45a0d584daf 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -4713,8 +4713,8 @@ int xhci_gen_setup(struct usb_hcd *hcd, xhci_get_quirks_t
get_quirks)
struct device *dev = hcd-self.controller;
int retval;
- /* Accept arbitrarily long scatter-gather lists */
- hcd-self.sg_tablesize = ~0;
+ /* Limit the block layer scatter-gather lists to half a segment. */
+ hcd-self.sg_tablesize = TRBS_PER_SEGMENT / 2;
/* support to build packet from discontinuous buffers */
hcd-self.no_sg_constraint = 1;
diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h
index 03c74b7965f8..c283cf183c48 100644
--- a/drivers/usb/host/xhci.h
+++ b/drivers/usb/host/xhci.h
@@ -1260,7 +1260,7 @@ union xhci_trb {
* since the command ring is 64-byte aligned.
* It must also be greater than 16.
*/
-#define TRBS_PER_SEGMENT 64
+#define TRBS_PER_SEGMENT 256
/* Allow two commands + a link TRB, along with any reserved command TRBs */
#define MAX_RSVD_CMD_TRBS (TRBS_PER_SEGMENT - 3)
#define TRB_SEGMENT_SIZE (TRBS_PER_SEGMENT*16)
--
1.8.3.3
--
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/20140106214250.GA9728@xanatos
Bug#734403: linux-image-3.12-1-amd64: shutdown -h now makes computer restart
Package: src:linux Version: 3.12.6-2 Severity: normal hi there, the last aptitude upgrade my kernel got updated to 3.12-1-amd64, since then something very strange happens: when i do a shutdown -h now, thge computer shuts down as expected, and all lights and fans go off. but after a few more seconds, the whole thing restarts itself, a bit of a zombie moment. I originally expected this to be some bizarre hardware thing, but then I found a report [0] linking this to the kernel (different version in their case). I still had linux-image-3.11-2-amd64 installed, so I rebooted into that and retried (a couple of times to make sure), and i'll be damned but that kernel does the shutdown fine! I have no clue how all that ACPI or whatever works, bbut something there isn't ideal. happy to try a few things if you point me in the right direction regards robert [0] http://forums.fedoraforum.org/showthread.php?t=83325 -- Package-specific info: ** Version: Linux version 3.12-1-amd64 (debian-kernel@lists.debian.org) (gcc version 4.8.2 (Debian 4.8.2-10) ) #1 SMP Debian 3.12.6-2 (2013-12-29) ** Command line: BOOT_IMAGE=/boot/vmlinuz-3.12-1-amd64 root=UUID=a7b74474-6a33-468b-841f-7708fb39db9b ro quiet ** Tainted: O (4096) * Out-of-tree module has been loaded. ** Kernel log: [2.739649] input: HDA Intel PCH Front Headphone as /devices/pci:00/:00:1b.0/sound/card1/input16 [2.739666] input: HDA Intel PCH Line Out CLFE as /devices/pci:00/:00:1b.0/sound/card1/input15 [2.739680] input: HDA Intel PCH Line Out Surround as /devices/pci:00/:00:1b.0/sound/card1/input14 [2.739696] input: HDA Intel PCH Line Out Front as /devices/pci:00/:00:1b.0/sound/card1/input13 [2.739715] input: HDA Intel PCH Line as /devices/pci:00/:00:1b.0/sound/card1/input12 [2.739735] input: HDA Intel PCH Rear Mic as /devices/pci:00/:00:1b.0/sound/card1/input11 [2.739756] input: HDA Intel PCH Front Mic as /devices/pci:00/:00:1b.0/sound/card1/input10 [2.740392] i801_smbus :00:1f.3: SMBus using PCI Interrupt [2.741047] [drm] Memory usable by graphics device = 2048M [2.741052] i915 :00:02.0: setting latency timer to 64 [2.744200] alg: No test for crc32 (crc32-pclmul) [2.764177] i915 :00:02.0: irq 59 for MSI/MSI-X [2.764186] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). [2.764187] [drm] Driver supports precise vblank timestamp query. [2.764240] vgaarb: device changed decodes: PCI::00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem [2.780393] media: Linux media interface: v0.10 [2.781771] Linux video capture interface: v2.00 [2.783802] uvcvideo: Found UVC 1.00 device unnamed (046d:080f) [2.824732] input: UVC Camera (046d:080f) as /devices/pci:00/:00:14.0/usb1/1-9/1-9:1.0/input/input17 [2.824857] usbcore: registered new interface driver uvcvideo [2.824859] USB Video Class driver (1.1.1) [2.825110] ata7.00: configured for UDMA/133 [2.825113] ata7: EH complete [2.825169] sd 6:0:0:0: [sdc] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [2.877886] md: bindsdb1 [2.878684] md: bindsdc1 [2.880110] md: raid1 personality registered for level 1 [2.880247] md/raid1:md0: active with 2 out of 2 mirrors [2.880342] created bitmap (4 pages) for device md0 [2.880477] md0: bitmap initialized from disk: read 1 pages, set 0 of 7451 bits [2.886097] md0: detected capacity change from 0 to 499972571136 [2.902531] md0: unknown partition table [2.956412] bcache: register_bdev() registered backing device md0 [2.957874] bcache: bch_cached_dev_attach() Caching md0 as bcache0 on set 8866e7fe-4e4e-4f64-be47-8e52e6843a72 [3.077945] fbcon: inteldrmfb (fb0) is primary device [3.249280] Console: switching to colour frame buffer device 210x65 [3.251550] i915 :00:02.0: fb0: inteldrmfb frame buffer device [3.251551] i915 :00:02.0: registered panic notifier [3.304019] acpi device:61: registered as cooling_device13 [3.304039] ACPI: Video Device [GFX0] (multi-head: yes rom: no post: no) [3.304060] input: Video Bus as /devices/LNXSYSTM:00/device:00/PNP0A08:00/LNXVIDEO:00/input/input18 [3.304164] [drm] Initialized i915 1.6.0 20080730 for :00:02.0 on minor 0 [3.304216] ACPI Warning: 0x1828-0x182f SystemIO conflicts with Region \PMIO 1 (20130725/utaddress-251) [3.304220] ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver [3.304223] ACPI Warning: 0x1c30-0x1c3f SystemIO conflicts with Region \GPRL 1 (20130725/utaddress-251) [3.304226] ACPI Warning: 0x1c30-0x1c3f SystemIO conflicts with Region \GPR_ 2 (20130725/utaddress-251) [3.304228] ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver [3.304229] ACPI
Bug#733826: [PATCH] xhci: Set scatter-gather limit to avoid failed block writes.
Don't worry, I'll trust you! Plus I'm 53. -- 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/87ob3o67fo@jidanni.org
Bug#733826: [PATCH] xhci: Set scatter-gather limit to avoid failed block writes.
On Tue, 2014-01-07 at 07:01 +0800, jida...@jidanni.org wrote: Don't worry, I'll trust you! Plus I'm 53. I don't think anyone else has reproduced this problem, so you are the person in the best place to check that these changes really fix it. You can test patches against the Debian kernel package by following the instructions here: http://kernel-handbook.alioth.debian.org/ch-common-tasks.html#s-common-official Ben. -- Ben Hutchings Any smoothly functioning technology is indistinguishable from a rigged demo. signature.asc Description: This is a digitally signed message part
Bug#734172: similar to
On Mon, 2014-01-06 at 16:08 -0200, Federico Gimenez wrote: Looks somewhat similar to https://bugzilla.redhat.com/show_bug.cgi?id=1023431 I don't think so, that's a BUG versus an Oops and not in the same function. Ben. -- Ben Hutchings Any smoothly functioning technology is indistinguishable from a rigged demo. signature.asc Description: This is a digitally signed message part
Bug#734403: linux-image-3.12-1-amd64: shutdown -h now makes computer restart
Control: tag -1 moreinfo On Mon, 2014-01-06 at 22:19 +, Robert Lemmen wrote: Package: src:linux Version: 3.12.6-2 Severity: normal hi there, the last aptitude upgrade my kernel got updated to 3.12-1-amd64, since then something very strange happens: when i do a shutdown -h now, thge computer shuts down as expected, and all lights and fans go off. but after a few more seconds, the whole thing restarts itself, a bit of a zombie moment. I originally expected this to be some bizarre hardware thing, but then I found a report [0] linking this to the kernel (different version in their case). I still had linux-image-3.11-2-amd64 installed, so I rebooted into that and retried (a couple of times to make sure), and i'll be damned but that kernel does the shutdown fine! I have no clue how all that ACPI or whatever works, bbut something there isn't ideal. Many devices can generate a wake-up signal after the computer is shut down (wake on LAN, wake on key, etc.) and this is evidently happening when it should not. So it is hardware-related but probably caused by a change in the way a driver prepares the hardware for shutdown. happy to try a few things if you point me in the right direction [...] Please try to work out which driver is doing this, by removing a driver with the 'rmmod' command and then shutting down. I think it is probably one of: e1000e igb xhci_hcd ehci-pci Ben. -- Ben Hutchings Any smoothly functioning technology is indistinguishable from a rigged demo. signature.asc Description: This is a digitally signed message part
Processed: Re: Bug#734403: linux-image-3.12-1-amd64: shutdown -h now makes computer restart
Processing control commands: tag -1 moreinfo Bug #734403 [src:linux] linux-image-3.12-1-amd64: shutdown -h now makes computer restart Added tag(s) moreinfo. -- 734403: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=734403 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.b734403.138906300815815.transcr...@bugs.debian.org
Bug#691576: GDB still broken with 3.11.10-1
On Mon, 2014-01-06 at 10:15 +0100, Émeric MASCHINO wrote: Hi, And happy new year! 2013/12/20 Ben Hutchings b...@decadent.org.uk: I actually tried building the kernel like that, so you could try the packages in: http://people.debian.org/~benh/packages/wheezy-ia64-kernel-O1/ Was your O1-compiled kernel working fine? I have no idea as no-one has reported their results yet. It seems that optimization settings have impact on this problem. Ben, I couldn't install your 3.2 kernel version (too old for my current Debian install). [...] I don't understand that - I still have 3.2 installed on this unstable (i386) system and can still boot it. How does it go wrong? I really need to know whether -O1 works for 3.2; I can't just speculatively change it in a stable update. Ben. -- Ben Hutchings Any smoothly functioning technology is indistinguishable from a rigged demo. signature.asc Description: This is a digitally signed message part
Bug#734430: linux-image-3.12-1-armmp: Enable BRCMFMAC wireless drivers
Package: linux-image-3.12-1-armmp Version: 3.12.6-2 Severity: wishlist Tags: patch Please enable the Broadcom IEEE802.11n embedded FullMAC WLAN driver, which is used in the wandboard quad. --- a/config/armhf/config.armmp +++ b/config/armhf/config.armmp @@ -451,6 +451,12 @@ CONFIG_SKFP=m CONFIG_MDIO_SUN4I=y ## +## file: drivers/net/wireless/brcm80211/Kconfig +## +CONFIG_BRCMFMAC=m +CONFIG_BRCMFMAC_SDIO=m + +## ## file: drivers/net/wireless/ti/Kconfig ## CONFIG_WL_TI=m Thanks! live well, vagrant signature.asc Description: Digital signature
Processing of linux_3.12.6-2~bpo70+1_multi.changes
linux_3.12.6-2~bpo70+1_multi.changes uploaded successfully to localhost along with the files: linux_3.12.6-2~bpo70+1.dsc linux_3.12.6-2~bpo70+1.debian.tar.xz linux-support-3.12-0.bpo.1_3.12.6-2~bpo70+1_all.deb linux-doc-3.12_3.12.6-2~bpo70+1_all.deb linux-manual-3.12_3.12.6-2~bpo70+1_all.deb linux-source-3.12_3.12.6-2~bpo70+1_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/e1w0p0w-0002go...@franck.debian.org
linux_3.12.6-2~bpo70+1_multi.changes is NEW
binary:linux-doc-3.12 is NEW. binary:linux-manual-3.12 is NEW. binary:linux-support-3.12-0.bpo.1 is NEW. binary:linux-source-3.12 is NEW. Your package contains new components which requires manual editing of the override file. It is ok otherwise, so please be patient. New packages are usually added to the override file about once a week. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1w0p3k-0002yg...@franck.debian.org
