: (unassigned) = Stefan Bader (smb)
** Changed in: linux (Ubuntu)
Status: Confirmed = In Progress
** Changed in: initramfs-tools (Ubuntu)
Status: New = Invalid
** Also affects: initramfs-tools (Ubuntu Saucy)
Importance: Undecided
Status: New
** Also affects: linux (Ubuntu Saucy
Proposing to build the driver into the kernel (again). Though for Saucy
this would only help the installation when the image would get re-spun
with the new kernel. This is normally not done. But we will have to see.
** Changed in: linux (Ubuntu)
Status: In Progress = Fix Committed
**
Fix committed does not mean its available. It just means it was added to
the git repo. If a kernel gets available there should be an automatic
release notice and the status changing to fix released.
--
You received this bug notification because you are a member of Kernel
Packages, which is
Funny enough the boot dmesg contains some indication about the problem,
while the serial output does now (or so it seems):
[0.627017] GPT:Primary header thinks Alt. header is not at the end of the
disk.
[0.628500] GPT:4194303 != 20971519
[0.629167] GPT:Alternate GPT header not at the
** Changed in: linux (Ubuntu Trusty)
Status: Confirmed = In Progress
** Changed in: linux (Ubuntu Trusty)
Assignee: (unassigned) = Stefan Bader (smb)
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https
Oh dear, the answer is so simple after one finally realizes what is
going on... The problem here is that the virtio_blk driver has not been
changed to support more than 15 partitions per device. The partition
scanning is looking at the GPT partition table but only at the first 15
elements. Since
** Changed in: linux (Ubuntu Trusty)
Assignee: Stefan Bader (smb) = (unassigned)
** Changed in: linux (Ubuntu Saucy)
Status: Confirmed = Won't Fix
** Changed in: linux (Ubuntu Raring)
Status: Confirmed = Won't Fix
** Changed in: linux (Ubuntu)
Status: In Progress = Won't
** Tags removed: verification-needed-saucy
** Tags added: verification-done-saucy
--
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/1244176
Title:
Server 13.10 Install Fails with USB
I set the saucy confirmation to done because a real verification is hard
there. ISO images are usually not re-created after release and even less
likely with a kernel still in proposed. So I just checked that the deb
packages for 3.11.0-15.23 contain no ohci-pci module and the contained
config has
... has CONFIG_USB_OHCI_HCD_PCI=y was what I tried to write...
--
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/1244176
Title:
Server 13.10 Install Fails with USB Keyboard (Appears to
Before running prepare-testbed:
- create a directory in /mnt that user ubuntu can write to (say /mnt/adt)
- echo BASEDIR=/mnt/adt ~/.adtrc
autopkgtest should then use /mnt which has lots of space on medium
guests.
--
You received this bug notification because you are a member of Kernel
I saw a similar crash when running the prepare script with a Saucy64
host, a Saucy32 1rst and Saucy32 2nd level guest. The 1rst level guest
cpu set to core2duo and I also had to replace the qemu-system-x86_64 by
qemu (which maps to the same arch). Otherwise the 2nd level guest was
not started at
Using a 64bit 1rst level guest seemed better on manual runs but running
in loops seemed to have locked up on the third run. Though completely
without any messages. I have to look into that next week. I need to run
again with qmp enabled. At least this allows to check for the
instruction pointer of
So host Q and 1rst 32 completed 35 runs and 1rst 64 completed 40.
--
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/1208455
Title:
general protection fault running apt-get inside double
They can be even together. The -nographic removes any emulated graphics
card. I am not sure in detail how the cloud images work, but I believe
serial line as a console is always on. Depending on which release (in
that case I think it is the qemu user-space) the used setup would not
work even.
** Changed in: linux (Ubuntu)
Assignee: Stefan Bader (smb) = (unassigned)
** Changed in: linux (Ubuntu Saucy)
Assignee: Stefan Bader (smb) = (unassigned)
** Changed in: qemu-kvm (Ubuntu)
Assignee: Stefan Bader (smb) = (unassigned)
** Changed in: qemu-kvm (Ubuntu Saucy
So as of IRC feedback this seems to work on a current Quantal kernel.
Which means the next steps should be to verify on one side whether for
example the originally released Raring kernel (3.8.0-19.29) already
showed that problem and on the other side whether a current Saucy
(3.11.0-9.16) kernel
Lucid server is supported until 2015 and I would tend to see this as a
server issue. So since this can be reduced to md problems, the fact that
/proc/mdstat is empty would lead to assume that something during the
assembly failed completely. Despite the weird output of mdadm --examine
(sounds
Serge mentioned today on IRC that this may be also a glibc issue, but I
am not sure what exactly he was looking at and why he thinks so.
Apparently ftracing (I guess the qemu process) and some partially
inlining clone function (those with .isra extention) were involved.
--
You received this bug
Yes, could be related but also is a slightly more complicated setup as
the imsm container is used (fakeRAID with some support in the BIOS from
Intel).
Tried to reproduce in a VM but without success, yet. Though one
interesting note is that mdadm --misc --scan --detail would somehow
report a
Looks like the --scan command might be useless as it seems only to work
properly when the array is defined correctly in mdadm.conf. All my
devices can be examined with --examine and do not show those odd
failed lines. While not being able to reproduce the exact issue,
removing the array definition
It looks a bit like the primary failure is something during the post-
install of linux-image is trying to call update-nvidia which does not
exist and then causes the complete post-install to fail. And that in
turn makes those other packages fail because they depend on linux-image.
Maybe worth
As the script seems to be present at least, could you check (ls -la
/etc/kernel/postinst.d) whether it is executable?
--
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/1242210
Title:
Unfortunately you did a whole lot of things by now. So it is hard to
tell in what state your system is now. If you run
sudo apt-get install -f
does this still complain about the kernel packages? This would be
something to solve first as the nvidia binary module requires those to
compile a driver
Could you attach /var/log/syslog and /var/log/Xorg.0.log from your
system, please.
--
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/1242210
Title:
Failed to install linux kernel
Status
Maybe also the output of dkms status as it sound like the binary
driver is intended to be used.
--
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/1242210
Title:
Failed to install linux
You are not really making it simpler by doing a lot of things you were
not asked to and not doing things you were asked to. Just saying...
I guess your system is in a state where the nvidia binary driver module
is not correctly compiled but the package is installed up to a point
where it prevents
Cannot speak for Kubuntu but its probably the same, but in Ubuntu it
relates to jockey. But then jockey is a front end to manage certain
packages for binary drivers. I have no machine up with an nvidia card
right now, so I cannot look what package name it is exactly. And I am by
now a bit confused
This looks to be the third case we hit with the same symptom (and likely
for yet another reason). The complicating issue is that lxc containers
make use of net namespaces and if those are released, references to I
think the netdevice structures, are temporarily moved over to the
loopback device.
I am sorry, I unfortunately got distracted by trying to finish some feature for
the next release. And I must admit right now I have no good idea how to
proceed. The pages that got dumped at least to me show no pattern that points
to a certain process. You might be in a better position there
** Also affects: linux (Ubuntu Precise)
Importance: Undecided
Status: New
--
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/1223920
Title:
Documentation build error
Status in
** Changed in: linux (Ubuntu Saucy)
Status: Fix Committed = 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/1197451
Title:
Ubuntu fails to properly boot on Macbook Air
As it seemed that starting a 64bit hypervisor (qemu-system-x86_64) from
a 32bit user-space running on another 64bit hypervisor has different
issues which seem to go back even further, I concentrated on bisecting
the case of host running 64bit user-space on a 64bit CPU and the first
level guest
Btw, James, this means there is a simple but not very helpful work-
around for Saucy: use AMD CPU based hosts. Did not check for 32bit user-
space on 1rst level but with 64bit and had no issues. Not very
surprising as the regression seems to be in the nested VMX code. But
also not very useful when
** Also affects: linux (Ubuntu)
Importance: Undecided
Status: New
** Changed in: linux (Ubuntu)
Status: New = Confirmed
** Changed in: linux (Ubuntu)
Importance: Undecided = High
** Changed in: vsftpd (Ubuntu)
Status: Confirmed = Invalid
--
You received this bug
As far as I can see from the upstream discussion this is indeed a kernel
issue. Initially it was intended to be fixed by
Author: Mel Gorman mgor...@suse.de
xen: properly account for _PAGE_NUMA during xen pte translations
...
Steven Noonan forwarded a users report where they had a problem
** Also affects: vsftpd (Ubuntu Trusty)
Importance: Undecided
Status: New
** Also affects: linux (Ubuntu Trusty)
Importance: Undecided
Status: New
** Changed in: linux (Ubuntu Trusty)
Importance: Undecided = High
** Changed in: linux (Ubuntu Trusty)
Status: New =
Could be interesting to find out whether on a m1.small the issue does not occur
(although that still could be resulting from other differences in the setup
than mtu). Not sure how AWS manages to cause the instance to come up with a
different mtu either. In my experiments I had a normal bridge
Thinking about this, I could build a debug kernel to which I add code to
print out the layout of the socket buffer when the size check fails.
Stéphan, would you be able to run that on a setup that shows the
failures?
--
You received this bug notification because you are a member of Kernel
Thanks for the additional info. Definitely the relation to MTU size sounds
quite plausible. The checking is on traffic from the guest out and that I would
expect to be affected by MTU together with GSO support. And yes, preferably we
find a reproducer that does not require a production system
Yes, the kernel would be a set of dpkg files to be installed via 'dpkg
-i'. Of course I still have to code that up. If I can reproduce it with
your instructions locally then even better (would cut down turnaround
times). Otherwise I can start up some EC2 instances, too. Good to have a
simple way
Good news, the reproducer works on my local system, too. Thanks. :)
--
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/1317811
Title:
Dropped packets on EC2, xen_netfront: xennet: skb rides
** Changed in: linux (Ubuntu)
Status: Confirmed = In Progress
** Changed in: linux (Ubuntu)
Assignee: (unassigned) = Stefan Bader (smb)
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https
So with the added debugging and running the reproducer with the outside
bridge (and so the vifs) and the PV guests eth0 set to 9001 (as seen on
EC2), I get the following (format is length@offset):
[ 698.108119] xen_netfront: xennet: skb rides the rocket: 19 slots
[ 698.108134] header 1490@238 -
in: linux (Ubuntu)
Importance: Undecided = Medium
** Changed in: linux (Ubuntu)
Assignee: (unassigned) = Stefan Bader (smb)
--
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/1319244
Title
This would be the proposed way of fixing the issue. I took a current 3.11
kernel version with the patch applied and prepared packages which can be found
at http://people.canonical.com/~smb/lp1319244/
Please could you try how this works on your system and report back here with
the results?
Playing around with this, I actually found an even simpler way to
trigger the issue:
PV guest #1: Install redis-server (and enable eth0 ip in config)
PV guest #2: Install redis-tools and run 'redis-benchmark -q -h PV guest #1
IP -d 1000'
The MTU size turns out to be irrelevant, this even
Oh, ok. It does work quite well on my local guests that come up with
1500 MTU. Maybe the EC2 guests would need a bigger data size value than
1000. But yeah, as long as I have some way to verify whatever comes up
to fix this, it is ok.
Yes, the loss of jumbo frames was expected. As long as high
Serge, looks like we need to be careful with those two. At least one of them:
bridge: only expire the mdb entry when query is received
was reverted with 3.12. The commit message looks a bit like they might have
packed several reverts into one. And it references
bridge: disable snooping if there
But the Trusty kernel has the CONFIG_USB_OHCI_HCD_PCI=y set (which was the
problem reported here) and I just checked the iso with the virtual
keyboard/monitor over lan which was failing before. And that is reacting on the
keyboard.
Michael, from the little info in your comment its unclear
I would think Boris is after memory related special settings on the host and
guest (if you can reveal those). Could be you are hinting that at least for the
host the config was not modified. I assume still using the xm/xend stack. The
other info there would be the number assigned to mem of
Hi Andrew,
sorry about the dyndbg. It all lokked like it would be tied to that but right
now I am not sure it is. I need to check the code again. If anything else fails
we can do a special kernel. I have the same issue as Boris in that I am not
able to cause the same problem on HVM guests
As far as I remember we changed CONFIG_DRM_VMWGFX_FBCON to 'y ' now. Generally
it is getting more complicated nowadays. Grub2 initializes some framebuffer
graphics mode (unless console mode is enforced in /etc/default/grub), hands
this fb over to plymouth and that hands things over to X. And
Hi Stuart,
On 29.04.2014 05:23, Stuart Longland wrote:
Did the linux-3.13.0-24-generic package miss out a few files or are they
in a separate package the installer forgot to install?
That could be and depends on you seed. For bare-metal you should have seleced
linux-server for d-i
Right, unfortunately a real fix without the need to disable scatter
gather will unlikely happen soon. None of the approaches discussed until
now seem to find the agreement of everybody as they all would not be
perfect.
--
You received this bug notification because you are a member of Kernel
The changes are in 3.15, so Utopic/development branch should be fixed
already.
** Changed in: linux (Ubuntu)
Status: Confirmed = Fix Released
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
** Description changed:
+ break-fix: 59a32e2ce5eb809967cac4e718bc527beca83c59
f74373a5cc7a0155d232c4e999648c7a95435bb2
+ break-fix: 59a32e2ce5eb809967cac4e718bc527beca83c59
058504edd02667eef8fac9be27ab3ea74332e9b4
+
Intermitently I get errors stating that various programs cannot allocate
I would doubt Saucy by now since it is almost EOL due to the reduced
support of non-LTS releases. Trusty should get it through the normal
upstream-stable path.
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
** Also affects: linux (Ubuntu Trusty)
Importance: Undecided
Status: New
** Changed in: linux (Ubuntu Trusty)
Importance: Undecided = Medium
** Changed in: linux (Ubuntu Trusty)
Status: New = Triaged
** Tags added: kernel-bug-break-fix
--
You received this bug notification
To add a bit of debugging I did (using two VMs):
- There server side kernel version does not matter (tested trusty and utopic)
- A client with a 3.13 kernel will have the delay, while the 3.16 kernel is ok
Enabling NFS debugging on both clients (as root echo 32767
/proc/sys/sunrpc/nfs_debug)
Some things (like the hardware of the host) we get through apport-collect. It
would be good to get a better understanding of the guest usage. Like how many
guests, how much memory they get, how many vcpus. virtio disks and network and
how are the guests connected to the network (NAT bridge,
** Changed in: linux (Ubuntu)
Status: Incomplete = 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/1322129
Title:
Raw Food Diet - Health Benefits of Raw Vegetables
Status
I see that this was agreed to be an upstream change that is considered
stable material. The patch looks reasonable from the discussion, but I
would like to see it at least reaching upstream linux or linux-next at
least.
--
You received this bug notification because you are a member of Kernel
Can you be more specific about the configuration of the server
(/etc/exports,/etc/defaul/nfs-*) and what kind of client you use. I just
tried this on two VMs and saw not issues (at least with a basic NFSv4
setup).
--
You received this bug notification because you are a member of Kernel
Packages,
Probably the relevant part I missed initially is that probably this involves
connections going on and succeeding for a bit and fail at some point. Where it
is unclear how many connections have been going on and so on.
The function tracing you did does show that there is some kind of loop going
Any news about how the test kernels did fare?
--
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/1319244
Title:
iostat: Cannot open /proc/stat: Cannot allocate memory
Status in “linux”
Oh, sorry, actually it was just me hitting too many Fs. So 32767
(0x7fff) should be enough. I guess the other value is ok, too just sets
too many bits in the mask.
Yes, the messages should end up in syslog. With all debugging turned on
there will be quite a bit of logging going on. Hope this does
If /proc/mounts shows nvsvers=4 I would assume as well that nfsv4 is
used. Formally I had the feeling that the examples looked like for
really using nfsv4 one would need to have one entry in /etc/exports
declaring a fsid=0 (iow the root) and then clients would ask for paths
relative to that root.
Now this also explains why I had a hard time (iow was not being able to)
reproducing this here. Since this indeed is a rather unusual corner
case, I can put it a little lower on the list. Still I would try to
understand the debug output enough to have some better idea about how
that windows app is
Deeper inspection of the logs looks like the problem is some connection
attempt when xprt is not connected. Part of that procedure is to re-use
the connection which forces the xprt to disconnect (so the socket can be
re-used). This triggers a state change (TCP_CLOSE) and wakes up the task
waiting
in: linux (Ubuntu Trusty)
Assignee: (unassigned) = Stefan Bader (smb)
** Changed in: linux (Ubuntu)
Status: Confirmed = Fix Released
--
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
The fix-released for the development kernel is based on both patches
being in the 3.14.4 upstream stable tree.
--
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/1322407
Title:
NFS kernel
It turns out we (you) were not the first ones running into it. The IBM
mainframe guys (obviously) have the same need to potentially allow many
CPUs. The upstream discussion is here:
https://lkml.org/lkml/2014/5/21/251
So, while the change I made does work in this case, it can cause issues.
Really you should file a new bug report (like anybody else still running
into keyboard issues). Like I said in comment #35 the symptoms may be
the same but the missing module of _this_ bug report is included in
14.04. Make sure to describe the environment with as much detail as
possible (keyboard
It might be a bit unclear but the main task is fix released because Utopic
(14.10 and current trunk) is based on 3.15 right now (will move to 3.16 before
release). So Utopic is ok. For Trusty this is still in the mill. The patches
have references to this report. So you should see an automatic
Pragmatically I would just go for a 14.04 (LTS) install. It is pretty
stable already and following updates you would end up with a long-term
supported install. If it has to be 13.10 then its either a netinstall
with a preseed (so no interaction is required), but that is slightly
complicated. Or
** Also affects: linux (Ubuntu Trusty)
Importance: Medium
Assignee: Stefan Bader (smb)
Status: Confirmed
** Also affects: qemu-kvm (Ubuntu Trusty)
Importance: Medium
Status: Confirmed
** Changed in: qemu-kvm (Ubuntu Trusty)
Status: Confirmed = Invalid
--
You
** Changed in: linux (Ubuntu Trusty)
Status: In Progress = 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/1268906
Title:
cpu soft lockup running kvm
Status in
I just did a manual expert install of the current server daily
(3.13.0-3-generic #18 kernel) and that did complete with raid getting
synced. Guest was configured with 1VCPU and 1G of memory. I used 2 LVs
of 8G size to have two virtio disks.
--
You received this bug notification because you are a
Could we confirm whether the automatic test runs still fail with the
latest images?
** Changed in: linux (Ubuntu)
Status: Confirmed = Incomplete
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
** Changed in: linux (Ubuntu)
Assignee: (unassigned) = Stefan Bader (smb)
--
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/1269086
Title:
RAID1 installations fail to complete
** Attachment added: dmesg.log
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1269401/+attachment/3949420/+files/dmesg.log
** Tags added: trusty
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
Public bug reported:
Trusty Server (daily image 2014-01-15)
Kernel: 3.13.0-3.18-generic 64bit
Booting a VM which is set to use cirrus graphics there seems to (still)
be a problem with the framebuffers. The kernel has a special KMS module
which also has a framebuffer interface. During boot
** Attachment added: udev.log
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1269401/+attachment/3949421/+files/udev.log
** Changed in: linux (Ubuntu)
Importance: Undecided = Medium
--
You received this bug notification because you are a member of Kernel
Packages, which is
The apport data from comment #11 shows a virtual machine on VMWare.
Looking at the first dmesg log, there seems to be some kind of resource
conflict between the simple-framebuffer driver and vmwgfx. For testing
you could probably try to create a file like /etc/modprobe.d/blacklist-
testing.conf
Part of v3.13 final. We should get that patch with the next rebase.
Marc, that screenshot counts as physical assault (or whatever the
appropriate charge for making ones eyes bleed is). ;)
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to
** Changed in: linux (Ubuntu)
Assignee: (unassigned) = Stefan Bader (smb)
--
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/1270228
Title:
Loading partman-xfs failed for unknown
There is one commit that is not yet in 3.13.0-4 but has a very
suspicious comment in the commit:
commit d1969a84dd6a44d375aa82bba7d6c38713a429c3
Author: Hugh Dickins hu...@google.com
Date: Thu Jan 16 15:26:48 2014 -0800
percpu_counter: unbreak __percpu_counter_add()
Commit
This appears to be fixed actually (reference in other bug)
** Changed in: linux (Ubuntu)
Status: Confirmed = Fix Released
** Changed in: linux (Ubuntu)
Status: Fix Released = Invalid
--
You received this bug notification because you are a member of Kernel
Packages, which is
Correct status is a bit hard to say as the problem was the journal which
was defined too small given the image size on creation. There may or may
not be a better way to detect this and bail early.
--
You received this bug notification because you are a member of Kernel
Packages, which is
Blacklisting simple-framebuffer for the Ubuntu kernel will have no
effect because it is built-in. But I am interested in the two dmesg's
without any blacklisting to compare the output. Somehow those labelled
as own kernel seem to be from a boot with the normal Ubuntu kernel, too.
Just the wrong
** Changed in: linux (Ubuntu)
Status: Confirmed = In Progress
--
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/1271669
Title:
move drivers/misc/vmw_vmci/vmw_vmci.ko from
** Package changed: ubuntu = linux (Ubuntu)
--
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/1271669
Title:
move drivers/misc/vmw_vmci/vmw_vmci.ko from linux-image-extra to
Modified the title so this could include multiple modules. vmxnet3 is
already in the main package, but vsock.ko and
vmw_vsock_vmci_transport.ko are not but likely should. There is a vmwgfx
driver, too but the target is probably more server type which does not
need accelerated gfx. Also right now
Came up with the same change mostly. just generically including
everything in net/vmw_vsock/*.
--
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/1271669
Title:
Move vmware related modules
Test packages in people.cc/~smb/vmcitest.
--
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/1271669
Title:
Move vmware related modules from extras into main kernel package
Status in
Ok so with those there seems to be some resolution lines which get
repeated three times with the Ubuntu kernel (which is odd) and compared
to the self-compiled kernel there seems to be no action to replace the
framebuffer.
Could you try to boot the Ubuntu kernel with vmwgfx.enable_fbdev=1
added
Not sure which errors are gone now. The line related to drm and vmwgfx are like
the previous no blacklisting and no setting fbdev dmesg to me. Again repeating
the resolution and FIFO line and not replacing the framebuffer.
How the user-space tools would influence the kernel boot I cannot
Did you find out whether this actually was a regression compared to the
previous kernel? Also, since the problem seems to be something
submitting a bufferhead that is not mapped (anymore?) on releasing the
mount namespace, maybe the content of /proc/pid/mount* of the process
about to be killed.
Hi Salvatore, so that old crash really looks quite similar. One
interesting difference is that this process did simply exit and was not
killed. Which sounds, like you did suspect as well, that this is not a
regression in a recent kernel but something in the way things are
executed changed and
1 - 100 of 5873 matches
Mail list logo
