Bug#1054345: usbcore call trace
I now seem to have captured a call trace which may be related: INFO: task kworker/0:0:7395 blocked for more than 120 seconds. [ 1088.815089] Not tainted 6.5.0-3-amd64 #1 Debian 6.5.8-1 [ 1088.815093] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 1088.815095] task:kworker/0:0 state:D stack:0 pid:7395 ppid:2 flags:0x4000 [ 1088.815105] Workqueue: usb_hub_wq hub_event [usbcore] [ 1088.815183] Call Trace: [ 1088.815186] [ 1088.815192] __schedule+0x3df/0xb80 [ 1088.815205] schedule+0x61/0xe0 [ 1088.815211] schedule_timeout+0x98/0x160 [ 1088.815218] ? __pfx_process_timeout+0x10/0x10 [ 1088.815227] wait_for_completion_timeout+0x83/0x170 [ 1088.815236] usb_start_wait_urb+0xa7/0x180 [usbcore] [ 1088.815299] usb_control_msg+0xef/0x150 [usbcore] [ 1088.815359] get_bMaxPacketSize0+0x5f/0xc0 [usbcore] [ 1088.815410] hub_port_init+0x418/0xff0 [usbcore] [ 1088.815465] hub_event+0x1207/0x1c10 [usbcore] [ 1088.815521] ? __schedule+0x3e7/0xb80 [ 1088.815528] process_one_work+0x1e1/0x3f0 [ 1088.815537] worker_thread+0x51/0x390 [ 1088.815542] ? _raw_spin_lock_irqsave+0x27/0x60 [ 1088.815549] ? __pfx_worker_thread+0x10/0x10 [ 1088.815554] kthread+0xf7/0x130 [ 1088.815562] ? __pfx_kthread+0x10/0x10 [ 1088.815570] ret_from_fork+0x34/0x50 [ 1088.815578] ? __pfx_kthread+0x10/0x10 [ 1088.815584] ret_from_fork_asm+0x1b/0x30 [ 1088.815597] [ 1209.646327] INFO: task kworker/0:0:7395 blocked for more than 241 seconds. [ 1209.646341] Not tainted 6.5.0-3-amd64 #1 Debian 6.5.8-1 [ 1209.646345] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 1209.646348] task:kworker/0:0 state:D stack:0 pid:7395 ppid:2 flags:0x4000 [ 1209.646363] Workqueue: usb_hub_wq hub_event [usbcore] [ 1209.646465] Call Trace: [ 1209.646469] [ 1209.646476] __schedule+0x3df/0xb80 [ 1209.646493] schedule+0x61/0xe0 [ 1209.646501] schedule_timeout+0x98/0x160 [ 1209.646509] ? __pfx_process_timeout+0x10/0x10 [ 1209.646520] wait_for_completion_timeout+0x83/0x170 [ 1209.646532] usb_start_wait_urb+0xa7/0x180 [usbcore] [ 1209.646620] usb_control_msg+0xef/0x150 [usbcore] [ 1209.646703] get_bMaxPacketSize0+0x5f/0xc0 [usbcore] [ 1209.646772] hub_port_init+0x418/0xff0 [usbcore] [ 1209.646849] hub_event+0x1207/0x1c10 [usbcore] [ 1209.646925] ? __schedule+0x3e7/0xb80 [ 1209.646935] process_one_work+0x1e1/0x3f0 [ 1209.646946] worker_thread+0x51/0x390 [ 1209.646954] ? _raw_spin_lock_irqsave+0x27/0x60 [ 1209.646962] ? __pfx_worker_thread+0x10/0x10 [ 1209.646969] kthread+0xf7/0x130 [ 1209.646980] ? __pfx_kthread+0x10/0x10 [ 1209.646990] ret_from_fork+0x34/0x50 [ 1209.647002] ? __pfx_kthread+0x10/0x10 [ 1209.647011] ret_from_fork_asm+0x1b/0x30 [ 1209.647028] [ 1330.478037] INFO: task kworker/0:0:7395 blocked for more than 362 seconds. [ 1330.478048] Not tainted 6.5.0-3-amd64 #1 Debian 6.5.8-1 [ 1330.478052] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 1330.478055] task:kworker/0:0 state:D stack:0 pid:7395 ppid:2 flags:0x4000 [ 1330.478066] Workqueue: usb_hub_wq hub_event [usbcore] [ 1330.478149] Call Trace: [ 1330.478152] [ 1330.478158] __schedule+0x3df/0xb80 [ 1330.478172] schedule+0x61/0xe0 [ 1330.478179] schedule_timeout+0x98/0x160 [ 1330.478186] ? __pfx_process_timeout+0x10/0x10 [ 1330.478196] wait_for_completion_timeout+0x83/0x170 [ 1330.478206] usb_start_wait_urb+0xa7/0x180 [usbcore] [ 1330.478276] usb_control_msg+0xef/0x150 [usbcore] [ 1330.478342] get_bMaxPacketSize0+0x5f/0xc0 [usbcore] [ 1330.478397] hub_port_init+0x418/0xff0 [usbcore] [ 1330.478458] hub_event+0x1207/0x1c10 [usbcore] [ 1330.478520] ? __schedule+0x3e7/0xb80 [ 1330.478527] process_one_work+0x1e1/0x3f0 [ 1330.478536] worker_thread+0x51/0x390 [ 1330.478542] ? _raw_spin_lock_irqsave+0x27/0x60 [ 1330.478549] ? __pfx_worker_thread+0x10/0x10 [ 1330.478555] kthread+0xf7/0x130 [ 1330.478564] ? __pfx_kthread+0x10/0x10 [ 1330.478572] ret_from_fork+0x34/0x50 [ 1330.478580] ? __pfx_kthread+0x10/0x10 [ 1330.478588] ret_from_fork_asm+0x1b/0x30 [ 1330.478601] However this was on hotplugging a garmin Etrex 20 which is always very slow and after increasing /sys/module/usbcore/parameters/initial_descriptor_timeout to a very large value (60 !), so it may not be related.
Bug#1054345: Bug presebt on all recent kernel versions
just tested on kernel versions 6.5.0-1-amd64, 6.4.0-4-amd64, 6.4.0-3-amd64 & 6.4.0-2-amd64 and same bug present on all. So it is long standing, and not specific to 6.5.0-2. ael
Bug#1054346: linux-image-6.5.0-2-amd64: Segfault with USB Mass storage
Package: src:linux Version: 6.5.6-1 Severity: normal Dear Maintainer, This is just a very preliminary report with little proper information as yet: perhaps a placeholder which may be useful if other are seein this problem. Since installing 6.5.0-2, when hot plugging USB sticks, I see segfault messages in dmesq such as: --- [ 2538.645420] usb 2-9: new high-speed USB device number 3 using xhci_hcd [ 2538.800696] usb 2-9: New USB device found, idVendor=090c, idProduct=1000, bcdDevice=20.40 [ 2538.800705] usb 2-9: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 2538.800708] usb 2-9: Product: USB 2.0 Flash Drive [ 2538.800711] usb 2-9: Manufacturer: Super Talent Flash [ 2538.800713] usb 2-9: SerialNumber: 13005672 [ 2538.915612] w[15439]: segfault at 4c ip 55bcdea2d09e sp 7ffd80083c00 error 4 in w[55bcdea2c000+3000] likely on CPU 5 (core 1, socket 0) [ 2538.915624] Code: 0f be c3 48 8b 12 f6 44 42 01 40 74 7f 80 fb 20 74 7a 0f be fb 48 83 c5 01 e8 6e f1 ff ff 49 39 ee 0f 84 7d 00 00 00 45 89 e7 <0f> b6 5d 00 84 db 75 ba 45 85 ff 75 65 48 8b 35 76 3f 00 00 bf 2d [ 2539.107372] usb-storage 2-9:1.0: USB Mass Storage device detected [ 2539.107500] scsi host6: usb-storage 2-9:1.0 [ 2539.107576] usbcore: registered new interface driver usb-storage [ 2539.110315] usbcore: registered new interface driver uas [ 2539.194645] w[16015]: segfault at 4c ip 55595990709e sp 7ffd9dc81ca0 error 4 in w[555959906000+3000] likely on CPU 2 (core 2, socket 0) [ 2539.194662] Code: 0f be c3 48 8b 12 f6 44 42 01 40 74 7f 80 fb 20 74 7a 0f be fb 48 83 c5 01 e8 6e f1 ff ff 49 39 ee 0f 84 7d 00 00 00 45 89 e7 <0f> b6 5d 00 84 db 75 ba 45 85 ff 75 65 48 8b 35 76 3f 00 00 bf 2d [ 2540.114671] scsi 6:0:0:0: Direct-Access Flash/SM Super Talent 2.0 2040 PQ: 0 ANSI: 0 CCS [ 2540.115312] sd 6:0:0:0: Attached scsi generic sg2 type 0 [ 2540.116750] sd 6:0:0:0: [sdb] 1014784 512-byte logical blocks: (520 MB/496 MiB) [ 2540.117302] sd 6:0:0:0: [sdb] Write Protect is off [ 2540.117308] sd 6:0:0:0: [sdb] Mode Sense: 43 00 00 00 [ 2540.117876] sd 6:0:0:0: [sdb] No Caching mode page found [ 2540.117883] sd 6:0:0:0: [sdb] Assuming drive cache: write through [ 2540.172366] sdb: sdb1 sdb2 [ 2540.172729] sd 6:0:0:0: [sdb] Attached SCSI removable disk This has happened with at least two different usb sticks of very different vintages. I did run a memtest check on RAM, but this only seem to happen when hotplugging USB sticks, so I am confident that this is a kernel/module bug. When I have more time, I will attempt to turn on debugging options and symbols and more. But I doubt that I am the only one seeing this, and maybe the bug is already fixed upstream. -- Package-specific info: ** Version: Linux version 6.5.0-2-amd64 (debian-kernel@lists.debian.org) (gcc-13 (Debian 13.2.0-5) 13.2.0, GNU ld (GNU Binutils for Debian) 2.41) #1 SMP PREEMPT_DYNAMIC Debian 6.5.6-1 (2023-10-07) ** Command line: BOOT_IMAGE=/boot/vmlinuz-6.5.0-2-amd64 root=UUID=5b8060f7-f126-4534-a051-db5d205bd315 ro elevator=deadline ** Not tainted ** Kernel log: Unable to read kernel log; any relevant messages should be attached ** Model information sys_vendor: Notebook product_name: W54_55SU1,SUW product_version: Not Applicable chassis_vendor: Notebook chassis_version: N/A bios_vendor: American Megatrends Inc. bios_version: 4.6.5 board_vendor: Notebook board_name: W54_55SU1,SUW board_version: Not Applicable ** Loaded modules: uas usb_storage mptcp_diag xsk_diag tcp_diag udp_diag raw_diag inet_diag unix_diag af_packet_diag netlink_diag xt_recent ipt_REJECT nf_reject_ipv4 xt_comment xt_hashlimit xt_addrtype xt_mark xt_NFLOG nfnetlink_log xt_LOG nf_log_syslog nf_nat_tftp nf_nat_snmp_basic nf_conntrack_snmp nf_nat_sip nf_nat_pptp nf_nat_irc nf_nat_h323 nf_nat_ftp nf_nat_amanda ts_kmp nf_conntrack_amanda nf_conntrack_sane nf_conntrack_tftp nf_conntrack_sip nf_conntrack_pptp nf_conntrack_netlink nf_conntrack_netbios_ns nf_conntrack_broadcast nf_conntrack_irc nf_conntrack_h323 nf_conntrack_ftp xt_tcpudp xt_conntrack nft_compat nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 nf_tables libcrc32c nfnetlink qrtr tun uinput binfmt_misc btusb btrtl btbcm btintel btmtk bluetooth sha3_generic jitterentropy_rng drbg ansi_cprng ecdh_generic ecc pktcdvd intel_rapl_msr intel_rapl_common x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel iwlmvm kvm cpufreq_ondemand irqbypass crc32_pclmul mac80211 ghash_clmulni_intel sha512_ssse3 sha512_generic snd_hda_codec_realtek snd_hda_codec_generic ledtrig_audio snd_hda_codec_hdmi libarc4 aesni_intel snd_hda_intel snd_intel_dspcfg crypto_simd snd_intel_sdw_acpi cryptd snd_hda_codec iwlwifi iTCO_wdt
Bug#1054345: linux-image-6.5.0-2-amd64: Segfault with USB Mass storage
Package: src:linux Version: 6.5.6-1 Severity: normal Dear Maintainer, This is just a very preliminary report with little proper information as yet: perhaps a placeholder which may be useful if other are seein this problem. Since installing 6.5.0-2, when hot plugging USB sticks, I see segfault messages in dmesq such as: --- [ 2538.645420] usb 2-9: new high-speed USB device number 3 using xhci_hcd [ 2538.800696] usb 2-9: New USB device found, idVendor=090c, idProduct=1000, bcdDevice=20.40 [ 2538.800705] usb 2-9: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 2538.800708] usb 2-9: Product: USB 2.0 Flash Drive [ 2538.800711] usb 2-9: Manufacturer: Super Talent Flash [ 2538.800713] usb 2-9: SerialNumber: 13005672 [ 2538.915612] w[15439]: segfault at 4c ip 55bcdea2d09e sp 7ffd80083c00 error 4 in w[55bcdea2c000+3000] likely on CPU 5 (core 1, socket 0) [ 2538.915624] Code: 0f be c3 48 8b 12 f6 44 42 01 40 74 7f 80 fb 20 74 7a 0f be fb 48 83 c5 01 e8 6e f1 ff ff 49 39 ee 0f 84 7d 00 00 00 45 89 e7 <0f> b6 5d 00 84 db 75 ba 45 85 ff 75 65 48 8b 35 76 3f 00 00 bf 2d [ 2539.107372] usb-storage 2-9:1.0: USB Mass Storage device detected [ 2539.107500] scsi host6: usb-storage 2-9:1.0 [ 2539.107576] usbcore: registered new interface driver usb-storage [ 2539.110315] usbcore: registered new interface driver uas [ 2539.194645] w[16015]: segfault at 4c ip 55595990709e sp 7ffd9dc81ca0 error 4 in w[555959906000+3000] likely on CPU 2 (core 2, socket 0) [ 2539.194662] Code: 0f be c3 48 8b 12 f6 44 42 01 40 74 7f 80 fb 20 74 7a 0f be fb 48 83 c5 01 e8 6e f1 ff ff 49 39 ee 0f 84 7d 00 00 00 45 89 e7 <0f> b6 5d 00 84 db 75 ba 45 85 ff 75 65 48 8b 35 76 3f 00 00 bf 2d [ 2540.114671] scsi 6:0:0:0: Direct-Access Flash/SM Super Talent 2.0 2040 PQ: 0 ANSI: 0 CCS [ 2540.115312] sd 6:0:0:0: Attached scsi generic sg2 type 0 [ 2540.116750] sd 6:0:0:0: [sdb] 1014784 512-byte logical blocks: (520 MB/496 MiB) [ 2540.117302] sd 6:0:0:0: [sdb] Write Protect is off [ 2540.117308] sd 6:0:0:0: [sdb] Mode Sense: 43 00 00 00 [ 2540.117876] sd 6:0:0:0: [sdb] No Caching mode page found [ 2540.117883] sd 6:0:0:0: [sdb] Assuming drive cache: write through [ 2540.172366] sdb: sdb1 sdb2 [ 2540.172729] sd 6:0:0:0: [sdb] Attached SCSI removable disk This has happened with at least two different usb sticks of very different vintages. I did run a memtest check on RAM, but this only seem to happen when hotplugging USB sticks, so I am confident that this is a kernel/module bug. When I have more time, I will attempt to turn on debugging options and symbols and more. But I doubt that I am the only one seeing this, and maybe the bug is already fixed upstream. -- Package-specific info: ** Version: Linux version 6.5.0-2-amd64 (debian-kernel@lists.debian.org) (gcc-13 (Debian 13.2.0-5) 13.2.0, GNU ld (GNU Binutils for Debian) 2.41) #1 SMP PREEMPT_DYNAMIC Debian 6.5.6-1 (2023-10-07) ** Command line: BOOT_IMAGE=/boot/vmlinuz-6.5.0-2-amd64 root=UUID=5b8060f7-f126-4534-a051-db5d205bd315 ro elevator=deadline ** Not tainted ** Kernel log: Unable to read kernel log; any relevant messages should be attached ** Model information sys_vendor: Notebook product_name: W54_55SU1,SUW product_version: Not Applicable chassis_vendor: Notebook chassis_version: N/A bios_vendor: American Megatrends Inc. bios_version: 4.6.5 board_vendor: Notebook board_name: W54_55SU1,SUW board_version: Not Applicable ** Loaded modules: uas usb_storage mptcp_diag xsk_diag tcp_diag udp_diag raw_diag inet_diag unix_diag af_packet_diag netlink_diag xt_recent ipt_REJECT nf_reject_ipv4 xt_comment xt_hashlimit xt_addrtype xt_mark xt_NFLOG nfnetlink_log xt_LOG nf_log_syslog nf_nat_tftp nf_nat_snmp_basic nf_conntrack_snmp nf_nat_sip nf_nat_pptp nf_nat_irc nf_nat_h323 nf_nat_ftp nf_nat_amanda ts_kmp nf_conntrack_amanda nf_conntrack_sane nf_conntrack_tftp nf_conntrack_sip nf_conntrack_pptp nf_conntrack_netlink nf_conntrack_netbios_ns nf_conntrack_broadcast nf_conntrack_irc nf_conntrack_h323 nf_conntrack_ftp xt_tcpudp xt_conntrack nft_compat nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 nf_tables libcrc32c nfnetlink qrtr tun uinput binfmt_misc btusb btrtl btbcm btintel btmtk bluetooth sha3_generic jitterentropy_rng drbg ansi_cprng ecdh_generic ecc pktcdvd intel_rapl_msr intel_rapl_common x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel iwlmvm kvm cpufreq_ondemand irqbypass crc32_pclmul mac80211 ghash_clmulni_intel sha512_ssse3 sha512_generic snd_hda_codec_realtek snd_hda_codec_generic ledtrig_audio snd_hda_codec_hdmi libarc4 aesni_intel snd_hda_intel snd_intel_dspcfg crypto_simd snd_intel_sdw_acpi cryptd snd_hda_codec iwlwifi iTCO_wdt
Bug#994719: linux-image-5.10.0-8-amd64: Kernel oops
Package: src:linux Version: 5.10.46-4 Severity: important Kernal oops: [ 4895.690309] FAT-fs (sdd1): Directory bread(block 23326848) failed [ 4895.690312] FAT-fs (sdd1): Directory bread(block 23326849) failed [ 4895.690314] FAT-fs (sdd1): Directory bread(block 23326850) failed [ 4895.690315] FAT-fs (sdd1): Directory bread(block 23326851) failed [ 4895.690317] FAT-fs (sdd1): Directory bread(block 23326852) failed [ 4895.690319] FAT-fs (sdd1): Directory bread(block 23326853) failed [ 4895.690320] FAT-fs (sdd1): Directory bread(block 23326854) failed [ 4895.690322] FAT-fs (sdd1): Directory bread(block 23326855) failed [ 4895.690324] FAT-fs (sdd1): Directory bread(block 23326856) failed [ 4895.690325] FAT-fs (sdd1): Directory bread(block 23326857) failed [ 4895.690530] FAT-fs (sdd1): FAT read failed (blocknr 4243) [ 4895.690532] [ cut here ] [ 4895.690533] bdi-(unknown) not registered [ 4895.690544] WARNING: CPU: 5 PID: 9048 at fs/fs-writeback.c:2326 __mark_inode_dirty+0 x17a/0x340 [ 4895.690545] Modules linked in: nls_ascii nls_cp437 vfat fat xt_recent ipt_REJECT nf_ reject_ipv4 xt_comment xt_hashlimit xt_addrtype xt_mark xt_CT nfnetlink_log xt_NFLOG nf _log_ipv4 nf_log_common xt_LOG nf_nat_tftp nf_nat_snmp_basic nf_conntrack_snmp nf_nat_s ip nf_nat_pptp nf_nat_irc nf_nat_h323 nf_nat_ftp nf_nat_amanda ts_kmp nf_conntrack_aman da nf_conntrack_sane nf_conntrack_tftp nf_conntrack_sip nf_conntrack_pptp nf_conntrack_ netlink nf_conntrack_netbios_ns nf_conntrack_broadcast nf_conntrack_irc nf_conntrack_h3 23 nf_conntrack_ftp nft_counter xt_tcpudp xt_conntrack nft_compat nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 nf_tables libcrc32c nfnetlink essiv authenc dm_crypt dm_mod uas usb_storage uinput binfmt_misc btusb btrtl btbcm btintel bluetooth uvcvideo videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 jitterentropy_rng videobuf2_ common drbg videodev ansi_cprng mc ecdh_generic ecc intel_rapl_msr intel_rapl_common x8 6_pkg_temp_thermal cpufreq_ondemand [ 4895.690601] intel_powerclamp coretemp snd_hda_codec_realtek kvm_intel snd_hda_codec_generic ledtrig_audio snd_hda_codec_hdmi iwlmvm pktcdvd kvm snd_hda_intel snd_intel_dspcfg irqbypass crc32_pclmul soundwire_intel soundwire_generic_allocation ghash_clmulni_intel mac80211 snd_soc_core aesni_intel snd_compress soundwire_cadence libaes iTCO_wdt intel_pmc_bxt crypto_simd libarc4 snd_hda_codec iTCO_vendor_support rtsx_pci_sdmmc cryptd iwlwifi watchdog glue_helper mmc_core snd_hda_core mei_hdcp at24 xhci_pci snd_hwdep rapl ehci_pci xhci_hcd soundwire_bus r8169 ehci_hcd intel_cstate snd_pcm cfg80211 realtek sr_mod mdio_devres snd_timer intel_uncore cdrom joydev mei_me pcspkr usbcore libphy sg i2c_i801 snd rtsx_pci mei rfkill lpc_ich soundcore i2c_smbus usb_common wmi battery ac button msr parport_pc nfsd ppdev lp parport auth_rpcgss nfs_acl lockd fuse grace configfs sunrpc ip_tables x_tables autofs4 ext4 crc16 mbcache jbd2 crc32c_generic sd_mod t10_pi crc_t10dif crct10dif_generic i915 [ 4895.690676] i2c_algo_bit ahci drm_kms_helper libahci libata cec drm scsi_mod psmouse crct10dif_pclmul crct10dif_common crc32c_intel evdev serio_raw video [ 4895.690697] CPU: 5 PID: 9048 Comm: AWT-EventQueue- Not tainted 5.10.0-8-amd64 #1 Debian 5.10.46-4 [ 4895.690699] Hardware name: Notebook W54_55SU1,SUW/W54_55SU1,SUW, BIOS 4.6.5 05/29/2014 [ 4895.690704] RIP: 0010:__mark_inode_dirty+0x17a/0x340 [ 4895.690707] Code: ff ff 48 8b 38 48 89 c5 f6 47 44 01 74 1e 48 8b 40 08 a8 01 75 16 e8 55 90 f3 ff 48 c7 c7 b8 8b 0f a4 48 89 c6 e8 29 3b 58 00 <0f> 0b 48 8b 05 1d 14 31 01 49 89 86 c8 00 00 00 45 85 ff 74 0e 48 [ 4895.690709] RSP: 0018:a672830a78a0 EFLAGS: 00010286 [ 4895.690712] RAX: RBX: 0001 RCX: 96ed0fb58a08 [ 4895.690713] RDX: ffd8 RSI: 0027 RDI: 96ed0fb58a00 [ 4895.690714] RBP: 96eae2f5c460 R08: R09: a672830a76c0 [ 4895.690715] R10: a672830a76b8 R11: a46cb3e8 R12: 96ea874c66d8 [ 4895.690716] R13: R14: 96ea874c6650 R15: [ 4895.690718] FS: 7fe7da562700() GS:96ed0fb4() knlGS: [ 4895.690719] CS: 0010 DS: ES: CR0: 80050033 [ 4895.690720] CR2: 55790a2de0f8 CR3: 00015ccec006 CR4: 001706e0 [ 4895.690722] Call Trace: [ 4895.690732] fat_alloc_clusters+0x487/0x4e0 [fat] [ 4895.690737] ? xas_load+0x5/0x70 [ 4895.690740] ? submit_bio_noacct+0x2c/0x420 [ 4895.690744] fat_add_new_entries+0x92/0x2f0 [fat] [ 4895.690748] ? _cond_resched+0x16/0x40 [ 4895.690750] ? ___ratelimit+0x90/0xe0 [ 4895.690753] ? fat__get_entry+0x8d/0x230 [fat] [ 4895.690757] fat_add_entries+0x49d/0x570 [fat] [ 4895.690760] ? vfat_add_entry+0x9c2/0xdf0 [vfat] [ 4895.690762] vfat_add_entry+0x9dd/0xdf0 [vfat] [ 4895.690768] ? __d_lookup_done+0x76/0xe0 [ 4895.690770] vfat_create+0x6c/0x170 [vfat] [
Bug#976284: linux-image-5.9.0-4-amd64: kernel oops when handling small 32GB usb drives
Package: src:linux Version: 5.9.11-1 Severity: normal Dear Maintainer, I checked dmesg after mounting a couple of new usb sticks and found a few oops apparently associated with task sync. I will attach the dmesg (gzipped) if reportbug does not do that automatially. -- Package-specific info: ** Version: Linux version 5.9.0-4-amd64 (debian-kernel@lists.debian.org) (gcc-10 (Debian 10.2.0-19) 10.2.0, GNU ld (GNU Binutils for Debian) 2.35.1) #1 SMP Debian 5.9.11-1 (2020-11-27) ** Command line: BOOT_IMAGE=/boot/vmlinuz-5.9.0-4-amd64 root=UUID=5b8060f7-f126-4534-a051-db5d205bd315 ro elevator=deadline ** Not tainted ** Kernel log: Unable to read kernel log; any relevant messages should be attached ** Model information sys_vendor: Notebook product_name: W54_55SU1,SUW product_version: Not Applicable chassis_vendor: Notebook chassis_version: N/A bios_vendor: American Megatrends Inc. bios_version: 4.6.5 board_vendor: Notebook board_name: W54_55SU1,SUW board_version: Not Applicable ** Loaded modules: nls_ascii nls_cp437 vfat fat essiv authenc dm_crypt dm_mod uas usb_storage snd_hrtimer snd_seq snd_seq_device cmac algif_hash algif_skcipher af_alg bnep uinput binfmt_misc btusb btrtl btbcm btintel bluetooth uvcvideo videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 videobuf2_common jitterentropy_rng videodev drbg mc ansi_cprng ecdh_generic ecc intel_rapl_msr intel_rapl_common x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel pktcdvd kvm irqbypass crc32_pclmul snd_hda_codec_realtek iwlmvm ghash_clmulni_intel snd_hda_codec_generic aesni_intel ledtrig_audio snd_hda_codec_hdmi libaes cpufreq_ondemand snd_hda_intel crypto_simd snd_intel_dspcfg mac80211 cryptd glue_helper libarc4 rtsx_pci_sdmmc snd_hda_codec xhci_pci iTCO_wdt intel_pmc_bxt rapl mmc_core iTCO_vendor_support iwlwifi xhci_hcd snd_hda_core r8169 ehci_pci watchdog at24 ehci_hcd intel_cstate snd_hwdep realtek snd_pcm mdio_devres sr_mod cfg80211 intel_uncore mei_me cdrom snd_timer i2c_i801 usbcore rtsx_pci libphy sg mei snd rfkill pcspkr soundcore lpc_ich joydev usb_common i2c_smbus wmi battery button ac nfsd msr parport_pc ppdev lp parport auth_rpcgss nfs_acl lockd grace sunrpc ip_tables x_tables autofs4 ext4 crc16 mbcache jbd2 crc32c_generic sd_mod t10_pi crc_t10dif crct10dif_generic i915 i2c_algo_bit drm_kms_helper ahci libahci cec libata crct10dif_pclmul drm crct10dif_common scsi_mod psmouse crc32c_intel evdev serio_raw video ** PCI devices: 00:00.0 Host bridge [0600]: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor DRAM Controller [8086:0c04] (rev 06) Subsystem: CLEVO/KAPOK Computer Xeon E3-1200 v3/4th Gen Core Processor DRAM Controller [1558:5455] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- Kernel modules: ie31200_edac 00:02.0 VGA compatible controller [0300]: Intel Corporation 4th Gen Core Processor Integrated Graphics Controller [8086:0416] (rev 06) (prog-if 00 [VGA controller]) Subsystem: CLEVO/KAPOK Computer 4th Gen Core Processor Integrated Graphics Controller [1558:5455] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- Kernel driver in use: i915 Kernel modules: i915 00:03.0 Audio device [0403]: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor HD Audio Controller [8086:0c0c] (rev 06) Subsystem: CLEVO/KAPOK Computer Xeon E3-1200 v3/4th Gen Core Processor HD Audio Controller [1558:5455] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- Kernel driver in use: snd_hda_intel Kernel modules: snd_hda_intel 00:14.0 USB controller [0c03]: Intel Corporation 8 Series/C220 Series Chipset Family USB xHCI [8086:8c31] (rev 05) (prog-if 30 [XHCI]) Subsystem: CLEVO/KAPOK Computer 8 Series/C220 Series Chipset Family USB xHCI [1558:5455] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- Kernel driver in use: xhci_hcd Kernel modules: xhci_pci 00:16.0 Communication controller [0780]: Intel Corporation 8 Series/C220 Series Chipset Family MEI Controller #1 [8086:8c3a] (rev 04) Subsystem: CLEVO/KAPOK Computer 8 Series/C220 Series Chipset Family MEI Controller [1558:5455] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast
Bug#958732: linux-image-5.5.0-2-amd64: invalid opcode: 0000 [#1] SMP PTI kernel crash (stilll called an Oops?)
Package: src:linux Version: 5.5.17-1 Severity: normal Kernel crash: Apr 24 12:58:24 shelf kernel: [ 8109.802668] [ cut here ] Apr 24 12:58:24 shelf kernel: [ 8109.802673] invalid opcode: [#1] SMP PTI Apr 24 12:58:24 shelf kernel: [ 8109.802676] CPU: 4 PID: 5665 Comm: Xorg Not tainted 5.5.0-2-amd64 #1 Debian 5.5.17-1 Apr 24 12:58:24 shelf kernel: [ 8109.802677] Hardware name: Notebook W54_55SU1,SUW/W54_55SU1,SUW, BIOS 4.6.5 05/29/2014 Apr 24 12:58:24 shelf kernel: [ 8109.802681] RIP: 0010:__list_del_entry_valid.cold+0x1d/0x55 Apr 24 12:58:24 shelf kernel: [ 8109.802683] Code: c7 c7 98 b0 31 b5 e8 65 a5 cc ff 0f 0b 48 89 fe 48 c7 c7 28 b1 31 b5 e8 54 a5 cc ff 0f 0b 48 c7 c7 d8 b1 31 b5 e8 46 a5 cc ff <0f> 0b 48 89 f2 48 89 fe 48 c7 c7 98 b1 31 b5 e8 32 a5 cc ff 0f 0b Apr 24 12:58:24 shelf kernel: [ 8109.802684] RSP: 0018:bd3ec0d47a18 EFLAGS: 00010046 Apr 24 12:58:24 shelf kernel: [ 8109.802686] RAX: 0054 RBX: 99851d93c900 RCX: Apr 24 12:58:24 shelf kernel: [ 8109.802687] RDX: RSI: 9985cfb19a48 RDI: 9985cfb19a48 Apr 24 12:58:24 shelf kernel: [ 8109.802688] RBP: 9985a97ef700 R08: 0383 R09: 0001 Apr 24 12:58:24 shelf kernel: [ 8109.802689] R10: R11: 0001 R12: 99851d93d200 Apr 24 12:58:24 shelf kernel: [ 8109.802690] R13: 0282 R14: 9985a97ef708 R15: 99859d458b00 Apr 24 12:58:24 shelf kernel: [ 8109.802691] FS: 7f0f70440f00() GS:9985cfb0() knlGS: Apr 24 12:58:24 shelf kernel: [ 8109.802692] CS: 0010 DS: ES: CR0: 80050033 Apr 24 12:58:24 shelf kernel: [ 8109.802693] CR2: 7f0f5c53a00c CR3: 0003dff38001 CR4: 001606e0 Apr 24 12:58:24 shelf kernel: [ 8109.802694] Call Trace: Apr 24 12:58:24 shelf kernel: [ 8109.802735] __i915_active_fence_set+0x42/0xc0 [i915] Apr 24 12:58:24 shelf kernel: [ 8109.802761] i915_active_ref+0x135/0x180 [i915] Apr 24 12:58:24 shelf kernel: [ 8109.802786] i915_vma_move_to_active+0x24/0x150 [i915] Apr 24 12:58:24 shelf kernel: [ 8109.802809] i915_gem_do_execbuffer+0xd75/0x18f0 [i915] Apr 24 12:58:24 shelf kernel: [ 8109.802813] ? _cond_resched+0x15/0x30 Apr 24 12:58:24 shelf kernel: [ 8109.802815] ? mutex_lock+0xe/0x30 Apr 24 12:58:24 shelf kernel: [ 8109.802818] ? unix_stream_read_generic+0x1f7/0x990 Apr 24 12:58:24 shelf kernel: [ 8109.802820] ? __switch_to_asm+0x34/0x70 Apr 24 12:58:24 shelf kernel: [ 8109.802823] ? aa_sk_perm+0x3e/0x1a0 Apr 24 12:58:24 shelf kernel: [ 8109.802827] ? __kmalloc_node+0x1fe/0x310 Apr 24 12:58:24 shelf kernel: [ 8109.802850] i915_gem_execbuffer2_ioctl+0x1df/0x3d0 [i915] Apr 24 12:58:24 shelf kernel: [ 8109.802872] ? i915_gem_execbuffer_ioctl+0x2e0/0x2e0 [i915] Apr 24 12:58:24 shelf kernel: [ 8109.802890] drm_ioctl_kernel+0xaa/0xf0 [drm] Apr 24 12:58:24 shelf kernel: [ 8109.802900] drm_ioctl+0x208/0x390 [drm] Apr 24 12:58:24 shelf kernel: [ 8109.802922] ? i915_gem_execbuffer_ioctl+0x2e0/0x2e0 [i915] Apr 24 12:58:24 shelf kernel: [ 8109.802924] do_vfs_ioctl+0x461/0x6d0 Apr 24 12:58:24 shelf kernel: [ 8109.802927] ? do_setitimer+0xad/0x1f0 Apr 24 12:58:24 shelf kernel: [ 8109.802929] ksys_ioctl+0x5e/0x90 Apr 24 12:58:24 shelf kernel: [ 8109.802931] __x64_sys_ioctl+0x16/0x20 Apr 24 12:58:24 shelf kernel: [ 8109.802933] do_syscall_64+0x52/0x180 Apr 24 12:58:24 shelf kernel: [ 8109.802935] entry_SYSCALL_64_after_hwframe+0x44/0xa9 Apr 24 12:58:24 shelf kernel: [ 8109.802937] RIP: 0033:0x7f0f70997427 Apr 24 12:58:24 shelf kernel: [ 8109.802938] Code: 00 00 90 48 8b 05 69 7a 0c 00 64 c7 00 26 00 00 00 48 c7 c0 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 39 7a 0c 00 f7 d8 64 89 01 48 Apr 24 12:58:24 shelf kernel: [ 8109.802939] RSP: 002b:7ffdf888fe38 EFLAGS: 0246 ORIG_RAX: 0010 Apr 24 12:58:24 shelf kernel: [ 8109.802941] RAX: ffda RBX: 7ffdf888fe80 RCX: 7f0f70997427 Apr 24 12:58:24 shelf kernel: [ 8109.802942] RDX: 7ffdf888fe80 RSI: 40406469 RDI: 000e Apr 24 12:58:24 shelf kernel: [ 8109.802942] RBP: 40406469 R08: 564981207f20 R09: 0010 Apr 24 12:58:24 shelf kernel: [ 8109.802943] R10: R11: 0246 R12: 5649811c56c0 Apr 24 12:58:24 shelf kernel: [ 8109.802944] R13: 000e R14: R15: 7f0f6fb93e08 Apr 24 12:58:24 shelf kernel: [ 8109.802946] Modules linked in: essiv authenc dm_crypt dm_mod uas usb_storage cpuid snd_hrtimer snd_seq snd_seq_device bnep uinput binfmt_misc uvcvideo videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 videobuf2_common videodev mc btusb btrtl btbcm btintel bluetooth drbg ansi_cprng ecdh_generic ecc intel_rapl_msr intel_rapl_common x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm irqbypass crct10dif_pclmul
Bug#883294: Problem appears to be solved on 4.16.0-2-amd64
First apologies again for delayed answers. I am running testing which is up to date. On kernel 4.16.0-2-amd64, with command line /boot/vmlinuz-4.16.0-2-amd64 root=UUID=43ae47ae-86fc-43a6-9661-dcf030179dc0 ro tsc=unstable init=/lib/sysvinit/init the problem seems to be resolved. I would close this bug, but it seems as if others may be seeing something similar, so I leave it to the maintainers to decide whether to leave it open. ael
Bug#883294: linux-image-4.13.0-1-amd64: Kernel panic prevents boot: regression (apic)
On Sun, Jul 01, 2018 at 02:57:02AM +0100, Ben Hutchings wrote: > I'm sending these questions to you since Romain mistakenly sent them > only to the bug: > > On Thu, 26 Apr 2018 08:54:26 +0200 Romain Perier > wrote: > > Hello, > > > > Could you : > > > > - Retry with linux-image 4.15, that is the current kernel in buster/sid > > (but now 4.16 is current) > > > - Instead of not using IO-APIC completly, could you try to boot with > > kernel parameter "no_timer_check" ? > > > > Does it help ? No, Romain did send a copy to me. Absurd delay is because I have been away without access to the machine. Will try to test this week. Apologises again: I know how frustrating it is to look at a bug and not get a prompt reply to follow up. ael
Bug#883294:
On Thu, Apr 26, 2018 at 08:54:26AM +0200, Romain Perier wrote: > Hello, > > Could you : > > - Retry with linux-image 4.15, that is the current kernel in buster/sid > - Instead of not using IO-APIC completly, could you try to boot with > kernel parameter "no_timer_check" ? I reaaly do apologise for no reply in all this time! I have been away without access to the machine. Hope to do tests again in the next week. ael
Bug#891766: nfsv4: Unknown symbol __x86_indirect_thunk_r*
Package: nfs-common Version: 1:1.3.4-2.2 Severity: grave Justification: renders package unusable Dear Maintainer, Since upgrading testing today ( 1:1.3.4-2.2 ) mount.nfs fails to mount at least two other filesystems on other debian machines, also running testing, and also upgraded today. dmesg reports many unknown symbols: [12995.092576] nfsv4: Unknown symbol __x86_indirect_thunk_r15 (err 0) [12995.093725] nfsv4: Unknown symbol __x86_indirect_thunk_r11 (err 0) [12995.094258] nfsv4: Unknown symbol __x86_indirect_thunk_rax (err 0) [12995.098091] nfsv4: Unknown symbol __x86_indirect_thunk_r13 (err 0) [12995.098789] nfsv4: Unknown symbol __x86_indirect_thunk_r10 (err 0) [12995.099563] nfsv4: Unknown symbol __x86_indirect_thunk_rcx (err 0) [12995.106045] nfsv4: Unknown symbol __x86_indirect_thunk_r9 (err 0) [12995.106814] nfsv4: Unknown symbol __x86_indirect_thunk_r8 (err 0) [12995.123108] nfsv4: Unknown symbol __x86_indirect_thunk_r15 (err 0) [12995.129793] nfsv4: Unknown symbol __x86_indirect_thunk_r11 (err 0) [12995.130336] nfsv4: Unknown symbol __x86_indirect_thunk_rax (err 0) [12995.131534] nfsv4: Unknown symbol __x86_indirect_thunk_r13 (err 0) [12995.135815] nfsv4: Unknown symbol __x86_indirect_thunk_r10 (err 0) [12995.136606] nfsv4: Unknown symbol __x86_indirect_thunk_rcx (err 0) [12995.137113] nfsv4: Unknown symbol __x86_indirect_thunk_r9 (err 0) [12995.137865] nfsv4: Unknown symbol __x86_indirect_thunk_r8 (err 0) [12995.144654] nfsv4: Unknown symbol __x86_indirect_thunk_r15 (err 0) [12995.145588] nfsv4: Unknown symbol __x86_indirect_thunk_r11 (err 0) [12995.152488] nfsv4: Unknown symbol __x86_indirect_thunk_rax (err 0) [12995.153577] nfsv4: Unknown symbol __x86_indirect_thunk_r13 (err 0) [12995.154159] nfsv4: Unknown symbol __x86_indirect_thunk_r10 (err 0) [12995.158831] nfsv4: Unknown symbol __x86_indirect_thunk_rcx (err 0) [12995.161160] nfsv4: Unknown symbol __x86_indirect_thunk_r9 (err 0) [12995.161841] nfsv4: Unknown symbol __x86_indirect_thunk_r8 (err 0) [12996.548940] nfsv3: Unknown symbol __x86_indirect_thunk_rax (err 0) -- [snip] -- [13062.548743] nfsd: last server has exited, flushing export cache [13063.900550] NFSD: Using /var/lib/nfs/v4recovery as the NFSv4 state recovery directory [13063.921390] NFSD: starting 90-second grace period (net b38d4b80) [13089.924328] nfsv4: Unknown symbol __x86_indirect_thunk_r15 (err 0) [13089.925123] nfsv4: Unknown symbol __x86_indirect_thunk_r11 (err 0) [13089.925452] nfsv4: Unknown symbol __x86_indirect_thunk_rax (err 0) [13089.926327] nfsv4: Unknown symbol __x86_indirect_thunk_r13 (err 0) [13089.926788] nfsv4: Unknown symbol __x86_indirect_thunk_r10 (err 0) [13089.927319] nfsv4: Unknown symbol __x86_indirect_thunk_rcx (err 0) [13089.927670] nfsv4: Unknown symbol __x86_indirect_thunk_r9 (err 0) [13089.928425] nfsv4: Unknown symbol __x86_indirect_thunk_r8 (err 0) [13089.934883] nfsv4: Unknown symbol __x86_indirect_thunk_r15 (err 0) [13089.935672] nfsv4: Unknown symbol __x86_indirect_thunk_r11 (err 0) [13089.936046] nfsv4: Unknown symbol __x86_indirect_thunk_rax (err 0) [13089.937190] nfsv4: Unknown symbol __x86_indirect_thunk_r13 (err 0) [13089.937722] nfsv4: Unknown symbol __x86_indirect_thunk_r10 (err 0) [13089.938280] nfsv4: Unknown symbol __x86_indirect_thunk_rcx (err 0) [13089.938632] nfsv4: Unknown symbol __x86_indirect_thunk_r9 (err 0) [13089.939176] nfsv4: Unknown symbol __x86_indirect_thunk_r8 (err 0) [13089.945661] nfsv4: Unknown symbol __x86_indirect_thunk_r15 (err 0) -- [snip] -- A typical mount failure:- # mount.nfs -v shelf: /mnt/shelf/ mount.nfs: timeout set for Wed Feb 28 15:55:38 2018 mount.nfs: trying text-based options 'vers=4.2,addr=192.168.0.8,clientaddr=192.168.0.2' mount.nfs: mount(2): Protocol not supported mount.nfs: trying text-based options 'vers=4.1,addr=192.168.0.8,clientaddr=192.168.0.2' mount.nfs: mount(2): Protocol not supported mount.nfs: trying text-based options 'vers=4.0,addr=192.168.0.8,clientaddr=192.168.0.2' mount.nfs: mount(2): Protocol not supported mount.nfs: trying text-based options 'addr=192.168.0.8' mount.nfs: prog 13, trying vers=3, prot=6 mount.nfs: trying 192.168.0.8 prog 13 vers 3 prot TCP port 2049 mount.nfs: prog 15, trying vers=3, prot=17 mount.nfs: trying 192.168.0.8 prog 15 vers 3 prot UDP port 34299 mount.nfs: mount(2): Protocol not supported mount.nfs: Protocol not supported -- Package-specific info: -- rpcinfo -- program vers proto port service 104 tcp111 portmapper 103 tcp111 portmapper 102 tcp111 portmapper 104 udp111 portmapper 103 udp111 portmapper 102 udp111 portmapper 3910022 tcp836 sgi_fam 1000241 udp 47937 status 1000241 tcp 39807 status 133 tcp 2049 nfs 134 tcp 2049 nfs 1002273 tcp 2049 133 udp 2049 nfs 1002273 udp 2049
Bug#800721: Also on testing with rev 73
On testing with kernel 4.3.0-1-amd64 and firmware-iwlwifi version 20160110-1, [1.815788] iwlwifi :02:00.0: Direct firmware load for iwlwifi-7260-17.ucode failed with error -2 Later suggests that it may have suceeded with -16.ucode rather than -17: [1.818536] iwlwifi :02:00.0: firmware: direct-loading firmware iwlwifi-7260-16.ucode [1.818750] iwlwifi :02:00.0: loaded firmware version 16.242414.0 op_mode iwlmvm processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 60 model name : Intel(R) Core(TM) i7-4712MQ CPU @ 2.30GHz stepping: 3 microcode : 0x1e cpu MHz : 2561.355 cache size : 6144 KB physical id : 0 siblings: 8 core id : 0 cpu cores : 4 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm ida arat epb pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid xsaveopt bugs: bogomips: 4589.41 clflush size: 64 cache_alignment : 64 address sizes : 39 bits physical, 48 bits virtual power management: processor : 1 vendor_id : GenuineIntel cpu family : 6 model : 60 model name : Intel(R) Core(TM) i7-4712MQ CPU @ 2.30GHz stepping: 3 microcode : 0x1e cpu MHz : 2300.000 cache size : 6144 KB physical id : 0 siblings: 8 core id : 1 cpu cores : 4 apicid : 2 initial apicid : 2 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm ida arat epb pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid xsaveopt bugs: bogomips: 4589.41 clflush size: 64 cache_alignment : 64 address sizes : 39 bits physical, 48 bits virtual power management: processor : 2 vendor_id : GenuineIntel cpu family : 6 model : 60 model name : Intel(R) Core(TM) i7-4712MQ CPU @ 2.30GHz stepping: 3 microcode : 0x1e cpu MHz : 2300.000 cache size : 6144 KB physical id : 0 siblings: 8 core id : 2 cpu cores : 4 apicid : 4 initial apicid : 4 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm ida arat epb pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid xsaveopt bugs: bogomips: 4589.41 clflush size: 64 cache_alignment : 64 address sizes : 39 bits physical, 48 bits virtual power management: processor : 3 vendor_id : GenuineIntel cpu family : 6 model : 60 model name : Intel(R) Core(TM) i7-4712MQ CPU @ 2.30GHz stepping: 3 microcode : 0x1e cpu MHz : 2292.812 cache size : 6144 KB physical id : 0 siblings: 8 core id : 3 cpu cores : 4 apicid : 6 initial apicid : 6 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm ida arat epb pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid xsaveopt bugs:
Bug#798787: linux-image-4.1.0-2-amd64: usb device recognised on i386 testing, but not on amd64: Alcor Micro Corp. Multi Flash Reader
,snd_hda_codec_generic,snd_hda_codec,snd_hda_controller snd_hwdep 16384 1 snd_hda_codec cfg80211 393216 3 ath,ath5k,mac80211 snd_pcm_oss45056 0 memstick 16384 1 jmb38x_ms snd_mixer_oss 24576 2 snd_pcm_oss rfkill 20480 1 cfg80211 snd_pcm81920 4 snd_pcm_oss,snd_hda_codec,snd_hda_intel,snd_hda_controller snd_timer 28672 3 snd_hrtimer,snd_pcm,snd_seq snd57344 21 snd_hda_codec_realtek,snd_pcm_oss,snd_hwdep,snd_timer,snd_pcm,snd_seq,snd_rawmidi,snd_hda_codec_generic,snd_hda_codec,snd_hda_intel,snd_seq_device,snd_mixer_oss soundcore 16384 2 snd drm 233472 6 i915,drm_kms_helper shpchp 32768 0 i2c_algo_bit 16384 1 i915 wmi20480 0 video 20480 1 i915 ac 16384 0 battery16384 0 button 16384 1 i915 acpi_cpufreq 20480 0 processor 28672 1 acpi_cpufreq thermal_sys28672 3 video,acerhdf,processor loop 24576 0 autofs436864 2 mmc_block 32768 2 ext4 466944 2 crc16 16384 1 ext4 mbcache20480 1 ext4 jbd2 73728 1 ext4 sd_mod 36864 3 ata_generic16384 0 ata_piix 32768 2 libata180224 2 ata_generic,ata_piix uhci_hcd 40960 0 ehci_pci 16384 0 ehci_hcd 65536 1 ehci_pci scsi_mod 172032 5 sg,uas,usb_storage,libata,sd_mod usbcore 180224 6 uas,uhci_hcd,uvcvideo,usb_storage,ehci_hcd,ehci_pci usb_common 16384 1 usbcore sdhci_pci 20480 0 sdhci 40960 1 sdhci_pci mmc_core 98304 3 mmc_block,sdhci,sdhci_pci r8169 73728 0 mii16384 1 r8169 -- This same reader fails to be recognised on this amd64 system. lsusb seems to hang for an extended period, but eventually returns with no entry for the reader. There seem to be no errors reported in dmesg or /var/log/messages. journalctl reports nothing relevant as far as I can tell. I imagine that turning on a debug parameter to an appropriate module might reveal something, but I don't know which to try. I should say that I have tried both the usb2 and usb3 ports with the same results, so presumably the bug is further away from the hardware than the port drivers. I collected an strace for lsusb and I can supply that if it would be useful. This problem has been happening on this amd64 system for at least a couple of months, so it is not related to very recent changes. I am fairly sure that it used to work on this amd64 at one time, probably around 4 months ago. Suggestions on how to diagnose this problem would be welcome. ael -- Package-specific info: ** Version: Linux version 4.1.0-2-amd64 (debian-kernel@lists.debian.org) (gcc version 4.9.3 (Debian 4.9.3-3) ) #1 SMP Debian 4.1.6-1 (2015-08-23) ** Command line: BOOT_IMAGE=/boot/vmlinuz-4.1.0-2-amd64 root=UUID=5b8060f7-f126-4534-a051-db5d205bd315 ro elevator=deadline ** Not tainted ** Kernel log: [ 369.715690] sd 7:0:0:0: Attached scsi generic sg2 type 0 [ 369.715998] sd 7:0:0:1: Attached scsi generic sg3 type 0 [ 369.722293] sd 7:0:0:0: [sdd] 3907584 512-byte logical blocks: (2.00 GB/1.86 GiB) [ 369.723254] sd 7:0:0:1: [sde] 61405184 512-byte logical blocks: (31.4 GB/29.2 GiB) [ 369.724703] sd 7:0:0:0: [sdd] Write Protect is off [ 369.724708] sd 7:0:0:0: [sdd] Mode Sense: 23 00 00 00 [ 369.725676] sd 7:0:0:1: [sde] Write Protect is off [ 369.725681] sd 7:0:0:1: [sde] Mode Sense: 23 00 00 00 [ 369.726719] sd 7:0:0:0: [sdd] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [ 369.727681] sd 7:0:0:1: [sde] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [ 369.747503] sdd: [ 369.754361] sde: sde1 [ 369.765545] sd 7:0:0:0: [sdd] Attached SCSI removable disk [ 369.766620] sd 7:0:0:1: [sde] Attached SCSI removable disk [ 384.001523] usb 3-9: USB disconnect, device number 46 [ 390.689782] usb 3-9: new full-speed USB device number 48 using xhci_hcd [ 390.802389] usb 3-9: Device not responding to setup address. [ 391.005627] usb 3-9: Device not responding to setup address. [ 391.209490] usb 3-9: device not accepting address 48, error -71 [ 425.770249] usb 3-9: new full-speed USB device number 50 using xhci_hcd [ 425.899141] usb 3-9: New USB device found, idVendor=091e, idProduct=2519 [ 425.899144] usb 3-9: New USB device strings: Mfr=0, Product=0, SerialNumber=5 [ 425.899146] usb 3-9: SerialNumber: e472f66f [ 425.900270] usb-storage 3-9:1.0: USB Mass Storage device detected [ 425.900420] scsi host8: usb-storage 3-9:1.0 [ 426.898371] scsi 8:0:0:0: Direct-Access Garmin GARMIN
Bug#773920: linux-image-3.16.0-4-amd64: Oops while using alsaplayer
Package: src:linux Version: 3.16.7-ckt2-1 Severity: normal While using alsaplayer to play a audio dvd (it was paused at the time) it became unresponsive and was in an uninterruptible disk sleep, so could not be killed. Subsequently I discovered this Oops:- Dec 25 16:40:20 shelf kernel: [ 4631.213380] Oops: [#1] SMP Dec 25 16:40:20 shelf kernel: [ 4631.213389] Modules linked in: binfmt_misc snd_hrtimer snd_seq snd_seq_device bnep nfsd auth_rpcgss oid_registry nfs_acl nfs lockd fscache sunrpc snd_hda_codec_hdmi joydev ecb uvcvideo videobuf2_vmalloc btusb videobuf2_memops videobuf2_core v4l2_common bluetooth videodev media 6lowpan_iphc arc4 snd_hda_codec_realtek snd_hda_codec_generic rtsx_pci_ms rtsx_pci_sdmmc memstick x86_pkg_temp_thermal intel_powerclamp intel_rapl coretemp mmc_core iTCO_wdt iTCO_vendor_support kvm_intel kvm crc32_pclmul crc32c_intel iwlmvm ghash_clmulni_intel mac80211 tpm_infineon tpm_tis tpm aesni_intel i915 iwlwifi aes_x86_64 snd_hda_intel lrw snd_hda_controller gf128mul glue_helper snd_hda_codec cfg80211 ablk_helper snd_hwdep cryptd video ehci_pci evdev snd_pcm r8169 xhci_hcd drm_kms_helper psmouse rfkill ehci_hcd snd_timer i2c_i801 wmi sr_mod mii drm serio_raw pcspkr rtsx_pci snd ac i2c_algo_bit sg cdrom soundcore battery i2c_core mei_me usbcore lpc_ich shpchp mei mfd_core usb_common button processor fuse parport_pc ppdev lp parport autofs4 ext4 crc16 mbcache jbd2 sd_mod crc_t10dif crct10dif_generic ahci crct10dif_pclmul libahci crct10dif_common libata scsi_mod thermal thermal_sys Dec 25 16:40:20 shelf kernel: [ 4631.213715] CPU: 3 PID: 3525 Comm: alsaplayer Not tainted 3.16.0-4-amd64 #1 Debian 3.16.7-ckt2-1 Dec 25 16:40:20 shelf kernel: [ 4631.213735] Hardware name: Notebook W54_55SU1,SUW/W54_55SU1,SUW, BIOS 4.6.5 05/29/2014 Dec 25 16:40:20 shelf kernel: [ 4631.213758] task: 88040f2ac190 ti: 8800cd4b task.ti: 8800cd4b Dec 25 16:40:20 shelf kernel: [ 4631.213775] RIP: 0010:[a024804a] [a024804a] mmc_ioctl_cdrom_read_audio+0x23a/0x3e0 [cdrom] Dec 25 16:40:20 shelf kernel: [ 4631.213800] RSP: 0018:8800cd4b3d48 EFLAGS: 00010282 Dec 25 16:40:20 shelf kernel: [ 4631.213813] RAX: RBX: 0004 RCX: Dec 25 16:40:20 shelf kernel: [ 4631.213829] RDX: 3a96 RSI: 0206 RDI: 8800cd4b3ca8 Dec 25 16:40:20 shelf kernel: [ 4631.213845] RBP: 000492b1 R08: 8800cd4b R09: 0018 Dec 25 16:40:20 shelf kernel: [ 4631.213861] R10: b9b9 R11: 0006 R12: 8800d6045438 Dec 25 16:40:20 shelf kernel: [ 4631.213877] R13: fffb R14: 8803f19e0c40 R15: 8803d94ca5d0 Dec 25 16:40:20 shelf kernel: [ 4631.213893] FS: 7f8b635f8700() GS:88041fac() knlGS: Dec 25 16:40:20 shelf kernel: [ 4631.213911] CS: 0010 DS: ES: CR0: 80050033 Dec 25 16:40:20 shelf kernel: [ 4631.213924] CR2: 0002 CR3: 0003ef013000 CR4: 001407e0 Dec 25 16:40:20 shelf kernel: [ 4631.213940] Stack: Dec 25 16:40:20 shelf kernel: [ 4631.213946] 88040df4d7c8 7f8b635f59b0 24c0 0004cd4b3d58 Dec 25 16:40:20 shelf kernel: [ 4631.213965] 0004000492b1 7f8b635f59b0 0001000492b1 0004 Dec 25 16:40:20 shelf kernel: [ 4631.213985] 7f8b635f59b0 ffe7 530e 7f8b635f5990 Dec 25 16:40:20 shelf kernel: [ 4631.214004] Call Trace: Dec 25 16:40:20 shelf kernel: [ 4631.214014] [a0249688] ? cdrom_ioctl+0xd38/0x1189 [cdrom] Dec 25 16:40:20 shelf kernel: [ 4631.214031] [a0227cfc] ? sr_block_ioctl+0x5c/0xc0 [sr_mod] Dec 25 16:40:20 shelf kernel: [ 4631.214049] [81289d54] ? blkdev_ioctl+0x214/0x7d0 Dec 25 16:40:20 shelf kernel: [ 4631.214064] [811d93fd] ? block_ioctl+0x3d/0x40 Dec 25 16:40:20 shelf kernel: [ 4631.214078] [811b7d2f] ? do_vfs_ioctl+0x2cf/0x4b0 Dec 25 16:40:20 shelf kernel: [ 4631.214093] [810d24ee] ? SyS_futex+0x6e/0x150 Dec 25 16:40:20 shelf kernel: [ 4631.214106] [811b7f91] ? SyS_ioctl+0x81/0xa0 Dec 25 16:40:20 shelf kernel: [ 4631.214120] [8150d32d] ? system_call_fast_compare_end+0x10/0x15 Dec 25 16:40:20 shelf kernel: [ 4631.214135] Code: 98 3a 00 00 66 41 89 87 20 01 00 00 49 8b 74 24 18 4d 8b 77 68 e8 17 9c 03 e1 85 c0 74 19 49 8b 87 30 01 00 00 41 bd fb ff ff ff 0f b6 40 02 83 e0 0f 41 88 44 24 60 4c 89 f7 e8 b2 94 03 e1 85 Dec 25 16:40:20 shelf kernel: [ 4631.214241] RSP 8800cd4b3d48 Dec 25 16:40:20 shelf kernel: [ 4631.214249] CR2: 0002 Dec 25 16:40:20 shelf kernel: [ 4631.219969] ---[ end trace caa91bf337a014b9 ]--- === -- Package-specific info: ** Version: Linux version 3.16.0-4-amd64 (debian-kernel@lists.debian.org) (gcc version 4.8.3 (Debian 4.8.3-16) ) #1 SMP Debian 3.16.7-ckt2-1
Bug#763325: Also in 3.16.5
This r8169 bug also shows up in linux-3.16.5. I suppose that is not very surprising since there has been no response on the netdev mailing list. ael -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141026205248.GA7222@shelf.conquest
Bug#763325: NETDEV WATCHDOG: eth0 (r8169): transmit queue 0 timed out
): Oct 6 13:59:06 shelf kernel: [1.466463] r8169 :03:00.1 eth0: RTL8411 at 0xc900018c4000, 80:fa:5b:04:ca:96, XID 1c800880 IRQ 44 Oct 6 13:59:06 shelf kernel: [1.466470] r8169 :03:00.1 eth0: jumbo features [frames: 9200 bytes, tx checksumming: ko] --[snip]-- Oct 6 13:59:06 shelf kernel: [1.556245] r8169 :03:00.1: firmware: direct-loading firmware rtl_nic/rtl8411-2.fw Oct 6 13:59:06 shelf kernel: [1.571948] r8169 :03:00.1 eth0: link down --[snip]-- Oct 6 13:59:09 shelf kernel: [5.463398] r8169 :03:00.1 eth0: link up --[snip]-- Oct 6 14:09:17 shelf kernel: [ 545.893079] r8169 :03:00.1 eth0: link down --[snip]-- Oct 6 14:09:17 shelf kernel: [ 547.647632] r8169 :03:00.1: no hotplug settings from platform Oct 6 14:09:17 shelf kernel: [ 547.648327] done. Oct 6 14:09:17 shelf kernel: [ 547.660691] Bluetooth: hci0: read Intel version: 370710018002030d37 Oct 6 14:09:17 shelf kernel: [ 547.660693] Bluetooth: hci0: Intel device is already patched. patch num: 37 Oct 6 14:09:17 shelf kernel: [ 547.805664] [drm] Enabling RC6 states: RC6 on, RC6p off, RC6pp off Oct 6 14:09:23 shelf kernel: [ 553.115079] r8169 :03:00.1 eth0: link up Oct 6 14:09:24 shelf kernel: [ 554.134710] r8169 :03:00.1 eth0: link down Oct 6 14:09:27 shelf kernel: [ 557.556657] r8169 :03:00.1 eth0: link up Oct 6 14:09:28 shelf kernel: [ 558.578349] r8169 :03:00.1 eth0: link down Oct 6 14:09:32 shelf kernel: [ 562.018553] r8169 :03:00.1 eth0: link up Oct 6 14:09:33 shelf kernel: [ 563.040819] r8169 :03:00.1 eth0: link down Oct 6 14:09:36 shelf kernel: [ 566.548111] r8169 :03:00.1 eth0: link up Oct 6 14:09:37 shelf kernel: [ 567.568219] r8169 :03:00.1 eth0: link down Oct 6 14:09:41 shelf kernel: [ 571.786079] r8169 :03:00.1 eth0: link up Oct 6 14:09:42 shelf kernel: [ 572.808291] r8169 :03:00.1 eth0: link down Oct 6 14:09:45 shelf kernel: [ 575.383331] r8169 :03:00.1 eth0: link up --[snip]-- Oct 6 14:11:59 shelf kernel: [ 691.106397] r8169 :03:00.1 eth0: link down --[snip]-- Oct 6 14:11:59 shelf kernel: [ 691.974414] r8169 :03:00.1: no hotplug settings from platform --[snip]-- Oct 6 14:12:05 shelf kernel: [ 697.522170] r8169 :03:00.1 eth0: link up lspci: - 00:00.0 Host bridge: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor DRAM Controller (rev 06) 00:02.0 VGA compatible controller: Intel Corporation 4th Gen Core Processor Integrated Graphics Controller (rev 06) 00:03.0 Audio device: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor HD Audio Controller (rev 06) 00:14.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset Family USB xHCI (rev 05) 00:16.0 Communication controller: Intel Corporation 8 Series/C220 Series Chipset Family MEI Controller #1 (rev 04) 00:1a.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset Family USB EHCI #2 (rev 05) 00:1b.0 Audio device: Intel Corporation 8 Series/C220 Series Chipset High Definition Audio Controller (rev 05) 00:1c.0 PCI bridge: Intel Corporation 8 Series/C220 Series Chipset Family PCI Express Root Port #1 (rev d5) 00:1c.2 PCI bridge: Intel Corporation 8 Series/C220 Series Chipset Family PCI Express Root Port #3 (rev d5) 00:1c.3 PCI bridge: Intel Corporation 8 Series/C220 Series Chipset Family PCI Express Root Port #4 (rev d5) 00:1d.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset Family USB EHCI #1 (rev 05) 00:1f.0 ISA bridge: Intel Corporation HM86 Express LPC Controller (rev 05) 00:1f.2 SATA controller: Intel Corporation 8 Series/C220 Series Chipset Family 6-port SATA Controller 1 [AHCI mode] (rev 05) 00:1f.3 SMBus: Intel Corporation 8 Series/C220 Series Chipset Family SMBus Controller (rev 05) 02:00.0 Network controller: Intel Corporation Wireless 7260 (rev 73) 03:00.0 Unassigned class [ff00]: Realtek Semiconductor Co., Ltd. Device 5287 (rev 01) 03:00.1 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 12) --- lspci -v -s 03:00.1: --- 03:00.1 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 12) Subsystem: CLEVO/KAPOK Computer Device 5455 Flags: bus master, fast devsel, latency 0, IRQ 43 I/O ports at e000 [size=256] Memory at f7c14000 (64-bit, non-prefetchable) [size=4K] Memory at f7c1 (64-bit, non-prefetchable) [size=16K] Capabilities: access denied Kernel driver in use: r8169 I have not set the debug parameter on r8169 but can do so if that would be useful. ael -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas
Bug#763325: Continues to be triggered when ethernet is active
This same crash in sch_generic.c is happening a few times each day when ethernet is active. Should I report it on the KML? -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141012205429.GA6451@shelf.conquest
Bug#763325: linux-image-3.16-2-amd64: Kernel oops 3.16.2-amd64
Package: src:linux Version: 3.16.3-2 Severity: normal Noticed several oddities while booting this laptop after recent upgrade: Keyboard was flakey (the 1 did not work unless first on line), then ok. Fan running continuously which was not happening before. Of course, these things may have no connection with the oops, which I have only just noticed. The oops (shown again in context later): - Sep 29 11:08:39 shelf kernel: [ 262.924810] WARNING: CPU: 0 PID: 0 at /build/linux-P15SNz/linux-3.16.3/net/sched/sch_g eneric.c:264 dev_watchdog+0x236/0x240() Sep 29 11:08:39 shelf kernel: [ 262.924812] NETDEV WATCHDOG: eth0 (r8169): transmit queue 0 timed out Sep 29 11:08:39 shelf kernel: [ 262.924813] Modules linked in: bnep uvcvideo videobuf2_vmalloc ecb videobuf2_memops vi deobuf2_core v4l2_common btusb videodev media bluetooth 6lowpan_iphc snd_hrtimer snd_seq snd_seq_device snd_hda_codec_h dmi joydev nfsd auth_rpcgss oid_registry nfs_acl nfs lockd fscache sunrpc arc4 rtsx_pci_ms rtsx_pci_sdmmc iTCO_wdt mems tick iTCO_vendor_support mmc_core snd_hda_codec_realtek snd_hda_codec_generic x86_pkg_temp_thermal intel_powerclamp int el_rapl coretemp kvm_intel kvm crc32_pclmul iwlmvm crc32c_intel mac80211 ghash_clmulni_intel aesni_intel aes_x86_64 lrw gf128mul glue_helper ablk_helper cryptd evdev psmouse iwlwifi i915 serio_raw pcspkr snd_hda_intel cfg80211 i2c_i801 sn d_hda_controller sg r8169 sr_mod cdrom mii rfkill rtsx_pci wmi ehci_pci xhci_hcd snd_hda_codec snd_hwdep ehci_hcd drm_k ms_helper snd_pcm battery snd_timer drm tpm_infineon mei_me tpm_tis i2c_algo_bit tpm snd i2c_core soundcore lpc_ich usb core ac mei shpchp mfd_core video usb_common button processor fuse parport_pc ppdev lp parport autofs4 ext4 crc16 mbcac he jbd2 sd_mod crc_t10dif crct10dif_generic ahci libahci crct10dif_pclmul crct10dif_common libata scsi_mod thermal ther mal_sys Sep 29 11:08:39 shelf kernel: [ 262.924877] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.16-2-amd64 #1 Debian 3.16.3-2 Sep 29 11:08:39 shelf kernel: [ 262.924878] Hardware name: Notebook W54_55SU1,SUW/W54_55SU1,SU W, BIOS 4.6.5 05/29/2014 Sep 29 11:08:39 shelf kernel: [ 262.924879] 0009 81506188 88041fa03e28 81065707 Sep 29 11:08:39 shelf kernel: [ 262.924881] 88041fa03e78 0001 Sep 29 11:08:39 shelf kernel: [ 262.924883] 88040b1b4000 8106576c 81775ca0 88040030 Sep 29 11:08:39 shelf kernel: [ 262.924886] Call Trace: Sep 29 11:08:39 shelf kernel: [ 262.924887] IRQ [81506188] ? dump_stack+0x41/0x51 Sep 29 11:08:39 shelf kernel: [ 262.924896] [81065707] ? warn_slowpath_common+0x77/0x90 Sep 29 11:08:39 shelf kernel: [ 262.924898] [8106576c] ? warn_slowpath_fmt+0x4c/0x50 Sep 29 11:08:39 shelf kernel: [ 262.924902] [81439af6] ? dev_watchdog+0x236/0x240 Sep 29 11:08:39 shelf kernel: [ 262.924904] [814398c0] ? dev_graft_qdisc+0x70/0x70 Sep 29 11:08:39 shelf kernel: [ 262.924908] [810709c1] ? call_timer_fn+0x31/0x100 Sep 29 11:08:39 shelf kernel: [ 262.924910] [814398c0] ? dev_graft_qdisc+0x70/0x70 Sep 29 11:08:39 shelf kernel: [ 262.924913] [81071ff9] ? run_timer_softirq+0x209/0x2f0 ep 29 11:08:39 shelf kernel: [ 262.924887] IRQ [81506188] ? dump_stack+0x41/0x51 Sep 29 11:08:39 shelf kernel: [ 262.924896] [81065707] ? warn_slowpath_common+0x77/0x90 Sep 29 11:08:39 shelf kernel: [ 262.924898] [8106576c] ? warn_slowpath_fmt+0x4c/0x50 Sep 29 11:08:39 shelf kernel: [ 262.924902] [81439af6] ? dev_watchdog+0x236/0x240 Sep 29 11:08:39 shelf kernel: [ 262.924904] [814398c0] ? dev_graft_qdisc+0x70/0x70 Sep 29 11:08:39 shelf kernel: [ 262.924908] [810709c1] ? call_timer_fn+0x31/0x100 Sep 29 11:08:39 shelf kernel: [ 262.924910] [814398c0] ? dev_graft_qdisc+0x70/0x70 Sep 29 11:08:39 shelf kernel: [ 262.924913] [81071ff9] ? run_timer_softirq+0x209/0x2f0 Sep 29 11:08:39 shelf kernel: [ 262.924916] [8106a5a1] ? __do_softirq+0xf1/0x290 Sep 29 11:08:39 shelf kernel: [ 262.924918] [8106a975] ? irq_exit+0x95/0xa0 Sep 29 11:08:39 shelf kernel: [ 262.924922] [8150f155] ? smp_apic_timer_interrupt+0x45/0x60 Sep 29 11:08:39 shelf kernel: [ 262.924924] [8150d25d] ? apic_timer_interrupt+0x6d/0x80 Sep 29 11:08:39 shelf kernel: [ 262.924925] EOI [81072906] ? get_next_timer_interrupt+0x1d6/0x250 Sep 29 11:08:39 shelf kernel: [ 262.924931] [813d96e2] ? cpuidle_enter_state+0x52/0xc0 Sep 29 11:08:39 shelf kernel: [ 262.924934] [813d96d8] ? cpuidle_enter_state+0x48/0xc0 Sep 29 11:08:39 shelf kernel: [ 262.924937] [810a5d28] ? cpu_startup_entry+0x2f8/0x400 Sep 29 11:08:39 shelf kernel: [ 262.924940] [8190305a] ?
Bug#763325: Solid
I just had a repeat of this dump with the same details and Call Trace. It seemed to happen when the machine was (probably) idle which I suppose fits with a watchdog bug. The other symptoms that I mentioned did not occur this time. ael -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140929133205.GA10203@shelf.conquest
Bug#689942: Also here
I am seeing the same bug here. I have yet to check fstab which is likely to be odd ( a heritage machine). Was the patch incorporated? -- 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/20140206104511.GA5662@exact.conquest
Bug#736659: Seems to have been a gcc-nn-multilib problem
The problem seems to be that gcc-4.7/8-multilib packages were installed. Not sure what changed during the recent upgrade to change behavior. Might be useful if others hit the same problem. ael -- 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/20140124165808.GA13901@conquest2.conquest
Bug#736659: traps: ld-linux-x32.so[10769] general protection
Package: initramfs-tools Version: 0.115 Severity: normal update-initramfs fails preeventing the full installation of the debian kernel and would reender the machine unbootable if I had not also installed my own locally compiled stock kernel. Example of a run of update-initramfs: # update-initramfs -c -k 3.12-1-amd64 update-initramfs: Generating /boot/initrd.img-3.12-1-amd64 do_general_protection: 24 callbacks suppressed traps: ld-linux-x32.so[10769] general protection ip:f770eeed sp:ff834b98 error:0 in ld-2.17.so[f76f8000+21000] traps: ld-linux-x32.so[10886] general protection ip:f771beed sp:ffb07808 error:0 in ld-2.17.so[f7705000+21000] traps: ld-linux-x32.so[10900] general protection ip:f774aeed sp:ffde7348 error:0 in ld-2.17.so[f7734000+21000] traps: ld-linux-x32.so[10914] general protection ip:f7755eed sp:ffcf2368 error:0 in ld-2.17.so[f773f000+21000] traps: ld-linux-x32.so[10975] general protection ip:f7711eed sp:ffdbe938 error:0 in ld-2.17.so[f76fb000+21000] traps: ld-linux-x32.so[10991] general protection ip:f778eeed sp:ff8c3668 error:0 in ld-2.17.so[f7778000+21000] traps: ld-linux-x32.so[11005] general protection ip:f7759eed sp:ffc106d8 error:0 in ld-2.17.so[f7743000+21000] traps: ld-linux-x32.so[11019] general protection ip:f7772eed sp:ff842bf8 error:0 in ld-2.17.so[f775c000+21000] traps: ld-linux-x32.so[11033] general protection ip:f7769eed sp:ffb38448 error:0 in ld-2.17.so[f7753000+21000] traps: ld-linux-x32.so[11047] general protection ip:f7770eed sp:ffa3cc88 error:0 in ld-2.17.so[f775a000+21000] The /boot/initrd.img-3.12-1-amd64 file appears to be written properly but grub then fails to link to it. ld-linux-x32.so - ld-2.17.so which is part of: libc6-x32 2.17-97 amd64 -- -- Package-specific info: -- initramfs sizes -rw-r--r-- 1 root root 13M Nov 16 23:01 /boot/initrd.img-3.10-3-amd64 -rw-r--r-- 1 root root 14M Dec 25 20:27 /boot/initrd.img-3.11-2-amd64 -rw-r--r-- 1 root root 14M Jan 24 05:00 /boot/initrd.img-3.12-1-amd64 -- /proc/cmdline ge-3.13.0_c2+ ro root=/dev/sdb1 -- resume RESUME=/dev/sdc5 -- /proc/filesystems ext3 ext2 ext4 -- lsmod Module Size Used by snd_hrtimer 1580 1 cpufreq_userspace 1357 0 cpufreq_stats 2485 0 cpufreq_powersave902 0 lp 8629 0 hwmon_vid 3076 0 nfsd 226081 13 auth_rpcgss41510 1 nfsd oid_registry2243 1 auth_rpcgss exportfs3531 1 nfsd nfs_acl 2463 1 nfsd nfs 113141 0 lockd 59385 2 nfs,nfsd sunrpc166232 23 nfs,nfsd,auth_rpcgss,lockd,nfs_acl ipv6 261563 54 analog 7326 0 joydev 9063 0 dm_crypt 16095 0 dm_mod 74267 1 dm_crypt fbcon 37107 70 bitblit 4937 1 fbcon softcursor 1213 1 bitblit font7364 1 fbcon pcspkr 1811 0 psmouse59313 0 serio_raw 4185 0 evdev 10005 2 snd_seq_dummy 1311 0 nouveau 1003469 1 snd_intel8x0 26980 0 video 10953 1 nouveau snd_ac97_codec106873 1 snd_intel8x0 backlight 5318 1 video mxm_wmi 1379 1 nouveau ac97_bus1150 1 snd_ac97_codec wmi 7747 2 mxm_wmi,nouveau snd_pcm_oss36911 0 ttm55665 1 nouveau snd_mixer_oss 13917 1 snd_pcm_oss drm_kms_helper 27254 1 nouveau snd_pcm71923 3 snd_pcm_oss,snd_ac97_codec,snd_intel8x0 drm 213715 3 ttm,drm_kms_helper,nouveau snd_page_alloc 6922 2 snd_intel8x0,snd_pcm snd_mpu401 3992 0 snd_mpu401_uart 5155 1 snd_mpu401 snd_seq_midi4624 0 k8temp 3386 0 snd_rawmidi16951 2 snd_mpu401_uart,snd_seq_midi i2c_algo_bit5175 1 nouveau hwmon 2769 2 k8temp,nouveau snd_seq_oss25945 0 snd_seq_midi_event 5156 2 snd_seq_oss,snd_seq_midi sg 26334 0 forcedeth 51110 0 snd_seq42858 7 snd_seq_midi_event,snd_seq_oss,snd_seq_dummy,snd_seq_midi sr_mod 13010 0 parport_pc 25852 1 snd_seq_device 4900 5 snd_seq,snd_rawmidi,snd_seq_oss,snd_seq_dummy,snd_seq_midi ohci_pci2952 0 cdrom 33057 1 sr_mod snd_timer 17228 3 snd_hrtimer,snd_pcm,snd_seq ohci_hcd 18241 1 ohci_pci parport28919 2 lp,parport_pc thermal 8212 0 i2c_nforce2 5039 0 snd52105 13
Bug#736659: closed by Ben Hutchings b...@decadent.org.uk (Re: Bug#736659: traps: ld-linux-x32.so[10769] general protection)
On Sat, Jan 25, 2014 at 09:21:23PM +, Debian Bug Tracking System wrote: Date: Sat, 25 Jan 2014 21:18:51 + From: Ben Hutchings b...@decadent.org.uk To: 736659-d...@bugs.debian.org Subject: Re: Bug#736659: traps: ld-linux-x32.so[10769] general protection X-Mailer: Evolution 3.8.5-2+b1 On Fri, 2014-01-24 at 05:30 +, ael wrote: [...] ld-linux-x32.so - ld-2.17.so which is part of: libc6-x32 2.17-97 amd64 [...] Don't install x32 libraries unless you run a custom kernel that supports them. That was a quick response! I had just discovered that that was an embedded 32 bit library and was puzzling about how it had been installed :-) I think I may have a misconfiguration from before multiarch support. Apologies for the noise. ael -- 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/20140125215742.GA3793@precise.conquest
Bug#733226: linux-image-3.11-2-686-pae: segfault index++
] EXT4-fs (sdb7): re-mounted. Opts: (null) [ 45.576512] EXT4-fs (sdb7): re-mounted. Opts: (null) [ 49.144613] apm: BIOS not found. [ 50.094677] bio: create slab bio-1 at 1 [ 50.363574] sbawe 01:01.00: [irq 10] [ 50.363630] sbawe 01:01.00: [dma 1] [ 50.363664] sbawe 01:01.00: [dma 5] [ 50.363725] sbawe 01:01.00: [io 0x0220-0x022f] [ 50.363771] sbawe 01:01.00: [io 0x0300-0x0301] [ 50.363815] sbawe 01:01.00: [io 0x0388-0x038b] [ 50.366186] sbawe 01:01.00: activated [ 50.366326] sbawe 01:01.02: [io 0x0620-0x0623] [ 50.366375] sbawe 01:01.02: [io 0x0a20-0x0a23] [ 50.366422] sbawe 01:01.02: [io 0x0e20-0x0e23] [ 50.368715] sbawe 01:01.02: activated [ 50.736496] udevd[910]: failed to execute '/usr/sbin/alsactl' '/usr/sbin/alsactl -E HOME=/var/run/alsa restore ': No such file or directory [ 51.035924] lp: driver loaded but no devices found [ 51.172729] fuse init (API version 7.22) [ 53.306456] EXT4-fs (sdb3): mounting ext2 file system using the ext4 subsystem [ 53.336190] EXT4-fs (sdb3): mounted filesystem without journal. Opts: (null) [ 53.338026] EXT4-fs (sdc3): mounting ext3 file system using the ext4 subsystem [ 53.360468] EXT4-fs (sdc3): mounted filesystem with ordered data mode. Opts: (null) [ 53.390682] EXT4-fs (dm-0): mounted filesystem with ordered data mode. Opts: (null) [ 53.526695] FAT-fs (sdb1): utf8 is not a recommended IO charset for FAT filesystems, filesystem will be case sensitive! [ 53.693083] FAT-fs (sdc1): utf8 is not a recommended IO charset for FAT filesystems, filesystem will be case sensitive! [ 63.816303] net eth0: Setting full-duplex based on MII#1 link partner capability of cde1 [ 64.029029] RPC: Registered named UNIX socket transport module. [ 64.029157] RPC: Registered udp transport module. [ 64.029240] RPC: Registered tcp transport module. [ 64.029322] RPC: Registered tcp NFSv4.1 backchannel transport module. [ 64.101012] FS-Cache: Loaded [ 64.258223] FS-Cache: Netfs 'nfs' registered for caching [ 64.505019] Installing knfsd (copyright (C) 1996 o...@monad.swb.de). [ 77.231612] [drm] Initialized drm 1.1.0 20060810 [ 77.265299] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). [ 77.265422] [drm] No driver support for vblank timestamp query. [ 77.265519] [drm] Initialized mga 3.2.1 20051102 for :01:00.0 on minor 0 [ 77.395053] w83781d: Found a W83781D chip at 0x290 [ 78.198740] ip_tables: (C) 2000-2006 Netfilter Core Team [ 78.576898] nf_conntrack version 0.5.0 (8014 buckets, 32056 max) [ 79.826060] ppdev: user-space parallel port driver [ 79.878002] parport_pc 00:0e: reported by Plug and Play BIOS [ 79.878284] parport0: PC-style at 0x378 (0x778), irq 7 [PCSPP,TRISTATE,EPP] [ 79.981703] lp0: using parport0 (interrupt-driven). [ 98.885154] NFSD: Using /var/lib/nfs/v4recovery as the NFSv4 state recovery directory [ 98.900781] NFSD: starting 90-second grace period (net c15728c0) [ 140.077033] systemd-logind[3024]: New seat seat0. [ 140.089037] systemd-logind[3024]: New session c1 of user root. [ 315.028918] index++[3263]: segfault at b78ebd50 ip 08054a17 sp bf8008e8 error 4 in index++[8048000+27000] [ 356.571815] index++[3293]: segfault at b7887d50 ip 08054a17 sp bf933e38 error 4 in index++[8048000+27000] [ 498.682620] systemd-logind[3024]: New session c2 of user ael. [ 524.196689] systemd-logind[3024]: New session c3 of user ael. ** Model information not available ** Loaded modules: snd_hrtimer parport_pc ppdev nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack xt_LOG xt_limit iptable_filter ip_tables x_tables eeprom w83781d hwmon_vid mga drm nfsd auth_rpcgss oid_registry nfs_acl nfs lockd fscache sunrpc nls_utf8 nls_cp437 vfat fat fuse lp parport snd_emu8000_synth snd_emux_synth snd_util_mem snd_seq_midi_emul snd_seq_virmidi snd_sbawe snd_sb16_csp snd_sb16_dsp snd_sb_common snd_mpu401_uart snd_opl3_lib snd_hwdep snd_pcm_oss snd_mixer_oss snd_pcm snd_page_alloc snd_seq_midi snd_seq_midi_event snd_rawmidi snd_seq snd_seq_device snd_timer snd soundcore dm_crypt microcode pcspkr psmouse evdev serio_raw i2c_piix4 shpchp i2c_core ext4 crc16 mbcache jbd2 dm_mod sg osst st sr_mod cdrom sd_mod crc_t10dif ata_generic ata_piix uhci_hcd ehci_hcd aic7xxx libata scsi_transport_spi tulip usbcore usb_common scsi_mod ** PCI devices: 00:00.0 Host bridge [0600]: Intel Corporation 440BX/ZX/DX - 82443BX/ZX/DX Host bridge [8086:7190] (rev 02) 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: 64 Region 0: Memory at e000 (32-bit, prefetchable) [size=64M] Capabilities: access denied Kernel driver in use: agpgart-intel 00:01.0 PCI bridge [0604]: Intel Corporation 440BX/ZX/DX - 82443BX/ZX/DX AGP bridge [8086:7191] (rev 02) (prog-if 00 [Normal decode]) Control: I/O
Bug#732117: Loop mounts ok on another machine.
I have just tried mounting the target filesystem (via nfs) on another (amd64) machine. There I can successfully loopmount debian-testing-source-DVD-1old.iso . I expected that to work, but thought I should check. ael -- 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/20131227200210.GA9285@exact.conquest
Bug#732117: mount under strace -f
On Sun, Dec 15, 2013 at 01:51:40PM -0500, Phillip Susi wrote: No, it's being called with a 4096 byte buffer size. The problem seems to be here: mount(/dev/loop0, /loopmnt1, iso9660, MS_MGC_VAL, NULL) = -1 EACCES (Permission denied) Root shouldn't be denied permission to mount. Maybe you're using selinux or an apparmor profile or something? I don't really know exactly how those work but the problem seems to be on the kernel side. I have libselinux1 installed as a dependency going back to core-utils but I am not making any explicit use of it. Also I can mount, for example, a usbstick: # mount /dev/disk/by-label/something /loopmnt1 without problems. A further data point: I have tried under a self compiled stock kernel: Linux exact 3.13.0-rc4_exact-293734-g319e2e3 #380 Tue Dec 17 16:42:27 GMT 2013 i686 GNU/Linux Same results. So it seems that it is not a particular kernel. ael -- 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/20131217184529.GA4729@exact.conquest
Bug#622231: psmouse module doesn't reliably detect Synaptics touchpad
: Adding input device SynPS/2 Synaptics TouchPad (/dev/input/mouse0) [ 2363.725] (**) SynPS/2 Synaptics TouchPad: Ignoring device from InputClass touchpad ignore duplicates - So it looks as if the kernel passed some sort of disconnect event to udev, but as there are no time stamps, I am not sure how this fits with the other symptoms. I realize this isn't a lot of help, but if this reaches Vojtech Pavlik's eyes, maybe he can spot what might be happening... ael -- 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/20120818145316.GA4143@elf.conquest
Bug#683111: Similar oops: looking reproducible
Another similar oops with 3.2.0-3-686-pae: Jul 29 20:07:57 elf kernel: [ 81.343324] [ cut here ] Jul 29 20:07:57 elf kernel: [ 81.343342] WARNING: at /build/buildd-linux_3.2.2 1-3-i386-vEohn4/linux-3.2.21/block/genhd.c:1573 disk_clear_events+0xa7/0xd6() Jul 29 20:07:57 elf kernel: [ 81.343349] Hardware name: AOA110 Jul 29 20:07:57 elf kernel: [ 81.343353] Modules linked in: usb_storage uas sn d_hrtimer microcode cpufreq_powersave cpufreq_userspace cpufreq_stats cpufreq_conservative uinput fuse nfsd nfs nfs_acl auth_rpcgss fscache lockd sunrpc loop dm_crypt dm_mod joydev snd_hda_codec_realtek snd_hda_intel arc4 snd_hda_codec snd_hwdep sparse_keymap snd_pcm_oss snd_mixer_oss snd_pcm uvcvideo snd_page_alloc videodev snd_seq_midi snd_seq_midi_event media ath5k snd_rawmidi acerhdf ath coretemp mac80211 pcspkr jmb38x_ms psmouse iTCO_wdt cfg80211 iTCO_vendor_support memstick evdev serio_raw snd_seq rng_core i2c_i801 rfkill i915 snd_seq_device snd_timer snd drm_kms_helper drm soundcore i2c_algo_bit i2c_core wmi battery ac acpi_cpufreq video power_supply mperf button processor thermal_sys ext4 crc16 jbd2 mbcache mmc_block sd_mod crc_t10dif ata_generic ata_piix libata uhci_hcd scsi_mod ehci_hcd usbcore usb_common sdhci_pci sdhci mmc_core r8169 mii [last unloaded: scsi_wait_scan] Jul 29 20:07:57 elf kernel: [ 81.343535] Pid: 4099, comm: blkid Not tainted 3.2.0-3-686-pae #1 Jul 29 20:07:57 elf kernel: [ 81.343540] Call Trace: Jul 29 20:07:57 elf kernel: [ 81.343553] [c1037fcc] ? warn_slowpath_common+0x68/0x79 Jul 29 20:07:57 elf kernel: [ 81.343562] [c1154145] ? disk_clear_events+0xa7/0xd6 Jul 29 20:07:57 elf kernel: [ 81.343570] [c1037fea] ? warn_slowpath_null+0xd/0x10 Jul 29 20:07:57 elf kernel: [ 81.343578] [c1154145] ? disk_clear_events+0xa7/0xd6 Jul 29 20:07:57 elf kernel: [ 81.343597] [c10ed4e6] ? check_disk_change+0x1a/0x40 Jul 29 20:07:57 elf kernel: [ 81.343616] [f826c28e] ? sd_open+0xc6/0x164 [sd_mod] Jul 29 20:07:57 elf kernel: [ 81.343625] [c10ee298] ? __blkdev_get+0x23e/0x334 Jul 29 20:07:57 elf kernel: [ 81.343637] [c10ee517] ? blkdev_get+0x189/0x253 Jul 29 20:07:57 elf kernel: [ 81.343646] [c1120824] ? fsnotify_perm+0x4e/0x5a Jul 29 20:07:57 elf kernel: [ 81.343654] [c10edc1f] ? bd_acquire+0x20/0x89 Jul 29 20:07:57 elf kernel: [ 81.343663] [c10ca6bf] ? __dentry_open+0x17a/0x253 Jul 29 20:07:57 elf kernel: [ 81.343672] [c10cb403] ? nameidata_to_filp+0x3a/0x45 Jul 29 20:07:57 elf kernel: [ 81.343679] [c10ee5e1] ? blkdev_get+0x253/0x253 Jul 29 20:07:57 elf kernel: [ 81.343687] [c10d54be] ? do_last+0x4f8/0x513 Jul 29 20:07:57 elf kernel: [ 81.343695] [c10d5780] ? path_openat+0xa1/0x287 Jul 29 20:07:57 elf kernel: [ 81.343703] [c10d5a0f] ? do_filp_open+0x23/0x5c Jul 29 20:07:57 elf kernel: [ 81.343712] [c1029ee0] ? should_resched+0x5/0x1e Jul 29 20:07:57 elf kernel: [ 81.343722] [c12be8b1] ? _cond_resched+0x5/0x18 Jul 29 20:07:57 elf kernel: [ 81.343730] [c10cb462] ? do_sys_open+0x54/0xcd Jul 29 20:07:57 elf kernel: [ 81.343738] [c10cb4f9] ? sys_open+0x1e/0x23 Jul 29 20:07:57 elf kernel: [ 81.343747] [c12c409f] ? sysenter_do_call+0x12/0x28 Jul 29 20:07:57 elf kernel: [ 81.343753] ---[ end trace 300852c97cb3e80f ]--- -- -- 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/20120729191740.GA4234@elf.conquest
Bug#627933: Regression: hot plugging sdhc card on Acer Aspire One
On Wed, May 25, 2011 at 05:00:35PM +, maximilian attems wrote: On Wed, May 25, 2011 at 05:49:03PM +0100, ael wrote: Package: linux-2.6 Version: 2.6.38-5 Severity: normal The Acer Aspire One netbook has two card readers, left right. Until recently (sorry not sure when regression happened) hotplugging the right hand card worked. But now such a card is only seen on cold boot. I am reporting on a system which has just booted with the card present, and all is well: $ ls -l /dev/disk/by-label/ please try against 2.6.39 in unstable, outdated linux image report against. Same bug has been present in all kernels since. I am currently on 3.2.0-2-686-pae. ael -- 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/20120501134245.GA4728@elf.conquest
Bug#576918: Keyboard disabled: atkbd.c: Spurious ACK on isa0060/serio0 ...
On Thu, Feb 09, 2012 at 09:44:57PM -0600, Jonathan Nieder wrote: ael wrote: With Linux 2.6.32-trunk-686 Linux 2.6.32-3-686, at least, on this Aspire One Netbook, the system frequently boots into a state in which the keyboard does not respond. The mouse (Synaptics touchpad) is still active, and as far as I can tell everything else is working. My only recourse is to hit the reset button. So this is nondeterministic, and so probably some sort of race? I *think* that it happens more frequently if I happen to touch the ps/2 touchpad during boot, but it definitely does still happen when I keep my hands well away during boot. Hey, neat. What's the newest kernel you've tried? Please attach full dmesg output from a good boot and a bad boot, even though as you mentioned there might not be any significant difference between them. Sorry for the long quiet. Well, it really is a long time. I am running testing so I have been through many kernels since this report. With recent kernels - I am running 3.1.0-1-686-pae today - this no longer happens. *However*, there is still some nondeterministic misbehaviour with the driver. 1) On maybe 10% of boots, the right button is not recognised. I test with mev, or if I have started X, then I use xev. There is simply no response to the button. Reloading the psmouse module (and presumably its dependants) does not solve the problem. Rebooting seems to be the only recourse. 2) In X, the VerticalEdgeScroll HorizEdgeScroll sometimes do not work. That is cured by rmmod psmouse; modprobe psmouse. Not sure that this is same problem, but again nondeterministic. I realize that this information is unlikely to be of much help in trying to localize the problem. My *impression* as I have seen various kernels behave in slightly different ways is that there are races happening, but the trigering and effects vary in frequency and importance as the code context changes. Just as one might expect :-) If you have any suggestions for how to diagnose the problem, let me know. I will try to collect a dmesg.diff for boots with working and failing right button recognition, but IIRC I tried that sort of thing earlier and could see no useful information. ael -- 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/20120210103742.GA2439@elf.conquest
Bug#640391: Possible fix ark3116
On Wed, Oct 26, 2011 at 09:09:47AM +0200, Bart Hartgers wrote: 2011/10/25 ael law_ence@ntlworld.com: On Tue, Oct 25, 2011 at 08:40:09PM +0200, Bart Hartgers wrote: I think I got it. The ark seems sensitive to a specific combination of setting the termios and enabling interrupts/submitting the interrupt urb. The old driver does not suffer because it does not use the interrupt urb. Success! Congratulations. Great! So wonderful. Thanks for all the work. Just a quick reply for tonight: you can stop biting your fingernails... Thanks! I'll create a patch and submit it to the kernel. Okay if I include you as tester in a Tested-by:-tag? I will be honoured :-) I haven't tried hotplugging of course, but I guess that must work. I might have time to see if I can do that easily later today. ael -- 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/20111026100508.GA2499@elf.conquest
Bug#640391: Possible fix ark3116
On Tue, Oct 25, 2011 at 08:40:09PM +0200, Bart Hartgers wrote: Hi ael, I think I got it. The ark seems sensitive to a specific combination of setting the termios and enabling interrupts/submitting the interrupt urb. The old driver does not suffer because it does not use the interrupt urb. Success! Congratulations. I thought I was going to have to break bad news when my first few attempts failed, but that seems to have been a flakey connection. So wonderful. Thanks for all the work. Just a quick reply for tonight: you can stop biting your fingernails... ael -- 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/20111025204123.GA3331@elf.conquest
Bug#624443: Closing
No problems recently so will close. -- 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/20111023084536.GA2999@elf.conquest
Bug#640391: Test result
On Sat, Oct 08, 2011 at 10:40:01PM +0200, Bart Hartgers wrote: Does this new version make any difference? To confuse you, I did not include a version number in the filenames ;-). Sorry for the delay in answering. Since my main 'scope has a video problem which I don't want to exacerbate by running it, I dug out an old serial protocol analyser and also an old digital storage adaptor to use with a real time 'scope. It took a while to find the manuals and refresh my memory on how they all worked. However, I fear that neither of the test versions that you sent make any difference. The UART end of the ark3116 continues to behave as if it is switched off, as you said. I can't think of any sensible suggestions apart from porting the old version to the new kernel essentially unchanged: which I am sure you have already considered. And then incrementally change to the new version. I can test the intermediate versions, and maybe pick up the critical change. Unfortunately in about 1 week, I will be away from my instruments for a time, perhaps up to a month. But I should still have email (dongle) and the gps, so I could still test basic functionality. I wish that I could be of more help:-( I could maybe hack around with the source a bit trying to change register bits. I must have a 16450 datasheet somewhere which should help a bit with avoiding messing up the known bits. ael -- 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/20111009154134.GA2955@elf.conquest
Bug#640391: ark3116 driver regression: oscilloscope shows no transmission
On Sat, Oct 08, 2011 at 08:48:20PM +0200, Bart Hartgers wrote: I had some trouble myself to get hold of the 3.0 source with the kernel.org infrastructure being down. So I settled for using 2.6.39 (that I downloaded a while ago) and looking at a source indexing website to make sure that the ark3116 in 3.0 and 2.6.39 are the same ;-). I attached .tar.gz containing the source for the test version. If you run 'make', it should build ark3116new.ko. Make sure you insmod that one before plugging in the ark3116. In my case I had to run 'modprobe usbserial' first, otherwise there were unresolved symbols. For building the driver, I need at least the 'linux-headers-generic' and 'build-essential' packages on ubuntu. I guess debian will need something similar. I am downloading the linux-headers-nnn package as I type, and it is also pulling down linux-kbuild-nnn as well. I am on the netbook just now I am not sure how much extra in the way of compilers and dev packages I will need. I may transfer to a proper desktop for the compilation if it gets too heavy. Let me know if you run into problems. I haven't used debian for a while, but I do have current experience with ubuntu, so I might be able to help. It *should* be straight forward, but you never know... I will have a quick attempt tonight, but may have to leave things to at least tomorrow if there are any complications. I too am very interested to see what happens... ael -- 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/20111008194053.GA2441@elf.conquest
Bug#640391: ark3116 new version
On Sat, Oct 08, 2011 at 08:48:20PM +0200, Bart Hartgers wrote: I attached .tar.gz containing the source for the test version. If you run 'make', it should build ark3116new.ko. It compiled :-) And built ark3116test.ko, not ark3116new.ko, but I am sure you just changed the name. It also loaded into the kernel without problems. Off the get the get the gps and ark3116 hardware. Fingers crossed :-) ael -- 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/20111008195400.GB2441@elf.conquest
Bug#640391: Test result
On Sat, Oct 08, 2011 at 08:48:20PM +0200, Bart Hartgers wrote: the electrical properties, and says nothing on how to control it over the usb bus. So not helpful in our case. I compared the registers accessed by the original driver to the new one, and I found one register that is only accessed in the new driver. From the windows driver, I could see it had something to do with baudrate selection. That said, it never actually affected the baudrate on my hardware. But perhaps it does something bad on yours. I removed the access to that register to see if it helps. Sorry. I have just done several tests, and they all failed in just the usual way :-( I have not got the serial breakout box and any instrumentation out, so I can't be absolutely sure that the gps cable is making a good connection. I will check properly tomorrow, but I am pretty certain that the test version is behaving just as before. Very disappointing: sorry again to be the bearer of bad news... ael -- 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/20111008200432.GC2441@elf.conquest
Bug#640391: ark3116 driver regression: oscilloscope shows no transmission
I managed to get an oscilloscope onto the breakout box between the garmin gps and the ark. This despite the oscilloscope deciding to develop a video fault :-( As I had suspected from the multimeter measurements, it seems that the ark 3116 does not transmit *anything* under the latest kernel (on the usual gpsbabel test). Under the old working kernel, I saw packets in both directions. For the record, the gps tx line was swinging between +5.6V and -5.4V, while the ark3116 board was driving the gps rx line between 0V and 3.2V. But under kernel 3.0.0-1, I could not get the 'scope to trigger on either line, nor could see any activity. So my conclusion is that the module is somehow setting the ark3116 into a mode whereby it cannot transmit if only the tx rx (plus grnd=pin5) are connected. Whereas the old version of the module sets it up so that this is possible. Agree? So rather than the gps failing to reply, it seems that the ark3116 never sends anything. If I had had a little more time, and the 'scope did not keep dying, I would have tried pulling the other lines up or down to see whether transmission suddenly came to life. I don't think there is now any point in trying a connection to an ordinary serial port is there? Is there anything else I can do at this stage? ael -- 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/20111002220459.GA2630@elf.conquest
Bug#640391: linux-image-3.0.0-1-686-pae: ark3116 driver regression
This is just an interim report on what I have discovered so far. 1) The garmin gps serial connection uses on 3 signals: rx,tx and grnd which are taken to the 9-pin coonector as follows: Garmin etrek hc 9-pin -- - rx pin 3 tx pin 2 grndpin 5 All the other pins on the 9-pin RS232 connector seem to be open. I have run the usual gpsbabel -w -i garmin -f /dev/ttyUSB0 -o gpx -F test.gpx test on the old working kernel. The breakout box (a Cablefaker) shows activity on the rx, tx lines as expected. Trying the same on the failing 3.0.0-xx kernel, the breakout box shows no activity at all. Which suggests that gpsbabel is not managing to send anything to the gps at all. Rather than the gps failing to respond, it looks if nothing is sent in the first place. I do not know how the ark chip is connected to its male 9 pin connector: it is moulded plastic and there does not seem to be anyway to dismantle it. The plastic shell is slightly transparent, and it looks as if all 9 pins are soldered to the pcb, but that might just be for physical support. I have yet to check other aspects and get an oscilloscope on the signals, nor try the other experiments suggested, so this is partial and to be continued. ael -- 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/20111001135954.GA2639@elf.conquest
Bug#640391: linux-image-3.0.0-1-686-pae: ark3116 driver regression
/drivers/usb/serial/ark3116.c: ark3116_ioctl cmd 0x5404 not supported Oct 1 17:51:36 elf kernel: [ 2287.169728] /tmp/buildd/linux-2.6-2.6.32/debian/build/source_i386_none/drivers/usb/serial/ark3116.c: ark3116_set_termios - port 0 Oct 1 17:51:36 elf kernel: [ 2287.169744] /tmp/buildd/linux-2.6-2.6.32/debian/build/source_i386_none/drivers/usb/serial/ark3116.c: setting CS8 Oct 1 17:51:36 elf kernel: [ 2287.169756] /tmp/buildd/linux-2.6-2.6.32/debian/build/source_i386_none/drivers/usb/serial/ark3116.c: setting parity to NONE Oct 1 17:51:36 elf kernel: [ 2287.169768] /tmp/buildd/linux-2.6-2.6.32/debian/build/source_i386_none/drivers/usb/serial/ark3116.c: setting 1 stop bit Oct 1 17:51:36 elf kernel: [ 2287.170708] /tmp/buildd/linux-2.6-2.6.32/debian/build/source_i386_none/drivers/usb/serial/ark3116.c: 000 1 bytes [0x03] Oct 1 17:51:36 elf kernel: [ 2287.170723] /tmp/buildd/linux-2.6-2.6.32/debian/build/source_i386_none/drivers/usb/serial/ark3116.c: setting baudrate to 9600 (-reg=312) Oct 1 17:51:36 elf kernel: [ 2287.171691] /tmp/buildd/linux-2.6-2.6.32/debian/build/source_i386_none/drivers/usb/serial/ark3116.c: 147 ok Oct 1 17:51:36 elf kernel: [ 2287.176086] /tmp/buildd/linux-2.6-2.6.32/debian/build/source_i386_none/drivers/usb/serial/ark3116.c: 148 ok Oct 1 17:51:36 elf kernel: [ 2287.176686] /tmp/buildd/linux-2.6-2.6.32/debian/build/source_i386_none/drivers/usb/serial/ark3116.c: 149 ok Oct 1 17:51:36 elf kernel: [ 2287.177661] /tmp/buildd/linux-2.6-2.6.32/debian/build/source_i386_none/drivers/usb/serial/ark3116.c: 150 ok Oct 1 17:51:36 elf kernel: [ 2287.178794] /tmp/buildd/linux-2.6-2.6.32/debian/build/source_i386_none/drivers/usb/serial/ark3116.c: 151 1 bytes [0x03] Oct 1 17:51:36 elf kernel: [ 2287.179657] /tmp/buildd/linux-2.6-2.6.32/debian/build/source_i386_none/drivers/usb/serial/ark3116.c: 152 ok Oct 1 17:51:36 elf kernel: [ 2287.179668] /tmp/buildd/linux-2.6-2.6.32/debian/build/source_i386_none/drivers/usb/serial/ark3116.c: updating bit count, stop bit or parity (cfg=0x03) Oct 1 17:51:36 elf kernel: [ 2287.180664] /tmp/buildd/linux-2.6-2.6.32/debian/build/source_i386_none/drivers/usb/serial/ark3116.c: 153 1 bytes [0x00] Oct 1 17:51:36 elf kernel: [ 2287.181658] /tmp/buildd/linux-2.6-2.6.32/debian/build/source_i386_none/drivers/usb/serial/ark3116.c: 154 ok Oct 1 17:51:36 elf kernel: [ 2287.181682] /tmp/buildd/linux-2.6-2.6.32/debian/build/source_i386_none/drivers/usb/serial/ark3116.c: ark3116_ioctl cmd 0x5401 not supported -- I will report what happens on shorting pin 4 under kernel-3.0.0 in the next message. Any suggestions before I get the oscilloscope out? ael -- 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/20111001170123.GA2273@elf.conquest
Bug#640391: linux-image-3.0.0-1-686-pae: ark3116 driver regression
I have just tried shorting pin 4 (rts ?) to ground under kernel-3.0.0. This with debug=1 on the module. Absolutely nothing in /var/log/debug or dmesq. I tried several times. So this seems to be a major difference from the old working modules. As for the explanation... Progress of a sort, I think. I just might get the 'scope out later this evening if I have time. ael -- 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/20111001171145.GA2537@elf.conquest
Bug#640391: linux-image-3.0.0-1-686-pae: ark3116 driver regression
On Sat, Oct 01, 2011 at 06:01:24PM +0100, ael wrote: 3) Both ark and garmin attached and working. pin 2 (tx on gps) : 0.01V on module load pin 3 (rx on gps) : -5.52V on module load Looks to me as if I reversed pins 2 3 above, although it is what I wrote down at the time... ael -- 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/20111001193821.GA2534@precise.conquest
Bug#640391: linux-image-3.0.0-1-686-pae: ark3116 driver regression
On Thu, Sep 29, 2011 at 04:35:31PM +0200, Bart Hartgers wrote: Hi ael, I have a real RS232 port on a desktop (back at home now), so I guess I could connect from the netbook USB - ark3116 - RS232 desktop. I will have to see what cables I have, but I think I have a very old RS232 breakout box somewhere, so I can probably fix something up. I have found the breakout box. Unfortunately it is all 25 pin connectors, so I will have to dig out or make some 25 -- 9 pin cables. Make take a while... That would be great! Hopefully we can make some progress that way. I suppose I could use picoterm or similar to view the incoming data on the desktop: it is a while since I looked at those programs. I realized I made a mistake: the program I meant is called picocom. If you have a breakout-box, it would also be interesting to 'manually' toggle some signals, basically just short rxd and/or cts to gnd for a sec. That should trigger some messages in the log if the ark3116 module is loaded with debug=1. It is a very long time since I played with stty, statserial and such. So I may need to pore over man pages try and work out what I am doing. I seem to remember having using minicom at one time. I think one could set up the serial parameters from a menu, and otherwise it just worked as a terminal. Somewhere, I think I have the specification for the garmin connector, but I can trace the wires otherwise. I guess I will start there. It can't be very complicated. I suppose just using statserial while the garmin is attached to the ordinary RS232 port would at least reveal its initial state. Unfortunately a hard disc has just failed on one machine (it would have to be the boot disc..) and the latest xorg packages have decided to stop working properly on another machine, so I have my hands rather full just now... ) ael Thanks! Bart -- Bart Hartgers - New e-mail: bart.hartg...@gmail.com -- 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/20110929154741.GA2693@conquest3.conquest
Bug#640391: linux-image-3.0.0-1-686-pae: ark3116 driver regression
On Wed, Sep 28, 2011 at 08:55:40PM +0200, Bart Hartgers wrote: 2011/9/21 ael law_ence@ntlworld.com: I have just done another test. This because that garmin odd connector often fails to make proper contact. So in this case I first verified that I could use gpsbabel successfully with the old kernel, so confirming a  proper connection. Then I just used $ gpsbabel -w -i garmin -f /dev/ttyUSB0 -o gpx -F test.gpx [ERROR] GPS_Packet_Read: Timeout.  No data received. GARMIN:Can't init /dev/ttyUSB0 Hi ael, I finally managed to find some time to test this on my own hardware on 2.6.38. I do not have a garmin gps, so I connect my ark3116 to a second serial interface. I used the same gpsbabel command as you to connect to my ark3116, and I could see data coming in on the second port and if I sent a reply the other way, it is received by gpsbabel. In short, everything seems to work as it should, which is not helping. Your traces show that gpsbabel never receives anything in your case, so somehow something is behaving different. I am running out of ideas. Would it be possible for you to do a similar experiment with a second serial port? That way we might learn if data actually makes it to the serial output when sending or if data is received on the serial input but not forwarded to the USB bus. I have a real RS232 port on a desktop (back at home now), so I guess I could connect from the netbook USB - ark3116 - RS232 desktop. I will have to see what cables I have, but I think I have a very old RS232 breakout box somewhere, so I can probably fix something up. I suppose I could use picoterm or similar to view the incoming data on the desktop: it is a while since I looked at those programs. I could also use a multimeter or whatever to see how those four wires on the garmin are connected to the 9-pin RS232 plug in case that throws any light on handshaking, if any. I might need a bit of hand holding since my serial knowledge is now rather rusty. It may take a day or two to find time to try all of this. I could also perhaps put an oscilloscope onto the RS232 breakout box to see what at least a couple of the signals are doing, but I will need to clear some bench space which is in very short supply! I guess that might also throw some light on what happens when connected to the garmin. That said, trying to follow serial signals on a 'scope isn't always straight forward: now if I had a logic analyser available, it might be much easier :-) If I do go to the 'scope, I guess a comparison between the old working kernel talking to the garmin and the latest problem version might help. But I suspect triggering properly might make that pretty difficult. ael -- 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/20110928194809.GA4926@elf.conquest
Bug#640391: linux-image-3.0.0-1-686-pae: ark3116 driver regression
I have just done another test. This because that garmin odd connector often fails to make proper contact. So in this case I first verified that I could use gpsbabel successfully with the old kernel, so confirming a proper connection. Then I just used $ gpsbabel -w -i garmin -f /dev/ttyUSB0 -o gpx -F test.gpx [ERROR] GPS_Packet_Read: Timeout. No data received. GARMIN:Can't init /dev/ttyUSB0 Here are the extracts from /var/log/debug: -- Sep 21 19:27:23 elf kernel: [ 105.693623] /build/buildd-linux-2.6_3.0.0-3-i386-G7H4XL/linux-2.6-3.0.0/debian/build/source_i386_none/drivers/usb/serial/ark3116.c: ark3116_set_termios - setting bps to 9600 Sep 21 19:27:23 elf kernel: [ 105.693635] /build/buildd-linux-2.6_3.0.0-3-i386-G7H4XL/linux-2.6-3.0.0/debian/build/source_i386_none/drivers/usb/serial/ark3116.c: ark3116_set_termios - setting hcr:0x00,lcr:0x13,quot:313 Sep 21 19:27:23 elf kernel: [ 105.701012] /build/buildd-linux-2.6_3.0.0-3-i386-G7H4XL/linux-2.6-3.0.0/debian/build/source_i386_none/drivers/usb/serial/ark3116.c: ark3116_set_termios - setting bps to 9600 Sep 21 19:27:23 elf kernel: [ 105.701035] /build/buildd-linux-2.6_3.0.0-3-i386-G7H4XL/linux-2.6-3.0.0/debian/build/source_i386_none/drivers/usb/serial/ark3116.c: ark3116_set_termios - setting hcr:0x00,lcr:0x13,quot:313 Sep 21 19:27:28 elf kernel: [ 109.878778] /build/buildd-linux-2.6_3.0.0-3-i386-G7H4XL/linux-2.6-3.0.0/debian/build/source_i386_none/drivers/usb/serial/ark3116.c: ark3116_read_int_callback - urb shutting down with status: -2 I haven't checked carefully, but I think no change? So I think that is all I can get from the debug log. ael -- 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/20110921184556.GA2449@elf.conquest
Bug#640391: linux-image-3.0.0-1-686-pae: ark3116 driver regression
On Tue, Sep 20, 2011 at 09:38:04PM +0200, Bart Hartgers wrote: Hope something here gives a clue... Alas, no. As far as I can tell, the hardware is correctly setup to do 9600N8 without rtscts handshaking. Nothing in the log about a failing transmit, so it seems that gpsbabel's command goes out to the device, but somehow nothing is received in response. I am now worrying that the garmin connector was not making proper contact. I will try and test again tomorrow, first on the old kernel so that I am sure there is a good connection, and then try again on 3.0.nnn. But I suspect that it was making contact: I tried to check carefully, although that is not always reliable. I'll try to see if my 3116 still works with a 3.0 kernel, hopefully tomorrow. Maybe that brings us further. Thanks again, ael -- 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/20110920195937.GA2896@elf.conquest
Bug#640391: linux-image-3.0.0-1-686-pae: ark3116 driver regression
On Fri, Sep 16, 2011 at 01:17:51PM +0200, Bart Hartgers wrote: [Previous messages are logged at http://bugs.debian.org/640391. I have now tested properly with debug=1. Unfortunately, the problem remains, and I can't see anything new in the messages. # rmmod ark3116; modprobe ark3116 debug=1 # uname -a Linux elf 3.0.0-1-686-pae #1 SMP Sat Aug 27 16:41:03 UTC 2011 i686 GNU/Linux - Sep 18 08:55:59 elf kernel: [ 308.938724] usbcore: registered new interface driver usbserial Sep 18 08:55:59 elf kernel: [ 308.938785] USB Serial support registered for generic Sep 18 08:55:59 elf kernel: [ 308.938860] usbcore: registered new interface driver usbserial_generic Sep 18 08:55:59 elf kernel: [ 308.938868] usbserial: USB Serial Driver core Sep 18 08:55:59 elf kernel: [ 308.942683] USB Serial support registered for ark3116 Sep 18 08:55:59 elf kernel: [ 308.942758] usbcore: registered new interface driver ark3116 Sep 18 08:55:59 elf kernel: [ 308.942767] ark3116:v0.6:USB ARK3116 serial/IrDA driver Sep 18 08:56:05 elf kernel: [ 314.953411] usbcore: deregistering interface driver ark3116 Sep 18 08:56:05 elf kernel: [ 314.953540] USB Serial deregistering driver ark3116 Sep 18 08:56:05 elf kernel: [ 314.967004] USB Serial support registered for ark3116 Sep 18 08:56:05 elf kernel: [ 314.967178] usbcore: registered new interface driver ark3116 Sep 18 08:56:05 elf kernel: [ 314.967195] ark3116:v0.6:USB ARK3116 serial/IrDA driver -- The above messages just from loading the module: the ark3116 was not plugged in. On plugging it: --- Sep 18 08:56:47 elf kernel: [ 357.080183] usb 2-1: new full speed USB device number 2 using uhci_hcd Sep 18 08:56:47 elf kernel: [ 357.240209] usb 2-1: New USB device found, idVendor=6547, idProduct=0232 Sep 18 08:56:47 elf kernel: [ 357.240229] usb 2-1: New USB device strings: Mfr=1, Product=3, SerialNumber=0 Sep 18 08:56:47 elf kernel: [ 357.240243] usb 2-1: Product: USB-UART Controller Sep 18 08:56:47 elf kernel: [ 357.240254] usb 2-1: Manufacturer: ArkMicroChips Sep 18 08:56:47 elf kernel: [ 357.242579] ark3116 2-1:1.0: ark3116 converter detected Sep 18 08:56:47 elf mtp-probe: checking bus 2, device 2: /sys/devices/pci:00/:00:1d.0/usb2/2-1 Sep 18 08:56:47 elf kernel: [ 357.253199] usb 2-1: ark3116 using RS232 mode Sep 18 08:56:47 elf kernel: [ 357.253590] usb 2-1: ark3116 converter now attached to ttyUSB0 Sep 18 08:56:47 elf mtp-probe: bus: 2, device: 2 was not an MTP device Sep 18 08:56:47 elf kernel: [ 357.544206] usb 2-1: ark3116: don't know how to do software flow control Sep 18 08:56:47 elf kernel: [ 357.557194] usb 2-1: ark3116: don't know how to do software flow control Sep 18 08:56:47 elf kernel: [ 357.567194] usb 2-1: ark3116: don't know how to do software flow control Sep 18 08:56:47 elf kernel: [ 357.674193] usb 2-1: ark3116: don't know how to do software flow control Sep 18 08:57:00 elf kernel: [ 370.017895] usb 2-1: ark3116: don't know how to do software flow control Sep 18 08:57:21 elf kernel: [ 391.615318] usb 2-1: ark3116: don't know how to do software flow control -- As far as I can see that is just the same as when debug is not set. Or did I get the parameter wrong? I can't see any acknowledgement that debug is set. ael -- 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/20110918081028.GA2619@elf.conquest
Bug#640391: linux-image-3.0.0-1-686-pae: ark3116 driver regression
On Sun, Sep 18, 2011 at 01:55:50PM +0200, Bart Hartgers wrote: 2011/9/18 ael law_ence@ntlworld.com: On Fri, Sep 16, 2011 at 01:17:51PM +0200, Bart Hartgers wrote: [Previous messages are logged at http://bugs.debian.org/640391. I have now tested properly with debug=1. Unfortunately, the problem remains, and I can't see anything new in the messages. # rmmod ark3116; modprobe ark3116 debug=1 # uname -a Linux elf 3.0.0-1-686-pae #1 SMP Sat Aug 27 16:41:03 UTC 2011 i686 GNU/Linux Sep 18 08:56:47 elf kernel: [ Â 357.253199] usb 2-1: ark3116 using RS232 mode Sep 18 08:56:47 elf kernel: [ Â 357.253590] usb 2-1: ark3116 converter now attached to ttyUSB0 Sep 18 08:56:47 elf mtp-probe: bus: 2, device: 2 was not an MTP device Sep 18 08:56:47 elf kernel: [ Â 357.544206] usb 2-1: ark3116: don't know how to do software flow control Sep 18 08:56:47 elf kernel: [ Â 357.557194] usb 2-1: ark3116: don't know how to do software flow control Sep 18 08:56:47 elf kernel: [ Â 357.567194] usb 2-1: ark3116: don't know how to do software flow control Sep 18 08:56:47 elf kernel: [ Â 357.674193] usb 2-1: ark3116: don't know how to do software flow control Sep 18 08:57:00 elf kernel: [ Â 370.017895] usb 2-1: ark3116: don't know how to do software flow control Sep 18 08:57:21 elf kernel: [ Â 391.615318] usb 2-1: ark3116: don't know how to do software flow control Strange. The rmmod and modprobe shoudl set the debug flag, so I would expect some debug messages around the 'software flow control' stuff. Did you check the output of 'dmesg'? (The prefixes suggest these are coming through syslogd.) Perhaps the debug messages end up in a different log or something? Ooops. I think you are right. I didn't check dmesg directly believing that it all appeared in /var/log/messages. But now I see /var/log/debug.. Sep 18 08:56:47 elf kernel: [ 357.542178] /build/buildd-linux-2.6_3.0.0-3-i386-G7H4XL/linux-2.6-3.0.0/debian/build/source_i386_none/drivers/usb/serial/ark3116.c: ark3116_set_termios - setting bps to 9600 Sep 18 08:56:47 elf kernel: [ 357.542195] /build/buildd-linux-2.6_3.0.0-3-i386-G7H4XL/linux-2.6-3.0.0/debian/build/source_i386_none/drivers/usb/serial/ark3116.c: ark3116_set_termios - setting hcr:0x00,lcr:0x13,quot:313 Sep 18 08:56:47 elf kernel: [ 357.550315] /build/buildd-linux-2.6_3.0.0-3-i386-G7H4XL/linux-2.6-3.0.0/debian/build/source_i386_none/drivers/usb/serial/ark3116.c: ark3116_set_termios - setting bps to 57600 Sep 18 08:56:47 elf kernel: [ 357.550339] /build/buildd-linux-2.6_3.0.0-3-i386-G7H4XL/linux-2.6-3.0.0/debian/build/source_i386_none/drivers/usb/serial/ark3116.c: ark3116_set_termios - setting hcr:0x00,lcr:0x13,quot:52 Sep 18 08:56:47 elf kernel: [ 357.557438] /build/buildd-linux-2.6_3.0.0-3-i386-G7H4XL/linux-2.6-3.0.0/debian/build/source_i386_none/drivers/usb/serial/ark3116.c: ark3116_set_termios - setting bps to 0 Sep 18 08:56:47 elf kernel: [ 357.557460] /build/buildd-linux-2.6_3.0.0-3-i386-G7H4XL/linux-2.6-3.0.0/debian/build/source_i386_none/drivers/usb/serial/ark3116.c: ark3116_set_termios - setting hcr:0x00,lcr:0x13,quot:313 Sep 18 08:56:47 elf kernel: [ 357.667612] /build/buildd-linux-2.6_3.0.0-3-i386-G7H4XL/linux-2.6-3.0.0/debian/build/source_i386_none/drivers/usb/serial/ark3116.c: ark3116_set_termios - setting bps to 57600 Sep 18 08:56:47 elf kernel: [ 357.667636] /build/buildd-linux-2.6_3.0.0-3-i386-G7H4XL/linux-2.6-3.0.0/debian/build/source_i386_none/drivers/usb/serial/ark3116.c: ark3116_set_termios - setting hcr:0x00,lcr:0x13,quot:52 Sep 18 08:57:00 elf kernel: [ 370.008846] /build/buildd-linux-2.6_3.0.0-3-i386-G7H4XL/linux-2.6-3.0.0/debian/build/source_i386_none/drivers/usb/serial/ark3116.c: ark3116_read_int_callback - urb shutting down with status: -2 Sep 18 08:57:00 elf kernel: [ 370.009808] /build/buildd-linux-2.6_3.0.0-3-i386-G7H4XL/linux-2.6-3.0.0/debian/build/source_i386_none/drivers/usb/serial/ark3116.c: ark3116_set_termios - setting bps to 9600 Sep 18 08:57:00 elf kernel: [ 370.009872] /build/buildd-linux-2.6_3.0.0-3-i386-G7H4XL/linux-2.6-3.0.0/debian/build/source_i386_none/drivers/usb/serial/ark3116.c: ark3116_set_termios - setting hcr:0x00,lcr:0x13,quot:313 Sep 18 08:57:00 elf kernel: [ 370.022971] /build/buildd-linux-2.6_3.0.0-3-i386-G7H4XL/linux-2.6-3.0.0/debian/build/source_i386_none/drivers/usb/serial/ark3116.c: ark3116_set_termios - setting bps to 115200 Sep 18 08:57:00 elf kernel: [ 370.022994] /build/buildd-linux-2.6_3.0.0-3-i386-G7H4XL/linux-2.6-3.0.0/debian/build/source_i386_none/drivers/usb/serial/ark3116.c: ark3116_set_termios - setting hcr:0x00,lcr:0x13,quot:26 Sep 18 08:57:06 elf kernel: [ 376.007693] /build/buildd-linux-2.6_3.0.0-3-i386-G7H4XL/linux-2.6-3.0.0/debian/build/source_i386_none/drivers/usb/serial/ark3116.c: ark3116_read_int_callback - urb shutting down with status: -2 Sep 18 08:57:21 elf kernel
Bug#640391: linux-image-3.0.0-1-686-pae: ark3116 driver regression
On Fri, Sep 16, 2011 at 01:17:51PM +0200, Bart Hartgers wrote: 2011/9/13 ael law_ence@ntlworld.com: On Tue, Sep 13, 2011 at 08:56:54PM +0200, Bart Hartgers wrote: [Previous messages are logged at http://bugs.debian.org/640391. truncated the termios data. Could you please rerun the strace with the '-v' option? Ok. Attached. Hi ael, As far as I can tell from the logs, gpsbabel does not enable handshaking. Unfortunately I do not another idea of what might be the problem. Another thing to try would be to load the ark3116 module with the debug=1 flag. Maybe something will appear in the kernel log/dmesg that gives a clue to what is going on. I'll see if I can find my ark3116 and hook it up with a null modem to try to reproduce the problem myself. But it will take a while before I can spend some time on that. I would try that now but it is a bit late and I am too tired to get the gps unit out and connect it tonight. But note that the dmesgs appear when the module is loaded before gpsbabel is run. I thought that I looked at the modinfo for ark3116 for a debug parameter: I must have missed it. But what I can do now is connect the ark3116 without the gps unit attached. Without debug, I see: Sep 16 20:20:29 elf kernel: [ 886.628117] USB Serial support registered for ark3116 Sep 16 20:20:29 elf kernel: [ 886.628230] ark3116 2-1:1.0: ark3116 converter detected Sep 16 20:20:29 elf kernel: [ 886.639145] usb 2-1: ark3116 using RS232 mode Sep 16 20:20:29 elf kernel: [ 886.639675] usb 2-1: ark3116 converter now attached to ttyUSB2 Sep 16 20:20:29 elf kernel: [ 886.639801] usbcore: registered new interface driver ark3116 Sep 16 20:20:29 elf kernel: [ 886.639818] ark3116:v0.6:USB ARK3116 serial/IrDA driver Sep 16 20:20:29 elf kernel: [ 886.721160] usb 2-1: ark3116: don't know how to do software flow control Sep 16 20:20:29 elf kernel: [ 886.734143] usb 2-1: ark3116: don't know how to do software flow control Sep 16 20:20:29 elf kernel: [ 886.742143] usb 2-1: ark3116: don't know how to do software flow control Sep 16 20:20:29 elf kernel: [ 886.850147] usb 2-1: ark3116: don't know how to do software flow control So that is nothing to do with the gps or gpsbabel. # rmmod ark3116; modprobe ark3116 debug=1 Now the tail of /var/log/messages has:- -- Sep 16 20:22:41 elf kernel: [ 1018.338935] usbcore: deregistering interface driver ark3116 Sep 16 20:22:41 elf kernel: [ 1018.339340] ark3116 ttyUSB2: ark3116 converter now disconnected from ttyUSB2 Sep 16 20:22:41 elf kernel: [ 1018.339442] ark3116 2-1:1.0: device disconnected Sep 16 20:22:41 elf kernel: [ 1018.339542] USB Serial deregistering driver ark3116 Sep 16 20:22:41 elf kernel: [ 1018.361551] USB Serial support registered for ark3116 Sep 16 20:22:41 elf kernel: [ 1018.362726] ark3116 2-1:1.0: ark3116 converter detected Sep 16 20:22:41 elf kernel: [ 1018.373754] usb 2-1: ark3116 using RS232 mode Sep 16 20:22:41 elf kernel: [ 1018.374179] usb 2-1: ark3116 converter now attached to ttyUSB2 Sep 16 20:22:41 elf kernel: [ 1018.374250] usbcore: registered new interface driver ark3116 Sep 16 20:22:41 elf kernel: [ 1018.374259] ark3116:v0.6:USB ARK3116 serial/IrDA driver -- So the don't know how to do messages have gone. Maybe I need to do a hot replug with debug on, or maybe the debug switch has changed a race or some such. I just unplugged and replugged (I assume ark3116 stayed loaded with debug=1 set) and just got: -- Sep 16 20:29:38 elf kernel: [ 1435.592212] usb 2-1: USB disconnect, device number 2 Sep 16 20:29:38 elf kernel: [ 1435.592788] ark3116 ttyUSB2: ark3116 converter now disconnected from ttyUSB2 Sep 16 20:29:38 elf kernel: [ 1435.592888] ark3116 2-1:1.0: device disconnected Sep 16 20:29:44 elf kernel: [ 1441.260149] usb 2-1: new full speed USB device number 3 using uhci_hcd Sep 16 20:29:44 elf kernel: [ 1441.420141] usb 2-1: New USB device found, idVendor=6547, idProduct=0232 Sep 16 20:29:44 elf kernel: [ 1441.420163] usb 2-1: New USB device strings: Mfr=1, Product=3, SerialNumber=0 Sep 16 20:29:44 elf kernel: [ 1441.420177] usb 2-1: Product: USB-UART Controller Sep 16 20:29:44 elf kernel: [ 1441.420188] usb 2-1: Manufacturer: ArkMicroChips Sep 16 20:29:44 elf kernel: [ 1441.422581] ark3116 2-1:1.0: ark3116 converter detected Sep 16 20:29:44 elf mtp-probe: checking bus 2, device 3: /sys/devices/pci:00/:00:1d.0/usb2/2-1 Sep 16 20:29:44 elf kernel: [ 1441.437135] usb 2-1: ark3116 using RS232 mode Sep 16 20:29:44 elf kernel: [ 1441.437541] usb 2-1: ark3116 converter now attached to ttyUSB2 Sep 16 20:29:44 elf mtp-probe: bus: 2, device: 3 was not an MTP device
Bug#640391: linux-image-3.0.0-1-686-pae: ark3116 driver regression
On Tue, Sep 13, 2011 at 08:56:54PM +0200, Bart Hartgers wrote:
[Previous messages are logged at http://bugs.debian.org/640391.
Thanks for the strace. It seems that gpsbabel is treating the device
as a tty and not just a plain file. My main suspect is still a problem
with the cts/rts handshaking. Unfortunately, I cannot tell what
exactly gpsbabel does to the handshake signals because strace
truncated the termios data. Could you please rerun the strace with the
'-v' option?
Ok. Attached.
One proviso. The peculiar garmin serial connector on this gps unit
sometimes doesn't make good contact. I am pretty sure that it was ok
for this run, but it is just possible that the connector was playing
up. (Known problem on this model, I fear.)
ael
fstat64(3, {st_dev=makedev(0, 3), st_ino=4026532018, st_mode=S_IFREG|0444,
st_nlink=1, st_uid=0, st_gid=0, st_blksize=1024, st_blocks=0, st_size=0,
st_atime=2011/09/13-21:29:17, st_mtime=2011/09/13-21:29:17,
st_ctime=2011/09/13-21:29:17}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0xb778c000
read(3, MemTotal:1540708 kB\nMemF..., 1024) = 1024
close(3)= 0
munmap(0xb778c000, 4096)= 0
open(/dev/ttyUSB0, O_RDWR)= 3
ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, {c_iflags=0x500, c_oflags=0x5,
c_cflags=0xcbd, c_lflags=0x8a3b, c_line=0,
c_cc=\x03\x1c\x7f\x15\x04\x00\x01\x00\x11\x13\x1a\x00\x12\x0f\x17\x16\x00\x00\x00})
= 0
ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, {c_iflags=0x500, c_oflags=0x5,
c_cflags=0xcbd, c_lflags=0x8a3b, c_line=0,
c_cc=\x03\x1c\x7f\x15\x04\x00\x01\x00\x11\x13\x1a\x00\x12\x0f\x17\x16\x00\x00\x00})
= 0
ioctl(3, SNDCTL_TMR_CONTINUE or TCSETSF, {c_iflags=0, c_oflags=0,
c_cflags=0xcbd, c_lflags=0, c_line=0, c_cc[VMIN]=1, c_cc[VTIME]=0,
c_cc=\x03\x1c\x7f\x15\x04\x00\x01\x00\x11\x13\x1a\x00\x12\x0f\x17\x16\x00\x00\x00})
= 0
ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, {c_iflags=0, c_oflags=0,
c_cflags=0xcbd, c_lflags=0, c_line=0, c_cc[VMIN]=1, c_cc[VTIME]=0,
c_cc=\x03\x1c\x7f\x15\x04\x00\x01\x00\x11\x13\x1a\x00\x12\x0f\x17\x16\x00\x00\x00})
= 0
ioctl(3, TCFLSH, 0x2) = 0
write(3, \20\376\0, 3)= 3
write(3, , 0) = 0
write(3, \2\20\3, 3) = 3
time(NULL) = 1315945757
time(NULL) = 1315945757
Bug#640391: linux-image-3.0.0-1-686-pae: ark3116 driver regression
Also the output of 'stty -a /dev/ttyUSB0' might give a clue. $ stty -a /dev/ttyUSB2 speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = undef; eol2 = undef; swtch = undef; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0; -parenb -parodd cs8 hupcl -cstopb cread clocal -crtscts -ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon -ixoff -iuclc -ixany -imaxbel -iutf8 opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt echoctl echoke ael -- 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/20110913204443.GB3051@elf.conquest
Bug#640391: linux-image-3.0.0-1-686-pae: ark3116 driver regression
On Thu, Sep 08, 2011 at 06:33:29PM +0200, Bart Hartgers wrote: Hi Ben, ael, I am reading this on my phone and will not be able to look into this properly (ie access a computer) before next week. In the mean time: strace logs would be very useful. And maybe the problen has to do with the new driver doing real handshaking while the old one effectively ignored hs signals iirc. That sounds very likely from what I can see. I don't think that gpsbabel is doing anything beyond opening the file trying to read it. /dev/ttyUSB* is just treated as any other file, I suspect. In passing, the serial port on the garmin satnav has a 4 wire connection. So any hardwired handshaking must be minimal. The garmin cable just takes those to the usual 9-pin RS232 serial plug - to which the USB converter connects. I might try statserial and strace that as well if I have time. Actually I seem to remember that statserial would only read serial files, and could not connect to /dev/ttyUSB*, so that probably won't work. As earlier in the report, I am away from home, using a small netbook with limited connectivity, so compiling and testing with a stock kernal isn't very practical for the moment. Thanks for all the help so far to both of you, ael -- 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/20110909083306.GA3336@elf.conquest
Bug#640391: linux-image-3.0.0-1-686-pae: ark3116 driver regression
On Tue, Sep 06, 2011 at 04:16:11AM +0100, Ben Hutchings wrote: Regression in the ark3116 (perhaps interaction with usbserial). available from http://snapshot.debian.org/package/linux-2.6/) to Probably the most useful one to test would be: http://snapshot.debian.org/package/linux-2.6/2.6.34-1~experimental.2/ I just checked in snapshot.debian.org/package/linux-2.6/ and I can't see any kernel to test between 2.6.32-5 (working) and 2.6.34-1 (failing). Is there any point in alerting upstream, presumably Bart Hartgers bart.hartgers+ark3...@gmail.com, to this bug report, or is he already aware? I doubt that it is a debian specific bug... ael -- 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/20110908130822.GA2820@elf.conquest
Bug#640391: linux-image-3.0.0-1-686-pae: ark3116 driver regression
On Tue, Sep 06, 2011 at 04:16:11AM +0100, Ben Hutchings wrote: On Mon, 2011-09-05 at 19:46 +0100, ael wrote: On Mon, Sep 05, 2011 at 12:11:26PM +0100, Ben Hutchings wrote: Package: linux-2.6 Version: 3.0.0-3 Severity: normal Tags: upstream Regression in the ark3116 (perhaps interaction with usbserial). I can maybe try perhaps one more kernel with my current limited connectivity if it would help. But at least I can recover my gps data for now. Probably the most useful one to test would be: http://snapshot.debian.org/package/linux-2.6/2.6.34-1~experimental.2/ Just downloaded and tried linux-image-2.6.34-1-686_2.6.34-1~experimental.2_i386.deb # uname -a Linux elf 2.6.34-1-686 #1 SMP Sun Jun 6 22:56:48 UTC 2010 i686 GNU/Linux It failed: $gpsbabel -t -i garmin -f /dev/ttyUSB0 -o gps -F 040911.gpx [ERROR] GPS_Packet_Read: Timeout. No data received. GARMIN:Can't init /dev/ttyUSB0 In /var/log/messages: Sep 7 11:03:40 elf kernel: [ 120.632142] usb 2-1: new full speed USB device using uhci_hcd and address 2 Sep 7 11:03:41 elf mtp-probe: checking bus 2, device 2: /sys/devices/pci:00/:00:1d.0/usb2/2-1 Sep 7 11:03:41 elf kernel: [ 120.792194] usb 2-1: New USB device found, idVendor=6547, idProduct=0232 Sep 7 11:03:41 elf kernel: [ 120.792212] usb 2-1: New USB device strings: Mfr=1, Product=3, SerialNumber=0 Sep 7 11:03:41 elf kernel: [ 120.792225] usb 2-1: Product: USB-UART Controller Sep 7 11:03:41 elf kernel: [ 120.792234] usb 2-1: Manufacturer: ArkMicroChips Sep 7 11:03:41 elf mtp-probe: bus: 2, device: 2 was not an MTP device Sep 7 11:03:41 elf kernel: [ 120.992791] usbcore: registered new interface driver usbserial Sep 7 11:03:41 elf kernel: [ 120.992860] USB Serial support registered for generic Sep 7 11:03:41 elf kernel: [ 120.993565] usbcore: registered new interface driver usbserial_generic Sep 7 11:03:41 elf kernel: [ 120.993576] usbserial: USB Serial Driver core Sep 7 11:03:41 elf kernel: [ 120.999642] USB Serial support registered for ark3116 Sep 7 11:03:41 elf kernel: [ 120.999692] ark3116 2-1:1.0: ark3116 converter detected Sep 7 11:03:41 elf kernel: [ 121.010175] usb 2-1: ark3116 using RS232 mode Sep 7 11:03:41 elf kernel: [ 121.010658] usb 2-1: ark3116 converter now attached to ttyUSB0 Sep 7 11:03:41 elf kernel: [ 121.010900] usbcore: registered new interface driver ark3116 Sep 7 11:03:41 elf kernel: [ 121.010912] ark3116:v0.5:USB ARK3116 serial/IrDA driver Sep 7 11:03:41 elf kernel: [ 121.080195] usb 2-1: ark3116: don't know how to do software flow control Sep 7 11:03:41 elf kernel: [ 121.092180] usb 2-1: ark3116: don't know how to do software flow control Sep 7 11:03:41 elf kernel: [ 121.099170] usb 2-1: ark3116: don't know how to do software flow control Sep 7 11:03:41 elf kernel: [ 121.206183] usb 2-1: ark3116: don't know how to do software flow control = So just the same don't know how to do software flow control messages as in the most recent kernel. So I guess that helps nail the regression a bit more accurately. I can probably test another kernel in a day or two to help narrow the regression interval. Thanks again for all the help. ael -- 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/20110907101402.GA2589@elf.conquest
Bug#640391: linux-image-3.0.0-1-686-pae: ark3116 driver regression
On Sun, Sep 04, 2011 at 09:07:17PM +0100, Ben Hutchings wrote: On Sun, 2011-09-04 at 19:42 +0100, ael wrote: Package: linux-2.6 Version: 3.0.0-3 Severity: normal Tags: upstream Regression in the ark3116 (perhaps interaction with usbserial). The hardware is a USB -serial port converter. It was last used on this machine running debian testing in December 2011. It ran successfully with the debian kernel at that time. Please can you test with an older kernel package (they are still available from http://snapshot.debian.org/package/linux-2.6/) to verify that this is definitely a difference between kernel versions. I was going to try that but I am away from home with limited connectivity. Just hope that I don't hit dependency hell... Any easy way to discover which binary was current back in December? The lack of a release date in debs I find awkward. Now the application reports: [ERROR] GPS_Packet_Read: Timeout. No data received. GARMIN:Can't init /dev/ttyUSB2 (It is attempting to establish a connection to a garmin gps unit with serial interface.) [...] What is this application? gpsbabel. I use it all the time, but usually on desktops with real RS232 ports. I only need this USB -- RS232 converter when away from home which is why I have only just discovered the problem. -- Package: gpsbabel Status: install ok installed Priority: optional Section: utils Installed-Size: 1304 Maintainer: Bernd Zeimetz b...@debian.org Architecture: i386 Version: 1.4.2-3 --- Thanks for the quick response. I haven't yet looked on KML for anything relevant. I don't fancy compiling a stock kernel on this atom netbook.. ael -- 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/20110905091545.GB3214@elf.conquest
Bug#640391: linux-image-3.0.0-1-686-pae: ark3116 driver regression
On Sun, Sep 04, 2011 at 09:07:17PM +0100, Ben Hutchings wrote: On Sun, 2011-09-04 at 19:42 +0100, ael wrote: Package: linux-2.6 Version: 3.0.0-3 Severity: normal Tags: upstream Regression in the ark3116 (perhaps interaction with usbserial). The hardware is a USB -serial port converter. It was last used on this machine running debian testing in December 2011. It ran successfully with the debian kernel at that time. Please can you test with an older kernel package (they are still available from http://snapshot.debian.org/package/linux-2.6/) to verify that this is definitely a difference between kernel versions. I have just downloaded and attempted to install linux-image-2.6.26-2-686_2.6.26-26lenny1_i386.deb I selected that on the basis of the timestamp in the snapshot pool. As anticipated, dependency hell started: dpkg -i linux-image-2.6.26-2-686_2.6.26-26lenny1_i386.deb Selecting previously deselected package linux-image-2.6.26-2-686. (Reading database ... 181698 files and directories currently installed.) Unpacking linux-image-2.6.26-2-686 (from linux-image-2.6.26-2-686_2.6.26-26lenny1_i386.deb) ... Could not find mkinitramfs-kpkg mkinitrd.yaird. at /var/lib/dpkg/tmp.ci/preinst line 234, STDIN line 9. Done. Setting up linux-image-2.6.26-2-686 (2.6.26-26lenny1) ... Running depmod. Failed to find suitable ramdisk generation tool for kernel version 2.6.26-2-686 on running kernel 3.0.0-1-686-pae in mkinitramfs-kpkg mkinitrd.yaird dpkg: error processing linux-image-2.6.26-2-686 (--install): subprocess installed post-installation script returned error exit status 127 Errors were encountered while processing: linux-image-2.6.26-2-686 I guess that I could use some of the -force switches, and I should be able to get grub2 to load the kernel, but I am not sure about the rest without of lot of time and effort. Any suggestions for a better way, or a better kernal test? I am not sure that a sort of manual git-bisect on the debian kernels is feasible given my limited time and bandwidth away from home. ael -- 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/20110905093537.GC3214@elf.conquest
Bug#640391: linux-image-3.0.0-1-686-pae: ark3116 driver regression
On Mon, Sep 05, 2011 at 12:11:26PM +0100, Ben Hutchings wrote:
Package: linux-2.6
Version: 3.0.0-3
Severity: normal
Tags: upstream
Regression in the ark3116 (perhaps interaction with usbserial).
Please can you test with an older kernel package (they are still
available from http://snapshot.debian.org/package/linux-2.6/) to
verify that this is definitely a difference between kernel versions.
In December, testing/unstable saw versions 2.6.32-{28,29,30} and
experimental saw 2.6.36-1~experimental.1 followed by various 2.6.37
release candidates. Maybe you should just test the current version from
squeeze.
Just installed 2.6.32-5-686 from squeeze:
linux-image-2.6.32-5-686_2.6.32-35_i386.deb
$ gpsbabel -t -i garmin -f /dev/ttyUSB2 -o gpx -F 040911.gpx
worked ok.
So the regression is quite recent. I can maybe try perhaps one more
kernel with my current limited connectivity if it would help.
But at least I can recover my gps data for now.
ael
--
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/20110905184659.GA3500@elf.conquest
Bug#640391: linux-image-3.0.0-1-686-pae: ark3116 driver regression
Package: linux-2.6 Version: 3.0.0-3 Severity: normal Tags: upstream Regression in the ark3116 (perhaps interaction with usbserial). The hardware is a USB -serial port converter. It was last used on this machine running debian testing in December 2011. It ran successfully with the debian kernel at that time. Now the application reports: [ERROR] GPS_Packet_Read: Timeout. No data received. GARMIN:Can't init /dev/ttyUSB2 (It is attempting to establish a connection to a garmin gps unit with serial interface.) = /var/log/messages includes: Sep 4 19:04:19 elf kernel: [ 3502.996139] usb 2-1: new full speed USB device nu mber 3 using uhci_hcd Sep 4 19:04:19 elf kernel: [ 3503.156165] usb 2-1: New USB device found, idVend or=6547, idProduct=0232 Sep 4 19:04:19d elf kernel: [ 3503.156188] usb 2-1: New USB device strings: Mfr= 1, Product=3, SerialNumber=0 Sep 4 19:04:19 elf kernel: [ 3503.156202] usb 2-1: Product: USB-UART Controller Sep 4 19:04:19 elf kernel: [ 3503.156213] usb 2-1: Manufacturer: ArkMicroChips Sep 4 19:04:19 elf kernel: [ 3503.158626] ark3116 2-1:1.0: ark3116 converter de tected Sep 4 19:04:19 elf mtp-probe: checking bus 2, device 3: /sys/devices/pci:0 0/:00:1d.0/usb2/2-1 Sep 4 19:04:19 elf kernel: [ 3503.173159] usb 2-1: ark3116 using RS232 mode Sep 4 19:04:19 elf kernel: [ 3503.173696] usb 2-1: ark3116 converter now attach ed to ttyUSB2 Sep 4 19:04:19 elf mtp-probe: bus: 2, device: 3 was not an MTP device Sep 4 19:04:35 elf kernel: [ 3519.616743] usb 2-1: ark3116: don't know how to d o software flow control Sep 4 19:05:00 elf kernel: [ 3544.195822] usb 2-1: ark3116: don't know how to d o software flow control Sep 4 19:05:25 elf kernel: [ 3569.458610] usb 2-1: ark3116: don't know how to d o software flow control Sep 4 19:06:23 elf kernel: [ 3627.785287] usb 2-1: ark3116: don't know how to d o software flow control Sep 4 19:07:32 elf kernel: [ 3696.180832] usb 2-1: ark3116: don't know how to d o software flow control === Googling reveals many similar reports, but those all seem to be old, dating from before the time when it worked in Debian. Sorry for the lack of further detail, but it certainly looks like a regression... I am sending this report using a USB dongle attached to ports /dev/ttyUSB0 /dev/ttyUSB1 -- so those entries in the logs can be ignored. Removing the dongle does not resolve the problem, which is not surprising given the error message. -- Package-specific info: ** Version: Linux version 3.0.0-1-686-pae (Debian 3.0.0-3) (b...@decadent.org.uk) (gcc version 4.5.3 (Debian 4.5.3-8) ) #1 SMP Sat Aug 27 16:41:03 UTC 2011 ** Command line: BOOT_IMAGE=/boot/vmlinuz-3.0.0-1-686-pae root=UUID=b0e0725b-0ebb-4a27-964d-75eb6e73e069 ro elevator=noop enable_mtrr_cleanup ** Not tainted ** Kernel log: [ 230.558740] usb 1-2: GSM modem (1-port) converter now attached to ttyUSB0 [ 230.558794] option 1-2:1.1: GSM modem (1-port) converter detected [ 230.559052] usb 1-2: GSM modem (1-port) converter now attached to ttyUSB1 [ 230.559167] usbcore: registered new interface driver option [ 230.559175] option: v0.7.2:USB Driver for GSM modems [ 231.279679] scsi 5:0:0:0: CD-ROMHUAWEI Mass Storage 2.31 PQ: 0 ANSI: 2 [ 231.285588] scsi 5:0:0:0: Attached scsi generic sg1 type 5 [ 231.293062] scsi 6:0:0:0: Direct-Access HUAWEI MMC Storage 2.31 PQ: 0 ANSI: 2 [ 231.302950] sd 6:0:0:0: Attached scsi generic sg2 type 0 [ 231.311795] sd 6:0:0:0: [sdb] Attached SCSI removable disk [ 231.334562] sr0: scsi-1 drive [ 231.334575] cdrom: Uniform CD-ROM driver Revision: 3.20 [ 231.335009] sr 5:0:0:0: Attached scsi CD-ROM sr0 [ 275.627233] ip_tables: (C) 2000-2006 Netfilter Core Team [ 276.489237] Netfilter messages via NETLINK v0.30. [ 276.512980] nf_conntrack version 0.5.0 (16384 buckets, 65536 max) [ 276.715507] ip6_tables: (C) 2000-2006 Netfilter Core Team [ 276.717318] NF_TPROXY: Transparent proxy support initialized, version 4.1.0 [ 276.717330] NF_TPROXY: Copyright (c) 2006-2007 BalaBit IT Ltd. [ 276.765464] ctnetlink v0.93: registering with nfnetlink. [ 276.928900] ip_set: protocol 6 [ 276.951233] ipt_CLUSTERIP: ClusterIP Version 0.8 loaded successfully [ 277.633633] xt_time: kernel timezone is - [ 278.325279] u32 classifier [ 278.325290] Performance counters on [ 278.325295] input device check on [ 278.325300] Actions configured [ 278.714795] PPP generic driver version 2.4.2 [ 3085.372149] usb 2-1: new full speed USB device number 2 using uhci_hcd [ 3085.532173] usb 2-1: New USB device found, idVendor=6547, idProduct=0232 [ 3085.532194] usb 2-1: New USB device strings: Mfr=1, Product=3, SerialNumber=0 [ 3085.532209] usb 2-1: Product: USB-UART Controller [ 3085.532219] usb 2-1:
Bug#627933: Regression: hot plugging sdhc card on Acer Aspire One
On Wed, May 25, 2011 at 05:00:35PM +, maximilian attems wrote: On Wed, May 25, 2011 at 05:49:03PM +0100, ael wrote: Package: linux-2.6 Version: 2.6.38-5 Severity: normal The Acer Aspire One netbook has two card readers, left right. Until recently (sorry not sure when regression happened) hotplugging the right hand card worked. But now such a card is only seen on cold boot. please try against 2.6.39 in unstable, outdated linux image report against. Just tried it. No change. # uname -a Linux elf 2.6.39-1-686-pae #1 SMP Fri May 20 20:40:05 UTC 2011 i686 GNU/Linux Do you need me to collect all the dumps for 2.6.39-1-686.. ? # modinfo pciehp filename: /lib/modules/2.6.39-1-686-pae/kernel/drivers/pci/hotplug/pciehp.ko license:GPL description:PCI Express Hot Plug Controller Driver author: Dan Zink dan.z...@compaq.com, Greg Kroah-Hartman g...@kroah.com, Dely Sy dely.l...@intel.com depends:pci_hotplug intree: Y vermagic: 2.6.39-1-686-pae SMP mod_unload modversions 686 parm: pciehp_detect_mode:Slot detection mode: pcie, acpi, auto pcie - Use PCIe based slot detection acpi - Use ACPI for slot detection auto(default) - Auto select mode. Use acpi option if duplicate slot ids are found. Otherwise, use pcie option (charp) parm: pciehp_debug:Debugging mode enabled or not (bool) parm: pciehp_poll_mode:Using polling mechanism for hot-plug events or not (bool) parm: pciehp_poll_time:Polling mechanism frequency, in seconds (int) parm: pciehp_force:Force pciehp, even if OSHP is missing (bool) Maybe I need to play around with the pciehp_detect-mode parameter? ael -- 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/20110526085205.GA2346@elf.conquest
Bug#627933: Regression: hot plugging sdhc card on Acer Aspire One
Package: linux-2.6 Version: 2.6.38-5 Severity: normal The Acer Aspire One netbook has two card readers, left right. Until recently (sorry not sure when regression happened) hotplugging the right hand card worked. But now such a card is only seen on cold boot. I am reporting on a system which has just booted with the card present, and all is well: $ ls -l /dev/disk/by-label/ total 0 lrwxrwxrwx 1 root root 15 May 25 16:22 ael_elf1 - ../../mmcblk0p1 lrwxrwxrwx 1 root root 15 May 25 16:22 ael_elf2 - ../../mmcblk1p1 lrwxrwxrwx 1 root root 10 May 25 16:22 Elf_ST_ssd - ../../sda1 The rh card above is ael_elf1 and /dev/mmcblkop1. Relevant extracts from /var/log/messages seem to be:- == May 25 16:22:32 elf kernel: [2.913360] sdhci: Secure Digital Host Controller Interface driver May 25 16:22:32 elf kernel: [2.913464] sdhci: Copyright(c) Pierre Ossman May 25 16:22:32 elf kernel: [2.934644] sdhci-pci :01:00.0: SDHCI control ler found [197b:2382] (rev 0) May 25 16:22:32 elf kernel: [2.934800] sdhci-pci :01:00.0: enabling devi ce ( - 0002) May 25 16:22:32 elf kernel: [2.934918] sdhci-pci :01:00.0: PCI INT A - GSI 16 (level, low) - IRQ 16 May 25 16:22:32 elf kernel: [2.935266] mmc0: no vmmc regulator found May 25 16:22:32 elf kernel: [2.936396] mmc0: SDHCI controller on PCI [:01:00.0] using ADMA May 25 16:22:32 elf kernel: [2.936545] sdhci-pci :01:00.2: SDHCI controller found [197b:2381] (rev 0) May 25 16:22:32 elf kernel: [2.936689] sdhci-pci :01:00.2: enabling device ( - 0002) May 25 16:22:32 elf kernel: [2.936805] sdhci-pci :01:00.2: PCI INT A - GSI 16 (level, low) - IRQ 16 May 25 16:22:32 elf kernel: [2.936939] sdhci-pci :01:00.2: Refusing to bind to secondary interface. May 25 16:22:32 elf kernel: [2.937048] sdhci-pci :01:00.2: PCI INT A disabled May 25 16:22:32 elf kernel: [2.937188] sdhci-pci :04:00.0: SDHCI controller found [197b:2382] (rev 0) May 25 16:22:32 elf kernel: [2.937336] sdhci-pci :04:00.0: PCI INT A - GSI 19 (level, low) - IRQ 19 May 25 16:22:32 elf kernel: [2.937624] mmc1: no vmmc regulator found May 25 16:22:32 elf kernel: [2.938505] mmc1: SDHCI controller on PCI [:04:00.0] using ADMA May 25 16:22:32 elf kernel: [2.938644] sdhci-pci :04:00.2: SDHCI controller found [197b:2381] (rev 0) May 25 16:22:32 elf kernel: [2.938797] sdhci-pci :04:00.2: PCI INT A - GSI 19 (level, low) - IRQ 19 May 25 16:22:32 elf kernel: [2.938937] sdhci-pci :04:00.2: Refusing to bind to secondary interface. May 25 16:22:32 elf kernel: [2.939046] sdhci-pci :04:00.2: PCI INT A disabled -- May 25 16:22:32 elf kernel: [4.289286] mmc0: new SDHC card at address 0007 === The target card ***RH slot* May 25 16:22:32 elf kernel: [4.317047] mmcblk0: mmc0:0007 SD16G 15.0 GiB May 25 16:22:32 elf kernel: [4.321947] mmcblk0: p1 May 25 16:22:32 elf kernel: [4.531611] EXT4-fs (sda1): mounted filesystem with ordered data mode. Opts: (null) May 25 16:22:32 elf kernel: [4.883331] mmc1: new SDHC card at address 0003 left hand slot May 25 16:22:32 elf kernel: [4.883989] mmcblk1: mmc1:0003 SD32G 30.0 GiB May 25 16:22:32 elf kernel: [4.885868] mmcblk1: p1 May 25 16:22:32 elf kernel: [5.228510] 30udev[315]: starting version 167 -- May 25 16:22:32 elf kernel: [9.838195] pci_hotplug: PCI Hot Plug PCI Core ve rsion: 0.5 May 25 16:22:32 elf kernel: [9.862304] pciehp: PCI Express Hot Plug Controll er Driver version: 0.4 May 25 16:22:32 elf kernel: [ 10.526330] EXT4-fs (mmcblk1p1): mounted filesystem without journal. Opts: (null) -- May 25 16:28:01 elf kernel: [ 343.594266] EXT4-fs (mmcblk1p1): re-mounted. Opts: commit=0 [ Comment: notice that LH card looks like a hotplug remount, but nothing similar for the target RH card. Consistent with problem hotplug? ] = In /etc/modprobe.d/aspire-rhs-sd_slot.conf :- #options pciehp pciehp_force=1 pciehp_detect_mode=pcie # options pciehp pciehp_force=1 pciehp_detect_mode=pcie pciehp_debug=1 --- The card readers are JMicron SD/MMC controllers. See also http://wiki.debian.org/DebianAcerOne, and http://wiki.archlinux.org/index.php/Acer_Aspire_One. --- Now to the problem. If in contrast the system is booted without a card installed into the right hand slot, then when a card is subsequently inserted, nothing happens. No uevent as reported by udevadm monitor, no /dev/disk/ entries, nothing in /var/log/messages. lsmod for the cold boot case is included by reportbug towards the end of this report. Here is lsmod for the problem hotplug case: Module
Bug#568288: mount.nfs: mount(2): Invalid argument
On Sun, Mar 20, 2011 at 11:32:32PM +0100, Luk Claes wrote: As noted above, I only had version 4 configured in one of them: might that have upset the negotiation/default somehow? It might if the export was not configured to be for NFSv4 (with an fsid=0 entry etc). Another possibility is a bug in an older version of the Debian package or using an older kernel at the other end AFAICS. Can you still reproduce this issue or are you fine with me closing this bug? I will have to find time to experiment. I still think the error message could be improved, although I guess if mount is talking to a kernel which is not configured for the right version, it is a tall order for it to diagnose that that is the problem. ael -- 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/2011032844.GA2341@elf.conquest
Bug#568288: mount.nfs: mount(2): Invalid argument
On Sun, Mar 20, 2011 at 07:40:47PM +0100, Luk Claes wrote: Hi Mounting an nfs file system suddenly stopped working with errors like this: -- # mount.nfs exact:/ /mnt/exact -v mount.nfs: timeout set for Wed Feb 3 16:09:00 2010 mount.nfs: trying text-based options 'addr=192.168.0.5,vers=4,clientaddr=192.168.0.3' mount.nfs: mount(2): Invalid argument mount.nfs: an incorrect mount option was specified -- Both systems (that on which the mount was issued and the server) were running testing. They were, however using custom kernels, but these had worked without problems until today. Only the server was set up for nfs version 4 which seems to be the heart of the problem from the message about the text based options above - see below as well. I guess it's an old kernel? Actually, no. I either run the current Debian kernel, or the latest from stable-git, compiled locally, of course. The problem was resolved by adding either -o nfsvers=2 or -o nfsvers-3 to the mount command. Thus there seems to be some sort of problem negotiating the nfs version between the client server? And a totally misleading error message? The default changed to version 4, but that does not work with old kernels, so I guess that's the problem? I don't think it can be: I was running kernel.org kernels, later then Debian testing. I can't remember what version I was at when I reported the bug: I confess that I had forgotten about the report. Maybe I had something wrong in the kernel configs, but I doubt it. As noted above, I only had version 4 configured in one of them: might that have upset the negotiation/default somehow? ael -- 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/20110320221117.GA3806@precise.conquest
Bug#576918: linux-image-2.6-686: Keyboard disabled: atkbd.c: Spurious ACK on isa0060/serio0 ...
On Sat, Apr 10, 2010 at 11:15:22PM +0100, Ben Hutchings wrote: Please report this upstream at https://bugzilla.kernel.org under product 'Drivers', component 'Input Devices'. Let us know the bug number so we can track it. OK. Will do. I am short of time just now. As I no longer have a clear correlation with the spurious interrupt message, I doubt that I have enough information to make a useful bug report. And I should probably try with the latest git kernel before reporting. So it may take a while ael -- 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/20100411094232.ga2...@elf.conquest
Bug#576918: linux-image-2.6-686: Keyboard disabled: atkbd.c: Spurious ACK on isa0060/serio0 ...
: 2570 0 PCI-MSI-edge eth0 NMI: 0 0 Non-maskable interrupts LOC: 30559 165279 Local timer interrupts SPU: 0 0 Spurious interrupts PMI: 0 0 Performance monitoring interrupts PND: 0 0 Performance pending work RES: 15169 29541 Rescheduling interrupts CAL: 13 57 Function call interrupts TLB:155213 TLB shootdowns TRM: 0 0 Thermal event interrupts THR: 0 0 Threshold APIC interrupts MCE: 0 0 Machine check exceptions MCP: 10 10 Machine check polls ERR: 1 MIS: 0 ael -- - System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.32-trunk-686 (SMP w/2 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages linux-image-2.6-686 depends on: ii linux-image-2.6.32-3-686 2.6.32-9 Linux 2.6.32 for modern PCs linux-image-2.6-686 recommends no packages. linux-image-2.6-686 suggests no packages. -- no debconf information -- 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/20100408081651.2587.10104.report...@elf.conquest
Bug#576918: Spurious ACK does not seem to be the real problem
I have just observed a correct boot (keyboard working), but with the atkbd.c Spurious ACK ... present in /var/log/messages. So this is much less clear than I thought. I have a good and bad versions log /var/log/messages am now wondering on how to best compare them. I need to look into a diff or a script that can ignore date and time differences, for a start. -- 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/20100408102524.ga2...@elf.conquest
Bug#573962: linux-image-2.6.32-3: Package fails to install: Failed to process /etc/kernel/postrm.d...
Package: linux-2.6 Version: 2.6.32-9 Severity: important File: linux-image-2.6.32-3 # dpkg -i /var/cache/apt/archives/linux-image-2.6.32-3-amd64_2.6.32-9_amd64.deb (Reading database ... 231498 files and directories currently installed.) Preparing to replace linux-image-2.6.32-3-amd64 2.6.32-9 (using .../linux-image-2.6.32-3-amd64_2.6.32-9_amd64.deb) ... Unpacking replacement linux-image-2.6.32-3-amd64 ... Running postrm hook script /usr/sbin/update-grub. Generating grub.cfg ... Found linux image: /boot/vmlinuz-2.6.32-trunk-amd64 Found initrd image: /boot/initrd.img-2.6.32-trunk-amd64 Found linux image: /boot/vmlinuz-2.6.32-3-amd64 Found initrd image: /boot/initrd.img-2.6.32-3-amd64 Found linux image: /boot/vmlinuz-2.6.30-2-amd64 Found initrd image: /boot/initrd.img-2.6.30-2-amd64 Found linux image: /boot/vmlinuz-2.6.26-2-amd64 Found initrd image: /boot/initrd.img-2.6.26-2-amd64 done Examining /etc/kernel/postrm.d . run-parts: executing /etc/kernel/postrm.d/extlinux 2.6.32-3-amd64 /boot/vmlinuz-2.6.32-3-amd64 run-parts: /etc/kernel/postrm.d/extlinux exited with return code 1 Failed to process /etc/kernel/postrm.d at /var/lib/dpkg/info/linux-image-2.6.32-3-amd64.postrm line 272. dpkg: warning: old post-removal script returned error exit status 2 dpkg - trying script from the new package instead ... Running postrm hook script /usr/sbin/update-grub. Generating grub.cfg ... Found linux image: /boot/vmlinuz-2.6.32-trunk-amd64 Found initrd image: /boot/initrd.img-2.6.32-trunk-amd64 Found linux image: /boot/vmlinuz-2.6.32-3-amd64 Found initrd image: /boot/initrd.img-2.6.32-3-amd64 Found linux image: /boot/vmlinuz-2.6.30-2-amd64 Found initrd image: /boot/initrd.img-2.6.30-2-amd64 Found linux image: /boot/vmlinuz-2.6.26-2-amd64 Found initrd image: /boot/initrd.img-2.6.26-2-amd64 done Examining /etc/kernel/postrm.d . run-parts: executing /etc/kernel/postrm.d/extlinux 2.6.32-3-amd64 /boot/vmlinuz-2.6.32-3-amd64 run-parts: /etc/kernel/postrm.d/extlinux exited with return code 1 Failed to process /etc/kernel/postrm.d at /var/lib/dpkg/tmp.ci/postrm line 272. dpkg: error processing /var/cache/apt/archives/linux-image-2.6.32-3-amd64_2.6.32-9_amd64.deb (--install): subprocess new post-removal script returned error exit status 2 Running postrm hook script /usr/sbin/update-grub. Generating grub.cfg ... Found linux image: /boot/vmlinuz-2.6.32-trunk-amd64 Found initrd image: /boot/initrd.img-2.6.32-trunk-amd64 Found linux image: /boot/vmlinuz-2.6.32-3-amd64 Found initrd image: /boot/initrd.img-2.6.32-3-amd64 Found linux image: /boot/vmlinuz-2.6.30-2-amd64 Found initrd image: /boot/initrd.img-2.6.30-2-amd64 Found linux image: /boot/vmlinuz-2.6.26-2-amd64 Found initrd image: /boot/initrd.img-2.6.26-2-amd64 done Examining /etc/kernel/postrm.d . run-parts: executing /etc/kernel/postrm.d/extlinux 2.6.32-3-amd64 /boot/vmlinuz-2.6.32-3-amd64 run-parts: /etc/kernel/postrm.d/extlinux exited with return code 1 Failed to process /etc/kernel/postrm.d at /var/lib/dpkg/tmp.ci/postrm line 272. dpkg: error while cleaning up: subprocess new post-removal script returned error exit status 2 Errors were encountered while processing: /var/cache/apt/archives/linux-image-2.6.32-3-amd64_2.6.32-9_amd64.deb So far I have not investigated further: it may be something trivial. It happened on the preceeding version. No trouble on another amd64 system here. I use dpkg -i on this report to avoid the extra complications under apt-get aptitude, etc. -- Package-specific info: ** Kernel log: boot messages should be attached ** Model information sys_vendor: To Be Filled By O.E.M. product_name: To Be Filled By O.E.M. product_version: To Be Filled By O.E.M. chassis_vendor: Chassis Manufacture chassis_version: Chassis Version bios_vendor: American Megatrends Inc. bios_version: 1012.004 board_vendor: ASUSTeK Computer Inc. board_name: K8V-X board_version: Rev 2.00 ** PCI devices: 00:00.0 Host bridge [0600]: VIA Technologies, Inc. VT8385 [K8T800 AGP] Host Bridge [1106:3188] (rev 01) Subsystem: ASUSTeK Computer Inc. K8V Deluxe/K8V-X motherboard [1043:80a3] 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: 64 Region 0: Memory at ignored (32-bit, prefetchable) Capabilities: access denied Kernel driver in use: agpgart-amd64 00:01.0 PCI bridge [0604]: VIA Technologies, Inc. VT8237 PCI bridge [K8T800/K8T890 South] [1106:b188] (prog-if 00 [Normal decode]) 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 Bus: primary=00, secondary=01, subordinate=01,
Bug#573962: closed by Bastian Blank wa...@debian.org (Re: Bug#573962: linux-image-2.6.32-3: Package fails to install: Failed to process /etc/kernel/postrm.d...)
On Mon, Mar 15, 2010 at 11:45:09AM +, Debian Bug Tracking System wrote: It has been closed by Bastian Blank wa...@debian.org. /etc/kernel/postrm.d/extlinux is not part of the kernel package. So no bug in the kernel to not ignore failures in other parts. Ok. I have reported it against extlinux. Even after purging that package /etc/kernel/postrm.d/extlinux remained! I had to manually delete it. I was not actually using extlinux to boot the host system. ael -- 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/20100315130031.ga10...@precise.conquest
Bug#565511: ext4.ko module missing from initramfs
Martin Michlmayr wrote: * Frans Pop elen...@planet.nl [2010-01-17 01:13]: I cannot reproduce the problem though. If I install a system with an ext4 root file system and MODULES=dep for initramfs-tools, the ext4 module gets correctly included in the initrd and the installed system boots fine. Didn't he say that he installed Debian and *then* converted the disk to ext4. This would explain why the ext4 module is not included - the disk wasn't ext4 when the ramdisk was generated. No, I started with ext4. I then hit problems with the swap partition which I fixed manually. I don't know whether that was somehow related to the missing ext4 support. But then ext4 was in the installer environment so maybe not. Then I installed (or re-installed - I can't quite remember, but I think I could mount what was nominally an ext4 partition as ext3 in rescue mode and then complete boot the installation) on ext3. Maybe that was when a new initrd was generated without ext4: not sure. After getting a working ext3 installation, I then went into rescue mode to convert to ext4 manually. Rebooting then caused problems - as now expected since my initrd didn't include ext4. Will experiment more later today: I ought to try the whole thing with ext3 and see if I get swap partition problems again. ael -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#565511: re-installation partition problem [so not initramfs related?]
I am trying to reinstall from scratch.
I am stuck on the Partition disks step.
The screen shows my two discs:
SCSI2 (0,0,0) (sda) - 31.3 GB ATA FEM32G13M
SCSI3 (0,0,0) (sdb) - 16.0 GB Easy Disc
The first is highlighted/selected : it is the SSD which already has the
two partitions, one swap, the other previous root.
Pressing return (selecting the SSD) simply loops back to same screen.
On alt-F4, the only message that looks relevant is
.. partman: No matching physical volumes found.
However that message is not repeated when I loop on the selection screen.
--
I switch to a BusyBox shell on alt-F2 to investigate:-
1) cat /proc/partitions has the right entries:
major minor #blocks name
0 0 30539376 sda
0 1 29230236 sda1== the old root
0 2 1301265 sda2== old swap
[..snip..]
2) fdisk /dev/sda shows the right entries
(sda1 has id 83 Linux and sda2 id 82 Linux swap/Solaris
which look right to me. sda1 is marked bootable, but is
irrelevant with grub?..)
I revert to alt-F1 use Go Back.
Intead 0f selecting 1st option [Guided - use entire disk]
I try manual.
This time the SCSI 2 partition 1 is shown as ext4. I change that
to ext3.
I then need to set it up again: I include relatime mount option
because it is an ssd with limited write cycle life.
On alt-f4, I see
partman: mke2fs 1.41.9 (22-Aug-2009)
partman: warning 295 blocks unused
{I now consider re-partitioning to avoid the, admittedly small,
wasted space. How come the original auto partitioning
produced that? SSD blocks are expensive :-( }
I decide to repartition and choose a slightly larger swap partiton.
I seem to have no way to ensure no wasted space with partman,
so simply guess sizes.
The installation then completed without problems - using ext3.
ael
--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
