Bug#438736: intel driver produces kernel crash in a variety of situations
On Mon, Aug 20, 2007 at 12:21:12AM +0200, Cesare Leonardi wrote: > Robert Millan wrote: > >I've recently upgraded my hardware (motherboard + cpu + ram) and am now > >getting Linux crashes in a variety of situations. I've detected them > >when any of the following conditions are met: > > > > - When starting a second X session. > > - When time goes backwards (e.g. due to ntpdate) while X is running (but > >NOT when X isn't running) > > - When stopping X. > > [...] > > > - X driver is xserver-xorg-video-i810. Card model: > > Are you sure this is a kernel bug? Well, since X is a userland process, I wouldn't expect it to be able to crash the kernel, even if it plays with /dev/agpgart in a bad way. It can even be a security issue. > I see that the constant is that crashes happen when X is running (or > when is finishing running). > You are using xserver-xorg-video-i810, but since some months this is a > transitional package that points to the newer (and less stable) > xserver-xorg-video-intel. > Since this transition i had noticed numerous crash (and various problems > using video applications, but these seems to be resolved), and reading > some bug reports seems that this driver still has different problems on > which Intel is working on. > I suggest you to look at: > http://bugs.debian.org/xserver-xorg-video-intel Yes, I've seen those reports. That's why I holded on backporting the driver from testing/sid to my etch system. > In the meanwhile try to use the generic vesa driver to see if the > crashes still happens. If they will not occur anymore, you can try with > the intel driver from unstable or experimental. > If they'll persists... this could be a kernel bug. ;-) Do you know if Linux had improvements in this area from 2.6.18 to 2.6.22 ? -- Robert Millan I know my rights; I want my phone call! What use is a phone call, if you are unable to speak? (as seen on /.) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
[bts-link] source package linux-2.6
# # bts-link upstream status pull for source package linux-2.6 # see http://lists.debian.org/debian-devel-announce/2006/05/msg1.html # user [EMAIL PROTECTED] # remote status report for #309964 # * http://bugzilla.kernel.org/show_bug.cgi?id=5084 # * remote status changed: ASSIGNED -> NEEDINFO # * closed upstream tags 309964 + fixed-upstream usertags 309964 - status-ASSIGNED usertags 309964 + status-NEEDINFO # remote status report for #321403 # * http://bugzilla.kernel.org/show_bug.cgi?id=4773 # * remote status changed: ASSIGNED -> NEEDINFO # * closed upstream tags 321403 + fixed-upstream usertags 321403 - status-ASSIGNED usertags 321403 + status-NEEDINFO thanks
Processed: [bts-link] source package linux-2.6
Processing commands for [EMAIL PROTECTED]: > # > # bts-link upstream status pull for source package linux-2.6 > # see http://lists.debian.org/debian-devel-announce/2006/05/msg1.html > # > user [EMAIL PROTECTED] Setting user to [EMAIL PROTECTED] (was [EMAIL PROTECTED]). > # remote status report for #309964 > # * http://bugzilla.kernel.org/show_bug.cgi?id=5084 > # * remote status changed: ASSIGNED -> NEEDINFO > # * closed upstream > tags 309964 + fixed-upstream Bug#309964: "drive appears confused (ireason = 0x01)" and linux hangs There were no tags set. Tags added: fixed-upstream > usertags 309964 - status-ASSIGNED Bug#309964: "drive appears confused (ireason = 0x01)" and linux hangs Usertags were: status-ASSIGNED. Usertags are now: . > usertags 309964 + status-NEEDINFO Bug#309964: "drive appears confused (ireason = 0x01)" and linux hangs There were no usertags set. Usertags are now: status-NEEDINFO. > # remote status report for #321403 > # * http://bugzilla.kernel.org/show_bug.cgi?id=4773 > # * remote status changed: ASSIGNED -> NEEDINFO > # * closed upstream > tags 321403 + fixed-upstream Bug#321403: 8139too network driver won't work with my card (it did with 2.6.8) Tags were: patch upstream Tags added: fixed-upstream > usertags 321403 - status-ASSIGNED Bug#321403: 8139too network driver won't work with my card (it did with 2.6.8) Usertags were: status-ASSIGNED. Usertags are now: . > usertags 321403 + status-NEEDINFO Bug#321403: 8139too network driver won't work with my card (it did with 2.6.8) There were no usertags set. Usertags are now: status-NEEDINFO. > thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#438736: intel driver produces kernel crash in a variety of situations
Robert Millan wrote: I've recently upgraded my hardware (motherboard + cpu + ram) and am now getting Linux crashes in a variety of situations. I've detected them when any of the following conditions are met: - When starting a second X session. - When time goes backwards (e.g. due to ntpdate) while X is running (but NOT when X isn't running) - When stopping X. [...] - X driver is xserver-xorg-video-i810. Card model: Are you sure this is a kernel bug? I see that the constant is that crashes happen when X is running (or when is finishing running). You are using xserver-xorg-video-i810, but since some months this is a transitional package that points to the newer (and less stable) xserver-xorg-video-intel. Since this transition i had noticed numerous crash (and various problems using video applications, but these seems to be resolved), and reading some bug reports seems that this driver still has different problems on which Intel is working on. I suggest you to look at: http://bugs.debian.org/xserver-xorg-video-intel In the meanwhile try to use the generic vesa driver to see if the crashes still happens. If they will not occur anymore, you can try with the intel driver from unstable or experimental. If they'll persists... this could be a kernel bug. ;-) Regards. Cesare. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Processed: Re: Bug#438550: linux-source-2.6.22-rc7: ifconfig, iwconfig fail to bring up network after hibernate.
Processing commands for [EMAIL PROTECTED]: > reassign 438550 linux-2.6 Bug#438550: linux-source-2.6.22-rc7: ifconfig, iwconfig fail to bring up network after hibernate. Warning: Unknown package 'linux-source-2.6.22-rc7' Bug reassigned from package `linux-source-2.6.22-rc7' to `linux-2.6'. > -- Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#438550: linux-source-2.6.22-rc7: ifconfig, iwconfig fail to bring up network after hibernate.
Package: linux-source-2.6.22-rc7 Severity: important -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.22-rc7 Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.22-rc7 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) I am using an rt73 usb wireless network card, after using the echo disk >/sys/power/state and I try to bring up the network this is the output I received. I did have the lapic kernel option appended. Aug 17 10:30:38 Xcall20 kernel: ds: 007b es: 007b fs: gs: 0033 ss: 0068 Aug 17 10:30:38 Xcall20 kernel: Process sudo (pid: 9057, ti=ca0e2000 task=c3bd6ad0 task.ti=ca0e2000) Aug 17 10:30:38 Xcall20 kernel: Stack: 2361 46c5bf1e 0002 ff97 cb00e680 c34d1400 Aug 17 10:30:38 Xcall20 kernel:ca886ea0 c0239528 00d0 cac54280 81125cbc 81125cbc c34d1408 c34d1400 Aug 17 10:30:38 Xcall20 kernel:ca886ea0 2361 c023b0b7 c11b8200 c526b4a0 0002 c022f341 Aug 17 10:30:38 Xcall20 kernel: Call Trace: Aug 17 10:30:38 Xcall20 kernel: [] netlink_dump+0x4b/0x15e Aug 17 10:30:38 Xcall20 kernel: [] netlink_dump_start+0xd6/0x107 Aug 17 10:30:38 Xcall20 kernel: [] rtnl_dump_ifinfo+0x0/0x7d Aug 17 10:30:38 Xcall20 kernel: [] rtnetlink_rcv_msg+0xbc/0x1ae Aug 17 10:30:38 Xcall20 kernel: [] rtnl_dump_ifinfo+0x0/0x7d Aug 17 10:30:38 Xcall20 kernel: [] netlink_run_queue+0x5c/0xd2 Aug 17 10:30:38 Xcall20 kernel: [] rtnetlink_rcv_msg+0x0/0x1ae Aug 17 10:30:38 Xcall20 kernel: [] rtnetlink_rcv+0x25/0x3d Aug 17 10:30:38 Xcall20 kernel: [] netlink_data_ready+0x12/0x4b Aug 17 10:30:38 Xcall20 kernel: [] netlink_sendskb+0x19/0x2f Aug 17 10:30:38 Xcall20 kernel: [] netlink_sendmsg+0x264/0x270 Aug 17 10:30:38 Xcall20 kernel: [] sock_sendmsg+0xcf/0xea Aug 17 10:30:38 Xcall20 kernel: [] autoremove_wake_function+0x0/0x35 Aug 17 10:30:38 Xcall20 kernel: [] link_path_walk+0xa5/0xaf Aug 17 10:30:38 Xcall20 kernel: [] __fput+0x120/0x14a Aug 17 10:30:38 Xcall20 kernel: [] netlink_insert+0xfa/0x104 Aug 17 10:30:38 Xcall20 kernel: [] sys_sendto+0x118/0x138 Aug 17 10:30:38 Xcall20 kernel: [] filemap_nopage+0x15c/0x260 Aug 17 10:30:38 Xcall20 kernel: [] __handle_mm_fault+0x285/0x6b1 Aug 17 10:30:38 Xcall20 kernel: [] d_alloc+0x1b/0x157 Aug 17 10:30:38 Xcall20 kernel: [] sock_attach_fd+0x53/0xb1 Aug 17 10:30:38 Xcall20 kernel: [] sys_socketcall+0x15e/0x242 Aug 17 10:30:38 Xcall20 kernel: [] sysenter_past_esp+0x5f/0x85 Aug 17 10:30:38 Xcall20 kernel: === Aug 17 10:30:38 Xcall20 kernel: Code: 00 00 c7 44 24 08 00 00 00 00 8b 40 08 89 44 24 04 8b 06 8b 40 30 89 04 24 89 e8 e8 9c fb ff ff 85 c0 7e 16 8b 5b 30 47 83 eb 30 <8b> 43 30 0f 18 00 90 81 fb 5c 09 31 c0 75 b0 89 7e 14 8b 45 54 Aug 17 10:30:38 Xcall20 kernel: EIP: [] rtnl_dump_ifinfo+0x60/0x7d SS:ESP 0068:ca0e3ccc Aug 17 10:46:17 Xcall20 kernel: BUG: unable to handle kernel NULL pointer dereference at virtual address Aug 17 10:46:17 Xcall20 kernel: printing eip: Aug 17 10:46:17 Xcall20 kernel: Aug 17 10:46:17 Xcall20 kernel: *pde = Aug 17 10:46:17 Xcall20 kernel: Oops: [#2] Aug 17 10:46:17 Xcall20 kernel: Modules linked in: ipv6 battery ac thermal processor fan button 3c59x mii rt73 rfcomm l2cap bluetooth cpufreq_ondemand nvram uinput dm_snapshot dm_mirror dm_mod thinkpad_acpi cpufreq_powersave speedstep_smi freq_table speedstep_lib loop mousedev tsdev snd_cs4281 gameport snd_rawmidi snd_ac97_codec ac97_bus parport_pc snd_pcm snd_page_alloc snd_opl3_lib psmouse pcmcia i2c_piix4 firmware_class snd_seq_device parport snd_timer snd_hwdep snd soundcore serio_raw i2c_core yenta_socket rsrc_nonstatic pcmcia_core shpchp intel_agp pci_hotplug agpgart evdev jfs ide_disk uhci_hcd usbcore piix generic ide_core Aug 17 10:46:17 Xcall20 kernel: CPU:0 Aug 17 10:46:17 Xcall20 kernel: EIP:0060:[<>]Not tainted VLI Aug 17 10:46:17 Xcall20 kernel: EFLAGS: 00210296 (2.6.22-rc7 #1) Aug 17 10:46:17 Xcall20 kernel: EIP is at run_init_process+0x3feff000/0x14 Aug 17 10:46:17 Xcall20 kernel: eax: c844ec00 ebx: c844ec00 ecx: c029674c edx: c844ec00 Aug 17 10:46:17 Xcall20 kernel: esi: ca886660 edi: c844ec00 ebp: 0400 esp: c38e5ee8 Aug 17 10:46:17 Xcall20 kernel: ds: 007b es: 007b fs: gs: 0033 ss: 0068 Aug 17 10:46:17 Xcall20 kernel: Process ifconfig (pid: 9660, ti=c38e4000 task=c3bd6ad0 task.ti=c38e4000) Aug 17 10:46:17 Xcall20 kernel: Stack: c0227f33 ca886660 c02dc7c3 cbb21800 Aug 17 10:46:17 Xcall20 kernel: Aug 17 10:46:17 Xcall20 kernel: c029674c ca886660 c0164dd8 b7f5f000 Aug 17 10:46:17 Xcall20 kernel: Call Trace: Aug 17 10:46:17 Xcall2
Bug#383600: behaviour of update-initramfs -u has changed, only updates latest kernel initrd
maks suggests > you may want to set all for update_initramfs in > /etc/initramfs-tools/update-initramfs.conf I think this means update_initramfs=all . Is that correct? Neither the comments in that file nor the man page list "all" as a legal option. It would be good to update them if it is. I too noticed this issue when updating udev while running an older kernel than the most recent one installed. I find the current behavior surprising, and it doesn't strike me as necessarily more conservative. It's safer if update-initramfs or something else makes the initramfs broken. But it's less safe if it fails to apply a security fix or a necessary component (e.g., if you install evms any initramfs from before the installation will not work; evms uses update-initramfs -u in its postinst). As long as there's some way to change the default, I guess everyone can have their own opinions :) Ross Boylan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#438736: intel driver produces kernel crash in a variety of situations
Package: linux-image-2.6.18-5-amd64 Version: 2.6.18.dfsg.1-13etch1 Severity: important I've recently upgraded my hardware (motherboard + cpu + ram) and am now getting Linux crashes in a variety of situations. I've detected them when any of the following conditions are met: - When starting a second X session. - When time goes backwards (e.g. due to ntpdate) while X is running (but NOT when X isn't running) - When stopping X. When this happens, terminal is switched to console, and a kernel backtrace is displayed. As for the backtrace, I've seen it at least once hitting functions related to intel driver, but it seems to be completely different every time. I can get it captured if that's of any use. Also, sometimes the crash is complete, and sometimes SysReq key responds allowing for a cleaner reboot. Some notes on my system: - Two cpu cores (Could parallelism be an issue? If it's possible to disable SMP without recompile I could give that a quick try) - X driver is xserver-xorg-video-i810. Card model: $ sudo lspci -v [...] 00:02.0 VGA compatible controller: Intel Corporation 945G/GZ Express Integrated Graphics Controller (rev 02) (prog-if 00 [VGA]) Subsystem: ASRock Incorporation Unknown device 2772 Flags: bus master, fast devsel, latency 0, IRQ 11 Memory at fea8 (32-bit, non-prefetchable) [size=512K] I/O ports at cc00 [size=8] Memory at d000 (32-bit, prefetchable) [size=256M] Memory at fea4 (32-bit, non-prefetchable) [size=256K] Capabilities: [90] Message Signalled Interrupts: Mask- 64bit- Queue=0/0 Enable- Capabilities: [d0] Power Management version 2 [...] -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-5-amd64 Locale: LANG=ca_AD.UTF-8, LC_CTYPE=ca_AD.UTF-8 (charmap=UTF-8) Versions of packages linux-image-2.6.18-5-amd64 depends on: ii coreutil 5.97-5.3The GNU core utilities ii debconf 1.5.11 Debian configuration management sy ii e2fsprog 1.39+1.40-WIP-2006.11.14+dfsg-2 ext2 file system utilities and lib ii initramf 0.85h tools for generating an initramfs ii module-i 3.3-pre4-2 tools for managing Linux kernel mo linux-image-2.6.18-5-amd64 recommends no packages. -- debconf information excluded -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#438717: bug 438717: test script
Looks like the attachment didn't make it through. Here it is. prio_filter_map_fallback_test.sh Description: Bourne shell script
Bug#416608: acpi - discover battery after hibernate takes a long time
I no longer use klaptopdaemon anymore I use KPowersave. Recently KPowersave has changed from relying on powersaved to HAL and I have noticed no more issues since. I recommend that this bug be closed. -- Regards, Sheridan Hutchinson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: linux-latest-2.6 update in stable incomplete
On 2007-08-18, dann frazier <[EMAIL PROTECTED]> wrote: > On Sat, Aug 18, 2007 at 01:20:11PM +0200, Bastian Blank wrote: >> Hi folks >> >> The linux-latest-2.6 update in 4.0r1 was incomplete. arm still have the >> version 6, anything else 6etch1. This is a serious problem as arm will >> be uninstallable now and no machine gets new security uploads. > > I'm sure this is my fault, sorry about that. Is it possible to > update this before r2? You could release a new linux-latest-2.6 package pointing to the new arm kernel images in a DSA-1356-2. Cheers, Moritz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#438717: linux-2.6: net scheduling: filter attached to prio qdisc breaks priomap handling of packets it does _not_ match
Package: linux-2.6 Version: 2.6.22-3 Severity: normal Attach: /home/master/prio_filter_map_fallback_test.sh Subject area: network, packet schedulers (qdisc), filters for classifying packets in classful qdiscs When I attach a filter to a prio qdisc, the packets that it does _not_ match are not correctly handled (enqueued) according to the priomap anymore, that is the same way than when there is no filter attached to the qdisc. For a concrete example, run the attached script (as root), trying to ensure no other traffic happens over the interface: it installs qdiscs on interface ${TIF} (defaults to eth0), pings host ${PHOST} (defaults to master.debian.org - numerical IP hardcoded) with various IP TOS bits set, installs a filter that matches TCP (_not_ ICMP) and does the pings again. Notice how the first pings (before filters get installed) get in the right queue according to their TOS bits, but after the filter gets installed, they all end up in the "best effort" queue. The output I get (non-relevant bits snipped out) is: Running test on interface eth0 by pinging host 70.103.162.29 Pinging with normal service 1 times Pinging with minimise delay 2 times Pinging with minimise cost 4 times qdisc pfifo 22: parent 20:2 limit 1000p Sent 196 bytes 2 pkt (dropped 0, overlimits 0 requeues 0) qdisc pfifo 23: parent 20:3 limit 1000p Sent 98 bytes 1 pkt (dropped 0, overlimits 0 requeues 0) qdisc pfifo 24: parent 20:4 limit 1000p Sent 392 bytes 4 pkt (dropped 0, overlimits 0 requeues 0) Adding a filter that does _not_ match ICMP Pinging with normal service 8 times qdisc pfifo 22: parent 20:2 limit 1000p Sent 196 bytes 2 pkt (dropped 0, overlimits 0 requeues 0) qdisc pfifo 23: parent 20:3 limit 1000p Sent 924 bytes 10 pkt (dropped 0, overlimits 0 requeues 0) qdisc pfifo 24: parent 20:4 limit 1000p Sent 392 bytes 4 pkt (dropped 0, overlimits 0 requeues 0) Pinging with minimise delay 16 times qdisc pfifo 22: parent 20:2 limit 1000p Sent 196 bytes 2 pkt (dropped 0, overlimits 0 requeues 0) qdisc pfifo 23: parent 20:3 limit 1000p Sent 2492 bytes 26 pkt (dropped 0, overlimits 0 requeues 0) qdisc pfifo 24: parent 20:4 limit 1000p Sent 392 bytes 4 pkt (dropped 0, overlimits 0 requeues 0) Pinging with minimise cost 32 times qdisc pfifo 22: parent 20:2 limit 1000p Sent 196 bytes 2 pkt (dropped 0, overlimits 0 requeues 0) qdisc pfifo 23: parent 20:3 limit 1000p Sent 5628 bytes 58 pkt (dropped 0, overlimits 0 requeues 0) qdisc pfifo 24: parent 20:4 limit 1000p Sent 392 bytes 4 pkt (dropped 0, overlimits 0 requeues 0) The output I would expect is: (... snip ...) Adding a filter that does _not_ match ICMP Pinging with normal service 8 times qdisc pfifo 22: parent 20:2 limit 1000p Sent XXX bytes 2 pkt (dropped 0, overlimits 0 requeues 0) qdisc pfifo 23: parent 20:3 limit 1000p Sent XXX bytes 10 pkt (dropped 0, overlimits 0 requeues 0) qdisc pfifo 24: parent 20:4 limit 1000p Sent XXX bytes 4 pkt (dropped 0, overlimits 0 requeues 0) Pinging with minimise delay 16 times qdisc pfifo 22: parent 20:2 limit 1000p Sent XXX bytes 18 pkt (dropped 0, overlimits 0 requeues 0) qdisc pfifo 23: parent 20:3 limit 1000p Sent XXX bytes 10 pkt (dropped 0, overlimits 0 requeues 0) qdisc pfifo 24: parent 20:4 limit 1000p Sent XXX bytes 4 pkt (dropped 0, overlimits 0 requeues 0) Pinging with minimise cost 32 times qdisc pfifo 22: parent 20:2 limit 1000p Sent XXX bytes 18 pkt (dropped 0, overlimits 0 requeues 0) qdisc pfifo 23: parent 20:3 limit 1000p Sent XXX bytes 10 pkt (dropped 0, overlimits 0 requeues 0) qdisc pfifo 24: parent 20:4 limit 1000p Sent XXX bytes 36 pkt (dropped 0, overlimits 0 requeues 0) -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.22-1-686 (SMP w/1 CPU core) Locale: LANG=fr_LU.UTF-8, LC_CTYPE=fr_LU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]