[Bug 1647793] Re: Yakkety: arm64: CONFIG_ARM64_ERRATUM_845719 isn't enabled

** Tags removed: verification-needed-yakkety ** Tags added: verification-done-yakkety -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1647793 Title: Yakkety: arm64: CONFIG_ARM64_ERRATUM_845719 isn't

[Bug 1647793] Re: Yakkety: arm64: CONFIG_ARM64_ERRATUM_845719 isn't enabled

** Description changed: - - CONFIG_ARM64_ERRATUM_845719 should be enabled in Yakkety, but it isn't. + CONFIG_ARM64_ERRATUM_845719 should have been enabled in Yakkety, but + it isn't actually. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to

[Bug 1647793] [NEW] Yakkety: arm64: CONFIG_ARM64_ERRATUM_845719 isn't enabled

Public bug reported: CONFIG_ARM64_ERRATUM_845719 should be enabled in Yakkety, but it isn't. ** Affects: linux (Ubuntu) Importance: Undecided Status: Incomplete -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu.

Re: [Bug 1638700] Re: hio: SSD data corruption under stress test

On Thu, Nov 3, 2016 at 5:42 AM, Kamal Mostafa <ka...@canonical.com> wrote: > Ming Lei comment #2 says you're the author of this patch to the hio > driver: > > +#if (LINUX_VERSION_CODE >= KERNEL_VERSION(4,3,0)) > + blk_queue_split(q, , q->bio_split); > +#en

[Bug 1592074] Re: ubuntu-core is change in progress after interrupt "snap install"

With Shuduo's help, looks the only solution for this issue is to run reset-state by the tools in the following link: https://github.com/zyga/devtools/blob/master/reset-state -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu.

[Bug 1612020] Re: arm64: virt machine: no virtio devices emulated

Just found that it is caused by missing one '\' ** Changed in: qemu (Ubuntu) Status: New => Invalid -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1612020 Title: arm64: virt machine: no

[Bug 1612020] [NEW] arm64: virt machine: no virtio devices emulated

Public bug reported: 1, script QEMU=qemu-system-aarch64 $QEMU \ -enable-kvm \ -m 4096 \ -smp 4 \ -cpu host \ -M virt,gic-version=host \ -vga none \ -nographic \ -kernel $1 \ -initrd $2 \ -append

[Bug 1584602] Re: internal compiler error: in fixup_reorder_chain, , at cfgrtl.c:3336

** Changed in: gcc-4.8 (Ubuntu) Status: New => Confirmed -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1584602 Title: internal compiler error: in fixup_reorder_chain,, at cfgrtl.c:3336 To

[Bug 1584602] Re: internal compiler error: in fixup_reorder_chain, , at cfgrtl.c:3336

Please see the gcc-4.8 crash log on trusty/arm64, which includes the gcc flag and PreprocessedSource. ** Attachment added: "gcc-4.8 crash log on trusty/arm64"

[Bug 1584602] Re: internal compiler error: in fixup_reorder_chain, , at cfgrtl.c:3336

Follos the steps to reproduce the issue: 1, find a arm64 machine or VM, which is installed trusty 2, prepare for building samba: sudo apt-get -y install dpkg-dev fakeroot sudo apt-get -y build-dep samba 3, download the following samba source: wget

[Bug 1584602] [NEW] internal compiler error: in fixup_reorder_chain, , at cfgrtl.c:3336

Public bug reported: When building samba package on trusty/arm64 with gcc-4.8, the following build crash can be observed, and it can be triggered with gcc-4.7 too. 01:07:10 runner /usr/bin/gcc -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -fPIC -D_REENTRANT

Re: [Bug 1574814] Re: ThunderX: soft lockup in cursor_timer_handler() Edit

On Tue, May 17, 2016 at 12:12 PM, Ming Lei <ming@canonical.com> wrote: > On Mon, May 16, 2016 at 5:25 PM, Ming Lei <ming@canonical.com> wrote: >> On Fri, May 13, 2016 at 7:22 AM, dann frazier >> <dann.fraz...@canonical.com> wrote: >>> I

Re: [Bug 1574814] Re: ThunderX: soft lockup in cursor_timer_handler() Edit

On Mon, May 16, 2016 at 5:25 PM, Ming Lei <ming@canonical.com> wrote: > On Fri, May 13, 2016 at 7:22 AM, dann frazier > <dann.fraz...@canonical.com> wrote: >> I used ftrace to do some duration measuring of the timer function >> fb_flashcursor(). I noticed several

