Hi henrix - I'm trying your patched kernel, will update soon with results.
I too get the kernel panics in 3.13.0-64, but not in -63.
In -64 they are very frequent, so it shouldn't take long to see one again it
re-occurs anyway with your patch in place.
--
You received this bug notification
@apw / @henrix - ah, that's good. No worries.
That explains why only my laptop has had the issue, as indeed I do pull in
updates from proposed there and that's fine - happy to help catch stuff early.
So, all is as it should be! awesome. thanks!
--
You received this bug notification because you
I concur with loann, although mine has only been up for 2h20. With the
unpatched kernel it would've long panicked.
--
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/1497184
Title:
henrix - just a note, probably pointing out the obvious
I find it a tad frustrating that this situation happened with an LTS release,
by the looks of it through a mistake of pulling in an incomplete or untested
kernel patch.
I'd rather not see that happen in LTS, it's causing a bit of grief
I have a similar problem. With this kernel my hdmi-audio works just fine:
/boot/vmlinuz-3.19.0-16-generic.efi.signed
With this new one it is not available/recognized:
/boot/vmlinuz-3.19.0-18-generic.efi.signed
In my case its a Intel HDMI device:
On 3.19.0-16 aplay -l shows:
$ aplay -l
List
This bug has been around for years and we have worked around it by
mounting NFS from rc.local. It's not pretty, but it gets pretty old to
reboot your system and find it hanging. For some reason the NFS mounts
won't wait until networking has completed (i.e. bringing up the
interface).
I doubt it
6 matches
Mail list logo
