Thank you Peter and Michael for patch and compilation.
I had classes with students. I could check the patch, just now.
The virtual machine works fine but I can still observe such a messages
in the log:
qemu-system-x86_64: pci_get_msi_message: unknown int for dev
'kvm-pci-assign' vector 0, using
Package: qemu
Version: 1:2.7+dfsg-3+b1
Severity: important
I use libvirt for runing Windows 2008 R2 server on qemu-kvm. VirtIO disks and
VirtIO network adapters.
After upgrading qemu from 2.6 to 2.6 Windows do not boot correctly.
The virtual machine crasches after Windows starts to show the "first
W dniu 11.02.2016 o 13:25, Vincent Lefevre pisze:
You need specific steps to reproduce the crash with VLC or the
example program written by Sebastian Ramacher, otherwise it is
not reproducible[*]. This may also depend on the window manager
or desktop environment. The fact that you do not notice
I've seen the bug #807379 I described "'libqt5widgets5: Crashing when
waking up from suspend..." was merged with the bug #790825 described as
"vlc crashes when laptop is undocked" - actually it is bug #790825.
I thing both bus are unrelated.
VLC works fine on my laptop. Suspending/resuspending
The bug is still present and very annoying. I observed it for longer
period of time.
The first observation (and the way to reproduce) is:
-lock the screen without external display connected
-connect external display (I use 2 displays connected via VGA and
DisplayPort)
External displays start w
Package: kde-full
Version: 5:90
Severity: grave
Justification: causes non-serious data loss
I've got numerous crasches connected with libthread_db.so.1. The most
problematic are crashes of kdeinit. When I suspend to RAM and resume, I should
get password prompt screen. Instead of that I usually get
I have libqt5giu5 5.5.1+dfsg-5 (actual Debian testing).
The problem still exists on up to date Debian testing.
Regards,
Maciek
W dniu 30.10.2015 o 17:43, Lisandro Damián Nicanor Pérez Meyer pisze:
tag 799319 unreproducible moreinfo
thanks
I'm assuming you have either testing or unstable.
Plea
Closing remarks and the solution of the problem:
We can conclude that *using 169.254.x.x for routed networks is not in
accordance with standards.*
According to the standards the router shouldn't forward such packages
(from 169.254.x.x network) and even the client shouldn't send such
packages t
W dniu 09.12.2014 o 19:27, Arturo Borrero Gonzalez pisze:
I think in some environments changing the addressing layout is not that simple.
@Maciej, could you post all the network-related config of your failing
machine? I mean: routing, addresses, firewalling, sysctl, IPv6 and
all.
Also, I see y
W dniu 09.12.2014 o 17:13, Henrique de Moraes Holschuh pisze:
On Tue, 09 Dec 2014, Maciej Kotliński wrote:
It is possible to ping the gateway and other computers in 169.254.1.0/24
network. The packets are not routed by the nat.
link-local addresses, such as 169.254.0.0/16 are "unrou
Hello, thanks for fast answer and suggestions.
>1) General is the wrong package for this bug. (i assume it's going to
get closed, network-manager or ifupdown are probably a better idea).
I don't know which one and I'm not sure if it is not somethink else. I
haven't found anything like this in b
Package: general
Severity: important
I have a NAT-ed network which uses 169.254.1.0/24 range (private/zeroconf
range). The network has dhcp and gateway (169.254.1.1). From some time
(probably few months) Debian Jessie is not able to use the gateway.
It is possible to ping the gateway and other co
Hello Rafael,
I've sent my configuration to Alberto. I sent the config only to him by
mistake. I attach the configs below.
Alberto had some remarks/advices connected with mtu. I changed it in
config and the log now is clean.
The problem still exists but I suppose that it is not openvpn but so
the server.
I also noticed such message in dmesg:
Loading kernel module for a network device with CAP_SYS_MODULE
(deprecated). Use CAP_NET_ADMIN and alias netdev- instead.
Regards,
Maciek
W dniu 12.09.2014 o 09:57, Alberto Gonzalez Iniesta pisze:
On Fri, Sep 12, 2014 at 12:10:44AM +0200, Ma
Package: openvpn
Version: 2.3.3-1
Severity: grave
Justification: renders package unusable
I can connect to OpenVPN server (2.3.2), no data is passed thru the tunnel. I
use networm-manager openvpn plugin.
Tcpdump see packages traveling out the client's both on tun0 interface and
client's eth interf
I tested switching as you wrote.
I attached the output of udevadm info.
Here is the output of
udevadm test --action=add -a -p
/devices/pci:00/:00:1c.4/:05:00.0/usb1/1-1/1-1:1.0
ACTION=-p
DEVPATH=/devices/pci:00/:00:1c.4/:05:00.0/usb1/1-1/1-1:1.0
DEVTYPE=usb_interface
DR
I paste description of bug #754499 that I reported for usb-modeswitch-data
package.
Josua Dietze asked me to join here. I haven't seen that bug before because I
checked bugs for usb-modeswitch-data where the file with the rules is located
not usb-modeswitch.
My Huawei E3272 (12d1:1f01) does n
Package: usb-modeswitch-data
Version: 20140529-1
Severity: important
Tags: patch
My Huawei E3272 (12d1:1f01) does not get switched after plugging.
I noticed that several rules for different Huawei devices present in
/lib/udev/rules.d/40-usb_modeswitch.rules were replaced by one rule.
This change w
Package: kde-workspace
Version: 4:4.11.7-1
Severity: important
I usually work at the office with two external monitors. I don't use laptop
screen.
Propably after upgrading to 4:4.11.7-1 (kde-workspace upgraded 01.04.2014) I
can only work with one external display.
When I connect one monitor (Disp
19 matches
Mail list logo