Re: [Bug 1574814] Re: ThunderX: soft lockup in cursor_timer_handler() Edit

On Fri, May 13, 2016 at 7:22 AM, dann frazier wrote: > I used ftrace to do some duration measuring of the timer function > fb_flashcursor(). I noticed several places where this timer takes around > 98 ms to complete. This time seems to be due to multiple calls to >

Re: [Bug 1574814] Re: ThunderX: soft lockup in cursor_timer_handler() Edit

On Tue, May 3, 2016 at 1:14 PM, Radha Mohan Chintakuntla wrote: > Ming, > The "-I" option of tcpdump is monitoring mode typically applicable only to > wifi interfaces. So even if you run it on Thunder's NIC interfaces it will > return saying that this is not supported.

Re: [Bug 1574814] Re: ThunderX: soft lockup in cursor_timer_handler() Edit

On Tue, May 3, 2016 at 10:35 AM, dann frazier <dann.fraz...@canonical.com> wrote: > On Fri, Apr 29, 2016 at 2:06 AM, Ming Lei <1574...@bugs.launchpad.net> wrote: >> It can be triggered 100% by running 'tcpdump -I ethX'. > > Thanks Ming. I let that run for a few hours, bu

Re: [Bug 1574814] Re: ThunderX: soft lockup in cursor_timer_handler() Edit

It can be triggered 100% by running 'tcpdump -I ethX'. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1574814 Title: ThunderX: soft lockup in cursor_timer_handler() Edit To manage notifications

Re: [Bug 1575506] Re: Xenial: ARM64: Unable to handle kernel NULL pointer dereference at virtual address 00000038

On Thu, Apr 28, 2016 at 9:55 PM, Tim Gardner wrote: > Ming - please try the kernel at > http://people.canonical.com/~rtg/lp1575506/ - I've updated AUFS to the > latest stable branch. Source at git://kernel.ubuntu.com/rtg/ubuntu- > xenial.git aufs Looks no difference by

Re: [Bug 1575506] Re: Xenial: ARM64: Unable to handle kernel NULL pointer dereference at virtual address 00000038

On Wed, Apr 27, 2016 at 4:31 PM, Ming Lei <1575...@bugs.launchpad.net> wrote: > Upstream 4.6-rc6 hasn't this problem > > -- > You received this bug notification because you are subscribed to the bug > report. > https://bugs.launchpad.net/bugs/1575506 > > Title: >

[Bug 1575506] Re: Xenial: ARM64: Unable to handle kernel NULL pointer dereference at virtual address 00000038

Upstream 4.6-rc6 hasn't this problem -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1575506 Title: Xenial: ARM64: Unable to handle kernel NULL pointer dereference at virtual address 0038 To

[Bug 1575506] Re: Xenial: ARM64: Unable to handle kernel NULL pointer dereference at virtual address 00000038

** Changed in: linux (Ubuntu) Status: Incomplete => Confirmed -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1575506 Title: Xenial: ARM64: Unable to handle kernel NULL pointer dereference at

[Bug 1575506] Re: Xenial: ARM64: Unable to handle kernel NULL pointer dereference at virtual address 00000038

The issue can be reproduced on '4.4.0-22-generic #38' too -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1575506 Title: Xenial: ARM64: Unable to handle kernel NULL pointer dereference at virtual

[Bug 1575506] [NEW] Xenial: ARM64: Unable to handle kernel NULL pointer dereference at virtual address 00000038

Public bug reported: When running 'stress-ng --all 64 -t 800 -v' on Xenial/ARM64, the following kernel oops is triggered. [ 93.309158] Unable to handle kernel NULL pointer dereference at virtual address 0038 [ 93.309160] pgd = 8007a5914000 [ 93.309163] [0038]

[Bug 1564653] Re: trusty: arm64: no grub.efi generated by d-i

** Branch linked: lp:~tom-leiming/debian-installer/trusty-for- generating-netboot-tarball -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1564653 Title: trusty: arm64: no grub.efi generated by d-i

[Bug 1564653] [NEW] trusty: arm64: no grub.efi generated by d-i

Public bug reported: [Impact] - no grub.efi generated by d-i on arm64, and arm64 server have been switching to uefi/grub already, so arm64 server can't be installed via trusty d-i [Test Case] - no grub.efi generated from the following link:

[Bug 1546439] Re: ISST:LTE: Regression: roselp2 Oops in kernel during setup io

