On Wed, Apr 20, 2016 at 01:46:13AM +0100, Maciej W. Rozycki wrote:
> I can see if I can find anything suspicious there if you send me original
> copies (i.e. those that oopsed) of arch/alpha/kernel/irq_alpha.o and
> arch/alpha/kernel/core_cia.o.
>
> > Machine has been stable since the machine
On Wed, Apr 20, 2016 at 01:46:13AM +0100, Maciej W. Rozycki wrote:
> I can see if I can find anything suspicious there if you send me original
> copies (i.e. those that oopsed) of arch/alpha/kernel/irq_alpha.o and
> arch/alpha/kernel/core_cia.o.
>
> > Machine has been stable since the machine
On Tue, 19 Apr 2016, Bob Tracy wrote:
> > 4.6.0-rc4 build complete, including suggested (by Alan Young) "Verbose
> > Machine Checks" option set to level 2 by default. System rebooted, and
> > now we wait... Thanks for everyone's continued patience.
>
> Within three minutes of rebooting, I got
On Tue, 19 Apr 2016, Bob Tracy wrote:
> > 4.6.0-rc4 build complete, including suggested (by Alan Young) "Verbose
> > Machine Checks" option set to level 2 by default. System rebooted, and
> > now we wait... Thanks for everyone's continued patience.
>
> Within three minutes of rebooting, I got
On Mon, Apr 18, 2016 at 09:52:43PM -0500, Bob Tracy wrote:
> 4.6.0-rc4 build complete, including suggested (by Alan Young) "Verbose
> Machine Checks" option set to level 2 by default. System rebooted, and
> now we wait... Thanks for everyone's continued patience.
Within three minutes of
On Mon, Apr 18, 2016 at 09:52:43PM -0500, Bob Tracy wrote:
> 4.6.0-rc4 build complete, including suggested (by Alan Young) "Verbose
> Machine Checks" option set to level 2 by default. System rebooted, and
> now we wait... Thanks for everyone's continued patience.
Within three minutes of
On Mon, Apr 18, 2016 at 02:47:40PM +0100, Maciej W. Rozycki wrote:
> On Mon, 18 Apr 2016, Bob Tracy wrote:
>
> > Build delayed slightly. Ran into "fs/binfmt_em86.o" build failure
> > patched by Daniel Wagner back in February (incompatible-pointer-types
> > warning treated as error by compiler).
On Mon, Apr 18, 2016 at 02:47:40PM +0100, Maciej W. Rozycki wrote:
> On Mon, 18 Apr 2016, Bob Tracy wrote:
>
> > Build delayed slightly. Ran into "fs/binfmt_em86.o" build failure
> > patched by Daniel Wagner back in February (incompatible-pointer-types
> > warning treated as error by compiler).
On Mon, 18 Apr 2016, Bob Tracy wrote:
> Build delayed slightly. Ran into "fs/binfmt_em86.o" build failure
> patched by Daniel Wagner back in February (incompatible-pointer-types
> warning treated as error by compiler). Is Daniel's patch queued for
> incorporation into the main kernel source
On Mon, 18 Apr 2016, Bob Tracy wrote:
> Build delayed slightly. Ran into "fs/binfmt_em86.o" build failure
> patched by Daniel Wagner back in February (incompatible-pointer-types
> warning treated as error by compiler). Is Daniel's patch queued for
> incorporation into the main kernel source
On Sun, Apr 17, 2016 at 10:58:48PM -0500, Bob Tracy wrote:
> On Mon, Apr 18, 2016 at 02:32:54AM +0100, Maciej W. Rozycki wrote:
> > I'd be tempted to run with the patch below to see what's the value of
> > `la_ptr' early on in processing (`entInt' code in entry.S looks sane to
> > me, doesn't
On Sun, Apr 17, 2016 at 10:58:48PM -0500, Bob Tracy wrote:
> On Mon, Apr 18, 2016 at 02:32:54AM +0100, Maciej W. Rozycki wrote:
> > I'd be tempted to run with the patch below to see what's the value of
> > `la_ptr' early on in processing (`entInt' code in entry.S looks sane to
> > me, doesn't
On Mon, Apr 18, 2016 at 02:32:54AM +0100, Maciej W. Rozycki wrote:
> I'd be tempted to run with the patch below to see what's the value of
> `la_ptr' early on in processing (`entInt' code in entry.S looks sane to
> me, doesn't touch a2). NB a rebuild doesn't have to be costly if you only
>
On Mon, Apr 18, 2016 at 02:32:54AM +0100, Maciej W. Rozycki wrote:
> I'd be tempted to run with the patch below to see what's the value of
> `la_ptr' early on in processing (`entInt' code in entry.S looks sane to
> me, doesn't touch a2). NB a rebuild doesn't have to be costly if you only
>
On Sun, 17 Apr 2016, Bob Tracy wrote:
> While a "machine check" is normally indicative of an underlying hardware
> issue, the fact this is a one-time-per-boot issue has me thinking
> otherwise. I suspect a code path being traversed prior to the Oops that
> gets bypassed afterward. As previously
On Sun, 17 Apr 2016, Bob Tracy wrote:
> While a "machine check" is normally indicative of an underlying hardware
> issue, the fact this is a one-time-per-boot issue has me thinking
> otherwise. I suspect a code path being traversed prior to the Oops that
> gets bypassed afterward. As previously
Apologies in advance for the "poor" quality of this bug report. No idea
how to proceed, because the issue historically has been intermittent to
non-existant for reasons unknown.
Within 24 hours of booting my Alpha (PWS 433au), I'm pretty much
guaranteed to see a "machine check" Oops which
Apologies in advance for the "poor" quality of this bug report. No idea
how to proceed, because the issue historically has been intermittent to
non-existant for reasons unknown.
Within 24 hours of booting my Alpha (PWS 433au), I'm pretty much
guaranteed to see a "machine check" Oops which
18 matches
Mail list logo
