Created attachment 46902 [details] dmesg My notebook doesn't see the battery. It starts seeing it when I unplug it from the power. Sometimes this works, sometimes not. X server crashes a lot. It may be related to recent updates in Intel GPU drivers for Core I7 in Dell Latitude E6410. This issues started from rc3. rc2 was quite fine. I have attached dmesg output and Xorg.0.log since the X server crashed when I unplugged it and run mplayer to watch a movie.
Created attachment 46912 [details] xorg log
Let's use this entry for tracking the ACPI battery problem, please file a separate bug for the X problems.
Well, the problem is, there were no commits touching ACPI between -rc2 and -rc3. Any chance to bisect?
Just for the record, I filed a bug for X here https://bugs.freedesktop.org/show_bug.cgi?id=34060. I will install rc4 today and give it a try. Don't have time for bisecting now, maybe on a weekend.
rc-4 doesn't help, in fact it is even worse. Is this calltrace any relevant to this? : ------------[ cut here ]------------ WARNING: at kernel/printk.c:430 do_syslog+0xcb/0x550() Hardware name: Latitude E6410 Attempt to access syslog with CAP_SYS_ADMIN but no CAP_SYSLOG (deprecated and denied). Modules linked in: ses snd_hda_codec_hdmi enclosure snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss arc4 ecb usb_storage snd_hda_codec_idt uvcvideo videodev uas iwlagn i915 snd_hda_intel snd_hda_codec drm_kms_helper v4l2_compat_ioctl32 snd_hwdep iwlcore snd_pcm drm snd_timer i2c_algo_bit ppdev parport_pc dell_wmi mac80211 snd dell_laptop intel_agp i2c_i801 lp sg sparse_keymap ac processor cfg80211 intel_gtt e1000e intel_ips parport sdhci_pci battery container ehci_hcd i2c_core video button wmi firewire_ohci serio_raw usbcore sdhci iTCO_wdt mmc_core iTCO_vendor_support soundcore snd_page_alloc fuse evdev psmouse dcdbas rfkill firewire_core pcspkr crc_itu_t ext4 mbcache jbd2 crc16 sr_mod cdrom sd_mod ahci libahci libata scsi_mod Pid: 1382, comm: syslog-ng Not tainted 2.6.38-rc4-mainline #1 Call Trace: [<ffffffff81055d9a>] ? warn_slowpath_common+0x7a/0xb0 [<ffffffff81055e71>] ? warn_slowpath_fmt+0x41/0x50 [<ffffffff8105705b>] ? do_syslog+0xcb/0x550 [<ffffffff811949a7>] ? kmsg_open+0x17/0x20 [<ffffffff81189963>] ? proc_reg_open+0xa3/0x190 [<ffffffff81194990>] ? kmsg_open+0x0/0x20 [<ffffffff81194970>] ? kmsg_release+0x0/0x20 [<ffffffff811898c0>] ? proc_reg_open+0x0/0x190 [<ffffffff8112fcd0>] ? __dentry_open+0x100/0x370 [<ffffffff8113be6e>] ? generic_permission+0x1e/0xc0 [<ffffffff81130f61>] ? nameidata_to_filp+0x61/0x70 [<ffffffff8113fe28>] ? finish_open+0xd8/0x1c0 [<ffffffff8113f632>] ? do_path_lookup+0x82/0x160 [<ffffffff81140585>] ? do_filp_open+0x265/0x7e0 [<ffffffff810b9fa0>] ? call_rcu+0x10/0x20 [<ffffffff8114cd94>] ? alloc_fd+0xf4/0x150 [<ffffffff811f859d>] ? strncpy_from_user+0x2d/0x40 [<ffffffff81130fd4>] ? do_sys_open+0x64/0x110 [<ffffffff8113109b>] ? sys_open+0x1b/0x20 [<ffffffff8100bdd2>] ? system_call_fastpath+0x16/0x1b ---[ end trace 131d266fc9fa8a6f ]--- Now when I resume it from sleep I only get turned off display and it doesn't react on ctrl-alt-del. Haven't tested SysRQ keys. I'm beginning to believe that it might have something to do with this https://bugs.freedesktop.org/show_bug.cgi?id=29278.
It might be related, by then -rc4 would work on your machine.
In the dmesg I attached, there is one more trace which is something about fs/inode. That I find strange, so I just put it here too: ------------[ cut here ]------------ kernel BUG at fs/inode.c:1421! invalid opcode: 0000 [#2] PREEMPT SMP last sysfs file: /sys/devices/pci0000:00/0000:00:1f.2/host0/target0:0:0/0:0:0:0/block/sda/uevent CPU 0 Modules linked in: tun ipv6 snd_hda_codec_hdmi ses snd_hda_codec_idt arc4 enclosure ecb snd_hda_intel iwlagn i915 usb_storage snd_hda_codec uvcvideo videodev iwlcore drm_kms_helper sdhci_pci mac80211 uas v4l2_compat_ioctl32 drm snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_hwdep sdhci iTCO_wdt intel_agp lp firewire_ohci dell_wmi i2c_algo_bit sparse_keymap snd_mixer_oss ppdev ehci_hcd i2c_i801 mmc_core usbcore parport_pc processor cfg80211 parport i2c_core iTCO_vendor_support sg wmi dell_laptop intel_ips firewire_core e1000e snd_pcm intel_gtt battery button video container ac serio_raw psmouse pcspkr evdev dcdbas rfkill snd_timer snd soundcore snd_page_alloc crc_itu_t fuse ext4 mbcache jbd2 crc16 sr_mod cdrom sd_mod ahci libahci libata scsi_mod Pid: 11485, comm: umount Tainted: G D W 2.6.38-rc3-mainline #1 0667CC/Latitude E6410 RIP: 0010:[<ffffffff8114b6f0>] [<ffffffff8114b6f0>] iput+0x240/0x2a0 RSP: 0018:ffff88011556dda8 EFLAGS: 00010202 RAX: 0000000000000000 RBX: ffff880117828800 RCX: 0000000000000000 RDX: 0000000000000016 RSI: ffffffff8155d480 RDI: ffff880117828800 RBP: ffff88011556ddb8 R08: fffffffcfffffffc R09: fffffffcfffffffc R10: 00032034fffffffc R11: fffffff0fffffff8 R12: 0000000000000000 R13: 0000000000000083 R14: ffff880117828720 R15: ffff880117828380 FS: 00007fbcf1e02740(0000) GS:ffff8800db400000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: 00007f0448176fc0 CR3: 0000000116e71000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Process umount (pid: 11485, threadinfo ffff88011556c000, task ffff8801154ecc50) Stack: ffff880117828700 0000000000000000 ffff88011556de08 ffffffff811659a7 ffff88011556ddf8 ffffffffa0026e80 ffff88011556df28 ffff880117828700 0000000000000083 ffff880117828720 ffff88011556df01 ffff880001813000 Call Trace: [<ffffffff811659a7>] __blkdev_put+0x137/0x1c0 [<ffffffff81165b01>] blkdev_put+0xd1/0x170 [<ffffffff811345f9>] kill_block_super+0x49/0x80 [<ffffffffa011f98d>] fuse_kill_sb_blk+0x4d/0x60 [fuse] [<ffffffff81134955>] deactivate_locked_super+0x45/0x60 [<ffffffff81135735>] deactivate_super+0x45/0x60 [<ffffffff8114fc8a>] mntput_no_expire+0x9a/0xe0 [<ffffffff81150787>] sys_umount+0x67/0x390 [<ffffffff8100bdd2>] system_call_fastpath+0x16/0x1b Code: 41 00 83 05 c6 86 5f 00 01 48 89 05 6b 48 41 00 48 89 42 08 48 89 93 88 00 00 00 48 c7 83 90 00 00 00 40 ff 55 81 e9 4f fe ff ff <0f> 0b be 6e 05 00 00 48 c7 c7 0a f8 47 81 e8 8d b3 f0 ff 48 8b RIP [<ffffffff8114b6f0>] iput+0x240/0x2a0 RSP <ffff88011556dda8> dell-wmi: Received unknown WMI event (0x11) e1000e: eth0 NIC Link is Up 100 Mbps Full Duplex, Flow Control: None e1000e 0000:00:19.0: eth0: 10/100 speed: disabling TSO ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready ---[ end trace bc079d007ab92181 ]---
The problem seems to be related to the block layer, so reassigning to it.
This is still happening in -rc4. Just letting you know because of the email reminder.
Umm... I'm completely confused by this bug report. Adam, next time when you see kernel complaining, please report that as the main item. It's easier for everyone that way. It seems to be caused by the recent eviction related changes to FUSE. BUG_ON(inode->i_state & I_CLEAR) in iput() is being triggered. I'll ping Al and Miklos. Thanks.
(In reply to comment #10) > It seems to be caused by the recent eviction related changes to FUSE. > BUG_ON(inode->i_state & I_CLEAR) in iput() is being triggered. I'll ping Al > and Miklos. It's iput on the block device at umount (likely of a ntfs-3g volume), not iput on a fuse inode. OK, the block dev might be on a fuse filesystem as well, but we don't know that, and it's not likely on a "normal" setup. Adam, is this reproducible? What's happening when that BUG hits?
I'm sorry guys, I was originally reporting the bug from comment #5. Later I noticed that the attached dmesg contains what's in #7. That is what you are referring to a FUSE bug. I wasn't sure if I should open a new bug for that, but then this bug was transfered to IO bugs. Now that you started dealing with the IO bug, maybe you should rename it if it's possible. Again, sorry for confusion. I believe I caused another confusion with my comment #9 that this happens every time in -rc4. I was referring to the original trace from #5. About the FUSE trace, I don't really know. I have quite a lot of troubles running Linux on my laptop now, so I'm quite busy with all the bugs here. I will try to reproduce it but I cannot say anything else right now.
Okay, it wasn't so hard to find what causes the FUSE bug. It's my external USB hard drive. It is mounted with ntfs-3g. It happens every time I disconnect it before unmounting. Do you need any more info?
I opened two new bugreports and made this bug depend on them, so we don't forget anything. I'm not entirely sure I didn't miss anything though, so double check me :|
I think the problem may be fixed by some patches that went into the Linus' tree earlier today. Please retest when -rc5 is out.
I am having this same issue with my Dell Studio XPS 1640 on dave airlied's drm-radeon-testing branch which is reporting -rc4, I will also try on a stock rc5 when it comes out. If you need more info let me know.
Note I don't recive a full lockup only a kernel oops message in dmesg matching the one in comment 5, aside from the slight machine and module differences.
The call trace in comment #7 definitely comes from the dentry lookup code that's got a few important fixes recently, so it would be good to test 2.6.38-rc5-git1 (or even -git2 when it's out). If the problem persists, we'll need to look deeper. For example, it seems to follow from the call trace in comment #7 that the dell-wmi driver is involved somehow (which kind of explains why Dells are affected), although it's not been modified after 2.6.37.
The event from dell-wmi seems to be related to media changes - I'll see if I can find out from Dell what this means. It should be unrelated to the problem, though.
Created attachment 48182 [details] dmesg This is dmesg from just started -rc5 kernel. Battery seems to be seen by KDE battery applet. I 'm going to do some testing now.
Created attachment 48192 [details] dmesg after resume from suspend Suspend and resume actually works now. Dmesg contains the fs/inode stacktrace. One more weird thing, while changing backlight and moving mouse, the mouse is very slow, like flickering, like it's on one place for like .5 sec and then like 50px elsewhere. I hope you can imagine what I mean.
Created attachment 48212 [details] dmesg after disconnecting mounted external hdd with ntfs-3g fs The last test about disconnecting the external ntfs drive. It throws the same error, i think the same.
Hmm, and what's even worse now, after plugging the disc back, I don't see it. It's not even registered in dmesg as you can see in the most recent one.
Do you have a removable drive with a different filesystem on it (like VFAT)? If so, could you please check if it has the same problems?
Also, do I understand correctly that the original issue appears to have been fixed?
Yes, please close this bug, I will try to find some USB key and let you know in bug report 29202.
I'm facing the original issue about the battery not beeing seen again(I'm still running -rc5). Here is dmesg | grep ACPI: BIOS-e820: 00000000db65f000 - 00000000db67f000 (ACPI data) BIOS-e820: 00000000db67f000 - 00000000db76f000 (ACPI NVS) ACPI: RSDP 00000000000fe300 00024 (v02 DELL ) ACPI: XSDT 00000000db67de18 00064 (v01 DELL E2 06222004 MSFT 00010013) ACPI: FACP 00000000db75fc18 000F4 (v04 DELL E2 06222004 MSFT 00010013) ACPI Warning: 32/64 FACS address mismatch in FADT - two FACS tables! (20110112/tbfadt-369) ACPI Warning: 32/64X FACS address mismatch in FADT - 0xDB76BF40/0x00000000DB76ED40, using 32 (20110112/tbfadt-486) ACPI: DSDT 00000000db73e018 0A248 (v01 DELL E2 00001001 INTL 20080729) ACPI: FACS 00000000db76bf40 00040 ACPI: APIC 00000000db67cf18 0008C (v02 DELL E2 06222004 MSFT 00010013) ACPI: TCPA 00000000db76dd18 00032 (v02 00000000 00000000) ACPI: MCFG 00000000db76dc98 0003C (v01 A M I GMCH945. 06222004 MSFT 00000097) ACPI: HPET 00000000db76dc18 00038 (v01 DELL E2 00000001 ASL 00000061) ACPI: BOOT 00000000db76db98 00028 (v01 DELL E2 06222004 AMI 00010013) ACPI: SLIC 00000000db766818 00176 (v03 DELL E2 06222004 MSFT 00010013) ACPI: SSDT 00000000db74d018 009F1 (v01 PmRef CpuPm 00003000 INTL 20080729) ACPI: Local APIC address 0xfee00000 ACPI: PM-Timer IO Port: 0x408 ACPI: Local APIC address 0xfee00000 ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled) ACPI: LAPIC (acpi_id[0x02] lapic_id[0x04] enabled) ACPI: LAPIC (acpi_id[0x03] lapic_id[0x01] enabled) ACPI: LAPIC (acpi_id[0x04] lapic_id[0x05] enabled) ACPI: LAPIC (acpi_id[0x05] lapic_id[0x04] disabled) ACPI: LAPIC (acpi_id[0x06] lapic_id[0x05] disabled) ACPI: LAPIC (acpi_id[0x07] lapic_id[0x06] disabled) ACPI: LAPIC (acpi_id[0x08] lapic_id[0x07] disabled) ACPI: IOAPIC (id[0x02] address[0xfec00000] gsi_base[0]) ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) ACPI: IRQ0 used by override. ACPI: IRQ2 used by override. ACPI: IRQ9 used by override. Using ACPI (MADT) for SMP configuration information ACPI: HPET id: 0x8086a701 base: 0xfed00000 ACPI: Core revision 20110112 ACPI FADT declares the system doesn't support PCIe ASPM, so disable it ACPI: bus type pci registered ACPI: EC: Look up EC in DSDT [Firmware Bug]: ACPI: BIOS _OSI(Linux) query ignored [Firmware Bug]: ACPI: BIOS _OSI(Linux) query ignored ACPI: SSDT 00000000db7eaa18 00474 (v01 PmRef Cpu0Ist 00003000 INTL 20080729) ACPI: Dynamic OEM Table Load: ACPI: SSDT (null) 00474 (v01 PmRef Cpu0Ist 00003000 INTL 20080729) ACPI: SSDT 00000000db7e8018 00891 (v01 PmRef Cpu0Cst 00003001 INTL 20080729) ACPI: Dynamic OEM Table Load: ACPI: SSDT (null) 00891 (v01 PmRef Cpu0Cst 00003001 INTL 20080729) ACPI: SSDT 00000000db7e9a98 00303 (v01 PmRef ApIst 00003000 INTL 20080729) ACPI: Dynamic OEM Table Load: ACPI: SSDT (null) 00303 (v01 PmRef ApIst 00003000 INTL 20080729) ACPI: SSDT 00000000db7e7d98 00119 (v01 PmRef ApCst 00003000 INTL 20080729) ACPI: Dynamic OEM Table Load: ACPI: SSDT (null) 00119 (v01 PmRef ApCst 00003000 INTL 20080729) ACPI: Interpreter enabled ACPI: (supports S0 S3 S4 S5) ACPI: Using IOAPIC for interrupt routing ACPI: EC: GPE = 0x10, I/O: command/status = 0x934, data = 0x930 ACPI: No dock devices found. PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and report a bug ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-3e]) ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P0P1._PRT] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.RP01._PRT] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.RP02._PRT] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.RP03._PRT] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.RP04._PRT] ACPI: PCI Root Bridge [CPBG] (domain 0000 [bus 3f]) ACPI: PCI Interrupt Link [LNKA] (IRQs 1 3 4 5 6 7 10 12 14 15) *11 ACPI: PCI Interrupt Link [LNKB] (IRQs 1 3 4 5 6 7 *11 12 14 15) ACPI: PCI Interrupt Link [LNKC] (IRQs 1 3 4 5 6 7 *10 12 14 15) ACPI: PCI Interrupt Link [LNKD] (IRQs 1 3 4 5 6 7 11 12 14 15) *10 ACPI: PCI Interrupt Link [LNKE] (IRQs 1 3 4 *5 6 7 10 12 14 15) ACPI: PCI Interrupt Link [LNKF] (IRQs 1 3 4 5 6 7 11 12 14 15) *0, disabled. ACPI: PCI Interrupt Link [LNKG] (IRQs 1 *3 4 5 6 7 10 12 14 15) ACPI: PCI Interrupt Link [LNKH] (IRQs 1 3 4 5 6 7 11 12 14 15) *0, disabled. PCI: Using ACPI for IRQ routing pnp: PnP ACPI init ACPI: bus type pnp registered pnp 00:00: Plug and Play ACPI device, IDs PNP0a08 PNP0a03 (active) pnp 00:01: Plug and Play ACPI device, IDs PNP0200 (active) pnp 00:02: Plug and Play ACPI device, IDs INT0800 (active) pnp 00:03: Plug and Play ACPI device, IDs PNP0103 (active) pnp 00:04: Plug and Play ACPI device, IDs PNP0c04 (active) system 00:05: Plug and Play ACPI device, IDs PNP0c02 (active) pnp 00:06: Plug and Play ACPI device, IDs PNP0b00 (active) pnp 00:07: Plug and Play ACPI device, IDs PNP0303 (active) pnp 00:08: Plug and Play ACPI device, IDs PNP0401 (disabled) pnp 00:09: Plug and Play ACPI device, IDs DLL040a PNP0f13 (active) system 00:0a: Plug and Play ACPI device, IDs PNP0c02 (active) pnp 00:0b: Plug and Play ACPI device, IDs SMO8800 (active) pnp 00:0c: Plug and Play ACPI device, IDs PNP0a03 (active) pnp: PnP ACPI: found 13 devices ACPI: ACPI bus type pnp unregistered ata1.00: ACPI cmd 00/00:00:00:00:00:a0 (NOP) rejected by device (Stat=0x51 Err=0x04) ata1.00: ACPI cmd 00/00:00:00:00:00:a0 (NOP) rejected by device (Stat=0x51 Err=0x04) ACPI: acpi_idle yielding to intel_idle ACPI: Lid Switch [LID] ACPI: Power Button [PBTN] ACPI: Sleep Button [SBTN] ACPI: resource 0000:00:1f.3 [io 0x7000-0x701f] conflicts with ACPI region SMBI [io 0x7000-0x700f] ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver ACPI: Power Button [PWRF] ACPI Exception: AE_TIME, Returned by Handler for [EmbeddedControl] (20110112/evregion-474) ACPI Error: Method parse/execution failed [\_SB_.PCI0.LPCB.ECDV.ECR1] (Node ffff88011bc43c08), AE_TIME (20110112/psparse-536) ACPI Error: Method parse/execution failed [\ECRB] (Node ffff88011bc43d70), AE_TIME (20110112/psparse-536) ACPI Error: Method parse/execution failed [\ECM8] (Node ffff88011bc43f28), AE_TIME (20110112/psparse-536) ACPI Error: Method parse/execution failed [\ECU0] (Node ffff88011bc43fc8), AE_TIME (20110112/psparse-536) ACPI Error: Method parse/execution failed [\ECG9] (Node ffff88011bc45000), AE_TIME (20110112/psparse-536) ACPI Error: Method parse/execution failed [\_SB_.BAT0._BIF] (Node ffff88011bc45668), AE_TIME (20110112/psparse-536) ACPI Exception: AE_TIME, Evaluating _BIF (20110112/battery-417) ACPI: Deprecated procfs I/F for battery is loaded, please retry with CONFIG_ACPI_PROCFS_POWER cleared ACPI: Battery Slot [BAT0] (battery present) ACPI: Deprecated procfs I/F for battery is loaded, please retry with CONFIG_ACPI_PROCFS_POWER cleared ACPI: Battery Slot [BAT1] (battery absent) ACPI: Deprecated procfs I/F for AC is loaded, please retry with CONFIG_ACPI_PROCFS_POWER cleared ACPI: AC Adapter [AC] (on-line) parport_pc 00:08: reported by Plug and Play ACPI ACPI: Video Device [VID1] (multi-head: yes rom: no post: no)
Thanks, but please attach such things instead of pasting them. It's much more useful that way. Does it also happen with CONFIG_ACPI_PROCFS_POWER unset?
It's quite hard to reproduce. This happened for the first time in almost a week. The only unusual thing I did yesterday was that I unplugged it and watched movie, then plugged it back and turned off. Today when I booted it it happened. And what I always forget to mention, since -rc5 when I shutdown the computer it always hangs on the POWER OFF line. That is when every daemon is off and it should just switch off the power. It doesn't, I have to turn it off by holding the power button for 5 secs. > Does it also happen with CONFIG_ACPI_PROCFS_POWER unset? I can't try now.
I am getting a hang on POWER OFF as well, I can paste my dmesg and I'll try building with that unset, though I'm still not sure if my issues and the original subbmitted are related. Bu I have been consistantly getting that same call trace on every boot. I have yet to see any other symptoms from this other than the not powering off and the call trace.
Created attachment 48522 [details] dmesg from Studio XPS 1640 with similiar call trace
The call trace is related to the way in which syslog is read (the reading process is supposed to have CAP_SYSLOG, but it has CAP_SYS_ADMIN only). IOW, it's completely unrelated to the issue at hand. I wonder if you're seeing bug #25522 rather than this one?
(In reply to comment #32) > The call trace is related to the way in which syslog is read (the reading > process is supposed to have CAP_SYSLOG, but it has CAP_SYS_ADMIN only). > IOW, it's completely unrelated to the issue at hand. > > I wonder if you're seeing bug #25522 rather than this one Ahh ok, then I'll look at that bug and if its right I'll comment there though it appears to be closed. The call trace still occurs for me with rc5 so if it continues with the next rc or release I'll file a new bug.