Bug#1071582: ip: Poor color choice for dark background

2024-05-22 Thread Gedalya
I'm trying ... https://lore.kernel.org/netdev/2c0a1779713b5bdd443a8e8258c7d...@manjaro.org/ https://lore.kernel.org/netdev/e1s9rpa-0006jy7-1...@ws2.gedalya.net/

Bug#1071582: ip: Poor color choice for dark background

2024-05-21 Thread Gedalya
On 5/21/24 10:55 PM, Luca Boccassi wrote: > This has always been enabled by default, even in stable. What is the meaning of this line in the changelog for 6.9.0-1, and why does it correlate with an actual change in behavior? Quote:   * Enable output with colors on terminals

Bug#1071582: ip: Poor color choice for dark background

2024-05-21 Thread Gedalya
Package: iproute2 Version: 6.9.0-1 Severity: minor Hello, The newly enabled colored output is rather hard to read on dark backgrounds, especially the deep blue color used for IPv6 addresses. Setting COLORFGBG=";0" as the manpage suggests helps a lot. Consider a scenario when this command is

Bug#1070159: i915: CPU usage spikes with monitor powered down or unplugged

2024-05-20 Thread Gedalya
On 5/21/24 2:41 AM, Salvatore Bonaccorso wrote: > Can you please test if you have the same behaviour with recent > upstream kernels? For instance test with 6.8.9-1 in unstable, or if > you can build upstream stable version 6.8.10, 6.9.1. 6.8.9 - same behavior 6.9.1 from pristine upstream tar

Bug#992832: linux-image-5.10.0-8-amd64: please enable CONFIG_AMD_PMC

2021-08-24 Thread Gedalya
Package: linux-image-5.10.0-8-amd64 Version: 5.10.46-4 Hi, amd-pmc is needed on recent AMD Ryzen laptops in order to properly enter s2Idle. Another module apparently relevant on recent Ryzen laptops is CONFIG_AMD_SFH_HID, although this PCI device is not present on my laptop. Thanks, Gedalya

Bug#984852: firmware-amd-graphics: Please add cezanne ("green sardine")

