search for: 3.2a

List moderator: feel free to delete my previous large message with attachments that's in the moderation queue...it's now obsolete anyway. I have found a fix/workaround for my reboot issues with Xen 4.6.3-12 + Kernel 4.9.13: Once I finally got serial output all the way through the boot process (xen+dom0) I discovered the stack trace: [Firmware Bug]: CPU7: APIC id mismatch. Firmware: 0

Sad to say that I already tested 4.9.20-26 from your repo yesterday...it does look a little cleaner before it dies, but still dies. I have not tested it with the vcpu=4 wokaround, but I can tonight if you would like. Relevant bits below: Loading Xen 4.6.3-12.el7 ... Loading Linux 4.9.20-26.el7.x86_64 ... Loading initial ramdisk ... [ 0.000000] Linux version 4.9.20-26.el7.x86_64 (mockbuild@)

There was a note that the non-Xen kernel at the same kernel version did indeed boot: "CentOS-6 4.9.20-26 kernel exhibits the same constant kernel-start-then-reboot issue when booting under the "CentOS Linux, with Xen hypervisor" grub2 menu option. However, it *does* properly boot under the "CentOS Linux (4.9.20-25.el7.x86_64) 7 (Core)" grub2 menu option!" Trying to

Pawel, We all understand that you're pretty new to release process, etc., but I think you should understand the implications of your actions. You just created a lot of harm for really huge pile of users - the ones who downloads the tarball via some automated build system and rely on the known good checksum. This includes, but not limited to to the users of FreeBSD, Gentoo, etc. Even worse,

Apologies: I installed the newer -26 kernel and had not rebooted into it. The grub2 menu item should have been "CentOS Linux (4.9.20-25.el7.x86_64) 7 (Core)". I am currently restarting that remote affected system (unmodified grub2 entry first). Thanks PJ On Tue, Apr 18, 2017 at 8:39 AM, PJ Welsh <pjwelsh at gmail.com> wrote: > Just to note, the same pattern happens on C7: >

On 04/14/2017 03:26 PM, Anderson, Dave wrote: > Sad to say that I already tested 4.9.20-26 from your repo yesterday...it does look a little cleaner before it dies, but still dies. I have not tested it with the vcpu=4 wokaround, but I can tonight if you would like. Relevant bits below: > > Loading Xen 4.6.3-12.el7 ... > Loading Linux 4.9.20-26.el7.x86_64 ... > Loading initial

So, strangely, I have two _identical_ dualproc xeon mobos (same bios/ipmi versions, they even share an enclosure, one is right side, other is left), each with different cpu/memory: Using 4.9.13 with vcpu limited to 4, early in the boot process, the one that _was_ booting before setting the xen vcpu args says: "[ 7.060720] smpboot: Max logical packages: 2", and the other one says

Just to note, the same pattern happens on C7: "CentOS Linux, with Xen hypervisor" = reboot "CentOS Linux (4.9.20-26.el7.x86_64) 7 (Core)" = boot [root at XXX ~]# uname -a Linux XXX 4.9.20-25.el7.x86_64 #1 SMP Fri Mar 31 08:53:28 CDT 2017 x86_64 x86_64 x86_64 On Tue, Apr 18, 2017 at 8:36 AM, PJ Welsh <pjwelsh at gmail.com> wrote: > There was a note that the non-Xen

Anton, > Pawel, > > We all understand that you're pretty new to release process, etc., but > I think you should understand the implications of your actions. > > You just created a lot of harm for really huge pile of users - the > ones who downloads the tarball via some automated build system and > rely on the known good checksum. This includes, but not limited to to

Here is something interesting... I went through the BIOS options and found that one R710 that *is* functioning only differed in that "Logical Processor"/Hyperthreading was *enabled* while the one that is *not* functioning had HT *disabled*. Enabled Logical Processor and the system starts without issue! I've rebooted 3 times now without issue. Dell R710 BIOS version 6.4.0 2x Intel(R)

rsync version: 2.6.8 on both source and destination linux kernel: 2.4.29-3.2a on both command: rsync --whole-file --temp-dir /tmp file.txt destination.machine:/path/to/file/file.txt error: rsync: stat "/path/to/file/file.txt" failed: No such file or directory (2) rsync error: some files could not be transferred (code 23) at main.c(702) rsync is attempting to stat() the transferred

Good news/bad news testing the new kernel on CentOS7 with my now notoriously finicky machines: Good news: 4.9.23-26.el7 (grabbed today via yum update) isn't any worse than 4.9.13-22 was on my xen hosts (as far as I can tell so far at least) Bad news: It isn't any better than 4.9.13 was for me either, if I don't set vcpu limit in the grub/xen config, it still panics like so: [

On 04/19/2017 12:18 PM, PJ Welsh wrote: > > On Wed, Apr 19, 2017 at 5:40 AM, Johnny Hughes <johnny at centos.org > <mailto:johnny at centos.org>> wrote: > > On 04/18/2017 12:39 PM, PJ Welsh wrote: > > Here is something interesting... I went through the BIOS options and > > found that one R710 that *is* functioning only differed in that

Dave, Take a look at this kernel as it is the one I think we are going to release (or a slightly newer 4.9.2x from kernel.org LTS). This version has some newer settings that are more redhat/fedora/centos base kernel like WRT what is a module and what is built into the kernel, etc. https://people.centos.org/hughesjr/4.9.x/ Thanks, Johnny Hughes On 04/14/2017 05:16 AM, Anderson, Dave wrote: >

Hummmm, seems there are still stability issues on the "4.9.2-26.el7.x86_64", recently hear many issue related to Supermicro board! :-( Peace!!! On Fri, Apr 21, 2017 at 9:40 AM, Anderson, Dave <daveanderson at wsu.edu> wrote: > Good news/bad news testing the new kernel on CentOS7 with my now > notoriously finicky machines: > > Good news: 4.9.23-26.el7 (grabbed today

On 1/11/2013 2:51 PM, Justin Holewinski wrote: > On Fri, Jan 11, 2013 at 3:47 PM, Pawel Wodnicki <root at 32bitmicro.com> wrote: > >> On 1/11/2013 2:40 PM, Brooks Davis wrote: >>> On Fri, Jan 11, 2013 at 09:33:17PM +0100, Benjamin Kramer wrote: >>>> >>>> On 11.01.2013, at 21:31, Justin Holewinski >>>> <justin.holewinski at

On Fri, Jan 11, 2013 at 3:47 PM, Pawel Wodnicki <root at 32bitmicro.com> wrote: > On 1/11/2013 2:40 PM, Brooks Davis wrote: > > On Fri, Jan 11, 2013 at 09:33:17PM +0100, Benjamin Kramer wrote: > >> > >> On 11.01.2013, at 21:31, Justin Holewinski > >> <justin.holewinski at gmail.com> wrote: > >> > >>> On Fri, Jan 11, 2013 at 3:26

Pawel, First, all your help with the 3.2 release is greatly appreciated. I do not think anyone is saying otherwise. I apologize for the lack of documentation regarding this issue. I do ask that you consult with previous release manager (myself or Bill) to determine what the best course of action is. There is a lot of room to improve our release process, but its a collaborative effort. You are

Hi, All: I encountered problems running "pdflatex wrapper.tex", as suggested on "www.r-project.org" -> Newsletter -> (near the bottom of the page). After 220 lines of seemingly successful processing, I got an error copied below. I hit <enter> a few times, and the "pdflatex" finished, apparently successfully. Comments? Thanks,