Hi, The attached patch should fix one related issue, could anyone test it? Thanks, ** Patch added: "fix crash" https://bugs.launchpad.net/ubuntu/+bug/1546439/+attachment/4615924/+files/0001-block-partition-initialize-percpuref-before-sending-.patch -- You received this bug notification

[Bug 1553934] Re: xenial: 'msi_irqs' directory isn't show under pci device capable of MSI

Finally figured out that the 'msi_irqs' directory can't show once the tg3 interface is down. When I make it up manually, the directory can appear. So looks an invalide report. ** Changed in: linux (Ubuntu Xenial) Status: Incomplete => Invalid -- You received this bug notification

[Bug 1553934] [NEW] xenial: 'msi_irqs' directory isn't show under pci device capable of MSI

Public bug reported: When I test xenial kernel about PCI function on one ARM64 box, I see the PCI device does work, and this device is shown with MSI capability. But the msi_irqs directory can't be found under: ./platform/soc/1f2b.pcie/pci:00/:00:00.0/:01:00.0/ When I trace

Re: [Bug 1547718] Re: 4.4.0-7.22 no longer boots on arm64

On Mon, Feb 22, 2016 at 4:37 PM, Ming Lei <ming@canonical.com> wrote: > Looks it is enough to just revert > 'e96e20134729121689a0089537c6ed(module: clean up RO/NX handling)' > for fixing the issue. > > But the interesting thing is that there isn't the problem in upst

[Bug 1548207] Re: xenial 4.4.0-7-generic: kernel oops during load module

*** This bug is a duplicate of bug 1547718 *** https://bugs.launchpad.net/bugs/1547718 ** This bug has been marked a duplicate of bug 1547718 4.4.0-7.22 no longer boots on arm64 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu.

Re: [Bug 1547718] Re: 4.4.0-7.22 no longer boots on arm64

Looks it is enough to just revert 'e96e20134729121689a0089537c6ed(module: clean up RO/NX handling)' for fixing the issue. But the interesting thing is that there isn't the problem in upstream kernel 4.5-rc5, and the commit(module: clean up RO/NX handling) isn't reverted in upstream yet. So looks

[Bug 1548207] Re: xenial 4.4.0-7-generic: kernel oops during load module

When this commit c8d73ebfe19daac81b7cb5c8d1dd(module: clean up RO/NX handling) is reverted, the issue disappeares. So the above commit should be the cause. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu.

[Bug 1548207] Re: xenial 4.4.0-7-generic: kernel oops during load module

** Changed in: linux (Ubuntu) Status: Incomplete => Confirmed -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1548207 Title: xenial 4.4.0-7-generic: kernel oops during load module To manage

[Bug 1548207] [NEW] xenial 4.4.0-7-generic: kernel oops during load module

Public bug reported: EFI stub: Booting Linux Kernel... EFI stub: Using DTB from configuration table EFI stub: Exiting boot services and installing virtual address map... L3c Cache: 8MB [0.587986] kernel BUG at /build/linux-RKt9qy/linux-4.4.0/mm/memory.c:1887! [0.594918] Internal error:

[Bug 1533009] Re: arm64: "unsupported RELA relocation"

Dann, In my test, the issue is nothing to do with kernel, and only related with modules built by the affected gcc 5.3. For example, the kernel running is built from gcc 5.2, then I rebuilt some modules by gcc 5.3, the issue comes when I try to load the just built module. BTW, '-mcmodel=large'

Re: [Bug 1533009] Re: arm64: "unsupported RELA relocation"

On Fri, Jan 15, 2016 at 6:29 PM, Matthias Klose wrote: > please attach the preprocessed source and the exact command line options > to build the libahci module. Not only libahci modules, all built modules has the problem. Follows the command line for building libahci.ko: 1)

[Bug 1533009] Re: arm64: "unsupported RELA relocation"

Looks the latest proposed gcc-5.3.1-6ubuntu1 has the problem too. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1533009 Title: arm64: "unsupported RELA relocation" To manage notifications about

Re: [Bug 1533009] Re: arm64: "unsupported RELA relocation"

Hi, Wrt. the build environment, the built kernel/modules can work fine just after switching gcc from gcc-5 to gcc-4.9 and keep other things not changed in Xenial. So I am sure the issue is in Xenial gcc-5, and the bug should be introduced after 5.2.1-22ubuntu2 because Wily gcc-5 hasn't this

Re: [Bug 1533009] Re: arm64: "unsupported RELA relocation"

