Are there going to be two branches, one for using the current API and one
using Zinc?
On Sat, Dec 30, 2017 at 00:30:32 +0800,
weiping zhang wrote:
1. Add proper SELINUX policy that give permission to mdadm for debugfs.
2. Split mdadm into 2 part, Firstly, user proccess mdadm trigger a kwork,
secondly kwork will create gendisk)and mdadm wait it done, Like
following:
diff --git a
On Fri, Dec 22, 2017 at 21:20:10 +0800,
weiping zhang wrote:
2017-12-22 12:53 GMT+08:00 Bruno Wolff III :
On Thu, Dec 21, 2017 at 17:16:03 -0600,
Bruno Wolff III wrote:
Enforcing mode alone isn't enough as I tested that one one machine at home
and it didn't trigger the problem
On Thu, Dec 21, 2017 at 17:16:03 -0600,
Bruno Wolff III wrote:
Enforcing mode alone isn't enough as I tested that one one machine at
home and it didn't trigger the problem. I'll try another machine late
tonight.
I got the problem to occur on my i686 machine when booting in
On Thu, Dec 21, 2017 at 12:15:31 -0600,
Bruno Wolff III wrote:
One important thing I have just found is that it looks like the
problem only happens when booting in enforcing mode. If I boot in
permissive mode it does not happen. My home machines are currently set
to boot in permissive mode
On Thu, Dec 21, 2017 at 10:02:15 -0700,
Jens Axboe wrote:
On 12/21/17 9:42 AM, Bruno Wolff III wrote:
On Thu, Dec 21, 2017 at 23:48:19 +0800,
weiping zhang wrote:
output you want. I never saw it for any kernels I compiled myself. Only when
I test kernels built by Fedora do I see it.
see
On Thu, Dec 21, 2017 at 23:48:19 +0800,
weiping zhang wrote:
output you want. I never saw it for any kernels I compiled myself. Only when
I test kernels built by Fedora do I see it.
see it every boot ?
I don't look every boot. The warning gets scrolled of the screen. Once I see
the CPU hang
On Thu, Dec 21, 2017 at 23:31:40 +0800,
weiping zhang wrote:
does every time boot fail can trigger WANRING in device_add_disk ?
Not that I see. But the message could scroll off the screen. The boot gets
far enough that systemd copies over dmesg output to permanent storage that
I can see on
On Thu, Dec 21, 2017 at 22:01:33 +0800,
weiping zhang wrote:
Hi,
how do you do bisect ?build all kernel commit one by one ?
as you did before:
https://bugzilla.redhat.com/show_bug.cgi?id=1520982
I just did the one bisect using Linus' tree. After each build, I would do
a test boot and see if
After today, I won't have physical access to the problem machine until
January 2nd. So if you guys have any testing suggestions I need them soon
if they are to get done before my vacation.
I do plan to try booting to level 1 to see if I can get a login prompt
that might facilitate testing. The l
On Tue, Dec 19, 2017 at 10:24:52 -0800,
Shaohua Li wrote:
Not sure if this is MD related, but could you please check if this debug patch
changes anything?
The system still had cpu hangs. I've attached dmesg output saved by systemd
and retrieved after booting with a pre-rc2 kernel.
-- Logs b
On Tue, Dec 19, 2017 at 10:24:52 -0800,
Shaohua Li wrote:
Not sure if this is MD related, but could you please check if this debug patch
changes anything?
I'm doing a build now. I do use md to mirror disk partitions between two disks. I do that on another machine that doesn't exhibit the pro
On Sun, Dec 17, 2017 at 21:43:50 +0800,
weiping zhang wrote:
Hi, thanks for testing, I think you first reproduce this issue(got WARNING
at device_add_disk) by your own build, then add my debug patch.
The problem is still in rc4. Reverting the commit still fixes the problem.
I tested that war
On Sun, Dec 17, 2017 at 21:43:50 +0800,
weiping zhang wrote:
Hi, thanks for testing, I think you first reproduce this issue(got WARNING
at device_add_disk) by your own build, then add my debug patch.
I'm going to try testing warnings with a kernel I've built, to try to
determine if warnings
On Sun, Dec 17, 2017 at 21:43:50 +0800,
weiping zhang wrote:
Hi, thanks for testing, I think you first reproduce this issue(got WARNING
at device_add_disk) by your own build, then add my debug patch.
No, the first log (that Laura copied) was from the Fedora bug and it was
from a Fedora kerne
On Fri, Dec 15, 2017 at 13:51:22 -0600,
Bruno Wolff III wrote:
I do not know what is different. Do you have any ideas? Most likely I
won't be able to test any more kernels until Monday (unless I can use
most of my most recent build over again very soon).
The .config looks like it s
On Fri, Dec 15, 2017 at 22:02:20 +0800,
weiping zhang wrote:
Sorry to let you confuse, WARN_ON means we catch log as following:
WARNING: CPU: 3 PID: 3486 at block/genhd.c:680 device_add_disk+0x3d9/0x460
I do not get this warning for any of the kernels I build, whether from
Linus' tree or Jos
On Fri, Dec 15, 2017 at 09:18:56 -0800,
Laura Abbott wrote:
You can see the trees Fedora produces at
https://git.kernel.org/pub/scm/linux/kernel/git/jwboyer/fedora.git
which includes the configs (you want to look at the ones withtout - debug)
Thanks. I found it a little while ago and am alr
On Fri, Dec 15, 2017 at 22:02:20 +0800,
weiping zhang wrote:
Yes, please help reproduce this issue include my debug patch. Reproduce means
we can see WARN_ON in device_add_disk caused by failure of bdi_register_owner.
I'm not sure why yet, but I'm only getting the warning message you want
w
On Fri, Dec 15, 2017 at 10:04:32 +0800,
weiping zhang wrote:
I just want to know WARN_ON WHAT in device_add_disk,
if bdi_register_owner return error code, it may fail at any step of following:
Was that output in the original boot log? I didn't see anything there
that had the string WARN_ON.
On Fri, Dec 15, 2017 at 10:04:32 +0800,
weiping zhang wrote:
so I want see the WARN_ON as you paste before, also my DEBUG log will help
to find which step fail.
The previous time also journalctl for output, but maybe I used slightly
different options. I'll look and see if it is in the journ
On Fri, Dec 15, 2017 at 09:22:21 +0800,
weiping zhang wrote:
Thanks your testing, but I cann't find WARN_ON in device_add_disk from
this boot1.log, could you help reproduce that issue? And does this issue can be
triggered at every bootup ?
I don't know what you need for the first question. W
On Thu, Dec 14, 2017 at 18:09:27 +0800,
weiping zhang wrote:
It seems something wrong with bdi debugfs register, could you help
test the forllowing debug patch, I add some debug log, no function
change, thanks.
I applied your patch to d39a01eff9af1045f6e30ff9db40310517c4b45f and there
were
On Thu, Dec 14, 2017 at 18:09:27 +0800,
weiping zhang wrote:
On Thu, Dec 14, 2017 at 02:24:52AM -0600, Bruno Wolff III wrote:
On Wed, Dec 13, 2017 at 16:54:17 -0800,
Laura Abbott wrote:
>Hi,
>
>Fedora got a bug report https://bugzilla.redhat.com/show_bug.cgi?id=1520982
>of a
On Wed, Dec 13, 2017 at 16:54:17 -0800,
Laura Abbott wrote:
Hi,
Fedora got a bug report https://bugzilla.redhat.com/show_bug.cgi?id=1520982
of a boot failure/bug on Linus' master (full bootlog at the bugzilla)
I'm available for testing. The problem happens on my x86_64 Dell Workstation,
but
On Sat, Jul 02, 2016 at 01:03:17 +0200,
"Jason A. Donenfeld" wrote:
Hey Bruno,
Sorry I didn't reply to this earlier; the message didn't make it to me
somehow.
I only sent it to LKML, since we had communicated separately when you helped
me by making changes for the 4.7 kernel, I didn't think
On Tue, Jun 28, 2016 at 16:49:18 +0200,
"Jason A. Donenfeld" wrote:
Today I'm releasing WireGuard, an encrypted and authenticated
tunneling virtual interface for the kernel. It uses next-generation
I tried this out on 4.7 kernels and it seemed to work OK. I can't tell
about security, but th
On Mon, Jan 25, 2016 at 03:52:25 +0100,
Bjørn Mork wrote:
Hello,
my oldish Thinkpad X301 only wanted to show a blank screen in v4.5-rc1.
Bisecting resulted in:
drm/i915: more virtual south bridge detection
I am likely seeing the same problem on a Dell laptop. I haven't finished
my bisec
On Fri, Dec 12, 2014 at 13:23:19 +0100,
toki clover wrote:
Now, I did not see any Linux FS devs activity/response to this... What
a waste of time because if those patch don't make it for this merge
window, rebasing/reposting will be, again, necessary.
The patches got pulled into linux-next.
On Thu, Nov 27, 2014 at 08:00:47 +,
Phillip Lougher wrote:
My intention is to submit them in the next kernel merge window.
If you want LZ4 support in Squashfs now is a good time to publically
support the inclusion of these patches.
Fedora has been supporting LZ4 functionallity in mksquas
On Wed, Jul 23, 2014 at 17:11:40 +0200,
Peter Zijlstra wrote:
OK, so that's become the below patch. I'll feed it to Ingo if that's OK
with hpa.
I tested this patch on 3 machines and it continued to fix the one that
was broken and didn't seem to break anything on the two that weren't
broken
On Tue, Jul 22, 2014 at 16:18:55 +0200,
Peter Zijlstra wrote:
You can put this on top of them. I hope that this will make the pr_err()
introduced in the robustify patch go away.
I went to 3.16-rc6 and then reapplied three patches from your previous
email messages. The dmesg output and the d
On Tue, Jul 22, 2014 at 15:35:14 +0200,
Peter Zijlstra wrote:
On Tue, Jul 22, 2014 at 03:26:03PM +0200, Peter Zijlstra wrote:
Something like so.. anything obviously broken?
Do you want me to test this change instead of, or combined with the other
patch you wanted tested earlier?
---
arc
On Tue, Jul 22, 2014 at 11:47:40 +0200,
Peter Zijlstra wrote:
On Mon, Jul 21, 2014 at 06:52:12PM +0200, Peter Zijlstra wrote:
On Mon, Jul 21, 2014 at 11:35:28AM -0500, Bruno Wolff III wrote:
> Is there more I can do to help with this now? Or should I just wait for
> patches to test?
On Tue, Jul 22, 2014 at 12:38:57 +0200,
Peter Zijlstra wrote:
Could you provide the output of cpuid and cpuid -r for your machine?
This code is magic and I've no idea what your machine is telling it to
do :/
I am attaching both sets of output. (I also added copies to the bug report.)
CPU 0:
Is there more I can do to help with this now? Or should I just wait for
patches to test?
--
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
On Fri, Jul 18, 2014 at 12:16:33 +0200,
Peter Zijlstra wrote:
So it looks like the actual domain tree is broken, and not what we
assumed it was.
Could I bother you to run with the below instead? It should also print
out the sched domain masks so we don't need to guess about them.
The full dm
On Fri, Jul 18, 2014 at 11:28:14 +0200,
Dietmar Eggemann wrote:
Didn't see what I was looking for in your dmesg output. Did you use
'earlyprintk=keep sched_debug'
I was missing a space. I'll get it on the next run.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
On Thu, Jul 17, 2014 at 14:35:02 +0200,
Peter Zijlstra wrote:
In any case, can someone who can trigger this run with the below; its
'clean' for me, but supposedly you'll trigger a FAIL somewhere.
I got a couple of fail messages.
dmesg output is available in the bug as the following attachme
On Thu, Jul 17, 2014 at 20:43:16 +0200,
Dietmar Eggemann wrote:
If you could apply the patch:
https://lkml.org/lkml/2014/7/17/288
and then run it on your machine, that would give us more details, i.e.
the information on which sched_group(s) and in which sched domain
level (SMT and/or DIE)
I did a few quick boots this morning while taking a bunch of pictures. I have
gone through some of them this morning and found one that shows bug on
was triggered at 5850 which is from:
BUG_ON(!cpumask_empty(sched_group_cpus(sg)));
You can see the JPEG at:
https://bugzilla.kernel.org/attachment
On Wed, Jul 16, 2014 at 21:17:32 +0200,
Dietmar Eggemann wrote:
Could you please share:
cat /proc/cpuinfo and
cat /proc/schedstat (kernel config w/ CONFIG_SCHEDSTATS=y)
/proc/schedstat output is attached.
version 15
timestamp 4294858660
cpu0 12 0 85767 30027 61826 37767 15709950719 562024106
Could you also put the two BUG_ON lines into build_sched_groups()
[kernel/sched/core.c] wo/ the cpumask_clear() and setting
sg->sgc->capacity to 0 and share the possible crash output as well?
I can try a new build with this. I can probably get results back tomorrow
before I leave for work. The c
On Thu, Jul 17, 2014 at 01:18:36 +0200,
Dietmar Eggemann wrote:
So the output of
$ cat /proc/sys/kernel/sched_domain/cpu*/domain*/*
would be handy too.
Attached and added to the bug.
Just to make sure, you do have 'CONFIG_X86_32=y' and '# CONFIG_NUMA is
not set' in your build?
Yes.
I p
On Wed, Jul 16, 2014 at 21:17:32 +0200,
Dietmar Eggemann wrote:
Hi Bruno and Josh,
From the issue, I see that the machine making trouble is an Xeon (2
processors w/ hyper-threading).
Could you please share:
cat /proc/cpuinfo and
I have attached it to the bug and to this message.
cat /p
So I tried checking out specific revisions and found
09dc4ab03936df5c5aa711d27c81283c6d09f495 is the latest good revision I
can boot. The first bad revision I hit is
51f2176d74ace4c3f58579a605ef5a9720befb00.
I have no idea how to fix it. I'm just a web developer/kernel tester :(
Could you co
caffcdd8d27ba78730d5540396ce72ad022aff2c has been causing crashes early in
the boot process on one of three machines I have been testing the kernel
on. On that one machine it happens every boot. It happens before netconsole
is functional.
A partial revert of the commit fixes the problem. I do
On Mon, Jun 23, 2014 at 08:44:40 +0100,
Al Viro wrote:
blkdev_read_iter() wants to cap the iov_iter by the amount of
data remaining to the end of device. That's what iov_iter_truncate()
is for (trim iter->count if it's above the given limit). So far,
so good, but the argument of iov_iter_tru
On Fri, Sep 27, 2013 at 13:18:20 -0700,
Andrew Morton wrote:
On Fri, 27 Sep 2013 19:53:53 +0200 Jean Delvare wrote:
Andrew,
On Fri, 27 Sep 2013 09:50:39 -0600, Bjorn Helgaas wrote:
> There's some indication that this change might have broken handling of
> signed types. See
> https://lists
On Tue, Jul 23, 2013 at 17:17:30 +0100,
Phillip Lougher wrote:
In otherwords I don't think it's wise yet to merge LZ4 onto stable,
not until at least there's some positive feedback on the mailing list.
Thoughts? Maybe some positive feedback? :-)
I think it makes sense to tie inclusion in
On Mon, Jul 22, 2013 at 03:21:01 +0100,
Phillip Lougher wrote:
Hi
Now that LZ4 compression support is in 3.11-rc1, I have written the
following two patches for Squashfs to use it.
If this gets accepted are you going to move the LZ4 changes to squashfs-tools
into the stable branch? I'd lik
On Thu, Feb 07, 2013 at 08:37:01 -0500,
Josh Boyer wrote:
Anyway, still seems to me that systemd/rtkit-daemon should be _checking_
to see if that feature is present instead of assuming it is and failing
in weird ways when it isn't.
I agree. It would have been a lot quicker to figure this ou
On Fri, Feb 01, 2013 at 14:13:32 -0600,
Bruno Wolff III wrote:
I have been testing 3.8 kernels on Fedora. The last good kernel was
3.8.0-0.rc5.git1.1.fc19.i686.PAE. I tested
3.8.0-0.rc5.git2.1.fc19.i686.PAE, 3.8.0-0.rc5.git3.1.fc19.i686 and
3.8.0-0.rc6.git0.1.fc19.i686.PAE and found these
On Tue, Feb 05, 2013 at 00:45:52 +0100,
JA Magallón wrote:
I had also problems with this and other daemons...
If you are using systemd, check if rtkit wants to run with PrivateTmp=yes.
If this is so, then check that your /tmp is _not_ a symlink, but
a real dir...
In this case it was using p
On Fri, Feb 01, 2013 at 14:13:32 -0600,
Bruno Wolff III wrote:
One is that the rtkit-daemon service fails to start up and the other
is that there are issues with X. One one machine with an rv280 based
video card the background image doesn't show up in gdm and I can't
enter a p
I have been testing 3.8 kernels on Fedora. The last good kernel was
3.8.0-0.rc5.git1.1.fc19.i686.PAE. I tested 3.8.0-0.rc5.git2.1.fc19.i686.PAE,
3.8.0-0.rc5.git3.1.fc19.i686 and 3.8.0-0.rc6.git0.1.fc19.i686.PAE and found
these all had two odd effects.
One is that the rtkit-daemon service fails
On Tue, Dec 04, 2012 at 21:01:33 -0600,
Bruno Wolff III wrote:
On Tue, Dec 04, 2012 at 16:42:10 -0500,
Johannes Weiner wrote:
kernel-3.7.0-0.rc7.git1.2.van.main.knurd.kswap.4.fc18.i686
and
kernel-3.7.0-0.rc7.git1.2.van.main.knurd.kswap.4.fc18.x86_64
for over 24hours with no evidence of
On Tue, Dec 04, 2012 at 16:42:10 -0500,
Johannes Weiner wrote:
kernel-3.7.0-0.rc7.git1.2.van.main.knurd.kswap.4.fc18.i686
and
kernel-3.7.0-0.rc7.git1.2.van.main.knurd.kswap.4.fc18.x86_64
for over 24hours with no evidence of problems with kswapd"
Now waiting for results from Jiri, Zdenek and
On Tue, Nov 20, 2012 at 10:38:45 -0500,
Josh Boyer wrote:
We've been tracking it in https://bugzilla.redhat.com/show_bug.cgi?id=866988
and people say this revert patch doesn't seem to make the issue go away
fully. Thorsten has created another kernel with the other patch applied
for testing.
On Wed, Nov 07, 2012 at 13:21:41 -0600,
Bruno Wolff III wrote:
I tested building dahdi-linux with kernel-3.7.0-0.rc4.git1.1.fc19
which has this patch and the build went fine. I won't be able to test
that the module works until tonight, but even if it ends up being
broken the signing
On Tue, Nov 06, 2012 at 07:54:17 -0500,
Josh Boyer wrote:
On Tue, Nov 06, 2012 at 12:04:02PM +1030, Rusty Russell wrote:
I've applied this in my fixes branch, will push to Linus later this
week.
Great. Thanks Rusty!
josh
I tested building dahdi-linux with kernel-3.7.0-0.rc4.git1.1.fc19
On Thu, Aug 30, 2012 at 16:10:10 +0200,
Takashi Iwai wrote:
As the test result looks positive, I applied it for the next pull
request. Thanks.
I tested 3.6.0-0.rc3.git3.2.fc18.i686.PAE (which inlcudes the patches) on two
more machines last night and it worked on them as well.
--
To unsu
On Wed, Aug 29, 2012 at 13:22:54 -0400,
Josh Boyer wrote:
On Wed, Aug 29, 2012 at 01:07:53PM -0400, Josh Boyer wrote:
> Right. New patch attached.
I'll try and get another kernel built with this later today. I'm at
Plumbers so it might have to wait a bit.
OK, I got impatient with myself a
On Sat, Aug 25, 2012 at 08:13:27 -0400,
Josh Boyer wrote:
On Sat, Aug 25, 2012 at 07:07:40AM -0500, Bruno Wolff III wrote:
On Sat, Aug 25, 2012 at 14:02:51 +0200,
Daniel Mack wrote:
>
>Can you revert commit e9ba389c5 ("ALSA: usb-audio: Fix
>scheduling-while-atomic bug
On Sat, Aug 25, 2012 at 08:13:27 -0400,
Josh Boyer wrote:
On Sat, Aug 25, 2012 at 07:07:40AM -0500, Bruno Wolff III wrote:
On Sat, Aug 25, 2012 at 14:02:51 +0200,
Daniel Mack wrote:
>
>Can you revert commit e9ba389c5 ("ALSA: usb-audio: Fix
>scheduling-while-atomic bug
On Sat, Aug 25, 2012 at 14:02:51 +0200,
Daniel Mack wrote:
Can you revert commit e9ba389c5 ("ALSA: usb-audio: Fix
scheduling-while-atomic bug in PCM capture stream") and see if that
I can try that, but it takes a long time to build a new kernel on my
old hardware.
helps? If not, can you
On Sat, Aug 25, 2012 at 06:17:49 -0500,
Bruno Wolff III wrote:
I see this behavior on three different computers. Rebooting into an old
enough kernel gets things working again. The older kernels also have
older initramfs images. I could rebuild those to see if there is some
issue there
On Sat, Aug 25, 2012 at 00:30:22 +0200,
Daniel Mack wrote:
So what does "isn't working anymore" refer to precisely? Are there any
more dmesg entries generated once the stream is started?
When I try to play music, the progress bar for the song doesn't advance and
there is no audbile sound.
On Fri, Sep 21, 2007 at 16:58:15 +0100,
Hugh Dickins <[EMAIL PROTECTED]> wrote:
>
> But once I look harder at it, I wonder what would have kept
> 2.6.18 to 2.6.23 safe from the same issue: per-cpu deltas from
> the global vm stats too low to get synched back to global, yet
> adding up to somethi
69 matches
Mail list logo
