I'm seeing similar performance degradation on xenial except that the
server I used seems to be pretty slow to start with too:
root@athos:~# sh test.sh
Creating 100 clones
Took: 11 seconds (9/s)
Creating 200 clones
Took: 46 seconds (4/s)
Creating 400 clones
Took: 297 seconds (1/s)
--
You receive
(but doing something pretty similar to what LXD does internally as far
as clones and mountpoint handling)
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to zfs-linux in Ubuntu.
https://bugs.launchpad.net/bugs/1567557
Title:
Performance de
That's pure ZFS completely outside of LXD.
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to zfs-linux in Ubuntu.
https://bugs.launchpad.net/bugs/1567557
Title:
Performance degradation of "zfs clone" when under load
Status in lxd package
Nope, task removed.
** No longer affects: lxc (Ubuntu)
** No longer affects: lxc (Ubuntu Wily)
--
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/1542049
Title:
lxc: ADT exercise test fail
Just a note that Joe's armhf kernel has been working well for me.
I can't test cascardo's kernel as it's not built for armhf.
--
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/1655842
Title:
I've had a few armhf systems running cascardo's kernel and so far no
sign of the OOM or any other problem with it.
--
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/1655842
Title:
"Out of m
I'd like to note that LXD works differently from LXC here.
In LXC we mount debugfs through ubuntu.common.conf whereas with lxd, we
simply bind-mount /sys/kernel/debug from the host if it exists.
LXD doesn't use any of the /usr/share/lxc/* files. If it does on your
system, then you most definitely
Oh and "lxc info" too for good measure (just in case lxd wasn't
restarted post-upgrade).
--
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/1551854
Title:
LXD bootstrap issues on xenial
Sta
Please can everyone affected by this issue post the output of: dpkg -l
lxc liblxc1 lxd lxd-client lxcfs
It's very difficult to figure out what's wrong when we don't even know
the version being used.
** Changed in: linux (Ubuntu)
Status: Confirmed => Incomplete
--
You received this bug no
Ok, so investigation shows that:
- LXD bind-mounts all that stuff, it doesn't have a choice as it's not
privileged enough to mount things itself
- mountall fails to run if its "optional" filesystems fail to mount (because
that makes a lot of sense...)
- systemd sets up the host filesystems, o
** Package changed: linux (Ubuntu) => lxd (Ubuntu)
** Changed in: lxd (Ubuntu)
Assignee: (unassigned) => Stéphane Graber (stgraber)
** Changed in: lxd (Ubuntu)
Status: Incomplete => Fix Committed
--
You received this bug notification because you are a member of Kernel
Public bug reported:
19:06 < stgraber> apw: hey, so looks like powerpc (not 64el) isn't booting with
current 4.4 from xenial
19:06 < stgraber> apw: smoser may have some more details for you, all I know is
that I dist-upgraded my ppc VM and it stopped booting, smoser had to reboot me
into 3.19 m
** No longer affects: lxc
--
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/1293549
Title:
Filesystem mount from lxc template causes filesystem permission
breakages
Status in juju-core:
** No longer affects: lxd (Ubuntu)
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux-armadaxp in Ubuntu.
https://bugs.launchpad.net/bugs/1527374
Title:
privilege escalation on attach through ptrace
Status in linux package in Ubuntu
Unloading and loading iwlmvm and iwlwifi did the trick to fix this.
Last time I had that issue, I attempted to reload iwlmvm, but not
iwlwifi too, maybe that made a difference this time.
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to lin
Public bug reported:
After resume, wifi doesn't come back up, all wifi related commands take
a long time before failing with input/output error.
Kernel log only seems to show some slowpaths being hit, but wifi sure
isn't working here...
ProblemType: Bug
DistroRelease: Ubuntu 16.04
Package: linux
I unfortunately can't reproduce this on demand. I've had it happen to me
so far twice, both times immediately after resume, on two completely
different wifi networks, once on a mobile hotspot from my phone and
another time at a hotel in Brussels.
My best guess is that it's got to do with some netw
Very much looks like it's related to threading and futexes somehow.
Forcing golang to use a single thread rather than one per container made
things more stable using a very simple test (infinite loop of "lxc
list"), though starting containers then still caused the hang to happen.
I've seen a simi
** No longer affects: linux (Ubuntu)
** Also affects: lxc (Ubuntu Trusty)
Importance: Undecided
Status: New
** No longer affects: linux (Ubuntu Utopic)
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bu
Serge, could we just have lxc-attach query lxc.arch using
get_config_item over the command interface and do the personality
mapping based on the running container config rather than the running
processes?
That should spare us the addition of a new command interface call and
the usual breakage we g
The LXC change looks good, it's in line with what I was planning to push
upstream. Feel free to upload that directly to the archive and I'll do a
similar upstream change right around the same time so our PPA users
don't break, then shortly after that will tag 1.0.3 and get that into
trusty so we ca
It's related to the apparmor patch, the security team is aware of it and
I believe John has a patch.
--
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/1308082
Title:
apparmor oops caused by
Moved to linux, ifenslave only tells the kernel to create the bond, if
the reported speed is wrong, it's a kernel bug not a userspace one.
** Package changed: ifenslave (Ubuntu) => linux (Ubuntu)
--
You received this bug notification because you are a member of Kernel
Packages, which is subscrib
t; Title:
> login console 0 in user namespace container is not configured right
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1263738/+subscriptions
--
Stéphane Graber
Ubuntu developer
http://www.ubuntu.com
--
You received th
Marking as invalid for LXC since this is a kernel bug.
** Changed in: lxc (Ubuntu)
Status: Confirmed => Invalid
--
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/1196295
Title:
lxc-
Public bug reported:
Hello,
We've just had a rather length chat in #ubuntu-touch about some problems
related to rtkit and pulseaudio on the phone and then on any trusty
machine.
It turns out that since we now put all users in their own cpu cgroup,
rt_runtime_us is set to 0 which prevents any of
I'm closing the lxc task as there's nothing we can do in lxc itself to
avoid this, the upstart and kernel patches will solve this for us.
Btw, the branch proposed by James above does work fine for me and has
since been accepted upstream, the next upload should include this fix.
** Changed in: lxc
root@lxc-dev:/# ls -lh /proc/sys/net/ipv4/ip_local_reserved_ports
ls: cannot access /proc/sys/net/ipv4/ip_local_reserved_ports: No such file or
directory
root@lxc-dev:/# uname -a
Linux lxc-dev 3.13.0-8-generic #27-Ubuntu SMP Fri Feb 7 02:01:37 UTC 2014
x86_64 x86_64 x86_64 GNU/Linux
So somethin
Setting as confirmed since this is 100% reproducible on current kernel
and not a crash but just broken /proc/sys/net (missing entries) and
possibly broken netns (those should be ns-specific).
** Changed in: linux (Ubuntu)
Status: Incomplete => Confirmed
--
You received this bug notificati
The audit problem with 3.14 is known and being looked at upstream I
believe.
--
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/1279041
Title:
/proc/sys/net/ipv4/ip_local_reserved_ports not
Public bug reported:
The recent security update kernel broke nested unprivileged LXC containers as
those attempt to do the following:
access("/usr/lib/x86_64-linux-gnu/lxc/dev/console", F_OK) = 0
mount("/dev/console", "/usr/lib/x86_64-linux-gnu/lxc/dev/console",
0x7fff406cd9e9, MS_BIND, NULL) =
root@qdisc:~# tc qdisc add dev eth0 root netem delay 50ms
root@qdisc:~# ping 10.0.3.1
PING 10.0.3.1 (10.0.3.1) 56(84) bytes of data.
64 bytes from 10.0.3.1: icmp_seq=1 ttl=64 time=50.3 ms
64 bytes from 10.0.3.1: icmp_seq=2 ttl=64 time=50.3 ms
^C
--- 10.0.3.1 ping statistics ---
2 packets transmitte
The verification of the Stable Release Update for intel-gpu-tools has
completed successfully and the package has now been released to
-updates. Subsequently, the Ubuntu Stable Release Updates Team is being
unsubscribed and will not receive messages about this bug report. In
the event that you enc
Public bug reported:
Hello,
I pushed a fix to the mainline kernel which I believe will first be released in
3.16.
This change is required to make setting tc rules inside an unprivileged lxc
container (assuming the userns owns a netns).
Commit id is: 4e8bbb819d1594a01f91b1de83321f68d3e6e245
Ca
so I think it's some systemd handling which does that. LXC unshares the
mnt namespace which gets it a copy of the host's, then it's doing some
magic (rprivate I believe) to get things working under systemd, then
mounts what it needs, unmounts everything else and pivot_root.
lxc itself has no code
So the problem is that a force unmount of a bind-mount of a fuse
filesystem somehow gets the kernel to send the "destroy" command back to
the user space process running the filesystem. This behavior is clearly
wrong.
As an example, lets say that I'm running "lxcfs" as a fuse filesystem on
my syste
I don't have any good example in mind of fuse being used in that manner
(system wide user accessible filesystem) but if there was, this would be
a potential security issue against them. Once we figure out the root
cause of this and fix it, it may be worth considering this a security
fix.
--
You r
Anything else that's special on that network, e.g. non-standard MTU?
--
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/1402763
Title:
Multicast traffic not propating correctly over linux br
Hmm, I can reproduce the exact same thing even without allow_other.
Sure, my user is getting permission denied if it attempts to read from
the fs, but it can still bind-mount it and then cause it to die by doing
a force unmount.
--
You received this bug notification because you are a member of K
So I came up with an alternate way around this which works for both
privileged and unprivileged containers and doesn't require an updated
apparmor. This uses seccomp to filter the umount2 call and return EACCES
when passed MNT_FORCE as second argument.
Code is at: http://paste.ubuntu.com/9568741/
SCMP_CMP_MASKED_EQ should be used to restrict MNT_FORCE regardless of
what other mntflags are passed, though I'm failing to find the right
syntax for it...
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launc
Might be worth mentioning that all affected hosts are x86 64bit Intel.
For those I've got access to, the issue happened on:
- 2x Xeon E3-1245v2
- 1x Xeon E5-2620v2
- 1x Atom C2750
- 1x Atom D2500
- 1x Core i5 750
All running on pretty standard Intel boards, so the usual set of Intel
chipsets
Public bug reported:
After updating a dozen machines from 3.13.0-40 to 3.13.0-43, they all
kernel panic within the next 24 hours.
I managed to pull the console from one over an IP KVM and it shows a panic
related to IPv6 networking:
https://dl.stgraber.org/panic-3.13-43.png
All affected machine
** Changed in: linux (Ubuntu)
Status: Incomplete => Confirmed
--
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/1404558
Title:
IPv6 related kernel panic following upgrade to 3.13.0-4
Public bug reported:
I recently noticed a bunch of containers failing in a rather odd way
when running postfix.
The most visible example is when running mailq on an empty queue.
Without apparmor (unconfined container) I see that the queue is empty,
with apparmor, I get Permission denied.
That's
Public bug reported:
I've recently been getting a few kernel panics which I've tracked down
to having panic_on_oops set to 1 and which appear to be related to this
oops:
[ 2182.341680] general protection fault: [#1] SMP
[ 2182.341702] Modules linked in: xt_CHECKSUM esp6 xfrm6_mode_transport
Yes, this is 3.13 with btrfs on a single encrypted block device with
zlib compression.
The oops doesn't appear particularly armful now that I've turned off
panic_on_oops so it's not something I'm willing to sacrifice 2TB of free
space to workaround :)
--
You received this bug notification becaus
I have since upgraded that server to the upcoming utopic backport (from
the kernel team PPA) and I haven't been able to reproduce this bug. So
it may well be that there are some btrfs bugfixes in 3.16 which haven't
made it to stable.
--
You received this bug notification because you are a member
Public bug reported:
So I just updated my home server to the 3.16 from the kernel team PPA
(3.16.0-23-generic #31-Ubuntu) and I'm now getting a ton of warnings
related to what looks like some kind of network hardware offloading.
A 10 minutes kernel.log sample is attached.
The server is a recent
I can confirm that something's broken with the recent kernel update...
--
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/1404558
Title:
IPv6 related kernel panic following upgrade to 3.13.0
Let's file a new bug for that one.
--
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/1404558
Title:
IPv6 related kernel panic following upgrade to 3.13.0-43
Status in linux package in Ubun
Public bug reported:
Hello,
Pretty similar to what happened with
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1404558 but this
time with the latest 3.13.0-46.
I've been getting about daily kernel panics (three times so far).
Screenshot attached. Another user also commented in bug 140455
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1426618
--
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/1404558
Title:
IPv6 related kernel panic following upgrade to 3.13.0-43
Statu
I don't have a reproducer other than install the kernel and wait 24h as
that's how long it took for some systems to panic...
>From a very quick look, those kernels are mainline kernels,
unfortunately all my hosts are LXC hosts using unprivileged containers
with overlayfs, so I need kernels with th
Rebooted the Xeon E5-2620v2 system on linux-image-3.13.0-44-generic now.
--
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/1404558
Title:
IPv6 related kernel panic following upgrade to 3.13
Reproduced the panic with -44, same stack trace, screenshot attached.
Booting the machine back on -40 now.
** Attachment added: "Screenshot from 2015-01-05 16:40:16.png"
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1404558/+attachment/4292566/+files/Screenshot%20from%202015-01-05%2016%
Almost 24 hours and no kernel panic so far!
--
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/1404558
Title:
IPv6 related kernel panic following upgrade to 3.13.0-43
Status in linux packag
Still no panic after 48h, let's call it good.
--
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/1404558
Title:
IPv6 related kernel panic following upgrade to 3.13.0-43
Status in linux pack
Booted the new kernel and so far so good. Since there is no real
reproducer for this bug, I'll mark this as verification-done and will
come flip it back to verification-failed if the box panics by the time
you push this kernel to updates.
** Tags removed: verification-needed-trusty
** Tags added:
As a workaround, you could do "lxc profile set default limits.cpu 1-2"
which will have LXD setup the cpuset pinning for all containers to avoid
CPU 0.
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.
Seems correct to have this tracked as a kernel bug. Unless you set
limits.cpu in LXD, LXD will not alter the cpu pinning in any way. And
even if it did, it'd do so through the cpuset cgroup, which shouldn't
allow a sub-cgroup to be any more permissive than the root cgroup.
--
You received this bu
So the problem here is that LXD itself DOES NOT touch the cpuset
controller at all.
liblxc does have some initialization code in place which will copy the
parent value for cpuset.cpus and cpuset.mems if cgroup.clone_children
hasn't been set to 1 yet.
So I guess we'd need a change to the cgfsng ba
I thought of looking at Cpus_allowed from the status file of the current
task or of pid 1, but since both of those would be affected by the task
being in a non-root cgroup, we can't rely on that.
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribe
I'm assuming you have a system that's booted with the right kernel
option.
Can you check if /sys/devices/system/cpu/possible includes the isolated
CPU?
If not, then we could copy that value instead of having to parse the CPU
ranges from /sys/devices/system/cpu/isolated and substract that from the
** Changed in: linux (Ubuntu)
Status: Incomplete => New
** Tags added: bot-stop-nagging
--
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/1639345
Title:
lxc-attach to malicious cont
** Changed in: linux (Ubuntu)
Status: Incomplete => Triaged
--
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/1639345
Title:
lxc-attach to malicious container allows access to host
Christian will be testing 4.4.0-45 to see if we hit this issue with a
pre-aastacking kernel.
--
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/1645037
Title:
apparmor_parser hangs indefinit
This has been confirmed to affect both the 4.4 and 4.8 kernels.
** Project changed: apparmor => apparmor (Ubuntu)
** Also affects: linux (Ubuntu)
Importance: Undecided
Status: New
** Also affects: apparmor (Ubuntu Zesty)
Importance: Undecided
Status: New
** Also affects: lin
Did you install squashfuse in your container?
--
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/1611078
Title:
Support snaps inside of lxd containers
Status in Snappy:
Fix Released
Statu
So I've confirmed that the python3 side of this has been resolved.
zfsutils-linux as it is in yakkety right now has now been changed over
to python3 by Colin.
Though, as discussed by e-mail when Dustin first brought this up, there
is a second issue I think we should have resolved before we start
i
Right, so unfortunately we can't base it on whether the zfs module is
loaded, as it will effectively always be loaded as soon as we pre-
install zfsutils-linux in our images.
Now what we could do I guess is:
- Don't start ANY of the 3 zfs systemd units in containers (that should be
pretty trivia
So the problem is that zfs does its own loop mount handling without
using a loop device so without a block uevent...
Triggering on a uevent would only work for pools that are using physical
devices, not for those using file as loops, which is unfortunately a
rather common setup for LXD users who d
** Changed in: lxd (Ubuntu)
Status: Fix Committed => Fix Released
** No longer affects: lxd
--
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/1611078
Title:
Support snaps inside of
Marking this bug fix released as all the bits we wanted done here have
been done.
We still have a separate bug open for the dependency on squashfuse and
its SRU to xenial.
** Changed in: snappy
Status: Fix Committed => Fix Released
--
You received this bug notification because you are a
** Changed in: lxd (Ubuntu Xenial)
Status: New => Fix Committed
--
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/1611078
Title:
Support snaps inside of lxd containers
Status in Sna
This is a kernel bug which sforshee has been working on. It should be
included in the next round of kernel updates.
** Package changed: lxc (Ubuntu) => linux (Ubuntu)
** Changed in: linux (Ubuntu)
Assignee: (unassigned) => Seth Forshee (sforshee)
--
You received this bug notification becau
Moving this over to the kernel. The upstream issue is closed for the
same reason.
The network namespace is somehow still alive despite the container being
fully gone (no processes).
In the past this has been caused by some problems in the
refcount/cleanup code for the network namespace. The inten
** Package changed: linux (Ubuntu) => lxc (Ubuntu)
** Changed in: lxc (Ubuntu)
Status: Confirmed => Triaged
** Changed in: lxc (Ubuntu)
Assignee: (unassigned) => Christian Brauner (cbrauner)
--
You received this bug notification because you are a member of Kernel
Packages, which is
stgraber@castiana:~$ wget -q
https://launchpad.net/ubuntu/+archive/primary/+files/nic-modules-3.8.0-28-generic-di_3.8.0-28.41_amd64.udeb
-O - | dpkg --contents /dev/stdin | grep iwldvm
-rw-r--r-- root/root388948 2013-07-26 18:52
./lib/modules/3.8.0-28-generic/kernel/drivers/net/wireless/iwlw
Public bug reported:
We noticed when doing some debugging at the release sprint that although
we have iwlwifi in d-i, we don't have iwldvm, making the whole thing
useless.
Can we please get iwldvm added?
** Affects: linux (Ubuntu)
Importance: High
Assignee: Andy Whitcroft (apw)
Hello AceLan, or anyone else affected,
Accepted linux-firmware into precise-proposed. The package will build
now and be available at http://launchpad.net/ubuntu/+source/linux-
firmware/1.79.8 in a few hours, and then in the -proposed repository.
Please help us by testing this new package. See
ht
** Changed in: linux (Ubuntu)
Milestone: ubuntu-13.07 => ubuntu-13.09
--
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/1066435
Title:
powerpc: "Fixing recursive fault but reboot is nee
Sorry I didn't get back to you earlier, I needed reliable internet the
past few days. I'm doing a test run now.
--
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/1251946
Title:
Network rela
Well, I'd if the kernels were there ;)
--
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/1251946
Title:
Network related kernel panic on Atom 64bit system using saucy backport
stack on pre
Same thing as your previous kernel, PPPoE doesn't work so my machine is
essentially useless and the panicing code path doesn't get exercised. So
the result is "no idea".
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
http
The verification of this Stable Release Update has completed
successfully and the package has now been released to -updates.
Subsequently, the Ubuntu Stable Release Updates Team is being
unsubscribed and will not receive messages about this bug report. In
the event that you encounter a regression
The verification of this Stable Release Update has completed
successfully and the package has now been released to -updates.
Subsequently, the Ubuntu Stable Release Updates Team is being
unsubscribed and will not receive messages about this bug report. In
the event that you encounter a regression
That kernel is still useless to me...
So I went looking a bit closer at your test kernels and it looks like
the problem is the config you're using, they simply lack PPPoE support
entirely...
root@sateda:~# grep -i pppoe /boot/config-3.7.0-030700rc5-generic
root@sateda:~# grep -i pppoe /boot/conf
That kernel still doesn't have PPPoE support in its config...
--
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/1251946
Title:
Network related kernel panic on Atom 64bit system using saucy
Sorry for the delay, I just got back from a couple of weeks on another
continent so didn't feel like testing this remotely :)
I'll do a test run now. By the way, since I first reported this issue, I
managed to reproduce it on two more machines running the 3.11 kernel, it
seems to vary with the num
That kernel panics:
[ 68.626968] [ cut here ]
[ 68.631590] kernel BUG at
/home/jsalisbury/bugs/lp1251946/linux-stable/net/core/skbuff.c:1040!
[ 68.640188] invalid opcode: [#1] SMP
[ 68.644324] Modules linked in: authenc esp6 xfrm6_mode_transport ipcomp6
xfrm
To add to the list above, I also had him test the current 3.13.0-0 from
the kernel-team PPA, this one doesn't work either.
--
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/1265544
Title:
8
So to clarify based on IRC discussion:
- Current trusty (3.12.0-7) gives a blank screen from the start
- mainline drm-intel-nightly build 2013-12-10 does the same
- mainline drm-intel-nightly build 2013-12-11 and any further one "works"
"works" here refers to the screen lighting up at boot time
Hello Yingying, or anyone else affected,
Accepted linux-firmware into saucy-proposed. The package will build now
and be available at http://launchpad.net/ubuntu/+source/linux-
firmware/1.116.1 in a few hours, and then in the -proposed repository.
Please help us by testing this new package. See
h
That kernel doesn't have PPPoE support so it's useless to me, I need a
distro kernel for those tests :)
--
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/1251946
Title:
Network related kern
Public bug reported:
I can't report this through ubuntu-bug as the system is a firewall with
restricted connectivity and the kernel bug prevents me from using the
system for more than a couple minutes anyway.
I recently deployed the saucy kernel on that precise system, after the
first reboot thin
Moving to Confirmed to make the bot happy, I believe all immediately
useful information is above, let me know if you need more.
** Changed in: linux (Ubuntu)
Status: Incomplete => Confirmed
--
You received this bug notification because you are a member of Kernel
Packages, which is subscri
I tried the current -proposed kernel which seems considerably more
reliable, instead of panicing within a couple of minutes from the boot
it now does within 30min or so, current panic message is:
[ 1407.957715] [ cut here ]
[ 1407.962346] Kernel BUG at 815e1310 [ver
And same thing reproduced after just a few seconds on the current 3.12
kernel:
[ 54.047386] [ cut here ]
[ 54.052018] Kernel BUG at 81607e40 [verbose debug info unavailable]
[ 54.058985] invalid opcode: [#1] SMP
[ 54.063118] Modules linked in: authenc(
Same thing on a 3.8 kernel:
[ 151.530274] [ cut here ]
[ 151.534897] Kernel BUG at 815be3a8 [verbose debug info unavailable]
[ 151.541849] invalid opcode: [#1] SMP
[ 151.545978] Modules linked in: authenc(F) esp6(F) xfrm6_mode_transport(F)
ipcomp6(F) xfrm
101 - 200 of 261 matches
Mail list logo