-5ubuntu2) On Wed, Jan 13, 2016 at 9:11 AM, Ming Lei <ming@canonical.com> wrote: > When I built 4.3.0-7-generic on arm64(mustang) Wily with the following steps, > > fakeroot debian/rules clean > fakeroot debian/rules binary-generic > > by this compiler:

Re: [Bug 1533009] Re: arm64: "unsupported RELA relocation"

When I built 4.3.0-7-generic on arm64(mustang) Wily with the following steps, fakeroot debian/rules clean fakeroot debian/rules binary-generic by this compiler: ubuntu@ubuntu:~$ gcc -v Using built-in specs. COLLECT_GCC=gcc

Re: [Bug 1521612] Re: Continued TFTP timeouts when PXE booting via grub

Hi Dann, On Mon, Dec 21, 2015 at 11:59 PM, dann frazier wrote: > @Ming can you clarify which build(s) you tested (trusty, vivid, and/or > wily)? It isn't clear to me if "three grub changes" means you tested all All three have been tested on both two kinds of arm64.

[Bug 1521612] Re: Continued TFTP timeouts when PXE booting via grub

The three grub changes have been tested fine on both APM arm64 board and HP m400, looks all works fine. ** Tags removed: verification-needed ** Tags added: verification-done -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu.

[Bug 1527047] [NEW] arm64: wily: hanging during reboot

Public bug reported: Inside VM wily kernel which is installed via wily d-i installer, reboot hangs, see the following message: [ 40.294727] reboot: Restarting system And never return to UEFI UI. The issue can be observed too in d-i installing too. ** Affects: edk2 (Ubuntu)

[Bug 1521612] Re: Continued TFTP timeouts when PXE booting via grub

Now grub2 for Xenial just works fine on mcdivitt in case of netboot, especially during loading kernel image via tftp. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1521612 Title: Continued TFTP

[Bug 1508893] Re: TFTP timeout when booting from grub that was PXE loaded

On HP ProLiant m400 Server, when booting via UEFI, TFTP still may timeout when loading kernel by netboot. Looks only the commit 49426e9fd2( efinet: open Simple Network Protocol exclusively) isn't enough, and the following three commits are required too for grub working well on HP m400 ARM64

[Bug 1507653] Re: Wily kernel crashed when running ifconfig eth0 up/done test

Looks there isn't crash during the ifconfig up/down test any more after applying the patch in the following link, but ifconfig still may hang during the test: https://www.mail-archive.com/netdev@vger.kernel.org/msg88060.html See test log in the attachment. ** Attachment added: "ifconfig hangs

[Bug 1517582] Re: flash-kernel causes postinsts to fail when it happens to be installed on an unsupported system

The following should fix the issue of flash-kernel, could anyone give a test in MAAS? diff --git a/functions b/functions index 97bbdd9..e753054 100644 --- a/functions +++ b/functions @@ -429,6 +429,10 @@ fi kfile_suffix=$(get_kfile_suffix "$kfile") if ! check_supported "$machine"; then +

Re: [Bug 1508893] Re: TFTP timeout on ARM64 hw when booting from grub that was PXE loaded

On Tue, Nov 3, 2015 at 11:48 PM, Newell Jensen wrote: > Ming, > > Trying to use your bootnetaa64.efi file from > http://kernel.ubuntu.com/~ming/bugs/1508893/bootnetaa64.efi > > I am not able to test this because I cannot PXE boot: > > TianoCore 2.0.0 UEFI 2.4.0 Sep 1

[Bug 1512193] Re: arm64: report 'error: failure writing sector 0x19df788 to `hd0'' after a fresh install

1) write environment failure grub> save_env 123 error: failure writing sector 0xe153800 to `hd0'. 2) LBA of grub environment variable file ubuntu@ubuntu:~$ sudo hdparm --fibmap /boot/grub/grubenv [sudo] password for ubuntu: /boot/grub/grubenv: filesystem blocksize 4096, begins at

[Bug 1508087] Re: Unhandled UDP error during manual enlistment of xgene-2

This one should be same with LP1508738, and can anyone to try to use the customerised grub to see if it can fix the issue? http://kernel.ubuntu.com/~ming/bugs/1508893/bootnetaa64.efi -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to

[Bug 1508087] Re: Unhandled UDP error during manual enlistment of xgene-2

This one should be same with LP1508738, and can anyone to try to use the customerised grub to see if it can fix the issue? http://kernel.ubuntu.com/~ming/bugs/1508893/bootnetaa64.efi -- You received this bug notification because you are a member of Ubuntu Server Team, which is

[Bug 1512193] Re: arm64: report 'error: failure writing sector 0x19df788 to `hd0'' after a fresh install