2021-03-09 Thread Gedalya
On 3/9/21 5:31 PM, maximilian attems wrote: > >> the display stopped updating as soon as amdgpu took over, and it never came >> back. >> The firmware is needed of course, and as a side note, it could be nice if >> the kernel could fail more gracefully, somehow bringing the display back (it >>

Bug#984852: firmware-amd-graphics: Please add cezanne ("green sardine")

2021-03-09 Thread Gedalya
Package: firmware-amd-graphics Version: 20210208-3 Hi, I've received my new laptop with a Ryzen R7 5800U and the display stopped updating as soon as amdgpu took over, and it never came back. The firmware is needed of course, and as a side note, it could be nice if the kernel could fail more

Bug#947413: linux-image-4.19.0-7-amd64: kernel lockup

2019-12-26 Thread Gedalya
Package: src:linux Version: 4.19.87-1 Dear Maintainer,    * What led up to the situation? Not sure exactly. Normal operations. I'll include some facts that I suspect might be relevant: Most volumes are mounted with the "discard" option. The I/O operations in question seem to have involved

Bug#930443: ixgbe: ixgbe_ipsec_tx: bad sa_idx=64512 handle=0

2019-10-15 Thread Gedalya
See: https://bugs.launchpad.net/ubuntu/+source/strongswan/+bug/1846283 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c?h=v5.4-rc1=f39b683d35dfa93a58f1b400a8ec0ff81296b37c (linked therein) And:

Bug#930443: ixgbe: ixgbe_ipsec_tx: bad sa_idx=64512 handle=0

2019-06-12 Thread Gedalya
on here, but I'd be happy to investigate further given some guidance. Also, if someone could provide some tips for a workaround that would be nice, since this is currently simply not working. Thanks, Gedalya ipsec statusall: Connections: office-1:  %any...office  IKEv2, dpddelay=30s office-1

Bug#839627: linux-image-4.7.0-1-amd64: kvm-clock provides unadjusted time

2016-10-08 Thread Gedalya
I have two KVM servers where I'm doing GPU passthrough to a VM. Both are running linux 4.6.4. We're using an NVIDIA GPU which means I have to hide KVM (kvm=off, or ). As a result, current_clocksource is tsc. ntpd shows a drift of ~0. So in seems that the tsc values the VM is getting are

Bug#839627: linux-image-4.7.0-1-amd64: kvm-clock provides unadjusted time

2016-10-06 Thread Gedalya
13231 [002] 387476.246883: kvmclock_update_fn <-process_one_work kworker/0:47-13195 [000] 387476.246884: kvmclock_update_fn <-process_one_work Yet, the guests still seem to be getting the unadjusted time. Thanks, Gedalya

Bug#839627: linux-image-4.7.0-1-amd64: kvm-clock provides unadjusted time

2016-10-03 Thread Gedalya
Package: src:linux Version: 4.7.5-1 Severity: normal Dear Maintainer, When booting the host with linux 3.16, it looks like kvm-clock provides guests with time as adjusted by ntpd. This looks like this (note the 'frequency' variable [0]): host : # ntpq -crv associd=0 status=0415 leap_none,

Bug#771045: System randomly freezes using Kernel 3.16 and radeon

2015-02-15 Thread Gedalya
Fixes for this are included in Linux 3.19, commits: 3a01fd367e09ebf05d75a000407364e7ebe2b678 d474ea7e52cbaaae22711d857949ba6018562c29 cbfc35b90f3b4853d1eb9fcb82e99531d6a1c629 -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact

Bug#771045: System randomly freezes using Kernel 3.16 and radeon

2015-02-15 Thread Gedalya
On 02/16/2015 01:08 AM, Gedalya wrote: Fixes for this are included in Linux 3.19, commits: 3a01fd367e09ebf05d75a000407364e7ebe2b678 d474ea7e52cbaaae22711d857949ba6018562c29 cbfc35b90f3b4853d1eb9fcb82e99531d6a1c629 Ah, already in 3.16.7-ckt6 too. -- To UNSUBSCRIBE, email to debian-kernel

Bug#776448: xen dom0: xen:balloon: reserve_additional_memory: add_memory() failed: -17

2015-01-27 Thread Gedalya
Package: src:linux Version: 3.16.7-ckt4-2 Severity: normal Dear Maintainer, After a clean boot everything is OK, but as soon as I reboot a domU for the first time, I start getting these lines in dmesg: xen:balloon: reserve_additional_memory: add_memory() failed: -17 And they keep repeating

Bug#776050: Bug#776237: xen-hypervisor-4.4-amd64: kernel panic on dom0 boot

2015-01-27 Thread Gedalya
On 01/27/2015 03:17 AM, Ian Campbell wrote: Could #776237 be related to #776050? https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=776050 It's quite possible and the coincidence of the issue arising in ckt4 makes me think it most likely is. Lets assume it is for now, I've merged the two

Bug#776050: Bug#776237: xen-hypervisor-4.4-amd64: kernel panic on dom0 boot

2015-01-26 Thread Gedalya
On Mon, 26 Jan 2015 10:24:41 + Ian Campbell wrote: This is actually a kernel issue I think, so reassigning accordingly. 2c3fc8d26dd0 swiotlb-xen: pass dev_addr to swiotlb_tbl_unmap_single was backported to the stable kernel but this commit was reverted in mainline via dbdd74763f1f.

Bug#771045: Acknowledgement (linux-image-3.16.0-4-amd64: System randomly freezes using Kernel 3.16 and radeon)

2015-01-23 Thread Gedalya
On Tue, 20 Jan 2015 12:36:59 +0100 Antoine Amarilli wrote: It seems like the bug was already reported in mesa: The mesa package already has a fix for this staged in git for jessie, not released yet.

Bug#771045: Kernel crashes with radeonsi

2015-01-12 Thread Gedalya
I've been running now for 4d17h with locally built mesa 10.3.2-1 + upstream commit ae4536b4 applied. Kernel 3.16.7-ckt2-1. So far running without any problems. Without that patch I wouldn't last 24 hours. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of

Bug#767261: xen-netback changes in #767261 break Mini-OS netfront

2014-12-29 Thread Gedalya
;-) With your newly built kernel, everything seems to be fine. Cheers! Gedalya -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54a24b4a.1040...@gedalya.net

Bug#767261: xen-hypervisor-4.4-amd64: host lockup when DomU network iface is down

2014-11-09 Thread Gedalya
On 11/09/2014 05:11 AM, Ian Campbell wrote: On Sat, 2014-11-08 at 15:13 -0500, Gedalya wrote: On 11/08/2014 08:44 AM, Gedalya wrote: Tried to just frankenport xen-netback from 3.18 into 3.16, didn't work very well ;-) Did you backport just the above or the full set of changes from 3.18? I

Bug#767261: [Pkg-xen-devel] Bug#767261: xen-hypervisor-4.4-amd64: host lockup when DomU network iface is down

2014-11-08 Thread Gedalya
On 11/08/2014 05:39 AM, Ian Campbell wrote: On Sat, 2014-11-08 at 00:40 -0500, Gedalya wrote: On 11/07/2014 03:25 AM, Ian Campbell wrote: On Thu, 2014-11-06 at 11:06 -0500, Gedalya wrote: I suspect we will need to backport some xen-netback patch or other. I've put some feelers out to see

