@Woody I also have a Gigabyte Z68-ud3h-b3 in another computer (i5 2500k) and event though it's approaching 10 years old, and it's overclocked, it never did that (there were times when it would not cold boot, but at least the fans moved and you could reset the bios via clr_cmos, no problem). My brother has a Gigabyte z97 board and this never happened to him. I will try replacing the power supply since it is quite old, maybe it's related? I measured all the rails with a DMM though and they were in spec but there could be something a multimeter can't detect like noise on the lines or too much delay on startup signal. Thanks for the info anyway!
@buzuk56 The board would not turn on at all, no fans ,no power supply start, nothing. And when it did start, it booted the normal bios no problem so it seems to me it wasn't bios corruption. Anyway, it works OK now, hopefully it was just an isolated event. While I was troubleshooting yesterday, I noticed on the back of the board there were very fine traces of silver colored residue. It looked like the board was soldered with solder paste and some of it spilled and flowed down on the PCB. I cleaned it as best as I could but I'm still worried about it. Any of you had this, or am I just being paranoid? -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1671360 Title: System doesn't boot properly on Gigabyte AM4 motherboards (AMD Ryzen) Status in Linux: Unknown Status in linux package in Ubuntu: Confirmed Bug description: [Impact] Gigabyte AM4 boards users cannot boot Ubuntu successfully. Commit linux-gpio/fixes babdc22b0ccf4ef5a3075ce6e4afc26b7a279faf "pinctrl/amd: Use regular interrupt instead of chained" can fix the issue. [Test Case] All Gigabyte AM4 boards can reproduce the issue. With the patch, the issue is resolved, per comment #170. [Regression Potential] Regression Potential is low. It limits to rather new AMD platform which has pinctrl-amd. As the commit log says, use chained interrupt is not a good idea. Use regular interrupt is the correct way. I also test the patch on an AMD laptop, where its touchpad depends on pinctrl-amd. No regression found. Original bug report: I'm trying to run ubuntu on Ryzen 1700x with Gigabyte GA-AB350-gaming-3 motherboard, and it has a load of problems, starting with not being able to boot normally. During normal boot, on 16.10 as well as 17.04 beta: system doesn't boot normally, hangs with a lot of "unexpected irq trap at vector 07" messages displayed. Following advice from various places, I've tried:disable cpu freq governor and cpu handling in acpi settings 1. add "acpi=off" to boot params That helps, allowing me to boot into recovery mode, though it leaves me with system seeing only one core, is really slow and still only boots in recovery mode. 2. Compile own kernel using 4.11.rc1 and disabling cpu freq governor and cpu handling in acpi settings. Boot with "quiet loglevel=3" option. That gets me even further - system sees all cores now. Still only recovery mode though, but its enough to get info for this bug report. Some observed problems: 1. dmesg reports *a lot* of messages like this all the time: [ 163.362068] ->handle_irq(): ffffffff87a7e090, [ 163.362081] bad_chained_irq+0x0/0x40 [ 163.362089] ->handle_irq(): ffffffff87a7e090, [ 163.362090] amd_gpio_irq_handler+0x0/0x200 [ 163.362090] ->irq_data.chip(): ffffffff88587e20, [ 163.362090] ioapic_ir_chip+0x0/0x120 [ 163.362090] ->action(): ffffffff884601c0 [ 163.362091] IRQ_NOPROBE set [ 163.362099] ->handle_irq(): ffffffff87a7e090, [ 163.362099] amd_gpio_irq_handler+0x0/0x200 [ 163.362100] ->irq_data.chip(): ffffffff88587e20, [ 163.362100] ioapic_ir_chip+0x0/0x120 [ 163.362101] ->action(): ffffffff884601c0 I've tried to redirect dmesg to a file, stopped after a short while, it generated 400M of those. 2. Systemd cannot start journald. Perhaps because it cannot cope with amount of kernel logs? 3. Looking at pci, I've noticed something called AMDI0040 (/sys/bus/acpi/devices/AMDI0040, path=_SB_.EMMC), among AMDI0010, AMDI0020, AMDI0030. Those however are mentioned in kernel source, kernel and google are completely silent about AMDI0040. Phoronix tested ryzen using different motherboard, and it worked better (though not well), so I suspect it is an issue with motherboard. --- ApportVersion: 2.20.4-0ubuntu2 Architecture: amd64 DistroRelease: Ubuntu 17.04 InstallationDate: Installed on 2015-08-06 (581 days ago) InstallationMedia: Kubuntu 15.10 "Wily Werewolf" - Alpha amd64 (20150728.1) Package: linux (not installed) ProcEnviron: LANGUAGE=en_US:en TERM=linux PATH=(custom, no user) LANG=en_US.UTF-8 SHELL=/bin/bash Tags: zesty Uname: Linux 4.11.0-rc1-custom x86_64 UnreportableReason: The running kernel is not an Ubuntu kernel UpgradeStatus: Upgraded to zesty on 2017-03-03 (6 days ago) UserGroups: _MarkForUpload: True To manage notifications about this bug go to: https://bugs.launchpad.net/linux/+bug/1671360/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