That can be reproduced by running 'save_env' command in grub shell: grub> save_env 123 error: failure writing sector 0xe14d800 to `hd0'. Thanks, -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu.

[Bug 1512193] Re: arm64: report 'error: failure writing sector 0x19df788 to `hd0'' after a fresh install

The issue can be work around by commenting 'recordfail' in the boot entry of 'Ubuntu'. And it can be reproduced on upstrem grub too. Looks the sectors wroten to hd0 is out of range in the partition, and it should be bug in grub. -- You received this bug notification because you are a member

[Bug 1512193] [NEW] arm64: report 'error: failure writing sector 0x19df788 to `hd0'' after a fresh install

Public bug reported: 1, grub boot log TianoCore 2.0.0 UEFI 2.4.0 Sep 1 2015 12:48:07 CPU: APM ARM 64-bit Strega Rev A2 2400MHz PCP 2400MHz 32 KB ICACHE, 32 KB DCACHE SOC 2000MHz IOBAXI 400MHz AXI 250MHz AHB 200MHz GFC 66MHz Board: X-Gene Merlin Board Slimpro FW: Ver: 3.4

Re: [Bug 1440536] Re: Oops __d_lookup+0x88/0x194

On Tue, Oct 27, 2015 at 11:03 PM, Fathi Boudra <fathi.bou...@linaro.org> wrote: > Ming Lei, > > yes, on Mustang. We're using U-Boot. OK, we found the issue is triggered during booting, and finally APM's fix on firmware can make the issue disappeared, but it isn't released yet

[Bug 1508893] Re: TFTP timeout on ARM64 hw when booting from grub that was PXE loaded

> A build from upstream git shows this problem as well. Looks it is thought as one AMI firmware's issue, so the patch should be merged to grub, otherwise grub can't run on APM's UEFI firmware. Thanks, -- You received this bug notification because you are a member of Ubuntu Bugs, which is

[Bug 1509221] Re: wily: arm64: warning in numa_init() during booting

The issue can be fixed by disabling 'ARM64_DT_NUMA', so it is definitley caused by the following commit: commit ecbd5d083f9d668436cd0cc18f06094233c1c336 Author: Ganapatrao Kulkarni Date: Fri Sep 18 15:44:40 2015 -0600 UBUNTU: SAUCE: arm64, numa, dt: adding

[Bug 1509221] Re: wily: arm64: warning in numa_init() during booting

** Changed in: linux (Ubuntu) Status: Incomplete => Confirmed -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1509221 Title: wily: arm64: warning in numa_init() during booting To manage

[Bug 1440536] Re: Oops __d_lookup+0x88/0x194

Riku, Did you reproduce the issue with UEFI booting or U-boot booting? And it is on Mustang? Thanks, -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1440536 Title: Oops __d_lookup+0x88/0x194 To

[Bug 1509221] [NEW] wily: arm64: warning in numa_init() during booting

Public bug reported: [0.00] [ cut here ] [0.00] WARNING: CPU: 0 PID: 0 at /build/linux-vmnY7Y/linux-4.2.0/arch/arm64/mm/numa.c:449 numa_init+0x90/0x398() [0.00] Modules linked in: [0.00] CPU: 0 PID: 0 Comm: swapper Not tainted

[Bug 1508893] Re: TFTP timeout on ARM64 hw when booting from grub that was PXE loaded

Dann, I just run a quick test on cvm0 and looks the grub.efi built from wily plug the patch just works fine, and attached my build commandline. ./autogen.sh ./configure --host=x86_64-linux-gnu --target=aarch64-linux-gnu --build=x86_64-linux-gnu --with-platform=efi

[Bug 1509221] Re: wily: arm64: warning in numa_init() during booting

** Changed in: linux (Ubuntu) Status: Incomplete => New -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1509221 Title: wily: arm64: warning in numa_init() during booting To manage

[Bug 1508893] Re: TFTP timeout on ARM64 hw when booting from grub that was PXE loaded

Today I have applied this patch(efinet: open Simple Network Protocol exclusively) against grub on wily, looks it does fix the issue on mustang/merlin. Dann, could you build one upstrem grub and test it on thunder to see if there is the synchronous exception issue? -- You received this bug