Bug#767261: [Pkg-xen-devel] Bug#767261: xen-hypervisor-4.4-amd64: host lockup when DomU network iface is down

2014-11-08 Thread Gedalya
On 11/08/2014 08:44 AM, Gedalya wrote: Tried to just frankenport xen-netback from 3.18 into 3.16, didn't work very well ;-) Did you backport just the above or the full set of changes from 3.18? I tried to simplify (avoid having to edit code myself..) by just copying the full xen-netback from

Bug#767261: [Pkg-xen-devel] Bug#767261: xen-hypervisor-4.4-amd64: host lockup when DomU network iface is down

2014-11-07 Thread Gedalya
On 11/07/2014 03:25 AM, Ian Campbell wrote: On Thu, 2014-11-06 at 11:06 -0500, Gedalya wrote: I suspect we will need to backport some xen-netback patch or other. I've put some feelers out to see if any of the upstream devs have any hints... OK so if it's just a matter of changing a kernel

Bug#767261: [Pkg-xen-devel] Bug#767261: xen-hypervisor-4.4-amd64: host lockup when DomU network iface is down

2014-11-06 Thread Gedalya
On 11/06/2014 07:17 AM, Ian Campbell wrote: Control: reassign -1 src:linux Control: found -1 3.16.5-1 On Wed, 2014-10-29 at 12:57 -0400, Gedalya wrote: On dom0 I get messages like 'vif vif-10-0 vif10.0: draining TX queue', starting as soon as the domU's boot up. I'm pretty sure

Bug#675302: reassign to linux

2012-11-26 Thread Gedalya
reassign 675302 src:linux 3.2.32-1 thanks -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/50b3654d.7070...@gedalya.net

Bug#675302: nouveau: hard lockup when gdm3 starts

2012-10-14 Thread Gedalya
What's up? Linux 3.2.30-1 (currently in sid) still has the same problem. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/507afad7.6010...@gedalya.net

Bug#681743: i915: display backlight brightness initially set to zero on boot

2012-10-14 Thread Gedalya
On 07/16/2012 07:45 AM, Jonathan Nieder wrote: If I don't get back to you soon, feel free to ping me. ping! -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive:

Bug#681743: i915: display backlight brightness initially set to zero on boot

2012-07-19 Thread Gedalya
Tested 3.5.0-rc7+, boots up the same way, with the backlight off. Adding i915.invert_brightness=1 makes it turn the brightness up to the maximum as expected, however this is pretty ugly. Without this parameter, I can just turn the brightness up with the fn keys and I get the nice on-screen

Bug#680737: linux-image-3.2.0-2-amd64: Intel i915: black display after boot

2012-07-16 Thread Gedalya
Package: src Version: 3.2.21-3 Followup-For: Bug #680737 I think this is the same problem here.. using an HP dm4t-1200 laptop. The backlight is set to zero brightness as soon as the kernel begins to load. In my case I can set the brightness higher by simply using the appropriate fn key

Bug#680737: [wheezy] Intel i915: black display after boot

2012-07-16 Thread Gedalya
On Mon, 2012-07-16 at 01:32 -0500, Jonathan Nieder wrote: Thanks for writing. Your hardware is sufficiently different from Roland's that I really want this as a separate bug. We can merge them later if they turn out to have the same cause.

Bug#675302: [Bug 50571] nouveau crashes with GeForce GT 520

2012-06-16 Thread Gedalya
On 6/13/2012 9:43 PM, bugzilla-dae...@freedesktop.org wrote: If you can find the fix by bisecting, that would make me very happy. I hope I got it all right, I tried to be very careful... $ git bisect bad 4cbb0f8d2b06c72aae3552ff1a0a57814c6ce7d2 is the first bad commit commit

Bug#676866: linux-image-3.2.0-2-686-pae: won't boot under xen

2012-06-09 Thread Gedalya
Package: linux-2.6 Version: 3.2.19-1 Severity: important Dear Maintainer, * What led up to the situation? dist-upgrade, got linux 3.2.19-1 * What exactly did you do (or not do) that was effective (or ineffective)? reboot, since there's a new kernel. * What was the outcome of

Bug#675302: nouveau: hard lockup when gdm3 starts

2012-06-01 Thread Gedalya
On 6/1/2012 1:57 AM, Jonathan Nieder wrote: Worrisome. Can you send a full kernel log from booting and doing this, including the boot-up sequence? Please send it as an attachment if possible so the log doesn't get corrupted in transit (e.g. by line wrapping). Saved the log from partedmagic

Bug#675302: nouveau: hard lockup when gdm3 starts

