Bug#660446: linux-image-3.2.0-1-4kc-malta: Should include built-in support for ext4
Package: linux-image-3.2.0-1-4kc-malta Version: 3.2.4-1 Severity: wishlist I've installed a mips system within qemu using the debian installer image for this architecture. Unfortunately the installer's default filesystem type ext4 is not built-in into the kernel image, which makes it very hard to boot the system after installation. Please change ext4 support from module to built-in for this kernel, as it's done for ext2 and ext3. thanks WM -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: i386 (x86_64) Kernel: Linux 3.2.0-1-amd64 (SMP w/2 CPU cores) Locale: LANG=de_AT.UTF-8, LC_CTYPE=de_AT.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- 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/20120219093201.6443.54631.reportbug@wmiwilli
Bug#590689: linux-2.6: Sudden slowdowns that feel like freezes in X
Hi! On 2011-08-30 07:14, Jonathan Nieder wrote: Neat. Did this problem eventually go away, or do you still experience it? If the former, what's the oldest fixed version you remember (/var/log/dpkg.log* can help)? Unfortunately, I do not remember when this problem went away, but it is gone. It might even have stopped to occur because of newer iceweasel versions (4~beta+) that no longer trigger the bug, which I first installed in March. A week before, I installed linux-image-2.6.38-rc6-amd64. It is too far in the past to remember more details. WM -- 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/4e5c9956.7000...@wm1.at
Bug#608698: linux-image-2.6.37-rc7-686: suspend/hibernate fails with pnp_bus_suspend+0x0/0x57 returns -5
If you don't use the parallel port, you may be able to work around this by blacklisting the 'parport_pc' module. That seems to help, but it might just be hidden by another problem I'm facing after a few hibernate cycles: Colors of fonts change (mostly white to black), and the screen gets very strange artefacts. I've switched to the amd64 kernel now, maybe it helps. I've not yet tested the current squeeze kernel, I'll do that after testing with the amd64 kernel. WM -- 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/4d3e924f.5060...@wm1.at
Bug#608698: linux-image-2.6.37-rc7-686: suspend/hibernate fails with pnp_bus_suspend+0x0/0x57 returns -5
Package: linux-2.6 Version: 2.6.37~rc7-1~experimental.1 Severity: normal After a few hibernate cycles, I can no longer suspend/hibernate my thinkpad T500. It fails with mentioned error - see the attached logs. Additionally, my external cherry USB keyboard (plugged in the Docking Station) failed to work after the first failed hibernate attempt. However, unplugging and replugging solved this problem. This is the second time that hibernation fails with 2.6.37-rc?, and the error message in dmesg is the same (... error -5) so this seems reproducable. I can't test earlier kernels because up to 2.6.36, I had memory corruption problems after wake-up from hibernate. In fact I'm quite happy that it works now at least for a few cycles, but I'd like to get back to the state before Kernel Mode Setting where i had an uptime of 180 days with at least one hibernate cycle daily. -- Package-specific info: ** Version: Linux version 2.6.37-rc7-686 (Debian 2.6.37~rc7-1~experimental.1) (b...@decadent.org.uk) (gcc version 4.4.5 (Debian 4.4.5-10) ) #1 SMP Sun Dec 26 18:21:15 UTC 2010 ** Command line: BOOT_IMAGE=/boot/vmlinuz-2.6.37-rc7-686 root=UUID=03db9303-638d-4e66-94c9-4e72f668620e ro ** Not tainted ** Kernel log: [143686.861383] ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready [143687.120060] usb 1-5.1: device not accepting address 11, error -32 [143687.120415] usb 1-5.1: USB disconnect, address 11 [143687.260178] usb 1-5.1: new low speed USB device using ehci_hcd and address 12 [143687.348172] usb 1-5.1: device descriptor read/64, error -32 [143687.540160] usb 1-5.1: device descriptor read/64, error -32 [143687.704075] device eth0 entered promiscuous mode [143687.716173] usb 1-5.1: new low speed USB device using ehci_hcd and address 13 [143687.804161] usb 1-5.1: device descriptor read/64, error -32 [143687.996169] usb 1-5.1: device descriptor read/64, error -32 [143688.172181] usb 1-5.1: new low speed USB device using ehci_hcd and address 14 [143688.580060] usb 1-5.1: device not accepting address 14, error -32 [143688.652167] usb 1-5.1: new low speed USB device using ehci_hcd and address 15 [143689.060057] usb 1-5.1: device not accepting address 15, error -32 [143689.060203] hub 1-5:1.0: unable to enumerate USB device on port 1 [143692.705890] device eth0 left promiscuous mode [143697.552092] eth0: no IPv6 routers present [143702.692585] tun0: Disabled Privacy Extensions [143707.191394] tun1: Disabled Privacy Extensions [143766.724956] PM: Hibernation mode set to 'shutdown' [143766.791206] PM: Marking nosave pages: 0009e000 - 0010 [143766.793731] PM: Basic memory bitmaps created [143766.796654] PM: Syncing filesystems ... done. [143766.837539] Freezing user space processes ... (elapsed 0.01 seconds) done. [143766.854437] Freezing remaining freezable tasks ... (elapsed 0.01 seconds) done. [143766.870460] PM: Preallocating image memory... done (allocated 296284 pages) [143767.049769] PM: Allocated 1185136 kbytes in 0.17 seconds (6971.38 MB/s) [143767.052125] Suspending console(s) (use no_console_suspend to debug) [143767.056119] sd 0:0:0:0: [sda] Synchronizing SCSI cache [143767.092060] ACPI handle has no context! [143767.092070] parport_pc 00:0b: disable failed [143767.092079] legacy_suspend(): pnp_bus_suspend+0x0/0x57 returns -5 [143767.092082] PM: Device 00:0b failed to freeze: error -5 [143767.131542] sd 0:0:0:0: [sda] Starting disk [143767.345639] PM: restore of devices complete after 214.252 msecs [143767.362683] Restarting tasks ... done. [143767.367665] PM: Basic memory bitmaps freed [143767.370174] video LNXVIDEO:00: Restoring backlight state [143767.408193] netconsole: network logging stopped, interface tun1 unregistered [143767.436155] usb 1-5.1: new low speed USB device using ehci_hcd and address 16 [143767.464098] netconsole: network logging stopped, interface tun0 unregistered [143767.526067] usb 1-5.1: device descriptor read/64, error -32 [143767.720123] usb 1-5.1: device descriptor read/64, error -32 [143767.896124] usb 1-5.1: new low speed USB device using ehci_hcd and address 17 [143767.984135] usb 1-5.1: device descriptor read/64, error -32 [143768.180134] usb 1-5.1: device descriptor read/64, error -32 [143768.356134] usb 1-5.1: new low speed USB device using ehci_hcd and address 18 [143768.736416] e1000e :00:19.0: irq 44 for MSI/MSI-X [143768.764057] usb 1-5.1: device not accepting address 18, error -32 [143768.792131] e1000e :00:19.0: irq 44 for MSI/MSI-X [143768.792598] ADDRCONF(NETDEV_UP): eth0: link is not ready [143768.836185] usb 1-5.1: new low speed USB device using ehci_hcd and address 19 [143769.244046] usb 1-5.1: device not accepting address 19, error -32 [143769.244197] hub 1-5:1.0: unable to enumerate USB device on port 1 [143770.356947] e1000e: eth0 NIC Link is Up 100 Mbps Full Duplex, Flow Control: RX/TX [143770.356965] e1000e :00:19.0: eth0: 10/100 speed: disabling TSO [143770.357394] ADDRCONF(NETDEV_CHANGE): eth0: link
Bug#599254: linux-image-2.6.36-rc5-686: icedove causes BUG when trying to open mail with very large attachments on i915
it could very well be fixed in rc6 please test that first, thanks. Yes, it seems so. At least I could not reproduce it with rc6. WM -- 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/4cb2e065.4010...@wm1.at
Bug#599254: linux-image-2.6.36-rc5-686: icedove causes BUG when trying to open mail with very large attachments on i915
Package: linux-2.6 Version: 2.6.36~rc5-1~experimental.1 Severity: important When trying to open a mail with with large images (e.g. 3 images with 4368x2912) in icedove the screen freezes and after a few seconds, a beep occurs (this is probably the kerneloops daemon) and the following messages occur in the kernel log: Oct 6 09:19:58 hostname kernel: [ 257.454598] [ cut here ] Oct 6 09:19:58 hostname kernel: [ 257.454660] kernel BUG at /build/buildd-linux-2.6_2.6.36~rc5-1~experimental.1-i386-I9JHPF/linux-2.6-2.6.36~rc5/debian/build/source_i386_none/drivers/gpu/drm/i915/i915_gem.c:1444! Oct 6 09:19:58 hostname kernel: [ 257.454810] invalid opcode: [#1] SMP Oct 6 09:19:58 hostname kernel: [ 257.454858] last sysfs file: /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:00/PNP0C09:00/PNP0C0A:00/power_supply/BAT0/energy_full Oct 6 09:19:58 hostname kernel: [ 257.454975] Modules linked in: inet_diag acpi_cpufreq mperf cpufreq_powersave cpufreq_conservative cpufreq_stats cpufreq_userspace ppdev lp tun sco bridge stp bnep rfcomm l2cap crc16 bluetooth uinput fuse nfsd exportfs nfs lockd fscache nfs_acl auth_rpcgss sunrpc firewire_sbp2 loop arc4 ecb snd_hda_codec_conexant snd_hda_intel iwlagn snd_hda_codec iwlcore snd_hwdep thinkpad_acpi snd_pcm_oss snd_mixer_oss snd_pcm pcmcia r852 sm_common nand nand_ids nand_ecc snd_seq_midi mac80211 parport_pc snd_rawmidi mtd parport snd_seq_midi_event cfg80211 yenta_socket pcmcia_rsrc pcmcia_core snd_seq snd_timer snd_seq_device psmouse joydev snd tpm_tis tpm soundcore i2c_i801 wmi rfkill battery evdev serio_raw ac processor snd_page_alloc tpm_bios nvram ext3 jbd mbcache netconsole configfs hid_cherry usbhid hid sg sd_mod crc_t10dif sr_mod cdrom i915 ahci libahci drm_kms_helper uhci_hcd sdhci_pci sdhci libata drm ehci_hcd i2c_algo_bit i2c_core scsi_mod mmc_core firewire_ohci video led_class firewire Oct 6 09:19:58 hostname kernel: _core crc_itu_t thermal usbcore thermal_sys output e1000e nls_base button [last unloaded: scsi_wait_scan] Oct 6 09:19:58 hostname kernel: [ 257.456386] Oct 6 09:19:58 hostname kernel: [ 257.456406] Pid: 1841, comm: Xorg Not tainted 2.6.36-rc5-686 #1 208252G/208252G Oct 6 09:19:58 hostname kernel: [ 257.456478] EIP: 0060:[f8a98e48] EFLAGS: 00213246 CPU: 0 Oct 6 09:19:58 hostname kernel: [ 257.456549] EIP is at i915_gem_object_put_pages+0x13/0xb2 [i915] Oct 6 09:19:58 hostname kernel: [ 257.456608] EAX: f4912302 EBX: f49123c0 ECX: 0001 EDX: 0001 Oct 6 09:19:58 hostname kernel: [ 257.456669] ESI: f6a39c00 EDI: f73c2000 EBP: 0001 ESP: f6445dec Oct 6 09:19:58 hostname kernel: [ 257.456730] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 Oct 6 09:19:58 hostname kernel: [ 257.456783] Process Xorg (pid: 1841, ti=f6444000 task=f692dac0 task.ti=f6444000) Oct 6 09:19:58 hostname kernel: [ 257.456853] Stack: Oct 6 09:19:58 hostname kernel: [ 257.456875] f49123c0 f6a39c00 f73c2000 f8a99c66 f4995cc0 f6445e30 f6445e28 Oct 6 09:19:58 hostname kernel: [ 257.456979] 0 f6445e30 f8a9d588 f6445e28 f73c2fd8 0500 1000 f73c3030 f4b2b1e8 Oct 6 09:19:58 hostname kernel: [ 257.457092] 0 f4ab6c68 f4912428 f4ae52a8 f4ae5f00 f6a39c14 f6a39c00 f73c2000 f8a991e5 Oct 6 09:19:58 hostname kernel: [ 257.457206] Call Trace: Oct 6 09:19:58 hostname kernel: [ 257.457252] [f8a99c66] ? i915_gem_object_unbind+0x96/0x129 [i915] Oct 6 09:19:58 hostname kernel: [ 257.457332] [f8a9d588] ? i915_gem_evict_something+0x311/0x359 [i915] Oct 6 09:19:58 hostname kernel: [ 257.457412] [f8a991e5] ? i915_gem_object_bind_to_gtt+0x1dc/0x261 [i915] Oct 6 09:19:58 hostname kernel: [ 257.457494] [f8a9954d] ? i915_gem_mmap_gtt_ioctl+0x180/0x1ad [i915] Oct 6 09:19:58 hostname kernel: [ 257.457577] [f893972b] ? drm_ioctl+0x224/0x2d5 [drm] Oct 6 09:19:58 hostname kernel: [ 257.457646] [f8a993cd] ? i915_gem_mmap_gtt_ioctl+0x0/0x1ad [i915] Oct 6 09:19:58 hostname kernel: [ 257.457712] [c1008b8b] ? restore_i387_fxsave+0x5c/0x6d Oct 6 09:19:58 hostname kernel: [ 257.457781] [f8939507] ? drm_ioctl+0x0/0x2d5 [drm] Oct 6 09:19:58 hostname kernel: [ 257.457833] [c10c11ad] ? do_vfs_ioctl+0x49e/0x4e9 Oct 6 09:19:58 hostname kernel: [ 257.457883] [c1008f15] ? restore_i387_xstate+0x19e/0x1d5 Oct 6 09:19:58 hostname kernel: [ 257.457939] [c10b655e] ? fsnotify_access+0x49/0x50 Oct 6 09:19:58 hostname kernel: [ 257.457987] [c10c123c] ? sys_ioctl+0x44/0x64 Oct 6 09:19:58 hostname kernel: [ 257.458034] [c1002f1f] ? sysenter_do_call+0x12/0x28 Oct 6 09:19:58 hostname kernel: [ 257.458084] Code: 00 00 00 89 d8 ff b1 80 00 00 00 b9 01 00 00 00 e8 b3 fc ff ff 5b 5b c3 55 57 56 53 89 c3 8b 68 38 8a 40 71 c1 ed 0c a8 0c 75 04 0f 0b eb fe 88 c2 83 e2 03 80 fa 02 75 04 0f 0b eb fe 88 c2 83 Oct 6 09:19:58 hostname kernel: [ 257.458295] EIP: [f8a98e48] i915_gem_object_put_pages+0x13/0xb2 [i915] SS:ESP 0068:f6445dec I haven't tested yet whether this
Bug#599254: linux-image-2.6.36-rc5-686: icedove causes BUG when trying to open mail with very large attachments on i915
Am 2010-10-06 13:11, schrieb maximilian attems: it could very well be fixed in rc6 please test that first, thanks. Hi! Is the i386 version of rc6 already somewhere available? The offical ones are currently waiting in NEW. thanks WM -- 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/4cac5c51.1020...@wm1.at
Bug#584259: initramfs-tools: breaks software suspend (hibernation)
Am 2010-06-20 18:10, schrieb Ben Hutchings: On Sat, 2010-06-19 at 19:06 +0200, Willi Mann wrote: Hi! The problem can be traced to module hid_cherry. If it exists in the initrd, the resume works, otherwise it doesn't. This seems to indicate that hid_cherry doesn't fully reinitialise the device on resume. This would be a kernel bug, so I'm reassigning it. I've now tested 2.6.34 from experimental. It works without hid_cherry in the initrd. So the bug only applies to the testing/unstable kernel. WM -- 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/4c1e54c9.70...@wm1.at
Bug#584259: initramfs-tools: breaks software suspend (hibernation)
Hi! The problem can be traced to module hid_cherry. If it exists in the initrd, the resume works, otherwise it doesn't. WM -- 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/4c1cf90a.4010...@wm1.at
Bug#584259: initramfs-tools: breaks software suspend (hibernation)
Hi! -- resume # RESUME=/dev/sda6 RESUME='LABEL=amdlinux-swap' Does it work with 'RESUME=/dev/disk/by-label/amdlinux-swap'? No. If it still does not work then: can you please extract the broken and the working initramfs[1] and check the difference between them? Especially the included configuration files and the list of files Attached is the diff on the filelist and the diff on the conf directory. Is there a way to forcefully insert the modules that are no longer included? WM diff -urN 0.93.3/conf//initramfs.conf 0.94.4/conf//initramfs.conf --- 0.93.3/conf//initramfs.conf 2010-06-09 18:22:05.0 +0200 +++ 0.94.4/conf//initramfs.conf 2010-06-09 18:25:25.0 +0200 @@ -8,7 +8,7 @@ # # MODULES: [ most | netboot | dep | list ] # -# most - Add all framebuffer, acpi, filesystem, and harddrive drivers. +# most - Add most filesystem and all harddrive drivers. # # dep - Try and guess which modules to load. # @@ -36,6 +36,12 @@ KEYMAP=n # +# COMPRESS: [ gzip | bzip2 | lzma ] +# + +COMPRESS=gzip + +# # NFS Section of the config. # filelist.diff.gz Description: GNU Zip compressed data
Bug#584784: also applies to unstable
Am 2010-06-07 03:44, schrieb Ben Hutchings: On Sun, 2010-06-06 at 23:18 +0200, Willi Mann wrote: Kernel panic - not syncing: To avoid data corruption io_map_base MUST be set with multiple PCI domains. has been applied on all PCI MIPS systems since Linux 2.6.24. Are you quite sure that this was introduced by the kernel upgrade and not a qemu upgrade. Yes, I didn't change the qemu version, it's really only the kernel that changed. Attached is the dmesg output of the working kernel, version 2.6.32-9. OK, it looks like this is due to an botched switch from IDE to libata drivers on MIPS. The qemu emulated HD controller is now being handled by the ide-generic driver whereas it should have been switched from piix to ata_piix, and ide-generic triggers this panic for reasons I don't fully understand. This will get fixed, but not immediately. OK. As long as it gets fixed before the release... Should we notify the d-i people so that they can put a note on the errata page? Though I wonder why the BTS did not fully process my found command. It still only marks the version in experimental as affected. WM -- 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/4c0d339d.8090...@wm1.at
Bug#584784: /boot/vmlinux-2.6.34-1-4kc-malta: no longer boots in qemu
Package: linux-2.6 Version: 2.6.34-1~experimental.1 Severity: grave File: /boot/vmlinux-2.6.34-1-4kc-malta This kernel no longer boots in qemu 0.12.4+dfsg-1 (boot messages attached). The last version that successfully booted is 2.6.32-9. I haven't yet tested the current unstable kernel. -- Package-specific info: ** Kernel log: boot messages should be attached ** Model information system type : MIPS Malta cpu model : MIPS 24Kc V0.0 FPU V0.0 ** PCI devices: 00:00.0 Host bridge [0600]: Marvell Technology Group Ltd. GT-64120/64120A/64121A System Controller [11ab:4620] (rev 10) Subsystem: Qumranet, Inc. Device [1af4:1100] Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- INTx- Interrupt: pin A routed to IRQ 0 Region 0: Memory at unassigned (32-bit, prefetchable) [disabled] Region 1: Memory at 0100 (32-bit, prefetchable) [disabled] [size=16M] Region 2: Memory at ignored (32-bit, non-prefetchable) [disabled] Region 3: Memory at ignored (32-bit, non-prefetchable) [disabled] Region 4: Memory at ignored (32-bit, non-prefetchable) [disabled] Region 5: I/O ports at ignored [disabled] 00:0a.0 ISA bridge [0601]: Intel Corporation 82371AB/EB/MB PIIX4 ISA [8086:7110] Subsystem: Qumranet, Inc. Device [1af4:1100] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 0 00:0a.1 IDE interface [0101]: Intel Corporation 82371AB/EB/MB PIIX4 IDE [8086:7111] (prog-if 80 [Master]) Subsystem: Qumranet, Inc. Device [1af4:1100] Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 0 Region 0: [virtual] Memory at 01f0 (32-bit, non-prefetchable) [size=8] Region 1: [virtual] Memory at 03f0 (type 3, non-prefetchable) [size=1] Region 2: [virtual] Memory at 0170 (32-bit, non-prefetchable) [size=8] Region 3: [virtual] Memory at 0370 (type 3, non-prefetchable) [size=1] Region 4: I/O ports at 1040 [size=16] Kernel driver in use: PIIX_IDE 00:0a.2 USB Controller [0c03]: Intel Corporation 82371AB/EB/MB PIIX4 USB [8086:7112] (rev 01) (prog-if 00 [UHCI]) Subsystem: Qumranet, Inc. Device [1af4:1100] Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 0 Interrupt: pin D routed to IRQ 11 Region 4: I/O ports at 1000 [size=32] Kernel driver in use: uhci_hcd 00:0a.3 Bridge [0680]: Intel Corporation 82371AB/EB/MB PIIX4 ACPI [8086:7113] (rev 03) Subsystem: Qumranet, Inc. Qemu virtual machine [1af4:1100] Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- INTx- Interrupt: pin A routed to IRQ 0 Kernel driver in use: piix4_smbus 00:0b.0 Ethernet controller [0200]: Advanced Micro Devices [AMD] 79c970 [PCnet32 LANCE] [1022:2000] (rev 10) Subsystem: Qumranet, Inc. Device [1af4:1100] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 0 (1500ns min, 63750ns max) Interrupt: pin A routed to IRQ 10 Region 0: I/O ports at 1020 [size=32] Region 1: Memory at 12011000 (32-bit, non-prefetchable) [size=32] Kernel driver in use: pcnet32 00:12.0 VGA compatible controller [0300]: Cirrus Logic GD 5446 [1013:00b8] (prog-if 00 [VGA controller]) Subsystem: Qumranet, Inc. Device [1af4:1100] Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- INTx- Region 0: Memory at 1000 (32-bit, prefetchable) [size=32M] Region 1: Memory at 1201 (32-bit, non-prefetchable) [size=4K] [virtual] Expansion ROM at 1200 [disabled] [size=64K] Kernel driver in use: cirrusfb ** USB devices: Bus 001 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (500, 'testing'), (1, 'experimental')
Bug#584784: also applies to unstable
found 584784 2.6.32-15 thanks Hi! Unfortunately, this bug also applies to unstable, only current testing kernel is unaffected. WM -- 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/4c0bdd20.5050...@wm1.at
Bug#584259: initramfs-tools: breaks software suspend (hibernation)
Package: initramfs-tools Version: 0.95.1 Severity: important Since the upgrade to 0.94.4 in testing, software suspend's resume does not complete. The screen it ends up with is black except a blinking cursor, but I can use Alt+F1 to switch to a screen that shows some messages concerning hibernation. In this screen, typed keys are shown on the screen, but no further action (especially no reaction of Sys-Rq keys) can be started. Particularly, it is not possible to undo the switch done with Alt+F1. I mainly tested the suspend with s2disk from uswsusp, but it's also reproduceable with the in-kernel suspend method. Downgrading to version 0.93.4 solves the issue (only tested with s2disk). I haven't yet tested the intermediate versions that only ended up in unstable. -- Package-specific info: -- initramfs sizes -rw-r--r-- 1 root root 8.3M Apr 29 2009 /boot/initrd.img-2.6.29-1-amd64 -rw-r--r-- 1 root root 8.2M Apr 29 2009 /boot/initrd.img-2.6.29-1-amd64.bak -rw-r--r-- 1 root root 8.3M May 18 2009 /boot/initrd.img-2.6.29-2-amd64 -rw-r--r-- 1 root root 9.5M Oct 12 2009 /boot/initrd.img-2.6.30-1-amd64 -rw-r--r-- 1 root root 9.5M Sep 30 2009 /boot/initrd.img-2.6.30-1-amd64.bak -rw-r--r-- 1 root root 11M Oct 29 2009 /boot/initrd.img-2.6.30-2-amd64 -rw-r--r-- 1 root root 9.5M Oct 18 2009 /boot/initrd.img-2.6.30-2-amd64.bak -rw-r--r-- 1 root root 8.4M May 23 2009 /boot/initrd.img-2.6.30-rc6 -rw-r--r-- 1 root root 8.6M Jun 24 2009 /boot/initrd.img-2.6.30-rc7 -rw-r--r-- 1 root root 8.4M May 24 2009 /boot/initrd.img-2.6.30-rc7.bak -rw-r--r-- 1 root root 12M Dec 15 18:50 /boot/initrd.img-2.6.31-1-amd64 -rw-r--r-- 1 root root 12M Dec 9 17:42 /boot/initrd.img-2.6.31-1-amd64.bak -rw-r--r-- 1 root root 12M Mar 15 20:37 /boot/initrd.img-2.6.32-3-amd64 -rw-r--r-- 1 root root 12M Feb 22 13:59 /boot/initrd.img-2.6.32-trunk-amd64 -rw-r--r-- 1 root root 12M Jan 15 18:12 /boot/initrd.img-2.6.32-trunk-amd64.bak -rw-r--r-- 1 root root 13M Jun 2 17:50 /boot/initrd.img-2.6.33-2-amd64 -rw-r--r-- 1 root root 13M Jun 2 17:13 /boot/initrd.img-2.6.33-2-amd64.bak -- /proc/cmdline BOOT_IMAGE=/boot/vmlinuz-2.6.33-2-amd64 root=UUID=d048da7e-57ef-4713-8f6d-193e926b468f ro quiet -- resume # RESUME=/dev/sda6 RESUME='LABEL=amdlinux-swap' -- /proc/filesystems ext3 fuseblk -- lsmod Module Size Used by powernow_k810978 1 cpufreq_stats 2659 0 cpufreq_powersave902 0 battery 4998 0 cpufreq_conservative 7910 0 cpufreq_userspace 2024 0 ppdev 5565 0 lp 8201 0 parport27314 2 ppdev,lp sco 7273 2 bridge 39813 0 stp 1440 1 bridge rfcomm 29810 0 bnep9722 2 l2cap 25306 4 rfcomm,bnep crc16 1319 1 l2cap bluetooth 42103 6 sco,rfcomm,bnep,l2cap rfkill 13164 2 bluetooth nfsd 255513 11 lockd 58547 1 nfsd nfs_acl 2031 1 nfsd auth_rpcgss33572 1 nfsd sunrpc162584 12 nfsd,lockd,nfs_acl,auth_rpcgss exportfs3202 1 nfsd binfmt_misc 6550 1 fuse 50478 1 radeon572633 2 ttm40361 1 radeon drm_kms_helper 20097 1 radeon drm 143510 5 radeon,ttm,drm_kms_helper i2c_algo_bit4225 1 radeon f71882fg 26374 0 eeprom 2457 0 lm808364 0 firewire_sbp2 11562 0 loop 11902 0 snd_ens137116842 4 gameport7448 1 snd_ens1371 snd_ac97_codec 99298 1 snd_ens1371 ac97_bus1086 1 snd_ac97_codec snd_pcm_oss32790 0 snd_mixer_oss 12654 1 snd_pcm_oss snd_pcm61078 4 snd_ens1371,snd_ac97_codec,snd_pcm_oss snd_seq_midi4432 0 snd_rawmidi15810 2 snd_ens1371,snd_seq_midi snd_seq_midi_event 4628 1 snd_seq_midi snd_seq43279 2 snd_seq_midi,snd_seq_midi_event snd_timer 15749 3 snd_pcm,snd_seq snd_seq_device 4493 3 snd_seq_midi,snd_rawmidi,snd_seq shpchp 26264 0 snd47090 15 snd_ens1371,snd_ac97_codec,snd_pcm_oss,snd_mixer_oss,snd_pcm,snd_rawmidi,snd_seq,snd_timer,snd_seq_device psmouse45603 0 edac_core 29261 0 tpm_tis 7336 0 pci_hotplug21251 1 shpchp joydev 8546 0 edac_mce_amd6457 0 tpm 9933 1 tpm_tis k8temp 3139 0 i2c_piix4 8328 0 soundcore 4822 1 snd pcspkr 1699 0 serio_raw 3960 0 i2c_core 15385 7
Bug#516018: linux-image-2.6.26-1-686: System shutdown fails (no poweroff)
Package: linux-image-2.6.26-1-686 Version: 2.6.26-13 Severity: normal I'm reporting this bug from a different machine than the machine the problem appears on, so I deleted the system information. When I hit the powerbutton, or choose shutdown from the kdm menu which I configured to invoke /sbin/poweroff, the computer does complete the system poweroff. Instead it prints the following messages: Shutdown: hda ACPI: Preparing to enter system sleep state S5 Disabling non-boot CPUs ... CPU 1 is now offline SMP alternatives: switching to UP code I'm not sure if this is a kernel bug, please reassign if appropriate. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#516018: Clarification
I meant the computer does *not* complete the system shutdown. And that applies to only about half of all system shutdowns, so it is not a stable bug. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#430776: linux-image-2.6.21-2-686: hangs on boot for 60 seconds while trying something related to pcmcia
Package: linux-image-2.6.21-2-686 Severity: normal This bug is a regression from linux-image-2.6.18-4-686 2.6.18.dfsg.1-12 The messages before the hang are: Yenta: Raising subordinate bus# of parent bus (#02) from #02 to #06 pcmcia: parent PCI bridge I/O window: 0x3000 - 0x3fff cs: IO port probe 0x3000-0x3fff: clean. pcmcia: parent PCI bridge Memory window: 0xe020 - 0xe07f pcmcia: parent PCI bridge Memory window: 0x3000 - 0x3bff Yenta: CardBus bridge found at :02:06.1 [1025:0050] Synaptics Touchpad, model: 1, fw: 5.8, id: 0x9d48b1, caps: 0x904713/0x4006 Yenta: ISA IRQ mask 0x0838, PCI irq 6 Socket status: 3006 Yenta: Raising subordinate bus# of parent bus (#02) from #06 to #0a pcmcia: parent PCI bridge I/O window: 0x3000 - 0x3fff cs: IO port probe 0x3000-0x3fff: clean. pcmcia: parent PCI bridge Memory window: 0xe020 - 0xe07f pcmcia: parent PCI bridge Memory window: 0x3000 - 0x3bff Yenta: CardBus bridge found at :02:06.3 [1025:0050] input: SynPS/2 Synaptics TouchPad as /class/input/input5 iTCO_wdt: Found a ICH4-M TCO device (Version=1, TCOBASE=0x1060) iTCO_wdt: initialized. heartbeat=30 sec (nowayout=0) intel_rng: FWH not detected Yenta: ISA IRQ mask 0x0838, PCI irq 6 Socket status: 3410 Yenta: Raising subordinate bus# of parent bus (#02) from #0a to #0e pcmcia: parent PCI bridge I/O window: 0x3000 - 0x3fff cs: IO port probe 0x3000-0x3fff: clean. pcmcia: parent PCI bridge Memory window: 0xe020 - 0xe07f pcmcia: parent PCI bridge Memory window: 0x3000 - 0x3bff ACPI: PCI Interrupt Link [LNKE] enabled at IRQ 10 ACPI: PCI Interrupt :02:04.0[A] - Link [LNKE] - GSI 10 (level, low) - IRQ 10 ipw2200: Detected Intel PRO/Wireless 2200BG Network Connection pccard: PCMCIA card inserted into slot 2 cs: memory probe 0xe020-0xe07f: excluding 0xe020-0xe025 pcmcia: registering new device pcmcia2.0 And then it hangs, but continues after 60 seconds. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (990, 'testing'), (500, 'oldstable'), (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.21-1-686 (SMP w/1 CPU core) Locale: LANG=de_AT.UTF-8, LC_CTYPE=de_AT.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#430779: linux-image-2.6.21-2-686: System seems to have microhangs, especially the mouse and sound are affected.
Package: linux-image-2.6.21-2-686 Severity: important This bug is a regression from linux-image-2.6.18-4-686 2.6.18.dfsg.1-1 When booted with 2.6.21, the mouse pointer moves with an unacceptable delay. Sound played with xmms has interrupts, and even now, while typing this report on the console, some characters appear with a delay on the screen, (or disappear with delay when I remove something) At least the mouse issue can be improved slightly setting cpufreq governor to userspace and setting the highest possible cpu frequency. I guess this report is not very useful, because I don't provide any logfiles. Can you give me any hints, how to produce something useful? -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (990, 'testing'), (500, 'oldstable'), (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.21-1-686 (SMP w/1 CPU core) Locale: LANG=de_AT.UTF-8, LC_CTYPE=de_AT.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#430779: linux-image-2.6.21-2-686: System seems to have microhangs, especially the mouse and sound are affected.
userspace cpufreqd are mostly useless, use ondemand echo ondemand /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor That was the first thing I did after I found out that it's a little bit better (the sound was a little bit less crippled) without any cpu frequency scaling. But unfortunately it does not help, at least the experience is the same. And even with the lowest frequency (600 Mhz), letters should not appear delayed in vim on the console if you type a bug report, no matter how stupid the cpufreqd is. No matter what scaling I use under 2.6.18, I have no issues at all with that kernel. Willi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#430779: linux-image-2.6.21-2-686: System seems to have microhangs, especially the mouse and sound are affected.
dmesg output and lsmod output attached. Note the lines PCI: Transparent bridge - :00:1e.0 PCI: Bus #03 (-#06) is hidden behind transparent bridge #02 (-#02) (try 'pci=assign-busses') Please report the result to linux-kernel to fix this permanently PCI: Bus #07 (-#0a) is hidden behind transparent bridge #02 (-#02) (try 'pci=assign-busses') Please report the result to linux-kernel to fix this permanently PCI: Bus #0b (-#0e) is hidden behind transparent bridge #02 (-#02) (try 'pci=assign-busses') Please report the result to linux-kernel to fix this permanently Are these bugs related to this lines? Willi Linux version 2.6.21-1-686 (Debian 2.6.21-4) ([EMAIL PROTECTED]) (gcc version 4.1.3 20070518 (prerelease) (Debian 4.1.2-8)) #1 SMP Sat May 26 16:14:59 UTC 2007 BIOS-provided physical RAM map: sanitize start sanitize end copy_e820_map() start: size: 0009f800 end: 0009f800 type: 1 copy_e820_map() type is E820_RAM copy_e820_map() start: 0009f800 size: 0800 end: 000a type: 2 copy_e820_map() start: 000ce000 size: 2000 end: 000d type: 2 copy_e820_map() start: 000dc000 size: 00024000 end: 0010 type: 2 copy_e820_map() start: 0010 size: 1ede end: 1eee type: 1 copy_e820_map() type is E820_RAM copy_e820_map() start: 1eee size: c000 end: 1eeec000 type: 3 copy_e820_map() start: 1eeec000 size: 00014000 end: 1ef0 type: 4 copy_e820_map() start: 1ef0 size: 0110 end: 2000 type: 2 copy_e820_map() start: fec1 size: 0001 end: fec2 type: 2 copy_e820_map() start: ff80 size: 0040 end: ffc0 type: 2 copy_e820_map() start: fc00 size: 0400 end: 0001 type: 2 BIOS-e820: - 0009f800 (usable) BIOS-e820: 0009f800 - 000a (reserved) BIOS-e820: 000ce000 - 000d (reserved) BIOS-e820: 000dc000 - 0010 (reserved) BIOS-e820: 0010 - 1eee (usable) BIOS-e820: 1eee - 1eeec000 (ACPI data) BIOS-e820: 1eeec000 - 1ef0 (ACPI NVS) BIOS-e820: 1ef0 - 2000 (reserved) BIOS-e820: fec1 - fec2 (reserved) BIOS-e820: ff80 - ffc0 (reserved) BIOS-e820: fc00 - 0001 (reserved) 0MB HIGHMEM available. 494MB LOWMEM available. Entering add_active_range(0, 0, 126688) 0 entries of 256 used Zone PFN ranges: DMA 0 - 4096 Normal 4096 - 126688 HighMem126688 - 126688 early_node_map[1] active PFN ranges 0:0 - 126688 On node 0 totalpages: 126688 DMA zone: 32 pages used for memmap DMA zone: 0 pages reserved DMA zone: 4064 pages, LIFO batch:0 Normal zone: 957 pages used for memmap Normal zone: 121635 pages, LIFO batch:31 HighMem zone: 0 pages used for memmap DMI present. ACPI: RSDP 000F6040, 0014 (r0 ACER ) ACPI: RSDT 1EEE57BD, 0030 (r1 ACER TM6000 20020608 LTP0) ACPI: FACP 1EEEBF2C, 0074 (r1 ACER TM6000 20020608 PTL50) ACPI Warning (tbfadt-0360): Ignoring BIOS FADT r1 C-state control [20070126] ACPI: DSDT 1EEE57ED, 673F (r1 ACER TM6000 20020608 MSFT 10E) ACPI: FACS 1EEFCFC0, 0040 ACPI: HPET 1EEEBFA0, 0038 (r1 ACER TM6000 20020608 PTL 0) ACPI: BOOT 1EEEBFD8, 0028 (r1 ACER TM6000 20020608 LTP1) ACPI: PM-Timer IO Port: 0x1008 ACPI: HPET id: 0x8086a201 base: 0x0 Allocating PCI resources starting at 3000 (gap: 2000:dec1) Built 1 zonelists. Total pages: 125699 Kernel command line: root=/dev/hda10 ro vga=791 resume=/dev/hda6 Local APIC disabled by BIOS -- you can enable it with lapic mapped APIC to d000 (013ea000) Enabling fast FPU save and restore... done. Enabling unmasked SIMD FPU exception support... done. Initializing CPU#0 PID hash table entries: 2048 (order: 11, 8192 bytes) Detected 1694.584 MHz processor. Console: colour dummy device 80x25 Dentry cache hash table entries: 65536 (order: 6, 262144 bytes) Inode-cache hash table entries: 32768 (order: 5, 131072 bytes) Memory: 493508k/506752k available (1661k kernel code, 12612k reserved, 637k data, 212k init, 0k highmem) virtual kernel memory layout: fixmap : 0xfff4f000 - 0xf000 ( 704 kB) pkmap : 0xff80 - 0xffc0 (4096 kB) vmalloc : 0xdf80 - 0xff7fe000 ( 511 MB) lowmem : 0xc000 - 0xdeee ( 494 MB) .init : 0xc0345000 - 0xc037a000 ( 212 kB) .data : 0xc029f405 - 0xc033e834 ( 637 kB) .text : 0xc010 - 0xc029f405 (1661 kB) Checking if this processor honours the WP bit even in supervisor mode... Ok. Calibrating delay using timer specific routine.. 3391.18 BogoMIPS (lpj=6782372) Security Framework v1.0.0
Bug#430779: linux-image-2.6.21-2-686: System seems to have microhangs, especially the mouse and sound are affected.
Are these bugs related to this lines? Willi yes maybe, do what they say, but before try really latest, see trunk http://wiki.debian.org/DebianKernel The bad news: These lines did not go away. the good news: The issue described in this bug report went away, and the whole system even feels faster than with 2.6.18. This is really cool. Just for the record: I used $ dmesg | head -1 Linux version 2.6.22-rc6-686 (Debian 2.6.22~rc6-1~experimental.1~snapshot.9027) ([EMAIL PROTECTED]) (gcc version 4.1.3 20070601 (prerelease) (Debian 4.1.2-12)) #1 SMP Wed Jun 27 00:31:19 UTC 2007 another bad news is that the issue described in bug 430776 did not go away. Willi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: svn /patch-tracking/
I've found http://svn.debian.org/wsvn/kernel/patch-tracking/ a really useful way of knowing what the kernel team thinks about kernel vulnerabilities. But it seems to have gone away. Has it moved somewhere else, or is there a better way for me to check debians position against http://svn.debian.org/wsvn/kernel-sec/patch-tracking/ http://svn.debian.org/wsvn/kernel/?rev=7040sc=1 The svn log has the reason. Willi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#314954: fixed in 2.6.16-git16
Hi! This bug is fixed in 2.6.16-git16, commit aef4e266964bc15861b5835c1f5b9d2ebc155c2a Willi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
linux-doc-* Package
Hi! Why was the linux-doc-* package removed? Is that a bug or was it removed deliberately? I cannot find anything matching linux-doc in the changelog since 2.6.14, that's why I am asking. Willi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#314954: [Linux-usb-users] Re: logitech usb mouse dies
I've tried; it wasn't accepted. The patch below should be more acceptable to the maintainer. Try it instead of the other one; it ought to get rid of all those error messages showing up in the log as well as fixing the mouse problem. That is, it won't prevent the actual errors from occurring at a rate of ~1 per minute -- it will just stop the driver from logging the messages. If it works well, I'll submit it. OK, it works well for me since 8 days. I hope it will be included in one of the next kernel releases. Willi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#314954: [Linux-usb-users] Re: logitech usb mouse dies
I've dropped Helmut Zeisel as cc: and will send him notice a when the issue is resolved. He can read our conversation in the mailing list archive anyway. I've tried; it wasn't accepted. The patch below should be more acceptable to the maintainer. Try it instead of the other one; it ought to get rid of all those error messages showing up in the log as well as fixing the mouse problem. That is, it won't prevent the actual errors from occurring at a rate of ~1 per minute -- it will just stop the driver from logging the messages. If it works well, I'll submit it. I'll try. - Now see what's happening when I unplug the mouse fast: Dec 21 14:40:44 wmiwilli kernel: drivers/usb/input/hid-core.c: input irq status -84 received Dec 21 14:40:44 wmiwilli last message repeated 2 times ... - When I unplug it slowly: Dec 21 14:41:27 wmiwilli kernel: drivers/usb/input/hid-core.c: input irq status -84 received Dec 21 14:41:28 wmiwilli last message repeated 7 times .. I don't see any significant difference. Did I miss something? I was just thinking what will happen if someone unplugs the mouse (or another HID device) not completely. Will that fill up the kernel logs? Willi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#314954: [Linux-usb-users] Re: logitech usb mouse dies
That particular error generally means that something is interfering with the USB data transmission. It could be a poor cable connection, or it could be the mouse sending a bad signal, or it could be some sort of outside electromagnetic interference. I would like to test with other USB mice. Unfortunately, I only have these two logitech mice for testing. By the way, it looks like you don't need the entire patch. Just the parts the remove the lines saying case -EILSEQ: should be enough to help. confirmed. What's needed to get that into the offical kernel releases? For reference, some more log snippets: - Log snippet from today to see the frequency: Dec 21 11:32:27 wmiwilli kernel: drivers/usb/input/hid-core.c: input irq status -84 received Dec 21 11:34:12 wmiwilli kernel: drivers/usb/input/hid-core.c: input irq status -84 received Dec 21 11:37:28 wmiwilli kernel: drivers/usb/input/hid-core.c: input irq status -84 received Dec 21 11:38:54 wmiwilli kernel: drivers/usb/input/hid-core.c: input irq status -84 received Dec 21 11:40:06 wmiwilli kernel: drivers/usb/input/hid-core.c: input irq status -84 received Dec 21 11:41:04 wmiwilli kernel: drivers/usb/input/hid-core.c: input irq status -84 received Dec 21 11:53:06 wmiwilli kernel: drivers/usb/input/hid-core.c: input irq status -84 received Dec 21 11:54:27 wmiwilli kernel: drivers/usb/input/hid-core.c: input irq status -84 received Dec 21 11:55:17 wmiwilli kernel: drivers/usb/input/hid-core.c: input irq status -84 received Dec 21 11:57:42 wmiwilli kernel: drivers/usb/input/hid-core.c: input irq status -84 received Dec 21 12:53:23 wmiwilli kernel: drivers/usb/input/hid-core.c: input irq status -84 received Dec 21 12:54:36 wmiwilli kernel: drivers/usb/input/hid-core.c: input irq status -84 received Dec 21 12:55:17 wmiwilli kernel: drivers/usb/input/hid-core.c: input irq status -84 received Dec 21 12:56:04 wmiwilli kernel: drivers/usb/input/hid-core.c: input irq status -84 received Dec 21 12:57:47 wmiwilli kernel: drivers/usb/input/hid-core.c: input irq status -84 received Dec 21 13:02:23 wmiwilli kernel: drivers/usb/input/hid-core.c: input irq status -84 received Dec 21 13:03:17 wmiwilli kernel: drivers/usb/input/hid-core.c: input irq status -84 received Dec 21 13:03:47 wmiwilli kernel: drivers/usb/input/hid-core.c: input irq status -84 received Dec 21 13:05:01 wmiwilli last message repeated 2 times Dec 21 13:06:46 wmiwilli kernel: drivers/usb/input/hid-core.c: input irq status -84 received Dec 21 13:07:47 wmiwilli last message repeated 2 times Dec 21 13:08:47 wmiwilli kernel: drivers/usb/input/hid-core.c: input irq status -84 received Dec 21 13:09:54 wmiwilli kernel: drivers/usb/input/hid-core.c: input irq status -84 received Dec 21 13:11:07 wmiwilli kernel: drivers/usb/input/hid-core.c: input irq status -84 received Dec 21 13:13:15 wmiwilli kernel: drivers/usb/input/hid-core.c: input irq status -84 received Dec 21 13:13:52 wmiwilli kernel: drivers/usb/input/hid-core.c: input irq status -84 received Dec 21 13:14:55 wmiwilli kernel: drivers/usb/input/hid-core.c: input irq status -84 received Dec 21 13:20:48 wmiwilli kernel: drivers/usb/input/hid-core.c: input irq status -84 received Dec 21 13:21:33 wmiwilli kernel: drivers/usb/input/hid-core.c: input irq status -84 received Dec 21 13:23:14 wmiwilli kernel: drivers/usb/input/hid-core.c: input irq status -84 received Dec 21 13:24:26 wmiwilli kernel: drivers/usb/input/hid-core.c: input irq status -84 received Dec 21 13:25:45 wmiwilli kernel: drivers/usb/input/hid-core.c: input irq status -84 received Dec 21 13:28:41 wmiwilli kernel: drivers/usb/input/hid-core.c: input irq status -84 received Dec 21 14:18:15 wmiwilli kernel: drivers/usb/input/hid-core.c: input irq status -84 received Dec 21 14:18:28 wmiwilli kernel: drivers/usb/input/hid-core.c: input irq status -84 received Dec 21 14:30:33 wmiwilli kernel: drivers/usb/input/hid-core.c: input irq status -84 received Dec 21 14:31:21 wmiwilli kernel: drivers/usb/input/hid-core.c: input irq status -84 received Dec 21 14:37:47 wmiwilli kernel: drivers/usb/input/hid-core.c: input irq status -84 received Dec 21 14:39:05 wmiwilli kernel: drivers/usb/input/hid-core.c: input irq status -84 received - Now see what's happening when I unplug the mouse fast: Dec 21 14:40:44 wmiwilli kernel: drivers/usb/input/hid-core.c: input irq status -84 received Dec 21 14:40:44 wmiwilli last message repeated 2 times Dec 21 14:40:44 wmiwilli kernel: hub 2-0:1.0: state 5 ports 2 chg evt 0002 Dec 21 14:40:44 wmiwilli kernel: uhci_hcd :00:1d.1: port 1 portsc 008a,00 Dec 21 14:40:44 wmiwilli kernel: hub 2-0:1.0: port 1, status 0100, change 0003, 12 Mb/s Dec 21 14:40:44 wmiwilli kernel: usb 2-1: USB disconnect, address 2 Dec 21 14:40:44 wmiwilli kernel: usb 2-1: usb_disable_device nuking all URBs Dec 21 14:40:44 wmiwilli kernel: uhci_hcd :00:1d.1: shutdown urb dd36b740 pipe 40408280 ep1in-intr Dec 21 14:40:44 wmiwilli kernel: usb 2-1: unregistering
Bug#314954: [Linux-usb-users] Re: logitech usb mouse dies
Yes. Read Documentation/usb/usbmon.txt in the kernel source. Ok, here is what I did: cat 2t - minimize the gnome-terminal - surfed the web - suddenly mouse died - Strg + Alt + F1, Alt+ F7 - reopened the terminal - marked the last 200 lines - pasted in file - grepped for the mouse identifier 002:01 here are the last lines of that output: ddd8de40 605937824 C Ii:002:01 0 4 = 00010100 ddd8de40 605937845 S Ii:002:01 -115 4 = 00010100 ddd8de40 605969820 C Ii:002:01 0 4 = 0001 ddd8de40 605969843 S Ii:002:01 -115 4 = 0001 ddd8de40 606809680 C Ii:002:01 0 4 = 01ff ddd8de40 606809704 S Ii:002:01 -115 4 = 01ff ddd8de40 607105630 C Ii:002:01 0 4 = 00ff ddd8de40 607105656 S Ii:002:01 -115 4 = 00ff ddd8de40 607121630 C Ii:002:01 0 4 = 00ff ddd8de40 607121656 S Ii:002:01 -115 4 = 00ff ddd8de40 607169624 C Ii:002:01 0 4 = 00ff ddd8de40 607169655 S Ii:002:01 -115 4 = 00ff ddd8de40 612744692 C Ii:002:01 0 4 = 00ff ddd8de40 612744717 S Ii:002:01 -115 4 = 00ff ddd8de40 613024644 C Ii:002:01 0 4 = 00ff ddd8de40 613024670 S Ii:002:01 -115 4 = 00ff ddd8de40 613040644 C Ii:002:01 0 4 = 00ff ddd8de40 613040670 S Ii:002:01 -115 4 = 00ff ddd8de40 613056640 C Ii:002:01 0 4 = 00ff ddd8de40 613056665 S Ii:002:01 -115 4 = 00ff ddd8de40 613072638 C Ii:002:01 0 4 = 00ff ddd8de40 613072661 S Ii:002:01 -115 4 = 00ff ddd8de40 613088637 C Ii:002:01 0 4 = 00ff ddd8de40 613088667 S Ii:002:01 -115 4 = 00ff ddd8de40 613112637 C Ii:002:01 0 4 = 00ff ddd8de40 613112671 S Ii:002:01 -115 4 = 00ff ddd8de40 613760520 C Ii:002:01 0 4 = 00ff ddd8de40 613760545 S Ii:002:01 -115 4 = 00ff ddd8de40 613800519 C Ii:002:01 0 4 = 00ff ddd8de40 613800546 S Ii:002:01 -115 4 = 00ff ddd8de40 614552386 C Ii:002:01 0 4 = 00ff ddd8de40 614552411 S Ii:002:01 -115 4 = 00ff ddd8de40 614568386 C Ii:002:01 0 4 = 00ff ddd8de40 614568411 S Ii:002:01 -115 4 = 00ff ddd8de40 614584385 C Ii:002:01 0 4 = 00ff ddd8de40 614584412 S Ii:002:01 -115 4 = 00ff ddd8de40 614600387 C Ii:002:01 0 4 = 00ff ddd8de40 614600414 S Ii:002:01 -115 4 = 00ff ddd8de40 614616379 C Ii:002:01 0 4 = 00ff ddd8de40 614616401 S Ii:002:01 -115 4 = 00ff ddd8de40 614672373 C Ii:002:01 0 4 = 00ff ddd8de40 614672399 S Ii:002:01 -115 4 = 00ff ddd8de40 617215945 C Ii:002:01 0 4 = 00ff ddd8de40 617215970 S Ii:002:01 -115 4 = 00ff ddd8de40 617879834 C Ii:002:01 0 4 = 00ff ddd8de40 617879859 S Ii:002:01 -115 4 = 00ff ddd8de40 617911835 C Ii:002:01 0 4 = 00ff ddd8de40 617911864 S Ii:002:01 -115 4 = 00ff ddd8de40 618383751 C Ii:002:01 0 4 = 00ff ddd8de40 618383777 S Ii:002:01 -115 4 = 00ff ddd8de40 618431747 C Ii:002:01 0 4 = 00ff ddd8de40 618431774 S Ii:002:01 -115 4 = 00ff ddd8de40 723190277 C Ii:002:01 -84 0 ddd8de40 769897561 S Ii:002:01 -115 4 = 00ff ddd8de40 769910480 C Ii:002:01 0 4 = 00838200 ddd8de40 769910495 S Ii:002:01 -115 4 = 00838200 Does that somehow help to track it down? The event in µs 723190277 seems very suspicious to me. thanks Willi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#314954: [Linux-usb-users] Re: logitech usb mouse dies
Yes indeed. This looks very similar to the problem reported in
http://bugzilla.kernel.org/show_bug.cgi?id=4916
See especially comment #19.
It's possible that the patch adding an HID reset routine (the last
attachment in the bug report) will work for you. You might have to fiddle
with it a little, because it is now four months old.
Yes, it works. No more freezing mouse despite the cold weather outside :-)
This _should_ have shown up in the dmesg log if you had CONFIG_USB_DEBUG
turned on. Make sure you have it on when running more tests.
Do you mean, it should have shown up without this patch? Since you told
me to enable CONFIG_USB_DEBUG, I had it always on while testing, but I
never saw that messages. Or do you mean, it is bug that these messages
weren't reported when CONFIG_USB_DEBUG is on?
The last 4 kernel messages since the first boot with your patch:
Dec 17 20:50:30 . kernel: mtrr: 0xe800,0x800 overlaps existing
0xe800,0x100
Dec 17 21:01:25 . kernel: drivers/usb/input/hid-core.c: input irq status
-84 received
Dec 17 21:25:43 . kernel: drivers/usb/input/hid-core.c: input irq status
-84 received
Dec 17 21:29:56 . kernel: drivers/usb/input/hid-core.c: input irq status
-84 received
I'm CCing Helmut Zeisel, he reported the same issue in an austrian
newsgroup. Helmut, you might want to try attached patch to fix our
dying mouse issue.
Willi
--- hid.h.bak 2005-12-17 20:25:41.0 +0100
+++ hid.h 2005-12-17 21:12:07.0 +0100
@@ -396,6 +396,8 @@
struct urb *urbin; /* Input URB */
char *inbuf; /* Input buffer */
dma_addr_t inbuf_dma; /* Input buffer dma */
+ int in_error_cnt; /* Input error counter */
+ struct work_struct work; /* Perform asynchronous reset */
struct urb *urbctrl; /* Control URB */
struct usb_ctrlrequest *cr; /* Control request struct */
--- hid-core.c.bak 2005-12-17 20:26:53.0 +0100
+++ hid-core.c 2005-12-17 20:31:41.0 +0100
@@ -909,6 +909,29 @@
}
/*
+ * Request a device reset.
+ */
+static void hid_reset(void *_hid)
+{
+ struct hid_device *hid = _hid;
+ int rc, result;
+
+ hid-in_error_cnt = 0;
+ rc = result = usb_lock_device_for_reset(hid-dev, hid-intf);
+ if (rc = 0) {
+ result = usb_reset_device(hid-dev);
+ if (result == 0 hid-open)
+ result = usb_submit_urb(hid-urbin, GFP_NOIO);
+ if (rc)
+ usb_unlock_device(hid-dev);
+ }
+ if (result 0)
+ warn(can't reset device, %s-%s/input%d, result %d,
+hid-dev-bus-bus_name, hid-dev-devpath,
+hid-ifnum, result);
+}
+
+/*
* Input interrupt completion handler.
*/
@@ -919,18 +942,20 @@
switch (urb-status) {
case 0: /* success */
+ hid-in_error_cnt = 0;
hid_input_report(HID_INPUT_REPORT, urb, 1, regs);
break;
case -ECONNRESET: /* unlink */
case -ENOENT:
case -EPERM:
case -ESHUTDOWN: /* unplug */
- case -EILSEQ: /* unplug timeout on uhci */
return;
- case -ETIMEDOUT: /* NAK */
- break;
default: /* error */
warn(input irq status %d received, urb-status);
+ if (++hid-in_error_cnt = 10) {
+schedule_work(hid-work);
+return;
+ }
}
status = usb_submit_urb(urb, SLAB_ATOMIC);
@@ -1099,7 +1124,6 @@
case 0: /* success */
break;
case -ESHUTDOWN: /* unplug */
- case -EILSEQ: /* unplug timeout on uhci */
unplug = 1;
case -ECONNRESET: /* unlink */
case -ENOENT:
@@ -1147,7 +1171,6 @@
hid_input_report(hid-ctrl[hid-ctrltail].report-type, urb, 0, regs);
break;
case -ESHUTDOWN: /* unplug */
- case -EILSEQ: /* unplug timectrl on uhci */
unplug = 1;
case -ECONNRESET: /* unlink */
case -ENOENT:
@@ -1781,6 +1804,7 @@
hid-urbctrl-transfer_dma = hid-ctrlbuf_dma;
hid-urbctrl-transfer_flags |= (URB_NO_TRANSFER_DMA_MAP | URB_NO_SETUP_DMA_MAP);
+ INIT_WORK(hid-work, hid_reset, hid);
return hid;
fail:
@@ -1808,6 +1832,7 @@
usb_kill_urb(hid-urbin);
usb_kill_urb(hid-urbout);
usb_kill_urb(hid-urbctrl);
+ flush_scheduled_work();
if (hid-claimed HID_CLAIMED_INPUT)
hidinput_disconnect(hid);
Bug#314954: [Linux-usb-users] Re: logitech usb mouse dies
I now recreated the patch in a more usable way.
BTW:
Dec 17 20:50:30 wmiwilli kernel: mtrr: 0xe800,0x800 overlaps
existing 0xe800,0x100
Dec 17 21:01:25 wmiwilli kernel: drivers/usb/input/hid-core.c: input irq
status -84 received
Dec 17 21:25:43 wmiwilli kernel: drivers/usb/input/hid-core.c: input irq
status -84 received
Dec 17 21:29:56 wmiwilli kernel: drivers/usb/input/hid-core.c: input irq
status -84 received
Dec 17 21:56:45 wmiwilli kernel: drivers/usb/input/hid-core.c: input irq
status -84 received
Dec 17 21:58:49 wmiwilli kernel: drivers/usb/input/hid-core.c: input irq
status -84 received
Dec 17 22:07:52 wmiwilli kernel: drivers/usb/input/hid-core.c: input irq
status -84 received
Dec 17 22:08:26 wmiwilli kernel: drivers/usb/input/hid-core.c: input irq
status -84 received
Dec 17 22:10:29 wmiwilli kernel: drivers/usb/input/hid-core.c: input irq
status -84 received
There seems to be relation between mouse usage and the -84 signal: The
more I use the mouse the less it occurs.
Willi
diff -ru rr/linux-source-2.6.14/drivers/usb/input/hid-core.c
linux-source-2.6.14/drivers/usb/input/hid-core.c
--- rr/linux-source-2.6.14/drivers/usb/input/hid-core.c 2005-10-28
02:02:08.0 +0200
+++ linux-source-2.6.14/drivers/usb/input/hid-core.c2005-12-17
20:31:41.0 +0100
@@ -909,6 +909,29 @@
}
/*
+ * Request a device reset.
+ */
+static void hid_reset(void *_hid)
+{
+ struct hid_device *hid = _hid;
+ int rc, result;
+
+ hid-in_error_cnt = 0;
+ rc = result = usb_lock_device_for_reset(hid-dev, hid-intf);
+ if (rc = 0) {
+ result = usb_reset_device(hid-dev);
+ if (result == 0 hid-open)
+ result = usb_submit_urb(hid-urbin, GFP_NOIO);
+ if (rc)
+ usb_unlock_device(hid-dev);
+ }
+ if (result 0)
+ warn(can't reset device, %s-%s/input%d, result %d,
+ hid-dev-bus-bus_name, hid-dev-devpath,
+ hid-ifnum, result);
+}
+
+/*
* Input interrupt completion handler.
*/
@@ -919,18 +942,20 @@
switch (urb-status) {
case 0: /* success */
+ hid-in_error_cnt = 0;
hid_input_report(HID_INPUT_REPORT, urb, 1, regs);
break;
case -ECONNRESET: /* unlink */
case -ENOENT:
case -EPERM:
case -ESHUTDOWN:/* unplug */
- case -EILSEQ: /* unplug timeout on uhci */
return;
- case -ETIMEDOUT:/* NAK */
- break;
default:/* error */
warn(input irq status %d received, urb-status);
+ if (++hid-in_error_cnt = 10) {
+ schedule_work(hid-work);
+ return;
+ }
}
status = usb_submit_urb(urb, SLAB_ATOMIC);
@@ -1099,7 +1124,6 @@
case 0: /* success */
break;
case -ESHUTDOWN:/* unplug */
- case -EILSEQ: /* unplug timeout on uhci */
unplug = 1;
case -ECONNRESET: /* unlink */
case -ENOENT:
@@ -1147,7 +1171,6 @@
hid_input_report(hid-ctrl[hid-ctrltail].report-type, urb, 0, regs);
break;
case -ESHUTDOWN:/* unplug */
- case -EILSEQ: /* unplug timectrl on uhci */
unplug = 1;
case -ECONNRESET: /* unlink */
case -ENOENT:
@@ -1781,6 +1804,7 @@
hid-urbctrl-transfer_dma = hid-ctrlbuf_dma;
hid-urbctrl-transfer_flags |= (URB_NO_TRANSFER_DMA_MAP |
URB_NO_SETUP_DMA_MAP);
+ INIT_WORK(hid-work, hid_reset, hid);
return hid;
fail:
@@ -1808,6 +1832,7 @@
usb_kill_urb(hid-urbin);
usb_kill_urb(hid-urbout);
usb_kill_urb(hid-urbctrl);
+ flush_scheduled_work();
if (hid-claimed HID_CLAIMED_INPUT)
hidinput_disconnect(hid);
diff -ru rr/linux-source-2.6.14/drivers/usb/input/hid.h
linux-source-2.6.14/drivers/usb/input/hid.h
--- rr/linux-source-2.6.14/drivers/usb/input/hid.h 2005-10-28
02:02:08.0 +0200
+++ linux-source-2.6.14/drivers/usb/input/hid.h 2005-12-17 21:12:07.0
+0100
@@ -396,6 +396,8 @@
struct urb *urbin; /*
Input URB */
char *inbuf;/*
Input buffer */
dma_addr_t inbuf_dma; /*
Input buffer dma */
+ int in_error_cnt;
Bug#314954: [Linux-usb-users] Re: logitech usb mouse dies
To get more information, turn on USB verbose debugging (CONFIG_USB_DEBUG) in the kernel configuration and rebuild the USB drivers. Post the kernel or dmesg log showing what happens when the connection is lost. I've used the debian source for that. They currently don't patch anything usb-related. I've set CONFIG_USB_DEBUG=y and changed the processor family to Pentium M. These are the only differences to the distributed debian kernels. Unfortunatly, when the connection is lost, there is no message in dmesg. And there's also no message when the connection is reactivated. (By chvt 1 sleep 1 chvt 7) when I unplug and replug the mouse, the following happens: hub 2-0:1.0: state 5 ports 2 chg evt 0004 uhci_hcd :00:1d.1: port 2 portsc 008a,00 hub 2-0:1.0: port 2, status 0100, change 0003, 12 Mb/s usb 2-2: USB disconnect, address 3 usb 2-2: usb_disable_device nuking all URBs usb 2-2: unregistering interface 2-2:1.0 usb 2-2:1.0: hotplug usb 2-2: unregistering device usb 2-2: hotplug hub 2-0:1.0: debounce: port 2: total 100ms stable 100ms status 0x100 hub 4-0:1.0: state 5 ports 6 chg evt 0010 ehci_hcd :00:1d.7: GetStatus port 4 status 001403 POWER sig=k CSC CONNECT hub 4-0:1.0: port 4, status 0501, change 0001, 480 Mb/s hub 4-0:1.0: debounce: port 4: total 100ms stable 100ms status 0x501 ehci_hcd :00:1d.7: port 4 low speed -- companion ehci_hcd :00:1d.7: GetStatus port 4 status 003002 POWER OWNER sig=se0 CSC hub 2-0:1.0: state 5 ports 2 chg evt 0004 uhci_hcd :00:1d.1: port 2 portsc 01a3,00 hub 2-0:1.0: port 2, status 0301, change 0001, 1.5 Mb/s hub 2-0:1.0: debounce: port 2: total 100ms stable 100ms status 0x301 usb 2-2: new low speed USB device using uhci_hcd and address 4 usb 2-2: skipped 1 descriptor after interface usb 2-2: default language 0x0409 usb 2-2: new device strings: Mfr=1, Product=2, SerialNumber=0 usb 2-2: Product: USB Mouse usb 2-2: Manufacturer: Logitech usb 2-2: hotplug usb 2-2: adding 2-2:1.0 (config #1, interface 0) usb 2-2:1.0: hotplug usbhid 2-2:1.0: usb_probe_interface usbhid 2-2:1.0: usb_probe_interface - got id input: USB HID v1.10 Mouse [Logitech USB Mouse] on usb-:00:1d.1-2 hub 2-0:1.0: state 5 ports 2 chg evt 0004 Is there some usb sniffer for linux around? Maybe that would shed some more light on this issue. Willi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: added memory protection from kernel 2.6.11 -- 2.6.12 ?
I was wondering if the current kernels (=2.6.12) have some kind of additional memory protection addded. Specifically, I'm trying to read from the process memory of another process (using gdb) which works just fine on kernel version up to (and including) 2.6.11. (This is inevitable for me since I'm currently playing with format string vulnerabilities to understand these kind of attacks.) I would like to know how to turn the mentioned protection off. If it is not possible, it would be great to get some hint which kernel code I would have to patch/modify to turn it off ;) I'm really no expert when it comes to linux kernel internals, but if you could read the memory of another process on a multitasking OS (without any guards), you should drop that OS ASAP. The only way in linux to attach to another process is (AFAIK) the ptrace call, and that's what you probably want to use (or rather, you will use a frontend like gdb program pid, to attach to a running process.) Your first example probably just works because the memory at this first instance of myshell is also a valid address in the second instance. In the second example that's not the case. And in your third example, you also tried a valid memory address of the second instance of your process. Willi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#314954: logitech usb mouse dies
I have already reported this bug in the Debian BTS with many details: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=314954 I have now tested with a second logitech mouse attached. Bus 004 Device 004: ID 04b4:6560 Cypress Semiconductor Corp. CY7C65640 USB-2.0 TetraHub Bus 004 Device 001: ID : Bus 002 Device 006: ID 046a:0004 Cherry GmbH Bus 002 Device 001: ID : Bus 001 Device 007: ID 046d:c00e Logitech, Inc. Optical Mouse Bus 001 Device 006: ID 046d:c00c Logitech, Inc. Optical Wheel Mouse Bus 001 Device 001: ID : Bus 003 Device 001: ID : It also loses the connection after a random amount of time (or maybe mouse move distance), but they lose the connection independently of each other. (Note that both mice are wheel mice, and share the same design, doesn't make sense to me that one is named .. Mouse and one .. Wheel Mouse) Willi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#295627: seems fixed
It seems this bug is fixed: (linux-2.6.12 is from kernel.org)
$ grep usp -A4 -B4 linux-2.6.12/include/asm-sparc64/compat.h
static __inline__ void __user *compat_alloc_user_space(long len)
{
struct pt_regs *regs = current_thread_info()-kregs;
unsigned long usp = regs-u_regs[UREG_I6];
if (!(test_thread_flag(TIF_32BIT)))
usp += STACK_BIAS;
else
usp = 0xUL;
return (void __user *) (usp - len);
}
struct compat_ipc64_perm {
compat_key_t key;
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#314954: bug still reproduceable
Hi! I can still reproduce this bug. The strange thing is: sometimes it happens very often, sometimes I have no problems for several hours. I have now disabled gpm, and since then, the workaround without unplugging the mouse is reduced to Strg + Alt + F1, Alt + F7. So it seems the mouse restarts when all its users stop reading it. To repeat the important facts: Mouse device: /dev/input/mice, and I have second mouse, a touchpad, which continues to work when the Logitech mouse freezes. As I have already written, someone else who doesn't use debian is also affected. Isn't this bug a good candidate to forward upstream? Willi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Note about unfortunate message from linux-image
Hi! I'm not reporting this as bug, because I think I've read this is fixed in the kernel-package in experimental anyway. Just in case it's not fixed... The bug is that linux-image complains about a possible previous install of the kernel, probably just because the linux-headers that were unpacked before, but in the same apt-get call, put the build symlink in /lib/modules/2.6.14-2/. Willi typescript Description: Binary data
Bug#337045: race condition?: sometimes fails to correctly detect my harddisk
I've seen similar symptoms (missing devices at boot) go away when I've increased the delay after the call to udevsynthesize in the initrd's init. You can try increasing the argument to sleep in /usr/share/initramfs-tools/init (around line 72): # Populate /dev tree log_begin_msg Initializing /dev mkdir /dev/.udevdb UDEVD_EXPECTED_SEQNUM=$(($(cat /sys/kernel/hotplug_seqnum) + 1)) udevd --daemon udevsynthesize sleep 2 log_end_msg Try changing 'sleep 2' to 'sleep 20', regenerate the initrd and reboot. Let us know if it fixes the problem. I changed it to sleep 10, and up to now, it hasn't occured again. thanks. However, I would ask you not to call that a fix, it's just a quite ugly workaround, something that should not end up in a stable release. And it makes another issue more annoying because the fbcon module is currently loaded after the sleep, so I have for about 12 seconds a blank screen (with vga=791). With sleep 2, it was about 4 seconds, something that was more or less acceptable. The proper fix is to avoid the race condition, by appropriate locking code in the concerned software. Willi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#337045: linux-image-2.6.14-1-686: race condition?: sometimes fails to correctly detect my harddisk
hda: , ATA disk drive .. ide0: I/O ressource 0x3F6 - 0x3F6 not free hda: Error, ports already in use ide0 at 0x1f0-0x1f7, 0x3f6 in irq 14 Sorry for the incomplete report, I have no idea where I could save the dmesg output the next time. Ok, today I got the same problem again, but this time both hda and hdc (cd-drive) were missing. Any ideas how to track the issue down? Willi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#333003: linux-image-2.6.14-1-686: vesafb is missing on video/drivers modules
[resend, it was accidently sent to @lists.debian.org instead of @bugs.debian.org] It was suggested to me by Sven Luther, that as vesafb is now compiled into the kernel, it would make sense to do the same with fbcon. Can anyone comment on this idea? It sounds like it would solve most of the problems we are seeing, without needing to muck around with isnmoding fbcon by itself. I've tried with initramfs-tools now, and that works (some messages will be lost to a short period with a blank screen, but that's minor). Maybe initramfs-tools should be preferred over yaird, when choosing the ramdisk generation tool? Willi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#337045: linux-image-2.6.14-1-686: race condition?: sometimes fails to correctly detect my harddisk
Package: linux-image-2.6.14-1-686 Version: 2.6.14-2 Severity: important First try: I got the following messages during boot (I noted them on paper, so there might be some mistakes) hda: , ATA disk drive .. ide0: I/O ressource 0x3F6 - 0x3F6 not free hda: Error, ports already in use ide0 at 0x1f0-0x1f7, 0x3f6 in irq 14 And then some lines later a message complaing that it could not find /dev/hda10, and the busybox console appears. ls /dev/hda10 - file not found. I'm currently using initramfs-tools. second try: ok, reboot by reset. It fails again, unfortunately I didn't note the error message down, but there was another message. third try: reboot, without any big issues. Sorry for the incomplete report, I have no idea where I could save the dmesg output the next time. -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.14-1-686 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) Versions of packages linux-image-2.6.14-1-686 depends on: ii initramfs-tools [linux-initra 0.37 tools for generating an initramfs ii module-init-tools 3.2-pre9-2 tools for managing Linux kernel mo linux-image-2.6.14-1-686 recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#337045: linux-image-2.6.14-1-686: I hate to me too, but me too
One thing I did do directly before this error is try and remove tg3 and replace with the non-free bcm5700 network card driver (the reboot was supposed to finish the replacement, until I realised the initramfs is loading all my modules now- which is a different bag of fun for a different bug report). I don't think this is the cause. I booted successfully at least once with the same initrd and kernel on the same machine before I had that problem. However, we both seem to have similar intel centrino chipsets. Is your machine a 1.5 Mhz Centrino (guess because of the ipw2100 module)? I have 1.7 Mhz Centrino. Maybe the bug is related to our hardware? Willi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#333003: linux-image-2.6.14-1-686: vesafb is missing on video/drivers modules
Some more info: there's no error message, the kernel output behaves as vesafb would work. (vga=0x305) $ egrep -i 'vesa|fb' /var/log/messages | cut -b 26- kernel: vesafb: framebuffer at 0xe800, mapped to 0xde88, using 1536k, total 32576k kernel: vesafb: mode is 1024x768x8, linelength=1024, pages=41 kernel: vesafb: protected mode interface info at 00ff:44f0 kernel: vesafb: scrolling: redraw kernel: vesafb: Pseudocolor: size=8:8:8:8, shift=0:0:0:0 kernel: vesafb: Mode is VGA compatible kernel: fb0: VESA VGA frame buffer device I remember that problem first occured with 2.6.13-1 from experimental. Should I verify that? Willi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
what happened to vesafb support in 2.6.13-1?
Hi! Can someone please tell me what happened to vesafb support in 2.6.13-1? (CONFIG_FB_VESA=m in 2.6.12-10 vs. not set in 2.6.13-1) I get a blank screen when booting with vga=791. Willi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: what happened to vesafb support in 2.6.13-1?
the old legacy modular vesafb patch got dropped. and it seems it was overlooked to set them to yes. thanks for the quick response. Willi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#314954: gpm restart as solution
thanks for your feedback. tg3 is again included in 2.6.12 due to relicensing of the firmware. please try that linux image. As I have already written in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=314954;msg=27 , this bug still occurs, but only very seldomly. I think it occured only about 3 times since I installed linux-image-2.6.12-1-686, and that was probably about three weeks ago (and as you can see, I first believed I would have gone) Willi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#314954: gpm restart as solution
gpm restart as solution only helps in case I switch to the console. Restarting gpm from an x terminal does not help. Willi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