[Bug 1507653] [NEW] Wily kernel crashed when running ifconfig eth0 up/done test

Public bug reported: 1, Wily kernel crashed with attached log on APM mustang(ARM64) 2, how to reproduce 2.1 start iperf first - run 'iperf -s' on mustang board - run 'iperf -c IP_OF_MUSTANG' on another machine, and make the client point to mustang 2.2 run the following 'ifconfig eth0 up/down'

[Bug 1495761] Re: stress-ng --numa 1 causes translation fault on itself on ARM64

Looks there are other translation fault issue on arm64, and the following fault is triggered when I run a stress-ng built from your tree just before, and kernel is v4.2. ubuntu@ubuntu:~/stress-ng$ ./stress-ng --all 8 -t 10 [90392.210285] stress-ng[2513]: unhandled level 3 translation fault (11)

Re: [Bug 1469859] Re: HP ProLiant m400: NULL pointer dereference PC is at ctx_sched_in+0xdc/0x30c

On Tue, Sep 1, 2015 at 11:27 PM, dann frazier wrote: > Sorry, I missed the request for more information. I retested yesterday, > and it is still possible to crash the system with the above stress-ng > command 4.2.0-6.6 from ppa:canonical-kernel-team/ppa. In fact, it

[Bug 1495761] [NEW] stress-ng --numa 1 causes translation fault on itself on ARM64

Public bug reported: ubuntu@ubuntu:~/stress-ng$ stress-ng --numa 1 stress-ng: info: [3191] defaulting to a 86400 second run per st[ 1722.813407] stress-ng-numa[3192]: unhandled level 2 translation fault (11) at 0x, esr 0x9206 ressor stress-ng: info: [3191] dispatching hogs: 1 numa

[Bug 1473818] Re: vivid kernel can't boot on APM xgene2 Soc

** Tags removed: verification-needed-vivid ** Tags added: verification-done-vivid -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1473818 Title: vivid kernel can't boot on APM xgene2 Soc To manage

[Bug 1477431] Re: vivid: ethernet can't work on xgene2 when booting from acpi

vivid kernel can't support ACPI on arm64, so marked it as invalid ** Changed in: linux (Ubuntu) Status: Triaged = Incomplete ** Changed in: linux (Ubuntu) Status: Incomplete = Invalid -- You received this bug notification because you are a member of Ubuntu Bugs, which is

[Bug 1477431] [NEW] vivid: ethernet can't work on xgene2 when booting from acpi

Public bug reported: Turns out the following commits are required: c2d33bd drivers: net: xgene: Check for IS_ERR rather than NULL for clock. 822e34a drivers: net: xgene: Add ACPI support for SGMII0 and XFI1 interface of 2nd H/W version 2c7be0a drivers: net: xgene: Implement the backward

[Bug 1476512] [NEW] wily: arm64: irqbalance works at oneshot mode at default

Public bug reported: From kernel v4.0, CPU cache topo information is added into sysfs for ARM64, in which all cores often share one L3 cache such as APM xgene, so cache domain count can be one, and irqbalance will work at oneshot mode. With the following upstream patch, irqbalance can work

[Bug 1476512] [NEW] wily: arm64: irqbalance works at oneshot mode at default

Public bug reported: From kernel v4.0, CPU cache topo information is added into sysfs for ARM64, in which all cores often share one L3 cache such as APM xgene, so cache domain count can be one, and irqbalance will work at oneshot mode. With the following upstream patch, irqbalance can work

[Bug 1474171] Re: Wily boot failure on HP proliant m400 server

** Changed in: linux (Ubuntu) Status: Incomplete = Confirmed -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1474171 Title: Wily boot failure on HP proliant m400 server To manage

[Bug 1474171] Re: Wily boot failure on HP proliant m400 server

Finally, I figured out it is the following patchset which can fix the issue. That is said the issue disappears if these patches are applied to v4.0 kernel: 9a6d729 of: Calculate device DMA masks based on DT dma-range size 22b3c18 arm: dma-mapping: limit IOMMU mapping size de335bb4 PCI: Update

[Bug 1469214] Re: HP ProLiant m400 Server crashes with unhandled level 3 translation fault

Dann, I have figured out patches for fixing wily kernel, see following link: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1474171/comments/4 so you can reproduce the issue on a totally clean wily distribution, :-) -- You received this bug notification because you are a member of

[Bug 1469214] Re: HP ProLiant m400 Server crashes with unhandled level 3 translation fault