2012-06-01 Thread Gedalya
On 6/1/2012 2:47 AM, Jonathan Nieder wrote: Ok, one more test and we should take this upstream: can you reproduce this with a 3.3.y or newer kernel from experimental? If so, please report this athttp://bugs.freedesktop.org/, product Xorg, component Driver/nouveau (yes, that's where they track

Bug#675302: nouveau: hard lockup when gdm3 starts

2012-05-31 Thread Gedalya
On 5/31/2012 2:31 AM, Jonathan Nieder wrote: Gedalya wrote: On 5/31/2012 1:59 AM, Jonathan Nieder wrote: Does starting X with the nouveau driver work if you do not start a GNOME session? (You can test by running startx xterm if the xinit package is installed.) Interesting. Still working

Bug#675302: nouveau: hard lockup when gdm3 starts

2012-05-31 Thread Gedalya
On 5/31/2012 1:59 AM, Jonathan Nieder wrote: Hi, Gedalya wrote: Tried removing the nvidia stuff and booting up with nouveau. [...] Total system hang as soon as xorg starts. No response from keyboard, mouse, no response on the network (no ping, no ARP response) [...] Using an Nvidia

Bug#675302: nouveau: hard lockup when gdm3 starts

2012-05-31 Thread Gedalya
On 5/31/2012 2:31 AM, Jonathan Nieder wrote: Hm. Might be possible to get a log with netconsole[1]. [1]http://www.kernel.org/doc/Documentation/networking/netconsole.txt http://blog.mraw.org/2010/11/08/Debugging_using_netconsole/ Now tried running startx /usr/bin/xterm with nouveau, [

Bug#675302: linux-image-3.2.0-2-amd64: system totally hands when using nouveau

2012-05-30 Thread Gedalya
Package: linux-2.6 Version: 3.2.17-1 Severity: important Dear Maintainer, * What led up to the situation? Wanted to change back from the nonfree nvidia driver to nouveau. * What exactly did you do (or not do) that was effective (or ineffective)? Tried removing the nvidia stuff and

Bug#637234: linux-image-3.0.0-1-686-pae: I/O errors using ext4 under xen (also affects ext3 as of linux-image-3.1.0-1-amd64 et al)

2012-03-04 Thread Gedalya
your dom0 to the latest kernel. I now have various wheezy domU's with barriers enabled again, running with no issues. Regards, Gedalya On 02/07/2012 05:17 AM, Timo Juhani Lindfors wrote: package linux-2.6 notfound 637234 3.0.0-3 found 637234 3.1.0-1~experimental.1 found 637234 3.1.1-1 found

Bug#637234: [Xen-devel] Re: Bug#637234: linux-image-3.0.0-1-686-pae: I/O errors using ext4 under xen

2011-08-26 Thread Gedalya
One way to make sure that is not the case is to disable barriers in the guest. Meaning in /etc/fstab have something like this: /dev/xvdc /blah ext4errors=remount-ro,barrier=0 0 1 That seems to fix it. It was remounting as read only either during the boot process or immediately

Bug#637234: linux-image-3.0.0-1-686-pae: I/O errors using ext4 under xen

2011-08-25 Thread Gedalya
Gedalya, 2.6.39-2-686-pae could be anything from v2.6.39..v2.6.39.2 please could you confirm which package version you have installed in case it makes a difference. root@mail:~# uname -a Linux mail 2.6.39-2-686-pae #1 SMP Tue Jul 5 03:48:49 UTC 2011 i686 GNU/Linux root@mail:~# dpkg -l

Bug#637234: linux-image-3.0.0-1-686-pae: I/O errors using ext4 under xen

2011-08-14 Thread Gedalya
This has already been reported here: http://www.mail-archive.com/ubuntu-server@lists.ubuntu.com/msg05621.html Generally I use lvm2 as storage backend, but I've just reproduced the exact same behavior using raw image files. I get the following exactly every other time the VM boots: [

Bug#637234: linux-image-3.0.0-1-686-pae: I/O errors using ext4 under xen

2011-08-13 Thread Gedalya
Confirmed this happens under xen, not under native hardware or vmware. Reproduced on various xen hosts with both i686-pae and amd64 kernels in DomU. On a side note: DomU doesn't come back up on a restart, it seems like it's destroyed and not recreated. Seems like this too was introduced with

Bug#637234: linux-image-3.0.0-1-686-pae: I/O errors using ext4 under xen

2011-08-09 Thread Gedalya
Package: linux-2.6 Version: 3.0.0-1 Severity: important Hello, I have a xen host running debian squeeze, amd64, some of the DomU's are running wheezy. My mail server is a DomU called mail, using ext4 for the root (and other) FS. A dist-upgrade on mail has upgraded the kernel to