Bug#708070: enable x32 support for the amd64 kernels
On Fri, 25 Jul 2014, Ben Hutchings wrote: No, there should be no extra kernel flavours for i386 or amd64. Hmm, still not getting this. I thought the point of flavours was to split off options that, though popular, have undesirable side effects. I had an idea how to unblock this, and finally got round to trying it, and it seems to work. That is, we build in x32 support but require a run-time parameter to enable. So, please try the attached patch (against the sid branch), adding syscall.x32=y to the kernel command line. But this sounds perfectly acceptable. The general instructions for building a patched package are: http://kernel-handbook.alioth.debian.org/ch-common-tasks.html#s-common-official. Oh, yes ... I remember that :-( You'll need to follow subsection 4.2.3 and apply the patch like so: patch -p1 ../x86-syscall-make-x32-syscall-support-conditional.patch quilt push Will try this shortly. Though I may have to spin up a VM to build it. -- Rob. (Robert de Bath robert$ @ debath.co.uk) http://www.debath.co.uk/ -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/alpine.DEB.2.02.1407250809080.25477@mayday
Bug#755995: External USB HD problem in linux kernel 3.16 with usb-uas module
Package: linux-image-3.16-rc6-amd64 Version: 3.16~rc6-1~exp1 Severity: important Dear Maintainer, After upgrading linux to 3.16-rc6 I have problems with my Seagate expansion hard drive. While mounting it or writing to it, my whole system quite often freezes and needs a hard reset. It seems to be a known UAS (USB Attached SCSI) issue and there is a workaround, see https://bbs.archlinux.org/viewtopic.php?id=183190 The mentioned workaround fixes the issue by telling the USB-UAS module to ignore the device. To avoid this issue the UAS module should be patched to handle the hard disk correctly. -- System Information: Debian Release: jessie/sid Architecture: amd64 (x86_64) Kernel: linux-image-3.16-rc6-amd64 Systemd, udev: 208-3 Kind regards, Jos v.Wolput -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53d22d12.2040...@openmailbox.org
Re: Random panic in load_balance() with 3.16-rc
On Thu, Jul 24, 2014 at 08:55:28PM -0700, Alexei Starovoitov wrote: -mno-red-zone only affected prologue emition in gcc. This part didn't change between the releases. So the bug is quite deep. What seems to be happening is that 2nd pass of instruction scheduler (after emit prologue and reg alloc) is ignoring barrier properties of 'subq $184, %rsp' and moving 'movq $.., -136(%rbp)' instruction ahead of it. afaik rtl sched was never aware of 'red-zone'. As an ex-compiler guy, I'm worried that this bug exists in earlier releases. rtl backend guys need to take a serious look at it. imo this is very serious bug, since broken red-zone is extremelly hard to debug. But wouldn't it be rather trivial to run a static analyzer on the final vmlinux to make sure there are no red zones? I mean, you would only need to read each function and check to make sure that the offset of rbp is within the change of rsp, wouldn't you? Almost seems like an objdump -rd into a perl script could do this. -- Steve There are two weak test in gcc testsuite related to -mno-red-zone, but not a single test that actually check that it is doing the right thing. It is scary. I hope I'm wrong with this analysis. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140725140237.gb32...@home.goodmis.org
Bug#741239: This may be caused by buggy ROM RAID code...here's my evidence...
My system: Linux nodename 3.2.61-030261-generic #201407112035 SMP Sat Jul 12 00:36:16 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux Running an i7 on X79 board. I got rid of these error messages and the slow behavior by turning off the ROM RAID stuff and rebuilding my RAID array using just the Linux Software RAID. Note, one other thing changed that may also be important. Because I made a mistake when I partitioned the new RAID array, I am no longer running a swap on the RAID. Instead it is running on the single drive that also houses the root and boot partitions. I could not get reliable booting on my system if the OS was on the RAID. Jonathan Dr. Jonathan H. Gutow Chemistry Department gu...@uwosh.edu UW-Oshkosh Office:920-424-1326 800 Algoma Boulevard FAX:920-424-2042 Oshkosh, WI 54901 http://www.uwosh.edu/facstaff/gutow/ -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5b45823d-c835-49a3-aa8e-e272e21c1...@uwosh.edu
Processed: unarchiving 686636, reopening 686636
Processing commands for cont...@bugs.debian.org:
unarchive 686636
Bug #686636 {Done: Ben Hutchings b...@decadent.org.uk} [linux] Please
backport virtio-scsi to wheezy
Unarchived Bug 686636
# virtio-modules udeb needs updating too
reopen 686636
Bug #686636 {Done: Ben Hutchings b...@decadent.org.uk} [linux] Please
backport virtio-scsi to wheezy
'reopen' may be inappropriate when a bug has been closed with a version;
all fixed versions will be cleared, and you may need to re-add them.
Bug reopened
No longer marked as fixed in versions linux/3.2.39-1.
thanks
Stopping processing here.
Please contact me if you need assistance.
--
686636: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=686636
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:
https://lists.debian.org/handler.s.c.140630994924360.transcr...@bugs.debian.org
Bug#756049: [L10N,DE] linux: updated german debconf translation
Package: linux Severity: wishlist Tags: patch,l10n Hi, attached is the updated german debconf translation for linux (version 3.14.12-2). Please include it in your package. Thanks for your i18n efforts. So long Holger -- Holger Wansing hwans...@mailbox.org linux-3.14.12-2_de.po.gz Description: Binary data
Bug#686636: Please backport virtio-scsi to wheezy
Hi, The virtio_scsi module got backported to the 3.2.39-1 kernel, but it appears it didn't get added to the virtio-modules udeb for the wheezy kernels -- which means you can switch to using it for an already installed wheezy guest in a VM, but you can't install a new VM configured to use it with the wheezy installer. Please consider adding this to virtio-modules for the wheezy branch to complete this (very welcome!) backport. Thanks! Ron -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140725175335.gv2...@hex.shelbyville.oz
Re: Random panic in load_balance() with 3.16-rc
On Fri, Jul 25, 2014 at 7:02 AM, Steven Rostedt rost...@goodmis.org wrote: But wouldn't it be rather trivial to run a static analyzer on the final vmlinux to make sure there are no red zones? I mean, you would only need to read each function and check to make sure that the offset of rbp is within the change of rsp, wouldn't you? Almost seems like an objdump -rd into a perl script could do this. I'm sure it's possible, but it sounds potentially complicated. It's not like the function prologue is fixed, and gcc will create code (including conditional branches etc) before the whole frame setup if there are simple things that can be done purely with the callee-clobbered registers etc. Some simple pattern to make sure that the sub $frame-size,%rsp comes before any accesses to (%rbp) (when frame pointers are enabled) *might* work, but it might also end up missing things. You want to try? Linus -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CA+55aFzOoJzqJ=4rvpebfsca8ordr5nv7fkx9axyw2+frku...@mail.gmail.com
Re: Random panic in load_balance() with 3.16-rc
On Fri, 25 Jul 2014 11:29:06 -0700 Linus Torvalds torva...@linux-foundation.org wrote: On Fri, Jul 25, 2014 at 7:02 AM, Steven Rostedt rost...@goodmis.org wrote: But wouldn't it be rather trivial to run a static analyzer on the final vmlinux to make sure there are no red zones? I mean, you would only need to read each function and check to make sure that the offset of rbp is within the change of rsp, wouldn't you? Almost seems like an objdump -rd into a perl script could do this. I'm sure it's possible, but it sounds potentially complicated. It's not like the function prologue is fixed, and gcc will create code (including conditional branches etc) before the whole frame setup if there are simple things that can be done purely with the callee-clobbered registers etc. Some simple pattern to make sure that the sub $frame-size,%rsp comes before any accesses to (%rbp) (when frame pointers are enabled) *might* work, but it might also end up missing things. You want to try? Yeah, I could write something up. I probably wont get to it for a week or two, but it shouldn't be too hard. As you said, it will probably miss the complex cases where gcc finishes the frame later in the function or with branches and such. But at least it should be able to catch any totally retard set up. I compiled Michel's file and I'll make sure that it at least catches that: 3572: 48 c7 85 78 ff ff ffmovq $0x0,-0x88(%rbp) 3579: 00 00 00 00 3579: R_X86_64_32S load_balance_mask 357d: 48 81 ec b8 00 00 00sub$0xb8,%rsp -- Steve -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140725151011.148db...@gandalf.local.home
Re: Random panic in load_balance() with 3.16-rc
On Fri, Jul 25, 2014 at 11:29 AM, Linus Torvalds
torva...@linux-foundation.org wrote:
Some simple pattern to make sure that the sub $frame-size,%rsp comes
before any accesses to (%rbp) (when frame pointers are enabled)
*might* work, but it might also end up missing things.
You're going to have a hard time doing that pattern. Just for fun, I
did something really quick in awk:
/:/ { state = 0 }
/%rsp,%rbp/ { state = 1 }
/\$.*rsp/ { state = 2 }
/lea/ { next }
/\(%rbp\)/ { if (state == 1) print Error: $0; state = 2; }
which is incomprehensible line noise, but it's a trivial state machine
where beginning of function starts state 0, mov %rsp,%rbp starts
state 1 (have frame pointer in function), sub/add constant of %rsp
starts state 2 (created frame), and then we ignore lea (because we
don't follow address calculations off %rbp) and error out if we see an
access through %rbp in a function with a frame pointer but without a
frame created.
That thing is excessively stupid, in other words, but hey, it's good
to see ok, what does that tell us.
And what it tells me is that gcc does some crazy things.
For example, gcc will not create a small stack frame with sub
$8,%rsp. No, what gcc does is to use a random push instruction.
Fair enough, but that really makes things much harder to see. Here's
an example:
813143a3 dock_notify:
813143a3: 55 push %rbp
813143a4: 48 89 e5mov%rsp,%rbp
813143a7: 41 57 push %r15
813143a9: 41 56 push %r14
813143ab: 49 89 femov%rdi,%r14
813143ae: 41 55 push %r13
813143b0: 41 89 f5mov%esi,%r13d
813143b3: 41 54 push %r12
813143b5: 53 push %rbx
813143b6: 51 push %rcx
...
81314501: 48 8b 7e 08 mov0x8(%rsi),%rdi
81314505: 48 89 75 d0 mov%rsi,-0x30(%rbp)
81314509: e8 5f d1 ff ff callq
8131166d acpi_bus_scan
8131450e: 85 c0 test %eax,%eax
...
813145d6: 5a pop%rdx
813145d7: 5b pop%rbx
813145d8: 44 89 e0mov%r12d,%eax
813145db: 41 5c pop%r12
813145dd: 41 5d pop%r13
813145df: 41 5e pop%r14
813145e1: 41 5f pop%r15
813145e3: 5d pop%rbp
813145e4: c3 retq
note the use (deep down in the function) of -0x30(%rbp), and note how
it does pop %rdx twice to undo the push %rcx. It was just to
allocate space.
So you definitely have to track the actual stack pointer updates, not
just the patterns of add/sub to %rsp.
Linus
--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
https://lists.debian.org/CA+55aFxbWfYPuzCZvhy24zVfWwhN=dcxrcdguz74cfsoz9u...@mail.gmail.com
Re: Random panic in load_balance() with 3.16-rc
On Fri, 25 Jul 2014 13:01:11 -0700 Linus Torvalds torva...@linux-foundation.org wrote: For example, gcc will not create a small stack frame with sub $8,%rsp. No, what gcc does is to use a random push instruction. Fair enough, but that really makes things much harder to see. Here's an example: 813143a3 dock_notify: 813143a3: 55 push %rbp 813143a4: 48 89 e5mov%rsp,%rbp 813143a7: 41 57 push %r15 813143a9: 41 56 push %r14 813143ab: 49 89 femov%rdi,%r14 813143ae: 41 55 push %r13 813143b0: 41 89 f5mov%esi,%r13d 813143b3: 41 54 push %r12 813143b5: 53 push %rbx 813143b6: 51 push %rcx ... 81314501: 48 8b 7e 08 mov0x8(%rsi),%rdi 81314505: 48 89 75 d0 mov%rsi,-0x30(%rbp) 81314509: e8 5f d1 ff ff callq 8131166d acpi_bus_scan 8131450e: 85 c0 test %eax,%eax ... 813145d6: 5a pop%rdx 813145d7: 5b pop%rbx 813145d8: 44 89 e0mov%r12d,%eax 813145db: 41 5c pop%r12 813145dd: 41 5d pop%r13 813145df: 41 5e pop%r14 813145e1: 41 5f pop%r15 813145e3: 5d pop%rbp 813145e4: c3 retq note the use (deep down in the function) of -0x30(%rbp), and note how it does pop %rdx twice to undo the push %rcx. It was just to allocate space. I don't see a pop %rdx twice. Sure you're not suffering from a little dyslexia? ;-) But I do get your point. The rdx is popped where the rcx was, and both are useless, as rcx and rdx are volatile regs. So you definitely have to track the actual stack pointer updates, not just the patterns of add/sub to %rsp. With Perl that would be rather trivial. I'm more concerned with branch logic. I'll see if I can include some simple branch logic too to flatten paths. But I wont really know the depth of this until I start hacking at it. -- Steve -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140725161318.3dd77...@gandalf.local.home
Bug#686636: Please backport virtio-scsi to wheezy
Control: tag -1 patch Ron r...@debian.org (2014-07-26): Hi, The virtio_scsi module got backported to the 3.2.39-1 kernel, but it appears it didn't get added to the virtio-modules udeb for the wheezy kernels -- which means you can switch to using it for an already installed wheezy guest in a VM, but you can't install a new VM configured to use it with the wheezy installer. Please consider adding this to virtio-modules for the wheezy branch to complete this (very welcome!) backport. Looking at the sid package, this module was added to the virtio-modules package unconditionally (doesn't depend on the arch, as opposed to the pci one); that happened in r20402, in preparation for 3.10.1-1. I've just looked at all linux-image-* binaries built from linux 3.2.60-1+deb7u1, and all contain that module but two[*], so I'm not entirely sure about its arch-independence. The attached patch (against the wheezy svn branch) might do the work, or might need an extra '?'. [*] The two packages are the s390* -tape variants, which were dropped in the meanwhile: linux-image-3.2.0-4-s390x-tape_3.2.60-1+deb7u1_s390.deb linux-image-3.2.0-4-s390x-tape_3.2.60-1+deb7u1_s390x.deb Mraw, KiBi. Index: debian/installer/modules/virtio-modules === --- debian/installer/modules/virtio-modules (revision 21632) +++ debian/installer/modules/virtio-modules (working copy) @@ -1,6 +1,7 @@ virtio_net virtio_blk virtio_balloon +virtio_scsi # Some architectures do not have PCI bus virtio_pci ? Index: debian/changelog === --- debian/changelog (revision 21632) +++ debian/changelog (working copy) @@ -67,6 +67,9 @@ - drm/vmwgfx: Fix incorrect write to read-only register v2: - drm/radeon: stop poisoning the GART TLB + [ Cyril Brulebois ] + * Add virtio_scsi to the virtio-modules udeb (Closes: #686636). + -- Ben Hutchings b...@decadent.org.uk Mon, 21 Jul 2014 02:42:10 +0100 linux (3.2.60-1+deb7u2) wheezy-security; urgency=medium signature.asc Description: Digital signature
Processed: Re: Bug#686636: Please backport virtio-scsi to wheezy
Processing control commands: tag -1 patch Bug #686636 [linux] Please backport virtio-scsi to wheezy Added tag(s) patch. -- 686636: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=686636 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: https://lists.debian.org/handler.s.b686636.14063230677985.transcr...@bugs.debian.org
Bug#691576: [reverse-bisected] GDB stops with SIGTRAP at 0 address fixed with GCC 4.8
Hi, Please have a look at upstream bug report: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61799 I was asked to test GCC 4.8 and found this issue go away with locally-recompiled GCC 4.8.2 (upstream source, as ia64 is no more supported by Debian). Whether this was expected or not, I don't know. Feel free to discuss more in details with ia64/GCC gurus in upstream bug. Thanks, Émeric -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAA9xbM5o+1pey8ju6y+pJBWLvw9nfD3m==LS=9+azq+c2zq...@mail.gmail.com
Re: Random panic in load_balance() with 3.16-rc
On Fri, Jul 25, 2014 at 01:01:11PM -0700, Linus Torvalds wrote: For example, gcc will not create a small stack frame with sub $8,%rsp. No, what gcc does is to use a random push instruction. Fair enough, but that really makes things much harder to see. Here's an example: That is because for -Os, push is certainly shorter than sub $8,%rsp. If you want to test for this gcc bug in the kernel, supposedly one should just take the short testcase from the GCC PR, try to compile it and see if you e.g. get a -fcompare-debug -Os failure with the testcase. In that case, you could instead of giving up completely just -fno-var-tracking-assignments. Jakub -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140725212555.gg2...@laptop.redhat.com
