On Wed, 09 Jul 2014 16:16:04 +0100, David Howells said:
> Verify certificate chain in the X.509 certificates contained within the PKCS#7
> message as far as possible. If any signature that we should be able to verify
> fails, we reject the whole lot.
What happens if we see a signature that we sho
On Tue, 15 Jul 2014 20:01:44 +0300, Sam Asadi said:
> From: Linus Torvalds
>
>
> Signed-off-by: sam-the-6
> ---
> Makefile |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Makefile b/Makefile
> index 2167084..f3c543d 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -1,7 +
On Sat, 19 Apr 2014 13:37:27 -0300, Geyslan Gregório Bem said:
> Maintainers, is there some chance to fix it or a.out is really doomed?
Is there an actual use case for a.out on a modern kernel?
In other wods, is there any reason to really care if it's doomed, since
it's been *years* since that w
On Tue, 22 Jul 2014 23:01:58 -0700, Alexei Starovoitov said:
> BPF is used in several kernel components. This split creates logical boundary
> between generic eBPF core and the rest
>
> kernel/bpf/core.c: eBPF interpreter
>
> net/core/filter.c: classic->eBPF converter, classic verifiers, socket fil
On Thu, 24 Jul 2014 16:58:23 -0700, Alexei Starovoitov said:
> On Thu, Jul 24, 2014 at 4:45 PM, wrote:
> > On Tue, 22 Jul 2014 23:01:58 -0700, Alexei Starovoitov said:
> >> +obj-$(CONFIG_NET) += bpf/
> >
> > I was expecting to see CONFIG_NETFILTER here. Is CONFIG_NET intentional?
>
> yes. it is
Dell Latitude E6530, BIOS A11, seeing a crash in xhci_add_ep_to_interval
when it's docked in a newer dock that has USB3.
It's very possible that the BIOS is buggy - it isn't like I haven't found
BIOS bugs in every single Dell laptop I've had. :) But that shouldn't
make the kernel crash
lsusb
On Thu, 05 Jun 2014 08:55:07 -0700, Dan Williams said:
> > On a working boot, it progresses:
>
> Is a working boot after reverting that change, or it intermittently
> works? If it's the latter I'm not sure I trust the bisect result,
> yet.
Oh, it's a 100% guaranteed crash. The following is from
On Thu, 05 Jun 2014 09:35:48 -0700, Dan Williams said:
> Actually, on second look I bet xhci_alloc_tt_info() is being called
> while hdev->maxchild is not set. Let me throw together a debug
> patch...
Sure, no problem - just let me know what variant of linux-next you
want it applied against. :)
ng of hdev->maxchild.
>
> Cc: Mathias Nyman
> Reported-by: Valdis Kletnieks
> Signed-off-by: Dan Williams
Applied cleanly, booted without complaint, the keyboard that's behind
the PS2-USB converter works.
uname -r reports 3.15.0-rc8-next-20140605-dirty as expected.
So fee
On Tue, 20 May 2014 10:56:47 +0200, Pali Rohár said:
> Hm? Which errors? Here is output from checkpacth:
>
> total: 0 errors, 0 warnings, 276 lines checked
>
> 0001-platform-x86-dell-smo8800-Dell-Latitude-freefall-dri.patch
> has no obvious style problems and is ready for submission.
>
> total: 0
On Tue, 20 May 2014 20:10:28 +0200, Pali Rohár said:
> > Hmm.. what tree are you building against? I wonder if your
> > checkpatch is a different version than mine (next-20140519).
>
> I'm using up-to-date linus tree, git rev
> 60b5f90d0fac7585f1a43ccdad06787b97eda0ab
Ah, OK. Linux-next tree h
ned-off-by: Valdis Kletnieks
--- linux-next/kernel/workqueue.c.dist 2014-05-26 11:18:40.155380772 -0400
+++ linux-next/kernel/workqueue.c 2014-05-27 12:07:51.464678172 -0400
@@ -4440,7 +4440,7 @@ void print_worker_info(const char *log_l
probe_kernel_read(desc, worker->de
This seems to be a repeateable BUG in next-20140529 (have hit it in
2 boots out of 2). Seeing it on a Dell Latitude E6530 while it's
enumerating the internal USB hubs. Whatever trips it, it's new since
next-20140519.
% lsusb
Bus 002 Device 004: ID 0a5c:5801 Broadcom Corp. BCM5880 Secure Applicat
e other half of the patch is correct.
Signed-off-by: Valdis Kletnieks
--- linux-next/kernel/workqueue.c.dist 2014-05-26 11:18:40.155380772 -0400
+++ linux-next/kernel/workqueue.c 2014-05-27 12:07:51.464678172 -0400
@@ -4440,7 +4440,7 @@ void print_worker_info(const char
So what did I do wrong with this build of 'perf' (other than
trying to do it on a Fedora Rawhide box updated to last night? :)
(The obvious hack fix is to change the '#define _BSD_SOURCE 1' in util/util.h
to use _DEFAULT_SOURCE instead, but not sure how that plays on older
userspaces, as that was
On Tue, 27 May 2014 20:44:33 +0200, Fabian Frederick said:
> Hello Valdis,
>
> I thought Tejun directly reverted that patch (Joe Perches noticed
> the level problem just after submit).Anyway, problem is solved now :)
Tejun - can you see if that patch in fact got reverted? It made it
into t
On Tue, 27 May 2014 21:43:59 +0200, Borislav Petkov said:
> On Tue, May 27, 2014 at 03:17:28PM -0400, Steven Rostedt wrote:
> > This looks like functionality change to me.
> >
> > Please make the fix of "==" --> ">=" a separate patch.
>
> Yeah, that's actually a fix for console_loglevel values > 10
Seen once while booting next-20131218 (different boot than the BUG
I hit). Command that triggered it would have been one of these 2:
/usr/sbin/tc qdisc add dev em1 root codel
/usr/sbin/tc qdisc add dev wlp3s0 root codel
It's possible that wlp3s0 wasn't there yet due to rfkill switch having
nuked
Saw this while booting latest linux-next. I've only triggered it once,
so I suspect a race condition of some sort that I don't always hit.
[ 18.248796] SELinux: initialized (dev autofs, type autofs), uses
genfs_contexts
[ 18.267473] BUG: spinlock wrong CPU on CPU#3, mount/563
[ 18.267476]
(Resending, first try seems to have vanished in the ether)
Saw this while booting latest linux-next. I've only triggered it once,
so I suspect a race condition of some sort that I don't always hit.
[ 18.248796] SELinux: initialized (dev autofs, type autofs), uses
genfs_contexts
[ 18.267473]
g vt_led_registered[B
I admit having zero understanding of the code, but I can confirm that
next-20140825 still throws the lockdep whine I was seeing, but the same
tree with this patch on top of it boots without warning. Soo...
Tested-By: Valdis Kletnieks
pgpTA5R9SvW7n.pgp
Description: PGP signature
On Tue, 26 Aug 2014 10:01:35 +0200, Johannes Berg said:
> On Tue, 2014-08-26 at 03:54 +0200, Samuel Thibault wrote:
>
> > + vt_led_wq = alloc_workqueue("input_leds", WQ_UNBOUND, 0);
> > + if (!vt_led_wq)
> > + return -ENOMEM;
>
> Does this really need a separate workqueue rather than
complains, and no complaints with this patch
on top.
Tested-by: Valdis Kletnieks
pgpDQwyYSc2K4.pgp
Description: PGP signature
It's possible for dev_alloc_skb() to fail. Propagate the error to the caller,
so it can clean up and drop the packet. The sender should end up retransmitting
the packet, hopefully at a time we're prepared to allocate skb's again.
Reported-By: Nicholas Krause
Signed-Off-By: V
On Mon, 08 Sep 2014 17:22:36 +0800, Ley Foon Tan said:
> This patch adds support for loadable modules.
>
> Signed-off-by: Ley Foon Tan
> +/*
> + * Modules should NOT be allocated with kmalloc for (obvious) reasons.
> + * But we do it for now to avoid relocation issues. CALL26/PCREL26 cannot
> re
On Tue, 09 Sep 2014 16:21:14 -0700, Andrew Morton said:
> On Tue, 9 Sep 2014 23:25:28 +0200 (CEST) Jiri Kosina wrote:
> kfree() is quite a hot path to which this will add overhead. And we
> have (as far as we know) no code which will actually use this at
> present.
We already do a check for ZERO
On Sat, 16 Aug 2014 20:27:01 -0700, Hugh Dickins said:
> Can we safely revert your 8b37e1bef5a6 ("leds: convert blink timer to
> workqueue"), or have there been other changes which now depend upon it?
I suspect there's something else busted. I hand-reverted that patch, and I
*still*
see the foll
On Tue, 19 Aug 2014 21:12:10 +0200, Thomas Meyer said:
> > Hi,
> >
> > the build with -O0 fails with:
> > bug or feature?
> >
> > any ideas?
Feature. The kernel is *known* to not build with -O0, because that
disables *all* function inlining, and there's several functions that *have*
to be inline
On Tue, 19 Aug 2014 22:19:58 +0200, Thomas Meyer said:
> Can you give an example function that relies on this GCC feature?
cd /usr/src/linux && find include -type f | xargs grep __builtin_return_address
pgpeG1DYwM0Wb.pgp
Description: PGP signature
On Wed, 20 Aug 2014 20:03:26 +0300, Ari Sundholm said:
> From: Ari Sundholm
>
> This reverts commit bdc3ae7221213963f438faeaa69c8b4a2195f491.
> + if (sscanf(buf, "%i", &mode) != 1 && (mode != 2 || mode != 1))
> return -EINVAL;
I'm not convinced that's right either. If we come
ainst the file that results from Ari's revert of the previous
patch.
Signed-Off-By: Valdis Kletnieks
--
--- drivers/platform/x86/toshiba_acpi.c.orig2014-08-20 14:45:52.159898938
-0400
+++ drivers/platform/x86/toshiba_acpi.c 2014-08-20 14:47:55.102444985 -0400
@@ -1258,7 +1258,7 @@ stat
On Wed, 20 Aug 2014 12:21:23 -0700, Tadeusz Struk said:
> Hi David,
> On 08/20/2014 11:34 AM, David Woodhouse wrote:
> > I'm not sure I understand. Precisely what fails?
>
> I clone a subsystem, configure it to use
> CONFIG_EXTRA_FIRMWARE="qat_895xcc.bin", type make && make install and get:
>
> MK_
(Adding Al Viro and linux-fsdevel, dropping Mark Brown and the SPI list,
because this is
heading off in a different direction now)
On Wed, 20 Aug 2014 22:26:02 +0200, Pavel Machek said:
> On Wed 2014-08-06 14:27:20, valdis.kletni...@vt.edu wrote:
> > On Wed, 06 Aug 2014 13:53:17 -0400, Nick Kraus
On Wed, 06 Aug 2014 13:53:17 -0400, Nick Krause said:
> Remove unused definition which cause the following warnings
>
> drivers/spi/spi-omap-100k.c:73:0: warning: "WRITE" redefined [enabled by
> default]
> include/linux/fs.h:193:0: note: this is the location of the previous
> definition
> driver
On Mon, 04 Aug 2014 19:07:53 -, Paul Zimmerman said:
> Are you sure about that? Last I heard, xHCI debug support was a logo
> requirement from Microsoft for Windows 8 and above, so I would have
> thought that most vendors would have implemented it by now.
There's a lot of gear out in the real
On Mon, 04 Aug 2014 19:40:15 -, Paul Zimmerman said:
> Ah, you didn't read far enough down the page :)
I'm willing to bet a large pizza with everything but anchovies that
out in the real world, a lot of implementors didn't read further either. :)
> So I have to believe there are a *lot* of s
--. 1 root root 67 Sep 29 23:42 console-efi-14120485500
1225 -r--r--r--. 1 root root 148 Sep 29 23:59 console-efi-14120495420
1224 -r--r--r--. 1 root root 67 Sep 29 23:59 console-efi-14120495440
Signed-off-by: Valdis Kletnieks
--- linux-next/fs/pstore/inode.c.orig 2014-10-03 23:58
On Mon, 13 Oct 2014 10:16:06 +0200, Gabriel Fernandez said:
> Concerning multiple writing in MIPHY_PLL_SBR_1, the writing of the
> first 0 it's to be sure there is no previous request.
> Then we take account new setting by writing 0x02.
> And then we make it 0 to make sure there is no other pendin
On Wed, 01 Oct 2014 11:45:47 -0400, Jeff Moyer said:
> This sounds an awful lot like posix_fadvise' POSIX_FADV_NOREUSE flag.
Gaah. No wonder 'man madvise' worked but 'man fadvise' came up empty :)
-ENOCAFFIENE :)
pgpTy4gSGTGdz.pgp
Description: PGP signature
On Wed, 01 Oct 2014 11:45:47 -0400, Jeff Moyer said:
> This sounds an awful lot like posix_fadvise' POSIX_FADV_NOREUSE flag.
Gaah. Premature click. man posix_fadvise says this:
In kernels before 2.6.18, POSIX_FADV_NOREUSE had the same semantics as
POSIX_FADV_WILLNEED. This was
On Mon, 06 Jul 2015 21:53:26 -0400, Sreenath Madasu said:
> When the checkpatch.pl script was run, it showed lines with length
> more than 80 characters in rtw_ap.c file. Fixed line number 382 by
> breaking it up into two lines within 80 characters.
> - stainfo_offset
On Tue, 07 Jul 2015 21:08:10 -0400, Sreenath Madasu said:
> The kernelnewbies.org guide said "For your first patch, only pick one
> warning". That is the reason why I fixed one warning.
They mean "don't fix lines over 80 characters *and* missing-blank
warnings in the same patch".
pgpMmWKYBIEA7.p
On Tue, 07 Jul 2015 13:38:47 -0700, Joe Perches said:
> The longest line in this file is 158 chars, that's
> probably excessive, awk shows 35 lines > 80 chars.
That doesn't count tabs. Checkpatch throws 98 warnings.
pgpRav2SIlbke.pgp
Description: PGP signature
27; as a curly bracket as the last character of a regexp and handed them
a \ as well, though I admit I don't understand why they didn't complain before.
I tested the code with a 'checkpatch.pl -f drivers/staging/*/*.c' and it
still seemed to work and didn't explode.
Signed-off-
On Thu, 09 Jul 2015 18:11:32 +0530, Vaibhav Hiremath said:
> This patch adds dev_info line at the end of probe function, to
> clearly put status of regulator probe on console. Useful during
> development, specially to check bootlog.
I can see that as a development thing...
> + dev_info(&pdev-
Hate to bother everybody, but we're at -rc7..
Commit 83129b37ef is still in Linus's tree. This one causes a crash
on my Dell Latitude after 4 hours uptime.
commit 83129b37ef35bb6a7f01c060129736a8db5d31c4
Author: Yanir Lubetkin
Date: Tue Jun 2 17:05:45 2015 +0300
e1000e: fix systim issues
I'm seeing my laptop crash/wedge up/something during very early
boot - before it can write anything to the console. Nothing in pstore,
need to hold down the power button for 6 seconds and reboot.
git bisect points at:
commit 7a6bacb133752beacb76775797fd550417e9d3a2
Author: Joonsoo Kim
Date: T
On Thu, 14 Apr 2016 10:35:47 +0900, Joonsoo Kim said:
> My fault. It should be assgined every time. Please test below patch.
> I will send it with proper SOB after you confirm the problem disappear.
> Thanks for report and analysis!
Still bombs out, sorry. Will do more debugging this evening if
On Thu, 14 Apr 2016 10:35:47 +0900, Joonsoo Kim said:
> On Wed, Apr 13, 2016 at 08:29:46PM -0400, Valdis Kletnieks wrote:
> > I'm seeing my laptop crash/wedge up/something during very early
> > boot - before it can write anything to the console. Nothing in pstore,
> > n
On Fri, 15 Apr 2016 11:17:55 -0500, David Lechner said:
> I omitted this on purpose. For my use case, I am using the SPI as
> write-only,
So your SPI accesses are fire-and-forget, and nothing ever comes back?
Seems a very dangerous way to design the use case, with no feedback if
something suddenl
Seen during boot on next-20160517. This apparently sneaked into the tree
sometime after -0502 (probably after -0512 but I can't prove it at the moment)
[1.806765] INFO: trying to register non-static key.
[1.806772] the code is fine but needs lockdep annotation.
[1.806777] turning off t
next-20160512 sets the screen brightness to about 40%-ish or so, rather
than the 100% intensity I want.
Dell Latitude E6530 laptop.
git bisect tells me:
059500940defe285222d3b189b366dfe7f299cae is the first bad commit
commit 059500940defe285222d3b189b366dfe7f299cae
Author: Aaron Lu
Date: Wed
So, not content in the amount of breakage I generate already, I
compiled with UBSAN enabled...
The immediately relevant part:
[2.418576]
[2.418579] UBSAN: Undefined behaviour in drivers/usb/host/ehci-hub.c:8
Seen at boot in a UBSAN-enabled kernel:
[2.936388]
[2.936392] UBSAN: Undefined behaviour in drivers/scsi/scsi_devinfo.c:457:21
[2.936396] index 8 is out of range for type 'char [8]'
The code:
452
On Tue, 17 May 2016 22:50:11 +0200, "Rafael J. Wysocki" said:
> On Tue, May 17, 2016 at 8:41 PM, Valdis Kletnieks
> wrote:
> > next-20160512 sets the screen brightness to about 40%-ish or so, rather
> > than the 100% intensity I want.
> >
> > Dell Latitud
'm doing" semantics of [0]. Change the declaration to match.
Signed-Off-By: Valdis Kletnieks
--- a/include/linux/usb/ehci_def.h 2015-01-06 01:04:24.342436706 -0500
+++ b/include/linux/usb/ehci_def.h 2016-05-19 13:57:20.869304540 -0400
@@ -180,11 +180,11 @@ struct ehci_regs {
On Wed, 18 May 2016 11:54:59 +0300, Mika Westerberg said:
> Can you check if the patch fixes the issue?
Tested, no complaints at boot, and everything seems to be working.
Feel free to add this to the patch and send it upstream:
Tested-By: Valdis Kletnieks
> -8<-8<-8&l
On Thu, 19 May 2016 17:50:31 -0700, Greg Kroah-Hartman said:
> On Thu, May 19, 2016 at 05:19:00PM -0400, Valdis Kletnieks wrote:
> > UBSAN throws a complaint:
> >
> > [2.418579] UBSAN: Undefined behaviour in
> > drivers/usb/host/ehci-hub.c:877:47
> > [2
On Thu, 19 May 2016 18:53:17 -0400, valdis.kletni...@vt.edu said:
> > > next-20160512 sets the screen brightness to about 40%-ish or so, rather
> > > than the 100% intensity I want.
> Put this one in the "things that go bump in the night" pile - the problem
> doesn't manifest on next-20160519, ev
On Fri, 20 May 2016 13:45:30 +0800, Aaron Lu said:
> On 05/20/2016 11:05 AM, valdis.kletni...@vt.edu wrote:
> > On Thu, 19 May 2016 18:53:17 -0400, valdis.kletni...@vt.edu said:
> >
> next-20160512 sets the screen brightness to about 40%-ish or so, rather
> than the 100% intensity I want.
to
stick a "Tested-By:" on it
> > Reported-by: Valdis Kletnieks
> > Signed-off-by: Aaron Lu
> > ---
> > drivers/acpi/acpi_video.c | 9 ++---
> > drivers/thermal/int340x_thermal/int3406_thermal.c | 2 +-
> > incl
On Fri, 27 May 2016 15:15:43 +0800, Lv Zheng said:
> The initial _LID returning value is not reliable after boot/resume because
> the BIOS vendors may implement it by returning a cached value that is only
> updated when a lid notification is received.
> This causes strange things happening after re
On Fri, 27 May 2016 14:54:59 +0200, Boris Brezillon said:
> From: Hans de Goede
>
> On some nand controllers with hw-ecc the controller code wants to know
> the ecc strength and size and having these as 0, 0 is not accepted.
>
> Specifying these in devicetree is possible but undesirable as the nan
On Tue, 26 Apr 2016 18:55:38 +0100, Al Viro said:
> It is a change of user-visible behaviour, but I would be very
> surprised if anything broke from that change. And it would help to simplify
> the awful mess we have in there.
I have to admit that over the past 3 decades of working with Un
On Tue, 26 Apr 2016 20:02:48 +0100, Al Viro said:
> > The biggest danger I can see is some shell script doing something like:
> >
> > foobar > $dir/$targetfile
> >
> > and $targetfile is unset. If we allow a program to get an open fd that
> > refers
> > to a directory, what are the semantics of v
no need to calculate len. Bye-bye.
Signed-off-by: Valdis Kletnieks
---
diff --git a/drivers/staging/lustre/lustre/include/lustre_cfg.h
b/drivers/staging/lustre/lustre/include/lustre_cfg.h
index eb6b292b7b25..d30d8b054c92 100644
--- a/drivers/staging/lustre/lustre/include/lustre_cfg.h
+++ b/driv
struct dentry *entry;
^
Just ignore the dentry returned, and add a comment that we *know*
we're not really leaking the dentry because something else will be able
to reap it via recursion.
Signed-off-by: Valdis Kletnieks
---
:100644 100644 96d9d4651a51... 4438dc426b54... M
/fid/../include/lu_object.h:765:1: warning:
'inline' is not at beginning of declaration [-Wold-style-
declaration]
static const inline struct lu_device_operations *
^
So we just swap inline and const. 272 warnings gone. :)
Signed-off-by: Valdis Kletnieks
---
diff --git a/drive
ng/lustre/lustre/llite/../include/linux/../../../include/linux/libcfs/libcfs_private.h:58:6:
note: in expansion of macro 'unlikely'
if (unlikely(!(cond))) { \
^
drivers/staging/lustre/lustre/llite/rw.c:763:2: note: in expansion of macro
'LASSERTF'
LASSERTF(reserved >= 0, &
save a page of compiler spew.
Signed-off-by: Valdis Kletnieks
---
diff --git a/drivers/staging/lustre/lustre/ptlrpc/sec_bulk.c
b/drivers/staging/lustre/lustre/ptlrpc/sec_bulk.c
index cd8a9987f7ac..1f326673f089 100644
--- a/drivers/staging/lustre/lustre/ptlrpc/sec_bulk.c
+++ b/drivers/staging/lustre/
of it. It says it's
test code - it should be *more* bulletproof than production, not less.
Signed-off-by: Valdis Kletnieks
---
diff --git a/drivers/staging/lustre/lustre/fid/lproc_fid.c
b/drivers/staging/lustre/lustre/fid/lproc_fid.c
index ce90c1c54a63..eff011f30fa5 100644
--- a/drivers/
Start of a batch series to clean up the Lustre tree. Other people have
done some sparse and checkpatch cleanups, but I found a bunch of
stuff building with W=1.
Valdis Kletnieks (6):
Swap inline/const to kill 272 warnings
Fix set-but-unused whinge.
Clean up another C warnining:
Fix
Seen this in 2 boots out of two on next-20151207 when IPV6 networking
was available. It was stable when no net was available. Also, next-20161127 is
OK.
Haven't bisected it yet - this ring any bells?
[ 92.231022] BUG: unable to handle kernel NULL pointer dereference at
(null)
[ 92
On Tue, 08 Dec 2015 12:34:09 +0100, Florian Westphal said:
> Valdis Kletnieks wrote:
>
> [ CC Pablo ]
>
> > Seen this in 2 boots out of two on next-20151207 when IPV6 networking
> > was available. It was stable when no net was available. Also,
> > next-20161127
I'm experiencing a spot of trouble with this commit:
commit aad730d0704545ad97654bd929b0aba05adb1436
Author: Takashi Iwai
Date: Mon Dec 2 13:33:57 2013 +0100
ALSA: hda - Always do delayed probes for HD-audio devices
That adds some code:
#ifndef CONFIG_SND_HDA_I915
if (chip->drive
On Tue, 21 Jul 2015 11:54:30 -0700, Andy Lutomirski said:
> Could this be done at link time, or perhaps when compressing the
> kernel image, instead of at boot time?
That's only safe to do if the kernel is built for one specific CPU - if it's
a generic kernel that boots on multiple hardware desig
On Tue, 21 Jul 2015 12:29:21 -0700, Andy Lutomirski said:
> That's not what I meant. We do something in the C code that tells the
> build step which way the initial state goes. At link time, we make
> the initial state actually work like that. Then, at run time, we can
> still switch it again i
So booting into a next-20151222 kernel, I can mount an external drive
that uses cryptLuks. I try -1231, and I get this failure:
Failed to setup dm-crypt key mapping for device /dev/sdb2.
Check that kernel supports aes-cbc-essiv:sha256 cipher (check syslog for more
info).
Tracked it down to this
On Sun, 03 Jan 2016 11:20:03 +0100, Milan Broz said:
> On 01/03/2016 06:34 AM, Valdis Kletnieks wrote:
> > So booting into a next-20151222 kernel, I can mount an external drive
> > that uses cryptLuks. I try -1231, and I get this failure:
> >
> > Failed to setup dm-c
On Fri, 29 Jan 2016 22:35:18 +0100, "Rafael J. Wysocki" said:
> > One more test unveils this one
> >
> > # modprobe -r sdhci-acpi
> > [ 1289.909441] [ cut here ]
> > [ 1289.918205] WARNING: CPU: 1 PID: 4374 at
> > /home/andy/prj/linux-otc/drivers/base/power/common.c:150
> >
Am seeing some DMAR error messages on reboot after a 'shutdown -r now'.
(Finally got annoyed enough to track it down while doing a git bisect)
Hardware: Dell Latitude E6530 laptop.
Working (booting from power-off state):
[0.027673] Freeing SMP alternatives memory: 28K (b5111000 -
ff
On Mon, 08 Feb 2016 22:50:39 +0100, "Rafael J. Wysocki" said:
> On Mon, Feb 8, 2016 at 10:44 PM, wrote:
> > My Dell Latitude laptopi on next-20160201 is throwing a similar error
> > at shutdown, except the traceback continues:
> >
> > mei_me_remove+0xbd/0xc0
> > pci_device_shutdown+0x32/0x50
> >
On Fri, 26 Feb 2016 22:00:44 +0100, Stanislav Brabec said:
> Well, it seems to be safe, even if the loop device was not allocated by
> mount(8) itself, as
> ioctl(fd, LOOP_CLR_FD)
> never returns EBUSY:
The fact you don't get an EBUSY doesn't mean it's actually safe
pgpdStixH5IlE.pgp
Descr
(spotted while looking at a 'git bisect visualize' for something else)
After this commit:
Author: Mitch Williams 2014-09-13 03:40:47
Committer: Jeff Kirsher 2014-10-23 23:38:04
i40e: Add 10GBaseT support
Add driver support for 10GBaseT device.
we have the following chunk of code in
Recent linux-next has broken my Juniper VPN client. The tunnel gets created,
routes get added, but trying to actually send packets across results in packets
just disappearing. 'ifconfig' consistently reports exactly 1 packet sent (even
after a 'ping' command or similar should have sent multiple pa
On Wed, 03 Dec 2014 03:20:19 +0008, Jason Wang said:
> > Still broken in next-20141201, and bisection fingers this commit:
> >
> > commit e0b46d0ee9c240c7430a47e9b0365674d4a04522
> > Author: Herbert Xu
> > Date: Fri Nov 7 21:22:23 2014 +0800
> >
> > tun: Use iovec iterators
> > What's the
On Wed, 03 Dec 2014 17:07:28 +, Sean Cleator said:
> A patch to fix the rest of the long line warnings in the dgnc_cls.h file
> found by the checkpatch.pl tool
> struct cls_uart_struct {
> u8 txrx;/* WR RHR/THR - Holding Reg */
> u8 ier; /* WR IER - Inter
commit 61104aa44529d59bd01a5d51df571ca2823a04b3
Author: Pali Rohár
Date: Thu May 14 12:54:27 2015 +0200
dell-laptop: Use dell-rbtn instead i8042 filter when possible
causes build errors:
LD init/built-in.o
drivers/built-in.o: In function `dell_init':
/usr/src/linux-next/dri
So after I made both config variables =y, the resulting kernel built, but
died a glorious death at boot.
Dell Latitude E6530, most current released BIOS.
[1.760739] BUG: unable to handle kernel NULL pointer dereference at
0090
[1.760778] IP: [] klist_next+0x1c/0x1d0
[1.76
On Sat, 23 May 2015 10:38:35 +0530, Shailendra Verma said:
> --- a/kernel/ptrace.c
> +++ b/kernel/ptrace.c
> @@ -108,7 +108,7 @@ void __ptrace_unlink(struct task_struct *child)
>
> /*
>* If transition to TASK_STOPPED is pending or in TASK_TRACED, kick
> - * @child in the butt.
On Sat, 23 May 2015 03:05:50 +0200, Pali Rohár said:
> I'm thinking about using symbol_request() in dell-laptop.c (instead hard=20
> dependency) and then not ignoring error here... It could fix this=20
> problem.
That would also address the problem of a build
that has DELL_LAPTOP=[ym] but DELL_RB
On Sun, 24 May 2015 11:32:36 +0100, John Whitmore said:
> $ ./mkknlimg ../../linux/arch/arm/boot/zImage 3.18.0-can+.img
> tail: +: invalid number of bytes
> * Is this a valid kernel? In pass-through mode.
Looks like they try to use 'tail' to skip over something, but the + sign
in your uname -r gi
On Tue, 12 May 2015 10:44:15 +0200, Ingo Molnar said:
> Btw., just some feedback, 'random' kernel configs still generate a ton
> of warnings:
>
> randconf: # 9, ed602bbb, Tue_May_12_09_07_25_CEST_2015: 39 kernels/hour,
[ bzImage...81 secs, modules...21 secs, done ] (warns: 6)
> rand
On Thu, 18 Dec 2014 17:34:56 +0100, Pali Rohár said:
> Thanks for testing. Anyway I would like to know if your dell
> machine supports i8k_get_fan_nominal_rpm(). Can you test without
> above 4 lines patch?
I'll give that a try this evening..
pgp06z7fPJJ3Q.pgp
Description: PGP signature
On Tue, 16 Dec 2014 20:09:54 -0500, Valdis Kletnieks said:
> Spotted these two while booting single-user on 20141216. 20141208
> doesn't throw these, so it's something in the last week or so..
Gaah! Turns out that 20141208 *is* susceptible - it had been booting
just fine for s
On Thu, 18 Dec 2014 11:50:20 -0500, Eric Paris said:
> On Thu, 2014-12-18 at 11:45 -0500, valdis.kletni...@vt.edu wrote:
> > On Tue, 16 Dec 2014 20:09:54 -0500, Valdis Kletnieks said:
> >
> > > Spotted these two while booting single-user on 20141216. 20141208
> >
On Thu, 18 Dec 2014 08:10:43 -0700, David Ahern said:
> Adds helper for following kernel formats:
> %pi4 print an IPv4 address with leading zeros
> %pI4 print an IPv4 address without leading zeros
> %pi6 print an IPv6 address without colons
> %pI6 print an IPv6 address with colons
> %pI6c
On Thu, 18 Dec 2014 18:43:10 -0700, David Ahern said:
> Adds helper for following kernel formats:
> %pi4 print an IPv4 address with leading zeros
> %pI4 print an IPv4 address without leading zeros
> %pi6 print an IPv6 address without colons
> %pI6 print an IPv6 address with colons
> %pI6c
text it should
> use, pass that down and use that.
>
> See: https://lkml.org/lkml/2014/12/16/542
> Reported-by: Valdis Kletnieks
> Signed-off-by: Richard Guy Briggs
> ---
> kernel/audit.c |8
> 1 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --g
On Tue, 10 Mar 2015 14:03:59 +0100, Yann Droneaud said:
> > Consider the following sequence of events:
> >
> > 0. Suppose a mutex is locked by task A and has no waiters.
> >
> > 1. Task B calls mutex_trylock().
> >
> > 2. mutex_trylock() calls the architecture-specific
> > __mutex_fastpath_
801 - 900 of 1041 matches
Mail list logo
