ached, leading to the panic.
>
> In hindsight, I should've made that function not return before the
> post-synchronization. Oh well, I know better now...
>
> Reported-by: Vitezslav Samel <vitezs...@samel.cz>
Tested-by: Vitezslav Samel <vitezs...@samel.cz>
> Signed-of
ached, leading to the panic.
>
> In hindsight, I should've made that function not return before the
> post-synchronization. Oh well, I know better now...
>
> Reported-by: Vitezslav Samel
Tested-by: Vitezslav Samel
> Signed-off-by: Borislav Petkov
> Cc: Ashok Raj
> Cc
hether we do CPU hotplug or not.
>
> So make the saving unconditional so that late loading can find the
> proper patch.
>
> Reported-by: Vitezslav Samel <vitezs...@samel.cz>
Tested-by: Vitezslav Samel <vitezs...@samel.cz>
> Signed-off-by: Borislav Petkov <b...@
hether we do CPU hotplug or not.
>
> So make the saving unconditional so that late loading can find the
> proper patch.
>
> Reported-by: Vitezslav Samel
Tested-by: Vitezslav Samel
> Signed-off-by: Borislav Petkov
> Cc: Ashok Raj
> Cc: # if it has backported
> d
On Fri, Apr 20, 2018 at 11:52:20AM +0200, Borislav Petkov wrote:
> On Fri, Apr 20, 2018 at 08:20:21AM +0200, Vitezslav Samel wrote:
> > ;-) This time it works.
>
> Good. :-)
>
> > microcode: __reload_late: CPU1 waiting to exit
> > x86/CPU: CPU features have c
On Fri, Apr 20, 2018 at 11:52:20AM +0200, Borislav Petkov wrote:
> On Fri, Apr 20, 2018 at 08:20:21AM +0200, Vitezslav Samel wrote:
> > ;-) This time it works.
>
> Good. :-)
>
> > microcode: __reload_late: CPU1 waiting to exit
> > x86/CPU: CPU features have c
On Thu, Apr 19, 2018 at 06:37:34PM +0200, Borislav Petkov wrote:
> On Thu, Apr 19, 2018 at 03:46:27PM +0200, Vitezslav Samel wrote:
> >
> > microcode: __reload_late: CPU0
> > microcode: __reload_late: CPU3
> &g
On Thu, Apr 19, 2018 at 06:37:34PM +0200, Borislav Petkov wrote:
> On Thu, Apr 19, 2018 at 03:46:27PM +0200, Vitezslav Samel wrote:
> >
> > microcode: __reload_late: CPU0
> > microcode: __reload_late: CPU3
> &g
On Thu, Apr 19, 2018 at 05:32:18AM -0700, Raj, Ashok wrote:
> Thanks.. also can you remove the ret below, and send the output
> of /proc/cpuinfo before and after?
>
> On Thu, Apr 19, 2018 at 02:18:41PM +0200, Borislav Petkov wrote:
> > } else {
> > + pr_info("%s: CPU%d returning
On Thu, Apr 19, 2018 at 05:32:18AM -0700, Raj, Ashok wrote:
> Thanks.. also can you remove the ret below, and send the output
> of /proc/cpuinfo before and after?
>
> On Thu, Apr 19, 2018 at 02:18:41PM +0200, Borislav Petkov wrote:
> > } else {
> > + pr_info("%s: CPU%d returning
On Thu, Apr 19, 2018 at 02:18:41PM +0200, Borislav Petkov wrote:
> On Thu, Apr 19, 2018 at 02:02:39PM +0200, Vitezslav Samel wrote:
> > Here it is:
>
> Thanks!
>
> > -
> > microcode: __reload_late: CPU
On Thu, Apr 19, 2018 at 02:18:41PM +0200, Borislav Petkov wrote:
> On Thu, Apr 19, 2018 at 02:02:39PM +0200, Vitezslav Samel wrote:
> > Here it is:
>
> Thanks!
>
> > -
> > microcode: __reload_late: CPU
On Thu, Apr 19, 2018 at 12:48:29PM +0200, Borislav Petkov wrote:
> On Thu, Apr 19, 2018 at 07:35:31AM +0200, Vitezslav Samel wrote:
> > > - Can you remove your builtin microcode,
> > > - rename the /lib/firmware/intel-ucode so we don't find it during late
> > > lo
On Thu, Apr 19, 2018 at 12:48:29PM +0200, Borislav Petkov wrote:
> On Thu, Apr 19, 2018 at 07:35:31AM +0200, Vitezslav Samel wrote:
> > > - Can you remove your builtin microcode,
> > > - rename the /lib/firmware/intel-ucode so we don't find it during late
> > > lo
On Wed, Apr 18, 2018 at 06:53:30AM -0700, Raj, Ashok wrote:
> On Wed, Apr 18, 2018 at 02:22:12PM +0200, Borislav Petkov wrote:
> > On Wed, Apr 18, 2018 at 02:08:40PM +0200, Vitezslav Samel wrote:
> > > I switched to firmware-in-kernel early loading and that works OK.
>
>
On Wed, Apr 18, 2018 at 06:53:30AM -0700, Raj, Ashok wrote:
> On Wed, Apr 18, 2018 at 02:22:12PM +0200, Borislav Petkov wrote:
> > On Wed, Apr 18, 2018 at 02:08:40PM +0200, Vitezslav Samel wrote:
> > > I switched to firmware-in-kernel early loading and that works OK.
>
>
On Wed, Apr 18, 2018 at 12:07:21PM +0200, Borislav Petkov wrote:
> On Wed, Apr 18, 2018 at 10:11:40AM +0200, Vitezslav Samel wrote:
> > Could be done anything to prevent this panic?
>
> Yes, for starters, is there anything preventing you from using an initrd
> and doing early
On Wed, Apr 18, 2018 at 12:07:21PM +0200, Borislav Petkov wrote:
> On Wed, Apr 18, 2018 at 10:11:40AM +0200, Vitezslav Samel wrote:
> > Could be done anything to prevent this panic?
>
> Yes, for starters, is there anything preventing you from using an initrd
> and doing early
Hi!
Starting with 4.15.17 I got panic "timeout during microcode update"
which I bisected down to commit 8e1161f94614 ("x86/microcode: Synchronize
late microcode loading") - upstream commit
a5321aec6412b20b5ad15db2d6b916c05349dbff.
The panic happens during CPU microcode update.
The
Hi!
Starting with 4.15.17 I got panic "timeout during microcode update"
which I bisected down to commit 8e1161f94614 ("x86/microcode: Synchronize
late microcode loading") - upstream commit
a5321aec6412b20b5ad15db2d6b916c05349dbff.
The panic happens during CPU microcode update.
The
Hi!
On Mon, Feb 01, 2016 at 08:38:09AM +0100, Ulrich Windl wrote:
> Hi folks!
>
> I'd wish ntp_loopfilter.c would compile without problems. The mess is
> (I had fixed it about 15 years ago (keyword "PPSkit")) that Linux uses
> ADJ_* flags to do traditional adjtime() things, as well as
Hi!
On Mon, Feb 01, 2016 at 08:38:09AM +0100, Ulrich Windl wrote:
> Hi folks!
>
> I'd wish ntp_loopfilter.c would compile without problems. The mess is
> (I had fixed it about 15 years ago (keyword "PPSkit")) that Linux uses
> ADJ_* flags to do traditional adjtime() things, as well as
Hi!
Just tried to compile 2.6.11-rc1, but it fails with unresolved symbols
"bitreverse" etc. Found out that TUN driver needs CRC32 which I haven't
compiled in.
Following patch fixes this. Please, consider applying.
Cheers,
Vita
diff -urN
Hi!
Just tried to compile 2.6.11-rc1, but it fails with unresolved symbols
bitreverse etc. Found out that TUN driver needs CRC32 which I haven't
compiled in.
Following patch fixes this. Please, consider applying.
Cheers,
Vita
diff -urN
Hi!
When I booted freshly compiled linux-2.4.3 on my SMP machine, during some
compilling (make -j2 in gtk+ sources) the machine reboots. There were some
other processes running: trplayer (command line realaudio player), some
bashes and midnight-commanders. XFree86 wasn't running.
Hi!
When I booted freshly compiled linux-2.4.3 on my SMP machine, during some
compilling (make -j2 in gtk+ sources) the machine reboots. There were some
other processes running: trplayer (command line realaudio player), some
bashes and midnight-commanders. XFree86 wasn't running.
Hi!
> I've just tried to compile hdparm v3.9 with a vanilla 2.4.1 tree.
> Gcc complained about serveral parse errors in /usr/include/linux/string.h.
> Compiling with an >=ac6 release works fine.
> Why isn't the little string.h fix not included in 2.4.1?
>
> Regards, Gregor
Hi!
I've just tried to compile hdparm v3.9 with a vanilla 2.4.1 tree.
Gcc complained about serveral parse errors in /usr/include/linux/string.h.
Compiling with an =ac6 release works fine.
Why isn't the little string.h fix not included in 2.4.1?
Regards, Gregor
Consider
ro r128
.config or other info available
Vitezslav Samel
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
available
Vitezslav Samel
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
30 matches
Mail list logo