Dann, I have figured out patches for fixing wily kernel, see following link: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1474171/comments/4 so you can reproduce the issue on a totally clean wily distribution, :-) -- You received this bug notification because you are a member of

[Bug 1474171] Re: Wily boot failure on HP proliant m400 server

From upstrem kernel, v4.0 is same with wily(4.0 kernel), but there isn't the issue in v4.1 and v4.2 kernel. And it can't be found by reverse 'git bisect', because some pci change can cause no mellanox nic found in pci bus. -- You received this bug notification because you are a member of

[Bug 1474171] Re: Wily boot failure on HP proliant m400 server

From upstrem kernel, v4.0 is same with wily(4.0 kernel), but there isn't the issue in v4.1 and v4.2 kernel. And it can't be found by reverse 'git bisect', because some pci change can cause no mellanox nic found in pci bus. -- You received this bug notification because you are a member of

[Bug 1474171] Re: Wily boot failure on HP proliant m400 server

** Package changed: irqbalance (Ubuntu) = linux (Ubuntu) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1474171 Title: Wily boot failure on HP proliant m400 server To manage notifications about

[Bug 1474171] Re: Wily boot failure on HP proliant m400 server

** Package changed: irqbalance (Ubuntu) = linux (Ubuntu) -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to irqbalance in Ubuntu. https://bugs.launchpad.net/bugs/1474171 Title: Wily boot failure on HP proliant m400 server To manage

[Bug 1469214] Re: HP ProLiant m400 Server crashes with unhandled level 3 translation fault

I prepared a wily package w/ the proposed upstream backport for testing: lp:~dannf/ubuntu/wily/irqbalance/lp1469214 Unfortunately, I'm still seeing irqbalance crash even with this backport: I guess you still test irqbalance on c33, looks that upgrade from trusty isn't good, and I can see

[Bug 1469214] Re: HP ProLiant m400 Server crashes with unhandled level 3 translation fault

I prepared a wily package w/ the proposed upstream backport for testing: lp:~dannf/ubuntu/wily/irqbalance/lp1469214 Unfortunately, I'm still seeing irqbalance crash even with this backport: I guess you still test irqbalance on c33, looks that upgrade from trusty isn't good, and I can see

[Bug 1469214] Re: HP ProLiant m400 Server crashes with unhandled level 3 translation fault

On Mon, Jul 13, 2015 at 9:27 AM, Ming Lei 1469...@bugs.launchpad.net wrote: Dann, Please follow the steps in #12, in which you should trigger the crash in 4 minutes. I've been running that in a loop and I'm currently on iteration #76 w/o a crash :( The issue is nothing to do with kernel

[Bug 1469214] Re: HP ProLiant m400 Server crashes with unhandled level 3 translation fault

On Mon, Jul 13, 2015 at 9:27 AM, Ming Lei 1469...@bugs.launchpad.net wrote: Dann, Please follow the steps in #12, in which you should trigger the crash in 4 minutes. I've been running that in a loop and I'm currently on iteration #76 w/o a crash :( The issue is nothing to do with kernel

[Bug 1469214] Re: HP ProLiant m400 Server crashes with unhandled level 3 translation fault

BTW, looks wily kernel can't boot to shell prompt on mcdivitt. That kernel(v4.0) isn't the final kernel for wily, so do we need to pay attention to that? -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to irqbalance in Ubuntu.

[Bug 1469214] Re: HP ProLiant m400 Server crashes with unhandled level 3 translation fault

BTW, looks wily kernel can't boot to shell prompt on mcdivitt. That kernel(v4.0) isn't the final kernel for wily, so do we need to pay attention to that? -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu.

[Bug 1469214] Re: HP ProLiant m400 Server crashes with unhandled level 3 translation fault

Dann, Please follow the steps in #12, in which you should trigger the crash in 4 minutes. BTW, looks wily kernel can't boot to shell prompt on mcdivitt. Thanks, -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to irqbalance in Ubuntu.

[Bug 1469214] Re: HP ProLiant m400 Server crashes with unhandled level 3 translation fault

Dann, Please follow the steps in #12, in which you should trigger the crash in 4 minutes. BTW, looks wily kernel can't boot to shell prompt on mcdivitt. Thanks, -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu.

[Bug 1474171] [NEW] Wily boot failure on HP proliant m400 server

