less, on the other hand, so seems good to me.
--
Meelis Roos
make -j64?
--
Meelis Roos
Tested by the below topology:
qemu-system-aarch64 -M virt -nographic \
Also works on the initial 8-node Sun Fire X4600-M2. No strange messages in
dmesg and no problems on kernel build with make -j64.
Tested-by: Meelis Roos
Could you paste the output of the below?
$ cat /sys/devices/system/node/node*/distance
10 12 12 14 14 14 14 16
12 10 14 12 14 14 12 14
12 14 10 14 12 12 14 14
14 12 14 10 12 12 14 14
14 14 12 12 10 14 12 14
14 14 12 12 14 10 14 12
14 12 14 14 12 14 10 12
16 14 14 14 14 12 12 10
Additio
5.9 introduces VGA console corruption in one of my test PC-s (I do not have VGA
console on most). The PC has Intel D2550MUD2 board with Atom D2550.
The symptoms include:
* missing screen updates on VT switch
* fragments of other VT-s appear during scrolling (kernel compilation output on
visible
I have an AlphaServer DS20E that ran 5.6.0 fine. 5.8.0 had a problem during
rc's - ext4 mounting failed
due to corrupt data (looked like memory corruption but was very deterministic).
5.8.0 release booted
fine once but if 5.9-git failed again, I recompiled 5.8.0 and that failed too.
Next 5.9-gi
000112cc96 CR3: 0000bb72e000 CR4: 06f0
--
Meelis Roos
s 5.9-rc4 cures it here as well - whatever the reason might have
been.
Nope, the reason was nondeterminism - it happened on the Core2Quad running
5.9-rc4 while trying to compile todays Linux from git.
--
Meelis Roos
0 R15: 0000--
Meelis Roos
Replying to myself:
This is 5.9-rc4 git on a specific amd64 machine with Debian unstable and custom
kernel config. 5.8 compiled and worked fine, I have seen something like this
with different 5.9-git commits. I made sure my binutils and gcc-10 are up to
date in Debian unstable and retried wit
:
0xdead0400 loks like some kind of poisoning.
[307299.392045] general protection fault, probably for non-canonical address
0xdead0400: [#1] SMP PTI
Was not reproducible in 5.9-rc4 while recompiling the kernel in a loop for 8
hours.
--
Meelis Roos
This is 5.9-rc4 git on a specific amd64 machine with Debian unstable and custom
kernel config. 5.8 compiled and worked fine, I hav seen something like this
with different 5.9-git commits. I made sure my binutils and gcc-10 are up to
date in Debian unstable and retried with 5.9-rc4. Still I see
ged for me recently.
--
Meelis Roos
I noticed that while 5.1 works on my HP Integrity RX2620, 5.2-rc6 crashed on
boot nondeterministically.
Bisecting it took many tries sice it does not happen on each boot and when it
happes, the symptoms are
different each time. But now the bisection converged to
!ma868b104d7379e28013e9d48bdd2db
Tried todays git on Sun Netra 240 (sparc64). Got bootup crash with custom,
machine-specific config:
[ 47.760841] Kernel unaligned access at TPC[7bf124]
sock_prot_inuse_add+0x4/0x20
[ 47.856969] Unable to handle kernel paging request in mna handler
[ 47.856972] at virtual address
The same Sun V445 that gave me BPF errors, had a differrnet error with todays
git, just idling:
[ 51.530195] Kernel unaligned access at TPC[58265c]
deactivate_slab.isra.28+0xfc/0x420
[ 51.675010] Unable to handle kernel paging request in mna handler
[ 51.675013] at virtual address 91d020
being worked on now,
so hopefully we won't need this patch:
https://marc.info/?l=linux-sparc&m=155915694304118&w=2
And the sparc64 patch that fixes CONFIG_DEBUG_PAGEALLOC also fixes booting
of the latest git kernel on Sun V445 where my problem initially happened.
--
Meelis Roos
Switch VM_FLUSH_RESET_PERMS to use a regular TLB flush intead of
vm_unmap_aliases() and fix calculation of the direct map for the
CONFIG_ARCH_HAS_SET_DIRECT_MAP case.
Meelis Roos reported issues with the new VM_FLUSH_RESET_PERMS flag on a
sparc machine. On investigation some issues were noticed
, that was my config on 2-CPU RX2660.
--
Meelis Roos
The warning UBSAN: Undefined behaviour in mm/compaction.c:1167:30 happened with
5.1-rc6 on UP 32-bit P4 PC with highmem.
[ 95.135408]
[ 95.135478] UBSAN: Undefined behaviour in mm/compaction.c:1167:30
[ 95.13
You might be hitting a bug I found.
Try applying this patch:
https://marc.info/?l=linux-kernel&m=155355953012985&w=2
Unfortunately it did not change anything.
--
Meelis Roos
_blackbird: registered device video1 [mpeg]
[ 16.287894] modprobe (155) used greatest stack depth: 5496 bytes left
[ 16.803253] Adding 2096124k swap on /dev/sda5. Priority:-2 extents:1
across:2096124k
[ 20.717229] IPv6: ADDRCONF(NETDEV_CHANGE): enp0s18: link becomes ready
[ 21.027559] systemd-udevd (100) used greatest stack depth: 4416 bytes left
--
Meelis Roos
:79!
Screenshot at http://kodu.ut.ee/~mroos/debug_virtual-boot-hang-1.jpg
The machine was Athlon XP with VIA KT600 chipset and 2G RAM.
--
Meelis Roos
to
CONFIG_BOUNCE or CONFIG_MIGRATION + CONFIG_COMPACTION? These are two
completely different things so knowing where to look will help. Thanks!
Tested both.
Just CONFIG_MIGRATION + CONFIG_COMPACTION breaks the alpha.
Just CONFIG_BOUNCE has no effect in 5 tries.
--
Meelis Roos
them.
First, I found out that both the problematic alphas had memory compaction and
page migration and bounce buffers turned on, and working alphas had them off.
Next, turing off these options makes the problematic alphas work.
--
Meelis Roos
ation and Alpha (added MM list to CC).
But my kernel config had memory compaction (that turned on page migration) and
bounce buffers. I do not remember why I found them necessary but I will try
without them.
--
Meelis Roos
-unverified-download-quarantine
/usr/portage/ /usr/portage/.tmp-unverified-download-quarantine/
Nothing in dmesg.
This means the real root reason is somewhere deeper and reverting this commit
just made
it less likely to happen.
--
Meelis Roos
look into
this.
To make things more interesting, it does not happen on any alpha but only one
subarch
so far:
https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1889207.html
is my original bug report.
--
Meelis Roos
makes the problem go away?
Tried reverting it on top of 5.0.0-rc6-00153-g5ded5871030e and it seems to make
the kernel work - emerge --sync succeeded.
Unfinished further bisection has also not yielded any other bad revisions so
far.
--
Meelis Roos
and PC164 have sym2 based scsi controllers too.
--
Meelis Roos
Got UBSAN warning from Dell D600 running 5.0.0-rc4-00218-g12491ed354d2.
The warning did not happen on bootup but during xfce session start or console
switch.
[ 15.323113] radeon :01:00.0: putting AGP V2 device into 4x mode
[ 15.323134] radeon :01:00.0: GTT: 128M 0xE000 - 0xE7
. Working Eiger and PC164 have sym2 based scsi controllers too.
--
Meelis Roos
The patch below was just applied to my tree, hopefully ti fixes this
issue.
Yes, it cures both the HP A500 (parisc) and HP RX2620 (ia64) that I also found
breaking meanwhile.
--
Meelis Roos
8ffeb35557070a5
a011db1916fbf5cfdcfff836a81e4fb5ee737003 M drivers
:04 04 b1b1dc977965eb2db6b2cc79939446a1cf2f684d
41322ab1c199f504cfcc5b2ca211b4638d41351c M include
--
Meelis Roos
I have noticed ext4 filesystem corruption on two of my test alphas with
4.20.0-09062-gd8372ba8ce28.
On AlphaServer DS10:
[10749.664418] EXT4-fs error (device sda2): __ext4_iget:5052: inode #1853093:
block 1: comm rsync: invalid block
On AlphaServer DS10L:
[ 5325.064656] EXT4-fs error (device s
ne: Make CONFIG_RETPOLINE depend on compiler
support")
Reported-by: Meelis Roos
Signed-off-by: Masahiro Yamada
---
Changes in v2:
- Revive ifdef CONFIG_RETPOLINE surrounding the KBUILD_CFLAGS addition
- Rephase the commit log a bit, hoping the cause of the issue will be clearer
/auto.conf:CONFIG_RETPOLINE=y
So the headers have not been updated yet, maybe?
--
Meelis Roos
8] x86/mm: Checked W+X mappings: FAILED, 2182367 W+X pages found.
--
Meelis Roos
Can you try the patch below? This is extracted from the code here:
https://github.com/joyent/illumos-joyent/blob/b6a0b04d591f5b877cfe05f45e81f0e8a5cfc2b3/usr/src/uts/intel/io/pci/pci_boot.c#L1805
Thank you. Unfortunately it does not change anything noticable.
Do you see the "disabling NMI on
with initramfs worked fine so far for my
test,
from these I have in grub menu. My selfcompiled kernels do not use initramfs.
--
Meelis Roos
d be
useful if this is related to some sort of bus error.
Nothing in the ILO logs.
--
Meelis Roos
seem to mostly assume 686 and PAE anyway for 32-bit systems.
--
Meelis Roos (mr...@ut.ee) http://www.cs.ut.ee/~mroos/
This is weekend's 4.19.0-rc2-00246-gd7b686ebf704 on a Thinkad T460s.
There seems to be a usercopy warning from rng_dev read (full dmesg
below).
[0.00] microcode: microcode updated early to revision 0xc6, date =
2018-04-17
[0.00] Linux version 4.19.0-rc2-00246-gd7b686ebf704 (mroo
Some time yesterday I have got this warning in dmesg.
[55255.629421] usercopy: Kernel memory exposure attempt detected from SLUB
object 'kmalloc-64' (offset 0, size 379)!
[55255.629440] [ cut here ]
[55255.629446] kernel BUG at mm/usercopy.c:102!
[55255.629465] invalid op
suspicious. Is this an entitely new issue on 4.19-rc or can you see
> the same with older kernel versions?
4.18 was fine with sea same toolchain, so this is a new issue.
--
Meelis Roos (mr...@linux.ee)
14/#gcc-5_5.3.1-14 - the
whole system is a snapshot of debian unstable when they stoooed
supporting pre-686 CPUs.
--
Meelis Roos (mr...@linux.ee)
E was not visible itself, but when I changed HIGHMEM_4G to
HIGHMEM_64G, X86_PAE was also selected and the resutling kernel works.
Also, I verified that the olid proliants with 6G RAM already have
HIGHMEM_64G set and they do not exhibit the problem either.
--
Meelis Roos (mr...@linux.ee)
eck, but out of my memery there were 2 G3 HP Proliants that did
not fit into the pattern (problem did not appear). I have more than 4G
RAM in those and HIGHMEM_4G there, maybe that's it?
--
Meelis Roos (mr...@linux.ee)
I am seeing userland corruption and application crashes on multiple
32-bit machines with 4.19-rc1+git. The machines vary: PII, PIII, P4.
They are all Intel. AMD Duron/Athlon/AthlonMP have been fine in my tests
so far (may be configuration dependent).
Typical problem is running aptitude in Debia
While trying to compile v4.18-13105-gaba16dc5cf93 with gcc 5.3.1 on a
32-bit x86 configured for AMD K6:
CC mm/slub.o
In file included from ./arch/x86/include/asm/atomic.h:8:0,
from ./include/linux/atomic.h:7,
from ./arch/x86/include/asm/thread_info.h:54,
ith pkg-config (and error
out if it does not give working result).
--
Meelis Roos (mr...@linux.ee)
/kernel/ptrace.o] Error 1
--
Meelis Roos (mr...@linux.ee)
at TPC[6b8ba8] aa_dfa_unpack+0x48/0x620
[ 46.412392] Kernel unaligned access at TPC[6b8c28] aa_dfa_unpack+0xc8/0x620
[ 46.698283] Kernel unaligned access at TPC[6b8ce8] aa_dfa_unpack+0x188/0x620
[ 46.789536] Kernel unaligned access at TPC[6b8cfc] aa_dfa_unpack+0x19c/0x620
--
Meelis Roos (mr
Tried to compile current git (v4.18-1934-gbe718b524d8d) with AMD KVM and
got the following linking error:
MODPOST vmlinux.o
ld: arch/x86/kvm/x86.o: in function `kvm_get_arch_capabilities':
x86.c:(.text+0x5132): undefined reference to `l1tf_vmx_mitigation'
#
# Automatically generated file; DO N
the value at runtime (it
would be postfactum). Do you mean changing the
CONFIG_BPF_JIT_ALWAYS_ON=y option?
Anyway, I started compile of v4.18-rc5 that was the latest I tested,
with the commit in question reverted. Will see if I can test tomorrow
morning. But I will leave tomorrow for a week and can only test further
things if they happen to boot fine (no manual reboot possible for a
week).
--
Meelis Roos (mr...@linux.ee)
n code
git bisect bad e64d52569f6e847495091db40ab58d2d379748ef
# bad: [b4264c96b5cbc00c4c07deb9fbab928d43dffcf9] nfp: bpf: rewrite map
pointers with NFP TIDs
git bisect bad b4264c96b5cbc00c4c07deb9fbab928d43dffcf9
# bad: [9816dd35ececc095f3e3be29d30d3adc755908d9] nfp: bpf: perf event output
helpers support
git bisect bad 9816dd35ececc095f3e3be29d30d3adc755908d9
# first bad commit: [9816dd35ececc095f3e3be29d30d3adc755908d9] nfp: bpf: perf
event output helpers support
--
Meelis Roos (mr...@linux.ee)
test v4.17-rc4, which is what the net-next tree was based on.
>
> Yes, the same prebuilt 3a443bd6dd7c appeared to be bad when retesting
> it. Building v4.17-rc4 now.
v4.17-rc4 seems good after 2 reboots.
--
Meelis Roos (mr...@ut.ee) http://www.cs.ut.ee/~mroos/
;,
> and can't really be good if 0bc5fe85727413 is bad and you are not using the
> 'qed' driver.
>
> I'd retest 3a443bd6dd7c again to see if that should have been 'bad', and
> if it was, test v4.17-rc4, which is what the net-next tree was based on.
Yes, the same prebuilt 3a443bd6dd7c appeared to be bad when retesting
it. Building v4.17-rc4 now.
--
Meelis Roos (mr...@linux.ee)
4a
# bad: [27bf96e32c92599dc7523b36d6c761fc8312c8c0] qed: Remove unused data
member 'is_mf_default'.
git bisect bad 27bf96e32c92599dc7523b36d6c761fc8312c8c0
# bad: [0bc5fe857274133ca028ebb15ff2e8549a369916] qed*: Refactor mf_mode to
consist of bits.
git bisect bad 0bc5fe857274133ca028ebb15ff2e8549a369916
# first bad commit: [0bc5fe857274133ca028ebb15ff2e8549a369916] qed*: Refactor
mf_mode to consist of bits.
--
Meelis Roos (mr...@linux.ee)
"The hang is caused when, during PCI enumeration, a PCI-PCI bridge is
partially disabled when the PCI command register bits which enable IO
and memory windows are cleared."
Is this information useful in some way for debugging it?
What else besides screenshot of the can be useful in de
R11: 0001 R12:
[91550.439012] R13: 7f54e8c96c40 R14: 02e3b010 R15: 7f54e8c96ca0
[91550.439013]
========
--
Meelis Roos (mr...@linux.ee)
d like it is related to my patches indeed. If you are not
> yet done bisecting, please checkout commit e27c49291a7f ("x86: Convert
> x86_platform_ops to timespec64") before you try anything else, that
> one is the top of the branch with my changes. If that fails, the bisection
> will be much quicker.
This commit was fine. So it's likely something else.
--
Meelis Roos (mr...@linux.ee)
I tried 4.18.0-rc1-00023-g9ffc59d57228 and now
4.18.0-rc3-00113-gfc36def997cf on a 32-bit server and then some other
32-bit machines, and got half-failed bootup - kernel and userspace come
up but some services fail to start, including network and
systemd-journald:
systemd-journald[85]: Asserti
HP Proliant DL360 G6 displays the following on bootup with
4.18.0-rc1-00023-g9ffc59d57228 (4.17 did not display this warning):
[0.00] WARNING: WARNING: Bad or missing .orc_unwind table. Disabling
unwinder.
Debian unstable, gcc 7.3.0-21, config below.
#
# Automatically generated file;
c0181260
[7.611894] FS: 7fef3a80b8c0() GS:8e8e3dd0()
knlGS:
[7.611988] CS: 0010 DS: ES: CR0: 80050033
[7.612067] CR2: CR3: 3ab1a000 CR4: 000006e0
--
Meelis Roos (mr...@linux.ee)
] [c0016230] do_page_fault+0x1bc/0x7e8
[ 140.519037] [d05a5f40] [c0012300] handle_page_fault+0x14/0x40
[ 140.519048] --- interrupt: 301 at 0xb78b6864
LR = 0xb78b6c54
--
Meelis Roos (mr...@linux.ee)
I had the same kthread_parkme warning on many machines I tested with
4.17.0-rc6-00158-gbee797529d7c (x86, amd64, sparc, parisc, alpha).
Your patch https://lkml.org/lkml/2018/5/4/212 fixed the problem for me.
Sorry for off-thread respnse, I found your mail from the web only.
--
Meelis Roos (mr
device (%04x -> %04x)\n", old_cmd, cmd);
^
scripts/Makefile.build:312: recipe for target 'arch/sparc/kernel/pci.o' failed
--
Meelis Roos (mr...@linux.ee)
> Hello, Meelis.
>
> Can you please verify whether the following patch fixes the problem?
>
> Thanks.
>
> Subject: blk-mq: Directly schedule q->timeout_work when aborting a request
Yes, this patch on top of 4.16 fixes it for me. dmesg shows CD detection
works fast now:
[2.278383] libata v
ok.
v2: - Add comment explaining the lack of synchronization around
->deadline update as requested by Bart.
Signed-off-by: Tejun Heo
Cc: Asai Thambi SP
Cc: Stefan Haberland
Cc: Jan Hoeppner
Cc: Bart Van Assche
Signed-off-by: Jens Axboe
:04 04 b5c8c2fd69850021865071f9641d54ab4fd20a15
e2dbd2a15a6baeec1332cc1416e51d537ff5040a M block
--
Meelis Roos (mr...@linux.ee)
> On Thursday, March 29, 2018 11:54:09 AM Meelis Roos wrote:
> > > 4.16 git bootup on HP Proliant DL380 G3 pauses for a a minute or two and
> > > then continues with "blocked for more than 120 seconds" message with
> > >
for TX and off for
> RX
> [ 246.012990] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
> [ 316.432903] scsi 1:0:0:0: Attached scsi generic sg3 type 5
> [ 316.667528] sr 1:0:0:0: [sr0] scsi3-mmc drive: 24x/24x cd/rw xa/form2 cdda
> tray
> [ 316.667571] cdrom: Uniform CD-ROM driver Revision: 3.20
> [ 316.667837] sr 1:0:0:0: Attached scsi CD-ROM sr0
> [ 4097.814125] random: crng init done
>
>
--
Meelis Roos (mr...@linux.ee)
> > This is Intel SE7520JR22S mainboard with 2 64-bit P4 xeons. Earlier
> > kernels up to 4.14 have had W+X checking on but found nothing. Now I
> > tried 4.15.0-rc9-00023-g1f07476ec143 and it gives a new W+X warning.
>
> This still happens in 4.15 and 4.16-rc2+.
>
> What can I do to help reso
c7 08 5b ee 81 e8 4b d6 00 00 <0f>
> ff 48 8b 73 10 e9 bc f9 ff ff 4d 85 ed 0f 84 b9 01 00 00 41
> [ 10.883103] ---[ end trace bc3e2cf1a1adfa39 ]---
> [ 10.896336] x86/mm: Checked W+X mappings: FAILED, 266243 W+X pages found.
> [ 10.896430] x86/mm: Checking user space page tables
> [ 10.909522] x86/mm: Checked W+X mappings: FAILED, 56 W+X pages found.
--
Meelis Roos (mr...@linux.ee)
(fb0) is primary device
[8.193959] Console: switching to colour frame buffer device 160x64
[8.195378] nouveau :00:0d.0: fb0: nouveaufb frame buffer device
[8.212083] [drm] Initialized nouveau 1.3.1 20120801 for :00:0d.0 on
minor 0
--
Meelis Roos (mr...@linux.ee)
5 7d 45 6f 01 01 48 89 f2 48 c7 c7 08 5b ee 81 e8 4b d6 00 00 <0f>
> ff 48 8b 73 10 e9 bc f9 ff ff 4d 85 ed 0f 84 b9 01 00 00 41
> [ 10.883103] ---[ end trace bc3e2cf1a1adfa39 ]---
> [ 10.896336] x86/mm: Checked W+X mappings: FAILED, 266243 W+X pages found.
> [ 10.896430]
dy
[ 316.432903] scsi 1:0:0:0: Attached scsi generic sg3 type 5
[ 316.667528] sr 1:0:0:0: [sr0] scsi3-mmc drive: 24x/24x cd/rw xa/form2 cdda
tray
[ 316.667571] cdrom: Uniform CD-ROM driver Revision: 3.20
[ 316.667837] sr 1:0:0:0: Attached scsi CD-ROM sr0
[ 4097.814125] random: crng init done
--
Meelis Roos (mr...@linux.ee)
I added a Atto U320 SCSI card into my HP Proliant DL585 (G1 despite the
G naming was not used then). I have not tried earlier kernels.
In dmesg there are actually two sets of BAR assignment failures, the
first bridge may or may not be related.
[0.353439] pci :00:03.0: BAR 15: no space f
> This happens on a HP DL360 G6 with Smart Array 410i.
>
> Will try to bisect.
>
> IO completion timeout could be because of some IRQ toubles?
Reverting 84676c1f21e8ff54befe985f4f14dc1edc10046b fixes it for me (as
suggested by Laurence Oberman).
--
Meelis Roos (mr...@linux.ee)
--
Meelis Roos (mr...@linux.ee)
DRM: MM: using M2MF for buffer copies
[1.517930] nouveau :04:05.0: DRM: allocated 1024x768 fb: 0x4000, bo
a09f4d1f
[1.519294] nouveau :04:05.0: fb1: nouveaufb frame buffer device
[1.519313] [drm] Initialized nouveau 1.3.1 20120801 for :04:05.0 on
minor 1
--
Meelis Roos (mr...@linux.ee)
This is 4.16-rc1+git as of today, on a IBM PC 365 that uses APM instead
of ACPI. APM linking fails:
MODPOST vmlinux.o
arch/x86/kernel/apm_32.o: In function `apm_init':
apm_32.c:(.init.text+0x597): undefined reference to `cpuidle_poll_state_init'
Config:
#
# Automatically generated file; DO NO
> This is 4.16-rc1+todays git on a lowly P4 with NV5, worked fine in 4.15:
NV5 in another PC (secondary card in x86-64) made the systrem crash on
boot, in nvkm_therm_clkgate_fini.
--
Meelis Roos (mr...@linux.ee)
erm_clkgate_fini+0x15/0x174 [nouveau] SS:ESP:
0068:f6155834
[7.423899] CR2:
[7.424033] ---[ end trace cad535783d11d7b9 ]---
--
Meelis Roos (mr...@linux.ee)
.archdata.dma_mask;
> dev->ofdev.dev.parent = parent;
> dev->ofdev.dev.bus = &macio_bus_type;
> dev->ofdev.dev.release = macio_release_dev;
Yes, it does - thank you!
Tested-by: Meelis Roos
--
Meelis Roos (mr...@linux.ee)
:
[1.418409] 939d 4bff6329 80010024 7fe3fb78 8361000c 83810010 7c0803a6
83a10014
[1.424201] 83c10018 83e1001c 38210020 4e800020 <0fe0> 4b84 7fa3eb78
3be0
[1.430020] ---[ end trace 89c0f4a91a110769 ]---
--
Meelis Roos (mr...@linux.ee)
rity are alive.
--
Meelis Roos (mr...@linux.ee)
d_startup(desc, IRQ_NORESEND))
^~~~
Just
irq_activate_and_startup(desc, IRQ_NORESEND);
cures the warning and at least the first bootup was working otherwise
too.
--
Meelis Roos (mr...@linux.ee)
Upgraded some of my older machines to v4.15 today. On a quad P3 HP
NetServer, I get a bootup warning at kernel/irq/chip.c:244
__irq_startup+0x80/0x100 (full dmesg below). It seems it was there
before but I did not notice it.
Reading older kernel logs, I found that up to
4.15.0-rc4-00041-gace52
;STATUS"
operation="profile_load" profile="unconfined" name="/usr/bin/man//groff"
pid=1013 comm="apparmor_parser"
[ 17.610155] audit: type=1400 audit(1516811432.167:5): apparmor="STATUS"
operation="profile_load" profile="unconfined" name="/usr/sbin/ntpd" pid=1014
comm="apparmor_parser"
--
Meelis Roos (mr...@linux.ee)
with screen on. It just hangs.
>
> And as of last Fridays git, it seems to have been fixed, so I did not
> try to bisect it.
And as of yesterdays git, the problem is back again :(
Will see if I can biusect it this time on battery power.
--
Meelis Roos (mr...@linux.ee)
> I am compiling the x86/urgent pull that you suggested.
And it works.
--
Meelis Roos (mr...@linux.ee)
or revert test.
Reverting this patch worked on 2 of the machines, 3rd one is compiling.
--
Meelis Roos (mr...@linux.ee)
t hangs.
And as of last Fridays git, it seems to have been fixed, so I did not
try to bisect it.
--
Meelis Roos (mr...@linux.ee)
> I've reverted the commit which Dou pointed out in rc8. Can you please confirm
> that
> this fixes the issue for you?
Tried rc8 on the P3, it still hangs.
--
Meelis Roos (mr...@linux.ee)
On Wed, 10 Jan 2018, Thomas Gleixner wrote:
> On Wed, 10 Jan 2018, Meelis Roos wrote:
>
> > > > On 3 of my test computers, boot hangs with 4.15 git kernels. So far I
> > > > have traced it down to 4.14.0 being good and 4.15-rc1 being bad (bisect
> > &
way to reproduce the
> problem.
I seem to have found a better reproducer - when running on battery, it
will hang after some minutes, with screen on. It just hangs.
--
Meelis Roos (mr...@linux.ee)
> > P4 was the quickest to rebuild the kernel and it is still hanging like
> > before with todays 4.15-rc7-00102-gcf1fb158230e.
>
> I try to find a time slot for this ...
And I will try to bisect.
--
Meelis Roos (mr...@linux.ee)
not tries newer than rc5
> > kernels.
>
> Please do so. We have fixes post rc5 in that area.
P4 was the quickest to rebuild the kernel and it is still hanging like
before with todays 4.15-rc7-00102-gcf1fb158230e.
--
Meelis Roos (mr...@linux.ee)
options) was working
fine.
Nothing in the log files afterwards. Network connection is WiFi. There
is a USB mouse connected.
Wat do I check next?
--
Meelis Roos (mr...@linux.ee)
1 - 100 of 520 matches
Mail list logo
