I still think however that shipping Ubuntu kernels with pinctrl-amd
built as a blacklistable module would be an acceptable interim solution
until someone of the AMD/GIGABYTE dream team that's responsible for this
mess can deliver an actual fix.
** Tags added: bitesize kernel-oops
--
You received
Marc, from what I can tell, pinctrl-amd is still enabled on all the
Ubuntu kernels, including the sources in the various git repos
(git://kernel.ubuntu.com/ubuntu/ubuntu-zesty.git etc.)
And I don't think that will change. It is needed for things like
trackpads on some laptops, I believe. Meaning,
I double checked a few times. Joseph's test kernel boots fine for me,
while the default kernel from the repositories still hangs with the same
BIOS settings.
Are you guys sure it's still the same issue that's preventing a
successful boot on your systems?
--
You received this bug notification bec
I tested the kernel on an AX370 Gaming K7 with F3 BIOS, it does seem to
resolve the issue for me.
--
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 proper
** Tags added: regression-release
--
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 pac
** Summary changed:
- System doesn't boot properly on AMD Ryzen / Gigabyte GA-AB350-gaming-3
+ System doesn't boot properly on Gigabyte AM4 motherboards (AMD Ryzen)
** Tags added: xenial yakkety
--
You received this bug notification because you are a member of Kernel
Packages, which is subscrib
In the meantime, is there any particular reason Ubuntu kernels need to
be shipping with pinctrl-amd built-in?
If not, I suggest building it as a module from now on, so that users
affected by this issue don't have to resort to custom built kernels, but
can instead just blacklist the module.
Note t
Bad news.
Using 4.11-rc5 as a base and reverting the commit I previously mentioned
(0be275e3a5607b23f5132121bca22a10ee23aa99) does yield a mostly
functional kernel.
I say "mostly" because there is still a lone "unexpected IRQ trap" in
dmesg when the pinctrl driver loads, though the system boots
s
I have found that kernel 4.1 actually seems to work fine on my board
(AX370-GK7, F2 BIOS), even when compiled with CONFIG_PINCTRL_AMD=y. Note
that to properly test kernels that old, the correct ACPI device ID needs
to be added as seen in commit
42a4440 pinctrl: amd:Add device HID for future AM
Yeah, it looks like the call to irq_desc_get_handler_data() inside that
irq handler is returning null. But I don't understand most of that code,
so no idea what might be causing that.
As a side note: From the looks of it it's probably not going to be
relevant, but just in case it is I have dumped
Here is some additional information. I built upstream kernel 4.11-rc5
with
CONFIG_PINCTRL_AMD=m
CONFIG_DEBUG_PINCTRL=y
CONFIG_DEBUG_GPIO=y
and blacklisted pinctrl-amd so as to able to boot that kernel and set up
netconsole. Doing a
modprobe pinctrl-amd
then results in a crash (o
11 matches
Mail list logo