Public bug reported: Looks kernel crashs inside mlx4_en_xmit() of mlx ethernet driver. ** Affects: irqbalance (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu.

[Bug 1474171] Re: Wily boot failure on HP proliant m400 server

** Attachment added: dmesg during boot https://bugs.launchpad.net/ubuntu/+source/irqbalance/+bug/1474171/+attachment/4428465/+files/hp-ProLiant-m400.txt -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu.

[Bug 1474171] [NEW] Wily boot failure on HP proliant m400 server

Public bug reported: Looks kernel crashs inside mlx4_en_xmit() of mlx ethernet driver. ** Affects: irqbalance (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to irqbalance in

[Bug 1474171] Re: Wily boot failure on HP proliant m400 server

** Attachment added: dmesg during boot https://bugs.launchpad.net/ubuntu/+source/irqbalance/+bug/1474171/+attachment/4428465/+files/hp-ProLiant-m400.txt -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to irqbalance in Ubuntu.

[Bug 1473818] [NEW] vivid kernel can't boot on APM xgene2 Soc

Public bug reported: Starting kernel ... L3C: 8MB Booting Linux on physical CPU 0x0 Initializing cgroup subsys cpu Linux version 3.19.8-ckt3+ (ming@r815) (gcc version 4.8.2 20140110 (prerelease) [ibm/gcc-4_8-branch merged from gcc-4_8-branch, revision 205847] (Ubuntu/Linaro 4.8.2-13ubuntu1) )

[Bug 1458042] Re: [SRU] xgene-enet: add SGMII based 1GbE support for the second port

ubuntu@ubuntu:~$ uname -a Linux ubuntu 3.19.0-23-generic #24-Ubuntu SMP Tue Jul 7 18:58:44 UTC 2015 aarch64 aarch64 aarch64 GNU/Linux ubuntu@ubuntu:~$ sudo ethtool eth2 sudo: unable to resolve host ubuntu Settings for eth2: Supported ports: [ MII ] Supported link modes:

[Bug 1425576] Re: Occasional crash in APM xgene enet driver on kernels prior to v3.19

ubuntu@am2:~$ iperf -c 10.228.0.2 -P 8 -t 120 Client connecting to 10.228.0.2, TCP port 5001 TCP window size: 85.0 KByte (default) [ 10] local 10.228.66.98 port 59722 connected

[Bug 1425576] Re: Occasional crash in APM xgene enet driver on kernels prior to v3.19

ubuntu@ms10-40-mcdivittA3:~$ uname -a Linux ms10-40-mcdivittA3 3.16.0-44-generic #59-Ubuntu SMP Tue Jul 7 02:18:58 UTC 2015 aarch64 aarch64 aarch64 GNU/Linux ubuntu@ms10-40-mcdivittA3:~$ ubuntu@ms10-40-mcdivittA3:~$ ubuntu@ms10-40-mcdivittA3:~$ ubuntu@ms10-40-mcdivittA3:~$ iperf -c

[Bug 1469214] Re: HP ProLiant m400 Server crashes with unhandled level 3 translation fault

** Description changed: - Running stress-ng on a HP ProLiant m400 server can cause unhandled level - 3 translations faults: + + [Impact] + irqbalance can be crashed(got signal of segment fault) on trusty, utopic, vivid and wily. + + [Test Case] + stress-ng --seq 0 -t 60 --syslog --metrics

[Bug 1469214] Re: HP ProLiant m400 Server crashes with unhandled level 3 translation fault

** Description changed: - Running stress-ng on a HP ProLiant m400 server can cause unhandled level - 3 translations faults: + + [Impact] + irqbalance can be crashed(got signal of segment fault) on trusty, utopic, vivid and wily. + + [Test Case] + stress-ng --seq 0 -t 60 --syslog --metrics

Re: [Bug 1469214] Re: HP ProLiant m400 Server crashes with unhandled level 3 translation fault

On Tue, Jul 7, 2015 at 11:16 AM, Ming Lei ming@canonical.com wrote: Looks there are two kinds of translation fault from irqbalance: 1) happend in place_irq_in_node() which can reproduce in vivid package 2) the 2nd one happened in glib2, which is built by myself, because irqbalance can

[Bug 1296665] Re: irqbalance crashed with SIGSEGV in __libc_start_main()

*** This bug is a duplicate of bug 1469214 *** https://bugs.launchpad.net/bugs/1469214 ** This bug is no longer a duplicate of bug 1183374 irqbalance crashed with SIGSEGV in place_irq_in_node() ** This bug has been marked a duplicate of bug 1469214 HP ProLiant m400 Server crashes with

  1   2   3   4   5   6   7   >