found 5.10.197-1
thanks
Yesterday I installed and tested a dozen or so kernel images from
snapshot.debian.org starting with 5.10.197-1 and ending with
6.4.4-3~bpo12+1. Unfortunately I was able to reproduce the issue on every
single one of them, although with older versions it usually takes around
Unfortunately it's not fixed. Looks like the probability of a freeze is
just lower :-(
Turns out this issue is already fixed in the 6.4.4-3~bpo12+1 version
available in bookworm-backports \o/
Today I switched to an Xorg-based GNOME session, and found out that
invoking `xset dpms force off` also results in the system freezing.
Interestingly, the system was responsive via ssh for another couple seconds
or so.
So I think this regression must be related to the kernel version change
more
Package: src:linux
Version: 4.19.16-1~bpo9+1
Severity: important
Every couple of weeks or so my laptop experiences some graphics-related crash.
As you can see from the log below, sometimes there is just a single "Resetting
rcs0 for hang on rcs0" from which it recovers, while at other times it is
Thank you for the contact, Ben. I will follow up with them.
FWIW, this patch does not even seem to work properly. While it does change
the max supported size reported by xrandr, trying to use the space just
results in an error.
Package: src:linux
Version: 4.9.82-1+deb9u3
Severity: normal
Dear Maintainer,
The i915 driver needs the following patch to allow the actually
supported X screen size of more recent chips. Currently one gets:
$ xrandr --fb 8960x2880
xrandr: screen cannot be larger than 8192x8192 (desired size
. Please try adding that to your installation image.
This made it difficult to set up WPA-based networking, as the error message
does not point in the right direction.
--
Marcin Owsiany porri...@debian.org http://marcin.owsiany.pl/
GnuPG: 1024D/60F41216 FE67 DA2D 0ACA FC5E 3F75 D6F6
On Sun, Oct 11, 2009 at 03:50:53PM +0100, Ben Hutchings wrote:
On Sun, 2009-10-11 at 14:44 +0100, Marcin Owsiany wrote:
WPA: Sending EAPOL-Key 4/4
WPA: TX EAPOL-Key - hexdump(len=99): 01 03 00 5f 02 03 0a 00 00 00 00 00 00
00 00 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
On Sun, Oct 11, 2009 at 05:03:53PM +0100, Ben Hutchings wrote:
On Sun, 2009-10-11 at 16:08 +0100, Marcin Owsiany wrote:
On Sun, Oct 11, 2009 at 03:50:53PM +0100, Ben Hutchings wrote:
On Sun, 2009-10-11 at 14:44 +0100, Marcin Owsiany wrote:
WPA: Sending EAPOL-Key 4/4
WPA: TX EAPOL-Key
better in 2.6.30, I was
able to achieve sustained 7Mbps transfer which I think was as much as I
ever managed to achieve on this network.
I guess this bug can be closed.
--
Marcin Owsiany porri...@debian.org http://marcin.owsiany.pl/
GnuPG: 1024D/60F41216 FE67 DA2D 0ACA FC5E 3F75
On Sun, Oct 11, 2009 at 07:10:47PM +0100, Ben Hutchings wrote:
On Sun, 2009-10-11 at 18:36 +0100, Marcin Owsiany wrote:
Indeed, loading aes_generic before running wpa_supplicant made it work
just fine! Does it make sense to file a bug against wpasupplicant
asking for this to be turned
On Fri, Aug 21, 2009 at 06:50:13PM +0200, Moritz Muehlenhoff wrote:
On Thu, Feb 19, 2009 at 09:10:47PM +, Marcin Owsiany wrote:
When I manually set it to rate 11M, the reported bit rate goes to 11M,
the real download speed improves by about 50% and the link quality
goes to about 70
manually set it to rate 11M, the reported bit rate goes to 11M,
the real download speed improves by about 50% and the link quality
goes to about 70%, but it's still a far cry from what the card can
achieve.
It works just fine using ndiswrapper...
--
Marcin Owsiany porri...@debian.org
] kernel_thread_helper+0x5/0xb
Code: ee 85 f6 75 96 58 5a 5b 5e 5f 5d c3 0f b7 0c 85 40 b8 37 c0 8b 15 84 19
2d c0 85 c9 74 1d 0f a3 8a 80 08 00 00 19 c0 85 c0 75 08 0f 0b e1 01 b2 1a 2b
c0 f0 0f ab 8a 00 08 00 00 b8 01 00 00 00
EIP: [c020c14a] retrigger+0x1f/0x35 SS:ESP 0069:c0e85eb0
--
Marcin Owsiany [EMAIL
, but no matching
kernel for it. Please don't make me build my own kernel! The last time I
had to do it was, like, 4 years ago! :-)
--
Marcin Owsiany [EMAIL PROTECTED] http://marcin.owsiany.pl/
GnuPG: 1024D/60F41216 FE67 DA2D 0ACA FC5E 3F75 D6F6 3A0D 8AA0 60F4 1216
--
To UNSUBSCRIBE
for an explanation and a patch.
http://lists.us.dell.com/pipermail/linux-poweredge/2007-January/029281.html
I wonder if this could still make it into etch with the other fixes for
kernel that were mentioned.
--
Marcin Owsiany [EMAIL PROTECTED] http://marcin.owsiany.pl/
GnuPG: 1024D/60F41216 FE67
Hi,
linux-image-2.6.16-1-xen-686 2.6.16-12 recommends libc6-i686, while
there is a special (nosegneg) libc6-xen available, which conflicts with
the -i686 one.
Is the recommendation by kernel package a mistake, or has libc6-i686
been made xen-friendly?
Marcin
--
Marcin Owsiany [EMAIL PROTECTED
Package: linux-doc-2.6.12
Version: 2.6.12-1
Severity: important
dpkg reports that /usr/share/man/man9/wanbook.9 is also in
kernel-doc-2.6.11
-- System Information:
Debian Release: testing/unstable
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: i386 (i686)
Shell: /bin/sh
Package: kernel-image-2.6.11-1-686
Version: 2.6.11-5
Severity: normal
I was experimenting with ifupdown's mapping feature to autodetect the
network my laptop is connected currently before bringing the interface
up, and have found the following problem:
Invoking mii-tool eth0 before the first
Here's some more system information.
Marcin
--
Marcin Owsiany [EMAIL PROTECTED] http://marcin.owsiany.pl/
GnuPG: 1024D/60F41216 FE67 DA2D 0ACA FC5E 3F75 D6F6 3A0D 8AA0 60F4 1216
Linux version 2.6.11-1-686 ([EMAIL PROTECTED]) (gcc version 3.3.6 (Debian
1:3.3.6-5)) #1 Fri May 20 07
Package: kernel-image-2.6.11-1-686
Version: 2.6.11-5
Severity: normal
Shortly (it's hard to measure, but seems a few seconds) after applying
some load on the system (like find / -type f|xargs cat|gzip -c|gzip
-dc|gzip -c /dev/null), the kacpid thread alone suddenly starts using
99.9% CPU (as
22 matches
Mail list logo
