I've put 4.14.27 this morning in this machine and in about 2h it started
showing null dereferences identical to the following one. There were several of
them, with about 1/2h of interval. Strangely it continued to work and I saw no
other anomalies. I've just reverted to 4.14.26.
It only happened i
Near the end of the build this appears:
KSYM.tmp_kallsyms2.S
AS .tmp_kallsyms2.o
LD vmlinux.o
MODPOST vmlinux.o
WARNING: vmlinux.o(.text.head+0xe4): Section mismatch: reference to
.init.data.2:trampoline_level4_pgt (between 'ident_complete' and
'secondary_startup_64')
WARNI
Jeff Lessem ([EMAIL PROTECTED]) wrote on 6 November 2007 22:00:
>Dan Williams wrote:
> > The following patch, also attached, cleans up cases where the code looks
> > at sh->ops.pending when it should be looking at the consistent
> > stack-based snapshot of the operations flags.
>
>I tried thi
Sean Hunter ([EMAIL PROTECTED]) wrote on 14 February 2001 17:26:
>This is an application problem, not a kernel one. You need to upgrade your
>netkit.
Yes, I was quite confident of this. However, unaligned traps are a
frequent problem with alphas. For a looong time we had zsh produce
lots of it
Jan-Benedict Glaw ([EMAIL PROTECTED]) wrote on 14 February 2001 15:48:
>With my currently installed ping (netkit-ping 0.10-6 from Debian Woody)
>I get unaligned accesses:
>
>ping(15953): unaligned trap at 0001200030e4: 000120026b34 29 1
>ping(15953): unaligned trap at 000120003110
Trond Myklebust ([EMAIL PROTECTED]) wrote on 13 February 2001 10:56:
>--- net/sunrpc/ping.c.origTue Feb 13 10:47:20 2001
>+++ net/sunrpc/ping.c Tue Feb 13 10:50:03 2001
**
Oops, the BUG() call appears in xprt.c! Here's a patch that makes it
compile. Let's see if it runs
Trond Myklebust ([EMAIL PROTECTED]) wrote on 13 February 2001 10:56:
>Actually, since BUG() only seems to be defined on i386 platforms for
>2.2.x, perhaps the easiest thing to do (unless somebody wants to
>volunteer to backport all the `safe' definitions from 2.4.x) would be
>to add the generi
Alan Cox ([EMAIL PROTECTED]) wrote on 12 February 2001 21:49:
>The ideal solution would be for someone to provide BUG() on the
>Alpha platform as in 2.4. That would sort things cleanly
Hmm... Looks more difficult than I expected. Can we just change the
one call to BUG to something sensible on a
When doing the final ld -o vmlinux on an alpha the linker
complains:
net/network.a(sunrpc.o): In function `xprt_ping_reserve':
sunrpc.o(.text+0x4b94): undefined reference to `BUG'
sunrpc.o(.text+0x4b98): undefined reference to `BUG'
Looks like a problem in Trond's patches, also it doesn't h
Doug Ledford ([EMAIL PROTECTED]) wrote on 9 February 2001 16:41:
>The latest patch I sent Alan had both the hosts.c fix and some other fixes, so
>I'm thinking it hasn't made it into his 2.2.19pre9 kernel. The next one
>should work fine as far as aic7xxx is concerned.
I think you should post y
Alan Cox ([EMAIL PROTECTED]) wrote on 31 January 2001 15:23:
>> > In the intel databook. Generally an MCE indicates hardware/power/cooling
>> > issues
>>
>> Doesn't an MCE also cover some hardware memory problems - parity/ECC
>> issues etc?
>
>Parity/ECC on main memory is reported by the c
Adrian Chung ([EMAIL PROTECTED]) wrote on 4 February 2001 15:53:
>I've been attempting to get two Promise Ultra66 controllers working
>with an Asus P2B-F motherboard. I've got one controller successfully
>working, but as soon as I stick the second controller in the computer,
>the system refus
Jan Kara ([EMAIL PROTECTED]) wrote on 4 September 2000 08:25:
> Following patch fixes bug in dquot_transfer() - while we were sleeping
>i_blocks might change and so number quota was miscounted. Patches are
>against 2.2.16 and 2.4.0-test6 (but should apply well on newer versions).
I seem to ha
13 matches
Mail list logo
