Bug#1051367: More versions
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 10 executions of `xset dpms force off`, while on 6.x kernels it usually freezes on the first attempt. One thing I noticed is that most of the time, regardless of kernel version, if I hit the keyboard within the first second of the screen going black, then the screen lights up again and the system does not freeze. This issue might after all be a sign of a hardware issue - sometimes Windows that I dual-boot to seems to be similarly hung. I also used to have weird freezes at early boot time. That problem disappeared initially - when a device was plugged into a USB port, and later - seemingly without reason - disappeared altogether. However I'll keep the bug open in case some kind soul decides to share a way to work around this. Marcin
Bug#1051367: Acknowledgement (regression: powersave screen blank causes system freeze after upgrade to Debian 12)
Unfortunately it's not fixed. Looks like the probability of a freeze is just lower :-(
Bug#1051367: Acknowledgement (regression: powersave screen blank causes system freeze after upgrade to Debian 12)
Turns out this issue is already fixed in the 6.4.4-3~bpo12+1 version available in bookworm-backports \o/
Bug#1051367: Acknowledgement (regression: powersave screen blank causes system freeze after upgrade to Debian 12)
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 than anything else. Reassigning the bug. Again, I'd be more than happy to do whatever is needed to investigate this deeper. The only idea comes to mind is to try and bisect the kernel history between 5.10.179-2 and 6.1.38-4, but I'm not sure how feasible it is these days (it's been almost two decades since I last built my own kernel package and don't know what config to use between these two versions).
Bug#928121: [i915] *ERROR* rcs0: reset request timeout; intel_do_flush_locked failed: Input/output error
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 followed by "reset request timeout", together with an X server crash. At that point, systemd tries to restart the X server, but it never succeeds, each time /usr/lib/gdm3/gdm-x-session reports: "intel_do_flush_locked failed: Input/output error". The only thing that helps at that point is a reboot. All I'm running is GNOME, Firefox, Google chrome and Zoom (a proprietary video conferencing program, though during the last couple of crashes it was just running in background, not really displaying anything). A possibly important detail is that I have an external DELL U2717D monitor attached over DisplayPort in addition to the built-in display. This is a backport linux package, but apparently the next Debian release will use basically the same kernel version. I'm a little worried this unhapiness will continue for a while :-( Please do let me know whether I can do anything to help debug this. -- Package-specific info: ** Version: Linux version 4.19.0-0.bpo.2-amd64 (debian-kernel@lists.debian.org) (gcc version 6.3.0 20170516 (Debian 6.3.0-18+deb9u1)) #1 SMP Debian 4.19.16-1~bpo9+1 (2019-02-07) ** Command line: BOOT_IMAGE=/vmlinuz-4.19.0-0.bpo.2-amd64 root=/dev/mapper/beczulka--vg-root ro quiet ** Tainted: W (512) * Taint on warning. ** Kernel log: (zgrep 915 over the last few /var/log/kern.log*) [4038641.201633] i915 :00:02.0: Resetting rcs0 for hang on rcs0 [4097895.262528] i915 :00:02.0: Resetting rcs0 for hang on rcs0 [4097895.263808] [drm:gen8_reset_engines [i915]] *ERROR* rcs0: reset request timeout [4097895.263989] i915 :00:02.0: Resetting chip for hang on rcs0 [4097895.266296] [drm:gen8_reset_engines [i915]] *ERROR* rcs0: reset request timeout [4097895.375626] [drm:gen8_reset_engines [i915]] *ERROR* rcs0: reset request timeout [4097895.483621] [drm:gen8_reset_engines [i915]] *ERROR* rcs0: reset request timeout [4097895.590309] i915 :00:02.0: Failed to reset chip [4097895.591607] [drm:gen8_reset_engines [i915]] *ERROR* rcs0: reset request timeout [ 16.505146] i915 :00:02.0: enabling device (0006 -> 0007) [ 16.508667] i915 :00:02.0: vgaarb: changed VGA decodes: olddecodes=io+mem,decodes=io+mem:owns=mem [ 16.508708] i915 :00:02.0: firmware: failed to load i915/kbl_dmc_ver1_04.bin (-2) [ 16.508712] i915 :00:02.0: Direct firmware load for i915/kbl_dmc_ver1_04.bin failed with error -2 [ 16.508713] i915 :00:02.0: Failed to load DMC firmware i915/kbl_dmc_ver1_04.bin. Disabling runtime power management. [ 16.508714] i915 :00:02.0: DMC firmware homepage: https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/i915 [ 16.896879] [drm] Initialized i915 1.6.0 20180719 for :00:02.0 on minor 0 [ 16.912106] snd_hda_intel :00:1f.3: bound :00:02.0 (ops i915_audio_component_bind_ops [i915]) [ 18.499873] i915 :00:02.0: fb0: inteldrmfb frame buffer device [113350.724745] i915 :00:02.0: Resetting rcs0 for hang on rcs0 [113796.730317] i915 :00:02.0: Resetting rcs0 for hang on rcs0 [116658.722200] i915 :00:02.0: Resetting rcs0 for hang on rcs0 [180404.755657] i915 :00:02.0: Resetting rcs0 for hang on rcs0 [180404.757430] [drm:gen8_reset_engines [i915]] *ERROR* rcs0: reset request timeout [180404.757537] i915 :00:02.0: Resetting chip for hang on rcs0 [180404.761122] [drm:gen8_reset_engines [i915]] *ERROR* rcs0: reset request timeout [180404.868367] [drm:gen8_reset_engines [i915]] *ERROR* rcs0: reset request timeout [180404.976368] [drm:gen8_reset_engines [i915]] *ERROR* rcs0: reset request timeout [180405.082559] i915 :00:02.0: Failed to reset chip [180405.085348] [drm:gen8_reset_engines [i915]] *ERROR* rcs0: reset request timeout [ 21.419336] i915 :00:02.0: enabling device (0006 -> 0007) [ 21.432919] i915 :00:02.0: vgaarb: changed VGA decodes: olddecodes=io+mem,decodes=io+mem:owns=mem [ 21.432960] i915 :00:02.0: firmware: failed to load i915/kbl_dmc_ver1_04.bin (-2) [ 21.432966] i915 :00:02.0: Direct firmware load for i915/kbl_dmc_ver1_04.bin failed with error -2 [ 21.432968] i915 :00:02.0: Failed to load DMC firmware i915/kbl_dmc_ver1_04.bin. Disabling runtime power management. [ 21.432969] i915 :00:02.0: DMC firmware homepage: https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/i915 [ 21.745713] [drm] Initialized i915 1.6.0 20180719 for :00:02.0 on minor 0 [ 21.749585] snd_hda_intel :00:1f.3: bound :00:02.0 (ops i915_audio_component_bind_ops [i915]) [ 23.362631] i915 :00:02.0: fb0: inteldrmfb frame buffer device ** Model information sys_vendor: LENOVO product_name: 20L9001TUS product_version:
Bug#894089: linux-image-4.9.0-6-amd64: Please fix max supported i915 screen (not display) resolution
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.
Bug#894089: linux-image-4.9.0-6-amd64: Please fix max supported i915 screen (not display) resolution
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 8960x2880)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 59231312c4e0..5e94163077e1 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -16457,9 +16457,12 @@ int intel_modeset_init(struct drm_device *dev)
} else if (IS_GEN3(dev_priv)) {
dev->mode_config.max_width = 4096;
dev->mode_config.max_height = 4096;
- } else {
+ } else if (IS_GEN4(dev_priv) || IS_GEN5(dev_priv) ||
IS_GEN6(dev_priv)) {
dev->mode_config.max_width = 8192;
dev->mode_config.max_height = 8192;
+ } else {
+ dev->mode_config.max_width = 16384;
+ dev->mode_config.max_height = 16384;
}
if (IS_845G(dev_priv) || IS_I865G(dev_priv)) {
Patch from
https://www.reddit.com/r/linux/comments/6bghzm/increasing_maximum_xorg_virtual_screen_resolution/
-- Package-specific info:
** Version:
Linux version 4.9.0-6-amd64 (debian-kernel@lists.debian.org) (gcc version
6.3.0 20170516 (Debian 6.3.0-18+deb9u1) ) #1 SMP Debian 4.9.82-1+deb9u3
(2018-03-02)
** Command line:
BOOT_IMAGE=/vmlinuz-4.9.0-6-amd64 root=/dev/mapper/beczulka--vg-root ro
quiet
** Tainted: O (4096)
* Out-of-tree module has been loaded.
** Kernel log:
[248016.585805] IPv6: ADDRCONF(NETDEV_UP): wlp4s0: link is not ready
[248171.894464] IPv6: ADDRCONF(NETDEV_UP): wlp4s0: link is not ready
[248172.002961] wlp4s0: authenticate with f4:f2:6d:de:d5:18
[248172.013554] wlp4s0: send auth to f4:f2:6d:de:d5:18 (try 1/3)
[248172.085251] wlp4s0: send auth to f4:f2:6d:de:d5:18 (try 2/3)
[248172.147040] wlp4s0: send auth to f4:f2:6d:de:d5:18 (try 3/3)
[248172.209781] wlp4s0: authentication with f4:f2:6d:de:d5:18 timed out
[248197.525015] IPv6: ADDRCONF(NETDEV_UP): wlp4s0: link is not ready
[248197.550377] IPv6: ADDRCONF(NETDEV_UP): wlp4s0: link is not ready
[248395.942863] IPv6: ADDRCONF(NETDEV_UP): wlp4s0: link is not ready
[248396.023748] wlp4s0: authenticate with f4:f2:6d:de:d5:18
[248396.032143] wlp4s0: send auth to f4:f2:6d:de:d5:18 (try 1/3)
[248396.107564] wlp4s0: send auth to f4:f2:6d:de:d5:18 (try 2/3)
[248396.159524] wlp4s0: send auth to f4:f2:6d:de:d5:18 (try 3/3)
[248396.221695] wlp4s0: authentication with f4:f2:6d:de:d5:18 timed out
[248421.595868] IPv6: ADDRCONF(NETDEV_UP): wlp4s0: link is not ready
[248421.611726] IPv6: ADDRCONF(NETDEV_UP): wlp4s0: link is not ready
[248492.951789] IPv6: ADDRCONF(NETDEV_UP): wlp4s0: link is not ready
[248493.025828] wlp4s0: authenticate with f4:f2:6d:de:d5:18
[248493.036767] wlp4s0: send auth to f4:f2:6d:de:d5:18 (try 1/3)
[248493.111697] wlp4s0: send auth to f4:f2:6d:de:d5:18 (try 2/3)
[248493.177987] wlp4s0: send auth to f4:f2:6d:de:d5:18 (try 3/3)
[248493.231629] wlp4s0: authentication with f4:f2:6d:de:d5:18 timed out
[248518.392729] wlp4s0: authenticate with f4:f2:6d:de:d5:18
[248518.402419] wlp4s0: send auth to f4:f2:6d:de:d5:18 (try 1/3)
[248518.468811] wlp4s0: send auth to f4:f2:6d:de:d5:18 (try 2/3)
[248518.514630] wlp4s0: send auth to f4:f2:6d:de:d5:18 (try 3/3)
[248518.516782] wlp4s0: aborting authentication with f4:f2:6d:de:d5:18 by
local choice (Reason: 3=DEAUTH_LEAVING)
[248518.529291] IPv6: ADDRCONF(NETDEV_UP): wlp4s0: link is not ready
[248518.552009] IPv6: ADDRCONF(NETDEV_UP): wlp4s0: link is not ready
[248818.541968] IPv6: ADDRCONF(NETDEV_UP): wlp4s0: link is not ready
[248819.526062] wlp4s0: authenticate with f4:f2:6d:de:d5:18
[248819.537268] wlp4s0: send auth to f4:f2:6d:de:d5:18 (try 1/3)
[248819.592445] wlp4s0: send auth to f4:f2:6d:de:d5:18 (try 2/3)
[248819.656363] wlp4s0: send auth to f4:f2:6d:de:d5:18 (try 3/3)
[248819.713262] wlp4s0: authentication with f4:f2:6d:de:d5:18 timed out
[248833.143991] wlp4s0: authenticate with f4:f2:6d:de:d5:18
[248833.152942] wlp4s0: send auth to f4:f2:6d:de:d5:18 (try 1/3)
[248833.219390] wlp4s0: send auth to f4:f2:6d:de:d5:18 (try 2/3)
[248833.280352] wlp4s0: send auth to f4:f2:6d:de:d5:18 (try 3/3)
[248833.326311] wlp4s0: authentication with f4:f2:6d:de:d5:18 timed out
[248843.520536] IPv6: ADDRCONF(NETDEV_UP): wlp4s0: link is not ready
[248843.608568] IPv6: ADDRCONF(NETDEV_UP): wlp4s0: link is not ready
[248843.664294] IPv6: ADDRCONF(NETDEV_UP): wlp4s0: link is not ready
[248844.469060] wlp4s0: authenticate with f4:f2:6d:de:d5:18
[248844.478301] wlp4s0: send auth to f4:f2:6d:de:d5:18 (try 1/3)
[248844.536858] wlp4s0: send auth to f4:f2:6d:de:d5:18 (try 2/3)
[248844.593867] wlp4s0: send auth to f4:f2:6d:de:d5:18 (try 3/3)
[248844.640307] wlp4s0: authentication with f4:f2:6d:de:d5:18 timed out
[248861.396446] wlp4s0: authenticate with f4:f2:6d:de:d5:18
[248861.405285] wlp4s0: send
Bug#550739: Wrong SIOCSIWENCODEEXT return code when crypto module not loaded
Package: linux-2.6 Version: 2.6.30-7 Here is a relevant fragment from http://bugs.debian.org/506223 about the problem. 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 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 de 32 41 70 ef ea 9e 2f ce 1c ef b5 48 52 32 f8 00 00 WPA: Installing PTK to the driver. wpa_driver_wext_set_key: alg=3 key_idx=0 set_tx=1 seq_len=6 key_len=16 ioctl[SIOCSIWENCODEEXT]: Cannot allocate memory [...] This indicates that the mac80211 code was unable to set up the AES encryption/decryption state for WPA. Excluding the unlikely case that the system is really out of memory, this means that the 'aes' module is not available. 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 3A0D 8AA0 60F4 1216 -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#506223: I can confirm that
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 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 de 32 41 70 ef ea 9e 2f ce 1c ef b5 48 52 32 f8 00 00 WPA: Installing PTK to the driver. wpa_driver_wext_set_key: alg=3 key_idx=0 set_tx=1 seq_len=6 key_len=16 ioctl[SIOCSIWENCODEEXT]: Cannot allocate memory [...] This indicates that the mac80211 code was unable to set up the AES encryption/decryption state for WPA. Excluding the unlikely case that the system is really out of memory, this means that the 'aes' module is not available. Please try adding that to your installation image. I'm assuming you mean the 'aes' kernel module? Could you be a bit more specific? Filename, package name, perhaps an udeb name if there is one? -- Marcin Owsiany porri...@debian.org http://marcin.owsiany.pl/ GnuPG: 1024D/60F41216 FE67 DA2D 0ACA FC5E 3F75 D6F6 3A0D 8AA0 60F4 1216 -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#506223: I can confirm that
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 - 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 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 de 32 41 70 ef ea 9e 2f ce 1c ef b5 48 52 32 f8 00 00 WPA: Installing PTK to the driver. wpa_driver_wext_set_key: alg=3 key_idx=0 set_tx=1 seq_len=6 key_len=16 ioctl[SIOCSIWENCODEEXT]: Cannot allocate memory [...] This indicates that the mac80211 code was unable to set up the AES encryption/decryption state for WPA. Excluding the unlikely case that the system is really out of memory, this means that the 'aes' module is not available. Please try adding that to your installation image. I'm assuming you mean the 'aes' kernel module? Could you be a bit more specific? Filename, package name, perhaps an udeb name if there is one? aes.ko in the kernel image package for the kernel you're using. I cannot find such file: http://packages.debian.org/search?suite=sidarch=i386mode=pathsearchon=contentskeywords=aes.ko Could it be that it's normally built in? Or that the package search is broken/stale? -- Marcin Owsiany porri...@debian.org http://marcin.owsiany.pl/ GnuPG: 1024D/60F41216 FE67 DA2D 0ACA FC5E 3F75 D6F6 3A0D 8AA0 60F4 1216 -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#506223: I can confirm that
On Sun, Oct 11, 2009 at 03:50:53PM +0100, Ben Hutchings wrote: This indicates that the mac80211 code was unable to set up the AES encryption/decryption state for WPA. Excluding the unlikely case that the system is really out of memory, this means that the 'aes' module is not available. Please try adding that to your installation image. 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 into a more meaningful error message? As for the card driver, it seems to work much 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 D6F6 3A0D 8AA0 60F4 1216 -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#506223: I can confirm that
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 into a more meaningful error message? No, the kernel is returning the wrong error code. Ouch. How about a bug report against the kernel, then? You might consider filing a bug against debian-installer to request that aes_generic (and any other crypto modules possibly needed for WPA) be included. They are included, in the sense that a crypto-modules udeb is made available for selection when loading components. I'm sure that they would be auto-installed if a wpasupplicant udeb was made available, but without one it does not make sense to install them by default. regards, -- Marcin Owsiany porri...@debian.org http://marcin.owsiany.pl/ GnuPG: 1024D/60F41216 FE67 DA2D 0ACA FC5E 3F75 D6F6 3A0D 8AA0 60F4 1216 -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#506223: I can confirm that
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%, but it's still a far cry from what the card can achieve. It works just fine using ndiswrapper... Has this been fixed in later kernels like the 2.6.30 from unstable or backports.org? There have been many changes since the Lenny kernel. I could try if there is a live CD that would let me test it. I'd rather not reinstall with unstable/testing since this machine needs to stay stable. -- Marcin Owsiany porri...@debian.org http://marcin.owsiany.pl/ GnuPG: 1024D/60F41216 FE67 DA2D 0ACA FC5E 3F75 D6F6 3A0D 8AA0 60F4 1216 -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#506223: I can confirm that
I just wiped my etch installation and replaced it with a fresh lenny installation. The installer auto-detected my wifi card and used the rt2500pci driver. By default it achieves: - 1Mbps rate (as reported by iwconfig - I can only download at max. ~20KBps) - approx 50% link quality 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%, but it's still a far cry from what the card can achieve. It works just fine using ndiswrapper... -- Marcin Owsiany porri...@debian.org http://marcin.owsiany.pl/ GnuPG: 1024D/60F41216 FE67 DA2D 0ACA FC5E 3F75 D6F6 3A0D 8AA0 60F4 1216 -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#422819: Call trace
Another call trace, not sure if it's useful, but I guess it's better to have too much information than to little. [ cut here ] kernel BUG at drivers/xen/core/evtchn.c:481! invalid opcode: [#1] SMP Modules linked in: xt_tcpudp xt_physdev iptable_filter ip_tables x_tables bridge netloop ipv6 ext3 jbd mbcache loop parport_pc shpchp parport pci_hotplug serial_core rtc psmouse i2c_piix4 pcspkr floppy serio_raw sworks_agp i2c_core agpgart evdev xfs dm_mirror dm_snapshot dm_mod ide_generic sd_mod ide_cd cdrom e100 mii aacraid scsi_mod serverworks generic ide_core thermal processor fan CPU:1 EIP:0061:[c020c14a]Not tainted VLI EFLAGS: 00010046 (2.6.18-4-xen-686 #1) EIP is at retrigger+0x1f/0x35 eax: ebx: 0208 ecx: 001c edx: f55f6000 esi: c0318520 edi: 010d ebp: esp: c0e85eb0 ds: 007b es: 007b ss: 0069 Process xenwatch (pid: 11, ti=c0e84000 task=c0eb8000 task.ti=c0e84000) Stack: c013b259 c0318520 010d c0318548 c013afaf c8a462c0 c8a462c0 c02170f0 c02174d0 c021065f 0010 020b 020a cfbbafd5 c02e67a4 d11fc000 0002 Call Trace: [c013b259] check_irq_resend+0x41/0x48 [c013afaf] enable_irq+0x72/0x87 [c02170f0] __netif_up+0xb/0x13 [c02174d0] netif_map+0x247/0x26f [c021065f] xs_talkv+0xe3/0x128 [c02109a8] xenbus_read+0x34/0x3b [c0210d6a] xenbus_scanf+0x18/0x4d [c0216b61] frontend_changed+0x29f/0x4a8 [c0211d48] otherend_changed+0x74/0x79 [c02104e2] xenwatch_handle_callback+0x12/0x44 [c0210f27] xenwatch_thread+0x105/0x11b [c012b6e5] autoremove_wake_function+0x0/0x2d [c0210e22] xenwatch_thread+0x0/0x11b [c012b619] kthread+0xc0/0xeb [c012b559] kthread+0x0/0xeb [c010293d] 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 PROTECTED] http://marcin.owsiany.pl/ GnuPG: 1024D/60F41216 FE67 DA2D 0ACA FC5E 3F75 D6F6 3A0D 8AA0 60F4 1216 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#426360: Need xen on non-pae machine
Package: linux-2.6 Version: 2.6.18.dfsg.1-12 How surprised I was after booting linux-image-2.6.18-4-xen-686 that it does not like my CPU. processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 13 model name : Intel(R) Celeron(R) M processor 1.30GHz stepping: 6 cpu MHz : 1300.000 cache size : 1024 KB fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr mce cx8 apic sep mtrr pge mca cmov pat clflush dts acpi mmx fxsr sse sse2 ss tm pbe up bogomips: 2597.16 Obviously it's not a production machine, but I need to do xen-related development on this laptop (not xen itself, but various things around it). I can see there is a non-pae hypervisor available, 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, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#418757: information about aacraid missing from /proc
Package: linux-2.6 Version: 2.6.18.dfsg.1-12 Tags: patch Looks like change of behavior of newer GCCs triggered a bug which causes the /proc/scsi/aacraid directory tree (which I understand contains information useful to array monitoring) not to appear. Please see the following link 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 DA2D 0ACA FC5E 3F75 D6F6 3A0D 8AA0 60F4 1216 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Wrong libc6 recommendation by -xen kernel?
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] http://marcin.owsiany.pl/ GnuPG: 1024D/60F41216 FE67 DA2D 0ACA FC5E 3F75 D6F6 3A0D 8AA0 60F4 1216 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#320042: conflicting files with kernel-doc-2.6.11
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 linked to /bin/bash Kernel: Linux 2.6.12-1-686 Locale: LANG=pl_PL, LC_CTYPE=pl_PL (charmap=ISO-8859-2) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#311820: ioctl(fd, SIOCGMIIPHY,...) causes hard freeze before first ifconfig up
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 ifconfig eth0 up run causes the system to freeze (HW reset required). It also seems that if I skip the mii-tool eth0 on bootup, it freezes later when starting up exim4, although I did not investigate that exim4 case. Stracing mii-tool revealed that the system freezes during the ioctl call: socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 3 ioctl(3, SIOCGMIIREG, the call never returns. However bringing the interface up before, makes mii-tool run OK. Also bringing it up and down again makes mii-tool run OK. It looks like something gets initialized in the kernel only on ifconfig up, and running mii-tool before that makes the system go into some kind of infinite loop. I'm using Broadcom 4400 10/100BaseT NIC on HP/Compaq nx6110 I'll submit a dmesg and othe stuff as a followup once I get this laptop online. (I'm submitting this bug from a different machine). Marcin -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.11-1-k7 Locale: LANG=pl_PL, LC_CTYPE=pl_PL (charmap=ISO-8859-2) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#311820: More information
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:34:54 UTC 2005 BIOS-provided physical RAM map: BIOS-e820: - 0009fc00 (usable) BIOS-e820: 0009fc00 - 000a (reserved) BIOS-e820: 000e - 0010 (reserved) BIOS-e820: 0010 - 1f7d (usable) BIOS-e820: 1f7d - 1f7efc00 (reserved) BIOS-e820: 1f7efc00 - 1f7fb000 (ACPI NVS) BIOS-e820: 1f7fb000 - 1f80 (reserved) BIOS-e820: e000 - f000 (reserved) BIOS-e820: fec0 - fec02000 (reserved) BIOS-e820: fed2 - fed9b000 (reserved) BIOS-e820: feda - fedc (reserved) BIOS-e820: ffb0 - ffc0 (reserved) BIOS-e820: fff0 - 0001 (reserved) 0MB HIGHMEM available. 503MB LOWMEM available. On node 0 totalpages: 128976 DMA zone: 4096 pages, LIFO batch:1 Normal zone: 124880 pages, LIFO batch:16 HighMem zone: 0 pages, LIFO batch:1 DMI 2.3 present. Allocating PCI resources starting at 1f80 (gap: 1f80:c080) Built 1 zonelists Kernel command line: auto BOOT_IMAGE=Linux-noacpi ro root=302 pnpbios=off acpi=off Found and enabled local APIC! mapped APIC to d000 (fec01000) Initializing CPU#0 PID hash table entries: 2048 (order: 11, 32768 bytes) Detected 1296.890 MHz processor. Using tsc for high-res timesource Console: colour VGA+ 80x25 Dentry cache hash table entries: 65536 (order: 6, 262144 bytes) Inode-cache hash table entries: 32768 (order: 5, 131072 bytes) Memory: 503608k/515904k available (1629k kernel code, 11800k reserved, 716k data, 172k init, 0k highmem) Checking if this processor honours the WP bit even in supervisor mode... Ok. Calibrating delay loop... 2547.71 BogoMIPS (lpj=1273856) Security Framework v1.0.0 initialized SELinux: Disabled at boot. Mount-cache hash table entries: 512 (order: 0, 4096 bytes) CPU: After generic identify, caps: afe9fbbf CPU: After vendor identify, caps: afe9fbbf CPU: L1 I cache: 32K, L1 D cache: 32K CPU: L2 cache: 1024K CPU: After all inits, caps: afe9fbbf 0040 Intel machine check architecture supported. Intel machine check reporting enabled on CPU#0. CPU: Intel(R) Celeron(R) M processor 1.30GHz stepping 06 Enabling fast FPU save and restore... done. Enabling unmasked SIMD FPU exception support... done. Checking 'hlt' instruction... OK. checking if image is initramfs...it isn't (bad gzip magic numbers); looks like an initrd Freeing initrd memory: 4592k freed NET: Registered protocol family 16 PCI: PCI BIOS revision 2.10 entry at 0xf0322, last bus=3 PCI: Using configuration type 1 mtrr: v2.0 (20020519) ACPI: Subsystem revision 20050211 ACPI: Interpreter disabled. Linux Plug and Play Support v0.97 (c) Adam Belay pnp: PnP ACPI: disabled PnPBIOS: Disabled PCI: Probing PCI hardware PCI: Probing PCI hardware (bus 00) PCI: Ignoring BAR0-3 of IDE controller :00:1f.1 PCI: Transparent bridge - :00:1e.0 PCI: Discovered primary peer bus 10 [IRQ] PCI: Using IRQ router PIIX/ICH [8086/2641] at :00:1f.0 VFS: Disk quotas dquot_6.5.1 Dquot-cache hash table entries: 1024 (order 0, 4096 bytes) devfs: 2004-01-31 Richard Gooch ([EMAIL PROTECTED]) devfs: boot_options: 0x0 Initializing Cryptographic API isapnp: Scanning for PnP cards... isapnp: No Plug Play device found i8042.c: Detected active multiplexing controller, rev 1.1. serio: i8042 AUX0 port at 0x60,0x64 irq 12 serio: i8042 AUX1 port at 0x60,0x64 irq 12 serio: i8042 AUX2 port at 0x60,0x64 irq 12 serio: i8042 AUX3 port at 0x60,0x64 irq 12 serio: i8042 KBD port at 0x60,0x64 irq 1 Serial: 8250/16550 driver $Revision: 1.90 $ 48 ports, IRQ sharing enabled PCI: Found IRQ 10 for device :00:1e.3 PCI: Sharing IRQ 10 with :00:1d.1 io scheduler noop registered io scheduler anticipatory registered io scheduler deadline registered io scheduler cfq registered RAMDISK driver initialized: 16 RAM disks of 8192K size 1024 blocksize input: AT Translated Set 2 keyboard on isa0060/serio0 NET: Registered protocol family 2 IP: routing cache hash table of 4096 buckets, 32Kbytes TCP established hash table entries: 16384 (order: 5, 131072 bytes) TCP bind hash table entries: 16384 (order: 4, 65536 bytes) TCP: Hash tables configured (established 16384 bind 16384) NET: Registered protocol family 8 NET: Registered protocol family 20 RAMDISK: cramfs filesystem found at block 0 RAMDISK: Loading 4592KiB [1 disk] into ram disk
Bug#310931: kacpid hogs CPU on HP/Compaq nx6110
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 shown by top), causing the whole system to become very slow and seriously decreasing its responsiveness. Sometimes even the load generated by system boot is sufficient, and kacpid starts to hog the CPU during bootup, which makes it very slow. Killing the load-generating task does not cause kacpid to release the CPU (I waited over half an hour). Specifying acpi=off eliminates the problem, but obviously is not a solution, since the machine does not seem to provide APM interface (modprobing apm says no such device or address), so I'm not even able to monitor battery status. :-/ Attached: a dmesg dump (though no messages are generated when kacpid goes crazy). Google returns some similar cases on kacpid cpu, but finds no fix. I would happily help with debugging this problem, since I'm not using this computer intensively. Just give me some suggestions / instructions / pointers / references :-) regards, Marcin -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.11-1-k7 Locale: LANG=pl_PL, LC_CTYPE=pl_PL (charmap=ISO-8859-2) 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:34:54 UTC 2005 BIOS-provided physical RAM map: BIOS-e820: - 0009fc00 (usable) BIOS-e820: 0009fc00 - 000a (reserved) BIOS-e820: 000e - 0010 (reserved) BIOS-e820: 0010 - 1f7d (usable) BIOS-e820: 1f7d - 1f7efc00 (reserved) BIOS-e820: 1f7efc00 - 1f7fb000 (ACPI NVS) BIOS-e820: 1f7fb000 - 1f80 (reserved) BIOS-e820: e000 - f000 (reserved) BIOS-e820: fec0 - fec02000 (reserved) BIOS-e820: fed2 - fed9b000 (reserved) BIOS-e820: feda - fedc (reserved) BIOS-e820: ffb0 - ffc0 (reserved) BIOS-e820: fff0 - 0001 (reserved) 0MB HIGHMEM available. 503MB LOWMEM available. On node 0 totalpages: 128976 DMA zone: 4096 pages, LIFO batch:1 Normal zone: 124880 pages, LIFO batch:16 HighMem zone: 0 pages, LIFO batch:1 DMI 2.3 present. ACPI: RSDP (v000 HP) @ 0x000fe270 ACPI: RSDT (v001 HP 099C 0x21120420 HP 0x0001) @ 0x1f7efc84 ACPI: FADT (v002 HP 099C 0x0002 HP 0x0001) @ 0x1f7efc00 ACPI: MADT (v001 HP 099C 0x0001 HP 0x0001) @ 0x1f7efcb4 ACPI: MCFG (v001 HP 099C 0x0001 HP 0x0001) @ 0x1f7efd10 ACPI: DSDT (v001 HP DAU00 0x0001 MSFT 0x010e) @ 0x ACPI: PM-Timer IO Port: 0x1008 ACPI: Local APIC address 0xfec01000 ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled) Processor #0 6:13 APIC version 20 ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1]) ACPI: IOAPIC (id[0x01] address[0xfec0] gsi_base[0]) IOAPIC[0]: apic_id 1, version 32, address 0xfec0, GSI 0-23 ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) ACPI: IRQ0 used by override. ACPI: IRQ2 used by override. ACPI: IRQ9 used by override. Enabling APIC mode: Flat. Using 1 I/O APICs Using ACPI (MADT) for SMP configuration information Allocating PCI resources starting at 1f80 (gap: 1f80:c080) Built 1 zonelists Kernel command line: BOOT_IMAGE=Linux ro root=302 pnpbios=off single mapped APIC to d000 (fec01000) mapped IOAPIC to c000 (fec0) Initializing CPU#0 PID hash table entries: 2048 (order: 11, 32768 bytes) Detected 1297.275 MHz processor. Using pmtmr for high-res timesource Console: colour VGA+ 80x25 Dentry cache hash table entries: 65536 (order: 6, 262144 bytes) Inode-cache hash table entries: 32768 (order: 5, 131072 bytes) Memory: 503608k/515904k available (1629k kernel code, 11800k reserved, 716k data, 172k init, 0k highmem) Checking if this processor honours the WP bit even in supervisor mode... Ok. Calibrating delay loop... 2555.90 BogoMIPS (lpj=1277952) Security Framework v1.0.0 initialized SELinux: Disabled at boot. Mount-cache hash table entries: 512 (order: 0, 4096 bytes) CPU: After generic identify, caps: afe9fbbf CPU: After vendor identify, caps: afe9fbbf CPU: L1 I cache: 32K, L1 D cache: 32K CPU: L2 cache: 1024K CPU: After all inits, caps: afe9fbbf 0040 Intel machine check architecture supported. Intel machine check reporting enabled on
